[kaffe] Re: jit breakage due to missing function

2003-09-25 Thread Dalibor Topic
Dalibor Topic wrote:
Hi Kiyo,

Kiyo Inaba wrote:

Hi Dalibor,

You said,

It seems that the configure script messes something up in the 
detection of getaddrinfo. I'll look into it.


And I think this is not the only problem for Solaris. At least, jni.c
shall be fixed to coexist with not only JIT3 but also JIT. The jit
version does not have function 'resetConstants'.
Am I right?


Yes, of course.

Currently the build for sparc-solaris (and all other platforms that have 
jit, but no jit3) fails because the jit engine doesn't have a function 
called resetConstants like the jit3 engine does.

What we could do would be
a) #ifdef the resetConstants call to only happen if defined TRANSLATOR 
and JIT3.
or
b) backport the resetConstants implementation to jit engine
or
c) provide a 'do-nothing' implementation of resetConstants for jit engine
or
d) separate the engine spefic bits of jni.c into jnisomething.c/h in 
engine directories.

I'd propose going with a) followed by c and d, if someone volunteers to 
do it. I could do step a) myself ;)
Step A: Done. Jit engine should build fine again (did for me on 
i386-linux). Kiyo, thanks again for pointing out it was broken!

cheers,
dalibor topic
___
kaffe mailing list
[EMAIL PROTECTED]
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe


[kaffe] CVS kaffe (dalibor): Fixed compiler warning on hppa-hpux

2003-09-25 Thread Kaffe CVS
PatchSet 4064 
Date: 2003/09/25 13:16:33
Author: dalibor
Branch: HEAD
Tag: (none) 
Log:
Fixed compiler warning on hppa-hpux

The configure checks didn't look if isinf, isnan and finite were defined
as macros, so the replacement definitions caused a warning

Members: 
ChangeLog:1.1659-1.1660 
THIRDPARTY:1.2-1.3 
configure:1.259-1.260 
configure.in:1.225-1.226 
config/config.h.in:1.80-1.81 

Index: kaffe/ChangeLog
diff -u kaffe/ChangeLog:1.1659 kaffe/ChangeLog:1.1660
--- kaffe/ChangeLog:1.1659  Thu Sep 25 10:06:13 2003
+++ kaffe/ChangeLog Thu Sep 25 13:16:33 2003
@@ -1,5 +1,17 @@
 2003-09-25  Dalibor Topic [EMAIL PROTECTED]
 
+   * configure.in:
+   Merged in ininf, isnan and finite checking code from 
+   Sablotron 1.0, licensed under MPL 1.1 and GPL.
+   
+   * THIRDPARTY:
+   Updated to reflect the inclusion of Sablotron's code.
+
+   * config/config.h.in, configure:
+   Regenerated.
+   
+2003-09-25  Dalibor Topic [EMAIL PROTECTED]
+
Fix for jit and intrp engine compilation breakage.

* kaffe/kaffevm/jni.c:
Index: kaffe/THIRDPARTY
diff -u kaffe/THIRDPARTY:1.2 kaffe/THIRDPARTY:1.3
--- kaffe/THIRDPARTY:1.2Mon Sep 22 20:57:51 2003
+++ kaffe/THIRDPARTYThu Sep 25 13:16:33 2003
@@ -67,4 +67,9 @@
 OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
 SUCH DAMAGE.
 
-At the time of writing, Kaffe uses getaddrinfo 1.6.1.
\ No newline at end of file
+At the time of writing, Kaffe uses getaddrinfo 1.6.1.
+
+* Configure.in tests for isinf, isnan, finite
+
+Taken from Sablotron 1.0, which is dually licensed licensed under MPL 1.1 
+and GPL. It is available from http://www.gingerall.cz/charlie/ga/xml/p_sab.xml
Index: kaffe/configure
diff -u kaffe/configure:1.259 kaffe/configure:1.260
--- kaffe/configure:1.259   Tue Sep 23 21:44:01 2003
+++ kaffe/configure Thu Sep 25 13:16:33 2003
@@ -39456,10 +39456,7 @@
 
 
 
