It's easier than I originally thought. In fact, I have almost
moved the whole socket communication into Lisp (viewman works,
hyperdoc partly works), making "sman" and "session" redundant.
https://github.com/oldk1331/fricas/commits/newserver/
(Code is in very very early stage, if you really want to
run it, apply the patches to 1.3.11-full release tarball,
and "export NEWSERVER=1".)
This is concrete proof of concept that this idea really works.
- Qian
On 10/19/24 5:14 PM, Qian Yun wrote:
I've uploaded a very early draft to illustrate my points.
(No error handling, no buffer overflow detection,
interface not refined.)
https://github.com/oldk1331/fricas/tree/newserver
In fact, this is already kind of have enough functionality to support
jfricas! Because jfricas is a single client connected to FriCAS,
and no hypertex or graphics needed, so no IO multiplex needed.
Currently, simply connect to the unix domain socket and you
can do REPL! It should also need only a few lines of python
to connect to this NEW SpadServer. No need for hunchentoot.
Should greatly simplifies the packaging of jfricas,
thus it should attract more users.
You can test my code by:
start fricas and type ")boot $NEWSERVER := true" to enable the
new server.
In another terminal, in build directory, use the following to
connect to FriCAS:
export SPADNUM=`ls /tmp/.s* | cut -d 's' -f 2`; echo $SPADNUM;
export NEWSERVER=1; ./target/x86_64-linux-gnu/lib/spadclient
- Qian
On 10/19/24 2:37 PM, 'Ralf Hemmecke' via FriCAS - computer algebra
system wrote:
Qian,
I do not understand all this stuff, but it somehow sounds as if it
might have influence on the connection that I use in jfricas. I
remember you have an eye on this. Can you confirm?
Thank you
Ralf
To clarify things up:
1. Currently we have stuff like "(PRINC STR *standard-output*)".
2. The above propose is like "(PRINC STR *spad-output*)" where
*spad-output* is bound to a socket-stream and can be switched
at runtime.
3. The following propose uses "(SPRINC STR *spad-output*)",
where SPRINC can do ")spool", and use FFI to print to
*spad-output*, which might be a socket file descriptor.
The usocket Lisp library does not support unix domian socket,
also this higher abstraction differs from our current idiom.
I plan to use the FFI for C functions instead. (Add new
wrappers for "select", "accept", etc.)
Very preliminary tests show that this approach is workable.
Also with this redesigned architecture, it would be very
easy for SageMath to communicate with FriCAS through socket.
This method should be more stable and support more Lisps
than the call-lisp-from-c method.
- 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/a7c06bd8-8ffe-4094-923a-6dc84e7f5e23%40gmail.com.
