Hi,
I have a problem with FuelMoose:
- I have an MSE produced by VerveineJ.
- Import it into Moose 4.7
- I export it with FuelMoose
- But, after I import it back I get a DNU from the model. The reason
seems to be that FuelMoose provides a property value (e.g., a method
signature) to the wrong property slot (e.g., the package reference).
- I do not know if it's relevant, but I do this on Windows 7
Originally, I suspected that somehow Fame messes up properties, but I
tried to export and load the same model using the MSE mechanism and
that works properly.
So, I would need help. If someone has time to look into this, I can
provide the model privately.
Cheers,
Doru
--
www.tudorgirba.com
"Every thing has its own flow"
For a long time I have had the code below linking Magritte-Roassal.
Originally I had expected ":view" to hold aROView, and it was a surprise
when I found out held aROMondrianViewBuilder instead.
While it makes sense to have had a drop in replacement for the
Magritte-Mondrian, and it is simple to get the ROView from the
ROMondrianBuilder, it feels inelegant to have to do this each time.
---
browser transmit
from: #pane1
to: #pane2
andShow:
[ :a |
a roassal
title: 'Instance Model Full View';
painting:
[ :view :selection | | rawView |
rawView := view raw.
...etc...
]
].
---
Looking in from outside and considering long term broadening use of
Roassal outside of Mondrian, it would "feel" better if ...
andShow: [ :a | a roassal....
passed aROView as a parameter to #painting, and the Mondrian drop-in
replacement to be something like ...
andShow: [ :a | a roassalMondrian
andShow: [ :a | a roMondrian
andShow: [ :a | a mondrianBuilder
which passed aROMondrianBuilder.
cheers -ben
I was wanting to better understand how to edges are handled in Roassal
and I modified ROElementTest>>testMostSpecificParentCommonWith: as
follows to get a visual of how it works....
-----
| el1 el11 el111 el12 el2 el21 view |
view := ROView new.
el1 := (ROElement spriteOn: 1) + ROLabel.
el11 := (ROElement spriteOn: 11) + ROLabel.
el111 := (ROElement spriteOn: 111) + ROLabel.
el12 := (ROElement spriteOn: 12) + ROLabel.
el2 := (ROElement spriteOn: 2) + ROLabel.
el21 := (ROElement spriteOn: 21) + ROLabel.
el1 add: el11; add: el12.
el11 add: el111.
el2 add: el21.
view add: el1; add: el2.
ROGridLayout on: el11 elements.
ROGridLayout on: el1 elements.
ROGridLayout on: el2 elements.
ROGridLayout on: view elements.
self assert: (el1 mostSpecificParentCommonWith: el2) == view.
self assert: (el1 mostSpecificParentCommonWith: el21) == view.
self assert: (el1 mostSpecificParentCommonWith: el11) == view.
self assert: (el12 mostSpecificParentCommonWith: el111) == el1.
self assert: (el11 mostSpecificParentCommonWith: el111) == el11.
"added by ben coman"
view open.
---
I casually added the last assert and the presumed answer, but the
failure which resulted surprised me. Now I'm actually not sure what the
result should be, or even whether it makes sense for an edge to be
defined between a node and its subnode. I'd be interested in your thoughts.
cheers -ben
Alexandre wrote:
>Doru told me that there is a Monticello importer in VisualWorks, but I haven't tried it.
I have. Not so easy to make work. There is a screencast, but it avoids the difficult
parts.
Stephan
Hi Alexandre,
That looks good. I ran into some trouble when trying this with multiple packages.
The VW5PackageExporter is very specialized for Seaside. If it notices classes
starting with WA or with a superclass starting with WA it adds Seaside to to the
imports, and uses a hack on Behavior to add Seaside.
visualworksName
^ (#('WA' 'SU' 'CT') includes: (self name copyFrom: 1 to: 2))
ifTrue: ['Seaside.', self name]
ifFalse: [self name]
I was able to work around that.
Stephan
Hi Alex,
I have already planned to migrate my tools to use Roassal...
But for now I have to use what we have with Mondrian because we are preparing an evaluation on our tool in Pharo1.4.
I suddenly have a problem that I do not know to detect
I draw a map with dominanceTreeLayout or forcedBaseLayout.
When the layout is dominanceTreeLayout I am getting the red rectangle with the cross. Sometimes i get it immediately or sometimes I see part of the visualization and when i move the scrollbars the red rectangle appears.
How can I debug that?, I haven't changed my code and I have no idea what is failing now
if I open the same visualization with forcedBaseLayout it works fine.
Regards,
Veronica
Hi,
The code for Roassal works on both vw and Pharo. How is that maintained?
Is one version leading, and the other derived from that? I noticed that the VW
version has a different package structure (much more flat), and classes have the
RO prefix. Or are changes simply performed twice? Or is Roassal an early user
of the github based approach advocated by Dale?
Stephan
>If anybody as a clue on what's happening ... ?
Sounds like #newline asParser already matches on cr, and then
has a remaining character lf.
PPJavaLexicon>lineTerminator
^ (Character lf asParser) / (Character cr asParser , (Character lf asParser ) optional )
Stephan
Trying to parse the 3 possible ends of line: Linux=lf ; MacOS=cr;
Windows=crlf
given the rule:
newline
^ #newline asParser / (#cr asParser , #newline asParser optional)
The linux and MacOs tests pass
testNewline1
^self parse: String lf rule: #newline.
testNewline2
^self parse: String cr rule: #newline.
But the windows one fails !?!?!?!
testNewline3
^self parse: String crlf rule: #newline.
Any clue why?
nicolas
Hi all,
I am trying to place a label besides nodes (and make them stick at their
place when dragging them around). Then I saw the ongoing discussion related
to RoTranslatingShape, which seems is exactly what I would need. I looked
at all the examples and the discussion, but am not able to make it work
correctly.
What I would want is to create some node, then have a label right at its
bottom left side (or top left, or bottom right). The node is not resizable
(and its contents, or children, do not change), so that should not be a
problem.
What I would like to do is simply something like in this image:
http://cl.ly/image/3c1e1s15433Q.
The difference to the other examples is probably that I already have a node
in the view, and then I try to attach the label afterwards.
So I have something like this:
*testNodeLabeling*
* | view rawView nodes node label |*
* rawView := ROView new.*
* view := ROMondrianViewBuilder view: rawView. *
* view shape rectangle size: 100.*
* nodes := view nodes: (Array with: 1).*
* node := nodes at: 1.*
* node translateTo: 20@20. *
* label := (ROElement on: 'test') + (ROTranslatingShape new offset:
0 @ 20 negated) + ROLabel.*
* rawView add: label.*
* view noLayout.*
* view open.*
How would I now 'attach' this label to the node?
Or is this the wrong way to go on about this?
Cheers,
Dennis
I was trying to apply ROTranslatingShape to produce a label sitting
above the children nodes. To understand it better how to get what I
need, I made ROExample>>nestingTranslate to show a permutation of the
order the shapes can be applied. I have attached a screen snapshot
and fileout for this. The case I am particularly interested in is el3.
The 'el0' case is the reference without any ROTranslatingShape.
When running the example hover near and over the inner elements to
view the misalignment of the mouse hotspot. I have marked the
approximate offset in green in the snapshot.
I notice that the existing call chain goes...
ROView>>localElementAt:
ROElement>>elementAt:
ROElement>>contains:
ROElemenet>>bounds
ROShape>>extentFor: (union of extent of each shape)
It seems to me the hotspot misalignment is related to the translation
being applied at the shape draw level whereas the #contains: checking
is done at the element level. This relies on the union of the shape
extents to set the element bounds, but I can't see how that extent union
could be modified to account for the translation - particular in the
case of a negative translation since extents throw away information
about any negative offset.
So I thought perhaps that the element #contains: checking needs
might be better chained through the shaped, so that the translation
could be applied similar to ROTranslatingShape>>chainedDrawOn:for:
and that this would not cause any/much additional computation
since all the shapes were being cycled through anyway for #extentFor:
Something like...
ROView>>localElementAt:
ROElement>>elementAt:
ROElement>>contains:
ROShape>>chainedContains:For: (for each shape)
cheers, Ben
'From Pharo1.4 of 18 April 2012 [Latest update: #14457] on 22 September 2012 at 9:41:20 pm'!
!ROExample methodsFor: 'nesting' stamp: 'BenComan 9/22/2012 17:04'!
nestingTranslate
"
self new nestingTranslate
"
| rawView outer el0 el1 el2 el3 el4 el5 el6 el7 el8 |
rawView := ROView new @ RODraggable.
el0 := (ROElement on:
'el0,
border,
label') + ROBorder + ROLabel @ RODraggable @ ROLightlyHighlightable.
el0 extent: 50@50.
1 to: 4 do: [ :n | el0 add: (ROElement spriteOn: n) @ ROLightlyHighlightable ].
ROGridLayout on: el0 elements .
el1 := (ROElement on:
'el1,
border,
positive translation,
label') + ROBorder + (ROTranslatingShape new offset: 0 @ 20) + ROLabel @ RODraggable @ ROLightlyHighlightable.
el1 extent: 50@50.
1 to: 4 do: [ :n | el1 add: (ROElement spriteOn: n) @ ROLightlyHighlightable ].
ROGridLayout on: el1 elements .
el2 := (ROElement on:
'el2,
border,
label,
positive translation') + ROBorder + ROLabel + (ROTranslatingShape new offset: 0 @ 20) @ RODraggable @ ROLightlyHighlightable.
el2 extent: 50@50.
1 to: 4 do: [ :n | el2 add: (ROElement spriteOn: n) @ ROLightlyHighlightable ].
ROGridLayout on: el2 elements .
el3 := (ROElement on:
'el3,
border,
negative translation,
label') + ROBorder + (ROTranslatingShape new offset: 0 @ 20 negated) + ROLabel @ RODraggable @ ROLightlyHighlightable.
el3 extent: 50@50.
1 to: 4 do: [ :n | el3 add: (ROElement spriteOn: n) @ ROLightlyHighlightable ].
ROGridLayout on: el3 elements .
el4 := (ROElement on:
'el4,
border,
label,
negative translation') + ROBorder + ROLabel + (ROTranslatingShape new offset: 0 @ 20 negated) @ RODraggable @ ROLightlyHighlightable.
el4 extent: 50@50.
1 to: 4 do: [ :n | el4 add: (ROElement spriteOn: n) @ ROLightlyHighlightable ].
ROGridLayout on: el4 elements .
el5 := (ROElement on:
'el5,
positive translation,
label,
border') + (ROTranslatingShape new offset: 0 @ 20) + ROLabel + ROBorder @ RODraggable @ ROLightlyHighlightable.
el5 extent: 50@50.
1 to: 4 do: [ :n | el5 add: (ROElement spriteOn: n) @ ROLightlyHighlightable ].
ROGridLayout on: el5 elements .
el6 := (ROElement on:
'el6,
label,
positive translation,
border,') + ROLabel + (ROTranslatingShape new offset: 0 @ 20) + ROBorder @ RODraggable @ ROLightlyHighlightable.
el6 extent: 50@50.
1 to: 4 do: [ :n | el6 add: (ROElement spriteOn: n) @ ROLightlyHighlightable ].
ROGridLayout on: el6 elements .
el7 := (ROElement on:
'el7,
negative translation,
label,
border') + (ROTranslatingShape new offset: 0 @ 20 negated) + ROLabel + ROBorder @ RODraggable @ ROLightlyHighlightable.
el7 extent: 50@50.
1 to: 4 do: [ :n | el7 add: (ROElement spriteOn: n) @ ROLightlyHighlightable ].
ROGridLayout on: el7 elements .
el8 := (ROElement on:
'el8,
label,
negative translation,
border') + ROLabel + (ROTranslatingShape new offset: 0 @ 20 negated) + ROBorder @ RODraggable @ ROLightlyHighlightable.
el8 extent: 50@50.
1 to: 4 do: [ :n | el8 add: (ROElement spriteOn: n) @ ROLightlyHighlightable ].
ROGridLayout on: el8 elements .
outer := (ROElement spriteOn: 'outer') addAll: { el0. el1. el2. el3. el4. el5. el6. el7. el8 }.
rawView add: outer.
ROHorizontalLineLayout on: outer elements.
rawView open ! !
Hi everybody,
I'm currently trying to parse a Delphi project into an .mse model so
that I can import it into Moose.
So far I have found "Petit Delphi":
http://ss3.gemstone.com/ss/PetitDelphi.html/Overview
I managed to add the Monticello Repository and I can now see the
"PPDelphiAssemblyParser" and "PPDelpiLexicon" when I open the Tools ->
PetitParser GUI.
But now I'm a bit stuck - how can I create an .mse file out of the
Delphi files on my disk now?
It seems now that I have the parser I don't know how to use it...
P.S.: the whole Smalltalk and Pharo environment is totally new to me,
so please forgive the beginner questions :-)
Thank you very much and best regards,
Torben
Status: New
Owner: tu...(a)tudorgirba.com
Labels: Type-Enhancement Priority-Medium Component-Finder Milestone-4.7
New issue 844 by tu...(a)tudorgirba.com: Moose Finder should let one browse
the implementing method of a navigation item
http://code.google.com/p/moose-technology/issues/detail?id=844
When browsing one entity, the first tab shows the navigation items from
this entity. Especially for newbies it is important to see how these
navigation methods are implemented.
Thus, the contextual menu should offer the possibility to browse the
corresponding methods.
For example, when browsing a class, selecting the invoked methods should
offer a menu item that opens a browser on FAMIXType>>invokedMethods.
Hello,
How to we add horizontal and vertical scroll bars to a Roassal
visualization. I browsed through some examples but could not find one with
these.
tx.
usman
Hi all,
I'd like to customize lines with arrows a little bit more than seems to be
possible out of the box at the moment and am looking for some pointers.
I have attached a screenshot to explain what I'd like to achieve.
I'd like to be able to:
1. Define a certain distance from the arrows beginning and end to the
objects they are attached to - so they are not directly 'glued' to the
objects.
2. Make lines wider, without just affecting the width of the line (and
in the same extend the line the arrow is made up), but instead it should
scale to nice looking arrows.
3. To place lines besides each other from and to the same object.
Are some of these points already possible but I missed them?
How would I best go on about modifying, extending Roassal to allow for edge
styling in this way?
Cheers,
Dennis
Just one more thing that has been playing on my mind. It is really a
nice feature that the parent element grows when the child is moved past
its boundary, but would be more good if it also shrank when the child
element is moved back towards center.
cheers ben
Guillermo wrote:
>Maybe you can use a -completely separate- pre-parser? :)
>
>It takes the input with the pre processor directives, and answers a new
>processed string which the original parser will handle?.
Yes, I guess so. I'm fighting a bit with PetitParser, wondering if the traditional
style of building parsers wouldn't be faster. But that might be just about trying
something new. I like the tests, the separate lexicon, syntax and semantics
subclassing not so much better than preprocessing, scanning, parsing.
I definitely don't like having 80 productions in a class (growing to 300, not
sure how to grow over the max nr of instVars ). Is there an array or dictionary
based PPCompositeParser?
Stephan
I have been looking at the ROExample "Nesting" examples and expanded
#nesting2 with another level as shown in the code below, such that there
is the outer view, middle "#1" nodes and inner "#2" nodes. However the
initial state of this has much of the middle node1 and inner node2 nodes
overlapping.
How can these be made for the circle layout to leave spacing between the
middle node1 nodes?
cheers -ben
--------------------
| view nodes1 |
view := ROView new.
view add: (ROElement sprite addAll: (nodes1 := ROElement spritesOn:
(1 to: 10))).
nodes1 do: [:n | n addShape: ROLabel].
nodes1 do:
[ :node1 |
( (node1 model) *100+1 to: (node1 model)*100+5 ) do:
[ :x |
node1 add: ( (ROElement spriteOn: x) addShape: ROLabel).
].
ROGridLayout on: node1 elements.
].
ROCircleLayout on: nodes1.
view openInWindow.