From noa@resare.com Thu Oct 7 21:55:00 2004 From: noa@resare.com (Noa Resare) Date: Thu, 07 Oct 2004 21:55:00 -0000 Subject: bogus test in gnu.testlet.java.net.DatagramPacket.DatagramPacketTest2 Message-ID: <1097186153.1324.15.camel@localhost.localdomain> In invalid_addr() in gnu.testlet.java.net.DatagramPacket.DatagramPacketTest2.java the code tests if DatagramPacket throws NullPointerException on null InetAddress and null setAddress() argument. This is however not specified in either 1.5, 1.4.2 or 1.3.1 API javadoc and nor implemented in either sun's 1.4.2_05 nor classpath. Please apply the attached patch that removes the tests in question. cheers/noa ps. have anyone looked at the xml output patches? -------------- next part -------------- A non-text attachment was scrubbed... Name: mauve-DatagramPacket.patch Type: text/x-patch Size: 2018 bytes Desc: not available URL: From noa@resare.com Fri Oct 8 06:35:00 2004 From: noa@resare.com (Noa Resare) Date: Fri, 08 Oct 2004 06:35:00 -0000 Subject: gnu/testlet/java/nio/channels/FileChannel/manyopen.java broken Message-ID: <1097217312.1324.43.camel@localhost.localdomain> gnu/testlet/java/nio/channels/FileChannel/manyopen.java tries to open 1024 * 3 files and signals failure if that fails. I don't think it can be considered an error if this fails, especially since many popular operating systems limit the number open files that a single process can have: Here is the output of "ulimit -n" on some boxes I have access to: OpenBSD 3.4 x86: 64 Solaris 9 sparc: 256 Linux (debian 2.2 x86/suse 8 AMD64/Fedora core 1/2/3) : 1024 FreeBSD 4.10-BETA: 7322 NetBSD 1.6.1: 64 OSX 10.2: 256 Since the test doesn't actually test for anything other than the ability to open many files and the extent of that ability isn't specified in any spec that I'm aware of I suggest that we remove the test. /noa From crawley@dstc.edu.au Fri Oct 8 06:47:00 2004 From: crawley@dstc.edu.au (Stephen Crawley) Date: Fri, 08 Oct 2004 06:47:00 -0000 Subject: gnu/testlet/java/nio/channels/FileChannel/manyopen.java broken In-Reply-To: Message from Noa Resare of "Fri, 08 Oct 2004 08:35:12 +0200." <1097217312.1324.43.camel@localhost.localdomain> Message-ID: <200410080647.i986l9QQ020343@piglet.dstc.edu.au> noa@resare.com said: > Since the test doesn't actually test for anything other than the > ability to open many files and the extent of that ability isn't > specified in any spec that I'm aware of I suggest that we remove the > test. Agreed. It should be deleted. This testcase previously used to also (indirectly) check that orphaned file handles were closed by garbage collection finalization. However, this was done by explicitly calling System.gc(), and thus was even more broken that the current version of the testcase. -- Steve From mark@klomp.org Fri Oct 8 10:05:00 2004 From: mark@klomp.org (Mark Wielaard) Date: Fri, 08 Oct 2004 10:05:00 -0000 Subject: gnu/testlet/java/nio/channels/FileChannel/manyopen.java broken In-Reply-To: <200410080647.i986l9QQ020343@piglet.dstc.edu.au> References: <200410080647.i986l9QQ020343@piglet.dstc.edu.au> Message-ID: <1097229925.1087.10.camel@localhost> Hi, On Fri, 2004-10-08 at 08:47, Stephen Crawley wrote: > noa@resare.com said: > > Since the test doesn't actually test for anything other than the > > ability to open many files and the extent of that ability isn't > > specified in any spec that I'm aware of I suggest that we remove the > > test. > > Agreed. It should be deleted. > > This testcase previously used to also (indirectly) check that orphaned file > handles were closed by garbage collection finalization. However, this > was done by explicitly calling System.gc(), and thus was even more broken > that the current version of the testcase. As the person that wrote this test let me explain why I wrote it and what I think should be tested. We had a problem with real programs that open lots of files quickly (gjdoc does this for example, a jar tool or a webserver might be another good example) and don't explicitly close these files, but let the file/stream just get garbage collected since the program structure doesn't explicitly define a "owner" for the file/stream object (which isn't that uncommon since that is what you normally do with random allocated objects, long life the garbage collector!). What I think should be tested is whether a program can open lots of files. And that the systems notices that stale file handle resources can be removed so that a program can keep opening files if needed. (As long as there are no large number of life file handles open at the same time.) Since I have seen multiple systems get this wrong in various ways I want to have an explicit test for this situation. It might be that this test does not simulate a real world program correctly, so if there are alternatives I would like to hear them instead of just deleting the test since some systems fail it. Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From noa@resare.com Fri Oct 8 11:07:00 2004 From: noa@resare.com (Noa Resare) Date: Fri, 08 Oct 2004 11:07:00 -0000 Subject: gnu/testlet/java/nio/channels/FileChannel/manyopen.java broken In-Reply-To: <1097229925.1087.10.camel@localhost> References: <200410080647.i986l9QQ020343@piglet.dstc.edu.au> <1097229925.1087.10.camel@localhost> Message-ID: <1097233619.23574.3.camel@localhost.localdomain> On fre, 2004-10-08 at 12:05 +0200, Mark Wielaard wrote: > Hi, > What I think should be tested is whether a program can open lots of > files. And that the systems notices that stale file handle resources can > be removed so that a program can keep opening files if needed. (As long > as there are no large number of life file handles open at the same > time.) > > Since I have seen multiple systems get this wrong in various ways I want > to have an explicit test for this situation. It might be that this test > does not simulate a real world program correctly, so if there are > alternatives I would like to hear them instead of just deleting the test > since some systems fail it. Ah, now I understand. Thanks for the explanation. /noa From zander@javalobby.org Fri Oct 8 17:00:00 2004 From: zander@javalobby.org (Thomas Zander) Date: Fri, 08 Oct 2004 17:00:00 -0000 Subject: gnu/testlet/java/nio/channels/FileChannel/manyopen.java broken In-Reply-To: <1097229925.1087.10.camel@localhost> References: <200410080647.i986l9QQ020343@piglet.dstc.edu.au> <1097229925.1087.10.camel@localhost> Message-ID: <200410081900.29934.zander@javalobby.org> On Friday 08 October 2004 12:05, Mark Wielaard wrote: > What I think should be tested is whether a program can open lots of > files. And that the systems notices that stale file handle resources can > be removed so that a program can keep opening files if needed. (As long > as there are no large number of life file handles open at the same > time.) So; what you want tested if a) File has finalize method b) that method actually closes the filehandle c) the GC / Finalizer / GC (in that order) is called early enough and often enough to ensure not only we don't have a OutOfMem, but also that we don't get an out-of-filehandles problem. IMO that should give you 3 seperate tests with very different things; your test (from the description, I did not read the test itself) seems to have taken the black-box-approuch which is most of the time wrong for unit tests.. > Since I have seen multiple systems get this wrong in various ways I want > to have an explicit test for this situation. It might be that this test > does not simulate a real world program correctly, so if there are > alternatives I would like to hear them instead of just deleting the test > since some systems fail it. Isn't creating an 'any' object with a finalizer and doing the same things, but keeping a counter of how often finalize is called verses how many objects are present going to test this problem much much simpler? Just a thought... -- Thomas From noa@resare.com Fri Oct 8 21:42:00 2004 From: noa@resare.com (Noa Resare) Date: Fri, 08 Oct 2004 21:42:00 -0000 Subject: [PATCH] locale and date formatting dependent test in gnu/testlet/java/util/SimpleTimeZone/check12.java Message-ID: <1097271756.29859.12.camel@localhost.localdomain> While poking around in gnu/testlet/java/util/SimpleTimeZone/check12.java i found the following code: Date date = new Date(1034705556525l); TimeZone zone = TimeZone.getTimeZone("EST"); DateFormat dateFormat = DateFormat.getDateTimeInstance( DateFormat.SHORT, DateFormat.LONG, Locale.getDefault()); dateFormat.setTimeZone(zone); harness.check("10/15/2002 2:12:36 PM EDT", dateFormat.format(date)); To me this seems problematic for two reasons: 1) The test depends on the locale of the test environment 2) More generally it depends on exactly matching formatting rules from the DateFormat instance, something I believe is not specified. In other words it is possible that a spec conforming implementation fails the test because it formats dates in a slightly different way. In the attached patch i have replaced the getDateTimeInstance() call with a SimpleDateFormat that should behave consistently in all locales and jvms. Please apply. Since I have a few patches now awaiting review/comments/inclusion/rejection I have collected them in http://resare.com/noa/mauve/patches for easy access. If anyone wants to try them out, apply them in lexical order. /noa -------------- next part -------------- A non-text attachment was scrubbed... Name: 03-mauve-SimpleTimeZone.patch Type: text/x-patch Size: 1392 bytes Desc: not available URL: From clellchezden@worldbreak.com Sat Oct 9 21:56:00 2004 From: clellchezden@worldbreak.com (danilo binkiewicz) Date: Sat, 09 Oct 2004 21:56:00 -0000 Subject: :)) good start for people want to o_rde^'r rx o^n^line Message-ID: <9D472FEC.C305D39@worldbreak.com> we believe you kn'_ow the difference between washington and washington d.c. for you're american.we also could give you professional service cause we kn_,ow the ropes. i purchased generics and brand name ones in this o'nli'ne ph.ar-m'a_cy many times, and saved a lot in each purchase that way! --- susan ne http://k.nightshade3aleutian.com/?zehl=fygf6674&kj&sdfg=0&fl=yeoj with the real good-will of a mind delighted with its own ideas, did she then do all the hon^'ours of the meal, and help and recommend likewise, a most brotherly affection for you, he is so far from -----Original Message----- From: moses tombs [mailto:mauve-discuss@sources.redhat.com] To: danilo binkiewicz; rob eck; refugio nowell; burl gassel; willy odore Sent: Friday, October, 2004 2:45 PM Subject: good start for people want to o-rde,-r rx o-n-line The intimacy between her and Emma must si-n,k; their fr`~ie-ndship must observed that he was perfectly good humoured and fr''ie'ndly. noriegallebute 12 koiranputkia 53 nazardnyttelytila ktisesti the minced chicken and sc_a'll-oped oysters, with an urgency which she From crawley@dstc.edu.au Mon Oct 11 00:50:00 2004 From: crawley@dstc.edu.au (Stephen Crawley) Date: Mon, 11 Oct 2004 00:50:00 -0000 Subject: gnu/testlet/java/nio/channels/FileChannel/manyopen.java broken In-Reply-To: Message from Mark Wielaard of "Fri, 08 Oct 2004 12:05:25 +0200." <1097229925.1087.10.camel@localhost> Message-ID: <200410110049.i9B0nLQQ008866@piglet.dstc.edu.au> Mark Wielaard wrote: > We had a problem with real programs that open lots of files quickly > (gjdoc does this for example, a jar tool or a webserver might be another > good example) and don't explicitly close these files, but let the > file/stream just get garbage collected since the program structure > doesn't explicitly define a "owner" for the file/stream object (which > isn't that uncommon since that is what you normally do with random > allocated objects, long life the garbage collector!). Java programs that rely on the GC to find / close file handles are non-portable and (IMO) broken. A portable program cannot depend on the GC running soon enough to get around a problem with running out of file descriptors. Indeed, it cannot even reliably cause the VM to run the garbage collector, because the VM is allowed to treat a call to java.lang.System.gc() as a "hint" ... and ignore it. [For the record, Kissme is currently implemented to only respect calls to java.lang.System.gc() when it is launched with the "-gc" command line option.] > What I think should be tested is whether a program can open lots of > files. And that the systems notices that stale file handle resources can > be removed so that a program can keep opening files if needed. (As long > as there are no large number of life file handles open at the same > time.) The trouble is that you cannot write a portable / reliable testcase for this. Even if you could, I do not believe that a Java VM should be required to be able to run programs that leak file descriptors like this. > Since I have seen multiple systems get this wrong in various ways I want > to have an explicit test for this situation. It might be that this test > does not simulate a real world program correctly, so if there are > alternatives I would like to hear them instead of just deleting the test > since some systems fail it. I think the solution is to test for behaviour that is not required by the Java 'specification' in a VM-specific test suite ... not in Mauve. -- Steve From jeroen@sumatra.nl Mon Oct 11 06:39:00 2004 From: jeroen@sumatra.nl (Jeroen Frijters) Date: Mon, 11 Oct 2004 06:39:00 -0000 Subject: gnu/testlet/java/nio/channels/FileChannel/manyopen.java broken Message-ID: Stephen Crawley wrote: > Java programs that rely on the GC to find / close file handles are > non-portable and (IMO) broken. A portable program cannot depend on > the GC running soon enough to get around a problem with running > out of file descriptors. While I agree with your general point (and that this test shouldn't be in Mauve), I would like to add a small footnote: The nio memory mapped file API *requires* you to rely on the GC to close the files. Personally, I happen to think that the API is broken because of this, but as of 1.4 (haven't looked at 1.5 yet) this is the sad reality. Regards, Jeroen From jeroen@sumatra.nl Tue Oct 12 09:35:00 2004 From: jeroen@sumatra.nl (Jeroen Frijters) Date: Tue, 12 Oct 2004 09:35:00 -0000 Subject: java.util.Date mess Message-ID: Michael Koch wrote: > On Monday 11 October 2004 15:39, Jeroen Frijters wrote: > > I have some code that depends on unspecified behavior of > > java.util.Date. In the Sun JDK if you pass out of range parameters > > to the Date constructors that take year, month, date, etc. it will > > automatically convert to a valid date (for example, new Date(104, > > 8, 41) is Oct 11, 2004.) > > > > I have a rather lame patch that addresses this (see below), would > > anyone object to this? > > Are there mauve test that confirm that this breaks nothing ? I made a new Mauve test (attached) that works better with my patch (after I fixed one error in my patch and fixed an additional Date bug), but it still fails on three tests. One is due to a bug in GregorianCalendar and I haven't investigated the other two. Is the attached test OK to commit? Do I need to modify any other Mauve files to add the test? Regards, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: range.java Type: application/octet-stream Size: 2052 bytes Desc: range.java URL: From aph@redhat.com Tue Oct 12 09:41:00 2004 From: aph@redhat.com (Andrew Haley) Date: Tue, 12 Oct 2004 09:41:00 -0000 Subject: java.util.Date mess In-Reply-To: References: Message-ID: <16747.42661.267373.605540@cuddles.cambridge.redhat.com> A modest proposal: could those people attaching files please give them a content-type of "text/plain" rather than "application/binary"? They'd still be transmitted faithfully, bus mailers could display them inline. Thanks, Andrew. From konqueror@gmx.de Tue Oct 12 09:41:00 2004 From: konqueror@gmx.de (Michael Koch) Date: Tue, 12 Oct 2004 09:41:00 -0000 Subject: java.util.Date mess In-Reply-To: References: Message-ID: <200410121141.31542.konqueror@gmx.de> On Tuesday 12 October 2004 11:35, Jeroen Frijters wrote: > Michael Koch wrote: > > On Monday 11 October 2004 15:39, Jeroen Frijters wrote: > > > I have some code that depends on unspecified behavior of > > > java.util.Date. In the Sun JDK if you pass out of range > > > parameters to the Date constructors that take year, month, > > > date, etc. it will automatically convert to a valid date (for > > > example, new Date(104, 8, 41) is Oct 11, 2004.) > > > > > > I have a rather lame patch that addresses this (see below), > > > would anyone object to this? > > > > Are there mauve test that confirm that this breaks nothing ? > > I made a new Mauve test (attached) that works better with my patch > (after I fixed one error in my patch and fixed an additional Date > bug), but it still fails on three tests. One is due to a bug in > GregorianCalendar and I haven't investigated the other two. > > Is the attached test OK to commit? Do I need to modify any other > Mauve files to add the test? Just add the file with a proper ChangeLog entry and be done. Thats all you need to do. Thanks for the testcase. Michael From jeroen@sumatra.nl Sun Oct 17 14:04:00 2004 From: jeroen@sumatra.nl (Jeroen Frijters) Date: Sun, 17 Oct 2004 14:04:00 -0000 Subject: Object.clone() out of memory tests Message-ID: Hi, I'd like to move the out of memory test in gnu/testlet/java/lang/object/clone.java to a separate file. The test makes my system unbearably slow (because it pushes all memory to the swap file) so it would be nice to be able to disable to separately. Any objections? Regards, Jeroen From crawley@dstc.edu.au Sun Oct 17 23:26:00 2004 From: crawley@dstc.edu.au (Stephen Crawley) Date: Sun, 17 Oct 2004 23:26:00 -0000 Subject: Object.clone() out of memory tests In-Reply-To: Message from "Jeroen Frijters" of "Sun, 17 Oct 2004 16:04:00 +0200." Message-ID: <200410172325.i9HNPswl028898@piglet.dstc.edu.au> "Jeroen Frijters" wrote: > I'd like to move the out of memory test in > gnu/testlet/java/lang/object/clone.java to a separate file. The test > makes my system unbearably slow (because it pushes all memory to the > swap file) so it would be nice to be able to disable to separately. > > Any objections? None from me. It would be nice if there was a convention of flagging tests that are in some way VM or environment specific so that they could be deselected in a Mauve key file. -- Steve From jeroen@sumatra.nl Tue Oct 19 11:45:00 2004 From: jeroen@sumatra.nl (Jeroen Frijters) Date: Tue, 19 Oct 2004 11:45:00 -0000 Subject: Object.clone() out of memory tests Message-ID: Stephen Crawley wrote: > "Jeroen Frijters" wrote: > > I'd like to move the out of memory test in > > gnu/testlet/java/lang/object/clone.java to a separate file. The test > > makes my system unbearably slow (because it pushes all memory to the > > swap file) so it would be nice to be able to disable to separately. > > > > Any objections? > > None from me. I made the change. > It would be nice if there was a convention of flagging tests > that are in some way VM or environment specific so that they could be > deselected in a Mauve key file. Yeah. On the other hand one could also argue that these tests don't belong in Mauve, but in the VM specific test suites. It turns out that the OutOfMemoryError test that I moved is also a bit dubious, because it tries to predict when the VM will throw an OutOfMemoryError, but the spec says nothing about this, it's perfectly legal for the VM to throw an OutOfMemoryError for a small allocation, but later on allow a larger allocation (e.g. due to environmental effects). Regards, Jeroen From tromey@redhat.com Fri Oct 22 16:56:00 2004 From: tromey@redhat.com (Tom Tromey) Date: Fri, 22 Oct 2004 16:56:00 -0000 Subject: Jacks test suite Message-ID: As discussed on the Jacks list and elsewhere, the Jacks test suite is now included in the Mauve cvs repository in the "jacks" module. Thanks to Chris Abbey, we have all the Jacks history. Future Jacks development will take place in Mauve. For those not in the know, Jacks is an excellent, comprehensive Java compiler test suite. Jacks changes will be discussed on mauve-discuss. If the volume is too large (doubtful at the moment) we can always make a new list later. Chris, the Mauve web pages are in cvs in the "htdocs" module. Commits go live immediately. Feel free to make whatever edits you like to the web pages. At the very least we should post a news item about this, I'll do it later unless someone beats me to it. (Really it would super if someone rewrote the Mauve web pages...) Tom From tromey@redhat.com Fri Oct 22 17:15:00 2004 From: tromey@redhat.com (Tom Tromey) Date: Fri, 22 Oct 2004 17:15:00 -0000 Subject: jacks updates Message-ID: Ok, I've checked in the minor Jacks bug fixes I've collected from the recent past. Mostly just typos, but also an additional test for method overriding (it seems that we could use more here) and a real fix to some test output. I also have a patch to change jacks to use tclsh8.4 -- I made this change locally since FC2 doesn't ship tclsh8.3. If nobody objects I'll make this change in the mauve cvs repository as well. Also, I have some tests (some by me, some posted to the jacks list this year) for 1.5 things: boxing, foreach, and enums. In my repository I have these in tests/non-jls/, but I suppose they probably belong in tests/jls now. Chris, what do you think? Also there's the question of what to do about code that was invalid in 1.4 but is now valid in 1.5. For instance something like Object x = 5; falls into this category due to auto-boxing. We could either modify these tests so that they are always invalid, or we could mark them so that we can continue testing compliance to 1.4 and 1.5. I'm inclined toward the latter offhand. Tom From noa@resare.com Fri Oct 22 19:24:00 2004 From: noa@resare.com (Noa Resare) Date: Fri, 22 Oct 2004 19:24:00 -0000 Subject: [PATCH] BinaryCompatibilty tests fail due to bogus CLASSPATH with kaffe Message-ID: <1098473061.28956.6.camel@c-061f72d5.01-60-6c6b701.cust.bredbandsbolaget.se> Hello When the CLASSPATH environment variable is unset when executing the BinaryCompatibility tests make sets CLASSPATH to just MAUVE_HOME. The BinaryCompatibility testing script 'foo' then executes $JAVA without an explicit -classpath arg which makes tests fail with kaffe. The attached patch adds an explicit -classpath . to the $JAVA args and makes cvs kaffe pass all the BinaryCompatibility tests. Please apply. As usual the patch is also available from http://resare.com/noa/mauve/patches/ along with my other pending patches. /noa From noa@resare.com Fri Oct 22 19:27:00 2004 From: noa@resare.com (Noa Resare) Date: Fri, 22 Oct 2004 19:27:00 -0000 Subject: [PATCH] BinaryCompatibilty tests fail due to bogus CLASSPATH with kaffe In-Reply-To: <1098473061.28956.6.camel@c-061f72d5.01-60-6c6b701.cust.bredbandsbolaget.se> References: <1098473061.28956.6.camel@c-061f72d5.01-60-6c6b701.cust.bredbandsbolaget.se> Message-ID: <1098473255.28956.7.camel@c-061f72d5.01-60-6c6b701.cust.bredbandsbolaget.se> fre 2004-10-22 klockan 21:24 +0200 skrev Noa Resare: > The attached patch adds an explicit -classpath . to the $JAVA args and > makes cvs kaffe pass all the BinaryCompatibility tests. Please apply. forgot to attach. sorry. /noa -------------- next part -------------- A non-text attachment was scrubbed... Name: mauve-binary-compat.patch Type: text/x-patch Size: 1229 bytes Desc: not available URL: From aph@redhat.com Sat Oct 23 10:07:00 2004 From: aph@redhat.com (Andrew Haley) Date: Sat, 23 Oct 2004 10:07:00 -0000 Subject: [PATCH] BinaryCompatibilty tests fail due to bogus CLASSPATH with kaffe In-Reply-To: <1098473061.28956.6.camel@c-061f72d5.01-60-6c6b701.cust.bredbandsbolaget.se> References: <1098473061.28956.6.camel@c-061f72d5.01-60-6c6b701.cust.bredbandsbolaget.se> Message-ID: <16762.11576.697437.596106@cuddles.cambridge.redhat.com> +2004-10-22 Noa Resare + + * gnu/testlet/BinaryCompatibility/foo: + added explicit classpath to $JAVA invocation in test script + OK. Andrew. From jikes@cabbey.net Sun Oct 24 03:44:00 2004 From: jikes@cabbey.net (Chris Abbey) Date: Sun, 24 Oct 2004 03:44:00 -0000 Subject: jacks updates In-Reply-To: Message-ID: Yesterday, Tom Tromey wrote: > I also have a patch to change jacks to use tclsh8.4 -- I made this > change locally since FC2 doesn't ship tclsh8.3. If nobody objects > I'll make this change in the mauve cvs repository as well. I've been keeping a local copy of what I bet is the same patch for ages now... so I certainly have no objection to moving up to something modern. > Also, I have some tests (some by me, some posted to the jacks list > this year) for 1.5 things: boxing, foreach, and enums. In my > repository I have these in tests/non-jls/, but I suppose they probably > belong in tests/jls now. Chris, what do you think? I've never really been good at picking the location for where tests should go in the hierarchy... it's often a subjective issue. Perhaps tests/jcr/NNN/ ? > Also there's the question of what to do about code that was invalid > in 1.4 but is now valid in 1.5. For instance something like ... > we could mark them so > that we can continue testing compliance to 1.4 and 1.5. Personally, I'm inclined to like this idea... it's likely something we should make extensible, so for example a test could be marked as "expect fail on < 1.5, expect pass on >= 1.5" or similar. I think we ended up throwing away some tests that were expecting different behaviour in pre 1.2 than was seen on 1.2 and higher... and I'm sure there are tests that behave differntly on 1.0 than any other version... and we adjusted them with a bias against 1.0. (But 1.0 was a very different transition than 1.5 is... there was very little 1.0 code, everyone was clamouring for 1.1... I expect there will be a lot of Java2 code for a while, the move to Java5 won't be as fast.) -- Never make a technical decision based upon the politics of the situation. Never make a political decision based upon technical issues. The only place these realms meet is in the mind of the unenlightened. -- Geoffrey James, The Zen of Programming From tromey@redhat.com Mon Oct 25 19:35:00 2004 From: tromey@redhat.com (Tom Tromey) Date: Mon, 25 Oct 2004 19:35:00 -0000 Subject: jacks updates In-Reply-To: References: Message-ID: Chris> I've never really been good at picking the location for where Chris> tests should go in the hierarchy... it's often a subjective Chris> issue. Yeah. I looked and there is already tests/non-jls/assert. So how about tests/non-jls/? Chris> Personally, I'm inclined to like this idea... it's likely Chris> something we should make extensible, so for example a test Chris> could be marked as "expect fail on < 1.5, expect pass on >= Chris> 1.5" or similar. Sounds good, let's do it. Tom From csm@gnu.org Tue Oct 26 05:46:00 2004 From: csm@gnu.org (Casey Marshall) Date: Tue, 26 Oct 2004 05:46:00 -0000 Subject: X.509 certificate tests Message-ID: <878y9um3q2.fsf@gnu.org> Hi, I've repackaged the implementation of the PKITS [1] test suite I wrote for the X.509 implementation I have been working on (and, might be putting into Classpath) for Mauve. The test tarball is quite large, as it contains a great many example certificates and CRLs, so I have posted it here instead of to this list: -- Casey Marshall || csm@gnu.org [1] http://csrc.nist.gov/pki/testing/x509paths.html From tromey@redhat.com Tue Oct 26 15:46:00 2004 From: tromey@redhat.com (Tom Tromey) Date: Tue, 26 Oct 2004 15:46:00 -0000 Subject: X.509 certificate tests In-Reply-To: <878y9um3q2.fsf@gnu.org> References: <878y9um3q2.fsf@gnu.org> Message-ID: Casey> I've repackaged the implementation of the PKITS [1] test suite I wrote Casey> for the X.509 implementation I have been working on (and, might be Casey> putting into Classpath) for Mauve. Is this something that would fit into the existing mauve approach? If not we can always make a new module in cvs. Hmm, I see you don't have mauve write access. Let's change that. Tom From csm@gnu.org Tue Oct 26 17:09:00 2004 From: csm@gnu.org (Casey Marshall) Date: Tue, 26 Oct 2004 17:09:00 -0000 Subject: X.509 certificate tests In-Reply-To: (Tom Tromey's message of "26 Oct 2004 09:45:48 -0600") References: <878y9um3q2.fsf@gnu.org> Message-ID: <87mzy9h0ea.fsf@gnu.org> >>>>> "Tom" == Tom Tromey writes: Casey> I've repackaged the implementation of the PKITS [1] test suite Casey> I wrote for the X.509 implementation I have been working on Casey> (and, might be putting into Classpath) for Mauve. Tom> Is this something that would fit into the existing mauve Tom> approach? If not we can always make a new module in cvs. I don't see why not; all of the tests are very simple, and follow the same pattern: parse some certificates, give them to the CertPathValidator, and get a "yes" or "no" answer at the end. The only really problematic part are the certificate data: they are about 2.6M of binary goo. Any problem with including them? -- Casey Marshall || csm@gnu.org From tromey@redhat.com Tue Oct 26 17:20:00 2004 From: tromey@redhat.com (Tom Tromey) Date: Tue, 26 Oct 2004 17:20:00 -0000 Subject: X.509 certificate tests In-Reply-To: <87mzy9h0ea.fsf@gnu.org> References: <878y9um3q2.fsf@gnu.org> <87mzy9h0ea.fsf@gnu.org> Message-ID: Casey> The only really problematic part are the certificate data: they are Casey> about 2.6M of binary goo. Any problem with including them? As long as there are no legal issues I don't see a problem. My copy of mauve seems to be about 14M already, a few more megabytes won't hurt. Tom From csm@gnu.org Tue Oct 26 17:58:00 2004 From: csm@gnu.org (Casey Marshall) Date: Tue, 26 Oct 2004 17:58:00 -0000 Subject: X.509 certificate tests In-Reply-To: (Tom Tromey's message of "26 Oct 2004 11:19:01 -0600") References: <878y9um3q2.fsf@gnu.org> <87mzy9h0ea.fsf@gnu.org> Message-ID: <87fz41gy3q.fsf@gnu.org> >>>>> "Tom" == Tom Tromey writes: Casey> The only really problematic part are the certificate data: they Casey> are about 2.6M of binary goo. Any problem with including them? Tom> As long as there are no legal issues I don't see a problem. My Tom> copy of mauve seems to be about 14M already, a few more megabytes Tom> won't hurt. The test suite was developed by the US government, so it is not subject to copyright. Parts were contracted out by the NSA, but it seems that they have stated that the test files are freely redistributable [1]. -- Casey Marshall || csm@gnu.org [1] http://cio.nist.gov/esd/emaildir/lists/pkits/msg00047.html From mark@klomp.org Tue Oct 26 20:33:00 2004 From: mark@klomp.org (Mark Wielaard) Date: Tue, 26 Oct 2004 20:33:00 -0000 Subject: X.509 certificate tests In-Reply-To: <87fz41gy3q.fsf@gnu.org> References: <878y9um3q2.fsf@gnu.org> <87mzy9h0ea.fsf@gnu.org> <87fz41gy3q.fsf@gnu.org> Message-ID: <1098822778.2556.61.camel@localhost> Hi, On Tue, 2004-10-26 at 19:58, Casey Marshall wrote: > The test suite was developed by the US government, so it is not > subject to copyright. > > Parts were contracted out by the NSA, but it seems that they have > stated that the test files are freely redistributable [1]. Please add the following text from that to the README: The test document and data were jointly developed by NIST and DigitalNet. Any contribution made to this project by NIST is covered by Title 17 Section 105 of the United States Code which states that any work developed by the United State Government is not subject to copyright protection (see http://www4.law.cornell.edu/uscode/17/105.html). So, NIST's contributions to the test documentation and data are in the public domain. While DigitalNet's contributions to the documentation and data may be subject to copyright, all of the work done by DigitalNet on this project was done under contract for NSA. So, it would be up to NSA to decide how DigitalNet's contributions to the project could be used. In response to your query, I asked DigitalNet about the use of the test suite and received the following response: "V51 [of NSA] approved of the public release of the PKITS test data and documents. There are no restrictions regarding their redistribution." when you add this data. Although we are more relaxed about accepting contributions to Mauve than with for example GNU Classpath (for which we require written confirmation by all contributors) we still want to have a record who contributed what when. This can be done in the ChangeLog and the README file though. Even if it wouldn't be a very big disaster if we ever have to remove a test from mauve we should try to prevent ever having to be in such a situation and prevent any unclearity about the origins of any of the tests. Thanks, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tromey@redhat.com Tue Oct 26 23:10:00 2004 From: tromey@redhat.com (Tom Tromey) Date: Tue, 26 Oct 2004 23:10:00 -0000 Subject: virtual machine tests Message-ID: I've been doing some surgery on the VM parts of libgcj, and it occurs to me that there isn't really a comprehensive test suite for this. I think it is time to set one up. My current plan is to make a new Mauve module called "vm", and put tests there. Of the many test frameworks we have at the moment, I find jacks is the easiest to work with (and most appropriate for this kind of testing), so I think I will just copy that framework and use it. Eventually I'd like to move the verifier tests here as well. It will be a little while before I set this up for real. Send email if you have an objection or comment. Tom From robilad@kaffe.org Tue Oct 26 23:32:00 2004 From: robilad@kaffe.org (Dalibor Topic) Date: Tue, 26 Oct 2004 23:32:00 -0000 Subject: virtual machine tests In-Reply-To: References: Message-ID: <417EDE95.4080401@kaffe.org> Tom Tromey wrote: > I've been doing some surgery on the VM parts of libgcj, and it occurs > to me that there isn't really a comprehensive test suite for this. I > think it is time to set one up. > > My current plan is to make a new Mauve module called "vm", and put > tests there. Of the many test frameworks we have at the moment, I > find jacks is the easiest to work with (and most appropriate for this > kind of testing), so I think I will just copy that framework and use > it. Eventually I'd like to move the verifier tests here as well. > > It will be a little while before I set this up for real. Send email > if you have an objection or comment. Sounds cool. I guess we could mirror the JVMS hierarchy in the tests like jacks does for JLS. All I've found last time around when I looked for VM tests was the tests in Jcon [1]. cheers, dalibor topic [1] http://www.cs.arizona.edu/icon/jcon/ From jikes@cabbey.net Wed Oct 27 03:37:00 2004 From: jikes@cabbey.net (Chris Abbey) Date: Wed, 27 Oct 2004 03:37:00 -0000 Subject: virtual machine tests In-Reply-To: Message-ID: Today, Tom Tromey wrote: > My current plan is to make a new Mauve module called "vm", and put > tests there. Of the many test frameworks we have at the moment, I > find jacks is the easiest to work with (and most appropriate for this > kind of testing), so I think I will just copy that framework and use > it. Eventually I'd like to move the verifier tests here as well. There are a handfull of tests in Jacks now that could probably move over to this new section. (look for the jvm constraint for the ones I'm thinking of.) -- Never make a technical decision based upon the politics of the situation. Never make a political decision based upon technical issues. The only place these realms meet is in the mind of the unenlightened. -- Geoffrey James, The Zen of Programming From david.gilbert@object-refinery.com Thu Oct 28 22:10:00 2004 From: david.gilbert@object-refinery.com (David Gilbert) Date: Thu, 28 Oct 2004 22:10:00 -0000 Subject: Mauve reports... Message-ID: <1099001456.10241.14.camel@linux42.overstone> Hi all, I've written a subclass of TestHarness that records the results of a Mauve run, and another class that generates HTML output for the results. You can see sample output from the program here: http://www.object-refinery.com/classpath/mauve-report/latest/ ...and the source code (GPL) is here: http://www.object-refinery.com/classpath/mauve-report/mauve-report.zip I haven't written any documentation yet, but will do so in time as I plan to use this reporting framework for some of my own projects. Regards, Dave Gilbert http://www.jfree.org From konqueror@gmx.de Thu Oct 28 22:41:00 2004 From: konqueror@gmx.de (Michael Koch) Date: Thu, 28 Oct 2004 22:41:00 -0000 Subject: Mauve reports... In-Reply-To: <1099001456.10241.14.camel@linux42.overstone> References: <1099001456.10241.14.camel@linux42.overstone> Message-ID: <200410290041.44986.konqueror@gmx.de> Am Freitag, 29. Oktober 2004 00:10 schrieb David Gilbert: > Hi all, > > I've written a subclass of TestHarness that records the results of > a Mauve run, and another class that generates HTML output for the > results. You can see sample output from the program here: > > http://www.object-refinery.com/classpath/mauve-report/latest/ > > ...and the source code (GPL) is here: > > http://www.object-refinery.com/classpath/mauve-report/mauve-report. >zip > > I haven't written any documentation yet, but will do so in time as > I plan to use this reporting framework for some of my own projects. That is pretty cool. We really need and want this. Very good job. Thanks. Michael -- Homepage: http://www.worldforge.org/ From noa@resare.com Fri Oct 29 06:06:00 2004 From: noa@resare.com (Noa Resare) Date: Fri, 29 Oct 2004 06:06:00 -0000 Subject: Mauve reports... In-Reply-To: <1099001456.10241.14.camel@linux42.overstone> References: <1099001456.10241.14.camel@linux42.overstone> Message-ID: <1099030008.2198.16.camel@c-241f72d5.01-60-6c6b701.cust.bredbandsbolaget.se> tor 2004-10-28 klockan 23:10 +0100 skrev David Gilbert: > Hi all, > > I've written a subclass of TestHarness that records the results of a > Mauve run, and another class that generates HTML output for the > results. You can see sample output from the program here: > > http://www.object-refinery.com/classpath/mauve-report/latest/ > > ...and the source code (GPL) is here: > > http://www.object-refinery.com/classpath/mauve-report/mauve-report.zip > > I haven't written any documentation yet, but will do so in time as I > plan to use this reporting framework for some of my own projects. > Very nice output. Getting rid of SimpleTestHarness by extending TestHarness directly is the right way to go IMHO. It seems however that there is a certain overlap between this effort and my xml output patch that I did a while ago[1]. Have you looked at it? With some minor modifications I think that the xml format can carry all information needed to create your html output. That way we could use the data from one test run both for generating a html report and doing automated test difference reporting with my testdiff[2] tool. I will be offline for about a week now, and then I hope to help getting kaffe-1.1.5 out the door but after that I have planned to turn my attention to mauve and your code fits into some of my plans quite well. Perhaps I whould write a separate message about that. Thanks for making this available /noa [1] http://resare.com/noa/mauve/patches/00-mauve-xmlout3.patch [2] http://resare.com/noa/testdiff/ From noa@resare.com Fri Oct 29 06:41:00 2004 From: noa@resare.com (Noa Resare) Date: Fri, 29 Oct 2004 06:41:00 -0000 Subject: future plans for mauve Message-ID: <1099032100.2198.50.camel@c-241f72d5.01-60-6c6b701.cust.bredbandsbolaget.se> Hello While using mauve for a while now I have felt an urge to put some time into change/fix some things that I think could be done better. This will not happen right now, as I would like to see kaffe-1.1.5 out the door first and I'm going offline for a week tonight but I thought it would be a good idea to share my ideas with the list anyway, especially since David Gilbert seems to be thinking about using a mauve for testing other code than the class library. Note that these are just random thoughts, and I'm really open to suggestions. * The './configure; make tests ARGS' invocation scheme is a little odd. I'd like to have a small script perhaps called 'mauve' that took arguments --java=/path/to/java --javac=/path/to/javac. The rest of the args should be like the KEYS variable. * Changes in mauve-KEYWORD files should trigger a recalculation of which classes should be tested. * The mechanism now implemented in the choose script should be faster and written in a language more suited for the task. java perhaps? * Improved documentation. There should be a 'write a new test guide' of some sort. * Package structure. The part that could be called the 'testlet api' should live in gnu.testlet. The test runner implementation should be in gnu.mauve.runner (?) and test hierarchy perhaps in gnu.mauve.tests. * Improved progress reporting when doing the tests. /noa From konqueror@gmx.de Fri Oct 29 06:42:00 2004 From: konqueror@gmx.de (Michael Koch) Date: Fri, 29 Oct 2004 06:42:00 -0000 Subject: Mauve reports... In-Reply-To: <1099030008.2198.16.camel@c-241f72d5.01-60-6c6b701.cust.bredbandsbolaget.se> References: <1099001456.10241.14.camel@linux42.overstone> <1099030008.2198.16.camel@c-241f72d5.01-60-6c6b701.cust.bredbandsbolaget.se> Message-ID: <200410290842.45195.konqueror@gmx.de> Am Freitag, 29. Oktober 2004 08:06 schrieb Noa Resare: > tor 2004-10-28 klockan 23:10 +0100 skrev David Gilbert: > > Hi all, > > > > I've written a subclass of TestHarness that records the results > > of a Mauve run, and another class that generates HTML output for > > the results. You can see sample output from the program here: > > > > http://www.object-refinery.com/classpath/mauve-report/latest/ > > > > ...and the source code (GPL) is here: > > > > http://www.object-refinery.com/classpath/mauve-report/mauve-repor > >t.zip > > > > I haven't written any documentation yet, but will do so in time > > as I plan to use this reporting framework for some of my own > > projects. > > Very nice output. Getting rid of SimpleTestHarness by extending > TestHarness directly is the right way to go IMHO. > > It seems however that there is a certain overlap between this > effort and my xml output patch that I did a while ago[1]. Have you > looked at it? With some minor modifications I think that the xml > format can carry all information needed to create your html output. > That way we could use the data from one test run both for > generating a html report and doing automated test difference > reporting with my testdiff[2] tool. I wasn't aware of your code until someone told me about it on IRC. XML is more nice of course. We can easily transform it to HTML with XSL stylescheets. I do this already with the checkstyle xml output. I will install this on developer.classpath.org when I'm back from holidays. Your mauve things might be good to have there too. Can you both work together on this mauve stuff ? Michael -- Homepage: http://www.worldforge.org/ From konqueror@gmx.de Fri Oct 29 06:51:00 2004 From: konqueror@gmx.de (Michael Koch) Date: Fri, 29 Oct 2004 06:51:00 -0000 Subject: future plans for mauve In-Reply-To: <1099032100.2198.50.camel@c-241f72d5.01-60-6c6b701.cust.bredbandsbolaget.se> References: <1099032100.2198.50.camel@c-241f72d5.01-60-6c6b701.cust.bredbandsbolaget.se> Message-ID: <200410290851.50695.konqueror@gmx.de> Am Freitag, 29. Oktober 2004 08:41 schrieb Noa Resare: > Hello > > While using mauve for a while now I have felt an urge to put some > time into change/fix some things that I think could be done better. > This will not happen right now, as I would like to see kaffe-1.1.5 > out the door first and I'm going offline for a week tonight but I > thought it would be a good idea to share my ideas with the list > anyway, especially since David Gilbert seems to be thinking about > using a mauve for testing other code than the class library. > > Note that these are just random thoughts, and I'm really open to > suggestions. > > > * The './configure; make tests ARGS' invocation scheme is a little > odd. I'd like to have a small script perhaps called 'mauve' that > took arguments --java=/path/to/java --javac=/path/to/javac. The > rest of the args should be like the KEYS variable. I like to use the ./batch_run. I just ./configure mauve without arguments once. Then I can set COMPILER and RUNTIME accordingly to my test I wanna do and run ./batch_run. Thats much more easy then re-reconfiguring each time. > * Package structure. The part that could be called the 'testlet > api' should live in gnu.testlet. The test runner implementation > should be in gnu.mauve.runner (?) and test hierarchy perhaps in > gnu.mauve.tests. Mauving things around in CVS is a bad idea as the history of changes for the moved files get lost. I often look into such informations. Michael -- Homepage: http://www.worldforge.org/ From konqueror@gmx.de Fri Oct 29 10:59:00 2004 From: konqueror@gmx.de (Michael Koch) Date: Fri, 29 Oct 2004 10:59:00 -0000 Subject: future plans for mauve In-Reply-To: <41822114.1020602@gmx.net> References: <1099032100.2198.50.camel@c-241f72d5.01-60-6c6b701.cust.bredbandsbolaget.se> <200410290851.50695.konqueror@gmx.de> <41822114.1020602@gmx.net> Message-ID: <200410291259.48230.konqueror@gmx.de> Am Freitag, 29. Oktober 2004 12:53 schrieb Robert Schuster: > Hi > > >>* Package structure. The part that could be called the 'testlet > >>api' should live in gnu.testlet. The test runner implementation > >>should be in gnu.mauve.runner (?) and test hierarchy perhaps in > >>gnu.mauve.tests. > > > >Mauving things around in CVS is a bad idea as the history of > > changes for the moved files get lost. I often look into such > > informations. > > Maybe this was an implicit wish to switch to SVN? > They have a nice CVS2SVN conversion tool at tigris.org, too: > http://cvs2svn.tigris.org/ I would like monotone more [1]. It can import CVS history too and is much more capable of distributed development and has better merging support. Perhaps someone does a drive while I'm in holiday ... Michael [1] http://www.venge.net/monotone/ -- Homepage: http://www.worldforge.org/ From jikes@cabbey.net Thu Nov 4 05:04:00 2004 From: jikes@cabbey.net (Chris Abbey) Date: Thu, 04 Nov 2004 05:04:00 -0000 Subject: jacks mailing list archives, bugs, patches, etc Message-ID: Can anyone think of any good use for the mailing list archive from the old jacks list, or the small number of bugs and the one patch that are outstanding on the dw server? The mailing list was shutdown today, and I have the mbox archive here if we can think of anything usefull to do with it. The bugs and patches will be around a bit longer, but not forever, as the project on dw will eventually be deactivated. The vast majority of the bugs are from Neil Gafter, there's one from me as well that is likely a bug in the upstream tcltest framework. The one patch out there is a testcase for import that needs to find a home in the suite, if there isn't already a test of the same thing and if the test even seems legit to folks. -- Never make a technical decision based upon the politics of the situation. Never make a political decision based upon technical issues. The only place these realms meet is in the mind of the unenlightened. -- Geoffrey James, The Zen of Programming From noa@resare.com Sat Nov 6 09:39:00 2004 From: noa@resare.com (Noa Resare) Date: Sat, 06 Nov 2004 09:39:00 -0000 Subject: Calendar.roll assumes default locale == Locale.US Message-ID: <1099733990.30634.107.camel@c-241f72d5.01-60-6c6b701.cust.bredbandsbolaget.se> The gnu/testlet/java/util/Calendar/roll.java test contains a simple date format with weekday ('EEE') as part of the format. The test then assumes that the weekday will be equal to the weekday in the US locale. I have applied a patch that explicitly sets the locale of the SimpleDateFormat to Locale.US to avoid failures when a different system locale is used. /noa -- nuclear cia fbi spy password code president bomb F3C4 AC90 B885 FE15 344B 4D05 220B 7662 A190 6F09 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Detta ?r en digitalt signerad meddelandedel URL: From david.gilbert@object-refinery.com Thu Nov 11 23:53:00 2004 From: david.gilbert@object-refinery.com (David Gilbert) Date: Thu, 11 Nov 2004 23:53:00 -0000 Subject: Mauve results... Message-ID: <1100217231.5072.11.camel@linux42.overstone> I ran (most of) the Mauve tests tonight (using JamVM 1.2 and the latest CVS version of Classpath) and posted the results here for anyone that is interested: http://www.object-refinery.com/classpath/mauve-report/latest/ The above reports exclude about 10 test files that won't run for me yet - I'll look into those when I get a chance. Regards, Dave Gilbert. From mark@klomp.org Fri Nov 12 00:01:00 2004 From: mark@klomp.org (Mark Wielaard) Date: Fri, 12 Nov 2004 00:01:00 -0000 Subject: Mauve results... In-Reply-To: <1100217231.5072.11.camel@linux42.overstone> References: <1100217231.5072.11.camel@linux42.overstone> Message-ID: <1100217694.8141.89.camel@localhost.localdomain> Hi David, On Fri, 2004-11-12 at 00:53, David Gilbert wrote: > I ran (most of) the Mauve tests tonight (using JamVM 1.2 and the latest > CVS version of Classpath) and posted the results here for anyone that is > interested: > > http://www.object-refinery.com/classpath/mauve-report/latest/ > > The above reports exclude about 10 test files that won't run for me yet > - I'll look into those when I get a chance. Thanks! Can you post that list of files? Maybe someone immediately knows what is wrong with those. Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From david.gilbert@object-refinery.com Fri Nov 12 11:15:00 2004 From: david.gilbert@object-refinery.com (David Gilbert) Date: Fri, 12 Nov 2004 11:15:00 -0000 Subject: Mauve results... In-Reply-To: <1100217694.8141.89.camel@localhost.localdomain> References: <1100217231.5072.11.camel@linux42.overstone> <1100217694.8141.89.camel@localhost.localdomain> Message-ID: <1100258111.4450.13.camel@linux42.overstone> On Fri, 2004-11-12 at 00:01, Mark Wielaard wrote: > Hi David, > > On Fri, 2004-11-12 at 00:53, David Gilbert wrote: > > I ran (most of) the Mauve tests tonight (using JamVM 1.2 and the latest > > CVS version of Classpath) and posted the results here for anyone that is > > interested: > > > > http://www.object-refinery.com/classpath/mauve-report/latest/ > > > > The above reports exclude about 10 test files that won't run for me yet > > - I'll look into those when I get a chance. > > Thanks! > Can you post that list of files? > Maybe someone immediately knows what is wrong with those. The tests I excluded were: gnu.testlet.java.awt.image.PixelGrabber.SimpleGrabber gnu.testlet.java.net.DatagramSocket.DatagramSocketTest2 gnu.testlet.java.net.DatagramSocket.DatagramSocketTest gnu.testlet.java.lang.Character.unicode gnu.testlet.java.text.DateFormatSymbols.Test gnu.testlet.java.util.logging.SocketHandler.getFormatter gnu.testlet.java.util.logging.SocketHandler.publish gnu.testlet.java.util.logging.SocketHandler.getFilter gnu.testlet.java.beans.XMLDecoder.jdk14 gnu.testlet.javax.swing.undo.AbstractUndoableEdit.getUndoPresentationName gnu.testlet.javax.swing.undo.AbstractUndoableEdit.getRedoPresentationName gnu.testlet.javax.swing.undo.AbstractUndoableEdit.getPresentationName gnu.testlet.javax.swing.undo.UndoManager.getUndoPresentationName gnu.testlet.javax.swing.undo.UndoManager.getRedoPresentationName gnu.testlet.javax.swing.undo.UndoManager.getUndoOrRedoPresentationName gnu.testlet.javax.swing.JLabel.Icon gnu.testlet.javax.swing.JLabel.Mnemonic I didn't have any time to look into the problems, I would guess that some of the latter tests fail because I compiled Classpath with --disable-gtk-peer (the machine that I run this on has SuSE 9.1 on it, therefore an old-ish version of Gnome, and for a bunch of reasons I don't want to mess around with updating the machine right now). And some failures may be due to bugs in the custom test harness that I run the tests with. It will probably be January before I'll get a chance to put a lot more time into this - but I hope the reports I posted are useful to give developers a quick overview of how the test failures are distributed. Regards, Dave > Cheers, > > Mark From mckinlay@redhat.com Fri Nov 12 17:20:00 2004 From: mckinlay@redhat.com (Bryce McKinlay) Date: Fri, 12 Nov 2004 17:20:00 -0000 Subject: Mauve results... In-Reply-To: <1100217231.5072.11.camel@linux42.overstone> References: <1100217231.5072.11.camel@linux42.overstone> Message-ID: <4194F0C8.3040506@redhat.com> Hey David, Very nice. What did you use to format the results? Regards Bryce David Gilbert wrote: >I ran (most of) the Mauve tests tonight (using JamVM 1.2 and the latest >CVS version of Classpath) and posted the results here for anyone that is >interested: > >http://www.object-refinery.com/classpath/mauve-report/latest/ > >The above reports exclude about 10 test files that won't run for me yet >- I'll look into those when I get a chance. > >Regards, > >Dave Gilbert. > > From david.gilbert@object-refinery.com Fri Nov 12 17:32:00 2004 From: david.gilbert@object-refinery.com (David Gilbert) Date: Fri, 12 Nov 2004 17:32:00 -0000 Subject: Mauve results... In-Reply-To: <4194F0C8.3040506@redhat.com> References: <1100217231.5072.11.camel@linux42.overstone> <4194F0C8.3040506@redhat.com> Message-ID: <1100280762.9185.10.camel@linux42.overstone> I wrote a custom subclass of TestHarness, the source code is here if you or anyone wants to look at it: http://www.object-refinery.com/classpath/mauve-report/mauve-report.zip I'm short on time this month and next, but in January I will try to write some documentation about how to generate the test reports, and tidy up the rough edges in the code. Regards, Dave Gilbert On Fri, 2004-11-12 at 17:20, Bryce McKinlay wrote: > Hey David, > > Very nice. What did you use to format the results? > > Regards > > Bryce > > > David Gilbert wrote: > > >I ran (most of) the Mauve tests tonight (using JamVM 1.2 and the latest > >CVS version of Classpath) and posted the results here for anyone that is > >interested: > > > >http://www.object-refinery.com/classpath/mauve-report/latest/ > > > >The above reports exclude about 10 test files that won't run for me yet > >- I'll look into those when I get a chance. > > > >Regards, > > > >Dave Gilbert. > > > > > > From david.gilbert@object-refinery.com Fri Nov 19 22:37:00 2004 From: david.gilbert@object-refinery.com (David Gilbert) Date: Fri, 19 Nov 2004 22:37:00 -0000 Subject: StatCVS reports... Message-ID: <419E77A5.5000406@object-refinery.com> I've posted a couple of StatCVS[1] reports that show the great progress being made with Classpath: http://www.object-refinery.com/classpath/statcvs-20041119/ ...and Mauve: http://www.object-refinery.com/classpath/mauve/statcvs-20041119/ Keep up the good work, Dave Gilbert www.jfree.org [1] http://statcvs.sourceforge.net/ From jeroen@sumatra.nl Wed Nov 24 15:28:00 2004 From: jeroen@sumatra.nl (Jeroen Frijters) Date: Wed, 24 Nov 2004 15:28:00 -0000 Subject: gnu/testlet/java/util/zip/GZIPInputStream/reference.data Message-ID: Hi, I removed gnu/testlet/java/util/zip/GZIPInputStream/reference.data from cvs and added it again as a binary file, previously it was a text file and that caused the Windows cvs client to convert the LF to CR/LF and that caused the test to fail. Regards, Jeroen From jeroen@sumatra.nl Wed Nov 24 16:02:00 2004 From: jeroen@sumatra.nl (Jeroen Frijters) Date: Wed, 24 Nov 2004 16:02:00 -0000 Subject: gnu/testlet/java/io/Utf8Encoding/utf8test.data Message-ID: Hi, I tried to remove utf8test.data and add it again as a binary file, but I somehow managed to get cvs confused. It thinks the file already exists. Tom can you fix this? For the time being I checked in the file as utf8test.bin and modified the test to read that instead. Regards, Jeroen From jeroen@sumatra.nl Wed Nov 24 16:08:00 2004 From: jeroen@sumatra.nl (Jeroen Frijters) Date: Wed, 24 Nov 2004 16:08:00 -0000 Subject: gnu/testlet/java/io/ObjectInputOutput/Test$NoCallDefault.data Message-ID: Hi, Removed and added again as binary. Regards, Jeroen From konqueror@gmx.de Wed Nov 24 16:16:00 2004 From: konqueror@gmx.de (Michael Koch) Date: Wed, 24 Nov 2004 16:16:00 -0000 Subject: gnu/testlet/java/io/Utf8Encoding/utf8test.data In-Reply-To: References: Message-ID: <200411241817.59483.konqueror@gmx.de> Am Mittwoch, 24. November 2004 17:01 schrieb Jeroen Frijters: > Hi, > > I tried to remove utf8test.data and add it again as a binary file, but I > somehow managed to get cvs confused. It thinks the file already exists. > Tom can you fix this? > > For the time being I checked in the file as utf8test.bin and modified > the test to read that instead. I would say: leave it as it is now. utf8test.bin is okay too. Michael -- Homepage: http://www.worldforge.org/ From tromey@redhat.com Wed Nov 24 18:22:00 2004 From: tromey@redhat.com (Tom Tromey) Date: Wed, 24 Nov 2004 18:22:00 -0000 Subject: gnu/testlet/java/util/zip/GZIPInputStream/reference.data In-Reply-To: References: Message-ID: >>>>> "Jeroen" == Jeroen Frijters writes: Jeroen> I removed gnu/testlet/java/util/zip/GZIPInputStream/reference.data from Jeroen> cvs and added it again as a binary file, previously it was a text file Jeroen> and that caused the Windows cvs client to convert the LF to CR/LF and Jeroen> that caused the test to fail. You should be able to "cvs admin -kb" in cases like this. It might require folks to check out from scratch, I forget. Thanks for doing this. Tom From jeroen@sumatra.nl Fri Nov 26 14:09:00 2004 From: jeroen@sumatra.nl (Jeroen Frijters) Date: Fri, 26 Nov 2004 14:09:00 -0000 Subject: PhantomReference Message-ID: Hi, Like (almost) all GC related tests, the PhantomReference test is dubious, but I'd to propose the attached changes anyway, which I think (hope?) will make it more robust on all VMs. The prints are there to keep the references alive, not really nice to use print for this, but I couldn't think of any other way that was both simple and reliable. Any comments? Regards, Jeroen -------------- next part -------------- A non-text attachment was scrubbed... Name: phantom.patch Type: application/octet-stream Size: 1392 bytes Desc: phantom.patch URL: From livelyram@yahoo.com Thu Dec 2 12:40:00 2004 From: livelyram@yahoo.com (ram krishna) Date: Thu, 02 Dec 2004 12:40:00 -0000 Subject: question Message-ID: <20041202124013.22226.qmail@web14101.mail.yahoo.com> examples of timeseries chart and gantt chart using jfreechart package. __________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail From konqueror@gmx.de Thu Dec 2 12:52:00 2004 From: konqueror@gmx.de (Michael Koch) Date: Thu, 02 Dec 2004 12:52:00 -0000 Subject: question In-Reply-To: <20041202124013.22226.qmail@web14101.mail.yahoo.com> References: <20041202124013.22226.qmail@web14101.mail.yahoo.com> Message-ID: <200412021352.36604.konqueror@gmx.de> Am Donnerstag, 2. Dezember 2004 13:40 schrieb ram krishna: > examples of timeseries chart and gantt chart using > jfreechart package. What do you wanna tell us with this ? Michael -- Homepage: http://www.worldforge.org/ From shiningliao@hotmail.com Tue Dec 7 16:40:00 2004 From: shiningliao@hotmail.com (Shining Liao) Date: Tue, 07 Dec 2004 16:40:00 -0000 Subject: Mauve test case changes Message-ID: Hi, I have downloaded mauve nightly build on 20041117 and 20041207. It look to me that there are lots of differences in between. For example, All gnu.testlet.java.lang.* gnu.testlet.java.math.* gnu.testlet.java.net.* gnu.testlet.java.security.* ... etc. test classes are missing! Where can I get more information about how mauve test cases changed and what direction are they going to.... Thanks. Shining Liao From konqueror@gmx.de Tue Dec 7 16:57:00 2004 From: konqueror@gmx.de (Michael Koch) Date: Tue, 07 Dec 2004 16:57:00 -0000 Subject: Mauve test case changes In-Reply-To: References: Message-ID: <200412071750.31395.konqueror@gmx.de> Am Dienstag, 7. Dezember 2004 17:39 schrieb Shining Liao: > Hi, > I have downloaded mauve nightly build on 20041117 and 20041207. > It look to me that there are lots of differences in between. For > example, All gnu.testlet.java.lang.* > gnu.testlet.java.math.* > gnu.testlet.java.net.* > gnu.testlet.java.security.* > ... etc. > test classes are missing! > > Where can I get more information about how mauve test cases changed > and what direction > are they going to.... I don't know about the tarballs but the best is to use CVS directly: http://sources.redhat.com/mauve/cvs.html With CVS you can get diffs between versions and when it was commited and all such infos. Michael -- Homepage: http://www.worldforge.org/ From shiningliao@hotmail.com Mon Dec 20 16:36:00 2004 From: shiningliao@hotmail.com (Shining Liao) Date: Mon, 20 Dec 2004 16:36:00 -0000 Subject: Mauve CVS server broken Message-ID: Hi, I am trying to download mauve. Unfortunately, there is something wrong on mauve CVS server. Anyone know where can I send an email to tell mauve project owner or whoever can fix it? I've tried to download nightly build (zip file), use Eclipse to download and use TortoseCVS. All of them are broken. There are lots of files are missing. The error message when using TortoseCVS is: cvs [checkout aborted]: unable to reopen `/cvs/mauve/mauve/gnu/testlet/java/io/Utf8Encoding/Attic/utf8test.data,v' Regards, Shining Liao From konqueror@gmx.de Tue Dec 21 06:44:00 2004 From: konqueror@gmx.de (Michael Koch) Date: Tue, 21 Dec 2004 06:44:00 -0000 Subject: Mauve CVS server broken In-Reply-To: References: Message-ID: <200412210745.09566.konqueror@gmx.de> Am Montag, 20. Dezember 2004 17:35 schrieb Shining Liao: > Hi, > I am trying to download mauve. Unfortunately, there is something > wrong on mauve CVS server. > Anyone know where can I send an email to tell mauve project owner > or whoever can fix it? > > I've tried to download nightly build (zip file), use Eclipse to > download and use TortoseCVS. All of > them are broken. There are lots of files are missing. > > The error message when using TortoseCVS is: > > cvs [checkout aborted]: unable to reopen > `/cvs/mauve/mauve/gnu/testlet/java/io/Utf8Encoding/Attic/utf8test.d >ata,v' I have no problem accessing mauve CVS here from my Linux clients. I duess you use some Windows versions. I read some time ago that TortoiseCVS has problems with some versions of CVS servers but its a TortoiseCVS bug. What error message(s) do you get with the nightly builds ? Michael -- Homepage: http://www.worldforge.org/ From jeroen@sumatra.nl Tue Dec 21 07:03:00 2004 From: jeroen@sumatra.nl (Jeroen Frijters) Date: Tue, 21 Dec 2004 07:03:00 -0000 Subject: Mauve CVS server broken Message-ID: Michael Koch wrote: > Am Montag, 20. Dezember 2004 17:35 schrieb Shining Liao: > > cvs [checkout aborted]: unable to reopen > > `/cvs/mauve/mauve/gnu/testlet/java/io/Utf8Encoding/Attic/utf8test.d > >ata,v' I caused this problem (with TortoiseCVS as well), it may very well be TortoiseCVS bug that it chokes on this, but I suspect there is something funny with the underlying cvs file as well (also caused by TortoiseCVS (and by me)). Regards, Jeroen From shiningliao@hotmail.com Tue Dec 21 10:49:00 2004 From: shiningliao@hotmail.com (Shining Liao) Date: Tue, 21 Dec 2004 10:49:00 -0000 Subject: Mauve CVS server broken In-Reply-To: <200412210745.09566.konqueror@gmx.de> Message-ID: Hi, Thank you very much for the prompt reply. 1). Yes, I am using the Windows version. I've just tried again with CVS command line on Linux, unfortunately, the error message are the same. 2). There is no error message in nightly build. Just the zip file doesn't contains all the files. I got 2 version of nightly build here: mauve-20041114.zip 1,723KB mauve-20041207.zip 773KB All the files in gnu.testlet.java.lang.* gnu.testlet.java.math.* gnu.testlet.java.net.* gnu.testlet.java.security.* ... etc. directories are missing. The missing files are exactly the same among Using TortoiseCVS Windows Using Eclipse on Windows Using CVS command line on Linux Therefore, I think it must be something wrong between 20041114 and 20041207 PS: I just tried again to download latest (20041221) night build zip file, the file size is 782KB and lots of missing files as well. Shining >Am Montag, 20. Dezember 2004 17:35 schrieb Shining Liao: > > Hi, > > I am trying to download mauve. Unfortunately, there is something > > wrong on mauve CVS server. > > Anyone know where can I send an email to tell mauve project owner > > or whoever can fix it? > > > > I've tried to download nightly build (zip file), use Eclipse to > > download and use TortoseCVS. All of > > them are broken. There are lots of files are missing. > > > > The error message when using TortoseCVS is: > > > > cvs [checkout aborted]: unable to reopen > > `/cvs/mauve/mauve/gnu/testlet/java/io/Utf8Encoding/Attic/utf8test.d > >ata,v' > >I have no problem accessing mauve CVS here from my Linux clients. I >duess you use some Windows versions. I read some time ago that >TortoiseCVS has problems with some versions of CVS servers but its a >TortoiseCVS bug. > >What error message(s) do you get with the nightly builds ? > > >Michael >-- >Homepage: http://www.worldforge.org/ From archie@dellroad.org Tue Dec 28 15:15:00 2004 From: archie@dellroad.org (Archie Cobbs) Date: Tue, 28 Dec 2004 15:15:00 -0000 Subject: CVS commit access? Message-ID: <41D1751C.4030809@dellroad.org> Folks may still be out of town for the holidays, so apologies if this is redundant. I didn't get a final response to this email: http://sources.redhat.com/ml/mauve-patches/2004/msg00124.html In particular, what do I need to do to get CVS commit access? Thanks, -Archie __________________________________________________________________________ Archie Cobbs * CTO, Awarix * http://www.awarix.com From konqueror@gmx.de Tue Dec 28 16:26:00 2004 From: konqueror@gmx.de (Michael Koch) Date: Tue, 28 Dec 2004 16:26:00 -0000 Subject: CVS commit access? In-Reply-To: <41D1751C.4030809@dellroad.org> References: <41D1751C.4030809@dellroad.org> Message-ID: <200412281726.28852.konqueror@gmx.de> Am Dienstag, 28. Dezember 2004 16:00 schrieb Archie Cobbs: > Folks may still be out of town for the holidays, so apologies if > this is redundant. I didn't get a final response to this email: > > http://sources.redhat.com/ml/mauve-patches/2004/msg00124.html > > In particular, what do I need to do to get CVS commit access? Contact Tom Tromey (done by CC'ing him). Michael -- Homepage: http://www.worldforge.org/ From zander@kde.org Thu Dec 30 12:07:00 2004 From: zander@kde.org (Thomas Zander) Date: Thu, 30 Dec 2004 12:07:00 -0000 Subject: locales test has non ascii chars.. Message-ID: <200412301307.07714.zander@kde.org> Hi, I'm having trouble getting the localeTest class to compile correctly since it has non-ascii chars. And lots of them :} I suggest to filter the java file and replace the non ascii values with their \u00xx values instead. See the attached patch and the class to generate this change. I'm worried about the code on lines 410-414 which contains lots of non-standard chars. Maybe a typo? Anyway; can you pick this up? Or can I commit? -- Thomas Zander -------------- next part -------------- A non-text attachment was scrubbed... Name: Convert.java Type: text/x-java Size: 1516 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: locales_charset.diff Type: text/x-diff Size: 7388 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From konqueror@gmx.de Thu Dec 30 12:17:00 2004 From: konqueror@gmx.de (Michael Koch) Date: Thu, 30 Dec 2004 12:17:00 -0000 Subject: locales test has non ascii chars.. In-Reply-To: <200412301307.07714.zander@kde.org> References: <200412301307.07714.zander@kde.org> Message-ID: <200412301318.46789.konqueror@gmx.de> Am Donnerstag, 30. Dezember 2004 13:07 schrieb Thomas Zander: > Hi, > > I'm having trouble getting the localeTest class to compile > correctly since it has non-ascii chars. And lots of them :} Well, mostly german umlauts. What do you expect from me ? ;-) > I suggest to filter the java file and replace the non ascii values > with their \u00xx values instead. > > See the attached patch and the class to generate this change. I'm > worried about the code on lines 410-414 which contains lots of > non-standard chars. Maybe a typo? No, this is no typo, just a workaround. > Anyway; can you pick this up? Or can I commit? Please commit. Thanks for testing. I think we need to fix some of the testcases. JDK seem to return wrong values. Or at least different ones than CLDR expects. Michael -- Homepage: http://www.worldforge.org/ From zander@kde.org Thu Dec 30 13:23:00 2004 From: zander@kde.org (Thomas Zander) Date: Thu, 30 Dec 2004 13:23:00 -0000 Subject: locales test has non ascii chars.. In-Reply-To: <200412301318.46789.konqueror@gmx.de> References: <200412301307.07714.zander@kde.org> <200412301318.46789.konqueror@gmx.de> Message-ID: <200412301423.10539.zander@kde.org> On Thursday 30 December 2004 13:18, you wrote: > Please commit. Thanks for testing. Done. > I think we need to fix some of the testcases. JDK seem to return wrong > values. Or at least different ones than CLDR expects. Attached is a nice output from the (fixed) mauve-report sources from David Gilbert. This is run on the SunsJDK 1.5 Hope that helps. -- Thomas Zander -------------- next part -------------- A non-text attachment was scrubbed... Name: LocaleTest.html.gz Type: application/x-gzip Size: 2827 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From konqueror@gmx.de Thu Dec 30 13:52:00 2004 From: konqueror@gmx.de (Michael Koch) Date: Thu, 30 Dec 2004 13:52:00 -0000 Subject: locales test has non ascii chars.. In-Reply-To: <200412301423.10539.zander@kde.org> References: <200412301307.07714.zander@kde.org> <200412301318.46789.konqueror@gmx.de> <200412301423.10539.zander@kde.org> Message-ID: <200412301453.37217.konqueror@gmx.de> Am Donnerstag, 30. Dezember 2004 14:23 schrieb Thomas Zander: > On Thursday 30 December 2004 13:18, you wrote: > > Please commit. Thanks for testing. > > Done. > > > I think we need to fix some of the testcases. JDK seem to return > > wrong values. Or at least different ones than CLDR expects. > > Attached is a nice output from the (fixed) mauve-report sources > from David Gilbert. > This is run on the SunsJDK 1.5 Can you write a patch to LocaleTest.java that would fix all FAILs for 1.5 and send it to me personally ? I know some stuff is wrong in JDK. I just wanna see what is wrong in our testcase. Michael -- Homepage: http://www.worldforge.org/ From zander@kde.org Thu Dec 30 14:17:00 2004 From: zander@kde.org (Thomas Zander) Date: Thu, 30 Dec 2004 14:17:00 -0000 Subject: locales test has non ascii chars.. In-Reply-To: <200412301453.37217.konqueror@gmx.de> References: <200412301307.07714.zander@kde.org> <200412301423.10539.zander@kde.org> <200412301453.37217.konqueror@gmx.de> Message-ID: <200412301517.20476.zander@kde.org> On Thursday 30 December 2004 14:53, Michael Koch wrote: > Am Donnerstag, 30. Dezember 2004 14:23 schrieb Thomas Zander: > > > I think we need to fix some of the testcases. JDK seem to return > > > wrong values. Or at least different ones than CLDR expects. > > > > Attached is a nice output from the (fixed) mauve-report sources > > from David Gilbert. > > This is run on the SunsJDK 1.5 > > Can you write a patch to LocaleTest.java that would fix all FAILs for > 1.5 and send it to me personally ? I know some stuff is wrong in JDK. > I just wanna see what is wrong in our testcase. Hmm, ok. Maybe I'll get to that next week. The html file I send with my last email allows anyone to do it, though. So you don't have to wait for me. -- Thomas Zander -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From konqueror@gmx.de Thu Dec 30 14:36:00 2004 From: konqueror@gmx.de (Michael Koch) Date: Thu, 30 Dec 2004 14:36:00 -0000 Subject: locales test has non ascii chars.. In-Reply-To: <200412301517.20476.zander@kde.org> References: <200412301307.07714.zander@kde.org> <200412301453.37217.konqueror@gmx.de> <200412301517.20476.zander@kde.org> Message-ID: <200412301537.50945.konqueror@gmx.de> Am Donnerstag, 30. Dezember 2004 15:17 schrieb Thomas Zander: > On Thursday 30 December 2004 14:53, Michael Koch wrote: > > Am Donnerstag, 30. Dezember 2004 14:23 schrieb Thomas Zander: > > > > I think we need to fix some of the testcases. JDK seem to > > > > return wrong values. Or at least different ones than CLDR > > > > expects. > > > > > > Attached is a nice output from the (fixed) mauve-report sources > > > from David Gilbert. > > > This is run on the SunsJDK 1.5 > > > > Can you write a patch to LocaleTest.java that would fix all FAILs > > for 1.5 and send it to me personally ? I know some stuff is wrong > > in JDK. I just wanna see what is wrong in our testcase. > > Hmm, ok. Maybe I'll get to that next week. > The html file I send with my last email allows anyone to do it, > though. So you don't have to wait for me. I'm not sure but I think the table in the html file is wrong. AFAIK the expected and got columns are exchanged. Michael -- Homepage: http://www.worldforge.org/ From fitzsim@redhat.com Thu Dec 30 20:34:00 2004 From: fitzsim@redhat.com (Thomas Fitzsimmons) Date: Thu, 30 Dec 2004 20:34:00 -0000 Subject: java.awt.Robot tests -- visual mauve tests revisited Message-ID: <1104438851.3365.29.camel@rh-ibm-t41> Hi, I've attached a series of tests for java.awt.Robot. I wrote a Robot implementation for GNU Classpath, so we can now start adding interactive GUI tests such as these to Mauve. I'm wondering how best to do this. There was a thread about this recently but I don't think we came to a decision. I know how I'd like GUI testing to work within libgcj's dejagnu harness, but I'm not sure how it should work in batch_run. Thoughts? Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: constructors.java Type: text/x-java Size: 1492 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: createScreenCapture.java Type: text/x-java Size: 2152 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: getPixelColor.java Type: text/x-java Size: 1889 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: keyPress.java Type: text/x-java Size: 2364 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: keyRelease.java Type: text/x-java Size: 2224 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: mouseMove.java Type: text/x-java Size: 2107 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: mousePress.java Type: text/x-java Size: 2038 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: mouseRelease.java Type: text/x-java Size: 2050 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: mouseWheel.java Type: text/x-java Size: 2354 bytes Desc: not available URL: From zander@kde.org Fri Dec 31 08:59:00 2004 From: zander@kde.org (Thomas Zander) Date: Fri, 31 Dec 2004 08:59:00 -0000 Subject: java.awt.Robot tests -- visual mauve tests revisited In-Reply-To: <1104438851.3365.29.camel@rh-ibm-t41> References: <1104438851.3365.29.camel@rh-ibm-t41> Message-ID: <200412310959.31909.zander@kde.org> On Thursday 30 December 2004 21:34, Thomas Fitzsimmons wrote: > There was a thread about this recently but I don't think we came to a > decision. The discussion was continued on IRC (#classpath), and here is what I remember. We wanted to add at least 2 features to the mauve test-runner. a) a keyword for all tests that need a DISPLAY b) a way to 'redirect' graphics output away from the users screen. There is a standard technology for that, I don't remember its name. A virtual buffer. With that in place you have to either explicitly enable GUI tests; or they would automatically detect and use the virtual framebuffer. With Robot a screenCapture can be made and then we need a 'simple' framework to have various visual check() methods on Image objects. Things like 'exact match' / 'tint match' / 'size match' should prove quite usefull. -- Thomas Zander -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From zander@kde.org Fri Dec 31 09:39:00 2004 From: zander@kde.org (Thomas Zander) Date: Fri, 31 Dec 2004 09:39:00 -0000 Subject: locales test has non ascii chars.. In-Reply-To: <200412301537.50945.konqueror@gmx.de> References: <200412301307.07714.zander@kde.org> <200412301517.20476.zander@kde.org> <200412301537.50945.konqueror@gmx.de> Message-ID: <200412311039.11243.zander@kde.org> On Thursday 30 December 2004 15:37, Michael Koch wrote: > I'm not sure but I think the table in the html file is wrong. AFAIK > the expected and got columns are exchanged. You are right; the runner indeed 'printed' this incorrectly; bug was due to a classic example of putting code in the wrong place ;) See new attachment. -- Thomas Zander -------------- next part -------------- A non-text attachment was scrubbed... Name: LocaleTest.html.gz Type: application/x-gzip Size: 2841 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: