Re: FYI: RMIC
At 12 Oct 2001 16:20:04 -0600, Tom Tromey wrote: > I just checked in some code that lets the rmic program actually invoke > the Java compiler. It is based on the interface already exposed in > RMIC.java; I didn't read the kaffe implementation to write this one. > I also changed it a little bit. Someone may want to use java compiler for other purpose. Then the compiler interface should be moved to gnu.tools.javac or like so. And someone may want following method for Compiler.java: /** * compile some sources at once. */ public abstract void compile (String sources[]) throws Exception; /** * compile but output messages to specified stream. */ public abstract void compile (String sources[], OutputStream out) throws Exception; /** * set classpath */ public abstract void setClasspath(String path) throws Exception; regards. Takashi Okamoto ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Partial Double/Float merge with libgcj
> "Eric" == Eric Blake <[EMAIL PROTECTED]> writes:
Eric> However, I argue that this is a faster implementation (it avoids a
Eric> native call):
Eric>
Eric> public static boolean isNaN(double v)
Eric> {
Eric> return v != v;
Eric> }
This seems reasonable to me too.
Tom
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: Partial Double/Float merge with libgcj
Shoot, I meant to hit reply-to-all.
Eric Blake wrote:
>
> Chris Gray wrote:
> >
> >
> > An interesting twist on this: jikes seems to have its own idea of the correct
> > bit-pattern for NaN (0xffc0 instead of 0x7fc). This shouldn't matter
> > if all NaN's are canonicalized to the same value.
>
> Which version of jikes? My guess is version 1.13 or sooner, as floating
> point emulation mode was made default in later versions. When doing
> floating point emulation jikes should always spit out 0x7fc0 for
> Float.NaN, but with native math, it uses whatever the CPU thinks is NaN
> (which for x86 architecture is 0xffc0). But you are right, as long
> as Float.floatToLongBits canonicalizes NaN, there should be no problem
> with the current algorithm.
>
> However, I argue that this is a faster implementation (it avoids a
> native call):
>
> public static boolean isNaN(double v)
> {
> return v != v;
> }
>
> This works since NaN != NaN is the only reflexive inequality comparison
> which returns true.
--
This signature intentionally left boring.
Eric Blake [EMAIL PROTECTED]
BYU student, free software programmer
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: Partial Double/Float merge with libgcj
> "Chris" == Chris Gray <[EMAIL PROTECTED]> writes: Chris> An interesting twist on this: jikes seems to have its own idea Chris> of the correct bit-pattern for NaN (0xffc0 instead of Chris> 0x7fc). This shouldn't matter if all NaN's are Chris> canonicalized to the same value. My understanding is that floatToIntBits is required to return 0x7fc0 for any NaN, and that Float.NaN must be the same as Float.intBitsToFloat(0x7fc0). This doesn't necessarily imply that there is a Jikes bug though. It depends on exactly when Jikes uses that particular value. Float.floatToRawIntBits can return other NaN values, and presumably the VM could use them as well. For instace libgcj uses whatever the underlying hardware decides, and only does the canonicalization when the real bit pattern might be seen by Java. Tom ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Partial Double/Float merge with libgcj
Tom Tromey wrote:
> > "Mark" == Mark Wielaard <[EMAIL PROTECTED]> writes:
>
> Mark> Maybe someone who knows a bit about float/doubles in java can
> Mark> comment on these differences.
>
> I don't know if I qualify, but ...
>
I too am not worthy ...
>
> Mark>public static boolean isNaN (double v)
> Mark>{
> Mark> -return (doubleToLongBits (v) == 0x7ff8L);
> Mark> +long bits = doubleToLongBits (v);
> Mark> +long e = bits & 0x7ff0L;
> Mark> +long f = bits & 0x000fL;
> Mark> +
> Mark> +return e == 0x7ff0L && f != 0L;
> Mark>}
>
> I think this is a remnant of when libgcj's doubleToLongBits would
> return the actual raw value instead of turning all NaNs into a single
> value. Both implementations are correct, but the Classpath
> implementation is more desirable.
>
An interesting twist on this: jikes seems to have its own idea of the correct
bit-pattern for NaN (0xffc0 instead of 0x7fc). This shouldn't matter
if all NaN's are canonicalized to the same value.
Chris Gray
VM Architect, ACUNIA
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: Missing AWT peer
On Mon, 15 Oct 2001, Andreas Rueckert wrote: > It seems everything is there. But shouldn't the compile of the Gtk peer lib > fail anyway, if one of the libs is missing? Not necessarily. Any paths seen by ld (e.g. with -L) will not be automatically searched by the loader (assuming an ELF target). So each lib directory must be one of the "system" lib dirs or mentioned in LD_LIBRARY_PATH, unless you also link with -rpath. Jeff ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Missing AWT peer
Hi! On Mon, 15 Okt 2001 Jeff Sturm wrote: > Did you try: > > ldd /usr/local/OSS_JDK/classpath/lib/classpath/libgtkpeer.so > > Note that loadLibrary fails if a DSO is not found _or_ any of its > DT_NEEDED libs could not be loaded. The error message may be misleading > in the latter case. It seems everything is there. But shouldn't the compile of the Gtk peer lib fail anyway, if one of the libs is missing? Ciao, Andreas ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Missing AWT peer
On Mon, 15 Oct 2001, Andreas Rueckert wrote: > > Your error could also be because LD_LIBRARY_PATH > > (Solaris/Linux) did not point to a directory with libgtkpeer.so in it. > > Don't think so... Did you try: ldd /usr/local/OSS_JDK/classpath/lib/classpath/libgtkpeer.so Note that loadLibrary fails if a DSO is not found _or_ any of its DT_NEEDED libs could not be loaded. The error message may be misleading in the latter case. Jeff ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Missing AWT peer
Hi!
On Mon, 15 Okt 2001 Brian Jones wrote:
> No, there is a library that should be created during compilation
> called libgtkpeer.so. There is no System.loadLibrary("gtkpeer") in
> that class. Your error could also be because LD_LIBRARY_PATH
> (Solaris/Linux) did not point to a directory with libgtkpeer.so in it.
The only System.loadLibrary("gtkpeer") call I could find, is in
gnu/java/awt/peer/gtk/GtkToolkit.java
I also checked the gnu/java/awt/peer/gtk/TestAWT.java
file and it sets the toolkit with
===
public static void main(String args[])
{
if (args.length==0)
{
Properties prop = System.getProperties ();
prop.put ("awt.toolkit", "gnu.java.awt.peer.gtk.GtkToolkit");
}
MainWindow f = new MainWindow();
f.show();
}
===
This app fails with the same problems on my box.
Ciao,
Andreas
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: Missing AWT peer
Hi!
On Mon, 15 Okt 2001 Brian Jones wrote:
> Andreas Rueckert <[EMAIL PROTECTED]> writes:
>
> > > I don't see a System.loadLibrary in that class. This is a "maybe"
> > > problem in a number of the gtk classes. Obviously something is going
> > > to load it and the rest don't really need to do so but maybe putting
> > > this in all the relevant classes is just safer?
> >
> > Sorry, I'm not really into Classpath, so I'm a bit slow here. You think, that
> >
> > static native void gtkInit();
> > native void gtkMain();
> >
> > in gnu/java/awt/peer/gtk/GtkMainThread.java are the problem. These
> > methods are part of the Gtk library?
>
> No, there is a library that should be created during compilation
> called libgtkpeer.so. There is no System.loadLibrary("gtkpeer") in
> that class.
And you think it should be there? If you have to load the library, shouldn't
the call rather be done in GtkGenericPeer ? GtkMainThread extends that class.
> Your error could also be because LD_LIBRARY_PATH
> (Solaris/Linux) did not point to a directory with libgtkpeer.so in it.
Don't think so...
===
[andreas@hun andreas]$ /sbin/ldconfig -p | grep -i gtk
libobgtk.so.1 (libc6) => /usr/lib/libobgtk.so.1
libobgtk.so (libc6) => /usr/lib/libobgtk.so
libgtkxmhtml.so.1 (libc6) => /usr/lib/libgtkxmhtml.so.1
libgtkxmhtml.so (libc6) => /usr/lib/libgtkxmhtml.so
libgtkpeer.so.0 (libc6) =>
/usr/local/OSS_JDK/classpath/lib/classpath/libgtkpeer.so.0
libgtkpeer.so (libc6) =>
/usr/local/OSS_JDK/classpath/lib/classpath/libgtkpeer.so
libgtk.so.1 (libc6) => /usr/lib/libgtk.so.1
libgtk.so (libc6) => /usr/lib/libgtk.so
libgtk-1.2.so.0 (libc6) => /usr/lib/libgtk-1.2.so.0
libgnorbagtk.so.0 (libc6) => /usr/lib/libgnorbagtk.so.0
libgnorbagtk.so (libc6) => /usr/lib/libgnorbagtk.so
===
There's a FrameTest.java file in the testsuite. Does this test work for you?
> > BTW: At this time, there's no configure switch to compile Classpath
> > for ORP, so you have to use the japhar or jdk includes for jni? Will
> > you add a with-orp switch at some point or is there a good reason
> > not to do so?
>
> Going to try to take out the VM switches completely.
But you have to get the JNI stuff from somewhere and the Classpath tools dir is
of no use at all on my box.
Ciao,
Andreas
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: Missing AWT peer
Andreas Rueckert <[EMAIL PROTECTED]> writes:
> > I don't see a System.loadLibrary in that class. This is a "maybe"
> > problem in a number of the gtk classes. Obviously something is going
> > to load it and the rest don't really need to do so but maybe putting
> > this in all the relevant classes is just safer?
>
> Sorry, I'm not really into Classpath, so I'm a bit slow here. You think, that
>
> static native void gtkInit();
> native void gtkMain();
>
> in gnu/java/awt/peer/gtk/GtkMainThread.java are the problem. These
> methods are part of the Gtk library?
No, there is a library that should be created during compilation
called libgtkpeer.so. There is no System.loadLibrary("gtkpeer") in
that class. Your error could also be because LD_LIBRARY_PATH
(Solaris/Linux) did not point to a directory with libgtkpeer.so in it.
> BTW: At this time, there's no configure switch to compile Classpath
> for ORP, so you have to use the japhar or jdk includes for jni? Will
> you add a with-orp switch at some point or is there a good reason
> not to do so?
Going to try to take out the VM switches completely.
--
Brian Jones <[EMAIL PROTECTED]>
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: Missing AWT peer
Hi! On Mon, 15 Okt 2001 Brian Jones wrote: > > How can I get more info on the problem? The libgtkpeer is in the > > dynamic linker path, so that should work. > > I don't see a System.loadLibrary in that class. This is a "maybe" > problem in a number of the gtk classes. Obviously something is going > to load it and the rest don't really need to do so but maybe putting > this in all the relevant classes is just safer? Sorry, I'm not really into Classpath, so I'm a bit slow here. You think, that static native void gtkInit(); native void gtkMain(); in gnu/java/awt/peer/gtk/GtkMainThread.java are the problem. These methods are part of the Gtk library? BTW: At this time, there's no configure switch to compile Classpath for ORP, so you have to use the japhar or jdk includes for jni? Will you add a with-orp switch at some point or is there a good reason not to do so? Ciao, Andreas ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
