Re: Bypassing security manager checks (was: Re: Infinite loop)
On Thu, 2005-11-17 at 13:42 +, Gary Benson wrote: You make it sound like an easy fix: is it? What needs to be done, and where? Besides what Jeroen already said you also have to merge ClassLoader. libgcj has a different version at the moment. In particular you want the logic that createSystemClassLoader() has. Cheers, Mark -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/ signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
New GNU Classpath developer Gary Benson
Hi all, As you probably already noticed by reading classpath-patches Gary has been working on the security framework. And has written several mauve tests to back up his patches. He now has direct developer access to speed up his work. Gary, here are the rules: The first rule of GNU Classpath is - you do not talk about GNU Classpath, you write code. The second rule of Fight Club is - you DO NOT talk about GNU Classpath, you write code. Third rule of GNU Classpath, someone yells stop!, goes limp, taps out, your patch is NOT approved. Fourth rule, a bug report is between just two people, the reporter and the fixer. Fifth rule, one commit at a time, or get CVS merge conflicts. Sixth rule, no shirt, no shoes, just bare ASCII source. Seventh rule, fixes will go in as long as they have to. And the eighth and final rule, if this is your first night at GNU Classpath, you have to patch the AUTHORS file. (*) Please post a patch and ChangeLog entry to classpath-patches to add yourself to the AUTHORS file. You can consider that patch pre-approved of course. Thanks, Mark (*) More formal rules are of course in the GNU Classpath Hackers guide: http://www.gnu.org/software/classpath/docs/hacking.html -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/ signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: JamVM does not startup
Hi Isabella, On Fri, 2005-11-18 at 15:32 -0800, Isabella Thomm wrote: I am new to this, so sorry about this simple question and it probably does not fit in here, but I'd be glad to solve this problem: I have installed classpath 0.19, as described, (configure, make, make install...), and then jamVM 1.3.3 (configure with the --with-classpath-install-dir option, make etc.) and I get the following error, while trying to execute a simple with java compiled program: Error initialising VM (initialiseMainThread). I think this is your --prefix option to classpath configure not matching the --with-classpath-install-dir configure option for jamvm. I saw that Robert wanted to to help offline. But please do post the solution to the list so others having the same problem might find the solution on the list later. I am using Debian unstable. Note that Debian unstable should come with the latest classpath and jamvm releases prepackaged. Cheers, Mark -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/ signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: New GNU Classpath developer Gary Benson
Hi Ito, On Fri, 2005-11-18 at 14:59 -0800, David Daney wrote: Ito Kazumitsu wrote: From: Mark Wielaard [EMAIL PROTECTED] long as they have to. And the eighth and final rule, if this is your first night at GNU Classpath, you have to patch the AUTHORS file. (*) I, Ito Kazumitsu, did not obey this rule, but I do not think I have to be listed in AUTHORS because I have fixed and will fix only simple bugs. Should I list myself in THANKYOU? If you have CVS commit privileges, you owe it to your self to do this. It will bring you worldwide renown. David is right. Please add yourself. We didn't have this rule in the past, but from now on we should do this. And your work, testing, reporting, fixing, retesting and discussing solutions for the various issues you found are really appreciated. What seem like simple bugs to you are hairy incomprehensible multi-byte character encoding issues to others. Cheers, Mark -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/ signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Comparable in java.util.Calendar
Hi Kendall, On Mon, 2005-11-21 at 17:15 -0600, Kendall Bell wrote: I would like to implement Comparable in java.util.Calendar. That seems like a nice start for a 1.5 addition. Please follow the Hacking Guide for some general instructions and post a patch to classpath-patches plus ChangeLog entry when you have something for review. http://www.gnu.org/software/classpath/docs/hacking.html I see you already sent the paperwork request forms. Thanks for that. Happy hacking, Mark -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/ signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
mailing list troubles
Hi all,
I tried to warn about a couple of issues with the mailing lists and
savannah. But apparently I am one of the people trapped in some insane
spam fighting scheme. Attached are the messages I sent from my normal
email address. Unfortunately gnu.org currently doesn't accept email from
that address (because it is refusing to handle sender verification
through null reverse paths [mail from: bounces]). I hope that some
people will at least get this message. If you are not receiving email,
or are not able to sent email to the various classpath mailing lists
please check the archives at
http://lists.gnu.org/archive/html/classpath/ or
http://news.gmane.org/gmane.comp.java.classpath.devel
This being a long thanksgiving weekend for some people makes it
impossible to predict how long this will be an issue. I try to keep you
updated.
Yes, I understand the irony of trying to sent email about email not
working... I'll try to post something on planet.classpath.org when I
know more.
Sigh,
Mark
---BeginMessage---
Hi all,
Seems my previous emails (forwarded below) have still not hit the
list :{ But the good news is that savannah is back up again:
http://savannah.gnu.org/forum/forum.php?forum_id=4136
Cheers,
Mark
---BeginMessage---
Hi all,
Seems this is a day that everything breaks down :{
My original email about the spamcop rbl block seems to have never
reached the list, so here it is attached again. And now savannah is
down. Several people have been paged to get the system back up, but
apparently everybody capable of doing that is located in an area
observing thanksgiving. So no ETA about when it will be available again.
Sorry for the bad news.
Cheers,
Mark
---BeginMessage---
Hi,
I am seeing a lot of list traffic bounce and/or people being
unsubscribed because spamcop.net has lists.gnu.org in its RBL. If you
are (indirectly through your ISP) using spamcop you will probably not
receive this email. But I post it anyway for people reading the archives
after they have discovered their mail server has been blocking any
gnu.org emails.
I asked the savannah-hackers and gnu.org sysadmins to investigate but
till it has been resolved it would be good to not use the spamcop RBL.
Cheers,
Mark
--
Escape the Java Trap with GNU Classpath!
http://www.gnu.org/philosophy/java-trap.html
Join the community at http://planet.classpath.org/
signature.asc
Description: This is a digitally signed message part
---End Message---
signature.asc
Description: This is a digitally signed message part
---End Message---
signature.asc
Description: This is a digitally signed message part
---End Message---
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath
Re: mauve comparison with tgolem
Hi Cacao Team, On Tue, 2005-11-22 at 12:33 +0100, Christian Thalinger wrote: http://www.cacaojvm.org/tgolem The mauve report is the comparison table. The common column shows all PASSes and FAILs which are identical on all JVMs/architectures. Each machine is listed with PASS, FAIL and MISS. MISSed mostly can have two reasons: the testlet crashed and the remaining test were not run or the testlet has been removed from mauve cvs. Maybe this helps someone. This is definitely very useful! The common failures would be good to investigate more closely by all GNU Classpath hackers. And possibly write bug reports (or better patches for fixes) for. In principle the mauve framework can support xfail files, although I don't believe anybody used that for a long time. When all common failures are inspected/identified correctly we could make a good xfails file so it is more clear what issues are regressions and what issues are runtime specific. Would it be possible to split out the mauve results pages? Or at least have a page with just a list of all common FAILS? Any idea about the GUI (Free Swing/AWT) tests? Is there a specific reason they are not enabled at the moment? Thanks, Mark ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: mauve comparison with tgolem
Hi Edwin, On Fri, 2005-11-25 at 23:42 +0100, Edwin Steiner wrote: Would it be possible to split out the mauve results pages? Or at least have a page with just a list of all common FAILS? Absolutely possible. Are there any specific details I should include in such a page? If it is in addition to what there is now already just the plain FAIL lines would be ideal to have. No extras, just the facts! :) Thanks, Mark ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: FreeSWTTestApps page added to wiki
On Tue, 2005-11-22 at 16:29 +0100, Roman Kennke wrote: Am Dienstag, den 22.11.2005, 13:23 +0100 schrieb Egon Willighagen: Anyway, I added a FreeSWTTestApps to the Classpath wiki using the same setup as the FreeSwingTestApps page. Very nice indeed! To complete the Free GUI Toolkits set I also added a FreeAWTTestApps page. Also linked from the frontpage now. http://developer.classpath.org/mediation/FreeAWTTestApps Currently it only lists MegaMek which is a bit big for a simple test application. So additional simpler Free AWT Test Applications wanted! It might be interesting if we also had pages for test applications that use Generics or Graphics2D explicitly so people can concentrate on those if they want. BTW. If you add new applications please do add a little more info then just a reference to some homepage. We want these pages to be good starting points for developers wanting a little hacking challenge. So please include specific download, build and run instructions whenever possible. The FreeSwingTestApps page has a lot of references without any indication what precisely should be tested or how at the moment. Cheers, Mark ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: CACAO 0.93 released
Hi Christian, On Thu, 2005-11-24 at 01:38 +0100, Christian Thalinger wrote: CACAO 0.93 released. This is a major feature enhancement and bugfix release. Wow this is an impressive release. Just tried it out and it seems really nice and fast :) ./configure make make install and off you go! Good work, and thanks for sharing under the GPL. * JIT codegenerators for Arm and MIPS (32-bit, -o32), currently closed-source But this list is not for promoting non-free addons. Please keep the GNU Classpath mailinglists themselves about sharing Free Software. Proprietary software has enough other places to be promoted and discussed. Thanks, Mark ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Build, Test, Deliver
Hi all, For a long time we have needed a clear way to explain what we have been doing, how we do it and what our goals and road map are. When I was in Brazil a few months back David Wheeler discussed our progress, development model and goals with Bruno, Dalibor and me. As an outsider to our development community he was able to give us a clear picture of what we were actually doing. He has a nice writeup of the whole event at http://www.dwheeler.com/essays/fisl2005.html#javaimp We discussed how to put down how we Build, Test and Deliver everything. And I asked several people and groups for input. But it is hard to get consensus on what are the essential things. Especially because we really wanted to put it all down in just 2 pages so it could be used as a quick reference for new people. Or used as a flyer at conferences. Recently I spoke to various people who were happily surprised that various things we helped build just worked in their latest Ubuntu and Fedora Core installation. Their surprise made me realize that we have to do a better job of communicating what we have done and how we are delivering it. So I just updated the document that we started during FISL to our current status and road map. I didn't get it down to 2 pages, but 3 pages isn't bad for a start. I cannot thank David enough for his patience and SouJava for bringing us together. But all mistakes in the final document are mine. This is clearly a first release, so please send corrections, additions, better pictures, translations, etc. A PDF and OpenOffice (sxw) version can be found at http://developer.classpath.org/support/ I tried to export it as XHTML, but the result was not very readable. Help converting the document to other formats is highly appreciated. I hope this document can be a basis for more specialized support and marketing documents for our efforts. So please feel free to adapt it to your own needs and audience. Cheers, Mark ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Performance of java.awt.Graphics's methods
Hi Theo, On Mon, 2005-11-28 at 01:05 +0800, Theodore Thindenberg wrote: every new release I try of course many Swing applications as well as some apps using a custom toolkit which just uses AWT for lightweight drawing. All these applications run at VERY low speed, even the application using only lightweight drawing (and performs quite well on the Netscape-4.7-JVM which is really ugly, slow and buggy) is almost unuseable with the Gtk-based AWT peers. What runtime are you using? Do you have an example program and action/drawing that shows the speed being VERY slow? Is it similarly slow when using a jit like kaffe or cacao, or when aot compiled with gcj? How do these examples compare to the Free Swing Demo in GNU Classpath examples? Is this a common problem, and if yes where is the time spent of e.g. drawLine or fillRect? Is it possible to profile GNU Classpath in any pratical way (like it is with the SUN jvm)? When compiling to native with gcj you can just use something like oprofile. Kaffe comes with some simple jvmpi support that might give you some clues. Cheers, Mark ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: mauve comparison with tgolem
Hi Edwin, On Mon, 2005-11-28 at 14:54 +0100, Edwin Steiner wrote: On Sat, Nov 26, 2005 at 02:01:53AM +0100, Mark Wielaard wrote: If it is in addition to what there is now already just the plain FAIL lines would be ideal to have. No extras, just the facts! :) You can now get a text-only list of common mauve fails at: http://www.complang.tuwien.ac.at/cacaojvm//tgolem/latest/mauve_common_fails.txt Very interesting list. Thanks. Quick analysis for those test that I know why they fail. Maybe others can take a look at the failures and quickly see whether there is a simple explanation or not for these failures. FAIL: gnu.testlet.java.io.File.newFile: getname returns the argument (number 3) Strange... I highly suspect that PlatformHelper is to blame since it tries to bridge any windows vs posix style file path issues. In practice is seems to fail miserably however... FAIL: gnu.testlet.java.lang.Character.classify12 (number 1) FAIL: gnu.testlet.java.lang.Character.getType (number 11) FAIL: gnu.testlet.java.lang.Character.getType (number 20) FAIL: gnu.testlet.java.lang.Character.getType (number 22) These fail because GNU Classpath provides Character based on a newer version of Unicode then what is being tested in Mauve. FAIL: gnu.testlet.java.lang.Package.getPackage: checking package for 'java.lang' (number 1) Needs runtime support. See NEWS file: * Changed implementation of VMClassLoader.getPackage(s) : new method VMClassLoader.getBootPackages should be implemented by the vm, and sould return a string array of boot package names (java.lang, java.net, ...). Feedback from vm implementors for usability and relevance of the getBootPackages method would be greatly appreciated. FAIL: gnu.testlet.java.nio.channels.FileChannel.map (number 1) Seems like a real bug, but fixing it (throwing the right exception) seems to trigger another bug. Needs investigation. FAIL: uncaught exception loading gnu.testlet.java.lang.Class.pkg.test1: java.lang.IllegalAccessException: gnu.testlet.java.lang.Class.pkg.test1 has an inaccessible constructor FAIL: uncaught exception loading gnu.testlet.java.lang.Class.pkg.test3: java.lang.IllegalAccessException: gnu.testlet.java.lang.Class.pkg.test3 has an inaccessible constructor FAIL: uncaught exception loading gnu.testlet.java.lang.Class.pkg.test4: java.lang.IllegalAccessException: gnu.testlet.java.lang.Class.pkg.test4 has an inaccessible constructor These are not tests and should be marked as such. I'll submit a patch. FAIL: uncaught exception loading gnu.testlet.java.lang.Number.NewNumber: java.lang.IllegalAccessException: gnu.testlet.java.lang.Number.NewNumber has an inaccessible constructor FAIL: uncaught exception loading gnu.testlet.java.lang.reflect.Other: java.lang.IllegalAccessException: gnu.testlet.java.lang.reflect.Other has an inaccessible constructor Likewise. Hopefully we can analyze the others also in the near future. Comments and suggestions appreciated. Cheers, Mark ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: mauve comparison with tgolem
Hi Christian, On Tue, 2005-11-29 at 21:20 +0100, Christian Thalinger wrote: On Tue, 2005-11-29 at 15:04 +0100, Mark Wielaard wrote: * Changed implementation of VMClassLoader.getPackage(s) : new method VMClassLoader.getBootPackages should be implemented by the vm, and sould return a string array of boot package names (java.lang, java.net, ...). Feedback from vm implementors for usability and relevance of the getBootPackages method would be greatly appreciated. Why isn't there a default implementation which returns the GNU classpath boot package names? For CACAO, there are not others. Probably because it was thought that it was easier for the runtime to provide this list. Since GNU Classpath doesn't come with a default bootstrap class loader (they are mostly different between runtimes) there is no easy hook to collect them all. We could of course have a little script that collects them all during configure/build time and then makes them available somewhere in some generated source code. Can you write something like that? Cheers, Mark ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Generics Branch Merge Announcement: Classpath 0.19 - 2005/11/27
Hi Andrew, On Sun, 2005-11-27 at 22:12 +, Andrew John Hughes wrote: All patches from Classpath 0.19 through to this afternoon (2005/11/27) to HEAD have been merged to the generics branch. Keep up the good work! :) Same to you! It is always a short announcement, but I know that with the amount of code that people produce these days merging code bases is real work. Thank you! Cheers, Mark -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/ signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Usage of RFC documentation for Javadoc
Hi Wolfgang, On Wed, 2005-11-30 at 20:03 +0100, Wolfgang Baer wrote: So the question comes to my mind if we also can use or maybe quote from the RFC documents in our javadocs. This would make documentation easier and as its the specification also correct in every detail. For your convenience I attached the full copyright statement of the RFC documents. Opinions ? Yes, you can use the text of that RFC for the documentation of the classes. If you look into our LICENSE file you see that the same is already done for org/ietf/jgss using RFC 2853. There are a couple of steps to follow when doing this. - We need to inform FSF legal (licensing@) that we wish to incorporate such text. Can you give me the RFC numbers? Then I inform them and include the text from the RFC. (We need to double check since not all RFCs come with precisely the same permission text.) - We need to add a similar note as already done for org/ietf/jgss to the LICENSE file. That file should list all legal text so the user has one place to review them all. - Each file that includes documentation from the RFC should have the full permission statement as part of the first comment block just after the standard boilerplate. See for an example the file org/ietf/jgss/Oid.java. This makes sure each file as all notices covering the work so people can look it up even in isolation. And that way the text is automatically picked up by gjdoc -licensetext so that the generated documentation includes all notices automatically. Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: [Fwd: [cp-patches] [RFC, Concept proposal]: Easing target dependency]
Hi Guilhem, On Wed, 2005-11-30 at 20:31 +0100, Guilhem Lavaux wrote: So I am proposing to keep the basic skeleton of the target layer but put the real code not in macro but in real C functions. That way we will be able to add autoconf macros without bothering the java interface and if some persons still want to use the TARGET layer it is possible by simply using the macro inside the C functions. Everything that replaces the macros with real functions has my vote. I have had to debug my way through the macros and it was a pain. So here is a patch which shows what I want to do. An idealistic situation would be to put all these functions which are using syscalls into a libjavasyscalls which will be implemented by VM writers (and of course we will propose a default implementation). My preference would be for one cp_io.c, cp_net.c file per core package. This is not the definite patch. So don't complain about missing ChangeLog and so on ... I ask whether people agree on using that concept. This makes the source much more readable for me so I am happy. The only thing I would like to see changed is to explicitly start all functions with cp_ ,to make clear that these symbols are part of the GNU Classpath library (we have the same naming scheme with the gtk+ awt peer native implementation). Thanks, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: gnu_java_awt_peer_gtk_GdkFontPeer.c (initStaticState): missing NewGlobalRef?
Hi Christian, I finally read the paper and took a look at the list. But you already fixed all the obvious things related to class fields. So the remaining things left seem to be jmethodIDs that are cached, but where we don't have a global ref to the class. Like the following: B gnu_java_awt_peer_gtk_GtkWindowPeer.c 272 (jmethodID) B gnu_java_awt_peer_gtk_GtkWindowPeer.c 275 (jmethodID) B gnu_java_awt_peer_gtk_GtkWindowPeer.c 279 (jmethodID) B gnu_java_awt_peer_gtk_GtkWindowPeer.c 282 (jmethodID) B gnu_java_awt_peer_gtk_GtkWindowPeer.c 286 (jmethodID) B gnu_java_awt_peer_gtk_GtkWindowPeer.c 289 (jmethodID) But are these really a problem? For GNU Classpath they are probably not a problem since these classes and naitve libraries are loaded by the bootstrap class loader so will never be unloaded. But is it even a real problem when the class and the native library are loaded by a user defined class loader? It seems that both the class reference can only disappear (and making the mathod id cache invalid) when the class loader is garbage collected. But in that case the native library will also be unloaded. So any method field ID caching will be redone when the class and native library are loaded again. What do you think? Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Duplicate object prevention policy
Hi Jan, On Wed, 2005-11-30 at 02:58 +0100, Jan Röhrich wrote: imagine the following case: A method supports the lookup of objects using a name - object mapping. The objects are stored in a map but can easily be newly created instead of performing a real lookup. Shall we perform this real lookup even if the newly created object is equal to the original object in terms of Object.equals(). That really depends on how much such a method is called, and how many different objects can be returned. If there are not that many object then you should probably store them in a map. If there are not many calls then it probably is not worth it to cache it, especially if recreating an instance is relatively cheap. Concrete?: Have a look at java.awt.datatransfer.SystemFlavorMap#decodeDataFlavor(). This is only one appearance of this problem (out of many many). In this case I would just create the new DataFlavor since it seems this is relative cheap and the method doesn't look like it will be that often called. If later benchmarks on real applications show otherwise we can always think about a caching mechanism. Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Compilation of Classpath with ecj on a 64-bit VM
Hi Andrew, On Sat, 2005-11-26 at 21:04 +, Andrew John Hughes wrote: I recently hit on the same bug again for the second time, and still there seems to be no general solution to it. ecj is a Java-based Java compiler, which means that in compiling Classpath, it can run across problems in the VM or Classpath. On x86_64, this leads to a spurious error with the MIN_DOUBLE value that ends up being misconverted from the literal in the Java source file. back in July, and received no response then. The original message that refers to is even older (January 2004). I believe this is quite a serious issue, as it prevents the generics branch being compiled on x86_64 (as only ecj can currently accomplish this), or ecj being used there at all for that matter. At the moment, I only solve this by using a locally-modified version of kaffe. I can't use a native version of ecj for the same reason. As such, I'm opening this to a wider audience in the hope of getting some response. Was any of the responses you got the solution? What/How exactly did you modify kaffe to get past this? David (CCed) has the same problems with a current kaffe CVS snapshot. Thanks, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: memory behavior to expect with gjdoc-0.7.6
Hi Fred, On Mon, 2005-12-05 at 12:32 -0500, [EMAIL PROTECTED] wrote: Could you also run JamVM with -verbose:gc and send me the output? Attached. Thanks. This seems to point out two things: 1) There is a huge allocation (2MB+): GC: Alloc attempt for 2209016 bytes failed. at this point in the code: // REVIEW: Using max instead of average may allocate a very large // buffer. Maybe we should do something more efficient? int remaining = in.remaining (); int n = (int) (remaining * maxBytesPerChar ()); ByteBuffer out = ByteBuffer.allocate (n); I believe that REVIEW note gives us a hint :) 2) JamVM has fragmented its heap so much that it cannot allocate such a block of data even though there is enough space in total: GC: Largest block is 2087448 total free is 778822576 out of 943718392 (82%) Or am I reading the output incorrectly? Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: memory behavior to expect with gjdoc-0.7.6
Hi Robert, On Mon, 2005-12-05 at 18:10 +, Robert Lougher wrote: On second thoughts, it may have been rejected by gmail if the attachment was too big (how big was it?). Could you try compressing it (if it wasn't)? It is in the gmane archives here: http://article.gmane.org/gmane.comp.java.classpath.devel/6717 Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: memory behavior to expect with gjdoc-0.7.6
[Sorry for the duplicate message, trouble with my primary email account] Hi, On Mon, 2005-12-05 at 18:52 +0100, Mark Wielaard wrote: Thanks. This seems to point out two things: 1) There is a huge allocation (2MB+): GC: Alloc attempt for 2209016 bytes failed. at this point in the code: // REVIEW: Using max instead of average may allocate a very large // buffer. Maybe we should do something more efficient? int remaining = in.remaining (); int n = (int) (remaining * maxBytesPerChar ()); ByteBuffer out = ByteBuffer.allocate (n); I believe that REVIEW note gives us a hint :) It gives us a hint (thanks for review help from Sven on irc) that we are pushing huge Strings through the encoders. In particular gjdoc creates a full String for each XHTMLified/pretty-printed/color-coded/etc source file in HtmlDoclet.java. Although all the rest of the generated pages are streamed to disk the actual source code formating is done in one go: String result = java2xhtml.makeHTML(sourceBuffer.getBuffer(), sourceFile.getName()); Which is then written to disk in one go. For the larger source files this can be pretty big. So a quick workaround for now would be to not include the -linksource flag to gjdoc. If someone wants a nice hacking task then they could look into making java2xhtml take a Reader to read the source from and a HtmlPage to output to instead of creating one huge String. Cheers, Mark ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Introducing builder.classpath.org
Hi all, We now have an official autobuilder and regression tester! The builder.classpath.org Xen infrastructure has been donated by Berkeley Signal Inc through Jim Pick who also helps with setup and maintenance of the system. We are currently using Tom Tromey's build scripts for updating, compiling and running the following things: - gcc-trunk build + libgcj regression test. - gcjx build - classpath CVS build with jikes and gcjx (no gcj since the Makefiles we produce for that use too much memory) (no ecj yet because it is not yet installed/bootstrapped) - jamvm build - mauve batchrun run for jamvm/classpath/gcjx - jacks run for gcjx Regressions are posted to classpath-regressions And on irc.gnu.org in #classpath there is a little cpbot that can give you the current status (just type =help). No fancy webpage results yet. If you want to help with the setup and maintenance of new tests please say so. At the moment the build-masters are Tom, Michael and myself with Jim for backups and any actual access to the hardware. The machine has Debian sarge installed with updated gcc, cairo, etc in /usr/local. Cheers, Mark ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: RFC: merging GNU Crypto and Jessie
Hi Casey, On Mon, 2005-12-05 at 23:42 -0800, Casey Marshall wrote: I propose that we - Rename the root package 'gnu.crypto' to 'gnu.javax.crypto' in GNU Crypto, and merge the current CVS sources into Classpath (not under external/). We then put GNU Crypto into a kind of stasis mode, and continue to develop these sources in Classpath. - Rename the root package 'org.metastatic.jessie' to 'gnu.javax.net.ssl' in Jessie, and merge the current sources. Then, I'll stop developing that branch on its own. We can then also merge other parts of GNU Crypto to projects where they make sense; its testsuite can go into Mauve (it was written to use (a possibly old version of) Mauve's own test harness classes), and the various tools can go into cp-tools. I think most Classpath hackers think this is a good idea Yeah I believe this is a good idea. I know GNU Crypto doesn't have any external dependencies. Jessie has an external dependency on JZlib which is in principle OK, but having multiple zip implementations in the tree is not perfect. Do you have an idea whether it would be possible to hook Jessie to the (internal) util.zip implementation we have? One complication is that a couple of projects based on GNU Classpath have another util.zip implementation based on zlib. Cheers, Mark ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: [Jessie-discuss] Re: RFC: merging GNU Crypto and Jessie
Hi, On Thu, 2005-12-08 at 20:07 -0800, Casey Marshall wrote: On Dec 8, 2005, at 11:25 AM, Anthony Green wrote: My only concern is there be some trivial mechanism to generate a US export-friendly version GNU Classpath, like.. $ configure --disable-munitions Good point. We should have a switch for this in configure. Probably adding the appropriate lines to standard.omit will do it? Also, J2SE has the ExemptionMechanism class, which is currently not much more than a stub in Classpath. I mean, it's trivially easy to get around this restriction with free software -- you just change the source -- but including a real implementation of that class may be enough to satisfy these restrictions. I wouldn't use --disable-munitions, though. The US Government spooks believe crypto is a munition, but I don't. My understanding is that the US government has made it simpler to distribute FOSS crypto code in recent years, but I have a situation where I actually need to strip all export controlled crypto. To be honest, I'm not sure what specific algorithms this means. It's possible that Classpath already contains some. Yes. RSA is export-controlled for key sizes larger than 40 bits, IIRC. In any case, it would be nice if the configury and build process could automatically handle the absence of crypto algorithms. Should this disable compiling the standard crypto library bits, too (javax.crypto and javax.net.ssl), or just the algorithms? As far as I know even the hooks fall under this. Although I am not against having some configure options to put parts of the core library into standards.omit I don't think it is really needed. When the first parts of GNU Crypto was merged into GNU Classpath (and indirectly into GCC and other projects) FSF legal made sure that all FSF distributed GNU software would be able to be distributed (as source) from ftp.gnu.org from mirrors. See the statement on savannah: https://savannah.gnu.org/faq/?admin=group_id=5802question=Savannah_-_Is_there_any_restriction_on_cryptographic_software.txt Similar notices have been placed on ftp.gnu.org and other distribution sites (ftp://ftp.gnu.org/CRYPTO.README). We really don't need more then that as long as we distribute GNU Classpath as Free Software. Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: [Jessie-discuss] Re: RFC: merging GNU Crypto and Jessie
Hi Anthony, On Sun, 2005-12-11 at 03:47 -0800, Anthony Green wrote: You're missing my point, which is that _I_ have a requirement to redistribute GNU Classpath with no export-restricted software. What's good enough for the FSF is not good enough for me. It would nice if there was a convenient way of doing this. Sure, and please do propose a patch to help you if you are willing to maintain that. But beware that you probably need guidance from a legal adviser to make sure you strip out and distribute only those parts not covered by the BXA. All I was saying is that it isn't a necessity for GNU Classpath as a project, or people redistributing GNU Classpath as Free Software. And binary derivatives from distributions and other projects already have to handle this if they have the misfortune to be distributed from inside the USA. See for example the Debian crypto guidelines [1] on how to deal with the the BIS/ENC notification procedures (I assume Fedora has similar guidelines). So, the situation doesn't change from when we first started distributing crypto hooks and algorithms with GNU Classpath [2]. Cheers, Mark [1] http://www.debian.org/legal/cryptoinmain [2] http://lists.gnu.org/archive/html/classpath/2004-08/msg00076.html signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Introducing builder.classpath.org
Hi Leo, On Fri, 2005-12-09 at 22:26 -0800, Leo Simons wrote: On Thu, Dec 08, 2005 at 02:49:18PM +0100, Mark Wielaard wrote: We are currently using Tom Tromey's build scripts Could I get a URL for those? Sounds like a good use case for a certain project I'm working on :-) :-) I was afraid someone would ask for them. Especially someone who actually has a nice, clean, auto-builder setup like gump... :) I would like to also have gump running on builder. But I thought it was good to have at least the bootstrapping environment (runtime, compiler and core libraries plus rudimentary core test suites) available before doing the more higher level setups. You are right, we shouldn't just have them available on builder.classpath.org, but distribute them more widely so others can also easily setup auto-builders/testers. The scripts aren't that complicated though, they are basically helpers for checking out, configuring, building and running some standard targets. Tom, would you be OK with setting up a new classpath CVS module builder and have the scripts available there with a rudimentary README how to bootstrap an auto-tester? Cheers, Mark -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/ signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: [Jessie-discuss] Re: RFC: merging GNU Crypto and Jessie
Hi Anthony, On Sun, 2005-12-11 at 05:38 -0800, Anthony Green wrote: On Sun, 2005-12-11 at 13:50 +0100, Mark Wielaard wrote: All I was saying is that it isn't a necessity for GNU Classpath as a project, or people redistributing GNU Classpath as Free Software. I'm being told that there are situations where this second part is not true, which is why I need to remove the export controlled code. If there are situations where you are not able to (re)distribute the GNU Classpath source code and/or follow the the BIS/ENC notification procedures as done by the various GNU/Linux distros to distribute binary derivatives of GNU Classpath as Free Software works then please let us know. And follow up with some more concrete information about these situations. I am happy to discuss this with FSF legal and see if there are procedures to help in your situation. How are these situations different from distributing GPG, GCC, Mozilla, OpenSSH, etc? Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: StatCVS runs free!
Hi David, On Wed, 2005-12-07 at 16:58 +, David Gilbert wrote: ...I decided it couldn't be too hard to get StatCVS[1] working the same way (StatCVS uses JFreeChart for the charts it generates). Here's the latest run for Mauve CVS generated, for the first time, with JamVM, GNU Classpath and cairo-java: http://www.object-refinery.com/classpath/mauve/statcvs/ So cool! The graphs look fine and smooth. It seems the characters printed vertically (like on the y-axis) seems rotated the wrong way. Alas, the process is too memory hungry to process (on my machine) the 226MB log file generated for Classpath CVS. If you use Kaffe it has some support for tracking memory issues through JVMPI. See http://gnu.wildebeest.org/diary/index.php?p=104 Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
lists.gnu.org and savannah.gnu.org (CVS) updates
Hi all, I talked to the GNU system administrators about the slowness of the mailinglists at times. They told me they are working on a completely new setup. Today I received the latest FRee Software Foundation Bulletin which has an article about the cool new machines that have been bought, how to install LinuxBIOS on it and what they are planning to do with them. I haven't seen this online yet, but if you become an FSF associate member you will get the paper version [1]. I'll let you know when it is online. It might take some time (weeks/months) till the whole infrastructure has moved though. It will reduce the amount of spam we need to moderate considerably and make the lists more snappy. Also savannah has seen some updates. - You can now use rsync to get a full copy of the CVS repostitory: http://savannah.gnu.org/forum/forum.php?forum_id=4142 - There is support for GNU Arch http://savannah.gnu.org/forum/forum.php?forum_id=4165 (I don't think we want to switch to that, but when subversion support hits savannah we might want to use that. No timeline yet on when/if that will be available though.) - All CVS services have now been put on cvs.savannah.gnu.org http://savannah.gnu.org/forum/forum.php?forum_id=4168 You will notice that last one when running CVS update. It will explain that you have to update the Root of your CVS working directory. If you the cvsutils installed then you can easily switch to the new CVS location by running this in your CVS working copy: cvschroot savannah-user-name@cvs.savannah.gnu.org:/cvsroot/classpath Cheers, Mark [1] Follow this link http://member.fsf.org/join?referrer=6 and make me happy! I only need 2 more referrers to receive this great gift: http://www.fsf.org/associate/referral-2004 signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: lists.gnu.org and savannah.gnu.org (CVS) updates
On Sun, 2005-12-11 at 19:47 +0100, Mark Wielaard wrote: - All CVS services have now been put on cvs.savannah.gnu.org http://savannah.gnu.org/forum/forum.php?forum_id=4168 You will notice that last one when running CVS update. It will explain that you have to update the Root of your CVS working directory. If you the cvsutils installed then you can easily switch to the new CVS location by running this in your CVS working copy: cvschroot savannah-user-name@cvs.savannah.gnu.org:/cvsroot/classpath And for those of you using anonymous CVS you need to switch to pserver: $ cvschroot :pserver:[EMAIL PROTECTED]:/cvsroot/classpath Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Proposal: Graphics2D rewrite branch
Hi, On Wed, 2005-12-07 at 12:05 -0700, Tom Tromey wrote: Tom == Thomas Fitzsimmons [EMAIL PROTECTED] writes: Tom I'd like to propose a new branch in the GNU Classpath CVS repository: Tom graphics2d-rewrite. Patches to this branch should be sent to Tom classpath-patches@gnu.org with a subject line prefix of [g2d rewrite]. Tom Commit policy is the same as GNU Classpath trunk. I say go for it. Yes, if you think you need a branch for this rewrite please do (call it something descriptive like cairo-graphics2d). I can see that if you want to just phase out GdkGraphics and always use a new setup around CairoGraphics2D that it might be nice to have a branch to not disturb the work of others. But as said by some others if at all possible do the work on the trunk. That does make it easier for others to follow/help out. Furthermore I think we should adopt gcc-ish branch rules. These are pretty reasonable and have proven to work well in practice. Namely: * Any Classpath developer can make a branch for any purpose. All branches ought to be documented somewhere, so we can know which are live, who owns them, and when they die. I don't know where we would put this though (suggestions?) I'll create a page in the wiki http://developer.classpath.org/mediation/ClasspathBranches * Some rules can be changed on a branch. In particular the branch maintainer can change the review requirements, and the requirement of keeping things building, testing, etc, can also be lifted. (These should be documented along with the branch name and owner if they differ from the trunk.) Requirements for patch email to classpath-patches and for paperwork *cannot* be lifted. And you should not see it as private or may be broken at random times. It should be as much as possible something that you work with a team on (and if there is no team - yet - then there is nothing as bad as having a completely broken build to get others to help out). * Merges from the trunk to a branch are at the discretion of the branch maintainer. * A merge from a branch to the trunk is treated like any other patch. In particular, it has to go through review, it must satisfy all the trunk requirements (build, regression test, documentation). This rule prevents folks from working around trunk rules by making a branch :-) These rules sound very good. I will add them to the Hacking Guide. There may be additional timing requirements on merging a branch to the trunk depending on the release schedule, etc. For instance we may not want to do a branch merge just before a release. Good point. I believe we do communicate very well on the mailing-lists. So I don't think this will ever be a problem. But the release master (which seems to be me atm, although we never officially created that role) should have a veto in the last few weeks before a stable release for any branch - trunk merges. Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Proposal: Graphics2D rewrite branch
On Sun, 2005-12-11 at 18:02 -0700, Tom Tromey wrote: Mark == Mark Wielaard [EMAIL PROTECTED] writes: Mark And you should not see it as private or may be broken at random Mark times. It should be as much as possible something that you work with a Mark team on (and if there is no team - yet - then there is nothing as bad as Mark having a completely broken build to get others to help out). Actually, I think it is reasonable to have a may be broken branch. In fact this is one of the main reasons for having a branch -- if you can keep stuff building and working, in many cases you won't need a branch at all. Yeah, this may be a bit too strong. I meant it as a strong warning that the branch cannot be a dumping ground for some code that isn't even supposed to work. I'll reformulate that as: @item A branch should not be seen as ``private'' or ``may be completely broken''. It should be as much as possible something that you work on with a team (and if there is no team - yet - then there is nothing as bad as having a completely broken build to get others to help out). There can of course be occasional breakage, but it should be planned and explained. And you can certainly have a rule like ``please ask me before committing to this branch''. Let me know if that still doesn't capture the spirit. Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
New bugzilla component xml
Hi, A new bugzilla component was added for all xml (javax.xml, gnu.xml) related bug reports. The initial owner is Chris, but he is of course free to not handle or reassign bugs. For the current list of bugs see: http://gcc.gnu.org/bugzilla/buglist.cgi?product=classpathcomponent=xml Initial bug component owners are just there to make sure someone has a first look at a bug and can confirm it is actually filed in the right category. There is no obligation to actually fix things. Just be nice to the reporter and refile/close things which are not properly reported. Please say when you need another component in bugzilla and want to be the initial owner for it. Andrew Pinski or I can add them and assign them to people. Cheers, Mark -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/ signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: lists.gnu.org and savannah.gnu.org (CVS) updates
Hi Archie, On Sun, 2005-12-11 at 13:39 -0600, Archie Cobbs wrote: Mark Wielaard wrote: If you have the cvsutils installed then you can easily switch to the new CVS location by running this in your CVS working copy: cvschroot savannah-user-name@cvs.savannah.gnu.org:/cvsroot/classpath And for those of you using anonymous CVS you need to switch to pserver: $ cvschroot :pserver:[EMAIL PROTECTED]:/cvsroot/classpath Hmm.. could this new infrastructure include possible a switchover from CVS to Subversion? (I'm so used to SVN now that CVS is gotten pretty gross to deal with). Subversion support for savannah is planned in the future. And it might make sense to adopt it then since other projects that rely on GNU Classpath also use it and it makes merging easier. On the other hand subversion is still a bit immature and not widely supported yet (for example on builder.classpath.org we needed to install the latest 1.3.0rc4 to get around some network timeout issues). CVS might be old and clumsy at times, it is much more mature and supported atm. That said, if savannah adds subversion support I would vote for us to switch. Cheers, Mark -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/ signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: lists.gnu.org and savannah.gnu.org (CVS) updates
Hi Archie, On Mon, 2005-12-12 at 09:31 -0600, Archie Cobbs wrote: Mark Wielaard wrote: subversion is still a bit immature and not widely supported yet (for example on builder.classpath.org we needed to install the latest 1.3.0rc4 to get around some network timeout issues). CVS might be old and clumsy at times, it is much more mature and supported atm. That said, if savannah adds subversion support I would vote for us to switch. I think you're information is slightly dated :-) Subversion is quite matture. The 1.0 release, which itself was very stable, was released almost two years ago. Now they're up to version 1.2.3. For example, all of Apache is on a single Subversion server and they're up to revision #356264 (including imported CVS commits). We've used it at my real job for over a year with zero problems. As far as being supported, not sure what you're referring to. Everything I've ever wanted to do with CVS I can do with SVN, plus a lot more. Don't get me wrong I do like subversion. And I used it for multi megabyte imports of classpath source into different gcc branches. And most things do work really nicely. And even much smoother then with CVS. But fact is that the first time I needed to use svn instead of cvs it took twice as long, since it isn't really a 1-to-1 mapping (to be fair, next time the same task will probably take me half the time). And I did experience some glitches (which is why we needed version 1.3.0rc4 on builder), nothing that looses data, but small inconveniences like very slow or stalled network connections in automated scripts. Or the fact that you really need to setup an external diff command since the built-in one is not capable enough. With supported I meant that CVS can be expected to be available everywhere in a really stable version. Subversion isn't there yet. It is starting to become more standard, but it isn't yet something that is just installed by default, so for people using multiple diverse platform/distributions it takes much more time to get a working setup. Also importing an old CVS repository like all of GCC seems possible now but there were some small anomalies. So the switch will have to be done carefully and will take some time to get right and double check. Lastly working copies take more than twice as much diskspace as with CVS (I do know that means some operations are much faster, but with large repositories like classpath it does add up when you have multiple checkouts). All this isn't meant as saying we shouldn't adopt subversion when savannah supports it though. Just to say that it isn't slam-dunk decission given the diverse background of our hackers. I am still convinced that if savannah supports it we should switch, but I do want to let people know there are some (small) downsides. Cheers, Mark -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/ signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: lists.gnu.org and savannah.gnu.org (CVS) updates
Hi, On Mon, 2005-12-12 at 13:42 -0700, Tom Tromey wrote: Mark Or the fact Mark that you really need to setup an external diff command since the Mark built-in one is not capable enough. ? I haven't noticed this one. See the bottom of http://gcc.gnu.org/wiki/SvnSetup Again, not a showstopper, just another example of small configuration issues. They do add up for people and it takes some time to be as productive as before. Just like the fact that emacs or eclipse doesn't come with subversion support out of box but require additional scripts and plugins. Not a big deal, but still annoying when you are used to the availability of CVS in each and every tool out there. Mark Also importing an old CVS repository like all of GCC seems possible now Mark but there were some small anomalies. So the switch will have to be done Mark carefully and will take some time to get right and double check. GCC has a long and complicated history, including evil repository hacking and re-basing branches using 'cvs admin'. I'm sure the Classpath import won't be as bad. I do hope so. But it will take time, energy and some patience to do it correctly and check the conversion. Lets continue the discussion if/when savannah actually support subversion. No need to start nitpicking the pros and cons at this time. I actually think we will agree that all the little drawbacks/flaws are nothing compared to the productivity boost in the long run. Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Fosdem 2005 reminder (Feb 25/26)
Hi all, Please do tell us if you are planning to come to the GNU Classpath hacker room in Brussels, Belgium Februari 25 and 26, 2006 (mailto:[EMAIL PROTECTED]) Yes, you will be allowed in even if you didn't tell us in advance :) We just want to see how many people are interested so we can better plan the talks, demos, discussions, etc. If you want to give a demo, presentation or have a discussion topic please also send an email to [EMAIL PROTECTED] so we can create a great schedule for the event. See for suggestions the original announcement (attached). Cheers, Mark ---BeginMessage--- 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/ signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath ---End Message--- signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Security manager problem
Hi Gary,
On Mon, 2005-12-12 at 17:55 +, Gary Benson wrote:
Gary Benson wrote:
Robert Lougher wrote:
Do you have a testcase?
If you build and run the attached testcase you ought to see only one
checkPermission() between Calling checkRead() and Done. ... In
reality, JamVM chokes on it pretty hard. I _think_ what is
happening is that the System.out.println in checkPermission() is
itself doing some initialisation which causes security checks,
causing an infinite loop.
The initialisation in question turns out to be:
1. Loading java.lang.StringBuffer to build the message.
2. Loading java.io.PrintStream to print it out.
3. Converting the message to bytes using String.getBytes(encoding).
Any one of them will trigger a security check and hence an infinite
loop.
Aha! There is your clue. libgcj hasn't merged in the new nio charset
provider setup. And indeed creating a new CharsetProvider requires a
RuntimePermission(charsetProvider). Even for creating the default
provider. Which obviously should always be created, otherwise nothing
works. It is safe in this case since we know the default provider
doesn't do nasty things (or at least we hope so). So you need the
attached patch to gnu/java/nio/charset/Provider.java.
But even then you need some more workaround. There are two steps needed:
- Before the SecurityManager is installer we make sure that the whole
System.out pipeline gets initialized.
- In the user defined TestSecurityManager we make sure that all classes
that are used in the checkPermission() method are loaded before it
gets installed. That is System and StringBuffer (because we use +).
Modified Test.java attached.
All this seems to come from having a user defined security manager
loaded by a user defined class loader (the default System/Application
class loader). We need to do ClassLoader.loadClass() checks in that
case. But as shown in this example that leads very easily to recursive
checkPermission() calls.
I don't have a good idea how to make this easier. Any ideas?
Cheers,
Mark
import java.security.*;
class Test
{
static class TestSecurityManager extends SecurityManager
{
TestSecurityManager()
{
// Make sure the classes needed by checkPermission() are loaded.
Class c = System.class;
c = StringBuffer.class;
}
public void checkPermission(Permission perm) {
System.out.println( checkPermission( + perm + ));
}
}
public static void main(String[] args) {
try {
// Make sure System is loaded
// and the full System.out pipeline is initialized.
System.out.println(Installing TestSecurityManager);
SecurityManager sm = new TestSecurityManager();
System.setSecurityManager(sm);
System.out.println(Calling checkRead());
sm.checkRead(/);
System.out.println(Done);
}
catch (Throwable t) {
t.printStackTrace();
}
}
}
Index: gnu/java/nio/charset/Provider.java
===
RCS file: /cvsroot/classpath/classpath/gnu/java/nio/charset/Provider.java,v
retrieving revision 1.6
diff -u -r1.6 Provider.java
--- gnu/java/nio/charset/Provider.java 2 Jul 2005 20:32:13 - 1.6
+++ gnu/java/nio/charset/Provider.java 13 Dec 2005 18:38:18 -
@@ -39,6 +39,8 @@
import java.nio.charset.Charset;
import java.nio.charset.spi.CharsetProvider;
+import java.security.AccessController;
+import java.security.PrivilegedAction;
import java.util.Collections;
import java.util.HashMap;
import java.util.Iterator;
@@ -232,8 +234,16 @@
public static synchronized Provider provider ()
{
+// The default provider is safe to instantiate.
if (singleton == null)
- singleton = new Provider ();
+ singleton = (Provider) AccessController.doPrivileged
+ (new PrivilegedAction()
+ {
+ public Object run()
+ {
+ return new Provider();
+ }
+ });
return singleton;
}
}
signature.asc
Description: This is a digitally signed message part
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath
ANN: gjdoc 0.7.7 released
We are pleased to announce gjdoc release 0.7.7. gjdoc is the GNU documentation generation framework for java source files. gjdoc is part of GNU Classpath Tools: http://www.gnu.org/software/classpath/cp-tools/ This is mostly a bug-fix release. This makes gjdoc much more robust when dealing with invalid documentation tags or source code and it is now possible to generate the whole javadocs for eclipse using gjdoc out of the box. New in release 0.7.7 * Bug fix release - gjdoc/24457: NPE for @see tag - gjdoc/24474: StackOverflowError in reflexive expressions - gjdoc/24501: gjdoc doesn't compile - gjdoc/24508: Files weren't generated for packages with names like *.java - gjdoc/24509: gjdoc is not able to use the javadocs from java.sun.com - gjdoc/24510: gjdoc have problems the -linkoffline - gjdoc/24507: The overview-summary.html are not generated - gjdoc/24553: Problem with @link tags in parameter descriptions - gjdoc/24722: Problems with single line comments between method arguments Thanks to Stephan Michels, David Gilbert, Julian Scheid and Michael Koch for reporting bugs, suggesting and testing fixes and preparing the release. The latest release of GNU gjdoc can always be found at ftp://ftp.gnu.org/gnu/classpath/ This new version of gjdoc has been used to generate class documentation for the GNU Classpath CVS source files: http://developer.classpath.org/doc/ -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/ signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
builder setup
Hi all, Hi list,
builder.classpath.org seems to shape up nicely.
There were 3 reboot last night. I assume that was Jim doing a Xen
upgrade?
There were a couple of issues with email (the scripts now fake the
envelop sender with sendmail to look like emails come from
developer.classpath.org) that I have asked the gnu.org sysadmin to look
at (we had the same issue with developer.classpath.org in the past,
gnu.org thinks it handles all of classpath.org, but developer and
builder are special).
I tweaked the Ecj script that Anthony contributed a bit (also created a
toplevel Nightly/ecj dir that the script expects to be there) and
together with Tom debugged gcjx a little. The script now builds/runs 5
versions of ecj:
- build ecj bytecode with gcj -C
- build native ecj with gcj
- build ecj bytecode with gcjx
- build ecj with jamvm using gcj bytecode version
- build ecj bytecode with native-ecj
There should probably be a jacks run added to check that
ecj-built-by-ecj version is completely sane. The produced ecj hasn't
been wired into the other build/check scripts.
I currently have a screen session running with one screen doing:
source setup; while true; do Everything; Report Idle; sleep 3600; done
(The sleep is there to prevent builder going insane and spamming
classpath-testresults with failure messages.)
And another doing:
source setup; cd Nightly;
gij -cp /home/cpdev/ircbot/pircbot.jar:/home/cpdev/ircbot/cpbot.jar
gnu.classpath.ircbot.Main
(irc seems a bit flaky so sometimes our little bot needs to be restarted
by hand)
I haven't figured out how to easily share this screen setup. Screen
seems to not like being run from a sudo su cpdev session :{
Any hints or tips appreciated.
There is no real web frontend yet, but I did do:
ln -s /home/cpdev/Nightly/CurrentStatus /var/www/index.html
so you can see what builder is doing by looking at
http://builder.classpath.org/
I am planning to create a new builder module in mauve to more easily
share the code next week with others as soon as we are reasonable happy
about the current script setup.
Cheers,
Mark
--
Escape the Java Trap with GNU Classpath!
http://www.gnu.org/philosophy/java-trap.html
Join the community at http://planet.classpath.org/
signature.asc
Description: This is a digitally signed message part
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath
Re: builder setup
Hi Tom,
On Tue, 2005-12-20 at 09:17 -0700, Tom Tromey wrote:
Mark == Mark Wielaard [EMAIL PROTECTED] writes:
Mark And another doing:
Mark source setup; cd Nightly;
Mark gij -cp /home/cpdev/ircbot/pircbot.jar:/home/cpdev/ircbot/cpbot.jar
Mark gnu.classpath.ircbot.Main
Mark (irc seems a bit flaky so sometimes our little bot needs to be restarted
Mark by hand)
Could we change the bot to restart itself on failure?
Probably, but I haven't looked very closely at the source. What seems to
happen is that the irc server sometimes just traps the bot and doesn't
let it join a channel, I haven't found out why. Often it happens for a
couple times so I need to restart the bot till it clear up.
Mark I haven't figured out how to easily share this screen setup. Screen
Mark seems to not like being run from a sudo su cpdev session :{
Mark Any hints or tips appreciated.
Instead of screen we could run it in the background, and provide a
couple scripts to start and stop it. We could also add an '@reboot'
cron job to make sure it starts when the machine is rebooted.
Yeah, that is probably better. I thought the screen idea was nicer since
you can in principle share it, but apparently that doesn't work well
when su-ing to a different user since screen gets confused about the
controlling terminal.
Cheers,
Mark
signature.asc
Description: This is a digitally signed message part
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath
Re: Hacking Classpath in Eclipse
Hi, On Tue, 2005-12-20 at 17:53 -0700, Tom Tromey wrote: We think it is now ready for a wider audience. You can read it here: http://developer.classpath.org/mediation/ClasspathHackingWithEclipse This document will walk you through setting up Eclipse, checking out Classpath, Cacao, and Mauve, and then trying them out. This is still a work in progress, but we think the instructions here should generally work ok. I played a bit more with it and it certainly has potential. The most impressive thing is how well native Eclipse actually works! In the past eclipse didn't really feel that stable, but the versions that come with Fedora and Debian seem pretty solid out of the box. It is clear we did a lot of stabilizing in the last couple of months. The single Mauve testlet example is pretty nice. Since if everything is setup a simple edit and save of a core library file is enough to retest the Testlet and immediately see PASS/FAIL results. I found a cute hack to actually run a single mauve Testlet from within eclipse using the just compiled classpath: $ mkdir -p ~/workspace/classpath/install/jre/lib $ touch ~/workspace/classpath/install/jre/lib/rt.jar Now as by magic you can add ~/workspace/classpath/install as JRE to eclipse (under Preferences - Java - JREs) and then configure Runners to use that alternative jre. I added a quick SingleTestHarness and MauveRun Runner to mauve as an example. With it you can immediately run a mauve Testlet that you are working on against the classpath code you are hacking inside eclipse. I have to get me some sleep now, but I will add it to the wiki tomorrow if nobody beats me to it. Cheers, Mark -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/ signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: [Devjam] Re: DevJam thanks, devjam mailinglist and DevJam++
Hi, On Wed, 2005-12-21 at 14:34 +0100, Petter Reinholdtsen wrote: [Mark Wielaard] And if you are interested in participating or helping out with a followup meeting please see the wiki about DevJam++: http://java.debian.net/index.php/DevJam++ Is it about time to start planning a new gathering? The new URL is URL:http://wiki.debian.org/Java/DevJam. Debian can probably help out with funding, and Andreas Schuldei got friends in Spain that could provide a location. I know FOSDEM is coming up (in February) and will host a java meeting, so I suggest the next devjam should be later in the spring, perhaps May (co-located with debconf6 in Mexico?). Since I am personally pretty busy at the moment (with Fosdem) I have CCed the GNU Classpath mailinglist since there are more hackers there that can help plan the next DevJam. It is probably good if interested people would already add their name and location to http://wiki.debian.org/Java/DevJam Then we can more easily see what a good location would be. Since the last DevJam and the Fosdem meetings were all in Europe it might make sense to have the next DevJam in North America/Canada (since I believe that is were a large part of our hackers are located). The difference between the Fosdem meeting and the DevJam meeting is that DevJam is more focused on actually hacking and working out ideas together and less about end-users, demos and presentations. So if people could add ideas for one or two day hack sessions to the wiki page that would be nice to see what projects can be worked on. If people want to help organize this please do join the devjam mailinglist: http://developer.classpath.org/mailman/listinfo/devjam Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Hacking Classpath in Eclipse
Hi, On Wed, 2005-12-21 at 19:21 -0700, Tom Tromey wrote: Note that this will work for running something, but not if you want to compile against that JRE. For the latter I think we need to come up with some kind of fake jdk project. I actually have the start of one here, but I haven't finished polishing it yet. Ideally Eclipse would offer the possibility of auto-exporting the build results as a .jar. That would solve this entirely. Wouldn't it be enough if we could convince eclipse to accept a hand-made jre? I mean one where you can you explicitly set the individual binaries that make up the tools that eclipse expects? Plus convincing the built-in eclipse compiler to use a flat (non-jar/zip) bootclasspath? (I believe ecj can use dirs already, but haven't checked.) It feels like eclipse is just trying to be too clever in its jre detection. Maybe if the JRE definitions preference box had an override - I know what I am doing box, so you could fill in the individual parts that make up the StandardVMType thing. If you take a quick look at org/eclipse/jdt/internal/launching/StandardVMType.java it looks like this class just needs a set of setters and a way to override that auto detection. Or maybe we need a new subclass of AbstractVMType that creates an IVMInstall just based on user defined locations that can be plugged into the standard JRE preferences dialog as override to the autodetecting StandardVMType? Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Using a workspace-based VM in Eclipse
Hi Tom, On Thu, 2005-12-22 at 12:34 -0700, Tom Tromey wrote: Once that is done, check out the fakejdk project from :pserver:[EMAIL PROTECTED]:/cvs/rhug, module 'fakejdk'. (This ought to auto-build, but if not, apply the usual Clean hack.) This just makes a little project consisting of symlinks -- it is a huge hack. One of the symlinks didn't work for me. Attached is a patch for the tools.jar to try and find it in some other location. Generated by eclipse of course :) Now, go to Window-Preferences-Java-Installed JREs and choose 'Add...' to add a new one. I named mine Cacao. For the JRE home directory, choose $workspace/fakejdk. Then turn off Use default system libraries and you can edit the Source attachment of the new JRE to point to the classpath directory in the workspace. Strangely the attach source step didn't work. I always get: Assertion failed; Path for IClasspathEntry must be absolute Once this is done you can pick this JRE for launchers, or to build other projects against. This is nice because it means these projects don't have to necessarily depend on Classpath -- there is a layer of indirection, so you can build and run them against the system VM if you prefer to do that, without modifying the shared build setup. Wow! That is really nice. It seems to work instantly. Edit the project or edit classpath and on a rerun your changes are there :) Thanks, Mark Index: build === RCS file: /cvs/rhug/fakejdk/build,v retrieving revision 1.1 diff -u -r1.1 build --- build 22 Dec 2005 19:01:09 - 1.1 +++ build 22 Dec 2005 22:51:40 - @@ -38,7 +38,13 @@ cd $top/lib # FIXME: tools.jar # We have to merge with java-gcj-compat. -cp /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/lib/tools.jar tools.jar +if test -f /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/lib/tools.jar; then + cp /usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/lib/tools.jar tools.jar +elif test -f /usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/lib/tools.jar; then + cp /usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/lib/tools.jar tools.jar +else + cp /usr/lib/jvm/java-*-gcj-*/lib/tools.jar tools.jar +fi cd $top/jre/bin ln -s $classpath/install/bin/$vm java signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Using a workspace-based VM in Eclipse
Hi Tom, On Thu, 2005-12-22 at 15:53 -0700, Tom Tromey wrote: Yeah, that one is super bogus. And, I think, not actually needed. Anyway, commit that if you like. You have rhug access, right? No I don't think I have rhug access. Mark Strangely the attach source step didn't work. I always get: Mark Assertion failed; Path for IClasspathEntry must be absolute Hmm. Did you choose Workspace... when specifying the source path? I did... anyway, check your .log, maybe this is a bug somewhere. It happens before that. When hitting the Edit... button. I worked around it by just removing the rt.jar and readding it by hand. Then I can Edit and attach source for the classpath workspace. Mark Wow! That is really nice. It seems to work instantly. Edit the project Mark or edit classpath and on a rerun your changes are there :) Yup, this is why I think Eclipse is the easiest way to develop Classpath. At least, that is true for the Java side of things. For the native code the traditional tools are probably still in the lead. It looks like the native side gets rebuild a lot though. I guess there are some dependencies wrong since I seem to trigger a full rebuild of cacao a lot when running mauve for example. Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: java.swing.text.NumberFormatter
Hi Roman, On Fri, 2005-12-23 at 10:33 +0100, Roman Kennke wrote: Thanks for your explanations. Could you file a bugreport about this and assign it to me (roman at kennke dot org), so it doesn't get lost? Right now I don't have much time and I'll try to look at this in a few days. Chris already did :) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25536 This is now assigned to you. BTW. For those that want to track the bug reports more closely, all bugzilla messages also go to bug-classpath http://lists.gnu.org/mailman/listinfo/bug-classpath which is also archived at gmane http://dir.gmane.org/gmane.comp.java.classpath.bugs Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Using a workspace-based VM in Eclipse
Hi Robert, On Thu, 2005-12-22 at 23:40 +, Robert Lougher wrote: On 22 Dec 2005 12:34:42 -0700, Tom Tromey [EMAIL PROTECTED] wrote: To do this, follow the wiki instructions to check out and build Classpath and Cacao (as always, this VM is chosen because all the needed build bits are in its cvs repository... hint to the other VM developers). Hint taken. The necessary files are now in JamVM's cvs repository. This is your patch with a couple of changes by Raif that adds the .cvsignore files and adds an Autogen Builder to create, among other things, the configure script. Wee! This is cool. I needed one small patch to make it all work smoothly with the fakejdk project. Besides building everything jamvm should also be installed and then you can just automagically switch fakejdk to use jamvm (it will automatically select jamvm if cacao isn't available). Now my eclipse based projects can use the just build in workspace classpath and jamvm for development. Patchlet attached. Cheers, Mark Index: .project === RCS file: /cvsroot/jamvm/jamvm/.project,v retrieving revision 1.1 diff -u -r1.1 .project --- .project 22 Dec 2005 21:36:56 - 1.1 +++ .project 23 Dec 2005 10:44:12 - @@ -56,11 +56,11 @@ /dictionary dictionary keyorg.eclipse.cdt.make.core.build.target.full/key - valueclean all/value + valueclean all install/value /dictionary dictionary keyorg.eclipse.cdt.make.core.build.target.auto/key - valueall/value + valueall install/value /dictionary dictionary keyorg.eclipse.cdt.make.core.build.location/key @@ -84,7 +84,7 @@ /dictionary dictionary keyorg.eclipse.cdt.make.core.build.target.inc/key - valueall/value + valueall install/value /dictionary dictionary keyorg.eclipse.cdt.make.core.enableCleanBuild/key signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Using a workspace-based VM in Eclipse
Hi Raif, On Fri, 2005-12-23 at 19:56 +1100, Raif S. Naffah wrote: Now, go to Window-Preferences-Java-Installed JREs and choose 'Add...' to add a new one. I named mine Cacao. For the JRE home directory, choose $workspace/fakejdk. Then turn off Use default system libraries and you can edit the Source attachment of the new JRE to point to the classpath directory in the workspace. when i do that Eclipse claims that Target is not a JDK root. System library was not found. this turns out to be caused by the fact that the instructions to follow do not cause a glibj.zip to be generated, and hence be used as the fake rt.jar. Are you sure you have the latest GNU Classpath CVS checked out in eclipse? Tom added a new Builder ClasspathJar that generates a glibj.zip after everything else has been build. See classpath Project - Properties - Builders. Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
0.20 (next year)
Hi all, I had wanted to push out one more new developer snapshot release (0.20) this year, but got distracted by setting up the new builder machine for automatic regression testing and the eclipse build infrastructure (both very cool things!). And now it seems that I might actually not have any internet access till the end of the year/early next year because I am moving houses (and the internet seems to be stuck somewhere between the two...). So lets move 0.20 to next year. Lets pick an arbitrary date, the second weekend of 2006 (between 10 and 12 January). Please go over the list of features and bugs and think about what you can finish before 0.20. And if someone wants to go over the ChangeLog file and add all the big things to the NEWS file that would be really appreciated. Replying to this post with things you want to work on or things you want to postpone till after 0.20 is also appreciated to keep everybody in the loop. If possible it would be nice to do another generics-branch release at the same time. So that branch should also be remerged. And if I fail to find proper internet access in the next one or two weeks: Happy Holidays! Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: XML parsing problems
Hi Chris, On Tue, 2005-12-27 at 20:03 +, Chris Burdess wrote: Please test the new XML parser on as many weird and wonderful XML sources as you can, and report any problems to me either by mail or Bugzilla - I will try to deal with them before release, or we can revert to aelfred2 again if there are other showstoppers. Nice work! You are running some test-suites from time to time on the xml parsers. If these are free then I would like to add them to builder.classpath.org so regressions (or better conformance results) are automatically tracked. How much space do they need and is it difficult to setup? Cheers, Mark -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/ signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: building Classpath for Win32
Hi Enrico, On Sat, 2005-12-24 at 13:01 +0100, Enrico Migliore wrote: I would like to build Classpath for Windows with Cygwin's GCC and GCJ. I read the INSTALL file but it doesn't say how to configure the tarball for a Windows build. It used to be possible and Stephane wrote up an install guide at: http://developer.classpath.org/mediation/ClasspathOnCygwin But it might be that those instructions are out of date now. If so, then please let us know and/or update that page. Thanks, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
GNU Classpath friends meeting during Fosdem 2006
GNU Classpath friends meeting during Fosdem 2006. The various free software library, runtimes, compiler and tool projects around GNU Classpath will meet in Brussel 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/ The program will be as follows: - Saturday from 13:00 to 17:30 - End-User talks Presentations that show what cool stuff can be done with the Free Stack right now. - Putting the 'Free' into JFreeChart Dave Gilbert, JFreeChart Project Leader A review of the efforts to make JFreeChart work with GNU Classpath-based runtimes, including a brief history, a demonstration of the current state (using the java bindings for Cairo), and an overview of the work that remains to be done. - Using Eclipse for GNU Classpath development Tom Tromey Learn how to setup a fully working development environment based on GNU Classpath in Eclipse that can be used to bootstrap the full free toolchain (and can be used to run Eclipse itself) in just 10 minutes. - Eclipse RCP and GCJ/GIJ Wayne Beaton Eclipse Rich Client Platform (RCP) is a runtime platform for delivering your Java applications on multiple platforms. RCP is far more than just a windowing toolkit; it is rich client middleware that provides a comprehensive framework for building and deploying applications that are modular, extensible, and updatable. The kinds of applications you can build with Eclipse RCP are limited only by your imagination. During this talk, we will discuss how the Eclipse RCP can be used in conjunction with the Eclipse Eco-system and GCJ/GIJ to build high quality applications. If there is time at the end of the day we would like to do a Show-And-Tell where people do quick Demos of applications running on a completely free stack. Ideas and suggestions welcome. - Sunday from 09:00 to 13:00 - Developer talks Presentations of (core) libraries and runtimes that are in progress, made a lot of progress in the last year and are in active development. - Free Swing, past, present and future Roman Kennke An overview of that state of Free Swing one year ago, what has been done in the meantime, what still must be done and which applications work now. - The Free CORBA comes Dr Audrius Meskauskas If the Free world does not want to step back in the battle, we need a complete set of the Free tools for advanced communication over the network. For our CORBA implementation we needed: 1. Free. No classes with restricted license. 2. Fully workable, interoperable and pass tests, recognized by the CORBA user community as serious (we needed to find a well known Free testing suite). 3. Properly commented, being ready for the long life in the Free world. 4. No pressure to use the outdated approaches. CORBA 3.0.3 and jdk 1.5. To reach these goals, we have chosen for implementing a clean room implementation, using the published standard specifications only. During the recent year of the GNU Classpath development, this goal is in large degree achieved. The important directions of future development could be providing features that are outside the scope of the both CORBA standard and Sun API, but included in the near all proprietary implementations (SSH, HTTP and other bridges, get rid of rmic code generator for RMI/IIOP, fault tolerant behavior, reduced the footprint and others). - The JamVM runtime Robert Lougher An overview of the JamVM virtual machine, with comparisons to other GNU Classpath runtimes, and a section on the VM interface. - Integrating Vmgen-based interpreters Christian Thalinger Vmgen is a tool for writing efficient interpreters. The Cacao runtime recently added a Vmgen based interpreter in addition to the JIT engine. - Sunday from 14:00 to 17:30 - The Future Interactive technical hacker discussions on how to integrate the projects more and move forward in the next year. - State of the world, beyond japi Mark Wielaard, GNU Classpath Maintainer After a short overview of the various free stacks, libraries, compilers, tools and runtimes this session is mostly open discussion about what work remains to be done and how to integrate the various efforts better. Ideas for work items welcome. We hope to see you in Brussels on February 25 and 26 2006, If you have suggestions or ideas for the demos and discussion sessions please contact us at [EMAIL PROTECTED
New GNU Classpath developer Raif Naffah
Hi all, I am happy to announce that Raïf decided to become one of our active hackers. Raïf was the former maintainer of GNU Crypto before Casey took over that package, and has been helping with integrating and testing the security and crypto framework in GNU Classpath (and writing Mauve test for it). Recently he created the HackingClasspathWithEclipse page on our developer wiki: http://developer.classpath.org/mediation/ClasspathHackingWithEclipse Raïf, even though you have been contributing to GNU Classpath in the past you name is missing in the AUTHORS file. Please post a patch and ChangeLog entry to add yourself to the AUTHORS file to the classpath-patches mailinglist. You can consider that patch pre-approved so feel free to commit it immediately as a test of your new powers. But remember that with power comes responsibility! (*) Thanks, Mark (*) http://www.gnu.org/software/classpath/docs/hacking.html -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/ signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: compiling Classpath on cigwin/win
Hi, On Mon, 2006-01-02 at 19:10 +0100, Enrico Migliore wrote: The problem is that the Classpath compilation process started this morning at 8:00 and, at 5 p.m., hasn't finished it. The machine I'm using is a: CPU: Intel @ 3GHz RAM: 192 MBytes OS: WinXP case: Laptop Is it reasonable a compilation time that long? yes. it is probably swapping itself to death. Do you mean anything is going wrong? I don't think this is normal, even with just 192MB memory. What was the last output of the build? Do you have top or ps on cygwin to see which process is active at the moment? If it is jikes try adding -verbose to the following line in lib/Makefile JAVAC = $(JIKES) $(JIKESWARNINGS) +F $(JIKESENCODING) -bootclasspath '' -extdirs '' -sourcepath '' --classpath $(compile_classpath) -d . @classes That should at least give a clue what jikes is doing. Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: compiling Classpath on cigwin/win
Hi Enrico, If you can figure out why jikes hangs, either by adding -verbose to the Makefile or by stracing or running it under gdb (if available under cygwin) that would be interesting. On Tue, 2006-01-03 at 09:41 +0100, Enrico Migliore wrote: The only one left is the Eclipse compiler. When I try: ./configure --with-ecj the configure script tells me that ecj is not found ECJ is a class, embedded in the following Eclipse plugin: org.eclipse.jdt.core.compiler ** and therefore is not an ordinary application. Can somebody tell me how to instruct the configure script to use the ECJ compiler? On builder.classpath.org we bootstrap the ECJ compiler with GCJ. I am not 100% sure you can do this with an older gcj (builder uses gcc from cvs), but if you can try then this is what should work: cvs -d:pserver:[EMAIL PROTECTED]:/home/eclipse co \ org.eclipse.jdt.core cd org.eclipse.jdt.core find compiler batch -name \*.java | xargs gcj \ --main=org.eclipse.jdt.internal.compiler.batch.Main \ -Icompiler -Ibatch -o ecj Then you have a native ecj executable that can be used to bootstrap classpath. Has anybody ever successfully built GNU/Classpath on Cygwin? Yes in the past, but clearly none of the core developers are using cygwin regularly. So it has bitrotten a bit. Sorry and thanks for trying to get it working. Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: compiling Classpath on cigwin/win
Hi Paul, On Tue, 2006-01-03 at 22:05 +, Paul Jenner wrote: Haven't figured out why (yet :-) but I can say where for anyone else playing with this. jikes looks to hang compiling org/omg/CORBA/INVALID_ACTIVITY.java under Cygwin. Take that file out of the classes list manually and jikes build completes for me. Try to compile just that file from within the build infrastructure and jikes hangs. O, interesting. The class comment in that file contains some strange characters. Does removing them help? Cheers, Mark Index: org/omg/CORBA/INVALID_ACTIVITY.java === RCS file: /sources/classpath/classpath/org/omg/CORBA/INVALID_ACTIVITY.java,v retrieving revision 1.1 diff -u -r1.1 INVALID_ACTIVITY.java --- org/omg/CORBA/INVALID_ACTIVITY.java 22 Oct 2005 19:57:03 - 1.1 +++ org/omg/CORBA/INVALID_ACTIVITY.java 3 Jan 2006 22:12:34 - @@ -43,7 +43,7 @@ /** * Raised when the transaction or Activity is resumed in a different context * than from which it was suspended. It is also raised when the invocation is - * not incompatible with the Activity’s current state. + * not incompatible with the Activity's current state. * * @since 1.5 * signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: compiling Classpath on cigwin/win
Hi Paul, On Tue, 2006-01-03 at 22:20 +, Paul Jenner wrote: On Tue, 2006-01-03 at 23:12 +0100, Mark Wielaard wrote: O, interesting. The class comment in that file contains some strange characters. Does removing them help? Just noticed that myself. Yep - remove the odd characters and build is merrily completing for me. Great! Committed as follows: 2006-01-03 Mark Wielaard [EMAIL PROTECTED] * org/omg/CORBA/INVALID_ACTIVITY.java: Remove non-ascii characters. Thanks, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: gnu.xml.dom.DomText implements Text and NodeList.
Hi,
On Wed, 2006-01-04 at 07:16 +, Chris Burdess wrote:
My proposed solution is:
Add to gnu.xml.dom.DomText:
import org.w3c.dom.NodeList;
/**
* Returns an EmptyNodeList.
*
* @author Pedro Izecksohn
*/
public NodeList getChildNodes()
{
return (NodeList) new EmptyNodeList();
}
Add to gnu/xml/dom/ the file EmptyNodeList.java:
package gnu.xml.dom;
import org.w3c.dom.Node;
import org.w3c.dom.NodeList;
/**
* @author Pedro Izecksohn
*/
public final class EmptyNodeList implements NodeList
{
public EmptyNodeList () {}
public final int getLength () {return 0;}
public final Node item (int index) {return null;}
}
That looks absolutely correct.
Thanks Pedro. Some small suggestions for improvements.
It really should be a static inner class (since no state of the outer
class is used). And maybe we can share one instance of the EmptyNodeList
for the whole dom tree so if a tree contains lots of empty node list we
only allocate one. BTW. The cast in getChildNode() isn't necessary since
EmptyNodeList already is a NodeList.
Cheers,
Mark
signature.asc
Description: This is a digitally signed message part
___
Classpath mailing list
Classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath
Fosdem LiveCD
Hi, Crazy idea time. It would be nice if we had a LiveCD for Fosdem that showed all the cool stuff we have working now. On Saturday (Feb 25) we would like to have a little Show-And-Tell to give people the oppertunity to show off their favorite applications. What better way to show off then to be able to say: and take this CD, it has everything on it ready to go! :) I was hoping that Fedora Core 5 would be out around Fosdem, but they extended their schedule by a couple of weeks and are now releasing just after Fosdem (March 15). Otherwise we could have nagged those Red Hatters that they should hand out those since Fedora Core 5 is based on GCC 4.1 (CVS-pre-release) it has most of the latest stuff already. Has someone experience with creating LiveCDs? (I don't, so maybe my idea of it being easy to create a LiveCD is terribly naive.) Can it be based on a Fedora Core 5 test release? (Fedora Core seems the most stable and includes Jonas) Or should we base it on the Debian packages (They have more things packaged like jamvm, kaffe, cacao, but don't have jonas yet and most things are based on the stable gcc 4.0.x release.) Does anybody know of a cheap way to create the CDs? Or do we have someone with a CD burner so we could burn them on the spot? Maybe that takes too long though. Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: CACAO in Debian
Hi Christian, On Wed, 2006-01-04 at 10:53 +0100, Christian Thalinger wrote: Tonight we finally made it into debian, woohoo! The build status page is here: http://people.debian.org/~igloo/status.php?packages=cacao Nice. It looks like only i86 and powerpc build at the moment. I thought you also had alpha, mips and arm working at one point. Is there a list of supported cacao platforms? Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: compiling Classpath on cigwin/win
On Thu, 2006-01-05 at 08:56 +0100, Enrico Migliore wrote: I still got 2 problems on my Cygwin which prevent Classpath from generating glibj.zip Problem 1 -- Found when issuing: $make make all-am make[2]: Entering directory `/home/Enrico/projects/classpath/classpath-0.19/examples' mkdir -p classes/gnu/classpath/examples/icons cp ./gnu/classpath/examples/icons/*.png classes/gnu/classpath/examples/icons /usr/local/bin/jikes -bootclasspath '' -extdirs '' -sourcepath '' --classpath ../lib:. -d classes ./gnu/classpath/examples/*/*.java cd classes; -r ../examples.zip .; cd .. /bin/sh: -r: command not found Configure didn't find zip. This is a bug in out configure setup: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24133 Configure does not detect (fatal) missing zip executable Problem 2 is most likely the same issue. Have you installed zip? If not, try installing that first. If you have make sure it is in your PATH. And if it is still not found look in config.log to see if there is an hint why it isn't found. Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
GPLv3 meeting
Hi all, As most of you probably know the FSF will go through a design process for the next revision of the GPL this year (http://gplv3.fsf.org/). I have given some feedback on license/legal issues we have seen with the GNU Classpath and related projects (especially about what a pity it is that the ASL and EPL are Free Software licenses with additional or different restrictions from the GPL which makes easy sharing of code-bases difficult). Unfortunately I cannot make it to the v3 intro meeting at the MIT in Cambridge, MA, USA, on January 16-17. David asked me to see if someone else from GNU Classpath could make it: I will ask around. But most hackers are coders, not legal enthusiasts :) What kind of input would be expected from them? We're interested in how they read the language (since the GPL is written as much for programmers as for lawyers). And we would like to hear stories about how licensing has affected various Free Software projects. We want to bring together developers to create the best license possible for the next fifteen years. So if you live around Boston and are able to attend the v3 intro meeting please register and share our stories (http://gplv3.fsf.org/launch). The FSF also made sure that there will be Apache and Eclipse people at the meeting. Cheers, Mark -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/ signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: 0.20 (next year)
Hi all, On Sat, 2005-12-24 at 12:02 +0100, Mark Wielaard wrote: I had wanted to push out one more new developer snapshot release (0.20) this year, but got distracted by setting up the new builder machine for automatic regression testing and the eclipse build infrastructure (both very cool things!). And now it seems that I might actually not have any internet access till the end of the year/early next year because I am moving houses (and the internet seems to be stuck somewhere between the two...). So lets move 0.20 to next year. Lets pick an arbitrary date, the second weekend of 2006 (between 10 and 12 January). Internet access restored :) Seems I was confused about the dates. 10/12 January isn't a weekend, but lets try to prepare a 0.20 snapshot by the end of this week. Please go over the list of features and bugs and think about what you can finish before 0.20. And if someone wants to go over the ChangeLog file and add all the big things to the NEWS file that would be really appreciated. Replying to this post with things you want to work on or things you want to postpone till after 0.20 is also appreciated to keep everybody in the loop. Please don't add any new larger (vm) changes this week. The merge of all GNU Crypto will wait till after 0.20. I haven't looked at the target-native/vm-interface threads/proposals yet and would like to postpone those also till next week. If possible it would be nice to do another generics-branch release at the same time. So that branch should also be remerged. Andrew said he might be able to do this. Please let us know if you can find time for this or whether you want someone to help do the merge. Please do report any positive or negative stories about the current (CVS) code base. It seems in pretty good shape. The autobuilder does show some swing.text regressions, but I believe these are not really new regressions. Tony and Lillian have been working on this package and much more seems to work, so these are probably latent bugs (see http://lists.gnu.org/archive/html/classpath-testresults/ for the current report). If they are not regressions then I will reset the autobuilder reports. Chris has been setting up XML test-suites which also show nice results (see http://builder.classpath.org/xml/) Cheers, Mark -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/ signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: gnu.xml.dom.DomText implements Text and NodeList.
Hi Pedro, On Tue, 2006-01-10 at 04:31 -0400, Pedro Izecksohn wrote: We ask that people agree to the GNU Classpath Hackers requirements before granting CVS commit permissions. You can find them at: http://www.gnu.org/software/classpath/docs/hacking.html#SEC2 I'm submiting source code to this list to be included in the GNU classpath project, assuring that I wrote this code and it is legally mine, accepting that it will be distributed under the GNU General Public License with the linking exception, and I'm donating this code to the Free Software Foundation. If I need to sign on paper, tell me from where may I download the model. Thanks. I'll sent you the request form by email in a second. It really should be a static inner class (since no state of the outer class is used). inner: Inside which one? DocumentType, ProcessingInstruction, Comment, Text, CDATASection and Notation have no children. As: DomCDATASection extends DomText, DomText extends DomCharacterData, DomComment extends DomCharacterData, it would be better to modify DomCharacterData. DomDoctype, DomNotation and DomProcessingInstruction seem (to the test case below) to be OK. May be a public class as below. Ah, right, I missed that it had to be done in several places. Having one (package private?) class seems the way to go. Sorry for not picking this up yet, I have been a bit busy with preparing for the next (0.20) snapshot release (and was secretly hoping Chris would pick this up since he is much more familiar with this part of the code). About the test case below: I could not imagine a better class name. It needs a XML with DTD that contain all the elements that it tests. I need to learn about Mauve. Most of Mauve is fairly simple. See http://sources.redhat.com/cgi-bin/cvsweb.cgi/~checkout~/mauve/README?cvsroot=mauve If you take one of the existing testlets as example you will see that it basically is replacing the main() method with a test() method and replacing the System.out and if statements with harness.check() statements. You can load a simple XML file with harness.getResourceFile(). // Resource names are // just like file names. They are relative to the top level Mauve // directory, but '#' characters are used in place of directory // separators. Cheers, Mark -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/ signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Assertion failure
Hi, On Tue, 2006-01-10 at 01:38 +0100, Christian Thalinger wrote: On Mon, 2006-01-09 at 18:02 -0600, Archie Cobbs wrote: FYI, Just testing current CVS with JCVM and I'm also getting this assertion failure: jc: mprec.c:100: _Jv_Balloc: Assertion `(1 k) 32' failed. This is on SuSE 10 on an x86 laptop (Dell Latitude D810). It's interesting that this also happens on 32-bit machines. See also: http://lists.gnu.org/archive/html/classpath-patches/2006-01/msg00141.html Hmmm. mprec originally came with fdlibm from libgcj and we regarded them as upstream, but they are now relying on us as upstream. It looks like the original mprec imported into libgcj actually through newlib (http://sourceware.org/newlib/) - notice that one maintainer! :) They do have an updated version of mprec.h and mprec.c at: http://sourceware.org/cgi-bin/cvsweb.cgi/src/newlib/libc/stdlib/?cvsroot=src Now we need a volunteer to merge our local changes back to that version and then import a new mprec. Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Assertion failure
On Tue, 2006-01-10 at 10:41 +0100, Mark Wielaard wrote: Hmmm. mprec originally came with fdlibm from libgcj and we regarded them as upstream, but they are now relying on us as upstream. It looks like the original mprec imported into libgcj actually through newlib (http://sourceware.org/newlib/) - notice that one maintainer! :) They do have an updated version of mprec.h and mprec.c at: http://sourceware.org/cgi-bin/cvsweb.cgi/src/newlib/libc/stdlib/?cvsroot=src Now we need a volunteer to merge our local changes back to that version and then import a new mprec. BTW, does anybody know why we are not using the system strtod() when available? That seems the way to the quickest solution on most platforms. It seems to work with some simple tests for me. But I notice that there is no strtod_r(), just strtod(). But I couldn't find a definitive answer on whether or not the standard strtod() is guaranteed to be thread-safe or not. Does anybody know (where to find this information)? Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Assertion failure
Hi, On Tue, 2006-01-10 at 10:17 +, Andrew Haley wrote: Christian Thalinger writes: On Mon, 2006-01-09 at 18:02 -0600, Archie Cobbs wrote: Just testing current CVS with JCVM and I'm also getting this assertion failure: jc: mprec.c:100: _Jv_Balloc: Assertion `(1 k) 32' failed. This is on SuSE 10 on an x86 laptop (Dell Latitude D810). It's interesting that this also happens on 32-bit machines. See also: http://lists.gnu.org/archive/html/classpath-patches/2006-01/msg00141.html Yes, but what is the value of k when this assertion fires? You can trigger it with the following (extracted from Mauve): new java.math.BigDecimal(1e200).floatValue(); Which gives: #4 0xad75ab88 in _Jv_Balloc (ptr=0xbfa7b7d4, k=5) at mprec.c:100 100 assert ((1 k) MAX_BIGNUM_WDS); Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Assertion failure
On Tue, 2006-01-10 at 11:49 +0100, Mark Wielaard wrote: BTW, does anybody know why we are not using the system strtod() when available? That seems the way to the quickest solution on most platforms. It seems to work with some simple tests for me. But I notice that there is no strtod_r(), just strtod(). But I couldn't find a definitive answer on whether or not the standard strtod() is guaranteed to be thread-safe or not. Does anybody know (where to find this information)? OK found that out myself. Apparently some strtod implementations are indeed not thread-safe by default (but most seem to be). The other problem is that strtod depends on the locale and changing the locale isn't thread-safe... sigh. So we do need our own implementation, or do something like glib g_ascii_strtod() and convert the string representation first to the current locale form (). Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Assertion failure
Hi Archie, On Tue, 2006-01-10 at 11:59 -0600, Archie Cobbs wrote: In any case, we probably need to fix this before 0.20, or at least disable the assertion (i.e., revert to the previous status quo). Agreed. I am still hoping someone has a good analysis of the issue, or wants to upgrade our mprec to the newlib version. If not we should indeed disable the assert again before 0.20 is released. Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
RE: SecurityManager troubles
Hi Jeroen, On Wed, 2006-01-11 at 08:45 +0100, Jeroen Frijters wrote: After fixing some IKVM specific bugs, I was able to run the testcase succesfully with only the attached GNU Classpath fix. That patch is obviously correct. Please do check this in even if other runtimes are still broken :) Thanks, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Some Mauve regressions builder missed
Hi all, Seems builder.classpath.org misses some regressions. builder can only accurately report when a PASS turns into a FAIL with the exact same message. It deliberately doesn't report new FAILs (since those could be from newly added tests). Since we sometimes use different messages when something PASSes and when something FAILs the auto-builder cannot currently detect those regressions. A special case are tests that crash a VM, then the message is replaced with CRASHED. Which is incorrectly interpreted as a new FAIL, but is obviously a regression. A workaround is to create a new test harness that ignores checkpoint names and PASS/FAIL messages. Such a harness should just use the test classname as message plus a counter. I'll implement that after 0.20. So here are the Mauve tests with regressions that builder missed: - gnu.testlet.java.math.BigDecimal.DiagBigDecimal This is the assert issue in mprec.c. - gnu.testlet.java.net.DatagramPacket.DatagramPacketOffset - gnu.testlet.java.net.DatagramPacket.DatagramPacketReceive - gnu.testlet.java.net.DatagramPacket.DatagramPacketReceive2 - gnu.testlet.java.net.DatagramSocket.DatagramSocketTest - gnu.testlet.java.net.DatagramSocket.DatagramSocketTest2 - gnu.testlet.java.net.InetAddress.getAllByName - gnu.testlet.java.net.MulticastSocket.MulticastSocketTest - gnu.testlet.java.net.ServerSocket.ServerSocketTest - gnu.testlet.java.net.Socket.SocketTest These are mostly the same issue (also an assert). I am working on a patch. - gnu.testlet.javax.swing.text.BoxView.spans I am unclear why the results changed between 0.19 an 0.20pre without the builder noticing. Maybe we accidentally reset the tester. Not investigated yet. - gnu.testlet.javax.swing.JTextField.createDefaultModel - gnu.testlet.javax.swing.JTextField.CopyPaste - gnu.testlet.javax.swing.BoxLayout.simplehorizontal - gnu.testlet.javax.swing.BoxLayout.simplevertical - gnu.testlet.javax.swing.AbstractButton.setRolloverEnabled - gnu.testlet.javax.swing.JEditorPane.ConstructorsAndTypes Not investigated yet. If people have time please do investigate the above Mauve tests so we can have a nice regression free release Friday. Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: RMI and java.rmi.server.hostname
Hi, On Wed, 2006-01-11 at 13:54 -0700, Tom Tromey wrote: I filed a PR: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25754 I would have linked to your message but, weirdly, it isn't in the list archives yet. The official archives are only updated every 12 hours (*). It is available as: http://lists.gnu.org/archive/html/classpath/2006-01/msg00098.html I added it to the PR. Cheers, Mark (*) If you need a quick link see Gmane: http://dir.gmane.org/gmane.comp.java.classpath.devel On that page there are also links to other (backup) archives. -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/ signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
RE: SecurityManager troubles
Hi Jeroen, On Fri, 2006-01-13 at 07:54 +0100, Jeroen Frijters wrote: I think I figured it out. With the attached test I could reproduce the problem on IKVM as well. The attach Classpath patch fixing things, although past 0.20 I think we should refactor the security properties like I did with the system properties (i.e. introduce a gnu.classpath.SecurityProperties class). Nice catch again. The use of VMStackWalker to see if the access is directly by one of the bootstrap classes is a bit nasty (and kind of breaks the model), so refactoring this would be nice. But please do check this in for now. As you can see in the test, there is still the incorrect charsetProvider permission being checked. I'm looking into that one as well. I guess this comes from having to register the default CharsetProvider in gnu.java.nio.charset.Provider.provider() this is wrapped in a AccessController.doPrivileged() since the constructor of java.nio.charset.spi.CharsetProvider does an explicit security check. Maybe we can again special case that security check by doing a this.getClass().getClassLoader() == null? Hmmm, no, that doesn't work since getClassLoader() will trigger a security check. Nasty... Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
RE: SecurityManager troubles (and the release)
On Fri, 2006-01-13 at 08:48 +0100, Mark Wielaard wrote: Maybe we can again special case that security check by doing a this.getClass().getClassLoader() == null? Hmmm, no, that doesn't work since getClassLoader() will trigger a security check. Nasty... I see you solved this by just doing an instanceof on the bootstrap providers. Much easier :) Thanks. With this issue out of the way and most of the tests giving green lights I am now going into release mode. Which just means I will do the following and then push out 0.20 unless someone screams hard enough :) - Do a last mauve run and some application testing. - Write the NEWS entries. - Set version number to 0.20. - Do a last make distcheck, generate documentation. - Tag the CVS tree (classpath-0_20-release) - Merge last changes from head to generics-branch. - Do a quick smoke test of generics (make distcheck, launch eclipse, write generic-hello-world, run it) - Tag the generics tree (generics-0_20-release) - upload to ftp://ftp.gnu.org/gnu/classpath/ - Write announcement - Announce! Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
tagged and ready
Hi hackers, The CVS tree has been tagged for both trunk and generics branch the final make distcheck is running and will be uploaded in a minute to ftp://ftp.gnu.org/gnu/classpath/ Official release announcement is in the works and will follow in a couple of hours. But please feel free to go crazy again adding lots of new coolness. Thanks all, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
ANN: GNU Classpath 0.20 released
, Completeness and Correctness checking. Various groups around GNU Classpath collaborate on the free software Mauve test suite which contains around 36.000 core library tests. Mauve has various modules for testing core class library implementations, byte code verifiers, source to byte code and native code compiler tests. Mauve also contains the Wonka visual test suite and the Jacks Compiler Killer Suite. See for more information: http://www.sourceware.org/mauve/ This release passes 35534 out of 36255 Mauve core library tests. Conformance reports for the included jaxp support can be found in the doc/README.jaxp file. GNU Classpath 0.20 can be downloaded from ftp://ftp.gnu.org/pub/gnu/classpath/ or one of the ftp.gnu.org mirrors http://www.gnu.org/order/ftp.html File: classpath-0.20.tar.gz MD5sum: 21e34b8e8acb4f7b31296bfaf4ad560a SHA1sum: c1a38c6c6b67d8c8092cc6af6d86d8c99dad272a File: classpath-0.20-generics.tar.gz (EXPERIMENTAL) MD5sum: db3c235b1ea497d7d2e5852f167d2b31 SHA1sum: 3d5f5cdd3dc51651f8b2c3765e30454931f45419 New in release 0.20 (Jan 13, 2006) (See the ChangeLog file for a full list of changes.) * New StAX pull parser and SAX-over-StAX driver. Lots of DOM, SAX/StAX, XPath and XSLT improvements. Support for XInclude and XML Base added. Conformance is now regularly tested against various test-suites at http://builder.classpath.org/xml/ See also doc/README.jaxp. * Full beans XMLEncoder implementation. * javax.sound.sampled implementation. * javax.print.attribute and javax.print.event implementated. * Lots of new datatransfer, print swing and swing.text work and optimization. * Additional 1.5 support. Including new (separate) generic branch release. * SecurityManager cleanups and start of review of all Permission checks (includes adding lots of new checks to the Mauve test-suite). * Buildable on cygwin. * Fully buildable as in-workspace library-plus-vm inside (native) Eclipse see http://developer.classpath.org/mediation/ClasspathHackingWithEclipse * Full example that shows a real world CORBA and Free Swing implementation. See examples/gnu/classpath/examples/CORBA/swing/README.html Runtime interface changes: * New method VMStackWalker.getClassLoader() was added to avoid an infinite loop between getCallingClassLoader() and Class.getClassLoader(). * The included fdlibm implementation has seen several cleanups to handle new architectures and namespacing issues (in particular for ppc, darwin and non-C99 compilers). Please double check any arithmetic test against new platforms/runtimes. * The gnu.java.net.Plain[Datagram]Socket implementations have been turned into VM reference classes with JNI/Posix implementations. New/Untested/Disabled Features: The following new features are included, but not ready for production yet. They are explicitly disabled and not supported. But if you want to help with the development of these new features we are interested in feedback. You will have to explicitly enable them to try them out (and they will most likely contain bugs). If you are interested in any of these then please join the mailing-list and follow development in CVS. * Cairo Gtk+ Graphics2D support, enabled by giving configure --enable-gtk-cairo. * QT4 AWT peers, enable by giving configure --enable-qt-peer. The following people helped with this release: Andreas Tobler Qt-4.1 support Andrew Haley Jar work and Jonas fixes Andrew John Hughes 1.5 generics language work Anthony Balkissoon Free Swing work Anthony Green Socket work Archie Cobbs New VMStackWalker work and JCVM integration Audrius Meskauskas Free CORBA work and various Free Swing fixes Bryce McKinlay Jar fixes Caolan McNamara Dom fixes and OpenOffice fixes Casey Marshall Crypto work Chris Burdess XML GNU JAXP work Christian Thalinger Various fixes, 64bit work and Cacao integration Dalibor Topic Build cleanups and Kaffe integration David Daney libgcj integration David Gilbert Free Swing work Freebeans Mysaifu Windows CE port and bug reports Fridjof Siebert Hashtable work Gary Benson Securitymanager and Permission work Guilhem Lavaux fdlibm cleanups, performance work and Kaffe integration Ingo Proetel Various fixes Ito Kazumitsu Regex, text and character conversion support Jan Roehrich Datatransfer work Jeroen Frijters SecurityManager, collections and IKVM integration Joao Victor Free Swing Timer work John Zigman SocketChannel testing Keith Seitz JDWP work Lillian Angel Free Swing work Mark Wielaard Bug fixes, packaging and release management Nicolas Geoffray 1.5 Class Instrumentation work Paul Jenner Installation and cygwin work Petteri Raty Configuration and Gentoo integration work Raif S. Naffah Security work and Eclipse integration Riccardo Mottola Powerpc work Robert Schuster XMLEncoder and beans work Roman Kennke Free Swing and AWT work, VM interface Roman Schnider AWT work Sven de Marothy Print and GTK+ work Thomas
Re: classpath-0.20.tar.gz and classpath-0.20-generics.tar.gz
Hi Nerdy Geeks, On Sun, 2006-01-15 at 06:07 +, nerdy geeks wrote: Both of the tarballs ftp://ftp.gnu.org/gnu/classpath/classpath-0.20.tar.gz ftp://ftp.gnu.org/gnu/classpath/classpath-0.20-generics.tar.gz appear to be flawed in the sense that there are several files of names matching *.java that are not contained in the directory tree archived in the tarball. From the order of elements listed by 'tar tvzf', it appears these files may belong in the subdirectory classpath-0.20/examples/gnu/classpath/examples/CORBA/SimpleCommunication/communication or its counterpart in the 2nd tarball, as these subdirectories are listed immediately before the files and would otherwise be empty as extracted from their respective tarballs. Maybe your tar version doesn't handle long path names? It seems to work for me: $ tar zxf classpath-0.20.tar.gz $ cd classpath-0.20/examples/ $ ls gnu/classpath/examples/CORBA/SimpleCommunication/communication DemoServant.java StructureToReturnHolder.java DemoTester.java TreeNode.java DirectTest.java TreeNodeHelper.java RequestTest.java TreeNodeHolder.java StructureToPass.java WeThrowThisException.java StructureToPassHelper.javaWeThrowThisExceptionHelper.java StructureToPassHolder.java_DemoTesterImplBase.java StructureToReturn.java_DemoTesterStub.java StructureToReturnHelper.java This is with tar (GNU tar) 1.15.1 Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Updating Mauve tags
Hi Roman, On Sat, 2006-01-14 at 22:33 +0100, Roman Kennke wrote: (BTW: This is a Mauve topic, I CC the classpath list because the mauve-discuss list seems so dead). Once upon a time there were lots of standard class library projects (kaffe, gcj, classpath) and we started cooperating by sharing a test suite. When most of these libraries merged together the test suite became a bit more the gnu classpath testsuite, but there are still independent users out there (although most of them are indeed pretty quiet - acunia used it for wonka, hp used it for chai, ibm used it for j9 and of course aicas uses it for jamaica, there are probably some others out there that never publicly announced their usage of the test suite.). I see that we have a concept of tags in Mauve. That is a collection of keys at the top of each test class. This way we can filter the tests. ATM we have tags for the JDK versions like JDK1.4 JDK1.3 and so on and a couple of other tags. However, it seems that they are not maintained in a usable way, so most people simply include every tag that they can think of (that is what's done in batch_run for example) to run all tests. Why do you feel they aren't maintained in a usable way? A test should mention the minimum version that it should work against. And can mention newer versions for which the tests isn't valid anymore (although I don't know of many examples of that). The README explains as follows: Tags must all appear on a single line beginning // Tags: . Many files test functionality that has existed since JDK1.0. The corresponding line in the source: // Tags: JDK1.0 Here is how you would tag something that first appeared in JDK1.2: // Tags: JDK1.2 Here is how you would tag something that was eliminated in JDK1.2: // Tags: JDK1.0 !JDK1.2 The idea behind this scheme is that it is undesirable to update all the files whenever we add a tag. So instead most tags are defined in terms of primitive tags, and then we note the exceptions. The reason the batch_run script lists all the tags is simply because it wants to run all the tests. I would like to fix the tagging of the tests with regard to the JDK versions. And since the current reference is JDK1.5, I would naturally start with this one. What I propose to do is run all the tests under JDK1.5 and set the JDK1.5 tag for all tests that pass there. For all tests that FAIL and have the JDK1.5 tag set, this tag would have to be removed. Later I would like to do the same for JDK1.4 and JDK1.3. (I have no JDK1.2 JDK1.1 or JDK1.0 available, otherwise I would probably do the same for these). It might be interesting to know what tests fail against which version of the reference implementation, but the reference implementation does have bugs, some of which aren't present in other implementations. Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: classpath-0.20.tar.gz and classpath-0.20-generics.tar.gz
On Sun, 2006-01-15 at 18:05 +0100, Mark Wielaard wrote: On Sun, 2006-01-15 at 06:07 +, nerdy geeks wrote: Both of the tarballs ftp://ftp.gnu.org/gnu/classpath/classpath-0.20.tar.gz ftp://ftp.gnu.org/gnu/classpath/classpath-0.20-generics.tar.gz appear to be flawed in the sense that there are several files of names matching *.java that are not contained in the directory tree archived in the tarball. [...] Maybe your tar version doesn't handle long path names? [works for me] with tar (GNU tar) 1.15.1 Just for the record. It seems an old GNU tar (1.11.2) was the problem. GNU tar 1.13.25 (and higher) are confirmed to work fine for the long path names. Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: a crazy idea -- the Book
Hi, On Sun, 2006-01-15 at 09:38 +0100, Meskauskas Audrius wrote: Great idea, I think! If this idea would move ahead, I am ready to join by writing sections about the javax.swing.text.html.parser, javax.rmi and org.omg. package groups. We maybe can divide chapters. I think, it would be good to have the printed book and not the web site content. I also think this is a great idea. We do have nice documentation for some parts of the standard library, but we don't have anything resembling a true manual for people just wishing to learn how to use all our stuff from scratch. There is the GCJ manual, but it is super light on details: http://gcc.gnu.org/onlinedocs/gcj Printing the book would probably require the initial money investment. This probably can be solved at least in the two ways: 1. The FSF pays for printing of this book and then gets the profit from selling it. There is GNU Press http://www.gnupress.org/ If there is someone willing to coordinate (anybody with technical writing experience?) the effort we should contact them and ask for help. Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Updating Mauve tags
Hi Roman, On Mon, 2006-01-16 at 00:59 +0100, Roman Kennke wrote: The problem that I am seeing is when a test that is written to PASS under 1.4 fails under 1.5. There are lots of those tests in the testsuite for the javax.swing package. To be honest, I would just remove those tests and concentrate on the 1.5 ones. So my plan would have been to tag all tests that pass under JDK1.5 with the 1.5 tag and those that don't only with JDK1.4 or whatever is ok. Since the tags are not meant to be used that way, maybe we can do it different. Could we extend the choose-classes script to detect !JDK1.x tags in the tag header of java source files and don't include the test in a JDK1.x test run? I always thought it already worked that way (see the README), so if it doesn't and you can make it actually do that then that would be great. Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Fosdem discussions (Was: Importing GNU Classpath 0.20)
Hi (CC classpath list), In response to the importing of 0.20 into GCC, Tom, Jeroen and I had the following small exchange: On Wed, 2006-01-18 at 08:26 +0100, Jeroen Frijters wrote: Mark Wielaard wrote: On Tue, 2006-01-17 at 09:32 -0700, Tom Tromey wrote: Mark == Mark Wielaard [EMAIL PROTECTED] writes: Mark But libgcj doesn't have a proper VMStackWalker class Mark so we cannot use those (this seems the thing that leads Mark to most of the libgcj/classpath divergence btw). Yeah... a while back Jeroen and I talked briefly about this, but we forgot to get back to it. I wish I could help here, but my own suggestion of having a class parameter for VMStackWalker.getCallingX() was rejected and I don't know of an easy and reliable way to implement it without that. Maybe we will be able to work something out during Fosdem? This is one of the topics that I would like to discuss during the last part of our Fosdem meeting (Feb 25/26, Brussels): http://www.gnu.org/software/classpath/events/fosdem06.html Sunday from 14:00 to 17:30 - The Future Interactive technical hacker discussions on how to integrate the projects more and move forward in the next year. State of the world, beyond japi Mark Wielaard, GNU Classpath Maintainer After a short overview of the various free stacks, libraries, compilers, tools and runtimes this session is mostly open discussion about what work remains to be done and how to integrate the various efforts better. Ideas for work items welcome. The extra work items I have now are: - Who is working on what? Quick round where everybody tells what their personal, group, organization/company work items are for the immediate and long term future/next year. - Deployment: distribution and packaging for GNU/Linux distros. Fedora just went through a round of, what looked from the outside a bit painful, process of deploying lots of new packages based on GNU Classpath and gcj for FC5. Debian is currently adding a lot of packages (moving from contrib to main). Since both Debian and Fedora hackers are attending it would be good to exchange success and failure stories. Where can we as upstream help making deployment easier? - VM integration and interfacing. There have been a couple of additions and changes this year (net/socket, instrumentation) and cleanups like the VMStackWalker. Also kaffe has moved much more closer to using GNU Classpath out of the box. But both gcj and kaffe still maintain divergences. I will go over the vm integration guide (and make sure it is up to date) and ask whether or not what we currently have makes sense. Ideas for more things to discuss are of course welcome. As are spontaneous monologues on what people think is important to concentrate on for the next year. Cheers, Mark -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/ signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Classpath 0.20 successfully built with Cygwin
Hi Enrico, On Thu, 2006-01-19 at 16:55 +0100, Enrico Migliore wrote: P.S. During the build phase gcc generates some C and some Java warnings, we might want remove in the future Patches for the C java warnings would be very welcome, indeed. If you've got some time to look over the warning for the obvious simple fixes, please put them in the bug tracker. I'll redirect the make output on a text file in order for me to look over the warnings and I'll let you know what kind of warning the compiler issues. Thanks a lot for doing this. Note that we try to have warning free compiles (at least the C source on GNU/Linux, unfortunately the java source cannot be 100% warning free). If you configure with --enable-Werror the compilation of that native C source will stop on the first warning message. If other people could report any issues on non-standard platforms with --enable-Werror that would be appreciated since a compile warning often points out some subtle issue. Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Classpath 0.20 successfully built with Cygwin
Hi Christian, On Thu, 2006-01-19 at 18:46 +0100, Christian Thalinger wrote: Cool! But have problems with jikes: /home/twisti/bin/jikes +Pno-switchcheck +Pno-shadow +F -bootclasspath '' -extdirs '' -sourcepath '' -classpath ../vm/reference:..:../external/w3c_dom:../external/sax:.: -d . @classes Found 1 system error and issued 1 warning: *** Semantic Warning: The file ../vm/reference:..:../external/w3c_dom:../external/sax:.: is not a valid directory. Which jikes is this? I assume there are 2 versions of jikes a pure cygwin version (that would know about using : as path separator) and a dos version (that thinks ; is the path separator). Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Win CE port
Hi Phillipe, On Fri, 2006-01-20 at 15:03 +0100, Philippe Laporte wrote: It is our understanding that a GPL VM can't be freely redistributed in a commercial product. There should be no trouble at all freely redistributing such a thing in a commercial product. Just make sure you distribute the source code for it to your users. See http://www.fsf.org/licensing/essays/selling.html And if you have more questions on the use of GPL covered products please feel free to contact [EMAIL PROTECTED], they even provide a complaince lab service for commercial entities. See http://www.fsf.org/licensing/compliancelab.html Cheers, Mark -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/ signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Moving classpath mailinglists
Hi all, Since email to the lists still can take hours from time to time we have decided to temporarily move some lists to developer.classpath.org till the new GNU mailing-list server is online (hopefully in a month). For now we only move the main classpath and classpath-patches lists since these are the most interactive. If we setup everything correctly you shouldn't notice much of this move. The address you sent and (seem to) receive email from is still [EMAIL PROTECTED], it just get routed through our own developer.classpath.org machine (mailman administration and archives will also move there for now). We hope to do the actual move at the end of the/my day (19:00 CET == 18:00 UTC == 1:00 PM Boston). I'll sent another email when the move is done. It should all be very transparent, so please feel free keep sending emails in the meantime to the lists. If you have any trouble after the move please contact me (or Jim, Tom and Michael who also help administration of the developer.classpath.org machine). Cheers, Mark P.S. lists.gnu.org seems to have been listed in spamcop again for a brief time (please don't use this RBL it seems very bogus) and we seem to get a lot of bounces at the moment and automatic unsubscribes by mailman because of this. I have a list of subscribers just before this seemed to have happened so I will reinstate all subscriptions during the move. signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Aicas again
Hi, On Tue, 2006-01-24 at 10:53 +0100, Roman Kennke wrote: But in general, I do not appreciate what Aicas has been doing nor do I find it valuable. All I see this work doing is making Classpath's native implementation of things less and less maintainable, with a benefit that is utterly unclear to me. I vote that they stop changing the native libraries of Classpath immediately, Aye. We will do so. Please feel free to revert the native code to the state of the 0.20 release. I and Aicas really don't want to discuss all this again. This was an attempt to improve the situation a bit by providing the posix layer, which was worked out with respect to suggestions that were made in the last discussion about that one year ago. All this costs a *lot* of time and if that is not valuable to Classpath we can plug ourselves out and do our thing on the VM interface level. BTW, I do see a benefit for non-posix-like systems. And I would very much like to have something next to a clean autoconfiscated reference implementation (for Posix like systems, GNU/Linux, Solaris, Darwin, *BSD, cygwin, etc). There main trouble I see is that you try to represent the posix layer as another target-layer and that means a lot of ugliness for no apparent benefit. If there was a good way to put the target-layer next to the autoconfiscated/posix-layer that would be my ideal solution. And I think with our VM-interface-classes that should not be too hard. Another reason for the somewhat hostile reception of some of the new code is because you are really too sloppy testing your patches, it takes people real time and energy to get their systems working again after you changed things. You should try to never break a working setup of one of the active hackers. At least ask whether people can try changes if you are unsure it might break on someones system. Mistakes happen, and we cannot support every configuration flawlessly all the time, but the main platforms (GNU/Linux, *BSD, Darwin, etc) should keep working. Please do try a little harder to not accidentally breaking other peoples setup and I think people will be a lot more receptive to your changes. Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: Win CE port
Hi Philippe, On Tue, 2006-01-24 at 13:31 +0100, Philippe Laporte wrote: Thanks for the answers. Yes, I mean rather Java VMs as seen as belonging to seperate categories according to their licensing requirements. Yet, the information you provide seems to be in contraditction somewhat with what they have at http://sablevm.org/wiki/License_FAQ As said before GNU Classpath itself doesn't come with a runtime at this time. GNU does provide one through GCC (libgcj/gij) and that one comes under the same distribution terms as GNU Classpath itself (GPL + Exception). If you have legal questions about that then please do contact [EMAIL PROTECTED] since this really is the technical mailing-list. If you have questions about non-GNU, GPL-covered runtimes then it is best to contact the copyright holders of those runtimes to ask for their opinions. (BTW. Random pages on the interweb explaining the policies of some rival runtime are not the most reliable information source...) Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Moving the mailinglists
First post! We are currently moving the mailinglists to developer.classpath.org. In a moment we will switch the main address classpath@gnu.org to this new machine. Please keep using the old address (classpath@gnu.org), it will work and as soon as the new FSF GNU mailing-list server is operational we will want to switch back. Apologies to those of you who had digest subscriptions, they have automagically been turned into normal subscriptions. Please see the mailman pages to change your preferences: http://developer.classpath.org/mailman/listinfo/classpath Now going to pull the switch on the old address/list. Keep your fingers crossed. classpath-patches will also move in a moment. Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://developer.classpath.org/mailman/listinfo/classpath
Re: Classpath and java.util.concurrent
Hi Tom, On Tue, 2006-01-24 at 11:15 -0700, Tom Tromey wrote: One idea would be to check it in on a pristine branch (like cvs import, but we probably don't want to use that in this case) and then merge it over the generics branch and clean it up there. I would suggest putting the code in external/, e.g., external/jsr166. I think it would make sense to import it and get it on the branch before hooking it into the build. That way, fixing it up to work in Classpath won't have to be a solo effort. Comments? Seems like a nice plan. But please put down precisely how/where the pristine branch comes from and how you sanitize it to only include the public domain bits from the jsr166 group. Then we sent that description to FSF-legal and to Doug so we have a clear record where the original source comes from. And we should probably also send it to Doug so the jsr166 group knows how their users/downstream depend on their work (it is probably a similar process the backport project goes through http://www.mathcs.emory.edu/dcl/util/backport-util-concurrent/). It would also be good to then have a simple way/description of how to get a diff between this pristine branch and what what we will have in external/jsr166 so it is easy to forward any patches upstream again. Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list Classpath@gnu.org http://developer.classpath.org/mailman/listinfo/classpath
Re: Moving classpath mailinglists
Hi Norman, On Fri, 2006-01-27 at 08:59 +0100, Norman Hendrich wrote: it seems that the mailing list archives for classpath and -patches are not updated anymore since moving the lists. http://lists.gnu.org/archive/html/classpath/ stops at 2006.01.24. Is there another location to access the archives? Yes there is: http://developer.classpath.org/pipermail/classpath/ http://developer.classpath.org/pipermail/classpath-patches/ I hope that we won't have the lists moved for too long and that when the new FSF gnu-list-server comes online we will move the archives back. There are also backup archives at: http://dir.gmane.org/gmane.comp.java.classpath.devel http://dir.gmane.org/gmane.comp.java.classpath.patches http://www.mail-archive.com/classpath@gnu.org/ http://www.mail-archive.com/classpath-patches@gnu.org/ http://www.nabble.com/Gnu---Classpath-f1524.html Cheers, Mark signature.asc Description: This is a digitally signed message part
Re: New native layer
Hi, On Sat, 2006-01-28 at 17:02 -0800, Casey Marshall wrote: On Jan 28, 2006, at 7:21 AM, Guilhem Lavaux wrote: I thought to have been already clear about that in the past (and with no answers !). Sorry, I meant to reply about what you were proposing, but forgot :-) Yeah, sorry. We all need little reminders from time to time. But showing up with real code does help getting replies :) What you're working on seems a bit better than the target layer stuff, in that you have real functions that the compiler/debugger can tell you about, if there's an error. Agreed, it is definitely better then what we have now with the macros. I don't, however, entirely see the point of another funcall to wrap the syscalls in. It seems to me as though efforts like this are trying to re-use the bits of JNI code that wrap syscalls in the native parts of VM* classes, and not much else. I do see some value because it makes it clear where the JNI part ends and where the platform specific part starts. But I am not sure putting all platform specific parts in separate files is always an improvement since most of it is actually pretty small and most of it seems not to be that different between platforms. Adding separate functions for things that might be different or that need VM specific hooks/callbacks is good though. I would just hate to see it overdone for small things that could just as well be in the same file or even function. In my opinion, time would be better spent: - Writing utility functions that make JNI easier to deal with. That is what JCL and NSA were for (native/jni/classpath). They were supposed to be safe wrappers for some common things like throwing exceptions, conversion of jstrings and cstrings and generic RawData support that hides whether the platform is 32 or 64 bits. But those functions were never really worked out much, nor are they used very consistently in all our JNI code at the moment. - Writing concise, portable (in the realm of POSIXy systems, at least) native implementations of VM* classes that require native support. Through autoconf and replacement functions where needed. That is how libgcj (and kaffe) do it. * if we want something which is quite portable (but maybe not as portable as aicas portability layer) we must ensure some level of abstraction to hide how syscalls are really used. That way if we have to call different things in the OS (e.g. for more exotic platforms like windows) or to use the syscalls differently we will not be completely stuck by tons of autoconf code in the common VM layer. It seems like a lot of the argument for this kind of native layer is we can port to Windows/some exotic platform, but frankly, I don't see it. Windows (in my uninformed opinion ;-) is probably wildly different enough such that writing a win32 `cpio_read' isn't much less work than writing a win32 `Java_gnu_java_nio_channels_FileChannelImpl_read__.' And since any port like this is (AFAIK) merely hypothetical, I don't see the value. libgcj has a somewhat separate Windows implementation of some platform native code (see the nat*Win32.cc files in gnu/java/nio, gnu/java/net, java/lang and java/net in gcc/libjava). And they also support cygwin and mingw to a point (although I don't know whether the Posix or Win32 native implementation is used by either the cygwin or mingw target). All this can/should of course be wrapped behind our VMClass interface layer since that also helps making our library JNI/CNI/.NET/Oberon/etc agnostic. I don't mind this proposal, and I think you should go ahead with it. I still have my own opinions about how to write Classpath's native library, so I may try my own experiment in another branch (unless, of course, no-one really agrees with me, in which case I will just stop critiquing other people's code). I think I agree with Casey. Please go ahead with your work Guilhem. We will try to be constructive in our criticism. Actually doing the work and providing patches is a very good way to proof your point that this is needed and makes things cleaner. Thanks for working on this. Cheers, Mark signature.asc Description: This is a digitally signed message part
Re: Missing doPrivileged() in VMProcess?
On Fri, 2006-01-27 at 13:50 +, Gary Benson wrote:
Andrew Haley wrote:
Gary Benson writes:
Hi all,
Each time you execute a file with Runtime.exec() a VMProcess
is created. The first time one of these is created it creates
a thread and calls its setDaemon() method which (eventually)
checks RuntimePermission(modifyThread).
I guess there should be a doPrivileged() in here somewhere, but
where?
I guess I don't understand the real problem. Would it not make
sense simply to wrap the
if (processThread == null)
{
processThread = new ProcessThread();
processThread.setDaemon(true);
processThread.start();
}
in a doPrivileged ?
That's where I was thinking. Is there (or should there be) something
that protects these VM* classes from being used by non-Classpath code?
And that seems indeed the right place to add the doPriviliged() block.
VM* classes are protected from being used directly by non-Classpath
code because they are package private. They should only be called after
the public (non-VM) code has done the appropriate runtime checks. If
that is done correctly then any (reference) code in the VMClass that
needs any other permissions (like in this case) needs to do that inside
a PrivilegedAction.
Cheers,
Mark
signature.asc
Description: This is a digitally signed message part
Re: Crypto/Security component in Bugzilla
Hi Casey, On Wed, 2006-02-01 at 13:00 -0800, Casey Marshall wrote: It's just that crypto/ssl is a large part of Classpath now, so it makes sense that it have it's own component (and bugs!). You got it! There is a new 'crypto' component for the 'classpath' product now with you as default owner. But feel free to reassign any bugs reported against it to others after initial analysis. And maybe a security keyword that describes direct security issues? For security right now we have a meta-bug which depends on all the security issues -- PR 13603. This is a bit weird since this predates classpath using bugzilla, and is filed against gcj. I don't know the pros and cons of meta-bugs versus keywords. I'm fine with whatever works. Maybe Andrew (one of the gcc bug-masters) can advise us on when to add a new keyword and when to use meta-bugs. How do other projects handle security issues/bug reports in their issue trackers? Cheers, Mark signature.asc Description: This is a digitally signed message part
Re: Crypto/Security component in Bugzilla
On Wed, 2006-02-01 at 20:01 -0500, Andrew Pinski wrote: On Feb 1, 2006, at 7:52 PM, Tom Tromey wrote: I thought this question was more about security in the sense of bugs we know of in our security code, not security flaws requiring a quick turnaround. Likewise. After reading Casey's email that Mark responded to. In that case it seems we don't need a keyword or meta-bug but just a new 'security' component covering java.security.* (Permissions, Policies, SecurityManager)? Cheers, Mark signature.asc Description: This is a digitally signed message part
Re: GNU classpath contribution question
Hi Ken, On Wed, 2006-02-01 at 16:09 -0500, Ken Larson wrote: System.out.println(FileFormat.BINARY) and run it against Sun's implementation. I find out that the value is 1, and I put that in my implementation. Is this legit for the purposes of contribuing to classpath? Normally public constants are listed in the public documentation. Otherwise you can look them up in the O'Reilly or Addison-Wesley books. Checking constants to make sure different implementations use the same public interface is fine. In general public user visible constants like this should be similar to make us more compatible with other implementations (especially since constants are embedded into the .class file when compiling sources) so programs work as is with our implementation. You can also add a Mauve test to make sure we stay compatible. Cheers, Mark signature.asc Description: This is a digitally signed message part
GNU Classpath and Friends Fosdem meeting (Feb 25/26, Brussels)
Hi all, The official program is ready and there is a wiki page for coordinating the meeting at http://developer.classpath.org/mediation/Fosdem2006 Please add yourself if you will come and please do make suggestions for the open sessions. The full schedule is: Saturday 13:10 - 13:50 - Putting the 'Free' into JFreeChart Dave Gilbert, JFreeChart Project Leader A review of the efforts to make JFreeChart work with GNU Classpath-based runtimes, including a brief history, a demonstration of the current state (using the java bindings for Cairo), and an overview of the work that remains to be done. Saturday 14:10 - 14:50 - Using Eclipse for GNU Classpath development Tom Tromey, GCJ Hacker Learn how to setup a fully working development environment based on GNU Classpath in Eclipse that can be used to bootstrap the full free toolchain (and can be used to run Eclipse itself) in just 10 minutes. Saturday 15:00 - till we are kicked out - Show your App/Hack your App! - Open Session Open session for everybody wanting to show their applications working on a free stack and for those people wanting to help out getting more applications to work out of the box. Sunday 09:10 - 09:50 - Free Swing, past, present and future Roman Kennke, GNU Classpath Hacker An overview of that state of Free Swing one year ago, what has been done in the meantime, what still must be done and which applications work now. Sunday 10:10 - 10:50 - The Free implementation of CORBA standard Dr Audrius Meskauskas, GNU Classpath Hacker Some famous software producers criticize the Free software for the insufficient support of interoperability between applications. The CORBA standard, proposed by the Object Management Group, belongs to the most popular and widely used standards for solving the task of the interoperable (cross language and cross platform) communications. The formal/04-03-12, where the standard is described, allows to implement and use it without restrictions. For our CORBA implementation we needed: 1. Free, without classes with restricted license. 2. Fully workable, interoperable and pass tests, recognized by the CORBA user community as serious (we needed to find a well known Free testing suite). 3. Properly commented, being ready for the long life in the Free world. 4. No pressure to use the outdated approaches. CORBA 3.0.3 and jdk 1.5. 5. The trademark - neutral abbreviation for naming the Free applications that use this package. The abbreviation GIOP is suggested, as it is not a registered mark. To reach these goals, we have chosen for implementing a clean room implementation, using the published standard specifications only. During the recent year of the GNU Classpath development, this goal is in large degree achieved. The important directions of future development could be providing features that are outside the scope of the both CORBA standard and Sun API, but included in the near all proprietary implementations (SSH, HTTP and other bridges, get rid of rmic code generator for RMI/IIOP, fault tolerant behavior, reduced the footprint and others). Sunday 11:10 - 11:50 - The JamVM runtime Robert Lougher, JamVM Designer An overview of the JamVM virtual machine, with comparisons to other GNU Classpath runtimes, and a section on the VM interface. Sunday 12:10 - 12:50 - Integrating Vmgen-based interpreters Christian Thalinger, CACAO Hacker Vmgen is a tool for writing efficient interpreters. The Cacao runtime recently added a Vmgen based interpreter in addition to the JIT engine. Christian Thalinger works at the Institute of Computer Languages at the Vienna University of Technology in the Christian Doppler Laboratory: Compilation Techniques for Embedded Processors. He is working on the CACAO Java Virtual Machine, currently working on an adaptive optimizations JIT, and is writing his Ph.D. thesis. Sunday 14:00 - till we are kicked out - The Future - State of the world, beyond japi Mark Wielaard, GNU Classpath Maintainer - Open Session After a short overview of the various free stacks, libraries, compilers, tools and runtimes this session is mostly open discussion about what work remains to be done and how to integrate the various efforts better. Ideas for work items welcome. - Who is working on what? - Deployment: distribution and packaging for GNU/Linux distros. - VM integration and interfacing. - Priority list for new development. There is one change from the earlier schedule. Unfortunately Wayne Beaton had a conflicting presentation at the other side of the planet and couldn't make it. If you do want to meet him, but couldn't come to Brussels then you can see him in Raleigh/Durham: https://www.regonline.com
