From tromey@redhat.com Wed Jan 30 12:01:00 2002 From: tromey@redhat.com (Tom Tromey) Date: Wed, 30 Jan 2002 12:01:00 -0000 Subject: bytecode verification Message-ID: <87g04n7fpo.fsf@creche.redhat.com> I've created a new module in the Mauve CVS repository called `verify'. This module is intended to include code that is useful for testing a bytecode verifier. Right now there are just two tests, and no build infrastructure, but hopefully it will expand over time. The existing tests require Jasmin, a Java bytecode assembler. This is readily available on the net and is GPL. For gcj users, I plan to import Jasmin into rhug. Feel free to add new tests. Both passes and failures are needed. When writing a test that is supposed to fail, you must be careful to ensure it fails in exactly the way you intend to test. How exactly the eventual build/test infrastructure should look for this is an open question. Tom From cbj@gnu.org Mon Feb 11 18:19:00 2002 From: cbj@gnu.org (Brian Jones) Date: Mon, 11 Feb 2002 18:19:00 -0000 Subject: oops Message-ID: I accidentally checked in my versions of configure, aclocal.m4, and Makefile.in. It probably doesn't matter, just a side affect of having these files checked into CVS. Brian -- Brian Jones From ebb9@email.byu.edu Sun Feb 17 17:50:00 2002 From: ebb9@email.byu.edu (Eric Blake) Date: Sun, 17 Feb 2002 17:50:00 -0000 Subject: mauve ./ChangeLog ./Makefile.in ./aclocal.m4 . ... References: <20020218014308.3023.qmail@sources.redhat.com> Message-ID: <3C705D7B.188890C1@email.byu.edu> cbj@sources.redhat.com wrote: > * gnu/testlet/java/text/MessageFormat/format.java (format): renamed > myformat because a class cannot have a method that has a return > type, i.e. is not a constructor, of the same name as the class. Actually, that is legal (although admittedly rare and unusual) Java. What compiler can't handle having a method named the same as its class? -- This signature intentionally left boring. Eric Blake ebb9@email.byu.edu BYU student, free software programmer From cbj@gnu.org Sun Feb 17 19:12:00 2002 From: cbj@gnu.org (Brian Jones) Date: Sun, 17 Feb 2002 19:12:00 -0000 Subject: mauve ./ChangeLog ./Makefile.in ./aclocal.m4 . ... In-Reply-To: <3C705D7B.188890C1@email.byu.edu> References: <20020218014308.3023.qmail@sources.redhat.com> <3C705D7B.188890C1@email.byu.edu> Message-ID: Eric Blake writes: > cbj@sources.redhat.com wrote: > > > * gnu/testlet/java/text/MessageFormat/format.java (format): renamed > > myformat because a class cannot have a method that has a return > > type, i.e. is not a constructor, of the same name as the class. > > Actually, that is legal (although admittedly rare and unusual) Java. > What compiler can't handle having a method named the same as its class? jikes 1.13. Brian -- Brian Jones From VISUAL@VISUALMICRO.COM.BR Sun Feb 24 10:22:00 2002 From: VISUAL@VISUALMICRO.COM.BR (DISTRIBUIDORA INFORMATICA) Date: Sun, 24 Feb 2002 10:22:00 -0000 Subject: ESTACA ACABANDO A PROMOÇÃO VOLTA AS AULAS APROVEITE!! Message-ID: SHOPPING VIRTUAL ?? AQUI WWW.VISUALMICRO.COM.BR Aproveite, tudo na ??rea de inform??tica, equipamentos, suprimentos, Cds, Processadores, Gravadoras, Mem??rias, consulte nossa loja, ou fa??a uma cota????o on-line. CD VIRGEM DR. HANK FOSCO/VERDE CLARO - 80MIN/700MB R$79.75 TUBO COM 100 UNIDADES GRAVADOR CD LG 16X10X40 R$262.84 IDE - OEM Se por ventura n??o quiser mais receber nossas propagandas, favor retornar o email com a titulo REMOVER! From VISUAL@VISUALMICRO.COM.BR Sun Feb 24 11:22:00 2002 From: VISUAL@VISUALMICRO.COM.BR (DISTRIBUIDORA INFORMATICA) Date: Sun, 24 Feb 2002 11:22:00 -0000 Subject: ESTACA ACABANDO A PROMOÇÃO VOLTA AS AULAS APROVEITE!! Message-ID: SHOPPING VIRTUAL ?? AQUI WWW.VISUALMICRO.COM.BR Aproveite, tudo na ??rea de inform??tica, equipamentos, suprimentos, Cds, Processadores, Gravadoras, Mem??rias, consulte nossa loja, ou fa??a uma cota????o on-line. CD VIRGEM DR. HANK FOSCO/VERDE CLARO - 80MIN/700MB R$79.75 TUBO COM 100 UNIDADES GRAVADOR CD LG 16X10X40 R$262.84 IDE - OEM Se por ventura n??o quiser mais receber nossas propagandas, favor retornar o email com a titulo REMOVER! From bclary@netscape.com Mon Feb 25 16:47:00 2002 From: bclary@netscape.com (Robert Clary) Date: Mon, 25 Feb 2002 16:47:00 -0000 Subject: Incorrect CSS on http://sources.redhat.com/mauve/ Message-ID: <3C7ADA08.3020804@netscape.com> Hello everyone. Can anyone point me to the web master for http://sources.redhat.com/mauve/? I have an evangelism bug filed on the page http://bugzilla.mozilla.org/show_bug.cgi?id=91357 where essentially the diagnosis is Over to evangelism. The stylesheet has: DIV.sidebar { position: float; background-image: url(img/sidebar.gif); background-repeat: no-repeat; background-position: left top; float: left; width: 110px; height: 600px; margin-left: 0px; border-left: 0px; padding-top: 12px; padding-left: 0px; border-width: 0; } DIV.content { position: float; float: right; padding-top: 12px; padding-left: 20px; overflow: hidden; border-width: 0; text-align: left; } Note the lack of a width for the div#content. Floated boxes _must_ have a width set... In this case, the width defaults to the width of the page, and the two floated boxes don't fit next to each other. This causes the page display to be not as intended in Mozilla based browsers. Thanks and sorry for the spam. Bob -- Bob Clary, bclary@netscape.com Technology Evangelist, Netscape Communications http://developer.netscape.com/evangelism/ From tromey@redhat.com Wed Feb 27 07:40:00 2002 From: tromey@redhat.com (Tom Tromey) Date: Wed, 27 Feb 2002 07:40:00 -0000 Subject: Incorrect CSS on http://sources.redhat.com/mauve/ In-Reply-To: bclary@netscape.com's message of "Mon, 25 Feb 2002 19:42:48 -0500" References: <3C7ADA08.3020804@netscape.com> Message-ID: <877koydi3o.fsf@creche.redhat.com> >>>>> "Robert" == Robert Clary writes: Robert> Can anyone point me to the web master for Robert> http://sources.redhat.com/mauve/? Could be me. Robert> Note the lack of a width for the div#content. Floated boxes Robert> _must_ have a width set... In this case, the width defaults Robert> to the width of the page, and the two floated boxes don't fit Robert> next to each other. I don't know anything about CSS, and I didn't write this web page. Could you send a patch to fix the problem? I'll install it. Tom From bclary@netscape.com Wed Feb 27 09:08:00 2002 From: bclary@netscape.com (Robert Clary) Date: Wed, 27 Feb 2002 09:08:00 -0000 Subject: Incorrect CSS on http://sources.redhat.com/mauve/ References: <3C7ADA08.3020804@netscape.com> <877koydi3o.fsf@creche.redhat.com> Message-ID: <3C7D1174.1000001@netscape.com> Tom Tromey wrote: >>>>>>"Robert" == Robert Clary writes: >>>>>> > >Robert> Can anyone point me to the web master for >Robert> http://sources.redhat.com/mauve/? > >Could be me. > >Robert> Note the lack of a width for the div#content. Floated boxes >Robert> _must_ have a width set... In this case, the width defaults >Robert> to the width of the page, and the two floated boxes don't fit >Robert> next to each other. > >I don't know anything about CSS, and I didn't write this web page. >Could you send a patch to fix the problem? I'll install it. > >Tom > I believe the simplest approach is to modify the style for DIV.content in http://sources.redhat.com/mauve/default.css Since the sidebar is already floated, the DIV.content does not need to be floated. So remove the position: float; float: right; from DIV.content and the page will display as intended in Mozilla and IE5.5+ Change DIV.content { position: float; float: right; padding-top: 12px; padding-left: 20px; overflow: hidden; border-width: 0; text-align: left; } to: DIV.content { padding-top: 12px; padding-left: 20px; overflow: hidden; border-width: 0; text-align: left; } Thanks, Bob -- Bob Clary, bclary@netscape.com Technology Evangelist, Netscape Communications http://developer.netscape.com/evangelism/ From tromey@redhat.com Mon Mar 4 07:56:00 2002 From: tromey@redhat.com (Tom Tromey) Date: Mon, 04 Mar 2002 07:56:00 -0000 Subject: Incorrect CSS on http://sources.redhat.com/mauve/ In-Reply-To: bclary@netscape.com's message of "Wed, 27 Feb 2002 12:03:48 -0500" References: <3C7ADA08.3020804@netscape.com> <877koydi3o.fsf@creche.redhat.com> <3C7D1174.1000001@netscape.com> Message-ID: <87y9h8i9me.fsf@creche.redhat.com> >>>>> "Robert" == Robert Clary writes: Robert> Since the sidebar is already floated, the DIV.content does not Robert> need to be floated. So remove the position: float; float: Robert> right; from DIV.content and the page will display as intended Robert> in Mozilla and IE5.5+ Thanks, I made this change. Tom From mark@klomp.org Sun Mar 31 16:06:00 2002 From: mark@klomp.org (Mark Wielaard) Date: Sun, 31 Mar 2002 16:06:00 -0000 Subject: BitSet.[x]or does (not) grow BitSet Message-ID: <1017619612.29655.23.camel@elsschot> Hi, Mauve contains an AcuniaBitSetTest and a jdk10 test for java.util.BitSet. The first assumes that an [x]or with another BitSet does not grow the original BitSet, the other assumes otherwise. Although the API documentation is not very clear I am inclined to go with the assumption that the BitSet does not grow. So I would like to check in the following to at least make both tests behave the same. --- jdk10.java 1999/03/21 09:59:56 1.3 +++ jdk10.java 2002/04/01 00:01:59 @@ -118,6 +118,8 @@ h.check( b2.toString().equals("{1, 2, 11, 15, 17, 200}") ); b2.xor(b2); h.check( b2.toString().equals("{}") ); + // No way to shrink the original BitSet, so create a new one. + // b2 = new BitSet(); b2.xor(b1); b3.or(b1); h.check( trulyEquals(b2,b3) ); (Context: b1 has bit 200 set, b2.length was 300, b3 is a new BitSet with default length.) Any objections? Cheers, Mark From tromey@redhat.com Sun Mar 31 16:17:00 2002 From: tromey@redhat.com (Tom Tromey) Date: Sun, 31 Mar 2002 16:17:00 -0000 Subject: BitSet.[x]or does (not) grow BitSet In-Reply-To: Mark Wielaard's message of "01 Apr 2002 02:06:52 +0200" References: <1017619612.29655.23.camel@elsschot> Message-ID: <87g02gxod7.fsf@creche.redhat.com> >>>>> "Mark" == Mark Wielaard writes: Mark> Although the API documentation is not very clear I am inclined Mark> to go with the assumption that the BitSet does not grow. I agree. I would be surprised by an implementation that grows the argument bitset. Mark> So I would like to check in the following to at least make both Mark> tests behave the same. Sounds good to me. Tom From ebb9@email.byu.edu Sun Mar 31 16:17:00 2002 From: ebb9@email.byu.edu (Eric Blake) Date: Sun, 31 Mar 2002 16:17:00 -0000 Subject: BitSet.[x]or does (not) grow BitSet References: <1017619612.29655.23.camel@elsschot> Message-ID: <3CA7A6F9.92E5D6B@email.byu.edu> Mark Wielaard wrote: > > Hi, > > Mauve contains an AcuniaBitSetTest and a jdk10 test for > java.util.BitSet. The first assumes that an [x]or with another BitSet > does not grow the original BitSet, the other assumes otherwise. > > Although the API documentation is not very clear I am inclined to go > with the assumption that the BitSet does not grow. So I would like to > check in the following to at least make both tests behave the same. I question your interpretation. The 1.4 docs state in the class description: "This class implements a vector of bits that grows as needed... Note that the size is related to the implementation of a bit set, so it may change with implementation. " > > --- jdk10.java 1999/03/21 09:59:56 1.3 > +++ jdk10.java 2002/04/01 00:01:59 > @@ -118,6 +118,8 @@ > h.check( b2.toString().equals("{1, 2, 11, 15, 17, 200}") ); > b2.xor(b2); > h.check( b2.toString().equals("{}") ); > + // No way to shrink the original BitSet, so create a new one. > + // b2 = new BitSet(); > b2.xor(b1); > b3.or(b1); > h.check( trulyEquals(b2,b3) ); > > (Context: b1 has bit 200 set, b2.length was 300, b3 is a new BitSet with > default length.) > > Any objections? Your patch does nothing, as the equals() method does not take size into account, so it does not matter whether b2 grew or not. Instead, you should patch AcuniaBitSetTest, because it is making blatant assumptions about the size of a bit set which do not have to be true, according to the specs I quoted. -- This signature intentionally left boring. Eric Blake ebb9@email.byu.edu BYU student, free software programmer From tromey@redhat.com Sun Mar 31 16:26:00 2002 From: tromey@redhat.com (Tom Tromey) Date: Sun, 31 Mar 2002 16:26:00 -0000 Subject: BitSet.[x]or does (not) grow BitSet In-Reply-To: Eric Blake's message of "Sun, 31 Mar 2002 17:16:57 -0700" References: <1017619612.29655.23.camel@elsschot> <3CA7A6F9.92E5D6B@email.byu.edu> Message-ID: <877knsxnyz.fsf@creche.redhat.com> >>>>> "Eric" == Eric Blake writes: Eric> "This class implements a vector of bits that grows as Eric> needed... Note that the size is related to the implementation of Eric> a bit set, so it may change with implementation. " Thanks for keeping us honest. It would be a weird implementation that did this, but I agree it is acceptable according to the docs. Based on this it sounds like we can't do any testing related to the size, since the size is implementation-defined. Tom From mark@klomp.org Sun Mar 31 16:51:00 2002 From: mark@klomp.org (Mark Wielaard) Date: Sun, 31 Mar 2002 16:51:00 -0000 Subject: BitSet.[x]or does (not) grow BitSet In-Reply-To: <3CA7A6F9.92E5D6B@email.byu.edu> References: <1017619612.29655.23.camel@elsschot> <3CA7A6F9.92E5D6B@email.byu.edu> Message-ID: <1017622305.13577.47.camel@elsschot> Hi, On Mon, 2002-04-01 at 02:16, Eric Blake wrote: > Mark Wielaard wrote: > > > > Although the API documentation is not very clear I am inclined to go > > with the assumption that the BitSet does not grow. So I would like to > > check in the following to at least make both tests behave the same. > > I question your interpretation. The 1.4 docs state in the class > description: > > "This class implements a vector of bits that grows as needed... Note > that the size is related to the implementation of a bit set, so it may > change with implementation. " The first sentence might be interpreted that this happens always, but the language of BitSet.or() and BitSet.xor() does not convince me immediatly. That last part is irrelevant since it talks about the size, an implementation aspect of a BitSet and not about the length. > > Any objections? > > Your patch does nothing, as the equals() method does not take size into > account, so it does not matter whether b2 grew or not. BitSet.equals() does indeed not take size into account since it is defined in terms of BitSet.set(). But the test is not about equals but about if a.or(b) takes bits of b into account that are not set/cleared in a. > Instead, you > should patch AcuniaBitSetTest, because it is making blatant assumptions > about the size of a bit set which do not have to be true, according to > the specs I quoted. I don't mind changing one or the other as long as they agree on the result. The problem with my original statement was that it talked about growing the BitSet which is not actually what these tests check. What they check is the following: - Given BitSet a = {1,2,3} BitSet b = {3,4,5} BitSet c = a.xor(b); - Is the result - c = {1,2} since bits 4 and 5 were not explicitly set or cleared in a. or - c = {1,2,4,5} since bits 3 and 5 are set in b. The language of BitSet.or() and BitSet.xor() is not clear to me about this issue. I arbitrarily took the interpretation of the first test. But since you recently rewrote the BitSet implementation for Classpath I am easily convinced that it should be the other way around :) Cheers, Mark From ebb9@email.byu.edu Sun Mar 31 17:13:00 2002 From: ebb9@email.byu.edu (Eric Blake) Date: Sun, 31 Mar 2002 17:13:00 -0000 Subject: BitSet.[x]or does (not) grow BitSet References: <1017619612.29655.23.camel@elsschot> <3CA7A6F9.92E5D6B@email.byu.edu> <1017622305.13577.47.camel@elsschot> Message-ID: <3CA7B3F7.870B9A03@email.byu.edu> Mark Wielaard wrote: > > I don't mind changing one or the other as long as they agree on the > result. > > The problem with my original statement was that it talked about growing > the BitSet which is not actually what these tests check. What they check > is the following: > > - Given > BitSet a = {1,2,3} > BitSet b = {3,4,5} > BitSet c = a.xor(b); > - Is the result > - c = {1,2} > since bits 4 and 5 were not explicitly set or cleared in a. > or > - c = {1,2,4,5} > since bits 3 and 5 are set in b. > > The language of BitSet.or() and BitSet.xor() is not clear to me about > this issue. I arbitrarily took the interpretation of the first test. But > since you recently rewrote the BitSet implementation for Classpath I am > easily convinced that it should be the other way around :) Well, a quick test on JDK 1.4 shows that Sun grows their BitSets (I purposefully spaced the bits to be beyond the 64-bit boundaries of long, to prove that growth is occuring): $ cat Blah.java class Blah { public static void main(String[] args) { BitSet a = new BitSet(); a.set(1); a.set(65); BitSet b = new BitSet(); b.set(1); b.set(129); System.out.println(a + " " + b); a.xor(b); System.out.println(a); } } $ java Blah {1, 65} {1, 129} {65, 129} -- This signature intentionally left boring. Eric Blake ebb9@email.byu.edu BYU student, free software programmer From mark@klomp.org Sun Mar 31 17:47:00 2002 From: mark@klomp.org (Mark Wielaard) Date: Sun, 31 Mar 2002 17:47:00 -0000 Subject: BitSet.[x]or does (not) grow BitSet In-Reply-To: <3CA7B3F7.870B9A03@email.byu.edu> References: <1017619612.29655.23.camel@elsschot> <3CA7A6F9.92E5D6B@email.byu.edu> <1017622305.13577.47.camel@elsschot> <3CA7B3F7.870B9A03@email.byu.edu> Message-ID: <1017625631.13577.67.camel@elsschot> Hi, On Mon, 2002-04-01 at 03:12, Eric Blake wrote: > Mark Wielaard wrote: > > > > The language of BitSet.or() and BitSet.xor() is not clear to me about > > this issue. I arbitrarily took the interpretation of the first test. But > > since you recently rewrote the BitSet implementation for Classpath I am > > easily convinced that it should be the other way around :) > > Well, a quick test on JDK 1.4 shows that Sun grows their BitSets And we all know that Sun's implementation is more accurate then their specification :) Thanks for testing Eric. I left the jdk10 tests alone except for removing one size() check and changed the AcuniaBitSetTest to take the extra bits in the given BitSet into account for BitSet.[x]or() and also removed all size() checks. If nobody complains I will check this in tomorrow. Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: BitSet.diff Type: text/x-patch Size: 4984 bytes Desc: URL: