Beginning to Smalltalk has begun!

I've started a new blog - "Beginning to Smalltalk".

This is where I'll be putting my more polished posts, and I'll hopefully manage to put them in a sensible order.

I'm confident  Beginning to Smalltalk will become a useful step-by-step tutorial guide.

I'll continue to log my notes to myself, and my 'aha' moments, here.

Get a Smalltalk up and running

Scope: This how-to covers Squeak, Pharo, Cuis and Dolphin.  

Many of the concepts also apply other Smalltalks.

Smalltalk installations come in two principal parts.

The first part is known as the "Virtual Machine" 

More usually called the "VM".  This is the underlying engine that Smalltalk runs on.  It interfaces with the operating system of the computer that you are running the Smalltalk on, and also provides low-level services e.g. garbage-collection.

Most Virtual Machines are cross-platform.  When you use a cross-platform VM, all the Smalltalks that run on top of the VM are cross-platform too.

Cuis, Pharo and Squeak can all run on the same Virtual Machines, which run on MacOS, Windows and Linux. 

Dolphin Smalltalk is designed to run on its own Virtual Machine, which runs on Windows.

The second part is called the "image" .  

The image holds a bunch of Smalltalk code.  And it holds more, too. It holds a bunch of data.  And it holds all the information about the Smalltalk GUI as it was when the image was last saved.  Which windows the user had open, and where they were positioned.

It holds everything that Smalltalk knew about, and all information relevant to running the Smalltalk installation.

The image file can be considered to be a collection of all information about a particular installation of  Smalltalk from just before it went into hibernation.

Choosing a Smalltalk 

A little bit about each Smalltalk, and platform-specific notes

Squeak has given rise to both Pharo and Cuis, and also both the Seaside and AidaWeb web applications frameworks, along with much else.

The Scratch graphical programming language is written in Squeak, for example.

A lot of work goes in to getting Squeak running fast on the Raspberry Pi , because Scratch is written in Squeak. Scratch is a key package for teaching children to program, and the Rasberry Pi is a platform designed for teaching children to program. This work is done so that Scratch will run fast on the Pi, but it has a very useful side-effect for people who want to use Smalltalk on the Pi.

Cuis is a fork of Squeak, intending to radically simplify the numbers of libraries in the distribution, and radically simplify the way GUIs are drawn and coded.

It contains only 500 classes, compared to the 2,300 in Squeak and the 5,000 in Pharo.

This makes it a good candidate for understanding a Smalltalk from top to bottom. Potentially it might lead to speedy performance.

Pharo is a fork of Squeak where the focus is on extending the functionality and ability of Squeak, without much regard to backward compatibility.  Considerable effort goes in to making sure that Pharo always remains a capable platform for the Seaside web server.

Pharo evolves rapidly, with vast majority of the additional functionality added by academic computer science research groups.  Nonetheless, the Pharo management team intend it also to be a useful platform for commercial application developments - as can be seen by the effort that goes into keeping the GUI and desktop themes looking clean and professional.

Cuis, Pharo and Squeak can all run on the same Virtual Machines, which run on MacOS, Windows and Linux. 

Squeak 5.0 includes extensive optimisations for when it runs on the Raspberry Pi.

Dolphin Smalltalk is designed to run on its own Virtual Machine, which runs on Windows.

The key advantages are that Dolphin is designed to provide a Windows native look-and-feel; and a working system can be packaged up as a .exe install file. This means there is no learning curve for Windows end-users when they are installing an end-user app written in Dolphin Smalltalk. 

Dolphin Community Edition cannot store code and classes to repositories in the cloud, or automatically retrieve packages from the internet.  Downloading packages that other people have already written for you to use from the internet is really useful as you start out. So you'd be better to download Squeak or Pharo, to start out with - unless you really want native look-and-feel from day 1.    

Downloading packages from the internet is available in the paid-licence version of Dolphin.  I have not yet used this, so cannot vouch for how well it works.

So unless you want to learn only Windows-GUIs, I personally advise you to start on a different Smalltalk, and then later come back and learn the Windows-GUI facilities in Dolphin, once you are used to Smalltalk.

If you want to start writing web applications as you learn, then you can use a package called Seaside, which has a once-click installer for Pharo and Seaside, all in one step. 

Seaside will also run on Squeak, but I don't know of any current All-in-one installer for it.

