March 2012 - Moose-dev

Issue 650 in moose-technology: Mondrian multiple selection uses a broken metaphor
by moose-technology＠googlecode.com 14 Oct '12

14 Oct '12

Status: New Owner: ---- CC: alexandr...(a)gmail.com Labels: Type-Defect Priority-Medium Component-Mondrian Milestone-4.5 New issue 650 by tu...(a)tudorgirba.com: Mondrian multiple selection uses a broken metaphor http://code.google.com/p/moose-technology/issues/detail?id=650 The multiple selection mechanism is confusing because you have to release the mouse to start selecting. It should be disabled until it works properly.

1 9

Re: Issue 396 in moose-technology: Mondrian should provide teh start and end nodes in the edge action
by moose-technology＠googlecode.com 03 Oct '12

03 Oct '12

Updates: Cc: tudor.girba Comment #1 on issue 396 by alexandre.bergel: Mondrian should provide teh start and end nodes in the edge action http://code.google.com/p/moose-technology/issues/detail?id=396 I started to work on this (testHandlerOnEdge). However, I am unsure for few things. view interaction on: MOMouseDown do: [ :v | ... ] What v is supposed to be? The announcement or the value on which one has clicked? It has to be the value I believe. However, it may brake already existing code. We could leave it like this, and introduce on:withValueDo: What do you think? Cheers, Alexandre

1 1

Issue 698 in moose-technology: Mondrian does not properly raise MOElementSelection
by moose-technology＠googlecode.com 03 Oct '12

03 Oct '12

Status: New Owner: ---- CC: alexandr...(a)gmail.com Labels: Type-Defect Priority-High Component-Mondrian Milestone-4.6 New issue 698 by tudor.gi...(a)gmail.com: Mondrian does not properly raise MOElementSelection http://code.google.com/p/moose-technology/issues/detail?id=698 When in Glamour, often when selecting a Mondrian element does not populate the selection because the MOCanvas does not raise MOElementSelection. The reason for this seems to be a race condition due to changes in the announcement framework. In the new announcement framework from Pharo 1.3, the order of announcements is not guaranteed. The issue seems to be due to the logic of the announcement: MOCanvas>>mouseUp: .. (lastEnteredGraphElement isNil not and: [ (lastEnteredGraphElement class ~~ MORoot and: [ lastEnteredGraphElement isNotSelected ])]) ifTrue: [ selectionEvent := MOElementSelection event: anEvent on: lastEnteredGraphElement. anEvent commandKeyPressed ifTrue: [ selectionEvent setAsMultiple ]. self announce: selectionEvent. anEvent wasHandled: true. ^ self ]. Sometimes, "lastEnteredGraphElement isNotSelected" returns false because somehow the element gets selected beforehand. This is most likely related to the fact that the selection of a node actually happens by handling the same MOElementSelection announcement: MOCanvas>>announce: anAnnouncement ... anAnnouncement element isNil ifFalse: [ anAnnouncement element announcer announce: anAnnouncement ]. self announcer announce: anAnnouncement. MOViewRenderer>>setUsefulHandlersForNodes ... self interaction on: MOElementSelection do: [:ann | ann isUnique ifTrue: [ self root allSelectedNodes do: [ :node | node deselect; announce: (MOElementDeselection new) ] ]. ann element select. self updateWindow ].

4 15

Re: Issue 113 in moose-technology: Lazy edges in Mondrian
by moose-technology＠googlecode.com 03 Oct '12

03 Oct '12

Updates: Labels: -Milestone-4.2 Comment #5 on issue 113 by tudor.gi...(a)gmail.com: Lazy edges in Mondrian http://code.google.com/p/moose-technology/issues/detail?id=113 Should we postpone this one until later?

2 5

Issue 701 in moose-technology: Cut and Paste do not update a Glamour Port
by moose-technology＠googlecode.com 29 Jul '12

29 Jul '12

