This is the mail archive of the
kawa@sourceware.org
mailing list for the Kawa project.
Re: "Image-based development" with Kawa
Oliver Flasch wrote:
This is interesting. However, my system does not have the concept of a
"source file" per se. Would it be possible to implement a "compile"
macro/procedure, which would take a list of expressions and compile them
as if they where contained in a source file passed to "compile-file"?
It should be trivial to generalize to a Reader (i.e. a sequence of
characters), but taking an intermediate list structure may be harder.
The Kawa compiler interleaves reading (chars -> lists) and expansion
(lists -> internal form).
Make sure <my-class> "references" the enclosing module, so it gets
serialized. You can probably do that by serializing its ClassLoader,
which is an ArrayClassLoader (see below).
Can you give me a hint on how to get hold on this ArrayClassLoader when
the class has been defined in a read-eval-print loop (where all
interaction with my system actually takes place, I am not using
"compile-file" at all, at this point in time)?
I think you answer your own question later.
Sorry if this is a stupid question to ask, but it might help my
understanding a lot if you could comment on the following behavior I
observe in a Kawa read-eval-print loop. I am using the <2d-vector> class
from the Kawa docs (which has some methods defined):
#> (define-simple-class <2d-vector> () [...])
-> undefined
#> (*:getMethods <2d-vector>)
-> #!null ;; no methods defined?
#> (*:scale (*:add (make <2d-vector>) (make <2d-vector>)) 1.0)
-> $N2d$Mnvector@992bae
#> (*:getMethods <2d-vector>)
-> $N2d$Mnvector.add($N2d$Mnvector)$N2d$Mnvector
#> (*:getClassLoader (*:getClass <2d-vector>))
-> sun.misc.Launcher$AppClassLoader@133056f ;; an AppClassLoader, not an
ArrayClassLoader?
Note that the "value" of the name <2d-vector> is an instance of
gnu.bytecode.ClassType, not an instannce of java.lang.Class. The
reason is ClassType can be used to name a class at compile-time
that doesn't yet exist, since it hasn't been compiled yet.
This causes some confusion. It may be possible to revisit this
separation, but I haven't thought through the issues involved.
I learned from your "Kawa internals" paper that "non-simple" forms, like
class-definitions, passed to a read-eval-print loop are in fact wrapped
into a ModuleBody which gets rewritten into a ModuleExp. This is then
compiled to bytecodes forming a Runnable class. In the case of a
class-definition, the interactively defined class would be represented
as an inner class of this Runnable class. If I understand you correctly,
the bytecodes are then loaded via an ArrayClassLoader and the Runnable
class is run. The solution to my problem then would be to get hold of
this ArrayClassLoader and serialize it together with the ClassType
object representing the interactively defined class. When de-serializing
the class, I would have to de-serialize the associated ArrayClassLoader
and register it as a parent of the current ClassLoader.
The last part sounds strange. It makes more sense to de-serialize the
ArrayClassLoader, and get load the serialized class from the copied
classloader.
Could this work? If so, it would be possible to allow "image-based"
development in Kawa/Scheme, which would be a very important feature for
the domain I am working in.
Let's hope so!
--
--Per Bothner
per@bothner.com http://per.bothner.com/