Re: J2ME-CDC-like library and classes dependency problems
Kenny Su 提到:
>PS2. For the "class not found" problem, something is strange, it seems that if
>you want to
>skip some classes to build and add them to the standard.omit, if it has
>depentency problems
>in it, the standard.omit doesn't work, and all the classes will be compiled.
>But sometimes
>it prints out "class not found". I need to look more deeply and check it again.
>
>
>
>
I found the problem why standard.omit doesn't work. The version of
classpath I download is 0.91.
There has a "../gnu/test/.*$" in standard.omit, but the "../" should be
skipped, because I check the
classes.1 file, there is no "../ " in it, when "gen-classlist.sh" doing
"grep -v ${filexp} < ${top_builddir}/lib/classes.1 >
${top_builddir}/lib/classes.tmp", the classes added in standard.omit
will not be skipped.
So, I add something like the following syntax in standard.omit, it works.
[EMAIL PROTECTED] lib]$ cat standard.omit
javax/naming/.*$
gnu/test/.*$
gnu/javax/print/.*$
java/awt/print/.*$
javax/print/.*$
gnu/java/awt/peer/swing/.*$
gnu/javax/swing/.*$
javax/swing/.*$
---
But there are still some dependency problem in it, because I can not
remove all the swing or print classes.
Some of them still keep in the glibj.zip. A great analysis tool is still
needed.
--
Po-Chou Su
Digital Home Networking Department, P100,
Computer & Communications Research Laboratories,
Industrial Technology Research Institute
TEL: +886-6-3847086 FAX: +886-6-3847182
本信件可能包含工研院機密資訊，非指定之收件者，請勿使用或揭露本信件內容，並請銷毀此信件。
This email may contain confidential information. Please do not use or disclose
it in any way and delete it if you are not the intended recipient.
J2ME-CDC-like library and classes dependency problems
Hi All: I am trying to modularize the classpath library and making it closely to CDC-based library. So what I am doing now is to add four configure options, it will something like --with-cdc-enable --with-fb-enable or --with-pbp-enable options. The standard.omit mechanism is good to reach this goal, it can skip to compile the useless classes and we can just add four profiles in classpath without changing any source codes. But I find some classes in classpath have dependency problems, such as javax.swing is used by gnu.javax.print, javax.accessibility or something else. If I skip to compile javax.swing, it will make "class not found" errors from other classes which need the javax.swing. So I think I need a classes dependency analysis tool to know how many depentency problems in it, and try to keep the classes/packages needed by other classes. For example, We can keep some swing classes for doing not modify other classes APIs. I don't want to change any source code about classpath, all I want to do is to make this task as simply as possible. Is there anyone who can tell me any useful tools to analyze the classpath library. I have tried Jdpend with text mode and structure101, but all these tools just can show me 1 level dependency relations, such as I just can know javax.swing is used by gnu.javax.print with those tools, but I can not know which class needs gnu.javax.print, it will be something like this "ServiceUIFactory.java (javax/print) -> PrinterDialog.java (gnu/javax/print) -> ?? -> ?? (-> means "used by"). If I want to know ??, I need to trace the code again but not generated by the tools, it is not efficiently. Any suggestions ? PS. I don't know if there anyone who is doing it now, if yes, please let me know. I think it is useful if classpath library has some configure options to build library more flexible, especially in embedded environment. PS2. For the "class not found" problem, something is strange, it seems that if you want to skip some classes to build and add them to the standard.omit, if it has depentency problems in it, the standard.omit doesn't work, and all the classes will be compiled. But sometimes it prints out "class not found". I need to look more deeply and check it again. %;+H%s%i/`%]'t$u,c0|>w1K8j0T!A+D+|)w$'&,%s*L!A=P$E(O%N)N4&ES%;+H%s$:.e!A(C=P>P74&9+H%s!C This email may contain confidential information. Please do not use or disclose it in any way and delete it if you are not the intended recipient.
Re: Mauve reports
Bryce McKinlay wrote: Roman Kennke wrote: Also, the ability to see/track when a failure started occurring could be very useful. That way we could easily match up new failures with patches that caused them. Hmm, that's an interesting feature indeed. We would have to keep diffs between versions around and teach the script to parse and display them somehow. I must think about this a little. It should become a bit easier with the new test harness. When you treat 1 test = 1 failure, each pass/fail can be uniquely identified, and regressions can be distinguished easily from new test cases. Yes, I posted a patch that makes the new harness the default and removes the old one to [EMAIL PROTECTED] yesterday. No one has responded thus far, but I'd appreciate comments. Tom
Re: [cp-patches] RFC: qt-peer: remove INIT_LOAD_LIBRARY
On Thu, Jun 08, 2006 at 05:13:54PM -0600, Tom Tromey wrote: > > "Jeroen" == Jeroen Frijters <[EMAIL PROTECTED]> writes: > > Jeroen> IKVM doesn't use it, because it replaces all VM classes that > Jeroen> have native methods. As a long term goal, I'd still like to > Jeroen> get rid of the Configuration class altogether, but I don't > Jeroen> know if others support that goal too ;-) > > Yeah, I do. /me too. cheers, dalibor topic > > Tom >
Re: Mauve reports
Roman Kennke wrote: Also, the ability to see/track when a failure started occurring could be very useful. That way we could easily match up new failures with patches that caused them. Hmm, that's an interesting feature indeed. We would have to keep diffs between versions around and teach the script to parse and display them somehow. I must think about this a little. It should become a bit easier with the new test harness. When you treat 1 test = 1 failure, each pass/fail can be uniquely identified, and regressions can be distinguished easily from new test cases. Bryce
Re: Mauve reports
On Fri, 2006-06-09 at 00:02 +0200, Roman Kennke wrote:
> Hi Andrew,
>
> Am Donnerstag, den 08.06.2006, 22:01 +0100 schrieb Andrew John Hughes:
> > On Thu, 2006-06-08 at 16:13 +0200, Roman Kennke wrote:
> > > FYI: I have set up my old Mauve report script on builder.classpath.org
> > > to generate nice HTML for the Mauve results:
> > >
> > > http://builder.classpath.org/mauve/mauvereport.cgi
> > >
> > > This really is only a frontend to:
> > > http://builder.classpath.org/mauve/mauve-jamvm
> > >
> > > These results normally get updated continuously, so the frontend should
> > > always report the latest results that have been built sucessfully.
> > >
> > > In the future we will (hopefully) add more compiler/VM(/classlib)
> > > combinations so that we can compare the results to others.
> > >
> > > I welcome suggestions for improvements of this frontend.
> > >
> > > /Roman
> > >
> >
> > Great work; I wondered what had happened to these.
>
> :-) This was actually one of my first contributions to Classpath when I
> started. Then they got lost somehow, with the plan to setup on builder,
> what never happened - until now.
>
> > But should I only be seeing gcj+jamvm?
>
> Of course not. But atm builder only generates mauve reports for this
> setup. We really should add more compilers/VMs soon... Any help with
> this is greatly appreciated.
>
> /Roman
>
Yes, but with three different variations: old release, HEAD and future
release (although the latter is obviously turned off at present). I
don't know which your page is showing, but there are currently two
active sets of Mauve results.
Cheers,
--
Andrew :-)
Please avoid sending me Microsoft Office (e.g. Word, PowerPoint)
attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
If you use Microsoft Office, support movement towards the end of vendor
lock-in:
http://opendocumentfellowship.org/petition/
"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
Escape the Java Trap with GNU Classpath!
http://www.gnu.org/philosophy/java-trap.html
public class gcj extends Freedom implements Java { ... }
signature.asc
Description: This is a digitally signed message part
Re: Mauve reports
> "Roman" == Roman Kennke <[EMAIL PROTECTED]> writes: Roman> Hmm, that's an interesting feature indeed. We would have to keep diffs Roman> between versions around and teach the script to parse and display them Roman> somehow. I must think about this a little. We've already got a script to do this for some cases. That is how we mail out regression reports. Tom
Re: Would nice, if you publish your code also under AL2
I came to the same conclusion like Audrius and found http://www.gnu.org/philosophy/freedom-or-power.html a good reason for sticking to the copyleft idea. cya Robert signature.asc Description: OpenPGP digital signature
Re: Mauve reports
Hi Bryce, Am Donnerstag, den 08.06.2006, 16:38 -0400 schrieb Bryce McKinlay: > Roman Kennke wrote: > > These results normally get updated continuously, so the frontend should > > always report the latest results that have been built sucessfully. > > > > In the future we will (hopefully) add more compiler/VM(/classlib) > > combinations so that we can compare the results to others. > > > > I welcome suggestions for improvements of this frontend. > > > > Sweet! I think it may be more useful to only report the failures. > Scrolling through the many thousands of PASSes isn't really very > interesting :) Yeah, this should be easily implemented. > Also, the ability to see/track when a failure started occurring could be > very useful. That way we could easily match up new failures with patches > that caused them. Hmm, that's an interesting feature indeed. We would have to keep diffs between versions around and teach the script to parse and display them somehow. I must think about this a little. /Roman -- “Improvement makes straight roads, but the crooked roads, without Improvement, are roads of Genius.” - William Blake signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
[Bug classpath/27966] New: ConfigFileParser#validateClassName(String)
cn.split(".") in
gnu.javax.security.auth.login.ConfigFileParser#validateClassName(String) may be
incorrect. It should be "\\.".
--
Summary: ConfigFileParser#validateClassName(String)
Product: classpath
Version: 0.91
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: classpath
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ujihara at aurora dot dti dot ne dot jp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27966
___
Bug-classpath mailing list
Bug-classpath@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-classpath
Re: Mauve reports
Hi Andrew, Am Donnerstag, den 08.06.2006, 22:01 +0100 schrieb Andrew John Hughes: > On Thu, 2006-06-08 at 16:13 +0200, Roman Kennke wrote: > > FYI: I have set up my old Mauve report script on builder.classpath.org > > to generate nice HTML for the Mauve results: > > > > http://builder.classpath.org/mauve/mauvereport.cgi > > > > This really is only a frontend to: > > http://builder.classpath.org/mauve/mauve-jamvm > > > > These results normally get updated continuously, so the frontend should > > always report the latest results that have been built sucessfully. > > > > In the future we will (hopefully) add more compiler/VM(/classlib) > > combinations so that we can compare the results to others. > > > > I welcome suggestions for improvements of this frontend. > > > > /Roman > > > > Great work; I wondered what had happened to these. :-) This was actually one of my first contributions to Classpath when I started. Then they got lost somehow, with the plan to setup on builder, what never happened - until now. > But should I only be seeing gcj+jamvm? Of course not. But atm builder only generates mauve reports for this setup. We really should add more compilers/VMs soon... Any help with this is greatly appreciated. /Roman -- “Improvement makes straight roads, but the crooked roads, without Improvement, are roads of Genius.” - William Blake signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Mauve reports
Hi Archie, Am Donnerstag, den 08.06.2006, 11:55 -0500 schrieb Archie Cobbs: > David Gilbert wrote: > > Roman Kennke wrote: > >> These results normally get updated continuously, so the frontend should > >> always report the latest results that have been built sucessfully. > >> > >> In the future we will (hopefully) add more compiler/VM(/classlib) > >> combinations so that we can compare the results to others. > > I'd like to get JCHEVM (the Harmony edition of JCVM) included.. > is that possible? Let me know what I can do to help if so. This should be possible. Whenever me or Mark or somebody else finds time to fiddle with the build scripts we will include this. OTOH, it might be possible that Mark gives you access to the machine so you can set this up yourself? /Roman -- “Improvement makes straight roads, but the crooked roads, without Improvement, are roads of Genius.” - William Blake signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: Would nice, if you publish your code also under AL2
On Jun 8, 2006, at 6:56 AM, theUser BL wrote: If you write completly classes for GNU Classpath at your own and they don't depend on other GNU Classpath specific files, it would be nice, if you would also publish it under the Apache License 2. I think it would be nice, to bring the Harmony- and GNU Classpath- project more together. I would, personally, never want the code I contribute to GNU Classpath licensed under anything except the GPL+exception. The Harmony people chose to not cooperate with us, and I'm not interested in bending over backward for them, especially when it probably won't make any difference. Classpath's license is entirely sufficient. It ensures that Classpath will remain free, without unnecessarily limiting those who want to use it, even for non-free applications. PGP.sig Description: This is a digitally signed message part
Re: Mauve reports
On Thu, 2006-06-08 at 16:13 +0200, Roman Kennke wrote:
> FYI: I have set up my old Mauve report script on builder.classpath.org
> to generate nice HTML for the Mauve results:
>
> http://builder.classpath.org/mauve/mauvereport.cgi
>
> This really is only a frontend to:
> http://builder.classpath.org/mauve/mauve-jamvm
>
> These results normally get updated continuously, so the frontend should
> always report the latest results that have been built sucessfully.
>
> In the future we will (hopefully) add more compiler/VM(/classlib)
> combinations so that we can compare the results to others.
>
> I welcome suggestions for improvements of this frontend.
>
> /Roman
>
Great work; I wondered what had happened to these.
But should I only be seeing gcj+jamvm?
Cheers,
--
Andrew :-)
Please avoid sending me Microsoft Office (e.g. Word, PowerPoint)
attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
If you use Microsoft Office, support movement towards the end of vendor
lock-in:
http://opendocumentfellowship.org/petition/
"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
Escape the Java Trap with GNU Classpath!
http://www.gnu.org/philosophy/java-trap.html
public class gcj extends Freedom implements Java { ... }
signature.asc
Description: This is a digitally signed message part
Re: Mauve reports
Roman Kennke wrote: These results normally get updated continuously, so the frontend should always report the latest results that have been built sucessfully. In the future we will (hopefully) add more compiler/VM(/classlib) combinations so that we can compare the results to others. I welcome suggestions for improvements of this frontend. Sweet! I think it may be more useful to only report the failures. Scrolling through the many thousands of PASSes isn't really very interesting :) Also, the ability to see/track when a failure started occurring could be very useful. That way we could easily match up new failures with patches that caused them. Bryce
[Bug classpath/22915] Indirect use of natives in java.io package
--- Comment #4 from gnu_andrew at member dot fsf dot org 2006-06-08 20:05 --- I've posted the patch here. I got this to compile, but it breaks the bootstrap cycle somewhere with both JamVM and Cacao. If someone wants to take a look, please do. I'm afraid personally I'll have to put it on hold until after the Summer of Code. -- gnu_andrew at member dot fsf dot org changed: What|Removed |Added AssignedTo|gnu_andrew at member dot fsf|unassigned at gcc dot gnu |dot org |dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22915 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
[Bug classpath/22915] Indirect use of natives in java.io package
--- Comment #3 from gnu_andrew at member dot fsf dot org 2006-06-08 20:04 --- Created an attachment (id=11641) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11641&action=view) VMFileChannelImpl patch (not fully working) This compiles, but currently breaks bootstrap with Cacao and JamVM; anyone who wants to work this out is more than welcome as I won't be able to work on it for the next few months. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22915 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
Re: Java2D Headless
FYI: I am working on a set of AWT peers on top of Escher (an X11 protocol impl in pure java). It has no dependencies at all, except for an X server running somewhere on the net (localhost for best performance of course). Headless mode could easily be supported by this, even without X server then. The drawing is all performed in Java (so far), which doesn't give best performance, but should be sufficient for the occasional chart. Even fonts are handled all in Java. However, this work is far from beeing complete. At the moment it is carried out outside of GNU Classpath because of the dependency to Escher. If there is interest, we could include it (with Escher going into external/ ). Most stuff is already implemented. The most important missing piece for now is proper font hinting, so if anybody is knowledgable in that area and wants to help, please ping me. I try to polish up the current code and upload it somewhere for public review soon. Cheers, Roman Am Mittwoch, den 31.05.2006, 15:21 +0200 schrieb Juerg Lehni: > I was reading about the Java2D rewrite and was wondering if there is > more information about this available now. > > http://developer.classpath.org/pipermail/classpath/2006-January/ > 20.html > > I assume this is the work on the new CairoGraphics2D. Will this > support headless mode? Will it still rely on Gtk, or be seperated > from it? At the moment my gcj setup on OS X does not seem to support > the java.awt.headless=true switch (gcj 4.1.1, classpath 0.20). > > For the use in server environments, classpath should support Java2D > in headless mode, without relying on any Gtk libraries, just Cairo. > > Is this planed? > > Jürg > -- “Improvement makes straight roads, but the crooked roads, without Improvement, are roads of Genius.” - William Blake signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Re: [crypto] OAEP, EME-OAEP, RC4
John Pritchard wrote: > A couple classes I'm moving into classpath::crypto/ciphers: OAEP, > EME-OAEP (and it looks like there's no RC4 there). ARCFour is there, check the prng dir. -- Morgon Kanter <[EMAIL PROTECTED]>
Re: Would nice, if you publish your code also under AL2
Well, not everybody writes the GPL - licensed code just because they do not have any other choice... some still read http://www.gnu.org/philosophy/why-copyleft.html. Audrius
Re: I've wrote some classes - what sould I do with it?
On 6/8/06, Mark Wielaard <[EMAIL PROTECTED]> wrote: Hi Maciej, On Tue, 2006-06-06 at 21:59 +0200, Maciej Piechotka wrote: > I've started writting java.util.concurrent classes. I've finish few of > them, but they are undocummented and unchecked (I have no java 1.5 > compiler). > What should I do with it - write, check, document or just send/ Cool thanks. We were hoping to use the public domain code from Doug Lea and hist jsr166 group. Tom already prepared a patch for that: http://thread.gmane.org/gmane.comp.java.classpath.patches/8896/focus=8896 Could you take a look how your work might fit into that? Thank you I'll connect - I've start java.concurrent.locks. For now you can use ecj (distributed as gcj compiled antive binary with most modern GNU/Linux distros these days) if you need 1.5 language support. I've found it. I'm using now gcj + ecj and it works not slower then orgianl sun and not take more memory (normal .class files). Also take a look at the developer wiki: http://developer.classpath.org/mediation/ In particular developer.classpath.org/mediation/ClasspathFirstSteps which should give you a good introduction to the code, customs and community. Yes . Thank you. Cheers, Regards.
Re: Would nice, if you publish your code also under AL2
On Jun 8, 2006, at 6:56 AM, theUser BL wrote: If you write completly classes for GNU Classpath at your own and they don't depend on other GNU Classpath specific files, it would be nice, if you would also publish it under the Apache License 2. I think it would be nice, to bring the Harmony- and GNU Classpath- project more together. Why not the opposite way, if the Harmony folks put their code under GPL+extension instead? Classpath is much older than Harmony and from the sound of it, Harmony is a dumping ground for companies like IBM and Intel which is just wrong. -- Pinski
Re: Would nice, if you publish your code also under AL2
On Thu, Jun 08, 2006 at 01:56:11PM +, theUser BL wrote: > If you write completly classes for GNU Classpath at your own and they don't > depend on other GNU Classpath specific files, it would be nice, if you > would also publish it under the Apache License 2. That's not sufficient. Please read the Harmony legal framework for contributors. I know you mean well, but you need to make yourself more familiar with the way how an ASF project works. Harmony has some specific rules wrt to accepting contributions. It can't just pick up arbitrary code, no matter how it was licensed. That's very similar to how GNU Classpath works. If you want to contribute to both, that's easily possible, as the way both projects are set up allows for it nicely. It just means following the proper legal procedures for each project, which are actually somewhat different. cheers, dalibor topic > I think it would be nice, to bring the Harmony- and GNU Classpath-project > more together. > > Have also a look at > http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200606.mbox/[EMAIL > PROTECTED] > > > Greatings > theuserbl > > >
Re: Mauve reports
David Gilbert wrote: Roman Kennke wrote: These results normally get updated continuously, so the frontend should always report the latest results that have been built sucessfully. In the future we will (hopefully) add more compiler/VM(/classlib) combinations so that we can compare the results to others. I'd like to get JCHEVM (the Harmony edition of JCVM) included.. is that possible? Let me know what I can do to help if so. Some details... - It's easy to download the latest source, but you'll need an SVN client - The SVN build requires the usual autofoo stuff (automake, autoconf, etc). There is a script included that runs everything (including ./configure). - Still targeted at Classpath 0.90, due to the fatal bug in Classpath 0.91 that makes startup fail with a NullPointerException. I have a patch for 0.91 though (it's currently checked in as an unapplied patch). Thanks, -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: Mauve reports
Roman Kennke wrote: FYI: I have set up my old Mauve report script on builder.classpath.org to generate nice HTML for the Mauve results: http://builder.classpath.org/mauve/mauvereport.cgi Nice! This really is only a frontend to: http://builder.classpath.org/mauve/mauve-jamvm Does anyone know why some tests don't appear in there (for example, tests for the MetalLookAndFeel class)? These results normally get updated continuously, so the frontend should always report the latest results that have been built sucessfully. In the future we will (hopefully) add more compiler/VM(/classlib) combinations so that we can compare the results to others. I welcome suggestions for improvements of this frontend. /Roman Can someone update the GNU Classpath home page to point to this report, instead of the one that I run manually (which is the current link on the home page)? Regards, Dave
Re: Would nice, if you publish your code also under AL2
On Thu, 2006-06-08 at 13:56 +, theUser BL wrote: > If you write completly classes for GNU Classpath at your own and they don't > depend on other GNU Classpath specific files, it would be nice, if you would > also publish it under the Apache License 2. > I think it would be nice, to bring the Harmony- and GNU Classpath-project > more together. Well, in the views of this developer: It would be nice if Apache Harmony chose to use my code under the terms of the License I've put it under. The license is not incompatible with theirs, and it was offered under that license when they started that project. However, they did not want that license. They didn't really want to discuss alterations to that license either, even though it was offered. The reason for that was that, in practice, what it was all about was that the Apache Harmony folks didn't want my code. Sure, they'll take it if I hand it over unconditionally, but they're not prepared to discuss terms with me or anyone representing me. But basically they wanted their own class library and total control over it. They didn't say it outright, but tended to refer to licensing, VM interfaces, and fancy but meaningless pictures and abstract designs showing equally abstract problems with Classpath. Or by referring to made-up "rules" on how ASF projects can't have non-ASL dependencies. This was all a smokescreen for the actual reality that Harmony never actually intended to use GNU Classpath, although they did manage to convince some of us that they would.. At least, for a while. So while Geir Magnusson may have given pretty speeches about "working with the community", his definition of that phrase is "How much code are you prepared to hand over, no strings attached?". Unfortunately, some people though that he meant "working with" as in a give-and-take process, involving compromises and negotiation. They also believed that meant being upfront and honest about your intentions and motives. Those people are pretty disappointed today. So, what you're suggesting here is that, because I'm "nice", I should go ahead and give them what they want. And what they want, given that they don't want our code under its existing license, nor do they seem prepared to discuss the matter, is that we either relicense under the ASL or simply fuck off. Personally, I don't really feel very inclined to doing that. After being mislead and basically having my concerns ignored, why should I? The misleading is an ongoing process, as you can see by Geir's list post. He's quite the politician. Lots of pretty words, but never any concrete proposals or straight answers. Read his post closely. Do you see any proposals on HOW we should work together? On WHAT we can do to work together? Saying that individual developers can do what they want with their code is not an answer for either his project our ours. Anyone can say "I'd really like it if we could all work together". Who would disagree with that kind of sentiment under any circumstance? But as under any circumstance, what the REAL question is: What compromises are you prepared to make to work together? /Sven (who's opinions aren't necessarily representative)
Re: Mauve reports
> "Roman" == Roman Kennke <[EMAIL PROTECTED]> writes: Roman> FYI: I have set up my old Mauve report script on builder.classpath.org Roman> to generate nice HTML for the Mauve results: Thanks! Roman> http://builder.classpath.org/mauve/mauvereport.cgi I made a link to this from the builder's main web page. Tom
Re: Would nice, if you publish your code also under AL2
Il giorno gio, 08/06/2006 alle 13.56 +, theUser BL ha scritto: > I think it would be nice, to bring the Harmony- and GNU Classpath-project > more together. Hi! Though sometimes I use the AL2 (see http://limamobilelibrary.dev.java.net for an example), I still prefer to use the old good GPL v2, without even the "at your option" clause. At least, until GPL v3 will be finalized. Why? While the idea behind the GPL (freedom to the users as well as to the developers of the code) is great, I want to control what is done with my software. I realize that the GPL v2 is the best option right now to: 1. Make the software available to everybody 2. Without the risk of someone to stole the code and make a "commercial" only version without me at least being informed of that. There are a lot of other reasons as well, but these are mine (at least the most important for me). At a general level, there is also the fact that Community is a pool of great code, ideas and collaboration. But this is, in general, together the driving factor and the side effect of all the OSI Approved licenses (GPL v2 in primis, but other licenses as well including the AL2). Why I would not give my code (I know, actually few and maybe useless lines in classpath, but still a contribution) as AL2, right now? The reason is that I don't want Sun to use my code, if I can't use Sun's code. Don't misunderstand me, I would be really glad to give it for free if they would be nice enough to ask. I wouldn't ever desire a name lost in a ChangeLog. But actually, If I read 3 lines of code from a Java class, than I'm tainted, I can't contribute to classpath. While they have the right to do so, I want to have the same right with my code. I think, that right now, this right is only guaranteed by the GPL v2. Apart for that, I agree that it would be nice to see more collaboration, so I hope a fix on the license model can guide us through the correct path (provided that A. what I said before remains true; B. the advantage for the community supercedes the disadvantage of giving away condition A). This is my personal point of view, and is subject to change without notice ;) > Greatings > theuserbl Mario -- Lima Software, SO.PR.IND. s.r.l. http://www.limasoftware.net/ pgp key: http://subkeys.pgp.net/ Please, support open standards: http://opendocumentfellowship.org/petition/ http://www.nosoftwarepatents.com/ signature.asc Description: Questa è una parte del messaggio firmata digitalmente
[Bug swing/27833] Strange repaint bugs after Graphics2D update
--- Comment #29 from david dot gilbert at object-refinery dot com 2006-06-08 15:10 --- (In reply to comment #27) > However, I think the patch is correct > and most likely it is just revealing another bug elsewhere. I'll file a > separate bug once I've looked at it some more... I think the JFreeChart problem is in the setTransform() method, I filed a separate bug report (and Mauve tests) for this: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27960 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27833 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
[Bug awt/27960] New: CairoGraphics2D.setTransform() doesn't update clip
I wrote a couple of Mauve tests to check the effect of the setTransform() and transform() methods on the clip for a Graphics2D: gnu.testlet.java.awt.Graphics2D.setTransform gnu.testlet.java.awt.Graphics2D.transform Both methods should impact the clip area, but in our CairoGraphics2D implementation the setTransform() method doesn't change the clip area at all. I believe this is the cause of the drawing problems in JFreeChart. -- Summary: CairoGraphics2D.setTransform() doesn't update clip Product: classpath Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P3 Component: awt AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: david dot gilbert at object-refinery dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27960 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
Re: Native layer
Hi Guilhem, On Tue, 2006-06-06 at 22:34 +0200, Guilhem Lavaux wrote: > I have a working native layer branch on jamvm (though I have not really > counted if there was a regression I know the one from kaffe and the > important ones in mauve are passing on standard linux). I will propose > before the end of the week a patch against HEAD for a merge. I suggest > people to take a look at the state of the NATIVE-LAYER branch and tell > me if they see huge trouble with it. There are still a lot to do but the > current state get rid of the target layer. I would like to remove the > other remaining direct syscalls from the rest of the JNI code for clarity. Yeah, it is probably a good idea to merge it back now otherwise you will keep having to merge things back and forth. I haven't reviewed the current branch code yet, but I did follow your patches. It is essential that if this is merged there are no mauve regressions for runtimes that use the classpath JNI code. If you need a help verifying that please do post a patch NATIVE-LAYER -> trunk somewhere so others can help you test that. > It's a pain to merge HEAD to NATIVE-LAYER by the way (too many patches > ;) )... Sorry about that. Lets ask everybody to stop working so hard :) It is indeed kind of amazing how many patches are written each day now. I have trouble keeping on top of it all myself at times. 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
Re: I've wrote some classes - what sould I do with it?
Hi Maciej, On Tue, 2006-06-06 at 21:59 +0200, Maciej Piechotka wrote: > I've started writting java.util.concurrent classes. I've finish few of > them, but they are undocummented and unchecked (I have no java 1.5 > compiler). > What should I do with it - write, check, document or just send/ Cool thanks. We were hoping to use the public domain code from Doug Lea and hist jsr166 group. Tom already prepared a patch for that: http://thread.gmane.org/gmane.comp.java.classpath.patches/8896/focus=8896 Could you take a look how your work might fit into that? For now you can use ecj (distributed as gcj compiled antive binary with most modern GNU/Linux distros these days) if you need 1.5 language support. Also take a look at the developer wiki: http://developer.classpath.org/mediation/ In particular developer.classpath.org/mediation/ClasspathFirstSteps which should give you a good introduction to the code, customs and community. Cheers, Mark signature.asc Description: This is a digitally signed message part
[crypto] OAEP, EME-OAEP, RC4
dear reader, A couple classes I'm moving into classpath::crypto/ciphers: OAEP, EME-OAEP (and it looks like there's no RC4 there). If you're working on any of these, please let me know. cheers John http://www.syntelos.com/src/com/syntelos/foam/OAEP.java.html http://www.syntelos.com/src/com/syntelos/foam/OEAP.java http://www.syntelos.com/src/com/syntelos/foam/EOAE.java.html http://www.syntelos.com/src/com/syntelos/foam/EOEA.java http://www.syntelos.com/src/com/syntelos/foam/RC4.java.html http://www.syntelos.com/src/com/syntelos/foam/RC4.java
Mauve reports
FYI: I have set up my old Mauve report script on builder.classpath.org to generate nice HTML for the Mauve results: http://builder.classpath.org/mauve/mauvereport.cgi This really is only a frontend to: http://builder.classpath.org/mauve/mauve-jamvm These results normally get updated continuously, so the frontend should always report the latest results that have been built sucessfully. In the future we will (hopefully) add more compiler/VM(/classlib) combinations so that we can compare the results to others. I welcome suggestions for improvements of this frontend. /Roman -- “Improvement makes straight roads, but the crooked roads, without Improvement, are roads of Genius.” - William Blake signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
Would nice, if you publish your code also under AL2
If you write completly classes for GNU Classpath at your own and they don't depend on other GNU Classpath specific files, it would be nice, if you would also publish it under the Apache License 2. I think it would be nice, to bring the Harmony- and GNU Classpath-project more together. Have also a look at http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200606.mbox/[EMAIL PROTECTED] Greatings theuserbl
Would nice, if you publish your code also under AL2
If anybody at GNU Classpath writes files for GNU Classpath, which are completly written by its own and which don't depends ob GNU Classpath specific classes, it would be nice, if you also could publish it under the Apache License 2. So, that this brings the Harmony- and the GNU Classpath-project a little bit more together. Also have a look at http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200606.mbox/[EMAIL PROTECTED] Greatings theuserbl
Re: JavaView runs with GNU Classpath
theUser BL wrote: If "Show Backside" is enabled, the backside isn't shown, and if it is disabled with GNU Classpath the backside is shown. FYI http://www.m-w.com/dictionary/backside -- 犬 Chris Burdess "They that can give up essential liberty to obtain a little safety deserve neither liberty nor safety." - Benjamin Franklin PGP.sig Description: This is a digitally signed message part
[Bug awt/27917] Massive memory leak in Graphics2D image operations
--- Comment #9 from hendrich at informatik dot uni-hamburg dot de 2006-06-08 12:25 --- (In reply to comment #8) > This seems to be a deadlock happening when the HideCursorManager sets the > cursor at some inconvenient time. I haven't debugged it fully yet. Good catch! This sounds very possible. When I tried gdb on this, I just got lots of waiting threads, but didn't notice any of the cursor hiding stuff. > It probably > deserves its own bug report. Is there an easy way to disable the > HideCursorManager? Not yet... (it is probably easiest to uncomment all setCursor calls in Niffler.java). I hope that get/setCursor is considered a thread-safe AWT operation. Using SwingUtilities.invokeLater would probably not help, or would it? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27917 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
RE: JavaView runs with GNU Classpath
Yesterday I have tested the ClosedSource program JavaView (http://www.javaview.de) on jamvm and cacao with the GNU Classpath Snapshot from yesterday. And it works fine. Now I have also nice screenshots of it running with GNU Classpath: http://user.web-gear.com/theuserbl/Bildschirmphoto6.png http://user.web-gear.com/theuserbl/Bildschirmphoto12.png Only some fields are not drawn. It looks like that there is a problem of GNU Classpath KJava2D with negative numbers, I think. I have now seen, that it is an other problem. As you can see at Bildschirmphoto12.png, it works fine. But in the AWT-Menu in Methods -> Show -> Show Backside is at default activated on GNU Classpath and Suns Java. But with GNU Classpath it is the other way around. If "Show Backside" is enabled, the backside isn't shown, and if it is disabled with GNU Classpath the backside is shown. A little mystical. Greatings theuserbl
