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.