FriCAS and GCL

[Waldek Hebisch]

I have now removed part of old GCL-specific code. This probably
means that FriCAS can not be build with GCL versions earlier
than GCL-2.6.13. On plus side, after that one gets sensible
error messages and one can do build from Lisp files. Algebra
bootstrap fails, I have tracked problem to missing or wrong
DATABASE property on |BasicType|. This probably indicates
some deeper problem.

Running testsuite on FriCAS build from Lisp files shows one
failure: apparently FriCAS on GCL can not catch numeric errors.

Also, FriCAS now uses ANSI Lisp code instead of old GCL-specific
code, so this requires enough ANSI support in GCL. I only tried
ANSI GCL, I do not know if "traditional" GCL would work.

BTW: The following gets around problem with loading to large
heap. I am not sure if this is right solution:

--- trunk/src/lisp/Makefile.in 2022-07-16 14:43:58.443666098 +0200
+++ dist/src/lisp/Makefile.in 2023-02-11 15:36:50.248556407 +0100
@@ -68,7 +68,8 @@
' (compiler::emit-fn t))' \
' (when (fboundp (quote si::sgc-on))' \
' (si::sgc-on nil))' \
- ' (setq compiler::*default-system-p* t))"' \
+ ' (setq compiler::*default-system-p* t)' \
+ ' (setq compiler::*default-large-memory-model-p* t))"' \
' si::*system-directory* (quote (list ".lsp")))' \
' "$(lisp_c_objects) $(fricas_c_runtime_extra)")' \
| $(FRICAS_LISP)

--
Waldek Hebisch

[Camm Maguire]

Greetings!

Think I've spotted this:

daase.lisp:

; #-:GCL
(setq nrlibdirs (directory "*.NRLIB/index.KAF"))

#| directory in GCL (at least gcl-2.6.8) on Windows is buggy,
it can not handle pathnames having wildcards in the middle,
so we need a workaround. |#
; #+:GCL
; (setq nrlibdirs
; (mapcar #'(lambda (f)
; (concatenate 'string (namestring f)
; "/index.KAF"))
; (directory "*.NRLIB")))

Testing now. Happy to commit when I'm enabled.

This will work, but might be slower than needed. Will look at this too.

Take care,
--
Camm Maguire ca...@maguirefamily.org
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah

[Camm Maguire]

Greetings! This seems to work, but not I'm getting "Cannot connect to
FRICAS server" in sman during the doc build stage. Any suggestions?

Take care,

[Ralf Hemmecke]

On 12.02.23 19:37, Camm Maguire wrote:
> Greetings! This seems to work, but not I'm getting "Cannot connect to
> FRICAS server" in sman during the doc build stage. Any suggestions?

I'm not sure whether I should take care of this, but since I do not know
exactly where in the build process this happens ("doc build stage" it
too vague for me), I cannot say anything.
What exactly do you want to build?

Ralf

[Waldek Hebisch]

On Sun, Feb 12, 2023 at 01:37:58PM -0500, Camm Maguire wrote:
> Greetings! This seems to work, but not I'm getting "Cannot connect to
> FRICAS server" in sman during the doc build stage. Any suggestions?

Do you mean:

session: Cannot connect to FriCAS server!

The actual connection is done in src/lib/sockio-c.c, in function
'connect_to_local_server' starting at line 772. There is not
much which can go wrong here. Normally there should be error
message explaing reason for failure. Of course, if there is
error message one should look at it. At first glance only way
to get failure without extra error message is when 'configure'
decides that there are no Unix domain sockets on the machine.
For this one should check if 'config/fricas_c_macros.h' in build
directory contains line:

#define HAVE_SOCKADDR_UN 1


--
Waldek Hebisch

[Camm Maguire]

Greetings!

Bingo, HAVE_SOCKADDR_UN was missing for some reason. Retesting now and
everything passes.

Please let me know if you would like to maintain compatibility with
gcl-2.6.12. By default, I'll assume the gcl conditionals should reflect
>= 2.6.13.

Take care,

[Waldek Hebisch]

On Mon, Feb 13, 2023 at 10:16:37AM -0500, Camm Maguire wrote:
> Greetings!
>

> Bingo, HAVE_SOCKADDR_UN was missing for some reason. Retesting now and
> everything passes.
>
> Please let me know if you would like to maintain compatibility with
> gcl-2.6.12. By default, I'll assume the gcl conditionals should reflect
> >= 2.6.13.

I think that keeping compatiblity with gcl-2.6.12 would be too
problematic. So yes, >= 2.6.13.

--
Waldek Hebisch

[Camm Maguire]

Greetings! Great! Do we also agree it is a win in general to incur a
little more package build time in exchange for a more compact final
image set for optimal user performance?

Take care,

Waldek Hebisch <de...@fricas.math.uni.wroc.pl> writes:

[Waldek Hebisch]

On Tue, Feb 14, 2023 at 12:48:55PM -0500, Camm Maguire wrote:
> Greetings! Great! Do we also agree it is a win in general to incur a
> little more package build time in exchange for a more compact final
> image set for optimal user performance?

Direct answer is yes. However, the issue is somewhat more
complex. One extra thing is debugability. Related is
robustness. To illustrate, in 'src/interp/interp-proclaims.lisp'
we currently have:

#+:GCL
(progn
(eval-when (:execute :compile-toplevel :load-toplevel)
(proclaim '(optimize (safety 1) (debug 3)))))

This was needed because at safety 0 we got essentially
undebugable failures (and at safety 1 failures were gone
with no hint what could be wrong at safety 0).

Another thing is retaining flexibility. Performance-critical
code in FriCAS is dynamicaly loaded. Dynamic loading of
course is bad for perfomance, but is essential to smooth
developement. And most functions are called in indirect
way. I am not sure how much GCL can optimize this.
In principle this should be easy: "just" generate
"corresponding" C code, that is take advantage of
fact that Spad calls need no special Lisp call processing,
note that Lisp types in Spad code can be mapped to C types
and pass type declarations to C.

The point of above is: if the only tradeof is between compile
time and run time, then it makes sense to turn on aggresive
optimization. But I suspect that there are other effects.
For example, extra code in Makefile or limited debugability
are likely to use extra developement time that could be spend
on other things. And for Lisp code generated by Spad compiler
good optimizations are unlikely to require much time.

--
Waldek Hebisch