Moose-dev July 2012

moose-dev@list.inf.unibe.ch

22 participants
110 discussions

migrating mondrian to roassal - Menus
by Ben Coman 29 Jul '12

29 Jul '12

just documenting another migration.... this in Mondrian... view interaction menuItems add: 'Browse class' -> [:a2 | a2 browse ]. view interaction registerMenu. appears to become this in Roassal... view interaction item: 'Browse class' action: #browse. How do you get a context menu on the background? btw, I see that ROEaselMorphic>>populateMenuOn: calls #zoomInButtonOn: which calls #addMenu:callBack: Does #addMenu:callBack always draw the item in a box? Can you get multiple items in one box? From an outside perspective if there can be only one item per box then #addButton:callBack would seem a more appropriate name.

2 1

reflections upon MooseChef withoutSelfLoops and scoping
by Nicolas Anquetil 29 Jul '12

29 Jul '12

Anybody can submit an opinion to the following issue: MooseChef allows to express a query such as: aClass queryOutgoingInvocations aMethod queryOutgoingReferences that will return all methods invoked from 'aClass' for the first query and all classes referenced by 'aMethod' in the second query Then you can constraint the scope of the result, for example to say that you are interested by the package containing the referenced classes aMethod queryOutgoingReferences atPackageScope You can also down scope the result, for example to say you want all the methods of the class referenced: aMethod queryOutgoingReferences atMethodScope Finally, there is something to say you are not interested in relation that loop back to the original object queried aClass queryOutgoingInvocations withoutSelfLoops will return all classes that own methods invoked from 'aClass' except 'aClass' itself (that would be a selfLoop) one sees on this example that withoutSelfLoops involves some scoping: queryOutgoingInvocations will return a collection of methods, but the query was sent to a class. So when we say withoutSelfLoop, we actually mean all methods that don't belong to the class to which the query was sent. This is equivalent to: aClass queryOutgoingInvocations atClassScope withoutSelfLoops Up to now, the semantic is rather Ok, but when you use hidden down scoping, it starts to be less clear: aMethod queryOutgoingReference withoutSelfLoops will return all classes referenced in 'aMethod' taken at methodScope and removing self loop. In the end, the result will ignore references to the class owning 'aMethod'. What do you think? There is some logic in the semantic, but it is not so intuitive. Looking at the query, I cannot convince me that this is the result that one would expect. Should we change the semantic? To what? (keep up-scoping and forbid implicit down-scoping? forbid all implicit re-scoping?) nicolas PS: This may look like a rather theoretical question, but I actually have a bug partly related to that and I need to know how to solve it

3 2

migrating mondrian to roassal - MOLineShape>>frompositions & view domain
by Ben Coman 29 Jul '12

29 Jul '12

I have just downloaded Moose47 and am starting to migrate my app from Mondrian to Roassal. For the code below where 'a mondrian' /becomes/ 'a roassal' ... At "#1" I get MNU ROLine>>fromPositions For now I worked around this by deleting #fromPositions: and #toPositions: but how do I get similar functionality to manage where the endpoints ? I did find in "attachPoint := ROShorterDistanceAttachPoint instance" in ROLine>>initialize but it would be good to get an idea of the overall architecture for this. At "#2" I get MNU ROMondrianViewBuilder>>domain - where #domain returns an OrderedList of all the model entities, of which I ask each for all its relationship links to other model entities to define the edges. For now I worked around this by factoring "EpcimRoot withAllSubclasses" out to a temporary variable, but I am wondering how in future to access the model entities of the graph. I did find "#elementsWithModelDo:" in ROMondrianViewBuilder>>rawEdgesFrom:to: but not sure whether that is a public/private method. ---------------------- a mondrian title: 'Class Definition - Full Model' ; painting: [ :view :selection | view shape label. view interaction popupText: [ : element | element class comment ]. view nodes: (EpcimRoot withAllSubclasses). view edgesFrom: #superclass. (view shape line) "#1: /was/ a MOStraightLine /becomes/ a ROLine " color: Color lightBrown. fromPositions: #(#center); toPositions: #(#center). view edges: view domain "#2: view /was/ a MOViewRenderer /becomes/ a ROMondrianViewBuilder" from: #yourself toAll: [ :x | x relations collect: [ :z | z key ] ]. view horizontalTreeLayout . ]

2 4

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

Re: scaling moose
by Stéphane Ducasse 28 Jul '12

28 Jul '12

>> >> >> Hi Stef, >> Sorry but the problem is not that there are no 64-bit vms and images >> available. The problem is that the available 32-bit vm and image cannot be >> pushed further 500MB. Even worst is that as far as I understood we are not >> even sure why is like that. >> >> For me a reasonable size for a Moose image containing an average size Java >> Enterprise application is between 500MB and 1500MB. So a 32-bit vm\image >> should be perfectly able to store the whole model and to have enough free >> space for computations. >> >> >> It is true that we cannot go larger than 500 mb? >> > yes, the hardcoded limit is 500mb do you know why? > >> >> >> Partial loading could be a solution in some cases but we need tool support >> for that. I cannot invest 2 weeks every time I need to script a 10 minutes >> analysis trying to figure out how to partially load the information that I >> "might" need. Without having a full model available the entire idea of >> prototyping analysis behind Moose goes down the drain and so Moose itself >> lose a lot of its meaning. >> I think the whole point is to have all the data on the system in analysis at >> hand. Either having 10GB model stored in an image or loading the needed >> entities on demand it is not relevant as soon as it is transparent for the >> user and the performances are not too bad. >> >> Cheers, >> Fabrizio >> >> 2012/7/25 <stephan(a)stack.nl> >>> >>> Hi Doru, >>> >>> When thinking about scalability of Moose, what scenarios do you have >>> in mind? Up to about half a terabyte, you can run out of main memory >>> on a single machine cost-effectively. The main limitation there is >>> the lack of a 64-bit vm and image. As far as I understand the access >>> patterns involved, a main memory based or distributed main memory >>> solution is far preferable for actually analyzing systems. What do you >>> hope to achieve by going to disk? When we did the data conversion project, >>> we thought about partitioning over multiple images but finally managed >>> with partial loading. >>> >>> Stephan >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev(a)iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> > > > > -- > Best regards, > Igor Stasenko.

