IPython + FriCAS

[Ralf Hemmecke]

Hello,

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?

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. Who else would
like to get his/her hands dirty (with coding or just with hints of how
to do it) and dive into "turning FriCAS into an IPython kernel"?

Note that in the above scheme one can change "notebook" with
"qt-console".
http://ipython.org/ipython-doc/dev/interactive/qtconsole.html That would
then be an interface that's not running in a browser.

Ralf

[Bill Page]

Definitely (B). I am interested and would like to help, especially if
the goals include typeset math output (such as LaTeX). Does
qt-console do that?

> --
> 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 fricas-devel...@googlegroups.com.
> To post to this group, send email to fricas...@googlegroups.com.
> Visit this group at http://groups.google.com/group/fricas-devel.
> For more options, visit https://groups.google.com/d/optout.

[Ralf Hemmecke]

On 08/17/2014 06:49 PM, Bill Page wrote:
> Definitely (B). I am interested and would like to help, especially if
> the goals include typeset math output (such as LaTeX).

Well, I think MathJax should be able to do that. I'm not sure whether it
would also be possible to send and render MathML directly.

> Does qt-console do that?

I don't know.

How familiar are you with sockets and they way FriCAS handles the
Read-Eval-Print-Loop?

Ralf

[Bill Page]

On 17 August 2014 12:52, Ralf Hemmecke <ra...@hemmecke.org> wrote:
>
> How familiar are you with sockets and they way FriCAS handles the
> Read-Eval-Print-Loop?
>

Not very familiar.

[Waldek Hebisch]

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
heb...@math.uni.wroc.pl

[Ralf Hemmecke]

>> 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.

> I do not see why you think that there are only two alternatives and
> especially why you put stress on second one.

I'm not claiming that I understand everything in full detail.

From what you wrote, I have the impression that you think of the connection

notebook --(a)-- FriCAS

as something that is done using Python code. Yes, it can probably be
done that way, but then it would basically look like

notebook --(a)-- K --(b)-- FriCAS

and that's not what I favour.

I still may have the wrong understanding of ZeroMQ, but for me it's a
library. So while on the notebook side there is definitely Python,
because all that IPython stuff is done in Python, the FriCAS side needs
no python at all. That was the reason why I cited
http://zeromq.org/bindings:cl , i.e. connection from the fricas side
would be done via a lisp library.

As I see it, I would have to change the definition of serverReadLine
because that is the place from where FriCAS gets its input.

https://github.com/fricas/fricas/blob/master/src/interp/int-top.boot#L199

So I would have to change something here.
https://github.com/fricas/fricas/blob/master/src/interp/server.boot#L73

I don't yet understand all of that code, but since I would basically
have FriCAS run via "fricas -nosman", I guess, the only important line is

not $SpadServer =>
read_-line(stream)

and this would have to be done via listening on the port of the zeromq
connection and get the information from there.

I haven't yet identified the actual output routine, but it's probably
some subroutine below sayString. (But I guess, it will be more
complicated, since I also see TERPRI used at other places, so it's not
totally clear where the lowest communication place is.)

What I'm not sure about is how Ctrl-C or the zeromq heart-beet are handled.

> Extra comment: FriCAS is single threaded and uses 'select' system
> call to multiplex between input sources.

OK, thanks. But I guess, it shouldn't concern my simplistic view of the
system. As I said, I'd rather call AXIOMsys directly, not all these
processes that are usually started by fricas (sman).

> If you want your interface to cooperate nicely with graphics,

I don't. Yes, that's the weak point of my approach. It would exclude
graphics and hyperdoc. Given my work on a HyperDoc replacement, I don't
see a big problem with losing that (YMMV). Losing graphics is, of
course, bad, but I (almost) never use FriCAS graphic anyway, so it
wouldn't be a big loss for me. And furthermore I'd be much more happy,
if we had someone (re-)programming a better graphics system with SVG or
mathplot output. Remember Sage also embeds mathplot figures into their
notebook.

I'm pretty sure that you would be against such an approach, but let me
say that I am more concerned with the current textual frontend than with
that graphics stuff and I will certainly not be asking you to include
such code into FriCAS if it removes features that you or other people
find important. In other words all that work on an IPython connection
can be done in a branch and live there until also a better graphics
system is in shape. Maybe the only thing that I would ask for is to
enable an option (similar to -nosman) that lets users choose there
preferred interface.

Anyway, we are currently only talking about a plan. I fear that without
your help (i.e. pointing me to the right place in the code and probably
also reviewing my code) I'll not be able to turn that plan into working
code.

From a first look at the code I got the impression that I would first
have to abstract all the input/output to go through one dedicated
function (i.e. not using LISP function directly in the code). It looks
as if macros.lisp and msgdb.boot would be a good start to look at.
It seems that TERPRI and PRINTEXP are the lowest-level output function,
but they appear everywhere (even (probably unnecessarily) in .spad code).

I'm not quite sure whether that would handle )read and )spool cases,
since they should probably not be flowing over the zeromq connection.

Any hints are welcome.

Ralf

[Ralf Hemmecke]

Dear Waldek,

You are probably busy with other things. Nevertheless, may I ask you for
a short reply to this mail/thread.

https://www.mail-archive.com/fricas...@googlegroups.com/msg07584.html

You probably have different priorities, that's OK, but I'm somehow stuck
with this ZeroMQ issue. I don't even know whether I can expect a few
little hints from you or whether I should rather figure out everything
on my own.

The most burning questions from my part would be.

1) How would I go to add the ZeroMQ library to FriCAS so that I could
use its functionality from Lisp (or even better from BOOT or even SPAD).

2) In my previous mail I talked about TERPRI and PRINTEXP.
Unfortunately, this all seems to be related to a (hidden) variable
$fricasOutput. Is there somewhere some documentation that would help me
to understand how currently the output is done (with all its redirections)?

3) Do you think it would be enough to figure out about all uses of
TERPRI/PRINTEXP and replace them by a central lisp abstraction so that
output through ZeroMQ could be hooked up there?

4) I certainly only want to modify interactive user input and redirect
that over ZeroMQ. How can I distinguish whether (for example), input
currently comes from a file or from a pipe to stdin? The latter is not
interactive and should, of course not go through ZeroMQ.

Thank you in advance
Ralf

[Waldek Hebisch]

Ralf Hemmecke wrote:
>
> The most burning questions from my part would be.
>
> 1) How would I go to add the ZeroMQ library to FriCAS so that I could
> use its functionality from Lisp (or even better from BOOT or even SPAD).

1) You need to either link or dynamically load the library.
Currently with sbcl, clisp and openmcl only option is dynamic linking.
With ecl and gcl both are possible, but static linking works
better. Theoretically w could use static linking with clisp,
but this looks quite hard to automate. Anyway, look like
'libspad' is handled. You need to write code to dynamically load
the library for Lisp that use dynamic linking and adjust
Makefiles to link it statically in other cases. This
assumes that you have both static and dynamic version
of the library. If you have only static one than you are
out of luck: you can only use Lisps that use static
linking. If you have only dynamic version you may create
a small static library with wrappers calling real
functions in dynamic library. Then you statically link
wrappers and linker/OS takes care of dynamic library.

Once you have linked library to FriCAS image you need
to make available its functions to FriCAS

2) Look at types of arguments/return values. If you have simple
types than existing macros in src/lisp/fricas-lisp.lisp should
work. You use them like:

(fricas-foreign-call |writeablep| "writeablep" int
(filename c-string))

First is Lisp name you want, than C name, return type
and pairs (argument name, argument type). Once you
have Lisp function you can freely use it from Boot and Spad
(in Spad via $Lisp). To get typechecking it is good to write
wrappers in Spad with appropriate types.

Note: this is generic instruction about adding foreign library.
You may look at Lapack thread to get more information.

Note2: After that you will be able to call ZeroMQ functions,
but it does not mean that this will bring you any closer
to your goal. AFAICS to work well within existing framework
you should call ZeroMQ functions from our C code

>
> 2) In my previous mail I talked about TERPRI and PRINTEXP.
> Unfortunately, this all seems to be related to a (hidden) variable
> $fricasOutput. Is there somewhere some documentation that would help me
> to understand how currently the output is done (with all its redirections)?

Sorry, it is a mess. Part of it is inherited. Part is new mess
which replaced old one -- I feel that new mess is a bit less
messy than old one, but not much. Basically, I would like
to get rid of all redirections -- that requires to have
explicit stream arguments from top down to lowest level.
Original code worked redirecting standard Lisp streams.
'$fricasOutput' is an attempt to eliminate redirection
of standard Lisp streams, but is not finished.

I do not expect redirections to be documented: once part
of it is understood well enough it can be safely removed.

>
> 3) Do you think it would be enough to figure out about all uses of
> TERPRI/PRINTEXP and replace them by a central lisp abstraction so that
> output through ZeroMQ could be hooked up there?

There is bunch of other functions that do output -- potentially
about 20. It would be good to sort this out, but ATM do
not count on me doing this: IME such work requres some
interval of time (optimistically a week) where attension is
focused on this task. It is hard to spare such continuous
interval, and even if I had one there are tasks of higerer
priority.

>
> 4) I certainly only want to modify interactive user input and redirect
> that over ZeroMQ. How can I distinguish whether (for example), input
> currently comes from a file or from a pipe to stdin? The latter is not
> interactive and should, of course not go through ZeroMQ.

You probably should not make such distinction. There are input
streams and when you _create_ stream you should know its destination
and conseqently which transport to use. Once stream is created
you should not care. More precisely, user input goes via
'serverReadLine'. If you want to support multiple input
sources than you need to hook into 'serverSwitch' (which
is really C code). File reading is separate, so do not
worry about it.

You may have more trouble with output: all output goes
together and 'session' is responsible for multiplexing it
to right destination.

However you wrote that you do not want to support multiple
input sources. This in particular means no pipes (and
as I wrote files are handled separately) and no need
to multiplex output.

--
Waldek Hebisch
heb...@math.uni.wroc.pl

[Ralf Hemmecke]

Thank you, Waldek, for your prompt reply!

> 1) You need to either link or dynamically load the library.

It sounds that you think that there is a C library that does the the
zeromq stuff. Maybe I got the wrong impression that actually the code at

http://repo.or.cz/w/cl-zmq.git/tree

implements zeromq in Lisp, but now I've looked again and it seems that
you are right.

http://repo.or.cz/w/cl-zmq.git/blob/HEAD:/src/package.lisp#l101

Pfffff... it seems more complicated than I first thought. :-(

>> 2) In my previous mail I talked about TERPRI and PRINTEXP.
>> Unfortunately, this all seems to be related to a (hidden) variable
>> $fricasOutput. Is there somewhere some documentation that would help me
>> to understand how currently the output is done (with all its redirections)?
>
> Sorry, it is a mess.

OK, not your fault. So it means that I have to study a bit.

> There is bunch of other functions that do output -- potentially
> about 20. It would be good to sort this out,

OK, then maybe a good approach would be that I first start documenting.
Of course that will take a lot of time on my part and will probably
thrown away (together with the code) in the end, but someone has to
start. I hope my motivation will not vanish too quickly.

Anyway thank you for your input. It'll take some time to digest your
information.

Ralf

[kfp]

Hi Ralf

> What do others say? Would (A) or (B) be the better alternative?

IMHO definitively (B). Although I've a working IPy notebook/qtconsole app via "core.prefilter" transformers (see below), I would prefer a "kernel" version because 'hacks' are too hard to maintan and not very user friendy (for non Python addics).

A 'native' kernel, however, might be a challenge, and is surely not a "one day project". Fortunately, in the upcoming version IPy 3, it's possible to write simple wrapper kernels (see http://ipython.org/ipython-doc/dev/development/wrapperkernels.html). I'm convinced this will provide a stable and user friendly interface. Regarding 'pexepct' : there are alternatives, e.g. any ssh-client lib (paramiko for instance) provided that you connect via a local/remote sshd (works on Win too, and there is Firefox SSH client in js).

I've also used the butterfly web terminal recently  (http://paradoxxxzero.github.io/2014/02/28/butterfly.html) to interface Fricas on  a Ubunutu box. An easy 'hack' gives you MathJax output. Eventually I've fallen back to the awesome TeXmacs interface. It's the most promising in my view.

Kurt
---

from IPython.core.prefilter import _default_transformers, PrefilterTransformer
from IPython.extensions.axiom import FriCAS

class FricasTrafo(PrefilterTransformer):
    def transform(self, line, continue_prompt):
        """Transform a line, returning the new one."""
        if line.startswith('$'):
            return line.lstrip('$')
        else:
            return "FriCAS0.fricas("+repr(line)+")"


