[fricas-devel] Using aldor FFI to link mathgl

[Riccardo GUIDA]

Hi

Quite dreamy, I was thinking at the conceptual possibility of writing a spad wrapper for the mathgl graphics library [1].

One could make spad-system-calls (systemCommand$MoreSystemCommands) sending scripts in mgl language to the mgl interpreter [2] (in the spirit of Bill's GnuDraw) or one could try to link the shared objects from the available C interface [3].

I've seen Waldek's experimental lapack package [4]. IIUC correctly the equivalent in this case would be spad functions calling lisp function wrappers which make "alien-calls" to functions in the shared objects from C.

I was wondering, waiting for a FFI for spad, would not be possible/realistic/efficient to prepare aldor wrapper functions that directly call the external C functions, then "somehow" compile these functions via FriCAS, and finally expose them? I'm sorry I'm vague but I never used aldor.

Riccardo

[1] http://mathgl.sourceforge.net/doc_en/MathGL-features.html#MathGL-features
[2] http://mathgl.sourceforge.net/doc_en/Utilities.html#Utilities
http://mathgl.sourceforge.net/doc_en/UDAV.html#UDAV
[3] http://mathgl.sourceforge.net/doc_en/C-interface.html
[4]http://www.math.uni.wroc.pl/~hebisch/fricas/lapack/

[Kurt Pagani]

BTW: I found the GLE prototype again (https://kfp.bitbucket.io/tmp/GLE.html).
May certainly compete with mathgl regarding quality ;)

There's also a patch for view2/3d somewhere.
https://nilqed.github.io/drawfe/


-------- Forwarded Message --------
Subject: Re: [fricas-devel] Using aldor FFI to link mathgl
Date: Wed, 1 Aug 2018 22:03:28 +0200
From: Kurt Pagani <***@gmail.com>
To: Riccardo GUIDA <***@gmail.com>

Hi Riccardo

Post by Riccardo GUIDA
Hi
Quite dreamy, I was thinking at the conceptual possibility of writing a spad
wrapper for the mathgl graphics library [1].

There are a lot of prototypes around for FFIs and a lot of spad interfaces to
graphics packages like gnuplot,gle,asymptote,paraview,mathmod,plotly ...
Lisp interfaces (e.g. like vgplot) are almost trivial to access from spad,
whereas C might be trickier (see [2]). As a rule of thumb, you can interface
almost any package from SPAD via CFFI (https://common-lisp.net/project/cffi/).



[1] http://goto.glocalnet.net/volkers/vgplot/vgplot.html
[1] https://parasol.tamu.edu/~gdr/OpenAxiom/ffi-draft.pdf


BTW: I'm implementing plotly.js in the new jupyter kernel
(https://github.com/nilqed/spad_http) in a similar way.

http://axiom-wiki.newsynthesis.org/SandBoxPlotly?root=SandBox

Unfortunately, the js script gets blocked, but the produced html snippet works
fine locally.

Best
Kurt

[Riccardo GUIDA]

Dear Kurt,

a lot of infos: thanks! BTW A list of all FriCAS non-core packages available on internet would be quite helpful to new users, hope Ralf one day will add it to the github site


(Kurt)> May certainly compete with mathgl regarding quality ;)

I do not want to enter in graphics-lib faith wars :) -- I must say I do not care the lib as far as standard features are available and layout is reasonably good.

As for mathgl: I spent (and I'm spending) some hours in trying to clarify the question of angles (theta,phi) in viewport, and I rapidly realized that the C code is -- how to say that politely -- "quite intricate" (tons of global variables and includes, verbatim code repetitions, unnecessarily repeated computations of geometrical matrices, mysterious changes of signs every here and there). For instance, nowadays, each time you plot a single 3D point in view3D you compute two 4x4 matrix products (of which one involving the *identity matrix*) to recover the matrices describing the global geometry (which is shared among *all* points in a given object). So, to calm my stomach ache, I just started to think how I would replace viewmanager and hyperdoc (and maybe socket manager) if I was a programmer and to dream of a nice Qt interface (mathgl is self contained but Qt friendly).



As for spad_http: I did not follow your spad_http project in the last months and now I'm really impressed by the the fact that you managed to have Jupyter working for spad and with some graphics support: bravo!

On the other hand, I must say that there a few things in spad_http that disturb me :( and (for the moment) prevent me from rush and install it in my production system: basically my motivations are due to paranoia and ignorance, which may pass with time & study of your code. Let me impudently expose them:

1)
I do not like the idea of having a package loader (quicklisp) that installs things in my production system (where btw?). IIUC, looking at the *.asd files, at each start of the kernel quicklisp is called to load your webSPAD server, which depends only on hunchentoot which :depends-on (:chunga, :cl-base64, :cl-fad, :cl-ppcre :flexi-streams :md5 :rfc2388 :trivial-backtrace :usocket :bordeaux-threads).

In debian I have py2 and py3 packages for all the 3 needed main dependences: requests, plotly and Hunchentoot: why should I need quicklisp at all?

Would not be better to keep install of dependencies as an optional command, well separated from kernel start & run?

2) (less severe, I guess)

Why do you hardcode the dependence on python 2 ?

On my side I have Jupyter running in python 3 (simpy is stopping support of python2 and sagemath working towards supporting py3). I do not know if I can safely install debian packages for python2-jupyter and python3-jupyter, so I would prefer to patch your code for py3.

Would not be better to stay py2/py3 agnostic and possibly leave the choice to the user via configuration or environmental variable?


3) (Naive & impudent)

