Moose-dev November 2012

moose-dev@list.inf.unibe.ch

23 participants
145 discussions

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.

11 years, 1 month

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.

11 years, 1 month

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.

11 years, 1 month

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.

11 years, 1 month

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

11 years, 1 month

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.

11 years, 1 month

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.

11 years, 1 month

Loading Hapax

by Hernán Morales Durand

Hello, I know that Hapax possibly isn't fully ported to Pharo, but running the Hapax tests causes my Moose 4.5 image to hang (I've loaded everything in the SqS Hapax repository). What image and package loading order should one use to load Hapax? I'm interested in the information retrieval part for natural language analysis, could that part be repackaged in its own package? Cheers, Hernán

11 years, 1 month

Issue 714 in moose-technology: VerveineJ does not produce correct values for classes in annotation instances

by moose-technology＠googlecode.com

Status: New Owner: ---- CC: anquetil...(a)gmail.com Labels: Type-Defect Priority-High Component-VerveineJ New issue 714 by tudor.gi...(a)gmail.com: VerveineJ does not produce correct values for classes in annotation instances http://code.google.com/p/moose-technology/issues/detail?id=714 Take a look at the example below: @XmlElement(name = "Time", required = true, type = String.class) protected Date time; The value of the third attribute of the annotation instance is the actual source code of the String class. Instead, it should be just the string 'String.class'. Ideally, we would get an actual reference, but the string would do for now.

11 years, 4 months

Issue 686 in moose-technology: Order in the Mondrian view DSL?

by moose-technology＠googlecode.com

Status: New Owner: ---- Labels: Type-Defect Priority-Medium New issue 686 by step...(a)stack.nl: Order in the Mondrian view DSL? http://code.google.com/p/moose-technology/issues/detail?id=686 The order in which the view script has to be build up is not very clear. This is to be documented in http://www.themoosebook.org/book/internals/mondrian/scripting {shape, interaction} < nodes < edges * Type-Review * Component-Mondrian

11 years, 5 months

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

Moose-dev November 2012