specific problem when loading a nested configuration

[Tudor Girba]

Hi,

A strange problem, that appeared before but was solved at the time,
seems to resurface again in a slightly different context.

It is related to the Morphic-MorphTreeWidget from the Momo
squeaksource repository. This is needed in Glamour.

Glamour is needed in Moose.

Now, if you load ConfigurationOfMoose, it all works fine:

Gofer new squeaksource: 'Moose'; addPackage: 'ConfigurationOfMoose';
load.
(Smalltalk at: #ConfigurationOfMoose) perform: #loadDefault

However, Moose is needed in MooseJEE. And if you load
ConfigurationOfMooseJEE it does not work anymore:

Gofer new squeaksource: 'MooseJEE'; addPackage:
'ConfigurationOfMooseJEE'; load.
(Smalltalk at: #ConfigurationOfMooseJEE) perform: #loadDefault

If you look in the packages to load, Morphic-MorphTreeWidget does not
seem to appear among them in the latter case.

I would need help for this one, if someone has time to look into that :)

Cheers,
Doru

--
www.tudorgirba.com

"The coherence of a trip is given by the clearness of the goal."

[Tudor Girba]

Right, that is why I sent it to the metacello mailing list but it is
also related to Moose, and that is why I cc-ed moose-dev :)

Cheers,
Doru


On 11 Dec 2009, at 13:28, Alexandre Bergel wrote:

> The problem seems related to Gofer and/or Metacello right?
>
> Alexandre

>> _______________________________________________
>> Moose-dev mailing list
>> Moos...@iam.unibe.ch
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>
> _______________________________________________
> Moose-dev mailing list
> Moos...@iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

--
www.tudorgirba.com

"From an abstract enough point of view, any two things are similar."

[Dale Henrichs]

Doru,

Things worked fine (well almost fine) with my first try at loading MooseJEE ... initialization failed in FSPlatformResolver, because there is no FSUnixResolver, however the Morphic-MorphTreeWidget is being loaded. I used this expression:

Gofer new squeaksource: 'MooseJEE'; addPackage:
'ConfigurationOfMooseJEE'; load.
(Smalltalk at: #ConfigurationOfMooseJEE) perform: #loadDefault

... This test was run with 1.0-beta.18 preloaded, so I will try again with a virgin image...

Dale

[Dale Henrichs]

Doru,

I looked at the #ensureMetacello method ConfigurationOfMooseJEE, but didn't notice (the first, second and third time that I looked:) that it is using MetacelloConfiguration so latest version isn't getting a recent enough version of Metacello ...

So update the ConfigurationOfMooseJEE class>>ensureMetacello to boot with ConfigurationOfMetacello instead of MetacelloConfiguration...

Dale

[Tudor Girba]

Oh! I am slightly embarrassed :)

I updated ConfigurationOfMooseJEE to use the latest
ConfigurationOfMetacello and indeed it works.

But I think this basically means that it starts to make sense to have
an abstract configuration in Pharo-Core, because copy paste just does
not scale anymore.

Cheers,
Doru

p.s. Btw, I love the progress bar :)

--
www.tudorgirba.com

"Presenting is storytelling."

[stephane ducasse]

> Oh! I am slightly embarrassed :)
>
> I updated ConfigurationOfMooseJEE to use the latest ConfigurationOfMetacello and indeed it works.
>
> But I think this basically means that it starts to make sense to have an abstract configuration in Pharo-Core, because copy paste just does not scale anymore.

I like to hear that sounds :)

[Esteban Lorenzano]

El 11/12/2009, a las 3:52p.m., stephane ducasse escribió:

>
>> Oh! I am slightly embarrassed :)
>>
>> I updated ConfigurationOfMooseJEE to use the latest ConfigurationOfMetacello and indeed it works.
>>
>> But I think this basically means that it starts to make sense to have an abstract configuration in Pharo-Core, because copy paste just does not scale anymore.
>
> I like to hear that sounds :)

