[kaffe] Re: Notes on kaffe (GNU Classpath integration) todo items
Tom Tromey <[EMAIL PROTECTED]> writes: > Mark> - Security/Crypto - Choose default provider > Mark> (kaffe, GNU Classpath and/or GNU Crypto). > > For libgcj we've settled on recommending GNU Crypto as the choice (we > don't ship it by default). GNU Crypto is actively maintained by > friendly people -- big pluses. I should mention here that GNU Classpath also has settled upon recommending GNU Crypto. Brian -- Brian Jones <[EMAIL PROTECTED]> ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [Rxtx] Implementing javax.comm for free software java implementations(Was: Re: [kaffe] Notes on kaffe (GNU Classpath integration) todo items)
On Mon, 14 Jul 2003, Dalibor Topic wrote: > Hi Trent, > > Trent Jarvi wrote: > > > We'd be more than willing to work with Classpath and or Kaffe to get this > > working. RXTX 2.1 implements CommAPI from the top down but is in package > > gnu.io to avoid confusion with Sun's impementation. > > > > RXTX 2.0 implements the lower portion of CommAPI and could be made to work > > with the upper portion offered in Kaffe. The Kaffe shell classes did look > > acceptable when I read through them. > > Could we implement the javax.comm shell classes on top of RXTX 2.1 > gnu.io API? I.e. would it be enough to just delegate method calls to > gnu.io. for a basic javax.comm implementation? Hi Dalibor That would be one possiblity. Another option would be to keep a diff which simply converts RXTX 2.1 into javax.comm. There are even scripts floating around which do that. -- Trent Jarvi ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [Rxtx] Implementing javax.comm for free software java implementations(Was: Re: [kaffe] Notes on kaffe (GNU Classpath integration) todo items)
On Mon, 14 Jul 2003, Dalibor Topic wrote: > Hi Chris, > > I've CC:ed Trent Jarvi, the maintainer of rxtx, see http://www.rxtx.org > for more information about it. > > Chris Gray wrote: > > On Monday 14 July 2003 00:11, Mark Wielaard wrote: > > > > > >>- javax.comm stuff > >> - Kaffe has incomplete stubs > >> - There is the rxtx (sp?) project which has been usable. > >>(Check kaffe mailinglist archives) > >>They have ported to lots of platforms > >> - Wonka also has a implementation... (Status?) > > > > > > Wonka implementation status: > > [+] works, tested in a number of real-life situations. Uses async i/o on > > Linux. > > [-] ugly as hell: hard-coded data structures for 4 serial ports, giant > > switch statements, etc. Uses Wonka Native Interface (WNI), would need porting > > to JNI (but this is not hard). > > > > For a project I'm working on currently it could be interesting to either > > convert the current Wonka implementation to JNI or switch to rxtx. Has anyone > > out there anyhing good or bad to say about rxtx? > > For kaffe it would be nice to use rxtx, since > > * we had it nicely running under kaffe > http://www.kaffe.org/pipermail/kaffe/2003-April/029251.html > > * it is supposed to be quite portable > > The following OS's should have full Serial Commapi Serial Support: > > mingw32 (windows 9* NT*) (no printer support) > WinCE (no printer support) > Solaris 2.x (*-*-solaris2*) x86 and sparc > Linux ELF (*-*-linux*, except aout, coff, and oldld) > FreeBSD 3.x 4.x (*-*-freebsd2*, *-*-freebsd3*) > Mac OS X > HP-UX 10.x (*-*-hpux10*) > SCO OpenServer 5.x (*-*-sco3.2v5*) (there may be recent breakage) > UnixWare > Digital/UNIX > > * it appears to be in widespread use in different projects. > > * it can be 'plugged in' into Sun's javax.comm implementation. > > On the negative side: > * it needs someone to write the java part of javax.comm (which wonka > already has working, kaffe has a GPLd implementation of unknown quality). > > * We don't have anyone from rxtx on Classpath's or Kaffe's mailing > lists, so there is a communication gap. > There should also be minimal support for printer ports on w32 also. We'd be more than willing to work with Classpath and or Kaffe to get this working. RXTX 2.1 implements CommAPI from the top down but is in package gnu.io to avoid confusion with Sun's impementation. RXTX 2.0 implements the lower portion of CommAPI and could be made to work with the upper portion offered in Kaffe. The Kaffe shell classes did look acceptable when I read through them. -- Trent Jarvi ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Playing with freenet...
Jim Pick ([EMAIL PROTECTED]) wrote: > Here's the key for the site: > > [EMAIL PROTECTED]/jimpick/1// I've managed to find the front page through my Kaffe node. (My Linux/Sun node hasn't found it yet, though. Perhaps it's a Sun anti-competitive feature? ;-) ) -- Greg Wooledge | "Truth belongs to everybody." [EMAIL PROTECTED] |- The Red Hot Chili Peppers http://wooledge.org/~greg/ | pgp0.pgp Description: PGP signature
StackTraceElements (Was: [kaffe] Notes on kaffe (GNU Classpathintegration) todo items)
Hi,
On Mon, 2003-07-14 at 10:19, Helmer Krämer wrote:
> i've got a working version of this in my local tree
> (jetty for jdk 1.4 was working fine with it), but
> somehow didn't get around to commit it :( Could you
> probably post a patch of your implementation so I
> can fix and commit it?
I got rid of the crashes, but there are still some regression test
failures (some are just textual since the output of the stack trace is
different, but some seem real).
The attached patch merges Throwable.java from GNU Classpath which is
used as is and adds a Kaffe specific VMThrowable class that holds the
backtrace and provides the actual StackTraceElements when needed.
I have to admit that I actually did not really design it but just copied
bits and pieces of existing code of kaffevm. And C isn't really my
language of choice. So if you could do a review of what I have now that
would be great.
Here is a ChangeLog entry for the attached (gzipped) patch:
2003-07-14 Mark Wielaard <[EMAIL PROTECTED]>
* include/Makefile.am (INSTALL_DERIVED_HDRS): Add
java_lang_VMThrowable.h and java_lang_StackTraceElement.h.
* include/Makefile.in: Regenerated.
* kaffe/kaffevm/baseClasses.h (javaLangVMThrowable): New extern
struct.
(javaLangStackTraceElement): Likewise.
* kaffe/kaffevm/baseClasses.h (javaLangVMThrowable): New base class.
(javaLangVMThrowable): Likewise.
(initBaseClasses): loadStaticClass new base classes.
* kaffe/kaffevm/exception.c (throwException): Get and initialize
vmstate.
(nullException): Create vmstate for exception.
(unhandledException): Use new Throwable->detailedMessage field name.
(floatingException): Create vmstate for exception.
* kaffe/kaffevm/stackTrace.c (getLineNumber): New method.
(getStackTraceElements): New method.
(printStackTrace): Get backtrace from vmState.
* libraries/clib/native/System.c (java_lang_System_debugE): Use new
Throwable->detailedMessage field name.
* libraries/clib/native/Throwable.c
(java_lang_Throwable_fillInStackTrace): Removed.
(java_lang_Throwable_printStackTrace0): Likewise.
(java_lang_VMThrowable_fillInStackTrace): New method.
(java_lang_VMThrowable_getStackTrace): Likewise.
* libraries/javalib/java/lang/Throwable.java: Replaced with Classpath
version.
* libraries/javalib/java/lang/VMThrowable.java: New class.
* libraries/javalib/bootstrap.classlist: Add VMThrowable.
* libraries/javalib/essential.files: Add StackTaceElement and
VMThrowable.
* libraries/javalib/Klasses.jar.bootstrap: Regenerated.
With this patch the attached program gives the following stack trace:
java.lang.NullPointerException
at Throw.testNull (Throw.java:17)
at Throw.main (Throw.java:5)
java.lang.ArithmeticException
at Throw.testDivZero (Throw.java:30)
at Throw.main (Throw.java:7)
java.lang.Exception: b confused
at Throw.a (Throw.java:58)
at Throw.testChain (Throw.java:42)
at Throw.main (Throw.java:9)
Caused by: java.lang.Exception: d broken
at Throw.c (Throw.java:75)
at Throw.b (Throw.java:64)
at Throw.a (Throw.java:54)
...2 more
Caused by: java.lang.Exception: fatal error
at Throw.e (Throw.java:86)
at Throw.d (Throw.java:81)
at Throw.c (Throw.java:71)
...4 more
BTW how do you keep track of copyrights? I added a new copyright header
to every file I changed, but looking through the rest of the sources
this seems not customary.
Cheers,
Mark
public class Throw
{
public static void main(String[] args)
{
testNull();
System.out.println();
testDivZero();
System.out.println();
testChain();
}
private static void testNull()
{
try
{
Object o = null;
o.toString();
}
catch (Throwable t)
{
t.printStackTrace();
}
}
private static void testDivZero()
{
try
{
int i = 0;
int j = 42/i;
}
catch (Throwable t)
{
t.printStackTrace();
}
}
private static void testChain()
{
try
{
a();
}
catch(Exception e)
{
e.printStackTrace();
}
}
static void a() throws Exception
{
try
{
b();
}
catch(Exception e)
{
throw new Exception("b confused", e);
}
}
static void b() throws Exception
{
c();
}
static void c() throws Exception
{
try
{
d();
}
catch(Exception e)
{
throw new Exception("d broken", e);
}
}
static void d() throws Exception
{
e();
}
static void e() throws Exception
{
throw new Exception("fatal error");
}
}
throwable.patch.gz
Description: GNU Zip compressed data
Re: [kaffe] erroneous regression test: test/regression/ProcessTest
> ":" == Rob Gonzalez <[EMAIL PROTECTED]> writes: :> When running ProcessTest against either kaffe or Sun's JRE 1.4.1_01 I get :> an "arrayIndexOutOfBoundsException" on line 24 in method main(), which :> accesses args[0], where args.length == 0. :> :> I believe the problems is that args[0] traditionally referred to the :> executing program, though in Java that's no longer the case, if it ever :> was (I don't recall ever using args[0] that way in Java). Yes, but I think ProcessTest is supposed to be started in this way: $JAVA ProcessTest $JAVA So args[0] is expected to be the name of the executing program. :> I'm not checking in the change because I don't think that it's safe to :> assume that "kaffe" is the right command to execute in all systems. In :> particular, it doesn't include whatever flags were used to execute the :> parent version of the program, but something should be done about this :> test case. If something is to be done, that will be to check the length of args and to issue a warning message if args[0] does not exist. ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Linux Kongress 2003 in Saarbruecken, Germany
On Monday 14 July 2003 21:05, Dalibor Topic wrote: > Hi everyone, > > Mark Wielaard has already said that I'd like the next free software java > develeper meeting to be in Saarbruecken, which hosts the Linux Kongress > from October 14 to October 16, 2003. I hope we can use this Kongress as > an oppportunity to present the current state of free java > implementations to a broader audience. And of course to have a BOF > session, a couple of drinks and a good time. > > I've attached the Call for Papers, since it specifically mentions > Virtual machines and emulations as one of the topics of interest. If you > want to submit a paper, you should hurry up: Extended abstracts are due > till August 8th. > > See you, > dalibor topic It's in my diary. :) (The 15th is my mother's 80th birthday, but so far the party is planned for the following weekend ... did I mention that her twin brother will be 80 too?) -- Chris Gray/k/ Embedded Java Solutions Embedded & Mobile Java, OSGi http://www.kiffer.be/k/ [EMAIL PROTECTED] +32 477 599 703 ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] java.util.BitSet (Re: Kaffe CVS: kaffe kaz)
> ":" == Kaffe CVS <[EMAIL PROTECTED]> writes: :> 2003-07-14 Ito Kazumitsu <[EMAIL PROTECTED]> :> :> * java/util/BitSet.java: :> copied from GNU Classpath to have JDK 1.4 features. I needed the method clear() (since 1.4) to compile KJC with kjc.jar with kaffe (It is not guaranteed that KJC can be compiled with KJC, but it is usually the case that KJC can be compiled with the same version of KJC). Guilhem's patch to KJC 2.1B may have made this unnecessary. But we had better have JDK 1.4 features anyway. ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] Infinite repaint with nestend FlowLayouts
Hello.
I found an problem when I put an large awt.Choice
in an FlowLayout Container, which is also nested in
an FlowLayout Container.
The component starts an infinite repaint and
the hole application hangs. I couldn't find the reason.
Sebastian.
Sample Prog:
import java.awt.*;
public class Test {
public static void main(String[] args) {
Choice choice = new Choice();
choice.addItem( "test test test test test test test test test test
test test" );
Frame f = new Frame();
Panel p = new Panel();
p.add( choice );
f.add( p );
f.show();
}
}
___
kaffe mailing list
[EMAIL PROTECTED]
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] iPAQ binary
Hi. On Donnerstag, 10. Juli 2003 12:03, Dalibor Topic wrote: > --- Sebastian Mancke <[EMAIL PROTECTED]> wrote: > > Hi. > > > > > but,At CaffeineMark, > > > I found a failed message when I tauched Info tab. > > > > > > ~/aaa # kaffe CaffeineMarkApp > > > kaffe-bin: jthread.c:1194: jthread_disable_stop: Assertion > > > `currentJThread->stop > > > Counter < 50' failed. > > > Aborted > > > ~/aaa # > > > > On the yopy i got the same error during the run of the > > Test of the CaffeineMarkApp. > > I've upped that limit from 10 to 50 a few months ago. I thought 50 should > be enough for everyone ;) Could you take a look at FAQ.debugging and post > the debugger backtrace, preferaby from interpreter mode with the method > names resolved. Oh, and does having an upper limit of, let's say 100 solve > the problem? Here is the trace. Sebastian.Call: java/io/PrintStream.flush()V. Call: java/io/BufferedOutputStream.flush()V. Call: java/io/FileOutputStream.write([BII)V. Call: java/io/FileOutputStream.writeBytes([BII)V. Call to native java/io/FileOutputStream.writeBytes([BII)V. at CaffeineMarkBenchmark.run(CaffeineMarkBenchmark.java:line unknown, pc 0x41)Returning from method write([BII)V. Call: java/io/OutputStream.flush()V. Returning from method flush()V. Returning from method flush()V. Returning from method flush()V. Returning from method write([BII)V. Call: java/io/PrintStream.flush()V. Call: java/io/BufferedOutputStream.flush()V. Call: java/io/OutputStream.flush()V. Returning from method flush()V. Returning from method flush()V. Returning from method flush()V. Returning from method print([B)V. Returning from method print([C)V. Call: java/io/PrintStream.println()V. Call: java/io/PrintStream.print([C)V. Call: java/lang/String.valueOf([C)Ljava/lang/String;. Call: java/lang/String.([C)V. Call: java/lang/String.([CII)V. Call: java/lang/Object.()V. Returning from method ()V. Call: java/lang/System.arraycopy(Ljava/lang/Object;ILjava/lang/Object;II)V. Call: java/lang/Object.getClass()Ljava/lang/Class;. Call to native java/lang/Object.getClass()Ljava/lang/Class;. Call: java/lang/Class.getComponentType()Ljava/lang/Class;. Call to native java/lang/Class.getComponentType()Ljava/lang/Class;. Call: java/lang/Object.getClass()Ljava/lang/Class;. Call to native java/lang/Object.getClass()Ljava/lang/Class;. Call: java/lang/Class.getComponentType()Ljava/lang/Class;. Call to native java/lang/Class.getComponentType()Ljava/lang/Class;. Call: java/lang/Class.isArray()Z. Call to native java/lang/Class.isArray()Z. Call: java/lang/Class.isArray()Z. Call to native java/lang/Class.isArray()Z. Call: java/lang/Class.isPrimitive()Z. Call to native java/lang/Class.isPrimitive()Z. Call: java/lang/Class.isPrimitive()Z. Call to native java/lang/Class.isPrimitive()Z. Call: java/lang/Class.isPrimitive()Z. Call to native java/lang/Class.isPrimitive()Z. Call: java/lang/Class.isPrimitive()Z. Call to native java/lang/Class.isPrimitive()Z. Call: java/lang/Class.isPrimitive()Z. Call to native java/lang/Class.isPrimitive()Z. Returning from method arraycopy(Ljava/lang/Object;ILjava/lang/Object;II)V. Returning from method ([CII)V. Returning from method ([C)V. Returning from method valueOf([C)Ljava/lang/String;. Call: java/lang/String.getBytes()[B. Call: kaffe/io/CharToByteConverter.getDefault()Lkaffe/io/CharToByteConverter;. Call: kaffe/io/CharToByteConverter.getConverter(Ljava/lang/String;)Lkaffe/io/Cha rToByteConverter;. Call: kaffe/io/CharToByteConverter.getConverterInternal(Ljava/lang/String;)Lkaff e/io/CharToByteConverter;. Call: java/util/Hashtable.get(Ljava/lang/Object;)Ljava/lang/Object;. Call: java/util/HashMap.get(Ljava/lang/Object;)Ljava/lang/Object;. Call: java/util/HashMap.find(Ljava/lang/Object;)Ljava/util/HashMap$Entry;. Call: java/util/HashMap.bucket(Ljava/lang/Object;I)I. Call: java/lang/String.hashCode()I. Returning from method hashCode()I. Returning from method bucket(Ljava/lang/Object;I)I. Call: java/util/HashMap.find(Ljava/lang/Object;I)Ljava/util/HashMap$Entry;. Call: java/lang/String.equals(Ljava/lang/Object;)Z. Returning from method equals(Ljava/lang/Object;)Z. Returning from method find(Ljava/lang/Object;I)Ljava/util/HashMap$Entry;. Returning from method find(Ljava/lang/Object;)Ljava/util/HashMap$Entry;. Returning from method get(Ljava/lang/Object;)Ljava/lang/Object;. Returning from method get(Ljava/lang/Object;)Ljava/lang/Object;. Call: java/lang/Class.newInstance()Ljava/lang/Object;. Call: java/lang/Class.getModifiers()I. Call to native java/lang/Class.getModifiers()I. Call: java/lang/reflect/Modifier.isAbstract(I)Z. Returning from method isAbstract(I)Z. Call: java/lang/Class.isInterface()Z. Call to native java/lang/Class.isInterface()Z. Call: java/lang/Class.isPrimitive()Z. Call to native java/lang/Class.isPrimitive()Z. Call: java/lang/Class.getDeclaredConstructor([Ljava/lang/Class;)Ljava/lang/refle ct/Constructor;. Call: java/lang/System.getSecurityManager()Ljava/lang/SecurityManager;. Returning from method getSecurityManag
[kaffe] Linux Kongress 2003 in Saarbruecken, Germany
Hi everyone, Mark Wielaard has already said that I'd like the next free software java develeper meeting to be in Saarbruecken, which hosts the Linux Kongress from October 14 to October 16, 2003. I hope we can use this Kongress as an oppportunity to present the current state of free java implementations to a broader audience. And of course to have a BOF session, a couple of drinks and a good time. I've attached the Call for Papers, since it specifically mentions Virtual machines and emulations as one of the topics of interest. If you want to submit a paper, you should hurry up: Extended abstracts are due till August 8th. See you, dalibor topic Linux-Kongress 2003 Call for Papers http://www.linux-kongress.org/2003/ Linux-Kongress 2003, the 10th International Linux System Technology Conference, is organized by the German Unix User Group (GUUG) and hosted by the Saarland University in Saarbrücken, Germany. Please contact <[EMAIL PROTECTED]> if you have any questions. Overview The 10th Linux-Kongress will take place from October 14 to October 16, 2003, at the Saarland University in Saarbrücken, Germany. It is the 10th anniversary of the traditional Linux-Kongress series (Heidelberg '94, Berlin '95 and '96, Würzburg '97, Köln '98, Augsburg '99, Erlangen 2000, Enschede 2001, and Köln 2002) which has evolved into the most important meeting for Linux experts and developers in Europe. You are invited to participate in this famous Linux community event by giving a presentation about your current development work, experiences with Linux, and future plans. The Linux-Kongress will be the best opportunity for Open Source developers to meet in Europe and exchange ideas about current and upcoming projects that (will) play an important role for Linux. You can learn from the tutorials, refereed papers, and invited talks, and discuss the newest technology with famous Linux and Open Source gurus. You can also visit the vendor exhibition, where leading Linux-related companies show their newest products, or find the latest books about your favorite topic on this exhibition. A social event will take place on Wednesday, October 15. A perfect opportunity to exchange ideas with other Linux experts, while enjoying food and drinks. The conference language is English. Tutorial Program (October 14) On Tuesday, a number of tutorials will be presented, all related to Linux and Open Source. Tutorials both for beginners and for more advanced users and developers will be included. If you're interested in presenting a tutorial or would like to share ideas about what would be a terrific tutorial, please contact the program committee via e-mail at <[EMAIL PROTECTED]>. Technical Conference (October 15-16) Wednesday and Thursday will offer around 25 technical sessions, including keynote address, presentations of refereed papers, and invited talks, divided in 2 parallel tracks. The talks will focus on Linux kernel and systems software, as well as more generic Open Source software used on Linux systems, and the underlying software technologies. Presentations should take about 40 minutes (including discussions, when applicable). The Linux-Kongress 2003 conference seeks original and innovative papers about current Linux and Open Source software development. Presentations are being solicited in areas including, but not limited to: * Security (firewalls, VPNs, cryptography, security models, programming techniques, smart cards, ...) * Networking (IPv6, IPsec, bandwith control, policy routing, VoIP, ...) * High-Availability and High-Performance clustering * Architectures (from Linux on PDAs to Linux on S/390) * Virtual machines and emulations (Wine, Plex86, User-Mode Linux, ...) * Storage management (RAID, LVM, filesystems, ...) * Device drivers (new advances, asynchronous I/O) * Desktop/office environments for Linux * Multimedia (sound, video, streaming media, conferencing) * ... To address the fast evolving nature of Linux, new topics not covered by the conference talks can be discussed during informal gatherings, called Birds-of-a-Feather (BoF) sessions. BoFs may be scheduled at the conference or in advance by mailing the program committee. Refereed Paper Submissions Papers for the technical sessions will be reviewed by the program committee. An extended abstract is required for the paper selection process. These abstracts must be submitted via the Linux-Kongress 2003 web site at http://www.linux-kongress.org/2003/cfp/subm.html . Only abstracts in ASCII format (250-500 words), including a title and the name(s) and e-mail address(es) of the author(s) are accepted. Furthermore, abstracts accompanied by non-disclosure agreement forms are
[kaffe] erroneous regression test: test/regression/ProcessTest
Hi everyone, When running ProcessTest against either kaffe or Sun's JRE 1.4.1_01 I get an "arrayIndexOutOfBoundsException" on line 24 in method main(), which accesses args[0], where args.length == 0. I believe the problems is that args[0] traditionally referred to the executing program, though in Java that's no longer the case, if it ever was (I don't recall ever using args[0] that way in Java). If I replace the String kaffe_exe = args[0] with String kaffe_exe = "kaffe" then everything's cool on my box, where I execute kaffe without any options. I'm not checking in the change because I don't think that it's safe to assume that "kaffe" is the right command to execute in all systems. In particular, it doesn't include whatever flags were used to execute the parent version of the program, but something should be done about this test case. Cheers, Rob ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] LinuxTag and RMLL impressions
Hi all, by now you might know that I've had a meeting with Mark Wielaard from GNU Classpath to discuss further integration of Classpath's class library into kaffe. I've also met with other Classpath hackers to discuss the advancement of GNU Classpath. It was all very exciting, and I wish that the next such meeting in October in Saarbruecken will attract more developers from kaffe. A few ideas came out of those meetings, that were summarized by Mark here http://www.kaffe.org/pipermail/kaffe/2003-July/043094.html http://mail.gnu.org/archive/html/classpath/2003-07/msg00040.html I'll give you a summary of other things I found interesting over the last couple of days. * Old kaffe versions in BSDs On the RMLL, all the BSD projects were present. I've got an introduction into the BSD ports system, and can now figure out who the maintainer of an out of date package is ;) OpenBSD : 1.0.6 : Ian Darwin <[EMAIL PROTECTED]> , has patches by pvalchev FreeBSD : 1.0.7 : [EMAIL PROTECTED], no patches NetBSD : 1.0.7nb1: [EMAIL PROTECTED], 3 somewhat strange patches If you are using one those operating systems, please get in touch with the respective maintainer to provide an updated version of kaffe for his system. * Kaffe 1.1.0 and debian Marko Jung from Saarbruecken offered to help with kaffe maintenance in debian to ease the load on Ean. Since 1.1.0 was broken on a few linux platforms, I'll get in touch with him when 1.1.1 is out. The stable version on debian is 1.0.5, which should somehow be resolved. 1.0.5 is *years* behind 1.1.0. I'm not familiar enough with Debian to say what needs to be done or fixed. The current situation casts a bad light on kaffe in debian, though. In fact, there seems to be a call to purge kaffe from the debian distribution. It is marked [REMOVE] on the release critical bug reports. * Kaffe and Worldforge The worldforge developers have a client in java that utilizes OpenGL. They would be interested in running it on kaffe, which means they could help getting open GL bindings for Java to work on kaffe. Beside the 'cool!' effect, having the OpenGL binding working in kaffe would result in an interesting testbed for a openGL based implementation of Graphics2D by GNU Classpath developers. * Kaffe and OpenOffice I've got hold of the e-mail address of the OpenOffice build system developer, who might be able to figure out what remains to be done for kaffe to be useable for an open office build. Apparently all they need is a java compiler, and we already ship kjc. Building OpenOffice might be a good reason to revive ports of kaffe like BeKaffe and merge them back into the kaffe.org tree. Talking to OpenOffice representatives at LinuxTag showed that there was a lot of interest on those platforms without a vendor provided somewhat current java implementation to use something else to build OpenOffice. * Kaffe and Konqueror Once Rob's verifier is finished, we could seriously start working together with free software browsers to provide support for applets in konqueror or mozilla. Unfortunately I wasn't able to get hold of a konqueror developer on LinuxTag, but I'll try to get through to someone. * NIO, NIO, NIO freenet needs nio. sascha brawer needs nio for his font rendering work. everyone seems to need nio these days, and noone has the native bits working yet. I hope that Michael Koch from libgcj is on a good way with his implementation. I'm in touch with Matthew from freenet to see what they exactly need. * OpenEJB I've played a bit with openEJB and got it to load a bit further by making AppClassLoader extend URLClassLoader, until it starts playing reflection games with Sun-specific fields of ClassLoader. Someone could try to persuade the OpenEJB developers not to do such embarassing things in public. ;) so much for the big stuff I can remember off the top of my head. cheers, dalibor topic __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] Kaffe CVS: kaffe kaz
CVSROOT:/cvs/kaffe Module name:kaffe Changes by: kaz 03/07/14 09:12:10 Modified files: . : ChangeLog libraries/javalib/java/util: BitSet.java Log message: 2003-07-14 Ito Kazumitsu <[EMAIL PROTECTED]> * java/util/BitSet.java: copied from GNU Classpath to have JDK 1.4 features. ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [Rxtx] Implementing javax.comm for free software java implementations(Was: Re: [kaffe] Notes on kaffe (GNU Classpath integration) todo items)
Hi Trent, Trent Jarvi wrote: We'd be more than willing to work with Classpath and or Kaffe to get this working. RXTX 2.1 implements CommAPI from the top down but is in package gnu.io to avoid confusion with Sun's impementation. RXTX 2.0 implements the lower portion of CommAPI and could be made to work with the upper portion offered in Kaffe. The Kaffe shell classes did look acceptable when I read through them. Could we implement the javax.comm shell classes on top of RXTX 2.1 gnu.io API? I.e. would it be enough to just delegate method calls to gnu.io. for a basic javax.comm implementation? cheers, dalibor topic ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] Playing with freenet...
Hi, I didn't spend any time working on Kaffe over the weekend, but I did spend some time playing with Freenet. :-) I made a "freesite", and inserted it into freenet using my node (running on the JDK, unfortunately, as the latest freenet builds use NIO and don't run ok Kaffe). As part of the freesite, I uploaded the Kaffe sources for 1.1.0. I think I'll publish future releases there as well. My site isn't anonymous, but it does mean that people can download Kaffe anonymously. :-) Here's the key for the site: [EMAIL PROTECTED]/jimpick/1// I sent some announcements around to various portal sites withing Freenet. Who knows if they'll ever receive them... Cheers, - Jim ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] Re: running Java applications within kaffe (Re: [kaffe]shutdownHook changes broke the build)
On Mon, 2003-07-14 at 03:34, Dalibor Topic wrote: > Salut Guilhem, > > Guilhem Lavaux wrote: > > >> I'll check in a patch that delegates running of kjc & pizza to another > >> VM instance through Runtime.exec, since that seems to be the sane > >> thing to do ;) > >> > >> cheers, > >> dalibor topic > > > > > > Hi dalibor ! > > > > Ok, have you tested the patch against KJC ? I am not sure they are > > active anymore (I tried to download from the CVS but I only get a timeout). > > I still have to write it, actually ;) I'll do it tonight, and then I'll > take a look at rmic to see how it calls the compiler to test it. > > > If you want I can provide you a new binary for KJC (based on KJC 2.1B). > > That would be very nice, but I'll try to rebuild it myself first, and to > run the jacks java compiler test suite against it. > > Then I'll put your patch into the developers directory and check in the > updated kjc.jar. You may want to change the version information as well, > to kjc-2.1B-gl-1 or something like that. > > Jim, could you post an update on your plans for the > kaffe-external-libraries repository? > > cheers, > dalibor topic I still haven't gotten the "kaffe-external-jars" thing done yet. Unfortunately, my time's been pretty tight the last two weeks. It's at the top of my list of things to do now... Please feel free to update kjc.jar, and post or check in the patch! :-) Cheers, - Jim ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Kaffe on YOPY, arm-linux PDA
Hallo Sebastian, --- Sebastian Mancke <[EMAIL PROTECTED]> wrote: > Hello. > > I have successfully cross compiled Kaffe 1.1.0 > for my arm-linux based PDA: YOPY, from GMate. > (Thanks for the FAQ.cross-compiling) Cool, good to hear that Kiyo's dosumentation finds its happy readers. > The YOPY has 207 MHz and 64 MB SD Ram > (The ram is used for both: filesystem and working memory.) > Is it possible to optimize Kaffe for such small systems? > For example by compile options for heap sizes > or making the binary size smaller? Please take a look at FAQ.embedded for a list of things you can do to reduce kaffe's size on an embedded platform. > Error message: > arm-linux-gcc -DHAVE_CONFIG_H -I. -I. -I../../../config -I../../../include \ > -I../../../kaffe -DKVER=\"1.1.0\" \ > -I/home/asteban/trash/kaffe-1.1.0/./kaffe/kaffevm \ > -I/home/asteban/trash/kaffe-1.1.0/./kaffe/kaffevm/systems/unix-jthreads \ > -I../../../config -I../../../include -DKAFFE_VMDEBUG -g -O2 -Wall \ > -Wstrict-prototypes -fsigned-char -c InetAddressImpl.c \ > -Wp,-MD,.deps/InetAddressImpl.TPlo -fPIC -DPIC -o > .libs/InetAddressImpl.o > InetAddressImpl.c: In function \ >`java_net_NativeInetAddressImpl_getHostByAddr0': > InetAddressImpl.c:413: structure has no member named `sin6_scope_id' this should be fixed in the current CVS sources. > 2. It inherently uses /usr/lib/libjpeg.so instead of > /usr/arm-linux/lib/libjpeg.so > I also tryed to set the lib dirs by the following options: > LDFLAGS=-L/usr/arm-linux/lib/ > --with-libraries=/usr/arm-linux/lib/ > --with-awtlibpath=/usr/arm-linux/lib/ > Theese had no affects. That's yet another bug in libtool, AFAIK. It seems to pick up libraries passed by --with-libraries only after it has tried to find a library in common library locations like /usr/lib. See http://mail.gnu.org/archive/html/libtool/2001-10/msg00127.html for a possible patch, that apparently has a typo somewhere ... sigh. Please report it as a bug to the libtool project, their web site is http://www.gnu.org/software/libtool/ and point them to the patch. cheers, dalibor topic __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] Re: porting kaffe to uclinux
Hi Dalibor, On 14/07/03, you wrote: > The gcc docs say : > > -fomit-frame-pointer > Don't keep the frame pointer in a register for > functions that don't need one. This avoids the instructions to save, > set up and restore frame > pointers; it also makes an extra register available in > many functions. It also makes debugging impossible on most machines. > I might add that not only does it prevent debugging, but it probably prevents stack-backtrace for exception handling. tony ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Fwd: MonitorVariable allocation problem
In message "[kaffe] Fwd: MonitorVariable allocation problem" on 03/07/12, Guilhem Lavaux <[EMAIL PROTECTED]> writes: > I know this is not really the place for that patch (I also sent it to KOPI > Developer list) but I do not know if the project is still really active... > Meanwhile here is a patch to fix KJC's problem raised by ShutdownHookTest. I > have checked the new compiler by compiling all the java libraries with itand > all regression tests pass successfully. So if someone is interested in > testing it... I tried your patch and foud it worked fine. I hope Kopi project is still active because some people at dms.at somtimes posts articles to the Kopi users mailing list. But I do not expect that an official bug fix of kjc.jar is coming soon. So I think it is a good idea that we use Guilhem's kjc.jar for the time being. ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Implementing javax.comm for free software java implementations (Was:Re: [kaffe] Notes on kaffe (GNU Classpath integration) todo items)
Hi Chris, I've CC:ed Trent Jarvi, the maintainer of rxtx, see http://www.rxtx.org for more information about it. Chris Gray wrote: On Monday 14 July 2003 00:11, Mark Wielaard wrote: - javax.comm stuff - Kaffe has incomplete stubs - There is the rxtx (sp?) project which has been usable. (Check kaffe mailinglist archives) They have ported to lots of platforms - Wonka also has a implementation... (Status?) Wonka implementation status: [+] works, tested in a number of real-life situations. Uses async i/o on Linux. [-] ugly as hell: hard-coded data structures for 4 serial ports, giant switch statements, etc. Uses Wonka Native Interface (WNI), would need porting to JNI (but this is not hard). For a project I'm working on currently it could be interesting to either convert the current Wonka implementation to JNI or switch to rxtx. Has anyone out there anyhing good or bad to say about rxtx? For kaffe it would be nice to use rxtx, since * we had it nicely running under kaffe http://www.kaffe.org/pipermail/kaffe/2003-April/029251.html * it is supposed to be quite portable The following OS's should have full Serial Commapi Serial Support: mingw32 (windows 9* NT*) (no printer support) WinCE (no printer support) Solaris 2.x (*-*-solaris2*) x86 and sparc Linux ELF (*-*-linux*, except aout, coff, and oldld) FreeBSD 3.x 4.x (*-*-freebsd2*, *-*-freebsd3*) Mac OS X HP-UX 10.x (*-*-hpux10*) SCO OpenServer 5.x (*-*-sco3.2v5*) (there may be recent breakage) UnixWare Digital/UNIX * it appears to be in widespread use in different projects. * it can be 'plugged in' into Sun's javax.comm implementation. On the negative side: * it needs someone to write the java part of javax.comm (which wonka already has working, kaffe has a GPLd implementation of unknown quality). * We don't have anyone from rxtx on Classpath's or Kaffe's mailing lists, so there is a communication gap. cheers, dalibor topic ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] porting kaffe to uclinux
Kiyo Inaba wrote: Hi, For LDFLAGS and the others it's ok but CFLAGS is hardcoded in config/m68k/linux/config.frag, Humm, all flags in CFLAGS should not be mandatory, we can delete this line at all. The gcc docs say : -fomit-frame-pointer Don't keep the frame pointer in a register for functions that don't need one. This avoids the instructions to save, set up and restore frame pointers; it also makes an extra register available in many functions. It also makes debugging impossible on most machines. Could you give it a try and see if it really is the case on m68k-linux? cheers, dalibor topic ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] porting kaffe to uclinux
Hi Andrea, Andrea Scian wrote: hi all! I'm trying to port kaffe on a m68k-uclinux system (the building system is x86-CygWin) and I have to make some changes to some the kaffe file. Have you looked at the pocketlinux sources for m68k-uclinux? they are here: http://www.kaffe.org/cgi-bin/viewcvs.cgi/pocketlinux/XOE_1.0/src/kaffe-all/src/config/m68k/ and might be helpful. is it better to make another directory under /config/m68k called uclinux and put there my options or there is a better solution? that's what transvirtual did, yes. I think that's the best option, since uclinux is somewhat different from common linux. Given that you have to specify some specific options for cross compilation, you may want to take a look at Kiyo's config.frag for superh-linux here http://www.kaffe.org/cgi-bin/viewcvs.cgi/kaffe/config/superh/linux/config.frag?rev=1.1&content-type=text/vnd.viewcvs-markup p.s. think about that I will also have to do some other changes (hope not to the source files!!! ;-) I'm looking forward to your patches ;) cheers, dalibor topic ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Porting Kaffe to Cray
Hi Justin, Justin R. Cutler wrote: I am part of GWU's project working on porting Kaffe to the Cray SV1. Wow! Kaffe on a Cray! I'm very impressed. Our project has already gotten the interpreter partially running, so we are also starting on a JIT3 implementation in parallel. We presently have no plans to use the vector units in our implementation, as we wish to take somewhat smaller steps in the porting process. Is there any chance of getting your changes back in the main tree eventually? I'd assume that you had to fix a few bugs in the core ;) cheers, dalibor topic ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: running Java applications within kaffe (Re: [kaffe] shutdownHookchanges broke the build)
Dalibor Topic wrote: Dalibor Topic wrote: hi Guilhem, I've just checked in a patch that fixed the remaining compilation problems for me. It now builds fine for me, but the shutdown hook test still fails. My patch changed the compile method of kaffe/tools/compiler/Compiler_kjc and Compiler_pizza classes to return false only when an exception occurs. But I don't think that kjc or pizza always throw an exception before they fail to compile some code, so my implementation of compile() smells funny ;) On the other hand, I don't think there is a way to get the exit codes of applications ra within kaffe as their calls to Runtime.exit() should shutdown the whole virtual machine. The apperently simple, but slow & fat way out is to just use Runtime.exec to start another instance of a JVM. What do you think? I'll check in a patch that delegates running of kjc & pizza to another VM instance through Runtime.exec, since that seems to be the sane thing to do ;) cheers, dalibor topic Hi dalibor ! Ok, have you tested the patch against KJC ? I am not sure they are active anymore (I tried to download from the CVS but I only get a timeout). If you want I can provide you a new binary for KJC (based on KJC 2.1B). Cheers, Guilhem. ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: running Java applications within kaffe (Re: [kaffe] shutdownHookchanges broke the build)
Dalibor Topic wrote: hi Guilhem, I've just checked in a patch that fixed the remaining compilation problems for me. It now builds fine for me, but the shutdown hook test still fails. My patch changed the compile method of kaffe/tools/compiler/Compiler_kjc and Compiler_pizza classes to return false only when an exception occurs. But I don't think that kjc or pizza always throw an exception before they fail to compile some code, so my implementation of compile() smells funny ;) On the other hand, I don't think there is a way to get the exit codes of applications ra within kaffe as their calls to Runtime.exit() should shutdown the whole virtual machine. The apperently simple, but slow & fat way out is to just use Runtime.exec to start another instance of a JVM. What do you think? I'll check in a patch that delegates running of kjc & pizza to another VM instance through Runtime.exec, since that seems to be the sane thing to do ;) cheers, dalibor topic ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] porting kaffe to uclinux
Hi, >For LDFLAGS and the others it's ok but CFLAGS is hardcoded in >config/m68k/linux/config.frag, Humm, all flags in CFLAGS should not be mandatory, we can delete this line at all. Kiyo ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: Problems with CygWin (was: Re: [kaffe] undefined references inkaffeh)
Hi Andrea, Andrea Scian wrote: I'm sorry for the last e-mail but it seems that I have made some mistakes while updating from the CVS... in fact I download it again and now it works! it still required the patch for jthread.c and give me an error with a cygwin include file (cygwin/types.h), but now I fix it and I get a working Kaffe on my CygWin! Thanks for you help I'm glad that it works now. I've checked in a patch for replace/inet_*.c that fixes the include file problems. I get a working build when I configure kaffe to build as a static binary on cygwin, while dynamic builds don't work yet because of missing symbols. Most regression tests fail unfortunately, since compiling with kjc on cygwin causes a weird segmentation violation in jar.c. Someone on cygwin should look into it. I'm not familiar with x86 assembler, so I can't say if something fishy is going on. But it looks like stack corruption, since I'm getting segmentation violations for access to local variables in jar.c. It would be great, if you could try to get the dynamic builds to work as well. Please take a look at http://sources.redhat.com/autobook/autobook/autobook_251.html#SEC251 . This chapter contains the necessary information on how to update the sourcecode and Makefile.am-s to allow building of DLLs on windows. Of course, all patches fixing kaffe's gcc warnings on Cygwin are welcome as well. cheers, dalibor topic ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Notes on kaffe (GNU Classpath integration) todo items
On Monday 14 July 2003 00:11, Mark Wielaard wrote: > - javax.comm stuff > - Kaffe has incomplete stubs > - There is the rxtx (sp?) project which has been usable. > (Check kaffe mailinglist archives) > They have ported to lots of platforms > - Wonka also has a implementation... (Status?) Wonka implementation status: [+] works, tested in a number of real-life situations. Uses async i/o on Linux. [-] ugly as hell: hard-coded data structures for 4 serial ports, giant switch statements, etc. Uses Wonka Native Interface (WNI), would need porting to JNI (but this is not hard). For a project I'm working on currently it could be interesting to either convert the current Wonka implementation to JNI or switch to rxtx. Has anyone out there anyhing good or bad to say about rxtx? -- Chris Gray/k/ Embedded Java Solutions Embedded & Mobile Java, OSGi http://www.kiffer.be/k/ [EMAIL PROTECTED] +32 477 599 703 ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Notes on kaffe (GNU Classpath integration) todo items
On 14 Jul 2003 00:11:14 +0200
Mark Wielaard <[EMAIL PROTECTED]> wrote:
Hi,
> - StackTraceElement stuff ("pure java Throwable"). Mark has some
> code hacked up. It compiles... but crashes in spectacular ways.
> -> Goal log4j (used by either JBOSS or Tomcat) uses XMLized stacktraces
> from StackTraceElements.
i've got a working version of this in my local tree
(jetty for jdk 1.4 was working fine with it), but
somehow didn't get around to commit it :( Could you
probably post a patch of your implementation so I
can fix and commit it?
Greetings,
Helmer
___
kaffe mailing list
[EMAIL PROTECTED]
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] porting kaffe to uclinux
hi all! I'm trying to port kaffe on a m68k-uclinux system (the building system is x86-CygWin) and I have to make some changes to some the kaffe file. In particular I have to change the enviroment variables like CFLAGS, LDFLAGS and others to support my target, 'til now I have just set them before calling ./configure, like this: CC=m68k-elf-gcc NM=m68k-elf-nm AR=m68k-elf-ar \ CFLAGS="-m5307 -g -Wl,-elf2flt" \ LDFLAGS="-m5307 -Wl,-elf2flt" \ KAFFEH=/../kaffeh \ LIBS=-lc \ ./configure --host=m68k-linux --build=i686-linux [more options...] For LDFLAGS and the others it's ok but CFLAGS is hardcoded in config/m68k/linux/config.frag, so it overwrite my definition... what should I do? is it better to make another directory under /config/m68k called uclinux and put there my options or there is a better solution? p.s. think about that I will also have to do some other changes (hope not to the source files!!! ;-) ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] Re: Notes on kaffe (GNU Classpath integration) todo items
> "Mark" == Mark Wielaard <[EMAIL PROTECTED]> writes: Mark> - java.util.zip Mark> How to modularize to allow multiple implementations to coexist? Mark> (See what classes are different between classpath/gcj) Here's a handy URL: http://gcc.gnu.org/java/libgcj-classpath-compare.html Note that the java.util.zip diffs will show up with the wrong mime-type, due to a server configuration oddity :-(. You should still be able to get them with wget though. Any zip classes listed as missing from libgcj are part of the pure-java zip implementation. Last time I looked there was at least one correctness bug in classpath here -- a constant had the wrong (byte-swapped) value. Mark> - Classpath seems to have all the proper Permission checks in place. Mark> (But has anybody every really used it? Probably not, because Mark> AccessController isn't really implemented.) As far as I know nobody has ever tried this. I'm certain they haven't with libgcj. I suspect not with any other VM, since I've never seen a bug report about it; the few security-related patches I've seen could plausibly have been found by inspection (e.g., misspelling somewhere). Mark> - Security/Crypto - Choose default provider Mark> (kaffe, GNU Classpath and/or GNU Crypto). For libgcj we've settled on recommending GNU Crypto as the choice (we don't ship it by default). GNU Crypto is actively maintained by friendly people -- big pluses. Tom ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
