Moose-dev May 2012

moose-dev@list.inf.unibe.ch

21 participants
109 discussions

by Alexandre Bergel

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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

12 years, 12 months

Issue 785 in moose-technology: inFamix don't export FAMIXLocalVariable>>parentBehaviouralEntity

by moose-technology＠googlecode.com

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.

13 years

the owner of mondrian edges

by Tudor Girba

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."

13 years

Jenkins build is still unstable: moose-latest-dev #960

by admin＠moosetechnology.org

See <http://hudson.moosetechnology.org/job/moose-latest-dev/960/>

13 years

AbstractDistributionMap >> defaultTitleFormattingBlock looks wrong

by Mariano Martinez Peck

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

13 years

New release of FuelMooseExtension

by Mariano Martinez Peck

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

13 years

Issue 501 in moose-technology: Cache independence

by moose-technology＠googlecode.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!

13 years

Issue 503 in moose-technology: Abstract classes and Hapao

by moose-technology＠googlecode.com

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

13 years

Issue 794 in moose-technology: More robust dynamicActions in MooseFinder

by moose-technology＠googlecode.com

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

13 years

Issue 601 in moose-technology: Covered methods and tests

by moose-technology＠googlecode.com

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

13 years

← Newer
1
...
4
5
6
7
8
9
10
11
Older →

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev May 2012