fricas-jfricas connection is broken

[Ralf Hemmecke]

Commit 87515e1d1aa303d0313cf044a1fc57ed831899cb broke the connection to
jfricas. :-(

An it is still broken in the current master
e58544d3888f591f73434c1a256e1e895c14e781.

Cannot that be tested before it goes into the official repo?
I thought that is the rule to only commit tested stuff to the
repository. :-(

I am busy with other work and cannot quickly look into it.
So it must wait.

Ralf

[Waldek Hebisch]

jfricas needs a lot of Python machinery which I do not have. So
as a whole is untestable for me. Normally this should be no
problem as we test that visible stuff in FriCAS works as before.
But AFAICS 'webspad.lisp' hooks into various internal Lisp
functions.

Let me add that I plan large restructuring for next release.
This inevitably leads to some regressions. Doing such
changes slowly would spread regressions over long time.
Instead my idea is to do changes relatively quickly and
then have some time to catch remaing troubles.

Looking at '|webspad-parseAndEvalStr|' I see '$fortranFormat'
'$htmlFormat' and '$openMathFormat', those are gone now.
The change is part of moving output machinery to Spad, jfricas
should use Spad level functions for such things.

In general, any Boot/Lisp level stuff may go away whithout
special notice unless it is known to be there for use
by interfaces or external code.

BTW, for HyperDoc I have (still not commited) stuff like:

$do_page_fun1_fun := [0, nil]

do_page_fun1(page, tag, data) ==
fun := SpadFun($do_page_fun1_fun,
getFunctionFromDomain1("do_page_fun1", ["HyperdocTopPage"],
$Void, [["HyperdocPage"], ["Symbol"], ["SExpression"]]))
SPADCALL(page, tag, data, fun)

dbChooseDomainOp(page, data) == do_page_fun1(page, 'dbChooseDomainOp, data)

and in HyperdocTopPage:

do_page_fun1(page : HyperdocPage, tag : Symbol,
data : SE) : Void ==
tag = 'cons_opts => cons_opts(page, symbol(data))
tag = 'dbChooseDomainOp => choose_domain_op(page, integer(data))
tag = 'dbSelectCon => select_con(page, data)
....

That way communication protocol is that same as in old code, but
Boot/Lisp part is only doing trivial forwarding to Spad.

--
Waldek Hebisch

[Waldek Hebisch]

On Sat, Mar 21, 2026 at 08:54:06PM +0100, 'Ralf Hemmecke' via FriCAS - computer algebra system wrote:

> Commit 87515e1d1aa303d0313cf044a1fc57ed831899cb broke the connection to
> jfricas. :-(

Just one more things. Instead of old output strams we have now
(in i-output.boot):

-- Below we emulate records using vectors and offsets
-- Record describing current state of an output stream
-- Should be
-- Record(stream : File, file : String, on : Boolean)
DEFCONST($stream_off, 0)
DEFCONST($file_off, 1)
DEFCONST($on_off, 2)

$algebra_out_rec := GETREFV(3)
$fortran_out_rec := GETREFV(3)
$mathml_out_rec := GETREFV(3)
...

This is transitional thing, before moving it to Spad. ATM needed
manipulations of streams should be done in terms of those.

Better, specify what needed functions should do, then we can add
such functions with tests.

--
Waldek Hebisch

[Waldek Hebisch]

On Sat, Mar 21, 2026 at 08:54:06PM +0100, 'Ralf Hemmecke' via FriCAS - computer algebra system wrote:

Attached is a version of "webspad.lisp" that has some chance of
working with current FriCAS.

As I wrote I do not have Python stuff, so I can not test full
thing. But a simple test like:

)lisp (webspad::webspad-eval "1 + 1")

seem to give sensible result.

Note: some output format mainly go to files. Disabling them or
redirecting to notebook arguably is wrong. The version in
attachement captures what would go to console, but does not
affect output to files.

If you want to discard Fortran output going to console you
can add apropriate markers. But IIUC other interfaces work
differenty: they discard things except for those which they
want, so for them it is enough to have markers for
"interesting" stuff.

--
Waldek Hebisch

[Waldek Hebisch]

Forgot to attach file to previous mail, doing it now.
--
Waldek Hebisch

[Kurt Pagani]

Hi Waldek

Thanks. You don't need Python to test -- a browser is sufficient:


fricas -nosman

)lisp (load "/home/kfp/Desktop/webspad_n.lisp")
)lisp (webspad::start 8080 "localhost")

Value = #<HUNCHENTOOT:EASY-ACCEPTOR (host localhost, port 8080)>


Test with browser (lnyx, firefox ...):

lynx localhost:8080

When you're reading this message, Hunchentoot has been properly
installed.

Please read the documentation.

[made-with-lisp-logo.jpg]


EVAL (simple)
----
lynx localhost:8080/eval?code="D(x^n,x,6)"


JSON
----
lynx localhost:8080/json?code="D(x^n,x,6)"


Looks good so far, however, Ralf has to test it thoroughly, of course.
Moreover I have built fricas with hsbcl, so I don't know for sure
whether webspad_n has overwritten the already contained
webspad::functions correctly.