Lisp Pipe

The Zipper [PDF]

Sat, 21 Nov 2009 06:51:45 -0800

submitted by lispnik
[link] [16 comments]

Zach Beane: Go try XONG

Sat, 21 Nov 2009 12:09:34 -0800

David O'Toole put out version 1.0 of his roguelike puzzle game XONG yesterday.

When he asked me to try it out, I expected some headache when downloading it, compiling it, grabbing libraries, etc. Nope! I'm using Snow Leopard on an Intel MacBook. I grabbed the .dmg, double-clicked the xong icon, and it ran perfectly. It bundles an executable SBCL image together with the graphics, sounds, and libraries it needs, so it's completely self-contained and looks like any other Mac .app bundle. It's nice to see this kind of application delivery.

Lispjobs: Software/firmware developer (Lisp), San Diego, CA

Sat, 21 Nov 2009 08:18:09 -0800

For biomedical devices, Software/Firmware Developer – Lisp (Contract to Hire).

Zach Beane: LISP is difficult to learn

Fri, 20 Nov 2009 15:05:35 -0800

The local grocery store has a big bin of used books for $1. After seeing a 1983 computer dictionary's description of LISP, I knew I had to buy it:

It says:

LISP acronym for LIST PROCESSING a high-level programming language use primarily for list processing, symbol manipulation, and recursive operations: it can handle many different data types, treat programs as data, and provide for the self-modification of the program as it is executing: generally considered a difficult language to learn

(Emphasis mine.)

François-René Rideau: Software Irresponsibility

Fri, 20 Nov 2009 06:05:02 -0800

In the way of achieving a healthy software development environment, a lot of projects fall in one of these two DON'Ts: irresponsibility and territoriality. Irresponsibility is when there is no one in charge of making things right (with respect to a whole category of problems). Territoriality is when there is someone in charge, and he won't let anyone else touch the code without him. They may sound opposite to one another, but often irresponsibility is a result of territoriality, where the person in charge just isn't interested in the kind of problem you're experiencing, and so any consideration for such problems gets disregarded in favor of whatever fits the interests of the maintainer.

As a notorious example of irresponsible software design, I will cite PHP, whose maintainer has repeatedly claimed he was never interested in designing a good programming language. It shows. But I'm sure you'll find plenty of familiar examples in your own experience, from the irresponsive provider of some proprietary software you've been locked into using, to maybe someone from some other department of your company that you've had to deal with, and perhaps even to yourself with respect to your own users.

Of course, it is always possible to start a new project to replace the software you're dissatisfied with. But the costs associated to such endeavour are often huge. You will have to reimplement not just the parts that the replaced software did wrong, but also the parts it did right. While by assumption you can clearly see parts of the design that are wrong and do better with respect to those parts, you may be lacking the proficiency, time and interest to do as well on these other parts. Last but not least, the community around the original software, that made it valuable, will not switch to the new one for merely small gains, and the transition from the old system to the new system may impose demanding constraints of backwards compatibility.

Free Software can drastically reduce the cost of starting a new project, by allowing you to fork the existing code base, copy large chunks of it, or at the very least read the code of what you may have to be compatible with. It does make the cost go down to zero, however. There again, cruft that made the original software bad enough that you felt like changing it will be a heavy burden upon you if you keep it, and a huge setback to reimplement if you decide to throw it away. And even in the world of free software, some licenses can incur a higher cost to forking than others: for instance, licenses that force you to distribute the code as source, that prevent you from making any adaptation and keep the name, or otherwise put hurdles in the way of forkers.

In the world of Common Lisp, an interesting case of not-so-responsible software is ASDF. Yeah, some of you might be tempted to sneer, is he going to blame the problem with ASDF on the original author who is long gone, and the current maintainer who isn't committing enough energy and availability to making the project go forward? No, not at all. Dan Barlow actually did a great job while he was there, and if no one is stepping up to offer more than Gary King provides, it's certainly not Gary who's to blame; he is getting blatant bugs fixed and accepting consensual patches, and at this point forking would be trivial to fork the git repo if anyone were dissatisfied with Gary's performance. Rather, I'll argue that any problem with ASDF is a symptom of the way responsibilities are distributed with respect to its update, and propose a small technical change that can hopefully improve things a lot.

