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
