On 6/2/24 02:24, Waldek Hebisch wrote:
On Sat, Jun 01, 2024 at 12:56:26PM +0800, oldk1331 wrote:

Hmm... cannot we also have something like this -paste option
for the .ps file generation?

To Ralf:  we can, but we also decided to decouple book generation
with hypertex pages generation.

Well, I am not sure why Ralf wants decoupling, but for me it
is no-goal.  In fact, since at core process is similar it is
natural to reuse as much code as possible.  And reuse already
done computations.  Which means doing what code in FriCAS
wiki is doing: produce both text and LaTeX output in the same
run.

There's \htonly and \texonly, so it has to run twice.


It seems that all discovered issues are resolved now.  It is not
clear to me it is worth splitting disscusion into separate threads.
Concerning splitting patches, I think it would be natural to
commit chages to HyperDoc program and graphics as one piece (assuming
they are compatible with current way of building book) and changes
to FriCAS book and src/doc Makefile as another piece.

I think the HyperDoc patch is relatively independent and should
commit separately, after all it solves Greg's problem.

As for the "file truncation problem", or let's rephrase it as
"sman in pipe problem". (I just noticed it is mentioned in the
"doc/fricas.1" man page.)  One thing I'm still not very sure:
what's the purpose of "wait_for_client_read" in "sread"?
In which context is it useful?  I'm inclined to remove it.

Another thing that I'm more certain: since in session.c
we use "session_socket_mask" instead of "socket_mask",
"sread" ("get_int" etc) can have unexpected side effects,
I need to take a deeper look to see if there's a better solution.

A final problem is, should "sman" restart "viewman" if it exits?
(https://github.com/fricas/fricas/pull/101)
If "viewman" exits normally, "sman" should not restart it,
otherwise "sman" (and the whole session) will not quit to terminal.

I have some small comment to changes that you did in .htex files.
Namely on page 876 subsection 'abbrs' you changed 'limited to 7
characters' into 'limited to 8 characters'.  The exact statement
is that _category_ abbreviations are limited to 7 characters
and domain/package abbreviations can use 8 characters.
I would probably skip 'limited to' part here.

Abbreviations are mentioned in other places and we probably should
put precise statement somewhere, but description of 'Browse' does
not look like good place.  And such change is independent of other
changes that you are making.


Branch rebased and updated.

- Qian

--
You received this message because you are subscribed to the Google Groups "FriCAS - 
computer algebra system" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/d/msgid/fricas-devel/8896f2e4-669e-4454-adb8-dd2b32441bc1%40gmail.com.

Reply via email to