sablevm-developer — SableVM developer mailing list

Re: [Sablevm-developer] Porting sablevm to powerpc

[Mark W. <ma...@kl...>]

Hi,

On Thu, 2002-08-15 at 23:46, Etienne M. Gagnon wrote:
> On Thu, Aug 15, 2002 at 10:43:05PM +0200, Mark Wielaard wrote:
> > Impressive! I am very interested in a VM that uses GNU Classpath and
> > that I can use on powerpc (Debian GNU/Linux system).
> > What 25 lines of code do I have to look at?
> 
> You have to look at the following files:
> 
> src/libsablevm/include/jni_system_specific.h
> src/libsablevm/system.h
> src/libsablevm/system.c

OK, after spending a couple of hours learning powerpc assembly and the
gcc asm constraints I think that I have something that might be what is
needed for powerpc. Unfortunately it doesn't work correctly yet, but
looking at the output of --verbose I get the impression that we are
almost there. Here are the last 15 lines for sablevm --verbose Hello:

[verbose class: creating "[Ljava/util/Hashtable$HashEntry;"]
[verbose class: loading "java/util/StringTokenizer"]
[verbose class: loading "java/util/Enumeration"]
[verbose class: creating "[Ljava/lang/String;"]
[verbose class: loading "java/lang/StringBuffer"]
[verbose class: loading "java/lang/VMSecurityManager"]
[verbose class: loading "java/util/WeakHashMap$WeakBucket$WeakEntry"]
[verbose class: loading "java/io/BufferedInputStream"]
[verbose class: loading "java/io/FilterInputStream"]
[verbose class: loading "java/io/InputStream"]
[verbose class: loading "java/io/FileInputStream"]
[verbose class: loading "java/io/FileDescriptor"]
[verbose class: loading "java/lang/SecurityException"]
java/lang/ExceptionInInitializerError
[verbose gc: total gc time = 0 sec 0 usec]

Attached are my versions of the above files. If there is someone with
some powerpc knowledge on the list then I would highly appreciate it if
you could take a look.

Have to get some sleep now.

Cheers,

Mark 

Re: [Sablevm-developer] SableVM requirement for sequential consistency

[Etienne M. G. <eti...@uq...>]

Here's the missing reference:

Etienne M. Gagnon wrote:
>... in particular D. Bacon's 
> thin locks[1].


[1] D. Bacon et Al., Thin Locks: Featherweight synchronization for Java. In 
proceedings of PLDI.  ACM Press, 1998.

Etienne
-- 
Etienne M. Gagnon                    http://www.info.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/

Re: [Sablevm-developer] SableVM requirement for sequential consistency

[Etienne M. G. <eti...@uq...>]

Hi Professor Pugh,

> Does everyone understand that no commodity multiprocessor offers a 
> sequentially consistent memory model, and that in particular x86 and 
> Alpha SMPs are not sequentially consistent?
 >
 > In fact, the Alpha has the weakest memory model that I know of.
 >
 > What is the story?

I wrote this note, and yes I do know that no commodity multiprocessor offers a 
sequentially consistent memory model.

SableVM claims "easy portability".  In my definition, this means that you should 
only have to modify a few well identified functions and macro definitions, and 
possibly implement a few inline assembly functions, and you're done.

Now, Implementing an "efficient" JVM requires one to pay attention to the cost 
of operations, and more specifically, synchronization operations.

The only "system independent" synchronization operations available to a 
relatively pure ISO C/POSIX program are pthread operations, which can become 
very costly if used too frequently.  For such reasons, people have developed 
"light" synchronization schemes; in particular D. Bacon's thin locks[1].

A "sound" implementation of thin locks, on a multi-processor system, would have 
to flush the cache in the "non-atomic" monitor exit implementation.  (This cache 
  flush business is not discussed in his paper).  Currently, SableVM implements 
no  such system-specific operation in "_svmf_exit_object_monitor()".

SableVM implements thin locks, and a few other tricks for operations that would 
otherwize require "full synchronization" (e.g. pthread_mutex_lock()).  The 
soundness of such operations, on SMP systems, would require adding cache 
related, system-specific, inline assembly function calls.

I have quickly investigated the question, at some point, (yes, I have also taken 
graduate courses on multi-processors, covering the many weak memory model 
designs), but I quickly discovered that every processor has its own cache 
related instructions, with various definitions of "memory barriers", etc.  So, 
my supervisor and me decided that we would leave this stuff outside the scope of 
my Ph.D. .  There's only so much you can do, in a single Ph.D.; you want to 
leave a few things for tenure track too... ;-)

So, in summary, the POSIX and strong memory model requirements on the SableVM 
web page are "weak" requirements.  These requirements only imply that porting to 
systems that do not meet these requirements will require a little more work, and 
probably some discussions with the VM designer to identify all the necessary 
modification points.  I admit: I should have been clearer on this.  I will 
update the web page.  [I also wanted to anticipate bug reports about misbehavior 
  of the current SableVM implementation on a multi-processor system].

Incidentally, I had a few questions I wanted to eventually ask you on the 
subject.  I would be very grateful if you could help me with some replies, when 
I get out of my current rush and have some time to carefully write the questions 
down (in the Fall).

Regards,

Etienne

-- 
Etienne M. Gagnon                    http://www.info.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/

[Sablevm-developer] SableVM requirement for sequential consistency

[Bill P. <pu...@cs...>]

Somebody pointed out to me this note on the SableVM home page:

>SableVM requires an ANSI/ISO C compiler (but preferably GCC) and a 
>POSIX platform.  It requires a strong memory model (sequential 
>consistency) on multiprocessor systems.  SableVM is currently known 
>to run on the i*86 and alpha processors with GNU/Linux.

Does everyone understand that no commodity multiprocessor offers a 
sequentially consistent memory model, and that in particular x86 and 
Alpha SMPs are not sequentially consistent?

In fact, the Alpha has the weakest memory model that I know of.

What is the story?

	Bill Pugh

[Sablevm-developer] Weird link error on FreeBSD

[Archie C. <ar...@de...>]

Hi,

First of all, if anyone else on this lists is interested in running
SableVM on FreeBSD, please feel free to offer suggestions re the port
(I'm the maintainer).

The FreeBSD version of SableVM doesn't seem to work correctly and
I'm mystified as to why. It might be some kind of obscure libtool
problem.

In any case, I'd appreciate a sanity check from the Linux crowd.
Does this happen to you? Under FreeBSD, running the attached class
file (produced with jikes 1.15) gives this output:

 $ sablevm DoublePrint
 *** Couldn't bind native method Java_java_io_FileOutputStream_writeInternal ***
 *** or Java_java_io_FileOutputStream_writeInternal__I_3BII ***
 *** Couldn't bind native method Java_java_io_FileOutputStream_writeInternal ***
 *** or Java_java_io_FileOutputStream_writeInternal__I_3BII ***
 java/lang/UnsatisfiedLinkError

But if you comment out the "float f = ..." line, it works just fine..
this seemingly makes no sense of course.

However, Float.intBitsToFloat() is a native method that requires
loading in the libjava-lang.so shared library. Perhaps this affects
SableVM's ability to subsequently load in the libjava-io.so shared
library, causing the error above.

Any ideas appreciated...

Thanks,
-Archie

__________________________________________________________________________
Archie Cobbs     *     Packet Design     *     http://www.packetdesign.com

Re: [Sablevm-developer] Porting sablevm to powerpc

[Etienne M. G. <eti...@uq...>]

Hi Mark.

Grzegorz told me he would be away from his email for a few days, (I
should be too, very soon), so I will reply to your message, as I think
this reply might benefit other potential porters..

On Thu, Aug 15, 2002 at 10:43:05PM +0200, Mark Wielaard wrote:
> Impressive! I am very interested in a VM that uses GNU Classpath and
> that I can use on powerpc (Debian GNU/Linux system).
> What 25 lines of code do I have to look at?

You have to look at the following files:

src/libsablevm/include/jni_system_specific.h
src/libsablevm/system.h
src/libsablevm/system.c

The easiest would be to forget about inline-threaded engine for now.
It should take me at most a few minutes to fix it on the powerpc, once
the remaining is in place; I have to add calls to _svmf_iflush in
_svmf_get_sequence. _svmf_iflush already has a draft implementation
for powerpc.  I have already setup the configure.ac stuff to select
the direct-threaded engine by default for non i*86-*-gnu systems.

The single most difficult part of porting SableVM to a new system, is
implementing the _svmh_compare_and_swap function, which ***MUST*** be
an *ATOMIC* operation.

[Note: You also have to worry about the _svmf_iflush stuff when you
want to run the inline-threaded engine on processors with distinct
instruction and data caches.]

I hope this helps.

Etienne
-- 
Etienne M. Gagnon                    http://www.info.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/

[Sablevm-developer] Help, in the next weeks

[Etienne M. G. <eti...@uq...>]

Hi all!

First, I would like to thank you all for your patience waiting for a
stable SableVM version to be released.  It has taken more time than I
thought, but it is there now.

Second, I would like to ask for your forgiveness in the next few
weeks; I am currently finishing the writing of my Ph.D. thesis, and I
have to put some time planning the teaching of 2 courses (graduate +
undergraduate) that start in 2 weeks from now, in addition to some
graduate/undergraduate supervision meetings for summing-up the summer
work.  So, to summarize this: I will be busy;-)

