On Sun, 24 Aug 2003, Mark Wielaard wrote:
- Up to date documentation that at a minimum provides a reference like
overview of what we have and what each class/method does. And clearly
describes what is work in progress/non-functional stubs.
(gjdoc really helps here. And our api doc isn't
On Sun, 22 Dec 2002, Artur Biesiadowski wrote:
I think that one of biggest problems is Graphics2D implementation. Doing
it all in java would require very major undertaking - I do not see a
chance of doing it by volunteers in any reasonable timeframe.
I actually have most of the Graphics2D
On 22 Dec 2002, Anthony Green wrote:
On Sun, 2002-12-22 at 04:23, Artur Biesiadowski wrote:
Do you think it is a good idea ?
It's a great idea. Here is some evidence:
http://www.cs.umd.edu/hcil/agile2d/index.shtml
Ah, we're talking about two different things. I have implemented the
On 27 Sep 2002, Nic Ferrier wrote:
(*) to java.io.* classes that I'm working.
fwiw, i've got some implementations/fixes to java.awt.geom.*
that i'm working on (as part of the Gerber tools mentioned on
http://www.cag.lcs.mit.edu/~cananian/Projects/FabClass/
). I'm following existing
On Thu, 26 Sep 2002, Dalibor Topic wrote:
If classpath uses different implementations of java
classes on different platforms the genuine
serialVersionUID for the different implementations
will obviously differ. I assume that Suns
serialVersionUID is the same on all platforms, though;
...the GNU classpath now works with the FLEX compiler,
http://flex-compiler.lcs.mit.edu
I just got 'Hello, world' working a few minutes ago. =)
The FLEX compiler bits are already very robust; now that the FLEX runtime
plays nicely with GNU classpath, I expect many other applications to work
On Tue, 10 Sep 2002, Daryl Lee wrote:
1. aclocal ran silently
[...]
3. automake produced:
configure.in:18: your implementation of AM_INIT_AUTOMAKE comes from an
configure.in:18: old Automake version. You should recreate aclocal.m4
configure.in:18: with aclocal and run automake
On 9 Sep 2002, John Leuner wrote:
Can I commit this to CVS?
yes, please!
--scott
Peking Serbian Dictionary radar Delta Force affinity group India kibo
jihad payment smuggle United Nations Secretary RNC AK-47 Rijndael
( http://cscott.net/ )
The VMObject.getClass() method should be removed, as it is not
VM-specific: it is implemented in terms of JNI calls (and gcj
has its own way of doing this in CNI). Furthermore, VMObject.getClass()
is never called anywhere in classpath, in particular not from
Object.getClass(). So I think
On 31 Jul 2002, Mark Wielaard wrote:
I am still interested in how/why those Strings had a non-zero offset in
the first place. Maybe a compiler/VM may do such a thing and then we
have to take that into account in Character and String when we use them.
The bytecode compiler cannot do this,
On Tue, 30 Jul 2002, R.S. Veldema wrote:
There are really a *kazillion* things not implemented/working yet in the
swing implementation.
Alas, awt needs to work properly also before debugging can truely start
on swing using all
and nothing but classpath.
However it's useful to note that
On Mon, 29 Jul 2002, Wu, Gansha wrote:
We have GNU Classpath submissions that make ORP/GNU Classpath run typical
commercial applications and workloads
[...]
The submission includes bug fixes, performance enhancement,
refactoring codes for
better maintenance, and some new
On 17 Jul 2002, John Leuner wrote:
The flex home page (and other pages) don't actually say that it's a java
source to native code compiler.
well, it had ambitions to be a java-to-hardware compiler at one point
(sadly unmaintained) and it could do bytecode-to-bytecode optimizations at
a
On 16 Jul 2002, John Leuner wrote:
After rewriting the class initializer code in kissme, I got to the
following stage with the TestAWT program:
http://people.debian.org/~jewel/kissme/shots/kissme_awt.png
Unfortunately nothing else works, but it's a big improvement (previously
a deadlock
On Sun, 24 Feb 2002, Eric Blake wrote:
Which is prefered, performing array bound checks throughout a method, or
enclosing the algorithm in a try-catch block which converts an
IndexOutOfBoundsException into a NumberFormatException?
For what it's worth: often adding explicit bounds checks will
On Mon, 25 Feb 2002, Eric Blake wrote:
C. Scott Ananian wrote:
For what it's worth: often adding explicit bounds checks will enable the
compiler to create faster code (by hoisting these checks, and others which
are implicit in the java semantics, out of the loop). I'm not sure
which
On Wed, 1 Aug 2001, Patrick Doyle wrote:
Does anyone have a hint as to how the inner class methods of
java.lang.Class (getDeclaringClass, getClasses, etc.) would be implemented
by a JVM? Don't they depend on how the Java compiler implements inner
classes? AFAIK the JVM isn't aware of inner
On Thu, 2 Aug 2001 [EMAIL PROTECTED] wrote:
Does anyone have a hint as to how the inner class methods of
java.lang.Class (getDeclaringClass, getClasses, etc.) would be implemented
by a JVM? Don't they depend on how the Java compiler implements inner
classes? AFAIK the JVM isn't aware
On Fri, 27 Jul 2001, Eric Blake wrote:
if (negative)
return -result;
return result;
}
you actually have to do this the other way 'round (maintain the number
negative as you build it, then negate it if the number was really
positive) because the negative range of the integer
On Thu, 26 Jul 2001, Artur Biesiadowski wrote:
Any feedback on this idea?
1) Think about internationalization of error messages.
that's a red herring. completely independent of eric's proposal.
2) I think that if statement adds some bytecodes. As you end up with path
for message
On 26 Jul 2001, Brian Jones wrote:
R.S. Veldema [EMAIL PROTECTED] writes:
Hi, more bugs, changed the LOADING, COMPLETE, etc
from private to protected inside java.awt.MediaEntry
since they we're accessed inside java.awt.ImageMediaEntry
Since ImageMediaEntry extends MediaEntry I
On 21 Jul 2001, Tom Tromey wrote:
and VMLoader on sane VMs being:
I assume you're characterizing libgcj as not-sane. I disagree with
this characterization.
sorry, that *was* a bit inflammatory. I meant something closer to, VMs
which will execute classpath as compiled to bytecode by
On 19 Jul 2001, Tom Tromey wrote:
-public static final Class TYPE = VMClassLoader.getPrimitiveClass(boolean);
+public static final Class TYPE = boolean.class;
With jikes, at least, this actually compiles to:
public static final Class TYPE = Boolean.TYPE;
which is probably not what
On Thu, 19 Jul 2001, C. Scott Ananian wrote:
On 19 Jul 2001, Tom Tromey wrote:
-public static final Class TYPE = VMClassLoader.getPrimitiveClass(boolean);
+public static final Class TYPE = boolean.class;
With jikes, at least, this actually compiles to:
public static final
On 19 Jul 2001, Tom Tromey wrote:
Mark == Mark Wielaard [EMAIL PROTECTED] writes:
Mark Would it not be simpler to add a VMClassLoader class to libgcj
Mark that implements the getPrimitiveClass() method?
I'd prefer not to, simply because the current implementation is more
efficient. It
On Thu, 19 Jul 2001, Jeff Sturm wrote:
(I know someone who once had a usable libgcj runtime in 28KB of memory.
I'll grant that that takes a lot of hacking anyway... he didn't even have
a String class in his runtime.)
okay, how about:
class Boolean {
Class TYPE = VMLoader.BooleanTYPE;
}
On Mon, 16 Jul 2001, Eric Blake wrote:
Someone will need to check my work with serialization issues, as I am not
very familiar with the process. Basically, my added hashCode() caching will
break if a deserialization restores the transient hashCode field to 0
instead of -1. I chose -1 for
On 12 Jul 2001, Tom Tromey wrote:
You can do a mostly-precise GC. In fact the GC in libgcj is mostly
precise. We only scan the stack conservatively. My understanding is
that on current 64-bit architectures, a conservative scan is pretty
unlikely to erroneously maintain much data.
On 12 Jul 2001, Tom Tromey wrote:
John == John Keiser [EMAIL PROTECTED] writes:
John 3. Slowness of Contribution: Argh. I was about to volunteer to
John write a page with the agreement. But *the FSF doesn't have it
John online anywhere*! Argh argh argh.
They did this on purpose. I
On Thu, 12 Jul 2001, Etienne M. Gagnon wrote:
I really think that a separate pure ANSI/ISO/POSIX C + JNI (OK... only
as pure as possible...) native tree should be maintained in Classpath.
GCJ programmers could contribute to a separate CNI tree (under the
condition that both trees are kept
On Thu, 12 Jul 2001, Aaron M. Renn wrote:
depending on an already existing Java library installation. There are
too many classes to simply pipe them all into the compiler on the
command line.
really? I've got 172,301 lines of java source (in 877 files) which I
compile by doing *exactly
Paul Russell [EMAIL PROTECTED] 13-Dec-00 3:44:22 PM
Are there any plans afoot to include JAVAX jars
into CLASSPATH? JAXP and XML.jar would
seem likely contenders?
Note also that the Apache project has XML parsers in Java:
http://xml.apache.org/xerces-j/
These are under Apache's
On Fri, 20 Oct 2000, Patrick Spingys wrote:
Now I have heard about the "Internet C++"-project
( http://www.xmission.com/~icvm/ )
On theire side stand, that this platformindependent code
runs a lot of faster than the Java-code on the JVM.
The 'Internet C++' project is not truely open source.
On 15 Aug 2000, Tom Tromey wrote:
I looked at this. Instead of checking in your fix, I elected to merge
the libgcj and Classpath implementations of this class. I largely
chose the libgcj implementation, as it is more efficient. In
particular the Classpath implementation resizes the buffer
I've just begun work on fitting Classpath together with the
FLEX j*va-to-native compiler infrastructure
(http://flex-compiler.lcs.mit.edu/Harpoon).
This is just a quick note to let the list know what I'm up to; I've gotten
only as far as autoconf/automake support for the new VM so far.
--s
35 matches
Mail list logo
