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
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@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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@inria.fr 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@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@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 ? 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@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On Jul 23, 2012, at 2:29 PM, Andrea Caracciolo wrote:
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@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--- Jannik Laval
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
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@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@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
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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
+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@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
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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Every thing has its own flow"
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--- Jannik Laval
+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@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
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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Every thing has its own flow"
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Jannik Laval
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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:
+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@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
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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Every thing has its own flow"
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Jannik Laval
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On Jul 23, 2012, at 11:22 PM, Stéphane Ducasse wrote:
+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.
:) 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
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@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
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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Every thing has its own flow"
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Jannik Laval
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--- Jannik Laval
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. 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.
:)
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.
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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--- Jannik Laval
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@gmail.comwrote:
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.
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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Jannik Laval
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On Jul 23, 2012, at 12:05 PM, Tudor Girba wrote:
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 :).
Ok, the status has changed no ? Why is it not clear about the status ?
Jannik
Cheers, Doru _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--- Jannik Laval
On Jul 23, 2012, at 9:54 PM, jannik.laval wrote:
On Jul 23, 2012, at 12:05 PM, Tudor Girba wrote:
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 :).
Ok, the status has changed no ? Why is it not clear about the status ?
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.
Jannik
Cheers, Doru _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Jannik Laval
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On Jul 23, 2012, at 11:56 AM, jannik.laval wrote:
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
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 ?
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
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) ?
Jannik
Andrea _____________________________ Andrea Caracciolo -- caracciolo@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Jannik Laval
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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.
the problem is that when you want to perform evolution analysis you are often forced to filter information about the original extracted code. Andre did some strategy for example to build simple trends analysis and to compute the metrics (either based on the 10 latest, one every 10 versions…) and one idea is that we can trace a project as a whole. - tracing code - tracing mse models - mse filtered models so an image should just acts as a cache and cannot contain all the information.
question: how fast is the moose release cycle ?
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
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
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
Andrea _____________________________ Andrea Caracciolo -- caracciolo@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Jannik Laval
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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
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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--- Jannik Laval
- 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
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.
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@gmail.comwrote:
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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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.
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
On Tue, Jul 24, 2012 at 3:38 PM, Mircea Filip Lungu mircea.lungu@gmail.comwrote:
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.
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@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
- 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
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.
Ok now what I'm saying is that as soon as you want to do analysis you need also the infrastructure to support partial information.
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.
:) My point is that having a server is something, having an infrastructure to perform analysis is important and this is what we brainstormed.
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.
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.
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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
- 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. It could contains all the informations that we discussed here.
Jannik
Andrea
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--- Jannik Laval
On Jul 24, 2012, at 9:33 PM, jannik.laval wrote:
- 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.
why xml? We could use use as use as well. It is usually much more readable than xml.
It could contains all the informations that we discussed here.
Jannik
Andrea
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Jannik Laval
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On Jul 25, 2012, at 3:59 PM, Stéphane Ducasse stephane.ducasse@inria.fr wrote:
On Jul 24, 2012, at 9:33 PM, jannik.laval wrote:
- 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.
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
It could contains all the informations that we discussed here.
Jannik
Andrea
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Jannik Laval
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--- Jannik Laval
On Jul 26, 2012, at 7:29 PM, jannik.laval wrote:
On Jul 25, 2012, at 3:59 PM, Stéphane Ducasse stephane.ducasse@inria.fr wrote:
On Jul 24, 2012, at 9:33 PM, jannik.laval wrote:
- 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.
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.
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 ?
Jannik
It could contains all the informations that we discussed here.
Jannik
Andrea
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Jannik Laval
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Jannik Laval
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Jannik Laval
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Jannik Laval
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On Fri, Jul 27, 2012 at 4:19 PM, Mariano Martinez Peck < 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...
Jannik
It could contains all the informations that we discussed here.
Jannik
Andrea
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Jannik Laval
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Jannik Laval
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Mariano http://marianopeck.wordpress.com
On 27/07/12 16:22, Mariano Martinez Peck wrote:
On Fri, Jul 27, 2012 at 4:19 PM, Mariano Martinez Peck <marianopeck@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
On Fri, Jul 27, 2012 at 4:31 PM, Nicolas Anquetil <Nicolas.Anquetil@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@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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
On Fri, Jul 27, 2012 at 4:19 PM, Mariano Martinez Peck < 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.
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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Jannik Laval
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Jannik Laval
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Mariano http://marianopeck.wordpress.com
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@gmail.com wrote:
On Fri, Jul 27, 2012 at 4:19 PM, Mariano Martinez Peck 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.
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@iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Jannik Laval
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Jannik Laval
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Mariano http://marianopeck.wordpress.com
-- Mariano http://marianopeck.wordpress.com
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On Mon, Jul 30, 2012 at 10:30 AM, Tudor Girba tudor@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@gmail.com wrote:
On Fri, Jul 27, 2012 at 4:19 PM, Mariano Martinez Peck 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.
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@iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > --- > Jannik Laval > > > _______________________________________________ > Moose-dev mailing list > Moose-dev@iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Jannik Laval
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Mariano http://marianopeck.wordpress.com
-- Mariano http://marianopeck.wordpress.com
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Every thing has its own flow"
A separate MSE file or the same where the famix model is in ?
I think that if we do not want to have a FAMIX entity and do not have to change the importer/exporter to write an header containing the meta data we will have to get it in another file.
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
It could contains all the informations that we discussed here.
Jannik
Andrea
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Jannik Laval
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Jannik Laval
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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
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:
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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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@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:
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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--- Jannik Laval
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@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:
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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Jannik Laval
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hi Andrea,
On Jul 31, 2012, at 3:11 PM, Andrea Caracciolo andyy.mailbox@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:
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@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:
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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Jannik Laval
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--- Jannik Laval
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@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
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@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@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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
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@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@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Andre Hora
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
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@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--- Jannik Laval
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 :)
On Jul 27, 2012, at 2:00 PM, Mircea Filip Lungu mircea.lungu@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--- Jannik Laval
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@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@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-
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