Why did you introduce a dependence on hunchentoot and drop the original python-only Jupyter kernel wrapper or the lisp one? Zero dependencies is better than one dependency: are the latter really impossible?

Riccardo

[Kurt Pagani]

Dear Riccardo,

Post by Riccardo GUIDA
Dear Kurt,
a lot of infos: thanks! BTW A list of all FriCAS non-core packages available on
internet would be quite helpful to new users, hope Ralf one day will add it to
the github site

Well, "proof of conecept" is one thing, "production quality" another. That's why
I like the "SandBOX" where users may pick up what they need.

Post by Riccardo GUIDA
(Kurt)> May certainly compete with mathgl regarding quality ;)
I do not want to enter in graphics-lib faith wars :) -- I must say I do not care
the lib as far as standard features are available and layout is reasonably good.

Neither do I. There are so many good libs that we're spoilt for choice. What
probably counts is a) maintainability and b) ease of implementing/use. IMO
"mathgl" is not so easy to interface like others providing the same
functionality/quality as well.

Post by Riccardo GUIDA
As  for mathgl: I spent (and I'm spending) some hours in trying to clarify the
question of angles (theta,phi) in viewport, and I rapidly realized that the C
code is -- how to say that politely -- "quite intricate" (tons of global
variables and includes, verbatim code repetitions, unnecessarily repeated
computations of geometrical matrices, mysterious changes of signs every here and
there). For instance, nowadays, each time you plot a single 3D  point in view3D
you compute two 4x4 matrix products (of which one involving the *identity
matrix*) to recover the matrices describing the global geometry (which is shared
among *all* points in a given object). So, to calm my stomach ache, I just
started to think how I would replace viewmanager and hyperdoc (and maybe socket
manager) if I was a programmer and to dream of a nice Qt interface (mathgl is
self contained but Qt friendly).

Only now do I probably understand what you mean. You'd like to replace Fricas'
graphics completely (C-code+viewXY?). It's admittedly true what you've been
criticizing above, however, there is surely one merit: it worked for years
without heavy maintenance. Replacing such long-standing components will (IMO)
require quite a well staffed development team.

Post by Riccardo GUIDA
As  for spad_http: I did not follow your spad_http project in the last months
and now I'm really impressed by the the fact that you managed to have Jupyter
working for spad and with some graphics support: bravo!
On the other hand, I must say that there a few things in spad_http that disturb
me  :(  and (for the moment) prevent me from rush and install it in my
production system: basically my motivations are due to paranoia and ignorance,

To preclude misunderstandings: it's not intended for production yet (far from
;). That's why I'll condense the answers, but in a nutshell, the whole setup is
just for ease of devlopment at the moment.

Post by Riccardo GUIDA
1)
I do not like the idea of having a package loader (quicklisp) that installs
things in my production system (where btw?). IIUC, looking at the *.asd files,
at each start of the kernel quicklisp is called to load your webSPAD server,
which depends only on hunchentoot which :depends-on (:chunga, :cl-base64,
:cl-fad, :cl-ppcre :flexi-streams :md5 :rfc2388 :trivial-backtrace :usocket
:bordeaux-threads).

