Issue 923 in moose-technology: EyeSee red-square-of-death from ESValueLabelDecorator>>chooseNonOverlappingValues
by moose-technology@googlecode.com
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 923 by benjamin...(a)gmail.com: EyeSee red-square-of-death from
ESValueLabelDecorator>>chooseNonOverlappingValues
http://code.google.com/p/moose-technology/issues/detail?id=923
ESValueLabelDecorator>>chooseNonOverlappingValues has the line...
chosenValues add: (self values minValue: [:each | each value]).
but minValue: injects (Float infinity) so that if 'self values' is empty
then (Float infinity) is added to choseValues, which later are #rounded
causing an error in the Morph drawing and subsequent RSOD for the EyeSee
morph.
I am not sure if I've done something wrong that causes 'self values' to be
empty, but in any case, this should not kill the Morph.
Just for further information, here is the triggering code...
browser transmit from: #navigationtree; to: #attributes; andShow:
[ :a |
a eyesee
title: 'Optimize' ;
diagram:
[ :renderer :input |
renderer scatterplot
diagramTitle: '@', input absorbedLoad asString , 'kW' ;
x: #ratedOutput ;
y: [ :m | m powerLossForAbsorbedLoad: input absorbedLoad ] ;
valueAxis ;
addXDecorator: ESValueLabelDecorator new ;
models: (LEKCatalogMotor catalog values sort: [ :m1 :m2 | m1
ratedOutput < m2 ratedOutput ]).
].
where if in a Workspace I do...
models:= (LEKCatalogMotor catalog values sort: [ :m1 :m2 | m1
ratedOutput < m2 ratedOutput ])'.
models collect: [ :m | m ratedOutput -> m powerLossForAbsorbedLoad: 24
] explore
...then all the data looks okay.
--
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
9 years, 4 months
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 "
9 years, 4 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.
9 years, 4 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.
9 years, 4 months