To a unified software model repository for Moose.

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
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

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





_______________________________________________
Moose-dev mailing list
[hidden email]
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



_______________________________________________
Moose-dev mailing list
[hidden email]
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
<[hidden email]> wrote:


--
www.tudorgirba.com

"Every thing has its own flow"

_______________________________________________
Moose-dev mailing list
[hidden email]
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 -- [hidden email]
Software Composition Group
University of Bern

On Jul 21, 2012, at 7:29 PM, jannik.laval wrote:


_______________________________________________
Moose-dev mailing list
[hidden email]
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


---
Jannik Laval


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Hi Jannik,

>> Some questions:
>> - is there any reason to support vervainJ instead of InFamix ? Would it make sense to support both ?
>
> This is a long discussion. I know that VerveinJ works fine. It is open-soure and well-maintained.
> Maybe Nicolas Anquetil has already done a comparison between the two importers.

Unfortunately, VerveineJ is not open-source. It is at the moment
available to be used, but as it stands, the license is not specified
at all. This is why the page says that you should contact Stef for
getting information about the license. It would be great to clarify
this point to avoid confusion in the future :).


Cheers,
Doru
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

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

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

For us we will continue to work on verveineJ and the license will stay like that for a while until we know were we go.
So for us verveineJ is important because we can control it, fix it…

Stef


_______________________________________________
Moose-dev mailing list
[hidden email]
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
<[hidden email]> wrote:


--
www.tudorgirba.com

"Every thing has its own flow"

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

On Jul 23, 2012, at 11:56 AM, jannik.laval wrote:

I have recently written a simple script which is able to load a given MSE file into a specified moose image, and save everything as a new image.
Sharing such images would save a lot of time to the end-user and is another little step to having consistent and reproducible analysis results.

question: how fast is the moose release cycle ?


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) ?




_______________________________________________
Moose-dev mailing list
[hidden email]
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



_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

On Jul 23, 2012, at 12:05 PM, Tudor Girba wrote:

Ok, the status has changed no ?
Why is it not clear about the status ?

Jannik

>
>
> Cheers,
> Doru
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev

---
Jannik Laval


_______________________________________________
Moose-dev mailing list
[hidden email]
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:

---
Jannik Laval


_______________________________________________
Moose-dev mailing list
[hidden email]
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.


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).
       


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

On Jul 23, 2012, at 9:54 PM, jannik.laval wrote:

because we do not know if having a java extractor cannot kill synectique.
So between giving a chance to synectique and having an open-source project we chose to give a chance to synectique
and again there should be a middle way: this can be something else than open-source or nothing but so far nobody pushed the idea further.



_______________________________________________
Moose-dev mailing list
[hidden email]
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 :)

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

_______________________________________________
Moose-dev mailing list
[hidden email]
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:

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.




_______________________________________________
Moose-dev mailing list
[hidden email]
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
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev