I’ve always been registered independent, despite voting for the Democratic party most of
the time. I don’t like that people identify as Democrat vs. Republican, or Liberal vs.
Conservative, or whatever. I prefer looking at the policies of candidates, what issues
they find important, and what character they show. Given that, I don’t care what label
they choose for themselves.

Just jotting down some notes while trying to get CEPL working on my
oldish MacBook Pro running El Capitan.

Use SBCL. I usually default to ClozureCL, but for the moment I can’t get
swank:*communication-style* nil to work with it, and things will just break horribly
if you end up off the main thread in CEPL. SBCL works fine.

To make sure that Swank starts up with the right communication style, I stuck this in ~/.swank.lisp:
#+sbcl (setf swank:*communication-style* nil)

My (old) Macs only support up to version 3.3 OpenGL contexts, but the version of CEPL that’s
available in Quicklisp uses 4.1 contexts. The current HEAD on Github lets you choose your
context version, so you’ll need to clone the CEPL repository and some
of its dependencies locally in your Quicklisp local-projects directory. (list below)

Download the runtime frameworks for SDL2 and SDL2_image and stick
them in ~/Libraries/Frameworks.

I’m haven’t been able to get the examples running directly yet: it seems like cepl.sdl2’s
host step function is getting clobbered by the one in cepl.skitter.sdl2, so you need
to avoid loading that.

Once you have your .swank.lisp set up, and Emacs configured to use SBCL, start SLIME
as normal. (e.g. M-x slime)

Load cepl.sdl2: (ql:quickload "cepl.sdl2")

Initialize CEPL, passing it a window size and the OpenGL context version you need:
(cepl:repl 480 320 3.3)

If everything went well, you should have a blank, untitled window somewhere on your
desktop, probably behind your Emacs window. Clicking on the SBCL icon on your dock won’t
bring it forward, you’ll have to go looking for it.

Again, I can’t get the examples to run directly, but you can run the triangle example below
by:

Loading livesupport: (ql:quickload "livesupport"). The examples use it to keep your
REPL usable while Swank is in single-threaded mode.

Load the example listed below.

Run (triangle::run-loop) to start it, and hit enter an extra time to get your REPL back.

We use SQLite4Java at work, and I’m playing around with our
databases from Clojure at the moment and just wanted to quickly jot down how
to do it.

First, native library management in SQLite4Java is a little hairy: it’s going to look
for the libraries either in java.library.path, sqlite4java.library.path, alongside
the SQLite4Java jar file, or you can explicitly tell it where to find things. The
Maven config to do this automatically is suitably ugly, and as far
as I know, there’s not a good way to do the same thing with Leiningen.

I opted to just explicitly tell it for now. I list the SQLite4Java dependency in my
project.clj, copied the native libraries I’m interested in into ${project.dir}/natives,
and then just added this at startup time:

(I’m leaving all of the namespace components in there to be explicit: I require/import
them as normal in my code.)

Next issue: actually running queries against a database has to be done using a
SQLiteConnection instance, and those instances are limited to being
used from the thread that created them. That precludes using them from the REPL: you don’t
have any control over what thread your expressions are going to be executed from. So, you
need to use SQLiteQueue, which wraps a SQLiteConnection and ensures all calls
come from a single thread.

SQLiteQueue works by taking SQLiteJob instances (basically just a function) and
running them in first-in-first-out order. Unfortunately, SQLiteQueue can’t just take a
Callable, so you can’t use Clojure functions directly. Wrapping a function up in a job is
pretty easy though, and is the first time I’ve needed to use clojure.core/proxy:

(defnjob"Returns a SQLiteJob proxy that calls the given function."[job-fn](proxy[com.almworks.sqlite4java.SQLiteJob][](job[^SQLiteConnectionconn](job-fnconn))))

Then using those jobs is done by calling SQLiteQueue::execute, which returns
the job again. Those jobs implement Future, so you can use them as normal, or
they have a convenience method SQLiteJob::complete that deals with exceptions
for you.

So all bundled together, my little library for working with SQLite4Java looks like this
right now:

(nsjfischer.db(:require[clojure.java.io:asio])(:import[com.almworks.sqlite4javaSQLiteQueueSQLiteConnectionSQLiteJob]))(defnopen-db"Creates (and starts, because I'm forever forgetting to .start it at
the REPL) a SQLiteQueue instance. The zero-argument version opens an
in-memory database, otherwise give it a filename."([](open-dbnil))([filename](.start(SQLiteQueue.(io/filefilename)))))(defnjob"Returns a SQLiteJob proxy that calls the given function."[job-fn](proxy[SQLiteJob][](job[^SQLiteConnectionconn](job-fnconn))))(defnexec-job"Runs the given job on the database queue and returns its result."[^SQLiteQueuedb^SQLiteJobjob](.complete(.executedbjob)))

Really quick: after dismissing Clojure for years (I have Common Lisp, I don’t
care about the JVM, why do I need it?) I finally took the time to learn it
about a year ago and OMG I love it and I want to use it for everything (much
to the dismay of my team at work).

One of the pain points though is how project-based everything seems to be: if
you want to pull in any sort of third party library, you have to build some sort
of project, be it Maven, Leiningen, or something similar.
List the libraries you want to pull in there and start (or restart) your REPL
before you can use them.

Coming from Quicklisp, it’s super annoying,
especially if you just want to give something a quick spin.

Enter Boot! It’s a relatively new way to handle building
Clojure projects, but it allows you to easily name dependencies when you run
it, like so:

To make life a little easier, I have a task in my ~/.boot/profile.boot that
pulls in the dependencies Cider needs:

(deftaskcider"Switch up the default dependencies and middleware to support cider-nrepl."[](require'boot.repl)(swap!@(resolve'boot.repl/*default-dependencies*)concat'[[org.clojure/tools.nrepl"0.2.12"][cider/cider-nrepl"0.10.1"]])(swap!@(resolve'boot.repl/*default-middleware*)concat'[cider.nrepl/cider-middleware])identity)

So when I want to tool around with something, I just run boot -d whatever:version cider repl,
fire up Emacs, connect and go to work.

I haven’t take the time to get comfortable with Boot for full projects yet, so I’m
still using Leiningen for most things, but I love it for quick one-off experiments.
It’s not as good as being able to load whatever I want from the comfort of the REPL,
but it makes things a lot less painful.

I’m pretty sure that every time I’ve built a web application of any sort in the last decade,
I’ve reached for a database. Usually SQLite, at least to start, because it lets me
get going fast without any infrastructure in place. It’s not even a question, really: if
I’m building a web app, it needs a database of some kind behind it.

Actually, let me rewind just a smidge. I really dig Clojure lately, and
my favorite thing about it are the immutable data structures: once you’ve created your map,
or vector, or whatever, you can’t change it. Instead, you can derive new things from
it. Now that I’m comfortable working with
immutable by default things, working without them feels almost like I’m building on shaky
foundations.