sablevm-developer — SableVM developer mailing list

Re: [Sablevm-developer] Obsoleting sablevm-classpath NOW!

[Steven A. <au...@wa...>]

Etienne:  Jikes RVM uses a stock classpath build.  All it does is copy 
Classpath's glibj.zip and the .so files over to its own local storage 
place.

We get away with this because we put our own classes earlier in the 
path than Classpath's.  So we always get our own implementation of 
VMRuntime, for instance, and never see Classpath's.  Ditto for all of 
the other VM* classes, I believe.

I'm not sure what improved level of working out-of-the-box you would 
want beyond that.  Perhaps I have misunderstood what you're suggesting?

--Steve Augart


Etienne Gagnon wrote:
> I definitely think that Classpath should work *out-of-the-box* with all
> normal[0] VMs; something like:
[...]
> This would work best with:
> 0- All VM-specific code moved to VM*.java classes.
> 1- VM*.java classes residing in the *normal* Classpath tree.
> 2- Using m4 to maintain real VM-specific code. [Many VM's
>    will probably share "native" method declarations, for example].
> 3- The /vm subtree could be either eliminated, or kept around for
>    unusual[1] VM's.
> 
> 
> [0] I mean VM's with a usual build process, such as kaffe, sablevm, etc.
> [1] I mean VM's with unusual build process, such as JikesRVM, etc.

-- 
Steven Augart

Jikes RVM, open source Research Virtual Machine:
http://oss.software.ibm.com/jikesrvm

Office: +1 914/784-6743
T.J. Watson Research Center, IBM

Re: [Sablevm-developer] SA_SIGINFO undefined

[Etienne G. <gag...@uq...>]

Hi Julio,

You've made the Hall of Fame.  Your name is in SableVM's AUTHORS file
(staging branch), along with your 3 patches applied.

Thanks a lot!

Etienne

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

[Sablevm-developer] SA_SIGINFO undefined

[Julio M. M. V. <jm...@me...>]

Hi again,

the last problem I found while building sablevm under NetBSD is that it didn't
find SA_SIGINFO defined.  Checked the sources, and <signal.h> is included
correctly, so the problem is coming from somewhere else.

Digging a bit in configure, I found that it defines _POSIX_C_SOURCE.  The
problem is that defining this disables SA_SIGINFO, because siginfo is not
POSIX compliant.  According to the siginfo(2) manpage:

STANDARDS
     The siginfo_t type conforms to X/Open System Interfaces and Headers
     Issue 5 (``XSH5'').

Removing that definition lets the code work (because, SA_SIGINFO is defined
if no _* macros are explicitly defined), but I don't think this is the
solution you want.

Instead, and according to the standards text I posted before, defining
_XOPEN_SOURCE to 500 lets it work fine.  This seems better, and is easy
to fix:

--- configure.ac.orig	2004-03-20 23:02:08.000000000 +0100
+++ configure.ac
@@ -21,6 +21,7 @@ AC_DEFINE_UNQUOTED(_SABLEVM_PACKAGE_VERS
 
 AC_DEFINE(_REENTRANT,1,link with reentrant library functions)
 AC_DEFINE(_POSIX_C_SOURCE,199506L,link with POSIX library functions)
+AC_DEFINE(_XOPEN_SOURCE,500,link with XOpen library functions)
 
 dnl *** uncomment if you want to insert a magic value in every object instance for debugging ***
 dnl AC_DEFINE(MAGIC,1,put "SableVM" in every instance)

Cheers

-- 
Julio M. Merino Vidal <jm...@me...>
The NetBSD Project - http://www.NetBSD.org/

Re: [Sablevm-developer] Uninitialized pthread condition causes a crash

[Chris P. <chr...@ma...>]

Hi Julio,

I was noticing intermittent problems with thread startup, but IIRC they 
only actually occurred on multiprocessors.  However, improving 
multiprocessor support in SableVM is important to us (me in particular).

I have some other patches in my tree that insert StoreLoad barriers in 
the right places, as per the JSR-133 Cookbook, but I can't conveniently 
test your patch against them nor the latest staging + classpath just yet 
(note to others: including #ifdef'd types in global_alloc.list is a 
pain), although I'm guessing it will help.  Thanks a lot!  I spent quite 
a while looking at this problem before giving up.

Note that even for something so small, Etienne will probably need to 
confirm contribution conditions with you, but I'll let him do that.

Cheers,
Chris

P.S.  If anyone has access to NetBSD on a multiprocessor, and I might be 
able to get some time at some point (not immediately, just sometime) to 
test threading code of my own (Julio: I'm working on speculative 
multithreading support), I'd be happy to hear about it.

Julio M. Merino Vidal wrote:
> Hi all,
> 
> I have just built and installed sablevm under NetBSD.  The build goes fine,
> (aside two minor problems I'll describe in another mail when I find the right
> solution), but when running threaded applications, it crashes.
> 
> The native libpthread library in NetBSD is full of assertions to capture
> problems like uses of uninitialized mutexes or conditions.  And this is
> what's happening.  The vm->threads.vm_destruction_cond condition is never
> initialized, so when a wait happens, the vm crashes.
> 
> I've patched the code to initialize the condition in the invoke_interface.c
> file, JNI_CreateJavaVM function.  I'm not sure if this is right (but is where
> I found other initializations).  AFAICT, it's working now (no crash, and a
> consumer/producer test program works fine).  The patch is this:
> 
> --- src/libsablevm/invoke_interface.c.orig	2004-03-20 23:02:04.000000000 +0100
> +++ src/libsablevm/invoke_interface.c
> @@ -220,6 +220,7 @@ JNI_CreateJavaVM (JavaVM **pvm, void **p
>      }
>  
>    _svmf_set_current_env (env);
> +  _svmm_cond_init (vm->threads.vm_destruction_cond);
>    vm->threads.user = env;
>    vm->threads.next_thread_id = 1;	/* thread IDs must start at 1
>  					   (i.e. no ID == 0) */
> 
> 
> Kind regards
> 

[Sablevm-developer] Incorrect order of m4 arguments causes build failure

[Julio M. M. V. <jm...@me...>]

Hi again ;)

the main Makefile.am in sablevm uses m4 to generate the the java-sablevm
script, using the following command:

	m4 -P java-sablevm.m4.sh -DSABLEVM_BINARY=@bindir@/sablevm >java-sablevm

As you see, the source file name appears between two options.  This doesn't
work with NetBSD's m4, as it expects all flags to appear before arguments
(that is, it uses the native getopt(3), which is POSIX compliant).

