Hi Tudor,
I was loading Glamour in a new core image (1.1) and I got this message:
----------------
This package depends on the following classes:
PluggableShoutMorph
You must resolve these dependencies before you will be able to load these definitions:
GLMPluggableShoutMorph
GLMPluggableShoutMorph>>announcer
GLMPluggableShoutMorph>>selectFrom:to:
-----------------
The shout package is missing in the configuration of glamour.
regards,
Veronica
Hi all,
I am looking at srcML, and I see that it make XML files from Java and C++ source code.
Since we use it for C source code, it should be possible to make it works with C++ and java.
This strategy allows us to not us a special tool for each language.
What do you think about it ?
Cheers
---
Jannik Laval
Hi!
I have been looking for a method that give me the depth of the class
hierarchy under a particular class. Doru pointed me the method
FAMIXClass>>maxHierarchyOfChildren. But I was not able to make it work.
I imported Morph into moose, and try to send #maxHierarchyOfChildren
to the famix representation of Canvas or Morph. It simply loops.
#maxHierarchyOfChildren and its unique caller (#ahh) are not tested.
I try to look at the implementation of maxHierarchyOfChildren, but it
was a bit obscure to me (almost midnight here :) I decided to write my
own:
-=-=-=-=-=-=-=-=-=-=-=-=
FAMIXClass>>subclassHierarchyDepth
<property: #SHD longName: 'Subclass hierarchy Depth' description:
'The depth of the class hierarchy for which I am the root'>
^ (self directSubclasses isEmpty or: [ self isStub ])
ifTrue: [ 0 ]
ifFalse:
[ | currentMaxDepth|
currentMaxDepth := 0.
self
subclassesDo:
[ :aClass | currentMaxDepth := currentMaxDepth max: aClass
subclassHierarchyDepth ].
1 + currentMaxDepth ]
-=-=-=-=-=-=-=-=-=-=-=-=
Any one can comment on maxHierarchyOfChildren? Does it make sense to
remove maxHierarchyOfChildren and add my subclassHierarchyDepth?
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi!
I have a question regarding browseMeta. In the Map depicted in the
lower pane of the browser, I see two distinct hierarchies, where
FAMIXEntity and MooseEntity are the roots, respectively. However,
FAMIXEntity is a subclass of MooseEntity. Why is there two distinct
hierarchies then?
I haven't checked at a deeper level. I am just wondering.
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
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