Licencing Issues

Cuis, Pharo and Squeak all use the MIT licence.  This allows commercial use, and is also GPL-compatible.

Dolphin's licence allows you to distribute the DLLs and the Dolphin VM as an integral part of executable applications created by you using Dolphin Smalltalk. 

Download a  Smalltalk

With all Smalltalks

If you have a specific pre-existing application, package or library you want to use, you may need to use an older version.  If you just want to get started with the latest version, choose the latest version.

On Windows

All of the cross-platform Smalltalks can be installed as a 'portable' installation.  You can copy the installed folder to anywhere on your PC and the Smalltalk will still run. The folder contains all the necessary code and .dlls to run successfully.

For specific Smalltalks

Cuis:

Cuis currently has you download the Smalltalk VM and the Cuis image separately. Probably best to start with one of the others, then come back to Cuis once you have got the hang of  VMs and Images.

The Cuis Image is available from
https://github.com/Cuis-Smalltalk

Any Squeak VM should work with Cuis. 

Dolphin:

http://www.object-arts.com/downloads/downloads.html

At time of writing (2015-11-11), there is one download link
Dolphin X6.0 (Community and Pro Editions)

This downloads a .exe file.   (And the first time it runs, it will prompt you to email for a (zero-cost) Community edition licence number). 

If later you wish to prepare .exe files for your application's end-users, you can upgrade to the Pro Edition for a fee of ~£160(GBP) or approx.  $225(USD)/€225(EUR)

Pharo: 

http://pharo.org/download 

At time of writing (2015-11-11), the site offers Pharo 4.0 via three download links, one for each of MacOS, Windows and Linux. 

MacOS : http://files.pharo.org/platform/Pharo4.0-mac.zip

Windows : http://files.pharo.org/platform/Pharo4.0-win.zip
Linux : http://pharo.org/gnu-linux-installation

Once you have a little experience with VMs and images, you can download the latest Pharo 5.0 development image from  http://files.pharo.org/get-files/50/pharo.zip

Seaside

http://www.seaside.st/download/pharo

Seaside One-Click Experience 3.1 (36 MB) For Windows, MacOS and Linux

Squeak:

http://squeak.org/downloads/



At time of writing (2015-11-11), there are two versions listed under "Quick Download"
All-in-One (Spur)  - Version 5.0
All-in-One (Non-Spur) - Version 4.6

"Spur" / "Non-Spur" refers to the Virtual Machine (VM) included in the download.  Cog is currently the most prevalent VM in the Squeak/Pharo/Cuis worlds.

A recent improvement to Cog was labelled "Spur".  So '(Spur)' means that the install includes the latest Cog VM with added Spur.  '(Non-Spur)' means that it includes a slightly older version of the Cog VM. 

To start A Smalltalk

Once you have the files unzipped and installed on your computer: 

For Cuis

On Windows
Open the folder with the VM in it.
Drag the Cuis .image file you want to use and drop it on the VM

On Linux

To be determined. If anyone knows how, please let me know, and I'll include it here. 

on MacOS

To be determined. If anyone knows how, please let me know, and I'll include it here. 

For Dolphin (Version 6)

On Windows 
Open the folder you have installed Dolphin to. 
Drag the 'Professional (Fresh Install).img' file and drop it on Dolphin.exe

For Pharo 4.0

on Windows
Open the folder you have unzipped Pharo to.
drag the .image file you want to use and drop it on Pharo.exe

On Linux
Move to the folder you have unzipped Pharo to
In a shell or terminal window, type:
./PharoS Pharo.image &

on MacOS 

To be determined. If anyone knows how, please let me know, and I'll include it here. 

For Seaside 3.1

on Windows 
Open the folder 
Double-click on Pharo.exe

On Linux 
To be determined. If anyone knows how, please let me know, and I'll include it here. 

on MacOS 

To be determined. If anyone knows how, please let me know, and I'll include it here. 

For Squeak 5.0

on Windows
Open the folder you have unzipped Squeak to.
Double-click on squeak.bat

on Linux
navigate into the Squeak folder 
In a shell or terminal window, type:
bash squeak.sh

on MacOS

To be determined. If anyone knows how, please let me know, and I'll include it here. 

I imagine you double-click on Squeak-5.0-All-in-One.app



