Re: [Jikesrvm-core] Re: gnu.java.nio.channels.FileChannelImpl
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 the size of a file descriptor. > > I think Michael was being ironic. I haven't checked the current > Classpath, libcj (which shares most of its code with Classpath) > certainly supports Windows. > > I think the cleanest solution is to allows FileChannelImpl to be > subclassed, or to uses different classes that implement FileChannel. > But the current code works fine for now. > > For JNI performance I don't see any reason not to not to have the > Java code pass the "native" fd field to the native method - just > realize that if/when Classpath gets ported to a system that > uses 64 pointers we may have to redo things. One solution > may be to use the Posix API. > > The Posix IO functions (open/read/write etc) are available on > Windows. I don't know why they're not used - performance? I don't really know, Orp developers used the Posix stuff in Windows for implementing Classpath's JNI methods some time back. Then some folks in GCJ land decided they'd be better off using the native Windows API. The changes are pretty small to use Windows Posix API vs what we do today. Is the current JNI code compatible with a 64 bit system? Can you open a file larger than 4G or whatever it is and use the whole thing? Brian signature.asc Description: This is a digitally signed message part ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Question on java.lang.Thread and "final static int" constants
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 the values at > Steven> run time and cache the results? Since the Java language spec > Steven> expicitly allows the java source-to-byte-code compiler to inline the > Steven> values of static final constants, presumably the values can never > Steven> change in the future > > Yeah, in theory the values can't change. In practice, Sun has broken > this once or twice in the past, though honestly I doubt they would > bother changing these particular values. > > I'd say in a case like this you can do whatever you like, provided the > result is documented. There is precedent for native code to simply #define these constants to avoid expensive lookups so feel free to do the same here. Could probably add it to the cp-tools version of javap even if it isn't there. Brian signature.asc Description: This is a digitally signed message part ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: [Jikesrvm-core] Re: gnu.java.nio.channels.FileChannelImpl
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 the size of a file descriptor. I think Michael was being ironic. I haven't checked the current Classpath, libcj (which shares most of its code with Classpath) certainly supports Windows. I think the cleanest solution is to allows FileChannelImpl to be subclassed, or to uses different classes that implement FileChannel. But the current code works fine for now. For JNI performance I don't see any reason not to not to have the Java code pass the "native" fd field to the native method - just realize that if/when Classpath gets ported to a system that uses 64 pointers we may have to redo things. One solution may be to use the Posix API. The Posix IO functions (open/read/write etc) are available on Windows. I don't know why they're not used - performance? -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
--portable-native-sync and error handling
It turns out that "glib"'s g_critical() facility, used to report serious problems, calls g_log(), which then goes ahead and calls the g_thread functions again. Which are the very ones that are trying to report the problem. I've switched the error reporting in the --portable-native-sync back to using the equivalent of fprintf(stderr, ...). I've also gone back to using old-fashioned assert() instead of glib's g_assert(). -- Steven Augart Jikes RVM, a free, open source, Virtual Machine: http://oss.software.ibm.com/jikesrvm ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: [Jikesrvm-core] Re: gnu.java.nio.channels.FileChannelImpl
Michael Koch wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Dienstag, 11. Mai 2004 22:36 schrieb Steven Augart: Michael Koch wrote: Which leads us to the discussion again what type a file descriptor should have. Is an int (4 byte) enought for 64 bit archs ? What about 128 bit archs in the future ? From the last discussions fd should be at least long when. I know that GNU classpath currently uses int but when we change it we can try to do it right. Yes, an int is plenty of space. It will always be plenty of space unless you plan to be opening more than 2^31 files (and that exceeds the limits of every Unix-like system that i know of). I should caution here that I don't have a copy of the POSIX spec. However, the manual page for open(2) on Linux says: The open() system call is used to convert a pathname into a file descriptor (a small, non-negative integer for use in subsequent I/O as with read, write, etc.). When the call is successful, the file descriptor returned will be the lowest file descriptor not currently open for the pro- ---^^ cess. This guarantee is part of historical Unix semantics for open() -- there is still code around that (for example) closes file descriptor 0 (standard input) and then opens some other file, expecting that any successful open will assign descriptor 0 to the opened file. So, if open() ever stopped handing out the lowest descriptor it could, existing Unix code would break. 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 the size of a file descriptor. I am not a big fan of writing massively general code "just in case." The Extreme Programming series of books talks about this too. "Sufficient unto the day is the evil thereof." It is nice to uses abstraction -- if we were running a preprocessor over Classpath's code then I would favor using a named type called something like filedesc_t which will turn into "int" on all of the platforms we currently run on -- but there is not consensus in favor of preprocessing our Java right now, and Java lacks any "typedef"-style mechanism for handling this sort of thing. I don't know what type the Win32 API uses for a file descriptor; I have a vague memory of it also being a small integer, but this may be wrong. In any case, I think that someone doing such a port would propose an appropriate change at the time of the port. This is also why I was not a big fan of using byte[] to represent pointers just so that we could possibly be compatible with a system that no Classpath users were actually running. In my Classpath code that interacts with C, I represent a C pointer as a Java "long". That wastes 32 bits on the machines that I am running classpath on, but it works. When we go to new kinds of machines, we'll deal with the problems as they come up. -- Steven Augart Jikes RVM, a free, open source, Virtual Machine: http://oss.software.ibm.com/jikesrvm ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Ease the synchronisation of GNUJAXP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Dienstag, 11. Mai 2004 19:03 schrieb Arnaud Vandyck: > Some comments about this cryptic message! > > Dalibor and Mark told me one day that it's difficult to merge > gnujaxp because of the $Id$ tags in some files. When they compare > files, the diff were huge and sometimes they were NO changes! > > So to ease the merge, I did remove all the $Id$ tags... but forgot > some. Now, every tags are out (I hope) ;-) > > Michael: Is it a better explanation? ;-) Muchas gracias for this explanation. I hope I dont write such cryptic mails too often and just noone tells me ... Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAoQuzWSOgCCdjSDsRAubTAJ9HLrZChunFadJZqamHeP8agT5ZYwCeKRgh pUc2Hrb24pau6MpD0AXlyYM= =QHYn -END PGP SIGNATURE- ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: [Jikesrvm-core] Re: gnu.java.nio.channels.FileChannelImpl
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Dienstag, 11. Mai 2004 22:36 schrieb Steven Augart: > Michael Koch wrote: > > Which leads us to the discussion again what type a file > > descriptor should have. Is an int (4 byte) enought for 64 bit > > archs ? What about 128 bit archs in the future ? From the last > > discussions fd should be at least long when. I know that GNU > > classpath currently uses int but when we change it we can try to > > do it right. > > Yes, an int is plenty of space. It will always be plenty of space > unless you plan to be opening more than 2^31 files (and that > exceeds the limits of every Unix-like system that i know of). > > I should caution here that I don't have a copy of the POSIX spec. > However, the manual page for open(2) on Linux says: > > The open() system call is used to convert a pathname into > a file descriptor (a small, non-negative integer for use > in subsequent I/O as with read, write, etc.). When the > call is successful, the file descriptor returned will be > the lowest file descriptor not currently open for the pro- > ---^^ > cess. > > This guarantee is part of historical Unix semantics > for open() -- there is still code around that (for example) closes > file descriptor 0 (standard input) and then opens some other file, > expecting that any successful open will assign descriptor 0 to > the opened file. > > So, if open() ever stopped handing out the lowest descriptor > it could, existing Unix code would break. What if someone wants to port GNU classpath to an Operating System with totally different semantics like Windows ? Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAoT4FWSOgCCdjSDsRAh9KAJ9dTcmLutgZ2J15tDQNdgb766No4QCfb+ls eD0Jn1YYAA82ImQynrzpUiQ= =i97K -END PGP SIGNATURE- ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: [Jikesrvm-core] Re: gnu.java.nio.channels.FileChannelImpl
Michael Koch wrote: Which leads us to the discussion again what type a file descriptor should have. Is an int (4 byte) enought for 64 bit archs ? What about 128 bit archs in the future ? From the last discussions fd should be at least long when. I know that GNU classpath currently uses int but when we change it we can try to do it right. Yes, an int is plenty of space. It will always be plenty of space unless you plan to be opening more than 2^31 files (and that exceeds the limits of every Unix-like system that i know of). I should caution here that I don't have a copy of the POSIX spec. However, the manual page for open(2) on Linux says: The open() system call is used to convert a pathname into a file descriptor (a small, non-negative integer for use in subsequent I/O as with read, write, etc.). When the call is successful, the file descriptor returned will be the lowest file descriptor not currently open for the pro- ---^^ cess. This guarantee is part of historical Unix semantics for open() -- there is still code around that (for example) closes file descriptor 0 (standard input) and then opens some other file, expecting that any successful open will assign descriptor 0 to the opened file. So, if open() ever stopped handing out the lowest descriptor it could, existing Unix code would break. -- Steven Augart Jikes RVM, a free, open source, Virtual Machine: http://oss.software.ibm.com/jikesrvm ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Changelog-umlaut-1.patch
> "Steven" == Steven Augart <[EMAIL PROTECTED]> writes: Steven> * ChangeLog: Restore corrupted umlauts. Steven> Some time between 2004-04-07 and 2004-05-01, somebody used Steven> an editing tool on ChangeLog that converted Bernd Mösli's surname Steven> to Mvsli, and similarly corrupted the names of Jörg Prante and Steven> H. Väisänen. I'm really sorry -- that was me. It looks like Eclipse and/or libgcj has a bug here. Cue Mark ... :-). I'll look more carefully in the future. Tom ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: GNU Classpath 0.09 release (not yet, but pre1 available)
Hi,
On Tue, 2004-05-04 at 13:42, Arnaud Vandyck wrote:
> Mark Wielaard <[EMAIL PROTECTED]> writes:
>
> > GNU Classpath has grown again and gjdoc takes more then two and half
> > hours with 170M on my machine :{ Found some small HTML entity issues
> > which have been fixed. Results can be seen at:
> > http://www.klomp.org/mark/classpath/doc/api/html/
> >
> > Unfortunately we will have to fix some things with gjdoc (copyright
> > statements, images, etc.) to have a real official page with the docs.
>
> As I already proposed, I still want to help cp-tools and gjdoc...
Great. Thanks.
There are several things that need to be done before we can easily and
correctly use gjdoc to create official GNU Classpath API documentation.
- HTML entity issues as described in [bugs #4823] HTML entities such as
auml and nbsp should be put back in the API doc
https://savannah.gnu.org/bugs/?func=detailitem&item_id=4823
The problem is unanalyzed and happens when using the native compiled
gjdoc as described in the FAQ:
http://www.gnu.org/software/classpath/faq/faq.html#faq5_1
It would be great if someone could analyze what goes wrong.
- Copyright statements as found in the actual source file should appear
in the generated HTML file.
What we need is an option to get the first comment block text that
contains the word 'Copyright' in it by gcj to be put in the generated
XML file so that we can use XSLT to put it into the HTML file.
- The generation of HTML files should be speed up a lot. It seems that
we can generate the XML files in not to much time, but the XSLT
transformation to XHTML takes hours. Someone with XSLT performance
experience would be great (or someone that would like to learn about
that of course).
- We do have images for some of the API doc, but those are not put into
the resulting HTML files.
Cheers,
Mark
signature.asc
Description: This is a digitally signed message part
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: Ease the synchronisation of GNUJAXP
Some comments about this cryptic message! Dalibor and Mark told me one day that it's difficult to merge gnujaxp because of the $Id$ tags in some files. When they compare files, the diff were huge and sometimes they were NO changes! So to ease the merge, I did remove all the $Id$ tags... but forgot some. Now, every tags are out (I hope) ;-) Michael: Is it a better explanation? ;-) Cheers, Arnaud Vandyck <[EMAIL PROTECTED]> writes: > FYI: > > 2004-05-11 Arnaud Vandyck <[EMAIL PROTECTED]> > > * acinclude.m4, aclocal.m4, configure.ac, config/mkinstalldirs, > source/gnu/xml/dom/package.html, > source/gnu/xml/pipeline/package.html, > source/gnu/xml/util/package.html, source/org/xml/sax/package.html, > source/org/xml/sax/ext/package.html, > source/org/xml/sax/helpers/package.html: removed $Id$ tag. > > Reported by Maarten Coene <[EMAIL PROTECTED]>: > * source/gnu/xml/aelfred2/XmlParser.java: changed 'enum' variable > name to 'enumer' to avoid reserved keyword of Java1.5. > > Cheers, > > -- > Arnaud Vandyck > > < sam> /.ing an issue is like asking an infinite number of monkeys for >advice > -- in #debian-devel > > > ___ > Classpath mailing list > [EMAIL PROTECTED] > http://mail.gnu.org/mailman/listinfo/classpath > > -- Arnaud Vandyck < asuffield> a workstation is anything you can stick on somebodies desk and con them into using -- in #debian-devel ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: classpath 0.09 and AIX
Sorry, I should have included the error messages in my previous email. They are appended. I'm a little baffled as to what is going on as the undeclared definitions can be found in fcntl.h and sys/stat.h and it looked to me like those files were being included. But, I'm not a big C hacker, so I am probably missing something obvious. --dave make[3]: Entering directory `/homes/angmar/dgrove/rvmRoot/classpath/powerpc-ibm-aix5.1.0.0/native/jni/java-io' if /bin/sh ../../../libtool --mode=compile /usr/gnu/bin/gcc -w -O -Wa,-mppc -DHAVE_CONFIG_H -I. -I../../../../classpath/native/jni/java-io -I../../../include -I. -I../../../../classpath/native/target/Linux -I../../../../classpath/native/target/generic -I../../../../classpath/native/jni/classpath -I../../../../classpath/include -I../../../include -ansi -pedantic -Wall -Wno-long-long -D_BSD_SOURCE -g -O2 -MT javaio.lo -MD -MP -MF ".deps/javaio.Tpo" -c -o javaio.lo ../../../../classpath/native/jni/java-io/javaio.c; \ then mv -f ".deps/javaio.Tpo" ".deps/javaio.Plo"; else rm -f ".deps/javaio.Tpo"; exit 1; fi /usr/gnu/bin/gcc -w -O -Wa,-mppc -DHAVE_CONFIG_H -I. -I../../../../classpath/native/jni/java-io -I../../../include -I. -I../../../../classpath/native/target/Linux -I../../../../classpath/native/target/generic -I../../../../classpath/native/jni/classpath -I../../../../classpath/include -I../../../include -ansi -pedantic -Wall -Wno-long-long -D_BSD_SOURCE -g -O2 -MT javaio.lo -MD -MP -MF .deps/javaio.Tpo -c ../../../../classpath/native/jni/java-io/javaio.c -DPIC -o .libs/javaio.o ../../../../classpath/native/jni/java-io/javaio.c: In function `_javaio_open_read': ../../../../classpath/native/jni/java-io/javaio.c:71: error: `O_RDONLY' undeclared (first use in this function) ../../../../classpath/native/jni/java-io/javaio.c:71: error: (Each undeclared identifier is reported only once ../../../../classpath/native/jni/java-io/javaio.c:71: error: for each function it appears in.) ../../../../classpath/native/jni/java-io/javaio.c:71: error: `S_IRUSR' undeclared (first use in this function) ../../../../classpath/native/jni/java-io/javaio.c:71: error: `S_IWUSR' undeclared (first use in this function) ../../../../classpath/native/jni/java-io/javaio.c:71: error: `S_IRGRP' undeclared (first use in this function) ../../../../classpath/native/jni/java-io/javaio.c:71: error: `S_IWGRP' undeclared (first use in this function) ../../../../classpath/native/jni/java-io/javaio.c:71: error: `S_IROTH' undeclared (first use in this function) ../../../../classpath/native/jni/java-io/javaio.c:71: error: `S_IWOTH' undeclared (first use in this function) ../../../../classpath/native/jni/java-io/javaio.c:71: error: `F_SETFD' undeclared (first use in this function) ../../../../classpath/native/jni/java-io/javaio.c:71: error: `FD_CLOEXEC' undeclared (first use in this function) ../../../../classpath/native/jni/java-io/javaio.c: In function `_javaio_open_readwrite': ../../../../classpath/native/jni/java-io/javaio.c:107: error: `O_RDWR' undeclared (first use in this function) ../../../../classpath/native/jni/java-io/javaio.c:107: error: `S_IRUSR' undeclared (first use in this function) ../../../../classpath/native/jni/java-io/javaio.c:107: error: `S_IWUSR' undeclared (first use in this function) ../../../../classpath/native/jni/java-io/javaio.c:107: error: `S_IRGRP' undeclared (first use in this function) ../../../../classpath/native/jni/java-io/javaio.c:107: error: `S_IWGRP' undeclared (first use in this function) ../../../../classpath/native/jni/java-io/javaio.c:107: error: `S_IROTH' undeclared (first use in this function) ../../../../classpath/native/jni/java-io/javaio.c:107: error: `S_IWOTH' undeclared (first use in this function) ../../../../classpath/native/jni/java-io/javaio.c:107: error: `F_SETFD' undeclared (first use in this function) ../../../../classpath/native/jni/java-io/javaio.c:107: error: `FD_CLOEXEC' undeclared (first use in this function) ../../../../classpath/native/jni/java-io/javaio.c: In function `_javaio_skip_bytes': ../../../../classpath/native/jni/java-io/javaio.c:164: error: `off_t' undeclared (first use in this function) ../../../../classpath/native/jni/java-io/javaio.c: In function `_javaio_get_file_length': ../../../../classpath/native/jni/java-io/javaio.c:195: error: storage size of `__statBuffer' isn't known make[3]: *** [javaio.lo] Error 1 make[3]: Leaving directory `/homes/angmar/dgrove/rvmRoot/classpath/powerpc-ibm-aix5.1.0.0/native/jni/java-io' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/homes/angmar/dgrove/rvmRoot/classpath/powerpc-ibm-aix5.1.0.0/native/jni' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/homes/angmar/dgrove/rvmRoot/classpath/powerpc-ibm-aix5.1.0.0/native' make: *** [all-recursive] Error 1___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Ease the synchronisation of GNUJAXP
FYI: 2004-05-11 Arnaud Vandyck <[EMAIL PROTECTED]> * acinclude.m4, aclocal.m4, configure.ac, config/mkinstalldirs, source/gnu/xml/dom/package.html, source/gnu/xml/pipeline/package.html, source/gnu/xml/util/package.html, source/org/xml/sax/package.html, source/org/xml/sax/ext/package.html, source/org/xml/sax/helpers/package.html: removed $Id$ tag. Reported by Maarten Coene <[EMAIL PROTECTED]>: * source/gnu/xml/aelfred2/XmlParser.java: changed 'enum' variable name to 'enumer' to avoid reserved keyword of Java1.5. Cheers, -- Arnaud Vandyck < sam> /.ing an issue is like asking an infinite number of monkeys for advice -- in #debian-devel ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
