Wednesday, April 27, 2011

Re: The myth of the Lisp Genius

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.

Friday, March 4, 2011

EclipseCon 2011 and High Performance Tabular Databinding

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.

Wednesday, December 8, 2010

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

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.

Saturday, September 25, 2010

Eclipse Databinding Aggregation

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);

Friday, April 9, 2010

C'mon, Apple!

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.

Friday, February 12, 2010

More praise for git at Eclipse

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.

Wednesday, January 6, 2010

Using git to submit a patch to Eclipse

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.

Thursday, December 3, 2009

Emacs on Snow Leopard Update

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.

Sunday, September 13, 2009

Emacs patches to build on Snow Leopard

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).

Saturday, September 12, 2009

Snow Leopard and Time Machine over NFS

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.

Tuesday, September 1, 2009

Highlights and Lowlights of Snow Leopard

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.

Monday, August 24, 2009

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

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.

Sunday, August 16, 2009

Paraphrase of Greenspun's Tenth Rule

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.

Saturday, April 18, 2009

Note to self...

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!

Wednesday, April 8, 2009

Upgrading an OpenSolaris Guest for Virtual Box 2.2

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.

Saturday, September 13, 2008

Continuing with Cocoa SWT

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.

Wednesday, September 3, 2008

First steps into SWT/Cocoa

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.

Saturday, March 22, 2008

More Mucking with Solaris

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.

Saturday, February 2, 2008

Small Update

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.

Tuesday, December 25, 2007

Radeon DRI Update

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