Hi!
I am wondering why MooseElement needs a mooseID. By looking at the
sender of mooseID, I can see methods like:
MooseModel>>includes: anItem
anItem isNil ifTrue: [^ false].
^ self includesID: anItem mooseID
and MooseModel class>>ownerOf: element that makes use of mooseID. But
is this really necessary?
Just wondering...
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi Cyrille,
I saw that during your cleaning effort, you commented the york
variable from the method
TheRoot>>accessingUnknowVariable
york is indeed undeclared, but this is done intentionally because we
want to be able to test such situations :).
Cheers,
Doru
--
www.tudorgirba.com
"Speaking louder won't make the point worthier."
Hi Cyrille,
Thanks for cleaning the entity state and its usage.
This kind of work typically goes unnoticed, but it is so important for
keeping the infrastructure nice and tidy.
Just one note: when you do such core structural changes, please let
the others know what they should do to comply :)
Cheers,
Doru
--
www.tudorgirba.com
"What is more important: To be happy, or to make happy?"
Hi,
I made available a package to integrate Moose with the command line:
http://github.com/girba/automoose
The package consists of a shell script that given a set of src and a
base moose.image (in the res folder) it does:
- parse sources with inFusion and generate an mse file
- take the moose.image and run a number of smalltalk scripts
- produce a time-stamped tgz with the resulting image and the mse file
The package can also be directly integrated with Hudson.
Cheers,
Doru
--
www.tudorgirba.com
"Being happy is a matter of choice."
Hi Tudor,
I got an error when in a column or row there is one presentation that has an icon as title...
here an example:
| browser |
browser := GLMTabulator new.
browser
column: #one.
browser showOn: #one; using: [
browser list
titleIcon:[ MenuIcons windowIcon ];
display: [:x | 1 to: x] ].
browser openOn: 5
Regards,
Veronica
Hi!
As you may know, Mondrian offers additional interaction mechanisms.
The script below shows a system complexity, and by waving the mouse
over a node, clientClasses will be connected. When the mouse leaves
the node, the edges disappear.
-=-=-=-=-=-=-=-=-=-=-=-=
view shape rectangle
width: #numberOfAttributes;
height: #numberOfMethods;
linearFillColor: #numberOfLinesOfCode within: classGroup.
view interaction
action: #inspect;
whenEnteringUpdateNode:
[:node | view edges: {node} from: #yourself toAll: #clientClasses ]
withLayoutUpdate: false.
view nodes: classGroup.
view edgesFrom: #superclass.
view treeLayout
-=-=-=-=-=-=-=-=-=-=-=-=
This mechanism is useful I think, however, the block you provide in
#whenEnteringUpdateNode: should be error free. Else the image may hang
(this is a well known Morphic problem, I will work on it one day).
Do you like this view? Would it make sense to make it as default in
Moose? Any comment?
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hello,
Last week I had a error due to a strange behaviour: I had an instance
variable and an accessor to this instance variable. The instance variable is
instanciated at the initialization of the class. When the error occure, the
instance variable is not nil (when inspecting it from the debugger ). But,
when evaluating the accessor, it return nil.
This occure in the pharo 1.0 dev image. I test it this morning on a clean
image and on a click image with moose. It seems that the bug is specific to
moose. If you want to reproduce it:
Download the last version of Merlin from
www.squeaksource.com/DelaunayTmpStuffs.
run the method MerlinExamples class >> parametrizedMorphDropLists. it should
work correctly.
Now restart, load moose (load ConfigurationOfMoose, and evaluate
'ConfigurationOfMoose loadDefault') and then load Merlin from
'DelaunayTmpStuffs'.
It should raise an error and you should be able to see this strange
behaviour. From the debugger, evaluate 'self dropList' in MorphDropListPart.
After showing this bug to Marcus, it seems that something is not weel
compiled at one point: browse the method 'dropList' in dropListPart. Now,
click on 'view' and 'byte code'. The offset indicated is 10 whereas it
should be 15