Status: New Owner: ---- CC: tudor.gi...(a)gmail.com Labels: Type-Defect Priority-Medium Component-Glamour New issue 701 by alexandr...(a)gmail.com: Cut and Paste do not update a Glamour Port http://code.google.com/p/moose-technology/issues/detail?id=701 Email snippets: Regarding copy paste, indeed it seems that pasting a text does not update the port. Please open a ticket. ------- I found another strange behavior, likely to be a bug. Try: -=-=-=-=-=-= | browser | browser := GLMFinder new. browser text act: [:prez :v | prez text inspect ] on: $i entitled: 'Inspect'. browser openOn: 'hello world' -=-=-=-=-=-= If you type something and press cmd-i then you open an inspector on what you have typed. Now, do a cut and paste in the textpane, and press cmd-i. You have an inspector on 'hello world', no matter what you have cut&pasted.

1 6

Issue 785 in moose-technology: inFamix don't export FAMIXLocalVariable>>parentBehaviouralEntity
by moose-technology＠googlecode.com 14 Jun '12

14 Jun '12

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.

3 9

Issue 501 in moose-technology: Cache independence
by moose-technology＠googlecode.com 01 Jun '12

01 Jun '12

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!

1 2

Issue 503 in moose-technology: Abstract classes and Hapao
by moose-technology＠googlecode.com 01 Jun '12

01 Jun '12

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

1 1

Issue 601 in moose-technology: Covered methods and tests
by moose-technology＠googlecode.com 31 May '12

31 May '12

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

1 3

Reviewing Fuel export/import utility
by Martin Dias 29 May '12

29 May '12

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

3 10

Issue 509 in moose-technology: Modularization Quality Metric
by moose-technology＠googlecode.com 28 May '12

28 May '12

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)

1 2

Issue 767 in moose-technology: Book: presentation names are confusing
by moose-technology＠googlecode.com 27 May '12

27 May '12

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 767 by sean.p.d...(a)gmail.com: Book: presentation names are confusing http://code.google.com/p/moose-technology/issues/detail?id=767 For example, on http://www.themoosebook.org/book/internals/glamour/presentations/action-list ActionListPresentation is referenced, but the class name is GLMActionListPresentation. So, when I pasted it into a workspace, it was highlighted red as an unrecognized class. I think it'd be clearer to either use full presentation class names or spaces between camel case (e.g. "Action List Presentation"). The same is true for some of the other presentations e.g. DiffPresentation

1 2

Issue 644 in moose-technology: A fly by help to show each time the source code of an entity
by moose-technology＠googlecode.com 27 May '12

27 May '12

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 644 by cy.delau...(a)gmail.com: A fly by help to show each time the source code of an entity http://code.google.com/p/moose-technology/issues/detail?id=644 Maybe it would be interesting when navigating in moose, to always have a fly by help that show the source code of an element

1 2

Issue 782 in moose-technology: inFamix should export basic metrics for methods
by moose-technology＠googlecode.com 26 May '12

26 May '12

Status: New Owner: ---- CC: georgega...(a)gmail.com Labels: Type-Defect Priority-Medium Component-ExternalTools New issue 782 by tudor.gi...(a)gmail.com: inFamix should export basic metrics for methods http://code.google.com/p/moose-technology/issues/detail?id=782 inFamix should export basic method metrics: - LOC (lines of code) - NOS (number of statements) - CYCLO (cyclomatic complexity)

1 1

Issue 582 in moose-technology: Watcher support in Glamour
by moose-technology＠googlecode.com 23 May '12

23 May '12

Status: New Owner: ---- Labels: Type-Enhancement Priority-Medium Component-Glamour New issue 582 by tudor.gi...(a)gmail.com: Watcher support in Glamour http://code.google.com/p/moose-technology/issues/detail?id=582 Like we now have a statusbar, we should also have a detailed preview shown in a floating Watcher window. The behavior would be similar to Quick Look on Mac.

