On Thu, 2002-03-07 at 07:05, Gustavo Niemeyer wrote: > Please, notice I've suggested a "long", not an "int". But the way it is > returned is not important. The real problem is classifying it as a > string. A C string is '\0' terminated. Calling it a string may suggest > to high level interfaces that it should be accessed as a real string, > and crash the application. In the Java Native Interface, there is a function for translating a null-terminated C string to a Java string. It is also possible to construct a Java byte array and fill it with all of the characters in the C string, up to the null terminator, which should probably be dropped. Then some Java code can translate this byte array into a Java string in more sophisticated ways (for instance, you can specify the character encoding this way). In either case, that isn't a problem for me. > As a side note, I'd like to share my enthusiasm. Yesterday I've worked > in the thread support. It's working perfectly! This means one will be > able to use the native python threading support just like if it was a > real interpreter. Each module, and the interactive interpreter as well, > has it's own interpreter state, so one may have multiple threads running > for each loaded module, and in the interactive interpreter. The > interactive console is already working. Any text typed into a > ">>python<<" query (which may be conveniently opened by a "/py console" > command) will be considered a python command, and will be processed by > the interactive interpreter in its own environment. Running something > like "/py exec <python statement>" is another way of talking to the > interactive interpreter. Unloading of individual modules is working > just fine, including unhooking of callbacks for that specific module. Uh... I've been using native threads in my Java code for quite some time now, on X-Chat 1.8.x. I put in accesses to X-Chat functions and data in a queue which is run several times per second in the main X-Chat thread. The calling thread is blocked until the queue item is handled, at which point the appropriate value is returned and the thread continues doing its thing. This scheme does incur some latency, particularly because I only run a maximum of 4 queue events per cycle (to prevent Java code from freezing up X-Chat), but it works quite well nonetheless. It was very easy to implement, too, since Java already provides almost all of the necessary functionality anyway. I suggest you consider using such a queue for your thread support, if X-Chat still isn't thread-safe, to avoid any synchronization problems. Regards, Alex. -- PGP Public Key: http://aoi.dyndns.org/~alex/pgp-public-key -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS d- s:++ a18 C++(++++)>$ UL+++(++++) P--- L+++>++++ E---- W+(+++) N- o-- K+ w--- !O M(+) V-- PS+++ PE-- Y+ PGP+(+++) t* 5-- X-- R tv b- DI D+++ G e h! !r y ------END GEEK CODE BLOCK------
This is a digitally signed message part