Re: I wish to help
Tom Tromey <[EMAIL PROTECTED]> writes: > I think as with any merge, something like this must be done > class-by-class with careful attention paid to preserving the benefits > of both implementations. A merge of the software remains impossible in this manner. If there are useful parts that might be treated as an external library then this is the most likely route for this project; I'm mainly thinking of things that are like our GTK peers, providing other functionality like framebuffer support. > Also, I think it is very important that native widgets be used in some > situations. For instance, it's hard to picture running a native Linux > AWT on anything other than Gtk or Qt. Writing a new toolkit is really > out of the question. Native peers are required. -- Brian Jones <[EMAIL PROTECTED]> ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: I wish to help
Mark Wielaard <[EMAIL PROTECTED]> writes: > On Wed, 2002-10-30 at 01:23, Brian Jones wrote: > > Mark Wielaard <[EMAIL PROTECTED]> writes: > > > > > Chris Gray said that they wanted to relicense it if needed but I > > > don't know if they are actually going to donate it to the FSF for > > > inclusion in the GNU Classpath project. Note however that Rudolph is > > > not a peer based implementation. > > > > I'm trying to get something definite from Chris right now. > > Thanks for following up on that! It would be very nice to work more > closely with the Wonka people. > > > Opinions? > > With respect to licensing/copyright it would be best IMHO to get > everything assigned to the FSF as we have done with all other > contributors. That is not a possibility at this time. You can imagine that they would like fixes assigned back to them so they can use them under any license they choose which also won't sit well with some of our contributors. > Also take into account that Wonka contains only the java.awt, > java.awt.event and java.awt.image packages. We have that and > java.awt.color, java.awt.datatransfer, java.awt.dnd, java.awt.dnd.peer, > java.awt.font, java.awt.geom, java.awt.im, java.awt.im.spi, > java.awt.image.renderable, java.awt.peer and java.awt.print. The > important advantage that Rudolph has is of course that the code that > they have actually works! I haven't checked on class level btw. > (More info can be found on http://wonka.acunia.com/javadoc-0.9.3/) > > A small thing, but important to me, is the fact that we have much better > documentation (apidoc) then the Wonka implementation. I know that RMS > finds it important to have good documentation for GNU programs so you > might want to bring up this point (certainly because it is a complicated > matter since the documentation is embedded into the source files). So I'm pretty much of the opinion that Classpath's AWT just needs a little TLC from someone dedicated to it for a while to make it useable. Having JVMs without major threading issues will aid this development. This is why I would personally develop the peers against Sun's VM, if I had the time to devote to it. Acunia has almost officially made this offer, but because it would be unlikely for me to get contributors to assign their copyright on changes back to this corporation that may not be so benevolent in the future (no guarantees) I'm inclined to believe we must continue working on the current implementation. It remains a possibility that if Acunia's current AWT is dual licensed in the manner Chris described that parts of this work could be integrated as an external library to provide optional functionality in Classpath's AWT. So inspection of their implementation would be possible but no verbatim copying allowed into _our_ classes. We could create a separate directory to place their library with an appropriate README indicating this is not part of Classpath and when we compile we could link this library without trouble. I hope this explains what is meant by external library in reference to FSF projects. Brian -- Brian Jones <[EMAIL PROTECTED]> ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: RMI update
Mark Wielaard <[EMAIL PROTECTED]> writes: > I also had to tweak some imports a bit and add some stub classes since > we don't have the org.omg classes yet (look for XXX in the code). Brian, > you where in discussion about those classes. What is the status? I sent email off into a blackhole at OMG, apparently I sent email to the wrong person. I'll take a look again and try to find someone there that will respond. Brian -- Brian Jones <[EMAIL PROTECTED]> ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: commit-classpath [was: FYI: java.util.logging]
> "Sascha" == Sascha Brawer <[EMAIL PROTECTED]> writes: Sascha> % cat java/util/logging/CVS/R* Sascha> /cvsroot/classpath//classpath/java/util/logging It is possible the `//' in the above causes the problem. The Classpath CVSROOT compares against the regexp `^classpath'. If you change the `//' to `/' in all the CVS/Repository files, you could try a dummy commit (cvs commit -f) of some file to see that fixes the problem. Tom ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: FYI: java.util.logging
On Thu, 2002-10-31 at 16:44, Brian Jones wrote: > Mark Wielaard <[EMAIL PROTECTED]> writes: > > > BTW. Do you know why your commits do not appear on the commit-classpath > > mailinglist? http://mail.gnu.org/pipermail/commit-classpath/ > > I'm trying to figure this out too. Doesn't appear to be a setting > issue on the list itself. Wasn't the last time this happened something wrong with the accounts on the CVS server? People with or without an actual (cvs) account on the machine didn't show up on the mailing list properly. But maybe that had to do with our move to Savannah at the time. Cheers, Mark ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: I wish to help
Hi, On Thu, 2002-10-31 at 14:32, Andy Walter wrote: > On Thursday 31 October 2002 12:15, Mark Wielaard wrote: > > Has someone actually tried Rudolph with GNU Classpath? > > Yes, it is running quite well here. But we replaced many native methods (all > but 5) by Java code. Since Rudolph uses a proprietary interface, this > replacement might be interesting for classpath. On the downside, our > implementation diverged from Rudolph. Nice. Do you use any of the non-rudolph java.awt.* packages/classes? We will probably have to merge a lot between the GNU Classpath implementations and the Rudolph implementations anyhow when we decide to import it. So that might be the ideal time to work away the diverged classes. > > Also take into account that Wonka contains only the java.awt, > > java.awt.event and java.awt.image packages. We have that and > > java.awt.color, java.awt.datatransfer, java.awt.dnd, java.awt.dnd.peer, > > java.awt.font, java.awt.geom, java.awt.im, java.awt.im.spi, > > java.awt.image.renderable, java.awt.peer and java.awt.print. The > > important advantage that Rudolph has is of course that the code that > > they have actually works! > > Not only that but it also doesn't depend on GTK. I don't know if I would count that as an important advantage :) Having AWT classes based on GTK peers seems like a very good idea for any GNU/Linux based system since it will give a more common look when used on the desktop. > I think it would be great to > separate the top level graphics stuff from the low level peer classes by a > common, well-defined interface. That way had three sets of peer classes > (GTK-based, acunia framebuffer, jni framebuffer), but only one common set of > top level classes, which are probably much more (I have to admit that > personally, I don't have to do much with graphics). > > I expect that the sooner we agree on such a common layer, the fewer redundant > work there is on the top level. Yes, that would be a great plan. I am glad that Jeffrey stepped in just at this time so that we now have someone with GTK+ experience that help define the correct interface. What do you think about the current java.awt.peer classes that we have. Are they general/flexible enough? > > And please make sure that all arrangements between Acunia and the FSF > > are made clear and public. The last deal that was done with respect to > > the AWT code (with Transvirtual) was never communicated clearly and that > > produced some tensions. (I am perfectly happy to let RMS try to get a > > deal that is in the best interest of all free software users as long as > > it is clear in the end what has been decided.) > > RMS for sure is the right person to do this. I had expected all agreements of > the FSF to be made public and am surprised to read this wasn't the case with > Transvirtual. It was actually meant to be public knowledge. But at the time not everybody was informed clearly of why and what decision was made. I don't think that was very deliberate. Although the fact that not everybody agreed with the decision was probably part of the reason that it was not clearly communicated. (Read the archives if you are interested in the details. At the time it felt important, but it is not really relevant anymore. And I changed my opinion a bit since that time.) Cheers, Mark ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: FYI: java.util.logging
Mark Wielaard <[EMAIL PROTECTED]> wrote on Thu, 31 Oct 2002 13:30:55 +0100: >In the past you said that you thought that java.util.logging is still >alpha quality code which is one of the reasons it is not yet included >into libgcj. How do you feel about the code quality now? The package now should be quite usable, IMHO. It behaves very similar to the Sun implementation, with some documented exceptions (for example, the Classpath implementation escapes non-ASCII characters in XML log files, while Sun J2SE 1.4 apparently does not, which can cause XML files to be ill-formed). Remaining problem areas: 1. serialization: should be compatible with Sun, but I haven't verified this yet 2. localization: Classpath currently does not emit localized log records 3. Javadoc is still incomplete 4. java.util.logging.FileHandler does not switch over to a new log file when the maximum size is reached I'll fix these soon. Apart from these, I think the code should now be ready for general use. -- Sascha ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: I wish to help
> "Mark" == Mark Wielaard <[EMAIL PROTECTED]> writes: Mark> Also take into account that Wonka contains only the java.awt, Mark> java.awt.event and java.awt.image packages. We have that and Mark> java.awt.color, java.awt.datatransfer, java.awt.dnd, java.awt.dnd.peer, Mark> java.awt.font, java.awt.geom, java.awt.im, java.awt.im.spi, Mark> java.awt.image.renderable, java.awt.peer and java.awt.print. I think as with any merge, something like this must be done class-by-class with careful attention paid to preserving the benefits of both implementations. Also, I think it is very important that native widgets be used in some situations. For instance, it's hard to picture running a native Linux AWT on anything other than Gtk or Qt. Writing a new toolkit is really out of the question. Tom ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
commit-classpath [was: FYI: java.util.logging]
> BTW. Do you know why your commits do not appear on the commit-classpath > mailinglist? http://mail.gnu.org/pipermail/commit-classpath/ I'm sorry, but I have no idea about this. Brian> I'm trying to figure this out too. Doesn't appear to be a setting Brian> issue on the list itself. Tom Tromey <[EMAIL PROTECTED]> wrote on Thu, 31 Oct 2002 11:11:49 -0700: >I've seen this happen in cases where the regexps in CVSROOT fail to >match. Sascha, could you `cat CVS/R*' from one of your classpath >directories? Maybe that will have some useful information. % cat java/util/logging/CVS/R* /cvsroot/classpath//classpath/java/util/logging [EMAIL PROTECTED]:/cvsroot/classpath I hope this helps... -- Sascha ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: I wish to help
> "Andy" == Andy Walter <[EMAIL PROTECTED]> writes: Andy> Not only that but it also doesn't depend on GTK. I think it Andy> would be great to separate the top level graphics stuff from the Andy> low level peer classes by a common, well-defined interface. Andy> I expect that the sooner we agree on such a common layer, the Andy> fewer redundant work there is on the top level. Does this need anything more than the peer interfaces already in java.awt.peer? Those aren't really well-defined, but we can define them as need be. The approach I've been taking on those occasions when I do AWT hacking is to simply assume that we won't try to be compatible with Sun's AWT peers. So I just change the peer code to suit the needs I perceive. Tom ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
RMI update
Hi, The Orp RMI patches have been merged. I added copyright notices and made the new files use the GNU code style. But most documentation is still missing. I tried to create meaningful ChangeLog entries, but I don't pretend to understand everything of it. I have not tried it. It compiles. If it breaks anybodies setup I will be happy to revert the patch. But I will be unable to fix it most likely. Any volunteers for testing this? I also had to tweak some imports a bit and add some stub classes since we don't have the org.omg classes yet (look for XXX in the code). Brian, you where in discussion about those classes. What is the status? 2002-10-31 Mark Wielaard <[EMAIL PROTECTED]>: Merge Orp RMI patches from Wu Gansha <[EMAIL PROTECTED]> * configure.in (AC_OUTPUT): Add javax/rmi/Makefile, gnu/javax/rmi/Makefile, javax/rmi/CORBA/Makefile and gnu/javax/rmi/CORBA/Makefile. * javax/.cvsignore: New File. * javax/Makefile.am (SUBDIRS): Add rmi. * javax/rmi/.cvsignore: New File. * javax/rmi/Makefile.am: New file. * javax/rmi/CORBA/.cvsignore: New file. * javax/rmi/CORBA/Makefile.am: New file. * gnu/Makefile.am (SUBDIRS): Add javax. * gnu/javax/.cvsignore: New file. * gnu/javax/Makefile.am: New file. * gnu/javax/rmi/.cvsignore: New file. * gnu/javax/rmi/Makefile.am: New file. * gnu/javax/rmi/CORBA/.cvsignore: New file. * gnu/javax/rmi/CORBA/Makefile.am: New file. * java/rmi/MarshalledObject.java (equals): Check hashcode first. * java/rmi/server/RMIClassLoader.java (MyClassLoader): Create/Use annotation. (loadClass): Take String as codebases. (getClassAnnotation): Use MyClassLoader annotations. * java/rmi/server/UnicastRemoteObject.java (UnicastRemoteObject): call exportObject(this). * gnu/java/rmi/RMIMarshalledObjectOutputStream.java (RMIMarshalledObjectOutputStream): set locBytesStream and locStream. (setAnnotation): Don't set locBytesStream and locStream. (replaceObject): Removed. (flush): Don't test locStream. (getLocButes): LikeWise. * gnu/java/rmi/dgc/DGCImpl.java: extends UnicastServerRef. (leaseCache): New field. (dirty): Use leaseCache. (LeaseRecord): New inner class. * gnu/java/rmi/registry/RegistryImpl.java (RegistryImpl): Don't explicitly call exportObject(). * gnu/java/rmi/registry/RegistryImpl_Stub.java: set useNewInvoke to false to communicate with Sun JDK130. * gnu/java/rmi/server/ConnectionRunnerPool.java: Add CPU comment. * gnu/java/rmi/server/RMIObjectInputStream.java (UnicastConnectionManager): Removed field. * gnu/java/rmi/server/RMIObjectOutputStream.java (replaceObject): Use UnicastServer.getExportedRef(). * gnu/java/rmi/server/UnicastConnection.java (reviveTime): New field. (expireTime): Likewise. (CONNECTION_TIMEOUT): Likewise. (disconnect): Call sock.close(). (isExpired): New method. (resetTime): Likewise. (run): Use do while loop and catch Exception for discardConnection(). * gnu/java/rmi/server/UnicastConnectionManager.java: Pool connections. * gnu/java/rmi/server/UnicastRef.java: Lots of changes. * gnu/java/rmi/server/UnicastRemoteCall.java: Lots of changes. * gnu/java/rmi/server/UnicastServer.java (refcache): New field. (exportObject): Use refcache. (unexportObject): Likewise. (getExportedRef): New method. * gnu/java/rmi/server/UnicastServerRef.java (UnicastServerRef): New constructor. (exportObject): Save manager.serverobj. (getStub): New method. * javax/rmi/PortableRemoteObject.java: New file. * gnu/javax/rmi/PortableServer.java: Likewise. * javax/rmi/CORBA/ClassDesc.java: New file. * javax/rmi/CORBA/PortableRemoteObjectDelegate.java: Likewise. * javax/rmi/CORBA/Stub.java: Likewise. * javax/rmi/CORBA/StubDelegate.java: Likewise. * javax/rmi/CORBA/Tie.java: Likewise. * javax/rmi/CORBA/Util.java: Likewise. * javax/rmi/CORBA/UtilDelegate.java: Likewise. * javax/rmi/CORBA/ValueHandler.java: Likewise. * gnu/javax/rmi/CORBA/DelegateFactory.java: Likewise. * gnu/javax/rmi/CORBA/GetDelegateInstanceException.java: Likewise. * gnu/javax/rmi/CORBA/PortableRemoteObjectDelegateImpl.java: Likewise. * gnu/javax/rmi/CORBA/StubDelegateImpl.java: Likewise. * gnu/javax/rmi/CORBA/UtilDelegateImpl.java: Likewise. * gnu/javax/rmi/CORBA/ValueHandlerImpl.java: Likewise. * javax/rmi/BAD_OPERATION.java: Stub class. * javax/rmi/ORB.java: Likewise * javax/rmi/CORBA/ObjectImpl.java: Likewise * javax/rmi/CORBA/SystemException.java: Likewise. Cheers, Mark ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: FYI: java.util.logging
> "Brian" == Brian Jones <[EMAIL PROTECTED]> writes: >> BTW. Do you know why your commits do not appear on the commit-classpath >> mailinglist? http://mail.gnu.org/pipermail/commit-classpath/ Brian> I'm trying to figure this out too. Doesn't appear to be a setting Brian> issue on the list itself. I've seen this happen in cases where the regexps in CVSROOT fail to match. Sascha, could you `cat CVS/R*' from one of your classpath directories? Maybe that will have some useful information. Tom ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: FYI: java.util.logging
Mark Wielaard <[EMAIL PROTECTED]> writes: > BTW. Do you know why your commits do not appear on the commit-classpath > mailinglist? http://mail.gnu.org/pipermail/commit-classpath/ I'm trying to figure this out too. Doesn't appear to be a setting issue on the list itself. Brian -- Brian Jones <[EMAIL PROTECTED]> ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: I wish to help
Hi, On Thursday 31 October 2002 12:15, Mark Wielaard wrote: > Has someone actually tried Rudolph with GNU Classpath? Yes, it is running quite well here. But we replaced many native methods (all but 5) by Java code. Since Rudolph uses a proprietary interface, this replacement might be interesting for classpath. On the downside, our implementation diverged from Rudolph. > Also take into account that Wonka contains only the java.awt, > java.awt.event and java.awt.image packages. We have that and > java.awt.color, java.awt.datatransfer, java.awt.dnd, java.awt.dnd.peer, > java.awt.font, java.awt.geom, java.awt.im, java.awt.im.spi, > java.awt.image.renderable, java.awt.peer and java.awt.print. The > important advantage that Rudolph has is of course that the code that > they have actually works! Not only that but it also doesn't depend on GTK. I think it would be great to separate the top level graphics stuff from the low level peer classes by a common, well-defined interface. That way had three sets of peer classes (GTK-based, acunia framebuffer, jni framebuffer), but only one common set of top level classes, which are probably much more (I have to admit that personally, I don't have to do much with graphics). I expect that the sooner we agree on such a common layer, the fewer redundant work there is on the top level. > And please make sure that all arrangements between Acunia and the FSF > are made clear and public. The last deal that was done with respect to > the AWT code (with Transvirtual) was never communicated clearly and that > produced some tensions. (I am perfectly happy to let RMS try to get a > deal that is in the best interest of all free software users as long as > it is clear in the end what has been decided.) RMS for sure is the right person to do this. I had expected all agreements of the FSF to be made public and am surprised to read this wasn't the case with Transvirtual. Cheers, Andy. -- aicas GmbH * Hoepfner Burg /"\ ASCII Ribbon Campaign Haid-und-Neu-Straße 18 * 76131 Karlsruhe \ / No HTML or RTF in mail http://www.aicas.com X No MS-Word in mail Tel: +49-721-663 968-24; Fax: +49-721-663 968-94 / \ Respect Open Standards ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: FYI: java.util.logging
Hi, On Wed, 2002-10-30 at 22:23, Sascha Brawer wrote: > just for your information: I've checked in a bunch of bug fixes to the > java.util.logging package. See the ChangeLog entries for details. > > I hope the ChangeLog is not too detailed, but for maintaining the code, > it might turn out to be useful to have that documentation available. Your ChangeLog entries are fine. They will be a great help if some bug is ever found or introduced or when someone tries to figure out what change could have changed some behaviour. Thanks. In the past you said that you thought that java.util.logging is still alpha quality code which is one of the reasons it is not yet included into libgcj. How do you feel about the code quality now? BTW. Do you know why your commits do not appear on the commit-classpath mailinglist? http://mail.gnu.org/pipermail/commit-classpath/ Cheers, Mark ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: I wish to help
Hi, On Wed, 2002-10-30 at 01:23, Brian Jones wrote: > Mark Wielaard <[EMAIL PROTECTED]> writes: > > > Chris Gray said that they wanted to relicense it if needed but I > > don't know if they are actually going to donate it to the FSF for > > inclusion in the GNU Classpath project. Note however that Rudolph is > > not a peer based implementation. > > I'm trying to get something definite from Chris right now. There has > been on-going discussion with RMS, FSF legal, and Chris since he made > that statement. There is the potential we could end up including the > relicensed Rudolph as an external library if it would save us a lot of > work. There are some logistics involved in getting our fixes or > changes back to the upstream source, for instance if we made it > possible to use native peers as an option since we have some of that > code already. Thanks for following up on that! It would be very nice to work more closely with the Wonka people. > Opinions? With respect to licensing/copyright it would be best IMHO to get everything assigned to the FSF as we have done with all other contributors. Has someone actually tried Rudolph with GNU Classpath? I have been playing a little with our current AWT implementation and Kissme but have not yet come much further then the screenshot posted by John Leuner. There are some Kissme thread issues at the moment with the latest pthreads that Stephen Crawley is working on (and if people want I have some very ugly hacks to make it more or less work atm). But after that is fixed nothing should stand in the way of hacking it into a more usable form. Also take into account that Wonka contains only the java.awt, java.awt.event and java.awt.image packages. We have that and java.awt.color, java.awt.datatransfer, java.awt.dnd, java.awt.dnd.peer, java.awt.font, java.awt.geom, java.awt.im, java.awt.im.spi, java.awt.image.renderable, java.awt.peer and java.awt.print. The important advantage that Rudolph has is of course that the code that they have actually works! I haven't checked on class level btw. (More info can be found on http://wonka.acunia.com/javadoc-0.9.3/) A small thing, but important to me, is the fact that we have much better documentation (apidoc) then the Wonka implementation. I know that RMS finds it important to have good documentation for GNU programs so you might want to bring up this point (certainly because it is a complicated matter since the documentation is embedded into the source files). And please make sure that all arrangements between Acunia and the FSF are made clear and public. The last deal that was done with respect to the AWT code (with Transvirtual) was never communicated clearly and that produced some tensions. (I am perfectly happy to let RMS try to get a deal that is in the best interest of all free software users as long as it is clear in the end what has been decided.) Thanks, Mark ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
