On Wed, 2005-06-22 at 10:48, Tom Tromey wrote:
Archit == Archit Shah [EMAIL PROTECTED] writes:
Archit A patch to replace the old RMIC implementation with the new ASM-based
Archit one attached. The patch file modifies configure.ac and Makefile.am to
Archit deal with asm.jar. The 2 java files
On Fri, 2005-03-18 at 01:56, Chris Pickett wrote:
C. Brian Jones wrote:
I still wear my Japhar Hungry Programmer t-shirt sometimes. Speaking
of which, we'll need a t-shirt for the 1.0 release. Anyone want to
design one? Is there a gcc 4.0 t-shirt?
I assume you mean Classpath 1.0
On Tue, 2005-02-15 at 15:25, Archit Shah wrote:
Thanks for the reply. I have a few questions below.
C. Brian Jones wrote:
If there is concern about the dependency on asm, I am open to
suggestions for an alternate bytecode generating facility. I understand
there is a gnu.bytecode in kawa
On Sat, 2005-02-05 at 14:48, Mark Wielaard wrote:
The current GNU Classpath documentation has been regenerated with this
version and can be found at: http://developer.classpath.org/doc/
(Note that by configuring --with-gjdoc you can do the same on your local
version of the GNU Classpath
On Mon, 2005-01-17 at 07:05, Michael Koch wrote:
Am Montag, 17. Januar 2005 07:45 schrieb jewel:
Welcome back, John.
Do all classpath VMs have native code to load jar files? Does it
make sense to distribute a jar instead?
The ones the don't have the code to load jars can install
So I'm poking around http://java.debian.net/ wiki and I have to say I
still don't understand what it is the upstream source provider should do
with reference to scripts and libraries and jars that would be
acceptable for everyone. It still seems like I have to pick a scheme,
with reference just
All,
If you have tried to send me email in the past week it is probably
lost. It appears I was bitten by a default mailbox size limit in
postfix of 50 MB that I didn't know about before. This should be
corrected now. Looks like I missed 20 or 30 emails on the classpath
list but the archives
On Tue, 2004-12-28 at 17:56, Thomas Zander wrote:
Since various Mauve users have said they wanted something like this anyway;
I went ahead and coded the jvm-parsing stuff already.
I read all source files, parse the minimum/maximum JVM 'Tags' from that file
and store it.
Then I have a new
On Wed, 2004-12-01 at 09:59, Dalibor Topic wrote:
Hi everyone,
after merging in libclasspath into Kaffe, primlib's missing LINK_*
functions broke static builds for riscos. I tried to figure out what
primlib does briefly, and gave up rather quickly as the files in
On Thu, 2004-11-25 at 14:52, Michael Koch wrote:
Am Donnerstag, 25. November 2004 19:35 schrieb Archie Cobbs:
Michael Koch wrote:
Assuming that this glibj.zip has the default Configuration.java
and that is acceptable to the builder, why not provide a way to
configure the build so you
On Mon, 2004-11-15 at 05:44, Dr. Torsten Rupp wrote:
Dear Mark,
(and I thought
we agreed to get rid of these kind of macros and would use normal
functions as much as possible in the future.)
When I remember right, the agreement was not to remove the macros
completely, but instead make
On Thu, 2004-11-11 at 14:17, Stuart Ballard wrote:
* A new bytecode reading implementation from Jeroen Frijters to
replace Jode. This vastly reduces the amount of code because it only
reads and understands the bits of metadata we actually need, where Jode
was part of a larger system
On Tue, 2004-11-02 at 15:06, Stuart Ballard wrote:
C. Brian Jones wrote:
Stuart, I've taken the serialization tests I once gave you to add to
japitools and added those to a module in Mauve called 'serialization'.
A new Mauve module seems like a good home for the japitools project to
me
On Fri, 2004-10-08 at 06:39, Mark Wielaard wrote:
The JCP also doesn't require the (final) specifications to be provided
under a click-wrap. As these JSR's show it it perfectly fine to publish
the specification, reference implementation and test compatability kit
in the public domain.
On Thu, 2004-09-30 at 11:56, Stuart Ballard wrote:
Michael Koch wrote:
Its possible again afaik. Another option would be to make it its own
CVS module in classpath or cp-tools.
I won't object if this is the consensus of others, but my own preference
is to keep japitools as a separate
On Sun, 2004-07-18 at 12:32, Roman Kennke wrote:
Am So, den 18.07.2004 schrieb Mark Wielaard um 16:36:
Hi Roman,
On Sun, 2004-07-18 at 00:23, Roman Kennke wrote:
http://ontographics.com/classpath/report-index.html
I still have to improve the script. When it is perfect, I will
On Mon, 2004-07-19 at 21:19, Dan wrote:
Hi,
Im using GNU Classpath (0.09) with JamVM on an embedded linux board.
I don't need the awt/swing classes (and a bunch of others) and thought I
would remove them from the build to same on space.
It's really simple, modify lib/standard.omit for the
On Fri, 2004-07-09 at 10:24, Archie Cobbs wrote:
Robert Schuster wrote:
What I want to say is: IMHO since Classpath already stepped into the 1.4
land it would not a good idea to primary support previous JDK versions.
Classpath had to rip classes, methods and signatures off to be
On Tue, 2004-07-06 at 06:04, Dalibor Topic wrote:
Ming Chen wrote:
Hi,
I have some problem to compile the CLASSPATH in Debian Linux/ Xscale, it
used up the memory (3G).
Let me guess ... jikes? Known bug in jikes. Avoid using it to compile
classpath on arm-linux. Use another compiler.
---BeginMessage---
Hi,
Your project draw my attention out. I would like to be part of it. I've checked some
tasks you needed people to be working on, but it seemed they may be out of date (some
should have been finished more than a year ago as it is written on the board). So I
was wondering
On Mon, 2004-05-10 at 12:46, Tom Tromey wrote:
Steven == Steven Augart [EMAIL PROTECTED] writes:
Steven So, for the purposes of GNU Classpath's AWT code
Steven (--portable-native-sync), is it reasonable to assume that they are,
Steven indeed, 1, 5, and 10, or should the implementation check
On Tue, 2004-05-11 at 20:41, Per Bothner wrote:
Steven Augart wrote:
Michael Koch wrote:
What if someone wants to port GNU classpath to an Operating System
with totally different semantics like Windows ?
If someone does that kind of port, he'll have more problems than just
than
On Fri, 2004-05-07 at 14:21, David P Grove wrote:
Here's some more data: dynamic count of JNI functions executed in 1
iteration of jack size 100 on classpath 0.08 and classpath 0.09 with
Jikes RVM. Note the massive number of calls from
FileChannelImpl.get_native_fd 2/3 of which are
On Mon, 2004-04-19 at 06:26, Dalibor Topic wrote:
Dalibor Topic wrote:
Dalibor Topic wrote:
Howdy,
I ocassionally try out classpath's configury mechanism, and it always
breaks down on me, so I must be doing something really 'special' to it.
I've tried the autogen.sh script
On Thu, 2004-04-08 at 16:36, Michael Koch wrote:
Hi all,
With my big NIO commit I accidently commited the first part (the parts
in configure.ac) for this patch and so I decided to commit it fully.
We now have two options for installing our classes
--enable-glibj
installs glibj.zip
On Tue, 2004-04-06 at 17:56, Archie Cobbs wrote:
Steven Augart wrote:
How about including all the build options in the Configuration class?
public class Configuration {
public static final String BUILD_OPTIONS = {
--enable-jni, --enable-load-library, ...
};
On Mon, 2004-03-29 at 01:35, Michael Koch wrote:
Am Sonntag, 28. März 2004 21:29 schrieb Etienne Gagnon:
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
On Thu, 2004-03-25 at 13:53, Tom Tromey wrote:
Etienne == Etienne Gagnon [EMAIL PROTECTED] writes:
Etienne [talking of normal package tree: would anybody object to moving the
Etienne whole tree to an src/ subdirectory, as it should be done in such
Etienne a big project?]
Personally
On Sun, 2004-03-14 at 07:12, Sascha Brawer wrote:
(b): As a client-side API, any JDI implementation should run on all VMs.
A free application that depends on JDI is JSwat, a GPL-ed graphical
debugger. Right now, there are also other things missing from Classpath
that would prevent JSwat from
On Sat, 2004-03-13 at 13:28, Mark Wielaard wrote:
Hi, Etienne,
On Sat, 2004-03-13 at 18:08, Etienne Gagnon wrote:
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
On Sun, 2004-03-07 at 19:00, Mark Wielaard wrote:
Hi all,
I finally imported gnu.regexp and added java.util.regex wrappers for it.
At the moment our gnu.regexp is the same as the original gnu.regexp
version, except for a few files and added copyright notices.
Maybe I should have mentioned
On Fri, 2004-03-05 at 04:35, Jens Lehmann wrote:
Chris Gray wrote:
This is bizarre. IBM already has an open source version of Java (JikesVM),
but perhaps Rod Smith is not aware of that.
The question is, if IBM is allowed to open source their Java
implementation.
Their
On Wed, 2004-02-18 at 05:12, Robert Lougher wrote:
Hi,
A quite interesting response. However, it's funny hearing Phipps slam IBM
so much (considering their Linux technology center and support of Jikes).
He used to be IBM's Java evangelist (based in Hursley, UK) before defecting
to Sun.
All,
I've been working a little lately on some tools I once added to japi for
serialization compatibility testing. I'm pretty close to having
something useful, just wondering if anyone is interested in using these
for checking compatibility? Here's the list of the files that are the
same when
On Fri, 2004-01-09 at 03:45, Sascha Brawer wrote:
Tom Tromey [EMAIL PROTECTED] wrote on Thu, 8 Jan 2004 17:48:59 -0700:
[standard pluggable JIT interface]
This would indeed be quite nice, IMHO.
Language choice for API.
The obvious choices being:
C lowest common denominator
On Sun, 2004-01-04 at 18:15, David Holmes wrote:
Mark,
My only comment is that a stated goal of at least as complete as 1.1
is no longer adequate. The Java platform is a moving target and 1.5 is
on the horizon. I recognise that there are too many packages to make a
blanket statement of
36 matches
Mail list logo
