shout for pharo 1.2: Please help.

Pharo 1.0-beta2 _is_ loading Shout 1.2.2 ... that's the one without ShoutWorkspace, which I think is correct ... so ProfStef is okay ...

BTW, validation doesn't check whether versions match or not ... if Shout had a symbolic version defined for Pharo1.2, then I would say that you should use #stable ... so that you can track the "approved version of shout for Pharo1.2", however if your project is tightly coupled to Shout then I would use a literal version number ...

Dale

On Feb 27, 2011, at 11:19 PM, laurent laffont wrote:

Hi,

I've remembered that ProfStef has a dependency on Shout. In version 1.6 (current stable) I have:

spec for: #pharo do: [
spec
project: 'Shout' with: '1.2.2';

can it be a problem ?

If I remove it Metacello validator raises a critical warning.

Laurent

On Mon, Feb 28, 2011 at 8:07 AM, Stéphane Ducasse <[hidden email]<mailto:[hidden email]>> wrote:
Yes but pharo was still loading the version 1.2.1
So normally the latest configurationOfPharo and shout are fixed and working.
Can you confirm that?

Stef
On Feb 28, 2011, at 5:30 AM, Francisco Ortiz Peñaloza wrote:

> Hi Stef don't know if you already solve this, i created a 1.2.2
> version of ConfigurationOfShout referencing some changes i made to
> shout to work with Editor changes.
>
> There're like five new versions since that and it's currently working
> with PharoCore 1.2 cause i tested a lot :)
>
> Cheers,
> Francisco
>
>
>
> On Sun, Feb 27, 2011 at 7:26 PM, Stéphane Ducasse

