OFSET Planet (English only)

To content | To menu | To search

Tag - smalltalk

Entries feed - Comments feed

Tuesday, June 1 2010

Horizontal grid artifact

I created a new artifact for Etoys, it is to divde a grid in two parts. It can be use to explain distribution in calculus 5*7=5*5+5*2. It is scriptable graphically with Etoys tiles.

Moreover, now the artifacts appear in a specific Artifacts category of the Object Catalog.

horizontal-grid.png

You can load in Etoys/Squeak/Pharo from its repository

Fraction Box Artifact

I created a new artifact for Etoys, it is to represent m parts among n parts. It is scriptable graphically with Etoys tiles.

FractioBoxMorph.png

You can load in Etoys/Squeak/Pharo from its repository

Wednesday, April 21 2010

Some more about Polymorph for DrGeo

Someone asked for a more elaborated UI for DrGeo, here are some progresses in this polymorphization of DrGeo. Known to work with Pharo 1.0.

In its latest Monticello package one can grab DrGeo at http://www.squeaksource.com/DrGeoII

DrGeo Polymorphization

To start a DrGeo instance, do a DrGeo new in a workspace and enjoy the UI.

Beware, style tools does not work in the toolbar.

It is also possible to use DrGeo as a service for Etoys when executing a DrGeo sample openInWorld

It is also possible to load XML description of DrGeo 1.1 geometric sketch, if one is interested you can grab it at http://svn.gnome.org/viewvc/drgeo/trunk/examples/figures/ and load a sketch with a command: DrGeo newXml: path

Beware sketch with embedded Scheme code will not work (just try)

Working sketch: mercedes, euler-line,

DrGeoII comes with a better interface for scripting with Smalltalk script, empowered by the IDE, nicer than the former Scheme one. See this elaborated demonstration (automatic translation link with Google in a comment, at the end of the article)

Thursday, April 15 2010

Pharo Smalltalk 1.0 is out

Pharo is a new Smalltalk programming environment, derived from Squeak. It is largely used by the Seaside web framework.

The 15 of April, the version 1.0 was released

Saturday, April 10 2010

UI with Pharo

How to write GUI application with Pharo Smalltalk?

In this series of articles I will use DrGeo Smalltalk porting effort to Pharo UI as an example. The articles use Pharo 1.0, but it should work with newer version without modification.

Do not hesitate to comment.

I start with with a kind of StandardWindow class I nammed DrGeoWindow, it is the main UI element of DrGeo:

StandardWindow subclass: #DrGeoWindow
     instanceVariableNames: 'view presenter domain'
     classVariableNames: ''
     poolDictionaries: ''
     category: 'DrGeoII-App'

If you look at the StandardWindow class definition, you see it uses a trait coming from the Polymorph UI framework:

