Re: IMHOs...

[Marco Vezzoli <marco dot vezzoli at st dot com>]

Thank you for the answer.

per@bothner.com wrote:
> 
> 
> Of course is only big in the context of applets that somebody downloads
> and runs in their browser each time they want to use it.  In terms of
> disk space it is not big (except for some really tiny computers).  So
> one approach is to have people download the kawa jar file, and save it
> in their browser's class path.

True. This is not so easy to manage for unskilled users but can be a
first solution. 

> Basically, if you use eval, I don't think there is much sense in
> trying to split things up.  I think it makes sense to split
> kawa-compiled.jar into a "kawa-rte" part and a "kawa-dk" part.

It was only an hypothesis, usually I don't need to use 'eval'. The idea
is to find some reasonable set of restrictions that can reduce
substantially the amount of bytecode needed for running a kawa compiled
program.

> 
> Run-time:
>         gnu.math
>         gnu.mapping
>         gnu.text
>         gnu.kawa.util
>         kawa
>         kawa.lib
>         kawa.standard
> 
> Compiler:
>         gnu.bytecode
>         gnu.expr
>         kawa.lang
>         gnu.kawa.reflect
> 

The jars generated with jdk 1.2 on solaris are respectively 867221 bytes
long (Compiler & Run-time) and 641391 bytes long (only runtime, 26%
smaller). 
 
> Some find tuning and experimentation of this division will probably be
> needed, but if you want to experiement, I'm here to answer your
> questions.

In my first tests some code compiled with --main -C (kawa-1.6.64) works
with the full package but not with run-time only: the JVM yelds 'class
not found <classname>'; of course the class is in the classpath.
I can send the source code, but it seems a problem not related to.

> 
> Working on it right now.  It *may* (if I get it working well enough)
> appear in the next snapshot.

Good!

> 
> The idea is that each Scheme "module" (source file, usually) is compiled
> to a Java class.  The non-private top-level definitions are compiled
> to public fields.  (A top-level procedure has both one or more methods
> plus a ModuleMethod field.)  This part is basically working.
> There can be multiple instances of a module, by making the fields
> be non-static.
> 
> To "import" a module you add the definitions exported by a class
> to the definitions currently visible.  By default, these imported
> definitions are not re-exported - in fact they are only visible
> at compile-time.  This is the part I'm currently working on.
> The tricky part is that I also want this to be efficient - for a
> procedure, importing module should generate code that directly
> calls the method in the exporing module, when possible.

Ok, it seems an intresting architecture, I'll wait for the release.

-- 
	(--cafe babe--) 
Marco Vezzoli	marco.vezzoli@st.com
CR&D Intranet Developement   STMicroelectronics
tel. +39 039 603 6852 fax. +39 039 603 5055