BUG - MooseModel resetMeta

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

BUG - MooseModel resetMeta

Anne Etien
Hi,

I am developing a tool based on Fame pragma.
Considering the following methods:
FAMIXSQLExpression >>referencedRequests
<MSEProperty: #referencedRequests type: #FAMIXRequest opposite: #usedInExpression> <multivalued> 
<MSEComment: 'List of requests referenced by the expression.'>
^ referencedRequests

FAMIXRequest >>usedInExpression
<MSEProperty: #usedInExpression type: #FAMIXSQLExpression opposite: #referencedRequests>
<MSEComment: 'Expression in which the request is used.'>
^ usedInExpression

 (FAMIXSQLExpression mooseDescription at: 'referencedRequests') hasOpposite should return true.
However, I don’t have always the same behavior after each resetMeta.
(1 to: 100) do: [ : e | MooseModel resetMeta. (FAMIXSQLExpression mooseDescription at: 'referencedRequests') hasOpposite ifFalse: [ 1halt ] ].
always halts, at some unpredictable iteration (usually less than 10)

Does someone has any idea what is the problem and how to solve it?

By the way, MooseSQL is available here https://ci.inria.fr/moose/job/MooseSQL/

Thanks in advance for your help.

Anne



_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: BUG - MooseModel resetMeta

Pavel Krivanek-3
Solved, there were more than one opposite references in the metamodel. Because the pragma processor was processing a dictionary of references, the order was random and it caused such undeterministic behavior.

-- Pavel

2017-01-19 12:23 GMT+01:00 Anne Etien <[hidden email]>:
Hi,

I am developing a tool based on Fame pragma.
Considering the following methods:
FAMIXSQLExpression >>referencedRequests
<MSEProperty: #referencedRequests type: #FAMIXRequest opposite: #usedInExpression> <multivalued> 
<MSEComment: 'List of requests referenced by the expression.'>
^ referencedRequests

FAMIXRequest >>usedInExpression
<MSEProperty: #usedInExpression type: #FAMIXSQLExpression opposite: #referencedRequests>
<MSEComment: 'Expression in which the request is used.'>
^ usedInExpression

 (FAMIXSQLExpression mooseDescription at: 'referencedRequests') hasOpposite should return true.
However, I don’t have always the same behavior after each resetMeta.
(1 to: 100) do: [ : e | MooseModel resetMeta. (FAMIXSQLExpression mooseDescription at: 'referencedRequests') hasOpposite ifFalse: [ 1halt ] ].
always halts, at some unpredictable iteration (usually less than 10)

Does someone has any idea what is the problem and how to solve it?

By the way, MooseSQL is available here https://ci.inria.fr/moose/job/MooseSQL/

Thanks in advance for your help.

Anne



_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev



_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: BUG - MooseModel resetMeta

Blondeau Vincent

I added a check at the end of the meta meta model generation on the opposites. It should throw an Assertion failure is your model is not well designed:

 

Name: Fame-SmalltalkBinding-VincentBlondeau.14

Author: VincentBlondeau

Time: 19 January 2017, 5:16:16.582209 pm

UUID: 814148a9-f22d-7244-97e9-e147e6cfdace

Ancestors: Fame-SmalltalkBinding-PavelKrivanek.13

 

Vincent

 

De : Moose-dev [mailto:[hidden email]] De la part de Pavel Krivanek
Envoyé : jeudi 19 janvier 2017 14:43
À : Moose-related development
Cc : Moose-dev Moose Dev
Objet : [Moose-dev] Re: BUG - MooseModel resetMeta

 

Solved, there were more than one opposite references in the metamodel. Because the pragma processor was processing a dictionary of references, the order was random and it caused such undeterministic behavior.

 

-- Pavel

 

2017-01-19 12:23 GMT+01:00 Anne Etien <[hidden email]>:

Hi,

 

I am developing a tool based on Fame pragma.

Considering the following methods:

FAMIXSQLExpression >>referencedRequests

<MSEProperty: #referencedRequests type: #FAMIXRequest opposite: #usedInExpression> <multivalued> 

<MSEComment: 'List of requests referenced by the expression.'>

^ referencedRequests

 

FAMIXRequest >>usedInExpression

<MSEProperty: #usedInExpression type: #FAMIXSQLExpression opposite: #referencedRequests>

