[squeak-dev] SM, scripts, and application names

Chris Cunnington smalltalktelevision at gmail.com
Fri Mar 9 15:54:16 UTC 2012


-inter-project dependencies
-names
-why Metacello configurations shouldn't be the underlying mechanism to 
put projects up on SM?


Thank you for the feedback. I'd like to try something that may show my 
point of view. I may be misinformed on some things. Let's combine two 
ideas, one yours and one mine. We'll take two postulates and combine 
them. That should make it clearer in my mind and perhaps answer your 
question. Or at least  you'll see where I'm coming from.

Your postulate will be the one above. I'll reduce that down to "only use 
Metacello". That's my interpretation of the question above.

My postulate will be "install with a button". To combine the two, then, 
is to ask "how do I install a Metacello configuration with a button"?

I haven't used Metacello Browser, because I tried to load it into Pharo 
with a Metacello configuration and it wouldn't. The idea sounds great, 
and I'm not sure why Pharo doesn't use it. Who doesn't like buttons?

Well, Pharo and Squeak have been doing without buttons just fine. The 
standard is to cut and paste a script. Maybe you get it from a mailing 
list. Maybe you get it from SqueakSource to download Moose with a 
Metacello configuration. It's a poor solution only supported by social 
proof and precedent. Installing with a button is better.

Take a Metacello configuration like this:

Installer ss
     project: 'MetacelloRepository';
     install: 'FooFooFoo';
((Smalltalk at: #FooFooFoo) project version: #stable) load.

We have that in a Workspace. In SM we put that in a file called, say, 
Foo.st. We save that on the SM server. Then we have a URL that installs 
with a button. And if you don't like files, you can't really be for SM, 
because it is only a storehouse of URLs with files at the end (mcz, sar, 
st).

So, from the point of view of things in a Workspace that become URL 
accessible files, Metacello is a subset of the tools we use to capture 
the context -- the file. You can't install Metacello without either 
Gofer or Installer. If we have a file at the end of a URL, then you can 
have Installer or Gofer install MC configuration files (like this one 
http://www.squeaksource.com/VMMaker/update-dtl.mcm), or package names, 
or Metacello Repository configurations. They can all go in a file. The 
only difference is whether the dependencies information is in the 
Metacello configuration or in the file itself like this:

Installer ss
     project: 'KomHttpServer';
     install: 'DynamicBindings';
     install: 'KomServices';
     install: 'KomHttpServer'.

That is a load script with the dependencies specified. In the Metacello 
related script above the dependency resolution is delegated from the 
script to Metacello.

So, I don't really understand your question, because you cannot make 
Metacello the underlying mechanism, because the underlying mechanism is 
taking something that is executed in a Workspace and making it a script, 
a file, that goes at the end of a URL. What you put into a Workspace is 
never confined to Metacello, and neither would any install need to be.

Oh yea, one more thing. I was advocating application names yesterday. I 
don't see anything in Metacello that does what I'm talking about. It has 
names for configurations like ConfigurationOfFoo. I just want Foo. Give 
me Foo. If I'm SmalltalkDirectons and someone gives me a tip on a great 
application called Foo, then I want to look for Foo. I don't want a 
"ConfigurationOfFoo" and I don't want to guess that the package name 
MCFoo or FFFoo or QSQuasiFoo is the package that may be the root. I want 
to see a list. I want to see Foo. And I want to press a button.

Thanks,
Chris




More information about the Squeak-dev mailing list