Skip to main content

Install current SBCL on OS X

You must have Command Line Tools installed. If you don't, this tutorial is not for you. Google: installation of XCode and Command Line Tools.

Normally, I use brew to install things (when it offers a solution), but in this case the keg version was a couple minor version's off. And, there had been sufficient addition's that motivated me to want the current release. So, building from source was the path of least resistance.

First, what not to do:

The note's caution against using OS X's Terminal, as their make.sh script pukes a shit-ton of text during the build, and according to them, it can slow the build. I did not experience an issue with this, compared to other builds I've done in the past.  BUT, they also say build can be accomplished with other LISP's installed (you must have a lisp installed prior to building). OMFG, unless you want to wait a month of Sunday's, my experience building with CLISP was slower than the Molasses in January.  Do yourself a favor if you don't have an install of sbcl already  (likely from brew as it is a few minor version's behind the current one at this time), install sbcl from brew FIRST!!!  Build went so much faster.

So, here's what I recommend:

Install sbcl using brew.  If you don't already have brew installed, why the frak not?  Install it. You can thank me later.

Ok, so you've installed sbcl using brew. Now, download the current version from sbcl's website,  untar/unbzip it, and cd into the new directory. For illustrative purposes, in my case it's /sbcl-1.2.5. Once inside, you can follow their prescribed method (you may need to sudo first):

sh make.sh

It will pick-up the current install of sbcl and use it. Once it's done, uninstall brew's version of sbcl:

brew uninstall sbcl

Now, (again, you may need to sudo first):

sh install.sh

You should now have the current sbcl available in your path at:

/usr/local/bin/sbcl

Comments

Popular posts from this blog

Codeigniter vs. Kohana Database access speeds

I was doing some basic profiling for a project in which I needed the fastest raw speed I could get with database queries. I'm a fan of Codeigniter for projects that are suitable for it, but had heard from some that Kohana was faster, so I decided to do a very basic comparison of the two. I was using MAMP for OSX, and created a very small db, with a table that had 3 fields: (id), (first), and (last). The data sample was also very small, only a few records. The basic query I tested was a "SELECT * FROM [table]". There is of course nothing remotely scientific about this. It was just a quick ad dirty, very limited comparison. Take it as such. Versions used: CI2.1.3, Kohana 3.3.0. Codeigniter I really like Codeigniter (CI). But, one thing that is very evident from their own profiling functions, is that CI is a bit of a memory hog! Essentially, the same Controller function running in CI takes approximately 10X more memory than in Kohana! This in itself is not ...

Passing Functions and Lambdas into Functions with Ruby

Ruby's New Style of Lambda Functions f = ->( m ) { p m } f.call( 1 ) #=> 1 Which of course means the same thing as: f = lambda { |n| p n } f.call(1) #=> 1 Ruby Proc Objects p = Proc.new { |n| p n + 2 } p.call(2) #=> 4 Using a Function as a Closure in Ruby def domo( k ) ->(m) { p m + k } end z = domo( 5 ) z.call( 5 ) #=> 10 Function :domo takes a single parameter. Within :domo , we create a lambda that takes a single parameter, and adds that parameter to the value :domo takes in as its parameter. Then, we assign z to be the result of the lambda in :domo with its 'k' parameter loaded with 5. When z is called, we pass (another) 5 to it. This parameter loads the lambdas n parameter. The lambda executes, essentially adding n (5) + k (5) and yielding the result of 10. The thing about closures such as this is, we can load the initial value of the lambda to be whatever we want it to be when assigning the function :domo '...

Screen Scraping in Ruby with Watir and Nokogiri

I was given an interesting challenge to scrape some data from a specific site.  Not to write a completed, packaged solution, but rather just to scrape the data.  The rub being, the site uses Javascript paging, so one couldn't simply use something like Mechanize.  While a self-contained product would require inclusion of V8 (as the Javascript would need to be run and evaluated), to just scrape the data allows making use of whatever is easy and available.  Enter Watir . Watir allows "mechanized/automated" browser control.  Essentially, we can script a browser to go to pages, click links, fill out forms, and what have you.  It's mainstay is in testing, but it's also pretty damned handy in cases where we need some Javascript on a page processed... like in this case.  Keep in mind though, it is literally automating a browser, so you'll see your browser open and navigate to pages, etc. when the script runs.  But, there is also a headless browser opti...