I also noticed this too. There are some methods or classes that are so "kernel" that cannot be wrapped. And of course, the class wrapper in itself.
So...do you have a list to share of the classes/methods that should not be wrapped ?
In my case, for example: #new #changed #initialize #drawOn: #doesNotUnderstand:
For my particular case, I do not instrument the packages coming with a core image. I tried to identify the dangerous subset of it, but apparently I run into some not easy-to-reproduce problem: running twice the image instrumentation block on a method different from the previous try.
I didn't understand you here. What I don't understand is how MessageTally may be of help here.
In order to avoid a complete image instrumentation, I instrument only what is necessary: what is actually executed for a particular scenario. Message tally is handy because you can easily infer what are the involved packages when executing a piece of code. I use this when profiling code: I do a message tally on the code to profile before doing a full-fledged instrumentation.
Sure. I have been playing (no more than 2 days) and analyzing an implementation of MethodWrappers, the TestCoverage and CUIS' Protocol catcher. I just wrote some notes for myself in a simple text file. Actually to write down what I understood and not to loose it. I attached just in case you are interested.
Ahhh I forgot. I am putting all these little tools here: http://www.squeaksource.com/ObjectMetaTools in case you want to take a look.
This was on my todo list. I will have a look at it soon. Cheers, Alexandre NB: Mail apparently cannot recognize your answer and I reply to your email. -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.