From aph@pasanda.cygnus.co.uk Thu Apr 1 04:02:00 1999 From: aph@pasanda.cygnus.co.uk (Andrew Haley) Date: Thu, 01 Apr 1999 04:02:00 -0000 Subject: New files checked in. References: <199903141705.JAA25942@hoser.cygnus.com> Message-ID: <19990401120235.23220.qmail@pasanda.cygnus.co.uk> > Date: Sun, 14 Mar 1999 09:05:45 -0800 > From: Anthony Green > > I've checked in a few of the new tests from HP. Andrew Haley did the > initial conversion to make them work in our framework. > > If you run them, you'll see that the test count isn't significantly > higher than before. It has to do with how the tests are counted. > Their code tries all kinds of things and only register failures when > they happen, whereas we like to keep track of `passes' as well. My > hope is that that these files will slowly migrate over to using the > harness.check methods rather than just harness.fail. If anyone feels > inspired, that would be very helpful. I've converted every instance of if (testcase) harness.fail ("Error"); to harness.check (!(testcase), "Error"); I did this automatically and have not attempted to rationalize any of the tests. This means that you'll see a lot of things like harness.check(!( !nan.isNaN()) but at least you'll now get a more accurate count of test passes. This doesn't work in every case, because there are many instances of things like try { testcase; } catch ( Exception e ) { harness.fail("Error"); } and if (testcase) { System.out.print (diagnostic); harness.fail("Error"); } which do not easily fit into the harness.check() way of doing things. Andrew. From peter@transvirtual.com Fri Apr 16 11:25:00 1999 From: peter@transvirtual.com (Peter Mehlitz) Date: Fri, 16 Apr 1999 11:25:00 -0000 Subject: AWT testing issues Message-ID: <37178075.63B58C0F@transvirtual.com> Hi all, Being in charge of the Kaffe AWT implementations, I'm thinking about to turn over our huge set of quick&dirty AWT testlets into something useful for mauve. Have there already been plans for how to tackle AWT testing issues? How do we want to cope with this notorious "side-effect" lib? We certainly can do something with respect to event flow tests, but there remain a lot of unsolved issues (e.g. how to test disabled Components without manual input). Is somebody already working on this? -- Peter -- Peter Mehlitz Tel: +1 510 704 1527 Transvirtual Technologies, Inc., Fax: +1 510 704 1893 http://www.transvirtual.com Email: peter@transvirtual.com From arenn@urbanophile.com Fri Apr 16 11:38:00 1999 From: arenn@urbanophile.com (Aaron M. Renn) Date: Fri, 16 Apr 1999 11:38:00 -0000 Subject: AWT testing issues Message-ID: <019001be8837$e8c31370$8638d6d8@6748bsc3p255.focal.com> >Have there already been plans for how to tackle AWT testing issues? How do we >want to cope with this notorious "side-effect" lib? We certainly can do >something with respect to event flow tests, but there remain a lot of unsolved >issues (e.g. how to test disabled Components without manual input). Is >somebody already working on this? I don't believe that anyone has done any work on AWT related tests yet. Certainly this presents more challenges than some of the other packages. Sorry I cannot be more helpful but I have not done much work with the AWT myself. -- Aaron M. Renn (arenn@urbanophile.com) http://www.urbanophile.com/arenn/ From warrenl@cygnus.com Thu Apr 29 15:24:00 1999 From: warrenl@cygnus.com (Warren Levy) Date: Thu, 29 Apr 1999 15:24:00 -0000 Subject: HP java.net tests committed to Mauve Message-ID: Folks, I just checked in Mauve tests for the java.net package that are based on the contributed HP tests for that package. I've done a pretty brute force conversion and tried as much as possible to convert things to use the TestHarness.check method. The tests as received from HP made extensive reference to internal machines at HP for connections. I have substituted these with the publicly accessible 'sourceware.cygnus.com' host. I have also created a (hopefully ;-) static web page for use by the tests at: < http://sourceware.cygnus.com/mauve/testarea/index.html > If/when more tests are developed, we can add/modify files on sourceware in the testarea dir for this purpose. That way we have greater reliability in keeping the test and the data in sync than if we relied on some arbitrary URL. I have *not* verified all the output/results produced by the tests. Given the conversion, I am sure that there are some false failures (as well as some meaningless passes). Also, I'm sure the tests can also be enhanced significantly to give us greater coverage. I encourage those interested in the java.net package to try out these tests and correct/extend them as appropriate. Take care! Warren Levy From green@cygnus.com Thu Apr 29 22:25:00 1999 From: green@cygnus.com (Anthony Green) Date: Thu, 29 Apr 1999 22:25:00 -0000 Subject: HP java.net tests committed to Mauve References: Message-ID: <199904300525.WAA18350@hoser.cygnus.com> Warren wrote: > Given the conversion, I am sure that there are some false failures > (as well as some meaningless passes). I was just trying some of these out. Some of the tests have to come out. For instance, there's a test for ServerSocket.toString(). I'm looking at the Java Class Libraries book right now, and it has very little to say about the specifics of this operation. The test checks for: ServerSocket[addr=all-zeros-broadcast/0.0.0.0,port=0,localport=30000] but the 1.1.7 JDK, for instance, does... ServerSocket[addr=0.0.0.0/0.0.0.0,port=0,localport=30000] I'm curious about what the classpath and kaffe folks have done. AG -- Anthony Green Cygnus Solutions Sunnyvale, California From green@cygnus.com Thu Apr 29 22:27:00 1999 From: green@cygnus.com (Anthony Green) Date: Thu, 29 Apr 1999 22:27:00 -0000 Subject: AWT testing issues References: <37178075.63B58C0F@transvirtual.com> <37178075.63B58C0F@transvirtual.com> Message-ID: <199904300527.WAA18354@hoser.cygnus.com> Peter wrote: > Have there already been plans for how to tackle AWT testing issues? Nope. > Is somebody already working on this? Not that I am aware of. Can you describe what you have? AG -- Anthony Green Cygnus Solutions Sunnyvale, California From gatgul@voicenet.com Fri Apr 30 03:18:00 1999 From: gatgul@voicenet.com (Uncle George) Date: Fri, 30 Apr 1999 03:18:00 -0000 Subject: HP java.net tests committed to Mauve References: <199904300525.WAA18350@hoser.cygnus.com> Message-ID: <3729917C.E9D6C72C@voicenet.com> Could there be a -D or a shell environment var to make the net address something different than cygnus.. I am not always on the net, and woyld prefer to test on the loopback-first, eth-next, and ppp/slip-last gat From warrenl@cygnus.com Fri Apr 30 10:56:00 1999 From: warrenl@cygnus.com (Warren Levy) Date: Fri, 30 Apr 1999 10:56:00 -0000 Subject: HP java.net tests committed to Mauve References: <3728FAEB.ABC125FD@voicenet.com> Message-ID: It is quite reasonable to have the tests do a System.getProperty on a particular item and if set, use that in constructing the URL. It would require having a mirror of the testarea in the appropriate place (or the conditional code in the tests could get a bit tricky I suppose and exclude certain tests in the non-Internet case). At this point I don't have the bandwidth to add this functionality; if someone else were into doing it, that'd be great. --warrenl On Thu, 29 Apr 1999, Uncle George wrote: > Could it possibly be rewritten to accept -D or a shell environment variable ? > I dont think i wanna rely on the internet to do ALL net testing, where my > local net would do ( & is faster than the ~26kb connection!) > gat > > Warren Levy wrote: > > > The tests as received from HP made extensive reference to internal > > machines at HP for connections. I have substituted these with the > > publicly accessible 'sourceware.cygnus.com' host. I have also created > > a (hopefully ;-) static web page for use by the tests at: > > > > < http://sourceware.cygnus.com/mauve/testarea/index.html > From peter@transvirtual.com Fri Apr 30 12:29:00 1999 From: peter@transvirtual.com (Peter Mehlitz) Date: Fri, 30 Apr 1999 12:29:00 -0000 Subject: AWT testing issues References: <37178075.63B58C0F@transvirtual.com> <199904300527.WAA18354@hoser.cygnus.com> Message-ID: <372A0484.251E78BD@transvirtual.com> Anthony Green wrote: > Can you describe what you have? Tons of little apps testing isolated things like single widgets (Buttons, TextFields etc.), and some more complex examples (like the Kaffe WidgetsDemo). But the point is that none of them can be used for automated testing. Most of them log something to System.out, but in a way which is platform dependent (e.g. on particular AWTEvent.toString() implementations). I was thinking of to "normalize" this output so that we can test it regardless of the AWT implementation. The other thing is to think about automated input, e.g. by means of a playback of recorded events. But that has limitations, too. For example, a certain AWT might not receive events for disabled components at all, and therefore you couldn't test enable/disable with that scheme. There also might be a dependency on how the Java event queue/dispatch thread is interfaced with the native one (e.g. if it is in a completely asynchronous thread or uses some kind of a blocking native getNextEvent). Then we have the problem of rendering validation, where it gets really hard to automate something. Seems that this is a area that needs a lot more thoughts. But that's not a big surprise, given the kind of specification we have for the AWT. -- Peter From gatgul@voicenet.com Sat May 1 04:07:00 1999 From: gatgul@voicenet.com (Uncle George) Date: Sat, 01 May 1999 04:07:00 -0000 Subject: HP java.net tests committed to Mauve References: Message-ID: <372AEE1B.A679DDE1@voicenet.com> Is not The net/testarea distributed with the tar.gz files ? Are they built on the fly , or are they static. gat Warren Levy wrote: > It > would require having a mirror of the testarea in the appropriate place > (or the conditional code in the tests could get a bit tricky I suppose > and exclude certain tests in the non-Internet case). From warrenl@cygnus.com Sat May 1 23:57:00 1999 From: warrenl@cygnus.com (Warren Levy) Date: Sat, 01 May 1999 23:57:00 -0000 Subject: HP java.net tests committed to Mauve References: <372AEE1B.A679DDE1@voicenet.com> Message-ID: It's actually mauve/testarea (rather than net), meaning it's part of the web pages and I don't believe the web pages are part of the snapshot tar file. Shouldn't be a problem as you can view the source of web pages from most browsers and just save it on your system for future use. --warrenl On Sat, 1 May 1999, Uncle George wrote: > Is not The net/testarea distributed with the tar.gz files ? Are they built on the > fly , or are they static. > > Warren Levy wrote: > > > It > > would require having a mirror of the testarea in the appropriate place > > (or the conditional code in the tests could get a bit tricky I suppose > > and exclude certain tests in the non-Internet case). From govind@mediabreeze.com Mon May 10 12:33:00 1999 From: govind@mediabreeze.com (Govind Shridhare) Date: Mon, 10 May 1999 12:33:00 -0000 Subject: Mauve running on Windows 98 Box? Message-ID: <000001be9b1c$15e26260$7f080ccf@w9x6w1> Hi there I was wondering if I can configure and run Mauve on windows 98 box? Thanks Govind Shridhare Govind@MediaBreeze.com MediaBreeze.com - "Come, Join us in the Evolution!" From tromey@cygnus.com Mon May 10 12:40:00 1999 From: tromey@cygnus.com (Tom Tromey) Date: Mon, 10 May 1999 12:40:00 -0000 Subject: Mauve running on Windows 98 Box? References: <000001be9b1c$15e26260$7f080ccf@w9x6w1> Message-ID: <87g154af1j.fsf@cygnus.com> >>>>> "Govind" == Govind Shridhare writes: Govind> I was wondering if I can configure and run Mauve on windows 98 Govind> box? As far as I know, nobody has tried this. You could probably do it out of the box if you have Cygwin installed. Otherwise you'll probably have to duplicate the `choose' machinery to include only the test classes you can run. The README tries to describe what `choose' does. Let us know what you find out. Tom From gatgul@voicenet.com Thu Apr 1 00:00:00 1999 From: gatgul@voicenet.com (Uncle George) Date: Thu, 01 Apr 1999 00:00:00 -0000 Subject: Java 1.2 References: <36FA44BC.43E205A5@voicenet.com> Message-ID: <36FA4555.DA57955B@voicenet.com> Some of ur tests do not compile unde 1.2. whats the deal with posting patches directed towards 1.2 compatability? gat From jsm@cygnus.com Thu Apr 1 00:00:00 1999 From: jsm@cygnus.com (Jason Molenda) Date: Thu, 01 Apr 1999 00:00:00 -0000 Subject: One last test Message-ID: <19990118004339.A5374@cygnus.com> Hi folks, sorry for the interruption. I've been cleaning up the list config a bit and I want to verify that I didn't break anything. From tromey@cygnus.com Thu Apr 1 00:00:00 1999 From: tromey@cygnus.com (Tom Tromey) Date: Thu, 01 Apr 1999 00:00:00 -0000 Subject: BitSet test References: <01bd01be5478$380d0a60$68102ad1@6748bsc3p255.focal.com> Message-ID: <87ogn091y8.fsf@cygnus.com> Aaron> It doesn't seem to like my TAGS value. It always pulls JDK1.1 Aaron> no matter what I put in it. What TAGS value do you use? Tom From gatgul@voicenet.com Thu Apr 1 00:00:00 1999 From: gatgul@voicenet.com (Uncle George) Date: Thu, 01 Apr 1999 00:00:00 -0000 Subject: Unicode character \u2102 Message-ID: <36FE632A.41B9FFEB@voicenet.com> the unicode character \u2102 seems to be a cap as defined in ftp://ftp.unicode.org/Public/UNIDATA/UnicodeData-Latest.txt as: 2102;DOUBLE-STRUCK CAPITAL C;Lu;0;L; 0043;;;;N;DOUBLE-STRUCK C;;;; This test fails with my SUN non-com port of java. 1) has this been reported to SUN ( there seems to be some 5000 bug reports related to unicode ) 2) AND AM I IN THE CORRECT UNICODE database ????? ( ie what kinda excuse will I get from java that this is the way it is and we are gonna stick to it! ) gat From gatgul@voicenet.com Thu Apr 1 00:00:00 1999 From: gatgul@voicenet.com (Uncle George) Date: Thu, 01 Apr 1999 00:00:00 -0000 Subject: DecimalFormal.java Message-ID: <36FDB96C.F99D9770@voicenet.com> it seems like the SUN jdk 1.2/117 version of DecimalFormat gives a string result of "0.2" for a format of "#.#". It was expected to be ".2", which appears from reading the documentaion to be correct. I submitted a bug report to sun for their opinion. I have also inquired about the format of the E . it seems that E# is not legit in practice, but appears correct in documentaion. I suppose one never wants to see just an "E" for a format of "E#", but what of "E0#" where the second digit is optional, and should ne=ot be printed. Also positive exponents dont appear to have any "+" signatures. But there is a "-" for neg exponents. gat From arenn@gnu.org Thu Apr 1 00:00:00 1999 From: arenn@gnu.org (Aaron M. Renn) Date: Thu, 01 Apr 1999 00:00:00 -0000 Subject: Reading Writing and Support Classes Message-ID: <199902190423.XAA29516@melange.gnu.org> I tried sending this message to this list yesterday and it seemed to disappear so I'll try again. Apologies if you get a dup. I run into new design questions every time I write a test it seems. 1). The resource framework is great for reading, but what should we do about tests that need to write? It seems to me that some environments might be read only, so we don't want to run these mixed in with everything else. I separated them into separate files. Also, do we want to worry about which directories we are writing to? 2). I noticed Tom split some of my things into support classes to avoid having multiple classes in the same file. When I do this, my support classes don't get built because they don't have a Tags: line that is in scope. What am I doing wrong? As a workaround, I tagged them with the appropriate tag for building them (eg. JDK1.0) and changed SimpleTestHarness to skip over anything that isn't an instance of Testlet (which it probably should be doing anyway). I actually kind of like my solution. -- Aaron M. Renn (arenn@urbanophile.com) http://www.urbanophile.com/arenn/ From arenn@urbanophile.com Thu Apr 1 00:00:00 1999 From: arenn@urbanophile.com (Aaron M. Renn) Date: Thu, 01 Apr 1999 00:00:00 -0000 Subject: Interface Tests Message-ID: <36AD103E.CB6DAB3F@urbanophile.com> I'm starting to write tests for java.sql. As you are probably aware, that package is mostly interfaces, with only a handful of small classes. I wrote a test case for the Connection interface. It basically consists of verifying that the interface constants have the correct value. However, I also had it implement the interface and stubbed out all the methods in order to see if would compile. Does this sort of check seem valueable to anyone, or do you think I'm just wasting my time? I checked the test in if anyone wants to look at it: gnu/testlet/java/sql/Connection/TestJdbc10.java -- Aaron M. Renn (arenn@urbanophile.com) http://www.urbanophile.com/arenn/ From tromey@cygnus.com Thu Apr 1 00:00:00 1999 From: tromey@cygnus.com (Tom Tromey) Date: Thu, 01 Apr 1999 00:00:00 -0000 Subject: DecimalFormal.java References: <36FDB96C.F99D9770@voicenet.com> Message-ID: <87677l4fqm.fsf@cygnus.com> >>>>> ">" == Uncle George writes: >> it seems like the SUN jdk 1.2/117 version of DecimalFormat gives a >> string result of "0.2" for a format of "#.#". It was expected to be >> ".2", which appears from reading the documentaion to be correct. I >> submitted a bug report to sun for their opinion. This sure sounds like a bug in their implementation to me. What does getMinimumIntegerDigits() return for this formatter? I think it should be 0. >> I have also inquired about the format of the E . it seems that E# >> is not legit in practice, but appears correct in documentaion. I >> suppose one never wants to see just an "E" for a format of "E#", >> but what of "E0#" where the second digit is optional, and should >> ne=ot be printed. Also positive exponents dont appear to have any >> "+" signatures. But there is a "-" for neg exponents. My reading of the online JDK 1.2 docs is that the DecimalFormat class as a whole is woefully under-documented. Exponential formats aren't really discussed at all -- only in passing. The serialization spec mentions a `minExponentDigits' field but there are no accessors for this. There aren't even any exponential format examples. In the discussion of currency symbols it mentions the "international currency symbol", a term which, as far as I can tell, goes undefined. Furthermore it says in this case: If present in a pattern, the monetary decimal separator is used instead of the decimal separator. However, the monetary decimal separator is likewise undefined -- and is not mentioned in DecimalFormatSymbols, where one might expect. For my own implementation I just picked things that made sense to me (for exponential formatting) or ignore them (the monetary decimal separator). Of course, this is lame. I'm reluctant to follow Sun's implementation in absence of a written spec though. We already know their implementation has bugs. I don't want to try to be bug-compatible when I don't even know what they think they are trying to write. As a programmer I don't see how I could even use the undocumented (but existent) functionality DecimalFormat class in my own Java applications. How would I know what results to expect? Tom From arenn@urbanophile.com Thu Apr 1 00:00:00 1999 From: arenn@urbanophile.com (Aaron M. Renn) Date: Thu, 01 Apr 1999 00:00:00 -0000 Subject: Fw: Mauve with my own java compiler References: <022501be48b3$1bc258e0$68102ad1@6748bsc3p255.focal.com> Message-ID: <36AD0F51.987E2ED4@urbanophile.com> >I've made a java compiler (100% written in Java, GNU license) and I've >test it against Mauve. Cool! >"gnu.testlet.java.io.LineNumberReader" looks more like a bug of your >test suite than a bug of my compiler. (FAIL: >gnu.testlet.java.io.LineNumberReader.Test: getLineNumber - first series >(number 1)) and since javac and jikes act like me I'm a little bit >confused. I looked at LineNumberReader briefly and didn't see a bug. It does fail for me when run with the JDK, but succeeds on Japhar+Classpath. I'll have to dig a little deeper. >Should a perfect compiler not fail in all of your test (in this case, >please explain why standard compilers fail) or is your test suite bugged? Mauve is a library test suite, not a compiler test suite. Assuming your compiler is able to compile Mauve (which itself is an interesting case because of the massive command line we currently use to compile) at all, it is probably working correctly. We don't do anything fancy that would provide much of a compiler test (to the best of my knowledge). Even correctly compiled, Mauve will generate many errors, particularly in the Character class, which performs a few million tests. This doesn't indicate that the compile was wrong, but rather either a bug in the test suite or the library being tested. >my compiler is freely available at: http://www.dms.at >It works under JDK1.1 and 1.2 and comes with xkjc a compiler for java + >embedded SQL. I'll have to check that out. -- Aaron M. Renn (arenn@urbanophile.com) http://www.urbanophile.com/arenn/ From gatgul@voicenet.com Thu Apr 1 00:00:00 1999 From: gatgul@voicenet.com (Uncle George) Date: Thu, 01 Apr 1999 00:00:00 -0000 Subject: Java 1.2: DescriptorTest.java References: <011f01be770e$b9d1e260$8638d6d8@6748bsc3p255.focal.com> <36FA6017.CEC9A956@voicenet.com> <19990325211300.B13388@urbanophile.com> <87vhfogbje.fsf@cygnus.com> Message-ID: <36FBA692.8EAC74@voicenet.com> It seems like this test fails on 1.2 because of a missing "setClass" . the class "java.lang.Object.class" has a getClass, but appears to be missing a (required by 1.2 spec ) a corresponding "setClass" Depending how how these tests are viewed, SUN's bean.PropertyDescriptor caught this missing method. Maybe others should also? gat Test needs a class that has both "setXxxxx" & "getXxxxx" to pass in 1.2 From tullmann@cs.utah.edu Thu Apr 1 00:00:00 1999 From: tullmann@cs.utah.edu (Patrick Tullmann) Date: Thu, 01 Apr 1999 00:00:00 -0000 Subject: a testing harness for VM tests Message-ID: <19990319121053.A9199@cs.utah.edu> I have a small testing harness I developed for testing my various hacks to Kaffe to support multiple processes (shameless plug: http://www.cs.utah.edu/projects/flux/java/alta/ ). I thought other Mauve folks might be interested in it, and it might be useful when supporting the VM tests in Mauve. Anyway, its written in perl. One perl script generates makefile fragments for each test, and the second perl script runs tests, captures their output, diffs it against expected output and supports timeouts for killing errant tests. I've put the scripts and some sample configuration files together in a tgz available from http://www.cs.utah.edu/~tullmann/mauve-test/ . -Pat ----- ----- ---- --- --- -- - - - - - Pat Tullmann tullmann@cs.utah.edu Your research fills a much needed gap. From toshok@hungry.com Thu Apr 1 00:00:00 1999 From: toshok@hungry.com (Christoph Toshok) Date: Thu, 01 Apr 1999 00:00:00 -0000 Subject: Java 1.2 References: <011f01be770e$b9d1e260$8638d6d8@6748bsc3p255.focal.com> <36FA6017.CEC9A956@voicenet.com> <87u2v8gbhq.fsf@cygnus.com> Message-ID: <36FB18F0.559664BE@hungry.com> Tom Tromey wrote: > >>>>> ">" == Uncle George writes: > > >> BTW, although i have working java/jdk1.2 for linux/i386/DecAlpha - > >> I do not have access to SUN's testing facility. Since I cannot help > >> with the GPL/java ports, i believe I can still assist with > >> Tests/and the writing of them. > > Does anybody know if he would be prevented from contributing tests if > he had seen Sun's source code? That might be a problem, but I really > don't know for sure. I wouldn't think that this would cause a problem. Seeing the Sun source code doesn't prohibit one from writing GPL/LGPL'ed subclasses, for instance. Chris From tromey@cygnus.com Thu Apr 1 00:00:00 1999 From: tromey@cygnus.com (Tom Tromey) Date: Thu, 01 Apr 1999 00:00:00 -0000 Subject: BitSet patch References: <36F51647.BC88D163@pg.gda.pl> Message-ID: <8790cq3epw.fsf@cygnus.com> >>>>> "Artur" == Artur Biesiadowski writes: Artur> A bit better test now - it was possible for and() to just clear Artur> a bitset and pass the test. I checked this in. Artur> BTW it is quite hard to write a good test without 'mutation Artur> testing' - introducing explicit errors in tested code :) Yeah. Sometimes I add new test cases to test for specific bugs I find in my code. I encourage everybody to do this. There's some chance that different programmers will make similar mistakes. Tom From toshok@hungry.com Thu Apr 1 00:00:00 1999 From: toshok@hungry.com (Chris Toshok) Date: Thu, 01 Apr 1999 00:00:00 -0000 Subject: japhar results with mauve References: <36ECC770.8B679B65@hungry.com> <36ED15C3.E9C2612E@pg.gda.pl> Message-ID: <36ED181B.9B7A4894@hungry.com> Artur Biesiadowski wrote: > > Christoph Toshok wrote: > > > > I took mauve for a whirl this evening, and put the results up here: > > > > http://www.japhar.org/mauve.html > > > > The script used to go from -verbose -debug output to the format you see > > there is in japhar's cvs. > > You are writing that java.lang.Character tests are hanging up. Most > probably it is because of unicode test. > Try to remove it and run test again. If they will pass you get the > offender. I've actually tried removing it, and then it just hangs upon completing the other character tests. It's really strange - the only way I can get any java.lang tests to work (and not have the whole package hang at some point) is to put !java.lang in the KEYS and then add the ones I'm interested in back in. > It is just a very long test - under JDK it takes smoething between 10s > and one minute. In japhar it can take even half an hour or more I > suppose. Try to add some debug comments (like processing character x) in > source and run again on its own - if it is speed then we are home. Well, the unicode test does take forever on japhar. What with the total lack of GC, my japhar process grew to over 320M before I finally got tired of waiting and hit control C... :) Chris From clark.evans@manhattanproject.com Thu Apr 1 00:00:00 1999 From: clark.evans@manhattanproject.com (Clark Evans) Date: Thu, 01 Apr 1999 00:00:00 -0000 Subject: http://sourceware.cygnus.com/mauve/ Message-ID: <36EB1931.2FAC5179@manhattanproject.com> The link to Kaffe has an extra slash. :) Clark From tromey@cygnus.com Thu Apr 1 00:00:00 1999 From: tromey@cygnus.com (Tom Tromey) Date: Thu, 01 Apr 1999 00:00:00 -0000 Subject: Java 1.2 References: <011f01be770e$b9d1e260$8638d6d8@6748bsc3p255.focal.com> <36FA6017.CEC9A956@voicenet.com> Message-ID: <87u2v8gbhq.fsf@cygnus.com> >>>>> ">" == Uncle George writes: >> BTW, although i have working java/jdk1.2 for linux/i386/DecAlpha - >> I do not have access to SUN's testing facility. Since I cannot help >> with the GPL/java ports, i believe I can still assist with >> Tests/and the writing of them. Does anybody know if he would be prevented from contributing tests if he had seen Sun's source code? That might be a problem, but I really don't know for sure. Tom From tromey@cygnus.com Thu Apr 1 00:00:00 1999 From: tromey@cygnus.com (Tom Tromey) Date: Thu, 01 Apr 1999 00:00:00 -0000 Subject: Unicode character \u2102 References: <36FE632A.41B9FFEB@voicenet.com> <36FEF334.EDFBD704@voicenet.com> Message-ID: <87pv5srw8z.fsf@cygnus.com> >>>>> ">" == Uncle George writes: >> From the JAVA documentaion, the unicode char 2102, is just not a >> capital letter ( 1'st test - must NOT be between \u2000 - \u2fff ). >> ergo can never be a java uppercase letter! >> Is there something going on with the presumption of the >> CharacterTest ? I don't recall -- does CharacterTest say that \u2102 is upper case or not? If you read the online JDK 1.2 docs, you'll notice that isLowercase has two possible definitions. One is `Ll'. The other is a long sequence of conditions. Sun told me that `Ll' is the correct answer. I'm not sure I believe them. So it's still possible that this bug could lie anywhere: in Sun's doc, Sun's implementation, or our test. Anyway, by analogy I'd assume their uppercase documentation is similarly incorrect (or not). Opinions, preferably with supporting documentation, solicited. Tom From tim@transvirtual.com Thu Apr 1 00:00:00 1999 From: tim@transvirtual.com (Tim Wilkinson) Date: Thu, 01 Apr 1999 00:00:00 -0000 Subject: Library/VM tests References: <36DC7DA9.16A46D4F@transvirtual.com> <36DE6CCC.83CF838B@pg.gda.pl> Message-ID: <36DF49FC.DE96ADD8@transvirtual.com> I guess I wasn't thinking of testing the basic operations of the VM - but when it comes down to it they should be tested too don't you think - after all they have to work correctly too right? Perhaps the testsuite should be split into various sub-trees contains test designed to go after particular bits of the Java implementation - you could put array[-1] in the tests designed to check the VM in one area and leave the API tests in another. For such things as serialization I'm not sure what the best structure would be - arguably you can serialize any class (even ones which don't implement Serializable have a behaviour that can be checked) - perhaps you just put a serializable check in each class test directory, or maybe you lump the serialization together (I'd go for the first option). Tim Artur Biesiadowski wrote: > I think that as long as you test API, not VM it is ok. I mean that you > should not test if > array[-1] > throws ArrayIndexOutOfBounds exception, but if Vector.elementAt(-1) > throws such exception (even if it uses the same mechanism). In other > words, you can suppose that VM is perfect - only core lib can be faulty. > > So, my personal opinion is that things that you mentioned fir into > mauve. Example fo thing that will not fit is StackOverflowException or > OutOfMemoryException testing - they are stritlty VM test, as there is > really not much to test in actual classes, and have a side effect of > possibly crashing entire test suite. I think that such tests (together > with bytecode tests etc), should be done separately - out of mauve. > > Artur -- Tim Wilkinson Tel: +1 510 704 1660 Transvirtual Technologies, Inc., Fax: +1 510 704 1893 Berkeley, CA, USA. Email: tim@transvirtual.com From abies@pg.gda.pl Thu Apr 1 00:00:00 1999 From: abies@pg.gda.pl (Artur Biesiadowski) Date: Thu, 01 Apr 1999 00:00:00 -0000 Subject: BitSet test Message-ID: <36B85E1C.6C8D389A@pg.gda.pl> Attached is test for JDK1.0 BitSet. There are some new methods in 1.2, but as it is not avail on linux... BTW, mauve check rules are very counter-intuitive for me. I was supposing that with make KEYS='!java java.util.BitSet' check I'll be able to run only my test. Actual result was to run all tests. I was trying to give these options in mauve-something file, no luck. I've ended up with compiling by hand and running through make check with hand edited 'classes' file Artur // Taqs: JDK1.0 package gnu.testlet.java.util.BitSet; import gnu.testlet.Testlet; import gnu.testlet.TestHarness; import java.util.BitSet; public class jdk10 implements Testlet { TestHarness h; public void test ( TestHarness harness ) { h = harness; BitSet b1, b2, b3, b4, b5; h.checkPoint("Clone/Equals"); b1 = new BitSet(); b2 = (BitSet)b1.clone(); h.check( trulyEquals(b1,b2) ); b1 = new BitSet(100); h.check( trulyEquals(b1,b2) ); b1.set(5); h.check( !trulyEquals(b1,b2) ); b2 = (BitSet)b1.clone(); h.check( trulyEquals(b1,b2)); h.check(!b2.equals(null)); h.checkPoint("NegativeSize"); try { b1 = new BitSet(-1); h.check(false); } catch ( NegativeArraySizeException e ) { h.check(true); } h.checkPoint("Set/Clear/Get"); b1 = new BitSet(); b1.set(1); b1.set(200); b1.set(0); h.check(b1.get(0)); h.check(b1.get(1)); h.check(!b1.get(2)); h.check(b1.get(200)); b1.clear(0); h.check(!b1.get(0)); h.checkPoint("Set/Clear/Get negative index"); try { b1.set(-1); h.check(false); } catch ( IndexOutOfBoundsException e ) { h.check(true); } try { b1.get(-1); h.check(false); } catch ( IndexOutOfBoundsException e ) { h.check(true); } try { b1.clear(-1); h.check(false); } catch ( IndexOutOfBoundsException e ) { h.check(true); } h.checkPoint("toString"); h.check(b1.toString().equals("{1, 200}")); b1.set(2); b1.set(11); h.check(b1.toString().equals("{1, 2, 11, 200}")); b2 = new BitSet(100); h.check(b2.toString().equals("{}")); h.checkPoint("Hascode"); h.check(b1.hashCode() == 2260); h.check(b2.hashCode() == 1234); h.checkPoint("And/Or/Xor"); b3 = new BitSet(); b2.and(b1); h.check( trulyEquals(b2,b3) ); b2.or(b1); h.check( trulyEquals(b2,b1) ); b2.xor(b2); h.check( trulyEquals(b2,b3) ); b2.xor(b1); b3.or(b1); h.check( trulyEquals(b2,b3) ); h.checkPoint("Size"); h.check ( b3.size() > 0 ); h.checkPoint("NullPointerExceptions"); try { b1.and(null); h.check(false); } catch ( NullPointerException e ) { h.check(true); } try { b1.or(null); h.check(false); } catch ( NullPointerException e ) { h.check(true); } try { b1.xor(null); h.check(false); } catch ( NullPointerException e ) { h.check(true); } } private boolean trulyEquals( BitSet b1, BitSet b2 ) { boolean e1 = b1.equals(b2); boolean e2 = true; for ( int i = 0; i < 300; i++ ) { if ( b1.get(i) != b2.get(i) ) e2 = false; } if ( e1 != e2 ) h.check(false, "BitSet.equals is wrong"); else h.check(true); return e2; } } From abies@pg.gda.pl Thu Apr 1 00:00:00 1999 From: abies@pg.gda.pl (Artur Biesiadowski) Date: Thu, 01 Apr 1999 00:00:00 -0000 Subject: Benchmarks Message-ID: <36C2E895.B060177B@pg.gda.pl> I wonder if it would be right to include benchmarks inside mauve. Mauve is designed to help in testing core lib. But in addition to just passing JCK, I think that implementors might be interested how given change will change speed of given class. Of course they can write small test classes (I have done really a lot of them during tya testing). Maybe such things can find their place inside mauve ? I'm thinking about creating additional class type and additional tag (benchmark). Or maybe instead of tag, we can just hardcode that class named benchmark.java in given directory performs benchmarks. Then user could just run something like make 'TAGS=!java java.util.Vector' benchmark and check results. Details of how it should be performed - by time command, measuring milliseconds from java program are secondary problem. Artur From arenn@urbanophile.com Thu Apr 1 00:00:00 1999 From: arenn@urbanophile.com (Aaron M. Renn) Date: Thu, 01 Apr 1999 00:00:00 -0000 Subject: Java 1.2 References: <011f01be770e$b9d1e260$8638d6d8@6748bsc3p255.focal.com> <36FA6017.CEC9A956@voicenet.com> <36FA6017.CEC9A956@voicenet.com> Message-ID: <19990325211300.B13388@urbanophile.com> Uncle George (gatgul@voicenet.com) wrote: > Why it is not - Spec for one function requires a try. > "gnu/testlet/java/io/StringWriter/Test.java" requires a try/catch in > sw.close(); This is probably a bug. > The others appear to be a lack of the complete set of sql impliment's > functionality > . > "gnu/testlet/java/sql/Connection/TestJdbc10.java" > "gnu/testlet/java/sql/DatabaseMetaData/TestJdbc10.java" These classes are specifically designed to test Java 1.1/JDBC 1.0 functionality. Mauve will be able to test implementations at various spec levels. To test Java 1.1, we cannot have any 1.2 functionality. You do bring up an interesting case. I believe one assumption of the test selection script is that Java 1.2 includes all Java 1.0 and Java 1.1 tests. For items such as these which test that interfaces are defined correctly at a particular spec level, this assumption is not valid. > ALSO running the tests present some interesting results. I ran these tests > on my non-comm port > of SUN's java/jdk. Its interesting all the "ERRORS" that are related to > the character sets, as well > as some errors in java.text.DecimalFormat. > > 1) Who deceides what is correct for the character sets ????? I'm not sure what you mean by character sets, but there are still some unresolved errors being reported out of the java.lang.Character test. It reports over 100 errors for the JDK implementation. Part of this is because we use the latest and greatest Unicode spec, while Sun uses an outdated one. Others may be bugs in the test script or the Java implementation. > 2) Who deceides what is correct for DecimalFormat. ( documentation or > Current JDK1.2 implimentation?) I'm not familiar with the test for this class. However, we should base our tests on the documentation unless there is some reason to believe it is wrong. (A typo, for example). Sun's implementation has bugs, and we should not require bug for bug compatibility. A certain level of compatibility is desireable though. In gray areas where the documentation does not specify a result - for example, the various default date formats, or toString() results - it is useful to emulate the JDK's output to match programmer and user expectations. > 3) If there is something inconsistent, do u folks actually inquire ( make > out bug reports ) to sun for their opinion ? ( ie try it on a SUN's port ? > ) I always run my Mauve tests against Sun's implementation. It really isn't a good idea to have the person writing the code write the only test program for it. My test and my code might both reflect my mistaken belief about the correct behavior. A sanity check against the JDK is a good idea. I have not been logging bugs against Sun's implementation because quite honestly I have not found any that haven't already been logged. Plus I doubt that Sun is interested in fixing bugs in JDK 1.1.5, which is what is installed on my machine. > BTW, although i have working java/jdk1.2 for linux/i386/DecAlpha - I do > not have access to SUN's testing facility. Since I cannot help with the > GPL/java ports, i believe I can still assist with Tests/and the writing of > them. That would be excellent. If you write anything, please send it to Anthony Green or Tom Tromey at Cygnus. Patches to existing tests can be posted to the list for now. BTW: Anthony is on vacation right now, so don't expect to hear back from him on any emails for a couple more weeks. -- Aaron M. Renn (arenn@urbanophile.com) http://www.urbanophile.com/arenn/ From green@cygnus.com Thu Apr 1 00:00:00 1999 From: green@cygnus.com (Anthony Green) Date: Thu, 01 Apr 1999 00:00:00 -0000 Subject: Interface Tests References: <36AD103E.CB6DAB3F@urbanophile.com> Message-ID: <199901261341.FAA17031@fencer.cygnus.com.> Aaron wrote: > However, I > also had it implement the interface and stubbed out all the methods in order > to see if would compile. Does this sort of check seem valueable to anyone, > or do you think I'm just wasting my time? I think this is a great idea. We should really improve the build process so it can survive individual build failures and record them as such. AG -- Anthony Green Cygnus Solutions Sunnyvale, California From green@cygnus.com Thu Apr 1 00:00:00 1999 From: green@cygnus.com (Anthony Green) Date: Thu, 01 Apr 1999 00:00:00 -0000 Subject: Reading Writing and Support Classes References: <199902190423.XAA29516@melange.gnu.org> <199902190423.XAA29516@melange.gnu.org> Message-ID: <199902190444.UAA16498@hoser.cygnus.com> Aaron wrote: > I run into new design questions every time I write a test it seems. You're just pushing the envelope! :-) > 1). The resource framework is great for reading, but what should we > do about tests that need to write? It seems to me that some > environments might be read only, so we don't want to run these mixed > in with everything else. I separated them into separate files. > Also, do we want to worry about which directories we are writing to? The resource framework is useful for reading support data (the unicode stuff, for instance). My feeling is that for tests that really require File support, we should tag them with something like HAVE_File. HAVE_File can be set by default in the choose script, and then implementations that don't support File stuff just !HAVE_File. Or something like that. As for directories... it seems like the testlet should ask TestHarness for a directory name. The name can either be passed on the command line, or set during configuration. I kind of think that we should have a SimpleTestHarness.java.in, and then set the srcdir and temp dir at configure time. What do you think? > 2). I noticed Tom split some of my things into support classes to avoid > having multiple classes in the same file. When I do this, my support > classes don't get built because they don't have a Tags: line that is in > scope. What am I doing wrong? As a workaround, I tagged them with the > appropriate tag for building them (eg. JDK1.0) and changed SimpleTestHarness > to skip over anything that isn't an instance of Testlet (which it probably > should be doing anyway). I actually kind of like my solution. Support classes are tagged with `not-a-test'. If testlet Toga uses support class Foo - it has a... // Uses: Foo This gives the choose script a little more control over what exactly gets built. For instance, if Toga is excluded from testing then Foo won't get built. AG -- Anthony Green Cygnus Solutions Sunnyvale, California From vgp@dms.at Thu Apr 1 00:00:00 1999 From: vgp@dms.at (Vincent Gay-Para) Date: Thu, 01 Apr 1999 00:00:00 -0000 Subject: Mauve with my own java compiler Message-ID: <36ACEFE4.A52A4CE8@dms.at> Hi, I've made a java compiler (100% written in Java, GNU license) and I've test it against Mauve. After correction of two little bugs in my compiler (in constant folding, thanks a lot) I got this message: 1041 of 3579754 tests failed like jikes or javac (bugs are identical, not only the number...). The first bug i 've tried to correct in "gnu.testlet.java.io.LineNumberReader" looks more like a bug of your test suite than a bug of my compiler. (FAIL: gnu.testlet.java.io.LineNumberReader.Test: getLineNumber - first series (number 1)) and since javac and jikes act like me I'm a little bit confused. Should a perfect compiler not fail in all of your test (in this case, please explain why standard compilers fail) or is your test suite bugged ? In every case, your test suite is very interesting and I've added it to mine. May be I can send you some tests more compiler oriented when I'll understand how Mauve works exactly. Some remarks: - you don't use the CLASSPATH from the user so I was unable to use my compiler directly with JAVAC='java at.dms.kjc.Main' (it's my compiler). And I need to modifie the Makefile by hand. - it is difficult to found a compile error with "jikes *" and then "error in file Test" where all files are named Test ! Thank you very much for your work, Vincent GAY-PARA PS: my compiler is freely available at: http://www.dms.at It works under JDK1.1 and 1.2 and comes with xkjc a compiler for java + embedded SQL. From arenn@urbanophile.com Thu Apr 1 00:00:00 1999 From: arenn@urbanophile.com (Aaron M. Renn) Date: Thu, 01 Apr 1999 00:00:00 -0000 Subject: BitSet test Message-ID: <01bd01be5478$380d0a60$68102ad1@6748bsc3p255.focal.com> >Aaron> I don't think make check works right. I'm just running all my >Aaron> tests by hand. > >I agree that `make check' is more than a little bogus. >It works well enough for me, though, so I haven't been motivated to >change it. What sorts of changes would you like to see? It doesn't seem to like my TAGS value. It always pulls JDK1.1 no matter what I put in it. It also doesn't ever seem to regenerate its class list. And it compiles everything on one big command line. Those are the things I remember offhand. Some of it could be pilot error since I haven't dug into it too deeply. -- Aaron M. Renn (arenn@urbanophile.com) http://www.urbanophile.com/arenn/ From arenn@urbanophile.com Thu Apr 1 00:00:00 1999 From: arenn@urbanophile.com (Aaron M. Renn) Date: Thu, 01 Apr 1999 00:00:00 -0000 Subject: BitSet test Message-ID: <009a01be4f85$1789e3f0$68102ad1@6748bsc3p255.focal.com> >BTW, mauve check rules are very counter-intuitive for me. I was >supposing that with >make KEYS='!java java.util.BitSet' check >I'll be able to run only my test. Actual result was to run all tests. I >was trying to give these options in mauve-something file, no luck. I've >ended up with compiling by hand and running through make check with hand >edited 'classes' file I don't think make check works right. I'm just running all my tests by hand. -- Aaron M. Renn (arenn@urbanophile.com) http://www.urbanophile.com/arenn/ From abies@pg.gda.pl Thu Apr 1 00:00:00 1999 From: abies@pg.gda.pl (Artur Biesiadowski) Date: Thu, 01 Apr 1999 00:00:00 -0000 Subject: japhar results with mauve References: <36ECC770.8B679B65@hungry.com> Message-ID: <36ED15C3.E9C2612E@pg.gda.pl> Christoph Toshok wrote: > > I took mauve for a whirl this evening, and put the results up here: > > http://www.japhar.org/mauve.html > > The script used to go from -verbose -debug output to the format you see > there is in japhar's cvs. You are writing that java.lang.Character tests are hanging up. Most probably it is because of unicode test. Try to remove it and run test again. If they will pass you get the offender. It is just a very long test - under JDK it takes smoething between 10s and one minute. In japhar it can take even half an hour or more I suppose. Try to add some debug comments (like processing character x) in source and run again on its own - if it is speed then we are home. Artur From green@cygnus.com Thu Apr 1 00:00:00 1999 From: green@cygnus.com (Anthony Green) Date: Thu, 01 Apr 1999 00:00:00 -0000 Subject: BitSet test References: <36B85E1C.6C8D389A@pg.gda.pl> <36B85E1C.6C8D389A@pg.gda.pl> Message-ID: <199902031724.JAA27147@hoser.cygnus.com> Artur wrote: > Attached is test for JDK1.0 BitSet. Cool - thanks. > BTW, mauve check rules are very counter-intuitive for me. I was > supposing that with > make KEYS='!java java.util.BitSet' check > I'll be able to run only my test. Actual result was to run all tests. I > was trying to give these options in mauve-something file, no luck. I've > ended up with compiling by hand and running through make check with hand > edited 'classes' file The following works.. make KEYS='!java. java.util.BitSet' check Note the extra '.'. > // Taqs: JDK1.0 This would have to be "Tags" :-) I think we will have to start requiring copyright notices in the test files. Artur, do you mind if I add the following header to your test file before I check it in? /* Copyright (C) 1999 Artur Biesiadowski This file is part of Mauve. Mauve is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2, or (at your option) any later version. Mauve is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with Mauve; see the file COPYING. If not, write to the Free Software Foundation, 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA. */ AG -- Anthony Green Cygnus Solutions Sunnyvale, California From No Thu Apr 1 00:00:00 1999 From: No (No) Date: Thu, 01 Apr 1999 00:00:00 -0000 Subject: No Subject Message-ID: <6801.926543245.0@NO-ID-FOUND.mhonarc.com> Is there something going on with the presumption of the CharacterTest ? gat Uncle George wrote: > the unicode character \u2102 seems to be a cap as defined in > > ftp://ftp.unicode.org/Public/UNIDATA/UnicodeData-Latest.txt > > as: > > 2102;DOUBLE-STRUCK CAPITAL C;Lu;0;L; 0043;;;;N;DOUBLE-STRUCK C;;;; > > This test fails with my SUN non-com port of java. > > 1) has this been reported to SUN ( there seems to be some 5000 bug > reports related to unicode ) > 2) AND AM I IN THE CORRECT UNICODE database ????? > ( ie what kinda excuse will I get from java that this is the way it > is and we are gonna stick to it! ) > gat From gback@cs.utah.edu Thu Apr 1 00:00:00 1999 From: gback@cs.utah.edu (Godmar Back) Date: Thu, 01 Apr 1999 00:00:00 -0000 Subject: VM tests [was Re: Library/VM tests] References: <36E8FBAD.F4FA1CF@pg.gda.pl> Message-ID: <199903121619.JAA12039@lal.cs.utah.edu> For a start, we could just use the kaffe/test/regression/TestScript.in Alexandre Oliva wrote. It allows compile options and the expected output to be hidden in a comment in the .java file, runs a test and (optionally) sorts and diffs the output. It does not support java assembler, JNI or native tests nor does it support timeouts. These are all very useful features. It's using sh at this point, but I wouldn't mind using perl. - Godmar > > This certainly would reuqire very different handling. > I think that it can be done by creating some informative directory > structure and then executing each class in separate VM by command line > (from makefile or perl or some other script). > > A lot of tests should be written directly in assembler - you cannot be > sure how compilers will translate given code. With assembler we can test > verious verify error, some magic combinations of stack/jumps which would > be impossible from java. This requires java assembler - there are some > available on the net, with jasmin coming to mind, but it is a bit large > (450kb packed ?). > > JNI tests would require C compiler and some knowledge about runtime libs > of given vm. Smart configure script should be enough. > > Some way would have to be defined to kill infinite loops. Maybe second > process sleeping for few minutes ? > > Artur > From abies@pg.gda.pl Thu Apr 1 00:00:00 1999 From: abies@pg.gda.pl (Artur Biesiadowski) Date: Thu, 01 Apr 1999 00:00:00 -0000 Subject: Library/VM tests References: <36DC7DA9.16A46D4F@transvirtual.com> Message-ID: <36DE6CCC.83CF838B@pg.gda.pl> Tim Wilkinson wrote: > > I have (finally) been looking into integrating our modest testsuite into > Mauve but have run up against a problem. So far as I understand things > Mauve is designed to test *only* the library functionality. Given this > what are we suppose to do about test which sit on the boundary - > ClassLoaders spring to mind but there's also such things as > Serialization, Reflection and bunch of other borderline stuff. None of > this is VM specific of course but it relies on more heavy VM support > than some tests (some stuff uses threads for example). > > So my question is - what's the policy on this? I think that as long as you test API, not VM it is ok. I mean that you should not test if array[-1] throws ArrayIndexOutOfBounds exception, but if Vector.elementAt(-1) throws such exception (even if it uses the same mechanism). In other words, you can suppose that VM is perfect - only core lib can be faulty. So, my personal opinion is that things that you mentioned fir into mauve. Example fo thing that will not fit is StackOverflowException or OutOfMemoryException testing - they are stritlty VM test, as there is really not much to test in actual classes, and have a side effect of possibly crashing entire test suite. I think that such tests (together with bytecode tests etc), should be done separately - out of mauve. Artur From arenn@urbanophile.com Thu Apr 1 00:00:00 1999 From: arenn@urbanophile.com (Aaron M. Renn) Date: Thu, 01 Apr 1999 00:00:00 -0000 Subject: Java 1.2 Message-ID: <011f01be770e$b9d1e260$8638d6d8@6748bsc3p255.focal.com> >Some of ur tests do not compile unde 1.2. whats the deal with posting >patches directed towards 1.2 >compatability? What in particular is not working and why is it not? -- Aaron M. Renn (arenn@urbanophile.com) http://www.urbanophile.com/arenn/ From tromey@cygnus.com Thu Apr 1 00:00:00 1999 From: tromey@cygnus.com (Tom Tromey) Date: Thu, 01 Apr 1999 00:00:00 -0000 Subject: Library/VM tests References: <36DC7DA9.16A46D4F@transvirtual.com> Message-ID: <87bti94rgj.fsf@cygnus.com> >>>>> "Tim" == Tim Wilkinson writes: Tim> I have (finally) been looking into integrating our modest Tim> testsuite into Mauve but have run up against a problem. So far Tim> as I understand things Mauve is designed to test *only* the Tim> library functionality. Given this what are we suppose to do Tim> about test which sit on the boundary - ClassLoaders spring to Tim> mind but there's also such things as Serialization, Reflection Tim> and bunch of other borderline stuff. None of this is VM specific Tim> of course but it relies on more heavy VM support than some tests Tim> (some stuff uses threads for example). Tim> So my question is - what's the policy on this? Policy is really for us to decide as a group. The original goal was to write a test suite for the class libraries, but I'm beginning to think we'd be better off expanding the scope to include VM/runtime tests as well. After all, why not? This will only benefit everybody. I'm not fully clear on all the issues in terms of implementation. However, I'm pretty clear on what Cygnus' requirements are in terms of functionality. I'd be happy to discuss this with anybody contemplating revising Mauve to include more kinds of tests (that is, if the test framework needs changing. I don't know whether it does). Tom From gback@cs.utah.edu Thu Apr 1 00:00:00 1999 From: gback@cs.utah.edu (Godmar Back) Date: Thu, 01 Apr 1999 00:00:00 -0000 Subject: Library/VM tests References: Message-ID: <199903042113.OAA14828@sal.cs.utah.edu> > > I have some tests that fall into this "other" catagory. > I developed some test test cases for the reflection API > for the Kaffe project but I think they really should but added > to the mauve tests. Is this the kind of thing that is not covered > under "libraries" tests? > My take on this is that all tests that can be put in the existing mauve framework are "library" tests, and all tests that cannot or for which it would be unreasonably cumbersome to do so are "VM" tests. (I admit that's a somewhat coarse and loose definition.) For the latter kind, the VM tests, I think starting up a VM and diffing the output against the expected output is the most straightforward thing to do. - Godmar From green@cygnus.com Thu Apr 1 00:00:00 1999 From: green@cygnus.com (Anthony Green) Date: Thu, 01 Apr 1999 00:00:00 -0000 Subject: Reading Writing and Support Classes References: <199902190423.XAA29516@melange.gnu.org> <199902190444.UAA16498@hoser.cygnus.com> <87oglzrx1n.fsf@cygnus.com> <87oglzrx1n.fsf@cygnus.com> Message-ID: <199903161746.JAA12238@hoser.cygnus.com> Tom wrote: > Anthony> I kind of think that we should have a > Anthony> SimpleTestHarness.java.in, and then set the srcdir and temp > Anthony> dir at configure time. What do you think? > > That would be fine with me. I did this earlier today, although the configuration is done via an interface (gnu/testlet/config.java.in). - No need to pass the source dir to SimpleTestHarness. - TestHarness now has a getTempDirectory() method. - configure has a --with-tmpdir=... option. The tmpdir defaults to /tmp. AG -- Anthony Green Cygnus Solutions Sunnyvale, California From dejong@cs.umn.edu Thu Apr 1 00:00:00 1999 From: dejong@cs.umn.edu (Moses DeJong) Date: Thu, 01 Apr 1999 00:00:00 -0000 Subject: Library/VM tests References: <87bti94rgj.fsf@cygnus.com> Message-ID: On 4 Mar 1999, Tom Tromey wrote: > >>>>> "Tim" == Tim Wilkinson writes: > > Tim> I have (finally) been looking into integrating our modest > Tim> testsuite into Mauve but have run up against a problem. So far > Tim> as I understand things Mauve is designed to test *only* the > Tim> library functionality. Given this what are we suppose to do > Tim> about test which sit on the boundary - ClassLoaders spring to > Tim> mind but there's also such things as Serialization, Reflection > Tim> and bunch of other borderline stuff. None of this is VM specific > Tim> of course but it relies on more heavy VM support than some tests > Tim> (some stuff uses threads for example). > > Tim> So my question is - what's the policy on this? > > Policy is really for us to decide as a group. The original goal was > to write a test suite for the class libraries, but I'm beginning to > think we'd be better off expanding the scope to include VM/runtime > tests as well. After all, why not? This will only benefit everybody. > > I'm not fully clear on all the issues in terms of implementation. > However, I'm pretty clear on what Cygnus' requirements are in terms of > functionality. I'd be happy to discuss this with anybody > contemplating revising Mauve to include more kinds of tests (that is, > if the test framework needs changing. I don't know whether it does). > > Tom > I have some tests that fall into this "other" catagory. I developed some test test cases for the reflection API for the Kaffe project but I think they really should but added to the mauve tests. Is this the kind of thing that is not covered under "libraries" tests? Mo DeJong dejong at cs.umn.edu From tromey@cygnus.com Thu Apr 1 00:00:00 1999 From: tromey@cygnus.com (Tom Tromey) Date: Thu, 01 Apr 1999 00:00:00 -0000 Subject: Java 1.2 References: <011f01be770e$b9d1e260$8638d6d8@6748bsc3p255.focal.com> <36FA6017.CEC9A956@voicenet.com> <19990325211300.B13388@urbanophile.com> Message-ID: <87vhfogbje.fsf@cygnus.com> >>>>> "Aaron" == Aaron M Renn writes: Aaron> You do bring up an interesting case. I believe one assumption Aaron> of the test selection script is that Java 1.2 includes all Java Aaron> 1.0 and Java 1.1 tests. For items such as these which test Aaron> that interfaces are defined correctly at a particular spec Aaron> level, this assumption is not valid. I believe you can write a tags line like: // Tags: JDK1.1 !JDK1.2 and that will do the right thing -- include the test when 1.1 is specified, but not when 1.2 is specified. I don't know anything about java.sql and wouldn't be comfortable making the change myself. Aaron> I'm not sure what you mean by character sets, but there are Aaron> still some unresolved errors being reported out of the Aaron> java.lang.Character test. It reports over 100 errors for the Aaron> JDK implementation. Part of this is because we use the latest Aaron> and greatest Unicode spec, while Sun uses an outdated one. Aaron> Others may be bugs in the test script or the Java Aaron> implementation. Yes, all three probably apply: * Sun's JDK 1.0 and JDK 1.1 use an outdated Unicode spec. I think we should just let these remain errors. * Sun's JDK 1.0 and 1.1 (haven't tried 1.2) have bugs in their Character implementation. * I once wrote Sun and asked about the apparently self-contradictory documentation in the online 1.2 docs for Character.isLower. Their reply is that the `Ll' rule applies and the rest is just expository. This means there is a bug in the current test suite (if you believe their reply, which I occasionally do not). I haven't had the time to look into this yet. The Character tests are really the most problematic. Sun's documentation is lacking, and so I sometimes picked what I thought was the most reasonable and useful behavior. Perhaps we should just aim for 1.2 compatibility (excluding whatever obvious bugs we might find). >> 2) Who deceides what is correct for DecimalFormat. ( documentation >> or Current JDK1.2 implimentation?) Aaron> I'm not familiar with the test for this class. However, we Aaron> should base our tests on the documentation unless there is some Aaron> reason to believe it is wrong. (A typo, for example). Sun's Aaron> implementation has bugs, and we should not require bug for bug Aaron> compatibility. Aaron> A certain level of compatibility is desireable though. I agree. There is a fair amount of gray in the picture, since Sun's documentation isn't all that great (parts are better than others). When writing new java.text tests (java.text has particularly poor documentation), I've been trying to test things which are more or less unambiguous. I might have failed -- this, like everything, is up for discussion, patches, etc. For DecimalFormat, I ran my test cases against our implementation and against JDK 1.1.6 (I think -- or was it 1.1.5?). Feel free to report specific problems! I don't have JDK 1.2 yet. Aaron> That would be excellent. If you write anything, please send it Aaron> to Anthony Green or Tom Tromey at Cygnus. Patches to existing Aaron> tests can be posted to the list for now. Yeah, send them on out. If you write more than a few, we'll see about getting you direct cvs access. Tom From gatgul@voicenet.com Thu Apr 1 00:00:00 1999 From: gatgul@voicenet.com (Uncle George) Date: Thu, 01 Apr 1999 00:00:00 -0000 Subject: subscribe Message-ID: <36F8D212.34377F9A@voicenet.com> From abies@pg.gda.pl Thu Apr 1 00:00:00 1999 From: abies@pg.gda.pl (Artur Biesiadowski) Date: Thu, 01 Apr 1999 00:00:00 -0000 Subject: VM tests [was Re: Library/VM tests] References: <36DC7DA9.16A46D4F@transvirtual.com> <36DE6CCC.83CF838B@pg.gda.pl> <36DF49FC.DE96ADD8@transvirtual.com> <87n21jrwv8.fsf@cygnus.com> Message-ID: <36E8FBAD.F4FA1CF@pg.gda.pl> Tom Tromey wrote: > Is there anybody who is *against* expanding Mauve to include VM tests? > If not, then we should go ahead and talk about requirements and > implementation. This certainly would reuqire very different handling. I think that it can be done by creating some informative directory structure and then executing each class in separate VM by command line (from makefile or perl or some other script). A lot of tests should be written directly in assembler - you cannot be sure how compilers will translate given code. With assembler we can test verious verify error, some magic combinations of stack/jumps which would be impossible from java. This requires java assembler - there are some available on the net, with jasmin coming to mind, but it is a bit large (450kb packed ?). JNI tests would require C compiler and some knowledge about runtime libs of given vm. Smart configure script should be enough. Some way would have to be defined to kill infinite loops. Maybe second process sleeping for few minutes ? Artur From gatgul@voicenet.com Thu Apr 1 00:00:00 1999 From: gatgul@voicenet.com (Uncle George) Date: Thu, 01 Apr 1999 00:00:00 -0000 Subject: Unicode character \u2102 References: <36FE632A.41B9FFEB@voicenet.com> <36FEF334.EDFBD704@voicenet.com> <87pv5srw8z.fsf@cygnus.com> Message-ID: <3700BECD.A75BF59C@voicenet.com> The 1.2 specification for Character.isLowerCase() appears to have 2 specifications. Also one might also read that all the "L1" characters are "considered to be lowercase" 1) is the "L1" in the unicode 2.0 character set. 2) The other soecification that specifically excludes the \u2000 <=> \u2fff range. The Character.isUpperCase() does not have any Unicode character 'category" specification at all. It is not yet, to me, what is/isnot really true/false for any of the Character methods. Searching...... gat Tom Tromey wrote: > >>>>> ">" == Uncle George writes: > > >> From the JAVA documentaion, the unicode char 2102, is just not a > >> capital letter ( 1'st test - must NOT be between \u2000 - \u2fff ). > >> ergo can never be a java uppercase letter! > > >> Is there something going on with the presumption of the > >> CharacterTest ? > > I don't recall -- does CharacterTest say that \u2102 is upper case or > not? > > If you read the online JDK 1.2 docs, you'll notice that isLowercase > has two possible definitions. One is `Ll'. The other is a long > sequence of conditions. > > Sun told me that `Ll' is the correct answer. I'm not sure I believe > them. So it's still possible that this bug could lie anywhere: in > Sun's doc, Sun's implementation, or our test. > > Anyway, by analogy I'd assume their uppercase documentation is > similarly incorrect (or not). > > Opinions, preferably with supporting documentation, solicited. > > Tom From tim@transvirtual.com Thu Apr 1 00:00:00 1999 From: tim@transvirtual.com (Tim Wilkinson) Date: Thu, 01 Apr 1999 00:00:00 -0000 Subject: Library/VM tests Message-ID: <36DC7DA9.16A46D4F@transvirtual.com> I have (finally) been looking into integrating our modest testsuite into Mauve but have run up against a problem. So far as I understand things Mauve is designed to test *only* the library functionality. Given this what are we suppose to do about test which sit on the boundary - ClassLoaders spring to mind but there's also such things as Serialization, Reflection and bunch of other borderline stuff. None of this is VM specific of course but it relies on more heavy VM support than some tests (some stuff uses threads for example). So my question is - what's the policy on this? Cheers Tim -- Tim Wilkinson Tel: +1 510 704 1660 Transvirtual Technologies, Inc., Fax: +1 510 704 1893 Berkeley, CA, USA. Email: tim@transvirtual.com From cbj@nortel.net Thu Apr 1 00:00:00 1999 From: cbj@nortel.net (Brian Jones) Date: Thu, 01 Apr 1999 00:00:00 -0000 Subject: Library/VM tests References: <36DC7DA9.16A46D4F@transvirtual.com> <36DE6CCC.83CF838B@pg.gda.pl> Message-ID: Artur Biesiadowski writes: > Tim Wilkinson wrote: > > > > I have (finally) been looking into integrating our modest testsuite into > > Mauve but have run up against a problem. So far as I understand things > > Mauve is designed to test *only* the library functionality. Given this > > what are we suppose to do about test which sit on the boundary - > > ClassLoaders spring to mind but there's also such things as > > Serialization, Reflection and bunch of other borderline stuff. None of > > this is VM specific of course but it relies on more heavy VM support > > than some tests (some stuff uses threads for example). > > > > So my question is - what's the policy on this? > > So, my personal opinion is that things that you mentioned fir into > mauve. Example fo thing that will not fit is StackOverflowException or > OutOfMemoryException testing - they are stritlty VM test, as there is > really not much to test in actual classes, and have a side effect of > possibly crashing entire test suite. I think that such tests (together > with bytecode tests etc), should be done separately - out of mauve. My personal opinion is that such a testing facility is needed for all the free VMs including Kaffe, Japhar, etc. If you want to look at the Mauve project as containing a couple of modules, one for testing core libraries and the other for testing vms/jit, then I think that would work well. What, if anything, has to be done to the testing framework seems like a separate issue to me as well. Brian -- |-------------------------------| |Brian Jones | |cbj@gnu.org | | http://www.classpath.org/ | From gatgul@voicenet.com Thu Apr 1 00:00:00 1999 From: gatgul@voicenet.com (Uncle George) Date: Thu, 01 Apr 1999 00:00:00 -0000 Subject: Java 1.2 References: <011f01be770e$b9d1e260$8638d6d8@6748bsc3p255.focal.com> Message-ID: <36FA6017.CEC9A956@voicenet.com> Why it is not - Spec for one function requires a try. "gnu/testlet/java/io/StringWriter/Test.java" requires a try/catch in sw.close(); The others appear to be a lack of the complete set of sql impliment's functionality . "gnu/testlet/java/sql/Connection/TestJdbc10.java" "gnu/testlet/java/sql/DatabaseMetaData/TestJdbc10.java" ALSO running the tests present some interesting results. I ran these tests on my non-comm port of SUN's java/jdk. Its interesting all the "ERRORS" that are related to the character sets, as well as some errors in java.text.DecimalFormat. 1) Who deceides what is correct for the character sets ????? 2) Who deceides what is correct for DecimalFormat. ( documentation or Current JDK1.2 implimentation?) 3) If there is something inconsistent, do u folks actually inquire ( make out bug reports ) to sun for their opinion ? ( ie try it on a SUN's port ? ) gat BTW, although i have working java/jdk1.2 for linux/i386/DecAlpha - I do not have access to SUN's testing facility. Since I cannot help with the GPL/java ports, i believe I can still assist with Tests/and the writing of them. Aaron M. Renn wrote: > >Some of ur tests do not compile unde 1.2. whats the deal with posting > >patches directed towards 1.2 > >compatability? > > What in particular is not working and why is it not? > > -- > Aaron M. Renn (arenn@urbanophile.com) http://www.urbanophile.com/arenn/ From toshok@hungry.com Thu Apr 1 00:00:00 1999 From: toshok@hungry.com (Christoph Toshok) Date: Thu, 01 Apr 1999 00:00:00 -0000 Subject: japhar results with mauve Message-ID: <36ECC770.8B679B65@hungry.com> I took mauve for a whirl this evening, and put the results up here: http://www.japhar.org/mauve.html The script used to go from -verbose -debug output to the format you see there is in japhar's cvs. Chris From green@cygnus.com Thu Apr 1 00:00:00 1999 From: green@cygnus.com (Anthony Green) Date: Thu, 01 Apr 1999 00:00:00 -0000 Subject: New files checked in. Message-ID: <199903141705.JAA25942@hoser.cygnus.com> I've checked in a few of the new tests from HP. Andrew Haley did the initial conversion to make them work in our framework. If you run them, you'll see that the test count isn't significantly higher than before. It has to do with how the tests are counted. Their code tries all kinds of things and only register failures when they happen, whereas we like to keep track of `passes' as well. My hope is that that these files will slowly migrate over to using the harness.check methods rather than just harness.fail. If anyone feels inspired, that would be very helpful. There's plenty more to say, but I have to run. More later. AG -- Anthony Green Cygnus Solutions Sunnyvale, California From green@cygnus.com Thu Apr 1 00:00:00 1999 From: green@cygnus.com (Anthony Green) Date: Thu, 01 Apr 1999 00:00:00 -0000 Subject: HP contributions Message-ID: <199903130104.RAA04445@hoser.cygnus.com> Good news.... Hewlett-Packard is graciously making a large contribution to our effort. They have GPL'd an enormous amount of test code for inclusion in Mauve. It converts fairly easily over to our framework and we'll start checking stuff in soon. Actually, we could use help on that front. More soon, I've got to take care of some info on the web site right now. We're about to experience the Slashdot effect. :-) AG -- Anthony Green Cygnus Solutions Sunnyvale, California From tromey@cygnus.com Thu Apr 1 00:00:00 1999 From: tromey@cygnus.com (Tom Tromey) Date: Thu, 01 Apr 1999 00:00:00 -0000 Subject: BitSet test References: <009a01be4f85$1789e3f0$68102ad1@6748bsc3p255.focal.com> Message-ID: <8790e7tg5f.fsf@cygnus.com> Aaron> I don't think make check works right. I'm just running all my Aaron> tests by hand. I agree that `make check' is more than a little bogus. It works well enough for me, though, so I haven't been motivated to change it. What sorts of changes would you like to see? Tom From gatgul@voicenet.com Thu Apr 1 00:00:00 1999 From: gatgul@voicenet.com (Uncle George) Date: Thu, 01 Apr 1999 00:00:00 -0000 Subject: Unicode character \u2102 References: <36FE632A.41B9FFEB@voicenet.com> Message-ID: <36FEF334.EDFBD704@voicenet.com> From abies@pg.gda.pl Thu Apr 1 00:00:00 1999 From: abies@pg.gda.pl (Artur Biesiadowski) Date: Thu, 01 Apr 1999 00:00:00 -0000 Subject: BitSet patch Message-ID: <36F51647.BC88D163@pg.gda.pl> A bit better test now - it was possible for and() to just clear a bitset and pass the test. BTW it is quite hard to write a good test without 'mutation testing' - introducing explicit errors in tested code :) Artur diff -urPwb old/jdk10.java new/jdk10.java --- old/jdk10.java Tue Feb 9 11:58:40 1999 +++ new/jdk10.java Sun Mar 21 16:39:00 1999 @@ -97,19 +97,27 @@ h.check(b1.toString().equals("{1, 2, 11, 200}")); b2 = new BitSet(100); h.check(b2.toString().equals("{}")); + b2.set(1); + h.check(b2.toString().equals("{1}")); h.checkPoint("Hashcode"); h.check(b1.hashCode() == 2260); - h.check(b2.hashCode() == 1234); + b3 = new BitSet(); + h.check(b3.hashCode() == 1234); h.checkPoint("And/Or/Xor"); - b3 = new BitSet(); + b2.set(1); + b2.set(3); + b2.set(200); + b2.set(300); b2.and(b1); - h.check( trulyEquals(b2,b3) ); + h.check( b2.toString().equals("{1, 200}") ); + b1.set(17); + b2.set(15); b2.or(b1); - h.check( trulyEquals(b2,b1) ); + h.check( b2.toString().equals("{1, 2, 11, 15, 17, 200}") ); b2.xor(b2); - h.check( trulyEquals(b2,b3) ); + h.check( b2.toString().equals("{}") ); b2.xor(b1); b3.or(b1); h.check( trulyEquals(b2,b3) ); From tromey@cygnus.com Thu Apr 1 00:00:00 1999 From: tromey@cygnus.com (Tom Tromey) Date: Thu, 01 Apr 1999 00:00:00 -0000 Subject: Reading Writing and Support Classes References: <199902190423.XAA29516@melange.gnu.org> <199902190444.UAA16498@hoser.cygnus.com> Message-ID: <87oglzrx1n.fsf@cygnus.com> This is a reply to some relatively old email... Anthony> My feeling is that for tests that really require File Anthony> support, we should tag them with something like HAVE_File. Anthony> HAVE_File can be set by default in the choose script, and Anthony> then implementations that don't support File stuff just Anthony> !HAVE_File. Or something like that. I agree. We should also keep a list of all the tags we define and what they are intended to mean. Anthony> I kind of think that we should have a Anthony> SimpleTestHarness.java.in, and then set the srcdir and temp Anthony> dir at configure time. What do you think? That would be fine with me. Tom From tromey@cygnus.com Thu Apr 1 00:00:00 1999 From: tromey@cygnus.com (Tom Tromey) Date: Thu, 01 Apr 1999 00:00:00 -0000 Subject: Library/VM tests References: <36DC7DA9.16A46D4F@transvirtual.com> <36DE6CCC.83CF838B@pg.gda.pl> <36DF49FC.DE96ADD8@transvirtual.com> Message-ID: <87n21jrwv8.fsf@cygnus.com> >>>>> "Tim" == Tim Wilkinson writes: Tim> I guess I wasn't thinking of testing the basic operations of the Tim> VM - but when it comes down to it they should be tested too don't Tim> you think - after all they have to work correctly too right? I agree. Tim> Perhaps the testsuite should be split into various sub-trees Tim> contains test designed to go after particular bits of the Java Tim> implementation - you could put array[-1] in the tests designed to Tim> check the VM in one area and leave the API tests in another. This sounds good to me. Tim> For such things as serialization I'm not sure what the best Tim> structure would be - arguably you can serialize any class (even Tim> ones which don't implement Serializable have a behaviour that can Tim> be checked) - perhaps you just put a serializable check in each Tim> class test directory, or maybe you lump the serialization Tim> together (I'd go for the first option). This sounds good too. We just need to mark such tests with some kind of serialization-specific tag. Is there anybody who is *against* expanding Mauve to include VM tests? If not, then we should go ahead and talk about requirements and implementation. Tom From jsm@cygnus.com Thu Apr 1 00:00:00 1999 From: jsm@cygnus.com (Jason Molenda) Date: Thu, 01 Apr 1999 00:00:00 -0000 Subject: Quick test Message-ID: <19990218112202.A1012@cygnus.com> I had a report that the mailing list is having problems. This is a quick test. From tromey@cygnus.com Thu Apr 1 00:00:00 1999 From: tromey@cygnus.com (Tom Tromey) Date: Thu, 01 Apr 1999 00:00:00 -0000 Subject: Mauve with my own java compiler References: <36ACEFE4.A52A4CE8@dms.at> Message-ID: <87ww28zbpa.fsf@cygnus.com> >>>>> "Vincent" == Vincent Gay-Para writes: Vincent> Some remarks: Vincent> - you don't use the CLASSPATH from the user so I was unable Vincent> to use my compiler directly with JAVAC='java at.dms.kjc.Main' Vincent> (it's my compiler). And I need to modifie the Makefile by Vincent> hand. How would you suggest we change the Makefile to make this easier? Vincent> - it is difficult to found a compile error with "jikes *" and Vincent> then "error in file Test" where all files are named Test ! That sounds like a bug in jikes to me. It seems like it ought to report more of the filename. I agree that having many files named "Test.java" is less than ideal, but I'm also not all that motivated to go rename them. Tom From aph@pasanda.cygnus.co.uk Thu Apr 1 04:02:00 1999 From: aph@pasanda.cygnus.co.uk (Andrew Haley) Date: Thu, 01 Apr 1999 04:02:00 -0000 Subject: New files checked in. References: <199903141705.JAA25942@hoser.cygnus.com> Message-ID: <19990401120235.23220.qmail@pasanda.cygnus.co.uk> > Date: Sun, 14 Mar 1999 09:05:45 -0800 > From: Anthony Green > > I've checked in a few of the new tests from HP. Andrew Haley did the > initial conversion to make them work in our framework. > > If you run them, you'll see that the test count isn't significantly > higher than before. It has to do with how the tests are counted. > Their code tries all kinds of things and only register failures when > they happen, whereas we like to keep track of `passes' as well. My > hope is that that these files will slowly migrate over to using the > harness.check methods rather than just harness.fail. If anyone feels > inspired, that would be very helpful. I've converted every instance of if (testcase) harness.fail ("Error"); to harness.check (!(testcase), "Error"); I did this automatically and have not attempted to rationalize any of the tests. This means that you'll see a lot of things like harness.check(!( !nan.isNaN()) but at least you'll now get a more accurate count of test passes. This doesn't work in every case, because there are many instances of things like try { testcase; } catch ( Exception e ) { harness.fail("Error"); } and if (testcase) { System.out.print (diagnostic); harness.fail("Error"); } which do not easily fit into the harness.check() way of doing things. Andrew. From peter@transvirtual.com Fri Apr 16 11:25:00 1999 From: peter@transvirtual.com (Peter Mehlitz) Date: Fri, 16 Apr 1999 11:25:00 -0000 Subject: AWT testing issues Message-ID: <37178075.63B58C0F@transvirtual.com> Hi all, Being in charge of the Kaffe AWT implementations, I'm thinking about to turn over our huge set of quick&dirty AWT testlets into something useful for mauve. Have there already been plans for how to tackle AWT testing issues? How do we want to cope with this notorious "side-effect" lib? We certainly can do something with respect to event flow tests, but there remain a lot of unsolved issues (e.g. how to test disabled Components without manual input). Is somebody already working on this? -- Peter -- Peter Mehlitz Tel: +1 510 704 1527 Transvirtual Technologies, Inc., Fax: +1 510 704 1893 http://www.transvirtual.com Email: peter@transvirtual.com From arenn@urbanophile.com Fri Apr 16 11:38:00 1999 From: arenn@urbanophile.com (Aaron M. Renn) Date: Fri, 16 Apr 1999 11:38:00 -0000 Subject: AWT testing issues Message-ID: <019001be8837$e8c31370$8638d6d8@6748bsc3p255.focal.com> >Have there already been plans for how to tackle AWT testing issues? How do we >want to cope with this notorious "side-effect" lib? We certainly can do >something with respect to event flow tests, but there remain a lot of unsolved >issues (e.g. how to test disabled Components without manual input). Is >somebody already working on this? I don't believe that anyone has done any work on AWT related tests yet. Certainly this presents more challenges than some of the other packages. Sorry I cannot be more helpful but I have not done much work with the AWT myself. -- Aaron M. Renn (arenn@urbanophile.com) http://www.urbanophile.com/arenn/ From warrenl@cygnus.com Thu Apr 29 15:24:00 1999 From: warrenl@cygnus.com (Warren Levy) Date: Thu, 29 Apr 1999 15:24:00 -0000 Subject: HP java.net tests committed to Mauve Message-ID: Folks, I just checked in Mauve tests for the java.net package that are based on the contributed HP tests for that package. I've done a pretty brute force conversion and tried as much as possible to convert things to use the TestHarness.check method. The tests as received from HP made extensive reference to internal machines at HP for connections. I have substituted these with the publicly accessible 'sourceware.cygnus.com' host. I have also created a (hopefully ;-) static web page for use by the tests at: < http://sourceware.cygnus.com/mauve/testarea/index.html > If/when more tests are developed, we can add/modify files on sourceware in the testarea dir for this purpose. That way we have greater reliability in keeping the test and the data in sync than if we relied on some arbitrary URL. I have *not* verified all the output/results produced by the tests. Given the conversion, I am sure that there are some false failures (as well as some meaningless passes). Also, I'm sure the tests can also be enhanced significantly to give us greater coverage. I encourage those interested in the java.net package to try out these tests and correct/extend them as appropriate. Take care! Warren Levy From green@cygnus.com Thu Apr 29 22:25:00 1999 From: green@cygnus.com (Anthony Green) Date: Thu, 29 Apr 1999 22:25:00 -0000 Subject: HP java.net tests committed to Mauve References: Message-ID: <199904300525.WAA18350@hoser.cygnus.com> Warren wrote: > Given the conversion, I am sure that there are some false failures > (as well as some meaningless passes). I was just trying some of these out. Some of the tests have to come out. For instance, there's a test for ServerSocket.toString(). I'm looking at the Java Class Libraries book right now, and it has very little to say about the specifics of this operation. The test checks for: ServerSocket[addr=all-zeros-broadcast/0.0.0.0,port=0,localport=30000] but the 1.1.7 JDK, for instance, does... ServerSocket[addr=0.0.0.0/0.0.0.0,port=0,localport=30000] I'm curious about what the classpath and kaffe folks have done. AG -- Anthony Green Cygnus Solutions Sunnyvale, California From green@cygnus.com Thu Apr 29 22:27:00 1999 From: green@cygnus.com (Anthony Green) Date: Thu, 29 Apr 1999 22:27:00 -0000 Subject: AWT testing issues References: <37178075.63B58C0F@transvirtual.com> <37178075.63B58C0F@transvirtual.com> Message-ID: <199904300527.WAA18354@hoser.cygnus.com> Peter wrote: > Have there already been plans for how to tackle AWT testing issues? Nope. > Is somebody already working on this? Not that I am aware of. Can you describe what you have? AG -- Anthony Green Cygnus Solutions Sunnyvale, California From gatgul@voicenet.com Fri Apr 30 03:18:00 1999 From: gatgul@voicenet.com (Uncle George) Date: Fri, 30 Apr 1999 03:18:00 -0000 Subject: HP java.net tests committed to Mauve References: <199904300525.WAA18350@hoser.cygnus.com> Message-ID: <3729917C.E9D6C72C@voicenet.com> Could there be a -D or a shell environment var to make the net address something different than cygnus.. I am not always on the net, and woyld prefer to test on the loopback-first, eth-next, and ppp/slip-last gat From warrenl@cygnus.com Fri Apr 30 10:56:00 1999 From: warrenl@cygnus.com (Warren Levy) Date: Fri, 30 Apr 1999 10:56:00 -0000 Subject: HP java.net tests committed to Mauve References: <3728FAEB.ABC125FD@voicenet.com> Message-ID: It is quite reasonable to have the tests do a System.getProperty on a particular item and if set, use that in constructing the URL. It would require having a mirror of the testarea in the appropriate place (or the conditional code in the tests could get a bit tricky I suppose and exclude certain tests in the non-Internet case). At this point I don't have the bandwidth to add this functionality; if someone else were into doing it, that'd be great. --warrenl On Thu, 29 Apr 1999, Uncle George wrote: > Could it possibly be rewritten to accept -D or a shell environment variable ? > I dont think i wanna rely on the internet to do ALL net testing, where my > local net would do ( & is faster than the ~26kb connection!) > gat > > Warren Levy wrote: > > > The tests as received from HP made extensive reference to internal > > machines at HP for connections. I have substituted these with the > > publicly accessible 'sourceware.cygnus.com' host. I have also created > > a (hopefully ;-) static web page for use by the tests at: > > > > < http://sourceware.cygnus.com/mauve/testarea/index.html > From peter@transvirtual.com Fri Apr 30 12:29:00 1999 From: peter@transvirtual.com (Peter Mehlitz) Date: Fri, 30 Apr 1999 12:29:00 -0000 Subject: AWT testing issues References: <37178075.63B58C0F@transvirtual.com> <199904300527.WAA18354@hoser.cygnus.com> Message-ID: <372A0484.251E78BD@transvirtual.com> Anthony Green wrote: > Can you describe what you have? Tons of little apps testing isolated things like single widgets (Buttons, TextFields etc.), and some more complex examples (like the Kaffe WidgetsDemo). But the point is that none of them can be used for automated testing. Most of them log something to System.out, but in a way which is platform dependent (e.g. on particular AWTEvent.toString() implementations). I was thinking of to "normalize" this output so that we can test it regardless of the AWT implementation. The other thing is to think about automated input, e.g. by means of a playback of recorded events. But that has limitations, too. For example, a certain AWT might not receive events for disabled components at all, and therefore you couldn't test enable/disable with that scheme. There also might be a dependency on how the Java event queue/dispatch thread is interfaced with the native one (e.g. if it is in a completely asynchronous thread or uses some kind of a blocking native getNextEvent). Then we have the problem of rendering validation, where it gets really hard to automate something. Seems that this is a area that needs a lot more thoughts. But that's not a big surprise, given the kind of specification we have for the AWT. -- Peter From gatgul@voicenet.com Sat May 1 04:07:00 1999 From: gatgul@voicenet.com (Uncle George) Date: Sat, 01 May 1999 04:07:00 -0000 Subject: HP java.net tests committed to Mauve References: Message-ID: <372AEE1B.A679DDE1@voicenet.com> Is not The net/testarea distributed with the tar.gz files ? Are they built on the fly , or are they static. gat Warren Levy wrote: > It > would require having a mirror of the testarea in the appropriate place > (or the conditional code in the tests could get a bit tricky I suppose > and exclude certain tests in the non-Internet case). From warrenl@cygnus.com Sat May 1 23:57:00 1999 From: warrenl@cygnus.com (Warren Levy) Date: Sat, 01 May 1999 23:57:00 -0000 Subject: HP java.net tests committed to Mauve References: <372AEE1B.A679DDE1@voicenet.com> Message-ID: It's actually mauve/testarea (rather than net), meaning it's part of the web pages and I don't believe the web pages are part of the snapshot tar file. Shouldn't be a problem as you can view the source of web pages from most browsers and just save it on your system for future use. --warrenl On Sat, 1 May 1999, Uncle George wrote: > Is not The net/testarea distributed with the tar.gz files ? Are they built on the > fly , or are they static. > > Warren Levy wrote: > > > It > > would require having a mirror of the testarea in the appropriate place > > (or the conditional code in the tests could get a bit tricky I suppose > > and exclude certain tests in the non-Internet case). From govind@mediabreeze.com Mon May 10 12:33:00 1999 From: govind@mediabreeze.com (Govind Shridhare) Date: Mon, 10 May 1999 12:33:00 -0000 Subject: Mauve running on Windows 98 Box? Message-ID: <000001be9b1c$15e26260$7f080ccf@w9x6w1> Hi there I was wondering if I can configure and run Mauve on windows 98 box? Thanks Govind Shridhare Govind@MediaBreeze.com MediaBreeze.com - "Come, Join us in the Evolution!" From tromey@cygnus.com Mon May 10 12:40:00 1999 From: tromey@cygnus.com (Tom Tromey) Date: Mon, 10 May 1999 12:40:00 -0000 Subject: Mauve running on Windows 98 Box? References: <000001be9b1c$15e26260$7f080ccf@w9x6w1> Message-ID: <87g154af1j.fsf@cygnus.com> >>>>> "Govind" == Govind Shridhare writes: Govind> I was wondering if I can configure and run Mauve on windows 98 Govind> box? As far as I know, nobody has tried this. You could probably do it out of the box if you have Cygwin installed. Otherwise you'll probably have to duplicate the `choose' machinery to include only the test classes you can run. The README tries to describe what `choose' does. Let us know what you find out. Tom From qwm@ari.ncl.omron.co.jp Tue May 25 22:36:00 1999 From: qwm@ari.ncl.omron.co.jp (Qian Wei Min) Date: Tue, 25 May 1999 22:36:00 -0000 Subject: question Message-ID: <000901bea739$a799c6c0$ca10a8c0@qwm.ari.ncl.omron.co.jp> Hi! ???? ???????? "Note that you will need GNU make to use this testsuite.???? " This word is in the README. How can I get 'GNU make '? ???? Thanks. From qwm@ari.ncl.omron.co.jp Tue May 25 22:46:00 1999 From: qwm@ari.ncl.omron.co.jp (Qian Wei Min) Date: Tue, 25 May 1999 22:46:00 -0000 Subject: question Message-ID: <000901bea73a$fa9a23a0$ca10a8c0@qwm.ari.ncl.omron.co.jp> Hi! ???? ???????????? Now I want to install Mauve.(mauve-snapshot-1999-05-20_tar.tar) ???????? "Note that you will need GNU make to use this testsuite.???? " ???????? This word is in the README. ???????? How can I get 'GNU make '? ???? Thanks. From tromey@cygnus.com Wed May 26 08:54:00 1999 From: tromey@cygnus.com (Tom Tromey) Date: Wed, 26 May 1999 08:54:00 -0000 Subject: question References: <000901bea739$a799c6c0$ca10a8c0@qwm.ari.ncl.omron.co.jp> Message-ID: <87btf74yk0.fsf@cygnus.com> >>>>> ">" == Qian Wei Min writes: >> "Note that you will need GNU make to use this testsuite. " >> This word is in the README. >> How can I get 'GNU make '? Get it from ftp.gnu.org or one of its many mirrors. Tom From qwm@ari.ncl.omron.co.jp Sun May 30 23:04:00 1999 From: qwm@ari.ncl.omron.co.jp (Qian Wei Min) Date: Sun, 30 May 1999 23:04:00 -0000 Subject: question Message-ID: <002801beab2b$5e054660$ca10a8c0@qwm.ari.ncl.omron.co.jp> Dear sir: ???? I am a beginner. I want to use Mauve. Now the file I used is mauve-snapshot-1999-05-20_tar.tar. ???? I???? used 'configure'???? and???? changed anything. ???? Then I used 'make'.But system show next two lines. "Makefile",line 301:Need an operator make: fatal errors encountered -- cannot continue The line 301 is ' include choices'. ???? I used '#' to ignore this line , and used 'make' . Everything is OK.Then used 'make' again. The same error happened,but this times error line is 307. "Makefile",line 307:Need an operator make: fatal errors encountered -- cannot continue The line 307 is ' include choices'. ???? And when I use 'make check' the return is "117 of 117 tests failed". FAIL: uncaught exception loading gnu.testlet.* All the reurn please see the file 'result.txt'. ???? Is there something error in my useing.? How can I do now?Can you help me? Thanks. ???? QWM ???? ok=no; if test -f .save-keys && test -f choices && test "`cat .save-keys`" = ""; then ok=yes; fi; here=`/bin/pwd`; if test "$ok" = no; then echo "" > .save-keys; cd . && /bin/sh choose $here ; fi javac -g gnu/testlet/config.java here=`/bin/pwd`; cd .; CLASSPATH=$here:`/bin/pwd` javac -g -d $here gnu/testlet/SimpleTestHarness.java gnu/testlet/TestHarness.java gnu/testlet/Testlet.java gnu/testlet/ResourceNotFoundException.java touch classes.stamp make check-local ok=no; if test -f .save-keys && test -f choices && test "`cat .save-keys`" = ""; then ok=yes; fi; here=`/bin/pwd`; if test "$ok" = no; then echo "" > .save-keys; cd . && /bin/sh choose $here ; fi here=`/bin/pwd`; cd .; CLASSPATH=$here:`/bin/pwd` javac -g -d $here gnu/testlet/SimpleTestHarness.java gnu/testlet/TestHarness.java gnu/testlet/Testlet.java gnu/testlet/ResourceNotFoundException.java touch classes.stamp cat classes | java gnu.testlet.SimpleTestHarness FAIL: uncaught exception loading gnu.testlet.java.beans.DescriptorTest FAIL: uncaught exception loading gnu.testlet.java.beans.IntrospectorTest FAIL: uncaught exception loading gnu.testlet.java.io.BufferedByteOutputStream.Test FAIL: uncaught exception loading gnu.testlet.java.io.BufferedCharWriter.Test FAIL: uncaught exception loading gnu.testlet.java.io.BufferedInputStream.MarkReset FAIL: uncaught exception loading gnu.testlet.java.io.BufferedInputStream.ProtectedVars FAIL: uncaught exception loading gnu.testlet.java.io.BufferedInputStream.SimpleRead FAIL: uncaught exception loading gnu.testlet.java.io.BufferedReader.MarkReset FAIL: uncaught exception loading gnu.testlet.java.io.BufferedReader.SimpleRead FAIL: uncaught exception loading gnu.testlet.java.io.ByteArrayInputStream.MarkReset FAIL: uncaught exception loading gnu.testlet.java.io.ByteArrayInputStream.ProtectedVars FAIL: uncaught exception loading gnu.testlet.java.io.ByteArrayInputStream.SimpleRead FAIL: uncaught exception loading gnu.testlet.java.io.CharArrayReader.MarkReset FAIL: uncaught exception loading gnu.testlet.java.io.CharArrayReader.ProtectedVars FAIL: uncaught exception loading gnu.testlet.java.io.CharArrayReader.SimpleRead FAIL: uncaught exception loading gnu.testlet.java.io.DataInputOutput.ReadReference FAIL: uncaught exception loading gnu.testlet.java.io.DataInputOutput.WriteRead FAIL: uncaught exception loading gnu.testlet.java.io.DataInputStream.readLine FAIL: uncaught exception loading gnu.testlet.java.io.LineNumberInputStream.Test FAIL: uncaught exception loading gnu.testlet.java.io.LineNumberReader.Test FAIL: uncaught exception loading gnu.testlet.java.io.PipedReaderWriter.Test FAIL: uncaught exception loading gnu.testlet.java.io.PipedStream.Test FAIL: uncaught exception loading gnu.testlet.java.io.PushbackInputStream.BufferOverflow FAIL: uncaught exception loading gnu.testlet.java.io.PushbackInputStream.ProtectedVars FAIL: uncaught exception loading gnu.testlet.java.io.PushbackInputStream.Unread FAIL: uncaught exception loading gnu.testlet.java.io.PushbackReader.BufferOverflow FAIL: uncaught exception loading gnu.testlet.java.io.PushbackReader.Unread FAIL: uncaught exception loading gnu.testlet.java.io.SequenceInputStream.Test FAIL: uncaught exception loading gnu.testlet.java.io.StringBufferInputStream.MarkReset FAIL: uncaught exception loading gnu.testlet.java.io.StringBufferInputStream.ProtectedVars FAIL: uncaught exception loading gnu.testlet.java.io.StringBufferInputStream.SimpleRead FAIL: uncaught exception loading gnu.testlet.java.io.StringWriter.Test FAIL: uncaught exception loading gnu.testlet.java.io.Utf8Encoding.ReadReference FAIL: uncaught exception loading gnu.testlet.java.io.Utf8Encoding.WriteRead FAIL: uncaught exception loading gnu.testlet.java.lang.Boolean.equals_Boolean FAIL: uncaught exception loading gnu.testlet.java.lang.Boolean.get FAIL: uncaught exception loading gnu.testlet.java.lang.Boolean.hashcode_Boolean FAIL: uncaught exception loading gnu.testlet.java.lang.Boolean.new_Boolean FAIL: uncaught exception loading gnu.testlet.java.lang.Boolean.value FAIL: uncaught exception loading gnu.testlet.java.lang.Byte.new_Byte FAIL: uncaught exception loading gnu.testlet.java.lang.Character.classify FAIL: uncaught exception loading gnu.testlet.java.lang.Character.consts FAIL: uncaught exception loading gnu.testlet.java.lang.Character.digit FAIL: uncaught exception loading gnu.testlet.java.lang.Character.equals_Character FAIL: uncaught exception loading gnu.testlet.java.lang.Character.forDigit FAIL: uncaught exception loading gnu.testlet.java.lang.Character.getNumericValue FAIL: uncaught exception loading gnu.testlet.java.lang.Character.getType FAIL: uncaught exception loading gnu.testlet.java.lang.Character.hash FAIL: uncaught exception loading gnu.testlet.java.lang.Character.to FAIL: uncaught exception loading gnu.testlet.java.lang.Character.unicode FAIL: uncaught exception loading gnu.testlet.java.lang.Double.new_Double FAIL: uncaught exception loading gnu.testlet.java.lang.Float.new_Float FAIL: uncaught exception loading gnu.testlet.java.lang.Integer.getInteger FAIL: uncaught exception loading gnu.testlet.java.lang.Integer.new_Integer FAIL: uncaught exception loading gnu.testlet.java.lang.Long.getLong FAIL: uncaught exception loading gnu.testlet.java.lang.Long.new_Long FAIL: uncaught exception loading gnu.testlet.java.lang.Math.cos FAIL: uncaught exception loading gnu.testlet.java.lang.Math.max FAIL: uncaught exception loading gnu.testlet.java.lang.Math.min FAIL: uncaught exception loading gnu.testlet.java.lang.Math.rint FAIL: uncaught exception loading gnu.testlet.java.lang.Short.hash FAIL: uncaught exception loading gnu.testlet.java.lang.String.charAt FAIL: uncaught exception loading gnu.testlet.java.lang.String.compareTo FAIL: uncaught exception loading gnu.testlet.java.lang.String.decode FAIL: uncaught exception loading gnu.testlet.java.lang.String.getBytes FAIL: uncaught exception loading gnu.testlet.java.lang.String.indexOf FAIL: uncaught exception loading gnu.testlet.java.lang.String.new_String FAIL: uncaught exception loading gnu.testlet.java.lang.String.startsWith FAIL: uncaught exception loading gnu.testlet.java.lang.String.substring FAIL: uncaught exception loading gnu.testlet.java.lang.String.to FAIL: uncaught exception loading gnu.testlet.java.lang.StringBuffer.plus FAIL: uncaught exception loading gnu.testlet.java.lang.System.arraycopy FAIL: uncaught exception loading gnu.testlet.java.lang.reflect.Modifier.toString FAIL: uncaught exception loading gnu.testlet.java.net.DatagramPacket.DatagramPacketTest FAIL: uncaught exception loading gnu.testlet.java.net.DatagramPacket.DatagramPacketTest2 FAIL: uncaught exception loading gnu.testlet.java.net.DatagramSocket.DatagramSocketTest FAIL: uncaught exception loading gnu.testlet.java.net.DatagramSocket.DatagramSocketTest2 FAIL: uncaught exception loading gnu.testlet.java.net.InetAddress.InetAddressTest FAIL: uncaught exception loading gnu.testlet.java.net.MulticastSocket.MulticastSocketTest FAIL: uncaught exception loading gnu.testlet.java.net.ServerSocket.ServerSocketTest FAIL: uncaught exception loading gnu.testlet.java.net.Socket.SocketTest FAIL: uncaught exception loading gnu.testlet.java.net.URL.URLTest FAIL: uncaught exception loading gnu.testlet.java.net.URLConnection.URLConnectionTest FAIL: uncaught exception loading gnu.testlet.java.net.URLEncoder.URLEncoderTest FAIL: uncaught exception loading gnu.testlet.java.sql.Connection.TestJdbc10 FAIL: uncaught exception loading gnu.testlet.java.sql.DatabaseMetaData.TestJdbc10 FAIL: uncaught exception loading gnu.testlet.java.sql.Types.TestJdbc10 FAIL: uncaught exception loading gnu.testlet.java.text.BreakIterator.chariter FAIL: uncaught exception loading gnu.testlet.java.text.BreakIterator.lineiter FAIL: uncaught exception loading gnu.testlet.java.text.BreakIterator.sentiter FAIL: uncaught exception loading gnu.testlet.java.text.BreakIterator.worditer FAIL: uncaught exception loading gnu.testlet.java.text.CharacterIterator.implement FAIL: uncaught exception loading gnu.testlet.java.text.ChoiceFormat.format FAIL: uncaught exception loading gnu.testlet.java.text.ChoiceFormat.next FAIL: uncaught exception loading gnu.testlet.java.text.ChoiceFormat.parse FAIL: uncaught exception loading gnu.testlet.java.text.Collator.Constants FAIL: uncaught exception loading gnu.testlet.java.text.Collator.GetSet FAIL: uncaught exception loading gnu.testlet.java.text.DateFormat.Test FAIL: uncaught exception loading gnu.testlet.java.text.DateFormatSymbols.Test FAIL: uncaught exception loading gnu.testlet.java.text.DecimalFormat.format FAIL: uncaught exception loading gnu.testlet.java.text.DecimalFormat.parse FAIL: uncaught exception loading gnu.testlet.java.text.DecimalFormat.position FAIL: uncaught exception loading gnu.testlet.java.text.DecimalFormat.topattern FAIL: uncaught exception loading gnu.testlet.java.text.DecimalFormatSymbols.DumpDefault11 FAIL: uncaught exception loading gnu.testlet.java.text.DecimalFormatSymbols.GetSet11 FAIL: uncaught exception loading gnu.testlet.java.text.MessageFormat.format FAIL: uncaught exception loading gnu.testlet.java.text.MessageFormat.parse FAIL: uncaught exception loading gnu.testlet.java.text.ParseException.Test FAIL: uncaught exception loading gnu.testlet.java.text.RuleBasedCollator.VeryBasic FAIL: uncaught exception loading gnu.testlet.java.text.SimpleDateFormat.Test FAIL: uncaught exception loading gnu.testlet.java.text.StringCharacterIterator.constructor FAIL: uncaught exception loading gnu.testlet.java.util.BitSet.jdk10 FAIL: uncaught exception loading gnu.testlet.java.util.Hashtable.basic FAIL: uncaught exception loading gnu.testlet.java.util.Random.basic FAIL: uncaught exception loading gnu.testlet.java.util.ResourceBundle.getBundle FAIL: uncaught exception loading gnu.testlet.java.util.zip.GZIPInputStream.basic FAIL: uncaught exception loading gnu.testlet.java.util.zip.ZipInputStream.basic 117 of 117 tests failed *** Error code 1 Stop. *** Error code 1 Stop. From weijian@ari.ncl.omron.co.jp Mon May 31 23:56:00 1999 From: weijian@ari.ncl.omron.co.jp (weijian) Date: Mon, 31 May 1999 23:56:00 -0000 Subject: install Message-ID: <007201beabfb$cd7fd340$c510a8c0@weijian.ari.ncl.omron.co.jp> hello; I want to use mauve,but i can not install it,how to install,please teach me From green@cygnus.com Tue Jun 1 05:56:00 1999 From: green@cygnus.com (Anthony Green) Date: Tue, 01 Jun 1999 05:56:00 -0000 Subject: question References: <002801beab2b$5e054660$ca10a8c0@qwm.ari.ncl.omron.co.jp> <002801beab2b$5e054660$ca10a8c0@qwm.ari.ncl.omron.co.jp> Message-ID: <199906011256.FAA03740@hoser.cygnus.com> Qian Wei Min wrote: > Then I used 'make'.But system show next two lines. > "Makefile",line 301:Need an operator > make: fatal errors encountered -- cannot continue > The line 301 is ' include choices'. What kind of system are you using? Are you using GNU make? What does `make --version' say? > And when I use 'make check' the return is "117 of 117 tests failed". > FAIL: uncaught exception loading gnu.testlet.* > All the reurn please see the file 'result.txt'. It looks to me like none of the .class files are being built. You can't simply not include `choices', because this is what tells make which files to compile. Good luck! AG -- Anthony Green Cygnus Solutions Sunnyvale, California From green@cygnus.com Tue Jun 1 06:04:00 1999 From: green@cygnus.com (Anthony Green) Date: Tue, 01 Jun 1999 06:04:00 -0000 Subject: install References: <007201beabfb$cd7fd340$c510a8c0@weijian.ari.ncl.omron.co.jp> <007201beabfb$cd7fd340$c510a8c0@weijian.ari.ncl.omron.co.jp> Message-ID: <199906011303.GAA03745@hoser.cygnus.com> weijian wrote: > I want to use mauve,but i can not install it,how to install,please teach me  -=- MIME -=-  This is a multi-part message in MIME format. ------=_NextPart_000_006E_01BEAC47.3D4D8AA0 Content-Type: text/plain; charset="shift_jis" Content-Transfer-Encoding: 7bit hello; I want to use mauve,but i can not install it,how to install,please teach me ------=_NextPart_000_006E_01BEAC47.3D4D8AA0 Content-Type: text/html; charset="shift_jis" Content-Transfer-Encoding: quoted-printable
hello;
I want to use mauve,but i can not = install it,how=20 to install,please teach me
------=_NextPart_000_006E_01BEAC47.3D4D8AA0-- What kind of system are you using? If you are using any kind of normal unix box, you should be able to simply run `configure'. Follow the directions in the README file. If you are running Windows, you'll probably need to use cygwin in order to make your machine look like a unix box (see http://sourceware.cygnus.com/cygwin ). Although, I haven't tried this myself. AG -- Anthony Green Cygnus Solutions Sunnyvale, California From qwm@ari.ncl.omron.co.jp Thu Jun 3 02:47:00 1999 From: qwm@ari.ncl.omron.co.jp (Qian Wei Min) Date: Thu, 03 Jun 1999 02:47:00 -0000 Subject: Help me please! Message-ID: <000901beada5$df467ba0$ca10a8c0@qwm.ari.ncl.omron.co.jp> Now I want to use Mauve. (mauve-snapshot-1999-05-24_tar.tar GNU make???? version 3.77) ???? 1.decompress files 2.configure 3.make but system show"make: Nothing to be done for `all'." 4.make check System show many FAILs link the last of this mail ant cannot finish(I waited 30 minutes). Why?What need me to do? ???? I am a beginner. ????I do not know Mauve how to test, and how to let it to test that you want to test? Please tell me! Thank you! ???? qwm ???? FAIL: gnu.testlet.java.beans.DescriptorTest (number 1)FAIL: gnu.testlet.java.beans.IntrospectorTest (number 16)FAIL: gnu.testlet.java.beans.IntrospectorTest (number 17)FAIL: gnu.testlet.java.beans.IntrospectorTest (number 18)FAIL: gnu.testlet.java.io.LineNumberReader.Test: getLineNumber - first series (number 1)FAIL: gnu.testlet.java.lang.Character.getType (number 27)FAIL: gnu.testlet.java.lang.Character.unicode: Character aa:FEMININE ORDINAL INDICATOR incorectly reported as lowercase (number 1)FAIL: gnu.testlet.java.lang.Character.unicode: Character b5:MICRO SIGN incorectly reported as lowercase (number 1)FAIL: gnu.testlet.java.lang.Character.unicode: Character ba:MASCULINE ORDINAL INDICATOR incorectly reported as lowercase (number 1) . . . . FAIL: gnu.testlet.java.lang.Character.unicode: Character ff65:HALFWIDTH KATAKANA MIDDLE DOT incorectly reported as not-unicodeidentifierpart (number 1)FAIL: gnu.testlet.java.lang.Double.new_Double (number 1)FAIL: gnu.testlet.java.net.DatagramPacket.DatagramPacketTest2: invalid_buf: test 2 - Should throw NullPointerException (number 1)FAIL: gnu.testlet.java.net.DatagramPacket.DatagramPacketTest2: invalid_buf: test 4 - Should throw NullPointerException (number 1)FAIL: gnu.testlet.java.net.DatagramPacket.DatagramPacketTest2: invalid_buflen: test 1 - Should NOT throw IllegalArgumentException (number 1)FAIL: gnu.testlet.java.net.DatagramPacket.DatagramPacketTest2: invalid_buflen: test 3 - Should throw IllegalArgumentException (number 1)FAIL: gnu.testlet.java.net.DatagramPacket.DatagramPacketTest2: invalid_addr: test 1 - Should throw NullPointerException (number 1)FAIL: gnu.testlet.java.net.DatagramPacket.DatagramPacketTest2: invalid_addr: test 2 - Should throw NullPointerException (number 1)FAIL: gnu.testlet.java.net.DatagramPacket.DatagramPacketTest2: invalid_addr: test 3 - Should throw NullPointerException (number 1)FAIL: gnu.testlet.java.net.DatagramSocket.DatagramSocketTest: Error : test_echoWithTimeout failed - 5 Exception occured while sending/receiving???? (number 1)FAIL: gnu.testlet.java.net.DatagramSocket.DatagramSocketTest: Error : test_echoWithTimeout - 7 failed The echo server didnot send the expected data???? (number 1)FAIL: gnu.testlet.java.net.InetAddress.InetAddressTest: Error : test_Basics failed - 10???? Should not throw UnknownHostException here???? (number 1) FAIL: gnu.testlet.java.net.InetAddress.InetAddressTest: uncaught exception at "Error : test_Basics failed - 10???? Should not throw UnknownHostException here " number 2FAIL: gnu.testlet.java.net.MulticastSocket.MulticastSocketTest: joinGroup() with incorrect params. should have thrown an IOException - 5a (number 1)FAIL: gnu.testlet.java.net.ServerSocket.ServerSocketTest: Error : test_params failed - 4toString did not return proper values???? (number 1)FAIL: gnu.testlet.java.net.ServerSocket.ServerSocketTest: Error : test_params failed - 5getInetAddress did not return proper values???? (number 1)FAIL: gnu.testlet.java.net.Socket.SocketTest: Error : test_Basics failed - 7 exception should not have been thrown here (number 1)FAIL: gnu.testlet.java.net.Socket.SocketTest: Error : test_params failed - 10 exception was thrown (number 1)FAIL: gnu.testlet.java.net.Socket.SocketTest: Error : test_BasicServer failed - 0 exception was thrown :null (number 1) ???? From green@cygnus.com Thu Jun 3 08:14:00 1999 From: green@cygnus.com (Anthony Green) Date: Thu, 03 Jun 1999 08:14:00 -0000 Subject: Help me please! References: <000901beada5$df467ba0$ca10a8c0@qwm.ari.ncl.omron.co.jp> Message-ID: <199906031513.IAA00657@fencer.cygnus.com> Qian Wei Min wrote: > Now I want to use Mauve. What java implementation are you testing? If you are testing against a 1.1 implementation, you must run: make KEYS=JDK1.1 check This is documented in the README file. > System show many FAILs link the last of this mail ant cannot finish(I waited > 30 minutes). > Why?What need me to do? Each failures is either... - a java implementation error, or - a test case error There are many known cases where Sun's implementation strays from the documentation. The tests are written to the documentation, so we expect to see many failures from Sun's JDK's. As for the hang, this is in the middle of the java.net test code. Our framework is still very primitive. Failing tests should actually time out, but they don't right now. This will require some more infrastructure work. AG -- Anthony Green Cygnus Solutions Sunnyvale, California From gatgul@voicenet.com Thu Jun 3 11:27:00 1999 From: gatgul@voicenet.com (Uncle George) Date: Thu, 03 Jun 1999 11:27:00 -0000 Subject: Help me please! References: <199906031513.IAA00657@fencer.cygnus.com> Message-ID: <3756C913.326972C0@voicenet.com> I'd prefer the term "inconsistencies" rather that failures. It is not (always) so obvious from the documentation as to how the software should work, and/or behave . Sometimes documentation wins the argument, and sometimes the software. gat Anthony Green wrote: > There are many known cases where Sun's implementation strays from the > documentation. The tests are written to the documentation, so we > expect to see many failures from Sun's JDK's. From qwm@ari.ncl.omron.co.jp Fri Jun 4 03:20:00 1999 From: qwm@ari.ncl.omron.co.jp (Qian Wei Min) Date: Fri, 04 Jun 1999 03:20:00 -0000 Subject: KEYS Message-ID: <000901beae73$848a97e0$ca10a8c0@qwm.ari.ncl.omron.co.jp> I want to use???? variable 'KEYS' to select a subset of the tests. ???? I input : make KEYS='!java. java.lang' check ???? Is it right? ???? But the return is : java.: Event not found. ???? Why? Please tell me What I did is error? Thank you very much! ???? qwm From aph@pasanda.cygnus.co.uk Fri Jun 4 03:30:00 1999 From: aph@pasanda.cygnus.co.uk (Andrew Haley) Date: Fri, 04 Jun 1999 03:30:00 -0000 Subject: KEYS References: <000901beae73$848a97e0$ca10a8c0@qwm.ari.ncl.omron.co.jp> Message-ID: <19990604103007.29615.qmail@pasanda.cygnus.co.uk> > From: "Qian Wei Min" > Date: Fri, 4 Jun 1999 19:17:57 +0900 > > This is a multi-part message in MIME format. Please don't do this: it discourages people from reading your mail. > ------=_NextPart_000_0005_01BEAEBE.F450AE20 > Content-Type: text/plain; > charset="gb2312" > Content-Transfer-Encoding: 7bit > > I want to use variable 'KEYS' to select a subset of the tests. > > I input : make KEYS='!java. java.lang' check > > Is it right? > > But the return is : java.: Event not found. > > Why? The '!' in your command is being expanded by the shell. Try: make KEYS='\!java. java.lang' check Andrew. From gback@cs.utah.edu Mon Jun 7 18:28:00 1999 From: gback@cs.utah.edu (Godmar Back) Date: Mon, 07 Jun 1999 18:28:00 -0000 Subject: KEYS References: <19990604103007.29615.qmail@pasanda.cygnus.co.uk> Message-ID: <199906080128.TAA63567@k2.cs.utah.edu> FWIW, what I find counterintuitive is that if you say KEYS="\!java. java.lang" it will do only java.lang, but if you put the same lines in a file mauve-QUUX and then say KEYS=QUUX it won't do anything. The reason, I think, is that in the first case, JDK1.0 and JDK1.1 are set, while in the latter case you have to set them in the file. - Godmar > > > From: "Qian Wei Min" > > Date: Fri, 4 Jun 1999 19:17:57 +0900 > > > > This is a multi-part message in MIME format. > > Please don't do this: it discourages people from reading your mail. > > > ------=_NextPart_000_0005_01BEAEBE.F450AE20 > > Content-Type: text/plain; > > charset="gb2312" > > Content-Transfer-Encoding: 7bit > > > > I want to use variable 'KEYS' to select a subset of the tests. > > > > I input : make KEYS='!java. java.lang' check > > > > Is it right? > > > > But the return is : java.: Event not found. > > > > Why? > > The '!' in your command is being expanded by the shell. Try: > > make KEYS='\!java. java.lang' check > > Andrew. > From warrenl@cygnus.com Wed Jun 23 18:08:00 1999 From: warrenl@cygnus.com (Warren Levy) Date: Wed, 23 Jun 1999 18:08:00 -0000 Subject: BufferedOutputStream patch References: <199906212330.QAA386712@arthur.ucsf.edu> Message-ID: John-Marc, First off, please note I've also cc'ed this to the mauve-discuss list (in addition to the java-discuss list you originally addressed) as there are folks following mauve-discuss who have valuable input on Java lib issues like this. Notwithstanding the VM behavior you observed, the doc I checked is not consistently clear on what should be done. The Java Class Libraries book (Second Edition, ISBN 0-201-31002-3) agrees with you for BufferedOutputStream in JDK 1.1, "If there is room in the buffer of this stream to hold the bytes, they are buffered..." But for BufferedWriter it says "If this writer's internal buffer becomes full as a result of this write, the contents of the internal buffer are flushed..." which is what the libgcj code seems to be doing when I look at it (though unless I misunderstood your original msg, you claim that BufferedWriter.write in libgcj behaves otherwise and doesn't do the flush until the buffer overflows). Though BufferedOutputStream needs a fix to one of it's 2 write methods to make them behave consistent with each other in this respect, I am holding off applying your patch temporarily because of what I found when looking at the JDK 1.2 doc. Though the JDK 1.2 online doc doesn't say anything specific on this issue for BufferedWriter, it does contradict the JCL book on BufferedOutputStream, "The data is written into an internal buffer, and then written to the underlying stream if the buffer reaches its capacity..." This seems to infer that the BufferedOutputStream behavior changed in JDK 1.2 to match the described behavior of BufferedWriter (i.e. flush on fill). Note that the Java Language Spec is not particularly clear and simply says "flushed as necessary" for BufferedOutputStream. I realize it could also be argued that the JCL & JDK 1.2 are simply wrong and should be ignored. I'd be interested in hearing others' opinions (and if your observed VM behavior was on JDK 1.2; that would be interesting input if available). I've checked around a bit and it seems that the typical behavior in *non*-Java buffering schemes is as you describe (i.e. flush on overflow rather than upon reaching capacity), so there is reasonable precedent for your requested behavior. So folks, anyone have opinions/justifications either way? Is the JDK 1.1 doc'ed behavior the way to go (BufferedOutputStream flush on overflow; BufferedWriter flush on fill)? Or the JDK 1.2 doc'ed behavior (flush on fill for both)? Or neither (flush on overflow for both)? I'm interested in hearing the different points of view on this. If you supply empirical evidence, please note whether it is version 1.1.* or 1.2 of the JDK. Thanks in advance and John-Marc, thanks for finding this! Warren Levy Cygnus Solutions, Sunnyvale, CA USA On Mon, 21 Jun 1999 jmc@cmpharm.ucsf.edu wrote: > I noticed that the write(byte[]) method of BufferedOutputStream > flushes immediately upon filling up the buffer; in a JVM (and > when using the write(byte) method), it doesn't flush until the next > write. As they say, "If it's yellow let it mellow..." Although > real apps shouldn't depend on either behavior, here is a patch > to make libgcj behave the same way a JVM does. I also confirmed > that BufferedWriter does not have the same bug: > > > diff -r -u libgcj-snapshot-1999-06-18.orig/libjava/java/io/BufferedOutputStream.java libgcj-snapshot-1999-06-18/libjava/java/io/BufferedOutputStream.java > --- libgcj-snapshot-1999-06-18.orig/libjava/java/io/BufferedOutputStream.java > Mon Jun 21 10:16:56 1999 > +++ libgcj-snapshot-1999-06-18/libjava/java/io/BufferedOutputStream.java > Mon Jun 21 10:23:19 1999 > @@ -56,7 +56,7 @@ > throws IOException, NullPointerException, IndexOutOfBoundsException > { > // If LEN < 0 then the downstream write will fail for us. > - if (len >= 0 && count + len < buf.length) > + if (len >= 0 && count + len <= buf.length) > { > System.arraycopy(b, off, buf, count, len); > count += len; > > JMC > -- > John-Marc Chandonia (jmc@cmpharm.ucsf.edu) We're everywhere... > Cohen Lab, University of California San Francisco for your convenience. > http://yuri.harvard.edu/~jmc -- Psi Corps <*> > From archie@whistle.com Wed Jun 23 18:15:00 1999 From: archie@whistle.com (Archie Cobbs) Date: Wed, 23 Jun 1999 18:15:00 -0000 Subject: BufferedOutputStream patch References: Message-ID: <199906240115.SAA32617@bubba.whistle.com> Warren Levy writes: > So folks, anyone have opinions/justifications either way? Is the JDK 1.1 > doc'ed behavior the way to go (BufferedOutputStream flush on overflow; > BufferedWriter flush on fill)? Or the JDK 1.2 doc'ed behavior (flush on > fill for both)? Or neither (flush on overflow for both)? I'm interested > in hearing the different points of view on this. If you supply empirical > evidence, please note whether it is version 1.1.* or 1.2 of the JDK. For what it's worth, kaffe flushes on overflow for both. -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com From per@bothner.com Wed Jun 23 20:10:00 1999 From: per@bothner.com (Per Bothner) Date: Wed, 23 Jun 1999 20:10:00 -0000 Subject: BufferedOutputStream patch References: Message-ID: Warren Levy writes: I think best behavior is flush on overflow - but I don't think it matters very much either way. -- --Per Bothner bothner@pacbell.net per@bothner.com http://home.pacbell.net/bothner/ From tromey@cygnus.com Fri Jun 25 12:43:00 1999 From: tromey@cygnus.com (Tom Tromey) Date: Fri, 25 Jun 1999 12:43:00 -0000 Subject: KEYS References: <19990604103007.29615.qmail@pasanda.cygnus.co.uk> <199906080128.TAA63567@k2.cs.utah.edu> <199906080128.TAA63567@k2.cs.utah.edu> Message-ID: <199906251943.MAA21730@ferrule.cygnus.com.> Godmar> FWIW, what I find counterintuitive is that if you say Godmar> KEYS="\!java. java.lang" it will do only java.lang, but if you Godmar> put the same lines in a file mauve-QUUX and then say KEYS=QUUX Godmar> it won't do anything. Since I added support for a mauve-* file, I stopped using KEYS except to specify the file to use. If you want to change how KEYS are interpreted, that's fine with me... Tom