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 -- 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 https://groups.google.com/group/fricas-devel. For more options, visit https://groups.google.com/d/optout.
