-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Saturday 24 April 2004 22:12, Archie Cobbs wrote:
So applying this logic, there should be no VMFile class because the
native methods of File.java are all implementable in a normal
Classpath-supplied shared library and are not VM-specific.
Just
Am Sonntag, 25. April 2004 11:06 schrieb Thomas Zander:
On Saturday 24 April 2004 22:12, Archie Cobbs wrote:
So applying this logic, there should be no VMFile class because the
native methods of File.java are all implementable in a normal
Classpath-supplied shared library and are not
And if your VM is sufficiently weird
enough (Jikes RVM with m-n threading), then you might actually want to
do something different about files. We used to have our own version
of FileDescriptor and do non-blocking I/O with hooks back into our threading
layer instead of using the default classpath
Hi,
On Thu, 2004-04-22 at 11:58, Jeroen Frijters wrote:
Since nobody objected, I'm going to be committing the change to
Class/VMClass that removes the need for a VMClass instance.
Thanks. I played a bit with it by implementing the necessary support
into jamvm (not that hard at all and it looks
Am Sonntag, 25. April 2004 13:40 schrieb David P Grove:
And if your VM is sufficiently weird enough (Jikes RVM with m-n
threading), then you might actually want to do something different
about files. We used to have our own version of FileDescriptor and
do non-blocking I/O with hooks back
David P Grove wrote:
On VMFoo vs. NativeFoo vs. PlatformFoo, I really don't care. I only
observe that one person's VMFoo is another person's native/platfrom so
perhaps it makes sense to just pick one name (VM) and leave it. I suspect
you are unlikely to be able to nicely divide the
Hi,
On Sat, 2004-04-24 at 20:57, Jeroen Frijters wrote:
Michael Koch wrote:
Here is another update.
Many thanks! Looks great. As far as I'm concerned, please commit.
I agree that this looks nice. It is good to see that every VM/Platform
specific method takes a path as argument. I had
David P. Grove wrote:
And if your VM is sufficiently weird enough (Jikes RVM with m-n
threading), then you might actually want to do something
different about files. We used to have our own version of
FileDescriptor and do non-blocking I/O with hooks back into our
threading layer instead of
Mark Wielaard wrote:
Starting your review with This makes no
sense whatsoever and then not giving any suggestion what you would like
to see changed or how isn't helpful.
This is false. I did provide a clear indication of the solution. I cite
the relevant part of my message:
Begin -
9 matches
Mail list logo