On 7 May 2011, at 15:46, Alexandre Bergel wrote:
He is
executing the tests to get the type at runtime.
Alex, I think it's nice to have this possibility. The problem with this approach is
that you can only get the relationships that are present in the tests. This can be Ok, or
not, depending on the use case.
Indeed, but it works relatively well in my setting. I would like to keep track of
dependencies of various software programs in which I am involved in their development.
I also made a small Glamour browser that shows me the case that remains unresolved. In
that case, I can write new test or give an arbitrary unique candidate.
Yes, I like the idea of going back to the tests. Basically, this shows the test coverage
of state, rather than the one of functionality :).
Cheers,
Doru
So far, I am satisfied with this solution. But again,
this works if you have unit tests.
Cheers,
Alexandre
On 7 May 2011, at 10:37, Stéphane Ducasse wrote:
alex
do you mean that you execute the system and keep trace. or this is just static analysis.
Stef
On May 6, 2011, at 5:48 PM, Alexandre Bergel wrote:
Hi!
I have been working on a new profiler to reduce the amount of candidates when analyzing a
Smalltalk project. The idea is to run the test to know exactly what are the methods that
are invoked.
I would like you to try my implementation.
With Mondrian, the standard candidates operator produces 27,890 candidates for all the
methods. Using the profiler, it is reduced to 9,828. The amount of candidates is
significantly reduced.
Below two screenshots of a complexity blueprint. I made it on Arki. One with the normal
candidates, and one with the profiling.
<ArkiWithoutProfile.png><ArkiWithProfile.png>
Go to the the squeaksource project ArchitectureMonitor. There is a configuration in it.
Load the last version. Then you should have the option:
<Screen shot 2011-05-06 at 11.44.41.png>
I quickly worked on this, so it may be that it contains some error. I would like to know
whether you like this approach or not.
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel
http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"What is more important: To be happy, or to make happy?"
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel
http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"It's not what we do that matters most, it's how we do it."