[Haskell-cafe] JVM-Bridge with Kaffe
Hello, I am attempting to package up the JVM bridge for Debian. As such, I am limited to the purely Free JVM's available within Debian. They include Kaffe, SableVM, GCJ/GIJ, and the Jikes compiler available for most of the above. I could not convince jvm-bridge's Native/configure to even see a gcj environment. Kaffe worked (after updating the include path to /usr/lib/kaffe/include). However, when I tried to start the compile: g++ -DHAVE_CONFIG_H -I. -I. -I. -I/usr/lib/kaffe/include/ -DVM_KAFFE -O3 -W -Wall -fno-rtti -g -O2 -MT JVMBridge.lo -MD -MP -MF .deps/JVMBridge.Tpo -c JVMBridge.cpp -fPIC -DPIC -o .libs/JVMBridge.o JVMBridge.cpp: In function `JNIEnv* JVMBridge_AttachCurrentThread(JavaVM*)': JVMBridge.cpp:57: error: invalid conversion from `JNIEnv**' to `void**' JVMBridge.cpp: In function `jboolean* JVMBridge_GetBooleanArrayRegion(JNIEnv*, _jobject*, int, int)': JVMBridge.cpp:239: warning: unused variable `jboolean foo' JVMBridge.cpp: In function `_jobject* JVMBridge_DefineClass(JNIEnv*, const char*, _jobject*, const jbyte*, int)': JVMBridge.cpp:1187: warning: ignoring #pragma unused JVMBridge.cpp:1188: error: no matching function for call to `_Jv_JNIEnv:: DefineClass(_jobject*, const jbyte*, jsize)' /usr/lib/kaffe/include/jni.h:498: error: candidates are: _jclass* _Jv_JNIEnv::DefineClass(const char*, _jobject*, const jbyte*, int) make[2]: *** [JVMBridge.lo] Error 1 This is jvm-bridge 0.3 and kaffe 1.1.4 (Debian version 1.1.4PRECVS6-1). Thanks, -- John Goerzen Author, Foundations of Python Network Programming http://www.amazon.com/exec/obidos/tg/detail/-/1590593715 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: library documentation
Peter Simons [EMAIL PROTECTED] writes: Isaac Jones writes: http://www.haskell.org/hawiki/LibraryDocsNeedingHelp This is a great idea. I have been thinking you know what would make contribution to the library efforts even simpler? If they were available in a Darcs repository. I can certainly understand Simon's wish to stay away from a split repository, one for GHC, one for libraries. What I'm doing for the cabal is keeping the _darcs directory in the same place as the CVS directory, and keeping them in sync by hand. This isn't too painful, if it were, I think there are some tools out there for this. Someone else suggested that someone maintain a darcs repository for the libraries and pull in documentatin changes, and then sync it all at once. I think that's a bad idea, because merging is never very easy, and is error prone. What might be good is if someone with CVS access would keep a darcs mirror of all of fptools (or just the libraries), and keep the darcs side automatically in sync w/ the CVS side (there are some tools for this). Then people could send darcs patches to this poor soul who would be sure to review them before committing them to CVS. I doubt that there would be too much traffic to handle, and if there were, then we could possibly put different people in charge of different components. Eventually, of course, everyone will realize that life would be simpler if we got rid of CVS altogether, and darcs will be mature enough to handle GHC, and we'll switch :) Saying darcs push after you've spontaneously added a ^ Probably darcs send if we're talking about letting the masses add documentation. peace, isaac ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: library documentation
On 2005-01-29, Isaac Jones [EMAIL PROTECTED] wrote: What I'm doing for the cabal is keeping the _darcs directory in the same place as the CVS directory, and keeping them in sync by hand. This isn't too painful, if it were, I think there are some tools out there for this. I'd think that would be king of painful cvsync/tailor.py might work for this purpose, but I don' think it'd like having them be in the same location -- see http://www.scannedinavian.org/DarcsWiki/ConvertingFromSubversion Despite the URL it *ought* to work with CVS too. darcs get http://nautilus.homeip.net/~lele/projects/cvsync/ Someone else suggested that someone maintain a darcs repository for the libraries and pull in documentatin changes, and then sync it all at once. I think that's a bad idea, because merging is never very easy, and is error prone. Agreed. What might be good is if someone with CVS access would keep a darcs mirror of all of fptools (or just the libraries), and keep the darcs side automatically in sync w/ the CVS side (there are some tools for this). Then people could send darcs patches to this poor soul who would be sure to review them before committing them to CVS. I doubt that there would be too much traffic to handle, and if there were, then we could possibly put different people in charge of different components. The script mentioned above will probably help with that. Eventually, of course, everyone will realize that life would be simpler if we got rid of CVS altogether, and darcs will be mature enough to handle GHC, and we'll switch :) Here's hoping. -- Aaron Denney -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: mathematical notation and functional programming
a b c which is a short-cut of a b \land b c The confusion between f(x) and x.f(x) is indeed a real bummer. OTOH I like the abc shorthand because it's both obvious and unambiguous (as long as the return value of can't be passed as an argument to , which is typically the case when the return value is boolean and there's no ordering defined on booleans). Stefan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: mathematical notation and functional programming
Stefan Monnier [EMAIL PROTECTED] writes: OTOH I like the abc shorthand because it's both obvious and unambiguous (as long as the return value of can't be passed as an argument to , which is typically the case when the return value is boolean and there's no ordering defined on booleans). It's unambiguous even if the return value of can be passed as an argument to . Operators are usually left-associative, right-associative or non-associative. A non-associative operator can have an additional semantics defined when it's used multiple times, just like a,b,c in OCaml is neither a,(b,c) nor (a,b),c, or even a*b*c as a type. -- __( Marcin Kowalczyk \__/ [EMAIL PROTECTED] ^^ http://qrnik.knm.org.pl/~qrczak/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: File path programme
The various UTF encodings do not have this particular problem; if a UTF string is valid, then it is a unique representation of a unicode string. However, decoding is still a partial function and can fail. And while it is partly true, it is qualified by the problems relative to canonicalization (an é in Unicode can both be represented as é or as two chars (an e and an accent) and they should (ideally) compare equal). Stefan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: mathematical notation and functional programming
On 2005-01-29, Stefan Monnier [EMAIL PROTECTED] wrote: a b c which is a short-cut of a b \land b c The confusion between f(x) and ?x.f(x) is indeed a real bummer. OTOH I like the abc shorthand because it's both obvious and unambiguous (as long as the return value of can't be passed as an argument to , which is typically the case when the return value is boolean and there's no ordering defined on booleans). Of course, it _is_ defined on Bools in Haskell, with True False. But see Martin's answer. -- Aaron Denney -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ocr'ed version of The implementation of functional languages
I have just embarked on creating a ocr'ed version of the jpeg images that have been made available for The implementation of functional languages. However, my ocr software is clunky at best and (not surprisingly) it is slow going. It struch me that someone else might also be hard at work doing this and that there is not point duplicating work. Is anyone else doing this? If so, how can I help? Matt ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
