Hi folks. I am trying to script some distribution maps. For the moment I was
doing simple things with just two colors. Example:
^ (DistributionMap onContainers: (self listOfCorePackages
collect: [ :each | (PackageInfo named: each) ]) elements: #classes
properties: [:element | element hasUsedInstances = true] )
That show me classes with used instances with blue and the rest with red.
Now I want:
element hasUsedInstances = true -> blue
element instanceCount > 0 and: [hasUsedInstances = false] -> red
the rest (without instances) -> yellow
Forget about the colors, I don't care which color (although it would be
cool to be able to choose). What I don't know how to do is to define
multiple properties. And I cannot use the wizard, I have to do it by code ;)
Can someone help ?
Thank you very much in advance.
When I want to view the moose menu by right-clicking on a mondrian element,
I have to add this to the script:
view interaction menuMorphBlock: [ :element | element
But, when I also want to have my own specific action:
view item: 'browse code' action: [:element | UIManager
default edit: element sourceCode].
this last one does not appear in the menu.
Is there any way to do that (to have both the moose menu and my own actions
in a same frame)?
I have a browser, which is a GLMTabulator.
I would like to dynamically change its number of rows.
Is there a way to do that?
My idea was:
Every time I want to update my browser, I delete all existing rows and
rebuild the ones i want. Is it possible?
What I did for the moment:
renamed all the methods from EntityState with the convention of a
dictionary (propertyAt: , cacheAt: ,
attributesAt: ). We kept the old ones as deprecated.
I kept all previous methods as 'deprecated'. So normally, If I did
that well, if your code is still using the old entityState API, you
should have a 'deprecated' message re-directing you to the new API.
Hi Moosers. I am doing little experiments to export/serialize big graph of
objects using ImageSegment. I though that MooseModel was a good candidate.
And I even remember Simon's wishes for copying them. But I have a couple of
1) Which is the bigger autogenerated MooseModel I can get to test? For the
moment I am evaluating "MooseModel installDefaultModels". and then I export
"MooseModel root". Is there a bigger one I can use? how ?
2) How is the root or any other MooseModel normally exported? Which
methods? which technology ? Can you give me an example of the standard way
to export/serialize/copy a MooseModel ? The only thing I saw is MooseModel
class >> export: aModel to: aStream
I just open a file and send it as Stream?
3) Suppose that I copy/export somehow a MooseModel (suppose the root) to a
file. I take another Moose image, I load the file, objects are alive again
and I replace MooseModel rootModel with the new object. How do I know if the
copy/export worked correctly ? If I do it in the same image, I can have
both, but how can I compare them to be sure everything was done ok ? method
#= has no sense as it will use Object with is #==. So...any idea to know if
the MooseModel I export and load again with ImageSegment is really working
I want to test exporting and loading these MooseModel with different
technologies but I need a way to know if the resulted object is correct or
Ahhh please, cc' me in the mail as I am not sure I receive emails from this
Thanks for any hints.
I need other clarifications on the topic of how to handle Java models in Famix.
How should we handle nested classes?
Right now, it appears infusion imports nested classes directly in a namespace, and loses the information about the parent class.
For example, anonymous classes are imported but we get no clue about the defining context, so it's pretty much useless.
Given that namespaces, but also classes and methods can contain types in Famix, why don't we use this attribute?
But then, how to access the namespace of a nested class?
Here is a brief and good overview of the different types of nested classes in Java:
I know that the requirements for mooseName are not completely explicit, however one condition which seems pretty interesting but is not completely enforced right now is that a moose name should be unique.
This is not the case for signatures from languages which provide overloading, like Java.
With infusion for example, SampleClass.method1(int) and SampleClass.method1(String) share the same mooseName SampleClass.method1()
Worse, I have seen cases where you can confuse getter and setter
void SampleCase.attribute(String attr) -> SampleCase.attribute()
String SampleCase.attribute() -> SampleCase.attribute()
Also since the moose finder uses #mooseName to format entities, this shows in the Moose finder.
Maybe we should adopt the convention of using the real signature in the moosename.
I am looking into AST-Semantic. I found the one from the http://www.squeaksource.com/rb
However, this one does not have the methods:
These are needed for the SmalltalkImporter.
Am I looking at the wrong repository, or are these methods just missing?
"When people care, great things can happen."
I am trying to load Glamour into Squeak 4.1. but run into a problem
completing the loading.
1) Use ConfigurationOfGlamour-tg.38.mcz (21 May 2010) in Squeak 4.1
trunk (or Squeak 4.2alpha updated)
3) A warning pops up
This package depends on the following classes:
(I am not told which package ).
Question: Where do I find the class Announcer and Announcement?
Thank you for the answer in advance.
P.S. I tried to ignore this warning and proceeded. It loads quite a
lot but the examples do not work because the class GLMTabulator is not
GLMTabulator seems to be a central class. Maybe I can load it through
other means. I do not necessarily need everyting at this moment. I
would just like to do a few simple examples to explore a net of