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

[Christian Krause <henshin.ck@xxxxxxxxx>]

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