I have a small Installer script called logic.st:
Installer cache install: 'AlgebraicDataType'; install: 'Unification'; install: 'Zippers' and I pass that in as the startup script when I start up my Squeak (whether a pre-4.3 or a 4.3 (yay!)), I see the usual progress bar. It says "Compiling AlgebraicDataType-fbs.nn" and then "Installing AlgebraicDataType-fbs.nn", as expected. And then it says the same thing again, talking about installing and compiling AlgebraicDataType instead of Unification, and then again when loading Zippers. The packages all load correctly: it's just the progress morph giving a misleading status message. Has anyone else seen this? frank |
On 26 December 2011 20:44, Frank Shearar <[hidden email]> wrote:
> I have a small Installer script called logic.st: > > Installer cache > install: 'AlgebraicDataType'; > install: 'Unification'; > install: 'Zippers' If I rewrite the script thusly: Installer cache install: 'AlgebraicDataType'. Installer cache install: 'Unification'. Installer cache install: 'UnificationTests'. Installer cache install: 'Zippers'. then all goes well. > and I pass that in as the startup script when I start up my Squeak > (whether a pre-4.3 or a 4.3 (yay!)), I see the usual progress bar. It > says "Compiling AlgebraicDataType-fbs.nn" and then "Installing > AlgebraicDataType-fbs.nn", as expected. And then it says the same > thing again, talking about installing and compiling AlgebraicDataType > instead of Unification, and then again when loading Zippers. > > The packages all load correctly: it's just the progress morph giving a > misleading status message. Has anyone else seen this? Further, the name of the ChangeSet into which the package loads gets mangled to start with the first package loaded. That's because MCPackageLoader>>basicLoad which has: "Obviously this isn't the package name but we don't have anything else to use here. ChangeSet current name will generally work since a CS is usually installed prior to installation." pkgName := ChangeSet current name. If I read correctly, Installer eventually calls InstallerMonticello>>basicInstall, which calls "self mcThing load". Had that been "self mcThing loadWithName: <left as exercise to reader>", I think things would be fine, and I'd see sensible changeset names (and status messages during loading). Is it feasible to change Installer to call a better loading method like #loadWithName: ? frank |
In reply to this post by Frank Shearar-3
On Mon, 26 Dec 2011, Frank Shearar wrote:
> I have a small Installer script called logic.st: > > Installer cache > install: 'AlgebraicDataType'; > install: 'Unification'; > install: 'Zippers' > > and I pass that in as the startup script when I start up my Squeak > (whether a pre-4.3 or a 4.3 (yay!)), I see the usual progress bar. It > says "Compiling AlgebraicDataType-fbs.nn" and then "Installing > AlgebraicDataType-fbs.nn", as expected. And then it says the same > thing again, talking about installing and compiling AlgebraicDataType > instead of Unification, and then again when loading Zippers. > > The packages all load correctly: it's just the progress morph giving a > misleading status message. Has anyone else seen this? Yes, AlgebraicDataType will be installed three times, Unification twice. This is because #install: is implemented as #addPackage:, then #install. Since the Installer subinstance is kept between #install sends, therefore the installations will repeat. The solution is to use #addPackage: and #install directly: Installer cache addPackage: 'AlgebraicDataType'; addPackage: 'Unification'; addPackage: 'Zippers'; install or using a collection: Installer cache install: #('AlgebraicDataType' 'Unification' 'Zippers') Levente > > frank > > |
In reply to this post by Frank Shearar-3
>> Installer cache
>> install: 'AlgebraicDataType'; >> install: 'Unification'; >> install: 'Zippers' > > If I rewrite the script thusly: > > Installer cache > install: 'AlgebraicDataType'. > Installer cache > install: 'Unification'. > Installer cache > install: 'UnificationTests'. > Installer cache > install: 'Zippers'. > > then all goes well. I noticed the exact same thing just a couple of weeks ago! Just awful. What you (we!) originally wrote is a natural, user-friendly way to direct the installer, definitely not something that it should silently punish the user for! But before putting out a reactive-fix, I wanted to see if we could look at the API and understand how Installer is intended to be used. Does one "set up" with builder methods like #addPackage:, and then a pull the trigger with #install to load them all at once? Or, is it meant to be used like you were -- like a nice utility Facade? Installer cache install: 'pkg1'; install: 'pkg2'; etc. Or, something else? We definitely need to clarify and fix this. >> and I pass that in as the startup script when I start up my Squeak >> (whether a pre-4.3 or a 4.3 (yay!)), I see the usual progress bar. It >> says "Compiling AlgebraicDataType-fbs.nn" and then "Installing >> AlgebraicDataType-fbs.nn", as expected. And then it says the same >> thing again, talking about installing and compiling AlgebraicDataType >> instead of Unification, and then again when loading Zippers. >> >> The packages all load correctly: it's just the progress morph giving a >> misleading status message. Has anyone else seen this? > > Further, the name of the ChangeSet into which the package loads gets > mangled to start with the first package loaded. That's because > MCPackageLoader>>basicLoad which has: > > "Obviously this isn't the package name but we don't have anything else > to use here. ChangeSet current name will generally work since a CS is > usually installed prior to installation." > pkgName := ChangeSet current name. > > If I read correctly, Installer eventually calls > InstallerMonticello>>basicInstall, which calls "self mcThing load". > Had that been "self mcThing loadWithName: <left as exercise to > reader>", I think things would be fine, and I'd see sensible changeset > names (and status messages during loading). Is it feasible to change > Installer to call a better loading method like #loadWithName: ? > > frank > |
In reply to this post by Levente Uzonyi-2
> Yes, AlgebraicDataType will be installed three times, Unification twice.
> This is because #install: is implemented as #addPackage:, then #install. That seems like a very wrong implementation.. > Since the Installer subinstance is kept between #install sends, therefore > the installations will repeat. The solution is to use #addPackage: and > #install directly: > > Installer cache > addPackage: 'AlgebraicDataType'; > addPackage: 'Unification'; > addPackage: 'Zippers'; > install > > or using a collection: > > Installer cache install: #('AlgebraicDataType' 'Unification' 'Zippers') These solutions would seem to offer a lot less configuratory control -- since nothing could be done between installations. And, even unnecessarily so, since it's really easy for the user to just write #install:. Why have a two-word/two-step API instead of just one that also happens to be a lot more flexible? I know you were just helping out, it is not your design, but since we all use Installer it's worth to discuss the API in case one of us gets an itch to "fix" it.. |
FWIW, it just occurred to me that the SqueakMap Publishing Guidelines at http://wiki.squeak.org/squeak/6182 seem to use the Installer in this - at least currently - wrong way. Maybe existing scripts are affected?
Cheers, Bernhard Am 27.12.2011 um 01:16 schrieb Chris Muller: >> Yes, AlgebraicDataType will be installed three times, Unification twice. >> This is because #install: is implemented as #addPackage:, then #install. > > That seems like a very wrong implementation.. > >> Since the Installer subinstance is kept between #install sends, therefore >> the installations will repeat. The solution is to use #addPackage: and >> #install directly: >> >> Installer cache >> addPackage: 'AlgebraicDataType'; >> addPackage: 'Unification'; >> addPackage: 'Zippers'; >> install >> >> or using a collection: >> >> Installer cache install: #('AlgebraicDataType' 'Unification' 'Zippers') > > These solutions would seem to offer a lot less configuratory control > -- since nothing could be done between installations. And, even > unnecessarily so, since it's really easy for the user to just write > #install:. Why have a two-word/two-step API instead of just one that > also happens to be a lot more flexible? > > I know you were just helping out, it is not your design, but since we > all use Installer it's worth to discuss the API in case one of us gets > an itch to "fix" it.. > |
Could you be more specific about what you mean by "wrong"?
On Thu, Dec 29, 2011 at 5:21 AM, Bernhard Pieber <[hidden email]> wrote: > FWIW, it just occurred to me that the SqueakMap Publishing Guidelines at http://wiki.squeak.org/squeak/6182 seem to use the Installer in this - at least currently - wrong way. Maybe existing scripts are affected? > > Cheers, > Bernhard > > Am 27.12.2011 um 01:16 schrieb Chris Muller: > >>> Yes, AlgebraicDataType will be installed three times, Unification twice. >>> This is because #install: is implemented as #addPackage:, then #install. >> >> That seems like a very wrong implementation.. >> >>> Since the Installer subinstance is kept between #install sends, therefore >>> the installations will repeat. The solution is to use #addPackage: and >>> #install directly: >>> >>> Installer cache >>> addPackage: 'AlgebraicDataType'; >>> addPackage: 'Unification'; >>> addPackage: 'Zippers'; >>> install >>> >>> or using a collection: >>> >>> Installer cache install: #('AlgebraicDataType' 'Unification' 'Zippers') >> >> These solutions would seem to offer a lot less configuratory control >> -- since nothing could be done between installations. And, even >> unnecessarily so, since it's really easy for the user to just write >> #install:. Why have a two-word/two-step API instead of just one that >> also happens to be a lot more flexible? >> >> I know you were just helping out, it is not your design, but since we >> all use Installer it's worth to discuss the API in case one of us gets >> an itch to "fix" it.. >> > > |
Free forum by Nabble | Edit this page |