Pointillist

What is it ? well, Pointillism is a style of painting I quite like, but Pointillist is simply the (working) name of a small graph library I'm working on. The previous post was discussing about the simulation software I wrote, which uses a simple graph view. I decided to clean up a bit that view, put it in a framework and commit it somewhere (likely on the étoilé repository). Not quite done yet, but it's shaping well, and it's now quite a bit more generic:

One of my "I will do it one day" project is a simple graph calculator... So in order to properly test the graph framework, I created a class using the StepTalk scripting framework to express functions (written in Smalltalk), which actually makes me rather close to have such a program :-P

for the curious, the code of the functions is:

Red function:

|y| 
y := -0.5. 
((x < 0.5) and: (x > -0.5)) ifTrue: [y := 1]. 
(x < -1) ifTrue: [ y := 0.25]. 
( x < -1.5) ifTrue: [ y := -2 ]. 
(x > 1.5) ifTrue: [ y := 2]. 
y := y + 1.5. 
^y

Green function:

x sin - 1 / x

Blue function:

|y mod| 
y := -1. 
mod := x mod: 2. 
(mod = 0) ifTrue: [ y := 1 ]. 
y := y - 2. 
^ y

StepTalk is really cool btw -- Easy to integrate, and works both on OSX and GNUstep. Here is the code I use here:

id environment = [STEnvironment environmentWithDefaultDescription];
id conversation = [STConversation conversationWithEnvironment: environment
      language: @"Smalltalk"];

(...)

id number = [NSNumber numberWithFloat: x];
[environment setObject: number forName: @"x"];
[conversation interpretScript: @"^ (x tan) / (x atan)"];
id result = [conversation result];

[values addObject: result];

values beeing a NSMutableArray containing the numbers returned by the steptalk function (the ^ in smalltalk is equivalent to a "return" statement in C). As you can see, difficult to have a scripting framework simpler than that to work with!

You can see that in the environment object I put an "external" (to the script) object, number, and this object can be accessed from the script using the given name (here, x). You could, instead of getting the script result, get the value of specific objects you put in the environment.