The result of this is that:

1- I have removed the "moderation" on the sablevm-developer list
(subscription is still required).

2- I will probably not be answering messages.

3- I would be very grateful that you help by answering new users and
developers that send messages to the sablevm-user and
sablevm-developer lists.

Thanks!  And have fun playing around with SableVM.

Etienne
-- 
Etienne M. Gagnon                    http://www.info.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/

[Sablevm-developer] Porting sablevm to powerpc

[Mark W. <ma...@kl...>]

Hi (reply to sablevm-developer original message was on debian lists),

On Thu, 2002-08-15 at 02:14, Grzegorz Prokopski wrote:
> 
> So I took some time to check what that "easily portable" means in
> practise - and started porting this JVM to alpha.
> 
> It was my first time I was doing a port and I never wrote in alpha's
> assembler, so it took very long - about 24 hours and resulted (of
> mostly learning) in small diff (around 100 lines, but there was some
> code reorganizing in it too, so real diff was around 25 lines!)
> 
> <blink><B>25 lines to port JVM to new architecture</B></blink>
> 
> Anyway - now SableVM JVM supports ia32 and alpha.
> Official 1.0.2 release will be made soon.
> 
> More arches will come.

Impressive! I am very interested in a VM that uses GNU Classpath and
that I can use on powerpc (Debian GNU/Linux system).
What 25 lines of code do I have to look at?

I have no experience with powerpc assembly so if anybody has references
that would be greatly appreciated.

I would use it to finally setup a autobuilder/tester for Classpath CVS
as I have currently running (on that powerpc machine) for libgcj (which
has still a long way to go for being completely merged with GNU
Classpath).

Cheers,

Mark

Re: [Sablevm-developer] new debian packages of sablevm and friends

[John L. <je...@pi...>]

Grzegorz

> > PS: Looking at all gnu-java related CVS trees - I am getting really worried,
> > as it looks like there's no real development being made. Times 'since last
> > update' are weeks at best - usually months and sometimes years. A lot of
> > features has only it's stub files put into CVS with no further action.
> > And where's awt/swing development? I hardly see any.

Are you reading the Changelogs?
 
> > Can we really count on that GNU Classpath will be THE Classpath for
> > free software java projects? What do you think?

Well, do you see any competition?

> I think that one of Classpath's current problems was that it lacked an
> appropriate VM for doing development.  There's ORP, but this is a JIT,
> and it has some problems, and locating problems in a JIT is much more
> difficult.  In fact, you can easily trace SableVM's execution with a
> debugger, add debugging traces on every exception thrown, (etc.) very
> easily.  Also, SableVM has a solid implementation of JNI (with some
> minor holes, easily fillable), which should help.

Yeah, it's a cyclical process where the VMs gets better, Classpath gets
better, the VMs get better ...

The number of fairly stable VMs that work with classpath are increasing
too. I think the whole system is close to achieving critical mass if
enough people start using and testing the software. (And this is where
packages like debian packages are critical)
 
> There is actually some development on the AWT (Swing?) side.  It could
> be faster, but it's there.  You should look at the classpath cvs
> commits ML.  You'll see things like
> http://mail.gnu.org/pipermail/commit-classpath/2002-July/000916.html
> which is pretty recent.

AWT has traditionally not been the focus of classpath and free java
projects. But it's coming along,  I don't think there is too much work
left before AWT becomes useful.

> GNU Classpath is a little like Debian; it is not backed off by a
> companyy, so you have to give it time.  Eventually, robust things come
> out of it.

Indeed.

John Leuner

Re: [Sablevm-developer] new debian packages of sablevm and friends

[Etienne M. G. <eti...@uq...>]

On Mon, Aug 12, 2002 at 01:48:56PM +0200, Grzegorz Prokopski wrote:
> sablevm 1.0.1-3 is uploaded to debian.sente.pl - I fixed it there
> I also added manual page java.sablevm.1.gz which is linke thru
> alternatives to java.1.gz when you have sablevm 'java' wrapper choosen.

OK, I'll try it.

> 
> > Then I tried to run HelloWorld.jar but it failed, with something like
> > classnotfound.  (I am too tired to remember at this point).
> Not sure if that's really script's fault.
> with jikes I compiled HelloWorld.java to .class and when I try to
> run it using sablevm, I am getting:
> 
> greg@greg:~$ sablevm -Y ./HelloWorld.class 
> java.lang.ClassNotFoundException: ./HelloWorld.class
> 	at gnu.java.lang.SystemClassLoader.findClass(SystemClassLoader.java:73)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:308)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:259)
> 	at java.lang.VirtualMachine.main(VirtualMachine.java:79)

Of course...  Try "sablevm -Y HelloWorld" (you have to give the class
name, not the file name).

> 
> I think I am doing sth. wrong. Could you please send me your
> HelloWorld.jar file (to private addr)?
> How should I run it using sablevm (not java wrapper)?
> If it runs with sablevm from debs and you can tell me how to run it -
> then fixing the wrapper should be trivial.

I'll send you the .jar, but remember that you have to type "sablevm -c
HelloWorld.jar HelloWorld".  I've seen that you try to extract the
Main class name in your wrapper; nice.

> > On the "running ant" side, I got Method.invoke() working.  Now it asks
> > for Class.getMethods() and Method.getArguments().  These are not
> > difficult to implement. per se (as SableVM already has all this
> > information in its internal data structures), But it is painfully long
> > to write, as you have to take care of array, class, and interface
> > types, as well as static, virtual and interface methods.  So this will
> > get done *after* my thesis, have I decided.  (Unless somebody else
> > wants to do it).
> When do you plan to finish them and get the time to fix this?
> (no pressure, just would like to know)

Would 3 weeks from now be acceptable to you?

> PS: Looking at all gnu-java related CVS trees - I am getting really worried,
> as it looks like there's no real development being made. Times 'since last
> update' are weeks at best - usually months and sometimes years. A lot of
> features has only it's stub files put into CVS with no further action.
> And where's awt/swing development? I hardly see any.
> 
> Can we really count on that GNU Classpath will be THE Classpath for
> free software java projects? What do you think?

I think that one of Classpath's current problems was that it lacked an
appropriate VM for doing development.  There's ORP, but this is a JIT,
and it has some problems, and locating problems in a JIT is much more
difficult.  In fact, you can easily trace SableVM's execution with a
debugger, add debugging traces on every exception thrown, (etc.) very
easily.  Also, SableVM has a solid implementation of JNI (with some
minor holes, easily fillable), which should help.

There is actually some development on the AWT (Swing?) side.  It could
be faster, but it's there.  You should look at the classpath cvs
commits ML.  You'll see things like
http://mail.gnu.org/pipermail/commit-classpath/2002-July/000916.html
which is pretty recent.

GNU Classpath is a little like Debian; it is not backed off by a
companyy, so you have to give it time.  Eventually, robust things come
out of it.

Etienne

-- 
Etienne M. Gagnon                    http://www.info.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/

Re: [Sablevm-developer] new debian packages of sablevm and friends

[Grzegorz P. <ga...@de...>]

W li=B6cie z pon, 12-08-2002, godz. 07:23, Etienne M. Gagnon pisze:=20
> On Mon, Aug 12, 2002 at 01:47:49AM +0200, Grzegorz Prokopski wrote:
> > I have added /usr/lib/sablevm/bin/java wrapper script - I have only
> The java wrapper didn't really work. I had to run update-alternatives
> by hand, and it linked to /usr/bin/sablevm instead of
> /usr/lib/sablevm/bin/java.
sablevm 1.0.1-3 is uploaded to debian.sente.pl - I fixed it there
I also added manual page java.sablevm.1.gz which is linke thru
alternatives to java.1.gz when you have sablevm 'java' wrapper choosen.

> Then I tried to run HelloWorld.jar but it failed, with something like
> classnotfound.  (I am too tired to remember at this point).
Not sure if that's really script's fault.
with jikes I compiled HelloWorld.java to .class and when I try to
run it using sablevm, I am getting:

greg@greg:~$ sablevm -Y ./HelloWorld.class=20
java.lang.ClassNotFoundException: ./HelloWorld.class
	at gnu.java.lang.SystemClassLoader.findClass(SystemClassLoader.java:73)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:308)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:259)
	at java.lang.VirtualMachine.main(VirtualMachine.java:79)

I think I am doing sth. wrong. Could you please send me your
HelloWorld.jar file (to private addr)?
How should I run it using sablevm (not java wrapper)?
If it runs with sablevm from debs and you can tell me how to run it -
then fixing the wrapper should be trivial.

> > I don't know how to run javadoc. The classes are in place but
> > which one is the starting one? I'd like to fix javadoc and add
> > it to alternatives. (try to run just /usr/lib/sablevm/bin/javadoc)
OK, I found cp-tools project http://savannah.gnu.org/projects/cp-tools/
I'll probably package some of these tools too, as they will give us
ability to have wrappers for:
javadoc, javah, javap, serialver

(com.sun.javadoc _really_ should be moved there, to gjdoc source tree,
as it seems to be kinda unusable in classpath alone)

However - those files (in cp-tools) were checked into cvs only once,
9 months ago and weren't touched since then. oh - if they work - then
no problem...

> On the "running ant" side, I got Method.invoke() working.  Now it asks
> for Class.getMethods() and Method.getArguments().  These are not
> difficult to implement. per se (as SableVM already has all this
> information in its internal data structures), But it is painfully long
> to write, as you have to take care of array, class, and interface
> types, as well as static, virtual and interface methods.  So this will
> get done *after* my thesis, have I decided.  (Unless somebody else
> wants to do it).
When do you plan to finish them and get the time to fix this?
(no pressure, just would like to know)

> Thanks for all your work.
And vice versa.

Best regards

						Grzegorz B. Prokopski

PS: Looking at all gnu-java related CVS trees - I am getting really worried=
,
as it looks like there's no real development being made. Times 'since last
update' are weeks at best - usually months and sometimes years. A lot of
features has only it's stub files put into CVS with no further action.
And where's awt/swing development? I hardly see any.

Can we really count on that GNU Classpath will be THE Classpath for
free software java projects? What do you think?

Re: [Sablevm-developer] new debian packages of sablevm and friends

[Etienne M. G. <eti...@uq...>]

On Mon, Aug 12, 2002 at 01:47:49AM +0200, Grzegorz Prokopski wrote:
> Hello!
> 
> So I divided the packages as we agreed. If you had them installed -
> you'll need to remove all *sablevm* packages before installing new
> ones. I have not provided easy upgrade path. Remove&install it the way.
> 
> I have added /usr/lib/sablevm/bin/java wrapper script - I have only
> done little testing. Seems to work. Please check if you can run any
> app using -jar parameter. _Should_ work. Please report problems
> and ideas of improvement (fixes are welcome also - of course).

I tested it very quickly.

The java wrapper didn't really work. I had to run update-alternatives
by hand, and it linked to /usr/bin/sablevm instead of
/usr/lib/sablevm/bin/java.

Then I tried to run HelloWorld.jar but it failed, with something like
classnotfound.  (I am too tired to remember at this point).

> I don't know how to run javadoc. The classes are in place but
> which one is the starting one? I'd like to fix javadoc and add
> it to alternatives. (try to run just /usr/lib/sablevm/bin/javadoc)
> 
> As a test - I tried to build ant - it has builded with exception
> of javadoc. But I belive it's that we're just one string away from
> solving this problem (initial method for javadoc)
>

On the "running ant" side, I got Method.invoke() working.  Now it asks
for Class.getMethods() and Method.getArguments().  These are not
difficult to implement. per se (as SableVM already has all this
information in its internal data structures), But it is painfully long
to write, as you have to take care of array, class, and interface
types, as well as static, virtual and interface methods.  So this will
get done *after* my thesis, have I decided.  (Unless somebody else
wants to do it).

> I think it's enough for today. It's 1.30AM already, so expect me to
> read and reply to your mail in about 8-9 hours from now.


It's 1:22AM here.  I'm going to bed too.

Thanks for all your work.

Etienne

-- 
Etienne M. Gagnon                    http://www.info.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/

[Sablevm-developer] new debian packages of sablevm and friends

[Grzegorz P. <ga...@de...>]

Hello!

So I divided the packages as we agreed. If you had them installed -
you'll need to remove all *sablevm* packages before installing new
ones. I have not provided easy upgrade path. Remove&install it the way.

I have added /usr/lib/sablevm/bin/java wrapper script - I have only
done little testing. Seems to work. Please check if you can run any
app using -jar parameter. _Should_ work. Please report problems
and ideas of improvement (fixes are welcome also - of course).

I don't know how to run javadoc. The classes are in place but
which one is the starting one? I'd like to fix javadoc and add
it to alternatives. (try to run just /usr/lib/sablevm/bin/javadoc)

As a test - I tried to build ant - it has builded with exception
of javadoc. But I belive it's that we're just one string away from
solving this problem (initial method for javadoc)

I think it's enough for today. It's 1.30AM already, so expect me to
read and reply to your mail in about 8-9 hours from now.

I'd like to upload the packages in few days, but would like to have:
a) tested java wrapper (-jar and other basic stuff working)
b) javadoc working (if it's possible with today's gnu classpath)
c) proven structure of the packages (so that I didn't need to add
    or remove resulting binary packages, change names etc.)

I am done for today.
Best regards

					Grzegorz B. Prokopski

PS: I am Cc:ing ant maintainer in the hope he's still interested
in having ant moved from contrib to main.

Stefan - you may want to take a look at all of our conversation here:
http://www.geocrawler.com/lists/3/SourceForge/4435/0/

A word about ant compilation - it _compiles_ w/o problems because
classlib contains _a lot_ of stub classes implementations. It causes
that ant detects that those classes are available and thus compiles
a lot of features. There's nothing really bad with it I belive, as
this would allow us to compile all(?) the features with free
compiler/jvm/classlib thus avoiding split of the package (hmm.. are we
really sure it is not really needed to move unusable but optional parts
to contrib?)
However there's some problem with "reflection" code (the same as with
a bit older kaffe) when running ant - Etienne offerred himself to fix
them for us later.

What do you think about all this stuff?

Re: [Sablevm-developer] Re: while building ant... and some other stuff

[Etienne M. G. <eti...@uq...>]

On Sun, Aug 11, 2002 at 10:23:08PM +0200, Grzegorz Prokopski wrote:
> BTW: Would it be possible to keep all the classpath as jar or .zip
> file? would it slow down things much? I know it's on the bottom of
> TODO file, but keeping all the classes uncompressed looks... strange.
> 
> Q: Is all the classpath treated as bootclasspath?

For the moment, yes, because anything that might be reached by, let
say, class initializers of bootstrap classes (Object, System, Thread,
etc.) has to also be in the bootstrap classpath.  It's amazing to see
the number of classes loaded to run a simple HelloWorld java program.
Try "sablevm -s HelloWorld"...

Supporting .jar on the boot classpath means being able to read .jar
files using C code.  The beauty of SableVM is that it avoids such
difficulties by using an application class loader written in Java,
that can thus use the java.util.jar classes to do this, but this means
it isn't available to bootstrap classes (some kind of chicken-engg
problems, as there are *many* when bootstrapping a VM).

This being said, nothing precludes tring to hack something in, at some
point, or even linking with some zip library, as long as it is license
compatible, and that it doesn't leak memory or resources (I'm quite
firm on these two points).  In fact, I'll either fix the memory leaks
in libpopt, or abandon it, eventually.  This leak is not that bad, as
libpopt is not linked to libsablevm.so, only to bin/sablevm, yet I
would like to get rid of it, eventually.

> We have time. ATM I mostly need your assistance and discussion/mails
> than any coding. We _do_ have time. Sarge won't release tomorrow ;-)

Good.

> PS: are you doing master's degree or PhD? or what?
> 'thesis' seems to be unclear - at least for me.

Ph.D.  In fact, I've taken some advance and I already am a University
"Assistant Professor" at UQAM. ;-)

> PSS: When we have some initial stuff moved into main - I'll make
> an announcement on debian-devel and debian-java that people should start
> trying sablevm and friends to compile their packages with free
> stuff only. Maybe in a month or two...

Then, we'll start receiving bunch of bug reports... Nice.  We'll just
have to sort through what goes to SableVM and what should be
redirected to Classpath.  (I'll help).  The nice thing is that I also
am a Classpath developer, having sent the copyright assignment paper
work, etc.  So, I'll be able to quickly fix small things upstream if
the need arises.

Etienne
-- 
Etienne M. Gagnon                    http://www.info.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/

Re: [Sablevm-developer] Re: while building ant... and some other stuff

[Grzegorz P. <ga...@de...>]

W li=B6cie z nie, 11-08-2002, godz. 21:29, Etienne M. Gagnon pisze:=20
> On Sun, Aug 11, 2002 at 09:04:49PM +0200, Grzegorz Prokopski wrote:
> > OK, I hope ant maintainer will join our conversation/efforts.
> > In case you didn't know why I started with ant - it is because _a lot_
> > of DFSG-free packages depend on it, and ant is still in contrib.
> > I belive this one with a few other packages from Apache (xml and more
> > general stuff) - once moved from contrib to main - can allow us to
> > move _a lot_ of Java programs to main.
> > Yes - that's another reason I am doing all of this...
> I see the need...  As long as you can be a little patient for the next
> couple of weeks, so that I terminate my Thesis, I will have more time
> to help filling the holes.
That's OK - I will surely not dissapear anywhere.

It will take a while to get for ex. ant into main but it's worth the
effort. However the first thing is to have good JVM with good classpath
that is available in debian. If we have this - we can start recompiling
stuff with jikes+sablevm+classpath and filling bugs (with patches)
on java packages that should be compiled with our "trio" and moved
to main.

Honestly - next big step forward would be swing implementation.
That would allow moving ArgoUML into main...
n/m - that's completly another story

> > It may be just oversight.
> Apparently not.  Look at the last messages of
> http://mail.gnu.org/pipermail/classpath/2002-August/thread.html
Hmm... yes but it doesn't do any harm - really. It can be as well GPL.
I already added a notoice to copyright file.
If it's moved away from classpath - I'll quickly repackage it for debian
and we'll depend on it - I think.

BTW: Would it be possible to keep all the classpath as jar or .zip
file? would it slow down things much? I know it's on the bottom of
TODO file, but keeping all the classes uncompressed looks... strange.

Q: Is all the classpath treated as bootclasspath?

> They might be moved to the gjdoc project.  Aren't we annoying to every
> other programmer out there, by checking licenses...  Poor them, having
> to deal with us.  But, it's for The Greater Good (TM). ;-)
Yes, we are. But too much people are not really interested in licenses
and stuff and then it takes sometime _a lot_ effort to get somenthing
that can be legally used. been there, done that. It hurts.
We need to know we feel the ground since the beginning.

> > BTW: do you know if classpathx project(s) are already packaged for
> > Debian?
> I think not...  You'll accumulate lots of Debian Karma, maintaining
> such numerous packages!  (Yep. I even noticed about the existence such
> things;-)
I think they _may_ be needed when we start recompiling stuff with
free tools only. I won't be packaging things just to have them
packaged.

> > I thought about other thing too. Machines of all 11 architectures of
> > Debian are available to debian developers. To port sablevm to new
> > architectures you could become debian developer. Just a thought.
> Let me finish my thesis, and I might well join!
We have time. ATM I mostly need your assistance and discussion/mails
than any coding. We _do_ have time. Sarge won't release tomorrow ;-)


Regards

						GBP
PS: are you doing master's degree or PhD? or what?
'thesis' seems to be unclear - at least for me.

PSS: When we have some initial stuff moved into main - I'll make
an announcement on debian-devel and debian-java that people should start
trying sablevm and friends to compile their packages with free
stuff only. Maybe in a month or two...

Re: [Sablevm-developer] Re: while building ant... and some other stuff

[Etienne M. G. <eti...@uq...>]

On Sun, Aug 11, 2002 at 09:04:49PM +0200, Grzegorz Prokopski wrote:
> Of course - why not ;-)
> You need to know I am good at it
> http://people.debian.org/~igenibel/packages.php?gpg_key=A4B8FDE9
> show that I managed to divide FireBird (InterBase derived&compat) into
> 13 pieces! ;-)

