Moose-dev

moose-dev@list.inf.unibe.ch

6621 discussions

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

update for Roassal
by Usman Bhatti 25 Jul '12

25 Jul '12

Hello, I am trying to add an update event in GLMMorphicRoassalRenderer so that when the pane containing the roassal visualization is sent an update event, the corresponding roassal visualization is redrawn (please see: http://code.google.com/p/**moose-technology/issues/**detail?id=808<http://code.google.com/p/moose-technology/issues/detail?id=808> ). Now, I can trigger painting block of the GLMRoassalPresentation but there are some missing entities and the layout not being applied properly.Please find attached to this mail my code for GLMMorphicRoassalRenderer class to trigger the update event. Can you please see what is missing in my code that does not allow proper rendering of roassal visualization? You can use this code to test the updated rendering feature: | browser startNumber | browser := GLMTabulator withStatusbar. startNumber := 1. browser column: #one. browser transmit to: #one; andShow: [ :a | a roassal title: 'Numbers in Roassal'; painting: [:view :number | view shape label. view interaction on: ROMouseClick do: [ :event | ROFocusView new on: event element view: view raw ]. view nodes: (startNumber to: number). view edgesFrom: [:each | each // 5 ]. self halt. view treeLayout. view addMenu: 'Refresh' callBack: [ :stack | startNumber := 10. (browser paneNamed: #one) update ]. ]]. browser openOn: 42 tx, Usman

3 2

Re: To a unified software model repository for Moose.
by Stéphane Ducasse 25 Jul '12

25 Jul '12

On Jul 25, 2012, at 3:42 PM, Andrea Caracciolo wrote: > Hi Stef, > > I read your replies in the mailing list and i wanted to clarify some doubts. > As I understand, your points are the following: > - extend the FAMIX meta-model adding new meta-data to make the concept of "project version" and "project" explicit. not necessarily. First the moose infrastructure. > - supporting the exchange of partial models Yes. > To me it seems that both of the mentioned ideas contradict the purpose of the MSE format. > MSE is good for packaging structural information about one single project snapshot. > If you want to represent a project and all of its versions as a whole, you need to come up with a new representation format. no :) mse is a format to exchange data. > Also shrinking models looks quite hard. You end up with a lot of broken dependencies and you need to generate a file which fits your personal analysis requirements. Not really. Have a look at MooseImportingContext it is there to manage that you always save and load a coherent model. In fact I use it to import coherent Smalltalk models. So loading is the same. You look at the graph dependencies and pay attention that if you remove attributes you do not use something that requires it. This is the job of the ImportingContext to manage that for you. We should ask cyrille because I think that I remember that he worked on partial loading. Now at the end some graph dependencies where expressed in FAME and I lost track. > In my opinion, the best option would be to transition to relational database as an intermediate representation medium. Give a try and let us know but I have some doubts. > Instead of exchanging models through mse files, you replicate a certain set of DB entires. Saving to relational databases graphs is not easy and simple. For the moment imagine that we want to build a dashboard where we monitor some metrics. you can write a script that checkout source code launch verveineJ generate a new version in use then you load the use file (filtering information if you can = make sense) compute your metrics save a strip down version of your model that fit the purpose of your analysis now since you want to do a trend analysis you load following the strategies developed by andre all the stripped versions, or just 10 of them and the latest…. and you compute your dashboard data. To me a project: an entity managing files and sources, versions on a disk or whatever it is stored . After a project could have different loading strategies but well encapsulated. > Parsing of MSE is replaced by recursively exploring the newly created database entries. > This would also allow to have different strategies for loading famix objects in memory. > > > Cheers > _____________________________ > Andrea Caracciolo -- caracciolo(a)iam.unibe.ch > Software Composition Group > University of Bern > > > > > >

1 0

Issue 813 in moose-technology: Java primitive type "int" created as FamixType
by moose-technology＠googlecode.com 25 Jul '12

25 Jul '12

Status: New Owner: anquetil...(a)gmail.com Labels: Type-Defect Priority-Medium Component-VerveineJ New issue 813 by anquetil...(a)gmail.com: Java primitive type "int" created as FamixType http://code.google.com/p/moose-technology/issues/detail?id=813 Parsing some files in Eclipse creates a FamixType for the primitive type int

1 0

Progress Indicator
by Dennis Schenk 25 Jul '12

25 Jul '12

Hi all, Could anyone point me in the right direction on how to create a progress indicator for long running tasks? Are there any examples, implementation I could look at? I found *MooseCustomTask* and *SystemProgressBarMorph*. I'm not sure about using the MooseCustomTask, because what I want to do is not directly related to moose. Its just a generic task. Are there any other classes that handle the display of progress bars? Thanks, Dennis

2 2

FAMIX: Lines of code for nested namespaces
by Dennis Schenk 25 Jul '12

25 Jul '12

Hi all, Whats the best way to get LOC for nested FAMIXNamespaces? Lets say I'm looking at a FAMIX model of argouml. I used the "Infer Namespace Parents Based on Names" command in the Moose Panel. I have a namespace argouml (org.argouml), and a namespace profile (org.argouml.profile). Calling numberOfLinesOfCode on the second namespace gives me a correct number of around 1000 (I assume because the "children" of profile are actually FAMIXClasses). Calling it on the first one returns 0. So what would be the best way to get LOC on parent namespaces like "org", or "org.argouml"? Also is this by design that LOC does not get propagated up in the hierarchy or is it even a bug? Cheers, Dennis

3 4

Issue 812 in moose-technology: All FamixType are at classScope in MooseChef
by moose-technology＠googlecode.com 25 Jul '12

25 Jul '12

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 812 by anquetil...(a)gmail.com: All FamixType are at classScope in MooseChef http://code.google.com/p/moose-technology/issues/detail?id=812 All FamixType are at classScope in MooseChef This means for example that the Java primitive type "void" can be returned by a mooseChef query: xyz queryOutgoingDependencies atClassScope there is an outgoing dependency to void, but void should not be at class scope need to change FAMIXType>>atClassScope and FAMIXClass>>atClassScope

1 0

Issue 810 in moose-technology: Create virtual association TypeDeclaration in MooseChef
by moose-technology＠googlecode.com 25 Jul '12

25 Jul '12

Status: New Owner: anquetil...(a)gmail.com Labels: Type-Enhancement Priority-Medium Milestone-4.7 New issue 810 by anquetil...(a)gmail.com: Create virtual association TypeDeclaration in MooseChef http://code.google.com/p/moose-technology/issues/detail?id=810 Famix recognizes 4 types of associations (reference, access, inheritance, invocation) and Moosechef was built upon these dependencies (queryAllOutgoingReferences, ...) but this misses some actual dependencies that are not expressed by FamixAssociations like: return type of a method or type of a variable Since we now have a nice general API to query dependencies, it would be nicer if it were complete, ... A possible solution would be to invent some new "virtual associations" (TypeDeclaration) and create queries for this, ...

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev