configuration question: package only in group
by Tudor Girba
Hi,
ConfigurationOfFuelMooseExtensions has the following baseline and version definitions and I am not sure whether they are correct. The problem is that the baseline defines a package only in a group, and then the version defines the version for it.
Loading seems to load just fine. If I simply load the version, it loads the two packages defined in the Core group as expected. However, my problem is that when I query version 1.1 for packages, it retrieves the extra FuelMooseExtensionBenchmarks package.
Could someone look into this?
baseline11: spec
<version: '1.1-baseline'>
spec for: #common do: [
spec blessing: #baseline.
spec repository: 'http://www.squeaksource.com/Fuel'.
spec
package: 'FuelFameExtension' with: [ spec requires: 'Fuel' ];
package: 'FuelMooseExtension' with: [ spec requires: 'FuelFameExtension' ].
spec
group: 'default' with: #('Core');
group: 'Core' with: #('FuelFameExtension' 'FuelMooseExtension');
group: 'Tests' with: #('FuelFameExtension' 'FuelMooseExtension');
group: 'Benchmarks' with: #('FuelFameExtension' 'FuelMooseExtension' 'FuelMooseExtensionBenchmarks').
spec
project: 'Fuel' with: [
spec
className: 'ConfigurationOfFuel';
loads: #('CoreWithProgressBar' );
file: 'ConfigurationOfFuel';
repository: 'http://www.squeaksource.com/Fuel' ] ].
version11: spec
<version: '1.1' imports: #('1.1-baseline') >
spec for: #common do: [
spec blessing: #release.
spec
project: 'Fuel' with: '1.1';
package: 'FuelFameExtension' with: 'FuelFameExtension-MartinDias.28';
package: 'FuelMooseExtension' with: 'FuelMooseExtension-MartinDias.8';
package: 'FuelMooseExtensionBenchmarks' with: 'FuelMooseExtensionBenchmarks-MartinDias.2'].
Cheers,
Doru
--
www.tudorgirba.com
"Some battles are better lost than fought."
12 years, 4 months
Fuel?
by Alexandre Bergel
Hi!
What is Fuel? By reading the unit test, it seems that it is a serializer.
Is there a description somewhere? There is none on moosetechnology.org and almost nothing on squeaksource.
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
12 years, 4 months
Re: wrong meta model definition
by Tudor Girba
Thanks for reporting this.
Indeed, we have to make the meta-model rules work again. I will see if I can refresh them in the context of the OnMoose report (this is in the Arki project).
Cheers,
Doru
On 26 Apr 2011, at 13:38, Fabrizio Perin wrote:
> Hi Doru,
> I was looking with Raffael to the definition of the meta model i we might find an inconsistency:
>
> You define:
>
> FAMIXGlobalVariable>>>parentModule
> <MSEProperty: #parentModule type: #FAMIXModule opposite: #globalVariables>
> <MSEComment: 'Module (typically a file) defining the global variable.'>
> ^ self privateState
> attributeAt: #parentModule
> ifAbsentPut: [ nil ]
>
> But the opposite globalVariable is not define in FAMIXModule but into FAMIXScopingEntity. So either the pragmas in FAMIXGlobalVariable>>>parentModule became like this:
> <MSEProperty: #parentModule type: #FAMIXScopingEntity opposite: #globalVariables>
> <MSEComment: 'Module (typically a file) defining the global variable.'>
>
> (In this case the property should be called parentScope not parentModule)
>
> or you move to FAMIXModule
>
> FAMIXScopingEntity>>>globalVariables
> <MSEProperty: #globalVariables type: #FAMIXGlobalVariable opposite: #parentScope> <multivalued> <derived>
> <MSEComment: 'Global variables defined in the scope, if any.'>
>
> I would go for the first.
>
> Thanks,
>
> Fabrizio and Raffael
--
www.tudorgirba.com
"Problem solving should be focused on describing
the problem in a way that makes the solution obvious."
12 years, 4 months
New pragmas 'alias' and 'aliasedBy'?
by Raffael Krebs
Hi all
I am a student at the University of Bern and for my Master's Thesis I am
using the FAMIX metamodel and I also intend to use Fame.
One thing that is most valuable for me is the possibility to generate
metamodel stub code from an fm3 mse file, in my case Java classes.
While filling in the stub classes for FAMIX core, I realized that much
of that work could also be done by the generator, if only it had some
additional information. So I suggest adding that information as pragmas.
Let me explain that on behalf of an example.
The message FAMIXNamedEntity>>belongsTo should be overridden in all of
FAMIXType
FAMIXScopingEntity
FAMIXMethod
FAMIXFunction
FAMIXLocalVariable
FAMIXUnknownVariable
FAMIXGlobalVariable
FAMIXParameter
FAMIXAttribute
FAMIXImplicitVariable
(and more outside FAMIX core)
but a code generator does not know that, so I have to implement the
corresponding messages/methods by hand. That is a bit annoying since
this really is very simple code that could easily be generated.
Example for one of the methods that have to be written by hand:
FAMIXAttribute>>belongsTo
^ self parentType
Every implementation of 'belongsTo' looks like that, i.e. is a very
simple delegate, or let us call it an "alias".
I suggest to add the information about such "aliases" to the pragmas:
1) add <alias> to NamedEntity>>belongsTo
2) add <aliasedBy #belongsTo> to all subclass properties, e.g. to
FAMIXAttribute>>parentType
Then, with that kind of information in an mse file, a code generator
could do more work for me and I had time to drink an additional coffee
or two :)
And maybe metamodel browsers can profit from that kind of information, too.
Cheers,
Raffael Krebs
12 years, 4 months