1 3

Issue 763 in moose-technology: VerveineJ generates wrong paths in source anchors when there is a . in the root folder
by moose-technology＠googlecode.com 16 Apr '12

16 Apr '12

Status: New Owner: ---- CC: anquetil...(a)gmail.com Labels: Type-Defect Priority-Medium Component-VerveineJ Milestone-4.6 New issue 763 by tudor.gi...(a)gmail.com: VerveineJ generates wrong paths in source anchors when there is a . in the root folder http://code.google.com/p/moose-technology/issues/detail?id=763 Do this: - download: http://sourceforge.net/projects/jfreechart/files/latest/download - go to: jfreechart-1.0.14 - execute: /PATH_TO_verveine.extractor.java/verveinej.sh -Xmx2000m -- -autocp . . The fileNames all start with "0.14/./" instead of "./"

2 4

Issue 721 in moose-technology: VerveineJ should mark constructors
by moose-technology＠googlecode.com 13 Apr '12

13 Apr '12

Status: New Owner: ---- Labels: Type-Defect Priority-Medium Component-ExternalTools New issue 721 by tu...(a)tudorgirba.com: VerveineJ should mark constructors http://code.google.com/p/moose-technology/issues/detail?id=721 Constructors should be marked with isConstructor.

2 10

VerveineJ Output path
by Matias Barahona 07 Apr '12

07 Apr '12

Hi fellows, I'm starting to use VerveineJ to parse java projects to MSE format. I want to know if there's a way to set the output path/filename as a parameter of the execution, instead of the default: "output.mse" thanks in advance for your answer, Matías Barahona.

4 3

Kontractor include in Moose by default
by Guillaume Larcheveque 05 Apr '12

05 Apr '12

Stef and I think that Kontractor should be include in Moose by default to offer a tool for reducing title length. Do you think it's a good idea and do you know a better tool to do this? -- *Guillaume Larcheveque*

7 17

Issue 786 in moose-technology: MooseQueryResult>>intersection: is broken
by moose-technology＠googlecode.com 30 Mar '12

30 Mar '12

Status: New Owner: ---- Labels: Type-Defect Priority-Medium Component-MooseTools New issue 786 by anquetil...(a)gmail.com: MooseQueryResult>>intersection: is broken http://code.google.com/p/moose-technology/issues/detail?id=786 calling intersection between two MooseQueryResult produces an error because "MooseQueryResult is not a variable type" This is raised in basicNew: A possible workaround is to redefine MooseQueryResult>>intersection: aCollection | result | result := self class new. aCollection do: [ :each| ((self includes: each) and: [(result includes: each) not]) ifTrue: [ result add: each]]. ^ result But it might not be the best solution since I assume basicNew: might be called from other methods ...

1 0

Emergency evaluator pops up on red tests
by Fabrizio Perin 30 Mar '12

30 Mar '12

Hi, I loaded all my stuff in the latest moose based on 1.4. All the tests of my PetitPHPParser are red. When I click on one red method the emergency evaluator pops up. To reproduce it: 1- grab the latest MooseJee from the ci: http://ci.moosetechnology.org/job/moose-latest-dev/ 2- load the petit php parser: Gofer new squeaksource: 'PetitPHPParser'; package: 'ConfigurationOfPetitPHPParser'; load. (Smalltalk at: #ConfigurationOfPetitPHPParser) perform: #loadDefault. 3- Run the tests of the php parser and click on any red method. How can I debug the problem? Any suggestions on how to proceed? Thanks, Fabrizio

2 1

Mondrian forNode:do: on top level self
by Ben Coman 29 Mar '12

29 Mar '12

