That looks great! I'm definitely going to have to experiment with that. I've been doing a lot of F# lately (being at BlueMountain now), so I'm starting to learn the .NET ecosystem. Our group (mortgages/abs) has our own in-house data store, so I doubt we'll be using JD directly, but it's worth experimenting with. (I'd much rather have someone else handle the infrastructure, but nothing we've found quite matches our needs.[1])
Cheers, Johann [1] Since I'm sure someone will ask, we want to fit nonlinear regression models on big data sets, and a lot of the "big" databases these days seem tuned to aggregations and map/reduce, which is a poor fit. On Mon, Sep 29, 2014 at 9:00 AM, Steven Taylor <[email protected]> wrote: > Hi, > > I've been fairly quiet on the list of late, but I've got a tiny project > that might be of interest. It's called *FSharp.Control.JSoftware*. It > connects to JHS / JD over http. It's actually my third version of this > project. I seem to start from scratch each year or so. This version could > be more feature rich, but I tore out a as many elements as possible in > order to minimise dependencies. If there's interest in this approach, some > of those features might slowly make their way back in. > > Brief feature outline: > > - out-of-process > - text & JSON support > - JBIN was working, but I tore that out to minimise dependencies. > Putting that back in is a @TODO item > - eval + J function support > > > To document / To do: > > - how to extend JD with J functions > - what that eval code should look like > - JD server set-up + start-up (I've got some c-shell scripts that I > know run on Windows + a short sequence of steps. Those aren't included > here yet. Another @TODO) > - Get the travis build working > > Please note that that JD approach doesn't have to be just for databases. > For example, I've exposed some functions via this interface that don't do > anything with a database. I really liked the way that JHS / JD have been > moving in, so I tried to align myself with this as much as possible. > Command based rather than REST based might makes sense in a number of > scenarios. > > Code notes: > > It's written in C#, but there'll most likely be extensions in F# (or > possibly an F# rewrite) in the near future. So to avoid later confusion, I > went for the FSharp.Control.JSoftware namespace early on. > > Thoughts on cross platform: > > - lots more to say here, but this approach (or any actually) could be > converted to Swift-lang, or cross-compiled via the Xamarin tool chain. > Maybe if there's a template that we all like, the out-of-process idiom > would proliferate. > > I almost forgot... here's the project link: > https://github.com/sgtz/FSharp.Control.JSoftware > > best regards, > -Steven Taylor > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
