The actual problem here was that the scalinestride gets modified when setDataSamples is called. But
scanlinestride is a field of this class that gets used in other methods too. So it happend to me
that I did set data elements for the whole model (therfore it was optimized and touched the showen
Archie Cobbs wrote:
C. Brian Jones wrote:
thought folks wanted to not abuse it too much. Another
option perhaps
even in addition to is to simply add these to standard classpath
specific system properties at startup for use via
System.getProperty()?
That's a good idea... and a more
Etienne Gagnon writes:
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),
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 documented anywhere? I can't
see how you'd do it on a
Jeroen Frijters writes:
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 documented anywhere? I
Etienne Gagnon writes:
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,
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 :-)
Regards,
Jeroen
___
Classpath mailing list
[EMAIL PROTECTED]
So,
I
have to admit that I haven't been following this thread in all of its glory
:-), but the JNI spec is quite clear on the sizes of the various primitives.
See the table in section 12.1.1 of the spec. A jbyte is signed
8 bit quantity. A jchar is an unsigned 16 bit quantity, etc. There
are
Who has this photo? Can we put it on the web?
Thanks,
Andrew.
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Jeroen Frijters writes:
Andrew Haley wrote:
Who has this photo? Can we put it on the web?
http://adorphuye.com/gallery/FOSDEM2004/IMGP0234?full=1
Cool, thanks!
Andrew.
___
Classpath mailing list
[EMAIL PROTECTED]
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 documented
Hi Andrew!
On Wed, Apr 07, 2004 at 12:55:48PM +0100, Andrew Haley wrote:
Who has this photo? Can we put it on the web?
Thanks,
Andrew.
I have it up on my gallery at the moment - I believe Jim Pick also has a
version. Feel free to put it up elsewhere if needed :)
direct link to the image
S. Meslin-Weber writes:
Hi Andrew!
On Wed, Apr 07, 2004 at 12:55:48PM +0100, Andrew Haley wrote:
Who has this photo? Can we put it on the web?
Thanks,
Andrew.
I have it up on my gallery at the moment - I believe Jim Pick also has a
version. Feel free to put it up
Andrew Haley wrote:
Who has this photo? Can we put it on the web?
http://adorphuye.com/gallery/FOSDEM2004/IMGP0234?full=1
Regards,
Jeroen
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Jeroen Frijters wrote:
That's why I'm very much in favor of using RawData. ...
public abstract class RawData {}
public final class RawData32 extends RawData
{
private int pointer;
}
public final class RawData64 extends RawData
{
private long pointer;
}
All the Java code would ever see are
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. Clearly
Per Bothner wrote:
Jeroen Frijters wrote:
That's why I'm very much in favor of using RawData. ...
public abstract class RawData {}
public final class RawData32 extends RawData
{
private int pointer;
}
public final class RawData64 extends RawData
{
private long
Etienne Gagnon writes:
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
Per Bothner writes:
Jeroen Frijters wrote:
That's why I'm very much in favor of using RawData. ...
public abstract class RawData {}
public final class RawData32 extends RawData
{
private int pointer;
}
public final class RawData64 extends RawData
{
Hi,
I would like to suggest removing all C++ keywords as names in the native implementations of GNU
Classpath. We have a customer who insists on using C++ because of the more thorough code inspection.
To be able to compile with such a compiler we need to change all names that are C++ keywords.
Any progress?
Onno.
On Feb 24, 2004, at 15:45, Mark Wielaard wrote:
Hi,
On Mon, 2004-02-23 at 23:18, Michael Emmel wrote:
Sun has offered to clarify the SCSL license and its effect on projects
such and Gnu Classpath.
This happened in the following discussion thread
Am Mittwoch, 7. April 2004 18:32 schrieb Ingo Prötel:
Hi,
I would like to suggest removing all C++ keywords as names in the
native implementations of GNU Classpath. We have a customer who
insists on using C++ because of the more thorough code inspection. To
be able to compile with such a
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 this optimization...
Bye,
Chr. Ullenboom
Am Mittwoch, 7. April 2004 19:48 schrieb Chr. Ullenboom:
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 this
On Mon, Apr 05, 2004 at 10:14:11AM +0100, S. Meslin-Weber wrote:
Hi everyone,
As reported on #sablevm I'm happy to say that Odonata[1] runs well under
SableVM. I haven't measured any speeds or memory usage but with regards
to visual output SableVM is on a par with GIJ (both use GNU
Ingo == Ingo Prötel [EMAIL PROTECTED] writes:
Ingo I would like to suggest removing all C++ keywords as names in
Ingo the native implementations of GNU Classpath. We have a customer
Ingo who insists on using C++ because of the more thorough code
Ingo inspection. To be able to compile with such
== 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 this
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.
Does this mean to change to change the implementation in Classpath too? I
like this optimization...
I don't think we
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 some
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
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.
Hi Etienne,
while I think that your proposal would work with our VM it would also be quite
ineficient.
Our arrays can be fragemented so we nee to do some magic when accessing them in native
code.
Do you have any system that requires a pointer size larger than 64bits ?
My feeling is that once we
Here are some localization patches for the gnu.regexp package's
messages.
Index: ChangeLog
===
RCS file: /cvsroot/classpath/classpath/ChangeLog,v
retrieving revision 1.1982
diff -I*.class -u -r1.1982 ChangeLog
--- ChangeLog 7 Apr
33 matches
Mail list logo