-
-
-
-for ac_func in rint floor ceil finite isinf isnan strtod mergesort
+for ac_func in rint floor ceil strtod mergesort
 do
 as_ac_var=`echo ac_cv_func_$ac_func | $as_tr_sh`
 echo $as_me:$LINENO: checking for $ac_func 5
@@ -39629,6 +39626,415 @@
 
 fi
 done
+
+
+
+
+echo $as_me:$LINENO: checking for isnan 5
+echo $ECHO_N checking for isnan... $ECHO_C 6
+if test ${ac_cv_func_isnan+set} = set; then
+  echo $ECHO_N (cached) $ECHO_C 6
+else
+  cat conftest.$ac_ext _ACEOF
+#line $LINENO configure
+/* confdefs.h.  */
+_ACEOF
+cat confdefs.h conftest.$ac_ext
+cat conftest.$ac_ext _ACEOF
+/* end confdefs.h.  */
+/* System header to define __stub macros and hopefully few prototypes,
+which can conflict with char isnan (); below.
+Prefer limits.h to assert.h if __STDC__ is defined, since
+limits.h exists even on freestanding compilers.  */
+#ifdef __STDC__
+# include limits.h
+#else
+# include assert.h
+#endif
+/* Override any gcc2 internal prototype to avoid an error.  */
+#ifdef __cplusplus
+extern C
+{
+#endif
+/* We use char because int might match the return type of a gcc2
+   builtin and then its argument prototype would still apply.  */
+char isnan ();
+/* The GNU C library defines this for functions which it implements
+to always fail with ENOSYS.  Some functions are actually named
+something starting with __ and the normal name is an alias.  */
+#if defined (__stub_isnan) || defined (__stub___isnan)
+choke me
+#else
+char (*f) () = isnan;
+#endif
+#ifdef __cplusplus
+}
+#endif
+
+int
+main ()
+{
+return f != isnan;
+  ;
+  return 0;
+}
+_ACEOF
+rm -f conftest.$ac_objext conftest$ac_exeext
+if { (eval echo $as_me:$LINENO: \$ac_link\) 5
+  (eval $ac_link) 25
+  ac_status=$?
+  echo $as_me:$LINENO: \$? = $ac_status 5
+  (exit $ac_status); } 
+ { ac_try='test -s conftest$ac_exeext'
+  { (eval echo $as_me:$LINENO: \$ac_try\) 5
+  (eval $ac_try) 25
+  ac_status=$?
+  echo $as_me:$LINENO: \$? = $ac_status 5
+  (exit $ac_status); }; }; then
+  ac_cv_func_isnan=yes
+else
+  echo $as_me: failed program was: 5
+sed 's/^/| /' conftest.$ac_ext 5
+
+ac_cv_func_isnan=no
+fi
+rm -f conftest.$ac_objext conftest$ac_exeext conftest.$ac_ext
+fi
+echo $as_me:$LINENO: result: $ac_cv_func_isnan 5
+echo ${ECHO_T}$ac_cv_func_isnan 6
+if test $ac_cv_func_isnan = yes; then
+  has_isnan=1;
+cat confdefs.h \_ACEOF
+#define HAVE_ISNAN 1
+_ACEOF
+
+else
+  has_isnan=0
+fi
+
+echo $as_me:$LINENO: checking for isinf 5
+echo $ECHO_N checking for isinf... $ECHO_C 6
+if test ${ac_cv_func_isinf+set} = set; then
+  echo $ECHO_N (cached) $ECHO_C 6
+else
+  cat conftest.$ac_ext _ACEOF
+#line $LINENO configure
+/* confdefs.h.  */
+_ACEOF
+cat confdefs.h conftest.$ac_ext
+cat conftest.$ac_ext _ACEOF
+/* end confdefs.h.  */
+/* System header to define __stub macros and hopefully few prototypes,
+which can conflict with char isinf (); below.
+Prefer limits.h to assert.h if __STDC__ is defined, since
+limits.h exists even on freestanding compilers.  */
+#ifdef __STDC__

[kaffe] build failing

