Moose-dev September 2014

moose-dev@list.inf.unibe.ch

42 participants
134 discussions

Re: Issue 393 in moose-technology: Interactive sort of table widget by columns
by moose-technology＠googlecode.com 13 Nov '14

13 Nov '14

Updates: Cc: simon.de...(a)gmail.com tudor.gi...(a)gmail.com Comment #1 on issue 393 by tu...(a)tudorgirba.com: Interactive sort of table widget by columns http://code.google.com/p/moose-technology/issues/detail?id=393 Issue 156 has been merged into this issue. -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings

1 1

Issue 973 in moose-technology: Roassal font organizer singleton inconsistencies
by moose-technology＠googlecode.com 13 Nov '14

13 Nov '14

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 973 by benjamin...(a)gmail.com: Roassal font organizer singleton inconsistencies http://code.google.com/p/moose-technology/issues/detail?id=973 Following on from Issue 971, use of singletons related to the Roassal font organizer seems not used consistently. Using Finder, I've searched all 'Source' of Roassal packages, for the following both 'ROFontOrganizer' and 'fontOrganizerClass' and found... ----Part1-------------- ROAbstractLabel >> fontFor: anElement with: aCamera fo := ROPlatform current fontOrganizerClass. ROAbstractLabel >> offsetWhenDrawing ^ ROPlatform current fontOrganizerClass ROAbstractLabel >> widthOfLine: string withFont: aFont ^ ROFontOrganizer current widthOfString: string font: font. I propose the last is changed to... ROAbstractLabel >> widthOfLine: string withFont: aFont ^ ROPlatform current fontOrganizerClass widthOfString: string font: font. and also delete... ROFontOrganizer >> current ^ self subclasses first which seems plain wrong. ----Part2-------------- Also I'm a perplexed by the way both of these methods ROMorphicPlatform>>fontOrganizerClass ^ ROFontOrganizerMorphic ROPharoAthensPlatform>>fontOrganizerClass ^ ROFontOrganizerAthens override this one ROPlatform>>fontOrganizerClass ^ fontOrganizerClass such that the instance-variable 'fontOrganizerClass' is ignored, as well as the following seeming irrelevant... ROPlatform>>fontOrganizerClass: ^ fontOrganizerClass := aClass. Is ROPlatform ever instantiated, or abstract? A search for all references to 'ROPlatform' in the 'Source' of all Roassal finds... * ROPlatform current (x40) * ROPlatform platforms (x2) * ROPlatform removeNamed: (x1) * ROPlatform add: (x2) * ROPlatform setCurrent: (x1) * ROPlatform new (x1) The last is only in a test ROPlatformTest>>testAddingAPlatform. I propose to modify... ROPlatform>>fontOrganizerClass self subclassResponsibility delete.... fontOrganizerClass instance-variable delete... ROPlatform>>fontOrganizerClass: from... ROPlatformTest>>testAddingAPlatform remove line... platform fontOrganizerClass: ROFontOrganizer subclasses anyOne. hope this helps, cheers -ben -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings

1 5

Issue 1077 in moose-technology: System complexity is not interactive
by moose-technology＠googlecode.com 13 Nov '14

13 Nov '14

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 1077 by damien.c...(a)gmail.com: System complexity is not interactive http://code.google.com/p/moose-technology/issues/detail?id=1077 The system complexity visualisation is not interactive: I don't get any fly-by-help nor can I click on rectangles to have details about the class. -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings

1 1

Issue 1070 in moose-technology: Group 'UI' depends on PPBrowser without loading it
by moose-technology＠googlecode.com 13 Nov '14

13 Nov '14

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 1070 by damien.c...(a)gmail.com: Group 'UI' depends on PPBrowser without loading it http://code.google.com/p/moose-technology/issues/detail?id=1070 Execute this in Pharo 3: (ConfigurationOfMoose project version: #development) load: 'UI' Then you can't open the World menu anymore. PPBrowser is missing. -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings

1 1

Issue 528 in moose-technology: Remove Category Importer
by moose-technology＠googlecode.com 12 Nov '14

12 Nov '14

Status: Accepted Owner: ---- Labels: Type-Defect Priority-Medium Milestone-4.3 Component-Famix Component-SmalltalkImporter New issue 528 by jannik.l...(a)gmail.com: Remove Category Importer http://code.google.com/p/moose-technology/issues/detail?id=528 With RPackage, Category importer is useless, We should remove it. They are some referecnes in examples in DSM.

1 6

Use of inFamix with Java
by James Foster 11 Nov '14

11 Nov '14

I’m trying to use Moose to analyze some C++ and Java code and will need some advice. First, I’ve tried to parse the Java code with inFamix and continue to get the error “The location of the project must be specified.” I’ve passed in as ‘-path’ every directory down to a Main.java file. James

2 1

Issue 1002 in moose-technology: The treemap builder should support multiple types of nodes
by moose-technology＠googlecode.com 02 Nov '14

02 Nov '14

