CORBA
So far, I see no much reasons for worying so seriously. There is an API documentation on org.omg.CORBA and I treat is just as the rest of the API documentation. Regards Audrius. ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: JamVM 1.2.5 released
Hi, Robert Schuster has sent me some very interesting performance results with JamVM. I don't know if he wants them made public, but on the fosdemo, JamVM 1.2.5 performs almost as well as Sun's Hotspot or IBM's VM (within ~0.5%). Admittedly I think it's spending most of it's time calling native code via JNI, but it's interesting none the less. If anybody else sees any dramatic speed improvements with 1.2.5 I'd be very grateful if you could provide feedback (equally, if you _don't_ see any improvements). It's not just an ego-trip -- feedback will help me tune the VM and suggest future optimisations. I only have a limited number of architectures and some defaults are pure guess-work. It's also nice to get positive feedback once in a while, instead of the usual bug reports :) Thanks, Rob. On Wed, 2 Mar 2005 10:30:24 +, Robert Lougher [EMAIL PROTECTED] wrote: Hi, I'm pleased to announce the release of JamVM 1.2.5 (http://jamvm.sourceforge.net). This release has an improved interpreter, which shows typical speed-ups of between 60% and 100% over JamVM 1.2.4. On some micro-benchmarks on a Athlon it's over 300% faster! The full list of changes are here: http://sourceforge.net/project/shownotes.php?release_id=309491 Thanks, Rob. ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: JamVM 1.2.5 released
Robert Lougher wrote: It's also nice to get positive feedback once in a while, instead of the usual bug reports :) Hi Robert, I don't have any performance numbers for you, but I can give you some positive feedback: I use JamVM for all my work on Mauve, and it is great to have a VM that is so easy to install and run with the latest GNU Classpath CVS. So I'm very grateful for all your hard work... Regards, Dave Gilbert ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
javax.swing.text.rtf.RTFEditorKit
Hi there, Is there somebody working on RTFEditorKit? I've heard some rumors about this but I am not sure. If not, I would begin with it, maybe with a simple RTF-Syntax-Filter that produces plain-text and then add special handling for formatting later. /Roman signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: CORBA
Stephen Crawley writes: For the record, I actually agree with most of what you are saying ... wearing my idealist hat. But if the aim is to find a practical solution to this problem, we are going to have to compromise somewhere. If that entails kowtowing to somebody, then maybe we need to be prepared to get our collective foreheads down into the dirt!! The practical solution, whenever we come across unfree software that we need, is re-implement it. Either that, or to persuade the original author to free it. But we don't wait very long. In the case of CORBA, we have a specification. Andrew. ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: CORBA
Hi, On Thu, 2005-03-03 at 11:36 +, Andrew Haley wrote: The practical solution, whenever we come across unfree software that we need, is re-implement it. And that is what Audrius has now set out to do. Thank you so much Audrius! You are doing what we have been talking about for years but what nobody actually did. Either that, or to persuade the original author to free it. But we don't wait very long. Chris has contacted OMG about this. But he hasn't heard back. Our main problem here is that neither the FSF nor Debian nor any other oranisation we know has very good contacts with them. The changes needed to the distribution terms wouldn't be that big. Basically add the words modify and redistribute to the distribution terms they now us for their implementation. If they don't want that, then we will not use their implementation of course. In the case of CORBA, we have a specification. And a publicly published one. As Jeff pointed out we have asked FSF legal whether we could use this specification for implementing our own compatible free implementation of these interfaces and the answer was yes. Basically whenever there is a publicly published specification or an interface describing what is needed for implementing a free implementation we can do that. 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: CORBA
Hi, On Thu, 2005-03-03 at 08:37 +0100, Dalibor Topic wrote: In my opinion, it's really up to customers that want such proof to do whatever it takes to obtain it, and not to the FSF, in general. While I've started the TCK dance with Sun as a 'qualified individual' Thanks for doing that btw. Obviously GNU Classpath is just the core libraries which are used as one of the building blocks for a full development environment that might or might not pass the TCK as you pointed out in your application. But we are positive that we want to help you in any way to pass the TCK. And we will happily accept any code changes that you think are necessary. Because I think we all feel that clear interfaces, compatibility and unit testing are a good thing for our users (in addition to the four freedoms). A badge is not important for free software, though, as the recepient can always peer under the hood and see if the software does what it claims to do. In particular if the software comes with its own extensive free software test suites, like mauve, jacks and all that. I think badges are very useful actually. But I also think that users should have the freedom to verify such claims. That is why Mauve is so important. And why it is so good to see that Mauve is growing so fastly these days. 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: CORBA
Mark Wielaard wrote: Hi, On Thu, 2005-03-03 at 08:37 +0100, Dalibor Topic wrote: In my opinion, it's really up to customers that want such proof to do whatever it takes to obtain it, and not to the FSF, in general. While I've started the TCK dance with Sun as a 'qualified individual' Thanks for doing that btw. Obviously GNU Classpath is just the core libraries which are used as one of the building blocks for a full development environment that might or might not pass the TCK as you pointed out in your application. But we are positive that we want to help you in any way to pass the TCK. And we will happily accept any code changes that you think are necessary. Because I think we all feel that clear interfaces, compatibility and unit testing are a good thing for our users (in addition to the four freedoms). Thanks for the great support and everyone's excellent work on GNU Classpath, that made it all possible, really. I'm very enthusiastic about working together with Sun on bridging the compatibility gap. A badge is not important for free software, though, as the recepient can always peer under the hood and see if the software does what it claims to do. In particular if the software comes with its own extensive free software test suites, like mauve, jacks and all that. I think badges are very useful actually. But I also think that users should have the freedom to verify such claims. That is why Mauve is so important. And why it is so good to see that Mauve is growing so fastly these days. Yeah :) I like it very much how the w3c does the badge thing with the 'valid xhtml' logos. Once your web page validates correctly, you can put the w3c badge of honour on your web page, and then anyone stopping by can click on it, and it will take them to the validator page on w3c, so they can see that for example the FSF home page is right now not[1] valid XHTML, despite the 'valid xhtml' logo on it. And I think such easy, instant public conformance validation services are great, and the way things should evolve to in general. cheers, dalibor topic [1] http://validator.w3.org/check?uri=http%3A%2F%2Fwww.fsf.org%2F ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: CORBA
Le jeudi 03 mars 2005 12:47 +1000, Stephen Crawley a crit : Sorry for the lag in responding. I lost a month's worth of mail, and this was in the middle of it. I had to recover this from GNU's ticket system. b) It is not clear (to me) that this does not violate the OMG's copyright. Certainly, it is doing something that they were (historically) trying to prevent. According to the good folks at [EMAIL PROTECTED]: * Our current plan is to just reimplement all the classes for GNU * Classpath based on the public specification published by OMG * (ftp://ftp.omg.org/pub/docs/ptc/00-01-08.pdf) *... * The zip file, is the zip file containing the source above. And often *the * actual classes and interfaces we need to implement are not that much * bigger than the examples given in the specification. This means that *our * implementation will look very similar to the example code in the * specification (and probably to the official implementation *contained * in the zip file). * *This sounds like a standard case of scenes a faire: * *'Likewise, when similar features of a work are as a practical matter *indispensable, or at least standard, in the treatment of a given idea, *they are treated like ideas and are therefore not protected by *copyright.' (Apple v. Microsoft) * *So, yes, you can do this. c) I'm not sure that a Classpath-based VM can claim CORBA compliance if it uses a version of the org.omg classes that come from a different source. It might mean that (for example) all Linux distros that include a Classpath-based Java implementation needs to get the CORBA compliance testing done themselves if they want a CORBA-x.y compliant badge. Certainly it can't. But we can't claim Java compliance either. =) The best I suspect that we could do is say 'Implements OMG Spec 00-01-08 (OMG IDL To Java Language Mapping)', and even that I would want to run past FSF legal. But that's a simple statement of truth at least. Tks, Jeff Bailey ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: javax.swing.text.rtf.RTFEditorKit
Is there somebody working on RTFEditorKit? I've heard some rumors about this but I am not sure. If not, I would begin with it, maybe with a simple RTF-Syntax-Filter that produces plain-text and then add special handling for formatting later. Yeah, I've taken a crack at doing just that. However, I wasn't really satisified with the results; it doesn't seem like a simple filter could consistently do a good job, and you really need to do some proper syntax-parsing to get good results. (and even despite that, I found that the JDK indeed has some parsing errors too.) So more recently, I started looking into using something like JavaCC to create a proper parser. (Although I haven't gotten further with that either.) But I've got no strong feelings about it, if you want to take over the code I've written so far and run with it, it's fine by me. /Sven ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: javax.swing.text.rtf.RTFEditorKit
Sven de Marothy wrote: So more recently, I started looking into using something like JavaCC to create a proper parser. (Although I haven't gotten further with that either.) Unless Sun's parser generator has surprisingly recently switched away from Sun's funny but broken non-nuclear BSD, or as Sun calls it, BSD+, to a sane license while I wasn't looking[0], I'd recommend using ANTLR for proper parsers, as it's in the public domain, well maintained and is already used successfully by gjdoc. Their licensing on JavaCC seems to be all over the place, really. The web site for JavaCC [1] claims it is under the GPL-compatible BSD license[2], but that's not the case. In reality, parts of it are under some obscure Sun closed source license that has nothing to do with BSD at all, for example [3] contains all sorts of funny claims, like restricting use, export, claims to have patents covering it, without licensing the patents to the users, and so on. A classical case of Sun claiming one thing in their 'PR' and a completely different thing in the actual licensing terms of the code. They seem do be doing that all the time recently, which is a bit disappointing from a company that should clearly know better. :( cheers, dalibor topic [0] http://lists.debian.org/debian-legal/2004/10/msg00190.html [1] https://javacc.dev.java.net/ [2] http://www.opensource.org/licenses/bsd-license.html [3] https://javacc.dev.java.net/source/browse/javacc/src/javacc.java?rev=1.1view=autocontent-type=text/vnd.viewcvs-markup ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: javax.swing.text.rtf.RTFEditorKit
Dalibor Topic wrote: Their licensing on JavaCC seems to be all over the place, really. I reported this as an issue: https://javacc.dev.java.net/issues/show_bug.cgi?id=69 No response of any kind. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/ ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: javax.swing.text.rtf.RTFEditorKit
Am Donnerstag, den 03.03.2005, 15:40 +0100 schrieb Sven de Marothy: Is there somebody working on RTFEditorKit? I've heard some rumors about this but I am not sure. If not, I would begin with it, maybe with a simple RTF-Syntax-Filter that produces plain-text and then add special handling for formatting later. But I've got no strong feelings about it, if you want to take over the code I've written so far and run with it, it's fine by me. Ok then I think I'll take it over. My plan is to start with a antlr created parser class for RTF somewhere in the gnu namespace and utilize this im RTFEditorKit. Sven, could you please send my your work? /Roman signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: javax.swing.text.rtf.RTFEditorKit
Per Bothner wrote: Dalibor Topic wrote: Their licensing on JavaCC seems to be all over the place, really. I reported this as an issue: https://javacc.dev.java.net/issues/show_bug.cgi?id=69 No response of any kind. Thanks! If they ever manage to act on it, I'd be interested to hear how it plays out. cheers, dalibor topic ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: javax.swing.text.rtf.RTFEditorKit
On Thu, 2005-03-03 at 16:10 +0100, Dalibor Topic wrote: Sven de Marothy wrote: So more recently, I started looking into using something like JavaCC to create a proper parser. (Although I haven't gotten further with that either.) Unless Sun's parser generator has surprisingly recently switched away from Sun's funny but broken non-nuclear BSD, or as Sun calls it, BSD+, to a sane license while I wasn't looking[0], I'd recommend using ANTLR for proper parsers, as it's in the public domain, well maintained and is already used successfully by gjdoc. Note the 'something like'-part.. :) And yes, the ambiguous and poor licensing situation is a good reason not to use JavaCC. /Sven ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: CORBA
(jumping into the fray..) Stephen, I think most of us (or me, at least) do understand the reasons and motives behind the OMG's choice of license. However, the fact remains that the license on their code is simply not acceptable for inclusion in any Free software project. Whether you or I or anybody thinks that position is overly idealistic is completely beside the point. Because, the point is this: CORBA can be implemented without using any OMG code, and only their written specifications. This does not violate any OMG copyright or our clean-room status, even if the OMG might like to think so. Copyright is simply NOT a good method to enforce a standard interface or API because you can't do it; Copyright does not cover the functional elements of code, which is exactly what an API or interface is. Unless we literally copy non-functional portions of their code, or literally copy non-functional parts of their specification text, they have no legal leg to stand on. And that is a good thing too. You wouldn't be able to have any kind of competition in computers if reproducing something necessary for interoperability was illegal. (Trade secret protection isn't an option either, since it's publicly documented. An intelligent choice would be to license the trademark 'CORBA' only to compliant implementations. But that's just my opinion) It can certainly be done. The OMG has no more legal standing against us than Sun does on the Java API, and that is pretty much what FSF-legal says too. Now, if the OMG made a written specification which isn't sufficient to produce compatible code, that will hardly be our fault. But I'm certain we will aim to be compatible. Anyway, I don't really think the OMG will change their scheme. But they should really have known better. But in my mind, it completely defeats the entire point of Classpath if it's not Free software. If someone wants to distribute a Classpath minus CORBA and a seperate OMG package to have guaranteed compatibility, we give them that right. But I can't see why there should be an exception for the OMG packages, when the main justification of Classpath is to have an implementation under a Free license. (I'm not entirely sympathetic to the OMG position either. I think it's overly paranoid. There are quite a number of standards out there which are NOT covered by such a license which still have not fragmented into dozens of incompatible versions.) /Sven ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: javax.swing.text.rtf.RTFEditorKit
I have started to write an RTF parser with antlr, based upon the RTF spec: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnrtfspec/html/rtfspec.asp which is quite easy and fun. When I have this ready, I will include both the antlr sources and the generated .java files in the classpath source tree, so that we have no additional dependency. The question here is, is it necessary that the generated .java files are formatted and commented just like normal source files? This can easily become a maintainence nightmare... What are your opinions? /Roman signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: javax.swing.text.rtf.RTFEditorKit
Roman Kennke wrote: I have started to write an RTF parser with antlr, based upon the RTF spec: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnrtfspec/html/rtfspec.asp which is quite easy and fun. When I have this ready, I will include both the antlr sources and the generated .java files in the classpath source tree, so that we have no additional dependency. The question here is, is it necessary that the generated .java files are formatted and commented just like normal source files? This can easily become a maintainence nightmare... What are your opinions? I don't think that's necessary for the generated files, as noone is supposed to edit them. cheers, dalibor topic ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
JDialog weirdness - what to do?
Hi list, I just found out the following got a headache from it: GNU Classpath's JDialog rejects illegal values given to the method setDefaultCloseOperation() with a IllegalArgumentException. This is good for robustness but it is not what the official implementation does :-( The official JDialog takes any argument (whether legal or not) and does not complain. That means for any int value n, after the call to dialog.setDefaultCloseOperation(n) the result of the corresponding getter is n. The behavior when you actually press the close button is as if you had set the operation to DO_NOTHING_ON_CLOSE. Btw. the default value for getDefaultCloseOperation() is HIDE_ON_CLOSE (this is documented at least). Eg. if you have a JDialog and set it's default close operation to JDialog.EXIT_ON_CLOSE getDefaultCloseOperation() will return exactly this value but does not act in this way. Now, I have two questions: 1) Who codes such crap and are we really really forced to adopt this? (I propose setting the value to DO_NOTHING_ON_CLOSE if the argument is invalid. ) 2) How could I test in mauve whether pressing the close button of a JDialog has no effect? cu Robert ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
Re: JDialog weirdness - what to do?
On Fri, Mar 04, 2005 at 01:57:53AM +0100, Robert Schuster wrote: Hi list, I just found out the following got a headache from it: GNU Classpath's JDialog rejects illegal values given to the method setDefaultCloseOperation() with a IllegalArgumentException. This is good for robustness but it is not what the official implementation does :-( The official JDialog takes any argument (whether legal or not) and does not complain. That means for any int value n, after the call to dialog.setDefaultCloseOperation(n) the result of the corresponding getter is n. The behavior when you actually press the close button is as if you had set the operation to DO_NOTHING_ON_CLOSE. Btw. the default value for getDefaultCloseOperation() is HIDE_ON_CLOSE (this is documented at least). Eg. if you have a JDialog and set it's default close operation to JDialog.EXIT_ON_CLOSE getDefaultCloseOperation() will return exactly this value but does not act in this way. Now, I have two questions: 1) Who codes such crap and are we really really forced to adopt this? (I propose setting the value to DO_NOTHING_ON_CLOSE if the argument is invalid. ) We should change the current behaviour only when real world applications fail to execute. 2) How could I test in mauve whether pressing the close button of a JDialog has no effect? You can use the hava.awt.Robot feature to press the buttun in a (GUI) mauve test. There are already some examples in mauve that use this feature. Michael -- Java Trap: http://www.gnu.org/philosophy/java-trap.html ___ Classpath mailing list Classpath@gnu.org http://lists.gnu.org/mailman/listinfo/classpath
