Smalltalk › Squeak › Squeak - Dev

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

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

3 messages Options

Chris Cunnington

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

First of all, what is it you're doing with AppleScript? I don't quite get what you're automating.

Metacello is throwing me a curve and I may have some light to shed.

If you download ConfigurationOfExternalWebBrowser and go to the class side you will not see #load. If you download ConfigurationOfSeaside28, you will.

Thus, with the latter you can open a Workspace and type:

ConfigurationOfSeaside28 load

and go have a cigarette.

If you do it with the former, you get:

class(Object)>>doesNotUnderstand: #load.

OK, so far; so messed up. Let's look at the docs:

http://code.google.com/p/metacello/wiki/DownloadMetacello

(Installer repository:

    'http://www.squeaksource.com/MetacelloRepository')

        install: 'ConfigurationOfMetacello'. 

(Smalltalk at: #ConfigurationOfMetacello) perform: #loadLatestVersion.

So maybe we should try:

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.

Chris

Andreas.Raab

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

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

Sean P. DeNigris

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

Administrator

In reply to this post by Chris Cunnington

Chris Cunnington-3 wrote

First of all, what is it you're doing with AppleScript? I don't quite get
what you're automating.
...snip...
I'm guessing that you used AppleScript on some configurations that had
#load, and now you've found one that doesn't.

Yes, not enough context in my example. The Applescript project is a dependency of ExternalWebBrowser that is automatically loaded during the initialization of a class in ExternalWebBrowser.

And, my musing was not about how to get this specifically to load (I hacked away during the installation and got it running), but what I see as a gap in the current spec format.

What I am pulling for, is a way to know exactly what versions of what fork a Config is made for. For example, this Config only had a #pharo part in the baseline, no #common (I'm guessing this is why it failed in Squeak). However, it didn't work in Pharo 1.0 *or* 1.1. If it was clear from looking at the spec what variants it works on (e.g. Pharo 1.x, or 0.9 to 1.3, or whatever), then it wouldn't be a mystery when it failed on another. There could even be a warning dialog telling the installer 'hey this may not work on this platform, do you still want to try?' (a la SqMap).

Chris Cunnington-3 wrote

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.
...snip...
But for me: no #load, means no go. And
until we can get a standard API here, then it's flawed.

Yes, I've run into this. I've always been able to load, but sometimes it involves throwing several messages at the wall - it would definitely be easier if they all had a load.

In this case, it's: (ConfigurationOfExternalWebBrowser project) latestVersion load.

Sean

Sean P. DeNigris wrote

Where I am hitting the wall is managing compatibility with different flavors of Squeak. Let me recount my latest experience...

> I want to install ExternalWebBrowser.
> Oh good, there is a ConfigurationOf... in the SqS MetacelloRepository
> Let me make sure it works and then I'll add it to my ImageSetup script
> Results
> Pharo 1.1 trunk update 11364: ExternalWebBrowserMacOS class>>isApplescriptAvailable references SMSqueakMap, which was removed from Pharo. Ugh, okay, I'll manually install Applescript via Gofer and Monticello, then restart
> Pharo 1.0: same problem
> Squeak 4.1 trunk update 10145: MetacelloMCProjectSpec's instance variable 'className' is nil; when asSymbol is called on it, DNU asSymbol
> Squeak 4.1 official release: same problem

So my question is - what platform does this config target? It failed for all the current Squeak and Pharo images!

As a user, I would like to either:
* have a specific place (depending on my platform) to find the correct config
* or, even easier (and I suspect much less duplication, since many configs may work with multiple platforms), a way to mark ConfigurationsOf as working with particular platforms. Then, you could at least issue a warning, like SqMap, that 'the Config was not approved for this platform, do you want to continue.' If this info was built into the Metacello model, one might even be able to query the MetacelloRepository for configs approved for the current platform.

The way it is now, I think I spent more time above than manually resolving the dependencies.
What are your experiences with this issue, if any?

Thanks.
Sean

Cheers,
Sean