Common Lisp, Cryptography, Development, LISP

ISAAC-64 Algorithm Added to CL-ISAAC

Over the long weekend, I finished porting the ISAAC-64 algorithm from C to Common Lisp, and it is now included in the CL-ISAAC package on GitHub: The new version (1.0.2) including ISAAC-64 will be available through Quicklisp in next month’s update; but if you would like to try it right away, you can clone the repo into ~/quicklisp/local-projects/ and give the Quick Recipe a try:

;; generate a 512-bit hex string token using ISAAC-64 context
(defvar my-isaac64-ctx (isaac:init-kernel-seed :is64 t))
(format nil "~64,'0x" (isaac:rand-bits-64 my-isaac64-ctx 512))
    => "6F00D098A342450CD7A2C27D941625ED70E7F7F4DD0BD46D8D1597361F0AA49180728D9BA062A14E6795F579D5B04B01F92310F18921A7397C57CF09012E104F"

Continue reading

Common Lisp, Development, LISP

Hacking Lisp in the Cloud

The other day I stumbled upon a very interesting new online service for developers, Cloud9 IDE. Imagine Sublime Text, a test server with command-line access, version control, live chat, code-sharing and live collaboration, all bundled together in one convenient web app, allowing you and your team to work together seamlessly from anywhere with an internet connection. With Cloud9 IDE, that’s exactly what you get—and that’s just what comes with the free account.

The service seems primarily tailored to Node.js developers, but also includes out-of-the-box support for Python, Ruby, and PHP. Naturally I decided it would be worth the effort to see if I could get a Lisp installation up and running—and in the end it wasn’t particularly difficult. The one set-back is that your Project Workspace is running on a version of Red Hat that includes v2.12 of glibc, which means that unless you want to compile both glibc and sbcl from source yourself for every lisp project you have on Cloud9, the latest version of SBCL you can install from the binary release is 1.0.23. Not ideal, but at least it works.

Continue reading

Development, LISP, Racket, Scheme, Technology, Virtual Reality

New Toys: (fluxus) and Oculus Rift

I got the email on Friday from Oculus VR that my Rift Developer Kit would be shipping soon. Naturally I’m pretty excited, since I haven’t used a VR headset since some tech expo I was at back in the 90s—and the Rift is substantially more advanced. I’m also quite excited for the 4-month Unity Pro trial license that comes with the Rift (not to mention Unity Pro’s new subscription license!).

So this weekend, with the expectation of the impending arrival of said hardware, I’ve been playing around with a bunch of different things. Exploring my options, as it were, to take full advantage of the Rift hardware once it arrives. I plan to write a Common Lisp wrapper to the Oculus SDK, as that will be generally useful for Lisp game developers; but it would benefit me more directly to have a toolkit in Lisp for procedural generation of 3D graphics.

That’s when I came across (FLUXUS), a really cool livecoding environment built on Racket (a relatively new flavour of LISP/Scheme). It doesn’t have support for the Oculus Rift, and I imagine it would be slightly difficult to type with a VR headset on, but at least it’s a step in the right direction. But that’s no matter, because (fluxus) is exactly the tool I was looking for, for my live music performances.

Continue reading

Common Lisp, Development, LISP, Quantum Computing, Quantum Programming, Technology

Hacking D-Wave One in Common Lisp: Introducing SILVER-SWORD

I’m pleased to announce that BURGLED-BATTERIES has not failed me (despite being far from finished), and I have been making steady progress with my Common Lisp interface to D-Wave’s Python Pack and Adiabatic Quantum Computer Simulator: SILVER-SWORD. It is now available in alpha as a Quicklisp-installable ASDF package on GitHub:

Features left to implement: reading and writing of qubo files, ising to qubo to ising converter functions, chimera graph indexing, and the BlackBox Solver.

Of course, you still need D-Wave’s Python Pack first, so unless you’re already a registered D-Wave developer, SILVER-SWORD won’t be much use to you. You will also need a few other dependencies, which are all conveniently listed in the repo’s README file.

