Re: What's the thread model on Linux?
> > But what I found is that kaffe cannot even support 200 users. > > Interesting! Only the unix-jthreads code gets tested and used a lot, > so I wouldn't be too surprised that unix-pthreads can't keep up with > unix-jthreads. In any event, the unix-pthreads code should be able to > support more than 200 threads. It could very well be a simple problem > in the unix-pthread code. pthread is buggy, at least up to glibc 2.1 on each linux distro I used (RH, SuSE, debian stable). I get deadlocks on a test-program I had to write for work (not related to kaffe at all). This is known and I got the advice to upgrade to glibc 2.2. I did that on one system (debian stable -> progeny), but still got a deadlock, be it in the longest run of the test-program ever (didn't do any further tests). YMMV, Kero. +--- Kero --- [EMAIL PROTECTED] ---+ | Don't split your mentality without thinking twice | | Proud like a God -- Guano Apes | +--- M38c -- http://huizen.dds.nl/~kero ---+
Focus bug
Hi all, I have a Frame that contains a Canvas, two Scrollbar's and a Label. When I create the Frame, I let the Canvas request focus. It gets it. However, whenever focus is lost to the Frame, the Canvas does not receive focus back again. This is due to the fact that when the mentioned Frame receives the focus, it calls focusNext() (via some ShortcutHandler). Neither of my four Components are focus-traversable, so none of them gets focus. What I would expect is that the Component that has the focus, is remembered in some way when the Frame loses focus, such that the Component can receive it back whenever the Frame receives it back. I tried to remember the Component in the Frame, but got caught in Components that never show they gain focus in the Java part. A peek in the C-code showed code involved in focus there, too and that is when I gave up. Remark: Component.processFocusEvent() tests whether there is a FocusListener, but when there was none, the function did not get called at all. Bye, Kero. PS: other JVM's have better behaviour, but not perfect either. PS2: I have a simple work-around. +--- Kero - [EMAIL PROTECTED] ---+ | Don't split your mentality without thinking twice | | Proud like a God -- Guano Apes | +--- M38c -- http://huizen.dds.nl/~kero ---+
Layout bug
Hm, patch attached now...
+--- Kero - [EMAIL PROTECTED] ---+
| Don't split your mentality without thinking twice |
| Proud like a God -- Guano Apes |
+--- M38c -- http://huizen.dds.nl/~kero ---+
--- libraries/javalib/java/awt/oldGridLayout.java Thu Mar 22 00:30:16 2001
+++ libraries/javalib/java/awt/GridLayout.java Thu Mar 22 00:40:37 2001
@@ -108,13 +108,14 @@
}
public void layoutContainer ( Container parent) {
+ int nChildren = parent.getComponentCount(); // beware of Frame Menubars
+ if (nChildren == 0) return;
+
Insets in = parent.getInsets(); // getInsets() might be reimplemented (swing)
int tw = parent.width - in.left - in.right - hgap;
int th = parent.height - in.top - in.bottom - vgap;
- Dimension d = adjustDim( parent);
- int nChildren = parent.getComponentCount(); // beware of Frame Menubars
-
+ Dimension d = adjustDim( parent); // #rows & #columns
int cw = tw / d.width;
int ch = th / d.height;
Layout bug
Hello all, A bug in the GridLayout manager causes it not to layout when the Container has no children. No check is performed (neither is it in most other managers I suppose), but dividing width by the number of columns is a bad idea... I added a simple check, patch onto cvs (dd 11 March) attached. Bye, Kero. PS: I could not compile Klasses.jar with jikes 1.12 and 1.13, but succeedded with Sun's javac. +--- Kero - [EMAIL PROTECTED] ---+ | Don't split your mentality without thinking twice | | Proud like a God -- Guano Apes | +--- M38c -- http://huizen.dds.nl/~kero ---+
Re: deadlock bug fix
> > With this fix I seem to have no more unexpected deadlocks. > > Just to be on the safe side, does anyone know of similar > > "supposed to be atomic" operations? > > I didn't put in your generic version in order to encourage > you and others to look through your MIPS manual and submit a > working md version. We don't want to make kaffe too easy to port ;-) Unfortunately, this generic solution did NOT fix the (awt) deadlock problem I experience under HP-UX 11. Bye, Kero. +--- Kero - [EMAIL PROTECTED] ---+ | Don't split your mentality without thinking twice | | Proud like a God -- Guano Apes | +--- M38c -- http://huizen.dds.nl/~kero ---+
Re: Last Frame disposed; all threads dead?
> Didn't we have this discussion before? I did a short search in the archives, but it is a bit hard to find in the long lists. > Have you tried the java.awt.Defaults.AutoStop property? The what? A short look gives me java.awt.Defaults in Kaffe, but not in Sun's API. /** * If set to 'true', the last Window that is closed will automatically * call a System.exit() */ static boolean AutoStop = true; So... I have no problem with the dispatch thread dying (after all, there won't be any event anymore), but I want to process the entire event before it does. System.exit() is fine, but it is too early. Can you point me to the thread that discussed this or summarize the reasons not to pass the windowClosed() event? Bye, Kero. +--- Kero - [EMAIL PROTECTED] ---+ | Don't split your mentality without thinking twice | | Proud like a God -- Guano Apes | +--- M38c -- http://huizen.dds.nl/~kero ---+
Last Frame disposed; all threads dead?
Hello all, When the last Frame is dispose()d, the prompt returns. I assume all threads die when the last Frame is dispose()d. That's nice, but I am trying to catch the windowClosed() event. From that, I call my own quit() method. It is never reached. It is contrary to Sun behaviour: when using Sun jvm, my quit() method is called and the prompt does _not_ return. So: what happens to the EventDispatchThread when I dispose() my last Frame? Bye, Kero. +--- Kero - [EMAIL PROTECTED] ---+ | Don't split your mentality without thinking twice | | Proud like a God -- Guano Apes | +--- M38c -- http://huizen.dds.nl/~kero ---+
Re: Kaffe requires -g
> > So, the problem really is (and I just tried compiling Kaffe 3
> > different ways to really confirm this) that Kaffe won't compile
> > without -O2 or better. Specifically:
> > -O2 is okay (with or without -g)
> > -O1 fails
>
> Sounds like a problem with one of the asm() scripts (but you
> probably knew this). Some constraint or other is not being
> properly specified or something like that...
Not necessarily.
I once had a macro something like
#define GetTwoBytes(a, d) { d=a[0]++; d+=a[0]++<<8; }
either -O1 or -O2 went ``wrong'', the other did what I wanted. The
optimization did the increase of the array (pointer) immediately
(hence twice), or postponed until after the macro (only once).
Nowadays I use something less obscure.
Morale of the story: -Ox does not always keep the same execution result!
Bye,
Kero.
+--- Kero -- [EMAIL PROTECTED] ---+
| If there were no hell to pay, would you still need a God? |
| -- Leah Androne |
+--- M38C --- http://www.huizen.dds.nl/~kero ---+
Re: windowClosed is not called
> I have found that the method windowClosed() is not called under Kaffe for > classes implementing and adding WindowListener. Weird, it works for me. Kaffe 1.0.5 (src download from 22 Oct) +--- Kero -- [EMAIL PROTECTED] ---+ | If there were no hell to pay, would you still need a God? | | -- Leah Androne | +--- M38C --- http://www.huizen.dds.nl/~kero ---+
Re: BufferedInputReader
> > I encountered a small problem using the BufferedInputStream. > > When telling it to skip a big number of bytes, it stops at the first > > 2k boundary (or, more precisely, from position 32 to skip 37919 bytes > > lets it stop at position 2048). > > This is not a bug. The skip() method as defined in FilterInputStream > is not required to skip the number of bytes requested. > > Ref: >http://java.sun.com/products/jdk/1.2/docs/api/java/io/BufferedInputStream.html#skip(long) Forgive my ignorance! I guess there is no use in complaining about such a useless API in this newsgroup, is there? Sorry, but I could not possibly imagine that this was _not_ a bug... Not that ``for a variety of reasons'' is a clear way of telling when skip(n) might not skip n bytes. (if anybody knows an alternative call that I can use, mail me :-) I guess I'll ByteArray my files instead of Buffering them. Fast enough and no problems with 2k boundaries. Lucky for me my files are only several 100k long. > No code was stolen :-) Kaffe tries to behave like JDK whenever possible > and in this case is just using the same default buffer size (eg., 2048). Fine with me. Sorry if I appeared harsh. (But it is something to be wary about.) > Presumably, JDK and kaffe use the same (obvious) skip() algorithm, > i.e., skip remaining buffered data first. Apparently... It's good to test programs on >1 JVM, preferably 1.1 and 1.2 mixed. Merry Christmas everybody! Kero. +--- Kero -- [EMAIL PROTECTED] ---+ | If there were no hell to pay, would you still need a God? | | -- Leah Androne | +--- M38C --- http://www.huizen.dds.nl/~kero ---+
BufferedInputReader
Hi all! I encountered a small problem using the BufferedInputStream. When telling it to skip a big number of bytes, it stops at the first 2k boundary (or, more precisely, from position 32 to skip 37919 bytes lets it stop at position 2048). Removing the BufferedInputStream and using only the ByteArrayInputStream that is underneath works. The funny thing is that sun/blackdown: $ java -version java version "1.2" Classic VM (build Linux_JDK_1.2_pre-release-v2, native threads, sunwjit) has _exactly_ the same problem, where _exactly_ the same solution worked. I don't want to be rude, but who is stealing code from whom? Yours, Kero. +--- Kero -- [EMAIL PROTECTED] ---+ | If there were no hell to pay, would you still need a God? | | -- Leah Androne | +--- M38C --- http://www.huizen.dds.nl/~kero ---+
Re: Kaffe works under HP-UX
Hello! Should have changed the subject on the previous posting :-) The snapshot dd 28 May 1999 compiles and runs out of the box. > In combination with IceWm, Kaffe does not continue when I switch to > another virtual screen. That is, it consumes CPU cycles, but does > nothing useful. Both for Linux and HP-UX. WindowDeactivated problem? > Focus problem? IceWm problem? This [last] problem does not appear when I use CDE. +--- Kero -- [EMAIL PROTECTED] ---+ | I ain't changed, | | but I know I ain't the same | +--- M38C --- http://huizen.dds.nl/~kero ---+
Re: libtool-enhanced testing on HP-PA
> > Since HP-UX has neither working system call tracing (at least it > > doesn't work too well on our installation at work) or "ldd" > > AFAIR, HPsUX's ldd is called chatr (sp?). chatr exists, the man-page says "change program's internal attributes". ldd does not exist. > > Has the HP version been tested since the integration of libtool? > > Only two weeks ago someone spotted and fixed a bug in libltdl that > would prevent libltdl from minimally working on HP/UX. It's reported > to be working now (in libtool 1.3), but I don't think anyone has tried > Kaffe snapshots after my last libtool import. I'd appreciate any > feedback. A miracle just happened: compilation out-of-the-box of Kaffe managed to launch the biggest Java package I have written. That is, with shared libraries! (Somebody else may try the static ones :-) Kaffe works under HP/UX 10.20! OK, now the problems: I can't get a KeyEvent through my Canvas. I've had this same problem a couple of versions ago on Linux, where I tried to solve them with Focus, but without reaching compatibility with Sun's jdk. The problem has been solved for Linux, though, 'coz I remember popping up a Frame as a consequence of such a KeyEvent. Pressing TAB a few times kind-of worked then, but does cause any reaction, now. In combination with IceWm, Kaffe does not continue when I switch to another virtual screen. That is, it consumes CPU cycles, but does nothing useful. Both for Linux and HP-UX. WindowDeactivated problem? Focus problem? IceWm problem? Bye, Kero van Gelder. +--- Kero -- [EMAIL PROTECTED] ---+ | I ain't changed, | | but I know I ain't the same | +--- M38C --- http://huizen.dds.nl/~kero ---+
