RE: JamVM 1.4.2 released
Congrats. Has anyone thought about what it might take to hook it up to the harmony classlib? It would be nice to see what that would take... Geir -Original Message- From: Robert Lougher [mailto:[EMAIL PROTECTED] Sent: Sun Jan 22 19:27:15 2006 To: jamvm discussions; GNU Classpath Project; harmony-dev@incubator.apache.org Subject:JamVM 1.4.2 released Hi, I'm pleased to announce the release of JamVM 1.4.2 (http://jamvm.sourceforge.net). This release adds support for class garbage-collection and unloading. A couple of other changes and bug-fixes have also been made. The full list of changes are here: http://sourceforge.net/project/shownotes.php?release_id=387586 Thanks, Rob.
JamVM 1.4.2 released
Hi, I'm pleased to announce the release of JamVM 1.4.2 (http://jamvm.sourceforge.net). This release adds support for class garbage-collection and unloading. A couple of other changes and bug-fixes have also been made. The full list of changes are here: http://sourceforge.net/project/shownotes.php?release_id=387586 Thanks, Rob.
CACAO 0.94 released
CACAO 0.94 released. This is a small feature enhancement and bugfix release. Here is a short list of the most important changes: * support compilation of Interpreter and JIT compiler into one binary (not enabled by default) * bootstrap ZIP code rewrite (VM startup time improvement) * fixed JNI DirectByteBuffer functions, JOGL works now * removed most third-party files from the repository, we link to the libraries instead * removed VM interface Java files which were identical to the GNU Classpath upstream version * added defineClassWithTransformers to java.lang.VMClassLoader, now we are able to build against the generics branch * Java compiler which should be used during compilation can be specified via JAVAC environment variable * a lot of bugfixes This release supports GNU Classpath 0.19+ and was tested on some platforms against GNU Classpath 0.20. With this release we were able for the first time to run most of the JOGL demos on i386-unknown-linux-gnu and x86_64-unknown-linux-gnu systems. Supported platforms added with this release: * powerpc64-unknown-linux-gnu (intrp only) ATTENTION: The usage of CACAO and GNU Classpath has a bit changed due to some issues on 64-bit distributions. The proper ./configure options are: --with-classpath-prefix= --with-classpath-libdir= Currently supported JIT compiler architectures are: * alpha-unknown-freebsd5.4 * alpha-unknown-linux-gnu * arm-unknown-linux-gnu * i386-unknown-freebsd5.3 * i686-pc-linux-gnu * mips-sgi-irix6.5 * mips-unknown-linux-gnu * powerpc-apple-darwin7.2.0 * powerpc-unknown-linux-gnu * x86_64-unknown-linux-gnu Additionally supported Interpreter architectures are: * powerpc64-unknown-linux-gnu Information about working applications and some screenshots can be found on http://www.cacaojvm.org/ Daily test runs with CACAO SVN head, GNU Classpath CVS head and Mauve CVS head can be found on http://www.cacaojvm.org/tgolem/ A StatCVS report for CACAO's CVS repository (generated on a free Java stack) can be found on http://www.cacaojvm.org/statcvs/ CACAO 0.94 can be downloaded from http://www.cacaojvm.org/download/cacao-0.94/ File : cacao-0.94.tar.gz md5sum : 9d12ae630773d6c3bb1b4ebd13f90f40 sha1sum: ee6262196675c3aef95d7245fba7e1d4acc39868 Enjoy! The CACAO Team [EMAIL PROTECTED]
Re: compiling JCHEVM with GCC/Cygwin
Enrico Migliore wrote:
pread() problem
-
In the zip.c file, I temporarily substituted the pread() call
with the following two calls:
lseek(fd,offset,SEEK_SET);
read(fd,buf,len);
Those are perfectly equivalent to pread() except that
they are not atomic
That is a reasonable workaround; it's not thread safe however.
In practice is probably won't matter though. You'd have to be
loading the same class at the same time from two different
class loaders for that to matter (highly unlikely).
problems
--
jc.exe enters the main function and crashes at the first call,
which is _jc_invoke();
In order to investigate the problem I did the following thngs:
1. Commented _jc_invoke() and added a dummy poptGetContext() call.
It crashes
2. Commented _jc_invoke() and added a printf("Hello World!");
It doesn't crash and print the message to the stdandard output
It seems to me that the problem is the calling convention.
I don't know enough about Windows or Cygwin to help here.
Can you run it under GDB?
-Archie
__
Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: Building harmony/enhanced/jchevm from svn
Jean-frederic Clere wrote: Hi, I have the following problem: +++ etc/Makefile.am:5: invalid variable `dist_jcetc_DATA' include/Makefile.am:13: invalid variable `nodist_jc_include_HEADERS' automake: libjc/Makefile.am: not supported: source file `native/gnu_classpath_VMStackWalker.c' is in subdirectory automake: libjc/Makefile.am: not supported: source file `native/gnu_classpath_VMSystemProperties.c' is in subdirectory automake: libjc/Makefile.am: not supported: source file `native/java_lang_VMClass.c' is in subdirectory automake: libjc/Makefile.am: not supported: source file `native/java_lang_VMClassLoader.c' is in subdirectory ... +++ When running etc/makedist.sh --with-classpath=/usr. What version of automake do you have? I'm using 1.9.6. I'm not an automake expert; my only guess is that your version is too old to support dist_* and nodist_* targets ... ? -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: [classlib] test suites
Geir Magnusson Jr wrote: > Tim Ellison wrote: >> Well its a Java-thing, so you can see why it is on a java view and not >> on the (generic) navigator view. > > Hm. I follow the same UI path to get there, both in java view and > generic nav view : > > right click on (package|folder), then "Run As", then "JUnit Test"... > Same keybinding as well. Yeah, that doesn't sound good (raise it at bugs.eclipse.org). >>> So if you can do this in Eclipse, why AllTests? Do you subgroup? (I >>> haven't seen that yet in the test cases...) >> >> Like I said before, to allow for use of regular test runners and allow >> for decoration. > > Do you use either on this? Both -- though as I wrote elsewhere it may be worth investigating replacing the AllTests suite() implementation with a test collector. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
[jira] Commented: (HARMONY-37) remove() method of IdentityHashMap works incorrectly
[
http://issues.apache.org/jira/browse/HARMONY-37?page=comments#action_12363586 ]
Vladimir Strigun commented on HARMONY-37:
-
Tim, thanks for the fix. Everything works fine.
> remove() method of IdentityHashMap works incorrectly
>
>
> Key: HARMONY-37
> URL: http://issues.apache.org/jira/browse/HARMONY-37
> Project: Harmony
> Type: Bug
> Components: Classlib
> Reporter: Vladimir Strigun
> Assignee: Tim Ellison
> Attachments: IdentityHashMapTest.java, IdentityHashMapTest.java
>
> When user try to remove unexisting key from empty hashmap, size of object
> decreased to -1.
> Testcase for reproducing:
> import java.util.IdentityHashMap;
> public class Harmony37 {
> public static void main(String args[]) {
> IdentityHashMap hashMap = new IdentityHashMap();
> hashMap.remove("unexist");
> if (hashMap.size() != 0) {
> System.out.println("FAILED, because size="+hashMap.size());
> }
> }
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Building harmony/enhanced/jchevm from svn
Hi, I have the following problem: +++ etc/Makefile.am:5: invalid variable `dist_jcetc_DATA' include/Makefile.am:13: invalid variable `nodist_jc_include_HEADERS' automake: libjc/Makefile.am: not supported: source file `native/gnu_classpath_VMStackWalker.c' is in subdirectory automake: libjc/Makefile.am: not supported: source file `native/gnu_classpath_VMSystemProperties.c' is in subdirectory automake: libjc/Makefile.am: not supported: source file `native/java_lang_VMClass.c' is in subdirectory automake: libjc/Makefile.am: not supported: source file `native/java_lang_VMClassLoader.c' is in subdirectory ... +++ When running etc/makedist.sh --with-classpath=/usr. Any hints? Cheers Jean-Frederic
Re: [classlib] test suites
Tim Ellison wrote: Geir Magnusson Jr wrote: Nope. Eclipse is inconstant. If you work in Package Explorer, you're right - you get that behavior. If you work in Navigator, you get the behavior I described. Interesting. Well its a Java-thing, so you can see why it is on a java view and not on the (generic) navigator view. Hm. I follow the same UI path to get there, both in java view and generic nav view : right click on (package|folder), then "Run As", then "JUnit Test"... Same keybinding as well. So if you can do this in Eclipse, why AllTests? Do you subgroup? (I haven't seen that yet in the test cases...) Like I said before, to allow for use of regular test runners and allow for decoration. Do you use either on this? geir Regards, Tim geirh Regards, Tim
Re: [classlib] test suites
Geir Magnusson Jr wrote: > Nope. Eclipse is inconstant. If you work in Package Explorer, you're > right - you get that behavior. If you work in Navigator, you get the > behavior I described. Interesting. Well its a Java-thing, so you can see why it is on a java view and not on the (generic) navigator view. > So if you can do this in Eclipse, why AllTests? Do you subgroup? (I > haven't seen that yet in the test cases...) Like I said before, to allow for use of regular test runners and allow for decoration. Regards, Tim > geirh > >> >> Regards, >> Tim >> > -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: [classlib] test suites
Geir Magnusson Jr wrote: <> > I wonder if it's some vestige of TDD extremos making a point. (I was > reading on JUnit site about AllTests, and how "early adopters" (IOW, > "users") of JUnit who grew up w/o AllTests thought they were nuts, but > the authors Knew Better.) Looks like there are test collectors [1] in JUnit already, but I don't see how they are connected to the runners. Seems to me that it wouldn't be too hard for a test runner to use a collector to create a test suite dynamically, with a hook that allows for suite decoration before it is executed. Regards, Tim [1] http://junit.sourceforge.net/javadoc/junit/runner/ClassPathTestCollector.html -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
Re: [classlib] test suites
Tim Ellison wrote: Geir Magnusson Jr wrote: Tim Ellison wrote: In Eclipse you can click on a project / package / source folder and say "Run As > JUnit Test" -- it will run all the test cases found in there. I tried that and it didn't - it gave me a dialog and let me choose from the tests in there. I couldn't make it do a multi-select. This may be PIBKAC on my part, so let me know. I have a pretty recent Eclipse (3.2M4), and it's there in the context menu for project/package/src folder in the Package Explorer. Alternatively, in the run configurations when you choose a new JUnit type, the "test" tab has a radio button for "run a single test" vs. "run all tests in the selected ..." Don't know if that is a recent addition. Nope. Eclipse is inconstant. If you work in Package Explorer, you're right - you get that behavior. If you work in Navigator, you get the behavior I described. Interesting. So if you can do this in Eclipse, why AllTests? Do you subgroup? (I haven't seen that yet in the test cases...) geirh Regards, Tim
Re: [classlib] test suites
Geir Magnusson Jr wrote: > Tim Ellison wrote: >> In Eclipse you can click on a project / package / source folder and say >> "Run As > JUnit Test" -- it will run all the test cases found in there. > > I tried that and it didn't - it gave me a dialog and let me choose from > the tests in there. I couldn't make it do a multi-select. This may be > PIBKAC on my part, so let me know. I have a pretty recent Eclipse (3.2M4), and it's there in the context menu for project/package/src folder in the Package Explorer. Alternatively, in the run configurations when you choose a new JUnit type, the "test" tab has a radio button for "run a single test" vs. "run all tests in the selected ..." Don't know if that is a recent addition. Regards, Tim -- Tim Ellison ([EMAIL PROTECTED]) IBM Java technology centre, UK.
