GNUstep participates in Google Summer of Code 2007

The GNUstep project just announced that it was accepted in the Google Summer of Code 2007 :

GNUstep provides a cross-platform solution for Objective-C/OpenStep/Cocoa developers. This year, it offers various projects for SoC, such as adding new classes from Mac OSX 10.4, enhancing text system, porting WebKit to GNUstep, improve GNUstep on MS Windows platform, etc. It is a great chance for students to learn programming in many aspects.



read more | digg story

It's an excellent news ! we tried to be accepted first two years ago if I remember, and last year we were in but under the GNU umbrella... and no projects were accepted. Beeing accepted as a separate organisation should help us, hopefully !

Beside, any progresses on GNUstep will be immediately useful for Étoilé :-)

If you are a student, it's definitely worth a look -- GNUstep is one of the best OO api available here, and a fun place to hack.

update: Squeak is also in ! :-) great news too...

Pink Floyd

Today I was in london for a job interview, and had a few hours to kill after it before going back to wales.. so I walked around a bit, and ended up reaching the Thames (duh! not surprising in london, is it ?). But I just ended up in front of the Battersea Power Station :

Of course, this power station is world famous because of Animals, the 1977 Pink Floyd album... ;-)

Sadly, I didn't have my camera with me, so the shots are from my mobile... here's some more:

ps: in the "cool for a geek dpt", I'm actually posting that from my laptop.. but through my 3G mobile cnx. With a cheap unlimited data plan, you basically get internet access everywhere -- as like here, in the train :D

Fun with Objective-C

Following a mail from david on étoilé dev about how it could be nice to try allocating ObjC objects on the stack, I played with a couple of things...

First I wrote a mini benchmark -- get a very basic object (a couple of ivars, one method "plop" assigning a value to an ivar), and then create an instance, initialize it (call the init method), call the one method the object has, then deallocate the object. 10000000 times. As far as micro benchark goes this one is pretty stupid but well, that'll give us some ideas of what's going on.

Without optimizations: ~4.10s (on a macbook pro 2.16Ghz, core duo)

Not that great -- doing the same thing in C++ with a similar object here is the timings I get:

Objects created on the stack: 0.24s (17 times faster !)
Objects created on the heap: 1.37s (3 times faster)

Ouch, the poor Objective-C... not a surprise when allocating objects on the stack, but even allocating them on the heap C++ is still 3 times faster.

One obvious reason is that Objective-C calls a lot of methods when creating an object; and a method call is more costly than a C++ function call. Still...

So the obvious idea here is to cache some method calls (ask their address then call the function directly -- as a C function). I restrained myself to alloc/init, the method the object had ("plop"), and the release method. Of course, there's other methods that are called by those, that won't be cached.

Caching method calls: 2.77s

It's still twice as slow as creating the C++ object on the heap, but it's anyway a nice performance increase.

Ok, then our only option left is to allocate the Objective-C object on the stack. Surprise:

ObjC objects created on the stack: 0.23s
ObjC objects created on the stack + cached imps: 0.13s

:-)

[note of course that it's a stupid micro-benchmark that doesn't prove much, but it's fun]


...


What ? how can you allocate objective-c objects on the stack ? ah well... you can:

#define STACKCLASS(class) typedef struct { @defs(class) } \
    __CLASS_ON_STACK__ ## class;


#define STACKOBJECTISA(objectName,className,classIsa) \
    __CLASS_ON_STACK__ ## className __INSTANCE_ON_STACK__ ## objectName; \
    __INSTANCE_ON_STACK__ ## objectName.isa = classIsa; \
    className* objectName = (className*)& __INSTANCE_ON_STACK__ ## objectName;


#define STACKOBJECT(objectName,className) \
    STACKOBJECTISA(objectName,className,[className class]);

Here is an example:

STACKCLASS(Test);

int i;
for (i=0; i< 10000000; i++)
{
  STACKOBJECT(test,Test);
  [test init];
  [test plop];
}

Basically, create the corresponding struct for the class and set the isa member (you can also cache the class isa to gain one message send). A bit of a hack, but that seem to work ok :)

Note of course that by doing that, you loose flexibility -- exit class clusters for instance (eg classes that actually returns another class instance, such as NSNumber), you can only work with concrete classes. And also, don't call directly -dealloc as it would try to deallocate the object, which is not needed as it was created on the stack (so if you need to do some cleanup you should do it in another method).

Here's the macros I used for imp caching (fairly straightforward):

#define CALLIMP(imp,object,sel,args...) \
    (*imp)(object, @selector(sel) , ##args)
#define GETIMP(class,sel) [class methodForSelector: @selector(sel)];

You use them like that:

IMP imp1 = GETIMP(Test,alloc);
id p = [Test new];
IMP imp2 = GETIMP(p,init);
IMP imp3 = GETIMP(p,plop);
IMP imp4 = GETIMP(p,release);
[p release];

int i;
for (i=0; i< 10000000; i++)
{
   id test = CALLIMP (imp1, c, alloc);
   CALLIMP (imp2, test, init);
   CALLIMP (imp4, test, plop);
   CALLIMP (imp3, test, release);
}

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)