Montcello Package Browser

Index

• Introduction
• Opening the Monticello Browser
• Adding a Repository
• Browsing a Package
• Loading a Package
• Saving a Package

Introduction

Notice, that ST/X tradiationally uses a different packaging scheme, which is based on individual source files and package-meta-description being contained as class-methods in so called ProjectDefinition classes. These are regular Smalltalk source code files, which are compiled with the package-classes and usually bundled in a single DLL (a binary class library).

The main use of monticello is to aid in bringing Squeak code to Smalltalk/X and vice versa. Please read the hints and notes below regarding possible problems when importing and exporting code.

Opening the Monticello Browser

Adding a Repository

You'll find such expressions in the squeaksource repository, under the "Registration" headline. For example in "http://www.squeaksource.com/@pAUgNekdCaXrMHvg/c4Orvnq3", you will find the expression:

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

When selected, a repository's packages are shown in the center list.
When a package is selected in the center list, the package's versions are shown in the right list.

Browsing a Package

In the change-list, take a look for any overrides - these are methods which are already present in the image and would be overwritten when the package is loaded. The changeset browser highlights such conflicts with a red exclamation mark.

If any such are present, it is recommended to manually step through each entry in the browser and apply the change by pressing "Accept". Thus loading the package incrementally. Skip any conflicting definitions. A future version if the Monticello browser may make this a more convenient operation, if it turns out to be a common task. For now, as this needs to be done only once (when the Squeak package is loaded for the very first time) this little inconvenience should be acceptable.

Loading a Package

• Monticello uses the class category as package name, and marks extension methods in other classes via the method category (a '*' followed by the package name)
• in contrst, ST/X uses a separate package attribute for both classes and individual methods, which is not required to be related to the category.

Getting the code initially loaded into ST/X is usually the biggest obstacle in your way. Once that has been acomplished, run the unit tests, check for incompatible message sends and fix the code. Then save it as Monticello package, or check it into your ST/X source code repository.

Saving a Package

Saving is not done from within the Monticello Browser, but in a System Browser instead. There, switch the "View"-mode to "Package", select the package to be saved, and execute the "Monticello"-"Commit or Write mcz File" menu item. This saves the selected package as a Monticello package - either in a public repository or locally in the file system (use the above directory repository for that). Generated mcz packages should load immediately into another ST/X system, but may require some porting effort, when importing into Squeak or another Smalltalk dialect.

When saving to a public (aka Squeak-) repository, make sure that you check the code for compatibility issues - the browser provides some special static code checks for this (although they may not cover all compatibility issues). Otherwise, make it clear to others, that this is an ST/X-only package, by appending an "-stx" suffix to the mcz file name.

Especially, make sure that the code is syntactically compatible with the target system. In particular, this means that End-of-Line comments and Namespaces should not be used in the code, if it is ever to be loaded into a non-ST/X Smalltalk.

Copyright © 2013-2016 Claus Gittinger, all rights reserved