Moose-dev January 2013

moose-dev@list.inf.unibe.ch

16 participants
121 discussions

Issue 621 in moose-technology: writing tests for removeMethod

by moose-technology＠googlecode.com

Status: Accepted Owner: ---- CC: cy.delau...(a)gmail.com Labels: Type-Defect Priority-Medium RPackage New issue 621 by stephane...(a)gmail.com: writing tests for removeMethod http://code.google.com/p/moose-technology/issues/detail?id=621 writing tests for "The bug appeared when removing two extensions methods (from the same extending package) for a same class. in RPackage >> removeMethod: , when removing an extension method, we were telling the organizer to remove the extending package for the class concerned. This was wrong, because even if one extension from this package has been removed, some others can still exist. And the organizer should keep the this package as extending package for the class. So removing the first extension method worked correctly, but then removing a second or more methods from the same package was raising some errors "

10 years, 5 months

Issue 527 in moose-technology: Add ModelInfo to hold extra information in MSE

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Enhancement Priority-Medium Component-MooseCore Milestone-4.3 New issue 527 by tudor.gi...(a)gmail.com: Add ModelInfo to hold extra information in MSE http://code.google.com/p/moose-technology/issues/detail?id=527 We should add a special MooseModelInfo entity that can be serialized in MSE. Like this we would have a backward compatible solution for storing extra information in MSE such as: - source language - importer version - metamodel version - importing date - source version I will give it a try for 4.3

10 years, 5 months

Issue 771 in moose-technology: Problem with tabs in Glamour

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 771 by santiago...(a)gmail.com: Problem with tabs in Glamour http://code.google.com/p/moose-technology/issues/detail?id=771 Running the following script: | browser | browser := GLMTabulator new. browser row: [ :r | r column: #columnA; column: #columnB ]. browser transmit to: #columnA; andShow: [ :a | a list display: [" :model | "#('Value 1' 'Value 2' 'Value 3' 'Value 1') ] ]. browser transmit from: #columnA; to: #columnB; andShow: [ :a | a list titleIcon: GLMUIThemeExtraIcons glamorousBrowse; display:#('data A' 'data B' 'data C'). a text titleIcon: GLMUIThemeExtraIcons glamorousAccept; display:'something'. a text titleIcon: GLMUIThemeExtraIcons glamorousAdd; display:'add something'. ]. browser openOn: MooseModel root allModels anyOne. after selecting a value in columnA the columnB is opened in the last tab (the one with the glamorousAdd icon). Instead it must be opened in the first tab (the one with the glamorousBrowse icon). Using text instead of icons, it works.

10 years, 5 months

Issue 658 in moose-technology: write a test for MooseMenu entries

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 658 by jannik.l...(a)gmail.com: write a test for MooseMenu entries http://code.google.com/p/moose-technology/issues/detail?id=658 We need a test that take all entries in Moose Browser and test them, to avoid DNU and other kind.

10 years, 5 months

Issue 728 in moose-technology: VerveineJ places methods in the wrong classes

by moose-technology＠googlecode.com

Status: New Owner: ---- CC: stephane...(a)gmail.com, anquetil...(a)gmail.com, usman.bh...(a)gmail.com Labels: Type-Defect Priority-Critical Component-VerveineJ New issue 728 by tu...(a)tudorgirba.com: VerveineJ places methods in the wrong classes http://code.google.com/p/moose-technology/issues/detail?id=728 For some reason, some methods are placed in the wrong classes. I did not manage to identify a standalone case, but it looks like if we have a case like below: public class A { ... public void m() { ... x() } } public class B { public void x() { ... } } public class C { ... } we sometimes get x as belonging to class C instead of B. The interesting part is that the invocation will go from A::m() to C::x(). This is a critical issue that stops us from using VerveineJ because the information is too unreliable.

10 years, 5 months

Issue 704 in moose-technology: One click image has a squeak icon

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 704 by alexandr...(a)gmail.com: One click image has a squeak icon http://code.google.com/p/moose-technology/issues/detail?id=704 Apparently, the icon of the one-click image available form Moose;s jenkins is the Squeak one.

10 years, 5 months

Issue 837 in moose-technology: ROCircle not constrained to equal dimensions

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 837 by google....(a)ben.coman.com.au: ROCircle not constrained to equal dimensions http://code.google.com/p/moose-technology/issues/detail?id=837 Currently ROCircle acts more like a hypothetical ROEllipse, since it is not constrained to force dimensions to be equal. The following might be a worthwhile test case... --- | rawView element1 element2 | element1 := (ROElement on: '1' ). element1 + ROCircle. element1 width: 200; height: 100. self assert: ( element1 height = 200). element2 := (ROElement on: '2' ). element2 width: 200; height: 100. element2 + ROCircle. "Swapped order with above line" self assert: ( element2 height = 200). "Should be true. Currently not." "optional - following not part of test - just visual feedback" rawView := ROView new. rawView add: element1. rawView add: element2. ROVerticalLineLayout on: rawView elements. rawView open. --- The first assert can be made to work by adding the following... ---- ROCircle>>extent: anExtentPoint | max | max := anExtentPoint x max: anExtentPoint y. extent := max @ max. next extent: anExtentPoint --- The second assert, I'm not sure yet about resolving the fail.

10 years, 5 months

Re: Issue 435 in moose-technology: Using RoelTyper for a better precision of method invocation

by moose-technology＠googlecode.com

Updates: Labels: Component-SmalltalkImporter Comment #4 on issue 435 by tudor.gi...(a)gmail.com: Using RoelTyper for a better precision of method invocation http://code.google.com/p/moose-technology/issues/detail?id=435 It seems that RoelTyper does not work for all classes. Try this code for getting the classes that raise an error: classes := Dictionary new. Object withAllSubclassesDo: [:each | [(TypeCollector typeInstvarsOfClass: each )] on: Error do: [:error | classes at: each put: error ]]. classes inspect

10 years, 5 months

Issue 516 in moose-technology: System Complexity displays more than the classes in the group

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 516 by tudor.gi...(a)gmail.com: System Complexity displays more than the classes in the group http://code.google.com/p/moose-technology/issues/detail?id=516 Currently, the algorithm to identify the hierarchies does not limit the result to the current class group, but it takes all the subclasses of the superclass. This means that if you have a group with Object inside, you will end up with a system complexity with all classes.

10 years, 5 months

Issue 526 in moose-technology: Add explicit Interface in Famix

by moose-technology＠googlecode.com

Status: New Owner: tudor.gi...(a)gmail.com Labels: Type-Enhancement Priority-Medium Milestone-4.3 New issue 526 by tudor.gi...(a)gmail.com: Add explicit Interface in Famix http://code.google.com/p/moose-technology/issues/detail?id=526 We should have a FAMIXInterface.

10 years, 5 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev January 2013