Several strange behavior in Roassal on a fresh moose 7.1 image (the
behavior with moose 6.1).
The following script tries to show classes within their packages, with
color according to their numberOfLinesOfCode:
|model v|
model := MooseModel root allModels last.
v := RTMondrian new.
v shape rectangle.
v nodes: (model allModelNamespaces)
   forEach: [ :p |
      v shape rectangle.
      v nodes: p types.
      v normalizer
         normalizeColor: #numberOfLinesOfCode
         using: {Color white . Color black}
         min: 0
         max: 1000.
      v layout grid.
   ].
v layout grid.
v
The result is that package color changes, not class color:
Now let's add the name of the packages (same script but for the 4th line):
|model v|
model := MooseModel root allModels last.
v := RTMondrian new.
v shape rectangle withTextAbove: #mooseName.
v nodes: (model allModelNamespaces)
   forEach: [ :p |
      v shape rectangle.
      v nodes: p types.
      v normalizer
         normalizeColor: #numberOfLinesOfCode
         using: {Color white . Color black}
         min: 0
         max: 1000.
      v layout grid.
   ].
v layout grid.
v
The result is that packages are not colored anymore but package names are :
So the question is:
What's wrong ?
How to have package with text above in black and color of inner class
depending on their numberOfLinesOfCode ?
thanks
nicolas
--
Nicolas Anquetil
RMod team -- Inria Lille
Hi,
The current Moose build from https://ci.inria.fr/moose/job/moose-6.1 no
longer works and there is the following error when creating a Famix model:
- "AssertionFailure: Link to opposite links should be a bijective
operation... Please check your model!"
This is caused by `FAMIX.BehaviouralReference.pointed` and
`FAMIX.BehaviouralReference.referer` that point to attributes
in FAMIXBehaviouralEntity that are not there.
They were added by Famix-CPlusPlus that is now loaded
by ConfigurationOfFamix.
Are there some commits missing that add the missing functionality to
FAMIXBehaviouralEntity?
Or should we remove for now `Famix-CPlusPlus` from ConfigurationOfFamix?
Cheers,
Andrei
Dear Smalltalk community,
My current contract at Lam Research is ending soon, I am looking for job opportunities starting in January 2019.
Last year, I finished my Ph.D. in Testing and Software Quality in the Inria's Rmod team in France.
I have been working with Pharo for five years and Visual Works for one year.
I am also experienced in creating tools to improve the efficiency of the developers.
Here are my website: https://vincentblondeau.github.io/
my LinkedIn: https://www.linkedin.com/in/vincent-blondeau/
and my GitHub: https://github.com/VincentBlondeau/
You can find my resume as an attachment.
I look forward to hearing from you.
Best Regards,
Vincent Blondeau
Thanx Alex :)
Looking forward to the Roassal talk on Thursday !
On Fri, Sep 7, 2018 at 5:22 PM Alexandre Bergel via Pharo-users <
pharo-users(a)lists.pharo.org> wrote:
> Wow!!!!!
> You guys rock!
>
> Alexandre
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
> On Sep 6, 2018, at 2:17 PM, Nick Papoylias <npapoylias(a)gmail.com> wrote:
>
> A nice example of how Pharo can be used for
> domain-specific modeling and simulation. Short
> session from one of our projects at Rochelle:
>
> https://www.youtube.com/watch?v=Z7wJNhAIaVQ
>
> Some additional info here: https://goo.gl/jS4NjB
>
> Currently investigating how to incorporate the new Bloc based
> widgets of @feenkcom into the workflow.
>
> Cheers,
>
> Nick
> _______________________________________________
> Moose-dev mailing list
> Moose-dev(a)list.inf.unibe.ch
> https://www.list.inf.unibe.ch/listinfo/moose-dev
>
>
>
A nice example of how Pharo can be used for
domain-specific modeling and simulation. Short
session from one of our projects at Rochelle:
https://www.youtube.com/watch?v=Z7wJNhAIaVQ
Some additional info here: https://goo.gl/jS4NjB
Currently investigating how to incorporate the new Bloc based
widgets of @feenkcom into the workflow.
Cheers,
Nick
Hi,
When connecting two composite shapes with RTEdgeBuilder, the connector
position loose its center over the connecting shapes.
It's easier to explain with two scripts:
This one looks good, the connector (RTArrowedLine) is centered:
| view shapes myElems |
view := RTView new.
myElems := 1 to: 2.
shapes := (RTSVGPath new
path: 'm 3.96875,9.2604167 h 31.75 V 25.135417 C 22.489583,23.8125
17.197917,34.395833 3.96875,27.78125 Z';
fillColor: Color red;
borderColor: Color black;
borderWidth: 1.2;
scale: 1.4) elementsOn: myElems.
view addAll: shapes.
RTEdgeBuilder new
view: view;
shape: (RTArrowedLine new
color: Color white;
yourself);
elements: shapes;
connectFrom: 1 to: 2.
RTTreeLayout new
verticalGap: 30;
horizontalGap: 30;
applyOn: shapes.
view inspect.
However when adding a label in a composite, both label and arrow looks shifted:
| view shape shapes myElems |
view := RTView new.
myElems := 1 to: 2.
shape := RTCompositeShape new
add: (RTLabel new text: 'Test');
add: (RTSVGPath new
path: 'm 3.96875,9.2604167 h 31.75 V 25.135417 C
22.489583,23.8125 17.197917,34.395833 3.96875,27.78125 Z';
fillColor: Color red;
borderColor: Color black;
borderWidth: 1.2;
scale: 1.4);
vertical;
yourself.
shapes := shape elementsOn: myElems.
view addAll: shapes.
RTEdgeBuilder new
view: view;
shape: (RTArrowedLine new
color: Color white;
yourself);
elements: shapes;
connectFrom: 1 to: 2.
RTTreeLayout new
verticalGap: 30;
horizontalGap: 30;
applyOn: shapes.
view inspect.
Any idea how to align these shapes?
Cheers,
Hernán
Hi,
In old FAMIX, the FAMIXAnnotationInstance defines two containers:
- annotatedEntity
- annotationType
The annotatedEntity is used for belongsTo, but I would like to know
why annotationType
was defined as container too. Does it has some reason?
Cheers,
-- Pavel
