[squeak-dev] Deprecation warnings in 5.3 cause showstopper error in Seaside
Das.Linux at gmx.de
Tue Jun 16 23:16:46 UTC 2020
> On 17.06.2020, at 01:04, tim Rowledge <tim at rowledge.org> wrote:
> Here's a fun problem. Part of the 'finger pointing' even points at me for this one...
> After loading Seaside into that clean 5.3 image it seems impossible to get Seaside to work. All that happens is a very unhelpful page saying
> Internal Error: SystemVersion>>> major
> No amount of trying adaptor restarts etc does anything different. Eventually one realises that the error handling has broken somewhere, in such a way as to prevent it even printing the error properly. This is always a fun thing to solve.
> Evidently somewhere a SystemVersion is being sent #major - but it does not implement it. OK, create an implementation and break on it. Dig deep into the stack and... #asMutator is sent to a Symbol, which is deprecated and that triggers the Seaside debug stack printing.
> So, problem 1 - the deprecation checking clearly got turned off in my Pi image and I didn't notice adequately to understand what it might change. Damn. Disabling the deprecation warnings lets Seaside 'work' - except of course is still has the problem in the error handling that will bite later.
> Where it goes wrong is in WAPharoWalkback>>#tempNamesAndValuesIn:do: that uses
> ` SystemVersion current major >= 8 ifTrue:[`
> ... which cannot work. Squeak hasn't implemented SystemVersion>>> major since at least before Squeak 4.0.
> I also suspect that despite the WAPharoWalkback class comment claiming it is a Squeak specific class, that in fact this is a Pharo specific class. Something about the class name... I dunno? Also of course, the Squeak major version name isn't 8, it's currently 5.
> The good news is that simply changing the method to
> tempNamesAndValuesIn: aContext do: aTwoArgumentBlock
> SystemVersion current majorVersionNumber >= 5 ifTrue:[
> aContext tempNames doWithIndex: [ :each :index |
> value: each
> value: (aContext namedTempAt: index) ] ]
> lets the Seaside walkback work properly.
> However, it seems odd that there is any guarding of the doWithIndex: clause - was there ever a time that it shouldn't have been evaluated? I don't *think* it would have been a problem pre-Closures but maybe?
Here are the two relevant commits:
It seems pharo before 8 used a different API to access the context…
> Also, what is the best practical option for fixing this permanently? It clearly can't work in a Pharo image so some separation will be required. Maybe add a really-Squeak specific subclass of WAPharoWalkback to the Seaside-Pharo-Development-Core package? Add a(nother) squeak related package to the configuration?
We have something like these already. Seaside-Squeak-Development-Core is maybe in order.
Or actually put that in Grease, where GemStone is already doing the right thing, more or less
More information about the Squeak-dev