sablevm-developer Mailing List for SableVM (Page 5)
Brought to you by:
egagnon
You can subscribe to this list here.
2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(27) |
Aug
(22) |
Sep
(1) |
Oct
|
Nov
(1) |
Dec
(30) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
(32) |
Oct
|
Nov
|
Dec
|
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(69) |
Sep
(10) |
Oct
(31) |
Nov
(15) |
Dec
(58) |
2003 |
Jan
(33) |
Feb
(81) |
Mar
(85) |
Apr
(24) |
May
(15) |
Jun
(14) |
Jul
(6) |
Aug
(9) |
Sep
(101) |
Oct
(59) |
Nov
(142) |
Dec
(34) |
2004 |
Jan
(107) |
Feb
(164) |
Mar
(181) |
Apr
(96) |
May
(81) |
Jun
(71) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Etienne G. <gag...@uq...> - 2004-05-16 17:47:11
|
Hi All, I just wanted to let you know that now that 1.1.4 is out, I have updated sablevm-classpath staging with the latest changes in the upstream CVS repository, as of Sun May 16 17:00:00 UTC 2004. My tests seemed to indicate that everything worked well. Let me know if I happened to break anything. Etienne -- Etienne M. Gagnon, Ph.D. http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
From: Etienne G. <gag...@uq...> - 2004-05-16 03:36:40
|
The developers of the SableVM Project are proud to announce the official release of SableVM 1.1.4. SableVM is a liberally licensed Free Java Virtual Machine. See the "About SableVM" section below for more informations about SableVM. The most important changes and features of the 1.1.4 version include: - Updated sablevm-classpath is with the recent GNU Classpath 0.09 release with later GNU Classpath CVS changes as of May 4, 2004. - Improved support for AWT and Swing. - Eliminated the dependency lt_dlopen(NULL) which seem broken on some platforms such as Cygwin and some *BSD. - Switched to new, complete implementation of VMProcess/Process from GNU Classpath instead of using our own previous partial implementation. - Added x86_64 (AMD64) support to the already supported 8 other architectures of Debian GNU/Linux (alpha, hppa, i386, ia64, m68k, powerpc, s390, sparc). The support for the remaining mips and mipsel architectures of Debian is apparently implemented but it has not yet been confirmed. - Improved autodetection of build parameters on non-GNU/Linux systems. This includes selection of dynamic libraries, availability of m4 preprocessor and auto-disabling "signals for exceptions" on platforms that don't seem to support signals. - Made sure that the m4 preprocessor will not be needed to build from sablevm-*.tar.gz distribution files. m4 is only required to build directly from a snapshot of the Subversion repository. - Updated and improved manual pages. - Made some other little improvements and applied a few bug fixes. === ABOUT SABLEVM === SableVM is a robust, extremely portable, efficient, and specifications-compliant Java Virtual Machine that aims to be easy to maintain and to extend. It features a state-of-the-art, efficient interpreter engine. Its source code is very accessible and easy to understand, and has many robustness features that have been the object of careful design. SableVM is licensed under the terms of the GNU Lesser General Public License (LGPL). It also uses a modified version of GNU Classpath called sablevm-classpath which is licensed under the terms of the GNU General Public License with a linking exception. See http://www.sablevm.org/ for more details. === INSTALLATION === SableVM is available to download from: http://sourceforge.net/project/showfiles.php?group_id=5523&release_id=238633 You must download both: - sablevm-1.1.4.tar.gz - sablevm-classpath-1.1.4.tar.gz. See the INSTALL file included in the sablevm-1.1.4.tar.gz archive for build environment requirements and installation procedures. We plan to make frequent 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. See the following for details: http://devel.sablevm.org/wiki/DevelopmentBranches === 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 new SableVM versions are usually available in the GNU/Linux Debian "unstable" distribution shortly after the official release. These packages should migrate to the "testing" distribution in a few weeks. 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 |
From: David <db...@cs...> - 2004-05-15 18:47:31
|
Done. Basically it adds -Werror only for Linux x86 and ppc, and the staging version. It still respect the --disable-errors-on-warning. Previously the -Werror was only added when debugging mode is enabled. This will help hopefully finding out about warning before committing to staging even if the developer doesn't test with debugging enabled. David On Wed, May 12, 2004 at 12:24:41AM -0400, Grzegorz B. Prokopski wrote: > On (11/05/04 23:50), David B?langer wrote: > >=20 > > Hi, > >=20 > > I would like to suggest to have errors on warning on by default for t= he > > staging branch for platforms where warnings should not occur: > > Linux on ppc, x86 and maybe other CPU archs. >=20 > I think only on ppc and x86. If I recall correctly none of the others > compiles w/o warnings. I'd attribute it to GCC though. >=20 > > On other platforms, it would be off by default. > >=20 > > Sometimes warnings are difficult to see through the output. > >=20 > > What do you think? >=20 > Good idea. We already have --disable-errors-on-warnings which are usef= ul > if you turn on debug mode no non-intel, non-ppc platform. I guess you > could build upon that. Just try to avoid things we have to switch whil= e > migrating code from staging to bugfree and further. I'd suggest you > use something like that: >=20 > case $PACKAGE_VERSION in > staging*)=20 > case $host in > i*86*-*-gnu) turn on errors on warnings ;; > powerpc-*) turn on errors on warings ;; > ... > esac > ... > esac >=20 > Looking at generated ./configure, it seems that you could as well use > $VERSION or $RELEASE in place of $PACKAGE_VERSION. Not sure which one > would be the best choice. >=20 > HTH >=20 > GBP >=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 --- 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 |
From: Grzegorz B. P. <ga...@de...> - 2004-05-14 01:47:37
|
On (11/05/04 23:09), David B?langer wrote: > On Tue, May 11, 2004 at 10:27:46PM -0400, Grzegorz B. Prokopski wrote: > > Please take a look at what I've just copied from my sandbox to > > > > svn cat \ > > svn://svn.sablevm.org/sablevm/branches/staging/doc/release_mail.txt > > > > Improvements are welcome. > > Looks good! Well presented. Agreed. Etienne's hand is visible ;-) > You may want to add that we are now using the (new) VMProcess/Process > from CP instead of our own implementation. CP provides a complete > implementation whereas our implementation was providing basic > functionality. Ok, added. On (11/05/04 10:04), Etienne Gagnon wrote: > So, is there anything holding this release? Looks like we have the announcement ready to be send out, the "const" problems have been ironed out, I have also just resurrected NEWS file and put there news from the announcement. I think that for next releases we should have ./doc/release_mail.txt w/o any NEWS, if possible, even w/o version number and put the news where they belong, that is - to the NEWS file. These two sources should be simply combined to procude announcement mail. I guess that this is what you (Etienne) wanted originally. Now I am going to sit back and watch 1.1.4 releasing... 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 |
From: Grzegorz B. P. <ga...@de...> - 2004-05-14 01:20:25
|
On (11/05/04 23:00), Chris Pickett wrote: > The following sentence is redundant, otherwise it looks fine. > > So, in general, the "staging" code is very robust. Hmm... it surely is a repetition, though we might want to keep it to emphasize that the code IS very usable. This is something, I think, that really is different in SableVM development model. And I also think that we *want* as many people as possible to use 'staging'. Personally, I'd keep it. > At some point soonish (either before the end of the summer or before > 1.2.0) I plan on getting some regression testing stuff into staging (it > will require the user to download benchmarks separately). Yeah, I am going to set up some UML (User Mode Linux) env. on our new server so that we could: a) securely build real, 'dist' tar archives - current staging snapshots are, as David noticed, simply tar.gzs of tree checked out from subversion, b) run nightly any tests we might think of, I hope on more than one architecture; UML might be preventing us from getting reliable *performance* results though, but all the rest should work just fine. So when you have some regression testing suite it will surely be put into use. I imagine we'd want to have there things like: a) SPEC bencharks b) BTF c) Mauve d) Ashes (are they usable currently?) e) ... and we'd have "alarm" emails sent to the ML if nightly testing shows any anomalies in the output on any architecture. Nice, ain't it? I know what you think... and no, I am not just brainstorming :-) Though these things surely won't be operational tomorrow. Cheers, GBP -- 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 |
From: Grzegorz B. P. <ga...@de...> - 2004-05-13 19:59:26
|
Hi again, Small update. With help from our Debian Project Leader, Martin Michlmayr I got the output of running BTF on an ARM machine (attached). It looks like all DADD, DDIV, DMUL, DREM, operations involving NaN or Infinity return wrong results. At the end we also see that an integer operation causes CPU to generate signal which should not be there... I did some tests running "equivalent" C code on ARM machnes from handhelds.org's iPAQ cluster, but everything seems to work just fine, so I have no clue yet as to what exactly is the problem. You might want to look at instructions.m4.c and instrucions*.c files generated for it for the engine you're using (switch/direct/inlined). After all it's just a plain C code so it shouldn't be anything magical to just get it to work. Ex. you can easily take gdb/ddd and put a breakpoint on DADD and see what exactly it exectues. You want to configure --enable-debugging-features to change optimiation level from -O2 to -O0, which will make debugging much easier. Let me know if you have questions, HTH 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 |
From: Grzegorz B. P. <ga...@de...> - 2004-05-13 18:19:34
|
On (13/05/04 13:42), Fabien Renaud wrote: > I use --with-thread=direct on ARM and that doesn?t wotk. On my x86, that > works with default options. > I?ll try with --enable-debugging-features. This will not help. ARM is the last architecture that needs ironing out of these arithmetic CPU-specific quirks. Basically ARM doesn't catch any special cases, so you have to check for them yourself, by hand. The practical problem here is that all Debian ARM machines are unaccessible since some weeks, so I don't have access to a system where I could finish the port. I tried iPAQ cluster at handhelds.org, but software there is much too old and installing newer versions of a dozen of tools in home directory would be a lot of work. So, if you knew of an up-to-date ARM system where I could get an account - let me know. You could also try to fix it yourself. Compile SableVM in testing mode by passing --enable-inlinability-testing [*] to ./configure and run BTF tests ex. from http://devel.sablevm.org/arm/btf.tgz ('sablevm -Y BytecodeVerificationTest') and then look into instructions.m4.c to fix the instructions that give us problems on ARM. It's not terribly complicated but it practically impossible to do it w/o access to hardware (unless you want to spend time reading StrongARM specs to find out which cases you have to catch yourself). I wish I could help you more, Grzegorz B. Prokopski [*] This is not ideal, as this testing mode was designed to help porting *inlined engine* and not to track portability issues like arithmetic problems. It is a side effect, but this will help, becaue it'll catch pretty much all unexpected signals and will try to recover from them - thus allowing the tests to run further. The only problem would be that you'd have mixed "inlining failures" with "bytecode implementation failures". PS: Regardless of the impression you can get from the above description, finishing ARM port is *not* a problem per se. Given proper access to hardware, this should be an hour or a few hours at most of not very challenging work. -- 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 |
From: Fabien R. <re...@ne...> - 2004-05-13 11:42:44
|
I use --with-thread=direct on ARM and that doesn´t wotk. On my x86, that works with default options. I´ll try with --enable-debugging-features. Cheers, Fabien Chris Pickett wrote: > Hi Fabien, > > We're able to help you much better if you include any details that > might possibly be relevant. It's also helpful if you provide minimal > test cases (i.e. remove all the working stuff from a test case). I > take it that divide-by-zero is meant to print out "Infinity" for > floating point numbers, but that sablevm hangs. > > Did you try it with the --with-threading=switch and > --enable-debugging-features options passed to configure? Or just the > default (which would be the inlined-engine with signalling for > exceptions)? > > What architectures did you try it on? > > Does it work with Sun's java? > > The attached Arith.java works for me on x86 with inlined and > switch-debug engines. > > Cheers, > Chris > >------------------------------------------------------------------------ > >public class Arith >{ > public static void main(String[] args) > { > float a = 3; > float b = 0; > System.out.println(a / b); > } >} > > |
From: Chris P. <chr...@ma...> - 2004-05-13 11:24:20
|
Hi Fabien, We're able to help you much better if you include any details that might possibly be relevant. It's also helpful if you provide minimal test cases (i.e. remove all the working stuff from a test case). I take it that divide-by-zero is meant to print out "Infinity" for floating point numbers, but that sablevm hangs. Did you try it with the --with-threading=switch and --enable-debugging-features options passed to configure? Or just the default (which would be the inlined-engine with signalling for exceptions)? What architectures did you try it on? Does it work with Sun's java? The attached Arith.java works for me on x86 with inlined and switch-debug engines. Cheers, Chris |
From: Fabien R. <re...@ne...> - 2004-05-13 07:27:01
|
Hello, With Arith.java I have some problem with numbers : [verbose class: loading "Arith"] iadd [verbose class: loading "java/lang/Integer"] [verbose class: loading "java/lang/Number"] = 4 isub = 2 imul = 3 idiv = 3 irem = 0 ineg = -3 ladd [verbose class: loading "java/lang/Long"] = 4 lsub = 2 lmul = 3 ldiv = 3 lrem = 0 lneg = -3 fadd [verbose class: loading "java/lang/Float"] [verbose class: loading "java/lang/Double"] = 3.0 fsub = 3.0 fmul = 0.0 fdiv [verbose gc: previously allocated 16777180 bytes, surviving 56040 bytes, new heap is 16777216 bytes, gc time = 0 sec 9971 usec] [verbose gc: previously allocated 16777208 bytes, surviving 55972 bytes, new heap is 16777216 bytes, gc time = 0 sec 8790 usec] [verbose gc: previously allocated 16777192 bytes, surviving 55980 bytes, new heap is 16777216 bytes, gc time = 0 sec 9381 usec] Kaffe too has problems (crashs when there is a double) This is the source : public class Arith { static int add(int a, int b) { return a + b; } static int sub(int a, int b) { return a - b; } static int mul(int a, int b) { return a * b; } static int div(int a, int b) { return a / b; } static int rem(int a, int b) { return a % b; } static int neg(int a) { return -a; } static long add(long a, long b) { return a + b; } static long sub(long a, long b) { return a - b; } static long mul(long a, long b) { return a * b; } static long div(long a, long b) { return a / b; } static long rem(long a, long b) { return a % b; } static long neg(long a) { return -a; } static float add(float a, float b) { return a + b; } static float sub(float a, float b) { return a - b; } static float mul(float a, float b) { return a * b; } static float div(float a, float b) { return a / b; } static float rem(float a, float b) { return a % b; } static float neg(float a) { return -a; } static double add(double a, double b) { return a + b; } static double sub(double a, double b) { return a - b; } static double mul(double a, double b) { return a * b; } static double div(double a, double b) { return a / b; } static double rem(double a, double b) { return a % b; } static double neg(double a) { return -a; } public static void main (String[] args) { test_int (3, 1); test_long (3, 1); test_float (3, 0); test_double (3, 0); System.out.println("Done!"); } static void test_int(int a, int b) { char prefix = 'i'; System.out.println(prefix + "add"); System.out.println("\t= " + add(a,b)); System.out.println(prefix + "sub"); System.out.println("\t= " + sub(a,b)); System.out.println(prefix + "mul"); System.out.println("\t= " + mul(a,b)); System.out.println(prefix + "div"); System.out.println("\t= " + div(a,b)); System.out.println(prefix + "rem"); System.out.println("\t= " + rem(a,b)); System.out.println(prefix + "neg"); System.out.println("\t= " + neg(a)); } static void test_long(long a, long b) { char prefix = 'l'; System.out.println(prefix + "add"); System.out.println("\t= " + add(a,b)); System.out.println(prefix + "sub"); System.out.println("\t= " + sub(a,b)); System.out.println(prefix + "mul"); System.out.println("\t= " + mul(a,b)); System.out.println(prefix + "div"); System.out.println("\t= " + div(a,b)); System.out.println(prefix + "rem"); System.out.println("\t= " + rem(a,b)); System.out.println(prefix + "neg"); System.out.println("\t= " + neg(a)); } static void test_float(float a, float b) { char prefix = 'f'; System.out.println(prefix + "add"); System.out.println("\t= " + add(a,b)); System.out.println(prefix + "sub"); System.out.println("\t= " + sub(a,b)); System.out.println(prefix + "mul"); System.out.println("\t= " + mul(a,b)); System.out.println(prefix + "div"); System.out.println("\t= " + div(a,b)); System.out.println(prefix + "rem"); System.out.println("\t= " + rem(a,b)); System.out.println(prefix + "neg"); System.out.println("\t= " + neg(a)); } static void test_double(double a, double b) { char prefix = 'd'; System.out.println(prefix + "add"); System.out.println("\t= " + add(a,b)); System.out.println(prefix + "sub"); System.out.println("\t= " + sub(a,b)); System.out.println(prefix + "mul"); System.out.println("\t= " + mul(a,b)); System.out.println(prefix + "div"); System.out.println("\t= " + div(a,b)); System.out.println(prefix + "rem"); System.out.println("\t= " + rem(a,b)); System.out.println(prefix + "neg"); System.out.println("\t= " + neg(a)); } } If someone has an idea ... Cheers, Fabien |
From: David <db...@cs...> - 2004-05-12 08:12:04
|
On Tue, May 11, 2004 at 10:04:47AM -0400, Etienne Gagnon wrote: > Hi folks, >=20 > So, is there anything holding this release? Hmmm... oh yes!... We=20 > lack an appropriate NEWS release. I have proven myself not to be very=20 > good at doing a satisfying job on this, according to some people, so,=20 > please send your proposal ASAP. :-) >=20 yes... I just notice that I get: checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes ./configure: line 19644: test: too many arguments checking for ffi_prep_cif in -lffi... yes checking for lt_dlinit in -lltdl... yes I get this on Gentoo/ppc. Okay on Debian/x86. Anyone else have this?=20 I looked into ./configure and it seems to be occuring in macro generated code... for libtool I think. BTW, about arch, I will ci soon: - changes to build on FreeBSD out-of-the-box - signals enable on FreeBSD and Linux/ppc, disabled explicitly on Darwin/ppc Also, Solaris/sparc works for exceptions. If someone knows the $host string let me know otherwise, will check tomorrow. David --- 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 |
From: Grzegorz B. P. <ga...@de...> - 2004-05-12 04:40:49
|
On (11/05/04 23:50), David B?langer wrote: > > Hi, > > I would like to suggest to have errors on warning on by default for the > staging branch for platforms where warnings should not occur: > Linux on ppc, x86 and maybe other CPU archs. I think only on ppc and x86. If I recall correctly none of the others compiles w/o warnings. I'd attribute it to GCC though. > On other platforms, it would be off by default. > > Sometimes warnings are difficult to see through the output. > > What do you think? Good idea. We already have --disable-errors-on-warnings which are useful if you turn on debug mode no non-intel, non-ppc platform. I guess you could build upon that. Just try to avoid things we have to switch while migrating code from staging to bugfree and further. I'd suggest you use something like that: case $PACKAGE_VERSION in staging*) case $host in i*86*-*-gnu) turn on errors on warnings ;; powerpc-*) turn on errors on warings ;; ... esac ... esac Looking at generated ./configure, it seems that you could as well use $VERSION or $RELEASE in place of $PACKAGE_VERSION. Not sure which one would be the best choice. HTH GBP -- 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 |
From: David <db...@cs...> - 2004-05-12 03:52:19
|
Hi, I would like to suggest to have errors on warning on by default for the staging branch for platforms where warnings should not occur: Linux on ppc, x86 and maybe other CPU archs. On other platforms, it would be off by default. Sometimes warnings are difficult to see through the output. What do you think? David --- 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 |
From: David <db...@cs...> - 2004-05-12 03:32:56
|
Hi, Today, Christian and I downloaded the SableVM-CP snapshot (since sometimes autoconf etc. difficult... on non-Linux). To my surprise, the snapshot is actually a snapshot of the svn including the .svn etc. I thought that snapshot would have been like a release (i.e. no .svn repository and the Makefile.in and ./configure generated etc.). I thought the goal of the snapshots was to provide to the user a more recent SableVM version to the *user* without requiring him or her to install the autoconf etc. What do you think? David --- 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 |
From: David <db...@cs...> - 2004-05-12 03:22:52
|
On Tue, May 11, 2004 at 10:27:46PM -0400, Grzegorz B. Prokopski wrote: >=20 > 2. At compile time I am getting a few dozens of such warnings: >=20 > In file included from libsablevm.c:113: > java_io_VMObjectStreamClass.c:24: warning: static declaration for > `Java_java_io_VMObjectStreamClass_hasClassInitializer' follows > non-static >=20 > Am I the only one seeing them? That'd be a surprise. > $ gcc --version > gcc (GCC) 3.3.3 (Debian 20040429) >=20 > Current Debian unstable. >=20 No, same thing here on Gentoo. I suspect these are due to recent changes of adding the static modifier to the function definition (in java_*.c). However their declaration in the java_*.h do not have it. The java_*.h are automatically generated... so we need to automatically add it to the java_*.h when they get regenerated. I guess we would need some script to do that. It may be a good idea to have a "make jni_headers" to regenerate them and make sure the "static" is added. They don't get changed often but it would help. David --- 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 |
From: David <db...@cs...> - 2004-05-12 03:09:54
|
On Tue, May 11, 2004 at 10:27:46PM -0400, Grzegorz B. Prokopski wrote: > On (11/05/04 10:04), Etienne Gagnon wrote: > > Hi folks, > >=20 > > So, is there anything holding this release? Hmmm... oh yes!... We=20 > > lack an appropriate NEWS release. I have proven myself not to be ver= y=20 > > good at doing a satisfying job on this, according to some people, so,= =20 > > please send your proposal ASAP. :-) >=20 > Please take a look at what I've just copied from my sandbox to >=20 > svn cat \ > svn://svn.sablevm.org/sablevm/branches/staging/doc/release_mail.txt >=20 > Improvements are welcome. >=20 >=20 Looks good! Well presented. You may want to add that we are now using the (new) VMProcess/Process from CP instead of our own implementation. CP provides a complete implementation whereas our implementation was providing basic functionality. David --- 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 |
From: Chris P. <chr...@ma...> - 2004-05-12 02:58:51
|
Grzegorz B. Prokopski wrote: > On (11/05/04 10:04), Etienne Gagnon wrote: > >>Hi folks, >> >>So, is there anything holding this release? Hmmm... oh yes!... We >>lack an appropriate NEWS release. I have proven myself not to be very >>good at doing a satisfying job on this, according to some people, so, >>please send your proposal ASAP. :-) > > > Please take a look at what I've just copied from my sandbox to > > svn cat \ > svn://svn.sablevm.org/sablevm/branches/staging/doc/release_mail.txt > > Improvements are welcome. The following sentence is redundant, otherwise it looks fine. So, in general, the "staging" code is very robust. At some point soonish (either before the end of the summer or before 1.2.0) I plan on getting some regression testing stuff into staging (it will require the user to download benchmarks separately). Cheers, Chris |
From: Grzegorz B. P. <ga...@de...> - 2004-05-12 02:38:16
|
On (11/05/04 10:04), Etienne Gagnon wrote: > Hi folks, > > So, is there anything holding this release? Hmmm... oh yes!... We > lack an appropriate NEWS release. I have proven myself not to be very > good at doing a satisfying job on this, according to some people, so, > please send your proposal ASAP. :-) Please take a look at what I've just copied from my sandbox to svn cat \ svn://svn.sablevm.org/sablevm/branches/staging/doc/release_mail.txt Improvements are welcome. Other than this - I also built sablevm and I keep getting two kinds of warnings which I don't like: 1. At autogen.sh time: automake: src/libsablevm/Makefile.am: not supported: source file `inlinability/inlined_alpha.h' is in subdirectory for each src/lib/sablevm/inlinablity/inlined_*.h file. But I think this is because of older autotools on my machine. I removed src/libsablevm/inlinabiliyt/Makefile and moved the logic back to src/libsablevm/Makefile using glue and I had *no* warnings like that. It compiles well though, so I am just mentioning this for completness. 2. At compile time I am getting a few dozens of such warnings: In file included from libsablevm.c:113: java_io_VMObjectStreamClass.c:24: warning: static declaration for `Java_java_io_VMObjectStreamClass_hasClassInitializer' follows non-static Am I the only one seeing them? That'd be a surprise. $ gcc --version gcc (GCC) 3.3.3 (Debian 20040429) Current Debian unstable. HTH GBP -- 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 |
From: David <db...@cs...> - 2004-05-11 16:39:49
|
On Tue, May 11, 2004 at 10:04:47AM -0400, Etienne Gagnon wrote: > Hi folks, >=20 > So, is there anything holding this release? Hmmm... oh yes!... We=20 > lack an appropriate NEWS release. I have proven myself not to be very=20 > good at doing a satisfying job on this, according to some people, so,=20 > please send your proposal ASAP. :-) >=20 Hi, SableVM now should build out-of-box on Darwin(OS X)/ppc but not with signals for exception, it segfaults. If you want to disable it by default, the host string is: powerpc-apple-darwin* and you enable them for powerpc-*. So I guess you need: powerpc-*-gnu. On FreeBSD, there are still a few issues to solve. Basically, instead of linking libpthread, we have to pass the -pthread option to gcc so it links -lc_r (reentrant libc + pthread function) instead of libc. Even with that, there were a few issues. It may take some time to fix these as I have to update several autoconf , subversion etc. on these system. So I think we should still go ahead with the release. David --- 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 |
From: Etienne G. <gag...@uq...> - 2004-05-11 14:11:59
|
Hi folks, So, is there anything holding this release? Hmmm... oh yes!... We lack an appropriate NEWS release. I have proven myself not to be very good at doing a satisfying job on this, according to some people, so, please send your proposal ASAP. :-) Thanks in advanced, Etienne -- Etienne M. Gagnon, Ph.D. http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
From: David <db...@cs...> - 2004-05-07 16:25:12
|
On Fri, May 07, 2004 at 02:51:26AM -0400, Grzegorz B. Prokopski wrote: > On (03/05/04 22:08), Etienne Gagnon wrote: > > Hi David, > >=20 > > David B?langer wrote: > > >I don't know how it is on OpenBSD but with FreeBSD, I have to use > > >gm4. > >=20 > > It's the same. > >=20 > > >In configure.ac in my sandbox, I have this line: > > >AC_CHECK_PROGS([M4],[gm4 m4],[none],[$PATH]) > > >It does not check the GNUness of the m4 program but it will used gm4= if > > >found, otherwise check for m4. If neither gm4 nor m4 is found, will= set > > >M4 to none. I guess ideally would need some if stmt for the none ca= se. > >=20 > > We need 2 things: > >=20 > > 1- Check for GNU M4's name and set $(M4) to it. If it's not found, > > configure should fail. I guess, configure should also be able > > to accept a pre-set $(M4) environment variable as override. > >=20 > > 2- Do something similar with "-lrt", which is giving me a hell of a > > time. Configure should figure by itself whether it is needed or > > not. >=20 > I've just commited this into "staging": > * -lrt only for Solaris, > * -lpthread not for Darwin (-lc_r instead), > * try $M4, gm4 and m4, issue warning if -P doesn't work, > * -no-undefined for Cygwin/MinGW (but we still need to fix classpath) >=20 > To Etienne and David: could you please try these on *BSD and Darwin and > tune the settings if needed? Hi, I am currently reinstalling OS X and I am not quite done. So there may be some delay for the test but I will try to do it today. The -lc_r instead of -lpthread is on FreeBSD and not Darwin. Darwin dit not like the -lrt. I will do some tests and fix it. Darwin has a single libSystem and all libc, libm etc. are only symlinks to libSystem. So all libs works on Darwin except -lrt as it does not exist and there is no librt symlink to libSystem. David >=20 > HTH >=20 > GBP >=20 > PS: I also noticed that InliningException disappeared somehow from > sablevm-classpath, not sure why. >=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 --- 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 |
From: Grzegorz B. P. <ga...@de...> - 2004-05-07 07:27:06
|
On (03/05/04 22:08), Etienne Gagnon wrote: > Hi David, > > David B?langer wrote: > >I don't know how it is on OpenBSD but with FreeBSD, I have to use > >gm4. > > It's the same. > > >In configure.ac in my sandbox, I have this line: > >AC_CHECK_PROGS([M4],[gm4 m4],[none],[$PATH]) > >It does not check the GNUness of the m4 program but it will used gm4 if > >found, otherwise check for m4. If neither gm4 nor m4 is found, will set > >M4 to none. I guess ideally would need some if stmt for the none case. > > We need 2 things: > > 1- Check for GNU M4's name and set $(M4) to it. If it's not found, > configure should fail. I guess, configure should also be able > to accept a pre-set $(M4) environment variable as override. > > 2- Do something similar with "-lrt", which is giving me a hell of a > time. Configure should figure by itself whether it is needed or > not. I've just commited this into "staging": * -lrt only for Solaris, * -lpthread not for Darwin (-lc_r instead), * try $M4, gm4 and m4, issue warning if -P doesn't work, * -no-undefined for Cygwin/MinGW (but we still need to fix classpath) To Etienne and David: could you please try these on *BSD and Darwin and tune the settings if needed? HTH GBP PS: I also noticed that InliningException disappeared somehow from sablevm-classpath, not sure why. -- 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 |
From: Chris P. <chr...@ma...> - 2004-05-06 13:58:03
|
Hi Fabien, Assuming you only specified --prefix to configure when installing SableVM: sablevm \ --property=sablevm.boot.class.path=${PREFIX}/share/sablevm/sablevm-classpath/ --property=sablevm.boot.library.path=${PREFIX}/lib/sablevm/sablevm-classpath/ HelloWorld should work (watch out for line wrapping or lack thereof in the above). If things are in different places, you just need to specify the two different sablevm-classpath directories. Cheers, Chris Fabien Renaud wrote: > Hi, > > If I don´t set boot.class.path I have "cannot create vm" because > directories are not the same than the machine where I cross compiled > (and sanlevm wants to search in these). > > My command : > sablevm -Y -c "/home/java/tests" -p > "sablevm.boot.class.path=/home/java/classpath" -p > "sablevm.verbose.methods=true" -p > "sablevm.boot.library.path=/home/java/sablevm/lib" helloworld > And I do this command in /home/java/tests where is my helloworld.class > > Fabien > > David Bélanger wrote: > > >>On Tue, May 04, 2004 at 10:58:58AM +0200, Fabien Renaud wrote: >> >> >> >>>Soon, I´ll be able to run QT embedded applications but ... I have a >>>little problem. >>>I set -p "sablevm.boot.class.path=my_path" and -c >>>"my_path_where_there_is_helloworld.class" >>>There is no problem but it doen´t check in >>>"my_path_where_there_is_helloworld.class" so he cannot find helloworld.class >>>If i move my helloworld.class in "my_path" that´s works well. >>> >>> >>> >> >>Hi, >> >>I cannot see what could be wrong unless the path is not specified >>correctly. If you don't specify the boot class path and use the default >>one, do you get the same error? >> >>Please copy and paste the full command line to report problems. >>Sometimes it happens to me what I think is correct but I don't do what I >>think I am doing and then it doesn't work... >> >>David >> >>--- >> >>David Bélanger >>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 >> >> >> >> > > > > > > ------------------------------------------------------- > This SF.Net email is sponsored by Sleepycat Software > Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to > deliver higher performing products faster, at low TCO. > http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 > _______________________________________________ > Sablevm-developer mailing list > Sab...@li... > https://lists.sourceforge.net/lists/listinfo/sablevm-developer > |
From: Fabien R. <re...@ne...> - 2004-05-06 07:01:48
|
Hi, If I don´t set boot.class.path I have "cannot create vm" because directories are not the same than the machine where I cross compiled (and sanlevm wants to search in these). My command : sablevm -Y -c "/home/java/tests" -p "sablevm.boot.class.path=/home/java/classpath" -p "sablevm.verbose.methods=true" -p "sablevm.boot.library.path=/home/java/sablevm/lib" helloworld And I do this command in /home/java/tests where is my helloworld.class Fabien David Bélanger wrote: >On Tue, May 04, 2004 at 10:58:58AM +0200, Fabien Renaud wrote: > > >>Soon, I´ll be able to run QT embedded applications but ... I have a >>little problem. >>I set -p "sablevm.boot.class.path=my_path" and -c >>"my_path_where_there_is_helloworld.class" >>There is no problem but it doen´t check in >>"my_path_where_there_is_helloworld.class" so he cannot find helloworld.class >>If i move my helloworld.class in "my_path" that´s works well. >> >> >> > >Hi, > >I cannot see what could be wrong unless the path is not specified >correctly. If you don't specify the boot class path and use the default >one, do you get the same error? > >Please copy and paste the full command line to report problems. >Sometimes it happens to me what I think is correct but I don't do what I >think I am doing and then it doesn't work... > >David > >--- > >David Bélanger >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 > > > > |
From: Grzegorz B. P. <ga...@de...> - 2004-05-06 00:16:15
|
On (05/05/04 13:53), Etienne Gagnon wrote: > Grzegorz B. Prokopski wrote: > >-lrt (and others of that kind) is on my todo list. I haven't looked at > >M4 yet but I am open for suggestions how it should look like. I have > >a few other small items for M4 ex. the last architecture that still > >bothers me: ARM :-) > > To summarize: > > * I'd like configure to do something like: > > ## Pseudo-code! > if (-lrt is required) ## This is a configure test that tries to > ## compile a little C program witout -lrt Unless you or somebody else is able to provide a good explanation or a C program that fails or not, depending on the need for sablevm to use -lrt, I'd say that we have only one special case of OS which needs -lrt, which is Solaris. So we'll make NO -lrt the default and -lrt special case for Solaris. I googled a bit for "librt" and there's no clues as to what Solaris keeps in their librt that we need... Under linux it's some stuff we definitely don't need. I remember that we had similar issue with -lpthread which in turn was NOT tolerated by OS X and instead(?) David used -lc_r. So again I'd make -lpthread the default and OS X a special case with different libs. > * I'd like configure to also do something like: > > # Pseudo-code > if ($M4 is not defined) > if (m4 is GNU m4) ## This should actually be a configure test > ## that executes m4 and looks for GNU m4 specific > ## behavior > M4 = m4 > else if (gm4 is GNU m4) > M4 = gm4 > endif > endif I'd say that we try 1. $M4 (we just use it if set) 2. gm4 (we just use it if available, unless somebody tells me that there exist some other program called gm4 which is not GNU m4) 3. m4 (we fallback to this no matter what, as currently) We do NOT want to fail if m4 is not found or it is not gnu-compatible m4, because we neither want nor have m4 dependency at build time, that is unless you build from SVN or you've modified some files that other files are generated from. What we might do is to check whether the m4 we've choosen fails on "m4 -P ..." or not and generate a BIG warning at configure time. There will be additional @no_undefined@ needed for Cygwin (and MinGW one day) - it can be handled the same way. This is what I am going to implement. If somebody has a better idea (and backed with good clues as to how it should be implemented) please speak up. Cheers, GBP PS: Please see this message and the following thread for reference: http://thread.gmane.org/gmane.comp.java.vm.sablevm.devel/511 -- 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 |