From Dean.Andreakis@med.ge.com Thu Apr 3 21:38:00 2003 From: Dean.Andreakis@med.ge.com (Andreakis, Dean (MED)) Date: Thu, 03 Apr 2003 21:38:00 -0000 Subject: installing Message-ID: I downlaoded the 1-18-2003 snapshot and you said to run configure to instyall it but I dont see a configure executable. From robilad@yahoo.com Thu Apr 3 21:42:00 2003 From: robilad@yahoo.com (Dalibor Topic) Date: Thu, 03 Apr 2003 21:42:00 -0000 Subject: installing In-Reply-To: Message-ID: <20030403214244.78747.qmail@web10001.mail.yahoo.com> --- "Andreakis, Dean (MED)" wrote: > I downlaoded the 1-18-2003 snapshot and you said to > run configure to > instyall it but I dont see a configure executa autoreconf ; ./configure ; make ; make check cheers, dalibor topic __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - File online, calculators, forms, and more http://tax.yahoo.com From raif@fl.net.au Mon Apr 7 01:05:00 2003 From: raif@fl.net.au (Raif S. Naffah) Date: Mon, 07 Apr 2003 01:05:00 -0000 Subject: running Mauve with JikesRVM(+GNU Classpath) Message-ID: <200304071057.08288.raif@fl.net.au> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 hello there, if somebody is using the above combo to test GNU Classpath and security classes, can they confirm this (how-to-do): 1. build JikesRVM. which may download the Classpath CVS HEADs. 2. cd to the MAUVE test directory; eg. .../mauve-test 3. do: $ JAVAC="jikes -bootclasspath " \ JAVA="rvm -X:vmClasses=:<$RVM_BUILD/RVM.classes>" \ ../mauve/configure (unless there's an easier way) 4. do: $rm -rf .save-keys choices ; \ make check KEYS="security" TESTFLAGS="-verbose -debug" where a mauve-security contains something like: JDK1.0 JDK1.1 JDK1.2 JDK1.3 JDK1.4 !java.applet !java.awt !java.beans !java.io !java.lang !java.math !java.net !java.nio !java.rmi java.security !java.sql !java.text !java.util !javax. 5. the result should be (as of today): 0 of 164 tests failed cheer; rsn -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Que du magnifique iD8DBQE+kMzf+e1AKnsTRiERA+isAJ48WLdeixmWDecBL6i6hcJVnsjoHACg5SR/ jy/rkTHB4nN7wl2qGpy79/0= =JEzT -----END PGP SIGNATURE----- From raif@fl.net.au Mon Apr 7 02:10:00 2003 From: raif@fl.net.au (Raif S. Naffah) Date: Mon, 07 Apr 2003 02:10:00 -0000 Subject: [Jikesrvm-researchers] running Mauve with JikesRVM(+GNU Classpath) In-Reply-To: References: Message-ID: <200304071157.58580.raif@fl.net.au> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 On Monday 07 April 2003 11:25, Michael Hind wrote: > ... > We run the mauve tests on Jikes RVM+Classpath head nightly and > automatically post the results on the jikesrvm-regression list, > which is archived at > http://www-124.ibm.com/pipermail/jikesrvm-regression > > The results from Saturday night can be found here > > http://www-124.ibm.com/pipermail/jikesrvm-regression/2003-April/00184 >3.html noted. i'm more interested in coming up with a way of testing patches, and modifications to GNU Classpath _before_ checking them in. as you may have noticed, the included (my) how-to is not very reliable, since it depends on a build+install of GNU Classpath, before building JikesRVM. the ideal is to let a launcher use the .classes generated by JikesRVM jbuild script if possible. > It appears that the security tests were run and there were no > failures. thanks for your prompt reply + cheers; rsn -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Que du magnifique iD8DBQE+kNsi+e1AKnsTRiERA1l7AJ9cjVgqFIIX1LQ+lMSlHuHSbaxGmwCg29Xb c9c3AjExqbCCMjvXe4Lg08o= =uEUR -----END PGP SIGNATURE----- From raif@fl.net.au Mon Apr 7 11:57:00 2003 From: raif@fl.net.au (Raif S. Naffah) Date: Mon, 07 Apr 2003 11:57:00 -0000 Subject: [Jikesrvm-researchers] running Mauve with JikesRVM(+GNU Classpath) In-Reply-To: References: Message-ID: <200304072157.57044.raif@fl.net.au> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 hello David, On Mon, 7 Apr 2003 09:41 pm, David P Grove wrote: > Hi, > > I usually do the following for your step 3 (assuming you want > to test the glib.zip in the JikesRVM build directory. BTW, for > historical reasons glib.zip is copied into the build directory and > renamed to rvmrt.jar by the JikesRVM build process). > > $ JAVAC="$RVM_BUILD/jbuild.tool" \ > JAVA="rvm -X:h=100" \ > ../mauve/configure > > jbuild.tool is a script that invokes jikes passing it a bootclasspath > that includes all the .jar and .classes of the Jikes RVM build > directory. Jikes RVM's classpath includes the jar files in the build > directory automatically, so you don't have to specify that. thanks a bunch :-) cheers; rsn > --dave > > "Raif S. Naffah" > Sent by: jikesrvm-researchers-admin@www-124.southbury.usf.ibm.com > 04/06/2003 08:56 PM > Please respond to jikesrvm-researchers > > To: GNU Classpath , JikesRVM > , Mauve > > cc: > Subject: [Jikesrvm-researchers] running Mauve with > JikesRVM(+GNU Classpath) > > > hello there, > > if somebody is using the above combo to test GNU Classpath and > security classes, can they confirm this (how-to-do): > > 1. build JikesRVM. which may download the Classpath CVS HEADs. > 2. cd to the MAUVE test directory; eg. .../mauve-test > 3. do: > $ JAVAC="jikes -bootclasspath " \ > JAVA="rvm > -X:vmClasses=:<$RVM_BUILD/RVM.classes>" \ > ../mauve/configure > > (unless there's an easier way) > > 4. do: > $rm -rf .save-keys choices ; \ > make check KEYS="security" TESTFLAGS="-verbose -debug" > > where a mauve-security contains something like: > > JDK1.0 > JDK1.1 > JDK1.2 > JDK1.3 > JDK1.4 > > !java.applet > !java.awt > !java.beans > !java.io > !java.lang > !java.math > !java.net > !java.nio > !java.rmi > java.security > !java.sql > !java.text > !java.util > > !javax. > > 5. the result should be (as of today): > 0 of 164 tests failed -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Que du magnifique iD8DBQE+kWfA+e1AKnsTRiERA4+1AJ9dtUUwqUtVNokNj8E8Ntb2gx6KwgCg8Gao uYxeTt7f/kZNOIB8kbPayNU= =asiF -----END PGP SIGNATURE----- From crawley@dstc.edu.au Mon Apr 7 16:09:00 2003 From: crawley@dstc.edu.au (Stephen Crawley) Date: Mon, 07 Apr 2003 16:09:00 -0000 Subject: classpath ./ChangeLog ./THANKYOU ./configure.in... In-Reply-To: Message from Brian Jones of "06 Apr 2003 23:33:56 -0400." Message-ID: <200304071608.h37G8siE021877@piglet.dstc.edu.au> > Stephen Crawley writes: > > > I can confirm that there really is a problem running some of the Mauve > > security testlets under the latest Kissme, Classpath and Mauve. It appears > > to be a Kissme class loading problem, rather than the fault of the Classpath > > security implementation. I'm trying to get to the bottom of it ... The "bottom of it" is that the problem was not in Kissme or Classpath at all! The problem was that the failing test cases' constructors were not declared public. On Kissme, this (correctly IMO) caused the call to 'Class.newInstance' to throw an InstantiationException. I have fixed the Mauve testcases, and add a 'hint' to SimpleTestHarness to point people in the right direction in future. Three issues remain: * There is a bug in the implementation of Class.getConstructor in the Jikes RVM. It should not return a constructor unless it is declared as 'public'. * We need more comprehensive Mauve testcases for the the Java APIs for reflective programming, * There is a problem with Kissme's implementation of stack traces when an exception is thrown in a native method. It is getting the source line number wildly wrong. -- Steve From Patrick.Ellis@sas.com Mon Apr 7 20:32:00 2003 From: Patrick.Ellis@sas.com (Patrick Ellis) Date: Mon, 07 Apr 2003 20:32:00 -0000 Subject: FW: Question about Java Lang testcase JAVA.LANG.REFLECT.ARRAY.NEGATIVEARRAYSIZEEXCEPTION Message-ID: Pat Ellis SDE Build and Test Team Phone: (919) 531-0355 R2263 Patrick.Ellis@sas.com SAS... The Power to Know > -----Original Message----- > From: Patrick Ellis > Sent: Monday, April 07, 2003 4:31 PM > To: 'mauve-discuss@sources.redhat.com' > Subject: Question about Java Lang testcase JAVA.LANG.REFLECT.ARRAY.NEGATIVEARRAYSIZEEXCEPTION > > > Question about JAVA.LANG.REFLECT.ARRAY.NEGATIVEARRAYSIZEEXCEPTION. This is part of the testcase in java.lang. > > int val = 0; > Object x = null; > val = 0; > try > { > x = new int[0][-1]; > val = 1; > } > catch (NegativeArraySizeException e) > { > val = 2; > e.printStackTrace(System.out); > > } > > the testcase should throw an NegativeArraySizeException but because the negative -1 is the second element and 0 is the first element > some JVMs fail to throw the exception. Should the testcase be changed from x = new int[0][-1]; -----> x = new int[1][-1]; > > > Pat Ellis > SDE Build and Test Team > Phone: (919) 531-0355 > R2263 Patrick.Ellis@sas.com > SAS... The Power to Know > From felicitaciones@horizontes.us Mon Apr 7 21:59:00 2003 From: felicitaciones@horizontes.us (Vacacione gratis en crucero por el Caribe) Date: Mon, 07 Apr 2003 21:59:00 -0000 Subject: Usted y su famila ganaron vacaciones gratis en crucero Message-ID: <20030408000747.2593.qmail@techie.dhis.org> An HTML attachment was scrubbed... URL: From raif@fl.net.au Mon Apr 7 22:59:00 2003 From: raif@fl.net.au (Raif S. Naffah) Date: Mon, 07 Apr 2003 22:59:00 -0000 Subject: classpath ./ChangeLog ./THANKYOU ./configure.in... In-Reply-To: <200304071608.h37G8siE021877@piglet.dstc.edu.au> References: <200304071608.h37G8siE021877@piglet.dstc.edu.au> Message-ID: <200304080852.47734.raif@fl.net.au> -----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 hello Steve, On Tue, 8 Apr 2003 02:09 am, Stephen Crawley wrote: > > Stephen Crawley writes: > > > I can confirm that there really is a problem running some of the > > > Mauve security testlets under the latest Kissme, Classpath and > > > Mauve. It appears to be a Kissme class loading problem, rather > > > than the fault of the Classpath security implementation. I'm > > > trying to get to the bottom of it ... > > The "bottom of it" is that the problem was not in Kissme or Classpath > at all! good catch! mea culpa. > The problem was that the failing test cases' constructors were not > declared public. On Kissme, this (correctly IMO) caused the call to > 'Class.newInstance' to throw an InstantiationException... shouldnt this be an IllegalAccessException? as the docs states this exception is thrown "...if the class or its nullary constructor is not accessible." also, is it legal for a JVM to try altering the accessibility of a non-public, but nullary ctor, before bailing out, and then and only then throw an InstantiationException? the accessibility of a ctor can be altered as follows: /** Instantiate a class with a 0-arguments ctor. */ private static Object makeNewInstance0(String className) { Class c = null; Constructor ctor = null; Object result = null; try { c = Class.forName(className); ctor = c.getConstructor(null); result = c.newInstance(); } catch (IllegalAccessException x) { System.out.println(" * no --IllegalAccessException;" +"will attempt altering Accessibility..."); boolean accessible = ctor.isAccessible(); if (accessible) System.out.println(" * no --unable to, " +"although it's accessible..."); else { try { ctor.setAccessible(true); result = ctor.newInstance(null); } catch (SecurityException y) { System.out.println(" * no --a SecurityManager " +"is forbidding us to..."); } catch (Exception y) { // should not happen y.printStackTrace(System.err); } } } catch (Exception x) { x.printStackTrace(System.err); } return result; } cheers; rsn -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Que du magnifique iD8DBQE+kgE++e1AKnsTRiERA6JpAKDHogUsoAjDsHjq7buP+ahhO0warQCg349t 3sxj20HEsX47Y/UPdfrJsng= =KNJD -----END PGP SIGNATURE----- From crawley@dstc.edu.au Mon Apr 7 23:32:00 2003 From: crawley@dstc.edu.au (Stephen Crawley) Date: Mon, 07 Apr 2003 23:32:00 -0000 Subject: classpath ./ChangeLog ./THANKYOU ./configure.in... In-Reply-To: Message from "Raif S. Naffah" of "Tue, 08 Apr 2003 08:52:46 +1000." <200304080852.47734.raif@fl.net.au> Message-ID: <200304072332.h37NW9iE013522@piglet.dstc.edu.au> > > The problem was that the failing test cases' constructors were not > > declared public. On Kissme, this (correctly IMO) caused the call to > > 'Class.newInstance' to throw an InstantiationException... > > shouldnt this be an IllegalAccessException? as the docs states this > exception is thrown "...if the class or its nullary constructor is not > accessible." > > also, is it legal for a JVM to try altering the accessibility of a > non-public, but nullary ctor, before bailing out, and then and only > then throw an InstantiationException? Good questions. The JDK javadoc is not entirely clear on either of them. I'll try some experiments with various Sun JDKs -- Steve From ebb9@email.byu.edu Tue Apr 8 12:07:00 2003 From: ebb9@email.byu.edu (Eric Blake) Date: Tue, 08 Apr 2003 12:07:00 -0000 Subject: FW: Question about Java Lang testcase JAVA.LANG.REFLECT.ARRAY.NEGATIVEARRAYSIZEEXCEPTION References: Message-ID: <3E92BBAE.6000609@email.byu.edu> No. Sun admits that their VM is buggy for not throwing the exception in this case (search their BugParade database). Patrick Ellis wrote: >>the testcase should throw an NegativeArraySizeException but because the negative -1 is the second element and 0 is the first element >>some JVMs fail to throw the exception. Should the testcase be changed from x = new int[0][-1]; -----> x = new int[1][-1]; -- This signature intentionally left boring. Eric Blake ebb9@email.byu.edu BYU student, free software programmer From ebb9@email.byu.edu Tue Apr 8 14:29:00 2003 From: ebb9@email.byu.edu (Eric Blake) Date: Tue, 08 Apr 2003 14:29:00 -0000 Subject: FW: Question about Java Lang testcase JAVA.LANG.REFLECT.ARRAY.NEGATIVEARRAYSIZEEXCEPTION References: Message-ID: <3E92DCE9.8040200@email.byu.edu> More quotes from Sun (by the way, I was the submitter of the bug you quote from, 4433326): http://developer.java.sun.com/developer/bugParade/bugs/4433326.html FWIW, this contradicts the JVMS and the JLS. So it is a bug. I doubt if it makes a big difference to anyone either way, but the KVM behaves differently (and for once, they're right). xxxxx@xxxxx 2002-07-31 http://developer.java.sun.com/developer/bugParade/bugs/4723534.html I read that to say that all the dimension expressions are evaluated first, and the only problems noted at this point are expressions that cannot be evaluated. I do not think that an expression evaluating to zero can be considered to have completed abruptly. Then *all* the evaluated dimension values are checked to be nonnegative, and only after that is space allocated for the new array. I don't see any way to argue that encountering a zero dimension should terminate the checking for nonnegative values. But is the case that, as described, encountering a zero dimension when allocating terminates allocation of the subarrays. So I conclude that KVM is right, and the test and HotSpot are wrong! Unfortunately, this gets us back to a variant of the philosophical problem: the JLS appears to conflict with a longstanding behavior. This might turn into something that Gilad and I have to worry about resolving somehow, and it's possible that resolution would mean deciding that the spec is in fact in error. But in the meanwhile I don't think you have a bug. -- Tim Patrick Ellis wrote: > Eric, > > I forgot to include a comment made by Sun. > > > This is a comment from one of our designers ...... > I think this is a gray area that would be classified as "interpretation of the spec.". All the vendors get the same spec to implement, but the interpretation of things not explicitly stated varies. This would probably fall into that category, but in the bug that was submitted to Sun (about two years ago) that is pretty much the exact same example you have in your code, Sun stated that they do not consider this to be a bug. There are lots of cases where IBM and other vendors have tightened up the functionality over and above what the spec states as being required. > >>From Sun: > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ > > "The first array element is zero size therefore we silently discontinue evaluating next array element size. This will not be fixed. This is not a bug. If user puts [1][-1] an exception will be thrown as desired and spec'd. Closing as a will not fix. xxxxx@xxxxx 2002-04-08" > -- This signature intentionally left boring. Eric Blake ebb9@email.byu.edu BYU student, free software programmer From Daniel.Bonniot@inria.fr Wed Apr 9 11:24:00 2003 From: Daniel.Bonniot@inria.fr (Daniel Bonniot) Date: Wed, 09 Apr 2003 11:24:00 -0000 Subject: AWT tests Message-ID: <3E9402F9.1060106@inria.fr> Hi, Is Mauve accepting testcases for AWT classes? I see there are none at the moment. I found a bug in Classpath, for java.awt.color.ColorSpace, which is a JDK1.2 class. It would fit well with mauve, since it is not an interactive test. Are there plans to include the tests written by acunia into mauve? There are some JDK1.1 awt tests. Cvsweb: http://www.acunia.com/cgi-bin/cvsweb.cgi/open-wonka/tool/mauve/). Daniel From cbj@gnu.org Thu Apr 10 03:02:00 2003 From: cbj@gnu.org (Brian Jones) Date: Thu, 10 Apr 2003 03:02:00 -0000 Subject: AWT tests In-Reply-To: <3E9402F9.1060106@inria.fr> References: <3E9402F9.1060106@inria.fr> Message-ID: Daniel Bonniot writes: > Hi, > > Is Mauve accepting testcases for AWT classes? I see there are none at > the moment. Wonka has some tests... there was talk of I think creating another module to include such tests. Not sure though. Really requires someone to dedicate some time to setting this up and getting it going. > I found a bug in Classpath, for java.awt.color.ColorSpace, which is a > JDK1.2 class. It would fit well with mauve, since it is not an > interactive test. Probably could put such a test into Mauve. Perhaps we should have a policy of putting all non-interactive tests that do not require a DISPLAY into Mauve? Brian -- Brian Jones From cbj@gnu.org Thu Apr 10 03:05:00 2003 From: cbj@gnu.org (Brian Jones) Date: Thu, 10 Apr 2003 03:05:00 -0000 Subject: problems with "InputStreamReader.read" tests in "java.io.Utf8Encoding" In-Reply-To: <200303271409.JAA21042@login006.unx.sas.com> References: <200303271409.JAA21042@login006.unx.sas.com> Message-ID: Steve Murry writes: > (I'm reposting my earlier email due to format problems. Sorry 'bout that) > > > Can someone check the 'negative' testcases within > java.io.Utf8Encoding.mojo to see if these are valid tests or not? > Specifically, I'm referring to the 9 testcases with data values that > are declared 'test5_bytes' through 'test13_bytes'. The testcases > expect a CharEncodingException when decoding illegal UTF-8 byte > strings. In some cases the UTF-8 data is incorrect and in others it > represents codepoints that have not yet been assigned (at least for > Unicode 3.2). As I read the Sun API description for > InputStreamReader.read, I would expect either > MalformedInputException or UTFDataFormatException to be thrown > instead (the API description doesn't seem very precise in this > area). In fact, most of the platforms that we have run these > testcases against do not throw any type of exception at all! Only > the IBM JREs throw the expected CharConversionException. We also > found the following paragraph in one of the Sun bug descriptions: > > >This is a bug in the tests. The specification of > >java.io.InputStreamReader does not require that an implementation > >throw IOExceptions on malformed input when decoding bytes in the > >UTF-8 charset. That our implementation has done this historically > >is a bug that was fixed as part of 4503732. > > I'm not sure I agree with this statement myself (BTW - I believe > they are referring to one of their own internal tests, not Mauve), > but I'm just trying to get Mauve's take on all of this. I would > appreciate anyone's thoughts. I'm not a Character/UTF-8/Unicode expert so I don't think I can answer your question. Brian -- Brian Jones From Patrick.Ellis@sas.com Thu Apr 10 20:41:00 2003 From: Patrick.Ellis@sas.com (Patrick Ellis) Date: Thu, 10 Apr 2003 20:41:00 -0000 Subject: Questions about exception error with gnu.testlet.java.io.PrintWriter.jdk11 & gnu.testlet.java.io.FilterWriter.write Message-ID: I get the following exceptions when trying to compile gnu.testlet.java.io.PrintWriter.jdk11 & gnu.testlet.java.io.FilterWriter.write. Is there anything in the code missing or is the URLpackage missing? *********************** Code for gnu.testlet.java.io.FilterWriter.write // the Free Software Foundation, 59 Temple Place - Suite 330, // Boston, MA 02111-1307, USA. */ package gnu.testlet.java.io.FilterWriter; import java.io.CharArrayWriter; import java.io.FilterWriter; import java.io.Writer; import java.io.*; import gnu.testlet.Testlet; import gnu.testlet.TestHarness; public class write extends FilterWriter implements Testlet { public write() { this(null); } write (CharArrayWriter caw) { super((Writer) caw); } public void test (TestHarness harness) { CharArrayWriter caw = new CharArrayWriter(); write tfw = new write(caw); try { tfw.write('A'); // A harness.check(true, "write(int)"); char[] ba = {'A', 'B', 'C', 'D'}; tfw.write(ba, 1, 2); // ABC harness.check(true, "write(buf,off,len)"); tfw.write("CDEF", 1, 3); // ABCDEF harness.check(caw.toString(), "ABCDEF", "wrote all characters okay"); tfw.flush(); harness.check(true, "flush()"); tfw.close(); harness.check(true, "close()"); } catch (IOException e) { harness.fail("IOException unexpected"); } } } ******************************* Code for gnu.testlet.java.io.PrintWriter.jdk11 // Tags: JDK1.1 package gnu.testlet.java.io.PrintWriter; import gnu.testlet.Testlet; import gnu.testlet.TestHarness; import java.io.PrintWriter; import java.io.ByteArrayOutputStream; import java.io.OutputStream; import java.io.CharArrayWriter; public class jdk11 extends PrintWriter implements Testlet { public jdk11() { this(null); } jdk11(OutputStream os) { super(os); } public void print(int i, boolean err) { if (err) { this.setError(); } } public String toString() { return ("ObjectString"); } public void test(TestHarness harness) { // Test constructors first ByteArrayOutputStream baos1 = new ByteArrayOutputStream(); PrintWriter pw1 = new PrintWriter(baos1); harness.check(pw1 != null, "PrintWriter(OutputStream)"); ByteArrayOutputStream baos2 = new ByteArrayOutputStream(); PrintWriter pw2 = new PrintWriter(baos2, true); harness.check(pw2 != null, "PrintWriter(OutputStream, boolean)"); CharArrayWriter caw1 = new CharArrayWriter(); PrintWriter pw3 = new PrintWriter(caw1); harness.check(pw3 != null, "PrintWriter(Writer)"); CharArrayWriter caw2 = new CharArrayWriter(); PrintWriter pw4 = new PrintWriter(caw2); harness.check(pw4 != null, "PrintWriter(Writer)"); // Now test the methods pw1.print(true); pw1.print(false); pw1.print('X'); char[] ca = {'A', 'B', 'C'}; pw1.print(ca); double x = 3.14; pw1.print(x); float y = (float) 1.414; pw1.print(y); int i = 37; pw1.print(i); long l = 65537L; pw1.print(l); pw1.print(new jdk11()); pw1.print("XYZ"); pw1.write(ca); pw1.write(ca,0,2); pw1.write('Q'); pw1.write("JKL"); pw1.write("MNOPQ", 1, 2); pw1.println(); pw1.println(true); pw1.println(false); pw1.println('X'); pw1.println(ca); pw1.println(x); pw1.println(y); pw1.println(i); pw1.println(l); pw1.println(new jdk11()); pw1.println("XYZ"); pw1.flush(); harness.check(true, "flush()"); pw1.close(); harness.check(true, "close()"); String tst = "truefalseXABC3.141.4143765537ObjectStringXYZABCABQJKLNO\n" + "true\nfalse\nX\nABC\n3.14\n1.414\n37\n65537\nObjectString\nXYZ\n"; harness.check(baos1.toString(), tst, "All characters printed okay"); harness.debug("Final output:" + baos1.toString()); // Set up to test setError() and checkError() ByteArrayOutputStream baos3 = new ByteArrayOutputStream(); jdk11 tpw = new jdk11(baos3); harness.check(!tpw.checkError(), "checkError"); tpw.print(3, true); // forces call to setError harness.check(tpw.checkError(), "setError"); } } // class Test java.lang.ClassNotFoundException: gnu.testlet.java.io.FilterWriter.write at java.net.URLClassLoader$1.run(URLClassLoader.java:198) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:186) at java.lang.ClassLoader.loadClass(ClassLoader.java:299) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:265) at java.lang.ClassLoader.loadClass(ClassLoader.java:255) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:315) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:140) at gnu.testlet.SimpleTestHarness.runtest(SimpleTestHarness.java:195) at gnu.testlet.SimpleTestHarness.main(SimpleTestHarness.java:349) FAIL: uncaught exception loading gnu.testlet.java.io.PrintWriter.jdk11 java.lang.ClassNotFoundException: gnu.testlet.java.io.PrintWriter.jdk11 at java.net.URLClassLoader$1.run(URLClassLoader.java:198) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:186) at java.lang.ClassLoader.loadClass(ClassLoader.java:299) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:265) at java.lang.ClassLoader.loadClass(ClassLoader.java:255) at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:315) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:140) at gnu.testlet.SimpleTestHarness.runtest(SimpleTestHarness.java:195) at gnu.testlet.SimpleTestHarness.main(SimpleTestHarness.java:349) Pat Ellis SDE Build and Test Team Phone: (919) 531-0355 R2263 Patrick.Ellis@sas.com SAS... The Power to Know From cbj@gnu.org Fri Apr 11 12:39:00 2003 From: cbj@gnu.org (Brian Jones) Date: Fri, 11 Apr 2003 12:39:00 -0000 Subject: Questions about exception error with gnu.testlet.java.io.PrintWriter.jdk11 & gnu.testlet.java.io.FilterWriter.write In-Reply-To: References: Message-ID: "Patrick Ellis" writes: > I get the following exceptions when trying to compile > gnu.testlet.java.io.PrintWriter.jdk11 & > gnu.testlet.java.io.FilterWriter.write. Is there anything in the > code missing or is the URLpackage missing? Seems okay to me. jikes -bootclasspath /home/cbj/cvs/classpath/build/lib/glibj.zip -classpath /home/cbj/cvs/mauve -d . gnu/testlet/java/io/FilterWriter/write.java gnu/testlet/java/io/PrintWriter/jdk11.java OR jikes -bootclasspath /usr/java/j2sdk1.4.1/jre/lib/rt.jar -classpath /home/cbj/cvs/mauve -d . gnu/testlet/java/io/FilterWriter/write.java gnu/testlet/java/io/PrintWriter/jdk11.java Both complete without error. Brian -- Brian Jones From tromey@redhat.com Fri Apr 11 17:03:00 2003 From: tromey@redhat.com (Tom Tromey) Date: Fri, 11 Apr 2003 17:03:00 -0000 Subject: AWT tests In-Reply-To: References: <3E9402F9.1060106@inria.fr> Message-ID: <877ka1gef8.fsf@fleche.redhat.com> Brian> Probably could put such a test into Mauve. Perhaps we should have a Brian> policy of putting all non-interactive tests that do not require a Brian> DISPLAY into Mauve? Definitely. If someone wants to try to tackle tests needing some sort of display, we can make a new module in cvs for them. Tom From robilad@yahoo.com Sat Apr 12 18:32:00 2003 From: robilad@yahoo.com (Dalibor Topic) Date: Sat, 12 Apr 2003 18:32:00 -0000 Subject: [patch] new java.sql tests Message-ID: <20030412183214.63460.qmail@web10007.mail.yahoo.com> Hi, attached you'll find a couple of new java.sql tests. They test for handling of bad arguments and illegal method calls in their classes. A patch fixing the issues for GNU classpath has been already checked into the GNU Classpath CVS tree. ChangeLog entry: gnu/testlet/java/sql/Date/DateTest.java, gnu/testlet/java/sql/DriverManager/DriverManagerTest.java, gnu/testlet/java/sql/Time/TimeTest.java, gnu/testlet/java/sql/Timestamp/TimestampTest.java: new files. cheers, dalibor topic __________________________________________________ Do you Yahoo!? Yahoo! Tax Center - File online, calculators, forms, and more http://tax.yahoo.com -------------- next part -------------- A non-text attachment was scrubbed... Name: mauve-sql-patch Type: application/octet-stream Size: 9320 bytes Desc: mauve-sql-patch URL: From cbj@gnu.org Sun Apr 13 13:22:00 2003 From: cbj@gnu.org (Brian Jones) Date: Sun, 13 Apr 2003 13:22:00 -0000 Subject: [patch] new java.sql tests In-Reply-To: <20030412183214.63460.qmail@web10007.mail.yahoo.com> References: <20030412183214.63460.qmail@web10007.mail.yahoo.com> Message-ID: Dalibor Topic writes: > Hi, > > attached you'll find a couple of new java.sql tests. They test for handling of > bad arguments and illegal method calls in their classes. A patch fixing the > issues for GNU classpath has been already checked into the GNU Classpath CVS > tree. > > ChangeLog entry: > > gnu/testlet/java/sql/Date/DateTest.java, > gnu/testlet/java/sql/DriverManager/DriverManagerTest.java, > gnu/testlet/java/sql/Time/TimeTest.java, > gnu/testlet/java/sql/Timestamp/TimestampTest.java: > new files. > > cheers, > dalibor topic Thanks, checked in. Brian -- Brian Jones From bcall@precise.com Wed Apr 16 18:54:00 2003 From: bcall@precise.com (Brian Call) Date: Wed, 16 Apr 2003 18:54:00 -0000 Subject: Autoconf problems? Message-ID: <3FCEB666DA97D511BA840002A564C1D986B4CE@EXCHANGE-CO> Hi Guys, I'm having some problems getting autoconf to generate the configure script. I'm not much of a wiz with autoconf but I've tried everything I can think of (including getting the latest version) to no avail. Here are the error messages I'm seeing when running the autoconf from the mauve base directory: $ autoconf configure.in:3: error: possibly undefined macro: AM_INIT_AUTOMAKE If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure.in:13: error: possibly undefined macro: AM_CONDITIONAL configure.in:42: error: possibly undefined macro: AM_PROG_GCJ Does anyone, by chance, know what the heck I'm doing wrong? Also, I couldn't find anything in the docs on using the m4_pattern_allow flag. Any thoughts? I'm running Win2k with Cygwin.... Any help is greatly, greatly appreciated. Thanks, Brian Call From cbj@gnu.org Wed Apr 16 20:24:00 2003 From: cbj@gnu.org (Brian Jones) Date: Wed, 16 Apr 2003 20:24:00 -0000 Subject: Autoconf problems? In-Reply-To: <3FCEB666DA97D511BA840002A564C1D986B4CE@EXCHANGE-CO> References: <3FCEB666DA97D511BA840002A564C1D986B4CE@EXCHANGE-CO> Message-ID: Brian Call writes: > Hi Guys, > > I'm having some problems getting autoconf to generate the configure script. > I'm not much of a wiz with autoconf but I've tried everything I can think of > (including getting the latest version) to no avail. Here are the error > messages I'm seeing when running the autoconf from the mauve base directory: I'll probably regret responding without trying myself... but the usual invocation from CVS is `aclocal;automake;autoconf'. aclocal updates aclocal.m4 which is where autoconf should find the macros you mention. aclocal should complain if it cannot find them in /usr/share/aclocal/. Hope that helps. Brian -- Brian Jones From moreinfo@eclisped.com Tue Apr 22 16:18:00 2003 From: moreinfo@eclisped.com (Sherman K. Daniels) Date: Tue, 22 Apr 2003 16:18:00 -0000 Subject: Get Paid Daily! Message-ID: Congratulations! You're in the right place at the right time! Pre-Paid Legal is the right company and is the right opportunity you've been looking for! More than half of all households have a legal situation right now. -Legal Needs and Civil Justice Survey, published by the American Bar Association Even law abiding Americans will encounter a legal situation an average of four to six times per year. -National Resource Center for Consumers of Legal Services You are nearly three times more likely to be in court than you are to be hospitalized. -National Center for State Courts/American Hospital Association Hospitalization vs. Court So how does it work, and how do you get paid every day? Click Here: http://www.prepaidlegal.com/go/daniels_s Testimonials: "Because of Pre-Paid Legal, we've lived a life that most people only dream about." - Fran Alexander California "I know have a personal life that includes church, family, and community service in addition to Pre-Paid Legal." -John Akins Missouri _____________________________________________________________________ This is an unsolicited commercial email message. If you would like to be removed from any future mailings about the product or opportunity of Pre-Paid Legal Services, Inc., and subsidiaries, please reply and type "REMOVE" in the Subject line. From lpmlm@thepostmaster.net Fri May 9 06:29:00 2003 From: lpmlm@thepostmaster.net (MLM Tools) Date: Fri, 09 May 2003 06:29:00 -0000 Subject: How to Create a Recruiting Explosion - FREE REPORT Message-ID: <200305090629.h496Tk8R011571@smtp22.singnet.com.sg> ============================== Spam notice and removal below ============================== Hi Friend, Regardless of whether you are a seasoned MLM Pro or beginner... Discover: "The most powerful recruiting technique in the free world." Fast Track Secrets revealed in this incredible FREE REPORT! Limited edition so act now! Click below to get your copy today! mailto:treasure88@buildreferrals.com?subject=LP_MORE_INFO To your success! Kent T. P.S I'll show you a secret on how to make money on your Pre Qualified Leads as well! That's called: Self-Liquidating-Lead-Generation! So in other words, you are gonna make money in the Front End as well..,just like the Pro's in MLM do! Earn WHILE recruiting...this is brilliant! ==================================================== This e-mail is NOT spam. Your email address was purchased from a list-provider as someone who is interested in receiving more information about making money from a home-based business. This list may or may not be 100% accurate. Under Bill S. 1618, Title III, Section 301 passed by the 105th US Congress, an e-mail cannot be considered spam as long as the sender includes contact information and a method of removal. You can remove yourself from this list by sending this message to lpmlm@thepostmaster.net with the word "Remove" in the subject line. ===================================================== From Daniel.Bonniot@inria.fr Thu May 22 20:18:00 2003 From: Daniel.Bonniot@inria.fr (Daniel Bonniot) Date: Thu, 22 May 2003 20:18:00 -0000 Subject: [patch] java/awt/color/ColorSpace Message-ID: <3ECD308A.5040201@inria.fr> Hi, I send a new testcae some time ago to mauve-patches, but nobody picked it up. It was suggested that muve-patches is not very active, so may it is worth to resend it here. This case concerns java.awt, but it does not require a display to run. It fails on all free vms I tried (it did one month ago, at least), but passes on Blackdown. This is my first patch, so please check it conforms to Mauve's standards. I did my best to ensure that, and it seems to work. 2003-04-10 Daniel Bonniot * gnu/testlet/java/awt/color/ColorSpace/isCS_sRGB.java: New file. I have at least two other tests to contribute. Should I send them to this list? Daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: isCS_sRGB.java Type: text/x-java Size: 1193 bytes Desc: not available URL: From mark@klomp.org Fri May 23 14:08:00 2003 From: mark@klomp.org (Mark Wielaard) Date: Fri, 23 May 2003 14:08:00 -0000 Subject: [patch] java/awt/color/ColorSpace In-Reply-To: <3ECD308A.5040201@inria.fr> References: <3ECD308A.5040201@inria.fr> Message-ID: <1053698920.26575.168.camel@elsschot> Hi, On Thu, 2003-05-22 at 22:18, Daniel Bonniot wrote: > I send a new testcae some time ago to mauve-patches, but nobody picked > it up. It was suggested that muve-patches is not very active, so may it > is worth to resend it here. Sorry about that, we must have missed it the first time. Thanks for sending it again. > This case concerns java.awt, but it does not require a display to run. > It fails on all free vms I tried (it did one month ago, at least), but > passes on Blackdown. > This is my first patch, so please check it conforms to Mauve's > standards. I did my best to ensure that, and it seems to work. > > 2003-04-10 Daniel Bonniot > > * gnu/testlet/java/awt/color/ColorSpace/isCS_sRGB.java: New file. Thanks, it looks good. I checked it in as is. > I have at least two other tests to contribute. Should I send them to > this list? Yes please. Cheers, Mark From Daniel.Bonniot@inria.fr Sat May 24 20:22:00 2003 From: Daniel.Bonniot@inria.fr (Daniel Bonniot) Date: Sat, 24 May 2003 20:22:00 -0000 Subject: [patch] New tests Message-ID: <3ECFD489.4060809@inria.fr> Hi, Here are two new tests, for collection features that used to be wrong in Kaffe. One is about java.util.LinkedList. Although it is already well tested in Mauve, one missing aspect was the behaviour of subList. The other tests the java.util.Arrays.equals method, in particular that it accepts when the arrays have null components. Daniel -------------- next part -------------- A non-text attachment was scrubbed... Name: SubListTest.java Type: text/x-java Size: 1637 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: equals.java Type: text/x-java Size: 1141 bytes Desc: not available URL: From mark@klomp.org Sat May 24 23:19:00 2003 From: mark@klomp.org (Mark Wielaard) Date: Sat, 24 May 2003 23:19:00 -0000 Subject: [patch] New tests In-Reply-To: <3ECFD489.4060809@inria.fr> References: <3ECFD489.4060809@inria.fr> Message-ID: <1053818381.26575.399.camel@elsschot> Hi, On Sat, 2003-05-24 at 22:22, Daniel Bonniot wrote: > Here are two new tests, for collection features that used to be wrong in > Kaffe. Installed as follows: 2003-05-24 Daniel Bonniot * gnu/testlet/java/util/Arrays/equals.java: New file. * gnu/testlet/java/util/LinkedList/SubListTest.java: New file. Thanks, Mark From pwbizzgicomppu@centerlink.com.br Sat Jun 7 07:37:00 2003 From: pwbizzgicomppu@centerlink.com.br (Fabio) Date: Sat, 07 Jun 2003 07:37:00 -0000 Subject: Inverno na Montanha Message-ID: Casa em Campos do Jord??o. A melhor op????o para fam??lias de bom gosto. Rec??m construida, privacidade, conforto e estilo de vida. Alugue para final de semana e temporada. Visite: http://campos.da.ru Fabio D??vidas pelo email: casaemcampos@ibest.com.br Para ser removido de futuros correios, por favor, envie email para lubava@ibest.com.br, com o assunto REMOVER. Obrigado. From dhazeghi@yahoo.com Sun Jun 8 07:01:00 2003 From: dhazeghi@yahoo.com (Dara Hazeghi) Date: Sun, 08 Jun 2003 07:01:00 -0000 Subject: Build Error Message-ID: <20030608070107.45208.qmail@web41104.mail.yahoo.com> Hello, I just checked the latest mauve out of cvs, set GCJ to the appropriate executable, ran autoreconf; ./configure --with-gcj; make check make check fails with (apologies for yahoo's munging of the messages)... gnu/testlet/java/net/Socket/TestSocketImplFactory.o(.text+0x0): In function `gnu::testlet::java::net::Socket::TestSocketImplFactory::createSocketImpl()': gnu/testlet/java/net/Socket/TestSocketImplFactory.java:30: multiple definition of `gnu::testlet::java::net::Socket::TestSocketImplFactory::createSocketImpl()' gnu/testlet/java/net/Socket/TestSocketImplFactory.o(.text+0x0):gnu/testlet/java/net/Socket/TestSocketImplFactory.java:30: first defined here gnu/testlet/java/net/Socket/TestSocketImplFactory.o(.text+0x10): In function `gnu::testlet::java::net::Socket::TestSocketImplFactory::TestSocketImplFactory[in-charge]()': gnu/testlet/java/net/Socket/TestSocketImplFactory.java:1: multiple definition of `gnu::testlet::java::net::Socket::TestSocketImplFactory::TestSocketImplFactory[in-charge]()' gnu/testlet/java/net/Socket/TestSocketImplFactory.o(.text+0x10):gnu/testlet/java/net/Socket/TestSocketImplFactory.java:1: first defined here gnu/testlet/java/net/Socket/TestSocketImplFactory.o(.data+0x40): multiple definition of `vtable for gnu::testlet::java::net::Socket::TestSocketImplFactory' gnu/testlet/java/net/Socket/TestSocketImplFactory.o(.data+0x40): first defined here gnu/testlet/java/net/Socket/TestSocketImplFactory.o(.data+0x80): multiple definition of `gnu::testlet::java::net::Socket::TestSocketImplFactory::class$' gnu/testlet/java/net/Socket/TestSocketImplFactory.o(.data+0x80): first defined here collect2: ld returned 1 exit status make[1]: *** [SimpleTestHarness] Error 1 make[1]: Leaving directory `/tmp/mauve' make: *** [check-am] Error 2 Is this a known problem, or did I miss something obvious when building? Thanks, Dara __________________________________ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com From mark@klomp.org Sun Jun 8 10:31:00 2003 From: mark@klomp.org (Mark Wielaard) Date: Sun, 08 Jun 2003 10:31:00 -0000 Subject: Build Error In-Reply-To: <20030608070107.45208.qmail@web41104.mail.yahoo.com> References: <20030608070107.45208.qmail@web41104.mail.yahoo.com> Message-ID: <1055068305.810.930.camel@elsschot> Hi, On Sun, 2003-06-08 at 09:01, Dara Hazeghi wrote: > I just checked the latest mauve out of cvs, set GCJ to > the appropriate executable, ran autoreconf; > ./configure --with-gcj; make check > > make check fails with (apologies for yahoo's munging > of the messages)... > [...] > > Is this a known problem, or did I miss something > obvious when building? Thanks, Each VM that uses Mauve should come with a keys file that tells which Mauve tests can be compiled/run with it. For gcj these are in cvs as libjava/mauve-libgcj. You will see that When you place this file in the mauve top-level directory you can do a 'make check KEYS=libgcj'. gcj can also use mauve from its own testsuite. See the section "Additional testing for Java Class Libraries" in http://gcc.gnu.org/install/test.html OK. I see that the configure --with-gcj which does a native compile seems to be broken (almost same error as you have). Hmmmm. Will investigate later. In the meantime you can use gcj in "traditional" mode as normal byte code compiler and interpreter by configuring as: $ JAVA=gij-3.3 JAVAC="gcj-3.3 -C" ../mauve/configure $ make check KEYS=libgcj Cheers, Mark From mark@klomp.org Sun Jun 8 12:40:00 2003 From: mark@klomp.org (Mark Wielaard) Date: Sun, 08 Jun 2003 12:40:00 -0000 Subject: Build Error In-Reply-To: <1055068305.810.930.camel@elsschot> References: <20030608070107.45208.qmail@web41104.mail.yahoo.com> <1055068305.810.930.camel@elsschot> Message-ID: <1055076035.779.1074.camel@elsschot> Hi, On Sun, 2003-06-08 at 12:31, Mark Wielaard wrote: > OK. I see that the configure --with-gcj which does a native compile > seems to be broken (almost same error as you have). Hmmmm. Will > investigate later. The problems comes from the fact that we are now sometimes using a class both as a test and as an helper class for another test. This means that we have to make sure that the combination of 'choices' and the 'uses' only contain each class once. The attached patch does this. 2003-06-08 Mark Wielaard * choose: Add all classes first to usesfile to uniqify them later before adding them to choises. I have checked it in. It should fix your problem. For me the following now works: $ GCJ=gcj-3.3 ../mauve/configure --with-gcj $ make check KEYS=libgcj Which gives: 174 of 7979 tests failed (Using a slightly tweaked mauve-libgcj) Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: choose.diff Type: text/x-patch Size: 619 bytes Desc: not available URL: From dhazeghi@yahoo.com Mon Jun 9 01:56:00 2003 From: dhazeghi@yahoo.com (Dara Hazeghi) Date: Mon, 09 Jun 2003 01:56:00 -0000 Subject: Build Error In-Reply-To: <1055076035.779.1074.camel@elsschot> Message-ID: <20030609015645.98958.qmail@web41107.mail.yahoo.com> > The problems comes from the fact that we are now > sometimes using a class > both as a test and as an helper class for another > test. This means that > we have to make sure that the combination of > 'choices' and the 'uses' > only contain each class once. The attached patch > does this. Thanks Mark, your patch seems to have fixed that problem. Now though, I can't just do: echo gnu.testlet.java.lang.Character.unicode | ./SimpleTestHarness from the directory I did make check in. I get: FAIL: uncaught exception loading gnu.testlet.java.lang.Character.unicode: java.lang.ClassNotFoundException: gnu.testlet.java.lang.Character.unicode not found in [file:./, core:/] java.lang.ClassNotFoundException: gnu.testlet.java.lang.Character.unicode not found in [file:./, core:/] at java.net.URLClassLoader.findClass(java.lang.String) (/tmp/dara/lib/libgcj.so.4.0.0) at gnu.gcj.runtime.VMClassLoader.findClass(java.lang.String) (/tmp/dara/lib/libgcj.so.4.0.0) at java.lang.ClassLoader.loadClass(java.lang.String, boolean) (/tmp/dara/lib/libgcj.so.4.0.0) at _Jv_FindClass(_Jv_Utf8Const, java.lang.ClassLoader) (/tmp/dara/lib/libgcj.so.4.0.0) at java.lang.Class.forName(java.lang.String, boolean, java.lang.ClassLoader) (/tmp/dara/lib/libgcj.so.4.0.0) at java.lang.Class.forName(java.lang.String) (/tmp/dara/lib/libgcj.so.4.0.0) at gnu.testlet.SimpleTestHarness.runtest(java.lang.String) (/tmp/mauve/gnu/testlet/SimpleTestHarness.java:215) at gnu.testlet.SimpleTestHarness.main(java.lang.String[]) (/tmp/mauve/gnu/testlet/SimpleTestHarness.java:371) 1 of 1 tests failed Hopefully this is as straightforward the last issue... Thanks, Dara __________________________________ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com From mark@klomp.org Mon Jun 9 07:52:00 2003 From: mark@klomp.org (Mark Wielaard) Date: Mon, 09 Jun 2003 07:52:00 -0000 Subject: Build Error In-Reply-To: <20030609015645.98958.qmail@web41107.mail.yahoo.com> References: <20030609015645.98958.qmail@web41107.mail.yahoo.com> Message-ID: <1055145123.810.1185.camel@elsschot> Hi, On Mon, 2003-06-09 at 03:56, Dara Hazeghi wrote: > Now though, I can't just do: > echo gnu.testlet.java.lang.Character.unicode | > ./SimpleTestHarness > > from the directory I did make check in. I get: > > FAIL: uncaught exception loading > gnu.testlet.java.lang.Character.unicode: > java.lang.ClassNotFoundException: You have probably used the mauve-libgcj from the gcc/libjava directory. If you have then this is clear since that file contains the following: # Character.unicode seems to be very broken (the test) # Does not give meaningfull test results at the moment. !java.lang.Character.unicode Which disables compiling of that class. If you really want to run this (buggy) test then remove that line from the mauve-libgcj file. You will then also have to $ rm choices .save-keys before redoing $ make check KEYS=libgcj Cheers, Mark From crawley@dstc.edu.au Wed Jun 11 14:19:00 2003 From: crawley@dstc.edu.au (Stephen Crawley) Date: Wed, 11 Jun 2003 14:19:00 -0000 Subject: Problem with CollationElementIterator.jdk11 testcases Message-ID: <200306111419.h5BEJ3FK014132@piglet.dstc.edu.au> Hi Brian, I've been trying to work out why Classpath (over Kissme) is failing 16 test in gnu.testlet.java.text.CollationElementIterator.jdk11. For example: FAIL: gnu.testlet.java.text.CollationElementIterator.jdk11: next() 0 (number 1) FAIL: gnu.testlet.java.text.CollationElementIterator.jdk11: primaryOrder() 0 (number 1) Examining the testcase code, and comparing the test results with those for various Sun JDK's, it seems that the Classpath implementation is returning different collation key values. The testcase is expecting the JDK value and is barffing. But I don't think that this is correct. Nothing I could see in the Sun javadocs that specifies what the precise key values should have. Rather, the specification says that the key values simply have to have specific ordering characteristics. What do you think? -- Steve From cbj@gnu.org Wed Jun 11 22:37:00 2003 From: cbj@gnu.org (Brian Jones) Date: Wed, 11 Jun 2003 22:37:00 -0000 Subject: Problem with CollationElementIterator.jdk11 testcases In-Reply-To: <200306111419.h5BEJ3FK014132@piglet.dstc.edu.au> References: <200306111419.h5BEJ3FK014132@piglet.dstc.edu.au> Message-ID: Can't remember exactly why I got involved, but the test I think was broken before I made a change so I decided since I didn't understand how the values were supposed to be generated precisely to make the test expect what the JDK actually does. If you understand what is broken here, and likely things in both the test and Classpath, then I'd like to get it fixed. Brian Stephen Crawley writes: > Hi Brian, > > I've been trying to work out why Classpath (over Kissme) is failing > 16 test in gnu.testlet.java.text.CollationElementIterator.jdk11. > For example: > > FAIL: gnu.testlet.java.text.CollationElementIterator.jdk11: > next() 0 (number 1) > FAIL: gnu.testlet.java.text.CollationElementIterator.jdk11: > primaryOrder() 0 (number 1) > > Examining the testcase code, and comparing the test results with those > for various Sun JDK's, it seems that the Classpath implementation is > returning different collation key values. The testcase is expecting > the JDK value and is barffing. > > But I don't think that this is correct. Nothing I could see in the Sun > javadocs that specifies what the precise key values should have. > Rather, the specification says that the key values simply have to have > specific ordering characteristics. > > What do you think? > > -- Steve > > -- Brian Jones From crawley@dstc.edu.au Wed Jun 11 23:42:00 2003 From: crawley@dstc.edu.au (Stephen Crawley) Date: Wed, 11 Jun 2003 23:42:00 -0000 Subject: Problem with CollationElementIterator.jdk11 testcases In-Reply-To: Message from Brian Jones of "11 Jun 2003 18:37:04 -0400." Message-ID: <200306112342.h5BNgNFK005066@piglet.dstc.edu.au> Brian wrote: > If you understand what is broken here, and likely things in both the > test and Classpath, then I'd like to get it fixed. I'll get onto it right away ... -- Steve From gal@uci.edu Sun Jun 15 00:29:00 2003 From: gal@uci.edu (Andreas Gal) Date: Sun, 15 Jun 2003 00:29:00 -0000 Subject: bytecode verifier test suite Message-ID: Hi, I am looking for a JVM bytecode verifier test suite. Is there any progress on this topic? Andreas -- Dipl. Inf. Andreas Gal Tel: none Dept. of Information & Computer Science Fax: (949)-824-4056 University of California, Irvine Office: CS/E 138 Irvine, CA 92697-3430 Email: gal@uci.edu From mark@klomp.org Sun Jun 15 10:42:00 2003 From: mark@klomp.org (Mark Wielaard) Date: Sun, 15 Jun 2003 10:42:00 -0000 Subject: bytecode verifier test suite In-Reply-To: References: Message-ID: <1055673757.16793.6.camel@elsschot> Hi, On Sun, 2003-06-15 at 02:29, Andreas Gal wrote: > I am looking for a JVM bytecode verifier test suite. Is there any progress > on this topic? Yes Tom Tromey and Jeroen Frijters created a whole bunch of tests using jasmin. You can checkout the verify module to see what there currently is. cvs -d:pserver:anoncvs@sources.redhat.com:/cvs/mauve login [password: anoncvs] cvs -d:pserver:anoncvs@sources.redhat.com:/cvs/mauve checkout verify Cheers, Mark From tromey@redhat.com Mon Jun 16 03:47:00 2003 From: tromey@redhat.com (Tom Tromey) Date: Mon, 16 Jun 2003 03:47:00 -0000 Subject: bytecode verifier test suite In-Reply-To: <1055673757.16793.6.camel@elsschot> References: <1055673757.16793.6.camel@elsschot> Message-ID: <877k7mr8ry.fsf@fleche.redhat.com> >>>>> "Mark" == Mark Wielaard writes: Mark> Yes Tom Tromey and Jeroen Frijters created a whole bunch of Mark> tests using jasmin. You can checkout the verify module to see Mark> what there currently is. There's not really that many -- certainly not enough to be confident that your verifier works correctly. For instance, the known bugs in the libgcj verifier are not caught by this test suite. But I'm definitely interested in adding more. Just write some in the existing style... Tom From dhazeghi@yahoo.com Fri Jun 20 06:34:00 2003 From: dhazeghi@yahoo.com (Dara Hazeghi) Date: Fri, 20 Jun 2003 06:34:00 -0000 Subject: Build Error In-Reply-To: <1055145123.810.1185.camel@elsschot> Message-ID: <20030620063456.6435.qmail@web41111.mail.yahoo.com> Hello, sorry I've been a bit busy, but I'm still trying to get mauve up and running. Here's what I did: cvs -z3 co mauve cd mauve; autoreconf; cd .. mkdir mauveobj; cd mauveobj GCJ=gcj ../mauve/configure --with-gcj make check KEYS=libgcj at which point things don't work. The first thing that happens in make check is: Makefile:458: choices: No such file or directory then SimpleTestHarness gets compiled. Then I get: cat classes | ./SimpleTestHarness make[1]: *** [check-local] Error 139 classes is an empty file. However, running SimpleTestHarness with any options yields a segfault. My question is, is this a mauve problem or a gcj problem? Thanks for your help! Dara P.S. I'm using gcc mainline __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com From yan.georget@koalog.com Wed Jun 25 18:32:00 2003 From: yan.georget@koalog.com (Yan Georget) Date: Wed, 25 Jun 2003 18:32:00 -0000 Subject: Mauve Code Coverage Message-ID: <200306251949.22868.yan.georget@koalog.com> Hello, I've recently discovered the Mauve project. I was myself thinking about writing tests for Java libraries, but since you started before... Anyway, my email concerns code coverage. Do you compute the code coverage of your test suites? At Koalog, we have developped a powerful code coverage computation tool (http://www.koalog.com/php/kover.php). You can download an evaluation version. If you like it, and since you are an open-source project, we could grant you the right to use it with no restrictions. Let me know what you think. Best regards, Yan Georget From crawley@dstc.edu.au Thu Jun 26 01:04:00 2003 From: crawley@dstc.edu.au (Stephen Crawley) Date: Thu, 26 Jun 2003 01:04:00 -0000 Subject: Mauve Code Coverage In-Reply-To: Message from Yan Georget of "Wed, 25 Jun 2003 19:49:22 +0200." <200306251949.22868.yan.georget@koalog.com> Message-ID: <200306260028.h5Q0SUSa026353@piglet.dstc.edu.au> > Anyway, my email concerns code coverage. Do you compute the code coverage of > your test suites? AFAIK, no we don't. > At Koalog, we have developped a powerful code coverage computation tool > (http://www.koalog.com/php/kover.php). > You can download an evaluation version. > If you like it, and since you are an open-source project, we could grant you > the right to use it with no restrictions. > > Let me know what you think. I think this is a good idea in principle. But a better idea would be for you to run the coverage tool on Mauve/Classpath/some VM and post the results. If you could set something up to do this automatically, that would be even better! Another point is that coverage testing will only really help if people volunteer to write good test cases to fill in the gaps. Finally, coverage testing won't tell us about test cases that are incorrect; e.g. ones that test for implementation specific behavior, or ones that don't work against various Sun JDK's. In other words, Mauve's limitations are not just restricted to coverage. -- Steve From yan.georget@koalog.com Thu Jun 26 08:53:00 2003 From: yan.georget@koalog.com (Yan Georget) Date: Thu, 26 Jun 2003 08:53:00 -0000 Subject: Mauve Code Coverage In-Reply-To: <200306260028.h5Q0SUSa026353@piglet.dstc.edu.au> References: <200306260028.h5Q0SUSa026353@piglet.dstc.edu.au> Message-ID: <200306261049.31453.yan.georget@koalog.com> > I think this is a good idea in principle. But a better idea would be > for you to run the coverage tool on Mauve/Classpath/some VM and post the > results. If you could set something up to do this automatically, that > would be even better! Not sure, it is much more rewarding for developpers (here, test writers) to run the code coverage themselves than letting a quality engineer (here, Koalog) do it for them. > Another point is that coverage testing will only really help if people > volunteer to write good test cases to fill in the gaps. That's the point. See above. > Finally, coverage testing won't tell us about test cases that are > incorrect; e.g. ones that test for implementation specific behavior, or > ones that don't work against various Sun JDK's. In other words, Mauve's > limitations are not just restricted to coverage. In a usual projet, you check that all the test pass under several environments (OS and JDK). In your case, you would also check that the coverage results are the same under these environments. Computing the code coverage is indeed a simple but powerful way to test the tests, which is exactly what you want to do here. What do you think? Yan From cbj@gnu.org Thu Jun 26 11:20:00 2003 From: cbj@gnu.org (Brian Jones) Date: Thu, 26 Jun 2003 11:20:00 -0000 Subject: Mauve Code Coverage In-Reply-To: <200306261049.31453.yan.georget@koalog.com> References: <200306260028.h5Q0SUSa026353@piglet.dstc.edu.au> <200306261049.31453.yan.georget@koalog.com> Message-ID: Yan Georget writes: > What do you think? > Yan > I think it's a cool idea. Most of our tests are written in a black box fashion in that we expect them to pass on any correct implementation of Java. It could still be enlightening to use the code coverage tool however. Brian -- Brian Jones From mark@klomp.org Thu Jun 26 14:43:00 2003 From: mark@klomp.org (Mark Wielaard) Date: Thu, 26 Jun 2003 14:43:00 -0000 Subject: Mauve Code Coverage In-Reply-To: <200306251949.22868.yan.georget@koalog.com> References: <200306251949.22868.yan.georget@koalog.com> Message-ID: <1056638601.764.72.camel@elsschot> Hi, On Wed, 2003-06-25 at 19:49, Yan Georget wrote: > I've recently discovered the Mauve project. > I was myself thinking about writing tests for Java libraries, but since you > started before... Please join the fun! As you can see there are lots of standard classes without mauve tests. > Anyway, my email concerns code coverage. Do you compute the code coverage of > your test suites? No currently not. > At Koalog, we have developped a powerful code coverage computation tool > (http://www.koalog.com/php/kover.php). > You can download an evaluation version. > If you like it, and since you are an open-source project, we could grant you > the right to use it with no restrictions. It looks interesting but does "right to use it with no restrictions" mean that you would distribute a version under a free software license? Does it run on one of the free VMs? Thanks, Mark From crawley@dstc.edu.au Thu Jun 26 15:14:00 2003 From: crawley@dstc.edu.au (Stephen Crawley) Date: Thu, 26 Jun 2003 15:14:00 -0000 Subject: Mauve Code Coverage In-Reply-To: Message from Yan Georget of "Thu, 26 Jun 2003 10:49:31 +0200." <200306261049.31453.yan.georget@koalog.com> Message-ID: <200306261513.h5QFDtSa013095@piglet.dstc.edu.au> Yan, I'm being the "Devil's Advocate" here ... bear with me. Basically, I think the idea is a good one, if we can pull it off. > > I think this is a good idea in principle. But a better idea would be > > for you to run the coverage tool on Mauve/Classpath/some VM and post the > > results. If you could set something up to do this automatically, that > > would be even better! > > Not sure, it is much more rewarding for developpers (here, test writers) to > run the code coverage themselves than letting a quality engineer (here, > Koalog) do it for them. I take your point that it >>could<< be more convenient for testcase developers to run the coverage tests themselves. But that assumes that the "barrier to entry" for using the tool isn't too high. 1) I assume that Koalog will want to limit the their offer of free licenses to "testcase developers". Have you considered how many you will provide, and your criteria for deciding who to give them to? Will there be much paperwork? 2) How easy will it be to use the coverage tool? In particular, is it much work to install the tool? Is it much work to set up the coverage tool for a particular project? [Could the setup files be CVS'd?] 3) Does the tool cope with calls (and callbacks) from Java and native code? A lot of this happens in a typical Classpath-based VM. > > Another point is that coverage testing will only really help if people > > volunteer to write good test cases to fill in the gaps. > > That's the point. See above. I think you missed >>my<< point. That is that we are desperately short of people writing testcases at the moment. Take a look at the rate of Mauve checkins as per the Changelog. A coverage tool won't change this. (This doesn't mean we shouldn't use a coverage tool ... but lets not get our expectations too high!) > > Finally, coverage testing won't tell us about test cases that are > > incorrect; e.g. ones that test for implementation specific behavior, or > > ones that don't work against various Sun JDK's. In other words, Mauve's > > limitations are not just restricted to coverage. > > In a usual projet, you check that all the test pass under several environments > (OS and JDK). In your case, you would also check that the coverage results > are the same under these environments. > Computing the code coverage is indeed a simple but powerful way to test the > tests, which is exactly what you want to do here. Am I missing something here? Can a Classpath cleanroom developer really do a coverage analysis of running Mauve testcases against a Sun JDK? Doesn't the developer need to use Sun source code to do this? -- Steve From yan.georget@koalog.com Thu Jun 26 16:13:00 2003 From: yan.georget@koalog.com (Yan Georget) Date: Thu, 26 Jun 2003 16:13:00 -0000 Subject: Mauve Code Coverage In-Reply-To: <1056642476.3658.109.camel@elsschot> References: <200306251949.22868.yan.georget@koalog.com> <200306261718.08841.yan.georget@koalog.com> <1056642476.3658.109.camel@elsschot> Message-ID: <200306261809.17551.yan.georget@koalog.com> > Koalog seems to integrate all kinds of free software like Ant, SkinLF, > JUnit and Log4J so I hoped you would distribute it under a Free Software > license. Actually, we just integrate with Log4J. KCC easily integrates with Ant, but Ant is not redistributed with KCC and you can use KCC without Ant. Same with SkinLF. BTW we gave a KCC license to the developper of SkinLF. We just use JUnit internally for our tests. Since we use free software, our policy has always been to give licenses to the people of the free software community who were interested in our products. In the same spirit, we gave several licenses of our constraint solver to universities and students. > I was not refering to the price, but meant Free Software as > defined by the Free Software Foundation: > http://www.gnu.org/philosophy/free-sw.html. Well, we are a small software company ... we can't let people modify and distribute our applications. If we become bigger, we could sell support only... > Since I am working on free software like gcj and GNU Classpath to > provide users a way to migrate away from proprietary software whenever > possible I am not comfortable with using non-free products if I can > avoid it. I fully understand. > The GNU Compiler Collection comes with gcj (GNU Compiler for Java) to > create native binaries from java source code and gij (GNU Interpreter > for Java) to interpret java byte code from class or jar files. > > > And there is Kaffe a traditional JVM which includes a Just In Time > compiler Yes, i know these two. Maybe, i'll try one of them. Which one do you recommend? Yan From yan.georget@koalog.com Thu Jun 26 17:36:00 2003 From: yan.georget@koalog.com (Yan Georget) Date: Thu, 26 Jun 2003 17:36:00 -0000 Subject: Mauve Code Coverage In-Reply-To: <200306261513.h5QFDtSa013095@piglet.dstc.edu.au> References: <200306261513.h5QFDtSa013095@piglet.dstc.edu.au> Message-ID: <200306261931.51310.yan.georget@koalog.com> Stephen, > I take your point that it >>could<< be more convenient for testcase > developers to run the coverage tests themselves. But that assumes that > the "barrier to entry" for using the tool isn't too high. > > 1) I assume that Koalog will want to limit the their offer of free > licenses to "testcase developers". Yes. > Have you considered how many you will > provide, As many as developers. > and your criteria for deciding who to give them to? No criteria. > Will there be > much paperwork? No. > 2) How easy will it be to use the coverage tool? In particular, is it > much work to install the tool? Is it much work to set up the coverage > tool for a particular project? [Could the setup files be CVS'd?] Install is very simple, it takes a couple of seconds. It is also very easy to set up the tool for a given project. For more information about these points, look at the user guide. > > 3) Does the tool cope with calls (and callbacks) from Java and native > code? A lot of this happens in a typical Classpath-based VM. No. To be more precise, KCC will only compute the code coverage for the Java byte code. > Am I missing something here? Can a Classpath cleanroom developer really do > a coverage analysis of running Mauve testcases against a Sun JDK? Doesn't > the developer need to use Sun source code to do this? You can use any JDK as long as it is JPDA compliant (Sun and IBM JDKs are). You don't need any source (since KCC does not instrument the code), you just need the jar files. You will need the source to see the result line per line (in KCC GUI only). Does it make sense? Yan From tromey@redhat.com Thu Jun 26 21:11:00 2003 From: tromey@redhat.com (Tom Tromey) Date: Thu, 26 Jun 2003 21:11:00 -0000 Subject: Mauve Code Coverage In-Reply-To: <200306261931.51310.yan.georget@koalog.com> References: <200306261513.h5QFDtSa013095@piglet.dstc.edu.au> <200306261931.51310.yan.georget@koalog.com> Message-ID: <16123.22062.121256.232966@creche.redhat.com> >>>>> "Yan" == Yan Georget writes: Yan> You can use any JDK as long as it is JPDA compliant (Sun and IBM Yan> JDKs are). Is there any free VM that is JPDA compliant? I don't know of one :-( If there is one, I'd love to see coverage results for Classpath libraries when run against Mauve. That would be really useful. Assuming anybody would use the results to drive Mauve development, not necessarily a good assumption. Tom From robilad@yahoo.com Thu Jun 26 23:07:00 2003 From: robilad@yahoo.com (Dalibor Topic) Date: Thu, 26 Jun 2003 23:07:00 -0000 Subject: Mauve Code Coverage In-Reply-To: <200306261809.17551.yan.georget@koalog.com> Message-ID: <20030626230749.75792.qmail@web10005.mail.yahoo.com> Salut Yan, --- Yan Georget wrote: > > The GNU Compiler Collection comes with gcj (GNU Compiler for Java) to > > create native binaries from java source code and gij (GNU Interpreter > > for Java) to interpret java byte code from class or jar files. > > > > > > And there is Kaffe a traditional JVM which includes a Just In Time > > compiler > > Yes, i know these two. Maybe, i'll try one of them. Which one do you > recommend? Since we don't have a JPDA implementation yet in kaffe, I doubt that the code coverage tool would run on kaffe. I'm not aware of anyone working on JPDa for kaffe yet, but there is a debugger for kaffe (bdbj) that maybe could be used as a starting point for implementing JPDA. cheers, dalibor topic __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com From crawley@dstc.edu.au Thu Jun 26 23:42:00 2003 From: crawley@dstc.edu.au (Stephen Crawley) Date: Thu, 26 Jun 2003 23:42:00 -0000 Subject: Mauve Code Coverage In-Reply-To: Message from Tom Tromey of "Thu, 26 Jun 2003 14:23:10 CST." <16123.22062.121256.232966@creche.redhat.com> Message-ID: <200306262341.h5QNfeSa004841@piglet.dstc.edu.au> Yan> You can use any JDK as long as it is JPDA compliant (Sun and IBM Yan> JDKs are). Tom> Is there any free VM that is JPDA compliant? I don't know of one :-( For the record, Kissme is not JPDA compliant.