> <[hidden email]<mailto:[hidden email]>> wrote:
>> Ok
>> For me I just wanted to check if I can load shout.
>> Now it is just breaking on Dev Toolset>>
>>                                                SHWorkspace open.
>>
>> I still do not understand how the correct version of shout was loaded before.
>> Since Pharo was referencing 1.2.1 which was referencing jannik old version
>> and the one with the fix of benjamin was not loaded.
>>
>> So I should adapt the baseline to load the correct test in 1.2.2
>> The problem is that testing all the setup takes 35 min.
>>
>> Stef
>>
>>
>>> So Stef, I looked at  ConfigurationOfPharo-StephaneDucasse.139 and I noticed that you commented out some package specs for 1.2-beta2 ... you need to be aware that commenting them out does not prevent those packages from being loaded ....
>>>
>>> To make structural changes you need to remove the package spec from 1.2-beta2 _and_ remove the package from 1.2-baseline.
>>>
>>> The specification for Shout Tests in  1.2-beta2 specifies the mcz file to load. By commenting out the spec and leaving the spec in 1.2-baseline you are telling Metacello to load the latest version of the Shout Tests package..
>>>
>>> Since 1.2-baseline is already shared by multiple versions, one way to remove Shout Tests for version 1.2-beta2, is to create a 1.2-beta2-baseline that does not include Shout Tests...
>>>
>>> You comment says that you don't know which version of the Shout Tests to load, but by looking at 1.2-beta2-baseline, Shout Tests is referencing the same project as Shout with a different load directive so it is correct to use the save version as Shout.
>>>
>>> In a normal case I would recommend that you use the validator to look at the configuration and fix those issues, but there _are_ a number of validation issues with ConfigurationOfPharo already (which depending on what other changes you have made might actually be contributing to the problem ... There were also validation issues ConfigurationOfShout ... so you might have hit a "perfect storm" of validation issues ..
>>>
>>> I have merged your changes into my working copy and I'll be doing a test load shortly so perhaps I'll be able to observe some of the problems first hand ..
>>>
>>> Dale
>>>
>>> On Feb 27, 2011, at 8:30 AM, Stéphane Ducasse wrote:
>>>
>>>> Ok
>>>> I do not understand how it loaded before because
>>>>      I got a duplicate instance warning raised (even if the class loaded was empty - I do not get it)
>>>>      So I remove the empty package, fixing the version and the baseline...
>>>>
>>>> Now I have the decompiler popping windows.... problem
>>>> Today this is tedious.
>>>> For a fix of 1 min I already spent 2 hours to try to load a configuration.
>>>>
>>>> Stef
>>>>
>>>>
>>>>> Stef,
>>>>>
>>>>> I will try to take a look at your issue today along with testing out the configuration fixes I have pending ... both Pharo and Shout had configuration issues, but I can't say that your particular issue is related ... yet.
>>>>>
>>>>> Dale
>>>>>
>>>>> On Feb 27, 2011, at 7:57 AM, Stéphane Ducasse wrote:
>>>>>
>>>>>> Hi guys
>>>>>>
>>>>>> I modified
>>>>>>
>>>>>> version 1.2.1 of ConfigurationOfShout to load my version
>>>>>>    Shout-sd.101 (apparently lot of comments were removed between Benjamin.100 and Benjamin.101 - strange)
>>>>>>
>>>>>>
>>>>>> In ConfigurationOfPharo there is
>>>>>>
>>>>>>    project: 'Shout' with: '1.2.1';
>>>>>>
>>>>>>
>>>>>> Now in ConfigurationOfShout there are
>>>>>>
>>>>>> version122: spec <version: '1.2.2' imports: #('1.1-baseline')> spec for: #common do: [ spec blessing: #development. spec author: 'Francisco Ortiz Peñaloza'. spec description: 'Shout Changes for 1.2 using new SmalltalkEditor'. ].
>>>>>>
>>>>>>
>>>>>> version121: spec
>>>>>>    <version: '1.2.1' imports: #('1.1-baseline')>
>>>>>>
>>>>>>    spec for: #common do: [
>>>>>>            spec blessing: #development.
>>>>>>            spec author: 'Stephane Ducasse'.
>>>>>>            spec description: 'Shout for 1.2'.
>>>>>>    ].
>>>>>>
>>>>>>
>>>>>> When I load the latest stable of Pharo
>>>>>>
>>>>>> ((Smalltalk globals at: #ConfigurationOfPharo) project version: #stable) load
>>>>>>
>>>>>> I get an error due to a duplicate (probably the instance variable of pluggableShout.....).
>>>>>> Probably loading the wrong package.
>>>>>>
>>>>>> So I do not know what to do and lost my time.
>>>>>>
>>>>>> Stef
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>>

On Feb 27, 2011, at 11:56 PM, laurent laffont wrote:

On Mon, Feb 28, 2011 at 8:40 AM, Dale Henrichs <[hidden email]<mailto:[hidden email]>> wrote:
Pharo 1.0-beta2 _is_ loading Shout 1.2.2 ... that's the one without ShoutWorkspace, which I think is correct ... so ProfStef is okay ...

BTW, validation doesn't check whether versions match or not ... if Shout had a symbolic version defined for Pharo1.2, then I would say that you should use #stable ... so that you can track the "approved version of shout for Pharo1.2", however if your project is tightly coupled to Shout then I would use a literal version number ...

OK. So now

(ConfigurationOfProfStef project version: '1.6') load.

will load Shout 1.2.2.


1/ if I have:
ConfigurationOfProfStef 1.6 -> Shout 1.3
ConfigurationOfPharo -> Shout 1.2,  ProfStef 1.6

which Shout will be loaded then ?

Metacello always goes with the latest version (okay a project can change it's rule, but the default rule is >=).

So Shout 1.3 will be loaded ... it's one of the reasons that symbolic versions were added: so that projects that need to have Shout loaded can just specify #stable and they don't have to worry about which platform or which version of Pharo the project is being loaded into ... you'll get the "correct version" ...

2/ if I have
ConfigurationOfProfStef 1.6 -> Shout #stable

and then a new #stable release of Shout 1.8 breaks compatibility with ProfStef. I suppose  ConfigurationOfProfStef 1.6  won't work anymore ?

If Shout can break your application, then you have a tight coupling to Shout and you need to worry about which version you are using ... Seaside3.0 and Grease are tightly coupled....

I don't the specifics of your implementation, but I assume that ProfStef just wants syntax highlighting for the workspaces then you have a loose coupling and useing #stable should work... in this case, if syntax highlighting breaks it isn't really ProfStef's fault ... more likely someone should _not_ have specified Shout 1.8 as stable:) ...

PS: I've gone through all Metacello help included in Pharo 1.2 recently - very cool to have this.  However I've just checked and it seems there's no explanation on dependency on symbolic versions.

IN my documentation I have tried to say what I know to be true:) The exact usage model for symbolic versions hasn't become completely clear ... 2 months ago, I figured that symbolic versions should be used everywhere, but I have backed off that and recommend that symbolic versions be used in literal versions when there is a loose coupling between the projects.

In baseline versions, I recommend that you certainly use either #bleedingEdge for tightly coupled projects or #stable for loosely coupled projects that way you can limit the exposure you have when using baseline versions to load the latest versions of everything ... #stable will just get you the known working version ...

I've been threatening to write a post about that, but I am finding that I am buried with work,so the documentation suffers:)

Dale