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
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
