From mark@klomp.org Wed Oct 5 21:11:00 2005 From: mark@klomp.org (Mark Wielaard) Date: Wed, 05 Oct 2005 21:11:00 -0000 Subject: Wrong exception thrown in AccessContoller In-Reply-To: References: <4327F292.7040604@menlina.com> Message-ID: <1128546663.12848.47.camel@localhost.localdomain> Hi, On Sat, 2005-09-17 at 09:47 -0600, Tom Tromey wrote: > >>>>> "Nicolas" == Nicolas Geoffray writes: > > Nicolas> I attached a patch (it's patched against 0.13, but it's ok for 0.18) > Nicolas> and a java program which execution is different between sun and gnu > Nicolas> classpath. > > Could you turn this into a Mauve test? I created the attached Mauve test for it. And tested that without the patch we have one failure, with the patch all pass. Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: doPrivileged.java Type: text/x-java Size: 2371 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 fabien.duminy@laposte.net Sat Oct 8 14:02:00 2005 From: fabien.duminy@laposte.net (Fabien DUMINY) Date: Sat, 08 Oct 2005 14:02:00 -0000 Subject: RFA: Can I commit a bug fix in CreateTags.java ? In-Reply-To: <43307E24.8060709@webmails.com> References: <432BFCD0.7030305@laposte.net> <20050917115254.GI19178@asterix.konqueror.de> <432C09CC.3070402@users.sourceforge.net> <432EC250.7070708@object-refinery.com> <43307E24.8060709@webmails.com> Message-ID: <4347D170.4010603@laposte.net> Hi all, Is there anybody that can test that under linux ? If nobody answer I will assume that it works under Linux and will commit that to CVS. Fabien. Fabien DUMINY a ??crit : > David Gilbert a ??crit : > >> Fabien DUMINY wrote: >> >>> Michael Koch a ??crit : >>> >>>> On Sat, Sep 17, 2005 at 01:24:00PM +0200, Fabien DUMINY wrote: >>>> >>>> >>>>> Hi, >>>>> I found and fixed a bug in CreateTags. The ';' wasn't removed from >>>>> the package declaration and it was written in the testlet className. >>>>> >>>>> Can I commit the bug fix (when I will have the rights to do) ? >>>>> I ask you that question because I read that such modification (in >>>>> the core of Mauve, not in the testlets) should be discussed here. >>>>> >>>> >>>> >>>> >>>> >>>> Please send a patch representing this change here. >>>> >>>> >>>> Michael >>>> >>>> >>> Here is the patch (joined file). >>> >>> Fabien. >>> >>> ------------------------------------------------------------------------ >>> >>> >>> Index: CreateTags.java >>> =================================================================== >>> RCS file: /cvs/mauve/mauve/gnu/testlet/runner/CreateTags.java,v >>> retrieving revision 1.1 >>> diff -u -r1.1 CreateTags.java >>> --- CreateTags.java 1 Jul 2005 18:33:43 -0000 1.1 >>> +++ CreateTags.java 17 Sep 2005 12:14:22 -0000 >>> @@ -130,7 +130,10 @@ >>> tags = line; >>> } >>> else if(buf.indexOf("package ") == 0) >>> - pckage = buf.substring(8, buf.length()-1); >>> + { >>> + int idx = buf.lastIndexOf(";"); >>> + pckage = buf.substring(8, idx); >>> + } >>> buf = new StringBuffer(); >>> maxLines--; >>> } >>> >>> >> I ran the CreateTags program (for the first time) and didn't see a >> problem. Here's the first few lines of the output file: >> >> [JDK1.0] >> gnu.testlet.java.io.LineNumberInputStream.Test >> gnu.testlet.java.io.FilterInputStream.MarkReset >> gnu.testlet.java.io.FilterInputStream.SimpleRead >> gnu.testlet.java.io.BufferedInputStream.ProtectedVars >> gnu.testlet.java.io.BufferedInputStream.MarkReset >> gnu.testlet.java.io.BufferedInputStream.ZeroRead >> gnu.testlet.java.io.BufferedInputStream.BigMark >> gnu.testlet.java.io.BufferedInputStream.SimpleRead >> >> What do you get when you run it? What are you running it with? (I >> tried both JamVM with Classpath CVS and Sun's JDK1.4.2_08 on GNU Linux). >> >> Regards, >> >> Dave >> >> > I tried with Sun's jdk 1.5.0_03 and Classpath under eclipse > 3.2M1/Windows XP. > Without that patch I get something like that > > gnu.testlet.java.io.LineNumberInputStream;.Test > gnu.testlet.java.io.FilterInputStream;.MarkReset > ... > So, for me, the ';' at the end of the package declaration is not removed. > I think that it is due to the fact that under Windows end of line are > on 2 characters CR LF ("\r\n") and Linux it is only 1 character. > > In fact, the patch give something more safe even on Linux because we > can be sure that nobody will add blank characters after the ';' on the > package declaration line. > Ok, I must say that I forgot to add a trim() on the package name, in > case of there were some blank(s) between it and the ';'. > ... maybe the ';' can also be on the next line but I don't thnik that > will occure. > > From mark@klomp.org Wed Oct 12 12:42:00 2005 From: mark@klomp.org (Mark Wielaard) Date: Wed, 12 Oct 2005 12:42:00 -0000 Subject: Thread.sleep() tests updated Message-ID: <1129120935.5922.7.camel@localhost.localdomain> Hi, The Thread.sleep() tests were not really deterministic. This fixes that by explicitly waiting for the helper thread to sleep and never using "zero sleeptime". The downside is that the tests now takes between 10 and 12 seconds because of the explicit sleep() statements. The upside is that the results are now deterministic. 2005-10-12 Mark Wielaard * gnu/testlet/java/lang/Thread/sleep.java: Explicitly wait for helper thread to start sleeping. Add extra debug info. Committed, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: sleep.diff Type: text/x-patch Size: 6186 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 Wed Oct 12 17:44:00 2005 From: mark@klomp.org (Mark Wielaard) Date: Wed, 12 Oct 2005 17:44:00 -0000 Subject: registerValidation update Message-ID: <1129139080.5922.20.camel@localhost.localdomain> Hi, This updates the ObjectInputStream.registerValidation() test to test whether it is only called one in the deserialization tree (the this reference) and whether you can add validators at any time and whether the priority order is observed. 2005-10-12 Mark Wielaard * gnu/testlet/java/io/ObjectInputStream/registerValidation.java: Check fields and priority order. * gnu/testlet/java/io/ObjectInputStream/TestObjectInputValidation.java: Add self reference, register multiple times with different priorities, add equals(). I am currently testing a patch for GNU Classpath. David since you wrote the original test you might have seen a real world program using this feature. If so and this is a Free Software program could you let me know so I can also test my patch against that. Thanks, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: registerValidation.patch Type: text/x-patch Size: 4274 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 david.gilbert@object-refinery.com Wed Oct 12 18:02:00 2005 From: david.gilbert@object-refinery.com (David Gilbert) Date: Wed, 12 Oct 2005 18:02:00 -0000 Subject: registerValidation update In-Reply-To: <1129139080.5922.20.camel@localhost.localdomain> References: <1129139080.5922.20.camel@localhost.localdomain> Message-ID: <434D5DC1.5000804@object-refinery.com> Mark Wielaard wrote: >Hi, > >This updates the ObjectInputStream.registerValidation() test to test >whether it is only called one in the deserialization tree (the this >reference) and whether you can add validators at any time and whether >the priority order is observed. > >2005-10-12 Mark Wielaard > > * gnu/testlet/java/io/ObjectInputStream/registerValidation.java: > Check fields and priority order. > * gnu/testlet/java/io/ObjectInputStream/TestObjectInputValidation.java: > Add self reference, register multiple times with different priorities, > add equals(). > >I am currently testing a patch for GNU Classpath. >David since you wrote the original test you might have seen a real world >program using this feature. If so and this is a Free Software program >could you let me know so I can also test my patch against that. > > > Hi Mark, There is one case of this in JFreeChart, in the AbstractDataset class. I didn't write the code, and I'd have to go and study it to figure out what it does...most likely I wrote the Mauve test while trying to understand the mechanism in general. I'm out of time for today, but can probably look at this in the morning... Regards, Dave From mark@klomp.org Wed Oct 12 19:38:00 2005 From: mark@klomp.org (Mark Wielaard) Date: Wed, 12 Oct 2005 19:38:00 -0000 Subject: registerValidation update In-Reply-To: <434D5DC1.5000804@object-refinery.com> References: <1129139080.5922.20.camel@localhost.localdomain> <434D5DC1.5000804@object-refinery.com> Message-ID: <1129145925.5922.32.camel@localhost.localdomain> Hi David, On Wed, 2005-10-12 at 19:02 +0000, David Gilbert wrote: > There is one case of this in JFreeChart, in the AbstractDataset class. > I didn't write the code, and I'd have to go and study it to figure out > what it does...most likely I wrote the Mauve test while trying to > understand the mechanism in general. I'm out of time for today, but can > probably look at this in the morning... Thanks. I looked at the code and that should work now. It is an interesting use of validation. (After the object is completely deserialized and the listeners are attached it fires an update event to them.) But I wasn't really able to run the unit tests of JFreeChart easily (some free swing breakage makes it impossible to select a test...). If you are able to run the unittests against a recent GNU Classpath from CVS that would be appreciated. I checked in my latest fixes now. 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 hendrich@informatik.uni-hamburg.de Fri Oct 14 13:56:00 2005 From: hendrich@informatik.uni-hamburg.de (Norman Hendrich) Date: Fri, 14 Oct 2005 13:56:00 -0000 Subject: classpath+mauve Message-ID: <200510141356.j9EDuS4O015670@rzdspc1.informatik.uni-hamburg.de> Hello David and Audrius, first of all, thanks for your answers to my mauve-setup question(s). I tried the MakeTestClassList program, which seems to work fine. However, after spending another few hours trying to get the whole testsuite running, my worst fears are confirmed... To summarize: * writing new testcases is easy * running individual testcases is easy (from the shell or eclipse) * running parts of the testsuite via an index file works. * BUT there is no easy way to run the whole testsuite. A developer first has to create a custom list of exclusion testcases, before running the remaining fraction of the testsuite... Despite David's nice program, command line parameters, and exclusion testcase lists, I did not manage to run the whole testsuite reliably against today's classpath CVS. After passing some tests, jamvm encounters a test that throws some unexpected exception, runs into a stack-overflow, or complains about an IllegalStateException in loadClass(). In all cases, gnu.testlet.runner.Mauve does not run to the end, and the user doesn't even get the summary of test results. This basically leads to the situation that a developer needs to run the testsuite, try to understand the last error, remove the problematic test question from the list of testcases, and re-run. I tried this from scratch without David's exclusion list, but stopped after the first 20 iterations of this (with no end in sight). I then proceeded to remove larger chunks of the tests, and finally got a test report - but this in turn means that many tests were never run at all. --- The current all-testcases-at-once model used by gnu.testlet.runner.Mauve is not robust enough to survive all tests, while the opposite strategy of running each test in a new VM via (Simple)TestHarness is extremely wasteful due to the VM initialization overhead. Perhaps we could switch to a two-level model, where an outer process watches the progress of the inner runner process, and restarts the inner process whenever this crashes or deadlocks? Also, a test that doesn't compile should be marked as FAIL instead of stopping the testsuite to run at all... - Norman PS: a matrix of today's mauve experiments: * mauve+jdk1.5.0 with 'make check': doesn't even compile * mauve+jdk1.4.2 with 'make check': works, but subset of tests only * mauve+jdk1.4.2 with 'ant': doesn't even compile * mauve+jdk1.5.0 with 'ant': doesn't even compile * mauve+classpath+jamvm+jikes: compiles, but crashes on lots of testcases From konqueror@gmx.de Fri Oct 14 14:02:00 2005 From: konqueror@gmx.de (Michael Koch) Date: Fri, 14 Oct 2005 14:02:00 -0000 Subject: classpath+mauve In-Reply-To: <200510141356.j9EDuS4O015670@rzdspc1.informatik.uni-hamburg.de> References: <200510141356.j9EDuS4O015670@rzdspc1.informatik.uni-hamburg.de> Message-ID: <20051014140125.GC27035@asterix.konqueror.de> On Fri, Oct 14, 2005 at 03:56:28PM +0200, Norman Hendrich wrote: > Hello David and Audrius, > > first of all, thanks for your answers to my mauve-setup question(s). > I tried the MakeTestClassList program, which seems to work fine. > However, after spending another few hours trying to get the whole > testsuite running, my worst fears are confirmed... To summarize: > > * writing new testcases is easy > > * running individual testcases is easy (from the shell or eclipse) > > * running parts of the testsuite via an index file works. > > * BUT there is no easy way to run the whole testsuite. A developer > first has to create a custom list of exclusion testcases, before > running the remaining fraction of the testsuite... Not true. I just use the batch_run utility to run them all. I know that Mark uses this too. Cheers, Michael -- Escape the Java Trap with GNU Classpath! http://www.gnu.org/philosophy/java-trap.html Join the community at http://planet.classpath.org/ From cbj@nc.rr.com Fri Oct 14 14:31:00 2005 From: cbj@nc.rr.com (Brian Jones) Date: Fri, 14 Oct 2005 14:31:00 -0000 Subject: classpath+mauve In-Reply-To: <20051014140125.GC27035@asterix.konqueror.de> References: <200510141356.j9EDuS4O015670@rzdspc1.informatik.uni-hamburg.de> <20051014140125.GC27035@asterix.konqueror.de> Message-ID: <434FC129.3030603@nc.rr.com> Michael Koch wrote: >On Fri, Oct 14, 2005 at 03:56:28PM +0200, Norman Hendrich wrote: > > >>Hello David and Audrius, >> >>first of all, thanks for your answers to my mauve-setup question(s). >>I tried the MakeTestClassList program, which seems to work fine. >>However, after spending another few hours trying to get the whole >>testsuite running, my worst fears are confirmed... To summarize: >> >>* writing new testcases is easy >> >>* running individual testcases is easy (from the shell or eclipse) >> >>* running parts of the testsuite via an index file works. >> >>* BUT there is no easy way to run the whole testsuite. A developer >> first has to create a custom list of exclusion testcases, before >> running the remaining fraction of the testsuite... >> >> > >Not true. I just use the batch_run utility to run them all. I know that >Mark uses this too. > > >Cheers, >Michael > > Yes, due to the nature of how a JVM can fail... especially with respect to hanging and doing nothing, you have to wrap execution of each test case in a fashion that will kill the JVM if it does not exit in a reasonable period of time. I think this batch_run utility does that. I used to have a nice little set of scripts that did something similar and created pretty graphs. From nicolas.geoffray@menlina.com Mon Oct 17 17:13:00 2005 From: nicolas.geoffray@menlina.com (Nicolas Geoffray) Date: Mon, 17 Oct 2005 17:13:00 -0000 Subject: tests with rmic Message-ID: <4353DBB0.10807@menlina.com> Hi everyone, I found what might be a bug in gnu classpath and I would like to commit a testlet in mauve. The thing is, my test involves compiling with rmic and launching two gnu classpath jvms. I never commited in mauve, but seeing other testlets, i didn't found ways to commit such a test. I attached the files. This is how you launch the test: gcj -C Main.java gcj -C ReceiveObject.java gcj -C ReceiveObjectImpl.java rmic ReceiveObjectImpl rmiregistry & jamvm ReceiveObjectImpl & jamvm Main Any suggestions? Thanks, Nicolas -------------- next part -------------- A non-text attachment was scrubbed... Name: Main.java Type: text/x-java Size: 443 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ReceiveObject.java Type: text/x-java Size: 179 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ReceiveObjectImpl.java Type: text/x-java Size: 535 bytes Desc: not available URL: From abalkiss@redhat.com Mon Oct 17 18:56:00 2005 From: abalkiss@redhat.com (Anthony Balkissoon) Date: Mon, 17 Oct 2005 18:56:00 -0000 Subject: FYI: new test for InputMap Message-ID: <1129575410.2838.24.camel@tony.toronto.redhat.com> This new test checks that the keys() method for javax.swing.InputMap returns null when the map is empty. We currently fail this test. 2005-10-17 Anthony Balkissoon * gnu/testlet/javax/swing/InputMap: New directory. * gnu/testlet/javax/swing/InputMap/newMapKeysNull.java: New test. --Tony -------------- next part -------------- A non-text attachment was scrubbed... Name: newMapKeysNull.java Type: text/x-java Size: 1456 bytes Desc: not available URL: From jikes@cabbey.net Tue Oct 18 02:37:00 2005 From: jikes@cabbey.net (Chris Abbey) Date: Tue, 18 Oct 2005 02:37:00 -0000 Subject: tests with rmic In-Reply-To: <4353DBB0.10807@menlina.com> References: <4353DBB0.10807@menlina.com> Message-ID: <200510172137.28552.jikes@cabbey.net> On Monday 17 October 2005 12:13, Nicolas Geoffray wrote: > rmiregistry & > jamvm ReceiveObjectImpl & > jamvm Main > > Any suggestions? Mauve style guidelines aside (because I have no idea what they would encourage here), I'd encourage you not to start the default rmiregistry in any test framework, as it creates a dependency on the runtime environment. (Specifically that whoever is running the testcase doesn't already have an rmi registry up.) Instead, I'd suggest that the ReceiveObjectImpl class binds your own registry to an off the wall port that you've selected, and then in the test case, you locate on that same port. This does create the problem that you'll have to pick a port that's not in use, one solution to that is to use a fallback pattern to select the port and write it to a file that the test case loads to find out where the registry is. Also, by creating the registry in the test server, you ensure that it goes away when the test is done. The test server should also have a dead man's switch to exit after a finite amount of time, otherwise you have to try to ensure some cleanup externally, and most of the ways I've seen of doing that have some *bad* side effects. (case in point at work, we have a few very large shared development machines, occasionally, folks would get failures in some of the test buckets they were running that just didn't make sense... further digging found a test case like this that wanted to clean up after itself, so it did a ps list and killed any task with it's name in it. This works fine as long as there is only one instance of the test suite running. Another routinely killed the snmpd on the system, because the test case fired up it's own with a unique config, on the default port, and then when the test failed because it was running iwht the wrong snmpd config, it blasted all instances of snmpd on the box.) Anyway, client/server test cases usually need some extra thought put into them was my only point before I started rambling. /me re-lurks now. -- Never make a technical decision based upon the politics of the situation. Never make a political decision based upon technical issues. The only place these realms meet is in the mind of the unenlightened. -- Geoffrey James, The Zen of Programming From audriusa@bluewin.ch Tue Oct 18 08:41:00 2005 From: audriusa@bluewin.ch (Meskauskas Audrius) Date: Tue, 18 Oct 2005 08:41:00 -0000 Subject: tests with rmic! In-Reply-To: <4353DBB0.10807@menlina.com> References: <4353DBB0.10807@menlina.com> Message-ID: <4354B543.1090404@bluewin.ch> Hi, Nicolas, Nice idea, great to have at least any java.rmi rests! The current testing situation with this package is deeply tragical, the coverage being plain zero. And it is possible to find random talks on the web like "how reliable they (GNU Classpath) RMI implementation is? Does it work?". Any tests are very welcome. I think it would be a good idea to write Mauve tests as the independent modules that run on a single virtual machine and does call external tools. The most of the current tests are written this way. Here are several suggestions how to make an ordinary Mauve test that would not need to cross the boundaries of the current virtual machine to run: 1. Instead of starting three independent virtual machines (one for server, one for client and one for the naming service), you can just start three threads. When all cleanup problems, if any, will be restricted to the current run of the test suite. 2. Instead of invoking rmic from inside the Mauve test, run it once with the -keep key and just add the generated source code file to your path. Such test would be easier to debug. 3. When all threads are together and can share static variables, all cleanup is trivial (use try {} finally { clean }). Nicolas Geoffray wrote: > Hi everyone, > > I found what might be a bug in gnu classpath and I would like to > commit a testlet in mauve. The thing is, my test involves compiling > with rmic and launching two gnu classpath jvms. I never commited in > mauve, but seeing other testlets, i didn't found ways to commit such a > test. > > I attached the files. This is how you launch the test: > > gcj -C Main.java > gcj -C ReceiveObject.java > gcj -C ReceiveObjectImpl.java > rmic ReceiveObjectImpl > > rmiregistry & > jamvm ReceiveObjectImpl & > jamvm Main > > > Any suggestions? > > Thanks, > Nicolas > >------------------------------------------------------------------------ > >import java.rmi.Naming; > >public class Main{ > > class Foo implements java.io.Serializable{} > > class Bar implements java.io.Serializable{ > Foo f = new Foo(); > } > > public static void main(String[]args){ > > try{ > Bar b = new Bar(); > ReceiveObject ref = (ReceiveObject) Naming.lookup("rmi://localhost/ReceiveObject"); > ref.receiveObject(b); > }catch(Exception e){ > System.out.println("Error : " + e ); > } > } >} > > >------------------------------------------------------------------------ > >import java.rmi.Remote; >import java.rmi.RemoteException; > >public interface ReceiveObject extends Remote{ > public Object receiveObject(Object unknown) > throws RemoteException; >} > > >------------------------------------------------------------------------ > >import java.rmi.*; >import java.rmi.server.*; > > >public class ReceiveObjectImpl extends UnicastRemoteObject implements ReceiveObject{ > > public ReceiveObjectImpl() throws RemoteException{ > } > > public Object receiveObject(Object unknown) > throws RemoteException{ > System.out.println(unknown); > return null; > } > > public static void main(String[] args){ > try{ > ReceiveObject ref = new ReceiveObjectImpl(); > Naming.rebind("ReceiveObject", ref); > }catch(Exception e){ > e.printStackTrace(); > } > } >} > > From nicolas.geoffray@menlina.com Tue Oct 18 11:47:00 2005 From: nicolas.geoffray@menlina.com (Nicolas Geoffray) Date: Tue, 18 Oct 2005 11:47:00 -0000 Subject: tests with rmic! In-Reply-To: <4354B543.1090404@bluewin.ch> References: <4353DBB0.10807@menlina.com> <4354B543.1090404@bluewin.ch> Message-ID: <4354E0C3.1000108@menlina.com> Hi Meskauskas, Meskauskas Audrius wrote: > Hi, Nicolas, > > Nice idea, great to have at least any java.rmi rests! The current > testing situation with this package is deeply tragical, the coverage > being plain zero. And it is possible to find random talks on the web > like "how reliable they (GNU Classpath) RMI implementation is? Does it > work?". > > Any tests are very welcome. > > I think it would be a good idea to write Mauve tests as the > independent modules that run on a single virtual machine and does call > external tools. The most of the current tests are written this way. > Here are several suggestions how to make an ordinary Mauve test that > would not need to cross the boundaries of the current virtual machine > to run: > > 1. Instead of starting three independent virtual machines (one for > server, one for client and one for the naming service), you can just > start three threads. When all cleanup problems, if any, will be > restricted to the current run of the test suite. I can't use threads in a same virtual machine, because there is no serialization of objects in RMI when the server and the client lives in the same virtual machine (maybe it's possible enabling a flag somewhere, but i don't know the API) > 2. Instead of invoking rmic from inside the Mauve test, run it once > with the -keep key and just add the generated source code file to your > path. Such test would be easier to debug. Allright. Good idea Bye, Nicolas From audriusa@bluewin.ch Tue Oct 18 18:10:00 2005 From: audriusa@bluewin.ch (Meskauskas Audrius) Date: Tue, 18 Oct 2005 18:10:00 -0000 Subject: tests with rmic In-Reply-To: <4354E0C3.1000108@menlina.com> References: <4353DBB0.10807@menlina.com> <4354B543.1090404@bluewin.ch> <4354E0C3.1000108@menlina.com> Message-ID: <43553A78.7040400@bluewin.ch> >I can't use threads in a same virtual machine, because there is no serialization of objects in RMI when the server and the client lives in the same virtual machine (maybe it's possible enabling a flag somewhere, but i don't know the API) I looked at our gnu.java.rmi.server.UnicastRef and - yes, unfortunately it seems that there is system property in Classpath that would force the object serialization even if the RMI client and server are in the same machine. If you plan serious testing work, we should probably add such property as a necessary testing tool, but altering RMI implementation requires to have a test suite first. I think, you can commit such tests anyway because the object serialization is not the only thing in RMI that deserves testing. Audrius. From nicolas.geoffray@menlina.com Wed Oct 19 08:10:00 2005 From: nicolas.geoffray@menlina.com (Nicolas Geoffray) Date: Wed, 19 Oct 2005 08:10:00 -0000 Subject: tests with rmic Message-ID: <4355FF5C.10204@menlina.com> Hi Audrius Meskauskas Audrius wrote: > > I looked at our gnu.java.rmi.server.UnicastRef and - yes, > unfortunately it seems that there is system property in Classpath that > would force the object serialization even if the RMI client and server > are in the same machine. > > If you plan serious testing work, we should probably add such property > as a necessary testing tool, but altering RMI implementation requires > to have a test suite first. I think, you can commit such tests anyway > because the object serialization is not the only thing in RMI that > deserves testing. > Unfortunately I do not plan for the moment serious rmi testing work. I just wanted to report a bug within gnu classpath. Because the test involves launching at least 2 vms, it's difficult to reveal the bug. The property forcing serialization would be great in my case! Cheers, Nicolas From abalkiss@redhat.com Thu Oct 20 20:25:00 2005 From: abalkiss@redhat.com (Anthony Balkissoon) Date: Thu, 20 Oct 2005 20:25:00 -0000 Subject: FYI: New test for DefaultListSelectionModel Message-ID: <1129839947.2838.120.camel@tony.toronto.redhat.com> This test checks to see if DefaultListSelectionModel.setLeadSelectionIndex checks the selection mode to see if extending the selection is allowed. We currently fail this test. 2005-10-20 Anthony Balkissoon * gnu/testlet/javax/swing/DefaultListSelectionModel: New directory. * gnu/testlet/javax/swing/DefaultListSelectionModel/leadSelectionIndex.java: New test. --Tony -------------- next part -------------- A non-text attachment was scrubbed... Name: leadSelectionIndex.java Type: text/x-java Size: 1809 bytes Desc: not available URL: From audriusa@bluewin.ch Thu Oct 27 12:25:00 2005 From: audriusa@bluewin.ch (Meskauskas Audrius) Date: Thu, 27 Oct 2005 12:25:00 -0000 Subject: FYI: Fixing the incomplete cleanup in java.io.File test. Message-ID: <4360C71F.6030205@bluewin.ch> 2005-10-27 Audrius Meskauskas From abalkiss@redhat.com Fri Oct 28 16:05:00 2005 From: abalkiss@redhat.com (Anthony Balkissoon) Date: Fri, 28 Oct 2005 16:05:00 -0000 Subject: New test for Component.requestFocus Message-ID: <1130515512.2838.207.camel@tony.toronto.redhat.com> Component.requestFocus is throwing a NPE when it shouldn't be. This test is checked in and I'm committing a fix to classpath. 2005-10-28 Anthony Balkissoon * gnu/testlet/java/awt/Component/requestFocus.java: New test. --Tony -------------- next part -------------- A non-text attachment was scrubbed... Name: requestFocus.java Type: text/x-java Size: 1341 bytes Desc: not available URL: From mark@klomp.org Fri Oct 28 16:42:00 2005 From: mark@klomp.org (Mark Wielaard) Date: Fri, 28 Oct 2005 16:42:00 -0000 Subject: New test for Component.requestFocus In-Reply-To: <1130515512.2838.207.camel@tony.toronto.redhat.com> References: <1130515512.2838.207.camel@tony.toronto.redhat.com> Message-ID: <1130517715.16983.58.camel@localhost.localdomain> Hi Tony, On Fri, 2005-10-28 at 12:05 -0400, Anthony Balkissoon wrote: > 2005-10-28 Anthony Balkissoon > > * gnu/testlet/java/awt/Component/requestFocus.java: New test. > > // Tags: GUI JDK1.1 Since you are using a JFrame in this test that should be 1.2. 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 abalkiss@redhat.com Fri Oct 28 18:09:00 2005 From: abalkiss@redhat.com (Anthony Balkissoon) Date: Fri, 28 Oct 2005 18:09:00 -0000 Subject: FYI: change to Component.requestFocus test Message-ID: <1130522969.2838.219.camel@tony.toronto.redhat.com> The Tag should have been 1.2 instead of 1.1, but I changed the JFrame to a Frame (because JFrame is more than what was needed) and made the Tag JDK 1.0 2005-10-28 Anthony Balkissoon * gnu/testlet/java/awt/Component/requestFocus.java: Changed from JFrame to Frame, changed Tags from JDK 1.2 to JDK 1.0. --Tony -------------- next part -------------- A non-text attachment was scrubbed... Name: requestFocusFix.diff Type: text/x-patch Size: 1452 bytes Desc: not available URL: From mark@klomp.org Mon Oct 31 20:53:00 2005 From: mark@klomp.org (Mark Wielaard) Date: Mon, 31 Oct 2005 20:53:00 -0000 Subject: registerValidation updated Message-ID: <1130792036.6648.27.camel@localhost.localdomain> Hi, Here is an update to the registerValidation test that I wrote while fixing a bug in GNU Classpath a while ago. 2005-10-12 Mark Wielaard * gnu/testlet/java/io/ObjectInputStream/registerValidation.java: Check fields and priority order. * gnu/testlet/java/io/ObjectInputStream/TestObjectInputValidation.java: Add self reference, register multiple times with different priorities, add equals(). Committed, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: registerValidation-update.patch Type: text/x-patch Size: 4274 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 langel@redhat.com Wed Nov 2 15:22:00 2005 From: langel@redhat.com (Lillian Angel) Date: Wed, 02 Nov 2005 15:22:00 -0000 Subject: FYI: New Test for Dialog Message-ID: <1130944967.2872.68.camel@tow.toronto.redhat.com> Added a new test to make sure the Dialog is shown at the preferred size if pack is not called before show. 2005-11-01 Lillian Angel * gnu/testlet/java/awt/Dialog/size.java: New Test. -------------- next part -------------- A non-text attachment was scrubbed... Name: size.java Type: text/x-java Size: 1425 bytes Desc: not available URL: From langel@redhat.com Wed Nov 2 16:39:00 2005 From: langel@redhat.com (Lillian Angel) Date: Wed, 02 Nov 2005 16:39:00 -0000 Subject: FYI: New Test for Dialog In-Reply-To: <1130944967.2872.68.camel@tow.toronto.redhat.com> References: <1130944967.2872.68.camel@tow.toronto.redhat.com> Message-ID: <1130949547.2872.70.camel@tow.toronto.redhat.com> Roman pointed out some problems with my last test case. Fixed. 2005-11-01 Lillian Angel * gnu/testlet/java/awt/Dialog/size.java: Fixed logic in test case. On Wed, 2005-11-02 at 10:22 -0500, Lillian Angel wrote: > Added a new test to make sure the Dialog is shown at the preferred size > if pack is not called before show. > > 2005-11-01 Lillian Angel > > * gnu/testlet/java/awt/Dialog/size.java: New Test. > > -------------- next part -------------- A non-text attachment was scrubbed... Name: size.java Type: text/x-java Size: 1588 bytes Desc: not available URL: From theuserbl@hotmail.com Thu Nov 3 11:31:00 2005 From: theuserbl@hotmail.com (theUser BL) Date: Thu, 03 Nov 2005 11:31:00 -0000 Subject: Existing testsclasses for "Scanner" ? Message-ID: Hi! I have seen, that in Java 1.5 is something possible like ------ import java.util.*; public class ScannerTest { public static void main(String[] args) { String name = new String(); int number1, number2, number3; Scanner console = new Scanner(System.in); System.out.print("Please input your name: "); name = console.nextLine(); System.out.print("Hello "+name+", now input a number: "); number1 = console.nextInt(); System.out.print("And a second number: "); number2 = console.nextInt(); number3 = number1+number2; System.out.println(number1+" + "+number2+" = "+number3); } } ------ Existing for Scanner already some test-classes? I wanted only to know it. Sadly I can not myself program for Mauve, because I am not a programmer. The nice thing of Scanner is, that it is since 1.5 possible to input from the console without "try", "catch" and other professional programmings. Greatings theuserbl From tromey@redhat.com Sat Nov 5 18:38:00 2005 From: tromey@redhat.com (Tom Tromey) Date: Sat, 05 Nov 2005 18:38:00 -0000 Subject: Existing testsclasses for "Scanner" ? In-Reply-To: References: Message-ID: >> Existing for Scanner already some test-classes? No, not yet. Scanner also has not yet been written for Classpath. Tom From abalkiss@redhat.com Wed Nov 9 15:19:00 2005 From: abalkiss@redhat.com (Anthony Balkissoon) Date: Wed, 09 Nov 2005 15:19:00 -0000 Subject: FYI: New SwingUtilities test Message-ID: <1131549567.2838.413.camel@tony.toronto.redhat.com> New test. 2005-11-09 Anthony Balkissoon * gnu/testlet/javax/swing/SwingUtilities/replaceUIActionMap.java: New test. --Tony -------------- next part -------------- A non-text attachment was scrubbed... Name: replaceUIActionMap.java Type: text/x-java Size: 1929 bytes Desc: not available URL: From George.Cowan@pfizer.com Fri Nov 11 15:29:00 2005 From: George.Cowan@pfizer.com (Cowan, George) Date: Fri, 11 Nov 2005 15:29:00 -0000 Subject: Jacks Tarball/Zip? Message-ID: <1D19A04475869B4E80FF9DAF1499600EF51CD9@anaamrexm01.amer.pfizer.com> I keep timing out when I try to download the Jacks test suite with CVS - perhaps it's a firewall problem. I notice that Jacks is not included in the Mauve nightly tarball and zip. Is there a Jacks tarball/zip somewhere on the web? George PUBLIC DOMAIN INFORMATION From greg.orlowski@gmail.com Sun Nov 13 03:32:00 2005 From: greg.orlowski@gmail.com (Greg Orlowski) Date: Sun, 13 Nov 2005 03:32:00 -0000 Subject: legal question about writing mauve test cases Message-ID: <4c60c7920511121932k195c6515mad4a7f281dc189f2@mail.gmail.com> Hi, Is it legal to use the reflection api's w/ sun's jdks to generate lists of method signatures and then compare them to gnu-classpath's method signatures as a reference-point from which to develop test cases for mauve? Does using the reflection capabilities of java with sun's libraries constitute reading source code (legally)? I've been doing some of this anyway just to be able to compare gnu-classpath & sun's implementation. If it's legal, I'd like to take some diffs of output from running reflection methods as a reference for some test cases. I'd like to contribute to classpath, but I'll be using sun's tools extensively at my job, and I'm worried that I'll be tainted by doing so. thanks for any information you can give me on this! -Greg From robilad@kaffe.org Sun Nov 13 13:19:00 2005 From: robilad@kaffe.org (Dalibor Topic) Date: Sun, 13 Nov 2005 13:19:00 -0000 Subject: legal question about writing mauve test cases In-Reply-To: <4c60c7920511121932k195c6515mad4a7f281dc189f2@mail.gmail.com> References: <4c60c7920511121932k195c6515mad4a7f281dc189f2@mail.gmail.com> Message-ID: <43773D68.6010204@kaffe.org> Greg Orlowski wrote: > Hi, > > Is it legal to use the reflection api's w/ sun's jdks to generate > lists of method signatures and then compare them to gnu-classpath's > method signatures as a reference-point from which to develop test > cases for mauve? I assume that you're interested in seing which classes/methods/fields are missing/bad in GNU Classpath, in order to figure out which areas to go after, you may be interested in looking at Japitools comparison results at http://www.kaffe.org/~stuart/japi/ > Does using the reflection capabilities of java with sun's libraries > constitute reading source code (legally)? No, afaict. Otoh, if you are using or writing, say, an automated test generator for libraries, the cleanest way to do it is to generate your tests against GNU Classpath sourcecode, and then to run the tests against a non-free VM, to see if the assumptions codified in GNU Classpath also exist in the non-free VM. On a side note, CnC from http://www.cc.gatech.edu/cnc/welcome.html might be interesting for such a task. > I'd like to contribute to classpath, but I'll be using sun's tools > extensively at my job, and I'm worried that I'll be tainted by doing > so. Afaik, using Sun's tools does not taint you, since you don't get to see actual implementation details by just using java/javac. Looking at the sources or having a NDA/contract with Sun not to disclose their implementation details otoh, would prevent you from contributing respective souce code to GNU Classpath. In that case, there are still other areas one can contribute to. cheers, dalibor topic From tromey@redhat.com Mon Nov 14 15:08:00 2005 From: tromey@redhat.com (Tom Tromey) Date: Mon, 14 Nov 2005 15:08:00 -0000 Subject: Jacks Tarball/Zip? In-Reply-To: <1D19A04475869B4E80FF9DAF1499600EF51CD9@anaamrexm01.amer.pfizer.com> References: <1D19A04475869B4E80FF9DAF1499600EF51CD9@anaamrexm01.amer.pfizer.com> Message-ID: >>>>> "George" == Cowan, George writes: George> I keep timing out when I try to download the Jacks test suite George> with CVS - perhaps it's a firewall problem. I notice that George> Jacks is not included in the Mauve nightly tarball and zip. Is George> there a Jacks tarball/zip somewhere on the web? Hmm, I don't think there is. Try cvsgrab, it should work around your firewall. Tom From abalkiss@redhat.com Mon Nov 14 19:58:00 2005 From: abalkiss@redhat.com (Anthony Balkissoon) Date: Mon, 14 Nov 2005 19:58:00 -0000 Subject: FYI: New test and updated InputMap.newMapNullKeys.java Message-ID: <1131998298.30492.63.camel@tony.toronto.redhat.com> I added to the test javax.swing.InputMap.newMapNullKeys to check that allKeys() returns null for new InputMaps. A new test is pretty much the exact same as this test except for ActionMaps, and I committed this. 2005-11-14 Anthony Balkissoon * gnu/testlet/javax/swing/InputMap/newMapKeysNull.java: Added a check for allKeys() in addition to existing check for keys(). * gnu/testlet/javax/swing/ActionMap/newMapKeysNull.java: New test. --Tony -------------- next part -------------- A non-text attachment was scrubbed... Name: newMapKeysNull.java Type: text/x-java Size: 1342 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: newMapKeysNull.java Type: text/x-java Size: 1335 bytes Desc: not available URL: From abalkiss@redhat.com Wed Nov 16 20:48:00 2005 From: abalkiss@redhat.com (Anthony Balkissoon) Date: Wed, 16 Nov 2005 20:48:00 -0000 Subject: FYI: New tests for JSplitPane Message-ID: <1132174108.30492.147.camel@tony.toronto.redhat.com> I submitted these new tests: 2005-11-16 Anthony Balkissoon * gnu/testlet/javax/swing/JSplitPane: New directory. * gnu/testlet/javax/swing/JSplitPane/Constructor.java: New test. * gnu/testlet/javax/swing/JSplitPane/setComponent.java: New test. There are currently 4 FAILS in here, but I should have that cleaned up soon. --Tony -------------- next part -------------- A non-text attachment was scrubbed... Name: Constructor.java Type: text/x-java Size: 1728 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: setComponent.java Type: text/x-java Size: 1800 bytes Desc: not available URL: From david.gilbert@object-refinery.com Wed Nov 16 21:09:00 2005 From: david.gilbert@object-refinery.com (David Gilbert) Date: Wed, 16 Nov 2005 21:09:00 -0000 Subject: FYI: New tests for JSplitPane In-Reply-To: <1132174108.30492.147.camel@tony.toronto.redhat.com> References: <1132174108.30492.147.camel@tony.toronto.redhat.com> Message-ID: <437B9FED.5040505@object-refinery.com> Anthony Balkissoon wrote: >I submitted these new tests: > >2005-11-16 Anthony Balkissoon > > > [snip] >//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. > > > Minor nit... There is a new address for the FSF now, GNU Classpath has been updated but Mauve is still to be done. It's probably a good idea to get in the habit of using the new address for new tests, while we wait for a volunteer for the glorious task of updating the address for all the existing tests---my script writing skills are not up to it, though I'm sure it's easy. Great to see all the new Mauve tests being written! Regards, Dave From edwin.steiner@gmx.net Fri Nov 18 19:08:00 2005 From: edwin.steiner@gmx.net (Edwin Steiner) Date: Fri, 18 Nov 2005 19:08:00 -0000 Subject: inconsistent test names Message-ID: <20051118190804.GA10989@localhost.localdomain> Hello! I'm one of the developers of the cacao jvm[1]. We use mauve intensively to test cacao and it is a very good test suite. Currently I'm developing an automated testing framework for cacao[2]. You can see preliminary results here (large page!): http://www.complang.tuwien.ac.at/cacaojvm//tgolem/2005-11-18T03-22/mauve.html One problem I've run accross is that some mauve tests use inconsistent names to report PASSes and FAILs. The most troublesome cases are those, where a *named* check/fail is followed by an *unnamed* one. For example: gnu/testlet/java/net/MulticastSocket/MulticastSocketTest.java:207 there is a harness.fail("could not create FIRST multicast socket on shared port " + sharedMcastPort); at this line. The next check on line 216 and unnamed. Now if the first check fails, and the second succeeds, you get a bogus PASS line like: PASS: gnu.testlet.java.net.MulticastSocket.MulticastSocketTest: could not create SECOND multicast socket on shared port 1234 (number 2) from the harness. If you also think these cases should be fixed (by naming the checks), I would be happy to provide patches. Makes more sense than teaching my tgolem to work around these cases. -Edwin [1] http://www.cacaojvm.org/ [2] http://www.cacaojvm.org/tgolem Most of the tgolem code is not cacao specific and I plan to release it as a GPL project within the next months. From gbenson@redhat.com Mon Nov 21 16:58:00 2005 From: gbenson@redhat.com (Gary Benson) Date: Mon, 21 Nov 2005 16:58:00 -0000 Subject: SecurityException throwpoint audit Message-ID: <20051121165809.GB12340@redhat.com> Hi all, I've been trying to work out how to test that permissions are checked at every point they ought to be. There's a table of every such point here: http://java.sun.com/j2se/1.4.2/docs/guide/security/permissions.html#PermsAndMethods Some of these already have tests, but most probably do not. Before I start creating tests I'm thinking that we need some way to correlate mauve tests with the throwpoints on this (and future) lists. How would people feel if I numbered the throwpoints on the above list and noted them in their corresponding tests in some easily parsable form (probably in comments like Tags are already). That way whether a throwpoint is tested (and the location of the test) can be found with a simple grep. For simplicity I'd probably number the 1.4.2 list from 1-whatever. Checks added in 1.5 can be added at the end of the list. It would be convenient if we made a version of the above list annotated with the throwpoint numbers, but obviously such a thing could not be distributed. It should be possible to write a script that would download and annotate the list for local use. Does this sound reasonable? Cheers, Gary From gbenson@redhat.com Tue Nov 22 16:27:00 2005 From: gbenson@redhat.com (Gary Benson) Date: Tue, 22 Nov 2005 16:27:00 -0000 Subject: SecurityException throwpoint audit In-Reply-To: <20051121165809.GB12340@redhat.com> References: <20051121165809.GB12340@redhat.com> Message-ID: <20051122162710.GC4839@redhat.com> Hi again, I take it that nobody minds if I start doing this. The attached script can be used to create the annotated list of throwpoints so you can look up IDs I add in comments or whatever. The script performs some MD5 checks so you can be sure you're looking at the same page I am. Cheers, Gary Gary Benson wrote: > Hi all, > > I've been trying to work out how to test that permissions are > checked at every point they ought to be. There's a table of > every such point here: > > http://java.sun.com/j2se/1.4.2/docs/guide/security/permissions.html#PermsAndMethods > > Some of these already have tests, but most probably do not. Before > I start creating tests I'm thinking that we need some way to > correlate mauve tests with the throwpoints on this (and future) > lists. > > How would people feel if I numbered the throwpoints on the above > list and noted them in their corresponding tests in some easily > parsable form (probably in comments like Tags are already). That > way whether a throwpoint is tested (and the location of the test) > can be found with a simple grep. > > For simplicity I'd probably number the 1.4.2 list from 1-whatever. > Checks added in 1.5 can be added at the end of the list. > > It would be convenient if we made a version of the above list > annotated with the throwpoint numbers, but obviously such a thing > could not be distributed. It should be possible to write a script > that would download and annotate the list for local use. > > Does this sound reasonable? > > Cheers, > Gary -------------- next part -------------- #!/usr/bin/env python import md5 import sgmllib def escape(data, escape_quote = False): data = data.replace("&", "&") data = data.replace("<", "<") if escape_quote: data = data.replace('"', """) return data class Parser(sgmllib.SGMLParser): from htmlentitydefs import entitydefs def __init__(self, fp, verbose = False): sgmllib.SGMLParser.__init__(self, verbose) self.fp = fp def reset(self): sgmllib.SGMLParser.reset(self) self.hashes = md5.new(), md5.new() self.passthrough = False self.row = None def feed(self, data): sgmllib.SGMLParser.feed(self, data) self.hashes[0].update(data) def write(self, data): self.fp.write(data) self.hashes[1].update(data) def digests(self): return [hash.hexdigest() for hash in self.hashes] # handle passthrough in generic overrides def handle_starttag(self, tag, method, attrs): sgmllib.SGMLParser.handle_starttag(self, tag, method, attrs) if self.passthrough: self.__write_tag(tag, attrs) def unknown_starttag(self, tag, attrs): sgmllib.SGMLParser.unknown_starttag(self, tag, attrs) if self.passthrough: self.__write_tag(tag, attrs) def handle_endtag(self, tag, method): if self.passthrough: self.__write_tag("/" + tag) sgmllib.SGMLParser.handle_endtag(self, tag, method) def unknown_endtag(self, tag): if self.passthrough: self.__write_tag("/" + tag) sgmllib.SGMLParser.unknown_endtag(self, tag) def handle_data(self, data): if self.passthrough: self.write(data) def __write_tag(self, tag, attrs = ()): self.write("<%s%s>" % (tag, "".join( [' %s="%s"' % (name, escape(value, True)) for name, value in attrs]))) # handle everything else in tag-specific overrides def start_table(self, attrs): for name, value in attrs: if name == "summary": if value == "methods and the premissions they require": self.passthrough = True self.row = 0 break if self.passthrough: self.write("\n \n ") def end_table(self): if self.passthrough: self.write("\n \n\n") self.passthrough = False def start_tr(self, attrs): if self.passthrough: if self.row == 29: self.passthrough = False self.row_tagged = False elif self.row == 29: self.passthrough = True def end_tr(self): if self.passthrough: self.row += 1 def start_th(self, attrs): if self.passthrough: if not self.row_tagged: self.write("ID\n ") self.row_tagged = True def start_td(self, attrs): if self.passthrough: if not self.row_tagged: self.write("se%03d\n " % self.row) self.row_tagged = True if __name__ == "__main__": import os import sys import urllib version = "1.4.2" src = "http://java.sun.com/j2se/" + version \ + "/docs/guide/security/permissions.html" dst = "throwpoints-%s.html" % version if os.path.exists(dst): print "%s: file exists" % dst sys.exit(1) parser = Parser(open(dst, "w")) parser.feed(urllib.urlopen(src).read()) parser.close() digests = parser.digests() if digests[1] == "3c40052647c417dead97068a32f51911": status = "PASS" elif digests[0] == "c4b9248859682e65ad71788acfc03b78": status = "FAIL (processing)" else: status = "FAIL (input = %s)" % digests[0] print "status:", status From mark@klomp.org Thu Nov 24 21:50:00 2005 From: mark@klomp.org (Mark Wielaard) Date: Thu, 24 Nov 2005 21:50:00 -0000 Subject: inconsistent test names In-Reply-To: <20051118190804.GA10989@localhost.localdomain> References: <20051118190804.GA10989@localhost.localdomain> Message-ID: <1132869012.5568.6.camel@localhost.localdomain> Hi Edwin, On Fri, 2005-11-18 at 20:08 +0100, Edwin Steiner wrote: > Currently I'm developing an automated testing framework for > cacao[2]. You can see preliminary results here (large page!): > > http://www.complang.tuwien.ac.at/cacaojvm//tgolem/2005-11-18T03-22/mauve.html Very nice overview! > One problem I've run accross is that some mauve tests use > inconsistent names to report PASSes and FAILs. The most troublesome > cases are those, where a *named* check/fail is followed by an > *unnamed* one. > [...] > If you also think these cases should be fixed (by naming the checks), > I would be happy to provide patches. Makes more sense than teaching > my tgolem to work around these cases. That does make sense to me. Probably the best approach would be to have an explicit harness.checkPoint("") after each named check followed by unnamed ones. But I would be happy with any patch that solves this issue. 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 Nov 25 00:02:00 2005 From: mark@klomp.org (Mark Wielaard) Date: Fri, 25 Nov 2005 00:02:00 -0000 Subject: SecurityException throwpoint audit In-Reply-To: <20051121165809.GB12340@redhat.com> References: <20051121165809.GB12340@redhat.com> Message-ID: <1132876894.5568.31.camel@localhost.localdomain> Hi Gary, On Mon, 2005-11-21 at 16:58 +0000, Gary Benson wrote: > I've been trying to work out how to test that permissions are checked > at every point they ought to be. There's a table of every such point > here: > > http://java.sun.com/j2se/1.4.2/docs/guide/security/permissions.html#PermsAndMethods I would not trust that list as the definite guide. I just looked for a random method (which I was just working on for GNU Classpath) Toolkit.getSystemSelection() and it was not listed. > Some of these already have tests, but most probably do not. Before I > start creating tests I'm thinking that we need some way to correlate > mauve tests with the throwpoints on this (and future) lists. > > How would people feel if I numbered the throwpoints on the above list > and noted them in their corresponding tests in some easily parsable > form (probably in comments like Tags are already). That way whether a > throwpoint is tested (and the location of the test) can be found with > a simple grep. > > For simplicity I'd probably number the 1.4.2 list from 1-whatever. > Checks added in 1.5 can be added at the end of the list. I don't really like the numbering. I would propose to actually name the tests with somewhat meaningful names. Something like __ for each Permission and class.method() needing to check for that permission. (example: AWTPermission_Toolkit_getSystemSelection) Or maybe have a directory per PermissionClassName. That is how jacks is setup. It follows the JLS, but it doesn't use the section numbers, but logical names of the sections that the tests are for. 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 Fri Nov 25 19:28:00 2005 From: tromey@redhat.com (Tom Tromey) Date: Fri, 25 Nov 2005 19:28:00 -0000 Subject: inconsistent test names In-Reply-To: <20051118190804.GA10989@localhost.localdomain> References: <20051118190804.GA10989@localhost.localdomain> Message-ID: <17287.25388.605383.259537@localhost.localdomain> >>>>> "Edwin" == Edwin Steiner writes: Edwin> One problem I've run accross is that some mauve tests use Edwin> inconsistent names to report PASSes and FAILs. The most troublesome Edwin> cases are those, where a *named* check/fail is followed by an Edwin> *unnamed* one. For example: Yeah, this is a problem. It is kind of a pain to write this correctly. I wonder if we should just give up on the current scheme and do what was suggested years ago, namely just name the test case after the .class, and do a single big pass/fail for the entire file as a whole. Then we would be guaranteed that the test names would be stable (as stable as the file names). We could still track down failures by passing a special flag that would make Mauve dump a stack trace on a failing check(). If compiled with debugging this would give the line number -- which would be even more convenient than what we do now. Thoughts? Tom From tromey@redhat.com Fri Nov 25 19:30:00 2005 From: tromey@redhat.com (Tom Tromey) Date: Fri, 25 Nov 2005 19:30:00 -0000 Subject: SecurityException throwpoint audit In-Reply-To: <1132876894.5568.31.camel@localhost.localdomain> References: <20051121165809.GB12340@redhat.com> <1132876894.5568.31.camel@localhost.localdomain> Message-ID: <17287.25514.89164.330051@localhost.localdomain> >>>>> "Mark" == Mark Wielaard writes: Mark> I don't really like the numbering. I would propose to actually name the Mark> tests with somewhat meaningful names. Yeah, if there is a way to do this "stably" then I think it would be preferable. Tom From gbenson@redhat.com Mon Nov 28 14:04:00 2005 From: gbenson@redhat.com (Gary Benson) Date: Mon, 28 Nov 2005 14:04:00 -0000 Subject: SecurityException throwpoint audit In-Reply-To: <1132876894.5568.31.camel@localhost.localdomain> References: <20051121165809.GB12340@redhat.com> <1132876894.5568.31.camel@localhost.localdomain> Message-ID: <20051128140426.GE12549@redhat.com> Mark Wielaard wrote: > On Mon, 2005-11-21 at 16:58 +0000, Gary Benson wrote: > > I've been trying to work out how to test that permissions are > > checked at every point they ought to be. There's a table of every > > such point here: > > > > http://java.sun.com/j2se/1.4.2/docs/guide/security/permissions.html#PermsAndMethods > > I would not trust that list as the definite guide. I just looked for > a random method (which I was just working on for GNU Classpath) > Toolkit.getSystemSelection() and it was not listed. Ah, thanks for the warning. > > How would people feel if I numbered the throwpoints on the above > > list and noted them in their corresponding tests in some easily > > parsable form (probably in comments like Tags are already). That > > way whether a throwpoint is tested (and the location of the test) > > can be found with a simple grep. > > > > For simplicity I'd probably number the 1.4.2 list from 1-whatever. > > Checks added in 1.5 can be added at the end of the list. > > I don't really like the numbering. I would propose to actually name > the tests with somewhat meaningful names. Something like > __ for each Permission > and class.method() needing to check for that permission. (example: > AWTPermission_Toolkit_getSystemSelection) Yeah, that's better I suppose, I'll use that. Cheers, Gary From gbenson@redhat.com Tue Nov 29 13:52:00 2005 From: gbenson@redhat.com (Gary Benson) Date: Tue, 29 Nov 2005 13:52:00 -0000 Subject: Disabled tests Message-ID: <20051129135154.GB5325@redhat.com> What do we do with failing tests? The reason I ask is that I just noticed that the listRoots test in gnu/testlet/java/io/File/security.java has been disabled in a totally non-obvious way. Should I reenable it? Cheers, Gary From mark@klomp.org Tue Nov 29 13:59:00 2005 From: mark@klomp.org (Mark Wielaard) Date: Tue, 29 Nov 2005 13:59:00 -0000 Subject: FYI: Mark gnu/testlet/java/lang/Class/pkg/test? as not-a-test Message-ID: <1133272809.6994.208.camel@localhost.localdomain> Hi, The following helper classes are not actual tests. 2005-11-29 Mark Wielaard * gnu/testlet/java/lang/Class/pkg/test1.java: Mark not-a-test. * gnu/testlet/java/lang/Class/pkg/test2.java: Likewise. * gnu/testlet/java/lang/Class/pkg/test3.java: Likewise. * gnu/testlet/java/lang/Class/pkg/test4.java: Likewise. Committed, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: pkg.patch Type: text/x-patch Size: 2064 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 Tue Nov 29 14:16:00 2005 From: mark@klomp.org (Mark Wielaard) Date: Tue, 29 Nov 2005 14:16:00 -0000 Subject: Disabled tests In-Reply-To: <20051129135154.GB5325@redhat.com> References: <20051129135154.GB5325@redhat.com> Message-ID: <1133273779.6994.216.camel@localhost.localdomain> Hi Gary, On Tue, 2005-11-29 at 13:51 +0000, Gary Benson wrote: > What do we do with failing tests? I think we should have xfail files for them. But currently we don't really have up to date ones. And in the past various runtimes had completely different failure behavior making it unclear what the "correct" xfail file would be. I hope the work of Edwin from teh Cacao team will help here since the produce lists of common failures between runtimes. > The reason I ask is that I just noticed that the listRoots test in > gnu/testlet/java/io/File/security.java has been disabled in a totally > non-obvious way. Should I reenable it? I think so. I have worked on this, but it is so obscure that I cannot really see the how and what should be happening here. Sorry about that. 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 gbenson@redhat.com Tue Nov 29 15:58:00 2005 From: gbenson@redhat.com (Gary Benson) Date: Tue, 29 Nov 2005 15:58:00 -0000 Subject: Disabled tests In-Reply-To: <1133273779.6994.216.camel@localhost.localdomain> References: <20051129135154.GB5325@redhat.com> <1133273779.6994.216.camel@localhost.localdomain> Message-ID: <20051129155837.GD5325@redhat.com> Mark Wielaard wrote: > On Tue, 2005-11-29 at 13:51 +0000, Gary Benson wrote: > > What do we do with failing tests? > > I think we should have xfail files for them. But currently we don't > really have up to date ones. And in the past various runtimes had > completely different failure behavior making it unclear what the > "correct" xfail file would be. > > I hope the work of Edwin from teh Cacao team will help here since > the produce lists of common failures between runtimes. > > > The reason I ask is that I just noticed that the listRoots test in > > gnu/testlet/java/io/File/security.java has been disabled in a > > totally non-obvious way. Should I reenable it? > > I think so. I have worked on this, but it is so obscure that I > cannot really see the how and what should be happening here. Sorry > about that. In this case there's nothing saying why it's disabled. The initial revision (1.1, July 2003) had the test: it was commented out in the next commit (1.2, March 2004) which was a total rewrite of the whole file. I don't think the test ever passed in Classpath, so it's possible the guy disabled it while he was rewriting and then forgot to reenable it before the commit. The javadoc here makes is pretty clear what needs checking. Does anyone mind if I reenable it? Cheers, Gary From mark@klomp.org Tue Nov 29 21:48:00 2005 From: mark@klomp.org (Mark Wielaard) Date: Tue, 29 Nov 2005 21:48:00 -0000 Subject: Disabled tests In-Reply-To: <20051129155837.GD5325@redhat.com> References: <20051129135154.GB5325@redhat.com> <1133273779.6994.216.camel@localhost.localdomain> <20051129155837.GD5325@redhat.com> Message-ID: <1133300903.4622.0.camel@localhost> hi gary, On Tue, 2005-11-29 at 15:58 +0000, Gary Benson wrote: > Does anyone mind if I reenable it? please do. 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 green@redhat.com Tue Dec 6 04:35:00 2005 From: green@redhat.com (Anthony Green) Date: Tue, 06 Dec 2005 04:35:00 -0000 Subject: Patch: Float/DoubleBuffer compareTo Message-ID: <1133843705.3036.170.camel@localhost.localdomain> These tests point out a bug in GNU Classpath. Float and Double buffers built from identical arrays containing NaN values should still compare as equal. I'm checking this in. Float/DoubleBuffer.compareTo need special checks for this case. Something like (a != a) && (b != b). 2005-12-05 Anthony Green * gnu/testlet/java/nio/DoubleBuffer/compareTo.java: New test. * gnu/testlet/java/nio/FloatBuffer/compareTo.java: New test. Index: gnu/testlet/java/nio/DoubleBuffer/compareTo.java =================================================================== RCS file: gnu/testlet/java/nio/DoubleBuffer/compareTo.java diff -N gnu/testlet/java/nio/DoubleBuffer/compareTo.java --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ gnu/testlet/java/nio/DoubleBuffer/compareTo.java 6 Dec 2005 04:28:29 -0000 @@ -0,0 +1,43 @@ +// Tags: JDK1.4 + +// Copyright (C) 2005 Red Hat, Inc. + +// 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.java.nio.DoubleBuffer; + +import gnu.testlet.Testlet; +import gnu.testlet.TestHarness; + +import java.nio.*; + +public class compareTo implements Testlet +{ + public void test(TestHarness h) + { + double darray[] = new double[1]; + darray[0] = Double.NaN; + + DoubleBuffer fb1 = DoubleBuffer.wrap(darray); + DoubleBuffer fb2 = DoubleBuffer.wrap(darray); + + h.check(fb1.compareTo(fb2), 0, "double buffer compare with NaN entry"); + } +} + Index: gnu/testlet/java/nio/FloatBuffer/compareTo.java =================================================================== RCS file: gnu/testlet/java/nio/FloatBuffer/compareTo.java diff -N gnu/testlet/java/nio/FloatBuffer/compareTo.java --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ gnu/testlet/java/nio/FloatBuffer/compareTo.java 6 Dec 2005 04:28:29 -0000 @@ -0,0 +1,43 @@ +// Tags: JDK1.4 + +// Copyright (C) 2005 Red Hat, Inc. + +// 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.java.nio.FloatBuffer; + +import gnu.testlet.Testlet; +import gnu.testlet.TestHarness; + +import java.nio.*; + +public class compareTo implements Testlet +{ + public void test(TestHarness h) + { + float farray[] = new float[1]; + farray[0] = Float.NaN; + + FloatBuffer fb1 = FloatBuffer.wrap(farray); + FloatBuffer fb2 = FloatBuffer.wrap(farray); + + h.check(fb1.compareTo(fb2), 0, "float buffer compare with NaN entry"); + } +} + From tromey@redhat.com Wed Dec 7 19:13:00 2005 From: tromey@redhat.com (Tom Tromey) Date: Wed, 07 Dec 2005 19:13:00 -0000 Subject: mauve ./ChangeLog gnu/testlet/javax/swing/plaf ... In-Reply-To: <20051206140424.7036.qmail@sourceware.org> References: <20051206140424.7036.qmail@sourceware.org> Message-ID: I think this patch broke compilation dgilbert> createFilterComboBoxModel.java This file has: import gnu.testlet.javax.swing.JFileChooser.MyFileChooser; But I don't see that file in CVS. Tom From david.gilbert@object-refinery.com Wed Dec 7 20:17:00 2005 From: david.gilbert@object-refinery.com (David Gilbert) Date: Wed, 07 Dec 2005 20:17:00 -0000 Subject: mauve ./ChangeLog gnu/testlet/javax/swing/plaf ... In-Reply-To: References: <20051206140424.7036.qmail@sourceware.org> Message-ID: <439744CD.3070508@object-refinery.com> Tom Tromey wrote: >I think this patch broke compilation > >dgilbert> createFilterComboBoxModel.java > >This file has: > >import gnu.testlet.javax.swing.JFileChooser.MyFileChooser; > >But I don't see that file in CVS. > >Tom > > Sorry. Fixed with this patch committed: 2005-12-07 David Gilbert * gnu/testlet/javax/swing/JFileChooser/MyFileChooser.java: New support class. Regards, Dave -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: diff.txt URL: From raif@swiftdsl.com.au Wed Dec 21 13:38:00 2005 From: raif@swiftdsl.com.au (Raif S. Naffah) Date: Wed, 21 Dec 2005 13:38:00 -0000 Subject: patch to improve use with Eclipse Message-ID: <200512220039.14344.raif@swiftdsl.com.au> hello there, pls. find attached a patch to improve the use of Mauve with (Native) Eclipse. cheers; rsn -------------- next part -------------- A non-text attachment was scrubbed... Name: mauve-20051221.patch Type: text/x-diff Size: 3416 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 216 bytes Desc: not available URL: From mark@klomp.org Wed Dec 21 15:07:00 2005 From: mark@klomp.org (Mark Wielaard) Date: Wed, 21 Dec 2005 15:07:00 -0000 Subject: patch to improve use with Eclipse In-Reply-To: <200512220039.14344.raif@swiftdsl.com.au> References: <200512220039.14344.raif@swiftdsl.com.au> Message-ID: <1135177669.7227.75.camel@localhost.localdomain> Hi Raif, On Thu, 2005-12-22 at 00:39 +1100, Raif S. Naffah wrote: > pls. find attached a patch to improve the use of Mauve with (Native) > Eclipse. Could you give some guidance for a newbie like me? I installed this and now I have under Run->External Tools a new item MauveBatchRun. If I select that (after following almost everything in http://developer.classpath.org/mediation/ClasspathHackingWithEclipse) it seems to configure mauve and then says: [Console output redirected to file:/home/mark/workspace/mauve/mauve.out] But there is nothing in that file. I did commit it so others can play more easily with it though. 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 Wed Dec 21 23:46:00 2005 From: mark@klomp.org (Mark Wielaard) Date: Wed, 21 Dec 2005 23:46:00 -0000 Subject: patch to improve use with Eclipse In-Reply-To: <1135177669.7227.75.camel@localhost.localdomain> References: <200512220039.14344.raif@swiftdsl.com.au> <1135177669.7227.75.camel@localhost.localdomain> Message-ID: <1135208811.7227.106.camel@localhost.localdomain> On Wed, 2005-12-21 at 16:07 +0100, Mark Wielaard wrote: > Hi Raif, > > On Thu, 2005-12-22 at 00:39 +1100, Raif S. Naffah wrote: > > pls. find attached a patch to improve the use of Mauve with (Native) > > Eclipse. > > Could you give some guidance for a newbie like me? > I installed this and now I have under Run->External Tools a new item > MauveBatchRun. If I select that (after following almost everything in > http://developer.classpath.org/mediation/ClasspathHackingWithEclipse) it > seems to configure mauve and then says: > [Console output redirected to file:/home/mark/workspace/mauve/mauve.out] > > But there is nothing in that file. > > I did commit it so others can play more easily with it though. Strangely enough it still doesn't really run for me. But I did experiment a bit with eclipse and mauve and came up with a simple SingleTestHarness which can be used with a Runner for quickly testing a mauve Testlet that you are working on: 2005-12-21 Mark Wielaard * gnu/testlet/SingleTestHarness.java: New file. With this you can define a simple runner that uses this class with as argument ${java_type_name}. A cool trick here is to do the following: $ mkdir -p ~/workspace/classpath/install/jre/lib $ touch ~/workspace/classpath/install/jre/lib/rt.jar Now you can go to Preferences -> Java -> JRE and add your workspace/classpath/install as alternative installed jre. Then you can use this alternative jre for the above runner to get it to test your mauve Testlets against your the classpath project. Pretty cool :) Cheers, Mark -------------- next part -------------- A non-text attachment was scrubbed... Name: SingleTestHarness.java Type: text/x-java Size: 4373 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 raif@swiftdsl.com.au Thu Dec 22 11:03:00 2005 From: raif@swiftdsl.com.au (Raif S. Naffah) Date: Thu, 22 Dec 2005 11:03:00 -0000 Subject: patch to improve use with Eclipse In-Reply-To: <1135177669.7227.75.camel@localhost.localdomain> References: <200512220039.14344.raif@swiftdsl.com.au> <1135177669.7227.75.camel@localhost.localdomain> Message-ID: <200512222204.46970.raif@swiftdsl.com.au> hello Mark, On Thursday 22 December 2005 02:07, Mark Wielaard wrote: > Hi Raif, > > On Thu, 2005-12-22 at 00:39 +1100, Raif S. Naffah wrote: > > pls. find attached a patch to improve the use of Mauve with > > (Native) Eclipse. > > Could you give some guidance for a newbie like me? > I installed this and now I have under Run->External Tools a new item > MauveBatchRun. If I select that (after following almost everything in > http://developer.classpath.org/mediation/ClasspathHackingWithEclipse) > it seems to configure mauve and then says: > [Console output redirected to > file:/home/mark/workspace/mauve/mauve.out] > > But there is nothing in that file. i just checked out Mauve, including this Runner, restarted Eclipse and tried it and it (still) works! i did see the symptoms you're describing when (a) the built VM had problems; (b) the VM was not configured properly; e.g. not picking up the correct Classpath classes; and/or (c) the environment variables --defined in this Runner-- are not being picked up. in these cases, the Mauve scripts would run, but no test class is selected for the "runner" script to run them. the best way to debug why nothing is being written to mauve.out is to add some 'echo ' statements in batch_run, choose-classes and runner. also, on line 119 of the batch_run script, invert 2 and 1 so you can see the stderr output on the Eclipse console. finally, did you create the symbolic link to mauve-classpath keys file? > > I did commit it so others can play more easily with it though. thanks + cheers; rsn -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 216 bytes Desc: not available URL: From mark@klomp.org Thu Dec 22 21:32:00 2005 From: mark@klomp.org (Mark Wielaard) Date: Thu, 22 Dec 2005 21:32:00 -0000 Subject: patch to improve use with Eclipse In-Reply-To: <200512222204.46970.raif@swiftdsl.com.au> References: <200512220039.14344.raif@swiftdsl.com.au> <1135177669.7227.75.camel@localhost.localdomain> <200512222204.46970.raif@swiftdsl.com.au> Message-ID: <1135287134.7227.211.camel@localhost.localdomain> Hi Raif, On Thu, 2005-12-22 at 22:04 +1100, Raif S. Naffah wrote: > finally, did you create the symbolic link to mauve-classpath keys file? Doh... I saw you also updated the wiki page with those instructions. http://developer.classpath.org/mediation/ClasspathHackingWithEclipse It works now for me. Thanks. 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 raif@swiftdsl.com.au Fri Dec 23 07:46:00 2005 From: raif@swiftdsl.com.au (Raif S. Naffah) Date: Fri, 23 Dec 2005 07:46:00 -0000 Subject: patch to improve use with Eclipse In-Reply-To: <1135287134.7227.211.camel@localhost.localdomain> References: <200512220039.14344.raif@swiftdsl.com.au> <200512222204.46970.raif@swiftdsl.com.au> <1135287134.7227.211.camel@localhost.localdomain> Message-ID: <200512231847.16552.raif@swiftdsl.com.au> hello Mark, On Friday 23 December 2005 08:32, Mark Wielaard wrote: > Hi Raif, > > On Thu, 2005-12-22 at 22:04 +1100, Raif S. Naffah wrote: > > finally, did you create the symbolic link to mauve-classpath keys > > file? > > Doh... > I saw you also updated the wiki page with those instructions. > http://developer.classpath.org/mediation/ClasspathHackingWithEclipse > > It works now for me. Thanks. good to hear :-) + cheers; rsn -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 216 bytes Desc: not available URL: From raif@swiftdsl.com.au Sat Dec 24 22:26:00 2005 From: raif@swiftdsl.com.au (Raif S. Naffah) Date: Sat, 24 Dec 2005 22:26:00 -0000 Subject: patch to run 1 testlet with "classpath" fakejdk Message-ID: <200512250927.55279.raif@swiftdsl.com.au> hello there, pls. find attached a patch to add to Eclipse a Runner that runs one selected Mauve testlet with the "fakejdk" named "classpath." cheers; rsn -------------- next part -------------- A non-text attachment was scrubbed... Name: mauve-20051225.patch Type: text/x-diff Size: 1747 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 216 bytes Desc: not available URL: