27 Oct
2010
27 Oct
'10
10:23 a.m.
Hi,
1- thanks to the tutorial pointed by Tudor, I ran infusion. Don't know
what went wrong the other time
2- I am attaching a zip file with the infusion and verveine generated
mse files for the LanModel project (sources available with
verveine.extractor.java). I hope this is not contrary to the rules of
the list, the file is only 6K.
There are differences, you can look at it and decide for yourselves
which one you prefer.
And if something strikes you as clearly wrong in Verveine, it can be
changed to fit the expected behaviour. For example verveine creates
Namespaces with their full java name: moose.lan.server, which can
admittedly be less elegant when you nest them:
moose :: moose.lan :: moose.lan.server
infusion creates a more concise:
moose :: lan :: server
yet the name of the inner Namespace becomes "server", which does not
seem to fit exactly the eclipse understanding of packages where
packages are not nested ...
(I know, Eclipse is not Java)
I ran infusion and verveine on Eclipse v.3.1.
It took about 3 min. for infusion and 1min for verveine which is not
very significant given that you are suppose to do it only once. From
my part, it could take one hour and I would not be too much worried
(even if < 5 min is much better).
And of course, infusion does much more things than verveine: it's a
graphical tool, that computes metrics and does a bunch of other
things.
Verveine sole purpose is to generate MSE from java source.
Actually I prefer the batch oriented philosophy of verveine that
allows to call it in srcipt, and let Moose do all the fancy stuff. It
used to be called the Unix philosophy: small tools that are good at
what they do but don't try to do everything.
(Does it makes me an old geek ?)
I might be wrong, but infusion seems to accept only one root directory
for the java project. This can be an issue. For example if you
consider Eclipse that has code for Linux, Mac and windows, you may
want to analyse only one of the versions to avoid duplicate classes (3
implementations of the Button class).
VerveineJ allows to do this by specifying the source path (it is based
on a "compiler" so it has all these options)
That's about what I could see in the 10 minutes I devoted to it.
nicolas
--
Nicolas Anquetil Univ. Lille1 / INRIA-equipe RMod
27 Oct
27 Oct
1:32 p.m.
Thanks Nicolas!
InFusion add the result of some metrics within the .mse, like the cyclomatic complexity.
You basically need the AST to compute it. So it cannot be deduced from a FAMIX model. It
would be cool to have it in Verveine
Alexandre
On 27 Oct 2010, at 05:23, anquetil.nicolas(a)gmail.com wrote:
Hi,
1- thanks to the tutorial pointed by Tudor, I ran infusion. Don't know
what went wrong the other time
2- I am attaching a zip file with the infusion and verveine generated
mse files for the LanModel project (sources available with
verveine.extractor.java). I hope this is not contrary to the rules of
the list, the file is only 6K.
There are differences, you can look at it and decide for yourselves
which one you prefer.
And if something strikes you as clearly wrong in Verveine, it can be
changed to fit the expected behaviour. For example verveine creates
Namespaces with their full java name: moose.lan.server, which can
admittedly be less elegant when you nest them:
moose :: moose.lan :: moose.lan.server
infusion creates a more concise:
moose :: lan :: server
yet the name of the inner Namespace becomes "server", which does not
seem to fit exactly the eclipse understanding of packages where
packages are not nested ...
(I know, Eclipse is not Java)
I ran infusion and verveine on Eclipse v.3.1.
It took about 3 min. for infusion and 1min for verveine which is not
very significant given that you are suppose to do it only once. From
my part, it could take one hour and I would not be too much worried
(even if < 5 min is much better).
And of course, infusion does much more things than verveine: it's a
graphical tool, that computes metrics and does a bunch of other
things.
Verveine sole purpose is to generate MSE from java source.
Actually I prefer the batch oriented philosophy of verveine that
allows to call it in srcipt, and let Moose do all the fancy stuff. It
used to be called the Unix philosophy: small tools that are good at
what they do but don't try to do everything.
(Does it makes me an old geek ?)
I might be wrong, but infusion seems to accept only one root directory
for the java project. This can be an issue. For example if you
consider Eclipse that has code for Linux, Mac and windows, you may
want to analyse only one of the versions to avoid duplicate classes (3
implementations of the Button class).
VerveineJ allows to do this by specifying the source path (it is based
on a "compiler" so it has all these options)
That's about what I could see in the 10 minutes I devoted to it.
nicolas
--
Nicolas Anquetil Univ. Lille1 / INRIA-equipe RMod
<LAN-mse.zip>_______________________________________________
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
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
10:42 p.m.
Hi,
First of all, thanks for this.
Hi,
1- thanks to the tutorial pointed by Tudor, I ran infusion. Don't know
what went wrong the other time
Something seems to have gone wrong, because the model you produced with inFusion has
significantly less entities than the verveine one. I have attached here a better version
of the exported MSE.
2- I am attaching a zip file with the infusion and
verveine generated
mse files for the LanModel project (sources available with
verveine.extractor.java). I hope this is not contrary to the rules of
the list, the file is only 6K.
That is fine.
There are differences, you can look at it and decide
for yourselves
which one you prefer.
The goal is to identify what can be improved in VerveineJ, not to choose between the two.
And if something strikes you as clearly wrong in
Verveine, it can be
changed to fit the expected behaviour. For example verveine creates
Namespaces with their full java name: moose.lan.server, which can
admittedly be less elegant when you nest them:
moose :: moose.lan :: moose.lan.server
infusion creates a more concise:
moose :: lan :: server
The thing is like this:
1. either you produce namespaces like moose.lan.server that do not belong to other
namespaces
2. or you create nested namespaces that have simple names (like lan) that belong to other
namespaces (like moose)
Right now, you do a combination of 1 and 2, which does not produce proper results.
inFusion does 1, but actually we almost always infer the namespace nesting in Moose, so it
would be best if the parser would produce 2.
yet the name of the inner Namespace becomes
"server", which does not
seem to fit exactly the eclipse understanding of packages where
packages are not nested ...
(I know, Eclipse is not Java)
I ran infusion and verveine on Eclipse v.3.1.
It took about 3 min. for infusion and 1min for verveine which is not
very significant given that you are suppose to do it only once. From
my part, it could take one hour and I would not be too much worried
(even if < 5 min is much better).
The goal would also be to compare the amount and quality of the produced entities. I went
quickly through the LAN example, and here is what I found:
(+) Inner classes are exported as nested to the parent class
(+) Anonymous classes are exported as nested in the parent method
(+) namespaces are nested
(+) Implicit variables like self and super
(+) receiver variables properly set in invocations
(-) VerveineJ does not produce annotation instances and annotation types.
(-) No exceptions
(-) classes like <Primitive Package>::void should be PrimitiveTypes
(-) namespace should have simple names
(-) References seem to be at the level of namespaces and it is unclear where they come
from (it looks like they come from the nesting which should not be modeled as a
reference)
(-) There are no source anchors
(-) There are no primitive metrics like lines of code, cyclomatic complexity, number of
statements
(-) There are no entities marked as stub (for example java.lang.Object is not stub)
(-) Interfaces are exported as regular FAMIXClass (it would be better to have them as
FAMIXInterface, or at least to have the isInterface flag set to true)
(-) The signature of the methods have an unwanted space between the name and the
parentheses
(*) It would be cool to also have the next and previous values set for the associations
(this would be useful to recover the order in which instructions appear in the code)
And of course, infusion does much more things than
verveine: it's a
graphical tool, that computes metrics and does a bunch of other
things.
Verveine sole purpose is to generate MSE from java source.
Actually I prefer the batch oriented philosophy of verveine that
allows to call it in srcipt, and let Moose do all the fancy stuff. It
used to be called the Unix philosophy: small tools that are good at
what they do but don't try to do everything.
(Does it makes me an old geek ?)
What we are comparing now are the exporters, not the ui. inFusion also offers a shell
scripts specially for Moose: java2mse.bat and java2mse.sh.
I might be wrong, but infusion seems to accept only
one root directory
for the java project. This can be an issue. For example if you
consider Eclipse that has code for Linux, Mac and windows, you may
want to analyse only one of the versions to avoid duplicate classes (3
implementations of the Button class).
Yes, this is correct. That is why when there are multiple sources, I first have to write a
small shell script that puts the sources together. This is indeed inconvenient.
VerveineJ allows to do this by specifying the source
path (it is based
on a "compiler" so it has all these options)
Nice.
Cheers,
Doru
That's about what I could see in the 10 minutes I
devoted to it.
nicolas
--
Nicolas Anquetil Univ. Lille1 / INRIA-equipe RMod
<LAN-mse.zip>_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"No matter how many recipes we know, we still value a chef."
11:24 p.m.
Many thanks Doru for your analysis!
I need the source code anchors for AspectMaps, so I wont be able to use VerveineJ until
these are added :-(
On 27 Oct 2010, at 17:42, Tudor Girba wrote:
Hi,
First of all, thanks for this.
--
Johan Fabry
jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry
PLEIAD Lab - Computer Science Department (DCC) - University of Chile
28 Oct
28 Oct
1:38 p.m.
Hi,
thanks Doru for the detailed review.
I did some of the easy things.
The thing is like this:
1. either you produce namespaces like moose.lan.server that do not belong to other
namespaces
2. or you create nested namespaces that have simple names (like lan) that belong to other
namespaces (like moose)
Right now, you do a combination of 1 and 2, which does
not produce proper results. inFusion does 1, but actually we almost always infer the
namespace nesting in Moose, so it would be best if the parser would produce 2.
The goal would also be to compare the amount and
quality of the produced entities. I went quickly through the LAN example, and here is what
I found:
(+) Inner classes are exported as nested to the parent class
(+) Anonymous classes are exported as nested in the parent method
(+) namespaces are nested
(+) Implicit variables like self and super
(+) receiver variables properly set in invocations
(-) VerveineJ does not produce annotation instances
and annotation types.
I put this in the wish list of the project
(-) No exceptions
I put this in the wish list
(-) classes like <Primitive Package>::void
should be PrimitiveTypes
Yes I know :-(
I was lazy
(-) namespace should have simple names
done
(-) References seem to be at the level of namespaces
and it is unclear where they come from (it looks like they come from the nesting which
should not be modeled as a reference)
They come from the "import" statements ...
Never was sure if it was a good idea or not, but I though it could be
nice to have the info ...
(-) There are no source anchors
OK, I did it for Classes, Methods and Attributes.
I left out method parameters, implicit variables, local variables and
associations.
I am afraid that would result in a huge model ...
Actually it was implemented at some point for invocations for
debugging purposes but then I commented it out :-)
(-) There are no primitive metrics like lines of code,
cyclomatic complexity, number of statements
It is already in the wish list
(-) There are no entities marked as stub (for example
java.lang.Object is not stub)
There could be some entities marked as stub.
The point is JDT binding resolver is quite good (it is used as a
compiler front end after all)
So, if one specifies correctly the source path and class path and all,
we have precisely all the information on all the entities.
For example, this means we can find the attributes and methods of
classes that are not in the parsed source code, but in libraries.
Currently, the stub flag is only set when we don't have this
information (which means, a library or something was not properly
specified in the command line).
Apart from this VerveineJ fetches all the informations "upward": It
fetchs the container of the entities, and for classes their superclass
(recursively)
Two persons already told me that the stub should be for everything
that is not in the parsed source code, even if we have all the info on
it.
You are the third one.
When we reach the total of 741 people asking for it, I will put it in
the wish list :-)
OK, I will think about it, actually it should not be too difficult
(-) Interfaces are exported as regular FAMIXClass (it
would be better to have them as FAMIXInterface, or at least to have the isInterface flag
set to true)
Yes I know
Did I mention I am lazy ?
"Implements" and "inherits" are both translated as
"Famix.Inheritance", I guess?
(-) The signature of the methods have an unwanted
space between the name and the parentheses
This one was easy, I can do it any time
(*) It would be cool to also have the next and
previous values set for the associations (this would be useful to recover the order in
which instructions appear in the code)
wish list
I will have to think a bit about it
So this is it for today
I will be looking at the other ones in the coming days (hopefully)
nicolas
--
Nicolas Anquetil Univ. Lille1 / INRIA-equipe RMod
29 Oct
29 Oct
1:11 p.m.
Hi,
Great work. I looked over the changes in the LAN model. I list some issues below.
If you give me your Google account, I can add you to the Google Code page of Moose and we
can handle the issues via this tracker.
Great.
That is exactly what we need.
However, you are storing the absolute path. The problem should be relative to the input
source I provided. Like this I can move the sources and the image around as I please.
Of course. This is what every reasonable parser does.
I thought so :)
Thanks for all the work. Please let us know if there are any new developments.
Cheers,
Doru
--
www.tudorgirba.com
"Live like you mean it."
thanks Doru for the detailed review.
I did some of the easy things.
I guess it should not be difficult.
The thing is like this:
1. either you produce namespaces like moose.lan.server that do not belong to other
namespaces
2. or you create nested namespaces that have simple names (like lan) that belong to other
namespaces (like moose)
Right now, you do a combination of 1 and 2, which
does not produce proper results. inFusion does 1, but actually we almost always infer the
namespace nesting in Moose, so it would be best if the parser would produce 2.
The goal would also be to compare the amount and
quality of the produced entities. I went quickly through the LAN example, and here is what
I found:
(+) Inner classes are exported as nested to the parent class
(+) Anonymous classes are exported as nested in the parent method
(+) namespaces are nested
(+) Implicit variables like self and super
(+) receiver variables properly set in invocations
(-) VerveineJ does not produce annotation
instances and annotation types.
I put this in the wish list of the project
(-) No exceptions
I put this in the wish
list
(-) classes like <Primitive Package>::void
should be PrimitiveTypes
Yes I know :-(
I was lazy (-) namespace
should have simple names
done (-) References
seem to be at the level of namespaces and it is unclear where they come from (it looks
like they come from the nesting which should not be modeled as a reference)
They come from the "import" statements ...
Never was sure if it was a good idea or not, but I though it could be
nice to have the info ...
(-) There are no source anchors
OK, I did it for Classes, Methods and Attributes.
I left out method parameters, implicit variables, local variables and
associations.
I am afraid that would result in a huge model ...
Actually it was implemented at some point for invocations for
debugging purposes but then I commented it out :-) (-) There are
no primitive metrics like lines of code, cyclomatic complexity, number of statements
It is already in the wish list
(-) There are no entities marked as stub (for
example java.lang.Object is not stub)
There could be some entities marked as stub.
The point is JDT binding resolver is quite good (it is used as a
compiler front end after all)
So, if one specifies correctly the source path and class path and all,
we have precisely all the information on all the entities.
For example, this means we can find the attributes and methods of
classes that are not in the parsed source code, but in libraries. Currently, the stub flag is only set when we don't
have this
information (which means, a library or something was not properly
specified in the command line).
Apart from this VerveineJ fetches all the informations "upward": It
fetchs the container of the entities, and for classes their superclass
(recursively)
Two persons already told me that the stub should be for everything
that is not in the parsed source code, even if we have all the info on
it.
Exactly. This is the semantics of stub (everything I did not tell you to look at
explicitly).
You are the third one.
When we reach the total of 741 people asking for it, I will put it in
the wish list :-)
4 to: 741 do: [:i | nicolas pleaseUpdateTheMeaningOfStub ] :)
OK, I will think about it, actually it should not be too difficult
Yes. The best thing would be to create a FAMIX.Interface which should be a subclass of
FAMIX.Type. This does not exist yet, but I will add one in the Pharo FAMIX.
(-) Interfaces are exported as regular FAMIXClass
(it would be better to have them as FAMIXInterface, or at least to have the isInterface
flag set to true)
Yes I know
Did I mention I am lazy ?
"Implements" and "inherits" are both translated as
"Famix.Inheritance", I guess? (-) The
signature of the methods have an unwanted space between the name and the parentheses
This one was easy, I can do it any time (*) It would
be cool to also have the next and previous values set for the associations (this would be
useful to recover the order in which instructions appear in the code)
wish list
I will have to think a bit about it
So this is it for today
I will be looking at the other ones in the coming days (hopefully)
5168
days inactive
5170
days old
5 comments
4 participants
participants (4)
-
Alexandre Bergel -
anquetil.nicolas＠gmail.com -
Johan Fabry -
Tudor Girba