Status of jFriCAS

[Grégory Vanuxem]

Hello Ralf, *,

May I ask here the status of jFriCAS since the recent changes in the FriCAS codebase?

Is it still usable?

Regards,

Greg

[Ralf Hemmecke]

Waldek has given a version that worked for him,

https://groups.google.com/g/fricas-devel/c/sTWdp7tkfcs/m/U9on7GVcAQAJ

Kurt has already given me a version that we will probably use for the
new jfricas version, but I did not yet have time to check it and upload
it. I am also not sure whether Waldek still has something in his stack
of patches that will break jfricas again.

Anyway, I still need to look at it.

Ralf

[Grégory Vanuxem]

OK. Yes I know, even if he is rarely here, that Kurt Pagani is working sometimes on this (I worked on webspad for CLozure CL without success so I read the code ;-)).

I will look further on this. 

I any I can try/test, eventually propose some changes if any.

BTW thanks for your response, 

Greg

--
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/45ff653f-79e4-4cf8-a057-35bfecffe3ce%40hemmecke.org.

[Waldek Hebisch]

On Sun, Apr 26, 2026 at 08:00:50PM +0200, 'Ralf Hemmecke' via FriCAS - computer algebra system wrote:
> Waldek has given a version that worked for him,
>
> https://groups.google.com/g/fricas-devel/c/sTWdp7tkfcs/m/U9on7GVcAQAJ
>
> Kurt has already given me a version that we will probably use for the new
> jfricas version, but I did not yet have time to check it and upload it. I am
> also not sure whether Waldek still has something in his stack of patches
> that will break jfricas again.

I would like to move administration of output format and related
streams to Spad code. That will affect jfricas. But I can not
say when this may happen. There are several things that have
higher priority. And I would like to have shorter release cycle,
so there is good chance that there will be a release before
such change.

--
Waldek Hebisch

[Ralf Hemmecke]

Understandable. However, that would mean that I would release a new
jFriCAS that works (for compatibility reasons) with the old streams code
of FriCAS 1.3.13 and the one that exists now. And in a few weeks there
will be another change that make another change to jfricas necessary.
That, of course, needlessly blows up the jFriCAS code with an
intermediate version. So if possible, I would like to avoid code in
jFriCAS that just works for FriCAS 1.3.14 (i.e. current trunk) and is
obsolete in all other versions.

So if your lifting-formatting-to-SPAD could be done before the release,
I would appreciate that very much. Why do you see a pressure to do a
release before that formatting stuff is finished?

Ralf

[Waldek Hebisch]

You think "few weeks", but changes to file handling have potential
delay relase a few months. And the earliest point where other
things are finished is few months from now.

--
Waldek Hebisch

[Ralf Hemmecke]

Hi Waldek, (hi Kurt),

> You think "few weeks", but changes to file handling have potential
> delay relase a few months. And the earliest point where other
> things are finished is few months from now.

Well, it's only a scaling factor of about 4.5. ;-)

Anyway,

30-Jun-2024 1.3.11
03-Jun-2025 1.3.12
05 Mar-2026 1.3.13

why is it so important that 1.3.14 is released before July or before
September? November would also be fine. Who or what presses you?

I don't know how Kurt sees it, but in principle I would be open for
including jfricas with the fricas repo, then we wouldn't have this
versioning compatibility problem I mentioned.

Including and installing jfricas from the fricas repo would certainly
not be a problem, but we must also find a method to put the respective
files into the right place and install jupyter (and friends) from a
binary distribution. Maybe we can at least figure out between you, Kurt
and me, whether this is doable before a new release. (Or whether that is
not in your interest.)

Ralf

[Kurt Pagani]

On 30/04/2026 16:36, 'Ralf Hemmecke' via FriCAS - computer algebra

system wrote:
> On 4/30/26 15:17, Waldek Hebisch wrote:
>> On Sun, Apr 26, 2026 at 08:00:50PM +0200, 'Ralf Hemmecke' via FriCAS -
>> computer algebra system wrote:
>>> Waldek has given a version that worked for him,
>>>
>>> https://groups.google.com/g/fricas-devel/c/sTWdp7tkfcs/m/U9on7GVcAQAJ
>>>
>>> Kurt has already given me a version that we will probably use for the
>>> new
>>> jfricas version, but I did not yet have time to check it and upload
>>> it. I am
>>> also not sure whether Waldek still has something in his stack of patches
>>> that will break jfricas again.
>>
>> I would like to move administration of output format and related
>> streams to Spad code.  That will affect jfricas.  But I can not
>> say when this may happen.  There are several things that have
>> higher priority.  And I would like to have shorter release cycle,
>> so there is good chance that there will be a release before
>> such change.

In principle webspad.lisp could be replaced by a spad 'package' when the
'new code' is conclusive. It also had the advantage that no lisp file
had to be distributed (i.e. only fricaskernel.py).

>
> Understandable. However, that would mean that I would release a new
> jFriCAS that works (for compatibility reasons) with the old streams code
> of FriCAS 1.3.13 and the one that exists now. And in a few weeks there
> will be another change that make another change to jfricas necessary.
> That, of course, needlessly blows up the jFriCAS code with an
> intermediate version. So if possible, I would like to avoid code in
> jFriCAS that just works for FriCAS 1.3.14 (i.e. current trunk) and is
> obsolete in all other versions.

At the moment we use the lisp *feature* list to distinguish the code
change by using the trick

(handler-case (|mkOutputConsoleStream|)
(error (c)
(format t "mkOutputConsoleStream has been removed: ~a~%" c)
(pushnew ':new-webspad *features* :test #'eq) ))