Background: I am trying to use Mondrian to visualize SomeContainerClass holding SomeOtherContainerClass that holds Equipment classes. So I was thinking each container class might have a method (#subviewOf: aView) which at some point does (aView forNode: self do:). Now I have come to the understanding that I am probably misusing #forNode:do: like that, and am continuing exploring that, but thought I would report the MNU that I encountered before moving on - just in case it was desirable to guard against such abuse. Steps to Reproduce: The essence of this distills down to the following in Mondrian Easel, where this first case works.... view nodes: (1 to: 20). view forNode: 2 do: [ view nodes: (50 to: 52) ] but this second case... view nodes: (1 to: 20). view forNode: view do: [ view nodes: (50 to: 52) ] gets MNU "removeAllEdges" Inserting 'self halt' between the two lines and tracing through to MONode>>nodeWith:ifAbsent shows the line... nodeLookedUp := self nodes detect: [:each | each model = anObject ] ifNone: aBlock. has in the first case (self nodes) as anOrderedCollection of 20 items and in the second (self nodes) is an empty Array. Just reporting for discussion. I am not sure if this would be considered a bug worth tracking, or just an abuse of the framework. Cheers, Ben

4 9

jenkins do not read the xml reports from Arki
by Fabrizio Perin 29 Mar '12

29 Mar '12

Hi, I have a problem with automoose and jenkins. I basically use automoose to load some code than at the end of the st file I do: Gofer new renggli: 'hudson'; package: 'HudsonBuildTools'; load. "Run reports" report := MyReport on: MooseModel root first. report open. REPHudson runOn: report spec. SmalltalkImage current snapshot: true andQuit: true. What happen is that jenkins ends with a failure claiming that there are no test runned but the xml file generated by REPHudson is in the folder together with the Moose image. Do I miss something? Shouldn't jenkins report about the Arki report? Thanks for any help. Cheers, Fabrizio

2 2

Load PetitGui with minimal dependency
by Norbert Hartl 29 Mar '12

29 Mar '12

Is there a way to load PetitGui with a smaller set of dependecies? Or is Magritte and Grease and etc. needed for the GUI? Loading PetitParser default loads default of Glamour, too. And that's quite a lot. thanks, Norbert

4 10

TreeMapLayout in Mondrian
by Dennis Schenk 28 Mar '12

28 Mar '12

Hi, I'm working on a treemap layout in Mondrian. I created the basic functionality but am far from finished. For the current progress see the following screenshots: http://cl.ly/342z261g021c3X1j3X2b - A visualization of a very simple java system (https://github.com/mircealungu/SimpleSample) http://cl.ly/3H3x1K1y3O3j430S0a2z - A visualization of FAMIX itself. The following is an example of how one sets up the layout: viewTreemapOn: view > view nodes: self nodes. > > view edges: self nodes > from: [ :each | each ] > toAll: [ :each | each children ]. > > view layout: (MOTreeMapLayoutIncubation withWeightBlock: [ :e | > | model | > model := e model. > model isNil ifTrue: [ > 0. > ] > ifFalse: [ > e model entity numberOfLinesOfCode. > ]. > ]). The tree structure is given by the edges definition. The layout is created with a weight block (lines of code here, but could be anything). At the end I'd like to have something like: http://cl.ly/3v1L3O2a2n1H1C2x3J0V - TreeMap in Softwarenaut in VisualWorks. This is the first code that I'm writing with Mondrian, so I'm sure it could be improved in many areas. If anyone sees a problem with how I set up the layout. please do tell. If anyone wants to look at the code in detail please take a look at MOTreeMapLayoutIncubation in my Softwarenaut repository (I'm creating the tree map layout as part of the Softwarenaut port to Pharo): MCHttpRepository > location: 'http://www.squeaksource.com/Softwarenaut' > user: '' > password: '' The layout is currently in this repo, if it is more mature, it would be cool to add it to Mondrian itself. I'd like to make it as generic as possible. Now for some specific questions: The red colors you see in the screenshots is actually a bug. What I would like to do is only color the leaf nodes, but somehow (my guess is, it has something to do with shape caching?), it also colors the containment blocks. The way I do it is, while ging through the nodes (MONode) to draw them If it is a leaf > node shape fillColor: ((Color fromString: '#ff0000') alpha: 0.1). If it is a containment block: > node shape fillColor: (Color fromString: '#eeeeee'). But somehow all shapes (except the root node) are colored with the red translucent color. Does anyone have an idea why this could be the case? In general: I'm doing the styling of the nodes (also tried to add some interactivity) directly inside the layout, but I'm not sure if this is the Mondrian way to do this, since normally shape definitions and interaction is defined when creating the view. Is this okay? Or should I do this in another way? My thought was that I'd like to have a treemap layout with default, nice looking interactions, colors etc. without having to define them outside, when defining the view, so it needs as little setup as possible. Any inputs in general are greatly appreciated. Cheers, Dennis

3 14

SciSmalltalk
by Serge Stinckwich 28 Mar '12

28 Mar '12

Dear all, we already discuss about that in the moose and pharo mailing-list. Maybe this is too late, but please find a small proposal for gsoc 2012 below. ================================================================ Name: SciSmalltalk Level: Intermediate Possible mentor: Serge Stinckwich Possible second mentor: ? Description Smalltalk has at that time no equivalent to mathematical libraries like NumPy, SciPy (Python) or SciRuby (Ruby). The goal of the SciSmalltalk project is to develop an open-source library of mathematical for the Smalltalk programming language (MIT Licence). Technical Details The development of this project is to be done in Pharo Smalltalk, but the code should be portable to other Smalltalk flavors. Numerous Smalltalk projects provide already some basic functionalities (complex and quaternions extensions, random number generator, fuzzy algorithms, LAPACK linear algebra package, Didier Besset's numerical methods, ...). A first task will be to do an audit of all the existing projects that provide some mathematical stuff and build a Pharo Configuration to load them in a fresh Pharo Smalltalk image. After that, the student help by his/her mentors will decide what are the numeric algorithms to develop in priority. The student will need to know some basic numeric algorithms usually found in such libraries. Units tests should also be provided. Benefits to the Student The student will help the Smalltalk community in a very concrete way. The student will learn to design well-designed code with tests. Benefits to the Community Having a package providing more elaborate numeric libraries is really important to develop the use Smalltalk in new domains (robotics, high performance computing, computer vision, bio-computing, ...). The lack of numeric librairies hamper the use of the Smalltalk in a scientific context at the moment. An another goal of this project is to develop a community of people interested by these topic. Regards, -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/

3 4

InFamix do not import correctly FAMIXLocalVariable parentBehaviouralEntity
by Fabrizio Perin 28 Mar '12

28 Mar '12

Hi, I imported a Model generated with InFamix and i tried to navigate the model with the MooseFinder. Once I click on class the debugger opens with a MNU: receiver of "classScope" is nil. In fact FAMIXLacalVariable>>belongsTo returns nil. Anybody have the same problem? Cheers, Fabrizio

2 3

how to embed a MooseFinder in another browser?
by Fabrizio Perin 28 Mar '12

28 Mar '12

Hi, I was wondering how to open a MooseFinder on an element selected in another browser. I tried something like this: browser := GLMTabulator new. browser column: #functions; column:#finder. browser transmit to: #functions; andShow: [ :a | a list title: 'Functions'; display: [:each | each ]]. browser transmit to: #finder; from: #functions; andShow: [ :a | a finder title: [:each | each mooseName]; ..... ^ browser but I don't know how to proceed (this is why I added the dots). Any suggestion? Am I doing it the wrong way? Cheers, Fabrizio

3 4

Mondrian saving and reloading a layout
by Ben Coman 28 Mar '12

28 Mar '12

In Mondrian I can drag nodes around the layout to make a more pleasing graph. Is there a mechanism built in to facilitate saving and later reloading the layout of a graph ? Or where should I look into to system to implement this? -cheers, Ben

3 7

Re: Jenkins build is still unstable: moose-latest-dev #906
by Alexandre Bergel 27 Mar '12

27 Mar '12

I fixed the two Mondrian failing tests. All these problems stems from the recent changes in the collection hierarchy. Somehow, the order of elements are not preserved. Here is an example: Consider the script: view nodes: (1 to: 4). view edgesFromAssociations: {1 -> 2 . 1 -> 3 . 3 -> 4}. view treeLayout It displays this: or this: Before the recent collection changes, it was always the same layout, one of the two. So the tests need to be updated... The build should be green again Cheers, Alexandre On 27 Mar 2012, at 02:17, admin(a)moosetechnology.org wrote: > See <http://hudson.moosetechnology.org/job/moose-latest-dev/906/> > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

1 0

Stable Moose Configuration
by Dennis Schenk 27 Mar '12

27 Mar '12

Hi, Im currently using the dev version of Moose. For some parts it is still very unstable. For example when using the Mondrian Easel examples, it always crashes after a short while. Also autocomplete does not seem to work at the moment. I looked at ConfigurationOfMoose to see if I could use the stable version for some of the development, but there the stable version currently points to version 4.3.4 as far as I can tell. Would it be possible to create a configuration for the latest stable version of Moose, i guess that would be 4.6.x? Cheers, dennis

4 16

Updating a browser with Glamour
by Santiago Vidal 27 Mar '12

27 Mar '12

Hi, I implement a browser with glamour. To provide data to the browser I use the Hismo models that are installed in the Moose Panel: browser openOn: MooseModel root allModelHistories How can I refresh the data shown by the browser when a new Hismo model is added to the Moose Panel? Thanks. Cheers, -- Santiago Vidal

2 2

8 failing tests remaining
by Tudor Girba 26 Mar '12

26 Mar '12

Hi, After fixing Collection>>union: in Pharo, the Moose tests are better. We now have only 8 failing tests. Any help to fix these would be appreciated :) Cheers, Doru -- www.tudorgirba.com "What is more important: To be happy, or to make happy?"

3 8

Issue 783 in moose-technology: hidden 'Name already defined' tempvar & ivar clash
by moose-technology＠googlecode.com 26 Mar '12

26 Mar '12

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 783 by google....(a)ben.coman.com.au: hidden 'Name already defined' tempvar & ivar clash http://code.google.com/p/moose-technology/issues/detail?id=783 Moose 4.6 has some hidden clashes between instance variables and method temporary variables. In order to observe the operation of #forNode:do: in Mondrian, I went to add only 'self halt' to MOViewRendererTest>>testEdgesAndInteractiveExpansion. When I tried to <Accept> this, it complained temporary variable 'view' was 'Name already defined' and indeed MOViewRendererTest does have a clashing instance variable 'view' which prevents me from saving my change. Similar has happened to me previously a few times, so I thought I would flag it in case anyone was curious to determine how this got past the compiler into the system, and also might be able to do some automated sweep of the code to detect any similar occurances. cheers, Ben

1 1

Mondrian - display of text within ellipse
by Ben Coman 26 Mar '12

26 Mar '12

In Moose 4.6, World > Moose > Mondrian Easel > Examples > basic > edges + tiled nodes has this code... | nodes | view shape rectangle width: 40; text: #yourself. nodes := view nodes: (1 to: 20). view shape arrowedLine. view edges: (2 to: 20) from: 1 to: #yourself. view layout: (MOCircleLayout forNodes: nodes allButFirst) which displays text inside each rectangular node. If I change the second line to... view shape ellipse then nodes do appear as ellipses but the text disappears. That is not what I expected. How can text be made to display within an ellipse? cheers, Ben

2 2

are you using moose?
by Tudor Girba 24 Mar '12

24 Mar '12

Hi, Are you using Moose for something? If yes, could you let us know what that something is? It can be research, play, commercial, short term, long term, for software analysis, for other kinds of analysis. Or maybe you are using only some part of it all. Anything would do. Please take 2 minutes to reply. Cheers, Doru -- www.tudorgirba.com "We can create beautiful models in a vacuum. But, to get them effective we have to deal with the inconvenience of reality."

13 21

Re: Jenkins build is back to stable : moose-latest-dev #901
by Tudor Girba 23 Mar '12

23 Mar '12

Great, indeed! Doru On Fri, Mar 23, 2012 at 11:16 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Yupi! No failed test! > Good job guys! > > Alexandre > > > > Le 22 mars 2012 à 16:41, admin(a)moosetechnology.org a écrit : > >> See <http://hudson.moosetechnology.org/job/moose-latest-dev/901/> >> >> -- www.tudorgirba.com "Every thing has its own flow"

1 0

Meta data for new SourceLanguage problem
by Guillaume Larcheveque 23 Mar '12

23 Mar '12

Hello, I added a new importer in the Moose Panel and so I can browse my model. It show me that no SourceLanguage was defined so I added my own sourceLanguage, inheriting from FAMIXSourceLanguage. I have a problem is about this call: anObject mooseInterestingEntity mooseDescription allPrimitiveAttributes because mooseDescription return nil. The problem is about asMooseDescription send to my class because it refer to the MooseModel meta dictionnary and my class is not in, so it return nil. I have implemented the class method annotation but it doesn't change anything. How can I have my class in the dictionnary? Thanks in advance. -- *Guillaume Larcheveque*

5 6

Draw math functions with EyeSee
by Serge Stinckwich 22 Mar '12

22 Mar '12

Hi all, i try to use EyeSee to plot mathematical functions with ESLineDiagram. They is not easy as i might expect at the beginning :-) The problem is EyeSee is using collections as models. I try to transform the function as a collection like above but maybe there is a better way to do that. |diag f functionAsModel| f := [:x | x*x]. functionAsModel := (0 to:10 by:0.1) collect:[:each | f value:each]. diag := ESDiagramRenderer new. (diag lineDiagram) y: #yourself; yAxisLabel: 'X^2'; rotatedLabels: true; regularAxis; defaultColor: Color green; models: functionAsModel. diag open Regards, -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Every DSL ends up being Smalltalk http://doesnotunderstand.org/

