FAMIXClass>>outgoingAccesses
by Alexandre Bergel
Dear List,
I produced a mse 3.0 file for Swing. Loading it in PhaMoose produces
an error. #outgoingAccesses is sent to a famix class.
Does it not make sense to ask a class for it outgoing accesses ?
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
13 years, 10 months
moose finder
by Tudor Girba
Hi,
I am happy to announce that with the great help of Jorge, we now have
a first working version of a Moose Finder based on Glamour. Some of
the features:
- you get a menu for each item you select in the group view or in the
entity view. This menu is rendered based on the menuItem:category: or
menuItem: pragmas.
- in the group view you can search for your entities using Smalltalk.
For example, "each numberOfMethods > 1" applied on classes will get
you the classes that have more than 1 method. There is a known issue
consisting in the selection not being shown on the current pane.
However, you do get the selection on the next pane.
- in the Editor pane you get an experimental editor based on Magritte.
The editing does not quite work yet, but you get an idea of all
properties.
- in the Evaluator pane, you get the option of writing a script whose
result can be spawned on the next pane. For example, if opened on the
group of classes, "self flatCollect: #methods" will return all the
methods of these classes. To get it in the next pane you have to
select it and press Apple+o. There is a known issue in that every time
you change something, you have to press Apple+s to tell Morphic that
something changed.
- For a FAMIXClassGroup, you also get a Complexity tab
- For a FAMIXClass you also get a Blueprint tab
To give it a try, just call "openInMoose" on your favorite model, or
Moose object. Feedback is more than welcome :).
Of course, you should get the latest versions of Moose-Finder and
Glamour, but probably best would be to update the complete Moose with:
ScriptLoader loadLatestPackage: 'MooseLoader' from: 'http://www.squeaksource.com
'.
(Smalltalk at: #MooseLoader) load
Cheers,
Doru
--
www.tudorgirba.com
"There are no old things, there are only old ways of looking at them."
13 years, 10 months
loading configurations
by Tudor Girba
Hi,
Over the past couple of days I worked on some more detailed
dependencies between Moose packages in Pharo. The generic code for
expressing and loading dependencies is based on the work of Lukas and
Jorge (Gofer and Flair from http://source.lukas-renggli.ch). In the
process we created a small DSL for expressing dependencies.
To get an idea, you can load the Moose distribution via:
MooseLoader load.
There is only one small problem in that Famix-Smalltalk just does not
want to load for some reason still to be identified. Other than that,
you can now inspect the graph of dependencies via:
MooseLoader all.
I attached here a Mondrian visualization of the dependencies. With
red, I marked the packages that have newer versions in Monticello. If
you load MondrianPaintings, you can also get the visualization via:
MOSmalltalkPaintings new viewFlairLoadable: MooseLoader all
Cheers,
Doru
--
www.tudorgirba.com
"Being happy is a matter of choice."
13 years, 10 months
loadRio is not correct
by stephane ducasse
loadRIO
"self loadRIO"
| instClass |
instClass := self environment at: #Installer ifAbsent: [self new
installingInstaller].
(Smalltalk at: #Rio ifAbsent: [ instClass ss project: 'Rio'; install:
'Rio-Kernel'; install: 'Rio-Grande'. ]).
self new installingInstaller looks suspicious to me.
Stef
13 years, 10 months
Re: [Pharo-project] [OT] Mondrian question
by Tudor Girba
Hi Mariano,
Mondrian is an engine for scripting visualizations of arbitrary
models. You start from a set of objects and you specify how you want
to display them.
Instead of going for hardcoded scripts, I suggest taking a look at the
scripting capabilities. Take a look here for an example (although the
example is for VW it largely works the same in Pharo):
http://moose.unibe.ch/tools/mondrian/tour
So, to answer your questions:
1) yes, you just have to connect the proper nodes with the desired edges
2) yes, you can specify exactly what objects you want to be displayed
Please let us know if you get more questions.
Cheers,
Doru
p.s. I think best would be to continue the conversation on the moose-dev(a)iam.unibe.ch
mailing list.
On 30 Jul 2009, at 15:43, Mariano Martinez Peck wrote:
> First of all, let me know if there is a better place to ask
> questions related to Mondrian.
>
> I am preparing my ESUG presentation and I am a bit lazy to some UML
> diagrams. I would like to do a reverse engineer of my code. The main
> problem is that most (if not all) UML software are with "java style"
> using () in methods and you cannot import smalltalk code. So, I want
> to give Mondrian a try.
>
> I loaded it into Pharo and draw the classes I need, using something
> like this:
>
> MOReadme new umlFor: self myClassesToDraw
>
> The thing is that only "inherits" relationship is drawn. Now I wonder:
>
> 1) can I draw by hand associations and dependencies between classes ?
>
> 2) Is there a way to show only some methods instead of ALL of them ?
>
> Thanks,
>
> Mariano
> _______________________________________________
> Pharo-project mailing list
> Pharo-project(a)lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
--
www.tudorgirba.com
"It's not how it is, it is how we see it."
13 years, 10 months
a Pharo Glamour Bug
by Laval Jannik
Hi Doru,
I just load the latest Glamour on the latest Pharo-Dev (10388).
And there is a bug on GLMMorphicRenderer>>renderPane:
On the line:
---
container
addMorph: ((self renderPresentationsOf: aPane)
adoptPaneColor: container paneColor)
frame: (0 @ 0 corner: 1 @ 1).
---
RectangleMorph does not understand #addMorph:frame:
You can reproduce the bug with examples in GLMMorphicExamples.
Cheers
---
Jannik Laval
PhD Student - Rmod Team - INRIA
Certified Project Management Associate (IPMA)
http://www.jannik-laval.eu
http://rmod.lille.inria.fr
---
13 years, 10 months
Call for Contributions: FAMOOSr 2009 (with WCRE 2009)
by Simon Denier
CALL FOR CONTRIBUTIONS
FAMOOSr 2009 - 3rd Workshop on FAMIX and Moose in Reengineering
http://moose.unibe.ch/events/famoosr2009
Co-located with WCRE 2009, Lille, France
http://web.soccerlab.polymtl.ca/wcre2009/
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. 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=famoosr2009
Important dates
• submission: August 28
• notification: September 18
• workshop: mid October
Organizers:
• Simon Denier, INRIA Lille, France
• Tudor Girba, University of Bern, Switzerland
--
Simon
13 years, 10 months
google code issues
by Tudor Girba
Hi,
I went today over all the issues reported on:
http://code.google.com/p/moose-technology/issues/list
With the help of Adrian Lienhard I refactored a bit the site. Among
others I added:
- Milestone-4.0alpha -> to be tackled for the alpha release (hopefully
in the next 1-2 weeks)
- Milestone-4.0 -> to be tackled for the stable release (end of August)
Also, to close an issue, you should choose between the following labels:
Fixed = Developer made requested changes
Invalid = This was not a valid issue report
Duplicate = This report duplicates an existing issue
WontFix = We decided to not take action on this issue
There are now 41 open issues out of which 8 for the 4.0alpha. I guess
a couple of smaller issues will be added in the following days.
If you want to contribute to any of these issues, please announce your
intention by sending an email to this list.
Cheers,
Doru
--
www.tudorgirba.com
"When people care, great things can happen."
13 years, 10 months
PhaMoose and Moose-All dependencies in monticello
by Simon Denier
I wonder if we could not refactor the dependencies between the
required packages in Moose-All. Because it starts to look like a big
ball of mud. Granted we will soon have the tools (with Jannik) to get
a better comprehension of that but here it is:
Moose-all required packages:
Moose-Core-jannik_laval.128,
Moose-GenericImporter-simon_denier.laval.26,
Moose-LAN-jannik_laval.8, <========= test and resources
Moose-SmalltalkImporter-jannik_laval.ducasse.58,
Moose-ModelTest-simon_denier.26, <========= test and resources
Moose-ConformityStrategies-simon_denier.9,
Famix-Core-Alexandre_Bergel.84,
Famix-Implementation-simon_denier.37,
Famix-Smalltalk-simon_denier.23,
Famix-File-Alexandre_Bergel.15,
EMOF-stephane.ducasse.1, <======= this one should be removed
Moose-Test-PackageTwo-simon_denier.ducasse.3, <========= test and
resources
Moose-ReferenceModel-stephane_ducasse.ducasse.15, <========= test and
resources
Moose-Test-PackageOne-stephane.ducasse.2, <========= test and resources
Famix-SmalltalkImporter-simon_denier.81,
Famix-LANTests-simon_denier.ducasse.22, <========= test and resources
CollectionExtensions-simon_denier.14,
Famix-Extensions-simon_denier.42,
Moose-File-Alexandre_Bergel.9, <========= test and resources
Moose-CookFamix3-simon_denier.18,
Moose-OBBrowser-simon_denier.50,
Moose-MondrianScripts-simon_denier.32, <==== require
MondrianExtensions and Mondrian
Moose-Hismo-simon_denier.12,
Famix-Test-simon_denier.4, <========= test and resources
Famix-SourceAnchor-tg.5,
Moose-MonticelloImporter-Alexandre_Bergel.7,
Moose-Finder-tg.28, <========= needs Glamour project
Moose also needs (but does not 'require') Fame project, Nile, Smacc,
RB, Omnibrowser, RIO for some extensions, and perhaps other things we
are not really aware of...
This is a lot...
In line with the current effort to better the MooseLoader, here is my
proposal for refactoring moose dependencies.
I distinguish between:
- external dependencies to external projects (Fame, Mondrian,
Glamour...) - managed by MooseLoader load scripts
- internal dependencies aka required packages for a single project -
managed by Monticello internal mechanisms
- hidden dependencies, which should be removed as soon as identified :)
*Moose-Basic*
The goal is to have a minimal footprint moose image, for performing
batch operations, importing big projects, exporting big MSE, etc,
without relying on a browser.
It can also serve as a basis for people who want to customize their
moose image (like Jannik or I do, loading DSM after loading moose...)
external: Nile, Fame, Smacc (to be removed?), RBSmallDictionary
internal:
Moose-Core-jannik_laval.128,
Moose-GenericImporter-simon_denier.laval.26,
Moose-SmalltalkImporter-jannik_laval.ducasse.58,
Moose-ConformityStrategies-simon_denier.9,
Famix-Core-Alexandre_Bergel.84,
Famix-Implementation-simon_denier.37,
Famix-Smalltalk-simon_denier.23,
Famix-SmalltalkImporter-simon_denier.81,
CollectionExtensions-simon_denier.14,
Famix-Extensions-simon_denier.42,
Famix-SourceAnchor-tg.5,
borderline:
Famix-File-Alexandre_Bergel.15,
Moose-CookFamix3-simon_denier.18,
*Moose-Basic-Tests* (actually tests and resources package require a
refactoring of their own, as some are tangled and others are rather
empty)
internal:
Moose-Basic
Moose-LAN-jannik_laval.8, <========= test and resources
Moose-ModelTest-simon_denier.26, <========= test and resources
Moose-Test-PackageTwo-simon_denier.ducasse.3, <========= test and
resources
Moose-ReferenceModel-stephane_ducasse.ducasse.15, <========= test and
resources
Moose-Test-PackageOne-stephane.ducasse.2, <========= test and resources
Famix-LANTests-simon_denier.ducasse.22, <========= test and resources
Moose-File-Alexandre_Bergel.9, <========= test and resources
Famix-Test-simon_denier.4, <========= test and resources
*Moose-All*
A complete distribution of Moose-related stable things for most usage.
external: Mondrian, Glamour, Omnibrowser (at least for know), RIO...
internal:
Moose-Basic
(Moose-Basic-Tests)
Moose-OBBrowser-simon_denier.50,
Moose-MondrianScripts-simon_denier.32, <==== require
MondrianExtensions and Mondrian
Moose-Hismo-simon_denier.12,
Moose-MonticelloImporter-Alexandre_Bergel.7,
Moose-Finder-tg.28, <========= needs Glamour project
Anyone has something to say?
--
Simon
13 years, 10 months
