Re: [fricas-devel] Re: HyperDoc and API
On 23.03.2021 20:41, Bill Page wrote: > On Tue, Mar 23, 2021 at 2:01 PM Ralf Hemmecke wrote: >> >>> Now, if we could only include the Jupyter interface in the >>> FriCAS distribution >> >> Well, yes, but, although I would like to see this offered, doing it >> the pip way or via installation from the github repo, is easy >> enough for early adopters to install the jfricas jupyter kernel. >> > > Well yes easy but ... First, doing it this way makes it almost > invisible except if we actually start actively discussing it here. > Second, as I recall (correct me if I am wrong) this means that a > specific binary SBCL-based version of FriCAS is installed with a > Lisp-level library for Jupyter kernel support. That's all past now. Ralf refactored the Lisp code to a minimum: https://github.com/fricas/jfricas/blob/master/jfricas/webspad.lisp The kernel itself is now Python based: https://github.com/fricas/jfricas/tree/master/jfricas Just two files ;) The dependency is https://edicl.github.io/hunchentoot/ We require a version of FriCAS_ which was compiled with a Common Lisp that supports multithreading and Hunchentoot. We recommend SBCL 1.4.5 or later. >From the website above: """ It currently works with LispWorks and all Lisps which are supported by the compatibility layers usocket and Bordeaux Threads. """ We've tested SBCL and ECL only, and it also works in WSL at least. > In order to add it to > the FriCAS distribution I presume that this would have to be extended > to support a wider range of Lisps and hopefully packaged in a way that > at least the interface part was distributed with FriCAS. Of course > Jupyter itself would have to be loaded in whatever way was standard > for the Jupyter user and then the kernel from the FriCAS distribution > appropriately installed. This would be closer to the way that we > support TeXmacs. > I guess you're thinking of the "old" (lisp based) Jupyter kernel (?). It was too hard to maintain because the dependency on the cl libraries, especially ZMQ changed too often. https://github.com/nilqed/fricas_jupyter is **deprecated** ! I have to edit the README ASAP. -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/354cfcd6-09c7-a33f-8803-0fcf33fd5d90%40gmail.com.
Re: [fricas-devel] Re: HyperDoc and API
On 24.03.2021 13:20, Andrey G. Grozin wrote: > On Tue, 23 Mar 2021, Ralf Hemmecke wrote: >>> Or send stuff to plot to gnuplot (that's what Maxima does) >> Would be an idea, but the original AXIOM developers obviously had some >> interaction (dynamic graphic) in mind. Not sure whether that would work >> with gnuplot. Don't ask more opinion from me. I'm not in the graphics >> world and haven't any need for graphics currently. If you know someone >> who is able to work on the FriCAS graphics system, then send him/her to >> us. Ideas and code are welcome. > > A few years ago my student tried to use geomview as a 3D backend instead of > the > standard fricas 3D viewer. geomview (http://www.geomview.org/) is very > interactive: it can show several 3D objects (various kinds of plots), you can > rotate, translate, zoom etc. each of them, or all together, or some subsets of > objects. Objects are described in a lisp-like language; these descriptions > were > generated by draw and sent to geomview via pipes. He had some semi-working > prototype; unfortunately, he has got his bachelor degree and left. I'm not > sure > if I still have his code somewhere. > > If we want an interactive 3D graphics backend, geomview is very good at it. > Unfortunately, its development seems to stop. The last release, 1.9.5, is from > 2014. It still works nicely. It uses motif, not a very fasionable toolkit, but > motif is now free and can be easily installed. I remember "geomview" well. It was widely used in the old days. But interactive 3d is another topic. In this case I would focus on VTK and ParaView (both BSD): https://en.wikipedia.org/wiki/VTK https://en.wikipedia.org/wiki/ParaView Writing related 3d format files is quite easy in fricas. > > Just an idea. > > Andrey > -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/68d0df29-0472-208a-2340-e032c711d510%40gmail.com.
Re: [fricas-devel] Re: HyperDoc and API
>> >> Since (AFAIK) there is no graphics library for CL, I see no alternative other >> than resorting to an external tool - nobody will write a lib from scratch ;) > > there is no graphics in CL standard, but you certainly have plenty of > choices to pick > CL bindings to various graphics libraries > https://www.cliki.net/graphics%20library > You're right and I looked at that list several times in the past. In the end we land on CFFI or a Lisp pipe. Interfacing is not the problem. Most of those libs could be accessed by the same method as Bill used for gnuDraw (https://fricas.github.io/api/GnuDraw.html). I also tried some from https://www.cliki.net/plotting, especially "vgplot" (https://www.cliki.net/vgplot) is noteworthy. -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/25c50041-d819-b36d-4833-4814b549b191%40gmail.com.
Re: [fricas-devel] Re: HyperDoc and API
On Tue, 23 Mar 2021, Ralf Hemmecke wrote: Or send stuff to plot to gnuplot (that's what Maxima does) Would be an idea, but the original AXIOM developers obviously had some interaction (dynamic graphic) in mind. Not sure whether that would work with gnuplot. Don't ask more opinion from me. I'm not in the graphics world and haven't any need for graphics currently. If you know someone who is able to work on the FriCAS graphics system, then send him/her to us. Ideas and code are welcome. A few years ago my student tried to use geomview as a 3D backend instead of the standard fricas 3D viewer. geomview (http://www.geomview.org/) is very interactive: it can show several 3D objects (various kinds of plots), you can rotate, translate, zoom etc. each of them, or all together, or some subsets of objects. Objects are described in a lisp-like language; these descriptions were generated by draw and sent to geomview via pipes. He had some semi-working prototype; unfortunately, he has got his bachelor degree and left. I'm not sure if I still have his code somewhere. If we want an interactive 3D graphics backend, geomview is very good at it. Unfortunately, its development seems to stop. The last release, 1.9.5, is from 2014. It still works nicely. It uses motif, not a very fasionable toolkit, but motif is now free and can be easily installed. Just an idea. Andrey -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/alpine.LRH.2.21.2103241906370.540%40star.inp.nsk.su.
Re: [fricas-devel] Re: HyperDoc and API
> it looks as if katex loads faster, but runs slower > > MathJax can be installed locally, and then the question of slow > loading is largerly gone. Yes, but I would like to provide jupyter notebooks translated to HTML at github-pages. So self-hosting is probably not an option. I should however still look into replacing the load of MathJax 2 by Mathjax 3 if Jupyter cannot/does not do this automatically. Ralf -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/3f46e5c7-11f2-010d-f815-5c3ad36c1218%40hemmecke.org.
Re: [fricas-devel] Re: HyperDoc and API
On Wed, Mar 24, 2021 at 9:50 AM Ralf Hemmecke wrote: > > Tobias sent a link via IRC. Seems that MathJax3 will bring quite some > progress. > > https://www.intmath.com/cg5/katex-mathjax-comparison.php?processor=MathJax3 it looks as if katex loads faster, but runs slower MathJax can be installed locally, and then the question of slow loading is largerly gone. > > Ralf > > -- > 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+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/fricas-devel/78e82015-76ae-ca2d-b54e-f00ada3358e1%40hemmecke.de. -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/CAAWYfq08wGckN5AKFjOswYfBe2SS56eFSa8_DOeamKH8e_M7zQ%40mail.gmail.com.
Re: [fricas-devel] Re: HyperDoc and API
Tobias sent a link via IRC. Seems that MathJax3 will bring quite some progress. https://www.intmath.com/cg5/katex-mathjax-comparison.php?processor=MathJax3 Ralf -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/78e82015-76ae-ca2d-b54e-f00ada3358e1%40hemmecke.de.
Re: [fricas-devel] Re: HyperDoc and API
On Wed, Mar 24, 2021 at 4:14 AM Kurt Pagani wrote: > > I'm gatecrashing the party as I have unfortunately missed most of the latest > conversation. I had a discussion with Ralf recently and we agree that the > current X11 graphics ought to be enough for illustrative purposes (it also > works > in jfricas and one can - in principle - include the graphics with ease into > the > notebook as described in the **deprecated** doc draft: > https://nilqed.github.io/jfricas.pip/sphinx/_build/html/usage.html#draw > > Since "graphics" is not may favourite subject either, enthusiasm has to be > fueled. Nevertheless I have been trying out various approaches with the > objective of "publication quality figures" in mind. I'd summarize the current > situation as follows: > > - X11 draw works fine (but some people find it ugly) > - Bill's gnuDraw (works, requires gnuplot) > - Martin's Scene Graph (works, sophisticated) > (https://www.euclideanspace.com/prog/scratchpad/mycode/graph/index.htm) > - Sixel graphics (requires xterm or similar sixel capable terminal (few) + > non-X gnuplot. I like it. > > Since (AFAIK) there is no graphics library for CL, I see no alternative other > than resorting to an external tool - nobody will write a lib from scratch ;) there is no graphics in CL standard, but you certainly have plenty of choices to pick CL bindings to various graphics libraries https://www.cliki.net/graphics%20library > There a hundreds (maybe exaggerated) of such plotting libraries written in JS, > Java, Python etc. and some few written in C/C++. To narrow down the search it > should be at least BSD licensed, mature and provide pub quality: > > Asymptote is LGPL, so not first choice. > https://en.wikipedia.org/wiki/Asymptote_(vector_graphics_language) > > PGF/Tikz is GPL or LaTeX PPL > https://en.wikipedia.org/wiki/PGF/TikZ > The top-level PGF and TikZ commands are invoked as TeX macros, but in contrast > with PSTricks, the PGF/TikZ graphics themselves are described in a language > that > resembles MetaPost. This would be my second choice. > > GLE - my favourite, BSD with a QT frontend lic. LGPL > https://en.wikipedia.org/wiki/Graphics_Layout_Engine > > GLE satisfies all requirements. > https://glx.sourceforge.io/ > https://glx.sourceforge.io/examples/index.html > > It's essentially a command line tool which can produce a lot of formats e.g. > EPS, PS, PDF, JPEG, and PNG. The frontend (QGLE) is relatively new, yet very > handy in that one can manipulate the sources on the fly with automated update > of > what you see ... > > kfp@euler:~$ gle --help > GLE version 4.2.5 > Usage: gle [options] filename.gle > More information: gle -help > > Options: > -help Shows help about command line options > -info Outputs software version, build date, GLE_TOP, GLE_BIN, etc. > -verbosity Sets the verbosity level of GLE console output > -device Selects output device(s) > -cairo Use cairo output device > -resolution Sets the resolution for bitmap and PDF output > -fullpage Selects full page output > -landscape Selects full page landscape output > -output Specifies the name of the output file > -nosave Don't write output file to disk (dry-run) > -previewPreviews the output with QGLE > -versionSelects a GLE version to run > -compatibility Selects a GLE compatibility mode > -calc Runs GLE in "calculator" mode > -catcsv Pretty print a CSV file to standard output > -texIndicates that the script includes LaTeX expressions > -incCreates an .inc file with LaTeX code > -texincprefix Adds the given subdirectory to the path in the .inc file > -mkinittex Creates "inittex.ini" from "init.tex" > -finddeps Automatically finds dependencies > -nocolorForces grayscale output > -inverseRender black as white for using on dark backgrounds > -transparentCreates transparent output (with -d png) > -noctrl-d Excludes CTRL-D from the PostScript output > -nomaxpath Disables the upper-bound on the drawing path complexity > -noligaturesDisable the use of ligatures for 'fl' and 'fi' > -gsoptions Specify additional options for GhostScript > -safemode Disables reading/writing to the file system > -allowread Allows reading from the given path > -allowwrite Allows writing to the given path > -keep Don't delete temporary files > > Show expert options: -help expert > Give more help about a given option: -help option > > --- > > For the sake of completeness I mention that we (Ralf and me) tried Gnuplot 5+ > (http://www.gnuplot.info/) - the new HTML canvas) and matplotlib > (https://matplotlib.org/). The results can be seen in the attached > ipysh_and_mplot.html and in the **deprecated** > https://nilqed.github.io/jfricas.pip/sphinx/_build/html/gnuplot.html. These > seems to me, however, not a long-term perspective because
Re: [fricas-devel] Re: HyperDoc and API
>> I actually thought so, but never looked deeper to find out how this can
>> be done.
>
> Click PS button in graphics menu. Draw has options giving output
> format. To avoid explicit options in drawing commands we would
> have to include Postscript in default output format. Crude
> way is to modify .spad file defining default. I am not sure
> if there is nicer way. When generationg .pht files HyperDoc
> sends some inital setup commands, it would be natural to
> change output format there.
I now looked into removing convert from ImageMagick.
Unfortunately, the only thing that I could find is in
src/input/mobius.input.
===
-- generate Mobius curve viewport for ViewportPage
port := draw(surface((v*cos(u/2)+1)*cos(u),(v*cos(u/2)+1)*sin(u), _
v*sin(u/2)), u=-%pi..%pi, v=-0.5..0.5)
write(port, "mobius", ["bitmap","pixmap"])
close port
)lisp (quit)
===
Replacing that by
write(port, "mobius", ["bitmap","pixmap","postscript"])
does the trick.
I can certainly extract the draw commands from the .htex files, since
they are marked in a particular way and generate a similar .input file
as above, but I wonder whether someone finds a quicker way. All the draw
commands are already executed during the generation of the .pht files.
The process generates *.VIEW directories with the files "data", image.bm
and image.xpm. I just don't yet know where (probably inside src/hyper)
the stanza
${GEN_VIEWPORTFILES_PHT}: %.pht: %.ht ${INPUT_EXTRA_INPUT} ${SMAN} \
$(fricas_target_bindir)/hypertex$(EXEEXT) stamp-initial-ht-db
echo $<
unset DAASE; HTPATH=.; export HTPATH; \
FRICAS_INITFILE='' ${XVFB} ${SMAN} -noihere -paste $<
from src/doc/Makefile.in sets the default output formats.
Actually, the question is also whether (apart from duration of
compilation) it makes sense to look into "adding postscript generation
during pht generation", since that stuff is for HyperDoc and only
book.pdf needs the .ps files. Perhaps I really take the route via
extracting the draw commands and do similar to mobius.input.
Comments?
Ralf
--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/fricas-devel/686aea76-1cb9-7cae-cdab-f709d943e028%40hemmecke.org.
Re: [fricas-devel] Re: HyperDoc and API
> How easy would it be to try KaTeX? https://katex.org/ Maybe someone > has already tried this? I cannot say. That is the first time I look at Katex. If it really renders faster that would be wonderful. But I wait until somebody throws a working .ipynb -> .html conversion at me that replaces mathjax with katex in the .html flle so that I would see how to actually use it. > It seems to me that Kurt has already experimented with several options > and that his opinion was that we should just pick one of these and run > with it. Yes, but I am not sure whether his stuff was already ripe for production. Ralf -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/57630458-b64d-1afb-06ef-020e75ddec61%40hemmecke.org.
Re: [fricas-devel] Re: HyperDoc and API
On Tue, Mar 23, 2021 at 2:01 PM Ralf Hemmecke wrote: > > > Now, if we could only include the Jupyter interface in the > > FriCAS distribution > > Well, yes, but, although I would like to see this offered, doing it > the pip way or via installation from the github repo, is easy > enough for early adopters to install the jfricas jupyter kernel. > Well yes easy but ... First, doing it this way makes it almost invisible except if we actually start actively discussing it here. Second, as I recall (correct me if I am wrong) this means that a specific binary SBCL-based version of FriCAS is installed with a Lisp-level library for Jupyter kernel support. In order to add it to the FriCAS distribution I presume that this would have to be extended to support a wider range of Lisps and hopefully packaged in a way that at least the interface part was distributed with FriCAS. Of course Jupyter itself would have to be loaded in whatever way was standard for the Jupyter user and then the kernel from the FriCAS distribution appropriately installed. This would be closer to the way that we support TeXmacs. > I must admit that I would like some people to work with it, but > to propose it for everyday use, it is maybe a bit early. I see in > particular problems when using mathjax with big output. Sure > one can always switch to ordinary algebra output, but mathjax > looks better. Unfortunately, mathjax takes quite some time to > render. > How easy would it be to try KaTeX? https://katex.org/ Maybe someone has already tried this? > > and decide on a way to render graphics (See previous discussion > > with Kurt.) then we would have a viable web-based user interface > > for FriCAS. > > I hope that some day Kurt has enough time to come up with a new > graphics framework that even works in jupyter. > It seems to me that Kurt has already experimented with several options and that his opinion was that we should just pick one of these and run with it. -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/CAC6x94S7gyQ%3DnkyFYgt9-8bYkYCupbW3vV9OW3Q-EngOH3MGTQ%40mail.gmail.com.
Re: [fricas-devel] Re: HyperDoc and API
> Now, if we could only include the Jupyter interface in the FriCAS > distribution Well, yes, but, although I would like to see this offered, doing it the pip way or via installation from the github repo, is easy enough for early adopters to install the jfricas jupyter kernel. I must admit that I would like some people to work with it, but to propose it for everyday use, it is maybe a bit early. I see in particular problems when using mathjax with big output. Sure one can always switch to ordinary algebra output, but mathjax looks better. Unfortunately, mathjax takes quite some time to render. > and decide on a way to render graphics (See previous discussion with > Kurt.) then we would have a viable web-based user interface for > FriCAS. I hope that some day Kurt has enough time to come up with a new graphics framework that even works in jupyter. Yes we are making progress and I very much hope that more and more people "get their hands dirty" and start contributing to areas that they are most interested in. Ralf -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/908c3293-f393-7ed8-66bc-aae51335825e%40hemmecke.de.
Re: [fricas-devel] Re: HyperDoc and API
On Tue, Mar 23, 2021 at 3:57 AM Ralf Hemmecke wrote: > > On 23.03.21 02:31, Bill Page wrote: > > So now I have a link on my desktop that starts a local copy of the > > api. Great. > > Great. It look as if I got a first user for this feature. ;-) > Thanks for taking the pain to go through the compilation. > Now, if we could only include the Jupyter interface in the FriCAS distribution and decide on a way to render graphics (See previous discussion with Kurt.) then we would have a viable web-based user interface for FriCAS. -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/CAC6x94Q-bBHeyuD2V5b-AeuFM6Ob1gGjkgK7fXx2V%3D795GhLug%40mail.gmail.com.
Re: [fricas-devel] Re: HyperDoc and API
> E.g. Common Lisp, yes, very new and hot. :-) I don't program in lisp and don't want to, but mathematically lisp is quite a nice thing. I don't believe that FriCAS will live forever on lisp. But for now, I consider it as runtime environment and I don't care so much whether it is C, Assembler or Lisp. C would probably a bit better when it come to using external libraries (like FLINT), but nobody has dared to write a working interpreter in Aldor, so time for switching to Aldor has not yet come. > Or send stuff to plot to gnuplot (that's what Maxima does) Would be an idea, but the original AXIOM developers obviously had some interaction (dynamic graphic) in mind. Not sure whether that would work with gnuplot. Don't ask more opinion from me. I'm not in the graphics world and haven't any need for graphics currently. If you know someone who is able to work on the FriCAS graphics system, then send him/her to us. Ideas and code are welcome. Ralf -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/1d3eeaed-443d-af11-bcc1-924e78918083%40hemmecke.org.
Re: [fricas-devel] Re: HyperDoc and API
On Mon, Mar 22, 2021 at 11:12 PM Waldek Hebisch wrote: > > On Mon, Mar 22, 2021 at 09:56:27PM +, Dima Pasechnik wrote: > > On Mon, Mar 22, 2021 at 9:43 PM Waldek Hebisch > > wrote: > > > > > > On Mon, Mar 22, 2021 at 10:03:09PM +0100, Ralf Hemmecke wrote: > > > > > Our graphics routines can create Postscript. > > > > > > > > I actually thought so, but never looked deeper to find out how this can > > > > be done. > > > > > > Click PS button in graphics menu. Draw has options giving output > > > format. To avoid explicit options in drawing commands we would > > > have to include Postscript in default output format. Crude > > > way is to modify .spad file defining default. I am not sure > > > if there is nicer way. When generationg .pht files HyperDoc > > > sends some inital setup commands, it would be natural to > > > change output format there. > > > > > > > > ATM you need access to X server for this, but you also need access > > > > > to X server to create .xpm, so this really is not extra requirement. > > > > > > > > Hmmm... in fact, I don't know what .xpm is really used for other than > > > > being converted into .ps. Maybe HyperDoc pics it up, but I never looked > > > > at what HyperDoc wants. > > > > > > Well, 'draw' sends data to C side. This is used for display. > > > When you store image C program save requested data formats > > > (which in case of viewport includes .data which is essentially > > > copy of data sent from FRICASsys to C side). However, when > > > you clik on image in HyperDoc, then viewer uses .xpm (presumably > > > the idea was to save time needed to render data). > > > > I don't know who would code such things in C in 2021, though. This is > > 25 years too late. > > People implementing new hot languages? E.g. Common Lisp, yes, very new and hot. :-) Or send stuff to plot to gnuplot (that's what Maxima does) > At some place you need > to call OS or existing libraries and currently portable > interface is in C (C++ is much more problematic to interface). > > And "code in C" is only partly accurate: for real work you need > to call library function which is close to 1 line of code > (replicated in few places as we have few similar but not > identical binaries). You need few more lines to decide if > call is required. Rest is configure/Makefile to make sure > program links to the library. > > Real work is to find right place to put library call and the > few other lines. That does not differ much from work > needed in any other language, except for fact that > some people like C and would code in C things better done > in other languages, other hate C do not want to touch it > even when it makes sense. > > BTW: There are folks who are not satisfied with mainstream > GUI toolkits and code new substantial things in C (both > alternative toolkits and applications based on them). > > BTW2: It would be nice to have some GUI capabilites in Spad. > However, I feel that it is wiser to put my effort in other > tasks. > > > > > > > BTW1: 2D Postscript output ATM is black and white. So > > > you may prefer .xpm due to color. OTOH, .xpm is just pixel > > > data, so Web-friendly convertion would go to .png > > > > Rather, to svg (scalable vector graphics). Png (or xpm) isn't optimal at > > all, > > as they are raster image/bitmap formats. > > And it is ideologically closer to postscript images, also very small in > > size. > > Well, if you start with .xpm then converting it to .svg have > limited sense... And Postscript produced from .xpm is not > better than .png. IIRC 'scene' (that I mention below) can > produce .svg > > > > BTW3: 'scene' framework can generate other formats, but it > > > is not clear how to connect it to 'draw' so that the > > > whole thing operate as a whole (ATM you need completely > > > different commands to get output from 'scene' framework). > > -- > Waldek Hebisch > > -- > 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+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/fricas-devel/20210322231215.GB7130%40math.uni.wroc.pl. -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/CAAWYfq3hZv36RTM%3Dy86se3wOE2g0Tb85wi0ih%2BNAO8ASJ%2BuJQA%40mail.gmail.com.
Re: [fricas-devel] Re: HyperDoc and API
On 23.03.21 02:31, Bill Page wrote: > OK, after enabling postscript generation in ImageMagick, loading > some missing TeXLive packages and installing Sphinx 'make localdoc' > succeeded. OK. It seems I have to produce some documentation about the prerequisites of "make localdoc". > I am able to access the result from > > $ firefox file:///home/wspage/fricas-build/src/doc/html/index.html > > So now I have a link on my desktop that starts a local copy of the > api. Great. > > ... And I am able to access my locally stored source code. So all is > good so far. > > Thanks. Great. It look as if I got a first user for this feature. ;-) Thanks for taking the pain to go through the compilation. Ralf -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/2b0a986f-5b43-9701-b841-30b8ba4e76db%40hemmecke.org.
[fricas-devel] Re: HyperDoc and API
OK, after enabling postscript generation in ImageMagick, loading some missing TeXLive packages and installing Sphinx 'make localdoc' succeeded. I am able to access the result from $ firefox file:///home/wspage/fricas-build/src/doc/html/index.html So now I have a link on my desktop that starts a local copy of the api. Great. Now, to answer an earlier question: Apparently search is supported through some local javascript. As a result what I have seems to look and work exactly the same way as the online version. And I am able to access my locally stored source code. So all is good so far. Thanks. -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/CAC6x94Q0McbMAHvSiTyM_kX%3DRGdFHYjsnyYJXKLp%2BgtB-ez3Cg%40mail.gmail.com.
Re: [fricas-devel] Re: HyperDoc and API
On Mon, Mar 22, 2021 at 09:56:27PM +, Dima Pasechnik wrote: > On Mon, Mar 22, 2021 at 9:43 PM Waldek Hebisch > wrote: > > > > On Mon, Mar 22, 2021 at 10:03:09PM +0100, Ralf Hemmecke wrote: > > > > Our graphics routines can create Postscript. > > > > > > I actually thought so, but never looked deeper to find out how this can > > > be done. > > > > Click PS button in graphics menu. Draw has options giving output > > format. To avoid explicit options in drawing commands we would > > have to include Postscript in default output format. Crude > > way is to modify .spad file defining default. I am not sure > > if there is nicer way. When generationg .pht files HyperDoc > > sends some inital setup commands, it would be natural to > > change output format there. > > > > > > ATM you need access to X server for this, but you also need access > > > > to X server to create .xpm, so this really is not extra requirement. > > > > > > Hmmm... in fact, I don't know what .xpm is really used for other than > > > being converted into .ps. Maybe HyperDoc pics it up, but I never looked > > > at what HyperDoc wants. > > > > Well, 'draw' sends data to C side. This is used for display. > > When you store image C program save requested data formats > > (which in case of viewport includes .data which is essentially > > copy of data sent from FRICASsys to C side). However, when > > you clik on image in HyperDoc, then viewer uses .xpm (presumably > > the idea was to save time needed to render data). > > I don't know who would code such things in C in 2021, though. This is > 25 years too late. People implementing new hot languages? At some place you need to call OS or existing libraries and currently portable interface is in C (C++ is much more problematic to interface). And "code in C" is only partly accurate: for real work you need to call library function which is close to 1 line of code (replicated in few places as we have few similar but not identical binaries). You need few more lines to decide if call is required. Rest is configure/Makefile to make sure program links to the library. Real work is to find right place to put library call and the few other lines. That does not differ much from work needed in any other language, except for fact that some people like C and would code in C things better done in other languages, other hate C do not want to touch it even when it makes sense. BTW: There are folks who are not satisfied with mainstream GUI toolkits and code new substantial things in C (both alternative toolkits and applications based on them). BTW2: It would be nice to have some GUI capabilites in Spad. However, I feel that it is wiser to put my effort in other tasks. > > > > BTW1: 2D Postscript output ATM is black and white. So > > you may prefer .xpm due to color. OTOH, .xpm is just pixel > > data, so Web-friendly convertion would go to .png > > Rather, to svg (scalable vector graphics). Png (or xpm) isn't optimal at all, > as they are raster image/bitmap formats. > And it is ideologically closer to postscript images, also very small in size. Well, if you start with .xpm then converting it to .svg have limited sense... And Postscript produced from .xpm is not better than .png. IIRC 'scene' (that I mention below) can produce .svg > > BTW3: 'scene' framework can generate other formats, but it > > is not clear how to connect it to 'draw' so that the > > whole thing operate as a whole (ATM you need completely > > different commands to get output from 'scene' framework). -- Waldek Hebisch -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/20210322231215.GB7130%40math.uni.wroc.pl.
Re: [fricas-devel] Re: HyperDoc and API
On Mon, Mar 22, 2021 at 9:43 PM Waldek Hebisch wrote: > > On Mon, Mar 22, 2021 at 10:03:09PM +0100, Ralf Hemmecke wrote: > > > Our graphics routines can create Postscript. > > > > I actually thought so, but never looked deeper to find out how this can > > be done. > > Click PS button in graphics menu. Draw has options giving output > format. To avoid explicit options in drawing commands we would > have to include Postscript in default output format. Crude > way is to modify .spad file defining default. I am not sure > if there is nicer way. When generationg .pht files HyperDoc > sends some inital setup commands, it would be natural to > change output format there. > > > > ATM you need access to X server for this, but you also need access > > > to X server to create .xpm, so this really is not extra requirement. > > > > Hmmm... in fact, I don't know what .xpm is really used for other than > > being converted into .ps. Maybe HyperDoc pics it up, but I never looked > > at what HyperDoc wants. > > Well, 'draw' sends data to C side. This is used for display. > When you store image C program save requested data formats > (which in case of viewport includes .data which is essentially > copy of data sent from FRICASsys to C side). However, when > you clik on image in HyperDoc, then viewer uses .xpm (presumably > the idea was to save time needed to render data). I don't know who would code such things in C in 2021, though. This is 25 years too late. > > BTW1: 2D Postscript output ATM is black and white. So > you may prefer .xpm due to color. OTOH, .xpm is just pixel > data, so Web-friendly convertion would go to .png Rather, to svg (scalable vector graphics). Png (or xpm) isn't optimal at all, as they are raster image/bitmap formats. And it is ideologically closer to postscript images, also very small in size. > > BTW2: Long ago I was thinking about replacing use of .xpm > by .png. However, to my surprize compressed .xpm was > smaller than corresponding .png. So with .png our > compressed tarball would be slightly bigger. So it looked > that .png gave us no advantage and I did not look how > much effort would be needed to generate .png > > BTW3: 'scene' framework can generate other formats, but it > is not clear how to connect it to 'draw' so that the > whole thing operate as a whole (ATM you need completely > different commands to get output from 'scene' framework). > > -- > Waldek Hebisch > > -- > 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+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/fricas-devel/20210322214330.GA7130%40math.uni.wroc.pl. -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/CAAWYfq0VG1Nqu7s9iAMdOrV7oD9BtPG-L7cGx-uDNBrg2Wzy0A%40mail.gmail.com.
Re: [fricas-devel] Re: HyperDoc and API
On Mon, Mar 22, 2021 at 10:03:09PM +0100, Ralf Hemmecke wrote: > > Our graphics routines can create Postscript. > > I actually thought so, but never looked deeper to find out how this can > be done. Click PS button in graphics menu. Draw has options giving output format. To avoid explicit options in drawing commands we would have to include Postscript in default output format. Crude way is to modify .spad file defining default. I am not sure if there is nicer way. When generationg .pht files HyperDoc sends some inital setup commands, it would be natural to change output format there. > > ATM you need access to X server for this, but you also need access > > to X server to create .xpm, so this really is not extra requirement. > > Hmmm... in fact, I don't know what .xpm is really used for other than > being converted into .ps. Maybe HyperDoc pics it up, but I never looked > at what HyperDoc wants. Well, 'draw' sends data to C side. This is used for display. When you store image C program save requested data formats (which in case of viewport includes .data which is essentially copy of data sent from FRICASsys to C side). However, when you clik on image in HyperDoc, then viewer uses .xpm (presumably the idea was to save time needed to render data). BTW1: 2D Postscript output ATM is black and white. So you may prefer .xpm due to color. OTOH, .xpm is just pixel data, so Web-friendly convertion would go to .png BTW2: Long ago I was thinking about replacing use of .xpm by .png. However, to my surprize compressed .xpm was smaller than corresponding .png. So with .png our compressed tarball would be slightly bigger. So it looked that .png gave us no advantage and I did not look how much effort would be needed to generate .png BTW3: 'scene' framework can generate other formats, but it is not clear how to connect it to 'draw' so that the whole thing operate as a whole (ATM you need completely different commands to get output from 'scene' framework). -- Waldek Hebisch -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/20210322214330.GA7130%40math.uni.wroc.pl.
Re: [fricas-devel] Re: HyperDoc and API
> Our graphics routines can create Postscript. I actually thought so, but never looked deeper to find out how this can be done. > ATM you need access to X server for this, but you also need access > to X server to create .xpm, so this really is not extra requirement. Hmmm... in fact, I don't know what .xpm is really used for other than being converted into .ps. Maybe HyperDoc pics it up, but I never looked at what HyperDoc wants. > In fact, one useful potential contribution from C programmer would be > to eliminate need for .xpm files. Namely our graphics should be able > to work with just .data files, and for export Postscript is probably > more useful (and if somebody really want .xpm, they can be created on > demand). > But if C programmer goes first to improve style of C files (which > admitedly is bad), then it could be long time before we see usability > improvement... Hmmm... that should go somewhere into a "wanted contribution" page. Something I plan for fricas.github.io. Ralf -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/07428d4a-6a4d-ee47-5cac-de5d1b877fdc%40hemmecke.org.
Re: [fricas-devel] Re: HyperDoc and API
On Mon, Mar 22, 2021 at 07:36:25PM +0100, Ralf Hemmecke wrote: > > make -f pics.mk pics > > make[2]: Entering directory '/home/wspage/fricas-build/src/doc' > > convert ugNewIntroGraphicsPage1.VIEW/image.xpm bessintr.ps > > convert-im6.q16hdri: not authorized `bessintr.ps' @ > > error/constitute.c/WriteImage/1037. > > pics.mk:3: recipe for target 'bessintr.ps' failed > > ... > > > This is due to an apparently well known change to ImageMagick to > > prevent creation of postscript files and some other things by default. > > Do you know if there is an alternative to 'convert' for this > > conversion that would avoid having to change the security options? > > Oh... yes. Sure if we want users/developers to create the documentation > themselves, that must eventually be changed. > > Unfortunately, I don't know any good replacement for ImageMagick. And I > haven't yet found an option that I could give on the "convert" > commandline to just ignore this problem with "not authorized". > In fact, it's a bit strange. How useful can ImageMagick be if one needs > root access to change > > - > + > > in /etc/ImageMagick/policy.xml in order to create .ps files. > > Any suggestion? Our graphics routines can create Postscript. ATM you need access to X server for this, but you also need access to X server to create .xpm, so this really is not extra requirement. In fact, one useful potential contribution from C programmer would be to eliminate need for .xpm files. Namely our graphics should be able to work with just .data files, and for export Postscript is probably more useful (and if somebody really want .xpm, they can be created on demand). But if C programmer goes first to improve style of C files (which admitedly is bad), then it could be long time before we see usability improvement... -- Waldek Hebisch -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/20210322190517.GB27259%40math.uni.wroc.pl.
Re: [fricas-devel] Re: HyperDoc and API
> make -f pics.mk pics > make[2]: Entering directory '/home/wspage/fricas-build/src/doc' > convert ugNewIntroGraphicsPage1.VIEW/image.xpm bessintr.ps > convert-im6.q16hdri: not authorized `bessintr.ps' @ > error/constitute.c/WriteImage/1037. > pics.mk:3: recipe for target 'bessintr.ps' failed > ... > This is due to an apparently well known change to ImageMagick to > prevent creation of postscript files and some other things by default. > Do you know if there is an alternative to 'convert' for this > conversion that would avoid having to change the security options? Oh... yes. Sure if we want users/developers to create the documentation themselves, that must eventually be changed. Unfortunately, I don't know any good replacement for ImageMagick. And I haven't yet found an option that I could give on the "convert" commandline to just ignore this problem with "not authorized". In fact, it's a bit strange. How useful can ImageMagick be if one needs root access to change - + in /etc/ImageMagick/policy.xml in order to create .ps files. Any suggestion? Ralf -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/0b5cdcf6-a6c5-410a-cb51-1297af377d8c%40hemmecke.org.
[fricas-devel] Re: HyperDoc and API
On Mon, Mar 22, 2021 at 9:59 AM Bill Page wrote: > ... > I will attempt to build the api locally and let you know what I find. > > Thanks. On Mar 19, 2021, 6:01 PM Ralf Hemmecke wrote: > Bill Page wrote: > > HyperDoc: almost every time I use FriCAS. I do often wish > > that the HyperDoc interface looked more up to date. On the > > other hand I do not much like to have to work online with > > http://fricas.github.io Maybe I would use it more if it was > > bundled into the FriCAS distribution somehow. > Bundled with the distribution, I cannot promise. But what I can > say is that when you compile FriCAS and say > > cd /path/to/build-dir/src/doc > make localdoc > > it will produce that what is on fricas.github.io on your local > machine. (even the book). And the links there are such that > you (almost) never need the web. > > See > https://github.com/fricas/fricas/blob/master/src/doc/Makefile.in#L75 My first observation is that on my system (Linux Mint 19.2) 'make localdoc' almost immediately returns a security error: ... cp /home/wspage/fricas-master/src/doc/ps/h-matxref.ps h-matxref.ps cp /home/wspage/fricas-master/src/doc/ps/h-root.ps h-root.ps make -f pics.mk pics make[2]: Entering directory '/home/wspage/fricas-build/src/doc' convert ugNewIntroGraphicsPage1.VIEW/image.xpm bessintr.ps convert-im6.q16hdri: not authorized `bessintr.ps' @ error/constitute.c/WriteImage/1037. pics.mk:3: recipe for target 'bessintr.ps' failed ... This is due to an apparently well known change to ImageMagick to prevent creation of postscript files and some other things by default. Do you know if there is an alternative to 'convert' for this conversion that would avoid having to change the security options? See for example: https://askubuntu.com/questions/1127260/imagemagick-convert-not-allowed -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/CAC6x94S3Et_GXq0MEh9hE6hO1m_2qUxZHM8LjrJEiLEcWmMrnQ%40mail.gmail.com.
[fricas-devel] Re: HyperDoc and API
On Sun, Mar 21, 2021 at 10:29 AM Ralf Hemmecke wrote: > > On 21.03.21 15:00, Bill Page wrote: > > On Sun, Mar 21, 2021 at 8:25 AM Ralf Hemmecke > > wrote: > >> ... The only thing (in my eyes) that HyperDoc can do and > >> http://fricas.github.io/api does not provide, is showing > >> "which domain/package/category implements a certain > >> function". > > > > Yes, exactly. HyperDoc allows "easy" navigation in the rather > > complex lattice of categories, domains and functions of the > > FriCAS library. > > May I ask what you mean by this. Suppose you have > http://fricas.github.io/api locally on your computer. > What would you miss? > Admittedly, my resistance is largely due to a lack of familiarity. By default HyperDoc starts automatically when you start FriCAS so it seems like part of FriCAS. http://fricas.github.io/api on the other hand is an external program. Maybe an option like $ fricas -api that automatically disabled HyperDoc and started a local copy of the api would help. Typically I would start with searching for a function or a domain. The online search at http://fricas.github.io/api seems OK although I probably not have used it enough yet to know if there are any limitations. How is search provided if I have it locally on my computer? > And I would like to clarify. When I wrote about "which > domain/package/category implementa certain function", > I did not mean which domain *exports* this function, but > rather what is the domain, that has the source code for > the respective functionality. You know with inheritance > from domains and category defaults, that can sometimes > be hard to find out if you browse through the source files. > I am not sure that you above mean the same. > Thank you for the clarification. Yes that is important. > > The user interface level of HyperDoc could be entirely replaced > > by a conventional browser but the navigation of the internal > > FriCAS dynamic type database still requires some sort of > > backend. > > Well, in fact, fricas.github.io/api tries to do exactly that, only > that it is static. That is however not a very big problem. One > can compile the API stuff of private .spad files in the same way > and the hyperlinks would correctly point into the FriCAS API > if they are not part of the new package/domain/categories. > > So what exactly would you miss? > I will attempt to build the api locally and let you know what I find. Thanks. -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/CAC6x94S%2BKT8-EWriDXGUW9P2RsRgFoN5Rd-UtOVpEZZH8embLg%40mail.gmail.com.
