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 <dale.henrichs at gemstone.com> 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" <andreas.raab at gmx.de> 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"<andreas.raab at gmx.de>  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
>> | >
>> | >
>>
>>
>>     
>
>
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100518/973e6719/attachment.htm