4 4

1 failing test: moose-latest-dev #900
by Tudor Girba 22 Mar '12

22 Mar '12

Hi, We got down to one failing test: MOLayoutTest>>testHorizontalTreeLayout This is related to the order in collection noticed by Alex. Cheers, Doru Begin forwarded message: > From: admin(a)moosetechnology.org > Subject: Jenkins build is unstable: moose-latest-dev #900 > Date: 22 March 2012 07:45:23 CET > To: tudor(a)tudorgirba.com, simon.denier(a)gmail.com, cy.delaunay(a)gmail.com, alexandre(a)bergel.eu, stephane.ducasse(a)inria.fr, jannik.laval(a)gmail.com > > See <http://hudson.moosetechnology.org/job/moose-latest-dev/900/> > > -- www.tudorgirba.com "Sometimes the best solution is not the best solution."

3 4

Automoose
by Norbert Hartl 22 Mar '12

22 Mar '12

Now that I found some new motivation spending some time on moose I defined a project for me to work on. In order to achieve the simple task I like to know if it is possible to export images from Automoose. I don't know how the integration of moose into jenkins is meant. I would imagine having predefined analysis diagrams shown on the jenkins project page side by side with the lint und sunit results. thanks, Norbert

5 7

numerical method in smalltalk
by Stéphane Ducasse 20 Mar '12

