New Website!

We have a new website and a new logo for our community. Go Smalltalk!

Smalltalk was designed for Kids!

Yes! Alan Kay was trying to develop an environment to be used in the education of our kids.

Did you Know that Smalltalk was created in 70's at Xerox?

The use of the mouse, the "copy and paste", the bitblt and others technologies was firstly created in Smalltalk. Steve Jobs saw those ideas at Xerox and he developed a new language, Objective-C.

Mailing List in Spanish!

Please, go to and join us!

April 26, 2009

The SqueakDBX team has announced the first stable version of the OpenDBX Wrapper

The SqueakDBX team has announced the first stable version of the OpenDBX Wrapper, here is the announcement in the Squeak List: 
After a continuous work since January 08, we are very glad to announce our first stable version of SqueakDBX.
For those who don't know what this is about, the aim of this project is to build an OpenDBX ( wrapper which will allow users to perform relational database operations (DDL, DML and SQL) through a truly open source library. Through this feature, the squeak community will hopefully be able to interact with major database engines, such as Oracle and SQL Server, besides those which are open source, like PostgreSQL, MySQL or Sqlite. Moreover, by integrating this with GLORP (, will allow us to generate a complete and open source solution to relational data base access.

Why did we do squeakDBX?

There are several approaches to persistence in Squeak, some very interesting: OODB like Gemstone and magma, image, CouchDB or TokyoT/C, and so on. All of this options get sense if you can actually decide the way you will persist your objects.
However, this is not something that happens very frequently. FREQUENTLY, the client (the one who pays you for making the software) requires you to use a particular persistence strategy (RDBMS). Not only that, but also a database in particular (like Oracle, MS SQL, and so on). They have lots of reasons: they already have license for it, they have support and companies for it, they know SQL, they want to do selects, legacy systems, and so on. But Squeak only provides drivers for MySQL and PostgreSQL natively, so... what would you do in the rest of the cases? move to another language? OK, we don't. We want to program systems in Squeak.
If you know about SqueakDBX you can just see changelog here:; If you don't, you should continue reading ;)
SqueakDBX features:

  • Runs on Squeak and Pharo.
  • Own SqueakDBX plugin (experimental). Ability to easily change the external call strategy (FFI or our own plugin).
  • Support for: Oracle, PostgreSQL, MySQL, MS SQL Server, ODBC and SQLite3
  • Automated database connection ralease (although manual disconnection is recommended ;-)
  • Automated results retrieving in order to do another query, after doing a query and not iterating ALL results 
  • Error handling: Not only errors, but levels associated with an error in order to avoid FFI calls (if you get a fatal error, it has no sense to do another query and the resources must be free). See
  • Very completed documentation in wiki and getting started.
  • Code critics and SwaLint were run several times.
  • Good design (at least all the major refactors demonstrated that).
Full documentation, installation and getting started instructions can be found at wiki page: We spent a lot of time in it. It has all the information you may need and is in continuos development.
Benchmarks: We have a lot of SqueakDBX benchmarks and also some for native squeak drivers (PostgreSQL and MySQL) and SqueakDBX seems to be faster than both of them. You can read more here:
Packages can be installed from Universe (3.10) or SqueakMap. Current version is 1.0. Sources can be download from SqueakSource (it requires FFI installed).

OpenDBX version: 1.4.
Remember that you can compile OpenDBX by yourself or use precompiled binaries. For more information please read:

GLORP integration: Actually, this may include two parts: The integration of GLORP with squeak is completely hardcoded with PostgreSQL native driver. Because of this, first we will do a refactor in GLORP in order to enable it to support different drivers. We will create a PostgreSQL driver with the things that GLORP already has. We invited Alan Night to have dinner with us when he came to Argentina. We told him our ideas and discuss for a while till we got a first design of this refactor. We have already started this part.
Create a SqueakDBX driver for GLORP just like the one we are planning to do for PostgreSQL.

The last squeak port of GLORP is very old and there is nobody to do it. A friend of us, Diogenes Moreira, has accepted this job, so, thanks to him, we hope to have latest GLORP releases in Squeak.
You can see our Glorp progress here:

Help is always wanted. We would really appreciate if you:

Give us opinions, comments, ideas, new features, complaints and so on.
Tell us if you find a bug. Tell us if you test SqueakDBX with other RDMBS or OS different from the ones we tested. Just to know if it works or not :)

If you try SqueakDBX and you write something somewhere like a blog, let us know. We have this link: where we put useful links for all the people.
Special thanks to:

  • ESUG, for supporting us through Summer of Talk 08; 
  • To Norbert (author of openDBX) for his help and to all the people who tested it and help us.
SqueakDBX team

April 3, 2009

Interview with Gabriel Honoré, the creator of a Commodore 64 emulator in Smalltalk

In the second edition of Smalltalks, the Argentinean Smalltalk congress, he presented a Commodore 64 emulator. The talk was the most voted by the public and, as the result, he won the historical Byte magazine issue. In this interview, he answered some questions about his motivations and future plans.

