Where our future is being hatched…

August 2, 2008 – 3:58 pm

These are beautiful pictures from LHC. The Large Hadron Collider is the latest super collider. It announces a shift back to Europe as the center place for High Energy physics. Back in April, CERN held Open Day 2008 so we took that opportunity to make a family trip from the US to Geneva to visit the facility. This was an old dream of mine, from the time when I was learning physics in high school and LEP was nearing completion. I never visit LEP, and I missed the opportunity to see the ongoing work on LHC four years ago, during CERN’s last open day. So with LHC coming online this year, I wanted to get into the tunnels before full commissioning.

beam pipeThis is the beam pipe as it enters the LHCb detector. Just outside of this picture, on the right side was where the beam pipe connected to the accelerator. The main goal of LHCb will be to explore the matter/anti-matter asymmetry and try to explain how the universe went from an equal amount of both, to the predominately matter-made universe as we know it today. LHCb is only one of the four massive detectors built around the accelerator. These detectors will be serving six experiments focussed on different aspects of modern physics. ALICE will be traveling back in time to immediately after the Big Bang, looking at a hypothetical state of matter where quarks roamed freely. ATLAS and CMS will be, among other things, looking for the holy grail: finding the elusive Higgs boson, the hypothesized corner stone of the standard model. LHCf will be chasing cosmic rays, and TOTEM will complete the measurements of other experiments. What’s interesting is that the accelerator itself is built by CERN, while the experiments are the result of massive collaborations between research facilities worldwide… the ultimate ‘BYOD (bring your own detector) to our particle smashing party’.

The most interesting aspect of my visit there was the patience and passion displayed by all the physicists I met. These people are lucky enough to do something they are passionate about, and the willingness to share it with anyone coming with an open mind. This is basically to science what Stallman and the FSF have tried to do for software: the idea of Open Science. The highest question on my mind was of course “so what happens if the Higgs does not show up?”. Aside from actually being the most interesting scenario, and the one likely to save jobs rather than slash them (finding the Higgs would represent the end of a nearly 40-year chase and would probably close the door on a number of alternate theories and experimentation currently seeking it), he suggested that a plausible scenario would be that what we call the Higgs could be the accumulated effects of a number of distinct particles, the multiplicity of particles explaining why the detector would not show one where we expected it.

As usual, in parallel with the grounds braking science, a lot of doom’s day predictions have been going-on, and in the most foolish american tradition, layers have joined the party …. Aside from the cheer stupidity of some of the claims that can be found on the Internet (Enrico Fermi should really not have made his famous joke about igniting the entire atmosphere, as they were on the verge of the Trinity test), this lawsuit also demonstrates the incredible arrogance of some people who do not question for a minute whether or not a US court has any jurisdictions in matters happening IN OTHER SOVEREIGN COUNTRIES… As I cannot for a second imagine that the people involved in this frivolous lawsuit are that incredibly ignorant, I favor the explanation that everyone involved is just in there for the publicity. June was supposed to be the scheduled date for a hearing on whether or the not the complaint was receivable by the court.

Considering Wagner’s past track-record as a naysayer I am not surprised to find him behind this lawsuit. However, I find really comical that on his own web site he would shamelessly quote himself as the “leading scientist” who brought forward the concerns that started it all.. I guess he could not really say because no serious scientists seemed to have any unaddressed concerns about the science behind LHC, this is how I recycled my old write-up from another silly crusade to try to get people to notice me, seeing how lonely I feel now that I am retired and all. What I wonder though is how an obscure retired government employee with only a minor in physics (public knowledge from the court papers he filled) can find the money to finance this crusade… I guess there are a lot of organized groups in America today that are afraid of mankind getting out of the mud puddle where we come from to use our brains for other things than blind obedience, that would finance anything as long as it promotes living in caves with candles and the fear of the unknown.

Interesting links

Some patient debunking

Apple is really not a software company

July 26, 2008 – 10:23 am

A couple of days ago I updated the firmware for my iPhone to 2.0, and transfered my .Mac account (not that I had any choice in the matter) to mobileMe. I should have known better… A minute ago my phone rang, and all I could do was listen to the ring until it stopped ringing. The phone would not let me pickup the call.. now, he was not entirely unjustified, as I had just plugged it on its cradle and iTunes had just kicked in to begin a synchronization… But you think whoever programmed it could have thought geez, we might want to overlay a small notice on the screen to let the users know why the screen is not responding at this time. But nope… looks like however simple this use case is, it fell into a crack. To check what the cause of that temporary freeze was, I tried to switch to iTunes… only to realize that despite the Mac Book Pro being a dual core machine (not to mention the 8 cores available to the Mac Pro), iTunes had also becom unresponsive…

In recent times, Apple has enjoyed a new popularity, primarily due to its two sugar daddies: the iPod and more recently the iPhone. In the process they have jumped on the ambulance and added their twist to the load of bad press Vista has enjoyed (not really a difficult thing to do to criticize Vista… make your pick, and shoot). Being a recent (2 years) switcher myself (no fanaticism here, I jumped to Apple because I was bored with the rest of the platforms, having spent a great deal of years learning their ins and outs both as a user and a programmer), I have been able to look at Mac OS with more objectivity: Apple is really lucky!!! There is no way that Mac OS is the “oh-so holy” platform that the company makes it to be in their brilliant ads. If anything, and considering the relative complexity of the two endeavors (Vista vs. Mac OS), there is no doubt in my mind that Vista is ‘better’ quality. I mean this in relative terms rather than absolutely.

Consider this for a moment: Apple is pretty much the sole hardware vendor for its platform. They actively develop for a wopping 4 or 5 motherboard designs at any given point in time, for which they only have to care about 4 or 5 video card chipsets, not all of them working on all the motherboards… with such a small set of permutations, they still manage to collect one significant blunder after another, the likes of:

  • the NVidia 8800 not working with the older clovertown predecessor on the day the board is launched,
  • having my laptop loose track of when it is asleep or awake (the screen would light up when I closed the lid and shut down when I opened the lid),
  • have some pretty nasty set of artifacts show up while playing video on the latest Mac Book Pro,
  • have my Mac Book Pro all confused when I attach/detach an external 30′ screen (the poor thing sometimes thinks the screen is there when it is not, and worse yet, thinks it has the same resolution as the internal screen, which is not even supported on the 30′ screen, leaving it blank until I reboot…),
  • have their own keyboard become randomly unresponsive while attached to their hardware and running their very own operating system and drivers (what, they are so advanced that no one is using a keyboard at Apple?),
  • or last but not least, have many people complain about the disappointing video performance level of the newest Mac Pro/NVidia 8800GT compared with the older ATI Radeon HD 2600 (pretty sad for a $3000 machine)…

And these are only the ones I remember of the top of my head for the last 16 months.. Compare that to the huge array of motherboards and peripherals any version of Windows has to, and most of the time does, operate on and you get the picture: Apple is the undisputed king of glitz but the quality of their software is in no way a match for the imagination of their marketing department.

So I can’t use my phone, iTunes can’t make use of the cores available in the machine, but I can sleep soundly with the reassurance from Bertrand Serlet(based on a true conversation I had with him), until recently the head of all things software at Apple, that Apple took great care to insure that all the Mac software is built with the greatest quality hashing algorithms… Am I the only one thinking what I think?

As I was writing this, I noticed a posting on Apple Insider referring to Apple’s acknowledgment of their troublesome start with MobileMe with the following:

“The team has also fixed over 70 bugs including one that was preventing MobileMe IMAP mail folders from syncing correctly between the web app and Mac OS X Mail or Outlook,” the employee notes, “plus others correcting display issues in Calendar and in general enhancing the performance of our web apps.”

Now that one tops it all… great that you fix 70 bugs AFTER the service has been launched.. but to fix something that “was preventing MobileMe IMAP mail folders from syncing correctly”, I have to say… THAT is arrogance. It basically means (which we should all already know) we are just walking wallets that can be fed any sort of non-functional crap, as long as it has a pretty color.

Apple is really not a software company… pretty scary considering how strongly they are pushing for everyone on the platform to be locked in a exclusive dependency on their development tools.

Advanced SWT graphics

July 19, 2008 – 6:05 am

In parallel with my portable Cairo GC project, I have been working on a library to simplify the creation of better looking SWT application. In particular, I got interested in building a customizable widget that would adopt different looks on different platforms and in different parts of an application. This is an example showing the widget as a replacement for the default status eclipse status bar. None of it is the result of using bitmaps, including the small icone on the buttons on the left side.

In the process of adding enhanced graphic effects to the widget, I ran again into SWT’s abysmal lack of support for advanced imaging when compared with Swing. The sum total of the resources available to deal with images in SWT is pretty much the following list. The sad part is that they pretty much all agree that manipulating images with the SWT can be quite time consuming and somewhat out of scope for SWT.

One of the usage for my widget is to replace the default eclipse perspective switcher on platforms where my unified toolbar is not available. The widget will support creating something like this with only a few lines of code.

One of the building blocks needed for that is a decent image effects library. A year ago, Daniel Spiewak tried to take a crack at showing how to create reflection effects on an SWT canvas. Although interesting, the result is nowhere near this, that, and much less that. Mathias Muller posted his own version of something similar, also suffering from some problems.

So starting with Romain’s work as a model…

… I started building my own graphics testing application. The snapshot uses the same bitmap Romain used in his example. The current code does not support variable length shadow, but this is coming next. The application also demos some of the additional capabilities I added to my graphic library. Among other things, it supports most of the compositing modes Romain built in BlendComposite.
These are additional examples running the sample testbed application:

Portable Cairo GC for SWT

July 19, 2008 – 4:18 am

For several years I have been impressed with the work Romain Guy did to popularize some of the advanced graphic capabilities of Swing. It was his post on transparent windows on Mac OS that pointed me in the direction of the JNA API which I ended up using to prototype support for the Mac OS unified toolbar with SWT.

Some of his early experimentations with AlphaComposite drew my attention to how poor the SWT API actually was in the arena of advanced graphics. At the time, most of my time was spent inside the linux Kernel or in server based Java applications, so I wasn’t overly bothered by it.

In the last two years, I gradually shifted my focus back to client side applications, as part of a rather large modeling and simulation project. Being the architect for the project, I had to make a decision about which technology to use for the dashboard module (a GUI application that controls distributed simulation environments). Considering the heavy investment in OSGi for the distributed server architecture, I decided to use SWT/JFace.

Spending again a great deal of time in and around SWT, I was again stumped by some of its shortcomings and the lack of interest from the SWT team (don’t get me going on this one) to fill some blatant gaps when compared with Swing. The absence of support for Porter-Duff composition in SWT, despite support by all the major GUI platforms once again hit me in the face.

Having seen the power of this simple abstraction in the Swing world, I quickly added support for Composition to the current GC definition.

public interface Composition {
    public CompositionContext createContext(PaletteData srcColorModel,
            PaletteData dstColorModel,
            int hints);

    public void dispose();
}
public abstract class CompositionContext extends Resource {
    CompositionContext(Device device) {
        this.device = device;
    }
    public abstract void compose(ImageData src,
                                            ImageData dstIn,
                                            ImageData dstOut);
    public abstract void dispose();
}

With this as a starting point, it was easy to create an AlphaComposition implementation based on the Carbon API. The problem with SWT is that any change made to it must be created for all supported platforms in order to have a chance to be accepted by the team (S. Northover reminds me as a very strict father watching very closely over the fate of his prodigal sun…). To avoid have to build n different implementations, I decided to explore the possibility of building a portable GC implementation based on Cairo. So a couple weeks ago I started chipping away at the Linux GC implementation.

The first thing I built was a new version of the AlphaComposition, this time taking advantage of Cairo, rather than using Quartz directly. I also quickly added support for radial gradients (the current SWT Pattern implementation only support linear gradients), as this early screen capture shows.

The GC is implemented in two parts: the portable GC itself which contains code that relies only on Cairo, and a driver that bridges with the platform for code that cannot be portable (for example, the instantiation of a Cairo surface, or the translation of the clipping area from Cairo to platform coordinates). As I work on a Mac Book Pro, the first of these drivers is for Mac OS.

At this point, I am able to run most of the GraphicsExample application (I will replace this Windows screenshot with an equivalent Cairo/Mac OS version). I still have some bugs in the region handling code and clipping (Path and Region) is not working. Working on the source code, I was wondering about performance: considering that there might be less JNI calls involved in performing some actions (one Cairo call being implemented by multiple Quartz calls), I am curious to see if that translates in an actually faster GC than the current Carbon based one.
Read the following article for more information on Porter-Duff compositing.

Supporting sheets in SWT on Mac OS

July 13, 2008 – 1:50 am

There are a number of ui widgets that make Mac OS distinct from all other platforms. One of them is the presence of sheets. Sheets are basically document modal dialog windows. As such, they are attached to the document window that prompted their appearance, thereby simplifying the task of keeping track of which dialog is linked to which window. Talking to Steve Northover, I got the sense that any form of modal (window or application) dialogs are actually frowned upon in the Eclipse team, their rational being that it is difficult to keep track of each of them as they appear, and more importantly that modal dialogs prevent users from looking at the document information.

Regardless of what the opinion of the SWT about modal dialogs in Eclipse itself, they made a decision years ago to build a UI toolkit that would be based on the native resources of each of the platforms it would be made available for. I think personal opinion that this should also include the ability for users to have a certain amount of choice in how their application will look. Although not as critical for the success of Eclipse itself, I think this is crucial for the success of RCP and SWT as independant development platforms. So despite the SWT team, I started to see what I could do about sheets.


In basically two hours, mostly spend scouting the excellent Apple documentation, I was able to display the page formatting dialog as a sheet.
And within 15 minutes the print dialog was also working.
Then came the message dialog…
… and the file dialog.
Bug# 233608 is where I kept track of the source code involved in providing this enhancement to SWT as well as the “deaf dialog” (as in the saying there is no worse deaf than someone who does not want to hear) I was having with Steve Northover about the whole thing.

Better looking SWT apps on Mac OS

July 12, 2008 – 4:04 am

Since I started my own work to improve the look of Java SWT apps on Mac OS, I found two other similar on-going efforts.

The first one is aimed at Swing, and creates a unified toolbar lookalike to embed in standard JFrame instances. The code is pretty simple and clever, and more importantly does the job. Unfortunately, because it is a lookalike, there is no support for the sheet based configuration screen yet.

The second effort is from Mike Schrag who, having found my name floating around in the SWT newgroups and bugzilla, recently send me an email pointing to his blog for more details. So far he has focussed his attention on improving the look of the SWT Coolbar (the vertical separator is no longer this ugly fake raised line), the Sash which he made wider and with a nice looking grip (personally I prefer my version where the sash is down to a single pixel like in most recent Apple applications), and the CTabFolder which he tremendously improved by giving the tabs a totally unique look (I am working on a replacement for the CTabFolder where the look will be similar to the flat gradient painted look of Coda and many other modern Mac OS apps). This is their version of a modern looking tab row

The following is the code status bar, which basically follows the current ui guidelines for a custom status bar (the alternative is to use a native bar which does to the bottom of a window frame what the unified toolbar does to the top). But more on that later…

Making SWT look more native on Mac OS

July 11, 2008 – 3:59 pm

Back in april, someone asked me if I had some thoughts about how to make an SWT app look and feel more like a real Mac OS application. Having only a couple days to think about it and the excellent Coda as a visual reference, I decided to create a silly file manager type application that would incorporate a unified toolbar, instead of the traditional ToolBar or CoolBar. The result was this rather silly looking contraption:

At that point, I could create a unified toolbar, populate it with the right contents, and even configure it using the default configuration mechanism. As I wasn’t sure where I was going when I started and with only three days to do something, I figured this would be a great opportunity to learn JNA, rather than start modifying the JNI layer of SWT. As is visible on the left side of the toolbar, I quickly found out how difficult it was to support segmented views the HIToolbar. I guess part of my problem was also that I have not written Apple code since the days of my Apple II.

After I gave the example to who had asked me, I started wondering about eclipse itself and the amount of work involved in transferring this little test to SWT, then to the Workspace. Within a couple days JNA was gone, and the same exact app was running on a modified 3.4M4 Carbon version. It was actually a lot easier than I had anticipated, a lot more than to try to convince the SWT team that this type of effort for the Mac and other platforms was actually worthwhile considering the leaps and bounds Swing made since they had started SWT. SWT is at close to (if not actually older) 10 years old… which in technology years makes it a dinosaur.

Once the code transfered to SWT, it was only a few more hours till I could do the same inside Eclipse.

As fate would have it, a couple days later I stumbled into a post on the SWT newsgroup made by someone asking the SWT team about their intentions in regards to supporting the Mac OS unified toolbar. I joined-in and asked their thoughts about moving parts of the classic Eclipse coolbar to the unified toolbar. The idea didn’t fly very far, and I was basically offered a lecture on the Apple ui guidelines, and how unfitting it basically was. Heaving read the document myself, I thought that the perspective switcher was actually a great candidate for relocation to the unified toolbar, while the rest would remain in a traditional toolbar (not unlike the division of labor in iWorks 08).

Up until then I was more preoccupied with how to wedge things in, rather than how to really make them fit meaningfully or properly. Having found out that it would not be too difficult to get something done, it was time to do the right thing (or at least something closer to it).

As a next step, I looked into wrapping this code inside an installable presentation that would also allow Mac users to move the switcher up the unified toolbar. Even though they offer a powerful way to configure Eclipse, custom presentation are not as flexible as one would expect. Some of the most fundamental characteristics of the Eclipse look are carved deeply in stone. In bug 229840 I started to track some changes to loosen things up via some enhancements to the current presentation definition.

Basically this is what some of the current workbench code looks like:

	private static int TILE_SPACING = 2;
	private static int LINE_SPACING = 2;
...
	totalMinor += (lines.size() + 1) * LINE_SPACING;

Not really a model of flexibility…

This is how I left things. SWT has two extra widgets MToolbar and MToolbarItem. These hide the details of supporting a the Mac OS unified toolbar in an SWT application. I also managed to get the segmented view code working and was able to display the traditional previous|next capsule style buttons. Buttons can have text and images, and the images can be custom org.eclipse.swt.Image instances or any of the OS provided default ones (via some constants I defined is OS.class). In order to get to the next, I’ll have to create a new toolbar and a new status control that will provide better control over its looks on all platforms. I have a name for it: Flatbar.

Cocoa SWT

July 9, 2008 – 12:08 pm

As I made the switch to a Mac, it quickly became a apparent that there was going to be trouble in my new paradise when word started to leak out that Apple was going to retire Carbon as part of its move to 64bits.

So back last summer I started playing around with Cocoa and quickly managed to play with simple shells. Through the process it became clear that it was not so much hard as it was a tedious task. At the time, I started building my own Cocoa port project, based on the source Cocoa code embedded within the Carbon port. I posted something in the SWT mailing-list where I reported my findings as well as asked a couple questions about the general philosophy a ‘proper’ Cocoa port should follow in order to be approved. Little did I know that this first first post was going to be the first of a series of increasingly frustrating interactions with the SWT team [more on that later].

At the time, one of the questions I was asking was wether or not to follow in the footstep of Apple and basically replicate the core of their Java Cocoa bridge that other people could later use to bind additional Cocoa libraries to Java. My own experimentation was around the idea of something somewhat dynamic, whereby reflection and caching would be used to compose NSObject descendants based on the object descriptors defined in Bridge Support (used by Camel Bones Ruby Cocoa). Starting from these descriptors, a significant portion (if not all) of the low level code would be generated, thereby greatly simplifying the code maintenance (apple is committed to maintaining Bridge Work). This is basically how Ruby Cocoa works: it is capable to dynamically load a new descriptor and make the matching object available. Looking at the current SWT Cocoa code, it looks like the code all manually written.

Mac OS Java

July 9, 2008 – 6:15 am

Apple and Java are an interesting story…

A few weeks ago I got in touch with some of the people from the Apple Java Runtime team. There are all very talented and very nice people.. The only problem? there is only a handful of them… Considering the scale of their task, to adapt Sun’s Java runtime and SDK source code to a new platform, I was really shocked to find out that there is less than a dozen people. Compare that with the hundreds working at Sun (the number was given to me by a friend working for Sun as lead for one of the java.xxxx APIs). In retrospect, this small number is very coherent with how little Apple cares about Java. I still recall an interesting discussion with someone high in the development tools hierarchy at Apple who explained to me, his personal opinion mind you, how Java is threatened by irrelevance within the next 5 years.

