Hi,
The Chef engine needs to be revisited. The goal of this new version was to generalize the logic, and that is a good thing. However, the problem is that it does it at the expense of understandability by relying on string concatenation and perform:.
We need to iterate on this one and look for another design, while preserving the current behavior.
Would anyone be interested to dive in this area?
Cheers,
Doru
--
www.tudorgirba.comwww.feenk.com
"Speaking louder won't make the point worthier."
Hi,
The Moose build is now green.
That puts us in a good situation for a release.
Until the release I would like us to push be great to touch the followings:
- Adding the Famix packages to a separate Famix configuration. Cyril would like to help with that.
- Integrate the PetitParser compiler in the ConfigurarionOfPetitParser. @Jan: any chance to get you interested to look at this?
- Integrating SmaCC and all its parsers.
Anything else we should be aware of?
Cheers,
Doru
--
www.tudorgirba.comwww.feenk.com
"From an abstract enough point of view, any two things are similar."
Hi,
I can arrange elements in a visualization where the size/area of an
RTBox is proportional to a specified value, like here:
or I can made all avatars (RTBitmaps) appear into this one:
But I would like to combine both, making the avatars area proportional
to a given value and present them in a RTFlowLayout. Is this possible
and how?
Thanks,
Offray
Hi,
As we talked in another thread I tried to look at the configuration of
Moose to be able to load Famix without every Moose tool (Glamour, Roassal…).
As Stephan said, since Famix is an inactive project for now groups are
enough to manage Famix. So I made some groups to be able to get only
Famix and the moose packages needed by famix.
There is 3 groups:
- Famix (Which is only the two following groups together)
- Famix-Without-Test
- Famix-Tests
So if you have a Tool that use Famix but not Moose tools you can had
this dependency:
spec project: 'Famix' with: [
spec
className: #ConfigurationOfMoose;
versionString: #development;
loads: #( #'Famix' );
repository: 'http://smalltalkhub.com/mc/Moose/Moose/main' ].
The only problem during the loading is about MalGraphBuilderStrategy
that is missing, but this was already the case in Moose.
I hope this will help you.
--
Cyril Ferlicot
http://www.synectique.eu
165 Avenue Bretagne
Lille 59000 France
Hi,
There is a package Famix specification that require a class of Pharo 3
(Or maybe 2).
There is no class comment inside.
Someone knows what it is? If this is useful then we should comment the
class, else we should remove the package because there is no senders.
--
Cyril Ferlicot
http://www.synectique.eu
165 Avenue Bretagne
Lille 59000 France
Hi,
I went quickly through the changes from the FAMIX-C package. The Multivalue code looks good.
Here are two remarks:
1. I am not convinced about having CompilationUnit and Header be subclasses of CFile (which is a subclass of File). But, to make an opinion I would first like to see a model. @Alex, could you provide a simple MSE model to play with?
2. I would want to change is the names of the following two properties:
FAMIXCFile>>includedInFiles
<MSEProperty: #includedInFiles type: #FAMIXInclude opposite: #includesFiles> <multivalued> <derived>
<MSEComment: 'includedInFiles relationships, i.e. files that includes this file.'>
^ includedInFiles
FAMIXCFile>>includesFiles
<MSEProperty: #includesFiles type: #FAMIXInclude opposite: #includedInFiles> <multivalued> <derived>
<MSEComment: 'includesFiles relationships, i.e. files included by this file.'>
^ includingFiles
The names suggest that the result will be a collection of File objects, but it is actually a collection of Includes.
It is a bit tricky to name these selectors, but we could use the same convention we used for invocations, and we could have:
- includedInFiles ==> incomingIncludeRelations
- includesFiles ==> outgoingIncludeRelations
What do you think?
Cheers,
Doru
--
www.tudorgirba.comwww.feenk.com
"To lead is not to demand things, it is to make them happen."
