Lines Matching defs:and
11 % the License for the specific language governing rights and limitations
37 interface, Tcl and {\eclipse} code communicates by sending and receiving
43 difference that the {\eclipse} program is a separate program and not
48 \item The connection between the Tcl and {\eclipse} processes are established
50 a different machine and platform from the {\eclipse} process.
55 \item For the programmer, the embedding and remote interfaces are largely
56 similar, and once the connection is established in the remote interface,
57 the same code on the {\eclipse} and Tcl sides can be used for both interfaces.
62 program. However, as the Tcl and {\eclipse} processes are not as tightly
64 the Tcl and {\eclipse} processes is likely to be slower.
68 The interface is used by starting separate {\eclipse} and Tcl processes, and
70 attached, the Tcl and {\eclipse} processes can communicate much as in the
73 and further I/O queues can be established between the {\eclipse} and Tcl
78 disconnection will terminate and clean-up the links between the two
80 application to be usable through both the Tcl remote and embedding
82 interface is the code associated with starting and termination of the
83 application (the attach and detach operations in the case of the remote
86 The interaction between the Tcl and {\eclipse} is mediated by a version of
89 process, and the {\eclipse} side, which is generally the {\eclipse}
91 an embedded {\eclipse}, or the {\eclipse} process and other attached remote
139 \section{Attaching and Initialising the Interface}
145 flexible \bipref{remote_connect_setup/3}{../bips/kernel/externals/remote_connect_setup-3.html} and \bipref{remote_connect_accept/6}{../bips/kernel/externals/remote_connect_accept-6.html}
150 occurs, then the connection is established and the interface is set up.
156 hostname and the port number that the Tcl side should connect to:
163 On the Tcl side, ec_remote_init is called with the hostname and port number
174 {\eclipse} side, which specifies the hostname ({\it host}) and port
179 details). {\it pass\/} and {\it format\/} are optional arguments for a simple
191 such as the control connection and the connection to allow rpc goals to be
195 the {\eclipse} side, and the init_command on the Tcl side), and the two
197 and {\it remote_connect/3} returns only when control is handed over to the
212 one side is outdated, e.g.\ if the remote Tcl interface used and the {\eclipse}
224 However, the connection must be initiated from the {\eclipse} side, and the
227 if a third party somehow knew which Address to connect to, and follows the
241 {\eclipse} side and then accepting a client connection from the Tcl
242 side. The accept command is told where the client connection is from, and
246 probably been compromised, and the two side should disconnect.
249 between the remote side and the {\eclipse} side is encrypted. If the
253 \section{Type Conversion Between Tcl and {\eclipse}}
265 main method of interacting and communicating with {\eclipse} in the remote
267 arguments when the call is made; and
279 and can be used from within Tcl queue event handlers. However, an
284 the {\eclipse} goal is constructed from {\it goal} and {\it format},
294 Queues should be used to set up long-term I/O links between {\eclipse} and
297 from one side to the other: on one side, data is written to the queue; and
301 be in EXDR format, in which case both sides need to read and write using
307 stream number, and has a user supplied symbolic
308 name. These all refer to the same queue. Queues are created using the symbolic names, and the Tcl side
310 names and stream numbers. The built-in Tcl I/O commands accepts the Tcl
311 channel name for operating on the queue, and for
325 sending and receiving of data across the queue are synchronised. This is
327 {\eclipse} and Tcl in a coroutine-like manner to ensure that data that is
335 different, in that the queues in the embedded case are memory queues and
339 this, and not all differences can be hidden. This is discussed in more detail in section~\ref{remotediff}.
345 not necessarily transfer control between {\eclipse} and
349 directly to the socket connections with no buffering, and there is no concept of a socket
351 transfer and processing of the data.
366 The processing of data on queues (synchronous and to some extent
373 is, an event is raised, and the event handler goal associated with the event
381 The handler is expected to read the data off the queue and process it.
385 invoked to read the data off the queue and display it on the window.
388 case, the handler is expected to generate the data and write the data onto
389 the queue, and send it to the other side. For example, on the Tcl side, a
396 For each queue and for a particular direction of data flow, a
401 triggering the data provider and the data consumer.
412 Creates a synchronous queue between Tcl and {\eclipse} sides. On
415 The {\it mode} argument indicates the direction of the queue, and
425 command\/} and {\it event\/} specifies the data handler for the
437 ec_stream_name}. The queue is closed on both the Tcl and {\eclipse}
438 sides, and bookkeeping information for the queue is removed.
443 connections between the two sides, and so the queues should not be created
444 and closed on a short-term basis. For quick interchange of data, it is
453 {\eclipse} side initially has control and flushes
470 \parbox{6.5cm}{{\eclipse} returns from flush, and continue executing the following code}&\\
477 invoke, and any user defined arguments. When the handler is invoked, two
479 the {\eclipse} stream number for the queue, and the number
481 off the queue and process it. The following predefined Tcl
486 Read {\it length\/} bytes from the specified queue and insert the data
489 queue, {\it length\/} and {\it stream_nr\/} would be supplied when
496 and an ok-button for closing. The data is read as normal
513 side. The programmer can write to the queue, and to send the data to the
525 Tcl, and the Tcl handler, in this case {\bf ec_stream_to_window_sync},
526 would be invoked. This reads the data on the queue (hello, and anything
527 else that has been written since the last flush), and puts it into the text
529 {\eclipse} stream number for the queue and the number of bytes sent as extra
530 arguments. The textwin widget and the tag red must
567 producer. This handler is initiated when {\eclipse} side has control, and
571 data to the queue, and call the Tcl remote interface command {\bf ec_flush}
573 control is returned to the {\eclipse} side, and the read operation is
583 to-{\eclipse} queue. The data is written to the queue and flushed
586 the data supplied by the Tcl handler, and continue execution the following code}&\\
593 queue so that the data would be transferred and processed on the {\eclipse}
595 handler, and also to invoke an {\eclipse} data consumer handler (see the
602 with the {\eclipse} stream number {\it eclipse_streamnum} and hands over
612 and the amount of data written is not known. However, the programmer may
613 have kept track of the number of bytes written inside the handler, and thus
619 connection, and without knowing the amount of data, it is not possible in
625 flushes the data, and the Tcl side then continues executing Tcl code
630 ec_flush} is invoked, control is actually transferred to {\eclipse}, and
633 handler finally finishes, control returns to {\eclipse}, and the original
634 read operation reads the data from the buffer and continues. This extra
641 invoke, and any user defined arguments. When the handler is invoked, an
644 data required, output it onto the queue, and call {\bf ec_flush} to flush
646 {\eclipse}, {\eclipse} will print a warning and return control to Tcl side.
654 and an ok-button. The text typed into the input field will
674 {\eclipse} handler and can be omitted as that is the default. This queue
686 When the {\eclipse} side reads from myqueue, and the queue contains no data
688 control will be handed over to Tcl, and {\bf ec_input_popup}
721 needs the Tcl channel name of the queue to write to, and this is provided
724 arguments in this case, both the queue number ({\it Stream}), and the
731 consumer. This handler is initiated when Tcl initially has control, and
733 {\eclipse}, and if the {\eclipse} handler is defined, this is invoked to
745 \parbox{6.5cm}{The {\eclipse} handler associated with the queue is called to consume and
755 {\eclipse} side does not see this data, and the event not raised, until the
756 data is flushed by {\bf ec_flush} and copied by {\eclipse} to its
757 buffer and, if the buffer was initially empty, the event would then be raised.
810 Creates a socket stream between {\eclipse} and Tcl with the name
812 stream is bidirectional, and can be written to or read from at both
815 and has no effect on the nature of the queue. The procedure
828 name of {\it ec_stream_name}. The queue is closed on both the Tcl and {\eclipse}
829 sides, and bookkeeping information for the queue is removed.
836 between {\eclipse} and Tcl sides without transfer of control.
843 between {\eclipse} and Tcl than the synchronous queues.
851 invoked and executed on the Tcl side while {\eclipse} side still has control, with the
856 available on the queue at the Tcl side and never wait for more data.
875 control, and so there would not be an
879 Output and flush
881 put into non-blocking mode, so that the data is buffered and the operations
883 to write and call the code to read the data from the queue on the {\eclipse} side when
898 executed, and this goal should read the data from the queue.
900 queues, the data is not buffered, and the handler goal is called every time
909 and Len is the number of bytes sent (this is supplied by {\bf ec_flush}, if
919 printed on a synchronous from-{\eclipse} queue, and handled by a Tcl data
920 consumer handler which prints the trace line and waits for the user to type
935 (\verb'debug_traceline'), and the asynchronous queue (used only in a
942 should output the trace-line, and wait for a debug command, process the
943 command, and carry on:
955 % read the command from debug_input and process it
970 called, control is handed over to the Tcl to handle the data, and the
991 stream}) and number of bytes sent ({\it length}) are appended as
994 simply read the trace-line as an EXDR term, and placing the resulting
1001 and the handler continues its execution beyond the {\bf tkwait}. The
1007 Tcl side carries on (and happens to finish immediately after the {\bf
1009 has finished, and the {\eclipse} side continues execution after the
1011 the tracer command, and this command is acted on.
1032 ;# get input for the queue and send to ECLiPSe side
1051 argument supplies the {\eclipse} stream number for the queue and the length
1063 a simple procedure which reads the data on the queue and places it on the
1078 invoked, and is the {\eclipse} stream number of the queue. The procedure
1079 simply reads the data from the corresponding Tcl channel and display the
1125 The remote queues connecting {\eclipse} and Tcl are given different names
1130 the one that is supplied in {\it ec_queue_connect\/} and {\it
1157 \section{Additional Control and Support}
1161 interaction of the Tcl and {\eclipse} sides, such as explicit transfer of
1162 control between {\eclipse} and Tcl, and the disconnection of the Tcl
1163 and {\eclipse} sides. The interface also provides support for special
1171 up various data queues between the two sides, and defining the actions to
1180 \subsection{Disconnection and Control Transfer Support}
1185 may be initiated from either side. In addition to cleaning up and closing
1188 event on the {\eclipse} side, and a call-back on the Tcl side), which can
1189 be used to perform extra application specific cleanup and shutdown
1192 For the transfer of control from Tcl to {\eclipse} and vice versa,
1197 call-back when control is transferred to {\eclipse} and reenabled when
1205 expected to eventually handed back control implicitly to {\eclipse}, and
1208 whenever the control is yielded, and the other is only executed when the
1228 will return 1 before connection and after disconnection.
1244 ({\it yield}), and when the Tcl side is
1246 disconnect}). The {\it start} and {\it end} commands are called
1259 two sides can no longer communicate, and {\it ec_running\/} will be
1269 automatically with {\it side\/} set to eclipse, and the disconnect
1284 Control}. This will close all connections between {\eclipse} and
1298 % automatically flush at the end of every line (and so transfer the data
1309 % for simplicity, the host and port are fixed.
1349 # this creates the gui_output from-ECLiPSe queue, and then uses an
1356 # this button initiates disconnection and terminates the Tcl program
1358 # only start and end commands given; the others default to no commands
1374 Figures~\ref{remote-eclipse} and \ref{remote-tcl} shows a simple example of
1378 program should then be started on the same machine, and the attachment will
1379 be connected using the fixed host and port address. During the
1384 Tcl data consumer handler {\bf ec_stream_output_popup} handles and display the data on the Tcl side on a
1387 button is disabled when {\eclipse} side has control, and this is done by
1388 setting up the appropriate call-backs to disable and enable the button in
1393 disconnection ensures that both the {\eclipse} and Tcl program terminates.
1401 {\eclipse} and Tcl. An example of this is the Tkeclipse development tools.
1404 handle the connection and disconnection of the Tcl and {\eclipse}
1412 The supported compatible methods of communicating between Tcl and
1413 {\eclipse} in the two interfaces is via the {\bf ec_rpc} calls and the use
1432 invoked, and this information must be used if the Tcl read is not
1450 there are no asynchronous queues, and {\bf ec_async_queue_create} is
1451 aliased to {\bf ec_queue_create}, and a uni-directional queue is
1456 In summary, to write code that will work for both the remote and embedded
1458 performed, and a handler ({\it command\/} argument) provided. The Tcl
1465 to the same file systems, and being able to distinguish whether the
1473 returns remote for the remote interface, and embedded for the