FriCAS status

[hebisch]

We have several open bugs and most of things I hoped to do
are not done. However, vast majority of bugs is old (present
in previous versions) and we have fixes for few problems.
So it makes sense to do a new release.

ATM major open thing is inclusion of hunchentoot, I would
prefer to have confirmation that binary that I create works
for jfricas. There is still time for small additions and bug
fixes, but not much: I would like to do release in about two weeks.

--
Waldek Hebisch

[Ralf Hemmecke]

On 13.06.23 22:46, hebisch wrote:
> ATM major open thing is inclusion of hunchentoot, I would prefer to
> have confirmation that binary that I create works for jfricas.

Obviously, Kurt and Qian are currently a bit silent. But you have at
least my confirmation. However, I would like to see how you actually
include hsbcl. A description of that should go into install.rst (and
INSTALL) and also committed to the repo.

> There is still time for small additions and bug fixes, but not much:

Hmmm... as I reported here

https://www.mail-archive.com/fricas...@googlegroups.com/msg15364.html
https://groups.google.com/g/fricas-devel/c/U5AryLOax7U/m/pq3G1XwyAQAJ

the FriCAS-Aldor interface compiles, but does not fully work. I really
would like that we do not release without this being fixed.

In fact, may I ask you a favour? If you do changes that affects quite a
big piece of code and could potentially break things, like the "$ --> %"
change, please open a pull request at github so that others have the
chance to check things they care about, before the patches become
officially committed to the repo.

Ralf

[Waldek Hebisch]

On Tue, Jun 13, 2023 at 09:40:51PM +0200, Ralf Hemmecke wrote:
> On 13.06.23 22:46, hebisch wrote:
> > ATM major open thing is inclusion of hunchentoot, I would prefer to
> > have confirmation that binary that I create works for jfricas.
>
> Obviously, Kurt and Qian are currently a bit silent. But you have at
> least my confirmation.

Well, I wrote "binary". The question is if sbcl version I use for
creation of binaries has all features needed by jfricas. It should,
but testing is better than bling faith.

> However, I would like to see how you actually
> include hsbcl. A description of that should go into install.rst (and
> INSTALL) and also committed to the repo.

As I wrote my current thinking is that hunchentoot is dependence
like other dependencies: it is responsibility of person doing build
to make sure that it is available. For convenience we can add
hsbcl tarball to the release area. And of course instruction
in INSTALL.

> > There is still time for small additions and bug fixes, but not much:
>
> Hmmm... as I reported here
>
> https://www.mail-archive.com/fricas...@googlegroups.com/msg15364.html
> https://groups.google.com/g/fricas-devel/c/U5AryLOax7U/m/pq3G1XwyAQAJ
>
> the FriCAS-Aldor interface compiles, but does not fully work. I really would
> like that we do not release without this being fixed.

As I wrote in other message this is not interface problem. ATM I am
not aware of any problems with FriCAS-Aldor interface.

> In fact, may I ask you a favour? If you do changes that affects quite a big
> piece of code and could potentially break things, like the "$ --> %" change,
> please open a pull request at github so that others have the chance to check
> things they care about, before the patches become officially committed to
> the repo.

Well, long time ago I tried to provide patches so that people can
test various changes. Feedback I received was almost empty,
so I rarely do this.

And this change is not more "dangerous" than many other changes.
In fact, supposedly innocent change can lead to breakage. What
was different was late testing. Fortunately Peter made progress
on this part.

--
Waldek Hebisch

[Ralf Hemmecke]

On 16.06.23 02:14, Waldek Hebisch wrote:
> Well, I wrote "binary". The question is if sbcl version I use for
> creation of binaries has all features needed by jfricas. It should,
> but testing is better than bling faith.

OK, but building SBCL 1.1.1 from the git repo does not work on my
computer. Certainly someprerequisite missing. I am building with the
default SBCL 2.1.11.debian on Ubuntu 22.04.2 LTS.

Is there an easier way to get the sbcl version you wil be using?

> As I wrote my current thinking is that hunchentoot is dependence
> like other dependencies: it is responsibility of person doing build
> to make sure that it is available. For convenience we can add
> hsbcl tarball to the release area. And of course instruction
> in INSTALL.

If we go that way, then it seems as simple as asking the user to provide
an sbcl image with hunchentoot included such that

(require :asdf)(require :hunchentoot)

can be called and we do not have to change anything in FriCAS. Oh wait,
there was this thing with stdout.

https://github.com/fricas/fricas/commit/7c1d3e8ea7ced544ecb57156415e7b8af64e098b#diff-953a91d70c9e61cba8f0e8f2f97d7141601a66d5d12985e181c9abbb4b8da7d2

(see into the vmlisp.lisp part of the attached patch).

When I jfricas starts webspad.lisp, then *OBEY-STDOUT* will be set to T
and output goes the way it should go for jfricas in order to capture
output that would normally go to stdout and otherwise be invisible in
the notebook.

>> In fact, may I ask you a favour? If you do changes that affects quite a big
>> piece of code and could potentially break things, like the "$ --> %" change,
>> please open a pull request at github so that others have the chance to check
>> things they care about, before the patches become officially committed to
>> the repo.
>
> Well, long time ago I tried to provide patches so that people can
> test various changes. Feedback I received was almost empty,
> so I rarely do this.

Well, at least for me it feels troublesome to extract the patch from the
mail, call patch and record it in my local git tree so that I know where
I am. It would be much easier, if I could simply "git fetch hebisch" and
look at your branches. Also for you it would be a simple "git push" to
your github repository.

But true, for some things I do not have to say much, but the
FriCAS-Aldor interface is something I care about.

Ralf

=========================================================
; wrote /home/hemmecke/v/git/sbcl/obj/from-host/src/code/early-type.fasl-tmp
; compilation finished in 0:00:00.236
Unhandled SIMPLE-ERROR in thread #<SB-THREAD:THREAD "main thread" RUNNING
{1001834363}>:
FAILURE-P was set when creating "obj/from-host/src/code/early-type.fasl".

