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.

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.

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.

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.

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

SXCE b78, and the Radeon DRI snapshot

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

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