Closed LinqLover closed 2 years ago
Looks correct to me starting from Squeak 5.2. My only doubt is whether it will not break if older Squeak images attempt to load the Metacello master. Compatibility could be ensured by just moving the methods to a compatibility package, and conditionally loading that via the baseline.
...on the other hand, I just tried to install Metacello in Squeak 5.1 and out of the box it fails anyway:
Thanks for the feedback! Hm, this looks more like an unrelated VM error ...
@dalehenrich How much backward compatibility should Metacello support for older Squeak versions? The CI only runs on 5.2 and never.
Backward compatibility is ultimately up to you. Even thought the CI might run only on newer versions of Squeak .. Metacello itself should continue to function on older versions as long as those older versions are still being used ... My approach is to use platform conditional code to preserve backward compatibility as I hate to have Metacello break for anyone :)
Alright, if we can maintain compatibility, I will do so.
Here are some notes from trying to load Metacello into older Squeak versions:
Could not resolve: ConfigurationOfMetacelloPreview
error, but not with an SSL error but a sporadic only OECD error. In other attempts, the repositoryError
was simply nil. After a few attempts and restarting the image, it worked 🤷♂️Installer class >> #gemsource
first to use http://seaside.gemtalksystems.com/ss
instead of http://seaside.gemstone.com/ss
(should we port that change back to 4.3)? Here, ConfigurationOfMetacelloPreview
can be never resolved, always without a concrete repositoryError
.Apart from that, I could not figure out where a BlockContext
would ever have been created (did not find any real senders of ContextPart >> #blockCopy:
), so I will just assume that it needs to be supported.
Ah! Now I got the same SSL error as you @j4yk. In my case, using the latest VM rather than the 5.1 helped ...
Please review the addition of the new compatibility package. :-)
@dalehenrich unrelated question: Is there any reason why the installation instructions for Metacello send #get
and #load
to different Metacello
instances? Is the only reason to keep the exception handler local to the loading phase?
@LinqLover Vmware retained the gemstone.com domain name when we split off (10 years ago or so) and for a number of years they forwarded all requests to gemtalksystems.com. They stopped doing that about 5 years ago(?) and at the time I made a pass through large chunks of GLASS/GsDevKit ecosystem fixing those references ... so it's not surprising that I missed some, especially in older versions of platforms that I didn't have direct access to ...
BlockContext
Not quite sure about the that one ... If it's not sent then it isn't needed
ConfigurationOfMetacelloPreview
The EOCD errors occur when something happens to interrupt the download of an .mcz file ... and the remedy is to retry ... Metacello makes 3 attempts to donwload mcz files, since these types errors were much more common in the old days ... in fact there is a facility within Metacello where it will cycle through a sequence of different Monticello repositories in an effort to find a server that was up or download an mcz file without error :)
unrelated question: Is there any reason why the installation instructions for Metacello send #get and #load to different Metacello instances? Is the only reason to keep the exception handler local to the loading phase?
I don't recall my logic :) If I were to guess, I'd think that by making it two separate statements, it would be clearer to the folks not familiar with Metacello that once you've done a get
, it isn't required as part of the load
expression and folks who know what they are doing can optimize the expressions as they see fit :)
Thank you Dale! :-)
@LinqLover Vmware retained the gemstone.com domain name when we split off (10 years ago or so) and for a number of years they forwarded all requests to gemtalksystems.com. They stopped doing that about 5 years ago(?) and at the time I made a pass through large chunks of GLASS/GsDevKit ecosystem fixing those references ... so it's not surprising that I missed some, especially in older versions of platforms that I didn't have direct access to ...
It's not a mistake of Metacello, but of Squeak itself. I will bring up that topic on the squeak-dev mailing list.
I don't recall my logic :) If I were to guess, I'd think that by making it two separate statements, it would be clearer to the folks not familiar with Metacello that once you've done a
get
, it isn't required as part of theload
expression and folks who know what they are doing can optimize the expressions as they see fit :)
Just a follow-up question, I'm not sure if I know what I'm doing: Would you expect any change in behavior if I merge both sends together into a single script in Squeak? :)
Metacello new
baseline: 'Metacello';
repository: 'github://Metacello/metacello:master/repository';
load: #('default' 'Metacello-Help').
@LinqLover, in a fresh image that does not have BaselineOfMetacello loaded, no ... However if there is an existing BaselineOfMetacello, then the get
is necessary to pick up the (potentially) new version of BaselineOfMetacello ... which reminds that my logic may have been, that "it is good practice to use the get
command when loading a new version of Metacello, because you never know when the BaselineOfMetacello has been changed" ... and this of course applies to all Metacello projects (monticallo and git based) ... :)
Quick follow-up, I just discovered a reason for this:
In an ancient version of Metacello (retrievable through the old bootstrap code), Metacello>>#execute
invoked by Metacello>>#get
looks like this:
So all the statements for baseline & Co. were reset after #get
. Latest version of Metacello does not show this limitation any longer. So most likely, this trick is only required during bootstrapping. Thanks!
Eliminates dependency on Squeak 60Deprecated by removing obsolete extension on BlockContext. This fixes Metacello/Squeak CI and loading Metacello into Squeak 6.0beta image. BlockContext has been deprecated since Squeak 5.2 is no longer available in Squeak 6.0. See 60Deprecated-pre.5.
/cc @marceltaeumel @tom95 - if one of you approves this, I will merge this. :-)