SystemWindow subclass: #StandardWindow
	uses: TEasilyThemed - {#theme}
	instanceVariableNames: ''
	classVariableNames: ''
	poolDictionaries: ''
	category: 'Polymorph-Widgets-Windows'

In a few words, a trait is a mechanism to import in a given class, an interface of methods, without the need of subclassing or poly- inheritance.

This keyword uses: TEasilyThemed - {#theme} says import the methods from trait TEasilyThemed without the method named @theme@.

So what is coming along this trait TEasilyThemed?

The screen shot bellow shows the hierarchy of the DrGeoWindow class, its direct ancestor is selected so we can see its interface. The methods imported from the trait are emphasized:

DrGeoWindow hierarchy

For the UI developer, the trait brings two advantages:

  1. Services of UI elements like dialogs: question dialog, file dialog, ...
  2. Controls to build up your own complex UI elements in your window: controls like button, menu, toolbar, entry,...

In a next article, we will learn how to use these controls to enhance our window features.

Saturday, April 3 2010

DrGeo for Pharo Smalltalk

Pharo uses the Metacello system to install a source package with its dependencies.

I have updated DrGeo to make it compliant with Pharo 1.0. I also took the opportunity to write a ConfigurationOfDrGeo using Metacello package management facility.

The Configuration is for now in the DrGeo repository: http://squeaksource.com/DrGeoII

To install it, execute in a Workspace:

Gofer new
   url: 'http://www.squeaksource.com/DrGeoII'  ;
   package: 'ConfigurationOfDrGeo';
   load.
(Smalltalk at: #ConfigurationOfDrGeo) perform:#load.

To start DrGeo, execute in Worspace:

DrGeo sample openInWorld

Sunday, December 14 2008

Smalltalk, the Free Software spirit in action

In this article, I explain how Smalltalk is since 30 years a practical social implementation of the freedom #3 and #4 of the Free Software philosophy: freedom to study, to modify and to redistribute a software.

Free Software takes a philosophical position toward software and how it should be shared. Open Source (OS) software, with the same practical position, does not share this philosophical position. Its position is more Free Software can improve the process to develop software.

Free Software (FS) is based one four simple freedoms:

  1. freedom to use the software
  2. freedom to redistribute the software
  3. freedom to study the software
  4. freedom to modify and to redistribute the software

FS does not care about the business aspect attached to software, it is not against it however it is deliberately socially targeted. This social dimension of FS software is very important, and it is for me an important difference with OSS. It makes the human been at the center. It is particularly clear with the freedom \#3.

So how are all these considerations related to the Smalltalk paradigm?[1]

Before being a Smalltalk experienced coder, I was a C++ developer. With this language I wrote the Dr. Geo interactive geometry software, targeted for educators in mathematics. When we look at the Dr. Geo sources the barrier of entrance for an educator to study and to modify the source code is very high and for most users out of reach. I think it is a serious problem regarding the social dimension of the FS. Not only C++ is a complicate language, worst the environments to develop and to modify the source code are not intuitive and limited in their scope[2]. These problems appear in all the languages I have used but Smalltalk.

So what is special about Smalltalk?

In 1981, Dan Ingalls a founding father of Smalltalk, wrote in the Byte magazine:

The purpose of the Smalltalk project is to provide computer support for the creative spirit in everyone. Our work flows from a vision that includes a creative individual and the best computing hardware available. We have chosen to concentrate on two principle areas of research: a language of description (programming language) that serves as an interface between the models in the human mind and those in computing hardware, and a language of interaction (user interface) that matches the human communication system to that of the computer.

The focus is not only on a suited language for creativity for everyone but also a user interface to interact with it. This later point was very innovative 30 years ago, it is still innovative today. So what is exposed there is how to make as smooth as possible the access to creativity with software: it is true not only when creating new software but also when studying and modifying an existing software.

Indeed, with Smalltalk it is just so obvious to modify a software you are using. Not only with the key stroke [Alt]-b you access to the source code of the application your are using, but you can also modify its source code and all the processes of compilation and execution is done transparently. With Smalltalk the barrier of entrance to modify source code is very low and it makes it a wonderful tool perfectly matching the philosophical approach of Free Software.

Next Dan explained:

Personal Mastery: If a system is to serve the creative spirit, it must be entirely comprehensible to a single individual.

This principle is very strong and it clearly states the application source code and all its necessary components must be in the reach of the user. How is it explicitly done with Smalltalk and what are the consequences for the end user?

To achieve Personal Mastery as defined by Dan, Smalltalk is written in itself. If you take a script language like Python, this one is written in C and most of its libraries are also written in C. C is a different language, thus another environment, thus a barrier when one wants to understand the use or design of the Python class libraries. I remember how complicated it was for me when I wanted to understand how to use the GTK+ binding for Python.

In Smalltalk, the language itself is written in Smalltalk, it is circular: all the class libraries are written in Smalltalk, even the basic arithmetic or boolean operators or loop and test constructors are written in Smalltalk. The consequence is that for the user, it is just one mouse clic away (Implementor button in the class browser) to access to the definition of these classes. So again there is a direct access to the source to study a software as wished in the FS philosophy, with Smalltalk it is pushed very far to make it accessible to a lot of users.

Good Design: A system should be built with a minimum set of unchangeable parts; those parts should be as general as possible; and all parts of the system should be held in a uniform framework.

This is the idea of Smalltalk being largely written in itself, thus only a minimal part of Smalltalk cannot be changed (6 keywords and 3 message sending protocols), then most of Smalltalk can be studied as any piece of Smalltalk code and of course modified if necessary by the end user.

I found it very interesting how Smalltalk, long time before FS, pushed very far this idea of the access to source code. This is a thought I want to share with you.

Notes

[1] Smalltalk is not only a programming language but also a way to interact with a computer.

[2] With these environments the user is limited to the source code of the software. From these environments, the user can't easily browse in the source code of the third party components (like widget and standard class libraries) used to developed the software itself, and of course the user can't modify easily these components.

Thursday, August 28 2008

DrGeo II wins ESUG 2008 Innovation Technology Awards

It looks like I did it!

DrGeoII #1 at ESUG 2008 Innovation Technology AwardsDr. Geo poster

Among 21 competitors, Dr. Geo II was ranked #1 by the attendees of the ESUG 2008 Conferences at Amsterdam. The participants to the contest were invited to present their product in a large show room where the attendees could discover the products and discuss with the developers. The 21 participants were great and many deserved to win.

See the details of the results.

Tuesday, August 5 2008

More fun with Smalltalk script

In a previous article, I introduced the Smalltalk script system used in DrGeoII. I exposed how a simple script with argument can be used to generate random numbers. Here I will demonstrate the use of script with arguments. When using argument with your script you can do complex computation and plug the result in the drawing area of DrGeoII.

A script with two points as argument

We will write a simple script to calculate the distance between two points. Note that this feature is built in DrGeoII.

To handle the arguments in our script we use the Smalltalk keyword-message. The argument of our script are two points called pointA and pointB. Before going further, I need to explain the nature of the arguments sent to script.

Nature of the argument

From the user point of view, the argument sent to a script is related to the item selected in the figure by the user. From an internal point of view, this argument is the model object of this visual item. To be accurate we have three layers to represent a geometric item: its models, its costume and its morph, the one the user see in the drawing area. The model of the items are all subclasses to the DrGMathItem.

Therefore the point arguments of our script are instances of DrGMathItem subclasses, exactly DrGPointItem.

Back to our script

Our script comes with two arguments, we can call it @distance:to:@, it is a two-keyword message. From the DrGeoII pop up menu, we open the script browser numerics>edit script and input our script content:

Un script avec deux arguments

Next, we create two points in the drawing area and we open the script wizard dialog from the menu numerics>use script.

Inserting a two arguments scipt in a drawing area

From the wizard dialog, select our distance:to: script, then select the two points, the selected points are flashing, then click somewhere in the drawing area to plug our script.

With the mouse over a script plugged in the figure, we have interesting feedback about its name and its arguments name:

Script feedback

Conclusion

In this article we have explained:

  • the nature of the arguments received by the script,
  • how to write keyword message
  • the use of script in a drawing area

In a next article, we will expose a more complex use of Smalltalk script.

Monday, August 4 2008

Fun with Smalltalk script

In DrGeo 1.1, I implemented a Scheme script plugged into a geometric figure. These scripts are written with the Scheme language and they are used to do user computation over geometric items. They are plugged into the area and they display the computed script value. See examples. I took a fresh view on how to implement it in DrGeoII, and of course I want take advantage of what Smalltalk can offer for these user script systems.

How does it work?

DrGeo handles user scripts just like any other geometric item, or more exactly as any value item inserted into the geometric figure. A script depends on:

  • a set of items in the geometric figure (its parents item). This parent collection is used as arguments for the script. To specify its parent items, the user selects them in the drawing area.
  • a script definition (or code source). The returned value of the script is printed in the drawing area, the script value.
  • a position in the drawing area is where to print the script value.

DrGeoII script revisited

Regarding DrGeoII script implementation (as of 04/08/2008), as follows:

  • the script language is Smalltalk, a script is defined as an instance method of the DrGeoUserScripts class.
  • a script owns an arbitrary number of arguments, starting with zero. Script name uses the Smalltalk convention: unary message or keyword message.
  • To create and to edit a script, the user operates with a Browser narrowed to the DrGeoUserScripts class

Step by step process to work on a script

We will give two examples, in this article one script without any arguments, and in a next article a script with two arguments. From the background menu of DrGeoII, go to numerics>edit script. A class browser window opens on the DrGeoUserScripts class. We can create and edit the script from there. You are encouraged to experiment the class browser to get your own feeling with the tool.

The browser is opened by default on the examples message category. The pane on the bottom is the place to write code. Edited code must be confirmed with the Alt+s key stroke. When confirming the code change, the method is compiled and DrGeoII is informed about the change, so the drawing area is updated.

A script without arguments

Let's say we want a random integer in ]-10 ; 10]. The method could looks like:

editScript1.png

Now you want to use this script in your drawing area. From the DrGeoII background menu, go to numerics>use script. In the newly opened wizard dialog, you can select the script:

Select a script to use in the drawing area

You may have noted the script description is the comment at the beginning of the message source code, between the double quotes.

Next, as this script owns no argument, click anywhere in the drawing area, the script value will be plugged in at this place. Now when you move this value with the mouse, you will note the script value is changing. Obviously it is at random!

Of course the script value can be used as any other item value: to define a point by coordinates, or as an argument to another script.

Conclusion

In this article, we have exposed the overall structure of the DrGeoII Smalltalk script system and how to use it. We have shown a simple script example without argument to generate random integer.

The DrGeoII Smalltalk script system completely fit in the OLPC philosophy regarding introducing programming to kid. Not only with DrGeoII kids can write code snippet but they can also do mathematical calculus. Moreover the Smalltalk environment provide an extremely friendly environment to write code: the class browser, the debugger and many more friendly tools.

Sunday, June 22 2008

Squeak/Smalltalk at RMLL 2008

The 9th Libre Software Meeting will be held at Mont de Marsan, Landes, in SW France, from the 1 to the 5 of July. LSM is an international free software event taking place in Jully, each year, in a town of France. The first event took place in 2000 at Bordeaux. This year, Squeak/Smalltalk will be largely represented with conferences and workshops.

Mont de Marsan During all the event, each day, topics related to Squeak/Smalltalk are proposed:

And during all the event, a Pharo sprint (coding-party) is organized.

The year of Squeak/Smalltalk ? At LSM 2008 definitely.

Picture Flickr.

Thursday, June 19 2008

Why Squeak? Part III

In this series of articles, I will highlight the advantages of using Squeak/Smalltalk to develop educational software. At some point and based on my experience, I will compare with other development languages. The focus of this article is for educators and developers interested in software programming education applications. In these articles, don't expect to learn about Smalltalk/Squeak programming, my goal is simply to give an overall picture, based on real experience. Feedback is of course very welcome. In this article I will discuss the Smalltalk/Squeak IDE.

previous article - next article

Smalltalk IDE

The most significant developer tools are the class browser, the inspector, the workspace, the debugger, Monticello, Change set sorter (we will not discuss the later one). These are the most used tools, other tools as the transcript, the method finder are pretty useful as well.

Sharing code

Monticello is the default tool to work collaboratively on code development:

  • to share code in a centralized repository. http://www.squeaksource.com offers, as does Sourceforge, space to publish and to share code with Monticello
  • to handle conflicts and to merge code
  • to review code changes

More information can be found at Squeak wiki.

In the following we will show how to load the DrGeoII code from the squeaksource.com repository.

First, open Monticello from open->Monticello browser in the World menu. Then click on +Repository button and choose HTTP, there are several supported protocols to share code.

monticello1.png

Write in the new small dialog box:

MCHttpRepository
	location: 'http://www.squeaksource.com/DrGeoII'
	user: ''
	password: ''

You can also get the magic strings from the web DrGeo II squeaksource interface.

In the left of the main Monticello window you have the loaded packages. When a package is prefixed with a * it has been modified in the image, and eventually changes can be saved in the repository, if you are granted write access to the repository (if not you can save it locally). In the right are the used repositories. A repository may contain several source packages.

I invite you to explore the Monticello interface and the link to the Monticello Squeak wiki page. Beware to not commit code change to an open repository.

Workspace

The workspace is the play field of the Smalltalk developer. From there you can execute code snippets. We continue our exploration of the development tool using DrGeoII code as an example.

Open a workspace from open->Workspace and write the following code:

|canvas|
canvas := DrGeo sample.
canvas openInWorld.
canvas view inspect.

Execute all of it with Alt+a and Alt+d.

Two windows pop up, one is a DrGeoII canvas (without icons, but only a contextual menu in the background) and the other one is an Inspector opened on the object referenced by canvas view. This one is a view description of the DrGeoII canvas.

The canvas can be deleted with the close handle in the halo. Depending on your Squeak version, the halo handles may appear with right click (this is what I get with Squeak 3.9.1 in GNU/Linux).

Now, create a free point on the canvas (you need to click on the canvas background to open the construction menu).

The inspector

An inspector presents the state of an instance, it shows its attributes and its values. From the inspector you can view but also edit the attributes of the instance. In the screen shot below, an inspector is opened on the view instance of the DrGeoII canvas. In this view instance, the costumes attribute is a collection of costume objects.

inspector1.png

In DrGeoII, a costume is an intermediate object between a geometric model and its Morphic view.

In the inspector, in the large area in the bottom you can type in code snippet to manipulate the attribute, both in read and write mode. Let's suppose we want to inspect the first costume from the costumes collection. Type in the bottom area costumes first inspect, select it and do a Alt+a. This will open an inspector on the selected instance variable. The title bar of this new inspector should be DrGPointCostume. (you can also execute costumes first with Alt+i to open an inspector on the value returned by the executed code).

Class browser

Now let's consider we want to edit the costume and change the name printed in the canvas. We will show how we can do this from our inspector. As we don't know the costume interface, we can, from the inspected instance variable, ask for the instance class definition. To do so, select the self attribute in the inspector and do a Alt+b. The browser presents the class of the costume: its instance variables and instance methods.

It is also necessary to know about the ancestor of the costume class. To do so we invoke a special class browser, the hierarchy browser: from the class browser click on the hierarchy browser button.

hierarchyBrowser.png

When exploring the hierarchy, we see the textMorph: method. We will use this method to send a message to the point costume to change its name. From our inspector, we can send messages to the object itself with self as the receiver: self textMorph: 'my point'. Select this code snippet and execute it with Alt+d:

inspector2.png

Now let's introduce a bug somewhere, in the point costume class. We will introduce a bug while we have living instances from our DrGeoII canvas.

Debugging with Smalltalk

From the hierarchy browser we previously opened, we introduce an error in a regularly called method when the canvas is updated. To do so we modify the DrGPointCostume>>redraw method, as you can expect it, a redraw message is sent to the point costume instances each time the canvas need update. Our introduced bug is just an additional 1/0 instruction in the method code.

bugs1.png

Now when we update our DrGeoII canvas (by dragging a point), a ZeroDivide exception is raised. Within Smalltalk we can catch such exception with the on:do message sent to a block of code:

[1/0]
   on: ZeroDivide
   do: ["my exception code"]

If we do not handle the exception, Smalltalk handles it and open the debugger directly on the method where the error occurred.

bugs2.png

In our example, after you drag a point, several debugger windows are opened. Don't worry, our drag just raised several update events. Close all but one debugger window.

The debugger window shows several informational items:

  • the window title is the name of the raised exception
  • the execution stack, one call per line

In the execution stack we see the exception was raised in the SmallInteger>>/ method. However it is not an effective place to look, as we are looking for error in our DrGeoII code. In the previous call instruction from the stack, we recognize our method DrGPointCostume>>redraw, it is a more interesting place to review. Clicking this instruction call expand the debugger with the method source code.

bugs3.png

From there we can edit the faulty source code, save it with Alt+s, then proceed (click on the Proceed button), and that's all.

Conclusion

In this article, we introduced several developer tools:

  • Monticello, for collaborative development
  • Workspace, to test code snippet and to instantiate objects
  • Inspector, to review and modify instance attributes
  • Code browsers to navigate within the source code and to edit it
  • Debugger, to jump into source code and to fix the error.

We have shown how from one tool, we can jump to another one with still the same application instance. In our developer session demonstration, we never need to destroy our application instance to test modifications in our code. Indeed developing Smalltalk application is a smooth process most of the time, involving small progressive steps: when we introduced our bug, we did not need to restart our DrGeoII application, the same is true when we fix that same bug from the debugger.

In this overview, many aspects and tools were not considered. I invite you to test more by yourself and if necessary to ask questions in the Squeak mailing list.

Thursday, April 24 2008

Why you could consider Smalltalk/Squeak as your preferred development platform for your next educational software - Part II

In this series of articles, I will highlight the advantages of using Squeak/Smalltalk to develop educational software. At some point and based on my experience, I will compare with other development languages. The focus of this article is for educators and developers interested in software programming education applications. In these articles, don't expect to learn about Smalltalk/Squeak programming, my goal is simply to give an overall picture, based on real experience. Feedback is of course very welcome. In this article I will discuss about the Smalltalk image concept and its consequences.

The Smalltalk image

Smalltalk comes in two pieces. A binary program specific to the host architecture and the Smalltalk codes.

The Virtual machine

The virtual machine (VM) is a program specific to a physical machine and an operating system. It is in charge of transforming the code produced by the Smalltalk compiler into native machine language, so it can be executed. The great advantage of this system is to make the Smalltalk code completely portable to any machine the virtual machine was ported to. The Smalltalk compiler produces byte code, a specific machine language to the virtual machine.

The virtual machine itself is written with Squeak and recoded in C. For access to resources local to the machine (library, hardware access) or to accelerate some critical parts of Squeak, C language plug-ins are developed for the VM.

Smalltalk codes

There are three files: the squeak.sources, the squeak.changes the and squeak.image:

  • squeak.sources contains the standard source code of the Squeak classes. This source is available through the Squeak development tools.
  • squeak.changes contains the source modifications and additions done by the user in the development environment. All user modifications in the code are immediately recorded in this file, in the form of subsequent changes. All versions are kept, so it is possible to come back to earlier code versions.
  • squeak.image, this file is the strangest one for people used to file based programming. This file is a dump of the virtual machine memory. It contains all the used objects of the environments at a given moment. These objects are the windows, compiled classes, running processes, loaded classes, any kind of object in memory, and even debugging sessions. It is possible to save the image through the world menu (click on the background). Therefore it is possible to save the state of the working environment, and to restore it at any time, and even restore it on a different host with a different virtual machine.

Why should an educator will care about that?

The educator willing to develop educational software will gain productivity, both for writing code and porting their applications to several platforms.

Portability

Thanks to the virtual machine and squeak.image pair, porting an application is easy and safe. To port your application, you just need to make your squeak.image file available to the target host.

If you developed your application on host A, you were using a virtual machine for host A and you were using your standard squeak.image (or maybe your renamed it MyGreatApplication.image. To port to host B, you just need to pack virtual machine B with your MyGreatApplication.image image file, and that's it.

Productivity

From the working environment, the developer can save at any moment the state of their work:

  • They can use a tool called the workspace to write down code snippets to remember specific code examples, or to instantiate quickly objects. I very often use this to write down specific sequences of code or notes. To execute this code, I select it then type Alt+d (or Alt+p to get a printed result). When I save my image, the workspace and its content is saved as well. In the right bottom of the picture below, you can see a workspace with some snipped code I used while developing DrGeoII.
  • When debugging an application, the working environment can be saved with the opened debugger. The picture below shows a working environment where I introduced a bug in DrGeoII, the debugger is opened, When I saved the environment (therefore, a memory dump in the image file), the debugging session is saved as well.

Squeak environment

When you are writing code, and especially while improving the quality of your software, your are working within a specific context of your software. The bug does not show up immediately after you start your application. You need it to be in a given state after you performed a series of interactions with it. It can be very time consuming to do so.

Now I guess you start to understand how Squeak can save you a lot of time when you are improving the quality of your application:

  • You can save in the image the specific context which lead to bugs in your application and you can decide to come back quickly to this context as often as you need it to fix the bugs. It is a big time saver.
  • While your application is running you can fix your code, you don't need to restart your application (and recover from the bug context). This an additional time saver.

Don't search for these features in other languages, you won't find them.

In the next article about the IDE, I will develop some of the concepts presented here, for example the debugger and the possibility to fix code in running applications.

previous article - next article

Why Squeak? Part II

In this series of articles, I will highlight the advantages of using Squeak/Smalltalk to develop educational software. At some point and based on my experience, I will compare with other development languages. The focus of this article is for educators and developers interested in software programming education applications. In these articles, don't expect to learn about Smalltalk/Squeak programming, my goal is simply to give an overall picture, based on real experience. Feedback is of course very welcome. In this article I will discuss about the Smalltalk image concept and its consequences.

previous article - next article

The Smalltalk image

Smalltalk comes in two pieces. A binary program specific to the host architecture and the Smalltalk codes.

The Virtual machine

The virtual machine (VM) is a program specific to a physical machine and an operating system. It is in charge of transforming the code produced by the Smalltalk compiler into native machine language, so it can be executed. The great advantage of this system is to make the Smalltalk code completely portable to any machine the virtual machine was ported to. The Smalltalk compiler produces byte code, a specific machine language to the virtual machine.

The virtual machine itself is written with Squeak and recoded in C. For access to resources local to the machine (library, hardware access) or to accelerate some critical parts of Squeak, C language plug-ins are developed for the VM.

Smalltalk codes

There are three files: the squeak.sources, the squeak.changes the and squeak.image:

  • squeak.sources contains the standard source code of the Squeak classes. This source is available through the Squeak development tools.
  • squeak.changes contains the source modifications and additions done by the user in the development environment. All user modifications in the code are immediately recorded in this file, in the form of subsequent changes. All versions are kept, so it is possible to come back to earlier code versions.
  • squeak.image, this file is the strangest one for people used to file based programming. This file is a dump of the virtual machine memory. It contains all the used objects of the environments at a given moment. These objects are the windows, compiled classes, running processes, loaded classes, any kind of object in memory, and even debugging sessions. It is possible to save the image through the world menu (click on the background). Therefore it is possible to save the state of the working environment, and to restore it at any time, and even restore it on a different host with a different virtual machine.

Why an educator will care about that?

The educator willing to develop educational software will gain productivity, both for writing code and porting their applications to several platforms.

Portability

Thanks to the virtual machine and squeak.image pair, porting an application is easy and safe. To port your application, you just need to make your squeak.image file available to the target host.

If you developed your application on host A, you were using a virtual machine for host A and you were using your standard squeak.image (or maybe your renamed it MyGreatApplication.image. To port to host B, you just need to pack virtual machine B with your MyGreatApplication.image image file, and that's it.

Productivity

From the working environment, the developer can save at any moment the state of their work:

  • They can use a tool called the workspace to write down code snippets to remember specific code examples, or to instantiate quickly objects. I very often use this to write down specific sequences of code or notes. To execute this code, I select it then type Alt+d (or Alt+p to get a printed result). When I save my image, the workspace and its content is saved as well. In the right bottom of the picture below, you can see a workspace with some snipped code I used while developing DrGeoII.
  • When debugging an application, the working environment can be saved with the opened debugger. The picture below shows a working environment where I introduced a bug in DrGeoII, the debugger is opened, When I saved the environment (therefore, a memory dump in the image file), the debugging session is saved as well.

Squeak environment

When you are writing code, and especially while improving the quality of your software, your are working within a specific context of your software. The bug does not show up immediately after you start your application. You need it to be in a given state after you performed a series of interactions with it. It can be very time consuming to do so.

Now I guess you start to understand how Squeak can save you a lot of time when you are improving the quality of your application:

  • You can save in the image the specific context which lead to bugs in your application and you can decide to come back quickly to this context as often as you need it to fix the bugs. It is a big time saver.
  • While your application is running you can fix your code, you don't need to restart your application (and recover from the bug context). This an additional time saver.

Don't search for these features in other languages, you won't find them.

In the next article about the IDE, I will develop some of the concepts presented here, for example the debugger and the possibility to fix code in running applications.

- page 2 of 3 -