- Moose-dev - INF Mailman

by Tudor Girba

Hi, I would like to get Athens for Balloon loaded by default in a Moose image. The idea would be to make it easy for people to migrate to this interface, to make the code ready for Cairo. In the process of testing it, I noticed that the text examples do not work with StrikeFont. Please note that we are using Pharo 1.4. I tried it by doing the followings: Gofer new squeaksource: 'Athens'; package: 'ConfigurationOfAthens'; load. ((Smalltalk at: #ConfigurationOfAthens) project version: #development) load: 'Athens-Morphic'. And then: AthensTextRenderTest test1. The problem seems to be caused by a missing method: StrikeFont>>getPreciseAscent @Igor: Is this a missing method, or is it something else? Would it be difficult to fix this? Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow"

13 years, 1 month

2
1
0 0

A preprocessor for PetitParser

by Guillaume Larcheveque

Hi everybody, i am currently implementing a preProcessor which is a kind of PPParser, so you can combine it like any parser. At this moment, it is able to manage a simple transformation (a matched regular expression is replaced by a substitution string) and it release the stream in a correct state after his action (the remaining data are not preprocessed and the position is correct). Do you think i should release it directly in PetitParser or in another module? -- *Guillaume Larcheveque*

13 years, 1 month

2
1
0 0

Moose meta-model extension

by Andrea Caracciolo

Hi, I'm writing to this mailing list for the first time, so let me shortly introduce myself: I'm a PhD student at SCG (prof. O. Nierstrasz / University of Bern) and i'm currently working on architecture validation. I recently started a little project (a more flexible and generic version of moose chef), and since i wanted to display my output in moose i tried to build an extension to the moose meta-model. What i did was creating a new class named FAMIXLiftedAssociation which extends FAMIXAssociation and has a 'from' and to 'to' attribute. I defined the following methods: to <MSEProperty: #to type: #MooseEntity> <MSEComment: 'to-side of the association'> ^ to. from <MSEProperty: #from type: #MooseEntity> <MSEComment: 'from-side of the association'> ^ from where both 'from' and 'to' attributes are MooseEntity objects. On the class side i redefined: annotation <MSEClass: #FAMIXLiftedAssociation super: #FAMIXAssociation> <package: #FAMIX> ^self When i try to browse a group populated with instances of the above described class, i'm able to see them all correctly. But as soon as i click on one of them i get the following error: MessageNotUnderstood: receiver of "allPrimitiveAttributes" is nil I guess the new class has not been recognized as being part of the moose meta-model. Am i wrong ? Did i forget any pragma ? Andrea Caracciolo

13 years, 1 month

3
3
0 0

[ANN] Roassal 1.28

by Alexandre Bergel

Dear Fellow, A couple of weeks ago we have released the Roassal visualization engine. Many of you gave us feedback and we are deeply grateful for this. Since we released the first version, we have closed 25 issues [*]. Many things are left to do, especially to satisfy all the requirements from the Moose community. We are currently working on an HTML exporter for Roassal. We know this is a highly wanted feature. In a couple of weeks we should be able to deliver it. Since the first release of Roassal, we have worked very hard on it and we will continue to do so. Thanks to all of you! Alexandre, Vanessa, Juan Pablo [*] http://code.google.com/p/objectprofile/issues/list?can=1&q=status=Fixed%20c… -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

13 years, 1 month

3
3
0 0

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, 1 month

3
3
0 0

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, 1 month

5
55
0 0

displaced edges in the new version of Roassal

by Usman Bhatti

Hello, I am having trouble with the new version of Roassal (downloaded with latest moose version today), the edges are abnormally displaced (c.f: attached figure). Here is the script to generate the visu. |mainNode view title childNodes ab mainTitle| view := ROView new. mainNode := (ROElement spriteOn: 'A Test Node') + ROBorder. mainTitle := (ROLabelElement on: 'A Test Node') textColor: Color gray. ab := Array with: 'Moose' with: 'Mondrian' with: 'Glamour'. childNodes := OrderedCollection new. ab do: [:each | element := ((ROElement spriteOn: each) + ROBorder). title := (ROLabelElement on: each) textColor: Color red. box := ROBox new color: Color transparent. element addInteraction: RODraggable. ('Mondrian' matches: each) ifTrue: [box color: Color lightBlue]. ('Glamour' matches: each) ifTrue: [box color: Color blue]. element add: title; addShape: box. childNodes add: element. ]. view add: (ROEdge arrowedLineFrom: childNodes first to: childNodes second) + ROLine blue. view add: (ROEdge arrowedLineFrom: childNodes first to: childNodes third) + ROLine blue. view add: (ROEdge arrowedLineFrom: childNodes second to: childNodes third) + ROLine blue. mainNode addAll: (ROGridLayout on: childNodes). view addAll: (ROVerticalLineLayout on: (Array with: mainTitle with: mainNode)). view open Should I open a bug entry? thanx Usman [image: Inline image 1]

13 years, 1 month

2
2
0 0

filterOn: in glamour

by Usman Bhatti

Hello all, I am trying to understand the functionality of filterOn: method in GLMListingPresentation. I am not able trigger the block in glamour examples by typing the search criteria in the provided search box (c.f: multipleFinderWithFilter example). How do we trigger the filterOn: block so that the matching entities appear in the next pane of the example? What I am trying to achieve is to reduce the list of items in a tree with the criterion provided in the search box. Currently with the searchOn: block, I can select the matching entities in the tree, my idea is to remove the entities from the tree which do not fulfill the selection criterion. tx Usman

13 years, 1 month

2
3
0 0

graph of object references

by Tudor Girba

Hi, I would need to debug memory leaks (maybe induced by announcements), and for that I am thinking to use a graph of object references. I guess this would be easily possible with Fuel. If I have an object, how would I go about doing this? Cheers, Doru -- www.tudorgirba.com "Don't give to get. Just give."

13 years, 1 month

2
2
0 0

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, 1 month

3
4
0 0

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, 1 month

4
11
0 0

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, 1 month

1
2
0 0

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, 1 month

1
1
0 0

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, 1 month

1
3
0 0

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, 1 month

1
3
0 0

One more question about fame/famix entities and fuel exporter

by Mariano Martinez Peck

Hi guys. Right now, our extension to export Moose models does the following: accepts: anObject MooseModel meta descriptionOf: anObject class ifAbsent: [ ^ false ]. ^ true so....if an object is NOT found in the #descriptionOf: then we use the normal Fuel serialization. If it WAS found, then we do something like: FLFameCluster >> referencesOf: anObject do: aBlock self attributes do: [ :anAttribute | | values | values := anAttribute getFrom: anObject. (self shouldIgnore: anAttribute withAll: values) ifTrue: [ aBlock value: 0 ] ifFalse: [ aBlock value: values size. values do: [ :aValue | aBlock value: aValue ] ] ] and shouldIgnore: attribute withAll: values "Copied from FMRepositoryVisitor>>ignoreProperty:withAll:" ^ values isEmpty or: [ attribute isDerived or: [ attribute type == FM3MetaDescription boolean and: [ values size == 1 and: [ values first == false ]]]] so...basically we follow all attributes. Now...my question is (actually, Martin), instead of doing the "if" to see whether I should do that or the normal fuel procedure, instead of being MooseModel meta descriptionOf: anObject class ifAbsent: can be: "object kindOf: MooseEntity" ? would that be the same? in other words, all what is included in descriptionOf: are MooseEntities? all MooseEntities (whether they are included in descriptionOf: or not should be ne serialized that way? I ask because it would make the code much easier. thanks -- Mariano http://marianopeck.wordpress.com

13 years, 1 month

2
3
0 0

dsm with roassal errors

by Tudor Girba

Hi Alex, The DSM implementation using Roassal produces errors. You can replicate these using the MooseFinder tests. Would it be possible to take a look at these? Otherwise, we revert. Cheers, Doru -- www.tudorgirba.com "It's not how it is, it is how we see it."

13 years, 1 month

2
1
0 0

3 failing tests

by Alexandre Bergel

Hi! We have 3 failing tests. Just to let you know that I am investigating what's going wrong. The 3 failing tests stems from Nautilus. Something that I fixed some times ago, but apparently my changes haven't been merged by Ben. I am seeing this with him. Will let you know. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

13 years, 1 month

2
4
0 0

Issue 793 in moose-technology: TreePresentation does not show the selected item when rendering with Morphic

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium Component-Glamour Milestone-4.7 New issue 793 by tudor.gi...(a)gmail.com: TreePresentation does not show the selected item when rendering with Morphic http://code.google.com/p/moose-technology/issues/detail?id=793 You can reproduce the problem with the example found in: GLMBasicExamples>>treeWithInitialSelection " | browser | browser := self new treeWithInitialSelection. browser openOn: { #first->{$a->{}. $c->{}. $d->{}}. #second->{$e->{}. $f->{}}. #third->{$h->{}} }. (browser panes first port: #selection) value: (browser panes first port: #entity) value. " | browser | browser := GLMTabulator new. browser column: #one; column: [ :c | c row: #two; row: #three ]. (browser transmit) to: #one; andShow: [ :a | (a tree) title: 'first tree'; children: [ :x | x value ]. (a tree) title: 'second tree'; children: [ :x | x value ] ]. (browser transmit) to: #two; from: #one; andShow: [ :a | a text title: 'Selection preview' ]. (browser transmit) to: #three; from: #one port: #selectionPath; andShow: [ :a | a text title: 'Selection path preview' ]. ^ browser

13 years, 1 month

1
2
0 0

starting roassal

by Usman Bhatti

Today, I worked a bit on creating some visu with Roassal. It really a nice tool. I had a few problems though: Non-dsl mode relies on the user to handle the drawing details. For example, the code below creates a box whose text exceeds the box boundaries. For mondrian-infested people like me, this should be automatically managed. node := 'this is a long chain'. view := ROWhiteView new view title: 'TEST'. moduleNode := (ROElement spriteOn: node) + (ROLabel new color: Color red). view add: moduleNode. view open. [image: Inline image 2] I tried to switch to the DSL mode with ROMondrianViewBuilder in Glamour but I had MessageNotUnderstood: ROMondrianViewBuilder>>camera. Did someone have a similar problem? tx Usman

13 years, 1 month

2
4
0 0

Reviewing Fuel export/import utility

by Martin Dias

Hello, I'm looking to improve current implementation, and maybe you can help me. The current procedure is based in a custom serialization of each MooseElement. It's inspired on MSE, I describe this with the following pseudo-code: serialize: aMooseElement (MooseModel meta descriptionOf: aMooseElement class) allAttributes do: [ :anAttribute | | values | values := anAttribute getFrom: aMooseElement. (self shouldIgnore: anAttribute withAll: values) ifFalse: [ self serialize: anAttribute withAll: values ] ]. where: shouldIgnore: anAttribute withAll: values ^ values isEmpty or: [ anAttribute isDerived or: [ anAttribute type == FM3MetaDescription boolean and: [ values size == 1 and: [ values first == false ]]]] The advantage of serializing the MooseElements in this way (and not just as a normal object) is to avoid storing unnecessary stuff that aMooseElement references. It's a disadvantage using FM3PropertyDescription>>getFrom: (and then to import, FM3PropertyDescription>>setOn:values:) which ends sending #perform: of the corresponding accessor selector. It'd be better to use #instVarAt: (and #instVarAt:put:) as Fuel normally does. I hope I've been clear enough to explain up to this point. Now my question: Do you think Fuel can do something on each MooseElement like - clean up some unnecessary references - declare some instance variables as transient - if it's not good idea to modify the elements, create a method like MooseElement>>copyWithoutDerivedValues, and so actually serialize such copy instead of the original element - any other ??? and thus, serialize the MooseElements as normal Fuel objects, removing the custom procedure. I'll be happy to receive some help from Moose and Fame experts! Thanks in advance. Martín

13 years, 1 month

3
10
0 0

holistic assessment (recorded talk)

by Tudor Girba

Hi, Perhaps this talk might be of interest to some of you: http://www.humane-assessment.com/blog/holistic-software-assessment-research Cheers, Doru -- www.tudorgirba.com "What is more important: To be happy, or to make happy?"

13 years, 1 month

1
0
0 0

Issue 509 in moose-technology: Modularization Quality Metric

by moose-technology＠googlecode.com

Status: New Owner: andreho...(a)gmail.com Labels: Type-Enhancement Priority-Medium Component-Famix New issue 509 by andreho...(a)gmail.com: Modularization Quality Metric http://code.google.com/p/moose-technology/issues/detail?id=509 We implemented the Bunch metrics of coupling and cohesion as quality metrics for existing packages (FAMIXPackage) and namespaces (FAMIXNamespace). Now the idea is to implement the Modularization Quality Metric as a quality metric for existing group of packages (FAMIXPackageGroup) and namespaces (FAMIXNamespaceGroup). Pointer to the papers that propose the metrics: Using Automatic Clustering to Produce High-Level System Organizations of Source Code (http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=693283) Bunch: A Clustering Tool for the Recovery and Maintenance of Software System Structures (http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=792498)

13 years, 1 month

1
2
0 0

transparent taskbar

by Tudor Girba

Hi, I got the Pharo taskbar to be transparent in the latest GLMUITheme. Take a look at the screenshot. It is always surprising to see how less can be more also graphically, and not just in code :). We could use more effort going in this direction. Cheers, Doru -- www.tudorgirba.com "What we can governs what we wish."

13 years, 1 month

1
0
0 0

SimpleXO

by Ben Coman

Doru, I was looking around for some tools to implement importing an RDF defined model and came across SimpleXO where I saw your name pop up in discussion [1]. How did that pan out? cheers -benen [1] http://www.digipedia.pl/usenet/thread/14829/3359/

13 years, 1 month

4
3
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev