OFSET Planet (English only)

To content | To menu | To search

Tag - programming

Entries feed - Comments feed

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.

Thursday, April 17 2008

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

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.

Have you noticed in my title I wrote development platform and not programming language. Indeed Smalltalk, and Squeak particularly, is not only a language it is also an environment to write code. This aspect is rooted to the whole history of Smalltalk in the 70s at the Xerox Parc, where Alan Kay's team created several versions of Smalltalk in a specific graphical user interface environment with a mouse and windows. It came with unique features such as a virtual machine and an image architecture, a full object oriented and reflexive language.

Why an educator will care about that?

Some key aspects in Squeak/Smalltalk I find the most interesting when writing educational applications are:

  • the GUI, called Morph
  • the Smalltalk image, an unique environment to test your ideas and instantly save the state of your work
  • your application is portable to many OS architectures
  • a nice integrated development environment (IDE)
  • an unique way to debug your application
  • a rich set of interactive and multimedia classes
  • a skilled community

I will develop these points with concrete examples. One point per article. I will first discuss the Morph GUI system.

The Morph GUI

In this GUI framework, a Morph is a graphical unit. It can be a bitmap, a geometric object as a segment, an ellipse, a polygon, a character, a string, a video canvas, etc. A Morph can be inserted into another one, with or without layout. All the graphical objects in Squeak are assembled Morph. Morph can be manipulated interactively by the user. One helper for such manipulation is the halo system.

The halo

The first special feature a user meets with Morph is the halo system. Within the Morph GUI, Halo is a collection of object handles surrounding any kind of graphical objects such as windows, button, graphic, text strings, etc. The halo can be called on demand.

Morph halos

There are various functions like duplicating, resizing, rotating, repainting, etc. I won't be explaining further, several starter guides are doing it. The halo strong point, is being able to let the user manipulate the object freely. If you design an educational application with Squeak, keep in mind the user will be empowered by the halo system, so be sure to consider the halo effect when designing your software.

As I just explained, Morph can be physically manipulated, assembled or disbanded by the user. But this is not the end of the story, Morph can be logically manipulated and interlinked through a graphical scripting system.

Squeak scripting

In the halo, one handle is responsible for opening the viewer (the blue eye on the left). A viewer presents a set of graphical commands. Commands are about physical or logical characteristics regarding a Morph. Command work is input or output.

Not only can the user assemble various commands from one Morph, but he can also put together commands from several Morphs. So it it possible to link their behaviors.

In Dr. Geo II, I decided to use Morph as my graphical canvas underneath. Indeed, I wanted to take advantage of the Morph features for: inter-inclusion of Morph external to Dr. Geo II into it, and vis-versa, and also to give the freedom to the user to use Squeak Scripting with Dr. Geo II. It really empowers your application to do so.

In the screen shot bellow, Squeak scripting is used to attach the y-axis position of a Dr. Geo II Moprh point to a Morph slider: when the user moves the slider, the Dr. Geo's point moves accordingly. Not only do the point and the slider not know about each other, but this logical relation is performed at the user level.

Squeak scripting

Programming the Morph

What we described in the two previous sections was about how the Morph GUI empowers the end user. On the other hand, the Morph GUI programmer is able to:

  • reuse existing Morphs to fit his needs. Reuse, can be: aggregate several Morphs in a new type of Morph, extend the behavior of a Morph,
  • write from scratch a new Morph. Writing a new Morph is fun because you are completely free to decide how it will behave and look (with drawOn: method).

Bellow are a few examples of Morph I wrote through reuse and modification of previous ones, or from scratch.

Pyramide de nombre PythagorasTable Rectange de point Dice.png

A few years ago, Python was becoming my favorite programming language to write educational application. I wrote a few articles on this topic (article 1, article 2, article 3) . The biggest advantage was the ease of use of the programming language. Using GTK+ with Python was pretty easy once you knew about it. However as the documentation about the GTK+ Python binding was mostly inexistent, I had to read the GTK+ C documentation and the Python source code binding then guessed about how to use it in Python. It was pretty do-able but quite time consuming. Funnily enough, I happened to do the same thing with Squeak and the Morph GUI as the documentation was also very thin, but thanks to the Smalltalk reflective nature, it is so much easier to find, to test and to understand the necessary features. This is another advantage which empowers the programmer this time. I will explain it later when discussing the Smalltalk IDE.

