Re: Mauve wishlist
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thomas Fitzsimmons wrote: > Hi, [...] > There is also lots of room for improvement in how Mauve tests are > selected and run. I'm hoping someone who better understands Mauve's > design will elaborate. I had a very quick look at TestNG[0] and I think it could be a good approach: no need to change the mauve test classes, just invoke the tests with TestNG. There is an eclipse plugin that display the running tests like JUnit. TestNG use a tag feature like we have in mauve (JDK1.1, JDK1.2, ...) and we can add other groups like swing, nio, etc. Those tags can be annotations or javadoc comments (with @ and I think it's processed with xdoclet). As I understood (but I did not read all the documentation), the very big advantage Mauve can take in adopting TestNG (vs JUnit?) is that we shouldn't have to re-write all the test cases! [0] http://testng.org/doc/ - -- Arnaud Vandyck ,= ,-_-. =. ((_/)o o(\_)) `-'(. .)`-' \_/ Java Trap: http://www.gnu.org/philosophy/java-trap.html -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFEHok24vzFZu62tMIRAmOoAJ9VI7oH+83wQ+FPJhvQjDfPNK+KFACbB5DS w3SFrZtDNCcjPNGEzJlDQLE= =7YEE -END PGP SIGNATURE-
Re: [cp-patches] Patch: FYI: implement NumericShaper
On 3/19/06, Stuart Ballard <[EMAIL PROTECTED]> wrote: > As far as I can figure out, an annotation is pretty much the only way > to get these kinds of methods to get flagged by Japi. Actually, I figured out (and implemented in Japi) a place where we can carry a flag on any method without requiring 1.5 at all. Adding an unchecked exception to the throws clause has absolutely no semantic effect (and Japi knows this and ignores them), but Japi can be (and has been) modified to pick up a particular exception and report based on it. I believe Classpath already has an unchecked NotImplementedException so that's what I used. Any method marked as "throws NotImplementedException" will be reported by Japi as "not implemented in Classpath", in the same category as "missing" errors. Any feedback on this approach is welcome, I'm certainly willing to modify it if people have any suggested improvements. Note that I'm not suggesting we just leave all stub methods around indiscriminately and use this trick on them; stub methods that aren't inherited from a superclass and can be removed without breaking compilation should just be removed. But for the ones we can't remove, we can now flag them. Obviously, the throws clause technique only works on methods and constructors, not fields or classes, but I don't think this is a big problem. There's not really any such thing as a "stub field" (it's either there or not) and any classes made up entirely of stubs should surely be removed anyway. If this approach is acceptable to everyone, the next question is how do we identify the stub methods to flag them? Obviously there's no reliable programmatic way but it seems like a program ought to be able to report possible candidates for a human to look through. I think any stub method would fall into one of these categories: A) Void method that does nothing at all or nothing but return; B) Method that unconditionally throws; C) Method that unconditionally calls superclass implementation of the same method with the same args; or D) Method that unconditionally returns a hardcoded constant, including null. Obviously detecting these things would give a lot of false positives, especially D, but I think it should catch all the stubs. Anyone know of a good tool that could produce a list of methods meeting these criteria? Stuart. -- http://sab39.dev.netreach.com/
Re: WinCE
> I don't believe in having a thousand VM projects. Mysaifu is > nowhere near anything specs compliant. Wow this guy is unpolite! Maybe you should ask IBM(J9) or the company that created Creme wether they would give you their JVM for free including the source and even provide support through a mailinglist where you can communicate with their devs. Furthermore if its not enough spec compliant why don't you enhance the parts that bother you? Otherwise I guess you should better spend your 50$ per runtime (yes, per device!) on Creme than wasting traffic here. Clemens
[Bug classpath/26668] java.util.logging bugs
--- Comment #11 from rafaels at redhat dot com 2006-03-20 15:51 --- Created an attachment (id=11072) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11072&action=view) updated patch -- rafaels at redhat dot com changed: What|Removed |Added Attachment #11044|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26668 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
[Bug classpath/26668] java.util.logging bugs
--- Comment #12 from rafaels at redhat dot com 2006-03-20 15:52 --- Created an attachment (id=11073) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11073&action=view) test suite -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26668 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
Re: WinCE
you're too late. If you read everything after, things are clear now. No worries... Clemens Eisserer wrote: I don't believe in having a thousand VM projects. Mysaifu is nowhere near anything specs compliant. Wow this guy is unpolite! Maybe you should ask IBM(J9) or the company that created Creme wether they would give you their JVM for free including the source and even provide support through a mailinglist where you can communicate with their devs. Furthermore if its not enough spec compliant why don't you enhance the parts that bother you? Otherwise I guess you should better spend your 50$ per runtime (yes, per device!) on Creme than wasting traffic here. Clemens
Re: Flagging stubs -- was FYI: implement NumericShaper
On 3/20/06, Andrew John Hughes <[EMAIL PROTECTED]> wrote: > It sounds like a bad hack on the JAPI side, but it's up to you if you're > maintaining this. True enough, but I think the problem of stub-inflated japi reports is important enough to try to find some way of tackling it. Obviously an annotation would be nicer and I'll probably migrate to that once it becomes practical, but I'd rather have a hacky solution today than no solution at all for months. > I can't currently find NotImplementedException in > Classpath outside the new jdwp code, but I may be missing something. > If we have a gnu.classpath.NotImplementedException, then we could catch > this specifically in JAPI, and also output a nice message. I must have misremembered I guess. Japi actually scans for *anything* called "NotImplementedException" in any package (because I was writing this code while offline and besides I want it to work for other projects too who might not be happy with "gnu.classpath." (coughharmonycough). > The immediate problem I see (and why we don't generally use an exception) is > that the problem can still continue with an exception, whereas it can't with > an error. I could easily change it to "NotImplementedError", or accept either. The important thing from Japi's perspective isn't whether the exception *actually* gets thrown - it could be, or the class could silently do nothing as it currently does, which in some cases may still be preferable if the functionality is noncritical. All Japi cares about is whether it shows up in the throws clause. > The main problem I can foresee is actually finding all the code and putting > this in... Yep. Hence the question about automated scanning to find a list of candidates... :) I'd rather have a process that gives lots of false positives than a process that misses lots... Stuart. -- http://sab39.dev.netreach.com/
Flagging stubs -- was FYI: implement NumericShaper
On Mon, 20 Mar 2006 09:15:41 -0500
"Stuart Ballard" <[EMAIL PROTECTED]> wrote:
> On 3/19/06, Stuart Ballard <[EMAIL PROTECTED]> wrote:
> > As far as I can figure out, an annotation is pretty much the only way
> > to get these kinds of methods to get flagged by Japi.
>
> Actually, I figured out (and implemented in Japi) a place where we can
> carry a flag on any method without requiring 1.5 at all. Adding an
> unchecked exception to the throws clause has absolutely no semantic
> effect (and Japi knows this and ignores them), but Japi can be (and
> has been) modified to pick up a particular exception and report based
> on it.
>
> I believe Classpath already has an unchecked NotImplementedException
> so that's what I used. Any method marked as "throws
> NotImplementedException" will be reported by Japi as "not implemented
> in Classpath", in the same category as "missing" errors.
>
It sounds like a bad hack on the JAPI side, but it's up to you if you're
maintaining this. I can't currently find NotImplementedException in
Classpath outside the new jdwp code, but I may be missing something.
If we have a gnu.classpath.NotImplementedException, then we could catch
this specifically in JAPI, and also output a nice message.
The immediate problem I see (and why we don't generally use an exception) is
that the problem can still continue with an exception, whereas it can't with
an error.
> Any feedback on this approach is welcome, I'm certainly willing to
> modify it if people have any suggested improvements.
>
The main problem I can foresee is actually finding all the code and putting
this in...
> Note that I'm not suggesting we just leave all stub methods around
> indiscriminately and use this trick on them; stub methods that aren't
> inherited from a superclass and can be removed without breaking
> compilation should just be removed. But for the ones we can't remove,
> we can now flag them.
>
Agreed; I think this should be a last resort course of action.
> Obviously, the throws clause technique only works on methods and
> constructors, not fields or classes, but I don't think this is a big
> problem. There's not really any such thing as a "stub field" (it's
> either there or not) and any classes made up entirely of stubs should
> surely be removed anyway.
>
> If this approach is acceptable to everyone, the next question is how
> do we identify the stub methods to flag them? Obviously there's no
> reliable programmatic way but it seems like a program ought to be able
> to report possible candidates for a human to look through. I think any
> stub method would fall into one of these categories:
>
> A) Void method that does nothing at all or nothing but return;
> B) Method that unconditionally throws;
> C) Method that unconditionally calls superclass implementation of the
> same method with the same args; or
> D) Method that unconditionally returns a hardcoded constant, including null.
>
> Obviously detecting these things would give a lot of false positives,
> especially D, but I think it should catch all the stubs. Anyone know
> of a good tool that could produce a list of methods meeting these
> criteria?
>
There are some FIXMEs in the code that would also help, but I think it has to
be
a largely manual process starting with a grep of the source for FIXMEs and then
checking likely candidates (there are obviously some classes that are fully
or largely implemented).
This seems like another case of reviewing code that is going to become more
prominent as Classpath matures to a largely implemented codebase. The same
really needs to be done for documentation and security.
> Stuart.
> --
> http://sab39.dev.netreach.com/
>
Cheers,
--
Andrew :-)
Please avoid sending me Microsoft Office (e.g. Word, PowerPoint) attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
Support OpenDocument instead.
Escape the Java Trap with GNU Classpath!
http://www.gnu.org/philosophy/java-trap.html
public class gcj extends Freedom implements Java { ... }
"Value your freedom, or you will lose it, teaches history.
`Don't bother us with politics' respond those who don't want to learn."
-- Richard Stallman
The views expressed above are representative of my own personal
opinions, and not necessarily those of the University of Sheffield.
pgpxNEQAlusPD.pgp
Description: PGP signature
Re: Mauve wishlist
On Fri, 2006-03-17 at 11:32 -0500, Thomas Fitzsimmons wrote: > Hi, > > Anthony Balkissoon has expressed interest in improving Mauve so we'd > like to know what would be the best things to work on. > Another suggestion that Tom Fitzsimmons had was to change the way we count the number of tests. Counting each invocation of the test() method rather than each call to harness.check() has two benefits: 1) constant number of tests, regardless of exceptions being thrown or which if-else branch is taken 2) more realistic number of tests, to accurately reflect the extent of our testing For point 1) this will help us see if we are making progress. Right now a Mauve run might say we have 113 fails out of 13200 tests and then a later run could say 200 fails out of 34000 tests. Is this an improvement? Hard to say. But if we count each call to test() as a test, and also detect hanging tests, then we should have a constant number of tests in each run and will be able to say if changes made have a positive impact on Mauve test results. Of course, if in one particular test file there are 1000 calls to harness.check() and only one of them fails, it's not helpful to just report that the entire test failed. So the output will have to pinpoint which call to harness.check failed (and preferably a line number). The negative side here is that the results will be overly pessimistic because any failing harness.check trumps all the passing harness.check calls and the test is reported as a failure. What do people have to say about this idea? --Tony
Re: [cp-patches] Patch: FYI: implement NumericShaper
> "Andrew" == Andrew John Hughes <[EMAIL PROTECTED]> writes: Tom> We need to declare war on stubs. They improperly inflate our japi Tom> scores and blind us to the real state of Classpath. Also I seem to Tom> keep running into them as I dig around :-( Andrew> My gut instinct would be to remove them all, and really show Andrew> up where we at, in order to motivate people to work on these Andrew> things that appear implemented. While tempting, I think this is too big a hammer for this problem. I'd rather we not break anything that currently works -- whether it is programs that run poorly, or even programs that currently compile (eg where we may rely on a program not using some of the stubs). Having a list of stubs would be a good start. The ones I fixed this weekend I ran across by chance; I had no idea we had stubs in AWT at all. I like David's idea of a STUB comment. Tom
Re: [cp-patches] Patch: FYI: implement NumericShaper
> "Stuart" == Stuart Ballard <[EMAIL PROTECTED]> writes: Stuart> What's the status on the whole ecj-as-gcc-frontend thing? It is still being discussed by the GCC Steering Committee. I'm hopeful that we'll get the go-ahead and be able to have this in GCC 4.2. Stuart> Since gcj Stuart> and ecj are pretty much the only maintained Free java compilers at Stuart> this point, seems to me that's the only blocker to making the generics Stuart> branch the primary development trunk and adopting the new language Stuart> features wholesale... Yes, I want to kill the generics branch (by merging it in :-) this year. With some luck, by the summer. Tom
Re: [cp-patches] Patch: FYI: implement NumericShaper
Tom Tromey writes: > > "Andrew" == Andrew John Hughes <[EMAIL PROTECTED]> writes: > > Tom> We need to declare war on stubs. They improperly inflate our japi > Tom> scores and blind us to the real state of Classpath. Also I seem to > Tom> keep running into them as I dig around :-( > > Andrew> My gut instinct would be to remove them all, and really show > Andrew> up where we at, in order to motivate people to work on these > Andrew> things that appear implemented. > > While tempting, I think this is too big a hammer for this problem. > I'd rather we not break anything that currently works -- whether it is > programs that run poorly, or even programs that currently compile (eg > where we may rely on a program not using some of the stubs). > > Having a list of stubs would be a good start. The ones I fixed this > weekend I ran across by chance; I had no idea we had stubs in AWT at > all. > > I like David's idea of a STUB comment. Yes. I would love to see the stubs gone, but I love evolutionary development more. Andrew.
Re: [cp-patches] Patch: FYI: implement NumericShaper
On 20 Mar 2006 11:45:27 -0700, Tom Tromey <[EMAIL PROTECTED]> wrote: > Having a list of stubs would be a good start. The ones I fixed this > weekend I ran across by chance; I had no idea we had stubs in AWT at > all. > > I like David's idea of a STUB comment. Does anyone know if eclipse allows plugging in custom rules to produce warnings, and where (if anywhere) there's documentation on how to produce such rules? I'd be interested in working on a "stub detector" but I don't really feel like writing an entire Java language parser for the purpose. If anyone can point me to a framework which made it fairly simple to write rules that define criteria based on the structure/semantics of the source code, I'll have a stab at this. FindBugs also sounds like the kind of thing I'm looking for (although I'd rather have something that could work on the source than on the bytecode, because I'm thinking it should be possible to ignore methods if they have a comment like "nothing to do here"), except that (last I heard) it wasn't runnable on a Free runtime. Is this still true? Stuart. -- http://sab39.dev.netreach.com/
Re: [cp-patches] Patch: FYI: implement NumericShaper
> "Stuart" == Stuart Ballard <[EMAIL PROTECTED]> writes: >> I like David's idea of a STUB comment. Stuart> Does anyone know if eclipse allows plugging in custom rules to produce Stuart> warnings, and where (if anywhere) there's documentation on how to Stuart> produce such rules? I don't know. Eclipse can easily find things like 'FIXME' comments, and the list of keywords to search for is configurable. So that would work. The unchecked exception idea would also work, since you can easily search for all references to a given class... if we had a new class for just this purpose, the search would only yield stubs. One thing I've done before to try to find some stubs is search for references to the various Error constructors. This is imprecise though. Tom
Free JVM on Macintel
Hi, Are any free VMs currently supported on OS X for Intel (natively)? Alternatively, if there's a concise description on what's needed to support jamvm or cacao (function call ABI hacks, I'd assume), I'd be happy to hack on it.
Re: Free JVM on Macintel
On Mon, 2006-03-20 at 13:51 -0800, Casey Marshall wrote: > Hi, > > Are any free VMs currently supported on OS X for Intel (natively)? > > Alternatively, if there's a concise description on what's needed to > support jamvm or cacao (function call ABI hacks, I'd assume), I'd be > happy to hack on it. I think it's quite easy (at least for me) to port cacao to i686-darwin. The ABI is the same as on linux, AFAIK. IIRC we don't have anything like a porting guideline. I could tell you what to do, or give me access to a box and you get a port in a half day, probably... :-) TWISTI
[Bug swing/26772] New: Toolbar buttons in Swing demo should not be painted with gradient
The toolbar buttons which can be seen in the top left corner of the Free Swing Demo are currently painted with the typical gradient of the Ocean theme. However on the RI this is not the case. The idea is that if a button is part of a toolbar then special drawing and layout properties are applied. The right place to implement this behavior might be BasicToolBarUI.ToolBarContentListener. -- Summary: Toolbar buttons in Swing demo should not be painted with gradient Product: classpath Version: 0.90 Status: UNCONFIRMED Severity: normal Priority: P3 Component: swing AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: thebohemian at gmx dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26772 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
Re: Free JVM on Macintel
On Mar 20, 2006, at 4:51 PM, Casey Marshall wrote: Hi, Are any free VMs currently supported on OS X for Intel (natively)? There is almost a port of GCJ, libffi was just ported. http://gcc.gnu.org/ml/java-patches/2006-q1/msg00320.html Alternatively, if there's a concise description on what's needed to support jamvm or cacao (function call ABI hacks, I'd assume), I'd be happy to hack on it. Most likely with the port of libffi, all there is needed now is testing. -- Pinski
Re: Free JVM on Macintel
On Mar 20, 2006, at 2:07 PM, Christian Thalinger wrote: On Mon, 2006-03-20 at 13:51 -0800, Casey Marshall wrote: Hi, Are any free VMs currently supported on OS X for Intel (natively)? Alternatively, if there's a concise description on what's needed to support jamvm or cacao (function call ABI hacks, I'd assume), I'd be happy to hack on it. I think it's quite easy (at least for me) to port cacao to i686- darwin. The ABI is the same as on linux, AFAIK. I did blindly try the i386-linux ABI support in jamvm, but that was hitting some weird SIGILL. My understanding is that the Darwin-i386 ABI is very similar to the SYSV ABI, with some alignment changes. I did something like this for MIPS some time ago, so I'm no stranger to this stuff. IIRC we don't have anything like a porting guideline. I could tell you what to do, or give me access to a box and you get a port in a half day, probably... :-) It's a laptop, and as such moves around the Bay Area a lot. A little description (look at this code/do something similar for your CPU/ABI) would help.
Re: [cp-patches] Patch: FYI: implement NumericShaper
> "Stuart" == Stuart Ballard <[EMAIL PROTECTED]> writes: Stuart> I believe Classpath already has an unchecked NotImplementedException Stuart> so that's what I used. Any method marked as "throws Stuart> NotImplementedException" will be reported by Japi as "not implemented Stuart> in Classpath", in the same category as "missing" errors. This is a nice hack, I like it. We probably don't want to use the JDWP exception as a marker, in general... I'd rather not overload it like this. We can easily add 'gnu.classpath.NotImplementedException' though. Stuart> If this approach is acceptable to everyone, the next question is how Stuart> do we identify the stub methods to flag them? By hand I'm afraid... Stuart> A) Void method that does nothing at all or nothing but return; Stuart> B) Method that unconditionally throws; Ones that 'throw new Error' are probable stubs. Sometimes there are methods which legitimately do nothing else; but those tend to throw something more specific. Tom
Re: Free JVM on Macintel
On Mon, 2006-03-20 at 14:55 -0800, Casey Marshall wrote: > I did blindly try the i386-linux ABI support in jamvm, but that was > hitting some weird SIGILL. Strange. > > My understanding is that the Darwin-i386 ABI is very similar to the > SYSV ABI, with some alignment changes. I did something like this for > MIPS some time ago, so I'm no stranger to this stuff. I only remember something related to structures passed in C. > It's a laptop, and as such moves around the Bay Area a lot. A little > description (look at this code/do something similar for your CPU/ABI) > would help. I see. Look at src/vm/jit/powerpc/darwin/*.[ch] stuff and so something like that in src/vm/jit/i386/darwin/. TWISTI
Re: Free JVM on Macintel
On 3/20/06, Casey Marshall <[EMAIL PROTECTED]> wrote: > On Mar 20, 2006, at 2:07 PM, Christian Thalinger wrote: > > > On Mon, 2006-03-20 at 13:51 -0800, Casey Marshall wrote: > >> Hi, > >> > >> Are any free VMs currently supported on OS X for Intel (natively)? > >> > >> Alternatively, if there's a concise description on what's needed to > >> support jamvm or cacao (function call ABI hacks, I'd assume), I'd be > >> happy to hack on it. > > > > I think it's quite easy (at least for me) to port cacao to i686- > > darwin. > > The ABI is the same as on linux, AFAIK. > > > > I did blindly try the i386-linux ABI support in jamvm, but that was > hitting some weird SIGILL. > > My understanding is that the Darwin-i386 ABI is very similar to the > SYSV ABI, with some alignment changes. I did something like this for > MIPS some time ago, so I'm no stranger to this stuff. > Most open-source VMs just rely on libffi to do the nasty calling-convention stuff. Therefore, if libffi is supported on your os/architecture it's already done. JamVM's a bit different in that it used to always use a "handcoded" routine to construct the call-frame on each os/cpu as this tends to be much faster. You've obviously found the linux/i386 one... But to ease porting of JamVM it can now also use libffi. So, at least with JamVM you have two choices : 1) code the calling-convention "by hand" for darwin/i386. It's not difficult, as i386 passes everything on the stack. As you said, it's probably alignment stuff, so the linux code should work with some minor mods. 2) Just use libffi. As Andrew Pinksi says it's ported, all you need to do is have an empty platform init.c in darwin/i386, and use --enable-ffi when configuring JamVM. Apple tends to have good documentation, so it shouldn't be too hard to find the differences. Somebody else has also asked me to support Intel Macs, so I'll see if I get time to look at it this week. However, testing will be difficult, as I don't have an Intel Mac, and I don't intend to buy one :) Rob. > > IIRC we don't have anything like a porting guideline. I could tell > > you > > what to do, or give me access to a box and you get a port in a half > > day, > > probably... :-) > > > > It's a laptop, and as such moves around the Bay Area a lot. A little > description (look at this code/do something similar for your CPU/ABI) > would help. > >