This is working in many other systems because they use (probably) GNU m4,
and thus use GNU getopt, which recognizes flags in any position (the
POSIX behavior can be requested by setting POSIXLY_CORRECT=yes in the
environment when running GNU m4, so you should be able to reproduce this).

The solution is trivial: just move the source file after the -D flag.  The
patch below lets it work under NetBSD, fixing a build problem:

--- Makefile.am.orig	2004-03-20 23:02:08.000000000 +0100
+++ Makefile.am
@@ -21,7 +21,7 @@ BUILT_SOURCES = java-sablevm
 
 java-sablevm: java-sablevm.m4.sh
 	rm -f java-sablevm
-	m4 -P java-sablevm.m4.sh -DSABLEVM_BINARY=@bindir@/sablevm >java-sablevm
+	m4 -P -DSABLEVM_BINARY=@bindir@/sablevm java-sablevm.m4.sh >java-sablevm
 	chmod a-w java-sablevm
 
 ChangeLog:

It could be good to have this applied to the sources ;-)

Kind regards

-- 
Julio M. Merino Vidal <jm...@me...>
The NetBSD Project - http://www.NetBSD.org/

[Sablevm-developer] Uninitialized pthread condition causes a crash

[Julio M. M. V. <jm...@me...>]

Hi all,

I have just built and installed sablevm under NetBSD.  The build goes fine,
(aside two minor problems I'll describe in another mail when I find the right
solution), but when running threaded applications, it crashes.

The native libpthread library in NetBSD is full of assertions to capture
problems like uses of uninitialized mutexes or conditions.  And this is
what's happening.  The vm->threads.vm_destruction_cond condition is never
initialized, so when a wait happens, the vm crashes.

I've patched the code to initialize the condition in the invoke_interface.c
file, JNI_CreateJavaVM function.  I'm not sure if this is right (but is where
I found other initializations).  AFAICT, it's working now (no crash, and a
consumer/producer test program works fine).  The patch is this:

--- src/libsablevm/invoke_interface.c.orig	2004-03-20 23:02:04.000000000 +0100
+++ src/libsablevm/invoke_interface.c
@@ -220,6 +220,7 @@ JNI_CreateJavaVM (JavaVM **pvm, void **p
     }
 
   _svmf_set_current_env (env);
+  _svmm_cond_init (vm->threads.vm_destruction_cond);
   vm->threads.user = env;
   vm->threads.next_thread_id = 1;	/* thread IDs must start at 1
 					   (i.e. no ID == 0) */


Kind regards

-- 
Julio M. Merino Vidal <jm...@me...>
The NetBSD Project - http://www.NetBSD.org/

Re: [Sablevm-developer] Re: Starting to swing... [screenshots]

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

Hi all,

On Wed, 2004-03-24 at 19:39, Etienne Gagnon wrote:
>  >   http://people.redhat.com/~graydon/free-swing-mar-23-2004.png
>=20
> OK SableVM guys!  I'd like to see this in SableVM's staging tree *now*!

:)

> To get get SableVM staging to work out-of-the-box with
> a Classpath CVS, using:
>=20
> $ # [go to classpath working copy]
> $ cd classpath
> $ ./configure --with-vm=3Dsablevm && make && make install
>=20
> $ # [go to sablevm working copy]
> $ cd ../sablevm
> $ ./configure && make && make install
>=20
> $ # [go to swing demo]
> $ cd ../swing-demo
> $ sablevm SwingDemo
>=20
> $ # [amazing GUI is now shown :-)]
>=20
> What's missing?

Two things:

- This code is now only in the development branch of libgcj. To keep the
AWT/Swing hackers busy and to to distracted by all the other cool things
going on this is only merged back to libgcj proper once a month (then it
needs to me merged back to classpath again). Which means that you will
have to wait till 0.09 probably to play with it out of the box.

- Although we have a TestAWT application, we don't have a TestSwing
application. It would be nice if Graydon could post the sources of the
demos he used for the nice shots at http://people.redhat.com/~graydon/
Hint, hint, ... ;)

Cheers,

Mark

Re: [Sablevm-developer] Re: Starting to swing... [screenshots]

[Etienne G. <gag...@uq...>]

 >   http://people.redhat.com/~graydon/free-swing-mar-23-2004.png

OK SableVM guys!  I'd like to see this in SableVM's staging tree *now*!

To get get SableVM staging to work out-of-the-box with
a Classpath CVS, using:

$ # [go to classpath working copy]
$ cd classpath
$ ./configure --with-vm=sablevm && make && make install

$ # [go to sablevm working copy]
$ cd ../sablevm
$ ./configure && make && make install

$ # [go to swing demo]
$ cd ../swing-demo
$ sablevm SwingDemo

$ # [amazing GUI is now shown :-)]

What's missing?


Etienne

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

[Sablevm-developer] Re: Starting to swing... [screenshots]

[graydon h. <gr...@re...>]

Aaron M. Renn wrote:

> Can I just say "Wow!"?  That is super cool.  It's fantastic to see
> actual Swing screens.

I can add another teaser from the branch. olga rodimina has chased down 
most of the major rendering, geometry, and image transfer bugs in our 
native Graphics2D (cairo) backend. as a result, here is a native swing 
GUI rendering through Graphics2D (note the pervasive smooth vector 
graphics feel):

   http://people.redhat.com/~graydon/free-swing-mar-23-2004.png

most of the new widgets there (scroll bars, tab pane) are kim ho's work.

-graydon

[Sablevm-developer] SableVM 1.1.1 Development Release

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

The developers of the SableVM Project are proud to announce the
official release of SableVM 1.1.1.  SableVM is a liberally licensed
Free Java Virtual Machine.  Although this release is considered to be
a "development" one, we believe that version 1.1.1 is far superior in
to our last stable release 1.0.9.  It also includes important
improvements and bug fixes over the previous 1.1.0 development
release.

The most important changes and features of 1.1.1 include:

* sablevm-classpath is based on the very recent GNU Classpath 0.08
  release

* Working ports to 8 architectures (alpha, hppa, i386, ia64, m68k,
  powerpc, s390, sparc)

* Many fills in JNI interface, reflection and other mechanisms

* Partially working AWT support (as GNU Classpath implements it)

* 'java-sablevm' command wrapper for similarity to Sun's 'java'
  command-line utility

* New manual pages and updated developer documentation

* Many other improvements and a few bug fixes


=== INSTALLATION ===