1 0

scaling moose
by Tudor Girba 27 Jul '12

27 Jul '12

Hi, A topic that was raised recently is the scalability issue of Moose. Indeed, it would be great to have again some traction in this direction. I think there are a couple of possibilities in this area: - Gemstone. This is the straightforward idea and it would probably match quite well the FAMIX object-oriented model. The realization might not be that easy because we would need to go through all the details of the language independence. Also, we would need a remote UI, or at least a bridge for Glamour. Perhaps the Seaside interface of Glamour, or another Seaside-based one, would be a good direction. - Graph DBs. http://neo4j.org/ would be an interesting target here. I have no experience in this area, but I would be very interested in collaborating with someone on this. - Relational DBs. I know that Marco D'Ambros worked on a solution to map FAMIX meta-descriptions to Glorp in VW. And it seemed to work. I think Alberto Bacchelli is or has used it. - Fuel. Loading with Fuel is about one order of magnitude faster than loading plain MSE: for example for ArgoUML 0.32 I got 108s for the MSE, and 17s for the Fuel based MSE information. So, having the Fuel export next to the MSE file can be a significant improvement. However, this solution only works when you have computations that treat one model at a time (so, it's not so nice if you have to switch between models all the time). I attached a simple script to analyze the difference between plain MSE loading and Fuel load variations. - Filtered loading. This solution works well when you have the full model, but you do not need all of it. FMMetaRepositoryFilter offers the infrastructure for a filtered loading at the level of FAME: if you want to load a sub part of your model, you construct a sub-meta-model and then let Fame do the rest. This kind of works, but it is only available at the moment in code (look at the tests). We need to move to the next step of integrating this solution and replace the MooseImportingContext and possibly offer a UI as well. If you want to pick up on any of these topics, let's open a separate thread and see what we can do. 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."

6 7

Issue 815 in moose-technology: Roassal Mondrian builder does not accept nodes that are not subclasses of Collection
by moose-technology＠googlecode.com 26 Jul '12

26 Jul '12

Status: New Owner: tudor.gi...(a)gmail.com CC: alexandr...(a)gmail.com Labels: Type-Defect Priority-Medium Component-Roassal Milestone-4.7 New issue 815 by tudor.gi...(a)gmail.com: Roassal Mondrian builder does not accept nodes that are not subclasses of Collection http://code.google.com/p/moose-technology/issues/detail?id=815 The guard condition restricts unnecessarily: nodes: objects | els | self assert: [ objects isKindOf: Collection] description: 'Should provide a collection as parameter'.

1 3

Issue 806 in moose-technology: Roassal does not store edges in the proper place
by moose-technology＠googlecode.com 26 Jul '12

26 Jul '12

Status: New Owner: ---- CC: alexandr...(a)gmail.com Labels: Type-Defect Priority-Medium Component-Roassal Milestone-4.7 New issue 806 by tudor.gi...(a)gmail.com: Roassal does not store edges in the proper place http://code.google.com/p/moose-technology/issues/detail?id=806 If you do: view nodes: #(1 2) forEach: [ :each | view shape label. view nodes: ({each * 10 . (each * 100)}). view treeLayout. ]. view edgesFromAssociations: {10 -> 100. 20 -> 200}. The inner nodes are not laid out in a tree. The reason is that the edges are stored in the parent node that defines them, rather than in the most specific common parent of the from and to nodes. We got the same problem in Mondrian.

1 5

Brain storming request: Semantic zooming for Roassal
by Alexandre Bergel 25 Jul '12

25 Jul '12

Hi! I've just found this video: http://cel.inf.usi.ch/index.php?action=gallery I am not sure I really want to program a tetris that way, but the tool they have is interesting. It intensively use zooming in and out. When you zoom in, you see different objects and when you zoom out they disappear or they change their visual representation. For Roassal, we are thinking about adding new graphical elements when a particular height of the camera is reached. The elements will then disappear when the camera is getting altitude. However, it looks a bit simple in my opinion. Is there any compelling scenario for a better mechanism? Is there anything else you guys want to see in this zooming ability? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

4 5

Issue 814 in moose-technology: [MooseChef] Need to deal with entities that don't have scope
by moose-technology＠googlecode.com 25 Jul '12

25 Jul '12

Status: New Owner: ---- Labels: Type-Defect Priority-Medium Component-MooseCore New issue 814 by anquetil...(a)gmail.com: [MooseChef] Need to deal with entities that don't have scope http://code.google.com/p/moose-technology/issues/detail?id=814 This is linked to issue 812. Making the change for this issue, highlighted a problem with scope: Some queries might return objects that do not have scope (ex: primitiveType, StructuralEntities, ...). The result can be then filtered with withoutSelfLoop that relies on scope There might be other example where one might ending up asking the scope of an unscoped entity. Possible solutions: - ensure that all entities have a relevant scope in MooseChef - create an "#unscoped" MooseChef scope and update MooseChef accordingly - return nil when asking the scope of an unscoped entity, and reprogram withoutSelfLoop to handle that case (not sure it is possible)

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev July 2012