so that #+-new-webspad allows backward compatibility. It would be of
course much simpler when some versioning existed like SVN revision or
so, or if Waldek could set a *feature* when making changes ...

In my version *features* is (:new-webspad is of course only a bad temp
choice):

Value = (:NEW-WEBSPAD :FRICAS_HAS_REMOVE_DIRECTORY :HUNCHENTOOT
:HUNCHENTOOT-NO-SSL :SPLIT-SEQUENCE
:SBCL-DEBUG-PRINT-VARIABLE-ALIST
:CL-FAD :BORDEAUX-THREADS :THREAD-SUPPORT
ALEXANDRIA::SEQUENCE-EMPTYP
:FLEXI-STREAMS :CHUNGA :CL-PPCRE :ASDF3.3 :ASDF3.2 :ASDF3.1 :ASDF3
:ASDF2 :ASDF :OS-UNIX :NON-BASE-CHARS-EXIST-P :ASDF-UNICODE
:X86-64
:GENCGC :64-BIT :ANSI-CL :COMMON-LISP :ELF
:IEEE-FLOATING-POINT :LINUX
:LITTLE-ENDIAN :PACKAGE-LOCAL-NICKNAMES :SB-CORE-COMPRESSION
:SB-LDB
:SB-PACKAGE-LOCKS :SB-THREAD :SB-UNICODE :SBCL :UNIX)


I think it's manageable one way or another. A pure spad solution would
certainly be most favourable.

[Ralf Hemmecke]

Hi Waldek,

I would like to set boot::|$ioHook| from within SPAD. How can I do this?

Suppose I have a function in a package JFriCAS.

foo(x: List String): Void == ...

that I would like to be called whenever FriCAS executes something like

ioHook("startSysCmd", "set")
or
ioHook("startAlgebraOutput").

Can I do it like this?
evalLisp(s) ==> EVAL(READ_-FROM_-STRING(s)$Lisp)$Lisp
evalLisp "(setf boot::|$ioHook|"_
      "  (lambda (x &optional args)"_
      "    (spadcall (cons x args) "_
      "      (|getFunctionFromDomain| _"foo_" '(JFriCAS) "_
      "        '(List String))))"

(I guess, my attempt is not fully correct.)

Would be cool to introduce a function

setIOHook: (List String -> Void) -> Void

so that I would be able to just call setIOHook(foo).

Thanks in advance
Ralf

[Kurt Pagani]

Bin leider kein Frühaufsteher ;-)


On 07/05/2026 08:12, 'Ralf Hemmecke' via FriCAS - computer algebra

system wrote:
> Hi Waldek,
>
> I would like to set boot::|$ioHook| from within SPAD. How can I do this?
>
> Suppose I have a function in a package JFriCAS.
>
>     foo(x: List String): Void == ...
>
> that I would like to be called whenever FriCAS executes something like
>
> ioHook("startSysCmd", "set")
> or
> ioHook("startAlgebraOutput").
>
> Can I do it like this?
> evalLisp(s) ==> EVAL(READ_-FROM_-STRING(s)$Lisp)$Lisp
> evalLisp "(setf boot::|$ioHook|"_
>          "  (lambda (x &optional args)"_
>          "    (spadcall (cons x args) "_
>          "      (|getFunctionFromDomain| _"foo_" '(JFriCAS) "_
>          "        '(List String))))"
>
> (I guess, my attempt is not fully correct.)

Ich dachte an so etwas wie getFunctionFromDomain(func,[dom],[args])$Lisp


p1:=getFunctionFromDomain(prime?,['Integer],['Integer])$Lisp
SPADCALL(3,p1)$Lisp --> T
SPADCALL(4,p1)$Lisp --> ()=NIL

DESCRIBE(p1)$Lisp

Muss mir das genauer ansehen, aber sollte doch möglich sein.

[Waldek Hebisch]

On Thu, May 07, 2026 at 08:12:21AM +0200, 'Ralf Hemmecke' via FriCAS - computer algebra system wrote:
> Hi Waldek,
>
> I would like to set boot::|$ioHook| from within SPAD. How can I do this?

ATM there is no support for defining Lisp-callable functions from
Spad.

> Suppose I have a function in a package JFriCAS.
>
> foo(x: List String): Void == ...
>
> that I would like to be called whenever FriCAS executes something like
>
> ioHook("startSysCmd", "set")
> or
> ioHook("startAlgebraOutput").
>
> Can I do it like this?
> evalLisp(s) ==> EVAL(READ_-FROM_-STRING(s)$Lisp)$Lisp
> evalLisp "(setf boot::|$ioHook|"_
>       "  (lambda (x &optional args)"_
>       "    (spadcall (cons x args) "_
>       "      (|getFunctionFromDomain| _"foo_" '(JFriCAS) "_
>       "        '(List String))))"
>
> (I guess, my attempt is not fully correct.)

There is obvious problem in code above: function is the _last_
argument to SPADCALL. Also, first argument to '$ioHook' is a
symbol. There could be non-obvious troubles here, but I see
no advantage to going via Lisp here, so I will not check this
more.

> Would be cool to introduce a function
>
> setIOHook: (List String -> Void) -> Void
>
> so that I would be able to just call setIOHook(foo).

Normal way is to define such function in boot, like
(untested):

$io_hook_fun := nil

call_spad_io_hook(x, :args) ==
SPADCALL(x, args, $io_hook_fun)

set_spad_io_hook(fun) ==
$io_hook_fun := fun
$ioHook := FUNCTION call_spad_io_hook

fun should have type like '(Symbol, SExpression) -> Void'

Then in Spad you should be able to do:

set_spad_io_hook(fun)$Lisp

--
Waldek Hebisch