[Seaside] Re: [Pharo-dev] Pharo{2,3} problems with seaside3.1

[Stephan Eggermont]

Sanjay wrote:
>The issue is that I am simply unable to get Seaside 3.1 debugger to work completely with Pharo 3 & 4 - For Pharo 4 it even shows an error while loading and Halos debugger just does not work. There is a post >about not working with Opal compiler 

Yes, basically because we're calling the wrong method on the compiler or don't give it the right parameters.

>I would like to know if there are Pharo 3 / 4 + Seaside 3.1 or later users and why this is not really a concern with them. 

Yes, we use Pharo3/4 + Seaside 3.1/2 all the time. It is no concern for us because:

- we always download a new version from ci that works for us,
  mostly https://ci.inria.fr/pharo-contribution/job/QCMagritte/
  I've found it takes me now about 5 minutes to add a new job there
  building a configuration for a new project (creating the configuration takes
  a lot more time).  

- QCMagritte default applications are registered with
  the WADebugErrorHandler for development.

QCApplication class>>registerForDevelopmentAt: anApplicationName
	| application |
	WAAdmin enableDevelopmentTools.
	application := self registerAt: anApplicationName.
	application filter configuration at: #exceptionHandler put: WADebugErrorHandler.
	(self overridesDefaults includes: WAAdmin defaultDispatcher defaultName)
		ifTrue: [ WAAdmin defaultDispatcher defaultName: anApplicationName ].
	^application

QCApplication class>>registerAt: anApplicationName
	^(WAAdmin register: self asApplicationAt: anApplicationName)
		preferenceAt: #sessionClass put: self sessionClass;
		addLibrary: JQDeploymentLibrary;
		addLibrary: JQUiDeploymentLibrary;
		yourself

- we nearly never use the halos. The css and page structure is mostly so complex,
  that it is easier to use the browser developer tools.

>I have embarked on a small commercial project as a Pilot / PoC which is to lead to a much larger commercial project and practically the only "tool" I am using as a debugger is "self halt". I want to know what I am >missing 

A lot. Spending half my time in the debugger is not unusual. And that is not about 
fixing issues, it is about designing code.

Stephan