WARNING: PLEASE READ THE INSTALLATION INSTRUCTIONS.  THIS WILL SAVE
         YOU PRECIOUS TIME.

         In particular, you *MUST* pass options to ./configure in
         'sablevm-classpath', otherwise your installation will NOT
         work.

         Easy "copy & paste" instructions are provided in the
         INSTALL-DEVEL file that you will find in the
         sablevm-x.y.z.tar.gz file.  These instructions are also
         available online at:
         http://devel.sablevm.org/docs/INSTALL.txt.

SableVM is available to download from:

    http://devel.sablevm.org/download/1.1.1/

You must download both:

    sablevm-1.1.1.tar.gz
and
    sablevm-classpath-1.1.1.tar.gz.


Or if you prefer the Source Forge download facilities (which are
probably faster), you can use the following link:

    http://sourceforge.net/projects/sablevm/


We plan to make frequent development releases, but please note that we
also have daily snapshots of our "staging" development tree readily
available at:

    http://devel.sablevm.org/shot


Note that the "staging" code is much more robust than the usual CVS
trunk of many other free software projects.  The "staging" tree only
contains code that has been first tested by developers within their
own "sandbox" development tree.  So, in general, the "staging" code is
very robust.


=== NOTES ===

We appreciate your feedback.  Please feel invited to mail us. See:

    http://devel.sablevm.org/wiki/MailingLists

You can also join us in real-time on the #sablevm IRC channel on
irc.sablevm.org (alias: irc.freenode.net).


=== BINARY PACKAGES ===

Binary packages of SableVM 1.1.1 are available in the GNU/Linux Debian
"unstable" distribution.  These packages should migrate to the
"testing" distribution in a few weeks.  The binary packages currently
found in the "testing" distribution contain the 1.1.0 version with
some bug fixes extracted from the 1.1.1 release.

We are looking for people willing to package SableVM for other
GNU/Linux distributions (and operating systems).  We have a
preliminary sablevm.spec (for the RPM package manager).  We would
really like to get LSB-compatible RPM packages.  Such packages could
be built on a Debian system (with the help of LSB development
packages).  If you are interested to get involved, we will be glad to
help you.


=== CONCLUSION ===

We wish you great fun using SableVM.

Enjoy!


        The SableVM Project developers

-- 
Grzegorz B. Prokopski <ga...@de...>
Debian GNU/Linux      http://www.debian.org
SableVM - LGPLed JVM  http://www.sablevm.org
Why SableVM ?!?       http://devel.sablevm.org/wiki/WhySableVM

Re: [Sablevm-developer] Obsoleting sablevm-classpath NOW!

[Etienne G. <gag...@uq...>]

Grzegorz B. Prokopski wrote:
> Spoiler: this SableVM supports GNU Classpath CVS out-of-the-box

Great!

> These classes wouldn't need
> to reside in GNU CP tree, so ./vm/reference will move to ./vm.
> (this is still a matter of discussion, I am not stating what will be!)

I am far from agreeing with this; this would lead to unnecessary
duplication of code between VM's.  Worse, it would lead to an awkward
installation process.

I definitely think that Classpath should work *out-of-the-box* with all
normal[0] VMs; something like:

$ su
$ tar -xzvf sablevm-x.y.z.tar.gz
$ cd sablevm-x.y.z
$ ./configure
$ make
$ make install
$ cd ..
$ tar -xzvf classpath-x.yy.tar.gz
$ cd classpath-x.yy
$ ./configure
[configure error]: You must specify a vm in the form of the following command
line option --with-vm=[none,sablevm,kaffe,jamvm,jikesrvm,...]
$ ./configure --with-vm=sablevm
$ make
$ make install
$ exit
$ cd ~/hello
$ /usr/local/bin/sablevm HelloWorld
Hello World!
$

This would work best with:
0- All VM-specific code moved to VM*.java classes.
1- VM*.java classes residing in the *normal* Classpath tree.
2- Using m4 to maintain real VM-specific code. [Many VM's
    will probably share "native" method declarations, for example].
3- The /vm subtree could be either eliminated, or kept around for
    unusual[1] VM's.


[0] I mean VM's with a usual build process, such as kaffe, sablevm, etc.
[1] I mean VM's with unusual build process, such as JikesRVM, etc.

Etienne

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

Re: [Sablevm-developer] Obsoleting sablevm-classpath NOW!

[David <db...@cs...>]

Hello,

I really like this idea!
Good work Grzegorz!

I looked quickly at the reorganization and it looks good.

I will test later, probably wait until it gets into staging.

David

On Sun, Mar 21, 2004 at 09:58:38PM -0500, Grzegorz B. Prokopski wrote:
> Hi everybody,
>=20
> Spoiler: this SableVM supports GNU Classpath CVS out-of-the-box
>=20
> 	svn co svn://svn.sablevm.org/developers/gadek/sandbox/svm-cpootb
>=20
> [ Instalation instructions are at the end ]
>=20
> How big hack it is, you'd ask? Well, yes, it is one, but not that big.
> But let me explain from the beginning.
>=20
> =3D=3D=3D=3D Story =3D=3D=3D=3D
>=20
> I discussed with Mark integration of GNU CP and SableVM. As far as I
> could understand his POV, the course will probably be so that each
> VM itself supplied own set of VM* classes. These classes wouldn't need
> to reside in GNU CP tree, so ./vm/reference will move to ./vm.
> (this is still a matter of discussion, I am not stating what will be!)
>=20
> Since some time I was looking at the diff between our classpath and
> upstream besides changes in VM* classes there were mainly thing related
> to ClassLoader, which currently is broken/doesn't exist in GNU CP,
> plus some other stuff that will have to be actually merged, ie. removin=
g
> static initializers (though not too many of such things).
>=20
> 	So I simply integrated VM* classes subtree with sablevm source,
> 	plus added these classes, which we have to have modifed because
> 	of the above reasons. This approach can be seen as
> 	controversial, but IMO there's no reason for SableVM to suffer
> 	just because all CP developers (us including) haven't agreed on
> 	ex. what ClassLoader should look/work like!
>=20
> The list of "classes that should not be there" (there's currently 12!
> of them) is provided and these classes should be eliminated one by one
> as soon as Classpath's code of this classes becomes usable for us. But
> this can be done incrementally and we can work w/ GNU CP CVS now, and
> not at the end of the process.
>=20
> If this or similar idea gets accepted (are you liestening Etienne? ;-)
> we can stop providing our "own" sablevm-classpath tree, but simply
> ship (almost) original classpath 'dist' tarball plus sablevm tarball.
>=20
> Unfortunatelly this doesn't let us forget about merging with GNU CP,
> as merging of changes to the VM* classes will always be needed until
> the interface isn't stabilized. And of course we need to merge changes
> done to these "classes that should not be there" in our tree, but we
> do that already anyway and this too should go away after some time.
>=20
> =3D=3D=3D=3D Rough edges =3D=3D=3D=3D
>=20
> The current code has some "features" you should be aware of.
> 1. Classpath *must* be installed first because jikes needs these
> classes to properly compile VM* classes.
> 2. WARNING: During 'make install' VM* classes from sablevm *overwrite*
> Classpath VM* classes (and the "classes that shouldn't be there"
> overwrite their counterparts).
> 3. I assume you're going to use jikes, no other javac is supported ATM.
>=20
> 1. will probably never go away, and 3. don't seem to be very harmful.
> Ad. 2: this is because currently bootclasspath can NOT contain more tha=
t
> one path. This should go away if we add support like for normal
> classpath values, so that ":" was used as a separator. Put onto
> immediate TODO list *IF* this or similar approach is accepted.
>=20
> =3D=3D=3D=3D Installation instructions =3D=3D=3D=3D
>=20
> 1. get SableVM from the above SVN address.
> 2. get GNU Classpath from CVS http://savannah.gnu.org/cvs/?group_id=3D8=
5
> 3. get easy-classpath-build script by using:
> svn cat svn://svn.sablevm.org/sablevm-classpath/branches/staging \
>  >./build_sablevm-classpath
> chmod +x ./build_sablevm-classpath
> 4. go into GNU Classpath source dir and run=20
> ../svm-cpootb/autogen.sh
> ../build_sablevm-classpath /where/you/want/to/install
> 5. go into SableVM source dir 'svm-cpootb'
> ./autogen.sh && ./configure --prefix=3D/where/you/want/to/install && \
> make && make install
>=20
> Have fun!
>=20
> 				Grzegorz B. Prokopski
>=20
> --=20
> Grzegorz B. Prokopski <ga...@de...>
> Debian GNU/Linux      http://www.debian.org
> SableVM - LGPLed JVM  http://www.sablevm.org
> Why SableVM ?!?       http://devel.sablevm.org/wiki/WhySableVM
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dc=
lick
> _______________________________________________
> Sablevm-developer mailing list
> Sab...@li...
> https://lists.sourceforge.net/lists/listinfo/sablevm-developer

--=20

---

David B=E9langer
Graduate Student
School of Computer Science
McGill University
Office: MC226

Web page:   http://www.cs.mcgill.ca/~dbelan2/
Public key: http://www.cs.mcgill.ca/~dbelan2/public_key.txt

[Sablevm-developer] Obsoleting sablevm-classpath NOW!

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

Hi everybody,

Spoiler: this SableVM supports GNU Classpath CVS out-of-the-box

	svn co svn://svn.sablevm.org/developers/gadek/sandbox/svm-cpootb

[ Instalation instructions are at the end ]

How big hack it is, you'd ask? Well, yes, it is one, but not that big.
But let me explain from the beginning.

==== Story ====

I discussed with Mark integration of GNU CP and SableVM. As far as I
could understand his POV, the course will probably be so that each
VM itself supplied own set of VM* classes. These classes wouldn't need
to reside in GNU CP tree, so ./vm/reference will move to ./vm.
(this is still a matter of discussion, I am not stating what will be!)

Since some time I was looking at the diff between our classpath and
upstream besides changes in VM* classes there were mainly thing related
to ClassLoader, which currently is broken/doesn't exist in GNU CP,
plus some other stuff that will have to be actually merged, ie. removing
static initializers (though not too many of such things).

	So I simply integrated VM* classes subtree with sablevm source,
	plus added these classes, which we have to have modifed because
	of the above reasons. This approach can be seen as
	controversial, but IMO there's no reason for SableVM to suffer
	just because all CP developers (us including) haven't agreed on
	ex. what ClassLoader should look/work like!

The list of "classes that should not be there" (there's currently 12!
of them) is provided and these classes should be eliminated one by one
as soon as Classpath's code of this classes becomes usable for us. But
this can be done incrementally and we can work w/ GNU CP CVS now, and
not at the end of the process.

If this or similar idea gets accepted (are you liestening Etienne? ;-)
we can stop providing our "own" sablevm-classpath tree, but simply
ship (almost) original classpath 'dist' tarball plus sablevm tarball.

Unfortunatelly this doesn't let us forget about merging with GNU CP,
as merging of changes to the VM* classes will always be needed until
the interface isn't stabilized. And of course we need to merge changes
done to these "classes that should not be there" in our tree, but we
do that already anyway and this too should go away after some time.

==== Rough edges ====

The current code has some "features" you should be aware of.
1. Classpath *must* be installed first because jikes needs these
classes to properly compile VM* classes.
2. WARNING: During 'make install' VM* classes from sablevm *overwrite*
Classpath VM* classes (and the "classes that shouldn't be there"
overwrite their counterparts).
3. I assume you're going to use jikes, no other javac is supported ATM.

1. will probably never go away, and 3. don't seem to be very harmful.
Ad. 2: this is because currently bootclasspath can NOT contain more that
one path. This should go away if we add support like for normal
classpath values, so that ":" was used as a separator. Put onto
immediate TODO list *IF* this or similar approach is accepted.

==== Installation instructions ====

1. get SableVM from the above SVN address.
2. get GNU Classpath from CVS http://savannah.gnu.org/cvs/?group_id=85
3. get easy-classpath-build script by using:
svn cat svn://svn.sablevm.org/sablevm-classpath/branches/staging \
 >./build_sablevm-classpath
chmod +x ./build_sablevm-classpath
4. go into GNU Classpath source dir and run 
../svm-cpootb/autogen.sh
../build_sablevm-classpath /where/you/want/to/install
5. go into SableVM source dir 'svm-cpootb'
./autogen.sh && ./configure --prefix=/where/you/want/to/install && \
make && make install

Have fun!

				Grzegorz B. Prokopski

-- 
Grzegorz B. Prokopski <ga...@de...>
Debian GNU/Linux      http://www.debian.org
SableVM - LGPLed JVM  http://www.sablevm.org
Why SableVM ?!?       http://devel.sablevm.org/wiki/WhySableVM

[Sablevm-developer] Re: Starting to swing... [screenshots]

