Hi Moose-List,
up to version 2.8 Seaside was a huge monolithic package with a few extension packages. For Seaside 2.9 we try to split the whole code into smaller packages, to simplify deployment and porting. For example platform specific code should be in a separate package, and development tools, tests and examples should be loadable independently.
We've coarsely split the code into multiple packages, however with all the code (around 500 classes and 5000 methods) it is difficult to see the dependencies and possible problems.
I wonder if there is anything in Moose that could help us to get the package structure right? Visualize the dependencies of packages? Detect circular dependencies? Discover code that is placed in the wrong package? etc.
I know that there is a package called MudPie for Squeak [1], that does something similar we want. Before trying to get it run I thought I ask here in the list for tips on how you would proceed with this endeavour.
Happy new year, Lukas
[1] http://map.squeak.org/package/617dbc24-e029-4d8c-a941-68db8c867952
it would be good to see if package blueprint can help. I was planning to sak a master student to build dependencies matrix as in www.ndepend.com as a start. May be hani will also work on that. I have some ideas but so far only writing latex :(
Stef On 5 janv. 08, at 14:27, Lukas Renggli wrote:
Hi Moose-List,
up to version 2.8 Seaside was a huge monolithic package with a few extension packages. For Seaside 2.9 we try to split the whole code into smaller packages, to simplify deployment and porting. For example platform specific code should be in a separate package, and development tools, tests and examples should be loadable independently.
We've coarsely split the code into multiple packages, however with all the code (around 500 classes and 5000 methods) it is difficult to see the dependencies and possible problems.
I wonder if there is anything in Moose that could help us to get the package structure right? Visualize the dependencies of packages? Detect circular dependencies? Discover code that is placed in the wrong package? etc.
I know that there is a package called MudPie for Squeak [1], that does something similar we want. Before trying to get it run I thought I ask here in the list for tips on how you would proceed with this endeavour.
Happy new year, Lukas
[1] http://map.squeak.org/package/617dbc24-e029-4d8c-a941-68db8c867952
-- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hey Lukas,
Hapax offers the distribution map to compare packages with topics, ie "soft" dependencies at vocabulary level. Alas, no support for "hard" dependencies as structure and the like.
If you like to use Hapax we can sit together, it does not run out of the box.
cheers, AA
On 5 Jan 2008, at 14:27 , Lukas Renggli wrote:
Hi Moose-List,
up to version 2.8 Seaside was a huge monolithic package with a few extension packages. For Seaside 2.9 we try to split the whole code into smaller packages, to simplify deployment and porting. For example platform specific code should be in a separate package, and development tools, tests and examples should be loadable independently.
We've coarsely split the code into multiple packages, however with all the code (around 500 classes and 5000 methods) it is difficult to see the dependencies and possible problems.
I wonder if there is anything in Moose that could help us to get the package structure right? Visualize the dependencies of packages? Detect circular dependencies? Discover code that is placed in the wrong package? etc.
I know that there is a package called MudPie for Squeak [1], that does something similar we want. Before trying to get it run I thought I ask here in the list for tips on how you would proceed with this endeavour.
Happy new year, Lukas
[1] http://map.squeak.org/package/617dbc24-e029-4d8c-a941-68db8c867952
-- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Thanks for your answers. I had a look at MudPie and modified it slightly to suit my exact needs. If you are interested have a look at the attached visualization. Open the SVG file in Safari, the tooltips on the edge labels give the reason for the dependencies.
@Stef: I would be interested to see a package blueprint of the code.
@Adrian: Thanks for your offer. I think Hapax is less useful in our case. We know the code pretty well, we are more looking at "hard" dependencies right now.
Lukas
On 5 janv. 08, at 20:57, Lukas Renggli wrote:
Thanks for your answers. I had a look at MudPie and modified it slightly to suit my exact needs. If you are interested have a look at the attached visualization. Open the SVG file in Safari, the tooltips on the edge labels give the reason for the dependencies.
@Stef: I would be interested to see a package blueprint of the code.
I will ask hani since we were rewriting the code from scratch and he took the lead I guess that you will get an answer by monday afternoon since he does not connection at home.
I would like to know (no answer before some months) how you imagine seaside 2.9 With layers?
You do not have that cycles in the pictures this is already something good :)
Why seaside code is depending on seaside examples :)
But this is a wonderful case study. Thanks a lot.
@Adrian: Thanks for your offer. I think Hapax is less useful in our case. We know the code pretty well, we are more looking at "hard" dependencies right now.
Lukas
-- Lukas Renggli http://www.lukas- renggli.ch<packages.svg>______________________________________________ _ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hi Lukas, Sorry to answer you so late :-(
for understanding packages we have developed different views: 1- package surface blueprints: they give a detailled and simple representation of the incoming/outgoing references to/from a package. It visualizes aslo the intra-references. 2- package references fingerprints: they are based on the principle of Similarity Matrix. The aime of these views is to give an idea about the contextual cohesion of a given package (the coupling between classes is based on the co-using). In other words, these views help to understand the package interfaces (package classes which are referenced from the outside 'In-Interface', and package classes which do reference to the outside 'Out-Interface').
to use these views you should download Cook bundle 'last version'.
let me know if you any question.
bests, Hani
On Jan 5, 2008, at 22:54 PM, Stéphane Ducasse wrote:
On 5 janv. 08, at 20:57, Lukas Renggli wrote:
Thanks for your answers. I had a look at MudPie and modified it slightly to suit my exact needs. If you are interested have a look at the attached visualization. Open the SVG file in Safari, the tooltips on the edge labels give the reason for the dependencies.
@Stef: I would be interested to see a package blueprint of the code.
I will ask hani since we were rewriting the code from scratch and he took the lead I guess that you will get an answer by monday afternoon since he does not connection at home.
I would like to know (no answer before some months) how you imagine seaside 2.9 With layers?
You do not have that cycles in the pictures this is already something good :)
Why seaside code is depending on seaside examples :)
But this is a wonderful case study. Thanks a lot.
@Adrian: Thanks for your offer. I think Hapax is less useful in our case. We know the code pretty well, we are more looking at "hard" dependencies right now.
Lukas
-- Lukas Renggli http://www.lukas- renggli.ch<packages.svg>_____________________________________________ _ _ 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 Lukas,
also what I have been doing around packaging in the ClusterFinder might come in handy to you. If you are interested we can sit together and have a look at it too. First it tries to combine techniques to find packages, then it gives you some tools to evaluate the detected packages. If your code comes packaged; you can also evaluate those.
cheers, Toon
Lukas Renggli wrote:
Thanks for your answers. I had a look at MudPie and modified it slightly to suit my exact needs. If you are interested have a look at the attached visualization. Open the SVG file in Safari, the tooltips on the edge labels give the reason for the dependencies.
@Stef: I would be interested to see a package blueprint of the code.
@Adrian: Thanks for your offer. I think Hapax is less useful in our case. We know the code pretty well, we are more looking at "hard" dependencies right now.
Lukas
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hi Toon,
also what I have been doing around packaging in the ClusterFinder might come in handy to you. If you are interested we can sit together and have a look at it too. First it tries to combine techniques to find packages, then it gives you some tools to evaluate the detected packages. If your code comes packaged; you can also evaluate those.
that sounds interesting. If you have some time I would like to learn about the ClusterFinder and what it detects about our existing package structure. What kind of input do you need? The packages are all in Squeak right now.
Lukas
Lukas Renggli wrote:
Hi Toon,
also what I have been doing around packaging in the ClusterFinder might come in handy to you. If you are interested we can sit together and have a look at it too. First it tries to combine techniques to find packages, then it gives you some tools to evaluate the detected packages. If your code comes packaged; you can also evaluate those.
that sounds interesting. If you have some time I would like to learn about the ClusterFinder and what it detects about our existing package structure. What kind of input do you need? The packages are all in Squeak right now.
Lukas
If you are able to file out a Famix (still the old 2.x version) version of your code in any way which we can then load into moose, we can use the clusterfinder on that model.
Toon
lukas
Hani has a flue. Now did you get seaside2.8 loading into moose because we would like to apply package blueprints on it. Hani was working on a new version of package blueprint and this should be availble soon.
stef
On 8 janv. 08, at 09:21, Lukas Renggli wrote:
Hi Toon,
also what I have been doing around packaging in the ClusterFinder might come in handy to you. If you are interested we can sit together and have a look at it too. First it tries to combine techniques to find packages, then it gives you some tools to evaluate the detected packages. If your code comes packaged; you can also evaluate those.
that sounds interesting. If you have some time I would like to learn about the ClusterFinder and what it detects about our existing package structure. What kind of input do you need? The packages are all in Squeak right now.
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hani has a flue. Now did you get seaside2.8 loading into moose because we would like to apply package blueprints on it. Hani was working on a new version of package blueprint and this should be availble soon.
I didn't try yet. I assume it I could use your Squeak exporter for that, right?
I used a self built tool to visualize the dependencies (inheritance, class extensions, direct class references) beteween the existing packages with GraphViz. It is all rather trivial, but it helps us to detect circular dependencies that would prevent the code from loading. So this was the most important thing.
Now I would be interested more in the quality of the packaging and if certain packages could be further split down into individual entities.
Lukas
On 8 janv. 08, at 21:09, Lukas Renggli wrote:
Hani has a flue. Now did you get seaside2.8 loading into moose because we would like to apply package blueprints on it. Hani was working on a new version of package blueprint and this should be availble soon.
I didn't try yet. I assume it I could use your Squeak exporter for that, right?
yes
I used a self built tool to visualize the dependencies (inheritance, class extensions, direct class references) beteween the existing packages with GraphViz. It is all rather trivial, but it helps us to detect circular dependencies that would prevent the code from loading. So this was the most important thing.
I imagine.
Now I would be interested more in the quality of the packaging and if certain packages could be further split down into individual entities.
:)
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-
Adrian Kuhn -
Hani ABDEEN -
Lukas Renggli -
Stéphane Ducasse -
Toon Verwaest