Tag Archives: ESUG

“New” Tanker – current status

Both ESUG 2012 and GSoC have finished. At ESUG I gave a presentation about Fuel/Tanker (sorry, no slides because it was all demo). I also presented Tanker in the ESUG Awards….we got the 4th place, and only 8 points of difference with the 3er place 🙂   Anyway…I wanted to make public what exactly we finally managed to do with Tanker, a package exporter and importer that uses Fuel serializer. As I said in a previous post, we have changed a lot how Tanker works internally. In that post also I mentioned that Tanker didn’t support source code export/import, but in this new version, it does support methods source code, class comments, timestamps and everything that is currently being stored in the .changes or .sources file.

Exporting packages

The following figure shows how the export works. The input is a package of code (classes + extension methods), in this example “MyPackage”. The first step is to traverse the classes and methods of the package and do 2 things: a) write the source code (source of methods, class comments, timestamps, etc) to a text-based chunk format sources file (MyPackage.tankst); b) create “definition” objects. These objects represent a kind of object model that store all the necessary information of the code entities to be able to recreate them back  in another image. So we have for example, TAClass, TATrait, TAMethod, TABinding, TAAdditionalMethodState, TATraitAlias, TATraitComposition, etc…

Something key here is that besides all that information, we also store the relative position of the source code of the entity in the “MyPackage.tankst”. So for example, TAMethod instances will have a number representing that relative offset (similar to the pointer that CompiledMethods have in their trailer to .sources/.changes) where its source code is.

Another important detail is that in TAMethod we are storing the bytecodes, because even if we have the source code we want to avoid needing to compile during the import.

Once we have finished writing the sources file and creating the definitions, we just serialize them into a Fuel binary, say “MyPackage.tank”.

Importing packages

The following diagram shows how the import works. The input is the sources file (MyPackage.tankst) and the Fuel binary file (MyPackage.tank). The first step is basically to read the sources file and append all its contents in the .changes file (so that to get the same behavior as if we were installing a package with Monticello). But before doing that, we temporally store/keep the current “end” position of the .changes file 😉  (you already guessed why?).

