Sputtering Digitized

Re: The myth of the Lisp Genius

2011-04-27T13:44:00.002-05:00

This post is largely a response to The myth of the Lisp genius and the ensuing conversation on reddit. In particular, I want to respond to the apparent confusion about where the claimed increased productivity could come from in a language like Lisp versus a more traditional language like C, Java or C#.

For me, the core of the productivity gain comes from this statement:

Lisp is a programmable programming language.

- John Foderaro, CACM, September 1991

Consider how natural languages affect your communication with others and your own thought processes. Without a proper shared vocabulary and cultural idioms, it can be very a cumbersome process to express complex and nuanced ideas. It's generally a trial and error process of statement->paraphrase->restatement until both parties feel they've come to a shared understanding. Our mind can even have trouble holding on to concepts that we can't adequately express in language.

Programming a system can feel much the same, when you first start out. Code, test, recode until you feel the code is doing what you intend. As a programmer works on a system, he or she will be developing a cognitive model of the concepts involved. This will in turn lead to a whole vocabulary and language that programmers can use when discussing the system with one another. But, in non-programmable programming languages, they're still required to dumb-it-down when actually writing out the code. This constant re-specification of higher-level concepts in the lower-level language can sometimes lead to bugs in the writing and can inhibit quick recognition of the higher-level intent when reading code. It can also tether the entire thought process to the level of the language.

On the other hand, Lisp allows the programmer to raise the level of abstraction in the programming language itself, so that you can more directly express in code the cognitive model that's been developed, which makes the entire programming process much quicker. This ability largely stems from two facts of Lisp. First, it's syntax is extremely simple. When writing Lisp code, you're largely writing abstract syntax trees serialized in nested lists, rather than expressions that have to be parsed into ASTs. Second, Lisp allows you to write code at several layers of the language. All programming languages allow you to specify code to run at execution time. Lisp also allows you to write code that will be executed by the compiler to generate the expression which should be compiled. Since the generated Lisp code is just a bunch of ASTs serialized to nested lists, and Lisp is very good at LISt Processing, it's relatively easy to write these code generators.

When you combine these two things, a very regular syntax with seamless usage of code generators, then it becomes much easier to add vocabulary and idioms that blend right in with the language, making the code much more straightforward to read, write and reason about.

EclipseCon 2011 and High Performance Tabular Databinding

2011-03-04T11:19:00.003-06:00

This past November, I was honored to have my talk, High Performance Tabular Databinding, be selected from amongst the first batch of EclipseCon 2011 Audition Sessions. Now, the conference proper is fast approaching, so I'm working to finalize the materials for the full talk. I've already watched the recommended video series, and am taking Scott's suggestions to heart in order to eliminate all suck from my talk. As I progress in the prep, I'm also noticing that I had originally shot for far more information than I feel could be properly covered in 20 minutes, so I'm likely to remove the NatTable/XViewer comparison and focus simply upon databinding with SWT Tables. That'll give me the opportunity to dive more deeply into my methods for gathering performance data, and what I found in that data. I'd be interested in hearing from anyone considering attending the talk though. What would make the 20 minutes most worthwhile for you? All in all, I'm very excited to see you all in San Jose in a couple weeks.

Android vs iOS: A(nother) Developer’s Perspective

2010-12-08T09:17:00.010-06:00

While reading Android vs iOS: A Developer’s Perspective from the Whereoscope Blog, I realized a few things that I'd like to share about my own perspective on Android vs iOS development.

For me, the single biggest win of the Android platform is its openness. I don't just mean the freely available documentation (and source) for the platform, though that is a big part of it. What I mean more is the ability for a hobbyist like myself to get software running on the device itself. When I got my iPhone, the first thing I wanted to do with it was write an app for it. I was a bit late to the iPhone party, so the SDK was already out (in fact, the availability of the SDK was one of the final straws that convinced me to buy one), but I was extremely disappointed to find you had to sign up for a paid developer account before Apple would allow you to test software you were writing, even on a device you (ostensibly) own. I can see charging a fee before allowing developers to upload their app to Apple's servers for dissemination through the App Store, but I'd like the ability to fully test software I'm writing on the target device during the development process. And I don't want to start paying the $99/year tithe to Apple until I'm actually ready to start marketing the app.

When I bought my Android phone, I literally had a hello world app of my own running on the device in 15 minutes. Sure, there's a fee to Google in order to host your apps on the Marketplace just as there is to host apps on the App Store, but that fee can be paid by the developer when they're ready to market the application, after they're confident it works to their satisfaction when physically installed on a device. Also, if a developer wants to have friends beta test their application, it's as simple as walking them through a configuration setting change and pointing them at a URL. Finally, Android developers have the ability completely opt-out of the Marketplace and market/sell their applications completely independently, if they so choose. That's the sort of openness (and freedom) that I care about as a developer.

