Hi,
To show how Moose can support the analysis of various data sets, I am looking for a case study containing a complex data structure that does not represent a software system, and a set of questions associated with it. Ideally, the data should be freely available and it should contain a set of entities with various properties and various relationships with other entities.
Anyone has any idea regarding such a case study?
Cheers,
Doru
--
www.tudorgirba.com
"There are no old things, there are only old ways of looking at them."
Hi moosers
I would like to know if you are interested in Moose?
Why because the comments are not good.
Now this is simple either we let moose decay (I can focus on Pharo easily) or we do something
Now I should know what you can do and energy you can put on the table because there is little use
we get a new engineer and postdoc (because if the core is not clean than nobody can learn from it).
So
Plan A- build a roadmap and do it (I can probably work every two evenings on it for a month).
Right now (this evening we log on chat and we fix) these two
allPropertySelectors
is used
allDeclaredProperties
is used
FamixCore class comments
Plan B - I focus only on pharo (because I cannot do both especially right now).
But I should know because we are hiring a new engineer and a new postdoc for moose and without a community effort
I do not see the point.
Stef
Hi,
Doru has introduced Moose to my local developer group. This one hour
presentation through Skype was recorded and you can watch it here:
http://vimeo.com/29338546
Laurent
Hi,
I created a small infrastructure for building scripting editors, such as Mondrian Easel.
You can find it here GLMScriptingEditorTemplate. This offers basically three panes:
- one for the script
- one for the set of input variables
- one for the preview once you accept the script
Currently, there are two subclasses:
- GLMMondrianEasel - the classic Mondrian Easel in a new form
- GLMEditor - an editor for glamour browsers
You can use this for all sorts of tasks. For example, we can create an GLMEyeSeeEditor. Or you can use it as a testbed for other APIs you might want to use for scripting.
Cheers,
Doru
--
www.tudorgirba.com
"Some battles are better lost than fought."
Status: New
Owner: ----
Labels: Type-Defect Priority-Medium Component-Glamour Milestone-4.4
New issue 542 by tudor.gi...(a)gmail.com: Completion in Glamour text
presentation for Smalltalk
http://code.google.com/p/moose-technology/issues/detail?id=542
The Glamour TextPresentation for Smalltalk should offer completion as well.
HI!
I need some help to show a new property on Moose Panel. For exemple I create
a new method named *newMethod* and I want to compute a number named *
mynumber* (this just a logic fo problem).
Now I need to show this number on Moose Panel like a property, but this
property is not avaiable on the mse file ( I catch it that, in general,
properties showed on Moose Panel have some reference tag on mse file such as
#LOC, #).
So how I can show *mynumber*, computed on my *newMethod*, as a property on
Moose Panel?
Julio
--
View this message in context: http://forum.world.st/Show-a-property-on-Moose-panel-tp3827991p3827991.html
Sent from the Moose mailing list archive at Nabble.com.
I wanted to address the following issue
Look for senders of:
propertySignature
<property: #XXX longName: 'YYY' description: 'ZZZ'>
And replace with:
propertySignature
<MSEProperty: #propertySignature type: #Number>
<MSEComment: 'ZZZ'>
but I do not understand it :(
numberOfMessageSends
<property: #MSG longName: 'Number of message sends' description:
'The number of message from a method'>
^self
lookUpPropertyNamed: #MSG
computedAs:
[self mooseModel isSmalltalk
ifTrue:
[| parser |
parser := VisualWorksParseTreeMetricCalculator new.
parser processMethod: self usingImporter: nil inModel: nil.
parser numberOfMessageSends]
ifFalse: [-1]]
numberOfMessageSends
<MSEProperty: #numberOfMessageSends
<MSEComment: 'Number of message sends' description:
'The number of message from a method'>
^self
lookUpPropertyNamed: #MSG
computedAs:
[self mooseModel isSmalltalk
ifTrue:
[| parser |
parser := VisualWorksParseTreeMetricCalculator new.
parser processMethod: self usingImporter: nil inModel: nil.
parser numberOfMessageSends]
ifFalse: [-1]]
How does the system know after that the property is linked with #MSG if MSG is not part
<property: #MSG longName: 'Number of message sends' description: 'The number of message from a method'>
Why do we duplicate the method selector?
why do we create comment as a separate entity. To me it looks like we are looking for complicated queries after.
I still do know how I can get a method containing two tags in one query.
What is the rationale? Why having a comment directly in would be a bad idea.
So guess what? I will wait because fixing the 122 left.
Stef
We have:
-------
MooseEntity is an abstract entity. Entities should subclass this class.
The state instance variable provides a mechanism for extending the state of entities.
Proposition:
----------
MooseEntity is an abstract class that refines MooseElement. Model entities should be instances of subclasses this class.
MooseEntity provides way to add state for model extensions as well as meta information (property and navigation).
For example a package can extend an entity to add more state and such extension should be only visible when the package is loaded.
Any MooseEntiy can extended with property that is described using the FAME meta model.
Here is an example: FAMIXAttribute defined the property AHNL as follow using the pragma
<property:longName:description:>
FAMIXAttribute>>hierarchyNestingLevel
<property: #AHNL longName: 'Attribute hierarchy nesting level'
description: 'The hierarchy nesting level of an attribute.'>
^self
lookUpPropertyNamed: #AHNL
computedAs: [self belongsTo hierarchyNestingLevel]
In addition, any MooseEntity can also be annotated with navigation declarations (which are used by the environment to propose navigation options to the user).
For example, the class FAMIXClass can define the navigation 'Accessor Methods' as follows
FAMIXClass>>accessorMethodsGroup
<navigation: 'Accessor methods'>
^ FAMIXMethodGroup withAll: (self accessorMethods) withDescription: 'Pure accessors in ', self name
The pragma <navigation:> declares that the method accessorMethodsGroup is the method to invoke to get the associated navigation.
The method navigationSelectors (see below) returns the list of methods declaring navigation of a given MooseEntity.
Finally, MooseEntity provides the possibility to add simple annotations (we call properties to avoid clash name with Java annotations),
to any moose model element. For example, a new information can be added to any model entity and it should be accessible. Like for example
a comment. Note that such a solution does not use FAME based description and as such will not appear when we will query the declared properties.
propertyNamed: name
propertyNamed: name put: value
Have a look at the test testProperty for an example of property use.
Some API:
description
returns the description (FAME instance) described the receiver.
allDeclaredProperties
return the properties (FAME instances) that describe the receiver. The properties are defined using <property:longName:description:>.
navigationSelectors
Return the list of methods that support the receiver navigation.
For example FAMIXClass instance can be navigated via #(#outgoingInvocationsGroup #allExternalMultiplications #invokedClasses #allExternalDuplications #clientClasses #invokingClasses #allMultiplications #allInternalDuplications #abstractMethodsGroup #providerClasses #allInternalMultiplications #accessorMethodsGroup #allDuplicatingClasses #incomingAccessesGroup #subclassHierarchyGroup #superclassHierarchyGroup #methodsGroup #withSuperclassHierarchyGroup #withSubclassHierarchyGroup #classes)
Try: FAMIXClass allInstances first navigationSelectors.
allPropertySelectors
Return a dictionary with all properties of the entity, including metamodel properties, metrics, and navigation groups.
Keys are abstract names of properties, values are implementing selectors.
for example: #ATFD -> #numberOfAccessesToForeignData means that ATDF is computed by invoking the method #numberOfAccessesToForeignData.
The state instance variable provides a mechanism for extending the state of entities.
so using MSEProperties how does the system links AFFC to this method?
afferentCoupling
"Afferent coupling for a class group is the number of classes that depend upon this class group"
<property: #AFFC longName: 'Afferent Coupling' description: 'Afferent Coupling of a class group'>
| cgClasses cgTypes |
cgClasses := self allClasses select: [:c | c isInstanceSide].
cgTypes := cgClasses flatCollect: [:c | c allRecursiveTypes].
^ (cgClasses flatCollect: [:aClass | aClass invokingClasses select: [: c | (cgClasses contains: [:each | each = c]) not and: [(cgTypes contains: [:each | each = c]) not and: [c isInstanceSide]]]]) asSet size