Java OpenGL bindings

1998-08-11 Thread Bernd Kreimeier
The ARB has set up a group working on official OpenGL bindings proposal for Java. See www.opengl.org news page. There is also a announcement of a VRML browser source written in Java, from the same coder in Graz who wrote VRWeb and contributed a lot to Hyper-G. http://www2.iicm.edu/vrwave

RE: java.lang checkin ...

1998-08-15 Thread Bernd Kreimeier
John Keiser writes: > It is literally impossible for all of our classes to work with Sun's > JDK *unless* we make our implementation identical, mimicking private and > package-protected methods and behavior, even down to the point of making > sure declare private class fields in the same

jnilink uselessness

1998-08-09 Thread Bernd Kreimeier
John Keiser writes: > JNILINK is useless. Use it no longer. Well, I do not feel so bad know that I did not have the time (yet) to get into it... b.

RE: native libs

1998-11-10 Thread Bernd Kreimeier
> > I'd install the libraries in the JVM specific "lib" directory. Kaffe 1.0b1 use of the JDK 1.2 Invocation API: vm_args.librarypath = "/opt/local/share/kaffe/lib/i386-linux/"; I take it that this is (an example of) the directory referred to above?

Re: native libs

1998-11-12 Thread Bernd Kreimeier
Christoph Toshok writes: > > > Kaffe 1.0b1 use of the JDK 1.2 Invocation API: > > > vm_args.librarypath = "/opt/local/share/kaffe/lib/i386-linux/"; > this isn't the 1.2 invocation API. it's a non-standard extension to the > 1.1 invocation API. They named the struct JavaVMInitArgs, not JDK

nifty web site!

1998-11-12 Thread Bernd Kreimeier
Brian Jones writes: > Aaron, you may be interestd in DOC++. If that's http://www.zib.de/Visual/software/doc++/index.html that has not been updated in years last time I looked. It has quite a few bugs, and is not compatible between the HTML and LaTeX backends - you have to take a decision. I was

DOC++/nifty web site!

1998-11-13 Thread Bernd Kreimeier
Bernd Kreimeier writes: > http://www.zib.de/Visual/software/doc++/index.html > that has not been updated in years last time I looked. Checked today, gotta correct myself. It has been updated recently - ChangeLog lists: Fri Jun 31 1998 Tue Feb 3 1997 Mon Dec 23 1996 Sources (Sep 15

RE: Yikes - it's opensauce

1998-12-09 Thread Bernd Kreimeier
John Keiser writes: > What we're left with is this: the original *program* is freely > redistributable, but a *derivative work* is freely redistributable > under two conditions: it must contain 60% or more of the original > code, and it must be a JDK 1.1 compiler. There are days when I think

Re: Fwd: Possible fix for JDK 1.1.7 JNI problems

1998-12-13 Thread Bernd Kreimeier
Moses DeJong writes: > Does anyone know what JNI problem this fixes? Yeah, well. Brian forwarded my message, which says: > problems with JNI/Invocation with JDK 1.1.7v1a+native > for apps that use libdl.so, Invocation does not work in certain patterns. The script comment lists those: > # T

Re: new volunteer

1999-02-08 Thread Bernd Kreimeier
Paul Fisher writes: > > Have you looked at DOC++ as a JavaDoc replacement? Does it measure up? > For some reason, I guess the last time I looked at it, it didn't > support JavaDoc, but it appears to now. The bad news is that it's > non-free software. The authors make a contradictory stateme

OpenGL based AWT?

1999-03-13 Thread Bernd Kreimeier
Paul Fisher writes: > Kimberley Burchett <[EMAIL PROTECTED]> writes: > > - What is the point of the peer architecture? > It's easier to port that way. The peers provide the native layer, and > the non-peers provide the Java layer. > Our peers are a drop in replacement for Sun's Motif peers

Re: Doc comments

