And how about correctness of the measured values? The class comment states: "Right now only Number of MessageSends is computed in a correct manner." On the first glance, I cannot see which of the measured values could be wrong. Any hint on inappropriate computation or improvement would be appreciated. The only thing I see a bit confusing is the computation of two McCabe numbers #cyclomaticNumber and #cyclomaticNumber2. Unfortunately, the class comment does not tell enough.
Correctness of measured values is a big issue. The correctness of
the
numbers that Moose produces is unknown. Even such simple
measurements
as the number of classes or method invocations might be wrong!
I think that adrian is a bit simplifying too much. What is the language that you want to analyse? For Smalltalk, since the langage is dynamically typed nobody on earth can be precise when talking about invocations! Now for the number of classes I think that this is correct.
Now if you take any "professional" tools you have to ask yourself
Example of error range in senders: FAMIX does not model shared variables and their initializers, thus any sender in an initializer is lost. If you browse senders with VW you get them. And RBCrawler gets them as well, but filters senders by the result of a flow analysis with method scope (by doing the same abstract interpretation as RoelTyper does, as I found out later when comparing the two tools). That is, three numbers with different precision for the same metric.
Example of error range in number of classes and methods: Fame uses 4 anonymous subclasses of Fame.MetaDescription to instantiate primitive descriptions. FAMIX will not model them, but Object withAllSubclasses will list them. That is, two numbers for the same metric.
i.e., even something as simple as the number of classes is more than one number and thus the correct number of classes is rather a range of possible numbers. In physics error ranges are given as N+/-Err, in software analysis they could be given by making clear what has been measured and what is missing. See examples above.
Of course, whether the above errors matter or not will depend on your use case. For some use cases they might be no problem, for other use cases they are critical or at least annoying.
Whether you care are not also depends on your distance from source code. Consider for example a class blueprint. In smalltalk most #new methods call an #initialize method that typically creates new objects of a different type by calling #new again. Moose will thus visualize the two methods as calling each other even though any developer can tell they do not! For a consultant doing an offline analysis at 10'000 feet altitude that might be good enough, but for the developer using the tool while working at ground level the visualization must be precise or they stop using it because its results are obviously false... and this is why RBCrawler takes the whole pain of running a flow analysis, because I was eating my own dogfood :)
cheers, AA
Example of error range in senders: FAMIX does not model shared variables and their initializers, thus any sender in an initializer is lost.
Adrian your importer removed them. Because old crap did it! And I will reintroduce it.
If you browse senders with VW you get them. And RBCrawler gets them as well, but filters senders by the result of a flow analysis with method scope (by doing the same abstract interpretation as RoelTyper does, as I found out later when comparing the two tools). That is, three numbers with different precision for the same metric.
Come on this is a dynamic typed language so nobody on earth find the exact set to any of my code if I decide it.
Example of error range in number of classes and methods: Fame uses 4 anonymous subclasses of Fame.MetaDescription to instantiate primitive descriptions. FAMIX will not model them, but Object withAllSubclasses will list them. That is, two numbers for the same metric.
Moose does support reflective use like anonymous subclasses.
i.e., even something as simple as the number of classes is more than one number and thus the correct number of classes is rather a range of possible numbers. In physics error ranges are given as N+/-Err, in software analysis they could be given by making clear what has been measured and what is missing. See examples above.
Thanks prof.
Of course, whether the above errors matter or not will depend on your use case. For some use cases they might be no problem, for other use cases they are critical or at least annoying.
Whether you care are not also depends on your distance from source code. Consider for example a class blueprint. In smalltalk most #new methods call an #initialize method that typically creates new objects of a different type by calling #new again. Moose will thus visualize the two methods as calling each other even though any developer can tell they do not! For a consultant doing an offline analysis at 10'000 feet altitude that might be good enough, but for the developer using the tool while working at ground level the visualization must be precise or they stop using it because its results are obviously false... and this is why RBCrawler takes the whole pain of running a flow analysis, because I was eating my own dogfood :)
You are so much better than us
cheers, AA _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On Sep 26, 2008, at 7:28 AM, Stéphane Ducasse wrote:
Example of error range in senders: FAMIX does not model shared variables and their initializers, thus any sender in an initializer is lost.
Adrian your importer removed them. Because old crap did it! And I will reintroduce it.
If you browse senders with VW you get them. And RBCrawler gets them as well, but filters senders by the result of a flow analysis with method scope (by doing the same abstract interpretation as RoelTyper does, as I found out later when comparing the two tools). That is, three numbers with different precision for the same metric.
Come on this is a dynamic typed language so nobody on earth find the exact set to any of my code if I decide it.
Example of error range in number of classes and methods: Fame uses 4 anonymous subclasses of Fame.MetaDescription to instantiate primitive descriptions. FAMIX will not model them, but Object withAllSubclasses will list them. That is, two numbers for the same metric.
Moose does
NOT
support reflective use like anonymous subclasses.
i.e., even something as simple as the number of classes is more than one number and thus the correct number of classes is rather a range of possible numbers. In physics error ranges are given as N+/-Err, in software analysis they could be given by making clear what has been measured and what is missing. See examples above.
Thanks prof.
Of course, whether the above errors matter or not will depend on your use case. For some use cases they might be no problem, for other use cases they are critical or at least annoying.
Whether you care are not also depends on your distance from source code. Consider for example a class blueprint. In smalltalk most #new methods call an #initialize method that typically creates new objects of a different type by calling #new again. Moose will thus visualize the two methods as calling each other even though any developer can tell they do not! For a consultant doing an offline analysis at 10'000 feet altitude that might be good enough, but for the developer using the tool while working at ground level the visualization must be precise or they stop using it because its results are obviously false... and this is why RBCrawler takes the whole pain of running a flow analysis, because I was eating my own dogfood :)
You are so much better than us
cheers, AA _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
It is part of RBCrawler, look for a subclass of InstructionStream (or whatever name that core class to iterate over bytecodes has).
If you like to use it in Moose, I can distribute it as a separate package.
AA
On 26 Sep 2008, at 7:30 , Stéphane Ducasse wrote:
Where can I load that? Because I would like to see how accurate it is?
Stef
On Sep 26, 2008, at 12:24 AM, Adrian Kuhn wrote:
RBCrawler takes the whole pain of running a flow analysis, because I was eating my own dogfood :)
Ok I think that in RB they got a class RB*Guess*Type Now I would like to see how such information can be used since this is what roeltyper is doing.
Stef
On Sep 26, 2008, at 1:38 PM, Adrian Kuhn wrote:
It is part of RBCrawler, look for a subclass of InstructionStream (or whatever name that core class to iterate over bytecodes has).
If you like to use it in Moose, I can distribute it as a separate package.
AA
On 26 Sep 2008, at 7:30 , Stéphane Ducasse wrote:
Where can I load that? Because I would like to see how accurate it is?
Stef
On Sep 26, 2008, at 12:24 AM, Adrian Kuhn wrote:
RBCrawler takes the whole pain of running a flow analysis, because I was eating my own dogfood :)
RoelTyper does not use RBGuessType. RoelType runs a byte code flow analysis and types inst vars. RBCrawler runs a byte code flow analysis and types message sends.
AA
On 26 Sep 2008, at 18:18 , Stéphane Ducasse wrote:
Ok I think that in RB they got a class RB*Guess*Type Now I would like to see how such information can be used since this is what roeltyper is doing.
Stef
On Sep 26, 2008, at 1:38 PM, Adrian Kuhn wrote:
It is part of RBCrawler, look for a subclass of InstructionStream (or whatever name that core class to iterate over bytecodes has).
If you like to use it in Moose, I can distribute it as a separate package.
AA
On 26 Sep 2008, at 7:30 , Stéphane Ducasse wrote:
Where can I load that? Because I would like to see how accurate it is?
Stef
On Sep 26, 2008, at 12:24 AM, Adrian Kuhn wrote:
RBCrawler takes the whole pain of running a flow analysis, because I was eating my own dogfood :)
On Sep 26, 2008, at 6:23 PM, Adrian Kuhn wrote:
RoelTyper does not use RBGuessType.
I know.
RoelType runs a byte code flow analysis and types inst vars. RBCrawler runs a byte code flow analysis and types message sends.
Ok do you mean that you get the type of receivers? I think that it would be good to integrate all that to Moose. First SqMoose...running Stef
AA
On 26 Sep 2008, at 18:18 , Stéphane Ducasse wrote:
Ok I think that in RB they got a class RB*Guess*Type Now I would like to see how such information can be used since this is what roeltyper is doing.
Stef
On Sep 26, 2008, at 1:38 PM, Adrian Kuhn wrote:
It is part of RBCrawler, look for a subclass of InstructionStream (or whatever name that core class to iterate over bytecodes has).
If you like to use it in Moose, I can distribute it as a separate package.
AA
On 26 Sep 2008, at 7:30 , Stéphane Ducasse wrote:
Where can I load that? Because I would like to see how accurate it is?
Stef
On Sep 26, 2008, at 12:24 AM, Adrian Kuhn wrote:
RBCrawler takes the whole pain of running a flow analysis, because I was eating my own dogfood :)
First Moose is not about model reflective smalltalk programs - this was never the goal. Second, your range error does not solve any of the problems. Because you can we know the error range for some metrics for which you do not have the reflective query at hand!
Stef
On Sep 26, 2008, at 12:24 AM, Adrian Kuhn wrote:
i.e., even something as simple as the number of classes is more than one number and thus the correct number of classes is rather a range of possible numbers. In physics error ranges are given as N+/-Err, in software analysis they could be given by making clear what has been measured and what is missing. See examples above.
-
Adrian Kuhn -
Stéphane Ducasse