Re: [classlib] Warning - our long paths can be a problem for WinXP
FYI, from http://linuxboxadmin.com/articles/filefriction.php : Windows file names can be up to 255 characters, but that includes the full path. A lot characters are wasted if the default storage location is used: C:\Documents and Settings\USER\My Documents\. Regards, David. On 20.07.2006, at 07:53, Geir Magnusson Jr wrote: It's hard to imagine I'm writing this in 2006, but it seems that our paths in classlib, plus a root directory that is some number of directories from c:, can be so long that svn and other tools choke under WinXP. I'm not completely sure, but after battling what appeared to be problematic .svn/tmp directory problems on a svn checkout with a 'deep' root, the problem immediately disappeared when I moved to C:\tmp. Just an FYI. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] smime.p7s Description: S/MIME cryptographic signature
Re: [classlib] Warning - our long paths can be a problem for WinXP
You're right, that's a possibility too. But the command line can be quite long under windows [1] (depending on how you execute the program) so my guess would be that the limitation is the file name length. Regards, David. [1] http://blogs.msdn.com/oldnewthing/archive/2003/12/10/56028.aspx On 20.07.2006, at 09:35, Alexey Petrenko wrote: It also could be the problem of command line length while executing compiler for example. 2006/7/20, David Tanzer [EMAIL PROTECTED]: FYI, from http://linuxboxadmin.com/articles/filefriction.php : Windows file names can be up to 255 characters, but that includes the full path. A lot characters are wasted if the default storage location is used: C:\Documents and Settings\USER\My Documents\. Regards, David. On 20.07.2006, at 07:53, Geir Magnusson Jr wrote: It's hard to imagine I'm writing this in 2006, but it seems that our paths in classlib, plus a root directory that is some number of directories from c:, can be so long that svn and other tools choke under WinXP. I'm not completely sure, but after battling what appeared to be problematic .svn/tmp directory problems on a svn checkout with a 'deep' root, the problem immediately disappeared when I moved to C:\tmp. Just an FYI. geir - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: harmony-dev- [EMAIL PROTECTED] For additional commands, e-mail: harmony-dev- [EMAIL PROTECTED] -- Alexey A. Petrenko Intel Middleware Products Division - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] smime.p7s Description: S/MIME cryptographic signature
Re: [announce] New Apache Harmony Committer : Paulex Yang
Congratulations Paulex! On 17.07.2006, at 01:35, Geir Magnusson Jr wrote: Please join the Apache Harmony PPMC in welcoming the project's newest committer, Paulex Yang. Mark has demonstrated the elements that help build a healthy community, namely his ability to work together with others, continued dedication to the project, an understanding of our overall goals of the project, and a really unnatural and probably unhealthy focus on nio :) We all continue to expect great things from him. Mark, as a first step to test your almighty powers of committership, please update the committers page on the website. That should be a good (and harmless) exercise to test if everything is working. Things to do : 1) test ssh-ing to the server people.apache.org. 2) Change your login password on the machine as per the account email 3) Add a public key to .ssh so you can stop using the password 4) Change your svn password as described in the account email At this point, you should be good to go. Checkout the website from svn and update it. See if you can figure out how. Also, for your main harmony/enhanced/classlib/trunk please be sure that you have checked out via 'https' and not 'http' or you can't check in. You can switch using svn switch. (See the manual) Finally, although you now have the ability to commit, please remember : 1) continue being as transparent and communicative as possible. You earned committer status in part because of your engagement with others. While it was a have to situation because you had to submit patches and defend them, but we believe it is a want to. Community is the key to any Apache project. 2)We don't want anyone going off and doing lots of work locally, and then committing. Committing is like voting in Chicago - do it early and often. Of course, you don't want to break the build, but keep the commit bombs to an absolute minimum, and warn the community if you are going to do it - we may suggest it goes into a branch at first. Use branches if you need to. 3) Always remember that you can **never** commit code that comes from someone else, even a co-worker. All code from someone else must be submitted by the copyright holder (either the author or author's employer, depending) as a JIRA, and then follow up with the required ACQs and BCC. Again, thanks for your hard work so far, and welcome. The Apache Harmony PPMC - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] smime.p7s Description: S/MIME cryptographic signature
Re: [announce] New Apache Harmony Committer : Weldon Washburn
Congratulations! On 05.07.2006, at 17:01, Geir Magnusson Jr wrote: Please join the Apache Harmony PPMC in welcoming the project's newest committer, Weldon Washburn. Weldon was one of the initial committers listed on the original Harmony proposal. Incubator tradition is such that listed committers be granted committer status immediately, but we've altered that process a little and look for continued commitment, participation, alignment and contribution. Weldon certainly has participated beyond the initial proposal in both our community discussions as well as code contributions, most significantly in the classpath library adapter, which we hope this committer status will make it easier to finish :) We all expect continued participation and contribution. Weldon, as a first step to test your almighty powers of committership, please update the committers page on the website. That should be a good (and harmless) exercise to test if everything is working. Things to do : 1) test ssh-ing to the server people.apache.org. 2) Change your login password on the machine as per the account email 3) Add a public key to .ssh so you can stop using the password 4) Change your svn password as described in the account email At this point, you should be good to go. Checkout the website from svn and update it. See if you can figure out how. Also, for your main harmony/enhanced/classlib/trunk please be sure that you have checked out via 'https' and not 'http' or you can't check in. You can switch using svn switch. (See the manual) Finally, although you now have the ability to commit, please remember : 1) continue being as transparent and communicative as possible. You earned committer status in part because of your engagement with others. While it was a have to situation because you had to submit patches and defend them, but we believe it is a want to. Community is the key to any Apache project. 2)We don't want anyone going off and doing lots of work locally, and then committing. Committing is like voting in Chicago - do it early and often. Of course, you don't want to break the build, but keep the commit bombs to an absolute minimum, and warn the community if you are going to do it - we may suggest it goes into a branch at first. Use branches if you need to. 3) Always remember that you can **never** commit code that comes from someone else, even a co-worker. All code from someone else must be submitted by the copyright holder (either the author or author's employer, depending) as a JIRA, and then follow up with the required ACQs and BCC. Again, thanks for your hard work so far, and welcome. The Apache Harmony PPMC - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] smime.p7s Description: S/MIME cryptographic signature
Re: [announce] New Apache Harmony Committer : Mark Hindess
Congratulations! On 09.06.2006, at 05:51, Geir Magnusson Jr wrote: Please join the Apache Harmony PPMC in welcoming the project's newest committer, Mark Hindess. Mark has demonstrated the elements that help build a healthy community, namely his ability to work together with others, continued dedication to the project, an understanding of our overall goals of the project, and some amazing ability in creating build systems :) We all continue to expect great things from him. Mark, as a first step to test your almighty powers of committership, please update the committers page on the website. That should be a good (and harmless) exercise to test if everything is working. Things to do : 1) test ssh-ing to the server people.apache.org. 2) Change your login password on the machine as per the account email 3) Add a public key to .ssh so you can stop using the password 4) Change your svn password as described in the account email At this point, you should be good to go. Checkout the website from svn and update it. See if you can figure out how. Also, for your main harmony/enhanced/classlib/trunk please be sure that you have checked out via 'https' and not 'http' or you can't check in. You can switch using svn switch. (See the manual) Finally, although you now have the ability to commit, please remember : 1) continue being as transparent and communicative as possible. You earned committer status in part because of your engagement with others. While it was a have to situation because you had to submit patches and defend them, but we believe it is a want to. Community is the key to any Apache project. 2)We don't want anyone going off and doing lots of work locally, and then committing. Committing is like voting in Chicago - do it early and often. Of course, you don't want to break the build, but keep the commit bombs to an absolute minimum, and warn the community if you are going to do it - we may suggest it goes into a branch at first. Use branches if you need to. 3) Always remember that you can **never** commit code that comes from someone else, even a co-worker. All code from someone else must be submitted by the copyright holder (either the author or author's employer, depending) as a JIRA, and then follow up with the required ACQs and BCC. Again, thanks for your hard work so far, and welcome. The Apache Harmony PPMC - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: - Terms of use : http://incubator.apache.org/harmony/mailing.html To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] smime.p7s Description: S/MIME cryptographic signature
[Fwd: Re: [classlib] build / test system]
Sorry, was meant for the list... Forwarded Message From: David Tanzer [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [classlib] build / test system Date: Tue, 21 Feb 2006 11:36:23 +0100 It has it's own repository format, and at the moment our repository is quite incomplete. Anyway, several resources in our repository will be downloaded from the maven repository at ibiblio.org. For a later version a feature to convert a complete maven repository to rr format (and maybe vice-versa) is planned AFAIK. Regards, David. On Mon, 2006-02-20 at 21:42 -0500, Geir Magnusson Jr wrote: Will it use a maven repository? This sounds like a lot of the functionality in Maven. Whether you like Maven or not, the fact that there are large repositories of jars is great, so I hope your friend will take advantage of that. David Tanzer wrote: A friend of mine is currently developing a program to manage Java project resources (jars and others) called gc resource repository (gc-rr): http://dev.guglhupf.net/commons/rr/index.html Some of the features are: * Central resource repository to share resources between multiple projects. * Needed resource are downloaded and stored in a local repository. * Dependencies between resources are solved. * Setup the classpath with all needed resources (jars). * Start java progams with the needed resources. * Ant integration to setup the classpath. * Modular ant build script support * Eclipse classpath builder to setup the classpath in eclipse. You may want to take a look at it. It is distributed under the Apache License, and I guess I could convince Rene Pirringer (the main developer of gc-rr) to contribute it to Apache Harmony if this is desired. Best Regards, David Tanzer On Tue, 2006-02-14 at 11:01 +, George Harley wrote: Hi Alexey, The usetimestamp attribute of Ant's get task kind of offers this functionality. Setting the attribute value to true means that the download only proceeds if the local copy of the resource is missing or stale. There is more information on this at http://ant.apache.org/manual/CoreTasks/get.html Best regards, George IBM UK Alexey Petrenko wrote: Well, it would be nice. However I don't like build scripts that depend on network. Yes, there should be the possibility to download needed jars once and forget about network. -- Alexey A. Petrenko Intel Middleware Products Division -- David Tanzer, Haghofstr. 29, A-3352 St. Peter/Au, Austria/Europe http://deltalabs.at -- http://dev.guglhupf.net -- http://guglhupf.net My PGP Public Key: http://guglhupf.net/david/david.asc -- Pinky, Are You Pondering What I'm Pondering? I think so Brain, but if was only supposed to be a three hour tour, why did Howells bring all his money? smime.p7s Description: S/MIME cryptographic signature
Re: [classlib] build / test system
A friend of mine is currently developing a program to manage Java project resources (jars and others) called gc resource repository (gc-rr): http://dev.guglhupf.net/commons/rr/index.html Some of the features are: * Central resource repository to share resources between multiple projects. * Needed resource are downloaded and stored in a local repository. * Dependencies between resources are solved. * Setup the classpath with all needed resources (jars). * Start java progams with the needed resources. * Ant integration to setup the classpath. * Modular ant build script support * Eclipse classpath builder to setup the classpath in eclipse. You may want to take a look at it. It is distributed under the Apache License, and I guess I could convince Rene Pirringer (the main developer of gc-rr) to contribute it to Apache Harmony if this is desired. Best Regards, David Tanzer On Tue, 2006-02-14 at 11:01 +, George Harley wrote: Hi Alexey, The usetimestamp attribute of Ant's get task kind of offers this functionality. Setting the attribute value to true means that the download only proceeds if the local copy of the resource is missing or stale. There is more information on this at http://ant.apache.org/manual/CoreTasks/get.html Best regards, George IBM UK Alexey Petrenko wrote: Well, it would be nice. However I don't like build scripts that depend on network. Yes, there should be the possibility to download needed jars once and forget about network. -- Alexey A. Petrenko Intel Middleware Products Division -- David Tanzer, Haghofstr. 29, A-3352 St. Peter/Au, Austria/Europe http://deltalabs.at -- http://dev.guglhupf.net -- http://guglhupf.net My PGP Public Key: http://guglhupf.net/david/david.asc -- Pinky, Are You Pondering What I'm Pondering? Well, I think so Brain but if Jimmy cracks corn and no one cares, why does he keep doing it? smime.p7s Description: S/MIME cryptographic signature
Re: [classlib] build / test system
On Sun, 2006-02-19 at 10:46 -0600, Archie Cobbs wrote: David Tanzer wrote: A friend of mine is currently developing a program to manage Java project resources (jars and others) called gc resource repository (gc-rr): http://dev.guglhupf.net/commons/rr/index.html Some of the features are: * Central resource repository to share resources between multiple projects. * Needed resource are downloaded and stored in a local repository. * Dependencies between resources are solved. * Setup the classpath with all needed resources (jars). * Start java progams with the needed resources. * Ant integration to setup the classpath. * Modular ant build script support * Eclipse classpath builder to setup the classpath in eclipse. You may want to take a look at it. It is distributed under the Apache License, and I guess I could convince Rene Pirringer (the main developer of gc-rr) to contribute it to Apache Harmony if this is desired. FYI, this sounds very similar to Jpackage.org... is it supposed to be better somehow? I didn't know Jpackage.org so far, but from my first impression gc-rr is somewhat different. The first version was thought as a replacement for the dependency management of maven - you could see it as a better version of the Ant get - task. The current version already has some more features. AFAICS jpackage.org is linux-only (or RPM based systems only) -- am I right here? gc-rr is platform independent. This example (written by Rene) shows how to run an application which depends on 2 libraries - maybe that makes it a little bit clearer how rr works: http://dev.guglhupf.net/commons/rr/example.html -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com -- David Tanzer, Haghofstr. 29, A-3352 St. Peter/Au, Austria/Europe http://deltalabs.at -- http://dev.guglhupf.net -- http://guglhupf.net My PGP Public Key: http://guglhupf.net/david/david.asc -- Pinky, Are You Pondering What I'm Pondering? Well, I think so Brain but if Jimmy cracks corn and no one cares, why does he keep doing it? smime.p7s Description: S/MIME cryptographic signature
This week on harmony-dev (Feb. 12 - Feb. 18 2006) (back again ;) )
/mod_mbox/incubator-harmony-dev/200602.mbox/[EMAIL PROTECTED] [12][http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200602.mbox/[EMAIL PROTECTED] In the thread newbie to project-where to start from there were several questions+answers about where to start when joining the Harmony project. There was also some more discussion about test case naming and other things (compatibility issues, licensing, ...) [13]. Andrey Chernyshev re-opened the thread repo layout again (renamed to Platform dependent code placement [14]. [13][http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200602.mbox/[EMAIL PROTECTED] [14][http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200602.mbox/[EMAIL PROTECTED] In the thread [classlib] do we need a global exclude list? the organisation of test case exclude lists was discussed [15]. There was some Java Performance discussions in I welcome J2SE 6's faster- splash [16]. Geir has moved the security2 module to security and archived the old security module: [classlib] security moved. Some discussion about snapshots followed [17]. Tim Ellison announced a new snapshot: [classlib] Snapshot build 378478 available [18]. [15][http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200602.mbox/[EMAIL PROTECTED] [16][http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200602.mbox/[EMAIL PROTECTED] [17][http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200602.mbox/[EMAIL PROTECTED] [18][http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200602.mbox/[EMAIL PROTECTED] In CLA issues Was: java.sql.* Tor-Einar Jarnbjo, Geir Magnusson Jr. and Leo Simons discussed some details about German laws and the Apache Licenses [19]. There was some more legal discussion (mostly about NDAs) in NDA issues and acceptable use of sun source [20]. [19][http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200602.mbox/[EMAIL PROTECTED] [20][http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200602.mbox/[EMAIL PROTECTED] Regards, David. -- Read the archive of this series at http://deltalabs.at/ -- RSS feed: http://deltalabs.at/?q=taxonomy/term/8/0/feed -- Also aggregated at: http://planet.classpath.org/ -- David Tanzer, Haghofstr. 29, A-3352 St. Peter/Au, Austria/Europe http://deltalabs.at -- http://dev.guglhupf.net -- http://guglhupf.net My PGP Public Key: http://guglhupf.net/david/david.asc -- A fractal is by definition a set for which the Hausdorff Besicovitch dimension strictly exceeds the topological dimension. -- Mandelbrot, The Fractal Geometry of Nature smime.p7s Description: S/MIME cryptographic signature
Re: [VOTE] Accept JIRA contribution HARMONY-16 (Intel's contrib of security code for classlib)
+1 (non-binding), thanks Intel! David. On Tue, 2005-12-20 at 18:55 -0500, Geir Magnusson Jr. wrote: Intel has offered an addition to the classlib effort in the form of security code to the project under the Apache License to Apache Harmony. It can be found here : http://issues.apache.org/jira/browse/HARMONY-16 The paperwork (Bulk Contribution Checklist and supporting documentation) has been received and all documentation is in place. Therefore : [ ] +1 Accept the code into the project sandbox [ ] -1 Don't accept the code. Reason : This vote will close 72 hours from now. (+1 from me, of course...) geir -- David Tanzer, Haghofstr. 29, A-3352 St. Peter/Au, Austria/Europe http://deltalabs.at -- http://dev.guglhupf.net -- http://guglhupf.net My PGP Public Key: http://guglhupf.net/david/david.asc -- METHODEN DER BEWEISFHRUNG -- WISCHWEG - METHODE Man wischt die entscheidenden Stellen des Beweises sofort nach dem Anschreiben wieder weg (rechts schreiben, links wischen). smime.p7s Description: S/MIME cryptographic signature
[jchevm] JCHEVM port to OSX/PPC committed (not yet working)
I have now committed my work on porting JCHEVM to OSX/PPC to trunk since this was suggested by Geir in the Where to put it? - discussion. It compiles successfully on OSX/PPC but doesn't run yet because I left some ppc specific functions unimplemented so far. In case anything went wrong or has to be reverted: The base revision is 354476, the new revision after the commits is 355123 (my first commit was 355107). Regards, David. -- David Tanzer, Haghofstr. 29, A-3352 St. Peter/Au, Austria/Europe http://deltalabs.at -- http://dev.guglhupf.net -- http://guglhupf.net My PGP Public Key: http://guglhupf.net/david/david.asc -- From Jockey for Position, after Pinky sees a similarly stupid looking horse Brain: Dear God, they're multiplying. smime.p7s Description: S/MIME cryptographic signature
Re: [jchevm] Porting JCHEVM to OSX/PPC
The good news first: it compiles now. The problem I described in the previous mail was that libjc was linked with the option -module (so it can be dlopen()ed) and this is not portable. I removed the -module and now it compiles. I stripped out lots of ELF specific stuff, so my version could be interesting for a port to windows too. I just don't want to commit it to trunk yet because it's completely untested. @Archie Cobbs: Is the -module really important for libjc? If yes we'd have to find a portable solution for this... To make it compile I left the funtion _jc_dynamic_invoke(...) in the file libjc/arc/ppc/arch_functions.c empty, but this function is needed to run JCHEVM (it calls C functions and is needed for JNI AFAICS). Maybe somebody with more PPC experience can help me with porting this function from i386. Cheers, David. On Sat, 2005-11-26 at 11:44 +0100, David Tanzer wrote: Hi Again. Now it compiles, but the linking fails: Making all in jc /bin/sh ../libtool --tag=CC --mode=link gcc -g -O2 -g -O3 -pipe -Wall -Waggregate-return -Wcast-align -Wchar-subscripts -Wcomment -Wformat - Wimplicit -Wmissing-declarations -Wmissing-prototypes -Wnested- externs -Wno-long-long -Wparentheses -Wpointer-arith -Wredundant- decls -Wreturn-type -Wswitch -Wtrigraphs -Wuninitialized -Wunused - Wwrite-strings -g -O2 -pthread -o jc main.o ../libjc/libjc.la -ldl - lpopt -lcrypto -lz -lm *** Warning: Linking the executable jc against the loadable module *** libjc.so is not portable! ** Warning, lib libjc.so is a module, not a shared library ** And there doesn't seem to be a static archive available ** The link will probably fail, sorry gcc -g -O2 -g -O3 -pipe -Wall -Waggregate-return -Wcast-align -Wchar- subscripts -Wcomment -Wformat -Wimplicit -Wmissing-declarations - Wmissing-prototypes -Wnested-externs -Wno-long-long -Wparentheses - Wpointer-arith -Wredundant-decls -Wreturn-type -Wswitch -Wtrigraphs - Wuninitialized -Wunused -Wwrite-strings -g -O2 -o .libs/jc main.o - pthread ../libjc/.libs/libjc.so -L/sw/lib -ldl /sw/lib/libpopt.dylib / sw/lib/libintl.dylib /sw/lib/libiconv.dylib -lcrypto -lz -lm powerpc-apple-darwin8-gcc-4.0.1: unrecognized option '-pthread' /usr/bin/ld: ../libjc/.libs/libjc.so is input for the dynamic link editor, is not relocatable by the static link editor again collect2: ld returned 1 exit status make[1]: *** [jc] Error 1 make: *** [all-recursive] Error 1 Something similar is discussed here: http://www.cocoadev.com/index.pl?ApplicationLinkingIssues Maybe somebody here on this list knows how to handle this. Cheers, David. On Thu, 2005-11-24 at 17:22 +0100, David Tanzer wrote: Hi Archie, Thanks for your help so far. etc/makedist.sh runs now, and I have removed some more elf specific stuff from libjc/ (I hope I didn't destroy too much ;)). The build now hangs at libjc/gc_root.c where _JC_REGISTER_OFFS is used for the first time. AFAICS this relies on the i386 registers, so I guess this one will become more tricky to port. I'll have a closer look into that over the weekend. Cheers, David. On Wed, 2005-11-23 at 11:56 -0600, Archie Cobbs wrote: David Tanzer wrote: Thanks, your infos brought me a little bit further. Not etc/makedist.sh fails when it invokes jcjavah for the first time: the _JC_MUTEX_LOCK(...) called from libjc/class_bytes.c (line 102) fails because of EINVAL, I'll have a look at this in the next few days. Maybe you have some hints for me where I could start? Oops, fortunately that's an easy fix.. should be fixed now... svn update and try again. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com -- David Tanzer, Haghofstr. 29, A-3352 St. Peter/Au, Austria/Europe http://deltalabs.at -- http://dev.guglhupf.net -- http://guglhupf.net My PGP Public Key: http://guglhupf.net/david/david.asc -- Real Programmers don't write in FORTRAN. FORTRAN is for pipe stress freaks and crystallography weenies. FORTRAN is for wimp engineers who wear white socks. smime.p7s Description: S/MIME cryptographic signature
Re: [jchevm] Porting JCHEVM to OSX/PPC
On Tue, 2005-11-29 at 16:34 -0600, Archie Cobbs wrote: [...] I stripped out lots of ELF specific stuff, so my version could be interesting for a port to windows too. I just don't want to commit it to trunk yet because it's completely untested. You could create a branch to play with in Subversion. If you do, I recommend also using svnmerge... http://dellroad.org/svnmerge Good Idea, but where would I place that branch? harmony/enhanced/branches/sandbox/contribs/jchevm/osx_port? I'll look at the rest of the issues later... Cheers, David. -- David Tanzer, Haghofstr. 29, A-3352 St. Peter/Au, Austria/Europe http://deltalabs.at -- http://dev.guglhupf.net -- http://guglhupf.net My PGP Public Key: http://guglhupf.net/david/david.asc -- Jeden Tag vorm Einschlafen des Biosavard-Gesetz. Eh klar, do seid ihr high und happy. -- F. Hoislbauer smime.p7s Description: S/MIME cryptographic signature
This week on harmony-dev (Nov. 21 - Nov. 27 2005)
In the thread compiling JCHEVM with MSVC, Ashish Ranjan suggested to use MINGW and MSYS to build native executables with gcc on ms-windows platform. Geir Magnusson Jr. suggested to create binary snapshots of the harmony stuff for people to play with. There was some more discussion about the problems with JCHEVM and MSVC. [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200511.mbox/[EMAIL PROTECTED] There was some discussion about the build process in the thread Code contribution to harmony which was then renamed to Building choices. Andrey Chernyshev posted some some potential issues with a mixed approach (using ant and make in the build process). Tim Ellison answered this concerns. Graeme Johnson gave a good argument for make: it makes the bootstrapping easier, since ant relies on an installed java system. As a reply in this thread, Stefano Mazzocchi wrote an interesting email called Keeping Social Dynamics in Mind where he writes which social impact such a choice can have (and some other interesting things). [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200511.mbox/[EMAIL PROTECTED] [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200511.mbox/[EMAIL PROTECTED] Mikhail Loenko wrote in Contribution of security, crypto, and x-net libraries that they are working on integrating the contribution with the contribution from IBM and that they hope to summarize the problems shortly and mail them to harmony-dev list. Leo Simons replied that you are more than welcome to do such 'sorting out' on this mailing list rather than just send out summaries when its done so we can get more people involved in this discussion. Later this week, Stepan Mishura posted a summary of the integration issues, and Tim Ellison offered to help. [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200511.mbox/[EMAIL PROTECTED] I started the thread [jchevm] Porting JCHEVM to OSX/PPC when I started to port JCHEVM to OSX because I had some questions. Archie Cobbs helped me with some of the issues.Steve Liao answered last weeks email from Kazuyuki Shudo with several technical details about separate jit threads vs. using application threads and simultanious jitting. Rodrigo Kumpera, who has offered to contribute a JVM he has written in Java some time ago, wrote about the status of this development and mentioned that he is still willing to contribute it but he wants to solve some problems before he does. At the moment there's a vote to accept HARMONY-14 into the sandbox running: [vote] accept JIRA contribution HARMONY-14 (IBMs contribution of core classlib, native support and vm/classlib interface), the result should be availiable next week. [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200511.mbox/[EMAIL PROTECTED] [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200511.mbox/[EMAIL PROTECTED] [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200511.mbox/[EMAIL PROTECTED] [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200511.mbox/[EMAIL PROTECTED] Regards, David. -- Read the archive of this series at http://deltalabs.at/ -- RSS feed: http://deltalabs.at/?q=taxonomy/term/8/0/feed -- Also aggregated at: http://planet.classpath.org/ -- David Tanzer, Haghofstr. 29, A-3352 St. Peter/Au, Austria/Europe http://deltalabs.at -- http://dev.guglhupf.net -- http://guglhupf.net My PGP Public Key: http://guglhupf.net/david/david.asc -- Are You Pondering What I'm Pondering? I think so Brain, but wouldn't his movies be more suitable for children if he was named 'Jean Claude Van Darn'? smime.p7s Description: S/MIME cryptographic signature
Re: [jchevm] Porting JCHEVM to OSX/PPC
Hi Archie, Thanks for your help so far. etc/makedist.sh runs now, and I have removed some more elf specific stuff from libjc/ (I hope I didn't destroy too much ;)). The build now hangs at libjc/gc_root.c where _JC_REGISTER_OFFS is used for the first time. AFAICS this relies on the i386 registers, so I guess this one will become more tricky to port. I'll have a closer look into that over the weekend. Cheers, David. On Wed, 2005-11-23 at 11:56 -0600, Archie Cobbs wrote: David Tanzer wrote: Thanks, your infos brought me a little bit further. Not etc/makedist.sh fails when it invokes jcjavah for the first time: the _JC_MUTEX_LOCK(...) called from libjc/class_bytes.c (line 102) fails because of EINVAL, I'll have a look at this in the next few days. Maybe you have some hints for me where I could start? Oops, fortunately that's an easy fix.. should be fixed now... svn update and try again. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com -- David Tanzer, Haghofstr. 29, A-3352 St. Peter/Au, Austria/Europe http://deltalabs.at -- http://dev.guglhupf.net -- http://guglhupf.net My PGP Public Key: http://guglhupf.net/david/david.asc -- A debugged program is one for which you have not yet found the conditions that make it fail. -- Jerry Ogdin smime.p7s Description: S/MIME cryptographic signature
Re: [jchevm] Porting JCHEVM to OSX/PPC
Thanks, your infos brought me a little bit further. Not etc/makedist.sh fails when it invokes jcjavah for the first time: the _JC_MUTEX_LOCK(...) called from libjc/class_bytes.c (line 102) fails because of EINVAL, I'll have a look at this in the next few days. Maybe you have some hints for me where I could start? Cheers, David. On Tue, 2005-11-22 at 14:51 -0600, Archie Cobbs wrote: David Tanzer wrote: First of all the problem with the missing elf.h. Simply copying it from a Linux system doesn't do the job (elf.h has other dependencies, and I didn't want to copy too much headers). Can I remove all the ELF specific stuff? I started doing so, it looks like a lot of work but AFAICS the ELF stuff isn't used anyway in the harmony edition. You can remove any ELF related stuff, it's not used. When time permits I'll work on stripping more stuff out. and added the appropriate headers (see next paragraph). Is there a powerpc-port of the original JCVM and could we use it for harmony? No, x86 is the only port so far. In the directory libjc/arch/ppc i added ppc_definitions.h, ppc_structures.h and ppc_libjc.h. I simply copied the files from the i386 directory and used the FreeBSD - Specific stuff where there were OS differences. This doesn't work for ppc_libjc.h. Here the structure mcontext_t is not defined. Where does that come from on i386? mcontext_t should be defined by #include ucontext.h. Cheers, -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com -- David Tanzer, Haghofstr. 29, A-3352 St. Peter/Au, Austria/Europe http://deltalabs.at -- http://dev.guglhupf.net -- http://guglhupf.net My PGP Public Key: http://guglhupf.net/david/david.asc -- Pinky, Are You Pondering What I'm Pondering? Well, I think so Brain but if Jimmy cracks corn and no one cares, why does he keep doing it? smime.p7s Description: S/MIME cryptographic signature
[Fwd: Re: Call for Contributions (was Re: 4 Months and...)]
Oops, didn't send it to the mailing list. Sorry. Forwarded Message From: David Tanzer [EMAIL PROTECTED] To: Rodrigo Kumpera [EMAIL PROTECTED] Subject: Re: Call for Contributions (was Re: 4 Months and...) Date: Wed, 23 Nov 2005 17:51:05 +0100 Thanks for the status update, cool to hear that you're still working on it. Cheers, David. On Wed, 2005-11-23 at 11:49 -0200, Rodrigo Kumpera wrote: Hi David, I haven´t dropped the idea, my current free time is really small and there are a few problems that I'm facing right know: -A Java JVM must have a JITer, I have one working for windows/x86 except for synchronization and String loading. I don't have even thought about multi-threading issues. -Bootstrapping is really hard, I've been studying how both joeq and jikesRVM work - it's troublesome and fragile. Taken from the mailing list archives I've dropped their approach of mmaping an image and decided for a more conventional approach. Right now I'm generating a COFF object file and linking it as a library, the missing parts are external method linking and making the JITer calling convention aware (java method invocations are diferent from C method invocations). -I want to make the JVM to be debugable as a Java application, this seens to be easier than to generate enouth debug information to make gdb happy. Maybe someone with DWARF-2 or COFF knowledge can say the oposite. -The JVM needs magic types for raw memory access, I've modeled then like MMtk but haven't implemented the magic code generation. I'm not sure that releasing code that perform just some random parts is worth the problem. []'s Rodrigo On 11/21/05, David Tanzer [EMAIL PROTECTED] wrote: Hi Rodrigo, You wrote the email I'm answering to some time ago on harmony-dev. IMHO it would be cool if we had a JVM in Java to compare against BootJVM and JCHEVM. Are you still willing to contribute your JVM? I reply to you directly because I'm not sure if you still want to contribute your JVM. You can also answer to this mail on harmony-dev if you want your answer to be public. Regards, David. On Tue, 2005-09-20 at 11:39 -0300, Rodrigo Kumpera wrote: I've written a pet JVM in Java, it includes a very simple JITer, no GC (but it is starting to use MMtk magic, so should be doable to use it), no self-hosting and no support for native code. The code have never left my machine but I'm willing to donate if is desirable. []'s Rodrigo On 9/20/05, Geir Magnusson Jr. [EMAIL PROTECTED] wrote: On Sep 20, 2005, at 8:52 AM, [EMAIL PROTECTED] wrote: This is not likely to actually attract code. Opening up SVN to committership would. You've described a reverse of how most projects work if you will such that the barrier is to initial commit rather than lazy veto/etc. Most projects give committership to people that have offered code and patches, don't they? geir -Andy Geir Magnusson Jr. wrote: I'd like to restate that we are always looking for code contributions. I do know of some in preparation, but it should be clear that if you have anything to offer (hey, Dan!) please post a note to dev list to discuss. :) geir On Sep 19, 2005, at 5:35 PM, [EMAIL PROTECTED] wrote: Four months and no code. Open up the repository and let the willing start committing. The discussion has gotten so verbose that there are already people publishing edited digests. Code will reduce the discussion :-) -Andy -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] -- David Tanzer, Haghofstr. 29, A-3352 St. Peter/Au, Austria/Europe http://deltalabs.at -- http://dev.guglhupf.net -- http://guglhupf.net My PGP Public Key: http://guglhupf.net/david/david.asc -- Real programmers don't draw flowcharts. Flowcharts are, after all, the illiterate's form of documentation. Cavemen drew flowcharts; look how much good it did them. -- David Tanzer, Haghofstr. 29, A-3352 St. Peter/Au, Austria/Europe http://deltalabs.at -- http://dev.guglhupf.net -- http://guglhupf.net My PGP Public Key: http://guglhupf.net/david/david.asc -- Pinky, Are You Pondering What I'm Pondering? Well, I think so Brain but if Jimmy cracks corn and no one cares, why does he keep doing it? smime.p7s Description: S/MIME cryptographic signature
[jchevm] Porting JCHEVM to OSX/PPC
Hi All, Is there anybody still working on an OSX/PPC port of JCHEVM? I tried to compile it on my iBook today and looked a little bit into it, but I'll not be able to do the port without some help. I read through the discussion which followed Archie Cobbs's announcement of the contribution [1] where Andy Oliver tried to port it, but I didn't find all the answers there. I don't really have experience with arch-specific stuff or porting to OSX/PPC, so if there's someone who wants to do the port instead of me I wouldn't mind too. First of all the problem with the missing elf.h. Simply copying it from a Linux system doesn't do the job (elf.h has other dependencies, and I didn't want to copy too much headers). Can I remove all the ELF specific stuff? I started doing so, it looks like a lot of work but AFAICS the ELF stuff isn't used anyway in the harmony edition. I saw that there is the following construct in some of the header files: #elif defined(__powerpc__) #include powerpc/powerpc_[some-header].h #endif which I extended to: #elif defined(__powerpc__) #include powerpc/powerpc_[some-header].h #elif defined(__ppc__) #include ppc/ppc_[some-header].h #endif and added the appropriate headers (see next paragraph). Is there a powerpc-port of the original JCVM and could we use it for harmony? In the directory libjc/arch/ppc i added ppc_definitions.h, ppc_structures.h and ppc_libjc.h. I simply copied the files from the i386 directory and used the FreeBSD - Specific stuff where there were OS differences. This doesn't work for ppc_libjc.h. Here the structure mcontext_t is not defined. Where does that come from on i386? Regards, David [1] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200509.mbox/[EMAIL PROTECTED] -- David Tanzer, Haghofstr. 29, A-3352 St. Peter/Au, Austria/Europe http://deltalabs.at -- http://dev.guglhupf.net -- http://guglhupf.net My PGP Public Key: http://guglhupf.net/david/david.asc -- From Meet John Brain Brain: Pinky, once I take over the world, remind me to publicly snub you. smime.p7s Description: S/MIME cryptographic signature
Re: [vote] Accept keyword scan contribution (JIRA : http://issues.apache.org/jira/browse/HARMONY-15)
+1 from me too. On Thu, 2005-11-17 at 21:53 +, Tim Ellison wrote: +1 Accept the HARMONY-15 contribution of the keyword scan tool and keyword list Regards, Tim -- David Tanzer, Haghofstr. 29, A-3352 St. Peter/Au, Austria/Europe http://deltalabs.at -- http://dev.guglhupf.net -- http://guglhupf.net My PGP Public Key: http://guglhupf.net/david/david.asc -- Jeden Tag vorm Einschlafen des Biosavard-Gesetz. Eh klar, do seid ihr high und happy. -- F. Hoislbauer smime.p7s Description: S/MIME cryptographic signature
Re: GNU Classpath hacker room at FOSDEM 2006
I'll try to come too. David. On Mon, 2005-11-14 at 22:50 -0500, Geir Magnusson Jr. wrote: I'll definitely be there - thanks for the note, Mark. Will you let us in the GNU Classpath hacker room though? :) geir On Nov 14, 2005, at 11:33 AM, Mark Wielaard wrote: Hi all, Like the last couple of years we want to come together with all the projects around GNU Classpath and the various free runtimes, compiler and tool projects to discuss what has happened in the last year in the Free Software community and what the next year will bring us during FOSDEM. The 6th edition of FOSDEM (Free and Opensource Software Developers' European Meeting) will take place on February 25+26 2006 in Brussels (Belgium), at the Solbosch Campus of the ULB (Free University of Brussels). FOSDEM is a free and non-commercial event for the community and organized by the community. See http://www.fosdem.org/ We were thinking of the following setup: - Saturday from 13:00 to 17:30 - End-User talks presentations to promote what we all build together to a wider audience that might have heard of what we do, but haven't actually seen it in action/put together. We might also want to have a lightning hour with lots of quick Demos of applications running on a completely free stack (5 - 10 minutes per demo). - Sunday from 09:00 to 12:30 - Developer talks presentations of things that are in progress and that people want to explain in more depth to get developers of the other projects to join in a share the fun. - Sunday from 13:00 to 17:30 - The Future hard core interactive technical hacker discussions on how to integrate the projects more and move forward in the next year. Arnaud Vandyck, Dalibor Topic, Mark Wielaard, Michael Koch and and Tom Tromey will be our program committee this year. If you would like to present something, have an idea for a demo or discussion topic please let us know at fosdem-at-developer.classpath.org Please mention the title, a little abstract, which track and whether you want to do a quick demo, a short 30 min talk or full hour talk (we prefer 30 minute talks to give everybody a chance to present something). Deadline for proposals is December 18, so you have a month to think of something cool. Then we make sure to have some kind of formal program at the start of January. Examples of presentations and reports from previous years: http://www.gnu.org/software/classpath/events/escape_fosdem05.html http://www.gnu.org/software/classpath/events/fosdem04.html Some ideas for interesting topics: - Free Swing - The Demo! - Your GNU/Linux distro and the free runtimes - package overview. - From 0 to 100 in 15 Minutes: Getting started with GNU Classpath development using Eclipse, JamVM, Mauve, and the ChangeLog plugin! - Integrating with Objectweb through native-(gcj)-JOnAS - Writing OpenOffice.org plugins using a free software stack. - Using GNU Classpath/gcj/kaffe for games - Using free runtimes on Wine and other win32 environments - Embedding GNU Classpath in web browsers and support for JNLP - Security Auditing! - 1.5 language support in GNU Classpath, gcjx and the free runtimes - GNU Classpath/OSGi/J2ME/Library splitting and trimming - Harmony through interfacing. - Beyond JAPI: what is needed to really finish GNU Classpath Or, Beyond Java -- what we can do when we finish 1.5. Or more generally some kind of presentation about development metrics: bug rates, rates of change in japi/lines of code/tests, email volume, stuff like that. - Debugging, JDWP development efforts. - etc. Hope to see you in Brussels on February 25 and 26 2006, Arnaud, Dalibor, Mark, Michael and Tom -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/ -- David Tanzer, Haghofstr. 29, A-3352 St. Peter/Au, Austria/Europe http://deltalabs.at -- http://dev.guglhupf.net -- http://guglhupf.net My PGP Public Key: http://guglhupf.net/david/david.asc -- Meet John Brain Episode: Brain: Pinky, Are You Pondering What I'm Pondering? Pinky: I think so, Brain, but this time, you put the trousers on the chimp. smime.p7s Description: S/MIME cryptographic signature
This (and last) week on harmony-dev (Oct. 31 - Nov. 13 2005)
the requirements for an interface between the VM and the Execution Engine which supports both interpreters and JITs. He wrote it according to the 4 areas in the previous email: abstracting over the mode of execution, asynchronous compilation, reentrancy, and supporting the mixing of JIT and interpreter. [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200511.mbox/[EMAIL PROTECTED] In other threads... Jean-frederic Clere and Dan Lydick discussed about some configuration issues of BootJVM in [BootJVM] configure. Archie Cobbs and Tim Ellison where talking about some finalization issues in Some questions about the architecture. Archie Cobbs (who contributed jchevm [which is not called ArchieVM :( ]) is our newes Apache Harmony committer. Leo Simons wrote The Unofficial Harmony, Licensing, the Universe and everything FAQ where he answeres several questions which have always been around on the list. Mark Wielaard wrote some interesting comments here. Leo Simons wrote about Harmony @ Apachecon US 2005. Dan Lydick sent in a status info for BootJVM in a mail called Current changes to bootJVM source base. Mark Wielaard announced ANN: GNU Classpath 95% and counting 0.19 released. [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200510.mbox/[EMAIL PROTECTED] [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200510.mbox/[EMAIL PROTECTED] [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200511.mbox/[EMAIL PROTECTED] [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200511.mbox/[EMAIL PROTECTED] [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200511.mbox/[EMAIL PROTECTED] [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200511.mbox/[EMAIL PROTECTED] [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200511.mbox/[EMAIL PROTECTED] pBTW: You might have noticed that I didn't list all people involved in the discussions this week. I'm not sure if this is really nessessary, but I'd really appreciate feedback about this. Would you want to be listed here when you've been involved in a discussion, or is it enough when I only mention some people which wrote important postings? Regards, David. -- Read the archive of this series at http://deltalabs.at/ -- RSS feed: http://deltalabs.at/?q=taxonomy/term/8/0/feed -- Also aggregated at: http://planet.classpath.org/ -- David Tanzer, Haghofstr. 29, A-3352 St. Peter/Au, Austria/Europe http://deltalabs.at -- http://dev.guglhupf.net -- http://guglhupf.net My PGP Public Key: http://guglhupf.net/david/david.asc -- Pavlov's Mice Episode: Brain: Are you thinking what I'm thinking, Pinky? Pinky: Uh... yeah, Brain, but where are we going to find rubber pants our size? smime.p7s Description: S/MIME cryptographic signature
Re: Apache Harmony welcomes Archie Cobbs as our newest committer
Congratulations! On Mon, 2005-11-07 at 22:13 -0500, Geir Magnusson Jr. wrote: The Apache Harmony PPMC is proud to announce Archie Cobbs as our newest Apache Harmony committer, and look forward to seeing him continue his work on jcheVM (now in sandbox/contribs/jchevm), as well as other areas of his interest. Archie has shown a long-standing and broad-ranging interest in the project, and this will allow him to continue working on his initial contribution. We believe he is an excellent addition to the project and will help others in the community with his experience and knowledge. Congratulations, The Apache Harmony PPMC -- David Tanzer, Haghofstr. 29, A-3352 St. Peter/Au, Austria/Europe http://deltalabs.at -- http://dev.guglhupf.net -- http://guglhupf.net My PGP Public Key: http://guglhupf.net/david/david.asc -- Pinky, Are You Pondering What I'm Pondering? I think so Brain, but isn't that why they invented tube socks? smime.p7s Description: S/MIME cryptographic signature
This week on harmony-dev (Oct. 23 - Oct. 31 2005)
as possible. [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200510.mbox/[EMAIL PROTECTED] [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200510.mbox/[EMAIL PROTECTED] [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200510.mbox/[EMAIL PROTECTED] Regards, David. -- Read the archive of this series at http://deltalabs.at/ -- RSS feed: http://deltalabs.at/?q=taxonomy/term/8/0/feed -- Also aggregated at: http://planet.classpath.org/ -- David Tanzer, Haghofstr. 29, A-3352 St. Peter/Au, Austria/Europe http://deltalabs.at -- http://dev.guglhupf.net -- http://guglhupf.net My PGP Public Key: http://guglhupf.net/david/david.asc -- Pinky: Hmmm... let me think... Brain: Don't hurt yourself, Pinky. -- Bubba Bo Bob Brain smime.p7s Description: S/MIME cryptographic signature
Re: [dev-process] Coding Style Guide
On Sat, 2005-10-22 at 10:42 +0200, Leo Simons wrote: On Fri, Oct 21, 2005 at 04:58:29PM +0200, David Tanzer wrote: I've just had a look at some C code from jchevm and BootJVM to compare the coding style of both contributions. Both use coding styles which are quite common for C source code but they are slightly different, and I don't think that's good. We should really define a coding style guide before even more code is contributed. *shrug*. A Foolish Consistency is the Hobgoblin of Little Minds (http://www.python.org/doc/essays/styleguide.html) The most important thing with coding style guides is that they don't get in the way of actual work or that discussing them turns into big flamewars or anything like that. IMNSHO. Ok, I didn't want to start a flame war (and AFAICS I didn't do so yet), and you're right, such a style guide should not get in the way of development. OTOH it has some advantages to have one and I've read on this list that others like the idea of a coding style guide too. Also it's good to know when *not* to apply such a style guide, but IMHO it's better to have a law you can break ;-). The rest IMHO. The second most important thing is consistency on a file-by-file basis. The third most important thing to note is that doing lots of reformatting halfway through a project makes the diffs harder to read, so it *is* something to do as early as possible. Exactly what I wanted to say. If we want such a style guide we should write it soon before too much code is contributed. [Snip] I like the kaffe one too: http://www.kaffe.org/doc/kaffe/FAQ.coding-style :-) :-D In any case, perhaps someone should just start a wiki page with some kind of policy on it and everyone that doesn't like the policy can change it so that what they're doing complies with that policy. See how it goes :-) Maybe I'll start one next week, this weekend I won't have too much time for that. cheers! Leo Cheers, David. -- David Tanzer, Haghofstr. 29, A-3352 St. Peter/Au, Austria/Europe http://deltalabs.at -- http://dev.guglhupf.net -- http://guglhupf.net My PGP Public Key: http://guglhupf.net/david/david.asc -- Are You Pondering What I'm Pondering? I think so Brain, but there's still a bug in there from last time. smime.p7s Description: S/MIME cryptographic signature
This week on harmony-dev (Oct. 16 - Oct. 22 2005)
/[EMAIL PROTECTED] [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200510.mbox/[EMAIL PROTECTED] [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200510.mbox/[EMAIL PROTECTED] Regards, David. -- Read the archive of this series at http://deltalabs.at/ -- RSS feed: http://deltalabs.at/?q=taxonomy/term/8/0/feed -- Also aggregated at: http://planet.classpath.org/ -- David Tanzer, Haghofstr. 29, A-3352 St. Peter/Au, Austria/Europe http://deltalabs.at -- http://dev.guglhupf.net -- http://guglhupf.net My PGP Public Key: http://guglhupf.net/david/david.asc -- Pinky, Are You Pondering What I'm Pondering? I think so Brain, but if they called them sad meals, kids wouldn't buy them. smime.p7s Description: S/MIME cryptographic signature
[dev-process] Coding Style Guide
I've just had a look at some C code from jchevm and BootJVM to compare the coding style of both contributions. Both use coding styles which are quite common for C source code but they are slightly different, and I don't think that's good. We should really define a coding style guide before even more code is contributed. I'm not worried about Java code we write, because I assume everyone agrees to use the Java Coding Conventions from Sun [1] here. Much of the development in Harmony is done in C at the moment, and we need a coding style guide here too. I once suggested to use the Java Coding Conventions in C and C++ code too [2] (at least where possible, and we'd have to extend them to cover pre-processor directives and other C/C++ specific things). We could also use a style like Archie Cobbs or Dan Lydick used in their contributions, but IMHO we should write it down and then stick to it. Mark Wielaard provided a link to the project policy of GNU Classpath [3], I guess we could get some Ideas from this too. Regards, David [1] http://java.sun.com/docs/codeconv/ [2] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200508.mbox/[EMAIL PROTECTED] [3] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200510.mbox/[EMAIL PROTECTED] -- David Tanzer, Haghofstr. 29, A-3352 St. Peter/Au, Austria/Europe http://deltalabs.at -- http://dev.guglhupf.net -- http://guglhupf.net My PGP Public Key: http://guglhupf.net/david/david.asc -- Pinky, Are You Pondering What I'm Pondering? Umm, I think so Big Brainy Fish Face Stove Pipe Wiggle Room Eileen. But if you get a long little doggie, wouldn't you just call it a dachshund? smime.p7s Description: S/MIME cryptographic signature
This week on harmony-dev (Oct. 9 - Oct. 15 2005)
Sorry, no links to the mail archive today because the new version of the archive doesn't work for me (Mozilla Firefox / Fedora Core 4). This week almost all discussions on this mailing list where in the thread [legal] Bulk contribution barrier to entry which was started by Geir Magnusson Jr. The problem he mentiones there is that for a bulk contribution - something created elsewhere and being contributed to harmony - we require that all authors of that work are Authorized Contributors, meaning that they hadn't been exposed to implementations of Java that weren't either available under an open source license, or were owned by an entity willing to give the author permission to work on other implementations elsewhere. He means that this standard might be too high, because there might be contributions where it might be hard or even impossible to track down all the authors. He asked for suggestions for a process which is flexible enough to allow all kinds of contributions, but which is OTOH strong enough to not put our project at unnessessary risks. This was followed by a long discussion about which specific permissions we need from whom and which risks the harmony project could be exposed to. I think I won't go further into details for this thread. There was no solution found yet. The people involved in this discussion are: Danese Cooper, Dermot Dunnion, Leo Simons, Dalibor Topic, Archie Cobbs and Richard Nienaber. Geir Magnusson Jr. made some changes to BootJVM to get in working under windows. He also got it working in OS X. Enrico Migliore posted some benchmark results he tested out in an email called optimization for speed in win32. Robin Garner announced a new version of the DaCapo benchmarks which are a set of real-world open-source Java benchmarks that have a non-trivial memory load and now come under the Apache License. Mark Wielaard announced a new version (0.7.6) of gjdoc, which is the source documentation framework for GNU Classpath. Regards, David. -- Read the archive of this series at http://deltalabs.at/ -- RSS feed: http://deltalabs.at/?q=taxonomy/term/8/0/feed -- Also aggregated at: http://planet.classpath.org/ -- David Tanzer, Haghofstr. 29, A-3352 St. Peter/Au, Austria/Europe http://deltalabs.at -- http://dev.guglhupf.net -- http://guglhupf.net My PGP Public Key: http://guglhupf.net/david/david.asc -- Pinky, Are You Pondering What I'm Pondering? I think so Brain, but how do we get a pair of Abe Vegoda's pants? smime.p7s Description: S/MIME cryptographic signature
Re: Apache Harmony welcomes Daniel Lydick as our newest committer
Congratulations Daniel! On Fri, 2005-10-14 at 02:13 -0400, Geir Magnusson Jr. wrote: The Apache Harmony PPMC is proud to announce Daniel Lydick as our newest Apache Harmony committer, and look forward to seeing him continue his work on his BootJVM (now in sandbox/contribs/bootJVM), as well as other areas of his interest. His work shows initiative, self-motivation and attention to detail. By contributing this work and wishing to continue development here in Harmony, he's clearly willing to work with others and looking for feedback. We believe he will be an excellent addition to the project and will help foster these values in others. Congratulations, The Apache Harmony PPMC -- David Tanzer, Haghofstr. 29, A-3352 St. Peter/Au, Austria/Europe http://deltalabs.at -- http://dev.guglhupf.net -- http://guglhupf.net My PGP Public Key: http://guglhupf.net/david/david.asc -- Pinky, Are You Pondering What I'm Pondering? I think so Brain, but this time you put the trousers on the chimp. smime.p7s Description: S/MIME cryptographic signature
Re: [vote] Accept JIRA contribution HARMONY-3 : Archie Cobbs' Contribution of JCVM
+1 (non-binding) On Fri, 2005-09-30 at 17:43 -0400, Geir Magnusson Jr. wrote: +1 from me I was concerned about the provenance given some of the statement found in the contribution, but Archie's explanation and statement of it being his original work based on exposure to only open-source implementations is fine for me. This is going into the sandbox - if we happen to discover an issue about this in the near future, we can simply fix it. On Sep 30, 2005, at 5:18 PM, Geir Magnusson Jr. wrote: Archie Cobbs has offered the JCVM project under the Apache License to Apache Harmony. It can be found here : http://issues.apache.org/jira/browse/HARMONY-3 [ ] +1 Accept the code into the project sandbox [ ] -1 Don't accept the code. Reason : This vote will close 72 hours from now. geir -- Geir Magnusson Jr +1-203-665-6437 [EMAIL PROTECTED] -- David Tanzer, Haghofstr. 29, A-3352 St. Peter/Au, Austria/Europe http://deltalabs.at -- http://dev.guglhupf.net -- http://guglhupf.net My PGP Public Key: http://guglhupf.net/david/david.asc -- A large number of installed systems work by fiat. That is, they work by being declared to work. -- Anatol Holt signature.asc Description: This is a digitally signed message part
This week on harmony-dev (Sept. 25 - Oct. 1 2005)
Archie Cobbs contributed a part of the JCVM to the project in the JIRA which might be called JCHE (JC Harmony Edition) within harmony. Andy Oliver tried to port it to OSX but had problems with the required packages. Santiago Gala, Stefano Mazzocchi, Archie Cobbs and Dalibor Topic tried to help, but Andy didn't get it running so far. [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200509.mbox/[EMAIL PROTECTED] Michael Koch asked in How to package a contribution if it's OK to dual-license a contribution (i.e. GPL and AL), Geir Magnusson Jr answered that he's free to do so and that he would encourage this to bring the communities together. [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200509.mbox/[EMAIL PROTECTED] I have added my proof-of-concept component model to JIRA and later there was the vote [vote] Accept JIRA contribution HARMONY-5 : David Tanzer's proof-of-concept component model about it. It was accepted with 3 binding votes from the PPMC (geir, dims, stefano) and it can now be found in https://svn.apache.org/repos/asf/incubator/harmony/enhanced/trunk/sandbox/contribs/tanzer_component There where a total of 10x +1, 1x 0 and 1x -1 votes. [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200509.mbox/[EMAIL PROTECTED] [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200509.mbox/[EMAIL PROTECTED] During this vote and a vote about the JCVM contribution some aspects of this voting process have been explained again. Everybody should vote because the opinion of the whole community is important, but the binding votes are the PPMC while in incubation, and the PMC when out of incubation. A vote needs three binding +1 votes to be accepted (with no -1 votes). In this context +1 means yes, -1 means no and 0 means don't care. Geir Magnusson Jr. also clarified that in votes for code for the sandbox: No one is going to reject contributions to the sandbox except for reasons of code provenance - i.e. 'Hey, that's Sun's source!' - or complete misalignment with project, such as someone donating an EJB container or something. [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200509.mbox/[EMAIL PROTECTED] [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200509.mbox/[EMAIL PROTECTED] [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200509.mbox/[EMAIL PROTECTED] In the thread [Arch] Class unloading and VM objects reclaim Usman Bashir explained a model where every class loader manages his part of the memory. Archie Cobbs replied that this would work, but he asked what we would gain with this approach. There has been no answer yet. [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200509.mbox/[EMAIL PROTECTED] The vote [vote] Accept JIRA contribution HARMONY-3 : Archie Cobbs' Contribution of JCVM is currently running. Daniel Lydick has posted a basic Java Virtual Machine entitled the 'Apache Harmony Bootstrap JVM.' as a JIRA contribution. Mark Wielaard has sent in a report from the GNU Classpath distro DevJam telling us it was a great success (congrats!). [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200509.mbox/[EMAIL PROTECTED] [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200509.mbox/[EMAIL PROTECTED] [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200509.mbox/[EMAIL PROTECTED] Regards, David. -- Read the archive of this series at http://deltalabs.at/ -- RSS feed: http://deltalabs.at/?q=taxonomy/term/8/0/feed -- Also aggregated at: http://planet.classpath.org/ -- David Tanzer, Haghofstr. 29, A-3352 St. Peter/Au, Austria/Europe http://deltalabs.at -- http://dev.guglhupf.net -- http://guglhupf.net My PGP Public Key: http://guglhupf.net/david/david.asc -- Pinky, Are You Pondering What I'm Pondering? Well, I think so Brain, but apply North Pole to what?
Re: [vote] Accept JIRA contribution HARMONY-5 : David Tanzer's proof-of-concept component model
On Fri, 2005-09-30 at 02:58 -0400, Geir Magnusson Jr. wrote: On Sep 30, 2005, at 2:51 AM, Mladen Turk wrote: Geir Magnusson Jr. wrote: David Tanzer has offered his proof-of-concept component model to the project. It can be found here : http://issues.apache.org/jira/browse/HARMONY-5 [ ] +1 Accept the code into the project [X] -1 Don't accept the code. Reason : The code itself is posix only. It's a proof of concept for the sandbox! This isn't a commitment to the idea or the implementation, but just getting it in so people can play Right, that's what my intention was, nothing more. If we continue this way, porting to the other platforms will become impossible. Even the simple posix itself is incompatible between various flavors. For example on AIX there is 'archive.a(dso.so)' and dlopen needs 'RTLD_NOW | RTLD_GLOBAL | RTDL_MEMBER' flags. Some platforms like HPUX use the shl_load, not to mention the Windows or Netware. The actual code itself exists, and is very much mature within Apache2, and module dependencies are implemented within apr-iconv project, so perhaps this would be a way to go. APR? I think that we'll leverage APR heavily. Whether or not the APR API is the one we use as the standard porting layer API remains to be seen. If not, I'm certain will used it for platform implementations of the porting layer... There are several places in the code where I've added comments about things that have to be changed if we really use this component model. Note that there are also serious concerns about performance in a runtime-configurable component model and Robin Garner suggested to aim for compile time configurability (See [1]). APR would definitely be a better choice than posix, but AFAICS the decision about what our portability layer will be has not been made yet. Also, what about coding style guide? That's a good question, and something I assume we'll converge around as we get moving. I totally agree with that. I discussed earlier with Weldon Washburn and Geir about using the Java Coding Conventions where possible (See [2] and follow-ups), but this still doesn't cover things like directory structure, some aspects of documentation policy, etc., and there was no decision yet. Regards, David. [1] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200509.mbox/[EMAIL PROTECTED] [2] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200508.mbox/[EMAIL PROTECTED] geir Regards, Mladen. -- David Tanzer, Haghofstr. 29, A-3352 St. Peter/Au, Austria/Europe http://deltalabs.at -- http://dev.guglhupf.net -- http://guglhupf.net My PGP Public Key: http://guglhupf.net/david/david.asc -- Jockey for Position Episode: Brain: Pinky, Are You Pondering What I'm Pondering? Pinky: Wuh, I think so, Brain, but isn't Regis Philbin already married? signature.asc Description: This is a digitally signed message part
Re: This week on harmony-dev (Sept. 18 - Sept. 24 2005)
On Mon, 2005-09-26 at 10:00 +0100, Tim Ellison wrote: David Tanzer wrote: Later this week, Rodrigo Kumpera contributed a JVM he has written in Java. ... AFAIK Rodrigo hasn't contributed his VM (yet), but made a generous offer [1] to donate if is desirable. I'd say that it *is* desirable to have Rodrigo's contribution as the seed for a Java-based VM study. You are right, thank you for this hint. I have corrected it in the blog. Regards, David Of course, since the summary was written we also got a contribution from archie [2] of key parts of the JCVM (= JCHE). Regards, Tim [1] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200509.mbox/[EMAIL PROTECTED] [2] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200509.mbox/[EMAIL PROTECTED] -- David Tanzer, Haghofstr. 29, A-3352 St. Peter/Au, Austria/Europe http://deltalabs.at -- http://dev.guglhupf.net -- http://guglhupf.net My PGP Public Key: http://guglhupf.net/david/david.asc -- Pinky: Narf! Pinky: Poit! Pinky: Zort! Pinky: Gat! signature.asc Description: This is a digitally signed message part
Re: [arch] VMCore / Component Model
I have now added the prototype implementation to JIRA: http://issues.apache.org/jira/browse/HARMONY-5 Cheers, David. On Mon, 2005-09-19 at 19:46 +0200, David Tanzer wrote: Today I have added some additional Information to the Wiki page. We should also consider using C++ and abstract classes to maintain our component model. While this would make inter-component communication slightly slower it would be easier to maintain. We should also think about using an existing component model like OSGi. The model I posted provides pretty fast communication between components without sacrificing too much flexibility, but it is maybe not as easy to maintain as a clean, object-oriented implementation (i.e. C++). We could discuss how important these aspects are to us, i.e. how much runtime efficiency we are willing to sacrifice for maintainability and flexibility and vice-versa. Regards, David. On Fri, 2005-09-16 at 21:47 +0200, David Tanzer wrote: Ok, it took a little bit longer than I first expected, but now my proof-of-concept implementation of the component model I described is available in the wiki: http://wiki.apache.org/harmony/ComponentModelFunctionPointers I have also linked it from the harmony architecture page. It contains a mechanism for loading components and a basic versioning and dependency management mechanism. The test case loads two components, where one depends on the other. I'll add some more explanations to the wiki page when I have more time, hopefully at the weekend. I have made several assumptions about the directory structure, the coding conventions and the documentation conventions, we should maybe discuss this in a different thread. Regards, David. On Tue, 2005-09-13 at 17:27 +0100, Tim Ellison wrote: David Tanzer wrote: Since we already started to define some component interfaces I think we also should start thinking about a component model which loads / connects such components. Maybe there are also some existing solutions we might want to look at (I must confess I didn't really search yet). Agreed, plus managing the API itself to ensure forwards/backwards version compatibility. I guess a requirement for such a component manager would be that it can load and connect components at runtime and that the specific implementations which are loaded can be configured. It might also be good if the same component implementations can be linked at compile time (i.e. statically) which could have benefits on embedded platforms, but I'm not sure if we really need this. I'm assuming that you are speculating on component management beyond the platform support (i.e. DLL-hell). The java world is already on this path with the OSGi framework (e.g. Felix). It will require a non-trivial solution to ensure that the runtime flexibility does not incur an unacceptable runtime cost. Another requirement would be that the components can be written in different programming languages (i.e. C, C++, Java, ...). It isn't really a problem to solve this for C and C++, but can we also easily support other programming languages? A simple way to implement such a component model in C would be an approach similar to the one Tim Ellison described in [1] where he explains the structure of the J9 VM's portability library. I started writing a proof of concept implementation for this, and I'll add it to the wiki as soon as it's finished. I look forward to seeing the proof of concept. Were you thinking of introducing versioning and dependency management style functions? It would be interesting to have several such proof-of-concept implementations of component models which we can study and the decide which to use. We could even write import mechanisms for the different component models so they can import and use components from another model too (of course this would normally imply reduced performance). Regards, David. [1] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200509.mbox/[EMAIL PROTECTED] -- David Tanzer, Haghofstr. 29, A-3352 St. Peter/Au, Austria/Europe http://deltalabs.at -- http://dev.guglhupf.net -- http://guglhupf.net My PGP Public Key: http://guglhupf.net/david/david.asc -- Brain: Pinky, I am in considerable pain. Pinky: Narf! Zort! Poit! Gat! I'm with you, Brain! -- Twas the Day Before Christmas signature.asc Description: This is a digitally signed message part
This week on harmony-dev (Sept. 18 - Sept. 24 2005)
into what I think would be more difficult in optimized code vs. non-optimized.. [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200509.mbox/[EMAIL PROTECTED] Also in this thread, Michael Haupt asked if startup-time in a JIT-only environment could be increased by caching the code on disk. Will Pugh and Tom Tromey explained that this is possible and what has to be considered to make this possible. [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200509.mbox/[EMAIL PROTECTED] In the thread [Arch] Suggestion to prioritize JVMTI over JVMPI and JVMDI, Chris Elford suggested we should concentrate our debug/tools interface work in Harmony to making JVMTI work really well and let JVMPI and JVMDI fall away. Geir Magnusson Jr. pointed out that we can only do so if we jump ahead to J2SE 6 rather than implement J2SE 5 (assuming they are dropped), but as long as we are working on J2SE 5 we have to support them. [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200509.mbox/[EMAIL PROTECTED] Xiao-Feng Li wrote an email called [arch] On finalizer design where he writes some points about finalizers in a JVM and he asks how others think about this. Robin Garner and Weldon Washburn discussed about the VM/GC interface Weldon posted earlier in the thread [arch] Modular JVM component diagram. Robin posted a link to a paper where he discribes the VM - GC interface of MMTk and asked some questions about the interfaces posted by Weldon, and Weldon answered them and said he'll post more info later. [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200509.mbox/[EMAIL PROTECTED] [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200509.mbox/[EMAIL PROTECTED] Regards, David. -- Read the archive of this series at http://deltalabs.at/ -- RSS feed: http://deltalabs.at/?q=taxonomy/term/8/0/feed -- Also aggregated at: http://planet.classpath.org/ -- David Tanzer, Haghofstr. 29, A-3352 St. Peter/Au, Austria/Europe http://deltalabs.at -- http://dev.guglhupf.net -- http://guglhupf.net My PGP Public Key: http://guglhupf.net/david/david.asc -- AUFGABEN DER PHYSIK -- QUANTENMECHANIK Gegebene Konstante: m(Kuh)=400 kg Die Kuh befinde sich auf einer Weide, die ringsum durch einen Zaun abgegrenzt ist. Der Weidezaun sie ideal gebaut, sodass die Kuh ihn (klassich gesehen) nicht passieren kann. Begrnden Sie, dass man die Kuh trotzdem mit gewisser Wahrscheinlichkeit ausserhalb der Weide antrifft.
Re: Code into SVN, not the WIKI (Re: [arch] VMCore / Component Model)
Geir Magnusson Jr. wrote: Lets not store code in the wiki, but rather SVN. There's no control on a WIKI, so we have no clue what it is or really where it came from. I totally agree with that, I just didn't know if I have SVN write access and how we structure the repository. I guess it would be good to set up a playground or sandbox where we can play around with prototypes like the one I've provided. As you know, we are being very careful about code pedigree for all sorts of good reasons. If you would like to get this code into SVN so others can start tweaking and playing, we should do that. 1) To get started, first look at the Authorized Contributor Questionnaire (ACQ) http://incubator.apache.org/harmony/auth_cont_quest.html or http://incubator.apache.org/harmony/auth_cont_quest.txt and fill out a copy, print it, and sign it. Fax to +1 203 665 6400 (that's my fax #). 2) Fill out an ICLA as required by part IV of the ACQ above http://www.apache.org/licenses/icla.txt print it, and sign it. Fax to same number. I have sent both documents via snail mail to Apache Software Foundation 1901 Munsey Drive, Forest Hill, MD 21050-2747 U.S.A. should I still fax it to you anyway? Assuming that all is well with the ACQ, this means that we can accept the code you have put in the WIKI into SVN for people to start playing with. You will have to add the code to a JIRA entry for the project, so you can definitively offer it under the Apache license. Note that we are going to be testing the contribution process that we have thought out, so please be patient :) Sure, no problem. I just thought we should start talking about code rather than abstract ideas. Regards, David. geir On Sep 16, 2005, at 3:47 PM, David Tanzer wrote: [Snip]
Re: [arch] VMCore / Component Model
Peter Edworthy wrote: [Snip] First of all thanks to David Tanzer, having something solid to start from makes a tremendous difference. The code captures a basic functional spec for a component loader very well. I'm not very familiar with UNIX dynamic libs so if this is way off please say; It seems dlfcn is quite platform specific; would ltdl make more sense? Maybe. I just saw that the APR also provides methods for doing this, so that would be a good solution too. As i said, my code should only be a basis for discussion and a proof-of-concept. It seems as though only one 'native method' is provided per file this way, is that just for the demo code or is it a limitation of this method? No, it's not a limitation of the method, the struct TestComponent* could store an arbitrary number of functions. Am I right in thinking that to use the table of 'native method' pointers we will have to place the operands on the stack and then jump to the method (just checking as the code to do that would also be a component and so how would we bootstrap it, jikes had a clever method involving writing from a JVM a startup JVM image with the native code in it)? I'm not sure if we are talking about the same thing here, maybe I just fail to see some important part of the bigger picture. My intention was to provide a mechanism with which we could handle components like the ones for which Weldon Washburn wrote the interfaces for. For example, it could be used to load implementations of http://wiki.apache.org/harmony-data/attachments/HarmonyArchitecture/attachments/gc_interface.txt and http://wiki.apache.org/harmony-data/attachments/HarmonyArchitecture/attachments/vm_gc_interface.txt and interconnect them. It focuses on C (or C++) implementations so far, I'm not sure if we can easily extend it to support other programming languages. I think what you are talking about here is more like the light-weight native calls which where proposed by Mladen Turk (correct me if I'm wrong): http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200509.mbox/[EMAIL PROTECTED] Could this be implemented in Java so long as a native call mechanism existed to 'register' components with each other, there is probably no compelling reason to do this but it might improve cross platform support. That should be no big problem. I mentioned earlier that it would be cool if we had several different prototypes we can play with, compare to each other and discuss about, so maybe someone volunteers for writing one ;-) [Code-In lining] To have a JIT we must have a method of storing 'compiled code' and calling it we could create the basic components as native code stored in the JVM using same system as the JIT. The class loader could then mark inside the byte stream a call to this native code in place of the original byte code. Or the interpreter could act as though the byte code should be interpreted as a call to that method. If this is too inefficient then the JIT will compile the method that the call is within and at this point may well decide to in line the code from the method call. I don't see why we would want to or need to create a different in lining method for these aspects of the interpretor. If we are using the boot strapping method like jikes then maybe some methods should be JIT'ed before the image is written. [native code storage for the JIT] I've never tried to create a JIT, but I assume we need to consider some way of describing the side-effects of a section of code; i.e. what registers are changed/used as input and output. Or do JITs not normally need this as they compile whole methods and so use the stack for data in and out and assume all registers are dirty? Thanks in advance, Peter
Re: [arch] VMCore / Component Model
Geir Magnusson Jr. wrote: Have you tried to communicate between two components, one in C(++) and one in Java? No, I didn't try that yet. For native compiled java code (gjc) I guess it should be straight forward to extend my proof-of-concept to support it. For java code which runs in the harmony vm the interface will have to be different, but we need this interface too. geir On Sep 19, 2005, at 1:46 PM, David Tanzer wrote: Today I have added some additional Information to the Wiki page. We should also consider using C++ and abstract classes to maintain our component model. While this would make inter-component communication slightly slower it would be easier to maintain. We should also think about using an existing component model like OSGi. The model I posted provides pretty fast communication between components without sacrificing too much flexibility, but it is maybe not as easy to maintain as a clean, object-oriented implementation (i.e. C++). We could discuss how important these aspects are to us, i.e. how much runtime efficiency we are willing to sacrifice for maintainability and flexibility and vice-versa. Regards, David. On Fri, 2005-09-16 at 21:47 +0200, David Tanzer wrote: Ok, it took a little bit longer than I first expected, but now my proof-of-concept implementation of the component model I described is available in the wiki: http://wiki.apache.org/harmony/ComponentModelFunctionPointers I have also linked it from the harmony architecture page. It contains a mechanism for loading components and a basic versioning and dependency management mechanism. The test case loads two components, where one depends on the other. I'll add some more explanations to the wiki page when I have more time, hopefully at the weekend. I have made several assumptions about the directory structure, the coding conventions and the documentation conventions, we should maybe discuss this in a different thread. Regards, David. On Tue, 2005-09-13 at 17:27 +0100, Tim Ellison wrote: David Tanzer wrote: Since we already started to define some component interfaces I think we also should start thinking about a component model which loads / connects such components. Maybe there are also some existing solutions we might want to look at (I must confess I didn't really search yet). Agreed, plus managing the API itself to ensure forwards/backwards version compatibility. I guess a requirement for such a component manager would be that it can load and connect components at runtime and that the specific implementations which are loaded can be configured. It might also be good if the same component implementations can be linked at compile time (i.e. statically) which could have benefits on embedded platforms, but I'm not sure if we really need this. I'm assuming that you are speculating on component management beyond the platform support (i.e. DLL-hell). The java world is already on this path with the OSGi framework (e.g. Felix). It will require a non-trivial solution to ensure that the runtime flexibility does not incur an unacceptable runtime cost. Another requirement would be that the components can be written in different programming languages (i.e. C, C++, Java, ...). It isn't really a problem to solve this for C and C++, but can we also easily support other programming languages? A simple way to implement such a component model in C would be an approach similar to the one Tim Ellison described in [1] where he explains the structure of the J9 VM's portability library. I started writing a proof of concept implementation for this, and I'll add it to the wiki as soon as it's finished. I look forward to seeing the proof of concept. Were you thinking of introducing versioning and dependency management style functions? It would be interesting to have several such proof-of-concept implementations of component models which we can study and the decide which to use. We could even write import mechanisms for the different component models so they can import and use components from another model too (of course this would normally imply reduced performance). Regards, David. [1] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/ 200509.mbox/[EMAIL PROTECTED] -- David Tanzer, Haghofstr. 29, A-3352 St. Peter/Au, Austria/Europe http://deltalabs.at -- http://dev.guglhupf.net -- http://guglhupf.net My PGP Public Key: http://guglhupf.net/david/david.asc -- AUFGABEN DER PHYSIK -- QUANTENMECHANIK Gegebene Konstante: m(Kuh)=400 kg Die Kuh befinde sich auf einer Weide, die ringsum durch einen Zaun abgegrenzt ist. Der Weidezaun sie ideal gebaut, sodass die Kuh ihn (klassich gesehen) nicht passieren kann. Begrnden Sie, dass man die Kuh trotzdem mit gewisser Wahrscheinlichkeit ausserhalb der Weide antrifft.
This week on harmony-dev (Sept. 11 - Sept. 17 2005)
Tim Ellison and I were discussing about the component model to use in harmony in the thread [arch] VMCore / Component Model. The component model should be some mechanism to load components, resolve dependencies between the components and provide some versioning mechanisms for the components and their interfaces to ensure forward/backward compatibility. I have posted a proof-of-concept implementation to the wiki which uses shared libraries and tables of function pointers to provide this functionality. [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200509.mbox/[EMAIL PROTECTED] Rana Dasgupta clarified some points about VM accessors in [arch] VM/Classlibrary Interface ( VM Accessors ). He defines them as a VM access toolkit which could be used by the class library or JVMTI agents. He started to define an initial set of candidates for standardization. He also mentioned that restricting access to these classes might result in better performance of these accessors. [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200509.mbox/[EMAIL PROTECTED] In the thread [Arch] Class unloading and VM objects reclaim, Robin Garner explained how this is done in JikesRVM with MMTk: where the classloader allocates its objects is essentially configurable. He then explains more details about how this is done. Peter Edworthy replied to this explaining where he thought OS could be used to assign seperate memory areas to the parts of the VM and then do acces checks at the OS level. In the same thread, Tim Ellison replied to Archie Cobbs that he agrees that All identical string literals must refer to the same instance and that a pure Java implementation of String.intern() would be acceptable. [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200509.mbox/[EMAIL PROTECTED] [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200509.mbox/[EMAIL PROTECTED] Chris Elford started the thread [Arch] Designing in support for JVMTI in Harmony where he explains what he expects from harmony's implementation of the JVMTI specification. Weldon Washburn has posted two interfaces between the VM and the GC in the thread [arch] Modular JVM component diagram and the wiki. [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200509.mbox/[EMAIL PROTECTED] [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200509.mbox/[EMAIL PROTECTED] Last week Mark Wielaard suggested to exdend This week an harmony-dev to also cover some of the other mailinglists of the sister projects, so I started reading some other mailing lists. It's really interesting what goes on in these projects, but it is quite a lot of traffic and I don't think I can give a valualbe summary in this series. These discussions can't be summarized in a single paragraph per sister project, and everything more would be too much for this series. Maybe a solution would be that these projects try to find somebody who summarizes their discussions (if they want it), and all these summaries are then aggregated at http://planet.classpath.org so we have a single point where we can find them. I hope you understand that I don't do this, I really enjoy writing these summaries for Harmony but it would be too much work for me to write about several other projects too. Regards, David. -- Read the archive of this series at http://deltalabs.at/ -- RSS feed: http://deltalabs.at/?q=taxonomy/term/8/0/feed -- Also aggregated at: http://planet.classpath.org/ -- David Tanzer, Haghofstr. 29, A-3352 St. Peter/Au, Austria/Europe http://deltalabs.at -- http://dev.guglhupf.net -- http://guglhupf.net My PGP Public Key: http://guglhupf.net/david/david.asc -- Pinky, Are You Pondering What I'm Pondering? I think so Brain, but how do we get a pair of Abe Vegoda's pants?
Re: [arch] VMCore / Component Model
Ok, it took a little bit longer than I first expected, but now my proof-of-concept implementation of the component model I described is available in the wiki: http://wiki.apache.org/harmony/ComponentModelFunctionPointers I have also linked it from the harmony architecture page. It contains a mechanism for loading components and a basic versioning and dependency management mechanism. The test case loads two components, where one depends on the other. I'll add some more explanations to the wiki page when I have more time, hopefully at the weekend. I have made several assumptions about the directory structure, the coding conventions and the documentation conventions, we should maybe discuss this in a different thread. Regards, David. On Tue, 2005-09-13 at 17:27 +0100, Tim Ellison wrote: David Tanzer wrote: Since we already started to define some component interfaces I think we also should start thinking about a component model which loads / connects such components. Maybe there are also some existing solutions we might want to look at (I must confess I didn't really search yet). Agreed, plus managing the API itself to ensure forwards/backwards version compatibility. I guess a requirement for such a component manager would be that it can load and connect components at runtime and that the specific implementations which are loaded can be configured. It might also be good if the same component implementations can be linked at compile time (i.e. statically) which could have benefits on embedded platforms, but I'm not sure if we really need this. I'm assuming that you are speculating on component management beyond the platform support (i.e. DLL-hell). The java world is already on this path with the OSGi framework (e.g. Felix). It will require a non-trivial solution to ensure that the runtime flexibility does not incur an unacceptable runtime cost. Another requirement would be that the components can be written in different programming languages (i.e. C, C++, Java, ...). It isn't really a problem to solve this for C and C++, but can we also easily support other programming languages? A simple way to implement such a component model in C would be an approach similar to the one Tim Ellison described in [1] where he explains the structure of the J9 VM's portability library. I started writing a proof of concept implementation for this, and I'll add it to the wiki as soon as it's finished. I look forward to seeing the proof of concept. Were you thinking of introducing versioning and dependency management style functions? It would be interesting to have several such proof-of-concept implementations of component models which we can study and the decide which to use. We could even write import mechanisms for the different component models so they can import and use components from another model too (of course this would normally imply reduced performance). Regards, David. [1] http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200509.mbox/[EMAIL PROTECTED] -- David Tanzer, Haghofstr. 29, A-3352 St. Peter/Au, Austria/Europe http://deltalabs.at -- http://dev.guglhupf.net -- http://guglhupf.net My PGP Public Key: http://guglhupf.net/david/david.asc -- METHODEN DER BEWEISFHRUNG -- WISCHWEG - METHODE Man wischt die entscheidenden Stellen des Beweises sofort nach dem Anschreiben wieder weg (rechts schreiben, links wischen). signature.asc Description: This is a digitally signed message part
This week on harmony-dev (Sept. 04 - Sept. 10 2005)
Mladen Turk responded to the concerns by Weldon Washburn about the light-weight native calls in the thread VM/Classlibrary Interface (take 2). He explained in more detail how he thinks those light-weight calls could work, they should avoid the overhead for native calls. Mladen and Tim Ellison then discussed what this means for the native methods which are called (for example, they would not be allowed to allocate objects on the heap). Such light-weight native calls could pontentially speed up the class library since often native calls don't need to create any objects (or use other operations which would be disallowd by the light-weight model). [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200509.mbox/[EMAIL PROTECTED] Also in the [arch] VM/Classlibrary Interface (take 2) - thread, Tim Ellison explained how the interface between their class libraries and a JVM works. These class libraries are a subset of SE and have been independently developed. They are designed to be portable across VM implementations but have been principally written against the J9 VM. [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200509.mbox/[EMAIL PROTECTED] Tim Ellison posted in the thread [arch] VM/Classlibrary Interface ( VM Accessors ) that VM Accessors would be some kind of classlibrary developer's toolkit and could allow implementation of functionality in pure Java which would otherwise require a native implementation. He also mentions that the list of accessors Rana Dasgupta wrote is a blend of functional enhancements and optimization enhancements. The security concerns for these accessors could be solved by the componentization of the class library. [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200509.mbox/[EMAIL PROTECTED] Sombody at roomity.com announced that GNU Classpath 0.18 has been released. In the discussion in this thread, Mark Wielaard told us that since the start of harmony the number of contributions a day to GNU Classpath have tripled and and a little bit more about the release. He also mentioned that the classpath/harmony sister projects will release an updated version soon. Robert Lougher posted that JamVM from CVS works with classpath 0.18 'out of the box' on Linux now. There was also some discussion about porting Kaffe to PSP and XBox 360, but I guess this will be continued in the Kaffe project. Dalibor Topic, Tom Tromey and I where involved in this discussion too. [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200509.mbox/[EMAIL PROTECTED] Xiao-Feng Li started a thread called [Arch] Class unloading and VM objects reclaim, where he discribes 2 approaches how to unload a class. One approach would encode VM objects similar to app objects, so they can be reclaimed by the GC, the other treats class unloading specially and reclaims the memory with the class loader. Archie Cobbs said that you can have the benefits of both approaches by having a per-class loader memory area, but Xiao-Feng wrote that this looks like the second one he suggested. There was also some discussion about situations where objects (especially strings) could not be relclaimed with these approaches and how to solve this, Peter Edworthy and Santiago Gala posted some interesting facts on this topic too. [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200509.mbox/[EMAIL PROTECTED] In the thread [arch] voluntary vs. preemptive suspension of Java threads Xiao-Feng Li posted that they had some difficulties in maintenance and portability with code patching (i.e. the VM patching compiled code at save points to stop a thread). He suggests we implement both approaches (preemtive and voluntary, voluntary first) for further study since the two approaches are not much conflicting. [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200509.mbox/[EMAIL PROTECTED] Regards, David. -- Read the archive of this series at http://deltalabs.at/ -- RSS feed: http://deltalabs.at/?q=taxonomy/term/8/0/feed -- Also aggregated at: http://planet.classpath.org/ -- David Tanzer, Haghofstr. 29, A-3352 St. Peter/Au, Austria/Europe http://deltalabs.at -- http://dev.guglhupf.net -- http://guglhupf.net My PGP Public Key: http://guglhupf.net/david/david.asc -- AUFGABEN DER PHYSIK -- QUANTENMECHANIK Gegebene Konstante: m(Kuh)=400 kg Die Kuh befinde sich auf einer Weide, die ringsum durch einen Zaun abgegrenzt ist. Der Weidezaun sie ideal gebaut, sodass die Kuh ihn (klassich gesehen) nicht passieren kann. Begrnden Sie, dass man die Kuh trotzdem mit gewisser Wahrscheinlichkeit ausserhalb der Weide antrifft.
Re: Classpath .18 release
Mark Wielaard wrote: [Snip] Maybe This week on harmony-dev can be extended to also cover some of the other mailinglists of the sister projects. Of course I could, the question is how to do this. First of all, we should compile a list of mailing lists we consider to add to these weekly reviews. I just found the following, please post additional suggestions: * GNU Classpath: - classpath@gnu.org - classpath-patches@gnu.org (maybe) * Jikes RVM: - [EMAIL PROTECTED] - [EMAIL PROTECTED] * Kaffee: - [EMAIL PROTECTED] I'll then subscribe to the suggested lists and maybe just read them for a week or two before I decide what I'll do (i.e. for which lists I want to write summaries). I'm not sure if I really want to summarize all the mailing lists which would be interesting for harmony, since this could be *really much* work, so if someone wants to volunteer for helping me with that we'll surely find a way to contribute ;-) I think it would be good to make two different series -- This week on harmony-dev as it is and something like This week in related projects with summaries of the development in the sister projects. We could post both article series here and at my homepage (and of course on other mailing lists who are interested too). Regards, David.
Re: This week on harmony-dev (Aug. 28 - Sept. 03 2005)
On Mon, 2005-09-05 at 16:54 +0100, Tim Ellison wrote: I think these summaries are great David, keep it up! Thank you, it's good to hear that. I really appreciate any feedback, so if some of you might have any suggestions what I could change (go more/less into detail, or whatever) please tell me. [ ...though it does make the little devil inside me want to start messing with your brain, to see if you can summarize wads of code, deliberately contradictory statements, etc. :-) ] Well, do so, let's see what I can take ;-) Regards, David. Regards, Tim David Tanzer wrote: Weldon Washburn, Geir Magnusson Jr. and I where discussing about the programming language in which to implement harmony and the coding conventions to use in the thread [arch] Modular JVM component diagram. I rewrote one of the interfaces Weldon wrote so it conforms to the Java Coding Conventions (where possible - it is C code), which where only cosmetic changes. Geir said his biggest concerns about coding conventions is safety and clarity (and he gave some examples). There was no decision yet. [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200508.mbox/[EMAIL PROTECTED] Alos in the thread [arch] Modular JVM component diagram, Xiao-Feng Li, Ron Braithwaite, Rodrigo Kumpera and Tom Tromey where discussing about APR and POSIX as OS abstraction libraries. There is a wide agreement that this makes sense. Tim Ellison then explained how the portability library of the J9 VM (portlib) works and that it has some features which APR doesn't have. [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200508.mbox/[EMAIL PROTECTED] Xiao-Feng Li started the thread [arch] voluntary vs. preemptive suspension of Java threads where he explains both models and gives a brief overview on the advantages and disadvantages of these approaches. Kazuyuki Shudo and Rodrigo Kumpera posted some more information about this topic. [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200509.mbox/[EMAIL PROTECTED] Rana Dasgupta started a discussion about [arch] VM/Classlibrary Interface ( VM Accessors ). He posted some initial thoughts about what these accessors are (They will provide access to VM functionality not exposed through the public Java api), how they could be implemented (i.e. JNI) and which problems might occur (security, ...). [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200509.mbox/[EMAIL PROTECTED] Weldon Washburn was responding to a posting by Mladen Turk about light-weight native calls where he lists some problems this approach migth have and asks how Mladen wants to solve them. Steven Gong asked how the VM/Classlibrary interface and VMAccessors are related, but he has not received an answer yet. [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200509.mbox/[EMAIL PROTECTED] [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200509.mbox/[EMAIL PROTECTED] Regards, David. -- Read the archive of this series at http://deltalabs.at/ -- RSS feed: http://deltalabs.at/?q=taxonomy/term/8/0/feed -- David Tanzer, Haghofstr. 29, A-3352 St. Peter/Au, Austria/Europe http://deltalabs.at -- http://dev.guglhupf.net -- http://guglhupf.net My PGP Public Key: http://guglhupf.net/david/david.asc -- Pinky, Are You Pondering What I'm Pondering? I think so Brain, but if we have nothing to fear but fear itself, then why does Elenor Roosevelt wear that spooky mask?
Re: [arch] Modular JVM component diagram
Some questions: Are these the actual headers we program against? If
yes, this would assume we use C or C++ to implement the VM, or at least
these components, right?
Sorry if I'm asking something which has already been resolved, but I
was just searching the mailing list archives and I found much
controversy about which language to use, but I didn't find a resolution.
Anyway, I thing C/C++ would be a good choice to implement performance
critical parts of the VM.
Another suggestion: IMHO it would be good to use the Java Coding
Conventions in C/C++ code too. While this has the disadvantage that
the coding style in the C/C++ code might be inconsistent in some places
it would have the great advantage that all code (and all interfaces)
we write use the same coding style.
Regards, David.
On Fri, 2005-08-26 at 09:24 -0700, Weldon Washburn wrote:
method_access.txt has been added.
On 8/25/05, Weldon Washburn [EMAIL PROTECTED] wrote:
On 8/25/05, Davanum Srinivas [EMAIL PROTECTED] wrote:
Weldon,
from which wiki page is this field_access.txt url linked from? could
we not add the code that wiki page itself? (if you enclose with {{{
and }}} with the code in between it looks nice)
Oops. Sorry. I put an http link to field_access.txt in
http://wiki.apache.org/harmony/HarmonyArchitecture. Its under the VM
Core paragraph that Ricardo added last week. Its about 3/4 of the
way down the page.
thanks,
dims
--
David Tanzer, Guglhupf Studios, http://guglhupf.net
My PGP Public Key: http://guglhupf.net/david/david.asc
--
Brain: Here we are, Pinky--at the dawn of time!
Pinky: Narf, Brain. Wake me at the noon of time.
-- When Mice Ruled the Earth
signature.asc
Description: This is a digitally signed message part
This week on harmony-dev (Aug. 21 - Aug. 27 2005)
Steve Liao started the thread [arch] JIT interfaces where he asks how Harmony wants to solve some basic JIT/VM interfacing. As an example he mentions stack maps - at Intel they cache these stack maps in the VM, but the JIT controls their interpretation. The other option would be that the JIT stores the stack maps internally, which is used in the Jikes RVM (Michael Hind explained this in detail in a reply to this email). Archie Cobbs posted how JCVM handles this. Rana Dasgupta mentioned that this data doesn't have to be unified since only the associated JIT interprets it, but that a common format could have benefits. In a reply, Steve Liao explained a little more details about the Intel approach and explained a scheme he calls lazy generation of stack maps which would have advantages on architectures where the memory footprint is an issue (but it would slow down execution). [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200508.mbox/[EMAIL PROTECTED] It's Steve Liao again, he explained a concept which can reduce the execution time for exceptions in [arch] throwing lazy exceptions. It is basically about finding out which parts of the exception handling mechanism are needed in every case, and then only execute this part. [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200508.mbox/[EMAIL PROTECTED] Weldon Washburn has started to fill in the interfaces in the component diagram Ricardo Morin made. He has put some classloader interfaces into the Harmony wiki, they are linked from the architecture page (http://wiki.apache.org/harmony/HarmonyArchitecture). [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200508.mbox/[EMAIL PROTECTED] Finally, Usman Bashir had a good time at the conference he was at (congrats) and also posted some links. Geir Magnusson Jr. answered a legal question regarding CCLA and CLA (saying the CCLA isn't a need, but it's good). [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200508.mbox/[EMAIL PROTECTED] [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200508.mbox/[EMAIL PROTECTED] Regards, David. -- Read the archive of this series at http://deltalabs.at/ -- RSS feed: http://deltalabs.at/?q=taxonomy/term/8/0/feed -- David Tanzer, Guglhupf Studios, http://guglhupf.net My PGP Public Key: http://guglhupf.net/david/david.asc -- Pinky, Are You Pondering What I'm Pondering? I think so Brain, but how do we get the Spice Girls into the paella.
This week on harmony-dev (Aug. 14 - Aug. 20 2005)
Here's a copy of the http://deltalabs.at article about this week's discussion on harmony-dev. There is a RSS feed about harmony-related articles at deltalabs: http://deltalabs.at/?q=taxonomy/term/8/0/feed This week was very much discussion about the architecture of the virtual machine, but there was some other things too. In the call for contributions - Thread, Thorbjørn Ravn Andersen volunteered for writing a native2ascii - replacement. Geir Magnusson Jr. updated the authorized contributor questionnaire, it can be found here: http://incubator.apache.org/harmony/auth_cont_quest.html . [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200508.mbox/[EMAIL PROTECTED]] [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200508.mbox/[EMAIL PROTECTED] Weldon Washburn wants to more discussion about VM modularization on harmony-dev. He wants to concentrate on simple and stable interfaces first, and leave the more complicated ones for later discussions. He also suggested some interfaces and sub-categories for what he calls Class Support. [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200508.mbox/[EMAIL PROTECTED] In the thread [arch] VM/Classlibrary Interface (take 2) there has been some discussion on how different development groups have solved this problem. At the beginning of the week there where still licensing issues to be resolved which prevented them from donating their interfaces, but yesterday Weldon Washburn has asked Graeme Johnson and Tim Ellison to post their interfaces to the wiki for further discussion. Tim will be on vacation next week, so he will join the discussion when he's back. [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200508.mbox/[EMAIL PROTECTED] [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200508.mbox/[EMAIL PROTECTED] [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200508.mbox/[EMAIL PROTECTED] Ricardo Morin has added a component diagram to the Harmony Architecture wiki page (http://wiki.apache.org/harmony/HarmonyArchitecture): http://wiki.apache.org/harmony-data/attachments/HarmonyArchitecture/attachments/ModularJVM.jpg and this started the thread [arch] Modular JVM component diagram. He later added some more explanations about the diagram and the modules to the wiki page. [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200508.mbox/[EMAIL PROTECTED] Also in the [arch] Modular JVM component diagram thread, Torsten Curdt asked for some mechanism in the VM to support native continuation in java. Werner Schuster posted two links about continuation: http://en.wikipedia.org/wiki/Continuation and http://www.intertwingly.net/blog/2005/04/13/Continuations-for-Curmudgeons . There was some more interesting suggestions on this topic by the two authors mentioned above and some others, you can read the details in the follow-ups to the original posting: [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200508.mbox/[EMAIL PROTECTED] And again in the [arch] Modular JVM component diagram thread, Tom started a discussion about using the Apache Portable Runtime (APR) as our OS abstraction layer (OAL). After some discussion this seems to be a good idea. Tom then suggested to give our solution a little finer granularity, i.e. to define the subset of the APR which is required to get the VM to run. [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200508.mbox/[EMAIL PROTECTED] Regards, David. -- David Tanzer, Guglhupf Studios, http://guglhupf.net My PGP Public Key: http://guglhupf.net/david/david.asc -- Jeden Tag vorm Einschlafen des Biosavard-Gesetz. Eh klar, do seid ihr high und happy. -- F. Hoislbauer
Re: This week on harmony-dev (Aug. 7 - Aug. 13 2005)
On Sat, 2005-08-13 at 12:29 +0200, David Tanzer wrote: I've been asked to post my weekly summary of the postings in the harmony-dev mailing list at http://deltalabs.at to this list too, so here it is. It is also listed in the Java RSS Feed of deltalabs at http://deltalabs.at/?q=taxonomy/term/3/0/feed Update: we have set up a dedicated RSS feed for harmony news at deltalabs: http://deltalabs.at/?q=taxonomy/term/8/0/feed so the This week on harmony-dev articles are now listed in this feed, and not in the Java feed. Regards, David. -- David Tanzer, Guglhupf Studios, http://guglhupf.net My PGP Public Key: http://guglhupf.net/david/david.asc -- Pinky, Are You Pondering What I'm Pondering? I think so Brain, but Zero Mostel times anything is still Zero Mostel. signature.asc Description: This is a digitally signed message part
This week on harmony-dev (Aug. 7 - Aug. 13 2005)
I've been asked to post my weekly summary of the postings in the harmony-dev mailing list at http://deltalabs.at to this list too, so here it is. It is also listed in the Java RSS Feed of deltalabs at http://deltalabs.at/?q=taxonomy/term/3/0/feed Another week is over and it's again time for this weeks summary of the postings at the harmony-dev mailing list. I added links to the emails in the archive of this list to each paragraph to give you a starting point for detail recherche if you are interested in this topic. First important thing: we have contributions! Ian Darwin sent in his partial javap replacement, and Mladen Turk volunteered vor working on a jar replacement. He also contributed a native-only implementation: http://apvfs.sourceforge.net/. [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200508.mbox/[EMAIL PROTECTED] [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200508.mbox/[EMAIL PROTECTED] Some people have asked how to contribute and what's the most important steps for someone who is new to the project (i.e. where to find important information and what's to be done). This is basically explained here: http://incubator.apache.org/harmony/get-involved.html, and following the mailing list for some time is surely helpful too. Hopefully some time in the future this article series will be a good starting point too ;-) Usman Bashir has finished a paper about the harmony project he wants to present at the open source conference in Lahore Pakistan. He posted it for public review in his blogs http://spaces.msn.com/members/gripusa and http://usmanbashir.blogspot.com/, and Jeffrey McManigal emailed him some suggestions (not posted to the list). So, Usman, I hope you got the help you wanted and good luck for your presentation. [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200508.mbox/[EMAIL PROTECTED] Finally, Geir has posted a legal update, he changed the Authorized Contributor Agreement and took the part about bulk contributions to a separate document. [http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200508.mbox/[EMAIL PROTECTED] Regards, David. -- David Tanzer, Guglhupf Studios, http://guglhupf.net My PGP Public Key: http://guglhupf.net/david/david.asc -- Wia da Franklin in Blitzableiter erfunden hat, da warn's alle so begeistert, dass sogar in Regnschirm an einbaut ham... Damit der Blitz extraguat einschlagt! -- F. Hoislbauer
