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
10 years
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
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
Issue 940 in moose-technology: In Pharo 2.0 the SpyWizard does not take notice of newly added packages. Possible solution: use RPackageOrganizer
by moose-technology@googlecode.com
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium
New issue 940 by w...(a)fastmail.fm: In Pharo 2.0 the SpyWizard does not take
notice of newly added packages. Possible solution: use RPackageOrganizer
http://code.google.com/p/moose-technology/issues/detail?id=940
Describe the problem: what do you get? what do you expect?
In Pharo 2.0 the SpyWizard does not take notice of newly added packages.
How to reproduce the problem: step by step if necessary
- load Spy into Pharo 2.0
- open for example the HapaoWizard and have a look at the packages
available. Close the wizard.
- add a new package to your image
- open the HapaoWizard again: the new package does not appear in the list
of available packages.
Possible solution:
Change
SpyWizard>>packagesList
^ (PackageOrganizer default packageNames select: #isString)
asSortedCollection: [ :a :b | a < b ]
to:
SpyWizard>>packagesList
^ (RPackageOrganizer default packageNames select: #isString)
asSortedCollection: [ :a :b | a < b ]
or perhaps:
SpyWizard>>packagesList
^ (SystemNavigation default packageOrganizerClass default packageNames
select: #isString) asSortedCollection: [ :a :b | a < b ]
--
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
10 years
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