From fitzsim@redhat.com Mon Jan 3 23:37:00 2005 From: fitzsim@redhat.com (Thomas Fitzsimmons) Date: Mon, 03 Jan 2005 23:37:00 -0000 Subject: Patch: GUI testing framework Message-ID: <1104795399.6374.117.camel@tortoise.toronto.redhat.com> Hi, This patch adds support to batch_run for running GUI tests, either within an Xvfb server (default) or directly on the tester's desktop. It also introduces the GUI tag; all tests that require DISPLAY to be set should be tagged as GUI tests. I tested this with the java.awt.Robot tests I posted last week. The tests run properly both within Xvfb and on my desktop. I would like to rely on the metacity window manager, since it handles inset sizing correctly. Comments? Tom 2005-01-03 Thomas Fitzsimmons * batch_run: Invoke Xvfb and metacity if GUI key is specified. * choose: Handle GUI tag. * README: Add section on GUI tests. -------------- next part -------------- A non-text attachment was scrubbed... Name: mauve-gui-framework.patch Type: text/x-patch Size: 2859 bytes Desc: URL: From zander@kde.org Tue Jan 4 08:31:00 2005 From: zander@kde.org (Thomas Zander) Date: Tue, 04 Jan 2005 08:31:00 -0000 Subject: Patch: GUI testing framework In-Reply-To: <1104795399.6374.117.camel@tortoise.toronto.redhat.com> References: <1104795399.6374.117.camel@tortoise.toronto.redhat.com> Message-ID: <200501040930.18433.zander@kde.org> On Tuesday 04 January 2005 00:36, Thomas Fitzsimmons wrote: > I would like to rely on the metacity window manager, since it handles > inset sizing correctly. If you feel the KWin WM does not, please make sure to inform the KWin developers where they don't follow the spec. I'd find it slightly amuzing if KDE does not since at least the main developer is also part of the spec lead.. If you don't want to create a bugreport, please tell me exactly what the problem is (a reproducable c/c++ testcase would be great) so I can contact Lubos about this. -- Thomas Zander -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From konqueror@gmx.de Tue Jan 4 09:01:00 2005 From: konqueror@gmx.de (Michael Koch) Date: Tue, 04 Jan 2005 09:01:00 -0000 Subject: Patch: GUI testing framework In-Reply-To: <1104795399.6374.117.camel@tortoise.toronto.redhat.com> References: <1104795399.6374.117.camel@tortoise.toronto.redhat.com> Message-ID: <200501041002.30797.konqueror@gmx.de> Am Dienstag, 4. Januar 2005 00:36 schrieb Thomas Fitzsimmons: > Hi, > > This patch adds support to batch_run for running GUI tests, either > within an Xvfb server (default) or directly on the tester's > desktop. It also introduces the GUI tag; all tests that require > DISPLAY to be set should be tagged as GUI tests. > > I tested this with the java.awt.Robot tests I posted last week. > The tests run properly both within Xvfb and on my desktop. Nice. Classpath has it now too, so we can generally test it too directly. > I would like to rely on the metacity window manager, since it > handles inset sizing correctly. Depending on a specific window manager is stupid. It just makes the hurdles for users of mauve higher. If we have problems with a specific window manager and its his fault and not ours we should report bugs. If you refer to the wrong insets bug I see here, I made sure its a jamvm/classpath bug, not a window manager bug. It only occurs in jamvm/classpath and not in a 100% merged java-gui-branch. I will try to investigate it more, no matter if I run kwin, windowmaker or GNOME/metacity. Michael -- Homepage: http://www.worldforge.org/ From fitzsim@redhat.com Tue Jan 4 16:39:00 2005 From: fitzsim@redhat.com (Thomas Fitzsimmons) Date: Tue, 04 Jan 2005 16:39:00 -0000 Subject: Patch: GUI testing framework In-Reply-To: <200501041002.30797.konqueror@gmx.de> References: <1104795399.6374.117.camel@tortoise.toronto.redhat.com> <200501041002.30797.konqueror@gmx.de> Message-ID: <1104856780.6374.135.camel@tortoise.toronto.redhat.com> On Tue, 2005-01-04 at 10:02 +0100, Michael Koch wrote: > Am Dienstag, 4. Januar 2005 00:36 schrieb Thomas Fitzsimmons: > > Hi, > > > > This patch adds support to batch_run for running GUI tests, either > > within an Xvfb server (default) or directly on the tester's > > desktop. It also introduces the GUI tag; all tests that require > > DISPLAY to be set should be tagged as GUI tests. > > > > I tested this with the java.awt.Robot tests I posted last week. > > The tests run properly both within Xvfb and on my desktop. > > Nice. Classpath has it now too, so we can generally test it too > directly. > > > I would like to rely on the metacity window manager, since it > > handles inset sizing correctly. > > Depending on a specific window manager is stupid. It just makes the > hurdles for users of mauve higher. If we have problems with a > specific window manager and its his fault and not ours we should > report bugs. > OK. Can we default to metacity? I'm thinking of: if test "x$WM" = "x" ; then WM=metacity fi Then you could set WM on the command line. Tom From konqueror@gmx.de Tue Jan 4 17:35:00 2005 From: konqueror@gmx.de (Michael Koch) Date: Tue, 04 Jan 2005 17:35:00 -0000 Subject: Patch: GUI testing framework In-Reply-To: <1104856780.6374.135.camel@tortoise.toronto.redhat.com> References: <1104795399.6374.117.camel@tortoise.toronto.redhat.com> <200501041002.30797.konqueror@gmx.de> <1104856780.6374.135.camel@tortoise.toronto.redhat.com> Message-ID: <200501041836.44020.konqueror@gmx.de> Am Dienstag, 4. Januar 2005 17:39 schrieb Thomas Fitzsimmons: > On Tue, 2005-01-04 at 10:02 +0100, Michael Koch wrote: > > Am Dienstag, 4. Januar 2005 00:36 schrieb Thomas Fitzsimmons: > > > Hi, > > > > > > This patch adds support to batch_run for running GUI tests, > > > either within an Xvfb server (default) or directly on the > > > tester's desktop. It also introduces the GUI tag; all tests > > > that require DISPLAY to be set should be tagged as GUI tests. > > > > > > I tested this with the java.awt.Robot tests I posted last week. > > > The tests run properly both within Xvfb and on my desktop. > > > > Nice. Classpath has it now too, so we can generally test it too > > directly. > > > > > I would like to rely on the metacity window manager, since it > > > handles inset sizing correctly. > > > > Depending on a specific window manager is stupid. It just makes > > the hurdles for users of mauve higher. If we have problems with a > > specific window manager and its his fault and not ours we should > > report bugs. > > OK. Can we default to metacity? I'm thinking of: > > if test "x$WM" = "x" ; then > WM=metacity > fi > > Then you could set WM on the command line. Why do you need the window manager at all ? Where does the $WM value get used ? Michael -- Homepage: http://www.worldforge.org/ From fitzsim@redhat.com Tue Jan 4 18:08:00 2005 From: fitzsim@redhat.com (Thomas Fitzsimmons) Date: Tue, 04 Jan 2005 18:08:00 -0000 Subject: Patch: GUI testing framework In-Reply-To: <200501040930.18433.zander@kde.org> References: <1104795399.6374.117.camel@tortoise.toronto.redhat.com> <200501040930.18433.zander@kde.org> Message-ID: <1104862126.6374.150.camel@tortoise.toronto.redhat.com> On Tue, 2005-01-04 at 09:30 +0100, Thomas Zander wrote: > On Tuesday 04 January 2005 00:36, Thomas Fitzsimmons wrote: > > I would like to rely on the metacity window manager, since it handles > > inset sizing correctly. > > If you feel the KWin WM does not, please make sure to inform the KWin > developers where they don't follow the spec. > I'd find it slightly amuzing if KDE does not since at least the main > developer is also part of the spec lead.. > It's not that they don't follow the spec, it's just that they don't interpret it as strictly as metacity does. See this thread for the original discussion: http://mail.gnome.org/archives/wm-spec-list/2003-December/msg00005.html > If you don't want to create a bugreport, please tell me exactly what the > problem is (a reproducable c/c++ testcase would be great) so I can > contact Lubos about this. > Try running gnu.testlet.java.awt.Robot.mouseMove under KWin and then under Metacity. I've attached a new patch that makes it easier to override the default window manager. Tom 2005-01-03 Thomas Fitzsimmons * batch_run: Invoke Xvfb and metacity if GUI key is specified. * choose: Handle GUI tag. * README: Add section on GUI tests. -------------- next part -------------- A non-text attachment was scrubbed... Name: mauve-gui-framework2.patch Type: text/x-patch Size: 2994 bytes Desc: URL: From fitzsim@redhat.com Tue Jan 4 18:28:00 2005 From: fitzsim@redhat.com (Thomas Fitzsimmons) Date: Tue, 04 Jan 2005 18:28:00 -0000 Subject: Patch: GUI testing framework In-Reply-To: <200501041836.44020.konqueror@gmx.de> References: <1104795399.6374.117.camel@tortoise.toronto.redhat.com> <200501041002.30797.konqueror@gmx.de> <1104856780.6374.135.camel@tortoise.toronto.redhat.com> <200501041836.44020.konqueror@gmx.de> Message-ID: <1104863294.6374.156.camel@tortoise.toronto.redhat.com> On Tue, 2005-01-04 at 18:36 +0100, Michael Koch wrote: > Am Dienstag, 4. Januar 2005 17:39 schrieb Thomas Fitzsimmons: > > On Tue, 2005-01-04 at 10:02 +0100, Michael Koch wrote: > > > Am Dienstag, 4. Januar 2005 00:36 schrieb Thomas Fitzsimmons: > > > > Hi, > > > > > > > > This patch adds support to batch_run for running GUI tests, > > > > either within an Xvfb server (default) or directly on the > > > > tester's desktop. It also introduces the GUI tag; all tests > > > > that require DISPLAY to be set should be tagged as GUI tests. > > > > > > > > I tested this with the java.awt.Robot tests I posted last week. > > > > The tests run properly both within Xvfb and on my desktop. > > > > > > Nice. Classpath has it now too, so we can generally test it too > > > directly. > > > > > > > I would like to rely on the metacity window manager, since it > > > > handles inset sizing correctly. > > > > > > Depending on a specific window manager is stupid. It just makes > > > the hurdles for users of mauve higher. If we have problems with a > > > specific window manager and its his fault and not ours we should > > > report bugs. > > > > OK. Can we default to metacity? I'm thinking of: > > > > if test "x$WM" = "x" ; then > > WM=metacity > > fi > > > > Then you could set WM on the command line. > > Why do you need the window manager at all ? Where does the $WM value > get used ? > You don't need a window manager, but having one makes for a more realistic testing environment. With the patch I just posted, you can set WM=/bin/true to run without a window manager. Tom From tromey@redhat.com Tue Jan 4 19:28:00 2005 From: tromey@redhat.com (Tom Tromey) Date: Tue, 04 Jan 2005 19:28:00 -0000 Subject: Patch: GUI testing framework In-Reply-To: <1104856780.6374.135.camel@tortoise.toronto.redhat.com> References: <1104795399.6374.117.camel@tortoise.toronto.redhat.com> <200501041002.30797.konqueror@gmx.de> <1104856780.6374.135.camel@tortoise.toronto.redhat.com> Message-ID: >>>>> "Tom" == Thomas Fitzsimmons writes: Tom> if test "x$WM" = "x" ; then Tom> WM=metacity Tom> fi That seems reasonable to me. The patch looks good too. Tom From konqueror@gmx.de Tue Jan 4 21:08:00 2005 From: konqueror@gmx.de (Michael Koch) Date: Tue, 04 Jan 2005 21:08:00 -0000 Subject: Patch: GUI testing framework In-Reply-To: <1104856780.6374.135.camel@tortoise.toronto.redhat.com> References: <1104795399.6374.117.camel@tortoise.toronto.redhat.com> <200501041002.30797.konqueror@gmx.de> <1104856780.6374.135.camel@tortoise.toronto.redhat.com> Message-ID: <200501042210.07725.konqueror@gmx.de> Am Dienstag, 4. Januar 2005 17:39 schrieb Thomas Fitzsimmons: > On Tue, 2005-01-04 at 10:02 +0100, Michael Koch wrote: > > Am Dienstag, 4. Januar 2005 00:36 schrieb Thomas Fitzsimmons: > > > Hi, > > > > > > This patch adds support to batch_run for running GUI tests, > > > either within an Xvfb server (default) or directly on the > > > tester's desktop. It also introduces the GUI tag; all tests > > > that require DISPLAY to be set should be tagged as GUI tests. > > > > > > I tested this with the java.awt.Robot tests I posted last week. > > > The tests run properly both within Xvfb and on my desktop. > > > > Nice. Classpath has it now too, so we can generally test it too > > directly. > > > > > I would like to rely on the metacity window manager, since it > > > handles inset sizing correctly. > > > > Depending on a specific window manager is stupid. It just makes > > the hurdles for users of mauve higher. If we have problems with a > > specific window manager and its his fault and not ours we should > > report bugs. > > OK. Can we default to metacity? I'm thinking of: > > if test "x$WM" = "x" ; then > WM=metacity > fi Can you default to /bin/true when metacity is not in the path ? Michael -- Homepage: http://www.worldforge.org/ From fitzsim@redhat.com Tue Jan 4 21:16:00 2005 From: fitzsim@redhat.com (Thomas Fitzsimmons) Date: Tue, 04 Jan 2005 21:16:00 -0000 Subject: Patch: GUI testing framework In-Reply-To: <1104862126.6374.150.camel@tortoise.toronto.redhat.com> References: <1104795399.6374.117.camel@tortoise.toronto.redhat.com> <200501040930.18433.zander@kde.org> <1104862126.6374.150.camel@tortoise.toronto.redhat.com> Message-ID: <1104873391.6374.158.camel@tortoise.toronto.redhat.com> On Tue, 2005-01-04 at 13:08 -0500, Thomas Fitzsimmons wrote: > Try running gnu.testlet.java.awt.Robot.mouseMove under KWin and then > under Metacity. I've attached a new patch that makes it easier to > override the default window manager. I committed this. Tom From fitzsim@redhat.com Wed Jan 5 00:18:00 2005 From: fitzsim@redhat.com (Thomas Fitzsimmons) Date: Wed, 05 Jan 2005 00:18:00 -0000 Subject: [PATCH] Enable GUI tests by default Message-ID: <1104884316.6374.168.camel@tortoise.toronto.redhat.com> Hi, I just committed this patch. It enables the GUI tests by default in both choose and choose-classes, allows setting of NATIVE on the command line and sets WM to /bin/true if metacity is not found. I also committed the gnu.testlet.java.awt.Robot tests. Tom 2005-01-04 Thomas Fitzsimmons * batch_run: Allow NATIVE to be set on the command line. Set WM to /bin/true if metacity is not found. * choose: Include GUI tests by default. * choose-classes: Likewise. * gnu/testlet/java/awt/Robot/mouseMove.java: New test. * gnu/testlet/java/awt/Robot/mousePress.java: Likewise. * gnu/testlet/java/awt/Robot/constructors.java: Likewise. * gnu/testlet/java/awt/Robot/createScreenCapture.java: Likewise. * gnu/testlet/java/awt/Robot/getPixelColor.java: Likewise. * gnu/testlet/java/awt/Robot/keyPress.java: Likewise. * gnu/testlet/java/awt/Robot/keyRelease.java: Likewise. * gnu/testlet/java/awt/Robot/mouseRelease.java: Likewise. * gnu/testlet/java/awt/Robot/mouseWheel.java: Likewise. -------------- next part -------------- A non-text attachment was scrubbed... Name: mauve-gui-framework3.patch Type: text/x-patch Size: 2048 bytes Desc: URL: From audriusa@bluewin.ch Wed Jan 26 21:28:00 2005 From: audriusa@bluewin.ch (Meskauskas Audrius) Date: Wed, 26 Jan 2005 21:28:00 -0000 Subject: I would like to join the project Message-ID: <000301c503ed$eee86fb0$2101a8c0@computername> Hello all, I am writing the HTML parser (javax.swing.text.html.parser.*) for Classpath and would like to contribute the corresponding tests to Mauve project. Mauve runs ok under Ant for me, and I already have my first tests working. Mauve is a separate project, so maybe I need to send a separate message that I would like to join it. If I understand correctly, the new developers are expected to send a message using this E-mail address. I am still not visible in Classpath developers list because they need to receive my signed copyright agreement. This agreement is on the way back to them. Regards Audrius Meskauskas From tromey@redhat.com Wed Jan 26 22:00:00 2005 From: tromey@redhat.com (Tom Tromey) Date: Wed, 26 Jan 2005 22:00:00 -0000 Subject: I would like to join the project In-Reply-To: <000301c503ed$eee86fb0$2101a8c0@computername> References: <000301c503ed$eee86fb0$2101a8c0@computername> Message-ID: Audrius> I am writing the HTML parser (javax.swing.text.html.parser.*) for Audrius> Classpath and would like to contribute the corresponding tests to Audrius> Mauve project. Awesome. Please fill out this form and put my email as the approver: http://sources.redhat.com/cgi-bin/pdw/ps_form.cgi Tom From audriusa@bluewin.ch Sat Jan 29 17:03:00 2005 From: audriusa@bluewin.ch (Meskauskas Audrius) Date: Sat, 29 Jan 2005 17:03:00 -0000 Subject: Discussing a helper class to migrate from JUnit Message-ID: <001701c50624$43f8df20$2101a8c0@computername> Hello, Following the rules of the Mauve project, I would like to discuss the following addition to Mauve before submission: Motivation: JUnit is another popular testing suite. Some people may already have a JUnit tests written and need to adapt them for Mauve. Some code generators produce tests for JUnit and not for Mauve. In this context, it seems good to have an additional helper class for easier conversion of JUnit TestCase into Mauve Testlet. It is possible to have the individual helper class as a part of the test itself. However it may be better to have it in a more public place where it could be shared. Suggestion: 1. The JUnit TestCase calls static methods like assertTrue(..), assertEquals(..) and so on. The helper class can have the identically named non-static methods, just delegating the call to the current instance of TestHarness. 2. The JUnit TestCase has a multiple public non static parameterless methods, starting with test.... These methods are found and called using reflection. The helper class can do just the same. 3. The two protected methods, setUp() and tearDown(), should be present in a helper class as they are frequently called from the generated code. These two methods can return without action for beginning. The class, implementing these two things, would allow to run a typical JUnit test on Mauve with only minor changes. If no suggested otherwise, the class could be called Unitizer and placed into gnu.testlet. Regards Audrius From theBohemian@gmx.net Sun Jan 30 15:59:00 2005 From: theBohemian@gmx.net (Robert Schuster) Date: Sun, 30 Jan 2005 15:59:00 -0000 Subject: Discussing a helper class to migrate from JUnit In-Reply-To: <001701c50624$43f8df20$2101a8c0@computername> References: <001701c50624$43f8df20$2101a8c0@computername> Message-ID: <41FD0418.1030703@gmx.net> Hello Audrius, AFAIK a solution that allows JUnit tests being run as part of mauve is frequently discussed here but there was no result yet. Former discussions could IMHO not solve this problem: JUnit uses reflection and therefore depends on a stable support for this mechanism. Mauve as a framework for testing the basic functionality of a VM could therefore not depend on a working reflection API. Despite from that I like the idea of faking a JUnit environment to run such tests. However that environment should be created with only minimal dependency on the VM. My suggestion is that for each testcase TC you have to: * scan the class file of TC with something like javap * generate Java source code that calls the public methods of TC, call that an adapter class AC * compile the AC * run the mauve test via the AC These are only basic thoughts. Meskauskas Audrius wrote: > Hello, > > Following the rules of the Mauve project, I would like to discuss the > following addition to Mauve before submission: > > Motivation: > JUnit is another popular testing suite. Some people may already have a > JUnit tests written and need to adapt them for Mauve. Some code > generators produce tests for JUnit and not for Mauve. In this context, > it seems good to have an additional helper class for easier conversion > of JUnit TestCase into Mauve Testlet. It is possible to have the > individual helper class as a part of the test itself. However it may > be better to have it in a more public place where it could be shared. > > Suggestion: > 1. The JUnit TestCase calls static methods like assertTrue(..), > assertEquals(..) and so on. The helper class can have the identically > named non-static methods, just delegating the call to the current > instance of TestHarness. I think that the helper class to live in the same package as the real JUnit classes. > > 2. The JUnit TestCase has a multiple public non static parameterless > methods, starting with test.... These methods are found and called > using reflection. The helper class can do just the same. IMHO reflection is considered high-tech which may be broken/unsupported on a VM. cu Robert From zander@kde.org Sun Jan 30 16:11:00 2005 From: zander@kde.org (Thomas Zander) Date: Sun, 30 Jan 2005 16:11:00 -0000 Subject: Discussing a helper class to migrate from JUnit In-Reply-To: <41FD0418.1030703@gmx.net> References: <001701c50624$43f8df20$2101a8c0@computername> <41FD0418.1030703@gmx.net> Message-ID: <200501301710.20212.zander@kde.org> On Sunday 30 January 2005 16:58, Robert Schuster wrote: > Hello Audrius, > AFAIK a solution that allows JUnit tests being run as part of mauve is > frequently discussed here but there was no result yet. > > Former discussions could IMHO not solve this problem: > JUnit uses reflection and therefore depends on a stable support for this > mechanism. Mauve as a framework for testing the basic functionality of a > VM could therefore not depend on a working reflection API. > > Despite from that I like the idea of faking a JUnit environment to run > such tests. However that environment should be created with only minimal > dependency on the VM. > > My suggestion is that for each testcase TC you have to: > * scan the class file of TC with something like javap > * generate Java source code that calls the public methods of TC, > call that an adapter class AC > * compile the AC > * run the mauve test via the AC I had the same idea; let AC implement the right mauve-structures (the Testlet interface) and you will have a runnable test environment. If javap is too big a dependency; then it is also possible to generate the AC class using reflection. This means you have to write a class that gets a list of fully-qualified class-names and then uses reflection much like JUnit does. Only instead of running the tests you write out a Testlet for that class. This would fit nicely with a project I am (still) working on. I intend to create one jar file with all the mauve tests and anyone can then use that jar to execute each test on their own JVM. This fits because I doubt we want the generated wrapper classes in CVS and I will surely compile/jar using the Sun JVM. The biggest problem I see with this is that the mauve toolkit will only compile/run with JUnit in the classpath. Perhaps some stubs can also be supplied to counter this problem. As Robert said; many have stated that this is a good idea, but nobody really supplied any code to actually do it :) Looking forward to any proof-of-concepts from you!! -- Thomas Zander -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jeroen@sumatra.nl Mon Jan 31 11:35:00 2005 From: jeroen@sumatra.nl (Jeroen Frijters) Date: Mon, 31 Jan 2005 11:35:00 -0000 Subject: Unicode test noise Message-ID: Hi, Does anyone have any objections against this patch to eliminate the noise that the unicode test generates? Regards, Jeroen Index: gnu/testlet/java/lang/Character/UnicodeBase.java =================================================================== RCS file: /cvs/mauve/mauve/gnu/testlet/java/lang/Character/UnicodeBase.java,v retrieving revision 1.1 diff -u -r1.1 UnicodeBase.java --- gnu/testlet/java/lang/Character/UnicodeBase.java 8 Apr 2004 16:05:36 -0000 1.1 +++ gnu/testlet/java/lang/Character/UnicodeBase.java 31 Jan 2005 11:34:16 -0000 @@ -276,7 +276,6 @@ protected void checkPassed() { - harness.check(true); } public boolean range(int mid, int low, int high) From konqueror@gmx.de Mon Jan 31 11:41:00 2005 From: konqueror@gmx.de (Michael Koch) Date: Mon, 31 Jan 2005 11:41:00 -0000 Subject: Unicode test noise In-Reply-To: References: Message-ID: <200501311241.28459.konqueror@gmx.de> Am Montag, 31. Januar 2005 12:34 schrieb Jeroen Frijters: > Hi, > > Does anyone have any objections against this patch to eliminate the > noise that the unicode test generates? Why don't you just skip the tests ? You change would make the tests don't show up in summaries when they succeed. Michael -- Homepage: http://www.worldforge.org/ From jeroen@sumatra.nl Mon Jan 31 12:14:00 2005 From: jeroen@sumatra.nl (Jeroen Frijters) Date: Mon, 31 Jan 2005 12:14:00 -0000 Subject: Unicode test noise Message-ID: Michael Koch wrote: > Am Montag, 31. Januar 2005 12:34 schrieb Jeroen Frijters: > > Hi, > > > > Does anyone have any objections against this patch to eliminate the > > noise that the unicode test generates? > > Why don't you just skip the tests ? You change would make the tests > don't show up in summaries when they succeed. I don't want to skip the tests, it's just that I don't think it is meaningful to have that single test count as 3.5 million tests, and in addition it makes the -verbose option incredibly slow. How about this patch? Regards, Jeroen -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: unicode.txt URL: From TZander@factotummedia.nl Mon Jan 31 12:32:00 2005 From: TZander@factotummedia.nl (Thomas Zander) Date: Mon, 31 Jan 2005 12:32:00 -0000 Subject: Unicode test noise In-Reply-To: References: Message-ID: <20050131123159.GA1875@factotummedia.nl> But it really is a lot of tests; there is nothing wrong with that. The real fix is in a better runner. Perhaps I should publish the runner I have been working on, it solves this problem already. (except that you get one page which is really big :) I think any of those changes are not a good idea. On Mon, Jan 31, 2005 at 01:13:58PM +0100, Jeroen Frijters wrote: > Michael Koch wrote: > > Am Montag, 31. Januar 2005 12:34 schrieb Jeroen Frijters: > > > Hi, > > > > > > Does anyone have any objections against this patch to eliminate the > > > noise that the unicode test generates? > > > > Why don't you just skip the tests ? You change would make the tests > > don't show up in summaries when they succeed. > > I don't want to skip the tests, it's just that I don't think it is > meaningful to have that single test count as 3.5 million tests, and in > addition it makes the -verbose option incredibly slow. > > How about this patch? > > Regards, > Jeroen -- Thomas Zander -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From zander@kde.org Sun Feb 6 20:27:00 2005 From: zander@kde.org (Thomas Zander) Date: Sun, 06 Feb 2005 20:27:00 -0000 Subject: New runner Message-ID: <200502062126.49492.zander@kde.org> Hi, I promised to continue work on a much much easier way for people to use mauve. Many of the people I know are not able to run the tests due to the dependency on the autotools. In short I plan to a) provide a jar which anyone can run using their own preferred VM b) provide simpler feedback in the form of html or even XML so everyone can put his or her results online. I'd like to present an intermediate version for feedback and perhaps for inclusion in the mauve CVS (although I'm personally quite please with darcs :) Please download and try on all your VMs; http://members.home.nl/zander/alltests.jar The resulting html of my installed vm is visible on: http://members.home.nl/zander/results/ The sources of the runner are also provided on: http://members.home.nl/zander/newRunner.tar.gz I'm still going to work on an XML format, like discussed in an earlier post so better aggregate results can be posted by VM groups online for comparison. Its not progressing as fast as I'd like; but I'm getting there :-) Anyway, this is just a "I did not forget about this just yet" message. I'd love to hear feedback on what is wrong/incomplete or great. -- Thomas Zander -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jeroen@sumatra.nl Mon Feb 7 08:55:00 2005 From: jeroen@sumatra.nl (Jeroen Frijters) Date: Mon, 07 Feb 2005 08:55:00 -0000 Subject: New runner Message-ID: Thomas Zander wrote: > Please download and try on all your VMs; > http://members.home.nl/zander/alltests.jar On my (Windows) system a bunch of tests fail because the gnu.testlet.config settings don't make sense. Also, some of the socket tests fail because they do a downcast from TestHarness to SimpleTestHarness. Thanks, Jeroen From theBohemian@gmx.net Mon Feb 7 10:10:00 2005 From: theBohemian@gmx.net (Robert Schuster) Date: Mon, 07 Feb 2005 10:10:00 -0000 Subject: ChangeLog entry Message-ID: <42074601.9040204@gmx.net> Hello Audrius, please do not forget to write a ChangeLog entry for each patch you apply. For these two patches I have done this for you: 2005-02-05 Audrius Meskauskas * gnu/testlet/javax/swing/text/html/HTML/HTML_Test.java, gnu/testlet/javax/swing/text/html/parser/AttributeList/AttributeList_test.java gnu/testlet/javax/swing/text/html/parser/DTD/DTD_test.java, gnu/testlet/javax/swing/text/html/parser/Element/Element_Test.java, gnu/testlet/javax/swing/text/html/parser/Entity/Entity_Test.java, gnu/testlet/javax/swing/text/html/parser/TagElement/TagElement_Test.java: Changed JDK tag to 1.2. 2005-02-05 Audrius Meskauskas * gnu/testlet/javax/swing/text/html/parser/AttributeList/AttributeList_test.java , gnu/testlet/javax/swing/text/html/parser/DTD/DTD_test.java, gnu/testlet/javax/swing/text/html/parser/Element/Element_Test.java, gnu/testlet/javax/swing/text/html/parser/Entity/Entity_Test.java, gnu/testlet/javax/swing/text/html/parser/TagElement/TagElement_Test.java: New tests. cu Robert From TZander@factotummedia.nl Mon Feb 7 19:41:00 2005 From: TZander@factotummedia.nl (Thomas Zander) Date: Mon, 07 Feb 2005 19:41:00 -0000 Subject: New runner In-Reply-To: References: Message-ID: <20050207194026.GA1959@factotummedia.nl> On Mon, Feb 07, 2005 at 09:54:54AM +0100, Jeroen Frijters wrote: > Thomas Zander wrote: > > Please download and try on all your VMs; > > http://members.home.nl/zander/alltests.jar > > On my (Windows) system a bunch of tests fail because the > gnu.testlet.config settings don't make sense. Also, some of the socket > tests fail because they do a downcast from TestHarness to > SimpleTestHarness. Hi, Jeroen. Thanks for your reply. I've just looked into this; when I delete the config and the SimpleTestHarness I get compile errors in (only) 9 tests. The following are easy to fix and run correctly with some modifications (read: removal of the cast): gnu/testlet/java/io/FileDescriptor/jdk11.java gnu/testlet/java/io/FileReader/jdk11.java gnu/testlet/java/io/FileWriter/jdk11.java gnu/testlet/java/io/RandomAccessFile/jdk11.java These are a bit more difficult; but I believe them to be broken by design or not usable for a 'java -jar' kind of test anyway. I'll be more specific: These 4 tests each test some socket stuff based completely on the assumtion that there is someone (an smtp host) listening on a pre-configured host/port. This is quite an assumtion that is not very usable in the proposed (portable) test-jar. gnu/testlet/java/net/Socket/SocketTest.java gnu/testlet/java/net/Socket/jdk12.java gnu/testlet/java/net/Socket/jdk13.java gnu/testlet/java/net/Socket/jdk14.java The following test tests things like being able to open a file we ship in mauve (in the same package) and other stuff thats really really basic. (like File.seperator) Quite useless to test in an environment that is shipped in a jar :-) gnu/testlet/java/io/File/jdk11.java What do you think? Should these last 5 tests be modified in any way? Or should we keep the dependency on config (and SimpleTestHarness) for them even though they have a different set of problems? Whatever we decide, I'll stop shipping those in my jar. -- Thomas Zander -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jeroen@sumatra.nl Wed Feb 9 09:25:00 2005 From: jeroen@sumatra.nl (Jeroen Frijters) Date: Wed, 09 Feb 2005 09:25:00 -0000 Subject: New runner Message-ID: Thomas Zander wrote: > Hi, Jeroen. Thanks for your reply. > I've just looked into this; when I delete the config and the > SimpleTestHarness I get compile errors in (only) 9 tests. > The following are easy to fix and run correctly with some > modifications > (read: removal of the cast): > gnu/testlet/java/io/FileDescriptor/jdk11.java > gnu/testlet/java/io/FileReader/jdk11.java > gnu/testlet/java/io/FileWriter/jdk11.java > gnu/testlet/java/io/RandomAccessFile/jdk11.java > > These are a bit more difficult; but I believe them to be > broken by design or not usable for a 'java -jar' kind of > test anyway. > I'll be more specific: > These 4 tests each test some socket stuff based completely on the > assumtion that there is someone (an smtp host) listening on a > pre-configured host/port. This is quite an assumtion that is not very > usable in the proposed (portable) test-jar. > gnu/testlet/java/net/Socket/SocketTest.java > gnu/testlet/java/net/Socket/jdk12.java > gnu/testlet/java/net/Socket/jdk13.java > gnu/testlet/java/net/Socket/jdk14.java I don't think they're inherently unusable from a jar, I'd like to see a gnu.testlet.config version that reads the settings from a properties file (or whatever) instead of hardcoding them in the auto dance. > The following test tests things like being able to open a > file we ship in mauve (in the same package) and other stuff thats > really really basic. (like File.seperator) Quite useless to test > in an environment that is shipped in a jar :-) > gnu/testlet/java/io/File/jdk11.java This is more tricky to handle, but hopefully we can figure out a way to get this test in as well. Regards, Jeroen From TZander@factotummedia.nl Wed Feb 9 09:36:00 2005 From: TZander@factotummedia.nl (Thomas Zander) Date: Wed, 09 Feb 2005 09:36:00 -0000 Subject: New runner In-Reply-To: References: Message-ID: <20050209093601.GA31991@factotummedia.nl> On Wed, Feb 09, 2005 at 10:25:03AM +0100, Jeroen Frijters wrote: > Thomas Zander wrote: > > Hi, Jeroen. Thanks for your reply. > > I've just looked into this; when I delete the config and the > > SimpleTestHarness I get compile errors in (only) 9 tests. > > The following are easy to fix and run correctly with some > > modifications > > (read: removal of the cast): > > gnu/testlet/java/io/FileDescriptor/jdk11.java > > gnu/testlet/java/io/FileReader/jdk11.java > > gnu/testlet/java/io/FileWriter/jdk11.java > > gnu/testlet/java/io/RandomAccessFile/jdk11.java > > > > These are a bit more difficult; but I believe them to be > > broken by design or not usable for a 'java -jar' kind of > > test anyway. > > I'll be more specific: > > These 4 tests each test some socket stuff based completely on the > > assumtion that there is someone (an smtp host) listening on a > > pre-configured host/port. This is quite an assumtion that is not very > > usable in the proposed (portable) test-jar. > > gnu/testlet/java/net/Socket/SocketTest.java > > gnu/testlet/java/net/Socket/jdk12.java > > gnu/testlet/java/net/Socket/jdk13.java > > gnu/testlet/java/net/Socket/jdk14.java > > I don't think they're inherently unusable from a jar, I'd like to see a > gnu.testlet.config version that reads the settings from a properties > file (or whatever) instead of hardcoding them in the auto dance. The way the config settings are shipped is not the issue here; the question where a socket can connect to that is reachable from the testing machine so the test does not fail because of wrong reasons is a bigger problem. And the one I tried to list above. When we solve that issue then we can think about how to config it. I have no idea how to do so; so I'm open to suggestions! > > The following test tests things like being able to open a > > file we ship in mauve (in the same package) and other stuff thats > > really really basic. (like File.seperator) Quite useless to test > > in an environment that is shipped in a jar :-) > > gnu/testlet/java/io/File/jdk11.java > > This is more tricky to handle, but hopefully we can figure out a way to > get this test in as well. When we are actually running this test we already did a 'java -jar' and we found several classes in that jar. Does that not imply that the tests in that class will pass? -- Thomas Zander -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jeroen@sumatra.nl Wed Feb 9 09:48:00 2005 From: jeroen@sumatra.nl (Jeroen Frijters) Date: Wed, 09 Feb 2005 09:48:00 -0000 Subject: New runner Message-ID: Thomas Zander wrote: > The way the config settings are shipped is not the issue here; the > question where a socket can connect to that is reachable from > the testing machine so the test does not fail because of wrong > reasons is a bigger problem. I thought the tests only connect to an SMTP server? Presumably most people have access to an SMTP server. You could ask a question in the test configuration step (where you ask about awt tests). > When we are actually running this test we already did a 'java > -jar' and we found several classes in that jar. Does that not > imply that the tests in that class will pass? Not necessarily. With IKVM, for example, you can pre-compile the jar into a .NET executable and run that directly, that way no Java I/O is involved in starting up the tests. I'm sure a similar scenario exists for gcj. Regards, Jeroen From mckinlay@redhat.com Wed Feb 16 19:11:00 2005 From: mckinlay@redhat.com (Bryce McKinlay) Date: Wed, 16 Feb 2005 19:11:00 -0000 Subject: Class choosing script - Tag sensitivity Message-ID: <42139AC0.5070209@redhat.com> The choose-classes script seems to be very sensitive to extra whitespace characters around the tags. For example, the test below was not being run due to an extra space. Perhaps some sed/egrep can fix this? In the mean time, this patch fixes the one I found. Bryce 2005-02-16 Bryce McKinlay * gnu/testlet/java/lang/Class/serialization.java: Remove stray space from 'Tags'. --- gnu/testlet/java/lang/Class/serialization.java 17 Jan 2005 17:03:24 -0000 1.2 +++ gnu/testlet/java/lang/Class/serialization.java 16 Feb 2005 19:06:59 -0000 @@ -1,4 +1,4 @@ -// Tags: JDK1.2 +// Tags: JDK1.2 // Copyright (C) 2005 David Gilbert From mckinlay@redhat.com Sat Feb 19 03:44:00 2005 From: mckinlay@redhat.com (Bryce McKinlay) Date: Sat, 19 Feb 2005 03:44:00 -0000 Subject: JLS vs JDK tags Message-ID: <4216B630.2030109@redhat.com> Does it make any sense to keep JLS tags in mauve? Only a handful of test cases use them. I'd like to simplify the tags a little and convert JLS1.2 -> JDK1.2, etc. Bryce From tromey@redhat.com Sat Feb 19 16:59:00 2005 From: tromey@redhat.com (Tom Tromey) Date: Sat, 19 Feb 2005 16:59:00 -0000 Subject: JLS vs JDK tags In-Reply-To: <4216B630.2030109@redhat.com> References: <4216B630.2030109@redhat.com> Message-ID: Bryce> Does it make any sense to keep JLS tags in mauve? Only a handful of Bryce> test cases use them. I'd like to simplify the tags a little and Bryce> convert JLS1.2 -> JDK1.2, etc. I never really understood the distinction. I say nuke 'em. Tom From mckinlay@redhat.com Mon Feb 21 15:52:00 2005 From: mckinlay@redhat.com (Bryce McKinlay) Date: Mon, 21 Feb 2005 15:52:00 -0000 Subject: JLS vs JDK tags In-Reply-To: References: <4216B630.2030109@redhat.com> Message-ID: <421A03AA.6040200@redhat.com> Tom Tromey wrote: >Bryce> Does it make any sense to keep JLS tags in mauve? Only a handful of >Bryce> test cases use them. I'd like to simplify the tags a little and >Bryce> convert JLS1.2 -> JDK1.2, etc. > >I never really understood the distinction. I say nuke 'em. > > OK - I'm checking in this patch. Regards Bryce -------------- next part -------------- A non-text attachment was scrubbed... Name: mauve-tags.diff Type: text/x-patch Size: 23514 bytes Desc: not available URL: From mark@klomp.org Mon Feb 21 16:03:00 2005 From: mark@klomp.org (Mark Wielaard) Date: Mon, 21 Feb 2005 16:03:00 -0000 Subject: JLS vs JDK tags In-Reply-To: References: <4216B630.2030109@redhat.com> Message-ID: <1109001922.8395.14.camel@localhost.localdomain> Hi, On Sat, 2005-02-19 at 09:57 -0700, Tom Tromey wrote: > Bryce> Does it make any sense to keep JLS tags in mauve? Only a handful of > Bryce> test cases use them. I'd like to simplify the tags a little and > Bryce> convert JLS1.2 -> JDK1.2, etc. > > I never really understood the distinction. I say nuke 'em. Agreed! It probably comes from when the JLS (Java Language Specification) books were the oonly place were the core packages were described in detail. They dropped the description of the libraries in later editions though. I believe the term JDK wasn't used in the early days. I remember talking about the JCL (1e edition, 2e edition, supplemental) because that is the abbrivation of the Addison Wesley book series most of us use to lookup details not found in other places. 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 taoufik@dms.at Wed Mar 2 14:27:00 2005 From: taoufik@dms.at (Taoufik EL AOUMARI) Date: Wed, 02 Mar 2005 14:27:00 -0000 Subject: Jacks tests for the new java spec Message-ID: <4225CDEA.6090407@dms.at> Hello, Are there gonna be tests for the jsr-201 (Enumerations, Autoboxing, Enhanced for loops and Static Import) in the next Jacks updates ? Is there a possiblity to add our tests made for the jsr-201 ? Regards -- Taoufik From robilad@yahoo.com Wed Mar 2 16:12:00 2005 From: robilad@yahoo.com (Dalibor Topic) Date: Wed, 02 Mar 2005 16:12:00 -0000 Subject: Jacks tests for the new java spec In-Reply-To: <4225CDEA.6090407@dms.at> Message-ID: <20050302161230.42470.qmail@web51010.mail.yahoo.com> --- Taoufik EL AOUMARI wrote: > Hello, > > Are there gonna be tests for the jsr-201 (Enumerations, Autoboxing, > Enhanced for loops and Static Import) in the next Jacks updates ? > > Is there a possiblity to add our tests made for the jsr-201 ? I think it would be great to have tests for the new jsrs added to jacks, too. You can ask Tom Tromey for cvs access to mauve/jacks. cheers, dalibor topic p.s. there is an updated draft of the JLS3 apparently without insane click-through licenses at http://java.sun.com/docs/books/jls/jls-proposed-changes.html __________________________________ Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web http://birthday.yahoo.com/netrospective/ From tromey@redhat.com Wed Mar 2 21:13:00 2005 From: tromey@redhat.com (Tom Tromey) Date: Wed, 02 Mar 2005 21:13:00 -0000 Subject: Jacks tests for the new java spec In-Reply-To: <20050302161230.42470.qmail@web51010.mail.yahoo.com> References: <20050302161230.42470.qmail@web51010.mail.yahoo.com> Message-ID: >> Are there gonna be tests for the jsr-201 (Enumerations, Autoboxing, >> Enhanced for loops and Static Import) in the next Jacks updates ? >> >> Is there a possiblity to add our tests made for the jsr-201 ? Yeah, definitely. Dalibor> I think it would be great to have tests for the new jsrs Dalibor> added to jacks, too. You can ask Tom Tromey for cvs access Dalibor> to mauve/jacks. Fill out the handy form: http://sources.redhat.com/cgi-bin/pdw/ps_form.cgi There are a few jacks tests for new language features already. And I think I have some more lying around that I haven't checked in yet... nothing very comprehensive though. Tom From rmathew@gmail.com Wed Mar 9 06:21:00 2005 From: rmathew@gmail.com (Ranjit Mathew) Date: Wed, 09 Mar 2005 06:21:00 -0000 Subject: Please update Jacks's "jacks.html" Message-ID: Hi, In the "Install Requirements" section of: http://sources.redhat.com/cgi-bin/cvsweb.cgi/~checkout~/jacks/jacks.html?cvsroot=mauve the instructions for fetching Jacks from CVS are incorrect in the light of the move to Mauve's CVS. Can someone please correct it? That aside, the Jacks logo in the top-left is not displayed correctly: a. It needs "?cvsroot=mauve" appended to the reference. b. Even then the MIME-type returned is incorrect for a PNG image. Thanks, Ranjit. -- Ranjit Mathew Email: rmathew AT gmail DOT com Bangalore, INDIA. Web: http://ranjitmathew.hostingzero.com/ From audriusa@bluewin.ch Thu Mar 10 14:19:00 2005 From: audriusa@bluewin.ch (Meskauskas Audrius) Date: Thu, 10 Mar 2005 14:19:00 -0000 Subject: A place for the Classpath specific tests Message-ID: <000701c5257c$0afc0c70$2101a8c0@computername> For a project as large as Classpath, it would be good to have a tests for all important classes. Apart the standard java.* and javax.* , this also includes the Classpath specific classes from gnu.* namespace. In some packages this namespace contains many classes, having hundreds lines of the working code. Even it they run ok today, staying without tests leaves a gap for the future regression bugs. It is not immediatly clear if such tests can be contributed to Mauve. With such tests the Mauve would not compile without the newest version of Classpath. Classpath has its own small test suite. While not very popular and requiring to write all tests in the form of the executable classes, it could be treated as an alternative. Before committing Classpath specific tests to Mauve, I would like to discuss this question in the list. Regards Audrius From konqueror@gmx.de Thu Mar 10 16:07:00 2005 From: konqueror@gmx.de (Michael Koch) Date: Thu, 10 Mar 2005 16:07:00 -0000 Subject: A place for the Classpath specific tests In-Reply-To: <000701c5257c$0afc0c70$2101a8c0@computername> References: <000701c5257c$0afc0c70$2101a8c0@computername> Message-ID: <20050310160510.GI4737@papacharly.konqueror.de> On Thu, Mar 10, 2005 at 03:18:33PM +0100, Meskauskas Audrius wrote: > For a project as large as Classpath, it would be good to > have a tests for all important classes. Apart the standard > java.* and javax.* , this also includes the Classpath > specific classes from gnu.* namespace. In some > packages this namespace contains many classes, > having hundreds lines of the working code. Even it they run ok today, staying without tests leaves a gap for > the future regression bugs. It is not immediatly clear if such tests can be contributed to > Mauve. With such tests the Mauve would not compile > without the newest version of Classpath. Classpath has its own small test suite. While not very popular > and requiring to write all tests in the form of the executable > classes, it could be treated as an alternative. > > Before committing Classpath specific tests to Mauve, I would > like to discuss this question in the list. We should really put the tests in muave. Into a specific CVS module if needed/wanted. We have already classpath specific tests in Mauve. If we consider an extra module is need then we should move them into it. Michael -- Java Trap: http://www.gnu.org/philosophy/java-trap.html From robilad@kaffe.org Thu Mar 10 16:21:00 2005 From: robilad@kaffe.org (Dalibor Topic) Date: Thu, 10 Mar 2005 16:21:00 -0000 Subject: A place for the Classpath specific tests In-Reply-To: <20050310160510.GI4737@papacharly.konqueror.de> References: <000701c5257c$0afc0c70$2101a8c0@computername> <20050310160510.GI4737@papacharly.konqueror.de> Message-ID: <423073F3.6000102@kaffe.org> Michael Koch wrote: > On Thu, Mar 10, 2005 at 03:18:33PM +0100, Meskauskas Audrius wrote: > >>For a project as large as Classpath, it would be good to >>have a tests for all important classes. Apart the standard >>java.* and javax.* , this also includes the Classpath >>specific classes from gnu.* namespace. In some >>packages this namespace contains many classes, >>having hundreds lines of the working code. Even it they run ok today, staying without tests leaves a gap for >>the future regression bugs. It is not immediatly clear if such tests can be contributed to >>Mauve. With such tests the Mauve would not compile >>without the newest version of Classpath. Classpath has its own small test suite. While not very popular >>and requiring to write all tests in the form of the executable >>classes, it could be treated as an alternative. >> >>Before committing Classpath specific tests to Mauve, I would >>like to discuss this question in the list. > > > We should really put the tests in muave. Into a specific CVS module if > needed/wanted. We have already classpath specific tests in Mauve. If we > consider an extra module is need then we should move them into it. I'd say mauve, too. If a test is Classpath specific, then it can be tagged as such. cheers, dalibor topic From tromey@redhat.com Sat Mar 12 19:24:00 2005 From: tromey@redhat.com (Tom Tromey) Date: Sat, 12 Mar 2005 19:24:00 -0000 Subject: A place for the Classpath specific tests In-Reply-To: <423073F3.6000102@kaffe.org> References: <000701c5257c$0afc0c70$2101a8c0@computername> <20050310160510.GI4737@papacharly.konqueror.de> <423073F3.6000102@kaffe.org> Message-ID: Dalibor> I'd say mauve, too. If a test is Classpath specific, then it Dalibor> can be tagged as such. I agree. We already put Classpath regression tests into Mauve. For things that are truly Classpath-specific, say tests for gnu.*, we can just invent a new "classpath" tag and mention it in README. Tom From mark@klomp.org Tue Mar 15 17:37:00 2005 From: mark@klomp.org (Mark Wielaard) Date: Tue, 15 Mar 2005 17:37:00 -0000 Subject: A place for the Classpath specific tests In-Reply-To: References: <000701c5257c$0afc0c70$2101a8c0@computername> <20050310160510.GI4737@papacharly.konqueror.de> <423073F3.6000102@kaffe.org> Message-ID: <1110908210.1186.53.camel@localhost> Hi, On Sat, 2005-03-12 at 12:21 -0700, Tom Tromey wrote: > Dalibor> I'd say mauve, too. If a test is Classpath specific, then it > Dalibor> can be tagged as such. > > I agree. We already put Classpath regression tests into Mauve. For > things that are truly Classpath-specific, say tests for gnu.*, we can > just invent a new "classpath" tag and mention it in README. OK. How about the following patch to the README: --- README 4 Jan 2005 20:53:30 -0000 1.20 +++ README 15 Mar 2005 17:34:46 -0000 @@ -46,6 +46,15 @@ JDK1.1 Run JDK1.1 tests only JDK1.2 Run JDK1.2 tests only + * The GNU_CLASSPATH tag selects and runs tests specific to the + (internal) core classes of the Free Software Foundation GNU Classpath + implementation (available from http://www.gnu.org/software/classpath) + on which a lot of free runtimes and compilers are build (but which are + not guaranteed to be available on all platforms). + These tests can be enable by adding GNU_CLASSPATH to your KEYS variable + and disabled by adding !GNU_CLASSPATH to the KEYS variable. + All such tests are in subdirectories under gnu/testlet/classpath. + If an otherwise unrecognized tag QUUX is seen, and the file `mauve-QUUX' exists in the mauve source directory, then the contents of this file are treated as a list of tags. For instance, here is the By having a tag and a special subdirectory for these tests it should be simple to enable/disable these special tests for the various ways people run mauve (by hand, make, batch_run, ant script, etc). Then we would need to move and retag the following files: gnu/testlet/gnu/javax/swing/text/html/parser/support/Parser/ParserEntityResolverTest.java gnu/testlet/gnu/javax/swing/text/html/parser/support/Parser/ParserTest.java gnu/testlet/gnu/javax/swing/text/html/parser/support/Parser/parameterDefaulter_Test.java gnu/testlet/gnu/javax/swing/text/html/parser/support/Parser/textPreProcessor_Test.java gnu/testlet/gnu/javax/swing/text/html/parser/support/low/Buffer/Buffer_Test.javagnu/testlet/gnu/javax/swing/text/html/parser/support/low/Constants/Constants_Test.java gnu/testlet/gnu/javax/swing/text/html/parser/support/low/ReaderTokenizer/ReaderTokenizer_Test.java Did I miss any? If people agree this is a good thing I will update the choose script and batch_run to understand the new GNU_CLASSPATH tag. 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 tromey@redhat.com Tue Mar 15 17:55:00 2005 From: tromey@redhat.com (Tom Tromey) Date: Tue, 15 Mar 2005 17:55:00 -0000 Subject: A place for the Classpath specific tests In-Reply-To: <1110908210.1186.53.camel@localhost> References: <000701c5257c$0afc0c70$2101a8c0@computername> <20050310160510.GI4737@papacharly.konqueror.de> <423073F3.6000102@kaffe.org> <1110908210.1186.53.camel@localhost> Message-ID: Mark> OK. How about the following patch to the README: Looks good. Mark> By having a tag and a special subdirectory for these tests it should be Mark> simple to enable/disable these special tests for the various ways people Mark> run mauve (by hand, make, batch_run, ant script, etc). I think just putting them in a directory named after their class, like we do for everything, will suffice. Using 'gnu.javax.swing....' is just as selectable -- and obviously classpath-specific, IMO -- as 'classpath.gnu.javax.swing...' But I don't have a strong opinion on it. Tom