2003-09-25 Thread Thomas Keane








Hi,

Im getting a different error now when I try to
run make check on the latest CVS kaffe.
Running stable Debian on PA-RISC architecture. Heres
the error:



make[1]:
Entering directory `/root/kaffe/libraries/javalib'

rm
-rf lib

mkdir
lib

/bin/sh ./rebuildLib @essential.files

Compiling classes from @essential.files using
/root/kaffe/kaffe/kaffe/kaffe-bin -verbosegc -mx 256M at.dms.kjc.Main

lt-kaffe-bin:
exception.c:308: dispatchException: Assertion `!intsDisabled()' failed.

./rebuildLib: line 58: 30943
Aborted $JAVAC $VERBOSE
$JAVAC_FLAGS -d $LIBDIR $CPATH ${1+$@}

make[1]:
*** [lib/stamp] Error 134

make[1]:
Leaving directory `/root/kaffe/libraries/javalib'

make:
*** [check-recursive] Error 1



Any ideas?



Cheers,

Thomas



Thomas Keane (B.Sc.)
Research Assistant

Research Lab 1,
Department of Computer Science,
NUI Maynooth,
Maynooth,
Co. Kildare,
Ireland.

Homepage: http://www.cs.may.ie/~tkeane/

Free Distributed Computing System: http://www.cs.may.ie/distributed
Email: [EMAIL PROTECTED]










[kaffe] CVS kaffe (dalibor): Fix for multi-line string compiler breakage on parisc on gcc 3.3.1

2003-09-25 Thread Kaffe CVS
PatchSet 4065 
Date: 2003/09/25 15:18:09
Author: dalibor
Branch: HEAD
Tag: (none) 
Log:
Fix for multi-line string compiler breakage on parisc on gcc 3.3.1

Members: 
ChangeLog:1.1660-1.1661 
config/parisc/hpux/md.c:1.1-1.2 
config/parisc/linux/md.c:1.1-1.2 

Index: kaffe/ChangeLog
diff -u kaffe/ChangeLog:1.1660 kaffe/ChangeLog:1.1661
--- kaffe/ChangeLog:1.1660  Thu Sep 25 13:16:33 2003
+++ kaffe/ChangeLog Thu Sep 25 15:18:09 2003
@@ -1,5 +1,12 @@
 2003-09-25  Dalibor Topic [EMAIL PROTECTED]
 
+   * config/parisc/hpux/md.c, 
+   config/parisc/linux/md.c:
+   Changed multi-line string literals into single line
+   strings to fix compilation on gcc 3.3.1.
+   
+2003-09-25  Dalibor Topic [EMAIL PROTECTED]
+
* configure.in:
Merged in ininf, isnan and finite checking code from 
Sablotron 1.0, licensed under MPL 1.1 and GPL.
Index: kaffe/config/parisc/hpux/md.c
diff -u kaffe/config/parisc/hpux/md.c:1.1 kaffe/config/parisc/hpux/md.c:1.2
--- kaffe/config/parisc/hpux/md.c:1.1   Tue Mar 31 19:10:53 1998
+++ kaffe/config/parisc/hpux/md.c   Thu Sep 25 15:18:11 2003
@@ -9,80 +9,80 @@
  * of this file. 
  */
 
-   asm(.text
-.align 4
-.EXPORT parisc_threadswitch,ENTRY,PRIV_LEV=3,RTNVAL=GR
-parisc_threadswitch
-.PROC
-.CALLINFO FRAME=192
-.ENTRY
-ldo 192(%r30),%r30
-stw %r2,-180(0,%r30)
-stw %r2,-176(0,%r30)
-stw %r3,-172(0,%r30)
-stw %r4,-168(0,%r30)
-stw %r5,-164(0,%r30)
-stw %r6,-160(0,%r30)
-stw %r7,-156(0,%r30)
-stw %r8,-152(0,%r30)
-stw %r9,-148(0,%r30)
-stw %r10,-144(0,%r30)
-stw %r11,-140(0,%r30)
-stw %r12,-136(0,%r30)
-stw %r13,-132(0,%r30)
-stw %r14,-128(0,%r30)
-stw %r15,-124(0,%r30)
-stw %r16,-120(0,%r30)
-stw %r17,-116(0,%r30)
-stw %r18,-112(0,%r30)
-ldo -104(%r30),%r1
-fstds,ma %fr12,8(0,%r1)
-fstds,ma %fr13,8(0,%r1)
-fstds,ma %fr14,8(0,%r1)
-fstds,ma %fr15,8(0,%r1)
-fstds,ma %fr16,8(0,%r1)
-fstds,ma %fr17,8(0,%r1)
-fstds,ma %fr18,8(0,%r1)
-fstds,ma %fr19,8(0,%r1)
-fstds,ma %fr20,8(0,%r1)
-fstds,ma %fr21,8(0,%r1)
-stw %r30,0(0,%r26)
-ldw 0(0,%r25),%r30
-ldw -172(0,%r30),%r3
-ldw -168(0,%r30),%r4
-ldw -164(0,%r30),%r5
-ldw -160(0,%r30),%r6
-ldw -156(0,%r30),%r7
-ldw -152(0,%r30),%r8
-ldw -148(0,%r30),%r9
-ldw -144(0,%r30),%r10
-ldw -140(0,%r30),%r11
-ldw -136(0,%r30),%r12
-ldw -132(0,%r30),%r13
-ldw -128(0,%r30),%r14
-ldw -124(0,%r30),%r15
-ldw -120(0,%r30),%r16
-ldw -116(0,%r30),%r17
-ldw -112(0,%r30),%r18
-ldo -104(%r30),%r1
-fldds,ma 8(0,%r1),%fr12
-fldds,ma 8(0,%r1),%fr13
-fldds,ma 8(0,%r1),%fr14
-fldds,ma 8(0,%r1),%fr15
-fldds,ma 8(0,%r1),%fr16
-fldds,ma 8(0,%r1),%fr17
-fldds,ma 8(0,%r1),%fr18
-fldds,ma 8(0,%r1),%fr19
-fldds,ma 8(0,%r1),%fr20
-fldds,ma 8(0,%r1),%fr21
-ldw -180(0,%r30),%r2
-   comib, 0,%r2,__nodyncall
-nop
-ldw -176(0,%r30),%r22
-ldo -192(%r30),%r30
-b,n $$dyncall
-__nodyncall:
-bv 0(%r2)
-ldo -192(%r30),%r30
-.EXIT
-.PROCEND);
+   asm(.text \n
+.align 4 \n
+.EXPORT parisc_threadswitch,ENTRY,PRIV_LEV=3,RTNVAL=GR \n
+parisc_threadswitch \n
+.PROC \n
+.CALLINFO FRAME=192 \n
+.ENTRY \n
+ldo 192(%r30),%r30 \n
+stw %r2,-180(0,%r30) \n
+stw %r2,-176(0,%r30) \n
+stw %r3,-172(0,%r30) \n
+stw %r4,-168(0,%r30) \n
+stw %r5,-164(0,%r30) \n
+stw %r6,-160(0,%r30) \n
+stw %r7,-156(0,%r30) \n
+stw %r8,-152(0,%r30) \n
+stw %r9,-148(0,%r30) \n
+stw %r10,-144(0,%r30) \n
+stw %r11,-140(0,%r30) \n
+stw %r12,-136(0,%r30) \n
+stw %r13,-132(0,%r30) \n
+stw %r14,-128(0,%r30) \n
+stw %r15,-124(0,%r30) \n
+stw %r16,-120(0,%r30) \n
+stw %r17,-116(0,%r30) \n
+stw %r18,-112(0,%r30) \n
+ldo -104(%r30),%r1 \n
+fstds,ma %fr12,8(0,%r1) \n
+fstds,ma %fr13,8(0,%r1) \n
+fstds,ma %fr14,8(0,%r1) \n
+fstds,ma %fr15,8(0,%r1) \n
+fstds,ma %fr16,8(0,%r1) \n
+fstds,ma %fr17,8(0,%r1) \n
+fstds,ma %fr18,8(0,%r1) \n
+fstds,ma %fr19,8(0,%r1) \n
+fstds,ma %fr20,8(0,%r1) \n
+fstds,ma %fr21,8(0,%r1) \n
+stw %r30,0(0,%r26) \n
+ldw 0(0,%r25),%r30 \n
+ldw -172(0,%r30),%r3 \n
+ldw -168(0,%r30),%r4 \n
+ldw -164(0,%r30),%r5 \n
+ldw -160(0,%r30),%r6 \n
+ldw -156(0,%r30),%r7 \n
+ldw -152(0,%r30),%r8 \n
+ldw -148(0,%r30),%r9 \n
+ldw 

Re: [kaffe] build breakage

2003-09-25 Thread James Simmons

 Fixed now. Thanks!

Its working now. Right know I'm cleaning up a bunch of bugs. I hope to get 
something buildable in the next few days.



___
kaffe mailing list
[EMAIL PROTECTED]
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe


[kaffe] Classpath beans update.

2003-09-25 Thread James Simmons

Is it possible to integrate beans from GNU Classpath into Kaffe. I need it 
for Classpath AWT. 



___
kaffe mailing list
[EMAIL PROTECTED]
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe


Re: [kaffe] Classpath beans update.

2003-09-25 Thread Dalibor Topic
James Simmons wrote:
Is it possible to integrate beans from GNU Classpath into Kaffe. I need it 
for Classpath AWT. 
Sure, go ahead and merge it in (i.e. post a patch  ChangeLog). I don't 
have the time to review the classes myself at the moment (fixing the 
parisc port warning by warning), so it would be great it you could take 
a look and check if Classpath's implementation is better than kaffe's in 
all respects.

BTW, Helmer needs it for running JBoss on top of kaffe ;)

cheers,
dalibor topic
___
kaffe mailing list
[EMAIL PROTECTED]
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe


[kaffe] Fw: patches to make Jetty-4.2.12 compile

2003-09-25 Thread Jim Pick
Thanks.  I'm going to forward these to the list.

Cheers,

 - Jim

Begin forwarded message:

Date: Thu, 25 Sep 2003 16:05:39 +1000
From: Chris Forkin [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: patches to make Jetty-4.2.12 compile


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Jim,
I needed to patch java.net.HttpURLConnection and java.net.URLConnection
to be able to compile Jetty-4.2.12. The patches bring those 2 classes
up2date with JDK 1.4. I'm not sure who to send this stuff to and therefore
sent it to you.
Regards, Chris.
- -- 
////
// Email:  [EMAIL PROTECTED] WWW:  http://www.forkin.com/  //
// PGP:http://www.forkin.com/pgpkeys/[EMAIL PROTECTED] //
// Postal: P.O.Box 106, BEROWRA HEIGHTS, NSW 2082, Australia  //
////
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (FreeBSD)

iD8DBQE/coW4AOIWT6aArssRAljQAJ40CxgqlfPFJYXJ9kgQFc4dTe/bKQCgkaan
hToosAiI364AfPYvMxpsIHQ=
=zcSL
-END PGP SIGNATURE-

*** libraries/javalib/java/net/URLConnection.java.orig	Fri Jul 18 22:51:33 2003
--- libraries/javalib/java/net/URLConnection.java	Thu Sep 25 15:52:21 2003
***
*** 247,252 
--- 247,263 
  	requestProperties.add( value );
  }
  
+ public void addRequestProperty(String key, String value) {
+ 	if ( key == null )
+ 		throw new NullPointerException(key is null);
+ 
+ 	int pos = requestProperties.indexOf( key );
+ 	if (pos  0) {
+ 		requestProperties.add( key );
+ 		requestProperties.add( value );
+ 	}
+ }
+ 
  public void setUseCaches(boolean usecaches) {
  	useCaches = usecaches;
  }

*** libraries/javalib/java/net/HttpURLConnection.java.orig	Fri Jul 18 22:51:33 2003
--- libraries/javalib/java/net/HttpURLConnection.java	Thu Sep 25 15:52:21 2003
***
*** 11,16 
--- 11,17 
  package java.net;
  
  import java.io.IOException;
+ import java.io.InputStream;
  
  abstract public class HttpURLConnection extends URLConnection {
  
***
*** 54,59 
--- 55,61 
  public static final int HTTP_VERSION = 505;
  
  static private boolean followRedirects = true;
+ private boolean instanceFollowRedirects = true;
  
  protected String method = GET;
  protected int responseCode;
***
*** 75,80 
--- 77,90 
 followRedirects = follow;
  }
  
+ public boolean getInstanceFollowRedirects () {
+ return instanceFollowRedirects;
+ }
+ 
+ public void setInstanceFollowRedirects (boolean follow) {
+instanceFollowRedirects = follow;
+ }
+ 
  public String getRequestMethod () {
  return method;
  }
***
*** 98,103 
--- 108,117 
  		throw new ProtocolException(bad request message:  + message);
  	}
  	method = message;
+ }
+ 
+ public InputStream getErrorStream() {
+ 	return null;
  }
  
  public abstract void disconnect ();



Re: [kaffe] Kaffe and gjdoc

2003-09-25 Thread Dalibor Topic
Arnaud Vandyck wrote:
Hi everybody,

[I do Cc: classpath because I'm not on cp-tools but someone can maybe forward]

The good news:
--
kaffe can run ant and build something (but maybe everyone already know! ;))

The bad news:
-
gjdoc from cvs is broken because of java.util.jar.JarFile.OPEN_READ. 
Salut Arnaud,

thanks for your bug report, it's fixed in kaffe's CVS now. I've merged 
in the fields from GNU Classpath. Could you give gjdoc on kaffe another 
spin?

cheers,
dalibor topic


___
kaffe mailing list
[EMAIL PROTECTED]
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe


[kaffe] Re: dotnet platform support / gnu config.sub (long)

2003-09-25 Thread Guido Draheim


Dalibor Topic wrote:
Guido Draheim wrote:

For the java machine, the term `jvm` is used universally. I do not
remember there were any dependency on pointer lengths, it runs in
managed mode always.


JVM, JDK, Java, etc. are all trade marks with associated conditions of 
use. http://www.sun.com/suntrademarks/#J . Are you sure you want/need to 
use them?
Yes. Actually, if the target is a java'ish machine then they will have to
take care of any of that legalese themselves. The config.sub thing is not
a java'ish thing itself here. - Furthermore, the use context is obviously
talking about compatiblity with a certain vm type and not identity, as
expressed in a lot of corners and we know that config.sub simply trying to
get a canonic variant of certain arguments given. jvm, java and similar
names _are_ the canonic variant of anything quite like it but not
the product (trademark!) itself.
That however points out a mistake in my attemps - it should not call for
sun as a default vendor vor any of the java lookalike targets. Still we
need to have some canonic name that software type, simply that it can
be used to autoconf'igure addon software.

Since ilvm64 may be run on a 32bit system, we do set the two
cpu/vm types of ilvm and ilvm32 for the dotnet binaries
and libraries. Alongside we use jvm for jar binaries


A virtual machine capable of executing programs written in java 
programing language usually executes only classes stored in class files. 
Some virtual machines also have the capability of executing programs 
stored in zip archives, or jar archives. So 'jvm' is a misleading term 
here.
The jvm is in the place of the processor, the packaging format
would be indicated in the last part around the OS-KERNEL type. That's
established use for other OS/EXE variants as well. My previous mail
was trying to indicate that strongly and differentiate between an
executable segment (jvm) and packaging exe format (jar) that can be
started by an interpreter (java). Sorry if it was not _that_ clear.

Therefore, for jvm we do usually paste 'java' as interpreter and
'jdk' as basic service series. Likewise the dotnet binaries are
given as 'ilrun' for the interpreter and 'mono' for the service
series (or something alike).


Not all java interpreters are called 'java'. there is gij, sablevm, 
kaffe, wonka, and a ton of others, that don't necessarily fit into this 
naming scheme. While some of them provide java-named wrapper scripts, 
I'm not sure if all of them do.
Correct. There may be no `java` (lowercased) wrapper script. However,
I expect that an autoconf script will detect a shellvar $JAVA to point
to it with the help of an ac_check_tool test. That test may include
other java wrapper names as tools to test for - probably testing for
a `java` wrapper first. That's why the canonic name is `java`, note
that the config.sub canonic name is always lowercase, unlike the
common form of a shellvar to point to a wrapper script.

jvm-sun-java-jdk
jvm-sun-java-j2me
jvm-sun-java-j2se
jvm-sun-java-j2ee


uh, what's that sun doing there? ;) what's the difference between 
jvm-sun-java-jdk and jvm-sun-java-j2se supposed to be? and so on ...

I believe it would be better if you got in touch with kaffe, gcj, 
sablevm, classpath, debian-java etc. developers before you try to push 
something as big as this through as some kind of a GNU convention. I 
don't know much about .net yet, and being a kaffe developer, I'm more 
focussed on the java side of things. AFAIK, similar definitions have 
been tried before on debian-java, and failed.

On the other hand, if the virtual machine implementors of varios GNU 
projects have already been consulted, and this is the concensual 
proposal, I'd like to have the reference to the mailing list threads ;) 
If that's not happended, then let's discuss this first, as it's a good 
idea, but it needs to be discussed in a broader, more realted audience, 
than the libtool mailing list, which, sincerely, doesn't seem like a 
good pick to debate the finer details of naming vm systems. ;)

No, I've been trying to get a decent cc list for dotnet targets as it is
a platform target that can have C/C++ source code as input - IOW a target
that can be different than the primary target of that software. That's not
the same for java. - I was including java (and python) in the description in
an attempt to establish guidelines for (any) other VM-type target platforms.
Note that dotgnu has a compiler that can output an ilrun binary with a
jvm executable segment. They call the target -mjvm. The gcc has references
to java as well, lot's of them really. Surely one can have F/U/D about the
usage of java/jvm trademark stuff but I expect them invalid in this context
where we speak about a canonic name for a family of platforms, not any
product specifically. Creating a java compatible product however would need
to care about the trademark stuff, but here we do not have this case.
I'll update that patch and to erase the reference to 'sun' 

Re: [kaffe] Re: dotnet platform support / gnu config.sub (long)

2003-09-25 Thread Stephen Crawley

[EMAIL PROTECTED] said:
 Sun has a lot of lawyers, and they've been pretty aggressive than most
 about staking their claims on the linguistic turf (so they can sell it
 off).

That's a rather twisted interpretation of Sun's use of trademarks, IMO.
Another way of interpreting this is that Sun is trying to ensure
that third-party Java vendors don't destroy Java's reputation for
platform independence by shipping incompatible implementations.  This
is a good thing for everyone ... apart from unscrupulous vendors like
Microsoft.

 Because they claim Java Compatible(tm) as a trademark, it makes it
 hard to use a normal noun+verb sentence to say that we're compatible
 with Java -- we are, by most dictionary definitions, but we're not
 Java Compatible(tm), under Trademark law.  Maybe we can say that
 we're interoperable?  :-) 

A dictionary definition of compatible is useless to users of our
software because it is too vague.  We cannot plausibly claim our
software to be compatible in all respects with Sun's Java.  So any
claim of compatibility must be qualified in some way to be meaningful.  

By trademarking Java Compatible, and restricting its use to
implementations that pass the JCK tests, Sun is doing users of Java a
big favor.  It prevents shonky vendors from tricking end users with
misleading claims of Java compatibility.

IMO, the only point against Sun is their unwillingness to make the JCKs
available under conditions that don't exclude typical Open Source java
projects.

-- Steve


___
kaffe mailing list
[EMAIL PROTECTED]
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe


Re: [kaffe] Re: dotnet platform support / gnu config.sub (long)

2003-09-25 Thread Andrew Haley
Stephen Crawley writes:
  
  [EMAIL PROTECTED] said:
   Sun has a lot of lawyers, and they've been pretty aggressive than most
   about staking their claims on the linguistic turf (so they can sell it
   off).
  
  That's a rather twisted interpretation of Sun's use of trademarks, IMO.
  Another way of interpreting this is that Sun is trying to ensure
  that third-party Java vendors don't destroy Java's reputation for
  platform independence by shipping incompatible implementations.

It doesn't matter what their motivation is.  What we do know is that
we can't call our system Java.  Instead we have to call it something
like The GNU Compiler for the Java[tm] Programming Language.  As
long as we stick to that, we're OK.

It's useful for us to know that JVM is a trademark so we may not use
it for our own work.

  This is a good thing for everyone ... apart from unscrupulous
  vendors like Microsoft.
  
   Because they claim Java Compatible(tm) as a trademark, it makes it
   hard to use a normal noun+verb sentence to say that we're compatible
   with Java -- we are, by most dictionary definitions, but we're not
   Java Compatible(tm), under Trademark law.  Maybe we can say that
   we're interoperable?  :-) 
  
  A dictionary definition of compatible is useless to users of our
  software because it is too vague.  We cannot plausibly claim our
  software to be compatible in all respects with Sun's Java.  So any
  claim of compatibility must be qualified in some way to be meaningful.  

Yes.

  By trademarking Java Compatible, and restricting its use to
  implementations that pass the JCK tests, Sun is doing users of Java a
  big favor.  It prevents shonky vendors from tricking end users with
  misleading claims of Java compatibility.

All that we have to know is what we may and may not do.  And that
seems to be quite well-defined.

Andrew.

___
kaffe mailing list
[EMAIL PROTECTED]
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe


[kaffe] Re: dotnet platform support / gnu config.sub (long)

2003-09-25 Thread Guido Draheim


Dalibor Topic wrote:
Guido Draheim wrote:



Dalibor Topic wrote:

Guido Draheim wrote:

For the java machine, the term `jvm` is used universally. I do not
remember there were any dependency on pointer lengths, it runs in
managed mode always.




JVM, JDK, Java, etc. are all trade marks with associated conditions 
of use. http://www.sun.com/suntrademarks/#J . Are you sure you 
want/need to use them?


Yes. Actually, if the target is a java'ish machine then they will have to
take care of any of that legalese themselves. The config.sub thing is not
a java'ish thing itself here. - Furthermore, the use context is obviously
talking about compatiblity with a certain vm type and not identity, as
expressed in a lot of corners and we know that config.sub simply 
trying to
get a canonic variant of certain arguments given. jvm, java and similar
names _are_ the canonic variant of anything quite like it but not
the product (trademark!) itself.


AFAIK sun has quite strict rules about claiming compatibility with any 
of their Java products. Basically, you can't do it, unless you shell out 
big bucks for a license to their code. But I may misunderstand what you 
want to say.
Exactly that - there is no product here. It's a different thing whether
addon software wants to be compilable for java licenced only or
even java lookalikes. The difference is often not important during
compiling (of source), it may only be interesting during advertising
of a product (the binary).

No, I've been trying to get a decent cc list for dotnet targets as it is
a platform target that can have C/C++ source code as input - IOW a target
that can be different than the primary target of that software. That's 
not
the same for java. - I was including java (and python) in the 
description in
an attempt to establish guidelines for (any) other VM-type target 
platforms.


It's just that all those java'ish runtimes are all somehow different in 
my experience, so trying to put some kind of 'it's all mutually 
compatible java' cover on it doesn't really fit. A 'abstract 
machine'-'runtime' mapping only works as long as there are only a few 
runtimes available. In java's case, those days are long gone, and the 
number of options is quite huge, so fitting all of them under the same 
cap is quite complicated, if not impossible. I assume that in few years, 
c# will have the similar problem ;)

*LOL* there are so many i*86 compatibles, and we still put them
under the same umbrella for autoconf'iguring software. You know, here
we speak about addon software that wants to configure itself to the
_specifics_ of a _platform_. It is not important how many derivatives
are there, or even lookalikes, - however for the task of getting at
the specifics, and well, we _need_ a general guideline of the platform
family in which we want to test for specifics.


___
kaffe mailing list
[EMAIL PROTECTED]
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe