Objology

There's been a flurry of work on the CairoGraphics package found in the Open Repository of late. A bunch of small stuff and fixes. And then there's one truly new feature.

We've added (need to stop to give credit here, Michael Lucas-Smith started this effort, he had the idea to try it, and did a lot of the ground work, so thanks go to him) the ability to use Cairo to draw on VisualWorks Image objects.

This is kind of cool. Historically to "draw" on a VisualWorks Image object, you had to convert it to a Pixmap, which allows one to instantiate a GraphicsContext to draw with, and then finally convert back. Now you can draw directly on the bits of the Image.

There are some pretty severe caveats though. Like other VW objects, you use the newCairoContextWhile: message to draw with it. Unless two conditions are met though, it will raise an error.

The first is pretty easy. The bits have to be allocated as a FixedSpace object. There is a useFixedSpaceBits method added to Image which you can use to move its bits into FixedSpace. This can be done on just about any image without negative side affects.

The second is that the palette has to be such that the bits of the Image are in a format that Cairo is happy with. There is a message which provides the transformation, becomeCairoCompatible (which should possibly be better named). This uses the convertToPalette:... message to create a new copy of the image, and then become:'s with the copy. So your image changes in place.

As it currently stands, you should send these two messages to an Image before using the newCairoContextWhile: message. I'm of two minds on this. The one is that these preparatory conversions should be explicit. On the sly, warping side affects, shouldn't happen out the open to surprise the programmer at a later point. The flip position, is that it's a pain to have to do this all the time, and it'd just be easier to have the newCairoContextWhile: automatically promote the Image to work with Cairo.

I'm curious what others think. Should an Image that is hit with Cairo methods automatically be coerced to something that Cairo is happy with? Or should that action be left to the programmer?

Belated completion of my CairoSummit 2008 reports. I did finally succeed in getting stuff to compile. And then spent the remainder of the time beginning to replace the libpng dependencies in the OS X builds with with CoreGraphics services that provide the same. Not done yet, but getting close. It's been a fun "get your feet wet" project for working on Cairo.

The Friday I left, we were all apart, it was too bad, because I started seeing the Google Chrome stuff that day and would have liked to have interrogate some of the Mozilla engineers to see what their thoughts were. But I digress...

All and all, it was a really fun experience. And I was greatful to have met a number of the key developers in the community. It adds a whole new element, as I watch traffic go by in the irc list. Thanks again to all the attendees, and especially Mozilla for hosting it.

Day two of the Cairo gathering, was spent mostly coding. There was some talk in the morning about Color Management. A basic overview of how Apple does it. Some thoughts on what services Cairo might or should provide.

After that, people split into different groups. One group was off figuring out how to reduce the number of pattern sources are built for PDF generation, when the same pattern is used multiple times. Another spent some time looking at automated build/test stuff. Mozilla has a rack of Mac Minis that they'll be setting up automated builds on. I spent time with a group who is trying to figure out how to make the Windows and OSX builds more approachable. We made some good progress in Windows, and it's still on going. Much thanks to Behdad, master maintainer of the automake/autoconf setup, for fixing some of the more difficult parts. And then I fought the OSX build. I'm almost there. Almost.

One of the things we talked about a little yesterday, was mesh gradients. You can learn about them in all their glory by reading around page 253 in the PDF Spec, culminating with the grand king daddy of them all, the Tensor-Product Patch Mesh (page 276-ish). Once you can do the type 7 gradient, you can do all the rest. So implementing this is seen as a long term good thing, because we can support more PDF features AND it gives you a way of doing all the other more limited types of gradients (such as path gradients provided by GDI+ or Conical gradients which are handy for quick and dirty shading).

What I did NOT know was that there are people out there that go to inane lengths to draw hyper realistic things with mesh gradients. Take a look at this picture. That's not a bit mapped picture originally. It's rasterized from a vector graphic, using mesh gradients. You can see where they put some of the mesh lines in the lower right corner.

The first day here at Cairo Summit was primarily vocal activity. Introductions, getting to know each other, and talking about a number of Cairo related topics. Most of these are covered in tedium in the notes taken. One of the interesting topics yesterday was the hardware acceleration. Supposedly, there's the beginnings of a DirectX backend running around somewhere in the halls of Mozilla. There was discussion at length of the pros and cons around doing an OpenGL backend. Today, we kick off actually coding. I'll be working with Antoine and Fred to try and improve the build situation for Windows and OSX.

While many of the Smalltalk faithful are gathering in Amsterdam at ESUG this week, I'm at the Mozilla office in Mountain View California, attending Cairo Summit 2008.

It's a small group, more like a Camp Smalltalk, but for Cairo. A chance for people who meet each other in mailing lists and IRC to meet face to face and communicate at a rate much higher than normal. I'm sitting in the introductions and "what do we want to talk about" right now, and it's always amazing how much more stuff you can get done face to face.

Big thanks to Mozilla for hosting this. They have one very cool office space. Very open and relaxed. If you're in a cube farm... you have no idea just how different it could be.

Stay tuned.

This is just too cool. Georg Heeg is talking about the application written to determine where Johan Sebastian Bach lived. Apparently, since great fame came to Bach posthumously, the real location of where he lived was lost to history. Amazing what we know about this man, and how the world benefited from his musical creativity, and we don't know where he lived.

Heeg got the contract to build an app which used criminal forensic technologies to gather a huge amount of data, build a semantic network, and figure out which house he lived in.They used VisualWorks, they used Seaside, they wrote their own semantic network analyzation stuff, they used Gemstone/S to store a huge amount of gathered data (basically anything written about the man, much of it in gothic script in old handwriting). The whole thing tells like an engaging Discovery Channel mystery.

Georg documents not only the technology they used, but how the whole story unraveled. And the addresses he lived at (turns out there was more than one). The story tells with how some theories were debunked, as well as the discovery that the city tax collector (long since dead) had defrauded the city for a number of years.

After lunch, I attended Vassili Bykov's "Interfaces without Tools" presentation. This is a presentation of some of the UI aspects Vassili has been exploring while at Cadence, building tools for Newspeak. Up front... it was really really really cool. If you've not read Vassili's paper on UI composition, you really should. It's a well done piece of work, both in describing where we are today with UIs, as well as some of the solutions he's worked on to close the gap.

Vassili's work underscores (imo) a long held observation about Smalltalk programs. It's been noted in the rise of the WebApp, that while under the hood Smalltalk programs are often technically really cool, their UIs don't look good. Web app or desktop app. What's cool about Vassili's work, is that it looks nice, so you don't have to extrapolate why some of these ideas are good. A random and trivial thing I learned while watching the presentation, in just a minute.

One of the key points of the presentation was that historically, people create "tools" which are statically defined and map to a window construct. And then you have to navigate these tools. And that they quickly become modal. Vassili's approach instead has been to build "interactive documents", and then have the one tool he uses simply be a document viewer/navigator. It's web browser like, but only in superficial ways.

He demoed the creation of a file browser/navigator, and used that process to demonstrate some of the tool aspects. Things like no modality, you can be editing multiple methods at the same time. Nifty custom widgets that make this work (instead of the stock set of buttons and lists). Ability to go back in history and not lose edits. Very cool stuff. He also did a demo, where he remove:'d the window from the Squeak environment and add:'d it to the Windows desktop, and suddenly it showed up as a Windows window, with windows widgets.

And now that random realization. I like gradients. It's one of the things I see as just as essential to get added to the VisualWorks environment as alpha blended icons. A light bulb went off for me regarding gradients while I watched this. From a graphics design point of view, what makes gradients appealing is that they can appear to be one color, but through subtle shading, also define the border of the region, without having to put lines, or beveled boxes around rectangles. Vassili's UI used gradients in a number of places to do this, and it worked very nicely.

