[Scilab-Dev] Scilab interconnection

[Sylvestre Ledru]

Le lundi 15 mars 2010 à 12:08 -0300, Federico Bergero a écrit :
> On Sun, Mar 14, 2010 at 9:30 AM, Sylvestre Ledru
> <sylvestre.ledru at scilab.org> wrote:
> > Le samedi 13 mars 2010 à 16:23 -0300, Federico Bergero a écrit :
> > However, in the family 5, we introduced a event loop (ie a decorrelation
> > of the various events). Though it is not available to a user, with a
> > minimal work, you should be available to lock the interpreter while you
> > run your task and unlock it after.
> > If you are interested by this potential solution, I can send you some
> > pointers on the Scilab code source and some help. I can also apply some
> > of your patches to make it available easily to external codes.
> Ok. Send me info and pointers about how to do this. Is this solution
> possible both in Linux and Windows?
Yes (and also Mac OS X)
Here is two usages of the internal threading capabilities:
http://gitweb.scilab.org/?p=scilab;a=blob;f=scilab/modules/action_binding/src/c/dynamic_menus.c;
http://gitweb.scilab.org/?p=scilab;a=blob;f=scilab/modules/shell/src/c/GetCommandLine.c;

And the send of a Scilab command to the interpreter:
http://gitweb.scilab.org/?p=scilab;a=blob;f=scilab/modules/call_scilab/src/c/SendScilabJobs.c#l41

Mixing both of them should be pretty easy.
Don't hesitate if you have any questions.

> >>  If we had  implemented with call_scilab, the Scilab workspace is lost after the first simulation
> >> (because the program ends and quits).
> >> Perhaps I haven't used it well but I think that if a process uses the
> >> call_scilab mechanism, Scilab doesnt show a GUI, and when the caller
> >> process finishes, the Scilab instance finishes too.
> > Well, no, you control the start and stop of the Scilab session
> > (StartScilab & TerminateScilab). It remains in the same session until
> > you call these functions.
> And call_scilab starts a complete Scilab instance? With GUI? Anyway
> the problem is that this kind of communication wouldn't be available
> after the caller process finishes, in order for a new process to
> communicate with the running Scilab, is that right?
Yes, you will just have to kind a thread open on the Scilab session.

To use call_scilab with the GUI, you just have to do:
	setScilabMode(SCILAB_STD);
	if ( StartScilab(getenv("SCI"),NULL,NULL) == FALSE )
with the include:
#include "scilabmode.h"

This works for me but this has not been testing with the GUI (we did not
know that some users might want to use it this way).

> >> So I was wondering if there is a cleaner mechanism that the one we
> >> have implemented.
> > Well, to talk with an already running application, network (or socket)
> > access seems the best way to go.
> Yes. We've implemented thorught UDP beacuse it is message orientated
> but we now have problems beacuse of UDP packet limit (we cannot send a
> complete matrix in a UDP message), so we are thinking of using TCP.
OK. Please let me know if you are getting somewhere here. I am sure that
other people might want to interact with Scilab this way and it could be
interesting to make a module out of your work.

Sylvestre


-- 
-------------------------
Sylvestre Ledru
-------------------------
The Scilab Consortium
Digiteo
Domaine de Voluceau
Rocquencourt - B.P. 105
78153 Le Chesnay Cedex
France