This vision also depends on untangling all those cyclic dependencies between Morphic and the base system (i.e. Graphics).

Best,
Marcel
Am 28.04.2020 07:26:38 schrieb keithy at consultant.com <keithy at consultant.com>:
Just to finish describing the vision. An important part of this vision was to enable package loading and unloading to be atomic. Thus the ultimate goal would be to enable morphic to be unloaded atomically, and replaced atomically with an alternative UI framework (morphic 3?) Prior to bringing up the UI.

At the time I was never able to manage to get the atomic loader working with traits. This was probably due to what some characterised as my "mediocre" programming skills. In truth my skills are more in the higher level process design, than down in the bits.

I have no idea if atomic loading/unloading ever came to fruition but it would have been a fundamental part of moving squeak on from the morphic etoys tangle that was, and a perfect compliment to sake/packages. Which incidentally also worked in cuis and pharo equally well because it didn't depend on any UI.

K.



On 28 Apr 2020 5:43 am, keithy at consultant.com wrote:

The (now 10 year old) theory was to have a clear way to declare packages, for loading and unloading with their dependencies. Then more parts of the monolithic squeak image could be seamlessly moved into optionally unloadable packages. (Argueably The opposite of traditional package management). 

I.e A test release could even contain all of the packages available, and the user could unload the ones they didn't want.

An alternative basis for developing the image was defined and used for a year This consisted of defining patches, mainly bug fixes enumerated by the mantis bug tracker. 

Thus the next release would always consistently be, the previous release + bug fixes + package definitions - package unloads. 

The idea was that the development of the image was to be changed from being based on a moving target (an always evolving trunk repository with multiple contributors tripping over each other) to a different model. The new model was based on a known fixed target, namely the previous release, plus an evolving set of blessed fixes, and package definitions that could be tested by everyone in their production images. 

Thus any project or fork would have the ability to keep up to date with latest by cherry picking the relevant fixes, and package definitions, into their current build or working image, rather than having to wait for the next fanfare release and port their code once every 2 years. 

This process was designed at the outset to enable parallel development of multiple forks/images, anticipating that as more packages get unloaded from the monolithic image, their maintainers need to be able to maintain those packages for multiple destinations. Via sake/packages You could publish a package together with, patches for Pharo, or cuis or cobalt, or even squeak 3.7 and all of those targets could use the same process. (via Installer)

A limitation of squeakmap and universe's was that each package definition is centrally managed. Sake/Packages on the other hand allowed each user, fork, or project to maintain their own subclass of package definitions. Thus the knowledge of what works where, and what patches are needed for deployment in each fork/project is provided by the actual users. Package maintainers can see how their package is actually used, in different contexts. E.g. magma when used with seaside, was not a use case that Chris regularly tested himself, but the visibility of how it is used provides feedback to the package maintainers.

The driving motivation for this was a realisation that it was hard for any commercial work to keep up to date, and larger projects inevitably got left behind in an older image, because the previous release teams were too busy making a great new revolutionary incompatible release, rather than supporting the evolution of what is already in use. This killed many potentially interesting projects.

I myself gave up on a pier/seaside/magma based web shop (before shopify.... Sigh) and you could argue that gjallar was another victim. Since the return to trunk based development, it became clear that squeak wasn't ever going to be a viable platform for commercial use because maintaining simple packages was being made harder not easier.

K.

On 28 Apr 2020 5:01 am, keithy at consultant.com wrote:

Universe's needed tools to be maintained and a server if I recall correctly.

Sake/Packages imported the universe's dependencies into class methods and was very effective indeed, supported unloading and loading.

http://wiki.squeak.org/squeak/5953


Keith

On 26 Apr 2020 8:33 am, Russell Allen <mail at russell-allen.com> wrote:

Hi all,

Back in the Jurassic period, somewhere around Squeak 3.7, there was something called “Package Universes” which I think was done by Lex Spoon, although my memory is a little hazy.

It attempted to simplify package management by reifying the concept of groups of packages which worked together - a ‘Universe’. Each Squeak image would then be within a Universe, and could be assured that packages wouldn’t conflict in that context.

The Package Universe browser isn’t in the latest Squeak, so I’m assuming that the approach was abandoned at some point in the last decade or so.

Did Lex or anyone do a post-mortem on why the Universes approach didn’t work for Squeak package management?

I can’t immediately see what replaced it in the current Squeak, but I haven’t used Squeak for a while so don’t really know what I’m doing…

Cheers

Russell







-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20200428/146f2915/attachment.html>