Proof of concept: use FRICASTERM environment variable for HyperDoc:

[Grégory Vanuxem]

Hello,

Attached are two very simple patches to use another terminal emulator
for HyperDoc using an environment variable FRICASTERM.

On my system TERM is also defined but wrongly defined. I mimicked
FRICASEDITOR to let the user choose the one for FriCAS in HyperDoc.
On my system I have:

└─$ update-alternatives --config x-terminal-emulator
There are 6 choices for the alternative x-terminal-emulator (providing
/usr/bin/x-terminal-emulator).

Selection Path Priority Status
------------------------------------------------------------
0 /usr/bin/qterminal 40 auto mode
1 /usr/bin/koi8rxterm 20 manual mode
2 /usr/bin/lxterm 30 manual mode
* 3 /usr/bin/mate-terminal.wrapper 35 manual mode
4 /usr/bin/qterminal 40 manual mode
5 /usr/bin/uxterm 20 manual mode
6 /usr/bin/xterm 20 manual mode

Press <enter> to keep the current choice[*], or type selection number:

qterminal does not support HyperDoc commands and mate-terminal.wrapper
is a Perl wrapper to support xterm commands apparently. This wrapper
is provided by the mate-terminal team. If FRICASTERM is not defined
xterm is used.

Regards,

- Greg

[Waldek Hebisch]

On Wed, Dec 25, 2024 at 07:28:16PM +0100, Grégory Vanuxem wrote:
> Hello,
>
> Attached are two very simple patches to use another terminal emulator
> for HyperDoc using an environment variable FRICASTERM.
>
> On my system TERM is also defined but wrongly defined. I mimicked
> FRICASEDITOR to let the user choose the one for FriCAS in HyperDoc.

For me it looks mostly OK. One style remark: it is better to
write:

char *TERM = getenv("FRICASTERM");

that is declare and initialize variable in one shot, instead of
a separate assignment later.

> There are 6 choices for the alternative x-terminal-emulator (providing
> /usr/bin/x-terminal-emulator).
>
> Selection Path Priority Status
> ------------------------------------------------------------
> 0 /usr/bin/qterminal 40 auto mode
> 1 /usr/bin/koi8rxterm 20 manual mode
> 2 /usr/bin/lxterm 30 manual mode
> * 3 /usr/bin/mate-terminal.wrapper 35 manual mode
> 4 /usr/bin/qterminal 40 manual mode
> 5 /usr/bin/uxterm 20 manual mode
> 6 /usr/bin/xterm 20 manual mode
>
> Press <enter> to keep the current choice[*], or type selection number:
>
> qterminal does not support HyperDoc commands and mate-terminal.wrapper
> is a Perl wrapper to support xterm commands apparently. This wrapper
> is provided by the mate-terminal team. If FRICASTERM is not defined
> xterm is used.

IIUC of the above, 'koi8rxterm', 'lxterm', 'uxterm' are just 'xterm'
with extra flags. So that leaves 'qterminal' and 'mate-terminal.wrapper'
as two potentially different terminals. You write that 'qterminal'
does not work. Do I understand correctly that 'mate-terminal.wrapper'
works? And what is to wrapping? In particular, is it really different
from 'xterm'?

On my machine the only really different termianal emulator is
'lxterminal' and it apparently does not work with HyperDoc.

--
Waldek Hebisch

[Dima Pasechnik]

On Wednesday, December 25, 2024 at 12:28:56 PM UTC-6 g.va...@gmail.com wrote:

Hello,

Attached are two very simple patches to use another terminal emulator
for HyperDoc using an environment variable FRICASTERM.

On my system TERM is also defined but wrongly defined. I mimicked
FRICASEDITOR to let the user choose the one for FriCAS in HyperDoc.
On my system I have:

└─$ update-alternatives --config x-terminal-emulator
There are 6 choices for the alternative x-terminal-emulator (providing
/usr/bin/x-terminal-emulator).

Selection Path Priority Status
------------------------------------------------------------
0 /usr/bin/qterminal 40 auto mode
1 /usr/bin/koi8rxterm 20 manual mode
2 /usr/bin/lxterm 30 manual mode
* 3 /usr/bin/mate-terminal.wrapper 35 manual mode
4 /usr/bin/qterminal 40 manual mode
5 /usr/bin/uxterm 20 manual mode
6 /usr/bin/xterm 20 manual mode

Press <enter> to keep the current choice[*], or type selection number:

qterminal does not support HyperDoc commands and mate-terminal.wrapper
is a Perl wrapper to support xterm commands apparently.

mate-terminal.wrapper is a shell script to launch mate-terminal. The latter is a fork of gnome-terminal

(using an older version of Gnome toolkit, GTK, namely, version 2)

[Dima Pasechnik]

it is different. It's using a newer widgets toolkit, as opposed to the really ancient, Athena

toolkit used by xterm (libAw).

AFAIK, no modern terminal emulator uses Athena toolkit. Major flavours which are used are: GTK-based, Qt based, and KDE-based.

[Grégory Vanuxem]

Hello,

Le ven. 27 déc. 2024 à 03:17, Waldek Hebisch <de...@fricas.org> a écrit :
>
> On Wed, Dec 25, 2024 at 07:28:16PM +0100, Grégory Vanuxem wrote:
> > Hello,
> >
> > Attached are two very simple patches to use another terminal emulator
> > for HyperDoc using an environment variable FRICASTERM.
> >
> > On my system TERM is also defined but wrongly defined. I mimicked
> > FRICASEDITOR to let the user choose the one for FriCAS in HyperDoc.
>
> For me it looks mostly OK. One style remark: it is better to
> write:
>
> char *TERM = getenv("FRICASTERM");

I attached a patch using this recommendation.

I tested gnome-terminal.wrapper, mate-terminal.wrapper, xterm*, rxvt*,
lxterm they all work. But for example qterminal, lxterminal or
terminology (enlightenment terminal) don't support the parameters
given. The mate or gnome wrappers are scripts with a Perl shebang
(Perl code). For example pure mate-terminal is not supported with the
message "Failed to parse arguments: Unknown option -sb". The wrapper
is here:

https://github.com/mate-desktop/mate-terminal/blob/master/mate-terminal.wrapper

So yes, using other terminals works, with small modifications, and
some of course are more user-friendly to configure (gnome-terminal,
mate-terminal and others I think).

- Greg

PS: I also attached a screenshot and a patch for src/etc/SPADEDIT. Not
for the pamphlet file, I do not have the build machinery for it.

[Camm Maguire]

Greetings! Just about finished getting fricas to work with the
forthcoming new GCL release.

This GCL version tries to be strict about enforcing
call-arguments-limit, which has always been 64. I get the following
when compiling SULS.spad. Somewhere an apply of '|Join| needs to be
replaced with reduce. Any suggestions of where to look?

Take care,

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

Broken at SYSTEM::BREAK-LEVEL.
Condition in |Join| [or a callee]: INTERNAL-SIMPLE-PROGRAM-ERROR: NIL [or a callee] requires less than sixty-eight arguments.