Backtrace for: #<SB-THREAD:THREAD "main thread" RUNNING {1001834363}>
0: (SB-DEBUG::DEBUGGER-DISABLED-HOOK #<SIMPLE-ERROR "FAILURE-P was set
when creating ~S." {10040CEC63}> #<unused argument> :QUIT T)
1: (SB-DEBUG::RUN-HOOK SB-EXT:*INVOKE-DEBUGGER-HOOK* #<SIMPLE-ERROR
"FAILURE-P was set when creating ~S." {10040CEC63}>)
2: (INVOKE-DEBUGGER #<SIMPLE-ERROR "FAILURE-P was set when creating ~S."
{10040CEC63}>)
3: (ERROR #<SIMPLE-ERROR "FAILURE-P was set when creating ~S."
{10040CEC63}>)
4: (SB-KERNEL:WITH-SIMPLE-CONDITION-RESTARTS ERROR NIL "FAILURE-P was
set when creating ~S." "obj/from-host/src/code/early-type.fasl")
5: (COMPILE-STEM "src/code/early-type" NIL :HOST-COMPILE)
6: (IN-HOST-COMPILATION-MODE #<FUNCTION (LAMBDA NIL :IN HOST-CLOAD-STEM)
{10054D5F2B}>)
7: (HOST-CLOAD-STEM "src/code/early-type" NIL)
8: (LOAD-OR-CLOAD-XCOMPILER #<FUNCTION HOST-CLOAD-STEM>)
9: (SB-INT:SIMPLE-EVAL-IN-LEXENV (LOAD-OR-CLOAD-XCOMPILER (FUNCTION
HOST-CLOAD-STEM)) #<NULL-LEXENV>)
10: (EVAL (LOAD-OR-CLOAD-XCOMPILER (FUNCTION HOST-CLOAD-STEM)))
11: (SB-EXT:INTERACTIVE-EVAL (LOAD-OR-CLOAD-XCOMPILER (FUNCTION
HOST-CLOAD-STEM)) :EVAL NIL)
12: (SB-IMPL::REPL-FUN NIL)
13: ((LAMBDA NIL :IN SB-IMPL::TOPLEVEL-REPL))
14: (SB-IMPL::%WITH-REBOUND-IO-SYNTAX #<FUNCTION (LAMBDA NIL :IN
SB-IMPL::TOPLEVEL-REPL) {10009BC53B}>)
15: (SB-IMPL::TOPLEVEL-REPL NIL)
16: (SB-IMPL::TOPLEVEL-INIT)
17: ((FLET SB-UNIX::BODY :IN SB-IMPL::START-LISP))
18: ((FLET "WITHOUT-INTERRUPTS-BODY-3" :IN SB-IMPL::START-LISP))
19: (SB-IMPL::START-LISP)

unhandled condition in --disable-debugger mode, quitting
deleted
#P"/home/hemmecke/v/git/sbcl/obj/from-host/src/code/early-type.fasl-tmp"
Command exited with non-zero status 1
4.02user 0.24system 0:06.83elapsed 62%CPU (0avgtext+0avgdata
118296maxresident)k
67240inputs+4336outputs (370major+69633minor)pagefaults 0swaps

[Dima Pasechnik]

It need not be GitHub. Any way to fetch git branches (from a git server) or patches which can be applied with "git apply" is infinity less error-prone that mailing patches without any metadata which specifies a  place in the git tree.

--
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 on the web visit https://groups.google.com/d/msgid/fricas-devel/44993d81-51e9-db00-3063-186e8996a79a%40hemmecke.org.

[Ralf Hemmecke]

An update to my attempt to build hsbcl on top of sbcl 1.1.1.
I use the binary sbcl 1.1.1 from sourceforge.net.

sbcl --eval '(load "../la.lisp")' --quit |tee rhxbld.lg
This is SBCL 1.1.1, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.

...

;
/home/hemmecke/v/git/hsbcl/hsbcl/pp/.cache/common-lisp/sbcl-1.1.1-linux-x64/home/hemmecke/v/git/hsbcl/hsbcl/pp/trivial-gray-streams-20210124-git/ASDF-TMP-streams.fasl
written
; compilation finished in 0:00:00.027

debugger invoked on a LOAD-SYSTEM-DEFINITION-ERROR in thread
#<THREAD "main thread" RUNNING {10029F1673}>:
Error while trying to load definition for system cl-ppcre from pathname
/home/hemmecke/v/git/hsbcl/hsbcl/pp/cl-ppcre-20220220-git/cl-ppcre.asd:
Illegal function call in method body:
((FUNCALL TEST-OP)
((INTERN (SYMBOL-NAME :RUN-ALL-TESTS) (FIND-PACKAGE :CL-PPCRE-TEST))
(EQL #<SYSTEM "cl-ppcre/test">)))

Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.

restarts (invokable by number or by possibly-abbreviated name):
0: [RETRY ] Retry EVAL of current
toplevel form.
1: [CONTINUE ] Ignore error and continue
loading file
"/home/hemmecke/v/git/hsbcl/hsbcl/pp/cl-ppcre-20220220-git/cl-ppcre.asd".
2: [ABORT ] Abort loading file
"/home/hemmecke/v/git/hsbcl/hsbcl/pp/cl-ppcre-20220220-git/cl-ppcre.asd".
3: [REINITIALIZE-SOURCE-REGISTRY-AND-RETRY] Retry finding system cl-ppcre
after reinitializing the
source-registry.
4: Retry EVAL of current
toplevel form.
5: Ignore error and continue
loading file "/home/hemmecke/v/git/hsbcl/hsbcl/pp/../la.lisp".
6: Abort loading file
"/home/hemmecke/v/git/hsbcl/hsbcl/pp/../la.lisp".
7: Ignore runtime option
--eval "(load \"../la.lisp\")".
8: Skip rest of --eval and
--load options.
9: Skip to toplevel
READ/EVAL/PRINT loop.
10: [EXIT ] Exit SBCL (calling
#'EXIT, killing the process).

((FLET #:LAMBDA2232 :IN ASDF::LOAD-SYSDEF)
#<SIMPLE-ERROR "Illegal function call in method body:~% ~S"
{1003E952E3}>)
0]

[Grégory Vanuxem]

Hi Ralf,

I wonder why you're using such an old LISP? It seems you have a x64 system, why are you not trying roswell for your LISP implementation? https://roswell.github.io/

With this very small app, you can easily manage the LISP you want and even add Hunchentoot with just 'ros install hunchentoot'. After, I guess with the Waldek FriCAS, add just the parameter used to add the webserver. Using configure parameter --with-lisp='ros run' all will be done automagically.

Regards,

__

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 on the web visit https://groups.google.com/d/msgid/fricas-devel/be1d4642-4e18-9020-64a1-cd4e7272e2b3%40hemmecke.org.

[Grégory Vanuxem]

I forgot, all LISP packages and implementations will be installed in $HOME/.roswell/

[Grégory Vanuxem]

Or, with installed 'quicklisp' from Debian, you can look at attached .input file code and remove the different ')lisp '

[Ralf Hemmecke]

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

[Dima Pasechnik]

On Mon, Jun 19, 2023 at 8:44 AM Ralf Hemmecke <ra...@hemmecke.org> wrote:
>
> 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's wishful thinking that SBCL 1.1.1.1, released in 2012, will
correctly work on all modern OSs.
Waste of time, if you ask me...

> --
> 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 on the web visit https://groups.google.com/d/msgid/fricas-devel/20e52895-082e-555a-24f4-13f1d3dff3f7%40hemmecke.org.

[Grégory Vanuxem]

I agree with you Dima,

I have even tried to build asdf using quicklisp and it hurts directly with:

; Fetching #<URL "http://beta.quicklisp.org/asdf/3.2.1/asdf.lisp">
; 628.18KB
==================================================
643,253 bytes in 0.19 seconds (3254.80KB/sec);
; caught ERROR:
;   READ error during COMPILE-FILE:
;
;     Symbol "PRINT-BACKTRACE" not found in the SB-DEBUG package.
;
;       Line: 4514, Column: 29, File-Position: 220633
;
;       Stream: #<SB-SYS:FD-STREAM for "file /tmp/quicklisp/asdf.lisp" {1005CB5E63}>
;
; compilation unit aborted
;   caught 1 fatal ERROR condition
;   caught 1 ERROR condition

debugger invoked on a SIMPLE-ERROR in thread
#<THREAD "main thread" RUNNING {10029F1993}>:
  Could not load ASDF "3.0" or newer

================================================================

So I guess tons of problems will happen if sbcl-1.1.1 is used.

To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/CAAWYfq0Wjt9idietzY%3D8wyH5tCPYvO67KWYpbWQKLesPyO9jdg%40mail.gmail.com.

[Waldek Hebisch]

On Mon, Jun 19, 2023 at 10:29:44AM +0100, Dima Pasechnik wrote:
> On Mon, Jun 19, 2023 at 8:44 AM Ralf Hemmecke <ra...@hemmecke.org> wrote:
> >
> > 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's wishful thinking that SBCL 1.1.1.1, released in 2012, will
> correctly work on all modern OSs.
> Waste of time, if you ask me...

Well, download binary 1.3.8 (based on sbcl 1.1.1) and try it. It
works on all systems available to me and up to now I had no report
of failure due to incompatibility with the system. Of course,
at some time we will have to move to newer version. But using
newest version is essentially warranted to fail on some systems,
so we need to choose correctly.

More generaly, if you declare everything more than 3.5 years as
obsolete and decide to break it, that is your right. But not all
folks adapt such point of view and it is possible to create
binaries compatible with wide range of system versions. Of
course, I need to avoid unstable dependencies (or at least have
some way to tame them), otherwise I would be hostage to other
folks breaking my binaries.

--
Waldek Hebisch

[Dima Pasechnik]

On Mon, Jun 19, 2023 at 3:05 PM Waldek Hebisch
<de...@fricas.math.uni.wroc.pl> wrote:
>
> On Mon, Jun 19, 2023 at 10:29:44AM +0100, Dima Pasechnik wrote:
> > On Mon, Jun 19, 2023 at 8:44 AM Ralf Hemmecke <ra...@hemmecke.org> wrote:
> > >
> > > 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's wishful thinking that SBCL 1.1.1.1, released in 2012, will
> > correctly work on all modern OSs.
> > Waste of time, if you ask me...
>
> Well, download binary 1.3.8 (based on sbcl 1.1.1) and try it. It
> works on all systems available to me and up to now I had no report
> of failure due to incompatibility with the system.

A system not certified by its makers to work on an OS/hardware,
because it's way too old,
should be avoided, full stop.

As well, I imagine that code compiled, for a modern CPU, with an up to
date sbcl, will be considerably
faster than the one built with sbcl 1.1.1, as the latter has no idea
about modern CPUs.

> Of course,
> at some time we will have to move to newer version. But using
> newest version is essentially warranted to fail on some systems,
> so we need to choose correctly.
>
> More generaly, if you declare everything more than 3.5 years as
> obsolete and decide to break it, that is your right. But not all
> folks adapt such point of view and it is possible to create
> binaries compatible with wide range of system versions.

Why do you want to encourage these folks to stay on obsolete OSs, which
have reached their EOL, are insecure and buggy?
You want them to get hacked? :-)

> Of
> course, I need to avoid unstable dependencies (or at least have
> some way to tame them), otherwise I would be hostage to other
> folks breaking my binaries.
>
> --
> Waldek Hebisch
>

> --
> 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 on the web visit https://groups.google.com/d/msgid/fricas-devel/ZJBguyweZz/7VXcd%40fricas.math.uni.wroc.pl.

[Waldek Hebisch]

On Mon, Jun 19, 2023 at 08:33:16AM +0200, Ralf Hemmecke wrote:
> An update to my attempt to build hsbcl on top of sbcl 1.1.1.
> I use the binary sbcl 1.1.1 from sourceforge.net.

Indeed, there are problems. I am looking at possible alternatives
and workarounds.

--
Waldek Hebisch

[Waldek Hebisch]

I am trying to use sbcl-1.4.6. ATM it seems that it works.
However, since the process uses different, newer environment
(Gentoo) there are possible glitches. I have now put test
tarball at

http://www.math.uni.wroc.pl/~hebisch/fricas/fricas-1.3.9-pre.amd64.tar.bz2

Actual release may contain more bug fixes and certainly there will
be update to documentation. This is mostly to verify that
binary works. In particular hunchentoot is included, so it
should work with jfricas.

--
Waldek Hebisch

[Nasser M. Abbasi]

Why is this build with sbcl 1.4.6 since there is newer version sbcl 2.3.0?

./fricas --version
FriCAS 2023-06-17
based on sbcl 1.4.16
>

>fricas --version
FriCAS 1.3.8
based on sbcl 2.3.0
>

Does it make any difference for performance? I assume the final version of Fricas 1.3.9 will

be in source code and one can build it with more up to date sbcl, like one can do now with 1.3.8?

I will do a quick test on this newer version of Fricas and compare results with 1.3.8 on

the first 12 files in CAS integration tests and see if there is any regression.

--Nasser

[Waldek Hebisch]

On Mon, Jun 19, 2023 at 03:46:34PM +0100, Dima Pasechnik wrote:
> On Mon, Jun 19, 2023 at 3:05 PM Waldek Hebisch
> <de...@fricas.math.uni.wroc.pl> wrote:
> >
> > On Mon, Jun 19, 2023 at 10:29:44AM +0100, Dima Pasechnik wrote:
> > > On Mon, Jun 19, 2023 at 8:44 AM Ralf Hemmecke <ra...@hemmecke.org> wrote:
> > > >
> > > > 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's wishful thinking that SBCL 1.1.1.1, released in 2012, will
> > > correctly work on all modern OSs.
> > > Waste of time, if you ask me...
> >
> > Well, download binary 1.3.8 (based on sbcl 1.1.1) and try it. It
> > works on all systems available to me and up to now I had no report
> > of failure due to incompatibility with the system.
>
> A system not certified by its makers to work on an OS/hardware,
> because it's way too old,
> should be avoided, full stop.

Burden of ensuring that existing software works in on OS and
hardware makers. Linux actually delivers quite good compatibility.
I agree that software which does not take compatibility seroiusly
should be avoided. Unfortunately, it looks that ASDF seriously
messed compatibility and signifcant portion of Lisp world
depends on ASDF.

> As well, I imagine that code compiled, for a modern CPU, with an up to
> date sbcl, will be considerably
> faster than the one built with sbcl 1.1.1, as the latter has no idea
> about modern CPUs.

Well, this is more about optimizations present in compiler. And
recent sbcl optimizes better. Compilers are reasonably mature
business and few percent improvement is "considerable", but
such improvements are frequently sacrified for partablity.

> > Of course,
> > at some time we will have to move to newer version. But using
> > newest version is essentially warranted to fail on some systems,
> > so we need to choose correctly.
> >
> > More generaly, if you declare everything more than 3.5 years as
> > obsolete and decide to break it, that is your right. But not all
> > folks adapt such point of view and it is possible to create
> > binaries compatible with wide range of system versions.
>
> Why do you want to encourage these folks to stay on obsolete OSs, which
> have reached their EOL, are insecure and buggy?
> You want them to get hacked? :-)

Well, unfortunately, installing software is turning into constraint
satisfaction problem, there are many constraints and user have to
find combination of versions that satisfies all constraints.
Much of that is not needed at all or could be much less
restrictive. And I do not want to add extra constraints to
FriCAS use.

Concerning security, normal life cycle for software is like
follows. In first few years after release there is a bug fest,
when bugs in new functionality are discoverd and fixed.
Then software enter stable period, with few bugs found.
After several years things start to break up because
somebody broke them. Security problem are due to bugs,
so if you want most security you should use stable versions.
Most major Linux distributions provide security updates
for 10 years, in this period old software is likely to
be more secure than new one.

Most security threats came from network, so old system
(even without security updates) not connected to network
is likely to be more secure than system connected to the
net. Yet people keep connecting computers to the net.

Anyway, there are legitimate reasons to run really obsolete
systems and I have no principal objection to people doing
this. Of course, there are limits: if some people want
to run FriCAS on real 370, they will have my sympathy,
but probably no real help. But I consider 10 years minimal
reasonable support window.

--
Waldek Hebisch

[Waldek Hebisch]

On Sat, Jun 24, 2023 at 11:23:32AM -0700, 'Nasser M. Abbasi' via FriCAS - computer algebra system wrote:
> Why is this build with sbcl 1.4.6 since there is newer version sbcl 2.3.0?

Binary that we distribute is supposed to run on wide range of systems,
including older ones. sbcl 1.4.16 makes this easier, as it is less
likely to depend on new features not present in older systems.

>
> ./fricas --version
> FriCAS 2023-06-17
> based on sbcl 1.4.16
> >
>
> >fricas --version
> FriCAS 1.3.8
> based on sbcl 2.3.0
> >
>
> Does it make any difference for performance?

There is some difference, sbcl-2.3.5 gives faster binary. But the
difference is much smaller than say using ecl.

> I assume the final version of
> Fricas 1.3.9 will
> be in source code and one can build it with more up to date sbcl, like one
> can do now with 1.3.8?

Yes, sure.

--
Waldek Hebisch

[Nasser M. Abbasi]

FYI,

I've done a quick initial Fricas integration test for

>which fricas
/home/me/TMP/usr/local/bin/fricas

>fricas --version
FriCAS 2023-06-17
based on sbcl 1.4.16

Using sagemath 10.0 on Linux on first 12 files
(1,892 integrals) from CAS integration tests database
(these integrals are obtained from Rubi's test suite
maintained by Albert Rich) and compared the result
with ones obtained using 1.3.8 using ecl 21.2.1
on same Linux virtual box. Both using same sagemath 10.0.

This is the result. The good news is that there were
no problems found and no regression. But
also obtained the same %pass on these files that 1.3.8 had.

FriCAS 2023-06-17:
% pass: 95.243

vs.

FriCAS 1.3.8 :
% pass: 95.243

For specific stats on one file, here are stats for file #10
(Timofeev integration Problems) which contains 705 problems.

Only difference I see is that it is faster now. This could be
due to using sbcl lisp instead of ecl lisp I was using before.

FriCAS 2023-06-17:
passed: 93.62%
A grade: 67.66%
average time used: 0.59 sec
average leaf size: 267.73

FriCAS 1.3.8:
passed: 93.62%
A grade: 67.66%
average time used: 1.55 sec
average leaf size: 267.73

The following is link to the PDF file report for just file #10 above
if you like to see it. This is for the FriCAS 2023-06-17 version.

report.pdf

Full tests will run when official 1.3.9 is released.

--Nasser

[Ralf Hemmecke]

On 25.06.23 05:46, 'Nasser M. Abbasi' via FriCAS - computer algebra

system wrote:
> FYI,
>
> I've done a quick initial Fricas integration test for

...

> This is the result. The good news is that there were
> no problems found and no regression.

Thank you, Nasser.

I think, it would be a good idea to always contact you to let your
machinery run on the FriCAS code, before the new release comes out.
You do important work.

Ralf

[Waldek Hebisch]

Thanks for info.

This time changes to integrator are modest. Main change is that
FriCAS no longer uses 'real'. Compare 1.3.8:

(1) -> integrate(sqrt(1-x^3),x)

+--------+
| 3
2 x\|- x + 1
(1) --------------
5
Type: Union(Expression(Integer),...)

to 1.3.9:

+--------+
+---+ | 3
6 weierstrassPInverse(0,4,x) + 2 x\|- 1 \|- x + 1
(1) ---------------------------------------------------
+---+
5 \|- 1
Type: Union(Expression(Integer),...)

In particular spurious zere results should be gone.

Concerning speed: 'real' caused excessive execution time on some
examples, but they were probably rare enough and did not significantly
influence average time.

--
Waldek Hebisch

[Ralf Hemmecke]

> I am trying to use sbcl-1.4.6. ATM it seems that it works.
> However, since the process uses different, newer environment
> (Gentoo) there are possible glitches. I have now put test
> tarball at
>
> http://www.math.uni.wroc.pl/~hebisch/fricas/fricas-1.3.9-pre.amd64.tar.bz2

> binary works. In particular hunchentoot is included, so it
> should work with jfricas.

I installed this binary. In fact, I roughly followed the steps at

https://hemmecke.github.io/qeta/fricasinstall.html#recommended-installation

I had, of course, no problem with libssl. So that section from the above
site can safely be ignored.

The jfricas installation in a virtual environment ran smoothly and
obviously seems to work nicely.

I have not installed JupyText, but these things do not depend on FriCAS
or hunchentoot, but are more connected to the jupyter side.

Waldek, newer versions of jfricas rely on a new variable *OBEY-STDOUT*
in FriCAS.

https://github.com/fricas/jfricas/commit/78be121a4b10ee4183d4e097547c05a4756da633

The respective patch to FriCAS is attached.

If that is not in the fricas repo, I must do a redefinition of OBEY
during the start of webspad.lisp from jfricas.

https://github.com/hemmecke/jfricas/blob/master/jfricas/webspad.lisp#L95

I would rather like to go without such a redefinition and simply switch
a variable to true.

Similarly with mathprintWithNumber. But I guess mathPrintWithNumber is
too late for the next release.

The definition of |interpret-block| would also be a nice addition to
FriCAS, since it allows multi-line strings to be interpreted as if
coming from a file (with intendation working correctly).

https://github.com/hemmecke/jfricas/blob/master/jfricas/webspad.lisp#L102

I would like to ask for inclusion of the attached patch since that
does not actually change any existing behaviour of FriCAS, except that
one then can set *OBEY-STDOUT* to true in order to be able to catch
everything that goes to the stdout, in particular the output of
")sys pwd".

Anyone else who tested jFriCAS? See above website for installation
steps. You just use the binary Waldek provided.

http://www.math.uni.wroc.pl/~hebisch/fricas/fricas-1.3.9-pre.amd64.tar.bz2

Thank you
Ralf

[Waldek Hebisch]

On Sun, Jun 25, 2023 at 04:13:46PM +0200, Ralf Hemmecke wrote:
> > I am trying to use sbcl-1.4.6. ATM it seems that it works.
> > However, since the process uses different, newer environment
> > (Gentoo) there are possible glitches. I have now put test
> > tarball at
> >
> > http://www.math.uni.wroc.pl/~hebisch/fricas/fricas-1.3.9-pre.amd64.tar.bz2
>
> > binary works. In particular hunchentoot is included, so it
> > should work with jfricas.
>
> I installed this binary. In fact, I roughly followed the steps at
>
> https://hemmecke.github.io/qeta/fricasinstall.html#recommended-installation
>
> I had, of course, no problem with libssl. So that section from the above
> site can safely be ignored.
>
> The jfricas installation in a virtual environment ran smoothly and obviously
> seems to work nicely.
>
> I have not installed JupyText, but these things do not depend on FriCAS or
> hunchentoot, but are more connected to the jupyter side.
>
> Waldek, newer versions of jfricas rely on a new variable *OBEY-STDOUT* in
> FriCAS.
>
> https://github.com/fricas/jfricas/commit/78be121a4b10ee4183d4e097547c05a4756da633
>
> The respective patch to FriCAS is attached.

OK

> If that is not in the fricas repo, I must do a redefinition of OBEY during
> the start of webspad.lisp from jfricas.
>
> https://github.com/hemmecke/jfricas/blob/master/jfricas/webspad.lisp#L95
>
> I would rather like to go without such a redefinition and simply switch a
> variable to true.
>
> Similarly with mathprintWithNumber. But I guess mathPrintWithNumber is too
> late for the next release.

Well, I was thinking about this. The attached patch should handle this.

Just set '$print_equatnum' to 'false' (Lisp 'nil') to supress equation
numbers.

> The definition of |interpret-block| would also be a nice addition to FriCAS,
> since it allows multi-line strings to be interpreted as if coming from a
> file (with intendation working correctly).
>
> https://github.com/hemmecke/jfricas/blob/master/jfricas/webspad.lisp#L102

Yes, it can go in.

> I would like to ask for inclusion of the attached patch since that
> does not actually change any existing behaviour of FriCAS, except that one
> then can set *OBEY-STDOUT* to true in order to be able to catch everything
> that goes to the stdout, in particular the output of
> ")sys pwd".

Yes, OK.

--
Waldek Hebisch

[Nasser M. Abbasi]

opps, very sorry. I had to re-run this Fricas small test
again on sagemath 10.

Please ignore the above post. Here is the correct one:

It turned out sagemath had its own internal fricas buildin,
and I forgot about that and thought because I changed the
PATH, sagemath will now use the new Fricas.
 
But Sagemath was still using 1.3.8 internally and did not
use the one I had setup as it ignores the PATH/LD_LIBRARY_PATH
used in my .bashrc (it has its own internal /local tree it looks at
first).

No wonder I was getting same result as before. I was suspicious
at first that same exact result was generated, as I expected Fricas
score to improve, even if by little but then I thought it was
may be due to no code changes in Fricas for these type of
integrals. My mistake, I should have looked more into this to
verify. it was late and I was sleepy.

I spend all this morning looking into this to make sure and found
the problem.

(It is always a struggle for me to tell sagemath after I install it
to use the correct versions of external CAS programs instead of
ones it builds or it wants to use). Same with Maxima.

For giac, sagemath does have this  configuration option
to tell it use system installed giac,

   ./configure --with-system-giac=force

But no one for fricas and no one for Maxima.

Maxima is even worst than Fricas, as sagemath always builds Maxima
regadless and then I have to go delete the one it build and add
symlinks to point to the system Maxima as that is more recent.

Any way, I just rebuild sagemath again now from scratch and made
sure now to not make it build Fricas 1.3.8 as I did before,
and re-run the tests.

Here is the result.

First made sure sage is using correct Fricas:

>sage
┌─────────────────────────────────
│ SageMath version 10.0, Release Date: 2023-05-20     
│ Using Python 3.10.9. Type "help()" for help.                 
└─────────────────────────────────
sage: print(fricas.eval(")lisp |$build_version|"))

Value = "FriCAS 2023-06-17"

sage: integrate(sin(x),x, algorithm="fricas")
-cos(x)
-------------------------------------

>which fricas
/usr/local/bin/fricas

>fricas --version
FriCAS 2023-06-17
based on sbcl 1.4.16

The results:
============

Using sagemath 10.0 on Linux on first 12 files
(1,892 integrals) from CAS integration tests database
(these integrals are obtained from Rubi's test suite
maintained by Albert Rich) and compared the result
with ones obtained using 1.3.8 using ecl 21.2.1
on same Linux virtual box.  Both using same sagemath 10.0.

The good news is that there were no problems found and no regression.

Also Fricas pre 1.3.9 performed better than 1.3.8 in this small
test (As one would expect).

FriCAS 2023-06-17:
    % pass: 95.455 (better than before)

vs.

FriCAS 1.3.8 :
    % pass: 95.243

For specific stats on one file, here are stats for file #10
(Timofeev integration Problems) which contains 705 problems.
                 

FriCAS 2023-06-17:
    passed:   93.90%  (43 failed) (better than before)
    A grade:  67.66% (same as before)
    average time used: 0.48 sec (better than before)
    average leaf size: 234.57 (better than before)

FriCAS 1.3.8:
    passed:   93.62%  (45 failed)

    A grade:  67.66%
    average time used: 1.55 sec
    average leaf size: 267.73

The following is link to the PDF file report for just file #10 above
if you like to see it. This is for the FriCAS 2023-06-17 version.

report.pdf

Full tests will run when official 1.3.9 is released which will
take few weeks to complete.

--Nasser

[Ralf Hemmecke]

On 26.06.23 01:11, 'Nasser M. Abbasi' via FriCAS - computer algebra

system wrote:
> Any way, I just rebuild sagemath again now from scratch and made
> sure now to not make it build Fricas 1.3.8 as I did before,
> and re-run the tests.

I run a standard sage (with no particular options used when I built it).
It automatically picks my installed sbcl-fricas.

I have no idea what additional features come in the sage-fricas
connection when you let sage build fricas on ecl.

Ralf

[Nasser M. Abbasi]

I setup new VBox with new Linux, and installed sagemath. 

There is an option with sage to ask it to install Fricas if you want afterwords, and I used that option, it is 

    sage -i fricas

And then it will download and install it all automatically (but local to sagemath, not on the system).

I normally do not do that, but since I was lazy and instead of me going and downloading the tar file

and etc..., I just let sagemath install it.  

There is no difference in connection mechanism if one installs Fricas outside sage or let it

install using the above command. 

I just thought that when I installed Fricas pre 1.3.9 outside and set the path to it, that sage will now use the external one.

--Nasser

[Ralf Hemmecke]

On 26.06.23 08:20, 'Nasser M. Abbasi' via FriCAS - computer algebra
system wrote:

> sage -i fricas

> There is no difference in connection mechanism if one installs
> Fricas outside sage or let it install using the above command.

Well, the sage people make it easy to install FriCAS via "sage -i
fricas'. That's the good thing. The bad thing is that they choose to
build it on ecl. Well, it's a natural choice for them, since they also
use ecl for Maxima. I am not aware of an option to select sbcl when
installing FriCAS that way. I am also not aware of an option to switch
of the FriCAS that was installed via "-i fricas" and use a FriCAS that
was installed otherwise. I guess you should ask on sage-devel how to do
it properly.

But not using 'sage -i fricas' and installing sbcl-fricas yourself
definitely works.

What I meant in my previous mail is that I have no idea whether using
ecl-fricas is more tightly connected to sage. When you use sbcl-fricas,
communication between fricas and sage goes essentially via strings.

Ralf

[Dima Pasechnik]

I've opened an issue to create a configure option for system-wide
fricas to be usable with Sage.
https://github.com/sagemath/sage/issues/35837

Please post there details on what you do to use Sage with system-wide
fricas now - this might help.

--
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 on the web visit

https://groups.google.com/d/msgid/fricas-devel/ab60ba55-1171-4ba9-9826-7d10e708fbddn%40googlegroups.com.

[Dima Pasechnik]

On Mon, Jun 26, 2023 at 7:20 AM 'Nasser M. Abbasi' via FriCAS -
computer algebra system <fricas...@googlegroups.com> wrote:
>
> I setup new VBox with new Linux, and installed sagemath.
>
> There is an option with sage to ask it to install Fricas if you want afterwords, and I used that option, it is
>
> sage -i fricas

it's better to run, before the build,

./configure --enable-fricas=yes


Then it will be built automatically during the run of make
After https://github.com/sagemath/sage/issues/35837 is done, to use
external fricas,
there will be --with-system-fricas= option to ./configure, as well.

>
> And then it will download and install it all automatically (but local to sagemath, not on the system).
>
> I normally do not do that, but since I was lazy and instead of me going and downloading the tar file
> and etc..., I just let sagemath install it.
>
> There is no difference in connection mechanism if one installs Fricas outside sage or let it
> install using the above command.
>
> I just thought that when I installed Fricas pre 1.3.9 outside and set the path to it, that sage will now use the external one.
>
> --Nasser
>
>
> On Monday, June 26, 2023 at 12:36:18 AM UTC-5 ra...@hemmecke.org wrote:
>>
>> On 26.06.23 01:11, 'Nasser M. Abbasi' via FriCAS - computer algebra
>> system wrote:
>> > Any way, I just rebuild sagemath again now from scratch and made
>> > sure now to not make it build Fricas 1.3.8 as I did before,
>> > and re-run the tests.
>>
>> I run a standard sage (with no particular options used when I built it).
>> It automatically picks my installed sbcl-fricas.
>>
>> I have no idea what additional features come in the sage-fricas
>> connection when you let sage build fricas on ecl.
>>
>> 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 fricas-devel...@googlegroups.com.

> To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/d379863a-8e8a-48d8-8f16-286a2363613an%40googlegroups.com.

[Ralf Hemmecke]

On 25.06.23 19:58, Waldek Hebisch wrote:
> On Sun, Jun 25, 2023 at 04:13:46PM +0200, Ralf Hemmecke wrote:

>> https://github.com/fricas/jfricas/commit/78be121a4b10ee4183d4e097547c05a4756da633

> OK

I've opened
https://github.com/fricas/fricas/pull/129
and will commit tomorrow night.

>> Similarly with mathprintWithNumber. But I guess mathPrintWithNumber is too
>> late for the next release.
>
> Well, I was thinking about this. The attached patch should handle this.
>
> Just set '$print_equatnum' to 'false' (Lisp 'nil') to supress equation
> numbers.

OK, will experiment tomorrow.

>> The definition of |interpret-block| would also be a nice addition to FriCAS,
>> since it allows multi-line strings to be interpreted as if coming from a
>> file (with intendation working correctly).
>>
>> https://github.com/hemmecke/jfricas/blob/master/jfricas/webspad.lisp#L102
>
> Yes, it can go in.

Hmmmm... not so easy for me. Long time ago that I did this. I think, I
took most stuff from here.

https://github.com/fricas/fricas/blob/master/src/interp/int-top.boot#L144

So |interpret-block| should probably live in int-top.boot.

But to translate my code back into .boot format without making erros is
currently out of scope. Waldek, may I ask for your help.

Ralf

[Waldek Hebisch]

On Mon, Jun 26, 2023 at 11:43:10PM +0200, Ralf Hemmecke wrote:
> > > The definition of |interpret-block| would also be a nice addition to FriCAS,
> > > since it allows multi-line strings to be interpreted as if coming from a
> > > file (with intendation working correctly).
> > >
> > > https://github.com/hemmecke/jfricas/blob/master/jfricas/webspad.lisp#L102
> >
> > Yes, it can go in.
>
> Hmmmm... not so easy for me. Long time ago that I did this. I think, I took
> most stuff from here.
>
> https://github.com/fricas/fricas/blob/master/src/interp/int-top.boot#L144
>
> So |interpret-block| should probably live in int-top.boot.
>
> But to translate my code back into .boot format without making erros is
> currently out of scope. Waldek, may I ask for your help.

AFACS in Boot this is:

interpret_block(code) ==
$newcompErrorCount : local := 0
$inclAssertions : local := []
$ncMsgList : local := []
$erMsgToss : local := false
$lastPos : local := $nopos
$EchoLines : local := false
st := MAKE_-STRING_-INPUT_-STREAM(code)
intloopInclude0(st, 'webspad, 0)

Both Lisp version and the above behave rather badly when called
from command line (the same is true for parseAndEvalStr).
Namely, after calling it interpreter is apparently waiting
for more input from the string, but none is coming. So
command line is effectively blocked. Probably does not
matter for server style use, but definitely it is not "universal"
function.

--
Waldek Hebisch

[Ralf Hemmecke]

> AFACS in Boot this is:
>
> interpret_block(code) ==
> $newcompErrorCount : local := 0
> $inclAssertions : local := []
> $ncMsgList : local := []
> $erMsgToss : local := false
> $lastPos : local := $nopos
> $EchoLines : local := false
> st := MAKE_-STRING_-INPUT_-STREAM(code)
> intloopInclude0(st, 'webspad, 0)

Thank you! I will test tonight.

> Both Lisp version and the above behave rather badly when called
> from command line (the same is true for parseAndEvalStr).
> Namely, after calling it interpreter is apparently waiting
> for more input from the string, but none is coming. So
> command line is effectively blocked. Probably does not
> matter for server style use, but definitely it is not "universal"
> function.

Maybe I do not quite get what you say. Is it: "The function works
nicely, but the user cannot send another string during the time the
first call to interpret_block is running?" In other words I cannot have
two instances of interpret_block running at the same time?
I wonder how this could be ever relevant when FriCAS anyway uses just
one processor.

Although it would be an interesting idea to send and evaluate other
input to FriCAS during a long running command, but wouldn't that badly
interfere with session management? When the first command does something
like "z:=1; for i in 1..10^100 repeat print(i)" and the second one says
"z:=2", would the first one suddenly print 2?

Ralf

[Waldek Hebisch]

To explain more: interpret_block gets simple input and should do its
work in almost no time, but apparently it never finishes. I must
admit that natural question is how it can work at all in
webspad? I did not look but probably some of extra variable
setting causes it to finish.

BTW: To see what I mean try

s := "1 + 1"
interpret_block(s)$Lisp

I can issue new commands only after pressing Ctrl-C.
And adding newline at end of the string does not help.

> Although it would be an interesting idea to send and evaluate other input to
> FriCAS during a long running command, but wouldn't that badly interfere with
> session management? When the first command does something like "z:=1; for i
> in 1..10^100 repeat print(i)" and the second one says "z:=2", would the
> first one suddenly print 2?

Not a problem at all. Effectively this is done when you run
Hyperdoc examples. Of course, when one command source has long
computation the second must wait. User variables are handled by
frame machinery. Of course, if code in two frames tried to set
global Boot variable to different value (possibly via ')set'
command) there would be trouble.

--
Waldek Hebisch

[Ralf Hemmecke]

On 27.06.23 14:07, Waldek Hebisch wrote:
>>> Both Lisp version and the above behave rather badly when called
>>> from command line (the same is true for parseAndEvalStr).
>>> Namely, after calling it interpreter is apparently waiting
>>> for more input from the string, but none is coming. So
>>> command line is effectively blocked. Probably does not
>>> matter for server style use, but definitely it is not "universal"
>>> function.
>>
>> Maybe I do not quite get what you say. Is it: "The function works nicely,
>> but the user cannot send another string during the time the first call to
>> interpret_block is running?" In other words I cannot have two instances of
>> interpret_block running at the same time?
>> I wonder how this could be ever relevant when FriCAS anyway uses just one
>> processor.
>
> To explain more: interpret_block gets simple input and should do its
> work in almost no time, but apparently it never finishes. I must
> admit that natural question is how it can work at all in
> webspad? I did not look but probably some of extra variable
> setting causes it to finish.

Oh... that sounds scary. I never saw that my |interpret-block| lisp
function did not return, OK, only for long running processes that are
expected not to return.

> BTW: To see what I mean try
>
> s := "1 + 1"
> interpret_block(s)$Lisp

Yes, I also see that with pure FriCAS and even loading the boot function
into a jfricas session and executing interpret_block(s)$Lisp never returns.

Hmmm, strange. But then I never call interpret-block directly in
webspad.lisp. In fact, it can have two reasons. One is this:

(defun |webspad-parseAndEvalStr| (code)
(setf |$printStorageIfTrue| T) ; Make sure we get "Storage:" line.
(setf |$fortranFormat| NIL) ; we don't want Fortran output
(setf |$htmlFormat| NIL) ; we don't want Html output
(setf |$openMathFormat| NIL) ; we don't want OpenMath output
(setf |$MARGIN| 0) ; we don't want indentation
(eq (catch 'SPAD_READER (catch '|top_level| (|interpret-block| code)))
'|restart|))

and if that is not sufficient to return, then webspad only calls that
function after having modified a number of streams.

https://github.com/fricas/jfricas/blob/master/jfricas/webspad.lisp#L155

I suspect that it is the last line in |webspad-parseAndEvalStr| that
saves me. Unfortunately, I were completely lost if I had to explain why
this line is there and what would happen if I removed it.

>> Although it would be an interesting idea to send and evaluate other input to
>> FriCAS during a long running command, but wouldn't that badly interfere with
>> session management? When the first command does something like "z:=1; for i
>> in 1..10^100 repeat print(i)" and the second one says "z:=2", would the
>> first one suddenly print 2?
>
> Not a problem at all. Effectively this is done when you run
> Hyperdoc examples.

But you maybe saying that hyperdoc runs in a different frame, so my
current session is actually not affected.

BTW, HyperDoc probably starts a completely new FriCAS process with no
assigned variables whatsoever. Or will it contact the running kernel and
just use a new frame?

Actually, my question is whether it would be possible to clone a running
fricas session and continue with some computation in one clone with at
the same time with another computation in another clone? Yes, I somehow
want to use the many processors on my machine and are always sad that I
must start two completely separate fricas sessions with only string
communication between them. Somehow more parallelism in FriCAS would be
wonderful... dream, dream.

Ralf

[Waldek Hebisch]

The last line is to make sure that in case of errors webspad-parseAndEvalStr
is still in control. Otherwise control would pass to top level of the
interpreter. This affects only error handling, in normal case this
should be no-op.

> > > Although it would be an interesting idea to send and evaluate other input to
> > > FriCAS during a long running command, but wouldn't that badly interfere with
> > > session management? When the first command does something like "z:=1; for i
> > > in 1..10^100 repeat print(i)" and the second one says "z:=2", would the
> > > first one suddenly print 2?
> >
> > Not a problem at all. Effectively this is done when you run
> > Hyperdoc examples.
>
> But you maybe saying that hyperdoc runs in a different frame, so my current
> session is actually not affected.

Yes.

> BTW, HyperDoc probably starts a completely new FriCAS process with no
> assigned variables whatsoever. Or will it contact the running kernel and
> just use a new frame?

Hyperdoc connects to running FriCAS. For example, when you compile a
new domain this would unknown to other process, but Hyperdoc has
info about new domain.

> Actually, my question is whether it would be possible to clone a running
> fricas session and continue with some computation in one clone with at the
> same time with another computation in another clone?

Well, that is what Unix fork is doing. Camm did this for GCL (I am
not sure if it was experimental version or regular one). For sbcl
there is extra factor, namely sbcl uses threads so there would be
some effort to avoid confusion within sbcl. However, it is not
clear if such form of parallelizm is really better than separate
processes: after fork processes are separate.

> Yes, I somehow want to
> use the many processors on my machine and are always sad that I must start
> two completely separate fricas sessions with only string communication
> between them. Somehow more parallelism in FriCAS would be wonderful...
> dream, dream.

Well, I am not aware of a CAS that can work really in parallel fashion.
Namely, CAS has things like symbol tables/caches and one needs to
for correct operation one needs to serialize access to such structures.
The effect could be that parallel version on many processors is
slower than serial version on single processor. Namely, on symbol
table intensive code real work is likely to be serial anyway, but
_possiblity_ of access from different threads leads to slowdown.

What is done is to give parallel implementations to performance
critical routines. For example parallel operations on big matrices
or on big polynomials.

--
Waldek Hebisch

[Ralf Hemmecke]

On 27.06.23 16:37, Waldek Hebisch wrote:
>> Actually, my question is whether it would be possible to clone a running
>> fricas session and continue with some computation in one clone with at the
>> same time with another computation in another clone?
>
> Well, that is what Unix fork is doing.

OK, yes, that is a bit too heavy actually. What I like is to call a
function in parallel with different parameters and in the end combine
the result. That's useful for example with something like chinese
remaindering. The computations mod several primes are completely
independent and should be separated from each other, but it should be
easily possible to combine the results if all parallel computations have
finished.

> Well, I am not aware of a CAS that can work really in parallel fashion.

Certainly a marketing document...

https://www.wolfram.com/mathematica/compare-mathematica/files/ParallelProgrammingMapleMathematica.pdf

but it looks as if there were some features in the direction that I
described above.

Ralf

[Waldek Hebisch]

On Tue, Jun 27, 2023 at 07:37:35PM +0200, Ralf Hemmecke wrote:
> On 27.06.23 16:37, Waldek Hebisch wrote:
> > > Actually, my question is whether it would be possible to clone a running
> > > fricas session and continue with some computation in one clone with at the
> > > same time with another computation in another clone?
> >
> > Well, that is what Unix fork is doing.
>
> OK, yes, that is a bit too heavy actually. What I like is to call a function
> in parallel with different parameters and in the end combine the result.

Basically that is what Open MP is doing. But even with most efficient
implementation this is heavy too.

> That's useful for example with something like chinese remaindering. The
> computations mod several primes are completely independent and should be
> separated from each other, but it should be easily possible to combine the
> results if all parallel computations have finished.

Well, my student did such thing (in C), but that requires appropriate
problem structure and scale.

> > Well, I am not aware of a CAS that can work really in parallel fashion.
>
> Certainly a marketing document...
>
> https://www.wolfram.com/mathematica/compare-mathematica/files/ParallelProgrammingMapleMathematica.pdf
>
> but it looks as if there were some features in the direction that I
> described above.

Well, quickly looking at it I noticed mention of distributing code
between nodes. So this looks like "generate code" approach, which
can be quite good at large scale, but generating code by necessity
takes time which may dominate at small scale. And Monte Carlo
integration is classic example of "embarassingly parallel" code,
which is easy to execute in parallel. Many special problems are
"embarassingly parallel" but general problems solved by CAS usually
are much harder to execute in parallel. So, yes, there is support
for special cases, but not in general.

--
Waldek Hebisch

[Ralf Hemmecke]

On 25.06.23 19:58, Waldek Hebisch wrote:

> On Sun, Jun 25, 2023 at 04:13:46PM +0200, Ralf Hemmecke wrote:
>> Similarly with mathprintWithNumber. But I guess mathPrintWithNumber is too
>> late for the next release.
>
> Well, I was thinking about this. The attached patch should handle this.
>
> Just set '$print_equatnum' to 'false' (Lisp 'nil') to supress equation
> numbers.

I've modified jfricas to work with $print_equatnum.

>> The definition of |interpret-block| would also be a nice addition to FriCAS,
>> since it allows multi-line strings to be interpreted as if coming from a
>> file (with intendation working correctly).
>>
>> https://github.com/hemmecke/jfricas/blob/master/jfricas/webspad.lisp#L102
>
> Yes, it can go in.

Done.

As far as I can see, the connection to jfricas should now work smoothly.

Thank you, Waldek, for making this possible.

From my side I only see fixing of download.rst and install.rst
(INSTALL) (ImageMagick) and removing the problem with a failing sphinx
build of fricas.github.io. I'm afraid that I might not be able to do
this tomorrow. Let's see how I can manage.

I would also take a look at the patch of Peter Broadbery for testing the
FriCAS aldor interface, but maybe this is not totally essential for the
next release.

Ralf

[Ralf Hemmecke]

On 30.06.23 00:20, Ralf Hemmecke wrote:
> From my side I only see fixing of download.rst and install.rst
> (INSTALL) (ImageMagick) and removing the problem with a failing sphinx
> build of fricas.github.io. I'm afraid that I might not be able to do
> this tomorrow. Let's see how I can manage.

Failing sphinx.

This is somewhat of a bad thing that I don't seem to be able to fix
quickly. All I can say is that with verion 4.4.0 of Sphinx, the build of
the fricas html pages goes well. My failing build was with the current
version of sphinx 7.0.1 or something.

No idea what they have changed, but it seems that they are stricter with
testing the content and our ++ docstrings are not in rst format, so I
will probably have to either do lots of changes in the ++ docstrings or
do that automatically via api.spad. But first I would have the cause for
the issue.

Anyway. sphinx 4.4.0 still works and that is good for now.

So... download.rst and install.rst and order minor docfixes have to be done.

Ralf

[Waldek Hebisch]

On Fri, Jun 30, 2023 at 03:03:27PM +0200, Ralf Hemmecke wrote:
> On 30.06.23 00:20, Ralf Hemmecke wrote:
> > From my side I only see fixing of download.rst and install.rst
> > (INSTALL) (ImageMagick) and removing the problem with a failing sphinx
> > build of fricas.github.io. I'm afraid that I might not be able to do
> > this tomorrow. Let's see how I can manage.
>
> Failing sphinx.
>
> This is somewhat of a bad thing that I don't seem to be able to fix quickly.
> All I can say is that with verion 4.4.0 of Sphinx, the build of the fricas
> html pages goes well. My failing build was with the current version of
> sphinx 7.0.1 or something.
>
> No idea what they have changed, but it seems that they are stricter with
> testing the content and our ++ docstrings are not in rst format, so I will
> probably have to either do lots of changes in the ++ docstrings or do that
> automatically via api.spad. But first I would have the cause for the issue.

I must admit that I do not see why are you using sphinx at all. Looking
at api pages AFACS the actual work done by sphinx look kind of trivial:
it is adding headers and footers and performing bunch of string
substitutions. It looks that we could generate .html essentially
with the same effort that we spent on generating .rst.

> Anyway. sphinx 4.4.0 still works and that is good for now.

Yes.

> So... download.rst and install.rst and order minor docfixes have to be done.

--
Waldek Hebisch

[Waldek Hebisch]

On Fri, Jun 30, 2023 at 03:03:27PM +0200, Ralf Hemmecke wrote:

> So... download.rst and install.rst and order minor docfixes have to be done.

Are you working on this? Concerning download.rst, my idea of download
page was to put there links to appropriate binaries. This is somewhat
fragile info, fully known only after release, so poor fit to be part
of release. I think minimal change would add link to Sourceforge
download page, that is

http://fricas.sf.net/download.html

(which I intend to keep up to date), delete 1.3.6
"up to version 1.3.6" phrase about Sourceforge (or maybe delete
the whole 'files' link to Surceforge, as this is subsumed by
'http://fricas.sf.net/download.html'). Also, there should be
visible link to release at Github, either

https://github.com/fricas/fricas/releases

or

https://github.com/fricas/fricas/releases/tag/1.3.9

(assuming that Github will not change its naming scheme).


Concerning decumentation build in install.rst
I would write something like this:

Building documentation
^^^^^^^^^^^^^^^^^^^^^^

After a build of FriCAS, (suppose your build directory is under
``$BUILD``), you can build extra documentation.

To build extra documention you need working 'convert' program
from ImageMagick. Note that several Linux distribution currently
disable ability to create .ps files via 'convert'. If your
distribution is doing this build of extra documention will fail.

Currently building .html pages only works with Sphinx 4.4.0.
Use this version or only build FriCAS book via
::
cd $BUILD/src/doc
make book.pdf

The |home page| can be built via
::

...

--
Waldek Hebisch

[Dima Pasechnik]

On Sat, Jul 1, 2023 at 7:55 PM Waldek Hebisch
<de...@fricas.math.uni.wroc.pl> wrote:
>
> On Fri, Jun 30, 2023 at 03:03:27PM +0200, Ralf Hemmecke wrote:
> > So... download.rst and install.rst and order minor docfixes have to be done.
>
> Are you working on this? Concerning download.rst, my idea of download
> page was to put there links to appropriate binaries. This is somewhat
> fragile info, fully known only after release, so poor fit to be part
> of release. I think minimal change would add link to Sourceforge
> download page, that is
>
> http://fricas.sf.net/download.html
>
> (which I intend to keep up to date), delete 1.3.6
> "up to version 1.3.6" phrase about Sourceforge (or maybe delete
> the whole 'files' link to Surceforge, as this is subsumed by
> 'http://fricas.sf.net/download.html'). Also, there should be
> visible link to release at Github, either
>
> https://github.com/fricas/fricas/releases
>
> or
>
> https://github.com/fricas/fricas/releases/tag/1.3.9
>
> (assuming that Github will not change its naming scheme).

Tag names for GitHub releases are fully within the user control.
They are actually git tags.

>
>
> Concerning decumentation build in install.rst
> I would write something like this:
>
> Building documentation
> ^^^^^^^^^^^^^^^^^^^^^^
>
> After a build of FriCAS, (suppose your build directory is under
> ``$BUILD``), you can build extra documentation.
>
> To build extra documention you need working 'convert' program
> from ImageMagick. Note that several Linux distribution currently
> disable ability to create .ps files via 'convert'. If your
> distribution is doing this build of extra documention will fail.
>
> Currently building .html pages only works with Sphinx 4.4.0.
> Use this version or only build FriCAS book via
> ::
> cd $BUILD/src/doc
> make book.pdf
>
> The |home page| can be built via
> ::
>
> ...
>
> --
> Waldek Hebisch
>

> --
> 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 on the web visit https://groups.google.com/d/msgid/fricas-devel/ZKB2dRGH2SEKRYya%40fricas.math.uni.wroc.pl.

[Ralf Hemmecke]

>> So... download.rst and install.rst and order minor docfixes have to be done.
>
> Are you working on this?

Yes. I already have nearly everything, but need to clean up and reread.
I will put something to my repo soon. Unfortunately, I am on travel and
family affairs interrupt me quite a bit.

> Concerning download.rst, my idea of download
> page was to put there links to appropriate binaries.

I will use

https://github.com/fricas/fricas/releases/

Since we are at github, this should now be the official place of release.

Ralf

[Waldek Hebisch]

On Sun, Jul 02, 2023 at 12:02:31AM +0200, Ralf Hemmecke wrote:
>
> Yes. I already have nearly everything, but need to clean up and reread. I
> will put something to my repo soon. Unfortunately, I am on travel and family
> affairs interrupt me quite a bit.
>
> > Concerning download.rst, my idea of download
> > page was to put there links to appropriate binaries.
>
> I will use
>
> https://github.com/fricas/fricas/releases/
>
> Since we are at github, this should now be the official place of release.

I see no reason to discriminate against Sourceforge, for download
people should use place that is more convenient. For other things
Sourceforge site has links to Github, so there should be no
confusion if somebody comes to Sourceforge first.

--
Waldek Hebisch

[Ralf Hemmecke]

Since I will most probably have no further time till Monday, I prepared
the install.rst and download.rst now.

You can find it in my github repo in branch wip/rst.

https://github.com/hemmecke/fricas/tree/wip/rst/src/doc/sphinx/source

The rendered pages are at

https://hemmecke.github.io/fricas/index.html

A few words to jFriCAS. I have put quite a lot of installation details
into install.rst. If this is not wanted, we can shorten this and I move
this part into the jfricas repository.

Good night
Ralf