[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: changes to allow macOS packaging work again
On Sun, Mar 21, 2021 at 06:51:21PM +0100, Ralf Hemmecke wrote: > On 21.03.21 17:49, Waldek Hebisch wrote: > > There is misunderstanding here: you do not need to wait > > to include another graphic framework. My impression > > was that I am not the main opponent of new code in > > FriCAS: when new code was proposed sometimes other > > folks voiced strong objections... > > Oh, good that you say that so openly. You are very conservative and with > strong opinion about the direction of FriCAS. Yes, I have strong opinion about the direction of FriCAS, I do not consider this as bad thing. Let me add that I am ready to change my opinions if I see facts contradicting my opinions. Concerning "very conservative", let me say that I have some experience with Sun systems. About 1990 their default shell was already dated, IIUC essentially the same shell as very early Unix. In 2007 I played with Open Solaris and it shipped the same default shell, probably bug-compatible with very early one. I understand the reason: their commercial customers would be unhappy it old shell scripts stopped to work, and some scripts depend on bugs (to avoid wrong impression: Solaris also had much newer shell, but it was not default and some action to was needed it invoke new shell). That I consider very conservative and I am not going to adopt such policy for FriCAS. OTOH I am very much against "modern" trend where program may fail to compile on few years old system (or that few years old program fails to compile on new system). > I guess, we have lost > Robert Smith for contribution to FriCAS. Possibly. I wonder, if you were responsible for the project, what would be your answer for his offer. > I don't generally say that this > conservativeness is a bad thing. Sometimes I even appreciate it after a > while (even against my own opinion and wishes). However, it gives the > impression that contributions are easily turned down and investing time > in new code seems like a waste. As you say above that impression is > wrong, but still it sometimes sounds unwelcome to new people. This is > what I consider a problem for further and faster development of FriCAS. > We should rather say that it is OK to just fork FriCAS and try own ideas > and come back and convince the main developers to include new (better) > code if it is ready and removes some deficiencies of FriCAS. Here I have different opinion: I encourage potential contributors to first disscuss their ideas here. Possibly we could link to some FAQ about contributing to open source software (a lot of folks seem to have misconceptions and such problems are not specific to FriCAS). Extra remark: I find one thing more offensive than quick rejection of code, namely to tell somebody to do lenghty developement and then, when code is "ready" reject it. -- 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/20210322185306.GA27259%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.
[fricas-devel] Re: binary download for all platforms from CI
Now everything I needed are made into repo now. We have binary download available for all platforms from GitHub Actions. And I consider it has reached ALPHA quality, testings and comments and bug reports are welcome. Waldek has verified his email (I assume), thank you! So we should have CI checks and binary downloads for every git push, at https://github.com/fricas/fricas/actions - Qian On 3/16/21 12:02 AM, Qian Yun wrote: I have a working configuration that we now have binary download for all platforms from CI. See: https://github.com/oldk1331/fricas/tree/ci-improvement or https://github.com/oldk1331/fricas/commit/c173a68c42a9151ec9e0b6234c8d02aa0e36676e or linux: https://github.com/oldk1331/fricas/actions/runs/654525090 macos: https://github.com/oldk1331/fricas/actions/runs/654525087 windows: https://github.com/oldk1331/fricas/actions/runs/654525092 A few downsides: 1. You have to login GitHub to download this "CI artifact". (Not necessarily a bad thing, I don't want to pollute the "Release" page in GitHub.) 2. It only exists for a short period. (90 days?) 3. The packaging is very crude for now, not out-of-box user experience. (You have to "cd" in the shell and set "FRICAS" env variable.) 4. It's double compressed, you have to unpack twice. Bugs found: Seems the "bin/fricas" shell script calls "viewman" endlessly on macOS? Will look into it later. - Qian -- 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/00da71ae-9b06-ebd5-d475-a26d223444a2%40gmail.com.
