Metacello class >>#load ( was Re: unsupported projects )

#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,

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 !! :)



--
Best regards,
Igor Stasenko AKA sig.

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:

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] 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
| >
| >


    

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
| >
| >