<MSEComment: 'Expression in which the request is used.'>

^ usedInExpression

 

 (FAMIXSQLExpression mooseDescription at: 'referencedRequests') hasOpposite should return true.

However, I don’t have always the same behavior after each resetMeta.

(1 to: 100) do: [ : e | MooseModel resetMeta. (FAMIXSQLExpression mooseDescription at: 'referencedRequests') hasOpposite ifFalse: [ 1halt ] ].

always halts, at some unpredictable iteration (usually less than 10)

 

Does someone has any idea what is the problem and how to solve it?

 

By the way, MooseSQL is available here https://ci.inria.fr/moose/job/MooseSQL/

 

Thanks in advance for your help.

 

Anne

 

 


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev

 


!!!*************************************************************************************
"Ce message et les pièces jointes sont confidentiels et réservés à l'usage exclusif de ses destinataires. Il peut également être protégé par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immédiatement l'expéditeur et de le détruire. L'intégrité du message ne pouvant être assurée sur Internet, la responsabilité de Worldline ne pourra être recherchée quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne saurait être recherchée pour tout dommage résultant d'un virus transmis.

This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.!!!"

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: BUG - MooseModel resetMeta

abergel
In reply to this post by Anne Etien
As a bit off the topic, I have always questioned myself to using pragmas. 
Are pragmas a mechanism we should continue to have to define a meta-model? Most of the time, I am better at implementing a simple meta-model without famix at all than trying to understand pragmas.

Alexandre
-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.



On Jan 19, 2017, at 8:23 AM, Anne Etien <[hidden email]> wrote:

Hi,

I am developing a tool based on Fame pragma.
Considering the following methods:
FAMIXSQLExpression >>referencedRequests
<MSEProperty: #referencedRequests type: #FAMIXRequest opposite: #usedInExpression> <multivalued> 
<MSEComment: 'List of requests referenced by the expression.'>
^ referencedRequests

FAMIXRequest >>usedInExpression
<MSEProperty: #usedInExpression type: #FAMIXSQLExpression opposite: #referencedRequests>
<MSEComment: 'Expression in which the request is used.'>
^ usedInExpression

 (FAMIXSQLExpression mooseDescription at: 'referencedRequests') hasOpposite should return true.
However, I don’t have always the same behavior after each resetMeta.
(1 to: 100) do: [ : e | MooseModel resetMeta. (FAMIXSQLExpression mooseDescription at: 'referencedRequests') hasOpposite ifFalse: [ 1halt ] ].
always halts, at some unpredictable iteration (usually less than 10)

Does someone has any idea what is the problem and how to solve it?

By the way, MooseSQL is available here https://ci.inria.fr/moose/job/MooseSQL/

Thanks in advance for your help.

Anne


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: BUG - MooseModel resetMeta

Nicolas Anquetil

+1


On 19/01/2017 18:37, Alexandre Bergel wrote:
As a bit off the topic, I have always questioned myself to using pragmas. 
Are pragmas a mechanism we should continue to have to define a meta-model? Most of the time, I am better at implementing a simple meta-model without famix at all than trying to understand pragmas.

Alexandre
-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.



On Jan 19, 2017, at 8:23 AM, Anne Etien <[hidden email]> wrote:

Hi,

I am developing a tool based on Fame pragma.
Considering the following methods:
FAMIXSQLExpression >>referencedRequests
<MSEProperty: #referencedRequests type: #FAMIXRequest opposite: #usedInExpression> <multivalued> 
<MSEComment: 'List of requests referenced by the expression.'>
^ referencedRequests

FAMIXRequest >>usedInExpression
<MSEProperty: #usedInExpression type: #FAMIXSQLExpression opposite: #referencedRequests>
<MSEComment: 'Expression in which the request is used.'>
^ usedInExpression

 (FAMIXSQLExpression mooseDescription at: 'referencedRequests') hasOpposite should return true.
However, I don’t have always the same behavior after each resetMeta.
(1 to: 100) do: [ : e | MooseModel resetMeta. (FAMIXSQLExpression mooseDescription at: 'referencedRequests') hasOpposite ifFalse: [ 1halt ] ].
always halts, at some unpredictable iteration (usually less than 10)

Does someone has any idea what is the problem and how to solve it?

