"The right thing should be easier to do"

I register here a series of tweets I already posted, for further ruminations.

One nice thing about Lisp and image based dev environments is that they make the act of exploring easier and more frictionless. This means producing something working is easier, when you're learning a new API or technology. On the other hand they make easier also to transform a crack-fueled idea into something deceitfully working, especially if you don't know well the domain. Thus breaking the rule "Right things should be easier to do", I guess.

CEPL

This weekend I have been exploring CEPL: "a lispy and REPL-friendly Common Lisp library for working with OpenGL", as its author writes. I have no prior experience with OpenGL, but thanks to Baggers' video series "Pushing pixels with Lisp", and predating the examples I found, I managed to write some working code. I have a project idea in mind, let's see how it ends up.

A couple of remarks if you're inclined to experiment on your own.

• When I started I was not able to run cepl:repl, due to the OpenGL version exposed by my driver (3.0, whereas the mininum for CEPL is 3.1). But that's not the actual version supported by the hardware. To access the real capabilities, and ultimately to be able to run CEPL, you must ask explicitly, for example (cepl:repl 800 600 3.1); I initially missed that, so I spent time trying to solve the wrong problem.

• I work with xmonad. The default tiled windows positioning is not ideal with the CEPL output window, but thankfully CEPL's window is easy to identify at manageHook level by its title. So I added this in my configuration: <+> (title =? "CEPL" --> doFloat). For example:

  myManageHook = manageDocks
    <+> (title =? "CEPL" --> doFloat)
    <+> manageHook defaultConfig
  

Writing a test library for Common Lisp

Writing a test library for Common Lisp

New page, with some notes about the ongoing process of writing a test library for CL (just a toy project, I'm not going to spoil the ecosystem).

"Finding most frequent element in a list"

A question on Stackoverflow and a brief search led me to some thoughts I want to register to document my learning experience.

I've been searching for a while for a function that does this in (Common) Lisp. Does one already exist, or do I need to code it on my own? To be more specific, I'm looking for a function that if I fed it in something like '(1 2 4 1), it would return 1?

First of all, the request specifics are incomplete: what should the function return if there's more than one element that occur most frequently? What is the notion of sameness among the elements of the list?

As a beginner, I often find myself looking for idiomatic ways to do things: reusing code in a package is apparently the way to go, but I haven't found a clear path yet for such researchs: I usually look for something in Quicklisp package collection, then on github and the Clwiki. I suspect that, at least for these simple functions, CL makes it so easy to roll your own version that everybody end up writing a homemade solution.

Status update

Some days off, not very much done. Somehow relevant in the context of this stream:

• Writing some simple Common Lisp, for exercise. The Wireworld simulator and editor –which has some significance per se besides being interesting as a CL exercise– is on pause (while I try to figure out Lispbuilder-sdl's ways of treating surfaces), and I'm now on something simpler. It's a Sudoku solver assistant. It's not clear to me what the scope of the project will be, however I'm discovering handy techniques and tools useful for a "real" system: for example I borrowed from scmutils the idea of using TeX to obtain a representation of the Sudoku problem (it's faster than I initially thought).
• Reading Seveneves by Neal Stephenson. I hope to write something more substantial as I reach its end.

The Lisp Curse

The Lisp Curse

Interesting read, that resounds with something we were talking about at last Haskell meetup.

Lisp is so powerful that problems which are technical issues in other programming languages are social issues in Lisp.

Consider the case of Scheme, again. Since making Scheme object-oriented is so easy, many Scheme hackers have done so. More to the point, many individual Scheme hackers have done so. In the 1990s, this led to a veritable warehouse inventory list of object-oriented packages for the language. The Paradox of Choice, alone, guaranteed that none of them would become standard. Now that some Scheme implementations have their own object orientation facilities, it's not so bad. Nevertheless, the fact that many of these packages were the work of lone individuals led to problems which Olin Shivers wrote about in documenting the Scheme Shell, scsh.

Logo-ish drawing environment

Some months ago I bought a copy of "Turtle Geometry". I am looking for a LOGO environment to follow along and do the exsercises, but I could not find anything good enough for Mac OS X (which is quite surprising, if you ask me). So I decided to write my own version. The first usable thing I produced is not quite LOGO, but enough to do fancy drawings and (I'm guessing) translate most of the exercises without efforts. Code is on github.

;; [...]
    (with-events ()
      (:quit-event () t)
      (:key-down-event (:key key)
                       (when (sdl:key= key :sdl-key-escape))
                       (sdl:push-quit-event))
      (:idle (reset-turtle)
             (fancy 20)
             (draw-turtle *position-x* *position-y* *direction*)
             (update-display)))))

lispbuilder-sdl

Tried to install listbuilder-sdl via quicklisp, but got stuck on cocoahelper dependency. Is it supposed to work on Yosemite?

Land of Lisp

Land of Lisp