Amber Blog

Amber Smalltalk and more

Cloning All Amber Repositories

Let’s say you are a developer working on Amber itself and you need to switch to a new development computer. You’ll then find yourself in the need of cloning all Amber related repositories.

As of now you will most probably go through the repository list from https://github.com/amber-smalltalk, select the Git URL and issue a git clone. It is a bit of work, yes, but currently there are only 3 to 4 repositories.

Now imagine that a new release is pending and all repositories need to be brought up to date to test the latest features. So you will go to each directory and do a git pull. Yeah, not much you say.

So let’s take a look into the future of Amber where the amount of different repositories will have increased. If the amount of repositories exceeds 4 to 5 the synchronisation of all of them gets quite boring and is a lot of manual work.

Exactly this situation was encountered by Google during the development of Android. As a solution they created the repo tool which is built on top of Git to manage multiple repositories. However, using repo is not limited to Android itself.

Starting from today a repo configuration for Amber repositories is available at https://github.com/mkroehnert/amber-repo-config.git. How to install repo and how to clone the Amber projects is explained in more detail in the README file of the repository. But basically it boils down to the following commands:

bash
1
2
3
4
5
6
7
8
9
> mkdir amber-smalltalk

> cd amber-smalltalk

> repo init -u https://github.com/mkroehnert/amber-repo-config.git

> repo sync

> repo start master --all # can be omitted once an initial checkout has been done

Afterwards, it will be as easy to update all repositories at once by running repo sync inside the amber directory. But be aware that repo sync will do a rebase of the current branch onto origin/master. Therefore, I’d advise you to do a checkout of the master branch in all repositories with repo forall -c "git checkout master" before actually doing a sync.

One last note for Mac users: the directory which is used for synchronisation /MUST/ be located on a case sensitive file system (the harddrive is usually formatted as case preserving). If you don’t want to reformat your whole computer it is possible to use disk images (DMG’s) which are formated with a case sensitive HFS+ file system.

Since repo is a tool of its own built on top of Git it has a learning curve for itself. So use it at your own risk ;–). But if you are already very familiar with Git you might find repo very handy once you got to know how it works.

Welcome

Hi, I have been involved with Amber Smalltalk for a while now. All started with my first reported issue #125 about two years ago shortly after the 0.9.1 release. By now we have almost reached 700 issues on GitHub, split the Amber repositories into multiple projects, moved to a GitHub Organization, and the 0.12.0 release is pending. Now I thought that it is about time to start writing about the ongoings in the project. The main question was about which system to use and where to publish.

After considering some options the choice fell on GitHub pages and then Octopress came into play. A big plus of Octopress is the integration of a variety of useful third party services. With plain GitHub pages a lot of handcrafting would have been necessary to achieve the same functionality.

Going back to Amber Smalltalk, my main contributions so far include a rewrite of the Amber commandline compiler in Node.js, introducing a Grunt.js based build system, and enhancing the Amber server which is used for development.

Previously the Amber commandline compiler was written in a mixture of Bash and Node.js. The main part of the compiler is written in Amber itself but reading files and processing commandline options and so on was done in Bash. Since Amber compiles to JavaScript a logical step was to transform the complete process into a Node.js script and take advantage of the async capabilities of Node.js.

The idea to switch from the Makefile based build system to Grunt.js originated from a pull request by johnnyt which he closed before it was applied because it wasn’t ready yet. After switching the commandline compiler to Node.js integrating it with Grunt.js became almost trivial. By now we are running on Grunt.js 0.4 and the build system is also used to the test cases on Travis.

The Amber server has seen some improvements regarding commandline parameters. The following parameters are available:

bash
1
2
3
4
5
6
7
8
9
10
11
# change listening host (default: 127.0.0.1)
--host
# change listening port (default: 4000)
--port
# use basic HTTP authentication: NOT recommended for production
--username
--password
# path to use as root directory (default: ./)
--base-path
# specify the file to serve instead of a 404 page
--fallback-page

Additionally, both Amber repl (read evaluate print loop) and server have been integrated into one tool for Amber 0.12.0. They can be started as follows:

bash
1
2
./bin/amber repl
./bin/amber serve [arguments as listed above]

For now that’s all folks. Expect irregular updates in the future.