How do you answer to something like that.. ‘duh.. where’s your brain?!’ .. ‘hello, anyone home? when’s the last time you looked outside the window of your little world?’ … instead, I just pointed out how Java has been an unprecedented success in the history of programming languages, managing to dethrone C/C++ in less time than it took either of them to even just get a stable specification, and managing to become the most likely replacement for Cobol. Then he said “that’s what I mean by irrelevant”. Then it downed on me that we were not talking about the same things at all. From his golden bubble in the silicone valley, irrelevance is simply a synonymous for un-cool, web 1.0… so all he really probably meant was despite being the most taught and maybe even used language, Java is very web 1.0, while our Objective-C which is almost as old, if not actually older, than Java, while still having less users than php or python gained in the same amount of time, is totally web 2.0… what do they call it? the millennial generation. I decided not to remind him that until they re-implement WebObjects(now that’s one very relevant technology, isn’t it) in Objective-C, Apple itself will be entirely dependent on a “soon to be irrelevant” technology for their very own survival. minor detail.

But now I do understand why Java 1.6 took so long to show up on Tiger, and even when it did, why there was so many problems with it. In retrospect, I find it almost miraculous that Apple is able to deliver a complete Java SDK, and a very decent at that, with such a small team. My biggest problem with 1.6 on Tiger was when Microsoft Office 2004 stopped working. Within a couple days I had done an update of iTunes and Tiger, and installed the latest development preview of 1.6 for Tiger. Realizing that Microsoft had announced a problem with Office, I fired the office updater only to find out… nothing. Launching any of the Office apps gave the same result. Within a couple days, my three Tiger machines were in the same state, and I had my answer as to what was going on: somehow the Java preview had disabled Rosetta… pretty difficult to miss that elephant staring at out in the narrow corridor..

Pretty ironic as I recall a comment from Bertrand Serlet about how at Apple’s systems were designed by focussing on getting the best hashing algorithms everywhere, to which I replied something to the effect that it was not always the case that it was enough to assemble the best individual components together to build the best products, and that great care should be taken to understand the nature and effects of the system’s interactions before making some decisions to optimize certain parts, prompting him to concede that a GetLastError() scheme was not necessarily the “obviously wrong design pattern” that he made it to be. I should know something about that myself.. having worked on a network stack where all the layers make the exact best decision that is possible to make for that particular layer.. and having watched the system give up transmitting network packets exactly at the time when it should start doing it: having no means to know about the other layers making similar perfect decisions, the system sometimes reaches a perfect phase inversion situation where it stops when the LOS radios are in range.

Switching to a Mac

July 8, 2008 – 9:36 am

A couple years ago, and after many years being a faithful Windows and Linux user, I finally made the switch to a Mac. A friend of mine working for the Clusters Sun been telling me how convenient it was for him to use a Mac for all his work even compared to Linux (13 years ago I was trying to convince him that Linux was more than a toy, but like many die-hard BSD fans, he never thought so).

First I got a Mac mini… a quick and painless way to start with a very minimum financial commitment. As most of my work still had to do with Linux, I quickly became addicted to parallels. Within a few month, I got tired of wheeling around my ‘laptop’ (one of those Alienware/Sager/Clevo monsters with housing an overheating 3.4Ghz prescott p4), and bought a MacBook. There were talks that the Pro was soon to be updated, so the thought was that as soon as it became available, I would give the mini to my daughter (only a few months old at the time, but already showing some interest for keyboards and winnie the pooh), and the MacBook to my wife, while I would move up to a MacBook Pro.

At the time, all my programing was in Java/C/C++/Perl/Shell, so Eclipse was a no brainer. It became quickly apparent that despite being a very convenient OS, Tiger was not without its own share of annoyances. Chief among them was the frailty of Mail.app and its incredible lack of maturity for an application that has been around in some way shape or form for the better part of 10 years (back to the Next days). Once past the excitement of the first hour, smart mailboxes are actually quite limited, and the team probably delegated the design of the mail tagging feature to a toddler: ‘now its marked, now its not’ (abysmally stupid if you ask me).

And then there was Java…