[Bug swing/26488] Menu selection behavior differs from Sun impl when mouse is depressed
-- fitzsim at redhat dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |langel at redhat dot com |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-03-03 19:51:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26488 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
[Bug libgcj/25713] GZIPOutputStream bad checksum
--- Comment #6 from tromey at gcc dot gnu dot org 2006-03-10 23:10 --- I checked in the fix. The fix for the 4.1 branch could be back-ported to the 4.0 branch if someone wanted to do it. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.1.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25713 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
[Bug libgcj/25713] GZIPOutputStream bad checksum
--- Comment #5 from tromey at gcc dot gnu dot org 2006-03-10 23:09 --- Subject: Bug 25713 Author: tromey Date: Fri Mar 10 23:09:23 2006 New Revision: 111949 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=111949 Log: libjava PR libgcj/25713: * java/util/zip/Deflater.java (flush): New method. * sources.am, Makefile.in: Rebuilt. * java/util/zip/DeflaterOutputStream.java: Removed. * java/util/zip/InflaterInputStream.java: Likewise. * java/util/zip/GZIPInputStream.java: Likewise. * java/util/zip/GZIPOutputStream.java: Likewise. libjava/classpath For PR libgcj/25713: * java/util/zip/InflaterInputStream.java (read): Replaced with libgcj implementation. Removed: trunk/libjava/java/util/zip/DeflaterOutputStream.java trunk/libjava/java/util/zip/GZIPInputStream.java trunk/libjava/java/util/zip/GZIPOutputStream.java trunk/libjava/java/util/zip/InflaterInputStream.java Modified: trunk/libjava/ChangeLog trunk/libjava/Makefile.in trunk/libjava/classpath/ChangeLog.gcj trunk/libjava/classpath/java/util/zip/InflaterInputStream.java trunk/libjava/java/util/zip/Deflater.java trunk/libjava/sources.am -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25713 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
Re: J2ME - based on classpath
On Fri, 2006-03-10 at 15:10 -0700, Tom Tromey wrote: > I think working on a branch in the Classpath repository would be a > great idea. > > We'll need to get through the paperwork hurdles -- but we'll need to > do that no matter what, if you want to eventually merge this code in. I think too the Classpath repository is the best location. The paperwork shouldn't be a problem, as Michal already did it for gforth. However, let's do that ASAP. Mark, can you send the form to Michal? TWISTI
Re: J2ME - based on classpath
> "Michal" == Michal Revucky <[EMAIL PROTECTED]> writes: Michal> the result of my work should conform the CLDC/MIDP specs, and Michal> CDC (what i learned today ;)) too. the question is if the gnu Michal> classpath community will support my plan and provide me a cvs Michal> repo or a branch in the repo. i could use the cacao or my own Michal> repository too. I think working on a branch in the Classpath repository would be a great idea. We'll need to get through the paperwork hurdles -- but we'll need to do that no matter what, if you want to eventually merge this code in. Tom
Re: Where's the love?
Dalibor Topic wrote: On Fri, Mar 10, 2006 at 12:20:02AM -0800, Per Bothner wrote: Dalibor Topic wrote: The only way GNU Classpath would be acceptable for Apache Harmony, afaict from our dicussions in the past year, would be if the FSF contributed it to the ASF, and had the ASF manage the project, under the Apache license. Anything else is non-option for ASF, for a variety of reasons. Harmony appears to be basically an attempt at a hostile takeover of the Free Java movement. They're all in favor of cooperation - as long as it is 100% on their terms. Complete surrender is all they will accept. I hope I'm wrong, but nothing I've heard suggests otherwise. I am sorry if I gave that impression, since that's not the way I experienced it. My impression was that the ASF simply has certain ways to do things, and does not want to change those, since their way basically works fine for them, and they don't think GNU Classpath is worth changing their ways of doing things, as apparently, that's all very tedious and so on. I wouldn't want to imply malice, where buerocratic inertia is a sufficient explanation. This is all really sad. Guess the only thing to do is ignore Harmony and and rub it in that they had to get donations to get anywhere. Ha! ;) Brian
[Bug awt/26486] Graphics.fillRect extremely slow
--- Comment #22 from hendrich at informatik dot uni-hamburg dot de 2006-03-10 10:17 --- Subject: Re: Graphics.fillRect extremely slow > Please disregard the numbers in Comments 18 and 19. Because of a bug in GNU > Classpath's build machinery (PR 26623), I was testing the same patch both > times. Here are the actual results for GCJ: one bug report almost always triggers the next ;-) > I think these results are pretty conclusive. yep. Thanks for fixing this; applications using lots of drawing should run much faster now. > - oneslime.net hardly flickers at all but feels sluggish. > - oneslime.net flickers badly but is fast and playable > - oneslime.net is unplayably choppy Do you have the source code for oneslime? I tried to look at the source code, but failed to find a download. If you don't have the source code, I am not sure that oneslime is the best reference application for gcj/classpath - except for its historical value of being the first applet/game ever running with classpath, of course. I have received (mild) flak on gcj/classpath lists for using non-open-source apps as tests myself... Using javap on the class files shows that there is a paint() method, but no update() method. The flickering indicates that oneslime doesn't use its own double-buffering. Therefore, the lack of update() is a strong indication of a "broken" design - prone to flicker. Perhaps we can find another reference app for testing and benchmarking animations? - Norman -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26486 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
[Bug xml/26620] Unexpected gnu.xml.dom.DomDOMException
--- Comment #3 from cvs-commit at developer dot classpath dot org 2006-03-10 09:15 --- Subject: Bug 26620 CVSROOT:/cvsroot/classpath Module name:classpath Branch: Changes by: Chris Burdess <[EMAIL PROTECTED]>06/03/10 09:12:27 Modified files: . : ChangeLog gnu/xml/transform: TransformerImpl.java Log message: 2006-03-10 Chris Burdess <[EMAIL PROTECTED]> PR 26620: * gnu/xml/transform/TransformerImpl.java: Suspend wellformedness checking while reindenting. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/classpath/classpath/ChangeLog.diff?tr1=1.6675&tr2=1.6676&r1=text&r2=text http://cvs.savannah.gnu.org/viewcvs/classpath/classpath/gnu/xml/transform/TransformerImpl.java.diff?tr1=1.11&tr2=1.12&r1=text&r2=text -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26620 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
[Bug classpath/26599] MechDisplay bugs in MegaMek
--- Comment #6 from langel at redhat dot com 2006-03-10 20:59 --- Fixed -- langel at redhat dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26599 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
[Bug classpath/26585] tools.zip should installed to $prefix/share/classpath
--- Comment #1 from cvs-commit at developer dot classpath dot org 2006-03-10 01:51 --- Subject: Bug 26585 CVSROOT:/cvsroot/classpath Module name:classpath Branch: Changes by: Tom Tromey <[EMAIL PROTECTED]>06/03/10 01:49:42 Modified files: . : ChangeLog tools : Makefile.am Log message: PR classpath/26585: * tools/Makefile.am (TOOLSdir): Don't put tools.zip in tools subdir. Added README. (install-data-local): Removed. (uninstall-local): Likewise. (EXTRA_DIST): Removed. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/classpath/classpath/ChangeLog.diff?tr1=1.6673&tr2=1.6674&r1=text&r2=text http://cvs.savannah.gnu.org/viewcvs/classpath/classpath/tools/Makefile.am.diff?tr1=1.6&tr2=1.7&r1=text&r2=text -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26585 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
[Bug classpath/26623] GNU Classpath should support install-exec target
--- Comment #1 from tromey at gcc dot gnu dot org 2006-03-10 01:02 --- I'll handle this. -- tromey at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tromey at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-03-10 01:02:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26623 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
[Bug awt/22163] scrollbars appear and disappear
--- Comment #3 from langel at redhat dot com 2006-03-09 22:09 --- Fixed. most widgets are fixed accordingly. I will be fixing the rest and creating mauve tests for all AWT widgets. -- langel at redhat dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22163 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
Re: Japi diffs for classpath-generics
So anyone subscribed to the testresults list may be thinking "huh?" right now...
As usual, fixing one bug I introduced another. I added code to make
Japi aware of covariance so that StringBuffer didn't get screwed up,
but my fix had a typo which caused the wrong method to be used in some
cases. I've fixed it, I think, but rather than spam everyone again,
I'll just let the next nightly run pick them up.
Note to self: In regexes, {1-2} is *not* a synonym for {1,2}
Stuart.
On 3/10/06, Stuart Ballard <[EMAIL PROTECTED]> wrote:
> Japi diff jdk10 vs classpath-generics:
> Full results:
> http://www.kaffe.org/~stuart/japi/htmlout/h-jdk10-classpath-generics.html
>
> Changes since last run:
>
> -Comparison run at Fri Mar 10 11:20:54 2006 GMT
> -jdk10 API scanned at 2006/03/10 05:32:52 EST
> -classpath-generics API scanned at 2006/03/10 06:14:34 EST
> +Comparison run at Fri Mar 10 19:05:57 2006 GMT
> +jdk10 API scanned at 2006/03/10 01:07:52 EST
> +classpath-generics API scanned at 2006/03/10 01:55:36 EST
> -java.lang: 99.33% good
> +java.lang: 99.4% good
> -Total: 91.25% good
> +Total: 91.26% good
>
>
> Japi diff jdk11 vs classpath-generics:
> Full results:
> http://www.kaffe.org/~stuart/japi/htmlout/h-jdk11-classpath-generics.html
>
> Changes since last run:
>
> -Comparison run at Fri Mar 10 11:21:27 2006 GMT
> -jdk11 API scanned at 2006/03/10 05:32:19 EST
> -classpath-generics API scanned at 2006/03/10 06:14:34 EST
> +Comparison run at Fri Mar 10 19:06:33 2006 GMT
> +jdk11 API scanned at 2006/03/10 01:07:13 EST
> +classpath-generics API scanned at 2006/03/10 01:55:36 EST
> -java.lang: 99.82% good
> +java.lang: 99.88% good
>
>
> Japi diff jdk12 vs classpath-generics:
> Full results:
> http://www.kaffe.org/~stuart/japi/htmlout/h-jdk12-classpath-generics.html
>
> Changes since last run:
>
> -Comparison run at Fri Mar 10 11:23:46 2006 GMT
> -jdk12 API scanned at 2006/03/10 05:28:45 EST
> -classpath-generics API scanned at 2006/03/10 06:14:34 EST
> +Comparison run at Fri Mar 10 19:08:34 2006 GMT
> +jdk12 API scanned at 2006/03/10 01:00:51 EST
> +classpath-generics API scanned at 2006/03/10 01:55:36 EST
> -java.lang: 99.89% good
> +java.lang: 99.94% good
>
>
> Japi diff jdk13 vs classpath-generics:
> Full results:
> http://www.kaffe.org/~stuart/japi/htmlout/h-jdk13-classpath-generics.html
>
> Changes since last run:
>
> -Comparison run at Fri Mar 10 11:26:18 2006 GMT
> -jdk13 API scanned at 2006/03/10 05:24:22 EST
> -classpath-generics API scanned at 2006/03/10 06:14:34 EST
> +Comparison run at Fri Mar 10 19:10:58 2006 GMT
> +jdk13 API scanned at 2006/03/10 12:52:06 EST
> +classpath-generics API scanned at 2006/03/10 01:55:36 EST
> -java.lang: 99.89% good
> +java.lang: 99.94% good
>
>
> Japi diff jdk14 vs classpath-generics:
> Full results:
> http://www.kaffe.org/~stuart/japi/htmlout/h-jdk14-classpath-generics.html
>
> Changes since last run:
>
> -Comparison run at Fri Mar 10 11:29:19 2006 GMT
> -jdk14 API scanned at 2006/03/10 05:17:50 EST
> -classpath-generics API scanned at 2006/03/10 06:14:34 EST
> +Comparison run at Fri Mar 10 19:15:10 2006 GMT
> +jdk14 API scanned at 2006/03/10 12:41:57 EST
> +classpath-generics API scanned at 2006/03/10 01:55:36 EST
> -java.lang: 99.91% good
> +java.lang: 99.95% good
>
>
> Japi diff jdk15 vs classpath-generics:
> Full results:
> http://www.kaffe.org/~stuart/japi/htmlout/h-jdk15-classpath-generics.html
>
> Changes since last run:
>
> -Comparison run at Fri Mar 10 11:32:34 2006 GMT
> -jdk15 API scanned at 2006/03/10 05:10:11 EST
> -classpath-generics API scanned at 2006/03/10 06:14:34 EST
> +Comparison run at Fri Mar 10 19:19:11 2006 GMT
> +jdk15 API scanned at 2006/03/10 12:28:39 EST
> +classpath-generics API scanned at 2006/03/10 01:55:36 EST
> -java.lang: 99.21% good, 0.78% missing
> +java.lang: 99.02% good, 0.21% bad, 0.76% missing
> -java.io: 99.74% good, 0.05% bad, 0.2% missing
> -java.math: 96.68% good, 0.47% minor, 2.84% missing
> -java.net: 89.6% good, 0.06% minor, 10.33% missing
> -java.nio: 100% good
> +java.io: 98.55% good, 1.24% bad, 0.19% missing
> +java.math: 96.74% good, 0.46% minor, 2.79% missing
> +java.net: 89.5% good, 0.06% minor, 10.42% missing
> +java.nio: 99.49% good, 0.5% bad
> -java.security: 82.43% good, 17.56% missing
> +java.security: 82.33% good, 17.66% missing
> -java.util: 95.84% good, 0.04% minor, 0.12% bad, 3.99% missing
> +java.util: 95.66% good, 0.04% minor, 0.24% bad, 4.05% missing
> -javax.net.ssl: 78.34% good, 0.12% bad, 21.52% missing
> +javax.net.ssl: 77.95% good, 0.12% bad, 21.91% missing
> -javax.swing: 98.97% good, 0.25% minor, 0.01% bad, 0.75% missing
> +javax.swing: 98.96% good, 0.25% minor, 0.01% bad, 0.76% missing
> -javax.swing.text.html: 64.09% good, 0.33% minor, 0.03% bad, 35.52% missing
> +javax.swing.text.html: 64.04% good, 0.33% minor, 0.03% bad, 35.57% missing
> -Total: 91.78% good, 0.12% minor, 0.01% bad, 8.07% missing
> +Total: 91.74% good, 0.12% minor, 0.03% bad, 8.09% missing
> -Methods: 8 minor, 6 bad, 371 missing.
> +M
Re: Where's the love?
Dalibor Topic wrote: On Fri, Mar 10, 2006 at 12:20:02AM -0800, Per Bothner wrote: Harmony appears to be basically an attempt at a hostile takeover of the Free Java movement. They're all in favor of cooperation - as long as it is 100% on their terms. Complete surrender is all they will accept. I am sorry if I gave that impression, since that's not the way I experienced it. My impression was that the ASF simply has certain ways to do things, and does not want to change those, since their way basically works fine for them, and they don't think GNU Classpath is worth changing their ways of doing things, as apparently, that's all very tedious and so on. I wouldn't want to imply malice, where buerocratic inertia is a sufficient explanation. I used "hostile takeover" in the sense of a corporate takeover. Malice is usually not involved - just an unwillingness to negotiate with the old management and board. That seems to be descriptive. I think it goes beyond bureaucratic inertia. You agree that they seem to have no interest in co-operating with the rest of the Free Software movement, unless it is done on their terms. Rather like the attitude of the current US government to the rest of the world ... And of course there is the Orwellian name "Harmony" - reminds you of Ministry of Peace, doesn't it? -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/
Re: GJDoc
Julian Scheid wrote: So I've finally got a chance to look at the ecj parser yesterday, and indeed it seems to be perfectly suited for the task. It even comes with a Javadoc comment parser which appears to be adaptable for Gjdoc's purposes. Assuming that you're right about the licensing issues, I agree that this lends itself very well. Thanks for the heads-up. Now one big problem remains, namely integrating the new parser into Gjdoc - as I said, the parsing step is not cleanly abstracted away, so unfortunately this amounts to quiet a lot of work - so much work actually that I am considering doing a complete rewrite of the Gjdoc core instead, something which is long overdue anyway. Given that a lot of last year's work on Gjdoc went into the doclet, which can be retained unmodified, and now that I'm quiet acquainted with the requirements and peculiarities of the system, this isn't as big an undertaking as it may sound at first. I'll look further into this during the next week(s) and keep you up to date. Julian Great! I'll volunteer to test out the refactored code as soon as you have something ready... Regards, Dave
[Bug classpath/26631] application to test
--- Comment #1 from mark at gcc dot gnu dot org 2006-03-10 15:11 --- See also the description of this app on the FreeSwingTestApps classpath developer wiki page at http://developer.classpath.org/mediation/FreeSwingTestApps#head-613b7f44f058139b48caa6c11a85a3d522a9a2b8 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26631 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
Re: GJDoc
On Fri, 10 Mar 2006 15:12:54 +0100
Julian Scheid <[EMAIL PROTECTED]> wrote:
> Andrew John Hughes wrote:
> > Not to put a spanner in the works, but is integrating with ecj possible now?
> > I notice the mail quoted above says 'in the future', and, given this and
> > Tom's original proposal, I'm wondering whether using ecj is reliant on
> > GPLv3.
> > If this is the case, then it won't be available until at least January next
> > year...
>
> Yes, I should have addressed this in my previous message. I didn't miss
> that part :)
>
> I plan to isolate the parser behind a well-defined interface. This way,
> when Gjdoc V2 is ready to replace V1 officially and the licensing issues
> aren't sorted out by then, it will be easy to swap it out in favor of an
> alternative.
>
> Since adapting the ecj parser for Gjdoc doesn't look like a lot of work,
> not much would be lost in this case. And by starting out with ecj I can
> concentrate on architecture and design without having to worry about
> parsing at this point.
>
> So as I see it, the ultimate choice of which parser to use for the final
> version of Gjdoc V2 can be safely postponed, with ecj as an intermediary
> solution (and "standard parser" any replacement parser can be compared
> against).
>
> Julian
>
Yes, abstracting the parser away from the rest of the code makes perfect sense.
Cheers,
--
Andrew :-)
Please avoid sending me Microsoft Office (e.g. Word, PowerPoint) attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
Support OpenDocument instead.
Escape the Java Trap with GNU Classpath!
http://www.gnu.org/philosophy/java-trap.html
public class gcj extends Freedom implements Java { ... }
"Value your freedom, or you will lose it, teaches history.
`Don't bother us with politics' respond those who don't want to learn."
-- Richard Stallman
The views expressed above are representative of my own personal
opinions, and not necessarily those of the University of Sheffield.
pgpDXAOOmazwv.pgp
Description: PGP signature
Re: GJDoc
On Fri, 10 Mar 2006 13:40:21 +0100
Julian Scheid <[EMAIL PROTECTED]> wrote:
>
> Stuart Ballard wrote:
> > On 3/1/06, Julian Scheid <[EMAIL PROTECTED]> wrote:
> >
> >>What I'd really like to do is completely replace the parser with a new
> >>one written from scratch (preferrably, a generated one.) In addition,
> >>the parsing and type resolution steps should be cleanly separated - they
> >>are somewhat intermingled at the time.
> >
> >
> > What are the odds of replacing it by calls into ecj's parsing engine,
> > since that's already pretty mature and implemented in pure Java?
> >
> > The licensing problems that may exist at this time seem to be
> > resolvable, as evidenced by the plan to use ecj as gcc's Java frontend
> > in the future...
>
> So I've finally got a chance to look at the ecj parser yesterday, and
> indeed it seems to be perfectly suited for the task. It even comes with
> a Javadoc comment parser which appears to be adaptable for Gjdoc's
> purposes. Assuming that you're right about the licensing issues, I
> agree that this lends itself very well. Thanks for the heads-up.
>
Not to put a spanner in the works, but is integrating with ecj possible now?
I notice the mail quoted above says 'in the future', and, given this and
Tom's original proposal, I'm wondering whether using ecj is reliant on GPLv3.
If this is the case, then it won't be available until at least January next
year...
> Now one big problem remains, namely integrating the new parser into
> Gjdoc - as I said, the parsing step is not cleanly abstracted away, so
> unfortunately this amounts to quiet a lot of work - so much work
> actually that I am considering doing a complete rewrite of the Gjdoc
> core instead, something which is long overdue anyway.
>
Yes, this was my grasp of it too.
> Given that a lot of last year's work on Gjdoc went into the doclet,
> which can be retained unmodified, and now that I'm quiet acquainted with
> the requirements and peculiarities of the system, this isn't as big an
> undertaking as it may sound at first.
>
> I'll look further into this during the next week(s) and keep you up to date.
>
> Julian
>
Thanks,
--
Andrew :-)
Please avoid sending me Microsoft Office (e.g. Word, PowerPoint) attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
Support OpenDocument instead.
Escape the Java Trap with GNU Classpath!
http://www.gnu.org/philosophy/java-trap.html
public class gcj extends Freedom implements Java { ... }
"Value your freedom, or you will lose it, teaches history.
`Don't bother us with politics' respond those who don't want to learn."
-- Richard Stallman
The views expressed above are representative of my own personal
opinions, and not necessarily those of the University of Sheffield.
pgppZJuhw0YI2.pgp
Description: PGP signature
[Bug awt/26519] Focus (?) troubles when switching phases.
--- Comment #5 from langel at redhat dot com 2006-03-07 23:07 --- Created an attachment (id=10988) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10988&action=view) gtk test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26519 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
[Bug awt/26486] Graphics.fillRect extremely slow
--- Comment #16 from fitzsim at redhat dot com 2006-03-07 22:07 --- By the way, I'd like to include FillRect and GameOfLifeAWT in the GNU Classpath AWT demo, and GameOfLife in the Swing demo. Including them may require a copyright assignment. Do you have paperwork on file with the FSF? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26486 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
[Bug awt/26519] Focus (?) troubles when switching phases.
--- Comment #3 from langel at redhat dot com 2006-03-07 21:04 --- I am pretty sure it is a problem in GTK. As it appears, gtk does not recognize those click events. The AWT does, but gtk doesnt- so postActionEvent is not called and the button does not change its state (it does not become depressed). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26519 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
[Bug classpath/26599] New: MechDisplay bugs in MegaMek
The mech display in megamek is really ugly. there are alot of problems with it. I will work on this. -- Summary: MechDisplay bugs in MegaMek Product: classpath Version: 0.90 Status: UNCONFIRMED Severity: normal Priority: P3 Component: classpath AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: langel at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26599 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
[Bug libgcj/25713] GZIPOutputStream bad checksum
--- Comment #3 from tromey at gcc dot gnu dot org 2006-03-10 16:13 --- This bug is gcj-specific. I'm handling it. -- tromey at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tromey at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Component|classpath |libgcj Product|classpath |gcc Last reconfirmed|2006-01-11 20:02:48 |2006-03-10 16:13:27 date|| Version|unspecified |4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25713 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
Re: A La Mort Subite
Oh, really thanks! I have brought home the full camera card of images but this is the only one where I can find myself! Audrius.
Friday job...
Hi All, Here is a nice Friday task if anyone is running out of things to do for the week (as if). The following packages have no description on the front page of our API docs - this is either because the package.html file contains an empty description, or package.html is missing entirely (in which case you can copy one from another package and amend the title and description accordingly). So if you know something about any of the following packages, please add/update the package.html file for it (so the front page of our API docs looks a little more polished). The description is just one or two sentences that describe what the package provides (only the first sentence appears on the front page). It would be nice to get this done in time for the next release in May - better still, by the end of next week! java.awt.image.renderable java.rmi.activation java.rmi.dgc java.rmi.registry java.rmi.server java.security java.security.acl java.security.cert java.security.interfaces java.security.spec javax.crypto javax.crypto.interfaces javax.crypto.spec javax.imageio.event javax.imageio.metadata javax.imageio.plugins.bmp javax.imageio.spi javax.imageio.stream javax.management javax.naming javax.naming.directory javax.naming.event javax.naming.ldap javax.naming.spi javax.net javax.net.ssl javax.print javax.security.auth javax.security.auth.callback javax.security.auth.login javax.security.auth.spi javax.security.auth.x500 javax.security.cert javax.security.sasl javax.sound.midi javax.sound.midi.spi javax.sound.sampled javax.sound.sampled.spi javax.sql javax.transaction javax.transaction.xa javax.xml javax.xml.stream javax.xml.stream.events javax.xml.stream.util org.ietf.jgss org.omg.Dynamic org.omg.DynamicAny.DynAnyFactoryPackage org.omg.IOP org.omg.IOP.CodecFactoryPackage org.omg.IOP.CodecPackage org.omg.PortableInterceptor.ORBInitInfoPackage org.omg.PortableServer.CurrentPackage org.omg.PortableServer.portable org.omg.SendingContext org.w3c.dom org.w3c.dom.bootstrap org.w3c.dom.css org.w3c.dom.events org.w3c.dom.html2 org.w3c.dom.ls org.w3c.dom.ranges org.w3c.dom.stylesheets org.w3c.dom.traversal org.w3c.dom.views org.w3c.dom.xpath Thanks! Dave
Re: GJDoc
Andrew John Hughes wrote: Not to put a spanner in the works, but is integrating with ecj possible now? I notice the mail quoted above says 'in the future', and, given this and Tom's original proposal, I'm wondering whether using ecj is reliant on GPLv3. If this is the case, then it won't be available until at least January next year... Yes, I should have addressed this in my previous message. I didn't miss that part :) I plan to isolate the parser behind a well-defined interface. This way, when Gjdoc V2 is ready to replace V1 officially and the licensing issues aren't sorted out by then, it will be easy to swap it out in favor of an alternative. Since adapting the ecj parser for Gjdoc doesn't look like a lot of work, not much would be lost in this case. And by starting out with ecj I can concentrate on architecture and design without having to worry about parsing at this point. So as I see it, the ultimate choice of which parser to use for the final version of Gjdoc V2 can be safely postponed, with ecj as an intermediary solution (and "standard parser" any replacement parser can be compared against). Julian
Re: GJDoc
On Fri, Mar 10, 2006 at 01:40:21PM +0100, Julian Scheid wrote: > So I've finally got a chance to look at the ecj parser yesterday, and > indeed it seems to be perfectly suited for the task. It even comes with > a Javadoc comment parser which appears to be adaptable for Gjdoc's > purposes. Assuming that you're right about the licensing issues, I > agree that this lends itself very well. Thanks for the heads-up. Nice. > I'll look further into this during the next week(s) and keep you up to date. Thanks a lot! TWISTI
Re: GJDoc
Stuart Ballard wrote: On 3/1/06, Julian Scheid <[EMAIL PROTECTED]> wrote: What I'd really like to do is completely replace the parser with a new one written from scratch (preferrably, a generated one.) In addition, the parsing and type resolution steps should be cleanly separated - they are somewhat intermingled at the time. What are the odds of replacing it by calls into ecj's parsing engine, since that's already pretty mature and implemented in pure Java? The licensing problems that may exist at this time seem to be resolvable, as evidenced by the plan to use ecj as gcc's Java frontend in the future... So I've finally got a chance to look at the ecj parser yesterday, and indeed it seems to be perfectly suited for the task. It even comes with a Javadoc comment parser which appears to be adaptable for Gjdoc's purposes. Assuming that you're right about the licensing issues, I agree that this lends itself very well. Thanks for the heads-up. Now one big problem remains, namely integrating the new parser into Gjdoc - as I said, the parsing step is not cleanly abstracted away, so unfortunately this amounts to quiet a lot of work - so much work actually that I am considering doing a complete rewrite of the Gjdoc core instead, something which is long overdue anyway. Given that a lot of last year's work on Gjdoc went into the doclet, which can be retained unmodified, and now that I'm quiet acquainted with the requirements and peculiarities of the system, this isn't as big an undertaking as it may sound at first. I'll look further into this during the next week(s) and keep you up to date. Julian
Re: Apache-friendly licenses
Amazing isn't it, on the technical front there is almost no problem we can't solve, but on the legal side we're hopelessly stuck. Huge amounts of effort goes into resolving licensing issues and all we get are sore heads and people agreeing to go and reinvent their own wheels. We write these words that nobody fully understands. People in the next generation will look back at us in wonder. 'When I use a word,' Humpty Dumpty said, in a rather scornful tone,' it means just what I choose it to mean, neither more nor less.' 'The question is,' said Alice, 'whether you _can_ make words mean so many different things.' Dave
Re: Where's the love?
On Fri, 2006-03-10 at 00:20 -0800, Per Bothner wrote: > Dalibor Topic wrote: > > The only way GNU Classpath would be acceptable for Apache Harmony, afaict > > from > > our dicussions in the past year, would be if the FSF contributed it to the > > ASF, > > and had the ASF manage the project, under the Apache license. Anything else > > is > > non-option for ASF, for a variety of reasons. > > Harmony appears to be basically an attempt at a hostile takeover of the > Free Java movement. They're all in favor of cooperation - as long as > it is 100% on their terms. Complete surrender is all they will accept. > > I hope I'm wrong, but nothing I've heard suggests otherwise. I think that is a bit harsh. Dalibor's description of the project and how Apache deals with it seems correct though. It is clear that a lot of the founders of "Harmony" that came from the GNU Classpath, GCJ, Kaffe, IKVM, etc communities had envisioned a different kind of cooperation. And I think most of use really tried to work hard for the last 9 months to make it work and tried to explain how a community works, what the goals of the different projects were, how we could do this together, etc. Some of us are rightly frustrated that it didn't work out. It isn't like we didn't try very hard and didn't put a lot of energy and effort into it. In the end the new people seemed only interested in doing all things "the Apache way". I don't think the legal/license issues were real blockers. It is just used as an excuse to not work together (for now). It would have been easy to solve if anything to have the code both ASL and GPL compatibility was acceptable to them. I also think we as GNU Classpath community are a bit intimidating. We have so many people working on so many wonderful things which aren't "just java" (.net/mono integration, aot/gcc integration, pushing distribution/packaging issues to the GNU/Linux distributions, creating an platform for innovative research and alternative runtime models, etc). It isn't easy for anybody to grok such a community with millions of lines of free code. And clearly some of the Apache people are proud of their own way of doing things. I just want to add that the FSF has been very helpful in trying to resolve any issues with respect to cooperation. Several of us (Dalibor, Tom and I) have had multiple (hours long) teleconferences with the FSF and ASF people to try to get a common understanding of what the real issues were. And I know a lot of people have tried to explain how we work together, why GPL-compatibility is important to our community, and how to resolve any perceived legal issues. Either by talking directly to people, using teleconferences or by phoning people directly. The lesson to draw from this is probably that if you are talking for months with several people on how to cooperate and the only people that agree with you are the people that you are already working together with and that are actually working on code together, then you might want to just cooperate with the people you are already sharing and working on code with and not with the people only talking and disagreeing. There are also a couple of good things though. It is clear that more people are frustrated with proprietary java as controlled by Sun (and some large JCP companies). That will only help us all to get awareness that we have to solve this problem (hopefully together). And the FSF did listen and incorporated a lot of ideas in the draft of the GPLv3. I believe the language is more clear and the biggest improvement is that there has been a lot of thought about being compatible with other free software licenses that have extra requirements like the ASLv2 and EPL for example. Which means that as soon as GPLv3 is adopted a lot of these "it is incompatible, so we cannot cooperate" discussions will hopefully be over and we will just reuse anything useful and really work together more. I do encourage everybody to take a look at http://gplv3.fsf.org/ Cheers, Mark signature.asc Description: This is a digitally signed message part
call for cooperation: signed jars
Hi, Casey Marshall wrote: On Mar 9, 2006, at 1:35 PM, Philippe Laporte wrote: Casey Marshall wrote: On Mar 9, 2006, at 8:54 AM, Philippe Laporte wrote: Does this library have (ie is in a perfect state) all the security and signing stuff that classpath lacks right now? How about the security audit? I don't understand (and have been largely ignoring this thread, so I may have missed some context). Unfortunate. Despite some people think I'm ugly, you'll come to like me with time...give me a chance Not you in particular; I saw "sablevm" and "license" and that discussion is always pointless. [you may skip this if you are from gcjwebplugin only] I spoke with Peter Mehlitz yesterday. He says it's been going since there was ever Java. I think you guys are wrong in thinking it is pointless. I will repeat myself as much as needed: when Nokia comes around they will want a clear story. I have sent the issue to the FSF. Please use any influcen you have to make Open Source Java great! Now for the VM question. I would very much like, and Peter seemingly agrees (now please don't go shooting at him here. He didn't agree to me citing him. I didn't ask. But I think this is fine. I think you all respect him to some extent), to see the number of Open Source VMs around decrease to around 5-6. What is the leading CLDC open-source VM where one can add proprietary software, link in extra code in whatever way he pleases, pay his hommage to the VM gods (loads of money also helps), and all happening harmoniously? And then the guy can sell the result to other big guys... What is wrong with that? Free software means the Freedom to not start from scratch when you change workplaces. The rest is all political. I propose that you look carefully into the Maemo/Nokia way of Open Source. Now, as to the appropriateness of this topic in this list. I think it is paying serious hommage to Classpath to talk about this here. I got a small pledge down below, and now I'll follow Etienne's advice, which is to take a break. What do you think is missing from Classpath's security infrastructure? support for signed jars, I was told Nope. Classpath has had support for *verifying* signed jar files for some time now; we do currently lack support for *creating* signed jar files (i.e., we don't have a replacement for `jarsigner' yet) but I think Raif said he would look into that. I kinda doubt Harmony has a `jarsigner' yet, unless they were able to panhandle one from IBM or Intel. Good. Now we need verification in Knopflerfish R4 and it is not yet implemented. Is someone willing to join forces to implement it both in KF and in GCJWebplugin? Off for the weekend, Philippe
Re: Where's the love?
On Fri, Mar 10, 2006 at 12:20:02AM -0800, Per Bothner wrote: > Dalibor Topic wrote: > >The only way GNU Classpath would be acceptable for Apache Harmony, afaict > >from > >our dicussions in the past year, would be if the FSF contributed it to the > >ASF, > >and had the ASF manage the project, under the Apache license. Anything > >else is > >non-option for ASF, for a variety of reasons. > > Harmony appears to be basically an attempt at a hostile takeover of the > Free Java movement. They're all in favor of cooperation - as long as > it is 100% on their terms. Complete surrender is all they will accept. > > I hope I'm wrong, but nothing I've heard suggests otherwise. I am sorry if I gave that impression, since that's not the way I experienced it. My impression was that the ASF simply has certain ways to do things, and does not want to change those, since their way basically works fine for them, and they don't think GNU Classpath is worth changing their ways of doing things, as apparently, that's all very tedious and so on. I wouldn't want to imply malice, where buerocratic inertia is a sufficient explanation. cheers, dalibor topic > -- > --Per Bothner > [EMAIL PROTECTED] http://per.bothner.com/
A La Mort Subite
Hi, I had a few photos from our meeting in Brussels on the night before Fosdem in A La Mort Subite. I added them to the pictures Robert uploaded http://developer.classpath.org/pics/fosdem2006/ in the alamortsubite folder. Even though there are only 6, and they are in black and white, I hope they capture the spirit of 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
J2ME - based on classpath
hello, i'm the guy who will implement or build a micro edition based on gnu classpath, it will be my internship at tuwien, i'll work for the same group, which is working on cacao. the result of my work should conform the CLDC/MIDP specs, and CDC (what i learned today ;)) too. the question is if the gnu classpath community will support my plan and provide me a cvs repo or a branch in the repo. i could use the cacao or my own repository too. i.e. the CLDC specs describes some constrains for the VM, those will be implemented in cacao, the limited j2me (according to CLDC/MIDP) packages will be based on classpath and should be part of it. what is the best approach, this aim can be reached? michal
Re: best CACAO release ever
On Fri, 2006-03-10 at 03:50 +0100, Dalibor Topic wrote: > And a long way to becoming the second free runtime to successfully > bootstrap & run OpenOffice.org! Congratulations, great work! Ahh, yes, wanted to mention that. A swiss guy call Juerg Billeter managed to compile OpenOffice.org with CACAO on i386 for (his?) linux distribution called http://www.paldo.org/. Thanks for the debugging work, Juerg! TWISTI
Re: Where's the love?
Dalibor Topic wrote: The only way GNU Classpath would be acceptable for Apache Harmony, afaict from our dicussions in the past year, would be if the FSF contributed it to the ASF, and had the ASF manage the project, under the Apache license. Anything else is non-option for ASF, for a variety of reasons. Harmony appears to be basically an attempt at a hostile takeover of the Free Java movement. They're all in favor of cooperation - as long as it is 100% on their terms. Complete surrender is all they will accept. I hope I'm wrong, but nothing I've heard suggests otherwise. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/
Re: Where's the love?
Casey Marshall gnu.org> writes: > So sure, the FSF could release Classpath under > the disjunction of the GPL and the ASL, if they saw it as fit to. > That would not be what the Apaches would want. Dual licensing is not acceptable for the ASF, as far as I have been told. The only way GNU Classpath would be acceptable for Apache Harmony, afaict from our dicussions in the past year, would be if the FSF contributed it to the ASF, and had the ASF manage the project, under the Apache license. Anything else is non-option for ASF, for a variety of reasons. cheers, dalibor topic