[Aaron M. R. <ar...@ur...>]

Grzegorz B. Prokopski (ga...@de...) wrote:
> Maybe it's not able yet to run serious Swing apps, but the progress is
> very visible. Here you'll find a few screenshots I took while testing
> this new version.

Can I just say "Wow!"?  That is super cool.  It's fantastic to see
actual Swing screens.

-- 
Aaron M. Renn (ar...@ur...) http://www.urbanophile.com/arenn/

[Sablevm-developer] Starting to swing... [screenshots]

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

Hi all,

I just wanted to share this little happiness with you. The swing code
merged recently from GCJ into GNU Classpath by Michael found its way
into SableVM's "vendor" branch (thanks to Etienne) and I just merged
it on my disk w/ our "staging" version (not yet comitted).

Maybe it's not able yet to run serious Swing apps, but the progress is
very visible. Here you'll find a few screenshots I took while testing
this new version.

	http://gadek.debian.net/swing

Good work, guys!

					Grzegorz B. Prokopski

-- 
Grzegorz B. Prokopski <ga...@de...>
Debian GNU/Linux      http://www.debian.org
SableVM - LGPLed JVM  http://www.sablevm.org
Why SableVM ?!?       http://devel.sablevm.org/wiki/WhySableVM

[Sablevm-developer] Bug#238651: marked as done (java-sablevm dequotes parameters)

[<ow...@bu...>]

Your message dated Sun, 21 Mar 2004 00:02:03 -0500
with message-id <E1B...@ne...>
and subject line Bug#238651: fixed in sablevm 1.1.1-1
has caused the attached Bug report to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere.  Please contact me immediately.)

Debian bug tracking system administrator
(administrator, Debian Bugs database)

--------------------------------------
Received: (at submit) by bugs.debian.org; 18 Mar 2004 08:03:16 +0000
>From ila...@in... Thu Mar 18 00:03:16 2004
Return-path: <ila...@in...>
Received: from mailbox1.avalonworks.net [216.58.97.66] 
	by spohr.debian.org with esmtp (Exim 3.35 1 (Debian))
	id 1B3sUm-0003tF-00; Thu, 18 Mar 2004 00:03:16 -0800
Received: from localhost (i216-58-64-59.avalonworks.net [216.58.64.59])
	by mailbox1.avalonworks.net (8.12.10/8.12.6) with ESMTP id i2I83AiX004084
	for <su...@bu...>; Thu, 18 Mar 2004 03:03:11 -0500 (EST)
	(envelope-from ila...@in...)
Received: from ilgiz by localhost with local (Exim 4.30)
	id 1B3rNe-0001E4-Bz
	for su...@bu...; Thu, 18 Mar 2004 01:51:50 -0500
Date: Thu, 18 Mar 2004 01:51:49 -0500
From: Ilguiz Latypov <ila...@in...>
To: su...@bu...
Subject: java-sablevm dequotes parameters
Message-ID: <200...@ei...>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.5.1+cvs20040105i
Sender: Ilguiz Latypov <ila...@in...>
Delivered-To: su...@bu...
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2004_03_12 
	(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Status: No, hits=-7.0 required=4.0 tests=BAYES_00,HAS_PACKAGE 
	autolearn=no version=2.60-bugs.debian.org_2004_03_12
X-Spam-Level: 



Package: sablevm
Version: 1.1.0-5

The /usr/bin/java-sablevm shell script dequotes parameters submitted by
the user's command line.  E.g., running

  java mypackage.MyApp "select * from table"

will yield only the word "select" in args[1] of the MyApp's main(String
args[]) method.  

I believe the lines

    $echo $JVM -Y $CLASSPATH $OPTS $REST $@
    $exec $JVM -Y $CLASSPATH $OPTS $REST $@

can be replaced with

    $echo $JVM -Y $CLASSPATH $OPTS $REST "$@"
    $exec $JVM -Y $CLASSPATH $OPTS $REST "$@"

Also, the line

      EST="$REST $1"

should probably read

      REST="$REST $1"

Regards,

-- 
Ilguiz Latypov

tel.  +1 (519) 569-8746
66 Wildlark Crescent
Kitchener, Ontario N2N 3E9


---------------------------------------
Received: (at 238651-close) by bugs.debian.org; 21 Mar 2004 05:08:02 +0000
>From ka...@ft... Sat Mar 20 21:08:02 2004
Return-path: <ka...@ft...>
Received: from newraff.debian.org [208.185.25.31] (mail)
	by spohr.debian.org with esmtp (Exim 3.35 1 (Debian))
	id 1B4vBq-00027r-00; Sat, 20 Mar 2004 21:08:02 -0800
Received: from katie by newraff.debian.org with local (Exim 3.35 1 (Debian))
	id 1B4v63-0003ez-00; Sun, 21 Mar 2004 00:02:03 -0500
From: Grzegorz Prokopski (Debian Developer) <ga...@de...>
To: 238...@bu...
X-Katie: $Revision: 1.45 $
Subject: Bug#238651: fixed in sablevm 1.1.1-1
Message-Id: <E1B...@ne...>
Sender: Archive Administrator <ka...@ft...>
Date: Sun, 21 Mar 2004 00:02:03 -0500
Delivered-To: 238...@bu...
X-Spam-Checker-Version: SpamAssassin 2.60-bugs.debian.org_2004_03_12 
	(1.212-2003-09-23-exp) on spohr.debian.org
X-Spam-Status: No, hits=-5.0 required=4.0 tests=BAYES_00,HAS_BUG_NUMBER 
	autolearn=no version=2.60-bugs.debian.org_2004_03_12
X-Spam-Level: 

Source: sablevm
Source-Version: 1.1.1-1

We believe that the bug you reported is fixed in the latest version of
sablevm, which is due to be installed in the Debian FTP archive:

jikes-sablevm_1.1.1-1_all.deb
  to pool/main/s/sablevm/jikes-sablevm_1.1.1-1_all.deb
libsablevm1-dev_1.1.1-1_all.deb
  to pool/main/s/sablevm/libsablevm1-dev_1.1.1-1_all.deb
libsablevm1_1.1.1-1_i386.deb
  to pool/main/s/sablevm/libsablevm1_1.1.1-1_i386.deb
sablevm_1.1.1-1.diff.gz
  to pool/main/s/sablevm/sablevm_1.1.1-1.diff.gz
sablevm_1.1.1-1.dsc
  to pool/main/s/sablevm/sablevm_1.1.1-1.dsc
