C-Style Common Lisp Compilation Cycle (2013.09.09)

This article will be quick. I just realized that I can mimic the C compilation cycle for application written in Common Lisp. Here's some sample code, specific to Clozure Common Lisp (CCL):

(eval-when (:compile-toplevel :load-toplevel :execute)  
  (declaim (optimize (debug 0) (speed 3) (safety 0) (compilation-speed 0) (space 1))))  
(load "~/quicklisp/setup")  
(ql:quickload :drakma)  
(defun main ()  
  (format t "~a~%" (drakma:http-request "")))  
(save-application "a.out" :toplevel-function #'main :prepend-kernel t) 

Let's say that's saved as "foo.lisp". All I have to do is call ccl -n -l foo.lisp and bam!, I've got a new file for my ~/bin directory. Now I just need to create a toolset to wrap that up for use from the command line, and offer a feature to compile quicklisp projects that way instead of just flat files... And I suppose I could do a few other things too, like:

  • create a tool that launches a Lisp image as a subprocess to do the compilation step (so I don't have to leave my Lisp REPL).
  • ensure that argument parsing and STDIN both work
  • wrap errors so the application exists with a non-zero return value instead of accosting users with full Lisp debugging experience

For some reason I'm excited by this.

♪ I'm just sitting here watching the page scroll down and down... ♫ (2013.09.07)

Today, my objective is to use JavaScript to create a script that will enhance the scrolling experience at c0de, or at least make for a neat little demo. At the moment, there's no way to know what articles are present on a page without scrolling through a mass expanse of bad writing and busted code. I mean, let's pause for a second and consider the current page. The page you are viewing includes the following articles:

    How quickly would you have been able to figure that out without the above list? I'll grant that the formatting could use some work, but it's certainly a better, more concise view than the alternative, which (as I previously mentioned) involves scrolling past the bodies of the articles themselves, or maybe dropping a few lines of code into the JS REPL (that's what I'd do!). Bottom line, the list is useful. The thing is, I can't keep it. This article will eventually be buried, and the list, unless it finds another home, will be buried with it. Where, then, should I put it?

    The Idea

    At first I wanted to put the list of on-page articles in a sidebar block, but then I decided that would look too crowded - plus, those sidebar items will disappear from view if you scroll down far enough. My idea, then, is to have the items fade into view as a page overlay whenever the user is actively scrolling. Let's create an overlay now to see how it will look.

    I think that looks pretty good! Let's create another, this time using the actual article titles, spaced according to document position.

    If you're using a browser similar in capability to mine (Chrome), then clicking that last link should have demonstrated the essence of what I hope to accomplish. The only thing left to do is make it appear automatically when the page is scrolled.

    Working With Scroll Events

    The simplest way to respond to scroll events is to listen for mousewheel changes. Obviously this means our code won't respond if the user uses another of the various methods of getting around in a document, but I think that mousewheel scrolls account for the majority of user scroll interactions - and they're the only events I want an overlay to appear for anyhow.

    Here's a quick test to make sure the current browser () can respond to mousewheel events. There should be a red square below.

    Mouse around and it should fade to black. Does it? If not, the rest of this article doesn't apply to you; I'm not feeling too keen today so can't be bothered to build this cross-browser.

    Actually, the truth is that I'm feeling downright lazy at the moment. Instead of droning on ad nauseum, I'm going to close this article off with a link to enable the behaviour I set out to build, and leave you with instructions to view the source if you're so inclined. After enabling the behaviour, give the page a swift scroll - it won't activate for feeble flicks. That's by design; I don't want to have the menu pop up every time I scroll down a few lines in an article... I only want the menu to pop up when you "scroll with intent".

    Making Miniatures (2013.09.03)

    I've been racking my brain trying to find a practical, non-gimicky use for CSS3 transforms. Finally, I think I've found something, at least for the 2D portion of the spec - element previews. Let's say I'm building a gallery of sidebar items (I actually am). The idea is to be able to pick a sidebar item from a table and enable it on-page to see how it will look. Ultimately, I want to see exactly what any given sidebar item looks like when enabled, but even before that I want a vague notion of what all the blocks (vis a vis each other) look like. Rather than taking a screenshot of each block, I'd like to harness the power of the browser's rendering engine by having webkit create preview thumbnails for me.

    The first order of business is to get some element grabbing code. Here's a few lines that will slurp a block from the article sidebar item into the body of the article itself.

    function grabCopyOfSidebarItem(n) {
      var sidebarItems = document.querySelectorAll(".sidebar-block");
      var sidebarItem = sidebarItems[n];
      var clone = sidebarItem.cloneNode(true);
      clone.className = ""; = "";
      return clone;

    I'm not going to run that code just yet, but trust that it will copy the HTML (minus root-level ids and class names) of a numbered sidebar item into this article, assuming of course I've stored a reference to this article in the thisArticle variable. This isn't too exciting. What's more fun is cloning an element along with a snapshot of its style information. Thanks to getComputedStyle, this is completely possible - trivial in fact.

    function camelize(str) {
      return str.replace(/^-/, "").replace(
        function(a, b) {
          return b.toUpperCase();
    function cloneWithCSS(element) {
      var cssInfo = getComputedStyle(element);
      var elClone = element.cloneNode(false); = elClone.className = null;
      for (var i = 0; i < cssInfo.length; i++) {
        if (cssInfo[i].match(/border|padding|margin/)) {
          if (!cssInfo[i].match(/top|left|right|bottom/)) continue;
        }[camelize(cssInfo[i])] = cssInfo[camelize(cssInfo[i])];
      return elClone;

    We'll run that code to confirm it works. Here's what happens when we run that (shallow) cloning function on the first sidebar item. Note that the code removes the classname and id from the element being copied.

    It does seem to work. We'll need the contents of the node as well though; the shallow clone isn't too interesting. It's a simple matter to recursively clone the child nodes, however. All we care about is the text and element nodes.

    function deepCloneWithCSS(el) {
      var clone = cloneWithCSS(el);
      var children = el.childNodes;
      for (var i = 0; i < children.length; i++) {
        if (children[i].nodeType == 1) {
        } else if (children[i].nodeType == 3) {
      return clone;

    Awesome! With the code for cloning nodes (stylistically) out of the way, we can move on to the the fun part: the miniatures!

    Here's a randomly generated miniatures gallery. To generate the miniatures I just wrapped cloned elements in a sized down div with overflow set to hidden, then used the transform and transform-origin properties to scale down the cloned elements themselves.

    Essential Features (2013-08-07) is the most complete of the three personal dev sites I'm building, but it is still far from finished. When trying to mentally keep track of everything that needs to be done, it's easy to get distracted and forget what's important; c0de frequently finds itself stewing on the backburner while I work on some peripheral coding project that, even if I were to finish, would have to be bolted ontop of this website's woefully inadequate foundation. To remind myself of what major site related tasks are outstanding, I'm posting this article and will consider keeping it stickied on the front page.

    • Fix styles around the site. The CSS is very sloppy. This article, for example, looks terrible.

    • I need to build an administrative section. Tending to adminstrative aspects of this site through code alone is starting to feel primitive.

    • Articles need to have their own pages. They're still not an actual content type. Right now I'm just plopping HTML onto the front page. I need to do better than that.

    • I need the infrastructure for attaching meta data to articles. I'm thinking about including meta data in an s-expression at the top of markdown files (actually, I should probably write an article about this...)

    • I need a Trello-like system for moving articles from their nascent state as ideas all the way through to publication.

    • Articles should accept comments.

    • I need a working search engine. I don't think many people actually use the search engines built into most websites (most prefer to use things like Google) but it's hard to take a coding site seriously if it doesn't have a search engine set up.

    • I would like to build a system around git hooks for accepting code changes. I don't want to /have/ to connect to the site's Lisp image and recompile functions (although I will of course reserve that as an option). A simple tweak to a local copy of the site's code followed by `git push' should be all I need.

    • Get Ace rigged up. As reliable and awesome as services like Github are, I don't like relying on outside services for core offerings of the site like source code. Also, I would like to build some intelligence into this site to organize code snippets from articles. Maybe include code snippet metadata?

    • Projects page should link to the projects I'm actually working on. All projects should have a corresponding github page.

    • Projects page should have a project where I should be tracking day to day progress. Basically, I ought to build a simple habit tracking section into the projects page as a way of publicly commiting to the continuous improvement of this site.

    Anyhow, one of my resolutions is to stop holding back from publishing articles just because they aren't perfect (or great, or hell, even good). So, the above list is as good a place to start as any. The end.

    Uninspired Coding (2013.07.22)

    Today I couldn't think of anything to write about. I aim, however, to be a better writer, so I'm going to write about nothing. I'm going to grind through the unpleasantness of an uninspired topic in order to improve my chance at having something useful to say next time I attempt a blog post. I think that's the right thing to do.

    Output that isn't rooted in uncommon genius can still be good. This applies to writing, and it applies to coding also. Too often I trip over my ambition, and, failing to live up to my aspiration to be the author of an article of dazzling greatness - an article, say, that is front page of Hacker News material - I contribute nothing to the Internet at all. Also, I avoid rocky starts. And rocky middles. And, really, any inhospitable terrain, now that I think of it. This is not how great things are made.

    Grinding at a challenge can be fun, in it's own way. It sure takes the pressure off. I don't feel I'm responsible to anyone but myself when I'm on the grind. And, although I don't feel obliged to be creative, doing boring work can be a source of newfound creativity, at least for me; my mind, tortured by the banality of its present station, is impelled to get up off its lazy cortex and start pumping protoplasm in search of a detour. It doesn't necessarily find a way around the challenge du jour, but I think there's some truth to the metaphor of "creative juices" - once sloshing around in my noggin, this potent fuel can be applied, like acid in a battery, to whatever task needs solving, without prejudice as to whether I should be solving said task or not.

    Uninspired coding opportunities abound. There are all kinds of challenge lists floating around. You could try a few Project Euler puzzles, or have a look at The Programmer's Idea book. Maybe pour over Rosetta Code in search of something to work on, or pick a task at random from the Ruby Quiz archive. Or, hey, here's a novel concept: you could finish one of those old projects you abandoned once verve for the task was lost. Yes, the projects you find in these places will lack that sexiness inherent to original ideas dreamed up in the spur of the moment, but they will be a way to better yourself in the here and now, without any dependency on such a finicky process as inspiration.

    I want to do more of my coding with a training mentality; I want to deliberately practice my craft. Is what I'm working on when training going to change the world? No. But if I do it every day, and if I live long enough, I will eventually be a great programmer (as opposed to merely a good programmer) -- and great programmers do change the world. Toiling to make every one of my programs great (instead of striving to make myself great) will undermine success in the grander arena. Greatness is as greatness does, so I will have to toil at some epicly proportioned undertaking eventually--but this will be my Everest, and one does not summit Everest without preparing themselves beforehand. So, for the next little while, when I'm at home and struggling to find something to work on, I'm going to spar, not fight - I'll code to better myself, not impress my peers. This might mean I will fight to lose... But I'm okay with losing for a while.

    Cheat Day (2013.07.16)

    Today, once again, I'm going to compare programming to weight loss. Maybe (probably) I'm overextending the metaphor, but getting in shape and transforming oneself into a world-class programmer are both long, grueling journeys. Grueling journeys, as a topic, are well covered in the fitness world. Contrast that with hacker wisdom. Hackers as a rule look for shortcuts, holding laziness to be a virtue. Granted, when someone uncovers, through ingenuity alone, an uncannily simple method to bypassing a sticky set of problems, it is a beautiful thing to behold--but not every path has a secret diversion waiting to be discovered. Some problems (like attaining mastery in any given subject) are just plain hard, and can be solved with little else but brute force. I hold that jocks have a thing or two to teach us about these less tractable sorts of challenges, where it takes muster to move on; where its a dogged plod towards a goal that is a long way off, to which it will take strategizing and planning, tenacity and determination - where you will fall down, but have to get up, because you are in it for the long haul on a journey you refuse to quit. Okay, so that sounded like prose written for a footwear commercial, but the point stands, so let's move on.

    I've been holding strong to my diet for over a month and a half. Despite spartan-like adherance to a primal (whole foods based) eating plan, and despite upping the intensity of my exercises, I've been stuck at a plateau for the last couple of weeks. This has been frustrating because I don't yet have the body I want, and because, as a participant in a friendly bodyfat losing competition, I'm held accountable to show some marker of progress week after week. When I entreated to Google for answers, I was directed to a community of body builders where a softbodied visitor who was "doing all the right things" was being reprimanded by one of the community's meatier denizens; the ambitious young hopeful was told that plateaus can be broken by temporarily loosening up and breaking diet - by incorporating a "carb up day", a.k.a., a cheat day.

    I found this intriguing. I always assumed cheat days existed purely to lessen mental stress - I thought they were for the weak, and while perhaps reinvigorating to the will, I never imagined that they could directly improve a persons physicality through nothing more than the biochemistry of their physiology. Apparently, though, they can shake things up and help dieters blast past barriers imposed upon them by their bodies. This got me wondering... What if I gave myself a programming practices cheat day? Could it possibly be a good thing to, for just one day, forget about maintaining structure and sensibility in my codebase? To haphazardly lift, all devil may care, a snippet of code glowing green on the walls of some shady forum?

    I haven't tried this yet. My hypothesis is this, however: mindfully abandoning good practices for a day will improve programmer creativity. It will illuminate options that were shuttered away, as thoughts once verboten get freedom to bloom. It will carve new neural pathways and boost programmer confidence in that way that only hacking up a working (if rickety) prototype can. Mistakes will be made, and fires will have to be extinguished. But maybe, in the same way as a cheating with food can boost one's metabolism into a hot frenzy, letting your sacred cows out to pasture for a day will enliven the passion you have for your craft in the days that follow. And, even if none of these things occur, at least you will understand why best practices are, well, best.

    Healthy Activities Database (2013.07.14)

    I'm trying to be more healthy; I want to keep my mind sharp and my body vital. It helps me think better and code better. My diet is mostly on point, and because I so frequently stuff my face wtih nutritious grub, my metabolism seldom rebels with uproarious demands for those out of bounds yet toxically delicious foods I've sworn to avoid. Note that I said seldom - cravings do happen, and today was one of those days.

    What kept me on track this time is the fact that I'm barely scrimping by from paycheck to paycheck (I'm saving up to do some major travelling next year), and so much a to do is made about every fiduciary decision--even those as minor as a pitstop at a burger shop. This compels me to reflect on whether I'm getting value for my money by buying something that will (a) leave me nutritionally unsufficed, veering my overall health off course; (b) trigger further cravings that will be detrimental in opposing directions to the weight of my body and the weight of my wallet; and (c) cause me to feel shame. Of course, I don't always keep these counterbalances in mind; it's all to easy to justify an indulgence when fixated trance-like on the glorious smells that saturate the air as clouds of grease billow from a roadside foodcart in heavy beckoning waves. I'd better come up with a solution.

    One idea for keeping a clearheaded sense of perspective is to contrast what healthy activities I can afford for the same dollar amount as the cheat meal that tempts me. To that end, I've decided to code up a simple, CRUDy database of healthy activities in and around Vancouver. Lettuce (har har) begin!

    The obvious starting point is to define the database's table structure. Well, actually, we have to decide what database to go with first. This is an easy choice for me since PostgreSQL is already up and running on my server and I have a utility function predefined (in Lisp, as I do) for authenticating with said database using postmodern.

     (defpackage :c0de.healthy-activities
       (:use :cl :alexandria))
     (in-package :c0de.healthy-activities)
     (defun create-database ()
       "Creates a table to store healthy activities in."
         (pomo:execute (:create-table :healthy-activities
                          ((:id :type :serial :primary-key t)
                           (:activity-name :type string)
                           (:activity-cost :type double-precision))))))

    A function for adding a healthy activity will be necessary...

     (defun add-healthy-activity (activity-name activity-cost)
       "Adds a healthy activity to our database."
         (pomo:execute (:insert-into :healthy-activities
                        :set :activity-name activity-name
                             :activity-cost activity-cost)))) 

    While I test my code I'll be filling the database with junk, so we'd better define a function to erase everything:

     (defun wipe-all-healthy-activities ()
       (when (yes-or-no-p "Really delete everything?")
           (pomo:query (:delete-from :healthy-activities)))))

    Now all there is to do is fill up the database. Unfortunately, that's a lot of work... All I can really do is try to make it easy to add new activities. This may be a stupid thing to do, but here's a form for adding new activities (and costs) to my list. Please help out if you can!

    Rock climbing$20.00
    Testing Again$3000.00
    Final Test$5000.00
    Yet Another Test$1.00

    Writing For Myself (2013.07.07)

    I'm getting really tired of making these pseudo-apologetic posts about how seldom I update this blog and how I'm going to do everything I can (yadda, yadda) to ensure that the dry spell will pass. The fact of the matter is that working full time, pursing my various goals and consistently updating this blog is at the present time too much for me to handle - but I'm not convinced that it has to be.

    I've come to realize that a big part of what's getting in the way of my productivity as a writer is that I've endevoured to write for some imaginary audience which most definitely does not exist right now. It's time to face the facts... As far as Google (and therefore Earth) is concerned, this blog barely exists. I mean, it doesn't even register in a search for "c0de". Hell, this page isn't even a blip in the listings for "c0de Vancouver". So why not use the sore lack of SEO to my advantage by dispelling any phantoms of anxiety about pleasing an audience and getting on with writing for myself?

    I believe that by taking the pressure off to cater to an audience the words will flow more naturally and this blog's growth will be stunted no more. I will make a point of writing every day (I am hoping to build a habit of it) but I won't be writing for anyone other than this guy, right here. Posting to my blog will be a decidedly unwork-like process and entirely optional; more a way of distilling my thoughts than anything else. If it becomes a journal, so be it. At least I will have accumulated some content; this in turn may spur further development on the code that shapes it; code which won't discriminate against the banal.

    Anyhow, I've done what I have to do today. I wrote something. To John Q. Public, watching me kick my own ass to write more probably isn't altogether gripping. It is however necessary. Maybe some good will come of this newfound aloofness towards my audience. Tomorrow I plan to write (indeed, for myself) an article about my coding bucket list - that is, the things I hope to accomplish as a programmer before I die. Wish me luck.

    Project Update (2013.04.04)

    While transitioning this site from plain old Hunchentoot to RESTAS, it occured to me that it's been a year since my last update! I wish I could say I've done a lot of work behind the scenes, but the truth is that I'm only just now dusting off this project and cracking back to work.

    I may have learned a thing or two about Lisp since April 2012, but only time will tell how applicable any of it actually is. My number one priority right now is to get the database running. About a year ago I evaluated rucksack and determined that it would not work for this site; the machine's heap crumpled under the combined weight of the montezuma search index and rucksack's in memory store, leaving much of my data corrupted. If I do decide to go the NoSQL route, I may switch to elephant, having had a positive experience with this library on my local machine, but for now I'm leaning towards plain old PostgreSQL.

    PostgreSQL should be relatively straightforward to set up. One thing I do not want is to have to store my database username and password in the source of this website. To that end, I recently created a little helper library called "config", which makes it slightly more convenient to sock away and retrieve information in the ~/.config/common-lisp/ directory.

    Now, as to the unpleasant absence of any real content at c0de: I do plan to fix this. Starting now, I'm going to make writing brief, probably stupid articles a weekly priority. And by articles, of course, I mean blog posts like this one.

    This Blog Is Being Built With Common Lisp (2012.04.30)

    This article sucks. I know it sucks. It's meant to suck. The fact is, I need to get used to publishing things that are not good. So I'm publishing this article, even though it is not good.

    I've gotten back to work on my blog. It may not be obvious, but this blog is not built on top of Wordpress. It is a custom built Common Lisp application, albeit a very basic one. I understand it is not as nice as a blog built with Wordpress. I understand that it will never be. I am doing this to learn.

    As I mentioned, the code running this blog is written in Common Lisp. The web server I am using is called hunchentoot. At the time of writing, all articles are being stored statically as function definitions, but I plan to use rucksack (a persistent object store) going forward.

    I'm using Emacs to edit the source code that constitutes this blog. I edit it through SSH using Tramp. On the remote server I am running screen; a detached terminal is running Emacs, which in turn is connected to the Lisp image which has my blog's code loaded. Every time I edit a file I have to connect to that Lisp image and recompile the file I edited. This is not the Lisp Way--I plan to improve my workflow in this respect.

    The search engine is not yet functional. After I get rucksack working I will hook up montezuma for search indexing. To fill my rucksack with articles for the search index I will build an admin control panel that uses cl-markdown and Ace for text entry.

    When I've done all that and my blog finally has a heartbeat, I will push the completed platform to GitHub. I'm well aware that there are already blog platforms written in Common Lisp available through GitHub, but they weren't invented by me, so better make room for one more.