I would consider separating the installation into several change sets all stuck in a SAR. You can then load them in the proper order, and/or have conditional loading based on Squeak versions. Is SAR available for Squeak 3.0? (Documentation problem: my network connection is down again. IT services are getting ready for the beginning of semester, and this seems to make my off-campus Web access disappear from time to time.) Having a whole bunch of change-sets just to get things done in the order I did them seems a little, no, extremely unfriendly of Squeak.
> Q4: I'd like the change set to be usable in 3.0, 3.2, and 3.4. > Is it OK if a change set file contains directives to remove > methods that don't exist? How do I make one remove a method from a > _class_ that might not exist in some version? I'd stick this in a preamble or postscript, generally, or in a separate change set for that specific version. Details, please. I know what preambles and postscripts are and how to create them, but WHAT do I stick in there? What MAY I stick in there?
If Squeak can't remember what order I did things in, letting me explicitly tie the changes into some sort of order and remembering _that_ might be a good idea.
On Tuesday 18 February 2003 09:34 pm, Richard A. O'Keefe wrote:
I would consider separating the installation into several change sets all stuck in a SAR. You can then load them in the proper order, and/or have conditional loading based on Squeak versions.
Is SAR available for Squeak 3.0?
I don't know. I suspect it would work, but haven't tried it. I'd try the SARInstaller for 3.2 package.
(Documentation problem: my network connection is down again. IT services are getting ready for the beginning of semester, and this seems to make my off-campus Web access disappear from time to time.) Having a whole bunch of change-sets just to get things done in the order I did them seems a little, no, extremely unfriendly of Squeak.
Q4: I'd like the change set to be usable in 3.0, 3.2, and 3.4. Is it OK if a change set file contains directives to remove methods that don't exist? How do I make one remove a method from a _class_ that might not exist in some version?
I'd stick this in a preamble or postscript, generally, or in a separate change set for that specific version.
Details, please. I know what preambles and postscripts are and how to create them, but WHAT do I stick in there? What MAY I stick in there?
The preambles and postscripts of *change sets* are just Squeak code that gets executed. You can put pretty much anything in them.
So you could have code like:
(Smalltalk includesKey: #SomeClass) ifTrue: [ ... do something to SomeClass ].
or:
(Smalltalk version beginsWith: 'Squeak3.0') ifTrue: [ ... something for 3.0 ... ]
In the SAR preamble and postscript (install/preamble and install/postscript), the same is true, with the addition that "self" represents the SAR Installer itself.
The SAR Installer has methods like:
extractMember: name
and
fileInMemberNamed: name
that take SAR member files and extract them to files or file them in as change sets or .st files.
So putting this together, you can do the entire installation in the preamble:
(Smalltalk version beginsWith: 'Squeak3.0') ifTrue: [ self fileInMemberNamed: 'MyStuffFor3.0.cs' ].
etc.
If Squeak can't remember what order I did things in, letting me explicitly tie the changes into some sort of order and remembering _that_ might be a good idea.
On Tuesday 18 February 2003 09:34 pm, Richard A. O'Keefe wrote:
Is SAR available for Squeak 3.0?
Hi Richard,
I checked this for you. Since the ZipArchive support is not in 3.0, SARInstaller won't work there. I thought you had been intending to use 3.2, though.
squeak-dev@lists.squeakfoundation.org