This is the mail archive of the kawa@sourceware.org mailing list for the Kawa project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: java/kawa hello world example


On 08/21/2010 02:51 PM, Helmut Eller wrote:
For me, interactive programming includes that it's possible to compile a
file and load the compiled code into the running Lisp.  I want to use
the same file, with the same module imports/exports as I would for a
batch compiler.  Then I want to make a small fix to the file, compile it
and load it again.  And the (existing) bindings should be updated in
some sensible way.  Yes, updatable bindings are obviously a problem for
compile-time analysis.

Yes that would be nice - even for just a repl.


To do a better job we need some combination of:
(1) --no-inline or other way to force indirection;
(2) dependency tracking to possibly force re-compilation;
(3) back-patching so existing procedure objects point to
the version.

Kawa already has crude module-level dependency-tracking, and a
mechanism for re-compiling and re-loading a module when it changes.
(This is used for the web server support.)

What we probably want is to change the require/import mechanism
so that when a module is re-loaded we patch existing function
pointers to reference the re-compiled functions.  This isn't
that difficult: We just patch the existing ModuleMethod objects.

The other change is (in interactive mode) to partly disable
optimizations: Rather than calling Java methods directly,
we "apply" the Procedure objects, even when known.
The --no-inline option is supposed to do this.

That leaves variable initialization and other top-level
actions as the problem.  The easiest is to just evaluate
that code when re-loading.  Once can use define-variable
to suppress re-initialization.

So I think we change interactive mode used --no-inline (or similar)
and we added a kludge to re-use/patch/share ModuleMethod
object when re-loaded, then I think we'd get close to what we need.

(Ideally I only want to recompile a single function because compiling a
big file is quite slow;

How slow? It might be useful to know if there are a few places that use most of the compilation time.

but I have given up all hopes on that already.)

That should be doable, as long as the IDE can tell us what has changed. However, let's not worry about that for now.

I think this is quite different from typing some small snippet in a REPL
(which is of course also important).  And it seems that Kawa prefers to
do more compile-time analysis instead of making interactive programming
easier.

It should be possible to do both.


One option to consider is lazy compilation of functions - that might
be desirable for a function in a REPL that has forward references.
I.e. we don't compile a function until it is called.  An IDE can
set a "dirty" flag when it is edited.

Implementing the condition system properly is also low on the priority
list.  I guess it will never be fixed.

I apologize. You did send me code code for R6RS exceptions over 2 years ago,
and I'd completely forgotten about it. There is some other stuff I want to
get done before JavaOne, but after that please keep bugging me until
we get something reasonable.


One feature that would require more than simple REPL I/O is
M-. - if you're in a Lisp/Scheme buffer, that should take you
to the definition.  To do that robustly needs compiler help
- at least the compiler needs to emit the appropriate mapping
tables.  Doubly nice if M-. in a Kawa buffer can take you
to the definition in a Java source file.

swank-kawa does it this way: it evaluates the name, then takes the function object to figure out which class/bytecode corresponds to it and uses JDI to get the source location form the line number table. It also can bring you to Java source files (even the ones in src.zip of the JDK).

That doesn't work for local variables, method/field names, overloaded names, and more. Better would be to ask the compiler to generate a mapping from reference to definition - since the compiler has that information.

What I'd like to do is have some mechanism that works for both CEDET
and Smile.  I don't know if there is a file format that gives
precise mappings from references to definitions, and if so whether
CEDIT or Smile can use it.

Evaluation, obviously, doesn't work for non-exported bindings.  And
people shouldn't use eval anyway, right?

Yes, this is another example of how eval isn't the right thing.


Kawa also emits relative filenames;

You mean the SourceFile attribute? That is a requirement of the class file specification, as I understand it.

so if swank-kawa doesn't know where
look for it can't find the source file.

If you compile a file with an absolute pathname, then Kawa will write the absolute path in the SourceDebugExtension attribute. You can see it with gnu.bytecode.dump. -- --Per Bothner per@bothner.com http://per.bothner.com/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]