jvm-bridge-devel Mailing List for Java VM Bridge for Functional Languages
Status: Beta
Brought to you by:
ashley-y
Menu
▾
▴
jvm-bridge-devel
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
(5) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(4) |
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
(1) |
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(15) |
| 2007 |
Jan
(5) |
Feb
(3) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Artem Gr <ar...@bi...> - 2007-02-26 14:02:51
|
I've found that: http://sourceforge.net/forum/forum.php?forum_id=591372 "A recent kernel exploit was released that allowed a non admin user to escalate privileges on the host pr-shell1. We urge all users who frequent this host to change their password immediately and check their project group space for any tampering. As a precaution, we have blocked access to all project resources by password until the user resets their password. After the password has been reset, project resources should be accessible within 5 minutes." But I've changed my password at http://sourceforge.net/account/ and after a long period of waiting still can't login. I've also tried to login using the public key, with no success either. Ashley Yakeley wrote: > On Feb 20, 2007, at 11:14, Artem Gr wrote: > >> I've tried to compile the current version (under FreeBSD 6.1) and run >> into linking problems with "haskell-jvm-bridge/javavm-typed". > > Go to javavm-interface/Native, and run "make check". There's no > Haskell dependency in that directory, so that will be a clue. > > Also I can't seem to ssh to sourceforge anymore. Maybe we should move > the repository to darcs.haskell.org. > > --Ashley Yakeley > > > > |
|
From: Ashley Y. <as...@se...> - 2007-02-23 10:30:36
|
On Feb 20, 2007, at 11:14, Artem Gr wrote: > I've tried to compile the current version (under FreeBSD 6.1) and > run into linking problems with "haskell-jvm-bridge/javavm-typed". Go to javavm-interface/Native, and run "make check". There's no Haskell dependency in that directory, so that will be a clue. Also I can't seem to ssh to sourceforge anymore. Maybe we should move the repository to darcs.haskell.org. -- Ashley Yakeley |
|
From: Artem Gr <ar...@bi...> - 2007-02-20 19:14:49
|
I've tried to compile the current version (under FreeBSD 6.1) and run into linking problems with "haskell-jvm-bridge/javavm-typed". 8<--------------------------------------------------------->8 Linking dist/build/ShowClasses/ShowClasses ... /usr/local/diablo-jdk1.5.0/jre/lib/i386/client//libjvm.so: undefined reference to `pthread_attr_destroy' /usr/local/diablo-jdk1.5.0/jre/lib/i386/client//libjvm.so: undefined reference to `pthread_attr_getstacksize' /usr/local/diablo-jdk1.5.0/jre/lib/i386/client//libjvm.so: undefined reference to `pthread_create' /usr/local/diablo-jdk1.5.0/jre/lib/i386/client//libjvm.so: undefined reference to `pthread_attr_init' /usr/local/diablo-jdk1.5.0/jre/lib/i386/client//libjvm.so: undefined reference to `pthread_exit' /usr/local/diablo-jdk1.5.0/jre/lib/i386/client//libjvm.so: undefined reference to `pthread_attr_getstackaddr' /usr/local/diablo-jdk1.5.0/jre/lib/i386/client//libjvm.so: undefined reference to `pthread_resume_np' /usr/local/diablo-jdk1.5.0/jre/lib/i386/client//libjvm.so: undefined reference to `pthread_kill' /usr/local/diablo-jdk1.5.0/jre/lib/i386/client//libjvm.so: undefined reference to `pthread_attr_setstacksize' /usr/local/diablo-jdk1.5.0/jre/lib/i386/client//libjvm.so: undefined reference to `pthread_attr_get_np' /usr/local/diablo-jdk1.5.0/jre/lib/i386/client//libjvm.so: undefined reference to `pthread_attr_setcreatesuspend_np' /usr/local/diablo-jdk1.5.0/jre/lib/i386/client//libjvm.so: undefined reference to `pthread_setprio' /usr/local/diablo-jdk1.5.0/jre/lib/i386/client//libjvm.so: undefined reference to `pthread_getprio' /usr/lib/jvm-bridge/lib/libJVMBridge.so: undefined reference to `JVMBridge_FreeFunction' /usr/local/diablo-jdk1.5.0/jre/lib/i386/client//libjvm.so: undefined reference to `pthread_attr_setdetachstate' /usr/local/diablo-jdk1.5.0/jre/lib/i386/client//libjvm.so: undefined reference to `pthread_suspend_np' /usr/local/diablo-jdk1.5.0/jre/lib/i386/client//libjvm.so: undefined reference to `pthread_cond_timedwait' *** Error code 1 8<--------------------------------------------------------->8 and after adding 8<--------------------------------------------------------->8 ld-options: -threaded -package javavm -package javavm-interface 8<--------------------------------------------------------->8 into "cabal.m4", still 8<--------------------------------------------------------->8 Linking dist/build/ShowClasses/ShowClasses ... /usr/lib/jvm-bridge/lib/libJVMBridge.so: undefined reference to `JVMBridge_FreeFunction' *** Error code 1 8<--------------------------------------------------------->8 That's strange, since linking command (revealed by adding "-v" into before-mentioned "ld-options") 8<--------------------------------------------------------->8 cc -v -o dist/build/ShowClasses/ShowClasses -DDONT_WANT_WIN32_DLL_SUPPORT dist/build/ShowClasses/ShowClasses-tmp/Main.o dist/build/ShowClasses/ShowClasses-tmp/Foreign/JavaVM/Typed.o dist/build/ShowClasses/ShowClasses-tmp/Foreign/JavaVM/Typed/Monad.o dist/build/ShowClasses/ShowClasses-tmp/Foreign/JavaVM/Typed/Class.o dist/build/ShowClasses/ShowClasses-tmp/Foreign/JavaVM/Typed/Reference.o dist/build/ShowClasses/ShowClasses-tmp/Foreign/JavaVM/Typed/Returnable.o dist/build/ShowClasses/ShowClasses-tmp/Foreign/JavaVM/Typed/Value.o dist/build/ShowClasses/ShowClasses-tmp/Foreign/JavaVM/Typed/ArgumentList.o dist/build/ShowClasses/ShowClasses-tmp/Foreign/JavaVM/Typed/Object.o dist/build/ShowClasses/ShowClasses-tmp/Foreign/JavaVM/Typed/Throwable.o dist/build/ShowClasses/ShowClasses-tmp/Foreign/JavaVM/Typed/Tuple.o dist/build/ShowClasses/ShowClasses-tmp/Foreign/JavaVM/Typed/String.o dist/build/ShowClasses/ShowClasses-tmp/Foreign/JavaVM/Typed/Array.o dist/build/ShowClasses/ShowClasses-tmp/Foreign/JavaVM/Typed/ListArray.o dist/build/ShowClasses/ShowClasses-tmp/Foreign/JavaVM/Typed/Field.o dist/build/ShowClasses/ShowClasses-tmp/Foreign/JavaVM/Typed/Method.o dist/build/ShowClasses/ShowClasses-tmp/Foreign/JavaVM/Typed/NewObject.o dist/build/ShowClasses/ShowClasses-tmp/Foreign/JavaVM/Typed/Thread.o dist/build/ShowClasses/ShowClasses-tmp/Foreign/JavaVM/Typed/Callback.o dist/build/ShowClasses/ShowClasses-tmp/Foreign/JavaVM/Typed/Primitive.o dist/build/ShowClasses/ShowClasses-tmp/Foreign/JavaVM/Typed/Invocation.o dist/build/ShowClasses/ShowClasses-tmp/Foreign/JavaVM/Monad.o dist/build/ShowClasses/ShowClasses-tmp/Foreign/JavaVM/Monad/Loadable.o dist/build/ShowClasses/ShowClasses-tmp/Foreign/JavaVM/Monad/Boot.o dist/build/ShowClasses/ShowClasses-tmp/Foreign/JavaVM/Monad/Standard.o dist/build/ShowClasses/ShowClasses-tmp/Foreign/JavaVM/Monad/User.o -lthr -L/usr/local/lib/javavm-interface-1.0/ghc-6.6 -L/usr/lib/jvm-bridge/lib -L/usr/local/lib/javavm-1.0/ghc-6.6 -L/usr/local/lib/ghc-6.6 -lHSjavavm-interface-1.0 -lJVMBridge -lJVMInvocation -L/usr/local/diablo-jdk1.5.0/jre/lib/i386/ -L/usr/local/diablo-jdk1.5.0/jre/lib/i386/client/ -ljava -ljvm -lverify -lHSjavavm-1.0 -lHSbase -lHSbase_cbits -lHSrts_thr -lm -lgmp -u base_GHCziBase_Izh_static_info -u base_GHCziBase_Czh_static_info -u base_GHCziFloat_Fzh_static_info -u base_GHCziFloat_Dzh_static_info -u base_GHCziPtr_Ptr_static_info -u base_GHCziWord_Wzh_static_info -u base_GHCziInt_I8zh_static_info -u base_GHCziInt_I16zh_static_info -u base_GHCziInt_I32zh_static_info -u base_GHCziInt_I64zh_static_info -u base_GHCziWord_W8zh_static_info -u base_GHCziWord_W16zh_static_info -u base_GHCziWord_W32zh_static_info -u base_GHCziWord_W64zh_static_info -u base_GHCziStable_StablePtr_static_info -u base_GHCziBase_Izh_con_info -u base_GHCziBase_Czh_con_info -u base_GHCziFloat_Fzh_con_info -u base_GHCziFloat_Dzh_con_info -u base_GHCziPtr_Ptr_con_info -u base_GHCziPtr_FunPtr_con_info -u base_GHCziStable_StablePtr_con_info -u base_GHCziBase_False_closure -u base_GHCziBase_True_closure -u base_GHCziPack_unpackCString_closure -u base_GHCziIOBase_stackOverflow_closure -u base_GHCziIOBase_heapOverflow_closure -u base_GHCziIOBase_NonTermination_closure -u base_GHCziIOBase_BlockedOnDeadMVar_closure -u base_GHCziIOBase_BlockedIndefinitely_closure -u base_GHCziIOBase_Deadlock_closure -u base_GHCziIOBase_NestedAtomically_closure -u base_GHCziWeak_runFinalizzerBatch_closure -L/usr/local/lib -u base_GHCziConc_ensureIOManagerIsRunning_closure 8<--------------------------------------------------------->8 contains the -lHSjavavm-interface-1.0, where JVMBridge_FreeFunction seems to be present... Ashley Yakeley wrote: > I've done some work towards getting it working with 6.6, which I've > pushed up. I don't think it's quite finished, though. > > --Ashley Yakeley |
|
From: Artem Gr <ar...@bi...> - 2007-01-05 16:10:55
|
I've discovered "the hard way" that JVM-Bridge is unstable under a modern kernel-level threading library. Fortunately, this is a known problem, one of my own C++ programs is unstable in a similar way too, so i knew about the "libmap.conf" trick, and indeed, it works. My JDBC program - "convertor" - keeps failing with mysterious Java errors, like NullPointerException and OutOfMemory, until i add [convertor] libthr.so.2 libc_r.so.6 to /etc/libmap.conf (this is on FreeBSD). Then everything runs smooth. I suspect the same problem might arise under NPTL. Artem Gr wrote: > FYI, the latest version of my JDBC module can be obtained via > darcs get http://glim.ru/open/haskell-jdbc/ > Documentation available at > http://glim.ru/open/haskell-jdbc/html/JDBC.html |
|
From: Ashley Y. <as...@se...> - 2007-01-03 09:47:30
|
On Jan 2, 2007, at 02:32, Artem Gr wrote: > I've downloaded the static binary from > http://evan.martin.googlepages.com/home > Stripped it, upx-ed, and've put it into the /home/groups/j/jv/jvm- > bridge/. > It have 1mb in size. Thanks. I've done some work towards getting it working with 6.6, which I've pushed up. I don't think it's quite finished, though. -- Ashley Yakeley |
|
From: Artem Gr <ar...@bi...> - 2007-01-02 10:33:03
|
The darcs executable i've placed to the /home/groups/j/jv/jvm-bridge/ wasn't, in fact, working: [artemgr@sc8-pr-shell1 jvm-bridge]$ ./darcs ./darcs: error while loading shared libraries: libcurl.so.3: cannot open shared object file: No such file or directory I've downloaded the static binary from http://evan.martin.googlepages.com/home Stripped it, upx-ed, and've put it into the /home/groups/j/jv/jvm-bridge/. It have 1mb in size. Also, the export PATH=$PATH:/home/groups/j/jv/jvm-bridge line must be put into ".bashrc", not ".bash_profile". And it works: 8<------------------------------------------------------------------------------->8 root@localhost:~/work/java-bridge/open/haskell-jvm-bridge/# SSH_PORT=22 darcs push ar...@ss...:/home/groups/j/jv/jvm-bridge/htdocs/haskell-jvm-bridge/ Pushing to "ar...@ss...:/home/groups/j/jv/jvm-bridge/htdocs/haskell-jvm-bridge/"... Tue Jan 2 13:18:43 MSK 2007 ArtemGr <ar...@bi...> * test Shall I push this patch? (1/1) [ynWvpxqadjk], or ? for help: y Finished applying... 8<------------------------------------------------------------------------------->8 Also, on the server: 8<------------------------------------------------------------------------------->8 [artemgr@sc8-pr-shell1 haskell-jvm-bridge]$ darcs unrecord Tue Jan 2 02:18:43 PST 2007 ArtemGr <ar...@bi...> * test Shall I unrecord this patch? (1/4) [ynWvpxqadjk], or ? for help: y Wed Dec 20 04:57:51 PST 2006 ArtemGr <ar...@bi...> * FreeBSD support. Shall I unrecord this patch? (2/4) [ynWvpxqadjk], or ? for help: n Thu Dec 14 07:02:39 PST 2006 ArtemGr <ar...@bi...> * Patches for ghc-6.4.2 Shall I unrecord this patch? (3/4) [ynWvpxqadjk], or ? for help: n Finished unrecording. 8<------------------------------------------------------------------------------->8 Artem Gr wrote: > We can place the darcs binary into the project directory. Stripped and > upx-ed it's only 716 kb. > I did this: > scp -P 22 darcs ar...@ss...:/home/groups/j/jv/jvm-bridge/ > then placed > export PATH=$PATH:/home/groups/j/jv/jvm-bridge > to the end of my .bash_profile > Then i did: > SSH_PORT=22 darcs pull -v > ar...@ss...:/home/groups/j/jv/jvm-bridge/htdocs/haskell-jvm-bridge/ > > and it works! > > Ashley Yakeley wrote: >> On Dec 22, 2006, at 05:15, Artem Gr wrote: >> >>> All right, the GHC-6.6-only variant should be easier to do. >>> >>> BTW, here are the GHC-6.4 release and the darcs repository: >>> http://jvm-bridge.sourceforge.net/ >> >> How can I push patches to the darcs repository? SF doesn't have darcs >> installed, and installing it in my own space will fill up my quota. >> >> --Ashley Yakeley > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > ------------------------------------------------------------------------ > > _______________________________________________ > JVM-Bridge-Devel mailing list > JVM...@li... > https://lists.sourceforge.net/lists/listinfo/jvm-bridge-devel > |
|
From: Artem Gr <ar...@bi...> - 2007-01-02 10:14:41
|
We can place the darcs binary into the project directory. Stripped and upx-ed it's only 716 kb. I did this: scp -P 22 darcs ar...@ss...:/home/groups/j/jv/jvm-bridge/ then placed export PATH=$PATH:/home/groups/j/jv/jvm-bridge to the end of my .bash_profile Then i did: SSH_PORT=22 darcs pull -v ar...@ss...:/home/groups/j/jv/jvm-bridge/htdocs/haskell-jvm-bridge/ and it works! Ashley Yakeley wrote: > On Dec 22, 2006, at 05:15, Artem Gr wrote: > >> All right, the GHC-6.6-only variant should be easier to do. >> >> BTW, here are the GHC-6.4 release and the darcs repository: >> http://jvm-bridge.sourceforge.net/ > > How can I push patches to the darcs repository? SF doesn't have darcs > installed, and installing it in my own space will fill up my quota. > > --Ashley Yakeley |
|
From: Ashley Y. <as...@se...> - 2007-01-02 02:14:50
|
On Dec 22, 2006, at 05:15, Artem Gr wrote: > All right, the GHC-6.6-only variant should be easier to do. > > BTW, here are the GHC-6.4 release and the darcs repository: > http://jvm-bridge.sourceforge.net/ How can I push patches to the darcs repository? SF doesn't have darcs installed, and installing it in my own space will fill up my quota. -- Ashley Yakeley |
|
From: Artem Gr <ar...@bi...> - 2006-12-28 19:14:33
|
FYI, the latest version of my JDBC module can be obtained via darcs get http://glim.ru/open/haskell-jdbc/ Documentation available at http://glim.ru/open/haskell-jdbc/html/JDBC.html Artem Gr wrote: > Attached is the version of the JDBC module which displays how JVMUser > monad is hidden from the user. > The user is provided by the module with following methods: > startJVMcp :: [FilePath] -> IO AttachedJVM > jdbcDriverConnection :: String -> String -> String -> String -> > AttachedJVM -> IO JConnection |
|
From: Artem Gr <ar...@bi...> - 2006-12-23 01:00:29
|
Attached is the version of the JDBC module which displays how JVMUser monad is hidden from the user. The user is provided by the module with following methods: startJVMcp :: [FilePath] -> IO AttachedJVM jdbcDriverConnection :: String -> String -> String -> String -> AttachedJVM -> IO JConnection > Artem Gr wrote: >> What i'm currently bothered with, is the imposing requirement of the >> JVM monad on the user of the module. >> Is it possible to do (in the user code): >> >> main = runWithClasspath cp do >> jdbc <- jdbcDriverConnection ... >> callIO (mainProg jdbc) >> mainProg jdbc = do >> rs <- query "select 0 from dual" jdbc >> close jdbc >> >> That is, to wrap the created JVM monad in the "jdbc" variable and >> wrap all the JDBC functions except the jdbcDriverConnection in the IO >> monad, but make them do the JVM monad work inside. I suppose it is >> somehow possible by merging the IO and JVM monads into another monad, >> but i haven't yet used such mechanics. >> >> That is, is it possible to write the "callJVM" function, which, like >> "callIO", invokes the code inside the JVM monad (without trying to >> create a second JVM every time). |
|
From: Artem Gr <ar...@bi...> - 2006-12-22 20:26:35
|
Well, what i've said is not very clear. To clarify: JVM is essentially an external state, like IO, and us such it can be, of course, handled by IO. But JVMUser state, which might contain some preloaded methods, is not external, and passing it via IO, i suppose, does not gives the proper monadic guarantee that the old state of the JVMUser monad is never reused. But from my (scarce) experience with the JVM-Bridge code, i think that this guarantee is not required anywere. ArtemGr write: > Fri Dec 22 22:46:10 MSK 2006 ArtemGr <ar...@bi...> > * Export createJavaVM, allowing us to wrap the VM in the IO monad as well. > Typically the lifespan of the VM is limited by the JVMUser monad, > because the only way to invoke any VM actions is thru the runWithClasspath > function, which wraps the computation into the JVMUser monad. But this > limitation is artificial, IMHO, because the VM resides in the IO monad > and the JVMUser state can be sufficiently passed around by the IO monad. |
|
From: ArtemGr <ar...@bi...> - 2006-12-22 19:55:36
|
Fri Dec 22 22:46:10 MSK 2006 ArtemGr <ar...@bi...> * Export createJavaVM, allowing us to wrap the VM in the IO monad as well= . Typically the lifespan of the VM is limited by the JVMUser monad, because the only way to invoke any VM actions is thru the runWithClasspat= h function, which wraps the computation into the JVMUser monad. But this limitation is artificial, IMHO, because the VM resides in the IO monad and the JVMUser state can be sufficiently passed around by the IO monad. |
|
From: Artem Gr <ar...@bi...> - 2006-12-22 19:28:25
|
Ok, attached is the case of the Java function called repeatedly from the IO monad (the third case in the "test" function). That is, we don't need to write the whole program inside the JVM monad, instead we can pass the necessary state variables (vm and env) to the functions working with the JVM, while keeping the rest of the program in the IO monad. That means we can write JVM-Bridge based modules whose JVM state is transparent to the user. Artem Gr wrote: > What i'm currently bothered with, is the imposing requirement of the > JVM monad on the user of the module. > Is it possible to do (in the user code): > > main = runWithClasspath cp do > jdbc <- jdbcDriverConnection ... > callIO (mainProg jdbc) > mainProg jdbc = do > rs <- query "select 0 from dual" jdbc > close jdbc > > That is, to wrap the created JVM monad in the "jdbc" variable and wrap > all the JDBC functions except the jdbcDriverConnection in the IO > monad, but make them do the JVM monad work inside. I suppose it is > somehow possible by merging the IO and JVM monads into another monad, > but i haven't yet used such mechanics. > > That is, is it possible to write the "callJVM" function, which, like > "callIO", invokes the code inside the JVM monad (without trying to > create a second JVM every time). |
|
From: Ashley Y. <as...@se...> - 2006-12-22 14:34:08
|
On Dec 22, 2006, at 06:10, Artem Gr wrote: > Ashley Yakeley wrote: >> If you're using CVS, you probably want the Rel0_2_Branch branch tag. > I feel darcs is much more convenient to the end-user (including > me): a) no need to "login" to get the contents; b) you can always > "darcs send" your patches by email; etc. The only trick is to > remember the --set-scripts-executable option. > I can import CVS into darcs, if you want the history (had done it > few monthes ago to some of my projects). > Do you oppose moving to darcs? I can reapply necessary patches to > the CVS HEAD then, but i'm not familiar with CVS branching. Moving to darcs is a good idea, but move the Rel0_2_Branch branch, not HEAD. -- Ashley Yakeley |
|
From: Artem Gr <ar...@bi...> - 2006-12-22 14:11:00
|
Ashley Yakeley wrote: > If you're using CVS, you probably want the Rel0_2_Branch branch tag. I feel darcs is much more convenient to the end-user (including me): a) no need to "login" to get the contents; b) you can always "darcs send" your patches by email; etc. The only trick is to remember the --set-scripts-executable option. I can import CVS into darcs, if you want the history (had done it few monthes ago to some of my projects). Do you oppose moving to darcs? I can reapply necessary patches to the CVS HEAD then, but i'm not familiar with CVS branching. > I'm not sure what state the HEAD is in. I've tried HEAD and it was around 0.2 version, and wasn't in a compilable state at all. |
|
From: Ashley Y. <as...@se...> - 2006-12-22 13:53:34
|
If you're using CVS, you probably want the Rel0_2_Branch branch tag. I'm not sure what state the HEAD is in. -- Ashley Yakeley On Dec 22, 2006, at 05:15, Artem Gr wrote: > All right, the GHC-6.6-only variant should be easier to do. > > BTW, here are the GHC-6.4 release and the darcs repository: > http://jvm-bridge.sourceforge.net/ > > Ashley Yakeley wrote: >> On Dec 19, 2006, at 19:58, Ashley Yakeley wrote: >> >>> On Dec 15, 2006, at 12:46, Artem Gr wrote: >>> >>>> I'm considering removal of the autoconf/automake stuff from the >>>> Haskell part of the bridge, with something much simpler being used >>>> to build and install it. >>> >>> I recommend moving it to Cabal. >> >> (And also GHC 6.6 only.) >> > > ---------------------------------------------------------------------- > --- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to > share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php? > page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > JVM-Bridge-Devel mailing list > JVM...@li... > https://lists.sourceforge.net/lists/listinfo/jvm-bridge-devel > |
|
From: Artem Gr <ar...@bi...> - 2006-12-22 13:48:17
|
Attached is my latest development in using JVMBridge as a "thin"
database driver.
It took me time to figure that
a) Explicit "getMethod" and "toCharArray :: JString -> () -> JVM
[Jchar]" signature are required to invoke the magic decoding the String
to "[Jchar]" instead of "ArrayRef.Jchar".
b) That MakeClassModule and MakeJVMModule boilerplate is unnecesary, and
we can write a Haskell module that compiles automatically with "ghc
--make" providing that boilerplate isn't used.
Somehow, explicit use of "Class.forName" throws ClassNotFoundException,
while the "findClassByName" function works and does what it is required
to do: registers the driver.
What i'm currently bothered with, is the imposing requirement of the JVM
monad on the user of the module.
Is it possible to do (in the user code):
main = runWithClasspath cp do
jdbc <- jdbcDriverConnection ...
callIO (mainProg jdbc)
mainProg jdbc = do
rs <- query "select 0 from dual" jdbc
close jdbc
That is, to wrap the created JVM monad in the "jdbc" variable and wrap
all the JDBC functions except the jdbcDriverConnection in the IO monad,
but make them do the JVM monad work inside. I suppose it is somehow
possible by merging the IO and JVM monads into another monad, but i
haven't yet used such mechanics.
That is, is it possible to write the "callJVM" function, which, like
"callIO", invokes the code inside the JVM monad (without trying to
create a second JVM every time).
And is the better way to wrap the JVM monad in the thread and do the
functions of JDBC module communicate with that hidden JVM thread?
|
|
From: Artem Gr <ar...@bi...> - 2006-12-22 13:15:25
|
All right, the GHC-6.6-only variant should be easier to do. BTW, here are the GHC-6.4 release and the darcs repository: http://jvm-bridge.sourceforge.net/ Ashley Yakeley wrote: > On Dec 19, 2006, at 19:58, Ashley Yakeley wrote: > >> On Dec 15, 2006, at 12:46, Artem Gr wrote: >> >>> I'm considering removal of the autoconf/automake stuff from the >>> Haskell part of the bridge, with something much simpler being used >>> to build and install it. >> >> I recommend moving it to Cabal. > > (And also GHC 6.6 only.) > |
|
From: Ashley Y. <as...@se...> - 2006-12-22 06:45:30
|
On Dec 19, 2006, at 19:58, Ashley Yakeley wrote: > On Dec 15, 2006, at 12:46, Artem Gr wrote: > >> I'm considering removal of the autoconf/automake stuff from the >> Haskell part of the bridge, with something much simpler being used >> to build and install it. > > I recommend moving it to Cabal. (And also GHC 6.6 only.) -- Ashley Yakeley |
|
From: Ashley Y. <as...@se...> - 2006-12-20 03:58:26
|
On Dec 15, 2006, at 12:46, Artem Gr wrote: > I'm considering removal of the autoconf/automake stuff from the > Haskell part of the bridge, with something much simpler being used > to build and install it. I recommend moving it to Cabal. -- Ashley Yakeley |
|
From: Artem Gr <ar...@bi...> - 2006-12-15 20:46:46
|
I have compiled the Bridge under FreeBSD (6.1-RELEASE), using it's diablo-jdk-1.5.0.07.01_1 and GHC-6.6! The Native part compiled NP after i've figured how to add another JVM into configuration tests, but the Haskell part required a lot of hacking, and given that i don't use and/or like autoconf & co., it is unprobable for me to do an autoconf release supporting both GHC-6.4 and GHC-6.6. In particular, GHC-6.6 can't link an executable when object files was compiled with "-package-name", so one of my hacks was to compile required executables (ShowClasses etc) without "-package-name" and then remove them from Makefile and recompile everything (except the executables this time), so that the same files can be used for the package, and i've just too unconfortable with autoconf/automake stuff to automate it. I'm considering removal of the autoconf/automake stuff from the Haskell part of the bridge, with something much simpler being used to build and install it. Artem Gr wrote: > I plan, eventually, to try the ghc-6.6 too. > (I will also try to use this under FreeBSD with it's native java package). |
|
From: Artem Gr <ar...@bi...> - 2006-12-14 22:21:53
|
I would like to inform the community, that i've just compiled and tested the beforementioned patched version of the bridge against the dev-java/sun-jdk-1.6.0 (Gentoo), and it works. Artem Gr wrote: > I was able to compile the haskell-jvm-bridge-0.3.1.RC5 (available from > http://semantic.org/jvm-bridge/haskell-jvm-bridge-0.3.1.RC5.tar.gz) > under Gentoo, using the dev-lang/ghc-bin-6.4.2 and > dev-java/blackdown-jdk-1.4.2.03-r12 from Portage. The tests in the > Examples directory are running okay too. |
|
From: Artem Gr <ar...@bi...> - 2006-12-14 16:41:26
|
I was able to compile the haskell-jvm-bridge-0.3.1.RC5 (available from http://semantic.org/jvm-bridge/haskell-jvm-bridge-0.3.1.RC5.tar.gz) under Gentoo, using the dev-lang/ghc-bin-6.4.2 and dev-java/blackdown-jdk-1.4.2.03-r12 from Portage. The tests in the Examples directory are running okay too. You can view my patches agains the 0.3.1.RC5 there: http://glim.ru/open/jvm-bridge.patch.1.txt And you can fetch the fresh version there: darcs get http://glim.ru/open/haskell-jvm-bridge/ I plan, eventually, to try the ghc-6.6 too. (I will also try to use this under FreeBSD with it's native java package). |
|
From: Ashley Y. <as...@se...> - 2004-04-19 06:48:31
|
Release 0.3 of Haskell/Java VM Bridge is now available in source-code
form.
New in Version 0.3:
* Windows support (thanks to Thomas Pasch)
* Can now work with third-party Java libraries
* Minor bug fixes
Haskell/Java VM Bridge allows Haskell programs access to the Java
Virtual Machine. It comes in two parts: the 'Native' part, that
abstracts away differences in the various Java VMs, and the 'Haskell'
part that provides a Haskell API. The Native part is not
Haskell-specific, and could potentially be used by other languages
wishing to access the Java VM.
Features include:
* Calling of Java methods, access to fields, array-handling;
* Integration of garbage collectors;
* Reconciliation of exception models;
* Reconciliation of thread models, including 'synchronized' monitor
support and the ability to fork Haskell actions as Java threads;
* Strong typing for Java classes and method argument lists (as tuples),
and use of Haskell lists as arrays;
* Creation of Java classes 'on the fly' (using DefineClass and the Java
Class File Format) that can have Haskell callback methods;
* Lifted monads which do all the necessary JNI class and method/field
ID preloading and 'JNIEnv'-pointer variable handling for you -- these
can be automatically generated via a tool (MakeJVMModule);
* Layered design includes lower-level IO-based interface;
* Automatic generation of modules for Java API classes;
* All relevant imports, flags and libraries etc. handled by a single
GHC package 'javavm';
* No 'unsafe' Haskell calls or pure function FFI anywhere;
* Easy to port to new Java VMs.
You will need:
* An x86 machine running some form of Unix, or a Mac OS X machine, or a
Windows machine with MinGW installed (see Building.win32 for notes on
this);
* GHC 6.2.1 or later;
Earlier versions of GHC may work, but there's a bug in ghc-pkg in GHC
6.2 that causes package problems and may necessitate editing your
package.conf by hand. Use 6.2.1 instead.
* A Java VM.
Haddock documentation is available by running "make doc". There are
currently no annotations however.
Some simple examples have been included such as a program that shows a
Java Frame containing an instance of a Haskell-defined subclass of
Canvas that has a Haskell 'paint' method that draws an oval. You should
be able to figure out most of it from that.
Haskell/JVM Bridge and source code is licensed under the GNU Lesser GPL.
<http://sourceforge.net/projects/jvm-bridge/>
Future plans:
* use hierarchical module structure
* separate out pure (non-FFI) Haskell into a separate package
--
Ashley Yakeley, Seattle WA
|
|
From: Ashley Y. <as...@se...> - 2003-08-07 00:40:14
|
At 2003-08-06 06:25, Jan Scheffczyk wrote: >As far as I can see the bridge goes only in one direction: Call Java from >Haskell. >Correct me if I'm wrong. No, you're correct. JVM-Bridge allows you to create Java classes that have methods that call Haskell, but that's it. Indeed I expect that a project to do so might not have any code overlap with JVM-Bridge. >Do you know of any other ways of calling Haskell from Java? No... you might be able to do it yourself, however. -- Ashley Yakeley, Seattle WA |
