Some issues..

Some issues..

[Thomas Zander]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hmm;
I spent a couple of days running with the snapshot which I downloaded from
the webpage (http://sources.redhat.com/mauve/) until I found out is _very_
far from recent (which the 'snapshot' seemed to imply)
I must say its pretty bad that the snapshot is over a year old!!
I suggest to remote the snapshot; or have up-to-date versions created
nightly.

I looked at the homepage and found a 'breaking news' that I found rather
dubious; it looks like its been there for ages since the 'sidebar' does
not work (on either konqueror or on mozilla), the 'logo design' leads to a
dead link, the 'contribute'  page is empty..

Next CVS does not compile with suns javac
(gnu/testlet/java/text/SimpleDateFormat/attribute.java)


Please make the project seem 'less dead' to the passing eye!!  If Red-hat
does not do anything; what about moving the project to sourceforge or
savannah ??

Anyway; maybe someone here can answer my question posted on the classpath
list a couple of days ago (providing a patch to mauve).
http://mail.gnu.org/archive/html/classpath/2004-04/msg00000.html

if this is a mailinglist; please cc answers!
- --
Thomas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAbrZnCojCW6H2z/QRAohDAKDnje/pd+rt0T6zb28tlFoWpOnnAwCfceY4
CHmp/2CEU8wc4iQVQdvYlUo=
=n7n2
-----END PGP SIGNATURE-----

Some issues..

[Andrew Haley]

Thomas Zander writes:
 > 
 > Next CVS does not compile with suns javac
 > (gnu/testlet/java/text/SimpleDateFormat/attribute.java)

Would you please help us here by sending a patch?

 > Please make the project seem 'less dead' to the passing eye!!  If Red-hat
 > does not do anything; what about moving the project to sourceforge or
 > savannah ??

How would moving the project to a different server help?  Many people
contribute to Mauve, Red Hat provide the server.

 > Anyway; maybe someone here can answer my question posted on the classpath
 > list a couple of days ago (providing a patch to mauve).
 > http://mail.gnu.org/archive/html/classpath/2004-04/msg00000.html

It was a very strange patch.  A tarfile with one file that was a diff,
and a new directory.  However, that patch looks reasonable enough.
However, there was no ChangeLog entry; we'll need one of those.

Andrew.

Re: Some issues..

[Thomas Zander]

[-- Attachment #1: Type: Text/Plain, Size: 2814 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Saturday 03 April 2004 15:15, Andrew Haley wrote:
> Thomas Zander writes:
>  > Next CVS does not compile with suns javac
>  > (gnu/testlet/java/text/SimpleDateFormat/attribute.java)
>
> Would you please help us here by sending a patch?

It seems the author used some illegal constructs; I'm not sure what he meant
so I'll send the error messages instead.

    [javac] Compiling 678 source files to /home/zander/sources/java/mauve/build
    [javac] /home/zander/sources/java/mauve/gnu/testlet/java/text/SimpleDateFormat/attribute.java:160: illegal start of expression
    [javac]     static Format.Field[] fields = new Format.Field[] {
    [javac]         ^
    [javac] /home/zander/sources/java/mauve/gnu/testlet/java/text/SimpleDateFormat/attribute.java:165: illegal start of expression
    [javac]     static int[] begin = new int[] {
    [javac]         ^
    [javac] /home/zander/sources/java/mauve/gnu/testlet/java/text/SimpleDateFormat/attribute.java:168: illegal start of expression
    [javac]     static int[] end = new int[] {

I don't think these 'static' modifiers are needed in the first place; but why were
they added?

Second; I found at least one directory that contains java files without a
package; leading it to be uncompilable (due to duplicate class names)
I found:
gnu/testlet/BinaryCompatibility/altered/
Should those have package lines??

>  > Please make the project seem 'less dead' to the passing eye!!  If
>  > Red-hat does not do anything; what about moving the project to
>  > sourceforge or savannah ??
>
> How would moving the project to a different server help?  Many people
> contribute to Mauve, Red Hat provide the server.

Oh; I did not want to imply mauve can't run on a RedHat server; my intent
was to let you know of the problems. And since I could not imagine being 
the first to notice them I added a suggestion in case the pages on RedHat's
servers were not available to the project members.
Anyway;  Please make the project seem 'less dead' to the passing eye!!

>  > maybe someone here can answer my question posted on the
>  > classpath list a couple of days ago (providing a patch to mauve).
>  > http://mail.gnu.org/archive/html/classpath/2004-04/msg00000.html
>
> It was a very strange patch.  A tarfile with one file that was a diff,
> and a new directory.  However, that patch looks reasonable enough.
> However, there was no ChangeLog entry; we'll need one of those.

I noticed that the patch does not cleanly apply anymore; here is a new diff.

- -- 
Thomas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAbr7TCojCW6H2z/QRAu+CAKCiC9VbH6bPq+rfQNga7ekPuLuaDACgwxI9
js0VZsiSLnzzLtIS1DitU20=
=MuJw
-----END PGP SIGNATURE-----

[-- Attachment #2: antCompat.diff --]
[-- Type: text/x-diff, Size: 1185 bytes --]

Index: gnu/testlet/SimpleTestHarness.java
===================================================================
RCS file: /cvs/mauve/mauve/gnu/testlet/SimpleTestHarness.java,v
retrieving revision 1.38
diff -u -3 -p -r1.38 SimpleTestHarness.java
--- gnu/testlet/SimpleTestHarness.java	29 Aug 2003 14:52:21 -0000	1.38
+++ gnu/testlet/SimpleTestHarness.java	3 Apr 2004 13:36:59 -0000
@@ -50,6 +50,11 @@ public class SimpleTestHarness
 	    " (number " + (count + 1) + ")");
   }
   
+
+  protected int getFailures() {
+    return failures;
+  }
+
   public void check (boolean result)
   {
     if (!result)
Index: ChangeLog
===================================================================
RCS file: /cvs/mauve/mauve/ChangeLog,v
retrieving revision 1.563
diff -u -3 -p -r1.563 ChangeLog
--- ChangeLog	26 Mar 2004 13:32:23 -0000	1.563
+++ ChangeLog	3 Apr 2004 13:37:00 -0000
@@ -1,3 +1,8 @@
+2004-04-03  Thomas Zander <zander@kde.org>
+
+	* added an ant build option so the autotools are not needed if you use
+	a fully functional JVM (for example for writing tests).
+
 2004-03-26  Mark Wielaard  <mark@klomp.org>
 
 	* gnu/testlet/java/io/ObjectInputOutput/Compat2.java: Explicitly set

[-- Attachment #3: antMauve.tgz --]
[-- Type: application/x-tgz, Size: 2538 bytes --]

Re: Some issues..

[Andrew Haley]

Thomas Zander writes:
 > -----BEGIN PGP SIGNED MESSAGE-----
 > Hash: SHA1
 > 
 > On Saturday 03 April 2004 15:15, Andrew Haley wrote:
 > > Thomas Zander writes:
 > >  > Next CVS does not compile with suns javac
 > >  > (gnu/testlet/java/text/SimpleDateFormat/attribute.java)
 > >
 > > Would you please help us here by sending a patch?
 > 
 > It seems the author used some illegal constructs; I'm not sure what he meant
 > so I'll send the error messages instead.
 > 
 >     [javac] Compiling 678 source files to /home/zander/sources/java/mauve/build
 >     [javac] /home/zander/sources/java/mauve/gnu/testlet/java/text/SimpleDateFormat/attribute.java:160: illegal start of expression
 >     [javac]     static Format.Field[] fields = new Format.Field[] {
 >     [javac]         ^
 >     [javac] /home/zander/sources/java/mauve/gnu/testlet/java/text/SimpleDateFormat/attribute.java:165: illegal start of expression
 >     [javac]     static int[] begin = new int[] {
 >     [javac]         ^
 >     [javac] /home/zander/sources/java/mauve/gnu/testlet/java/text/SimpleDateFormat/attribute.java:168: illegal start of expression
 >     [javac]     static int[] end = new int[] {
 > 
 > I don't think these 'static' modifiers are needed in the first place; but why were
 > they added?

Beats me.  Whatever they are for, they do nothing to test date formatting.

 > Second; I found at least one directory that contains java files without a
 > package; leading it to be uncompilable (due to duplicate class names)
 > I found:
 > gnu/testlet/BinaryCompatibility/altered/
 > Should those have package lines??

No.  This package comes with a script that does the building and
copies some files around.  I suppose you could create a Ant version of
this script.

 > >  > Please make the project seem 'less dead' to the passing eye!!  If
 > >  > Red-hat does not do anything; what about moving the project to
 > >  > sourceforge or savannah ??
 > >
 > > How would moving the project to a different server help?  Many people
 > > contribute to Mauve, Red Hat provide the server.
 > 
 > Oh; I did not want to imply mauve can't run on a RedHat server; my
 > intent was to let you know of the problems. And since I could not
 > imagine being the first to notice them I added a suggestion in case
 > the pages on RedHat's servers were not available to the project
 > members.
 > Anyway;  Please make the project seem 'less dead' to the passing eye!!

 > >  > maybe someone here can answer my question posted on the
 > >  > classpath list a couple of days ago (providing a patch to mauve).
 > >  > http://mail.gnu.org/archive/html/classpath/2004-04/msg00000.html
 > >
 > > It was a very strange patch.  A tarfile with one file that was a diff,
 > > and a new directory.  However, that patch looks reasonable enough.
 > > However, there was no ChangeLog entry; we'll need one of those.
 > 
 > I noticed that the patch does not cleanly apply anymore; here is a new diff.

Sorry to make this difficult, but the ChangeLog must contain the names
of all the files that are added, with some comment.  The diff must
contain everything that changes: use "diff -N" to generate diffs with
new files.

Andrew.

Re: Some issues..

[Thomas Zander]

[-- Attachment #1: Type: Text/Plain, Size: 732 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Saturday 03 April 2004 17:41, Andrew Haley wrote:
> Thomas Zander writes:
> Sorry to make this difficult, but the ChangeLog must contain the names
> of all the files that are added, with some comment.  The diff must
> contain everything that changes: use "diff -N" to generate diffs with
> new files.

Here is a diff off what I did here.
1) fix compilation of attribute.java
2) add ant stuff
3) add some tests in swing.

Hope you can use it in 1 patch!

- -- 
Thomas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAbuDMCojCW6H2z/QRAuZLAJ4xRwtKNJRjCmOnVids0XUo79CHiQCfZg9S
SM9gNhmRIBR3sUMvx2Kukfo=
=TCmt
-----END PGP SIGNATURE-----

[-- Attachment #2: mauve.diff.bz2 --]
[-- Type: application/x-bzip2, Size: 11602 bytes --]

Re: Some issues..

[Mark Wielaard]

[-- Attachment #1: Type: text/plain, Size: 758 bytes --]

Hi,

On Sat, 2004-04-03 at 17:41, Andrew Haley wrote:
> Thomas Zander writes:
>  > Second; I found at least one directory that contains java files without a
>  > package; leading it to be uncompilable (due to duplicate class names)
>  > I found:
>  > gnu/testlet/BinaryCompatibility/altered/
>  > Should those have package lines??
> 
> No.  This package comes with a script that does the building and
> copies some files around.  I suppose you could create a Ant version of
> this script.

Which script is this? Is it documented?
Might it be a good idea to add these tests to a separate module like the
visual tester and the verifier tests since they are actually different
from the rest of the mauve core library tests?

Cheers,

Mark

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Some issues..

[Andrew Haley]

Mark Wielaard writes:
 > Hi,
 > 
 > On Sat, 2004-04-03 at 17:41, Andrew Haley wrote:
 > > Thomas Zander writes:
 > >  > Second; I found at least one directory that contains java files without a
 > >  > package; leading it to be uncompilable (due to duplicate class names)
 > >  > I found:
 > >  > gnu/testlet/BinaryCompatibility/altered/
 > >  > Should those have package lines??
 > > 
 > > No.  This package comes with a script that does the building and
 > > copies some files around.  I suppose you could create a Ant version of
 > > this script.
 > 
 > Which script is this? 

Err, the one in the BinaryCompatibility directory...

It's called `foo', of course!  :-)

 > Is it documented?

Yeah, right.

 > Might it be a good idea to add these tests to a separate module
 > like the visual tester and the verifier tests since they are
 > actually different from the rest of the mauve core library tests?

Can you please be a little more specific about this?

Andrew.

Re: Some issues..

[Mark Wielaard]

[-- Attachment #1: Type: text/plain, Size: 1759 bytes --]

Hi,

On Fri, 2004-04-16 at 11:30, Andrew Haley wrote:
> Mark Wielaard writes:
>  > Which script is this? 
> 
> Err, the one in the BinaryCompatibility directory...
> 
> It's called `foo', of course!  :-)

Aha. Wow. I never found that before.
Ehe, how do you use/invoke it?

I tried setting JAVA/JAVAC/GCJ as variables before invoking foo, but in
all cases it fails in weird and wonderful ways either compiling or
running. One issue seems to be that it does want the gnu/testlet/*.java
files, but this is never specified in its classpath or sourcepath.

>  > Is it documented?
> 
> Yeah, right.

:)
I admit to be guilty of not documenting my batch_run and runner script.
But a little blurb in the README wouldn't hurt.
If I promise to add something about my scripts, could you add something
about yours? At least how to invoke the thing...

>  > Might it be a good idea to add these tests to a separate module
>  > like the visual tester and the verifier tests since they are
>  > actually different from the rest of the mauve core library tests?
> 
> Can you please be a little more specific about this?

Since it seem to not be integrated with the rest of the tests (but I
might be wrong about this since I couldn't get them working at all) it
might make sense to but it into their own module. Like the verifier
tests and the visual test engine (CVS modules verify and wonka). It
seems this binary compatibility test is useful on its own without any
dependency on the core library tests so we might want to promote it to
its own CVS module that people can just use without worrying about all
the rest. And it would add a new bullet point on the website which makes
the project seem more alive :)

Cheers,

Mark

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Some issues.. (batch_run and runner script documentation)

[Mark Wielaard]

[-- Attachment #1: Type: text/plain, Size: 1455 bytes --]

Hi,

On Fri, 2004-04-16 at 13:29, Mark Wielaard wrote:
> On Fri, 2004-04-16 at 11:30, Andrew Haley wrote:
> > Mark Wielaard writes:
> >  > Is it documented?
> > 
> > Yeah, right.
> 
> :)
> I admit to be guilty of not documenting my batch_run and runner script.
> But a little blurb in the README wouldn't hurt.
> If I promise to add something about my scripts, could you add something
> about yours? At least how to invoke the thing...

OK. I added the following to README:

+An alternative way to compiling and running all tests is the batch_run
+script.  This makes it easy to run all test in one batch without worrying
+wheter all tests compile and/or running them crashes or hangs the runtime.
+
+batch_run and the runner helper script aren't integrated with the configure
+setup yet so you will have to edit them by hand to explicitly set the
+COMPILER variable in batch_run and the RUNTIME variable in runner.
+Optionally you can also change the KEYS setting in batch_run if you don't
+want to run all tests.  You can also set the variable NATIVE=true in
+batch_run when you want to use gcj (without -C) in native mode.
+
+When a test cannot be compiled with the given COMPILER batch_run will
+output FAIL: <testname> COMPILE FAILED and go on with the next test.
+If the runner detects a runtime crash or timeout (runner variable
+WAIT=60 seconds) it will output FAIL: <testname> CRASH or TIMEOUT.

Cheers,

Mark

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Some issues..

[Andrew Haley]

Mark Wielaard writes:
 > Hi,
 > 
 > On Fri, 2004-04-16 at 11:30, Andrew Haley wrote:
 > > Mark Wielaard writes:
 > >  > Which script is this? 
 > > 
 > > Err, the one in the BinaryCompatibility directory...
 > > 
 > > It's called `foo', of course!  :-)
 > 
 > Aha. Wow. I never found that before.
 > Ehe, how do you use/invoke it?

It gets invoked automatically when you run Mauve, at least on my
system.  BinaryCompatibilityTest.java is the driver that invokes it.

 > I tried setting JAVA/JAVAC/GCJ as variables before invoking foo, but in
 > all cases it fails in weird and wonderful ways either compiling or
 > running. One issue seems to be that it does want the gnu/testlet/*.java
 > files, but this is never specified in its classpath or sourcepath.

Well, I can't really understand the problem.

BinaryCompatibilityTest.java is tagged JDK1.1, so it gets run along
with the rest of Mauve.  It then does all the grunt work and runs the
test.  So, if it fails, something else is wrong.

 > >  > Is it documented?
 > > 
 > > Yeah, right.
 > 
 > :)
 > I admit to be guilty of not documenting my batch_run and runner script.
 > But a little blurb in the README wouldn't hurt.
 > If I promise to add something about my scripts, could you add something
 > about yours? At least how to invoke the thing...
 > 
 > >  > Might it be a good idea to add these tests to a separate module
 > >  > like the visual tester and the verifier tests since they are
 > >  > actually different from the rest of the mauve core library tests?
 > > 
 > > Can you please be a little more specific about this?
 > 
 > Since it seem to not be integrated with the rest of the tests (but I
 > might be wrong about this since I couldn't get them working at all)

It is, it is!

I want it to be run whenever we run Mauve.

Andrew.

Re: Some issues..

[Mark Wielaard]

[-- Attachment #1: Type: text/plain, Size: 615 bytes --]

Hi,

On Fri, 2004-04-16 at 14:03, Andrew Haley wrote:
> Mark Wielaard writes:
>  > Ehe, how do you use/invoke it?
> 
> It gets invoked automatically when you run Mauve, at least on my
> system.  BinaryCompatibilityTest.java is the driver that invokes it.

Aha. And it uses Runtime.exec()... Which wasn't properly implemented in
GNU Classpath proper. But we have it now (almost)!

ow that I can run it I see that kaffe, jamvm and gij all fail most of
the tests. Each of IL bin_01 till IL bin_18 fails 5 or 6 times giving:
107 of 125 tests failed

Do you get better/other results?

Cheers,

Mark

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Some issues..

[Mark Wielaard]

[-- Attachment #1: Type: text/plain, Size: 1791 bytes --]

Hi,

On Sat, 2004-04-03 at 15:04, Thomas Zander wrote:
> Hmm;
> I spent a couple of days running with the snapshot which I downloaded from
> the webpage (http://sources.redhat.com/mauve/) until I found out is _very_
> far from recent (which the 'snapshot' seemed to imply)
> I must say its pretty bad that the snapshot is over a year old!!
> I suggest to remote the snapshot; or have up-to-date versions created
> nightly.

So sorry about that. I asked around and Tom will install a script on
sources to make sure we get fresh snapshots up again. (Thanks Tom!)

> I looked at the homepage and found a 'breaking news' that I found rather
> dubious; it looks like its been there for ages since the 'sidebar' does
> not work (on either konqueror or on mozilla), the 'logo design' leads to a
> dead link, the 'contribute'  page is empty..

We really need to update the website.
If someone wants to then they can get the website files with:
cvs -d :pserver:anoncvs@sources.redhat.com:/cvs/mauve checkout htdocs

BTW see http://sources.redhat.com/cgi-bin/cvsweb.cgi/?cvsroot=mauve for
other modules like verify and "wonka" (the visual test engine).

> Please make the project seem 'less dead' to the passing eye!!  If Red-hat
> does not do anything; what about moving the project to sourceforge or
> savannah ??

It isn't really Red Hat not doing things. They are just hosting the
project. Like sourceforge or savnnah would do. We need people to
actually work on the pages (and complain loudly on the mailing list) to
make the project seem less dead. (And thanks again for yelling and
screaming, we have been a bit neglecting the appearance of the project.)

> if this is a mailinglist; please cc answers!

CCed. But please join the list!

Cheers,

Mark

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: Some issues..

[John Leuner]

I haven't read all the list postings, so forgive me if I missed
something. (my reply is below)

> I spent a couple of days running with the snapshot which I downloaded from
> the webpage (http://sources.redhat.com/mauve/) until I found out is _very_
> far from recent (which the 'snapshot' seemed to imply)
> I must say its pretty bad that the snapshot is over a year old!!
> I suggest to remote the snapshot; or have up-to-date versions created
> nightly.
> 
> I looked at the homepage and found a 'breaking news' that I found rather
> dubious; it looks like its been there for ages since the 'sidebar' does
> not work (on either konqueror or on mozilla), the 'logo design' leads to a
> dead link, the 'contribute'  page is empty..

> Please make the project seem 'less dead' to the passing eye!!  If Red-hat
> does not do anything; what about moving the project to sourceforge or
> savannah ??

Yes, I think it makes a lot of sense to move the website part of mauve
to a site like sourceforge. This would make the maintenance of the web
pages easier (it's easy to give people access on sourceforge).

I don't see any reason to move any of the other services however (I
assume "other services" is just the CVS repo?).

John Leuner

-- 
John Leuner <jewel@pixie.co.za>

Re: Some issues..

[Thomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday 07 May 2004 13:39, John Leuner wrote:
> > Please make the project seem 'less dead' to the passing eye!!  If Red-hat
> > does not do anything; what about moving the project to sourceforge or
> > savannah ??
>
> Yes, I think it makes a lot of sense to move the website part of mauve
> to a site like sourceforge. This would make the maintenance of the web
> pages easier (it's easy to give people access on sourceforge).
>
> I don't see any reason to move any of the other services however (I
> assume "other services" is just the CVS repo?).

Actually; I was blessed with a CVS account a couple of days ago. I have a 
(graphical) design of a cleaned up page on my machine at home; my html is 
extremely rusty, but I intend to work a little on creating a new look this 
weekend.
If I create something nice looking I'll put it up somewhere for all to see and 
judge, moving it to the real mauve site is a piece of cake if an agreement is 
found.

- -- 
Regards
Thomas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFAm45SCojCW6H2z/QRAnq4AJ9PbPGkddr47Ros458qdH/4Ewfy1gCgph/3
tQav5KPZF4bL8vDHBcEDJoU=
=3yPc
-----END PGP SIGNATURE-----

RE: Some issues..

[Jeroen Frijters]

Mark Wielaard wrote:
> On Fri, 2004-04-16 at 14:03, Andrew Haley wrote:
> > Mark Wielaard writes:
> >  > Ehe, how do you use/invoke it?
> > 
> > It gets invoked automatically when you run Mauve, at least on my
> > system.  BinaryCompatibilityTest.java is the driver that invokes it.
> 
> Aha. And it uses Runtime.exec()... Which wasn't properly 
> implemented in GNU Classpath proper. But we have it now (almost)!
> 
> ow that I can run it I see that kaffe, jamvm and gij all fail most of
> the tests. Each of IL bin_01 till IL bin_18 fails 5 or 6 times giving:
> 107 of 125 tests failed

I never really payed attention to this test, but now I see that it is
*nix specific (using shell script <shiver>).

What is the policy for Mauve? I realise most of you don't care about/for
Windows, but personally I do. So I support Mark's earlier
suggestion/request to move this to a separate section.

On a somewhat related note, the invalid_port test in DatagramSocketTest2
assumes that it is illegal to create a DatagramSocket that listens on
port 21, but I don't believe that is part of the Java specification.

Regards,
Jeroen

RE: Some issues..

[Mark Wielaard]

[-- Attachment #1.1: Type: text/plain, Size: 1982 bytes --]

Hi,

On Fri, 2004-04-23 at 11:11, Jeroen Frijters wrote:
> Mark Wielaard wrote:
> > On Fri, 2004-04-16 at 14:03, Andrew Haley wrote:
> > > Mark Wielaard writes:
> > >  > Ehe, how do you use/invoke it?
> > > 
> > > It gets invoked automatically when you run Mauve, at least on my
> > > system.  BinaryCompatibilityTest.java is the driver that invokes it.
> > 
> > Aha. And it uses Runtime.exec()... Which wasn't properly 
> > implemented in GNU Classpath proper. But we have it now (almost)!
> > 
> > ow that I can run it I see that kaffe, jamvm and gij all fail most of
> > the tests. Each of IL bin_01 till IL bin_18 fails 5 or 6 times giving:
> > 107 of 125 tests failed
> 
> I never really payed attention to this test, but now I see that it is
> *nix specific (using shell script <shiver>).
> 
> What is the policy for Mauve? I realise most of you don't care about/for
> Windows, but personally I do. So I support Mark's earlier
> suggestion/request to move this to a separate section.

There is always Cygwin <http://cygwin.com/>
But I do think it might be better to separate out this test from the
rest of Mauve proper. On the other hand, if you have a non-GNUish/Posix
system then you can always disable this one test. Separating it out
without a mechanism for running the tests on multiple systems isn't
really worth it I guess.

> On a somewhat related note, the invalid_port test in DatagramSocketTest2
> assumes that it is illegal to create a DatagramSocket that listens on
> port 21, but I don't believe that is part of the Java specification.

I believe you are right. It is only an issue for processes without
enough privileges on some systems (which normally reserve all post
between 0 and 1024 for "system" services). So I committed this patch:

2004-04-25  Mark Wielaard  <mark@klomp.org>

       * gnu/testlet/java/net/DatagramSocket/DatagramSocketTest2.java: Remove
       RESERVED_PORT (21) test.

Cheers,

Mark


[-- Attachment #1.2: patch --]
[-- Type: text/x-patch, Size: 1319 bytes --]

Index: gnu/testlet/java/net/DatagramSocket/DatagramSocketTest2.java
===================================================================
RCS file: /cvs/mauve/mauve/gnu/testlet/java/net/DatagramSocket/DatagramSocketTest2.java,v
retrieving revision 1.5
diff -u -r1.5 DatagramSocketTest2.java
--- gnu/testlet/java/net/DatagramSocket/DatagramSocketTest2.java	29 Oct 2003 14:39:20 -0000	1.5
+++ gnu/testlet/java/net/DatagramSocket/DatagramSocketTest2.java	25 Apr 2004 11:08:51 -0000
@@ -59,7 +59,6 @@
 {
 	final static int INVALID_PORT = -1;
 	final static int ECHO_PORT = 7;
-	final static int RESERVED_PORT = 21;
 	final static int GOOD_PORT = 37777;
 	final static int MAX_PORT = 65535;
 
@@ -93,25 +92,6 @@
 	public void invalid_port()
 	{
 		harness.checkPoint("invalid_port");
-		try
-		{
-			DatagramSocket sock = new DatagramSocket(RESERVED_PORT);
-			errormsg("invalid_port", 1, true, "BindException");
-		}
-		catch (BindException e)
-		{
-			harness.check(true);
-		}
-		catch (SocketException e)
-		{
-			errormsg("invalid_port", 1, false, "SocketException");
-		}
-		catch (NullPointerException e)
-		{
-			errormsg("invalid_port", 1, false, "NullPointerException");
-			e.printStackTrace();
-		}
-
 		try
 		{
 			DatagramSocket sock = new DatagramSocket(INVALID_PORT);

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

RE: Some issues..

[Andrew Haley]

Mark Wielaard writes:
 > Hi,
 > 
 > On Fri, 2004-04-23 at 11:11, Jeroen Frijters wrote:
 > > Mark Wielaard wrote:
 > > > On Fri, 2004-04-16 at 14:03, Andrew Haley wrote:
 > > > > Mark Wielaard writes:
 > > > >  > Ehe, how do you use/invoke it?
 > > > > 
 > > > > It gets invoked automatically when you run Mauve, at least on my
 > > > > system.  BinaryCompatibilityTest.java is the driver that invokes it.
 > > > 
 > > > Aha. And it uses Runtime.exec()... Which wasn't properly 
 > > > implemented in GNU Classpath proper. But we have it now (almost)!
 > > > 
 > > > ow that I can run it I see that kaffe, jamvm and gij all fail most of
 > > > the tests. Each of IL bin_01 till IL bin_18 fails 5 or 6 times giving:
 > > > 107 of 125 tests failed
 > > 
 > > I never really payed attention to this test, but now I see that it is
 > > *nix specific (using shell script <shiver>).
 > > 
 > > What is the policy for Mauve? I realise most of you don't care
 > > about/for Windows, but personally I do.

 > > So I support Mark's earlier suggestion/request to move this to a
 > > separate section.

Well, alright, as long as you don't have to run it separately if you
are on a *nix system.

 > There is always Cygwin <http://cygwin.com/>

I think Windows has its own *nix compatible subsystem now.  But I'm
not an expert...

 > But I do think it might be better to separate out this test from the
 > rest of Mauve proper. On the other hand, if you have a non-GNUish/Posix
 > system then you can always disable this one test. Separating it out
 > without a mechanism for running the tests on multiple systems isn't
 > really worth it I guess.

I don't see the problem, really.  If it doesn't run on some system,
what is lost?  All that happens is a few test failures.

There's no reason why someone who is using an unfree OS can't rewrite
this test in pure Java if they really need it.  But I note that this
shell script will work even on MacOS these days.

Andrew.

Re: Some issues..

[Thomas]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday 29 April 2004 13:39, Andrew Haley wrote:
> I don't see the problem, really.  If it doesn't run on some system,
> what is lost?  All that happens is a few test failures.

For most test environments I make the whole build fail as soon as a test 
fails; this is implemented in the ant-based mauve test as well.
The reason for this is simple; if a test fails its a regression bug; you can't 
commit changes while you have a regression bug.

This might not seem fully logical for mauve; but do expect people to become 
very annoyed when tests fail. Its a mental thing; 100% correct is a world of 
difference from 99.5% correct.

- -- 
Regards
Thomas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFAkQBhCojCW6H2z/QRAvfkAJwMo1BgIdRyeTewvgt4oY+q09wi0QCfZyUJ
IeWgI6C9oI5jnDeC4fA14Mo=
=jM5V
-----END PGP SIGNATURE-----

Re: Some issues..

[Andrew Haley]

Thomas writes:
 > -----BEGIN PGP SIGNED MESSAGE-----
 > Hash: SHA1
 > 
 > On Thursday 29 April 2004 13:39, Andrew Haley wrote:
 > > I don't see the problem, really.  If it doesn't run on some system,
 > > what is lost?  All that happens is a few test failures.
 > 
 > For most test environments I make the whole build fail as soon as a test 
 > fails; this is implemented in the ant-based mauve test as well.
 > The reason for this is simple; if a test fails its a regression bug; you can't 
 > commit changes while you have a regression bug.

Okay, but if you're going to insist on this you need a way to mark
known/expected failures: does any VM pass everything?  So, why not
mark this whole thing as "known to fail" on Windows and move on?

Andrew.

Re: Some issues..

[Thomas Zander]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday 29 April 2004 17:28, Andrew Haley wrote:
> Thomas writes:
>  > -----BEGIN PGP SIGNED MESSAGE-----
>  > Hash: SHA1
>  >
>  > On Thursday 29 April 2004 13:39, Andrew Haley wrote:
>  > > I don't see the problem, really.  If it doesn't run on some system,
>  > > what is lost?  All that happens is a few test failures.
>  >
>  > For most test environments I make the whole build fail as soon as a
>  > test fails; this is implemented in the ant-based mauve test as well.
>  > The reason for this is simple; if a test fails its a regression bug;
>  > you can't commit changes while you have a regression bug.
>
> Okay, but if you're going to insist on this you need a way to mark
> known/expected failures: does any VM pass everything?  So, why not
> mark this whole thing as "known to fail" on Windows and move on?

There are 3 approaches to this; I'd suggest the first for ease of use..
1) check in the test (or even in the test-framework) if a system setting is 
present.  
If(System.getProperty("os.name").equals("Windows")) return;

2) add tags to the source files that say "Exclude this on.."
Tags like: Windows, i386, 64bit etc.

3) add negative tags to the sourc files that say: "Only run this test on.."
Tags like: Unix, 32bit, Kaffe etc.

- -- 
Thomas
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAk3JfCojCW6H2z/QRAk5uAKCNQhwbaX82CxizgYJMNd/FxANgrQCghUOD
D07PnmqzkMUmdAJdzN3DSyw=
=q/Un
-----END PGP SIGNATURE-----

Re: Some issues..

[Andrew Haley]

Thomas Zander writes:
 > -----BEGIN PGP SIGNED MESSAGE-----
 > Hash: SHA1
 > 
 > On Thursday 29 April 2004 17:28, Andrew Haley wrote:
 > > Thomas writes:
 > >  > -----BEGIN PGP SIGNED MESSAGE-----
 > >  > Hash: SHA1
 > >  >
 > >  > On Thursday 29 April 2004 13:39, Andrew Haley wrote:
 > >  > > I don't see the problem, really.  If it doesn't run on some system,
 > >  > > what is lost?  All that happens is a few test failures.
 > >  >
 > >  > For most test environments I make the whole build fail as soon as a
 > >  > test fails; this is implemented in the ant-based mauve test as well.
 > >  > The reason for this is simple; if a test fails its a regression bug;
 > >  > you can't commit changes while you have a regression bug.
 > >
 > > Okay, but if you're going to insist on this you need a way to mark
 > > known/expected failures: does any VM pass everything?  So, why not
 > > mark this whole thing as "known to fail" on Windows and move on?
 > 
 > There are 3 approaches to this; I'd suggest the first for ease of use..
 > 1) check in the test (or even in the test-framework) if a system setting is 
 > present.  
 > If(System.getProperty("os.name").equals("Windows")) return;

This sounds not entirely unreasonable, but there is one disadvantage:
if the Win system has a working shell, it seems a shame not to run
this test.  But in this case it's probably not important one way or
the other: if the Runtime.exec() fails, you can just return.  It's
really only gcj that needs these tests as far as I am aware.

Andrew.