*g*

> OK, I hope ant maintainer will join our conversation/efforts.
> In case you didn't know why I started with ant - it is because _a lot_
> of DFSG-free packages depend on it, and ant is still in contrib.
> I belive this one with a few other packages from Apache (xml and more
> general stuff) - once moved from contrib to main - can allow us to
> move _a lot_ of Java programs to main.
> Yes - that's another reason I am doing all of this...

I see the need...  As long as you can be a little patient for the next
couple of weeks, so that I terminate my Thesis, I will have more time
to help filling the holes.
 
> It may be just oversight.

Apparently not.  Look at the last messages of
http://mail.gnu.org/pipermail/classpath/2002-August/thread.html

They might be moved to the gjdoc project.  Aren't we annoying to every
other programmer out there, by checking licenses...  Poor them, having
to deal with us.  But, it's for The Greater Good (TM). ;-)

> BTW: do you know if classpathx project(s) are already packaged for
> Debian?

I think not...  You'll accumulate lots of Debian Karma, maintaining
such numerous packages!  (Yep. I even noticed about the existence such
things;-)

> I thought about other thing too. Machines of all 11 architectures of
> Debian are available to debian developers. To port sablevm to new
> architectures you could become debian developer. Just a thought.

Let me finish my thesis, and I might well join!

Thanks,

Etienne

-- 
Etienne M. Gagnon                    http://www.info.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/

Re: [Sablevm-developer] Re: while building ant... and some other stuff

[Grzegorz P. <ga...@de...>]

W li=B6cie z nie, 11-08-2002, godz. 20:25, Etienne M. Gagnon pisze:=20
> On Sun, Aug 11, 2002 at 07:48:25PM +0200, Grzegorz Prokopski wrote:
> > Hmm... I was looking at manual page for kaffe's 'java' and sablevm
> > --help. Yes there are differencies. Don't you think it would be good
> > to have sablevm understanding standard 'java' options?
>=20
> On the principle, SableVM is not "TM" Java;-).  Also, I like sablevm
> to behave as a typical Debian GNU/Linux app.  Now, my plan was to
> effectively provide bassh scripts to emulate java; but I continue to
> see a "sablevm" binary executable in /usr/bin.  This would allow, for
> example, some people to select another vm as default through Debian's
> alternative magic, yet be able to use sablevm explicitly.  It would
> also allow some packages to depend directly on sablevm, instead of
> "java", if they wish so for some reason (e.g. eventual sablevm
> extentions).
I agree with everything above, but that doesn't really deny that
sablevm _could_ be itself compatible with 'java'!
Kaffe does it the same way - it has /usr/bin/kaffe and
/usr/lib/kaffe/bin/java script
/usr/lib/kaffe is kaffe's JAVA_HOME - oh - here it is (FYI):
greg:/# ls /usr/lib/kaffe/bin/
appletviewer jar javadoc javap kaffeh kopi rmic serialver install-jar
java javakey jdb kjc native2ascii rmiregistry

I took a look at the wrapper - it plays with _many_ env. variables,
but it does NOT touch commandline params - kaffe binary is able
to handle all standard 'java' params itself.
It would be a bit hard to analize '-classpath /some/dir/:/other/one.jar'
- wouldn't it? I'll think of it. I know shell - _maybe_ shift will
be sufficient? we'll see.

Anyway - if we want to have sablevm available to the users as java
using alternatives - we _need_ to provide 'java' compatible
command.

Oh... OK - EOT for now I think. I'll try to write something, but
first I need to cut the packages into pieces.

> Writing such a wrapper that would by default set the -Y option, among
> other things, would be fairly easy.
=3D)

> I insist to keep the default -Y behavior as it is now (in the sablevm
> executable).  It is a prerogative of the Copyright holder to self
> advertize.  It's my only payback for giving away the stuff; please be
> indulgent.
OK, you're right - I take it back.
However your name doesn't take 15 lines on the screen? ;-)

> > If not - I'll probably try to create some kind of shell wrapper.
> > Having (Sun's?) 'java' compatible command is very important for wide
> > acceptance.
> This should be fairly simple, as long as you are litterate in bash/sh.
> Don't forget to turn on the -Y option by default in the script for
> maximum compatibility.
We'll see into that.

> > OK, I changed it to have no $VERSION part for now, but it's probably no=
t
> > final solution here. I'll find a way so that I didn't need to manually
> > write new version number to the scripts every time I update the source.
> > Else it would be errorprone.
> As soon as I get more time, we could discuss this in depth, and I
> would go ahead and make the appropriate changes in the tar.gz
> distribution to simplify your life.
OK, ok, we'll suspend a bit now.
I have TODO:
0) read the archive
a) repackaging
b) java wrapper

> > I think that we'll have:
> >=20
> > from sablevm source:
> > * sablevm (/usr/bin/sablevm, JAVA_HOME and other helper stuff)
> > * libsablevm[012...] - with libs of sablevm=20
> > * libsablevm[012...]-dev - with *.h headers (I know they're small,
> > but else they also tend to conflict with other packages like libgcj)
> >=20
> > from sablevm-nativelib source:
> > * libsablevm-native[012...] - arch. dependant stuff extracted from
> >    classpath; we don't have any -dev here
> >=20
> > from sablevm-classpath source:
> > * libsablevm-classpath[012...]-java - according to java policy - java
> >    libs should have lib prefix and -java suffix=20
> Yep.  This is good (better than my above stuff; I should have read all of=
 your message first...).
;-) we're good at writing _a lot_ ;-) aren't we? ;-))

> > I must say there's NO JVM in Debian that has it's components divided
> > into different packages as above. usually it is like for ORP - two
> > packages: orp and orp-classpath
> > But that doesn't mean they're right with what they do!
> > I belive our way can be cleaner.
> Why not?  :-)
Of course - why not ;-)
You need to know I am good at it
http://people.debian.org/~igenibel/packages.php?gpg_key=3DA4B8FDE9
show that I managed to divide FireBird (InterBase derived&compat) into
13 pieces! ;-)

> The reflection stuff can be partly done in a platform independent way
> using JNI, but not all of it, and such an implementation would be even
> slower.  It has normally to be done in the VM itself.  I was planning
> to fix the whole thing once my thesis is written, but I can try to get
> enough of it working for basic ant operation (at least for a simple
> <javac/> task, of possible).
OK, I hope ant maintainer will join our conversation/efforts.
In case you didn't know why I started with ant - it is because _a lot_
of DFSG-free packages depend on it, and ant is still in contrib.
I belive this one with a few other packages from Apache (xml and more
general stuff) - once moved from contrib to main - can allow us to
move _a lot_ of Java programs to main.
Yes - that's another reason I am doing all of this...

> > Shouldn't -Y work otherwise? _enabling_ the copyright not disabling it?
> >  ;-) I'll think if not change it  when I have nothing else to do ;-))
> See my request for indulgence above, and the solution for the java
> script...
OK, ok - it's your right.

> > I think /usr/lib/sablevm with bin directory would be sufficient, OR
> > we could recomment using JAVA_HOME=3D/usr but providing java and javado=
c
> > wrappers that can be used by alternatives mechanism (yeah, I'd recommen=
d
> > that one).
> I am inclined towards the second solution too "JAVA_HOME=3D/usr".
will do, at least for now
JAVA_HOME is not absolutely _necessery_ but simplifies a lot of things.
BUT we have alternatives which do more-less the same!