Broken at SYSTEM::BREAK-LEVEL. Type :H for Help.
1 Return to top level.
BOOT>>(si::fle '|Join|)

(LAMBDA (&REST L) (BLOCK |Join| (BLOCK NIL #)))
NIL
|Join|
BOOT>>(setq *print-pretty* t *print-length* nil *print-level* nil)

NIL
BOOT>>(si::fle '|Join|)

(LAMBDA
(&REST L)
(BLOCK
|Join|
(BLOCK NIL (LET NIL (TAGBODY (RETURN-FROM NIL (|JoinInner| L)))))))
NIL
|Join|
BOOT>>:fr 1

#1 Join {loc0=#<vector 0000000002ada8c0>,loc1=#<vector 0000000004eb1a20>,loc2=#<vector 0...} [ihs=68]
BOOT>>:bl
>> Join():
Local(0): #<vector 0000000002ada8c0>
Local(1): #<vector 0000000004eb1a20>
Local(2): #<vector 0000000004eb1b10>
Local(3): #<vector 0000000004eb1c00>
Local(4): #<vector 0000000004eb1cf0>
Local(5): #<vector 0000000004eb1de0>
Local(6): #<vector 0000000004eb1ed0>
Local(7): #<vector 0000000004eb1fc0>
Local(8): #<vector 0000000004eb20c0>
Local(9): #<vector 0000000004eb21b0>
Local(10): #<vector 0000000004eb22a0>
Local(11): #<vector 0000000004eb2390>
Local(12): #<vector 0000000004eb2480>
Local(13): #<vector 0000000004eb2570>
Local(14): #<vector 0000000004eb2660>
Local(15): #<vector 0000000004eb2750>
Local(16): #<vector 0000000004eb2840>
Local(17): #<vector 0000000004eb2930>
Local(18): #<vector 0000000004eb2a20>
Local(19): #<vector 0000000004eb2b10>
Local(20): #<vector 0000000004eb2c00>
Local(21): #<vector 0000000004eb2cf0>
Local(22): #<vector 0000000004eb2de0>
Local(23): #<vector 0000000004eb2ed0>
Local(24): #<vector 0000000004eb2fc0>
Local(25): #<vector 0000000004eb30c0>
Local(26): #<vector 0000000004eb31b0>
Local(27): #<vector 0000000004eb32a0>
Local(28): #<vector 0000000004eb3390>
Local(29): #<vector 0000000004eb3480>
Local(30): #<vector 0000000004eb3570>
Local(31): #<vector 0000000004eb3660>
Local(32): #<vector 0000000004eb3750>
Local(33): #<vector 0000000004eb3840>
Local(34): #<vector 0000000004eb3930>
Local(35): #<vector 0000000004eb3a20>
Local(36): #<vector 0000000004eb3b10>
Local(37): #<vector 0000000004eb3c00>
Local(38): #<vector 0000000004eb3cf0>
Local(39): #<vector 0000000004eb3de0>
Local(40): #<vector 0000000004eb3ed0>
Local(41): #<vector 0000000004eb3fc0>
Local(42): #<vector 0000000004eb40c0>
Local(43): #<vector 0000000004eb41b0>
Local(44): #<vector 0000000004eb42a0>
Local(45): #<vector 0000000004eb4390>
Local(46): #<vector 0000000004eb4480>
Local(47): #<vector 0000000004eb4570>
Local(48): #<vector 0000000004eb4660>
Local(49): #<vector 0000000004eb4750>
Local(50): #<vector 0000000004eb4840>
Local(51): #<vector 0000000004eb4930>
Local(52): #<vector 0000000004eb4a20>
Local(53): #<vector 0000000004eb4b10>
Local(54): #<vector 0000000004eb4c00>
Local(55): #<vector 0000000004eb4cf0>
Local(56): #<vector 0000000004eb4de0>
Local(57): #<vector 0000000004eb4ed0>
Local(58): #<vector 0000000004eb4fc0>
Local(59): #<vector 0000000004eb50c0>
Local(60): #<vector 0000000004eb51b0>
Local(61): #<vector 0000000004eb52a0>
Local(62): #<vector 0000000004eb5390>
Local(63): #<vector 0000000004eb5480>
Local(64): #<vector 0000000004eb5570>
Local(65): #<vector 0000000004eb5660>
Local(66): #<vector 0000000004eb5750>
Local(67): #<vector 0000000004eb5840>
NIL
BOOT>>:bt

#0 INVOKE-DEBUGGER {loc0=#<conditions::internal-simple-program-error.0>} [ihs=70]
#1 Join {loc0=#<vector 0000000002ada8c0>,loc1=#<vector 0000000004eb1a20>,loc2=#<vector 0...} [ihs=68]
#2 EVAL {loc0=nil,loc1=nil,loc2=nil,loc3=#<function 00000000173468b0>} [ihs=67]
#3 eval {loc0=(|Join| (|UnivariateLaurentSeriesConstructorCategory| (quote |Coef|) (quot...} [ihs=66]
#4 c_eval {loc0=(|Join| (|UnivariateLaurentSeriesConstructorCategory| (quote |Coef|) (quot...} [ihs=65]
#5 compMakeCategoryObject {loc0=(|Join| (|UnivariateLaurentSeriesConstructorCategory| |Coef| (|SparseUniva...} [ihs=64]
#6 getViewsConditions {loc0=(|Join| (|UnivariateLaurentSeriesConstructorCategory| |Coef| (|SparseUniva...} [ihs=63]
#7 InvestigateConditions {loc0=((|Join| (|UnivariateLaurentSeriesConstructorCategory| |Coef| #) (category...} [ihs=62]
#8 buildFunctor {loc0=(|SparseUnivariateLaurentSeries| |Coef| |var| ...),loc1=((|Join| (|Univari...} [ihs=61]
#9 processFunctor {loc0=(|SparseUnivariateLaurentSeries| |Coef| |var| ...),loc1=((|Join| (|Univari...} [ihs=60]
#10 compCapsuleInner {loc0=((qsetrefv % 9 ...) (|CodeDefine| (|variable| #) (|dispatchFunction| |SULS...} [ihs=59]
#11 compCapsule {loc0=(capsule (qsetrefv % 9 ...) (|CodeDefine| (|variable| #) (|dispatchFunctio...} [ihs=58]
#12 compAdd {loc0=(|add| (|InnerSparseUnivariatePowerSeries| |Coef|) (capsule (qsetrefv % 9 ...} [ihs=57]
#13 compExpression {loc0=(|add| (|InnerSparseUnivariatePowerSeries| |Coef|) (capsule (qsetrefv % 9 ...} [ihs=56]
#14 comp3 {loc0=(|add| (|InnerSparseUnivariatePowerSeries| |Coef|) (capsule (qsetrefv % 9 ...} [ihs=55]
#15 comp2 {loc0=(|add| (|InnerSparseUnivariatePowerSeries| |Coef|) (capsule (qsetrefv % 9 ...} [ihs=54]
#16 compNoStacking {loc0=(|add| (|InnerSparseUnivariatePowerSeries| |Coef|) (capsule (qsetrefv % 9 ...} [ihs=53]
#17 comp {loc0=(|add| (|InnerSparseUnivariatePowerSeries| |Coef|) (capsule (qsetrefv % 9 ...} [ihs=52]
#18 compOrCroak1,fn {loc0=(|add| (|InnerSparseUnivariatePowerSeries| |Coef|) (capsule (qsetrefv % 9 ...} [ihs=51]
#19 compOrCroak1 {loc0=(|add| (|InnerSparseUnivariatePowerSeries| |Coef|) (capsule (qsetrefv % 9 ...} [ihs=50]
#20 compOrCroak {loc0=(|add| (|InnerSparseUnivariatePowerSeries| |Coef|) (capsule (qsetrefv % 9 ...} [ihs=49]
#21 compFunctorBody {loc0=(|add| (|InnerSparseUnivariatePowerSeries| |Coef|) (capsule (qsetrefv % 9 ...} [ihs=48]
#22 compDefineFunctor1 {loc0=(def (|SparseUnivariateLaurentSeries| |Coef| |var| ...) ((|Join| # #) nil ...} [ihs=47]
#23 compDefineLisplib {loc0=(def (|SparseUnivariateLaurentSeries| |Coef| |var| ...) ((|Join| # #) nil ...} [ihs=46]
#24 compDefineFunctor {loc0=(def (|SparseUnivariateLaurentSeries| |Coef| |var| ...) ((|Join| # #) nil ...} [ihs=45]
#25 compDefine1 {loc0=(def (|SparseUnivariateLaurentSeries| |Coef| |var| ...) ((|Join| # #) nil ...} [ihs=44]
#26 compDefine {loc0=(def (|SparseUnivariateLaurentSeries| |Coef| |var| ...) ((|Join| # #) nil ...} [ihs=43]
#27 compExpression {loc0=(def (|SparseUnivariateLaurentSeries| |Coef| |var| ...) ((|Join| # #) nil ...} [ihs=42]
#28 comp3 {loc0=(def (|SparseUnivariateLaurentSeries| |Coef| |var| ...) ((|Join| # #) nil ...} [ihs=41]
#29 comp2 {loc0=(def (|SparseUnivariateLaurentSeries| |Coef| |var| ...) ((|Join| # #) nil ...} [ihs=40]
#30 compNoStacking {loc0=(def (|SparseUnivariateLaurentSeries| |Coef| |var| ...) ((|Join| # #) nil ...} [ihs=39]
#31 comp {loc0=(def (|SparseUnivariateLaurentSeries| |Coef| |var| ...) ((|Join| # #) nil ...} [ihs=38]
#32 compWhere {loc0=(|where| (def (|SparseUnivariateLaurentSeries| |Coef| |var| ...) (# nil ni...} [ihs=37]
#33 compExpression {loc0=(|where| (def (|SparseUnivariateLaurentSeries| |Coef| |var| ...) (# nil ni...} [ihs=36]
#34 comp3 {loc0=(|where| (def (|SparseUnivariateLaurentSeries| |Coef| |var| ...) (# nil ni...} [ihs=35]
#35 comp2 {loc0=(|where| (def (|SparseUnivariateLaurentSeries| |Coef| |var| ...) (# nil ni...} [ihs=34]
#36 compNoStacking {loc0=(|where| (def (|SparseUnivariateLaurentSeries| |Coef| |var| ...) (# nil ni...} [ihs=33]
#37 comp {loc0=(|where| (def (|SparseUnivariateLaurentSeries| |Coef| |var| ...) (# nil ni...} [ihs=32]
#38 compDefWhereClause {loc0=(def (|SparseUnivariateLaurentSeries| |Coef| |var| ...) ((|Join| # #) (|Ri...} [ihs=31]
#39 compDefine1 {loc0=(def (|SparseUnivariateLaurentSeries| |Coef| |var| ...) ((|Join| # #) (|Ri...} [ihs=30]
#40 compDefine {loc0=(def (|SparseUnivariateLaurentSeries| |Coef| |var| ...) ((|Join| # #) (|Ri...} [ihs=29]
#41 compExpression {loc0=(def (|SparseUnivariateLaurentSeries| |Coef| |var| ...) ((|Join| # #) (|Ri...} [ihs=28]
#42 comp3 {loc0=(def (|SparseUnivariateLaurentSeries| |Coef| |var| ...) ((|Join| # #) (|Ri...} [ihs=27]
#43 comp2 {loc0=(def (|SparseUnivariateLaurentSeries| |Coef| |var| ...) ((|Join| # #) (|Ri...} [ihs=26]
#44 compNoStacking {loc0=(def (|SparseUnivariateLaurentSeries| |Coef| |var| ...) ((|Join| # #) (|Ri...} [ihs=25]
#45 comp {loc0=(def (|SparseUnivariateLaurentSeries| |Coef| |var| ...) ((|Join| # #) (|Ri...} [ihs=24]
#46 compOrCroak1,fn {loc0=(def (|SparseUnivariateLaurentSeries| |Coef| |var| ...) ((|Join| # #) (|Ri...} [ihs=23]
#47 compOrCroak1 {loc0=(def (|SparseUnivariateLaurentSeries| |Coef| |var| ...) ((|Join| # #) (|Ri...} [ihs=22]
#48 compOrCroak {loc0=(def (|SparseUnivariateLaurentSeries| |Coef| |var| ...) ((|Join| # #) (|Ri...} [ihs=21]
#49 compTopLevel {loc0=(def (|SparseUnivariateLaurentSeries| |Coef| |var| ...) ((|Join| # #) (|Ri...} [ihs=20]
#50 S_process {loc0=(|where| (== (|:| # |Exports|) |Implementation|) (|;| (|;| # #) (==> |Impl...} [ihs=19]
#51 fakeloopProcess1 {loc0=((|id| |SparseUnivariateLaurentSeries| 0 ...) (|key| |(| 29 ...) (|id| |Co...} [ihs=18]
#52 fakeloopProcess {loc0=nil,loc1=(((# #) (# # # ...)) ((# #) (# # # ...)) |nonnullstream| ...)} [ihs=17]
#53 fakeloopInclude0 {loc0=#<input stream #P"/mnt/sda4/debian/fricas/src/algebra/SULS.spad">,loc1="/m...} [ihs=16]
#54 handle_input_file {loc0="/mnt/sda4/debian/fricas/src/algebra/SULS.spad",loc1=#<function 0000000017...} [ihs=15]
#55 fakeloopInclude {loc0="/mnt/sda4/debian/fricas/src/algebra/SULS.spad",loc1=nil} [ihs=14]
#56 spadCompile1 {loc0="/mnt/sda4/debian/fricas/src/algebra/SULS.spad",loc1=nil} [ihs=13]
#57 spadCompile {loc0="/mnt/sda4/debian/fricas/src/algebra/SULS.spad"} [ihs=12]
#58 read_or_compile {loc0=t,loc1=t} [ihs=11]
#59 compilerDoit {loc0=nil,loc1=(|rq| |lib|)} [ihs=10]
#60 compileSpad2Cmd {loc0=("/mnt/sda4/debian/fricas/src/algebra/SULS.spad")} [ihs=9]
#61 compile {loc0=(|SULS.spad|)} [ihs=8]
#62 systemCommand {loc0=((|compile| |SULS.spad|))} [ihs=7]
#63 tokenSystemCommand {loc0=|compile|,loc1=((|compile| |SULS.spad|))} [ihs=6]
#64 handleTokensizeSystemCommands {loc0=|compile|,loc1=("compile SULS.spad")} [ihs=5]
#65 doSystemCommand {loc0="compile SULS.spad"} [ihs=4]
#66 ExecuteInterpSystemCommand {loc0=")compile SULS.spad"} [ihs=3]
#67 InterpExecuteSpadSystemCommand {loc0=")compile SULS.spad"} [ihs=2]
#68 ncloopCommand {loc0=")compile SULS.spad",loc1=1} [ihs=1]
=============================================================================
--
Camm Maguire ca...@maguirefamily.org
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah

[Waldek Hebisch]

On Fri, Jan 10, 2025 at 01:28:02PM -0500, Camm Maguire wrote:
> Greetings! Just about finished getting fricas to work with the
> forthcoming new GCL release.
>
> This GCL version tries to be strict about enforcing
> call-arguments-limit, which has always been 64. I get the following
> when compiling SULS.spad. Somewhere an apply of '|Join| needs to be
> replaced with reduce. Any suggestions of where to look?

Hmm, I do not see how reduce could help here. 'Join' is used
as a wrapper around 'JoinInner'. 'JoinInner' depends on getting
list of arguments.

> BOOT>>:bt
>
> #0 INVOKE-DEBUGGER {loc0=#<conditions::internal-simple-program-error.0>} [ihs=70]
> #1 Join {loc0=#<vector 0000000002ada8c0>,loc1=#<vector 0000000004eb1a20>,loc2=#<vector 0...} [ihs=68]
> #2 EVAL {loc0=nil,loc1=nil,loc2=nil,loc3=#<function 00000000173468b0>} [ihs=67]
> #3 eval {loc0=(|Join| (|UnivariateLaurentSeriesConstructorCategory| (quote |Coef|) (quot...} [ihs=66]
> #4 c_eval {loc0=(|Join| (|UnivariateLaurentSeriesConstructorCategory| (quote |Coef|) (quot...} [ihs=65]
> #5 compMakeCategoryObject {loc0=(|Join| (|UnivariateLaurentSeriesConstructorCategory| |Coef| (|SparseUniva...} [ihs=64]

This is a very specific code path. 'compMakeCategoryObject' is a function
in 'src/interp/define.boot', 'c_eval' is a function in
'src/interp/util.lisp', 'eval' is also in 'src/interp/util.lisp'.
Lisp form passed to 'c_eval' is produced by 'mkEvalableCategoryForm'
in 'src/interp/lisplib.boot'.

There is similar code path where result of 'mkEvalableCategoryForm'
is passed to 'eval'. For FriCAS categories one needs first use
'mkEvalableCategoryForm' before using 'eval', so basically there
are 3 call sites that pass category expression to Lisp 'EVAL',
all going via 'eval'. In principle 'mkEvalableCategoryForm'
could replace

(Join arg1 arg2 ... argn)

with

(JoinInner (LIST arg1 arg2 ... argn))

if that helps.

'Join' is also called from compiled code (in my developement tree
there are 1165 uses of 'Join' in compiled code, but some are not
calls), I am not sure if those places use large number of arguments.

Concernig bigger picture, internal representation of types in FriCAS
(inherited from Axiom) is as an S-expression which after modest
transformation may be passed to Lisp EVAL. In most cases specific
constructs use small fixed number of arguments. Variable argument
constructs are: 'Join' (the case above), 'Record', 'Union',
'Mapping' and 'Enumeration' (there are also 'RecordCategory',
'UnionCategory' and 'EnumerationCategory'). 'Mapping' represents
types of functions and number of arguments is number of arguments of
corresponding function + 1. So any trouble with 'Mapping'
is likely to appear due to a function exceeding argument limit
(an unlikely event). 'Enumeration' currently is essentially
unused, but in principle could have rather large number of
arguments. I think that currently in FriCAS 'Record' and
'Union' are well below the argument limit, but I have seen in
other languages uses with hundreds of recored fields and that
would exceed the limit. So it would be unnatural to have any
smallish limit on number of arguments to 'Record' and 'Union'.

Currently 'Join' probably can occurr only at top level of an
expression: 'Join' produces a category and categories are
allowed as arguments to 'Join' but not as arguments to other
constructs. And FriCAS code aggressively flattens application
of 'Join'.

Nested inside a type expression can be essentially arbitrary
FriCAS expression. Of those list constructors may have largish
number of arguments, but I hope that this is already handled.

--
Waldek Hebisch

[Waldek Hebisch]

On Sat, Jan 11, 2025 at 01:27:54AM +0100, Waldek Hebisch wrote:
>
> There is similar code path where result of 'mkEvalableCategoryForm'
> is passed to 'eval'. For FriCAS categories one needs first use
> 'mkEvalableCategoryForm' before using 'eval', so basically there
> are 3 call sites that pass category expression to Lisp 'EVAL',
> all going via 'eval'. In principle 'mkEvalableCategoryForm'
> could replace
>
> (Join arg1 arg2 ... argn)
>
> with
>
> (JoinInner (LIST arg1 arg2 ... argn))
>
> if that helps.

I mean the attached patch.

--
Waldek Hebisch

[Camm Maguire]

Greetings, and thank you so much! This appears to have removed the
practical problem for the moment -- great!

Your extremely helpful earlier exposition however indicates the
potential need for large argument lists in the future. Please forgive
me as I have not yet examined the code in any detail, but the naming
seems to indicate that some of these functions might satisfy a property
like

(fn a b c) == (fn (fn a b) c)

(e.g. '|Join|, '|Union|...) You also indicate that you aggressively
'flatten' '|Join| calls, which is also suggestive that '|Join| might
have this property. This was the thinking about suggesting reduce on a
list, which may very well be equivalent to the algorithm of
'|JoinInner|. If there is such flattening going on, one might very
well limit it to call-arguments-limit at that point.

I am experimenting with a list macro at the moment to take care of that
function, which seems to be working. You might be interested to know
that when we were working out similar problems with ACL2, now finished,
the author introduced a list$ macro:

(defmacro list$ (&rest args)

; The logical definitions agree for this macro and list. But in raw Lisp, a
; macro call of list$ expands to a nest of cons calls, which allows GCL version
; 2.7.0 (and presumably later versions) to avoid causing an error when list is
; called on too many arguments.

(list-macro args))

(defun list-macro (lst)
(declare (xargs :guard t))
(if (consp lst)
(cons 'cons
(cons (car lst)
(cons (list-macro (cdr lst)) nil)))
nil))

GCL's compiler then groups this code, valid regardless of
call-arguments-limit, into valid calls to list respecting that limit.
ACL2 had been writing code like that for a long time anyway so it made
eminent sense. I do not know if a similar approach is a good fit for
FRICAS.

Take care,

[Waldek Hebisch]

On Sat, Jan 11, 2025 at 12:14:14PM -0500, Camm Maguire wrote:
> Greetings, and thank you so much! This appears to have removed the
> practical problem for the moment -- great!
>
> Your extremely helpful earlier exposition however indicates the
> potential need for large argument lists in the future. Please forgive
> me as I have not yet examined the code in any detail, but the naming
> seems to indicate that some of these functions might satisfy a property
> like
>
> (fn a b c) == (fn (fn a b) c)
>
> (e.g. '|Join|, '|Union|...) You also indicate that you aggressively
> 'flatten' '|Join| calls, which is also suggestive that '|Join| might
> have this property. This was the thinking about suggesting reduce on a
> list, which may very well be equivalent to the algorithm of
> '|JoinInner|. If there is such flattening going on, one might very
> well limit it to call-arguments-limit at that point.

'Union' is not associative. 'Join' logically is associative, but
internally FriCAS depends on flat form. Also, 'JoinInner' is
rather expensive and trying to do it as a sequence of say binary
calls would lead to redoing much of work, so significantly
worse performance.

> I am experimenting with a list macro at the moment to take care of that
> function, which seems to be working. You might be interested to know
> that when we were working out similar problems with ACL2, now finished,
> the author introduced a list$ macro:
>
> (defmacro list$ (&rest args)
>
> ; The logical definitions agree for this macro and list. But in raw Lisp, a
> ; macro call of list$ expands to a nest of cons calls, which allows GCL version
> ; 2.7.0 (and presumably later versions) to avoid causing an error when list is
> ; called on too many arguments.

ATM for 'LIST' I prefer shadowing 'LIST' from "COMMON-LISP" package
(FriCAS uses are in BOOT package). There are several cases where
FriCAS uses variation of Common Lisp functions under changed name
and while workable they cause some maintainence burden. It looks
for me that shadowing can give needed effect with least effort.

BTW: I have added a test for file operations and currently there
are several failures in GCL based FriCAS. One issue is that
FriCAS creates specialised array with element type '(UNSIGNED-BYTE 32)'.
GCL reports element type of the array as 'FIXNUM' and type
tests that FriCAS uses consider 'FIXNUM' as different from
'(UNSIGNED-BYTE 32)'. When reading from files FriCAS needs to
re-create array type, so currently writing of such arrays
fails. I can add 'FIXNUM' to the list of array element types
considerd by FriCAS, but I a bit worried if this does not lead
to wrong code somewhere else: FriCAS type machinery "knows"
that element type is '(UNSIGNED-BYTE 32)' and uses this type
for in declarations passed to Lisp. If I re-create the array
with element type 'FIXNUM', then formally types do not match
and there is potential for miscompilation. So, the question
is if specialized array having 'FIXNUM' as element type
is the same as specialized array having '(UNSIGNED-BYTE 32)'
as element type.

The second problem is that apparently GCL does not flush file
buffers on 'CLOSE'. Do I need to call 'FINISH-OUTPUT' before
'CLOSE'?

The third problem is that apparently GCL writes wrong thing
which it can not read back. The Lisp expression is somewhat
complex, one can reproduce this from recent FriCAS using:

kf := open("ts_kaf", "output")$KeyedAccessFile(None)
a3 : EXPR(INT) := exp(x) - 1
kf("a3") := a3 pretend None

After that file 'ts_kaf/index.KAF' contains apparently wrong
S-expression. Reading it back via:

kr3 := kf("a3") pretend EXPR(INT)

gives:

>> System error:
SIMPLE-ERROR: #2= multiply defined

and '#2' indeed seem to be multiply defined.

I wrote "recent" FriCAS because there were changes on FriCAS
side which fixed some probles (and potentially may introduce
new bugs). However this problem is also present in GCL
compiled FriCAS 1.3.11.

--
Waldek Hebisch

[Camm Maguire]

Greetings, and please excuse the delayed reply.

Waldek Hebisch <de...@fricas.org> writes:

> BTW: I have added a test for file operations and currently there
> are several failures in GCL based FriCAS. One issue is that
> FriCAS creates specialised array with element type '(UNSIGNED-BYTE 32)'.
> GCL reports element type of the array as 'FIXNUM' and type
> tests that FriCAS uses consider 'FIXNUM' as different from
> '(UNSIGNED-BYTE 32)'. When reading from files FriCAS needs to
> re-create array type, so currently writing of such arrays
> fails. I can add 'FIXNUM' to the list of array element types
> considerd by FriCAS, but I a bit worried if this does not lead
> to wrong code somewhere else: FriCAS type machinery "knows"
> that element type is '(UNSIGNED-BYTE 32)' and uses this type
> for in declarations passed to Lisp. If I re-create the array
> with element type 'FIXNUM', then formally types do not match
> and there is potential for miscompilation. So, the question
> is if specialized array having 'FIXNUM' as element type
> is the same as specialized array having '(UNSIGNED-BYTE 32)'
> as element type.

In GCL 2.6.14, the array element types created when passing
:element-type '(unsigned-byte 32) or :element-type 'fixnum to make-array
are the same, and are indistinguishable if all the elements are.

In 2.7.0, there is a separate type for the former. In general, in ANSI
cl, implementations must "upgrade" element-types to a fixed lattice
set, so you really only get the result of (upgrade-array-element-type
type). On 64bit machines, in 2.7.0 the element types take 4 and 8 bytes
respectively, while in 2.6.14 both take 8. You should be able to read
and write these arrays without error in both cases. You won't be able
to retrieve the element type you used to make the array with
(array-element-type array), but rather just the upgraded type. This is
always the case in any lisp.

>
> The second problem is that apparently GCL does not flush file
> buffers on 'CLOSE'. Do I need to call 'FINISH-OUTPUT' before
> 'CLOSE'?

Do you have an example I can look into?

>
> The third problem is that apparently GCL writes wrong thing
> which it can not read back. The Lisp expression is somewhat
> complex, one can reproduce this from recent FriCAS using:
>
> kf := open("ts_kaf", "output")$KeyedAccessFile(None)
> a3 : EXPR(INT) := exp(x) - 1
> kf("a3") := a3 pretend None
>
> After that file 'ts_kaf/index.KAF' contains apparently wrong
> S-expression. Reading it back via:
>

I can confirm this, and that it is absent in 2.7.0. I will investigate
a patch and get back to you.

Take care,

> kr3 := kf("a3") pretend EXPR(INT)
>
> gives:
>
> >> System error:
> SIMPLE-ERROR: #2= multiply defined
>
> and '#2' indeed seem to be multiply defined.
>
> I wrote "recent" FriCAS because there were changes on FriCAS
> side which fixed some probles (and potentially may introduce
> new bugs). However this problem is also present in GCL
> compiled FriCAS 1.3.11.
>
> --
> Waldek Hebisch

[Camm Maguire]

Greetings, and one more question --

My build is now hanging waiting for input here:

unset DAASE; HTPATH=. FRICAS_INITFILE='' /mnt/sda4/debian/fricas/target/x86_64-linux-gnu/bin/sman -noihere -paste exdiff.ht
openServer result 0
FriCAS Computer Algebra System
Version: FriCAS 2022-07-16
Timestamp: Fri Jan 17 01:59:52 PM EST 2025
-----------------------------------------------------------------------------
Issue )copyright to view copyright notices.
Issue )summary for a summary of useful system commands.
Issue )quit to leave FriCAS and return to shell.
-----------------------------------------------------------------------------


making exdiff.input
parsing: ExDiffBasic
writing: differentiate(sin(x) * exp(x^2),x)

Thoughts?

Take care,

[Waldek Hebisch]

On Fri, Jan 17, 2025 at 03:02:46PM -0500, Camm Maguire wrote:
> Greetings, and one more question --
>
> My build is now hanging waiting for input here:
>
> unset DAASE; HTPATH=. FRICAS_INITFILE='' /mnt/sda4/debian/fricas/target/x86_64-linux-gnu/bin/sman -noihere -paste exdiff.ht
> openServer result 0
> FriCAS Computer Algebra System
> Version: FriCAS 2022-07-16
> Timestamp: Fri Jan 17 01:59:52 PM EST 2025
> -----------------------------------------------------------------------------
> Issue )copyright to view copyright notices.
> Issue )summary for a summary of useful system commands.
> Issue )quit to leave FriCAS and return to shell.
> -----------------------------------------------------------------------------
>
>
> making exdiff.input
> parsing: ExDiffBasic
> writing: differentiate(sin(x) * exp(x^2),x)
>
> Thoughts?

