[Pharo-project] UndefinedObject(Object)>>doesNotUnderstand: #findNextHandlerContextStarting

Toon Verwaest toon.verwaest at gmail.com
Thu Apr 28 21:41:32 CEST 2011

> On Wed, Apr 27, 2011 at 11:31 AM, Marcus Denker 
> <marcus.denker at inria.fr <mailto:marcus.denker at inria.fr>> wrote:
>     On Apr 24, 2011, at 5:12 PM, Mariano Martinez Peck wrote:
>     > grrrr I don't know what is happening. I am building a PharoDev
>     1.3 and at the end, I do: Undeclared removeUnreferencedKeys
>     > but this throws an error that I attach. It is a big loop of such
>     error.
>     > The progress bar is showing "Clean up in DebuggerMethodMap"
>     >
>     So I added the DebuggerMethodMap intialize (reset the cache) to
>     Smalltalk cleanUp.
>     But why is that called when calling "Undeclared
>     removeUnreferencedKeys"?
> Because the  DebuggerMethodMap holds onto older versions of methods 
> and these can be sources of undeclared references. 
>  If DebuggerMethodMap's collection of methods is properly weak then 
> this isn't an issue but in practice this belt-and-braces approach is 
> more robust.
Is there a good reason why the debugger method map stores this data? It 
seems horribly complex for not that much gain ... When I started working 
on the Glamour Debugger I reimplemented the debugger method map as the 
GTDebugMethodModel which is a hyper-simplification of the 
DebuggerMethodMap for a big part since I don't have to handle caching. 
... and honestly, I never noticed any slowdown in the debugger.

Of course it could just be that my machine is too fast... or that it's 
used somewhere else; or that my code just wasn't complete or so.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gforge.inria.fr/pipermail/pharo-project/attachments/20110428/b8cebcff/attachment.htm>

More information about the Pharo-project mailing list