This can be considered as a sub-issue of the "sman in pipe"
issue.
When running in terminal, Ctrl-D is interpreted as EOF,
causing "read" to return 0, this does not mean the input
is finished.
When running in pipe, EOF ("read" returns 0) means the
end of input, we should remove fd 0 from "select",
otherwise we get this problem of 100% CPU in "spadclient".
- Qian
On 6/11/24 07:56, Qian Yun wrote:
Can you reprodce this?
We can see that 'spadclient' is taking 100% CPU.
Which is stange.
I'd like to see a "strace" output of this process.
- Qian
On 6/11/24 04:23, Ralf Hemmecke wrote:
Sorry, but I am still unhappy with Qian's stuff.
I just compiled with -j1 and it hangs here.
$tail -f /dev/shm/hemmecke/fricas/b/src/doc/tmp/ug07.spool
-- \end{TeXOutput}
-- \begin{MessageOutput}
Type:
TwoDimensionalViewport
-- \end{MessageOutput}
-- \end{xtcnooutput}
-- \includespadgraph{2DppcB}
-- \begin{xtcnooutput}
write(%, "tmp/2DppcB", "postscript"); close(%)
^C
and leaving the following processes (see below).
If this becomes the release, then we will ship a broken version that
only finishes compiling when you are lucky.
I try to investigate the patches now. Some seem acceptable, but I
think piping the generated (from .htex) .input files through fricas
(i.e. sman) instead of directly to FRICASsys causes all the problems
with hanging compilation or truncation of output.
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/1193066b-9bcd-4104-a52d-5432ccca6003%40gmail.com.
