On Thu, 27 Feb 2003, David P Grove wrote:
[CG]
What we really need is
#define isNaN(a) ((a) != (a))
I thought we had this already because the classpath Double.isNaN is defined
as:
/**
* Return codetrue/code if the codedouble/code has the same
* value as codeNaN/code,
On Thu, 27 Feb 2003, Aaron M. Renn wrote:
The Classpath project has reached a milestone of sorts. Five years ago
in March 1998, the Classpath project was born when I started work on a
java.net implementation for the Japhar JVM project. Shortly thereafter,
Paul Fisher and Brian Jones
hi Chris,
--- Chris Gray [EMAIL PROTECTED] wrote:
On Thu, 27 Feb 2003, David P Grove wrote:
[CG]
What we really need is
#define isNaN(a) ((a) != (a))
I thought we had this already because the
classpath Double.isNaN is defined
as:
/**
* Return codetrue/code if the
On Fri, 28 Feb 2003, Dalibor Topic wrote:
hi Chris,
--- Chris Gray [EMAIL PROTECTED] wrote:
[...] SFAIK the only
legitimate inlining a
bytecode compiler can do is for static final
constants.
I doubt even that is safe, as
Chris Gray wrote:
Nonetheless, javac certainly used to do that, and I'm pretty sure it still
does. (I could swear that the JLS actually specifies this behaviour, but
I'm darned if I can find the words now.)
13.4.8
Hi Chris,
--- Chris Gray [EMAIL PROTECTED] wrote:
On Fri, 28 Feb 2003, Dalibor Topic wrote:
In my opinion, the safest place to do constant
inlining is in a class loader, when you know that
which specific implementation you're going to
'link'
to. Method inlining is possible during
On Fri, 28 Feb 2003, Artur Biesiadowski wrote:
Chris Gray wrote:
Nonetheless, javac certainly used to do that, and I'm pretty sure it still
does. (I could swear that the JLS actually specifies this behaviour, but
I'm darned if I can find the words now.)
13.4.8
On Fri, 28 Feb 2003, Chris Gray wrote:
Know the feeling. ; It's got me thinking too though - I might at least
instrument Wonka to find out what the size distribution of static methods
is. If there are a lot of one-liners or empty(!) methods then there may be
some low-hanging fruit to be
Hi,
I'm putting the finishing touches on a script to run mauve tests
against the CVS head of classpath Jikes RVM. We plan to run this as part
of our nightly regression tests. Is there interest in having these results
periodically (once a week? every day?) posted to the automauve
There are currently some workarounds in the tree to let us build
classpath with gcj. Some of these won't be necessary with gcj 3.3.
When should I remove them? I assume sometime after 3.3 is released --
but how long after?
Tom
___
Classpath mailing
Tom Tromey [EMAIL PROTECTED] writes:
There are currently some workarounds in the tree to let us build
classpath with gcj. Some of these won't be necessary with gcj 3.3.
When should I remove them? I assume sometime after 3.3 is released --
but how long after?
You could do it now, for it is
I want to throw out a couple random thoughts to stimulate discussion. I
see this as two separate issues:
1. What native methods ought to exist (it is different in CP and GCJ today)
2. How to implement those methods (JNI or CNI)
Like Tom, I'm skeptical of the machine translation of CNI to JNI
I think it makes sense to release Classpath 1.0 when AWT is complete and
we provide most of Java 1.1.
The important part is not the version number though, it's filling in the
missing pieces and debugging them.
It would be nice if someone could write a TODO for the AWT and GTK peers
code.
John
13 matches
Mail list logo
