Mulling Things Over

Here are some notes from my initial experiences with a Verizon Motorola Droid phone that I just recently started using.

This is my first “smartphone”, and I’m pretty impressed. (Those closer to the tech edge will find little of interest in this article.)  My old phone was an LG VX3850 (not quite smart, perhaps a cleverphone?). The hinge on the VX3850 broke a few weeks ago, which  is what prompted this new purchase. The Droid is definitely a palm-sized computer, and not just a mobile phone. The versatility will be welcome; although I use a cell phone every day, I’m not one to spend much time on the phone, and my calls are invariably brief. The other things I can do with this device will very much justify the effort required to tote it around and keep its battery fed.

Some useful roles I’ve found for it so far, each of which I’ll talk about briefly, below:

• eBook reader
• guitar tuner
• Music player
• Web browser
• alarm clock
• GPS navigator
• text messaging tool

It’s fairly easy to use the Market application to search for and download applications from the Android Market. There are lots of free ones, and many that you have to pay for. The prices are very modest, not at all like the very few applications that were available from Verizon for my old phone.

One note about purchasing applications:  Save yourself having to enter credit card info on the phone by setting up a credit card in Google Checkout from a real computer before trying to buy applications from the Market. Note that Discover cards can’t be used to buy applications that are priced in non-U.S. currencies. In fact, from what I’ve read, you might need to have a VISA card set up for this.

I bought an eBook reader with an electronic ink display two years ago, and got quite hooked on the convenience and the reduction in the rate of accumulation of book mass in our house. However, the device died after an unfortunate fall after only a year and a half, and I’ve been postponing the purchase of a replacement while watching the explosion of new eBook readers coming out. I pooh-poohed the idea of using something like a cell phone as a reader because of the small display, but of course I had to try this out anyway on the new toy. To my surprise, it works quite well — you just ending up flipping “pages” very frequently, which is not a problem for very linear reading of fiction. I read about and tried and  several different applications. The one I settled on for now is called WordPlay. It’s free, although I plan on making a donation soon. The only downside I’ve encountered, and it is significant, is that the battery life is very much shorter than that of a dedicated device with an electronic ink display – on the order of six hours continuous reading instead of eighteen or more. The screen on this phone is gorgeous, but it’s also very power-hungry.

(Note that choosing a device and software for eBooks can be complex, because there are a variety of formats and encryption schemes in common use by different vendors. It’s too large a topic to go into here.)

The guitar tuner thing — well, it’s cute. The guys I play guitar with have an iPod and an iPhone, and they both had an inexpensive guitar tuner application on their devices. There was an application like this available for my old VX3850 through Verizon, but it was way overpriced. So of course I had to look for one for the Droid right away. There are numerous free tuner programs available for this phone;  at the moment I’m using gStrings. I already have a very nice dedicated electronic tuner, and I’ll probably keep using that because I can plug an electric guitar into it directly for “silent” tuning, but it’s nice to have options.

I also installed “Robotic Guitarist”, which includes a tuner, but mainly it lets you use your phone as a virtual, strummable guitar. This is amusing, and I’m sure it would be big hit with kids.

The built-in music player application is reasonably easy to use, so I haven’t looked to see if there are others. The phone can take a micro SD card, which installs behind the battery. (You won’t be popping these in and out frequently.) Mine came with a 16 GB card, which is just big enough to hold my entire music collection with a bit of space left over for pictures. This, together with the guitar tuner, quenches my incipient iPhone-envy.

Being able to browse the Web from anywhere is going to be great. On the VX3850, you could sort of do this, but were trapped in the restrictive Verizon  gateway and lousy browser software. General Web browsing really wasn’t at all practical. Now, I’ll be able to Google anything at any time, which always makes me feel smarter. It’s the next-best thing to the neural interface to the global data cloud that I expect will be available in a decade or so. The browser is quite usable, but of course it’s a tiny screen. You often have to zoom in and pan around to be able to navigate links on a page.

