Hi
Wanted to have likkle fun, so I tried something with like a
laggered tree, I saw that someone asked for it.
Not committed yet, but
in a near morrow, still have crossing problems even with Bezier curves
because all the nodes of the same line do not have the same y.
Regards
Mathieu
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(a)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(a)tudorgirba.com
>
> On Apr 17, 2013, at 2:24 PM, Dennis Schenk <d.schenk(a)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."
See <https://ci.inria.fr/moose/job/moose-latest-dev-4.8/372/>
------------------------------------------
[URLTrigger] A change within the response URL invocation (log)
Building remotely on moose-slave in workspace <https://ci.inria.fr/moose/job/moose-latest-dev-4.8/ws/>
Deleting project workspace... done
[moose-latest-dev-4.8] $ /bin/sh -xe /tmp/hudson935403054952537838.sh
+ bash
+ wget --quiet -O - http://get.pharo.org/20+vmLatest
+ ./pharo Pharo.image save moose-latest-dev-4.8
/tmp/hudson935403054952537838.sh: 4: /tmp/hudson935403054952537838.sh: ./pharo: not found
Build step 'Execute shell' marked build as failure
Archiving artifacts
Recording test results
Mathieu wrote:
>Wanted to have likkle fun, so I tried something with like a
>laggered tree, I saw that someone asked for it.
Yes, that was me.
>Not committed yet, but
>in a near morrow, still have crossing problems even with Bezier curves
>because all the nodes of the same line do not have the same y.
Nice! The result has a much better height-to-width than the simple
layout. I never said it was trivial :) Getting rid of the crossing problem
would probably take one of the chip- or pcb-layout algorithms.
Stephan Eggermont
Hi everyone. Let's say that I'm prototyping some model. Is there some tool to
show it's structure like moose meta browser does? I mean, you can use moose
meta browser, but what if you want to visualize my model alone? And what if
I want to refine the visualization?
--
View this message in context: http://moose-dev.97923.n3.nabble.com/Visualization-of-language-tp4027132.ht…
Sent from the moose-dev mailing list archive at Nabble.com.
Hi,
As you might know we have a couple of dedicated editors for:
- Glamour
- Roassal
- EyeSee, and
- Mondrian
Until now, if you had certain errors in the code, the whole editor would be rendered useless. I finally fixed this, and now the editors should be robust: if you have an error in the code (for example, syntax problem), you get a default rendering that exhibits the problem (see attachments).
If you happen to find any other problems with the editors, please let me know.
Cheers,
Doru
--
www.tudorgirba.com
"Every thing should have the right to be different."
Hi,
I would like to start a project to redesign the Moose webpage:
http://www.moosetechnology.org/news/call-for-help-webpage-redesign
(you can tweet this :))
The initial goals of the redesign are:
• redesign the first page to make the message clear: Crafting analyses made easy;
• provide a get started set of pages;
• provide a structure for documentation;
• provide a better space for sub projects.
Would anyone be interested in joining the effort?
Cheers,
Doru
--
www.tudorgirba.com
"To lead is not to demand things, it is to make them happen."
Hi all,
I am not fully done testing, but so far looking good, so here I share how far I am:
> Version 0.4 is tested in Moose 4.8. I loaded it in Pharo 2.0 and got an error while loading Seaside Tests. Only the tests depend on this project, so this should be ok. Maybe the tests even run, when you proceed on the warning.
> Important note: the configuration of Seaside30 comes from Seaside30 repository instead of the MetacelloRepository on squeak source. So you need to load this configuration manually before loading GlamourSeaside.
After manually loading configuration of GlamourSeaside and Seaside30 the following should load this project:
(ConfigurationOfGlamourSeaside project version: '0.4') load: 'Examples'
After that you should of course start the server by:
ZnZincServerAdaptor startOn: 8080
Cheers
Hi,
I did a little experiment to check the performance of Rubric when dealing with large content. And by large, I mean 45 MB or about 15 million lines of text.
I opened the file in several other editors:
- TextMate: 10s + the text is wrapped and can be browsed smoothly
- Sublime Text 2: 10s + the text is wrapped and can be browsed smoothly
- Eclipse: 5s + browsing is very slow (so it is basically useless)
How did Rubric perform:
- When opened with unwrapped lines: 33s + the text can be browsed smoothly
- When opened with wrapped lines -> Pharo crashed :(
In any case, I think being 3 times slower (even if without wrapping) than TextMate is highly exciting. Great job Alain.
If you want to reproduce the experiment, here is the Smalltalk snippet I used:
---
Gofer new
smalltalkhubUser: 'AlainPlantec' project: 'Rubric';
package: 'Rubric-AlainPlantec.26';
load.
[
contents := ((FileSystem disk workingDirectory / 'src' / 'ArgoUML-0-34' / 'output.mse') readStreamDo: #contents).
(RubLipsumBasicExample
windowWithScrolledText: (
RubLipsumBasicExample new
string: contents;
newScrolledTextNotWrapped))
openInWorld
] timeToRun
---
Cheers,
Doru
--
www.tudorgirba.com
"What we can governs what we wish."
Hi
I've refactored bezier curves, now there's just one class
ROBezierCurve, and when you call for it you can tell if you want either
a radial drawing or an orthoHorizontal or vertical.
Just write: +
ROBezierCurve radial or + ROBezierCurve orthoVertical...
And I've
dowloaded the up to date version of Roassal, it seems there are bugs in
populatemenu: on: and in ROFixedSizeParent.
Regards
Mathieu