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 |
			aTwoArgumentBlock
				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?
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?

tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Useful random insult:- Suffers from Clue Deficit Disorder.