Version 0.9, published 2015-11-12

In Progress : How to use Versionner in Pharo Smalltalk 4

What is Versionner For

Versionner is for helping to automate writing the ConfigurationOf<PackageName> for a package or project, i.e. it assists you in creating Metacello configurations.

A Metacello configuration is a managed code package, which explicitly defines the dependencies between one package (perhaps your own package that you are developing) and other packages.

n.b. Groups in Metacello/Versionner are unrelated to groups in Nautilus/the System Browser.

The "MyKillerApp" example

MyKillerGame is a project with several loadable Pharo code packages:
  MyKillerGame-Core
    - containing base classes with the domain model of your application
   MyKillerGame-UI-Widgets
    - a package providing own UI widgets for your application
   MyKillerGame-UI-Board
    - a package containing classes with the board of your killer game, ...
   MyKillerGame-Tests-Core
    - a test package with SUnit tests that test classes in the MyKillerGame-Core package
   MyKillerGame-Tests-UI-Widgets
    - a test package with unit tests for MyKillerGame-UI-Widgets
   MyKillerGame-Tests-UI-Board
    - a test package with unit tests for MyKillerGame-UI-Board

So with this structure:
 - the code is split into a domain model package and UI code package
 - the test are separated from the code packages, which makes it easier to deploy the completed KillerGame out to end-users, later on.  Having the tests in separate packages allows you to either load them for development or leave leave them unloaded in the production version

 - you have a test package for each implementation package

Working through the Example with Versionner

Open Versionner
  - in Pharo 4 .  left-click (i.e action-click) the Pharo desktop, World Menu | Tools | Versionner
  - in Pharo 5 .  ???

Versionner opens up a list of configurations in the image
   (is that the meta-repository list of configurations that the image knows of? i.e. the one which is shown in the Configuration Browser?
       or
    is that the list of configurations which have already been loaded into the image?)

Two initial options:
"New project" - Create a new configuration for your project
"Load Project" - Load a configuration from a repository
and a third, greyed-out option
"Open project"  (which can also be achieved by double-clicking on a package listed in the browser pane

Create the new project
Create a new configuration project "MyKillerGame", using "New project"
New project opens up a "Name of the new project" dialogue box, followed by an "Author identification" dialog, creates a development version of the project, and then brings up the main Versionner window

It also
   automatically defines a class ConfigurationOfMyKillerGame.
      (This will hold all the Metacello load definitions),
   automatically creates a package "ConfigurationOfMyKillerGame".
      (This package is automatically placed in the "Configurations" group in the Packages pane of the Nautilus/System Browser).

Once the new project has been created, you can update the development version whenever you need to, using 'Save to Development'.

Define the package dependencies

Next,  you need to define the package dependencies in the main Versionner window - the Dependency Browser.

The dependency browser shows you the dependencies of the already-loaded packages. If you reference a class in another package from within your project, it will be displayed in dependency browser

- add the necessary package
- add loading dependencies
     the three packages of tests are each dependent on the package they test, because the test classes need the classes to test, so
        - "MyKillerGame-Tests-Core" is dependent on the classes in "MyKillerGame-Core"
        - MyKillerGame-Tests-UI-Widgets requires MyKillerGame-UI-Widgets
        - MyKillerGame-Tests-UI-Board has a dependency on MyKillerGame-UI-Board
        - MyKillerGame-UI-Board requires MyKillerGame-UI-Widgets
             (as the game board requires fancy widgets )
        - MyKillerGame-UI-Board requires MyKillerGame-Core
             (as the game board requires the game's domain model/non UI logic)

Once these are defined, each and every package has all dependencies on any package that needs to be
loaded before the package itself works.  And if every package within a project has all its dependencies defined, then the project as a whole has all its dependencies defined.

So we have one core package (with the game logic), two packages for UI related stuff,  and three packages related to testing.

We can then group them in Versionner by adding Metacello Groups:
   "Core" - containing the "MyKillerGame-Core" package
    "UI" -  containing the "MyKillerGame-UI-Board" and "MyKillerApp-UI-Widgets" packages
    "Tests" - containing "MyKillerGame-Tests-Core", MyKillerGame-Tests-UI-Widgets" and "MyKillerGame-Tests-UI-Board"

This means that later you can load the "Core" group specifically, and Metacello will load just the packages listed in this group.  Likewise, you could just load the "Tests" group. Metacello would then will load the packages in this group and the packages that they were defined as dependent on - their required packages.

There are two pseudo [Versionner?] groups
 "all" - you define this, so it will load all packages related so your project.
 "default" -> Monticello loads this group is by default
                             (i.e. if you do not give another group or package to load).

So in our example we can either
   put all packages into the "all" group
       or
   put the group "Core","UI", "Tests" and tests into the [seems to be something missing here] group
        (This is the easier and more logical approach of the two)
            N.b. Groups can include packages and can also include other groups.

"all" should include all packages, as the name suggests.  It's up to you how you define the "default".

For the MyKillerGame, the two best approaches are either
  a) define "default" group to have  group "all" (so by default anything is loaded for development)
      or
  b) define "default" group to have groups "Core" and "UI" (so by default anything is loaded for deployment, without tests)