When Dan Barlow wrote ASDF in 2001, he only wanted a better CL build system that he could use on top of SBCL for his own projects, something that would be more declarative than the previous best alternative, MK:DEFSYSTEM, and would only need to support modern ANSI CL implementations, not old forgotten Lisp variants. In developing ASDF, he loosely followed the better design principles once proposed by Kent Pitman for an extensible CL build system. In all those objectives, ASDF was a tremendous success, and CL users should all be grateful to Dan was his achievement. However, as usual the problem lies with issues he didn't try to tackle.

Problems with ASDF include the painful way you have to configure it, deficient support for documentation or testing, broken support for conditional compilation, missing support for generated files, its weird TRAVERSE algorithm, etc. Unlike the issue of deterministic incremental compilation that prompted me to start XCVB, none of the above issues is unsolvable in itself. But the constraints within which ASDF is developed make it hard to solve them. Happily, some of these constraints can be removed with a little bit of hackery. Unhappily, others are intrinsic to the choice of constraints.

Indeed, ASDF has a distribution bootstrap problem: it specifies how to load other systems, but nothing specifies how ASDF itself is loaded into your system. That problem is left to whoever writes the Lisp implementation, distributes the Lisp package, or maintains a larger project within which ASDF is used. And in the world of Common Lisp, there are tens of different implementations, many of them packaged in various ways. To make the problem tractable, ASDF follows the constraint that it comes as a single file that may be loaded independently of its location, and doesn't depend on any third party library beside what is included by each supported implementation.

