On 19.06.23 09:22, Grégory Vanuxem wrote:
I wonder why you're using such an old LISP?
Waldek wants to make sure that jfricas also works with the sbcl that he
puts into the binary fricas release. In fricas-1.3.8 this was
sbcl-1.1.1. So I presume that I should test 1.1.1.
It seems you have a x64 system, why are you not trying roswell for
your LISP implementation? https://roswell.github.io/
Also a good suggestion.
Look like quicklisp functionality with which I described the jfricas
installation here:
https://hemmecke.github.io/qeta/fricasinstall.html#optional-jfricas-installation
But Waldek wants as a prerequisite an sbcl image that already contains
hunchentoot. I somehow support that since hunchentoot is not really
needed for the fricas functionality, only to make the interface to the
jupyter notebook (jfricas) work. Then ./configure --with-lisp=hsbcl
would compile the right FRICASsys image.
But we can have several scenarios for building from the git repo.
A) user provides hsbcl and uses --with-lisp=hsbcl.
B) like on the above website a few additions to FriCAS makefiles and
a little patch to vmlisp.lisp by using quicklisp to bring
hunchentoot into FRICASsys while compiling it (uses pure sbcl)
C) like (B) replacing quicklisp by roswel.
It seems we will be going the (A) direction.
Using configure parameter --with-lisp='ros run' all will
be done automagically.
Are you sure that this would include hunchentoot into the FRICASsys
image? Kurt and me struggled quite a bit, because FRICASsys would not
know SBCL_HOME and thus not find any otherwise installed hunchentoot if
not explicitly told. That is why hunchentoot should be inside the
FRICASys image.
Ralf
--
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/20e52895-082e-555a-24f4-13f1d3dff3f7%40hemmecke.org.