The second step is to materialize the definitions using Fuel. Something very nice is that the definitions that were serialized, also understand the necessary messages to be installed in the system (#installUsing: aSourcesFile environment: anEnvironment). So we basically tell each class and each extension method to get installed in the system. Those objects will delegate to the rest of the definitions to complete their task (all definitions know what to do when installing them in the system).

Classes and traits will use the class builder to recreate themselves back. The source code was already installed in the .changes, so now we need to fix the “pointers” from our newly created classes/methods to point to the correct place of their source in the .changes file. And this is very easy because their position is just the “end” position of the .changes before installing our package (that value I told you we were temporally storing) + the relative position that was stored in the definition itself 🙂

So what is the biggest difference with Monticello for example? The key point is that we export bytecodes and we avoid having to compile during import. This make things faster while also being able to install packages without compiler (very useful for bootstrapping for example).

How to install it and use it

Tanker only works in Pharo 2.0 (because we rely on new class builder and layouts) so you first need to grab an image. Then, you can evaluate:

Gofer it
smalltalkhubUser: 'marianopeck' project: 'Tanker';
package: 'ConfigurationOfTanker';
(Smalltalk at: #ConfigurationOfTanker) perform: #loadDevelopment.
Yes, so far there isn’t a stable version yet, we are waiting for new class builder. Be careful because that will install the new class builder (and change the system to use it)  and it may have some bugs…so take care 🙂
The export and import look like:
aPackage := TAPackage behaviors: {MyClass. MySecondClass} extensionMethods: {String>>#myExtensionMethod1. Object>>#myExtensionMethod2}.
 package: aPackage
 binariesOn: aBinaryWriteStream
 sourcesOn: aTextSourcesWriteStream)

 binariesFrom: aBinaryReadStream
 sourcesFrom: aSourcesReadStream)

However, we do not expect the final user to provide all the list of classes and extension methods. Therefore, we have helper methods to export and import RPackages and PackageInfos. Example:

 TAExport exportRPackageNamed: 'MyProjectCore'.
 TAExport exportRPackageNamed: 'MyProjectTests'.

TAImport importPackageNamed: 'MyProjectCore'.
 TAImport importPackageNamed: 'MyProjectTests'.


So that was all for today. Probably, I will do another blog post where I will show how we can query Metacello to know which packages to export and in which order, some details about the new class builder, some benchmarks while exporting all seaside/pier/magritte (10 seconds to export and 20 to import), and so on. The conclusion we got with this project is that indeed Fuel can be successfully used in yet another completely different domain. If you want to help us, please test it with your own packages. Right now we have only one open issue (need to recompile if superclasses present in the image have reshaped). I guess that soon we will fix this last issue and release the first stable version. In the future we plan to analyze how can we really integrate Tanker with Monticello/Metacello.

ESUG 2012: when the time to pay for the beers has arrived!

Hi guys. In a blog post of last year, I said:

“What is really great is to meet people. Have you ever sent 1 million emails to someone without even knowing his face?. Is he 70 years old? 20 ? What language does he speak?  Well, ESUG is the perfect conference to meet people by real, face to face. The best part of ESUG happens in the “corridors”, I mean, talking with people between talks, after the conference, in the social event, etc. There will be people who will ask you about your stuff, they will give you feedback and ideas. You will find yourself wanting to give feedback to others. It is a nice circle.”

This year, we should have another motivation. How many times have you promised people to buy them a beer if they did XXX? How many times people have promised you a beer for doing YYY? What better place than Belgium to balance the accounts?

I have already done my homework. I own beers to: Alain Plantec and  Henrik Sperre Johansen.

Anyway guys, hope to see you there!

Tanker screencast and image ready for testing

Hi guys. Last days, we submitted Tanker to the ESUG Innovation Technology Awards. As part of that submission, I have created a screencast and an image with the examples.

The screencast gives you an introduction to Tanker and shows you how to export and import packages. I starts with a simple example, then it exports a real library and ends up exporting all Seaside, Magritte and Pier 🙂   Ahhh yes, sorry for my voice, I know it is ugly hahaha. You can also watch it here:

You can also get the image I used for the screencast, which you can try and experiment.

Have fun,

My (past) presentations at PharoConf and (future) talk at ESUG 2012

Hi. As usual, I wanted to share with you the slides of my last talks in case you are interested.


Last month I went to the first PharoConf held in Lille, France, and I gave to talks. One was about using the Fuel serializer for several different hacky things 🙂  You can find the slides here but since most of the presentation was a demo, they are almost useless. The videos of the conference are being processed and will be updated soon. I will update this post once they are finished.

The other talk I gave was about building the Pharo Virtual Machine and you can find the slides here. If you are interesting in the topic, you can see all the blog posts I have written about it.

ESUG 2012

Once again, I will be attending and presenting at ESUG (in Ghent, Belgium). This year I will present something similar to the Fuel talk at PharoConf. As you can see in the ESUG schedule, the abstract of my talk says:

Fuel is an open-source general-purpose object serialization framework developed in Pharo. It is fast, extensible and has an object-oriented design. It can serialize not only plain objects, but also closures, contexts, methods, classes, traits, among others.
This presentation will be mostly a demo with only a few slides. I will show the power of Fuel by using it in several scenarios: rebuilding Pharo from a kernel image, exporting/importing Monticello packages, moving a debugger from one image to another one, persisting (and also import/export) Pier kernels, etc.

So…see you at Ghent?

Random news

Hi. Sorry for being away from the blog for so long but I was on holidays and, when I came back, I dedicate all my time to submitting a paper. This post is just a summary of some recent news. In case you are already aware, then just discard this post 😉

Pharo 1.4 was released

Finally. After a lot of work, Pharo 1.4 was released. You can read the list of actions done here. Pharo is not perfect and, of course, there is still a lot of room for improvement but, from my point of view, the system is getting better with each release. Some of the improvements are in the UI or in direct tools so users notice them. However, most of the changes are in the infrastructure, that is, under the hood so they are not always perceived by the user. One way to notice this is the fact that we are able to build a lot of great stuff using this new infrastructure. As an example, I refer to projects such as Ring, RPackage, Nautilus, Zinc, Fuel, Opal, NativeBoostAthens, Moose, Spec, DrGeo, etc.

Pharo Conf 2012

For the first time ever, we  will have a Pharo Conference. It will be held in Lille, France on the 24th and 25 th of May 2012. Pharo Conf 2012 is organized by the Pharo core team of INRIA and the IA team of Ecole des Mines de Douai, both of which I am proud to be part of. For more information you can read this blog post. The main goal of the conference is to bring companies, developers and users together. Yo can register for the social event here.

International Workshop – IWST 2012 program committee

This is kind of personal but, since I am really happy, I wanted to share the news with you. I will be part of the program committee of IWST 2012 collocated in ESUG. It is the first time for me so I hope I will enjoy it.

Young Engineer Position on Smalltalk VM and Related Technology

This looks to me like the best job offer ever. It is an engineer position in RMoD team (in Lille, France) which is focused on virtual machine related work. As researchers, we need a system that allows us to explore new ideas. The job of the engineer is to help us by improving the infrastructure we use for our daily work. You can read more about it here. Wanna apply?

13 GSoC accepted projects (Fuel included!)

ESUG has received 13 slots for the GSoC 2012. This means that there were 13 accepted Smalltalk projects. I think these kind of projects are always useful. I was part of the ESUG SummerTalk (in two opportunities as a student and once as a mentor) and I think it is really worthy. As a  student, you can learn a lot and hopefully also give something useful to the community. Happily for me, one of the accepted projects is FuelPackageLoader. Even if I am not as official “mentor” in the GSoC, I will be there 🙂  What we are going do is described here. Basically, we will continue the prototype we have started. I talked about that when I showed how to import and export packages with Fuel (meaning to load Seaside in 10 seconds).

Ok, so that’s all for now. Talk to you soon!

ESUG 2011 presentations’ slides

Thanks to Marcus Denker, all the slides of the presentations of ESUG 2011 are available in two places: to directly download from: http://esug.org/data/ESUG2011/ and to view or download from slideshare:   http://www.slideshare.net/esug/

As every year, ESUG has not only the presentations of the conference itself but also from the International Workshop in Smalltalk Technologies (IWST). So, the slides of the presentations of the conference are in http://esug.org/data/ESUG2011/Slides/ and http://www.slideshare.net/esug/presentations. The ones of IWST are in http://esug.org/data/ESUG2011/IWST/PRESENTATIONS/ and http://www.slideshare.net/esug/presentations. In addition, the proceedings of IWST are in: http://esug.org/data/ESUG2011/IWST/Proceedings.pdf

As I have explained in a previous post, I gave 3 presentations: one (DBXTalk) for the conference and two (Fuel and Ghost proxies) for the IWST.

The first one was the one of Fuel. It was a pity because the printed schedule of the conference was not in sync with the real time of the talk. Hence, some people missed it. Anyway, the slides can be downloaded here and in slideshare.  You can also download the paper from here. If you are interested in Fuel, I really recommend to see the slides and to read the paper.

The second talk was also as part of the IWST and was about Ghost, a proxy implementation I did on top of Pharo. The slides can be downloaded here and in slideshare.  Again, you can also download the paper from here.

Finally, on Friday we did (together with Santiago Bragañolo and Guillermo Polito) a presentation of DBXTalk. The slides can be downloaded here and in slideshare. The live demo….well maybe we will have the video in a near future.

See you

Fuel: First place at ESUG Innovation Technology Awards

ESUG Innovation Technology Awards presentations

Hi guys. As I have already told you before, I finally presented Fuel at ESUG Innovation Technology Awards. The awards ceremony was quite good. Some people came to the table where I was and asked things about Fuel. Some didn’t know at all what Fuel was about (neither the internals of a general serializer while others knew a lot about serializers. I got interesting talks and some good ideas. Now there are even more items in my infinitive to-do list.

BTW, thanks Adriaan van Os for his wonderful pictures.

Now….showing a serializer is quite boring. What would you show?  Serializing and materializing an object graph is plain boring. So I though I could show something more interesting such as:

  1. Type some code on a workspace, debug it and then, in the middle of the debugging, serialize the debugger and its content into a file. Then I opened another image, I materialized the file and the debugger just opened. I could continue the debugging in this new image, exactly in the same place where it was serialized and with all the temp variables with its correct state. People were amazed about this. It is fun it took me literally 2″  to test it and see it works. There is NOTHING special needed for Fuel to test that.
  2. Following the previous item, Esteban A. Maringolo recommend me in the Pharo mailing list to do more or less the same but with Pharo errors. Pharo writes down an exception into PharoDebug.log (this is done in #logError:inContext:). So what I did is to modify such method so that it also serializes the context into a PharoDebug.fuel. Then, for the demo, I raised an exception so that the PharoDebug.fuel was written. Finally, I could take another image, materialize such file and debug the exception 🙂   That was kind of fun. Of course there are a lot of limitations in this but it was fun anyway.
  3. I showed how to use Fuel with a Riak NoSQL database. This is basically what I explained in a previous post.
  4. I showed how to speed up SandstoneDB by using Fuel instead of SmartRefStream. Again, this was the same as my previous post.

So…that was pretty much what I showed from Fuel. There were much more things I wanted to show but didn’t have time. For example, Martin Dias (main author of Fuel) could export seaside packages, load them in another image and start Seaside!!!

So far so good. Which was the problem? While we (submitters of ESUG Awards) were presenting our projects, Instantiations offered a reception with drinks (wine and scotch) and food. Grrrr I couldn’t take anything. Well…. almost anything. Henrik Johansen took my place a couple of minutes while I took a glass of wine. I may be wrong but someone told me that someone put a nice text in a workspace saying something like “Will be back in a couple of minutes” hahaha. Awesome.

ESUG Innovation Technology Awards Ceremony

The ceremony of the awards was on Wednesday (2 days after the presentation). This happened in the “City Chambers” in Edinburgh. There was a very nice reception (food and drinks again) in a really nice place. Before announcing the winners, “The Lord Provost and Council of the City of Edinburgh” give a nice speech. He (George Grubb) explained Edinburgh was proud of receiving ESUG and the talk was quite fun. Finally, he gave the diploma to each of the winners.

So….as you may guess from the title, Fuel got the first place. First of all, I want to really thanks to all the people who vote for us. There were a lot of interesting projects out there. Second, I would like to thanks Martin Dias. HE is the real Fuel developer. He has been doing a great job with Fuel and I just help him as much as I can. He deserves the honor as much as I do (and even more!). Finally, thanks to ESUG for sponsoring Martin with SummerTalk and to Stéphane Ducasse for bringing Fuel to life.

Paper accepted and slides of the presentation

Apart from presenting Fuel at the ESUG Innovation Technology Awards, we have also submitted a paper to the International Workshop on Smalltalk Technologies. You can get the paper here. The paper was accepted, invited to do an extended journal version of it and then I gave a presentation in the ESUG conference. The talk was more or less good but as always I have something to learn. This time, the problem was the I had too many slides. I was on time (ok, maybe 5 minutes more hahahhah) but I have to be too fast. Next time: less slides.

Anyway, the slides are available here and also in slideshare.

Boosting SandstoneDB with Fuel

Hi guys. I continue to find nice Fuel examples to show at ESUG, and I while doing so, I post my results 😉 . It may be useful for someone else apart from myself.  SandstoneDB is a database similar to Ruby’s ActiveRecord. SandstoneDB is a simple object database that uses (by default) SmartRefStreams to serialize clusters of objects to disk. It seems that currently there is also a GOODS database backend.

For more details about SandstoneDB please read: http://onsmalltalk.com/sandstonedb-simple-activerecord-style-persistence-in-squeak. There is also an excellent screencast about it in PharoCasts.

In summary, SandstoneDB is a simple database which I think it may be useful for small/medium applications. Anyway….the goal of this short post is to show you how to speed-up SandstoneDB by using Fual serializer instead of SmartRefStream. Ramon Leon, author of SandstoneDB did the integration between the both. This was pretty straighforward and worked out of the box in the lass one hour. It was necessary to only create the class SDFuelSerializer with two methods: #serialize: anObject toFile: aFile  and #materializeFromFile: aFile.

So….how to install and use SandstoneDB with Fuel? Quite easy in fact:

1) Grab a Pharo image and install Fuel. Otherwise, you can download an image from Jenkis: https://ci.lille.inria.fr/pharo/job/Fuel/. Anyway, if you want to take a Pharo image and install Fuel in it, just execute:

Gofer new
squeaksource: 'MetacelloRepository';
package: 'ConfigurationOfFuel';

((Smalltalk at: #ConfigurationOfFuel) project version: '1.6') load.

2) Install SandstoneDB and its integration with Fuel:

Gofer new
squeaksource: 'SandstoneDb';
package: 'SandstoneDb';
package: 'SandstoneDbTests';
package: 'SandstoneDbFuel';

3) If you run now the tests with SandstoneDB you will still be using SmartRefStream instead of Fuel, even if we have downloaded the package “SandstoneDbFuel”. So if you want to use Fuel as the default serializer you have to evaluate:

SDFileStore serializer: SDFuelSerializer new.

4) That’s all 🙂 You can now run all SandstoneDB tests, they all should be using Fuel and they all should be green 🙂

Now, how much speed-up you can have? Well…that depends on the graph you are serializing. The bigger it is the graph to serialize, the faster Fuel will be over SmartRefStream. If the graph is large, Fuel can be like 10x faster than SmartRefStream. If it is small, much less. The following is a benchmark where we individually serialize 500 persons. Each person is small, hence there is not that big difference. Nevertheless, in this test, Fuel is 2.5 times faster in serialization 1.5 times in materialization.

| commitTime people lookupTime loadTime |
 "  SDFileStore serializer:  SDSmartRefStreamSerializer new."
 SDFileStore serializer: SDFuelSerializer new.
 setStore: SDFileStore new;
 "only want to warm up test models, not anything else that might be in this image"
 SDFooObject warmUp.
 SDPersonMock withAllSubclasses do: [ :each | each warmUp ].

people := (1 to: 500) collect: [ :it | SDPersonMock testPerson ].
 commitTime := [ people do: [ :each | each save ] ] timeToRun.
 lookupTime := [ people do: [ :each | SDPersonMock atId: each id ] ] timeToRun.
 loadTime := [
 SDActiveRecord resetStoreForLoad.
 withAllSubclassesDo: [ :each | SDActiveRecord store ensureForClass: each ];
 withAllSubclassesDo: [ :each | each warmUp ].
 SDActiveRecord store ensureForClass: SDFooObject.
 SDFooObject warmUp ] timeToRun.
 show: 'Serialiation time: ', commitTime asString;
 show: 'Materialization time: ', loadTime asString;
 SDPersonMock do: [ :each | [each delete] on: Error do: [] ].
 SDPersonMock coolDown.
 SDFooObject do: [:each | [each delete] on: Error do: [] ].
 SDPersonMock allSubclassesDo: [ :each | each coolDown ].
 Smalltalk garbageCollect

If we take the same example what instead of serializing each person individually we save serialize an object that contains all those persons, Fuel is 12x faster in serialization and 6x in materialization.

Anyway…all this was just a proof of concept. All I can tell you is that all tests are green and that Fuel seems to speed-up SandstoneDB. If you want to give it a try, please go ahead. And if you already have an application running with SandstoneDB and SmartRefStream I would appreciate if you can benchmark both since it is interesting to see a real case.

See you.

When Fuel meets Riak NoSQL database

Hi guys. I was fed up of writing a paper so I started to think what to show in the ESUG Awards with Fuel. As explained in my previous post, Fuel is a new general purpose and fast object graph serializer for Pharo.

The first thing it come to my mind, was the following: debug something from the workspace and in the middle of the debugging, serialize the debugger into a file. Then open another image, materialize the debugger, and continue debugging. The good news is that it worked from the first shoot! Nice! I will show it in ESUG.

Now, the second thing was something that was in my head since a couple of months: use Fuel to get a byte array representation of an object graph and store/retrieve it from a NoSQL database. Of course, there are several NoSQL databases, and even several wrappers for Pharo. For my experiments I choose Riak because I read it may have the best results. Runar Jordahl did the binding for such database and as many cases, the API is using HTTP protocol. Thanks to Sven Van Caekenberghe, we have now a wonderful HTTP library in Pharo Smalltalk: Zinc. Obviously, Riak client for Pharo uses Zinc.

Why is Riak important and how it is related to Fuel? Most web apps read intensive. Fuel is designed by scratch to be extremely fast during materialization. And Fuel fits nice with a NoSQL like Riak, since Riak reads fast as well. Minimizing latency on web pages is really important. With riak (commercial version) you can host your database on many datacenters. So you can have datacenters close to all customers. So…reading from Riak is fast, and materializing from Fuel is also fast. And now in Pharo we have a fast VM as well. 🙂

Ok….I should stop talking and show you the code. I will show you how to store and read a simple object graph into a Riak database using Fuel. Steps:

1) Install Riak database server. You can download it from here: http://downloads.basho.com/riak/CURRENT/. For more information about how to install and setup a Riak database you can read: http://wiki.basho.com/Installation-and-Setup.html

In my Mac OS, I just unzip the file and that was all. Let’s say  the directory where I have the unzip is /home/mariano/riak.

2) Start the server. In Mac I went to the directory /home/mariano/riak/bin. There you will find the executable Riak. So, just run “./riak start”.

3) Check the server is running. Just execute “./ping” and you should get a “pong”.  Another possibility is to go to your web browser and go to http://localhost:8098/riak/ or http://localhost:8098/ and you should see a couple of things.

4) Ok…..cool. Now, grab a Pharo image and install Fuel. Of course, if you are lazy like me, you can download an image from our greatest tester/slave, Jenkis: https://ci.lille.inria.fr/pharo/job/Fuel/. Anyway, if you want to take a Pharo image and install Fuel in it, just execute:

Gofer new
squeaksource: 'Fuel';
package: 'ConfigurationOfFuel';
((Smalltalk at: #ConfigurationOfFuel) project latestVersion) load.

5) Install Riak client by executing:

Gofer new
squeaksource: 'EpigentRiakInterface';
package: 'ConfigurationOfEpigentRiakInterface';

((Smalltalk at: #ConfigurationOfEpigentRiakInterface) project version: '0.2') load.

6) Since in step 2) we have started our server locally, our tests should use the local server. To make this work, you have to options: add a mapping between ‘riaktest’ and localhost in your “hosts” file or even simple, just modify the method #riakTestUrlString to something like:

^ 'http://localhost:8098/riak'

7) Now you should be able to run Riak tests and they should be green.  Of course, Fuel tests should be green as well.

