Re: [eclipse-clp-users] looking for AsyncEclipseQueue sample code

On 03/01/2011 14:13, -dp- wrote:
> Thanks for the reply, Kish. I worked out a solution at the end of last week
> that's a little different than either of our prior ideas. More below...
>
> On Mon, Jan 3, 2011 at 4:38 PM, Kish Shen<kisshen_at_cisco.com>  wrote:
>
>
>> I am also not quite sure I understand the interaction you have (or want to
>> have), with the to/from queues, execution of ECLiPSe is 'paused' when the
>> Java side has control, regardless of what flavour of interface you are
>> using. This was a very deliberate design decision, to keep the interaction
>> between ECLiPSe and Java simple.
>>
>
> Yes, I appreciated the simplicity of this single-threaded design until I
> realized I needed an interactive visualization, and that interactivity
> wasn't possible within the single-threaded design. To boil it down to
> essentials, a button that pauses Eclipse can't notice button presses unless
> the listener of that button is run on a separate thread.
>

The essential idea of the 'control' is that only the side that has 
control can initiate the sending/receiving of data from the other side.
Once you initiate this action, control is passed to the other side. This 
is managed via the synchronous queues.

I think what you are calling interactive is that you want the user to be 
able to interact with UI (such as pressing buttons) at any time. As I 
think you worked out, this does not mean that you need to immediately 
send whatever the interaction represent to ECLiPSe side. You can store 
this information as you have done, and only send it to ECLiPSe when the 
Java side has control.

The ECLiPSE GUI (TkECLiPSe/TkTools) has quite a few interactions like 
this. The external language is Tcl/Tk in that case, but the ECLiPSe side 
code was reused for Saros, which is written in Java. Perhaps you want to 
look at that?

One more suggestion is that you should avoid sending ECLiPSe goals from 
the external language to ECLiPSe as much as possible. You mentioned that 
you were thinking of sending sleep/1 to ECliPSe. Instead of doing that, 
I recommend that your queue should implement some sort of 'API', in 
which simple messages are sent (such as 'go to sleep'), and implement 
the needed code on the ECLiPSe side. [As you found out, 'sleep' is 
actually not needed, as ECLiPSe side is basically stopped when Java has 
control, and you can simply get ECLiPSe side to sleep by not passing 
control back to ECLiPSe].


>
> Before explaining my solution, here's a bit of background: I have a core app
> on the CLP side as well as a bunch of tests where each test is defined by an
> .ecl file to load and a list of strings representing what the output of the
> test should be. I wanted my visualization to allow the user to select which
> test to run, then display incremental results as they arrived on the "from
> eclipse" queue, then indicate overall success or failure, and finally permit
> the user to run any other tests. I recently asked about how I might clear
> away compiled rules so I could permit "clean" followup tests, and there was
> a good suggestion to use modules, but I discovered that OutOfProcessEclipse
> actually ran much faster than EmbeddedEclipse on my low-end WindowsXP
> laptop, and destroying/creating a new OutOfProcessEclipse for each test was
> similarly fast and easy. But I still had the problem of a non-interactive
> interface.
>
> I realized that I just needed to put the code that creates the
> OutOfProcessEclipse in its own thread. [btw, this code started from
> QueueExample2.java as given in the standard examples and has changed fairly
> little over a year except for moving the destroy call into a 'finally' block
> -- I suggest making the same change to the example code, to anticipate cases
> where EmbeddedEclipse is replaced with OutOfProcessEclipse and an exception
> would otherwise leave an orphaned CLP process running. At least, that's what
> I think would happen.] Also, the UI's 'next input token' button listener
> sets a boolean indicating whether the button has been pressed, and if that
> boolean is still false, dataRequest() calls wait() on an object whose sole
> reason to exist is to receive wait() and notifyAll() calls. The call to
> wait() leads dataRequest() to block, which also causes CLP to block, saving
> cycles while the UI remains responsive on the other thread. Not only does
> the button's listener maintain a boolean, but also it calls notifyAll() on
> the special obj whenever the button is pressed, thereby releasing
> dataRequest() to pass the next input token to Eclipse.
>
> Note that causing dataRequest() to block keeps Eclipse from trying to do
> anything when there actually isn't any work for it to do, saving cycles.

I suspect that the documentation of the Java interface may not be very 
good at providing a 'high-level' view of the interface, as it 
concentrates on the details of the interface. We have a paper that 
describes a high-level view of the interface, which you can download from:

http://www.eclipseclp.org/reports/eclipse_generic_interface.ps.gz

Hopefully it should give a better description of the 'high-level' ideas 
behind the interface.

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.