On 6/26/08 12:06 AM, Mark Mitchell wrote:
I am a huge fan of testing, but I do think that right now we're running
too much testing for not enough return. It's not that the testing is
bad, or that more testing doesn't prevent bugs; it's that the marginal
cost of bug-prevention from the Java
Mark Mitchell wrote:
Andrew Haley wrote:
But, I am actually ok with having it be disabled by default, provided
that regressions affect gcj are treated seriously: fixed in a timely
way by the person causing the regression, or, if not, letting gcj
maintainers start the patch-reversion clock.
Andrew Haley wrote:
I agree. I also agree that if someone breaks Java, they should be
required to fix the problem. In fact, we could have the rule that the
Java maintainers get to revert a patch summarily based merely on the
fact that there exists a Java post-patch failure that does not occur
Mark Mitchell wrote:
Andrew Haley wrote:
I agree. I also agree that if someone breaks Java, they should be
required to fix the problem. In fact, we could have the rule that the
Java maintainers get to revert a patch summarily based merely on the
fact that there exists a Java post-patch
All,
--- Andrew Haley [EMAIL PROTECTED] wrote:
Mark Mitchell wrote:
Andrew Haley wrote:
I agree. I also agree that if someone breaks Java, they should be
required to fix the problem. In fact, we could have the rule that the
Java maintainers get to revert a patch summarily based
Andrew Haley writes:
Mark Mitchell wrote:
Andrew Haley wrote:
But, I am actually ok with having it be disabled by default, provided
that regressions affect gcj are treated seriously: fixed in a timely
way by the person causing the regression, or, if not, letting gcj
maintainers start
Andrew Haley wrote:
But, I am actually ok with having it be disabled by default, provided
that regressions affect gcj are treated seriously: fixed in a timely
way by the person causing the regression, or, if not, letting gcj
maintainers start the patch-reversion clock.
If we make this change
Ben Elliston [EMAIL PROTECTED] writes:
On Sun, 2008-06-22 at 07:32 -0700, Ian Lance Taylor wrote:
I think it would only be a few days of work for somebody familiar with
Tcl to add -j support to DejaGNU. I think that would be a very useful
contribution to gcc development.
What did you have
Ian Lance Taylor [EMAIL PROTECTED] writes:
This feature could not be used when executing
programs on a target board or when using DejaGNU to drive a compiler
running on a different host; however, that is not the common case.
To be clear, when using an embedded target board, the compilations
2008/6/23 NightStrike:
On 6/23/08, Laurent GUERBY wrote:
I think it could also be addressed with the gcc compile farm. I
thought that there was some place where we could put patches, and they
would be automatically picked up and tested by some sort of automatic
scripts am I dreaming
From: Laurent GUERBY [EMAIL PROTECTED]
Date: Sat, 21 Jun 2008 22:12:24 +0200
I'm curious at how many GCC developpers use non x86/_64 as their
main development machine (and how many non x86/_64 core they use).
I definitely am one.
Or, maybe you are asking the wrong question, which likely
On Sun, 2008-06-22 at 00:04 -0700, David Miller wrote:
From: Laurent GUERBY [EMAIL PROTECTED]
Date: Sat, 21 Jun 2008 22:12:24 +0200
I'm curious at how many GCC developpers use non x86/_64 as their
main development machine (and how many non x86/_64 core they use).
I definitely am one.
From: Laurent GUERBY [EMAIL PROTECTED]
Date: Sun, 22 Jun 2008 09:21:32 +0200
On Sun, 2008-06-22 at 00:04 -0700, David Miller wrote:
From: Laurent GUERBY [EMAIL PROTECTED]
Date: Sat, 21 Jun 2008 22:12:24 +0200
I'm curious at how many GCC developpers use non x86/_64 as their
main
On Sun, 2008-06-22 at 00:45 -0700, David Miller wrote:
How many core does your main development machine have?
8 cores and 8 cpu threads per core on one, 64 cpus total.
16 cores and 8 cpu threads per core on another, 128 cpus total.
It still takes an hour or so to bootstrap on these
From: Laurent GUERBY [EMAIL PROTECTED]
Date: Sun, 22 Jun 2008 10:05:26 +0200
On Sun, 2008-06-22 at 00:45 -0700, David Miller wrote:
How many core does your main development machine have?
8 cores and 8 cpu threads per core on one, 64 cpus total.
16 cores and 8 cpu threads per core on
Sent from my iPhone because I no longer have Internet access at home :(.
On Jun 22, 2008, at 0:21, Laurent GUERBY [EMAIL PROTECTED] wrote:
On Sun, 2008-06-22 at 00:04 -0700, David Miller wrote:
From: Laurent GUERBY [EMAIL PROTECTED]
Date: Sat, 21 Jun 2008 22:12:24 +0200
I'm curious at how
On 6/22/08, Andrew Pinski [EMAIL PROTECTED] wrote:
On Jun 22, 2008, at 2:08, Andrew Pinski [EMAIL PROTECTED] wrote:
On Jun 22, 2008, at 0:21, Laurent GUERBY [EMAIL PROTECTED] wrote:
On Sun, 2008-06-22 at 00:04 -0700, David Miller wrote:
From: Laurent GUERBY [EMAIL PROTECTED]
Date:
On Sat, Jun 21, 2008 at 08:58:05PM +0200, Laurent GUERBY wrote:
On Sat, 2008-06-21 at 08:10 -0400, Diego Novillo wrote:
On Sat, Jun 21, 2008 at 05:21, Andrew Haley [EMAIL PROTECTED] wrote:
And for make -k check:
-j1 2h18
-j2 1h11
-j4 0h55
-j6 0h44
For make check, it would perhaps help
On Sun, Jun 22, 2008 at 4:04 AM, Richard Kenner
[EMAIL PROTECTED] wrote:
An interesting question that I see as relevant here and for which I have no
data is: what percentage of the time does a patch cause an error *only*
in libjava? I think you have to weigh the cost of the build of that
NightStrike wrote on 22 June 2008 12:57:
On 6/22/08, Andrew Pinski [EMAIL PROTECTED] wrote:
On Jun 22, 2008, at 2:08, Andrew Pinski [EMAIL PROTECTED] wrote:
On Jun 22, 2008, at 0:21, Laurent GUERBY [EMAIL PROTECTED] wrote:
On Sun, 2008-06-22 at 00:04 -0700, David Miller wrote:
From: Laurent
Jakub Jelinek [EMAIL PROTECTED] writes:
On Sat, Jun 21, 2008 at 08:58:05PM +0200, Laurent GUERBY wrote:
On Sat, 2008-06-21 at 08:10 -0400, Diego Novillo wrote:
On Sat, Jun 21, 2008 at 05:21, Andrew Haley [EMAIL PROTECTED] wrote:
And for make -k check:
-j1 2h18
-j2 1h11
-j4 0h55
-j6
Laurent GUERBY [EMAIL PROTECTED] writes:
I noticed insn-attrtab compilation is about 5mn20s and probably
explain about all of the not so perfect speedup: when I look at top it
takes more than 1 minute per stage finishing alone. I've seen it up to 3
minutes alone. There's a comment in the
* Ian Lance Taylor wrote on Sun, Jun 22, 2008 at 04:42:19PM CEST:
First I'll note that insn-attrtab.c is particularly slow for
x86/x86_64, presumably due to the many processor varieties and complex
scheduling. It is much faster for other targets.
Compiling it earlier than it would
* NightStrike wrote on Sun, Jun 22, 2008 at 06:14:22PM CEST:
On 6/22/08, Ian Lance Taylor [EMAIL PROTECTED] wrote:
I think it would only be a few days of work for somebody familiar with
Tcl to add -j support to DejaGNU. I think that would be a very useful
contribution to gcc development.
Ralf == Ralf Wildenhues [EMAIL PROTECTED] writes:
Ralf Has anybody ever looked at using threading capabilities of tcl directly?
At least Fedora compiles the system Tcl without threading enabled.
This has been attempted a few times over the years but apparently
always reverted due to bugs.
Tom
Richard == Richard Kenner [EMAIL PROTECTED] writes:
IME, bugs found during libjava have been also triggered during
libstdc++ and/or C. Though several folks at the summit mentioned that
they had found bugs triggered only by libjava.
Richard To me, as I said, this is the key issue: how often
Richard Guenther wrote:
On Sat, Jun 21, 2008 at 12:50 AM, Richard Kenner
[EMAIL PROTECTED] wrote:
Fundamentally, our philosophy has been to catch errors *before* they get
into the repository. Sure one day of breaking the trunk isn't so bad, but
when it breaks it affects hundreds of developers
On Sun, Jun 22, 2008 at 07:13:03PM +0200, Ralf Wildenhues wrote:
Has anybody ever looked at using threading capabilities of tcl directly?
Parallel DejaGNU could benefit other packages too. There is a thread
pools package (tpool.html, linked from http://wiki.tcl.tk/2770) but I
have no idea how
On Sun, 22 Jun 2008, Daniel Jacobowitz wrote:
On Sun, Jun 22, 2008 at 07:13:03PM +0200, Ralf Wildenhues wrote:
Has anybody ever looked at using threading capabilities of tcl directly?
Parallel DejaGNU could benefit other packages too. There is a thread
pools package (tpool.html, linked
On Fri, Jun 20, 2008 at 1:56 PM, Kaveh R. GHAZI [EMAIL PROTECTED] wrote:
Ugh, I think this is a terrible idea. It took me all of zero days to find
an example of libjava breaking when someone didn't test it:
http://gcc.gnu.org/ml/gcc-patches/2008-06/msg01351.html
Actually that patch caused a
On Fri, Jun 20, 2008 at 1:56 PM, Kaveh R. GHAZI [EMAIL PROTECTED] wrote:
Ugh, I think this is a terrible idea. It took me all of zero days to find
an example of libjava breaking when someone didn't test it:
http://gcc.gnu.org/ml/gcc-patches/2008-06/msg01351.html
This is a bad example for
On Fri, 2008-06-20 at 17:05 -0400, Diego Novillo wrote:
On Fri, Jun 20, 2008 at 16:56, Kaveh R. GHAZI [EMAIL PROTECTED] wrote:
That aside, our current policy already allows e.g. not testing java if
your change is to a part of the compiler that can't possible affect it.
I didn't make it
On Sat, 2008-06-21 at 10:58 +0200, Ralf Wildenhues wrote:
IIRC, then objects in libjava were built from lists of source files as a
means to avoid per-object overhead of libtool and some other stuff, and
to produce a bit better code[1]. Now, at least libtool compile mode
overhead should be a
On Sun, 2008-06-22 at 19:13 +0200, Ralf Wildenhues wrote:
Has anybody ever looked at using threading capabilities of tcl directly?
Parallel DejaGNU could benefit other packages too. There is a thread
pools package (tpool.html, linked from http://wiki.tcl.tk/2770) but I
have no idea how
On Sun, 2008-06-22 at 07:32 -0700, Ian Lance Taylor wrote:
I think it would only be a few days of work for somebody familiar with
Tcl to add -j support to DejaGNU. I think that would be a very useful
contribution to gcc development.
What did you have in mind, Ian? That DejaGnu would run
On Sat, 21 Jun 2008, Andrew Haley wrote:
Steven Bosscher wrote:
On Sat, Jun 21, 2008 at 12:41 AM, Kaveh R. Ghazi [EMAIL PROTECTED] wrote:
Fundamentally, our philosophy has been to catch errors *before* they get
into the repository. Sure one day of breaking the trunk isn't so bad, but
On 6/22/08, Kaveh R. GHAZI [EMAIL PROTECTED] wrote:
IMHO, having more languages and testsuites in the bootstrap process
enhances the quality of GCC. I sympathize with the problems of regtest
duration. I believe some of this could be addressed through making things
run in parallel better.
I
On Sun, 2008-06-22 at 21:57 -0400, NightStrike wrote:
On 6/22/08, Kaveh R. GHAZI [EMAIL PROTECTED] wrote:
IMHO, having more languages and testsuites in the bootstrap process
enhances the quality of GCC. I sympathize with the problems of regtest
duration. I believe some of this could be
* Ben Elliston wrote on Mon, Jun 23, 2008 at 01:58:38AM CEST:
On Sat, 2008-06-21 at 10:58 +0200, Ralf Wildenhues wrote:
IIRC, then objects in libjava were built from lists of source files as a
means to avoid per-object overhead of libtool and some other stuff, and
to produce a bit better
On 6/23/08, Laurent GUERBY [EMAIL PROTECTED] wrote:
I think it could also be addressed with the gcc compile farm. I
thought that there was some place where we could put patches, and they
would be automatically picked up and tested by some sort of automatic
scripts am I dreaming about
On Sat, Jun 21, 2008 at 12:41 AM, Kaveh R. Ghazi [EMAIL PROTECTED] wrote:
Fundamentally, our philosophy has been to catch errors *before* they get
into the repository. Sure one day of breaking the trunk isn't so bad, but
when it breaks it affects hundreds of developers and it adds up.
But,
* David Miller wrote on Sat, Jun 21, 2008 at 12:26:03AM CEST:
I used to be able to bootstrap gcc fully in minutes on average
hardware 6 or so years ago. Those days are long gone. On my largest
64 cpu and 128 cpu boxes it takes forever these days.
The libjava build is notoriously not
Diego Novillo wrote:
On Fri, Jun 20, 2008 at 16:56, Kaveh R. GHAZI [EMAIL PROTECTED] wrote:
That aside, our current policy already allows e.g. not testing java if
your change is to a part of the compiler that can't possible affect it.
I didn't make it completely clear, but my suggestion
Steven Bosscher wrote:
On Sat, Jun 21, 2008 at 12:41 AM, Kaveh R. Ghazi [EMAIL PROTECTED] wrote:
Fundamentally, our philosophy has been to catch errors *before* they get
into the repository. Sure one day of breaking the trunk isn't so bad, but
when it breaks it affects hundreds of developers
On Sat, Jun 21, 2008 at 05:21, Andrew Haley [EMAIL PROTECTED] wrote:
Kaveh does have a point, Diego. The libjava build regularly finds middle-end
problems that are not revealed by bootstrap testing.
So does Ada. This is why I have offered keep building it on my nightly testers.
IME, bugs
IME, bugs found during libjava have been also triggered during
libstdc++ and/or C. Though several folks at the summit mentioned that
they had found bugs triggered only by libjava.
To me, as I said, this is the key issue: how often do we have such bugs?
On 6/21/08, Diego Novillo [EMAIL PROTECTED] wrote:
My point remains that libjava has become a serious problem in the
development cycle of GCC. It takes roughly 3 hours on modern hardware
to finish a GCC bootstrap (with -j2). A significant chunk of which is
taken by libjava. If we could at
On Sat, Jun 21, 2008 at 11:27, NightStrike [EMAIL PROTECTED] wrote:
What do you define as modern hardware?
Dell Precision 390 Core2 6600 @2.40Ghz. 4Gb RAM. Fedora 8.
Diego.
It takes about 50 minutes to bootstrap gcc with -j4 on a Core 2 Quad 2.66GHz
with default language, both 32bit and 64bit enabled. If I use
--enable-checking=assert,
it takes 25 minutes. Given the price of quad core today, there is no
reason no to
use quad core for gcc build.
H.J.
--
On Sat, Jun
On Sat, Jun 21, 2008 at 11:39, H.J. Lu [EMAIL PROTECTED] wrote:
It takes about 50 minutes to bootstrap gcc with -j4 on a Core 2 Quad 2.66GHz
with default language, both 32bit and 64bit enabled. If I use
--enable-checking=assert,
it takes 25 minutes. Given the price of quad core today, there is
On Sat, Jun 21, 2008 at 12:50 AM, Richard Kenner
[EMAIL PROTECTED] wrote:
Fundamentally, our philosophy has been to catch errors *before* they get
into the repository. Sure one day of breaking the trunk isn't so bad, but
when it breaks it affects hundreds of developers and it adds up.
From: Ralf Wildenhues [EMAIL PROTECTED]
Date: Sat, 21 Jun 2008 10:58:55 +0200
Would that be compiles of object files that end up in libgcj (as opposed
to the link, or stuff that depends on libgcj)? If yes, the lack of
parallelism should be fixable.
It's the compilation of the object files,
On 6/21/08, Diego Novillo [EMAIL PROTECTED] wrote:
On Sat, Jun 21, 2008 at 11:39, H.J. Lu [EMAIL PROTECTED] wrote:
It takes about 50 minutes to bootstrap gcc with -j4 on a Core 2 Quad 2.66GHz
with default language, both 32bit and 64bit enabled. If I use
--enable-checking=assert,
it takes
On Sat, 2008-06-21 at 08:10 -0400, Diego Novillo wrote:
On Sat, Jun 21, 2008 at 05:21, Andrew Haley [EMAIL PROTECTED] wrote:
Kaveh does have a point, Diego. The libjava build regularly finds
middle-end
problems that are not revealed by bootstrap testing.
So does Ada. This is why I
Without Ada (=all) bootstrap gets down to 1h54 at -j1 so Ada is 0h24, or
17% of =all, without Ada and Java (=c,c++,fortran,objc) it gets down to
1h17 at -j1 so java is 0h37 or 27% of =all.
Note that I recently made the ada build parallel on trunk, so these figures
should be very different on
How is that irrelevant? If the argument is that libjava takes too
long to build on modern hardware, and someone else has a different
view of what is modern hardware where the original argument is
invalid... what makes your view correct and HJ's view incorrect?
Quad cores are available for
On Sat, 2008-06-21 at 22:05 +0200, Eric Botcazou wrote:
How is that irrelevant? If the argument is that libjava takes too
long to build on modern hardware, and someone else has a different
view of what is modern hardware where the original argument is
invalid... what makes your view
NightStrike wrote on 21 June 2008 17:08:
On 6/21/08, Diego Novillo dnovillo wrote:
On Sat, Jun 21, 2008 at 11:39, H.J. Lu hjl.tools wrote:
It takes about 50 minutes to bootstrap gcc with -j4 on a Core 2 Quad
2.66GHz with default language, both 32bit and 64bit enabled. If I use
On Sat, 21 Jun 2008, Laurent GUERBY wrote:
I'm curious at how many GCC developpers use non x86/_64 as their
main development machine (and how many non x86/_64 core they use).
It's not just backend changes that require testing on non-x86
architectures. And it is very worthwhile to get testing
On Sat, 2008-06-21 at 21:03 +0200, Arnaud Charlet wrote:
Without Ada (=all) bootstrap gets down to 1h54 at -j1 so Ada is 0h24, or
17% of =all, without Ada and Java (=c,c++,fortran,objc) it gets down to
1h17 at -j1 so java is 0h37 or 27% of =all.
Note that I recently made the ada build
An interesting question that I see as relevant here and for which I have no
data is: what percentage of the time does a patch cause an error *only*
in libjava? I think you have to weigh the cost of the build of that
library against the number of bugs that it finds.
Happened to me
Tom Tromey wrote:
Florian == Florian Weimer [EMAIL PROTECTED] writes:
We could look into this. The minimum subset is probably several
hundred classes. For instance, Class refers to URL, which will
probably pull in most of java.net.
Florian Can't you fallback to the interpreter for the
On Fri, 20 Jun 2008, Tom Tromey wrote:
Andrew My suggestion is that we build jc1 but not libgcj by default.
Andrew HOWEVER, we build libgcj on the autobuilders and make very sure that
Andrew if anyone breaks the libgcj build they have to fix their breakage,
Andrew even tho it's not part of
On Fri, Jun 20, 2008 at 16:56, Kaveh R. GHAZI [EMAIL PROTECTED] wrote:
That aside, our current policy already allows e.g. not testing java if
your change is to a part of the compiler that can't possible affect it.
I didn't make it completely clear, but my suggestion was mostly to
help us
On Fri, 20 Jun 2008, Diego Novillo wrote:
On Fri, Jun 20, 2008 at 16:56, Kaveh R. GHAZI [EMAIL PROTECTED] wrote:
That aside, our current policy already allows e.g. not testing java if
your change is to a part of the compiler that can't possible affect it.
I didn't make it completely
On Fri, Jun 20, 2008 at 05:16:41PM -0400, Kaveh R. GHAZI wrote:
On Fri, 20 Jun 2008, Diego Novillo wrote:
On Fri, Jun 20, 2008 at 16:56, Kaveh R. GHAZI [EMAIL PROTECTED] wrote:
That aside, our current policy already allows e.g. not testing java if
your change is to a part of the
On Fri, Jun 20, 2008 at 11:16 PM, Kaveh R. GHAZI [EMAIL PROTECTED] wrote:
On Fri, 20 Jun 2008, Diego Novillo wrote:
On Fri, Jun 20, 2008 at 16:56, Kaveh R. GHAZI [EMAIL PROTECTED] wrote:
That aside, our current policy already allows e.g. not testing java if
your change is to a part of the
From: Steven Bosscher [EMAIL PROTECTED]
Date: Sat, 21 Jun 2008 00:09:26 +0200
What is far more worrying to me, actually, is that libjava grows
bigger and bigger and bigger with every release, so that testing it
costs developers who care zilch about java (i.e. most people) get
penalized more
From: Joe Buck [EMAIL PROTECTED]
On Fri, Jun 20, 2008 at 05:16:41PM -0400, Kaveh R. GHAZI wrote:
On Fri, 20 Jun 2008, Diego Novillo wrote:
On Fri, Jun 20, 2008 at 16:56, Kaveh R. GHAZI [EMAIL PROTECTED]
wrote:
That aside, our current policy already allows e.g. not testing java
if
Fundamentally, our philosophy has been to catch errors *before* they get
into the repository. Sure one day of breaking the trunk isn't so bad, but
when it breaks it affects hundreds of developers and it adds up. Everyone
separately either stops and waits, or tracks down which patch it was
Diego Novillo wrote:
I posted this question to the SC panel at the GCC Summit today. I
wanted to consider the possibility of making java a non-default language.
Would the Java maintainers agree to this?
The rationale is mostly that Java takes a very long time to build, and
it does not
Andrew == Andrew Haley [EMAIL PROTECTED] writes:
Diego I posted this question to the SC panel at the GCC Summit today. I
Diego wanted to consider the possibility of making java a non-default language.
Andrew If this were to happen it would break repeatedly.
Yeah, our experience back when
Tom Tromey wrote:
Andrew == Andrew Haley [EMAIL PROTECTED] writes:
Diego I posted this question to the SC panel at the GCC Summit today. I
Diego wanted to consider the possibility of making java a non-default
language.
Andrew If this were to happen it would break repeatedly.
Yeah,
Andrew Haley [EMAIL PROTECTED] writes:
[ Java ]
I wonder if some compromise less than disabling it as a default everywhere
is possible.
Is it possible to only build and test a subset of libjava by default,
and still get useful coverage of Java? The issue I see is simply that
building libjava
Ian == Ian Lance Taylor [EMAIL PROTECTED] writes:
Ian Is it possible to only build and test a subset of libjava by default,
Ian and still get useful coverage of Java? The issue I see is simply that
Ian building libjava is half of the time required for a bootstrap.
We could look into this. The
On Fri, 2008-06-20 at 10:41 -0600, Tom Tromey wrote:
Andrew == Andrew Haley [EMAIL PROTECTED] writes:
Diego I posted this question to the SC panel at the GCC Summit today. I
Diego wanted to consider the possibility of making java a non-default
language.
Andrew If this were to happen it
Janis Johnson wrote:
On Fri, 2008-06-20 at 10:41 -0600, Tom Tromey wrote:
Andrew == Andrew Haley [EMAIL PROTECTED] writes:
Diego I posted this question to the SC panel at the GCC Summit today. I
Diego wanted to consider the possibility of making java a non-default
language.
Andrew If this
Andrew My suggestion is that we build jc1 but not libgcj by default.
Andrew HOWEVER, we build libgcj on the autobuilders and make very sure that
Andrew if anyone breaks the libgcj build they have to fix their breakage,
Andrew even tho it's not part of the default build. That will prevent most
Tom Tromey wrote:
Ian == Ian Lance Taylor [EMAIL PROTECTED] writes:
Ian Is it possible to only build and test a subset of libjava by default,
Ian and still get useful coverage of Java? The issue I see is simply that
Ian building libjava is half of the time required for a bootstrap.
We
On 6/19/08 11:06 AM, Janis Johnson wrote:
I'll continue to include java in my nightly builds on
powerpc64-unknown-linux-gnu, for which I test with both -m32 and -m64.
Likewise. I will keep including java in my ppc64, i686 and x86_64 daily
testers. I'm only trying to address the every day
Diego Novillo wrote:
On 6/19/08 11:06 AM, Janis Johnson wrote:
I'll continue to include java in my nightly builds on
powerpc64-unknown-linux-gnu, for which I test with both -m32 and -m64.
Likewise. I will keep including java in my ppc64, i686 and x86_64 daily
testers. I'm only trying to
* Tom Tromey:
We could look into this. The minimum subset is probably several
hundred classes. For instance, Class refers to URL, which will
probably pull in most of java.net.
Can't you fallback to the interpreter for the URL class?
Florian == Florian Weimer [EMAIL PROTECTED] writes:
We could look into this. The minimum subset is probably several
hundred classes. For instance, Class refers to URL, which will
probably pull in most of java.net.
Florian Can't you fallback to the interpreter for the URL class?
We prefer
83 matches
Mail list logo
