[kaffe] 'mktemp' check in configure (or kaffe shell script does not work)
Hi, As the subject line says, configure.in version 1.200 introduced existence check for 'mktemp' command, but it does not change anything for configure script. This command is used in 'kaffe' shell script and if we don't have mktemp (well, this is the case for me on Solaris) the final 'kaffe' script does not work properly if you set debug flag. Kiyo ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] Re: 'mktemp' check in configure (or kaffe shell script does not work)
Oops, my previous report is too terse. I said, As the subject line says, configure.in version 1.200 introduced existence check for 'mktemp' command, but it does not change anything for configure script. This command is used in 'kaffe' shell script and if we don't have mktemp (well, this is the case for me on Solaris) the final 'kaffe' script does not work properly if you set debug flag. If we don't do anything while configure for missing mktemp, then I think this check is not needed anyway. Or, of course we can warn the user while configure for the missing tool (or, just say 'See FAQ.requiredlibrary'). Kiyo ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] Re: 'mktemp' check in configure (or kaffe shell script does not work)
Hi again, Since mktemp command in 'www.mktemp.org' is BSD style license, aren't there any possibilities to include it into kaffe tree? Kiyo ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Re: 'mktemp' check in configure (or kaffe shell script does not work)
On Tue, 30 Sep 2003 15:53:33 +0900 (JST) Kiyo Inaba [EMAIL PROTECTED] wrote: Hi, I said, As the subject line says, configure.in version 1.200 introduced existence check for 'mktemp' command, but it does not change anything for configure script. This command is used in 'kaffe' shell script and if we don't have mktemp (well, this is the case for me on Solaris) the final 'kaffe' script does not work properly if you set debug flag. If we don't do anything while configure for missing mktemp, then I think this check is not needed anyway. Or, of course we can warn the user while configure for the missing tool (or, just say 'See FAQ.requiredlibrary'). AFAIK, mktemp is used to generate a unique filename which can be used for a small gdb script that's passed via -command to gdb. Why do we have to use mktemp here anyways? I think if someone wants to debug kaffe, they'll be well able to imagine a unique filename and set KAFFE_DEBUG_TEMPFILE accordingly, don't they? Regards, Helmer ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] huge number of 'sleep' processes
On Tue, 30 Sep 2003 16:52:24 +1200 M.Negovanovic [EMAIL PROTECTED] wrote: Hi, i am having trouble while running 'make check' on netbsd/i386. No mater what number of max user processes i set its never enough and i always get 'cant fork' error. Now quick look at top while running 'make check' in the background shows very large number of 'sleep' processes. Doing 'kill -9 sleep' few times during checks results in diff number of failed tests every time! Does anyone have any clues about this? It sounds like the changes I made to TestScript.in to create a killer process to kill off long-running tests. I guess I'm doing something non-portable. :-( Does anybody have an idea what I did wrong? When a test completes, it should kill off the killer process. My guess is that isn't happening. I've got a really old NetBSD box at home -- I'll do some experiments when I get some time. Cheers, - Jim ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Feature freeze for 1.1.2
On Mon, 29 Sep 2003 12:42:36 -0400 Stuart Ballard [EMAIL PROTECTED] wrote: Jim Pick wrote: Hi, Just a reminder - we're in a feature freeze now, for the 1.1.2 release that I'm going to try to make next Sunday (Oct. 5). So, please try to do some testing, if you've got time, and please don't check in stuff that might be destabilizing until after the release. Any chance of applying my HashMap/Hashtable patch that's being debated on the Classpath list at the moment? I know that it's still up in the air as to whether it will be accepted into Classpath or not, and what modifications, if any, will be made to it first, but the patch as it stands doesn't make anything worse than it currently is (except for the inconsistency of having some collection classes do one thing and some another in an obscure situation that hardly ever comes up). I had some issues with HashMap/Hashtable as well (with new compiles of ant). I'd like to see the issue resolved for 1.1.2. On the other hand, if it were applied to Kaffe then I'd be able to upload my project to Savannah, and say Requires Kaffe 1.1.2 or greater rather than Requires Kaffe CVS from 2003-xx-xx or later. I'll try to make some time to look into the issue before 1.1.2 is released on Sunday. Cheers, - Jim ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Goodbye for Now
On Sun, 28 Sep 2003 20:55:06 -0400 (EDT) Rob Gonzalez [EMAIL PROTECTED] wrote: Hi guys, I've had a great time working on the project on and off for the past year or so. As some of you know, I've been sortof in limbo lately, moving around the east coast of the US without much access to my own computer. Tomorrow I'm leaving for Zurich from which I'll be backpacking to Beijing, China, where I'll be teaching English for a while. When I get to China there's a chance that I'll be able to start working on Kaffe again, but if that doesn't work out I'll probably be off the project until June, 2004, when I get back to the states. Sounds like fun. :-) This project has been moving forward at an amazing pace lately. I have no doubts that it's still going to be going strong when get back :) I've learned a ton by working on it and especially by reading the posts and talking to the other developers. Thanks guys. Thanks for all the code! It's very much appreciated. Having a free software VM that can run untrusted Java code opens a whole world of possibilities -- it's very exciting. Hopefully we won't screw it up too much by the time you get back. :-) Cheers, - Jim ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] CVS kaffe (hkraemer): fixes and improvement for the garbage collector
fixes and improvement for the garbage collector * fixed the endless loop in startGC when running javalayer 0.3.0 * (hopefully) made the heap management more efficient Excellent! We needed that. I'll have to test freenet again to see if it helps. Cheers, - Jim ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] just-in-time question
excuse me: I want to understand that how JITworks , so thatI can researchin translating bytecode to x86 native code. Can you introduce to me some documents about JIT compiler? thanks!
[kaffe] CVS kaffe (hkraemer): fixes for arm-linux jit engine
PatchSet 4083
Date: 2003/09/30 19:50:52
Author: hkraemer
Branch: HEAD
Tag: (none)
Log:
fixes for arm-linux jit engine
It compiles without warnings using gcc 3.2.2, but crashes
at runtime, hope to fix it, though.
Members:
ChangeLog:1.1678-1.1679
config/arm/common.h:1.6-1.7
config/arm/jit.h:1.9-1.10
config/arm/linux/jit-md.h:1.5-1.6
config/arm/linux/md.h:1.4-1.5
libraries/clib/math/BigInteger.c:1.19-1.20
Index: kaffe/ChangeLog
diff -u kaffe/ChangeLog:1.1678 kaffe/ChangeLog:1.1679
--- kaffe/ChangeLog:1.1678 Mon Sep 29 23:50:25 2003
+++ kaffe/ChangeLog Tue Sep 30 19:50:52 2003
@@ -1,3 +1,25 @@
+2003-09-30 Helmer Kraemer [EMAIL PROTECTED]
+
+ * libraries/clib/math/BigInteger.c
+ [!HAVE_GMP_H] (Java_java_math_BigInteger_assignString0): changed
+ return type to jint to match prototype of assignString0 when gmp
+ is used
+
+ * config/arm/common.h (sysdepCallMethod): changed into an inline
+ method, don't treat 'L' return type specially
+
+ * config/arm/jit.h (exceptionFrame): changed type of fields to
+ uintp to fix compilation warnings
+ (NEXTFRAME, PCFRAME, FPFRAME): remove now unnecessary casts
+
+ * config/arm/linux/jit-md.h (FIRSTFRAME): redefined using gcc's
+ __builtin_frame_address extension
+ (ARM_LINUX_HACK): removed since it's no longer necessary
+
+ * config/arm/linux/md.h (SP_OFFSET, FP_OFFSET): corrected to
+ match what current glibc does
+ (ARM_LINUX_HACK): removed since it's no longer necessary
+
2003-09-30 Dalibor Topic [EMAIL PROTECTED]
* libraries/javalib/java/util/zip/ZipEntry.java:
Index: kaffe/config/arm/common.h
diff -u kaffe/config/arm/common.h:1.6 kaffe/config/arm/common.h:1.7
--- kaffe/config/arm/common.h:1.6 Sat Oct 19 11:04:41 2002
+++ kaffe/config/arm/common.h Tue Sep 30 19:50:54 2003
@@ -27,83 +27,87 @@
* have to take this into account here. It is a convention of the
* software floating point libraries and the build tools.
*/
-
-#definesysdepCallMethod(CALL) do { \
- int extraargs[((CALL)-nrargs4)?((CALL)-nrargs-4):0]; \
- switch((CALL)-nrargs) { \
-register int r0 asm(r0); \
-register int r1 asm(r1); \
-register int r2 asm(r2); \
-register int r3 asm(r3); \
-register double f0 asm(f0); \
- default: \
-{ \
- int *args = extraargs; \
- int argidx = 4; \
- if ((CALL)-callsize[3] == 2) { \
- *args++ = ((CALL)-args[argidx].j) 32; \
- } \
- for(; argidx (CALL)-nrargs; ++argidx) { \
- if ((CALL)-callsize[argidx]) { \
- *args++ = (CALL)-args[argidx].i; \
- if ((CALL)-callsize[argidx] == 2)\
- *args++ = ((CALL)-args[argidx].j) 32; \
- } \
- }\
-} \
- case 4: \
-if ((CALL)-callsize[3]) { \
- r3 = (CALL)-args[3].i; \
- if ((CALL)-callsize[3] == 2)\
-*extraargs = ((CALL)-args[3].j) 32;\
-} \
- case 3: \
-if ((CALL)-callsize[2]) { \
- r2 = (CALL)-args[2].i; \
- if ((CALL)-callsize[2] == 2)\
-r3 = ((CALL)-args[2].j) 32;\
-} \
- case 2: \
-if ((CALL)-callsize[1]) { \
- r1 = (CALL)-args[1].i; \
- if ((CALL)-callsize[1] == 2)\
-r2 = ((CALL)-args[1].j) 32;
Re: [kaffe] huge number of 'sleep' processes
On Tue, Sep 30, 2003 at 11:48:20AM -0700, Jim Pick wrote: It sounds like the changes I made to TestScript.in to create a killer process to kill off long-running tests. I guess I'm doing something non-portable. :-( hmm yes! :) Does anybody have an idea what I did wrong? When a test completes, it should kill off the killer process. My guess is that isn't happening. I've got a really old NetBSD box at home -- I'll do some experiments when I get some time. it works fine on my netbsd 1.6 STABLE box, and fails miserably on CURRENT. Regards Milos ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
