Re: [kaffe] Classpath config.sub modification question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ok, the config.sub is already patched implicitly. :-) (done by the regeneration of configuration/makefiles - see mail Fix to be able to use ECJ instead of JIKES) Alex. Jim Pick wrote: Alexander Boettcher wrote: Hi Kaffe developers, I omitted in my last checkin the modifications at libraries/javalib/external/classpath/config.sub (add DROPS as OS, in order to enable cross configuration and compiling of Kaffe), because I'm unsure whether it's ok to modify this file. This classpath directory and therefore this file is an imported one. Can this cause trouble for you, if I modify it and you want to reimport changes of the classpath project later ? I'd just check it in. If you then send the patch to the upstream people (there are some intructions at the the top of the config.sub file), there shouldn't be any problems. I'm sure that Classpath can apply the patch to their config.sub too. Cheers, - Jim ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDkzNRqjRK9KYzJbMRAl0EAKCB1rptdfkWNUhetwBqX2uZ3EduxACgg1LX btoxkL4v/bnVek8BmkYQ0KY= =I2+t -END PGP SIGNATURE- ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] Classpath config.sub modification question
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Kaffe developers, I omitted in my last checkin the modifications at libraries/javalib/external/classpath/config.sub (add DROPS as OS, in order to enable cross configuration and compiling of Kaffe), because I'm unsure whether it's ok to modify this file. This classpath directory and therefore this file is an imported one. Can this cause trouble for you, if I modify it and you want to reimport changes of the classpath project later ? Thx, Alex. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDj4oXqjRK9KYzJbMRAqyCAJ9lg9akhkwhS+kBsJQKT+ymQfIoYwCgx4ws 0AnEf6RK5PRfk2PcfA1MXmo= =yffH -END PGP SIGNATURE- ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] Unofficial and experimental release of Kaffe on DROPS/L4
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, at [1] you can find a snapshot of a packet, which contains the latest working Kaffe version (without RTSJ experimental extensions) running on top of DROPS. I'm in contact with Dalibor and Jim in order to merge the DROPS/L4 port in the current cvs version of kaffe.org. However, I already got a request for Kaffe on DROPS, therefore I provide it this way for interested people until it is available from kaffe.org. The packet contains a complete snapshot of the sources of kaffe.org (October this year) and not only the port specific files, because the latest cvs version of kaffe.org doesn't build with the DROPS/L4 port :-(. Please note, the state of the port must be considered as experimental. My port specific code are licensed under GPL and I provide it with no warranty. A README is available at [2]. Best regards, Alexander Boettcher. [1] http://wwwos.inf.tu-dresden.de/~ab764283/kaffe.tar.bz2 - 8,4 MB [2] http://wwwos.inf.tu-dresden.de/~ab764283/README.drops [3] http://wwwos.inf.tu-dresden.de/~ab764283/kaffe.tar.bz2.sig -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDbfuEqjRK9KYzJbMRAu8uAJsEaafL9wEM5SWiXzxGShpNt1yjTACgm8nh Bdq8HK/t5MrU8jLsjN19PTM= =y9fd -END PGP SIGNATURE- ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[Fwd: Re: [kaffe] boehm configure problem]
---BeginMessage--- Hi Riccardo, it's the same problem I had with Kaffe on L4. Dalibor introduced --disable-boehm-gc-configuration to disable it. Bye, Alex. Riccardo wrote: Hey, is boehm always enabled now? In any case I get the following error: checking for thread model used by GCC... posix configure: error: Pthreads not supported by the GC on this platform. configure: error: /bin/sh '../../../../../kaffe/kaffe/kaffevm/boehm-gc/boehm/configure' failed for kaffe/kaffevm/boehm-gc/boehm while I used the configure line: ../kaffe/configure -C --without-classpath-gtk-awt --with-kaffe-x-awt --with-threads=unix-jthreads --with-engine=jit3 so maybe it should either disable boehm automatically...or in any case try to hnour my jthread choice in the smartest way possible... cheers, Riccardo ---End Message--- ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] configure issue
Hi Kaffe developers, the boehm-gc configure script is executed always, even though the kaffe-gc garbage collector is used. This cause for me trouble because the boehm-gc requires a pthread implementation, which we don't have (DROPS L4Env), so that the configure script aborts. The attached diff solves this by moving the boehm-gc stuff within the configure.ac to the right place (I hope). Can you please have a look at it and update the cvs ? Thx, best regards, Alex. Index: configure.ac === RCS file: /cvs/kaffe/kaffe/configure.ac,v retrieving revision 1.159 diff -u -r1.159 configure.ac --- configure.ac 7 Aug 2005 22:58:05 - 1.159 +++ configure.ac 12 Aug 2005 19:39:37 - @@ -1165,10 +1165,11 @@ esac ac_configure_args=$ac_configure_args --enable-libgc-convenience -fi -AC_CONFIG_SUBDIRS([kaffe/kaffevm/boehm-gc/boehm]) -AC_SUBST(BOEHMGC_SPECIFIC_FLAGS) + AC_CONFIG_SUBDIRS([kaffe/kaffevm/boehm-gc/boehm]) + + AC_SUBST(BOEHMGC_SPECIFIC_FLAGS) +fi AC_MSG_RESULT($GC_NAME) ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] problem using QtAWT with 1.1.5 (Gnu Linux/i686)
[EMAIL PROTECTED] schrieb: On Fri, Apr 29, 2005 at 12:50:42PM +0200, Alexander Boettcher wrote: Hi, I have some patches for the QT backend. Hi Alexander, Thanks for your patches! I have checked in CVS repository. receive events for objects (var o) from QT, that are not registered in Kaffe's backend. (I use QT 3.3.1 with Linux and a port of QT 3.3.4 with DROPS/L4). The objects seems not to be from Kaffe, seems to be from the I am a bit curious if Qt 3.3.4 already works on L4 as native C++ framework. That must be great, and do you mind if I ask for the porting issues in details? cheers, Jim Huang Hi Jim, yes, it works on DROPS/L4 as native framework. I'm not familiar with the QT port in detail, but you can read it in [3] (in german). QT on DROPS requires the graphical console [4] or DOpE [5]. L4 Kaffe [6] uses the QT port to support GUI Java application. Currently, L4 Kaffe [6] is not available, but I am willing to merge it into kaffe.org. In [1] you can find the links to our projects DROPS, the microkernel Fiasco, L4Env and L4Linux. In [2] all papers of us can be found. Regards, Alexander Boettcher. [1] http://wwwos.inf.tu-dresden.de [2] http://wwwos.inf.tu-dresden.de/project/finished/finished.xml.de [3] http://wwwos.inf.tu-dresden.de/papers_ps/weinhold-beleg.pdf [4] http://wwwos.inf.tu-dresden.de/l4env/doc/con [5] http://wwwos.inf.tu-dresden.de/dope [6] http://wwwos.inf.tu-dresden.de/papers_ps/boettcher-beleg.pdf ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] problem using QtAWT with 1.1.5 (Gnu Linux/i686)
Hi,
I have some patches for the QT backend.
gian paolo ciceri schrieb:
[EMAIL PROTECTED] example]$ /usr/local/kaffe-1.1.5-JIT-qt/bin/kaffe
-Xkaffe-qt-awt AnimatorApplication
java.lang.ArrayIndexOutOfBoundsException
~ at java.awt.ComponentEvt.getEvent (ComponentEvt.java:98)
~ at java.awt.Toolkit.evtGetNextEvent (Toolkit.java)
~ at java.awt.EventQueue.getNextEvent (EventQueue.java:174)
~ at java.awt.EventDispatchThread.run (EventDispatchThread.java:34)
~ at java.lang.VMThread.run (VMThread.java:123)
This happens also for me. The reasons seems to be, that the method
EventDispatcher::eventFilter in kaffe/libraries/clib/awt/qt/evt.cc
receive events for objects (var o) from QT, that are not registered in
Kaffe's backend. (I use QT 3.3.1 with Linux and a port of QT 3.3.4 with
DROPS/L4). The objects seems not to be from Kaffe, seems to be from the
QT internal. Therefore, the function getSourceIdx returns
0x(unsigned) or -1 (signed) for these objects, therefore later
java.awt.ComponentEvt.getEvent fails. The patch evt.diff prevents
processing these events. I don't know, whether it is ok, or it is a bug
of QT ? However, no outofbounds exception are thrown and the QT GUI
backend works.
after a while ...
QtAWT - Warning: QPainter: Internal error; no available GC
Before this message, I get :
QtAWT - Warning: QWidget (unnamed): deleted while being painted
QtAWT - Warning: QPaintDevice: Cannot destroy paint device that is being
painted
and then
QtAWT - Warning: QPainter: Internal error; no available GC
QtAWT - Warning: QPainter: Internal error; no available GC
...
If a QWidget is closed (Window, etc.), it seems that all QPainter
objects have to be closed. If not, QT complains and later fails. The
patches NativeGraphics.diff and gra.diff close the QPainter objects,
created in the function Java_java_awt_Toolkit_graInitGraphics in
kaffe/libraries/clib/awt/qt/gra.cc. With these patches, the QT backend
of Kaffe works and QT does not complain :-).
Another patch is necessary for the color defines in
kaffe/libraries/clib/awt/qt/toolkit.h. If they are used with
Java_java_awt_Toolkit_graSetXORMode in
kaffe/libraries/clib/awt/qt/gra.cc, they will produce color values
255 and QT complains :
QtAWT - Warning: QColor::setRgb: RGB parameter(s) out of range
toolkit.diff solves it.
Regards,
Alexander Boettcher.
Index: evt.cc
===
RCS file: /cvs/kaffe/kaffe/libraries/clib/awt/qt/evt.cc,v
retrieving revision 1.9
diff -u -r1.9 evt.cc
--- evt.cc 14 Jul 2004 07:08:10 - 1.9
+++ evt.cc 29 Apr 2005 09:19:43 -
@@ -98,7 +98,7 @@
EventPacket* packet = NULL;
bool processed = false;
- if(X-srcIdx == 0)
+ if(X-srcIdx == 0 || getSourceIdx(X, o) == 0x)
return QWidget::eventFilter(o, e);
switch(e-type()) {
Index: NativeGraphics.java
===
RCS file:
/cvs/kaffe/kaffe/libraries/javalib/awt-implementations/kaffe/java/awt/NativeGraphics.java,v
retrieving revision 1.1
diff -u -r1.1 NativeGraphics.java
--- NativeGraphics.java 22 Jul 2004 19:19:32 - 1.1
+++ NativeGraphics.java 29 Apr 2005 10:26:57 -
@@ -173,6 +173,11 @@
bgClr = null;
}
+if ( nativeData != null ) {
+Toolkit.graFreeGraphics( nativeData);
+nativeData = null;
+}
+
synchronized ( lock ) {
next = cache;
cache = this;
Index: gra.cc
===
RCS file: /cvs/kaffe/kaffe/libraries/clib/awt/qt/gra.cc,v
retrieving revision 1.5
diff -u -r1.5 gra.cc
--- gra.cc 14 Jul 2004 07:08:10 - 1.5
+++ gra.cc 29 Apr 2005 10:20:59 -
@@ -68,6 +68,14 @@
memset((void*)gr, 0, sizeof(Graphics));
}
+ /**
+ * Release QPainter objects of reused NativeGraphics Java objects !
+ */
+ if (gr-painter != NULL)
+ {
+delete gr-painter;
+ }
+
gr-painter = new QPainter(drw);
DBG(AWT_GRA, qqDebug(painter=%x\n, gr-painter));
Index: toolkit.h
===
RCS file: /cvs/kaffe/kaffe/libraries/clib/awt/qt/toolkit.h,v
retrieving revision 1.5
diff -u -r1.5 toolkit.h
--- toolkit.h 12 Jul 2004 10:20:53 - 1.5
+++ toolkit.h 29 Apr 2005 10:36:23 -
@@ -493,10 +493,10 @@
*/
void initColorMapping ( JNIEnv* env, jclass clazz, Toolkit* X);
-#define JRGB(_r,_g,_b) (_r16 | _g8 | _b)
-#define JRED(_rgb) ((_rgb 0xff) 16)
-#define JGREEN(_rgb)((_rgb 0x00ff00) 8)
-#define JBLUE(_rgb) (_rgb 0xff)
+#define JRGB(_r,_g,_b) ((_r)16 | (_g)8 | (_b))
+#define JRED(_rgb) (((_rgb) 0xff) 16)
+#define JGREEN(_rgb)(((_rgb) 0x00ff00) 8)
+#define JBLUE(_rgb) ((_rgb) 0xff)
/**
___
kaffe mailing list
kaffe@kaffe.org
http://kaffe.org/cgi-bin
Re: [kaffe] Awt Qt backend problems in 1.1.5.
Hi, gian paolo ciceri wrote: Hi all, I've a simple graphical application that runs fine under plain vanilla 1.1.5 (so with classpath gtk/X Awt backend). But when I run it under a kaffe built with Qt backend for Awt I take the following. Kaffe partially uses for the AWT backends different Java classes, for QT from libraries/javalib/awt-implementations/kaffe/java/awt and for the Gtk backend from libraries/javalib/java/awt. The state of implemented classes and methods differs. [EMAIL PROTECTED] DisplayButton]$ /usr/local/kaffe-1.1.5-JIT-qt/bin/kaffe - -Xkaffe-qt-awt ButtonFrame java.lang.NoSuchMethodError: java/awt/EventQueue.invokeLater(Ljava/lang/Runnable;)V ~ at ButtonFrame.main (ButtonFrame.java:185) The method is not implemented in libraries/javalib/awt-implementations/kaffe/java/awt/EventQueue.java. Maybe, a simple adaptation of this method of the gtk backend to the qt backend is possible. I'm perplexed, perhaps I've done some errors building kaffe: I used I do not think so - see the first statement. Regards, Alex. ___ kaffe mailing list kaffe@kaffe.org http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] race during thread creation and gc invocation
Hi,
i have a race condition in thread.c found which (may) causes Kaffe to
hang - for our L4 system it happens. In the function startThread in
kaffe/kaffevm/thread.c
startThread(Hjava_lang_VMThread* tid)
{ ...
nativeTid = createThread(tid, firstStartThread,
jthread_current(),
threadStackSize, info);
...
ksemGet(THREAD_DATA()-sem, (jlong)0);
linkNativeAndJavaThread (nativeTid, tid);
ksemPut(jthread_get_data(nativeTid)-sem);
}
a thread is created and later the native thread and the java object
are linked.
In the function createThread the pointer(to jthread_current()) is
saved - during the call to jthread_create - in (somewhat
jthread_t)-data.jlThread. In linkNativeAndJavaThread the pointer(
to tid) is saved in (somewhat jthread_t)-data.jlThread. This means,
different types of pointers are used in data.jlThread ... jthread* and
Hjava_lang_VMThread* .
The problem appears if between createThread and
linkNativeAndJavaThread the GarbageCollector is invoked (which
happens in my testcase sporatic). The gc calls for each thread -
during its work - liveThreadWalker in
kaffe/kaffevm/kaffe-gc/gc-refs.c, which assumes that jlThread is of
type Hjava_lang_VMThread. But the pointer between createThread and
linkNativeThread is of type jthread_t. In my case, Kaffe hangs and
does not return from KGC_markObject.
The new created thread is already listed (createThread) in the
activeThread list of the current thread implementation (i looked at
unix-pthreads unix-jthreads and it is also so for our l4thread
implementation). Therefore, the gc calls jthread_walkLiveThreads and
the function found the new created - but unready( still wrong
jthread_t pointer) - thread.
liveThreadWalker(jthread_t tid, void *private)
{
Collector *c = (Collector *)private;
threadData *thread_data = jthread_get_data(tid);
Hjava_lang_VMThread *thread = (Hjava_lang_VMThread
*)thread_data-jlThread;
printf(livethread jtid=%p unhandthread=%p
vmthread=%p\n,tid,unhand(thread)-thread,thread);
KGC_markObject(c, NULL, unhand(thread)-thread);
KGC_markObject(c, NULL, thread);
...
}
So, jlThread can not be used in this form, a other pointer would be
necessary in the threadData structure or the gc may not assume that
jlThread is of type VMThread and has to handle it.
What do you think ?
Thanks - sorry for my english,
Alexander Boettcher.
___
kaffe mailing list
[EMAIL PROTECTED]
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] more missing files
Also not in cvs are: tools/gjdoc/javalib/gnu/classpath/tools/ - StringToolkit.java gjdoc/ - InheritDocTagImpl.java - TagContainer.java Alexander Böttcher ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] ksem interface MAIN_MD
Hi, somehow the test for THREAD_SYSTEM_HAS_KSEM in ksem.c was lost during the last months. It's neccessary if an port provides its own ksem semaphore implementation. At the moment you get double defined functions. Additional, is it possible to move the declaration of the ksem* functions into the ifdef of THREAD_SYSTEM_HAS_KSEM in ksem.h ? So, it is possible to declare also inline ksem functions, if the ksem implementation of the functions is small. Please, look at the diff, it does not affect unix-pthreads or unix-jthreads, but is necessary for ports with its own ksem implementation. Another question, in the Changelog entry 2004-06-15 is described that the call to INIT_MD was removed from the kaffe/kaffe/main.c file. But in fact, the call to MAIN_MD was removed. Can we reintroduce it ? Because it's necessary for the oskit (it uses INIT_MD and MAIN_MD in different manner) and for our port. MAIN_MD was/is useful if you have to initialize some things before Kaffe becomes running. Thx, regards, Alexander Böttcher. Index: ksem.c === RCS file: /cvs/kaffe/kaffe/kaffe/kaffevm/ksem.c,v retrieving revision 1.7 diff -u -r1.7 ksem.c --- ksem.c 2 Aug 2004 10:44:56 - 1.7 +++ ksem.c 29 Sep 2004 08:35:25 - @@ -10,6 +10,8 @@ #include ksem.h +#ifndef THREAD_SYSTEM_HAS_KSEM + /* * Initialize the just-allocated Ksem. This function is only invoked * by the threading system when a new thread is allocated. @@ -86,3 +88,5 @@ jmutex_destroy((sem-mux)); jcondvar_destroy((sem-cv)); } + +#endif Index: ksem.h === RCS file: /cvs/kaffe/kaffe/kaffe/kaffevm/ksem.h,v retrieving revision 1.8 diff -u -r1.8 ksem.h --- ksem.h 20 Apr 2004 16:53:25 - 1.8 +++ ksem.h 29 Sep 2004 08:35:25 - @@ -20,11 +20,6 @@ */ struct Ksem; -extern void ksemInit(struct Ksem* sem); -extern void ksemPut(struct Ksem* sem); -extern jboolean ksemGet(struct Ksem* sem, jlong timeout); -extern void ksemDestroy(struct Ksem* sem); - /* * Include the system locking layer interface. See if it gives us * Ksem's or jmutex/jcondvar's (see FAQ.locks). @@ -44,6 +39,11 @@ */ #ifndef THREAD_SYSTEM_HAS_KSEM + extern void ksemInit(struct Ksem* sem); + extern void ksemPut(struct Ksem* sem); + extern jboolean ksemGet(struct Ksem* sem, jlong timeout); + extern void ksemDestroy(struct Ksem* sem); + /* * Present POSIX mutex+condvar as a binary semaphore. */ @@ -52,6 +52,5 @@ jcondvarcv; int count; } Ksem; - #endif /* !defined(JTHREAD_HAS_KSEM) */ #endif /* kaffevm_ksem_h */ ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] Missing ifdef in ksem.c
Hi, somehow the test for THREAD_SYSTEM_HAS_KSEM was lost during the last months. It's neccessary if an operating system provides its own ksem semaphore implementation. I attached the small diff/fix . Regards, Alexander Böttcher. Index: ksem.c === RCS file: /cvs/kaffe/kaffe/kaffe/kaffevm/ksem.c,v retrieving revision 1.7 diff -u -d -r1.7 ksem.c --- ksem.c 2 Aug 2004 10:44:56 - 1.7 +++ ksem.c 22 Sep 2004 12:04:20 - @@ -10,6 +10,8 @@ #include ksem.h +#ifndef THREAD_SYSTEM_HAS_KSEM + /* * Initialize the just-allocated Ksem. This function is only invoked * by the threading system when a new thread is allocated. @@ -86,3 +88,5 @@ jmutex_destroy((sem-mux)); jcondvar_destroy((sem-cv)); } + +#endif ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] MAIN_MD
Hi, in the Changelog entry 2004-06-15 is described that the call to INIT_MD was removed from the kaffe/kaffe/main.c file. But in fact, the call to MAIN_MD was removed. Can we reintroduce it ? Because it's necessary for the oskit (it uses INIT_MD and MAIN_MD in different manner) and for our port. Thx, Alexander Böttcher. ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
Re: [kaffe] kwrite usage
Guilhem Lavaux wrote: BTW, New ports are always really welcome for our hall of fame. ;-) So please send. :-) Regards, Guilhem Lavaux. Hi Guilhem, I hope it will be able in the near future. At the moment the configure/build process is a hyprid of the kaffe one and the build system of our DROPS. I have to investigate some time, so that it works completly with kaffes build process and works without manual modifications. Furthermore I have to merge the actual kaffe-cvs with the l4-kaffe. (additional stack range adaption - I not look for it yet). For the moment l4-kaffe runs as interpreter, uses as threading implementation/interface of our l4thread library (we don't use jthread/pthreads) and only runs on ia32. Regards, Alexander Boettcher. ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] kwrite usage
Hi,
is it useful/possible to use kwrite instead of write in the
kaffe/kaffevm/debug.c ? (see diff).
I use it when stderr(2) is not opened or another filedescriptor is used
for the output. Then the implementation of the syscall interface can
change the behavior.
I use it for Kaffe with our DROPS. Kaffe now runs as a native
application, ;-) , on our microkernel Fiasco and the L4 environment.
(http://wwwos.inf.tu-dresden.de/drops). I plan to update my cvs state
of kaffe (february) with the current one and therefore I submit this
proposal/patch, which could be useful for you (and for me ;-) ).
Thx,
Alexander Böttcher.
Index: debug.c
===
RCS file: /cvs/kaffe/kaffe/kaffe/kaffevm/debug.c,v
retrieving revision 1.55
diff -u -r1.55 debug.c
--- debug.c 2 Aug 2004 10:44:56 - 1.55
+++ debug.c 26 Aug 2004 16:26:46 -
@@ -36,6 +36,7 @@
#include gtypes.h
#include gc.h
#include debug.h
+#include jsyscall.h
/* Default debugging mask to use (if debug is enabled) */
#define DEFAULT_DEBUG_MASK DBG_NONE
@@ -388,6 +389,7 @@
int n;
int max;
va_list args;
+ ssize_t w = 0;
va_start(args, fmt);
if (!debugBuffer)
@@ -417,9 +419,10 @@
*/
max = 0;
while (max n) {
- int w = write(2,
- debugBuffer + max,
- (size_t)(n - max));
+KWRITE(2,
+ debugBuffer + max,
+ (size_t)n - max,w);
+
if (w = 0)
/* ignore errors */
max += w;
___
kaffe mailing list
[EMAIL PROTECTED]
http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
[kaffe] Question about priorities
Hi, is somewhere defined how many priorities a JVM has to provide. I didn't find something about it in the Java spec. I'm porting Kaffe to our DROPS (http://wwwos.inf.tu-dresden.de/drops) and now is the question, whether Kaffe has to use/provide exactly 10 priorities or whether more than 10 priorities are possible. Thanks, Alexander Boettcher. ___ kaffe mailing list [EMAIL PROTECTED] http://kaffe.org/cgi-bin/mailman/listinfo/kaffe
