Hi all,
see: http://www.rosuda.org/Mondrian/
Not exactly as powerful but a clash of names nonetheless ...
Regards
Thomas
--
mailto thomas j schrader at web de
____________________________________________________________________
Psssst! Schon vom neuen WEB.DE MultiMessenger gehört?
Der kann`s mit allen: http://www.produkte.web.de/messenger/?did=3123
Dear SqMoose friends,
i was wondering whether Moose-All is necessary since we have
MooseLoader.
The dependencies defined on Moose-All could be made explicit said in
MooseLoader.
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi All,
Am i the only one to notice the very long time taken by Moose to load?
I do not understand how it could be so long... I have a "Writing
definitions" for almost 10 minutes...
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi
I'm trying to load a mse file into VW Moose without using the GUI.
Below is my best shot right now: it doesnt fail but the created model
is empty. I guess that "MooseImporter withActiveMetamodel" is too
optimistic.
Anyway, before I dive once again into the peculiarities of VW, what is
the straightforward way to do that? I couldnt find the right API in
Moose.
model := MooseModel new name: (fileName asFilename tail removeSuffix:
'.mse').
self halt.
loader := MooseImporter withActiveMetamodel.
loader stream: fileName asFilename readStream.
result := loader asTask run.
loader resolveDanglingReferences.
model addEntity: result
--
Simon
Hi
I wanted to merge the change made by veronicas and when I use the
merge tool
and apply resolution I get a DNU.... (I will not comment).
So doru how do you do that normally?
Stef
Hi Alex,
I guess this mail was supposed to go to moose-dev, too :).
> I was wondering why is there a method originFor: in FormsBuilder. In
> VW there is none. Why the builder should know about the bounds of the
> element to display? I always though the shape was in charge of it.
The method's name is wrong. The *For: methods take a Figure as an
argument.
In our case it should be originOf: because it computes the origin of a
shape inside the context of the form.
> Something else, both in Squeak and VW we have the following method:
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> FormsBuilder>>at: aX and: aY
> "Utility method that makes other methods easier to read."
>
> ^self components
> select: [:component | component gridX = aX and: [component gridY =
> aY]]
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>
> Is there a reason to not store the components in a matrix ? One reason
> that I see, is that one could have a large compound contains only few
> elements in it. But still, I find that strange.
You could store it in a matrix.
Cheers,
Doru
> Cheers,
> Alexandre
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project(a)lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
--
www.tudorgirba.com
"Problem solving should be concentrated on describing
the problem in a way that is relevant for the solution."
Hi Alex,
I guess this mail was supposed to go to moose-dev :).
> I was wondering what the best strategy to implement a DSM will be. I
> see two different strategies:
> 1 - Building the matrix with a formsBuilder. Each shape contained in
> the builder is therefore a cell of the DSM.
> 2 - Having an MONode for each cell.
>
> I would favor option 2, but a special layout need to be defined right?
In VW, you can already do that through "formsBuilder asLayout". I used
this to build an evolution matrix that can be align nicely both
vertically and horizontally.
> Doru, you said once that Mondrian may not be adapted to build DSM. I
> do not understand (or even feel) why. May you comment on this?
You can, but it won't be optimal. The reason is that for any
significantly sized matrix you will not want to represent each cell as
an object, but rather treat the complete matrix as one smart object
that optimizes the display.
Cheers,
Doru
> Cheers,
> Alexandre
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
--
www.tudorgirba.com
"Beauty is where we see it."
I was looking at the pragma processor in SqMoose and noticed that
there is a subclass of FMPragmaProcessor called MSEPragmaProcessor.
Now this class does nothing except override one method from
FMPragmaProcessor, which is almost a copy-paste of its overridden
method. The only difference between the two methods is that one have
an early abort condition while the other continues even if the
condition is met.
Now MSEPragmaProcessor is packaged in Moose-Finder (and is used by
mooseDescription). I wonder what is the intent behind this class?
--
Simon
Dear friends,
I am now sitting in a room in which people are doing demos of their
software. A team does some sensor wireless networks, and they have a
fancy animation looping on a screen. Some of us are doing
visualization (including me, even if I am a newbie), I think we should
be able to produce some eye-catching animations.
Maybe something can be done around code city. A .mov will be welcomed...
I will work on something in the near future, as soon as I have time.
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Dear List,
The MOViewRenderer contains a list of layers (instances of MOLayer).
Is there a particular use for layers? what was the idea behind?
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
