Hi!
The release of Roassal is now official. As you might have seen, Roassal is now distributed with Moose. The plan is to slowly replace Mondrian by Roassal. This may take some time, but we will reach the point that Mondrian can rest in peace.
Roassal remains largely compatible with Mondrian. The visualizations you have scripted with Mondrian should normally work with Roassal without too much pain.
Gofer new
squeaksource: 'Roassal';
package: 'ConfigurationOfRoassal';
load.
(Smalltalk at: #ConfigurationOfRoassal) project lastVersion load.
Having Roassal out implies that I will essentially focus on Roassal instead of Mondrian. Naturally, I will continue to incorporate important bug fixes in Mondrian. But as far I am concerned, no major enhancement of Mondrian is planned.
We learnt a lot with Mondrian. Roassal really goes one step further with better interactions, a clean low level if you wish to build your own domain specific language. To be short, Roassal is simpler and better.
I suggest people to enter bug fixes and requests for enhancement in the Moose google project as we are doing for Mondrian.
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 785 by fabrizio...(a)gmail.com: inFamix don't export
FAMIXLocalVariable>>parentBehaviouralEntity
http://code.google.com/p/moose-technology/issues/detail?id=785
FAMIXLocalVariable entities exported with inFamix are not associated with
the behavioural entity they are belong to.
Hi Fabrizio.
Thanks for helping me reproduce the problem.
It should be fixed now.
However, there are still some red tests because they assume the old wrong behavior of assigning edges to an owner node.
Cheers,
Doru
On 26 May 2012, at 15:28, Fabrizio Perin wrote:
> Hi Doru,
> Here is the code you were working on:
>
> view := MOViewRenderer new.
> view nodes: #(2) forEach: [:each |
> view shape label.
> view node: each* 10.
> view shape label.
> view node: (each * 10 + 1).
> view treeLayout.
> ].
> view edgesFromAssociations: {"10->20. 10 -> 11 ." 20->21}.
> view open.
>
> Cheers,
> Fabrizio
--
www.tudorgirba.com
"It's not what we do that matters most, it's how we do it."
AbstractDistributionMap >> defaultTitleFormattingBlock
^ [ :each |
| t |
t := each.
(t beginsWith: 'Citezen-')
ifTrue: [ t := t copyReplaceAll: 'Citezen-' with: 'C' ].
(t beginsWith: 'Seaside-')
ifTrue: [ t := t copyReplaceAll: 'Seaside-' with: 'S' ].
t := t copyReplaceAll: 'Tests-' with: 'T-'.
"t := (Kontract reduce: t upTo: 10)."
t ]
On the one hand, it hardcodes stuff like Citizen or Seaside. But what is
worse is that that Kontract does not exist...
Cheers,
--
Mariano
http://marianopeck.wordpress.com
Hi Doru. I have updated FuelMooseExtension to work with the latest stable
version of Fuel 1.8. I think this is worth it because:
1) Right now you are using an old version of Fuel (1.6) which is like an
year ago. The older it is the more difficult it will be in the future to
update.
2) If you don't take into account the time to compute attributes we can
have improvement up to 30% in export time.
3) Fuel 1.8 is integrated by default in Pharo 2.0 now, meaning that you
will have problems when moving Moose to Pharo 2.0 (because you would need
1.6).
Of course the bad news is that if you have already exported files you won't
be able to import them with this new version.
If you agree, let me know. I will create a new version 1.5 in
ConfigurationOfFuelMooseExtension but I don't know how the Moose image is
built (it seems it is not using ConfigurationOfFuel).
Cheers
--
Mariano
http://marianopeck.wordpress.com
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 501 by alexandr...(a)gmail.com: Cache independence
http://code.google.com/p/moose-technology/issues/detail?id=501
The core of Mondrian is not independent of the cache implementation. The
logic of Mondrian rely on the cache to implement its semantics. This is
obviously wrong.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
bounds
"Answer the bounds of the receiver."
"the bounds is has an absolute origin"
"Note that the bounds computed above, may have (and it is likely to) a
different origin. The reason is that the layout is in charge to position
the nodes properly"
| basicBounds |
boundsCache ifNotNil: [ ^ boundsCache ].
"We check if the shape if present"
self shapeBoundsAt: self shape ifPresent: [ :b | ^ boundsCache := b ].
basicBounds := self shape computeBoundsFor: self.
self shapeBoundsAt: self shape put: basicBounds.
^ boundsCache := basicBounds
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
translateAbsoluteCacheBy: aPoint
absoluteBoundsCache ifNil: [ ^ self ].
absoluteBoundsCache := absoluteBoundsCache translateBy: aPoint
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Thanks to Santiago Vidal for pointing this out!
Status: New
Owner: ----
CC: vhane...(a)gmail.com
Labels: Type-Defect Priority-Medium Component-Spy
New issue 503 by alexandr...(a)gmail.com: Abstract classes and Hapao
http://code.google.com/p/moose-technology/issues/detail?id=503
Gaëtan le Brun suggested to remove abstract classes before running the test
in Hapao.
This makes sense
Status: Accepted
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 794 by usman.bh...(a)gmail.com: More robust dynamicActions in
MooseFinder
http://code.google.com/p/moose-technology/issues/detail?id=794
Doru
When we clicked (to bring the menu) in Moose Finder we got list entity
mooseInterestingEntity = to nil.
So for now we patched the method to
[ :list | list entity mooseInterestingEntity ifNotNil: [:entity| entity
mooseFinderActions ]].
buildBrowser
browser := GLMFinder new.
browser title: [:each | 'Moose Finder on ', each mooseInterestingEntity
mooseDisplayString].
browser show: [ :a |
a
title: [ :each |
(each mooseInterestingEntity mooseDisplayString contractTo: 30), ' (',
each mooseInterestingEntity class name, ')' ];
dynamicActions: [ :list | list entity mooseInterestingEntity ifNotNil:
[:entity| entity mooseFinderActions ]].
a dynamic
display: [:each |
| dynamic |
dynamic := GLMCompositePresentation new.
each mooseInterestingEntity mooseFinderPresentationsIn: dynamic.
dynamic ].
a updateOn: MooseEntityAdded from: [:each | each isNil ifFalse: [each
announcer] ifTrue: [nil] ].
a updateOn: MooseEntityRemoved from: [:each | each isNil ifFalse: [each
announcer] ifTrue: [nil] ].
a updateOn: MooseEntityRenamed from: [:each | each isNil ifFalse: [each
announcer] ifTrue: [nil] ]].
^ browser
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium Component-Hapao
New issue 601 by alexandr...(a)gmail.com: Covered methods and tests
http://code.google.com/p/moose-technology/issues/detail?id=601
It would be good to see what are the tests that _indirectly_ tests a
methods.
Thanks Laurent & Patrick