#load typically loads the latest project version that is marked
with a #release blessing. It is optional to have these convenience methods on the class side. If #load is missing you can implement it like this: load "self load" ^self project latestVersion load since typically one wants to quickly load the latest release version. If you look in detail in ConfigurationOfScriptManager from squeaksource/MetacelloRepository then you will notice that evaluating ConfigurationOfScriptManager project latestVersion you will return version 1.1. although another version 1.2 exists. Guess why: the version 1.1 is marked as release by setting the blessing to #release. version11: spec <version: '1.1' imports: #('1.0-baseline') > spec for: #common do: [ spec blessing: #release. ... while version 1.2 still is in development mode version12: spec <version: '1.2' imports: #('1.0-baseline') > spec for: #common do: [ spec blessing: #development. ... Independent from all that you can always follow the usual pattern: (ConfigurationOfXXX project version: 'vv.vv') load to load a specific version - where vv.vv is the version noted in the pragma (Metacello uses the pragmas and doesnt care about the method name). The other form you may have seem: ConfigurationOfXXX load is just a timesaver to get the latest version. It may be missing since most configs are written by hand since still more tools for Metacello are missing. ----------------------------------------------------------- And by the way: Installer ss project: 'MetacelloRepository'; install: 'ConfigurationOfExternalWebBrowser'. (Smalltalk at: #ConfigurationOfExternalWebBrowser) load is now working in Squeak too. It is the same as: ((Smalltalk at: #ConfigurationOfExternalWebBrowser) project version: '1.1') load ----------------------------------------------------------- If you require a ConfigurationOfAppleScript we can create one. Side note: a new book chapter on Metacello is in preparation by Mariano, be patient or ask questions on the squeak/pharo list. Have fun T. -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 |
Andreas,
It _is_ the curse of not having a common superclass...but until Metacello is included in the base release, the curse would be getting the common superclass loaded BEFORE you can load any configurations. In the early versions of Metacello the configs were subclassed off of a common superclass, but bootstrapping was a complete pain, since you couldn't use Metacello to load itself. As it stands now, you can load any configuration into any image. If you create your configurations by copying MetacelloConfigTemplate (http://code.google.com/p/metacello/wiki/CreateMetacelloConfiguration) then you will get a config that has all of the "expected" methods, including #load on the class-side. To be clear...the only only reason that I don't use the common superclass model, is to make bootstrapping easy....If a MetacelloAbstractConfiguration class were included in the core image for Squeak, Pharo, and GemStone then we could migrate away from the current "self-contained" configurations. The class would be a clone of MetacelloConfigTemplate and existing configs could easily be converted to use the new superclass.... The ensureMetacello logic would be included in the abstract superclass so it wouldn't be necessary to include the core implementation of Metacello in the base... I'm sure the Pharo folks would be in favor of this (as would I, speaking for GemStone)... Dale ----- "Andreas Raab" <[hidden email]> wrote: | On 5/14/2010 6:38 PM, Chris Cunnington wrote: | > ConfigurationOfExternalWebBrowser perform: #loadLatestVersion | > | > Why? | > There is no #loadLatestVersion on the class side either. | > | > There is #lastMetacelloVersionLoad. I try: | > | > ConfigurationOfExternalWebBrowser perform: #loadLatestVersion | > | > Nope, that's a dud. | > | > My summary is this: if you install a config and it has #load on the | > class side, you're golden. If not, then you're in a world of the | unknown. | > All things being equal, I'd say that Dale has created this with | > something in mind where this is not a problem. Maybe it's a Pharo | thing. | > Perhaps they have a tool that fills in the gap. But for me: no | #load, | > means no go. And until we can get a standard API here, then it's | flawed. | > I'm guessing that you used AppleScript on some configurations that | had | > #load, and now you've found one that doesn't. | | It's the curse of not having a common superclass. Various variants get | | created because there's no shared standard. I think the canonical form | | is actually this: | | ConfigurationOfXXX project load. | | But I could be wrong; I'm no Metacello expert. | | Cheers, | - Andreas |
Hi Dale -
I completely understand your reasoning and I'm not criticizing it all. I would've done just the same to get initial adoption (and it has worked very well for this purpose). But now that it's being adopted I think it's time to take it to the next level and fix the divergence if we can. So can I ask you to provide us with the current 'correct' current superclass implementation that we should use for the next set of experiments? Cheers, - Andreas On 5/15/2010 10:53 AM, Dale Henrichs wrote: > Andreas, > > It _is_ the curse of not having a common superclass...but until Metacello is included in the base release, the curse would be getting the common superclass loaded BEFORE you can load any configurations. > > In the early versions of Metacello the configs were subclassed off of a common superclass, but bootstrapping was a complete pain, since you couldn't use Metacello to load itself. > > As it stands now, you can load any configuration into any image. If you create your configurations by copying MetacelloConfigTemplate (http://code.google.com/p/metacello/wiki/CreateMetacelloConfiguration) then you will get a config that has all of the "expected" methods, including #load on the class-side. > > To be clear...the only only reason that I don't use the common superclass model, is to make bootstrapping easy....If a MetacelloAbstractConfiguration class were included in the core image for Squeak, Pharo, and GemStone then we could migrate away from the current "self-contained" configurations. > > The class would be a clone of MetacelloConfigTemplate and existing configs could easily be converted to use the new superclass.... > > The ensureMetacello logic would be included in the abstract superclass so it wouldn't be necessary to include the core implementation of Metacello in the base... > > I'm sure the Pharo folks would be in favor of this (as would I, speaking for GemStone)... > > Dale > ----- "Andreas Raab"<[hidden email]> wrote: > > | On 5/14/2010 6:38 PM, Chris Cunnington wrote: > |> ConfigurationOfExternalWebBrowser perform: #loadLatestVersion > |> > |> Why? > |> There is no #loadLatestVersion on the class side either. > |> > |> There is #lastMetacelloVersionLoad. I try: > |> > |> ConfigurationOfExternalWebBrowser perform: #loadLatestVersion > |> > |> Nope, that's a dud. > |> > |> My summary is this: if you install a config and it has #load on the > |> class side, you're golden. If not, then you're in a world of the > | unknown. > |> All things being equal, I'd say that Dale has created this with > |> something in mind where this is not a problem. Maybe it's a Pharo > | thing. > |> Perhaps they have a tool that fills in the gap. But for me: no > | #load, > |> means no go. And until we can get a standard API here, then it's > | flawed. > |> I'm guessing that you used AppleScript on some configurations that > | had > |> #load, and now you've found one that doesn't. > | > | It's the curse of not having a common superclass. Various variants get > | > | created because there's no shared standard. I think the canonical form > | > | is actually this: > | > | ConfigurationOfXXX project load. > | > | But I could be wrong; I'm no Metacello expert. > | > | Cheers, > | - Andreas > > |
Andreas,
Certainly ... GemStone has been acquired VMWare and today is my first day as a VMWare employee so things will be a little unsettled for the next day or so, but I will get something to you as soon as the decks get cleared... Dale ----- "Andreas Raab" <[hidden email]> wrote: | Hi Dale - | | I completely understand your reasoning and I'm not criticizing it all. | I | would've done just the same to get initial adoption (and it has worked | | very well for this purpose). But now that it's being adopted I think | it's time to take it to the next level and fix the divergence if we | can. | | So can I ask you to provide us with the current 'correct' current | superclass implementation that we should use for the next set of | experiments? | | Cheers, | - Andreas | | On 5/15/2010 10:53 AM, Dale Henrichs wrote: | > Andreas, | > | > It _is_ the curse of not having a common superclass...but until | Metacello is included in the base release, the curse would be getting | the common superclass loaded BEFORE you can load any configurations. | > | > In the early versions of Metacello the configs were subclassed off | of a common superclass, but bootstrapping was a complete pain, since | you couldn't use Metacello to load itself. | > | > As it stands now, you can load any configuration into any image. If | you create your configurations by copying MetacelloConfigTemplate | (http://code.google.com/p/metacello/wiki/CreateMetacelloConfiguration) | then you will get a config that has all of the "expected" methods, | including #load on the class-side. | > | > To be clear...the only only reason that I don't use the common | superclass model, is to make bootstrapping easy....If a | MetacelloAbstractConfiguration class were included in the core image | for Squeak, Pharo, and GemStone then we could migrate away from the | current "self-contained" configurations. | > | > The class would be a clone of MetacelloConfigTemplate and existing | configs could easily be converted to use the new superclass.... | > | > The ensureMetacello logic would be included in the abstract | superclass so it wouldn't be necessary to include the core | implementation of Metacello in the base... | > | > I'm sure the Pharo folks would be in favor of this (as would I, | speaking for GemStone)... | > | > Dale | > ----- "Andreas Raab"<[hidden email]> wrote: | > | > | On 5/14/2010 6:38 PM, Chris Cunnington wrote: | > |> ConfigurationOfExternalWebBrowser perform: #loadLatestVersion | > |> | > |> Why? | > |> There is no #loadLatestVersion on the class side either. | > |> | > |> There is #lastMetacelloVersionLoad. I try: | > |> | > |> ConfigurationOfExternalWebBrowser perform: #loadLatestVersion | > |> | > |> Nope, that's a dud. | > |> | > |> My summary is this: if you install a config and it has #load on | the | > |> class side, you're golden. If not, then you're in a world of | the | > | unknown. | > |> All things being equal, I'd say that Dale has created this with | > |> something in mind where this is not a problem. Maybe it's a | Pharo | > | thing. | > |> Perhaps they have a tool that fills in the gap. But for me: no | > | #load, | > |> means no go. And until we can get a standard API here, then | it's | > | flawed. | > |> I'm guessing that you used AppleScript on some configurations | that | > | had | > |> #load, and now you've found one that doesn't. | > | | > | It's the curse of not having a common superclass. Various variants | get | > | | > | created because there's no shared standard. I think the canonical | form | > | | > | is actually this: | > | | > | ConfigurationOfXXX project load. | > | | > | But I could be wrong; I'm no Metacello expert. | > | | > | Cheers, | > | - Andreas | > | > |
On 17 May 2010 22:15, Dale Henrichs <[hidden email]> wrote:
> Andreas, > > Certainly ... GemStone has been acquired VMWare and today is my first day as a VMWare employee so things will be a little unsettled for the next day or so, but I will get something to you as soon as the decks get cleared... > Long live to G/S !! :) > Dale > ----- "Andreas Raab" <[hidden email]> wrote: > > | Hi Dale - > | > | I completely understand your reasoning and I'm not criticizing it all. > | I > | would've done just the same to get initial adoption (and it has worked > | > | very well for this purpose). But now that it's being adopted I think > | it's time to take it to the next level and fix the divergence if we > | can. > | > | So can I ask you to provide us with the current 'correct' current > | superclass implementation that we should use for the next set of > | experiments? > | > | Cheers, > | - Andreas > | > | On 5/15/2010 10:53 AM, Dale Henrichs wrote: > | > Andreas, > | > > | > It _is_ the curse of not having a common superclass...but until > | Metacello is included in the base release, the curse would be getting > | the common superclass loaded BEFORE you can load any configurations. > | > > | > In the early versions of Metacello the configs were subclassed off > | of a common superclass, but bootstrapping was a complete pain, since > | you couldn't use Metacello to load itself. > | > > | > As it stands now, you can load any configuration into any image. If > | you create your configurations by copying MetacelloConfigTemplate > | (http://code.google.com/p/metacello/wiki/CreateMetacelloConfiguration) > | then you will get a config that has all of the "expected" methods, > | including #load on the class-side. > | > > | > To be clear...the only only reason that I don't use the common > | superclass model, is to make bootstrapping easy....If a > | MetacelloAbstractConfiguration class were included in the core image > | for Squeak, Pharo, and GemStone then we could migrate away from the > | current "self-contained" configurations. > | > > | > The class would be a clone of MetacelloConfigTemplate and existing > | configs could easily be converted to use the new superclass.... > | > > | > The ensureMetacello logic would be included in the abstract > | superclass so it wouldn't be necessary to include the core > | implementation of Metacello in the base... > | > > | > I'm sure the Pharo folks would be in favor of this (as would I, > | speaking for GemStone)... > | > > | > Dale > | > ----- "Andreas Raab"<[hidden email]> wrote: > | > > | > | On 5/14/2010 6:38 PM, Chris Cunnington wrote: > | > |> ConfigurationOfExternalWebBrowser perform: #loadLatestVersion > | > |> > | > |> Why? > | > |> There is no #loadLatestVersion on the class side either. > | > |> > | > |> There is #lastMetacelloVersionLoad. I try: > | > |> > | > |> ConfigurationOfExternalWebBrowser perform: #loadLatestVersion > | > |> > | > |> Nope, that's a dud. > | > |> > | > |> My summary is this: if you install a config and it has #load on > | the > | > |> class side, you're golden. If not, then you're in a world of > | the > | > | unknown. > | > |> All things being equal, I'd say that Dale has created this with > | > |> something in mind where this is not a problem. Maybe it's a > | Pharo > | > | thing. > | > |> Perhaps they have a tool that fills in the gap. But for me: no > | > | #load, > | > |> means no go. And until we can get a standard API here, then > | it's > | > | flawed. > | > |> I'm guessing that you used AppleScript on some configurations > | that > | > | had > | > |> #load, and now you've found one that doesn't. > | > | > | > | It's the curse of not having a common superclass. Various variants > | get > | > | > | > | created because there's no shared standard. I think the canonical > | form > | > | > | > | is actually this: > | > | > | > | ConfigurationOfXXX project load. > | > | > | > | But I could be wrong; I'm no Metacello expert. > | > | > | > | Cheers, > | > | - Andreas > | > > | > > > -- Best regards, Igor Stasenko AKA sig. |
In reply to this post by Dale
Well, congrats! Hope you're having fun there. There is no urgency on our
end so take your time to get settled :-) Cheers, - Andreas On 5/17/2010 12:15 PM, Dale Henrichs wrote: > Andreas, > > Certainly ... GemStone has been acquired VMWare and today is my first day as a VMWare employee so things will be a little unsettled for the next day or so, but I will get something to you as soon as the decks get cleared... > > Dale > ----- "Andreas Raab"<[hidden email]> wrote: > > | Hi Dale - > | > | I completely understand your reasoning and I'm not criticizing it all. > | I > | would've done just the same to get initial adoption (and it has worked > | > | very well for this purpose). But now that it's being adopted I think > | it's time to take it to the next level and fix the divergence if we > | can. > | > | So can I ask you to provide us with the current 'correct' current > | superclass implementation that we should use for the next set of > | experiments? > | > | Cheers, > | - Andreas > | > | On 5/15/2010 10:53 AM, Dale Henrichs wrote: > |> Andreas, > |> > |> It _is_ the curse of not having a common superclass...but until > | Metacello is included in the base release, the curse would be getting > | the common superclass loaded BEFORE you can load any configurations. > |> > |> In the early versions of Metacello the configs were subclassed off > | of a common superclass, but bootstrapping was a complete pain, since > | you couldn't use Metacello to load itself. > |> > |> As it stands now, you can load any configuration into any image. If > | you create your configurations by copying MetacelloConfigTemplate > | (http://code.google.com/p/metacello/wiki/CreateMetacelloConfiguration) > | then you will get a config that has all of the "expected" methods, > | including #load on the class-side. > |> > |> To be clear...the only only reason that I don't use the common > | superclass model, is to make bootstrapping easy....If a > | MetacelloAbstractConfiguration class were included in the core image > | for Squeak, Pharo, and GemStone then we could migrate away from the > | current "self-contained" configurations. > |> > |> The class would be a clone of MetacelloConfigTemplate and existing > | configs could easily be converted to use the new superclass.... > |> > |> The ensureMetacello logic would be included in the abstract > | superclass so it wouldn't be necessary to include the core > | implementation of Metacello in the base... > |> > |> I'm sure the Pharo folks would be in favor of this (as would I, > | speaking for GemStone)... > |> > |> Dale > |> ----- "Andreas Raab"<[hidden email]> wrote: > |> > |> | On 5/14/2010 6:38 PM, Chris Cunnington wrote: > |> |> ConfigurationOfExternalWebBrowser perform: #loadLatestVersion > |> |> > |> |> Why? > |> |> There is no #loadLatestVersion on the class side either. > |> |> > |> |> There is #lastMetacelloVersionLoad. I try: > |> |> > |> |> ConfigurationOfExternalWebBrowser perform: #loadLatestVersion > |> |> > |> |> Nope, that's a dud. > |> |> > |> |> My summary is this: if you install a config and it has #load on > | the > |> |> class side, you're golden. If not, then you're in a world of > | the > |> | unknown. > |> |> All things being equal, I'd say that Dale has created this with > |> |> something in mind where this is not a problem. Maybe it's a > | Pharo > |> | thing. > |> |> Perhaps they have a tool that fills in the gap. But for me: no > |> | #load, > |> |> means no go. And until we can get a standard API here, then > | it's > |> | flawed. > |> |> I'm guessing that you used AppleScript on some configurations > | that > |> | had > |> |> #load, and now you've found one that doesn't. > |> | > |> | It's the curse of not having a common superclass. Various variants > | get > |> | > |> | created because there's no shared standard. I think the canonical > | form > |> | > |> | is actually this: > |> | > |> | ConfigurationOfXXX project load. > |> | > |> | But I could be wrong; I'm no Metacello expert. > |> | > |> | Cheers, > |> | - Andreas > |> > |> > |
In reply to this post by Igor Stasenko
Thanks! It is looking like VMWare will be a good place for GemStone/S to have a long life:) Dale Igor Stasenko wrote: On 17 May 2010 22:15, Dale Henrichs [hidden email] wrote:Andreas, Certainly ... GemStone has been acquired VMWare and today is my first day as a VMWare employee so things will be a little unsettled for the next day or so, but I will get something to you as soon as the decks get cleared...Long live to G/S !! :)Dale ----- "Andreas Raab" [hidden email] wrote: | Hi Dale - | | I completely understand your reasoning and I'm not criticizing it all. | I | would've done just the same to get initial adoption (and it has worked | | very well for this purpose). But now that it's being adopted I think | it's time to take it to the next level and fix the divergence if we | can. | | So can I ask you to provide us with the current 'correct' current | superclass implementation that we should use for the next set of | experiments? | | Cheers, | - Andreas | | On 5/15/2010 10:53 AM, Dale Henrichs wrote: | > Andreas, | > | > It _is_ the curse of not having a common superclass...but until | Metacello is included in the base release, the curse would be getting | the common superclass loaded BEFORE you can load any configurations. | > | > In the early versions of Metacello the configs were subclassed off | of a common superclass, but bootstrapping was a complete pain, since | you couldn't use Metacello to load itself. | > | > As it stands now, you can load any configuration into any image. If | you create your configurations by copying MetacelloConfigTemplate | (http://code.google.com/p/metacello/wiki/CreateMetacelloConfiguration) | then you will get a config that has all of the "expected" methods, | including #load on the class-side. | > | > To be clear...the only only reason that I don't use the common | superclass model, is to make bootstrapping easy....If a | MetacelloAbstractConfiguration class were included in the core image | for Squeak, Pharo, and GemStone then we could migrate away from the | current "self-contained" configurations. | > | > The class would be a clone of MetacelloConfigTemplate and existing | configs could easily be converted to use the new superclass.... | > | > The ensureMetacello logic would be included in the abstract | superclass so it wouldn't be necessary to include the core | implementation of Metacello in the base... | > | > I'm sure the Pharo folks would be in favor of this (as would I, | speaking for GemStone)... | > | > Dale | > ----- "Andreas Raab"[hidden email] wrote: | > | > | On 5/14/2010 6:38 PM, Chris Cunnington wrote: | > |> ConfigurationOfExternalWebBrowser perform: #loadLatestVersion | > |> | > |> Why? | > |> There is no #loadLatestVersion on the class side either. | > |> | > |> There is #lastMetacelloVersionLoad. I try: | > |> | > |> ConfigurationOfExternalWebBrowser perform: #loadLatestVersion | > |> | > |> Nope, that's a dud. | > |> | > |> My summary is this: if you install a config and it has #load on | the | > |> class side, you're golden. If not, then you're in a world of | the | > | unknown. | > |> All things being equal, I'd say that Dale has created this with | > |> something in mind where this is not a problem. Maybe it's a | Pharo | > | thing. | > |> Perhaps they have a tool that fills in the gap. But for me: no | > | #load, | > |> means no go. And until we can get a standard API here, then | it's | > | flawed. | > |> I'm guessing that you used AppleScript on some configurations | that | > | had | > |> #load, and now you've found one that doesn't. | > | | > | It's the curse of not having a common superclass. Various variants | get | > | | > | created because there's no shared standard. I think the canonical | form | > | | > | is actually this: | > | | > | ConfigurationOfXXX project load. | > | | > | But I could be wrong; I'm no Metacello expert. | > | | > | Cheers, | > | - Andreas | > | > |
In reply to this post by Igor Stasenko
Igor,
Thanks! It is looking like VMWare will be a good place for GemStone/S to have a long life:) Dale Igor Stasenko wrote: On 17 May 2010 22:15, Dale Henrichs <[hidden email]><mailto:[hidden email]> wrote: Andreas, Certainly ... GemStone has been acquired VMWare and today is my first day as a VMWare employee so things will be a little unsettled for the next day or so, but I will get something to you as soon as the decks get cleared... Long live to G/S !! :) Dale ----- "Andreas Raab" <[hidden email]><mailto:[hidden email]> wrote: | Hi Dale - | | I completely understand your reasoning and I'm not criticizing it all. | I | would've done just the same to get initial adoption (and it has worked | | very well for this purpose). But now that it's being adopted I think | it's time to take it to the next level and fix the divergence if we | can. | | So can I ask you to provide us with the current 'correct' current | superclass implementation that we should use for the next set of | experiments? | | Cheers, | - Andreas | | On 5/15/2010 10:53 AM, Dale Henrichs wrote: | > Andreas, | > | > It _is_ the curse of not having a common superclass...but until | Metacello is included in the base release, the curse would be getting | the common superclass loaded BEFORE you can load any configurations. | > | > In the early versions of Metacello the configs were subclassed off | of a common superclass, but bootstrapping was a complete pain, since | you couldn't use Metacello to load itself. | > | > As it stands now, you can load any configuration into any image. If | you create your configurations by copying MetacelloConfigTemplate | (http://code.google.com/p/metacello/wiki/CreateMetacelloConfiguration) | then you will get a config that has all of the "expected" methods, | including #load on the class-side. | > | > To be clear...the only only reason that I don't use the common | superclass model, is to make bootstrapping easy....If a | MetacelloAbstractConfiguration class were included in the core image | for Squeak, Pharo, and GemStone then we could migrate away from the | current "self-contained" configurations. | > | > The class would be a clone of MetacelloConfigTemplate and existing | configs could easily be converted to use the new superclass.... | > | > The ensureMetacello logic would be included in the abstract | superclass so it wouldn't be necessary to include the core | implementation of Metacello in the base... | > | > I'm sure the Pharo folks would be in favor of this (as would I, | speaking for GemStone)... | > | > Dale | > ----- "Andreas Raab"<[hidden email]><mailto:[hidden email]> wrote: | > | > | On 5/14/2010 6:38 PM, Chris Cunnington wrote: | > |> ConfigurationOfExternalWebBrowser perform: #loadLatestVersion | > |> | > |> Why? | > |> There is no #loadLatestVersion on the class side either. | > |> | > |> There is #lastMetacelloVersionLoad. I try: | > |> | > |> ConfigurationOfExternalWebBrowser perform: #loadLatestVersion | > |> | > |> Nope, that's a dud. | > |> | > |> My summary is this: if you install a config and it has #load on | the | > |> class side, you're golden. If not, then you're in a world of | the | > | unknown. | > |> All things being equal, I'd say that Dale has created this with | > |> something in mind where this is not a problem. Maybe it's a | Pharo | > | thing. | > |> Perhaps they have a tool that fills in the gap. But for me: no | > | #load, | > |> means no go. And until we can get a standard API here, then | it's | > | flawed. | > |> I'm guessing that you used AppleScript on some configurations | that | > | had | > |> #load, and now you've found one that doesn't. | > | | > | It's the curse of not having a common superclass. Various variants | get | > | | > | created because there's no shared standard. I think the canonical | form | > | | > | is actually this: | > | | > | ConfigurationOfXXX project load. | > | | > | But I could be wrong; I'm no Metacello expert. | > | | > | Cheers, | > | - Andreas | > | > |
Free forum by Nabble | Edit this page |