20 Mar '12

could be interesting to see if we need to some numerical analysis in moose and pharo. I will create a configuration MCSqueaksourceRepository location: 'http://squeaksource.com/DHBNumerical' user: '' password: ''

5 16

FAMIX.Invocation Help
by roberto.minelli＠usi.ch 20 Mar '12

20 Mar '12

Hi all, I have a doubt regarding 'FAMIX.Invocation's. Suppose I've this line of Java code: > startActivity(new Intent(this, ActivityTwo.class)); When I generate the mse (using VerveineJ) this result in a FAMIX.Invocation such as > (FAMIX.Invocation (id: 8005) > (candidates (ref: 9100)) > (previous (ref: 3174)) > (receiver (ref: 2547)) > (sender (ref: 7328)) > (signature 'startActivity(Intent)')) The 'new Intent(…)' instead results in a FAMIX.Invocation such as > (FAMIX.Invocation (id: 8291) > (candidates (ref: 753)) > (sender (ref: 430)) > (signature 'Intent(Context,Class<?>)')) I need to extract the 'ActivityTwo.class' argument. Is there a way to get it? Thanks in advance for any sort of help. Cheers, RM

2 2

Re: Issue 602 in moose-technology: Hapao should provide a legend in every window
by moose-technology＠googlecode.com 20 Mar '12

