Dear Riccardo, a lot of questions ;-) But seriously, see below:
On 02.08.2018 12:30, Riccardo GUIDA wrote: > 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. > > (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. > > 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. > > > 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: > 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. > 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. > > 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? 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 ... > > 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". > 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. > 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? 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 > > 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.
