21 Jul
2012
21 Jul
'12
7:29 p.m.
Hi guys,
Each time we need to do case studies in Moose, we have to select the software application,
in a certain version and probably without all the source code needed. This results on
evaluations that are probably not reproducible.
I think that we need to unify our efforts and share the mse files of our models. With
that, it will be not necessary to generate a FAMIX model each time we need one.
For now, I begun to generate the model from the Qualitas Corpus 'e'
(http://qualitascorpus.com/). There are 486 multiple versions of multiple Java systems.
The mse files are really big (more than 650Mo for Eclipse_SDK3.7). I tried to load the
biggest one in Moose, and it loads ! I just needed to attribute 2Gb of memory in the
info.plist file of Moose 4.6.
I propose to put the files on a server. For all the tar.bz2 files, I need 3.65Gb.
Now, we lack ok at least two pieces of information : (i) the version of verveineJ used for
the extraction. For now, VerveineJ has no version (I took the latest one). (ii) the
version(s) of Moose that can load the file. I tried one mse file with Moose4.6.
We also need a server that can accept all the files.
Any suggestion ?
Jannik
22 Jul
22 Jul
3:53 p.m.
Hi Jannik,
you should definitely talk with Mircea who is planing to create a FAMIX
Corpus. He wanted to create something more complex than a bunch of mse
files on a server. He was trying to identify useful metadata to add to the
files to.
Anyway, I like the idea and yes from the point of view having a mse files
repo I think the only mandatory meta-data are: name and version of the
extractor used to create the mse and the version of Moose that can load the
file. Other simple meta-data could be: name and version of the extracted
system, language of the system, and number of classes and methods (just to
have an idea of the system size).
Cheers,
Fabrizio
2012/7/21 jannik.laval <jannik.laval(a)gmail.com>
Hi guys,
Each time we need to do case studies in Moose, we have to select the
software application, in a certain version and probably without all the
source code needed. This results on evaluations that are probably not
reproducible.
I think that we need to unify our efforts and share the mse files of our
models. With that, it will be not necessary to generate a FAMIX model each
time we need one.
For now, I begun to generate the model from the Qualitas Corpus 'e' (
http://qualitascorpus.com/). There are 486 multiple versions of multiple
Java systems. The mse files are really big (more than 650Mo for
Eclipse_SDK3.7). I tried to load the biggest one in Moose, and it loads ! I
just needed to attribute 2Gb of memory in the info.plist file of Moose 4.6.
I propose to put the files on a server. For all the tar.bz2 files, I need
3.65Gb.
Now, we lack ok at least two pieces of information : (i) the version of
verveineJ used for the extraction. For now, VerveineJ has no version (I
took the latest one). (ii) the version(s) of Moose that can load the file.
I tried one mse file with Moose4.6.
We also need a server that can accept all the files.
Any suggestion ?
Jannik
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
23 Jul
23 Jul
10:35 a.m.
On Jul 22, 2012, at 3:53 PM, Fabrizio Perin wrote:
Hi Jannik,
you should definitely talk with Mircea who is planing to create a FAMIX Corpus. He wanted
to create something more complex than a bunch of mse files on a server. He was trying to
identify useful metadata to add to the files to.
Anyway, I like the idea and yes from the point of view having a mse files repo I think
the only mandatory meta-data are: name and version of the extractor used to create the mse
and the version of Moose that can load the file. Other simple meta-data could be: name and
version of the extracted system, language of the system, and number of classes and methods
(just to have an idea of the system size).
Indeed this was in really early version of famix and after we lost it.
Metadata is important. Guillaume and andre also worked on how to manage versions so that
we can compute different trend analysis.
We discussed also with usman about the structure of a typical project
- original files
- maximum import mse files
- shrunk mse files (because to compute certain metrics we do not need to load the
complete use files - size problem)
A project should be a FAMIX entity so that we do not fill up code with path and other
uglies.
And so that we can query
Project
allProjects
Project
named: 'Azureus';
loadLatestVersion
…
If people want to discuss and join I think that this is needed for moose.
Stef
Cheers,
Fabrizio
2012/7/21 jannik.laval <jannik.laval(a)gmail.com>
Hi guys,
Each time we need to do case studies in Moose, we have to select the software
application, in a certain version and probably without all the source code needed. This
results on evaluations that are probably not reproducible.
I think that we need to unify our efforts and share the mse files of our models. With
that, it will be not necessary to generate a FAMIX model each time we need one.
For now, I begun to generate the model from the Qualitas Corpus 'e'
(http://qualitascorpus.com/). There are 486 multiple versions of multiple Java systems.
The mse files are really big (more than 650Mo for Eclipse_SDK3.7). I tried to load the
biggest one in Moose, and it loads ! I just needed to attribute 2Gb of memory in the
info.plist file of Moose 4.6.
I propose to put the files on a server. For all the tar.bz2 files, I need 3.65Gb.
Now, we lack ok at least two pieces of information : (i) the version of verveineJ used
for the extraction. For now, VerveineJ has no version (I took the latest one). (ii) the
version(s) of Moose that can load the file. I tried one mse file with Moose4.6.
We also need a server that can accept all the files.
Any suggestion ?
Jannik
_______________________________________________
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
10:42 a.m.
Indeed, it would be great to have effort spend in building up
meta-data and associated repositories.
I guess the first thing would be for people to raise their hand if
they want and have resources to participate in this effort. So, who is
in?
I can be in to a limited extent as a reviewer.
Cheers,
Doru
On Mon, Jul 23, 2012 at 10:35 AM, Stéphane Ducasse
<stephane.ducasse(a)inria.fr> wrote:
On Jul 22, 2012, at 3:53 PM, Fabrizio Perin wrote:
--
www.tudorgirba.com
"Every thing has its own flow"
Hi Jannik,
you should definitely talk with Mircea who is planing to create a FAMIX Corpus. He wanted
to create something more complex than a bunch of mse files on a server. He was trying to
identify useful metadata to add to the files to.
Anyway, I like the idea and yes from the point of view having a mse files repo I think
the only mandatory meta-data are: name and version of the extractor used to create the mse
and the version of Moose that can load the file. Other simple meta-data could be: name and
version of the extracted system, language of the system, and number of classes and methods
(just to have an idea of the system size).
Indeed this was in really early version of famix and after we lost it.
Metadata is important. Guillaume and andre also worked on how to manage versions so that
we can compute different trend analysis.
We discussed also with usman about the structure of a typical project
- original files
- maximum import mse files
- shrunk mse files (because to compute certain metrics we do not need to
load the complete use files - size problem)
A project should be a FAMIX entity so that we do not fill up code with path and other
uglies.
And so that we can query
Project
allProjects
Project
named: 'Azureus';
loadLatestVersion
…
If people want to discuss and join I think that this is needed for moose.
Stef
Cheers,
Fabrizio
2012/7/21 jannik.laval <jannik.laval(a)gmail.com>
Hi guys,
Each time we need to do case studies in Moose, we have to select the software
application, in a certain version and probably without all the source code needed. This
results on evaluations that are probably not reproducible.
I think that we need to unify our efforts and share the mse files of our models. With
that, it will be not necessary to generate a FAMIX model each time we need one.
For now, I begun to generate the model from the Qualitas Corpus 'e'
(http://qualitascorpus.com/). There are 486 multiple versions of multiple Java systems.
The mse files are really big (more than 650Mo for Eclipse_SDK3.7). I tried to load the
biggest one in Moose, and it loads ! I just needed to attribute 2Gb of memory in the
info.plist file of Moose 4.6.
I propose to put the files on a server. For all the tar.bz2 files, I need 3.65Gb.
Now, we lack ok at least two pieces of information : (i) the version of verveineJ used
for the extraction. For now, VerveineJ has no version (I took the latest one). (ii) the
version(s) of Moose that can load the file. I tried one mse file with Moose4.6.
We also need a server that can accept all the files.
Any suggestion ?
Jannik
_______________________________________________
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
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 
2:29 p.m.
Stef, you seem to be talking about a Gofer-like tool for fetching and loading MSEs (and
source files) within a moose image from a squaksource-like repository. is that correct ?
Having an easy to use API would surely be helpful.
what we were thinking about was a bit simpler but i believe that the two things can come
together.
we thought about:
- setting up a server capable of generating MSEs from given source code files
- uploading the latest version of qualities corpus (http://qualitascorpus.com/ - both
evolutionary and regular version)
- generating MSEs (and maybe moose images with preloaded MSEs)
- inviting users to download the contents via shell scripts (fetching source code from the
qualities corpus web site and everything else from our server)
most of the metadata related to the single projects are already provided as part of the
qualities corpus in textual format.
the verveineJ issue still has to be clarified.
If there is a way to know more about the version being used for generating the models, it
would be easy to write this information in a text file or simply including it in the
filename.
On Jul 23, 2012, at 10:35 AM, Stéphane Ducasse wrote:
On Jul 22, 2012, at 3:53 PM, Fabrizio Perin wrote:
Hi Jannik,
you should definitely talk with Mircea who is planing to create a FAMIX Corpus. He wanted
to create something more complex than a bunch of mse files on a server. He was trying to
identify useful metadata to add to the files to.
Anyway, I like the idea and yes from the point of view having a mse files repo I think
the only mandatory meta-data are: name and version of the extractor used to create the mse
and the version of Moose that can load the file. Other simple meta-data could be: name and
version of the extracted system, language of the system, and number of classes and methods
(just to have an idea of the system size).
Indeed this was in really early version of famix and after we lost it.
Metadata is important. Guillaume and andre also worked on how to manage versions so that
we can compute different trend analysis.
We discussed also with usman about the structure of a typical project
- original files
- maximum import mse files
- shrunk mse files (because to compute certain metrics we do not need to load the
complete use files - size problem)
A project should be a FAMIX entity so that we do not fill up code with path and other
uglies.
And so that we can query
Project
allProjects
Project
named: 'Azureus';
loadLatestVersion
…
If people want to discuss and join I think that this is needed for moose.
Stef
Cheers,
Fabrizio
2012/7/21 jannik.laval <jannik.laval(a)gmail.com>
Hi guys,
Each time we need to do case studies in Moose, we have to select the software
application, in a certain version and probably without all the source code needed. This
results on evaluations that are probably not reproducible.
I think that we need to unify our efforts and share the mse files of our models. With
that, it will be not necessary to generate a FAMIX model each time we need one.
For now, I begun to generate the model from the Qualitas Corpus 'e'
(http://qualitascorpus.com/). There are 486 multiple versions of multiple Java systems.
The mse files are really big (more than 650Mo for Eclipse_SDK3.7). I tried to load the
biggest one in Moose, and it loads ! I just needed to attribute 2Gb of memory in the
info.plist file of Moose 4.6.
I propose to put the files on a server. For all the tar.bz2 files, I need 3.65Gb.
Now, we lack ok at least two pieces of information : (i) the version of verveineJ used
for the extraction. For now, VerveineJ has no version (I took the latest one). (ii) the
version(s) of Moose that can load the file. I tried one mse file with Moose4.6.
We also need a server that can accept all the files.
Any suggestion ?
Jannik
_______________________________________________
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
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
4:21 p.m.
On Jul 23, 2012, at 2:29 PM, Andrea Caracciolo wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Stef, you seem to be talking about a Gofer-like tool
for fetching and loading MSEs (and source files) within a moose image from a
squaksource-like repository. is that correct ?
kind of :)
Having an easy to use API would surely be helpful.
what we were thinking about was a bit simpler but i believe that the two things can come
together.
The problem is how to manage the source and all the versions.
we thought about:
- setting up a server capable of generating MSEs from given source code files
- uploading the latest version of qualities corpus (http://qualitascorpus.com/ - both
evolutionary and regular version)
- generating MSEs (and maybe moose images with preloaded MSEs)
- inviting users to download the contents via shell scripts (fetching source code from
the qualities corpus web site and everything else from our server)
ok I see.
most of the metadata related to the single projects are already provided as part of the
qualities corpus in textual format.
the verveineJ issue still has to be clarified.
you can use it if you want.
If there is a way to know more about the version being
used for generating the models, it would be easy to write this information in a text file
or simply including it in the filename.
stef
Hi Jannik,
you should definitely talk with Mircea who is planing to create a FAMIX Corpus. He wanted
to create something more complex than a bunch of mse files on a server. He was trying to
identify useful metadata to add to the files to.
Anyway, I like the idea and yes from the point of view having a mse files repo I think
the only mandatory meta-data are: name and version of the extractor used to create the mse
and the version of Moose that can load the file. Other simple meta-data could be: name and
version of the extracted system, language of the system, and number of classes and methods
(just to have an idea of the system size).
Indeed this was in really early version of famix and after we lost it.
Metadata is important. Guillaume and andre also worked on how to manage versions so that
we can compute different trend analysis.
We discussed also with usman about the structure of a typical project
- original files
- maximum import mse files
- shrunk mse files (because to compute certain metrics we do not need to load the
complete use files - size problem)
A project should be a FAMIX entity so that we do not fill up code with path and other
uglies.
And so that we can query
Project
allProjects
Project
named: 'Azureus';
loadLatestVersion
…
If people want to discuss and join I think that this is needed for moose.
Stef
Cheers,
Fabrizio
2012/7/21 jannik.laval <jannik.laval(a)gmail.com>
Hi guys,
Each time we need to do case studies in Moose, we have to select the software
application, in a certain version and probably without all the source code needed. This
results on evaluations that are probably not reproducible.
I think that we need to unify our efforts and share the mse files of our models. With
that, it will be not necessary to generate a FAMIX model each time we need one.
For now, I begun to generate the model from the Qualitas Corpus 'e'
(http://qualitascorpus.com/). There are 486 multiple versions of multiple Java systems.
The mse files are really big (more than 650Mo for Eclipse_SDK3.7). I tried to load the
biggest one in Moose, and it loads ! I just needed to attribute 2Gb of memory in the
info.plist file of Moose 4.6.
I propose to put the files on a server. For all the tar.bz2 files, I need 3.65Gb.
Now, we lack ok at least two pieces of information : (i) the version of verveineJ used
for the extraction. For now, VerveineJ has no version (I took the latest one). (ii) the
version(s) of Moose that can load the file. I tried one mse file with Moose4.6.
We also need a server that can accept all the files.
Any suggestion ?
Jannik
_______________________________________________
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
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
10:42 a.m.
Hi Jannik,
As Fabrizio said, Mircea (and I) is (are) already working at building such a repository.
We would like to share MSE files as a complement to the cited qualitias corpus.
We are also thinking to distribute moose images with a preloaded MSE files.
Some questions:
- is there any reason to support vervainJ instead of InFamix ? Would it make sense to
support both ?
- would anybody be interested in sharing the results of their analyses ? which features
are to be expected from such a service ?
Andrea
_____________________________
Andrea Caracciolo -- caracciolo(a)iam.unibe.ch
Software Composition Group
University of Bern
On Jul 21, 2012, at 7:29 PM, jannik.laval wrote:
Hi guys,
Each time we need to do case studies in Moose, we have to select the software
application, in a certain version and probably without all the source code needed. This
results on evaluations that are probably not reproducible.
I think that we need to unify our efforts and share the mse files of our models. With
that, it will be not necessary to generate a FAMIX model each time we need one.
For now, I begun to generate the model from the Qualitas Corpus 'e'
(http://qualitascorpus.com/). There are 486 multiple versions of multiple Java systems.
The mse files are really big (more than 650Mo for Eclipse_SDK3.7). I tried to load the
biggest one in Moose, and it loads ! I just needed to attribute 2Gb of memory in the
info.plist file of Moose 4.6.
I propose to put the files on a server. For all the tar.bz2 files, I need 3.65Gb.
Now, we lack ok at least two pieces of information : (i) the version of verveineJ used
for the extraction. For now, VerveineJ has no version (I took the latest one). (ii) the
version(s) of Moose that can load the file. I tried one mse file with Moose4.6.
We also need a server that can accept all the files.
Any suggestion ?
Jannik
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
11:56 a.m.
Hi Andrea,
On Jul 23, 2012, at 10:42 AM, Andrea Caracciolo wrote:
Hi Jannik,
As Fabrizio said, Mircea (and I) is (are) already working at building such a repository.
We would like to share MSE files as a complement to the cited qualitias corpus.
We are also thinking to distribute moose images with a preloaded MSE files.
We should discuss about this point particularly. Where are you with your investigations ?
Some questions:
- is there any reason to support vervainJ instead of InFamix ? Would it make sense to
support both ?
This is a long discussion. I know that VerveinJ works fine. It is open-soure and
well-maintained.
Maybe Nicolas Anquetil has already done a comparison between the two importers.
- would anybody be interested in sharing the results
of their analyses ? which features are to be expected from such a service ?
For sure, in experimental study, we need to compare different approaches.
When we have coherent data and reproducible experimentation, it is clearly better.
Jannik
Andrea
_____________________________
Andrea Caracciolo -- caracciolo(a)iam.unibe.ch
Software Composition Group
University of Bern
On Jul 21, 2012, at 7:29 PM, jannik.laval wrote:
---
Jannik Laval
Hi guys,
Each time we need to do case studies in Moose, we have to select the software
application, in a certain version and probably without all the source code needed. This
results on evaluations that are probably not reproducible.
I think that we need to unify our efforts and share the mse files of our models. With
that, it will be not necessary to generate a FAMIX model each time we need one.
For now, I begun to generate the model from the Qualitas Corpus 'e'
(http://qualitascorpus.com/). There are 486 multiple versions of multiple Java systems.
The mse files are really big (more than 650Mo for Eclipse_SDK3.7). I tried to load the
biggest one in Moose, and it loads ! I just needed to attribute 2Gb of memory in the
info.plist file of Moose 4.6.
I propose to put the files on a server. For all the tar.bz2 files, I need 3.65Gb.
Now, we lack ok at least two pieces of information : (i) the version of verveineJ used
for the extraction. For now, VerveineJ has no version (I took the latest one). (ii) the
version(s) of Moose that can load the file. I tried one mse file with Moose4.6.
We also need a server that can accept all the files.
Any suggestion ?
Jannik
_______________________________________________
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
12:05 p.m.
Hi Jannik,
Unfortunately, VerveineJ is not open-source. It is at the moment
available to be used, but as it stands, the license is not specified
at all. This is why the page says that you should contact Stef for
getting information about the license. It would be great to clarify
this point to avoid confusion in the future :).
Cheers,
Doru
Some
questions:
- is there any reason to support vervainJ instead of InFamix ? Would it make sense to
support both ?
This is a long discussion. I know that VerveinJ works fine. It is open-soure and
well-maintained.
Maybe Nicolas Anquetil has already done a comparison between the two importers.
1:04 p.m.
For us we will continue to work on verveineJ and the license will stay like that for a
while until we know were we go.
So for us verveineJ is important because we can control it, fix it…
Stef
Hi Jannik,
Unfortunately, VerveineJ is not open-source. It is at the moment
available to be used, but as it stands, the license is not specified
at all. This is why the page says that you should contact Stef for
getting information about the license. It would be great to clarify
this point to avoid confusion in the future :).
Cheers,
Doru
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Some
questions:
- is there any reason to support vervainJ instead of InFamix ? Would it make sense to
support both ?
This is a long discussion. I know that VerveinJ works fine. It is open-soure and
well-maintained.
Maybe Nicolas Anquetil has already done a comparison between the two importers.
1:28 p.m.
Sure. But, you see, even Jannik who is an Moose insider misunderstood
the status of VerveineJ. This means we have to be more clear somehow.
I added now explicitly a line saying that there is a commercial license.
Should I remove the pointer of how to checkout the source as well?
Doru
On Mon, Jul 23, 2012 at 1:04 PM, Stéphane Ducasse
<stephane.ducasse(a)inria.fr> wrote:
For us we will continue to work on verveineJ and the
license will stay like that for a while until we know were we go.
So for us verveineJ is important because we can control it, fix it…
Stef
--
www.tudorgirba.com
"Every thing has its own flow"
Hi Jannik,
Unfortunately, VerveineJ is not open-source. It is at the moment
available to be used, but as it stands, the license is not specified
at all. This is why the page says that you should contact Stef for
getting information about the license. It would be great to clarify
this point to avoid confusion in the future :).
Cheers,
Doru
_______________________________________________
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 Some
questions:
- is there any reason to support vervainJ instead of InFamix ? Would it make sense to
support both ?
This is a long discussion. I know that VerveinJ works fine. It is open-soure and
well-maintained.
Maybe Nicolas Anquetil has already done a comparison between the two importers.
9:56 p.m.
+1
Now what should I use ? InMoose that I do not control, or VerveineJ.... that is not open
source ?
This is stupid but maybe, I should write mine :)
Jannik
On Jul 23, 2012, at 1:28 PM, Tudor Girba wrote:
Sure. But, you see, even Jannik who is an Moose
insider misunderstood
the status of VerveineJ. This means we have to be more clear somehow.
I added now explicitly a line saying that there is a commercial license.
Should I remove the pointer of how to checkout the source as well?
Doru
On Mon, Jul 23, 2012 at 1:04 PM, Stéphane Ducasse
<stephane.ducasse(a)inria.fr> wrote:
---
Jannik Laval
For us we will continue to work on verveineJ and
the license will stay like that for a while until we know were we go.
So for us verveineJ is important because we can control it, fix it…
Stef
--
www.tudorgirba.com
"Every thing has its own flow"
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev Hi Jannik,
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev > Some questions:
> - is there any reason to support vervainJ instead of InFamix ? Would it make sense to
support both ?
This is a long discussion. I know that VerveinJ works fine. It is open-soure and
well-maintained.
Maybe Nicolas Anquetil has already done a comparison between the two importers.
Unfortunately, VerveineJ is not open-source. It is at the moment
available to be used, but as it stands, the license is not specified
at all. This is why the page says that you should contact Stef for
getting information about the license. It would be great to clarify
this point to avoid confusion in the future :).
Cheers,
Doru
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
11:22 p.m.
+1
Now what should I use ? InMoose that I do not control, or VerveineJ.... that is not open
source ?
This is stupid but maybe, I should write mine :)
give a try to see :)
again we were planning to have a license so that verveineJ is usable for close friends.
I'm sorry but we do not want to give everything for free all the time.
Stef
Jannik
On Jul 23, 2012, at 1:28 PM, Tudor Girba wrote:
Sure. But, you see, even Jannik who is an Moose
insider misunderstood
the status of VerveineJ. This means we have to be more clear somehow.
I added now explicitly a line saying that there is a commercial license.
Should I remove the pointer of how to checkout the source as well?
Doru
On Mon, Jul 23, 2012 at 1:04 PM, Stéphane Ducasse
<stephane.ducasse(a)inria.fr> wrote:
---
Jannik Laval
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev For us we will continue to work on verveineJ and
the license will stay like that for a while until we know were we go.
So for us verveineJ is important because we can control it, fix it…
Stef
--
www.tudorgirba.com
"Every thing has its own flow"
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev Hi Jannik,
>> Some questions:
>> - is there any reason to support vervainJ instead of InFamix ? Would it make
sense to support both ?
>
> This is a long discussion. I know that VerveinJ works fine. It is open-soure and
well-maintained.
> Maybe Nicolas Anquetil has already done a comparison between the two importers.
Unfortunately, VerveineJ is not open-source. It is at the moment
available to be used, but as it stands, the license is not specified
at all. This is why the page says that you should contact Stef for
getting information about the license. It would be great to clarify
this point to avoid confusion in the future :).
Cheers,
Doru
_______________________________________________
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 
11:40 p.m.
I will soon bump into this problem. Roassal for VisualWorks and Pharo is and will remain
open source.
We will soon release the Amber version, which will then be available to the whole
JavaScript World. Should Roassal for Amber stay open source? Well... It is not clear. It
will naturally be to the Amber community, but I am not sure outside.
It would be cool to hear some experience on that topic. Maybe a "lite" version
for the whole World, and a full-fledged one as soon as you pay. This is the model
frequently used in the Mobile App.
Stef, why the INRIA guys did not come with a solution yet? I guess they have seen this
situation many times haven't they?
Cheers,
Alexandre
On Jul 23, 2012, at 5:22 PM, Stéphane Ducasse wrote:
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
+1
Now what should I use ? InMoose that I do not control, or VerveineJ.... that is not open
source ?
This is stupid but maybe, I should write mine :)
give a try to see :)
again we were planning to have a license so that verveineJ is usable for close friends.
I'm sorry but we do not want to give everything for free all the time.
Stef
Jannik
On Jul 23, 2012, at 1:28 PM, Tudor Girba wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev Sure. But, you see, even Jannik who is an Moose
insider misunderstood
the status of VerveineJ. This means we have to be more clear somehow.
I added now explicitly a line saying that there is a commercial license.
Should I remove the pointer of how to checkout the source as well?
Doru
On Mon, Jul 23, 2012 at 1:04 PM, Stéphane Ducasse
<stephane.ducasse(a)inria.fr> wrote:
---
Jannik Laval
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev For us we will continue to work on verveineJ and
the license will stay like that for a while until we know were we go.
So for us verveineJ is important because we can control it, fix it…
Stef
> Hi Jannik,
>
>>> Some questions:
>>> - is there any reason to support vervainJ instead of InFamix ? Would it make
sense to support both ?
>>
>> This is a long discussion. I know that VerveinJ works fine. It is open-soure and
well-maintained.
>> Maybe Nicolas Anquetil has already done a comparison between the two importers.
>
> Unfortunately, VerveineJ is not open-source. It is at the moment
> available to be used, but as it stands, the license is not specified
> at all. This is why the page says that you should contact Stef for
> getting information about the license. It would be great to clarify
> this point to avoid confusion in the future :).
>
>
> Cheers,
> Doru
> _______________________________________________
> 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
"Every thing has its own flow"
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
24 Jul
24 Jul
9:14 p.m.
On Jul 23, 2012, at 11:22 PM, Stéphane Ducasse wrote:
:) it was just a joke.
I want to say that I am not sure the message is good: "you can use Moose, it is
open-source, but must pay for importing data".
You are right, this is a commercial message, and maybe it is a bonus for Synectique...
Now, I have a researcher point of view and I think that using a tool that is open source
is easier than contacting guys and maybe they answer or not. And if not ? I will use
another tool.
I only give my opinion on something that does not concern me directly.
Jannik
+1
Now what should I use ? InMoose that I do not control, or VerveineJ.... that is not open
source ?
This is stupid but maybe, I should write mine :)
give a try to see :)
again we were planning to have a license so that verveineJ is usable for close friends.
I'm sorry but we do not want to give everything for free all the time.
Stef
---
Jannik Laval
Jannik
On Jul 23, 2012, at 1:28 PM, Tudor Girba wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev Sure. But, you see, even Jannik who is an Moose
insider misunderstood
the status of VerveineJ. This means we have to be more clear somehow.
I added now explicitly a line saying that there is a commercial license.
Should I remove the pointer of how to checkout the source as well?
Doru
On Mon, Jul 23, 2012 at 1:04 PM, Stéphane Ducasse
<stephane.ducasse(a)inria.fr> wrote:
---
Jannik Laval
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev For us we will continue to work on verveineJ and
the license will stay like that for a while until we know were we go.
So for us verveineJ is important because we can control it, fix it…
Stef
> Hi Jannik,
>
>>> Some questions:
>>> - is there any reason to support vervainJ instead of InFamix ? Would it make
sense to support both ?
>>
>> This is a long discussion. I know that VerveinJ works fine. It is open-soure and
well-maintained.
>> Maybe Nicolas Anquetil has already done a comparison between the two importers.
>
> Unfortunately, VerveineJ is not open-source. It is at the moment
> available to be used, but as it stands, the license is not specified
> at all. This is why the page says that you should contact Stef for
> getting information about the license. It would be great to clarify
> this point to avoid confusion in the future :).
>
>
> Cheers,
> Doru
> _______________________________________________
> 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
"Every thing has its own flow"
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
9:23 p.m.
Now, I have a researcher point of view and I think
that using a tool that is open source is easier than contacting guys and maybe they answer
or not. And if not ? I will use another tool.
did you send an email and did not get
an answer? I guess not so there is no problem.
I think that having a company around moose is the best that can happen to Moose even if it
can make the system more complex.
If we play smart everybody can benefit from it.
If synectique fails then it will be far easier but much sadder.
I only give my opinion on something that does not
concern me directly.
:)
9:38 p.m.
On Jul 24, 2012, at 9:23 PM, Stéphane Ducasse wrote:
I'm sorry but we do not want to give everything for free all the time.
:) it was just a joke.
I want to say that I am not sure the message is good: "you can use Moose, it is
open-source, but must pay for importing data".
You are right, this is a commercial message, and maybe it is a bonus for Synectique...
It is not a bonus. It is important. Our goal is to make sure that our company gets a
chance in face of the too many companies in the field.
Not from you, but we are experimenting some tools and guys do not answers about their
tools... so not possible to compare.
---
Jannik Laval
Now, I have a researcher point of view and I
think that using a tool that is open source is easier than contacting guys and maybe they
answer or not. And if not ? I will use another tool.
did you send an email and did
not get an answer? I guess not so there is no problem. I think that having a company around moose is the best
that can happen to Moose even if it can make the system more complex.
If we play smart everybody can benefit from it.
If synectique fails then it will be far easier but much sadder.
You are probably right.
And I hope the best for Synectique.
Jannik
I only give my opinion on something that does not
concern me directly.
:)
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 
25 Jul
25 Jul
12:45 a.m.
Hello all,
Rapidly sharing some points with you guys regarding Synectique and this
community...
- VerveinJ should be available to you guys to conduct your experiments,
extract MSEs and save them. As Stef mentioned, it should be free and open
to use for the people in the community. This is because VJ has improved a
lot because of the feedback from the community and we do not want to lose
this precious loop.
- Synectique is transitioning from "not-sure" to "looks interesting"
phase
so from September we should start to look for appropriate usage licences
for VerveineJ so that will clarify the "not sure" situation around VJ.
- May be this is pharo-related issue but very soon we need to look for a
database to store analysis results because i) we need to store a lot of
data ii) we do not want to get into resolving issues related to data
consistency, concurrent accesses, data merging, etc.
- Companies working in the domain of software analysis have this constant
size problem: very soon we will face it too. Since, this community gathers
some of the most exp. people in software analysis, it would be good to see
how we can innovate in Moose to resolve the problem.
And thanx a lot for all the tools created in this community that serves us
as enabling techno. Currently, we might not have sufficient time to improve
the Moose infrastructure as we would like to but the least we can do is to
contribute with our feedback on the tools and improve them whenever we can.
regards,
Usman
www.synectique.eu
On Tue, Jul 24, 2012 at 9:38 PM, jannik.laval <jannik.laval(a)gmail.com>wrote;wrote:
On Jul 24, 2012, at 9:23 PM, Stéphane Ducasse wrote:
---
Jannik Laval
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>> I'm sorry but we do not want to give everything for free all the time.
>
> :) it was just a joke.
> I want to say that I am not sure the message is good: "you can use
Moose,
it is open-source, but must pay for importing data".
> You are right, this is a commercial message,
and maybe it is a bonus
for Synectique...
It is not a bonus. It is important. Our goal is to make sure that our
company gets
a chance in face of the too many companies in the field.
> Now, I have a researcher point of view and I think that using a tool
that is
open source is easier than contacting guys and maybe they answer or
not. And if not ? I will use another tool.
did you send an email and did not get an answer?
I guess not so there is
no problem.
Not from you, but we are experimenting some tools and guys do not answers
about their tools... so not possible to compare.
I think that having a company around moose is the
best that can happen
to Moose even if it can make the system more complex.
If we play smart everybody can benefit from it.
If synectique fails then it will be far easier but much sadder.
You are probably right.
And I hope the best for Synectique.
Jannik
I only give my opinion on something that does not
concern me directly.
:)
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
23 Jul
23 Jul
9:54 p.m.
On Jul 23, 2012, at 12:05 PM, Tudor Girba wrote:
Hi Jannik,
Unfortunately, VerveineJ is not open-source. It is at the moment
available to be used, but as it stands, the license is not specified
at all. This is why the page says that you should contact Stef for
getting information about the license. It would be great to clarify
this point to avoid confusion in the future :).
Ok, the status has changed no ?
Why is it not clear about the status ?
Jannik
Some
questions:
- is there any reason to support vervainJ instead of InFamix ? Would it make sense to
support both ?
This is a long discussion. I know that VerveinJ works fine. It is open-soure and
well-maintained.
Maybe Nicolas Anquetil has already done a comparison between the two importers.
Cheers,
Doru
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
---
Jannik Laval
11:20 p.m.
On Jul 23, 2012, at 9:54 PM, jannik.laval wrote:
On Jul 23, 2012, at 12:05 PM, Tudor Girba wrote:
because we do not know if having a java extractor cannot kill synectique.
So between giving a chance to synectique and having an open-source project we chose to
give a chance to synectique
and again there should be a middle way: this can be something else than open-source or
nothing but so far nobody pushed the idea further.
Hi Jannik,
Unfortunately, VerveineJ is not open-source. It is at the moment
available to be used, but as it stands, the license is not specified
at all. This is why the page says that you should contact Stef for
getting information about the license. It would be great to clarify
this point to avoid confusion in the future :).
Ok, the status has changed no ?
Why is it not clear about the status ? Some
questions:
- is there any reason to support vervainJ instead of InFamix ? Would it make sense to
support both ?
This is a long discussion. I know that VerveinJ works fine. It is open-soure and
well-maintained.
Maybe Nicolas Anquetil has already done a comparison between the two importers. Jannik
Cheers,
Doru
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
---
Jannik Laval
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
2:50 p.m.
On Jul 23, 2012, at 11:56 AM, jannik.laval wrote:
We already have a couple of ideas and we think it would be interesting to explore such an
option.
Having all contributed results in a common format would benefit information sharing and
data comparison.
Does anybody have any idea about any possible usage of such kind of information ?
Is there any existing data format which could be used to specify these data (keeping a
link to the MSE model entities) ?
Hi Andrea,
On Jul 23, 2012, at 10:42 AM, Andrea Caracciolo wrote:
I have recently written a simple script which is able to load a given MSE file into a
specified moose image, and save everything as a new image.
Sharing such images would save a lot of time to the end-user and is another little step to
having consistent and reproducible analysis results.
question: how fast is the moose release cycle ?
Hi Jannik,
As Fabrizio said, Mircea (and I) is (are) already working at building such a repository.
We would like to share MSE files as a complement to the cited qualitias corpus.
We are also thinking to distribute moose images with a preloaded MSE files.
We should discuss about this point particularly. Where are you with your investigations
Some questions:
- is there any reason to support vervainJ instead of InFamix ? Would it make sense to
support both ?
This is a long discussion. I know that VerveinJ works fine. It is open-soure and
well-maintained.
Maybe Nicolas Anquetil has already done a comparison between the two importers.
- would anybody be interested in sharing the
results of their analyses ? which features are to be expected from such a service ?
For sure, in experimental study, we need to compare different approaches.
When we have coherent data and reproducible experimentation, it is clearly better Jannik
Andrea
_____________________________
Andrea Caracciolo -- caracciolo(a)iam.unibe.ch
Software Composition Group
University of Bern
On Jul 21, 2012, at 7:29 PM, jannik.laval wrote:
---
Jannik Laval
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev Hi guys,
Each time we need to do case studies in Moose, we have to select the software
application, in a certain version and probably without all the source code needed. This
results on evaluations that are probably not reproducible.
I think that we need to unify our efforts and share the mse files of our models. With
that, it will be not necessary to generate a FAMIX model each time we need one.
For now, I begun to generate the model from the Qualitas Corpus 'e'
(http://qualitascorpus.com/). There are 486 multiple versions of multiple Java systems.
The mse files are really big (more than 650Mo for Eclipse_SDK3.7). I tried to load the
biggest one in Moose, and it loads ! I just needed to attribute 2Gb of memory in the
info.plist file of Moose 4.6.
I propose to put the files on a server. For all the tar.bz2 files, I need 3.65Gb.
Now, we lack ok at least two pieces of information : (i) the version of verveineJ used
for the extraction. For now, VerveineJ has no version (I took the latest one). (ii) the
version(s) of Moose that can load the file. I tried one mse file with Moose4.6.
We also need a server that can accept all the files.
Any suggestion ?
Jannik
_______________________________________________
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
11:19 p.m.
We should discuss about this point particularly. Where are you with your investigations
I have recently written a simple script which is able to load a given MSE file into a
specified moose image, and save everything as a new image.
Sharing such images would save a lot of time to the end-user and is another little step
to having consistent and reproducible analysis results. question: how fast is the moose release cycle ?
We already have a couple of ideas and we think it would be interesting to explore such an
option.
Having all contributed results in a common format would benefit information sharing and
data comparison.
but use is not that one?
I do not get your sentence
Some questions:
- is there any reason to support vervainJ instead of InFamix ? Would it make sense to
support both ?
This is a long discussion. I know that VerveinJ works fine. It is open-soure and
well-maintained.
Maybe Nicolas Anquetil has already done a comparison between the two importers.
- would anybody be interested in sharing the
results of their analyses ? which features are to be expected from such a service ?
For sure, in experimental study, we need to compare different approaches.
When we have coherent data and reproducible experimentation, it is clearly better
Does anybody have any idea about any possible usage of such kind of information ?
you are talking about meta information
In famix 1.0
in the file header there was one entity describing the model.
what we could do is either
- have a separate file in use format (= reuse of parser) containing information and the
file name of the model to which they refer
- or have the information inside the mse model by having an entity representing the
model (we did that in some old moose versions).
Is there any existing data format which could be used
to specify these data (keeping a link to the MSE model entities) ?
Jannik
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Andrea
_____________________________
Andrea Caracciolo -- caracciolo(a)iam.unibe.ch
Software Composition Group
University of Bern
On Jul 21, 2012, at 7:29 PM, jannik.laval wrote:
---
Jannik Laval
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev Hi guys,
Each time we need to do case studies in Moose, we have to select the software
application, in a certain version and probably without all the source code needed. This
results on evaluations that are probably not reproducible.
I think that we need to unify our efforts and share the mse files of our models. With
that, it will be not necessary to generate a FAMIX model each time we need one.
For now, I begun to generate the model from the Qualitas Corpus 'e'
(http://qualitascorpus.com/). There are 486 multiple versions of multiple Java systems.
The mse files are really big (more than 650Mo for Eclipse_SDK3.7). I tried to load the
biggest one in Moose, and it loads ! I just needed to attribute 2Gb of memory in the
info.plist file of Moose 4.6.
I propose to put the files on a server. For all the tar.bz2 files, I need 3.65Gb.
Now, we lack ok at least two pieces of information : (i) the version of verveineJ used
for the extraction. For now, VerveineJ has no version (I took the latest one). (ii) the
version(s) of Moose that can load the file. I tried one mse file with Moose4.6.
We also need a server that can accept all the files.
Any suggestion ?
Jannik
_______________________________________________
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 
24 Jul
24 Jul
11:03 a.m.
some comments on all I read in this thread:
- the idea of unified repository is very nice for research. It is
important if we want to be able to share results, and reproduce experiments.
Could it have some interest for industry projects?
For example, it could be usefull as a comparison base for a company to
understand how good or bad its own software is compared to some other
(presumably open source) projects ...
- keeping source code (and much more) is important because you never
know what people would like to do in the future.
It happened to a team in Brazil recently, they correlated some metrics
to bugs.
So they needed on top of the MSEs: access to a bug-tracking system to
identify bug-identifiers; access to SVN commit comments to identify
bug-fixing commits; access to the code to know what methods/classes were
changed to correct the bug.
Anyway, people want to see source code. If something looks strange in a
visualization, you want to go back to the code to understand what's
happening.
- metadata verveinej version.
For now, what I do is I keep a copy of verveinej along with the project.
It is not big (<20Mo.)
Anyway, it does not change that much, just keeping the date of the
download should be enough for now to track versions.
- server generated MSEs.
It can be a nice thing for small projects, but from my experience,
generating MSEs is not trivial.
Think about it like compiling a project (converting from one language to
another).
It requires setting up the path correctly, pointing to the right
libraries, may be generating some source code, ...
Not something you can automate.
And for industry, it would not work. A company would be very cautious
about sending its source code to some unknown server.
- memory
I commented with Jannik that a 2Gb. image for a 650Mo. MSE file looks
like a huge difference to me.
This is an issue because the VM is constrained in memory whereas the
size of software systems does not seem to be :-)
How can we deal with REAL BIG systems? 10 MLOCs for example ?
- verveineJ vs. inFamix
I never really used inFamix, so I cannot tell.
Doru seems to be the one that knows better both projects (and all of
Moose as usual :-) ).
May be he has some idea on the pros/cons of each tool ?
- licence: We are trying to startup a business around moose. We think
this is something that could be profitable to the entire community. On
the other hand, this is not something easy to do and we need to take
care not to shoot ourselves in the foot. It is like raising a baby, it
is better to be a bit over protective and correct things afterwards than
to be too much confident and risking a serious accident ...
So the license is closed for now and we give explicit permission to
friends to use it.
And we did not yet formalize it at the moment simply because it does not
rely only on us, it requires legal knowledge that we don't have, and
above all there are a lot of other things to do that are more urgent.
As for rewriting a new (open) one. Yes you could. But why loosing time
with this? The solutions exist for now that you can use and work with.
If in the future the situation is really unbearable, then you can think
of investing time in correcting it.
(and as mentioned, don't underestimate the amount of work it represents.
Sure, any of us can do it, but it means months of effort, do you really
have that much free time to spend ?)
nicolas
9:21 p.m.
Hi Nico,
On Jul 24, 2012, at 11:03 AM, Nicolas Anquetil wrote:
some comments on all I read in this thread:
- the idea of unified repository is very nice for research. It is important if we want to
be able to share results, and reproduce experiments.
Could it have some interest for industry projects?
For example, it could be usefull as a comparison base for a company to understand how
good or bad its own software is compared to some other (presumably open source) projects
...
- keeping source code (and much more) is important because you never know what people
would like to do in the future.
It happened to a team in Brazil recently, they correlated some metrics to bugs.
So they needed on top of the MSEs: access to a bug-tracking system to identify
bug-identifiers; access to SVN commit comments to identify bug-fixing commits; access to
the code to know what methods/classes were changed to correct the bug.
Anyway, people want to see source code. If something looks strange in a visualization,
you want to go back to the code to understand what's happening.
- metadata verveinej version.
For now, what I do is I keep a copy of verveinej along with the project. It is not big
(<20Mo.)
Anyway, it does not change that much, just keeping the date of the download should be
enough for now to track versions.
Tis is what I do for now.
- server generated MSEs.
It can be a nice thing for small projects, but from my experience, generating MSEs is not
trivial.
Think about it like compiling a project (converting from one language to another).
It requires setting up the path correctly, pointing to the right libraries, may be
generating some source code, ...
Not something you can automate.
And for industry, it would not work. A company would be very cautious about sending its
source code to some unknown server.
- memory
I commented with Jannik that a 2Gb. image for a 650Mo. MSE file looks like a huge
difference to me.
This is an issue because the VM is constrained in memory whereas the size of software
systems does not seem to be :-)
How can we deal with REAL BIG systems? 10 MLOCs for example ?
That is a problem. We will overpass this problem by increasing the memory of the VM, but
it does not solve the problem.
Maybe a database...
- verveineJ vs. inFamix
I never really used inFamix, so I cannot tell.
Doru seems to be the one that knows better both projects (and all of Moose as usual :-)
).
May be he has some idea on the pros/cons of each tool ?
- licence: We are trying to startup a business around moose. We think this is something
that could be profitable to the entire community. On the other hand, this is not something
easy to do and we need to take care not to shoot ourselves in the foot. It is like raising
a baby, it is better to be a bit over protective and correct things afterwards than to be
too much confident and risking a serious accident ...
So the license is closed for now and we give explicit permission to friends to use it.
And we did not yet formalize it at the moment simply because it does not rely only on us,
it requires legal knowledge that we don't have, and above all there are a lot of other
things to do that are more urgent.
As for rewriting a new (open) one. Yes you could. But why loosing time with this? The
solutions exist for now that you can use and work with. If in the future the situation is
really unbearable, then you can think of investing time in correcting it.
(and as mentioned, don't underestimate the amount of work it represents. Sure, any of
us can do it, but it means months of effort, do you really have that much free time to
spend ?)
I do not really want to do this, but if Moose become close, what about the community ?
The reason why we move from Visual Work to Pharo is because Pharo is open-source and we
control it.
Jannik
nicolas
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
---
Jannik Laval
9:32 p.m.
- memory
I commented with Jannik that a 2Gb. image for a 650Mo. MSE file looks like a huge
difference to me.
This is an issue because the VM is constrained in memory whereas the size of software
systems does not seem to be :-)
How can we deal with REAL BIG systems? 10 MLOCs for example ?
I hope that in the future pharo will be able to run and use 64 bits.
Now the GC would have to be changed too. This is why the consortium is important to be
able to get some work done
to make the future safer.
Now it would be interested to experiment with some database backend and gemstone like
solutions. Now that FAMIX3.0 is
fully meta described (which was not the case with famix10 and 20) it should be easier.
Stef
11:40 a.m.
Does anybody have any idea about any possible usage of such kind of
information ?
you are talking about meta information
In famix 1.0
in the file header there was one entity describing the model.
what we could do is either
- have a separate file in use format (= reuse of parser)
containing information and the file name of the model to which they refer
- or have the information inside the mse model by having
an entity representing the model (we did that in some old moose versions).
3:38 p.m.
Hi guys,
Some small observations:
*Reduced Models*
- Having reduced (partial) models is a nice idea. An even nicer one would
be to have partial loading of the model. But until that happens, I guess
the partial models could be a solution... And still, having the full
Qualitas Corpus loaded even with partial models is impossible. I guess this
is what Stef proposed to address by having the Project be just a proxy and
loading it on demand, only that this might be too expensive.
In my experience, loading a MSE file for an average system takes between 3
and 5 minutes. Imagine that you want to collect the number of classes in
each of the systems in the QC. you have 150 systems * 3 minutes each for
loading the model = 7.5 hours. And imagine that after that you want to
count the number of methods in each of the systems... This is why with
Andrea we thought about caching Moose images preloaded with the systems in
the Qualitas Corpus. In this way I could run a new analysis on the entire
corpus in 10 minutes: I open an image, load the latest version of my
analysis package if needed, run the analysis, return the results and close.
On the other hand, maybe the alternative to this an image per system could
be to serialize the FAMIX models with Fuel and hope that loading an entire
system with it would be waaay faster than when loading an MSE file.
*Evolutionary Analysis*
- I seem to remember talking at some point with Andy Kellens and him
mentioning that they had an incremental model of FAMIX for modeling
evolutionary analysis. This would allow them to only represent the deltas
between two versions. We had this discussion last year at Sattose. Does
anybody know anything about that? That would be the right solution for
doing evolutionary analysis. Otherwise we should just be happy with
analyzing at most a dozen versions at once, as many as fit in memory. Or
loading things on demand if we find a fast way.
*Memory*
Did anybody look into using Gemstone...?
*Server*
Jannik I guess we could use one of the servers at SCG if needed for serving
this information.
Cheers,
M.
On Tue, Jul 24, 2012 at 11:40 AM, Fabrizio Perin
<fabrizio.perin(a)gmail.com>wrote;wrote:
I would prefer a separate file. If the idea is to setup a repository of
projects the meta info are about a project together with its mse file not
just about the mse.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Does anybody have any idea about any possible
usage of such kind of
information ?
you are talking about meta information
In famix 1.0
in the file header there was one entity describing the model.
what we could do is either
- have a separate file in use format (= reuse of parser)
containing information and the file name of the model to which they refer
- or have the information inside the mse model by having
an entity representing the model (we did that in some old moose versions).
3:45 p.m.
On 24/07/12 15:38, Mircea Filip Lungu wrote:
In my experience, loading a MSE file for an average system takes
between 3 and 5 minutes. Imagine that you want to collect the number
of classes in each of the systems in the QC. you have 150 systems * 3
minutes each for loading the model = 7.5 hours. And imagine that after
that you want to count the number of methods in each of the systems...
This is why with Andrea we thought about caching Moose images
preloaded with the systems in the Qualitas Corpus. In this way I could
run a new analysis on the entire corpus in 10 minutes: I open an
image, load the latest version of my analysis package if needed, run
the analysis, return the results and close.
- images are dependent on the smalltalk
code.
In three years these images will be completly outdated and one will need
to reload all of pharo and moose to be able to use them which will
probably take much more than 5 minutes.
Which is not saying that the loading should be faster.
Actually saving a model is very slow too, ...
Maybe it is something in the way Fame is implemented ?
- from an experimental point of view, 8 hours is not a lot.You do it
once, you get your results and that'sit.
27 Jul
27 Jul
11:26 p.m.
On Jul 24, 2012, at 3:45 PM, Nicolas Anquetil wrote:
- images are dependent on the smalltalk code.
In three years these images will be completly outdated and one will need to reload all of
pharo and moose to be able to use them which will probably take much more than 5 minutes.
Sounds like a job for Jenkins.
Stephan
24 Jul
24 Jul
4:54 p.m.
On Tue, Jul 24, 2012 at 3:38 PM, Mircea Filip Lungu
<mircea.lungu(a)gmail.com>wrote;wrote:
With this idea, you need to be aware that you will lose (a lot of) data.
You will lose data because several (derived) properties are calculated by
Moose and you don't have access to such information directly in your MSE.
For instance, suppose you want to load only the entities FAMIXPackage and
FAMIXClass. Then your classes you will not have information about the
attributes, since FAMIXClass>>attributes is derived (in fact, you need to
have FAMIXAttribute in your model). Then, AFAIK this is not good and also
option (1) above is not so good. Then, option (2) is better.
But until that happens, I guess the partial models could be a solution...
> And still, having the full Qualitas Corpus loaded even with partial models
> is impossible. I guess this is what Stef proposed to address by having the
> Project be just a proxy and loading it on demand, only that this might be
> too expensive.
> In my experience, loading a MSE file for an
average system takes between 3
> and 5 minutes. Imagine that you want to collect the number of classes in
> each of the systems in the QC. you have 150 systems * 3 minutes each for
> loading the model = 7.5 hours. And imagine that after that you want to
> count the number of methods in each of the systems... This is why with
> Andrea we thought about caching Moose images preloaded with the systems in
> the Qualitas Corpus. In this way I could run a new analysis on the entire
> corpus in 10 minutes: I open an image, load the latest version of my
> analysis package if needed, run the analysis, return the results and close.
> On the other hand, maybe the alternative to
this an image per system could
> be to serialize the FAMIX models with Fuel and hope that loading an entire
> system with it would be waaay faster than when loading an MSE file.
> *Evolutionary Analysis*
> - I seem to remember talking at some point with Andy Kellens and him
> mentioning that they had an incremental model of FAMIX for modeling
> evolutionary analysis. This would allow them to only represent the deltas
> between two versions. We had this discussion last year at Sattose. Does
> anybody know anything about that? That would be the right solution for
> doing evolutionary analysis. Otherwise we should just be happy with
> analyzing at most a dozen versions at once, as many as fit in memory. Or
> loading things on demand if we find a fast way.
If you need just class and package data, then I think Hismo will work
pretty well. Model with just classes and packages are very small, and you
load hundreds small models in Hismo.
> *Memory*
> Did anybody look into using Gemstone...?
> *Server*
> Jannik I guess we could use one of the servers at SCG if needed for
> serving this information.
> Cheers,
> M.
> On Tue, Jul 24, 2012 at 11:40 AM, Fabrizio
Perin <fabrizio.perin(a)gmail.com
> > wrote:
>
>> >>> >
Does anybody have any idea about any possible usage of such kind of
>>> information ?
>>> you are talking about meta information
>>> In famix 1.0
>>> in the file header there was one entity describing the model.
>>> what we could do is either
>>> - have a separate file in use format (= reuse of parser)
>>> containing information and the file name of the model to which they refer
>>> - or have the information inside the mse model by having
>>> an entity representing the model (we did that in some old moose versions).
>> >> >>
>> I would prefer a separate file. If the idea is to setup a repository of
>> projects the meta info are about a project together with its mse file not
>> just about the mse.
> >
> >>
_______________________________________________
>> 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
--
Andre Hora
Hi guys,
Some small observations:
*Reduced Models*
- Having reduced (partial) models is a nice idea.
Yes. You can have reduced models either by:
- (1) exporting a reduced (MSE) version from VerveineJ (I guess this is
implemented);
- (2) or, importing your full model in Moose and then exporting the
entities you want (this is also implemented, not sure if this integrated);
An even nicer one would be to have partial loading of the model.
5:44 p.m.
- the idea of unified repository is very nice for
research. It is important if we want to be able to share results, and reproduce
experiments.
Could it have some interest for industry projects?
For example, it could be usefull as a comparison base for a company to understand how
good or bad its own software is compared to some other (presumably open source) projects
...
Our idea is to build an open repository containing a collection of models from a large
group of projects (qualitas corpus), where each of these models can be annotated and
expanded with analysis results.
Analysis results could be anything (i.e. all classes of a certain project can be annotated
with a certain metric; two classes can be related by a duplication relationship; etc.. ).
The resulting "expanded models" can be queried or downloaded (useful if you want
to compare the data against results of an industrial project analysis).
MSE files are used as a way to import a simple version (no contributed analysis results
annotations) of the project model into moose and enable new analyses.
Yes. You can have reduced models either by:
- (1) exporting a reduced (MSE) version from VerveineJ (I guess this is implemented);
- (2) or, importing your full model in Moose and then exporting the entities you want
(this is also implemented, not sure if this integrated);
Distributing reduced MSE models of a project does not make much sense to me. You have to
take in consideration multiple analysis requirements and build a reduced model for each of
them.
Would it be possible (and would it make sense) to create a web service which interprets
moose queries, runs them on the specified target image and returns a serialized
representation of the returned objects ?
- keeping source code (and much more) is important
because you never know what people would like to do in the future.
It happened to a team in Brazil recently, they correlated some metrics to bugs.
So they needed on top of the MSEs: access to a bug-tracking system to identify
bug-identifiers; access to SVN commit comments to identify bug-fixing commits; access to
the code to know what methods/classes were changed to correct the bug.
Anyway, people want to see source code. If something looks strange in a visualization,
you want to go back to the code to understand what's happening.
Since qualitascorpus.com already provides and maintains a good collection of java
projects, we thought about reusing that valuable source of information and building the
MSE repository as a complement to Qualitas Corpus.
This means that MSE files would be generated and hosted by us and source code can be
downloaded from qualitascorpus.com.
Andrea
8:12 p.m.
Yes. You can have reduced models either by:
- (1) exporting a reduced (MSE) version from VerveineJ (I guess this is implemented);
- (2) or, importing your full model in Moose and then exporting the entities you want
(this is also implemented, not sure if this integrated);
Distributing reduced MSE models of a project does not make much sense to me. You have to take in consideration multiple analysis
requirements and build a reduced model for each of them.
Would it be possible (and would it make sense) to create a web service which interprets
moose queries, runs them on the specified target image and returns a serialized
representation of the returned objects ?
I would always version the source code and the mse (as well as the version of the tools
used to extracted it).
HD is cheap and you always want to get all the information if you can.
- keeping source code (and much more) is
important because you never know what people would like to do in the future.
It happened to a team in Brazil recently, they correlated some metrics to bugs.
So they needed on top of the MSEs: access to a bug-tracking system to identify
bug-identifiers; access to SVN commit comments to identify bug-fixing commits; access to
the code to know what methods/classes were changed to correct the bug.
Anyway, people want to see source code. If something looks strange in a visualization,
you want to go back to the code to understand what's happening.
Since qualitascorpus.com already provides and maintains a good collection of java
projects, we thought about reusing that valuable source of information and building the
MSE repository as a complement to Qualitas Corpus. This means that MSE files would be generated and
hosted by us and source code can be downloaded from qualitascorpus.com.
I would follow an object-oriented approach: project with all data together and
encapsulated.
Andrea
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
9:33 p.m.
- keeping source code (and much more) is
important because you never know what people would like to do in the future.
It happened to a team in Brazil recently, they correlated some metrics to bugs.
So they needed on top of the MSEs: access to a bug-tracking system to identify
bug-identifiers; access to SVN commit comments to identify bug-fixing commits; access to
the code to know what methods/classes were changed to correct the bug.
Anyway, people want to see source code. If something looks strange in a visualization,
you want to go back to the code to understand what's happening.
Since qualitascorpus.com already provides and maintains a good collection of java
projects, we thought about reusing that valuable source of information and building the
MSE repository as a complement to Qualitas Corpus.
This means that MSE files would be generated and hosted by us and source code can be
downloaded from qualitascorpus.com.
Andrea
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
---
Jannik Laval
25 Jul
25 Jul
3:59 p.m.
On Jul 24, 2012, at 9:33 PM, jannik.laval wrote:
Ok, all the MSE files are generated, I have them.
I will share them.
For the metadata, I propose to use an xml file that is independent of mse files / source
files.
why xml?
We could use use as use as well. It is usually much more readable than xml.
- keeping source code (and much more) is
important because you never know what people would like to do in the future.
It happened to a team in Brazil recently, they correlated some metrics to bugs.
So they needed on top of the MSEs: access to a bug-tracking system to identify
bug-identifiers; access to SVN commit comments to identify bug-fixing commits; access to
the code to know what methods/classes were changed to correct the bug.
Anyway, people want to see source code. If something looks strange in a visualization,
you want to go back to the code to understand what's happening.
Since qualitascorpus.com already provides and maintains a good collection of java
projects, we thought about reusing that valuable source of information and building the
MSE repository as a complement to Qualitas Corpus.
This means that MSE files would be generated and hosted by us and source code can be
downloaded from qualitascorpus.com.
It could contains all the informations that we
discussed here.
Jannik
Andrea
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
---
Jannik Laval
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
26 Jul
26 Jul
7:29 p.m.
On Jul 25, 2012, at 3:59 PM, Stéphane Ducasse <stephane.ducasse(a)inria.fr> wrote:
---
Jannik Laval
On Jul 24, 2012, at 9:33 PM, jannik.laval wrote:
Ok, all the MSE files are generated, I have them.
I will share them.
For the metadata, I propose to use an xml file that is independent of mse files / source
files.
why xml?
We could use use as use as well. It is usually much more readable than xml.
iep,
Just that xml is verbose :)
But mse is good too.
Jannik
- keeping source code (and much more) is
important because you never know what people would like to do in the future.
It happened to a team in Brazil recently, they correlated some metrics to bugs.
So they needed on top of the MSEs: access to a bug-tracking system to identify
bug-identifiers; access to SVN commit comments to identify bug-fixing commits; access to
the code to know what methods/classes were changed to correct the bug.
Anyway, people want to see source code. If something looks strange in a visualization,
you want to go back to the code to understand what's happening.
Since qualitascorpus.com already provides and maintains a good collection of java
projects, we thought about reusing that valuable source of information and building the
MSE repository as a complement to Qualitas Corpus.
This means that MSE files would be generated and hosted by us and source code can be
downloaded from qualitascorpus.com.
It could contains all the informations that we
discussed here.
Jannik
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev Andrea
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
---
Jannik Laval
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
27 Jul
27 Jul
4:04 p.m.
On Jul 26, 2012, at 7:29 PM, jannik.laval wrote:
On Jul 25, 2012, at 3:59 PM, Stéphane Ducasse <stephane.ducasse(a)inria.fr> wrote:
A separate MSE file or the same where the famix model is in ?
i tried to write down a list of all the meta-data needed:
- project name
- project version
- verveineJ version (i would use the SVN revision number)
is it enough ?
should we include the FAMIX version ?
I didn't include the supported moose version, because i don't think it's
relevant and i don't see how this information should be interpreted.
The rest of the data should be the following:
- MSE of FAMIX model
- source code
If there are multiple versions of a project, it would be also interesting to distribute an
Orion model of all the versions.
Is it possible to build such a model having an MSE file for each version as input ?
How much effort is needed to fix the bugs and make it work ?
How do you look for changes between subsequent versions ? Do you diff the source code of
the analyzed code entities ?
Would it make sense to distribute also a FUEL file containing the famix model ?
Would it make loading faster ?
On Jul 24, 2012, at 9:33 PM, jannik.laval wrote:
why xml?
We could use use as use as well. It is usually much more readable than xml.
iep,
Just that xml is verbose :)
But mse is good too.
> - keeping source code (and much more) is important because you never know what people
would like to do in the future.
> It happened to a team in Brazil recently, they correlated some metrics to bugs.
> So they needed on top of the MSEs: access to a bug-tracking system to identify
bug-identifiers; access to SVN commit comments to identify bug-fixing commits; access to
the code to know what methods/classes were changed to correct the bug.
> Anyway, people want to see source code. If something looks strange in a
visualization, you want to go back to the code to understand what's happening.
Since qualitascorpus.com already provides and maintains a good collection of java
projects, we thought about reusing that valuable source of information and building the
MSE repository as a complement to Qualitas Corpus.
This means that MSE files would be generated and hosted by us and source code can be
downloaded from qualitascorpus.com.
Ok, all the MSE files are generated, I have them.
I will share them.
For the metadata, I propose to use an xml file that is independent of mse files / source
files.
Jannik
---
Jannik Laval
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
It could contains all the informations that we
discussed here.
Jannik
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev Andrea
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
---
Jannik Laval
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 
4:19 p.m.
Would it make sense to distribute also a FUEL file containing the famix
model ?
Would it make loading faster ?
We have benchmarks for Fuel and MSE. However, I was just trying to run the
benchs with MSE (to compare to Fuel) but I run into the attached problem.
It seems related to FAMIX, but I have no idea. If someone can fix it, I can
finish the benchmark.
Jannik
---
Jannik Laval
_______________________________________________
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
It could contains all the informations that we
discussed here.
Jannik
> Andrea
>
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
---
Jannik Laval
_______________________________________________
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
4:22 p.m.
On Fri, Jul 27, 2012 at 4:19 PM, Mariano Martinez Peck <
marianopeck(a)gmail.com> wrote:
I have just discovered that Famix-Core-NicolasAnquetil.201 fixes that...
--
Mariano
http://marianopeck.wordpress.com
--
Mariano
http://marianopeck.wordpress.com
Would it make sense to distribute also a FUEL file containing the famix
model ?
Would it make loading faster ?
We have benchmarks for Fuel and MSE. However, I was just trying to run the
benchs with MSE (to compare to Fuel) but I run into the attached problem.
It seems related to FAMIX, but I have no idea. If someone can fix it, I
can finish the benchmark.
Jannik
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
> It could contains all the informations that we discussed here.
>
> Jannik
>
>
>
>> Andrea
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> Moose-dev(a)iam.unibe.ch
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> ---
> Jannik Laval
>
>
> _______________________________________________
> 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
---
Jannik Laval
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
4:31 p.m.
On 27/07/12 16:22, Mariano Martinez Peck wrote:
On Fri, Jul 27, 2012 at 4:19 PM, Mariano Martinez Peck
<marianopeck(a)gmail.com <mailto:marianopeck@gmail.com>> wrote:
Would it make sense to distribute also a FUEL file containing
the famix model ?
Would it make loading faster ?
We have benchmarks for Fuel and MSE. However, I was just trying to
run the benchs with MSE (to compare to Fuel) but I run into the
attached problem.
It seems related to FAMIX, but I have no idea. If someone can fix
it, I can finish the benchmark.
I have just discovered that Famix-Core-NicolasAnquetil.201 fixes that...
:-) OK
That was the idea of my previous email :-)
you are too fast for me
nicolas
4:40 p.m.
On Fri, Jul 27, 2012 at 4:31 PM, Nicolas Anquetil <Nicolas.Anquetil(a)inria.fr
wrote:
> On 27/07/12 16:22, Mariano Martinez Peck wrote:
>
>
>
> On Fri, Jul 27, 2012 at 4:19 PM, Mariano Martinez Peck <
> marianopeck(a)gmail.com wrote:
>
>>
>>>
>>> Would it make sense to distribute also a FUEL file containing the famix
>>> model ?
>>> Would it make loading faster ?
>>>
>>>
>> We have benchmarks for Fuel and MSE. However, I was just trying to run
>> the benchs with MSE (to compare to Fuel) but I run into the attached
>> problem.
>> It seems related to FAMIX, but I have no idea. If someone can fix it, I
>> can finish the benchmark.
>>
>>
>>
> I have just discovered that Famix-Core-NicolasAnquetil.201 fixes that...
>
>
>
> :-) OK
> That was the idea of my previous email :-)
> you are too fast for me
>
Or maybe you were to fast for me since you already fixed it :)
Thanks Nicolas.
nicolas
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
Mariano
http://marianopeck.wordpress.com
4:30 p.m.
We have benchmarks for Fuel and MSE. However, I was
just trying to run
the benchs with MSE (to compare to Fuel) but I run into the attached
problem.
It seems related to FAMIX, but I have no idea. If someone can fix it,
I can finish the benchmark.
Mariano,
When did you try this?
What version of Moose.
I spent sometime yesterday and the day before working on scoping in
MooseChef.
How did you get this error?
I would think it could only appear if you issue some MooseChef query ...
nicolas
4:39 p.m.
On Fri, Jul 27, 2012 at 4:19 PM, Mariano Martinez Peck <
marianopeck(a)gmail.com> wrote:
So the benchmarks for The model network and morphic are:
Model name: Morphic
Model size: 110798
MSE export: 219031 ms
MSE import: 25331 ms
MSE file size: 13135561 bytes
FL export: 8492 ms
FL import: 5118 ms
FL file size: 4805120 bytes
*Fuel export is a 4% of MSE export.*
*Fuel import is a 20% of MSE import*
*Fuel file size is a 36% of MSE file size *
-------
Model name: Network
Model size: 26949
MSE export: 49283 ms
MSE import: 4889 ms
MSE file size: 3144945 bytes
FL export: 1788 ms
FL import: 1049 ms
FL file size: 1219372 bytes
*
*
*Fuel export is a 4% of MSE export.*
*Fuel import is a 21% of MSE import*
*Fuel file size is a 38% of MSE file size *
So the difference between both models are quite proporcional :)
Cheers,
--
Mariano
http://marianopeck.wordpress.com
--
Mariano
http://marianopeck.wordpress.com
Would it make sense to distribute also a FUEL file containing the famix
model ?
Would it make loading faster ?
We have benchmarks for Fuel and MSE. However, I was just trying to run the
benchs with MSE (to compare to Fuel) but I run into the attached problem.
It seems related to FAMIX, but I have no idea. If someone can fix it, I
can finish the benchmark.
Jannik
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
> It could contains all the informations that we discussed here.
>
> Jannik
>
>
>
>> Andrea
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>> Moose-dev(a)iam.unibe.ch
>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
> ---
> Jannik Laval
>
>
> _______________________________________________
> 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
---
Jannik Laval
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
30 Jul
30 Jul
10:30 a.m.
Hi Mariano,
Could you please share the scripts you used for the benchmark?
I attach here the one I use.
Cheers,
Doru
On Fri, Jul 27, 2012 at 4:39 PM, Mariano Martinez Peck
<marianopeck(a)gmail.com> wrote:
On Fri, Jul 27, 2012 at 4:19 PM, Mariano Martinez Peck
<marianopeck(a)gmail.com> wrote:
So the benchmarks for The model network and morphic are:
Model name: Morphic
Model size: 110798
MSE export: 219031 ms
MSE import: 25331 ms
MSE file size: 13135561 bytes
FL export: 8492 ms
FL import: 5118 ms
FL file size: 4805120 bytes
Fuel export is a 4% of MSE export.
Fuel import is a 20% of MSE import
Fuel file size is a 36% of MSE file size
-------
Model name: Network
Model size: 26949
MSE export: 49283 ms
MSE import: 4889 ms
MSE file size: 3144945 bytes
FL export: 1788 ms
FL import: 1049 ms
FL file size: 1219372 bytes
Fuel export is a 4% of MSE export.
Fuel import is a 21% of MSE import
Fuel file size is a 38% of MSE file size
So the difference between both models are quite proporcional :)
Cheers,
--
Mariano
http://marianopeck.wordpress.com
--
Mariano
http://marianopeck.wordpress.com
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Every thing has its own flow"
Would it make sense to distribute also a FUEL file containing the famix
model ?
Would it make loading faster ?
We have benchmarks for Fuel and MSE. However, I was just trying to run the
benchs with MSE (to compare to Fuel) but I run into the attached problem.
It seems related to FAMIX, but I have no idea. If someone can fix it, I
can finish the benchmark.
Jannik
>
>> It could contains all the informations that we discussed here.
>>
>> Jannik
>>
>>
>>
>>> Andrea
>>>
>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> Moose-dev(a)iam.unibe.ch
>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>
>> ---
>> Jannik Laval
>>
>>
>> _______________________________________________
>> 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
---
Jannik Laval
_______________________________________________
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
10:34 a.m.
On Mon, Jul 30, 2012 at 10:30 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote:
Hi Mariano,
Could you please share the scripts you used for the benchmark?
Sure. From Fuel ss3 repo, you need to install the packages:
FuelBenchmarks, FuelFameExtensionBenchmarks
and FuelMooseExtensionBenchmarks.
Then, open a Transcript and then you can execute:
FLMooseBenchmarks new runWithModelInstalledWith: [ MooseScripts
createModelForMorphic ] name: 'Morphic' benchSelectors: #(runFLWith:)
FLMooseBenchmarks new runWithModelInstalledWith: [ MooseScripts
createModelForMorphic ] name: 'Morphic' benchSelectors: #(runMSEWith:)
And of course, you can change the Morphic to something else if you want.
Let me know if that works.
Cheers,
I attach here the one I use.
Cheers,
Doru
On Fri, Jul 27, 2012 at 4:39 PM, Mariano Martinez Peck
<marianopeck(a)gmail.com> wrote:
--
Mariano
http://marianopeck.wordpress.com
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
www.tudorgirba.com
"Every thing has its own flow"
--
Mariano
http://marianopeck.wordpress.com
On Fri, Jul 27, 2012 at 4:19 PM, Mariano Martinez Peck
<marianopeck(a)gmail.com> wrote:
>>
>>
>>
>> Would it make sense to distribute also a FUEL file containing the famix
>> model ?
>> Would it make loading faster ?
>>
>
> We have benchmarks for Fuel and MSE. However, I was just trying to run
the
> benchs with MSE (to compare to Fuel) but I
run into the attached
problem.
It seems
related to FAMIX, but I have no idea. If someone can fix it, I
can finish the benchmark.
So the benchmarks for The model network and morphic are:
Model name: Morphic
Model size: 110798
MSE export: 219031 ms
MSE import: 25331 ms
MSE file size: 13135561 bytes
FL export: 8492 ms
FL import: 5118 ms
FL file size: 4805120 bytes
Fuel export is a 4% of MSE export.
Fuel import is a 20% of MSE import
Fuel file size is a 36% of MSE file size
-------
Model name: Network
Model size: 26949
MSE export: 49283 ms
MSE import: 4889 ms
MSE file size: 3144945 bytes
FL export: 1788 ms
FL import: 1049 ms
FL file size: 1219372 bytes
Fuel export is a 4% of MSE export.
Fuel import is a 21% of MSE import
Fuel file size is a 38% of MSE file size
So the difference between both models are quite proporcional :)
Cheers,
>
> Jannik
>
>>
>>> It could contains all the informations that we discussed here.
>>>
>>> Jannik
>>>
>>>
>>>
>>>> Andrea
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>> Moose-dev(a)iam.unibe.ch
>>>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>>>
>>> ---
>>> Jannik Laval
>>>
>>>
>>> _______________________________________________
>>> 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
>
> ---
> Jannik Laval
>
>
> _______________________________________________
> 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
--
Mariano
http://marianopeck.wordpress.com
28 Jul
28 Jul
9:26 a.m.
i tried to write down a list of all the meta-data
needed:
- project name
- project version
- verveineJ version (i would use the SVN revision number)
is it enough ?
No
Did you look at the famix 2.1 document
should we include the FAMIX version ?
- project name
- location of the original files: URI?
- version of the project
- language
- version of the original language: Java but which one
- description
- author: email
- extractor: Moose42 on Pharo1.4
- date
- mse file name (if this is external
I didn't include the supported moose version,
because i don't think it's relevant and i don't see how this information
should be interpreted.
Why?
If I extract a model using Moose does it make sense not to be able to reload it because
the model change.
Try to come up with a meta data that is not just for Java because soon there is scala,
java, cobol and many more out there.
The rest of the data should be the following:
- MSE of FAMIX model
- source code
If there are multiple versions of a project, it would be also interesting to distribute
an Orion model of all the versions.
Is it possible to build such a model having an MSE file for each version as input ?
yes
How much effort is needed to fix the bugs and make it
work ?
Jannik? But normally it should work.
Now I do not know if orion covers all the famix entities but extending it should not be a
problem,
What would be good is that orion gets the trick that andy and veronica implemented in
their implementation of Orion
How do you look for changes between subsequent
versions ? Do you diff the source code of the analyzed code entities ?
Would it make sense to distribute also a FUEL file containing the famix model ?
yes but in that case you should also have in the meta data
- fuel version
Would it make loading faster ?
Apparently you did not check Fuel :)
You can reload Pharo completely in 10-15 seconds with Fuel.
Jannik
---
Jannik Laval
_______________________________________________
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 It could contains all the informations that we
discussed here.
Jannik
> Andrea
>
>
>
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)iam.unibe.ch
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
---
Jannik Laval
_______________________________________________
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
10:17 p.m.
If there are multiple versions of a project, it would be also interesting to distribute
an Orion model of all the versions.
Is it possible to build such a model having an MSE file for each version as input ?
yes
How much effort is needed to fix the bugs and
make it work ?
Jannik? But normally it should work. Now I do not know if orion covers all the famix
entities but extending it should not be a problem,
It is easy and fast to extend FAMIX entities.
Jannik
What would be good is that orion gets the trick that
andy and veronica implemented in their implementation of Orion
30 Jul
30 Jul
11:41 a.m.
I downloaded the latest version from OrionDev and i tried to create 2 model versions
starting from 2 MSE files of two subsequent versions of the same project.
The following code does simply create 2 versions, the second of which contains all the
entities coming from famixModel2 and a reference to all the entities contained in model1.
model1 := OrionConverter convertFrom: famixModel1.
model2 := OrionConverter convertFrom: famixModel2.
system originalModel: model1.
model1 orionSystem: system.
model2 withParent: model1.
I would like to know if there is a method which allows to add a new version and also makes
a diff between the entities being added and the entities contained in the parent version.
The diff should be made between entities sharing the same mooseName and should be done on
the basis of the contained code (if existing).
Thanks :)
On Jul 28, 2012, at 10:17 PM, jannik.laval wrote:
Iep, it should work.
I used the pragma for importing elements in MSE.
But I never tried it.
If there are multiple versions of a project, it would be also interesting to distribute
an Orion model of all the versions.
Is it possible to build such a model having an MSE file for each version as input ?
yes
How much effort is needed to fix the bugs and
make it work ?
Jannik? But normally it should work. Now I do not know if orion covers all the famix
entities but extending it should not be a problem,
It is easy and fast to extend FAMIX entities.
Jannik
What would be good is that orion gets the trick
that andy and veronica implemented in their implementation of Orion
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
9:32 p.m.
Dear Andrea,
I am happy that you try to use Orion.
The primary goal of Orion was to try modifications on a model and keep changes.
The meta-model allows clearly to save history, but the infrastructure needs some work.
For now, a diff is not implemented. We have to think about this feature. I have no idea
how to do that, because some problems appear when merging or forking.
Jannik
On Jul 30, 2012, at 11:41 AM, Andrea Caracciolo <andyy.mailbox(a)gmail.com> wrote:
I downloaded the latest version from OrionDev and i
tried to create 2 model versions starting from 2 MSE files of two subsequent versions of
the same project.
The following code does simply create 2 versions, the second of which contains all the
entities coming from famixModel2 and a reference to all the entities contained in model1.
model1 := OrionConverter convertFrom: famixModel1.
model2 := OrionConverter convertFrom: famixModel2.
system originalModel: model1.
model1 orionSystem: system.
model2 withParent: model1.
I would like to know if there is a method which allows to add a new version and also
makes a diff between the entities being added and the entities contained in the parent
version.
The diff should be made between entities sharing the same mooseName and should be done on
the basis of the contained code (if existing).
Thanks :)
On Jul 28, 2012, at 10:17 PM, jannik.laval wrote:
Iep, it should work.
I used the pragma for importing elements in MSE.
But I never tried it.
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
---
Jannik Laval
If there are multiple versions of a project, it would be also interesting to distribute
an Orion model of all the versions.
Is it possible to build such a model having an MSE file for each version as input ?
yes
How much effort is needed to fix the bugs and
make it work ?
Jannik? But normally it should work. Now I do not know if orion covers all the famix
entities but extending it should not be a problem,
It is easy and fast to extend FAMIX entities.
Jannik
What would be good is that orion gets the trick
that andy and veronica implemented in their implementation of Orion
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
31 Jul
31 Jul
3:11 p.m.
Hi Jannik,
Are you saying that this feature can't be added because some already implemented
actions are not always working as expected ? Did i understand correctly ?
Do you think you can fix it ?
Do you need help with it ?
I attached a small code snippet which might help developing a possible solution…
Andrea
On Jul 30, 2012, at 9:32 PM, jannik.laval wrote:
Dear Andrea,
I am happy that you try to use Orion.
The primary goal of Orion was to try modifications on a model and keep changes.
The meta-model allows clearly to save history, but the infrastructure needs some work.
For now, a diff is not implemented. We have to think about this feature. I have no idea
how to do that, because some problems appear when merging or forking.
Jannik
On Jul 30, 2012, at 11:41 AM, Andrea Caracciolo <andyy.mailbox(a)gmail.com> wrote:
I downloaded the latest version from OrionDev and
i tried to create 2 model versions starting from 2 MSE files of two subsequent versions of
the same project.
The following code does simply create 2 versions, the second of which contains all the
entities coming from famixModel2 and a reference to all the entities contained in model1.
model1 := OrionConverter convertFrom: famixModel1.
model2 := OrionConverter convertFrom: famixModel2.
system originalModel: model1.
model1 orionSystem: system.
model2 withParent: model1.
I would like to know if there is a method which allows to add a new version and also
makes a diff between the entities being added and the entities contained in the parent
version.
The diff should be made between entities sharing the same mooseName and should be done on
the basis of the contained code (if existing).
Thanks :)
On Jul 28, 2012, at 10:17 PM, jannik.laval wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
---
Jannik Laval
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev >
>
> If there are multiple versions of a project, it would be also interesting to
distribute an Orion model of all the versions.
> Is it possible to build such a model having an MSE file for each version as input ?
yes
> How much effort is needed to fix the bugs and make it work ?
Jannik? But normally it should work.
Iep, it should work.
I used the pragma for importing elements in MSE.
But I never tried it.
Now I do not know if orion covers all the famix
entities but extending it should not be a problem,
It is easy and fast to extend FAMIX entities.
Jannik
What would be good is that orion gets the trick
that andy and veronica implemented in their implementation of Orion
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
2 Aug
2 Aug
9:25 p.m.
Hi Andrea,
On Jul 31, 2012, at 3:11 PM, Andrea Caracciolo <andyy.mailbox(a)gmail.com> wrote:
Hi Jannik,
Are you saying that this feature can't be added because some already implemented
actions are not always working as expected ? Did i understand correctly ?
The feature can be added, but is not :)
Do you think you can fix it ?
Do you need help with it ?
I attached a small code snippet which might help developing a possible solution…
<orion.txt>
It seems to be a good first approach, but I think that loading all the 2nd model to remove
it after is not efficient.
A solution could be to read the mse file and create only the necessary entities using
orion methods.
I will try to do something during August.
If you need it, you can also propose source code, and I can review it.
Cheers,
Jannik
Andrea
On Jul 30, 2012, at 9:32 PM, jannik.laval wrote:
---
Jannik Laval
Dear Andrea,
I am happy that you try to use Orion.
The primary goal of Orion was to try modifications on a model and keep changes.
The meta-model allows clearly to save history, but the infrastructure needs some work.
For now, a diff is not implemented. We have to think about this feature. I have no idea
how to do that, because some problems appear when merging or forking.
Jannik
On Jul 30, 2012, at 11:41 AM, Andrea Caracciolo <andyy.mailbox(a)gmail.com> wrote:
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev I downloaded the latest version from OrionDev and
i tried to create 2 model versions starting from 2 MSE files of two subsequent versions of
the same project.
The following code does simply create 2 versions, the second of which contains all the
entities coming from famixModel2 and a reference to all the entities contained in model1.
model1 := OrionConverter convertFrom: famixModel1.
model2 := OrionConverter convertFrom: famixModel2.
system originalModel: model1.
model1 orionSystem: system.
model2 withParent: model1.
I would like to know if there is a method which allows to add a new version and also
makes a diff between the entities being added and the entities contained in the parent
version.
The diff should be made between entities sharing the same mooseName and should be done on
the basis of the contained code (if existing).
Thanks :)
On Jul 28, 2012, at 10:17 PM, jannik.laval wrote:
---
Jannik Laval
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev >>
>>
>> If there are multiple versions of a project, it would be also interesting to
distribute an Orion model of all the versions.
>> Is it possible to build such a model having an MSE file for each version as input
?
>
> yes
>> How much effort is needed to fix the bugs and make it work ?
>
> Jannik? But normally it should work.
Iep, it should work.
I used the pragma for importing elements in MSE.
But I never tried it.
> Now I do not know if orion covers all the famix entities but extending it should not
be a problem,
It is easy and fast to extend FAMIX entities.
Jannik
> What would be good is that orion gets the trick that andy and veronica implemented in
their implementation of Orion
>
_______________________________________________
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
3 Aug
3 Aug
10:09 a.m.
On Aug 2, 2012, at 9:25 PM, jannik.laval wrote:
Hi Andrea,
On Jul 31, 2012, at 3:11 PM, Andrea Caracciolo <andyy.mailbox(a)gmail.com> wrote:
Indeed it's not very efficient. It takes around 10 min to compare 2 small sized models
(5mb MSE each).
Hi Jannik,
Are you saying that this feature can't be added because some already implemented
actions are not always working as expected ? Did i understand correctly ?
The feature can be added, but is not :)
Do you think you can fix it ?
Do you need help with it ?
I attached a small code snippet which might help developing a possible solution…
<orion.txt>
It seems to be a good first approach, but I think that loading all the 2nd model to
remove it after is not efficient.
A solution could be to read the mse file and create only the necessary entities using
orion methods. I will try to do something during August.
If you need it, you can also propose source code, and I can review it.
I'm looking forward to use it. Please keep me informed.
I will send you some code in case i start working on it.
Cheers,
Andrea
29 Nov
29 Nov
9:11 a.m.
Hi Andrea,
I retrieved your mail and tried to find a solution.
I clearly not found anyone.
In fact, in Orion, the idea is to have a link between each version at
entity level. It means that a class that has been renamed know its previous
version with its previous name.
In 2 different mse files, there is no link between these entities. We have
to postulate that an entity from the second version is linked to an entity
of the first version. For that, we need to use heuristics... which is not
deterministic.
So, I found 2 possible ways:
- we match the name of the entities. If they match, there is a link. But,
all rename of entities would provide inconsistencies in the understanding
of the model.
- we don't match anything and only remove changed entities to add the
updated one, without link between them.
I am not sure about an easy way to develop this feature. But someone has
probably an idea...
Cheers,
Jannik
2012/8/3 Andrea Caracciolo <andyy.mailbox(a)gmail.com>
On Aug 2, 2012, at 9:25 PM, jannik.laval wrote:
Hi Andrea,
On Jul 31, 2012, at 3:11 PM, Andrea Caracciolo <andyy.mailbox(a)gmail.com>
wrote:
Hi Jannik,
Are you saying that this feature can't be added because some already
implemented actions are not always working as expected ? Did i understand
correctly ?
The feature can be added, but is not :)
Do you think you can fix it ?
Do you need help with it ?
I attached a small code snippet which might help developing a possible
solution…
<orion.txt>
It seems to be a good first approach, but I think that loading all the 2nd
model to remove it after is not efficient.
A solution could be to read the mse file and create only the necessary
entities using orion methods.
Indeed it's not very efficient. It takes around 10 min to compare 2 small
sized models (5mb MSE each).
I will try to do something during August.
If you need it, you can also propose source code, and I can review it.
I'm looking forward to use it. Please keep me informed.
I will send you some code in case i start working on it.
Cheers,
Andrea
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--
~~Dr. Jannik Laval~~
École des Mines de Douai
Enseignant-chercheur
http://www.jannik-laval.eu
11:14 a.m.
On 29/11/12 09:11, jannik laval wrote:
Hi Andrea,
I retrieved your mail and tried to find a solution.
I clearly not found anyone.
In fact, in Orion, the idea is to have a link between each version at
entity level. It means that a class that has been renamed know its
previous version with its previous name.
In 2 different mse files, there is no link between these entities. We
have to postulate that an entity from the second version is linked to
an entity of the first version. For that, we need to use heuristics...
which is not deterministic.
So, I found 2 possible ways:
- we match the name of the entities. If they match, there is a link.
But, all rename of entities would provide inconsistencies in the
understanding of the model.
- we don't match anything and only remove changed entities to add the
updated one, without link between them.
I am not sure about an easy way to develop this feature. But someone
has probably an idea...
Cheers,
Jannik
Hi,
First there is no absolute solution, unless you watch all user actions
to see that this method was renamed that name.
So the idea is to be as close as possible to the perfect solution.
I developped something related in VerveineJ
Because it allows incremental parsing, it needs to check every "new"
entity to see if it does not already exist (created in a previous parse
of the system).
The heuristics used are based on containers. Basically, the algorithm is:
If two entites have the same name and their respective owner are "equal"
hten they are "equal".
The algorithm goes recursively up the owner relationship until there is
no owner (for example, Java package "java").
We can discuss this more in depth if you want, or you can have a look at
the code (methods matchAndMapXXX in JavaDictionnary.java)
nicolas
24 Jul
24 Jul
8:14 p.m.
On Jul 24, 2012, at 4:54 PM, Andre Hora wrote:
On Tue, Jul 24, 2012 at 3:38 PM, Mircea Filip Lungu <mircea.lungu(a)gmail.com>
wrote:
Hi guys,
Some small observations:
Reduced Models
- Having reduced (partial) models is a nice idea.
Yes. You can have reduced models either by:
- (1) exporting a reduced (MSE) version from VerveineJ (I guess this is implemented);
- (2) or, importing your full model in Moose and then exporting the entities you want
(this is also implemented, not sure if this integrated);
Andre you did not implement a filter at loading time?
I thought that you or cyril did it.
An even nicer one would be to have partial loading of
the model.
I think that using the MooseImportingContext we could do that easily.
With this idea, you need to be aware that you will lose (a lot of) data. You will lose
data because several (derived) properties are calculated by Moose and you don't have
access to such information directly in your MSE. For instance, suppose you want to load
only the entities FAMIXPackage and FAMIXClass. Then your classes you will not have
information about the attributes, since FAMIXClass>>attributes is derived (in fact,
you need to have FAMIXAttribute in your model). Then, AFAIK this is not good and also
option (1) above is not so good. Then, option (2) is better.
But until that happens, I guess the partial models could be a solution... And still,
having the full Qualitas Corpus loaded even with partial models is impossible. I guess
this is what Stef proposed to address by having the Project be just a proxy and loading it
on demand, only that this might be too expensive.
In my experience, loading a MSE file for an average system takes between 3 and 5 minutes.
Imagine that you want to collect the number of classes in each of the systems in the QC.
you have 150 systems * 3 minutes each for loading the model = 7.5 hours. And imagine that
after that you want to count the number of methods in each of the systems... This is why
with Andrea we thought about caching Moose images preloaded with the systems in the
Qualitas Corpus. In this way I could run a new analysis on the entire corpus in 10
minutes: I open an image, load the latest version of my analysis package if needed, run
the analysis, return the results and close.
On the other hand, maybe the alternative to this an image per system could be to
serialize the FAMIX models with Fuel and hope that loading an entire system with it would
be waaay faster than when loading an MSE file.
Evolutionary Analysis
- I seem to remember talking at some point with Andy Kellens and him mentioning that they
had an incremental model of FAMIX for modeling evolutionary analysis. This would allow
them to only represent the deltas between two versions. We had this discussion last year
at Sattose. Does anybody know anything about that? That would be the right solution for
doing evolutionary analysis. Otherwise we should just be happy with analyzing at most a
dozen versions at once, as many as fit in memory. Or loading things on demand if we find a
fast way.
If you need just class and package data, then I think Hismo will work pretty well. Model
with just classes and packages are very small, and you load hundreds small models in
Hismo.
Memory
Did anybody look into using Gemstone...?
Server
Jannik I guess we could use one of the servers at SCG if needed for serving this
information.
Cheers,
M.
On Tue, Jul 24, 2012 at 11:40 AM, Fabrizio Perin <fabrizio.perin(a)gmail.com> wrote:
Does anybody have any idea about any possible usage of such kind of information ?
you are talking about meta information
In famix 1.0
in the file header there was one entity describing the model.
what we could do is either
- have a separate file in use format (= reuse of parser) containing
information and the file name of the model to which they refer
- or have the information inside the mse model by having an entity
representing the model (we did that in some old moose versions).
I would prefer a separate file. If the idea is to setup a repository of projects the meta
info are about a project together with its mse file not just about the mse.
_______________________________________________
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
--
Andre Hora
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
9:31 p.m.
On Jul 24, 2012, at 3:38 PM, Mircea Filip Lungu wrote:
Hi guys,
Some small observations:
Reduced Models
- Having reduced (partial) models is a nice idea. An even nicer one would be to have
partial loading of the model. But until that happens, I guess the partial models could be
a solution... And still, having the full Qualitas Corpus loaded even with partial models
is impossible. I guess this is what Stef proposed to address by having the Project be just
a proxy and loading it on demand, only that this might be too expensive.
In my experience, loading a MSE file for an average system takes between 3 and 5 minutes.
Imagine that you want to collect the number of classes in each of the systems in the QC.
you have 150 systems * 3 minutes each for loading the model = 7.5 hours. And imagine that
after that you want to count the number of methods in each of the systems... This is why
with Andrea we thought about caching Moose images preloaded with the systems in the
Qualitas Corpus. In this way I could run a new analysis on the entire corpus in 10
minutes: I open an image, load the latest version of my analysis package if needed, run
the analysis, return the results and close.
On the other hand, maybe the alternative to this an image per system could be to
serialize the FAMIX models with Fuel and hope that loading an entire system with it would
be waaay faster than when loading an MSE file.
+1,
For example loading Eclipse 3.4 takes several hours, on a 4Gb memory system and a SSD...
Evolutionary Analysis
- I seem to remember talking at some point with Andy Kellens and him mentioning that they
had an incremental model of FAMIX for modeling evolutionary analysis. This would allow
them to only represent the deltas between two versions. We had this discussion last year
at Sattose. Does anybody know anything about that? That would be the right solution for
doing evolutionary analysis. Otherwise we should just be happy with analyzing at most a
dozen versions at once, as many as fit in memory. Or loading things on demand if we find a
fast way.
Yes, I know it, it is my work :)
You can find the paper on my website
(http://www.jannik-laval.eu/assets/files/papers/Lava10b-SCP-Orion.pdf).
The implementation is available on the moose website
(http://www.moosetechnology.org/tools/orion)
There are some bugs and I do not use it since 1 year.
Now, it is possible for me to work on the implementation.
Memory
Did anybody look into using Gemstone...?
Server
Jannik I guess we could use one of the servers at SCG if needed for serving this
information.
Good idea !
Jannik
Cheers,
M.
On Tue, Jul 24, 2012 at 11:40 AM, Fabrizio Perin <fabrizio.perin(a)gmail.com> wrote:
---
Jannik Laval
Does anybody have any idea about any possible usage of such kind of information ?
you are talking about meta information
In famix 1.0
in the file header there was one entity describing the model.
what we could do is either
- have a separate file in use format (= reuse of parser) containing
information and the file name of the model to which they refer
- or have the information inside the mse model by having an entity
representing the model (we did that in some old moose versions).
I would prefer a separate file. If the idea is to setup a repository of projects the meta
info are about a project together with its mse file not just about the mse.
_______________________________________________
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
27 Jul
27 Jul
2 p.m.
Yes, I know it, it is my work :)
You can find the paper on my website (
http://www.jannik-laval.eu/assets/files/papers/Lava10b-SCP-Orion.pdf).
The implementation is available on the moose website (
http://www.moosetechnology.org/tools/orion)
There are some bugs and I do not use it since 1 year.
Now, it is possible for me to work on the implementation.
+1
That seems to be the best approach to supporting evolutionary analysis i've
seen mentioned here yet :)
28 Jul
28 Jul
10:19 p.m.
On Jul 27, 2012, at 2:00 PM, Mircea Filip Lungu <mircea.lungu(a)gmail.com> wrote:
Yes, I know it, it is my work :)
You can find the paper on my website
(http://www.jannik-laval.eu/assets/files/papers/Lava10b-SCP-Orion.pdf).
The implementation is available on the moose website
(http://www.moosetechnology.org/tools/orion)
There are some bugs and I do not use it since 1 year.
Now, it is possible for me to work on the implementation.
+1
That seems to be the best approach to supporting evolutionary analysis i've seen
mentioned here yet :)
Ok, lets begin to work :)
You can probably begin to use it and give me bugs you find.
Cheers,
Jannik
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
---
Jannik Laval
23 Jul
23 Jul
1:02 p.m.
On Jul 23, 2012, at 10:42 AM, Andrea Caracciolo wrote:
Hi Jannik,
As Fabrizio said, Mircea (and I) is (are) already working at building such a repository.
We would like to share MSE files as a complement to the cited qualitias corpus.
We are also thinking to distribute moose images with a preloaded MSE files.
Andrea did you see my proposal about projects?
Because having MSE is often not enough.
- you want to distinguish MSE representing the original code
- MSE were some information is added/removed
- identify the source code that goes with the original code (else you cannot browse).
Stef
Some questions:
- is there any reason to support vervainJ instead of InFamix ? Would it make sense to
support both ?
- would anybody be interested in sharing the results of their analyses ? which features
are to be expected from such a service ?
Andrea
_____________________________
Andrea Caracciolo -- caracciolo(a)iam.unibe.ch
Software Composition Group
University of Bern
On Jul 21, 2012, at 7:29 PM, jannik.laval wrote:
Hi guys,
Each time we need to do case studies in Moose, we have to select the software
application, in a certain version and probably without all the source code needed. This
results on evaluations that are probably not reproducible.
I think that we need to unify our efforts and share the mse files of our models. With
that, it will be not necessary to generate a FAMIX model each time we need one.
For now, I begun to generate the model from the Qualitas Corpus 'e'
(http://qualitascorpus.com/). There are 486 multiple versions of multiple Java systems.
The mse files are really big (more than 650Mo for Eclipse_SDK3.7). I tried to load the
biggest one in Moose, and it loads ! I just needed to attribute 2Gb of memory in the
info.plist file of Moose 4.6.
I propose to put the files on a server. For all the tar.bz2 files, I need 3.65Gb.
Now, we lack ok at least two pieces of information : (i) the version of verveineJ used
for the extraction. For now, VerveineJ has no version (I took the latest one). (ii) the
version(s) of Moose that can load the file. I tried one mse file with Moose4.6.
We also need a server that can accept all the files.
Any suggestion ?
Jannik
_______________________________________________
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
4406
days inactive
4537
days old
57 comments
13 participants
participants (13)
-
Alexandre Bergel -
Andre Hora -
Andrea Caracciolo -
Fabrizio Perin -
jannik laval -
jannik.laval
-
Mariano Martinez Peck -
Mircea Filip Lungu -
Nicolas Anquetil -
Stephan Eggermont -
Stéphane Ducasse -
Tudor Girba -
Usman Bhatti