Re: Cinco de Mayo
> > Would there be objections to a new release available on May 5? Mostly > > to get the recent changes requiring VM support out there on the ftp > > site but also to show the progress with other packages. > > It would be great to get a new release out. But I am afraid that I won't > have much time to help this week and I still haven't got Orp to play > nice with the latest Classpath changes. I do have some extra time next > week if you need any help with testing and/or releasing. > > I also would like to wait till gcj 3.1 is actually released (any > day/week now) since Classpath cannot be compiled with older versions > anymore. And Mauve was recently cleaned up a bit so I would like to see > the new results on at least one VM/Classpath combination. A new release would be very useful. What can I do to help? John Leuner ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Cinco de Mayo
Mark Wielaard <[EMAIL PROTECTED]> writes: > Hi, > > On Thu, 2002-05-02 at 04:41, Brian Jones wrote: > > Would there be objections to a new release available on May 5? Mostly > > to get the recent changes requiring VM support out there on the ftp > > site but also to show the progress with other packages. > > It would be great to get a new release out. But I am afraid that I won't > have much time to help this week and I still haven't got Orp to play > nice with the latest Classpath changes. I do have some extra time next > week if you need any help with testing and/or releasing. I'll look into the ORP problems today, my guess is the ORP team has already tracked these changes in their unreleased version. > I also would like to wait till gcj 3.1 is actually released (any > day/week now) since Classpath cannot be compiled with older versions > anymore. And Mauve was recently cleaned up a bit so I would like to see > the new results on at least one VM/Classpath combination. It is still compilable with jikes 1.15b. I checked out the lateast Kissme to see if it worked with CVS as well but didn't anywhere. Brian -- Brian Jones <[EMAIL PROTECTED]> ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Bug in java.util.TreeMap
Hello, the third line from the end of the sourcecode of java.util.TreeMap as visible at http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/java/util/TreeMap.java?rev=1.19&content-type=text/vnd.viewcvs-markup is return this.keys; but it should be return this.values; This typo was not caught by the compiler because each set is also a collection. Regards, Xuân. P.S.: Please include my e-Mail address in replies as I'm not subscribed. -- Mit freundlichen Grüßen Xuân Baldauf Medium.net Internet Server Software ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Another bug in TreeMap
Hello,
there is another bug in java.util.TreeMap. The sourcecode
contains following lines:
public Object remove(Object key)
{
Node n = getNode(key);
if (n == nil)
return null;
removeNode(n);
return n.value;
}
final void removeNode(Node node)
{
Node splice;
Node child;
modCount++;
size--;
// Find splice, the node at the position to actually
remove from the tree.
if (node.left == nil)
{
// Node to be deleted has 0 or 1 children.
splice = node;
child = node.right;
}
else if (node.right == nil)
{
// Node to be deleted has 1 child.
splice = node;
child = node.left;
}
else
{
// Node has 2 children. Splice is node's
predecessor, and we swap
// its contents into node.
splice = node.left;
while (splice.right != nil)
splice = splice.right;
child = splice.left;
node.key = splice.key;
node.value = splice.value;
}
// Unlink splice from the tree.
Node parent = splice.parent;
if (child != nil)
child.parent = parent;
if (parent == nil)
{
// Special case for 0 or 1 node remaining.
root = child;
return;
}
if (splice == parent.left)
parent.left = child;
else
parent.right = child;
if (splice.color == BLACK)
deleteFixup(child, parent);
}
In case the node to be removed has two children, within
removeNode(), new keys and values will be swapped into the
node the which is about to be removed. After removeNode()
finished, remove() returns the value variable of that node.
Because it was changed previously within removeNode(), the
wrong value (from the swapped in node rather than from the
original node) is returned. This is a bug.
Regards,
Xuân.
P.S.: Please include my e-Mail address in replies as I'm not
subscribed.
--
Mit freundlichen Grüßen
Xuân Baldauf
Medium.net Internet Server Software
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: Cinco de Mayo
John Leuner <[EMAIL PROTECTED]> writes: > A new release would be very useful. > > What can I do to help? You have a good perspective on how changes since the last release affect JVMs even in less obvious cases. I'd like to add some notes to the NEWS file indicating these things. If Kissme works with Classpath's CVS, some directions on setting it up would be great. Brian -- Brian Jones <[EMAIL PROTECTED]> ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Cinco de Mayo
> > > Would there be objections to a new release available on May 5? Mostly > > > to get the recent changes requiring VM support out there on the ftp > > > site but also to show the progress with other packages. > > > > It would be great to get a new release out. But I am afraid that I won't > > have much time to help this week and I still haven't got Orp to play > > nice with the latest Classpath changes. I do have some extra time next > > week if you need any help with testing and/or releasing. > > I'll look into the ORP problems today, my guess is the ORP team has > already tracked these changes in their unreleased version. > > > I also would like to wait till gcj 3.1 is actually released (any > > day/week now) since Classpath cannot be compiled with older versions > > anymore. And Mauve was recently cleaned up a bit so I would like to see > > the new results on at least one VM/Classpath combination. > > It is still compilable with jikes 1.15b. I checked out the lateast > Kissme to see if it worked with CVS as well but didn't anywhere. > I quickly tried to compile kissme and classpath, my notes are attached. This is not meant to be quite such a manual process, we are in the middle of fixing the build scripts. I tested a simple case (haven't run mauve yet). As you can see in the last line there, kissme needs the class files to be unpacked. It can load .jar and .zip files, but since that code is java code, it needs to get all the core stuff from the filesystem first. Could we add an option to 'make install' which would copy all .class files to a $prefix/share/classpath/classes directory? It's wonderful that classpath can compile itself without requiring any VM files. Am I correct in saying that classpath depends only on the auto* programs, gcc, jikes and zip? I want to build a debian package when the new release comes out. Prior to this I always built a package with kissme-specific VM files, now I can remove this dependency (and effort). John Leuner ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Cinco de Mayo
John Leuner <[EMAIL PROTECTED]> writes: > I quickly tried to compile kissme and classpath, my notes are > attached. This is not meant to be quite such a manual process, we > are in the middle of fixing the build scripts. I didn't find any notes attached. > Could we add an option to 'make install' which would copy all .class > files to a $prefix/share/classpath/classes directory? Someone mentioned doing this recently, it is easy and I planned to add it myself before the release. > > > It's wonderful that classpath can compile itself without requiring > any VM files. Am I correct in saying that classpath depends only on > the auto* programs, gcc, jikes and zip? auto*, libtool, gcc, jikes or gcj 3.1), zip is optional > I want to build a debian package when the new release comes > out. Prior to this I always built a package with kissme-specific VM > files, now I can remove this dependency (and effort). Great! -- Brian Jones <[EMAIL PROTECTED]> ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Cinco de Mayo
> > I quickly tried to compile kissme and classpath, my notes are
> > attached. This is not meant to be quite such a manual process, we
> > are in the middle of fixing the build scripts.
>
> I didn't find any notes attached.
They should give an option in mailers to cleverly search the text and determine when
someone has forgotten to actually do the attachment.
> > Could we add an option to 'make install' which would copy all .class
> > files to a $prefix/share/classpath/classes directory?
>
> Someone mentioned doing this recently, it is easy and I planned to add
> it myself before the release.
Excellent.
> >
> >
> > It's wonderful that classpath can compile itself without requiring
> > any VM files. Am I correct in saying that classpath depends only on
> > the auto* programs, gcc, jikes and zip?
>
> auto*, libtool, gcc, jikes or gcj 3.1), zip is optional
Great
> > I want to build a debian package when the new release comes
> > out. Prior to this I always built a package with kissme-specific VM
> > files, now I can remove this dependency (and effort).
Is there anyone who builds RPMs, has anyone built a classpath RPM?
John Leuner
Made install directory /mnt/dev/freshinst
Fetched classpath CVS
Fetched kissme CVS
bapli% aclocal; autoheader; automake; autoconf
/mnt/dev/freshkiss/classpath/classpath
WARNING: Using auxiliary files such as `acconfig.h', `config.h.bot'
WARNING: and `config.h.top', to define templates for `config.h.in'
WARNING: is deprecated and discouraged.
WARNING: Using the third argument of `AC_DEFINE' and
WARNING: `AC_DEFINE_UNQUOTED' allows to define a template without
WARNING: `acconfig.h':
WARNING: AC_DEFINE([NEED_MAIN], 1,
WARNING: [Define if a function `main' is needed.])
WARNING: More sophisticated templates can also be produced, see the
WARNING: documentation.
configure.in:20: warning: do not use m4_patsubst: use patsubst or m4_bpatsubst
configure.in:364: warning: do not use m4_regexp: use regexp or m4_bregexp
autoheader2.50: `include/config.h.in' is created
./configure --enable-jni --prefix=/mnt/dev/freshinst --with-jikes
Jikes version:
(debian 1.15-2)
Version 1.15 - 26 Sept 2001
bapli% gcc -v
Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.4/specs
gcc version 2.95.4 20011002 (Debian prerelease)
make
make install
Kissme build:
make
jikes -classpath /mnt/dev/freshinst/share/classpath/glibj.zip:classes `find
classes/{java,gnu,plava,jos} -name '*.java'`
LD_LIBRARY_PATH=/mnt/dev/freshinst/lib/classpath/ ./kissme -bootclasspath
classes:/mnt/dev/freshkiss/classpath/classpath/lib someclass
FYI: bug in cygwin affects build
I ran into a bug with cygwin 1.3.10 when compiling the latest Classpath with jikes 1.15b. Basically, cygwin is unable to tell the difference between java/net and java/nio in some cases, so it causes jikes to compile .class files to the wrong directory. The bug is detailed in http://cygwin.com/ml/cygwin/2002-04/msg01655.html. It is dependent on the absolute path of the build directory, so it will not appear for all users; and in many cases, if you are bit by the bug, the simplest workaround is renaming the build directory. Or you can wait for the next release of cygwin, when it will be patched, or check out the latest CVS version of jikes where I added a hack to avoid this particular bug. -- This signature intentionally left boring. Eric Blake [EMAIL PROTECTED] BYU student, free software programmer ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Cinco de Mayo
John Leuner <[EMAIL PROTECTED]> writes: > Is there anyone who builds RPMs, has anyone built a classpath RPM? I built one a long time ago; I still have the .src.rpm available and therefor the spec file. Brian -- Brian Jones <[EMAIL PROTECTED]> ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Bug in java.util.TreeMap
Xuan Baldauf <[EMAIL PROTECTED]> writes: > Hello, > > the third line from the end of the sourcecode of > java.util.TreeMap as visible at > > >http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/java/util/TreeMap.java?rev=1.19&content-type=text/vnd.viewcvs-markup > > is > > return this.keys; > > but it should be > > return this.values; > > This typo was not caught by the compiler because each set is > also a collection. Thanks, I've got this one into CVS shortly. 2002-05-02 Xuan Baldauf <[EMAIL PROTECTED]> * java/util/TreeMap.java (SubMap.values): return this.values instead of this.keys Brian -- Brian Jones <[EMAIL PROTECTED]> ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Another bug in TreeMap
Xuan Baldauf <[EMAIL PROTECTED]> writes:
> else
> {
> // Node has 2 children. Splice is node's
> predecessor, and we swap
> // its contents into node.
> splice = node.left;
> while (splice.right != nil)
> splice = splice.right;
> child = splice.left;
> node.key = splice.key;
> node.value = splice.value;
> }
>
> // Unlink splice from the tree.
> Node parent = splice.parent;
> if (child != nil)
> child.parent = parent;
> if (parent == nil)
> {
> // Special case for 0 or 1 node remaining.
> root = child;
> return;
> }
> if (splice == parent.left)
> parent.left = child;
> else
> parent.right = child;
>
> if (splice.color == BLACK)
> deleteFixup(child, parent);
> }
>
>
> In case the node to be removed has two children, within
> removeNode(), new keys and values will be swapped into the
> node the which is about to be removed. After removeNode()
> finished, remove() returns the value variable of that node.
> Because it was changed previously within removeNode(), the
> wrong value (from the swapped in node rather than from the
> original node) is returned. This is a bug.
I'm pretty sure that without dusting off my data structures book I
couldn't patch this properly. I'm unsure what the point is of setting
the key/value of node in the else statement with that "node" being
deleted from the tree.
Brian
--
Brian Jones <[EMAIL PROTECTED]>
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Aegis VM
Hi I am the developer of the Aegis VM (aegisvm.sourceforge.net), which is a JNI-conforming C library released under LGPL. Starting from the next release, we are planning to use GNU Classpath as our class library. However, for classes that requires internal support from the VM (e.g. java.lang.Class, java.lang.ClassLoader, etc etc), we will supply our own independently developed version rather than using those from GNU Classpath. And of course this is easily done by structuring the VM's bootstrap classloading path carefully. My question is, is there any licensing complication here? We won't be packaging Classpath with our library, but merely loading it into cour VM. Is this considered "linking" with the class library, and thereby making it necessary for us to change our license to GPL? Thanks for taking time to answer the question. Thanks also for making Classpath a reality. Philip * Philip W. L. Fong * School of Computing Science * Simon Fraser University, Burnaby, B.C., Canada V5A 1S6 * [EMAIL PROTECTED] * http://www.cs.sfu.ca/~pwfong/ * (604)719-2333 ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Aegis VM
Philip Fong <[EMAIL PROTECTED]> writes: > My question is, is there any licensing complication here? We won't > be packaging Classpath with our library, but merely loading it > into cour VM. Is this considered "linking" with the class library, > and thereby making it necessary for us to change our license to > GPL? Your VM can use the LGPL if you wish. This is the license Japhar used. Brian -- Brian Jones <[EMAIL PROTECTED]> ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: Another bug in TreeMap
Yes, it is a bug. I posted the following patch (since I was responsible for this bug in the first place, several months ago): 2002-05-02 Eric Blake <[EMAIL PROTECTED]> * java/util/TreeMap.java (remove): Fix improper return value. * THANKYOU: Add Xuan Baldauf for spotting this. Index: java/util/TreeMap.java === RCS file: /cvsroot/classpath/classpath/java/util/TreeMap.java,v retrieving revision 1.19 diff -u -r1.19 TreeMap.java --- java/util/TreeMap.java 20 Feb 2002 23:56:46 - 1.19 +++ java/util/TreeMap.java 3 May 2002 04:17:37 - @@ -623,8 +623,10 @@ Node n = getNode(key); if (n == nil) return null; +// Note: removeNode can alter the contents of n, so save value now. +Object result = n.value; removeNode(n); -return n.value; +return result; } /** @@ -1768,7 +1770,7 @@ SubMap.this.clear(); } }; - return this.keys; + return this.values; } } // class SubMap } // class TreeMap By the way, Brian, you forgot to commit TreeMap, so I did it for you. Brian Jones wrote: > > Xuan Baldauf <[EMAIL PROTECTED]> writes: > > > > > In case the node to be removed has two children, within > > removeNode(), new keys and values will be swapped into the > > node the which is about to be removed. After removeNode() > > finished, remove() returns the value variable of that node. > > Because it was changed previously within removeNode(), the > > wrong value (from the swapped in node rather than from the > > original node) is returned. This is a bug. > > I'm pretty sure that without dusting off my data structures book I > couldn't patch this properly. I'm unsure what the point is of setting > the key/value of node in the else statement with that "node" being > deleted from the tree. The swap of the node contents saves effort over the additional pointer manipulation that is otherwise required, at the expense of modifying the node so that it is no longer valid in remove(). In short, the code deletes a leaf node, after moving its contents to the original node, so that the net result is deleting the contents of the original node. -- This signature intentionally left boring. Eric Blake [EMAIL PROTECTED] BYU student, free software programmer ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
orp-1.0.9
I believe the problem with using Orp 1.0.9 with classpath cvs is the
new dependencies in the tree on startup. In Orp these appear to be
handled just before with a number of preload_class method calls in
common/base/orp_init.cpp.
270 env->JavaLangString_Class = preload_class("java/lang/String");
271 env->JavaLangObject_Class = class_java_lang_Object;
272
273 env->java_lang_Throwable_Class =
274 preload_class("java/lang/Throwable");
275 env->java_lang_Error_Class =
276 preload_class("java/lang/Error");
277 env->java_lang_ExceptionInInitializerError_Class =
278 preload_class("java/lang/ExceptionInInitializerError");
279 env->java_lang_NullPointerException_Class =
280 preload_class("java/lang/NullPointerException");
281 env->java_lang_ArrayIndexOutOfBoundsException_Class =
282 preload_class("java/lang/ArrayIndexOutOfBoundsException");
283 env->java_lang_ArrayStoreException_Class =
284 preload_class("java/lang/ArrayStoreException");
285 env->java_lang_ArithmeticException_Class =
286 preload_class("java/lang/ArithmeticException");
287 env->java_lang_ClassCastException_Class =
288 preload_class("java/lang/ClassCastException");
289
290 env->java_lang_Cloneable_Class =
291 preload_class("java/lang/Cloneable");
292 env->java_lang_Thread_Class =
293 preload_class("java/lang/Thread");
294
295 env->java_util_Date_Class =
296 preload_class("java/util/Date");
297
298 env->java_lang_Runtime_Class =
299 preload_class("java/lang/Runtime");
300
301 Method *m = class_lookup_method_recursive(env->java_lang_Throwable_Class,
302 "", "()V");
303 assert(m);
304 m->set_side_effects(MSE_False);
305 m = class_lookup_method_recursive(env->java_lang_Throwable_Class,
306 "", "(Ljava/lang/String;)V");
307 assert(m);
308 m->set_side_effects(MSE_False);
309
310 // Invoke java.lang.Class constructor
311 Class *jlc = env->JavaLangClass_Class;
312 Method *java_lang_class_init = object_lookup_method(jlc, "", "()V");
313 orp_execute_java_method(java_lang_class_init, 0, jlc);
Line 313 brings about the No Java handlers found... I think some
changes to Class.java could also be causing trouble. I'd like to know
if the ORP team has already handled these changes in the JVM before
anyone else dives further into this.
Thanks,
Brian
--
Brian Jones <[EMAIL PROTECTED]>
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
