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:
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: http://w
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.o
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 li
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 answe
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
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
few
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 Class
Hi all,
As usual, Mark has forgotten to include SableVM in the list of runtimes
that use GNU Classpath. It is understandable, I guess, as he does not
use SableVM for development, and he is not willing to accept our patches
without copyright assignment. Nonetheless, SableVM does use GNU
Classpath
Hi all,
As usual, Mark has forgotten to include SableVM in the list of runtimes
that use GNU Classpath. It is understandable, I guess, as he does not
use SableVM for development, and he is not willing to accept our patches
without copyright assignment. Nonetheless, SableVM does use GNU
Classpath
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
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=detailitem&item_id=12301
There seems to be an easy f
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 b
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
(http://
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 inc
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
Dalibor Topic wrote:
I'm not sure what the precise naming semantics are, maybe it would make
sense to have interface that must be implemented by a VM into VM*
classes, and classes that can be implemented natively in a different
fashion in their own Platform* or Native* namespace. I'd prefer Nati
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 ca
Download
http://sourceforge.net/project/showfiles.php?group_id=5523&package_id=5567&release_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 S
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
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
t
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:
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
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 som
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. Clea
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 documente
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 non-portab
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
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:
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
e
Andrew Haley wrote:
malloc() returns a char*, not a jbyte*.
So, can you tell me the difference between a jbyte and a "signed char"?
Sigh. No it isn't, and this code will break with gcc.
OK, maybe I am tired and I don't see it. GCC -Wall does not complain
about the attached example.
... Also, "w
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, nativePoi
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 a
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. http://www.info.uqam.ca/~egag
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
Jeroen,
Jeroen Frijters wrote:
>>IMO, the cleanest approach is really the use of a byte array.
>
> But it is inefficient and hard to optimize. I don't see why RawData
> doesn't give you the same capabilities as a byte array (as an extreme
> example, you can replace Classpath's RawData with your ow
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 approac
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
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-
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 such
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 dyna
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
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
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
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 st
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 prov
Why are the following files in CVS?
config.guess
config.sub
ltmain.sh
If there is no particular reason, I'd like to remove them from
CVS, as runnnig auto* tools causes spurious diffs in these files.
Etienne
--
Etienne M. Gagnon, Ph.D. http://www.info.uqam.ca/~egagnon/
SableVM:
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 o
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 impractical
> 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
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 t
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 t
/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 th
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. Gagn
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" any
Hi Archie,
I would be interested in using your code if it was licensed under the
less restrictive LGPL. Some people even suggested that it would be
very nice of you if you could put this code in the public domain, so
that any jvm, regardless of license, would be able to use it...
Are you up to ma
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:
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 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
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 F
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 interprete
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 co
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, fil
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 n
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 hier
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
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 least).
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
dependin
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:
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
versio
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 u
Of course, we should keep around a copy of Jalopy's current CVS, in case
it becomes proprietary. But, as far as I know, SourceForge should
only be hosting non-proprietary versions, anyway.
Etienne
Etienne Gagnon wrote:
Hi Brian & all,
So, given that there seem to be no licensing pr
with
it, do not hesitate to ask 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 loo
Hi Tom & Brian,
Jalopy seems to fill the needs, on the technical side. We could take
the latest Free snapshot available before it becomes proprietary to
indent the code.
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
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.
http:/
77 matches
Mail list logo
