Ralf Hemmecke wrote: > > as is probably known, I would like to make the IPython notebook a > frontend for FriCAS. > > As I currently understand, there are in principle two ways to achieve this. > > (A) using pexpect and communicating with the FriCAS command line (and > probably heavily relying on ioHook, > (B) adding a zeromq library to FriCAS and thus turning FriCAS directly > into an IPython kernel. > > Method (A) together with recent ipython development > http://ipython.org/ipython-doc/dev/development/wrapperkernels.html > is probably easier to achieve (similar to what was already running in > the SageNotebook). However, I feel that it has some disadvantages, > mainly coming from the fact that (as I understand it now) the flow would go > > notebook --(a)-- K --(b)-- FriCAS > > where K would be a kernel (similar to bash ... see > https://github.com/takluyver/bash_kernel) and connection (a) would be > done via zeromq (http://zeromq.org) whereas connection (b) would be with > pexpect (i.e. a simple text interface). > > I somehow find (B) more attractive, since it would simply look like > > notebook --(a)-- FriCAS > > ZeroMQ looks to me very similar to the socket stuff that we anyway have > in FriCAS only that the messaging protocol would be different. > http://ipython.org/ipython-doc/dev/development/messaging.html > There also seems to exist a library http://zeromq.org/bindings:cl that > could be used. > > What do others say? Would (A) or (B) be the better alternative?
I do not see why you think that there are only two alternatives and especially why you put stress on second one. Basically you need protocol which can transport complex data structures between processes. In 'pexpect' approach you reuse existing text interface at the cost of parsing. AFAIK on 'pexpect' side is done via regexes, which is likely to be slow. On FriCAS side data would go via interpreter parser and type reconstruction and that also takes time. Binary protocols (or even apropriately designed text ones) can be quite easy to parse giving relatively small ovehead (but still notrivial compared to copy). So, form my point of view main difference is between text protocl and binary protocol. Another possibility is running code in a single process. For Python this _may_ be a possibility. Namely, there is Lisp code which works as Python compiler/interpreter. IIRC Martin Rubey tried that in 2008 and simple things worked. My impression is that running Python + Lisp in a single image has problem because frequently Python is really C++, that is real work is done in C++ and Python just wraps it. Interface between Python and C++ "knows" about implementation details which normal code can ignore, so it may cause problem for Python on Lisp. If Python on Lisp could be made to work it probably would be the best solution. Binary protocol is second best and pexpect way is least desirable. Let me add that for user inteface pexpect is probably good enough. Extra comment: FriCAS is single threaded and uses 'select' system call to multiplex between input sources. Code for doing this is crappy (buggy), but usually works. If you want your interface to cooperate nicely with graphics, it should be integrated with this multiplexing code. Namely, 'select' needs to know about all imput sources to properly multiplex between them. And input/output routines must behave in appropriate way (otherwise you will have something like issue 145). > > In particular for (B), it looks like one would have to hook into > "intloopReadConsole" > https://github.com/fricas/fricas/blob/master/src/interp/int-top.boot#L197 and > add the zeromq messaging for the notebook from there. If you want to hook a via text interface than I am not sure if zeromq buys you anything worthwile. -- Waldek Hebisch [email protected] -- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
