changes to allow macOS packaging work again

[Qian Yun]

This is the change I made to get the macOS dmg working.
Not very elegant, but I wonder if there is a better way?

Comments are welcome. And macOS users can try/test the binary
at https://github.com/oldk1331/fricas/actions/runs/664218153

- Qian

https://github.com/fricas/fricas/commit/ed1f43ad1a7be891a6bbb050b055e2ff7f9f3ab8.patch

diff --git a/Makefile.in b/Makefile.in
index f50f0bde3..17af45595 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -133,9 +133,11 @@
echo exec_prefix='"$${FRICAS_PREFIX:-$(exec_prefix)}"' \
>> '${COMMAND}'.tmp
if test "$(fricas_lib)" != "$(libdir)" ; then \
- echo \
- FRICAS='"$${exec_prefix}/$(fricas_lib)/fricas/target/$(target)"' \
- >> '${COMMAND}'.tmp ; \
+ if test $(uname -s) != "Darwin" ; then \
+ echo
FRICAS='"$${exec_prefix}/$(fricas_lib)/fricas/target/$(target)"' >>
'${COMMAND}'.tmp ; \
+ else \
+ echo FRICAS='"`dirname
$$0`/../$(fricas_lib)/fricas/target/$(target)"' >> '${COMMAND}'.tmp ; \
+ fi \
else \
echo FRICAS='"$(libdir)/fricas/target/$(target)"' \
>> '${COMMAND}'.tmp ; \
diff --git a/contrib/macos/FriCAS.c b/contrib/macos/FriCAS.c
index bf7f1470f..35c83deac 100644
--- a/contrib/macos/FriCAS.c
+++ b/contrib/macos/FriCAS.c
@@ -25,7 +25,7 @@

setenv("FRICAS_PREFIX", CFStringGetCStringPtr(path, encoding), 1);

- system("/usr/X11/bin/xterm"
- " -e \"${FRICAS_PREFIX}/bin/fricas\"");
+ system("open -a Terminal.app"
+ " \"${FRICAS_PREFIX}/usr/local/bin/fricas\"");
return 0;
}

[Qian Yun]

This is all the changes I need in order to get a working
macOS dmg package.

See attachment or
https://github.com/oldk1331/fricas/commit/71c511531475a1c754b555362bc14a4299ccba0c.patch

Binary at https://github.com/oldk1331/fricas/actions/runs/667643819

Comments are welcome.

- Qian

[Waldek Hebisch]

On Fri, Mar 19, 2021 at 07:12:58PM +0800, Qian Yun wrote:
> This is all the changes I need in order to get a working
> macOS dmg package.

Just asking: apparently you replace "xterm" by "Terminal.app",
what is the reason?

--
Waldek Hebisch

[Dima Pasechnik]

macOS typically has no X11 nowdays, thus no xterm.

>
> --
> 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...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/20210319142118.GA32840%40math.uni.wroc.pl.

[Waldek Hebisch]

On Fri, Mar 19, 2021 at 02:22:10PM +0000, Dima Pasechnik wrote:
> On Fri, Mar 19, 2021 at 2:21 PM Waldek Hebisch <heb...@math.uni.wroc.pl> wrote:
> >
> > On Fri, Mar 19, 2021 at 07:12:58PM +0800, Qian Yun wrote:
> > > This is all the changes I need in order to get a working
> > > macOS dmg package.
> >
> > Just asking: apparently you replace "xterm" by "Terminal.app",
> > what is the reason?
>
> macOS typically has no X11 nowdays, thus no xterm.

AFAIK X11 was an optional component which could be installed.
I we want it installed for graphics and HyperDoc.

--
Waldek Hebisch

[Dima Pasechnik]

wow, 

https://www.xquartz.org/ just had a (pre)release, first in 5 years.

I thought it is just gone.

--
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...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/20210319143752.GB32840%40math.uni.wroc.pl.

[Qian Yun]

At this stage I do not want to add support for X11/HyperDoc on macOS.
Not yet, maybe later, if a user puts such request.

Can you agree with this?

- Qian

[Waldek Hebisch]

On Fri, Mar 19, 2021 at 11:25:12PM +0800, Qian Yun wrote:
> At this stage I do not want to add support for X11/HyperDoc on macOS.
> Not yet, maybe later, if a user puts such request.
>
> Can you agree with this?

Maybe I am wrong, but my impression was:
- FriCAS builds from sources on Mac OSX with X11 support
- there are packaging systems on Mac which distribute
FriCAS with X11 support

So we are not talking about adding support. Rather, we
do not want to break what is working. It is fine if you
do not want to work with X11 (now or also in the future).
However, the problem is to ensure that various efforts add.
That is why I was asking about "Terminal.app": your earlier
posts suggested that it introduces breakage...

Another thing are versions for user. Namely, for testing
it is fine to test without X11 (ATM in batch mode we can
only test if X11 interface builds, but no more). However
for users versions with X11 interface are much more preferable.
It still makes some sense to offer version without X11
support, but we should make lack of X11 support clear
in documentaion and probably point to alternatives supporting
X11.

--
Waldek Hebisch

[Ralf Hemmecke]

> It still makes some sense to offer version without X11
> support, but we should make lack of X11 support clear
> in documentaion and probably point to alternatives supporting
> X11.

I don't think that X11 will disappear too quickly, but still, we should
be prepared. Windows has no X, MacOS has no X, with Wayland coming, X
will not be the default in Ubuntu etc.

In fact, I do not really see why FriCAS needs X. Of course supporting it
as long as it works, is OK, but I wouldn't want to invest much time into
it. We already have jfricas as a nice interface. Much of the stuff in
HyperDoc lives at fricas.github.io. The big problem is our graphics
engine. For that we would need someone that comes up with a connection
to some newer graphics framework so that X is no prerequisit anymore.

Ralf

[Waldek Hebisch]

We need some graphic environment. Simple fact of life is that
up to now X11 was most stable environment. Namely, old 30
years old programs work as they used to work. Unfortunatly,
this is not the case with newer things, my graphic code
for "famework of the day" got broken in few years. And a lot
of folks have similar experience.

Let me add that retargetting our existing programs say to
WinAPI would be rather easy (and would not require breaking
X11 support), but nobody voluntereed to do the work. It
seems that people prefer to work on new code, probably
because in new code they can concentrate on core things
and (at least at beginning ignore some system aspects and
corner cases). But for long term interface it is exactly
handling of system aspects and corner cases that determines
viablility. Adapting tried code in very slowly evolving
environment is much easier than coping with rapid breaking
chages in "modern" systems.

Another apect is performace: our X11 programs have by
current standard very small resource requirements and
high performace. Browsers (and web page code) tend to
get slower faster than hardware get faster so for
long time we can expect bad performance.

BTW: Long time ago I was one of users of shared Sun
workstations. There was X11 installed, but machines
had only 4M of memory and X11 was quite slow on them.
But I have found manuals of "suntools", clearly
marked "obsolete". I peeked into manuals and tried
the software. It had it quiks, but run with quite
satisfactory performance. Form that time I started
to appreciate advantages of "obsolete" software...

--
Waldek Hebisch

[Ralf Hemmecke]

On 19.03.21 19:20, Waldek Hebisch wrote:
> We need some graphic environment.

Yes and all you say about stability of X11 might be true, but you must
admit that with the graphics system of FriCAS you cannot really impress
somebody. If you think otherwise than produce some nice examples that we
can showcase on our website so that people see that FriCAS can also
visualise nicely.

If you like to keep the current graphics system that is fine.
However, I do not think it is wise to stop other people from what they
think is best for FriCAS. If someone develops a new graphics system in
his/her fork of FriCAS and you do not take it, that's also OK. People
will choose whatever helps to solve their problems.

Since seemingly nobody is interested in developing a new graphics
framework we should anyway not throw away the current stack. However,
that does not mean that we cannot discuss a new way of handling graphics.

Actually, I would be interested in a poll that asks how many of our
users ever use the graphics facilities of FriCAS. A similar poll for the
use of HyperDoc would also be fine.
Someone here on the list who would answer these questions?

Ralf

[Bill Page]

On Fri, Mar 19, 2021 at 5:07 PM Ralf Hemmecke <ra...@hemmecke.org> wrote:

>
> Actually, I would be interested in a poll that asks how many of
> our users ever use the graphics facilities of FriCAS. A similar
> poll for the use of HyperDoc would also be fine.
> Someone here on the list who would answer these questions?
>

Graphics: almost 0. Even if it did look nice I probably would not
use it often. Maybe that is just because of the kinds of things for
which I use FriCAS.

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.

[Ralf Hemmecke]

Thank you Bil for this feedback.

> 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

Ralf

[Qian Yun]

I never use the graphics interface, I rarely use "draw".

I almost never use HyperDoc. In fact I always lanuch fricas
with "-nox". I can find most information from terminal, if not,
I'll go for source code.

- Qian

[Qian Yun]

On 3/20/21 2:20 AM, Waldek Hebisch wrote:
>
> We need some graphic environment. Simple fact of life is that
> up to now X11 was most stable environment. Namely, old 30
> years old programs work as they used to work. Unfortunatly,
> this is not the case with newer things, my graphic code
> for "famework of the day" got broken in few years. And a lot
> of folks have similar experience.

If X11 becomes obsolete (let's say 20 years later), would you
agree to include another graphic framework into our repo?

> Let me add that retargetting our existing programs say to
> WinAPI would be rather easy (and would not require breaking
> X11 support), but nobody voluntereed to do the work. It
> seems that people prefer to work on new code, probably
> because in new code they can concentrate on core things
> and (at least at beginning ignore some system aspects and
> corner cases). But for long term interface it is exactly
> handling of system aspects and corner cases that determines
> viablility. Adapting tried code in very slowly evolving
> environment is much easier than coping with rapid breaking
> chages in "modern" systems.

I don't think there are many "corner cases" get improved in
HyperDoc in the past 20 years? Probably because it doesn't
attract many users, thus fewer developers.

> Another apect is performace: our X11 programs have by
> current standard very small resource requirements and
> high performace. Browsers (and web page code) tend to
> get slower faster than hardware get faster so for
> long time we can expect bad performance.

No modern GUI toolkits can beat X11 in terms of low RAM
usage. (But it can beat X11 in performance by using
GPU rendering in some cases.)

I would say X11 programs has its own list of disadvantages:
1. Security. (One reason it is getting replaced by wayland.)
2. Performance. Because rendering using CPU is much slower than GPU.
3. i18n. I don't think X11 libs can do truetype fonts and RTL languages?

Anyway, back to original problem, I'll give X11 support on
macOS another try.

- Qian

[Ralf Hemmecke]

> I don't think there are many "corner cases" get improved in
> HyperDoc in the past 20 years?  Probably because it doesn't
> attract many users, thus fewer developers.

One of the reasons why I would like to get rid of HyperDoc is that it is
legacy software that hinders us to go on more freely.

If you are unaware of it ... HyperDoc contains a full copy of the FriCAS
book (https://fricas.github.io/book.pdf). And basically the same
information as is now at http://fricas.github.io/api/.

The language for HyperDoc is called HyperTeX and is a small subset of
TeX, with some extensions for creations of menus etc. Most of the
sources for the Book is in .htex file. They are basically LaTeX files
that can easily be translated to the .ht (hypertex) format. But these
.htex files must follow a simple structure, because they are modified by
simple looking awk scripts.
Actually the book doesn't bother me too much, but I would really like to
agree on a better format for the ++ docstrings. Who really knows how
formatting is to be done for ++ docstrings? I cannot make
http://fricas.github.io/api looking much better. It's not a question of
"the API stuff needs online access", because if we would agree, we could
also distribute that information for local access on the users computer,
easily accessible with an ordinary browser.

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". Admittedly, that
is a very useful feature, but that should/could rather be available from
the FriCAS command line. I actually don't like to start an X programm
(HyperDoc) only to find out about which domain implements some function.

If this feature is provided in another way, then we could slowly let
HyperDoc rest in peace.

Ralf

[Qian Yun]

The reason is that xterm is not longer installed by default.
Termainl.app is basically a native graphical terminal emulator.

About X11 support:

Simply "brew install libx11 libxpm libice libsm" and configure
with X11, the result FriCAS binary works fine on macOS with X11,
when the X11 server XQuartz is installed.

So, may I commit my original commit?

- Qian

[Bill Page]

On Sun, Mar 21, 2021 at 8:25 AM Ralf Hemmecke <ra...@hemmecke.org> 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. I
find this a critically important feature of FriCAS. Without it I would
feel like I was lost, even though of course it is always possible to
"read the source code" and search through (often somewhat dubious)
documentation.

> Admittedly, that is a very useful feature, but that
> should/could rather be available from the FriCAS
> command line.

I disagree strongly. Navigating the type hierarchy is something that
is ideal for a web browser-like interface. That is what HyperDoc
is/was all about. The word "hyper" is exactly from this early (1970's
?) vision of what web browsers would later become.

> I actually don't like to start an X programm
> (HyperDoc) only to find out about which domain
> implements some function.
>

That is exactly the reason why I use HyperDoc in almost every FriCAS session.

> If this feature is provided in another way, then we could
> slowly let HyperDoc rest in peace.
>

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.

Bill Page.

[Waldek Hebisch]

On Sun, Mar 21, 2021 at 09:04:48PM +0800, Qian Yun wrote:
> The reason is that xterm is not longer installed by default.
> Termainl.app is basically a native graphical terminal emulator.
>
> About X11 support:
>
> Simply "brew install libx11 libxpm libice libsm" and configure
> with X11, the result FriCAS binary works fine on macOS with X11,
> when the X11 server XQuartz is installed.
>
> So, may I commit my original commit?

Yes, OK.
--
Waldek Hebisch

[Waldek Hebisch]

On Sun, Mar 21, 2021 at 07:55:06PM +0800, Qian Yun wrote:
>
>
> On 3/20/21 2:20 AM, Waldek Hebisch wrote:
> >
> > We need some graphic environment. Simple fact of life is that
> > up to now X11 was most stable environment. Namely, old 30
> > years old programs work as they used to work. Unfortunatly,
> > this is not the case with newer things, my graphic code
> > for "famework of the day" got broken in few years. And a lot
> > of folks have similar experience.
>
> If X11 becomes obsolete (let's say 20 years later), would you
> agree to include another graphic framework into our repo?

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...

Concerning what I look at:

- first, code must be useful and of resonable quality, this
is not a high barrier and quite natural
- build and dependencies: FriCAS should build cleanly with
new components added. New mandatory dependency requires
quite string justification. Optional dependecy, say when
you disable new component when dependency is not present
is OK. However, with optional dependecy the component
itself becomes optional and core parts can not depend on
its presence.

Having said that, much of power of system comes from
cooperation, that is how well various components play
together. There is scenegraph subsystems by Martion
Baker. AFAICS it is underutilised. At leat for me
major obstacle in using this subsystem is that it
lives in its own world, with rather narrow connection
to other graphic components in FriCAS. I have
rather detailed opinions about what develepements
would be most useful for FriCAS, but ultimately
people who write code decide what gets written.

Different matter is removal of code. While I like
to remove dead code, when removing functionality
I am more careful. For example, I mostly use
HyperDoc and make almost no use of ')show'. But
I do not propose removal of ')show'. Paraphrasionig
what what said about HyperDoc in other messages
somebody could say: "HyperDoc is now supported on
all our platforms, so ')show' can be removed"
(on Windows one can get HyperDoc via Cygwin or WSL).
There were proposed patches which removed some
functionality on principle that is is easier
than keep code working. This can be valid argument,
but only rarely (and most that should be removed is
already removed).

> > Let me add that retargetting our existing programs say to
> > WinAPI would be rather easy (and would not require breaking
> > X11 support), but nobody voluntereed to do the work. It
> > seems that people prefer to work on new code, probably
> > because in new code they can concentrate on core things
> > and (at least at beginning ignore some system aspects and
> > corner cases). But for long term interface it is exactly
> > handling of system aspects and corner cases that determines
> > viablility. Adapting tried code in very slowly evolving
> > environment is much easier than coping with rapid breaking
> > chages in "modern" systems.
>
> I don't think there are many "corner cases" get improved in
> HyperDoc in the past 20 years? Probably because it doesn't
> attract many users, thus fewer developers.

There is a buch of fixes on C side. More important, large
(one can argue that main) part of HyperDoc subsystem is
in written in Boot and included in FRICASsys. This part
got a lot of fixes and cleanups.

> > Another apect is performace: our X11 programs have by
> > current standard very small resource requirements and
> > high performace. Browsers (and web page code) tend to
> > get slower faster than hardware get faster so for
> > long time we can expect bad performance.
>
> No modern GUI toolkits can beat X11 in terms of low RAM
> usage. (But it can beat X11 in performance by using
> GPU rendering in some cases.)
>
> I would say X11 programs has its own list of disadvantages:
> 1. Security. (One reason it is getting replaced by wayland.)

I am not aware of security problems specific to X11. AFAICS
main problem is that X subsystem is large piece of code dealing
with sensitive data. IMO any GUI will have the same core
problem. Of course, new implementation can take advantage
of past experience and avoid known problems. But the
unknown problems are main issue. Also, new design/implementation
usualy starts from mainstream applications. That frequently
can by done by simpler approach than general case. To
be more specific IIUC Android proposes new security regime,
supposed to be much safer than trandtiononal Unix way.
But my understanding is that many everday activities does
not fit well into Android model, either depriving users
of functionality or needing holes in security model.
So, IMHO before Wayland gets enough testing it is premature
to make security claims.

> 2. Performance. Because rendering using CPU is much slower than GPU.

X11 has extentions. Direct access to acceleration functions in
cards was available for many years. More important, for majority
of normal programs is rendering is fast enough. And rendering is
mostly handled by library/X server code, so once distribution is
updated it will automatically use whatever acceleration is
available. Of course, programs like games must be aware of
extensions and use them.

> 3. i18n. I don't think X11 libs can do truetype fonts and RTL languages?

IIRC from the start X11 had framework for internationalization.
Of course, it depends on vendors/distributions how well they
use that framwork. For example it took long time to get widely
distributed Unicode fonts (but it is not problem of X, but
availability of fonts). In particular, in traditional X way
all applications had to do was to choose appropriate font
names. IIUC problems with truetype fonts was/are mostly legal
(my understaning is that free implementations are not allowed
to support "hinting") and that limited availability, X can use
them if included in build. There is also "new" trend that
moves fonts to client side. I am not sure how much impact
this have.

Anyway, by design X11 protocol is extensible and new features
my be supported by extensions or appropriate conventions.

--
Waldek Hebisch

[Waldek Hebisch]

On Sun, Mar 21, 2021 at 01:25:24PM +0100, 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". Admittedly, that
> is a very useful feature, but that should/could rather be available from
> the FriCAS command line. I actually don't like to start an X programm
> (HyperDoc) only to find out about which domain implements some function.

I think that you vastly underestimate HyperDoc. Namely, part included
in FRICASsys is designed to support dynamic GUI with rich user
interaction. We miss important part of this (Texexplorer renderer),
but _all_ (or maybe almost all as some Texexplorer specific parts
are removed) that is needed in FRICASsys is already present.

I think you underestimate fact that HyperDoc machinery dynamically
creates rich cross-links (only part of them is used by HyperDoc
interface). I did not see Texexplorer in action, but code
suggest that you can click on parts of displayed results to
get extra type info (and mybe also documentation links).
To re-create such functionalty you would need either use exiting
HyperDoc support or implement equivalent in your interface. Clearly
duplicating such things in each interace is wasteful, so
I would prefer to use shared functionality.

Concerning "start an X programm", I very much prefer to start
small X program (HyperDoc) to a bloated one (web browser).
In fact, for getting things from web I normally use lynx or wget
and start graphical browser only once in few days.

--
Waldek Hebisch

[Ralf Hemmecke]

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. I guess, we have lost
Robert Smith for contribution to FriCAS. 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.

Ralf

[Bill Page]

On Sun, Mar 21, 2021 at 1:51 PM Ralf Hemmecke <ra...@hemmecke.org> wrote:

> ...

> 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.

I think this is an inadequate response for most potential developers.
Of course it is OK to fork - FriCAS is an open source project. But
this is like telling someone to "go away and not come back until you
have something more interesting to say ." Visibility _within_ the
project is important. There has to be some way to be more welcoming
and encourage "off-trunk" development - maybe the more frequent
creation of development branches within the FriCAS repository?

[Bill Page]

On Sun, Mar 21, 2021 at 10:29 AM Ralf Hemmecke <ra...@hemmecke.org> wrote:

>
> On 21.03.21 15:00, Bill Page wrote:
> > On Sun, Mar 21, 2021 at 8:25 AM Ralf Hemmecke <ra...@hemmecke.org>
> > 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.

[Bill Page]

On Mon, Mar 22, 2021 at 9:59 AM Bill Page <bill...@newsynthesis.org> 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:

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

[Ralf Hemmecke]

> 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

- <policy domain="coder" rights="none" pattern="PS" />
+ <policy domain="coder" rights="read|write" pattern="PS" />

in /etc/ImageMagick/policy.xml in order to create .ps files.

Any suggestion?

Ralf

[Waldek Hebisch]

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

[Waldek Hebisch]

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

[Ralf Hemmecke]

> 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

[Waldek Hebisch]

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

[Dima Pasechnik]

On Mon, Mar 22, 2021 at 9:43 PM Waldek Hebisch <heb...@math.uni.wroc.pl> 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...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/20210322214330.GA7130%40math.uni.wroc.pl.

[Waldek Hebisch]

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

[Bill Page]

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.

[Ralf Hemmecke]

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

[Dima Pasechnik]

On Mon, Mar 22, 2021 at 11:12 PM Waldek Hebisch

E.g. Common Lisp, yes, very new and hot. :-)

Or send stuff to plot to gnuplot (that's what Maxima does)

> --
> 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...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/20210322231215.GB7130%40math.uni.wroc.pl.

[Ralf Hemmecke]

> 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

[Bill Page]

On Tue, Mar 23, 2021 at 3:57 AM Ralf Hemmecke <ra...@hemmecke.org> 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.

[Ralf Hemmecke]

> 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

[Bill Page]

On Tue, Mar 23, 2021 at 2:01 PM Ralf Hemmecke <ra...@hemmecke.de> 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.

[Ralf Hemmecke]

> 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

[Kurt Pagani]

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 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)
-preview Previews the output with QGLE
-version Selects 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
-tex Indicates that the script includes LaTeX expressions
-inc Creates 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
-nocolor Forces grayscale output
-inverse Render black as white for using on dark backgrounds
-transparent Creates transparent output (with -d png)
-noctrl-d Excludes CTRL-D from the PostScript output
-nomaxpath Disables the upper-bound on the drawing path complexity
-noligatures Disable 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 dev/release cycles of
this packages are quite rapid, users have to know/learn special syntax and last
but not least it might depend on browser flavour and javascript libraries.

So, coming to an end, my suggestion is to build upon GLE by utilizing the Fricas
domains Plot and Plot3D. The idea is to create a graphic object (a Record in
SPAD) that may be manipulated (overwrite defaults) and displayed in QGLE,
Texmacs, Jupyter or finalized in one of the graphic formats (ps, png etc.).

Instead of tiresome explanations I have attached a demo_gle.tar.gz containing a
rudimentary prototype, albeit one has to install the prerequisites:

sudo apt install gle-graphics
sudo apt install ghostscript # for TeX text/titles, otherwise optional

# checks
apt list -a gle-graphics
gle-graphics/bionic,now 4.2.5-7 amd64 [installed]

apt list -a ghostscript
ghostscript/bionic 9.22~dfsg+1-0ubuntu1 amd64

# test

$ qgle
should open an window, and

$ gle --version
GLE version 4.2.5
Usage: gle [options] filename.gle
More information: gle -help

To run the demo, extract "demo_gle.tar.gz" into /tmp or wherever, start fricas and

)read demo_qgle

which compiles gle.spad and provides two functions, demo() and demo3d().
Starting with

demo()

a first QGLE windows should open. The show will proceed when closing one window
after another (by upper right [X]), about five times. This should give an
impression about the quality and the features of QGLE.
The same can be done with

demo3d() -- only 2 windows ;)

Another - more simple - approach could be to tune view2D.spad, view3D.spad and
draw.spad allowing (users choice) different frontends for the "draw" command. I
did this 5y ago (https://github.com/nilqed/fricas_input/tree/master/spad/draw,
see the patches and drawfe.spad), the result of test_draw.input can be seen
here: https://kfp.bitbucket.io/drawfe/ (just an example as gnuplot sixel
(gnuplot itself provides a huge amount of 'set terminal' options). I would not
pursue this; too little gain for my taste compared to the builtin graphics.

Now it's up to the community to set the agenda. If no one is interested, then we
should allow the topic to rest awhile. The inventive mind will hardly produce
graphics form within fricas anyway?

On 23.03.2021 21:23, Ralf Hemmecke wrote:
>> How easy would it be to try KaTeX? https://katex.org/ Maybe someone
>> has already tried this?

It has actually improved since I tried some years ago (was not complete, but
fast). Using it in Jupyter might certainly be an option. At the moment, however,
MathJax is a dependency of Jupyter (installed with the core nb) and has some
advantages over KaTeX (AFAIK, might have changed) in that one can easily pick
the LaTeX source code by right clicking on the displayed formula. Moreover, I'm
quite sure that the speed of MathJax will improve in the near future (it's not
so bad at all).

> 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.

You're right, far from production, however if there is a compass, I guess it
will be doable in reasonable time, but as I am more the 'prototyper' (I dread
the last mile) it won't go without your discipline and persistency :)
>
> Ralf
>

[Ralf Hemmecke]

>> 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

[Dima Pasechnik]

On Wed, Mar 24, 2021 at 4:14 AM Kurt Pagani <nil...@gmail.com> 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

> --
> 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...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/a560d11e-3726-ba62-89eb-32e5c106236a%40gmail.com.

[Ralf Hemmecke]

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

[Dima Pasechnik]

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...@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.

[Ralf Hemmecke]

> 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

[Andrey G. Grozin]

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

[Kurt Pagani]

>>
>> 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.

[Kurt Pagani]

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
>

[Kurt Pagani]

On 23.03.2021 20:41, Bill Page wrote:
> On Tue, Mar 23, 2021 at 2:01 PM Ralf Hemmecke <ra...@hemmecke.de> 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.

[Waldek Hebisch]

On Thu, Mar 18, 2021 at 07:49:49PM +0800, Qian Yun wrote:
> This is the change I made to get the macOS dmg working.
> Not very elegant, but I wonder if there is a better way?
>
> Comments are welcome. And macOS users can try/test the binary
> at https://github.com/oldk1331/fricas/actions/runs/664218153
>
> - Qian
>
> https://github.com/fricas/fricas/commit/ed1f43ad1a7be891a6bbb050b055e2ff7f9f3ab8.patch
>
> diff --git a/Makefile.in b/Makefile.in
> index f50f0bde3..17af45595 100644
> --- a/Makefile.in
> +++ b/Makefile.in
> @@ -133,9 +133,11 @@
> echo exec_prefix='"$${FRICAS_PREFIX:-$(exec_prefix)}"' \
> >> '${COMMAND}'.tmp
> if test "$(fricas_lib)" != "$(libdir)" ; then \
> - echo \
> - FRICAS='"$${exec_prefix}/$(fricas_lib)/fricas/target/$(target)"' \
> - >> '${COMMAND}'.tmp ; \
> + if test $(uname -s) != "Darwin" ; then \
^^
$$(uname -s)
> + echo
> FRICAS='"$${exec_prefix}/$(fricas_lib)/fricas/target/$(target)"' >>
> '${COMMAND}'.tmp ; \
> + else \
> + echo FRICAS='"`dirname
> $$0`/../$(fricas_lib)/fricas/target/$(target)"' >> '${COMMAND}'.tmp ; \
> + fi \
> else \
> echo FRICAS='"$(libdir)/fricas/target/$(target)"' \
> >> '${COMMAND}'.tmp ; \

Hi Qian, I wonder why you wanted the 'dirname $$0' part? It breaks
internal 'fricas' script for its intended uses, in particular
it causes problem reported by Gregory Vanuxem, that is failure
of 'efricas'. AFAICS you intended 'dirname $$0' part to be
used only on Mac OS, but you need to double '$' for this.
Doubling '$' fixes problem on other systems, but there remain
question what 'dirname $$0' solves? I think that even on
Mac OS it does not work for internal 'fricas' script.

--
Waldek Hebisch

[oldk1331]

Yes, you are right about the double '$' error.

About 'dirname $$0', that was intended to be used by DMG packaging.
Indeed it breaks traditional "make install" installation. Let me find a
better solution.

- Qian