[PATCH] generate book.pdf with PS image instead of bitmap image

[Qian Yun]

With this patch, the book.pdf uses PS format images instead of
using imagemagick to "covert" from bitmap xpm images.

Also as Ralf wishes, now the build of book is independent from
build of hypertex pages.

P.S to Ralf, this patch uses a few lines of your noOutputXtc patch,
you should upstream that first.

Also after this patch, src/doc/ps/arrowr.ps SEGBIND.ps knot3.ps
ribbon2r.ps ribbons2.ps ribbons2b.ps can be removed, saves 1.3MB
and 81123 lines from repo.

https://github.com/oldk1331/fricas/commit/46b2e034148674eb05834d8a642d337b1162b897.patch

- Qian

[Waldek Hebisch]

On Thu, Apr 25, 2024 at 09:36:45PM +0800, Qian Yun wrote:
> With this patch, the book.pdf uses PS format images instead of
> using imagemagick to "covert" from bitmap xpm images.

Good.

> Also as Ralf wishes, now the build of book is independent from
> build of hypertex pages.
>
> P.S to Ralf, this patch uses a few lines of your noOutputXtc patch,
> you should upstream that first.

There is some problem with this. On my machine I got faulty
'TEXTFILE.tex', it contained '\begin{noOutputXtc}' but no
matching end part, causing documentaion build failure.

For me titles of pictures are too small, in bitmapped version
title letters are of comparable size to text letters, in .ps
version are smaller and almost unreadable when text has comfortable
size.

I also noticed problem which has nothing to do with the patch:
in 5.4.5 there is an example computing 100!. In HyperDoc
number appears fine, but in the .pdf it is truncated.

In slightly different spirit: book convention of having separate
page numbers in "front matter" and in main part IMO is misguided
in .pdf: viewer allows navigation by page number, but number on
pages and numbers in viewer frequently diverge. IMO it would be
good to adopt uniform numbering. Also, maybe print full section
number in the page header, that is 5.4.5 instad of current 5.4.

> Also after this patch, src/doc/ps/arrowr.ps SEGBIND.ps knot3.ps
> ribbon2r.ps ribbons2.ps ribbons2b.ps can be removed, saves 1.3MB
> and 81123 lines from repo.
>
> https://github.com/oldk1331/fricas/commit/46b2e034148674eb05834d8a642d337b1162b897.patch

I think that they should be removed in the same commit as your
patch (when it goes in).

