Re: [henshin-dev] Resetting of the temporary domain

[Enrico Biermann <enrico@xxxxxxxxxxxxxxx>]

The transformation should be confluent, especialy considering its intend
of model2model transformation.
Just an idea: Could you run a state space analysis of the
transformation? It should show the divergence between a successful and
failed run? Otherwise the only difference I can see between the two
failed and the two successful runs is the match of the "SYN_ACK" for the
trigger parameter for the failed runs.

On 13.06.2012 13:56, Christian Krause wrote:
> I don't think that is the problem, because I tried to shuffle the
> domains and still got the correct result. So I assume the
> transformation is confluent. I'm still puzzled why the
> "temporaryDomain=null" messes up things. I saved the intermediate
> model of the transformation just before the first difference occurs in
> the log. When I try out the match finder for this model, I get the
> same matches in the same order independently of whether
> "temporaryDomain=null" is used or not. Interestingly, the first found
> match is neither of the ones that I get during the complete
> transformation.
>
>
> On 06/13/2012 01:22 PM, Christian Krause wrote:
>> It seems like the order of matches is affected by the change. If the
>> transformation is not confluent, this could explain the different
>> result.
>>
>> On 06/12/2012 10:10 PM, Christian Krause wrote:
>>> Here a version of the logs without hash codes. From these you can
>>> compute a nice diff. The first difference occurs in step 449 (rule
>>> 'decendSwitch').
>>>
>>> On 06/12/2012 09:43 PM, Christian Krause wrote:
>>>> Hi Enrico,
>>>>
>>>> ok, ok, I buy that the "temporaryDomain=null" should be in clear(). ;)
>>>>
>>>> But then, somewhere else must be a bug. I executed the
>>>> Java2StateMachine example with and without the
>>>> "temporaryDomain=null" and generated logs. I attached the logs to
>>>> this e-mail. The LogginApplicationMonitor supports saving of
>>>> intermediate results, so we should be possible extract the graph
>>>> and rule application where the matching fails. Anyway, I have not
>>>> looked at the logs in detail yet, but I know they are long and
>>>> differ at some points....
>>>>
>>>> Cheers,
>>>> Christian
>>>>
>>>> On 06/12/2012 07:38 PM, Enrico Biermann wrote:
>>>>> You are right for cases with failed match attempts, because the
>>>>> backtracking will end with the first variable no longer being
>>>>> instanciable and all domain slots unlocked. But just to clarify:
>>>>> In unlock only the temporary domain of *other* domain slots
>>>>> (targets of
>>>>> binary constraints) get reset *not* the temporary domain of the
>>>>> variable
>>>>> itself. Granted, all domain slots *not* being initialized by binary
>>>>> constraints, still have temporaryDomain == null ;)
>>>>>
>>>>> Still, resetting the temporary domain during clear() is neccessary
>>>>> for
>>>>> succesful match attempts, because they end with all variables in a
>>>>> valid
>>>>> state.  This is exactly what happend in the Comb example. The
>>>>> domain of
>>>>> the NAC node was initialized by a binary constraint. After the NAC
>>>>> matched (meaning a failed LHS match) the LHS backtracked and found
>>>>> another match. Now the temporary domain of the NAC node was
>>>>> incompatible
>>>>> with the binary constraints of one of the other nodes.
>>>>>
>>>>> Unlock() is an essential part of backtracking, keeping the state
>>>>> of all
>>>>> domains consistent, clear() should reset the domain slot to its
>>>>> original
>>>>> state. Note that not simply creating a fresh domain slot was a design
>>>>> decision based on performance, because you would have to recreate the
>>>>> domainMap in ApplicationCondition for all graphs (lhs and acs).
>>>>>
>>>>> In any case, clear() is behaving correctly, if the state after clear
>>>>> corresponds to the state of a fresh DomainSlot(). If any logic in
>>>>> clear() is completly redundant to unlock it can be removed (since
>>>>> unlock
>>>>> is called anyway by clear), but be *very* sure that is the case
>>>>> before
>>>>> removal ;)
>>>>>
>>>>> Cheers,
>>>>> Enrico
>>>>>
>>>>> On 12.06.2012 15:30, Christian Krause wrote:
>>>>>> Hi Enrico,
>>>>>>
>>>>>> the DomainChange class is apparently used to store the old
>>>>>> contents of
>>>>>> the temporaryDomain when it is changed (see ReferenceConstraint:52).
>>>>>> When unlocking a variable, this change is reverted again (see
>>>>>> DomainSlot:231). At this point, the temporaryDomain is reset to its
>>>>>> previous value. If the temporaryDomain is reset to its original
>>>>>> values
>>>>>> at this point, why should it be also done in DomainSlot.clear() ?
>>>>>>
>>>>>> Cheers,
>>>>>> Christian
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> henshin-dev mailing list
>>>>>> henshin-dev@xxxxxxxxxxx
>>>>>> https://dev.eclipse.org/mailman/listinfo/henshin-dev
>>>>> _______________________________________________
>>>>> henshin-dev mailing list
>>>>> henshin-dev@xxxxxxxxxxx
>>>>> https://dev.eclipse.org/mailman/listinfo/henshin-dev
>>>>
>>>
>>
>
> _______________________________________________
> henshin-dev mailing list
> henshin-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/henshin-dev