This means that the provider of libraries that use ASDF must rely on the least common denominator of ASDF features, unless he wants to force his users to make sure they upgrade their ASDF. Upgrading the current ASDF could conceivably be easy, but is actually hard, because of the inability to hot-upgrade a loaded ASDF. It is still possible to remove an old ASDF and replace it, and XCVB does it in an ugly way (see how xcvb/no-asdf deletes the ASDF package and anything that uses it); however, files compiled against the old ASDF may not work with the new one and vice versa (I've had "interesting" issues that way while using xcvb-master in slightly different setups).

This inability to upgrade further makes the pre-packaging of a Lisp implementation with a given version ASDF a bit of a damned if you do, damned if you don't proposition to Lisp implementers and distributors. Happily, implementers have the option of only providing ASDF when REQUIRE'd, and this is the preferred way for users to specify they want to use ASDF, when it is available. Distributors may not have this option inasmuch as there is no standard mechanism to hook into an implementation's REQUIRE. An example of a failed attempt at distributing Common Lisp with ASDF is common-lisp-controller. It tried to provide a way to make sure there is always a configured ASDF, but their solution only works if everyone uses only debian or another supported OS distribution, and only if the debian maintainers keep up with all the common-lisp software (implementations and libraries) that one may want to use; two hypotheses that have been disproved in practice with respect to the needs of many users.

To step back to the problem of responsibility, the current constraints of ASDF are such that a consistent upgrade of ASDF requires action on the part of tens of people, each in his own territory: ASDF contributors, Lisp implementers, package distributors. If only one hacker alone decides to upgrade ASDF, he has to incur the cost of the associated work of modifying ASDF and the risk that this will introduce incompatibilities, for little overall progress in terms of what users may rely upon unless he convinces tens of other people also do the same. Thus, the costs of adoption are high, the benefits of development are low, development is slow, and a cycle of stagnation continues.

If someone cares about the future of ASDF, I recommend they should address the upgradability bug, which will itself unlock a big hurdle on the way of further evolution of ASDF. Note that this upgradability includes both the technical ability to load a new ASDF on top of an old one, but probably also the proper configuration of ASDF, to load systems from a series of configured paths declared in user and system preference files.

Personally, I'd rather work on XCVB, and invite people interested in build systems to work on it instead of ASDF. But if XCVB is to prevail, it may as well prevail against the best ASDF that ASDF can be.

XCVB tries to avoid all the problems of ASDF by stepping back from the assumption that everything happens in a one Lisp world that has already been setup. Instead, XCVB will manage many Lisp worlds that it will help you setup. It doesn't live inside your Lisp image, and thus doesn't depend on Lisp implementers or distributors to provide it for you; it can therefore evolve fast without any issue due to slow distribution. It is also liberated from the constraint ASDF has of itself having no dependencies, because these dependencies would both make bootstrap more difficult and interfere with other versions of same software as part of the software being built. XCVB thus reuses plenty of libraries and is richer in features, and will use even more libraries in the future. All this in addition to its original essential distinguishing feature of providing deterministic incremental compilation.

XCVB isn't complete yet, but I believe that on supported implementations (currently only SBCL, CCL, CLISP, but I could add more on demand, or you could do it yourself), it is already better than ASDF. If you care for CL build systems, please fix ASDF; but please give XCVB a try, too.

Even if you don't care for CL build systems, organize your software developments so that every upgrade step can be done by the single maintainer of a single project, without requiring the coordination between many people in many different projects.

This lesson should be particularly dear to those who dream of making a Standard for Lisp, Scheme, Javascript, Java or any other language or piece of software: if you need to agree on something that will require future coordination between plenty of people, it is almost sure to fail to evolve fast enough to remain relevant, even though one or two iterations might make it live (see e.g. R6RS and its current attempted successor). Instead, you should offer software that already runs with a free software reference implementation that others can trivially adapt to their systems if needed (also in Scheme, compare the SRFI process). After your code has become de facto standard, you might not even care for it being any kind of de jure standard anymore. Whereas if there's going to be a de jure standard, it will be blood and conflict as long as there's anything to disagree about, and still resentment at the unsatisfying compromise that results.

The same idea also accounts for Conway's Law: if you divide your software project between many teams, each team will build its own code base, and the structure of the software will end up following the structure of the teams that build it. Parts of the software where the ownership is not clearly assigned but where authority is divided will be the scene for conflict, slow evolution, bad design (if design at all), etc. Vertical disintegration, where independent teams manage layers of the software and its life-cycle, will in particular lead to a multiplication of such dysfunctional interfaces between entrenched overlapping code bases the global architecture of which cannot be refactored.

Happily, solving the problem of irresponsible software is much easier than solving the problem of irresponsible government.

Vladimir Sedach: November Montreal Scheme/Lisp User Group presentation

Thu, 19 Nov 2009 13:36:00 -0800

On November 17, I gave a presentation to the Montreal Scheme/Lisp User Group about developing high-performance network servers in Lisp. I looked at the lessons to be learned from existing Common Lisp web servers, notably Antiweb and TPD2, tried out some of the ideas in my own new under-development web server HTTP DOHC along with some new ideas about threading and concurrency, and put the results of my findings into the presentation.

If you're interested in the topic, you should also watch John Fremlin's TPD2 presentation to the Shibuya Lisp user's group.

I plan on making HTTP DOHC a full-featured Common Lisp web server with an interface that's somewhat compatible with Hunchentoot 1.0.

In other news, I now have time available for contract work. Get in touch at vsedach@gmail.com.

Patrick Stein: Playing with Sheeple-based GUI atop CL-OpenGL

Thu, 19 Nov 2009 08:59:55 -0800

Inspired by the previous TC Lispers meeting and spurred on by the probable topic of the next TC Lispers meeting, I have spent the little bit of coding time I’ve had over the past two weeks on making a GUI layer using Sheeple atop CL-OpenGL and employing ZPB-TTF for font-loading.

I have dubbed this project Woolly (because it’s made from Sheeple and because Woolly sounds sorta like GUI).

I spent about half of my coding time so far getting the basic framework in place (proven through clickable buttons with labels). I am trying to keep it cleanly separated between generic GUI stuff and the CL-OpenGL specifics in the event that someone would like to port it to some other I/O spec.

The other half of my coding time was spent getting the font-rendering to be anti-aliased. I promise to write more about how I accomplished the font-rendering in a future post so that if you’re ever stuck rendering fonts in OpenGL, you won’t be stuck with pixelated blockiness or resorting to rendering to a texture-map and letting the mipmapper figure it out.

For this post, however, I’ll just show you the code that sets up the interface depicted here.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

(require :asdf)
(asdf:operate 'asdf:load-op 'woolly-gl :verbose nil)

;; make it easier to change renderer/controller later
(rename-package 'woolly-gl 'toolkit)

(defun test ()
(let ((font (sheeple:object :parents toolkit:=font=
:em-size 48
:pathname "okolaks/okolaksRegular.ttf")))
(let ((app (sheeple:object :parents toolkit:=app=))
(win (sheeple:object :parents toolkit:=window=
:title "Woolly Window 1"
:width 640
:height 480))
(but (sheeple:object :parents toolkit:=button=
:offset-x 40
:offset-y 40
:width 300
:height 100
:font font
:label "Button")))
(woolly:display-window win)
(woolly:add win but)
(woolly:main-loop app)
(woolly:destroy-window win))))

Next up on my agenda is to make the background and button prettier. It should be easy enough to do with GL_LIGHTING and some vertex-coloring for gradations. After that, it’s on to more controls like labels, panels, checkboxes, drop-downs, borders, and (my dread) text input boxes. Then, it’s on to a layout manager.

Edit: Here’s the same GUI a day later. I’m using a simple lighting scheme and rendering the button in 3D. I haven’t yet hooked in the bit to render it depressed when the button is pressed. I’ve tested the code that draws it the other way, but I haven’t hooked it into the mouse handlers yet.

Edit #2: Actually, it only took a few minutes for me to hook in the rendering it pressed vs. unpressed. When I did it though, it looked like the label was sliding around because the effect of the contrast between the light and dark edges of the button was so great that you perceive the whole button sliding when it’s pressed. So, I added a little bit in there to actually slide the text by an amount close to what is perceived. So, now… it looks pretty spiffy.

Christophe Rhodes: 19 Nov 2009

Thu, 19 Nov 2009 05:24:17 -0800

A while ago now, Nikodemus Siivola moved bug information for SBCL from a flat text file to Launchpad. Historically I have had almost nothing but displeasure working with the "standard" or "industrial" bug trackers; I have found Bugzilla horrible to work with, both as a bug reporter and as an administrator; lighter-weight solutions such as Trac are just about tolerable, but basically anything that requires me to have a Web Browser seems to end up confusing and distracting me. An honourable mention at this point goes to debbugs: being able to report, manipulate, update and close bugs by e-mail is close to my idea of Nirvana.

So, Launchpad. Initially, I was dismayed, because there doesn't seem to be a way of getting notifications of bug updates over RSS, which would be a second-best to getting updates by e-mail. I managed to ignore all SBCL bug reports for a while, but eventually I bit the bullet and signed up (having refused to do so a good long while ago, when shortly after I used Ubuntu's bugzilla to report a bug they closed the bugzilla in favour of launchpad without managing to transfer accounts across.)