FriCAS0 = FriCAS()
_default_transformers.append(FricasTrafo)

   

[Ralf Hemmecke]

On 08/25/2014 10:53 PM, kfp wrote:
>> What do others say? Would (A) or (B) be the better alternative?

> IMHO definitively (B).

OK. From the many people who replied ;-) , the "native" way seems to be
preferred.

> A 'native' kernel, however, might be a challenge, and is surely not a "one
> day project".

Certainly this will take longer. Given my more or less zero knowledge, I
don't expect something this year.

I would, however, be very happy if I wouldn't have to do this myself.
If there were more enthusiasts that know about networking and/or sockets
(maybe even zeromq) that could speed up that "little" project dramatically.

> Fortunately, in the upcoming version IPy 3, it's possible to

> write simple wrapper kernels.

Yes, I know. And since ipython isn't part of FriCAS nor can one expect
it to exist on the user system, I would rather make a small script and
install IPy3 into a virtualenv. This removes the "problem" with IPy 2 vs 3.

Going the pexpect way, would probably be much faster to achieve
something. But I already feel that this something would have quite some
problems in an ordinary workflow, since not all user inputs that lead to
fricas error messages can be detected. (In particular, I saw already
problems when the compilation aborts in the middle or some Ctrl-C stuff
ends up at an SBCL prompt.

> Eventually I've fallen back to the awesome TeXmacs interface. It's the most
> promising in my view.

Yeah, maybe. Nevertheless, would you be interested in helping with
FriCAS kernel to IPython? What knowledge could you contribute?

Ralf

[Bill Page]

On 25 August 2014 17:19, Ralf Hemmecke <ra...@hemmecke.org> wrote:
> On 08/25/2014 10:53 PM, kfp wrote:

> ...

>> Eventually I've fallen back to the awesome TeXmacs interface. It's the most
>> promising in my view.
>
> Yeah, maybe. Nevertheless, would you be interested in helping with
> FriCAS kernel to IPython? What knowledge could you contribute?
>

I strongly agree that TeXmacs is by far the "most promising" user
interface for FriCAS. If someone has time available for work on a
graphical user inferface, then I think it is best spent on the
FriCAS/TeXmacs interface. I have some patches to support a much
larger set of symbols in the TeXmacs interface and would like it to be
included in a future release.

But of course if for some reason someone is interested in a
browser-based interface, I think what Ralf has in mind is a good idea
and I am prepared to help with that too.

[kfp]

Yeah, maybe. Nevertheless, would you be interested in helping with
FriCAS kernel to IPython?

By all means, but the journey is the reward. Since, as already mentioned, I have a working app by the prefilter method and so do not expect to get a 'nicer' interface (MathJax doesn't look very proper, therefore I use tex->png, especially in qt console as there MathJax doesn't work anyway).    
 

What knowledge could you contribute?
 

Not very much, I'm afraid. Some cl and zmq knowledge but I've no idea of the Fricas internals (esp. hooks). I've looked into some other kernels like IHaskell, IScala and so on. Those were written by much smarter people than me, yet there are still a lot of problems indicating that there is no straight way.

See e.g. : http://python.6.x6.nabble.com/Simple-Kernel-Example-td5044217.html
    
There is a nice example kernel (https://github.com/dsblank/simple_kernel) by Doug Blank (a result of the thread above?) which might serve as a starting point. In the first place I would setup the cl language bindings for zmq for the various dialects (sbcl, clisp, gcl, ecl ..) then I would try to translate the example kernel to cl to have a toy. However, my cl is so rusty that I doubt to get it running within reasonable time ;)

Anyway, you can count on me.

Kurt

[kfp]

    I have some patches to support a much

larger set of symbols in the TeXmacs interface and would like it to be
included in a future release.

Yes, please. Any improvement of the TeXmacs interface is most welcome. 

[kfp]

A Common Lisp kernel for iPython frontends (yet far from complete)
This may also be of some use. https://github.com/agentultra/butler

 

[kfp]

Going the pexpect way, would probably be much faster to achieve
something. But I already feel that this something would have quite some
problems in an ordinary workflow, since not all user inputs that lead to
fricas error messages can be detected. (In particular, I saw already
problems when the compilation aborts in the middle or some Ctrl-C stuff
ends up at an SBCL prompt.

I've written a prototype: https://github.com/scios/fricas_kernel. It's incredible simple compared to a 'full' kernel and surprisingly stable. One could build on this wrapper version to explore its limits before attempting the hard way ;)

Kurt

p.s. forgot to mention the link to the pre-filter version in my former post: https://bitbucket.org/kfp/fricasipy. However, I do not recommend it (outdated). This new wrapper method is by far superior. 

 

 

[Ralf Hemmecke]

On 08/29/2014 05:53 AM, kfp wrote:
> I've written a prototype: https://github.com/scios/fricas_kernel.
> It's incredible simple compared to a 'full' kernel and surprisingly
> stable.

Ah! Bravo and thanks!

I managed to get it running. Coooool!

> One could build on this wrapper version to explore its limits before
> attempting the hard way ;)

Well, I have some comments:

1) You are just searching for the FriCAS prompt pattern. You could have
used the iohooks to inject a very specific string that makes it easier
to detect prompt, latex, and type.