sablevm_1.1.1-1_i386.deb
  to pool/main/s/sablevm/sablevm_1.1.1-1_i386.deb
sablevm_1.1.1.orig.tar.gz
  to pool/main/s/sablevm/sablevm_1.1.1.orig.tar.gz



A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 23...@bu...,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Grzegorz Prokopski (Debian Developer) <ga...@de...> (supplier of updated sablevm package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftp...@de...)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Sat, 20 Mar 2004 16:59:55 -0500
Source: sablevm
Binary: libsablevm1 sablevm jikes-sablevm libsablevm1-dev
Architecture: source all i386
Version: 1.1.1-1
Distribution: unstable
Urgency: low
Maintainer: Grzegorz Prokopski (Debian Developer) <ga...@de...>
Changed-By: Grzegorz Prokopski (Debian Developer) <ga...@de...>
Description: 
 jikes-sablevm - Wrapper for jikes using classes from SableVM JVM
 libsablevm1 - Free implementation of JVM second edition - library
 libsablevm1-dev - Free implementation of JVM secon edition - development files
 sablevm    - Free implementation of Java Virtual Machine (JVM) second edition
Closes: 238651
Changes: 
 sablevm (1.1.1-1) unstable; urgency=low
 .
   * New upstream release. Uses SableVM Classpath derived from Classpath 0.08.
   * Don't dequote params passed to program invoked with 'java-sablevm'.
     Closes: #238651.
Files: 
 b60e4201eb67099ec06d6e18c7a1d6a5 720 interpreters optional sablevm_1.1.1-1.dsc
 c47f1b4e198e57fa5a9477ff75ca535d 554037 interpreters optional sablevm_1.1.1.orig.tar.gz
 77bb22f5e6f973228cf0d7d9787b19d2 9632 interpreters optional sablevm_1.1.1-1.diff.gz
 9563a65f4d7e6798ad29f9ca4067c070 23172 interpreters optional sablevm_1.1.1-1_i386.deb
 2ab4e53a554c3d5f546eed97293a8237 147146 libs optional libsablevm1_1.1.1-1_i386.deb
 337baefcd7f544b5003a076d528c20b1 12872 libdevel optional libsablevm1-dev_1.1.1-1_all.deb
 368f3587c59e00d4c5332662f432c0f3 7424 devel optional jikes-sablevm_1.1.1-1_all.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAXPKPcxjwiKS4/ekRAimoAJ0UmYye9CxSswPKt8D9F/xKj6D43wCgoiyd
cqYd8SYAnebFU697/gY8mks=
=Gz4J
-----END PGP SIGNATURE-----

[Sablevm-developer] Accepted sablevm-classlib 1.1.1-1 (i386 source all)

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Sat, 20 Mar 2004 19:36:41 -0500
Source: sablevm-classlib
Binary: libsablevm-native1 libsablevm-classlib1-java
Architecture: source all i386
Version: 1.1.1-1
Distribution: unstable
Urgency: low
Maintainer: Grzegorz Prokopski (Debian Developer) <ga...@de...>
Changed-By: Grzegorz Prokopski (Debian Developer) <ga...@de...>
Description: 
 libsablevm-classlib1-java - GNU Classpath modified to work with SableVM JVM
 libsablevm-native1 - GNU Classpath modified to work with SableVM JVM (native part)
Changes: 
 sablevm-classlib (1.1.1-1) unstable; urgency=low
 .
   * New upstream release based on GNU Classpath 0.08.
   * Tightened dependencies.
Files: 
 9b399c9597d4d0c3d7cd0c727c915870 740 libs optional sablevm-classlib_1.1.1-1.dsc
 46350aef99a63b92026b6f9a3ac6ecab 3495089 libs optional sablevm-classlib_1.1.1.orig.tar.gz
 926347cea079577017416e11f8973263 4349 libs optional sablevm-classlib_1.1.1-1.diff.gz
 d5d665d9cf47cb5f3644a26e28d7dc44 2065876 libs optional libsablevm-classlib1-java_1.1.1-1_all.deb
 3b3986177767d46e5818da310b986f36 353686 libs optional libsablevm-native1_1.1.1-1_i386.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAXQatcxjwiKS4/ekRAl0HAKCcR+YLRXOIAq6qpW/6lI131qRUugCeKGR7
xcx+16d67cIKvdNuOKlvQ0U=
=D6dR
-----END PGP SIGNATURE-----


Accepted:
libsablevm-classlib1-java_1.1.1-1_all.deb
  to pool/main/s/sablevm-classlib/libsablevm-classlib1-java_1.1.1-1_all.deb
libsablevm-native1_1.1.1-1_i386.deb
  to pool/main/s/sablevm-classlib/libsablevm-native1_1.1.1-1_i386.deb
sablevm-classlib_1.1.1-1.diff.gz
  to pool/main/s/sablevm-classlib/sablevm-classlib_1.1.1-1.diff.gz
sablevm-classlib_1.1.1-1.dsc
  to pool/main/s/sablevm-classlib/sablevm-classlib_1.1.1-1.dsc
sablevm-classlib_1.1.1.orig.tar.gz
  to pool/main/s/sablevm-classlib/sablevm-classlib_1.1.1.orig.tar.gz

[Sablevm-developer] Accepted sablevm 1.1.1-1 (i386 source all)

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.7
Date: Sat, 20 Mar 2004 16:59:55 -0500
Source: sablevm
Binary: libsablevm1 sablevm jikes-sablevm libsablevm1-dev
Architecture: source all i386
Version: 1.1.1-1
Distribution: unstable
Urgency: low
Maintainer: Grzegorz Prokopski (Debian Developer) <ga...@de...>
Changed-By: Grzegorz Prokopski (Debian Developer) <ga...@de...>
Description: 
 jikes-sablevm - Wrapper for jikes using classes from SableVM JVM
 libsablevm1 - Free implementation of JVM second edition - library
 libsablevm1-dev - Free implementation of JVM secon edition - development files
 sablevm    - Free implementation of Java Virtual Machine (JVM) second edition
Closes: 238651
Changes: 
 sablevm (1.1.1-1) unstable; urgency=low
 .
   * New upstream release. Uses SableVM Classpath derived from Classpath 0.08.
   * Don't dequote params passed to program invoked with 'java-sablevm'.
     Closes: #238651.