Yes, I agree... a Configuration class should be available to avoid copy paste.
This guides us to two diferent metacello packages needed:

1) Metacello Loader (with Configuration class and the Loader tool I'm making)... this package should be preloaded with all pharo images... and maybe with GLASS images too
2) Metacello package as now... this does not needs to be present.

Cheers,
Esteban

[Dale Henrichs]

I wouldn't be entirely opposed to having an abstract configuration class, but I hate to switch the configuration structure in midstream again... it is very nice that a config can be loaded into any old smalltalk image without any prerequisites....

The #ensureMetacello method should simply load ConfigurationOfMetacello and go from there ...

To require an abstract configuration class, I would want that class to be in the core for Pharo, GemStone and Squeak ... Metacello is already bundled with the core in GemStone so that leaves Squeak ... I really don't want to have to preface all of the install instructions with "Before loading the configuration, make sure that you've done X, Y and Z"

If bootstrapping is the only consideration, I don't think it is worth making the change ... there isn't a lot protocol that I would want to put into the Abstract configuration class ... project instance variable and method ...

If there are enough other arguments for an Abstract configuration class, then it would be good to make the switch sooner rather than later.

Being able to view the configurations using a hierarchy browser is an advantage, but that's more of a tools issue.

As I think about it, most of the advantages that come to mind are tools related. Even bootstrapping is a tools issue of sorts...

What do others think?

Dale

----- "Tudor Girba" <tudor...@gmail.com> wrote:

| Oh! I am slightly embarrassed :)
|
| I updated ConfigurationOfMooseJEE to use the latest
| ConfigurationOfMetacello and indeed it works.
|
| But I think this basically means that it starts to make sense to have
|
| an abstract configuration in Pharo-Core, because copy paste just does
|
| not scale anymore.
|

| Cheers,
| Doru

|
| p.s. Btw, I love the progress bar :)
|
|

[Mariano Martinez Peck]

On Fri, Dec 11, 2009 at 8:26 PM, Dale Henrichs <dale.h...@gemstone.com> wrote:

I wouldn't be entirely opposed to having an abstract configuration class, but I hate to switch the configuration structure in midstream again... it is very nice that a config can be loaded into any old smalltalk image without any prerequisites....

The #ensureMetacello method should simply load ConfigurationOfMetacello and go from there ...

To require an abstract configuration class, I would want that class to be in the core for Pharo, GemStone and Squeak ... Metacello is already bundled with the core in GemStone so that leaves Squeak ... I really don't want to have to preface all of the install instructions with "Before loading the configuration, make sure that you've done X, Y and Z"

If bootstrapping is the only consideration, I don't think it is worth making the change ... there isn't a lot protocol that I would want to put into the Abstract configuration class ... project instance variable and method ...

If there are enough other arguments for an Abstract configuration class, then it would be good to make the switch sooner rather than later.

Being able to view the configurations using a hierarchy browser is an advantage, but that's more of a tools issue.

As I think about it, most of the advantages that come to mind are tools related. Even bootstrapping is a tools issue of sorts...

What do others think?

The first time I have to create my configuration, when I did the tutorial, and I have to copy paste the template I wondered myself why there wasn't an abstract configuration class :)
In my opinion, it is easier for the configurations. You put the ensure metacello and all those methods that are in the template there and that's all.

So... +1 to have an abstract class for me.
 

[Dale Henrichs]

Mariano,

Would you be in favor of the abstract class, if the abstract class itself had to be booted into the image?

It's just a practical issue for me ... if we can count on the abstract class being preloaded in all dialects, then an abstract class makes sense.

If we can count on Metacello being preloaded in some of the dialects, then the ensureMetacello method need only be present for portability to platforms in which Metacello is not preloaded.

I don't disagree with the oddity of copy and paste.

Earlier versions of Metacello configurations did rely on a superclass, but booting the superclass into the image was problematic. Granted bootstrapping would only be hard in Squeak, but it isn't supposed to be hard!