2) Maybe it would be a good idea to already test my new TexFormat.
Something I could probably try to investigate.

3) I'm definitely for option (B), i.e., something without pexpect.
What exactly do you think can be tested with your prototype.

Anyway, I like to be able to run fricas locally in the browser. Wonderful.

Ralf

[kfp]

On Monday, 1 September 2014 00:29:10 UTC+2, Ralf Hemmecke wrote:

Well, I have some comments:

1) You are just searching for the FriCAS prompt pattern. You could have
used the iohooks to inject a very specific string that makes it easier
to detect prompt, latex, and type.

iohooks?  Are they documented somewhere? Indeed it would be much easier if one could request specific information than to filter it out by regexp. 

 

2) Maybe it would be a good idea to already test my new TexFormat.
   Something I could probably try to investigate.

By all means. As you can see in the notebook sample there are some caveats. Moreover I had to prefix all TeX output in order to get MathJax work (\sp,\sb,\leqno ...). BTW you can play around with the code at its destination (somewhere in /.../dist-utils), so you don't have to reinstall the kernel after editing.
 

3) I'm definitely for option (B), i.e., something without pexpect.
   What exactly do you think can be tested with your prototype.

Of course, (B) should be the goal. However, what you will see in the frontend is not much different from what you see using the wrapper kernel. I'm not yet really convinced if it is worthwile to (whoever) undertake such a tedious task, at least not before recognizing the benefits, though I admit the qtconsole is quite handy if its features are fully utilized.

What I suppose should/could be tested:
- completion already works (bit primitive) but it should provide more information (as in Python), i.e.
- inspection and history
- syntax highlighting (pygments)
- plotting (matplotlib?)
...

and finally, rather important to me, the re-usability of the notebook's. I agree that for educational purposes it's nice and tidy, however, what can I do with them? With TeXmacs I can write (in plain LaTeX) papers, slides and so on using executable folds which save a lot of typing and if you want to submit, just do 'export', voilà. Sorry for advocating again ...
Kurt








  

 

[kfp]

Hi

I glanced at the plotting capabilities of Fricas in order to provide some basic functionality for the 'kernel'. Naturally, I also searched this list for any hints as I try to avoid reinventing the wheel. After all the matter is quite confusing to me. Thus I dare asking some questions:

a) Is there any strategy to refurbish graphics output?
b) Is there any library which provides (file) output for some of the common plotting/viewing packages? E.g. GLE, Asymptote, Gnuplot, matplotlib, Paraview, jmol  ...
For instance GLE and Asymptote provide nice ps output which could be automatically inserted into a frontend (IPy, TeXmacs). In TeXmacs it's even possible to receive 'ps' out of Fricas directly with the \x2ps:..\x5 sequence. Therefore: is any of the current plotting routines able to give Postscript output to stdout?
c) What is the state of the Plot() domain? The 'coerce' gives some output (e.g. =plot((x:DF +-> x^2),1.0::DF..2.0::DF)@Plot), however, what was the purpose of this? Terminal graphics?

I found some promising links in the thread: Re:[Axiom-mail] gnuplot on axiom-wiki , but the links seem to be dead. I read there that Bill Page had something in the direction of Gnuplot script output. This could be a starting point and I would be rather interested to use it in texmacs. The following two functions allow to insert graphics into tm while using the plugin, so a ready-to-use 'myplot' command could easily be patched up (not only for gnuplot).

