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.euhttp://rmod.lille.inria.fr
---
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
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."
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
Hi
Did anyone succeed with importing a full eclipse SDK (3.5) source code
in Infusion? I tried yesterday and after several hours it was clear it
was going nowhere: I could just see the progress bar, stucked at 0,
while my processor was always running at some 20/30% for Infusion.
Granted, I did go the brute way, downloading the SDK, unpacking all
jars to get the java source files, then running Infusion on the folders.
So any hints or pointers on how to proceed from here would help :)
--
Simon
Here are the notes of the Moose meeting
Cyrille, Stef, Jannik, Simon
- First goal: Moose should be usable.
- load save filtering what is saved and what should be loaded mse
- get
Distribution Map
PackageBlueprint working on PhaMoose
- We should use systematically the bugtracker available at:
http://code.google.com/p/moose-technology/
- We need a moose documentation. Now we cannot afford writing it.
We will select some tests and tagged them with a pragma and use this
pragma to indicate that the tests is a documentation tests.
Documentation will have comment and show user scenario.
- Tests should be cleaned/reorganized
- Profiling Moose
- use of hashtable instead of Dictionary to see if we can go faster
- faster sets?
- SmallDictionary?
- Run SmallLint on Moose and update methods with pragmas
- Comment in classes
- in Fame classes also
- We should get a release process
- Stable Moose version
May be we should have a Moose and Moose Public repository
- Need a Browser based on Glamour
Check VW
Check new VW browser made by doru
IO
Selection/Filter -> Group
Property displayed
Actions on selection
- Mondrian Exporter as PNG
- Mondrian caches
- Moose is too slow to load
- package info
- MC 1.5 speed up
Hi,
I need to study one (or more) C++ systems. However, due to the macro
definition issue, it is quite long (and the results can be approximate) to
generate the mse files using iPlasma (or also inFusion), if you want to
analyze a C++ system that you don't know.
For this reason, I was wondering if there's somebody who can share the mse
files of C++ systems with me. The ideal situation is a system big enough to
have a bug reporting system (e.g. bugzilla) and a mailing list.
Thank you in advance,
Alberto
Hi all
I tried to load moose
I changed MooseLoader to have now
MooseLoader loadMinimalMoose (which loads automatically OB if
necessary)
Now my pharo image blocks automatically during the cleaning phase when
I load Mondrian
Can one of you try to reproduce the problem
MooseLoader loadMondrian
Hi everybody,
I created a few MSE files from JRuby releases using iPlasma 6.1
However, when I try to import them in Moose (I am using Visualworks 7.6nc at
the moment),
on the most recent releases I get the following exception:
"Unhandled exception: Unknown character".
The first releases are correctly imported in Moose.
If you want to help me with this problem,
you find an example of a problematic MSE here :
http://www.inf.unisi.ch/phd/bacchelli/research/20080720_jruby-1.1.3.mse
and an example of a not-problematic MSE here :
http://www.inf.unisi.ch/phd/bacchelli/research/20060802_jruby-0.9.0.mse
Thank you,
Alberto