sablevm-developer Mailing List for SableVM (Page 21)
Brought to you by:
egagnon
Menu
▾
▴
sablevm-developer — SableVM developer mailing list
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-02-15 14:51:29
|
Chris Pickett wrote: > I am pretty sure I can get more detailed info if I set things up; I'm > just sending this mail to report that we have a usable C profiler now. Super! -- 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-02-15 14:51:14
|
Chris Pickett wrote: >> 2. Updated http://devel.sablevm.org/docs/INSTALL.txt document, which >> serves as both: release notes and installation instruction, and put it >> into sablevm/staging as INSTALL-DEVEL text file (made it included in >> the "dist" tarball - should be removed on migration to trunk!). > > > Seems like common practice would be to put a single INSTALL file in the > top level of sablevm. I agree with the INSTALL file. Another thing: I do really think that "./configure ; make ; make install" should work out-of-the-box for sablevm-x.y.z.tar.gz and for sablevm-classpath-x.y.z.tar.gz. Currently, it is broken for sablevm-classpath (as you need to pass specific configure options to get a sablevm usable build). Assume that the typical user WILL NOT read the README file nor the INSTALL files and will simply go ahead and type the standard commands above. [Alternatively, you could make sure that "./configure" fails for sablevm-classpath, and issues a message inviting the user to read the README and INSTALL files...] The worst situation is if a user does the standard commands, gets no build error message, yet gets "could not start vm" when trying to run HelloWorld. What do you think? 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-02-15 14:40:18
|
Hi Greg, Only developers that have done the FSF paperwork thing (e.g. copyright assignment) have write access to sablevm-classpath. So, both David and I have access to it for the time being. I'll let David take care of your patch (and see if it can be accepted according to the FSF's contribution rules). Etienne Grzegorz B. Prokopski wrote: > Hi, > > I am not sure if David is able to do the below operations, so it's > most probably to Etienne. I couldn't do them (lack of permissions). > > 1. Please apply the attached patch to classpath/staging. > 2. Remove empty classpath/bugfree directory (yup, its needed) > svn del > svn+ssh://svn.sablevm.org/public/sablevm-classpath/branches/bugfree > 3. Copy current classpath/staging into classpath/bugfree > svn cp > svn+ssh://svn.sablevm.org/public/sablevm-classpath/branches/staging > svn+ssh://svn.sablevm.org/public/sablevm-classpath/branches/bugfree > 4. svn co > svn+ssh://svn.sablevm.org/public/sablevm-classpath/branches/bugfree > sablevm-classpath-bugfree > 5. Change version number in configure.ac in AC_INIT to [1.1.0] > 6. Commit the changes to classpath/bugfree > > [the below one is surely for Etienne] > 7. Make tags of 1.1.0 for sablevm/bugfree and classpath/bugfree. > (I prepared the sablevm/bugfree already) > > We should then checkout these tags, run "make distcheck" on them > (I fixed that for both of them, so I know it will work), build and run > SableVM from these tarballs. [*] If everything is fine this will > become 1.1.0 development release. > > Cheers, > > Grzegorz B. Prokopski > > [*] You will need tar from Debian *testing* for "make distcheck"! > -- Etienne M. Gagnon, Ph.D. http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
|
From: Chris P. <chr...@ma...> - 2004-02-15 08:03:35
|
Grzegorz B. Prokopski wrote: > Hi! > > So what has been done and how it looks now? FYI: > > 1. Chris used benchmarks to assure there's no functional regressions > in staging, as compared to 1.0.9. I checked the SPECjvm98, JOlden, and JGF single- and multi-threaded suites, on i686, with gcc-2.95.4 for 1.0.9 and gcc-3.3.2 for staging-r1575, with the switch-debug and inlined interpreters only, and the "correctness" is only against the stdout/stderr of a single trial run. We still need to work on a multiple-architecture regression suite that actually tests all the compilation modes if we want to be really sure in the future. But at least there don't appear to be any fundamental regressions. > 2. Updated http://devel.sablevm.org/docs/INSTALL.txt document, which > serves as both: release notes and installation instruction, and put it > into sablevm/staging as INSTALL-DEVEL text file (made it included in > the "dist" tarball - should be removed on migration to trunk!). Seems like common practice would be to put a single INSTALL file in the top level of sablevm. Other than that it's all great! Cheers, Chris |
|
From: Chris P. <chr...@ma...> - 2004-02-15 07:53:16
|
Grzegorz B. Prokopski wrote: >>Seems okay. Except that staging changes frequently, so I suspect that >>when the version really does matter, we'll end up referring to it by >>revision number (e.g. staging-r1575). I'm not even sure if `1.0.9' or >>`1.1.0' is necessary in the name ... isn't it just obvious that staging >>is changes against bugfree at all times, which in turn is changes >>against the latest release?> > > I tried to use the subversion's magic string substitution or even the > svnversion utility to put the revision number there, but I am afraid > it can't be done easily, unless we want to generate configure.ac from > some other file or sth. like that (hmm... maybe use sed and generate > it from itself in ./autogen.sh and on make dist? feel free to try it!) Okay, I'll try it if I need a break :) It seems like it could be quite useful ... > But I am sure staging shouldn't claim to be just "1.0.9" or any other > release. I wanted to put "staging" name initialy, but I guess > "1.0.9+staging" or (hopefuly soon) "1.1.0+staging" should at least give > some more informations if we ask a user to do 'sablevm -V' for us. Well, /only/ because I find this oddly interesting ... I see it as: staging == 1.0.9 + new changes == 1.0.9 + (staging - 1.0.9) == staging >>I think staging needs to be frozen with respect to SableVM functionality >>once the regression tests have started until the big merge into bugfree >>is made. But then I don't know -- do you want critical fixes to bugfree I meant, do you think the freeze should expire once the merge to bugfree is complete? Or once the release is made? Or once something else? It sounds like you're saying once the merge is complete. Cheers, Chris |
|
From: Grzegorz B. P. <ga...@de...> - 2004-02-15 01:51:14
|
Hi! So what has been done and how it looks now? FYI: 1. Chris used benchmarks to assure there's no functional regressions in staging, as compared to 1.0.9. 2. Updated http://devel.sablevm.org/docs/INSTALL.txt document, which serves as both: release notes and installation instruction, and put it into sablevm/staging as INSTALL-DEVEL text file (made it included in the "dist" tarball - should be removed on migration to trunk!). 3. Fixed make dist for sablevm (and Mark helped w/ classpath's dist) 3. Merged SableVM/staging into bugfree and did all the steps for it as http://devel.sablevm.org/wiki/ReleaseProcess describes. 4. Couldn't do changes to our classpath repo so requested David or Etienne to do them (and to make the 1.1.0 release tags). Cheers, 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-02-15 01:47:38
|
> > Tried both automake 1.8.2 and 1.7.9. > > autoconf 2.59 and libtool 1.5.2 > > Strange it now suddenly all works. > I don't know what changed though. But with both automake 1.8.2 and 1.7.9 > make distcheck works now. Yeah! Yup, downgrade of tar helped. We're at release 1.1.0 point now. Thanks a lot! 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-02-15 01:47:21
|
Hi, I am not sure if David is able to do the below operations, so it's most probably to Etienne. I couldn't do them (lack of permissions). 1. Please apply the attached patch to classpath/staging. 2. Remove empty classpath/bugfree directory (yup, its needed) svn del svn+ssh://svn.sablevm.org/public/sablevm-classpath/branches/bugfree 3. Copy current classpath/staging into classpath/bugfree svn cp svn+ssh://svn.sablevm.org/public/sablevm-classpath/branches/staging svn+ssh://svn.sablevm.org/public/sablevm-classpath/branches/bugfree 4. svn co svn+ssh://svn.sablevm.org/public/sablevm-classpath/branches/bugfree sablevm-classpath-bugfree 5. Change version number in configure.ac in AC_INIT to [1.1.0] 6. Commit the changes to classpath/bugfree [the below one is surely for Etienne] 7. Make tags of 1.1.0 for sablevm/bugfree and classpath/bugfree. (I prepared the sablevm/bugfree already) We should then checkout these tags, run "make distcheck" on them (I fixed that for both of them, so I know it will work), build and run SableVM from these tarballs. [*] If everything is fine this will become 1.1.0 development release. Cheers, Grzegorz B. Prokopski [*] You will need tar from Debian *testing* for "make distcheck"! -- 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-02-15 01:47:21
|
W li=B6cie z sob, 14-02-2004, godz. 12:30, Chris Pickett pisze:=20 > Grzegorz B. Prokopski wrote: > > Hi all! > >=20 > > Shortly. > > - Take a look at http://devel.sablevm.org/wiki/ReleaseProcess > > That's more less what I had in mind. Comments? > >=20 > > - staging has now version '1.0.9+staging' - it should be less confusi= ng > > (we'll make it 1.1.0+staging after 1.1.0 release, I guess). >=20 > Seems okay. Except that staging changes frequently, so I suspect that=20 > when the version really does matter, we'll end up referring to it by=20 > revision number (e.g. staging-r1575). I'm not even sure if `1.0.9' or=20 > `1.1.0' is necessary in the name ... isn't it just obvious that staging= =20 > is changes against bugfree at all times, which in turn is changes=20 > against the latest release? Then we never have to worry about naming=20 > the staging version. Similarly for sandboxes (my version is `chris')=20 > and bugfree. I don't know ... it's not a big deal. I tried to use the subversion's magic string substitution or even the svnversion utility to put the revision number there, but I am afraid it can't be done easily, unless we want to generate configure.ac from some other file or sth. like that (hmm... maybe use sed and generate it from itself in ./autogen.sh and on make dist? feel free to try it!) But I am sure staging shouldn't claim to be just "1.0.9" or any other release. I wanted to put "staging" name initialy, but I guess "1.0.9+staging" or (hopefuly soon) "1.1.0+staging" should at least give some more informations if we ask a user to do 'sablevm -V' for us. > I think staging needs to be frozen with respect to SableVM functionalit= y=20 > once the regression tests have started until the big merge into bugfree= =20 > is made. But then I don't know -- do you want critical fixes to bugfre= e=20 I agree. You should go and modify ReleaseProcess wiki page w/ this info. Other ideas/improvements are also appreciated. I tried to make it more a "checklist" so that we didn't forget about anything, and a guideline. 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 |
|
From: Mark W. <ma...@kl...> - 2004-02-14 23:24:20
|
Hi, On Sat, 2004-02-14 at 18:46, Mark Wielaard wrote: > > > P.S. I get much further now, but at the end I get the following error= : > > >=20 > > > ERROR: files left in build directory after distclean: > > > ./native/fdlibm/DEPDIR > > > ./native/fdlibm/=3D > > > [...] > > > ./native/jni/gtk-peer/DEPDIR > > > ./native/jni/gtk-peer/=3D > > > make[1]: *** [distcleancheck] Error 1 > > > make[1]: Leaving directory > > > `/home/mark/src/classpath-obj/classpath-0.07+cvs/_build' > > > make: *** [distcheck] Error 2 > > >=20 > > > Still investigating. > >=20 > > Hmmm, I dont get that either. What versions of autoconf/automake/libtoo= l > > are you using ? >=20 > Tried both automake 1.8.2 and 1.7.9. > autoconf 2.59 and libtool 1.5.2 Strange it now suddenly all works. I don't know what changed though. But with both automake 1.8.2 and 1.7.9 make distcheck works now. Yeah! Cheers, Mark |
|
From: Chris P. <chr...@ma...> - 2004-02-14 19:49:02
|
Chris Pickett wrote: > Hi, > > Has anybody had any luck with profiling SableVM? I need to do this to > cut down on the overhead of my speculative multithreading work, because > currently benchmarks take too long to execute for an efficient > write-compile-test-debug cycle. So, after more trying with gprof, OProfile, and FunctionCheck ... I spoke to Clark, and he soon found qprof, released under the GPL by HP (Google finds different things for different people). It works great! Even with just a simple install, I get: $ qprof_start $ sablevm-chris-switch-spmt-debug -Y DmdNoStrings random2000.dg Number of components: 399 qprof: /home/research/ccl/cpicke/temp/bin/sablevm-chris-switch-spmt-debug: 5710 samples, 5710 counts [0x4000dea4] 2 ( 0%) libsablevm.so.1 286 ( 5%) libsablevm.so.1(_svmf_buffer_create) 2 ( 0%) libsablevm.so.1(_svmf_buffer_validate) 40 ( 1%) libsablevm.so.1(_svmf_buffer_commit) 51 ( 1%) libsablevm.so.1(_svmf_buffer_destroy) 4 ( 0%) libsablevm.so.1(_svmf_buffer_status_ok) 1 ( 0%) libsablevm.so.1(_svmf_predictor_read_jint) 2 ( 0%) libsablevm.so.1(_svmf_predictor_write_jint) 29 ( 1%) libpthread.so.0(__pthread_mutex_trylock) 8 ( 0%) libpthread.so.0(__pthread_mutex_lock) 4 ( 0%) libpthread.so.0(__pthread_mutex_unlock) 40 ( 1%) libc.so.6(malloc) 127 ( 2%) libc.so.6(__libc_free) 29 ( 1%) libc.so.6(calloc) 17 ( 0%) libc.so.6(__default_morecore) 4 ( 0%) libc.so.6(strncpy) 1 ( 0%) libc.so.6(memset) 117 ( 2%) libc.so.6(memcpy) 4804 ( 84%) libc.so.6(__open) 3 ( 0%) libc.so.6(brk) 136 ( 2%) libc.so.6(sbrk) 3 ( 0%) $ qprof_stop Which is just the kind of thing I was looking for! (this is with qprof-0.5 and libunwind-0.96, both available from HP -- you need to put a symlink to or extract libunwind-0.96 in the qprof-0.5 directory for qprof's make to enable libunwind functionality) I am pretty sure I can get more detailed info if I set things up; I'm just sending this mail to report that we have a usable C profiler now. Cheers, Chris |
|
From: Michael K. <kon...@gm...> - 2004-02-14 19:07:23
|
On Sat, Feb 14, 2004 at 06:46:54PM +0100, Mark Wielaard wrote: > Hi, > > On Sat, 2004-02-14 at 17:53, Michael Koch wrote: > > Ah, yes. There is discussion about buggy tar in Debian unstable and > > broken debs on debian-devel lately. > > OK, then we are probably bitten by that one. > Do you have a bug number? I couldn't find it immediately on > bugs.debian.org. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=230910 I dont know if its related but it seems when downgrading helps you. Michael |
|
From: Grzegorz B. P. <ga...@de...> - 2004-02-14 18:21:47
|
Hello Paul! W li=B6cie z wto, 10-02-2004, godz. 10:51, Paul Cockshott pisze:=20 > I am trying to build a version of the sable vm for the sony ps2 in That's great! (What CPU does it have btw?) Which version of SableVM exactly? Original 1.0.9? Current staging? > I find that when I run autogen.sh I get a lot of error messages about > unquoted strings for JAPHAR_CLASSPATH etc. See this document and check whether you have all the needed versions of auto* tools installed. svn cat svn://svn.sablevm.org/sablevm/branches/staging/INSTALL-DEVEL > Is there a reliable release of sablevm with just a normal pre-built=20 > ./configure > ./make > ./make install > =20 > sequence available? This requires working 'make dist', which currently works for sablevm in staging so I could put up a tarball for you, BUT it doesn't seem to work for sablevm-classpath (see other mails from yesterday/today). I think that as soon as it's fixed - you can expect 1.1.0 release which naturally won't require you to run autogen.sh. But I'd rather suggest trying to figure out what is wrong and why autogen.sh doesn't work for you. Can you check the versions, as I said above, and can you provide full error output? Cheers, Grzegorz B. Prokopski --=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 |
|
From: Mark W. <ma...@kl...> - 2004-02-14 17:49:29
|
Hi, On Sat, 2004-02-14 at 17:53, Michael Koch wrote: > Ah, yes. There is discussion about buggy tar in Debian unstable and > broken debs on debian-devel lately. OK, then we are probably bitten by that one. Do you have a bug number? I couldn't find it immediately on bugs.debian.org. > > P.S. I get much further now, but at the end I get the following error: > >=20 > > ERROR: files left in build directory after distclean: > > ./native/fdlibm/DEPDIR > > ./native/fdlibm/=3D > > ./native/jni/classpath/DEPDIR > > ./native/jni/classpath/=3D > > ./native/jni/java-awt/DEPDIR > > ./native/jni/java-awt/=3D > > ./native/jni/java-io/DEPDIR > > ./native/jni/java-io/=3D > > ./native/jni/java-lang/DEPDIR > > ./native/jni/java-lang/=3D > > ./native/jni/java-net/DEPDIR > > ./native/jni/java-net/=3D > > ./native/jni/java-nio/DEPDIR > > ./native/jni/java-nio/=3D > > ./native/jni/java-util/DEPDIR > > ./native/jni/java-util/=3D > > ./native/jni/gtk-peer/DEPDIR > > ./native/jni/gtk-peer/=3D > > make[1]: *** [distcleancheck] Error 1 > > make[1]: Leaving directory > > `/home/mark/src/classpath-obj/classpath-0.07+cvs/_build' > > make: *** [distcheck] Error 2 > >=20 > > Still investigating. >=20 > Hmmm, I dont get that either. What versions of autoconf/automake/libtool > are you using ? Tried both automake 1.8.2 and 1.7.9. autoconf 2.59 and libtool 1.5.2 Cheers, Mark |
|
From: Chris P. <chr...@ma...> - 2004-02-14 17:31:53
|
Grzegorz B. Prokopski wrote: > Hi all! > > Shortly. > - Take a look at http://devel.sablevm.org/wiki/ReleaseProcess > That's more less what I had in mind. Comments? > > - staging has now version '1.0.9+staging' - it should be less confusing > (we'll make it 1.1.0+staging after 1.1.0 release, I guess). Seems okay. Except that staging changes frequently, so I suspect that when the version really does matter, we'll end up referring to it by revision number (e.g. staging-r1575). I'm not even sure if `1.0.9' or `1.1.0' is necessary in the name ... isn't it just obvious that staging is changes against bugfree at all times, which in turn is changes against the latest release? Then we never have to worry about naming the staging version. Similarly for sandboxes (my version is `chris') and bugfree. I don't know ... it's not a big deal. I think staging needs to be frozen with respect to SableVM functionality once the regression tests have started until the big merge into bugfree is made. But then I don't know -- do you want critical fixes to bugfree to happen on bugfree directly, and flow back into staging (or rather, be committed at the same time)? Because if not, it seems better to keep staging frozen until the actual release tag is made (I think freezing for the shortest amount of time is best). Anyway, whatever. In practice there are only a handful of developers, so it's not mission-critical whatever you do. The time spent figuring these things out and documenting them can offset the actual benefits. Chris |
|
From: Michael K. <kon...@gm...> - 2004-02-14 16:55:58
|
On Sat, Feb 14, 2004 at 05:40:39PM +0100, Mark Wielaard wrote:
> Hi,
>
> On Sat, 2004-02-14 at 14:04, Michael Koch wrote:
> > > > *** Semantic Error: A candidate for type
> > > > "TransformerFactoryConfigurationError" was found, but it is invalid and
> > > > needs to be fixed before this type will successfully compile.
> > > >
> > > >
> > > > I guess some .java files aren't included in the tarball? or...?
> > > >
> > > > Help w/ this issue would be greatly apprieciated.
> > >
> > > Ugh, so it isn't my setup :{
> > > I get the same with a clean "upstream" classpath.
> > > Somehow one of the gnu jaxp .java files ends up in the root build dir!?!
> > >
> > > I'll try to fix make distcheck for classpath soon (hopefully tonight).
> > >
> >
> > I do "make distcheck" on a daily basis in the daily build scripts on
> > Patrick Reali's server. They dont broke. I do this here locally too on a
> > regular basis and didnt broke.
> >
> > I think this error occurs because of the compiler used to compile to
> > bytecode is buggy or configure did something strange. classpath uses
> > jikes (1.18) here locally to compile to bytecode and this works great.
>
> It wasn't the compiler. It seems to be my version of tar !?!?!
> I just downgraded tar from 1.13.92-4 to 1.13.25-6
> (Debian unstable to Debian testing version) and everything works again.
>
> For some mysterious reason this newer version of tar puts
> classpath-0.07+cvs/external/jaxp/source/javax/xml/transform/TransformerFactoryConfigurationError.java
> in the tar file as plain "TransformerFactoryConfigurationError.java"
> without any directory path. Can someone confirm that downgrading tar
> helps.
>
> It sounds fishy, but maybe it is because this path is just one larger
> then 100 (101) characters. I read somewhere that tar handles file names
> longer then 100 chars special (and different depending on Posix/GNU/etc)
Ah, yes. There is discussion about buggy tar in Debian unstable and
broken debs on debian-devel lately.
> P.S. I get much further now, but at the end I get the following error:
>
> ERROR: files left in build directory after distclean:
> ./native/fdlibm/DEPDIR
> ./native/fdlibm/=
> ./native/jni/classpath/DEPDIR
> ./native/jni/classpath/=
> ./native/jni/java-awt/DEPDIR
> ./native/jni/java-awt/=
> ./native/jni/java-io/DEPDIR
> ./native/jni/java-io/=
> ./native/jni/java-lang/DEPDIR
> ./native/jni/java-lang/=
> ./native/jni/java-net/DEPDIR
> ./native/jni/java-net/=
> ./native/jni/java-nio/DEPDIR
> ./native/jni/java-nio/=
> ./native/jni/java-util/DEPDIR
> ./native/jni/java-util/=
> ./native/jni/gtk-peer/DEPDIR
> ./native/jni/gtk-peer/=
> make[1]: *** [distcleancheck] Error 1
> make[1]: Leaving directory
> `/home/mark/src/classpath-obj/classpath-0.07+cvs/_build'
> make: *** [distcheck] Error 2
>
> Still investigating.
Hmmm, I dont get that either. What versions of autoconf/automake/libtool
are you using ?
Michael
|
|
From: Mark W. <ma...@kl...> - 2004-02-14 16:43:12
|
Hi,
On Sat, 2004-02-14 at 14:04, Michael Koch wrote:
> > > *** Semantic Error: A candidate for type
> > > "TransformerFactoryConfigurationError" was found, but it is invalid a=
nd
> > > needs to be fixed before this type will successfully compile.
> > >=20
> > >=20
> > > I guess some .java files aren't included in the tarball? or...?
> > >=20
> > > Help w/ this issue would be greatly apprieciated.
> >=20
> > Ugh, so it isn't my setup :{
> > I get the same with a clean "upstream" classpath.
> > Somehow one of the gnu jaxp .java files ends up in the root build dir!?=
!
> >=20
> > I'll try to fix make distcheck for classpath soon (hopefully tonight).
> >=20
>
> I do "make distcheck" on a daily basis in the daily build scripts on
> Patrick Reali's server. They dont broke. I do this here locally too on a
> regular basis and didnt broke.
>=20
> I think this error occurs because of the compiler used to compile to
> bytecode is buggy or configure did something strange. classpath uses
> jikes (1.18) here locally to compile to bytecode and this works great.
It wasn't the compiler. It seems to be my version of tar !?!?!
I just downgraded tar from 1.13.92-4 to 1.13.25-6
(Debian unstable to Debian testing version) and everything works again.
For some mysterious reason this newer version of tar puts
classpath-0.07+cvs/external/jaxp/source/javax/xml/transform/TransformerFact=
oryConfigurationError.java
in the tar file as plain "TransformerFactoryConfigurationError.java"
without any directory path. Can someone confirm that downgrading tar
helps.
It sounds fishy, but maybe it is because this path is just one larger
then 100 (101) characters. I read somewhere that tar handles file names
longer then 100 chars special (and different depending on Posix/GNU/etc)
Cheers,
Mark
P.S. I get much further now, but at the end I get the following error:
ERROR: files left in build directory after distclean:
./native/fdlibm/DEPDIR
./native/fdlibm/=3D
./native/jni/classpath/DEPDIR
./native/jni/classpath/=3D
./native/jni/java-awt/DEPDIR
./native/jni/java-awt/=3D
./native/jni/java-io/DEPDIR
./native/jni/java-io/=3D
./native/jni/java-lang/DEPDIR
./native/jni/java-lang/=3D
./native/jni/java-net/DEPDIR
./native/jni/java-net/=3D
./native/jni/java-nio/DEPDIR
./native/jni/java-nio/=3D
./native/jni/java-util/DEPDIR
./native/jni/java-util/=3D
./native/jni/gtk-peer/DEPDIR
./native/jni/gtk-peer/=3D
make[1]: *** [distcleancheck] Error 1
make[1]: Leaving directory
`/home/mark/src/classpath-obj/classpath-0.07+cvs/_build'
make: *** [distcheck] Error 2
Still investigating.
|
|
From: Michael K. <kon...@gm...> - 2004-02-14 13:07:20
|
On Sat, Feb 14, 2004 at 11:17:25AM +0100, Mark Wielaard wrote:
> Hi,
>
> On Sat, 2004-02-14 at 09:43, Grzegorz B. Prokopski wrote:
> > but 'make distcheck' in classpath dies with this output:
> >
> > Found 2 semantic errors compiling
> > "../../external/jaxp/source/javax/xml/transform/TransformerFactory.java":
> >
> > 94. throws TransformerFactoryConfigurationError
> > ^----------------------------------^
> > *** Semantic Error: Type
> > javax.xml.transform.TransformerFactoryConfigurationError was not found.
> >
> >
> > 104. throw new
> > TransformerFactoryConfigurationError(e);
> > ^----------------------------------^
> > *** Semantic Error: A candidate for type
> > "TransformerFactoryConfigurationError" was found, but it is invalid and
> > needs to be fixed before this type will successfully compile.
> >
> > Found 3 semantic errors compiling
> > "../../external/jaxp/source/javax/xml/transform/ClassStuff.java":
> >
> > 141. throw new TransformerFactoryConfigurationError (e,
> > ^----------------------------------^
> > *** Semantic Error: A candidate for type
> > "TransformerFactoryConfigurationError" was found, but it is invalid and
> > needs to be fixed before this type will successfully compile.
> >
> >
> > 145. throw new TransformerFactoryConfigurationError (e,
> > ^----------------------------------^
> > *** Semantic Error: A candidate for type
> > "TransformerFactoryConfigurationError" was found, but it is invalid and
> > needs to be fixed before this type will successfully compile.
> >
> >
> > 149. throw new TransformerFactoryConfigurationError (e,
> > ^----------------------------------^
> > *** Semantic Error: A candidate for type
> > "TransformerFactoryConfigurationError" was found, but it is invalid and
> > needs to be fixed before this type will successfully compile.
> >
> >
> > I guess some .java files aren't included in the tarball? or...?
> >
> > Help w/ this issue would be greatly apprieciated.
>
> Ugh, so it isn't my setup :{
> I get the same with a clean "upstream" classpath.
> Somehow one of the gnu jaxp .java files ends up in the root build dir!?!
>
> I'll try to fix make distcheck for classpath soon (hopefully tonight).
>
> Cheers,
>
> Mark
>
> P.S. To the Classpath hackers. Please do a make distcheeck from time to
> time. Especially after you alter configure.ac, Makefile.am and/or added
> a file.
I do "make distcheck" on a daily basis in the daily build scripts on
Patrick Reali's server. They dont broke. I do this here locally too on a
regular basis and didnt broke.
I think this error occurs because of the compiler used to compile to
bytecode is buggy or configure did something strange. classpath uses
jikes (1.18) here locally to compile to bytecode and this works great.
Michael
|
|
From: Patrick C. <er...@ps...> - 2004-02-14 11:41:16
|
Also sprach Paul Cockshott zu "10.02.2004 16:51" Anno Domini: > I am trying to build a version of the sable vm for the sony ps2 in order > to port my vectorising compiler tool kit to it. The toolkit is built using > sablecc. > > I find that when I run autogen.sh I get a lot of error messages about > unquoted strings for JAPHAR_CLASSPATH etc. > Are you sure, that these are ERROR messages and not just warnings. aclocal of automake-1.8 warns about unquoted macro definitions, but these can be slightly ignored! -- Patrick Cernko | mailto:er...@er... | http://www.errror.de Quote of the Week: "Quis custodit custodes? Ceterum censeo Microsoftem esse delendam!" (anonyum) |
|
From: Mark W. <ma...@kl...> - 2004-02-14 10:19:49
|
Hi,
On Sat, 2004-02-14 at 09:43, Grzegorz B. Prokopski wrote:
> but 'make distcheck' in classpath dies with this output:
>=20
> Found 2 semantic errors compiling
> "../../external/jaxp/source/javax/xml/transform/TransformerFactory.java":
>=20
> 94. throws TransformerFactoryConfigurationError
> ^----------------------------------^
> *** Semantic Error: Type
> javax.xml.transform.TransformerFactoryConfigurationError was not found.
>=20
>=20
> 104. throw new
> TransformerFactoryConfigurationError(e);
> ^----------------------------------^
> *** Semantic Error: A candidate for type
> "TransformerFactoryConfigurationError" was found, but it is invalid and
> needs to be fixed before this type will successfully compile.
>=20
> Found 3 semantic errors compiling
> "../../external/jaxp/source/javax/xml/transform/ClassStuff.java":
>=20
> 141. throw new TransformerFactoryConfigurationError (e,
> ^----------------------------------^
> *** Semantic Error: A candidate for type
> "TransformerFactoryConfigurationError" was found, but it is invalid and
> needs to be fixed before this type will successfully compile.
>=20
>=20
> 145. throw new TransformerFactoryConfigurationError (e,
> ^----------------------------------^
> *** Semantic Error: A candidate for type
> "TransformerFactoryConfigurationError" was found, but it is invalid and
> needs to be fixed before this type will successfully compile.
>=20
>=20
> 149. throw new TransformerFactoryConfigurationError (e,
> ^----------------------------------^
> *** Semantic Error: A candidate for type
> "TransformerFactoryConfigurationError" was found, but it is invalid and
> needs to be fixed before this type will successfully compile.
>=20
>=20
> I guess some .java files aren't included in the tarball? or...?
>=20
> Help w/ this issue would be greatly apprieciated.
Ugh, so it isn't my setup :{
I get the same with a clean "upstream" classpath.
Somehow one of the gnu jaxp .java files ends up in the root build dir!?!
I'll try to fix make distcheck for classpath soon (hopefully tonight).
Cheers,
Mark
P.S. To the Classpath hackers. Please do a make distcheeck from time to
time. Especially after you alter configure.ac, Makefile.am and/or added
a file.
|
|
From: Grzegorz B. P. <ga...@de...> - 2004-02-14 09:03:58
|
Hi all! Shortly. - Take a look at http://devel.sablevm.org/wiki/ReleaseProcess That's more less what I had in mind. Comments? - staging has now version '1.0.9+staging' - it should be less confusing (we'll make it 1.1.0+staging after 1.1.0 release, I guess). - I am missing only #3 to complete Prolog part, that is, I fixed SableVM 'make distcheck', updated INSTALL-DEVEL (which is both: Installation and Release Notes), but 'make distcheck' in classpath dies with this output: Found 2 semantic errors compiling "../../external/jaxp/source/javax/xml/transform/TransformerFactory.java": 94. throws TransformerFactoryConfigurationError ^----------------------------------^ *** Semantic Error: Type javax.xml.transform.TransformerFactoryConfigurationError was not found. 104. throw new TransformerFactoryConfigurationError(e); ^----------------------------------^ *** Semantic Error: A candidate for type "TransformerFactoryConfigurationError" was found, but it is invalid and needs to be fixed before this type will successfully compile. Found 3 semantic errors compiling "../../external/jaxp/source/javax/xml/transform/ClassStuff.java": 141. throw new TransformerFactoryConfigurationError (e, ^----------------------------------^ *** Semantic Error: A candidate for type "TransformerFactoryConfigurationError" was found, but it is invalid and needs to be fixed before this type will successfully compile. 145. throw new TransformerFactoryConfigurationError (e, ^----------------------------------^ *** Semantic Error: A candidate for type "TransformerFactoryConfigurationError" was found, but it is invalid and needs to be fixed before this type will successfully compile. 149. throw new TransformerFactoryConfigurationError (e, ^----------------------------------^ *** Semantic Error: A candidate for type "TransformerFactoryConfigurationError" was found, but it is invalid and needs to be fixed before this type will successfully compile. I guess some .java files aren't included in the tarball? or...? Help w/ this issue would be greatly apprieciated. GBP -> sleep -- 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-02-14 08:18:31
|
Hi Heinrich! W li=B6cie z =B6ro, 11-02-2004, godz. 01:55, Etienne Gagnon pisze:=20 > Heinrich Moser wrote: > > * What version should I use? > Currently: The "staging" version. It's the best one available for the = moment. > Soon, Greg (Grzegorz) and David will release a "bugfree" version which = would > also be an interesting candidate. Surely not 1.0.9. I'd say that if you want to develop things - "staging" is most likely to be good choice, especially, if you want to be able to often feed your improvements back into "staging". [*] But you might want to start from some better recognizable point, like ex. the soon-to-be-released 1.1.0. > Ideally, whichever version you pick, you should be working within a > Subversion working copy, so that you can easily extract "patches" again= st > a "precise" version, e.g. Definitely. It will save you lots of time. > > * Did someone already try some benchmarks on SableVM? > Look in my Ph.D. thesis for some performance numbers. Others (Greg, Da= vid, Chris...) > might have additional information. (BTF, AshesX, ... ???) See latest mails from Chris, with some results. I also had some, but they= 'll have to be repeated. > > * The Wiki cannot be edited with IE or Opera. The reason is the > > <plaintext> tag that's used to display the LGPL. <plaintext> cannot > > be turned off (see RFC 1866: there is no </plaintext>) and is highl= y > > deprecated. Thanks for pointing this out. That's the cost of monoculture. We all use Mozilla(-based) browsers :-) Should be fixed now. > > * Although <http://devel.sablevm.org/docs/INSTALL.txt> claims that > > only libart-dev is required for SABLEVM-CLASSPATH, you (also?) need > > libart-2.0-dev to configure successfully. I wrote "libart-dev" because on different systems it may be called differently, though you're right - on debian it is libart-2.0-dev. I altered that (and added a comment for other distros) in newest version of this document that will get into staging probably in a few moments. > > * I didn't really test it in-depth but SableVM seems to run well on m= y > > testing system (user-mode-linux on i386 with Debian sarge/testing). Cool! :-) Welcome, and wish you happy hacking! Grzegorz B. Prokopski [*] This requires explanation, that generaly the code flow is such: Deveper's sandbox =3D> Staging =3D> Bugfree =3D> Trunk. >From Staging you have daily snapshots, tags on Bugfree are development releases (ex. 1.1.0 will be such one), tags on trunk are stable releases (it will take a while before 1.2.0). --=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 |
|
From: Chris P. <chr...@ma...> - 2004-02-13 22:55:29
|
Chris Pickett wrote: > Okay. I'll put the scripts for doing the regression testing in > ~/sablevm/regression in my home directory -- they need some unification > to become truly reusable, but as long as you have the same directory > layout for the benchmarks as me, and run 4 different SableVM's, they > should be fairly easily adjusted (using some editor's find-and-replace). Sorry, I meant sandbox (~/sablevm IS the working copy of my sandbox). They were just committed. I'm stopping work on progress towards bugfree now, unless there's something else specific you'd like me to do. By the way, the link to the benchmark results on the news page is dead. http://www.sable.mcgill.ca/~cpicke/sablevm/r1575-vs-1.0.9/ Cheers, Chris |
|
From: Chris P. <chr...@ma...> - 2004-02-13 19:35:34
|
Mark Wielaard wrote: > Hi, >=20 > On Fri, 2004-02-13 at 06:21, Grzegorz B. Prokopski wrote: >=20 >>W li=B6cie z czw, 12-02-2004, godz. 23:04, Chris Pickett pisze:=20 >> >>>2) A fix for the classpath configure problem (I think the easiest is t= o=20 >>>undo Mark's configure.ac patch, since apparently this was only for Jam= VM). >> >>I guess we can just undo the change for this moment, but it'd be >>best to ask on gnu classpath ML. Hmmm... I think he's on SableVM list. >> >>Mark? :-) >=20 >=20 > Something like that patch is definitely needed. Not just for JamVM, > libgcj needed the same to be able to run AWT programs, see: > http://gcc.gnu.org/ml/java-patches/2004-q1/msg00411.html >=20 > Is pkg.m4 available on the machine, in sablevm? > Seems the problem is that the PKG_CHECK_MODULES macro from that file > isn't defined. On a debian system it comes from the package > 'pkg-config'. I installed pkg-config-0.15.0 and it worked. I didn't test earlier=20 versions. I think pkg-config should be added to the list of classpath=20 dependencies in the `Suggested Software' part of INSTALL, and that we=20 should put a little note in our version of classpath in the interim. Cheers, Chris |
|
From: Chris P. <chr...@ma...> - 2004-02-13 19:35:32
|
Grzegorz B. Prokopski wrote: >>Basically: >> >>1) I found no regressions > > I have to believe you, because I looked at the diffs and firstly: > > I don't know what I am comaring with what. I mean, that you used > just diff, instead of ex. 'diff -u', which would put filenames > into the header. Each SableVM output is compared against java.out, which is supposed to be the correct output (from sun's 1.4.1-b21 java). If there's a problem, the name of the SableVM output file is printed, and then the diff. e.g. ./grande/section1/sablevm-1.0.9-switch-debug-JGFSerialBench.out 1c1,12 < Exception in thread "main" java.lang.VerifyError: (class: JGFSerialBench, method: JGFrun signature: ()V) Incompatible types for storing into array of arrays or objects --- > *** Couldn't bind native method Java_java_lang_Class_getDeclaredFields *** > *** or Java_java_lang_Class_getDeclaredFields__ *** > java.lang.UnsatisfiedLinkError If they're identical, save for timing information (grep -i -v -E 'time|total|msec|returned value'), the result is a pass in the report file. The `paranoid' diffs are those that have everything (but still worth scanning over -- one time I found negative numbers reported for timing information with my spmt stuff). I ran the SableVM's with '-Y'. If you want, it's very easy to get a 'diff -u'. Let me know (I don't think it will provide more useful information, just nicer formatting). > Second thing, partially being result of the first one: I looked at > http://www.sable.mcgill.ca/~cpicke/sablevm/r1575-vs-1.0.9/grande_section1_diff_feb12 > and it seems that errors are not identical. I guess that both cases > qualify as "doesn't work", but still - I'd love to know which errors > do we get now. Do I get it right, that w/ 1.0.9 we get link error, > and now we get security provider error (so it's more CP problem)? Without having looked at any code, yes, I think so. "Doesn't work" is sort of abused in this case, because it "doesn't work" for Sun's Java either. But you're right, there is an improvement on JGFSerialBench: the error is handled more gracefully. >>2) mtrt seems to have been fixed for switch-debug (no blank line) > > oh, and how about switch w/o signals? It might be interesting to see. $ diff sablevm-staging-r1575-switch-nosig.out java.out and $ diff sablevm-1.0.9-switch-nosig.out java.out both give me nothing, which is interesting. N.B. I only did it once -- the error may be intermittent. I think for now we need to focus on micro synchronization problems first (e.g. JGFSyncBench). > >>3) JGFSyncBench, JGFLUFactBench, and JGFRayTracerBench fail >> (single- and multi-threaded errors) >>4) JGFSerialBench fails, but it fails for java as well >> (verification error) >>5) In general things are faster, but there are a couple of exceptions. > > Working on it. Inlined is staging is ATM not reliable in terms of speed. > There are good chances to get fixed this weekend. Okay. I'll put the scripts for doing the regression testing in ~/sablevm/regression in my home directory -- they need some unification to become truly reusable, but as long as you have the same directory layout for the benchmarks as me, and run 4 different SableVM's, they should be fairly easily adjusted (using some editor's find-and-replace). >>1) A list of known issues (incl. the above benchmark failures and the >>fact that synchronized methods may crash the VM) >>2) A fix for the classpath configure problem (I think the easiest is to >>undo Mark's configure.ac patch, since apparently this was only for JamVM). > > I guess we can just undo the change for this moment, but it'd be > best to ask on gnu classpath ML. Hmmm... I think he's on SableVM list. > > Mark? :-) Fixed (see other email to Mark). > I think Chirs, that you've just pushed 1.1.0 a lot to make it reality. > Thanks a lot! No problem :) Most of the time went into compilation (configure wasn't seeing gcc-3.3.2 for staging, and once that was fixed I had to go back and specify gcc-2.95.4 for 1.0.9), installing dependencies, and adjusting benchmarking scripts. The actual benchmarks took about 6 hours total to run (4 different machines, I think), but that could be sped up if the grande benchmarks were broken into section1, section2, and section3, and creating the reports is trivial once the scripts are set up. I want a release personally too -- if anything, so that I have a supposedly more stable codebase to work against if I want it. According to the policy, we have to try and fix regressions as soon as possible, if they appear. I think "bugfree" is a bit of a misnomer, it should really be thought of as "regressionfree", since no software is truly bug-free. One last thing: I think it would be helpful to include David's build script for classpath, and if we're not putting one in for SableVM, at least put a note that says "the default configure options are: --with-threading=inlined, etc. etc." We also need a note about gcc. Cheers, Chris |
6 messages has been excluded from this view by a project administrator.