tmcmd(cmd:String):Void == print (concat [char 2,"command:",cmd,char 5]);

tm_inline_image(url:String):Void ==
   options:=" _"_" _"_" _"_" _"_" ))"
   q:="_""
   tmcmd(concat ["(make-inline-image (list ", q, url, q, options])
  

Kurt

[Bill Page]

There is some GNUplot stuff here:

http://axiom-wiki.newsynthesis.org/GnuDraw

It would probably be quite easy to make this work in TeXmacs.

But maybe more interesting is the scenegraph extensions to FriCAS by
Martin Baker:

http://www.euclideanspace.com/prog/scratchpad/mycode/graph/

[kfp]

On Friday, 5 September 2014 23:28:22 UTC+2, Bill Page wrote:

There is some GNUplot stuff here:

http://axiom-wiki.newsynthesis.org/GnuDraw

Just what I looked for!.Thank you very much!
 

It would probably be quite easy to make this work in TeXmacs.

We'll see. I'm going to try ... report follows
 

But maybe more interesting is the scenegraph extensions to FriCAS by
Martin Baker:

http://www.euclideanspace.com/prog/scratchpad/mycode/graph/

Well, 3d is another topic ;)  

Thanks
Kurt

 

[kfp]

On Friday, 5 September 2014 23:28:22 UTC+2, Bill Page wrote:

There is some GNUplot stuff here:

http://axiom-wiki.newsynthesis.org/GnuDraw

Just what I looked for!.Thank you very much!
 

It would probably be quite easy to make this work in TeXmacs.

We'll see. I'm going to try ... report follows

The 'gnuplot' function works perfectly whereas GnuDraw requires X (unless I've missed something?). Consequently the process FriCAS => gnuplot script => set terminal [ps|png|...] => Insert into frontend is a simple yet reliable method to get graphics into the frontends (not only with gp). For the IPy kernel (wrapped or native)  I see no other way to embed graphics at the moment.
 

 

But maybe more interesting is the scenegraph extensions to FriCAS by
Martin Baker:

http://www.euclideanspace.com/prog/scratchpad/mycode/graph/

Well, 3d is another topic ;)  

I glimpsed at the sources, well, tremendous work .. which needs some time to understand. At least one can see that people have been contemplating on this subject.
 

Thanks
Kurt

 

[Bill Page]

On 6 September 2014 10:27, kfp <nil...@gmail.com> wrote:
>>
>> On Friday, 5 September 2014 23:28:22 UTC+2, Bill Page wrote:
>>>
>>> There is some GNUplot stuff here:
>>>
>>> http://axiom-wiki.newsynthesis.org/GnuDraw
>>
>

> The 'gnuplot' function works perfectly whereas GnuDraw requires X (unless
> I've missed something?). Consequently the process FriCAS => gnuplot script
> => set terminal [ps|png|...] => Insert into frontend is a simple yet
> reliable method to get graphics into the frontends (not only with gp). For
> the IPy kernel (wrapped or native) I see no other way to embed graphics at
> the moment.
>

Why do you think that GnuDraw requires X? If it does, then perhaps I
am missing something. :)

[kfp]

On Tuesday, 9 September 2014 02:43:21 UTC+2, Bill Page wrote:

On 6 September 2014 10:27, kfp <nil...@gmail.com> wrote:
>>
>> On Friday, 5 September 2014 23:28:22 UTC+2, Bill Page wrote:
>>>
>>> There is some GNUplot stuff here:
>>>
>>> http://axiom-wiki.newsynthesis.org/GnuDraw
>>

Why do you think that GnuDraw requires X?  If it does, then perhaps I
am missing something. :)

You are right (how stupid of me) it doesn't need X at all. The term 'viewport manager' in the output snippet below let me assume that some window should pop up ;) Of course, output goes to the file specified and gp works fine. I'm glad that it works, it's much more sophisticated than the simple gnuplot function.

Thanks and sorry for the confusion
Kurt     

 (8) -> gnuDraw(%,z=-5..5,"testfile1.dat",title=="fun2")
   Compiling function %I with type DoubleFloat -> DoubleFloat
   Graph data being transmitted to the viewport manager...
   FriCAS2D data being transmitted to the viewport manager...