Hi Alex,
With the team at Bordeaux, we are working on an implementation to query histories (the tool is named VPraxis). I implement a importer for Smalltalk. For now, I can load histories for a package, for a metacello configuration, from a repository.
A first part is build in Pharo (building snapshots from Monticello), and a second part in build with our java software and build the history file. We can export xml, sql or swipl, which allows us to build prolog queries.
Here (http://code.google.com/p/harmony/wiki/VPraxis) is a tutorial for the java VPraxis. For Smalltalk, I am working on it.
I generated the current Mondrian history in a swipl format, available here: http://dl.dropbox.com/u/7739334/MondrianHistorySwipl.zip An important point is that we do not into account the multiple branches (it is a current work :) ). So, when there are multiple branches, for now, we check were is the merge and we "ignore the multiple branches".
Now, for your question, we create a script: http://dl.dropbox.com/u/7739334/mondrianScript.txt Using swi-prolog (http://www.swi-prolog.org/) , you can call, in this script, the method moreN(L, 10).
For the package Mondrian-Layout, it returns: L = [id_MOAbstractGraphLayout, id_MOCircleLayout, id_MOSugiyamaLayout]. Which are the three classes that have changed more that 10 times.
For now, I am working on packaging all the things together. But if you have some other requests, do not hesitate to ask me :)
Cheers, Jannik
On Nov 24, 2011, at 14:05 , Alexandre Bergel wrote:
Having a reification in Moose of 100 versions of Mondrian for example :-)
Just answering the question 'Which classes and methods of Mondrian have changed more than 10 times since the day Mondrian was born?' cannot be easily done without a lot of memory
Alexandre
On 24 Nov 2011, at 03:27, Francois Stephany wrote:
I'm wondering: how big is a dataset > 500MB ? I've no idea how big it is. Alex, what is your use case (in practice!) for more than 500MB?
On 23/11/11 18:25, Igor Stasenko wrote:
It is problematic, and requires different memory management than we currently have. I think if you need really big data sets, then use gemstone, which is developed to deal with that specifically.
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
--- Jannik Laval
On Thu, Dec 8, 2011 at 5:15 PM, jannik.laval jannik.laval@gmail.com wrote:
Hi Alex,
With the team at Bordeaux, we are working on an implementation to query histories (the tool is named VPraxis). I implement a importer for Smalltalk. For now, I can load histories for a package, for a metacello configuration, from a repository.
A first part is build in Pharo (building snapshots from Monticello), and a second part in build with our java software and build the history file. We can export xml, sql or swipl, which allows us to build prolog queries.
I am looking for an infrastructure in java which can be used to query java history for versions of packges, classes, authors, etc. Do you already have something related to java?
Here (http://code.google.com/p/harmony/wiki/VPraxis) is a tutorial for the java VPraxis. For Smalltalk, I am working on it.
I generated the current Mondrian history in a swipl format, available here: http://dl.dropbox.com/u/7739334/MondrianHistorySwipl.zip An important point is that we do not into account the multiple branches (it is a current work :) ). So, when there are multiple branches, for now, we check were is the merge and we "ignore the multiple branches".
Now, for your question, we create a script: http://dl.dropbox.com/u/7739334/mondrianScript.txt Using swi-prolog (http://www.swi-prolog.org/) , you can call, in this script, the method moreN(L, 10).
For the package Mondrian-Layout, it returns: L = [id_MOAbstractGraphLayout, id_MOCircleLayout, id_MOSugiyamaLayout]. Which are the three classes that have changed more that 10 times.
For now, I am working on packaging all the things together. But if you have some other requests, do not hesitate to ask me :)
Cheers, Jannik
On Nov 24, 2011, at 14:05 , Alexandre Bergel wrote:
Having a reification in Moose of 100 versions of Mondrian for example :-)
Just answering the question 'Which classes and methods of Mondrian have changed more than 10 times since the day Mondrian was born?' cannot be easily done without a lot of memory
Alexandre
On 24 Nov 2011, at 03:27, Francois Stephany wrote:
I'm wondering: how big is a dataset > 500MB ? I've no idea how big it is.
Alex, what is your use case (in practice!) for more than 500MB?
On 23/11/11 18:25, Igor Stasenko wrote:
It is problematic, and requires different memory management than we
currently have.
I think if you need really big data sets, then use gemstone, which is
developed to deal with that specifically.
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Jannik Laval
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On Dec 8, 2011, at 22:48 , Usman Bhatti wrote:
On Thu, Dec 8, 2011 at 5:15 PM, jannik.laval jannik.laval@gmail.com wrote: Hi Alex,
With the team at Bordeaux, we are working on an implementation to query histories (the tool is named VPraxis). I implement a importer for Smalltalk. For now, I can load histories for a package, for a metacello configuration, from a repository.
A first part is build in Pharo (building snapshots from Monticello), and a second part in build with our java software and build the history file. We can export xml, sql or swipl, which allows us to build prolog queries.
I am looking for an infrastructure in java which can be used to query java history for versions of packges, classes, authors, etc. Do you already have something related to java?
Yes, Actually, we have an importer for Java, C and Smalltalk.
Jannik
Here (http://code.google.com/p/harmony/wiki/VPraxis) is a tutorial for the java VPraxis. For Smalltalk, I am working on it.
I generated the current Mondrian history in a swipl format, available here: http://dl.dropbox.com/u/7739334/MondrianHistorySwipl.zip An important point is that we do not into account the multiple branches (it is a current work :) ). So, when there are multiple branches, for now, we check were is the merge and we "ignore the multiple branches".
Now, for your question, we create a script: http://dl.dropbox.com/u/7739334/mondrianScript.txt Using swi-prolog (http://www.swi-prolog.org/) , you can call, in this script, the method moreN(L, 10).
For the package Mondrian-Layout, it returns: L = [id_MOAbstractGraphLayout, id_MOCircleLayout, id_MOSugiyamaLayout]. Which are the three classes that have changed more that 10 times.
For now, I am working on packaging all the things together. But if you have some other requests, do not hesitate to ask me :)
Cheers, Jannik
On Nov 24, 2011, at 14:05 , Alexandre Bergel wrote:
Having a reification in Moose of 100 versions of Mondrian for example :-)
Just answering the question 'Which classes and methods of Mondrian have changed more than 10 times since the day Mondrian was born?' cannot be easily done without a lot of memory
Alexandre
On 24 Nov 2011, at 03:27, Francois Stephany wrote:
I'm wondering: how big is a dataset > 500MB ? I've no idea how big it is. Alex, what is your use case (in practice!) for more than 500MB?
On 23/11/11 18:25, Igor Stasenko wrote:
It is problematic, and requires different memory management than we currently have. I think if you need really big data sets, then use gemstone, which is developed to deal with that specifically.
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
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 Fri, Dec 9, 2011 at 10:31 AM, jannik.laval jannik.laval@gmail.comwrote:
On Dec 8, 2011, at 22:48 , Usman Bhatti wrote:
On Thu, Dec 8, 2011 at 5:15 PM, jannik.laval jannik.laval@gmail.comwrote:
Hi Alex,
With the team at Bordeaux, we are working on an implementation to query histories (the tool is named VPraxis). I implement a importer for Smalltalk. For now, I can load histories for a package, for a metacello configuration, from a repository.
A first part is build in Pharo (building snapshots from Monticello), and a second part in build with our java software and build the history file. We can export xml, sql or swipl, which allows us to build prolog queries.
I am looking for an infrastructure in java which can be used to query java history for versions of packges, classes, authors, etc. Do you already have something related to java?
Yes, Actually, we have an importer for Java, C and Smalltalk.
Can you provide me a link to the java version of history importer? And a link to the licence information? :-)
Jannik
Here (http://code.google.com/p/harmony/wiki/VPraxis) is a tutorial for the java VPraxis. For Smalltalk, I am working on it.
I generated the current Mondrian history in a swipl format, available here: http://dl.dropbox.com/u/7739334/MondrianHistorySwipl.zip An important point is that we do not into account the multiple branches (it is a current work :) ). So, when there are multiple branches, for now, we check were is the merge and we "ignore the multiple branches".
Now, for your question, we create a script: http://dl.dropbox.com/u/7739334/mondrianScript.txt Using swi-prolog (http://www.swi-prolog.org/) , you can call, in this script, the method moreN(L, 10).
For the package Mondrian-Layout, it returns: L = [id_MOAbstractGraphLayout, id_MOCircleLayout, id_MOSugiyamaLayout]. Which are the three classes that have changed more that 10 times.
For now, I am working on packaging all the things together. But if you have some other requests, do not hesitate to ask me :)
Cheers, Jannik
On Nov 24, 2011, at 14:05 , Alexandre Bergel wrote:
Having a reification in Moose of 100 versions of Mondrian for example :-)
Just answering the question 'Which classes and methods of Mondrian have changed more than 10 times since the day Mondrian was born?' cannot be easily done without a lot of memory
Alexandre
On 24 Nov 2011, at 03:27, Francois Stephany wrote:
I'm wondering: how big is a dataset > 500MB ? I've no idea how big it is.
Alex, what is your use case (in practice!) for more than 500MB?
On 23/11/11 18:25, Igor Stasenko wrote:
It is problematic, and requires different memory management than we
currently have.
I think if you need really big data sets, then use gemstone, which is
developed to deal with that specifically.
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
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
On Dec 9, 2011, at 11:10 , Usman Bhatti wrote:
On Fri, Dec 9, 2011 at 10:31 AM, jannik.laval jannik.laval@gmail.com wrote:
On Dec 8, 2011, at 22:48 , Usman Bhatti wrote:
On Thu, Dec 8, 2011 at 5:15 PM, jannik.laval jannik.laval@gmail.com wrote: Hi Alex,
With the team at Bordeaux, we are working on an implementation to query histories (the tool is named VPraxis). I implement a importer for Smalltalk. For now, I can load histories for a package, for a metacello configuration, from a repository.
A first part is build in Pharo (building snapshots from Monticello), and a second part in build with our java software and build the history file. We can export xml, sql or swipl, which allows us to build prolog queries.
I am looking for an infrastructure in java which can be used to query java history for versions of packges, classes, authors, etc. Do you already have something related to java?
Yes, Actually, we have an importer for Java, C and Smalltalk.
Can you provide me a link to the java version of history importer? And a link to the licence information? :-)
All is here: http://code.google.com/p/harmony/wiki/VPraxis
Cheers, Jannik
Jannik
Here (http://code.google.com/p/harmony/wiki/VPraxis) is a tutorial for the java VPraxis. For Smalltalk, I am working on it.
I generated the current Mondrian history in a swipl format, available here: http://dl.dropbox.com/u/7739334/MondrianHistorySwipl.zip An important point is that we do not into account the multiple branches (it is a current work :) ). So, when there are multiple branches, for now, we check were is the merge and we "ignore the multiple branches".
Now, for your question, we create a script: http://dl.dropbox.com/u/7739334/mondrianScript.txt Using swi-prolog (http://www.swi-prolog.org/) , you can call, in this script, the method moreN(L, 10).
For the package Mondrian-Layout, it returns: L = [id_MOAbstractGraphLayout, id_MOCircleLayout, id_MOSugiyamaLayout]. Which are the three classes that have changed more that 10 times.
For now, I am working on packaging all the things together. But if you have some other requests, do not hesitate to ask me :)
Cheers, Jannik
On Nov 24, 2011, at 14:05 , Alexandre Bergel wrote:
Having a reification in Moose of 100 versions of Mondrian for example :-)
Just answering the question 'Which classes and methods of Mondrian have changed more than 10 times since the day Mondrian was born?' cannot be easily done without a lot of memory
Alexandre
On 24 Nov 2011, at 03:27, Francois Stephany wrote:
I'm wondering: how big is a dataset > 500MB ? I've no idea how big it is. Alex, what is your use case (in practice!) for more than 500MB?
On 23/11/11 18:25, Igor Stasenko wrote:
It is problematic, and requires different memory management than we currently have. I think if you need really big data sets, then use gemstone, which is developed to deal with that specifically.
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
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
--- Jannik Laval
On Dec 8, 2011, at 10:48 PM, Usman Bhatti wrote:
On Thu, Dec 8, 2011 at 5:15 PM, jannik.laval jannik.laval@gmail.com wrote: Hi Alex,
With the team at Bordeaux, we are working on an implementation to query histories (the tool is named VPraxis). I implement a importer for Smalltalk. For now, I can load histories for a package, for a metacello configuration, from a repository.
A first part is build in Pharo (building snapshots from Monticello), and a second part in build with our java software and build the history file. We can export xml, sql or swipl, which allows us to build prolog queries.
I am looking for an infrastructure in java which can be used to query java history for versions of packges, classes, authors, etc. Do you already have something related to java?
You mean that you are looking for something that you cannot extract with multiple version of verveineJ ?
Stef
Here (http://code.google.com/p/harmony/wiki/VPraxis) is a tutorial for the java VPraxis. For Smalltalk, I am working on it.
I generated the current Mondrian history in a swipl format, available here: http://dl.dropbox.com/u/7739334/MondrianHistorySwipl.zip An important point is that we do not into account the multiple branches (it is a current work :) ). So, when there are multiple branches, for now, we check were is the merge and we "ignore the multiple branches".
Now, for your question, we create a script: http://dl.dropbox.com/u/7739334/mondrianScript.txt Using swi-prolog (http://www.swi-prolog.org/) , you can call, in this script, the method moreN(L, 10).
For the package Mondrian-Layout, it returns: L = [id_MOAbstractGraphLayout, id_MOCircleLayout, id_MOSugiyamaLayout]. Which are the three classes that have changed more that 10 times.
For now, I am working on packaging all the things together. But if you have some other requests, do not hesitate to ask me :)
Cheers, Jannik
On Nov 24, 2011, at 14:05 , Alexandre Bergel wrote:
Having a reification in Moose of 100 versions of Mondrian for example :-)
Just answering the question 'Which classes and methods of Mondrian have changed more than 10 times since the day Mondrian was born?' cannot be easily done without a lot of memory
Alexandre
On 24 Nov 2011, at 03:27, Francois Stephany wrote:
I'm wondering: how big is a dataset > 500MB ? I've no idea how big it is. Alex, what is your use case (in practice!) for more than 500MB?
On 23/11/11 18:25, Igor Stasenko wrote:
It is problematic, and requires different memory management than we currently have. I think if you need really big data sets, then use gemstone, which is developed to deal with that specifically.
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
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
With the team at Bordeaux, we are working on an implementation to query histories (the tool is named VPraxis).
Which kind of query are you interested in? Is Hismo not enough? I worked on a configuration importer. We can analyze many many versions now :-)
I implement a importer for Smalltalk. For now, I can load histories for a package, for a metacello configuration, from a repository.
Have a look at the Spirit project on ss3.gemstone.com/ss It contains a lot of scripts to load versions of Mondrian, Versionner, Spy, ...
A first part is build in Pharo (building snapshots from Monticello), and a second part in build with our java software and build the history file. We can export xml, sql or swipl, which allows us to build prolog queries.
Here (http://code.google.com/p/harmony/wiki/VPraxis) is a tutorial for the java VPraxis. For Smalltalk, I am working on it.
I generated the current Mondrian history in a swipl format, available here: http://dl.dropbox.com/u/7739334/MondrianHistorySwipl.zip An important point is that we do not into account the multiple branches (it is a current work :) ). So, when there are multiple branches, for now, we check were is the merge and we "ignore the multiple branches".
Now, for your question, we create a script: http://dl.dropbox.com/u/7739334/mondrianScript.txt Using swi-prolog (http://www.swi-prolog.org/) , you can call, in this script, the method moreN(L, 10).
For the package Mondrian-Layout, it returns: L = [id_MOAbstractGraphLayout, id_MOCircleLayout, id_MOSugiyamaLayout]. Which are the three classes that have changed more that 10 times.
For now, I am working on packaging all the things together. But if you have some other requests, do not hesitate to ask me :)
Looks cool!
Alexandre
On Nov 24, 2011, at 14:05 , Alexandre Bergel wrote:
Having a reification in Moose of 100 versions of Mondrian for example :-)
Just answering the question 'Which classes and methods of Mondrian have changed more than 10 times since the day Mondrian was born?' cannot be easily done without a lot of memory
Alexandre
On 24 Nov 2011, at 03:27, Francois Stephany wrote:
I'm wondering: how big is a dataset > 500MB ? I've no idea how big it is. Alex, what is your use case (in practice!) for more than 500MB?
On 23/11/11 18:25, Igor Stasenko wrote:
It is problematic, and requires different memory management than we currently have. I think if you need really big data sets, then use gemstone, which is developed to deal with that specifically.
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Jannik Laval
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On Dec 9, 2011, at 24:06 , Alexandre Bergel wrote:
With the team at Bordeaux, we are working on an implementation to query histories (the tool is named VPraxis).
Which kind of query are you interested in? Is Hismo not enough?
We store facts, not models. It allows us to have the history (which method have been removed...) The use of prolog allows VPraxis to be very fast, as it can store hundreds versions.
I worked on a configuration importer. We can analyze many many versions now :-)
Cool ! How do you bypass the problem of memory in Pharo ?
Jannik
I implement a importer for Smalltalk. For now, I can load histories for a package, for a metacello configuration, from a repository.
Have a look at the Spirit project on ss3.gemstone.com/ss It contains a lot of scripts to load versions of Mondrian, Versionner, Spy, ...
A first part is build in Pharo (building snapshots from Monticello), and a second part in build with our java software and build the history file. We can export xml, sql or swipl, which allows us to build prolog queries.
Here (http://code.google.com/p/harmony/wiki/VPraxis) is a tutorial for the java VPraxis. For Smalltalk, I am working on it.
I generated the current Mondrian history in a swipl format, available here: http://dl.dropbox.com/u/7739334/MondrianHistorySwipl.zip An important point is that we do not into account the multiple branches (it is a current work :) ). So, when there are multiple branches, for now, we check were is the merge and we "ignore the multiple branches".
Now, for your question, we create a script: http://dl.dropbox.com/u/7739334/mondrianScript.txt Using swi-prolog (http://www.swi-prolog.org/) , you can call, in this script, the method moreN(L, 10).
For the package Mondrian-Layout, it returns: L = [id_MOAbstractGraphLayout, id_MOCircleLayout, id_MOSugiyamaLayout]. Which are the three classes that have changed more that 10 times.
For now, I am working on packaging all the things together. But if you have some other requests, do not hesitate to ask me :)
Looks cool!
Alexandre
On Nov 24, 2011, at 14:05 , Alexandre Bergel wrote:
Having a reification in Moose of 100 versions of Mondrian for example :-)
Just answering the question 'Which classes and methods of Mondrian have changed more than 10 times since the day Mondrian was born?' cannot be easily done without a lot of memory
Alexandre
On 24 Nov 2011, at 03:27, Francois Stephany wrote:
I'm wondering: how big is a dataset > 500MB ? I've no idea how big it is. Alex, what is your use case (in practice!) for more than 500MB?
On 23/11/11 18:25, Igor Stasenko wrote:
It is problematic, and requires different memory management than we currently have. I think if you need really big data sets, then use gemstone, which is developed to deal with that specifically.
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Jannik Laval
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--- Jannik Laval
On Fri, Dec 9, 2011 at 12:06 AM, Alexandre Bergel alexandre.bergel@me.comwrote:
With the team at Bordeaux, we are working on an implementation to query
histories (the tool is named VPraxis).
Which kind of query are you interested in? Is Hismo not enough? I worked on a configuration importer. We can analyze many many versions now :-)
Alex, where can I have more information about this importer? Is that related to a script you sent to the list few days ago?
I implement a importer for Smalltalk. For now, I can load histories for a package, for a metacello
configuration, from a repository.
Have a look at the Spirit project on ss3.gemstone.com/ss It contains a lot of scripts to load versions of Mondrian, Versionner, Spy, ...
A first part is build in Pharo (building snapshots from Monticello), and
a second part in build with our java software and build the history file. We can export xml, sql or swipl, which allows us to build prolog queries.
Here (http://code.google.com/p/harmony/wiki/VPraxis) is a tutorial for
the java VPraxis.
For Smalltalk, I am working on it.
I generated the current Mondrian history in a swipl format, available
here: http://dl.dropbox.com/u/7739334/MondrianHistorySwipl.zip
An important point is that we do not into account the multiple branches
(it is a current work :) ). So, when there are multiple branches, for now, we check were is the merge and we "ignore the multiple branches".
Now, for your question, we create a script:
http://dl.dropbox.com/u/7739334/mondrianScript.txt
Using swi-prolog (http://www.swi-prolog.org/) , you can call, in this
script, the method moreN(L, 10).
For the package Mondrian-Layout, it returns: L =
[id_MOAbstractGraphLayout, id_MOCircleLayout, id_MOSugiyamaLayout].
Which are the three classes that have changed more that 10 times.
For now, I am working on packaging all the things together. But if you have some other requests, do not hesitate to ask me :)
Looks cool!
Alexandre
On Nov 24, 2011, at 14:05 , Alexandre Bergel wrote:
Having a reification in Moose of 100 versions of Mondrian for example
:-)
Just answering the question 'Which classes and methods of Mondrian have
changed more than 10 times since the day Mondrian was born?' cannot be easily done without a lot of memory
Alexandre
On 24 Nov 2011, at 03:27, Francois Stephany wrote:
I'm wondering: how big is a dataset > 500MB ? I've no idea how big it
is.
Alex, what is your use case (in practice!) for more than 500MB?
On 23/11/11 18:25, Igor Stasenko wrote:
It is problematic, and requires different memory management than we currently have. I think if you need really big data sets, then use gemstone, which is developed to deal with that specifically.
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Jannik Laval
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Alex, where can I have more information about this importer? Is that related to a script you sent to the list few days ago?
Yes. You can have a look at the class AutomaticalCaseStudies in ss3.gemstone.com/ss/SPIRIT
I started to work on an importer, but I am not satisfied, mainly because I have to effectively install the code in the image (i.e., compile all the methods). However, the scripts essentially do what we need.
Cheers, Alexandre
On Fri, Dec 9, 2011 at 8:05 PM, Alexandre Bergel alexandre.bergel@me.comwrote:
Alex, where can I have more information about this importer? Is that
related to a script you sent to the list few days ago?
Yes. You can have a look at the class AutomaticalCaseStudies in ss3.gemstone.com/ss/SPIRIT
I started to work on an importer, but I am not satisfied, mainly because I have to effectively install the code in the image (i.e., compile all the methods). However, the scripts essentially do what we need.
Thanks Alex! I will check.
Cheers, Alexandre
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On Dec 9, 2011, at 20:08 , Andre Hora wrote:
On Fri, Dec 9, 2011 at 8:05 PM, Alexandre Bergel alexandre.bergel@me.com wrote:
Alex, where can I have more information about this importer? Is that related to a script you sent to the list few days ago?
Yes. You can have a look at the class AutomaticalCaseStudies in ss3.gemstone.com/ss/SPIRIT
I started to work on an importer, but I am not satisfied, mainly because I have to effectively install the code in the image (i.e., compile all the methods).
Hi Alex,
Why do you have to compile all the methods ? What about a project that needs some packages not installed ?
Jannik
However, the scripts essentially do what we need. Thanks Alex! I will check.
Cheers, Alexandre
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
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
--- Jannik Laval
Why do you have to compile all the methods ? What about a project that needs some packages not installed ?
What I meant is the following: If you want to create a moose model for version 2.135 of Mondrian, you need to load the version 2.135 from the configuration. You can then import it via the MoosePanel (or programmatically).
The oddity is to have to install the version. We shouldn't need that. Unfortunately, I can't devote much time on that issue.
Cheers, Alexandre
On Fri, Dec 9, 2011 at 8:08 PM, Andre Hora andrehoraa@gmail.com wrote:
On Fri, Dec 9, 2011 at 8:05 PM, Alexandre Bergel alexandre.bergel@me.comwrote:
Alex, where can I have more information about this importer? Is that
related to a script you sent to the list few days ago?
Yes. You can have a look at the class AutomaticalCaseStudies in ss3.gemstone.com/ss/SPIRIT
I started to work on an importer, but I am not satisfied, mainly because I have to effectively install the code in the image (i.e., compile all the methods). However, the scripts essentially do what we need.
Thanks Alex! I will check.
So, you are creating Moose models and not one Hismo model in the importer. For instance in the methods AutomaticalCaseStudies>>easy* creates several Moose models. It should be good to have the Hismo model.
Cheers, Alexandre
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- Andre Hora
So, you are creating Moose models and not one Hismo model in the importer. For instance in the methods AutomaticalCaseStudies>>easy* creates several Moose models. It should be good to have the Hismo model.
Hismo models are trivial to create. We did this at the beginning. However we quickly bump into the limit of 500Mb for the image size.
We were hoping to have 100's of versions at the same time, but we couldn't :-( So, we export everything to Excel.
Cheers, Alexandre
On Fri, Dec 9, 2011 at 10:17 PM, Alexandre Bergel alexandre.bergel@me.comwrote:
So, you are creating Moose models and not one Hismo model in the
importer. For instance in the methods AutomaticalCaseStudies>>easy* creates several Moose models. It should be good to have the Hismo model.
Hismo models are trivial to create. We did this at the beginning. However we quickly bump into the limit of 500Mb for the image size.
We were hoping to have 100's of versions at the same time, but we couldn't :-( So, we export everything to Excel.
Maybe you can work with just classes and packages (like that Hismo can scale), but if you need all the entities.. indeed..
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
On Dec 9, 2011, at 22:17 , Alexandre Bergel wrote:
So, you are creating Moose models and not one Hismo model in the importer. For instance in the methods AutomaticalCaseStudies>>easy* creates several Moose models. It should be good to have the Hismo model.
Hismo models are trivial to create. We did this at the beginning. However we quickly bump into the limit of 500Mb for the image size.
We were hoping to have 100's of versions at the same time, but we couldn't :-( So, we export everything to Excel.
to Excel ??? You should try VPraxis. We can export in xml.
Jannik
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--- Jannik Laval
to Excel ??? You should try VPraxis. We can export in xml.
I used Excel and R to conduct statistical analysis
Cheers, Alexandre
Hi,
My guess is that you only worked on named entities like methods, classes, packages. These usually make some 5% of the overall model size, the rest being associations and fine grained variables (params and local variables).
It should scale to only load these entities for your analyses without exporting to Excel, that is if you do not need any special functionality.
Cheers, Doru
On 10 Dec 2011, at 19:56, Alexandre Bergel wrote:
to Excel ??? You should try VPraxis. We can export in xml.
I used Excel and R to conduct statistical analysis
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Live like you mean it."
My guess is that you only worked on named entities like methods, classes, packages.
I need dependencies as well. We are currently working on correlating dependencies with complexity.
Alexandre
On Dec 11, 2011, at 12:34 AM, Alexandre Bergel wrote:
My guess is that you only worked on named entities like methods, classes, packages.
I need dependencies as well. We are currently working on correlating dependencies with complexity.
Still I do not understand why you cannot import a model, save only what you need. without local variables and friends.
I think that saving to excel is obscure to me and I do not see how it will help moose to get better.
For the importer without loading code. It is MC specific so we will not work on it right now. But it should not be difficult to check inside MC and see how we can query the MCdefinitions.
I hope that in the future Ring will be able to be used inside.
Stef
On Dec 11, 2011, at 11:41 , Stéphane Ducasse wrote:
On Dec 11, 2011, at 12:34 AM, Alexandre Bergel wrote:
My guess is that you only worked on named entities like methods, classes, packages.
I need dependencies as well. We are currently working on correlating dependencies with complexity.
Still I do not understand why you cannot import a model, save only what you need. without local variables and friends.
I think that saving to excel is obscure to me and I do not see how it will help moose to get better.
For the importer without loading code. It is MC specific so we will not work on it right now. But it should not be difficult to check inside MC and see how we can query the MCdefinitions.
The MooseMonticelloImporter seems already to work, no ? Jannik
I hope that in the future Ring will be able to be used inside.
Stef
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
--- Jannik Laval
Hi,
On 11 Dec 2011, at 00:34, Alexandre Bergel wrote:
My guess is that you only worked on named entities like methods, classes, packages.
I need dependencies as well. We are currently working on correlating dependencies with complexity.
What does that mean? Are you exporting the list of dependencies to Excel? I guess not.
More likely, you are summarizing the dependencies with some metrics. In this case, what you can do is to produce the models, save it with all metrics, and only load the entities you are interested in. This is how I did all my analyses with Hismo for my thesis (e.g., 50 versions of JBoss). Would that not work?
Doru
Alexandre
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Quality cannot be an afterthought."
More likely, you are summarizing the dependencies with some metrics. In this case, what you can do is to produce the models, save it with all metrics, and only load the entities you are interested in. This is how I did all my analyses with Hismo for my thesis (e.g., 50 versions of JBoss). Would that not work?
It would indeed work. For example, one metric is: cls queryAllOutgoingDependencies atClassScope size
Maybe we could compute it right after having loaded it and store the result in the privateState. And then? We should remove all the dependencies since we do not need them anymore (e.g., setting to nil #accesses, #outgoingReferences)
How does that sound?
Cheers, Alexandre
Doru
Alexandre
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Quality cannot be an afterthought."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hi,
On 11 Dec 2011, at 13:58, Alexandre Bergel wrote:
More likely, you are summarizing the dependencies with some metrics. In this case, what you can do is to produce the models, save it with all metrics, and only load the entities you are interested in. This is how I did all my analyses with Hismo for my thesis (e.g., 50 versions of JBoss). Would that not work?
It would indeed work. For example, one metric is: cls queryAllOutgoingDependencies atClassScope size
Maybe we could compute it right after having loaded it and store the result in the privateState. And then? We should remove all the dependencies since we do not need them anymore (e.g., setting to nil #accesses, #outgoingReferences)
How does that sound?
You do not remove them from the current model. You reload them in a new model with filtering.
Doru
Cheers, Alexandre
Doru
Alexandre
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Quality cannot be an afterthought."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Quality cannot be an afterthought."
you save the model with just the package/classes and the metrics and after you reload everything and you should be able to get 1000 of models.
On Dec 11, 2011, at 1:58 PM, Alexandre Bergel wrote:
More likely, you are summarizing the dependencies with some metrics. In this case, what you can do is to produce the models, save it with all metrics, and only load the entities you are interested in. This is how I did all my analyses with Hismo for my thesis (e.g., 50 versions of JBoss). Would that not work?
It would indeed work. For example, one metric is: cls queryAllOutgoingDependencies atClassScope size
Maybe we could compute it right after having loaded it and store the result in the privateState. And then? We should remove all the dependencies since we do not need them anymore (e.g., setting to nil #accesses, #outgoingReferences)
How does that sound?
Cheers, Alexandre
Doru
Alexandre
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Quality cannot be an afterthought."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Ideally, the model should always be saved in full. You only load what you want using the filtering mechanism.
Doru
On 11 Dec 2011, at 15:21, Stéphane Ducasse wrote:
you save the model with just the package/classes and the metrics and after you reload everything and you should be able to get 1000 of models.
On Dec 11, 2011, at 1:58 PM, Alexandre Bergel wrote:
More likely, you are summarizing the dependencies with some metrics. In this case, what you can do is to produce the models, save it with all metrics, and only load the entities you are interested in. This is how I did all my analyses with Hismo for my thesis (e.g., 50 versions of JBoss). Would that not work?
It would indeed work. For example, one metric is: cls queryAllOutgoingDependencies atClassScope size
Maybe we could compute it right after having loaded it and store the result in the privateState. And then? We should remove all the dependencies since we do not need them anymore (e.g., setting to nil #accesses, #outgoingReferences)
How does that sound?
Cheers, Alexandre
Doru
Alexandre
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Quality cannot be an afterthought."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
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
"We can create beautiful models in a vacuum. But, to get them effective we have to deal with the inconvenience of reality."
-
Alexandre Bergel -
Andre Hora -
jannik.laval -
Stéphane Ducasse -
Tudor Girba -
Usman Bhatti