Ok. Once you follow all those steps, you should have a Riak database running locally and a Riak client in Pharo using Zinc and being able to talk to the database. So…how do you store stuff in a NoSQL database? basically, data is stored with key / value. The key is usually a String and the value can be a string or something binary. You may have listen that NoSQL databases can be used as a persistency strategy for enterprise applications. But how can that be possible if Riak only accepts strings or bytes? Well, here is when the serializer plays its role. One possible solution is to use a JSON or XML serializer in which case you take your domain specific object graph and you serialize it to a text file which is then stored in the NoSQL database.

But with Fuel, we can serialize an object graph in a binary way, and we able to serialize it and materialize it really fast. Here is an example of how you can use Fuel with Riak:

| bucket storedObject materializedObject aRectangle client |
client := EpigentRiakClient newForRestConnection: 'http://localhost:8098/riak'.
aRectangle := Rectangle origin: (4@2) corner: (7@1).
storedObject := FLSerializer serializeInMemory: aRectangle.
bucket := client  bucketNamed:  'epigenttest' .
bucket atKey: 'test' put: storedObject type: 'application/binary'.
self assert: (bucket atKey: 'test') = storedObject.
materializedObject := FLMaterializer materializeFromByteArray: storedObject.
self assert: materializedObject origin = (4@2).
self assert: materializedObject corner = (7@1).