> > So if we want to Provide: not only java-virtual-machine but also
> > java-runtime-environment - we need to be able to be called by
> > standard 'java' invocation.
> Do you think you can try writing one (and LGPL it)?
Sure. But any DFSG-compat license would do. It is only a wrapper, so
it is not linking to anything really.

> Probably the "java" wrapper would eventually have to convert $CLASSPATH i=
nto
> a --classpath argument (in absence of one, to mimic the behavior of
> the normal "java").
if sablevm doesn't use env. vars (which is the case it seems) - then Yes

> > PS: About javadoc - in that particular case - I don't see any problem
> > as we don't need to link javadoc classes with anything external. We jus=
t
> > USE javadoc 'program' to create some output. So _even_ if it stayed pur=
e
> > GPL forever - we don't really want to remove this stuff.
> > Maybe that the whole point and the authors knew it?
> I have already filed a bug report on Classpath.  If this is their
> intent, they should move the stuff to the classpathx (or something
> similar) GNU project.  The GNU Classpath web page is pretty eloquent
> about the GPL + exception.  They even explicitly display its whole
> text there.
It may be just oversight.
BTW: do you know if classpathx project(s) are already packaged for
Debian?

I thought about other thing too. Machines of all 11 architectures of
Debian are available to debian developers. To port sablevm to new
architectures you could become debian developer. Just a thought.

Regards

						GBP

Re: [Sablevm-developer] Re: while building ant... and some other stuff

[Etienne M. G. <eti...@uq...>]

On Sun, Aug 11, 2002 at 07:48:25PM +0200, Grzegorz Prokopski wrote:
> Hmm... I was looking at manual page for kaffe's 'java' and sablevm
> --help. Yes there are differencies. Don't you think it would be good
> to have sablevm understanding standard 'java' options?

On the principle, SableVM is not "TM" Java;-).  Also, I like sablevm
to behave as a typical Debian GNU/Linux app.  Now, my plan was to
effectively provide bassh scripts to emulate java; but I continue to
see a "sablevm" binary executable in /usr/bin.  This would allow, for
example, some people to select another vm as default through Debian's
alternative magic, yet be able to use sablevm explicitly.  It would
also allow some packages to depend directly on sablevm, instead of
"java", if they wish so for some reason (e.g. eventual sablevm
extentions).

Writing such a wrapper that would by default set the -Y option, among
other things, would be fairly easy.

I insist to keep the default -Y behavior as it is now (in the sablevm
executable).  It is a prerogative of the Copyright holder to self
advertize.  It's my only payback for giving away the stuff; please be
indulgent.