This typically means error in calculation. Unfortunately,
in this phase errors can easily lead to hang build.
I would suggest to just kill hanged processes and run
testsuite. If there are no testsute failures and build
still hangs, then one can re-run re-run offending commands
by hand to see if they work.

--
Waldek Hebisch

[Camm Maguire]

Greetings, and please excuse the delayed reply.

I have a tree passing all regression tests now with 2.7.0.

There was an issue regarding sort/stable-sort. In 2.7.0, sort uses the
random quicksort algorithm. This caused random failures in 3 tests.
I've stepped over the issue defining sort to be stable-sort in a local
gcl image. The details of one case:

5> (|evalMmCat|
|elt| (*1 *2 *3 *2)
((|isDomain| *3 #1=(|Fraction| *1))
(|ofCategory| *1 (|UnivariatePolynomialCategory| *2))
(|ofCategory| *2 (|SemiRng|))
(|ofCategory| *2 (|AbelianMonoid|))
(|ofCategory| *2 (|Field|)))
((*3 . #1#)))
6> (|orderMmCatStack|
((|ofCategory| *1 (|UnivariatePolynomialCategory| *2))
(|ofCategory| *2 (|SemiRng|))
(|ofCategory| *2 (|AbelianMonoid|))
(|ofCategory| *2 (|Field|))))
<6 (|orderMmCatStack|
((|ofCategory| *2 (|Field|))
(|ofCategory| *2 (|SemiRng|))
(|ofCategory| *1 (|UnivariatePolynomialCategory| *2))
(|ofCategory| *2 (|AbelianMonoid|))))

|orderMmCatStack| needs to return this list in its original order for

f: UP(n, INT) -> UP(n, INT) := p +-> p.(n+1)

of bugs2008.input to work.


With all this in place, the build still hangs at

making exdiff.input
parsing: ExDiffBasic
writing: differentiate(sin(x) * exp(x^2),x)

waiting for input. I will try poking around in gdb and report back when
it is resolved. If you have any suggestions in the meantime, they are
most appreciated!

Take care,


Waldek Hebisch <de...@fricas.org> writes:

[Camm Maguire]

Greetings again! Its the hyperdoc paste mechanism in sman -- giving
System Error: not a string

investigating....

Take care,

Waldek Hebisch <de...@fricas.org> writes:

[Waldek Hebisch]

On Sat, Feb 01, 2025 at 01:58:15PM -0500, Camm Maguire wrote:
> Greetings again! Its the hyperdoc paste mechanism in sman -- giving
> System Error: not a string
>
> investigating....
>
> Take care,
>
> Waldek Hebisch <de...@fricas.org> writes:
>
> > On Fri, Jan 17, 2025 at 03:02:46PM -0500, Camm Maguire wrote:
> >> Greetings, and one more question --
> >>
> >> My build is now hanging waiting for input here:
> >>
> >> unset DAASE; HTPATH=. FRICAS_INITFILE='' /mnt/sda4/debian/fricas/target/x86_64-linux-gnu/bin/sman -noihere -paste exdiff.ht
> >> openServer result 0
> >> FriCAS Computer Algebra System
> >> Version: FriCAS 2022-07-16
> >> Timestamp: Fri Jan 17 01:59:52 PM EST 2025
> >> -----------------------------------------------------------------------------
> >> Issue )copyright to view copyright notices.
> >> Issue )summary for a summary of useful system commands.
> >> Issue )quit to leave FriCAS and return to shell.
> >> -----------------------------------------------------------------------------
> >>
> >>
> >> making exdiff.input
> >> parsing: ExDiffBasic
> >> writing: differentiate(sin(x) * exp(x^2),x)
> >>
> >> Thoughts?

Much of above happens in separate processes. In FRICASsys the
expression is supposed to come to 'parseAndEvalToHypertex' which
calls 'parseAndEvalToStringEqNum'. So one thing to check is
starting FRICASsys and trying

)boot parseAndEvalToStringEqNum('"differentiate(sin(x) * exp(x^2),x)")

This should give something like:


(EVAL-WHEN (:EXECUTE :LOAD-TOPLEVEL)
(PROG ()
(RETURN
(|parseAndEvalToStringEqNum| "differentiate(sin(x) * exp(x^2),x)"))))
Value = (" 2 2"
" x x"
" (1) 2 x %e sin(x) + cos(x)%e"
" Type: Expression(Integer)")

If the above works OK, then possible reason could be is socket code
(data have to go trough sockets before it gets to
'parseAndEvalToHypertex')

--
Waldek Hebisch

[Camm Maguire]

Greetings, and thanks so much! With this, found it and fixed now.

What do you want to do about the stable-sort issue? I can check if the
instance I found is the only case, but in general the rule is sort iff
the predicate defines a total order.

[Grégory Vanuxem]

Hi,

Just a subsidiary question, is it the version in the GNU Github-like CVS your actual work? I tried gcl27 on Kali-rolling, somethings like Debian testing without success with an old error I know LF_error not defined or something like that. Note: I write this mail on a smartphone right now.

- 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/87y0yolana.fsf%40maguirefamily.org.

[Camm Maguire]

Greetings!

Camm Maguire <ca...@maguirefamily.org> writes:

> Greetings, and please excuse the delayed reply.
>
> Waldek Hebisch <de...@fricas.org> writes:
>
>> The third problem is that apparently GCL writes wrong thing
>> which it can not read back. The Lisp expression is somewhat
>> complex, one can reproduce this from recent FriCAS using:
>>
>> kf := open("ts_kaf", "output")$KeyedAccessFile(None)
>> a3 : EXPR(INT) := exp(x) - 1
>> kf("a3") := a3 pretend None
>>
>> After that file 'ts_kaf/index.KAF' contains apparently wrong
>> S-expression. Reading it back via:
>>
>
> I can confirm this, and that it is absent in 2.7.0. I will investigate
> a patch and get back to you.
>
> Take care,

I just wanted to get back to you on this -- thank you so much, I've
found and fixed the issue. Committed in Version_2_6_15pre11 as debian
version 2.6.14-12 now building, and in master.

I have a short set of diffs against fricas master that will build against
both GCL 2.6 and GCL 2.7 (current master) without affecting others
(tested sbcl just to check). GCL 2.7 has no regression test issues. I
will push these shortly for you to inspect after my last set of tests
finish.

Take care,

[Camm Maguire]

Greetings, and thanks so much for your feedback!

I believe current fricas master works with current GCL master, and
branch Version_2_6_15pre. Debian gcl27 version 2.7.0-32 git tag
Version_2_7_0pre35 is three commits behind master -- Version_2_7_0pre36
will be released in about a week. Debian GCL version 2.6.14-12 git tag
Version_2_6_15pre11 is currently up to date.

Take care,

[Waldek Hebisch]

On Mon, Feb 03, 2025 at 08:49:52PM -0500, Camm Maguire wrote:
> Greetings, and thanks so much for your feedback!
>
> I believe current fricas master works with current GCL master, and
> branch Version_2_6_15pre. Debian gcl27 version 2.7.0-32 git tag
> Version_2_7_0pre35 is three commits behind master -- Version_2_7_0pre36
> will be released in about a week. Debian GCL version 2.6.14-12 git tag
> Version_2_6_15pre11 is currently up to date.

There is a problem, AFAICS when using GCL as Lisp compiler build
outside source tree is broken. For my build failed because
of including .c files. For normal C compilation and .h files
build machinery takes care of needed paths, but not for .c
files. We have a few Lisp files with similar problem, those
are copied to the source tree.

--
Waldek Hebisch

[Camm Maguire]

Greetings, and thanks so much for your feedback!

Could you please post the failing log? AFAICS including C source is
standard C and works, at least in my testing, with GCL built outside the
source tree, both 2.7 and 2.6.

Take care,

Waldek Hebisch <de...@fricas.org> writes:

[Waldek Hebisch]

On Tue, Feb 04, 2025 at 10:31:48AM -0500, Camm Maguire wrote:
> Greetings, and thanks so much for your feedback!
>

> Could you please post the failing log? AFAICS including C source is
> standard C and works, at least in my testing, with GCL built outside the
> source tree, both 2.7 and 2.6.

The relevant part seem to be:

/pom/fricas/axp1/fr-build272/src/lisp/fricas-lisp.c:7:10: fatal error: ../lib/bs
dsignal.c: No such file or directory
7 | #include "../lib/bsdsignal.c"
| ^~~~~~~~~~~~~~~~~~~~
compilation terminated.

Note: My source tree is at '/pom/fricas/axp1/trunk'. In
'/pom/fricas/axp1' I did:

mkdir fr-build272
cd fr-build272
(export GCL_MEM_MULTIPLE=0.03; ../trunk/configure --with-lisp=/pom/fricas/usr-2.6.14/bin/gcl > clogg 2>&1)
(export GCL_MEM_MULTIPLE=0.03; time make -j 12 > mlogg 2>&1 && time make all-input -j 12 > tst_logg 2>&1)

This uses gcl-2.6.14, I wanted to know if build works with this version
(which IIUC is current "official" version and users are likely to use
it for some time). But AFAICS the failure is due to use of separate
build directory: "../lib/bsdsignal.c" works inside FriCAS source tree,
but not outside.

--
Waldek Hebisch

[Waldek Hebisch]

On Tue, Feb 04, 2025 at 10:31:48AM -0500, Camm Maguire wrote:
> Greetings, and thanks so much for your feedback!
>

> Could you please post the failing log? AFAICS including C source is
> standard C and works, at least in my testing, with GCL built outside the
> source tree, both 2.7 and 2.6.

_FriCAS_ is supposed to build out of _its_ source tree. This is
broken due to include paths. C compile commands in FriCAS should
look like in this Makefile rule:

%.$(OBJEXT): $(srcdir)/%.c $(fricas_c_macros_h)
$(CC) -g -fPIC $(CCF) $(CFLAGS) -c $(fricas_includes) \
$(FRICAS_X11_CFLAGS) $< -o $@

That is '$(srcdir)/' to give path to source dir and '$(fricas_includes)'
which is adjusted so to it points to source tree. Plain '../include' or
'../lib/bsdsignal.c' is wrong for FriCAS, it does not work with out
of source build.

If we really need C includes there should be rules like:

bsdsignal.c: $(srcdir)/../lib/bsdsignal.c
cp $< $@

and the same for other included files. And the paths in '-I' must
contain '$(srcdir).

However, I must ask: what is wrong with 'compiler::link'? Once
we re-add support for out of source build Makefile using
'compiler::link' will be of comparable size as version not
using it and IMO 'compiler::link' will give more robust Makefile
(basically cruft in 'compiler::link' variant is constant, while
avoiding it leads to variable cruft which may break in strange
setups).

--
Waldek Hebisch

[Camm Maguire]

Greetings, and thanks so much for clarifying! Can you please give me a
sample out of source tree build command line with which I can test and
propose a resolution?

Waldek Hebisch <de...@fricas.org> writes:

> However, I must ask: what is wrong with 'compiler::link'? Once
> we re-add support for out of source build Makefile using
> 'compiler::link' will be of comparable size as version not
> using it and IMO 'compiler::link' will give more robust Makefile
> (basically cruft in 'compiler::link' variant is constant, while
> avoiding it leads to variable cruft which may break in strange
> setups).

I wrote compiler::link many years ago as a stopgap compromise to get a
standalone separate GCL to support the standard applications. Prior to
this it was conventional to take snapshots of the GCL source code and
embed it into the source of the applications, with the obvious
maintenance difficulties accompanying. I do not intend to withdraw
compiler::link anytime soon, but it alone requires shipping a large
number of GCL source files and compiled libraries alongside the GCL
binary. The alternate '(load "foo.o")(save-system "bar")' lisp paradigm
is clearly dominant, and arguably a distinctive feature of the lisp
'world'. Supporting two different linkers is fragile and an extra
maintenance headache I would like to avoid. FRICAS is the last
application still using it.

Take care,

[Camm Maguire]

Greetings again! Please ignore the request below. I see your previous
email now with the command in it. Apologies for not seeing it before now.
I will propose a fix shortly.

Take care,

> Greetings, and thanks so much for clarifying! Can you please give me a
> sample out of source tree build command line with which I can test and
> propose a resolution?
>
> Waldek Hebisch <de...@fricas.org> writes:
>

> > However, I must ask: what is wrong with 'compiler::link'? Once
> > we re-add support for out of source build Makefile using
> > 'compiler::link' will be of comparable size as version not
> > using it and IMO 'compiler::link' will give more robust Makefile
> > (basically cruft in 'compiler::link' variant is constant, while
> > avoiding it leads to variable cruft which may break in strange
> > setups).
>

> I wrote compiler::link many years ago as a stopgap compromise to get a
> standalone separate GCL to support the standard applications. Prior to
> this it was conventional to take snapshots of the GCL source code and
> embed it into the source of the applications, with the obvious
> maintenance difficulties accompanying. I do not intend to withdraw
> compiler::link anytime soon, but it alone requires shipping a large
> number of GCL source files and compiled libraries alongside the GCL
> binary. The alternate '(load "foo.o")(save-system "bar")' lisp paradigm
> is clearly dominant, and arguably a distinctive feature of the lisp
> 'world'. Supporting two different linkers is fragile and an extra
> maintenance headache I would like to avoid. FRICAS is the last
> application still using it.
>
> Take care,

[Camm Maguire]

Greetings! OK I've pushed a quick commit addressing this issue which
seems to be working -- please let me know what you think.

And if there is a stream close/flush issue you'd like me to look at and
have an example, please let me know.

Take care,

> Greetings, and thanks so much for clarifying! Can you please give me a
> sample out of source tree build command line with which I can test and
> propose a resolution?
>
> Waldek Hebisch <de...@fricas.org> writes:
>

> > However, I must ask: what is wrong with 'compiler::link'? Once
> > we re-add support for out of source build Makefile using
> > 'compiler::link' will be of comparable size as version not
> > using it and IMO 'compiler::link' will give more robust Makefile
> > (basically cruft in 'compiler::link' variant is constant, while
> > avoiding it leads to variable cruft which may break in strange
> > setups).
>

> I wrote compiler::link many years ago as a stopgap compromise to get a
> standalone separate GCL to support the standard applications. Prior to
> this it was conventional to take snapshots of the GCL source code and
> embed it into the source of the applications, with the obvious
> maintenance difficulties accompanying. I do not intend to withdraw
> compiler::link anytime soon, but it alone requires shipping a large
> number of GCL source files and compiled libraries alongside the GCL
> binary. The alternate '(load "foo.o")(save-system "bar")' lisp paradigm
> is clearly dominant, and arguably a distinctive feature of the lisp
> 'world'. Supporting two different linkers is fragile and an extra
> maintenance headache I would like to avoid. FRICAS is the last
> application still using it.
>
> Take care,

[Waldek Hebisch]

On Fri, Feb 07, 2025 at 08:59:33AM -0500, Camm Maguire wrote:
> Greetings! OK I've pushed a quick commit addressing this issue which
> seems to be working -- please let me know what you think.

It did not work: 'config' include is in build tree and normally not
present in source tree (it could be in source tree if you previously
build there).

There were missing dependencies, not a problem for build itself
but could be very confusing if one tries to re-make after change.

I would also prefer to avoid overlong lines. Diff with my
changes attached.

BTW: I prefer to commit things after enough testing, to have
clean history and to avoid broken builds for people fetching trunk.

> > I wrote compiler::link many years ago as a stopgap compromise to get a
> > standalone separate GCL to support the standard applications. Prior to
> > this it was conventional to take snapshots of the GCL source code and
> > embed it into the source of the applications, with the obvious
> > maintenance difficulties accompanying. I do not intend to withdraw
> > compiler::link anytime soon, but it alone requires shipping a large
> > number of GCL source files and compiled libraries alongside the GCL
> > binary. The alternate '(load "foo.o")(save-system "bar")' lisp paradigm
> > is clearly dominant, and arguably a distinctive feature of the lisp
> > 'world'. Supporting two different linkers is fragile and an extra
> > maintenance headache I would like to avoid. FRICAS is the last
> > application still using it.

AFAICS both dumping and 'compiler::link' are useful. 'compiler::link'
seem to be only possibility if one only has binary object files
(say from non-C compiler) or static library. And with all other
Lisp-s FriCAS can link objects created from C files, either staticaly
or dynamically. Currently this include business is managable, but
I have plans for more C files where I may need target-specific
options for good performance (the idea is to link-in multiple
variants and choose good one at runtime).

--
Waldek Hebisch

[Camm Maguire]

Greetings!

Waldek Hebisch <de...@fricas.org> writes:

> On Fri, Feb 07, 2025 at 08:59:33AM -0500, Camm Maguire wrote:
>> Greetings! OK I've pushed a quick commit addressing this issue which
>> seems to be working -- please let me know what you think.
>
> It did not work: 'config' include is in build tree and normally not
> present in source tree (it could be in source tree if you previously
> build there).
>
> There were missing dependencies, not a problem for build itself
> but could be very confusing if one tries to re-make after change.
>
> I would also prefer to avoid overlong lines. Diff with my
> changes attached.

Thank you so much -- looks great to me, and just committed to restore
trunk out of source tree builds.

>
> BTW: I prefer to commit things after enough testing, to have
> clean history and to avoid broken builds for people fetching trunk.
>

Duly noted, and my apologies.

>> > I wrote compiler::link many years ago as a stopgap compromise to get a
>> > standalone separate GCL to support the standard applications. Prior to
>> > this it was conventional to take snapshots of the GCL source code and
>> > embed it into the source of the applications, with the obvious
>> > maintenance difficulties accompanying. I do not intend to withdraw
>> > compiler::link anytime soon, but it alone requires shipping a large
>> > number of GCL source files and compiled libraries alongside the GCL
>> > binary. The alternate '(load "foo.o")(save-system "bar")' lisp paradigm
>> > is clearly dominant, and arguably a distinctive feature of the lisp
>> > 'world'. Supporting two different linkers is fragile and an extra
>> > maintenance headache I would like to avoid. FRICAS is the last
>> > application still using it.
>
> AFAICS both dumping and 'compiler::link' are useful. 'compiler::link'
> seem to be only possibility if one only has binary object files
> (say from non-C compiler) or static library. And with all other
> Lisp-s FriCAS can link objects created from C files, either staticaly
> or dynamically. Currently this include business is managable, but
> I have plans for more C files where I may need target-specific
> options for good performance (the idea is to link-in multiple
> variants and choose good one at runtime).

Thanks for the feedback. I am wondering what you think of the
persistent linking of new C code as described below:

https://lists.nongnu.org/archive/html/gcl-devel/2007-06/msg00001.html

One can take any C-interface shared object and permanently link it into
a GCL image in this way -- the only difference with compiler::link is
that the object remains in a separate file.

Many years ago I worked on a scheme for switchable access to optimized
blas/lapack routines (ATLAS) based on the simd extensions in the running
cpu via configuration/instructions to ld.so. I'm sure things have
evolved since then and there is some canonically preferred method, but
it is and was an eminently workable idea.

[Camm Maguire]

Greetings! Might you be able to suggest what could cause the difference
between these two compile outputs?

=============================================================================
good
=============================================================================
(1) -> )co EXPUPXS
Compiling AXIOM source code from EXPUPXS.spad
EXPUPXS abbreviates domain ExponentialOfUnivariatePuiseuxSeries
1> (|autoLoad| |Field| |Field|)
<1 (|autoLoad| #<compiled-function |Field|>)
1> (|autoLoad| |EuclideanDomain| |EuclideanDomain|)
<1 (|autoLoad| #<compiled-function |EuclideanDomain|>)
1> (|autoLoad| |PrincipalIdealDomain| |PrincipalIdealDomain|)
<1 (|autoLoad| #<compiled-function |PrincipalIdealDomain|>)
1> (|autoLoad| |GcdDomain| |GcdDomain|)
<1 (|autoLoad| #<compiled-function |GcdDomain|>)
1> (|autoLoad| |IntegralDomain| |IntegralDomain|)
<1 (|autoLoad| #<compiled-function |IntegralDomain|>)
1> (|autoLoad| |CommutativeRing| |CommutativeRing|)
<1 (|autoLoad| #<compiled-function |CommutativeRing|>)
1> (|autoLoad| |Ring| |Ring|)
<1 (|autoLoad| #<compiled-function |Ring|>)
1> (|autoLoad| |Rng| |Rng|)
<1 (|autoLoad| #<compiled-function |Rng|>)
1> (|autoLoad| |AbelianGroup| |AbelianGroup|)
<1 (|autoLoad| #<compiled-function |AbelianGroup|>)
1> (|autoLoad| |CancellationAbelianMonoid| |CancellationAbelianMonoid|)
<1 (|autoLoad| #<compiled-function |CancellationAbelianMonoid|>)
1> (|autoLoad| |AbelianMonoid| |AbelianMonoid|)
<1 (|autoLoad| #<compiled-function |AbelianMonoid|>)
1> (|autoLoad| |AbelianSemiGroup| |AbelianSemiGroup|)
<1 (|autoLoad| #<compiled-function |AbelianSemiGroup|>)
1> (|autoLoad| |SetCategory| |SetCategory|)
<1 (|autoLoad| #<compiled-function |SetCategory|>)
1> (|autoLoad| |BasicType| |BasicType|)
<1 (|autoLoad| #<compiled-function |BasicType|>)
1> (|autoLoad| |CoercibleTo| |CoercibleTo|)
<1 (|autoLoad| #<compiled-function |CoercibleTo|>)
1> (|autoLoad| |SemiGroup| |SemiGroup|)
<1 (|autoLoad| #<compiled-function |SemiGroup|>)
1> (|autoLoad| |Monoid| |Monoid|)
<1 (|autoLoad| #<compiled-function |Monoid|>)
1> (|autoLoad| |LeftModule| |LeftModule|)
<1 (|autoLoad| #<compiled-function |LeftModule|>)
1> (|autoLoad| |BiModule| |BiModule|)
<1 (|autoLoad| #<compiled-function |BiModule|>)
1> (|autoLoad| |RightModule| |RightModule|)
<1 (|autoLoad| #<compiled-function |RightModule|>)
1> (|autoLoad| |Algebra| |Algebra|)
<1 (|autoLoad| #<compiled-function |Algebra|>)
1> (|autoLoad| |Module| |Module|)
<1 (|autoLoad| #<compiled-function |Module|>)
1> (|autoLoad| |EntireRing| |EntireRing|)
<1 (|autoLoad| #<compiled-function |EntireRing|>)
1> (|autoLoad| |LeftOreRing| |LeftOreRing|)
<1 (|autoLoad| #<compiled-function |LeftOreRing|>)
1> (|autoLoad| |UniqueFactorizationDomain| |UniqueFactorizationDomain|)
<1 (|autoLoad| #<compiled-function |UniqueFactorizationDomain|>)
1> (|autoLoad| |DivisionRing| |DivisionRing|)
<1 (|autoLoad| #<compiled-function |DivisionRing|>)
1> (|autoLoad| |OrderedSet| |OrderedSet|)
<1 (|autoLoad| #<compiled-function |OrderedSet|>)
processing macro definition UPXS ==> UnivariatePuiseuxSeries(FE,var,cen)
processing macro definition SIG ==> -- the constructor category
processing macro definition CODE ==> -- the constructor capsule
------------------------------------------------------------------------
initializing nrlib EXPUPXS for ExponentialOfUnivariatePuiseuxSeries
[Detaching after vfork from child process 674979]
[Detaching after vfork from child process 674980]
compiling into nrlib EXPUPXS
1> (|autoLoad| |UnivariatePuiseuxSeriesCategory| |UnivariatePuiseuxSeriesCategory|)
<1 (|autoLoad| #<compiled-function |UnivariatePuiseuxSeriesCategory|>)
1> (|autoLoad| |UnivariatePowerSeriesCategory| |UnivariatePowerSeriesCategory|)
<1 (|autoLoad| #<compiled-function |UnivariatePowerSeriesCategory|>)
1> (|autoLoad| |PowerSeriesCategory| |PowerSeriesCategory|)
<1 (|autoLoad| #<compiled-function |PowerSeriesCategory|>)
1> (|autoLoad| |AbelianMonoidRing| |AbelianMonoidRing|)
<1 (|autoLoad| #<compiled-function |AbelianMonoidRing|>)
1> (|autoLoad| |CharacteristicZero| |CharacteristicZero|)
<1 (|autoLoad| #<compiled-function |CharacteristicZero|>)
1> (|autoLoad| |CharacteristicNonZero| |CharacteristicNonZero|)
<1 (|autoLoad| #<compiled-function |CharacteristicNonZero|>)
1> (|autoLoad| |Eltable| |Eltable|)
<1 (|autoLoad| #<compiled-function |Eltable|>)
1> (|autoLoad| |DifferentialRing| |DifferentialRing|)
<1 (|autoLoad| #<compiled-function |DifferentialRing|>)
1> (|autoLoad| |PartialDifferentialRing| |PartialDifferentialRing|)
<1 (|autoLoad| #<compiled-function |PartialDifferentialRing|>)
1> (|autoLoad| |RadicalCategory| |RadicalCategory|)
<1 (|autoLoad| #<compiled-function |RadicalCategory|>)
1> (|autoLoad| |TranscendentalFunctionCategory| |TranscendentalFunctionCategory|)
<1 (|autoLoad| #<compiled-function |TranscendentalFunctionCategory|>)
1> (|autoLoad| |TrigonometricFunctionCategory| |TrigonometricFunctionCategory|)
<1 (|autoLoad| #<compiled-function |TrigonometricFunctionCategory|>)
1> (|autoLoad| |ArcTrigonometricFunctionCategory| |ArcTrigonometricFunctionCategory|)
<1 (|autoLoad| #<compiled-function |ArcTrigonometricFunctionCategory|>)
1> (|autoLoad| |HyperbolicFunctionCategory| |HyperbolicFunctionCategory|)
<1 (|autoLoad| #<compiled-function |HyperbolicFunctionCategory|>)
1> (|autoLoad| |ArcHyperbolicFunctionCategory| |ArcHyperbolicFunctionCategory|)
<1 (|autoLoad| #<compiled-function |ArcHyperbolicFunctionCategory|>)
1> (|autoLoad| |ElementaryFunctionCategory| |ElementaryFunctionCategory|)
<1 (|autoLoad| #<compiled-function |ElementaryFunctionCategory|>)
1> (|autoLoad| |OrderedAbelianMonoid| |OrderedAbelianMonoid|)
<1 (|autoLoad| #<compiled-function |OrderedAbelianMonoid|>)
1> (|autoLoad| |OrderedAbelianSemiGroup| |OrderedAbelianSemiGroup|)
<1 (|autoLoad| #<compiled-function |OrderedAbelianSemiGroup|>)
****** Domain: FE already in scope
****** Domain: FE already in scope
compiling exported exponential : UnivariatePuiseuxSeries(FE,var,cen) -> $
Time: 0.05 SEC.

compiling exported exponent : $ -> UnivariatePuiseuxSeries(FE,var,cen)
EXPUPXS;exponent;$Ups;2 is replaced by f
Time: 0 SEC.

compiling exported exponentialOrder : $ -> Fraction Integer
1> (|autoLoad| |IntegerNumberSystem| |IntegerNumberSystem|)
<1 (|autoLoad| #<compiled-function |IntegerNumberSystem|>)
1> (|autoLoad| |OrderedIntegralDomain| |OrderedIntegralDomain|)
<1 (|autoLoad| #<compiled-function |OrderedIntegralDomain|>)
1> (|autoLoad| |OrderedRing| |OrderedRing|)
<1 (|autoLoad| #<compiled-function |OrderedRing|>)
1> (|autoLoad| |OrderedAbelianGroup| |OrderedAbelianGroup|)
<1 (|autoLoad| #<compiled-function |OrderedAbelianGroup|>)
1> (|autoLoad| |OrderedCancellationAbelianMonoid| |OrderedCancellationAbelianMonoid|)
<1 (|autoLoad| #<compiled-function |OrderedCancellationAbelianMonoid|>)
1> (|autoLoad| |ConvertibleTo| |ConvertibleTo|)
<1 (|autoLoad| #<compiled-function |ConvertibleTo|>)
1> (|autoLoad| |RetractableTo| |RetractableTo|)
<1 (|autoLoad| #<compiled-function |RetractableTo|>)
1> (|autoLoad| |LinearlyExplicitRingOver| |LinearlyExplicitRingOver|)
<1 (|autoLoad| #<compiled-function |LinearlyExplicitRingOver|>)
1> (|autoLoad| |PatternMatchable| |PatternMatchable|)
<1 (|autoLoad| #<compiled-function |PatternMatchable|>)
1> (|autoLoad| |CombinatorialFunctionCategory| |CombinatorialFunctionCategory|)
<1 (|autoLoad| #<compiled-function |CombinatorialFunctionCategory|>)
1> (|autoLoad| |RealConstant| |RealConstant|)
<1 (|autoLoad| #<compiled-function |RealConstant|>)
1> (|autoLoad| |StepThrough| |StepThrough|)
<1 (|autoLoad| #<compiled-function |StepThrough|>)
Time: 0.02 SEC.

compiling exported zero? : $ -> Boolean
1> (|autoLoad| |Integer| |Integer|)
<1 (|autoLoad| #<compiled-function |Integer|>)
1> (|autoLoad| |List| |List|)
<1 (|autoLoad| #<compiled-function |List|>)
1> (|autoLoad| |IndexedList| |IndexedList|)
<1 (|autoLoad| #<compiled-function |IndexedList|>)
Time: 0.03 SEC.

compiling exported = : ($,$) -> Boolean
Time: 0.04 SEC.

compiling exported < : ($,$) -> Boolean
1> (|autoLoad| |Boolean| |Boolean|)
<1 (|autoLoad| #<compiled-function |Boolean|>)
1> (|autoLoad| |OpenMath| |OpenMath|)
<1 (|autoLoad| #<compiled-function |OpenMath|>)
Time: 0.01 SEC.

compiling exported coerce : $ -> OutputForm
Time: 0 SEC.

****** Domain: FE already in scope
augmenting FE: (PartialDifferentialRing (Symbol . NIL) . NIL)
augmenting FE: (SIGNATURE FE ** (FE FE (Fraction (Integer . NIL) . NIL) . NIL) . NIL)
augmenting FE: (SIGNATURE FE coerce (FE (Symbol . NIL) . NIL) . NIL)
augmenting FE: (SIGNATURE FE integrate (FE FE (Symbol . NIL) . NIL) . NIL)
augmenting FE: (SIGNATURE FE variables ((List (Symbol . NIL) . NIL) FE . NIL) . NIL)
1> (|autoLoad| |QuotientFieldCategory| |QuotientFieldCategory|)
<1 (|autoLoad| #<compiled-function |QuotientFieldCategory|>)
1> (|autoLoad| |FullyEvalableOver| |FullyEvalableOver|)
<1 (|autoLoad| #<compiled-function |FullyEvalableOver|>)
1> (|autoLoad| |Evalable| |Evalable|)
<1 (|autoLoad| #<compiled-function |Evalable|>)
1> (|autoLoad| |InnerEvalable| |InnerEvalable|)
<1 (|autoLoad| #<compiled-function |InnerEvalable|>)
1> (|autoLoad| |DifferentialExtension| |DifferentialExtension|)
<1 (|autoLoad| #<compiled-function |DifferentialExtension|>)
1> (|autoLoad| |FullyLinearlyExplicitRingOver| |FullyLinearlyExplicitRingOver|)
<1 (|autoLoad| #<compiled-function |FullyLinearlyExplicitRingOver|>)
1> (|autoLoad| |Patternable| |Patternable|)
<1 (|autoLoad| #<compiled-function |Patternable|>)
1> (|autoLoad| |FullyPatternMatchable| |FullyPatternMatchable|)
<1 (|autoLoad| #<compiled-function |FullyPatternMatchable|>)
1> (|autoLoad| |Type| |Type|)
<1 (|autoLoad| #<compiled-function |Type|>)
1> (|autoLoad| |PolynomialFactorizationExplicit| |PolynomialFactorizationExplicit|)
<1 (|autoLoad| #<compiled-function |PolynomialFactorizationExplicit|>)
****** Domain: FE already in scope
augmenting FE: (CharacteristicNonZero . NIL)
augmenting FE: (SIGNATURE FE ** (FE FE (Fraction (Integer . NIL) . NIL) . NIL) . NIL)
(time taken in buildFunctor: 4 . NIL)

;;; *** |ExponentialOfUnivariatePuiseuxSeries| REDEFINED

;;; *** |ExponentialOfUnivariatePuiseuxSeries| REDEFINED
Time: 0.09 SEC.


Warnings:
[1] zero?: empty? has no value
[2] zero?: entries has no value
[3] =: entries has no value


Cumulative Statistics for Constructor ExponentialOfUnivariatePuiseuxSeries
Time: 0.24 seconds

--------------non extending category----------------------
.. ExponentialOfUnivariatePuiseuxSeries(#1,#2,#3) of cat
(|Join| (|UnivariatePuiseuxSeriesCategory| |#1|) (|OrderedAbelianMonoid|) (CATEGORY |domain| (SIGNATURE |exponential| ($ (|UnivariatePuiseuxSeries| |#1| |#2| |#3|))) (SIGNATURE |exponent| ((|UnivariatePuiseuxSeries| |#1| |#2| |#3|) $)) (SIGNATURE |exponentialOrder| ((|Fraction| (|Integer|)) $)))) has no
(|UnivariatePuiseuxSeriesConstructorCategory| |#1| (|UnivariateLaurentSeries| |#1| |#2| |#3|)) finalizing nrlib EXPUPXS
Processing ExponentialOfUnivariatePuiseuxSeries for Browser database:
--------(exponential (% UPXS))---------
--------(exponent (UPXS %))---------
--------(exponentialOrder ((Fraction (Integer)) %))---------
--------constructor---------
[Detaching after vfork from child process 674981]
[Detaching after vfork from child process 674982]
[Detaching after vfork from child process 674984]
[Detaching after vfork from child process 674987]
------------------------------------------------------------------------
ExponentialOfUnivariatePuiseuxSeries is now explicitly exposed in
frame initial
ExponentialOfUnivariatePuiseuxSeries will be automatically loaded
when needed from
/home/camm/tmpp/axiom-20170501/src/algebra/EXPUPXS.nrlib/code

[Detaching after vfork from child process 674989]
[Detaching after vfork from child process 674990]
========================================================================================

========================================================================================
bad
========================================================================================
(1) -> )co EXPUPXS
Compiling AXIOM source code from EXPUPXS.spad
EXPUPXS abbreviates domain ExponentialOfUnivariatePuiseuxSeries
1> (|autoLoad| |Field| |Field|)
<1 (|autoLoad| #<function 0000000002208460>)
1> (|autoLoad| |EuclideanDomain| |EuclideanDomain|)
<1 (|autoLoad| #<function 000000000221fc70>)
1> (|autoLoad| |PrincipalIdealDomain| |PrincipalIdealDomain|)
<1 (|autoLoad| #<function 000000000222edc0>)
1> (|autoLoad| |GcdDomain| |GcdDomain|)
<1 (|autoLoad| #<function 000000000223dee0>)
1> (|autoLoad| |IntegralDomain| |IntegralDomain|)
<1 (|autoLoad| #<function 0000000002245a00>)
1> (|autoLoad| |CommutativeRing| |CommutativeRing|)
<1 (|autoLoad| #<function 0000000002249a00>)
1> (|autoLoad| |Ring| |Ring|)
<1 (|autoLoad| #<function 0000000002250730>)
1> (|autoLoad| |Rng| |Rng|)
<1 (|autoLoad| #<function 0000000002257520>)
1> (|autoLoad| |AbelianGroup| |AbelianGroup|)
<1 (|autoLoad| #<function 000000000225d220>)
1> (|autoLoad| |CancellationAbelianMonoid| |CancellationAbelianMonoid|)
<1 (|autoLoad| #<function 000000000225dbe0>)
1> (|autoLoad| |AbelianMonoid| |AbelianMonoid|)
<1 (|autoLoad| #<function 00000000022614f0>)
1> (|autoLoad| |AbelianSemiGroup| |AbelianSemiGroup|)
<1 (|autoLoad| #<function 0000000002261f70>)
1> (|autoLoad| |SetCategory| |SetCategory|)
<1 (|autoLoad| #<function 000000000226c430>)
1> (|autoLoad| |BasicType| |BasicType|)
<1 (|autoLoad| #<function 000000000226c790>)
1> (|autoLoad| |CoercibleTo| |CoercibleTo|)
<1 (|autoLoad| #<function 000000000226ca30>)
1> (|autoLoad| |SemiGroup| |SemiGroup|)
<1 (|autoLoad| #<function 000000000226cd00>)
1> (|autoLoad| |Monoid| |Monoid|)
<1 (|autoLoad| #<function 000000000242a070>)
1> (|autoLoad| |LeftModule| |LeftModule|)
<1 (|autoLoad| #<function 000000000242a2e0>)
1> (|autoLoad| |BiModule| |BiModule|)
<1 (|autoLoad| #<function 000000000242a640>)
1> (|autoLoad| |RightModule| |RightModule|)
<1 (|autoLoad| #<function 000000000242a820>)
1> (|autoLoad| |Algebra| |Algebra|)
<1 (|autoLoad| #<function 000000000242ac10>)
1> (|autoLoad| |Module| |Module|)
<1 (|autoLoad| #<function 000000000242ad60>)
1> (|autoLoad| |EntireRing| |EntireRing|)
<1 (|autoLoad| #<function 0000000002446190>)
1> (|autoLoad| |LeftOreRing| |LeftOreRing|)
<1 (|autoLoad| #<function 0000000002446400>)
1> (|autoLoad| |UniqueFactorizationDomain| |UniqueFactorizationDomain|)
<1 (|autoLoad| #<function 0000000002446610>)
1> (|autoLoad| |DivisionRing| |DivisionRing|)
<1 (|autoLoad| #<function 00000000024467f0>)
1> (|autoLoad| |OrderedSet| |OrderedSet|)
<1 (|autoLoad| #<function 0000000002446940>)
processing macro definition UPXS ==> UnivariatePuiseuxSeries(FE,var,cen)
processing macro definition SIG ==> -- the constructor category
processing macro definition CODE ==> -- the constructor capsule
------------------------------------------------------------------------
initializing nrlib EXPUPXS for ExponentialOfUnivariatePuiseuxSeries
[Detaching after vfork from child process 708225]
[Detaching after vfork from child process 708226]
compiling into nrlib EXPUPXS
1> (|autoLoad| |UnivariatePuiseuxSeriesCategory| |UnivariatePuiseuxSeriesCategory|)
<1 (|autoLoad| #<function 0000000002446c70>)
1> (|autoLoad| |UnivariatePowerSeriesCategory| |UnivariatePowerSeriesCategory|)
<1 (|autoLoad| #<function 0000000002446f10>)
1> (|autoLoad| |PowerSeriesCategory| |PowerSeriesCategory|)
<1 (|autoLoad| #<function 0000000002479040>)
1> (|autoLoad| |AbelianMonoidRing| |AbelianMonoidRing|)
<1 (|autoLoad| #<function 0000000002479190>)
1> (|autoLoad| |CharacteristicZero| |CharacteristicZero|)
<1 (|autoLoad| #<function 00000000024792b0>)
1> (|autoLoad| |CharacteristicNonZero| |CharacteristicNonZero|)
<1 (|autoLoad| #<function 0000000002479850>)
1> (|autoLoad| |Eltable| |Eltable|)
<1 (|autoLoad| #<function 0000000002479a00>)
1> (|autoLoad| |DifferentialRing| |DifferentialRing|)
<1 (|autoLoad| #<function 0000000002479fa0>)
1> (|autoLoad| |PartialDifferentialRing| |PartialDifferentialRing|)
<1 (|autoLoad| #<function 000000000247a370>)
1> (|autoLoad| |RadicalCategory| |RadicalCategory|)
<1 (|autoLoad| #<function 000000000247a5b0>)
1> (|autoLoad| |TranscendentalFunctionCategory| |TranscendentalFunctionCategory|)
<1 (|autoLoad| #<function 000000000247ac10>)
1> (|autoLoad| |TrigonometricFunctionCategory| |TrigonometricFunctionCategory|)
<1 (|autoLoad| #<function 000000000247b490>)
1> (|autoLoad| |ArcTrigonometricFunctionCategory| |ArcTrigonometricFunctionCategory|)
<1 (|autoLoad| #<function 000000000247b790>)
1> (|autoLoad| |HyperbolicFunctionCategory| |HyperbolicFunctionCategory|)
<1 (|autoLoad| #<function 000000000247be80>)
1> (|autoLoad| |ArcHyperbolicFunctionCategory| |ArcHyperbolicFunctionCategory|)
<1 (|autoLoad| #<function 000000000247bf40>)
1> (|autoLoad| |ElementaryFunctionCategory| |ElementaryFunctionCategory|)
<1 (|autoLoad| #<function 000000000247c130>)
1> (|autoLoad| |OrderedAbelianMonoid| |OrderedAbelianMonoid|)
<1 (|autoLoad| #<function 000000000247c280>)
1> (|autoLoad| |OrderedAbelianSemiGroup| |OrderedAbelianSemiGroup|)
<1 (|autoLoad| #<function 000000000247c520>)
****** Domain: FE already in scope
****** Domain: FE already in scope
compiling exported exponential : UnivariatePuiseuxSeries(FE,var,cen) -> $
Time: 0.08 SEC.

compiling exported exponent : $ -> UnivariatePuiseuxSeries(FE,var,cen)
EXPUPXS;exponent;$Ups;2 is replaced by f
Time: 0 SEC.

compiling exported exponentialOrder : $ -> Fraction Integer
1> (|autoLoad| |IntegerNumberSystem| |IntegerNumberSystem|)
<1 (|autoLoad| #<function 000000000247c6d0>)
1> (|autoLoad| |OrderedIntegralDomain| |OrderedIntegralDomain|)
<1 (|autoLoad| #<function 000000000247c940>)
1> (|autoLoad| |OrderedRing| |OrderedRing|)
<1 (|autoLoad| #<function 000000000247ca30>)
1> (|autoLoad| |OrderedAbelianGroup| |OrderedAbelianGroup|)
<1 (|autoLoad| #<function 000000000247ce80>)
1> (|autoLoad| |OrderedCancellationAbelianMonoid| |OrderedCancellationAbelianMonoid|)
<1 (|autoLoad| #<function 000000000247d0d0>)
1> (|autoLoad| |ConvertibleTo| |ConvertibleTo|)
<1 (|autoLoad| #<function 000000000247d280>)
1> (|autoLoad| |RetractableTo| |RetractableTo|)
<1 (|autoLoad| #<function 000000000247d340>)
1> (|autoLoad| |LinearlyExplicitRingOver| |LinearlyExplicitRingOver|)
<1 (|autoLoad| #<function 000000000247d550>)
1> (|autoLoad| |PatternMatchable| |PatternMatchable|)
<1 (|autoLoad| #<function 000000000247d610>)
1> (|autoLoad| |CombinatorialFunctionCategory| |CombinatorialFunctionCategory|)
<1 (|autoLoad| #<function 000000000247d7c0>)
1> (|autoLoad| |RealConstant| |RealConstant|)
<1 (|autoLoad| #<function 000000000247d910>)
1> (|autoLoad| |StepThrough| |StepThrough|)
<1 (|autoLoad| #<function 000000000247da90>)
Time: 0.03 SEC.

compiling exported zero? : $ -> Boolean
Time: 0.03 SEC.

compiling exported = : ($,$) -> Boolean
Time: 0.08 SEC.

compiling exported < : ($,$) -> Boolean
1> (|autoLoad| |OpenMath| |OpenMath|)
<1 (|autoLoad| #<function 000000000247de50>)
Time: 0.01 SEC.

compiling exported coerce : $ -> OutputForm
Time: 0 SEC.

****** Domain: FE already in scope
augmenting FE: (PartialDifferentialRing (Symbol . NIL) . NIL)
augmenting FE: (SIGNATURE FE ** (FE FE (Fraction (Integer . NIL) . NIL) . NIL) . NIL)
augmenting FE: (SIGNATURE FE coerce (FE (Symbol . NIL) . NIL) . NIL)
1> (|autoLoad| |AlgebraicallyClosedFunctionSpace| |AlgebraicallyClosedFunctionSpace|)

Error:
Signalled by SYSTEM::LOAD-PATHNAME.
Condition in SYSTEM::LOAD-PATHNAME [or a callee]: INTERNAL-SIMPLE-FILE-ERROR: File error on #P"/home/camm/axiom-20170501/obj/linux/bin/../../../mnt/linux/algebra/ACFS.o": File does not exist.

Broken at SYSTEM::BREAK-LEVEL. Type :H for Help.
1 Return to top level.
BOOT>>

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

[Waldek Hebisch]

On Sat, Feb 08, 2025 at 08:52:19PM -0500, Camm Maguire wrote:
> Greetings! Might you be able to suggest what could cause the difference
> between these two compile outputs?

First guess is change to ordering predicate. Spad compiler
is supposed to do top-down recursive search to resolve
overloads. Basically all aspects of this depend on order:
available signatures are tried in order, conditions on
signatures are tried in order, etc. In particular categories
are loaded to evaluate conditions. Success normally terminates
search, so what is loaded depends on order.

IIUC you are compiling Axiom and Axiom build procedure in 2006
(and probably now too) used experimentaly determined order
(layers) to satisfy load dependencies (there were collection of
domains to break cycles). If you change ordering used by Spad
compiler load dependencies may change.

--
Waldek Hebisch

[Camm Maguire]

Greetings! In updating these packages I've noticed that the traditional
AXIOM regression ran many more tests than the current FRICAS
regression. Has there been some weeding out of bogus tests or some
such?

[Waldek Hebisch]

On Sun, Feb 16, 2025 at 07:29:06AM -0500, Camm Maguire wrote:
> Greetings! In updating these packages I've noticed that the traditional
> AXIOM regression ran many more tests than the current FRICAS
> regression. Has there been some weeding out of bogus tests or some
> such?

In short, yes. Slightly longer: the was considerable duplication
between tests, several duplicate tests were removed. FriCAS
also added several new tests files, when new test files did
more thorough job old tests have been removed. In very rare
cases tests were bogus or made invalid by changes in FriCAS.

You can grep git log for 'test', you will see several commits
removing tests. Note also that a lot of files in 'src/input'
subdirectory were not run at all, most of them is removed now.
It is possible that Axiom runs some of them now. And of course
Axiom added its own tests.

--
Waldek Hebisch