Re: Interraction between main programs and events

From: Joachim Schimpf <j.schimpf_at_icparc.ic.ac.uk>
Date: Tue 26 Jul 2005 02:32:00 PM GMT
Message-ID: <42E64960.6050408@icparc.ic.ac.uk>
ludovic picouays wrote:
> After some tests and verifications about the failure of a predicate
> which is wake up by an event (demon/1 and suspend/1) the failure of
> this predicate doesn't return a fail to the main program.
> 
> When the domain of a variable is modified  by indomain, the associated
> event is awakened (I've looked with the tracer what was happening). In
> order to say if the modification is valid or not, there are some
> verifications. If modifications are not valid, the predicate fails,
> and the failure goes back to the wake and not to the indomain. I think
> the wake creates another tree where it is the root of another tree. So
> when it fail, the main programm doesn't fail and continues to run.
 >
 > I want a solution to the interactions between the wake and the main
 > programm. When the predicate wakes  due to the event fail, I want to
 > cut the current branche in the search tree.
 >
 > Could you give me a solution that allows this ?

Sorry, your verbal description is far too vague for me to tell
what you are doing wrong.

It sounds like in principle you are doing the right thing,
but you may have made some mistake in the implementation,
possibly just an unintended choicepoint in your woken predicate
(watch out for *EXIT ports in the debugger).
Or maybe you wake your goal inside the condition of an if-then-else,
in which case the failure only leads to execution of the else branch,
rather than failing to the last indomain-choicepoint.


 > I want a solution to the interactions between the wake and the main
 > programm.

There is nothing special about this "interaction". When a goal gets
woken, it behaves as if it were dynamically inserted into the code,
just after the condition which wakes it occurs. When the woken
goal fails, it is as if you had inserted a 'fail' at this point
in the code.

Try testing your implementation incrementally, bottom-up,
first some simple cases without search, later with search.
If you find a behaviour of eclipse that you don't expect,
send us a corresponding code example (preferably without
C++ components...)


-- 
  Joachim Schimpf              /             phone: +44 20 7594 8187
  IC-Parc                     /      mailto:J.Schimpf@imperial.ac.uk
  Imperial College London    /    http://www.icparc.ic.ac.uk/eclipse
Received on Tue Jul 26 15:32:12 2005

This archive was generated by hypermail 2.1.8 : Wed 16 Nov 2005 06:07:38 PM GMT GMT