By the way, MooseSQL is available here https://ci.inria.fr/moose/job/MooseSQL/

Thanks in advance for your help.

Anne


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev



_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev

-- 
Nicolas Anquetil -- MCF (HDR)
Project-Team RMod

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: BUG - MooseModel resetMeta

Tudor Girba-2
Hi,

Pragmas are only useful when you want to export/import. They are also used a bit for navigation but that use can be easily replaced with dedicated inspector panes. So, if you do not have the import/export use case, you do not need the pragmas.

Cheers,
Doru


> On Jan 19, 2017, at 11:06 PM, Nicolas Anquetil <[hidden email]> wrote:
>
> +1
>
> On 19/01/2017 18:37, Alexandre Bergel wrote:
>> As a bit off the topic, I have always questioned myself to using pragmas.
>> Are pragmas a mechanism we should continue to have to define a meta-model? Most of the time, I am better at implementing a simple meta-model without famix at all than trying to understand pragmas.
>>
>> Alexandre
>> --
>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> Alexandre Bergel  http://www.bergel.eu
>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>
>>
>>
>>> On Jan 19, 2017, at 8:23 AM, Anne Etien <[hidden email]> wrote:
>>>
>>> Hi,
>>>
>>> I am developing a tool based on Fame pragma.
>>> Considering the following methods:
>>> FAMIXSQLExpression >>referencedRequests
>>> <MSEProperty: #referencedRequests type: #FAMIXRequest opposite: #usedInExpression> <multivalued>
>>> <MSEComment: 'List of requests referenced by the expression.'>
>>> ^ referencedRequests
>>>
>>> FAMIXRequest >>usedInExpression
>>> <MSEProperty: #usedInExpression type: #FAMIXSQLExpression opposite: #referencedRequests>
>>> <MSEComment: 'Expression in which the request is used.'>
>>> ^ usedInExpression
>>>
>>>  (FAMIXSQLExpression mooseDescription at: 'referencedRequests') hasOpposite should return true.
>>> However, I don’t have always the same behavior after each resetMeta.
>>> (1 to: 100) do: [ : e | MooseModel resetMeta. (FAMIXSQLExpression mooseDescription at: 'referencedRequests') hasOpposite ifFalse: [ 1halt ] ].
>>> always halts, at some unpredictable iteration (usually less than 10)
>>>
>>> Does someone has any idea what is the problem and how to solve it?
>>>
>>> By the way, MooseSQL is available here https://ci.inria.fr/moose/job/MooseSQL/
>>>
>>> Thanks in advance for your help.
>>>
>>> Anne
>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> [hidden email]
>>> https://www.list.inf.unibe.ch/listinfo/moose-dev
>>
>>
>>
>> _______________________________________________
>> Moose-dev mailing list
>>
>> [hidden email]
>> https://www.list.inf.unibe.ch/listinfo/moose-dev
>
> --
> Nicolas Anquetil -- MCF (HDR)
> Project-Team RMod
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.list.inf.unibe.ch/listinfo/moose-dev

--
www.tudorgirba.com
www.feenk.com

“The smaller and more pervasive the hardware becomes, the more physical the software gets."

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: BUG - MooseModel resetMeta

abergel
Really?

Does it mean that the pragmas contained in:
-=-=-=-=-=-=-=-=
FAMIXType>>subInheritances
        <MSEProperty: #subInheritances type: #FAMIXInheritance opposite: #superclass> <multivalued> <derived>
        <MSEComment: 'Subinheritance relationships, i.e. known subclasses of this type.'>
       
        ^subInheritances
-=-=-=-=-=-=-=-=

Are only for the import / export?
<multivalued>, <derived> ?

Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.