Files: 
 b60e4201eb67099ec06d6e18c7a1d6a5 720 interpreters optional sablevm_1.1.1-1.dsc
 c47f1b4e198e57fa5a9477ff75ca535d 554037 interpreters optional sablevm_1.1.1.orig.tar.gz
 77bb22f5e6f973228cf0d7d9787b19d2 9632 interpreters optional sablevm_1.1.1-1.diff.gz
 9563a65f4d7e6798ad29f9ca4067c070 23172 interpreters optional sablevm_1.1.1-1_i386.deb
 2ab4e53a554c3d5f546eed97293a8237 147146 libs optional libsablevm1_1.1.1-1_i386.deb
 337baefcd7f544b5003a076d528c20b1 12872 libdevel optional libsablevm1-dev_1.1.1-1_all.deb
 368f3587c59e00d4c5332662f432c0f3 7424 devel optional jikes-sablevm_1.1.1-1_all.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAXPKPcxjwiKS4/ekRAimoAJ0UmYye9CxSswPKt8D9F/xKj6D43wCgoiyd
cqYd8SYAnebFU697/gY8mks=
=Gz4J
-----END PGP SIGNATURE-----


Accepted:
jikes-sablevm_1.1.1-1_all.deb
  to pool/main/s/sablevm/jikes-sablevm_1.1.1-1_all.deb
libsablevm1-dev_1.1.1-1_all.deb
  to pool/main/s/sablevm/libsablevm1-dev_1.1.1-1_all.deb
libsablevm1_1.1.1-1_i386.deb
  to pool/main/s/sablevm/libsablevm1_1.1.1-1_i386.deb
sablevm_1.1.1-1.diff.gz
  to pool/main/s/sablevm/sablevm_1.1.1-1.diff.gz
sablevm_1.1.1-1.dsc
  to pool/main/s/sablevm/sablevm_1.1.1-1.dsc
sablevm_1.1.1-1_i386.deb
  to pool/main/s/sablevm/sablevm_1.1.1-1_i386.deb
sablevm_1.1.1.orig.tar.gz
  to pool/main/s/sablevm/sablevm_1.1.1.orig.tar.gz

[Sablevm-developer] [PATCH] automake doesn't allow for 100+ long paths in "dist" tarball

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

reopen 235395
reassign 235395 automake1.7
tag 235395 patch
thanks

While creating "dist" tarball tar is called with "chof" options.
The option "o" forces OLD archive format which only allows for
maximum of 100 chars in a path. 

This problem does not show up if one is using old-enough version of
tar, ex. from woody. As I learned from discussion with Tom Tromey,
the original author of automake, they used "o" option because it
was the only way to make gnu tar produce tarballs readable by other
tars.

The old gnu tar (ex. from Woody) misinterpreted this option and forced
--posix mode. In newer versions of gnu tar this has been fixed, but as
a sideffect - it broke usage of autotools for all software projects
that create "dist" tarballs with paths longer than 100 chars.

The "chof" options passed to tar come from
/usr/share/automake-1.7/am/distdir.am. The attached patch changes
"o" into "--posix". I have tested it and it fixed problem of
creating tarballs of GNU Classpath. It would be very important
to have this problem fixed before Sarge release.

HTH

				Grzegorz B. Prokopski

PS: For reference see also #414 at
 http://sources.redhat.com/cgi-bin/gnatsweb.pl?database=automake

-- 
Grzegorz B. Prokopski <ga...@de...>
Debian GNU/Linux      http://www.debian.org
SableVM - LGPLed JVM  http://www.sablevm.org
Why SableVM ?!?       http://devel.sablevm.org/wiki/WhySableVM

[Sablevm-developer] SableVM 1.1.1 is there - no announcements yet

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

Hi Etienne, hi everyone,

Tags for 1.1.1 have been made. I don't expect any changes to them, but
if somebody has a good reason for it - speak up now! The dist tarballs
I made (and tested) are available at:

	http://devel.sablevm.org/download/1.1.1/

There are two things remaining to be done:
1) Etienne builds his tarballs from tags and uploads to SF and devel.s.o
2) Announcements are made.

I think we should send the announce here and to classpath ML _now_, and
do the NEWS update. But sablevm-announce, freshmeat etc. should be
postponed till ex. tuesday. Here's why: FWCS normal people are generally
trying to get rest during the weekend, then mondays are always quite
busy so tuesday seems like a good idea to remind them about SableVM.
Additionally Debian packages should be uploaded and available from
mirrors by then. [*]

And if something was severly broken we could release 1.1.2 before
too many people tried the broken version.

BTW: I've just noticed that we haven't followed the policy of bugfree,
that is, we haven't fixed the bugs in bugfree, but only in staging.
I think mostly about this exec()/waitFor() bug. After applying
this one-liner fix we could have also released bugfix development
release 1.1.1, just with this change. Maybe not just yet, but I think
we should make sure that bugfree is actually bugfree and also
make bugfix releases as needed [**].

What do you think?

				Grzegorz B. Prokopski

[*] We're also looking for somebody to prepare RPM packages. I have done
some RPMs years ago and I have some preliminary sablevm.spec to start
with, so if there was somebody willing to _try_ it - please contact me
or the mailing list. There's also an idea of LSB-compatible RPM which
might be even more interesting, for some (and I am willing to help too).
It can even be realized on a Debian system (packages are there).

[**] I think I need to find a faster machine to do "make dist" on
Classpath. It takes almost an hour on my old, crappy machine...

PS: David, what's your standing on the SableJIT snapshot release?
Looks like there might be a bit more time to do it and still synchronize
with the main 1.1.1 announcements. Most probably I won't be able to do
any new release in april, so it might be the only such occasion.
-- 
Grzegorz B. Prokopski <ga...@de...>
Debian GNU/Linux      http://www.debian.org
SableVM - LGPLed JVM  http://www.sablevm.org
Why SableVM ?!?       http://devel.sablevm.org/wiki/WhySableVM

Re: [Sablevm-developer] Staging build failure...

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

W li=B6cie z pi=B1, 19-03-2004, godz. 20:01, David B=E9langer pisze:
> I test on Debian/x86, jikes 1.18 and could not reproduce this error.

Neither could I. I discussed that with Etienne (on IRC) soon after he
sent the mail. The report was bogus.

> Does anyone else have this problem?

Apparently nobody, as long as one is using rather old tar, ex. from
Woody. This version works fine:

$ tar --version
tar (GNU tar) 1.13.25

Cheers,

				GBP

--=20
Grzegorz B. Prokopski <ga...@de...>
Debian GNU/Linux      http://www.debian.org
SableVM - LGPLed JVM  http://www.sablevm.org
Why SableVM ?!?       http://devel.sablevm.org/wiki/WhySableVM