Once the project repository is set up, you can directly commit the ConfigurationOf<PackageName> to the repository using "Commit the Project"?' There is no need to upload the changed  "ConfigurationOfXXX " package using the Monticello browser.  You can directly upload it into the repository from Versionner.

[Does this mean the package and project also do not need to be Monticello'd?  That committing only the ConfigurationOf<PackageName> automagically stores the project and the packes within the project to their repositories?]

=========

Beyond here lies Work-in-progress

=========

Open some of the configuration classes in the browser and try to understand them.

Pharo 4:   load from my ConfigurationBrowser
Pharo 5:   load from the new CatalogBrowser that Esteban wrote. I polished it a little bit but
                     also extended Spotter to be able to load configurations from Catalog.

Example: In a fresh Pharo 5 image hit SHIFT + Enter (to open Spotter) and enter "DesktopMan", dependening on
                     network latency  you quickly get "DesktopManager" project. If not wait a few seconds.
                     If you hit enter the project will be loaded. No need to open the Catalog Browser anymore. :simple_smile:

https://www.youtube.com/watch?v=zpLY7uQnPsg

When the project is loaded just hit SHIFT+Enter again to open spotter and enter the class
name ConfigurationOfDesktopManager. Hit enter and Nautilus will open on the class
(the package is not selected by default but this is a known bug)

Check out the baseline defined in class ConfigurationOfDesktopManager.
Here we have two simple packages
    "DesktopManager-Core" (implementation)
       and
    "DesktopManager-Tests-Core" with the tests.

There is a dependency in the spec defined from "DesktopManager-Tests-Core" requiring "DesktopManager-Core" as the test package need the implementation package with the code to test.

There is also a group "Core" and a group "Tests".
The pseudo group "default" is defined to load the groups "Core" and "Tests".

The Baseline "0.1-baseline" defined in #baseline01: just defines depencies (=from which the load order is calculated by Metacello) and the groups.

Beside the Baseline there is also a real initial version "0.1.0" defined in #version010: method using this baseline and defining the appropriate versions of each package that fit together.

Semantic Versionning (http://semver.org/) is recommended - then you'd version you project with 0.1.0, 0.2.0, 0.3.0 etc, as you define milestones.

Some users of "MyKillerGame" might not be interested in a specific version. They just want to have a stable thing to work with.

Others might want to use the latest development version, which might well be unstable

This is what developer-defined symbolic versions like #stable or #baseline are for.

#development (usually references the latest baseline. This way, the latest version of each package is loaded in the right order).

see also:
Videos
Versionner
https://www.youtube.com/watch?v=S5Dbmmln8tA
Versionner:
http://smallworks.eu/web/blog/2015-04-30-use-versionner

Versionner - Commit Tool for Pharo (2/2)
https://www.youtube.com/watch?v=SxTpuSHNh2E
Dependency Managment for Pharo
https://www.youtube.com/watch?v=cFRJDuWL-Q0

Books
http://pharobooks.gforge.inria.fr/PharoByExampleTwo-Eng/latest/Metacello.pdf

Github
https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloUserGuide.md
https://github.com/dalehenrich/metacello-work/blob/master/docs/MetacelloScriptingAPI.md
GitHub  dalehenrich/metacello-work
metacello-work - Metacello is a package management system for Smalltalk

=====


define dependencies to other projects (for instance if you use JSON you might want to define a dependency to NeoJSON)

If the config is done right it will load NeoJSON first and then your code

versionner also allows to mark a combination of packages as "Version x.y.z"

=====

https://youtu.be/S5Dbmmln8tA

Once the development version is complete, you can 'Release version'.  Release versions are frozen - further changes to them are not allowed.

Beginning to SmallTalk. 1. Hello World

Transcript show: 'Hello  World'

Which means:
On a Transcript object, show the string 'Hello World'

The Transcript object is a display window, logging results and displaying them.

If we send a specific string to a Transcript, with a polite request to show it, the Transcript object will (hopefully) respond appropriately.

So
   Transcript (the class) is asked to
   show:
   'Hello World'

We can ask politely in three different ways in Smalltalk - i.e. we can send three types of message in Smalltalk.

The message can be a single part. Known as a  'Unary' message.

The message can have two parts - a 'Binary' message.

The message can have multiple named parts - a 'keyword' message.

Keyword messages come in paired parts.
A request name or a parameter name - the keyword -
   followed by
an argument (aka a parameter)

The request's (or message's) name has a colon at the end of it.

The argument is an object.  (Or to be pedantically technical, the object's given name.)

Because everything in Smalltalk is an object, the argument (or parameter) can be as simple or complex an object as you like.

It can be as simple as an integer number (as all the integers are objects).

It can be as complicated as a huge agglomeration of other, smaller objects.

Perhaps an object representing a person, with strings for the person's name, and age and date of birth and place of birth, and lists of every type of medicine the person has ever been prescribed, and when, and a set of schedules of when the patient should be taking their current medication, and freeform notes on what the next treatment steps might be, and a running count of the number of face-to-face treatment visits the person has had, and a dictionary of the person's symptoms, and, and, and

You can even create unnamed objects on-the-fly, complete with new code to execute, and hand these over as parameters.

These spontaneous, anonymous objects are known as 'blocks', and they'll become idiomatic later on.

So Transcript show: 'Hello World'
is a keyword message.

Transcript is the object receiving the request.  In this message, Transcript is the receiver.

show: is the keyword.
We can tell it's the keyword in two ways.
It's between the receiver and the argument.
It ends in a colon.

'Hello World' is the argument or parameter.  It's an object.  In this case, a String object.

Keyword messages can have several keywords, e.g.

theAuthorsPetExampleOfAnObject 
   firstKeyword: anObjectBeingUsedAsAParameter
   secondKeyword: anotherObjectBeingUsedAsAParameter
   thirdKeyword: yetAnotherObjectBeingUsedAsAParameter .

This message has a receiver, an object which receives the message.
The message has three keywords.
The message has three parameters.

Messages are also known as methods.  Strictly speaking, a message is a request, and a method is how an object responds to the specific request.

For instance, if a boss says 'Jump!', perhaps the response they are looking for is for you to say 'How high?'

The message they have sent you  is 'Jump!'.  Your method of responding to a 'Jump!' request may be to say 'How high?' back.  Perhaps your chosen method of responding to a 'Jump!' message is to leap up into the air.

In any event, we can use the word's 'method' and 'message' somewhat interchangeably.  One thing's message send is another thing's method of responding.

So the method's name in our example is
   firstKeyword:secondKeyword:thirdKeyword:

To write the method's name out in full, we'd place a pair of >'s to separate the end of the name of the Class of objects from the start of the name of the first of the keywords.

AuthorsPetExampleOfAnObject>>firstKeyword:secondKeyword:thirdKeyword:

The convention is to have object's names and methods begin with a lower-case letter, and have Classes and their methods have names beginning with Upper-case letters.  In the wild, Classes will always have an InitialUpperCaseLetter, but their Class methods often don't.

To execute the code, open up your Smalltalk, e.g. Pharo, Squeak, Dolphin, Cincom, Cuis  Smalltalk.

If you have a two or three button mouse, click the left-button on the window backdrop.
If you have a single button mouse, click on the window backdrop.  (This type of click is called an action-click).

This brings up the World Menu.  Select Transcript.

Action-click again, and select Workspace (which is named Playground, in some Smalltalks).

Type in the code in the Workspace.  Select it.  Right-click on the highlighted text, if you're using two (or three) button mouse.  (If you are using a single button mouse, there will be (a) key(s) to press a the same time)

Then select 'Do it'.

Hello World will appear in your Transcript window.