Just another WordPress.com weblog

Archive for March, 2012

Athens: a first babysteps

The Athens is a secret military project, with aim to conquer the world..

At first stage our task is to create a modern object-oriented vector graphics framework (codename: Athens) for smalltalk, and then.. yes! conquer the world.

Today, Pharo lacks a decent and modern graphics framework. A heritage, what comes from Squeak (and it goes back to smalltalk’80) is a today’s classic bitblt framework, which allows one to manipulate with bits and blit them in twisted ways. Squeak VM, in addition, having a balloon engine on top of it, which is kind-of vector-based add-on to bitblt engine, but it is also quite outdated and lacks many features comparing to any modern vector graphics frameworks.

Needless to say, that there are big demand for such a framework in our community, because it opens doors to magical world of graphics. I wouldn’t say that it is not open at all, i would say that it doesn’t widely open.. by now, only smartest can sneak through the narrow passage but any inexperienced explorer will be blocked, not saying about larger parties of fun-hunters.

Over past years, there was a multiple attempts (including me) to get a bit closer to the holy grail, but without focus and big investments of time, there is a little chance for something decent to appear. So, one of my tasks, as a Pharo engineer (a job position, i currently have at INRIA, Lille), is to design and implement such framework.

So, little words about what was existed before (or at least i know of):

Rome is a framework which supposed to have multiple backends, but primarily Cairo graphics library , via plugin which provides a binding to it. Currently dormant.

OpenVG in same way, is a binding, which i wrote for an emerging open standard – OpenVG. Dormant as whell 🙂

Apart of it stays an OpenGL framework, but i am not listing it there, because it is more 3D graphics oriented rather than 2D vector graphics. And while you can use OpenGL as backend for rendering 2D vector graphics, it will still require a lot of work , to build something on top of it.

You may rightfully ask , why do we need yet another project which providing merely the same, when we already having two? Isn’t it a waste, instead of putting more effort into one of those, to do everything from scratch?

Of course, Athens is about same thing (vector graphics), but quite different in one significant aspect: it is object-oriented.

The main problem about the above two projects that they are constructed using bottom-up design, serving primarily to expose features in corresponding APIs to smalltalk. They are almost 1:1 replicating the structure of API’s they rely on, with a little thought, how to make a smalltalk side to be more object-oriented instead of being thin wrappers around those libraries.

In other words, give me 1 week, a lump sum of money, and after 2 weeks 😉 i will deliver you a binding to any C library you want. But do not expect that it will be much easier to use it, only because you can access it in smalltalk. This is because exposing a non-object oriented library in smalltalk does not automagically makes it by a bit more object oriented, especially in terms of smalltalk, not in terms of C++ 🙂 .

So, my primary focus in Athens was (well, and still is ) to use top-down oriented design and think more about how to make sure that API is convenient and easy to use, rather than how it would be easy to expose certain features in existing non-object-oriented APIs.

Of course, i have to keep an eye how to make sure that things will be running efficiently, using different backends, but even more i care about framework API and it ease of use.

A top-level API in Athens is self-sufficient. My aim is to make sure that developer don’t needs to know intimate details about how Cairo/OpenVG/OpenGL (or any other backend) works nor needs to study their API in order to start using Athens. Instead all he will need to know is Athens API.

We want to make one thing real: an application, which uses Athens , should work same, no matter what rendering backend you using.

Yes, i know, that such approach leads to a problem of minimum common denominator , but i think that clean design outweighs it , because nobody expects from me to deliver full-blown and feature rich framework from a first iteration, which is then will be “carved in stone” for decades. I think that good foundation will pay off.

Ok. I think it is enough blabbering for today.. i will continue my novel later, in future posts. 🙂

P.S. oh.. btw.. to all ‘take a look’ and ‘have a look’-ers. I taking a look and having a look over many things and i am very interested in what exists on a landscape of modern graphics world. Just take note: this post is about ‘take a look on Athens’, not about ‘lets speculate about the topic’.

Advertisements

Smalltalk as embedded language: Problems

One of the major smalltalk shortages, which often mentioned by people, is lack of good interoperability with operating system and external libraries.

I know that originally, smalltalk were designed as an fully functional environment for personal computers, with very little (if any) need for low-level support of what we calling today as “Operating System” or basically “environment”. A modern examples, like SqueakNOS demonstrating very clearly, that smalltalk image can run without any OS, and still be quite functional and even useful.

But here, i do not want to analyze why or what prevented to push smalltalk environment into masses (if it it would be successful, there will be no need to talk about any interoperability with non-smalltalk world at first place), what i want to say is that it is a mistake today to keep trying to stick with paradigm where things happen only inside smalltalk environment, and nothing exists beyond it.

If smalltalk environment runs inside another environment (such as an OS), it is a mistake to not have decent interoperability with it.

So, what we have today? Both, Squeak and Cog VMs, is more or less same in this regard now (sure Cog is more advanced ;).

We have an FFI. Okay, maybe it is not as good or complete as analogous implementations in other similar languages, but in my opinion it is quite decent and we’re not standing here. So, on this front, i think, we are doing fine.

But FFI is just one side of medal: it allows an application(s) written in smalltalk to speak with external libraries, effectively supporting model where smalltalk environment is a host , while external modules is servants (i.e. embedded).