A large motivation for signing up was the discovery that launchpad does, in fact, have an email interface to the bug tracker; as long as you can emit GPG-signed mail (which I can), it seems to have all the required functionality for doing things without needing to go near a web browser; I can now receive bug reports and reply to them, and in at least some cases the References: headers in the mail I receive allows my client to thread the discussion properly (I haven't really stress-tested this yet, but it works at least well enough for now.)

If that were all, this would not be news (and not even worthy of a blog post). But now I get to demonstrate my Emacs lisp “scripting” ability, in much the same way as Dan Barlow did for me many years ago: SBCL has a mailing list for reporting bugs, for people who are unsure as to whether their problem is a bug or not, or for people who don't want to go to the trouble to get a launchpad account just to report a bug. When such a report does describe a new bug that we should be tracking, that report needs to make its way to launchpad.

Without too much further ado, I present sbcl-bugs-mail-forward, which constructs a message (almost) ready to be sent:

(defun sbcl-bugs-mail-forward () (interactive) (let ((message-forward-ignored-headers "") from subject) (gnus-summary-mail-forward 4) (message-goto-to) (insert "new@bugs.launchpad.net") (message-goto-subject) (message-beginning-of-line) (re-search-forward "\\[\\(.*\\)\\].*\\[\\(.*\\)\\] \\(.*\\)$") (setq from (match-string 1) subject (match-string 3)) (message-beginning-of-line) (let ((kill-whole-line nil)) (kill-line)) (insert subject) (message-goto-body) (insert "Report from " from "\n\n") (insert " affects sbcl\n status confirmed\n importance ") (save-excursion (insert "\n tag \n done\n\n") (message-goto-body) (re-search-forward "^\\(-\\)+ Start of forwarded message \\(-\\)+$") (beginning-of-line) (let ((kill-whole-line t)) (kill-line)) (re-search-forward "^\\(-\\)+$") (beginning-of-line) (end-of-buffer) (kill-region (mark) (point))) (mml-secure-message-sign-pgpmime)))

You can tell it's scripting, really: it's an odd mixture of plausible and dubious ways of getting things done: regular expressions to extract the original sender of the report, and to remove the forwarded message information (and the dull advert inserted in the footer by SourceForge's mailing list system). On the other hand, that function, coupled with something along the lines of

(setq gnus-parameters '(("nnml\\+private:list.sbcl-bugs" (gnus-summary-prepared-hook '(lambda () (local-set-key (kbd "C-c C-f") 'sbcl-bugs-mail-forward) (local-set-key (kbd "S o m") 'sbcl-bugs-mail-forward))))))