Regarding the observation that "the software is of lower quality, on average," on the Marketplace, I must say that I side with Google's approach to this as well. I'd rather have a wide open Marketplace with crowd-sourced quality control than have a single gatekeeper which is ostensibly in place purely for quality control reasons, but is free to reject or delay apps indefinitely with little to no reason given. And then there's patentgate... I'm just not comfortable entrusting Apple Inc. with ultimate authority over my work.

Eclipse Databinding Aggregation

2010-09-25T15:09:00.008-05:00

In RCP apps I'm working on, especially when displaying numeric data in a Table, I often find myself wanting to have some aggregation support built into Eclipse's databinding framework. As an example, if I have a list of Students, and each Student has a list of ExamResults, it would be nice to easily bind a TableColumn to the average of each student's exam results. To that end, I've created a new project, net.juckel.rcp.databinding.aggregate. I'm relatively new to extending the databinding framework, so I'd greatly appreciate comments on the the API design, as well as suggestions for how to extend the functionality. As a quick example (pulled from the tests on github), here's how you'd create an observable map for the example given above (average score for each student in a list).

IObservableList observableBeanList = new WritableList(studentList,
    Student.class);
IObservableSet observableBeanSet = new ListToSetAdapter(
    observableBeanList);
IObservableMap map = AggregateProperties.average(
    EMFProperties.list(ClassroomPackage.Literals.STUDENT__TEST_RESULTS)
        .values(ClassroomPackage.Literals.EXAM_RESULT__SCORE))
    .observeDetail(observableBeanSet);

C'mon, Apple!

2010-04-09T08:23:00.003-05:00

As noted at Daring Fireball and others, Apple has made the following change in their iPhone Developer Program License Agreement.

Old:

3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs.

New:

3.3.1 — Applications may only use Documented APIs in the manner prescribed by Apple and must not use or call any private APIs. Applications must be originally written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine, and only code written in C, C++, and Objective-C may compile and directly link against the Documented APIs (e.g., Applications that link to Documented APIs through an intermediary translation or compatibility layer or tool are prohibited).

The fact that Apple refuses to allow me to install software I write onto the iPhone 3G that I "own," has already convinced me to not purchase another iPhone (or iPad), but this change makes me want to immediately blend my current iPhone just so I don't continue to add to the statistics Jobs uses in his keynotes to demonstrate the iPhone's popularity.

I'm a large fan of the hardware Apple puts out. The iPhone, iPad and Macbooks are all fantastic from a hardware viewpoint. But as AAPL has exploded over the past decade, Apple has been getting more and more brazen in their lock-in policies. Now, not only does Apple want to control the hardware platform and software platform, they also want to dictate the tools that developers use to perform their work. That's just unconscionable.

I really wanted my next laptop to be a nice, new unibody Macbook Pro (to upgrade my early 2008 model), but unless Apple makes a pretty hard about-face on this, I'll have to vote with my wallet and take my business elsewhere.

More praise for git at Eclipse

2010-02-12T10:47:00.004-06:00

Yesterday, @iamkevb tweeted: #SWT needs help with a carbon bug on 10.6. If you have time and hardware, attach patches to http://bugs.eclipse.org/294929. I happened to have the hardware to test it, so I downloaded a few carbon builds, and succeeded in reproducing the error using the steps posted to bugzilla. Luckily, I found that the latest 3.6 integration build didn't exhibit the same error. Now, I'm no carbon programmer, so I just posted my results as a comment, hoping that someone who knew more about SWT would be able to deduce what changed between 3.5.2RC3 and the latest in the 3.6 integration build. Today, Silenio Quarti posted that he believed the error was fixed as a result of bug #275686. Now, this is where it git comes in. I only had about 30 minutes before I had to be out the door, but I figured that would be plenty of time to whether Silenio was correct. I headed over to http://dev.eclipse.org/git/ to find out the URL for the jface.text project (turned out bug 275686 was a jface change, and didn't even touch the Carbon bindings specifically).

$ git clone git://dev.eclipse.org/org.eclipse.jface/org.eclipse.jface.text.git
 [.. snip ..]
$ cd org.eclipse.jface.text
$ git log --grep='275686'
commit a7d0c902cae6382be0b0812a773f651f75a801d8
Author: mkeller 
Date:   Thu Oct 8 19:22:34 2009 +0000

    Bug 275686: [painting] Rulers should not draw outside of SWT.Paint
$ git checkout -b b294929 origin/R3_5_maintenance
$ git cherry-pick a7d0c902c
Finished one cherry-pick.
# On branch b294929
# Your branch is ahead of 'origin/R3_5_maintenance' by 1 commit.