But if we turn our medal upside down, we can see that we’re absolutely missing (literally nothing), to support running smalltalk as embedded language in host application. And i see very little movement (and attention) towards changing the situation in this regard.

Personally, i think that smalltalk as embedded language could be best what i would dream of.

So, if we would like to do it, where we should start from?

First is VM , of course. We should turn VM from being self-sustaining and all-knowing OS-level process into a library, so then a host applications may link either statically or dynamically with it.

Second, we need an API, allowing host application to communicate with VM and be able to control execution of smalltalk code, as well as control the object memory and available VM capabilities.

There are many things, which hardcoded in VM, assuming that it is running as a standalone process in OS. For example a FilePlugin, a plugin which operating with files, but despite it has “plugin” name, is not optional. In cases when a host application using smalltalk as embedded language, it is easy to imagine that in many situations a smalltalk part may not require direct manipulation with files at all, since host application can take care about providing data to smalltalk side by using own, often more efficient, ways.

So we should make sure that VM does not assumes that it runs as a full-fledged environment, because when embedded, it is totally not VM’s cocern, but up to host application.

All of the listed above is relatively easy to fix, because it more or less about the same: we should make VM code more modular, and ensure that VM can be used as a library with well-defined API (like Lua does).

There’s only one thing, which makes me worry and solution might be quite tricky: scheduling. Again, since smalltalk envisioned as self-sustaining environment, it has to deal (by itself) with multiple processes to be able to run many things in parallel, and therefore VM has to support scheduling.

But again, this is not absolutely necessary when smalltalk used as embedded language. I shown that scheduling can be moved completely into language side, so VM will know very little about things like Process, Semaphore. It will still know about things like signals and contexts.. but much less. So this step, i think, is necessary, if we would like to get to the point where we can use smalltalk as embedded language.

For example, imagine that host application sent a message (through VM API, of course) and waiting for answer.. but because of scheduling, the context which evaluating given message can be interrupted and switched to another one and then even killed/lost etc , resulting the situation, where host application could never gain control back.

With VM scheduling it makes very difficult to have a simple call scheme, where host application “calls” VM, then after running some piece of smalltalk code VM returns result(s) and completely stops any activities upon next call. And even interpreter is implemented as infinite loop, once entered, never leaved.

Another aspect of same problem is that we don’t have a good abstraction around VM and interpreter state. If i would want to use multiple different interpreters with different object memory , running in parallel , i cannot do that. Because current VMs are too centered around idea that they controlling everything, and nothing happens outside. I demonstrated with HydraVM, that it is relatively easy to make VM to be able to maintain multiple interpreter states and run two (or more) object memories. But the idea needs further development and more attention.

I am not mentioning a language-side changes, because obviously, when we speaking about embedding, it will mean that in most cases we will run quite specialized image(s), far , far less feature-blown comparing to images what we use today.  Yes we need decent tools support for generating such small images by either bootstrapping them or shrinking existing images, but for me VM is more important and more harder part of the story.

I’d like to know, what other thinking about it. Do you think we need to be able to use smalltalk as embedded language at all? Or we can live with just FFI?

Building Freetype plugin on windows

Since i had to install everything from scratch on new Win7 running under Virtual Box, and prepare the environment for building Cog VMs, i had to iterate over all steps.

I hate setting up things from scratch, because there’s always something which can go wrong, and you mostly losing time, trying to make things working. And those things are not directly related to your current task (debugging VM), it just a tools, which need to be there before you can even build VM.

I really happy that Mariano wrote down all instructions about preparing environment, so i can just go and do things step by step.

Now it doesn’t means that things which were working year ago will keep working. In my case i stumbled upon strange compiler errors , when i first tried to compile VM:

c:/MinGW/msys/1.0/home/sig/cog/blessed/platforms/win32/vm/sqWin32Intel.c:
In function 'squeakExceptionHandler':
c:/MinGW/msys/1.0/home/sig/cog/blessed/platforms/win32/vm/sqWin32Intel.c:128:18:
error: '_RC_NEAR' undeclared (first use in this function)
c:/MinGW/msys/1.0/home/sig/cog/blessed/platforms/win32/vm/sqWin32Intel.c:128:18:
note: each undeclared identifier is reported only once for each
function it appears in
c:/MinGW/msys/1.0/home/sig/cog/blessed/platforms/win32/vm/sqWin32Intel.c:128:18:
error: '_PC_53' undeclared (first use in this function)
c:/MinGW/msys/1.0/home/sig/cog/blessed/platforms/win32/vm/sqWin32Intel.c:128:18:
error: '_EM_INVALID' undeclared (first use in this function)

Searching web, i found that this is discrepancy introduced with new GCC compiler.

All you need to do is to add:

#ifndef _MINGW_FLOAT_H_
 #include_next <float.h>
 #endif

in C:\MinGW\lib\gcc\mingw32\4.6.1\include\float.h

(yeah, literally copy and paste at the end of that file)

Now i were able to build VM. But since i built it without freetype plugin first, i did not yet met another problem:

a freetype makefiles using autoconf, and before you will try to build a library, you need to install it. Now of course, you should know how to install things in mingw environment. And since i’m not using it daily, its easy to forget how to do it.

So finally, here the single line which was a reason provoked me to write this post:

mingw-get install automake

… But not so fast, says automake.. here’s another line:

mingw-get install libtool

and only after that i can finally see

[100%] Built target FT2Plugin

Congratulations!