thanks, I will have a look at it On 2012-02-21, at 06:10, Ben Coman wrote:
I loaded SLICE-Issue-5290 onto a freshly unzipped Pharo-1.4-14341 + cogwin_r2522.zip This caused a problem with the debugger as follows. In workspace I execute... self halt. x := 1. y := 2. z := x+y.
I click the second line of the stack "UndefinedObject>>DoIt" which now shows "halt" highlighted. I click <Into> and " := 1" is now highlighted. I click <Into> again and nothing happens. There is no further response from any of the debugger buttons, although <Full Stack> causes the window to flash once.
I can temporarily fix this misbehaviour by forcing #isPostMortem to always return false.
Camillo Bruni wrote:
you can try to load SLICE-Issue-5290-Cleanup-Startup-Error-Handling-CamilloBruni.2
from the pharoInbox which will significantly improve the error responses during startup.
best cami
On 2012-02-18, at 00:19, Ben Coman wrote:
When using the following StartupLoader script
StartupLoader default executeAtomicItems: { StartupAction name: 'Shared Package Cache' code: [ MCCacheRepository default directory setPathName: 'C:\Apps\Smalltalk\!Shared-Package-Cache'.]. }.
I was getting a "syntax error in startup" that I could not identify (is it obvious to others?) This was due to the debugger not opening at the point of error since SmalltalkImage>>executeDeferredStartupActions catches the errors. So I hacked this as follows... deferredStartupActions do: [:each | [ each cull: resuming ] value. "btcdebug on: Halt do: [ :err| Smalltalk logError: '==== Startup Error: ', err description inContext: err signalerContext. errors add: err]"].
and then after a quit and restart the dialog "Syntax error: Unmatched string quote" appeared with... StartupLoader default executeAtomicItems: { StartupAction name: 'Shared Package Cache' code: [ MCCacheRepository default directory setPathName: _Unmatched string quote_ -> 'C:\Apps\Smalltalk\
So after removing "!" from the folder name the syntax error went away.
So now a few questions...
1. Is there a simpler way to debug the startup scripts that I have missed? If not, can a StartupLoader>>test or similar be implemented which runs the same as at image start time but without the error catching in executeDeferredStartupActions, rather than needing to hack executeDeferredStartupActions as I did.
2. Is it reasonable to set a shared package cache in the startup like I have? Or are there some obvious problems with this that I don't see? I would like to avoid downloading all packages every time unzip a fresh image for testing.
3. Is the invalid "!" fixable (though of course I've worked around it)?
I'll open any required bug entries. This was with Pharo-14333 / cogwin_r2522.zip / Windows 7.
cheers, -ben