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... an
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 a
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
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 documente
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
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]
http:/
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. Th
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]
http://mail.gnu.org/ma
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 documente
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 imag
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
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
Etienne Gagnon writes:
> 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
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 R
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. Clea
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
>
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.
> >
> >
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 exten
Hi,
this is my revised patch for ColorPaintContext.
ingo
Thomas Fitzsimmons wrote:
On Mon, 2004-04-05 at 08:59, Ingo PrÃtel wrote:
I suggest the following patch
2004-04-05 Ingo Proetel <[EMAIL PROTECTED]>
* java/awt/ColorPaintContext.java (): Added ColorModel to signature.
(ge
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.
I
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
http://www.javalobby.org/thr
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
>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 li
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 Class
> "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 compil
> ">" == 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
>> li
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 necessari
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 som
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 200
Tom Tromey wrote:
"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 a
Am Donnerstag, 8. April 2004 05:06 schrieb Steven Augart:
> Here are some localization patches for the gnu.regexp package's
> messages.
Shouldnt this get submitted upstream first ?
Michael
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu
37 matches
Mail list logo