Why Squeak? Part I

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.

next article

Have you noticed in my title I wrote development platform and not programming language. Indeed Smalltalk, and Squeak particularly, is not only a language it is also an environment to write code. This aspect is rooted to the whole history of Smalltalk in the 70s at the Xerox Parc, where Alan Kay's team created several versions of Smalltalk in a specific graphical user interface environment with a mouse and windows. It came with unique features such as a virtual machine and an image architecture, a full object oriented and reflexive language.

Why an educator will care about that?

Some key aspects in Squeak/Smalltalk I find the most interesting when writing educational applications are:

  • the GUI, called Morph
  • the Smalltalk image, an unique environment to test your ideas and instantly save the state of your work
  • your application is portable to many OS architectures
  • a nice integrated development environment (IDE)
  • an unique way to debug your application
  • a rich set of interactive and multimedia classes
  • a skilled community

I will develop these points with concrete examples. One point per article. I will first discuss the Morph GUI system.

The Morph GUI

In this GUI framework, a Morph is a graphical unit. It can be a bitmap, a geometric object as a segment, an ellipse, a polygon, a character, a string, a video canvas, etc. A Morph can be inserted into another one, with or without layout. All the graphical objects in Squeak are assembled Morph. Morph can be manipulated interactively by the user. One helper for such manipulation is the halo system.

The halo

The first special feature a user meets with Morph is the halo system. Within the Morph GUI, Halo is a collection of object handles surrounding any kind of graphical objects such as windows, button, graphic, text strings, etc. The halo can be called on demand.

Morph halos

There are various functions like duplicating, resizing, rotating, repainting, etc. I won't be explaining further, several starter guides are doing it. The halo strong point, is being able to let the user manipulate the object freely. If you design an educational application with Squeak, keep in mind the user will be empowered by the halo system, so be sure to consider the halo effect when designing your software.

As I just explained, Morph can be physically manipulated, assembled or disbanded by the user. But this is not the end of the story, Morph can be logically manipulated and interlinked through a graphical scripting system.

Squeak scripting

In the halo, one handle is responsible for opening the viewer (the blue eye on the left). A viewer presents a set of graphical commands. Commands are about physical or logical characteristics regarding a Morph. Command work is input or output.

Not only can the user assemble various commands from one Morph, but he can also put together commands from several Morphs. So it it possible to link their behaviors.

In Dr. Geo II, I decided to use Morph as my graphical canvas underneath. Indeed, I wanted to take advantage of the Morph features for: inter-inclusion of Morph external to Dr. Geo II into it, and vis-versa, and also to give the freedom to the user to use Squeak Scripting with Dr. Geo II. It really empowers your application to do so.

In the screen shot bellow, Squeak scripting is used to attach the y-axis position of a Dr. Geo II Moprh point to a Morph slider: when the user moves the slider, the Dr. Geo's point moves accordingly. Not only do the point and the slider not know about each other, but this logical relation is performed at the user level.

Squeak scripting

Programming the Morph

What we described in the two previous sections was about how the Morph GUI empowers the end user. On the other hand, the Morph GUI programmer is able to:

  • reuse existing Morphs to fit his needs. Reuse, can be: aggregate several Morphs in a new type of Morph, extend the behavior of a Morph,
  • write from scratch a new Morph. Writing a new Morph is fun because you are completely free to decide how it will behave and look (with drawOn: method).

Bellow are a few examples of Morph I wrote through reuse and modification of previous ones, or from scratch.

Pyramide de nombre PythagorasTable Rectange de point Dice.png

A few years ago, Python was becoming my favorite programming language to write educational application. I wrote a few articles on this topic (article 1, article 2, article 3) . The biggest advantage was the ease of use of the programming language. Using GTK+ with Python was pretty easy once you knew about it. However as the documentation about the GTK+ Python binding was mostly inexistent, I had to read the GTK+ C documentation and the Python source code binding then guessed about how to use it in Python. It was pretty do-able but quite time consuming. Funnily enough, I happened to do the same thing with Squeak and the Morph GUI as the documentation was also very thin, but thanks to the Smalltalk reflective nature, it is so much easier to find, to test and to understand the necessary features. This is another advantage which empowers the programmer this time. I will explain it later when discussing the Smalltalk IDE.

page 2 of 2 -