> If not - I'll probably try to create some kind of shell wrapper.
> Having (Sun's?) 'java' compatible command is very important for wide
> acceptance.

This should be fairly simple, as long as you are litterate in bash/sh.
Don't forget to turn on the -Y option by default in the script for
maximum compatibility.

> OK, I changed it to have no $VERSION part for now, but it's probably not
> final solution here. I'll find a way so that I didn't need to manually
> write new version number to the scripts every time I update the source.
> Else it would be errorprone.

As soon as I get more time, we could discuss this in depth, and I
would go ahead and make the appropriate changes in the tar.gz
distribution to simplify your life.

> > 4- You will have to document clearly the fact that different component
> > of the libsablevm Debian package are under distinct copyright/license
> > terms.
> I thought everything in sablevm source is LGPL?
> And 'the rest' - classlib and nativelib are GPL+exception?
> No?

.../lib/libsablevm.so is LGPLed, whereas lib/sablevm/lib*-VERSION.so are GPL + exception.


So, I see 4 packages:
- sablevm: sablevm, java* wrappers, etc.  [LGPL]
- libsablevm: /usr/lib/libsablevm.so [LGPL]
- sablevm-native-library: /usr/lib/sablevm/*.so [GPL+excp]
- sablevm-class-library: .../classes-VERSION/* [GPL+excp]

with the following dependencies:

sablevm: depends on libsablevm
libsablevm: depends on sablevm-native-library and sablevm-class-library

> I think that we'll have:
> 
> from sablevm source:
> * sablevm (/usr/bin/sablevm, JAVA_HOME and other helper stuff)
> * libsablevm[012...] - with libs of sablevm 
> * libsablevm[012...]-dev - with *.h headers (I know they're small,
> but else they also tend to conflict with other packages like libgcj)
> 
> from sablevm-nativelib source:
> * libsablevm-native[012...] - arch. dependant stuff extracted from
>    classpath; we don't have any -dev here
> 
> from sablevm-classpath source:
> * libsablevm-classpath[012...]-java - according to java policy - java
>    libs should have lib prefix and -java suffix

Yep.  This is good (better than my above stuff; I should have read all of your message first...).

> I must say there's NO JVM in Debian that has it's components divided
> into different packages as above. usually it is like for ORP - two
> packages: orp and orp-classpath
> But that doesn't mean they're right with what they do!
> I belive our way can be cleaner.

Why not?  :-)

> Right - when I was trying some pre 1.0.7 version (3 months old now) -
> I was getting some "reflecion" errors. Probably they had problems
> with it too. But now they have the reflecion code fixed.
> 
> FWIW: I talked with kaffe authors for long and Dalibor Topic
> <ro...@ya...> caimed he was digging into that code.
> We had a talk about licensing and he said he would happily relicense
> any piece of kaffe he owns copyright to under GPL+exception (outside
> of kaffe). I belive that it would be possible to ask him for
> relicensing it under LGPL.
> 
> I must admit don't really know what reflections are - if that
> thing closely related to particluar JVM - then it can be hard.
> But if that's a bit largish work and not very JVM specific -
> I could ask him what he would think about eventuall relicensing
> his reflecion code under LGPL.
> 
> Does it makes any sense?

The reflection stuff can be partly done in a platform independent way
using JNI, but not all of it, and such an implementation would be even
slower.  It has normally to be done in the VM itself.  I was planning
to fix the whole thing once my thesis is written, but I can try to get
enough of it working for basic ant operation (at least for a simple
<javac/> task, of possible).

> Shouldn't -Y work otherwise? _enabling_ the copyright not disabling it?
>  ;-) I'll think if not change it  when I have nothing else to do ;-))

See my request for indulgence above, and the solution for the java
script...

> I think we would need mainly:
> *java (wrapper to /usr/bin/sablevm that understands 'java' parameters
>   or symlink to /usr/bin/sablevm if sablevm could understand the
>   options directly - which would not be stupid)
> *jar - we could just symlink to /usr/bin/fastjar and depend on fastjar
>   or even better - symlink to /usr/bin/jar which is handled by
>   alternatives mechanism (recommends fastjar)
> *javac - just like above (recommends jikes)
> *javadoc - trivial wrapper script copied (rewrote with looking at) from
>   kaffe
>... 
> I think /usr/lib/sablevm with bin directory would be sufficient, OR
> we could recomment using JAVA_HOME=/usr but providing java and javadoc
> wrappers that can be used by alternatives mechanism (yeah, I'd recommend
> that one).

I am inclined towards the second solution too "JAVA_HOME=/usr".

> We NEED java wrapper if we want sablevm to be used more widely, because
> every java program uses just 'java' invocation (with parameters) to
> start. It would be stupid to expect any program that wants to work
> with sablevm to change it's wrapper script.
> 
> So if we want to Provide: not only java-virtual-machine but also
> java-runtime-environment - we need to be able to be called by
> standard 'java' invocation.

Do you think you can try writing one (and LGPL it)?

> > Instead of reading environment variables, SableVM supports traditional
> > configuration files.  So, you can create a ...etc/sablevm file and/or
> > a $HOME/.sablevm file, and write into it things like:
> > 
> > classpath=blah
> > no-copyright
> > verbose-gc
> I belive it was discussed (probably many times) at debian-java but I
> didn't find out (reading the archives) that consensus was made. For now
> program expect having working 'java' and that's all that matters.
> I belive I could quite easily just copy kaffe's 'java' wrapper and
> adopt it to sablevm needs (haven't checked it though).

Probably the "java" wrapper would eventually have to convert $CLASSPATH into
a --classpath argument (in absence of one, to mimic the behavior of
the normal "java").

> 
> PS: About javadoc - in that particular case - I don't see any problem
> as we don't need to link javadoc classes with anything external. We just
> USE javadoc 'program' to create some output. So _even_ if it stayed pure
> GPL forever - we don't really want to remove this stuff.
> Maybe that the whole point and the authors knew it?

I have already filed a bug report on Classpath.  If this is their
intent, they should move the stuff to the classpathx (or something
similar) GNU project.  The GNU Classpath web page is pretty eloquent
about the GPL + exception.  They even explicitly display its whole
text there.

Etienne
-- 
Etienne M. Gagnon                    http://www.info.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/

Re: [Sablevm-developer] while building ant... Success!

[Grzegorz P. <ga...@de...>]

W li=B6cie z nie, 11-08-2002, godz. 18:58, Etienne M. Gagnon pisze:=20
> Hi Grzegorz,
>=20
> A little bug already...
>=20
> $ sablevm -L
> sablevm: can't open "/usr/share/sablevm/AUTHORS"
I was doing rm -rf /usr/share/sablevm - but OK, I'll take it back
and remove AUTHORS from /usr/share/doc/sablevm (where they can
be compressed if the file is bigger than 2(or3?) kb.

> Also, doesn't the Debian policy mandate putting libsablevm.so into a
> seoarate package?  I remember reading about something similiar while
> browsing occasionally the debian-devel ml archive...
Yes and no. There's _a lot_ of packages that include libs along with
binaries. And there's noting wrong with it as long as either
1. nobody uses those libs externaly
or
2. if binary interface changes in incompatible way - package gets
new name, ex. foobar and then foobar2

I thought we'll have 1. here but if we can not (hopefully ;-) - I have
described now package scheme in previous mail. Would like to hear
your opinion about it of course.

Regards

					Grzegorz B. Prokopski

[Sablevm-developer] Re: while building ant... and some other stuff

[Grzegorz P. <ga...@de...>]

W li=B6cie z nie, 11-08-2002, godz. 17:55, Etienne M. Gagnon pisze:=20
> On Sun, Aug 11, 2002 at 02:17:40PM +0200, Grzegorz Prokopski wrote:
> > Hello!
> >=20
> > My first mail, sent to sablevm-developer list (after I subscribed)
> > still hasn't reached my mailbox. So I am Cc:ing Etienne.
> Usually, posting is restricted to official SableVM developers, by I
> have now added you to the white list.
Thanks.

> > It is very nice that /usr/bin/sablevm is designed to be replacement
> > of /usr/bin/java.
> I don't see what you mean...  java supports a different set of
> command-line options.  In particular, sablevm uses '--' for long
> options and '-' short options are one letter long.
Hmm... I was looking at manual page for kaffe's 'java' and sablevm
--help. Yes there are differencies. Don't you think it would be good
to have sablevm understanding standard 'java' options?

If not - I'll probably try to create some kind of shell wrapper.
Having (Sun's?) 'java' compatible command is very important for wide
acceptance.

> > It is also very nice that it doesn't need to be given classpath path
> > on the commandline,
> You mean a "bootstrap-classpath", which is a different beast from a
> "classpath".  Yes, this can get confusing, but it is so much nicer for
> users when both are managed separately!
Exactly.

> Now, SableVM supports a single path on its bootstrap-classpath.  It is
> a pain to do fancy things there, as it has to be coded in C, and
> eveyone knows that string manipulation (and related memory management)
> is tedions in C.
OK, I changed it to have no $VERSION part for now, but it's probably not
final solution here. I'll find a way so that I didn't need to manually
write new version number to the scripts every time I update the source.
Else it would be errorprone.

> Why is this important?  Because through the invocation interface,
> libsablevm.so could be used as a scripting engine (or embedded VM) by
> another application.  Imagine that the Mozilla project decided to
> eventually use SableVM.  They would not be interested in the
> /usr/bin/sablevm executable, but they would link with libsablevm.so.
> If I was to release a binary incompatible new libsablevm.so, it could
> break mozilla, but it won't because SableVM uses libtool versioning to
> avoid such problems.  But, libsablevm.so internally depends on a
> specific set of sablevm/java*.so files (dependencies which are NOT
> visible through ldd) and on classes-VERSION.  So, we must take care of
> this too.
I like you're looking so far into the future.

> Consequences of this for Debian:
> 1- You should probably break SableVM into 2 packages: sablevm and
> libsablevm.
Ah yes - I was about to ask about it. OK.

> 2- The sablevm package will be pretty small.  It should mainly include
> /usr/bin/sablevm.
Uhm... and probably some JAVA_HOME related stuff.

> 3- The libsablevm should include all of:
> /usr/lib/libsablevm.[so,la,...], the /usr/lib/sablevm directory
> content and all subdirectories.
Right

> 4- You will have to document clearly the fact that different component
> of the libsablevm Debian package are under distinct copyright/license
> terms.
I thought everything in sablevm source is LGPL?
And 'the rest' - classlib and nativelib are GPL+exception?
No?

> 5- Instead of 4, you could instead make a sablevm-library package, or
> even sablevm-class-library and sablevm-native-library packages, as I
> have done, and add a dependency of libsablevm on them.  Just make sure
I have done it like this. 3 packages. It makes sense, because nativelib
must be compiled separeately for every architecture (just like sablevm)
while -classlib is arch-indep.

> that distinct versions could eventually be installed on the same
> system, in case some other application decides to link directly
> against libsablevm.so. (Maybe libsablevm-class/native-library is a
> more appropriate name for Debian? I'm not sure; I haven't read all of
> the Debian policy manual yet...;-)
I think that we'll have:

from sablevm source:
* sablevm (/usr/bin/sablevm, JAVA_HOME and other helper stuff)
* libsablevm[012...] - with libs of sablevm=20
* libsablevm[012...]-dev - with *.h headers (I know they're small,
but else they also tend to conflict with other packages like libgcj)

from sablevm-nativelib source:
* libsablevm-native[012...] - arch. dependant stuff extracted from
   classpath; we don't have any -dev here

from sablevm-classpath source:
* libsablevm-classpath[012...]-java - according to java policy - java
   libs should have lib prefix and -java suffix

I must say there's NO JVM in Debian that has it's components divided
into different packages as above. usually it is like for ORP - two
packages: orp and orp-classpath
But that doesn't mean they're right with what they do!
I belive our way can be cleaner.

For normal user apt-get install sablevm will be sufficient anyway.

> > java/lang/UnsatisfiedLinkError
> > ... Failed Building Ant Distribution !
> I have looked at Ant.  It seems to require some reflection primitives
> that are not all yet implemented.  Using the precompiled ant.jar on
> unstable with the CVS version of SableVM (which has a little less
> holes in reflection support than 1.0.1), I get:
Right - when I was trying some pre 1.0.7 version (3 months old now) -
I was getting some "reflecion" errors. Probably they had problems
with it too. But now they have the reflecion code fixed.

FWIW: I talked with kaffe authors for long and Dalibor Topic
<ro...@ya...> caimed he was digging into that code.
We had a talk about licensing and he said he would happily relicense
any piece of kaffe he owns copyright to under GPL+exception (outside
of kaffe). I belive that it would be possible to ask him for
relicensing it under LGPL.

I must admit don't really know what reflections are - if that
thing closely related to particluar JVM - then it can be hard.
But if that's a bit largish work and not very JVM specific -
I could ask him what he would think about eventuall relicensing
his reflecion code under LGPL.

Does it makes any sense?

> Method.invokeNative (which should show as Method.invoke in your
> version) is a little painful to code.  The equivalent
> java.lang.reflect.Construction.newInstance() is already implemented,
> but Method.invoke has this painful return value wrapping to do... Let
> me see what I can do.
OK

> Rant: Why does it require all this reflection stuff?  Reflection is
> inherently slow in Java!  Programmers shouldn't be messing with it,
> unless it is absolutely critical.
*g*

> > It works with kaffe and blackdown 1.3 java.
> > Any hints are welcome. On my side - I was told that the latest jikes,
> > which is currently in unstable (I use unstable, so I used this version
> > of compiler too) - has some serious problems. I'll try to recompile
> > sablevm-classpath with previous version and if that changes anything
> It is also written in SableVM's README file.  Please read it again!
> Unstable's Jikes-1.16 is broken.  Jikes official repository contains
> some patches that haven't made it to Debian yet, but if I was you, I
> would stick to testing's 1.15.  You could discuss the problem with
> Jikes' maintainer, but first, read his opinion in bug
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D148169&repeatmerged=3D=
yes
I already reverted as I said in my previous mail.

> > PSS: Is this really needed to show all that long information about
> > SableVM and all stuff about it when the only important part is
> > one-liner message about error?
> > IMVHO a kind of 2-4 liner information would be more in place here.
> Maybe you should try "sablevm --help" and learn about the "-Y" option.
Shouldn't -Y work otherwise? _enabling_ the copyright not disabling it?
 ;-) I'll think if not change it  when I have nothing else to do ;-))

> > PST: It would be nice to have a kind of JAVA_HOME environment.
> > Is there some documentation about what should be there?
> > (I can _look_ at what kaffe/blackdown put there of course) -
> > what do you think of JAVA_HOME? How should it be set for SableVM?
> How does that JAVA_HOME work?  I sincerely don't know.
<disclaimer>
I don't claim I know Java. I started packaging java programs _because_
I didn't to it before (I know Java theorethically ;-)
However I can speak from my (not so wide and not surerly right)
expirience.
</disclaimer>
I am looking at /usr/lib/j2sdk1.3 from blackdown java now.

It seems that it's kind of real home for java engine (you didn't expect
it - did you ;-). It seem the most normalized dirs there are:
include - *.h files (jawt.h, jni.h, jvmdi.h, jvmpi.h) - unimportant for
           us IMO
lib - contains all the jars that sdk carries - not really important IMHO
bin - that's the main point

in bin there is a lot of different wrappers - about 25!
I don't even know what most of them do (would need to take look at
manuals, but that's unimportant now).

I think we would need mainly:
*java (wrapper to /usr/bin/sablevm that understands 'java' parameters
  or symlink to /usr/bin/sablevm if sablevm could understand the
  options directly - which would not be stupid)
*jar - we could just symlink to /usr/bin/fastjar and depend on fastjar
  or even better - symlink to /usr/bin/jar which is handled by
  alternatives mechanism (recommends fastjar)
*javac - just like above (recommends jikes)
*javadoc - trivial wrapper script copied (rewrote with looking at) from
  kaffe

> Also, SableVM is structured as a typical *NIX application, unlike the
> jdk.  So, libsablevm.so goes into /usr/lib, some files go in
> /usr/share/sablevm, etc.  So, where would that JAVA_HOME point?  I
> have no intention whatsoever to make sablevm read any environment
> variable; this is a painful mess for users, specially if you install
> more than one sablevm version on your system.  Think of those who use
> the build-many script, and get 6 distinct versions.  What would the
> appropriate JAVA_HOME be?
I think /usr/lib/sablevm with bin directory would be sufficient, OR
we could recomment using JAVA_HOME=3D/usr but providing java and javadoc
wrappers that can be used by alternatives mechanism (yeah, I'd recommend
that one).

We NEED java wrapper if we want sablevm to be used more widely, because
every java program uses just 'java' invocation (with parameters) to
start. It would be stupid to expect any program that wants to work
with sablevm to change it's wrapper script.

So if we want to Provide: not only java-virtual-machine but also
java-runtime-environment - we need to be able to be called by
standard 'java' invocation.

> Instead of reading environment variables, SableVM supports traditional
> configuration files.  So, you can create a ...etc/sablevm file and/or
> a $HOME/.sablevm file, and write into it things like:
>=20
> classpath=3Dblah
> no-copyright
> verbose-gc
I belive it was discussed (probably many times) at debian-java but I
didn't find out (reading the archives) that consensus was made. For now
program expect having working 'java' and that's all that matters.
I belive I could quite easily just copy kaffe's 'java' wrapper and
adopt it to sablevm needs (haven't checked it though).

Regards

					Grzegorz B. Prokopski

PS: About javadoc - in that particular case - I don't see any problem
as we don't need to link javadoc classes with anything external. We just
USE javadoc 'program' to create some output. So _even_ if it stayed pure
GPL forever - we don't really want to remove this stuff.
Maybe that the whole point and the authors knew it?

Re: [Sablevm-developer] trying SableVM in Debian

[Etienne M. G. <eti...@uq...>]

On Sun, Aug 11, 2002 at 11:48:30AM +0200, Grzegorz Prokopski wrote:
> W li?cie z nie, 11-08-2002, godz. 02:43, Etienne M. Gagnon pisze: 
> > Etienne M. Gagnon wrote:
> > > On the benchmark side, I have yet to see Kaffe run all of the SPECjvm98 
> > > benchmarks, SableCC and Soot.
> > 
> > To be honest, my current experiments show that the latest verions of Kaffe has 
> > been fixed to run all of SPECjvm98.  I'm still trying to get SableCC and Soot to 
> > run on it, though.
> Yes, kaffe 1.0.7 is MAJOR step forward.
> The number change 1.0.6->1.0.7 doesn't show how much effort was put
> into it since previous release.
> 
> Oh - and it is being ported to all Debian architectures (just released
> Woody has 11 of them).
> 
> While we're at it - what's the status of ports of SableVM?
> >From what I could read using that ugly SF archive - it works on i386
> and Alpha. Any others? Are there plans/people working on new ones?

I have personally only built it on x86.  The code of SableVM (I can't
speak for Classpath) has been desinged to work, with minimal changes
in 3 files, to any POSIX platform very easily. The only caveat: On
multi-processors, SableVM assumes a strong memory model (i.e. cache
coherency).  Weak memory models are not supported, but this shouldn't
be a big limitation, as currently, the JVM specification is broken in
this regard.

I will let users take care of porting to different architectures, as I
do not have the machines to test other architectures.  In the fall, I
will have Sun machines, so I'll port it there at that point.

Etienne


-- 
Etienne M. Gagnon                    http://www.info.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/

Re: [Sablevm-developer] while building ant... Success!

[Etienne M. G. <eti...@uq...>]

Hi Grzegorz,

A little bug already...

$ sablevm -L
sablevm: can't open "/usr/share/sablevm/AUTHORS"

Also, doesn't the Debian policy mandate putting libsablevm.so into a
seoarate package?  I remember reading about something similiar while
browsing occasionally the debian-devel ml archive...

Etienne

On Sun, Aug 11, 2002 at 06:13:47PM +0200, Grzegorz Prokopski wrote:
> W li?cie z nie, 11-08-2002, godz. 17:28, Grzegorz Prokopski pisze: 
> > W li?cie z nie, 11-08-2002, godz. 14:17, Grzegorz Prokopski pisze: 
> > > So as I said before - I tried to compile ant. the critical part, that
> > > gives me problems is this:
> > The new version of jikes I belive - really was causing trobules.
> > I reverted to older version, recompiled all sablevm-classpath stuff
> > (and cleaned/polished the packages - they're almost ready)
> 
> So I played a bit with it, cleaned up the packages a little bit more,
> and... it worked!
> 
> I got ant compiled and ant.jar got created.
> 
> Now I got to the stage where 'javadoc' program is being used...
> (it didn't worked as you could expect) hmm...
> I belive we have com.sun.javadoc in classpath - should we have
> some kind of a wrapper in sablevm package?
> 
> It seems that kaffe for ex. has 'javadoc' wrapper. It's this:
> #! /bin/sh
> # Script to run Sun's documenter
> prefix=/usr
> exec_prefix=${prefix}
> exec ${exec_prefix}/bin/kaffe sun.tools.javadoc.Main ${1+"$@"}
> 
> So the packages are working, now I'll be looking forward for ideas
> on how to improve them. Currently I mostly think of how to provide
> JAVA_HOME environment (I think in /usr/lib/sablevm/), with any needed
> wrappers etc. in it. Any thoughts are welcomed.
> 
> The packages are available at http://debian.sente.pl/debian
> /etc/apt/sources.lists line is this:
> deb http://debian.sente.pl ./
> 
> apt-get update; apt-get install sablevm
> should do the the trick
> 
> Best regards
> 
> 					Grzegorz B. Prokopski
> 
> PS: I am Cc:ing ant maintainer.
> 



-- 
Etienne M. Gagnon                    http://www.info.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/

Re: [Sablevm-developer] while building ant... Success!

[Etienne M. G. <eti...@uq...>]

On Sun, Aug 11, 2002 at 06:13:47PM +0200, Grzegorz Prokopski wrote:
> So I played a bit with it, cleaned up the packages a little bit more,
> and... it worked!

Wow!

> I got ant compiled and ant.jar got created.

Amazing.

> Now I got to the stage where 'javadoc' program is being used...
> (it didn't worked as you could expect) hmm...
> I belive we have com.sun.javadoc in classpath - should we have
> some kind of a wrapper in sablevm package?

Isn't this the bit which is missing the "legal" linking exception?  I
was planning to remove that stuf...

> It seems that kaffe for ex. has 'javadoc' wrapper. It's this:
> #! /bin/sh
> # Script to run Sun's documenter
> prefix=/usr
> exec_prefix=${prefix}
> exec ${exec_prefix}/bin/kaffe sun.tools.javadoc.Main ${1+"$@"}

Yes, we could make some utility scripts.  As long as they are LGPL'ed,
I could include them in sablevm-x.y.z.tar.gz.

> So the packages are working, now I'll be looking forward for ideas
> on how to improve them. Currently I mostly think of how to provide
> JAVA_HOME environment (I think in /usr/lib/sablevm/), with any needed
> wrappers etc. in it. Any thoughts are welcomed.

Can you explain to me how this JAVA_HOME works?  What is it useful for?

> The packages are available at http://debian.sente.pl/debian
> /etc/apt/sources.lists line is this:
> deb http://debian.sente.pl ./

Great!!!

> apt-get update; apt-get install sablevm
> should do the the trick

I'm just trying it now.

> 
> Best regards

Thanks a lot!

Etienne

PS: As I said before, actually running ant can get you into trouble,
because of some reflection holes.  I'll try to fix the Method.invoke
one, and I'll keep you informed as soon as it is done.

-- 
Etienne M. Gagnon                    http://www.info.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/

Re: [Sablevm-developer] while building ant... Success!

[Grzegorz P. <ga...@de...>]

W li=B6cie z nie, 11-08-2002, godz. 17:28, Grzegorz Prokopski pisze:=20
> W li=B6cie z nie, 11-08-2002, godz. 14:17, Grzegorz Prokopski pisze:=20
> > So as I said before - I tried to compile ant. the critical part, that
> > gives me problems is this:
> The new version of jikes I belive - really was causing trobules.
> I reverted to older version, recompiled all sablevm-classpath stuff
> (and cleaned/polished the packages - they're almost ready)

So I played a bit with it, cleaned up the packages a little bit more,
and... it worked!

I got ant compiled and ant.jar got created.

Now I got to the stage where 'javadoc' program is being used...
(it didn't worked as you could expect) hmm...
I belive we have com.sun.javadoc in classpath - should we have
some kind of a wrapper in sablevm package?

It seems that kaffe for ex. has 'javadoc' wrapper. It's this:
#! /bin/sh
# Script to run Sun's documenter
prefix=3D/usr
exec_prefix=3D${prefix}
exec ${exec_prefix}/bin/kaffe sun.tools.javadoc.Main ${1+"$@"}

So the packages are working, now I'll be looking forward for ideas
on how to improve them. Currently I mostly think of how to provide
JAVA_HOME environment (I think in /usr/lib/sablevm/), with any needed
wrappers etc. in it. Any thoughts are welcomed.

The packages are available at http://debian.sente.pl/debian
/etc/apt/sources.lists line is this:
deb http://debian.sente.pl ./

apt-get update; apt-get install sablevm
should do the the trick

Best regards

					Grzegorz B. Prokopski

PS: I am Cc:ing ant maintainer.

[Sablevm-developer] Re: while building ant... and some other stuff

[Etienne M. G. <eti...@uq...>]

On Sun, Aug 11, 2002 at 02:17:40PM +0200, Grzegorz Prokopski wrote:
> Hello!
> 
> My first mail, sent to sablevm-developer list (after I subscribed)
> still hasn't reached my mailbox. So I am Cc:ing Etienne.

Usually, posting is restricted to official SableVM developers, by I
have now added you to the white list.

> So I have got early packages, they're:
> sablevm
> sablevm-nativelib
> sablevm-classlib
> 
> It is very nice that /usr/bin/sablevm is designed to be replacement
> of /usr/bin/java.

I don't see what you mean...  java supports a different set of
command-line options.  In particular, sablevm uses '--' for long
options and '-' short options are one letter long.

> It is also very nice that it doesn't need to be given classpath path
> on the commandline,

You mean a "bootstrap-classpath", which is a different beast from a
"classpath".  Yes, this can get confusing, but it is so much nicer for
users when both are managed separately!

> however I'd like it to search not only for
> /usr/lib/sablevm/classes-$VERSION, but at least for
> /usr/lib/sablevm/classes if the above is not found.
> (it will be a symlink to /usr/share/sablevm/classes anyway, but that's
> another story)

Hmmm... I have explicitely make it look into
/usr/lib/sablevm/classes-$VERSION so that you could install 2 distinct
versions of libsablevm.so on the same system.  The .so numbering avoid
name clashes for both libsablevm and sablevm/libjava-*-VERSION.so, but
it won't work with /usr/lib/sablevm/classes.

Now, SableVM supports a single path on its bootstrap-classpath.  It is
a pain to do fancy things there, as it has to be coded in C, and
eveyone knows that string manipulation (and related memory management)
is tedions in C.

Why is this important?  Because through the invocation interface,
libsablevm.so could be used as a scripting engine (or embedded VM) by
another application.  Imagine that the Mozilla project decided to
eventually use SableVM.  They would not be interested in the
/usr/bin/sablevm executable, but they would link with libsablevm.so.
If I was to release a binary incompatible new libsablevm.so, it could
break mozilla, but it won't because SableVM uses libtool versioning to
avoid such problems.  But, libsablevm.so internally depends on a
specific set of sablevm/java*.so files (dependencies which are NOT
visible through ldd) and on classes-VERSION.  So, we must take care of
this too.

Consequences of this for Debian:

1- You should probably break SableVM into 2 packages: sablevm and
libsablevm.

2- The sablevm package will be pretty small.  It should mainly include
/usr/bin/sablevm.

3- The libsablevm should include all of:
/usr/lib/libsablevm.[so,la,...], the /usr/lib/sablevm directory
content and all subdirectories.

4- You will have to document clearly the fact that different component
of the libsablevm Debian package are under distinct copyright/license
terms.

5- Instead of 4, you could instead make a sablevm-library package, or
even sablevm-class-library and sablevm-native-library packages, as I
have done, and add a dependency of libsablevm on them.  Just make sure
that distinct versions could eventually be installed on the same
system, in case some other application decides to link directly
against libsablevm.so. (Maybe libsablevm-class/native-library is a
more appropriate name for Debian? I'm not sure; I haven't read all of
the Debian policy manual yet...;-)

> 
> So as I said before - I tried to compile ant. the critical part, that
> gives me problems is this:
> 
> /bin/sh bootstrap.sh
> ... Bootstrapping Ant Distribution
> ... Compiling Ant Classes
> ... Copying Required Files
> ... Building Ant Distribution
> /usr/bin/java -classpath
> build/classes:src/main::/usr/share/java/antlr.jar:/usr/share/java/bsf.jar:
> /usr/share/java/junit.jar:/usr/share/java/log4j.jar:/usr/share/java/oro.jar:
> /usr/share/java/regexp.jar:/usr/share/java/xalan2.jar:
> /usr/share/java/xercesImpl.jar:/usr/share/java/xml-apis.jar:
> /usr/lib/sablevm/classes:/usr/lib/tools.jar -Dant.home=.
> org.apache.tools.ant.Main -emacs jars javadocs
> 
> SableVM version 1.0.1
> Copyright (C) 2000-2002 Etienne M. Gagnon <eti...@uq...> and
> others.  All rights reserved.
> 
> This software comes with ABSOLUTELY NO WARRANTY.  This is free
> software, and you are welcome to redistribute it under certain
> conditions.
> 
> To get the name of all copyright holders and detailed license
> information, type "sablevm --license" or look in the directory
> "/usr/share/sablevm".
> 
> The SableVM web site is located at http://www.sablevm.org/ .
> 
> java/lang/UnsatisfiedLinkError
> ... Failed Building Ant Distribution !

I have looked at Ant.  It seems to require some reflection primitives
that are not all yet implemented.  Using the precompiled ant.jar on
unstable with the CVS version of SableVM (which has a little less
holes in reflection support than 1.0.1), I get:

$sablevm -Yc /usr/share/java/ant.jar org.apache.tools.ant.Main
Buildfile: build.xml
*** Couldn't bind native method Java_java_lang_reflect_Method_invokeNative ***
*** or Java_java_lang_reflect_Method_invokeNative___3B_3C_3Ljava_lang_Object_2 ***
*** Couldn't bind native method Java_java_lang_Class_isInstance ***
*** or Java_java_lang_Class_isInstance__Ljava_lang_Object_2 ***
java.lang.UnsatisfiedLinkError
        at java.lang.Class.isInstance(Class.java)
        at java.text.MessageFormat.format(MessageFormat.java:357)
        at java.text.MessageFormat.format(MessageFormat.java:379)
        at java.text.MessageFormat.format(MessageFormat.java:401)
        at java.text.Format.format(Format.java:82)
        at org.apache.tools.ant.util.DateUtils.formatElapsedTime(DateUtils.java:165)
        at org.apache.tools.ant.DefaultLogger.formatTime(DefaultLogger.java:308)
        at org.apache.tools.ant.DefaultLogger.buildFinished(DefaultLogger.java:192)
        at org.apache.tools.ant.Project.fireBuildFinished(Project.java:1871)
        at org.apache.tools.ant.Main.runBuild(Main.java:629)
        at org.apache.tools.ant.Main.start(Main.java:196)
        at org.apache.tools.ant.Main.main(Main.java:235)
        at java.lang.VirtualMachine.invokeMain(VirtualMachine.java)
        at java.lang.VirtualMachine.main(VirtualMachine.java:88)

Method.invokeNative (which should show as Method.invoke in your
version) is a little painful to code.  The equivalent
java.lang.reflect.Construction.newInstance() is already implemented,
but Method.invoke has this painful return value wrapping to do... Let
me see what I can do.

Rant: Why does it require all this reflection stuff?  Reflection is
inherently slow in Java!  Programmers shouldn't be messing with it,
unless it is absolutely critical.

> It works with kaffe and blackdown 1.3 java.
> Any hints are welcome. On my side - I was told that the latest jikes,
> which is currently in unstable (I use unstable, so I used this version
> of compiler too) - has some serious problems. I'll try to recompile
> sablevm-classpath with previous version and if that changes anything

It is also written in SableVM's README file.  Please read it again!
Unstable's Jikes-1.16 is broken.  Jikes official repository contains
some patches that haven't made it to Debian yet, but if I was you, I
would stick to testing's 1.15.  You could discuss the problem with
Jikes' maintainer, but first, read his opinion in bug
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=148169&repeatmerged=yes
.

> PSS: Is this really needed to show all that long information about
> SableVM and all stuff about it when the only important part is
> one-liner message about error?
> IMVHO a kind of 2-4 liner information would be more in place here.

Maybe you should try "sablevm --help" and learn about the "-Y" option.

> PST: It would be nice to have a kind of JAVA_HOME environment.
> Is there some documentation about what should be there?
> (I can _look_ at what kaffe/blackdown put there of course) -
> what do you think of JAVA_HOME? How should it be set for SableVM?

How does that JAVA_HOME work?  I sincerely don't know.

Also, SableVM is structured as a typical *NIX application, unlike the
jdk.  So, libsablevm.so goes into /usr/lib, some files go in
/usr/share/sablevm, etc.  So, where would that JAVA_HOME point?  I
have no intention whatsoever to make sablevm read any environment
variable; this is a painful mess for users, specially if you install
more than one sablevm version on your system.  Think of those who use
the build-many script, and get 6 distinct versions.  What would the
appropriate JAVA_HOME be?

Instead of reading environment variables, SableVM supports traditional
configuration files.  So, you can create a ...etc/sablevm file and/or
a $HOME/.sablevm file, and write into it things like:

classpath=blah
no-copyright
verbose-gc



Etienne

-- 
Etienne M. Gagnon                    http://www.info.uqam.ca/~egagnon/
SableVM:                                       http://www.sablevm.org/
SableCC:                                       http://www.sablecc.org/