That being said, I have already included a few tutorials, so you can at least see Common Lisp quantum energy programming in action.

Continue reading

Common Lisp, Development, LISP

Two Doug Hoyte Libraries, now ready for Quicklisp!

The other day I uploaded two of Doug Hoyte’s libraries that I’ve been sitting on to GitHub: the source code from his book Let Over Lambda, featuring a number of useful macros; and his Common Lisp version of the ISAAC-32 algorithm for fast cryptographic random number generation. The libraries are ASDF- and Quicklisp- installable, tested on SBCL 1.1.7+ on Arch Linux and OS X Lion.

Doug Hoyte’s code has been modified slightly to work under SBCL and load as libraries. Both libraries, just as Doug Hoyte’s original code, are released under the BSD Simplified License (attribution required).

You can get the repos here:



Continue reading

Common Lisp, Development, LISP, Python, Quantum Computing, Quantum Programming, Technology

Hacking D-Wave One in Common Lisp

Mostly for my own amusement, I’ve tried a variety of approaches to hacking D-Wave’s python pack in Common Lisp, from existing Python/Lisp bridges to Python-in-Lisp implementations to decompiling the binary in order to recreate C++ header files that could then be used as a basis for a direct CFFI bridge, without much success. Being that the D-Wave Developer Portal only ever offered a simulator of the company’s D-Wave One hardware for the Python language, and no C/C++ library with associated header files, this was a fairly significant problem as support for Python–Lisp bridges has always been extremely limited, and until very recently, such bridges did not support CPython libraries such as D-Wave’s Python Pack, or its dependencies such as Numpy. Enter burgled-batteries.

With the burgled-batteries library, I was hacking away at D-Wave’s Python Pack within the SBCL REPL in a matter of minutes. And according to the library’s author, it’s only the beginning. Support for Python introspection and calling Lisp from Python are in the works—but in the mean time, handy macros such as RUN and DEFPYFUN allow you to get at all aspects of a Python library in a manner familiar to those used to working with the CLPython or CFFI Common Lisp libraries.

Using burgled-batteries in its present state, it will now be a fairly straightforward task to recreate the Python Pack’s API in Common Lisp. Sadly, registration to D-Wave’s developer portal has been closed for some time (and very few developers registered for it in the first place), so the only person that will get to enjoy hacking away at a quantum computer in Common Lisp (as far as I know) is me.

That being said, I look forward to the continued development of burgled-batteries, and think it will become an invaluable tool for Lisp and Python hackers everywhere. Just think of all the libraries and frameworks we’ll get to add to Lisp!

Common Lisp, Development, LISP, Mobile Development

mocl: first impressions

mocl: Common Lisp for iPhone/iOS, Android, and other mobile platforms

As many Lispers are aware, the long-fabled and falsely-accused vapourware mocl was finally released by Wukix, pretty much right on schedule. Since it’s Canada Day long weekend, I decided to celebrate by getting myself the Personal License. The license fees are a bit steep, but hopefully the grand simplification of cross-platform mobile development through Common Lisp will make it more than worthwhile. Currently the only platforms supported by mocl are iOS and Android, but other platforms should be added eventually, ideally Blackberry 10 first. The download for mocl is available for Mac OS X and Linux (both 32- and 64-bit), but obviously if you intend to do any iOS development, you’ll need a Mac.

Edit: the latest version of mocl is now also available for Windows. – 09/16/2013

My first impressions of mocl are slightly mixed, unfortunately. The installation itself was both easy and seamless, but then I noticed that mocl’s ASDF support requires a link farm—a directory of symlinks that point to your *.asd files. Seriously, who uses link farms anymore? I tried my best to get Quicklisp working anyway, but to no avail. If there’s one thing mocl needs, it’s quicklisp support. Patiently, I symlinked drakma and all its dependencies to the mocl link farm and disabled SSL support as the documentation mentioned, but mocl’s experimental REPL crashed when loading it. Ah well. As it says when launched, the mocl REPL is currently “an experimental work in progress.”

In my next post, we’ll see if the example Contacts application from the Wukix github works or not.