From zander@javalobby.org Sat Apr 3 13:05:00 2004 From: zander@javalobby.org (Thomas Zander) Date: Sat, 03 Apr 2004 13:05:00 -0000 Subject: Some issues.. Message-ID: <200404031504.41093.zander@javalobby.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hmm; I spent a couple of days running with the snapshot which I downloaded from the webpage (http://sources.redhat.com/mauve/) until I found out is _very_ far from recent (which the 'snapshot' seemed to imply) I must say its pretty bad that the snapshot is over a year old!! I suggest to remote the snapshot; or have up-to-date versions created nightly. I looked at the homepage and found a 'breaking news' that I found rather dubious; it looks like its been there for ages since the 'sidebar' does not work (on either konqueror or on mozilla), the 'logo design' leads to a dead link, the 'contribute' page is empty.. Next CVS does not compile with suns javac (gnu/testlet/java/text/SimpleDateFormat/attribute.java) Please make the project seem 'less dead' to the passing eye!! If Red-hat does not do anything; what about moving the project to sourceforge or savannah ?? Anyway; maybe someone here can answer my question posted on the classpath list a couple of days ago (providing a patch to mauve). http://mail.gnu.org/archive/html/classpath/2004-04/msg00000.html if this is a mailinglist; please cc answers! - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAbrZnCojCW6H2z/QRAohDAKDnje/pd+rt0T6zb28tlFoWpOnnAwCfceY4 CHmp/2CEU8wc4iQVQdvYlUo= =n7n2 -----END PGP SIGNATURE----- From aph@redhat.com Sat Apr 3 13:16:00 2004 From: aph@redhat.com (Andrew Haley) Date: Sat, 03 Apr 2004 13:16:00 -0000 Subject: Some issues.. In-Reply-To: <200404031504.41093.zander@javalobby.org> References: <200404031504.41093.zander@javalobby.org> Message-ID: <16494.47358.415834.600012@cuddles.cambridge.redhat.com> Thomas Zander writes: > > Next CVS does not compile with suns javac > (gnu/testlet/java/text/SimpleDateFormat/attribute.java) Would you please help us here by sending a patch? > Please make the project seem 'less dead' to the passing eye!! If Red-hat > does not do anything; what about moving the project to sourceforge or > savannah ?? How would moving the project to a different server help? Many people contribute to Mauve, Red Hat provide the server. > Anyway; maybe someone here can answer my question posted on the classpath > list a couple of days ago (providing a patch to mauve). > http://mail.gnu.org/archive/html/classpath/2004-04/msg00000.html It was a very strange patch. A tarfile with one file that was a diff, and a new directory. However, that patch looks reasonable enough. However, there was no ChangeLog entry; we'll need one of those. Andrew. From zander@javalobby.org Sat Apr 3 13:41:00 2004 From: zander@javalobby.org (Thomas Zander) Date: Sat, 03 Apr 2004 13:41:00 -0000 Subject: Some issues.. In-Reply-To: <16494.47358.415834.600012@cuddles.cambridge.redhat.com> References: <200404031504.41093.zander@javalobby.org> <16494.47358.415834.600012@cuddles.cambridge.redhat.com> Message-ID: <200404031540.39350.zander@javalobby.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday 03 April 2004 15:15, Andrew Haley wrote: > Thomas Zander writes: > > Next CVS does not compile with suns javac > > (gnu/testlet/java/text/SimpleDateFormat/attribute.java) > > Would you please help us here by sending a patch? It seems the author used some illegal constructs; I'm not sure what he meant so I'll send the error messages instead. [javac] Compiling 678 source files to /home/zander/sources/java/mauve/build [javac] /home/zander/sources/java/mauve/gnu/testlet/java/text/SimpleDateFormat/attribute.java:160: illegal start of expression [javac] static Format.Field[] fields = new Format.Field[] { [javac] ^ [javac] /home/zander/sources/java/mauve/gnu/testlet/java/text/SimpleDateFormat/attribute.java:165: illegal start of expression [javac] static int[] begin = new int[] { [javac] ^ [javac] /home/zander/sources/java/mauve/gnu/testlet/java/text/SimpleDateFormat/attribute.java:168: illegal start of expression [javac] static int[] end = new int[] { I don't think these 'static' modifiers are needed in the first place; but why were they added? Second; I found at least one directory that contains java files without a package; leading it to be uncompilable (due to duplicate class names) I found: gnu/testlet/BinaryCompatibility/altered/ Should those have package lines?? > > Please make the project seem 'less dead' to the passing eye!! If > > Red-hat does not do anything; what about moving the project to > > sourceforge or savannah ?? > > How would moving the project to a different server help? Many people > contribute to Mauve, Red Hat provide the server. Oh; I did not want to imply mauve can't run on a RedHat server; my intent was to let you know of the problems. And since I could not imagine being the first to notice them I added a suggestion in case the pages on RedHat's servers were not available to the project members. Anyway; Please make the project seem 'less dead' to the passing eye!! > > maybe someone here can answer my question posted on the > > classpath list a couple of days ago (providing a patch to mauve). > > http://mail.gnu.org/archive/html/classpath/2004-04/msg00000.html > > It was a very strange patch. A tarfile with one file that was a diff, > and a new directory. However, that patch looks reasonable enough. > However, there was no ChangeLog entry; we'll need one of those. I noticed that the patch does not cleanly apply anymore; here is a new diff. - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAbr7TCojCW6H2z/QRAu+CAKCiC9VbH6bPq+rfQNga7ekPuLuaDACgwxI9 js0VZsiSLnzzLtIS1DitU20= =MuJw -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: antCompat.diff Type: text/x-diff Size: 1185 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: antMauve.tgz Type: application/x-tgz Size: 2538 bytes Desc: not available URL: From aph@redhat.com Sat Apr 3 15:42:00 2004 From: aph@redhat.com (Andrew Haley) Date: Sat, 03 Apr 2004 15:42:00 -0000 Subject: Some issues.. In-Reply-To: <200404031540.39350.zander@javalobby.org> References: <200404031504.41093.zander@javalobby.org> <16494.47358.415834.600012@cuddles.cambridge.redhat.com> <200404031540.39350.zander@javalobby.org> Message-ID: <16494.56084.958410.241061@cuddles.cambridge.redhat.com> Thomas Zander writes: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Saturday 03 April 2004 15:15, Andrew Haley wrote: > > Thomas Zander writes: > > > Next CVS does not compile with suns javac > > > (gnu/testlet/java/text/SimpleDateFormat/attribute.java) > > > > Would you please help us here by sending a patch? > > It seems the author used some illegal constructs; I'm not sure what he meant > so I'll send the error messages instead. > > [javac] Compiling 678 source files to /home/zander/sources/java/mauve/build > [javac] /home/zander/sources/java/mauve/gnu/testlet/java/text/SimpleDateFormat/attribute.java:160: illegal start of expression > [javac] static Format.Field[] fields = new Format.Field[] { > [javac] ^ > [javac] /home/zander/sources/java/mauve/gnu/testlet/java/text/SimpleDateFormat/attribute.java:165: illegal start of expression > [javac] static int[] begin = new int[] { > [javac] ^ > [javac] /home/zander/sources/java/mauve/gnu/testlet/java/text/SimpleDateFormat/attribute.java:168: illegal start of expression > [javac] static int[] end = new int[] { > > I don't think these 'static' modifiers are needed in the first place; but why were > they added? Beats me. Whatever they are for, they do nothing to test date formatting. > Second; I found at least one directory that contains java files without a > package; leading it to be uncompilable (due to duplicate class names) > I found: > gnu/testlet/BinaryCompatibility/altered/ > Should those have package lines?? No. This package comes with a script that does the building and copies some files around. I suppose you could create a Ant version of this script. > > > Please make the project seem 'less dead' to the passing eye!! If > > > Red-hat does not do anything; what about moving the project to > > > sourceforge or savannah ?? > > > > How would moving the project to a different server help? Many people > > contribute to Mauve, Red Hat provide the server. > > Oh; I did not want to imply mauve can't run on a RedHat server; my > intent was to let you know of the problems. And since I could not > imagine being the first to notice them I added a suggestion in case > the pages on RedHat's servers were not available to the project > members. > Anyway; Please make the project seem 'less dead' to the passing eye!! > > > maybe someone here can answer my question posted on the > > > classpath list a couple of days ago (providing a patch to mauve). > > > http://mail.gnu.org/archive/html/classpath/2004-04/msg00000.html > > > > It was a very strange patch. A tarfile with one file that was a diff, > > and a new directory. However, that patch looks reasonable enough. > > However, there was no ChangeLog entry; we'll need one of those. > > I noticed that the patch does not cleanly apply anymore; here is a new diff. Sorry to make this difficult, but the ChangeLog must contain the names of all the files that are added, with some comment. The diff must contain everything that changes: use "diff -N" to generate diffs with new files. Andrew. From zander@javalobby.org Sat Apr 3 16:06:00 2004 From: zander@javalobby.org (Thomas Zander) Date: Sat, 03 Apr 2004 16:06:00 -0000 Subject: Some issues.. In-Reply-To: <16494.56084.958410.241061@cuddles.cambridge.redhat.com> References: <200404031504.41093.zander@javalobby.org> <200404031540.39350.zander@javalobby.org> <16494.56084.958410.241061@cuddles.cambridge.redhat.com> Message-ID: <200404031805.35315.zander@javalobby.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Saturday 03 April 2004 17:41, Andrew Haley wrote: > Thomas Zander writes: > Sorry to make this difficult, but the ChangeLog must contain the names > of all the files that are added, with some comment. The diff must > contain everything that changes: use "diff -N" to generate diffs with > new files. Here is a diff off what I did here. 1) fix compilation of attribute.java 2) add ant stuff 3) add some tests in swing. Hope you can use it in 1 patch! - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAbuDMCojCW6H2z/QRAuZLAJ4xRwtKNJRjCmOnVids0XUo79CHiQCfZg9S SM9gNhmRIBR3sUMvx2Kukfo= =TCmt -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: mauve.diff.bz2 Type: application/x-bzip2 Size: 11602 bytes Desc: not available URL: From zander@javalobby.org Tue Apr 6 07:55:00 2004 From: zander@javalobby.org (Thomas) Date: Tue, 06 Apr 2004 07:55:00 -0000 Subject: Mauve patches. Message-ID: <200404060956.14298.zander@javalobby.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've submitted several patches to both list and hear nothing; is there anyone who can comment/commit on these? Please! - -- Regards Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAcmKdCojCW6H2z/QRAvZpAKDd5gaoHFbHLIMM/RsAMWA5VSj2HgCgi4na KTB8qTvzHh02ysf+loktnGI= =OWa0 -----END PGP SIGNATURE----- From konqueror@gmx.de Tue Apr 6 08:47:00 2004 From: konqueror@gmx.de (Michael Koch) Date: Tue, 06 Apr 2004 08:47:00 -0000 Subject: Mauve patches. In-Reply-To: <200404060956.14298.zander@javalobby.org> References: <200404060956.14298.zander@javalobby.org> Message-ID: <200404061046.27919.konqueror@gmx.de> Am Dienstag, 6. April 2004 09:56 schrieb Thomas: > I've submitted several patches to both list and hear nothing; is > there anyone who can comment/commit on these? We are all doing this in our freetime so we need some time nee out backlogs sometimes. Personally I have Mauve CVS access but I'm using not using ant so I cant really vote on your patch. I think Tom Tromey or Mark Wielaard will look into this in some days. If not please ping me and I will do it. Michael From brawer@dandelis.ch Tue Apr 6 11:52:00 2004 From: brawer@dandelis.ch (Sascha Brawer) Date: Tue, 06 Apr 2004 11:52:00 -0000 Subject: Mauve patch In-Reply-To: <200404060330.i363UY1B018067@arch20m.dellroad.org> References: <200404060330.i363UY1B018067@arch20m.dellroad.org> Message-ID: <20040406115205.3060@smtp.mail.ch.easynet.net> Archie Cobbs wrote on Mon, 5 Apr 2004 22:30:34 -0500: >Is this the right place to send Mauve patches? If not please point me >(or the patch) in the right direction. There's a list mauve-discuss@sources.redhat.com (presumably with mostly the same subscribers as commit-classpath@gnu.org, although there seem to be also a few non-Classpath people there). >In JC, phantom references are enqueued on the next finalizer run >after the one that finalizes the object, and finalizer runs only >happen after a GC cycle, therefore the patch below is required to >make JC pass the test; ie, the test is being too strict. >Index: gnu/testlet/java/lang/ref/PhantomReference/phantom.java >=================================================================== >RCS file: /cvs/mauve/mauve/gnu/testlet/java/lang/ref/PhantomReference/ >phantom.java,v >retrieving revision 1.1 >diff -u -r1.1 phantom.java >--- gnu/testlet/java/lang/ref/PhantomReference/phantom.java 27 Sep >2001 15:44:09 -0000 1.1 >+++ gnu/testlet/java/lang/ref/PhantomReference/phantom.java 6 Apr >2004 03:28:19 -0000 >@@ -70,6 +70,8 @@ > > PhantomReference wr = try1 (q, harness); > System.gc (); >+ Thread.yield(); >+ System.gc (); > > Reference r = null; > try Does this really guarantee that the finalizer has run? Couldn't this also lead to any other thread, such as some VM-internal thread, without running the finalizer? If so, you might want to call Object.notify in the finalizer and Object.wait at the above code location. -- Sascha Sascha Brawer, brawer@dandelis.ch, http://www.dandelis.ch/people/brawer/ From proetel@aicas.com Tue Apr 6 12:15:00 2004 From: proetel@aicas.com (=?ISO-8859-1?Q?Ingo_Pr=F6tel?=) Date: Tue, 06 Apr 2004 12:15:00 -0000 Subject: Mauve patch In-Reply-To: <20040406115205.3060@smtp.mail.ch.easynet.net> References: <200404060330.i363UY1B018067@arch20m.dellroad.org> <20040406115205.3060@smtp.mail.ch.easynet.net> Message-ID: <40729F67.9030309@aicas.com> Sascha Brawer wrote: > Archie Cobbs wrote on Mon, 5 Apr 2004 22:30:34 -0500: > > >>Is this the right place to send Mauve patches? If not please point me >>(or the patch) in the right direction. > > > There's a list mauve-discuss@sources.redhat.com (presumably with mostly > the same subscribers as commit-classpath@gnu.org, although there seem to > be also a few non-Classpath people there). > > >>In JC, phantom references are enqueued on the next finalizer run >>after the one that finalizes the object, and finalizer runs only >>happen after a GC cycle, therefore the patch below is required to >>make JC pass the test; ie, the test is being too strict. > > > >>Index: gnu/testlet/java/lang/ref/PhantomReference/phantom.java >>=================================================================== >>RCS file: /cvs/mauve/mauve/gnu/testlet/java/lang/ref/PhantomReference/ >>phantom.java,v >>retrieving revision 1.1 >>diff -u -r1.1 phantom.java >>--- gnu/testlet/java/lang/ref/PhantomReference/phantom.java 27 Sep >>2001 15:44:09 -0000 1.1 >>+++ gnu/testlet/java/lang/ref/PhantomReference/phantom.java 6 Apr >>2004 03:28:19 -0000 >>@@ -70,6 +70,8 @@ >> >> PhantomReference wr = try1 (q, harness); >> System.gc (); >>+ Thread.yield(); >>+ System.gc (); >> >> Reference r = null; >> try > > > Does this really guarantee that the finalizer has run? Couldn't this also > lead to any other thread, such as some VM-internal thread, without > running the finalizer? If so, you might want to call Object.notify in the > finalizer and Object.wait at the above code location. > I'm not sure a wait/notify will help. It might also just hang the VM since no garbage collection might occur. Probably the only real solution would be to force an OutOfMemoryError. Before the VM may throw such an error it has to try to clean up memory. But probably not all VMs survive such a test ;-) ingo > -- Sascha > > Sascha Brawer, brawer@dandelis.ch, http://www.dandelis.ch/people/brawer/ > > > -- Ingo Pr??tel proetel@aicas.com aicas GmbH http://www.aicas.com Haid-und-Neu-Str. 18 phone +49 721 663 968-32 76131 Karlsruhe fax +49 721 663 968-93 Germany From archie@dellroad.org Tue Apr 6 14:08:00 2004 From: archie@dellroad.org (Archie Cobbs) Date: Tue, 06 Apr 2004 14:08:00 -0000 Subject: Mauve patch In-Reply-To: <20040406115205.3060@smtp.mail.ch.easynet.net> Message-ID: <200404061346.i36DkRdh019920@arch20m.dellroad.org> Sascha Brawer wrote: > > PhantomReference wr = try1 (q, harness); > > System.gc (); > >+ Thread.yield(); > >+ System.gc (); > > > > Reference r = null; > > try > > Does this really guarantee that the finalizer has run? Couldn't this also > lead to any other thread, such as some VM-internal thread, without > running the finalizer? If so, you might want to call Object.notify in the > finalizer and Object.wait at the above code location. This patch doesn't guarantee anything, and in general it's impossible to make this test "correct" because the spec allows finalization and reference enqueuing to happen after arbitrarily long delays. For example, a JVM that *never* finalizes is still within the spec (it would probably throw OutOfMemoryError's more readily though). This patch simply makes the test "correct" for JC (and possibly some other VM(s) out there). Since there's no way to *ensure* the finalizer and reference enqueing thread(s) have run, we just try to give them every opportunity to do so before declaring that their work should be done. -Archie __________________________________________________________________________ Archie Cobbs * CTO, Awarix * http://www.awarix.com From tromey@redhat.com Wed Apr 7 05:45:00 2004 From: tromey@redhat.com (Tom Tromey) Date: Wed, 07 Apr 2004 05:45:00 -0000 Subject: Mauve patch In-Reply-To: <200404061346.i36DkRdh019920@arch20m.dellroad.org> References: <200404061346.i36DkRdh019920@arch20m.dellroad.org> Message-ID: <87vfkc4amd.fsf@fleche.redhat.com> >>>>> "Archie" == Archie Cobbs writes: Archie> This patch doesn't guarantee anything, and in general it's impossible Archie> to make this test "correct" because the spec allows finalization and Archie> reference enqueuing to happen after arbitrarily long delays. Yeah, these tests are basically bogus. I thought I had removed them, but I guess I forgot. Archie> This patch simply makes the test "correct" for JC (and possibly Archie> some other VM(s) out there). Since there's no way to *ensure* the Archie> finalizer and reference enqueing thread(s) have run, we just try Archie> to give them every opportunity to do so before declaring that their Archie> work should be done. I think the patch is fine to go in. It certainly doesn't make the situation any worse. Perhaps it is better to just remove the test. Or make a new "unportable" section of Mauve, since some things seemingly can't be tested. Tom From crawley@dstc.edu.au Wed Apr 7 06:01:00 2004 From: crawley@dstc.edu.au (Stephen Crawley) Date: Wed, 07 Apr 2004 06:01:00 -0000 Subject: Mauve patch In-Reply-To: Message from Tom Tromey of "06 Apr 2004 23:31:38 CST." <87vfkc4amd.fsf@fleche.redhat.com> Message-ID: <200404070600.i3760YmT005287@piglet.dstc.edu.au> Hi Tom, > Perhaps it is better to just remove the test. That would be my preferred option. > Or make a new "unportable" section of Mauve, since some things > seemingly can't be tested. I think it would be better for each JVM projects to manage its own non-portable testcases. In Kissme for example, there is a small regression testsuite (called "HitMe") that tests some of Kissme's low level and VM specific features. The HitMe harness assumes that less of the VM infrastructure is working that the Mauve harness does. There is even a version that avoids using java.lang.io.* and uses the rc returned using System.exit() to signal test success / failure. Some HitMe tests require special Kissme commandline arguments. The makefile understands this ... -- Steve From archie@dellroad.org Wed Apr 7 14:53:00 2004 From: archie@dellroad.org (Archie Cobbs) Date: Wed, 07 Apr 2004 14:53:00 -0000 Subject: Mauve patch In-Reply-To: <200404070600.i3760YmT005287@piglet.dstc.edu.au> Message-ID: <200404071426.i37EQY4N077630@arch20m.dellroad.org> Stephen Crawley wrote: > > Or make a new "unportable" section of Mauve, since some things > > seemingly can't be tested. That's a reasonable idea.. i.e., a "don't panic if these tests fail" section. > I think it would be better for each JVM projects to manage its own > non-portable testcases. In Kissme for example, there is a small Would these be kept in the Mauve source or the JVM source? If the latter, it would be nice for us to define a standard way to tell Mauve, "oh yeah, also run these JVM-specific tests and by the way they're in this other directory..." or whatever. -Archie __________________________________________________________________________ Archie Cobbs * CTO, Awarix * http://www.awarix.com From zander@javalobby.org Thu Apr 8 19:34:00 2004 From: zander@javalobby.org (Thomas Zander) Date: Thu, 08 Apr 2004 19:34:00 -0000 Subject: Mauve patches. In-Reply-To: <200404061046.27919.konqueror@gmx.de> References: <200404060956.14298.zander@javalobby.org> <200404061046.27919.konqueror@gmx.de> Message-ID: <200404082133.32680.zander@javalobby.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'd really like to see my stuff committed, or commented on if just committing is unacceptable. Are there any people actually maintaining mauve? Nobody commented on the fixed needed for the website either. In short who is the core maintainer for mauve? On Tuesday 06 April 2004 10:46, Michael Koch wrote: > Am Dienstag, 6. April 2004 09:56 schrieb Thomas: > > I've submitted several patches to both list and hear nothing; is > > there anyone who can comment/commit on these? > > We are all doing this in our freetime so we need some time nee out > backlogs sometimes. > > Personally I have Mauve CVS access but I'm using not using ant so I cant > really vote on your patch. I think Tom Tromey or Mark Wielaard will > look into this in some days. If not please ping me and I will do it. > > > Michael - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAdakLCojCW6H2z/QRAvPAAJ9VIVsdIvvJo9XvNIKvkKtho1FqgQCglYT1 004SB9mIxk/3Z8FF04TrxHE= =dK+F -----END PGP SIGNATURE----- From konqueror@gmx.de Thu Apr 8 19:50:00 2004 From: konqueror@gmx.de (Michael Koch) Date: Thu, 08 Apr 2004 19:50:00 -0000 Subject: Mauve patches. In-Reply-To: <200404082133.32680.zander@javalobby.org> References: <200404060956.14298.zander@javalobby.org> <200404061046.27919.konqueror@gmx.de> <200404082133.32680.zander@javalobby.org> Message-ID: <200404082150.24907.konqueror@gmx.de> Am Donnerstag, 8. April 2004 21:33 schrieb Thomas Zander: > I'd really like to see my stuff committed, or commented on if just > committing is unacceptable. > > Are there any people actually maintaining mauve? Nobody commented on > the fixed needed for the website either. > In short who is the core maintainer for mauve? Mauve has no real maintainer. There are just some people that commit stuff in a chaotic way. Michael > On Tuesday 06 April 2004 10:46, Michael Koch wrote: > > Am Dienstag, 6. April 2004 09:56 schrieb Thomas: > > > I've submitted several patches to both list and hear nothing; is > > > there anyone who can comment/commit on these? > > > > We are all doing this in our freetime so we need some time nee out > > backlogs sometimes. > > > > Personally I have Mauve CVS access but I'm using not using ant so I > > cant really vote on your patch. I think Tom Tromey or Mark Wielaard > > will look into this in some days. If not please ping me and I will > > do it. > > > > > > Michael From aph@redhat.com Thu Apr 8 19:58:00 2004 From: aph@redhat.com (Andrew Haley) Date: Thu, 08 Apr 2004 19:58:00 -0000 Subject: Mauve patches. In-Reply-To: <200404082150.24907.konqueror@gmx.de> References: <200404060956.14298.zander@javalobby.org> <200404061046.27919.konqueror@gmx.de> <200404082133.32680.zander@javalobby.org> <200404082150.24907.konqueror@gmx.de> Message-ID: <16501.44635.43431.486147@cuddles.cambridge.redhat.com> Michael Koch writes: > Am Donnerstag, 8. April 2004 21:33 schrieb Thomas Zander: > > I'd really like to see my stuff committed, or commented on if just > > committing is unacceptable. > > > > Are there any people actually maintaining mauve? Nobody commented on > > the fixed needed for the website either. > > In short who is the core maintainer for mauve? > > Mauve has no real maintainer. There are just some people that commit > stuff in a chaotic way. I have some patches for Mauve. Thomas Zander's patch is one of them, but it needs a little change to the ChangeLog entry to make it standard. I was intending to do it at the start of this week, sorry. Andrew. From zander@javalobby.org Sun Apr 11 06:48:00 2004 From: zander@javalobby.org (Thomas Zander) Date: Sun, 11 Apr 2004 06:48:00 -0000 Subject: Mauve patches. In-Reply-To: <16501.44635.43431.486147@cuddles.cambridge.redhat.com> References: <200404060956.14298.zander@javalobby.org> <200404082150.24907.konqueror@gmx.de> <16501.44635.43431.486147@cuddles.cambridge.redhat.com> Message-ID: <200404110848.06673.zander@javalobby.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 08 April 2004 21:56, Andrew Haley wrote: > ?> > I'd really like to see my stuff committed, or commented on if just > ?> > committing is unacceptable. ... > I was intending to do it at the start of this week, sorry. Its next week now; so your schedule was probably too full. (No offence!) I hope you'll agree that its more important to have people creating patches and moving the project forward then to always have a 100% correct CVS. (problems can be fixed post-commit) In that case; what about providing me with a writable CVS account so I won't have to bother you anymore. Oh; and a explanation of the correct changelog format; or a link to that since you said there was something wrong with it; but I don't know what. Hope to hear from you; Mauve is growing way too slow for my taste this way. - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAeOolCojCW6H2z/QRAtQNAKCeeKJpauJkytXf1iYfV8QDxv4H+gCfbYRw 6fhgQWbMbRMOwFI71OahauA= =EvsI -----END PGP SIGNATURE----- From dave@lichteblau.com Sun Apr 11 12:22:00 2004 From: dave@lichteblau.com (David Lichteblau) Date: Sun, 11 Apr 2004 12:22:00 -0000 Subject: Mauve patches. In-Reply-To: <200404110848.06673.zander@javalobby.org> References: <200404060956.14298.zander@javalobby.org> <200404082150.24907.konqueror@gmx.de> <16501.44635.43431.486147@cuddles.cambridge.redhat.com> <200404110848.06673.zander@javalobby.org> Message-ID: <20040411122255.GC21097@lichteblau.com> Quoting Thomas Zander (zander@javalobby.org): > I hope you'll agree that its more important to have people creating patches > and moving the project forward then to always have a 100% correct CVS. > (problems can be fixed post-commit) No! David -- Common Lisp is the Borg of programming languages -- Bill Clementson -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From archie@dellroad.org Sun Apr 11 15:56:00 2004 From: archie@dellroad.org (Archie Cobbs) Date: Sun, 11 Apr 2004 15:56:00 -0000 Subject: Mauve patches. In-Reply-To: <200404110848.06673.zander@javalobby.org> Message-ID: <200404111544.i3BFiGbN040298@arch20m.dellroad.org> Thomas Zander wrote: > On Thursday 08 April 2004 21:56, Andrew Haley wrote: > > ??> > I'd really like to see my stuff committed, or commented on if just > > ??> > committing is unacceptable. > ... > > I was intending to do it at the start of this week, sorry. > > Its next week now; so your schedule was probably too full. (No offence!) > > I hope you'll agree that its more important to have people creating patches > and moving the project forward then to always have a 100% correct CVS. > (problems can be fixed post-commit) > In that case; what about providing me with a writable CVS account so I > won't have to bother you anymore. Me too :-) -Archie __________________________________________________________________________ Archie Cobbs * CTO, Awarix * http://www.awarix.com From zander@javalobby.org Sun Apr 11 17:20:00 2004 From: zander@javalobby.org (Thomas Zander) Date: Sun, 11 Apr 2004 17:20:00 -0000 Subject: Mauve patches. In-Reply-To: <20040411122255.GC21097@lichteblau.com> References: <200404060956.14298.zander@javalobby.org> <200404110848.06673.zander@javalobby.org> <20040411122255.GC21097@lichteblau.com> Message-ID: <200404111919.24816.zander@javalobby.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday 11 April 2004 14:22, David Lichteblau wrote: > Quoting Thomas Zander (zander@javalobby.org): > > I hope you'll agree that its more important to have people creating > > patches and moving the project forward then to always have a 100% > > correct CVS. (problems can be fixed post-commit) > > No! David; I have not seen you before; an introduction might be in place. After we found out what your part in Mauve is; would you care to elaborate on your position? I'm assuming we all want the best java test suite there is; and in my experience the project is moving forward too slow to get that to happen. Instead of just shouting 'no!' an alternative solution is always welcome. Thanx. - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAeX4ZCojCW6H2z/QRAtPDAJ9UsFw4/Rt4SKHlAbLVOMOnAGyE8QCgjLMP S6M2ClKX4exsFt8aTu6HfG8= =Ol2e -----END PGP SIGNATURE----- From dave@lichteblau.com Sun Apr 11 18:57:00 2004 From: dave@lichteblau.com (David Lichteblau) Date: Sun, 11 Apr 2004 18:57:00 -0000 Subject: Mauve patches. In-Reply-To: <200404111919.24816.zander@javalobby.org> References: <200404060956.14298.zander@javalobby.org> <200404110848.06673.zander@javalobby.org> <20040411122255.GC21097@lichteblau.com> <200404111919.24816.zander@javalobby.org> Message-ID: <20040411185745.GD21097@lichteblau.com> Hi Thomas, Quoting Thomas Zander (zander@javalobby.org): > On Sunday 11 April 2004 14:22, David Lichteblau wrote: > > Quoting Thomas Zander (zander@javalobby.org): > > > I hope you'll agree that its more important to have people creating > > > patches and moving the project forward then to always have a 100% > > > correct CVS. (problems can be fixed post-commit) > > No! > David; I have not seen you before; an introduction might be in place. > After we found out what your part in Mauve is; I'm just yet another Mauve user. > would you care to elaborate on your position? Sure: "Problems should be fixed pre-commit." BTW, to ask a technical question, is the "tagging" of Mauve testcases used in practice? Much of the complexity of the existing build systems stems from the fact that tests are selected by a non-trivial script. If not for the tags, something like "find . -name \*.java" would be enough to select all files. Mark Wielaard sent an analysis of test suite failures for current Classpath, which I found very helpful (thanks!). When I am interested to see whether the current Classpath version "works", which tags should be used? All of them, right? Unless I misunderstood Thomas' question, he could not compile all of Mauve because his script tried to compile _everything_, as opposed to those files usually chosen by the standard build system. I would find it a little confusing if Mauve provided two build systems, one which uses tags and one which does not. Thanks, David -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From zander@javalobby.org Sun Apr 11 19:37:00 2004 From: zander@javalobby.org (Thomas Zander) Date: Sun, 11 Apr 2004 19:37:00 -0000 Subject: Mauve patches. In-Reply-To: <20040411185745.GD21097@lichteblau.com> References: <200404060956.14298.zander@javalobby.org> <200404111919.24816.zander@javalobby.org> <20040411185745.GD21097@lichteblau.com> Message-ID: <200404112136.52657.zander@javalobby.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Unless I misunderstood Thomas' question, he could not compile all of > Mauve because his script tried to compile _everything_, as opposed to > those files usually chosen by the standard build system. I would find > it a little confusing if Mauve provided two build systems, one which > uses tags and one which does not. You did misunderstand my question; the question is that I created a build system that only tests the classes I select (based on ant) and I want it committed; but there seems to be no maintainer that can comment on, or commit the patch. My question therefor (to be exact) was that if some more freedom for not-yet-initiated coders is allowed, I would like to have a writable cvs-account which means I can continue working without waiting for more then a week. Hope that clears it up. - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAeZ5TCojCW6H2z/QRAt1GAJ9BozGa9R0Li6JhJyIIDvj8+q+9hgCfaEPr bOVQl0rJWCtvYzH0mB+r2Jc= =C+YF -----END PGP SIGNATURE----- From cbj@gnu.org Mon Apr 12 04:12:00 2004 From: cbj@gnu.org (C. Brian Jones) Date: Mon, 12 Apr 2004 04:12:00 -0000 Subject: Mauve patches. In-Reply-To: <200404112136.52657.zander@javalobby.org> References: <200404060956.14298.zander@javalobby.org> <200404111919.24816.zander@javalobby.org> <20040411185745.GD21097@lichteblau.com> <200404112136.52657.zander@javalobby.org> Message-ID: <1081743135.3175.18.camel@lyta.haphazard.org> On Sun, 2004-04-11 at 15:36, Thomas Zander wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > > > Unless I misunderstood Thomas' question, he could not compile all of > > Mauve because his script tried to compile _everything_, as opposed to > > those files usually chosen by the standard build system. I would find > > it a little confusing if Mauve provided two build systems, one which > > uses tags and one which does not. > > You did misunderstand my question; > the question is that I created a build system that only tests the classes I > select (based on ant) and I want it committed; but there seems to be no > maintainer that can comment on, or commit the patch. > > My question therefor (to be exact) was that if some more freedom for > not-yet-initiated coders is allowed, I would like to have a writable > cvs-account which means I can continue working without waiting for more > then a week. Started doing some work over the weekend to add some tests to Mauve based on another software package I've made that has non-Mauve related functionality. Anyway it seems to be somewhat difficult to add something like this to Mauve, that has extensive data sets, a small library not in the gnu.* namespace, etc. I've started by trying to define the problem and generalize on potential solutions. Problems * Cannot be installed (packaged, used repeatedly for various cases from same install) * No integrated pass/fail/expected/unexpected summary * Repeated executions require knowing inner workings of various scripts * Integration of additional libraries difficult at best * Integration of VM specific tests also difficult Solutions * Change configure script to be installation oriented, similar for Makefile.am (started this already) * New script(s) for running mauve to compile, execute, report results (consider using dejagnu) * Specify java compiler at runtime * Specify vm at runtime * Specify temporary directory at runtime * Specify additional libraries/resources at runtime * Specify additional tests at runtime Basically all the cruft and gorp in configure.in, Makefile.am, choose, etc. gets done over. The TAGS system is broken, it doesn't allow one to specify that a particular test is only valid for 1.1, 1.2, 1.3 and not 1.4+, essential to handle deprecated methods that eventually get removed. I have no problem doing this work, my problem is all the people that depend on the current directory structure, build process, etc. that will scream if something is changed. Anyway I have started the work, when I have a patch I'll let the list review. Don't hold your breath, I'm slow sometimes. :) Thanks, Brian -- Brian Jones -------------- 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 mark@klomp.org Mon Apr 12 12:15:00 2004 From: mark@klomp.org (Mark Wielaard) Date: Mon, 12 Apr 2004 12:15:00 -0000 Subject: mauve ./ChangeLog gnu/testlet/java/lang/Charac ... In-Reply-To: <20040408160537.21917.qmail@sources.redhat.com> References: <20040408160537.21917.qmail@sources.redhat.com> Message-ID: <1081772102.13170.567.camel@elsschot.wildebeest.org> Hi Stephen, On Thu, 2004-04-08 at 18:05, crawley@sources.redhat.com wrote: > Fixed java.lang.Character.unicode test to match JDK 1.4 semantics Nice cleanup! One thing that seems to be missing though is the CharInfo.decimalDigit field. Without such a field the code will not compile. But it seems we don't use that field during the tests either. Should I add the following or did you have something else in mind? diff -u -r1.3 CharInfo.java --- gnu/testlet/java/lang/Character/CharInfo.java 4 Feb 1999 18:46:19 -0000 1.3 +++ gnu/testlet/java/lang/Character/CharInfo.java 12 Apr 2004 12:12:44 -0000 @@ -29,6 +29,7 @@ { public String name; public String category; + public int decimalDigit; public int digit; public int numericValue; public char uppercase; With that it compiles again and java.lang.Character.unicode gives 0 of 3578944 tests failed for GNU Classpath :) 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 crawley@dstc.edu.au Mon Apr 12 23:26:00 2004 From: crawley@dstc.edu.au (Stephen Crawley) Date: Mon, 12 Apr 2004 23:26:00 -0000 Subject: mauve ./ChangeLog gnu/testlet/java/lang/Charac ... In-Reply-To: Message from Mark Wielaard of "Mon, 12 Apr 2004 14:15:02 +0200." <1081772102.13170.567.camel@elsschot.wildebeest.org> Message-ID: <200404122326.i3CNQ6mT011686@piglet.dstc.edu.au> Folks, Mark Wielaard wrote: > One thing that seems to be missing though is the CharInfo.decimalDigit > field. Without such a field the code will not compile. But it seems we > don't use that field during the tests either. Should I add the following > or did you have something else in mind? > > diff -u -r1.3 CharInfo.java > --- gnu/testlet/java/lang/Character/CharInfo.java 4 Feb 1999 18:46:19 -0000 1.3 > +++ gnu/testlet/java/lang/Character/CharInfo.java 12 Apr 2004 12:12:44 -0000 > @@ -29,6 +29,7 @@ > { > public String name; > public String category; > + public int decimalDigit; > public int digit; > public int numericValue; > public char uppercase; OOPS!! My apologies everyone. It looks like I forgot to check-in the change to CharInfo! Mark: your change is spot on. -- Steve From aph@redhat.com Tue Apr 13 13:22:00 2004 From: aph@redhat.com (Andrew Haley) Date: Tue, 13 Apr 2004 13:22:00 -0000 Subject: Mauve patches. In-Reply-To: <20040411185745.GD21097@lichteblau.com> References: <200404060956.14298.zander@javalobby.org> <200404110848.06673.zander@javalobby.org> <20040411122255.GC21097@lichteblau.com> <200404111919.24816.zander@javalobby.org> <20040411185745.GD21097@lichteblau.com> Message-ID: <16507.59643.348460.749466@cuddles.cambridge.redhat.com> David Lichteblau writes: > > BTW, to ask a technical question, is the "tagging" of Mauve testcases > used in practice? Yes, it is. > Much of the complexity of the existing build systems stems from the > fact that tests are selected by a non-trivial script. If not for > the tags, something like "find . -name \*.java" would be enough to > select all files. Well, sooner or later we'll be working with 1.5 (Java++? :-) and at that point it'll be pretty useful. So let's keep it, please. > Unless I misunderstood Thomas' question, he could not compile all > of Mauve because his script tried to compile _everything_, as > opposed to those files usually chosen by the standard build system. > I would find it a little confusing if Mauve provided two build > systems, one which uses tags and one which does not. Yes. I suppose Thomas' Ant script should do the right thing with respect to the tags. Andrew. From zander@javalobby.org Tue Apr 13 13:55:00 2004 From: zander@javalobby.org (Thomas) Date: Tue, 13 Apr 2004 13:55:00 -0000 Subject: Mauve patches. In-Reply-To: <16507.59643.348460.749466@cuddles.cambridge.redhat.com> References: <200404060956.14298.zander@javalobby.org> <20040411185745.GD21097@lichteblau.com> <16507.59643.348460.749466@cuddles.cambridge.redhat.com> Message-ID: <200404131556.13282.zander@javalobby.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 13 April 2004 15:19, you wrote: > David Lichteblau writes: > > Unless I misunderstood Thomas' question, he could not compile all > > of Mauve because his script tried to compile _everything_, as > > opposed to those files usually chosen by the standard build system. > > I would find it a little confusing if Mauve provided two build > > systems, one which uses tags and one which does not. > > Yes. I suppose Thomas' Ant script should do the right thing with > respect to the tags. The selecting of files based on some 'tag in their content is quite easy in ant; its a standard target. I could add an ant-build target that builds based on tags. Sorry fly to David for not fully understanding the above paragraph the first time I replied to it! (And giving an answer that did not it justice). - -- Regards Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAe/F8CojCW6H2z/QRAvTJAKDLBfvoky2GpU+G3rezejPRZ4sPzACg1K62 7qtMb1oEi3sOSShNuLHDSAs= =+joY -----END PGP SIGNATURE----- From aph@redhat.com Tue Apr 13 14:30:00 2004 From: aph@redhat.com (Andrew Haley) Date: Tue, 13 Apr 2004 14:30:00 -0000 Subject: Mauve patches. In-Reply-To: <200404131556.13282.zander@javalobby.org> References: <200404060956.14298.zander@javalobby.org> <20040411185745.GD21097@lichteblau.com> <16507.59643.348460.749466@cuddles.cambridge.redhat.com> <200404131556.13282.zander@javalobby.org> Message-ID: <16507.63791.746420.624801@cuddles.cambridge.redhat.com> Thomas writes: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Tuesday 13 April 2004 15:19, you wrote: > > David Lichteblau writes: > > > Unless I misunderstood Thomas' question, he could not compile all > > > of Mauve because his script tried to compile _everything_, as > > > opposed to those files usually chosen by the standard build system. > > > I would find it a little confusing if Mauve provided two build > > > systems, one which uses tags and one which does not. > > > > Yes. I suppose Thomas' Ant script should do the right thing with > > respect to the tags. > > The selecting of files based on some 'tag in their content is quite easy in > ant; its a standard target. > I could add an ant-build target that builds based on tags. Excellent. Now I feel not so bad for being slow to commit... Andrew. From zander@javalobby.org Tue Apr 13 17:14:00 2004 From: zander@javalobby.org (Thomas Zander) Date: Tue, 13 Apr 2004 17:14:00 -0000 Subject: Mauve patches. In-Reply-To: <16507.63791.746420.624801@cuddles.cambridge.redhat.com> References: <200404060956.14298.zander@javalobby.org> <200404131556.13282.zander@javalobby.org> <16507.63791.746420.624801@cuddles.cambridge.redhat.com> Message-ID: <200404131913.49935.zander@javalobby.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 13 April 2004 16:29, Andrew Haley wrote: > Thomas writes: > > On Tuesday 13 April 2004 15:19, you wrote: > > > Yes. I suppose Thomas' Ant script should do the right thing with > > > respect to the tags. > > > > The selecting of files based on some 'tag in their content is quite > > easy in ant; its a standard target. > > I could add an ant-build target that builds based on tags. > > Excellent. Now I feel not so bad for being slow to commit... Hmm; I kind of (really) like working in CVS, its like a net that catches you when you fail (and more). What about you commit first; then I can safely start to work on adding extra features. I mean; all the questions I posed have been quietly been ignored, I'm not really under the impression Mauve is getting the attention it deserves; I honestly begin starting to wonder if putting it in a CVS on sourceforge or whereever, and more freely giving out CVS accounts is such a bad idea. Some rights to commit and/or to clean up the webpages is the only thing standing in my way to really help make Mauve move forward! - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAfB/LCojCW6H2z/QRAp7eAKDCzNrGAZhIg9c4mLaje2RmIY7/gACeIQ5k wsvu26crbD4glB6ncSiqUlo= =sJxK -----END PGP SIGNATURE----- From aph@redhat.com Tue Apr 13 17:45:00 2004 From: aph@redhat.com (Andrew Haley) Date: Tue, 13 Apr 2004 17:45:00 -0000 Subject: Mauve patches. In-Reply-To: <200404131913.49935.zander@javalobby.org> References: <200404060956.14298.zander@javalobby.org> <200404131556.13282.zander@javalobby.org> <16507.63791.746420.624801@cuddles.cambridge.redhat.com> <200404131913.49935.zander@javalobby.org> Message-ID: <16508.9997.393675.283091@cuddles.cambridge.redhat.com> Thomas Zander writes: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Tuesday 13 April 2004 16:29, Andrew Haley wrote: > > Thomas writes: > > > On Tuesday 13 April 2004 15:19, you wrote: > > > > Yes. I suppose Thomas' Ant script should do the right thing with > > > > respect to the tags. > > > > > > The selecting of files based on some 'tag in their content is quite > > > easy in ant; its a standard target. > > > I could add an ant-build target that builds based on tags. > > > > Excellent. Now I feel not so bad for being slow to commit... > > Hmm; I kind of (really) like working in CVS, its like a net that catches > you when you fail (and more). > What about you commit first; then I can safely start to work on adding > extra features. Alright. > I mean; all the questions I posed have been quietly been ignored, I'm not > really under the impression Mauve is getting the attention it deserves; I > honestly begin starting to wonder if putting it in a CVS on sourceforge or > whereever, and more freely giving out CVS accounts is such a bad idea. Actually, all the questions you posed have not quietly been ignored. I have answered some of them. > Some rights to commit and/or to clean up the webpages is the only > thing standing in my way to really help make Mauve move forward! That and the fact that as yet you have not managed correctly to submit a patch. I have attached a version here, FYI. I don't think I've broken anything with the checkin, but please check. Andrew. 2004-04-13 Thomas Zander * build.xml: New file. * gnu/anttask/RunTests.java: New file. * gnu/testlet/SimpleTestHarness.java (getFailures): New method. * gnu/testlet/javax/swing/JLabel/Icon.java: New file. * gnu/testlet/javax/swing/JLabel/Mnemonic.java: New file. * gnu/testlet/java/text/SimpleDateFormat/attribute.java (test_FieldPos): Locals no longer static. Index: build.xml =================================================================== RCS file: build.xml diff -N build.xml *** /dev/null 1 Jan 1970 00:00:00 -0000 --- build.xml 13 Apr 2004 17:38:48 -0000 *************** *** 0 **** --- 1,87 ---- + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Mauve test API]]> + + + + + + + + + + + Index: gnu/anttask/RunTests.java =================================================================== RCS file: gnu/anttask/RunTests.java diff -N gnu/anttask/RunTests.java *** /dev/null 1 Jan 1970 00:00:00 -0000 --- gnu/anttask/RunTests.java 13 Apr 2004 17:38:48 -0000 *************** *** 0 **** --- 1,101 ---- + /* + Copyright (c) 2004 Thomas Zander + + 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. */ + + package gnu.anttask; + + import gnu.testlet.*; + import java.io.*; + import java.util.*; + + import org.apache.tools.ant.*; + import org.apache.tools.ant.taskdefs.*; + import org.apache.tools.ant.types.*; + + public class RunTests extends MatchingTask { + private boolean verbose=false, debug=false, haltOnFailure=false, failOnError=true; + private Path sourceDir=null; + private Vector filesets=new Vector(); + + public void execute() throws BuildException { + MyTestHarness harness = new MyTestHarness (verbose, debug, haltOnFailure); + + Iterator iter = filesets.iterator(); + while(iter.hasNext()) { + FileSet fs = (FileSet) iter.next(); + try { + DirectoryScanner ds = fs.getDirectoryScanner(getProject()); + Iterator classNames = Arrays.asList(ds.getIncludedFiles()).iterator(); + while(classNames.hasNext()) { + String filename = (String) classNames.next(); + if(! filename.endsWith(".class")) + continue; // only class files + if(filename.lastIndexOf("$") > filename.lastIndexOf(File.separator)) + continue; // no inner classeS + filename=filename.substring(0, filename.length()-6); + filename=filename.replace(File.separatorChar, '.'); + + harness.runTest(filename); + } + } catch (BuildException be) { + // directory doesn't exist or is not readable + if (failOnError) + throw be; + else + log(be.getMessage(),Project.MSG_WARN); + } + } + } + + public void setVerbose(boolean verbose) { + this.verbose = verbose; + } + + public void setDebug(boolean debug) { + this.debug = debug; + } + + public void setHaltOnFailure(boolean on) { + haltOnFailure = on; + } + + public void setFailOnError(boolean on) { + failOnError = on; + } + + public void addFileset(FileSet set) { + filesets.add(set); + } + + + private static class MyTestHarness extends SimpleTestHarness { + private boolean haltOnFailure; + // extend it b/cause someone thought it should not have public constructors. + public MyTestHarness(boolean verbose, boolean debug, boolean haltOnFailure) { + super(verbose, debug, false); + this.haltOnFailure = haltOnFailure; + } + + protected void runTest (String name) throws BuildException { + super.runtest(name); + if(haltOnFailure && getFailures() > 0) + throw new BuildException("Failures"); + } + } + } Index: gnu/testlet/SimpleTestHarness.java =================================================================== RCS file: /cvs/mauve/mauve/gnu/testlet/SimpleTestHarness.java,v retrieving revision 1.38 diff -p -2 -c -r1.38 SimpleTestHarness.java *** gnu/testlet/SimpleTestHarness.java 29 Aug 2003 14:52:21 -0000 1.38 --- gnu/testlet/SimpleTestHarness.java 13 Apr 2004 17:38:48 -0000 *************** public class SimpleTestHarness *** 51,54 **** --- 51,59 ---- } + + protected int getFailures() { + return failures; + } + public void check (boolean result) { Index: gnu/testlet/java/text/SimpleDateFormat/attribute.java =================================================================== RCS file: /cvs/mauve/mauve/gnu/testlet/java/text/SimpleDateFormat/attribute.java,v retrieving revision 1.1 diff -p -2 -c -r1.1 attribute.java *** gnu/testlet/java/text/SimpleDateFormat/attribute.java 24 Mar 2004 20:21:29 -0000 1.1 --- gnu/testlet/java/text/SimpleDateFormat/attribute.java 13 Apr 2004 17:38:48 -0000 *************** public class attribute implements Testle *** 158,170 **** SimpleDateFormat format = new SimpleDateFormat("yyyy.MM.dd hh:kk:mm:ss 'zone' zzzz"); Date date = new Date(); ! static Format.Field[] fields = new Format.Field[] { DateFormat.Field.YEAR, DateFormat.Field.MONTH, DateFormat.Field.DAY_OF_MONTH, DateFormat.Field.HOUR1, DateFormat.Field.HOUR_OF_DAY1, DateFormat.Field.MINUTE, DateFormat.Field.SECOND }; ! static int[] begin = new int[] { 0, 5, 8, /***/ 11, 14, 17, 20 }; ! static int[] end = new int[] { 4, 7, 10, /***/ 13, 16, 19, 22 }; --- 158,170 ---- SimpleDateFormat format = new SimpleDateFormat("yyyy.MM.dd hh:kk:mm:ss 'zone' zzzz"); Date date = new Date(); ! Format.Field[] fields = new Format.Field[] { DateFormat.Field.YEAR, DateFormat.Field.MONTH, DateFormat.Field.DAY_OF_MONTH, DateFormat.Field.HOUR1, DateFormat.Field.HOUR_OF_DAY1, DateFormat.Field.MINUTE, DateFormat.Field.SECOND }; ! int[] begin = new int[] { 0, 5, 8, /***/ 11, 14, 17, 20 }; ! int[] end = new int[] { 4, 7, 10, /***/ 13, 16, 19, 22 }; Index: gnu/testlet/javax/swing/JLabel/Icon.java =================================================================== RCS file: gnu/testlet/javax/swing/JLabel/Icon.java diff -N gnu/testlet/javax/swing/JLabel/Icon.java *** /dev/null 1 Jan 1970 00:00:00 -0000 --- gnu/testlet/javax/swing/JLabel/Icon.java 13 Apr 2004 17:38:48 -0000 *************** *** 0 **** --- 1,75 ---- + // Tags: JDK1.2 + + // Copyright (C) 2004 Thomas Zander + + // 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. + + package gnu.testlet.javax.swing.JLabel; + + import gnu.testlet.Testlet; + import gnu.testlet.TestHarness; + import java.util.EventListener; + import java.awt.*; + import javax.swing.*; + + /** + * These tests pass with the Sun JDK 1.4.1_03 on GNU/Linux IA-32. + */ + public class Icon implements Testlet { + public void test(TestHarness harness) { + MyIcon icon = new MyIcon(); + JLabel l = new JLabel(icon); + harness.check(l.getIcon(), icon); + harness.check(l.getDisabledIcon(), null); + l.setIcon(icon); + harness.check(l.getIcon(), icon); + harness.check(l.getDisabledIcon(), null); + + l = new JLabel(); + Dimension base = l.getPreferredSize(); + l.setIcon(icon); + Dimension one = l.getPreferredSize(); + harness.check(one.width, base.width + icon.getIconWidth()); + + l = new JLabel("bla"); + base = l.getPreferredSize(); + l.setIcon(icon); + one = l.getPreferredSize(); + harness.check(one.width, base.width + icon.getIconWidth() + l.getIconTextGap() ); + + l.setIconTextGap(100); + one = l.getPreferredSize(); + harness.check(one.width, base.width + icon.getIconWidth() + 100 ); + } + + private static class MyIcon implements javax.swing.Icon { + private int painted = 0; + public int getIconHeight() { + return 10; + } + public int getIconWidth() { + return 20; + } + public void paintIcon(Component c, Graphics g, int x, int y) { + painted++; + } + public int getPainted() { + return painted; + } + } + } Index: gnu/testlet/javax/swing/JLabel/Mnemonic.java =================================================================== RCS file: gnu/testlet/javax/swing/JLabel/Mnemonic.java diff -N gnu/testlet/javax/swing/JLabel/Mnemonic.java *** /dev/null 1 Jan 1970 00:00:00 -0000 --- gnu/testlet/javax/swing/JLabel/Mnemonic.java 13 Apr 2004 17:38:48 -0000 *************** *** 0 **** --- 1,61 ---- + // Tags: JDK1.2 + + // Copyright (C) 2004 Thomas Zander + + // 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. + + package gnu.testlet.javax.swing.JLabel; + + import gnu.testlet.Testlet; + import gnu.testlet.TestHarness; + import java.util.EventListener; + import javax.swing.JLabel; + + /** + * These tests pass with the Sun JDK 1.4.1_03 on GNU/Linux IA-32. + */ + public class Mnemonic implements Testlet { + public void test(TestHarness harness) { + JLabel l = new JLabel("lskdjnvmdsklzedfsdmnWK"); + harness.check(l.getDisplayedMnemonic(), 0); + harness.check(l.getDisplayedMnemonicIndex(), -1); + + l.setDisplayedMnemonic(java.awt.event.KeyEvent.VK_K); + harness.check(l.getDisplayedMnemonic(), java.awt.event.KeyEvent.VK_K); + harness.check(l.getDisplayedMnemonicIndex(), 2); + + l.setDisplayedMnemonic(java.awt.event.KeyEvent.VK_Q); + harness.check(l.getDisplayedMnemonicIndex(), -1); + + l.setDisplayedMnemonic(java.awt.event.KeyEvent.VK_W); + harness.check(l.getDisplayedMnemonicIndex(), 20); + + l.setText("new text"); + harness.check(l.getDisplayedMnemonicIndex(), 2); + + l.setDisplayedMnemonicIndex(5); + // the following test is really un-intuitive... Is this a bug in Suns JVM? + harness.check(l.getDisplayedMnemonic(), java.awt.event.KeyEvent.VK_W); // unchanged + harness.check(l.getDisplayedMnemonicIndex(), 5); + + l = new JLabel("new text"); + l.setDisplayedMnemonicIndex(5); + harness.check(l.getDisplayedMnemonic(), 0); + harness.check(l.getDisplayedMnemonicIndex(), 5); + } + } From zander@javalobby.org Tue Apr 13 18:59:00 2004 From: zander@javalobby.org (Thomas Zander) Date: Tue, 13 Apr 2004 18:59:00 -0000 Subject: Mauve patches. In-Reply-To: <16508.9997.393675.283091@cuddles.cambridge.redhat.com> References: <200404060956.14298.zander@javalobby.org> <200404131913.49935.zander@javalobby.org> <16508.9997.393675.283091@cuddles.cambridge.redhat.com> Message-ID: <200404132058.37587.zander@javalobby.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 13 April 2004 19:44, Andrew Haley wrote: > ?> > ?> Hmm; I kind of (really) like working in CVS, its like a net that > catches > you when you fail (and more). > ?> What about you commit first; then I can safely start to work on > adding > extra features. > > Alright. Thank you. > ?> I mean; all the questions I posed have been quietly been ignored, I'm > not > really under the impression Mauve is getting the attention it > deserves; I > honestly begin starting to wonder if putting it in a CVS > on sourceforge or > whereever, and more freely giving out CVS accounts > is such a bad idea. > > Actually, all the questions you posed have not quietly been ignored. > I have answered some of them. Indeed, I stand corrected, you did answer some of them. > ?> Some rights to commit and/or to clean up the webpages is the only > ?> thing standing in my way to really help make Mauve move forward! > > That and the fact that as yet you have not managed correctly to submit > a patch. ?I have attached a version here, FYI. > > I don't think I've broken anything with the checkin, but please check. Hmm; I'm wondering what was wrong with the last patch I sent; the only difference I see is that I failed to mention the new method in SimpleTestHarness, and the change in statics in SimpleDateFormat/attribute.java. Was it a bad choice to sent it as a bzip2 compressed patch? Anyway; you forgot this thingy: diff -U3 -p -N -r mauve-orig/.cvsignore mauve-new/.cvsignore - --- mauve-orig/.cvsignore 2004-04-03 17:59:23.000000000 +0200 +++ mauve-new/.cvsignore 2004-04-03 17:55:59.000000000 +0200 @@ -9,3 +9,5 @@ config.status dataoutput.out utf8test.out todos.txt +build +doc Cheers! - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAfDhcCojCW6H2z/QRAr6bAKC4sunY3qwseVScgx6QpTaIFrQOHwCgn2tD wI68OhAeY52gyBerWTLo7As= =WGVb -----END PGP SIGNATURE----- From crawley@dstc.edu.au Tue Apr 13 23:13:00 2004 From: crawley@dstc.edu.au (Stephen Crawley) Date: Tue, 13 Apr 2004 23:13:00 -0000 Subject: mauve ./ChangeLog gnu/testlet/java/lang/Charac ... In-Reply-To: Message from Mark Wielaard of "Mon, 12 Apr 2004 14:15:02 +0200." <1081772102.13170.567.camel@elsschot.wildebeest.org> Message-ID: <200404132313.i3DNDhT8029625@piglet.dstc.edu.au> Hi Mark, I've now checked in the missing update for CharInfo. -- Steve From billmc@agora.rdrop.com Wed Apr 14 00:09:00 2004 From: billmc@agora.rdrop.com (Bill McFadden) Date: Wed, 14 Apr 2004 00:09:00 -0000 Subject: Mauve patches. In-Reply-To: Your message of Tue, 13 Apr 2004 15:56:09 +0200. <200404131556.13282.zander@javalobby.org> Message-ID: <200404140009.i3E09RaJ047949@agora.rdrop.com> >Thomas wrote: >> David Lichteblau writes: >> Yes. I suppose Thomas' Ant script should do the right thing with >> respect to the tags. > >The selecting of files based on some 'tag in their content is quite easy in >ant; its a standard target. I could add an ant-build target that builds >based on tags. A build.xml that does the JDK1.1 tests would be terrific. I was unsuccessful building Mauve from the instructions in README, but Thomas's Ant script worked. -- Bill McFadden billmc@agora.rdrop.com http://www.rdrop.com/users/billmc CAUTION: Don't look into laser beam with remaining eye. From aph@redhat.com Wed Apr 14 09:56:00 2004 From: aph@redhat.com (Andrew Haley) Date: Wed, 14 Apr 2004 09:56:00 -0000 Subject: Mauve patches. In-Reply-To: <200404132058.37587.zander@javalobby.org> References: <200404060956.14298.zander@javalobby.org> <200404131913.49935.zander@javalobby.org> <16508.9997.393675.283091@cuddles.cambridge.redhat.com> <200404132058.37587.zander@javalobby.org> Message-ID: <16509.2724.862124.386156@cuddles.cambridge.redhat.com> Thomas Zander writes: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Tuesday 13 April 2004 19:44, Andrew Haley wrote: > >??I have attached a version here, FYI. > > > > I don't think I've broken anything with the checkin, but please check. > > Hmm; I'm wondering what was wrong with the last patch I sent; the only > difference I see is that I failed to mention the new method in > SimpleTestHarness, and the change in statics in > SimpleDateFormat/attribute.java. This is what you sent: diff -U3 -p -N -r mauve-orig/ChangeLog mauve/ChangeLog --- mauve-orig/ChangeLog 2004-04-03 17:59:25.000000000 +0200 +++ mauve/ChangeLog 2004-04-03 17:54:08.000000000 +0200 @@ -1,4 +1,17 @@ +2004-04-03 Thomas Zander + + * new files + gnu/testlet/javax/swing/JLabel/Icon.java, + gnu/testlet/javax/swing/JLabel/Mnemonic.java + +2004-04-03 Thomas Zander + + * added an ant build option so the autotools are not needed if you use + a fully functional JVM (for example for writing tests). + build.xml: ant build file + gnu/anttask/RunTests.java: ant task for calling SimpleTestHarness.java + This is what I did to make it right: 2004-04-13 Thomas Zander * build.xml: New file. * gnu/anttask/RunTests.java: New file. * gnu/testlet/SimpleTestHarness.java (getFailures): New method. * gnu/testlet/javax/swing/JLabel/Icon.java: New file. * gnu/testlet/javax/swing/JLabel/Mnemonic.java: New file. * gnu/testlet/java/text/SimpleDateFormat/attribute.java (test_FieldPos): Locals no longer static. See http://www.gnu.org/prep/standards_42.html#SEC42. Note in particular that Change Logs document only what, not why. Explanations should be comments in the program. > Was it a bad choice to sent it as a bzip2 compressed patch? Not always, but it does mean that reviewers are less likely to look at your patch straight away. > Anyway; you forgot this thingy: > > diff -U3 -p -N -r mauve-orig/.cvsignore mauve-new/.cvsignore Ah, yes. Thanks. Andrew. From mark@klomp.org Thu Apr 15 21:04:00 2004 From: mark@klomp.org (Mark Wielaard) Date: Thu, 15 Apr 2004 21:04:00 -0000 Subject: Mauve patch In-Reply-To: <200404061346.i36DkRdh019920@arch20m.dellroad.org> References: <200404061346.i36DkRdh019920@arch20m.dellroad.org> Message-ID: <1082063032.1986.7.camel@elsschot.wildebeest.org> Hi, On Tue, 2004-04-06 at 15:46, Archie Cobbs wrote: > This patch doesn't guarantee anything, and in general it's impossible > to make this test "correct" because the spec allows finalization and > reference enqueuing to happen after arbitrarily long delays. > > For example, a JVM that *never* finalizes is still within the spec > (it would probably throw OutOfMemoryError's more readily though). > > This patch simply makes the test "correct" for JC (and possibly > some other VM(s) out there). Since there's no way to *ensure* the > finalizer and reference enqueing thread(s) have run, we just try > to give them every opportunity to do so before declaring that their > work should be done. I committed it to mauve as follows since it doesn't break things for others and might actually help. 2004-04-15 Archie Cobbs * gnu/testlet/java/lang/ref/PhantomReference/phantom.java: Give the runtime some more hints (Thread.yield/System.gc) that it should really garbage collect. But a "non-portable" section in Mauve is also a good idea. It is just more work :) Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: phantom.patch Type: text/x-patch Size: 728 bytes Desc: not available URL: -------------- 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 mark@klomp.org Thu Apr 15 21:10:00 2004 From: mark@klomp.org (Mark Wielaard) Date: Thu, 15 Apr 2004 21:10:00 -0000 Subject: Mauve patches. In-Reply-To: <200404110848.06673.zander@javalobby.org> References: <200404060956.14298.zander@javalobby.org> <200404082150.24907.konqueror@gmx.de> <16501.44635.43431.486147@cuddles.cambridge.redhat.com> <200404110848.06673.zander@javalobby.org> Message-ID: <1082063426.1986.14.camel@elsschot.wildebeest.org> Hi Thomas, On Sun, 2004-04-11 at 08:48, Thomas Zander wrote: > Oh; and a explanation of the correct changelog format; or a link to that > since you said there was something wrong with it; but I don't know what. Look at the new and improved GNU Classpath Hackers Guide: (7.1 Documenting what changed when with ChangeLog entries) http://www.gnu.org/software/classpath/docs/hacking.html#SEC9 > Hope to hear from you; Mauve is growing way too slow for my taste this way. My apologies for not following up on this sooner. I am happy that Andrew helped you out. Your help is really appreciated. Especially since we are all short on time. So, please don't see the slow reactions as rejections of your work. I am really, really happy you want to pick this up and make it easier for others. Mauve is very important but indeed far to difficult to setup and hack on. 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 mark@klomp.org Thu Apr 15 22:14:00 2004 From: mark@klomp.org (Mark Wielaard) Date: Thu, 15 Apr 2004 22:14:00 -0000 Subject: Some issues.. In-Reply-To: <200404031504.41093.zander@javalobby.org> References: <200404031504.41093.zander@javalobby.org> Message-ID: <1082067248.1986.45.camel@elsschot.wildebeest.org> Hi, On Sat, 2004-04-03 at 15:04, Thomas Zander wrote: > Hmm; > I spent a couple of days running with the snapshot which I downloaded from > the webpage (http://sources.redhat.com/mauve/) until I found out is _very_ > far from recent (which the 'snapshot' seemed to imply) > I must say its pretty bad that the snapshot is over a year old!! > I suggest to remote the snapshot; or have up-to-date versions created > nightly. So sorry about that. I asked around and Tom will install a script on sources to make sure we get fresh snapshots up again. (Thanks Tom!) > I looked at the homepage and found a 'breaking news' that I found rather > dubious; it looks like its been there for ages since the 'sidebar' does > not work (on either konqueror or on mozilla), the 'logo design' leads to a > dead link, the 'contribute' page is empty.. We really need to update the website. If someone wants to then they can get the website files with: cvs -d :pserver:anoncvs@sources.redhat.com:/cvs/mauve checkout htdocs BTW see http://sources.redhat.com/cgi-bin/cvsweb.cgi/?cvsroot=mauve for other modules like verify and "wonka" (the visual test engine). > Please make the project seem 'less dead' to the passing eye!! If Red-hat > does not do anything; what about moving the project to sourceforge or > savannah ?? It isn't really Red Hat not doing things. They are just hosting the project. Like sourceforge or savnnah would do. We need people to actually work on the pages (and complain loudly on the mailing list) to make the project seem less dead. (And thanks again for yelling and screaming, we have been a bit neglecting the appearance of the project.) > if this is a mailinglist; please cc answers! CCed. But please join the list! 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 mark@klomp.org Thu Apr 15 22:22:00 2004 From: mark@klomp.org (Mark Wielaard) Date: Thu, 15 Apr 2004 22:22:00 -0000 Subject: Some issues.. In-Reply-To: <16494.56084.958410.241061@cuddles.cambridge.redhat.com> References: <200404031504.41093.zander@javalobby.org> <16494.47358.415834.600012@cuddles.cambridge.redhat.com> <200404031540.39350.zander@javalobby.org> <16494.56084.958410.241061@cuddles.cambridge.redhat.com> Message-ID: <1082067738.1986.49.camel@elsschot.wildebeest.org> Hi, On Sat, 2004-04-03 at 17:41, Andrew Haley wrote: > Thomas Zander writes: > > Second; I found at least one directory that contains java files without a > > package; leading it to be uncompilable (due to duplicate class names) > > I found: > > gnu/testlet/BinaryCompatibility/altered/ > > Should those have package lines?? > > No. This package comes with a script that does the building and > copies some files around. I suppose you could create a Ant version of > this script. Which script is this? Is it documented? Might it be a good idea to add these tests to a separate module like the visual tester and the verifier tests since they are actually different from the rest of the mauve core library tests? 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 mark@klomp.org Thu Apr 15 22:56:00 2004 From: mark@klomp.org (Mark Wielaard) Date: Thu, 15 Apr 2004 22:56:00 -0000 Subject: Mauve patches. In-Reply-To: <20040411185745.GD21097@lichteblau.com> References: <200404060956.14298.zander@javalobby.org> <200404110848.06673.zander@javalobby.org> <20040411122255.GC21097@lichteblau.com> <200404111919.24816.zander@javalobby.org> <20040411185745.GD21097@lichteblau.com> Message-ID: <1082069767.1986.76.camel@elsschot.wildebeest.org> Hi, On Sun, 2004-04-11 at 20:57, David Lichteblau wrote: > Quoting Thomas Zander (zander@javalobby.org): > > On Sunday 11 April 2004 14:22, David Lichteblau wrote: > > > Quoting Thomas Zander (zander@javalobby.org): > > > > I hope you'll agree that its more important to have people creating > > > > patches and moving the project forward then to always have a 100% > > > > correct CVS. (problems can be fixed post-commit) > > > No! > > > > would you care to elaborate on your position? > > Sure: "Problems should be fixed pre-commit." I agree. Mauve is actually used daily by people (me). And some people even use it in autobuilders/testers which are updated from CVS. > BTW, to ask a technical question, is the "tagging" of Mauve testcases > used in practice? Much of the complexity of the existing build systems > stems from the fact that tests are selected by a non-trivial script. If > not for the tags, something like "find . -name \*.java" would be enough > to select all files. There are Tags to select which test (sets) you want to run. But also Uses which declare what a test depends on. That is needed to make sure you compile all java source files needed and only those files. > Mark Wielaard sent an analysis of test suite failures for current > Classpath, which I found very helpful (thanks!). When I am interested > to see whether the current Classpath version "works", which tags should > be used? All of them, right? Yes. I am using: KEYS="JDK1.0 JDK1.1 JDK1.2 JDK1.3 JDK1.4 JLS1.0 JLS1.2 JDBC1.0 JDBC2.0 JAVA2" And I used to add !java.lang.Character.unicode since that was broken till next week (thanks Stephan!). > Unless I misunderstood Thomas' question, he could not compile all of > Mauve because his script tried to compile _everything_, as opposed to > those files usually chosen by the standard build system. I would find > it a little confusing if Mauve provided two build systems, one which > uses tags and one which does not. Actually Mauve already provides two mechanism. I secretly (well, there is a changelog entry and some discussion on the mailinglist) added a second method last year. The way the Makefile works does indeed try to compile everything you tagged/choose at once and then run all those tests in one go. I added a little batch_run and runner (bash shell) script that actually uses the choose script to compile each test (and dependent source file) separately and then run each test separately (installing a timer to catch a hanging runtime). Unfortunately I never documented that in the README. And it also doesn't work nicely with the configure script. You actually have to edit the used compiler (COMPILER) in batch_run and the used runtime (RUNTIME) in runner. But it is nice for those times that a test doesn't compile or hangs/crashed the runtime, then you just get one failure and the rest of the tests are still run. (There is actually even a third build system for mauve. It is embedded in an expect script inside libgcj gcc/libjava/testsuite that does kind of what the above shell script does, but then runs each test both with a traditional byte code interpreter and compiled as native code.) 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 aph@redhat.com Fri Apr 16 09:31:00 2004 From: aph@redhat.com (Andrew Haley) Date: Fri, 16 Apr 2004 09:31:00 -0000 Subject: Some issues.. In-Reply-To: <1082067738.1986.49.camel@elsschot.wildebeest.org> References: <200404031504.41093.zander@javalobby.org> <16494.47358.415834.600012@cuddles.cambridge.redhat.com> <200404031540.39350.zander@javalobby.org> <16494.56084.958410.241061@cuddles.cambridge.redhat.com> <1082067738.1986.49.camel@elsschot.wildebeest.org> Message-ID: <16511.42905.101387.569375@cuddles.cambridge.redhat.com> Mark Wielaard writes: > Hi, > > On Sat, 2004-04-03 at 17:41, Andrew Haley wrote: > > Thomas Zander writes: > > > Second; I found at least one directory that contains java files without a > > > package; leading it to be uncompilable (due to duplicate class names) > > > I found: > > > gnu/testlet/BinaryCompatibility/altered/ > > > Should those have package lines?? > > > > No. This package comes with a script that does the building and > > copies some files around. I suppose you could create a Ant version of > > this script. > > Which script is this? Err, the one in the BinaryCompatibility directory... It's called `foo', of course! :-) > Is it documented? Yeah, right. > Might it be a good idea to add these tests to a separate module > like the visual tester and the verifier tests since they are > actually different from the rest of the mauve core library tests? Can you please be a little more specific about this? Andrew. From mark@klomp.org Fri Apr 16 11:29:00 2004 From: mark@klomp.org (Mark Wielaard) Date: Fri, 16 Apr 2004 11:29:00 -0000 Subject: Some issues.. In-Reply-To: <16511.42905.101387.569375@cuddles.cambridge.redhat.com> References: <200404031504.41093.zander@javalobby.org> <16494.47358.415834.600012@cuddles.cambridge.redhat.com> <200404031540.39350.zander@javalobby.org> <16494.56084.958410.241061@cuddles.cambridge.redhat.com> <1082067738.1986.49.camel@elsschot.wildebeest.org> <16511.42905.101387.569375@cuddles.cambridge.redhat.com> Message-ID: <1082114942.1971.9.camel@elsschot.wildebeest.org> Hi, On Fri, 2004-04-16 at 11:30, Andrew Haley wrote: > Mark Wielaard writes: > > Which script is this? > > Err, the one in the BinaryCompatibility directory... > > It's called `foo', of course! :-) Aha. Wow. I never found that before. Ehe, how do you use/invoke it? I tried setting JAVA/JAVAC/GCJ as variables before invoking foo, but in all cases it fails in weird and wonderful ways either compiling or running. One issue seems to be that it does want the gnu/testlet/*.java files, but this is never specified in its classpath or sourcepath. > > Is it documented? > > Yeah, right. :) I admit to be guilty of not documenting my batch_run and runner script. But a little blurb in the README wouldn't hurt. If I promise to add something about my scripts, could you add something about yours? At least how to invoke the thing... > > Might it be a good idea to add these tests to a separate module > > like the visual tester and the verifier tests since they are > > actually different from the rest of the mauve core library tests? > > Can you please be a little more specific about this? Since it seem to not be integrated with the rest of the tests (but I might be wrong about this since I couldn't get them working at all) it might make sense to but it into their own module. Like the verifier tests and the visual test engine (CVS modules verify and wonka). It seems this binary compatibility test is useful on its own without any dependency on the core library tests so we might want to promote it to its own CVS module that people can just use without worrying about all the rest. And it would add a new bullet point on the website which makes the project seem more alive :) 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 mark@klomp.org Fri Apr 16 12:01:00 2004 From: mark@klomp.org (Mark Wielaard) Date: Fri, 16 Apr 2004 12:01:00 -0000 Subject: Some issues.. (batch_run and runner script documentation) In-Reply-To: <1082114942.1971.9.camel@elsschot.wildebeest.org> References: <200404031504.41093.zander@javalobby.org> <16494.47358.415834.600012@cuddles.cambridge.redhat.com> <200404031540.39350.zander@javalobby.org> <16494.56084.958410.241061@cuddles.cambridge.redhat.com> <1082067738.1986.49.camel@elsschot.wildebeest.org> <16511.42905.101387.569375@cuddles.cambridge.redhat.com> <1082114942.1971.9.camel@elsschot.wildebeest.org> Message-ID: <1082116861.1971.13.camel@elsschot.wildebeest.org> Hi, On Fri, 2004-04-16 at 13:29, Mark Wielaard wrote: > On Fri, 2004-04-16 at 11:30, Andrew Haley wrote: > > Mark Wielaard writes: > > > Is it documented? > > > > Yeah, right. > > :) > I admit to be guilty of not documenting my batch_run and runner script. > But a little blurb in the README wouldn't hurt. > If I promise to add something about my scripts, could you add something > about yours? At least how to invoke the thing... OK. I added the following to README: +An alternative way to compiling and running all tests is the batch_run +script. This makes it easy to run all test in one batch without worrying +wheter all tests compile and/or running them crashes or hangs the runtime. + +batch_run and the runner helper script aren't integrated with the configure +setup yet so you will have to edit them by hand to explicitly set the +COMPILER variable in batch_run and the RUNTIME variable in runner. +Optionally you can also change the KEYS setting in batch_run if you don't +want to run all tests. You can also set the variable NATIVE=true in +batch_run when you want to use gcj (without -C) in native mode. + +When a test cannot be compiled with the given COMPILER batch_run will +output FAIL: COMPILE FAILED and go on with the next test. +If the runner detects a runtime crash or timeout (runner variable +WAIT=60 seconds) it will output FAIL: CRASH or TIMEOUT. 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 aph@redhat.com Fri Apr 16 12:04:00 2004 From: aph@redhat.com (Andrew Haley) Date: Fri, 16 Apr 2004 12:04:00 -0000 Subject: Some issues.. In-Reply-To: <1082114942.1971.9.camel@elsschot.wildebeest.org> References: <200404031504.41093.zander@javalobby.org> <16494.47358.415834.600012@cuddles.cambridge.redhat.com> <200404031540.39350.zander@javalobby.org> <16494.56084.958410.241061@cuddles.cambridge.redhat.com> <1082067738.1986.49.camel@elsschot.wildebeest.org> <16511.42905.101387.569375@cuddles.cambridge.redhat.com> <1082114942.1971.9.camel@elsschot.wildebeest.org> Message-ID: <16511.52090.696553.529257@cuddles.cambridge.redhat.com> Mark Wielaard writes: > Hi, > > On Fri, 2004-04-16 at 11:30, Andrew Haley wrote: > > Mark Wielaard writes: > > > Which script is this? > > > > Err, the one in the BinaryCompatibility directory... > > > > It's called `foo', of course! :-) > > Aha. Wow. I never found that before. > Ehe, how do you use/invoke it? It gets invoked automatically when you run Mauve, at least on my system. BinaryCompatibilityTest.java is the driver that invokes it. > I tried setting JAVA/JAVAC/GCJ as variables before invoking foo, but in > all cases it fails in weird and wonderful ways either compiling or > running. One issue seems to be that it does want the gnu/testlet/*.java > files, but this is never specified in its classpath or sourcepath. Well, I can't really understand the problem. BinaryCompatibilityTest.java is tagged JDK1.1, so it gets run along with the rest of Mauve. It then does all the grunt work and runs the test. So, if it fails, something else is wrong. > > > Is it documented? > > > > Yeah, right. > > :) > I admit to be guilty of not documenting my batch_run and runner script. > But a little blurb in the README wouldn't hurt. > If I promise to add something about my scripts, could you add something > about yours? At least how to invoke the thing... > > > > Might it be a good idea to add these tests to a separate module > > > like the visual tester and the verifier tests since they are > > > actually different from the rest of the mauve core library tests? > > > > Can you please be a little more specific about this? > > Since it seem to not be integrated with the rest of the tests (but I > might be wrong about this since I couldn't get them working at all) It is, it is! I want it to be run whenever we run Mauve. Andrew. From green@redhat.com Fri Apr 16 20:23:00 2004 From: green@redhat.com (Anthony Green) Date: Fri, 16 Apr 2004 20:23:00 -0000 Subject: Mauve patches. In-Reply-To: <1081743135.3175.18.camel@lyta.haphazard.org> References: <200404060956.14298.zander@javalobby.org> <200404111919.24816.zander@javalobby.org> <20040411185745.GD21097@lichteblau.com> <200404112136.52657.zander@javalobby.org> <1081743135.3175.18.camel@lyta.haphazard.org> Message-ID: <1082146987.3559.71.camel@escape> On Sun, 2004-04-11 at 21:12, C. Brian Jones wrote: > * Cannot be installed (packaged, used repeatedly for various cases from > same install) I'm not sure why you would want to "install" mauve. I guess I'm too used to how we use Mauve with libgcj. > * No integrated pass/fail/expected/unexpected summary The Big Idea was that different projects would have different QA infrastructure requirements, which would be satisfied by writing system specific test harnesses. So, for instance, we have a dejagnu specific test harness in the libgcj source tree. > * Repeated executions require knowing inner workings of > various scripts Again, this may be a result of our assumption that the core Mauve infrastructure would be augmented by project specific infrastructure. > * Integration of additional libraries difficult at best > * Integration of VM specific tests also difficult > > Solutions > > * Change configure script to be installation oriented, similar for > Makefile.am (started this already) > * New script(s) for running mauve to compile, execute, report > results (consider using dejagnu) > * Specify java compiler at runtime > * Specify vm at runtime > * Specify temporary directory at runtime > * Specify additional libraries/resources at runtime > * Specify additional tests at runtime Are you doing this for a specific system, or for stand-alone Mauve usage? > Basically all the cruft and gorp in configure.in, Makefile.am, choose, > etc. gets done over. The TAGS system is broken, it doesn't allow one to > specify that a particular test is only valid for 1.1, 1.2, 1.3 and not > 1.4+, essential to handle deprecated methods that eventually get > removed. I have no problem doing this work, my problem is all the > people that depend on the current directory structure, build process, > etc. that will scream if something is changed. Anyway I have started > the work, when I have a patch I'll let the list review. Don't hold your > breath, I'm slow sometimes. :) FWIW, I don't feel strongly about the stand-alone Mauve infrastructure as long as the libgcj usage doesn't break (see gcc/libjava/testsuite/libjava.mauve). AG -- Anthony Green Red Hat, Inc. From tromey@redhat.com Fri Apr 16 20:27:00 2004 From: tromey@redhat.com (Tom Tromey) Date: Fri, 16 Apr 2004 20:27:00 -0000 Subject: snapshots Message-ID: <8765bzsmpm.fsf@fleche.redhat.com> Hi folks. At Mark's request, I've set up nightly Mauve snapshots. You can find them at: ftp://sources.redhat.com/pub/mauve/snapshot/mauve-nightly.tar.bz2 ftp://sources.redhat.com/pub/mauve/snapshot/mauve-nightly.zip (These have the same contents, but the bz2 is much smaller...) Tom From cbj@gnu.org Fri Apr 16 22:57:00 2004 From: cbj@gnu.org (C. Brian Jones) Date: Fri, 16 Apr 2004 22:57:00 -0000 Subject: Mauve patches. In-Reply-To: <1082146987.3559.71.camel@escape> References: <200404060956.14298.zander@javalobby.org> <200404111919.24816.zander@javalobby.org> <20040411185745.GD21097@lichteblau.com> <200404112136.52657.zander@javalobby.org> <1081743135.3175.18.camel@lyta.haphazard.org> <1082146987.3559.71.camel@escape> Message-ID: <1082156245.3175.49.camel@lyta.haphazard.org> Thanks for your comments Anthony! On Fri, 2004-04-16 at 16:23, Anthony Green wrote: > On Sun, 2004-04-11 at 21:12, C. Brian Jones wrote: > > * Cannot be installed (packaged, used repeatedly for various cases from > > same install) > > I'm not sure why you would want to "install" mauve. I guess I'm too > used to how we use Mauve with libgcj. I want to be able to run it against gcj, gij, kissme, kaffe, sablevm, jamvm, jdk, etc. Not really all at once, just depending on what I'm using at the time. I don't think the clean, reconfigure, make dance is appropriate for this task. > > * No integrated pass/fail/expected/unexpected summary > > The Big Idea was that different projects would have different QA > infrastructure requirements, which would be satisfied by writing system > specific test harnesses. So, for instance, we have a dejagnu specific > test harness in the libgcj source tree. Nothing wrong with that, but it wouldn't hurt to provide something out of the box would it? > > * Repeated executions require knowing inner workings of > > various scripts > > Again, this may be a result of our assumption that the core Mauve > infrastructure would be augmented by project specific infrastructure. It's pretty nasty. I have a feeling it turns some people away when it isn't very clear how to set it up, run it, add or modify a test, and re-run it. > > * Integration of additional libraries difficult at best > > * Integration of VM specific tests also difficult > > > > Solutions > > > > * Change configure script to be installation oriented, similar for > > Makefile.am (started this already) > > * New script(s) for running mauve to compile, execute, report > > results (consider using dejagnu) > > * Specify java compiler at runtime > > * Specify vm at runtime > > * Specify temporary directory at runtime > > * Specify additional libraries/resources at runtime > > * Specify additional tests at runtime > > Are you doing this for a specific system, or for stand-alone Mauve > usage? The intention is for standalone use. Although one could probably keep the Makefile.am/configure as-is, it would clean things up considerably to move such their current functionality into a re-usable script. > > Basically all the cruft and gorp in configure.in, Makefile.am, choose, > > etc. gets done over. The TAGS system is broken, it doesn't allow one to > > specify that a particular test is only valid for 1.1, 1.2, 1.3 and not > > 1.4+, essential to handle deprecated methods that eventually get > > removed. I have no problem doing this work, my problem is all the > > people that depend on the current directory structure, build process, > > etc. that will scream if something is changed. Anyway I have started > > the work, when I have a patch I'll let the list review. Don't hold your > > breath, I'm slow sometimes. :) > > FWIW, I don't feel strongly about the stand-alone Mauve infrastructure > as long as the libgcj usage doesn't break (see > gcc/libjava/testsuite/libjava.mauve). Right, I have a feeling that to do what I want I'd have to modify some part of this though probably not a great deal as long as tests can still be executed without installing. Brian -------------- 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 zander@javalobby.org Sat Apr 17 14:45:00 2004 From: zander@javalobby.org (Thomas Zander) Date: Sat, 17 Apr 2004 14:45:00 -0000 Subject: Mauve patches. In-Reply-To: <1082069767.1986.76.camel@elsschot.wildebeest.org> References: <200404060956.14298.zander@javalobby.org> <20040411185745.GD21097@lichteblau.com> <1082069767.1986.76.camel@elsschot.wildebeest.org> Message-ID: <200404171644.21352.zander@javalobby.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 16 April 2004 00:56, you wrote: > > > > > I hope you'll agree that its more important to have people > > > > > creating patches and moving the project forward then to always > > > > > have a 100% correct CVS. (problems can be fixed post-commit) > > > > > > > > No! > > > > > > would you care to elaborate on your position? > > > > Sure: "Problems should be fixed pre-commit." > > I agree. Mauve is actually used daily by people (me). And some people > even use it in autobuilders/testers which are updated from CVS. Hmm, I should have been more clear then. I naturally always will keep things compiling (one of the fixes I had was to get it compiling with suns Javac, for example). I would never change the content of a class significantly without prior consent on the list. The problems I 'expect' will be formatting things and other little things that I miss due to my different background. I put the "expect" between quotes because its not like I feel these things will happen; its just a saveguard for the rest of the team that if I commit something thats not up to spec; feel free to change it. So I repeat my request for a cvs account.. Cheers! - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAgULBCojCW6H2z/QRAiAXAJ9b232cutzP1a24L1iSRgn34I6pJQCffqAd UMwMzP7qKpews57QPh0jN/4= =Hd8X -----END PGP SIGNATURE----- From mark@klomp.org Thu Apr 22 21:41:00 2004 From: mark@klomp.org (Mark Wielaard) Date: Thu, 22 Apr 2004 21:41:00 -0000 Subject: Some issues.. In-Reply-To: <16511.52090.696553.529257@cuddles.cambridge.redhat.com> References: <200404031504.41093.zander@javalobby.org> <16494.47358.415834.600012@cuddles.cambridge.redhat.com> <200404031540.39350.zander@javalobby.org> <16494.56084.958410.241061@cuddles.cambridge.redhat.com> <1082067738.1986.49.camel@elsschot.wildebeest.org> <16511.42905.101387.569375@cuddles.cambridge.redhat.com> <1082114942.1971.9.camel@elsschot.wildebeest.org> <16511.52090.696553.529257@cuddles.cambridge.redhat.com> Message-ID: <1082669893.27234.160.camel@elsschot.wildebeest.org> Hi, On Fri, 2004-04-16 at 14:03, Andrew Haley wrote: > Mark Wielaard writes: > > Ehe, how do you use/invoke it? > > It gets invoked automatically when you run Mauve, at least on my > system. BinaryCompatibilityTest.java is the driver that invokes it. Aha. And it uses Runtime.exec()... Which wasn't properly implemented in GNU Classpath proper. But we have it now (almost)! ow that I can run it I see that kaffe, jamvm and gij all fail most of the tests. Each of IL bin_01 till IL bin_18 fails 5 or 6 times giving: 107 of 125 tests failed Do you get better/other results? 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 jeroen@sumatra.nl Fri Apr 23 09:12:00 2004 From: jeroen@sumatra.nl (Jeroen Frijters) Date: Fri, 23 Apr 2004 09:12:00 -0000 Subject: Some issues.. Message-ID: <788B535AB1F9CB49BB9C229372B50ACC0ADEA3@LEMBU.sumatrasoftware.com> Mark Wielaard wrote: > On Fri, 2004-04-16 at 14:03, Andrew Haley wrote: > > Mark Wielaard writes: > > > Ehe, how do you use/invoke it? > > > > It gets invoked automatically when you run Mauve, at least on my > > system. BinaryCompatibilityTest.java is the driver that invokes it. > > Aha. And it uses Runtime.exec()... Which wasn't properly > implemented in GNU Classpath proper. But we have it now (almost)! > > ow that I can run it I see that kaffe, jamvm and gij all fail most of > the tests. Each of IL bin_01 till IL bin_18 fails 5 or 6 times giving: > 107 of 125 tests failed I never really payed attention to this test, but now I see that it is *nix specific (using shell script ). What is the policy for Mauve? I realise most of you don't care about/for Windows, but personally I do. So I support Mark's earlier suggestion/request to move this to a separate section. On a somewhat related note, the invalid_port test in DatagramSocketTest2 assumes that it is illegal to create a DatagramSocket that listens on port 21, but I don't believe that is part of the Java specification. Regards, Jeroen From mark@klomp.org Sun Apr 25 11:10:00 2004 From: mark@klomp.org (Mark Wielaard) Date: Sun, 25 Apr 2004 11:10:00 -0000 Subject: Some issues.. In-Reply-To: <788B535AB1F9CB49BB9C229372B50ACC0ADEA3@LEMBU.sumatrasoftware.com> References: <788B535AB1F9CB49BB9C229372B50ACC0ADEA3@LEMBU.sumatrasoftware.com> Message-ID: <1082891420.27234.1377.camel@elsschot.wildebeest.org> Hi, On Fri, 2004-04-23 at 11:11, Jeroen Frijters wrote: > Mark Wielaard wrote: > > On Fri, 2004-04-16 at 14:03, Andrew Haley wrote: > > > Mark Wielaard writes: > > > > Ehe, how do you use/invoke it? > > > > > > It gets invoked automatically when you run Mauve, at least on my > > > system. BinaryCompatibilityTest.java is the driver that invokes it. > > > > Aha. And it uses Runtime.exec()... Which wasn't properly > > implemented in GNU Classpath proper. But we have it now (almost)! > > > > ow that I can run it I see that kaffe, jamvm and gij all fail most of > > the tests. Each of IL bin_01 till IL bin_18 fails 5 or 6 times giving: > > 107 of 125 tests failed > > I never really payed attention to this test, but now I see that it is > *nix specific (using shell script ). > > What is the policy for Mauve? I realise most of you don't care about/for > Windows, but personally I do. So I support Mark's earlier > suggestion/request to move this to a separate section. There is always Cygwin But I do think it might be better to separate out this test from the rest of Mauve proper. On the other hand, if you have a non-GNUish/Posix system then you can always disable this one test. Separating it out without a mechanism for running the tests on multiple systems isn't really worth it I guess. > On a somewhat related note, the invalid_port test in DatagramSocketTest2 > assumes that it is illegal to create a DatagramSocket that listens on > port 21, but I don't believe that is part of the Java specification. I believe you are right. It is only an issue for processes without enough privileges on some systems (which normally reserve all post between 0 and 1024 for "system" services). So I committed this patch: 2004-04-25 Mark Wielaard * gnu/testlet/java/net/DatagramSocket/DatagramSocketTest2.java: Remove RESERVED_PORT (21) test. Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: patch Type: text/x-patch Size: 1319 bytes Desc: not available URL: -------------- 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 zander@javalobby.org Sun Apr 25 12:29:00 2004 From: zander@javalobby.org (Thomas Zander) Date: Sun, 25 Apr 2004 12:29:00 -0000 Subject: [PATCH] tags-fixes. Message-ID: <200404251428.10760.zander@javalobby.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 See attached patch; it fixes a couple of files where a) JDK1.2 and JAVA2 were both used (and since the latter implies the former, thats a duplicate). b) some files had tags that are not documented/used anywhere, so I replaced them with ones that are. I'm not 100% sure this is correct; please give me feedback. 2004-04-25 Thomas Zander * gnu/testlet/java/beans/Introspector/jdk12.java: remove duplicate tag * gnu/testlet/java/net/DatagramSocket/DatagramSocketTest2.java gnu/testlet/java/security/AlgorithmParameterGenerator/MauveAlgorithm.java gnu/testlet/java/security/AlgorithmParameters/MauveAlgorithm.java gnu/testlet/java/security/KeyFactory/MauveAlgorithm.java gnu/testlet/java/security/KeyPairGenerator/MauveAlgorithm.java: fix tag - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAi67ZCojCW6H2z/QRApJOAKDIVV9BLdPGUVfMPjn9NHbGgZcJpQCdFacM AbFmHuYCwbF3GdNrtWIwW8Y= =7uiH -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: tagFixes.diff Type: text/x-diff Size: 4408 bytes Desc: not available URL: From zander@javalobby.org Sun Apr 25 12:30:00 2004 From: zander@javalobby.org (Thomas Zander) Date: Sun, 25 Apr 2004 12:30:00 -0000 Subject: [PATCH] teach ant to use the mauve-tagsystem Message-ID: <200404251429.45299.zander@javalobby.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Subject says it all.. 2004-04-25 Thomas Zander * gnu/anttask/RunTests: Add javadoc, add setSrcdir, setTestJDK, setTestJDBC * build.xml: fix typo, use new flags srcdir, testjdk, testjdbc Please commit. - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAi68uCojCW6H2z/QRArgSAJ90lQuulIPCRZoyl0ag/HbDq74eTwCfed1e 6Qj15c2gjDCJvCL0aKGZL3M= =BtQ7 -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: ant-feature.diff Type: text/x-diff Size: 10627 bytes Desc: not available URL: From tromey@redhat.com Wed Apr 28 20:02:00 2004 From: tromey@redhat.com (Tom Tromey) Date: Wed, 28 Apr 2004 20:02:00 -0000 Subject: Eclipse and Classpath In-Reply-To: References: Message-ID: <877jvzhoef.fsf@fleche.redhat.com> Jeff> (What about Mauve? Much of Eclipse's usefulness for us comes from Jeff> interactively running the test suite so we get a very quick Jeff> edit/compile/test/debug cycle. But eclipse only knows about junit-style Jeff> tests, not the gnu.testlet classes in Mauve.) I think Graydon changed Mauve to use JUnit at one point, but it never went in. I think there was some confusion about some points I made. It's time to revisit this (various folks pointed this out to me at the recent RH meeting). IMO anything that makes Mauve easier to hack is a good thing. My only real requirement is that we still be able to run the gcj test suite; I don't think there is any substantial problem here. Tom From zander@javalobby.org Wed Apr 28 21:56:00 2004 From: zander@javalobby.org (Thomas Zander) Date: Wed, 28 Apr 2004 21:56:00 -0000 Subject: Eclipse and Classpath In-Reply-To: <877jvzhoef.fsf@fleche.redhat.com> References: <877jvzhoef.fsf@fleche.redhat.com> Message-ID: <200404282354.50797.zander@javalobby.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 28 April 2004 21:51, Tom Tromey wrote: > Jeff> (What about Mauve? Much of Eclipse's usefulness for us comes from > Jeff> interactively running the test suite so we get a very quick > Jeff> edit/compile/test/debug cycle. But eclipse only knows about > junit-style Jeff> tests, not the gnu.testlet classes in Mauve.) > > I think Graydon changed Mauve to use JUnit at one point, but it never > went in. I think there was some confusion about some points I made. > > It's time to revisit this (various folks pointed this out to me at the > recent RH meeting). IMO anything that makes Mauve easier to hack is a > good thing. My only real requirement is that we still be able to run > the gcj test suite; I don't think there is any substantial problem > here. IIRC the biggest problem with using JUnit is that it depends of rather advanced JVM features; like reflection. Its technically possible to have a mauve test case extend a mauve-base-class which can be changed on run-time (probably using a singleton) to either use the very-simple-mauve test framework, or the JUnit ones. Using a facade pattern in that baseclass. Its still needed to call each test in one long test() method if you want to use the mauve version, but other then that it would integrate with JUnit quite nicely. Naturally all tests will need to be refactored to do this.. - - extending a base class instead of implementing Testlet - - using the assertTrue() style checking instead of the check() versions. Thoughts? - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAkCgpCojCW6H2z/QRAp0LAKCxgcsGMzDHdMPDDVDTPUBNPCQjGgCgkU8j qAf1uGZxFCYoTpSJreFpitY= =nRwQ -----END PGP SIGNATURE----- From archie@dellroad.org Wed Apr 28 22:54:00 2004 From: archie@dellroad.org (Archie Cobbs) Date: Wed, 28 Apr 2004 22:54:00 -0000 Subject: Eclipse and Classpath In-Reply-To: Message-ID: <200404282250.i3SMoiuV003364@arch20m.dellroad.org> David P Grove wrote: > > IIRC the biggest problem with using JUnit is that it depends of rather > > advanced JVM features; like reflection. > > Sorry if this is an ignorant question, but is this really an issue? I'd > always assumed (without actually checking) that most (all?) of the VMs > being used by classpath developers implement reflection. If this is the > case, then maybe making reflection a pre-req for being able to run mauve > wouldn't be an issue. It's hard to run very much Java code these days > without running into some use of reflection by the application. I inferred the problem to be that reflection is one of the things we want to test, so we shouldn't be relying on it for the test itself. Of course, if reflection doesn't work, then the test will probably still fail :-) But it may make it harder to track down the real problem. All in all, it's probably not a major deal... Perhaps there could be a small set of basic reflection tests that didn't use JUnit too. -Archie __________________________________________________________________________ Archie Cobbs * CTO, Awarix * http://www.awarix.com From cbj@gnu.org Thu Apr 29 05:09:00 2004 From: cbj@gnu.org (C. Brian Jones) Date: Thu, 29 Apr 2004 05:09:00 -0000 Subject: Eclipse and Classpath In-Reply-To: <200404282250.i3SMoiuV003364@arch20m.dellroad.org> References: <200404282250.i3SMoiuV003364@arch20m.dellroad.org> Message-ID: <1083215334.3175.104.camel@lyta.haphazard.org> On Wed, 2004-04-28 at 18:50, Archie Cobbs wrote: > David P Grove wrote: > > > IIRC the biggest problem with using JUnit is that it depends of rather > > > advanced JVM features; like reflection. > > > > Sorry if this is an ignorant question, but is this really an issue? I'd > > always assumed (without actually checking) that most (all?) of the VMs > > being used by classpath developers implement reflection. If this is the > > case, then maybe making reflection a pre-req for being able to run mauve > > wouldn't be an issue. It's hard to run very much Java code these days > > without running into some use of reflection by the application. > > I inferred the problem to be that reflection is one of the things > we want to test, so we shouldn't be relying on it for the test itself. > Of course, if reflection doesn't work, then the test will probably > still fail :-) But it may make it harder to track down the real problem. > > All in all, it's probably not a major deal... Perhaps there could be > a small set of basic reflection tests that didn't use JUnit too. Junit does not require reflection if used in a particular manner. See http://junit.sourceforge.net/doc/testinfected/testing.htm. But it's probably easier all around if reflection is allowed. JUnit supports two ways of running single tests: * static * dynamic In the static way you override the runTest method inherited from TestCase and call the desired test case. A convenient way to do this is with an anonymous inner class. Note that each test must be given a name, so you can identify it if it fails. TestCase test= new MoneyTest("simple add") { public void runTest() { testSimpleAdd(); } }; -------------- 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 aph@redhat.com Thu Apr 29 11:41:00 2004 From: aph@redhat.com (Andrew Haley) Date: Thu, 29 Apr 2004 11:41:00 -0000 Subject: Some issues.. In-Reply-To: <1082891420.27234.1377.camel@elsschot.wildebeest.org> References: <788B535AB1F9CB49BB9C229372B50ACC0ADEA3@LEMBU.sumatrasoftware.com> <1082891420.27234.1377.camel@elsschot.wildebeest.org> Message-ID: <16528.59771.25101.572974@cuddles.cambridge.redhat.com> Mark Wielaard writes: > Hi, > > On Fri, 2004-04-23 at 11:11, Jeroen Frijters wrote: > > Mark Wielaard wrote: > > > On Fri, 2004-04-16 at 14:03, Andrew Haley wrote: > > > > Mark Wielaard writes: > > > > > Ehe, how do you use/invoke it? > > > > > > > > It gets invoked automatically when you run Mauve, at least on my > > > > system. BinaryCompatibilityTest.java is the driver that invokes it. > > > > > > Aha. And it uses Runtime.exec()... Which wasn't properly > > > implemented in GNU Classpath proper. But we have it now (almost)! > > > > > > ow that I can run it I see that kaffe, jamvm and gij all fail most of > > > the tests. Each of IL bin_01 till IL bin_18 fails 5 or 6 times giving: > > > 107 of 125 tests failed > > > > I never really payed attention to this test, but now I see that it is > > *nix specific (using shell script ). > > > > What is the policy for Mauve? I realise most of you don't care > > about/for Windows, but personally I do. > > So I support Mark's earlier suggestion/request to move this to a > > separate section. Well, alright, as long as you don't have to run it separately if you are on a *nix system. > There is always Cygwin I think Windows has its own *nix compatible subsystem now. But I'm not an expert... > But I do think it might be better to separate out this test from the > rest of Mauve proper. On the other hand, if you have a non-GNUish/Posix > system then you can always disable this one test. Separating it out > without a mechanism for running the tests on multiple systems isn't > really worth it I guess. I don't see the problem, really. If it doesn't run on some system, what is lost? All that happens is a few test failures. There's no reason why someone who is using an unfree OS can't rewrite this test in pure Java if they really need it. But I note that this shell script will work even on MacOS these days. Andrew. From zander@javalobby.org Thu Apr 29 13:16:00 2004 From: zander@javalobby.org (Thomas) Date: Thu, 29 Apr 2004 13:16:00 -0000 Subject: Some issues.. In-Reply-To: <16528.59771.25101.572974@cuddles.cambridge.redhat.com> References: <788B535AB1F9CB49BB9C229372B50ACC0ADEA3@LEMBU.sumatrasoftware.com> <1082891420.27234.1377.camel@elsschot.wildebeest.org> <16528.59771.25101.572974@cuddles.cambridge.redhat.com> Message-ID: <200404291517.22903.zander@javalobby.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 29 April 2004 13:39, Andrew Haley wrote: > I don't see the problem, really. ?If it doesn't run on some system, > what is lost? ?All that happens is a few test failures. For most test environments I make the whole build fail as soon as a test fails; this is implemented in the ant-based mauve test as well. The reason for this is simple; if a test fails its a regression bug; you can't commit changes while you have a regression bug. This might not seem fully logical for mauve; but do expect people to become very annoyed when tests fail. Its a mental thing; 100% correct is a world of difference from 99.5% correct. - -- Regards Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAkQBhCojCW6H2z/QRAvfkAJwMo1BgIdRyeTewvgt4oY+q09wi0QCfZyUJ IeWgI6C9oI5jnDeC4fA14Mo= =jM5V -----END PGP SIGNATURE----- From aph@redhat.com Thu Apr 29 15:29:00 2004 From: aph@redhat.com (Andrew Haley) Date: Thu, 29 Apr 2004 15:29:00 -0000 Subject: Some issues.. In-Reply-To: <200404291517.22903.zander@javalobby.org> References: <788B535AB1F9CB49BB9C229372B50ACC0ADEA3@LEMBU.sumatrasoftware.com> <1082891420.27234.1377.camel@elsschot.wildebeest.org> <16528.59771.25101.572974@cuddles.cambridge.redhat.com> <200404291517.22903.zander@javalobby.org> Message-ID: <16529.7946.481687.868491@cuddles.cambridge.redhat.com> Thomas writes: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Thursday 29 April 2004 13:39, Andrew Haley wrote: > > I don't see the problem, really. ??If it doesn't run on some system, > > what is lost? ??All that happens is a few test failures. > > For most test environments I make the whole build fail as soon as a test > fails; this is implemented in the ant-based mauve test as well. > The reason for this is simple; if a test fails its a regression bug; you can't > commit changes while you have a regression bug. Okay, but if you're going to insist on this you need a way to mark known/expected failures: does any VM pass everything? So, why not mark this whole thing as "known to fail" on Windows and move on? Andrew. From tromey@redhat.com Fri Apr 30 23:22:00 2004 From: tromey@redhat.com (Tom Tromey) Date: Fri, 30 Apr 2004 23:22:00 -0000 Subject: Eclipse and Classpath In-Reply-To: <200404282354.50797.zander@javalobby.org> References: <877jvzhoef.fsf@fleche.redhat.com> <200404282354.50797.zander@javalobby.org> Message-ID: <873c6lm57k.fsf@fleche.redhat.com> >>>>> "Thomas" == Thomas Zander writes: Thomas> IIRC the biggest problem with using JUnit is that it depends Thomas> of rather advanced JVM features; like reflection. Yeah. However, Mauve already uses Class.forName and Class.newInstance, so it is already relying on some reflection capability. Also, when Mauve was started, gcj limitations drove some of the design decisions. In particular we set things up carefully to avoid functionality we knew would not work with gcj. Since then things have changed; all the free VMs are much more capable. Tom From zander@javalobby.org Sat May 1 09:49:00 2004 From: zander@javalobby.org (Thomas Zander) Date: Sat, 01 May 2004 09:49:00 -0000 Subject: Some issues.. In-Reply-To: <16529.7946.481687.868491@cuddles.cambridge.redhat.com> References: <788B535AB1F9CB49BB9C229372B50ACC0ADEA3@LEMBU.sumatrasoftware.com> <200404291517.22903.zander@javalobby.org> <16529.7946.481687.868491@cuddles.cambridge.redhat.com> Message-ID: <200405011148.16628.zander@javalobby.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 29 April 2004 17:28, Andrew Haley wrote: > Thomas writes: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > > On Thursday 29 April 2004 13:39, Andrew Haley wrote: > > > I don't see the problem, really. ?If it doesn't run on some system, > > > what is lost? ?All that happens is a few test failures. > > > > For most test environments I make the whole build fail as soon as a > > test fails; this is implemented in the ant-based mauve test as well. > > The reason for this is simple; if a test fails its a regression bug; > > you can't commit changes while you have a regression bug. > > Okay, but if you're going to insist on this you need a way to mark > known/expected failures: does any VM pass everything? So, why not > mark this whole thing as "known to fail" on Windows and move on? There are 3 approaches to this; I'd suggest the first for ease of use.. 1) check in the test (or even in the test-framework) if a system setting is present. If(System.getProperty("os.name").equals("Windows")) return; 2) add tags to the source files that say "Exclude this on.." Tags like: Windows, i386, 64bit etc. 3) add negative tags to the sourc files that say: "Only run this test on.." Tags like: Unix, 32bit, Kaffe etc. - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAk3JfCojCW6H2z/QRAk5uAKCNQhwbaX82CxizgYJMNd/FxANgrQCghUOD D07PnmqzkMUmdAJdzN3DSyw= =q/Un -----END PGP SIGNATURE----- From zander@javalobby.org Sun May 2 12:17:00 2004 From: zander@javalobby.org (Thomas Zander) Date: Sun, 02 May 2004 12:17:00 -0000 Subject: patch committal. Message-ID: <200405021416.35670.zander@javalobby.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm (again) feeling a tad frustrated that nobody is available to commit or even comment on my patches. http://sources.redhat.com/ml/mauve-discuss/2004-q2/msg00050.html http://sources.redhat.com/ml/mauve-discuss/2004-q2/msg00051.html I've requested a cvs account several times; but have not even received the courtesy of a yes/no answer. Any suggestions on how to get this to move forward again? I have a (graphical) redisign for the website here, I started some tests, but all in all it just does not seem worth it if the reply-cycle is this long. I'm just about ready to give up here.. - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAlOaiCojCW6H2z/QRAgnyAKDZiZ73/v7dLkRPjOe4mpyOg+LdegCfW6nK 2cb7oACp0KiCY5EsWrK6zLk= =0frK -----END PGP SIGNATURE----- From aph@redhat.com Sun May 2 12:27:00 2004 From: aph@redhat.com (Andrew Haley) Date: Sun, 02 May 2004 12:27:00 -0000 Subject: Some issues.. In-Reply-To: <200405011148.16628.zander@javalobby.org> References: <788B535AB1F9CB49BB9C229372B50ACC0ADEA3@LEMBU.sumatrasoftware.com> <200404291517.22903.zander@javalobby.org> <16529.7946.481687.868491@cuddles.cambridge.redhat.com> <200405011148.16628.zander@javalobby.org> Message-ID: <16532.59616.488848.916160@cuddles.cambridge.redhat.com> Thomas Zander writes: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Thursday 29 April 2004 17:28, Andrew Haley wrote: > > Thomas writes: > > > -----BEGIN PGP SIGNED MESSAGE----- > > > Hash: SHA1 > > > > > > On Thursday 29 April 2004 13:39, Andrew Haley wrote: > > > > I don't see the problem, really. ??If it doesn't run on some system, > > > > what is lost? ??All that happens is a few test failures. > > > > > > For most test environments I make the whole build fail as soon as a > > > test fails; this is implemented in the ant-based mauve test as well. > > > The reason for this is simple; if a test fails its a regression bug; > > > you can't commit changes while you have a regression bug. > > > > Okay, but if you're going to insist on this you need a way to mark > > known/expected failures: does any VM pass everything? So, why not > > mark this whole thing as "known to fail" on Windows and move on? > > There are 3 approaches to this; I'd suggest the first for ease of use.. > 1) check in the test (or even in the test-framework) if a system setting is > present. > If(System.getProperty("os.name").equals("Windows")) return; This sounds not entirely unreasonable, but there is one disadvantage: if the Win system has a working shell, it seems a shame not to run this test. But in this case it's probably not important one way or the other: if the Runtime.exec() fails, you can just return. It's really only gcj that needs these tests as far as I am aware. Andrew. From aph@redhat.com Sun May 2 12:50:00 2004 From: aph@redhat.com (Andrew Haley) Date: Sun, 02 May 2004 12:50:00 -0000 Subject: patch committal. In-Reply-To: <200405021416.35670.zander@javalobby.org> References: <200405021416.35670.zander@javalobby.org> Message-ID: <16532.61022.809686.215004@cuddles.cambridge.redhat.com> Thomas Zander writes: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I'm (again) feeling a tad frustrated that nobody is available to commit or > even comment on my patches. > http://sources.redhat.com/ml/mauve-discuss/2004-q2/msg00050.html > http://sources.redhat.com/ml/mauve-discuss/2004-q2/msg00051.html There are okay, I think. > I've requested a cvs account several times; but have not even > received the courtesy of a yes/no answer. We should get you a CVS account. However, your opinion that "its more important to have people creating patches and moving the project forward then to always have a 100% correct CVS" makes people worried. > Any suggestions on how to get this to move forward again? I have a > (graphical) redisign for the website here, I started some tests, > but all in all it just does not seem worth it if the reply-cycle is > this long. > > I'm just about ready to give up here.. You should get CVS access, I think, but of course you'll still need to post patches here for pre-commit discussion. Everybody does that. There were problems with your patches. I fixed the problems by hand. Please don't provide he ChangeLog as a diff: it won't apply anyway. I have committed both these patches. Please check they're OK. Andrew. $ patch -p0 < ~/zander.1 patching file `ChangeLog' Hunk #1 FAILED at 1. 1 out of 1 hunk FAILED -- saving rejects to ChangeLog.rej patching file `gnu/testlet/java/beans/Introspector/jdk12.java' patching file `gnu/testlet/java/security//AlgorithmParameterGenerator/MauveAlgorithm.java' patching file `gnu/testlet/java/security//AlgorithmParameters/MauveAlgorithm.java' patching file `gnu/testlet/java/security//KeyFactory/MauveAlgorithm.java' patching file `gnu/testlet/java/security//KeyPairGenerator/MauveAlgorithm.java' $ patch -p0 < ~/zander.2 patching file `ChangeLog' patch: **** malformed patch at line 91: Index: build.xml From zander@javalobby.org Sun May 2 15:05:00 2004 From: zander@javalobby.org (Thomas Zander) Date: Sun, 02 May 2004 15:05:00 -0000 Subject: patch committal. In-Reply-To: <16532.61022.809686.215004@cuddles.cambridge.redhat.com> References: <200405021416.35670.zander@javalobby.org> <16532.61022.809686.215004@cuddles.cambridge.redhat.com> Message-ID: <200405021704.12662.zander@javalobby.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sunday 02 May 2004 14:49, Andrew Haley wrote: > Thomas Zander writes: > > I've requested a cvs account several times; but have not even > > received the courtesy of a yes/no answer. > > We should get you a CVS account. However, your opinion that "its more > important to have people creating patches and moving the project > forward then to always have a 100% correct CVS" makes people worried. That statement was discussed and I learned that mauve does not have any sort of release cycle in which bugs can be fixed. Its 'released' as a final product in CVS on a daily basis, so to say. I agree that that takes a slightly different approach. > You should get CVS access, I think, That would be nice; anyone I can contact? > but of course you'll still need to > post patches here for pre-commit discussion. Everybody does that. No problem, if you think that helps :-) > There were problems with your patches. I fixed the problems by hand. > Please don't provide he ChangeLog as a diff: it won't apply anyway. I > have committed both these patches. Please check they're OK. After a CVS update I indeed found no file to be modified anymore. Thanx! - -- Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAlQ3pCojCW6H2z/QRAoS9AJwK00dYdrXqsJSZT6YkKEIQn9GfyQCg6jTA bND9ONOOzSpYFiJybbWTmhI= =GsIw -----END PGP SIGNATURE----- From cbj@gnu.org Sun May 2 23:49:00 2004 From: cbj@gnu.org (C. Brian Jones) Date: Sun, 02 May 2004 23:49:00 -0000 Subject: patch committal. In-Reply-To: <200405021704.12662.zander@javalobby.org> References: <200405021416.35670.zander@javalobby.org> <16532.61022.809686.215004@cuddles.cambridge.redhat.com> <200405021704.12662.zander@javalobby.org> Message-ID: <1083541755.3175.108.camel@lyta.haphazard.org> On Sun, 2004-05-02 at 11:04, Thomas Zander wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Sunday 02 May 2004 14:49, Andrew Haley wrote: > > Thomas Zander writes: > > > I've requested a cvs account several times; but have not even > > > received the courtesy of a yes/no answer. > > > > We should get you a CVS account. However, your opinion that "its more > > important to have people creating patches and moving the project > > forward then to always have a 100% correct CVS" makes people worried. > > That statement was discussed and I learned that mauve does not have any > sort of release cycle in which bugs can be fixed. Its 'released' as a > final product in CVS on a daily basis, so to say. > I agree that that takes a slightly different approach. > > > You should get CVS access, I think, > That would be nice; anyone I can contact? > > > but of course you'll still need to > > post patches here for pre-commit discussion. Everybody does that. > No problem, if you think that helps :-) > > > There were problems with your patches. I fixed the problems by hand. > > Please don't provide he ChangeLog as a diff: it won't apply anyway. I > > have committed both these patches. Please check they're OK. > > After a CVS update I indeed found no file to be modified anymore. Thanx! Tom Tromey can get you access. Mauve has a fairly relaxed commit policy, basically adding/fixing tests good, changing anything else requires discussion. Brian -------------- 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 aph@redhat.com Tue May 4 10:27:00 2004 From: aph@redhat.com (Andrew Haley) Date: Tue, 04 May 2004 10:27:00 -0000 Subject: patch committal. In-Reply-To: <200405021704.12662.zander@javalobby.org> References: <200405021416.35670.zander@javalobby.org> <16532.61022.809686.215004@cuddles.cambridge.redhat.com> <200405021704.12662.zander@javalobby.org> Message-ID: <16535.28621.499614.841380@cuddles.cambridge.redhat.com> Thomas Zander writes: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Sunday 02 May 2004 14:49, Andrew Haley wrote: > > Thomas Zander writes: > > > I've requested a cvs account several times; but have not even > > > received the courtesy of a yes/no answer. > > > > We should get you a CVS account. However, your opinion that "its more > > important to have people creating patches and moving the project > > forward then to always have a 100% correct CVS" makes people worried. > > That statement was discussed and I learned that mauve does not have > any sort of release cycle in which bugs can be fixed. Its > 'released' as a final product in CVS on a daily basis, so to say. > I agree that that takes a slightly different approach. Cool. > > You should get CVS access, I think, > That would be nice; anyone I can contact? Tromey should be listening, and AFAICR he holds the keys. Tom, you there? > > but of course you'll still need to > > post patches here for pre-commit discussion. Everybody does that. > No problem, if you think that helps :-) Oh yes. Andrew. From dann@broadjam.com Wed May 5 21:20:00 2004 From: dann@broadjam.com (Daniel Naab) Date: Wed, 05 May 2004 21:20:00 -0000 Subject: Mauve usage with custom bootclasspath? Message-ID: <91109D2A38887045A9549186D4D0EE06011B5670@hermes.broadjam.com> I'm attempting to create some scripts to test the SwingWT library, a Swing implementation over SWT: http://swingwt.sourceforge.net Given the nature of the library (replacement for existing base runtime libraries) and a desire to allow the test suite to run under any JVM configuration, I'd like to run the tests with SwingWT in the boot class path. Assume running with the Sun JDK, how would I go about this? I'm trying something along these lines currently: > autoreconf > ./configure JAVA="{PATH TO JAVA} -bootclasspath=BOOTCLASSPATH" JAVAC="{PATH TO JAVAC} -bootclasspath=BOOTCLASSPATH" > make check where BOOTCLASSPATH = {PATH TO SWINGWT JAR};{PATH TO RT.JAR} Is this the correct approach? Any suggestions for how to isolate tests just to SwingWT? Forgive my ignorance if this is the incorrect way to use Mauve, but I found it difficult for find documentation. Thank you! Daniel Naab From tromey@redhat.com Wed May 5 21:33:00 2004 From: tromey@redhat.com (Tom Tromey) Date: Wed, 05 May 2004 21:33:00 -0000 Subject: Mauve usage with custom bootclasspath? In-Reply-To: <91109D2A38887045A9549186D4D0EE06011B5670@hermes.broadjam.com> References: <91109D2A38887045A9549186D4D0EE06011B5670@hermes.broadjam.com> Message-ID: <87vfjaefif.fsf@fleche.redhat.com> >>>>> "Daniel" == Daniel Naab writes: >> ./configure JAVA="{PATH TO JAVA} -bootclasspath=BOOTCLASSPATH" Daniel> JAVAC="{PATH TO JAVAC} -bootclasspath=BOOTCLASSPATH" Daniel> Is this the correct approach? Any suggestions for how to Daniel> isolate tests just to SwingWT? This looks pretty good. Once you have everything built, you just need to run the `gnu.testlet.SimpleTestHarness' program. How you launch it is up to you. This program accepts test names on stdin. By default the Makefile will run it with `cat classes | java ...'. You can easily subset this: `grep whatever classes | java ...' Tom From dann@broadjam.com Thu May 6 04:28:00 2004 From: dann@broadjam.com (Daniel Naab) Date: Thu, 06 May 2004 04:28:00 -0000 Subject: Mauve usage with custom bootclasspath? Message-ID: <91109D2A38887045A9549186D4D0EE06011B5671@hermes.broadjam.com> Thank you much, things seem to be working well. I have a couple comments/questions: There's a problem with build.xml on Windows, which surfaces when building either through cmd.exe or Cygwin (bash). The lines... .... successfully replace the specified paths in the source, but since Windows uses "\" as the file separator, the resulting Java code won't compile. Somehow those portions of the paths should be escaped out. I got to this point by trying to create an Ant script to do a Mauve checkout and build.. I have no trouble building manually, but when trying to run the configure script from Ant, I ran into the problem that it doesn't seem to have a way to call a shell script with parameters.. of which some escaped " characters may exist. I'm probably just missing something, but noticing that the Ant script also exists, I realized it would probably be easier just to call the appropriate compile target instead. Do I still need to run configure if using the Ant script? What would be the steps necessary to execute the compile target, assuming a clean checkout? I suppose I could just use a makefile instead, but now that I'm as far as I am, that urge to finish is too strong. :) Thanks. The test suite looks excellent, and will be a very useful tool for SwingWT! Dan Naab > -----Original Message----- > From: Tom Tromey [mailto:tromey@redhat.com] > Sent: Wednesday, May 05, 2004 4:22 PM > To: Daniel Naab > Cc: 'mauve-discuss@sources.redhat.com' > Subject: Re: Mauve usage with custom bootclasspath? > > > >>>>> "Daniel" == Daniel Naab writes: > > >> ./configure JAVA="{PATH TO JAVA} -bootclasspath=BOOTCLASSPATH" > Daniel> JAVAC="{PATH TO JAVAC} -bootclasspath=BOOTCLASSPATH" > > Daniel> Is this the correct approach? Any suggestions for how to > Daniel> isolate tests just to SwingWT? > > This looks pretty good. > Once you have everything built, you just need to run the > `gnu.testlet.SimpleTestHarness' program. How you launch it is up to > you. > > This program accepts test names on stdin. By default the Makefile > will run it with `cat classes | java ...'. You can easily subset > this: `grep whatever classes | java ...' > > Tom > From dann@broadjam.com Thu May 6 23:10:00 2004 From: dann@broadjam.com (Daniel Naab) Date: Thu, 06 May 2004 23:10:00 -0000 Subject: Mauve usage with custom bootclasspath? Message-ID: <91109D2A38887045A9549186D4D0EE06011B5673@hermes.broadjam.com> I was able to get things going in a cross-platform way by using a combination of configure and an external call to the build.xml compile tag. Thanks for the help. Dan > -----Original Message----- > From: Daniel Naab > Sent: Wednesday, May 05, 2004 11:35 PM > To: 'tromey@redhat.com' > Cc: 'mauve-discuss@sources.redhat.com' > Subject: RE: Mauve usage with custom bootclasspath? > > > Thank you much, things seem to be working well. I have a > couple comments/questions: From jewel@pixie.co.za Fri May 7 11:54:00 2004 From: jewel@pixie.co.za (John Leuner) Date: Fri, 07 May 2004 11:54:00 -0000 Subject: Some issues.. In-Reply-To: <200404031504.41093.zander@javalobby.org> References: <200404031504.41093.zander@javalobby.org> Message-ID: <1083929941.419.213.camel@cmalu> I haven't read all the list postings, so forgive me if I missed something. (my reply is below) > I spent a couple of days running with the snapshot which I downloaded from > the webpage (http://sources.redhat.com/mauve/) until I found out is _very_ > far from recent (which the 'snapshot' seemed to imply) > I must say its pretty bad that the snapshot is over a year old!! > I suggest to remote the snapshot; or have up-to-date versions created > nightly. > > I looked at the homepage and found a 'breaking news' that I found rather > dubious; it looks like its been there for ages since the 'sidebar' does > not work (on either konqueror or on mozilla), the 'logo design' leads to a > dead link, the 'contribute' page is empty.. > Please make the project seem 'less dead' to the passing eye!! If Red-hat > does not do anything; what about moving the project to sourceforge or > savannah ?? Yes, I think it makes a lot of sense to move the website part of mauve to a site like sourceforge. This would make the maintenance of the web pages easier (it's easy to give people access on sourceforge). I don't see any reason to move any of the other services however (I assume "other services" is just the CVS repo?). John Leuner -- John Leuner From zander@javalobby.org Fri May 7 13:25:00 2004 From: zander@javalobby.org (Thomas) Date: Fri, 07 May 2004 13:25:00 -0000 Subject: Some issues.. In-Reply-To: <1083929941.419.213.camel@cmalu> References: <200404031504.41093.zander@javalobby.org> <1083929941.419.213.camel@cmalu> Message-ID: <200405071525.45349.zander@javalobby.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Friday 07 May 2004 13:39, John Leuner wrote: > > Please make the project seem 'less dead' to the passing eye!! If Red-hat > > does not do anything; what about moving the project to sourceforge or > > savannah ?? > > Yes, I think it makes a lot of sense to move the website part of mauve > to a site like sourceforge. This would make the maintenance of the web > pages easier (it's easy to give people access on sourceforge). > > I don't see any reason to move any of the other services however (I > assume "other services" is just the CVS repo?). Actually; I was blessed with a CVS account a couple of days ago. I have a (graphical) design of a cleaned up page on my machine at home; my html is extremely rusty, but I intend to work a little on creating a new look this weekend. If I create something nice looking I'll put it up somewhere for all to see and judge, moving it to the real mauve site is a piece of cake if an agreement is found. - -- Regards Thomas -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQFAm45SCojCW6H2z/QRAnq4AJ9PbPGkddr47Ros458qdH/4Ewfy1gCgph/3 tQav5KPZF4bL8vDHBcEDJoU= =3yPc -----END PGP SIGNATURE----- From jeanicelafontainezcat@hardwarefanatic.net Wed Jun 9 19:32:00 2004 From: jeanicelafontainezcat@hardwarefanatic.net (nickolas woodhouse) Date: Wed, 09 Jun 2004 19:32:00 -0000 Subject: Gphiuanyrc this is a real hit Message-ID: conflcit bagbs anonymified And to give you a general idea of what we specialize in: V@L|UM, X@NA.X, AM.BIEN PHEN.TERMINE PR0ZAC ...much more.. ! It's private, fast, and safe. (you may exclude youself with the same l i n k) M X http://xj.info.ginformation.com/abc/bigger/ Professor Tom was going to meet his students on the next day, so he wrote some words on the blackboard which read as follows: "Professor Tom will meet the class tomorrow."A student, seeing his chance to display his sense of humor after reading the notice, walked up and erased the "c" in the word "class." The Professor noticing the laughter, wheeled around, walked back, looked at the student, then at the notice with the "c" erased--calmly walked up and erased the "l" in "lass", looked at the flabbergasted student and proceeded on his way German scientists dug 50 meters down and discovered small pieces of copper. After studying these pieces for a long time, Germany announced that the ancient Germans 25,000 years ago had a nation-wide telephone net. Naturally, the Russian government was not that easily impressed. They ordered their own scientists to dig even deeper. 100 meters down they found small pieces of glass and they soon announced that the ancient Russians 35,000 years ago already had a nation-wide fiber net. American scientists were outraged by this. They dug 200 meters down & found absolutely nothing. They happily concluded that the ancient Americans 55,000 years ago had cellular telephones. teibunsh8tasuki02sinjuumi,oriae shuuseir. From mike.fletcher@theplanet.ca Fri Jun 11 13:44:00 2004 From: mike.fletcher@theplanet.ca (Michael Fletcher) Date: Fri, 11 Jun 2004 13:44:00 -0000 Subject: GMane Message-ID: <40C9B575.3000703@theplanet.ca> Hello. Would anyone mind if I subscribed mauve-discuss, mauve-announce and mauve-patches to GMane? From mike.fletcher@theplanet.ca Sat Jun 12 20:59:00 2004 From: mike.fletcher@theplanet.ca (Michael Fletcher) Date: Sat, 12 Jun 2004 20:59:00 -0000 Subject: Mauve Distributable Message-ID: <40CB6D97.3050604@theplanet.ca> Hello. I would like to hack the makefiles so that they could produced a distributable mauve test suite. I would like this so that it would be easier for someone to test there VM's against Mauve. For example one might only need to run: java -jar mauve-jdk1.4.jar sablevm-java -jar mauve-jdk1.4.jar kaffe-java -jar mauve-jdk1.4.jar This would also make it easier to run the test suite under Windows. From cbj@gnu.org Wed Jun 16 23:04:00 2004 From: cbj@gnu.org (C. Brian Jones) Date: Wed, 16 Jun 2004 23:04:00 -0000 Subject: Mauve Distributable In-Reply-To: <40CB6D97.3050604@theplanet.ca> References: <40CB6D97.3050604@theplanet.ca> Message-ID: <1087427047.2563.1.camel@lyta.haphazard.org> On Sat, 2004-06-12 at 16:54, Michael Fletcher wrote: > Hello. > > I would like to hack the makefiles so that they could produced a > distributable mauve test suite. I would like this so that it would be > easier for someone to test there VM's against Mauve. For example one > might only need to run: > > java -jar mauve-jdk1.4.jar > sablevm-java -jar mauve-jdk1.4.jar > kaffe-java -jar mauve-jdk1.4.jar > > This would also make it easier to run the test suite under Windows. I'm interested in the same thing. No time to work on it now. Main concern expressed before is to ensure gcj's testsuite continues to work after making changes. -------------- 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 Jun 29 17:59:00 2004 From: tromey@redhat.com (Tom Tromey) Date: Tue, 29 Jun 2004 17:59:00 -0000 Subject: GMane In-Reply-To: <40C9B575.3000703@theplanet.ca> References: <40C9B575.3000703@theplanet.ca> Message-ID: <87y8m6cl5q.fsf@fleche.redhat.com> Michael> Would anyone mind if I subscribed mauve-discuss, mauve-announce and Michael> mauve-patches to GMane? Not at all. Tom