Basically, we use Fuel to serialize an object graph into a ByteArray. Then we store such object into a Blob in the database. And of course, we can then read it and materialize it. What do we gain with this? Now you are able to take any object graph and store/retrieve it from Riak database. Just replace “aRectangle” for whatever object you want. If you are developing a real application, this object may be your “root” which is usually a dictionary.

So….since I am a simple PhD student, I’ve already done my job: experiment. Now it is your time to get something real from this 😉

See you

My talks at ESUG 2011

Hi guys. This is a short post to just let you know what I’ll be talking about at ESUG this year in Edinburgh, Scotland. I’ll give a total of 3 talks which are the following:

1) Fuel: Boosting your serialization.

Fuel is an open-source general purpose framework to serialize and materialize object graphs based on a pickling algorithm. Fuel is implemented in Pharo Smalltalk environment and we demonstrate that we can build a really fast serializer without specific VM support, with a clean object-oriented design and providing most possible required features for a serializer.

For more details please visit Fuel website: http://rmod.lille.inria.fr/web/pier/software/Fuel

I will give an introduction to Fuel explaining its pickle format showing some examples of how to use this serializer. Ahhh at the same time, I am submitting Fuel to the Innovation Technology Awards 🙂

I participate in Fuel in several ways:

– Fuel is being sponsored by ESUG SummerTalk and I am the mentor. The student and main developer is Martin Dias.

