Just take a deeper look. If you start with "fricas -nox", you can start hyperDoc later with ")hd", which is just a shorthand for ")system hypertex &".
And it seems that ")system /usr/lib64/fricas/target/x86_64-pc-linux-gnu/lib/viewman &" works as well. So if I dig deeper and find that there is no special reason for sman to spawn "viewman" endlessly, we can treat it the same as "hyertex": sman will just spawn it once when launch fricas, user can spawn it manually when needed. - Qian On 6/14/22 09:16, Waldek Hebisch wrote:
On Sat, Jun 11, 2022 at 03:52:55PM +0800, Qian Yun wrote:The description of this bug: 1. First, I found this bug on macOS, when I run the binary from GitHub CI, which is built with X11 support. But the system does not include any X11 libraries, because they are not installed from homebrew yet. Start "fricas" with no options will cause the screen to be flooded with error messages that viewman has problem loading shared libraries. 2. So this is easily reproduced on Linux as well. Simply rename a X11 .so file (for example /usr/lib64/libXpm.so.4) to something else and you can reproduce this bug. (Remember to rename it back!) Further more, running a pre-built FriCAS distribution with X11 support on a server or a container that does not have X11 libraries will meet this bug. ==== The simpliest workaround is to use "fricas -nogr". The relevant code is in src/sman/sman.c: static void start_the_graphics(void) { spawn_of_hell(GraphicsProgram, DoItAgain); } The "DoItAgain" flag causes sman to start it endlessly. Not sure why it is designed this way. If we start with "fricas -nox", we can start hyperdoc by ")hd", but we can not use "draw" anymore. This should be related.Missing library is system/installation error. In such case you can not expect FriCAS to work properly. Of course, infinite loop of error messages is not nice, but IMO this is relatively low priority issue, it is more important to ensure that required libraries are preset. Considering loop of respawning, AFAICS if things work OK it should be not needed. It seems that orignals authors believed that respawning masks some problems. I hope that some day we will have more sane code on C side. However, small tweaks are unlikely to converge to better stucture unless there is enough advance plannig. As I wrote, I would like to change communication protocol between various parts of FriCAS. Precondition for protocol change is getting right structure on Boot/Lisp side, in particular isolating all I/O. We are close to this, but still not there...
-- You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/3ce8bb8f-d56b-49c2-7a48-10a5001b4b30%40gmail.com.
