Some people suggested trying moose for analysis of SAS programs, and I'm
trying to figure out where to start with the meta-modeling.
SAS is not object oriented, though parts of it could be imagined to be.
The main SAS code contains blocks of statements that begin with DATA or
PROC; each block could probably be thought of as a function--to be
precise, the application of a function.
If I want to make some new models, where do I start? FM3? FAMIX?
elsewhere? The 4.0 release announcement says FM3 and FAMIX3 are both
implemented in Fame, so maybe start with Fame? I've read some
documentation, but I can't tell.
My inspiration for the project is understanding how some SAS datasets
were produced. I have a system that creates numerous datasets, which
feed into later datasets, etc. This is split at least across a couple
of program files and it's really too complicated to keep in the brain.
If I get ambitious it would also be useful to trace where particular
variables came from, in the sense of both datasets and individual
expressions.
The only thing resembling a SAS parser I've run into (except for SAS,
which is closed source) is a Perl module, and it looked relatively
primitive. I've been using PetitParser, and at the point I started
thinking about what it would parse results into.
Thanks for any pointers.
Ross Boylan
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] )
render
open.
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.
Mariano
Hello,
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
mooseMenuMorph ].
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)?
Hi all,
i just spotted that in the Moose Panel "all famixclass" appear 2 times (check the attachment)
I loaded Moose evaluating:
Gofer new
squeaksource: 'Moose';
package: 'ConfiguationOfMoose';
load.
(Smalltalk at: #ConfigurationOfMoose) perform: #loadDefault
into a Pharo-1.1-11400-rc2.
Then i imported an MSE file generated with inFusion 7.2.10.
It happen also installing the sample models.
Should i open an issue?
Mariano
We want to use Moose to get information about Pharo. We plan to define a set of views, queries...
to help us drive the quality of Pharo releases.
Now what I would love to have is a distribution map showing the unused classes,
the classes having a lot of instances....
Would it be possible for you do package the logic of the analysis you did so that we can use it in Moose?
We can talk about that friday.
Stef
Hello,
I implemented a tool that enable to make a kind of demo of Moose: you launch
it on a mooseModel, then select some moose-tools you want to apply on this
model, and all those tools are then group in a report.
Concretly, it's an Arki report configurable with a Wizard.
This MooseDemoReport is available at: www.squeaksource.com/MooseDemoReport.
To test it, have a look at: MooseDemoWizard class >> on:
If you want to use it, feel free to implement your own 'Concerns' in the
MooseDemoReport package and save it in the squeaksource repository, so that
everyone can then use them.
Call for Submissions
ICSM 2010 Tool Demonstrations Track
26th IEEE International Conference on Software Maintenance
September 12-18, 2010, Timisoara, Romania
http://icsm2010.upt.ro/calls/tool-demos
--------------------
Important dates:
- Submission: July 5, 2010
- Notification: July 27, 2010
- Camera-ready: August 2, 2010
--------------------
The goal of this track is to provide tool demonstrations on topics
related to software maintenance and evolution:
- Experience reports
- Techniques, methods and processes:
- to facilitate and support software maintenance
- to analyze and comprehend software systems
- to specify, design, implement and test evolvable systems
- Maintenance and evolution of multi‐language, multi‐platform and,
network-centric systems
- Model driven software maintenance and evolution
More information about the call for submissions can be found at:
http://icsm2010.upt.ro/calls/tool-demos
Tool Demonstrations Co-Chairs
Tudor Gîrba and Yann-Gaël Guéhéneuc
--
www.tudorgirba.com
"When people care, great things can happen."
Before posting this issue on pharo, I would like to check that I'm not the only one affected.
On my computer, some tests of Moose-Algos-Graph are failing since we went to Pharo 1.1. Same things for our internal test server (they do not appear on hudson though, maybe because hudson does not test moose-algos?)
This was really strange until I noticed that some data structures used by MooseAlgos were missing their trait declaration.
I have something like that in monticello:
MOGraphNode subclass: #MABfsNode
uses: MATEdgeNode - {#previousEdges. #from:edge:}
instanceVariableNames: 'nextEdges firstDepth'
classVariableNames: ''
poolDictionaries: ''
category: 'Moose-Algos-Graph'
But when loading the package, the definition becomes:
MOGraphNode subclass: #MABfsNode
instanceVariableNames: 'nextEdges firstDepth'
classVariableNames: ''
poolDictionaries: ''
category: 'Moose-Algos-Graph'
Notice that the trait declaration is missing, but it seems to only happen when the declaration contains an operation like #-
A declaration without operator loads fine:
MOGraphNode subclass: #MADijkstraNode
uses: MATEdgeNode
instanceVariableNames: 'pathWeight previousEdges nextEdges previousNodes'
classVariableNames: ''
poolDictionaries: ''
category: 'Moose-Algos-Graph'
Can anyone confirm? Because it seems like a strong bug and I'm surprised nobody noticed it before.
--
Simon
Reminder: deadline for submission is 5th of July.
CALL FOR CONTRIBUTIONS
FAMOOSr 2010 - 4th Workshop on FAMIX and Moose in Reengineering
http://www.moosetechnology.org/events/famoosr2010
Co-located with ICSM 2010, Timisoara, Romania
http://icsm2010.upt.ro/
We solicit experience reports and position papers (2-4 pages, IEEE format). Experience reports will be expected to discuss meta-modeling and software analysis using, but not limited to, FAMIX or Moose. Position papers will be expected to describe new directions and challenges for software analysis infrastructures, like FAMIX or Moose.
Papers may address issues along general themes, including but not limited to:
- Analysis specific meta-models for evolution data, dynamic traces, bug entries, etc...
- Meta-modeling in reengineering tools
- Visualization techniques.
- Analysis techniques: clustering, data mining, machine learning, pattern matching, probabilistic approaches, etc...
- Mechanisms for tool composition and rapid tool prototyping.
- Reusability of research: making research results and tools available to and reusable by the community.
- Persistency and manipulation of models and meta-models.
Submissions are not limited to FAMIX and Moose or to their active users. We welcome any related ideas.
During the workshop, authors are expected to present their ideas using a short format, lasting 3 to 7 minutes, in order to spawn vivid discussions between participants. Presentations with demos are also warmly welcomed (and may be given 10 minutes). More information about this format can be found at: http://moose.unibe.ch/events/famoosr2008/presenterskit
Submissions should be made via Easychair at
http://www.easychair.org/conferences/?conf=famoosr2010
Important dates
- submission: July 5
- notification: July 19
- workshop: September 17
Organizers:
- Simon Denier, INRIA Lille, France
- Mircea Lungu, University of Lugano, Switzerland