– I contribute with code and test.

– For my research/PhD prototype, I use Marea as the serializer.

2) Ghost:  A Uniform, Light-weight and Stratified Proxy Implementation

This talk is about the paper we wrote about a novel proxy implementation. I’ve developed Ghost proxies in Pharo Smalltalk and it is part of my PhD.

This toolbox provides low memory consuming proxies for regular objects as well as for classes and methods. Ghost proxies let us intercept all messages sent to a proxy, with clear separation between the layers of intercepting and handling interceptions. Ghost is stratified and does not use the common yet problematic #doesNotUnderstand: for implementing proxies.

For more info please read: http://rmod.lille.inria.fr/web/pier/software/Marea/GhostProxies

3) DBXTalk: Argentinian Connection.

DBXTalk is the complete and open-source solution to relational database access. It has been in development since 4 years already and it includes the following tools:

  • OpenDBXDriver: this is the database driver and it wraps the C library OpenDBX. This subset of DBXTalk was formerly known as SqueakDBX.
  • GlorpDBX: this is a port of VisualWorks Glorp plus some changes to make it work with different database drivers such us OpenDBXDriver.
  • DBXTalkDescriptions: it’s a tool to generate classes from tables and tables from classes, based in Glorp types. Also to generate GlorpConfiguration from Magritte descriptions. And a UI to make it easy to use.
  • DBXPlus: it’s a UI to visualize and browse databases without going out the image. You can execute sql query and review the results, browse into the defined tables and views, inspect the structure and the data stored.

Guillermo Polito, Santiago Bragagnolo and me (all part of the team) will give you an introduction to all those tools of the DBXTalk suite while showing real examples.

For DBXTalk, well…I was part of the authors. I have been actively developed SqueakDBX/DBXTalk and it is the open-source project I have spent more time in apart from Pharo. DBXTalk is used in several production applications and it has already it list of users.

For more info, check the links:



All the schedule of the talks are in here

That’s all for today.