From: Brian Jones <cbj@nortel.net>
To: Artur Biesiadowski <abies@pg.gda.pl>
Cc: Tim Wilkinson <tim@transvirtual.com>,
mauve <mauve-discuss@sourceware.cygnus.com>
Subject: Re: Library/VM tests
Date: Thu, 04 Mar 1999 10:46:00 -0000 [thread overview]
Message-ID: <m3r9r5umjp.fsf@lyta.nortel.net> (raw)
In-Reply-To: Artur Biesiadowski's message of "Thu, 04 Mar 1999 12:21:48 +0100"
Artur Biesiadowski <abies@pg.gda.pl> writes:
> Tim Wilkinson wrote:
> >
> > I have (finally) been looking into integrating our modest testsuite into
> > Mauve but have run up against a problem. So far as I understand things
> > Mauve is designed to test *only* the library functionality. Given this
> > what are we suppose to do about test which sit on the boundary -
> > ClassLoaders spring to mind but there's also such things as
> > Serialization, Reflection and bunch of other borderline stuff. None of
> > this is VM specific of course but it relies on more heavy VM support
> > than some tests (some stuff uses threads for example).
> >
> > So my question is - what's the policy on this?
>
> So, my personal opinion is that things that you mentioned fir into
> mauve. Example fo thing that will not fit is StackOverflowException or
> OutOfMemoryException testing - they are stritlty VM test, as there is
> really not much to test in actual classes, and have a side effect of
> possibly crashing entire test suite. I think that such tests (together
> with bytecode tests etc), should be done separately - out of mauve.
My personal opinion is that such a testing facility is needed for all
the free VMs including Kaffe, Japhar, etc. If you want to look at the
Mauve project as containing a couple of modules, one for testing core
libraries and the other for testing vms/jit, then I think that would
work well. What, if anything, has to be done to the testing framework
seems like a separate issue to me as well.
Brian
--
|-------------------------------|
|Brian Jones |
|cbj@gnu.org |
| http://www.classpath.org/ |
WARNING: multiple messages have this Message-ID
From: Brian Jones <cbj@nortel.net>
To: Artur Biesiadowski <abies@pg.gda.pl>
Cc: Tim Wilkinson <tim@transvirtual.com>,
mauve <mauve-discuss@sourceware.cygnus.com>
Subject: Re: Library/VM tests
Date: Thu, 01 Apr 1999 00:00:00 -0000 [thread overview]
Message-ID: <m3r9r5umjp.fsf@lyta.nortel.net> (raw)
Message-ID: <19990401000000.aTbAMqph7qc1UG1oxuy5rqOfoLtFqCvjzbLvRakVcrU@z> (raw)
In-Reply-To: <36DE6CCC.83CF838B@pg.gda.pl>
Artur Biesiadowski <abies@pg.gda.pl> writes:
> Tim Wilkinson wrote:
> >
> > I have (finally) been looking into integrating our modest testsuite into
> > Mauve but have run up against a problem. So far as I understand things
> > Mauve is designed to test *only* the library functionality. Given this
> > what are we suppose to do about test which sit on the boundary -
> > ClassLoaders spring to mind but there's also such things as
> > Serialization, Reflection and bunch of other borderline stuff. None of
> > this is VM specific of course but it relies on more heavy VM support
> > than some tests (some stuff uses threads for example).
> >
> > So my question is - what's the policy on this?
>
> So, my personal opinion is that things that you mentioned fir into
> mauve. Example fo thing that will not fit is StackOverflowException or
> OutOfMemoryException testing - they are stritlty VM test, as there is
> really not much to test in actual classes, and have a side effect of
> possibly crashing entire test suite. I think that such tests (together
> with bytecode tests etc), should be done separately - out of mauve.
My personal opinion is that such a testing facility is needed for all
the free VMs including Kaffe, Japhar, etc. If you want to look at the
Mauve project as containing a couple of modules, one for testing core
libraries and the other for testing vms/jit, then I think that would
work well. What, if anything, has to be done to the testing framework
seems like a separate issue to me as well.
Brian
--
|-------------------------------|
|Brian Jones |
|cbj@gnu.org |
| http://www.classpath.org/ |
next prev parent reply other threads:[~1999-03-04 10:46 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-03-02 16:06 Tim Wilkinson
1999-03-03 23:56 ` Tom Tromey
[not found] ` < 87bti94rgj.fsf@cygnus.com >
1999-03-04 12:56 ` Moses DeJong
[not found] ` < Pine.SGI.4.05.9903041452180.811-100000@neon.cs.umn.edu >
1999-03-04 13:11 ` Godmar Back
1999-04-01 0:00 ` Godmar Back
1999-04-01 0:00 ` Moses DeJong
1999-04-01 0:00 ` Tom Tromey
1999-03-04 7:45 ` Artur Biesiadowski
1999-03-04 10:46 ` Brian Jones [this message]
1999-04-01 0:00 ` Brian Jones
1999-03-04 19:03 ` Tim Wilkinson
1999-03-11 23:25 ` Tom Tromey
1999-03-12 3:37 ` VM tests [was Re: Library/VM tests] Artur Biesiadowski
[not found] ` < 36E8FBAD.F4FA1CF@pg.gda.pl >
1999-03-12 8:19 ` Godmar Back
1999-04-01 0:00 ` Godmar Back
1999-04-01 0:00 ` Artur Biesiadowski
1999-04-01 0:00 ` Library/VM tests Tom Tromey
1999-04-01 0:00 ` Tim Wilkinson
1999-04-01 0:00 ` Artur Biesiadowski
1999-04-01 0:00 ` Tim Wilkinson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m3r9r5umjp.fsf@lyta.nortel.net \
--to=cbj@nortel.net \
--cc=abies@pg.gda.pl \
--cc=mauve-discuss@sourceware.cygnus.com \
--cc=tim@transvirtual.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).