gives me exactly what I think I want: a simple way of creating, tagging and classifying an entry in the bug tracker from a mail report.

I couldn't find any convenient emacs/launchpad interfaces (or any at all, in fact); I'm not sure this counts as one either, but by all means use, adapt and improve on the above for your purposes – I'll happily take criticism of and improvements to this hack.

Vladimir Sedach: Templates and code generation

Wed, 18 Nov 2009 14:12:00 -0800

Earlier this month Google released Closure Templates, a new templating library intended for generating HTML. Who cares? I personally dislike HTML templating, and avoid it whenever possible in lieu of s-expression based generation tools like CL-WHO. At first look, Closure Templates didn't seem to be anything new or useful.

The one thing that makes Closure Templates somewhat interesting is that the library works in both Java and JavaScript, so you get client and server-side templates in one place. I did a similar thing with uri-template by having the URI template expand into code that executed in both Common Lisp and JavaScript via Parenscript (here I have to state that despite being an author of a templating library, I still dislike templating libraries and even find my own creation annoying at times).

About a week after Closure Templates was released, Andrey Moskvitin (archimag) wrote an implementation in Common Lisp (interesting note: it took him only five days and 1/15 the number of lines of code as the original). The resulting system, cl-closure-template, similarly generates JavaScript via Parenscript.

I still didn't understand the motivation. Yesterday, Andrey was kind enough to explain it. Those pampered by web development in Common Lisp using s-expression HTML generation tools simply don't encounter the problem of trying to fit HTML templating onto the paradigm of incremental page updating via AJAX. So if you want to build an AJAX web application and use HTML templating, give cl-closure-template a try.

