Re: [kaffe] Planning for 1.1.2 release - XAWT obsolete?
Hi there! Nope. GNU Classpath AWT integrating should happen for the 1.1.3. Does this mean the current kaffe-xawt implementation will be thrown away? This was the best awt implemenation I´ve every seen, and I dont understand why gnu-classpath isnt based on this awt. The only problem are the ugly widget LF´s, but should be possible to make this whole thing skinable without big troubles. Sad :-( lg Clemens ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Planning for 1.1.2 release - XAWT obsolete?
Hallo Clemens, Clemens Eisserer wrote: Nope. GNU Classpath AWT integrating should happen for the 1.1.3. Does this mean the current kaffe-xawt implementation will be thrown away? I hope we'll have some way of interfacing to 'kaffe-style' AWTs from the past as well. We'll be able to see what can be done, when James and Stephane have finished their efforts to port kaffe's Qt-Awt and Xlib-Awt over to Classpath's peers. I hope we'll at least end up with some docs on migrating your peerless AWT to GNU/Kaffe [1]. The intention for kaffe's AWT is to transform it to work with Classpath's peers. It shouldn't be a problem to ship the 'old, but working' AWT alongside it, and provide a compile time selection switch --enable-old-awt that would compile the AWT libraries from different directories. This was the best awt implemenation I´ve every seen, and I dont understand why gnu-classpath isnt based on this awt. A) Incompabile licensing. Classpath is GPL + linking exception, kaffe is GPL, so Classpath can not include code from Kaffe. B) Copyright assignment. The author of kaffe's AWT, Transvirtual, doesn't exist anymore, so there is noone who can transfer their copyright to the FSF anyway. Anyway, if you want to help make the transition to Classpath easier, you're more than welcome to start looking at kaffe's and Classpath's classes and to point out where things can be taken over from Classpath already without breaking kaffe's AWT in any way. I've been doing this off and on when I carved enough time for it, but my time is unfortunately quite limited at the moment. So I'd very much appreciate any effort to enhance what we have in kaffe already by replacing more of the old code by code from Classpath where there are no negative effects. cheers, dalibor topic [1] Bad joke, I know. ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] CVS kaffe-extras (guilhem): Nested class loading fix.
PatchSet 13
Date: 2003/09/23 18:29:52
Author: guilhem
Branch: HEAD
Tag: (none)
Log:
Nested class loading fix.
When imported classes are specified using import class; KJC was not looking
for nested classes in the class. Accessibility of nested classes fixed
btw.
Members:
build.xml:1.7-1.8
patches/kjc-nested-class-loading.diff:INITIAL-1.1
Index: kaffe-extras/build.xml
diff -u kaffe-extras/build.xml:1.7 kaffe-extras/build.xml:1.8
--- kaffe-extras/build.xml:1.7 Thu Aug 14 07:15:04 2003
+++ kaffe-extras/build.xml Tue Sep 23 18:29:52 2003
@@ -242,6 +242,9 @@
patch patchfile=${patches_dir}/kjc-class-file-dir.diff
strip=1
dir=${kjcsuite_dir}/
+ patch patchfile=${patches_dir}/kjc-nested-class-loading.diff
+ strip=1
+ dir=${kjcsuite_dir}/
touch file=${kjcsuite_unpacked_stamp}/
/target
===
Checking out kaffe-extras/patches/kjc-nested-class-loading.diff
RCS: /home/cvs/kaffe/kaffe-extras/patches/kjc-nested-class-loading.diff,v
VERS: 1.1
***
--- /dev/null Sun Aug 4 19:57:58 2002
+++ kaffe-extras/patches/kjc-nested-class-loading.diff Tue Sep 23 18:29:54 2003
@@ -0,0 +1,49 @@
+--- kjc-suite-2.1B/src/kjc/CCompilationUnit.java 2002-07-15 20:53:32.0
+0200
kjc-suite-2.1B.new/src/kjc/CCompilationUnit.java 2003-09-23 19:15:25.0
+0200
+@@ -79,6 +79,26 @@
+ return cl;
+ }
+
++ // Now we must check whether the specified class is an inner class
++ // of the imported classes.
++ for (int i = 0; i importedClasses.length; i++) {
++ String qualifiedName = importedClasses[i].getQualifiedName() + '$' + name;
++
++ if (classReader.hasClassFile(qualifiedName)) {
++CClasslastClass = (CClass)loadedClasses.get(name);
++
++ if (lastClass!= null !lastClass.isAccessible(caller)) {
++ lastClass = null; // not accessible - not imported
++}
++if (lastClass != null
!lastClass.getQualifiedName().equals(qualifiedName)) {
++// Oops, the name is ambiguous (declared by more than one
import-on-demand declaration)
++throw new UnpositionedError(KjcMessages.CUNIT_RENAME2, name);
++}
++loadedClasses.put(name, classReader.loadClass(typeFactory, qualifiedName));
++importedClasses[i].setUsed();
++ }
++ }
++
+ // Otherwise, look for a type declared in another compilation unit of this
package
+ if (packageName.length() == 0) {
+ cl = classReader.hasClassFile(name) ? classReader.loadClass(typeFactory, name)
: null;
+@@ -94,7 +114,7 @@
+ // Otherwise, look for a type declared by EXACTLY ONE import-on-demand
declaration
+ for (int i = 0; i importedPackages.length; i++) {
+ StringqualifiedName;
+-
++
+ if (classReader.hasClassFile(importedPackages[i].getName())) {
+ // import on demand of enclosed classes!
+ qualifiedName = (importedPackages[i].getName() + '$' + name).intern();
+--- kjc-suite-2.1B/src/kjc/CMember.java2002-07-15 20:53:32.0 +0200
kjc-suite-2.1B.new/src/kjc/CMember.java2003-09-23 19:27:38.0 +0200
+@@ -207,7 +207,7 @@
+ return true;
+ } else if (!isPrivate() owner.getPackage() == from.getPackage()) {
+ return true;
+-} else if (isProtected() from.descendsFrom(owner)) {
++} else if (!isPrivate() from.descendsFrom(owner)) {
+ return true;
+ } else {
+ return false;
___
kaffe mailing list
[EMAIL PROTECTED]
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] unexpected java.lang.IllegalAccessError
Hi ! I have just committed a fix for KJC about loading and accessing nested classes. It doesn't fix the original IllegalAccessError but Helmer's problem. BTW, I have localized the problem which is the cause of the thrown exception in KJC. Now I have to imagine a fix ... ;-) Cheers, Guilhem. ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] Planning for 1.1.2 release - XAWT obsolete?
On Tue, 23 Sep 2003 18:47:28 +0200 Clemens Eisserer [EMAIL PROTECTED] wrote: Hi there! Nope. GNU Classpath AWT integrating should happen for the 1.1.3. Does this mean the current kaffe-xawt implementation will be thrown away? Not at all. We already support multiple AWTs -- this would just be another one, I imagine. This was the best awt implemenation I´ve every seen, and I dont understand why gnu-classpath isnt based on this awt. I think it comes down to ownership/licensing dynamics (eg. Transvirtual never transferred copyrights to the FSF for the AWT). The only problem are the ugly widget LF´s, but should be possible to make this whole thing skinable without big troubles. Yeah, the LF is definitely ugly. :-) I haven't done too much AWT stuff myself, but I think we could serve as a useful place to experiment with AWT integration since we have somewhat looser licensing constraints than other projects. Here's what I'd like to see: 1) Multiple AWT implementations a) Some using lightweight widgets, where the widgets are drawn in Java. eg: - our current X AWT - Swing (we can run Sun's old AWT based one, and should be able to run their newer Java2D based one if we get a Java2D implementation) - others, eg. Rudolph (from Wonka) The Transvirtual version of Kaffe had a lot of additional AWT work done on it. The big thing was it had a lightweight AWT that could render to a no-native-wm backend, which provided a pluggable backend for the core graphics primitives on a number of platforms (X, Linux framebuffer (using the fgl library), Wind River's UGL, GRX, MGL, Allegro). The no-native-wm backend sounds similar in concept in many ways to what Java2D does - it might make sense to move that stuff into a Java2D implementation. There is probably additional window-manager functionality that Java2D doesn't cover. Transvirtual's AWT and Swing both provide support for skins / LF's. As far as backends go, I think it would be cool to experiment with even more extreme Java-only solutions, eg. driving a framebuffer as a Java byte array, or writing a xlib completely in Java! Graphics backends are really interesting, because the challenges involved in utilizing modern graphics acceleration hardware are interesting. Things like Cairo and DirectFB on Linux, DirectX on Windows, and Quartz on Mac OS X provide use ways to get access to accelerated hardware. If we had a really good Java2D implementation, it might even be feasible to use something like WeirdX as a more flexible replacement for XFree86 to support legacy apps. :-) b) Some using native widgets. These provide tighter integration on some platforms. - Gtk - nice for Gnome desktops. There's a version of Gtk which will render to the framebuffer too. - Qt and Qt/Embedded - Win32 (for Windows) - there was a MicroWindows AWT for Kaffe based on the Win32 widgets, I think. - a Carbon based AWT for Mac OS X would be nice - Motif/Lesstif would be interesting, just because it's what Sun used in their original AWT - SWT apparently works, which works with Win32, Motif, and Gtk. It would be cool to do a SWT backend that used lightweight widgets. Note that some of these widget sets are themeable themselves, and can use multiple backends as well. eg. Qt is essentially a lightweight widget set that renders it's own widgets on the platforms it supports. Conceivably, it could even be made to use a Java2D backend. :-) 2) Compile-time switching of AWTs All these AWTs should be configurable at configure time. For embedded platforms, it's nice to be able to select only one specific AWT tuned to the target platform. Transvirtual took this to extremes with fgl, where even the color depth was chosen at configure time. 3) Run-time switching of AWTs It would be nice to be able to configure Kaffe with multiple AWTs, and have them selectable at runtime using a property. If somebody wanted to do something even more extreme, I imagine that it would be possible to create and API to enable applications to use multiple AWT implementations simultaneously. :-) Sascha Brawer is organizing a free Java AWT BOF at Linux Kongress - that should be interesting: http://www.linux-kongress.org/2003/bofs/index.html Anyways, I don't think there is a one-size-fits-all solution for graphics on Java - I'd like to keep an open mind, and hope some really nice interfaces and implementations evolve. Cheers, - Jim ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] build breakage
Really weird, I'm configuring with --enable-debug --enable-xdebugging and I'm not seing it. Could you 'cvs -qz9 update -APd' and try again, just for sure that you don't have some old sources stuck in your checkout? Or come over to the irc channel, and we can discuss this online. It works now. The only problem is I need very specific build tools to make it work. The laptop I have on my current system is barfed. So only one laptop with kaffe works. I really really hate teh build system :-( ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] build breakage
James Simmons wrote: It works now. The only problem is I need very specific build tools to make it work. The laptop I have on my current system is barfed. So only one laptop with kaffe works. I really really hate teh build system :-( At least something ... I'm glad it at least kind of works for you now. If the problem is in the building of class library, just send me a message, and I'll put a distribution online on kaffe.org/~robilad from the current sources. Distribution have the nice property that you don;t have to rebuild the class library. So if you want to play with kaffe from CVS, but class library compilation breakage prevents you from doing so, drop me an e-mail, and I'll try to help. ;) cheers, dalibor topic ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] CVS kaffe (dalibor): Fixed addrinfo related build breakage on sparc-solaris
PatchSet 4057 Date: 2003/09/23 21:44:00 Author: dalibor Branch: HEAD Tag: (none) Log: Fixed addrinfo related build breakage on sparc-solaris getaddrinfo.h didn't always redefine addrinfo away if addrinfo was declared so this lead to a compiler error on sparc-solaris 2.9 as addrinfo was suddendly defined twice Fixed by adding a new check to getaddrinfo m4 macros for struct addrinfo. Members: ChangeLog:1.1652-1.1653 aclocal.m4:1.68-1.69 configure:1.258-1.259 configure.in:1.224-1.225 sockaddrin6.m4:1.2-1.3 config/config.h.in:1.79-1.80 include/getaddrinfo.h:1.1-1.2 Index: kaffe/ChangeLog diff -u kaffe/ChangeLog:1.1652 kaffe/ChangeLog:1.1653 --- kaffe/ChangeLog:1.1652 Mon Sep 22 20:57:50 2003 +++ kaffe/ChangeLog Tue Sep 23 21:44:00 2003 @@ -1,5 +1,21 @@ 2003-09-22 Dalibor Topic [EMAIL PROTECTED] + Fix for getaddrinfo on sparc-solaris2.9 compiler breakage. + + * configure.in: + Check for struct addrinfo. + + * sockaddrin6.m4: + (AC_STRUCT_ADDRINFO) New check. + + * include/getaddrinfo.h: + Redefine addrinfo away if struct addrinfo is declared. + + * aclocal.m4, configure, config/config.h.in: + Regenerated. + +2003-09-22 Dalibor Topic [EMAIL PROTECTED] + * sockinttypes.m4: Updated to getaddrinfo-1.6.1. From the getaddrinfo docs: Index: kaffe/aclocal.m4 diff -u kaffe/aclocal.m4:1.68 kaffe/aclocal.m4:1.69 --- kaffe/aclocal.m4:1.68 Mon Sep 22 20:57:51 2003 +++ kaffe/aclocal.m4Tue Sep 23 21:44:01 2003 @@ -8272,6 +8272,81 @@ dnl * dnl * +dnl * Check for struct sockaddr_in6 +dnl * +AC_DEFUN(AC_STRUCT_SOCKADDR_IN6, +[AC_CACHE_CHECK(for struct sockaddr_in6, ac_cv_struct_sockaddr_in6, +[AC_TRY_COMPILE([ +#include sys/types.h +#include sys/socket.h +#include netinet/in.h],[ +struct sockaddr_in6 address; +], [ac_cv_struct_sockaddr_in6=yes], [ac_cv_struct_sockaddr_in6=no])]) +if test $ac_cv_struct_sockaddr_in6 = yes; then +AC_DEFINE(HAVE_STRUCT_SOCKADDR_IN6, 1, +[Define to 1 if netinet/in.h defines `struct sockaddr_in6']) +fi]) + +dnl * +dnl * Check for struct sockaddr_storage +dnl * +AC_DEFUN(AC_STRUCT_SOCKADDR_STORAGE, +[AC_CACHE_CHECK(for struct sockaddr_storage, ac_cv_struct_sockaddr_storage, +[AC_TRY_COMPILE([ +#include sys/types.h +#include sys/socket.h +#include netinet/in.h],[ +struct sockaddr_storage address; +], [ac_cv_struct_sockaddr_storage=yes], [ac_cv_struct_sockaddr_storage=no])]) +if test $ac_cv_struct_sockaddr_storage = yes; then +AC_DEFINE(HAVE_STRUCT_SOCKADDR_STORAGE, 1, +[Define to 1 if netinet/in.h defines `struct sockaddr_storage']) +fi]) + +dnl * +dnl * Check for struct addrinfo +dnl * +AC_DEFUN(AC_STRUCT_ADDRINFO, +[AC_CACHE_CHECK(for struct addrinfo, ac_cv_struct_addrinfo, +[AC_TRY_COMPILE([ +#include netdb.h],[ +struct addrinfo info; +], [ac_cv_struct_addrinfo=yes], [ac_cv_struct_addrinfo=no])]) +if test $ac_cv_struct_addrinfo = yes; then +AC_DEFINE(HAVE_STRUCT_ADDRINFO, 1, +[Define to 1 if netdb.h defines `struct addrinfo']) +fi]) + + +dnl * +dnl * Copyright (c) 2001 Motoyuki Kasahara +dnl * +dnl * Redistribution and use in source and binary forms, with or without +dnl * modification, are permitted provided that the following conditions +dnl * are met: +dnl * 1. Redistributions of source code must retain the above copyright +dnl *notice, this list of conditions and the following disclaimer. +dnl * 2. Redistributions in binary form must reproduce the above copyright +dnl *notice, this list of conditions and the following disclaimer in the +dnl *documentation and/or other materials provided with the distribution. +dnl * 3. Neither the name of the project nor the names of its contributors +dnl *may be used to endorse or promote products derived from this software +dnl *without specific prior written permission. +dnl * +dnl * THIS SOFTWARE IS PROVIDED BY THE PROJECT AND CONTRIBUTORS ``AS IS'' AND +dnl * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE +dnl * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR +dnl * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE PROJECT OR CONTRIBUTORSBE +dnl * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR +dnl * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF +dnl * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS +dnl * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN +dnl * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) +dnl * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF +dnl * THE POSSIBILITY OF SUCH DAMAGE. +dnl * + +dnl * dnl * Check for struct in6_addr dnl * AC_DEFUN(AC_STRUCT_IN6_ADDR, @@ -8332,67 +8407,6 @@ [Define to 1 if `in6addr_loopback' is declared by netinet/in.h]) fi fi]) - -dnl * -dnl * Copyright (c) 2001 Motoyuki Kasahara -dnl * -dnl *
