Hi all,
Does any of you has the new email of Ben Burns? Hid old emails were:
- [EMAIL PROTECTED]
- [EMAIL PROTECTED]
Thanks,
Etienne
--
Etienne M. Gagnon, Ph.D.http://www.info2.uqam.ca/~egagnon/
SableVM: http://www.sablevm.org/
SableCC:
Here's the attached document...
Etienne Gagnon wrote:
The attached call for papers might interest some members of this mailing
list.
--
Etienne M. Gagnon, Ph.D.http://www.info2.uqam.ca/~egagnon/
SableVM: http://www.sablevm.org/
SableCC
Hi all,
The attached call for papers might interest some members of this mailing
list.
Etienne
--
Etienne M. Gagnon, Ph.D.http://www.info2.uqam.ca/~egagnon/
SableVM: http://www.sablevm.org/
SableCC:
Hi Dalibor,
You just managed to insult the SableVM team. Please stop this; it is
unworthy of a great project leader as you.
To all involved in this latest waste of bandwidth, please stop this
falmewaring. I am tired of all this.
As my team and me have been directly attacked, I have to answer
Hi Andrew,
Please don't restart the license talks! See below for some hint about
potential problems in one of the exceptions. For the rest, please
search the archives, or use the Classpath license Wiki.
Here's one problem with the license below:
- Are you allowed to modify the library and
Michael,
I disagree. I have evidence that the FSF considers our interpretation
to be correct; at least, Richard Stallman considered it to be correct a
few years ago. Our interpretation of the GNU GPL in the context of a
JVM is actually based on a long discussion I had with Richard Stallman a
Hi Michael,
Just for the record, SableVM is being worked on full-time actively by,
at least, 7 people which are students of mine (and I am not counting
myself there, as I work part-time on it). I would not consider this
inactive. :-)
Usually, they have little time for working on issues that are
Tom,
You are avoiding the discussion on the main issue: the missing reference
to SableVM in the release announcement. As far as I can see: GCC/GCJ,
Kaffe, JamVM, Jikes RVM, and Kissme are included, but not SableVM.
*If* the argument to not include SableVM is that a VM must run directly
using
Hi all,
Recent gtk peer code seems to have introduced a subtle bug, only visible
on VM's that verify that structured locking is properly done. I have
put a description of the bug in the bug tracker at:
http://savannah.gnu.org/bugs/index.php?func=detailitemitem_id=12301
There seems to be an easy
Here's what the JNI spec says about it:
MonitorExit
Prototype jint MonitorExit(JNIEnv *env, jobject obj);
...
Native code must not use MonitorExit to exit a monitor entered through
a synchronized method or a monitorenter Java virtual machine
instruction.
So, the current AWT code clearly does
Robert Lougher wrote:
Opinions?
How about specification instead? :-)
http://java.sun.com/docs/books/jni/html/design.html#10110
11.5.1 Organization of the JNIEnv Interface Pointer
...
Because the JNIEnv interface pointer is thread-local, native code must
not use the JNIEnv interface pointer
Mark Wielaard wrote:
If people have suggestions for the NEWS file please let me know.
I have suggestions of addition for the README:
In:
Complete development environments known to be based on GNU Classpath
include (recommended for end users):
Add:
* Debian's free-java-sdk
The developers of the SableVM Project are proud to announce the
official release of SableVM 1.1.6. SableVM is a liberally licensed
Free Java virtual machine. See the About SableVM section below for
more informations about SableVM.
Here is a list of the most important changes and new features.
The developers of the SableVM Project are proud to announce the
official release of SableVM 1.1.4. SableVM is a liberally licensed
Free Java Virtual Machine. See the About SableVM section below for
more informations about SableVM.
The most important changes and features of the 1.1.4 version
Mark Wielaard wrote:
Starting your review with This makes no
sense whatsoever and then not giving any suggestion what you would like
to see changed or how isn't helpful.
This is false. I did provide a clear indication of the solution. I cite
the relevant part of my message:
Begin -
This makes no sense whatsoever. File is NOT VM-specific in any way.
VM*.java should be reserved for the VM interface only.
Etienne
Michael Koch wrote:
Hi list,
I started to do some GNU classpath/VM separation work. I decided to
split the native methods of java.io.File into its own VM class
Download
http://sourceforge.net/project/showfiles.php?group_id=5523package_id=5567release_id=230647
Changes
===
- Cleaned up build process so that ./configure ; make ; make install
works out of the box for both sablevm-classpath (as it does for
sablevm).
Notes
=
To build
Jeroen Frijters wrote:
Indeed. The goal is to find the optimal solution that would be spec
compliant, portable and efficient. Since I obviously believe that my
proposal is better than the byte[] proposal, I would like to convice
Etienne (and you) of this. I fail to see how you can take issue with
Jeroen Frijters wrote:
Indeed. The goal is to find the optimal solution that would be spec
compliant, portable and efficient.
and later:
I'm not the one nitpicking about pure ISO C portability (I don't use
JNI, so I couldn't care less), ...
and later:
and is of thus ranks lower than my proposal on
On Wed, Apr 07, 2004 at 11:19:47AM +0100, Andrew Haley wrote:
jbyte must have a single platform-specific definition, as all
JVMs on that platform should be able to execute the same JNI
library code (no recompilation required).
I didn't know that. Is that requirement documented
On Wed, Apr 07, 2004 at 11:42:08AM +0100, Andrew Haley wrote:
Platform = Machine + OS. I don't have any reference, but I believe that
Etienne is right in saying that the same library should be usuable with
all JVMs on a specific platform.
But it's not necessarily possible. Clearly
Per Bothner wrote:
I can see on a few JVMs it may cause problems,
but they can easily sed the source to convert RawData to long.
Just think of RawData has a macro.
I am starting to have difficulty understanding Classpath's goals and
motivations.
When I proposed to add to Classpath some
Andrew Haley wrote:
Okay, but ANS specifically does not allow you to do this subtraction.
Also, there is no guarantee that every pointer is representable as a
ptrdiff_t. (6.5.6 Para 9, if you're interested)
The point is: if your platform is one that does *not* have 8-bit chars (!!!),
then you can
Michael Koch wrote:
Let me know what you think.
Makes sense to me.
Personally I think using obj or so is better then using thiz.
Agree. I like obj instead of this. [I don't like thiz]
Similarly, I like cls instead of class. [I don't like clazz]
Etienne
--
Etienne M. Gagnon, Ph.D.
Andrew Haley wrote:
Maybe, but that's not the only thing. It's possible to define jbyte
so that it is an 8 bit signed value but not a character type, and JNI
does not forbid this. I suspect that all the platforms we use define
jbyte to be a character type, but I can see no overpowering reason to
Andrew Haley wrote:
Yes, but it's not a question of whether the type jbyte is the same
size as a character type, but whether it is treated in the same way as
a character by the compiler.
Hi Andrew. Please look carefully at my proposal (sent minutes ago),
and tell me if it still contains
I Agree with Andrew, regarding the reference JNI library code; this code is
*NOT* the VM*.java interface, so it should be written to be compatible
with any JNI compliant JVM. As far as I know, disguising a native
pointer into a Java reference is not portable across JVMs.
IMO, the cleanest
Andrew,
Andrew Haley wrote:
- Everyone who can use a long as a pointer (and, in practice, this is
everyone) will do so.
It's *NOT* the VM interface! There is a single JNI source code source base,
used by everyone.
So, there is no SableVM does it this way, gcj that way, and Kaffe the other.
It
Andrew Haley wrote:
Well, not exactly: I'm suggesting that we wrap all those longs in an
opaque type. But otherwise, yes.
So, how do you do opaque types, in Java? And how do you guarantee portability
to 128bit systems?
Etienne
--
Etienne M. Gagnon, Ph.D.
Andrew Haley wrote:
Sure. Instead of putting a native pointer in a long or in a byte[],
you just declare a class with a single field that contains the
pointer. Everyone who needs a pointer makes a suitably named
subclass, so they'll know what they're pointing to.
How is that more efficient than
For one thing, you have not shown me *your* native part.
Second, see below.
Andrew Haley wrote:
JNIEXPORT void JNICALL
Java_somepackage_someNativeMethod
(JNIEnv *env, jobject this, jbyteArray nativePointer, ...)
{
void *ptr;
(*env)-GetByteArrayRegion(env, nativePointer,
I should have compiled with -pedantic, of course... I've included a few fixes
in the attachment.
malloc() returns a char*, not a jbyte*.
[#1] byte
addressable unit of data storage large enough to hold any
member of the basic character set of the execution
Etienne Gagnon wrote:
FYI: The JNI specification guarantees that jbyte is an 8-bit signed value.
Hmmm... Thinking about all this mess of non-specified C byte length...
Can JNI actually be implemented on a 16-bit per byte system?
Anybody has a reasonable answer?
To consider:
5.2.4.2.1
Tom Tromey wrote:
Etienne It would be so much easier if we had something like:
Etienne $ svn st
I don't know what this is.
If it is some kind of what is the status of my working tree? query,
I recommend the cvsutils (or is it cvs-utils? I recommend both...)
for this sort of thing. I probably
Archie Cobbs wrote:
Eeeh. I can't imagine that either. If there's a strong argument for
holding native pointer in a byte[] ?
Object is good because it is automatically the size of a pointer
on any platform. However, it has one significant disadvantage, which
is that you must special case all
Etienne Gagnon wrote:
vmData = new byte[PTR_SIZE];
or
vmData = new RawData();
or whatever.
So what's the problem, with this?
And for those who want to do:
vmData = [internalVMpointer]
They can deal with it in many ways, such as:
1- make sure [internalVMpointer] points to
a non-GC'ed
Mark Wielaard wrote:
I would like the vmdata field type then to be VMClass not Object.
I disagree, as it imposes a restriction on what vmData actually is.
The most obvious implementation of vmData is to be a byte[] instance
holding the byte of a native pointer to an internal VM non-moveable
data
Etienne Gagnon wrote:
The most obvious implementation of vmData is to be a byte[] instance
holding the byte of a native pointer to an internal VM non-moveable
bytes (of course)
Why byte[]? For transparent protability to 16, 32, 64, 128, etc. bit
processors
Just to be cristal clear:
I propose to declare vmData of type Object, so that a native implementation
can choose to creat an instance of *any* type to hold the VM-specific value.
Etienne
Etienne Gagnon wrote:
Etienne Gagnon wrote:
The most obvious implementation of vmData is to be a byte
Mark Wielaard wrote:
Unless running with --force the auto* tools shouldn't override these
files so normally you won't see any diffs when following the HACKING
instructions. But there is no particular reason. So please remove them.
Make sure to update the HACKING file and send a message to the list
Hi,
I have 2 questions:
1- Why is the -module option explicitly provided in the
lib*_la_LDFLAGS = xxx
line of */Makefile.am ?
2- Currently, classpath uses libtool kind of versioning for its JNI
libraries, yet, I do not understand why. I see no reason for any
C application to
Hi all,
As most people dislike the m4 approach without even having a look at it
(just remembering m4 as used in auto* stuff...), I will no push for this
further. I have no time for religious wars.
As for the --with-vm, it will for now be implemented as an optional
command-line argument. Not
Hi All.
I would like to suggest 2 things.
Build Process
=
Classpath is not meant to live on its own; it is either meant to be used
as a class library for a compiler (e.g. jikes), or as a class library for
a virtual machine (gcj, JikesRVM, SableVM, Kaffe, ...).
It would be
On Thu, Mar 25, 2004 at 09:48:58PM +0100, Jeroen Frijters wrote:
Etienne Gagnon wrote:
My vote is firmly against introducing macros. Unless it is done in such
a way that the resulting code is still valid Java code, so that
Classpath can still be compiled without running m4 or any of the build
http://people.redhat.com/~graydon/free-swing-mar-23-2004.png
OK SableVM guys! I'd like to see this in SableVM's staging tree *now*!
To get get SableVM staging to work out-of-the-box with
a Classpath CVS, using:
$ # [go to classpath working copy]
$ cd classpath
$ ./configure --with-vm=sablevm
/basic/BasicDefaults.java
lib/gen_nio.sh.in
native/jni/gtk-peer/gnu_java_awt_image_GdkPixbufDecoder.c
vm/reference/java/lang/Runtime.java
Etienne
Etienne Gagnon wrote:
Hi Mark,
While importing Classpath into sablevm-classpath, using the
classpath-0_08-release tag, I notice that you are resuscitating
Hi Mark,
While importing Classpath into sablevm-classpath, using the
classpath-0_08-release tag, I notice that you are resuscitating
some files such as ./configure.in. Why isn't this file left
into the Attic? Maybe it's just a tagging mistake.
A good test, for a tag, is to do:
cvs export -r
Mark Wielaard wrote:
Or does someone know the magic command to make it all right in the
repository?
cvs co classpath # no tags
works fine, and does not export the dead files. In other words, the
files *are* in the Attic; what you need to do is to get a clean working
copy with no dead files so
Hi Archie,
Sorry for the late answers. This was the last teaching week at UQAM, so I lacked time
to answer all my emails.
See below.
Archie Cobbs wrote:
Seems like this fix (really workaround) should be merged into
Classpath itself too, no?
Theoretically: I really dislike seeing com.sun
Hi Archie,
Archie Cobbs wrote:
I'm not a license freak so if LGPL doesn't work for somebody let me know.
This is really generous of you. Thanks a lot. I will be integrating this code
in SableVM in a few days. [I am experiencing end of term overload... ;-)]
Have fun!
Etienne
--
Etienne M.
Hi Mark,
Is there any ETA for CVS to be back up? It's already 2 days past the
announced ETA on savannah.gnu.org.
Etienne
--
Etienne M. Gagnon, Ph.D. http://www.info.uqam.ca/~egagnon/
SableVM: http://www.sablevm.org/
SableCC:
Hi there,
Usually, we have daily SVN (Subversion) snapshots and publicly accessible
Subversion repository:
See http://sablevm-shot.dyndns.org/ for snapshots and INSTALL.txt
But, the machine died yesterday, so *.tar.gz snapshots will be unavailable
for a very short while (a day or two). You you
I ought to re-read my messages berfore pressing send.
Mainly, what I meant, in my previous message, was that you can actually
get a staging copy of SableVM + Classpath 0.07 right *now*, by following
the stated instructions.
Usually, you could also get a pre-packages .tar.gz daily snapshot, but
Hi Dalibor,
I would drop h) altogether.
Rationale: while a naive Java compiler would produce a series of iload
instructions, for reusing a local variable, an optimizing compiler or a jit
would completely remove this. So, yes, the code that reuse a local could be
a little slower on a interpreter
Arnaud Vandyck wrote:
It also could be great to announce new releases from SableVM, gcj, kaffe
and classpath... all together ;)
That would be great! Is there any corporate sponsor, on this list, that would
like to finance the travel of one SableVM developer (gadek, belanger, or
myself) to attend
Dalibor Topic wrote:
e) use '+' to concatenate strings and objects
Rationale: Most Java compilers can optimize string concatenation by
using string buffers. There is no need to do that task by hand. Using
'+' allows you to write simpler code.
I partly disagree. When you iterate through a
David Bélanger wrote:
I think Etienne did these two changes, I'm not sure. Maybe Etienne
could answer your questions on these.
java_io_File.c: Basically, it frees a local ref, I guess otherwise it may
run out of local refs for a long directory listing.
(*env)-SetObjectArrayElement(env,
Mark Wielaard wrote:
I think that is in fact what Mark was suggesting and I think this is
definitely a good idea. There are a lot of VMs that don't (want to) use
JNI for their native methods. Having all native methods in the VM*
classes makes this much easier.
I was suggesting that. Sorry for
Stephen,
Do as you like. I do not want to fight on this. I think that my
proposal is the best approach to (1) handle missing functionality in a
way that will make life easier to users trying to run Java
applications on classpath-based free vms amd (2) mimick the
LinkageError usually expected in
Just a little note:
On Mon, Sep 29, 2003 at 02:32:49PM +1000, Stephen Crawley wrote:
I cannot see for the life of me where you are got this different
semantics idea from. The documentation for the exception defines its
semantics as:
The semantic difference comes from the inheritance
Hi all,
I personally think that a Java application should not try to discover
the JVM/library version through an akward usage of exceptions/errors.
If an application wants to adapt to some version of the above, it should
use System.getProperty() and test for a specific jvm/class-library
FYI: There are interesting standard system properties that could be
used for this:
java.specification.version 0.06
java.specification.vendor Gnu
java.specification.nameClasspath
;-)
Etienne
--
Etienne M. Gagnon, Ph.D. http://www.info.uqam.ca/~egagnon/
SableVM:
David Holmes wrote:
I'm not so sure this is about actual version information but more
about not yet implemented methods in a VM/library that purports to
support the version of the API that includes that method. Classpath is
in the unfortunate state of supporting different versions of API's
Stephen Crawley wrote:
If no user is allowed to catch this new error/exception, why are we going
to the bother of creating it in the first place??
So that, when a user runs his application on top of a Free jvm using
Classpath, he can identify clearly missing functionality (at run time,
at
Ingo Prötel wrote:
We can certainly do this. I also appreciate if an exception name already
describes the problem. But I also must caution against using too long
names. Especially for classes with inner classes. Such Classes result in
very long class-filenames. Some Systems have hard limits on
OK.
I will try to get some of my compiler course students to make a term
project, out of it. It should be fun for them, and they will get a wide
community of testers. ;-)
Etienne
Tom Tromey wrote:
Actually, there are a few problems with it. We'd like a blank line
before `package' (we can't
questions on the sablevm-developer mainling-list.
Etienne
Brian Jones wrote:
Etienne Gagnon [EMAIL PROTECTED] writes:
The only worry I have is that it is not obvious to me if all the
licenses of the various parts of jalopy are compatible.
Have a look at:
http://jalopy.sourceforge.net
Hi Mark,
You can find performance measurements SableVM compared to other free/non-free
JVMs running some real benchmarks (SPECjvm, Soot, SableCC) in my Ph.D. Thesis.
Look for the Chapter on performance measurements. More precisely, you might
be interested by Tables 9.1 and 9.2 on page 118.
68 matches
Mail list logo