CS: Gabriel, tell a little about your background
GH: My name is Gabriel Honoré, I'm 24 and I live in Buenos Aires, Argentina. I'm studying Computer Science at the University of Buenos Aires, and I work as a game developer.
Since I was a child I developed a special interest for computers. The first computer I used was a Commodore 64 that belonged to my brother. I remember how much I enjoyed playing its games. In the meantime, I found out that I could use a computer to make programs, and since then, programming became one of my favorite hobbies.
When my parents bought me my first IBM compatible I learnt new programming languages. Eventually, I discovered the demoscene and immediately became interested in computer graphics and low level programming.
During my studies in the university I realized that I was also very interested in other things I hadn't investigated previously in depth, such as computer architecture and software development using the object paradigm.

CS: How did you start with Smalltalk?
GH: The first time I heard about Smalltalk was in one of the subjects I attended, called Paradigms of Programming Languages. The last classes corresponded to the object paradigm, and to show the concepts behind it, my teachers used Smalltalk.
What was my first impression? Well, first I was amazed with the keyword messages; I had never read such a clear code! The "everything is an object" concept resulted quite natural and at the same time, made me feel curious. Afterwards, we went over some of the other language features such as late binding and its dynamic typing system.
All those language features along with those of the object paradigm awoke a spark in me that led me to decide to attend two subjects about the paradigm. In those subjects I learnt in detail what the paradigm was about, along with Smalltalk. I found out that Smalltalk was more than a programming language and I came to know its other virtues such as its excellent dynamic environment, its free access to all the system objects, the persistence of objects and the non-distinction between a development time and an execution time, just to name a few.
Since that moment, all my personal projects started to be done in Smalltalk. And where I can't use Smalltalk, I try to apply its principles!

CS: Why did you decide to build a Commodore 64 emulator?
GH: Nostalgia was a determining factor. The Commodore 64 was the first computer I had at home, and as a child, I spent hours and hours in front of the TV writing my own programs or copying them from books and magazines.
From that moment on, I've been interested in everything that concerns that computer; you will be surprised to know the amount of software and hardware projects that are being developed for the C64 after such a long time!
On the other hand, my interest in the object paradigm and the discovery of Smalltalk awoke in me the desire of making a relatively big project involving them.
There were other things that motivated me to start with this project. For example, I realized that almost every emulator was written in statically typed languages and just a few in dynamically typed ones (actually, I found just one, written in Python). Also, very few of them were developed based on the object paradigm, and the ones that did failed at identifying unrelated entities and giving each one a different object in the model.
All this things made me wonder: Could it be done? Could I make an emulator in Smalltalk that works at full-speed, can run the majority of the games available, and at the same time has a good object oriented software model? Would I have to sacrifice a good model in order to obtain a reasonable performance?
Making a C64 emulator in Smalltalk meant a big challenge, a lot of fun and a huge satisfaction as I knew I would be joining two things that I like a lot: the C64, and software modeling using the object paradigm.

CS: What were the most difficult parts to resolve in an emulator?
GH: The most difficult part is to achieve a good and clean design, while at the same time working out specific problems of the software domain, such as performance.
This is especially true when it comes to the modeling of hardware components, because an isomorphic representation in software usually requires high computation power. A lot of times, the available solutions to reduce this negative impact imply changing the software model in a way that it doesn't work exactly like the real counterparts anymore, making the model poorer.

CS: What is the conclusion after the experience?
GH:It was a very great experience! As regards the emulator, I could achieve all the objectives I set myself. The result was a functional emulator with a high level of compatibility and a reasonable performance, while keeping a clear and simple model, and with many concepts being reified.
Personally, I had a lot of fun during this project. I acquired greater knowledge about computer architecture, and I learnt a lot about how sound works (something I felt always curious about). I kept discovering more about Smalltalk and I improved my skills to model with objects.
As a bonus, my thesis director offered me to make a thesis based on my C64 project. Afterwards, my lecture at Smalltalks 2008 showed me that people also liked it. What more can I ask for!

CS: A Commodore 64 emulator and Smalltalk could be, for a lot of trendy IT Colleges, like a couple of things from the past. How do you feel about the trendy market of today?
GH: I don't think it is a healthy decision to define the choice of a programming language, or a development environment, exclusively because it is a tendency. Needs are not the same for everyone, and different development languages/environments tend to solve different needs.
I think the decision has to be made with the improvement of productivity in mind, allowing software developers to only worry about creating good software, and not to waste time dealing with technical issues of the language or the environment they use.
Smalltalk is a system that was thought with productivity in mind; we can see that, for instance, in the excellent level of its tools, its dynamism, its capabilities to be extended and adapted to any context, and its high fidelity to the object paradigm.

CS: What are your future plans?
GH: Within a short time I will intend to develop a framework that makes easier the development of emulators for all kinds of old computers and consoles. Once that is finished, I'd like to develop at least one more emulator that uses it. A NES console Nintendo Entertainment System and other Commodore computers are possible candidates.
I also want to publish my C64 emulator, for free, even though I would like to add first some features that I consider important and that are lacking now.