One non-telephony role that my cleverphone did serve was that of alarm clock. (And wristwatch, for that matter, since I hate wearing wristwatches.) The new phone can of course perform this function, using pre-installed software. But there’s a whole bunch of choices available for download that will turn it into the Ferrari of nightstand alarm clocks. The one I’m going to try out when my vacation ends next Monday morning is Gentle Alarm, my first paid-for application. It sounds promising. It has a nice discreet low-light time display, programmable alarm “profiles” that allow your chosen alarm — vibration, ringtone, music, or even a random selection from a playlist — to start out gently and get gradually louder. It has, of course, snooze functionality. And optional ways to make sure that you don’t turn the alarm off to easily. And even an optional method of attempting to avoid waking you up during a “deep sleep” cycle. Very promising. This application, by the way, is priced in British pounds, hence the earlier note about credit cards.

I don’t do a lot of text messaging, but I imagine that I will be doing a little more soon. The slide-out keyboard on the Droid doesn’t make me want to type a long letter on it, but it’s a hell of a lot better than cycling  through letters on a numeric keypad. And the text messaging interface is pretty nice when you get used to it. It’s a lot like a chat application on a computer, encouraging you to think of text messaging as an ongoing back-and-forth exchange instead of a one-shot transmission.

One feature that I really like is the auto-synchronization feature of contacts. When you first set up the phone, you have to connect it to a Google account. If you have a Google Mail account, the contacts can be kept automatically synchronized in both directions. To initially populate contacts on the new phone, I downloaded a CSV file from Verizon’s backup of my old phone’s contact list. (This existed because I had installed a free auto-backup utility from Verizon on that phone quite a while ago.) I then imported this into my Google Mail account. Soon afterwards, the list showed up on the new phone. This activity also prompted me to do some much-needed maintenance on the list, which I did from my home computer. All the changes appeared seamlessly on the phone.

Your contact list can also show all of your Facebook contacts, merged with your Google Mail contact list, if you set up the pre-installed Facebook application on the phone. Very nice! The Facebook app also makes it dead easy to upload photographs that you take with the phone.

The phone has a built-in GPS receiver, and various applications can take advantage of this. Google’s Maps application, which is still in beta (you’ve been warned), includes a full-blown talking navigation application. This makes it rather tempting to buy Motorola’s car mount for the phone. I haven’t tried navigating with it yet, so I can’t say how well the GPS locator works compared to, e.g., the GPS dongle that we have for our netbook computer.

Here are all the applications that I’ve installed so far, only some of which were mentioned above:

• Gentle Alarm
• Google Sky Map (for outdoor astronomy)
• gStrings
• Maps
• MotoTorch LED (lets you use the camera flash as a flashlight)
• Robotic Guitarist Free
• WordPlayer v3

There are also a lot of pre-installed things, some of which have been mentioned, but also including basics like a calculator,  the browser, calendar, music player … oh, and an application that lets you make phone calls, believe it or not!

All in all, I think this is going to be a fun daily companion. I hope this more or less random walk through my first experiences is useful to you.

[Typos fixed 2010-01-03]

Lately, I have been contributing work to ASDF-INSTALL in an attempt to make it more configurable (especially on Windows), and to make it handle multiple defsystems correctly. This was motivated in part by dissatisfaction with the recommended techniques for dealing with Windows’ lack of symbolic links in ASDF and ASDF-INSTALL. It should, and can, be simpler: As simple as using a regular file containing a pathname to the target in lieu of a bona fide symbolic link file. Teaching ASDF to do this easy; teaching ASDF-INSTALL is not really possible right now (except in the unstable version, sort of).

Another motivation was seeing people often recommend ASDF-INSTALL to Lisp newcomers on comp.lang.lisp, only to have the new visitor return shortly thereafter with problems (usually but not always on Windows), and then have people disrecommend ASDF-INSTALL and describe alternate approaches. Which is a pity because of the wasted time, and because ASDF-INSTALL is really convenient when it does work. So it should, well, just work!

I was pleased to note the presence of a unit test suite in ASDF-INSTALL. As I started making more complex changes, I really wanted to leverage that, but I found it unreliable. The main problem is setup of scratch directory trees for the unit tests to operate on. Or more specifically, the removal of such trees. As per the usual recommendations for using ASDF, these trees often contain symbolic links to system files. Do you know how hard it is for a Common Lisp program to portably delete a directory tree that contains symbolic links with targets internal to the tree? Infernally hard! I turned to CL-FAD‘s DELETE-DIRECTORY-AND-FILES, apparently modeled on Allegro‘s function of the same name, but it can be easily confounded by symbolic links. The difficulties are legion…

