Hi,
It looks like most issues related to 4.0 are solved, with the exception of the Glamour cycle which I moved to 4.1. So, I would say that we can now release 4.0.
I would only have one question: What would you say about including the MOGraphVizLayout in this release? On the one hand, it offers a number of new layout possibilities, on the other hand it requires GraphViz to be installed in the command line and it works only on Linux and Mac (however, there is a check).
Cheers, Doru
-- www.tudorgirba.com
"Problem solving efficiency grows with the abstractness level of problem understanding."
On 10 mai 2010, at 11:58, Tudor Girba wrote:
Hi,
It looks like most issues related to 4.0 are solved, with the exception of the Glamour cycle which I moved to 4.1. So, I would say that we can now release 4.0.
I would only have one question: What would you say about including the MOGraphVizLayout in this release? On the one hand, it offers a number of new layout possibilities, on the other hand it requires GraphViz to be installed in the command line and it works only on Linux and Mac (however, there is a check).
It's the same thing for infusion right? Except (infusion works on 3 platforms).
Does it mean it gets included in the one-click image?
-- Simon
Hi,
On 10 May 2010, at 12:40, Simon Denier wrote:
On 10 mai 2010, at 11:58, Tudor Girba wrote:
Hi,
It looks like most issues related to 4.0 are solved, with the exception of the Glamour cycle which I moved to 4.1. So, I would say that we can now release 4.0.
I would only have one question: What would you say about including the MOGraphVizLayout in this release? On the one hand, it offers a number of new layout possibilities, on the other hand it requires GraphViz to be installed in the command line and it works only on Linux and Mac (however, there is a check).
It's the same thing for infusion right? Except (infusion works on 3 platforms).
Indeed.
Does it mean it gets included in the one-click image?
What? The MOGraphVizLayout? If nobody has objections, then yes :). Or inFusion?
Cheers, Doru
-- www.tudorgirba.com
"Obvious things are difficult to teach."
On 10 mai 2010, at 13:48, Tudor Girba wrote:
Hi,
On 10 May 2010, at 12:40, Simon Denier wrote:
On 10 mai 2010, at 11:58, Tudor Girba wrote:
Hi,
It looks like most issues related to 4.0 are solved, with the exception of the Glamour cycle which I moved to 4.1. So, I would say that we can now release 4.0.
I would only have one question: What would you say about including the MOGraphVizLayout in this release? On the one hand, it offers a number of new layout possibilities, on the other hand it requires GraphViz to be installed in the command line and it works only on Linux and Mac (however, there is a check).
It's the same thing for infusion right? Except (infusion works on 3 platforms).
Indeed.
Does it mean it gets included in the one-click image?
What? The MOGraphVizLayout? If nobody has objections, then yes :). Or inFusion?
I was thinking of the platform-dependent graphviz package. But if there is already an informative check (like a pop-up informing user to install graphviz if not detected), I think it's good enough.
-- Simon
Hi,
I added such a popup. Could someone check if it is good enough? (I already have GraphViz installed)
To try it, load the latest MondrianGraphVizLayout package and execute:
view := MOViewRenderer new. view nodes: (1 to: 100). view edgesFrom: [:x | x // 10]. view graphvizLayout. view open
Cheers, Doru
On 10 May 2010, at 13:57, Simon Denier wrote:
On 10 mai 2010, at 13:48, Tudor Girba wrote:
Hi,
On 10 May 2010, at 12:40, Simon Denier wrote:
On 10 mai 2010, at 11:58, Tudor Girba wrote:
Hi,
It looks like most issues related to 4.0 are solved, with the exception of the Glamour cycle which I moved to 4.1. So, I would say that we can now release 4.0.
I would only have one question: What would you say about including the MOGraphVizLayout in this release? On the one hand, it offers a number of new layout possibilities, on the other hand it requires GraphViz to be installed in the command line and it works only on Linux and Mac (however, there is a check).
It's the same thing for infusion right? Except (infusion works on 3 platforms).
Indeed.
Does it mean it gets included in the one-click image?
What? The MOGraphVizLayout? If nobody has objections, then yes :). Or inFusion?
I was thinking of the platform-dependent graphviz package. But if there is already an informative check (like a pop-up informing user to install graphviz if not detected), I think it's good enough.
-- Simon
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Every thing should have the right to be different."
Hi Doru,
If MOGraphVizLayout is useful, then it should be part of Moose 4.0. However, I am not sure it has to be part of Mondrian itself. MOGraphVizLayout use OSProcess, and I think that Mondrian should not depend on OSProcess.
Cheers, Alexandre
On 10 May 2010, at 05:58, Tudor Girba wrote:
Hi,
It looks like most issues related to 4.0 are solved, with the exception of the Glamour cycle which I moved to 4.1. So, I would say that we can now release 4.0.
I would only have one question: What would you say about including the MOGraphVizLayout in this release? On the one hand, it offers a number of new layout possibilities, on the other hand it requires GraphViz to be installed in the command line and it works only on Linux and Mac (however, there is a check).
Cheers, Doru
-- www.tudorgirba.com
"Problem solving efficiency grows with the abstractness level of problem understanding."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
GraphVizLayout is pretty useful when you have large graphs without a particular order. MOGraphVizLayout provides convenience constructors (both class and instance side) for the different layouts supported by GraphViz. The spring layouts offered are pretty interesting.
The layouts are described briefly here: http://www.graphviz.org/
Cheers, Doru
On 10 May 2010, at 15:56, Alexandre Bergel wrote:
Hi Doru,
If MOGraphVizLayout is useful, then it should be part of Moose 4.0. However, I am not sure it has to be part of Mondrian itself. MOGraphVizLayout use OSProcess, and I think that Mondrian should not depend on OSProcess.
Cheers, Alexandre
On 10 May 2010, at 05:58, Tudor Girba wrote:
Hi,
It looks like most issues related to 4.0 are solved, with the exception of the Glamour cycle which I moved to 4.1. So, I would say that we can now release 4.0.
I would only have one question: What would you say about including the MOGraphVizLayout in this release? On the one hand, it offers a number of new layout possibilities, on the other hand it requires GraphViz to be installed in the command line and it works only on Linux and Mac (however, there is a check).
Cheers, Doru
-- www.tudorgirba.com
"Problem solving efficiency grows with the abstractness level of problem understanding."
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
"Speaking louder won't make the point worthier."
Most of these layouts are in Mondrian already. It would be cool to have a scalable spring layout.
Cheers, Alexandre
On 10 May 2010, at 11:51, Tudor Girba wrote:
GraphVizLayout is pretty useful when you have large graphs without a particular order. MOGraphVizLayout provides convenience constructors (both class and instance side) for the different layouts supported by GraphViz. The spring layouts offered are pretty interesting.
The layouts are described briefly here: http://www.graphviz.org/
Cheers, Doru
On 10 May 2010, at 15:56, Alexandre Bergel wrote:
Hi Doru,
If MOGraphVizLayout is useful, then it should be part of Moose 4.0. However, I am not sure it has to be part of Mondrian itself. MOGraphVizLayout use OSProcess, and I think that Mondrian should not depend on OSProcess.
Cheers, Alexandre
On 10 May 2010, at 05:58, Tudor Girba wrote:
Hi,
It looks like most issues related to 4.0 are solved, with the exception of the Glamour cycle which I moved to 4.1. So, I would say that we can now release 4.0.
I would only have one question: What would you say about including the MOGraphVizLayout in this release? On the one hand, it offers a number of new layout possibilities, on the other hand it requires GraphViz to be installed in the command line and it works only on Linux and Mac (however, there is a check).
Cheers, Doru
-- www.tudorgirba.com
"Problem solving efficiency grows with the abstractness level of problem understanding."
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
"Speaking louder won't make the point worthier."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hi Alex,
Not really.
Three of them (neato, fdp and sfdp) are spring layouts.
Dot is similar to the DominanceTreeLayout.
Twopi is similar to RadialTreeLayout, but the layout makes better use of space, especially when you have connected trees.
Even the circo layout is different in that it can handle multiple circles.
Cheers, Doru
On 10 May 2010, at 17:58, Alexandre Bergel wrote:
Most of these layouts are in Mondrian already. It would be cool to have a scalable spring layout.
Cheers, Alexandre
On 10 May 2010, at 11:51, Tudor Girba wrote:
GraphVizLayout is pretty useful when you have large graphs without a particular order. MOGraphVizLayout provides convenience constructors (both class and instance side) for the different layouts supported by GraphViz. The spring layouts offered are pretty interesting.
The layouts are described briefly here: http://www.graphviz.org/
Cheers, Doru
On 10 May 2010, at 15:56, Alexandre Bergel wrote:
Hi Doru,
If MOGraphVizLayout is useful, then it should be part of Moose 4.0. However, I am not sure it has to be part of Mondrian itself. MOGraphVizLayout use OSProcess, and I think that Mondrian should not depend on OSProcess.
Cheers, Alexandre
On 10 May 2010, at 05:58, Tudor Girba wrote:
Hi,
It looks like most issues related to 4.0 are solved, with the exception of the Glamour cycle which I moved to 4.1. So, I would say that we can now release 4.0.
I would only have one question: What would you say about including the MOGraphVizLayout in this release? On the one hand, it offers a number of new layout possibilities, on the other hand it requires GraphViz to be installed in the command line and it works only on Linux and Mac (however, there is a check).
Cheers, Doru
-- www.tudorgirba.com
"Problem solving efficiency grows with the abstractness level of problem understanding."
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
"Speaking louder won't make the point worthier."
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
"Speaking louder won't make the point worthier."
Hi,
I have two more issues on the topic of dependencies to be loaded by the default configuration:
1. XML Support I would include the XML-Parser from the XMLSupport repo and OPAX (the small addition to the SAXParser that enables dealing with tags polymorphically)
2. Magritte as a requirement for MagrittePresentation in Glamour It is true that there is no direct usage of Magritte, but if we want to position Moose as allowing people to build their own tools, I think it is important. An example of what can be done with it can be seen here: http://www.themoosebook.org/book/internals/glamour/presentations/magritte
The drawback here is that this would load 150 classes (including tests) + 50 classes from Grease.
What do you think?
Cheers, Doru
On 10 May 2010, at 18:08, Tudor Girba wrote:
Hi Alex,
Not really.
Three of them (neato, fdp and sfdp) are spring layouts.
Dot is similar to the DominanceTreeLayout.
Twopi is similar to RadialTreeLayout, but the layout makes better use of space, especially when you have connected trees.
Even the circo layout is different in that it can handle multiple circles.
Cheers, Doru
On 10 May 2010, at 17:58, Alexandre Bergel wrote:
Most of these layouts are in Mondrian already. It would be cool to have a scalable spring layout.
Cheers, Alexandre
On 10 May 2010, at 11:51, Tudor Girba wrote:
GraphVizLayout is pretty useful when you have large graphs without a particular order. MOGraphVizLayout provides convenience constructors (both class and instance side) for the different layouts supported by GraphViz. The spring layouts offered are pretty interesting.
The layouts are described briefly here: http://www.graphviz.org/
Cheers, Doru
On 10 May 2010, at 15:56, Alexandre Bergel wrote:
Hi Doru,
If MOGraphVizLayout is useful, then it should be part of Moose 4.0. However, I am not sure it has to be part of Mondrian itself. MOGraphVizLayout use OSProcess, and I think that Mondrian should not depend on OSProcess.
Cheers, Alexandre
On 10 May 2010, at 05:58, Tudor Girba wrote:
Hi,
It looks like most issues related to 4.0 are solved, with the exception of the Glamour cycle which I moved to 4.1. So, I would say that we can now release 4.0.
I would only have one question: What would you say about including the MOGraphVizLayout in this release? On the one hand, it offers a number of new layout possibilities, on the other hand it requires GraphViz to be installed in the command line and it works only on Linux and Mac (however, there is a check).
Cheers, Doru
-- www.tudorgirba.com
"Problem solving efficiency grows with the abstractness level of problem understanding."
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
"Speaking louder won't make the point worthier."
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
"Speaking louder won't make the point worthier."
-- www.tudorgirba.com
"There are no old things, there are only old ways of looking at them."
I have two more issues on the topic of dependencies to be loaded by the default configuration:
- XML Support
I would include the XML-Parser from the XMLSupport repo and OPAX (the small addition to the SAXParser that enables dealing with tags polymorphically)
I was wondering, should OPAX be kept separated from XMLSupport?
- Magritte as a requirement for MagrittePresentation in Glamour
It is true that there is no direct usage of Magritte, but if we want to position Moose as allowing people to build their own tools, I think it is important. An example of what can be done with it can be seen here: http://www.themoosebook.org/book/internals/glamour/presentations/magritte
The drawback here is that this would load 150 classes (including tests) + 50 classes from Grease. What do you think?
We should promote innovation. Include it then. 200 classes is nothing compared to loading Linux and Swing in the same image.
Alexandre
Cheers, Doru
On 10 May 2010, at 18:08, Tudor Girba wrote:
Hi Alex,
Not really.
Three of them (neato, fdp and sfdp) are spring layouts.
Dot is similar to the DominanceTreeLayout.
Twopi is similar to RadialTreeLayout, but the layout makes better use of space, especially when you have connected trees.
Even the circo layout is different in that it can handle multiple circles.
Cheers, Doru
On 10 May 2010, at 17:58, Alexandre Bergel wrote:
Most of these layouts are in Mondrian already. It would be cool to have a scalable spring layout.
Cheers, Alexandre
On 10 May 2010, at 11:51, Tudor Girba wrote:
GraphVizLayout is pretty useful when you have large graphs without a particular order. MOGraphVizLayout provides convenience constructors (both class and instance side) for the different layouts supported by GraphViz. The spring layouts offered are pretty interesting.
The layouts are described briefly here: http://www.graphviz.org/
Cheers, Doru
On 10 May 2010, at 15:56, Alexandre Bergel wrote:
Hi Doru,
If MOGraphVizLayout is useful, then it should be part of Moose 4.0. However, I am not sure it has to be part of Mondrian itself. MOGraphVizLayout use OSProcess, and I think that Mondrian should not depend on OSProcess.
Cheers, Alexandre
On 10 May 2010, at 05:58, Tudor Girba wrote:
Hi,
It looks like most issues related to 4.0 are solved, with the exception of the Glamour cycle which I moved to 4.1. So, I would say that we can now release 4.0.
I would only have one question: What would you say about including the MOGraphVizLayout in this release? On the one hand, it offers a number of new layout possibilities, on the other hand it requires GraphViz to be installed in the command line and it works only on Linux and Mac (however, there is a check).
Cheers, Doru
-- www.tudorgirba.com
"Problem solving efficiency grows with the abstractness level of problem understanding."
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
"Speaking louder won't make the point worthier."
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
"Speaking louder won't make the point worthier."
-- www.tudorgirba.com
"There are no old things, there are only old ways of looking at them."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hi,
On 14 May 2010, at 18:48, Alexandre Bergel wrote:
I have two more issues on the topic of dependencies to be loaded by the default configuration:
- XML Support
I would include the XML-Parser from the XMLSupport repo and OPAX (the small addition to the SAXParser that enables dealing with tags polymorphically)
I was wondering, should OPAX be kept separated from XMLSupport?
I would be happy if OPAX would get integrated into XMLSupport. I think it belongs there. There are a number of things that could be added (such as better matching for tags, or various default traversals), but I think even as simple as it currently is, it still adds to the SAX protocol.
- Magritte as a requirement for MagrittePresentation in Glamour
It is true that there is no direct usage of Magritte, but if we want to position Moose as allowing people to build their own tools, I think it is important. An example of what can be done with it can be seen here: http://www.themoosebook.org/book/internals/glamour/presentations/magritte
The drawback here is that this would load 150 classes (including tests) + 50 classes from Grease. What do you think?
We should promote innovation. Include it then. 200 classes is nothing compared to loading Linux and Swing in the same image
That is true. I was just weighing pros and cons :)
Cheers, Doru
Alexandre
Cheers, Doru
On 10 May 2010, at 18:08, Tudor Girba wrote:
Hi Alex,
Not really.
Three of them (neato, fdp and sfdp) are spring layouts.
Dot is similar to the DominanceTreeLayout.
Twopi is similar to RadialTreeLayout, but the layout makes better use of space, especially when you have connected trees.
Even the circo layout is different in that it can handle multiple circles.
Cheers, Doru
On 10 May 2010, at 17:58, Alexandre Bergel wrote:
Most of these layouts are in Mondrian already. It would be cool to have a scalable spring layout.
Cheers, Alexandre
On 10 May 2010, at 11:51, Tudor Girba wrote:
GraphVizLayout is pretty useful when you have large graphs without a particular order. MOGraphVizLayout provides convenience constructors (both class and instance side) for the different layouts supported by GraphViz. The spring layouts offered are pretty interesting.
The layouts are described briefly here: http://www.graphviz.org/
Cheers, Doru
On 10 May 2010, at 15:56, Alexandre Bergel wrote:
Hi Doru,
If MOGraphVizLayout is useful, then it should be part of Moose 4.0. However, I am not sure it has to be part of Mondrian itself. MOGraphVizLayout use OSProcess, and I think that Mondrian should not depend on OSProcess.
Cheers, Alexandre
On 10 May 2010, at 05:58, Tudor Girba wrote:
> Hi, > > It looks like most issues related to 4.0 are solved, with the > exception of the Glamour cycle which I moved to 4.1. So, I > would say that we can now release 4.0. > > I would only have one question: What would you say about > including the MOGraphVizLayout in this release? > On the one hand, it offers a number of new layout > possibilities, on the other hand it requires GraphViz to be > installed in the command line and it works only on Linux and > Mac (however, there is a check). > > Cheers, > Doru > > > -- > www.tudorgirba.com > > "Problem solving efficiency grows with the abstractness level > of problem understanding." > > > > _______________________________________________ > 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
"Speaking louder won't make the point worthier."
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
"Speaking louder won't make the point worthier."
-- www.tudorgirba.com
"There are no old things, there are only old ways of looking at them."
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
"Being happy is a matter of choice."
I was wondering, should OPAX be kept separated from XMLSupport?
I would be happy if OPAX would get integrated into XMLSupport. I think it belongs there. There are a number of things that could be added (such as better matching for tags, or various default traversals), but I think even as simple as it currently is, it still adds to the SAX protocol.
Ok. I will include OPAX in XMLSupport. Just give me a few days.
Alexandre
- Magritte as a requirement for MagrittePresentation in Glamour
It is true that there is no direct usage of Magritte, but if we want to position Moose as allowing people to build their own tools, I think it is important. An example of what can be done with it can be seen here: http://www.themoosebook.org/book/internals/glamour/presentations/magritte
The drawback here is that this would load 150 classes (including tests) + 50 classes from Grease. What do you think?
We should promote innovation. Include it then. 200 classes is nothing compared to loading Linux and Swing in the same image
That is true. I was just weighing pros and cons :)
Cheers, Doru
Alexandre
Cheers, Doru
On 10 May 2010, at 18:08, Tudor Girba wrote:
Hi Alex,
Not really.
Three of them (neato, fdp and sfdp) are spring layouts.
Dot is similar to the DominanceTreeLayout.
Twopi is similar to RadialTreeLayout, but the layout makes better use of space, especially when you have connected trees.
Even the circo layout is different in that it can handle multiple circles.
Cheers, Doru
On 10 May 2010, at 17:58, Alexandre Bergel wrote:
Most of these layouts are in Mondrian already. It would be cool to have a scalable spring layout.
Cheers, Alexandre
On 10 May 2010, at 11:51, Tudor Girba wrote:
GraphVizLayout is pretty useful when you have large graphs without a particular order. MOGraphVizLayout provides convenience constructors (both class and instance side) for the different layouts supported by GraphViz. The spring layouts offered are pretty interesting.
The layouts are described briefly here: http://www.graphviz.org/
Cheers, Doru
On 10 May 2010, at 15:56, Alexandre Bergel wrote:
> Hi Doru, > > If MOGraphVizLayout is useful, then it should be part of Moose 4.0. However, I am not sure it has to be part of Mondrian itself. MOGraphVizLayout use OSProcess, and I think that Mondrian should not depend on OSProcess. > > Cheers, > Alexandre > > > On 10 May 2010, at 05:58, Tudor Girba wrote: > >> Hi, >> >> It looks like most issues related to 4.0 are solved, with the exception of the Glamour cycle which I moved to 4.1. So, I would say that we can now release 4.0. >> >> I would only have one question: What would you say about including the MOGraphVizLayout in this release? >> On the one hand, it offers a number of new layout possibilities, on the other hand it requires GraphViz to be installed in the command line and it works only on Linux and Mac (however, there is a check). >> >> Cheers, >> Doru >> >> >> -- >> www.tudorgirba.com >> >> "Problem solving efficiency grows with the abstractness level of problem understanding." >> >> >> >> _______________________________________________ >> 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
"Speaking louder won't make the point worthier."
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
"Speaking louder won't make the point worthier."
-- www.tudorgirba.com
"There are no old things, there are only old ways of looking at them."
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
"Being happy is a matter of choice."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Hi all,
There is no more issue in bugTracker for 4.0. We should push the release, now.
Alex, have you finished to include OPAX ? Do you need help ?
Is there something to do for the release ? With Cyrille, we can do this afternoon the Metacello configuration for it.
Cheers,
On May 16, 2010, at 23:12 , Alexandre Bergel wrote:
I was wondering, should OPAX be kept separated from XMLSupport?
I would be happy if OPAX would get integrated into XMLSupport. I think it belongs there. There are a number of things that could be added (such as better matching for tags, or various default traversals), but I think even as simple as it currently is, it still adds to the SAX protocol.
Ok. I will include OPAX in XMLSupport. Just give me a few days.
Alexandre
--- Jannik Laval
Hi,
Hi all,
There is no more issue in bugTracker for 4.0. We should push the release, now.
Yes.
Alex, have you finished to include OPAX ? Do you need help ?
For OPAX, we could just simply move the package over to XMLSupport.
Is there something to do for the release ?
I am now working on adding Magritte as prerequisite for Glamour. I will let you know when I am done.
With Cyrille, we can do this afternoon the Metacello configuration for it.
Great. I will be online.
Cheers, Doru
Cheers,
On May 16, 2010, at 23:12 , Alexandre Bergel wrote:
I was wondering, should OPAX be kept separated from XMLSupport?
I would be happy if OPAX would get integrated into XMLSupport. I think it belongs there. There are a number of things that could be added (such as better matching for tags, or various default traversals), but I think even as simple as it currently is, it still adds to the SAX protocol.
Ok. I will include OPAX in XMLSupport. Just give me a few days.
Alexandre
Jannik Laval
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"To lead is not to demand things, it is to make them happen."
Hi,
I added: - Magritte to the default configuration of Glamour - Arki-Reporter package to the ConfigurationOfMoose - ConfigurationOfXMLSupport (1.0.1-baseline) to the ConfigurationOfMoose - Opax package to the ConfigurationOfMoose
Everything loads fine: http://hudson.moosetechnology.org/job/moose-latest-dev/152/
Cheers, Doru
On 21 May 2010, at 09:57, Tudor Girba wrote:
Hi,
Hi all,
There is no more issue in bugTracker for 4.0. We should push the release, now.
Yes.
Alex, have you finished to include OPAX ? Do you need help ?
For OPAX, we could just simply move the package over to XMLSupport.
Is there something to do for the release ?
I am now working on adding Magritte as prerequisite for Glamour. I will let you know when I am done.
With Cyrille, we can do this afternoon the Metacello configuration for it.
Great. I will be online.
Cheers, Doru
Cheers,
On May 16, 2010, at 23:12 , Alexandre Bergel wrote:
I was wondering, should OPAX be kept separated from XMLSupport?
I would be happy if OPAX would get integrated into XMLSupport. I think it belongs there. There are a number of things that could be added (such as better matching for tags, or various default traversals), but I think even as simple as it currently is, it still adds to the SAX protocol.
Ok. I will include OPAX in XMLSupport. Just give me a few days.
Alexandre
Jannik Laval
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"To lead is not to demand things, it is to make them happen."
-- www.tudorgirba.com
"Problem solving efficiency grows with the abstractness level of problem understanding."
Alex, have you finished to include OPAX ? Do you need help ?
I planned to do this before Sunday. And it has nothing to do with lazyness, believe me
Alexandre
Is there something to do for the release ? With Cyrille, we can do this afternoon the Metacello configuration for it.
Cheers,
On May 16, 2010, at 23:12 , Alexandre Bergel wrote:
I was wondering, should OPAX be kept separated from XMLSupport?
I would be happy if OPAX would get integrated into XMLSupport. I think it belongs there. There are a number of things that could be added (such as better matching for tags, or various default traversals), but I think even as simple as it currently is, it still adds to the SAX protocol.
Ok. I will include OPAX in XMLSupport. Just give me a few days.
Alexandre
Jannik Laval
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Opax is now in. I added a small method called readme in OPOpaxTest. It says what Opax is for.
I could not understand the class OPOpaxHandlerTestClass. This class is part of a test scenario. But I cannot easily see a justification of the method override in it. Maybe the class could be documented?
Cheers, Alexandre
On 21 May 2010, at 07:45, Alexandre Bergel wrote:
Alex, have you finished to include OPAX ? Do you need help ?
I planned to do this before Sunday. And it has nothing to do with lazyness, believe me
Alexandre
Is there something to do for the release ? With Cyrille, we can do this afternoon the Metacello configuration for it.
Cheers,
On May 16, 2010, at 23:12 , Alexandre Bergel wrote:
I was wondering, should OPAX be kept separated from XMLSupport?
I would be happy if OPAX would get integrated into XMLSupport. I think it belongs there. There are a number of things that could be added (such as better matching for tags, or various default traversals), but I think even as simple as it currently is, it still adds to the SAX protocol.
Ok. I will include OPAX in XMLSupport. Just give me a few days.
Alexandre
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
Hi Alex,
Thanks. I will then remove the Opax from the ConfigurationOfMoose.
Just a question, which ConfigurationOfXMLParser should we depend on? The one from the XMLSupport repository, or the one from the MetacelloRepository. I would prefer the one from the XMLSupport repository.
Cheers, Doru
On 21 May 2010, at 19:11, Alexandre Bergel wrote:
Opax is now in. I added a small method called readme in OPOpaxTest. It says what Opax is for.
I could not understand the class OPOpaxHandlerTestClass. This class is part of a test scenario. But I cannot easily see a justification of the method override in it. Maybe the class could be documented?
Cheers, Alexandre
On 21 May 2010, at 07:45, Alexandre Bergel wrote:
Alex, have you finished to include OPAX ? Do you need help ?
I planned to do this before Sunday. And it has nothing to do with lazyness, believe me
Alexandre
Is there something to do for the release ? With Cyrille, we can do this afternoon the Metacello configuration for it.
Cheers,
On May 16, 2010, at 23:12 , Alexandre Bergel wrote:
I was wondering, should OPAX be kept separated from XMLSupport?
I would be happy if OPAX would get integrated into XMLSupport. I think it belongs there. There are a number of things that could be added (such as better matching for tags, or various default traversals), but I think even as simple as it currently is, it still adds to the SAX protocol.
Ok. I will include OPAX in XMLSupport. Just give me a few days.
Alexandre
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
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Some battles are better lost than fought."
Pick ConfigurationOfXMLSupport from XMLSupport.
Cheers, Alexandre
On 21 May 2010, at 14:25, Tudor Girba wrote:
Hi Alex,
Thanks. I will then remove the Opax from the ConfigurationOfMoose.
Just a question, which ConfigurationOfXMLParser should we depend on? The one from the XMLSupport repository, or the one from the MetacelloRepository. I would prefer the one from the XMLSupport repository.
Cheers, Doru
On 21 May 2010, at 19:11, Alexandre Bergel wrote:
Opax is now in. I added a small method called readme in OPOpaxTest. It says what Opax is for.
I could not understand the class OPOpaxHandlerTestClass. This class is part of a test scenario. But I cannot easily see a justification of the method override in it. Maybe the class could be documented?
Cheers, Alexandre
On 21 May 2010, at 07:45, Alexandre Bergel wrote:
Alex, have you finished to include OPAX ? Do you need help ?
I planned to do this before Sunday. And it has nothing to do with lazyness, believe me
Alexandre
Is there something to do for the release ? With Cyrille, we can do this afternoon the Metacello configuration for it.
Cheers,
On May 16, 2010, at 23:12 , Alexandre Bergel wrote:
> I was wondering, should OPAX be kept separated from XMLSupport?
I would be happy if OPAX would get integrated into XMLSupport. I think it belongs there. There are a number of things that could be added (such as better matching for tags, or various default traversals), but I think even as simple as it currently is, it still adds to the SAX protocol.
Ok. I will include OPAX in XMLSupport. Just give me a few days.
Alexandre
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
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Some battles are better lost than fought."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Ok, I updated the ConfigurationOfMoose and everything looks Ok.
Cheers, Doru
On 21 May 2010, at 21:49, Alexandre Bergel wrote:
Pick ConfigurationOfXMLSupport from XMLSupport.
Cheers, Alexandre
On 21 May 2010, at 14:25, Tudor Girba wrote:
Hi Alex,
Thanks. I will then remove the Opax from the ConfigurationOfMoose.
Just a question, which ConfigurationOfXMLParser should we depend on? The one from the XMLSupport repository, or the one from the MetacelloRepository. I would prefer the one from the XMLSupport repository.
Cheers, Doru
On 21 May 2010, at 19:11, Alexandre Bergel wrote:
Opax is now in. I added a small method called readme in OPOpaxTest. It says what Opax is for.
I could not understand the class OPOpaxHandlerTestClass. This class is part of a test scenario. But I cannot easily see a justification of the method override in it. Maybe the class could be documented?
Cheers, Alexandre
On 21 May 2010, at 07:45, Alexandre Bergel wrote:
Alex, have you finished to include OPAX ? Do you need help ?
I planned to do this before Sunday. And it has nothing to do with lazyness, believe me
Alexandre
Is there something to do for the release ? With Cyrille, we can do this afternoon the Metacello configuration for it.
Cheers,
On May 16, 2010, at 23:12 , Alexandre Bergel wrote:
>> I was wondering, should OPAX be kept separated from XMLSupport? > > I would be happy if OPAX would get integrated into XMLSupport. > I think it belongs there. There are a number of things that > could be added (such as better matching for tags, or various > default traversals), but I think even as simple as it > currently is, it still adds to the SAX protocol.
Ok. I will include OPAX in XMLSupport. Just give me a few days.
Alexandre
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
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Some battles are better lost than fought."
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
"Presenting is storytelling."
-
Alexandre Bergel -
Alexandre Bergel -
Laval Jannik -
Simon Denier -
Tudor Girba