RE: [Jikesrvm-core] Re: gnu.java.nio.channels.FileChannelImpl
Steven Augart wrote: 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. I agree, my port of classpath qualifies as fairly exotic and I just replaced FileChannelImpl with my own version. Similarly with PlainSocketImpl and PlainDatagramSocketImpl. I consider these cases the same as the VM* classes. As long as the interface to these classes doesn't change too often, this is a very workable solution. I don't know what type the Win32 API uses for a file descriptor; It uses a a pointer sized integer (i.e. 32 bit on Win32 and 64 bit on Win64). Regards, Jeroen ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Ease the synchronisation of GNUJAXP
Michael Koch [EMAIL PROTECTED] writes: 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 ... Except when you try to explain coding standards :P -- Arnaud Vandyck This is Unix we're talking about, remember. It's not supposed to be nice for the applications programmer. -- Matthew Danish on debian-devel ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: GNU Classpath 0.09 release (not yet, but pre1 available)
Mark Wielaard [EMAIL PROTECTED] writes: Hi, Hi Mark, Hi all, On Tue, 2004-05-04 at 13:42, Arnaud Vandyck wrote: 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=detailitemitem_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. Is it a feature present in the original javadoc? That's not a problem if not, but I just wanna know. - 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). I did never thought about that ;-) I'll look at it... - We do have images for some of the API doc, but those are not put into the resulting HTML files. Only the first sentence of the packages.html page is copied in the index.xml file. But the rest is not copied in the generated html file ([task #962] Parse package.html and extract body contents; there is a note saying 'Mark solved this' so maybe I'm wrong and I need to re-sync the Debian package); also the 'doc-files' directory is not copied ([bugs #8898] copy doc-files directory). I also plan to file bugs against all the original javadoc arguments gjdoc does not understand because in Debain we'd like gjdoc to be a complete replacement of javadoc tool. 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
Re: [Jikesrvm-core] Re: gnu.java.nio.channels.FileChannelImpl
On Tue, 2004-05-11 at 14:34, Steven Augart wrote: If someone does that kind of port, he'll have more problems than just than the size of a file descriptor. I did an exotic port, and this was my solution (which I still think is a good idea!): http://mail.gnu.org/archive/html/classpath/2003-04/msg00092.html AG -- Anthony Green [EMAIL PROTECTED] Red Hat, Inc. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: [Jikesrvm-core] Re: gnu.java.nio.channels.FileChannelImpl
Anthony Green wrote: I did an exotic port, and this was my solution (which I still think is a good idea!): http://mail.gnu.org/archive/html/classpath/2003-04/msg00092.html The overhead of always using a 64-bit quantity to store a file descriptor and then passing it to the JNI functions would be several times lower than the overhead of those JNI functions having to call PlatformFileDescriptor.getFD(). Unless, of course, your VM implements something like CNI. So this might be an efficient solution for GCJ. --Steve Augart ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: [Jikesrvm-core] Re: gnu.java.nio.channels.FileChannelImpl
On Wed, 2004-05-12 at 03:58, Steven Augart wrote: The overhead of always using a 64-bit quantity to store a file descriptor and then passing it to the JNI functions would be several times lower than the overhead of those JNI functions having to call PlatformFileDescriptor.getFD(). ? That's not what I'm suggesting at all. AG -- Anthony Green [EMAIL PROTECTED] Red Hat, Inc. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: [Jikesrvm-core] Re: gnu.java.nio.channels.FileChannelImpl
Anthony Green wrote: I did an exotic port, and this was my solution (which I still think is a good idea!): http://mail.gnu.org/archive/html/classpath/2003-04/msg00092.html which says: My basic plan is to move all of these package private methods to a new abstract class called gnu.java.io.PlatformFileDescriptor (for lack of a better name). java.io.FileDescriptor will have one new package private method for returning the PlatformFileDescriptor associated with that FileDescriptor. One of the advantages of the new FileChannel-based implementation is that we no longer need a separate PlatformFileDescriptor. The FileChannelImpl serves that need, without the need for an extra object and extra indirection. Right now FileChannelImpl is not sub-classed, but it would be perfectly reasonable and a minor change to use implementation-specific FileChannel[Impl] classes. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/ ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Trouble running autogen.sh
I get the following output when I run ./autogen.sh in the root of a classpath CVS checkout. Am I doing something wrong? This has happened several times in a row, even after I updated my aclocal.m4 by running aclocal -I . (Not that I should have to, since autogen does it for me, but there is that warning from libtoolize.) --Steve Augart --- Output Follows -- libtoolize (GNU libtool) 1.4.3 libtoolize: minimum version required: 1.4.2 autoconf (GNU Autoconf) 2.59 autoconf: minimum version required: 2.59 autoheader (GNU Autoconf) 2.59 autoheader: minimum version required: 2.59 automake (GNU automake) 1.7.7 automake: minimum version required: 1.7.0 aclocal (GNU automake) 1.7.7 aclocal: minimum version required: 1.7.0 libtoolize ... You should update your `aclocal.m4' by running aclocal. aclocal ... autoheader ... automake ... native/fdlibm/Makefile.am:1: Libtool library used but `LIBTOOL' is undefined native/fdlibm/Makefile.am:1: native/fdlibm/Makefile.am:1: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL' native/fdlibm/Makefile.am:1: to `configure.ac' and run `aclocal' and `autoconf' again. native/jni/classpath/Makefile.am:1: Libtool library used but `LIBTOOL' is undefined native/jni/classpath/Makefile.am:1: native/jni/classpath/Makefile.am:1: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL' native/jni/classpath/Makefile.am:1: to `configure.ac' and run `aclocal' and `autoconf' again. native/jni/gtk-peer/Makefile.am:1: Libtool library used but `LIBTOOL' is undefined native/jni/gtk-peer/Makefile.am:1: native/jni/gtk-peer/Makefile.am:1: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL' native/jni/gtk-peer/Makefile.am:1: to `configure.ac' and run `aclocal' and `autoconf' again. native/jni/java-awt/Makefile.am:1: Libtool library used but `LIBTOOL' is undefined native/jni/java-awt/Makefile.am:1: native/jni/java-awt/Makefile.am:1: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL' native/jni/java-awt/Makefile.am:1: to `configure.ac' and run `aclocal' and `autoconf' again. native/jni/java-io/Makefile.am:1: Libtool library used but `LIBTOOL' is undefined native/jni/java-io/Makefile.am:1: native/jni/java-io/Makefile.am:1: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL' native/jni/java-io/Makefile.am:1: to `configure.ac' and run `aclocal' and `autoconf' again. native/jni/java-lang/Makefile.am:1: Libtool library used but `LIBTOOL' is undefined native/jni/java-lang/Makefile.am:1: native/jni/java-lang/Makefile.am:1: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL' native/jni/java-lang/Makefile.am:1: to `configure.ac' and run `aclocal' and `autoconf' again. native/jni/java-net/Makefile.am:1: Libtool library used but `LIBTOOL' is undefined native/jni/java-net/Makefile.am:1: native/jni/java-net/Makefile.am:1: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL' native/jni/java-net/Makefile.am:1: to `configure.ac' and run `aclocal' and `autoconf' again. native/jni/java-nio/Makefile.am:1: Libtool library used but `LIBTOOL' is undefined native/jni/java-nio/Makefile.am:1: native/jni/java-nio/Makefile.am:1: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL' native/jni/java-nio/Makefile.am:1: to `configure.ac' and run `aclocal' and `autoconf' again. native/jni/java-util/Makefile.am:1: Libtool library used but `LIBTOOL' is undefined native/jni/java-util/Makefile.am:1: native/jni/java-util/Makefile.am:1: The usual way to define `LIBTOOL' is to add `AC_PROG_LIBTOOL' native/jni/java-util/Makefile.am:1: to `configure.ac' and run `aclocal' and `autoconf' again. Compilation exited abnormally with code 1 at Wed May 12 06:43:49 ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: [Jikesrvm-core] Re: gnu.java.nio.channels.FileChannelImpl
Anthony Green wrote: On Wed, 2004-05-12 at 03:58, Steven Augart wrote: The overhead of always using a 64-bit quantity to store a file descriptor and then passing it to the JNI functions would be several times lower than the overhead of those JNI functions having to call PlatformFileDescriptor.getFD(). ? That's not what I'm suggesting at all. Sorry that I misunderstood. I've now read over the whole thread from your original proposal (I'd only read the proposal itself). Until I take the time to download and read the .gz file you referred to in a later post, and until I better familiarize myself with the current state of that code, I'll avoid further comment. --Steve Augart -- 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: Trouble running autogen.sh
Michael Koch wrote: Can you try a newer libtool ? Perhaps 1.4.2/3 is just too old. Done. I downloaded and built 1.5.6 onto the antique Red Hat 9 system I'm using. It works fine. Obviously the minimum should be upgraded to at least 1.4.4 (and that too might not work). Would someone be willing to update the message that autogen.sh puts out? (Possibly also to do the research?) I've successfully used 1.4.3 to run autogen on another host for the nightly Jikes RVM classpath regression tests, so I don't really know what is going on here. --Steve Augart -- 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: Trouble running autogen.sh
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Mittwoch, 12. Mai 2004 18:03 schrieb Steven Augart: Michael Koch wrote: Can you try a newer libtool ? Perhaps 1.4.2/3 is just too old. Done. I downloaded and built 1.5.6 onto the antique Red Hat 9 system I'm using. It works fine. Obviously the minimum should be upgraded to at least 1.4.4 (and that too might not work). Would someone be willing to update the message that autogen.sh puts out? (Possibly also to do the research?) I've successfully used 1.4.3 to run autogen on another host for the nightly Jikes RVM classpath regression tests, so I don't really know what is going on here. Whats the differences between the two machines ? same architeture ? Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAok1qWSOgCCdjSDsRAsfpAJ9JcgYeapMn9e9GL0q9x4ghBCWkKQCdF+Vt iXahQvfatrhmDhFVHDr0veY= =J0i9 -END PGP SIGNATURE- ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Trouble running autogen.sh
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Am Mittwoch, 12. Mai 2004 12:47 schrieb Steven Augart: I get the following output when I run ./autogen.sh in the root of a classpath CVS checkout. Am I doing something wrong? This has happened several times in a row, even after I updated my aclocal.m4 by running aclocal -I . (Not that I should have to, since autogen does it for me, but there is that warning from libtoolize.) Can you try a newer libtool ? Perhaps 1.4.2/3 is just too old. Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAojPkWSOgCCdjSDsRAq0SAJ9HSGAbFn0iAsHE328kN/uIMTG+DQCdEOS1 hTxoLFmv4ls1IMcIpk0vin0= =6UaH -END PGP SIGNATURE- ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
