<body><div id="__MailbirdStyleContent" style="font-size: 10pt;font-family: Arial;color: #000000">
This vision also depends on untangling all those cyclic dependencies between Morphic and the base system (i.e. Graphics).<div><br></div><div>Best,</div><div>Marcel</div><div class="mb_sig"></div><blockquote class="history_container" type="cite" style="border-left-style:solid;border-width:1px; margin-top:20px; margin-left:0px;padding-left:10px;">
<p style="color: #AAAAAA; margin-top: 10px;">Am 28.04.2020 07:26:38 schrieb keithy@consultant.com <keithy@consultant.com>:</p><div style="font-family:Arial,Helvetica,sans-serif"><div dir="auto">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.<div dir="auto"><br></div><div dir="auto">At the time I was never able to manage to get the atomic loader working with traits. This was probably due<span style="font-family: sans-serif;"> 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.</span></div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">K.</div><div dir="auto"><br></div><div dir="auto"><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 28 Apr 2020 5:43 am, keithy@consultant.com wrote:<br type="attribution"><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto">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). <div dir="auto"><br></div><div dir="auto">I.e A test release could even contain all of the packages available, and the user could unload the ones they didn't want.<div dir="auto"><br></div><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">Thus the next release would always consistently be, the previous release + bug fixes + package definitions - package unloads. </div><div dir="auto"><br></div><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">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)</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">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.</div><div dir="auto"><br></div><div dir="auto">K.</div></div></div><div><br><div class="elided-text">On 28 Apr 2020 5:01 am, keithy@consultant.com wrote:<br type="attribution"><blockquote style="margin:0 0 0 0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto">Universe's needed tools to be maintained and a server if I recall correctly.<div dir="auto"><br></div><div dir="auto">Sake/Packages imported the universe's dependencies into class methods and was very effective indeed, supported unloading and loading.</div><div dir="auto"><br></div><div dir="auto">http://wiki.squeak.org/squeak/5953<br></div><div dir="auto"><br></div><div dir="auto">Keith</div></div><div><br><div class="elided-text">On 26 Apr 2020 8:33 am, Russell Allen <mail@russell-allen.com> wrote:<br type="attribution"><blockquote style="margin:0 0 0 0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto" style="word-wrap:break-word"><div>Hi all,<br><br>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.<br><br>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.<br><br>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.<br><br>Did Lex or anyone do a post-mortem on why the Universes approach didn’t work for Squeak package management? <br><br>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…<br><br>Cheers<br><br>Russell<br><br><br><br><br></div></div></blockquote></div><br></div></blockquote></div><br></div></blockquote></div><br></div>
</div></blockquote>
</div></body>