Anyway, it's very simple to add StepTalk support to your program, and recent versions even add nifty UI widgets to play with scripts.. also, StepTalk is not "just" a Smalltalk scripting framework : it can actually use other languages. On GNUstep for instance there's an Io bundle, so you could use Io instead of Smalltalk, etc. (it's actually fairly easy to add languages to StepTalk).

Note also that StepTalk automatically bridge the numbers in the script to actual NSNumber instances... which is how I decided to implement the math functions, and this actually demonstrate a very cool Objective-C feature; NSNumber doesn't have thoses sin,cos,mod.. math functions; so in another programming language we'd be stuck. A "normal" solution could be to modify StepTalk so that it would use something else than NSNumber (say, a custom class of ours), or reversely, to add those functions to NSNumber and recompile -- wait! you could do that with GNUstep (because we have the source), but certainly not with Cocoa on OSX. So how comes it works ?

Well, Objective-C has this great feature: categories. A Category lets you add new code to an existing class, at runtime. So that's simply what I did here -- I created a category on NSNumber with my specific math functions. Without needing to have access to the NSNumber source, or to recompile Foundation. Isn't it great ?

System simulation

I'm (rather predictably) still working on my distributed rendering system.. but as it's a bit tiresome to make some modifications, recompile, restart.. -- more importantly, that it takes time to do so (1), I wrote a simple and nice simulation program that let me try different rendering/clustering strategies easily, swap them, evaluate or compare them, etc. That way I can concentrate on them rather than waiting 5-10 minutes to start visualizing a one gigabyte dataset on the cluster. Even better, the final idea is to integrate the simulation in the real system (it actually already gets timings from the real one and extrapolate the results) in order to have a nice feedback loop: run things, keep simulations in parallel, switch to other strategies if the simulation says it's better, update timings if needed, etc. Here is a screenshot of the current program:

The screenshot shows three simulated clustering strategies; basically we want to render an image using multiple computers. Each computer having one or more rendering agent. We divide the image in tiles and the rendering agents' job is to render them, send them back to the clustering agent, which will recompose the final image to send it back to a visualisation client. It's a fairly straightforward distributed technic. What's more interesting here is that we have three different strategies defining which tiles are sent to which agent. The simplest one is to divide the total number of tiles by the number of agents, and send continuous tiles up to that number for each agent (second bottom figure -- each color represents one agent). Another is to alternate tiles (eg no consecutive tiles are sent). Another one is to break the tiles according the the image complexity (first bottom left figure). The image complexity beeing the time each tile took to be renderered (bottom right figure).

The graphic shows the evolution of these three strategies depending on the number of agents. We can see that the alternate tiles strategy works fairly well usually (because the complexity is more evenly distributed), unless we ends on a multiple of the width (16), meaning the tiles are aligned, and thus the complexity is not properly distributed. Having a simulator can let us choose which strategy is the best before having to really use it.

(1) which break one of my Rules of Programming, ie, keep the REPL (Read-Eval-Print-Loop) cycle as short as possible: as obviously the shortest it is, the more ideas you can try.

e-book

I just read that article about the new Sony's e-book reader (from the osnews story). That made me think a bit about e-book.

I would love to have a "true" ebook. For what ? well, in my case, for reading technical documentation and research papers, possibly some websites. Another excellent usage would be to read newspapers and magazines, or research journals. Or if you are a student, another really obvious target are textbooks. And think about the manga/comics market.

Why would it be interesting to have an ebook for all that ? What's the pattern ? Simply, it's the volume: in all these use cases, you end up with lots of paper very easily (and in a short time frame), and having one device to gather everything would be nice.

But books ? books do not really have a volume problem -- most persons do not read or carry dozen of books at the same time, and the minor inconvenience to carry 2-3 books for a very long journey is not enough to warrant paying premium to have an ebook. Sure, if you have a device able to read pdf and newspapers, it can handles a book, so you'll have books too of course. Having your whole library in one device could be appealing to some too, I guess. But if the main advantage of an ebook reader is answering the "volume" problem, then it means books almost certainly shouldn't be the main target.

So if books aren't (or should not be) the real target, and if things like documentation, newspapers, textbooks are, what does it mean ? Well, it means your device should provide the same features you'd expect from paper when dealing with these. Specifically, you absolutely need annotation. But more than annotation, the device shouldn't be content to only be "as good as paper" -- if you want people to buy it, you need to be better. An obvious candidate feature (come on, we are talking about electronic documents) is to provide a much better way to manage your document collection. Things like searching, grouping, sorting, adding whatever annotation/metadata you want, do specific things that use these categories (like marking some documents, pages or text to be sent to somebody else via email, etc)...

Then, you will have something that people (and companies, and schools) might be interested in.

The screen technology is imho nearly irrelevant, as long as the battery life is good enough (~7-8 hours in continuous usage) and with a good enough resolution. While e-ink is extremely interesting and answers perfectly the battery/resolution problem, it's too slow for the moment (it's also black and white, not absolutely dramatic but something that reduce a bit its impact). Between an e-ink display and a high resolution lcd screen, even if the battery life would be much shorter on the device with the lcd screen, if it provides the kind of characteristics I described above, I will definitely choose it over the e-ink display, and I bet that many persons would do just the same.

Right now, the sony ebook looks more like a solution looking for a problem than anything else, and they focus their efforts on the wrong side (books).

They fail at everything I described above: it's slow to navigate, management of your documents seems inexistant, pdf aren't even there apparently (seriously!), no annotations... the only good thing (while not perfect) is the e-ink display, but they seem to think it's enough. It's not.

If I had money (and time) and more electronic skills I'd definitely want to create a good e-book device. Why not something based on gumstix + a high resolution lcd screen. There's a market waiting to be picked here.

edit: to be fair, checking the sony page they indicate that the device actually CAN read pdf and doc... But only after converting them to the proprietary format Sony uses. Crap ! :D (oh and it plays AAC and MP3 too)

Pfff...

I finally finished writing the last remaining things for my system, integrated everything, and could generate the data for the paper just in time... That was a hell of a week, but at least this deadline is over now ! I'll sleep a bit :-P

I will also try to resume a minimum my gnustep's activity next week (been more than a couple of months it's on hold) -- I have a couple of things to do that shouldn't take much time from me and that would be rather welcomed :-P

UDP ...

Well, I'm not working much on anything related to GNUstep/étoilé lately -- I have my thesis to write for december, which also means I need to finish properly my visualisation system soon...

I changed completely the communication stack -- exit XMLRPC/TCP, welcome lossy UDP communication -- good things, it enables broadcast and low latency, bad things... well, using broadcast as an asset, you need to change quite a lot the way you think your program. But it's worth it: not only the end result (the visualization) can be broadcasted, which is nice, but moreover, the rendering process itself can take advantage of broadcasting to be more efficient. Anyway. Here is a screenshot showing a broadcasted MIP visualization of the CThead dataset:

The rendering itself is done on a cluster connected to these 3 machines through a simple udp tunnel. Works quite well..

Flow, State and Persistence

I gave a talk today discussing state and persistence in your work environment, for the No Grownups Seminar Series.. Here is a flash version of the talk, and here is the pdf one. Have a look !