Re: [Sablevm-developer] Staging build failure...

[David <db...@cs...>]

Hello,

I test on Debian/x86, jikes 1.18 and could not reproduce this error.
Does anyone else have this problem?

David

On Fri, Mar 19, 2004 at 01:45:51PM -0500, Etienne Gagnon wrote:
> Hi all,
>=20
> "make distcheck" of sablevm-classpath fails with:
> ...
> *** Semantic Error: The variable "th" may be accessed here before havin=
g=20
> been definitely assigned a value.
> jikes: bytecode.h:794: u2 ByteCode::RegisterClass(Utf8LiteralValue*):=20
> Assertion `lit && "null argument to RegisterClass"' failed.
> make[2]: *** [compile-classes] Aborted
> make[2]: Leaving directory=20
> `/home/egagnon/sablevm-classpath/sablevm-classpath-1.1.0+staging/_build=
/lib'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory=20
> `/home/egagnon/sablevm-classpath/sablevm-classpath-1.1.0+staging/_build=
'
> make: *** [distcheck] Error 2
>=20
> I guess this *must* be fixed ASAP...
>=20
> Etienne
> --=20
> Etienne M. Gagnon, Ph.D.             http://www.info.uqam.ca/~egagnon/
> SableVM:                                       http://www.sablevm.org/
> SableCC:                                       http://www.sablecc.org/
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dc=
lick
> _______________________________________________
> Sablevm-developer mailing list
> Sab...@li...
> https://lists.sourceforge.net/lists/listinfo/sablevm-developer

--=20

---

David B=E9langer
Graduate Student
School of Computer Science
McGill University
Office: MC226

Web page:   http://www.cs.mcgill.ca/~dbelan2/
Public key: http://www.cs.mcgill.ca/~dbelan2/public_key.txt

[Sablevm-developer] Staging build failure...

[Etienne G. <gag...@uq...>]

Hi all,

"make distcheck" of sablevm-classpath fails with:
...
*** Semantic Error: The variable "th" may be accessed here before having been definitely assigned a value.
jikes: bytecode.h:794: u2 ByteCode::RegisterClass(Utf8LiteralValue*): Assertion `lit && "null argument to RegisterClass"' failed.
make[2]: *** [compile-classes] Aborted
make[2]: Leaving directory `/home/egagnon/sablevm-classpath/sablevm-classpath-1.1.0+staging/_build/lib'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/egagnon/sablevm-classpath/sablevm-classpath-1.1.0+staging/_build'
make: *** [distcheck] Error 2

I guess this *must* be fixed ASAP...

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

Re: [Sablevm-developer] boot.library.path vs. boot.class.path

[Chris P. <chr...@ma...>]

Archie Cobbs wrote:

> Chris Pickett wrote:
> 
>>--property=sablevm.boot.class.path=/some-transformed-path/
>>
>>and
>>
>>--property=sablevm.boot.library.path=/some-transformed-path/
>>
>>do, or at least tell me where to look?  In other words, what is the 
>>difference between them?
> 
> 
> A class path is a search path for Java class files, while a library
> path is a search path for shared library files (e.g., ELF files), such
> as may be needed by classes that rely on external native code.


Thanks.  I was having a problem where the number of Java method calls 
was going up slightly when I specified sablevm.boot.library.path as a 
property.  I later discovered from sablevm.verbose.methods=true output 
that this is because it is a System property set in Java, and requires 
some Java calls.

So, to anybody out there running benchmarks, if you need a consistent 
number of calls / instructions across experiments and you are varying VM 
properties across experiments, the solution is to specify always the 
properties you are varying, even if for a particular experiment the 
value is equivalent to the default value.

Cheers,
Chris

Re: [Sablevm-developer] On the 1.1.1 release and further

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

W li=B6cie z =B6ro, 10-03-2004, godz. 21:37, David B=E9langer pisze:=20
> > Another thing is SableJIT release. It's up to David when it happens,
> > but I think we shouldn't wait too long with releasing this code as a
> > _development_ release. We can even do it along 1.1.1, why not? I thin=
k
> > that this way David (and we all) could get some bugreports from the
> > users or/and gain confidence that SableJIT is actually usable in
> > the real, wild world ;-) And for some people word "JIT" is magical...
>=20
> If you want, it could be added eventually.  It is still

I vote for yes, the rest is not against. I'd say: it's as _you_ want.

> underdevelopment but a SableVM compiled with the JIT code is still able
> to run in interpreter-only mode.  In that case the JIT is never
> initialized and not used and this should not make sablevm unstable.

I think at this point we should release sth. like sablevm-sablejit-1.1.1
that contains all the needed code.=20

> So we could have these options:
> 1) provide a sablejit patch for SableVM
> 2) add SableJIT support to sablevm/staging, all code is #ifdef SABLEJIT=
* though
>    some clutter files, especially prepared_code.c.
> 3) use sablejit/staging
>    created subdir sablevm/ with patched SableVM
>    created subdir sablejit/ with Java code
>    In that case we have 2 staging version of SableVM, 1 with jit suppor=
t,
>    the other without.
I see... I think that svn://svn.sablevm.org/sablejit/branches/staging
should only contain SableJIT code.

I think this sablevm-sablejit tarball it doesn't have to come from
staging. We might not call it 1.1.1 then, but:

sablevm-sablejit-snapshot1.tar.gz

(it can be made by re-packing tar.gz created by 'make dist' so that it
unpack to sablevm-sablejit-snapshot1 directory)

Would you be able to create such tarball with a short instruction how
to compile it? I could then announce it along with SableVM 1.1.1 release
I want to make 'test' tarballs in a few minutes, then tomorrow evening
the 1.1.1 release.

Would you be able to prepare tarball + instruction till friday evening?
If not, then we'll make a separate release a while later.

Cheers,

				Grzegorz B. Prokopski

> > * The next thing seems to be this long-promised and awaited closer
> > integration with GNU Classpath. It's in the works, I'll send more inf=
o
> > as soon as the idea of implementing it in realistic way stabilizes.

Hmm... still waiting for Mark's response. It's over a week as I mailed
him.

--=20
Grzegorz B. Prokopski <ga...@de...>
Debian GNU/Linux      http://www.debian.org
SableVM - LGPLed JVM  http://www.sablevm.org
Why SableVM ?!?       http://devel.sablevm.org/wiki/WhySableVM