Re: GTK peers

It seems that sometimes there is some threading problem which causes an Xlib error: Xlib: unexpected async reply (sequence 0x29)! Using kissme, if I enable some internal debugging (with -t jni), this is less likely to happen, so I think it's a thread timing issue. See what

Patches waiting to be committed ...

FYI: There are a number of Classpath patches on 'savannah' waiting to be applied by someone with commit privilege. 1571 fix for java.math.BigDecimal.setScale() 1487 Bad Permission in ObjectInputStream.enableResolveObject 1519 Fix typo in java.io.ObjectInputStream 1532 Fix equals/hashcode

Re: Patches waiting to be committed ...

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Mittwoch, 11. Juni 2003 17:15 schrieb Stephen Crawley: FYI: There are a number of Classpath patches on 'savannah' waiting to be applied by someone with commit privilege. 1571 fix for java.math.BigDecimal.setScale() 1487 Bad Permission in

Re: Patches waiting to be committed ...

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Mittwoch, 11. Juni 2003 17:15 schrieb Stephen Crawley: FYI: There are a number of Classpath patches on 'savannah' waiting to be applied by someone with commit privilege. 1571 fix for java.math.BigDecimal.setScale() Not my area. 1487 Bad

javax.swing.border (was: Classpath compilation error injavax/swing/plaf/BorderUIResource.java)

Sascha Brawer [EMAIL PROTECTED] wrote on Tue, 10 Jun 2003 19:21:16 +0200: I'll have a look at the existing code in the next few days and tell the list [about javax.swing.border]. I am now seriously working on the classes in javax.swing.border. Therefore, please do not change anything in that

Re: Patches waiting to be committed ...

Stephen == Stephen Crawley [EMAIL PROTECTED] writes: Stephen 1571 fix for java.math.BigDecimal.setScale() There's a discussion of this one taking place on the java-patches list. The patch has been rewritten but I haven't looked at the new one yet. If Per approves it, I'll make sure it gets

Re: Patches waiting to be committed ...

Stephen 1532 Fix equals/hashcode for DateFormat classes This one looks fine to me. I assume this was discovered by running some actual program? Otherwise I'd be surprised by this behavior. Yes indeed. I wrote a test program to create and compare DateFormat instances, and ran on

Re: Patches waiting to be committed ...

Stephen == Stephen Crawley [EMAIL PROTECTED] writes: Stephen Yes indeed. I wrote a test program to create and compare Stephen DateFormat instances, and ran on Classpath/Kissme and on Stephen various Sun JDKs. Could you put it into Mauve? That would be nice. Stephen On the second point, this