sablevm-developer Mailing List for SableVM (Page 25)
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: aj <aj...@da...> - 2004-01-29 00:09:09
|
Package: libsablevm-native1 Version: 1.0.9-1 Severity: minor I want to do free java development without installing libart and libgtk or anything x-windows related. Could we move these dependancies to reccomends? I suppose a seperate package for Swing stuff would be asking too much. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux daisho 2.4.21 #2 Mon Aug 25 22:46:36 EDT 2003 i686 Locale: LANG=C, LC_CTYPE=C Versions of packages libsablevm-native1 depends on: ii java-common 0.22 Base of all Java packages ii libc6 2.3.2.ds1-10 GNU C Library: Shared libraries an -- no debconf information |
|
From: Chris P. <chr...@ma...> - 2004-01-27 14:00:46
|
Okay, this is weird. I tried sending my reply AGAIN to the list, and it didn't work. I think think it's because the first time it was a cut-and-paste job with the same subject title (hence the headers were messed up), and the second time it was because I "forwarded" the original sent message to Greg (again, headers were likely messed up). I guess the mailer (mailman?) doesn't like non-replies with the same subject line as an existing thread or something. Chris Pickett wrote: > *** note *** > > my reply to Greg never made it to the list, but it's doubly-indented > below so it should be sufficient. > |
|
From: Chris P. <chr...@ma...> - 2004-01-27 13:06:11
|
well, here it is anyway ... >>I notice that instructions.m4.c in staging@r1503 no longer has a pc++ to >>skip the preparation address at the beginning of (GET|PUT)(FIELD|STATIC). >> >> >Right. > > > >>How does this address get skipped in the switch interpreter without >>inlinability testing? >> >>You have a some _svmf_no_inlining_increment_pc() function, but it's only >>turned on / defined for inlinability testing. >> >>The other instructions like INVOKE<X> still have the pc++ at the >>beginning. I checked in prepare_code.c and the preparation address is >>still being used, I'm just wondering where it gets skipped ... >> >> >First see two_modes.list - it list all two-mode instructions. > >Then see instructions_preparation.m4.c - there's all logic (or magic) >there. See m4svm_mark_start_and_skip macro which has two versions. >You're mainly interested in m4svm_mark_start_and_skip_normal. > >For any two-modes bytecode it generates this code: > > if (SVM_INLINEABLE_$1 != SVM_INTRP_FLAG_INLINEABLE) pc++; > >Note, that the result of the comparison is known at comile time >as both values are #defines so no real conditional here. >Also note, that it depends on the value of SVM_INLINEABLE_$1 of >certain bytecode for certain architecture so we don't hardcode >pc++ usage in two_modes.list. > >And for non-inlined engines it does pc++ for all two-modes instructions. > > > Thanks for the explanation. I put the above text in my instructions_preparation.m4.c working copy. It's not in my sandbox yet, but will be tomorrow. I think you should move your inlining stuff out of prepare_code.c into a separate file like "inlinability.c" or something, and just put it above prepare_code.c in libsablevm.c. The file is pushing 10000 lines now and your stuff doesn't tie in directly as one of the phases called in _svmf_prepare_code(). Just my opinion ... I'll let you know how things go tomorrow. I wrote up some short coding guidelines today, mostly based on the existing code, that I think would help everyone (especially newcomers), but I'll wait till I'm done to mail them. Cheers, Chris |
|
From: Chris P. <chr...@ma...> - 2004-01-27 12:48:36
|
*** note *** my reply to Greg never made it to the list, but it's doubly-indented=20 below so it should be sufficient. Grzegorz B. Prokopski wrote: >W li=B6cie z wto, 27-01-2004, godz. 00:29, Chris Pickett pisze:=20 > =20 > >>I think you should move your inlining stuff out of prepare_code.c into >>a separate file like "inlinability.c" or something, and just put it >>above prepare_code.c in libsablevm.c. The file is pushing 10000 lines >>now and your stuff doesn't tie in directly as one of the phases called >>in _svmf_prepare_code(). Just my opinion ... >> =20 >> >You're definitely right. It's the cleanup part that has yet to be >actually finalized (along w/ removing magic values of string lenght). >It should probably end up in inlinability/testing.c or some such. > > =20 > "testing.c" isn't such a good name, just because people tend to use that = kind of name to write disposable testing programs. Well, whatever, it's = your program. All I know is somebody warned me not to write a "test.c"=20 when starting to program C because "test" exists in /usr/bin/test ... >>I'll let you know how things go tomorrow. I wrote up some short >>coding guidelines today, mostly based on the existing code, that I >>think would help everyone (especially newcomers), but I'll wait till >>I'm done to mail them. >> =20 >> >Cool! > >BTW: Any reason to keep such discussions private? I don't find technical= >discussion (even about code cleanness, which might be percieved >differently by different peple) to be an offense of any kind. > > =20 > Actually, I sent it to you first, without CC'ing the list by mistake. =20 Then I sent another one to the list. I guess by some freak of nature it = never got there ... I never know what the policy is about CC's. I personally prefer to get=20 just one mail if I'm already subscribed to the list. Cheers, Chris |
|
From: Chris P. <chr...@ma...> - 2004-01-27 05:30:40
|
>>I notice that instructions.m4.c in staging@r1503 no longer has a pc++ to >>skip the preparation address at the beginning of (GET|PUT)(FIELD|STATIC). >> >> >Right. > > > >>How does this address get skipped in the switch interpreter without >>inlinability testing? >> >>You have a some _svmf_no_inlining_increment_pc() function, but it's only >>turned on / defined for inlinability testing. >> >>The other instructions like INVOKE<X> still have the pc++ at the >>beginning. I checked in prepare_code.c and the preparation address is >>still being used, I'm just wondering where it gets skipped ... >> >> >First see two_modes.list - it list all two-mode instructions. > >Then see instructions_preparation.m4.c - there's all logic (or magic) >there. See m4svm_mark_start_and_skip macro which has two versions. >You're mainly interested in m4svm_mark_start_and_skip_normal. > >For any two-modes bytecode it generates this code: > > if (SVM_INLINEABLE_$1 != SVM_INTRP_FLAG_INLINEABLE) pc++; > >Note, that the result of the comparison is known at comile time >as both values are #defines so no real conditional here. >Also note, that it depends on the value of SVM_INLINEABLE_$1 of >certain bytecode for certain architecture so we don't hardcode >pc++ usage in two_modes.list. > >And for non-inlined engines it does pc++ for all two-modes instructions. > > > Thanks for the explanation. I put the above text in my instructions_preparation.m4.c working copy. It's not in my sandbox yet, but will be tomorrow. I think you should move your inlining stuff out of prepare_code.c into a separate file like "inlinability.c" or something, and just put it above prepare_code.c in libsablevm.c. The file is pushing 10000 lines now and your stuff doesn't tie in directly as one of the phases called in _svmf_prepare_code(). Just my opinion ... I'll let you know how things go tomorrow. I wrote up some short coding guidelines today, mostly based on the existing code, that I think would help everyone (especially newcomers), but I'll wait till I'm done to mail them. Cheers, Chris |
|
From: Grzegorz B. P. <ga...@de...> - 2004-01-27 05:09:41
|
Hello! I just wanted to point you for a 30 seconds to http://gadek.homelinux.org/google-rank/ and ehm... be proud ;-) at least a bit more than a few days ago [*] Cheers, GBP [*] 430 - 180 = 250... positions after all. PS: This is a repost as the first mail apparently got lost somewhere. -- 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-01-27 05:01:58
|
W liście z pon, 26-01-2004, godz. 23:34, Chris Pickett pisze: > Hi Greg, > > I'm almost done merging staging into my tree (should be done tomorrow if > not tonight). Nice. > I notice that instructions.m4.c in staging@r1503 no longer has a pc++ to > skip the preparation address at the beginning of (GET|PUT)(FIELD|STATIC). Right. > How does this address get skipped in the switch interpreter without > inlinability testing? > > You have a some _svmf_no_inlining_increment_pc() function, but it's only > turned on / defined for inlinability testing. > > The other instructions like INVOKE<X> still have the pc++ at the > beginning. I checked in prepare_code.c and the preparation address is > still being used, I'm just wondering where it gets skipped ... First see two_modes.list - it list all two-mode instructions. Then see instructions_preparation.m4.c - there's all logic (or magic) there. See m4svm_mark_start_and_skip macro which has two versions. You're mainly interested in m4svm_mark_start_and_skip_normal. For any two-modes bytecode it generates this code: if (SVM_INLINEABLE_$1 != SVM_INTRP_FLAG_INLINEABLE) pc++; Note, that the result of the comparison is known at comile time as both values are #defines so no real conditional here. Also note, that it depends on the value of SVM_INLINEABLE_$1 of certain bytecode for certain architecture so we don't hardcode pc++ usage in two_modes.list. And for non-inlined engines it does pc++ for all two-modes instructions. 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: Chris P. <chr...@ma...> - 2004-01-27 04:32:40
|
Hi Greg, I'm almost done merging staging into my tree (should be done tomorrow if not tonight). I notice that instructions.m4.c in staging@r1503 no longer has a pc++ to skip the preparation address at the beginning of (GET|PUT)(FIELD|STATIC). How does this address get skipped in the switch interpreter without inlinability testing? You have a some _svmf_no_inlining_increment_pc() function, but it's only turned on / defined for inlinability testing. The other instructions like INVOKE<X> still have the pc++ at the beginning. I checked in prepare_code.c and the preparation address is still being used, I'm just wondering where it gets skipped ... Cheers, Chris |
|
From: Grzegorz B. P. <ga...@de...> - 2004-01-27 03:15:38
|
Hello! I just wanted to point you for a 30 seconds to http://gadek.homelinux.org/google-rank/ and ehm... be proud ;-) at least a bit more than a few days ago [*] Cheers, GBP [*] 430 - 180 = 250... positions after all. -- 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: P. <mp...@ch...> - 2004-01-26 20:41:33
|
Package: sablevm Version: 1.0.9+svn20040115-1 Severity: serious File: /usr/bin/java-sablevm Justification: Policy 10.4 The script uses a bash-specific '=3D=3D' operator two times. POSIX sh scripts must use single '=3D' for string equality testing. --=20 Micha=B3 Politowski -- mp...@ch... Talking has been known to lead to communication if practised carelessly. |
|
From: Grzegorz B. P. <ga...@de...> - 2004-01-26 11:29:57
|
tags 229001 pending thanks It's already fixed in yesterday's upload, but got stuck in NEW queue because I also added jikes-sablevm wrapper. 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: Etienne G. <gag...@uq...> - 2004-01-23 00:35:36
|
David B=E9langer wrote: > Hi, >=20 > So if I understand well, we will use the AC_CHECK_LIB in two ways: >=20 > 1) For system libraries such as: m, pthread, rt, ... > To check their if we need to link them explicitly. > 2) For non-system lib such as: ltdl, popt, ffi > To check if the user have installed them like we are currently > doing. >=20 > Sounds good? Sounds good to me. I'll let you figure out how to do it. I learned just enough about auto* tools as to write the current *.[ac|am] files :-) Etienne --=20 Etienne M. Gagnon, Ph.D. http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
|
From: Grzegorz B. P. <ga...@de...> - 2004-01-22 20:15:20
|
On Thu, 2004-01-22 at 11:15, David Bélanger wrote: > So if I understand well, we will use the AC_CHECK_LIB in two ways: > > 1) For system libraries such as: m, pthread, rt, ... > To check their if we need to link them explicitly. > 2) For non-system lib such as: ltdl, popt, ffi > To check if the user have installed them like we are currently > doing. Just beware of one thing. The fact that for ex. librt exists and we can technically link to it - doesn't mean we actually need! For ex. on Linux we can just simply omit the -lrt - it'll work with or without it as well. But on Solaris we have to add -lrt, while on cygwin we must not. I don't know exactly how you want to use AC_CHECK_LIB but it's just not great idea to do "oh, you do have this lib? let's link to it!" I belive auto* tools can actually check whether a lib has certain symbols to which you can link, or not. So if we want it to be actually automated, maybe for the symbol that is available in librt, we should first look into the regular, other lib, whether it is available there, and if not - try to find it in librt. Makes sense? ;-) Grzegorz B. Prokopski |
|
From: David <db...@cs...> - 2004-01-22 16:15:25
|
On Mon, Jan 19, 2004 at 08:31:31AM +0100, Patrick Cernko wrote: > Also sprach Grzegorz B. Prokopski zu "17.01.2004 11:08" Anno Domini: > > W li?cie z sob, 17-01-2004, godz. 04:17, David B=E9langer pisze:=20 > >=20 > >>Hi, > >> > >>I think it would be great if SableVM could be built out-of-the-box on > >>all platforms including the non-Linuxian FreeBSD and OS X. It will > >>simplify my life as I want to build and test on these platforms. > >>Currently source code is not an issue, it is more a configure/Makefil= e > >>isssue. > >> > >>src/libsablevm/Makefile.am has some line like: > >>libsablevm_la_LIBADD =3D -lpthread -lm -lffi -lltdl -lrt > >> > >>FreeBSD does not like -lpthread. > >>OS X does not like -lrt. > >> ... > >=20 > > Ideally, I think we'd have in configure.ac sth. like: ... > >=20 > > +AC_MSG_CHECKING([if we need -lrt]) > > + > > +case "$host" in > > + *solaris*) > > + lrt=3D-lrt > > + AC_MSG_RESULT([yes]) > > + ;; > > + *) > > + AC_MSG_RESULT([no]) > > + ;; > > +esac > >=20 > > +AC_MSG_CHECKING([if we need -lpthread]) > > + > > +case "$host" in > > + *freebsd*) > > + AC_MSG_RESULT([no]) > > + ;; > > + *) > > + lpthread=3D-lpthread > > + AC_MSG_RESULT([yes]) > > + ;; > > +esac > >=20 >=20 > That's exactly what you should do in configure! For that reason, there > are more macros provided by autoconf that only "AC_MSG_*". Your last > case for example could be simpliefied to a simple one-liner using > AC_CHECK_LIB! Have a look at the autoconf info pages for a complete > overview. A call of autoscan in your sources could also be helpful (hav= e > a look at the generated configure.scan template). On Debian, there > exists a package named autobook with a quiet complete html documentatio= n > about auto*. Last but not least, three pointers: >=20 Hi, So if I understand well, we will use the AC_CHECK_LIB in two ways: 1) For system libraries such as: m, pthread, rt, ... To check their if we need to link them explicitly. 2) For non-system lib such as: ltdl, popt, ffi To check if the user have installed them like we are currently doing. Sounds good? 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-01-20 16:44:16
|
Grzegorz B. Prokopski wrote: > I copied AllocObject and DeleteGlobalRef from David's sandbox [*] and > was able to get "bugreporter" utility that far (thanks David!): > http://gadek.homelinux.org/debbuggtk-sablevm.png Great! > This one is SableVM/Classpath problem, no? How hard would it be > to fix it? How can I install debbuggtk and try to run it on SableVM? Can I compile it from sources (much easier to debug that way)? 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-01-20 16:18:58
|
David B=E9langer wrote: > 4) If it is judged to unstable for bugfree, it is easy to downgrade no > real changes in SableVM internals. Agreed. Etienne --=20 Etienne M. Gagnon, Ph.D. http://www.info.uqam.ca/~egagnon/ SableVM: http://www.sablevm.org/ SableCC: http://www.sablecc.org/ |
|
From: Archie C. <ar...@de...> - 2004-01-20 16:00:09
|
David B=E9langer wrote:
> This requires implementing the Thread interrupt()ing mechanism in
> SableVM. If I remember well there is no functionality right now.
> In addition to Thread.interrupted(), .interrupt(), etc.
> Object.wait(), Process.waitFor(), maybe also join() and sleep()...
> need to be modified to throw InterruptedException.
I am interested in hearing people's ideas about how to best implement
Thread.interrupt().
First observation: if you implement join(), sleep(), and waitFor() using
wait(), then you get them for free.
So look at the wait() case. There will have to be some interruption state
associated with each that is updated with compare&swap. One possibility:
INTERRUPT_CLEAR /* not interrupted, not interruptible */
INTERRUPT_SET /* interrupted, but not asleep yet */
INTERRUPT_INTERRUPTIBLE /* sleeping in wait() and interruptible *=
/
INTERRUPT_INTERRUPTED /* waking up to handle interruption */
Not sure if the last state is needed.
To wake up a thread in wait(), the interrupting thread will have
to notify the wait() condition variable. However, there may be multiple
threads waiting. To ensure the correct one is woken up & notices
its interruption state has changed, we must use pthread_cond_broadcast()
instead of pthread_cond_signal(). So some threads will wake up spuriously.
This implies the wait() algorithm will have to loop (i.e., handle the
case where the wakeup was spurious). But we should be doing this anyway
according to:
http://www.opengroup.org/onlinepubs/7908799/xsh/pthread_cond_wait.html
"Spurious wakeups from the pthread_cond_wait() or pthread_cond_timedwait(=
)
functions may occur."
Interested to hear others' thoughts. I haven't really looked at how
other VMs do it, there's probably a better way than above.
-Archie
_________________________________________________________________________=
_
Archie Cobbs * Halloo Communications * http://www.halloo.co=
m
|
|
From: David <db...@cs...> - 2004-01-20 15:40:26
|
Hi, Small update. 0) SableVM/Classpath new snaphsot moved to staging. 1) build_classpath has been renamed and moved to the build_sablevm-classp= ath staging for convenience: svn+ssh://svn.sablevm.org/public/sablevm-classpath/branches/staging/bu= ild_sablevm-classpath 2) I fixed bug in gtk peers (was quite easy). I will send a patch upstream. 3) The autoconf problem may be due to the use of an old autoconf. If someone gets warnings with automake/autoconf etc. and have all the version in the Classpath HACKING file, you should report it to CP. 4) If it is judged to unstable for bugfree, it is easy to downgrade no real changes in SableVM internals. Have fun! 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-01-20 07:11:03
|
On Tue, Jan 20, 2004 at 01:19:03AM -0500, Grzegorz B. Prokopski wrote: > Hi all! >=20 > I copied AllocObject and DeleteGlobalRef from David's sandbox [*] and > was able to get "bugreporter" utility that far (thanks David!): > http://gadek.homelinux.org/debbuggtk-sablevm.png >=20 > This error shows up, but the app continues in spite of it: > $ bugreporter=20 > *** Couldn't bind native method Java_java_lang_VMThread_interrupted *** > *** or Java_java_lang_VMThread_interrupted__ *** > Exception in thread "Lazy cache writer" java.lang.UnsatisfiedLinkError > at java.lang.VMThread.interrupted (VMThread.java) > at java.lang.Thread.interrupted (Thread.java:572) > at com.tildemh.debbug.CacheWriter.run (CacheWriter.java:45) > at java.lang.Thread.run (Thread.java:455) > at java.lang.VMThread.callRun (VMThread.java:116) > at java.lang.Thread.callRun (Thread.java:333) > at java.lang.VirtualMachine.runThread (VirtualMachine.java:117) >=20 > This one is SableVM/Classpath problem, no? How hard would it be > to fix it? You will probably need to ask Etienne to implement it... This requires implementing the Thread interrupt()ing mechanism in SableVM. If I remember well there is no functionality right now. In addition to Thread.interrupted(), .interrupt(), etc. Object.wait(), Process.waitFor(), maybe also join() and sleep()... need to be modified to throw InterruptedException. So, it is not simply playing with VM/Classpath interface... >=20 > I can go to the next screen by pressing Forward, I can put package > name into edit window, however after next Forward it dies with: > (Gtk.java:-1) org/gnu/gtk/Gtk.gtk_main n > (Gtk.java:64) org/gnu/gtk/Gtk.main =20 > (BugReporter.java:257) com/tildemh/debbuggtk/BugReporter.main =20 > (VirtualMachine.java:-1) java/lang/VirtualMachine.invokeMain n > (VirtualMachine.java:88) java/lang/VirtualMachine.main =20 > [jni: fatal error (Local reference capacity exceeded)] >=20 > Which in this case seems to be again problem of gtk-java libs > not freeing (leaking) references. Yes, basically it would need to be fixed in the code that allocates them. > Anyway, I am very happy, because it is first real graphical window > that I was able to see using SableVM on my machine. >=20 Bravo! Your app seem to be good to test JNI and other stuff. >=20 > [*] I guess then that as AllocObject and DeleteGlobalRef have been > excersised, they're good enough to go into staging.=20 >=20 they were simple... 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-01-20 06:51:30
|
On Tue, Jan 20, 2004 at 12:23:43AM -0500, Grzegorz B. Prokopski wrote: > W li?cie z pon, 19-01-2004, godz. 23:22, David B=E9langer pisze:=20 > > - Note: some native lib that uses gtk does not compile. I simply > > disable gtk peers (pass --no-gtk to build_classpath if you are usin= g > > my script), I did not try to fix it. >=20 > I understand that it's upstream problem. Does GNU CP people know about > it? I haven't seen any information/discussion on the ML and it's not > mentioned in the bug database. Does it mean nobody is actually using > GNU CP CVS daily? Nobody noticed yet? >=20 I would say upstream because I don't touch these files, but I will need to have a look at the actual problem to make sure. > Other than that - not sure if it's acceptable for staging. Thought > we, unfortunatelly, haven't got real graphical apps working yet, > I hope we soon will. >=20 > Or at least maybe we should promote current CP staging to bugfree > prior to that? (not to mention sablevm itself) >=20 > Etienne, what do you think? >=20 If you want I could delay it and keep it in my sandbox if the problem can be fixed soon then merge once it's fixed. But I don't want to freeze staging to CP 0.07 until next SableVM is release. Staging needs to keep going... Otherwise, when CP 0.08 will be ready, we will still be at CP 0.07 and won't have time to test CP 0.08. 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-01-20 06:19:07
|
Hi all! I copied AllocObject and DeleteGlobalRef from David's sandbox [*] and was able to get "bugreporter" utility that far (thanks David!): http://gadek.homelinux.org/debbuggtk-sablevm.png This error shows up, but the app continues in spite of it: $ bugreporter *** Couldn't bind native method Java_java_lang_VMThread_interrupted *** *** or Java_java_lang_VMThread_interrupted__ *** Exception in thread "Lazy cache writer" java.lang.UnsatisfiedLinkError at java.lang.VMThread.interrupted (VMThread.java) at java.lang.Thread.interrupted (Thread.java:572) at com.tildemh.debbug.CacheWriter.run (CacheWriter.java:45) at java.lang.Thread.run (Thread.java:455) at java.lang.VMThread.callRun (VMThread.java:116) at java.lang.Thread.callRun (Thread.java:333) at java.lang.VirtualMachine.runThread (VirtualMachine.java:117) This one is SableVM/Classpath problem, no? How hard would it be to fix it? I can go to the next screen by pressing Forward, I can put package name into edit window, however after next Forward it dies with: (Gtk.java:-1) org/gnu/gtk/Gtk.gtk_main n (Gtk.java:64) org/gnu/gtk/Gtk.main (BugReporter.java:257) com/tildemh/debbuggtk/BugReporter.main (VirtualMachine.java:-1) java/lang/VirtualMachine.invokeMain n (VirtualMachine.java:88) java/lang/VirtualMachine.main [jni: fatal error (Local reference capacity exceeded)] Which in this case seems to be again problem of gtk-java libs not freeing (leaking) references. Anyway, I am very happy, because it is first real graphical window that I was able to see using SableVM on my machine. Cheers, Grzegorz B. Prokopski [*] I guess then that as AllocObject and DeleteGlobalRef have been excersised, they're good enough to go into staging. PS: Updated Debian packages (won't be put in Debian yet) are at: http://gadek.homelinux.org/sablevm-unofficial/ PPS: Just for reference - other bug* tools die with: $ bugwatcher (LibGlade.java:-1) org/gnu/glade/LibGlade.glade_xml_signal_autoconnect_full n (LibGlade.java:118) org/gnu/glade/LibGlade.<init> (LibGlade.java:88) org/gnu/glade/LibGlade.<init> (BugWatcher.java:89) com/tildemh/debbuggtk/BugWatcher.<init> (BugWatcher.java:206) com/tildemh/debbuggtk/BugWatcher.main (VirtualMachine.java:-1) java/lang/VirtualMachine.invokeMain n (VirtualMachine.java:88) java/lang/VirtualMachine.main [jni: fatal error (Local reference capacity exceeded)] -- 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-01-20 05:23:49
|
W liście z pon, 19-01-2004, godz. 23:22, David Bélanger pisze: > - Note: some native lib that uses gtk does not compile. I simply > disable gtk peers (pass --no-gtk to build_classpath if you are using > my script), I did not try to fix it. I understand that it's upstream problem. Does GNU CP people know about it? I haven't seen any information/discussion on the ML and it's not mentioned in the bug database. Does it mean nobody is actually using GNU CP CVS daily? Nobody noticed yet? Other than that - not sure if it's acceptable for staging. Thought we, unfortunatelly, haven't got real graphical apps working yet, I hope we soon will. Or at least maybe we should promote current CP staging to bugfree prior to that? (not to mention sablevm itself) Etienne, what do you think? 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: Etienne G. <gag...@uq...> - 2004-01-20 04:23:28
|
David B=E9langer wrote: > Hi, > > I am currently have problem with the svn server: something happened. I recovered the database. [svnadmin recover] Etienne --=20 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-01-20 04:22:45
|
Hi, I will check a new Classpath snapshot made of today in staging *tomorrow* (currently problems with svn). However, I will announce it now. - Build it as before. Build clean. Some files have moved etc. You may want to use my build_classpath script located here: svn+ssh://svn.sablevm.org/public/developers/belanger/sandbox/sablejit-c= lasspath/bin/build_classpath (may need to remove +ssh and /public if don't have write access via ssh). Will move it to staging also. =20 - Note: autoconf gives me a warning, however the ./configure is still produce. - Note: some native lib that uses gtk does not compile. I simply disable gtk peers (pass --no-gtk to build_classpath if you are using my script), I did not try to fix it. - Note to Etienne: may be in a few weeks, you could import a new copy and with luck gtk peers problem will be fixed. I don't mind merging it, it requires very little work as the VM interface is getting stable. - Only change that affect SableVM are split of Runtime into VMRuntime/Runtime. This is mostly method renaming. So SableVM should not have been broken. - Did not test heavily, report any problem after you merge. Hope you can wait until 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: David <db...@cs...> - 2004-01-20 03:59:39
|
Hi, I am currently have problem with the svn server: ibou:~/work/svn_sablejit/belanger/sandbox/sablevm> svn up ../subversion/libsvn_fs/bdb/bdb-err.c:61: (apr_err=3D160029) svn: Berkeley DB error svn: Berkeley DB error while opening 'uuids' table for filesystem /home/svn/public/db: Cannot allocate memory ibou:~/work/svn_sablejit/belanger/sandbox/sablevm>=20 or for a ci: ibou:~/work/svn_sablejit/belanger/sandbox/sablevm-classpath> svn ci java/io/ObjectInputStream.java Sending java/io/ObjectInputStream.java Transmitting file data .subversion/libsvn_client/commit.c:733: (apr_err=3D165001) svn: A repository hook failed svn: Commit failed (details follow): ../subversion/libsvn_repos/hooks.c:101: (apr_err=3D165001) svn: 'pre-commit' hook failed with error output: svn: Berkeley DB error svn: Berkeley DB error while opening 'uuids' table for filesystem /home/svn/public/db: Cannot allocate memory error: the log message is empty subversion/clients/cmdline/util.c:358: (apr_err=3D165001) svn: Your commit message was left in a temporary file: subversion/clients/cmdline/util.c:358: (apr_err=3D165001) svn: '/home/david/work/svn_sablejit/belanger/sandbox/sablevm-classpath/java/io= /svn-commit.tmp' ibou:~/work/svn_sablejit/belanger/sandbox/sablevm-classpath>=20 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 |
6 messages has been excluded from this view by a project administrator.