The "Keynote" this morning was provided by Gilad Bracha. Gilad's leading the Newspeak effort at Cadence. This talk was similar, but not exactly the same, as the one given at Potsdam and video taped a while back. Niall Ross was busy bashing out minute by minute notes on the talk, I'll leave that report to him. I'll just highlight a couple of the high level thoughts shared and my thoughts about them.

Nested Classes

This is perhaps my most favorite part of Newspeak. Newspeak allows a class to be declared in the scope of another class. It has no distinct namespace model, or perhaps better said, Classes (Behaviors) are Namespaces. I've been enamored with this concept since I observed Smalltalk/X doing this many years ago. Beta did it. I've felt for a number of years, that the VisualWorks namespace model would be better served by doing something simple like this. The devils always been in the details, and I admit to truly never thinking out all the edge cases. But seeing yet another language inventor embrace this model, gives me strengthened faith that it would be the right way to do namespaces. It builds the language semantics from fewer reusable blocks, and I think that's a good thing.

Aliens

One of the new things I hadn't heard about yet in the Newspeak world, was how they do foreign function interfacing. I hope to see more of this later this afternoon with Vassili. But what I understand is that you treat things like DLLs as Alien objects, and the claim is, you do much less "special syntax" to interface with them. More later on this maybe.

Mirrors

All reflection in Newspeak is done via Mirror objects. By separating them into separable objects, you can control the degree of reflection you want to support. You might just provide a mirror that can tell you things about your objects. Or it might be the full blown thing we are used to in Smalltalk that lets you find out how things are composed, as well as change them. I find this kind of appealing. Even primitives are done with a mirror like thing. You get a mirror for the VM. Making it pluggable like this means you can have more or less "primitive" support for your language execution.

Security

This is where I wonder if Newspeak won't stumble. I'm not predicting it will. I'm wondering. Gilad made the point that historically Smalltalk came from a sort of "It's a Small World" environment where the impetus was exploration and learning, no boundaries. But that in the real world, there are people who write malware and spambots and that kind of thing. So being able to support security seems a strong undercurrent of Newspeak design. For example, class extensions (or "Monkey Patching" as Gilad has called it) are discouraged. Skepticism on my part is not based on any technical grounds, but at a higher philosophical level (I think this is appropriate with Smalltalk-ish systems, because they allow us to anthropomorphize so easily). I note that the world I live in is very imprecise. And it's very insecure. I have lots of weak security around me (I have locks on my doors and car, but I often don't use them). My bank is pretty secure, but it's added on. In the end, I keep the real world security around me to a bare minimum, because it makes life easiest and most pleasant. Can one hope that if we put too much security in a our programming expressions, that we won't find them tedious and onerous to deal with. Just random musings.

This morning, there were two talks, one by Paul Bauman and one by Tom Hawker, both presenting the types of tools people with large and complex VisualWorks + Gemstone applications have built and the experiences they've had. What impressed me was how truly large these systems are. And how small teams build them.

One point that stuck out to me from Tom Hawker's talk was the statement "ENVY got it right and Store didn't." To give that statement some context, Tom had been talking about prerequisite specification betwixt different code modules (whether you call them apps, subapps, packages, bundles, buckages, whatever). If I understood correctly, they were dissapointed when they converted from ENVY that no one specified these correctly.

In the context of maintaining code module integrity, I would add a qualified agreement. ENVY constantly nagged you, telling you what you needed to change to keep your prerequisites correct. In fact, ENVY went so far as to never let you make a change that would render the prereq tree invalid. You had to make the prereq change before you could make the change. Which sometimes created circular problems (anyone who tried to move ValueModel out of the UI Applications experienced this). This is where I think ENVY went to far and got it wrong. It never allowed module integrity to even be temporarily invalid. Store went the other direction. Threw the baby out with the bath water so to speak. A sort of "since it's nice to put module prereqs in an invariant state temporarily for some changes, let's do very little (almost nothing) to ever help maintain it."