Re: [Haskell-cafe] Talking to Java from Haskell?
Besides the FFI option, I know that Haskell has pretty good Lua bindings [1] and Lua has pretty good Java bindings [2] so perhaps the law of transitivity can work for you! -deech [1] http://hackage.haskell.org/package/hslua-0.2 [2] http://www.keplerproject.org/luajava/manual.html On Mon, Jul 19, 2010 at 10:09 PM, Max Cantor mxcan...@gmail.com wrote: I use Apache Thrift, as someone else mentioned for IPC with some java code that connects to a third party data vendor. As of version 0.2, there are some bugs that you need to be aware of. However, and possibly more of interest to you, I have already written a FIX implementation in pure haskell. Its not exactly shippable code but it works fine for me. Its not as full featured as quick fix but its fine for single orders. Since you seem to be in a similar line of work to me (using haskell for finance/trading) perhaps we shoudl have a chat. Get me on gtalk at this address. Max On Jul 9, 2010, at 8:11 PM, Daniel Cook wrote: A simpler solution might be Facebook's thrift [1] This is a very interesting solution. I'll investigate Thrift further, but it may wind up being what I do. Does anyone know how solid this code is in Haskell? the Java binary directly from Haskell using System.Process and friends, and rather than communicating over ports, communicate over pipes. Cool! This is probably a second step, though - first get the code working, then worry about making it all fast. On Fri, Jul 9, 2010 at 5:11 AM, sterl s.clo...@gmail.com wrote: Daniel Cook wrote: b) Wrap the Java library with some code to use a lightweight message queue (zeromq) to send messages to my Haskell program? (This would require essentially re-implementing an abstracted subset of the the protocol into 0MQ messages) A simpler solution might be Facebook's thrift [1] (now an Apache project). You write a simple file in a C-inspired IDL which gives typedefs and RPC signatures, and not only do you get the data structures and serialization functions in a number of target languages including Haskell and Java, but you get lightweight, relatively robust, server and client implementations. The implementations of the Java functions can then be written in Scala or Clojure, so you avoid having to leave fp-land entirely. One could even run the Java binary directly from Haskell using System.Process and friends, and rather than communicating over ports, communicate over pipes. In any case, I've had good luck with this approach. Cheers, Sterl. [1] http://incubator.apache.org/thrift/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Talking to Java from Haskell?
Someone has written a large Java library (QuickFIX/J) which speaks a gnarled, ugly protocol (FIX). They've also written a large C++ library for the same purpose called QuickFix[1]. You could try wrapping it directly via the Haskell FFI. Travis [1] http://www.quickfixengine.org/ On Thu, Jul 8, 2010 at 6:35 PM, Daniel Cook danielkc...@gmail.com wrote: Hi, Someone has written a large Java library (QuickFIX/J) which speaks a gnarled, ugly protocol (FIX). There don't appear to be any FIX protocol libraries in Hackage. I need my Haskell program to talk to a 3rd-party system that only speaks FIX. Should I: a) Reimplement the protocol directly Haskell? (This appears to be non-trivial) b) Wrap the Java library with some code to use a lightweight message queue (zeromq) to send messages to my Haskell program? (This would require essentially re-implementing an abstracted subset of the the protocol into 0MQ messages) c) Find a way for Haskell to interact directly with Java? (the various JNI bridges seem very unmaintained...) To me, (b) seems like the best approach, but I'd like to hear what the cafe thinks.. Cheers, - Dan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Talking to Java from Haskell?
I use Apache Thrift, as someone else mentioned for IPC with some java code that connects to a third party data vendor. As of version 0.2, there are some bugs that you need to be aware of. However, and possibly more of interest to you, I have already written a FIX implementation in pure haskell. Its not exactly shippable code but it works fine for me. Its not as full featured as quick fix but its fine for single orders. Since you seem to be in a similar line of work to me (using haskell for finance/trading) perhaps we shoudl have a chat. Get me on gtalk at this address. Max On Jul 9, 2010, at 8:11 PM, Daniel Cook wrote: A simpler solution might be Facebook's thrift [1] This is a very interesting solution. I'll investigate Thrift further, but it may wind up being what I do. Does anyone know how solid this code is in Haskell? the Java binary directly from Haskell using System.Process and friends, and rather than communicating over ports, communicate over pipes. Cool!This is probably a second step, though - first get the code working, then worry about making it all fast. On Fri, Jul 9, 2010 at 5:11 AM, sterl s.clo...@gmail.com wrote: Daniel Cook wrote: b) Wrap the Java library with some code to use a lightweight message queue (zeromq) to send messages to my Haskell program? (This would require essentially re-implementing an abstracted subset of the the protocol into 0MQ messages) A simpler solution might be Facebook's thrift [1] (now an Apache project). You write a simple file in a C-inspired IDL which gives typedefs and RPC signatures, and not only do you get the data structures and serialization functions in a number of target languages including Haskell and Java, but you get lightweight, relatively robust, server and client implementations. The implementations of the Java functions can then be written in Scala or Clojure, so you avoid having to leave fp-land entirely. One could even run the Java binary directly from Haskell using System.Process and friends, and rather than communicating over ports, communicate over pipes. In any case, I've had good luck with this approach. Cheers, Sterl. [1] http://incubator.apache.org/thrift/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Talking to Java from Haskell?
A simpler solution might be Facebook's thrift [1] This is a very interesting solution. I'll investigate Thrift further, but it may wind up being what I do. Does anyone know how solid this code is in Haskell? the Java binary directly from Haskell using System.Process and friends, and rather than communicating over ports, communicate over pipes. Cool!This is probably a second step, though - first get the code working, then worry about making it all fast. On Fri, Jul 9, 2010 at 5:11 AM, sterl s.clo...@gmail.com wrote: Daniel Cook wrote: b) Wrap the Java library with some code to use a lightweight message queue (zeromq) to send messages to my Haskell program? (This would require essentially re-implementing an abstracted subset of the the protocol into 0MQ messages) A simpler solution might be Facebook's thrift [1] (now an Apache project). You write a simple file in a C-inspired IDL which gives typedefs and RPC signatures, and not only do you get the data structures and serialization functions in a number of target languages including Haskell and Java, but you get lightweight, relatively robust, server and client implementations. The implementations of the Java functions can then be written in Scala or Clojure, so you avoid having to leave fp-land entirely. One could even run the Java binary directly from Haskell using System.Process and friends, and rather than communicating over ports, communicate over pipes. In any case, I've had good luck with this approach. Cheers, Sterl. [1] http://incubator.apache.org/thrift/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Talking to Java from Haskell?
From: Daniel Cook danielkc...@gmail.com Hi, Someone has written a large Java library (QuickFIX/J) which speaks a gnarled, ugly protocol (FIX). There don't appear to be any FIX protocol libraries in Hackage. I need my Haskell program to talk to a 3rd-party system that only speaks FIX. Should I: a) Reimplement the protocol directly Haskell? (This appears to be non-trivial) b) Wrap the Java library with some code to use a lightweight message queue (zeromq) to send messages to my Haskell program? (This would require essentially re-implementing an abstracted subset of the the protocol into 0MQ messages) I think you need to answer these two questions to make a decision: 1) How stable/defined is FIX? 2) How large of a subset of FIX do you use? If FIX is relatively stable or has multiple (non-C) implementations in current use, and you'd be using a large-enough subset, then I expect implementing a Haskell implementation would be the smallest amount of work overall. If FIX has only one canonical implementation, changes frequently, or you'll only use a small portion of it, then b) would likely be simplest. Another option would be to expose hooks to your Haskell program through the FFI and have it called by Java. John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
FIX Protocol in Haskell (was Re: [Haskell-cafe] Talking to Java from Haskell?)
1) How stable/defined is FIX? Not very. There are several protocol versions, various vendors have their own custom message types, there are service packs released fairly regularly updating the protocol for new message types, etc. 2) How large of a subset of FIX do you use? I will be using a relatively small subset of the available FIX messages, and my subset will change a lot at the beginning but then stabilize. work overall. If FIX has only one canonical implementation, changes frequently, or you'll only use a small portion of it, then b) would likely be simplest. FIX has one canonical open source implementation (actually 2, but they're the same program ported to C++ and Java). Another option is to use Haskell's FFI to wrap the C++ implementation. QuickFIX is designed exactly the way you *wouldn't* design it to make interop with Haskell easy. The API is based on callbacks to a class which one extends. The C++ uses lots of templates, and the .h files are full of macros. On the plus side, the program has a .idl, and is already SWIG-wrapped for C#, Python, and Ruby. Do you (or anyone) have experience wrapping highly stateful C++ programs with Haskell FFI? Are there examples around? (Xmonad comes to mind, but I don't know if X11's API is C or C++ ..) I think I'm going to have to recreate the various message types in Haskell's type system anyway. Given that, maybe I should simply use Haskell to implement a small, clean, extensible subset of this protocol (what I need). I can then test it heavily against the QuickFIX implementation. Opinions? -- Dan On Fri, Jul 9, 2010 at 2:31 PM, John Lato jwl...@gmail.com wrote: From: Daniel Cook danielkc...@gmail.com Hi, Someone has written a large Java library (QuickFIX/J) which speaks a gnarled, ugly protocol (FIX). There don't appear to be any FIX protocol libraries in Hackage. I need my Haskell program to talk to a 3rd-party system that only speaks FIX. Should I: a) Reimplement the protocol directly Haskell? (This appears to be non-trivial) b) Wrap the Java library with some code to use a lightweight message queue (zeromq) to send messages to my Haskell program? (This would require essentially re-implementing an abstracted subset of the the protocol into 0MQ messages) I think you need to answer these two questions to make a decision: 1) How stable/defined is FIX? 2) How large of a subset of FIX do you use? If FIX is relatively stable or has multiple (non-C) implementations in current use, and you'd be using a large-enough subset, then I expect implementing a Haskell implementation would be the smallest amount of work overall. If FIX has only one canonical implementation, changes frequently, or you'll only use a small portion of it, then b) would likely be simplest. Another option would be to expose hooks to your Haskell program through the FFI and have it called by Java. John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Talking to Java from Haskell?
HI Dan, It depends on how much of the protocol you're going to use. If you only have to use some kinds of messages it may be fastest to use Scala and Actors using the Java library. Depending on the data I'd use a very simple protocol for the communication Haskell - Scala. Whether you should reimplement the protocol also depends on whether speed is an issue. If nobody picked up and started to work on Java interaction I think you're right that b is the fastest option. Marc Weber ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Talking to Java from Haskell?
On Thu, Jul 8, 2010 at 6:35 PM, Daniel Cook danielkc...@gmail.com wrote: Hi, Someone has written a large Java library (QuickFIX/J) which speaks a gnarled, ugly protocol (FIX). There don't appear to be any FIX protocol libraries in Hackage. I need my Haskell program to talk to a 3rd-party system that only speaks FIX. Should I: a) Reimplement the protocol directly Haskell? (This appears to be non-trivial) b) Wrap the Java library with some code to use a lightweight message queue (zeromq) to send messages to my Haskell program? (This would require essentially re-implementing an abstracted subset of the the protocol into 0MQ messages) c) Find a way for Haskell to interact directly with Java? (the various JNI bridges seem very unmaintained...) Are you referring to projects like these? * lambdaVM: http://www.cs.rit.edu/~bja8464/lambdavm/ * EclipseFP uses (or used, I'm not sure) a bridge between Java/Haskell. I doubt these approaches are very mature for general purpose work. They probably work well for the author's original purpose, but perhaps you'd run into low level bugs using them yourself. I assume they use Java's JNI and connect that to Haskell FFI. I don't know why this would be a necessarily hard problem. Haskell's FFI is very nice for talking to C, but perhaps Java's JNI is not as friendly. I would probably start by writing a JNI wrapper around QuickFIX to expose it to C and C-like languages. Then I would write a Haskell FFI binding to that library. In this way, C will become your glue language as odd as that may sound. As a longer term solution, having a combinator library for FIX in Haskell sounds really nice. I don't need it personally, but it just seems like the way to go. The drawback here is that you will have to duplicate a lot of effort to keep your implementation in sync with the de facto implementation. On the other hand, depending on the nature of the technical hurdles your Haskell implementation may be significantly easier to maintain and could possibly end up serving as a concise, correct, reference implementation when the FIX specification changes. It's also possible that some Haskell compiler, such as YHC, would serve well here. Maybe it's easier to modify that in the way lambdaVM is a modification to GHC. If I recall correctly, YHC had a backend for JavaScript at one point. That makes me think it has a very hackable backend. Another possibility that tends to work very well is to use Haskell to define a domain specific language. Your DSL could generate Java source that uses QuickFIX directly. You get the strength of using the de facto tool chain for your production binaries, the power of Haskell for language design, and the expressive power that comes from having a domain specific language. This solution is also cheaper than it might sound. You start with combinators that build up Java expressions and go from there. It's hard for me to say which is best without knowing more about the programs you'll be writing. Sounds like an interesting project! Good luck, Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Talking to Java from Haskell?
I would probably start by writing a JNI wrapper around QuickFIX to expose it to C and C-like languages. Then I would write a Haskell FFI binding to that library. In this way, C will become your glue language as odd as that may sound. vs. Depending on the data I'd use a very simple protocol for the communication Haskell - Scala. The JNI thing would probably run very fast. Given my total ignorance of JNI and Haskell FFI, it could be challenging to implement, however. In some ways, this suggestion encourages me even more to use a message queue: people have already implemented the messaging interface for both Haskell and Java, so that all I need to do is specify some messages. I should make it clear: my objective is to do the minimal amount of engineering necessary to get the data from FIX messages into my Haskell program. As a longer term solution, having a combinator library for FIX in Haskell sounds really nice. I don't need it personally, but it just seems like the way to go. It does - but I think sounds really nice [...] it just seems like the way to go is exactly what my professors meant by mission creep in all those software engineering classes. Doesn't using an existing Scala Haskell libraries to generate parse e.g. lightweight JSON messages also seem elegant? Another possibility that tends to work very well is to use Haskell to define a domain specific language. Woah. Lateral thinking. In some ways, Jaskell has already done this. On Fri, Jul 9, 2010 at 2:58 AM, Jason Dagit da...@codersbase.com wrote: On Thu, Jul 8, 2010 at 6:35 PM, Daniel Cook danielkc...@gmail.com wrote: Hi, Someone has written a large Java library (QuickFIX/J) which speaks a gnarled, ugly protocol (FIX). There don't appear to be any FIX protocol libraries in Hackage. I need my Haskell program to talk to a 3rd-party system that only speaks FIX. Should I: a) Reimplement the protocol directly Haskell? (This appears to be non-trivial) b) Wrap the Java library with some code to use a lightweight message queue (zeromq) to send messages to my Haskell program? (This would require essentially re-implementing an abstracted subset of the the protocol into 0MQ messages) c) Find a way for Haskell to interact directly with Java? (the various JNI bridges seem very unmaintained...) Are you referring to projects like these? * lambdaVM: http://www.cs.rit.edu/~bja8464/lambdavm/ * EclipseFP uses (or used, I'm not sure) a bridge between Java/Haskell. I doubt these approaches are very mature for general purpose work. They probably work well for the author's original purpose, but perhaps you'd run into low level bugs using them yourself. I assume they use Java's JNI and connect that to Haskell FFI. I don't know why this would be a necessarily hard problem. Haskell's FFI is very nice for talking to C, but perhaps Java's JNI is not as friendly. I would probably start by writing a JNI wrapper around QuickFIX to expose it to C and C-like languages. Then I would write a Haskell FFI binding to that library. In this way, C will become your glue language as odd as that may sound. As a longer term solution, having a combinator library for FIX in Haskell sounds really nice. I don't need it personally, but it just seems like the way to go. The drawback here is that you will have to duplicate a lot of effort to keep your implementation in sync with the de facto implementation. On the other hand, depending on the nature of the technical hurdles your Haskell implementation may be significantly easier to maintain and could possibly end up serving as a concise, correct, reference implementation when the FIX specification changes. It's also possible that some Haskell compiler, such as YHC, would serve well here. Maybe it's easier to modify that in the way lambdaVM is a modification to GHC. If I recall correctly, YHC had a backend for JavaScript at one point. That makes me think it has a very hackable backend. Another possibility that tends to work very well is to use Haskell to define a domain specific language. Your DSL could generate Java source that uses QuickFIX directly. You get the strength of using the de facto tool chain for your production binaries, the power of Haskell for language design, and the expressive power that comes from having a domain specific language. This solution is also cheaper than it might sound. You start with combinators that build up Java expressions and go from there. It's hard for me to say which is best without knowing more about the programs you'll be writing. Sounds like an interesting project! Good luck, Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Talking to Java from Haskell?
Daniel Cook wrote: b) Wrap the Java library with some code to use a lightweight message queue (zeromq) to send messages to my Haskell program? (This would require essentially re-implementing an abstracted subset of the the protocol into 0MQ messages) A simpler solution might be Facebook's thrift [1] (now an Apache project). You write a simple file in a C-inspired IDL which gives typedefs and RPC signatures, and not only do you get the data structures and serialization functions in a number of target languages including Haskell and Java, but you get lightweight, relatively robust, server and client implementations. The implementations of the Java functions can then be written in Scala or Clojure, so you avoid having to leave fp-land entirely. One could even run the Java binary directly from Haskell using System.Process and friends, and rather than communicating over ports, communicate over pipes. In any case, I've had good luck with this approach. Cheers, Sterl. [1] http://incubator.apache.org/thrift/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
