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

[Christian Krause <henshin.ck@xxxxxxxxx>]

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