26 Sep
2008
26 Sep
'08
12:24 a.m.
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 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 
26 Sep
26 Sep
7:28 a.m.
New subject: More metrics in Moose?
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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
7:33 a.m.
New subject: More metrics in Moose?
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.
7:39 a.m.
New subject: More metrics in Moose?
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.
NOT
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(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
1:38 p.m.
New subject: More metrics in Moose?
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 :)
6:18 p.m.
New subject: More metrics in Moose?
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 :)
6:23 p.m.
New subject: More metrics in Moose?
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 :)
>
>
6:35 p.m.
New subject: More metrics in Moose?
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 :)
>
>
5699
days inactive
5700
days old
9 comments
2 participants
participants (2)
-
Adrian Kuhn -
Stéphane Ducasse