> As I myself am working on two separate sets of AWT peer implementations
> (framebuffer and peered Qt/Embedded), I'd really appreciate it if we
> could treat such peer implementations as self-contained jar extensions
> with their build separate from kaffe's.
Cool. Where do you have the code so I
Hi James,
As I myself am working on two separate sets of AWT peer implementations
(framebuffer and peered Qt/Embedded), I'd really appreciate it if we
could treat such peer implementations as self-contained jar extensions
with their build separate from kaffe's.
Stephane
-Original Message
Hi folks!!!
Currently for kaffe all AWT targets use the exact same Java class
files. Only the native C code varies. Now in a peer design each target
would have its own set of classes. How will we approach this for setting
up the build system?
_
On Sat, 16 Aug 2003 08:50:07 -0700
"Jim Pick" <[EMAIL PROTECTED]> wrote:
> I've added some matching code / sanity checks to the script, so hopefully
> it will send the right patch for the commit now.
And, I just added some code to truncate the subject line of the email to
80 characters. :-)
Che
PatchSet 3961
Date: 2003/08/18 17:40:27
Author: dalibor
Branch: HEAD
Tag: (none)
Log:
Merged in RMI from GNU Classpath, replacing kaffe's old implementation. I've left out
the RMISecurityManager for now, as it prevents native libraries needed for java.net
from loading. I've changed classpath's
On Friday, August 8, 2003, at 10:22 AM, Timothy Stack wrote:but not
CSTATE_LINKED. The subclass would load the superclass using this
special
getClass(), set its own state to CSTATE_LOADED_SUPER (and NMS_LOADING)
and process the superclass to CSTATE_LINKED afterwards. That way, the
verifier would b