20 Mar '12

Updates: Summary: Hapao should provide a legend in every window Comment #3 on issue 602 by tudor.gi...(a)gmail.com: Hapao should provide a legend in every window http://code.google.com/p/moose-technology/issues/detail?id=602 Then let's name the issue for what it should do.

1 3

Re: Issue 439 in moose-technology: Make package blueprints work on Namespace
by moose-technology＠googlecode.com 20 Mar '12

20 Mar '12

Updates: Status: WontFix Comment #1 on issue 439 by tudor.gi...(a)gmail.com: Make package blueprints work on Namespace http://code.google.com/p/moose-technology/issues/detail?id=439 I guess this won't be worked on.

1 0

failing tests
by Tudor Girba 20 Mar '12

20 Mar '12

Hi, A ton of tests are still failing due to the issue of Collection>>union:. Most of these issues seem to come from the metrics that seem to overuse this functionality: http://ci.moosetechnology.org/job/moose-latest-dev/lastCompletedBuild/testR… It would be great if the authors would look over it. Cheers, Doru -- www.tudorgirba.com "Live like you mean it."

3 7

Issue 489 in moose-technology: Glamour: action list without the dropdown
by moose-technology＠googlecode.com 20 Mar '12

20 Mar '12

Status: New Owner: ---- CC: tudor.girba Labels: Type-Defect Priority-Medium New issue 489 by jfabry: Glamour: action list without the dropdown http://code.google.com/p/moose-technology/issues/detail?id=489 I have a Glamour pane that is an actionList where I do 5 populate:on:entitled:with: so that the pane has 5 buttons. Now what happens is that the pane also has a dropdown menu, with the same actions as the buttons. This menu should not be there according to Doru ...

1 2

Re: Issue 281 in moose-technology: Accordion should expand the last presentation
by moose-technology＠googlecode.com 20 Mar '12

20 Mar '12

Updates: Status: WontFix Comment #4 on issue 281 by tudor.gi...(a)gmail.com: Accordion should expand the last presentation http://code.google.com/p/moose-technology/issues/detail?id=281 (No comment was entered for this change.)

1 0

Re: Issue 240 in moose-technology: Smalltalk importer scalability
by moose-technology＠googlecode.com 20 Mar '12

20 Mar '12

Comment #2 on issue 240 by tudor.gi...(a)gmail.com: Smalltalk importer scalability http://code.google.com/p/moose-technology/issues/detail?id=240 Anyone interested in picking this up?

1 1

Re: Issue 191 in moose-technology: Do not execute unnecessary transmissions
by moose-technology＠googlecode.com 20 Mar '12

20 Mar '12

Updates: Labels: -Milestone-4.2 Comment #5 on issue 191 by tudor.gi...(a)gmail.com: Do not execute unnecessary transmissions http://code.google.com/p/moose-technology/issues/detail?id=191 (No comment was entered for this change.)

1 1

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev March 2012