There’s no portable way to delete a directory. Some Lisps allow DELETE-FILE to delete a directory; others (e.g. CLISP) take a stricter interpretation and disallow this. So immediately you need a non-standard function, typically DELETE-DIRECTORY in some implementation-specific package. (CL-FAD handles this issue internally.)

Next, whatever the means of deleting a directory, it often can’t delete a non-empty directory. When it can’t, the fun really begins. In order to make a directory empty, you have to be able to find everything in it, and delete it. This is what CL-FAD:DELETE-DIRECTORY-AND-FILES usually tries to do. But in the presence of symlinks, this gets ugly.

Finding everything in a directory can be surprisingly hard. DIRECTORY is specified to return truenames. Most Lisps interpret the truename of a symbolic link to be the ultimate target of the link. This is quite reasonable, but it immediately leaves you with no standard way to find the actual contents of a directory. From the point of view of a conforming Common Lisp program, the link files disappear, replaced by their targets. Standard programs are unable to discover link files, period. Most implementations provide some non-standard means of seeing the link files; I’m working on discovering these techniques. CL-FAD does not deal with this issue, which makes DELETE-DIRECTORY-AND-FILES fail sometimes, and makes it a pretty scary function in the general case, since it may follow symbolic links outside the tree that you’re trying to delete.

Links within the tree are interesting, too. You may encounter a link or its target in either order, with different consequences. If you delete the target first, the link becomes a broken link. If you encounter the link first, you better be sure that the program sees the link file itself and deletes it, rather than what deleting what it points to and leaving the link file behind.

In CLISP, there are two additional wrinkles to this problem. By default, DIRECTORY completely ignores broken symlinks. This behavior can be overridden with an implementation-specific keyword argument, and I sent Edi Weitz a change that adds this to CL-FAD’s LIST-DIRECTORY. (He immediately rolled this out in 0.6.1. Thanks, Edi.)

Worse, although CLISP offers a way to list symbolic links (the non-standard :FULL keyword of DIRECTORY), it only works with links to files and broken links, and not with links to directories. I may submit a bug report for this, because I haven’t found a way around it. Symbolic link files that reference existing directories appear to be invisible to a CLISP program.

The next (and perhaps last) problem, if you can solve the preceding ones, is deleting what you find in a directory. Again we have the (solvable) problem of variations in DELETE-FILE’s ability to delete directories. But there’s also a potential issue with deleting a symbolic link file. I think most Lisps will allow you to delete a symbolic link using DELETE-FILE. However, I have found that under certain circumstances, CLISP cannot. (And for this I did submit a bug report.)

I picked on CLISP a lot above, but it happens to be my first target for getting the unit tests running. I don’t yet know how I’ll fare with other Lisps — or how many of them I’ll have the patience to test.

I’ve been staring at a lot of Microsoft documentation lately, trying to architect a database access layer that leverages the rather nice design tools in Visual Studio 2005 , while still giving us some hooks into a data constraint mechanism. I’m trying to stay away from the currently popular business-object-to-table-hierarchy design, since I think this is badly flawed for complex applications.

What had me baffled lately is how to wire up what I want into the ADO.NET 2.0 framework. I’ve been thinking that implementing a DataAdapter was the way to go, since this seems to be the main conduit between the disconnected world of DataSet objects and the DBMS-specific connected layer. I know I could use an ad hoc class of my own making for this, but would like to try integrating into the framework to see what that gets me.

A little while ago I realized one reason that I’ve been spinning my wheels. It’s Microsoft’s documentation. It’s terribly confusing in this area. Usually, I find Microsoft’s API documentation to be OK but incomplete, but the documentation for these adapter classes and interfaces seems almost deliberately obfuscatory.

There are two key interfaces here: IDataAdapter and IDbDataAdapter. The first is designed to work with DataSet objects containing multiple DataTable objects. The latter is designed to handle a single DataTable — yet it derives from the first. There are two related classes, DataAdapter and DbDataAdapter, which implement the respective interfaces. The classes deal with multiple and single DataTables, respectively, just like the interfaces. And again we have the odd inheritance relationship. What’s worse — much worse — is that the documentation for upper layer (IDataAdapter and DataAdapter) constantly refers to features of the lower layer (IDbDataAdapter and IDbDataAdapter), giving the impression that the upper layer also can only deal with one DataTable per adapter instance. Supplemental MSDN articles suffer from similar confusion. Almost all of these articles talk about single-table data adapters, sometimes referred to as table data adapters or table adapters. Only passing mention is made of multiple-table adapters.

(BTW, these interfaces and adapters are in the System.Data.Common namespace, implemented in the System.Data assembly.)

So if you’re in the business of writing code related to ADO.NET 2.0 framework classes, be aware of the confusion in the documentation, and don’t let it become your own confusion.

Oh, and here’s another fun detail that I just discovered, using Lutz Roeder’s Reflector. If you disassemble the key public methods of DataAdapter, you find that all of the following have non-implementations that merely throw a “not supported” exception:

* Fill (DataSet) :Int32
* Fill(DataTable[], IDataReader, Int32, Int32) : Int32 (but only if given more than one DataTable)
* FillSchema(DataSet, SchemaType) : DataTable[]
* Update(DataSet) : Int32

There is no hint of this in the API documentation. In fact, the documentation for Update() is one of the first offenders I’ve seen yet, with a bunch of verbiage that is almost entirely related to a single-table update. Example: “If INSERT, UPDATE, or DELETE statements have not been specified, the Update method generates an exception.” There is no way to specify such statements in a DataAdapter!

I haven’t worked on CLinNet in quite a while, but a few months ago I started playing with RDNZL, a .NET/Common Lisp interface written by Edi Weitz. Very nice! But I found the need to use assembly-qualified type names, or to import types or assembly contents, to be fairly cumbersome when I worked with Direct3D. I discussed some of these things with Edi on the RDNZL developer’s mailing list and in private email exchanges, and figured out some improvements. But then I got interested in trying out some alternative reader syntaxes, different from RDNZL’s reader, so I ended up writing a layer on top of RDNZL to experiment with. I call it CL-CLR.

Ideally, I’d like the ideas from CL-CLR to be incorporated into RDNZL, at which point CL-CLR could go away. But some of them are significantly different from the way RDNZL works now, so I don’t know if that will happen. Edi’s too busy right now to give this much attention, although he’s interested. At his suggestion, I made the CL-CLR code available today via the mailing list so others could comment on it.

I’ve been using CL-CLR successfully for a few weeks to write the Direct3D rendering code for a simple physics simulator. I’m quite satsified with the way it came out. If Edi decides not to incorporate it in RDNZL, I’ll probably write a new low-level backend to replace RDNZL, because CL-CLR could be considerably faster than it is right now.

You can download the code at http://spookydistance.com/cl-clr.zip. It has a BSD-style license, and includes several of Microsoft’s Direct3D tutorials translated into Lisp. All of my testing has been with the personal edition of LispWorks so far, but CL-CLR should work with any implementation supported by RDNZL.

I’m trying out WordPress as of today. Although I copied over my two existing articles, I haven’t bothered to bring over the two legitimate comments. (Sorry, Alex and Chuck!)

I’m hoping that fighting referrer and comment spam will be easier with WordPress. We’ll see.

Here’s an overdue update to my post about rolling your own smokes.

After about six months of using the Supermatic II cigarette-stuffing machine, it was getting more and more balky. It would jam frequently, and wouldn’t quite stuff the full length of cigarettes, requiring a lot of tapping to pack the tobacco down to the filter. My wife actually gave up on it completely and used one of the under-$10 plastic machines instead. No amount of adjustment seemed to help. None of the parts seemed excessively worn, but I was contemplating ordering replacements to see if it would help.

