Testing Seaside in Squeak4.3alpha-11321

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Testing Seaside in Squeak4.3alpha-11321

Hannes Hirzel
Hi

As Enrico mentioned that Pier does not load anymore in Squeak I did a
test if Seaside loads and runs.

I could load Seaside into Squeak4.3-11321 (as of today) with the
script taken from 'Extending the System'

"Seaside 3.0 http://www.seaside.st"
(Installer ss project: 'MetacelloRepository') install:
'ConfigurationOfSeaside30'.
(Smalltalk at: #ConfigurationOfSeaside30) load.
(Smalltalk at: #WAPharoServerAdaptorBrowser) open.

I run all the test of the category
  Seaside-Tests

834 of 834 run and passed


However I cannot start an adaptor

menu 'Apps' / 'Seaside control panel'

add 'Adaptor' , e.g. WAComanceAdaptor

clicking on the 'start' button has no effect.

The feedback still says 'stopped'

Any suggestions how to proceed?

Thank you for the answer in advance

--Hannes

Reply | Threaded
Open this post in threaded view
|

Re: Testing Seaside in Squeak4.3alpha-11321

Tobias Pape
Hi
Am 2011-04-19 um 16:34 schrieb Hannes Hirzel:

> […]
>
> However I cannot start an adaptor
>
> menu 'Apps' / 'Seaside control panel'
>
> add 'Adaptor' , e.g. WAComanceAdaptor
>
> clicking on the 'start' button has no effect.
>
> The feedback still says 'stopped'
>
> Any suggestions how to proceed?

Curously, the buttons and the righ-click commands do not work,
I suspect some OB-proelems there.

What works is right-clik -> 'inspect' and then do-it 'self start'

the same holds for stopping.


So Long,
        -TObias
Reply | Threaded
Open this post in threaded view
|

Re: Testing Seaside in Squeak4.3alpha-11321

Andreas.Raab
On 4/19/2011 17:06, Tobias Pape wrote:
> Curously, the buttons and the righ-click commands do not work,
> I suspect some OB-problems there.

Yes, definitely. It appears as if the culprit is in the combination of
OBButtonBar>>buttonFor: aCommand which will substitute #yourself as
action selector when the button is inactive. However, later, when the
button should be updated we hit an optimization in
OBButtonBar>>updateCommands which attempts to avoid the full recreation
of the buttons and uses OBButtonBar>>updateButton:for: which does not
update the action selector. Curiously, the latter method has my initials
on it :-) so I'm taking a bit responsibility here. I think we should
change OBButtonBar>>updateButton:for: to say:

updateButton: aButton for: aCommand

        ^aButton
                model: aCommand;
                setBalloonText: aCommand longDescription;
                action: (aCommand isActive
                                ifTrue: [ #execute ]
                                ifFalse: [ #yourself ]);
                yourself

I'm not sure where to push this fix.

Cheers,
   - Andreas

Reply | Threaded
Open this post in threaded view
|

Re: Testing Seaside in Squeak4.3alpha-11321

Dale Henrichs
In reply to this post by Hannes Hirzel
I have noticed that certain buttons in OmniBrowser under Squeak4.2+
don't work when clicked while the buttons work when the same
OmniBrowser-based application is running in Pharo... I'm seeing this
with the MetacelloBrowser ...

Anyway, I have gotten the impression, that someone has done some fairly
recent work on getting OmniBrowser to work (again?) in Squeak4.x but
haven't gotten around to tracking it down ... but then I don't even know
if that work would address the problem:)

Dale

On 04/19/2011 07:34 AM, Hannes Hirzel wrote:

> Hi
>
> As Enrico mentioned that Pier does not load anymore in Squeak I did a
> test if Seaside loads and runs.
>
> I could load Seaside into Squeak4.3-11321 (as of today) with the
> script taken from 'Extending the System'
>
> "Seaside 3.0 http://www.seaside.st"
> (Installer ss project: 'MetacelloRepository') install:
> 'ConfigurationOfSeaside30'.
> (Smalltalk at: #ConfigurationOfSeaside30) load.
> (Smalltalk at: #WAPharoServerAdaptorBrowser) open.
>
> I run all the test of the category
>    Seaside-Tests
>
> 834 of 834 run and passed
>
>
> However I cannot start an adaptor
>
> menu 'Apps' / 'Seaside control panel'
>
> add 'Adaptor' , e.g. WAComanceAdaptor
>
> clicking on the 'start' button has no effect.
>
> The feedback still says 'stopped'
>
> Any suggestions how to proceed?
>
> Thank you for the answer in advance
>
> --Hannes
>


Reply | Threaded
Open this post in threaded view
|

Re: Testing Seaside in Squeak4.3alpha-11321

Colin Putney-3
In reply to this post by Andreas.Raab
On Tue, Apr 19, 2011 at 8:26 AM, Andreas Raab <[hidden email]> wrote:

> On 4/19/2011 17:06, Tobias Pape wrote:
>>
>> Curously, the buttons and the righ-click commands do not work,
>> I suspect some OB-problems there.
>
> Yes, definitely. It appears as if the culprit is in the combination of
> OBButtonBar>>buttonFor: aCommand which will substitute #yourself as action
> selector when the button is inactive. However, later, when the button should
> be updated we hit an optimization in OBButtonBar>>updateCommands which
> attempts to avoid the full recreation of the buttons and uses
> OBButtonBar>>updateButton:for: which does not update the action selector.
> Curiously, the latter method has my initials on it :-) so I'm taking a bit
> responsibility here. I think we should change OBButtonBar>>updateButton:for:
> to say:
>
> updateButton: aButton for: aCommand
>
>        ^aButton
>                model: aCommand;
>                setBalloonText: aCommand longDescription;
>                action: (aCommand isActive
>                                ifTrue: [ #execute ]
>                                ifFalse: [ #yourself ]);
>                yourself
>
> I'm not sure where to push this fix.

The best place would be the OmniBrowser project on SqueakSource. It's
world writable.

In this case though, don't bother, I'll just harvest the method above.

Colin

Reply | Threaded
Open this post in threaded view
|

Re: Testing Seaside in Squeak4.3alpha-11321

Colin Putney-3
In reply to this post by Dale Henrichs
On Tue, Apr 19, 2011 at 8:31 AM, Dale Henrichs <[hidden email]> wrote:
> I have noticed that certain buttons in OmniBrowser under Squeak4.2+ don't
> work when clicked while the buttons work when the same OmniBrowser-based
> application is running in Pharo... I'm seeing this with the MetacelloBrowser
> ...
>
> Anyway, I have gotten the impression, that someone has done some fairly
> recent work on getting OmniBrowser to work (again?) in Squeak4.x but haven't
> gotten around to tracking it down ... but then I don't even know if that
> work would address the problem:)

Yeah, I'm bringing Lukas' work over to the Squeak version and
collecting bug reports/fixes. Hope to get a solid release together
soon. If we can get that SqueakMap bug fixed, I'll post it there.

Colin

Reply | Threaded
Open this post in threaded view
|

Re: Testing Seaside in Squeak4.3alpha-11321

Hannes Hirzel
Thank you Tobias for the workaround, Andreas for the analysis of the
bug and the fix and Colin for adding it to his current work of
updating OmniBrowser for Squeak (again).

By using 'inspect' and 'self start' it works fine. For development and
testing work this is OK.

--Hannes

On 4/19/11, Colin Putney <[hidden email]> wrote:

> On Tue, Apr 19, 2011 at 8:31 AM, Dale Henrichs <[hidden email]> wrote:
>> I have noticed that certain buttons in OmniBrowser under Squeak4.2+ don't
>> work when clicked while the buttons work when the same OmniBrowser-based
>> application is running in Pharo... I'm seeing this with the
>> MetacelloBrowser
>> ...
>>
>> Anyway, I have gotten the impression, that someone has done some fairly
>> recent work on getting OmniBrowser to work (again?) in Squeak4.x but
>> haven't
>> gotten around to tracking it down ... but then I don't even know if that
>> work would address the problem:)
>
> Yeah, I'm bringing Lukas' work over to the Squeak version and
> collecting bug reports/fixes. Hope to get a solid release together
> soon. If we can get that SqueakMap bug fixed, I'll post it there.
>
> Colin
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Testing Seaside in Squeak4.3alpha-11321

Dale Henrichs
In reply to this post by Colin Putney-3
On 04/19/2011 09:59 AM, Colin Putney wrote:

> On Tue, Apr 19, 2011 at 8:31 AM, Dale Henrichs<[hidden email]>  wrote:
>> I have noticed that certain buttons in OmniBrowser under Squeak4.2+ don't
>> work when clicked while the buttons work when the same OmniBrowser-based
>> application is running in Pharo... I'm seeing this with the MetacelloBrowser
>> ...
>>
>> Anyway, I have gotten the impression, that someone has done some fairly
>> recent work on getting OmniBrowser to work (again?) in Squeak4.x but haven't
>> gotten around to tracking it down ... but then I don't even know if that
>> work would address the problem:)
>
> Yeah, I'm bringing Lukas' work over to the Squeak version and
> collecting bug reports/fixes. Hope to get a solid release together
> soon. If we can get that SqueakMap bug fixed, I'll post it there.
>
> Colin
>

If you supply me with the magic formula, I can update the
ConfigurationOfOmniBrowser with the correct packages ... which is what
Seaside30 and MetacelloBrowser and others will need ...

Dale

Reply | Threaded
Open this post in threaded view
|

Re: Testing Seaside in Squeak4.3alpha-11321

Tobias Pape

Am 2011-04-19 um 19:45 schrieb Dale Henrichs:

> On 04/19/2011 09:59 AM, Colin Putney wrote:
>> On Tue, Apr 19, 2011 at 8:31 AM, Dale Henrichs<[hidden email]>  wrote:
>>> […]
>>> Anyway, I have gotten the impression, that someone has done some fairly
>>> recent work on getting OmniBrowser to work (again?) in Squeak4.x but haven't
>>> gotten around to tracking it down ... but then I don't even know if that
>>> work would address the problem:)
>>
>> Yeah, I'm bringing Lukas' work over to the Squeak version and
>> collecting bug reports/fixes. Hope to get a solid release together
>> soon. If we can get that SqueakMap bug fixed, I'll post it there.
>>
>> Colin
>>
>
> If you supply me with the magic formula, I can update the ConfigurationOfOmniBrowser with the correct packages ... which is what Seaside30 and MetacelloBrowser and others will need ...


Hmmm progress :) how I like that smell ^.^

Thanks, y'all

So Long,
        -Tobias
Reply | Threaded
Open this post in threaded view
|

Re: Testing Seaside in Squeak4.3alpha-11321

Chris Muller-3
In reply to this post by Colin Putney-3
> soon. If we can get that SqueakMap bug fixed, I'll post it there.

I haven't forgotten about that Colin.  Give me another day or two..  Thx..

 - Chris

Reply | Threaded
Open this post in threaded view
|

Re: Testing Seaside in Squeak4.3alpha-11321

Hannes Hirzel
Chris, which SqueakMap bug did you mean?

I see that somebody (Colin) has posted an OmniBrowser load script
http://map.squeak.org/recentnew

What about posting the Seaside load script?

--Hannes

P.S. The script in the "extending the system" workspace for loading
Seaside 3.0 works in Squeak 4.3 alpha.


On 4/20/11, Chris Muller <[hidden email]> wrote:
>> soon. If we can get that SqueakMap bug fixed, I'll post it there.
>
> I haven't forgotten about that Colin.  Give me another day or two..  Thx..
>
>  - Chris
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Testing Seaside in Squeak4.3alpha-11321

Chris Muller-3
Great idea.  It's just a matter of getting Phillip to do it or getting
his permission to let the community do it.

Phillip?

  - Chris


On Tue, May 3, 2011 at 5:24 AM, Hannes Hirzel <[hidden email]> wrote:

> Chris, which SqueakMap bug did you mean?
>
> I see that somebody (Colin) has posted an OmniBrowser load script
> http://map.squeak.org/recentnew
>
> What about posting the Seaside load script?
>
> --Hannes
>
> P.S. The script in the "extending the system" workspace for loading
> Seaside 3.0 works in Squeak 4.3 alpha.
>
>
> On 4/20/11, Chris Muller <[hidden email]> wrote:
>>> soon. If we can get that SqueakMap bug fixed, I'll post it there.
>>
>> I haven't forgotten about that Colin.  Give me another day or two..  Thx..
>>
>>  - Chris
>>
>>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Testing Seaside in Squeak4.3alpha-11321

Stephane Schitter
In reply to this post by Andreas.Raab
Hi - I just tested loading Seaside 3 from the "Extending the system" instructions in the latest 4.3 alpha (#11453), and the result is the same, the buttons in the seaside control panel are ineffective. The patch of Andreas solves it, is there a reason not to include this to trunk?

Stephane


Le 19 avr. 2011 à 17:26, Andreas Raab a écrit :

> On 4/19/2011 17:06, Tobias Pape wrote:
>> Curously, the buttons and the righ-click commands do not work,
>> I suspect some OB-problems there.
>
> Yes, definitely. It appears as if the culprit is in the combination of OBButtonBar>>buttonFor: aCommand which will substitute #yourself as action selector when the button is inactive. However, later, when the button should be updated we hit an optimization in OBButtonBar>>updateCommands which attempts to avoid the full recreation of the buttons and uses OBButtonBar>>updateButton:for: which does not update the action selector. Curiously, the latter method has my initials on it :-) so I'm taking a bit responsibility here. I think we should change OBButtonBar>>updateButton:for: to say:
>
> updateButton: aButton for: aCommand
>
> ^aButton
> model: aCommand;
> setBalloonText: aCommand longDescription;
> action: (aCommand isActive
> ifTrue: [ #execute ]
> ifFalse: [ #yourself ]);
> yourself
>
> I'm not sure where to push this fix.
>
> Cheers,
>  - Andreas


Reply | Threaded
Open this post in threaded view
|

Re: Testing Seaside in Squeak4.3alpha-11321

Chris Muller-3
Extending the System workspace is obsolete and will be removed soon.
You may load Seaside from SqueakMap.


On Thu, Jun 2, 2011 at 2:21 PM, Stephane <[hidden email]> wrote:

> Hi - I just tested loading Seaside 3 from the "Extending the system" instructions in the latest 4.3 alpha (#11453), and the result is the same, the buttons in the seaside control panel are ineffective. The patch of Andreas solves it, is there a reason not to include this to trunk?
>
> Stephane
>
>
> Le 19 avr. 2011 à 17:26, Andreas Raab a écrit :
>
>> On 4/19/2011 17:06, Tobias Pape wrote:
>>> Curously, the buttons and the righ-click commands do not work,
>>> I suspect some OB-problems there.
>>
>> Yes, definitely. It appears as if the culprit is in the combination of OBButtonBar>>buttonFor: aCommand which will substitute #yourself as action selector when the button is inactive. However, later, when the button should be updated we hit an optimization in OBButtonBar>>updateCommands which attempts to avoid the full recreation of the buttons and uses OBButtonBar>>updateButton:for: which does not update the action selector. Curiously, the latter method has my initials on it :-) so I'm taking a bit responsibility here. I think we should change OBButtonBar>>updateButton:for: to say:
>>
>> updateButton: aButton for: aCommand
>>
>>       ^aButton
>>               model: aCommand;
>>               setBalloonText: aCommand longDescription;
>>               action: (aCommand isActive
>>                               ifTrue: [ #execute ]
>>                               ifFalse: [ #yourself ]);
>>               yourself
>>
>> I'm not sure where to push this fix.
>>
>> Cheers,
>>  - Andreas
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Testing Seaside in Squeak4.3alpha-11321

Levente Uzonyi-2
On Thu, 2 Jun 2011, Chris Muller wrote:

> Extending the System workspace is obsolete and will be removed soon.
> You may load Seaside from SqueakMap.

That doesn't solve this problem. The loader script on SqueakMap uses
an unspecified version of ConfigurationOfOmniBrowser. This shouldn't
really be a problem, but the version where I fixed the Squeak (and some
Pharo) part of it was simply ignored by others (Pharo devs). So loading
the newest version of ConfigurationOfOmniBrowser via Installer won't
work for Squeak. Other than that, the configuration is still loading the
same old mczs, which don't include the fix for the button bar.


Levente

>
>
> On Thu, Jun 2, 2011 at 2:21 PM, Stephane <[hidden email]> wrote:
>> Hi - I just tested loading Seaside 3 from the "Extending the system" instructions in the latest 4.3 alpha (#11453), and the result is the same, the buttons in the seaside control panel are ineffective. The patch of Andreas solves it, is there a reason not to include this to trunk?
>>
>> Stephane
>>
>>
>> Le 19 avr. 2011 ˙˙ 17:26, Andreas Raab a écrit :
>>
>>> On 4/19/2011 17:06, Tobias Pape wrote:
>>>> Curously, the buttons and the righ-click commands do not work,
>>>> I suspect some OB-problems there.
>>>
>>> Yes, definitely. It appears as if the culprit is in the combination of OBButtonBar>>buttonFor: aCommand which will substitute #yourself as action selector when the button is inactive. However, later, when the button should be updated we hit an optimization in OBButtonBar>>updateCommands which attempts to avoid the full recreation of the buttons and uses OBButtonBar>>updateButton:for: which does not update the action selector. Curiously, the latter method has my initials on it :-) so I'm taking a bit responsibility here. I think we should change OBButtonBar>>updateButton:for: to say:
>>>
>>> updateButton: aButton for: aCommand
>>>
>>>       ^aButton
>>>               model: aCommand;
>>>               setBalloonText: aCommand longDescription;
>>>               action: (aCommand isActive
>>>                               ifTrue: [ #execute ]
>>>                               ifFalse: [ #yourself ]);
>>>               yourself
>>>
>>> I'm not sure where to push this fix.
>>>
>>> Cheers,
>>>  - Andreas
>>
>>
>>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Testing Seaside in Squeak4.3alpha-11321

Hannes Hirzel
On 6/3/11, Levente Uzonyi <[hidden email]> wrote:

> On Thu, 2 Jun 2011, Chris Muller wrote:
>
>> Extending the System workspace is obsolete and will be removed soon.
>> You may load Seaside from SqueakMap.
>
> That doesn't solve this problem. The loader script on SqueakMap uses
> an unspecified version of ConfigurationOfOmniBrowser. This shouldn't
> really be a problem, but the version where I fixed the Squeak (and some
> Pharo) part of it was simply ignored by others (Pharo devs). So loading
> the newest version of ConfigurationOfOmniBrowser via Installer won't
> work for Squeak. Other than that, the configuration is still loading the
> same old mczs, which don't include the fix for the button bar.
>
>
> Levente
>
>>


Colin Putney wrote on the 19th of April in this thread that he has
included the fix of Andreas.
So either he has not published his update of OmniBrowser yet
(upstream?) or the configuration script takes a copy from another
repository.

A note aside:
OmniBrowser has its own UI construction framework which is the only
one portable between Squeak and Pharo. Seaside uses it for the control
panel

Colin Putney (one of the original authors who still maintains
OmniBrowser) keeps a repository of OmniBrowser at the wiresong
repository.

Lukas Renggli does a fork from time to time to his own repository and
adds Pharo-specific things and other enhancements.

And I think there is even a third one maintained by Pharo developers
as Pharo is a moving target (Not sure, needs checking).

So we need

1) That the fix by Andreas is included in OmniBrowser
2) That the load script picks the right version of OmniBrowser

BTW it does not matter if the load script resides on Squeak map or is
in the "Extending the system workspace". We need to make it work again
in either case.

--Hannes

Reply | Threaded
Open this post in threaded view
|

Re: Testing Seaside in Squeak4.3alpha-11321

Levente Uzonyi-2
On Fri, 3 Jun 2011, Hannes Hirzel wrote:

> On 6/3/11, Levente Uzonyi <[hidden email]> wrote:
>> On Thu, 2 Jun 2011, Chris Muller wrote:
>>
>>> Extending the System workspace is obsolete and will be removed soon.
>>> You may load Seaside from SqueakMap.
>>
>> That doesn't solve this problem. The loader script on SqueakMap uses
>> an unspecified version of ConfigurationOfOmniBrowser. This shouldn't
>> really be a problem, but the version where I fixed the Squeak (and some
>> Pharo) part of it was simply ignored by others (Pharo devs). So loading
>> the newest version of ConfigurationOfOmniBrowser via Installer won't
>> work for Squeak. Other than that, the configuration is still loading the
>> same old mczs, which don't include the fix for the button bar.
>>
>>
>> Levente
>>
>>>
>
>
> Colin Putney wrote on the 19th of April in this thread that he has
> included the fix of Andreas.

In that case ConfigurationOfOmniBrowser should be updated with the fixed
versions, then the SqueakMap script has to be changed, to explicitly load
that version of ConfigurationOfOmniBrowser.

Is the list of the updated mczs available?


Levente

> So either he has not published his update of OmniBrowser yet
> (upstream?) or the configuration script takes a copy from another
> repository.
>
> A note aside:
> OmniBrowser has its own UI construction framework which is the only
> one portable between Squeak and Pharo. Seaside uses it for the control
> panel
>
> Colin Putney (one of the original authors who still maintains
> OmniBrowser) keeps a repository of OmniBrowser at the wiresong
> repository.
>
> Lukas Renggli does a fork from time to time to his own repository and
> adds Pharo-specific things and other enhancements.
>
> And I think there is even a third one maintained by Pharo developers
> as Pharo is a moving target (Not sure, needs checking).
>
> So we need
>
> 1) That the fix by Andreas is included in OmniBrowser
> 2) That the load script picks the right version of OmniBrowser
>
> BTW it does not matter if the load script resides on Squeak map or is
> in the "Extending the system workspace". We need to make it work again
> in either case.
>
> --Hannes
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Testing Seaside in Squeak4.3alpha-11321

Edgar J. De Cleene-3
In reply to this post by Levente Uzonyi-2



On 6/3/11 4:07 AM, "Levente Uzonyi" <[hidden email]> wrote:

> That doesn't solve this problem. The loader script on SqueakMap uses
> an unspecified version of ConfigurationOfOmniBrowser. This shouldn't
> really be a problem, but the version where I fixed the Squeak (and some
> Pharo) part of it was simply ignored by others (Pharo devs). So loading
> the newest version of ConfigurationOfOmniBrowser via Installer won't
> work for Squeak. Other than that, the configuration is still loading the
> same old mczs, which don't include the fix for the button bar.
>
>
> Levente


So do a thing which works in current Squeak via SqueakMap.
If Pharopatas rip SqueakMap, good for they, we need concentrate on our own
affairs.

Edgar



Reply | Threaded
Open this post in threaded view
|

Re: Testing Seaside in Squeak4.3alpha-11321

Chris Muller-4
In reply to this post by Levente Uzonyi-2
It's a shame that Seaside has a dependency on a particular UI tool
framework at all.  Why?  For my own personal image-build, I simply
exclude the few packages that initiate this dependency.  e.g., I have
a (near) full-running Seaside without OmniBrowser.

Another problem:  Seaside also still references #tempScopedNames, a
method that Pharo renamed from #tempNames.

The Seaside maintainers might be able to be convinced to remove
Pharo-specific code.  If not, perhaps it can at least be split into
separate platform-specific packages to help (although that might not
help with the #tempScopedNames).

Finally, Levente you're right.  The script provided by Seaside
maintainers was not sustainable because it always loads "the latest"
rather than a specific configuration.  We need both, and that is a
practice I've been trying to advocate for a long time with use of
SqueakMap.  Create one release called head which loads the latest and
then other releases which are for legacy Squeak images (e.g., 4.2,
4.1) which load specific named versions.

That way, we can minimize these kinds of stupid "I can't load XYZ"
conversations which consume our community's bandwidth..

  - Chris


On Fri, Jun 3, 2011 at 3:28 AM, Levente Uzonyi <[hidden email]> wrote:

> On Fri, 3 Jun 2011, Hannes Hirzel wrote:
>
>> On 6/3/11, Levente Uzonyi <[hidden email]> wrote:
>>>
>>> On Thu, 2 Jun 2011, Chris Muller wrote:
>>>
>>>> Extending the System workspace is obsolete and will be removed soon.
>>>> You may load Seaside from SqueakMap.
>>>
>>> That doesn't solve this problem. The loader script on SqueakMap uses
>>> an unspecified version of ConfigurationOfOmniBrowser. This shouldn't
>>> really be a problem, but the version where I fixed the Squeak (and some
>>> Pharo) part of it was simply ignored by others (Pharo devs). So loading
>>> the newest version of ConfigurationOfOmniBrowser via Installer won't
>>> work for Squeak. Other than that, the configuration is still loading the
>>> same old mczs, which don't include the fix for the button bar.
>>>
>>>
>>> Levente
>>>
>>>>
>>
>>
>> Colin Putney wrote on the 19th of April in this thread that he has
>> included the fix of Andreas.
>
> In that case ConfigurationOfOmniBrowser should be updated with the fixed
> versions, then the SqueakMap script has to be changed, to explicitly load
> that version of ConfigurationOfOmniBrowser.
>
> Is the list of the updated mczs available?
>
>
> Levente
>
>> So either he has not published his update of OmniBrowser yet
>> (upstream?) or the configuration script takes a copy from another
>> repository.
>>
>> A note aside:
>> OmniBrowser has its own UI construction framework which is the only
>> one portable between Squeak and Pharo. Seaside uses it for the control
>> panel
>>
>> Colin Putney (one of the original authors who still maintains
>> OmniBrowser) keeps a repository of OmniBrowser at the wiresong
>> repository.
>>
>> Lukas Renggli does a fork from time to time to his own repository and
>> adds Pharo-specific things and other enhancements.
>>
>> And I think there is even a third one maintained by Pharo developers
>> as Pharo is a moving target (Not sure, needs checking).
>>
>> So we need
>>
>> 1) That the fix by Andreas is included in OmniBrowser
>> 2) That the load script picks the right version of OmniBrowser
>>
>> BTW it does not matter if the load script resides on Squeak map or is
>> in the "Extending the system workspace". We need to make it work again
>> in either case.
>>
>> --Hannes
>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Testing Seaside in Squeak4.3alpha-11321

Levente Uzonyi-2
On Fri, 3 Jun 2011, Chris Muller wrote:

> It's a shame that Seaside has a dependency on a particular UI tool
> framework at all.  Why?  For my own personal image-build, I simply
> exclude the few packages that initiate this dependency.  e.g., I have
> a (near) full-running Seaside without OmniBrowser.

Seaside itself doesn't depend on OmniBrowser, just the developement tools.

>
> Another problem:  Seaside also still references #tempScopedNames, a
> method that Pharo renamed from #tempNames.

Since it's being used from one of the platform specific packages for Pharo
(Seaside-Pharo-Developement), I don't expect it to be fixed in the near
future.

>
> The Seaside maintainers might be able to be convinced to remove
> Pharo-specific code.  If not, perhaps it can at least be split into
> separate platform-specific packages to help (although that might not
> help with the #tempScopedNames).

http://code.google.com/p/seaside/issues/detail?id=650

>
> Finally, Levente you're right.  The script provided by Seaside
> maintainers was not sustainable because it always loads "the latest"
> rather than a specific configuration.  We need both, and that is a
> practice I've been trying to advocate for a long time with use of
> SqueakMap.  Create one release called head which loads the latest and
> then other releases which are for legacy Squeak images (e.g., 4.2,
> 4.1) which load specific named versions.

I guess you're mixing things here. A Metacello configuration contains
information for loading code into various smalltalks (Squeak, Pharo,
Gemstone) and various versions per smalltalk (Squeak 4.1, 4.2, Pharo 1.1,
1.2, etc). The real problem is MetacelloRepository, or the way it's being
used. Since it's an MC repository, people can ignore or break other's
work (both happened) resulting in issues like this.

So the simple solution is to be explicit and change the installer script
from loading ConfigurationOfOmniBrowser, to load
ConfigurationOfOmniBrowser-xyz.123. The same configuration should be able
to load OB into Squeak 4.1, 4.2, head, etc.

What SqueakMap scripts lack and Metacello does pretty well is proper
dependency handling. It's not enough to check if you have a given class in
the system to decide if you have the proper version of the dependency
loaded or not. E.g.: if I have some version of OCompletion loaded into my
image and I want to load the latest OB, then I expect the loader script to
update OCompletion to the minimal required version if my version is not
sufficient.


Levente

>
> That way, we can minimize these kinds of stupid "I can't load XYZ"
> conversations which consume our community's bandwidth..
>
>  - Chris
>
>
> On Fri, Jun 3, 2011 at 3:28 AM, Levente Uzonyi <[hidden email]> wrote:
>> On Fri, 3 Jun 2011, Hannes Hirzel wrote:
>>
>>> On 6/3/11, Levente Uzonyi <[hidden email]> wrote:
>>>>
>>>> On Thu, 2 Jun 2011, Chris Muller wrote:
>>>>
>>>>> Extending the System workspace is obsolete and will be removed soon.
>>>>> You may load Seaside from SqueakMap.
>>>>
>>>> That doesn't solve this problem. The loader script on SqueakMap uses
>>>> an unspecified version of ConfigurationOfOmniBrowser. This shouldn't
>>>> really be a problem, but the version where I fixed the Squeak (and some
>>>> Pharo) part of it was simply ignored by others (Pharo devs). So loading
>>>> the newest version of ConfigurationOfOmniBrowser via Installer won't
>>>> work for Squeak. Other than that, the configuration is still loading the
>>>> same old mczs, which don't include the fix for the button bar.
>>>>
>>>>
>>>> Levente
>>>>
>>>>>
>>>
>>>
>>> Colin Putney wrote on the 19th of April in this thread that he has
>>> included the fix of Andreas.
>>
>> In that case ConfigurationOfOmniBrowser should be updated with the fixed
>> versions, then the SqueakMap script has to be changed, to explicitly load
>> that version of ConfigurationOfOmniBrowser.
>>
>> Is the list of the updated mczs available?
>>
>>
>> Levente
>>
>>> So either he has not published his update of OmniBrowser yet
>>> (upstream?) or the configuration script takes a copy from another
>>> repository.
>>>
>>> A note aside:
>>> OmniBrowser has its own UI construction framework which is the only
>>> one portable between Squeak and Pharo. Seaside uses it for the control
>>> panel
>>>
>>> Colin Putney (one of the original authors who still maintains
>>> OmniBrowser) keeps a repository of OmniBrowser at the wiresong
>>> repository.
>>>
>>> Lukas Renggli does a fork from time to time to his own repository and
>>> adds Pharo-specific things and other enhancements.
>>>
>>> And I think there is even a third one maintained by Pharo developers
>>> as Pharo is a moving target (Not sure, needs checking).
>>>
>>> So we need
>>>
>>> 1) That the fix by Andreas is included in OmniBrowser
>>> 2) That the load script picks the right version of OmniBrowser
>>>
>>> BTW it does not matter if the load script resides on Squeak map or is
>>> in the "Extending the system workspace". We need to make it work again
>>> in either case.
>>>
>>> --Hannes
>>>
>>>
>>
>

12