The ensureMetacello method is only there for ease of bootstrapping software that is supposed to make it easy to boostrap software, but can't do the bootstrapping until it is bootstrapped itself:)

I just hate the idea of making it harder to share configurations with Squeak...

Dale

[Mariano Martinez Peck]

On Fri, Dec 11, 2009 at 9:40 PM, Dale Henrichs <dale.h...@gemstone.com> wrote:

Mariano,

Would you be in favor of the abstract class, if the abstract class itself had to be booted into the image?

Yes, it is just one simple clase. We have goffer inside Pharo core, why can't we have this class? In addition our idea is to use Metacello to manage our images.

What about having just a package for "utiliies". Right now, you can have only that class, but maybe in the future there are more. So that this package will be included in the "standard" images or Squeak/Pharo/Gemstone.  Is this complicated? I really don't know. In pharo I guess there won't be any problem
 and in gemstone neither. So...if you want to use the abstract class, included it in the standard image. If you don't want, just don't use it and do like we re doing now.

 

It's just a practical issue for me ... if we can count on the abstract class being preloaded in all dialects, then an abstract class makes sense.

Pharo and gemstone are ok.
 

If we can count on Metacello being preloaded in some of the dialects, then the ensureMetacello method need only be present for portability to platforms in which Metacello is not preloaded.

I don't disagree with the oddity of copy and paste.

Earlier versions of Metacello configurations did rely on a superclass, but booting the superclass into the image was problematic. Granted bootstrapping would only be hard in Squeak, but it isn't supposed to be hard!

The ensureMetacello method is only there for ease of bootstrapping software that is supposed to make it easy to boostrap software, but can't do the bootstrapping until it is bootstrapped itself:)

yes, of course :)
 

I just hate the idea of making it harder to share configurations with Squeak...

Me too. I also want Metacello to work everywhere!

Mariano
 

[Dale Henrichs]

Mariano,

So in essence you are proposing that there be a "portable configuration" and a "semi-portable" configuration (requiring abstract superclass, but portable between GemStone and Pharo)....

Hmmm, I would think that this could be done ... the current configuration scheme would suffice for the "portable configuration"... if one has been using the "semi-portable" scheme and want's a portable version, it would easy to convert it to a portable version (some copying required:)...

Any other opinions?

DAle

[Mariano Martinez Peck]

On Fri, Dec 11, 2009 at 11:10 PM, Dale Henrichs <dale.h...@gemstone.com> wrote:

Mariano,

So in essence you are proposing that there be a "portable configuration" and a "semi-portable" configuration (requiring abstract superclass, but portable between GemStone and Pharo)....

Exactly. You even can include in that "package" the Loader Esteban is doing (that thing like the apt-get) where you can do something like Loader install: 'SqueakDBX' or Loader load: 'GLASS' version: '1.0'. Then, this loader automatically looks and download for the ConfiguraationOfXXX (using Gofer) in the repositories, which of course can be set and added (something like universe in apt-get). This seems to make everything simpler. And of course, it may run under squeak/pharo and gemstone.
 

Hmmm, I would think that this could be done ... the current configuration scheme would suffice for the "portable configuration"... if one has been using the "semi-portable" scheme and want's a portable version, it would easy to convert it to a portable version (some copying required:)...

Any other opinions?

Yes, it would be nice to hear other opinions :)

 

[stephane ducasse]

On Dec 11, 2009, at 11:10 PM, Dale Henrichs wrote:

> Mariano,
>
> So in essence you are proposing that there be a "portable configuration" and a "semi-portable" configuration (requiring abstract superclass, but portable between GemStone and Pharo)....
>
> Hmmm, I would think that this could be done ... the current configuration scheme would suffice for the "portable configuration"... if one has been using the "semi-portable" scheme and want's a portable version, it would easy to convert it to a portable version (some copying required:)...

I think that this is a nice solution. This way we could minimize code duplication as well as let a door open for complete bootstrap.
I imagine that this is possible to launch/compile on the fly the methods missing when there is no adequate superclass.