Hi Dennis,
I went briefly over your code. I think the algorithm gets in a good state!
- MalHgRepository should be removed from this level. It is essentially not used. It only adds global variables and it is not essential for the algorithm. - MooseAlgos is at the lowest level in Moose, and it should have no dependencies to other parts like FAMIX. Please fix the tests. - The MalHgVisitorTask hierarchy and MalHgBottomUpNodeVisitor are not used and should be removed from the package. - MalHgUtilities are not used within the package and should be removed from the package. - FILOStack is only used in a test so it seems to not be particularly useful.
In general, we want to keep global state to a bare minimum because we want to enable unforeseen combinations at object-level. Caches can be built at a certain application level, but only if truly necessary.
After we do this cleaning, we can move on to add the package to the configuration.
Cheers, Doru
On Apr 18, 2013, at 7:12 AM, Tudor Girba tudor@tudorgirba.com wrote:
Hi Dennis,
Excellent news :). I will try to take a bit of time to look into it.
Just please let's have these discussions over the mailing list because others might get interested as well. In case you think that you would waste other people's time, HierarchicalGraphs is now part of the 5.0 Roadmap :)
Cheers, Doru
p.s. and please use tudor@tudorgirba.com
On Apr 17, 2013, at 2:24 PM, Dennis Schenk d.schenk@students.unibe.ch wrote:
Hi Doru,
I moved the Quicksilver-Core to Moose-Algos-HierarchicalGraph and the tests to Moose-Tests-Algos-HierarchicalGraph. I also renamed the classes. Could you take a look and see if everything looks good from your point of view?
I did not touch ConfigurationOfMooseAlgos so far as I am not sure to which version the packages should be added. I assume 2.4? But did not see a version for this.
I guess one of the next steps should be to look how we can further merge the code bases, e.g. using classes like MalGraphNode and MalGraphEdge as parents of MalHgNode and MalHgEdge. I also made some utilities which I can guess are already implemented somewhere, like a linear equation generator. If you have some ideas there, or would like to code on this as well, tell me.
Cheers, Dennis
-- www.tudorgirba.com
"One cannot do more than one can do."
-- www.tudorgirba.com
"Sometimes the best solution is not the best solution."
In general, we want to keep global state to a bare minimum because we want to enable unforeseen combinations at object-level. Caches can be built at a certain application level, but only if truly necessary.
Yes! Caches should be built by subclassing and combining objects.
Cheers, Alexandre
Hi,
I took care of all your suggestions and also began to integrate the HierarchicalGraph more tightly into the MooseAlgos graph system: MalHgNode is now a subclass of MalGraphNode, MalHgEdge of MalGraphEdge and MalHierarchicalGraph of MalGraphAlgorithm.
There are some differences in the APIs of MalGraphAlgorithm and MalHierarchicalGraph. Will look into how to integrate them better next.
Cheers, Dennis
On Sun, Apr 21, 2013 at 8:36 AM, Tudor Girba tudor@tudorgirba.com wrote:
Hi Dennis,
I went briefly over your code. I think the algorithm gets in a good state!
- MalHgRepository should be removed from this level. It is essentially not
used. It only adds global variables and it is not essential for the algorithm.
- MooseAlgos is at the lowest level in Moose, and it should have no
dependencies to other parts like FAMIX. Please fix the tests.
- The MalHgVisitorTask hierarchy and MalHgBottomUpNodeVisitor are not used
and should be removed from the package.
- MalHgUtilities are not used within the package and should be removed
from the package.
- FILOStack is only used in a test so it seems to not be particularly
useful.
In general, we want to keep global state to a bare minimum because we want to enable unforeseen combinations at object-level. Caches can be built at a certain application level, but only if truly necessary.
After we do this cleaning, we can move on to add the package to the configuration.
Cheers, Doru
On Apr 18, 2013, at 7:12 AM, Tudor Girba tudor@tudorgirba.com wrote:
Hi Dennis,
Excellent news :). I will try to take a bit of time to look into it.
Just please let's have these discussions over the mailing list because
others might get interested as well. In case you think that you would waste other people's time, HierarchicalGraphs is now part of the 5.0 Roadmap :)
Cheers, Doru
p.s. and please use tudor@tudorgirba.com
On Apr 17, 2013, at 2:24 PM, Dennis Schenk d.schenk@students.unibe.ch
wrote:
Hi Doru,
I moved the Quicksilver-Core to Moose-Algos-HierarchicalGraph and the
tests to Moose-Tests-Algos-HierarchicalGraph. I also renamed the classes. Could you take a look and see if everything looks good from your point of view?
I did not touch ConfigurationOfMooseAlgos so far as I am not sure to
which version the packages should be added. I assume 2.4? But did not see a version for this.
I guess one of the next steps should be to look how we can further
merge the code bases, e.g. using classes like MalGraphNode and MalGraphEdge as parents of MalHgNode and MalHgEdge. I also made some utilities which I can guess are already implemented somewhere, like a linear equation generator. If you have some ideas there, or would like to code on this as well, tell me.
Cheers, Dennis
-- www.tudorgirba.com
"One cannot do more than one can do."
-- www.tudorgirba.com
"Sometimes the best solution is not the best solution."
Great. I will go over it again this week.
Doru
On Apr 23, 2013, at 12:19 PM, Dennis Schenk d.schenk@students.unibe.ch wrote:
Hi,
I took care of all your suggestions and also began to integrate the HierarchicalGraph more tightly into the MooseAlgos graph system: MalHgNode is now a subclass of MalGraphNode, MalHgEdge of MalGraphEdge and MalHierarchicalGraph of MalGraphAlgorithm.
There are some differences in the APIs of MalGraphAlgorithm and MalHierarchicalGraph. Will look into how to integrate them better next.
Cheers, Dennis
On Sun, Apr 21, 2013 at 8:36 AM, Tudor Girba tudor@tudorgirba.com wrote: Hi Dennis,
I went briefly over your code. I think the algorithm gets in a good state!
- MalHgRepository should be removed from this level. It is essentially not used. It only adds global variables and it is not essential for the algorithm.
- MooseAlgos is at the lowest level in Moose, and it should have no dependencies to other parts like FAMIX. Please fix the tests.
- The MalHgVisitorTask hierarchy and MalHgBottomUpNodeVisitor are not used and should be removed from the package.
- MalHgUtilities are not used within the package and should be removed from the package.
- FILOStack is only used in a test so it seems to not be particularly useful.
In general, we want to keep global state to a bare minimum because we want to enable unforeseen combinations at object-level. Caches can be built at a certain application level, but only if truly necessary.
After we do this cleaning, we can move on to add the package to the configuration.
Cheers, Doru
On Apr 18, 2013, at 7:12 AM, Tudor Girba tudor@tudorgirba.com wrote:
Hi Dennis,
Excellent news :). I will try to take a bit of time to look into it.
Just please let's have these discussions over the mailing list because others might get interested as well. In case you think that you would waste other people's time, HierarchicalGraphs is now part of the 5.0 Roadmap :)
Cheers, Doru
p.s. and please use tudor@tudorgirba.com
On Apr 17, 2013, at 2:24 PM, Dennis Schenk d.schenk@students.unibe.ch wrote:
Hi Doru,
I moved the Quicksilver-Core to Moose-Algos-HierarchicalGraph and the tests to Moose-Tests-Algos-HierarchicalGraph. I also renamed the classes. Could you take a look and see if everything looks good from your point of view?
I did not touch ConfigurationOfMooseAlgos so far as I am not sure to which version the packages should be added. I assume 2.4? But did not see a version for this.
I guess one of the next steps should be to look how we can further merge the code bases, e.g. using classes like MalGraphNode and MalGraphEdge as parents of MalHgNode and MalHgEdge. I also made some utilities which I can guess are already implemented somewhere, like a linear equation generator. If you have some ideas there, or would like to code on this as well, tell me.
Cheers, Dennis
-- www.tudorgirba.com
"One cannot do more than one can do."
-- www.tudorgirba.com
"Sometimes the best solution is not the best solution."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Be rather willing to give than demanding to get."
Hi,
I looked over the current state. Looks much better. I added it to the configuration now.
Next I would like to look at Quicksilver :)
Cheers, Doru
On Apr 24, 2013, at 6:46 AM, Tudor Girba tudor@tudorgirba.com wrote:
Great. I will go over it again this week.
Doru
On Apr 23, 2013, at 12:19 PM, Dennis Schenk d.schenk@students.unibe.ch wrote:
Hi,
I took care of all your suggestions and also began to integrate the HierarchicalGraph more tightly into the MooseAlgos graph system: MalHgNode is now a subclass of MalGraphNode, MalHgEdge of MalGraphEdge and MalHierarchicalGraph of MalGraphAlgorithm.
There are some differences in the APIs of MalGraphAlgorithm and MalHierarchicalGraph. Will look into how to integrate them better next.
Cheers, Dennis
On Sun, Apr 21, 2013 at 8:36 AM, Tudor Girba tudor@tudorgirba.com wrote: Hi Dennis,
I went briefly over your code. I think the algorithm gets in a good state!
- MalHgRepository should be removed from this level. It is essentially not used. It only adds global variables and it is not essential for the algorithm.
- MooseAlgos is at the lowest level in Moose, and it should have no dependencies to other parts like FAMIX. Please fix the tests.
- The MalHgVisitorTask hierarchy and MalHgBottomUpNodeVisitor are not used and should be removed from the package.
- MalHgUtilities are not used within the package and should be removed from the package.
- FILOStack is only used in a test so it seems to not be particularly useful.
In general, we want to keep global state to a bare minimum because we want to enable unforeseen combinations at object-level. Caches can be built at a certain application level, but only if truly necessary.
After we do this cleaning, we can move on to add the package to the configuration.
Cheers, Doru
On Apr 18, 2013, at 7:12 AM, Tudor Girba tudor@tudorgirba.com wrote:
Hi Dennis,
Excellent news :). I will try to take a bit of time to look into it.
Just please let's have these discussions over the mailing list because others might get interested as well. In case you think that you would waste other people's time, HierarchicalGraphs is now part of the 5.0 Roadmap :)
Cheers, Doru
p.s. and please use tudor@tudorgirba.com
On Apr 17, 2013, at 2:24 PM, Dennis Schenk d.schenk@students.unibe.ch wrote:
Hi Doru,
I moved the Quicksilver-Core to Moose-Algos-HierarchicalGraph and the tests to Moose-Tests-Algos-HierarchicalGraph. I also renamed the classes. Could you take a look and see if everything looks good from your point of view?
I did not touch ConfigurationOfMooseAlgos so far as I am not sure to which version the packages should be added. I assume 2.4? But did not see a version for this.
I guess one of the next steps should be to look how we can further merge the code bases, e.g. using classes like MalGraphNode and MalGraphEdge as parents of MalHgNode and MalHgEdge. I also made some utilities which I can guess are already implemented somewhere, like a linear equation generator. If you have some ideas there, or would like to code on this as well, tell me.
Cheers, Dennis
-- www.tudorgirba.com
"One cannot do more than one can do."
-- www.tudorgirba.com
"Sometimes the best solution is not the best solution."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Be rather willing to give than demanding to get."
-- 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."
Hi Doru,
Cool thanks.
If there is anything you would like to know about Quicksilver, don't hesitate to ask. You can also look at: http://scg.unibe.ch/research/quicksilver
Cheers, Dennis
On Wed, Apr 24, 2013 at 10:37 PM, Tudor Girba tudor@tudorgirba.com wrote:
Hi,
I looked over the current state. Looks much better. I added it to the configuration now.
Next I would like to look at Quicksilver :)
Cheers, Doru
On Apr 24, 2013, at 6:46 AM, Tudor Girba tudor@tudorgirba.com wrote:
Great. I will go over it again this week.
Doru
On Apr 23, 2013, at 12:19 PM, Dennis Schenk d.schenk@students.unibe.ch
wrote:
Hi,
I took care of all your suggestions and also began to integrate the
HierarchicalGraph more tightly into the MooseAlgos graph system: MalHgNode is now a subclass of MalGraphNode, MalHgEdge of MalGraphEdge and MalHierarchicalGraph of MalGraphAlgorithm.
There are some differences in the APIs of MalGraphAlgorithm and
MalHierarchicalGraph. Will look into how to integrate them better next.
Cheers, Dennis
On Sun, Apr 21, 2013 at 8:36 AM, Tudor Girba tudor@tudorgirba.com
wrote:
Hi Dennis,
I went briefly over your code. I think the algorithm gets in a good
state!
- MalHgRepository should be removed from this level. It is essentially
not used. It only adds global variables and it is not essential for the algorithm.
- MooseAlgos is at the lowest level in Moose, and it should have no
dependencies to other parts like FAMIX. Please fix the tests.
- The MalHgVisitorTask hierarchy and MalHgBottomUpNodeVisitor are not
used and should be removed from the package.
- MalHgUtilities are not used within the package and should be removed
from the package.
- FILOStack is only used in a test so it seems to not be particularly
useful.
In general, we want to keep global state to a bare minimum because we
want to enable unforeseen combinations at object-level. Caches can be built at a certain application level, but only if truly necessary.
After we do this cleaning, we can move on to add the package to the
configuration.
Cheers, Doru
On Apr 18, 2013, at 7:12 AM, Tudor Girba tudor@tudorgirba.com wrote:
Hi Dennis,
Excellent news :). I will try to take a bit of time to look into it.
Just please let's have these discussions over the mailing list because
others might get interested as well. In case you think that you would waste other people's time, HierarchicalGraphs is now part of the 5.0 Roadmap :)
Cheers, Doru
p.s. and please use tudor@tudorgirba.com
On Apr 17, 2013, at 2:24 PM, Dennis Schenk d.schenk@students.unibe.ch
wrote:
Hi Doru,
I moved the Quicksilver-Core to Moose-Algos-HierarchicalGraph and the
tests to Moose-Tests-Algos-HierarchicalGraph. I also renamed the classes. Could you take a look and see if everything looks good from your point of view?
I did not touch ConfigurationOfMooseAlgos so far as I am not sure to
which version the packages should be added. I assume 2.4? But did not see a version for this.
I guess one of the next steps should be to look how we can further
merge the code bases, e.g. using classes like MalGraphNode and MalGraphEdge as parents of MalHgNode and MalHgEdge. I also made some utilities which I can guess are already implemented somewhere, like a linear equation generator. If you have some ideas there, or would like to code on this as well, tell me.
Cheers, Dennis
-- www.tudorgirba.com
"One cannot do more than one can do."
-- www.tudorgirba.com
"Sometimes the best solution is not the best solution."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Be rather willing to give than demanding to get."
-- 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."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Thanks Dennis!
Something that would be great, is to have screenshots on: http://scg.unibe.ch/research/quicksilver/HierarchicalGraph
Cheers, Alexandre
On Apr 30, 2013, at 4:28 AM, Dennis Schenk d.schenk@students.unibe.ch wrote:
Hi Doru,
Cool thanks.
If there is anything you would like to know about Quicksilver, don't hesitate to ask. You can also look at: http://scg.unibe.ch/research/quicksilver
Cheers, Dennis
On Wed, Apr 24, 2013 at 10:37 PM, Tudor Girba tudor@tudorgirba.com wrote: Hi,
I looked over the current state. Looks much better. I added it to the configuration now.
Next I would like to look at Quicksilver :)
Cheers, Doru
On Apr 24, 2013, at 6:46 AM, Tudor Girba tudor@tudorgirba.com wrote:
Great. I will go over it again this week.
Doru
On Apr 23, 2013, at 12:19 PM, Dennis Schenk d.schenk@students.unibe.ch wrote:
Hi,
I took care of all your suggestions and also began to integrate the HierarchicalGraph more tightly into the MooseAlgos graph system: MalHgNode is now a subclass of MalGraphNode, MalHgEdge of MalGraphEdge and MalHierarchicalGraph of MalGraphAlgorithm.
There are some differences in the APIs of MalGraphAlgorithm and MalHierarchicalGraph. Will look into how to integrate them better next.
Cheers, Dennis
On Sun, Apr 21, 2013 at 8:36 AM, Tudor Girba tudor@tudorgirba.com wrote: Hi Dennis,
I went briefly over your code. I think the algorithm gets in a good state!
- MalHgRepository should be removed from this level. It is essentially not used. It only adds global variables and it is not essential for the algorithm.
- MooseAlgos is at the lowest level in Moose, and it should have no dependencies to other parts like FAMIX. Please fix the tests.
- The MalHgVisitorTask hierarchy and MalHgBottomUpNodeVisitor are not used and should be removed from the package.
- MalHgUtilities are not used within the package and should be removed from the package.
- FILOStack is only used in a test so it seems to not be particularly useful.
In general, we want to keep global state to a bare minimum because we want to enable unforeseen combinations at object-level. Caches can be built at a certain application level, but only if truly necessary.
After we do this cleaning, we can move on to add the package to the configuration.
Cheers, Doru
On Apr 18, 2013, at 7:12 AM, Tudor Girba tudor@tudorgirba.com wrote:
Hi Dennis,
Excellent news :). I will try to take a bit of time to look into it.
Just please let's have these discussions over the mailing list because others might get interested as well. In case you think that you would waste other people's time, HierarchicalGraphs is now part of the 5.0 Roadmap :)
Cheers, Doru
p.s. and please use tudor@tudorgirba.com
On Apr 17, 2013, at 2:24 PM, Dennis Schenk d.schenk@students.unibe.ch wrote:
Hi Doru,
I moved the Quicksilver-Core to Moose-Algos-HierarchicalGraph and the tests to Moose-Tests-Algos-HierarchicalGraph. I also renamed the classes. Could you take a look and see if everything looks good from your point of view?
I did not touch ConfigurationOfMooseAlgos so far as I am not sure to which version the packages should be added. I assume 2.4? But did not see a version for this.
I guess one of the next steps should be to look how we can further merge the code bases, e.g. using classes like MalGraphNode and MalGraphEdge as parents of MalHgNode and MalHgEdge. I also made some utilities which I can guess are already implemented somewhere, like a linear equation generator. If you have some ideas there, or would like to code on this as well, tell me.
Cheers, Dennis
-- www.tudorgirba.com
"One cannot do more than one can do."
-- www.tudorgirba.com
"Sometimes the best solution is not the best solution."
Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev
-- www.tudorgirba.com
"Be rather willing to give than demanding to get."
-- 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."
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
-
Alexandre Bergel -
Dennis Schenk -
Tudor Girba