Fork me on GitHub

I'm getting into Machine Learning, and since Clojure is love, Clojure is life: I'd love to do that with any of the great libraries I've found so far like Cortex, Neanderthal or @hswick's I bought a book called linear algebra with applications and am following coursera courses for learning it "the hard way". But recently I've been super lucky to stumble into an opportunity and reason for putting all my learning into a higher gear.. I got an invite to a StarCraft II AI workshop with freaking DeepMind and Blizzard 🎉 🎉 .


I feel a bit like an imposter to go there, but I was honest in my application that I'm not a machine learning expert at all yet, and I guess it's a workshop for a reason 🙂. I put effort (more than I like to admit, Clojure has no maintained library for protobuf :/) into using the StarCraft II AI API from Clojure:


I hope this channel can help me out a bit with ml-beginners questions.


@pragsmike @dave.dixon I tried Beaker briefly but I found the dependency management to be painful, plus it hard-coded the clojure version to an old one (leading me to conclude the clojure kernel wasn't actively maintained)


looked slick though


I'm also limited in the time I can contributing to this unfortunately


@elise_huard I heard a comment in your talk about dependency management being difficult, but I thought that was with clojupyter rather than BeakerX. That was what made me start looking into the jupyter integration story, actually. No one seems to like any of the alternatives for specifying dependencies. At the conj, I met someone who had been looking into tying dependencies to namespaces rather than projects (or notebooks in this case).


@pragsmike I tried Beaker as well, but didnt' mention it in the talk


(Jupyter seemed the more popular one to mention 🙂 )


curious to hear other people's experiences though


@bbss that is awesome you got accepted into the workshop! Your api is pretty involved, so you deserve it!


@elise_huard Agreed on the dependency management. BeakerX does not use nREPL, rather has it's own internal evalutation engine (in Java). And I may be mistaken, but I think because everything is evaluated under a single JVM (both the kernel and your code) you're going to wind up with some issues. Ideally, it seems like a Jupyter kernel just needs to act as a go-between with an nREPL process. Then you get all the lein/boot goodies to deal with dependencies.


Both BeakerX and SoS allow data to be copied between different language kernels (BeakerX support is currently limited). SoS has an extensibility mechanism where you provide your implementation of "serializing" your language's data to/from Python. This seems like it should be straightforward using transit.