After reading a fine review of a competitor’s machine at Roll Your Own Magazine, I decided I’d give it a try. The Top-O-Matic by Republic Tobacco is a bit pricy — around $70 locally — but man, is it nice. It uses almost the precisely the same mechanism as the Supermatic II, but the mechanical parts are all superior, made out of better materials and to tighter tolerances. Very smooth and easy to use. I’ve only had one jam myself, when I obviously overfilled it. My wife had one when she used some particularly dry tobacco. Those are the only two I know of after a month’s worth of frequent use.

The action is smoother and requires less force, and the cigarettes are almost always fully stuffed. We’ll see how it’s performing after a few more month’s of daily abuse.

Making your own cigarettes can be done by hand-rolling. If you grew up in the sixties or seventies, you should have at least a passing familiarity with this activity, albeit not with cigarette tobacco. However, most people who make their own cigs nowadays use an injection machine, and the process is one of injecting tobacco into a pre-made paper cylinder, rather than rolling anything. You purchase the cylinders with filters already in them. The result looks very much like a prepackaged cigarette.

There are two reasons to make your own: a considerable cost savings, and they taste better. Leaving aside the cost of the injection machine, you’ll spend something like $13 per carton on your homemade cigarettes.

Inexpensive plastic injection machines cost as little as four or five dollars. You can get starter kits with one of these, but I don’t know what kind of tobacco they come with; if you go this route, be sure to take into account that the tobacco might be substandard when making your initial judgments. Consider buying a small pouch of nicer tobacco to experiment with, too.

Fancier injection machines cost up to about $70; I have a Supermatic II, which costs about $50. The small ones can be held in your hand; the Supermatic is a table-top machine, about the size of a thick spiral-bound notebook, with a large hand-crank on it.

I haven’t used one of the cheap injectors. My brother tells me that they wear out after several months, but at that price, it’s not a big deal. He doesn’t think they’re hard to use, but the table-top units like my Supermatic are reputed to be easier. Injection machines typically make one cigarette at a time, although there are some that make two at a time. The only one I have personal experience with is my Supermatic. The Excel, by the same company, works a bit differently, is more compact, costs less, and is also reputed to be very good.

To make a cigarette, you place a ready-made paper cylinder with filter on a short tube that sticks out of the machine, pack some tobacco in a slot, and then apply some muscle power. On the Supermatic, you turn a crank; on the little injectors, you usually push or slide something. This action packs the tobacco into a cylindrical shape and pushes (injects) it into the paper tube. The only tricky part is learning how much tobacco to pack into the machine, which can vary a bit depending on the type and moistness of the tobacco. It requires a little force, but my wife uses the Supermatic to make her own with little trouble, and she’s certainly not a weight lifter. The only time it’s hard is if you pack too much tobacco in the machine. Be sure to read the instructions that come with your machine and heed them to avoid overstressing and breaking it.

After some practice, it takes me about 10 or 15 minutes to make two packs of cigarettes. My brother reports similar speed with his small injection machine.

The pre-made tubes I have used so far are Zig-Zag brand, and they cost about $2.60 for a box of 200. They’re available as regular or light — the latter having ventilation holes just in front of the filter that mix air with the smoke. (Prepackaged light cigarettes usually use the same scheme.) My wife uses the light tubes, but I prefer the regulars. My brother has settled on a different brand of tube, Premiere, which I’ve also tried. Can’t say as I see much difference.

You can get tobacco in various sizes of pouches and cans. For a carton’s worth of tobacco, prices might be about $7 to $11 (maybe more for finer tobaccos?). Watch out for the really cheap ones, like Top; my memory of these from my hand-rolling days is that they are pretty tasteless.

The tobaccos are usually a shaggier cut and moister than what you get in a prepackaged cigarette. The tobaccos are specifically for cigarettes; I don’t think pipe tobacco would work well for injecting, and a few puffs of that would probably knock you out cold anyway.

There are lots of tobaccos to choose from, and most are much better than the tobacco in prepackaged cigarettes. Trying out different tobaccos is fun, and you can even blend them to get something that’s just right for you.

Here are some tobaccos I’ve tried so far:

Kentucky Smooth ultra-light: A nice, smooth, but unremarkable tobacco. Recommended to me by the tobacconist in Saline when I started a few weeks ago, and it probably is a good starting point.

Drum: This is a European-style “halfzware shag”, i.e. a very shaggy cut. Very strong, with a nice flavor that will seem very unusual to American smokers. This’ll give you a hell of a buzz if you’re used to smoking prepackaged light cigs. In spite of the strength, it has less initial ‘bite’ than tobaccos that you’re probably used to. Get a small pouch to try it, or larger quantities in a can. Although I like it for hand-rolled cigarettes (the shag cut makes it easier to roll), I find it too strong by itself in injected cigarettes, which have a lot more tobacco in them than hand-rolled ones. I generally use a blend of about 40% Drum with 60% McClintock Full Flavor. This was my first experiment with blending, and I was quite happy with the results. A bit more expensive than average.

McClintock Full Flavor (the red can): Very nice by itself, a bit strong with a little bit of a bite, but still smoother than prepackaged butts. Mixing with Drum adds flavor. Reasonable price.

McClintock Virginia (the yellow can): A bit lighter than the Full Flavor, but more of a bite like prepackaged butts. Not my favorite. Reasonable price.

Samson: Another halfzware shag, like Drum. Somewhat less strong. Still very dark and flavorful, perhaps slightly less so than Drum.

Bali: Another halfzware shag, supposedly competes with Drum. I have a pouch of this, but haven’t gotten around to trying it yet.

So far, I’ve purchase all my supplies in person at the Smoker’s Shop in Saline, MI:

521 E Michigan Ave
Saline, MI 48176
Phone: (734) 944-7147

You can also order all this stuff online. Check out this Web site, dedicated to making your own cigarettes, it’s a hoot and very informative: Roll Your Own Magazine.

As an example of pricing, a 6-ounce can of McClintock costs less than $12 at Smoker’s Shop, and claims to make 200 cigs (one carton). This is on the low end of tobacco prices, so the average carton cost is probably a bit more than what I said below. Drum and Samson come in cans with slightly less than 6 ounces, and cost under $14.

For fun and education, I’m currently working on an implementation of Common Lisp on the .NET framework. This meshes with my personal strong interest in Common Lisp, and my new responsibilities at my day job, where I’ve just become a charter member of a group that is working on a new generation of products based on the .NET framework.

Common Lisp is a big language. Even the language core, which I define loosely as the various special operators, the “most primitive” built-in data types, and the most primitive functions associated with these types, is pretty large. I don’t know how far this project will get, but it should be a fun way of learning the excruciating details of Common Lisp, the .NET framework, and C#.

So far, I’ve got a basic implementation of READTABLE and the reader functions (sufficient to read symbols, lists, strings, and fixnums), basic printing functionality (similar coverage), and a bare start on the evaluator. A simple REPL understands how to evaluate whatever can be read, but the only operators supported so far are SETQ, QUOTE, CATCH, and THROW. Everything is written in C# so far, using .NET 2.0 beta 1 but trying to stick to .NET 1.1 features for the most part. (I’ll be picking up beta 2 this week, hopefully.)

The next steps require some interesting decisions. I can stop further development of the evaluator and instead head in the direction of always-compile-to-execute, which is fairly common in modern CL implementations, AFAIK. Since compilation is an important and complex feature, and implementing it is likely to teach me quite a bit about the details of the .NET framework, I’m inclined to go in this direction.

The basic ability to dynamically compile and execute code seems well-developed in .NET, but there are some concerns. In particular, the ability to reclaim resources from dynamic assemblies seems to be sorely lacking in .NET 1.1. (See for instance this entry in Jim Arnold’s blog, and associated links.) Many people seem to be calling for the ability to unload assemblies, but even this feature would be at the wrong granularity to support a Lisp-like language efficiently, which needs to be able to define and redefine functions. If function code memory is never released, this could be a terrible waste of resources, especially when implementing dynamically-created closures as compiled code.

There is hope for 2.0, though. This article on Jason Zander’s blog discusses “Lightweight Code Generation” and methods that are garbage-collectable. It references examples in
this article on Joel Pobar’s blog. I’m still digesting the information in these blogs.

The code for this project is not publicly available at this time.