Re: [eclipse-clp-users] Remote Tools

Hi Rafael,

Rafael Oliveira wrote:
> Thanks very much! I need exactly this, because I intend to build a CHR editor/debug for eclipse IDE. 

Is your aim is to build a CHR debugger for lib(ech), rather than 
debugging ECLiPSe/CHR code you have running from a Java application? 
That is, your  Java application is the eclipse IDE?

I assume you know that there is an eclipse IDE plug-in for ECLiPSe, 
Saros, which you can download from ECLiPSe's source forge project site? 
This provides the same set of development tools as tktools (the ECLiPSe 
side code is the same for both). I would suggest you use this if you 
want to do anything with eclipse IDE and ECLiPSe.

If you are writting a Java application that uses ECLiPSe, and want to 
use the eclipse IDE to debug the Java as well as the ECLiPSe code, then 
I don't know if Saros is able to do this at the moment (I am not very 
familiar with it). This should be possible, because Saros uses the 
remote peer interface to connect eclipse IDE to ECLiPSe, the same way as 
remote tktools.

It would be great if you can develop a CHR debugger for lib(ech), as 
lib(ech) needs this. We have wanted to add such a debugger for it, but 
never had the time to do so. The lack of this debugger is the only 
reason the older lib(chr) have not been removed from the distribution 
yet, as it does provide a better view of the CHR constraints when you 
are debugging. I assume you do want to use lib(ech), because it is 
faster and less restricted than lib(chr), and lib(chr) doesn't really 
need extension of the debugger. If you do develop this, and you want to 
contribute it to ECLiPSe, we would greatly welcome it.

However, I suspect that working out how to map the transformed code back 
to the CHR constraints may be difficult. I don't think it is documented.
I can give some help (I wrote lib(ech)), but be sure you want to do this 
before you start on it.

> Then I need for the following .pl
> 
> p(X,Y) :- 
>         trace_call_port(call,_, Y is X*X-1),
> 
> 
>         *(X,X,T),
>         -(T,1,Y),
>         trace_exit_port.
> calling eclipse.rpc("p(3,Y)"); in Java to see something like this follow output however in Java console
> 
> (1) 1 CALL  p(3, Y)   %> creep
> 
> (2) 2 CALL  Y is 3 * 3 - 1   %> skip
> (2) 2 EXIT  8 is 3 * 3 - 1   %> creep
> (1) 1 EXIT  p(3, 8)   %> creep
> This is possible? (active the mode trace for view execution without tktools but using Java)
> 
These predicates should be independent of which debugger you are using 
-- they simply generate events that are raised at the right time, e.g. 
when a call port needs to be displayed. Currently there are two way to 
handle these events. One set is in tracer_tty.pl, which provides a 
text-based debugger. The other is tracer_tcl.pl, which provides the 
ECLiPSe-side of a GUI interface, and the same code on the ECLiPSe side 
is used for the TkECLipSe/Tktools and Saros. So what you do for the CHR 
debugger should work for all debuggers.

I am slightly surprised that the interface provided by tracer_tty.pl is 
in the example you show above -- are you running an embedded ECLiPSe 
from Java?

If you use eclipse IDE and Saros, then this uses the tracer_tcl.pl 
interface, so you should not see the above.

Cheers,

Kish


-- 
This e-mail may contain confidential and privileged material for the
sole use of the intended recipient. Any review, use, distribution or
disclosure by others is strictly prohibited. If you are not the intended
recipient (or authorized to receive for the recipient), please contact
the sender by reply e-mail and delete all copies of this message.
Cisco Systems Limited (Company Number: 02558939), is registered in
England and Wales with its registered office at 1 Callaghan Square,
Cardiff, South Glamorgan CF10 5BT.