The "quicklisp" is just a local version (independent of your systemwide and/or
personal quicklisp). You certainly know that the "local-projects" folder is only
an easy way to load any package having a "asdf" file, i.e. in principle nothing
has to be loaded from the internet.

Post by Riccardo GUIDA
requests, plotly and Hunchentoot: why should I need quicklisp at all?

Wow, I really didn't know that "Hunchentoot" is available by "apt". Good news,
indeed. Besides this, we don't need "quicklisp" in the end ...

Post by Riccardo GUIDA
Would not be better to keep install of dependencies as an optional command, well
separated from kernel start & run?

Yes, of course. The "start" procedure as it is by now will be changed anyway.
We're used to start the kernel by opening a jupyter notebook and then select the
kernel (so it will be here as well when it's finished). The current method is
convenient for developing in that it re-installs the kernel at every "./start.sh".

Post by Riccardo GUIDA
2) (less severe, I guess)
Why do you hardcode the dependence on python 2 ?

That's just a technical reason -- I used py3 in the first place but encountered
some issues which have to be resolved. Planned is py2/py3-agnostic as you
suggested below.

Post by Riccardo GUIDA
On my side I have Jupyter running in python 3 (simpy is stopping support of
python2 and sagemath working towards supporting py3). I do not know if I can
safely install debian packages for python2-jupyter and python3-jupyter, so I
would prefer to patch your code for py3.
Would not be better to stay py2/py3 agnostic and possibly leave the choice to
the user via configuration or environmental variable?

3) ~ (Naive || impudent)

Post by Riccardo GUIDA
Why did you introduce a dependence on hunchentoot and drop the original
python-only Jupyter kernel wrapper or the lisp one? Zero dependencies is better
than one dependency: are the latter really impossible?

A good question that actually would require a longer answer:

1. Although the lisp kernel still works when using the correct versions of
SBCL/0ZMQ+ a lot of lisp libraries (alternatively there a docker images, but
slightly outdated), it is hard to impossible to maintain it by a single person
(at least for me). The pace of development of Jupyter,SBCL and ZeroMQ makes it
really time consuming, and aggravating, I'm not a lisp expert ;)

The wrapper kernel (Python) is easy to maintain, however, the "expect" libraries
(used to interface fricas) are not really suited for data exchange. So the idea
was using the "wrapper kernel" and replace "expect" by the HTTP protocol+JSON
(request). The big advantage with Hunchentoot is a) it's written by a real
expert (Edi Weitz) and well maintained, b) it might be used for other things as
well, i.e. you can interface Fricas from every tool that can do GET/PUT
requests. This way you might use it from atom,lynx,w3m,...

Hope this was not too voluptuous :)
Kurt

Post by Riccardo GUIDA
Riccardo

[Riccardo GUIDA]

Post by Kurt Pagani
3) ~ (Naive || impudent)

Funny fix!

Thanks for your clarifications, Kurt.

Riccardo

PS ... and yes I dreamed of replace sman hyperdoc and graphics with Qt (+- mathgl)

PS2: could you give a link to the asymptote wrapper?

[Kurt Pagani]

On 02.08.2018 18:42, Riccardo GUIDA wrote:
...

Post by Riccardo GUIDA
PS2: could you give a link to the asymptote wrapper?

I've searched a while, unfortunately only parts of it were rediscovered.
The "asy" package works interactively (i.e. you need the 'pipe' package which
requires SBCL exclusively at the moment), however, I couldn't find the Asymptote
package itself (must be on a drive at home, will revert when back). A
non-interactive "asy" (e.g. graph) should work along the lines of gnudraw or
gle.spad (attached). Feel free to provide one ;-)