Status: New Owner: ---- CC: alexandr...(a)gmail.com Labels: Type-Enhancement Priority-Medium Component-Roassal Milestone-5.0 New issue 1002 by tu...(a)tudorgirba.com: The treemap builder should support multiple types of nodes http://code.google.com/p/moose-technology/issues/detail?id=1002 TreeMaps are particularly useful to show leaf nodes within a nested parent nodes tree. For example, they can show classes within packages. They are less useful for showing only one type of nodes, like a class hierarchy given that the weight is only meaningful when applied to the leaf nodes. However, right now, we can specify nodes only with one block, weight with one block only and edges with another one block. This is less convenient. We should extend this to allow multiple sets of nodes. Consider this code: packages := RPackageOrganizer default packages select: [:each | each name beginsWith: 'AST']. classes := packages flatCollect: [:each | each definedClasses ]. ... builder weightBlock: [ :el | el isBehavior ifTrue: [ el linesOfCode + 1] ifFalse: [ 1 ] ]. builder nodes: (packages), (classes). builder nestingFromAssociations: ( (builder nodes select: [ :each | each isBehavior ]) collect: [ :each | (each) -> each package ]). builder drawOn: rawView . It would be better to have it like: builder weight: [ :el | el linesOfCode + 1] ]. builder nodes: classes. builder nodes: packages builder nest: classes in: [ :each | each package ]. builder drawOn: rawView . Note how nesting is defined following the same pattern as edges:from:to:, and how the weight is only applied to the next nodes. -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings

1 1

Issue 1087 in moose-technology: Migrate Overview Pyramid to RTView
by moose-technology＠googlecode.com 13 Oct '14

13 Oct '14

Status: New Owner: ---- Labels: Type-Defect Priority-Medium Component-Finder New issue 1087 by tu...(a)tudorgirba.com: Migrate Overview Pyramid to RTView https://code.google.com/p/moose-technology/issues/detail?id=1087 I removed Overview Pyramid from the MooseModel menu. It is still in the image. It would be great if anyone would want to refactor this. In doing so, you should use directly RTView and compose the boxes manually rather than going through the MondrianBuilder. -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings

1 2

how to handle generic methods in Famix 3.0
by Thomas Haug 12 Oct '14

12 Oct '14

Hi everybody, I hope my question is not off topic: I am currently trying to figure out how to describe generic methods in Famix 3.0 (for the .NET FamixGenerator) For example in Java you can write the following code. public class ClassWithGenericMethod { public static <TResult> TResult getTheGeneric(String resource) { return null; } public static <TValue> void useTheGeneric(TValue value) { System.out.println("value '"+value +"' type: "+value.getClass()); } If I run InFamix on this code I get an Famix file containing something like: 1 method: (FAMIX.Method (id: 24) (sourceAnchor (ref: 60)) (parentType (ref: 30)) (declaredType (ref: 33)) (name 'getTheGeneric') (signature 'getTheGeneric(_unknown_path::String)') (hasClassScope true) (isPublic true) (isPureAccessor true) (ATFD 0.00) (ALD 0.00) (CYCLO 1.00) (DR 0.00) (ICDO 1.00) (ICIO 1.00) (LOC 3.00) (LOCOMM 1.00) (LDA 1.00) (MAXNESTING 1.00) (NOAV 0.00) (NOOC 0.00) (NOPAR 1.00) (OCDO 0.00) (OCIO 0.00) ) But id 33 is not existing. 2 method: (FAMIX.Method (id: 25) (sourceAnchor (ref: 61)) (parentType (ref: 30)) (declaredType (ref: 28)) (name 'useTheGeneric') (signature 'useTheGeneric(_unknown_path::TValue)') (hasClassScope true) (isPublic true) (ATFD 0.00) (ALD 0.00) (CYCLO 1.00) (DR 0.00) (ICDO 1.00) (ICIO 1.00) (LOC 3.00) (LOCOMM 1.00) (LDA 1.00) (MAXNESTING 1.00) (NOAV 2.00) (NOOC 2.00) (NOPAR 1.00) (OCDO 0.00) (OCIO 0.00) ) (FAMIX.Parameter (id: 35) (name 'value') (parentBehaviouralEntity (ref: 25)) (declaredType (ref: 36)) (position 0) ) But id 36 is not existing. I am wondering if there should be something like ParameterizableMethod (like ParameterizableClass? Can anybody give me some clues? Thank you very much Thomas ----------- Thomas Haug Principal Consultant MATHEMA Software GmbH Anschrift: Henkestraße 91 91052 E r l a n g e n Telefon: 09131/8903- 0 Telefax: 09131/8903-55 E-Mail: thomas.haug(a)mathema.de Internet: http://www.mathema.de Handelsregister: HR B 8965, Fürth/Bayern Geschäftsführer: Michael Wiedeking Andreas Hanke

2 3

Issue 1076 in moose-technology: System complexity can't export as PNG
by moose-technology＠googlecode.com 09 Oct '14

09 Oct '14

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 1076 by damien.c...(a)gmail.com: System complexity can't export as PNG http://code.google.com/p/moose-technology/issues/detail?id=1076 When viewing the system complexity visualization, clicking on "Export as PNG" under the black triangle opens a debugger: ROAthensImageExporter has the sublcass responsability to implement exportViewAsPNG: -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings

1 4

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev September 2014