Then I opened my 3.5.2RC3 carbon build of eclipse, imported the org.eclipse.jface.text project, and File->Export->Deployable plug-ins and fragments. Choose Install into host, and restart the workbench. Voila, Silenio was correct and that commit solved the issue. All told, the above took about 10 minutes, and left enough time for me to sing the praises of git usage at Eclipse in this blog post before I had to be out the door.

Using git to submit a patch to Eclipse

2010-01-06T21:39:00.005-06:00

I've been getting more and more comfortable with git of late, so when it came time for me to poke around at an Eclipse bug (#130854), I decided to work off the git mirrors rather than CVS. I must say, although the Eclipse CVS tools making working with CVS relatively tolerable, using git is a huge improvement for external contributors like myself. Since I was working on org.eclipse.jface, I started with:

git clone git://dev.eclipse.org/org.eclipse.jface/org.eclipse.jface.git
git clone git://dev.eclipse.org/org.eclipse.jface/org.eclipse.jface.snippets.git

After importing those projects into my workspace, I noticed some compilation errors due to recent changes in SWT. Now, the bug I was working on was an old bug, so I didn't have to chase the latest development, so I just switched to the R3_5_maintenance branch instead.

git checkout -b b130854 origin/R3_5_maintenance

Now the project compiled just fine, so I could start poking around at the issue at hand. All told, this was probably just 3-5 minutes, as opposed to drilling through a CVS tree in Eclipse for 3-5 minutes, followed by fetching a coffee while waiting for the branch to check out (another 3-5 minutes), then another 3-5 after realizing I really wanted a different branch. At this point, it was back to a normal git workflow. I mucked around with the code, had about 3 separate commits, all broken, before I realized where I wanted to actually make the change. Just reset HEAD on my branch to ignore those commits, committed the change that actually fixed my bug, then formatted a patch file to send to bugzilla.

git add ...
git commit ...
git reset ...
# repeat until satisfied
git format-patch origin/R3_5_maintenance

All in all, a very quick and painless experience, though this would be relatively easy even using CVS. The real benefit of git would come into play if I had a longer-lived local branch (trying to add a new feature). I'd have full version control available locally to maintain my work as a patchset against the latest upstream work. A hearty thanks to everyone at Eclipse that's been pushing forward on making git repositories available. Even if projects don't migrate to using git as their canonical repo, just having a git mirror available makes working from the outside significantly easier than it has been in the past.

Emacs on Snow Leopard Update

2009-12-03T07:24:00.002-06:00

When last I posted, I was having problems compiling Emacs 23.1 on Snow Leopard, as well as problems with -daemon mode. It appears the upstream emacs repo (git://git.savannah.gnu.org/emacs.git) has resolved the issues regarding compiling on Snow Leopard. Also, -daemon mode has become quite reliable. I can now create new frames and destroy them as often as I want, and Emacs won't crash. I do still have the issue where the modeline font gets garbled after the first connect, but that appears to be related to color-theme (I'm using color-theme-gnome2). If I remove just that one line from my .emacs, then the modeline problem goes away as well.

Emacs patches to build on Snow Leopard

2009-09-13T14:19:00.002-05:00

I've been tinkering with the Emacs 23.1 code lately, trying to get it to compile on Snow Leopard, and get --daemon mode working on Mac OS X as well. I'm posting my patches to github as I work on it. I'm a bit of a git noob, so I'm not certain how (or even if) I could make a public repo on github of my branch, containing just my branch changes, and derive from git://git.savannah.gnu.org/emacs.git for the bulk of the data. That would be ideal, rather than maintaining a repo of patches. Also, even though the patch does get Emacs to compile, there are some obvious issues with it, so it's not ready for production use. First, font heights are not being calculated correctly. Second, there's very obvious lag when first starting up the window, which I must have added (as the 32 bit 23.1 binary doesn't have that problem).

Snow Leopard and Time Machine over NFS

2009-09-12T12:58:00.005-05:00

Ok, admittedly, I muck around with my systems more than strictly necessary (those that know me are guffawing at how much I'm understating this tendency), but I was having some issues getting Snow Leopard's Time Machine to continue backing up to my OpenSolaris file server over an NFS mount. My first problem was that I had somehow lost my NFS config on the OpenSolaris box. May have been due to a recent zpool upgrade, or due to the fact that I had recently completely destroyed and re-created that pool. In any case, I hadn't noticed this for a while because my NFS mounts were still working as expected for my average usage. After recreating the NFS share info (including the ability for root users on my MBP to be mapped as such on my file server), Time Machine got a bit further along. But now, it seemed to be complaining that it didn't have enough room on the backup drive. I hastily destroyed the old sparsebundle thinking that it a fresh start with a new image would work fine. When trying to backup with no sparsebundle available on the server, it gave the expected error due to being unable to create a sparsebundle directly on an NFS share. I still don't know why that's the case, but I remembered doing the same the previous time I set it up, and just created a sparsebundle locally then copied it to the server.

sudo hdiutil create -size 200g -type SPARSEBUNDLE -nospotlight -volname "Time Machine" -fs "Case-sensitive Journaled HFS+" -verbose /tmp/MACHINENAME.sparsebundle

Unfortunately, now when it tried to connect, I still saw TM attempting to create a new bundle. Not sure why, I decided to poke around backupd with dtrace for a bit to see what it was doing on the file system.


#!/usr/sbin/dtrace -s
syscall::open:entry
/execname=="backupd"/
{
 printf("UID %d: Opening file: %s.\n", uid, copyinstr(arg0));
}

syscall::open:return
/execname=="backupd"/
{
 printf("UID %d: Opening file returned: %d.\n", uid, arg0);
}

Turns out, TM was trying to read a file called com.apple.TimeMachine.MachineID.plist from within the sparsebundle directory (not the mounted image, just the directory). Some searching for that file name brought me to this page where they had the following as the suggested content for that file:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
 <key>com.apple.backupd.HostUUID</key>
 <string>YOURUUIDHERE</string>
</dict>
</plist>

After dutifully replacing YOURUUIDHERE with my machine's UUID (pulled from System Profiler -> Hardware), Time Machine finally mounted my sparsebundle as requested and started the backup.

Highlights and Lowlights of Snow Leopard

2009-09-01T10:10:00.003-05:00

I've had a few days to play around with Snow Leopard now, so I thought I'd just note a few of my favorite bits and a few nits I'd like to pick. The Good:

Four finger gesture support on my early 2008 MBP. I love this, and find myself already using it all the time for running Expose.
Improved services and creating services with Automator. About 20 minutes after I had Snow Leopard installed, I had an Automator workflow added to the services menu to open the selected file or folder in Emacs (still haven't finished debugging the --daemon mode on OS X yet though).
Hiding applications to their app icon, rather than a separate slot in the Dock. It used to drive me a bit crazy that when I clicked a doc icon for a hidden app, the app itself wouldn't pop back into view, and instead I'd have to find the minimized window. No more.
Dock Expose. I also find myself using this quite often to select a given window of an app.

The Bad:

Doesn't boot 64 bit by default. Wasn't this supposed to be one of the big selling points of Snow Leopard? Why do I have to hold magic keys during boot or update a plist to get this enabled?
Once I've booted into a 64 bit kernel, I'm having issues with both VMWare Fusion and VirtualBox. Fusion simply refused to start. VirtualBox attempted to start, but caused a kernel panic.

Getting Emacs 23.1 --daemon to play nice on Mac OS X

2009-08-24T19:34:00.007-05:00

I've been a hard core GNU Emacs junky for nearly as long as I've been using computers, and definitely as long as I've been programming. To get my Emacs fix on Mac OS X, I've been using Aquamacs, and while I think they do a great job in general, I don't think I'm really their target audience. I'm not really looking to have a more Mac-like experience in Emacs, I just want an Emacs experience on my Mac. I was very excited to find that the GNU Emacs folks were finally main-lining the NextStep/OpenStep/Cocoa support with version 23. I was also very interested in --daemon mode, as I do have a fair amount of elisp that gets executed on startup. Unfortunately, all did not work perfectly on Mac OS X with 23.1. While the the first connection using emacsclient worked fine, after disconnecting and reconnecting, the font in the modeline would be garbled, and after disconnecting the second time, Emacs would crash. Console.app reported the stack trace each time as similar to:

Thread 0 Crashed:
0   libSystem.B.dylib              0x90071e42 __kill + 10
1   libSystem.B.dylib              0x900e423a raise + 26
2   libSystem.B.dylib              0x900f0679 abort + 73
3   org.gnu.Emacs                  0x00177985 ns_term_shutdown + 117 (nsterm.m:4015)
4   org.gnu.Emacs                  0x0009cf3f fatal_error_signal + 399 (emacs.c:389)
5   libSystem.B.dylib              0x900702bb _sigtramp + 43
6   ???                            0xffffffff 0 + 4294967295
7   libSystem.B.dylib              0x900e423a raise + 26
8   libSystem.B.dylib              0x900f0679 abort + 73
9   org.gnu.Emacs                  0x001262de font_clear_cache + 366 (font.c:2708)
10  org.gnu.Emacs                  0x00126b3b font_update_drivers + 731 (font.c:2653)
11  org.gnu.Emacs                  0x000116ba delete_frame + 442 (frame.c:1466)

Checking font.c:2708, I found:

font_assert (font && driver == font->driver);

I believed (and Wikipedia confirmed) that == binds tighter than &&, so I applied the following patch:

--- emacs-23.1/src/font.c 2009-07-28 09:51:20.000000000 -0500
+++ emacs-23.1-modified/src/font.c 2009-08-24 08:15:31.000000000 -0500
@@ -2705,7 +2705,7 @@
 
         if (! NILP (AREF (val, FONT_TYPE_INDEX)))
    {
-     font_assert (font && driver == font->driver);
+     font_assert (font && (driver == font->driver));
      driver->close (f, font);
      num_fonts--;
    }

That does indeed get me a correct modeline font on the second connection from emacsclient, and the second disconnect appears to work as well, but on the third connect, Emacs is still crashing. Just with a slightly different stack trace now:

Thread 0 Crashed:
0   libSystem.B.dylib              0x90071e42 __kill + 10
1   org.gnu.Emacs                  0x0009ceea fatal_error_signal + 314 (emacs.c:404)
2   libSystem.B.dylib              0x900702bb _sigtramp + 43
3   ???                            0xffffffff 0 + 4294967295
4   libSystem.B.dylib              0x900e423a raise + 26
5   libSystem.B.dylib              0x900f0679 abort + 73
6   org.gnu.Emacs                  0x00177985 ns_term_shutdown + 117 (nsterm.m:4015)
7   org.gnu.Emacs                  0x0009cf3f fatal_error_signal + 399 (emacs.c:389)
8   libSystem.B.dylib              0x900702bb _sigtramp + 43
9   ???                            0xffffffff 0 + 4294967295
10  com.apple.CoreGraphics         0x96f68b3c _setWindowRegion + 382
11  com.apple.CoreGraphics         0x96f6899a CGSClearDragRegion + 75
12  com.apple.AppKit               0x90bf317d _NSClearDragRectsInWindow + 62
13  com.apple.AppKit               0x90bf2b4d -[NSFrameView _resetDragMargins] + 219
14  com.apple.AppKit               0x90b1c32f -[NSThemeFrame _resetDragMargins] + 188
15  com.apple.AppKit               0x90b22a03 -[NSTitledFrame setTitle:] + 724
16  com.apple.AppKit               0x90b22540 -[NSWindow _dosetTitle:andDefeatWrap:] + 324
17  com.apple.AppKit               0x90ea417f -[NSWindow _calcAndSetFilenameTitle] + 361
18  org.gnu.Emacs                  0x001838fc ns_set_name_as_filename + 908 (nsfns.m:667)
19  org.gnu.Emacs                  0x00035577 prepare_menu_bars + 919 (xdisp.c:9506)
20  org.gnu.Emacs                  0x000364dd redisplay_internal + 3373 (xdisp.c:11475)
21  org.gnu.Emacs                  0x00036e38 redisplay_preserve_echo_area + 56 (xdisp.c:12093)
22  org.gnu.Emacs                  0x0015b224 wait_reading_process_output + 4852 (process.c:5018)
23  org.gnu.Emacs                  0x0000ccf6 sit_for + 214 (dispnew.c:6647)

Obviously, I have more testing/work to do.

Paraphrase of Greenspun's Tenth Rule

2009-08-16T08:23:00.003-05:00

Recently, I was trying to convince some team members that OSGi would be a good choice for a system we're designing. After indicating the benefits, as I saw them, one person asked, "Couldn't we accomplish the same thing by doing x, y and z?" At the time, I had a rather dry counter, but it occurs to me that Greenspun's Tenth Rule can be rather accurately adapted to the current Java development landscape.

Any sufficiently complicated Java program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of OSGi.

Note to self...

2009-04-18T18:44:00.002-05:00

Never run zpool add when you mean to run zpool attach on your new disk. Apparently, zfs does not yet support shrinking a zpool. On the bright side, though I may not have redundant storage, I've now got much more space in my pool!

Upgrading an OpenSolaris Guest for Virtual Box 2.2

2009-04-08T18:40:00.003-05:00

Virtual Box 2.2 was just released. I was rather excited to try Compiz in a box, but was soon disappointed to find that my guest OS could not start properly. After some tinkering, I booted into single-user mode (hit e on the text boot line, then add -s at the end of the kernel$ line, then hit b to boot), and ran pkgrm SUNWvboxguest to remove the old guest additions, which allowed the guest OS to boot up just fine.

Continuing with Cocoa SWT

2008-09-13T11:08:00.002-05:00

I had some problems building the JNI code for Cocoa SWT on my MBP. First, I didn't want to get sidetracked by building a specific XulRunner SDK, so I just downloaded the 1.9.0.1 binary available from mozilla.org. Next, I had to make a couple minor modifications to org.eclipse.swt/Eclipse SWT PI/cocoa/library/make_macosx.mak. After specifying the proper location for XULRUNNER_SDK, I still ran into the following problem in the build:

[exec] /Library/Frameworks/XUL.framework/Versions/1.9.0.1-sdk/sdk/include/nsStringAPI.h:1053: error: size of array 'arg' is negative

That line contains:

PR_STATIC_ASSERT(sizeof(wchar_t) == 2);

A quick C program proved that wchar_t was actually 4 bytes on my machine. After commenting out the HAVE_CPP_2BYTE_WCHAR_T define in mozilla-config.h within my xulrunner install, I reran the build from Eclipse, and everything compiled. Now on to the actual work of adding NSFormatter and NSNumberFormatter to the JNI code.

First steps into SWT/Cocoa

2008-09-03T21:29:00.006-05:00

As I recently picked up a MacBook for myself, I've decided to put some effort in to contributing to the SWT/Cocoa port. First step, is choosing a bug. I'm relatively new to both Cocoa and SWT development, so I decided to start with something that should be relatively easy. I chose bug 222791. First step was to write a simple Cocoa app with a a spinner type control written natively. Turns out that an SWT Spinner is simply an NSTextField and an NSStepper which are linked together. The way Cocoa validates text entered into an NSTextField is through a formatter associated with that field, and specifically by sending the following message:

- (BOOL) isPartialStringValid: (NSString  *)partialString
         newEditingString: (NSString **)newEditingString
         errorDescription: (NSString **)errorDescription

This is where things get a little trickier. This method is called from Cocoa, not from our Java application, but the SWT mindset is that the OS wrapper should be as thin as possible. I shouldn't just write up an NSFormatter in native code and reference it from Java. Rather, I need to find a way to trampoline this Cocoa callback into our Java code. Naturally, there are plenty of examples of this, especially in the Display class for the Cocoa port, but OS.java (when I started) did not contain the above selector. My easy bug has quickly morphed in to something requiring me to regen the JNI layer for SWT... Time for a bit more research before I can really dig my teeth in.

More Mucking with Solaris

2008-03-22T10:03:00.003-05:00

I've been trying out OpenSolaris again lately, this time installing OpenSolaris Developer Preview 2. Especially now that I've got a ZFS root filesystem, I'm very much enjoying the power of ZFS.

For instance, I've been mucking around with building fox-gate lately. Well, as I'm doing many modifications to the system in order to try to get this build to work, I decided to do the following:


$ pfexec zfs snapshot rpool/ROOT/preview2@prefox

This made it easy to clone that snapshot, do my updates (including a BFU, which I was pretty sure would end poorly), and be assured that in the worst case scenario, I could always boot that snapshot to figure out what I broke on my original, or even just revert the original entirely. Luckily, I figured out a workaround for my booting problems after the BFU, so I didn't have to revert to the snapshot, but it is definitely very empowering to know that the option is there. No having to deal with backups or a convoluted restore procedure. Just zfs snapshot, zfs clone and zfs rollback.

Small Update

2008-02-02T21:27:00.000-06:00

Been a while since I've posted anything, so here's a quick state-of-the-hobby address.

Been playing with JRuby on Rails for running a RoR app that I've been maintaining for a few years. All in all, JRuby on Glassfish seems to work without major incident, which is nice.
I finally gave up on running the Radeon DRI driver on Solaris. The non-DRI driver has significantly better performance, currently.
I've always been a fan of Eclipse, and my recent toying with NetBeans didn't convince me to become a switcher, so I've gone back to playing with Eclipse plug-in development.

Nothing more substantial than that for now.

Radeon DRI Update

2007-12-25T09:48:00.000-06:00

I got a response from Minskey on the xwindow-discuss alias regarding my trouble upgrading SXCE with the Radeon driver installed:

I am sorry. I should have mentioned it early. The upgrading install or bfu will override the drm module (/kernel/misc/(amd64)/drm) and consconfig_dact (platform/i86pc/kernel/dacf/(amd64)consconfig_dacf). It is because the consconfig_dact is replaced during upgrading. So, before you upgrade your system, you have to : 1. remove radeon driver by "rem_drv radeon" 2. upgrade your system; 3. re-install radeon driver by install.sh scrip in the tarball; -minskey

SXCE b78, and the Radeon DRI snapshot

2007-12-21T22:56:00.000-06:00

This morning I did a live upgrade to SXCE b78, but unfortunately ran into some issues. When booting the system, I got the error: WARNING: consconfig: no screen found Can't find driver for console framebuffer I did compares of /etc/driver_aliases on both BEs, and checked for differences under the /kernel tree. I did find one file, /kernel/misc/drm~11 that certainly looked suspicious. I tried moving that file into it's proper place, /kernel/misc/drm, but still the new b78 BE would not boot. After digging a little further in to the install script, I found another path /platform that contained some x86-specific drivers (likely obvious to all you long-time Solaris admins). Again, I found a file /platform/i86pc/kernel/dacf/consconfig_dacf~11. After finding two files like this with the same extension, I decided to do a simple: find $newBE -name '*~11' > /tmp/filelist.txt This turned up quite a few files. Doing a quick search for relevant files, I came up with the following list:


/kernel/misc/drm
/platform/i86pc/kernel/dacf/consconfig_dacf
/usr/X11/lib/X11/xserver/libdrm.so.2
/usr/X11/lib/modules/drivers/ati_drv.so
/usr/X11/lib/modules/drivers/atimisc_drv.so
/usr/X11/lib/modules/drivers/radeon_drv.so
/usr/X11/lib/modules/extensions/libdri.so

After moving all of these files from their *~11 variant to the path listed, I can now boot into b78. Unfortunately, I must not have done everything right, because the display no longer has direct rendering enabled, but I'm sure I can fix that soon enough. At least I've got the system booting again. I've found myself in this position more often than I'd care to admit.

Java Generics

2007-12-19T06:48:00.000-06:00

My surprise at not being able to bind a table to a List<Weekend> in NetBeans is not at all surprising when I remember that Java Generics are really just compiler notes, not actual generic types. An ArrayList<String> is exactly the same type as an ArrayList<Weekend>.

OpenSolaris DRI Follow-up

2007-12-17T21:35:00.000-06:00

Well, ask and you shall receive. I got in touch with the people involved in porting DRI to OpenSolaris, and it turns out they had recently released a snapshot of their efforts. I got that installed this afternoon, but I'm still having some problems. Direct rendering is enabled, but I'm having trouble with AGP support (which may just be a configuration issue, I haven't played with it much yet). Performance still isn't quite where I'd like it, but it's nice to see progress. I'll be following their progress with much interest.

JEE 5 Development with NetBeans 6 First Impressions

2007-12-15T12:01:00.000-06:00

Playing around with Netbeans 6 for writing my trivia software for a couple hours now, and I must say, even with the great tool support this JEE 5 stuff is a relatively slow development process. Particularly frustrating is that it doesn't appear that Netbeans is terribly good at auto-generating a JUnit test that can access the JEE context. I got relatively spoiled with RoR with my last trivia re-write, so I really expect unit testing to be a first-class consideration for any programming environment. If the environment makes it difficult to unit test, then it makes it difficult to develop, end of story. I'm certain that it's possible to get my unit tests set up to actually run, but as a JEE newbie, I'm not sure exactly how to go about it, and I feel time spent figuring out how to make a JEE context available to JUnit is time that's pretty wasted. I'm attempting to add a JSF page for displaying some of my entities, but even that is relatively painful. While the Scaffolding that Rails provides is rarely used in the final deployment of an app, it is very nice to have that structure there from the get-go so that you can hit the ground running. I'm finding in NetBeans that I'm having to build up that scaffolding myself (though it's possible that I just missed some wizard for generating a default interface for managing your entity beans). When I create a Visual JSF page in NetBeans, it creates a ton of (IMO) useless junk in the resulting classes. Also, what's with the ugly SessionBean1, RequestBean1, etc. I see the purpose for the classes, but are they really manditory? If not, why have them created by default? Finally, it was relatively irritating using NetBeans Bind to Data functionality for binding some data to a JSF table. I tried a few times to expose a List<Weekend> (a weekend is the top level entity in my trivia software) and bind the table to that, but it wouldn't appear in the magic Get Data From drop down. Apparently, I have to expose the property as an array (Weekend[]) rather than a generic List. I'm certain that it's possible to code around these issues that I have, but from a first-impression stand-point, NetBeans and JEE 5 aren't really impressing me that much. I do feel that JPA is a vast improvement over EJB 2.1persistence, but I'm really not sold on JSF (I may just go back to straight JSP/Spring MVC for this project) or NetBeans default JEE wizards. Also, the emacs keybindings for NetBeans are atrocious. Ctrl-G should stop the previous incremental search (and turn off highlighting of the results), not bring up a go to line dialog. It doesn't appear that Ctrl-Alt-f and co aren't working. Emacs bindings are more than just Ctrl-a, Ctrl-e, Ctrl-p, Ctrl-n, people. It doesn't appear that there's any notion of a mark, nor a kill ring. Eclipse at least does a very adequate job of emulating these features (though I still run into surprises when using Eclipse). Anyway, that's enough brain dumping for today. Perhaps once I get this initial scaffolding in place for my project I'll start to see some productivity improvements. Also, I've always felt that one of the strongest arguments for using Java over scripting languages is the superior support for debugging and observability, not initial developer productivity.

OpenSolaris for Mobile Development

2007-12-15T11:41:00.000-06:00

I generally prefer to use my laptop for all my hobby programming for various reasons. I currently have my laptop set up as a dual boot system with both Windows XP and OpenSolaris (SX?E b77) installed. I've been trying for over a year now to get really comfortable with OpenSolaris as a development OS, but for my particular needs, it is still a somewhat troubling experience. For instance, I've been using NetBeans 6.0 a lot recently (for the JEE trivia app that I've been working on), but NetBeans is painfully slow on my ThinkPad t42p. This may be due to the pretty sluggish performance of GUIs in general since OpenSolaris does not have direct rendering support for my ATI video card (yet), but it is still disappointing that running the most recent Sun IDE on the most recent Sun OS on the most recent Sun JVM leaves much to be desired with respect to productivity. I really want to like this OpenSolaris experience, but the following issues always make me feel like going back to Linux or perhaps even Windows for my development machine. Here's my current wishlist for developing on OpenSolaris on my laptop:

Direct Rendering support for my ATI 9600 Mobility card. The graphics performance on this machine is very noticibly sluggish.
Bluetooth support so that I can use my mobile mouse. This mouse has worked fine for me in Linux, FreeBSD and Windows, but I still cannot get it to work on Solaris.
Proper support for my Synaptics trackpad. Even if I had a working external mouse, I still find the convenience of having the track pad right and mouse buttons right at my fingertips to be very helpful. Right now, it simply works as a default PS2 two-button mouse. No middle mouse button, no scroll-wheel emulation, no disabling of tap-to-click, etc.
A proper upgrade solution for the base OS. Indiana isn't quite there yet (from what I've heard, I've been too busy with other things to actually give it a test run so far), so I'm still using Solaris Express. I've decided to build all my local software packages under my home directory now, since I'm wiping the system partition so often for re-installs. Also, it's a little frustrating to have to download 3+ GB of data, just for incremental updates.
ZFS for the root partition in a way that's upgradable. I did set this up once using the manual procedure, but I was then completely unable to upgrade the OS with the current OpenSolaris install tools (aside from BFU, of course, though I'm not completely sold on going that route, and being resposible for updating each consolidation manually).
Seemless support for suspend, hibernate, resume. I've had this working just fine on Linux and Windows (not FreeBSD last I checked), and it is definitely one of the compelling features of laptop development that I'm missing out on while using OpenSolaris. If I want to shift locations, I have to either close down all my apps, or close the lid while the computer still runs. Also, it's nice to be able to simply hibernate the machine overnight, so the next time I have a few minutes for development time, I can have my environment set up just as I left it, without having to leave the laptop on 24/7.

That said, I should point out that it isn't all bad, of course. There are some good aspects of using OpenSolaris as my dev platform (which is why I haven't wiped it quite yet).

ZFS for my home partition rocks. Being able to send my home partition to another machine, with incremental snapshot upgrades, is great. Setting auto-compression for my source directories helps me save a bunch of space.
Having DTrace (and the other observability tools) available is wonderful, as well as the fact that Java/PostgreSQL both come with DTrace probes enabled on Solaris Express.
Having the latest Gnome is a nice touch. I've been using Gnome for my desktop environment for many years now, so the actual desktop on Solaris Express is extremely familiar.
NWAM has made a wonderful difference in my everyday usage. I can now easily set up my network whether I'm wireless at home, wired at home, or on using the free wireless at my local library and/or Panera. This lets me at least not have to worry about network connectivity while working.
Having a full Unix command line available all the time. This is something that I really miss whenever I have to use Windows. I always install cygwin, but even so, I often have compatibility issues while using it under windows, and I simply cannot be productive without the Unix shell that I've grown to love in the decade since I first installed Linux.

Now, many of the issues that I mentioned in my nit-picking are currently being worked on, but I still get the feeling that the OpenSolaris community isn't the most open (e.g. Why exactly was b78 delayed, and when will it be available? Is there anything the community can do to help the build/deploy process along?), so it is difficult to tell when exactly these enhancements will be released.

Introduction

2007-12-15T11:33:00.000-06:00

The obligatory introductory post. Sputtering Digitized is simply a place for me to capture my own musings on programming. I'm interested in quite a few different topics, from programming languages (Java, C, C++, Objective-C, C#, Erlang, Smalltalk, Lisp, Ruby, etc), to programming environments (Eclipse, NetBeans, Visual Studio, Emacs, Vi) to operating systems (Linux, OpenSolaris, FreeBSD, Windows). Currently, my hobby time is being focused on OpenSolaris, Erlang, JEE 5 and NetBeans. These interests are all stemming around an annual trivia contest that I've been part of for a number of years. I inherited some software for our trivia team, and have been maintaining it for a number of years. I generally use it as an excuse to try building a full solution in different environments. The system started out as a C# app connecting to a MySQL database with a PHP front end. I later ported it to a C# app connecting to web services run by Ruby on Rails with a PostgreSQL database as the backend. This year, I'm attempting to port the whole system to a full JEE stack, with a Swing and JSF front-ends, and EJB/JMS for the backend (though still connecting to my PostgreSQL database).