Starting with Pharo and external source control

Here's a series of steps I'm following for using Git to store the source code of some Pharo experiments I'm working on.

I'm starting learning about Pharo. The information on this post is based on the nice Pharo and Github using Sourcetree video and an introduction to Monticello.

Configuring a repository

We can start by creating a repository that is located in the filesystem. To define configure this repository we open the "Monticello Browser" from the "World" menu and press the "+Repository" button.

We are going to select the filetree:// repository type. This is useful to store the code in separate files.

When this option is selected the UI will prompt us for the folder where the code will be stored. We are going to specify a directory where we executed the git init command . Other source control systems could be used to manage this directory since it will contain the source code as text files.

Creating a package

Now we're going to define a package where we will the create the code to be stored in source control. To define the package we open the "Monticello Browser" from the "World" menu and press the "+Package" button.

Now we can create a class inside this package. We are going to define the GameOfLifeMorph class to be in the GameOfLife category.

We are going to add a method to the GameOfLifeMorph class.

After adding these elements we can save the changes to the GameOfLife package. We can review the changes before saving by pressing the Changes button on the "Monticello" browser.

This option opens the following screen to review the changes before saving.

After reviewing the changes we can save the changes to the file system using the Save button in the "Monticello Browser" window. Now we can go to the command line to directory we selected when creating the repository and execute a git status command.

~/devel/pharo/GameOfLife$ git add .filetree GameOfLife.package/
~/devel/pharo/GameOfLife$ git status
On branch master

Initial commit

Changes to be committed:
  (use "git rm --cached <file>..." to unstage)

        new file:   .filetree
        new file:   GameOfLife.package/.filetree
        new file:   GameOfLife.package/GameOfLifeMorph.class/README.md
        new file:   GameOfLife.package/GameOfLifeMorph.class/instance/initWithRows.columns..st
        new file:   GameOfLife.package/GameOfLifeMorph.class/methodProperties.json
        new file:   GameOfLife.package/GameOfLifeMorph.class/properties.json
        new file:   GameOfLife.package/monticello.meta/categories.st
        new file:   GameOfLife.package/monticello.meta/initializers.st
        new file:   GameOfLife.package/monticello.meta/package
        new file:   GameOfLife.package/monticello.meta/version
        new file:   GameOfLife.package/properties.json

~/devel/pharo/GameOfLife$ git commit -m "First commit"

First Smalltalk experiences

Experimenting with a new programming language is always a nice experience. While preparing some snippets for a future post, I took some time to learn a little bit about Smalltalk. In this post I'm going to show a couple of this that caught my attention about the environment.

There's a lot of tutorials that available. The ones I use: Smalltalk Overview, Basic Aspects of Squeak and the Smalltalk-80 Programming Language, Objects, Classes, and Constructors, Smalltalk Style and Smalltalk collections. The Smalltalk implementation I downloaded was Squeak.

As a friend of mine once told me, one (of the many) nice things about Smalltalk is the way it handles the source code. No explicit files are used to store the code. It seems that the source of program and the IDE you are working on is part of the running program itself(!).

The System Browser is a key part of the Smalltalk environment. There you can explore existing class definitions and add or modify classes.



Another interesting element of the environment is a section called Workspace, where you can write some code to test the functionality you just implemented. For example I implemented a class that loads the contents of a CSV file. Here I'm creating an instance of this class, and I'm going to inspect its contents.



By calling the inspect method the inspect window let you explore the members of the instance.




Another interesting thing is that the environment itself helps you to write a correct program. For example in the definition of the following method I forgot to the declare the headers instance field. When trying to save the modifications the environment tells me that the headers variable is not declared and ask me if I want it to be declared as a local variable or as a instance variable.



The environment also inform you when a local variable is not used. For example when trying to save the following code:



The environment tells me:




This "live" programming environment is pretty nice. It seems that the Smalltalk environment was/is a strong inspiration for IDEs for other languages.