> On Jan 20, 2017, at 7:24 AM, Tudor Girba <[hidden email]> wrote:
>
> Hi,
>
> Pragmas are only useful when you want to export/import. They are also used a bit for navigation but that use can be easily replaced with dedicated inspector panes. So, if you do not have the import/export use case, you do not need the pragmas.
>
> Cheers,
> Doru
>
>
>> On Jan 19, 2017, at 11:06 PM, Nicolas Anquetil <[hidden email]> wrote:
>>
>> +1
>>
>> On 19/01/2017 18:37, Alexandre Bergel wrote:
>>> As a bit off the topic, I have always questioned myself to using pragmas.
>>> Are pragmas a mechanism we should continue to have to define a meta-model? Most of the time, I am better at implementing a simple meta-model without famix at all than trying to understand pragmas.
>>>
>>> Alexandre
>>> --
>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>> Alexandre Bergel  http://www.bergel.eu
>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>
>>>
>>>
>>>> On Jan 19, 2017, at 8:23 AM, Anne Etien <[hidden email]> wrote:
>>>>
>>>> Hi,
>>>>
>>>> I am developing a tool based on Fame pragma.
>>>> Considering the following methods:
>>>> FAMIXSQLExpression >>referencedRequests
>>>> <MSEProperty: #referencedRequests type: #FAMIXRequest opposite: #usedInExpression> <multivalued>
>>>> <MSEComment: 'List of requests referenced by the expression.'>
>>>> ^ referencedRequests
>>>>
>>>> FAMIXRequest >>usedInExpression
>>>> <MSEProperty: #usedInExpression type: #FAMIXSQLExpression opposite: #referencedRequests>
>>>> <MSEComment: 'Expression in which the request is used.'>
>>>> ^ usedInExpression
>>>>
>>>> (FAMIXSQLExpression mooseDescription at: 'referencedRequests') hasOpposite should return true.
>>>> However, I don’t have always the same behavior after each resetMeta.
>>>> (1 to: 100) do: [ : e | MooseModel resetMeta. (FAMIXSQLExpression mooseDescription at: 'referencedRequests') hasOpposite ifFalse: [ 1halt ] ].
>>>> always halts, at some unpredictable iteration (usually less than 10)
>>>>
>>>> Does someone has any idea what is the problem and how to solve it?
>>>>
>>>> By the way, MooseSQL is available here https://ci.inria.fr/moose/job/MooseSQL/
>>>>
>>>> Thanks in advance for your help.
>>>>
>>>> Anne
>>>>
>>>>
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>> [hidden email]
>>>> https://www.list.inf.unibe.ch/listinfo/moose-dev
>>>
>>>
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>>
>>> [hidden email]
>>> https://www.list.inf.unibe.ch/listinfo/moose-dev
>>
>> --
>> Nicolas Anquetil -- MCF (HDR)
>> Project-Team RMod
>>
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.list.inf.unibe.ch/listinfo/moose-dev
>
> --
> www.tudorgirba.com
> www.feenk.com
>
> “The smaller and more pervasive the hardware becomes, the more physical the software gets."
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.list.inf.unibe.ch/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: BUG - MooseModel resetMeta

Anne Etien
Not only, they are used, I think, also in the MoosePanel. And if you want to generate a tool that can be used for different metamodel, as MooseQuery or OrionGenerator, you need the pragmas.

<multivalued> and <derived> also.

We are currently working with Pavel to define more easily metamodels without pragmas and FMMultivalueLink.

Anne

