• Due to popular demand, the Deflate system is now called "deflate" instead of "Deflate", thus allowing

  (require :deflate)
  

  or

  (asdf:oos 'asdf:load-op :deflate)
  

  to do the right thing. Note that this is an incompatible change from version 1.0.0, thus requiring changes to system definition or init files referencing "Deflate" to reference "deflate" or :deflate or #:deflate instead. Sorry for the inconvenience.

• A minor bug workaround for ECL, which also improves performance on ECL by a factor of 2 (although performance on ECL is still very much non-optimized, patches are always welcome). Note that you will need to use ECL from the current git repository, since only this version currently contains other fixes needed to let Deflate work correctly (thanks go to Juan Jose Garcia-Ripoll for the quick fixes)!

Links

• PMSF Resources Page for Deflate
• GitHub Project Page for Deflate

Please expect minor re-edits of old posts in the following days to manage some of the fallout from these design tweaks.

(defun frob (x) (format t 'Frob: ~a~%' x))
(frob (defun frob (x) (format t 'New frob: ~a~%' x))

This provides an example where I think the ANSI Common Lisp standard is actually very helpful, since it often tries to go out of its way to point out things that are explicitly left undefined, instead of simply leaving them left undefined by not defining them, as many other standards (out of fear of being ambiguous) do. Quoting from the HyperSpec, Section 3.1.2.1.2.3 Function Forms:

Although the order of evaluation of the argument subforms themselves is strictly left-to-right, it is not specified whether the definition of the operator in a function form is looked up before the evaluation of the argument subforms, after the evaluation of the argument subforms, or between the evaluation of any two argument subforms if there is more than one such argument subform. For example, the following might return 23 or 24.

(defun foo (x) (+ x 3))
(defun bar () (setf (symbol-function 'foo) #'(lambda (x) (+ x 4))))
(foo (progn (bar) 20))

Thus we can see that the effect of evaluating the orginal two forms is indeed undefined (as already suspected by Ingvar Mattsson) as to which function definition is called in the second form, without going to the trouble of trying to take into account possible differences between evaluation and compilation, compile-time effects of defun, etc.

Which is my long-winded way of saying a big thank you to the people involved in creating the ANSI Common Lisp standards document (with special thanks to all involved in creating, releasing and maintaining the HyperSpec online text equivalent thereof, especially of course Kent Pitman), which is one of the nicest language standards I have had the pleasure of working with and against.

1. iPhone 3GS

   I agree with John Gruber’s prediction that a faster iPhone “3GS” will be announced, and of course it will have at least 16GB and 32GB models, though I sincerely hope, but do not expect, a 64GB model that would aid in replacing my 160GB iPod Classic. Well, maybe next year.

   I also think that we are going to see something for the lower end of the market, and I suspect it is not going to be the current iPhone 3G.

2. Snow Leopard

   Of course WWDC on the Mac side will be all about Snow Leopard, and I fully expect an announced ship date, as well as one or two currently unknown features for Snow Leopard, though probably nothing earth shattering, technically speaking.

   I doubt a new UI will be announced for Snow Leopard, with such a short lead time for developers, and announcing a new UI that is going to ship with 10.7 before 10.6 ships is out of the question.

   I fully expect Snow Leopard to be a full price paid update, i.e. $129.

3. No Tablet

   I’d love to be proven wrong, but I don’t think an “iTablet” is ready for release. If it should be released, it would be a high-end iPhone.

   The reason I’d love to be proven wrong is not that I’d personally want a tablet (I’d rather have either an iPhone or MacBook Air, thanks very much), but it would finally put to rest all the euphoric Apple tablet-excitement. I’ve been around since before (probably) the first time in the late 80s when tablets were all the rage (remember the GRiDPad?), and with each new tablet mania each 5-8 years, (IMHO unrealistic and unclear) expectations were never ever met by the products, and they subsequently vanished in small niche markets, never to be heard of again. An Apple tablet is either going to meet the same fate, not unlikely, or it is going to revolutionize the tablet form factor into something which people can really use in practice, not merely crave in the abstract. In either case we’ll know something more about tablets and their place in the world.

4. Cinema Displays

   I continue to expect that they’ll update the Cinema Display range sometime this year, and it is getting kind of urgent with all current products going to DisplayPort connectors, and only one matching display. However Apple has continually failed to update them, so why now? We’ll see…

Since I can’t let any benchmarking opportunity go to waste, here’s an overview of performance when decompressing a 18.6MB gzip-compressed file into 81.9 MB uncompressed form with Deflate 1.0.0, Chipz 0.7.3 and inflate.cl from Franz, version 2.6, on various CL implementations, and gzip 1.3.10:

Since CRC-32 calculations can overshadow deflate performance itself on some implementations, and since inflate.cl does not perform CRC-32 checksum calculations at all, the columns showing Deflate and Chipz without CRC-32 calculations might be more indicative of actual deflate performance.

Note that this was all done on a MacBook Air 1.8GHz Core2 Duo under Mac OS X 10.5.7, timing was done as an average of 3 runs each.

What can be learned from the results is that 64bit implementations with their bigger fixnum range help quite a bit in performing 32bit algorithms (like CRC-32) well even without extensive/effective declaration fine-tuning or special 32bit arithmetics operators.

The library supports decompression of pure deflate streams, zlib-style (RFC 1950) and gzip-style (RFC 1952) streams, including optional checksum checking. The code should be fully portable across all conforming ANSI Common Lisp implementations, and has been performance tuned for SBCL and CMU CL, and somewhat for Lispworks (CRC-32 checksum code). While the performance does not reach the level of zlib/gzip (by a factor of around 3 to 3.5² on my most recent tests with SBCL), mostly due to stream I/O overhead and a not very sophisticated huffman decoder, it is eminently usable.

Support for compression and ZIP-file handling are currently not included.

Enjoy.

Links

• PMSF Resources Page
• GitHub Project Page

1. Since publishing this entry, I’ve been made aware of Chipz from Nathan Froyd, which achieves comparable levels of performance and is as free as Deflate; see my newer blog entry for more information.

2. It seems that on larger files the factor is actually nearer to 1.25-1.5, see this entry for details.

More importantly its exposition of American civic culture and political philosophy against the backdrop of Casablanca can also be a refreshing reminder of certain civic values which though constantly under attack are sorely needed in any age, especially ours.

One of those is the LG GSA-E50L, which is only slightly larger (156 x 165 x 21 vs. 139 x 139 x 17 mm) and heavier (380g vs. 320g) than the MBA Superdrive, is a bit faster and cheaper, and offers Lightscribe and DVD-RAM support, for those that care. I’ve purchased one of those, and it works very well with the MBA from its beefed up USB port, and through its Lightscribe support I can label discs on the road without all of the pain of printed labels. Recommended.

I just hope that support for more than 4GB of RAM will move into the mainstream sometime later this year, maybe when Intel releases their new mobile chipsets in the second half of 2008. I find it kind of strange having all 64bit Mobile Processor line-ups (Core 2 Duo and friends), yet still next to no support for actually employing that addressing power with physical memory, given the resource hoggishness of current operating systems and applications and their non-trivial working sets.

(Via Heise Newsticker.)

On the topic of airport security, as e.g. Michael Nygard has already noted, the X-ray signature of the MBA is indeed different enough from the ordinary for screeners to notice (though at least the European screeners I met handled this with much less fuss than the TSA screeners encountered by Michael Nygard). Which BTW seems not so surprising to me, given the design goals of the MBA, which leads to a laptop with very little electronics inside, and the rest of the enclosure containing the spread out battery. If one were to design a device that contained as much plastic explosives as possible, while still being able to function as enough of a laptop so as to fool casual tests, the design might end up looking similar, though one would probably create something with a little more volume.

Anyway, the road so far with the MBA as a main machine has been very successful, though I still sometimes long for my large 17” PowerBook display. A related nuisance I have noticed with the MBA is that connecting an external display leads to very frequent fan noise, apparently caused by the GPU circuitry working overtime (at least with my Cinema HD 23” display).

Aside from this nuisance and either a second powered USB port or a FireWire port (or a much bigger internal HD), I still have to find something about the MBA not to like. Definitely recommened for people not doing heavily media-centric stuff. Even as a developer main machine, this can pass muster, if carefully used. And as a second machine besides a Mac Pro, the MBA is likely to be enough for many more.

On a Lisp-related note: The MBA is, like all Intel-based Macs, one of the nicest modern Lisp machines, able to run all currently maintained Common Lisp implementations (even Windows-only ones ;).

Sticking out for Mac users are the following improvements:

• 64bit Version with full Cocoa support on Leopard
• Services and Dock menu support in CAPI
• LispWorks as a dynamic library (on Linux as well, Windows already had this support in 5.0)
• Support for drag and drop of text and files

Windows users get:

• OLE embedding i.e. LispWorks as ActiveX control
• Documented windows registry access API
• Support for drag and drop of text and files

General improvements:

• Compiler optimization hints
• Various IDE and CAPI improvements

• Bit-accurate Reference Interpreter for Simulink/TargetLink discrete-time models, used to validate full code-generation tool-chains, comprising code-generator, compiler, linker and target hardware.

  Implementations used are both SBCL and LispWorks on Windows and Mac OS X for Intel and Power PC, to ensure diversity of implementation and prevent common-cause errors.

  Most of the code is self-written including some internal support libraries, but the code base uses ASDF, CL-PPCRE, CL-YACC, CXML, Puri, SLIME, and trivial-gray-streams. Thanks to everyone who put so much work into those.

• Framework for target-based testing of generated code, including test-harness generation, stimulus/result management and differencing. This is also used in the validation of code-generators, same as the Reference Interpreter above.

  Also uses both SBCL and LispWorks as implementations, and makes use of many of the same libraries.

• Model-differencing and translation toolbox, with support for FIBEX, ASCET and UML-RT. Used in the maintenance and integration of inter-ECU models in automotive development.

  This tool is implemented using LispWorks on Windows, and employs CL-PPCRE and a modified early version of xmls. Note that the tool has been used in production usage for a couple of years, and is mostly in maintenance mode.

Well, there you have it, looking forward to hearing about other users/uses!

Having ranted about even MacBook Pros being RAM starved for my uses, and barely living within the constraints of my self-upgraded 160GB HD, why-oh-why would I want a MacBook Air? Well, for one because it’s sexy and like any self-respecting tech junkie, why wouldn’t I want one?

The main other reason is that my work-pattern has changed for the better in recent years, with less time spent at customer premises, and more time spent in-office, with a certain amount of traveling all over the country/continent/world for shortish durations thrown in. So the idea of having a heavy-duty laptop as main machine for ease of permanent relocation is getting somewhat less important to me, and the idea of going back to a non-portable main machine with a travel-friendly laptop is actually something that might become palatable.

Of course, there are still a number of open questions, especially when it comes to keeping stuff in-sync, especially to the point of being able to leave at fairly short notice without missing stuff on the road. A lot of stuff, like e-mail, address books, base-line source code, etc., is already stored and synced through centralized servers, but there is still lots of things that are not so synced, so I will have to see about that.

The next couple of weeks I’m going to try to live within the confines of the MacBook Air as a sort-of main machine, with only non-essential stuff living somewhere else.

The first impressions of the MBA to me are quite favorable: It is indeed very thin and stylish, very well made, and reasonably light, while remaining stiff and somewhat robust.

The new touch-pad gestures are very, very likable, making me miss a mouse much less than normally. The optical-drive borrowing works reliably (though a directly connected drive is really preferable for largish installations, especially over 802.11g and lower networks).

Performance is nothing to be ashamed of, though of course once you enter swapping-territory, having a 1.8” HD does not really help (D’oh)!

All in all, living within the MBA in the last couple of days proved surprisingly unrestrictive, and I can really see this being the one and only computer for quite a lot of folks. The only thing that I’m really missing is a Firewire 400/800 connector, since I really dislike USB 2.0 for mass-storage (especially on Apple platforms), and have standardized on firewire for all external storage. That said, most people will likely be just as happy with the USB 2.0 port.

We will see how things progress from here, once the mundane cruft accrues on the HD and sychronization issues crop up…