Self Wright

Category: Lisp Page 1 of 2

The universal type

CL-USER> (setf universe (find-class 't))
CL-USER> (typep universe universe)

A graphical Repl for Lisp

Finally found one of the things I was looking for!

GTFL is a (ql:quickload "gtfl") call away.

See this pdf to find out more.

Meanwhile, here is an example:

The graphical Repl in action

Lisp, CLOS and Math

What, you say, mathematicians just have to use Haskell ??

Stop right there, and read this.

Technically, there’s nothing new to see here at all. Lisp is high-level and low-level. Lisp is multi-paradigm. Lisp has uniform syntax. Blah blah blah. You’ve heard it all.

Still, some people seem to require an “argument from authority” (and usually still keep looking) … in which case you might be persuaded by this.

An extract (describing how defclass and defgeneric can be handily abused to yield whatever you like):

For example, a mathematician who installs under CLOS the traditional mathematical categories must organize his work as follows:

  • The defclass statements will be used to define what a “set” object is, what a “group” object is, what a “chain complex” object is, and so on.

  • The defgeneric statements will be used to define functions working on these objects, but these “functions” are traditionally called in this case functors in mathematics; therefore one defgeneric statement for the sum functor, another defgeneric for the classifying space functor, and so on.

  • Finally each generic function will have various methods to adapt the generic function to specific cases; for example the product of two objects of some category is also an object of this category with the corresponding structure to be defined. Therefore one product method for the sets, another product method for the magmas, another method for the monoids, and so on. The call-next-method and change-class functions will allow these methods to possibly refer to the less specific ones.

Summing up

I came across this post talking about numerical speed in Clojure, so I thought I would try out the equivalent in Common Lisp (Clozure CL) on my Macbook:

CL-USER> (let* ((arr-size 3000000)
        (double-arr (make-array arr-size :element-type 'single-float)))
       (dotimes (i arr-size)
         (setf (aref double-arr i) (random 1.0)))
       (time (loop for i from 0 below arr-size
            summing (aref double-arr i))))
took 45,649 microseconds (0.045649 seconds) to run.
During that period, and with 4 available CPU cores,
     45,558 microseconds (0.045558 seconds) were spent in user mode
         57 microseconds (0.000057 seconds) were spent in system mode

So — 45 milliseconds, not bad.

Lispium ?

What if you did the following:

  • Take a chromebook
  • Modify the chromium build running to run Sbcl within it.
  • Create lisp bindings to the internal surface, so that all UI elements can be created and manipulated within the Lisp image.
  • Allow downloading, compiling and running arbitrary lisp code
  • One of the tabs is always a Repl
  • Add a caching filesystem that would persist part or whole of the image

… might this create a modern-day Lisp machine? Maybe.

Did I miss anything obvious here? If not, this sounds doable in a few years.

I’m lazy, do you if you like this idea (I’m sure there’s a guaranteed niche market for these machines), go ahead and throw it on to Kickstarter. Or something.

Baktoo: Taking baby steps with generative art

Continuing (or stumbling) along a path to using Common Lisp for stuff I consider fun, I came up with this.

As mentioned in the `README`, I need to work on making this more efficient.

Stuff I learned along the way:

  • I love how I can focus on “making it work” _before_ worrying about “making it fast”
  • Utilities exist for a reason. _Use them_ (I’ve decided to stick with `:rutils`)
  • Don’t be afraid of using libraries. I found `:cl-log`, which is amazingly well-written and I will never use all of it, but just the basic use case of toggling levels of verbosity is good enough for me, and something that would normally be hard to do.
  • Building up the system works really well. This is the first time I’ve had an experience of writing stuff that sort of _just worked_, since it felt like I was **directly translating my thoughts into code**.
  • It’s easy to rapidly create and modify functions, stubs, what not, while keeping them all in view, in the same 100 or so lines of vertical space (contrast with switching between (say) multiple `.java` files)

Anyway, here are a couple of samples I made with this (click to see detailed image):
Baktoo - 2

Baktoo - 1


(ql:quickload 'lispbuilder-sdl) worked right away on an ubuntu box, but failed (couldn’t find `cocoahelper) when I tried the sam on my Macbook.

The fix is to install SDL, then go to ~/quicklisp/dists/quicklisp/software/lispbuilder-20140113-svn/lispbuilder-sdl/cocoahelper and type make. After this, the ql:quickload form succeeds.

However, the same dummy blank screen test program that worked fine on the linux box doesn’t seem to work anymore:

(defpackage :simple-sdl
  (:use :common-lisp

(in-package :simple-sdl)

(defun main-screen ()
  (sdl:with-init ()
    (sdl:window 300 300
        :title-caption "Simple SDL"
        :icon-caption "Simple SDL")
    (sdl:with-events ()
      (:quit-event () t)
      (:key-down-event ()

It fails with this backtrace:

  0: ("bogus stack frame")
  1: ("foreign function: CGSScanconverterRenderRGBMask")
  2: ("foreign function: create_rgb_bitmap")
  3: ("foreign function: CGGlyphBitmapCreateWithPath_32")
  4: ("foreign function: CGFontCreateGlyphBitmap")
  5: ("foreign function: _ZN14CGGlyphBuilder22create_missing_bitmapsEPK17CGGlyphIdentifiermPPK13CGGlyphBitmap")
  6: ("foreign function: render_glyphs")
  7: ("foreign function: draw_glyph_bitmaps")
  8: ("foreign function: ripc_DrawGlyphs")
  9: ("foreign function: draw_glyphs")
 10: ("foreign function: CTFontDrawGlyphsAtPositions")
 11: ("foreign function: -[CUITextEffectStack drawGlyphs:inContext:usingFont:atPositions:count:lineHeight:inBounds:atScale:]")
 12: ("foreign function: -[CUICatalog drawGlyphs:atPositions:inContext:withFont:count:stylePresetName:styleConfiguration:foregroundColor:]")
 13: ("foreign function: -[NSLineFragmentRenderingContext drawAtPoint:inContext:]")
 14: ("foreign function: _NSStringDrawingCore")
 15: ("foreign function: _NSDrawTextCell")
 16: ("foreign function: -[NSTitledFrame _drawTitleStringIn:withColor:]")
 17: ("foreign function: -[NSThemeFrame _drawTitleStringInClip:]")
 18: ("foreign function: -[NSThemeFrame drawFrame:]")

Just when I was getting excited about it … so what other platform-independent Lisp GUI should I use 🙁 ?

BTW, while we’re knocking this (unfairly, of course), I should point out it doesn’t support SDL 2.x

I then stumbled on this library which seemed better maintained, and modified my example:

(defun main-screen ()
  (sdl2:with-init (:everything)
    (sdl2:with-window (win :w 300 :h 300
               :title "Simple SDL")
    (sdl2:with-event-loop (:method :poll)
      (:quit () t)
      (:keydown ()

Now a window did get created, but it didn’t play well with OSX (it wasn’t a “window” so much as a blank square of real estate on the screen, with a spinning beachball and no response).

So … the search for a basic simple drawing facility continues 🙁

Hash table utilities

People have referred to the usage of hashtables in ANSI common lisp as archaic. This isn’t necessarily true, but if you do feel this way there’s no need to stick with it. Here’s an example of how “radical utils” can simplify your life.

> (setf myhash (hash-table-from-alist '((apple . 2) (berry . 5) (lemon . 1))))
> (let ((acc 0))
          (dotable (_ val myhash acc)
        (incf acc val)))
> (print-hash-table myhash)

So, converting from an alist or a plist to a hash table is straightforward, as is iterating over it (notice the use of _ for the ignored “key” value).

(I’m slowly working my way through the (, so I hope it’s ok to post little snippets like these as I go along, even though this is a blog and I really should gather them up together. OTOH if I wait that long I’ll never get around to it)

Lisp is dead ? No, just lispers.

Came across this quote from the “Naggum-mine”:

An uncomfortable answer is that the Common Lisp community is hostile to creativity. People argue that Lisp is dead, but it is the Lispers who are dead. With a few exceptions, people who use Lisp have given up, and they only require, they do not provide.

Many Lisp programmers demand that sockets and multiprocessing should be standardized before they want to use it, which penalizes creativity like nothing else. Many Lisp programmers think it sucks to interface with other (inferior) languages, some in general, some because it isn’t standardized, some because they fail to understand how software is organized and want a perfect world.

Rutils ?

I was excited to try this out when I came across it … but it looks like (today!) the github repo is not in a compilable state, at least on Allegro CL.

CL-USER(44): (ql:quickload 'rutils)
To load "rutils":
  Load 1 ASDF system:
; Loading "rutils"
[package editor-hints.named-readtables]...........
[package rutils.readtable]........................
[package rutils.core].............................
[package rutils.misc].............................
[package rutils.anaphora].........................
[package rutils.list].............................
[package rutils.string]...........................
[package rutils.hash-table].......................
[package rutils.sequence].........................
[package rutils.pair].............................
[package rutils.tree].............................
[package rutils.array]............................
[package rutils.abbr].............................
[package rutils]..................................
[package rutil].; While EVALUATING an unknown function in
Error: There is no readtable named :RUTILS.READTABLE.RUTILS-READTABLE.
  [condition type: SIMPLE-ERROR]


It works fine on SBCL(!)

I think this is because Allegro CL (which, in its defense, is trying to be clever) supports a named readtable feature that is getting triggered by the text at the top of this file. Oh well, I guess I’ll have to stick with SBCL.

Anyway, coming back to rutils: read the announcement. I for one totally agree with this goal of collecting and consolidating utility code, and as a newbie, will do my best to learn as much as I can from it!

Page 1 of 2

Powered by WordPress & Theme by Anders Norén