> Le 20 janv. 2017 à 15:18, Alexandre Bergel <[hidden email]> a écrit :
>
> Really?
>
> Does it mean that the pragmas contained in:
> -=-=-=-=-=-=-=-=
> FAMIXType>>subInheritances
> <MSEProperty: #subInheritances type: #FAMIXInheritance opposite: #superclass> <multivalued> <derived>
> <MSEComment: 'Subinheritance relationships, i.e. known subclasses of this type.'>
>
> ^subInheritances
> -=-=-=-=-=-=-=-=
>
> Are only for the import / export?
> <multivalued>, <derived> ?
>
> Alexandre
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>> On Jan 20, 2017, at 7:24 AM, Tudor Girba <[hidden email]> wrote:
>>
>> Hi,
>>
>> Pragmas are only useful when you want to export/import. They are also used a bit for navigation but that use can be easily replaced with dedicated inspector panes. So, if you do not have the import/export use case, you do not need the pragmas.
>>
>> Cheers,
>> Doru
>>
>>
>>> On Jan 19, 2017, at 11:06 PM, Nicolas Anquetil <[hidden email]> wrote:
>>>
>>> +1
>>>
>>> On 19/01/2017 18:37, Alexandre Bergel wrote:
>>>> As a bit off the topic, I have always questioned myself to using pragmas.
>>>> Are pragmas a mechanism we should continue to have to define a meta-model? Most of the time, I am better at implementing a simple meta-model without famix at all than trying to understand pragmas.
>>>>
>>>> Alexandre
>>>> --
>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>>> Alexandre Bergel  http://www.bergel.eu
>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>>
>>>>
>>>>
>>>>> On Jan 19, 2017, at 8:23 AM, Anne Etien <[hidden email]> wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>> I am developing a tool based on Fame pragma.
>>>>> Considering the following methods:
>>>>> FAMIXSQLExpression >>referencedRequests
>>>>> <MSEProperty: #referencedRequests type: #FAMIXRequest opposite: #usedInExpression> <multivalued>
>>>>> <MSEComment: 'List of requests referenced by the expression.'>
>>>>> ^ referencedRequests
>>>>>
>>>>> FAMIXRequest >>usedInExpression
>>>>> <MSEProperty: #usedInExpression type: #FAMIXSQLExpression opposite: #referencedRequests>
>>>>> <MSEComment: 'Expression in which the request is used.'>
>>>>> ^ usedInExpression
>>>>>
>>>>> (FAMIXSQLExpression mooseDescription at: 'referencedRequests') hasOpposite should return true.
>>>>> However, I don’t have always the same behavior after each resetMeta.
>>>>> (1 to: 100) do: [ : e | MooseModel resetMeta. (FAMIXSQLExpression mooseDescription at: 'referencedRequests') hasOpposite ifFalse: [ 1halt ] ].
>>>>> always halts, at some unpredictable iteration (usually less than 10)
>>>>>
>>>>> Does someone has any idea what is the problem and how to solve it?
>>>>>
>>>>> By the way, MooseSQL is available here https://ci.inria.fr/moose/job/MooseSQL/
>>>>>
>>>>> Thanks in advance for your help.
>>>>>
>>>>> Anne
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Moose-dev mailing list
>>>>> [hidden email]
>>>>> https://www.list.inf.unibe.ch/listinfo/moose-dev
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>>
>>>> [hidden email]
>>>> https://www.list.inf.unibe.ch/listinfo/moose-dev
>>>
>>> --
>>> Nicolas Anquetil -- MCF (HDR)
>>> Project-Team RMod
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> [hidden email]
>>> https://www.list.inf.unibe.ch/listinfo/moose-dev
>>
>> --
>> www.tudorgirba.com
>> www.feenk.com
>>
>> “The smaller and more pervasive the hardware becomes, the more physical the software gets."
>>
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.list.inf.unibe.ch/listinfo/moose-dev
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.list.inf.unibe.ch/listinfo/moose-dev

_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: BUG - MooseModel resetMeta

abergel
> We are currently working with Pavel to define more easily metamodels without pragmas and FMMultivalueLink.

+1 !!!!!!
Go go go!

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.



_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: BUG - MooseModel resetMeta

Tudor Girba-2
In reply to this post by Anne Etien
Hi,

> On Jan 20, 2017, at 6:11 PM, Anne Etien <[hidden email]> wrote:
>
> Not only, they are used, I think, also in the MoosePanel.

As I said, the MoosePanel navigation can easily be replaced with an extension to the inspector.

> And if you want to generate a tool that can be used for different metamodel, as MooseQuery or OrionGenerator, you need the pragmas.
>
> <multivalued> and <derived> also.

Actually, MooseQuery relies on <container>. I do not know what OrionGenerator does :).

> We are currently working with Pavel to define more easily metamodels without pragmas and FMMultivalueLink.

Just to clarify. The multi value link are not essential for any meta-model, but they are an important internal piece that allows us to have consistent bidirectional relationships which offer a nice solution for more succinct queries. Ideally, we should have them implemented as slots, and even nicer would be to have refactorings that would guide us to maintain them.

Cheers,
Doru



