5 Jan
2008
5 Jan
'08
2:27 p.m.
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
5 Jan
5 Jan
4:31 p.m.
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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
5:17 p.m.
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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
8:57 p.m.
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
--
Lukas Renggli
http://www.lukas-renggli.ch
10:54 p.m.
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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
8 Jan
8 Jan
3:08 p.m.
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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
_______________________________________________
Moose-dev mailing list
Moose-dev(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev 
6 Jan
6 Jan
2:42 p.m.
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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
8 Jan
8 Jan
9:21 a.m.
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
2:51 p.m.
Lukas Renggli wrote:
Hi Toon,
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
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
8:35 p.m.
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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
9:09 p.m.
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
--
Lukas Renggli
http://www.lukas-renggli.ch
10 Jan
10 Jan
12:41 p.m.
On 8 janv. 08, at 21:09, Lukas Renggli wrote:
yes
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.
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(a)iam.unibe.ch
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
5951
days inactive
5956
days old
12 comments
5 participants
participants (5)
-
Adrian Kuhn -
Hani ABDEEN -
Lukas Renggli -
Stéphane Ducasse -
Toon Verwaest