[kaffe] Kaffe vs. Freenet round (N+2): nio
20:12 greycat> is nio going to be mandatory in 0.5.2? this is going to screw kaffe users 20:13 toad_> greycat: yes. kaffe users can fix the bugs. $ ln -sf freenet-nio-20030616.jar freenet.jar $ java freenet.node.Main java.lang.UnsatisfiedLinkError: Failed to locate native function: gnu/java/nio/SocketChannelImpl.SocketCreate()I at gnu.java.nio.ServerSocketChannelImpl.(ServerSocketChannelImpl.java:70) at gnu.java.nio.SelectorProviderImpl.openServerSocketChannel(SelectorProviderImpl.java:75) at java.nio.channels.ServerSocketChannel.open(ServerSocketChannel.java:90) at freenet.transport.TCP$privServerSocketFactory.createServerSocket(TCP.java:129) at freenet.transport.tcpNIOListener.startListener(tcpNIOListener.java:62) at freenet.transport.tcpNIOListener.(tcpNIOListener.java:50) at freenet.transport.tcpNIOListener.(tcpNIOListener.java:36) at freenet.interfaces.PublicNIOInterface.(PublicNIOInterface.java:46) at freenet.node.Main.startNode(Main.java:1292) at freenet.node.Main.main(Main.java:868) Dumping live threads: `QThread-6' tid 0xc51010, status SUSPENDED flags [EMAIL PROTECTED] (0xc51010->|) `QThread-5' tid 0xc46010, status SUSPENDED flags [EMAIL PROTECTED] (0xc46010->|) `QThread-4' tid 0xc17010, status SUSPENDED flags [EMAIL PROTECTED] (0xc17010->|) `QThread-3' tid 0xc01010, status SUSPENDED flags [EMAIL PROTECTED] (0xc01010->|) `QThread-2' tid 0xbee010, status SUSPENDED flags [EMAIL PROTECTED] (0xbee010->|) `QThread-1' tid 0xbdd010, status SUSPENDED flags [EMAIL PROTECTED] (0xbdd010->|) `Thread creation thread.' tid 0xbbd010, status SUSPENDED flags [EMAIL PROTECTED] (0xbbd010->|) `Background inserter' tid 0xb5b010, status SUSPENDED flags [EMAIL PROTECTED] (0xb5b010->|) `Diffie-Helman-Precalc' tid 0x73f010, status SUSPENDED flags [EMAIL PROTECTED] (0x73f010->|) `Log File Writer Thread' tid 0x679010, status SUSPENDED flags [EMAIL PROTECTED] (0x679010->|) `gc' tid 0x1d0010, status SUSPENDED flags DONTSTOP [EMAIL PROTECTED] (0x1d0010->|) `finaliser' tid 0x1c7010, status SUSPENDED flags DONTSTOP [EMAIL PROTECTED] (0x1c7010->|) Deadlock: all threads blocked on internal events Abort (core dumped) (gdb) bt #0 0x40215fcf in _thread_sys_kill () #1 0x402158bb in abort () #2 0x40057434 in onDeadlock () at thread.c:603 #3 0x4007e2d8 in reschedule () at jthread.c:1679 #4 0x4007ceda in killThread (tid=0xd9050) at jthread.c:364 #5 0x4007e0c6 in jthread_exit () at jthread.c:1580 #6 0x400571c0 in exitThread () at thread.c:439 #7 0x4004a893 in Kaffe_DestroyJavaVM (vm=0x400b3c74) at jni.c:3530 #8 0x1b64 in main2 (env=0x0, argv=0xcfbfda40, farg=2, argc=0) at main.c:238 #9 0x199d in main (argc=2, argv=0xcfbfda40) at main.c:145 Engine: Just-in-time v3 Version: 1.1.x-cvs Java Version: 1.1 Configuration/Compilation options: Compile date : Fri Jun 13 18:41:35 EDT 2003 Compile host : pegasus Install prefix: /usr/local/kaffe Thread system : unix-jthreads CC: gcc CFLAGS: -g -O2 -Wall -Wstrict-prototypes LDFLAGS : ChangeLog head: 2003-05-11 Dalibor Topic <[EMAIL PROTECTED]> -- Greg Wooledge | "Truth belongs to everybody." [EMAIL PROTECTED] |- The Red Hot Chili Peppers http://wooledge.org/~greg/ | pgp0.pgp Description: PGP signature
Re: [kaffe] libraries/clib/net/InetAddressImpl.c cannot be compiled on old Linux
In message "Re: [kaffe] libraries/clib/net/InetAddressImpl.c cannot be compiled on old Linux" on 03/06/13, Ito Kazumitsu <[EMAIL PROTECTED]> writes: > In message "Re: [kaffe] libraries/clib/net/InetAddressImpl.c cannot be compiled on > old Linux" > on 03/06/13, Dalibor Topic <[EMAIL PROTECTED]> writes: > > Looks good, please check the dummyin.h patch in, and send it to the getaddrinfo > > maintainer for inclusion in the next version. I don't think the 'fake'comments > > are really necessary, since it's all fake IPv6 support anyway ;) > > OK, I will. I sent the patch to the author of getaddrinfo-1.5.1. And he said he would include it in the next version. ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Replaced the good old lightweight AWT?!
Hi Jim, --- Jim Pick <[EMAIL PROTECTED]> wrote: > Actually, we have multiple AWTs now, selectable at configure time. > > I wouldn't mind seeing it so that we could compile them all in, and > easily select them at run time, using properties, or something like > that. If somebody was really ambitious, maybe it's even possible to > mix them up, and run multiple AWTs at once. :-) > > I'd like to see a merge of the old Transvirtual lightweight AWT from > the PocketLinux fork of Kaffe. That had a lot of neat stuff, and > support for things like drawing to the framebuffer, and quite a few > low level graphics libraries. > > Also, there's Classpath's AWT, which has GTK peer classes implemented. > They've got some Swing stuff too. > > Another cool one to suck in might be Rudolph (from Acunia's Wonka VM), > which also works on the framebuffer. > > Another one that looks interesting is Agile2D, which is a Java 2D > implementation, that sits on top of OpenGL (released under the MPL). > It's not really an AWT, but they have pictures of Swing running on top > of it. We could port the back end of the Transvirtual lightweight > AWT onto it, I think. sounds like more material for the projects section of the FAQ.awt. ;) Could you check in an update? 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
Re: Using tar files (was Re: [kaffe] make dist-gzip on OpenBSD)
--- Jim Pick <[EMAIL PROTECTED]> wrote: > On Wed, 2003-06-11 at 15:57, Greg Wooledge wrote: > > 'make dist-gzip' on OpenBSD produces several of these: > > > > tar: File name too long for tar > kaffe-1.1.x-cvs/libraries/javalib/META-INF/services/javax.sound.sampled.spi.FormatConversionProvider > > tar: File name too long for tar > kaffe-1.1.x-cvs/libraries/javalib/org/tritonus/share/sampled/convert/TAsynchronousFilteredAudioInputStream.java > > ... > > This is annoying the heck out of me. I first saw this with our viewcvs > interface on the the website, which allowed people tar files, but I had > to disable it because it couldn't do long filenames. > > And now a lot of people are finding that it doesn't work on their > platform because they don't have a tar that supports GNU tar extensions. > > Unfortunately, 100 characters isn't a very long name, given classes > named like above. > > I'd like to eliminate the dependency on GNU tar. But I'm not sure what > the best way to do this is. Any ideas? zip should be able to handle longer filenames thatn tar, but doesn't compress that well. 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
Using tar files (was Re: [kaffe] make dist-gzip on OpenBSD)
On Wed, 2003-06-11 at 15:57, Greg Wooledge wrote: > 'make dist-gzip' on OpenBSD produces several of these: > > tar: File name too long for tar > kaffe-1.1.x-cvs/libraries/javalib/META-INF/services/javax.sound.sampled.spi.FormatConversionProvider > tar: File name too long for tar > kaffe-1.1.x-cvs/libraries/javalib/org/tritonus/share/sampled/convert/TAsynchronousFilteredAudioInputStream.java > ... This is annoying the heck out of me. I first saw this with our viewcvs interface on the the website, which allowed people tar files, but I had to disable it because it couldn't do long filenames. And now a lot of people are finding that it doesn't work on their platform because they don't have a tar that supports GNU tar extensions. Unfortunately, 100 characters isn't a very long name, given classes named like above. I'd like to eliminate the dependency on GNU tar. But I'm not sure what the best way to do this is. Any ideas? Cheers, - Jim ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Replaced the good old lightweight AWT?!
Actually, we have multiple AWTs now, selectable at configure time. I wouldn't mind seeing it so that we could compile them all in, and easily select them at run time, using properties, or something like that. If somebody was really ambitious, maybe it's even possible to mix them up, and run multiple AWTs at once. :-) I'd like to see a merge of the old Transvirtual lightweight AWT from the PocketLinux fork of Kaffe. That had a lot of neat stuff, and support for things like drawing to the framebuffer, and quite a few low level graphics libraries. Also, there's Classpath's AWT, which has GTK peer classes implemented. They've got some Swing stuff too. Another cool one to suck in might be Rudolph (from Acunia's Wonka VM), which also works on the framebuffer. Another one that looks interesting is Agile2D, which is a Java 2D implementation, that sits on top of OpenGL (released under the MPL). It's not really an AWT, but they have pictures of Swing running on top of it. We could port the back end of the Transvirtual lightweight AWT onto it, I think. Interestingly, Sun seems to have gotten the message, and it coming out with their own Lightweight AWT for Tiger (Java 1.5). http://servlet.java.sun.com/javaone/sf2003/conf/sessions/display-1999.en.jsp Cheers, - Jim On Sun, 2003-06-15 at 22:50, Clemens Eisserer wrote: > Hi there! > > I just read the release notes of Kaffe-1.1 and I was really shocked. I > dont have the opportunity to test kaffe-1.1 by myself so I´ve to ask. > > I read that theres a new AWT that uses QT as underlaying toolik. Was the > old lightweight AWT replaced with this heavyweight toolkit? > My Problem is, that I was very happy with the old solution, because it was > so incredible fast, especally for other lightweight toolkits (Biss AWT, > Ought2, ..). > I also tinkered in integrating Biss-AWT instead of the "old" AWT used in > Kaffe, because it has all the common awt features but also supports a lot > of other new widgets. > For JVM´s that doesnt include these new AWT classes it would be no > problem, to create "compatibility packages" which only include classes not > included in the standard classpath. > > With QT creating such packages would be really hard, the native widgets > need to be created lightweight for other JVM´s! > > The second problem I see is that QT slows down all the primitive drawing > functions which are used very often by lightweight toolkits! I loved kaffe > because it used the underlaying X directly without requiring a native > toolkit whioch slows down drawing speed, because of adding a new layer of > code! > > Kaffes built-in Gui support is very poor for bigger apps, and because of > free swing replacements doesnt come up (I also tried it by myself, butthe > toolkit seems to be incerdibly overdesigned and ugly!) it would make sence > in my opinion to extend the currently used AWT implementation. > > But when QT replaced all the great lightweight stuff, all my thoughts are > useless ;-(( > > Please tell my your ideas! > > lg Clemens > > > > > ___ > kaffe mailing list > [EMAIL PROTECTED] > http://kaffe.org/cgi-bin/mailman/listinfo/kaffe ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] kaffe 1.1.0 with qt awt on board like assabet
Hi Sankalpa, --- Sankalpa <[EMAIL PROTECTED]> wrote: > Hi > > First of all I must thank to the community for their prompt > responses,specially to Dalibor Topic. I'm flattered ;) > I managed to up kaffe on my board like assabet with qt awt support. cool. > Now I tested with a simple awt application.It works fine. sorry that it took so long to get there. > How ever the I like to report about following. > 1.Though FAQ.awt says it support swing simple swing application did not > work. have you tried using sun's swing 1.1.1 with kaffe? citing from the FAQ.awt: We completely support Swing. The version that works best with kaffe is JFC 1.1 with SWING 1.1.1, available from http://java.sun.com/products/jfc/download.html. Later versions may or may not run. Patches to get them to run are welcome. It would be in general preferable to help out GNU Classpath to implement SWING, though. > 2.There is some problem with Inner classes > 3.The look and feel of controls of awt is not good.Specially buttons do > not appear as 3d and TextArea controller did not appear as it is. > 4.Further we found many exceptins in event handling. > (But my QTOPIA palm top works very fine) the qt-awt implementation is not as stable or polished as the Xlib one. so consequently, we are looking for AWT hackers who know a deal about Qt to help improve it, and fix the remaining issues. It would be very nice if you could help out, since you a) are using AWT b) are using Qt c) last but not least have a personal interest in seing it fixed ;) So if you're not tainted (i.e. haven't looked at or disassembled Sun's code, or signed some NDAs that would prevent you from contributing) I'd propose to start with a cleanup patch, that removes all the commented out and ifdef 0 -ed portions of code from the Qt-based AWT implementation. Then it should be easier to spot the bugs ;) 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 1.1.0 with qt awt on board like assabet
Hi First of all I must thank to the community for their prompt responses,specially to Dalibor Topic. I managed to up kaffe on my board like assabet with qt awt support. I maned to get over with first instance of compilation break of below by export LDFLAGS=-lm before make.(I have raised this question in my previous mail to the question). arm-linux-gcc -g -O2 -Wall -Wstrict-prototypes -fsigned-char -o kaffeh sigs.o support.o main.o mem.o inflate.o jar.o utf8const.o readClass.o constants.o debug.o -L/tmp/qtopia/qtopia/qt-2.3.4/lib -lqte -Wl,--rpath -Wl,/usr/local/arm/2.95.3/lib /tmp/qtopia/qtopia/qt-2.3.4/lib/libqte.so: undefined reference to `cos' /tmp/qtopia/qtopia/qt-2.3.4/lib/libqte.so: undefined reference to `sin' /tmp/qtopia/qtopia/qt-2.3.4/lib/libqte.so: undefined reference to `pow' collect2: ld returned 1 exit status make[2]: *** [kaffeh] Error 1 Now I tested with a simple awt application.It works fine. How ever the I like to report about following. 1.Though FAQ.awt says it support swing simple swing application did not work. 2.There is some problem with Inner classes 3.The look and feel of controls of awt is not good.Specially buttons do not appear as 3d and TextArea controller did not appear as it is. 4.Further we found many exceptins in event handling. (But my QTOPIA palm top works very fine) Can you please let me know whether these are limitations of kaffe or I have not ported kaffe properly. Thanks Sankalpa This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Crossvue Private Limited - a Symbol Technologies Company ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] arm linux compilation problem of kaffe-1.1.0
Hi Sankalpa, --- Sankalpa <[EMAIL PROTECTED]> wrote: > arm-linux-gcc -g -O2 -Wall -Wstrict-prototypes -fsigned-char -o kaffeh > sigs.o support.o main.o mem.o inflate.o jar.o utf8const.o readClass.o > constants.o debug.o -L/tmp/qtopia/qtopia/qt-2.3.4/lib -lqte -Wl,--rpath > -Wl,/usr/local/arm/2.95.3/lib > /tmp/qtopia/qtopia/qt-2.3.4/lib/libqte.so: undefined reference to `cos' > /tmp/qtopia/qtopia/qt-2.3.4/lib/libqte.so: undefined reference to `sin' > /tmp/qtopia/qtopia/qt-2.3.4/lib/libqte.so: undefined reference to `pow' > collect2: ld returned 1 exit status > make[2]: *** [kaffeh] Error 1 > > > What may be the reason for this. It uses mathematical functions in libqte, but doesn't link to libm. That should be easy to fix by adding a -lm to the linking command above. Does arm-linux-gcc -g -O2 -Wall -Wstrict-prototypes -fsigned-char -o kaffeh sigs.o support.o main.o mem.o inflate.o jar.o utf8const.o readClass.o constants.o debug.o -L/tmp/qtopia/qtopia/qt-2.3.4/lib -lqte -Wl,--rpath -Wl,/usr/local/arm/2.95.3/lib -lm work? What puzzles me though, is that it tries to link qte with kaffeh. There is no reason for kaffeh to use Qt. I'll have a look at it. The simple fix should be to just add -lm to QPE's QT_CXXFLAGS in gwqt.m4, and run developers/autogen.sh. 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
