Am Montag, den 07.03.2005, 21:49 -0600 schrieb Archie Cobbs:
In this thread:
http://lists.gnu.org/archive/html/classpath/2004-12/threads.html#00137
we talked about putting together somehow a list of Mauve tests that
all Classpath-based VMs should expect to pass, along with another
Hi,
while wading throught our fine apidoc on developer.classpath.org/doc I
wondered why java.lang.reflect.InvocationHandler.invoke() does not
show that the method can throw a Throwable. At first I thought it is a
bug in our API implementation but a short glimpse at the source code
revealed
Hi Robert,
Robert Schuster wrote:
while wading throught our fine apidoc on developer.classpath.org/doc I
wondered why java.lang.reflect.InvocationHandler.invoke() does not
show that the method can throw a Throwable. At first I thought it is a
bug in our API implementation but a short glimpse at
Roman Kennke wrote:
http://lists.gnu.org/archive/html/classpath/2004-12/threads.html#00137
we talked about putting together somehow a list of Mauve tests that
all Classpath-based VMs should expect to pass, along with another
(complementary) list of those tests a Classpath-based VM should
expect to
Am Dienstag, den 08.03.2005, 09:11 -0600 schrieb Archie Cobbs:
Roman Kennke wrote:
http://lists.gnu.org/archive/html/classpath/2004-12/threads.html#00137
we talked about putting together somehow a list of Mauve tests that
all Classpath-based VMs should expect to pass, along with another
Roman Kennke wrote:
Ah, now I'm understanding. I think maybe you mean the mauve HTML pages
that I once put together? This basically tested different runtimes
against the Mauve suite and formatted to Mauve output nicely into HTML
for displaying in a browser, so it is easily visible which tests
Am Dienstag, den 08.03.2005, 10:34 -0600 schrieb Archie Cobbs:
Roman Kennke wrote:
Ah, now I'm understanding. I think maybe you mean the mauve HTML pages
that I once put together? This basically tested different runtimes
against the Mauve suite and formatted to Mauve output nicely into HTML
Roman Kennke wrote:
If we're going to make these HTML pages the official place for
VM implementors to look for this information, that's OK. I'd just
like us to decide and then do it, keep them updated, etc. This can
perhaps be automated, etc.
They actually are (or were) automated. Mauve has been
It seems that UrlConnection.getContent() for image/gif should return an
ImageProducer object. I guess doing something like...
package gnu.java.net.content.image;
import java.net.ContentHandler;
import javax.imageio.ImageIO;
public class gif extends ContentHandler{
public Object
On Tue, Mar 08, 2005 at 05:07:08PM +0100, Roman Kennke wrote:
Am Dienstag, den 08.03.2005, 09:11 -0600 schrieb Archie Cobbs:
Roman Kennke wrote:
http://lists.gnu.org/archive/html/classpath/2004-12/threads.html#00137
we talked about putting together somehow a list of Mauve tests that
Chris Pickett wrote:
I think this kind of automated testing/regression testing for Classpath
VM's is a great idea.
s/automated testing/automated compatability/
If it's possible, some performance numbers would be interesting so we
find discrepancies between there VM's there as well.
s/between
It depends on what your definition of
free is, but you night want to checkout the DaCapo benchmarks (http://osl-www.cs.umass.edu/DaCapo/gcbm.html).
The main obligation of the license is that if you use the benchmarks you
need to cite them correctly and report the version number of the benchmark
Hi David,
That's a non-free license.
http://osl-www.cs.umass.edu/DaCapo/gcbm.html#License_and_copyright
This is generally what's accepted to define free software:
http://www.gnu.org/philosophy/free-sw.html
Maybe we need a replacement for DaCapo as well. Thanks for the
suggestion though, it's
I think you need to understand the point
of the benchmark suite. The whole goal is reproducible science, so
if someone doesn't cite the exact version of the benchmarks, then it isn't
useful (in an academic sense). The license forces that plus proper
academic credit (ie a citation) for the
David P Grove wrote:
I think you need to understand the point of the benchmark suite. The
whole goal is reproducible science, so if someone doesn't cite the exact
version of the benchmarks, then it isn't useful (in an academic sense).
That can be achieved without the DaCapo restrictions. For
David P Grove wrote:
I think you need to understand the point of the benchmark suite. The
whole goal is reproducible science, so if someone doesn't cite the exact
version of the benchmarks, then it isn't useful (in an academic sense).
The license forces that plus proper academic credit (ie a
Chris Pickett wrote:
Perhaps a replacement for DaCapo and SPECjvm98 is not in order: this
would make comparison with other papers in the literature difficult and
just confuse the issue. So, how about a good *companion* suite then?
By the way, Ashes was started as a free testing framework for
Chris Pickett wrote:
Chris Pickett wrote:
Perhaps a replacement for DaCapo and SPECjvm98 is not in order: this
would make comparison with other papers in the literature difficult
and just confuse the issue. So, how about a good *companion* suite then?
By the way, Ashes was started as a free
18 matches
Mail list logo