> Anne
>> Le 20 janv. 2017 à 15:18, Alexandre Bergel <[hidden email]> a écrit :
>>
>> Really?
>>
>> Does it mean that the pragmas contained in:
>> -=-=-=-=-=-=-=-=
>> FAMIXType>>subInheritances
>> <MSEProperty: #subInheritances type: #FAMIXInheritance opposite: #superclass> <multivalued> <derived>
>> <MSEComment: 'Subinheritance relationships, i.e. known subclasses of this type.'>
>>
>> ^subInheritances
>> -=-=-=-=-=-=-=-=
>>
>> Are only for the import / export?
>> <multivalued>, <derived> ?
>>
>> Alexandre
>> --
>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> Alexandre Bergel  http://www.bergel.eu
>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>
>>
>>
>>> On Jan 20, 2017, at 7:24 AM, Tudor Girba <[hidden email]> wrote:
>>>
>>> Hi,
>>>
>>> Pragmas are only useful when you want to export/import. They are also used a bit for navigation but that use can be easily replaced with dedicated inspector panes. So, if you do not have the import/export use case, you do not need the pragmas.
>>>
>>> Cheers,
>>> Doru
>>>
>>>
>>>> On Jan 19, 2017, at 11:06 PM, Nicolas Anquetil <[hidden email]> wrote:
>>>>
>>>> +1
>>>>
>>>> On 19/01/2017 18:37, Alexandre Bergel wrote:
>>>>> As a bit off the topic, I have always questioned myself to using pragmas.
>>>>> Are pragmas a mechanism we should continue to have to define a meta-model? Most of the time, I am better at implementing a simple meta-model without famix at all than trying to understand pragmas.
>>>>>
>>>>> Alexandre
>>>>> --
>>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>>>>> Alexandre Bergel  http://www.bergel.eu
>>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>>>>
>>>>>
>>>>>
>>>>>> On Jan 19, 2017, at 8:23 AM, Anne Etien <[hidden email]> wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I am developing a tool based on Fame pragma.
>>>>>> Considering the following methods:
>>>>>> FAMIXSQLExpression >>referencedRequests
>>>>>> <MSEProperty: #referencedRequests type: #FAMIXRequest opposite: #usedInExpression> <multivalued>
>>>>>> <MSEComment: 'List of requests referenced by the expression.'>
>>>>>> ^ referencedRequests
>>>>>>
>>>>>> FAMIXRequest >>usedInExpression
>>>>>> <MSEProperty: #usedInExpression type: #FAMIXSQLExpression opposite: #referencedRequests>
>>>>>> <MSEComment: 'Expression in which the request is used.'>
>>>>>> ^ usedInExpression
>>>>>>
>>>>>> (FAMIXSQLExpression mooseDescription at: 'referencedRequests') hasOpposite should return true.
>>>>>> However, I don’t have always the same behavior after each resetMeta.
>>>>>> (1 to: 100) do: [ : e | MooseModel resetMeta. (FAMIXSQLExpression mooseDescription at: 'referencedRequests') hasOpposite ifFalse: [ 1halt ] ].
>>>>>> always halts, at some unpredictable iteration (usually less than 10)
>>>>>>
>>>>>> Does someone has any idea what is the problem and how to solve it?
>>>>>>
>>>>>> By the way, MooseSQL is available here https://ci.inria.fr/moose/job/MooseSQL/
>>>>>>
>>>>>> Thanks in advance for your help.
>>>>>>
>>>>>> Anne
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Moose-dev mailing list
>>>>>> [hidden email]
>>>>>> https://www.list.inf.unibe.ch/listinfo/moose-dev
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Moose-dev mailing list
>>>>>
>>>>> [hidden email]
>>>>> https://www.list.inf.unibe.ch/listinfo/moose-dev
>>>>
>>>> --
>>>> Nicolas Anquetil -- MCF (HDR)
>>>> Project-Team RMod
>>>>
>>>> _______________________________________________
>>>> Moose-dev mailing list
>>>> [hidden email]
>>>> https://www.list.inf.unibe.ch/listinfo/moose-dev
>>>
>>> --
>>> www.tudorgirba.com
>>> www.feenk.com
>>>
>>> “The smaller and more pervasive the hardware becomes, the more physical the software gets."
>>>
>>> _______________________________________________
>>> Moose-dev mailing list
>>> [hidden email]
>>> https://www.list.inf.unibe.ch/listinfo/moose-dev
>>
>> _______________________________________________
>> Moose-dev mailing list
>> [hidden email]
>> https://www.list.inf.unibe.ch/listinfo/moose-dev
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.list.inf.unibe.ch/listinfo/moose-dev

--
www.tudorgirba.com
www.feenk.com

"No matter how many recipes we know, we still value a chef."







_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.list.inf.unibe.ch/listinfo/moose-dev
Loading...