1999-02-13 Thread Bernd Kreimeier
Aaron M. Renn writes: > Per usual I was thinking > of something more ambitious. To the best of my knowledge there is no > standard parsing API. I was thinking that there should be a "parselet" API > for applications that need to parse Java source files (JavaDeps, JavaDoc, > etc). This is a

SOT: C to Java converter?

1999-02-14 Thread Bernd Kreimeier
I am looking for a Linux tool to generate Java source from C. I am aware of C2J/C2J++. What I need would have to be used repeatedly - the code will be maintained in C. Changing the C code once to match converters restrictions is feasible. Short of hacking C2J++ - any recommendations?

Re: SOT: C to Java converter?

1999-02-16 Thread Bernd Kreimeier
Michael Emmel writes: > > > I am looking for a Linux tool to generate Java source > > > from C. I am aware of C2J/C2J++. > > It's not possible. > > Don't even think port C program to java > > without complete redesign of basic programs > > structures and data. > > simple translating of even

Java/C

1999-02-18 Thread Bernd Kreimeier
Daniel Rall writes: > This is for whoever was asking about a Java/C gadget. > http://www.irisa.fr/compose/harissa/ Nah, this is Java to C. What I want is a stock dumb tool that automatically creates an ugly Java source from a C source. The idea is to map all C functions to static methods of a

Re: 3D API's

1999-03-13 Thread Bernd Kreimeier
Paul Fisher writes: > > whether anyone is working on the 2D and 3D API support? > > I don't believe that anyone is working on 3D support. I've become > familiar with the 2D API, and if no one else tackles it before I get > to it, I'll begin work after the 1.1 AWT is complete. (which will be

Re: 3D API's

1999-03-15 Thread Bernd Kreimeier
Godmar Back writes: > > Magician is a Java OpenGL API including implementations > > for Linux, Win32, Mac and other OS, supporting JNI, > > RNI, and Netscape's JRI. In contrast to Java3D, this > > is a portable, popular, efficient solution. > >From this perspective, I think that a Java bind

gnu.*/RE: HP Contributes to Mauve Project

1999-03-20 Thread Bernd Kreimeier
I gave Mauve a quick try (with a test harness for my own stuff in mind). Comments: 1. It's GPL'ed, which makes it impossible to apply to non-GPL'ed Java software. To my understanding, any Java tool or utility that loads a class performs linking. If GPL'ed, I violate the license loading a non

Java OpenGL bindings

1999-03-23 Thread Bernd Kreimeier
Edward Ribeiro writes: > Where we can get information about Java OpenGL bindings? In theory, www.opengl.org would be The Place. In practice, I can't remember something there short of the occasional archived news. www.arcana.co.uk keeps HTML mailing list archives of the ARB/JavaGL discussion list

[OT] C++Doc

1999-03-27 Thread Bernd Kreimeier
John Keiser writes: > I remember a while back someone knew > of a good javadoc-like tool for C++. doc++? Used to be: http://www.zib.de/Visual/software/doc++/ It is not a *good* javadoc like tool IMO. It is a javadoc like tool, you can restrict yourself to javadoc compatible tags or use incomp

RE: Javadoc replacement

1999-03-27 Thread Bernd Kreimeier
John Keiser writes: > I am curious: just how tied to Java is this, besides being written in it? > What kind of work would it take to make it work with something like C/C++? > A generic system that could generate doc-comments and do cross-linking and > todo lists would be a very useful thing fo

Re: Free Swing?

1999-03-29 Thread Bernd Kreimeier
Paul Fisher writes: > > Is there a free implementation of Swing avalible > > The GNU Classpath project http://www.classpath.org> has started > work on a free implementation of Swing; however, it will be some time > before it's completed. Is this using your AWT? I gather from Kaffe's source

Float.intBitsToFloat detail

1999-04-19 Thread Bernd Kreimeier
While doing something OpenGL related (interleaved float/int arrays) I stumbled over a detail of the native float Float.intBitsToFloat(int) implementation: that all IEEE 754 NaN values (2^23) are mapped to Float.NaN. Might be worth a Mauve check? A native method jfloat Java_jni_Native_i

Re: Project Mauve: A Free Java Regression Test and Compatibility Package

1998-12-04 Thread Bernd Kreimeier
Tom Tromey writes: > I believe we currently require GNU make, sh, a Java runtime, and a > Java compiler. It would probably be possible to get rid of the GNU > make dependency. I'm not particularly motivated to do it. There is a JavaMake ( and a JavaDepend http://www.cs.mcgill.ca/~stever/sof

Open Source JVM/core classes vs. trust

1998-12-17 Thread Bernd Kreimeier
SOT, but you have prolly solved this already... How do you prevent somebody taking a (L)GPL'ed or Open source for a JVM and/or core classes, hacking backdoors and trojan horses into it, and deploying it? To be more precise: sure it'll be either obvious (source is there) or illegal (violation of

RE: multi-VMs (was re: native_state troubles)

1998-08-25 Thread Bernd Kreimeier
John Keiser writes: > When you get around to dealing with multiple VMs--I know you have a lot > on your plate right now--I suggest you allow a configure option: --single-vm > or --multi-vm. Second that. Actually, I came to think of Japhar more as a (potential) toolkit to built and tailor

RE: jnilink enhancements

1998-07-28 Thread Bernd Kreimeier
John Keiser writes: > In short, yes, once I put the LGPL copyright notice in there (which I > haven't yet) it is usable for anyone. I'll send you a copy tonight or > tomorrow once I slap those headers on. I don't think anonymous CVS access > is set up yet, unfortunately :( Appreciated.

RE: 1.1 vs. 1.2 revisited

1998-08-07 Thread Bernd Kreimeier
John Keiser writes: > The problem with the public static final boolean variable > is, you have to edit the source every time you want to change it. Different classpaths, different Config.java first? Yeah, well - last time I tried, javac seemed to screw up dependencies to different package

Re: jnilink enhancements

1998-07-26 Thread Bernd Kreimeier
Maxim Kizub writes: > Just a few notes about class collecting and re-loading. I could add something else here. I tried to make my C++ classes for JVM/JClass/JObject fit for use with multiple JVM's from the same C application. As none of the field/methodID information etc. is supposed to be inva

Re: 1.1 vs. 1.2 revisited

1998-08-11 Thread Bernd Kreimeier
Wes Biggs writes: > I think explicit imports help readability anyway Agreed. > of the classes to check). The utility would look for "import x.y.z", > check if the file x/y/z.java exists, and if so insert a make dependency > line for x/y/z.class accordingly. Taking the current classpath int

1.1 vs. 1.2 revisited

1998-08-04 Thread Bernd Kreimeier
John Keiser writes: > I have one use for conditional compilation of Java classes that I would > like to employ. I do a lot of sanity checking in the JavaBeans classes, and > that code is rather bulky. -DNO_SANITY_CHECKS would be kinda nice. > There must be some macro preprocessor o

jnilink enhancements

1998-07-26 Thread Bernd Kreimeier
John Keiser writes: > I've been doing some heavy thinking about jnilink. I must be missing something here. What exactly is jnilink? Specific to Classpath, used internally to implement the native parts? > LINK_LinkClass(env,theClass,"java/lang/Integer"); > LINK_LinkMethod(env,theMethod,intCla

Re: multi-VMs (was re: native_state troubles)

1998-08-21 Thread Bernd Kreimeier
[EMAIL PROTECTED] writes: > > > if (is_not_cached_for_current_vm(jID)) > > > update_jfieldID(jID); > > > > > Hmm, now that is an interesting and very good idea. Have to bring it up > > with Japhar. Would bring them up to spec and make legacy code compatible > > with multiple VMs ... >

Javadoc proposal comments

1998-07-21 Thread Bernd Kreimeier
I do not think that adding tags is the right thing to do, ultimately. I have to dig out some weave/tangle references with respect to SGML, but for the moment just for SGML: www.sgmltools.org What I think is that, within the /** javadoc */ pieces, SGML should be used instead of HTML. The most con

Re: multi-VMs (was re: native_state troubles)

1998-08-21 Thread Bernd Kreimeier
Paul Fisher writes: > > which values does the JNI spec say can be cached? > jfieldID's and jmethodID's. See page 17 of the JNI spec. "Accessing > Fields and Methods". As long as you keep a live reference to the > underlying class, the VM ensures that your jfieldIDs and jmethodIDs > are val

Re: Is it possible to port to GCJ ?

1999-12-07 Thread Bernd Kreimeier
> Thomas Kuhn wrote: > Well, do you think it is possible to port those Parts from JNI to CNI > and to extract the AWT-Parts from the package Mid term and long term, adding JNI support to gcj would be the better idea IMO. Cygnus seems to consider likely that you can get away with defines and macro

Re: CNI vs JNI [Was: [per@bothner.com: Status of Free Java Environment?]]

1999-12-17 Thread Bernd Kreimeier
Stuart Ballard wrote: > > One of the goals of the Classpath project is to remain VM-neutral. > > Using JNI supports this goal. Doesn't this settle the issue then? > Or, we could implement one in terms of the other, or implement an > abstraction layer over the top that allowed C code to use whic

Re: Working from javadoc; J2EE

1999-12-20 Thread Bernd Kreimeier
Mark Wielaard wrote: > When you have not agreed to a license/contract the publisher can not > force you to do or don't do anything with the information. You can > use the ideas for everything you want as long as you don't violate > the copyright by directly copying large portions and distributing

Re: Working from javadoc; J2EE

1999-12-20 Thread Bernd Kreimeier
Paul Fisher wrote: > > Sun is taking the stance that copyright on specifications prohibits > > implementation of these specifications w/o a license. > > Sun does indeed take this bogus stance. We choose to ignore it. > Sun interprets copyright law far too broadly. Interesting. I don't know whet

Re: Announcement: libgcj and GNU Classpath merge

1999-12-20 Thread Bernd Kreimeier
Paul Fisher wrote: > /* As a special exception, if you link this library with other files > to produce an executable, this library does not by itself cause > the resulting executable to be covered by the GNU General Public > License. This exception does not however invalidate any oth

Re: Announcement: libgcj and GNU Classpath merge

1999-12-21 Thread Bernd Kreimeier
Stuart Ballard wrote: > This sounds like a good plan... I never heard of a GNU/Linux system that > didn't include Perl, but certainly some other unixes don't. One of the implications of Java for free software is that it could eventually make large inroads into Win32/other non-UNIX. Vice versa, Ja

Re: Proposal for CNI/JNI problems

2000-01-15 Thread Bernd Kreimeier
Per Bothner writes: > You need to analyze CNI (i.e. C++) source code. You need to recognize > CNI field and method references, which are just C++ field/method > references. That implies a semantic analysis of the C++ code. Yep. > The logical tool is a compiler. The only C++ compiler we ha

Re: Proposal for CNI/JNI problems

2000-01-15 Thread Bernd Kreimeier
Per Bothner writes: > > Is a modification of gcjh a good way to simplify the task for > > the parser/converter? I.e. marking Java-turned-C++ classes, > > enforcing naming schemes/prefixes etc.? > > I don't see how it helps. The problem is analyzing the user's C++ > native code. If you c

CNI to JNI ABI compilation?

2000-05-22 Thread Bernd Kreimeier
I (ever so briefly) looked at the GCJ FAQ and pages trying to find out whether compilation of CNI code to JNI compliant DLL's is possible, and/or on the agenda of the GCJ project. Any comments appreciated, thanks. b.