> From: Qian Yun <oldk...@gmail.com>
> Date: Thu, 25 Apr 2024 21:27:43 +0800
> Subject: [PATCH] generate book with ps image instead of bitmap image
>
> ---
> src/doc/Makefile.in | 29 +++++++++++++++--------------
> src/doc/fricas.sty | 4 +++-
> src/doc/htex/SEGBIND.htex | 2 +-
> src/doc/htex2input.awk | 28 ++++++++++++++++++++++++++--
> src/doc/spool2tex.awk | 3 +++
> src/doc/ugepsf.awk | 24 ------------------------
> src/input/images1.input | 7 ++++++-
> src/input/ug-pics.input | 28 ++++++++++++++++++++++++++++
> 8 files changed, 82 insertions(+), 43 deletions(-)
> delete mode 100644 src/doc/ugepsf.awk
> create mode 100644 src/input/ug-pics.input
>
> diff --git a/src/doc/Makefile.in b/src/doc/Makefile.in
> index 7093802ec..68e214a62 100644
> --- a/src/doc/Makefile.in
> +++ b/src/doc/Makefile.in
> @@ -46,9 +46,7 @@
> #
> # "make book.pdf" does the following:
> # - Copy pictures from the ps/ directory for (documentation of HyperDoc).
> -# - Convert the *.VIEW/image.xpm pictures to .ps images (target stamp-pics).
> -# That expects all the .VIEW/ directories to exist (make viewports).
> -# It needs the convert program from ImageMagick. See ugepsf.awk.
> +# - Copy pictures from tmp/*.VIEW/image.ps (target stamp-pics).
> # - Generate tmo/ug09.tex with the list of examples.
> # - Create tmp/*.input from htex/*.htex (target ${HTEX_FILES_INPUT}).
> # The .input files contain the commands that should be executed.
> @@ -138,7 +136,6 @@ UGSYSCMD2HELP = ${AWK} -f ${srcdir}/syscmd.awk
> HTEX2INPUT = ${AWK} -f ${srcdir}/htex2input.awk
> SPOOL2TEX = ${AWK} -f ${srcdir}/spool2tex.awk
> UGEXAMPLES = ${AWK} -f ${srcdir}/ugexamples.awk
> -UGEPSF = ${AWK} -f ${srcdir}/ugepsf.awk
>
> ###################################################################
> # Most of the variables below are designed in the following way: If
> @@ -297,7 +294,8 @@ HTEX_PASTEFILES = \
> # HyperDoc and book.pdf.
> # The list can be generated by the following command.
> # grep -R '\\spadcommand{)read' *| sed 's/[^ ]* //;s/[ \].*//'|sort -u
> -INPUT_EXTRA = arrows bouquet newton ribbon vectors
> +INPUT_EXTRA = arrows bouquet newton ribbon vectors \
> + ntube tknot images1 ug-pics
>
> ###################################################################
> # For these files .ht files will be generated.
> @@ -634,7 +632,9 @@ ${HTEX_FILES_INPUT}: tmp/%.input: ${htexsrcdir}/%.htex
> HTEX_FILES_SPOOL = ${patsubst %, tmp/%.spool, ${HTEX_FILES}}
> ${HTEX_FILES_SPOOL}: tmp/%.spool: tmp/%.input
> ${MKDIR_P} tmp
> - echo ")read $<" | FRICAS_INITFILE='' ${INTERPSYS} > $@
> + (unset DAASE; FRICAS=${FRICAS}; export FRICAS; \
> + echo ')read $<' | FRICAS_INITFILE='' ${XVFB} \
> + ${FRICAS}/bin/fricas -noht -noclef > $@)
>
> HTEX_FILES_TEX = ${patsubst %, tmp/%.tex, ${HTEX_FILES}}
> ${HTEX_FILES_TEX}: tmp/%.tex: tmp/%.spool
> @@ -645,17 +645,12 @@ tmp/ug09.tex: tmp/examples.list
> ${MKDIR_P} tmp
> ${UGEXAMPLES} $< > $@
>
> -pics.mk:
> - grep '\(\\head{\|\\psXtc\|\xtc\|\\noOutputXtc\|\\nullXtc\|epsffile\|\\spadgraph\)' ${srcdir}/htex/ug*.htex \
> - | ${UGEPSF} > $@
> -
> ###################################################################
> # There are a number of pictures for sections in book.pdf that
> # demonstrate the use of HyperDoc.
> PS_FILES = \
> exit help home up \
> - ribbon2r ribbons2 ribbons2b \
> - 2Dctrl 3Dctrl SEGBIND arrowr knot3 \
> + 2Dctrl 3Dctrl \
> h-alldoms h-allrank h-atsearch h-brfront h-comsearch h-consearch \
> h-docsearch h-gensearch h-matargs h-matats h-matdesc h-matexamp \
> h-matexports h-matimp h-matinv h-matmap h-matops h-matpage \
> @@ -665,8 +660,14 @@ PS_FILES_PS = ${patsubst %, %.ps, ${PS_FILES}}
> ${PS_FILES_PS}: %.ps: ${pssrcdir}/%.ps
> cp $< $@
>
> -stamp-pics: pics.mk viewports ${PS_FILES_PS}
> - ${MAKE} -f pics.mk pics
> +stamp-pics: ${INPUT_EXTRA_INPUT} ${HTEX_FILES_SPOOL} ${PS_FILES_PS}
> + ${MKDIR_P} tmp
> + (unset DAASE; FRICAS=${FRICAS}; export FRICAS; \
> + echo ')read ug-pics' | FRICAS_INITFILE='' ${XVFB} \
> + ${FRICAS}/bin/fricas -noht -noclef)
> + for f in tmp/*.VIEW/image.ps; do \
> + cp $$f `echo $$f | cut -d / -f 2 | cut -d . -f 1`.ps; \
> + done
> ${STAMP} $@
>
> ###################################################################
> diff --git a/src/doc/fricas.sty b/src/doc/fricas.sty
> index 5d734a023..de186b06c 100644
> --- a/src/doc/fricas.sty
> +++ b/src/doc/fricas.sty
> @@ -16,7 +16,8 @@
> \usepackage{epsf}
> \def\epsfsize#1#2{.24\textheight}
> \let\spadepsffilesave\epsffile
> -\def\epsffile[#1]#2{\begin{center}\spadepsffilesave[#1]{#2}\end{center}}
> +%\def\epsffile[#1]#2{\begin{center}\spadepsffilesave[#1]{#2}\end{center}}
> +\def\epsffile[#1]#2{\begin{center}\includegraphics[height=.24\textheight]{#2}\end{center}}
>
> \usepackage{fricasmath}
> \usepackage{verbatim} % Needed for the discard environment.
> @@ -24,6 +25,7 @@
> \usepackage{color}
> \usepackage{listings}
> \usepackage{makeidx}
> +\usepackage{graphicx}
> \makeindex
>
> % We use xparse for the definition of a number of verbatim-like
> diff --git a/src/doc/htex/SEGBIND.htex b/src/doc/htex/SEGBIND.htex
> index fb6e1c1f8..d9e417ca7 100644
> --- a/src/doc/htex/SEGBIND.htex
> +++ b/src/doc/htex/SEGBIND.htex
> @@ -58,7 +58,7 @@ This is an example of a two-dimensional parametrized plot;
> other \spadfun{draw} options use more than one
> \spadtype{SegmentBinding} argument.
> }{
> -\spadcommand{draw(x^2, x = -2..2)}
> +\spadgraph{draw(x^2, x = -2..2)}
> }{
> % window was 256 x 256
> \epsffile[72 72 300 300]{SEGBIND.ps}
> diff --git a/src/doc/htex2input.awk b/src/doc/htex2input.awk
> index 48b06a983..60f362212 100644
> --- a/src/doc/htex2input.awk
> +++ b/src/doc/htex2input.awk
> @@ -62,11 +62,13 @@ END {
>
> /^} *$/ && xtc>1 {
> xtc=0
> + spadgraph=0
> print "-- \\end{" xtcname "}"
> next
> }
>
> xtc==2 && (/^\\spadcommand{/ || /^\\spadgraph{/) {
> + if (match($0, /^\\spadgraph{/)) spadgraph=1
> print "-- \\begin{spadsrc}"
> gsub(/^\\spadcommand{/, "")
> gsub(/^\\spadgraph{/, "")
> @@ -79,7 +81,13 @@ xtc==2 && (/^\\spadcommand{/ || /^\\spadgraph{/) {
> gsub(/\\bound{.*/, "")
> print "-- " $0
> print "-- \\end{spadsrc}"
> - if (xtcname=="xtc" || xtcname=="noOutputXtc") {print $0}
> + if (xtcname=="psXtc" || xtcname=="noOutputXtc") {
> + print "-- \\begin{xtcnooutput}"
> + }
> + if (xtcname=="xtc" || xtcname=="noOutputXtc" || xtcname=="psXtc") {print $0}
> + if (xtcname=="psXtc" || xtcname=="noOutputXtc") {
> + print "-- \\end{xtcnooutput}"
> + }
> next
> }
>
> @@ -114,7 +122,23 @@ xtc==2 && /^\\begin{spadsrc}/ {
> next
> }
>
> -/^}{/ && xtc==2 {next}
> +/^}{/ && xtc==2 {
> + xtc=3
> + next
> +}
> +
> +xtc==3 && /^\\epsffile/ {
> + print "-- " $0
> + if (xtcname == "psXtc" && spadgraph == 1) {
> + gsub(/^\\epsffile.*{/, "")
> + gsub(/}$/, "")
> + print "-- \\begin{xtcnooutput}"
> + print "write(%, \"tmp/" $0 "\", \"postscript\")"
> + print "close(%%(-2))"
> + print "-- \\end{xtcnooutput}"
> + }
> + next
> +}
>
> {
> print "-- " $0
> diff --git a/src/doc/spool2tex.awk b/src/doc/spool2tex.awk
> index 6fcd74c2a..a459cdd92 100644
> --- a/src/doc/spool2tex.awk
> +++ b/src/doc/spool2tex.awk
> @@ -35,6 +35,9 @@ BEGIN {
> # Discard \begin{inputonly} ... \end{inputonly}.
> /^-- \\begin{inputonly}/,/^-- \\end{inputonly}/ {next}
>
> +# Discard \begin{xtcnooutput} ... \end{xtcnooutput}.
> +/^-- \\begin{xtcnooutput}/,/^-- \\end{xtcnooutput}/ {next}
> +
> # start of xtc
> /^-- \\begin{xtc}/ || /^-- \\begin{noOutputXtc}/ {
> inxtc=1
> diff --git a/src/doc/ugepsf.awk b/src/doc/ugepsf.awk
> deleted file mode 100644
> index e39ddde9e..000000000
> --- a/src/doc/ugepsf.awk
> +++ /dev/null
> @@ -1,24 +0,0 @@
> -/:\\head/ {
> - sub(/.*{/,"")
> - sub(/}/,"")
> - view=$0 "Page"
> - n=0
> -}
> -
> -(/:\\psXtc/ || /:\\xtc/ || /:\\noOutputXtc/ || /:\\nullXtc/) {n++}
> -
> -/:\\spadgraph/ {spadgraph=1}
> -
> -/:\\epsffile/ {
> - sub(/.*{/,"")
> - gsub(/}/,"")
> - sub(/.*\//,"")
> - if (spadgraph==1) {
> - print "pics: " $0
> - } else {
> - print "no-pics: " $0
> - }
> - print $0 ": " view n ".VIEW/image.xpm"
> - print "\tconvert $< $@"
> - spadgraph=0
> -}
> diff --git a/src/input/images1.input b/src/input/images1.input
> index c74dac6a1..3f9425150 100644
> --- a/src/input/images1.input
> +++ b/src/input/images1.input
> @@ -5,4 +5,9 @@
>
> -- draw a (15,17) torus knot
>
> -torusKnot(15,17, 0.1, 6, 700)
> +vp := torusKnot(15,17, 0.1, 6, 700)
> +
> +title(vp, ""); axes(vp, "off"); rotate(vp, 90, 0)
> +zoom(vp, 1.9); outlineRender(vp, "off")
> +write(vp, "tmp/knot3.ps", "postscript")
> +close(vp)
> diff --git a/src/input/ug-pics.input b/src/input/ug-pics.input
> new file mode 100644
> index 000000000..ced3a84c0
> --- /dev/null
> +++ b/src/input/ug-pics.input
> @@ -0,0 +1,28 @@
> +-- chapter 10
> +vp := draw(x^2,x=-1..1,y=0..1,var2Steps==1)
> +
> +rotate(vp, 0, -90)
> +write(vp, "tmp/ribbon2r.ps", "postscript")
> +
> +sp := subspace(vp)
> +close(vp)
> +
> +vp := draw(x^3,x=-1..1,y=1..2,var2Steps==1, space==sp)
> +
> +drawStyle(vp,"shade");outlineRender(vp,"on")
> +write(vp, "tmp/ribbons2.ps", "postscript")
> +
> +rotate(vp,20,-60); showRegion(vp,"on")
> +write(vp, "tmp/ribbons2b.ps", "postscript")
> +close(vp)
> +
> +vp := makeViewport3D(sp,"Arrow")
> +
> +rotate(vp,200,-60)
> +write(vp, "tmp/arrowr.ps", "postscript")
> +close(vp)
> +
> +-- chapter 7
> +)read images1
> +
> +)quit


--
Waldek Hebisch

[Qian Yun]

On 4/26/24 06:00, Waldek Hebisch wrote:
>
> There is some problem with this. On my machine I got faulty
> 'TEXTFILE.tex', it contained '\begin{noOutputXtc}' but no
> matching end part, causing documentaion build failure.

This does not always happen, and sometimes happen to other
tmp/*tex file. The problem is that this TeX file missing
a few last lines.

This commit changes the processing of input->spool->tex from
interpsys to fricas (with sman). So I guess it is caused by
some buffering issues/race condition related to sman?

This can be workaround by adding a few "--" lines by
htex2input.awk.

> For me titles of pictures are too small, in bitmapped version
> title letters are of comparable size to text letters, in .ps
> version are smaller and almost unreadable when text has comfortable
> size.

Yes, the old image is 300x300 while now is 400x400.
Also there is only one font size.

In the following patch I make the title font size different
from the axes label font and units font.

https://github.com/oldk1331/fricas/commit/103c0c04de8d6e1d38524a6d5aa2e4ee92742b0a.patch

> I also noticed problem which has nothing to do with the patch:
> in 5.4.5 there is an example computing 100!. In HyperDoc
> number appears fine, but in the .pdf it is truncated.

Yeah, it would be hard to handle this automatically.
Solve this by introducing a new latex package to line
break long numbers?

> In slightly different spirit: book convention of having separate
> page numbers in "front matter" and in main part IMO is misguided
> in .pdf: viewer allows navigation by page number, but number on
> pages and numbers in viewer frequently diverge. IMO it would be
> good to adopt uniform numbering.

Some pdf readers can handle this difference in page numbering.

> Also, maybe print full section
> number in the page header, that is 5.4.5 instad of current 5.4.

Well, even pages show chapter number, odd pages show section number,
leaves no space to show subsection number. Also some subsection
names are very long.

>> Also after this patch, src/doc/ps/arrowr.ps SEGBIND.ps knot3.ps
>> ribbon2r.ps ribbons2.ps ribbons2b.ps can be removed, saves 1.3MB
>> and 81123 lines from repo.
>>
>> https://github.com/oldk1331/fricas/commit/46b2e034148674eb05834d8a642d337b1162b897.patch
>
> I think that they should be removed in the same commit as your
> patch (when it goes in).

Sure.

- Qian

[Qian Yun]

On 4/26/24 18:23, Qian Yun wrote:
>
>
> On 4/26/24 06:00, Waldek Hebisch wrote:
>>
>> There is some problem with this.  On my machine I got faulty
>> 'TEXTFILE.tex', it contained '\begin{noOutputXtc}' but no
>> matching end part, causing documentaion build failure.
>
> This does not always happen, and sometimes happen to other
> tmp/*tex file.  The problem is that this TeX file missing
> a few last lines.
>
> This commit changes the processing of input->spool->tex from
> interpsys to fricas (with sman).  So I guess it is caused by
> some buffering issues/race condition related to sman?
>
> This can be workaround by adding a few "--" lines by
> htex2input.awk.
>

More findings:

It seems that I can't reproduce this "missing final lines"
problem in single process environment.

So it seems like this doesn't happen when building book
with "make -j1".

Anyway, the attached patch make the generation of
input->spool->tex to use XVFB+sman only when needed.

Now I tested build with multiple processes many times
and encounter no failure.

- Qian

[Ralf Hemmecke]

Qian,

I assume that your patches are the same as your new-ps-book branch.
I somehow liked your idea for the "stamp-pics" target.
Currently, I am going slowly through the documentation and found a
number of bugs. See my branch
https://github.com/hemmecke/fricas/tree/wip/fricas-book.
(DANGER! I will freely rebase that on top of "master")
I'm not yet that far to include all you stuff of the ps generation.
As you see, I still have some old remnants of your old patches from your
ps-book branch. Maybe with your recent commits to master, some of them
could be removed from my branch.

Sorry that I am so slow, but I am working on it.

Ralf

[Qian Yun]

I have committed all related patches, the patch in this thread is
the last one.

I have updated it a little bit to improve the build process and
fixed the pictures in section 10.5.

https://github.com/oldk1331/fricas/commit/e34fadc066ee34b4b6a56ceadfa3284934166999

So your changes should be based on master branch from now on.

But before I commit this patch, I really would like to see
you to commit
https://github.com/hemmecke/fricas/commit/d460657632ce3fb9f8b9ea83112642ba59a9e3a9

and

https://github.com/hemmecke/fricas/commit/32a50eeb2c762e4df3b42c5f0f9cb38aa4f2a811

first. These "noOutputXtc" patches.


I'm more familiar with these related areas and I'm confident
these changes are good to go.

- Qian

[Ralf Hemmecke]

Hi Qian,

I can try your patch only tonight. For my two patches, I think I can
commit them. Will also do tonight.

I have detected a few more docfixes while I go through the sources, and
things are not that easy whent it comes to generating the .input files
from the data in the book.

Compare

https://github.com/fricas/fricas/blob/master/src/input/images2.input

with

https://github.com/fricas/fricas/blob/master/src/doc/htex/ug21.htex#L79

Yes, vectors.input and cdraw.input are similar, but not identical.

However, OK, I agree, that your .ps generation patches might go in
before the generation of .input from ug*.htex (even though all that is
not urgent). Give me one or two days.

Ralf

[Ralf Hemmecke]

Qian,

I just compiled your new-ps-book branch
https://github.com/oldk1331/fricas/commit

https://github.com/oldk1331/fricas/commit/e34fadc066ee34b4b6a56ceadfa3284934166999

It leave one process hanging and thus does not finish. I must
investigate, but have no time now. Will try more as soon as possible.

The process was a spadclient that ran with 100% CPU.

Ralf

[Qian Yun]

That's probably caused by tmp/ug07.input.

It doesn't hang here, but I do find that there are remaining processes
like viewman and view3D.

The problem is that there are multiple unclosed viewports.

The following fixup patch should solve that: by adding 5 images to
the book (section 7.1.9 and 7.1.10) and using "nullXtc" to
disable viewport creation in section 7.2.4 and 7.2.5.

https://github.com/oldk1331/fricas/commit/32716305e0e00ce1499e1d578092502e42badbf5


So I think that "nullXtc" should not be removed.
It is useful for the cases that we show the command into the book,
but do not actually execute it.

- Qian

[Ralf Hemmecke]

> So I think that "nullXtc" should not be removed.
> It is useful for the cases that we show the command into the book,
> but do not actually execute it.

OK, then finally, there is a good semantics for \nullXtc.
I'll document that later.
When I started recreating the build procedure for the book, I had to
"invent" some semantics and was probably a bit careless.

You asked me previously to commit the "remove nullXtc" patch. I was
already a bit reluctant there, because I have not yet checked whether it
had an influence on the HyperDoc side of the documentation creation.

Anyway, by building with -j1 I got your branch compiled with a view3D
still running with 100% cpu usage after the build had successfully finished.

Looking at the book is a pleasure now. Qian, you really did a great job.
Some pictures look even better than in the printed version of the
original Jenks&Sutor book.

I think I can savely upstream

https://github.com/hemmecke/fricas/commit/d460657632ce3fb9f8b9ea83112642ba59a9e3a9

and then please recheck that there will be no hanging view3D (and
friends) in your patch. I would like to test it again before you commit.

Ralf

[Qian Yun]

On 5/4/24 22:01, Ralf Hemmecke wrote:
>
> Anyway, by building with -j1 I got your branch compiled with a view3D
> still running with 100% cpu usage after the build had successfully
> finished.

I've never met this before.

> Looking at the book is a pleasure now. Qian, you really did a great job.
> Some pictures look even better than in the printed version of the
> original Jenks&Sutor book.
>
> I think I can savely upstream
>
> https://github.com/hemmecke/fricas/commit/d460657632ce3fb9f8b9ea83112642ba59a9e3a9
>
> and then please recheck that there will be no hanging view3D (and
> friends) in your patch. I would like to test it again before you commit.
>
> Ralf
>

I've rebased https://github.com/oldk1331/fricas/commits/new-ps-book/
to
https://github.com/oldk1331/fricas/commit/7102a38052a58de2ac5dba33ec9ccb13b8981798

Please try this with a fresh build. There should be no more problems.

- Qian

[Waldek Hebisch]

On Sat, May 04, 2024 at 11:13:14PM +0800, Qian Yun wrote:
>
> On 5/4/24 22:01, Ralf Hemmecke wrote:
> >
> > Anyway, by building with -j1 I got your branch compiled with a view3D
> > still running with 100% cpu usage after the build had successfully
> > finished.
>
> I've never met this before.

I have written about it in messsage titled "Races in graphics".
This is not a new thing and core reason is not due to your patch.
Simply, your patch affects timing and _maybe_ increased probabilty
of this happening. Or maybe the hang is just bad luck.

This 100% cpu usage is principle should be not very hard to
eliminate, but involves some tedious work. And before doing
this work it would be good to know what Wayland folks are going to
break.

--
Waldek Hebisch

[Grégory Vanuxem]

Hi,

I just built the book cloning the new-ps-book branch, very good job,
thanks to all !

I regularly use to look at he book.pdf, the one downloadable from
github.io but I gave it a try to build it, I hadn't built it for more
than 10 years, so I did it with a newbie spirit in mind.

./configure && make

After I tried
make book
make book.pdf
without success. But since _I_ know that to build html doc I need to
switch to src/doc, I switched to src/doc and issued again make book,
make book.pdf and he build stopped with:
=========================================
┌──(greg㉿ellipse)-[~/Tmp/fricas]
└─$ make book.pdf
make: *** Aucune règle pour fabriquer la cible « book.pdf ». Arrêt.

┌──(greg㉿ellipse)-[~/Tmp/fricas]
└─$ ls
build config confignotes.tex contrib
INSTALL LICENSE.txt README.rst
build-setup.sh config_cl.out config.status doc
INSTALL.CYGWIN Makefile src
ChangeLog config.lisp configure FAQ
lastBuildDate Makefile.in stamp-rootdirs
CHANGELOG.old config.log configure.ac generate_INSTALL.sh
license Makenotes.tex target

┌──(greg㉿ellipse)-[~/Tmp/fricas]
└─$ cd src/doc/

┌──(greg㉿ellipse)-[~/Tmp/fricas/src/doc]
└─$ make book
make: *** Aucune règle pour fabriquer la cible « book ». Arrêt.

┌──(greg㉿ellipse)-[~/Tmp/fricas/src/doc]
└─$ make book.pdf

grep '\(\\head{\|\\psXtc\|\xtc\|\\noOutputXtc\|\\nullXtc\|epsffile\|\\spadgraph\)'

/home/greg/Tmp/fricas/src/doc/htex/ug*.htex \
| mawk -f /home/greg/Tmp/fricas/src/doc/ugepsf.awk > pics.mk
(unset DAASE; FRICAS=/home/greg/Tmp/fricas/target/x86_64-linux-gnu;
export FRICAS; \
FRICAS_INITFILE='' \
/home/greg/Tmp/fricas/target/x86_64-linux-gnu/bin/fricas -noht
-noclef -eval ')read /home/greg/Tmp/fricas/src/input/mobius.input')
Checking for foreign routines
FRICAS="/home/greg/Tmp/fricas/target/x86_64-linux-gnu"
spad-lib="/home/greg/Tmp/fricas/target/x86_64-linux-gnu/lib/libspad.so"
foreign routines found
openServer result 0
FriCAS Computer Algebra System
Version: FriCAS 2024-04-15 built with sbcl 2.4.4
Timestamp: sam. 04 mai 2024 17:43:10 CEST
-----------------------------------------------------------------------------
Issue )copyright to view copyright notices.
Issue )summary for a summary of useful system commands.
Issue )quit to leave FriCAS and return to shell.
-----------------------------------------------------------------------------

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

Compiling function %C with type (DoubleFloat, DoubleFloat) ->
DoubleFloat
Compiling function %E with type (DoubleFloat, DoubleFloat) ->
DoubleFloat
Compiling function %G with type (DoubleFloat, DoubleFloat) ->
DoubleFloat
Transmitting data...

BadMatch (invalid parameter attributes)
reading: integer: Connection reset by peer
session: fatal, got out of sync with Spad server
(lost race)
mkdir -p /home/greg/Tmp/fricas/target/x86_64-linux-gnu/share/viewports
cp -r *.VIEW /home/greg/Tmp/fricas/target/x86_64-linux-gnu/share/viewports
echo timestamp > viewports
cp /home/greg/Tmp/fricas/src/doc/ps/exit.ps exit.ps
cp /home/greg/Tmp/fricas/src/doc/ps/help.ps help.ps
cp /home/greg/Tmp/fricas/src/doc/ps/home.ps home.ps
cp /home/greg/Tmp/fricas/src/doc/ps/up.ps up.ps
cp /home/greg/Tmp/fricas/src/doc/ps/ribbon2r.ps ribbon2r.ps
cp /home/greg/Tmp/fricas/src/doc/ps/ribbons2.ps ribbons2.ps
cp /home/greg/Tmp/fricas/src/doc/ps/ribbons2b.ps ribbons2b.ps
cp /home/greg/Tmp/fricas/src/doc/ps/2Dctrl.ps 2Dctrl.ps
cp /home/greg/Tmp/fricas/src/doc/ps/3Dctrl.ps 3Dctrl.ps
cp /home/greg/Tmp/fricas/src/doc/ps/SEGBIND.ps SEGBIND.ps
cp /home/greg/Tmp/fricas/src/doc/ps/arrowr.ps arrowr.ps
cp /home/greg/Tmp/fricas/src/doc/ps/knot3.ps knot3.ps
cp /home/greg/Tmp/fricas/src/doc/ps/h-alldoms.ps h-alldoms.ps
cp /home/greg/Tmp/fricas/src/doc/ps/h-allrank.ps h-allrank.ps
cp /home/greg/Tmp/fricas/src/doc/ps/h-atsearch.ps h-atsearch.ps
cp /home/greg/Tmp/fricas/src/doc/ps/h-brfront.ps h-brfront.ps
cp /home/greg/Tmp/fricas/src/doc/ps/h-comsearch.ps h-comsearch.ps
cp /home/greg/Tmp/fricas/src/doc/ps/h-consearch.ps h-consearch.ps
cp /home/greg/Tmp/fricas/src/doc/ps/h-docsearch.ps h-docsearch.ps
cp /home/greg/Tmp/fricas/src/doc/ps/h-gensearch.ps h-gensearch.ps
cp /home/greg/Tmp/fricas/src/doc/ps/h-matargs.ps h-matargs.ps
cp /home/greg/Tmp/fricas/src/doc/ps/h-matats.ps h-matats.ps
cp /home/greg/Tmp/fricas/src/doc/ps/h-matdesc.ps h-matdesc.ps
cp /home/greg/Tmp/fricas/src/doc/ps/h-matexamp.ps h-matexamp.ps
cp /home/greg/Tmp/fricas/src/doc/ps/h-matexports.ps h-matexports.ps
cp /home/greg/Tmp/fricas/src/doc/ps/h-matimp.ps h-matimp.ps
cp /home/greg/Tmp/fricas/src/doc/ps/h-matinv.ps h-matinv.ps
cp /home/greg/Tmp/fricas/src/doc/ps/h-matmap.ps h-matmap.ps
cp /home/greg/Tmp/fricas/src/doc/ps/h-matops.ps h-matops.ps
cp /home/greg/Tmp/fricas/src/doc/ps/h-matpage.ps h-matpage.ps
cp /home/greg/Tmp/fricas/src/doc/ps/h-matrelops.ps h-matrelops.ps
cp /home/greg/Tmp/fricas/src/doc/ps/h-matrixops.ps h-matrixops.ps
cp /home/greg/Tmp/fricas/src/doc/ps/h-matsource.ps h-matsource.ps
cp /home/greg/Tmp/fricas/src/doc/ps/h-matxref.ps h-matxref.ps
cp /home/greg/Tmp/fricas/src/doc/ps/h-root.ps h-root.ps
make -f pics.mk pics
make[1] : on entre dans le répertoire « /home/greg/Tmp/fricas/src/doc »
make[1]: *** Aucune règle pour fabriquer la cible «
ugNewIntroGraphicsPage1.VIEW/image.xpm », nécessaire pour «
bessintr.ps ». Arrêt.
make[1] : on quitte le répertoire « /home/greg/Tmp/fricas/src/doc »
make: *** [Makefile:858 : stamp-pics] Erreur 2

┌──(greg㉿ellipse)-[~/Tmp/fricas/src/doc]
└─$ cd ../..
=================================================

But I remember having read somewhere viewports will not be build (I
use WSL2 so I never tried xvfb), the only thing I have
fleetingly sawn is:

configure: HyperDoc graphics must be built separately.
configure: WARNING: Aldor interface will not be built.

So at the root source tree I issued a 'make viewports' with success,
only those messages:

Warning: could not get the 9x15 font for messageFont
Warning: could not get the 8x13 font for buttonFont
Warning: could not get the 9x15 font for headerFont
Warning: could not get the 9x15 font for titleFont
Warning: could not get the 9x15 font for graphFont
Warning: could not get the 6x10 font for unitFont

Missing fonts.

I re-switched to src/doc, issued a 'make book.pdf' and, after
temporarily installing tensor.sty with 'apt-get install
texlive-science' I was able to obtain an up to date book. Good!

So my notes would be maybe to add at the end of the./configure step,
as it's usual, a displayed message related to:

configure: HyperDoc graphics must be built separately.
configure: WARNING: Aldor interface will not be built.

and building viewports and eventually how to build book.pdf.

Remember, I did this with a newbie spirit in mind.

Nevertheless, very nice! Thanks all again!

> --
> 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/dc45d2c3-2352-4d62-bcd6-d2bfeb817b17%40hemmecke.org.

[Grégory Vanuxem]

Just a question, I used to prefer pdflatex over latex/dvips in the
past (for links and other addons), and at the end of the book build I
saw:
ps2pdf book.ps

Why are you not using pdflatex? Because of .ps image?

[Ralf Hemmecke]

> Why are you not using pdflatex? Because of .ps image?

Initially, I had to use just latex. The pictures would not work nicely
with pdflatex.

pdflatex is the goal, Just wait a little. I also want to see hyperlinks.
(In fact, I rather dream of the book in html format.)

Ralf

[Ralf Hemmecke]

> After I tried
> make book
> make book.pdf
> without success. But since _I_ know that to build html doc I need to
> switch to src/doc, I switched to src/doc and issued again make book,

Not only *you* know. It is even properly documented. ;-)

http://fricas.github.io/install.html#build-extra-documentation-book-and-website

But you are right, at some point, we should add a "book.pdf" target to
the top-level Makefile.

> But I remember having read somewhere viewports will not be build (I
> use WSL2 so I never tried xvfb)

I am not sure, but I would bet that xvfb allows to build without X. So
it should work under WSL2. Sorry, that is just a guess.

> I re-switched to src/doc, issued a 'make book.pdf' and, after
> temporarily installing tensor.sty with 'apt-get install
> texlive-science' I was able to obtain an up to date book. Good!

Cool! So that was on WSL2?

> So my notes would be maybe to add at the end of the./configure step,
> as it's usual, a displayed message related to:
>
> configure: HyperDoc graphics must be built separately.
> configure: WARNING: Aldor interface will not be built.
>
> and building viewports and eventually how to build book.pdf.
>
> Remember, I did this with a newbie spirit in mind.

The newbie spirit is good. We need more of this kind.

But since the generation is not important for people that are not
familiar with building things (we provide it on github anyway), I think
it is enough to have the build-instruction on the website (url above).

Ralf> After I tried

> make book
> make book.pdf
> without success. But since _I_ know that to build html doc I need to
> switch to src/doc, I switched to src/doc and issued again make book,

Not only *you* know. It is even properly documented. ;-)

http://fricas.github.io/install.html#build-extra-documentation-book-and-website

But you are right, at some point, we should add a "book.pdf" target to
the top-level Makefile.

> But I remember having read somewhere viewports will not be build (I
> use WSL2 so I never tried xvfb)

I am not sure, but I would bet that xvfb allows to build without X. So
it should work under WSL2. Sorry, that is just a guess.

> I re-switched to src/doc, issued a 'make book.pdf' and, after
> temporarily installing tensor.sty with 'apt-get install
> texlive-science' I was able to obtain an up to date book. Good!

Cool! So that was on WSL2?

> So my notes would be maybe to add at the end of the./configure step,
> as it's usual, a displayed message related to:
>
> configure: HyperDoc graphics must be built separately.
> configure: WARNING: Aldor interface will not be built.
>
> and building viewports and eventually how to build book.pdf.
>
> Remember, I did this with a newbie spirit in mind.

The newbie spirit is good. We need more of this kind.

But since the generation is not important for people that are not
familiar with building things (we provide it on github anyway), I think
it is enough to have the build-instruction on the website (url above).

Ralf

[Ralf Hemmecke]

Qian,

you should also replace epsf by graphicx in
src/doc/sphinx/source/install.rst.

In fact, any traces of ImageMagick (Makefile.in and install.rst) should
be remove.

Ralf

[Qian Yun]

On 5/5/24 00:09, Waldek Hebisch wrote:
> On Sat, May 04, 2024 at 11:13:14PM +0800, Qian Yun wrote:
>>
>> On 5/4/24 22:01, Ralf Hemmecke wrote:
>>>
>>> Anyway, by building with -j1 I got your branch compiled with a view3D
>>> still running with 100% cpu usage after the build had successfully
>>> finished.
>>
>> I've never met this before.
>
> I have written about it in messsage titled "Races in graphics".

I can't find this message. Is this the recent reply to
"remove sleep to speed up draw" thread or an older mail?

> This is not a new thing and core reason is not due to your patch.
> Simply, your patch affects timing and _maybe_ increased probabilty
> of this happening. Or maybe the hang is just bad luck.
>
> This 100% cpu usage is principle should be not very hard to
> eliminate, but involves some tedious work. And before doing
> this work it would be good to know what Wayland folks are going to
> break.
>

Regarding wayland, I believe XWayland will continue to provide
compatibility. I've being using wayland for a long time and
hit no problems so far.

- Qian

[Waldek Hebisch]

On Sun, May 05, 2024 at 09:55:38PM +0800, Qian Yun wrote:
>
>
> On 5/5/24 00:09, Waldek Hebisch wrote:
> > On Sat, May 04, 2024 at 11:13:14PM +0800, Qian Yun wrote:
> > >
> > > On 5/4/24 22:01, Ralf Hemmecke wrote:
> > > >
> > > > Anyway, by building with -j1 I got your branch compiled with a view3D
> > > > still running with 100% cpu usage after the build had successfully
> > > > finished.
> > >
> > > I've never met this before.
> >
> > I have written about it in messsage titled "Races in graphics".
>
> I can't find this message. Is this the recent reply to
> "remove sleep to speed up draw" thread or an older mail?

For some reason it did not get to the list, I have re-sent it.

> > This is not a new thing and core reason is not due to your patch.
> > Simply, your patch affects timing and _maybe_ increased probabilty
> > of this happening. Or maybe the hang is just bad luck.
> >
> > This 100% cpu usage is principle should be not very hard to
> > eliminate, but involves some tedious work. And before doing
> > this work it would be good to know what Wayland folks are going to
> > break.
> >
>
> Regarding wayland, I believe XWayland will continue to provide
> compatibility. I've being using wayland for a long time and
> hit no problems so far.

Common sense says that there should be good compatiblity for many
years. But new "cool" trend is to break things, so I am not
sure. IIUC 'xnest' is incombatible with Wayland. 'xvfb' seem to
be derivative of 'xnest' so that potentially may be broken
(more precisely, if/when 'xnest' is broken IMO there is risk that
'xvfb' will be no longer updated and may bitrot).

One possible way to improve our graphics is to use Xt. Xt is basic
X11 toolkit (some other toolkits are built on top of Xt). But,
it is not clear how long Xt will be maintained. Note: I do not
think there is worry in the next few years. However, we are
using code that is 30 years old and preferably improved code
should live longer.

--
Waldek Hebisch