[Blog metanote: if you're reading this blog through its feed, you will shortly see this post show up in Russian. a CONS is an object which cares is now syndicated on Russian Lisp Planet, and I'm going to be writing Lisp-related posts in Russian as well as English. All such posts will be tagged 'lisp-ru'. Filter out that tag if you don't want the Russian version of the posts to show up in your feed reader.]

Christophe Rhodes: 18 Nov 2009

Wed, 18 Nov 2009 04:02:50 -0800

As mentioned earlier: the 2010 European Lisp Symposium invites your contributions. Unfortunately, the website for the 2010 event is not set up yet; you can get an impression of what the event is like by looking at last year's website, which in the fullness of time (soon, I hope) will be updated with ELS2010 information. In the meantime, here's the Call for Contributions: we would welcome both papers describing original work, not published elsewhere, and submissions for tutorial sessions. Submission will be through EasyChair's conference management system.

3rd European Lisp Symposium

May 6-7, 2010, Fundação Calouste Gulbenkian, Lisbon, Portugal

Important Dates

Submission Deadline: January 29, 2010
Author Notification: March 1, 2010
Final Paper Due: March 26, 2010
Symposium: May 6-7, 2010

Authors of accepted research contributions will be invited to submit an extended version of their papers to a special issue of the Journal of Universal Computer Science (J.UCS).

Scope

The purpose of the European Lisp Symposium is to provide a forum for the discussion and dissemination of all aspects of design, implementation and application of any of the Lisp dialects. We encourage everyone interested in Lisp to participate.

The European Lisp Symposium 2010 invites high quality papers about novel research results, insights and lessons learned from practical applications, and educational perspectives, all involving Lisp dialects, including Common Lisp, Scheme, Emacs Lisp, AutoLisp, ISLISP, Dylan, Clojure, and so on.

Topics include, but are not limited to:

Language design and implementation
Language integration, interoperation and deployment
Development methodologies, support and environments
Reflection, protocols and meta-level architectures
Lisp in Education
Parallel, distributed and scientific computing
Large and ultra-large-scale systems
Hardware, virtual machine and embedded applications
Domain-oriented programming
Lisp pearls
Experience reports and case studies

We invite submissions in two categories: original contributions and tutorials.

Original contributions should neither have been published previously nor be under review in any other refereed events or publication. Research papers should describe work that advances the current state of the art, or presents old results from a new perspective. Experience papers should be of broad interest and should describe insights gained from substantive practical applications. The programme committee will evaluate each contributed paper based on its relevance, significance, clarity, and originality.
Tutorial submissions should be extended abstracts of up to four pages for in-depth presentations about topics of special interest for at least 90 minutes and up to 180 minutes. The programme committee will evaluate tutorial proposals based on the likely interest in the topic matter, the clarity of the presentation in the extended abstract, and the scope for interactive participation.

The tutorials will run during the symposium on May 6, 2010.

Programme Chair

Christophe Rhodes, Goldsmiths, University of London, UK

Local Chair

António Leitão, Technical University of Lisbon, Portugal

Programme Committee

Marco Antoniotti, Università Milano Bicocca, Italy
Giuseppe Attardi, Università di Pisa, Italy
Pascal Costanza, Vrije Universiteit Brussel, Belgium
Irène Anne Durand, Université Bordeaux I, France
Marc Feeley, Université de Montréal, Canada
Ron Garret, Amalgamated Widgets Unlimited, USA
Gregor Kiczales, University of British Columbia, Canada
Nick Levine, Ravenbrook Ltd, UK
Scott McKay, ITA Software, Inc., USA
Peter Norvig, Google Inc., USA
Kent Pitman, PTC, USA
Christian Queinnec, Université Pierre et Marie Curie, France
Robert Strandh, Université Bordeaux I, France
Didier Verna, EPITA Research and Development Laboratory, France
Barry Wilkes, Citi, UK
Taiichi Yuasa, Kyoto University, Japan

Andreas Fuchs: Hunchentoot gets a debugging-acceptor

Sun, 15 Nov 2009 13:11:36 -0800

Today, I submitted a patch (the first free software lisp one in months for me!) to the Hunchentoot project, and it got accepted. Yay!

Some backstory: Hunchentoot’s 1.0.0 release dropped a lot of implementation-dependent features, among them functionality to invoke the debugger if an error happens while handling a request. While workarounds exist, none of them were obvious to new users or users who recently upgraded.

The patch I sent should fix this, hopefully. It adds a rudimentary error handling protocol to Hunchentoot, and provides two generic functions whose behavior can be adapted to your error handling needs. You can see for yourself in Hunchentoot’s svn repository.

If you’re a Hunchentoot user, I urge you to test this (in both development mode using debuggable-acceptor and running with the default settings). The sooner you find bugs, the sooner they can be fixed, the sooner a release can be pushed out. And if you don’t find bugs at all, that’s cool, too (-:

Back from vacation

Sun, 27 Sep 2009 22:28:02 -0700

I just got back from a 2-week vacation, so I've been busy catching up on things.

Xcode Requirement for iPhone OS 3.0.1

Fri, 31 Jul 2009 14:20:15 -0700

I've just updated my iPhone OS to 3.0.1 (it's a security upgrade to fix the iPhone SMS vulnerability that was recently announced) and found that I could no longer build/install development apps on my iPhone. A bit of searching uncovered this Apple advisory:
http://adcdownload.apple.com/iphone/iphone_sdk_3.0__final/iphone_os_3.0.1_advisory.pdf

So, if you plan to install iPhone OS 3.0.1 on an iPhone that you use for iPhone app development, you'll need to follow the instructions in the advisory. Note that the terminal command that is described in the advisory is one long line, not 2 lines.

HebrewBible App Store Rankings

Tue, 28 Jul 2009 12:39:03 -0700

I use a variety of different tools to measure how my HebrewBible iPhone App is doing. With the latest 2.0 version of the app, it has now moved into the top 100 of the "Reference" app category in both the USA and France (the top markets for the app). The following MajicRank graph illustrates the current rankings:

Woohoo!

Update-2009-07-28: After 1 week, the app's performance in both the USA and France has improved even more and I've broken into the top 100 for another "Big Eight" country - Canada!:

Woohoo, Woohoo!

New Version of Hebrew Bible iPhone App Available

Sat, 18 Jul 2009 18:47:07 -0700

Today, Apple approved Version 2.0 of my Hebrew Bible iPhone application. In addition to providing 8 different versions of the Hebrew Bible (which can either be read online with no content stored on the iPhone or cached locally for off-network reading) and Hebrew word lookup/lexicon, this version includes links to over 200 Wikipedia articles and provides Google Maps of over 1,000 locations.

Apple made me change the rating of the app to "17+" to indicate that there are "Frequent/Intense" types of "Mature/Suggestive Themes". Their reasoning for this was:

"Our review indicates that the application content is not consistent with the current rating. HebrewBible allows unfiltered access to wikipedia.org, where content with mature or suggestive themes can be accessed."

Come on guys, you've got to be kidding - give me a break! Hmm, a rating of "17+" seems to boost sales of certain movies - maybe I can expect a sudden spike in downloads now! ;-)

Good thing I got my iPhone 3GS last week

Mon, 29 Jun 2009 16:00:25 -0700

It looks like Rogers is all sold out of all models of the iPhone 3GS throughout Canada. Good thing I got mine last week - I've been really pleased by how much better the user experience is with the 3GS over my old iPhone 3G. The features I find most compelling are:

Speed: The increase in processor speed (600MHz CPU as opposed to the 412MHz iPhone 3G) and RAM (256 MB vs 128MB on the iPhone 3G) make a HUGE difference.
Oleophobic Screen: The yucky fingerprint-covered screen of the iPhone 3G is now a thing of the past. The new iPhone's screen coating is the secret and it makes a big difference in the visual appeal of the display.
Video and Camera: The video camera was a nice additon; however, the camera has improved significantly as well. The camera is now 3 megapixels (vs 2 megapixels in the 3G) and both video and camera have geotagging, autofocus, and tap-to-focus functionality. I rarely used the camera on the 3G because of the poor picture quality but I can see myself using the 3GS camera a lot.
Magnetometer: This is most visible in the new Compass app that comes with the 3GS. However, the more useful application of the direction-awareness provided by the magnetometer is in the Maps app. If you press the "location" icon in the bottom-left of the Maps app, it displays your current location (as it did with the iPhone 3G). However, if you press it a second time, the map reorients itself to the direction you're facing and the blue location dot displays a "flashlight" to illustrate the direction you're heading. Very useful when you're in an unfamiliar neighborhood!

New iPhone + New Apple Developer Provisioning Profile

Sun, 21 Jun 2009 21:54:27 -0700

Yesterday, I took some time off from the nice weather and gardening tasks to go out and get a new iPhone 3GS. First off, let me say that the speed difference is really great! I've only played around with a few of the new features (such as the video camera and compass), but the speed increase is a huge plus. Today, I got around to creating a new developer profile for my new iPhone 3GS. My old iPhone was having some problems a few months ago and Apple replaced it, so I remembered the hassles I had then setting up a new provisioning profile for the replacement device (this seems to be a common iPhone developer complaint). I had similar problems this time with the 3GS, so I've decided to note down all the things that I did to get it setup properly. Hopefully, this will help someone else (or, at least, it might remind me of the necessary steps the next time I have to do it!). Not all these steps may be necessary (and it's probably a lot easier if you're just adding a device to an existing profile rather than replacing a provisioning profile); however, I wanted to make sure I knew all the steps this time and it's what worked for me!

When you upgrade to a new device, you need to do the following:

In Apple's iPhone Developer Program Program Portal:

Create a new provisioning profile for the device
Set up a new device profile
Download the new provisioning profile to the Desktop

On the Mac:

Delete the old provisioning profile from ~/Library/MobileDevice/Provisioning Profiles/
Drag the new provisioning profile from the Desktop into ~/Library/MobileDevice/Provisioning Profiles/

In the Organizer window in Xcode:

Click on the device (in the left-hand pane)
Drag the new provisioning profile into the "Provisioning" box
Click on the "Provisioning Profiles" (in the left-hand pane)
Double-click on the new profile name (in the top pane) - it should appear in the "Included Devices" bottom pane with an "Installed" status
Close the Organizer window
Press the Xcode/Empty Caches... menu option
Close Xcode

On the Mac and iPhone:

Power off both the Mac and the iPhone
Power on both the Mac and the iPhone
Attach the iPhone to the Mac

For each project you previously built with the old provisioning profile:

Right-click on the [projectname].xcodeproj file and select "Show Package Contents"
Make a backup copy of the project.pbxproj file
Use a text editor (I used Emacs) to edit the project.pbxproj file:
1. Delete any lines that have the key CODE_SIGN_IDENTITY
2. Delete any lines that have the key PROVISIONING_PROFILE
3. Delete any lines that have the key "CODE_SIGN_IDENTITY[sdk=iphoneos*]"
4. Delete any lines that have the key "PROVISIONING_PROFILE[sdk=iphoneos*]"

In Xcode, for each project you previously built with the old provisioning profile:

Open the project
Press the Build/Clean All Targets menu option
Press the Project/Edit Project Settings menu option
On the Build tab under "All Configurations", chage the "Code Signing Identity" value to iPhone Developer
On the Xcode dropdown menu, select to build on the Device
Press the Build/Build and Run menu option (the application should build and load on the device)

That's what worked for me. If anyone has an easier/alternative approach, let me know and I'll publish relevant comments in updates to this post.

Twin Cities Lisp Group Inaugural Meeting

Fri, 08 May 2009 11:53:01 -0700

Two years ago, Robert Goldman gave a presentation to our Vancouver lispvan group. I'm pleased to note that he's decided to start up his own Lisp User Group in Minneapolis. Here are the details of their upcoming inaugural meeting:

TWIN CITIES LISP GROUP INAUGURAL MEETING 9 June 2009, 6:00 PM - 8:00 PM CDT Common Roots Cafe Corner of 26th and Lyndale, Minneapolis, MN http://preview.tinyurl.com/tclisp-crc Temporary web page: http://rpgoldman.real-time.com/tc-lisp.html
There's a lisp renaissance out there, spurred by the availability of several high-quality open source Common Lisp implementations (SBCL, CMUCL, Clozure CL, and CLISP, at least). After attending the 2009 International Lisp Conference in Cambridge ( http://www.international-lisp-conference.org/2009/index) I was fired up to see if we could share in some of this renaissance here in the Twin Cities.

I was also inspired by visiting with the Vancouver Lisp group, Lispvan. They meet roughly monthly at some location offering coffee, beer, and wine, where they have a talk and some mingling.

In the interests of setting up something like this here, I've (well, Josh Hamell did all the real work) set up a mailman mailing list, tc-lispers ( http://sift.info/mailman/listinfo/tc-lispers_sift.info), and I've reserved the meeting room at Common Roots Cafe ( http://www.commonrootscafe.com/ourcommunity.htm), which offers the aforementioned coffee, beer, and wine (and tasty food --- vegetarian is available and there seem to be at least some vegan options).

At the first meeting John Maraist will talk about the NST unit testing framework for Common Lisp, which he has been developing at SIFT (abstract follows). Then we can plan a next meeting, chat, mingle, and swap stories. Share and learn the latest Lisp applications, techniques, packages, and implementations. Show off your lambda tattoos, evil hacks, and wigflip graphics.

Please come if you can and, whether you can or not, please sign up for the tc-lispers mailing list.

Best,

Robert Goldman
NST: A Unit Test Framework for Common Lisp
In this talk we will introduce the Lisp unit test framework NST. SIFT developed NST for internal use on a number of ongoing Lisp projects, and we believe that the system is now mature enough to release more broadly. In this talk we will review the notion of a unit test, and introduce the use of NST in Lisp project development. NST's implementation makes interesting use of a number of Lisp features --- macro expansion, compile-time execution, metaobject protocols --- and we will discuss its current implementation as well as the lessons we learned along the way.

If you will be in the Twin Cities area on June 9, be sure to attend this new user group meeting. Best wishes to Robert and all the other Twin Cities lispers! By the way, if anyone else is inspired to start a new Lisp User Group, you might want to read my "How to start a Lisp User Group" blog post. I've tried to summarize my experiences in that post.