This should be added to the 3.6 update stream. I will post a corresponding version for 3.4/3.5 on SqueakMap.
from preamble:
"Change Set: SARInstallerEnhancements-nk Date: 21 July 2003 Author: Ned Konz
21 July:
Fixed a bug in the DVS file-in.
5 July:
More enhancements for the SARInstaller (for 3.5 or 3.6a).
Adds a default (DWIM) mode in which SAR files that are missing both a preamble and postscript have all their members loaded in a default manner.
Changes the behavior of #extractMemberWithoutPath: to use the same directory as the SAR itself.
Added #extractMemberWithoutPath:inDirectory:
Moved several change set methods to the class side.
Made change set methods work with 3.5 or 3.6a/b
Now supports the following file types:
Projects (with or without construction of a ViewMorph) Genie gesture dictionaries Change sets DVS packages Monticello packages Graphics files (loaded as SketchMorphs) Text files (loaded as text editor windows) Morph(s) in files
Now keeps track of installed members.
"!
Hm, for SqueakMap, SMLoader & PackageInfo, I've been treating the copy on SM as the "master" copy, so that the 3.6alpha/beta image gets updated from SM occasionally. (In other words, we're avoiding patching these packages in the image... the patches always go in the SM package first, and then the image gets the whole updated package from SM.)
I was going to update these three tonight, including a postscript which makes the image think that SMLoader 1.02 was installed (which it was, really), for example.
I guess I'm not sure yet what the best solution is here, but I'm a bit wary of adding a package-patch directly to the image.
(Another complicating factor is that the image will always (well, for a long time) list "SARInstaller for 3.4" as being installed, because we can't uninstall packages right now. Although we could unregister that one in the image, and then register a SARInstaller for 3.6 or similar. Or...)
- Doug Way
ned@bike-nomad.com wrote:
This should be added to the 3.6 update stream. I will post a corresponding version for 3.4/3.5 on SqueakMap.
from preamble:
"Change Set: SARInstallerEnhancements-nk Date: 21 July 2003 Author: Ned Konz
21 July:
Fixed a bug in the DVS file-in.
5 July:
More enhancements for the SARInstaller (for 3.5 or 3.6a).
Adds a default (DWIM) mode in which SAR files that are missing both a preamble and postscript have all their members loaded in a default manner.
Changes the behavior of #extractMemberWithoutPath: to use the same directory as the SAR itself.
Added #extractMemberWithoutPath:inDirectory:
Moved several change set methods to the class side.
Made change set methods work with 3.5 or 3.6a/b
Now supports the following file types:
Projects (with or without construction of a ViewMorph) Genie gesture dictionaries Change sets DVS packages Monticello packages Graphics files (loaded as SketchMorphs) Text files (loaded as text editor windows) Morph(s) in files
Now keeps track of installed members.
"!
On Monday 21 July 2003 04:23 pm, Doug Way wrote:
Hm, for SqueakMap, SMLoader & PackageInfo, I've been treating the copy on SM as the "master" copy, so that the 3.6alpha/beta image gets updated from SM occasionally. (In other words, we're avoiding patching these packages in the image... the patches always go in the SM package first, and then the image gets the whole updated package from SM.)
I could certainly post a 3.6 version (containing *just* SARInstaller) on SqueakMap.
But I'd rather not maintain all those other fixes (to ZipArchive, etc.) in the package on SqueakMap. They'll run the risk of not being up to date, and they should be updated with the update stream.
I was going to update these three tonight, including a postscript which makes the image think that SMLoader 1.02 was installed (which it was, really), for example.
I guess I'm not sure yet what the best solution is here, but I'm a bit wary of adding a package-patch directly to the image.
(Another complicating factor is that the image will always (well, for a long time) list "SARInstaller for 3.4" as being installed, because we can't uninstall packages right now. Although we could unregister that one in the image, and then register a SARInstaller for 3.6 or similar. Or...)
The postscript can unregister one and register the other.
On Monday 21 July 2003 04:23 pm, Doug Way wrote:
(Another complicating factor is that the image will always (well, for a long time) list "SARInstaller for 3.4" as being installed, because we can't uninstall packages right now. Although we could unregister that one in the image, and then register a SARInstaller for 3.6 or similar. Or...)
Well, I don't see any "official" way to mark a package as being uninstalled. Though I could just remove it from the installedPackages dictionary, this won't leave any trail.
I'll post a 3.6 version of SARInstaller that contains just the SARInstaller code on SqueakMap, and it'll contain some registration logic.
Ned Konz ned@bike-nomad.com wrote:
On Monday 21 July 2003 04:23 pm, Doug Way wrote:
(Another complicating factor is that the image will always (well, for a long time) list "SARInstaller for 3.4" as being installed, because we can't uninstall packages right now. Although we could unregister that one in the image, and then register a SARInstaller for 3.6 or similar. Or...)
Well, I don't see any "official" way to mark a package as being uninstalled. Though I could just remove it from the installedPackages dictionary, this won't leave any trail.
Right. Note that the installedPackages Dictionary is different in SM1.07. Now it has an OrderedCollection of Arrays as values with timestamps and sequence numbers etc, see the code.
But you can still manipulate it in whichever way you like, we should probably add some API for uninstallation etc.
The only "other" place where this info is kept is in the changelog, and the idea of keeping doits in there to try to keep the installedPackages Dictionary "correct" when recovering images was perhaps not that smart anyway.
regards, Göran
[closed] allreadt there.
< I'm a bug-fixing machine! >
This post brought to you by the BugFixArchiveViewer, a handy tool that makes it easy to comment on proposed fixes and enhancements for Squeak. For more information, check out the Web page for the BugFixArchiveViewer project: http://minnow.cc.gatech.edu/squeak/3214
< I'm a bug-fixing machine! >
squeak-dev@lists.squeakfoundation.org