Showing posts with label clojure. Show all posts
Showing posts with label clojure. Show all posts

Friday, June 20, 2014

Om examples: Scrubbing Calculator component

I'm starting to get the hang of Om.  While I've used cljs & jayq for a while, understanding the right way to use om + core.async has taken a bit of doing.  They're both great libraries, and have fairly small APIs, but I've been hungry for fairly simple examples.  In that vein, here are a couple, the second inspired by Bret Victor's Scrubbing Calculator.

Update: git repo with examples

Prelude: simple clock

Simple enough, derived from the animation example in om examples.

Scrubbing Int, Approach one: all local state

Two utility functions:

My first attempt entirely used internal state.  Not terribly useful, but it set the stage.

It works entirely in the span element.  Click and drag changes the value. If you drag out of the element before you release the mouse button, the state becomes inconsistent.  The snippet below will let you tune the sensitivity if you use it in the :onMouseMove handler.


Approach two: Moving out the state

So here I've switched things to use an external atom for the value, and moved most of the logic into event listeners under IWillMount.  This works correctly even if you drag off the span element.  It's pretty much everything I set out to do with this.

The only drawback is the event listeners should be connected in the handler for onMouseDown, and removed when "mouseup" is received. I'll update it when I've figured out how to remove existing listeners.

Afterward: Stuff you should be looking at

Friday, May 2, 2014

DataScript might be a great idea for Datomic

I was looking at DataScript, and the simple implementation gave me (I think) a lot of insight into Datomic.  If Tonsky's post is correct, and there is a core to Datomic that could be used as an in-memory Datomic-like thing, which could be used as easily as, say, core.logic, and that I could look under the hood to see how a simple case works, I would be in a much better place.  A big part of the problem is the catch-22 for learning datalog, easy to toy with, don't know where to go from there.

I'm not against spending money.  A few months back I went to an all-day Datomic class, and thought it well worth the $300 or so I spent on it.  I wouldn't be against talking people into paying for Datomic, but I'm not familiar with it to know when I should.  The main problem is that I haven't spent enough time playing with it to get a good feel for where it fits best.  Spinning up a separate server process just doesn't really work for that kind of playing.

Sort of like how I understood garbage collection, but once I implemented a toy lisp, I *got* it, and understood it's tradeoffs in a way I never had before.

I don't know what Datomic's sales numbers look like, but this seems like it would be a good strategy to increase interest/familiarity with the protocols and ideas involved, which would presumably increase the sales pipeline.

Friday, June 29, 2012

.emacs style Clojure rc files

The following will let you run clojure code in the current namespace, from a dotfile in your home directory.

(require '[ :as io])

(load-string (slurp (io/file (System/getenv "HOME") *rc-file*)))

Monday, June 7, 2010

Using Apache Camel from Clojure

I've been looking at Apache Camel for a project at work, and had a bit of trouble getting it working from Clojure, so I wrote this up in case anyone has the same issues.

The first example in Camel in Action watches a directory for new files, and copies them to an output directory. Here are the steps to get that running in Clojure, using leiningen.

  • Create your input and output directories
  • Create a new leiningen project
  • Add the following to the project.clj

  • run lein deps
  • Add the following to your src/org/whitlark/fc.clj (or whatever your last name is ;-)

Part of what screwed me up was the fact that you need to include spring in the project in order to get camel to work properly.

You can also use a macro to make the code even cleaner, like this:

Which I think compares nicely to the original Java:

I'm sure there are more improvements possible, but this got me started.

Saturday, March 7, 2009

Clojure, Frozen Bubble, and how I learned to start worrying about my math education

So, I've been playing around with Clojure, reading the rough cut of Programming Clojure, (good book, so far), and was looking for a project to sink my teeth into in order to really get a feel for the language. Frozen Bubble, aka Bust A Move, has long been a favorite game of my wife, and while I tend to lose to my coworkers, should be interesting to implement.

Using a sample implementation of snake from the book as a template, I start hacking on the code, striping out all the snakey stuff, and just getting a minimal program that just displays a window. So, Frozen Bubble has only two real game objects: your target pointer, which ranges from -90 to +90 degrees, (a little less actually, no sense firing horizontally), and bubbles, which are in one of three states: not moving while in the initial position at the center of the bottom of the screen, stuck to the top of the game area (directly or via a chain of bubbles), and moving from the bottom of the screen to the top.

Well, the first state is easy, the third state is probably the same, but the second state has some unexpected complexity. First I think I'll give the bubble a location and direction, and handle the speed via the game tics. Seems reasonable, right? Then I run smack into something that makes me wish I had paid more attention in math class. The bubble has a direction, expressed in degrees, which I need to use to manipulate the location, which is expressed as [x,y].

Being a proper little reductionist, and stubborn enough to try to figure it out for myself instead of spending five minutes with google, I decide to think about the second simplest case, a 2x2 grid of pixels. (The simplest would be a single pixel, and I don't see how that would help at all. Perhaps I'm just not being clever enough, though.)

Anyway, this setup gives us the following:

Starting point: [0,0], 0 degrees (straight up or North) -> [0,1], 90 degrees (right or East) -> [1,0], and 45 degrees (NE) -> [1,1]

This says to me that if I want to work in single pixels, I have to do it in 45 degree increments. Not satisfactory. I can approximate closer and closer angles by using a larger grid, (why do I feel like this leads to calculus?) But that means that I'm not working with single pixels anymore.

I went and read some things at Better Explained, which while fascinating in their own right, (I love that site), didn't seem to help matters. I think the gap is that the actual position in real space would be floating point (well, kinda), but the game space in measured in integers (pixels).

Grabbing my trusty graph paper, I start diagramming. A 3x3 grid only buys me two new angles: 22.5 and 67.5. 4x4 gives me 0, 15, 30, 45, 60, 75, & 90.

I now have:
2x2 = 4 squares = 3 angles
3x3 = 9 squares = 5 angles
4x4 = 16 squares = 7 angles
5x5 = 25 squares = 9 angles, etc.
which generalizes to: AxA = A**2 squares, and 2A-1 angles
So to represent all 90 degrees, (which is actually kind of arbitrary anyway), I solve for 90 = 2A-1 = 45.5 squares to a side. My screen resolution on my laptop is 1024/768, so using the height as a guide, if I want to update to bubble position by individual degrees, I can only do it ~16 times from the bottom to the top of the screen. Clearly less than ideal, some sort of approximation is called for.

There are two ways that I can think of to do this off the top of my head for a 2x2 grid update: splitting the difference evenly, (i.e. a 20 degree angle will be bumped up to 45, or it can be rounded to the closer number, in this case 0. The rounding case seems more rational.) Obviously I want to stagger the updates to get the closes approximation to the actual angle I can, but a constraint I'm operating under is to have no other state saved between updates than location and direction. Ummmm.....

The only option I can see is to manipulate the direction each time so that after ~45 pixels, it arrives in the correct place. However, my laptop battery is about to die, and it's late, so I think I'll sleep on it and continue this later.