[PATCH] simplify sending a block from hypertex

[Qian Yun]

Simplify the logic when sending a "Spadsrc" block
from hypertex to FRICASsys.

Use "interpret_block" instead of writing a temporary file.

- Qian

[Waldek Hebisch]

In general it looks good. However, there are some issues. First,
'escape_string' in general does not work (except when using GCL).
You can see the problem trying HyperDoc Browse on '/\'. I get:

>> System error:
:UTF-8 c-string decoding error: the octet sequence #(128) cannot be decoded.

This happens because 'escape_string' replaces backslash with byte
128. Such byte is legal in 8-bit encoding and unlikely to conflict
with any user character, but sbcl uses UTF-8 and rejects it as
such byte can not appear as part of valid UFT-8 sequence. Note
that files are free from this problem, because there is no need
for escaping in such case.

Backslashes are rare in FriCAS sources, but I am reluctant to increase
use of 'escape_string' before. Somewhat related is that debugging
problems with build of HyperDoc pages is rather nasty.

Minor issue is that I trying to have uniform style for new Boot
code. First, 4 char indent. Generous use of spaces, that is
after commas, around ':' in declarations. Function arguments
in parenthesis. 'if ... then ... else ...' formated as

if ... then
...
else
...

To ease comparisons with original code I do not reformat otherwise
unmodified code and typically keep existing indentation when
modifying part of a function. But I would like to have new
formatting for new parts, even if they copy part of old code
(once code is in new place it will show in diffs as changed
so we can reformat it).

--
Waldek Hebisch

[Qian Yun]

Can we have proper escape then?

Common Lisp string literal only treat " and \ as special char
needing escape.

Can we do the proper escape at C level? (With proper memory
management of course.)

- Qian

[Waldek Hebisch]

On Tue, Aug 11, 2026 at 06:45:40AM +0800, Qian Yun wrote:
> Can we have proper escape then?
>
> Common Lisp string literal only treat " and \ as special char
> needing escape.
>
> Can we do the proper escape at C level? (With proper memory
> management of course.)

There are multiple possible approaches. One is to allow increase
of length due to escaping, then we can produce a string which
after single Lisp evaluation gives original string. Or we
can use 128 encoded in UTF-8 (replacing single byte by 2 bytes).

Alternatively, we could change HyperDoc protocol to send
a sequence of strings instead of a single string. Or maybe
a simpler approach: command identifier (an integer) + string.
Actually, having command identifiers would be desirable for
other reasons.

Whatever is choosen, we need change in Boot/Spad code to match.

I would prefer change to HyperDoc protocol, but that is probably
more work than using malloc. OTOH malloc may behave badly in
presence of our signal handlers. Current C code uses mostly
static allocation and troubles are rare enough (and not easily
reproducible) that I did not hear complaints. But if we make
more use of stateful library calls, then frequency of troubles
may increase.

Just to explain more the last part: Linux at system call level
allows almost arbitrary signal handling. But C standard says
essentially that the only thing which one can do in signal
handler is to set a flag. "Main" program can periodically
look at the flag and react if flag is set. Restriction in
C standard is due to C library, in particular functions like
malloc.

As you can see there are many things in HyperDoc program that
may go wrong. It would be good to fix them, but deeper problems
are not resolvable by incremental changes. For example, modifying
signal handler to just set a flag is easy. But finding right
places in which to test the flag requires more work and affects
the whole program.

> On 8/11/26 1:05 AM, Waldek Hebisch wrote:
> > On Mon, Aug 10, 2026 at 10:07:32PM +0800, Qian Yun wrote:
> >> Simplify the logic when sending a "Spadsrc" block
> >> from hypertex to FRICASsys.
> >>
> >> Use "interpret_block" instead of writing a temporary file.
> >
> > In general it looks good. However, there are some issues. First,
> > 'escape_string' in general does not work (except when using GCL).
> > You can see the problem trying HyperDoc Browse on '/\'. I get:
> >
> > >> System error:
> > :UTF-8 c-string decoding error: the octet sequence #(128) cannot be decoded.
> >
> > This happens because 'escape_string' replaces backslash with byte
> > 128. Such byte is legal in 8-bit encoding and unlikely to conflict
> > with any user character, but sbcl uses UTF-8 and rejects it as
> > such byte can not appear as part of valid UFT-8 sequence. Note
> > that files are free from this problem, because there is no need
> > for escaping in such case.
> >
> > Backslashes are rare in FriCAS sources, but I am reluctant to increase
> > use of 'escape_string' before. Somewhat related is that debugging
> > problems with build of HyperDoc pages is rather nasty.
> >
>

> --
> 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 visit https://groups.google.com/d/msgid/fricas-devel/714b2aad-9e67-48ba-9947-1e4730a9cd19%40gmail.com.

--
Waldek Hebisch

[Qian Yun]

OK, for a simpler solution/hack, let's change the \200 char
with \037 (unit separator), how about that?

- Qian

[Waldek Hebisch]

On Tue, Aug 11, 2026 at 08:43:33AM +0800, Qian Yun wrote:
> OK, for a simpler solution/hack, let's change the \200 char
> with \037 (unit separator), how about that?

That looks reasonable. We need to check that readers in Lisp-s
that we use preserve this character (and that our code does not
use it for other purpose), but hopefully this holds.

> To view this discussion visit https://groups.google.com/d/msgid/fricas-devel/9a8c3370-6757-4286-abdd-af8304577f7c%40gmail.com.

--
Waldek Hebisch