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.

[Ralf Hemmecke]

Hello...

Kurt and me worked on the Jupyter-FriCAS bridge again and now I have
something working.

It basically includes Waldek's proposed change to webspad.lisp, but we
decided that we should rather aim at ending the python package on
pypi.org and instead distribute jfricas together with FriCAS.

Our current proposal is at my git repository in the branch "wip/jfricas"

https://github.com/hemmecke/fricas/tree/wip/jfricas

This is still work in progress (I still need to clean up a few things),
but should already work fine.

Installation description is at

https://hemmecke.github.io/fricas/install.html#install-jfricas

Let me say something about the proposed changes.
It consists of two parts.
(1) a few minor changes to boot files and some others
(2) jfricas.spad

ad (1):
These changes mostly are concerned with ioHook.
* Correct "endSysCmd" --> "endOfSysCmd",
"endPatternMsg" --> "endOfPatternMsg",
to be more uniform with other ioHooks.
* Introduce startType/endOfType, startTime/endOfTime,
startStorage/endOfStorage.

ad (2)
To prepare for future changes I included the functions that were
formerly in webspad.lisp and fricaskernel.py into jfricas.spad.
As the installation guide tells you there is still need to write out a
(smaller) fricaskernel.py out and make it available to jupyter in order
to actually start FriCAS. Some of the python code now also lives as spad
functions.

The first commit in my branch just concerns (1) with basically the
original (from jfricas 2.0) fricaskernel.py file generated from
jfricas.spad.
The other commits are intermediate steps towards moving more code into
spad form.

Depending on when the next release will happen, I may propose only the
first commit. However, both Kurt and me would like to distribute jfricas
together with FriCAS so that there is no question about potential
incompatibilities between FriCAS and jFriCAS versions.

Note that jfricas does (on purpose) not appear in configure.ac nor in
any Makefile, since it's supposed to be an optional add-on.

Please test and comment.

Waldek, I hope that just providing jfricas.spad is minimal invasive
enough to include it into the official FriCAS repository.

Ralf