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 (enabled by default)
--enable-class-install
installs all cl
Hi list,
I just commited my big NIO patch. I doesnt contain yet anything from the
big pointer discussion. It is just a merge from libgcj. It reworks
java.io file operations to use java.nio.channels internally for
performance. I have done a full mauve run and found no new strange
failures with
Am Donnerstag, 8. April 2004 21:33 schrieb Thomas Zander:
> I'd really like to see my stuff committed, or commented on if just
> committing is unacceptable.
>
> Are there any people actually maintaining mauve? Nobody commented on
> the fixed needed for the website either.
> In short who is the cor
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I'd really like to see my stuff committed, or commented on if just
committing is unacceptable.
Are there any people actually maintaining mauve? Nobody commented on the
fixed needed for the website either.
In short who is the core maintainer for mau
Andrew Haley wrote:
> > Finally, "RawData as opaque
> > pointer" doesn't require any unwraping but does hit GC cycle time
> > severely as every object has to be check for being in this special
> > RawData class. So for JC byte[] is best.
>
> We get away with this in GCJ because a pointer outsi
Archie Cobbs wrote:
Okay, perhaps we need to agree what platforms we care about.
Here are my votes...
- We don't care about platforms that don't have 8 bit bytes or where
typeof(jchar) != signed char.
- We don't care about platforms where 'jlong' is insufficient to hold
VM private data. E.g.,
Archie Cobbs writes:
>
> Note: by this logic byte[] is the most portable/generic way to hold
> VM private data. It places no portability restrictions, only
> (possibly) performance ones. However, I have yet to hear a
> convincing argument that proves byte[] is slower than RawData (or
> whate
Etienne Gagnon <[EMAIL PROTECTED]> writes:
> Michael Koch wrote:
> > 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"]
thiz makes sense if you a
Andrew Haley wrote:
Strong typing for legibility and reliability is IMO for more
important.
I strongly agree with this, on software engineering grounds.
> And here it is with named opaque types:
>
> public static final synchronized native int
> g_signal_handlers_unblock_matched(gpointer instance,
Andrew Haley wrote:
> Perhaps we need to define what we're really aiming at.
>
> I would have thought:
>
> 1. Correctness (well-defined on the platforms we care about.)
> 2. Portability (to the platforms we care about.)
> 3. Maintainability/Readability of code.
> 4. Efficiency.
>
> Does anyo
Etienne Gagnon wrote:
the main motivation is for Classpath to use less portable
approaches when
they make CNI faster, as the performance of CNI and the other non-spec
compliant
interfaces is the main objective.
Jikes RVM uses JNI and is unlikely to ever implement CNI. There are
other classpath-
Etienne Gagnon writes:
> 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), ...
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Stephen Crawley wrote:
| Folks,
|
| I've just checked in a new version of the Mauve testcase for Unicode
| character handling. This fixes previous problems that resulted in
| huge numbers of test failures with the current version of Classpath.
| [It tu
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
Folks,
I've just checked in a new version of the Mauve testcase for Unicode
character handling. This fixes previous problems that resulted in
huge numbers of test failures with the current version of Classpath.
[It turns out that they were partly because the testcase used an old
Unicode table, b
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thursday 08 April 2004 15:24, Eric Blake wrote:
> Tom Tromey wrote:
> I also wonder if the following implementation would be more efficient.
> In the common case, StringBuffer/StringBuilder is used for appends, and
> then converted to a String jus
Tom Tromey wrote:
">" == Chr Ullenboom <[EMAIL PROTECTED]> writes:
From http://java.sun.com/j2se/1.5.0/jcp/beta1/index.html#java.lang:
"In this release, the sharing between String and StringBuffer has been
eliminated."
Does this mean to change to change the implementation in Classpath too? I
like
Etienne Gagnon writes:
>
> Now that my proposal has been criticised to death on the smallest
> nitpicks of pure ISO C portability, let me comment on the portability
> ]of your code.
>
>
> The ISO C standard says:
>
> [#6] Any pointer type may be converted to an integer type;
Jeroen Frijters writes:
>
> > > return env->NewObject(pclass, mid, p);
> >
> > ** Bzzzt *** Please try again...
> >
> > Now that my proposal has been criticised to death on the smallest
> > nitpicks of pure ISO C portability, let me comment on the portability
> > of your code.
That wa
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
Etienne Gagnon wrote:
> 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 f
Hi Arsene,
[EMAIL PROTECTED] wrote:
> hi,
> i'm a java developer, yet new to use classpath such
> project. currently i test how to use classpath to
> develop my project. however, after kaffe
> (/usr/local/kaffe) and classpath
> (/usr/local/classpath) installed, when compiling a
> simple HelloWorl
hi,
i'm a java developer, yet new to use classpath such
project. currently i test how to use classpath to
develop my project. however, after kaffe
(/usr/local/kaffe) and classpath
(/usr/local/classpath) installed, when compiling a
simple HelloWorld program, there's a dilemma occurred.
if i put cla
Etienne Gagnon wrote:
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 c
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thursday 08 April 2004 01:24, Artur Biesiadowski wrote:
> Tom Tromey wrote:
> >>>From http://java.sun.com/j2se/1.5.0/jcp/beta1/index.html#java.lang:
> >>>"In this release, the sharing between String and StringBuffer has
> >>> been eliminated."
> >>>
Grzegorz B. Prokopski wrote:
> On (07/04/04 13:47), Jeroen Frijters wrote:
> > Andrew Haley wrote:
> > > This seems to be identical to my proposal.
> > >
> > > I no longer understand what we're arguing about...
> >
> > I know. I thought we were still trying to convince Etienne :-)
>
> I thought
26 matches
Mail list logo
