On 17/01/2008, Dalibor Topic <[EMAIL PROTECTED]> wrote: > Andrew John Hughes schrieb: > >> I take it the Qt peers mentioned are ones that ship with Kaffe as > >> opposed to the Classpath ones (which are also dormant)? If there's > >> anything worth salvaging, it might be best to throw it over the wall > >> to Classpath. > >> > Yes, they are. I think the interesting part is that they also worked > with Qtopia, but I believe > there are patches in the Classpath bug tracker for the ones in Classpath > to make them build > with Qtopia, too. >
Yeah, we really need to get on top of our bugs and mislaid patches... :( > Concentrating on one Qt peer implementation, provided someone cares > about maintaining them, > is better then having two different efforts, and GNU Classpath's > AWT/Swing is a lot better than > what old Kaffe AWT has to offer. Yeah, I was thinking more if there was any code worth porting to the GNU Classpath peer framework. > >> * GNU MP big math > >> > >> I'd like to remove the feature and let GNU Classpath handle it for the > >> next release. > >> > >> There is a patch from Raif for GNU Classpath that proposes an > >> implementation of that feature for GNU Classpath, it would need someone to > >> move it to the point > >> where it could be merged into Classpath proper. The PR is Classpath/28664 > >> in Classpath's > >> bug tracker. > >> > >> The feature belongs into a class library, rather than a VM, in my opinion. > >> > >> > > > > The bug seems to have been inactive for the best part of a year and a > > half. Where's the patch you mention? Has it been applied to > > Classpath? It's not attached to the bug tracker or mentioned there. > > > It hasn't been applied yet. It's waiting for someone to review it. See > http://article.gmane.org/gmane.comp.java.classpath.patches/11222/match=classpath+gnu+mp+28664 > for the last version. I'll try and take a look. From that mail, it seems it will at least need moving to a VM interface. > > > With both zip and GNU MP support, there's a question of whether a > > native or Java-based implementation is better. Classpath currently > > has Java-based implementations of both, which is an advantage for > > Java-based VMs over OpenJDK, etc. but a performance issue for other > > VMs such as Kaffe. > Depends on the situation. For example, using Classpath's pure java zip > on x86, with jit3, is about > as fast as using the zlib zip for me. I think choice is interesting for > the situations where people deploy > the free VMs on platforms with limited resources, but from a project > management perspective, the > less class library code is in a VM project, the better. ;) > > Maybe we need to provide alternatives perhaps via > > a property that can be set by the VM? (Doing it at configure time > > would make things tricky as the user or distro then has to choose, and > > the VM would have to determine how Classpath was built, etc.) > I don't think so. In general, doing that dynamically makes it all very > complicated, and provides no > benefit for the situations where you want to use the alternative > implementation, as you'd want to > configure out the features you don't use on limited devices anyway. > > Let the distro / deployer make their choices, they should know what they > are doing best. They > can always simply build a couple of different Classpath configurations > to play with, and build a > VM against each, if they want to test configurations out. > Yeah, you're probably right :) In the case of GMP, it should probably be the default once more throughly tested as I'm guessing there are quite a few holes in our implementation. > cheers, > dalibor topic > Cheers, -- Andrew :-) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net _______________________________________________ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe