Re: [FOSDEM] Friday meeting!
On Thu, 2006-02-16 at 06:35 +, Andrew Haley wrote: > Tom Tromey writes: > > > "Keith" == Keith Seitz <[EMAIL PROTECTED]> writes: > > > > Keith> A La Mort Subite - 7 rue Montagne aux Herbes Potageres > > > > I like the name, I vote for here. > > A La Mort Subite is a great place. Cool. It seems we have a winner! :) I have added the info also to the Fosdem2006 wiki page: http://developer.classpath.org/mediation/Fosdem2006 I'll try to be there around 18:00. Cheers, Mark signature.asc Description: This is a digitally signed message part
Re: [FOSDEM] Friday meeting!
Mark Wielaard writes: > On Thu, 2006-02-16 at 06:35 +, Andrew Haley wrote: > > Tom Tromey writes: > > > > "Keith" == Keith Seitz <[EMAIL PROTECTED]> writes: > > > > > > Keith> A La Mort Subite - 7 rue Montagne aux Herbes Potageres > > > > > > I like the name, I vote for here. > > > > A La Mort Subite is a great place. > > Cool. It seems we have a winner! :) > > I have added the info also to the Fosdem2006 wiki page: > http://developer.classpath.org/mediation/Fosdem2006 > > I'll try to be there around 18:00. I look forward with some amusement to the sight of people unfamiliar with the Geuze trying it for the first time... Andrew.
Mysaifu JVM 0.2.1 released
Hello, Mysaifu JVM version 0.2.1 released. http://www2s.biglobe.ne.jp/~dat/java/project/jvm/index_en.html Mysaifu JVM is a Java virtual machine for Pocket PC 2003. Changes in this version: * Class library updated. (GNU Classpath 0.20) * Add bytecode verifier. * Save command line parameters in shortcut file. * Add gsgetfile.dll support. * Many bug fixes. Regards, -- freebeans <[EMAIL PROTECTED]>
SwingSet demo
Hi folks, Today I had some success to get Sun's SwingSet demo from Swing1.1 to run with GNU Classpath. Unfortuately it is not 100% suitable for the FreeSwingTestApps page, because it has a somewhat crazy license. However, it is pretty impressive to see this run with Classpath and I really want to share it with you, so I prepared a package for you to download: http://kennke.org/~roman/SwingSet.tgz This contains a slight modification so that the HTML example is not loaded (this would cause exceptions and requires lots of work still). Run it with: java -classpath build:SwingSet.jar SwingSet and enjoy. There are some small problems in it still, but all in all it looks quite nice IMO. Good work Swing team! (the others also, but this is mostly Swing related, so ...) I find it especially interesting that quite a lot of the details also work ... Maybe we can get some inspiration for our own Demo from this? Cheers, Roman signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Japi diffs for classpath
On 2/15/06, Stuart Ballard <[EMAIL PROTECTED]> wrote: > 2) The problem that I was actually trying to target with this change > doesn't seem to be solved yet: > http://www.kaffe.org/~stuart/japi/htmlout/h-jdk14-jdk15.html#err_missing_java_lang > Still shows a whole bunch of methods missing from 1.5 that should be > present. Why that's happening requires further investigation. Figured it out - it's a japi bug that's rather hard to fix. Seems that in JDK1.5 there's a package-private class AbstractStringBuilder> and StringBuffer is a subclass of AbstractStringBuilder. The methods in question are defined in AbstractStringBuilder as returning T. So they're present in StringBuffer two ways: as bridge methods, returning AbstractStringBuilder, and as real methods returning StringBuffer. Unfortunately japi is having some trouble with the fact that these methods differ only in their return type, and ends up only seeing the bridge method. And since that returns a nonpublic type, it skips it. The code in Japize that needs to be changed to fix this is complicated and the change needed isn't trivial. However, it's a different bug than the one that was just fixed, so the current results are correct as far as they go. Stuart. -- http://sab39.dev.netreach.com/
Re: SwingSet demo
I forgot to say: Don't use this demo to control a nuclear plant or airplane. It is a bad idea to attach a Swing demo to an auto pilot. :-D And do not disparage Sun using this demo, ROTFL /Roman Am Donnerstag, den 16.02.2006, 16:00 +0100 schrieb Roman Kennke: > Hi folks, > > Today I had some success to get Sun's SwingSet demo from Swing1.1 to run > with GNU Classpath. Unfortuately it is not 100% suitable for the > FreeSwingTestApps page, because it has a somewhat crazy license. > However, it is pretty impressive to see this run with Classpath and I > really want to share it with you, so I prepared a package for you to > download: > > http://kennke.org/~roman/SwingSet.tgz > > This contains a slight modification so that the HTML example is not > loaded (this would cause exceptions and requires lots of work still). > Run it with: > > java -classpath build:SwingSet.jar SwingSet > > and enjoy. > > There are some small problems in it still, but all in all it looks quite > nice IMO. Good work Swing team! (the others also, but this is mostly > Swing related, so ...) I find it especially interesting that quite a lot > of the details also work ... > > Maybe we can get some inspiration for our own Demo from this? > > Cheers, Roman > signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Mauve license
(including the Classpath list as well as Mauve list here as I don't know how many people actually read the mauve list) Recently on the Harmony list there's been some discussion of how tests should be written and where they should be put. I chimed in pointing out what I thought would be a no-brainer - tests for public APIs should be in Mauve of course. I only just made that post and I haven't seen the responses yet, but it occurred to me to look and see what Mauve's license is just to make sure that wouldn't be a showstopper, and, well, as I'm sure many of you know, it's GPL. This is slightly strange to me. We (the Free Software community) are forced to make our own test suite because Sun won't release theirs under terms we can use, but when we do write our own, we put it under a license that prevents even other Free Software projects from working with it. Our test suite is under a stronger copyleft than Classpath itself is! I understand why we want Classpath itself to be copyleft. But what on earth benefit are we getting from preventing people from "proprietarizing" our testsuite? My understanding is that a license change could be difficult to effect at this point because I don't think a copyright assignment has been required for Mauve contributions and therefore there are probably a lot of copyright holders, some of whom may be difficult to track down. But if it *could* be managed (and if the Harmony hackers could be persuaded to put their tests there), I think it would be a major win for everybody. Mauve gets a bunch of new contributors (Harmony certainly seems to have a fair bit of momentum at this point) and code (I believe some of Harmony's big contributions came with test suites that could be integrated). Classpath and Harmony both get a bunch of new tests. Harmony hackers get to see that Classpath hackers aren't inflexible GPL-zealots, and both groups of hackers get used to working together on a project that benefits both. I don't think it's a coincidence that all the projects that originally collaborated on Mauve ended up combining their class libraries, either. Once people get used to working together, the level of collaboration can only go up from there... Stuart. PS I didn't include the Harmony list on this post mainly because my understanding is it's of absolutely no interest to them unless there *is* some way for Mauve to make this change. "GPL software is a nonstarter for us" is a quote I saw on the Harmony mailing list a couple of days ago... -- http://sab39.dev.netreach.com/
Re: Mauve license
Stuart Ballard wrote: (including the Classpath list as well as Mauve list here as I don't know how many people actually read the mauve list) Recently on the Harmony list there's been some discussion of how tests should be written and where they should be put. I chimed in pointing out what I thought would be a no-brainer - tests for public APIs should be in Mauve of course. Indeed. I only just made that post and I haven't seen the responses yet, but it occurred to me to look and see what Mauve's license is just to make sure that wouldn't be a showstopper, and, well, as I'm sure many of you know, it's GPL. This is slightly strange to me. We (the Free Software community) are forced to make our own test suite because Sun won't release theirs under terms we can use, but when we do write our own, we put it under a license that prevents even other Free Software projects from working with it. Our test suite is under a stronger copyleft than Classpath itself is! I understand why we want Classpath itself to be copyleft. But what on earth benefit are we getting from preventing people from "proprietarizing" our testsuite? Free to use, free to redistribute, and since you'll never want to combine Mauve with anything else, I can't see why the GPL is considered a showstopper. My understanding is that a license change could be difficult to effect at this point because I don't think a copyright assignment has been required for Mauve contributions and therefore there are probably a lot of copyright holders, some of whom may be difficult to track down. But if it *could* be managed (and if the Harmony hackers could be persuaded to put their tests there), I think it would be a major win for everybody. I think a more significant "problem" is practical: Mauve, which predates JUnit, uses its own test harness and Harmony is using JUnit. Integrating the two is a pile of work that you're not going to find anyone willing to spend time on. I think we should just accept that there are going to be two separate test suites, that will overlap in some places. It's not that big a deal in the scheme of things. Mauve gets a bunch of new contributors (Harmony certainly seems to have a fair bit of momentum at this point) and code (I believe some of Harmony's big contributions came with test suites that could be integrated). Classpath and Harmony both get a bunch of new tests. We have those tests now, just in separate places. Regards, Dave
Re: SwingSet demo
Wow, thanks, very nice demo, and many our things are working! It is really a very nice evening! I will fix a couple remaining problems of our table. For me, the compiler initially reported several errors, related to the import statments (cannot separate between the two *.*.Timer), but these were one minute problems, probably depends on the copiler version. Audrius
Re: Mauve license
Stuart Ballard wrote: Harmony hackers get to see that Classpath hackers aren't inflexible GPL-zealots, and both groups of hackers get used to working together on a project that benefits both. This Apache/Harmony thing vs. Claspath/GPL debate is just so tempting.. :-) But let's talk practicalities.. here's a simple thing I don't understand. What exactly prevents Harmony from using Mauve as a test suite? Would Apache want to create it's own copy of Mauve and check that into SVN? That seems like a bad idea -- i.e, creating a "code fork". So then if Apache only wants to run Mauve tests, what impact does Mauve being GPL have? Why can Apache folks just download Mauve and run it, the same way Classpath hackers do? Mauve is its own self-contained project. As to the issue of converting Mauve to JUnit, that's surely a lot of work any way you slice it, and in any case that seems like an orthogonal issue. -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: Mauve license
On 2/16/06, David Gilbert <[EMAIL PROTECTED]> wrote: > Free to use, free to redistribute, and since you'll never want to > combine Mauve with anything else, I can't see why the GPL is considered > a showstopper. Politics don't have to make sense ;) The logical conclusion of your statements, though, is that the GPL isn't actually making any practical difference. And if that's the case, what's the point of using it? > I think a more significant "problem" is practical: Mauve, which > predates JUnit, uses its own test harness and Harmony is using JUnit. > Integrating the two is a pile of work that you're not going to find > anyone willing to spend time on. I think we should just accept that > there are going to be two separate test suites, that will overlap in > some places. It's not that big a deal in the scheme of things. AIUI currently you couldn't integrate the two if you wanted to because JUnit is under a non-GPL-compatible license. Another reason why a Mauve license change would be a benefit. >From a practical point of view, if the license issues disappeared, it would presumably be easy enough to create a "junit" directory in mauve, have the mauve launcher scripts run both junit *and* the existing harness, pull the harmony tests into the new folder, everybody write new tests as junit tests, and gradually convert the old tests one-at-a-time over time. It wouldn't have to be a once-off "convert the world" operation. > We have those tests now, just in separate places. True. The current situation isn't a disaster. It would just be nice to get some cooperation in a place where, IMO, it clearly *does* make sense and the showstoppers seem to be entirely unnecessary. Stuart. -- http://sab39.dev.netreach.com/
Re: Mauve license
On 2/16/06, Archie Cobbs <[EMAIL PROTECTED]> wrote: > This Apache/Harmony thing vs. Claspath/GPL debate is just so tempting.. :-) Heh. > But let's talk practicalities.. here's a simple thing I don't understand. > > What exactly prevents Harmony from using Mauve as a test suite? Nothing, and in fact I think they plan to do just that. But as I understand it their current plan is to use Mauve *in addition to* (and secondary to) their own test suite and only develop their own tests in their own repository. So we end up with two test suites being developed by two disjoint groups, both of whom are free to (and likely to) *run* the other group's suite against their own implementation, but still no actual cooperation. > So then if Apache only wants to run Mauve tests, what impact does Mauve > being GPL have? Why can Apache folks just download Mauve and run it, > the same way Classpath hackers do? Mauve is its own self-contained project. They can, but the Classpath hackers don't just run it, they write it too. Basically, I just don't see why Mauve *should* be GPL. There's absolutely no benefit in claiming copyleft on it and a considerable benefit from not doing so. Other than the issue of finding copyright holders, why *shouldn't* it be X11 or modified-BSD licensed so that anyone can use it as they see fit? I'm a GPL supporter in general but using it on a testsuite seems really wrong to me. > As to the issue of converting Mauve to JUnit, that's surely a lot of work > any way you slice it, and in any case that seems like an orthogonal issue. Yes, at this moment I'm only concerned with political issues. Technical issues are so much easier that they can be deferred for now ;) Stuart. -- http://sab39.dev.netreach.com/
Re: Mauve license
On 2/16/06, Archie Cobbs <[EMAIL PROTECTED]> wrote: > This can make sense if the Harmony tests are Harmony-specific. Some are, some aren't. They plan to have a separation between the two though. So Classpath will be able to use the non-specific part of Harmony's testsuite. > Otherwise I don't see what the point is. The point is that, for whatever reasons (rational or irrational), some people simply won't contribute to a GPL-licensed project. Some of those people are Harmony contributors. If those people want to contribute to a Java testsuite, which they do, it won't be Mauve as long as Mauve is GPL. > There may be no real reason it should be GPL, but in any case it is... > so.. what's the problem with that? I mean, from a practical standpoint. >From a practical standpoint it's deterring a fairly large body of potential contributors... > But you seem also to be asking the religious question "why GPL"? Not at all. I like the GPL. I think the GPL-with-exception license of Classpath is the perfect license for what Classpath does. I use the GPL on almost all my own code (although I prefer the LGPL for things that are designed to be used as libraries). Even RMS points out that using non-copyleft licenses can be beneficial when it's a net gain for Free Software as a whole (eg Ogg). And in this case I think there is such a gain, because the GPL is buying us nothing (since there's no practical reason why anyone would *want* to take Mauve proprietary) but costing us contributors. I seem to be in a minority though, so I'll drop the issue I guess. Stuart. -- http://sab39.dev.netreach.com/
Re: Mauve license
Hi. > But you seem also to be asking the religious question "why GPL"? > Like most religious questions that one has no objective "answer".. I dont think that "why GPL" is a religious question. The one who asks deserves an answer and here is mine: > If you really want to hear an "answer" then you can read the "official" > one in the GPL FAQ... Not in the FAQ but clearly in this essay: http://www.gnu.org/philosophy/freedom-or-power.html How is that related to our testsuite? Users of Sun's TCK have to abide to certain rules: Eg. they are not allowed to talk about the results in detail and such things. I think Dalibor can explain this better as he seems to have a natural interest in Licensing Circuses. ;) Giving a testsuite away under a non-copylefted license allows others to implement such powers over their users. At least for me I am against giving someone this kind of freedom. Sorry. cya Robert signature.asc Description: OpenPGP digital signature
Re: Mauve license
Stuart Ballard writes: > > Even RMS points out that using non-copyleft licenses can be beneficial > when it's a net gain for Free Software as a whole (eg Ogg). > > And in this case I think there is such a gain, because the GPL is > buying us nothing (since there's no practical reason why anyone would > *want* to take Mauve proprietary) Oh, I see your meaning. > but costing us contributors. This part is the mystery. If, as you say, there's no practical reason why anyone would *want* to take Mauve proprietary, why does it matter that Mauve is GPL? > I seem to be in a minority though, so I'll drop the issue I guess. It's not that. I just don't understand. Andrew.
Re: Mauve license
Stuart Ballard wrote: But as I understand it their current plan is to use Mauve *in addition to* (and secondary to) their own test suite and only develop their own tests in their own repository. So we end up with two test suites being developed by two disjoint groups, both of whom are free to (and likely to) *run* the other group's suite against their own implementation, but still no actual cooperation. This can make sense if the Harmony tests are Harmony-specific. Otherwise I don't see what the point is. Basically, I just don't see why Mauve *should* be GPL. There's absolutely no benefit in claiming copyleft on it and a considerable benefit from not doing so. Other than the issue of finding copyright holders, why *shouldn't* it be X11 or modified-BSD licensed so that anyone can use it as they see fit? There may be no real reason it should be GPL, but in any case it is... so.. what's the problem with that? I mean, from a practical standpoint. But you seem also to be asking the religious question "why GPL"? Like most religious questions that one has no objective "answer".. If you really want to hear an "answer" then you can read the "official" one in the GPL FAQ... -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
[Bug classpath/22918] java.lang.Math contains lots of native methods.
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |0.21 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22918 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
Re: Mauve license
I don't really understand your reasoning here. You haven't explained why all the usual reasons in favour of GPL don't apply to testsuites. Andrew.
Re: Mauve license
(this is going to show up in the wrong place in the thread - for some reason I can see mails showing up in the archives but I'm not receiving them myself till much later, so I don't have this one myself to respond to yet) Andrew Haley wrote: > > but costing us contributors. > > This part is the mystery. If, as you say, there's no practical reason > why anyone would *want* to take Mauve proprietary, why does it matter > that Mauve is GPL? There are quite a few reasons, some logical, some not, why people won't contribute to GPL projects. Some corporations have policies prohibiting employees from looking at GPL code. I don't believe there's any *good* reason for an organization to have such a policy, but some do. It appears there's at least one contributor on the Harmony list who is unable to look at Classpath code for this reason. Some corporations may have weaker policies that would still prohibit employees from actually writing GPL code on company time. Some people see the GPL as an endorsement of a political position they don't agree with and won't work on software licensed under it for that reason. Some people philosophically oppose the idea of copyleft and don't want their work under such a license. The Apache organization has policies against distributing GPL code and I believe also against requiring it as a dependency. (Even if everyone at Apache could be persuaded that changing this was a good idea, their procedures for doing so seem to take a while). A test suite isn't strictly a dependency but I think they'd at least have strong reservations against making it official policy that if you're writing tests for Harmony that test public APIs they should go in this GPL project. Another reason I feel test suites shouldn't be copyleft is similar to RMS's reasoning about Ogg: the greatest benefit to Free Software is obtained by having all implementations be compatible and compatible with the existing proprietary solution to help people escape the trap. The best way to achieve that is by getting good tests as widely disseminated and used as possible (analagous to getting Ogg support as widely used as possible to help people escape the mp3 trap). (another email I'm seeing in the archives but haven't received myself - Andrius's point about the OMG tests. I believe it should be possible to convert the license back to LGPL if we have permission from the copyright holders of all the code that was changed since, which would then mean that as long as the OMG tests are self-contained, they could be linked happily with a non-copyleft Mauve even if they themselves are still copyleft). Stuart. -- http://sab39.dev.netreach.com/
Re: Mauve license
Stuart Ballard wrote: The point is that, for whatever reasons (rational or irrational), some people simply won't contribute to a GPL-licensed project. Some of those people are Harmony contributors. If those people want to contribute to a Java testsuite, which they do, it won't be Mauve as long as Mauve is GPL. Well then IMHO those people are the ones who are being "difficult" and putting politics over progress. Saying you won't contribute to a GPL project is more a political statement than the result of some reasonable decision-making process, because even if you do contribute to GPL software, you still own the copyright so you can also release your code under any other license you choose. Personally I don't love the GPL because it imposes more restrictions than a BSD style license (making, in my opinion, GPL software less free). But I respect others' religious beliefs. So if the GPL is not otherwise in the way, I have no problem working with it, etc. "Can't we all just get along?" :-) -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: Mauve license
On Thu, Feb 16, 2006 at 12:51:41PM -0500, Stuart Ballard wrote: > On 2/16/06, Archie Cobbs <[EMAIL PROTECTED]> wrote: > > This can make sense if the Harmony tests are Harmony-specific. > > Some are, some aren't. They plan to have a separation between the two > though. So Classpath will be able to use the non-specific part of > Harmony's testsuite. > > > Otherwise I don't see what the point is. > > The point is that, for whatever reasons (rational or irrational), some > people simply won't contribute to a GPL-licensed project. Some of > those people are Harmony contributors. If those people want to > contribute to a Java testsuite, which they do, it won't be Mauve as > long as Mauve is GPL. > Wait. Sit back. Relax. We've all been there (Sven, Mark, Tom, Anthony, Leo, Geir, Davanum, etc.), done that, and eventually figured out that trying to fix politics for fixing politics sake is not working that well. If there is no need for people to sit down and actually do something together, then there will be no results other than an enthusiastic exchange of opinions. While those things are fun, they are best done in a bar, with appropriate beverages. (That reminds me to ping Leo, Geir and the other ASF guys about their plans for arrival at FOSDEM). There is no harm done in Harmony and GNU Classpath being two separate projects, with largely different sets of code. There is absolutely no harm being done in Harmony duplicating the efforts of GNU Classpath, under a different license. We've got glibc, and we've got dietlibc, uclibc, newlib, you name it. Each of the smaller libcs fills a different niche, and so does Apache Harmony. It wouldn't have a niche that needed filling with source code contributions if it went and wed itself to GNU Classpath and Mauve: then all the good, easy spots for contributions would be already taken. And if you want to entice companies to dig out their 'crown jewels', and give them into the hands of the people, you have to give them a place where they are needed. What holds for class libraries, holds for test suites as well. I'd love to see $BIG_CORPS contribute their internal test suites to Mauve. Failing that, contributing their test suites to Harmony suddendly offers a better PR opportunity than simply sitting on the code forever. That opportunity did not exist before Harmony was created with big fanfares. We don't have to share code in order to grow together. Code duplication is not a bad thing, and Harmony needs time and space to find its own niches. Once it has found them, and successfully occupied them, and technically, shareing code make sense for everyone, sure, code will be shared. The FSF is putting the necessary mechanisms to be able to reuse Harmony's code in GPLv3, so in the long run, there are no issues at all that require political action today. > > There may be no real reason it should be GPL, but in any case it is... > > so.. what's the problem with that? I mean, from a practical standpoint. > > >From a practical standpoint it's deterring a fairly large body of > potential contributors... > Then Harmony is the perfect place for them. They put their tests there, and everyone wins. See, even if Mauve was licensed under a public domain license, a fairly large body of potential contributors has no desire to be associated with the FSF at all, for whatever reasons they may have. It's important to acknowledge that no matter what we do, we'll never be able to make everyone happy. But that's precisely what those other nice projects are for, so that everyone can find the one that suits them best. cheers, dalibor topic > > But you seem also to be asking the religious question "why GPL"? > > Not at all. I like the GPL. I think the GPL-with-exception license of > Classpath is the perfect license for what Classpath does. I use the > GPL on almost all my own code (although I prefer the LGPL for things > that are designed to be used as libraries). > > Even RMS points out that using non-copyleft licenses can be beneficial > when it's a net gain for Free Software as a whole (eg Ogg). > > And in this case I think there is such a gain, because the GPL is > buying us nothing (since there's no practical reason why anyone would > *want* to take Mauve proprietary) but costing us contributors. > > I seem to be in a minority though, so I'll drop the issue I guess. > > Stuart. > > -- > http://sab39.dev.netreach.com/ >
Re: SwingSet demo
Hi Roman, On Thu, 2006-02-16 at 16:46 +0100, Roman Kennke wrote: > I forgot to say: Don't use this demo to control a nuclear plant or > airplane. It is a bad idea to attach a Swing demo to an auto pilot. :-D > And do not disparage Sun using this demo, ROTFL Funny. But also a little sad. They are small restrictions that make this demo almost, but not really Free Software. It is a nice demo though. (The word disparage is troublesome though. I am no native speaker, but it seems to mean "to dishonor by a comparison with what is inferior". So it is probably not a good idea to use this Demo to show we draw things faster, or have better anti-aliasing compared to the Sun implementation...) > Am Donnerstag, den 16.02.2006, 16:00 +0100 schrieb Roman Kennke: > > However, it is pretty impressive to see this run with Classpath and I > > really want to share it with you, so I prepared a package for you to > > download: > > > > http://kennke.org/~roman/SwingSet.tgz > > > > There are some small problems in it still, but all in all it looks quite > > nice IMO. Good work Swing team! (the others also, but this is mostly > > Swing related, so ...) I find it especially interesting that quite a lot > > of the details also work ... This is very, very impressive! I just tried it with jamvm and GNU Classpath cvs head (you really need the lastest cvs source). And it is pretty snappy and looks really good. I am really looking forward to your Free Swing talk at Fosdem. Congrats to everybody! Mark signature.asc Description: This is a digitally signed message part
Re: SwingSet demo
Mark Wielaard wrote: This is very, very impressive! I just tried it with jamvm and GNU Classpath cvs head (you really need the lastest cvs source). And it is pretty snappy and looks really good. I am really looking forward to your Free Swing talk at Fosdem. Me too...2006 is the year of Free Swing! Regards, Dave
[Bug xml/26324] New: AElfred: spurious extra newline notified
AElfred notifies a spurious extra newline to the user-supplied ContentHandler. Given the source document This is the child number 1. Tracing shows the following sequence of events notified: RCVR 2 START DOCUMENT RCVR 2 START ELEMENT doc RCVR 2 CHARACTERS (whitespace) "10 32 32 " RCVR 2 START ELEMENT child1 RCVR 2 START CONTENT RCVR 2 CHARACTERS "84 104 105 115 32 105 115 32 116 104 101 32 99 104 105 108 100 32 110 117 109 98 101 114 32 49 46 " RCVR 2 END ELEMENT RCVR 2 CHARACTERS (whitespace) "10 10 " RCVR 2 END ELEMENT RCVR 2 END DOCUMENT The last "CHARACTERS" event should be a single newline, not two. Note that in the source, the newlines are actually x0D x0A (Windows line endings) -- Summary: AElfred: spurious extra newline notified Product: classpath Version: 0.21 Status: UNCONFIRMED Severity: normal Priority: P3 Component: xml AssignedTo: dog at gnu dot org ReportedBy: mike at saxonica dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26324 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
