This is the mail archive of the
kawa@sourceware.org
mailing list for the Kawa project.
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/