\documentclass{book}
%\newcommand{\VolumeName}{Volume 2: Axiom Users Guide}
%\input{bookheader.tex}
\pagenumbering{arabic}
\mainmatter
\setcounter{chapter}{0} % Chapter 1

\usepackage{makeidx}
\makeindex
\begin{document}
\begin{verbatim}
\start
Date: 01 Mar 2007 17:04:05 +0100
From: Martin Rubey
To: list
Subject: Re: Problem compiling wh-sandbox

Dear all,

I still cannot compile wh-sandbox.

I did a symbolic link of gcl in build-improvements 436 into wh-sandbox. make
complains after a short while...

Please help,

Martin

Finished compiling /local/scratch/wh-sandbox/obj/i686-pc-linux/interp/g-boot.o.
Loading /local/scratch/wh-sandbox/obj/i686-pc-linux/interp/g-boot.o
start address -T 0x968a000 Finished loading /local/scratch/wh-sandbox/obj/i686-pc-linux/interp/g-boot.o
Compiling g-util.clisp.
; (DEFUN REMALIST ...) is being compiled.
;; The variable |true| is undefined.
;; The compiler will assume this variable is a global.
; (DEFUN |deleteAssocWOC,fn| ...) is being compiled.
;; The variable |nil| is undefined.
;; The compiler will assume this variable is a global.
; (DEFUN |reshape| ...) is being compiled.
;; Warning: The variable |b| is not used.
; (DEFUN |charRangeTest| ...) is being compiled.
;; The variable |false| is undefined.
;; The compiler will assume this variable is a global.
; (DEFUN |update| ...) is being compiled.
;; The variable /VERSION is undefined.
;; The compiler will assume this variable is a global.
;; The variable /WSNAME is undefined.
;; The compiler will assume this variable is a global.
; (DEFUN |semchkProplist| ...) is being compiled.
;; Warning: The variable |val| is not used.
End of Pass 1.
End of Pass 2.
OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3
Finished compiling /local/scratch/wh-sandbox/obj/i686-pc-linux/interp/g-util.o.
Loading /local/scratch/wh-sandbox/obj/i686-pc-linux/interp/g-util.o

Error: |atom| is invalid as a function.
Fast links are on: do (si::use-fast-links nil) for debugging
Error signalled by |OPOF|.
Broken at APPLY.  Type :H for Help.
BOOT>>make[2]: *** [/local/scratch/wh-sandbox/build/i686-pc-linux/bin/depsys] Fehler 255
make[2]: Verlasse Verzeichnis '/local/scratch/wh-sandbox/src/interp'
make[1]: *** [all-interpsys] Fehler 2
make[1]: Verlasse Verzeichnis '/local/scratch/wh-sandbox/src'
make: *** [all-src] Fehler 2

\start
Date: Thu, 1 Mar 2007 20:41:16 +0100 (CET)
From: Waldek Hebisch
To: Martin Rubey
Subject: Re: Problem compiling wh-sandbox

> Dear all,
> 
> I still cannot compile wh-sandbox.
> 
> I did a symbolic link of gcl in build-improvements 436 into wh-sandbox. make
> complains after a short while...
> 
> Please help,
> 

FYI I test using out of source build with gcl-2.6.7 and with gcl from
build improvements around 370 (but the eaxt version of gcl should not
make significant difference).

I wander if you started from clean tree.  Axiom Makfiles do _not_ recompile
all needed files, so it is possible to get misterious failures even if
the problem is fixed in the source tree (but binaries contain errors).

I am looking at your report, but it will take some time.

\start
Date: 01 Mar 2007 22:20:03 +0100
From: Martin Rubey
To: list
Subject: Re: Problem compiling wh-sandbox

Waldek Hebisch writes:

> > Dear all,
> > 
> > I still cannot compile wh-sandbox.
> > 
> > I did a symbolic link of gcl in build-improvements 436 into wh-sandbox. make
> > complains after a short while...
> > 
> > Please help,
> > 
> 
> FYI I test using out of source build with gcl-2.6.7 and with gcl from
> build improvements around 370 (but the eaxt version of gcl should not
> make significant difference).
> 
> I wander if you started from clean tree.  

I did a 

make distclean

> I am looking at your report, but it will take some time.

That's a pity. The reason why I wanted to rebuild is that I need aldor
support. In principle, aldor did work, but was unusable since running aldor
functions yielded tons of messages like

(Entering C28-axextend-<=
Returning from C28-axextend-<=)

I suspect this is due to the fact that I used experimental patches by Peter
Broadbery to make aldor extend working (it didn't work out though).

Of course I wanted to build the most recent sandbox...

In any case, I attach the output of configure and make.

Two things: 

* does it matter which version of noweb I use (Tim Daly's modified or the
original one)?

* I did not make install gcl. But, in fact, looking at make's output, gcl seems
  to work, doesn't it?

Martin


--=-=-=

H4sICFM950UAA2NvbmZpZ2xvZwCVl01v3CAQhu/9FRxbqV4rrRRVvbWbKMqhOTSqlCvGY0MXg8VH
vP73HbA3WX9t2Uvw8j4Dw3hmTBgHdhCqJoUXsiS2tw4a4voWdrsdEbffbrOWZVIof/zATizX1iWi
jpoaUuFKG9LQQ0TCOFVqxoKAw3R+T5huWiHBkBIq6qUj2rvWO1LhJFG0iQvSHc6+W3YcHEcT/HO+
QqfNwQa8B7uEOyDUAGFGWzvaoBxwpadOWV9V4kh0ReAIzDtaSIjrbmG6+AtscDlyenN3b2Ng0e+H
pz9nvm96jREjlDFonSVZvcDG2BLdOqEVcXqEyY+n50eyH06nMJAAJZRTO0p+Pt9lwQPqBB6RCGUd
lTIY5d6avBAqH+dIxpa+SUUyuxH1sIHTnvGgxIeZ07Q7xIzAcaZg2q29lXEahxmP7g/bzC3ehPgw
1QxVUhRBHJ5moYlbzXeS1MExCPFhmfpClYP+9mPKKO2oqiWMAQZjc+ML6GOgT+LcpAP6umURtXky
yHkouO5CYhivxoJpDbRGM7BWm7EqSXY/XeclnlMUhhoBdsiHl5ub37c5Tn4mHGiJ3mDKEMwPVVKD
/QeoYTwEe/6uMV2w6xT9qZwXmcK0UlhBq5qBRr+um1ne0HWjRwb7YU0siyffFJiu6GsmH/f3qwZQ
Y1BiMHBcRGOopvHU73W+dKi3eeiTdsc3dYyX25JdGZJySzShX62LDQbJ9Bctt3wSyl102ZVIbIhe
CdRXRAM1lgLHfkcL7LOu3yQwGS0otv6CRygl1h8ZRbn8NAVjwDU7gLvozAS76NE5mfCK172ah26d
KqryotODftHbiKwnDMVyiBURmBOhVSVqb+A7fiYBvwoI7/JhdhcO5U/M+OuM+4U9LxTGJmANy5Mg
LIFU0LZpZKG1SyMx18Ekrmo5ftLTUCprwF6aBoNLjBSTUKWRpU5csja05degD6Whnb3G4lVA9+Xu
WouvV1v8kHjzudaooSrx5SeTHJuUSc0+vPomp/RBgkuMfEvxDv9/NP4jkVtmBN43Q9L4BpTbxIf5
nB6FbjKWNTRcrnd8wa9jRFjsgozjtQevpv8A0PS/Jc0MAAA=
--=-=-=

H4sICN0950UAA21ha2Vsb2cA7F17d5tIlv97+RS17j5jJ6eRYiedfmScGQTIpo1AAeTYu72rRqhk
s0agBeRHn/nwe2+BBHoWtons2TN9Tiei6lf31uM+qwoyvhn6MREnpBlEnhs0Ey92U++6eXctJm44
HET3zcHUD4ZN/+PPH8WJJwZ+OIUyPxTGT2sa+IMqTVM3vqLp09iubfscvsPIe3Lb5NqN6fNaN1N6
Px7hn4I/IilNUrLX2CP/fox/fSLpNQ3J7wIhxJsQMSaN5pUXkMYnKBv5n4g3JPCMT42mF4Uj/2oa
UyKKk5iO/PvjR60eNKOhOwiomKRumjwkg9EQyoZ+wgqHD+G8LMfdJon/Jz3++OOP7z++PSrKx+79
xL2ix0c/fnx7+O7oQ4lKepN1s1R0X/6No/vLX2A8/zZ2byj+ZH/7IfQpCIQgcod+eEU817umZDbm
BnsU4H/vBmuvI5hF6GxKxyR9mNBGo0EWhipehVMBUcerxdkY+mMg6Yf0WJgm9Pg9gBii4DGKYph6
D0kfMPbDN/hcAO6uKSxejCtIZOJF44kfwOMBgGA1yRtyF8U3CbZ/oMkjmvkJcYkXR0kizmqRSBit
0rijBCSMTBMsPDF6RF7o7lq+yMf1PDpJEyJebcZfR3ckjUg8DfOugshN4sijSRLFy7NCRHVp5ty7
m0UQFBSQfO1uaZz4UUgOsAnInzv2PZKLwBtsvkATBcUPR1E+Gzpb0aPGx8bhj+LRTyIs9GIfpqGf
pMPG9eYxIgq6gkIGEkjEwNuO7dtyX9bP+o58hsDDd++WRj2e8Nj1+wD6s++HfpqxxDZbW9D7lMah
GyD12YytzE1AM72ZhkNAeFGMKkWiwf9QDzVlPIiCZFmKsB0KTTAk0STFdRA77mRFYNkkgRkg0Yh1
IfDHA0brQ4Hp26em5fR1rdNa5tLXTeMk/2NNNVIHm8ObNoCU5gwbbISDlQ0pHaLwDsFIhiC7pmE7
c05rOgAmAG0C4zKIIpjMcGUaZlMQROGi1nxYxAAkSeMpTDuIVToAA80U4eelRQ2HPjDZMuoMEYK6
ISbw0zSgS4syiG/WrlYMPiAaQ1+Gc8zCiP2QyYrSUk80A2uvopS8u//5HftvFSjbjiSf9SVFsVTb
njUQD9/99NMvv/z08ePqDOAkZX/4Ybq2j+g/7vxhymbg8GhJj2jq3W1Z4hzDg0zBoFAuldQfQ5eH
7gPXTjT9yEsDnqjSYFQB0ncH/hJsWSqRYwLi40ccYMtWNo5jGVt9wGUkaJIXuBBk5LYHfEFCw3TZ
SISZeo63Ex67cyAU3dH7rR0euyAjnPm8dYMpTXioEXiWlAfykzCKx26wVmj9ZIRGiK63kbBUNE1W
TDOYgRCsMHeyMVwZPPBFNgZTD7EKbc5+8IZUzPe8xXYGQR8Dj4DiakOcBJElTaoSaAOBEFQTYh8Y
+ZAyimE2Nw1vZeLYj8yDgbOGUDiLZUZemK5fAghBRn7AUVUKlG45fthDKz+dbJS9tmYaLc0kt0mD
mH0DHnRTPsuGE4XMriNMa5pIokCsG5t93kcXJGVhw4YJsLUT+9LeDlA7zjr/5SbjZuJfocOBaIEn
DzkaQgpubFTQZP+VClAeZkSWjBtE1skC3eY0iTH9a7KqkovDR6CSUlz9CYEsCxQliplhelximqVa
jGATCYpIsLnMCuIBdxqkDcoEqNEsnpeRGGc2oT9P7QlrvzgvqRc005sV8wDFyeIysJJNKhz4lNJl
oQ3BHY8iiP2KVpBMQa9XpEleCKqmV1cPLHyfBeKjOBqDgRleu+lMzkDlU2wwz8UweZwmRQWG5TCR
XlFyB3FDdJdgJtvwk2S1Ajwbzu3ATVfr8kywESSTovIaafmhh8I25yd8Rwb0CmYlL0mwZDGbg4L5
9EHJDQZwsXvXB2qCrrXsY5L9B66IZLF4JqyBP8D/MVx0F0r8AY3TBygsbCH8DL1pnFDk70CqNAaR
8tFFej6bVGgWu/EDhIXT0UjodNuartrH3x90uopmvWn+vdPV+lj2dzIvgybjSRSnDVfAMcQRW+As
acwniPniHwi9yvuHMgpQ5xryx7toCkG958JkLKTXGBOzOaWlRkwzMS0HoQYCpQocM1SIR+Lf/tZ8
CyuUXoOXG0Oc7CaQqIEdBqcrPGUrAgcFCSlkKdCjSeB6NB/aKMrICprRNvswF4+ju6B9Czymaa7Z
zNLkXVc7kmz3bc1RITexu0/itWJzgC2OpbAtjFvOS1HbUk93+qp+vGB+oFE4HdM4mibEkfWmcwZB
TexjVpIQbxoEEMsz5UTS6Y2cq+I1LhoajHkBEMJtJvDY2d4AMwsNwTnrQxbU1k76XUttaxfHWAIa
YEnWJfyW9dLDWf9CM2S9p4CU4lP+kMGKB9a+b3dVmT20epquLBZdoIp9XaGYMZvB4ElhBUUV/BIM
09Hal8dovGT5GDde5LYunaDGil9RlEXl3NSPbyNUBEjdxBF6IzoUPVgVIk78CZSZ76EcMqFUHMUQ
V4mTCNIRGgMJ7fuDE1lnuhYJbc2Q9P6cfnUGgqE9ulPLzM33GYlNnRXMoxlAECy9b7Z+s2E+gv48
FotYOcwbTFtHOlNRdY5HbpBQQWgzuU7cWzpkRg8iDEftYHshW7BWWzkWTpjZOQbz9164yFfgYjYh
gtC1TBkSP9Pqz0rUC8eSIKnHvgi6KikapPc9Q1EtWzYtkI4To9fXleNDQfp6dsz2ftzhUEQjfUgK
85wFe/PnBjPiaLD+8/C/fiUqDh8B87iA/LGkoUwtRX8MUeEtHUNGwpzOvuC5KfiM3GFdk39ASDgk
IiV7hz80W8xnsMh8PEGf0hzu4X4kVjdVUKdS1XRImz/8iFkxYD6TdDy5F6h3HSGt/e9yBNkrWO39
Hn7nj2AcxD6Rfw/3vsu3IOAJqygsCpbiNs1oXghZ9mgfOulNJuToM5iF22YIKv8PchXTCRFvyf5/
k7ffIyJ1fRCywwB/gkANyf7ePvn8mfUrH3PW8UMYdclpsskYT8Bus98UbA37MWY7VvAj2yliP28z
zGCY/c2Ekf0KIFNjrW8x6EO3CbXTEP0qK3fTtM/CT/gd0rs+5oxl1kfzBzcDQV+jMHiA3xEkM1f0
PutLE1Yzjfw/kevnfNIbzXt0U2NYZtEfoT6FV7Ck41tWXYwblgNCBFaGlnGxnNyhN8BgCa1oguMS
gnAthQ38vMkyyWix3VIt9iGq0oftVA+8IYHufMqcORiaN5mWHD1HS9Dv7xd0jCi9RjLgLAfgvaIw
S93+AG77jQKmU/f2edzIeJK5+OcPoUL3c2Z1DGFfiMdgopcX9NM6qWBLFtW8YNEOlyvntawXta7Z
H4vE9/HoYzphG7cQov5rxR7NC0YwDf17zBzmJ2uZ74cgnfn/IPmVNMC4sbC++bYRYb9IMvWuWZRK
8BxmxngGHkfDisgJdKMa0gsgaH4EFP/ov21ghL2tSQ1LNpvAfSGNkAmmi/ns9cfuRGCnXVG5mLDo
QW9gEBj8gGcoy41YhjlD15Nr4mEVUvGCCRFAnHFfcsYSc2eQrSgLVfbIgR+KE9e7ca8o+X2vZ6vW
73tvDrIzuF9RPsT8PO73vQVpARREPZ+R0uPmrlmenUc2hUH5Azxv35yMIZ78lY0Q4mhywE4+o/EY
cm0dBOQNIdIkhkDp8JdfPhBy9PHo8MMHduCQCC3knp1A4pkYBFR47oN6+IwRNhrzc+tHUgHxhrXC
MoicWMKP2x7PJwbRJaSlcVQTOYz4GL2kJoJpNKmJEhinaUBrIuZO0wipMHLCZ+G7v+7JZqer6aq1
R3IN+pxX2LppdldLVcsyV8GSYWvi2gaK2u5K8pl0oq5UOWer5Fn6Vi7OSj4Lb6GjHclQRMk6sd/O
y58/J7gvDxqZTclXNw6BHJhg51RWLHTYA4r0Y5olOsPGAmY7oK1ZtrMdYquyaSjbMc6pZnEgbbNn
8XvT5kFs7YILUc9V7sBV7eSUhzE0LhlnE6fnrzqYtuFs1Z9PLaHpqC4VjWP3ob6euUlC67S62dF/
bfSgEUQBNZHzo/rmbewnq0YB95pErdPV1Q5IpuRopiGeq5YNf38bKQ2n4/qGhDa1TpH/3/oo1det
NHa9uuQpCaLa3DhoYRzF9ekNU8MpZgD9gR8OayI8H3BJ5sGpfxvhBkq5m69LZyE5qo8qZM8hvWOE
WSLNtqLrJDlN/aA2gRhMr+qyongDsc5xsgusdRKsQeCXCLJLbHVS9GYnvPURhGa1UsQbJIuqjscg
uqR1tgdlGarDvF+9hmGpf7gLX+eARwF9buCyRHAa1mtjnhtDLpIL3AGtdwYDd1wvvZoXBJrXSm/s
Ptf9L9HDixO1Ukwm1PNr1pPUfa4rWaL37CBqkd6t+9w4aoneczd9FsndZTIt6Dm9RcDITYalnaa2
H/rJNR3OXgrYjtaf5dyTh0TEFxwC1x+zjeZV7nURfnpH88F/k75upP307uIxQ3rTTG/EctBZQ1/X
E372vM4Nm5+5rrlXz7cBRbyntd3/58jtIEWzJdtWO60NwPpWc3lEtUxRAK6dbQzWtZwbade1otHk
W/S1RPh5tme2+dwHynX1cy1dwcl3kvEUaGF7OR6XT61qOI8sDtLwZBWYfyLZidpbdj5V80krkNwX
BJm9MIcElvcKG4XDKXJWf3HtKljVCpBV+nO173VPLElRcZPeki5FNdsoE53LLsde4LWurNF23Lkq
OyZnWz7jrWjAGnfm7CpozRBbZs9QbHHtZscy3DK/ih3pN9OChop6sb1JS+OdAXARABAl3jEBgjTe
5CDoogpI/XLOBxmVOmVU4QeU5MNqsCM+zLSqEANUBVqGyVmdTCjFbs/mnGeUgKJ64ai8yZvh1+/A
lYRS+a1nO1v0B2/9RSPSdZOEHDYIEYRPn/C+Bv2VOK4fiGCLpnHi31KCGxcItdUvPdWQVVHuWTas
352bAEF2k3lIBg/EBzuWvS21QPwIiZtdR+to/6GSgN5SvORguyOaPhwf/UBsMMj0+D3+oHR4/L6w
Lt56y8auI9RzI3b7eXtERG+RtSc08lty7mRCYZCL1UM3dZeKohUDPT99eRXmWT5V5bMK1hhDN4sj
9Kos2bxIkQ/BvvBRajWYvBW2ogPfRG6zBX8Bqc0Yb5DZrLIksVnBiryWr1W8pMTuZK3mg939as1Z
r1+veXWxYvOidWtWHMq+CjOjqG3bsXoyx4LgHeHMpTCWIhsscJ3grbCdiUA+dy8iAznvjUKQ1y9I
QV62RgyKs/RXIgW2bGktjs3WDHxNZr2k7EgE8nl7CQnIWW8SgLy6vP550cryL95geyUC0D6XOJE/
ux1mSR3VUflI9pkLyeCYFW5KwstGdFOWdJ2TiG46Fhc+kQOt0zUhfNr/eor7ZI1G402BzL94g8BP
pAiDrulsq4Kg/WOR9TKhfdzSeMMicT8kLhm4w+zVwsVZ6kiyZXLnsrf27K50ymerzhfeRiBvpr+e
qhw2PUNXbU6G3rXMEz7iLR/CyQgRwkkHOz3d0bq6Kp5Lek8VdY13vW+pAX9Slxq0NN4cK7y1Njkz
w4+rLdXpWZyFVEz+ZCgmWGuVs9qKWuEMWpc6LUV6OadRsra7dxsl5usdRwlQuI5S4YrzmF+cexV+
46vmnIpmVzVEiCJViSMKDK0Z3Z4jti2zg200g2MvMg49Bxs5ZqUm0BHlEQwszVGrku4C5PAxYLkq
uJhJ/rHOpWhaosHb/rxUbYYzeUAFQr9Nhz87UdFMpnevnRnf9YqZ1RU6mT2vqGPpRvqrUMieseGq
T+kydwWMZkCQZ0Owz6dWHQoeVVS0dlu1cLeSQ/YxYMSqF7Les7VzVeTFjMbj4HavBQ04KvSvVxA2
dvgVvIKwsAZZtFbX1nsH0o988bdsu/PItLQTPpHKlvcdOTDYxzLxk2mEXWaef+bnTXWrPDNtu7fL
M87rLfOstrDNs5IV61y8GfAqjDOG1NyI2lRUESw0vqsg6SK/CZjHxzYpXyARu5Jzakj8Jlk+z8u1
Hfa1mfn3+Qi79DbyYfmVS+CiydlhGjNz0/AmjO7C2lrjsLJTbE5G8rhXQ8qBJboO+9Jmk7Y+OdpJ
wJTL9e41M2e8XjHzykIv84JVtZy/J/kq1LJrmeeawk2sv/Q0i6e+ptyby1RNLqatGYq4SHjHB7z5
cr2AtGWMN0hbVlmStqxgRdqKF7NehbRp9hfeea3U4m2znXI3gmwIKXqcfFzWeBdubI1jEiXZ5NAA
EpygDEjwIjuJR0Pis5H4fCQ+I4upoKRXQ6HibY+y27rJy0Dasqrp3A2EtmP1DFlyeAwtvDvF2zA/
4d8WQhB/e/6kwl2hHMXZzwUU/6ZQBuJT4t4TAoyj8rKx1iVvthEh2lwpYLCuaWv8JFpXWlyAyO96
R7LPIP5Tdd6WdZfDTlFZv7fQ2klElBv53fuonPF6H5VXFj4qL1jxUaX3fV+Fk2JBB6S2EOx2WqbO
OwcwK+MwfrfAMFZuULkTEoRxIIoVDnpyZIX92PxrGKIGnZY2XWbdiXzPBGT3Aj7jvF7CZ7WFiM9K
VmU8nn/G4VXIuKK2+dfrEMHZ+7N7rQoo2VStDfuYj88JOpIjn5avTe84I5gt5QtIY855gzTmtSVp
zEtWpDH/JsKrkER2o352i5e7D4MxnsGN8zoST2xN7s7SuWpxtnsgjpIMPmYzpZ0YT1zr3Ysqcl0v
plhTiCg+rRPP12QrLVXp8USzrem8rEjt6hKPjKV2zPNKGFFrV4Tx3wtQVF3lqVSG4XKdw/hcZcjF
qkC4PGcoPks8znI0p8cbbIHjMl+A8ntgVO2C8Yg+GI/sRJt7WYeFwDy2OYjPr1pyN0Nx+ZaAfN65
Gii9rq6h8+De6mHyWxXe0WwWjvDOASWLizF5G2O2I7V0cJVcYEe1TvgOUtQMh3Mli6UBp5J9Kmas
H5cJcAO5Lz1NPsvGs+MQLncwL+IWNwdweeWCc9wQvmVfcXsV3hEv0asO1y2AsWDXCttiR3VOTY79
OcGjpieCxcWridzbEzxrw4fYp1qbh7EgWHTUatPUMRWtfSlWuCAL1o1DUjNkLlMegv/CICIM9SvP
bq+Pyp/y0h+stnrRxc9sHj7n7kFlQt/GCoEav4QNArabLBBUle0PPK5Yn/wzKa/C+HyVePd9W5Yq
ndWcfdV0xwQncvfLj1zXrz7WFIuPT6trP/tq4atYfcfiJlSQGfBBtrNhA+vxlolxE00w4l1I+LJ/
ruU5Bip/E5ZRxQ8K/3+kld0syWixW/XZAWI9G3uVdPUdX1eZ4L+AtjK+G/SV1ZU0lj2vRouzj2X+
c74oW9MCZrPwAt6W8d3gblldyd+y5zVvTOYfzXxVC8hVa6Wli73uroOqbLJe4h1J5LvpBUmsK78d
ic+rb7fkHzR9Vcu8az1lk/ACb0Mg2w0vQ2BV6V0IfFyTks8+m/zPuXpzDTuardDR5rSFDfUlEhfG
eFPqwirLyQsrWPf++ZpvUr+KeBZP/K0TMdvPZv9+BSehliwbQ6Yqr9KyY7Yz9fKryXs/YkavSg/O
VQt3KnK6nM1S3TTPet1qnchBot3rdnVNVXivcS1OhZi9d1nhOgT7xJHdazEoe4uV/2YbNtHVx6BR
6/BGXMUmbCwtU+GcLSpq9vWKHr5gt/kN3Bc36Ws07kW+YbDciY1fM1gGLnzXYLly3XdOSp/CfEnD
8okczK53/1r88zZPfcl/Lal1L/njlwWM2fUhkn3g8MlfFlgltIEl1BbQ0j/m81TOm+n9H3tX3502
rvT/Xj6Flm2WJE8NTdrmdtPbnpsQ2rIlkAvkbns2+6TGGOIt2NQ2Sbon5372OyNZsmzLBLApSTd7
ui0eSTN6+Wk0ehupMnAHOplA3VpcxHDhqT5ieISIkxhOTN6SSD6RcD8Nq5yaN14fa7iPEMtBysWE
WCzphkIsJHmb+A4sU8i2Sl5LgjBK148PujWNXlXD89DZ9izy5odFDdbdcMusXce93m/K8Ft3pjUt
Bc1YCYotBAXrQNld/1JnvOj1l/lKXqnjXyYi4ftXegdlnp49vw/4W526f7eDAa/Sbw9hLlmNYh4a
AplTEspefszmARb5wYLW6XpwQUWnA4MGR5FBSSpo8FeJHpCRGzJola4FGFRyKi5oaAQWlKJGRfC0
1AMscoQF1umacIGiZwADg2PIQJIKGsEbYd8JMOTL+Tk8dLbMvfvTJvVppDGXeswVd4YpwcHRkSZ4
RvJ7h6YFAY7W0hlQcGpXwMBIR0CCshsET9F9J/3gLihIWqXrgQRKTscEhkZBgRQVKvh7gg+oyA0V
tErXggoqORUVNDSCCkpRooI9Cvm9guL2E2yBUyftTauB24t3ayDC1lkPvkBwOrwgMIouIKjAZc19
P+H7xNbOm+PGQabzldk5/DrzWs3Kk79ZYfI1dEhrHUf1mdzU7mgNor3RUpzWp0DmT4L/bTvkIbuC
16j9O5Onyrm4rAOcrIXXA1AmOx2kLDwKVEZTgVU8Bv29YnUN8GB1uhZ0MNGp4GDBEWwwkhoa4wdg
5AyM8bpgMZ4FinEcEmM1IB7mtXkDYl3T2pmz2sSkNm1OC+IeAJEvIKBG1wMIEJwOCAiMAgIIKkCM
9bmPFD0AYi5AYI2uBRAoOBUQGBgBBBKUgJiOfOsBEvlCgtbpekBBRafDggZHgUFJKmhQf+vf9/7J
HMtO3Xd36qie1C5rARgXngoxHiECMk5UwczX577L+V1C7NfT45MOPgw1c8l9ng3ldu1tPj478sMq
Nu5acIqCUzGKgRF8IkGJzflPYH+X2Dyivq5a2mnzqNbuVFvtGnrJyoLT7k6rfVRvHrQ/3jWkruUI
dCA4HalOzI5TeiFB+tfJ33tFG0/kaOinPgs45+CxDmhi264Hmyg5HZwYGkUnUlTwnEJGv2d4rgEV
tErXggoqORUVNDSCCkpRoeJSn9tDwH0Exa365rcuXge6Y9oGG2UtsELBqajCwAiokKDE1NzvqN9H
SK0DD+t4KpnJTUeDFwOD4m1kIF89bIfki4WrNe2GXM3YDLmK7YVc+bncFDSC23u/k2KRvHqFf/9B
bm4IXh68hgjaLvn5Z3ZhEJ8QfAW5m9rW9cRx/YqnX5p9fG3gHCJuFSAFDxJpWBQILmBDYdEoz8p2
2dmHQYN4eC1xgLUKjSUyzyOPnf6cMSdQlPliGiPDWyQq/nW+TeE7K0kOFyl55ZUK7pho7oCMrB7Q
y3oBYOZ64hOz5lQAmLj5EXy4rv5VfHiIT+TLKT3d+PxFfPQ98dMahj/xuh7/TadfwQe7rcU+gpsY
wQc9BRj8hq6gG1ByQRhde5DQFHkAoOnTa/Hl2H0Lx35cLWMkU3ctXzAPvPgEH5dhtIHun3s+1rCg
WPgCXvDbcce6kEm7oviY4ukTUZRhT9Qe9ijX1PvscEpAG0/Or1zsg66orgvdE/lDfXU+gSwLgrBm
AsIoLPvIFAUHHAkyf+6ef1l2+PuzKdXuWJ/IX7iULdUI9N9zqj75d6ykdrQh7On4PFLVSDCc6Nd4
In+PnKH8ie+LyN+ubke+PSmz8N0LUSGcAPBP/8KWmmgyErlEGRbALQyDJpdCwxxhy4W/B6Zr2oYZ
Eobm9UTIh8HhHEck0xPV7plfpnIKb6B7ompZzYVxI7jjLmHCpF/HPUekhT5EByjxDZNGXCDm39jd
ZVn0G4ZM+RvVZ+Q7GowDnfj2ws6Mv3fFBwxaQSoc0RHsVF1QF+MRqueZrh+lBS7roqQBBW6CGmlc
ic7qKU4GZWj1EpGTbnbkcNQDcqfhdOabLUJxEsUb8QeTI0SHazpOSfiriAQGj7tGaMETnDKNP3km
08QbUREif6pHJtLHUWIERaRQQ4Y0dNwcoSQL6CcIzH8oHfGoNcBtsrABYvRwSIgGsCucKroYNqIB
9EKTgiy0W5Q+EDo1Ruf6Jkq2BkqqHer5aEhwBE0VMFaS1bkR43KUTLemFWS2MZkMEJtJySC6jq8g
O0oJbLUqSWfrFUk6nXIqyJ6KimYoGvpo48EvMFX2iQEq2UcTSBgwzP2Eq1+dsy42oea15nASIWeF
H7RGGS3u0WPtWJ/IkQmQRxhLG43pz/GEgI5zYTDt4f+9QR+sIpkCmsX1vwJRG/GBHX7auDBhevDL
YAwnpGBMCB3KMZ/QIcjAcQqmceGQItm0bI07iDqjXqjOilubUFbfHO+jZtbYbwgUZi7EKJLXr5HL
YkZfhdfEgsmgIFYPTM14utgsg/yTluxttUE23zZPCcwhx45NGmDVbhFyAIPriOz88sszQnb3dnee
PSMTKLVXOETpbCqHQxvx9R4YvmBkLZpNXrpyucCnfgtykIcBSqGzxTq0HXQS6y8+ewtHp2SYPHwk
Q9mWQ4IsXljOnm996jvIhea88Lrw0z+Lwav07SJ3RfY6COigN50klfpmTJAPmp26pkwgOTCLB3Xf
J9l/7HRrxzKZUV4XtiGjx/haAjr93hb0RG2FT88lgoJXBRL00BhRhAUmibKduV2hCuTWRTIssAyS
AcI+UGCAv+meCBFvmyZrQjwJqaiJLynklATcw3cySeAxSMEr8IKqqpukK8NkZaTwjTjyStZTwtdX
Ioo0ACsDg0V0hWDmOznZnswvr4pXsE2jCkord2jdKMMCHxXqIOakQBXG7m0rQ9jlXVVQcINTGUSv
3ynrVtnFQtsmJWycFpKaBXbyUhXCjuApQ4IzWKqw8OiMsiV1ZduLjWJVCFs5V4Yo9T9fUxMrnMsp
+jkWPfNivHxGAxtuJXlN5b18duFb8z9X/M/cHqMjaA55VTPOXK+iJ1h21LFHMNxrb+Cv2x43pDFv
8QRc7xx0OrXjw5SI+bVmvES5VNEI9BgddvNqzlTeebWoM1lFXiXG2XQPNzLPgXNe+VTyLXQDi5H6
5pXNSHfMZ245bE6EK+JsAsnmW3R5fEBwjwSnFNfBj8IxzG6O6u1Xn+j8beZ8iNwQD2pFM0nJ+/D/
Z5u/69pff5xt7X+onO18GJY+kZcwIZ2fHYtPNzws2/PBSNAMmGBBBFKso7uBRuO8UT88R3aPGNsi
KYKtPLCuJQL1Eg4xgoKI4hdz2F0oBbU2e5rIq3KTlrn004+U4l2UaAEp0bw2jVu4xDaIsL7PzkIO
JZzPQ/5L87JJpmZz3tsYJNOhuUVKZ6XSJsxGvhDP2t/fxo2UK234lzWZmH0NNxO2ib8FkWjys8KP
5HfIrtgYm80MRhLIm6u7X7chqHhWLAWcXkrZIDTo0b/OimSLvJ6vSV4GyX8qEce/MF0CGsNybG8f
KgP6NilW/PGkAnP8slPkpD/psyJFntPi5p+OSZ5uFUvk9ZxSC8YFzH+J/n/Xc8ZfAGTjck/3C9aA
0KUg7dJ0PSgQ9Myha07IGEB+RV5X+uZlxZ6ORmT39c870JpQdpsE8PxXp9YlRv9VCRuZSDSA/niy
Qf/2NyKhJ20YV7uEJYyEVKGTvt4A9TLZKJ9BgwK+MIOROPLHBuk7xHZ80jfBSjYhYxZu0dkmiUqs
Vd+1iDMYyMQgFyyHcsCbVptsbBik3iSbmCF8l3aLHLUocXbmgEqMq/6rDaO/Eaez7kKDzsrlM/g8
Q8vnE8xZyFj/E6v+U5l9WTb9inPgfZGyYew2zoR6liLjlg7hgmgjnkF7v9w4Oei+k/NVBDXp+mRD
YrxxJvRFGbQM1RHRCGKxi2chgPZZ8db+DH1tY4ds7JKNp2TjGdl4Tjb2yMY/yMYLsvHLAv2QohZw
OLAWwTrYYzC3mYV3zZoL8hRNrI53EtULZQBZVgwZRZomqO6deRpfNKyyQRZjETbZXOlyalBUcLwq
Fmhc0UysgTMbMMwHMxoowNCY4Oo5t1rKWwiFcGQJmvms8AOkYNMScYiCjmEjz8RQ1qRBBFQ/Y71v
lstjy/Mwh5ZtjKZ9ejYBartIkw4sUpgzAZ7hwAUVLjqPYw3Ir1QY6FgAlo2yb15Ltft7QMWIf5Aa
PbezQzatoe3AXGZLSupZNOkPsbRATkub3QZl2ad8djJBQbDIYMPJJuZO0rZMBzllWLH2XuxpEwO6
pD29pnslt3TH0EpdiHURX87odDFL+diu48+oQrTJjG6cUkKybFroqBnE0ordLe+VXxSO461024Ti
VpZzzV7mm41kyEUO2JCmPLGMxec+T1c790kBQMa50K1VmMdMaQEhy8yjbmd/72dZMxr/G866ZkFw
nlnYrPQZ4P8wS3uYpd2TWdptKJ5v1jaDy8Ms7u7O4uZpNmlW9zSTKZ8BQ9gEBWhFYgyIRhTjP843
Ktt0QrNN5E0CZzSCbA7wpJuSjKeXgtP13levbw7orhsnYdz+lW+yDZEk1dA9k14pInzBfwilHkQo
wTHL8OyiQ49ey1HCozlEdeqFqLeTiHIzhKRt5xDVngS5qNCzBXQ6W74IqzZyvEtQxWH6GGUCJOWu
YEjFc278I6iS4LNvGg4I96EZBWXs4HUDiYEgWUmag2aLcrOXpG2rErz6oIiOdxeSZNAngUgsvZRR
+Mf/rE+vCagyevkjy/zkJQL8GgC+hVDfj2B6n1R1G0dk0GX+rBsVNKVc6culZC20VFqp8TKlX046
b5HFErMlEPPaoiaP/hXmiQOwX8DYMi8tZ+qxe1He0iMYpgviObbhTgy6ToSnsdJSGDB9piypCmSJ
yv1R4qTjUnMa1OhMrWeDrGCIK19nhR/Gl+HVJYIWXUBn4/ema8LAptHuBaO4B/OADKLxUCmMkPKJ
0vBAaXGrBE1Trkh5YKMPEtLOc7JeWG34jR1UKMfQG8kO2X3y5B9kZ2//2e7+k2eFjjN1DRNSGKbt
mTAavj1pbILAx8PxZOsxwa+pjRPcx71B/zGOF1uFQxhJYZgUaTAW6U/BrHbwZym4S+fYOFTuk812
7eCoUW/WyOGbI3LarH2oVbcKx07fGuDVDpxI4c0+apP3AOMwvxpPPZ+4pg8DA5rtIAhj6JQtpMDT
pyMmvXAUXBDpo3RAGhlDd4Pc4YXjMukYF+bIN91C4dQzySZ8QMVAxCGYyZ4zNkGgZxlUM+GNIewB
8OfCucJIU0gCVVsudKGSHZxnSkYCnn4NXpR1aS/0CNrekIxOBnFjvFlvwD9sfdckxfAUrPd1LC32
GtJ4hEE5zfJpd1AtLgN40EqT9YvnXgK8zgrBelLR+xHKfd59TxeHytvyV5bMMZE/DouYByYHuDbq
h+2D9keUI31hrNcQLbu8sIhoRy87ib6NM6tstKEWVQPehe6aFXOs41Bt+aaGQ3SlSH6k1zD5lAEU
m0nH7uDdxmBNj/BVtK2YWbv8Sj0Vs/Riq7o0eMB+u2wuqu1TmFFUF8sw0Az06cgHvry2pB0U3hqg
JGNRRRTsBnKQtKJaOay9hYk91sfjSq15RH/1SwtPPtQloHr8nFLPA/FstfYymh/5o4xjN41FCNP9
kWAjCOL/Ydn0fl+TuC288LRI5qGBV8Y9UidyDayuOMFGG5YqVouxzFDDI1QrbjI8+1STd8lMCoZa
36yfTO3PtnNlFyXdQrf7XvKNxhVrmJl7gU8z7AU+nXcvMFNrSHuBedRDJkVLW7Xw+7KdgSZH8XS5
nR2vy8KnQGcFrAWyZSg+jbi54ZsLxW20ysiRY4BtKTX2VvmHmA1M6HFysDIx8hTrnV3NLi6rCpPF
9D+vuJjd91JJgy4BJQXylWX3wVDFSNTJxABvh+RXNCppxYU7sAEmonhB2Qgjy+3YCdoxr+aj1ghb
W1u+0xmTfRhlxZycfApYlm51EEHVVKBelSoqs0YowyjkGFhOzeXdMStcQ57b/csMvTvgk5ceXuGg
GHg+Wfl4yOTkMRJE2r1/Bb9z4BWDOWWbHeSIIxi6oSNO+hkGr7RcUrY5dMXMKOWNu+xSG9RTtXXy
sd58W4a5Mcw/nxC8zDw2tZ5ll1nShWpPTFaXzQ5V1caiYwM7/pZBcuAOZzGpQdNCF/48+3r0jMRs
dsOGW48T6Vr+suxkXn3HK3sXgoSbNmzDeImdJSnxt69q6IbLVTNNSG/g0/2BC3+86DoB6rl7WGDN
DQotdvyCoVr8hvF62arI4dhqDscdYRQtVzzXwEXrzsnB0Yz1Q193h6Yf01WddvUVTV9vdmekBQOY
tA5/nRHD6f0JPKozYoCUCj8H22zVO7VXRW1RJUevaBfJf2rtTr3VfFU8uLacMUlWDum5ug2j0u6T
J3vazo62u1ckR63q6XFtZjGZSLzVPoEK7geTGnLSePOqWCTVKvyjtXZhMmg7mue7pj30LzQYx6aG
KZzYncMk6bzTOm1Xa0XSOMIkwyLz6oYqLTzvO+ch1WgNlhY66Bmr/ZHVk9I3Hf8Ck/sO6Zmk79jM
5cQnKEapvAi8VVIAl3Q1FWDJrDs8H0nvp2bKP67SBJtDfHNgfx+9cBHbGi1qoqJGR5ZFUoos7dFD
bWSTbVkwxpvoCguM1pHpk83Nbdxop3tS22DH4v7KfztEIm5tleL80v8DSfTkBk1OvVdtAztgkcjT
LBZhbZjUO6JN/HlZQOorapEPes7U7k/I5pep45v0PIk3NDTHXigzvEAs6ULZoMdYwpJsBwt9wXad
NsGjLHjCL41diZ2BCaILWG3zEm3i0QZSpAcHt5T5KpFZIOIYRKMY/3C4V3peH50BUjdCSyRHF3+e
ZiyXGJ2nWQ6mLiZKdLPkScaHDc+7uOG5MrdCc6ACbxtThZ7uWmi5fdS76nAoc2nibojYbvWDN6IH
b0QP3ogevBE9eCO6F96IMo0Ci/v9yVlc3oVa2p9R/hLzLpo4AbuQ76Ocxa2ovUQfveN+kvIu5wqr
czGfSvlLXC1S5vW/lLO4VehgbonP7aspX2nMg9MqW0u+mPJtGiwikZZv2XU3SJtlmZGeolx+NbHn
OH6pQP0ZY4747pFm4A7n0NylEWDkWeZG+9KlYpnafY6LprMb0LLx0g0UehLua2ta3gn00dDsufqc
KZzen4k9OSqQnoDDX9EFYUaDOs7SjoxJqfD09jpLQ2PfpJl4WPa6i8teQn2yKzATxQNJn4ez3kbi
ober4RBOwT/C6vQWNnRv5cWzYzus/CkSosE8EeiJz5fO6HlKomgwT8TeTVQmCIN45MsxfqZElwN5
guEQHdKbbkqSaDBPRB97UScIg6RC+7hUnl5oKVgU2sYzbSmlDsNEa+ByTEpLiKAQkXTVUR1dDuQJ
6JMv6uhhkID2RO+zJZ0UcEfDeTK2aqJOIoXJUmYIiLWA5afWvggSnE3/SxpnEcQjQ+eY0NcE1Ami
wWHbzsCoHMgTDBx9fJ7WB+RAnkC/Nq/91BSR0PBduNuURiJG+NbcxPH8CT5dSPNeeEk2j2pvTpvk
pg/fI/3riWuyyFTJ0vNU3g0pl8tb4ZQrUKd9+kRtF1T5pe5adO3/xrZGNxhxaotZWRBH6OArC4wg
3fOm48CPg0gNv3UyHDk9fC4+zBlmuQo9ewjqfGZWxESx+3ViAhShBlw2VuCblQPcfKTDAR4yo1uR
UsYfgXlm9c0TSVZ90HWn5o2ilD7SV1nMxwN7PSWN5OY3y7+4A9nourrt4bhfxVcAV5chaMrWJCJd
n4xQ+KpEPnpbazZbskDDsdGW8g51e7hAr6PXKXIC5Fofblzc8q9wheaU57C/budSYL459H7fNaHA
Wpc8uX7x/MlgsPeELGCczSFI0sm665lJjUzJAvzfAPffRJnzQq2uPE60EwuJj2d3qdxlVmHCRHfF
Vq1DhaBvPWLRmoVs1y710RSU+DduU5SMWmZOsZEKuaa1gbJg9thX4oUON28ct20ajttfRgjkOirl
3ilXqpkyqlbGQ61YdwzjRU6KNRATVavwbzmmV2ud6sFJTXtf+/hbq33UmXuUFQny7UWV2vFh7Uj7
99z5YAmaB8e1vLNSb1UbtYP24kCvN2OdKS1i67R7/zsEYip7l6BcVJ3il51n/SdP8usUTFDYLcam
r+NLtrFu0az91j5t1OaG4XGte3B+0q69qX/ICYYxAZibnb+nTcubKBvKBBe16t19+uxZPigLBYUo
w7UyBcrqzXpXO2y1uhW8TKDhinNtpsKJQALT0MNqnS6kPM5Z/SH3887HZvfgwzmVsrgiPPxYgz/3
W8XxlssGPsFFreL2nuel4kJBIfhs8wofKY9hr3NSq9YPGtWDTo218ty467ber0bHVd+1/54aLmih
bBjjTNQQe/7LnpkPxIQcybZ0TWZwxjAGA+LJQbsz/zD6qNo6Pmy0qu8b9U53NSB71HlfPzmurYb5
zaMLE3cJIg4a8pppJmT1HaNhef7K+I/16w7es8Dn4BvAu0mfvV+ZOINP3B03f2lxSGrU9ezCQxpu
CHNs3t9BTfTXjIa7YJMyrBm5We6hpFDrcG+wUuseasfwY/Fm/ZCy/AF/a/Vmc7ZRpmbZqb9tHnRP
2/fc/sFKzoYSykEJkL3nL/ICCBMSndbh/4kRifb9d4sZ2h9weeHvaZmIesw++WJsUjTFwMxx9hVI
CtEwAJtFQsN9awSR/WyNELJR90YwEHPqjZKksBEMvAOR2NbBiqlCyHp21b/JxoAxMnV3wTIaOsCq
jQ55c88ODKWO61ct15iOIF8oqAOG6iLnGmjumtDPVlNX73Tvom0O/tfe1fUmCEPRd38FrzNxX4lx
8WGLc6AmGgyauWVPFaswoJgWlizxx++2oKCDKQNGTPYK4fb0lnta2nMvmGKi464L0ZYZHD8NKcFz
DocmE4+amHE9wLVAlwFcmgkhcSgYrgHxPab81KXcc6j/8/eI+QTJ5aPpwEQyRbdaRVF02EpEzyyR
ngOyUHyi83cipoWqWAUVPqlh3aeCJjR8Aq6Ug8l3n1ipB6CCkYbcvyN3gR20rpIozy0cWP5wYD+E
Q3NZVDiww3BYNfhW6veAIFwVLb8Mpg8ZXoNSlhVgaShPbyoOxABFeVOMjb0eJs+wUOHTJKabImQi
TwHog34MJiVKU1gpvQDI8U7wV/YPJFIi0ZkpLu2pm/PjpDCy87HS1kgyL92honhp106cmUT2wCEz
afKoI3Ymq2Yl/ku6DmOuPlO7x5S75fMTDIuB1qdqsfbgzNPXBAaiGiIrPMUsy+q/yJVxhMZfL46p
zfYlM2E9t3K+oa9mk+K2y6JOMuzohsU/Z2zziM9ThvMD2WeuPwsjPy9zhfU/akIt2JY2yHMd4RmT
gI/MBYwLDMEyXPNf1hTE+H8ciQWXKZZc0ub/nxRVx8CPjSXcbgS3IYAvxLQhEl9WgDBoRArKdcEA
SfNPaaOOVQUmjkfqWphIyJM64/HwFfwtJqN2X5joYxvojYsj7qO01Xq9Lr39NuFwWxD3ttnMkTK6
zX/cFRUUmPbSK3cNZSk5mVR4MGYcrkVmvwBZDJjuo2kBAA==
--=-=-=--

\start
Date: Fri, 2 Mar 2007 12:59:39 +0100 (CET)
From: Waldek Hebisch
To: Martin Rubey
Subject: Re: Problem compiling wh-sandbox

> Waldek Hebisch writes:
> 
> > > Dear all,
> > > 
> > > I still cannot compile wh-sandbox.
> > > 
> > > I did a symbolic link of gcl in build-improvements 436 into wh-sandbox. make
> > > complains after a short while...
> > > 
> > > Please help,
> > > 
> > 
> > FYI I test using out of source build with gcl-2.6.7 and with gcl from
> > build improvements around 370 (but the eaxt version of gcl should not
> > make significant difference).
> > 
> > I wander if you started from clean tree.  
> 
> I did a 
> 
> make distclean
>

I just checked, and unfortunatly in wh-sandbox make distclean (and relatives
like make clean) are broken: they does not clean src subdirectory.

In my build tree I do not see |atom| function in the translated Lisp --
I think that your build went wrong due to use of stale files.

> > I am looking at your report, but it will take some time.
> 
> That's a pity. The reason why I wanted to rebuild is that I need aldor
> support. In principle, aldor did work, but was unusable since running aldor
> functions yielded tons of messages like
> 
> (Entering C28-axextend-<=
> Returning from C28-axextend-<=)
> 
> I suspect this is due to the fact that I used experimental patches by Peter
> Broadbery to make aldor extend working (it didn't work out though).
> 
> Of course I wanted to build the most recent sandbox...
> 
> In any case, I attach the output of configure and make.
> 
> Two things: 
> 
> * does it matter which version of noweb I use (Tim Daly's modified or the
> original one)?

That should not matter -- IIRC the modification affected only Latex output,
and now Latex files are fixed to not require Tim's change.

> 
> * I did not make install gcl. But, in fact, looking at make's output, gcl seems
>   to work, doesn't it?
> 

AFAICS you copied gcl source tree into wh-sandbox and make just build fresh
gcl from sources.

\start
Date: 02 Mar 2007 13:14:23 +0100
From: Martin Rubey
To: Waldek Hebisch
Subject: Re: Problem compiling wh-sandbox

Waldek Hebisch writes:

> > Waldek Hebisch writes:

> I just checked, and unfortunatly in wh-sandbox make distclean (and relatives
> like make clean) are broken: they does not clean src subdirectory.

So, I should do a fresh checkout? Or is there a simple way to clean it
otherwise?

> > * I did not make install gcl. But, in fact, looking at make's output, gcl
> > seems to work, doesn't it?
> > 
> 
> AFAICS you copied gcl source tree into wh-sandbox and make just build fresh
> gcl from sources.

yes.

\start
Date: 02 Mar 2007 17:04:59 -0500
From: Camm Maguire
To: Gabriel Dos Reis
Subject: Re: GCC/GCL warning messages

Greetings!

Gabriel Dos Reis writes:

> Tim Daly writes:
> 
> | Camm,
> | 
> | I'm building the next Axiom release. During the GCL build I see a large
> | number of messages that read:
> | 
> | gcl_defmacro.c:In function `L12':
> | gcl_defmacro.c:79: warning: dereferencing type-punned pointer will
> |  break strict-aliasing rules
> | 

[ Note:  Back from one month out of office ]

Thanks for the heads up.  I cannot reproduce -- perhaps my gcc is out
of date -- will update to Debian unstable and retry.

> | C99 language semantics now assume that pointers to different types
> | point to different memory locations, which is obvious nonsense, but
> | part of the new standard.
> 
> That statement is obviously untrue. 
> 
> The non-aliasing rule, which has always been there since I don't know
> when -- certainly, it is part of C89, and it is not a C99 invention --
> says that the following is undefined behaviour
> 
>       double z;
>       *(long*)&z = 1;
>       printf ("%g", z);
> 
> That makes perfect sense.  Why would you think it is nonsense?
> 
> | You might want to add -fno-strict-aliasing option to the GCC command line.
> 
> Instead of papering over the incorrectness, I would suggest to fix it.
> 

Agreed.

\start
Date: 02 Mar 2007 17:06:47 -0500
From: Camm Maguire
To: Bill Page
Subject: Re: Request for testing (Win32 users)

Bill Page writes:

> Earlier Gregory Vanuxem wrote:
>
> > I have uploaded a version of Axiom built on top of SBCL for
> > Windows (32 bits).
> >
> > It can be downloaded from:
> > http://perso.orange.fr/parabola/axiom-sbcl-win.tar.bz2
> > ...
>
> On February 12, 2007 11:25 AM Gregory Vanuxem wrote:
> > ...
> > Le dimanche 11 f=E9vrier 2007 =E0 19:31 -0500, Bill Page a =E9crit :
> > >
> > > It works. Great job. I think this is a great step forward
> > > for a fully ANSI-compliant common lisp implementation of Axiom.
> > > I can't resist to ask: Have you tried building this version of
> > > Axiom with GCL in ANSI mode?
> >
> > No, I dropped support of GCL because of spurious bugs: (cond ...)
> > handled strangely (a runtime problem apparently). But I added
> > some modifications to allow it to run on the "ANSI" version of
> > GCL. They are not tested of course.
> >
>
> Thanks. I think the GCL main developer Camm Maquire would be
> strongly motivated to help with ensuring that an ANSI version
> of Axiom works with GCL, especially as a means to test and
> improve GCL's support for ANSI. As I recall he is away for a
> few more weeks but we should expect some comment from him on
> this when he returns.

Greetings!  Yes indeed -- we'll make sure any axiom ansi improvements
work.  Please feel free to forward specific issues to me or to one of
the lists. (Still am not receiving either reliably, alas.)

\start
Date: 02 Mar 2007 17:07:07 -0500
From: Camm Maguire
To: Bill Page
Subject: Re: [Maxima] windows-only read patch (was: error in ./configure when building gcl 2.6.7 onUbuntu)
Cc: Vadim V. Zhytnikov

Greetings!  Any progress here?

Take care,

Camm Maguire writes:

> Greetings!
> 
> Bill Page writes:
> 
> > Camm,
> > 
> > What are the symptoms of this change? What problem is it
> > intended to correct? How can I test it? Is it sufficient
> > if I can build Axiom on windows after this change?
> > 
> 
> The code is intended to fix read-char-no-hang, which had been broken
> for a long time.  This caused Mike Thomas some problem of which I do
> not know the details, hence his ifdef patch with the comment:
> 
> revision 1.14.4.1.2.2.2.4.6.1.6.1.4.3
> date: 2006-06-15 22:26:22 -0400;  author: mjthomas;  state: Exp;  lines: +2 -1
> Band aid fix to stop build failure on Windows.
> ----------------------------
> 
> Vadim found the discrepancy in testing maxima:
> 
> http://www.mail-archive.com/gcl-devel@gnu.org/msg01408.html
> 
> Ideally, I'd like to know that reverting the patch works for both of
> you.  I'd really be pleased if someone could try acl2 as well.
> 
> Alas, due to email chaos, I seem to be disconnected from Vadim.
> 
> Take care,
> 
> 
> > Regards,
> > Bill Page.
> > 
> > > -----Original Message-----
> > > From: Camm Maguire [mailto:Camm Maguire] 
> > > Sent: January 11, 2007 10:51 AM
> > > To: Bill Page
> > > Cc: gcl-devel@gnu.org; list
> > > Subject: Re: [Gcl-devel] Re: error in ./configure when 
> > > building gcl 2.6.7 onUbuntu
> > > 
> > > 
> > > Greetings, and thanks so much!
> > > 
> > > Could you please try reverting:
> > > 
> > > cvs -z9 -q diff -u -r 1.14.4.1.2.2.2.4.6.1.6.1.4.2 -r 
> > > 1.14.4.1.2.2.2.4.6.1.6.1.4.3 read.d
> > > Index: read.d
> > > ===================================================================
> > > RCS file: /cvsroot/gcl/gcl/o/read.d,v
> > > retrieving revision 1.14.4.1.2.2.2.4.6.1.6.1.4.2
> > > retrieving revision 1.14.4.1.2.2.2.4.6.1.6.1.4.3
> > > diff -u -r1.14.4.1.2.2.2.4.6.1.6.1.4.2 -r1.14.4.1.2.2.2.4.6.1.6.1.4.3
> > > --- read.d	7 Jun 2006 15:09:38 -0000	
> > > 1.14.4.1.2.2.2.4.6.1.6.1.4.2
> > > +++ read.d	16 Jun 2006 02:26:22 -0000	
> > > 1.14.4.1.2.2.2.4.6.1.6.1.4.3
> > > @@ -256,6 +256,7 @@
> > >  
> > >  	x = read_object(in);
> > >  	vs_push(x);
> > > +#ifndef _WIN32
> > >  	while (listen_stream(in)) {
> > >  	  object c=read_char(in);
> > >  	  if (cat(c)!=cat_whitespace) {
> > > @@ -263,7 +264,7 @@
> > >  	    break;
> > >  	  }
> > >  	}
> > > -
> > > +#endif
> > >  	if (sharp_eq_context_max > 0)
> > >  		x = vs_head = patch_sharp(x);
> > >  
> > > Take care,
> > > 
> > > 
> > > 
> > > Bill Page writes:
> > > 
> > > > Camm,
> > > > 
> > > > On January 10, 2007 11:12 AM you wrote:
> > > > > ... 
> > > > > export CVSROOT=:pserver:anonymous@cvs.sv.gnu.org:/sources/gcl
> > > > > cvs -z9 -q co -d gcl-2.6.8pre -r Version_2_6_8pre
> > > > > 
> > > > > This is way past due for release.  I am only waiting on a 
> > > volunteer
> > > > > to test a windows-only read patch -- alas our heroic windows
> > > > > volunteer has resigned.  If anyone here can help please let me
> > > > > know.
> > > > > ...
> > > > 
> > > > Both Gaby and I have successfully built Axiom on Windows from a
> > > > recent version of gcl-2.6.8pre. What is required in order to test
> > > > this "windows-only read patch"?

\start
Date: Fri, 2 Mar 2007 16:29:36 -0600 (CST)
From: Gabriel Dos Reis
To: Camm Maguire
Subject: Re: GCC/GCL warning messages

On Fri, 2 Mar 2007, Camm Maguire wrote:

| [ Note:  Back from one month out of office ]

Welcome back!

Please could you hand hold me a bit through GCL?

I'm interested in processing command line arguments used to invoke GCL or
images obtained from saving GCL.  In particular, assume I have a saved
image "foo", and it is invoked like this:

   ./foo --mumble --jumble=bar

How do I get my hand on the command line arguments --mumble and
--jumble=bar?


Furthermore, is there an equivalent of C's main() function in GCL?

\start
Date: 03 Mar 2007 13:00:43 +0100
From: Martin Rubey
To: Tim Daly
Subject: Re: next release

Dear Tim,

there is a new patch for divisors on IssueTracker now. (Issue #340)

I still didn't have time to document the series patch. Maybe later today...

\start
Date: Sat, 03 Mar 2007 14:21:02 -0500
From: Cliff Yapp
To: list
Subject: noweb, lisp, and how to proceed

I have been working (slowly) on getting Waldek's finite state version of
notangle into a literate program, and I think I am making progress.  As
I do so, I would like to raise a question because it may impact how this
should be done.

Looking at the TeX output of the noweb command, it should be possible to
generate this output from Lisp as well and combine both the code
extraction and document generation.  If the scan records some additional
information, and the standard noweb TeX output style is used, this could
reduce the external requirement to only axiom.sty (which I gather
contains the noweb sty file?)

The obvious thing to want to do is generate vanilla TeX or LaTeX and be
able to use a garden variety external LaTeX system to do everything, but
 while page references are (I believe) within the standard package I'm
doubtful the automatic assignment of 2a, 2b, etc. to chunks on a page is
a standard ability - perhaps that's what the sty file defines.  (I
haven't dived into the style file as yet.)  The Lisp system doesn't have
enough information (any, actually) about page numbering to generate
these internally - it must be done as a TeX command (unless someday we
do the typesetting in lisp as well, and I don't think we want to wait
for that.)

My first thought is that a lisp notangle isn't going to be worth the
trouble without the additional noweb ability, since to generate the
documentation we still need noweb and Tim has repeatedly pointed out
document creation is an integral part of literate programming.  Given
that, the thing to do is to proceed to add the ability to generate both
the source file and the TeX file before proposing a literate version of
this for actual inclusion in Axiom.  Would everyone concur?

If so, should the extra step be taken of trying to generate vanilla TeX
or LaTeX that doesn't require an external axiom.sty file?  This might
mean inserting some important definitions into each file to eliminate
the sty file requirement, but I don't know enough yet to say.  Probably
the quickest and simplest thing to do would be to simply generate the
same output noweb does, and continue to require axiom.sty - if that is
OK with everyone I can take a crack at it.

Sorry about the long time it's been taking to get this done - I was sick
this last week and also keeping the finite state tangle straight has
been harder than probably it should be :-/.

\start
Date: 03 Mar 2007 21:53:54 +0100
From: Martin Rubey
To: list
Subject: Re: next release

Dear Tim,

there is now documentation for the power series patch available on IssueTracker
now. (Issue #312)

\start
Date: Sat, 3 Mar 2007 16:04:07 -0600
From: Tim Daly
To: Waldek Hebisch
Subject: .pht file generation

Waldek,

I'm trying to incorporate your changes to generate .pht files
but it doesn't seem to be working. Can you take a moment to
explain what you learned so I can understand what I might have 
missed?

sman -noihere -paste OP.ht

just starts axiom and then hangs. I've tried to trace the process
to understand how it works but have had no luck so far. What is
the relationship between .ht files and .pht files? How should 
the process work? (The .pht process was created during the last
days of the axiom process while the book was being created and
I had nothing to do with that task).

\start
Date: Sat, 3 Mar 2007 19:40:33 -0600 (CST)
From: Gabriel Dos Reis
To: Camm Maguire
Subject: Re: GCC/GCL warning messages

On Fri, 2 Mar 2007, Camm Maguire wrote:

| > | C99 language semantics now assume that pointers to different types
| > | point to different memory locations, which is obvious nonsense, but
| > | part of the new standard.
| >
| > That statement is obviously untrue.
| >
| > The non-aliasing rule, which has always been there since I don't know
| > when -- certainly, it is part of C89, and it is not a C99 invention --
| > says that the following is undefined behaviour
| >
| >       double z;
| >       *(long*)&z = 1;
| >       printf ("%g", z);
| >
| > That makes perfect sense.  Why would you think it is nonsense?
| >
| > | You might want to add -fno-strict-aliasing option to the GCC command line.
| >
| > Instead of papering over the incorrectness, I would suggest to fix it.
| >
|
| Agreed.

Interestingly, ECL -- another CL implementation with KCL as
grandfather -- invokes GCC explicitly with -fstrict-aliasing, e.g. it
is explicitly askign the compiler to exploit aliasing rules, when
compiling generated C codes.

\start
Date: Sun, 04 Mar 2007 14:25:35 +0300
From: Vadim V. Zhytnikov
To: Camm Maguire
Subject: Re: [Gcl-devel] Re: [Maxima] windows-only read patch (was: error in	./configure when building gcl 2.6.7 onUbuntu)

Camm Maguire writes:
> Greetings!  Any progress here?

I only can confirm that removing WIN32 conditional
below really breaks build on Windows.

>>>> +++ read.d	16 Jun 2006 02:26:22 -0000	
>>>> 1.14.4.1.2.2.2.4.6.1.6.1.4.3
>>>> @@ -256,6 +256,7 @@
>>>>  
>>>>  	x = read_object(in);
>>>>  	vs_push(x);
>>>> +#ifndef _WIN32
>>>>  	while (listen_stream(in)) {
>>>>  	  object c=read_char(in);
>>>>  	  if (cat(c)!=cat_whitespace) {
>>>> @@ -263,7 +264,7 @@
>>>>  	    break;
>>>>  	  }
>>>>  	}
>>>> -
>>>> +#endif
>>>>  	if (sharp_eq_context_max > 0)
>>>>  		x = vs_head = patch_sharp(x);
>>>>  

\start
Date: Sun, 04 Mar 2007 15:16:28 +0100
From: Ralf Hemmecke
To: list
Subject: Aldor proves 4 to be prime... :-(

Since "prime?: % -> Boolean" segfaults,
let us test "prime?: Integer -> Partial Boolean".

aldor -q1 -fx -lalgebra -laldor aaa.as
aaa
[T]

Either my Aldor compiler doesn't like me or it looks like a good 
candidate for the general problem that computer algebra faces: Lack of 
well documented programs that everyone could check before trusting a result.

Ralf

---BEGIN aaa.as
#include "algebra"
#include "aldorio"

macro Z == Integer;

main(): () == {
	import from Z;
	b: Partial Boolean := prime? 4;
	stdout << b << newline;
}
main();
---END aaa.as

\start
Date: Sun, 4 Mar 2007 21:29:01 -0500
From: Bill Page
To: list
Subject: Coming Soon: * Aldor open source release

Axiom Developers;

In case you haven't noticed ...

The Aldor web site:

http://www.aldor.org

has a new look and a new message:

News

Feb. 19, 2007

    * v. 1.1-rc (bug fixes) released; 

Coming Soon:

    * Aldor open source release;
    * 64-bit Aldor releases for Linux and Solaris;
    * Aldor Web Demo

Development Public CVS (Coming Soon)

---

and it's own wiki:

http://www.aldor.org/mediawiki

(Warning: The content is still a little sparse.)

Dare we hope that the long wait for an Open Source version of Aldor
is finally (nearly) over?

Does anyone have any idea exactly what "v. 1.1-rc" refers? Note:
The current version of the Aldor compiler is: v1.0.3. Where can
we find v. 1.1-rc?

\start
Date: Sun, 4 Mar 2007 21:53:01 -0500
From: Bill Page
To: Doug Stewart
Subject: RE: Coming Soon: * Aldor open source release

On March 4, 2007 9:46 PM Doug Stewart wrote:
> 
> Bill Page wrote:
> > nyone have any idea exactly what "v. 1.1-rc" refers? Note:
> > The current version of the Aldor compiler is: v1.0.3. Where can
> > we find v. 1.1-rc?
> >
> > Regards,
> > Bill Page.
> >
> >   
> 
> try 
> 
> http://www.aldor.org/downl.html
 

Thanks, but I did try it. At that page I see:

Step 3. Select your OS:

      Linux version 1.0.3 (glibc2.3)
      Linux version (glibc2.2)
      Linux x86 64-bit
      DEC/OSF1 version 1.0.2
      Solaris version 1.0.2
      Linux version 1.1.0 (glibc2.3)
      Solaris version 1.1.0
      Windows gcc version 1.1.0
      Windows MS Visual C version 1.1.0

-------

Where do you see "v. 1.1-rc"? I am blind or just confused?

\start
Date: Sun, 04 Mar 2007 21:56:55 -0500
From: Doug Stewart
To: Bill Page
Subject: Re: Coming Soon: * Aldor open source release

Bill Page wrote:
> On March 4, 2007 9:46 PM Doug Stewart wrote:
>   
>> Bill Page wrote:
>>     
>>> nyone have any idea exactly what "v. 1.1-rc" refers? Note:
>>> The current version of the Aldor compiler is: v1.0.3. Where can
>>> we find v. 1.1-rc?
>>>
>>> Regards,
>>> Bill Page.
>>>
>>>   
>>>       
>> try 
>>
>> http://www.aldor.org/downl.html
>>     
>  
>
> Thanks, but I did try it. At that page I see:
>
> Step 3. Select your OS:
>
>       Linux version 1.0.3 (glibc2.3)
>       Linux version (glibc2.2)
>       Linux x86 64-bit
>       DEC/OSF1 version 1.0.2
>       Solaris version 1.0.2
>       Linux version 1.1.0 (glibc2.3)
>       Solaris version 1.1.0
>       Windows gcc version 1.1.0
>       Windows MS Visual C version 1.1.0
>
> -------
>
> Where do you see "v. 1.1-rc"? I am blind or just confused?
>
> Regards,
> Bill Page. 
>
>   


I was looking at the 1.1    not the 1.1-rc

1.1 is still better than

"The current version of the Aldor compiler is: v1.0.3."

\start
Date: Sun, 4 Mar 2007 21:58:06 -0500
From: Bill Page
To: Doug Stewart
Subject: RE: Coming Soon: * Aldor open source release

Oh, sorry. I didn't go far enough. After selecting

>    (*)   Linux version 1.1.0 (glibc2.3)

and

Do you accept the terms of the license? 	Yes

I do see:

  aldor-linux-i386-1.1.0-rc.bin

Thanks.

Regards,
Bill Page.

> -----Original Message-----
> From: 
> axiom-developer-bounces+bill.page1=synthesis.anikast.ca@nongnu
> .org 
> a@nongnu.org] On Behalf Of Bill Page
> Sent: March 4, 2007 9:53 PM
> To: Doug Stewart
> Cc: 'axiom-dev'
> Subject: RE: Coming Soon: * Aldor open 
> source release
> 
> 
> On March 4, 2007 9:46 PM Doug Stewart wrote:
> > 
> > Bill Page wrote:
> > > nyone have any idea exactly what "v. 1.1-rc" refers? Note:
> > > The current version of the Aldor compiler is: v1.0.3. Where can
> > > we find v. 1.1-rc?
> > >
> > > Regards,
> > > Bill Page.
> > >
> > >   
> > 
> > try 
> > 
> > http://www.aldor.org/downl.html
>  
> 
> Thanks, but I did try it. At that page I see:
> 
> Step 3. Select your OS:
> 
>       Linux version 1.0.3 (glibc2.3)
>       Linux version (glibc2.2)
>       Linux x86 64-bit
>       DEC/OSF1 version 1.0.2
>       Solaris version 1.0.2
>       Linux version 1.1.0 (glibc2.3)
>       Solaris version 1.1.0
>       Windows gcc version 1.1.0
>       Windows MS Visual C version 1.1.0
> 
> -------
> 
> Where do you see "v. 1.1-rc"? I am blind or just confused?

\start
Date: 04 Mar 2007 21:04:45 -0600
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: Coming Soon: * Aldor open source release

Bill Page writes:

| Axiom Developers;
| 
| In case you haven't noticed ...
| 
| The Aldor web site:
| 
| http://www.aldor.org
| 
| has a new look and a new message:
| 
| News
| 
| Feb. 19, 2007
| 
|     * v. 1.1-rc (bug fixes) released; 
| 
| Coming Soon:
| 
|     * Aldor open source release;
|     * 64-bit Aldor releases for Linux and Solaris;
|     * Aldor Web Demo
| 
| Development Public CVS (Coming Soon)

Let's hope this is not one more promise...

| ---
| 
| and it's own wiki:
| 
| http://www.aldor.org/mediawiki
| 
| (Warning: The content is still a little sparse.)
| 
| Dare we hope that the long wait for an Open Source version of Aldor
| is finally (nearly) over?
| 
| Does anyone have any idea exactly what "v. 1.1-rc" refers? 

The standard relase scheme says that "-rc" means "Release Candidate".
Basically, it calls for testers.  If some critical programs are found,
then the release may be delayed, otherwise it goes as the final
release.

| Note:
| The current version of the Aldor compiler is: v1.0.3. Where can
| we find v. 1.1-rc?

\start
Date: 04 Mar 2007 21:06:35 -0600
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: Coming Soon: * Aldor open source release

Bill Page writes:

| On March 4, 2007 9:46 PM Doug Stewart wrote:
| > 
| > Bill Page wrote:
| > > nyone have any idea exactly what "v. 1.1-rc" refers? Note:
| > > The current version of the Aldor compiler is: v1.0.3. Where can
| > > we find v. 1.1-rc?
| > >
| > > Regards,
| > > Bill Page.
| > >
| > >   
| > 
| > try 
| > 
| > http://www.aldor.org/downl.html
|  
| 
| Thanks, but I did try it. At that page I see:
| 
| Step 3. Select your OS:
| 
|       Linux version 1.0.3 (glibc2.3)
|       Linux version (glibc2.2)
|       Linux x86 64-bit
|       DEC/OSF1 version 1.0.2
|       Solaris version 1.0.2
|       Linux version 1.1.0 (glibc2.3)
|       Solaris version 1.1.0
|       Windows gcc version 1.1.0
|       Windows MS Visual C version 1.1.0
| 
| -------
| 
| Where do you see "v. 1.1-rc"? I am blind or just confused?

Maybe 1.1-rc turned into 1.1.0?

\start
Date: 04 Mar 2007 21:17:00 -0600
From: Gabriel Dos Reis
To: Tim Daly
Subject: ANSI Lisp and Axiom (Boot)

Tim --

  The ANSI specification for the IN-PACKAGE syntax dictates that
the argument must be a string, not a symbol.  SBCL gives a fatal
error on that.  Furthermore, the specification also says that the
packages LISP, USER and SYSTEM are no longer required for a
conforming implementation.  Consequently, it is non-portable (and a
potential source of errors) to say something like

        (in-package 'BOOTTRAN :USE '(LISP USER SYSTEM)) 

SBCL gives a fatal error.

I stumbled over those while I was playing with the new configuration
setting for building src/boot with SBCL -- I have not tried ECL yet.
I'm working on a patch. 

\start
Date: Sun, 4 Mar 2007 23:06:47 -0600
From: Tim Daly
To: Gabriel Dos Reis
Subject: ANSI Lisp and Axiom (Boot)

Yeah, Axiom was being rewritten into "common lisp" at the same time
I was (ghost) reviewing the original X3J13 specs. The package stuff
was not solidly defined at that time so I used the code from the
Symbolics Machine. This seemed to conform to the announced spec.

The new ANSI spec breaks Axiom in at least 3 ways, they want strings
as package names, in-package does not create the package and lisp,
system, etc are special.

\start
Date: Mon, 05 Mar 2007 09:20:30 +0100
From: Kai Kaminski
To: Tim Daly
Subject: Re: ANSI Lisp and Axiom (Boot)
Cc: Gabriel Dos Reis


Gaby wrote:
>   The ANSI specification for the IN-PACKAGE syntax dictates that
> the argument must be a string, not a symbol.  SBCL gives a fatal
The hyperspec [1] says that the argument of IN-PACKAGE has to be a
string *designator*, that is either a string or a character or a
symbol. I've tested this with SBCL 1.0.2, CMUCL 19d and Allegro CL
8.0. They all accept any of #:foo, :foo, 'foo or "FOO" as argument to
IN-PACKAGE. It is usually recommended that one uses uninterned (#:) or
keyword (:) symbols rather than interned (') symbols or strings. For
one thing they don't clutter the current package and they also work
well with the "modern mode" of some CLs.

> error on that.  Furthermore, the specification also says that the
> packages LISP, USER and SYSTEM are no longer required for a
> conforming implementation.  Consequently, it is non-portable (and a
> potential source of errors) to say something like
> 
>         (in-package 'BOOTTRAN :USE '(LISP USER SYSTEM)) 
> 
> SBCL gives a fatal error.
That should probably be 

(defpackage #:boottran
  (:use #:cl))

in a file packages.lisp, and then

(in-package #:boottran)


Kai

[1] http://www.lisp.org/HyperSpec/Body/mac_in-package.html

\start
Date: Mon, 05 Mar 2007 09:34:25 +0100
From: Christian Aistleitner
To: Bill Page
Subject: Re: [Aldor-l] Coming Soon: * Aldor open source	release

Hello,

On Mon, 05 Mar 2007 03:29:01 +0100, Bill Page  
Bill Page wrote:

> Does anyone have any idea exactly what "v. 1.1-rc" refers? Note:
> The current version of the Aldor compiler is: v1.0.3. Where can
> we find v. 1.1-rc?

maybe you just caught the aldor webpage in a state of transition.

http://www.aldor.org/downl.html
offers me an option:
   Linux version 1.1.0 (glibc2.3)
. If you'll accept their license, you'll be able to download  
aldor-linux-i386-1.1.0-rc.bin.

\start
Date: 05 Mar 2007 04:05:09 -0600
From: Gabriel Dos Reis
To: Kai Kaminski
Subject: Re: ANSI Lisp and Axiom (Boot)

Kai Kaminski writes:

| Gaby wrote:
| >   The ANSI specification for the IN-PACKAGE syntax dictates that
| > the argument must be a string, not a symbol.  SBCL gives a fatal
| The hyperspec [1] says that the argument of IN-PACKAGE has to be a
| string *designator*, that is either a string or a character or a
| symbol. I've tested this with SBCL 1.0.2, CMUCL 19d and Allegro CL
| 8.0. They all accept any of #:foo, :foo, 'foo or "FOO" as argument to
| IN-PACKAGE.

I'm using SBCL 1.0.2.  Here is what I got when I sent the message:

sbcl --noinform --noprint --eval '(compile-file "exports.lisp" :output-file "exports.o")'
; compiling file "/home/gdr/build/axiom/src/boot/exports.lisp" (written 04 MAR 2007 08:41:33 PM):
; compiling (IN-PACKAGE (QUOTE BOOTTRAN))
; file: /home/gdr/build/axiom/src/boot/exports.lisp
; in: IN-PACKAGE 'BOOTTRAN
;     (IN-PACKAGE 'BOOTTRAN)
; 
; caught ERROR:
;   (during macroexpansion of (IN-PACKAGE 'BOOTTRAN))
;   'BOOTTRAN cannot be coerced to a string.


Which I interpret as an error on using a symbol in place of a string.
How should it be read?

[...]

| > error on that.  Furthermore, the specification also says that the
| > packages LISP, USER and SYSTEM are no longer required for a
| > conforming implementation.  Consequently, it is non-portable (and a
| > potential source of errors) to say something like
| > 
| >         (in-package 'BOOTTRAN :USE '(LISP USER SYSTEM)) 
| > 
| > SBCL gives a fatal error.
| That should probably be 
| 
| (defpackage #:boottran
|   (:use #:cl))
| 
| in a file packages.lisp, and then

Does the file *name* matter?

\start
Date: Mon, 05 Mar 2007 11:38:46 +0100
From: Kai Kaminski
To: Gabriel Dos Reis
Subject: Re: ANSI Lisp and Axiom (Boot)

Gabriel Dos Reis writes:

> Kai Kaminski writes:
>
> | Gaby wrote:
> | >   The ANSI specification for the IN-PACKAGE syntax dictates that
> | > the argument must be a string, not a symbol.  SBCL gives a fatal
> | The hyperspec [1] says that the argument of IN-PACKAGE has to be a
> | string *designator*, that is either a string or a character or a
> | symbol. I've tested this with SBCL 1.0.2, CMUCL 19d and Allegro CL
> | 8.0. They all accept any of #:foo, :foo, 'foo or "FOO" as argument to
> | IN-PACKAGE.
>
> I'm using SBCL 1.0.2.  Here is what I got when I sent the message:
>
> sbcl --noinform --noprint --eval '(compile-file "exports.lisp" :output-file "exports.o")'
> ; compiling file "/home/gdr/build/axiom/src/boot/exports.lisp" (written 04 MAR 2007 08:41:33 PM):
> ; compiling (IN-PACKAGE (QUOTE BOOTTRAN))
> ; file: /home/gdr/build/axiom/src/boot/exports.lisp
> ; in: IN-PACKAGE 'BOOTTRAN
> ;     (IN-PACKAGE 'BOOTTRAN)
> ; 
> ; caught ERROR:
> ;   (during macroexpansion of (IN-PACKAGE 'BOOTTRAN))
> ;   'BOOTTRAN cannot be coerced to a string.
>
>
> Which I interpret as an error on using a symbol in place of a string.
> How should it be read?
Good one. I'll look into this, but I can't find EXPORTS.LISP in my
Axiom tree. I'll download your branch and look for it there.

> [...]
>
> | > error on that.  Furthermore, the specification also says that the
> | > packages LISP, USER and SYSTEM are no longer required for a
> | > conforming implementation.  Consequently, it is non-portable (and a
> | > potential source of errors) to say something like
> | > 
> | >         (in-package 'BOOTTRAN :USE '(LISP USER SYSTEM)) 
> | > 
> | > SBCL gives a fatal error.
> | That should probably be 
> | 
> | (defpackage #:boottran
> |   (:use #:cl))
> | 
> | in a file packages.lisp, and then
>
> Does the file *name* matter?
No, not at all. But it is customary to put your package definition,
i.e. the DEFPACKAGE forms, in a single file called either
PACKAGES.LISP, PACKAGE.LISP or DEFPACKAGE.LISP.

Kai

PS: Lisp is all lower-case nowadays. I only capitalize Lisp identifiers and
file names in my posts to make them stand out from normal text.

\start
Date: 05 Mar 2007 04:44:39 -0600
From: Gabriel Dos Reis
To: Kai Kaminski
Subject: Re: ANSI Lisp and Axiom (Boot)

Kai Kaminski writes:

| Gabriel Dos Reis writes:
| 
| > Kai Kaminski writes:
| >
| > | Gaby wrote:
| > | >   The ANSI specification for the IN-PACKAGE syntax dictates that
| > | > the argument must be a string, not a symbol.  SBCL gives a fatal
| > | The hyperspec [1] says that the argument of IN-PACKAGE has to be a
| > | string *designator*, that is either a string or a character or a
| > | symbol. I've tested this with SBCL 1.0.2, CMUCL 19d and Allegro CL
| > | 8.0. They all accept any of #:foo, :foo, 'foo or "FOO" as argument to
| > | IN-PACKAGE.
| >
| > I'm using SBCL 1.0.2.  Here is what I got when I sent the message:
| >
| > sbcl --noinform --noprint --eval '(compile-file "exports.lisp" :output-file "exports.o")'
| > ; compiling file "/home/gdr/build/axiom/src/boot/exports.lisp" (written 04 MAR 2007 08:41:33 PM):
| > ; compiling (IN-PACKAGE (QUOTE BOOTTRAN))
| > ; file: /home/gdr/build/axiom/src/boot/exports.lisp
| > ; in: IN-PACKAGE 'BOOTTRAN
| > ;     (IN-PACKAGE 'BOOTTRAN)
| > ; 
| > ; caught ERROR:
| > ;   (during macroexpansion of (IN-PACKAGE 'BOOTTRAN))
| > ;   'BOOTTRAN cannot be coerced to a string.
| >
| >
| > Which I interpret as an error on using a symbol in place of a string.
| > How should it be read?
| Good one. I'll look into this, but I can't find EXPORTS.LISP in my
| Axiom tree. I'll download your branch and look for it there.

It is extracted from src/boot/exports.lisp.pamphlet, with Tim listed
as \author.  I don't think it is particular to my branch.

| > [...]
| >
| > | > error on that.  Furthermore, the specification also says that the
| > | > packages LISP, USER and SYSTEM are no longer required for a
| > | > conforming implementation.  Consequently, it is non-portable (and a
| > | > potential source of errors) to say something like
| > | > 
| > | >         (in-package 'BOOTTRAN :USE '(LISP USER SYSTEM)) 
| > | > 
| > | > SBCL gives a fatal error.
| > | That should probably be 
| > | 
| > | (defpackage #:boottran
| > |   (:use #:cl))
| > | 
| > | in a file packages.lisp, and then
| >
| > Does the file *name* matter?
| No, not at all. But it is customary to put your package definition,
| i.e. the DEFPACKAGE forms, in a single file called either
| PACKAGES.LISP, PACKAGE.LISP or DEFPACKAGE.LISP.

src/boot/boothdr.lisp.pamphlet serves similar purpose.

\start
Date: 05 Mar 2007 04:51:36 -0600
From: Gabriel Dos Reis
To: Kai Kaminski
Subject: Re: ANSI Lisp and Axiom (Boot)

Kai Kaminski writes:

[...]

| PS: Lisp is all lower-case nowadays.

yeah, fashion comes and goes. :-)

Those familiar with SBCL and some other lisps will probably notice that
lisp compilers/tools tend to output things in all caps, even when the
original is all lower case.

In this specific case, the iput file src/boot/exports.lisp is in lower
case.  For that matter.

\start
Date: Mon, 05 Mar 2007 12:22:42 +0100
From: Kai Kaminski
To: Gabriel Dos Reis
Subject: Re: ANSI Lisp and Axiom (Boot)

Gabriel Dos Reis writes:

> Kai Kaminski writes:
>
> [...]
>
> | PS: Lisp is all lower-case nowadays.
>
> yeah, fashion comes and goes. :-)
>
> Those familiar with SBCL and some other lisps will probably notice that
> lisp compilers/tools tend to output things in all caps, even when the
> original is all lower case.
Yes. Common Lisp specifies that the reader (!) makes everything
uppercase. By the time the compiler prints an identifier, it doesn't
know anymore how you typed it. If you really want lower case you can
use vertical bars[2]:

CL-USER> '|CamelCaseIdentifier|
|CamelCaseIdentifier|
CL-USER> 

Some Common Lisps offer a so called 'modern mode' nowadays
(eg. Allegro CL), where the reader preserves the case and exports all
standard symbols (eg CL:MAPCAR) in lower case. In fact, you can set
the behaviour of the reader even in CL: see the Hyperspec for details,
in particular [1]. Preserving the case is useful for XML <-> sexp
mappings for example, but sometimes breaks older code.

Kai

[1] http://www.lisp.org/HyperSpec/Body/sec_23-1-2.html
    Simply setting the READTABLE-CASE doesn't really cut it though,
    since you then have to say:

      (WITH-OPEN-FILE (s "blah" :DIRECTION :INPUT) ...)

[2] This is used in Axiom a lot and I must admit that I don't like it
    at all. Either use all lower case, use a lisp with modern mode.

\start
Date: 05 Mar 2007 05:46:48 -0600
From: Gabriel Dos Reis
To: Kai Kaminski
Subject: Re: ANSI Lisp and Axiom (Boot)

Kai Kaminski writes:

| Gabriel Dos Reis writes:
| 
| > Kai Kaminski writes:
| >
| > [...]
| >
| > | PS: Lisp is all lower-case nowadays.
| >
| > yeah, fashion comes and goes. :-)
| >
| > Those familiar with SBCL and some other lisps will probably notice that
| > lisp compilers/tools tend to output things in all caps, even when the
| > original is all lower case.
| Yes. Common Lisp specifies that the reader (!) makes everything
| uppercase.

I know.


Gosh, try to report an issue with the build system and you a get a
full lecture on what does not help you.

\start
Date: Mon, 05 Mar 2007 12:53:03 +0100
From: Kai Kaminski
To: Gabriel Dos Reis
Subject: Re: ANSI Lisp and Axiom (Boot)

Gabriel Dos Reis writes:

> Kai Kaminski writes:
>
> | Gabriel Dos Reis writes:
> | 
> | > Kai Kaminski writes:
> | >
> | > | Gaby wrote:
> | > | >   The ANSI specification for the IN-PACKAGE syntax dictates that
> | > | > the argument must be a string, not a symbol.  SBCL gives a fatal
> | > | The hyperspec [1] says that the argument of IN-PACKAGE has to be a
> | > | string *designator*, that is either a string or a character or a
> | > | symbol. I've tested this with SBCL 1.0.2, CMUCL 19d and Allegro CL
> | > | 8.0. They all accept any of #:foo, :foo, 'foo or "FOO" as argument to
> | > | IN-PACKAGE.
> | >
> | > I'm using SBCL 1.0.2.  Here is what I got when I sent the message:
> | >
> | > sbcl --noinform --noprint --eval '(compile-file "exports.lisp" :output-file "exports.o")'
> | > ; compiling file "/home/gdr/build/axiom/src/boot/exports.lisp" (written 04 MAR 2007 08:41:33 PM):
> | > ; compiling (IN-PACKAGE (QUOTE BOOTTRAN))
> | > ; file: /home/gdr/build/axiom/src/boot/exports.lisp
> | > ; in: IN-PACKAGE 'BOOTTRAN
> | > ;     (IN-PACKAGE 'BOOTTRAN)
> | > ; 
> | > ; caught ERROR:
> | > ;   (during macroexpansion of (IN-PACKAGE 'BOOTTRAN))
> | > ;   'BOOTTRAN cannot be coerced to a string.
> | >
> | >
> | > Which I interpret as an error on using a symbol in place of a string.
> | > How should it be read?
> | Good one. I'll look into this, but I can't find EXPORTS.LISP in my
> | Axiom tree. I'll download your branch and look for it there.
>
> It is extracted from src/boot/exports.lisp.pamphlet, with Tim listed
> as \author.  I don't think it is particular to my branch.
So I stuffed up twice. The file is indeed not particular to your
branch. I simply forgot the .PAMPHLET suffix when running FIND.

The IN-PACKAGE form doesn't work, since it doesn't evaluate its
argument[1]. Hence you must not quote the symbol. The following work
like a charm (in my case it chokes because there is no such package):

(in-package boottran)

I'm sorry for spreading confusion when claiming that 'foo should
work. It does work in Allegro CL and CMUCL, and apparently I've
overlooked the warnings they issue.

Of course, as I said before, it is usually recommended to use
uninterned or keyword symbols, hence

(in-package #:boottran)

The EXPORT statement in that file should probably just be appended to
the DEFPACKAGE statement like so:

(defpackage #:boot-translator
  (:nicknames #:boottran)
  (:use #:cl)
  (:export #:boottocl
           #:boottocllines
           #:boottoclc
           #:boottoclclines
           #:boottomc
           #:compile-boot-file
           #:boot
           #:eval-boot-file
           #:bo
           #:fbo
           #:fev
           #:stout
           #:steval
           #:sttomc
           #:fc
           #:boot-compile-definition-from-file
           #:boot-eval-definition-from-file
           #:boot-print-definition-from-file
           #:boclam
           #:bootclam
           #:bootloop
           #:defuse
           #:xref))

> | > [...]
> | >
> | > | > error on that.  Furthermore, the specification also says that the
> | > | > packages LISP, USER and SYSTEM are no longer required for a
> | > | > conforming implementation.  Consequently, it is non-portable (and a
> | > | > potential source of errors) to say something like
> | > | > 
> | > | >         (in-package 'BOOTTRAN :USE '(LISP USER SYSTEM)) 
> | > | > 
> | > | > SBCL gives a fatal error.
> | > | That should probably be 
> | > | 
> | > | (defpackage #:boottran
> | > |   (:use #:cl))
> | > | 
> | > | in a file packages.lisp, and then
> | >
> | > Does the file *name* matter?
> | No, not at all. But it is customary to put your package definition,
> | i.e. the DEFPACKAGE forms, in a single file called either
> | PACKAGES.LISP, PACKAGE.LISP or DEFPACKAGE.LISP.
>
> src/boot/boothdr.lisp.pamphlet serves similar purpose.
It should probably be renamed, but that's none of my business.

\start
Date: 05 Mar 2007 06:18:43 -0600
From: Gabriel Dos Reis
To: Kai Kaminski
Subject: Re: ANSI Lisp and Axiom (Boot)

Kai Kaminski writes:

[...]

| Of course, as I said before, it is usually recommended to use
| uninterned or keyword symbols, hence
| 
| (in-package #:boottran)

I'll probably do something like that or use the string form.

\start
Date: Mon, 05 Mar 2007 08:19:24 -0400
From: Humberto Zuazaga
To: Gabriel Dos Reis
Subject: Re: ANSI Lisp and Axiom (Boot)
Cc: Kai Kaminski

Gabriel Dos Reis wrote:

> Gosh, try to report an issue with the build system and you a get a
> full lecture on what does not help you.

How's this? In cltl1 gcl IN-PACKAGE will create a package if it did not
exist. In ANSI lisps, you need to DEFPACKAGE the package first. The
defpackage coerces the argument to a string, and the package is created
with that string as a name.

CL-USER> (in-package #:foo)
"The name \"FOO\" does not designate any package."
; Evaluation aborted
CL-USER> (defpackage #:bar)
#<PACKAGE "BAR">
CL-USER> (in-package #:bar)
#<COMMON-LISP:PACKAGE "BAR">
BAR>

The same code should cause ANSI gcl to choke too. In fact, ANSI gcl
won't let you use #:bar as a package name.

$ gcl
GCL (GNU Common Lisp)  2.6.7 ANSI    May 31 2006 04:48:55
Source License: LGPL(gcl,gmp), GPL(unexec,bfd)
Binary License:  GPL due to GPL'ed components: (READLINE BFD UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter

Use (help) to get some basic information on how to use GCL.

>(in-package #:foo)

Error in EVAL [or a callee]: The variable #:FOO is unbound.

Fast links are on: do (use-fast-links nil) for debugging
Broken at IN-PACKAGE.  Type :H for Help.
 1 (Abort) Return to top level.
dbl:>>:q

Top level.
>(defpackage #:bar)

#<"BAR" package>

>(in-package #:bar)

Error in EVAL [or a callee]: The variable #:BAR is unbound.

Fast links are on: do (use-fast-links nil) for debugging
Broken at IN-PACKAGE.  Type :H for Help.
 1 (Abort) Return to top level.
dbl:>>:q

Top level.
>(in-package "BAR")

#<"BAR" package>

BAR>

\start
Date: 05 Mar 2007 06:53:09 -0600
From: Gabriel Dos Reis
To: Humberto Zuazaga
Subject: Re: ANSI Lisp and Axiom (Boot)
Cc: Kai Kaminski

Humberto Zuazaga writes:

| Gabriel Dos Reis wrote:
| 
| > Gosh, try to report an issue with the build system and you a get a
| > full lecture on what does not help you.
| 
| How's this? In cltl1 gcl IN-PACKAGE will create a package if it did not
| exist. 

That is what I suspected -- since we all have functioning Axiom.
Thanks for the confirmation!

| In ANSI lisps, you need to DEFPACKAGE the package first. 

Yes; in my current experiment I've merged src/boot/boothdr.lisp and
src/boot/npextras.lisp into a single file.  That file is loaded in a
fresh Lisp image, and the result is saved, then re-used to build
bootsys.  That apparently is much simpler than current scheme and
saves us from many non-portability issues.

[...]

| The same code should cause ANSI gcl to choke too.

I haven't built ANSI GCL; I'll try.  Maybe it would be a good think to
have as a configure option for helping check portability issues.

| In fact, ANSI gcl won't let you use #:bar as a package name.

Ah!  Now, I know why I don't use Lisp for everyday programming :-/

I'll stick to the string form.
Many thanks!

\start
Date: Mon, 5 Mar 2007 09:41:38 -0500
From: Bill Page
To: Ralf Hemmecke
Subject: RE: Coming Soon: * Aldor open source release

On March 5, 2007 9:20 AM Ralf Hemmecke wrote:
> ...
> Bill Page wrote: 
> > Development Public CVS (Coming Soon)
> 
> > Dare we hope that the long wait for an Open Source version
> > of Aldor is finally (nearly) over?
> 
> It is closer, but I would not be overly optimistic. I haven't 
> heard that the license issue has already been settled. And
> before that you will probably not see any source...

Has anyone ever heard exactly what this "license issue" is?
What exactly is the problem? Who objects to making Aldor open
source? And what needs to be done to satisfy those objections?

> 
> ... except perhaps SumIt. I currently have the sources in 
> order to check whether they are complete and compilable and
> everything. If I find some time slot I'll try to check it
> and send message to Stephane Dalmas so that he can put the
> sources on the web.
> 


??? Why not put it on the web now so everyone or anyone can
check it. It seems that every time someone hesitates just
because they think it might not be "ready", everyone ends up
waiting until they almost loose all interest. If it was made
available as soon as possible without checking every little
nut and bolt then other people can share in making it right.

I think there is some problem here of philosophy or psychology
that is not compatible with mass collaboration. :-(

\start
Date: 05 Mar 2007 10:50:20 -0500
From: Camm Maguire
To: Vadim V. Zhytnikov
Subject: Re: [Maxima] [Gcl-devel] Re: windows-only read	patch (was: error in	./configure when building gcl 2.6.7 onUbuntu)

Greetings!

Vadim V. Zhytnikov writes:

> Camm Maguire writes:
> > Greetings!  Any progress here?
> 
> I only can confirm that removing WIN32 conditional
> below really breaks build on Windows.
> 
> >>>> +++ read.d	16 Jun 2006 02:26:22 -0000	
> >>>> 1.14.4.1.2.2.2.4.6.1.6.1.4.3
> >>>> @@ -256,6 +256,7 @@
> >>>>  
> >>>>  	x = read_object(in);
> >>>>  	vs_push(x);
> >>>> +#ifndef _WIN32
> >>>>  	while (listen_stream(in)) {
> >>>>  	  object c=read_char(in);
> >>>>  	  if (cat(c)!=cat_whitespace) {
> >>>> @@ -263,7 +264,7 @@
> >>>>  	    break;
> >>>>  	  }
> >>>>  	}
> >>>> -
> >>>> +#endif
> >>>>  	if (sharp_eq_context_max > 0)
> >>>>  		x = vs_head = patch_sharp(x);
> >>>>  
> 
> 

Thanks Vadim!  Is there a way, in windows, to determine if data is
ready for reading in from a terminal interface?  The FIONREAD ioctl
works on linux, and there is the following non-blocking generic code
which appears in force on windows:

#ifdef LISTEN_USE_FCNTL
  do { int c = 0;
  FILE *fp = strm->sm.sm_fp;
  int orig;
  int res;
  if (feof(fp)) return TRUE;
  orig = fcntl(fileno(fp), F_GETFL);
  if (! (orig & O_NONBLOCK ) ) {
    res=fcntl(fileno(fp),F_SETFL,orig | O_NONBLOCK);
  }
  c = getc(fp);
  if (! (orig & O_NONBLOCK ) ){
    fcntl(fileno(fp),F_SETFL,orig );
  }
  if (c != EOF)
    { 
      ungetc(c,fp);
      return TRUE;
    }
  return FALSE;
  } while (0);
#endif

that is, presuming the configure check

check for listen using fcntl

returns yes.  Can you tell me if the latter is true or not, and then
if so, what are the symptoms of breakage in light of the code above?

\start
Date: Mon, 5 Mar 2007 17:41:05 +0100 (CET)
From: Waldek Hebisch
To: Martin Rubey
Subject: Re: Problem compiling wh-sandbox

> Waldek Hebisch writes:
> 
> > > Waldek Hebisch writes:
> 
> > I just checked, and unfortunatly in wh-sandbox make distclean (and relatives
> > like make clean) are broken: they does not clean src subdirectory.
> 
> So, I should do a fresh checkout? Or is there a simple way to clean it
> otherwise?
>

I think the safest way is just to do fresh checkout.  The build may work
if you remove just generated .clisp files from src/interp subdirectory
(in principle other things should be correctly re-made), but any troubles
are likely to take you more time than fresh checkout...

\start
Date: Mon, 5 Mar 2007 18:49:08 +0100 (CET)
From: Waldek Hebisch
To: Tim Daly
Subject: Re: .pht file generation

> Waldek,
> 
> I'm trying to incorporate your changes to generate .pht files
> but it doesn't seem to be working. Can you take a moment to
> explain what you learned so I can understand what I might have 
> missed?
> 
> sman -noihere -paste OP.ht
> 
> just starts axiom and then hangs. I've tried to trace the process
> to understand how it works but have had no luck so far. What is
> the relationship between .ht files and .pht files? How should 
> the process work? 

Basic things:

1) You need to set up AXIOM environment variable
2) ht.db must contain information from .ht pages involved
3) there were multiple bugs which prevented the process from working:
  - gcl socket issues (the patch to sockio.lisp.pamphlet from 2006-11-03
    fixed the problem for me)
  - hyperdoc crash fixed (on 2006-11-26) by using strcpy
  - sman trying to set terminal setting on exit (caused hang when run
    in the background)
  - race in hyperdoc protocol (this one is worked around using -noihere
    and additionlly I added code to detect lost race, so that one gets
    sensible error message)

In general bugs in Axiom/sman/hyperdoc (or even in input pages) may cause
the .pht generation process to hang.

What is done: hypertex parses .ht file extracting from it Spad commands
(\spadpaste construct and similar).  Hypertex writes out extacted commands
to .input file and sends them (via sockets) to AXIOMsys for execution.
Then hypertex recevies AXIOMsys answers (again via sockets) and writes
them out to .pht file.

In short: .pht file caches Axiom output, so that hypertex can show
output of various commands without invoking AXIOMsys.

How the process works:

sman starts AXIOMsys and hypertex, giving special -k -ip options to
hypertex.  The main work is done by make_input_file_from_page routine
which calls print_paste (or print_graph_paste) for specific hunks.
Much of the work in those routines is simple bookkeeping to correctly
generate names of hunks in .pht file and generating boilerplate. 
AXIOMsys answers are read by get_spad_output routine.  At the end
hypertex send kill command to AXIOMsys.

In my experience hangs were caused by hypertex and AXIOMsys getting
out of sync.  Namely, hyperdoc protocol is mostly synchronous, meaning
that each side waits for expected answer from the other side.  However,
it seems that on errors AXIOMsys throws, and the corresponding catch is
outside protocol handler, so on error AXIOMsys may forget that it should
answer.  Also, there is race in the protocol and sman may interpret some
new request as answer to old request giving a misterous error (and
possibly hang later).

Since all communication is done via sockets any socket problems may
give errors or hangs.

\start
Date: 05 Mar 2007 13:37:44 -0500
From: Camm Maguire
To: Gabriel Dos Reis
Subject: Re: GCC/GCL warning messages

Greetings!

Gabriel Dos Reis writes:

> On Fri, 2 Mar 2007, Camm Maguire wrote:
> 
> | [ Note:  Back from one month out of office ]
> 
> Welcome back!
> 
> Please could you hand hold me a bit through GCL?
> 
> I'm interested in processing command line arguments used to invoke GCL or
> images obtained from saving GCL.  In particular, assume I have a saved
> image "foo", and it is invoked like this:
> 
>    ./foo --mumble --jumble=bar
> 
> How do I get my hand on the command line arguments --mumble and
> --jumble=bar?
> 

A good example is gcl-top-level, for example:

(si::get-command-arg "-compile")

> 
> Furthermore, is there an equivalent of C's main() function in GCL?
> 

A good idea is to set si::*top-level-hook*, like in hol88:

      (progn
	 (setq si::*top-level-hook* (lambda nil (tml)))
         (gbc t)
         (si::save-system file))

'tml is their top level.

\start
Date: 05 Mar 2007 13:46:50 -0500
From: Camm Maguire
To: Gabriel Dos Reis
Subject: Re: GCC/GCL warning messages

Greetings!

Gabriel Dos Reis writes:

> On Fri, 2 Mar 2007, Camm Maguire wrote:
> 
> | > | C99 language semantics now assume that pointers to different types
> | > | point to different memory locations, which is obvious nonsense, but
> | > | part of the new standard.
> | >
> | > That statement is obviously untrue.
> | >
> | > The non-aliasing rule, which has always been there since I don't know
> | > when -- certainly, it is part of C89, and it is not a C99 invention --
> | > says that the following is undefined behaviour
> | >
> | >       double z;
> | >       *(long*)&z = 1;
> | >       printf ("%g", z);
> | >
> | > That makes perfect sense.  Why would you think it is nonsense?
> | >
> | > | You might want to add -fno-strict-aliasing option to the GCC command line.
> | >
> | > Instead of papering over the incorrectness, I would suggest to fix it.
> | >
> |
> | Agreed.
> 
> Interestingly, ECL -- another CL implementation with KCL as
> grandfather -- invokes GCC explicitly with -fstrict-aliasing, e.g. it
> is explicitly askign the compiler to exploit aliasing rules, when
> compiling generated C codes.
> 

Great!  Isn't this enabled by -O2 and higher anyway:

     `-O2' turns on all optimization flags specified by `-O'.  It also
     turns on the following optimization flags:
          -fforce-mem
          -foptimize-sibling-calls
          -fstrength-reduce
          -fcse-follow-jumps  -fcse-skip-blocks
          -frerun-cse-after-loop  -frerun-loop-opt
          -fgcse   -fgcse-lm   -fgcse-sm
          -fdelete-null-pointer-checks
          -fexpensive-optimizations
          -fregmove
          -fschedule-insns  -fschedule-insns2
          -fsched-interblock -fsched-spec
          -fcaller-saves
          -fpeephole2
          -freorder-blocks  -freorder-functions
          -fstrict-aliasing
          -falign-functions  -falign-jumps
          -falign-loops  -falign-labels


Still can't reproduce any aliasing warnings with gcl 2.6.8pre and gcc
4.1.2.  Could someone please tell me what I'm missing?

\start
Date: Mon, 5 Mar 2007 13:25:18 -0600 (CST)
From: Gabriel Dos Reis
To: Camm Maguire
Subject: Re: GCC/GCL warning messages

On Mon, 5 Mar 2007, Camm Maguire wrote:

| Greetings!
|
| Gabriel Dos Reis writes:
|
| > On Fri, 2 Mar 2007, Camm Maguire wrote:
| >
| > | [ Note:  Back from one month out of office ]
| >
| > Welcome back!
| >
| > Please could you hand hold me a bit through GCL?
| >
| > I'm interested in processing command line arguments used to invoke GCL or
| > images obtained from saving GCL.  In particular, assume I have a saved
| > image "foo", and it is invoked like this:
| >
| >    ./foo --mumble --jumble=bar
| >
| > How do I get my hand on the command line arguments --mumble and
| > --jumble=bar?
| >
|
| A good example is gcl-top-level, for example:
|
| (si::get-command-arg "-compile")
|
| >
| > Furthermore, is there an equivalent of C's main() function in GCL?
| >
|
| A good idea is to set si::*top-level-hook*, like in hol88:
|
|       (progn
| 	 (setq si::*top-level-hook* (lambda nil (tml)))
|          (gbc t)
|          (si::save-system file))
|
| 'tml is their top level.

\start
Date: Mon, 5 Mar 2007 13:28:31 -0600 (CST)
From: Gabriel Dos Reis
To: Camm Maguire
Subject: Re: GCC/GCL warning messages

On Mon, 5 Mar 2007, Camm Maguire wrote:

| Greetings!
|
| Gabriel Dos Reis writes:
|
| > On Fri, 2 Mar 2007, Camm Maguire wrote:
| >
| > | > | C99 language semantics now assume that pointers to different types
| > | > | point to different memory locations, which is obvious nonsense, but
| > | > | part of the new standard.
| > | >
| > | > That statement is obviously untrue.
| > | >
| > | > The non-aliasing rule, which has always been there since I don't know
| > | > when -- certainly, it is part of C89, and it is not a C99 invention --
| > | > says that the following is undefined behaviour
| > | >
| > | >       double z;
| > | >       *(long*)&z = 1;
| > | >       printf ("%g", z);
| > | >
| > | > That makes perfect sense.  Why would you think it is nonsense?
| > | >
| > | > | You might want to add -fno-strict-aliasing option to the GCC command line.
| > | >
| > | > Instead of papering over the incorrectness, I would suggest to fix it.
| > | >
| > |
| > | Agreed.
| >
| > Interestingly, ECL -- another CL implementation with KCL as
| > grandfather -- invokes GCC explicitly with -fstrict-aliasing, e.g. it
| > is explicitly askign the compiler to exploit aliasing rules, when
| > compiling generated C codes.
| >
|
| Great!  Isn't this enabled by -O2 and higher anyway:

Yes, it is in the official release.  Some people prefer to mention it
explicitly, in case their vendor have turned it off by default -- I
think that is the case for some *BSD systems.

[...]

| Still can't reproduce any aliasing warnings with gcl 2.6.8pre and gcc
| 4.1.2.

I saw it many times in the past (notably with some GCC-3.3.x compilers).
I upgraded my OS this week-end and my development machine is not
accessible at this time.  But, I'll post a build log once I'm
back to normal.

\start
Date: Wed, 7 Mar 2007 11:46:29 -0500
From: Bill Page
To: Francois Maltey
Subject: RE: Tests of sage.

Francois,

I am sorry that is has taken a bit of time but I promised to let you
know when the problem using Axiom with Sage that you reported back
in January is fixed. I just tried the new release 2.3 of Sage today
and I can confirm that the problem is gone, however I can not say
yet exactly what has changed in the new verison that makes this now
work for me.

http://modular.math.washington.edu/sage

In my testing the problem seemed to have something to do with the
communication between Sage and Axiom that is handled by an interface
called pexpect.

For example in Sage on my OpenSuse 10.2 system after I typed an
Axiom command such as:

  sage: axiom('1+1')

the system would hang until I pressed control-C. Thereafter, if I
repeated the command, or other Axiom commands, everything would work
fine.

The affect of this problem in the notebook() interface was more
severe since when the notebook tries to run the first Axiom command
there is no way to interrupt and restart this computation that did
not repeat the same problem.

The problem seemed to occur on some systems but not on others. For
example it failed for me on OpenSuse 10.2 linux but it works on the
axiom-developer.org server and William Stein told me a few weeks ago
that he could not reproduce the problem on his systems. Perhaps there
has been a subtle change in the way pexpect works. I will discuss
this with William.

In any case, you should be able to upgrade your installed version of
Sage to the latest version by the following simple command:

  $ sage -upgrade

Sage will download all of the necessary updates and automatically
rebuild the system.

The version of Axiom I used for testing this was also installed using
Sage via the command:

  $ sage -i axiom4sage-0.1.spkg

This downloads and builds a version of the Axiom build-improvments
branch dated '2006-10-10'. I hope to release a new package
'axiom4sage-0.2.spkg' based on the current source from the wh-sandbox
branch some time in the near future - sooner if anyone else expresses
some interest in this.

Please let me know if you have any more problems.

Regards,
Bill Page.

On February 1, 2007 10:25 PM Bill Page wrote:

> 
> Thank you for testing this.
> 
> I have been able to reproduce this problem. The same thing
> happens to me. I am looking into the problem and I will let
> you know a solution soon.
> 
> Regards,
> Bill Page.
> 
> On January 31, 2007 9:31 AM Francois Maltey wrote:
> > 
> > Many thanks for your pretty mail, Bill :
> > 
> > > Please see the examples at:
> > > 
> > > http://sage-notebook.axiom-developer.org/axiom
> > > 
> > > I would be happy to answer any questions you have.
> > 
> > So I download sage (a 130 MB file), untar and make the system.
> >
> 
> What version of Sage did you download? As far as I can see the
> most recent version of Sage (version 2.0) is "only" about 88 Mb.
> 
> http://modular.math.washington.edu/sage/dist/src/index.html
> 
> or
> 
> http://sage.scipy.org/sage/dist/src/index.html
> 
> I just finished downloading, untar and make of Sage-2.0 on a
> OpenSuSE 10.2 linux system.
>  
> > As root I add axiom binary in the $PATH, 
> > and add also the main sage directory in the $PATH.
> > 
> > I can run axiom -nox -nocle in a root-xterm.
> >
> 
> On my system I have Axiom built from a recent version of the
> build-improvements branch.
>  
> > As root I can run sage everywhere 
> > run install_scripts('/usr/local/bin') in sage, 
> > and lauch notebook()
> > 
> > In x11 I open http://localhost:8000 with firefox.
> > I get the screen of the sage system.
> > I can type commands in bluebox.
> > 
> > But I almost never obtain any results. 
> 
> Make sure to press Shift+Enter to execute the contents of
> the bluebox.
> 
> > Neither without system when I test 2*3
> > neither for axiom when I type in two lines %axiom \\ 2+3.
> >
> 
> I have very similar problems. But if I only enter Sage
> commands, everything seems to work. If I try Axiom commands
> then it fails. I see an error traceback in the Sage session
> log. These same commands work properly on the Sage server
> which is apparently running the same version of Sage but a
> different version of Axiom.
>  
> > Return adds a break-line.
> 
> Use Shift+Enter to execute a cell.
> 
> > Evaluate rerun the session but result remains green box.
> > 
> > What I forget ?
> > 
> 
> I think you are doing everything correct. There seems to be
> some problem with Sage and/or Axiom. I recall that I had some
> problem with readline when I first tested this and I am quite
> sure that the 'axiom4sage-0.1.spkg' that is used on the Sage
> server was built using gcl with readline disabled. I will
> check this and get back to you.

\start
Date: Wed, 7 Mar 2007 13:45:34 -0500
From: Bill Page
To: list
Subject: Re: Tests of sage.

-----Original Message-----

On 3/7/07, Bill Page wrote:
> I am sorry that is has taken a bit of time but I promised to let you
> know when the problem using Axiom with Sage that you reported back
> in January is fixed. I just tried the new release 2.3 of Sage today
> and I can confirm that the problem is gone, however I can not say
> yet exactly what has changed in the new verison that makes this now
> work for me.

I distinctly remember fixing the problem.

> For example in Sage on my OpenSuse 10.2 system after I typed an
> Axiom command such as:
>
>   sage: axiom('1+1')
>
> the system would hang until I pressed control-C. Thereafter, if I
> repeated the command, or other Axiom commands, everything would work
> fine.

I think my fix was just to send an extra line to axiom on startup.
This should work on all platforms.

> The problem seemed to occur on some systems but not on others. For
> example it failed for me on OpenSuse 10.2 linux but it works on the
> axiom-developer.org server and William Stein told me a few weeks ago
> that he could not reproduce the problem on his systems. Perhaps there
> has been a subtle change in the way pexpect works. I will discuss
> this with William.

I don't know what caused the problem.  It wasn't a change in pexpect,
since I have not upgraded pexpect in over a year, I think.  I must have
changed something in the SAGE expect interfaces that causes this
problem.   In any case, it's fixed now. Sorry it took a while.

\start
Date: Mon, 12 Mar 2007 22:04:19 -0400
From: Bill Page
To: list
Subject: FW: [Om] CFP: Prog. Lang for Mechanized Mathematics Workshop

I think this workshop might be of interest to Axiom developers...

Please note that the Axiom Workshop (Thursday, June 14 to Saturday,
June 16) fits nicely with some of the other related activities at
RISC Summer program:

http://www.risc.uni-linz.ac.at/about/conferences/summer2007

for example:

CoCoA School (June 18-22)
http://cocoa.dima.unige.it/conference/cocoa2007

in case you might want to prolong your stay in Hagenberg-Linz.

Perhaps the Axiom Workshop should be cross-listed at some of
these other websites?

Regards,
Bill Page.

-----Original Message-----
From: om-bounces@openmath.org [mailto:om-bounces@openmath.org] On Behalf =
Of
Jacques Carette
Sent: March 12, 2007 5:10 PM
To: OCaml; Haskell Cafe; omdoc@mathweb.org; calculemus-ig@ags.uni-sb.de;
seworld@cs.colorado.edu; SymbolicNet@mcs.kent.edu; om@openmath.org
Subject: [Om] CFP: Prog. Lang for Mechanized Mathematics Workshop


Programming Languages for Mechanized Mathematics Workshop
As part of Calculemus 2007
Hagenberg, Austria

[http://www.cas.mcmaster.ca/plmms07/]

The intent of this workshop is to examine more closely the intersection
between programming languages and mechanized mathematics systems (MMS). =
By
MMS, we understand computer algebra systems (CAS), [automated] theorem
provers (TP/ATP), all heading towards the development of fully unified
systems (the MMS), sometimes also called universal mathematical =
assistant
systems (MAS) (see Calculemus 2007).

There are various ways in which these two subjects of programming =
languages
and systems for mathematics meet:

Many systems for mathematics contain a dedicated programming language. =
For
instance, most computer algebra systems contain a dedicated language =
(and
are frequently built in that same language); some proof assistants (like =
the
Ltac language for Coq) also have an embedded programming language. Note =
that
in many instances this language captures only algorithmic content, and
declarative or representational issues are avoided.

The mathematical languages of many systems for mathematics are very =
close to
a functional programming language. For instance the language of ACL2 is =
just
Lisp, and the language of Coq is very close to Haskell. But even the
mathematical language of the HOL system can be used as a functional
programming language that is very close to ML and Haskell. On the other
hand, these languages also contain very rich specification capabilities,
which are rarely available in most computation-oriented programming
languages. And even then, many specification languages ((B, Z, Maude, =
OBJ3,
CASL, etc) can still teach MMSes a trick or two regarding =
representational
power.

Conversely, functional programming languages have been getting "more
mathematical" all the time. For instance, they seem to have discovered =
the
value of dependent types rather recently. But they are still not quite =
ready
to 'host' mathematics (the non-success of docon being typical). There =
are
some promising languages on the horizon (Epigram, Omega) as well as some
hybrid systems (Agda, Focal), although it is unclear if they are truly
capable of expressing the full range of ideas present in mathematics.
Systems for mathematics are used to prove programs correct. (One method =
is
to generate "correctness conditions" from a program that has been =
annotated
in the style of Hoare logic and then prove those conditions in a proof
assistant.) An interesting question is what improvements are needed for =
this
both on the side of the mathematical systems and on the side of the
programming languages.

We are interested in all these issues. We hope that a certain synergy =
will
develop between those issues by having them explored in parallel.
These issues have a very colourful history. Many programming language
innovations first appeared in either CASes or Proof Assistants, before
migrating towards more mainstream languages. One can cite (in no =
particular
order) type inference, dependent types, generics, term-rewriting,
first-class types, first-class expressions, first-class modules, code
extraction, and so on. However, a number of these innovations were never
aggressively pursued by system builders, letting them instead be =
developped
(slowly) by programming language researchers. Some, like type inference =
and
generics have flourished. Others, like first-class types and first-class
expressions, are not seemingly being researched by anyone.

We want to critically examine what has worked, and what has not. Why are =
all
the current ``popular'' computer algebra systems untyped? Why are the
(strongly typed) proof assistants so much harder to use than a typical =
CAS?
But also look at question like what forms of polymorphism exists in
mathematics? What forms of dependent types exist in mathematics? How can =
MMS
regain the upper hand on issues of 'genericity'? What are the biggest
barriers to using a more mainstream language as a host language for a =
CAS or
an ATP?

This workshop will accept two kinds of submissions: full research papers =
as
well as position papers. Research papers should be nore more than 15 =
pages
in length, and positions papers no more than 3 pages. Submission will be
through EasyChair. An informal version of the proceedings will be =
available
at the workshop, with a more formal version to appear later. We are =
looking
into having the best papers completed into full papers and published as =
a
special issue of a Journal (details to follow).

Important Dates

April 25, 2007: Submission Deadline
June 29-30, 2007: Workshop

Program Committee

Lennart Augustsson [Credit Suisse]
Wieb Bosma[Radboud University Nijmegen, Netherlands]
Jacques Carette (co-Chair) [McMaster University, Canada]
David Delahaye [CNAM, France]
Jean-Christophe Filli=E2tre [CNRS and Universit=E9 de Paris-Sud, France]
John Harrison [Intel Corporation, USA]
Markus (Makarius) Wenzel [Technische Universit=E4t M=FCnchen, Germany]
Freek Wiedijk (co-Chair) [Radboud University Nijmegen, Netherlands]
Wolfgang Windsteiger [University of Linz, Austria]

Location and Registration

Location and registration information can be found on the Calculemus web
site.

http://www.risc.uni-linz.ac.at/about/conferences/Calculemus2007

\start
Date: 13 Mar 2007 02:04:14 -0500
From: Gabriel Dos Reis
To: list
Subject: Boot and other Lisps

  As of revision 445, bootsys from src/boot in build-improvements
can be built with GCL, SBCL, CLISP.  Just configure with the option

     --with-lisp=<your lisp command>

That was an opportunity to clean up src/boot/Makefile.pamphlet a bit.
I merged boothdr.lisp, npextras.lisp and exports.lisp in a single
file, initial-env.lisp, which I augmented with functions to interface
with the build machinery.

I've not tempted to build src/interp yet -- and it is not going to be
an easy party.

Building bootsys with SBCL and CLISP is amazingly fast, compared to
building with GCL.

\start
Date: Tue, 13 Mar 2007 05:31:27 -0700 (PDT)
From: Cliff Yapp
To: Gabriel Dos Reis
Subject: Re: Boot and other Lisps

> 
> Howdy!
> 
>   As of revision 445, bootsys from src/boot in build-improvements
> can be built with GCL, SBCL, CLISP.  Just configure with the option
> 
>      --with-lisp=<your lisp command>

EXCELLENT!

> That was an opportunity to clean up src/boot/Makefile.pamphlet a bit.
> I merged boothdr.lisp, npextras.lisp and exports.lisp in a single
> file, initial-env.lisp, which I augmented with functions to interface
> with the build machinery.

Interface in the sense of getting variable settings from the autoconf
system?

> I've not tempted to build src/interp yet -- and it is not going to be
> an easy party.

No.  Is the plan to alter the boot files to use Shoe, or simply tweak
the interp system as is to run?

> Building bootsys with SBCL and CLISP is amazingly fast, compared to
> building with GCL.

Really?  SBCL is not surprising, but I would have expected Clisp to be
a lot slower.  Interesting.

Thanks Gaby for all of your hard work!

\start
Date: 13 Mar 2007 08:46:52 -0500
From: Gabriel Dos Reis
To: Cliff Yapp
Subject: Re: Boot and other Lisps

Cliff Yapp writes:

| --- Gabriel Dos Reis wrote:
| 
| > 
| > Howdy!
| > 
| >   As of revision 445, bootsys from src/boot in build-improvements
| > can be built with GCL, SBCL, CLISP.  Just configure with the option
| > 
| >      --with-lisp=<your lisp command>
| 
| EXCELLENT!
| 
| > That was an opportunity to clean up src/boot/Makefile.pamphlet a bit.
| > I merged boothdr.lisp, npextras.lisp and exports.lisp in a single
| > file, initial-env.lisp, which I augmented with functions to interface
| > with the build machinery.
| 
| Interface in the sense of getting variable settings from the autoconf
| system?

Currently, interface in the sense of abstracting over the various many
ways to save Lisp image, compile Lisp files, and build executable out
of previously compiled Lisp files.  It seems every single Lisp
implementation wants to explore the implementation-defined space on its own.

| > I've not tempted to build src/interp yet -- and it is not going to be
| > an easy party.
| 
| No.  Is the plan to alter the boot files to use Shoe, or simply tweak
| the interp system as is to run?

Two overriding goals:
   (1) build all the rest of src/interp with Shoe
   (2) correct and simplify the interface with the C world (possibly
       reusing various Lisp extensions where available)

| > Building bootsys with SBCL and CLISP is amazingly fast, compared to
| > building with GCL.
| 
| Really?  SBCL is not surprising, but I would have expected Clisp to be
| a lot slower.  Interesting.

Well, for the specific case of src/boot, that is what happened.  I was
quite impressed -- with GCL, I would have got the time to make coffee;
I couldn't with CLISP and SBCL.

I found SBCL notes and diagnostics sometime interesting.

| 
| Thanks Gaby for all of your hard work!

You're welcome.

Another project would be to start annotating Boot codes with type, so
that the translation can automatically insert proclamations and
assertions.  But that is not for today, I've got lot to catch on
during this break. 

\start
Date: 13 Mar 2007 09:08:22 -0500
From: Gabriel Dos Reis
To: Tim Daly
Subject: cfuns.lisp and ELF platforms

Tim --

  src/interp/cfuns.lisp contains conditional defentries for KCL
further discriminated by :elf.  Those functions are:

   hashString
   hashCombine

There is no explanation of why the discrimination on :elf is needed.
Do you happen to remember?

\start
Date: Tue, 13 Mar 2007 18:00:45 +0100 (CET)
From: Waldek Hebisch
To: Camm Maguire
Subject: Creating executables which use Lisp compiler

I wonder if there is a preferred procedure to create executables
with gcl such that the resulting executable can use Lisp
compiler.  More precisely, using defualt setting of si::*system-directory*
may lead to problems.  Namely, if gcl is installed in a privite
directory (not readable by other users) then the resulting 
executable give errors during C compile.  This is because
gcl (unconditionally) passes to C compiler -I directive pointing
to original system directory.  However when directory specified 
in -I directive exists but is not readable by the user invoking
the compiler gcc treats this as an error.

This problem appeared when trying to install Axiom, see:

http://lists.nongnu.org/archive/html/axiom-developer/2007-02/msg00212.html

but I belive is a general problem for gcl created executables.

So the question is what is the preferred solution, in particular
if creator of the executable should change the value of
si::*system-directory* ?

\start
Date: Tue, 13 Mar 2007 19:34:46 +0100 (CET)
From: Waldek Hebisch
To: list
Subject: Issue 336

The fix for bug 336 looks fine.  But one thing in original
code looks strange: we are testing if s>0.  s belongs to some
ring which  has RetractableTo(Z) and we test that if s can
be retracted to Z.  Then use s in comparizon.  AFAIU the 
comparison is taken from R and in principle can be quite
different than comparison in Z.  However, the logic really
requires comparison in Z.  So I think that we should 
use here t (that is value retracted to Z) in comparison.

\start
Date: Tue, 13 Mar 2007 19:57:01 +0100
From: Gregory Vanuxem
To: Gabriel Dos Reis
Subject: Re: Boot and other Lisps

Hello Gaby,

Le mardi 13 mars 2007 =E0 02:04 -0500, Gabriel Dos Reis a =E9crit :
> Howdy!
>
>   As of revision 445, bootsys from src/boot in build-improvements
> can be built with GCL, SBCL, CLISP.  Just configure with the option
>
>      --with-lisp=<your lisp command>
>
> That was an opportunity to clean up src/boot/Makefile.pamphlet a bit.
> I merged boothdr.lisp, npextras.lisp and exports.lisp in a single
> file, initial-env.lisp, which I augmented with functions to interface
> with the build machinery.

I'm very happy of these modifications, this is great, thanks! I hope
works in this direction will be continued. On another direction I'm also
happy of works on the compiler and am reasonably impatient to see some
things.

A part from that, apparently, you forgot to commit the file
initial-env.lisp in the repository and I found a minor typo in btpile2
(v\documentclass line 1).

You have also added documentation here and there which is a yet another
good thing (I stop here my pseudo congratulations, this become
insane :-). In the version of Axiom that I uploaded I added the
Makefile.pamphlet from src/boot, which is the only documentation as far
as I know of the boot, more precisely Shoe, language.

I have a question about an issue in this language. You have probably
encountered a problem with the redefinition of the *package* variable,
at least with SBCL. From what I have read you're using directly (setq
*package* something), this prevents the addition of the *packages*
variable to the list of locally bound variable in the 'prog'. My
question is as follow, is it possible to declare a variable as special
without adding it to this list of variables ? Such that it can be used
normally i.e if you want to assign a new value you can use the :=
operator and, important thing, it's not bound to nil at the beginning of
the prog ?

If I remember correctly it's possible with variables that begin with a
dollar sign but in the case of Lisp special variable (generally of the
form *something*) I have not found how. During my small work on boot I
began to modify the boot language (fluid and local variables) and
stopped there mainly because I do not have a clear meaning of what I
really wanted to do, what to do with these Lisp special variables (do we
really want to manipulate these variables in boot) and, of course,
because you, Waldek and probably others are working in these areas and I
do not have the necessary knowledge to work on these issues (I always
postponed my "study" of the shoe/boot/spad compilers).
If this is not possible actually to do what I'm asking, maybe you (or
any others) have some thoughts about this (this is not restricted to
bootsys, in the interpreter some special variables are used too,
*standard-output* among others (though *standard-output* is relatively
important since setting it to nil break the compilation process under
SBCL).

Just curious,

Greg

>
> I've not tempted to build src/interp yet -- and it is not going to be
> an easy party.
>
> Building bootsys with SBCL and CLISP is amazingly fast, compared to
> building with GCL.

\start
Date: 13 Mar 2007 20:38:30 +0100
From: Martin Rubey
To: Waldek Hebisch
Subject: Re: Issue 336

Waldek Hebisch writes:

> The fix for bug 336 looks fine.  But one thing in original
> code looks strange: we are testing if s>0.  s belongs to some
> ring which  has RetractableTo(Z) and we test that if s can
> be retracted to Z.  Then use s in comparizon.  AFAIU the 
> comparison is taken from R and in principle can be quite
> different than comparison in Z.  However, the logic really
> requires comparison in Z.  So I think that we should 
> use here t (that is value retracted to Z) in comparison.

Yes, we are actually interested whether first l or first l - second l are a
positive integer, i.e., we should use t there.

If the second argument k is negative, we could return zero. However, I vaguely
remember that the definition in terms of Gamma functions does not yield this as
a limit, at least not for any n. Do you happen to remember?

In fact, if n=k, the definition in terms of Gamma functions always gives one,
no matter whether n is negative of not...

Axiom gives 0 currently, due to the definition of ibinom. This looks all quite
inconsistent...

\start
Date: 13 Mar 2007 15:22:08 -0500
From: Gabriel Dos Reis
To: Gregory Vanuxem
Subject: Re: Boot and other Lisps

Gregory Vanuxem writes:

| Hello Gaby,
|
| Le mardi 13 mars 2007 =E0 02:04 -0500, Gabriel Dos Reis a =E9crit :
| > Howdy!
| >
| >   As of revision 445, bootsys from src/boot in build-improvements
| > can be built with GCL, SBCL, CLISP.  Just configure with the option
| >
| >      --with-lisp=<your lisp command>
| >
| > That was an opportunity to clean up src/boot/Makefile.pamphlet a bit.
| > I merged boothdr.lisp, npextras.lisp and exports.lisp in a single
| > file, initial-env.lisp, which I augmented with functions to interface
| > with the build machinery.
|
| I'm very happy of these modifications, this is great, thanks!

You are welcome.

| I hope
| works in this direction will be continued. On another direction I'm also
| happy of works on the compiler and am reasonably impatient to see some
| things.

Yes, I'm trying to allocate some fixed amount of time per week to work
on Axiom, and ISO C++ stuff tends to take over :-)
I do hope to quickly get to src/interp and start improving on the Spad
compiler (which many people are waiting for).

| A part from that, apparently, you forgot to commit the file
| initial-env.lisp in the repository and I found a minor typo in btpile2
| (v\documentclass line 1).

Gah!  Just fixed.  Many thanks for testing and reporting.  That is
very much appreciated.

| You have also added documentation here and there which is a yet another
| good thing (I stop here my pseudo congratulations, this become
| insane :-).

I should have done more of that -- but then I need to buy time :-)

| In the version of Axiom that I uploaded I added the
| Makefile.pamphlet from src/boot, which is the only documentation as far
| as I know of the boot, more precisely Shoe, language.

Yes, I intend to improve on that.  I face this dilemma: Produce an
academic style definition of Shoe, or are more to the rigid
style of the existing documentation.  I end up doing the latter. But I
believe the former is the long term solution.

I have not had (yet) the chance to look at your package -- shame on me :-(

| I have a question about an issue in this language. You have probably
| encountered a problem with the redefinition of the *package* variable,
| at least with SBCL.

Yes; that refined my understanding of Shoe :-)
And I forgot to put more documentation as planned :-(

| From what I have read you're using directly (setq
| *package* something), this prevents the addition of the *packages*
| variable to the list of locally bound variable in the 'prog'.

Yes, that ois correct.

| My
| question is as follow, is it possible to declare a variable as special
| without adding it to this list of variables ? Such that it can be used
| normally i.e if you want to assign a new value you can use the :=
| operator and, important thing, it's not bound to nil at the beginning of
| the prog ?

Not that I'm aware of, if my understanding of Shoe is correct.

When, I stumbled on that problem, I went back and looked at the Shoe code m=
ore
carefully.  First Shoe, translates the body of a function, by
shoCompTran1.  That function updates global states that keep track of
fluid variables (those declared with the "fluid" or "local" type),
global variables (those beginning with $), and local variables (those
that are assigned to in the body of the function).
Then Shoe considers that anything that is on the fluid variables list
or local variables list really is a local variable, therefore put it
on the PROG header.  That exhausts all the handling of variables.

My first reaction, when I ran into that problem was to extend the
algorithm for special handling of the Lisp convention.  Then I
imagined opposition from more senior contributors and decided to go
with the solution I like the least (i.e. ugly), direct use of SETQ.

[ By the way, I would like to get rid of the PROG annotation when
  there is no variable in the list -- very common situation. ]

I see your question as suggesting that we should have the translator
honor the Lisp convention -- that would be the most logical thing to
do.  If people agree, I can add that capability to the translator --
and of course, I'll document it :-)

| If I remember correctly it's possible with variables that begin with a
| dollar sign but in the case of Lisp special variable (generally of the
| form *something*) I have not found how.

I think your observation is correct.

| During my small work on boot I
| began to modify the boot language (fluid and local variables) and
| stopped there mainly because I do not have a clear meaning of what I
| really wanted to do, what to do with these Lisp special variables (do we
| really want to manipulate these variables in boot) and,

My vision for Boot is to have as few direct reference to Lisp as
possible, and have a defined list of reserved names with well defined
semantics.

| of course,
| because you, Waldek and probably others are working in these areas and I
| do not have the necessary knowledge to work on these issues (I always
| postponed my "study" of the shoe/boot/spad compilers).
| If this is not possible actually to do what I'm asking, maybe you (or
| any others) have some thoughts about this (this is not restricted to
| bootsys, in the interpreter some special variables are used too,
| *standard-output* among others (though *standard-output* is relatively
| important since setting it to nil break the compilation process under
| SBCL).

It is definitely possible to give variables whose names are enclosed
in stars the same behaviour as those whose names starts with dollar.
We just need to make sure that we doon't conflict with some other
Boot identifiers, such as star or double-star...

\start
Date: 13 Mar 2007 16:22:57 -0400
From: Camm Maguire
To: Waldek Hebisch
Subject: Re: Creating executables which use Lisp compiler

Greetings!

I feel the best solution would be to conditionalize the addition of
the -I on the :system-p compile-file option not being set.  GCL
carries a copy of cmpinclude.h in compiler::*cmpinclude-string* which
is written into each file unless :system-p is on.  Somewhat wasteful,
but much more portable.  I'd leave si::*system-directory* alone if at
all possible.  Several autoloads will break unless this setting and
others like it are correct.  See si::reset-sys-paths, which is used in
the Debian gcl package when installing gcl in a fresh location.

I think this could go into 2.6.8pre if it is important to axiom.

Take care,

Waldek Hebisch writes:

> I wonder if there is a preferred procedure to create executables
> with gcl such that the resulting executable can use Lisp
> compiler.  More precisely, using defualt setting of si::*system-directory*
> may lead to problems.  Namely, if gcl is installed in a privite
> directory (not readable by other users) then the resulting 
> executable give errors during C compile.  This is because
> gcl (unconditionally) passes to C compiler -I directive pointing
> to original system directory.  However when directory specified 
> in -I directive exists but is not readable by the user invoking
> the compiler gcc treats this as an error.
> 
> This problem appeared when trying to install Axiom, see:
> 
> http://lists.nongnu.org/archive/html/axiom-developer/2007-02/msg00212.html
> 
> but I belive is a general problem for gcl created executables.
> 
> So the question is what is the preferred solution, in particular
> if creator of the executable should change the value of
> si::*system-directory* ?

\start
Date: Tue, 13 Mar 2007 16:52:57 -0500 (CDT)
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: cfuns.lisp and ELF platforms

On Tue, 13 Mar 2007 Tim Daly wrote:

| I don't remember writing an :elf conditional so I'm not sure
| what the reason was. I know that elf files were a new format.
| I believe that COFF or other variants were used on most platforms.

Yes, my being puzzled comes from the fact those functions have to do with
hashing a C-style string and not linking format, and looking at the
code, I cannot possibly phantom a reason for the descrimination.
Alas, GCL's documentation is just as verbose as Axiom's...

Many thanks; I'll carefully study a simplication.

\start
Date: Wed, 14 Mar 2007 02:31:52 +0100
From: Gregory Vanuxem
To: Gabriel Dos Reis
Subject: Re: Boot and other Lisps

Le mardi 13 mars 2007 =E0 15:22 -0500, Gabriel Dos Reis a =E9crit :

[...]

> Yes, I'm trying to allocate some fixed amount of time per week to work
> on Axiom, and ISO C++ stuff tends to take over :-)

Ah, time is always short...

[...]

> | In the version of Axiom that I uploaded I added the
> | Makefile.pamphlet from src/boot, which is the only documentation as f=
ar
> | as I know of the boot, more precisely Shoe, language.
>
> Yes, I intend to improve on that.  I face this dilemma: Produce an
> academic style definition of Shoe, or are more to the rigid
> style of the existing documentation.  I end up doing the latter. But I
> believe the former is the long term solution.

Probably, you know "The 30 years horizon" theme (which is now The 26
years horizon :-)

> I have not had (yet) the chance to look at your package -- shame on me =
:-(

No problem, I'm more interested by directions taken.

[...]

> | My
> | question is as follow, is it possible to declare a variable as specia=
l
> | without adding it to this list of variables ? Such that it can be use=
d
> | normally i.e if you want to assign a new value you can use the :=
> | operator and, important thing, it's not bound to nil at the beginning=
 of
> | the prog ?
>
> Not that I'm aware of, if my understanding of Shoe is correct. 
>
> When, I stumbled on that problem, I went back and looked at the Shoe co=
de more
> carefully.  First Shoe, translates the body of a function, by
> shoCompTran1.  That function updates global states that keep track of
> fluid variables (those declared with the "fluid" or "local" type),
> global variables (those beginning with $), and local variables (those
> that are assigned to in the body of the function).
> Then Shoe considers that anything that is on the fluid variables list
> or local variables list really is a local variable, therefore put it
> on the PROG header.  That exhausts all the handling of variables.

Thanks, I'll probably look at it though I have to look at the C code
used by Axiom and try to get rid of it when possible. I quickly added,
several days ago, a GCL Lisp version of directoryp using (system::stat)
but it is unsatisfactory, I will probably ask Camm if stat can returns
more information, eventually I'll implement it.

> My first reaction, when I ran into that problem was to extend the
> algorithm for special handling of the Lisp convention.  Then I
> imagined opposition from more senior contributors and decided to go
> with the solution I like the least (i.e. ugly), direct use of SETQ.
>
> [ By the way, I would like to get rid of the PROG annotation when
>   there is no variable in the list -- very common situation. ]

Yes

> I see your question as suggesting that we should have the translator
> honor the Lisp convention -- that would be the most logical thing to
> do.  If people agree, I can add that capability to the translator --
> and of course, I'll document it :-)

:-)

Not exactly, I'm not suggesting something though rereading my mail it
seems to be. In fact I asked some thoughts because I don't know how this
should be handled. I like the idea to add support of Lisp special
variables (*something*) but on the other hand this is a restriction. You
have to use $variable or *variable*. Don't know what to do, force the
user or use a more general way via a declaration.

\start
Date: Tue, 13 Mar 2007 21:53:13 -0500 (CDT)
From: Gabriel Dos Reis
To: Gregory Vanuxem
Subject: Re: Boot and other Lisps

On Wed, 14 Mar 2007, Gregory Vanuxem wrote:

| > I see your question as suggesting that we should have the translator
| > honor the Lisp convention -- that would be the most logical thing to
| > do.  If people agree, I can add that capability to the translator --
| > and of course, I'll document it :-)
|
| :-)
|
| Not exactly, I'm not suggesting something though rereading my mail it
| seems to be. In fact I asked some thoughts because I don't know how this
| should be handled. I like the idea to add support of Lisp special
| variables (*something*) but on the other hand this is a restriction. You
| have to use $variable or *variable*. Don't know what to do, force the
| user or use a more general way via a declaration.

OK; I believe it is an issue we have to address.  Would you prefer

    _*PACKAGE_* : global	     -- Boot, please, *PACKAGE* is global
    callingPackage := _*PACKAGE_*
    -- ... do some work ...
    _*PACKAGE_* := callingPackage

instead?

\start
Date: Wed, 14 Mar 2007 06:43:31 -0400
From: Bill Page
To: Rainbow Sally
Subject: Re: re. windows and pdf v. dvi

Quoting Rainbow Sally:

> I have not yet joined the discussions but I wanted to toss in my two cents.
>
> The 50 megs download makes an additional download of the tex viewer seem
> pretty minor.  It should also be a nice intro to some of the linux stuff
> that's available and maybe open some minds to alternatives to neo-free
> enterprise and the resulting paradox of people spying on themselves
> without warrants (the purpose of Windows NSA_KEY should be pretty well
> understood by now despite MS apologetics).
>
> But the enforced standardization of windows is sometimes nice.  I'm
> using it today so I thought I'd toss you a line.
>
> I vote for the smaller d/load and a good link to a working tex viewer or
> whatever is required.
>

Your email seems a little out of context to me, but I presume that you
are referring to the Windows version of Axiom? If you would like to
discuss Axiom I strongly recommend that you subscribe to the Axiom
Email Lists. See: http://wiki.axiom-developer.org and in particular
http://mail.nongnu.org/mailman/listinfo/axiom-mail and/or
http://mail.nongnu.org/mailman/listinfo/axiom-developer

Your encouragement might help to motivate other Axiom developers
to produce an updated version of Axiom for Windows.

\start
Date: Thu, 15 Mar 2007 00:13:46 +0100
From: Gregory Vanuxem
To: Gabriel Dos Reis
Subject: Re: Boot and other Lisps

Le mardi 13 mars 2007 =E0 21:53 -0500, Gabriel Dos Reis a =E9crit :
> On Wed, 14 Mar 2007, Gregory Vanuxem wrote:
>
> | > I see your question as suggesting that we should have the translato=
r
> | > honor the Lisp convention -- that would be the most logical thing t=
o
> | > do.  If people agree, I can add that capability to the translator -=
-
> | > and of course, I'll document it :-)
> |
> | :-)
> |
> | Not exactly, I'm not suggesting something though rereading my mail it
> | seems to be. In fact I asked some thoughts because I don't know how t=
his
> | should be handled. I like the idea to add support of Lisp special
> | variables (*something*) but on the other hand this is a restriction. =
You
> | have to use $variable or *variable*. Don't know what to do, force the
> | user or use a more general way via a declaration.
>
> OK; I believe it is an issue we have to address.  Would you prefer
>
>     _*PACKAGE_* : global	     -- Boot, please, *PACKAGE* is global
>     callingPackage := _*PACKAGE_*
>     -- ... do some work ...
>     _*PACKAGE_* := callingPackage
>
> instead?

Yes, why not, that could be a good idea I think.

\start
Date: Fri, 16 Mar 2007 00:12:20 -0400 (EDT)
From: Neil Sloane
To: Martin Rubey
Subject: Re:  Guessing package,	was: Re: your program / paper

Martin,

tonight I tried to install Axiom on our new linux machine.
so that I could start trying out your program!

unfortunately I did not get very far

I started at the top, and first downloaded 

axiom-20050901-3.i386.rpm

There were no instructions about what to do next!

So I guessed that

$  rpm -i axiom-20050901-3.i386.rpm 

might be the thing to do.  It was not!

prim$ rpm -i axiom-20050901-3.i386.rpm 
error: Failed dependencies:
        libreadline.so.5 is needed by axiom-20050901-3.i386
prim$ 

You said I should ask axiom-developer if I ran into trouble,
so I will copy this to them.  This is a linux  x86-64  machine.

\start
Date: 16 Mar 2007 07:14:46 +0100
From: Martin Rubey
To: Neil Sloane
Subject: Re: Guessing package,	was: Re: your program / paper
Cc: Waldek Hebisch

Dear Neil, Dear Waldek,

the best thing is to compile and install Waldek's distribution, since it
contains many important bugfixes which did not yet make it into trunk.

I hope you have subversion installed. (http://subversion.tigris.org/) If so,
please do the following:

svn co https://axiom.svn.sourceforge.net/svnroot/axiom/branches/wh-sandbox

cd wh-sandbox

svn co https://axiom.svn.sourceforge.net/svnroot/axiom/branches/build-improvements/gcl gcl

!!!!!!!!!!!! Waldek, does Neil need to install noweb, too? !!!!!!!!!!!!!!

-- if you want axiom to be installed in a non-standard location, like
-- /local/scratch/axiom, (axiom is automatically appended) say

./configure --prefix=/local/scratch

make

make install


Neil Sloane writes:

> Martin,
> 
> tonight I tried to install Axiom on our new linux machine.
> so that I could start trying out your program!
> 
> unfortunately I did not get very far
> 
> I started at the top, and first downloaded 
> 
> axiom-20050901-3.i386.rpm
> 
> There were no instructions about what to do next!
> 
> So I guessed that
> 
> $  rpm -i axiom-20050901-3.i386.rpm 
> 
> might be the thing to do.  It was not!
> 
> prim$ rpm -i axiom-20050901-3.i386.rpm 
> error: Failed dependencies:
>         libreadline.so.5 is needed by axiom-20050901-3.i386
> prim$ 
> 
> You said I should ask axiom-developer if I ran into trouble,
> so I will copy this to them.  This is a linux  x86-64  machine.
> 
> Regards
> 
> Neil Sloane
> 
>  Neil J. A. Sloane
>  AT&T Shannon Labs, Room C233, 
>  180 Park Avenue, Florham Park, NJ 07932-0971
>  Email: Neil Sloane
>  Office: 973 360 8415; fax: 973 360 8178
>  Home page: http://www.research.att.com/~njas/

\start
Date: Fri, 16 Mar 2007 13:26:03 +0100 (CET)
From: Waldek Hebisch
To: Martin Rubey
Subject: re: Guessing package, was: Re: your program / paper
Cc: Neil Sloane

> Dear Neil, Dear Waldek,
> 
> the best thing is to compile and install Waldek's distribution, since it
> contains many important bugfixes which did not yet make it into trunk.
> 
> I hope you have subversion installed. (http://subversion.tigris.org/) If so,
> please do the following:
> 
> svn co https://axiom.svn.sourceforge.net/svnroot/axiom/branches/wh-sandbox 
> 
> cd wh-sandbox
> 
> svn co https://axiom.svn.sourceforge.net/svnroot/axiom/branches/build-improvements/gcl gcl
> 
> !!!!!!!!!!!! Waldek, does Neil need to install noweb, too? !!!!!!!!!!!!!!
>

Yes, noweb is required.  So (assuming there is no noweb on the machine)
one should also do:

svn co https://axiom.svn.sourceforge.net/svnroot/axiom/branches/build-improvements/noweb noweb

If subversion is a problem I (or maybe Martin) could provide a source
tarball containg all needed pieces (in the past I created a few
such tarballs for my use on machines without network connection).

Also, it may be necessary to instal some devel packages -- by defaults
many distributions do not intall some components needed to compile
Axiom.

\start
Date: Fri, 16 Mar 2007 10:03:16 -0400
From: Heow Eide-Goodman
To: Tim Daly
Subject: LispNYC is in SoC 2007!
Cc: Bill Page, William Sit

Once again, LispNYC would be happy to submit all Axiom related projects!

The ideas page:

  http://lispnyc.org/soc.clp

\start
Date: Fri, 16 Mar 2007 19:26:18 +0100 (CET)
From: Waldek Hebisch
To: Neil Sloane
Subject: Re: a small problem installing axiom!

> 
> Short version:
> 
> prim$ cd src
> prim$ pwd
> /home/njas/axiom/wh-sandbox/src

No, run make just from wh-sandbox directory.

> prim$ export AXIOM=/spad/mnt/linux

Explicit setting of AXIOM variable is no longer needed.
Just in case, the correct setting for AXIOM variable is:

AXIOM=/path_to_axiom_tree/target/x86_64-unknown-linux

(the last part depends on your machine, I gave value for 64-bit linux).
  
> Long version:
> 
> Notes on trying to install axiom on prim, Mar 16 2007
> 
> I did
> 
> prim$ cd
> prim$ cd axiom
> 
> prim$ svn co https://axiom.svn.sourceforge.net/svnroot/axiom/branches/wh-sandbox
> 
> prim$ svn co https://axiom.svn.sourceforge.net/svnroot/axiom/branches/build-improvements/noweb noweb
> 

As Martin wrote noweb is needed inside wh-sandbox directory.

\start
Date: Fri, 16 Mar 2007 19:47:08 +0100 (CET)
From: Waldek Hebisch
To: Camm Maguire
Subject: Re: Creating executables which use Lisp compiler

> Greetings!
> 
> I feel the best solution would be to conditionalize the addition of
> the -I on the :system-p compile-file option not being set.  GCL
> carries a copy of cmpinclude.h in compiler::*cmpinclude-string* which
> is written into each file unless :system-p is on.  Somewhat wasteful,
> but much more portable.  I'd leave si::*system-directory* alone if at
> all possible.  Several autoloads will break unless this setting and
> others like it are correct.  See si::reset-sys-paths, which is used in
> the Debian gcl package when installing gcl in a fresh location.
>

Does it mean that executable should carry with it copy of gcl libraries?
Otherwise autoloads would not work anyway. 
 
> I think this could go into 2.6.8pre if it is important to axiom.
> 

The problem appeared in real use, so it would be nice to have it fixed.
But there are reasonable workarounds, so Axiom can wait some time
if needed.

> Take care,
> 
> Waldek Hebisch writes:
> 
> > I wonder if there is a preferred procedure to create executables
> > with gcl such that the resulting executable can use Lisp
> > compiler.  More precisely, using defualt setting of si::*system-directory*
> > may lead to problems.  Namely, if gcl is installed in a privite
> > directory (not readable by other users) then the resulting 
> > executable give errors during C compile.  This is because
> > gcl (unconditionally) passes to C compiler -I directive pointing
> > to original system directory.  However when directory specified 
> > in -I directive exists but is not readable by the user invoking
> > the compiler gcc treats this as an error.
> > 
> > This problem appeared when trying to install Axiom, see:
> > 
> > http://lists.nongnu.org/archive/html/axiom-developer/2007-02/msg00212.html
> > 
> > but I belive is a general problem for gcl created executables.
> > 
> > So the question is what is the preferred solution, in particular
> > if creator of the executable should change the value of
> > si::*system-directory* ?

\start
Date: Sat, 17 Mar 2007 02:27:21 -0400
From: Bill Page
To: Heow Eide-Goodman
Subject: RE: LispNYC is in SoC 2007!
Cc: William Sit

On March 16, 2007 10:03 AM Heow Eide-Goodman wrote:
> 
> Once again, LispNYC would be happy to submit all Axiom 
> related projects!
> 
> The ideas page:
> 
>   http://lispnyc.org/soc.clp
> 

Hoew, how very kind of you to offer! :-)

I think our previous arrangement during a the Google Summer of
Code 2005 (Kai Kaminski's AxiomUI project) turned out very well
for both Axiom and LispNYC since it demonstrated as least one
way in which Axiom could be extended using standard common lisp
packages methods. Perhaps we can do it again this year.

A few weeks ago Martin Rubey setup a tentative Summer of Code
2007 web page for Axiom at:

http://wiki.axiom-developer.org/SummerOfCode2007

Here is the new list of possible projects so far:

Project 1: create a HyperDoc replacement/enhancement
Project 2: a zero test for algebraic differential equations
Project 3: extending SPAD to understand "extend"
Project 4: create a package management system for Axiom
Project 5: improve the Sage interface to Axiom

I just added the last two items on this list. This list
might grow if other Axiom developers think there is a serious
possibility of having a funded Summer of Code project for
Axiom.

I think the Axiom Developers would be more than happy to
receive project proposals on these and of course any other
proposal based on not-yet-accomplished items in the previous
Summer of Code page and the general Axiom WishList.

If you think it appropriate, please feel free to provide a
link from your web site to our SummerOfCode2007 list.

Many thanks again for continuing to think of us.

\start
Date: Sat, 17 Mar 2007 19:41:39 +0100 (CET)
From: Waldek Hebisch
To: Martin Rubey
Subject: Re: Issue 336

Martin Rubey wrote:
> If the second argument k is negative, we could return zero. However, I vaguely
> remember that the definition in terms of Gamma functions does not yield this as
> a limit, at least not for any n. Do you happen to remember?
> 
> In fact, if n=k, the definition in terms of Gamma functions always gives one,
> no matter whether n is negative of not...
> 
> Axiom gives 0 currently, due to the definition of ibinom. This looks all quite
> inconsistent...
>

Hmm, really inconsistent:

(4) ->  binomial(n, n)
   (4)  1
                                                     Type: Expression Integer
(5) -> binomial(-3, -3)
   (5)  0
                                                     Type: NonNegativeInteger

I would tend to say that binomial(n, k) with k beeing a negative
integeriis an error.  Definition in term of Gamma functions has
discontinuity there: if n is non-integer and k tends to negative integer
then we get 0 as a limit.  Now, if we keep k fixed and let n go to
any value we get 0.  But if we allow n and k to change simultaneously
we may get nonzero limit (so limit as a function of two variables does
not exist).  We have discontinuity only for integer n and k such that
k <= n < 0 (otherwise limit is 0).

\start
Date: 17 Mar 2007 20:16:02 +0100
From: Martin Rubey
To: Waldek Hebisch
Subject: Re: Issue 336

Der Waldek,

Waldek Hebisch writes:

> Martin Rubey wrote:
> > If the second argument k is negative, we could return zero. However, I vaguely
> > remember that the definition in terms of Gamma functions does not yield this as
> > a limit, at least not for any n. Do you happen to remember?
> > 
> > In fact, if n=k, the definition in terms of Gamma functions always gives one,
> > no matter whether n is negative of not...

> I would tend to say that binomial(n, k) with k beeing a negative integer is
> an error.  Definition in term of Gamma functions has discontinuity there: if
> n is non-integer and k tends to negative integer then we get 0 as a limit.
> Now, if we keep k fixed and let n go to any value we get 0.  But if we allow
> n and k to change simultaneously we may get nonzero limit (so limit as a
> function of two variables does not exist).  We have discontinuity only for
> integer n and k such that k <= n < 0 (otherwise limit is 0).

I should know, but I don't: is there a sensible definition of the binomial
coefficient which disagrees with the definition in terms of Gamma functions at
certain values?

(I don't think so...)

If the definition in terms of the Gamma function is "canonical", I'd suggest to
simplify only when the limit is unique. (Contrary to Mathematica) So, as you
and Mathworld say

* for 0 <= k \in Z we return the product
* if we can prove that n<k, we return 0

I wonder about the case n=k. Why isn't that equal to 1? We obtain

binomial(m,m)=limit(k->m, n->m) Gamma(n+1)/(Gamma(k+1)Gamma(n-k+1))

isn't that limit equal to one?

In ibinom (that is, for FunctionSpaces over arbitrary R we currently have

binomial(n,0)=1 
binomial(n,n)=1 
binomial(n,1)=n
binomial(n,n-1)=n

If the above limit does not exist, they are all wrong, I guess...

BTW, does binomial(n,k)=binomial(n,n-k) hold always?

\start
Date: 17 Mar 2007 14:21:22 -0500
From: Gabriel Dos Reis
To: list
Subject: |shoeread-line|

renamed to shoeReadLine and moved from initial-env.lisp to in
ptyout.boot, the only file that uses it.  It is now defined in Boot,
instead of Lisp. 
Applied to gdr-sandbox.
Make all-boot with SBCL.

-- Gaby

2007-03-17  Gabriel Dos Reis  Gabriel Dos Reis
  
	* src/boot/initial-env.lisp.pamphlet (|shoeread-line|): Move to...
	* src/boot/ptyout.boot.pamphlet (shoeReadLine): ... here.  Rename.
	(bRgen1): Update.
	Update cachaed Lisp translation.

*** src/boot/initial-env.lisp.pamphlet	(revision 19345)
--- src/boot/initial-env.lisp.pamphlet	(local)
*************** with the base Lisp system.
*** 228,236 ****
  (defun make-full-cvec (sint &optional (char #\space))
    (make-string sint :initial-element (character char)))
  
- (defun |shoeread-line| (st &optional (eofval nil))
-   (read-line st nil eofval))
- 
  (defun |shoePLACEP| (item) 
    (eq item nil))
  
--- 228,233 ----
*** src/boot/ptyout.boot.pamphlet	(revision 19345)
--- src/boot/ptyout.boot.pamphlet	(local)
*************** BOOTTOCLLINES(lines, fn)==
*** 109,114 ****
--- 109,120 ----
  setCurrentPackage x ==
    SETQ(_*PACKAGE_*,x)
  
+ 
+ ++ Read a Newline-terminated line form input STREAM.  Return nil
+ ++ if end-of-file is reached before any character is actually read.
+ shoeReadLine stream ==
+   READ_-LINE(stream, nil)
+ 
  -- (boottocl "filename") translates the file "filename.boot" to
  -- the common lisp file "filename.clisp"
   
*************** bNext1(f,s)==
*** 475,481 ****
  bRgen s==bDelay(function bRgen1,[s])
   
  bRgen1(:s) ==
!         a:=shoeread_-line car s
          if shoePLACEP a
          then
  --          shoeCLOSE car s
--- 481,487 ----
  bRgen s==bDelay(function bRgen1,[s])
   
  bRgen1(:s) ==
!         a:=shoeReadLine car s
          if shoePLACEP a
          then
  --          shoeCLOSE car s
*************** PSTOUT string==
*** 887,892 ****
--- 893,901 ----
  (DEFUN |setCurrentPackage| (|x|)
    (PROG () (RETURN (SETQ *PACKAGE* |x|))))
  
+ (DEFUN |shoeReadLine| (|stream|)
+   (PROG () (RETURN (READ-LINE |stream| NIL))))
+ 
  (DEFUN BOOTTOCL (|fn|)
    (PROG (|$bfClamming|)
      (DECLARE (SPECIAL |$bfClamming|))
*************** PSTOUT string==
*** 1469,1475 ****
    (PROG (|a|)
      (RETURN
        (PROGN
!         (SETQ |a| (|shoeread-line| (CAR |s|)))
          (COND
            ((|shoePLACEP| |a|) (LIST '|nullstream|))
            ('T (CONS |a| (|bRgen| (CAR |s|)))))))))
--- 1478,1484 ----
    (PROG (|a|)
      (RETURN
        (PROGN
!         (SETQ |a| (|shoeReadLine| (CAR |s|)))
          (COND
            ((|shoePLACEP| |a|) (LIST '|nullstream|))
            ('T (CONS |a| (|bRgen| (CAR |s|)))))))))



\start
Date: Sat, 17 Mar 2007 21:42:15 +0100 (CET)
From: Waldek Hebisch
To: Martin Rubey
Subject: Re: Issue 336

Martin Rubey wrote:
> Waldek Hebisch writes:
 
> > Martin Rubey wrote:

> > > If the second argument k is negative, we could return
> > > zero. However, I vaguely remember that the definition in terms
> > > of Gamma functions does not yield this as a limit, at least not
> > > for any n. Do you happen to remember?  In fact, if n=k, the
> > > definition in terms of Gamma functions always gives one, no
> > > matter whether n is negative of not...
 
> > I would tend to say that binomial(n, k) with k beeing a negative
> > integer is an error.  Definition in term of Gamma functions has
> > discontinuity there: if n is non-integer and k tends to negative
> > integer then we get 0 as a limit.  Now, if we keep k fixed and let
> > n go to any value we get 0.  But if we allow n and k to change
> > simultaneously we may get nonzero limit (so limit as a function of
> > two variables does not exist).  We have discontinuity only for
> > integer n and k such that k <= n < 0 (otherwise limit is 0).
 
> I should know, but I don't: is there a sensible definition of the
> binomial coefficient which disagrees with the definition in terms of
> Gamma functions at certain values?
 

P. Luschny argues in favour of another extension of factorial to 
analytic function:

http://www.luschny.de/math/factorial/hadamard/HadamardsGammaFunction.html

Presumably this will also give "sensible" definition of binomial
coefficients.

I am not aware of other proposals, but it is hard to a priori
exclude possibility of "sensible ones.  But I think that definition
in terms of Gamma functions is simply much more popular and
much more useful, so I would take it as canonocal definition.

> (I don't think so...)
> 
> If the definition in terms of the Gamma function is "canonical", I'd suggest to
> simplify only when the limit is unique. (Contrary to Mathematica) So, as you
> and Mathworld say
> 
> * for 0 <= k \in Z we return the product
> * if we can prove that n<k, we return 0
> 

I think that we should produce a conditional expression:

if (k in Z) and (n in Z) and (k <= n) and (n < 0) then
   error
else 
   ....

Or use provisos.  But in the mean time I feel that we should
simplify: we can not produce correct answer (because not simplifying
may also give a wrong answer), so the best we can do is to try
to be wrong in as rarely as possible.  I do not think we should 
just disable _all_ unjustified simplifications: it would a hard job
and would make Axiom essentially useless (I do want to get rid
of unjustified simplifications, but not by disabling them, rather
I want to justify then if possible and use conditional expressions
otherwise).  Since now we have a lot of unjustified simplifications
disabling one of them may just trigger another one, sometimes
worse.

> I wonder about the case n=k. Why isn't that equal to 1? We obtain
> 
> binomial(m,m)=limit(k->m, n->m) Gamma(n+1)/(Gamma(k+1)Gamma(n-k+1))
> 
> isn't that limit equal to one?

Take non-integer n.  Let k go to negative integer.  Then Gamma(n+1)
and Gamma(n-k+1) stay finite, while Gamma(k+1) go to infinity.
So you get zero as one accumulation points.  Of course 1
is another accumulation point, so the limit does not exist.

In other words:  binomial(n, n) has limit 1 when n goes to negative
integer.  But binomial(m, k) has no limit when (m, k) goes to (n, n)
where n is a negative integer.

> 
> In ibinom (that is, for FunctionSpaces over arbitrary R we currently have
> 
> binomial(n,0)=1 
> binomial(n,n)=1 
> binomial(n,1)=n
> binomial(n,n-1)=n
> 
> If the above limit does not exist, they are all wrong, I guess...
>

Only binomial(n,n)=1 and binomial(n,n-1)=n.  
 
> BTW, does binomial(n,k)=binomial(n,n-k) hold always?
> 

The equality holds whenever definition via Gamma function works.
If you extend definition via continuity it still works.  But
if one puts some arbitrary value in point of discontinuity then
such extension may break equality.

\start
Date: 17 Mar 2007 22:47:46 +0100
From: Martin Rubey
To: Waldek Hebisch
Subject: Re: Issue 336

Waldek Hebisch writes:

> > I should know, but I don't: is there a sensible definition of the binomial
> > coefficient which disagrees with the definition in terms of Gamma functions
> > at certain values?
> > 
> 
> P. Luschny argues in favour of another extension of factorial to analytic
> function:
> 
> http://www.luschny.de/math/factorial/hadamard/HadamardsGammaFunction.html
> 
> Presumably this will also give "sensible" definition of binomial
> coefficients.

Interesting reference, however, I doubt that the alternatives to Gamma are
interesting with respect to binomial coefficients - I have the feeling that

F(x+1)=(x+1)F(x)

is something rather important... (BTW, doesn't define that relation Gamma more
or less uniquely?, What other properties does one need to make it unique?)

> But I think that definition in terms of Gamma functions is simply much more
> popular and much more useful, so I would take it as canonocal definition.

Agreed, Well, it just occurred to me: if we postulate

binomial(n,k)+binomial(n,k+1)=binomial(n+1,k+1)

that forces, putting k=-1

binomial(n,-1) = binomial(n+1,0) - binomial(n,0) = 0

(or did I make a mistake?) I imagine that

binomial(n,k)=(-1)^k binomial(k-n-1, k)

also implies some non-pleasant stuff...

> > If the definition in terms of the Gamma function is "canonical", I'd
> > suggest to simplify only when the limit is unique. (Contrary to
> > Mathematica) So, as you and Mathworld say
> > 
> > * for 0 <= k \in Z we return the product
> > * if we can prove that n<k, we return 0
> 
> I think that we should produce a conditional expression:
> 
> if (k in Z) and (n in Z) and (k <= n) and (n < 0) then
>    error
> else 
>    ....

OK.

> Or use provisos.  

Yes, that should be really high priority by now. Fortunately, meanwhile I am
quite sure that provisos *only* make sense for "expression like domains", so
they do not seem such a impossible thing anymore.

> But in the mean time I feel that we should simplify: we can not produce
> correct answer (because not simplifying may also give a wrong answer),

I do not understand this. Could you provide an example?

> so the best we can do is to try to be wrong in as rarely as possible.  I do
> not think we should just disable _all_ unjustified simplifications: it would
> a hard job and would make Axiom essentially useless (I do want to get rid of
> unjustified simplifications, but not by disabling them, rather I want to
> justify then if possible and use conditional expressions otherwise).  Since
> now we have a lot of unjustified simplifications disabling one of them may
> just trigger another one, sometimes worse.

To be honest, I doubt that this is the way to go. I'd rather stay
correct-correct, and fix things I break doing so in other ways. This should be
possible, shouldn't it?

> > I wonder about the case n=k. Why isn't that equal to 1? We obtain
> > 
> > binomial(m,m)=limit(k->m, n->m) Gamma(n+1)/(Gamma(k+1)Gamma(n-k+1))
> > 
> > isn't that limit equal to one?
> 
> Take non-integer n.  Let k go to negative integer.  Then Gamma(n+1) and
> Gamma(n-k+1) stay finite, while Gamma(k+1) go to infinity.  So you get zero
> as one accumulation points.  Of course 1 is another accumulation point, so
> the limit does not exist.

thanks.

> In other words: binomial(n, n) has limit 1 when n goes to negative integer.
> But binomial(m, k) has no limit when (m, k) goes to (n, n) where n is a
> negative integer.

So, that raises the question whether to simplify binomial(n,n)... Note that
Mathworld defines it to be 0 when n<0. 

> > In ibinom (that is, for FunctionSpaces over arbitrary R we currently have
> > 
> > binomial(n,0)=1 
> > binomial(n,n)=1 
> > binomial(n,1)=n
> > binomial(n,n-1)=n
> > 
> > If the above limit does not exist, they are all wrong, I guess...
> 
> Only binomial(n,n)=1 and binomial(n,n-1)=n.  

But for n<0, binomial(n, n-1) is undefined, isn't it?  If I didn't make a
mistake, this also questions:

> > BTW, does binomial(n,k)=binomial(n,n-k) hold always?

> The equality holds whenever definition via Gamma function works.  If you
> extend definition via continuity it still works.  But if one puts some
> arbitrary value in point of discontinuity then such extension may break
> equality.

\start
Date: 18 Mar 2007 01:33:09 +0100
From: Martin Rubey
To: Ralf Hemmecke
Subject: Re: Issue 336

Ralf Hemmecke writes:

> It seems that we all agree on
> 
> (B1) binomial(r,k) = r(r-1)...(r-k+1)/(k!)
> 
> for any complex r. (Actually it doesn't very much on the domain of r.
> 
> Graham/Knuth/Patashnik in "Concrete Mathematics" extend it to
> 
> (B2) binomial(r,k) = 0 for k < 0.
> 
> With that extension also the addition formula (*) you stated above holds for
> all reals n and all integers k.

Thanks Ralf for pointing out this possibility. So, the answer to my question

> > is there a sensible definition of the binomial coefficient which disagrees
> > with the definition in terms of Gamma functions at certain values?

is simply "yes". So, how to go on now? We cannot check whether n in 

binomial(n,n)

is negative... So that would suggest leaving binomial(n,n) unevaluated. I guess
that it shouldn't be too difficult for the *user* to tell axiom what to do with
it (either using eval or a rule), but might it break other packages?

Below is the list of places where binomial is used. Those which refer to the
definition in IntegerCombinatoricFunctions can be safely ignored. Although, the
first line of the definition there is

      n < 0 or m < 0 or m > n => 0

which is just Graham/Knuth/Patashnik...

Martin

crfp.spad:534:         maxi := max( nthRoot( locmax/(binomial(d,j)$ICF::R), j), maxi)
crfp.spad:600:           cc := cc + coef.i * (binomial(i,j)$ICF :: R)
divisor.spad:333:      for i in 1..(n := binomial(nr, nc)) repeat
divisor.spad:347:        i <= (b := binomial(n - j, m)) =>
facutil.spad:114:       k:=binomial(n1,m)
galutil.spad:115:       binomial(n,r)$IntegerCombinatoricFunctions(Z) :: R
lodof.spad:107:         sz() := binomial(n, m)$IntegerCombinatoricFunctions(Integer) :: N
lodo.spad:143:            killer(u::P ** m, binomial(n + m - 1, n - 1)::N, [un], [a], diff)
mlift.spad:225:     k:=binomial(n1,m)
multsqfr.spad:355:     k:=binomial(n1,m)
odeef.spad:70:    localbinom(j, i) == (j > i => binomial(j, i+1); 0)
rep1.spad:227:         m      :   I   := binomial(n,k)$ICF
rep1.spad:258:       dim : NNI := (binomial(m+n-1,n)$ICF)::NNI
sgcf.spad:205:      n = 0 => binomial(m,cm)$ICF
sgcf.spad:278:      bin : I := binomial$ICF (n,m)
sgcf.spad:287:            if binomial$ICF (y,s) > mm then leave
sgcf.spad:289:         mm := mm - binomial$ICF (y-1,s)
special.spad:319:            cx := (-1)**m * binomial(ni,ni-mi) * factorial(ni)

\start
Date: Sun, 18 Mar 2007 18:59:48 -0400
From: Heow Eide-Goodman
To: Bill Page
Subject: RE: LispNYC is in SoC 2007!
Cc: William Sit


Great guys.

Go ahead and sign up as mentors here, under "Registering to Participate
in the Program":

http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-=
the-gsoc-web-app-for-mentors-and-organization-administrators

...and we'll get the applications in!

- Heow

\start
Date: Sun, 18 Mar 2007 22:22:53 -0400
From: Bill Page
To: Heow Eide-Goodman
Subject: RE: LispNYC is in SoC 2007!

Heow,

>
> > http://wiki.axiom-developer.org/SummerOfCode2007
>

On March 18, 2007 7:00 PM you wrote:
>
> Great guys.
>
> Go ahead and sign up as mentors here, under "Registering to
> Participate in the Program":
>
>
http://groups.google.com/group/google-summer-of-code-announce/web/guide-t=
o-t
he-gsoc-web-app-for-mentors-and-organization-administrators
>
> ...and we'll get the applications in!


This registration process is a bit new to me but I think I managed
to register - at least I did receive the message:

"LispNYC.org     Your Mentoring Acceptance is Pending"

\start
Date: Mon, 19 Mar 2007 12:45:33 +0100 (CET)
From: Waldek Hebisch
To: Martin Rubey
Subject: Re: Issue 336

Martin Rubey wrote:
> Waldek Hebisch writes:
> I do not understand this. Could you provide an example?
>

Division by unsimplified zero (IMHO the largest single source of
bugs).  
 
> > so the best we can do is to try to be wrong in as rarely as possible.  I do
> > not think we should just disable _all_ unjustified simplifications: it would
> > a hard job and would make Axiom essentially useless (I do want to get rid of
> > unjustified simplifications, but not by disabling them, rather I want to
> > justify then if possible and use conditional expressions otherwise).  Since
> > now we have a lot of unjustified simplifications disabling one of them may
> > just trigger another one, sometimes worse.
> 
> To be honest, I doubt that this is the way to go. I'd rather stay
> correct-correct, and fix things I break doing so in other ways. This should be
> possible, shouldn't it?
> 

Basically I agree.  But do you want to disable division?  That would break
lage part of Axiom.

Concerning binomial, the question is if binomial(n, k) with negative k
is of any use.  If we agree that such binomials are useless it is 
reasonable to make a global assumption that k >= 0 (to some degree it
is similar to current assumption that variables are real). 

\start
Date: Mon, 19 Mar 2007 09:07:57 -0400
From: Cliff Yapp
To: Bill Page
Subject: Axiom package system

Bill Page wrote:

> Project 4: create a package management system for Axiom

Bill, would this entail either interfacing with and/or polishing the 
"database" system Axiom uses for mathematical relationships?

Tim was kind enough to explain a bit what the "database" actually is and 
some of the design considerations behind it here:
http://lists.nongnu.org/archive/html/axiom-developer/2006-10/msg00293.html

I might be wrong, but wouldn't any package mechanism be intimately 
connected with this system?  If so, perhaps the first project would be 
to thoroughly document the design of the "database" system (perhaps 
"datahash" would be more appropriate?) and then from there either 
modernize it as appropriate to make it easier to accomplish the new 
tasks like a package system  or proceed to implement the package system 
if the current setup is robust enough to handle it?

Perhaps Waldek and Gaby could comment, having worked with this system in 
the branches?

One functionality for package authors that would be really nice is a way 
to automatically generate a list of functionality they are using in all 
the code in a file or package.  This is particularly good for cases 
where multiple packages outside the main Axiom tree are used together 
and thus one or more requirements might not be present "by default."

\start
Date: Mon, 19 Mar 2007 16:10:09 -0400
From: Bill Page
To: Cliff Yapp
Subject: RE: Axiom package system

On March 19, 2007 9:08 AM C Y wrote
> 
> Bill Page wrote:
> 
> > Project 4: create a package management system for Axiom
> ...
> 
> Bill, would this entail either interfacing with and/or
> polishing the "database" system Axiom uses for mathematical
> relationships?

Certainly interfacing with the Axiom database system is
required since new entries in the database will be required
when a package is installed (and deleted when a package is
removed). There are already Lisp-callable routines for these
purposes that are used internally in Axiom. I don't think any
"polishing" is required - at least not for the purpose of
implementing Axiom packages.

> ...
> I might be wrong, but wouldn't any package mechanism be
> intimately connected with this system?

Yes, certainly connected, but not the main purpose.

> If so, perhaps the first project would be to thoroughly
> document the design of the "database" system (perhaps 
> "datahash" would be more appropriate?) and then from there
> either modernize it as appropriate to make it easier to
> accomplish the new tasks like a package system  or proceed
> to implement the package system if the current setup is
> robust enough to handle it?

More documentation is always a good thing but I think the
current documentation for the Axiom database system is
probably almost good enough. Naturally the Axiom package
developer may need to discuss details with other more
experienced Axiom developers and as a result also contribute
to it's documentation. But again I don't think we need to
touch the actual mechanism.

> Perhaps Waldek and Gaby could comment, having worked with
> this system in the branches?

I certainly hope they would be interested and willing to help
anyone who takes on this task.

> One functionality for package authors that would be really
> nice is a way to automatically generate a list of
> functionality they are using in all the code in a file or
> package.  This is particularly good for cases where multiple
> packages outside the main Axiom tree are used together
> and thus one or more requirements might not be present
> "by default."

I do not know what you mean by "list of functionality". Could
you explain? Can you give an example of this in any existing
package management system, e.g. Debian apt-get, RedHat Yum,
etc. ?

\start
Date: Mon, 19 Mar 2007 18:45:24 -0400
From: Cliff Yapp
To: Bill Page
Subject: Re: Axiom package system

Bill Page wrote:

>> One functionality for package authors that would be really
>> nice is a way to automatically generate a list of
>> functionality they are using in all the code in a file or
>> package.  This is particularly good for cases where multiple
>> packages outside the main Axiom tree are used together
>> and thus one or more requirements might not be present
>> "by default."
> 
> I do not know what you mean by "list of functionality". Could
> you explain? Can you give an example of this in any existing
> package management system, e.g. Debian apt-get, RedHat Yum,
> etc. ?

Sorry, I probably didn't say it right.

Let's take an example - say that, hypothetically, a units package and an 
error analysis package have been implemented as packages external to Axiom.

Now, say I want to implement a version of Feyncalc in Axiom that builds 
off of those core packages.  As I develop the new Feyncalc, I would have 
the other packages I depend on loaded.  However, when I went to pack it 
for distribution, I would want to know what I had loaded and wound up 
using that isn't part of the default Axiom.  A command that could 
determine what parts of the system and any loaded packages were used, 
and flag any 3rd party packages, would be a useful utility.  In 
addition, I might find I have used only a very small part of some 
package and it might be useful to incorporate that small part into my 
own code to avoid the external requirement. Later I could use the same 
mechanism to check if it has become part of the main Axiom, which would 
help pinpoint possible conflicts and help keep my code clean.

I was thinking working at the domain level or whatever level makes 
sense, sort of a "deep requirements" map of a package at a mathematical 
level.  Maybe something similar to xref in lisp.

Another possible use would be to quickly check if my 3rd party package 
depends on any parts of Axiom that have been updated in a given release. 
  If so, checking is indicated, and if not it's probably a fairly safe 
bet that everything is OK.  Eventually a unit testing system might take 
advantage of this to trigger checks automatically on commits - check all 
functionality which relies on the code which has just been changed. 
Perhaps there are better ways of doing that, it's just an idea. 
Obviously it's a bit more of a development tool than a package tool, but 
it would help in building external packages.

\start
Date: Mon, 19 Mar 2007 23:36:10 -0400
From: Alfredo Portes
To: Bill Page
Subject: re: Guessing package

Hi Bill,

> tonight I tried to install Axiom on our new linux machine.
> so that I could start trying out your program!
>
> unfortunately I did not get very far
>
> I started at the top, and first downloaded
>
> axiom-20050901-3.i386.rpm
>
> There were no instructions about what to do next!
>
> So I guessed that

It has been suggested that http://wiki.axiom-developer.org/AxiomBinaries needs
to be improved. I suggest using the content of this page:
http://wiki.axiom-developer.org/SandBoxDoyen instead. This page of
course is only a little organization of the current content. More work
needs to be done on it. I volunteer to create binaries if a release
schedule is decided.

\start
Date: Tue, 20 Mar 2007 15:34:14 +0100 (CET)
From: Waldek Hebisch
To: list
Subject: Issue 338

I looked at the issue 338.  It seems that we have extra porblem here.
Axiom allows operators of arity 0, and it looks that for such operators
we would have exactly the same problem of ordering.  I am not sure
if Axiom typechecker allows 0 arity functions here, but assuming
that such functions are allowed we have problem.

It seems taht both problem can be avoided if we disable early exit
from smprep:

diff -u /home/s/test/tt/axiom2/wh-sandbox2/src/algebra/fspace.spad.pamphlet wh-sandbox2/src/algebra/fspace.spad.pamphlet
--- /home/s/test/tt/axiom2/wh-sandbox2/src/algebra/fspace.spad.pamphlet	2007-02-07 14:59:29.000000000 +0100
+++ wh-sandbox2/src/algebra/fspace.spad.pamphlet	2007-03-20 15:21:17.000000000 +0100
@@ -634,7 +634,8 @@
       -- op(arg)**m ==> func(arg)**(m quo n) * op(arg)**(m rem n)
       smprep(lop, lexp, lfunc, p) ==
         (v := mainVariable p) case "failed" => p::%
-        symbolIfCan(k := v::K) case SY => p::%
+        -- symbolIfCan(k := v::K) case SY => p::%
+        k := v::K
         g := (op := operator k)
            (arg := [eval(a,lop,lexp,lfunc) for a in argument k]$List(%))
         q := map(eval(#1::%, lop, lexp, lfunc),


I am still investigating if this is a right fix.  Also smprep looks
inefficient and this change would make it even less efficient than
it is now.

\start
Date: Tue, 20 Mar 2007 10:36:36 -0400
From: Bill Page
To: Alfredo Portes
Subject: re: Guessing package, 	was: Re: your program / paper

Alfredo,

On March 19, 2007 11:36 PM Alfredo Portes wrote:
> ... 
> It has been suggested that 
> http://wiki.axiom-developer.org/AxiomBinaries needs
> to be improved. I suggest using the content of this page:
> http://wiki.axiom-developer.org/SandBoxDoyen instead. This
> page of course is only a little organization of the current
> content. More work needs to be done on it.
> 

I agree that your new version is much better than the old one.
Please go ahead and update the AxiomBinaries page. If you have
more ideas on how to make it better, feel free to change it
however you think is best. Be Bold. :-)

> I volunteer to create binaries if a release schedule is decided.

Great!

I have no idea when/if Tim will be able to release a new "Gold"
version of Axiom. In the mean time, I think wh-sandbox is
currently our best candidate for a new Axiom "Silver" version.
It contains many important fixes to hyperdoc and some very
significant improvements in the Axiom math library including
Martin's guess package.

I would like to proposed to Gaby and Waldek that we go ahead
and establish wh-sandbox as the new trunk in svn at Sourceforge
as soon as possible. When that is done, I think it would be
appropriate to prepare up to date "Silver" binaries for as
wide a range of hardware/operating systems as possible. I think
that where it is possible, we should also include Aldor in these
binaries.

\start
Date: Tue, 20 Mar 2007 10:50:34 -0400
From: Bill Page
To: list
Subject: Axiom Google Summer of Code Deadline

This year LispNYC is offering to support Google-funded Summer of Code
projects for Axiom. For more information please see:

http://lispnyc.org/soc.clp

and

http://wiki.axiom-developer.org/SummerOfCode2007

Note: The deadline for student applications is March 24th!

Apply now online here:

http://groups.google.com/group/google-summer-of-code-announce/web/guide-t=
o-t
he-gsoc-web-app-for-student-applicants

Do not hesitate if your interests do not exactly match the project
proposals. All applications relevant to Lisp and Axiom will be
considered. Successful applicants will earn up to $US 4,500 this
summer.

Regards,
Bill Page.

PS. Since the time is very short please advertise this offer
within your department/organization as soon as possible.

\start
Date: 20 Mar 2007 11:23:02 -0500
From: Gabriel Dos Reis
To: Bill Page
Subject: re: Guessing package,	was: Re: your program / paper

Bill Page writes:

[...]

| I would like to proposed to Gaby and Waldek that we go ahead
| and establish wh-sandbox as the new trunk in svn at Sourceforge
| as soon as possible. When that is done, I think it would be
| appropriate to prepare up to date "Silver" binaries for as
| wide a range of hardware/operating systems as possible. I think
| that where it is possible, we should also include Aldor in these
| binaries.

Instead of constantly changing branches for "new silver", I would
rather see a backport for specific changes from wh-sandbox to
build-improvements,  and then when its status is clear to what is
still called "Silver".  

Waldek sent a list ago (I don't have that mail right now), we should
work out the details for backport. 

\start
Date: Tue, 20 Mar 2007 11:36:29 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: re: Guessing package,	was: Re: your program / paper
Cc: Waldek Hebisch

On March 20, 2007 12:23 PM Gaby wrote:
> 
> Bill Page writes:
> 
> [...]
> 
> | I would like to proposed to Gaby and Waldek that we go ahead
> | and establish wh-sandbox as the new trunk in svn at Sourceforge
> | as soon as possible. When that is done, I think it would be
> | appropriate to prepare up to date "Silver" binaries for as
> | wide a range of hardware/operating systems as possible. I
> | think that where it is possible, we should also include Aldor
> | in these binaries.
> 
> Instead of constantly changing branches for "new silver", I
> would rather see a backport for specific changes from wh-sandbox
> to build-improvements,  and then when its status is clear to
> what is still called "Silver".
> 
> Waldek sent a list ago (I don't have that mail right now), we
> should work out the details for backport. 
> 

That would certainly be fine with me. The main reason that I
currently favour wh-sandbox is that Waldek recently "backported"
a selection of revisions from build-improvements to wh-sandbox.
But I am not completely certain of the status of all potential
revisions that we might want to include in a new "Silver". Of
course I am especially concerned about the ability to build on
Windows but I haven't tested this yet.

>From my point of view, the creation of a new "Silver" trunk is
a little overdue. Unfortunately only you and Waldek are really
in a good position to do this. But with your direction I am
certainly willing to help - especially in testing of the new
release.

\start
Date: 20 Mar 2007 11:49:23 -0500
From: Gabriel Dos Reis
To: Bill Page
Subject: re: Guessing package,	was: Re: your program / paper
Cc: Waldek Hebisch

Bill Page writes:

| On March 20, 2007 12:23 PM Gaby wrote:
| > 
| > Bill Page writes:
| > 
| > [...]
| > 
| > | I would like to proposed to Gaby and Waldek that we go ahead
| > | and establish wh-sandbox as the new trunk in svn at Sourceforge
| > | as soon as possible. When that is done, I think it would be
| > | appropriate to prepare up to date "Silver" binaries for as
| > | wide a range of hardware/operating systems as possible. I
| > | think that where it is possible, we should also include Aldor
| > | in these binaries.
| > 
| > Instead of constantly changing branches for "new silver", I
| > would rather see a backport for specific changes from wh-sandbox
| > to build-improvements,  and then when its status is clear to
| > what is still called "Silver".
| > 
| > Waldek sent a list ago (I don't have that mail right now), we
| > should work out the details for backport. 
| > 
| 
| That would certainly be fine with me. The main reason that I
| currently favour wh-sandbox is that Waldek recently "backported"
| a selection of revisions from build-improvements to wh-sandbox.

Yes, but that is fine.  It is normal process for branches to sync with
what they branched from even when they are going to backport.  In
fact, that should be the procedure for unconfusing backport. 

| But I am not completely certain of the status of all potential
| revisions that we might want to include in a new "Silver". Of
| course I am especially concerned about the ability to build on
| Windows but I haven't tested this yet.

The recent discussions with Tim, and the various tentative of
recreating new "Silvers" have made me less sympathetic to recreate yet
another silver.  Let's stick to a single point of reference. 

| From my point of view, the creation of a new "Silver" trunk is
| a little overdue.

We need an "upgraded" silver branch for sure.  However, we do have
severe communication problems. 

Let's upgrade build-improvements with backports from wh-sandbox.

| Unfortunately only you and Waldek are really
| in a good position to do this. But with your direction I am
| certainly willing to help - especially in testing of the new
| release.

I would really like to the fixes Waldek implemented to the Axiom
community.  Today is already overbooked for me [yeah, spring break was
over before it started].  But, tomorrow might be better.

\start
Date: Tue, 20 Mar 2007 12:33:27 -0400
From: Alfredo Portes
To: Gabriel Dos Reis
Subject: re: Guessing package,	was: Re: your program / paper
Cc: Waldek Hebisch

> | From my point of view, the creation of a new "Silver" trunk is
> | a little overdue.
>
> We need an "upgraded" silver branch for sure.  However, we do have
> severe communication problems.
>
> Let's upgrade build-improvements with backports from wh-sandbox.

But why not back porting quick fixes to Silver trunk directly from wh-sandbox?
Isnt that the purpose of Silver trunk to be experimental and represent
the latest
and greatest from Axiom? I think that Martin package and other quick
patches should have been added to silver trunk directly and not to the
branches.

\start
Date: Tue, 20 Mar 2007 13:35:08 -0400
From: Bill Page
To: Alfredo Portes, Gabriel Dos Reis
Subject: re: Guessing package,	was: Re: your program / paper
Cc: Waldek Hebisch

On March 20, 2007 12:33 PM Alfredo Portes wrote:
> 
> > Bill Page wrote: 
> > | From my point of view, the creation of a new "Silver" trunk
> > | is a little overdue.
> >
> Gaby wrote:
> > We need an "upgraded" silver branch for sure.  However, we do
> > have severe communication problems.
> >
> > Let's upgrade build-improvements with backports from wh-sandbox.
> 
> But why not back porting quick fixes to Silver trunk directly 
> from wh-sandbox? Isnt that the purpose of Silver trunk to be
> experimental and represent the latest and greatest from Axiom?

Actually as I understand it Silver is supposed to be the
"release candidate" for Axiom Gold. But as Gaby stated in such
an eloquent circumlocution: "We seem to have communications
problems." The procedure as set out by Tim Daly is not really
working and it seems that he is continuing on his own to
manually incorporate some of the changes now in the build-
improvements and wh-sandbox branches, effectively bypassing
the "Silver" stage. This might result in a new "Gold" but
it's pedigree will still be rather uncertain.

> I think that Martin package and other quick patches should
> have been added to silver trunk directly and not to the
> branches.
> 

wh-sandbox has implemented a radically different algebra build
process that avoids many of the problems associated with the
old "bootstrap" method. It has also implemented some significant
improvements to the way the Axiom database is built. Therefore
it is not clear to me if it would be possible to incorporate
Martin's package in the old Silver release without first
incorporating most (if not all) of the changes in wh-sandbox.
Silver is essentially just the old patch-50 from the tla
archives. You will recall the problems that we had last summer
trying to get Martin's code built on that system.

One could proceed by backporting all (or most) of the revisions
from the build-improvements branch and the wh-sandbox sub-
branch, but that would certainly be a lot of work! I think the
state of the current /silver branch (almost the same as /trunk)
on SourceForge is too distant from both build-improvements and
wh-sandbox branches to continue to serve as the base. It would
much better just to re-define it as something very close to the
current wh-sandbox (or build-improvements with wh-sandbox
backports).

\start
Date: Tue, 20 Mar 2007 14:15:48 -0400
From: Alfredo Portes
To: Bill Page
Subject: re: Guessing package,	was: Re: your program / paper
Cc: Waldek Hebisch, Gabriel Dos Reis

> wh-sandbox has implemented a radically different algebra build
> process that avoids many of the problems associated with the
> old "bootstrap" method. It has also implemented some significant
> improvements to the way the Axiom database is built. Therefore
> it is not clear to me if it would be possible to incorporate
> Martin's package in the old Silver release without first
> incorporating most (if not all) of the changes in wh-sandbox.
> Silver is essentially just the old patch-50 from the tla
> archives. You will recall the problems that we had last summer
> trying to get Martin's code built on that system.

Arghh... do not remind me :-).  I spent 3 days without been able to
create a live cd for Martin. But as I recall patch-50 broke something,
because Martin was able to add his package using patch-49.

> One could proceed by backporting all (or most) of the revisions
> from the build-improvements branch and the wh-sandbox sub-
> branch, but that would certainly be a lot of work! I think the
> state of the current /silver branch (almost the same as /trunk)
> on SourceForge is too distant from both build-improvements and
> wh-sandbox branches to continue to serve as the base. It would
> much better just to re-define it as something very close to the
> current wh-sandbox (or build-improvements with wh-sandbox
> backports).

One would think that with so many open source projects out there as
examples and the great minds that read this list, a working
development/release method could be achieved :-). But of course
this probably has been discussed many times on this list.

I just say this because I plan to work heavily on Doyen this summer
and would like to know "which" Axiom should I use.

By the way, what should be done with Axiom@Google?
If we cannot keep it up to date, I think we should remove it, especially
now that the problems with sourceforge look like they have been solved.

\start
Date: Tue, 20 Mar 2007 15:01:03 -0400
From: Alfredo Portes
To: Gabriel Dos Reis
Subject: re: Guessing package,	was: Re: your program / paper

On 3/20/07, Gabriel Dos Reis wrote:
> Quoting Alfredo Portes:
>
> > By the way, what should be done with Axiom@Google?
> > If we cannot keep it up to date, I think we should remove it, especially
> > now that the problems with sourceforge look like they have been solved.
>
> Ask for the nth times it to be reset to zero.
> Then let the community decide which source is to be the basis for
> future development.  Have everyone agrees on a roadmap to be followed.
>

I can do that. But then we cannot duplicate a directory like last time
or we are going to have the disk space problem again. But should
/trunk be removed first?  If Bill agrees, I can ask Ben to repopulate
like he did last time.

> What? we did that last time it didn't work? Hmm, out of idea :-(

The nth time should be the lucky one. :-)

\start
Date: Tue, 20 Mar 2007 15:08:33 -0400
From: Bill Page
To: Alfredo Portes
Subject: re: Guessing package,	was: Re: your program / paper
Cc: Waldek Hebisch, Gabriel Dos Reis

On March 20, 2007 2:16 PM Alfredo Portes wrote:
> ... 
> One would think that with so many open source projects out there
> as examples and the great minds that read this list, a working
> development/release method could be achieved :-). But of course
> this probably has been discussed many times on this list.
> 

The problem with the Axiom project are probably fairly typical
of open source projects. Somebody else must have said this
already but ... it seems to me that the biggest problem with
software development is the people. It's hard enough to manage
an ordinary software project but open source takes that a step
further - you might say that it is impossible even in principle
to manage an open source project. People do what they are
personally motivated to do. Sometimes that is good for
collaboration and sometimes it is bad.

> I just say this because I plan to work heavily on Doyen this
> summer and would like to know "which" Axiom should I use.

I've used all three: Axiom "Gold", build-improvements branch
and wh-sandbox. Right now wh-sandbox seems to me to be the
most stable and the most interesting.
 
> By the way, what should be done with Axiom@Google?
> If we cannot keep it up to date, I think we should remove
> it, especially now that the problems with sourceforge look
> like they have been solved.
> 

That is a good question. So far I have just let it sit after
we ran into the space limitation again. Personally I think
it is still worth having Google Code as a possible development
environment. What I would like to do is re-populate it with
the new Silver (= build-improvements + wh-sandbox) minus
all the history.

\start
Date: Tue, 20 Mar 2007 15:16:27 -0400
From: Bill Page
To: Alfredo Portes, Gabriel Dos Reis
Subject: re: Guessing package, was: Re: your program / paper

On March 20, 2007 3:01 PM Alfredo Portes
> 
> On 3/20/07, Gabriel Dos Reis wrote:
> > Quoting Alfredo Portes:
> >
> > > By the way, what should be done with Axiom@Google?
> > > If we cannot keep it up to date, I think we should remove 
> > > it, especially now that the problems with sourceforge
> > > look like they have been solved.
> >
> > Ask for the nth times it to be reset to zero.
> > Then let the community decide which source is to be the basis
> > for future development.  Have everyone agrees on a roadmap to
> > be followed.
> >
> 
> I can do that. But then we cannot duplicate a directory like 
> last time or we are going to have the disk space problem again.
> But should /trunk be removed first?

I think we should *first* merge build-improvements and wh-sandbox
to define a new "Silver" /trunk at SourceForge. Delete the old
/silver branch as SourceForge.

> If Bill agrees, I can ask Ben to repopulate like he did last
> time.

I don't think we can simply re-population with all the history
at SourceForge. The result would likely be too large again. I
would prefer to reset to 0 and then simply import the source
(minus the history) from the new "Silver" /trunk at SourceForge.

> 
> > What? we did that last time it didn't work? Hmm, out of
> > idea :-(
> 
> The nth time should be the lucky one. :-)
> 

Yes, let's do it again.

\start
Date: 21 Mar 2007 11:40:02 -0500
From: Gabriel Dos Reis
To: Bill Page
Subject: re: Guessing package,	was: Re: your program / paper

Bill Page writes:

[...]

| > I can do that. But then we cannot duplicate a directory like 
| > last time or we are going to have the disk space problem again.
| > But should /trunk be removed first?
| 
| I think we should *first* merge build-improvements and wh-sandbox
| to define a new "Silver" /trunk at SourceForge. Delete the old
| /silver branch as SourceForge.

If we all agree on that, I would like to work out the details 
(which patchsets, etc.) with Waldek so that we can present the
community with an improved system.  

But, I would really like to have a buy-in from the key developers.

For me, the ability to build Axiom on windows has become important.
The reason being that part of my working environment is Windows --
four months ago, I got one those "toys" are fully supported only by
windows at the moment.  However, I would like not have to spend 
time solving Windows specific issues. So, a single uniform code base
is a must. 

\start
Date: Wed, 21 Mar 2007 12:24:42 -0400
From: Bill Page
To: Gabriel Dos Reis, Tim Daly
Subject: re: Guessing package,	was: Re: your program / paper

On March 21, 2007 12:40 PM Gaby wrote:

> 
> Bill Page writes:
> 
> [...]
> 
> | I think we should *first* merge build-improvements and
> | wh-sandbox to define a new "Silver" /trunk at SourceForge.
> | Delete the old  /silver branch as SourceForge.
> 
> If we all agree on that, I would like to work out the details 
> (which patchsets, etc.) with Waldek so that we can present
> the community with an improved system.  
> 
> But, I would really like to have a buy-in from the key
> developers.
> 

Great.

Tim Daly is working on a new "Axiom Gold"

Gaby (and Waldek?) are working on a new "Axiom Silver"

Can we than formally take a vote?
---------------------------------

I vote: Yes.

And I volunteer to help with both efforts in any way possible.

\start
Date: Wed, 21 Mar 2007 18:39:29 +0100 (CET)
From: Waldek Hebisch
To: list
Subject: noweb and SVN

Looking at build problem (reported in private mail) I noticed
something which looks as serious incompatibility between svn
and noweb.  Namely, AFAICS files retrived by svn get timestamp
corresponding to time of retrival.  So, genereted files which
are up to date in repository may look out of date after checkout.
Typically this is not a problem because if checkout is fast
enough file and its dependencies get the same timestamp.
But sometimes we may loose race and files are needlessly
re-made, which again typically is not a big problem.  But
to re-make noweb we need noweb, so for noweb this is fatal.

We have the same problem with few critical build files,
notably with Makefile.in.

I think the the most natural solution for this problem is to require
already installed external noweb.

\start
Date: Wed, 21 Mar 2007 19:20:36 +0100
From: Ralf Hemmecke
To: Waldek Hebisch
Subject: Re: noweb and SVN

On 03/21/2007 06:39 PM, Waldek Hebisch wrote:
> Looking at build problem (reported in private mail) I noticed
> something which looks as serious incompatibility between svn
> and noweb.  Namely, AFAICS files retrived by svn get timestamp
> corresponding to time of retrival.  So, genereted files which
> are up to date in repository may look out of date after checkout.

I don't understand that. You must mean "working copy" instead of 
"repository". Why should "generated" files live inside the repository?

> Typically this is not a problem because if checkout is fast
> enough file and its dependencies get the same timestamp.
> But sometimes we may loose race and files are needlessly
> re-made, which again typically is not a big problem.  But
> to re-make noweb we need noweb, so for noweb this is fatal.

What kind of dependency is that? Noweb doesn't need noweb to build 
itself, so why would there be a dependency for the noweb that comes with 
the axiom sources at sourceforge?

> We have the same problem with few critical build files,
> notably with Makefile.in.

If this is generated from Makefile.in.pamphlet then eventually it should 
not live inside the repository.

> I think the the most natural solution for this problem is to require
> already installed external noweb.

That clearly gets my support.

\start
Date: 21 Mar 2007 14:23:03 -0500
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: noweb and SVN

Waldek Hebisch writes:

| Looking at build problem (reported in private mail) I noticed
| something which looks as serious incompatibility between svn
| and noweb.  Namely, AFAICS files retrived by svn get timestamp
| corresponding to time of retrival.  So, genereted files which
| are up to date in repository may look out of date after checkout.

This is a problem accute only because SVN does not have the
equivalent of "cvs ci -f", at least I have been unable to find it.
We may version the modification time of the generated files, but that
is not a solution I like.

| Typically this is not a problem because if checkout is fast
| enough file and its dependencies get the same timestamp.
| But sometimes we may loose race and files are needlessly
| re-made, which again typically is not a big problem.  But
| to re-make noweb we need noweb, so for noweb this is fatal.

Yes, if and when we need to regenerate noweb source files, it is a bug.

| 
| We have the same problem with few critical build files,
| notably with Makefile.in.
| 
| I think the the most natural solution for this problem is to require
| already installed external noweb.

That is a reasonable requiremnt for developers.  I'm not sure it
exports to most end users without getting the entry bar too high.
This is an issue I'm ambivalent about and don't have a clear cut
answer for.  

Let see, what the requirements would be:

  (1) need an installed lisp -- I still believe me must have GCL
      around as long as we cannot build Axiom with other systems.
  (2) need an installed noweb -- noweb is not as widely packaged
      as Lisp systems.
  (3) needs socket support -- I believe this is a bogus requirement
      at least for the time being.
  (4) needs installed latex

\start
Date: 21 Mar 2007 14:28:26 -0500
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: noweb and SVN

Ralf Hemmecke writes:

[...]

| > Typically this is not a problem because if checkout is fast
| > enough file and its dependencies get the same timestamp.
| > But sometimes we may loose race and files are needlessly
| > re-made, which again typically is not a big problem.  But
| > to re-make noweb we need noweb, so for noweb this is fatal.
| 
| What kind of dependency is that? Noweb doesn't need noweb to build
| itself, so why would there be a dependency for the noweb that comes
| with the axiom sources at sourceforge?

Noweb needs noweb to build, when the generated source files timestamps
appear out of date with respect to the .nw files'.  This happens from
time to time -- especially when you make a fresh check out.  That is a
bug that happened when I incorporated noweb in the tree.
It can be worked around by first 'touch'ing noweb/src/c/*.c.

[...]

| > I think the the most natural solution for this problem is to require
| > already installed external noweb.
| 
| That clearly gets my support.

I know how Tim feels about it; Bill what is your opinion?

\start
Date: Wed, 21 Mar 2007 14:33:54 -0400
From: Bill Page
To: Waldek Hebisch
Subject: RE: noweb and SVN

On March 21, 2007 1:39 PM Waldek Hebisch wrote:
> ... 
> We have the same problem with few critical build files,
> notably with Makefile.in.
> 

Yes, I confirm that sometimes this is problem. Sometimes
I have to 'touch' the Makefiles.

> I think the the most natural solution for this problem is to
> require already installed external noweb.
> 

I agree. In fact I think it would be best to also require
external gcl. We can do what is necessary to warn and advise
the user what to do when noweb or gcl are not found and we
can supply a non-trunk copy of these in the Axiom repository.

\start
Date: 21 Mar 2007 14:40:24 -0500
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: noweb and SVN

Bill Page writes:

[...]

| > I think the the most natural solution for this problem is to
| > require already installed external noweb.
| > 
| 
| I agree. In fact I think it would be best to also require
| external gcl. We can do what is necessary to warn and advise
| the user what to do when noweb or gcl are not found and we
| can supply a non-trunk copy of these in the Axiom repository.

OK, I'll implement the removal of noweb from the source code.
However, we must document the dependency and point to/put a copy of
readly available noweb.

I'm less enthousistic about the removal of GCL for the moment.

\start
Date: Wed, 21 Mar 2007 21:56:01 +0100 (CET)
From: Waldek Hebisch
To: Bill Page
Subject: re: Guessing package, was: Re: your program /	paper
Cc: Gabriel Dos Reis

Bill Page wrote:
> wh-sandbox has implemented a radically different algebra build
> process that avoids many of the problems associated with the
> old "bootstrap" method. It has also implemented some significant
> improvements to the way the Axiom database is built. Therefore
> it is not clear to me if it would be possible to incorporate
> Martin's package in the old Silver release without first
> incorporating most (if not all) of the changes in wh-sandbox.
> Silver is essentially just the old patch-50 from the tla
> archives. You will recall the problems that we had last summer
> trying to get Martin's code built on that system.
> 

Actually, one can add Martin's package to other branches.  The
new algebra bootstrap is not needed for that.  However the
method used (compiling the whole packeage in a single compiler
image) is differnt that method suggested in Makefile.pamhlet
and similar to bootstrap procedure.  

Also, IIUC Martin's package needs various algebra fixes.

\start
Date: Wed, 21 Mar 2007 22:15:00 +0100 (CET)
From: Waldek Hebisch
To: Gabriel Dos Reis
Subject: re: Guessing package, was: Re: your program /	paper

Gabriel Dos Reis wrote:
> Bill Page writes:
> 
> [...]
> 
> | > I can do that. But then we cannot duplicate a directory like 
> | > last time or we are going to have the disk space problem again.
> | > But should /trunk be removed first?
> | 
> | I think we should *first* merge build-improvements and wh-sandbox
> | to define a new "Silver" /trunk at SourceForge. Delete the old
> | /silver branch as SourceForge.
> 
> If we all agree on that, I would like to work out the details 
> (which patchsets, etc.) with Waldek so that we can present the
> community with an improved system.  
> 
> But, I would really like to have a buy-in from the key developers.
> 

Yes it would be good to have updated "base".  Concerning 
SourceForge silver: we probably should ask SourceForge staff
to delete it.   Currently silver togerher with "deleted" parts
takes about 200 MB of disk space -- anybody who uses rsync to
get copy of Axiom repository will get all of this. (AFAIUI normal
user on SourceForge can not remove anything from repository
-- old versions stay there forever).

\start
Date: Wed, 21 Mar 2007 22:23:33 +0100
From: Ralf Hemmecke
To: list
Subject: Emacs+ALLPROSE workaround for #line problem

Versions of the Aldor compiler up to 1.0.3 (I have not actually checked 
1.1.0rc1) cannot properly deal with #line directives.

ALLPROSE is a framework to produce Aldor libraries. Instead of .as 
files, the sources are noweb files (extension .as.nw). The .as files are 
actually generated and fed to the compiler. If an error is encountered 
the filename and line number point to the .as file. That is however 
*not* the actual source.

If compiling inside Emacs, the 'next-error' command jumps to the .as 
file and up to now one had to read the ALLPROSE-generated directives like

--#line 240 "sitools/sitools.as.nw"

to figure out manually where the error in the actual source file is.

With the help and code of Cliff Yap and Jay Belanger, I could now put 
together some lines that one has to put into the .xemacs/init.el file.
Now M-F12 jumps correctly into the .as.nw file.

Thank you Cliff and thank you Jay.

Ralf

PS: Since the .as file is still loaded by next-error, does someone know 
how I can get rid of those buffers in allprose-workaround-aldor-next-error ?


;--Workaround for the Aldor compiler bug of being unable to deal
;-- properly with #line directives
(defvar pamphlet-line-id "--#line ")
(defun find-previous-pamphlet-id-line ()
   (re-search-backward pamphlet-line-id nil t))
;;ALLPROSE spits out lines like
;;--#line 211 "poly/idxpp.as.nw"
(defun allprose-previous-input ()
   "Move to the previous input line."
   (interactive)
   (let ((orig (point))
         (pt (find-previous-pamphlet-id-line)))
     (if (not pt)
         (message "No id line found.")
       (let ((n (count-lines pt orig))
             (filename)
             (lineno))
	(re-search-forward " +")
	(setq lineno (current-word))
	(re-search-forward " +\"")
	(setq filename (thing-at-point 'filename))
	(find-file filename)
	(goto-line (+ n (string-to-number lineno) -1))))))

(defun allprose-workaround-aldor-next-error ()
   "Move point to the next error position in the corresponding .as.nw file."
   (interactive)
   (next-error)
   (allprose-previous-input))

(global-set-key [(meta f12)] 'allprose-workaround-aldor-next-error)

\start
Date: 21 Mar 2007 22:14:08 -0500
From: Gabriel Dos Reis
To: Tim Daly
Subject: spad-save

Tim --

  Is there a particular reason why "spad-save" is defined in package
"user", instead of "boot"?  

\start
Date: 21 Mar 2007 22:19:57 -0500
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: noweb and SVN

Gabriel Dos Reis writes:

| Bill Page writes:
| 
| [...]
| 
| | > I think the the most natural solution for this problem is to
| | > require already installed external noweb.
| | > 
| | 
| | I agree. In fact I think it would be best to also require
| | external gcl. We can do what is necessary to warn and advise
| | the user what to do when noweb or gcl are not found and we
| | can supply a non-trunk copy of these in the Axiom repository.
| 
| OK, I'll implement the removal of noweb from the source code.
| However, we must document the dependency and point to/put a copy of
| readly available noweb.

\start
Date: Thu, 22 Mar 2007 01:59:17 -0400
From: Alfredo Portes
To: list
Subject: FrontPage/Google SOC

The summer of code deadline has been pushed back to March 26th:

http://code.google.com/soc/

\start
Date: Thu, 22 Mar 2007 00:20:17 -0600
From: Tim Daly
To: list
Subject: silver/gold

I'm still in the process of trying to merge silver/BI/WH-sandbox.
I'm currently tracking down a compiler bug that was introduced by
one of the interp changes causing the compile of EXPR.spad to fail.

\start
Date: Thu, 22 Mar 2007 03:54:10 -0500
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: spad-save

Quoting Tim Daly:

> There is no obvious reason why spad-save is defined in user or boot.
> Is there a reason to change it?

yes.  The package "user" is not required to exist an ANSI comforming
Lisp implementation.  Therefore, we have a portability problem.

\start
Date: 22 Mar 2007 13:37:31 +0100
From: Martin Rubey
To: Waldek Hebisch
Subject: re: Guessing package,	was: Re: your program / paper
Cc: Gabriel Dos Reis

Waldek Hebisch writes:

> Also, IIUC Martin's package needs various algebra fixes.

I don't know what IIUC means, but I think I should comment:

YES.

My latest version (which guesses things of the form

binomial(a+b*n,n)*r(n),

r a rational function,

also needs the fix for iibinom in COMBF.

On the other hand, since my unpleasant experience of bad-fixing sttaylor, I
have written extensive documentation for *all* my fixes! Thus, including them
should not be a problem.

Very unfortunately, it seems that nobody is interested in porting Christian
Aistleitner's AldorUnit to libaxiom. This would save us a *lot* of trouble,
concerning the algebra. (More precisely, we could make it less likely that a
fix breaks other things - in a *very* axiom-like manner.)

\start
Date: Fri, 23 Mar 2007 12:01:21 -0400
From: Bill Page
To: list
Subject: Science calls Sage a "supercomputer"

In a recent widely distributed online edition of Science
Magazine, SCIENCE News This Week March 23 2007, 315 (5819)
Dana Mackenzie writes:

MATHEMATICS:
Mapping the 248-Fold Way
Dana Mackenzie
This week, an international team of 18 mathematicians and
computer scientists called the Atlas Project announced that
a supercomputer called Sage has successfully "mapped" a vast,
248-dimensional entity known as E8. (Read more.)

http://www.sciencemag.org/cgi/content/full/315/5819/1647

"On 8 January, Sage, a supercomputer at the University of
Washington, computed the last entry in the table for E8."

As much as I value getting some long needed press for things
related to computer algebra, I am particularly disturbed that a
high profile publication like Science Magazine from the American
Association for the Advancement of Science should so badly
misrepresent the nature of a computer algebra system! :-( Oh
please, won't somebody please to Science Magazine the difference
between a supercomputer and a computer program? Ok, it is true
that the server that Sage runs on at the math department at
University of Washington is a nice and fast 16-processor linux
system, but the last time I looked that didn't qualify it as
a supercomputer...

http://www.sagemath.org/sage.html

Even here at

http://aimath.org/E8/

we can read:

"News flash:
Congressman Jerry McNerney will deliver a commendation of the
Atlas team to Congress on Tuesday, March 27. Watch it on TV!"

and

"In the end the calculation took about 77 hours on the
supercomputer Sage."

Would it be *that* embarrassing to admit that almost anyone
with a high end "gaming" desktop computer could do this same
calculation in about the same amount of time? Perhaps yes,
given how much NSF money has gone into supporting super
computer projects...

--------

For some reason this type of journalism and "science by press
release" disturbs me. Am I alone in this reaction? Do we have
to promote our work this way?

BTW, congratulations to the mathematicians of the Atlas project.
In spite of the hype, this is of course a momentus result!

\start
Date: Fri, 23 Mar 2007 09:25:57 -0700
From: Justin Walker
To: list
Subject: Re: [sage-devel] Science calls Sage a "supercomputer"


On Mar 23, 2007, at 09:01 , Bill Page wrote:

> As much as I value getting some long needed press for things
> related to computer algebra, I am particularly disturbed that a
> high profile publication like Science Magazine from the American
> Association for the Advancement of Science should so badly
> misrepresent the nature of a computer algebra system!

The software used in the E8 project is readily available, and it  
looks to be more-or-less pure C++.  There is only one mention of  
SAGE, and that is in a directory string: "/data1/sage".

I think that they used sage.math, not SAGE.

Still, there is a bunch of hype that could be misleading, but I don't  
think it's a big deal.  "Any publicity...", as has been often observed.

\start
Date: 24 Mar 2007 19:07:07 -0500
From: Gabriel Dos Reis
To: list
Subject: [build-improvements] Remove dead packages

This patch removes dead packages SCRATCHPAD_COMPILER and SPECFNSF.
Furthermore, it removes "define-macro" which is not used anywhere.
GCL's extension system::getenv is consistently used with
package name prefix, so we don't need any import or whatever.

Applied to build-improvements.

Next, I would like to move VMLISP content to BOOT.  The existing
separate VMLISP package definition followed by a long list of import
of almost all of VMLISP in BOOT is an over-engineering.

Next, I would like to have a less confusing naming for packages that
contain Boot to Lisp translator, and Axiom interpreter and compilers.

-- Gaby

2007-03-24  Gabriel Dos Reis  Gabriel Dos Reis

	* vmlisp.lisp.pamphlet (define-macro): Likewise.
	* sys-pkg.lisp.pamphlet: Remove dead packages SCRATCHPAD_COMPILER
	and SPECFNSF.
	(define-macro): Remove.
	Remove explicit import of GCL's system::getenv.

*** src/interp/sys-pkg.lisp.pamphlet	(revision 19354)
--- src/interp/sys-pkg.lisp.pamphlet	(local)
***************
*** 1,79 ****
  \documentclass{article}
  \usepackage{axiom}
! \begin{document}
! \title{\$SPAD/src/interp sys-pkg.lisp}
  \author{Timothy Daly}
  \maketitle
  \begin{abstract}
  \end{abstract}
  \newpage
  \tableofcontents
  \newpage
  \section{Non-portable code}
  \subsection{GCL only code}
  This section contains code that will only work in Gnu Common Lisp
  (GCL). These tagged symbols are split out so we can find suitable
  replacements in other common lisps.
! \subsubsection{GETENV}
! GETENV is a GCL function to return the value of shell variables
! from the environment.
! <<GCL.GETENV>>=
! #+:GCL   SYSTEM:GETENV
! @ 
! \subsubsection{DEFINE-MACRO}
! <<GCL.DEFINE-MACRO>>=
! #+:GCL    SYSTEM:DEFINE-MACRO 
! @ 
  \subsubsection{MEMQ}
  <<GCL.MEMQ>>=
  #+:GCL    SYSTEM:MEMQ 
  @ 
  \subsubsection{PNAME}
  <<GCL.PNAME>>=
  #+:GCL    SYSTEM:PNAME
  @ 
- \section{New Common Lisp Changes}
- \subsection{in-package change}
- Common lisp has changed in-package to require a string-designator which
- is a character, string, or symbol. Further, if the package does not exist
- then in-package will throw an error. We fix this by using defpackage.
- We create all of the known packages here.
- <<*>>=
- <<license>>
  
! @
! The spad compiler package. Although I believe this is a dead
! package at this point. All of the symbols from this package
! have been moved into the boot package.
  <<*>>=
! (make-package "SCRATCHPAD_COMPILER")
  @
- The special functions package. There was originally lisp code
- to support hardcoded knowledge of special functions like gamma.
- This is also a dead package as the functions have been lifted
- to the algebra level.
- <<*>>=
- (make-package "SPECFNSF")
  
! @
! This is the package that originally contained the VMLisp macros
  but in fact contains macros to support several other lisps. It
  is essentially the place where most of the macros to support
! idioms from prior ports (like rdefiostream and fileactq)
  <<*>>=
  (make-package "VMLISP")
  (in-package "VMLISP")
  (lisp::use-package '("USER" "SYSTEM" "LISP"))
  
  @
! This is the boot to lisp compiler package which contains the
! src/boot files. Tt is the boot translator package.
  <<*>>=
  (make-package "BOOTTRAN")
  (in-package "BOOTTRAN")
  (lisp::use-package '("LISP"))
  
  @
  Everything in axiom that the user references eventually shows
  up here. The interpreter and the algebra are run after switching
  to the boot package (in-package "BOOT") so any symbol that the
--- 1,81 ----
+ %% Oh Emacs, this is a -*- Lisp -*- file, despite appearance.
  \documentclass{article}
  \usepackage{axiom}
! 
! \title{\Fil{src/interp/sys-pkg.lisp} Pamphlet}
  \author{Timothy Daly}
+ 
+ \begin{document}
  \maketitle
+ 
  \begin{abstract}
  \end{abstract}
  \newpage
  \tableofcontents
  \newpage
+ 
+ 
  \section{Non-portable code}
+ 
  \subsection{GCL only code}
+ 
  This section contains code that will only work in Gnu Common Lisp
  (GCL). These tagged symbols are split out so we can find suitable
  replacements in other common lisps.
! 
  \subsubsection{MEMQ}
  <<GCL.MEMQ>>=
  #+:GCL    SYSTEM:MEMQ 
  @ 
+ 
  \subsubsection{PNAME}
  <<GCL.PNAME>>=
  #+:GCL    SYSTEM:PNAME
  @ 
  
! 
! \section{The many packages}
! 
! Building \Tool{Axiom}, in its current state, requires five packages.
! We create all of them here.  
  <<*>>=
! <<license>>
  @
  
! \subsection{The [[VMLISP]] package}
! 
! This is the package that originally contained the \Tool{VMLisp} macros
  but in fact contains macros to support several other lisps. It
  is essentially the place where most of the macros to support
! idioms from prior ports (like [[rdefiostream]] and [[fileactq]])
  <<*>>=
  (make-package "VMLISP")
  (in-package "VMLISP")
  (lisp::use-package '("USER" "SYSTEM" "LISP"))
  
  @
! 
! We plan to move the content of [[VMLISP]] to [[BOOT]].
! 
! 
! \subsection{The [[BOOTTRAN]] package}
! 
! This is the old Boot to Lisp translator package.
  <<*>>=
  (make-package "BOOTTRAN")
  (in-package "BOOTTRAN")
  (lisp::use-package '("LISP"))
  
  @
+ 
+ Note that the directory \File{src/boot} defines similar package
+ for ``new Boot'' (or Shoe).  Eventually, the old Boot to Lisp 
+ translator will disappear so that the [[BOOTTRAN]] package will 
+ not be created here anymore.
+ 
+ 
+ \subsection{The [[BOOT]] package}
+ 
  Everything in axiom that the user references eventually shows
  up here. The interpreter and the algebra are run after switching
  to the boot package (in-package "BOOT") so any symbol that the
*************** interpreter or algebra uses has to (coug
*** 84,89 ****
--- 86,99 ----
  (lisp::use-package '("VMLISP" "LISP"))
  
  @
+ 
+ Note that it is confusing the package \Tool{Axiom}'s compiler and
+ interpreter use is called [[BOOT]].  It should have been
+ [[Spad]], or better yet [[Axiom]].
+ 
+ 
+ \subsection{The [[FOAM]] package}
+ 
  FOAM is the intermediate language for the aldor compiler. FOAM
  means "first order abstract machine" and functions similar to
  RTL for the GCC compiler. It is a "machine" that is used as the
*************** expanded for the real target machine (or
*** 95,100 ****
--- 105,113 ----
  (lisp::use-package '("LISP"))
  
  @
+ 
+ \subsection{The [[FOAM-USER]] package}
+ 
  FOAM-USER is the package containing foam statements and macros
  that get inserted into user code versus the foam package which
  provides support for compiler code.
*************** provides support for compiler code.
*** 109,115 ****
      '(VMLISP::ERROROUTSTREAM LISP::COUNT VMLISP::NE VMLISP::FLUID
  	 LISP:SEQUENCE VMLISP::OBEY LISP:NUMBER VMLISP::|union|
  	 LISP:STEP VMLISP::OPTIONLIST VMLISP::EXIT VMLISP::throw-protect
- <<GCL.GETENV>>
           VMLISP::*INDEX-FILENAME*))
  (lisp:export
      '(BOOT::|$FormalMapVariableList| BOOT::|$userModemaps|
--- 122,127 ----
*************** provides support for compiler code.
*** 327,339 ****
  ;;; Definitions for package VMLISP of type EXPORT
  (lisp:in-package "VMLISP")
  (lisp:import '(
- <<GCL.DEFINE-MACRO>>
  <<GCL.MEMQ>>
  <<GCL.PNAME>>
  	  BOOT:|directoryp|))
  (lisp:export
      '(VMLISP::SINTP VMLISP::$FCOPY 
- <<GCL.DEFINE-MACRO>>
  <<GCL.MEMQ>>
  <<GCL.PNAME>>
           VMLISP::PUT
--- 339,349 ----
*************** provides support for compiler code.
*** 465,471 ****
  
  ;;; Definitions for package VMLISP of type SHADOW
  (lisp:in-package "VMLISP")
! (lisp:import '(SYSTEM::DEFINE-MACRO SYSTEM::MEMQ SYSTEM::PNAME))
  
  
  (in-package "BOOT") ;; Used to be "UNCOMMON"
--- 475,481 ----
  
  ;;; Definitions for package VMLISP of type SHADOW
  (lisp:in-package "VMLISP")
! (lisp:import '(SYSTEM::MEMQ SYSTEM::PNAME))
  
  
  (in-package "BOOT") ;; Used to be "UNCOMMON"
*************** FOAM::|BIntTimesPlus|
*** 1071,1077 ****
--- 1081,1090 ----
  FOAM::|BIntNext|
  ))
  @
+ 
+ 
  \section{License}
+ 
  <<license>>=
  ;; Copyright (c) 1991-2002, The Numerical ALgorithms Group Ltd.
  ;; All rights reserved.
*** src/interp/util.lisp.pamphlet	(revision 19354)
--- src/interp/util.lisp.pamphlet	(local)
***************
*** 1,15 ****
  \documentclass{article}
  \usepackage{axiom}
! \begin{document}
  \title{\$SPAD/src/interp util.lisp}
  \author{Timothy Daly}
  \maketitle
  \begin{abstract}
  \end{abstract}
  \eject
  \tableofcontents
  \eject
  \section{util.lisp}
  This file is a collection of utility functions that are useful
  for system level work. A couple of the functions, {\bf build-depsys}
  and {\bf build-interpsys} interface to the src/interp/Makefile.
--- 1,22 ----
+ % Oh Emacs, this is a -*- Lisp -*- file, despite appearance.
  \documentclass{article}
  \usepackage{axiom}
! 
  \title{\$SPAD/src/interp util.lisp}
  \author{Timothy Daly}
+ 
+ \begin{document}
  \maketitle
+ 
  \begin{abstract}
  \end{abstract}
  \eject
  \tableofcontents
  \eject
+ 
+ 
  \section{util.lisp}
+ 
  This file is a collection of utility functions that are useful
  for system level work. A couple of the functions, {\bf build-depsys}
  and {\bf build-interpsys} interface to the src/interp/Makefile.
*************** search Emacs TAGS files.
*** 29,35 ****
--- 36,44 ----
  A fifth group of related functions are some translated boot
  functions we need to define here so they work and are available
  at load time.
+ 
  \subsection{Building Depsys (build-depsys)}
+ 
  The {\bf depsys} image is one of the two images we build from
  the src/interp subdirectory (the other is {\bf interpsys}). We
  use {\bf depsys} as a compile-time image as it contains all of
*************** loaded.
*** 56,62 ****
--- 65,73 ----
  ;;		      :rpages 1000 :hole 2000) )
  
  @
+ 
  \subsubsection{make-depsys}
+ 
  When we are building a {\bf depsys} image for AKCL (now GCL) we need
  need to initialize some optimization routines. Each time a file is
  compiled in GCL we collect some function information and write it
*************** into the image. It used to read:
*** 90,95 ****
--- 101,107 ----
    )
  
  @
+ 
  \subsection{Building Interpsys (build-interpsys)}
  \begin{verbatim}
  ;############################################################################
*************** After this function is called the image 
*** 158,164 ****
--- 170,178 ----
   )
  
  @
+ 
  \subsubsection{GCL porting changes}
+ 
  GCL likes to output lines of the form:
  \begin{verbatim}
  ;; Note: Tail-recursive call of |matSuperList1| was replaced by iteration.
*************** he was debugging tail-recursive replacem
*** 169,175 ****
--- 183,192 ----
    #+:AKCL
    (setq compiler::*suppress-compiler-notes* t)
  @
+ 
+ 
  \subsection{The variables}
+ 
  Various lisps use different ``extensions'' on the filename to indicate
  that a file has been compiled. We set this variable correctly depending
  on the system we are using.
*************** on the system we are using.
*** 182,195 ****
--- 199,217 ----
    #+:ccl "not done this way at all")
  
  @
+ 
  \subsubsection{directory-list}
+ 
  This is the system-wide list of directories to search.
  It is set up in the {\bf reroot} function.
  <<directory-list>>=
  (defvar $directory-list ())
  
  @
+ 
+ 
  \subsubsection{relative-directory-list}
+ 
  The relative directory list specifies a search path for files 
  for the current directory structure. It has been changed from the
  NAG distribution back to the original form. 
*************** NAG distribution back to the original fo
*** 202,222 ****
--- 224,252 ----
      "/doc/spadhelp/" ))
  
  @
+ 
+ 
  \subsubsection{library-directory-list}
+ 
  This is the system-wide search path for library files.
  It is set up in the {\bf reroot} function.
  <<library-directory-list>>=
  (defvar $library-directory-list ())
  
  @
+ 
  \subsubsection{relative-library-directory-list}
+ 
  The relative directory list specifies how to find the algebra
  directory from the current {\bf AXIOM} shell variable.
  <<relative-library-directory-list>>=
  (defvar $relative-library-directory-list '("/algebra/"))
  
  @
+ 
+ 
  \subsection{The autoload list}
+ 
  There are several subsystems within {\bf AXIOM} that are not normally
  loaded into a running system. They will be loaded only if you invoke
  one of the functions listed here. Each of these listed functions will
*************** overwritten, the function call is retrie
*** 227,233 ****
--- 257,265 ----
  containing functions listed here are assumed to exist in the 
  {\bf autoload} subdirectory. The list of files to load is defined
  in the src/interp/Makefile.
+ 
  \subsubsection{setBootAutloadProperties}
+ 
  This function is called by {\bf build-interpsys}. It takes two lists.
  The first is a list of functions that need to be used as 
  ``autoload triggers''. The second is a list of files to load if one
*************** This helper function is listed below.
*** 246,252 ****
--- 278,286 ----
  )
  
  @
+ 
  \subsubsection{setBootAutoLoadProperty}
+ 
  This is a helper function to set up the autoload trigger. It sets
  the function cell of each symbol to {\bf mkBootAutoLoad} which is
  listed below. 
*************** listed below. 
*** 255,261 ****
--- 289,297 ----
    (setf (symbol-function func) (|mkBootAutoLoad| func file-list)) )
  
  @
+ 
  \subsubsection{mkBootAutoLoad}
+ 
  This is how the autoload magic happens. Every function named in the
  autoload lists is actually just another name for this function. When
  the named function is called we call {\bf boot-load} on all of the
*************** call succeeds.
*** 271,277 ****
--- 307,315 ----
  		  (apply (symbol-function fn) args)))))
  
  @
+ 
  \subsubsection{boot-load}
+ 
  This function knows where the {\bf autoload} subdirectory lives.
  It is called by {\bf mkBootAutoLoad} above to find the necessary
  files.
*************** files.
*** 283,289 ****
--- 321,329 ----
      (load name)))
  
  @
+ 
  \subsubsection{setNAGBootAutloadProperties}
+ 
  This is a further refinement of the autoload scheme. Since the
  Numerical Algorithms Group (NAG) fortran library contains many
  functions we subdivide the NAG library subsystem into chapters.
*************** which files to load.
*** 299,305 ****
--- 339,347 ----
      file-list))
  
  @
+ 
  \subsubsection{get-NAG-chapter}
+ 
  This function is used to find the names of the files to load.
  On solaris 9 under GCL the original implementation will fail because
  the max number of arguments is 63. We rewrite it to get around this
*************** problem. It originally read:
*** 323,329 ****
--- 365,373 ----
    (nreverse r)))
  
  @
+ 
  \subsubsection{nag-files}
+ 
  We analyze the function names to decide which chapter we are in.
  We load files based on the chapter.
  <<nag-files>>=
*************** We load files based on the chapter.
*** 334,340 ****
--- 378,386 ----
       filelist)))
  
  @
+ 
  \subsubsection{chapter-name}
+ 
  The library names follow a convention that allows us to extract
  the chapter name. 
  <<chapter-name>>=
*************** the chapter name. 
*** 349,355 ****
--- 395,403 ----
  )
  
  @
+ 
  \subsubsection{parse-functions}
+ 
  This is the {\bf boot parser} subsystem. It is only needed by 
  developers who translate boot code to Common Lisp.
  <<parse-functions>>=
*************** developers who translate boot code to Co
*** 364,370 ****
--- 412,420 ----
  	init-boot/spad-reader))
  
  @
+ 
  \subsubsection{comp-functions}
+ 
  This is the {\bf spad compiler} subsystem. It is only needed by
  developers who write or modify algebra code.
  <<comp-functions>>=
*************** developers who write or modify algebra c
*** 381,387 ****
--- 431,439 ----
  	|sublisV|))
  
  @
+ 
  \subsubsection{browse-functions}
+ 
  This is the {\bf browser} subsystem. It will get autoloaded only
  if you use the browse function of the {\bf hypertex} system.
  <<browse-functions>>=
*************** if you use the browse function of the {\
*** 444,450 ****
--- 496,504 ----
  	|unescapeStringsInForm|))
  
  @
+ 
  \subsubsection{translate-functions}
+ 
  This is a little used subsystem to generate {\bf ALDOR} code
  from {\bf Spad} code. Frankly, I'd be amazed if it worked.
  <<translate-functions>>=
*************** from {\bf Spad} code. Frankly, I'd be am
*** 455,461 ****
--- 509,517 ----
  	))
  
  @
+ 
  \subsubsection{asauto-functions}
+ 
  This is part of the {\bf ALDOR subsystem}. These will be loaded
  if you compile a {\bf .as} file rather than a {\bf .spad} file.
  {\bf ALDOR} is an external compiler that gets automatically called
*************** if the file extension is {\bf .as}.
*** 475,481 ****
--- 531,539 ----
          |attributesToAxFile| ))
  
  @
+ 
  \subsubsection{debug-functions}
+ 
  These are some {\bf debugging} functions that I use. I can't imagine
  why you might autoload them but they don't need to be in a running
  system.
*************** system.
*** 489,495 ****
--- 547,555 ----
  	|showImp|))
  
  @
+ 
  \subsubsection{anna-functions}
+ 
  The {\bf ANNA} subsystem, invoked thru {\bf hypertex}, is an
  expert system that understands the Numerical Algorithms Group (NAG)
  fortran library. 
*************** fortran library. 
*** 523,529 ****
--- 583,591 ----
  	|annaOdeDefaultSolve2|))
  
  @
+ 
  \subsubsection{nagbr-functions}
+ 
  The Numerical Algorithms Group (NAG) fortran library has a set
  of cover functions. These functions need to be loaded if you use
  the NAG library.
*************** the NAG library.
*** 564,571 ****
--- 626,637 ----
        ))
  
  @
+ 
+ 
  \subsection{The command-line build functions}
+ 
  \subsubsection{translist}
+ 
  Translate a list of boot files to common lisp.
  <<translist>>=
  (defun translist (fns)
*************** Translate a list of boot files to common
*** 574,580 ****
--- 640,648 ----
  	  fns))
  
  @
+ 
  \subsubsection{translate}
+ 
  Translate a single boot file to common lisp
  <<translate>>=
  (defun translate (file) ;; translates a single boot file
*************** Translate a single boot file to common l
*** 588,594 ****
--- 656,664 ----
      (boot bootfile (make-pathname :type "lisp" :defaults bootfile))))
  
  @
+ 
  \subsubsection{compile-boot-file}
+ 
  Translate a single boot file to common lisp, compile it 
  and load it.
  <<compile-boot-file>>=
*************** and load it.
*** 604,610 ****
--- 674,682 ----
  )
  
  @
+ 
  \subsubsection{retranslate-file-if-necessary}
+ 
  Retranslate a single boot file if it has been changed.
  <<retranslate-file-if-necessary>>=
  (defun retranslate-file-if-necessary (bootfile)
*************** Retranslate a single boot file if it has
*** 619,625 ****
--- 691,699 ----
  		      (boot bootfile lfile) (list bootfile))))))
  
  @
+ 
  \subsubsection{retranslate-directory}
+ 
  Translate a directory of boot code to common lisp if the boot code
  is newer.
  <<retranslate-directory>>=
*************** is newer.
*** 631,637 ****
--- 705,713 ----
        (mapcan #'retranslate-file-if-necessary files)))
  
  @
+ 
  \subsubsection{recompile-NRLIB-if-necessary}
+ 
  Recompile a single library's lisp file if it is out of date.
  The {\bf recompile-lib-file-if-necessary} is defined in nlib.lisp.
  <<recompile-NRLIB-if-necessary>>=
*************** The {\bf recompile-lib-file-if-necessary
*** 640,646 ****
--- 716,724 ----
    (lift-NRLIB-name (namestring lib)))
  
  @
+ 
  \subsubsection{lift-NRLIB-name}
+ 
  We used to use FOO.NRLIB/code.o files for algebra. However there
  was no need for this additional level of indirection since the rest
  of the information in an NRLIB is now kept in the daase files. Thus
*************** we lift the FOO.NRLIB/code.o to FOO.o in
*** 651,657 ****
--- 729,737 ----
    nil)
  
  @
+ 
  \subsubsection{recompile-lib-directory}
+ 
  Recompile library lisp code if necessary.
  <<recompile-lib-directory>>=
  (defun recompile-lib-directory (dir)
*************** Recompile library lisp code if necessary
*** 662,668 ****
--- 742,750 ----
        (mapcan #'recompile-NRLIB-if-necessary files)))
  
  @
+ 
  \subsubsection{recompile-all-files}
+ 
  Force recompilation of all lisp files in a directory.
  <<recompile-all-files>>=
  (defun recompile-all-files (dir)
*************** Force recompilation of all lisp files in
*** 673,679 ****
--- 755,763 ----
       (mapcar #'compile-file files)))
  
  @
+ 
  \subsubsection{recompile-directory}
+ 
  This function will compile any lisp code that has changed in a directory.
  <<recompile-directory>>=
  (defun recompile-directory (dir)
*************** This function will compile any lisp code
*** 684,690 ****
--- 768,776 ----
        (mapcan #'recompile-file-if-necessary files)))
  
  @
+ 
  \subsubsection{recompile-file-if-necessary}
+ 
  This is a helper function that checks the time stamp between
  the given file and its compiled binary. If the file has changed
  since it was last compiled this function will recompile it.
*************** since it was last compiled this function
*** 700,706 ****
--- 786,794 ----
  	     (list bfile)))))
  
  @
+ 
  \subsubsection{our-write-date}
+ 
  Get the write date of a file. In GCL we need to check that it
  exists first. This is a simple helper function.
  <<our-write-date>>=
*************** exists first. This is a simple helper fu
*** 708,714 ****
--- 796,804 ----
  				  (file-write-date file)))
  
  @
+ 
  \subsubsection{fe}
+ 
  I'm unsure what this does but I believe it is related to an interpreter
  command. Invoking ``)fe'' in the interpreter tries to get at the 
  src/interp/TAGS file.
*************** src/interp/TAGS file.
*** 726,732 ****
--- 816,824 ----
  			(load (make-pathname :type *bin-path* :defaults tlispfile)))
        (load tlispfile))))
  @
+ 
  \subsubsection{fc}
+ 
  I'm unsure what this does but I believe it is related to an interpreter
  command. Invoking ``)fc'' in the interpreter tries to get at the 
  src/interp/TAGS file.
*************** src/interp/TAGS file.
*** 734,740 ****
--- 826,834 ----
  (defun fc (function file) (fe function file t))
  
  @
+ 
  \subsubsection{compspadfiles}
+ 
  The {\bf compspadfiles} function will recompile a list of {\bf spad} files.
  The filelist should be a file containing names of files to compile.
  <<compspadfiles>>=
*************** The filelist should be a file containing
*** 749,755 ****
--- 843,851 ----
  	      (spad fname (concat (pathname-name fname) ".out"))))))
  
  @
+ 
  \subsubsection{load-directory}
+ 
  Load a whole subdirectory of compiled files
  <<load-directory>>=
  (defun load-directory (dir)
*************** Load a whole subdirectory of compiled fi
*** 760,766 ****
--- 856,864 ----
        (mapcar #'load files)))
  
  @
+ 
  \subsubsection{interp-make-directory}
+ 
  This is used by the ")cd" system command.
  <<interp-make-directory>>=
  (defun interp-make-directory (direc)
*************** This is used by the ")cd" system command
*** 790,796 ****
--- 888,896 ----
        direc))))
  
  @
+ 
  \subsubsection{make-directory}
+ 
  Make a directory relative to the {\bf \$spadroot} variable.
  <<make-directory>>=
  (defun make-directory (direc)
*************** Make a directory relative to the {\bf \$
*** 815,821 ****
--- 915,923 ----
        direc))))
  
  @
+ 
  \subsubsection{recompile-all-libs}
+ 
  Occasionally it will be necessary to iterate over all of the NRLIB
  directories and compile each of the code.lsp files in every NRLIB.
  This function will do that. A correct call looks like:
*************** where the [[${SYS}]] variable is same as
*** 835,841 ****
--- 937,945 ----
         files)))
  
  @
+ 
  \subsubsection{recompile-all-algebra-files}
+ 
  We occasionally need to completely rebuild the algebra from the spad
  files. This function will iterate across a directory containing all
  of the spad files and attempt to recompile them. A correct call looks
*************** and all of the matching files would be r
*** 867,873 ****
--- 971,979 ----
         files)))
  
  @
+ 
  \subsubsection{boottocl}
+ 
  The {\bf boottocl} function is the workhorse function that translates
  {\bf .boot} files to {\bf Common Lisp}. It basically wraps the actual
  {\bf boot} function call to ensure that we don't truncate lines 
*************** because of {\bf *print-level*} or {\bf *
*** 888,894 ****
--- 994,1002 ----
        (merge-pathnames (make-pathname :type "clisp") file))))
  
  @
+ 
  \subsubsection{yearweek}
+ 
  We need a way of distinguishing different versions of the system.
  There used to be a way to touch the src/timestamp file whenever
  you checked in a change to the change control subsystem. 
*************** format string from the file [[src/doc/ms
*** 922,928 ****
--- 1030,1038 ----
        (setq *yearweek* "no timestamp")))
  
  @
+ 
  \subsubsection{makelib}
+ 
  Make will not compare dates across directories.
  Rather than copy all of the code.lsp files to the MNT directory
  we run this function to compile the files that are out of date
*************** need to be compiled without optimize due
*** 991,997 ****
--- 1101,1109 ----
        (compile-lib-file dotlsp :output-file doto)))))))
  
  @
+ 
  \subsubsection{makespad}
+ 
  Make will not compare dates across directories.
  In particular, it cannot compare the algebra files because there
  is a one-to-many correspondence. This function will walk over
*************** quality we check anyway.
*** 1067,1073 ****
--- 1179,1187 ----
       (format tmp ")co ~a~%" spad))))))
  
  @
+ 
  \subsubsection{libcheck}
+ 
  We need to ensure that the INTERP.EXPOSED list, which is a list
  of the exposed constructors, is consistent with the actual libraries.
  <<libcheck>>=
*************** of the exposed constructors, is consiste
*** 1199,1205 ****
--- 1313,1322 ----
      (format t "libcheck:~a has no spad source file~%" item)))))
  
  @
+ 
+ 
  \subsection{Constructing TAGS}
+ 
  TAGS are useful for finding functions if you run Emacs. We have a
  set of functions that construct TAGS files for Axiom.
  \subsubsection{make-tags-file}
*************** final TAGS file is constructed in the {\
*** 1215,1221 ****
--- 1332,1340 ----
    (obey "cat /tmp/boot.TAGS >> /tmp/TAGS"))
  
  @
+ 
  \subsubsection{spadtags-from-directory}
+ 
  This function will walk across a directory and call 
  {\bf spadtags-from-file} on each file.
  <<spadtags-from-directory>>=
*************** This function will walk across a directo
*** 1242,1248 ****
--- 1361,1369 ----
  		     (write-line line tagstream)))))))
  
  @
+ 
  \subsubsection{spadtags-from-file}
+ 
  This function knows how to find function names in {\bf boot} code
  so we can add them to the TAGS file using standard etags format.
  <<spadtags-from-file>>=
*************** so we can add them to the TAGS file usin
*** 1283,1289 ****
--- 1404,1412 ----
  					  line-count char-count))  )))))))
  
  @
+ 
  \subsubsection{write-tag-line}
+ 
  This function knows how to write a single line into a TAGS file
  using the etags file format.
  <<write-tag-line>>=
*************** using the etags file format.
*** 1296,1309 ****
--- 1419,1436 ----
    (terpri tagstream))
  
  @
+ 
  \subsubsection{blankcharp}
+ 
  This is a trivial predicate for calls to {\bf position-if-not} in the
  {\bf findtag} function.
  <<blankcharp>>=
  (defun blankcharp (c) (char= c #\Space))
  
  @
+ 
  \subsubsection{findtag}
+ 
  The {\bf findtag} function is a user-level function to figure out
  which file contains a given tag. This is sometimes useful if Emacs
  is not around or TAGS are not loaded.
*************** is not around or TAGS are not loaded.
*** 1347,1353 ****
--- 1474,1482 ----
  		       (return (cons sourcefile tagline))))))))
  
  @
+ 
  \subsubsection{match-lisp-tag}
+ 
  The {\bf match-lisp-tag} function is used by {\bf findtag}. This
  function assumes that \\ can only appear as first character of name.
  <<match-lisp-tag>>=
*************** function assumes that \\ can only appear
*** 1369,1376 ****
--- 1498,1509 ----
  	     (eq tag (read-from-string tagline nil nil :start pos))) ))
  
  @
+ 
+ 
  \subsection{Translated Boot functions}
+ 
  \subsubsection{string2BootTree}
+ 
  <<string2BootTree>>=
  (DEFUN |string2BootTree| (S)
    (init-boot/spad-reader)
*************** function assumes that \\ can only appear
*** 1384,1390 ****
--- 1517,1525 ----
      (DEF-RENAME (|new2OldLisp| PARSEOUT))))
  
  @
+ 
  \subsubsection{string2SpadTree}
+ 
  <<string2SpadTree>>=
  (DEFUN |string2SpadTree| (LINE)
    (DECLARE (SPECIAL LINE))
*************** function assumes that \\ can only appear
*** 1401,1413 ****
--- 1536,1553 ----
      PARSEOUT))
  
  @
+ 
  \subsubsection{processSynonyms}
+ 
  ;;--------------------> NEW DEFINITION (see i-syscmd.boot.pamphlet)
  <<processSynonyms>>=
  (defun |processSynonyms| () nil) ;;dummy def for depsys, redefined later
  
  @
+ 
+ 
  \section{License}
+ 
  <<license>>=
  ;; Copyright (c) 1991-2002, The Numerical ALgorithms Group Ltd.
  ;; All rights reserved.
*** src/interp/vmlisp.lisp.pamphlet	(revision 19354)
--- src/interp/vmlisp.lisp.pamphlet	(local)
*************** Contributed by Juergen Weiss.
*** 232,241 ****
  (defmacro dcq (&rest args)
   (cons 'setqp args))
  
- #-Lucid
- (defmacro define-macro (f v)
-  `(setf (macro-function ,f) (macro-function ,v)))
- 
  #-:CCL
  (defmacro difference (&rest args)
   `(- ,@args))
--- 232,237 ----

\start
Date: Fri, 23 Mar 2007 10:45:46 +0100
From: Ralf Hemmecke
To: Bill Page
Subject: re: Guessing package,	was: Re: your program / paper
Cc: Waldek Hebisch, Gabriel Dos Reis

> wh-sandbox has implemented a radically different algebra build
> process that avoids many of the problems associated with the
> old "bootstrap" method. It has also implemented some significant
> improvements to the way the Axiom database is built. Therefore
> it is not clear to me if it would be possible to incorporate
> Martin's package in the old Silver release without first
> incorporating most (if not all) of the changes in wh-sandbox.
> Silver is essentially just the old patch-50 from the tla
> archives. You will recall the problems that we had last summer
> trying to get Martin's code built on that system.

Just a data point: recently, I installed axiom-silver p50 from svn,
and, apart from some make problems (which I reported on one of the
lists), I could build it and install/run the Guess packages
successfully.

\start
Date: 25 Mar 2007 19:50:30 -0500
From: Gabriel Dos Reis
To: list
Subject: [build-improvements] make-depsys

  Currently build-depsys calls make-depsys to load some type
information (.fn files), proclaim into ./proclaims.lisp, and
load that file.  Anyone who has looked at ./proclaims.lisp knows
that file contains only

    (in-package "BOOT")

which is of no help.  Plans are to improve on declarations and
proclamation, but for the time being I'm ditching make-depsys -- it
brings nothing to the build.

Applied to build-improvements.
Built on an i686-pc-linux-gnu.

-- Gaby

2007-03-25  Gabriel Dos Reis  Gabriel Dos Reis

	* Makefile.pamphlet (${DEPSYS}): Adjust call to build-depsys.
	* Makefile.in: Regenerate.
	* util.lisp.pamphlet (make-depsys): Remove.
	(build-depsys): Adjust.

*** src/interp/Makefile.pamphlet	(revision 19358)
--- src/interp/Makefile.pamphlet	(local)
*************** ${DEPSYS}:	${DEP} sys-pkg.lisp nocompil.
*** 1022,1028 ****
  	@ echo '(load "bookvol5.lisp")' >> makedep.lisp
  	@ echo '(load "util.lisp")' >> makedep.lisp
  	@ echo '(in-package "BOOT")' >> makedep.lisp
! 	@ echo '(build-depsys (quote ($(patsubst %, "%", ${DEP}))) "${AXIOM}" "$(builddir)")' >> makedep.lisp
  	@ echo '(unless (probe-file "postpar.$(OBJEXT)") (compile-file "postpar.clisp" :output-file "postpar.$(OBJEXT)"))' >> makedep.lisp
  	@ echo '(load "postpar")' >> makedep.lisp
  	@ echo '(unless (probe-file "parse.$(OBJEXT)") (compile-file "parse.clisp" :output-file "parse.$(OBJEXT)"))' >> makedep.lisp
--- 1022,1028 ----
  	@ echo '(load "bookvol5.lisp")' >> makedep.lisp
  	@ echo '(load "util.lisp")' >> makedep.lisp
  	@ echo '(in-package "BOOT")' >> makedep.lisp
! 	@ echo '(build-depsys (quote ($(patsubst %, "%", ${DEP}))) "${AXIOM}")' >> makedep.lisp
  	@ echo '(unless (probe-file "postpar.$(OBJEXT)") (compile-file "postpar.clisp" :output-file "postpar.$(OBJEXT)"))' >> makedep.lisp
  	@ echo '(load "postpar")' >> makedep.lisp
  	@ echo '(unless (probe-file "parse.$(OBJEXT)") (compile-file "parse.clisp" :output-file "parse.$(OBJEXT)"))' >> makedep.lisp
*** src/interp/util.lisp.pamphlet	(revision 19358)
--- src/interp/util.lisp.pamphlet	(local)
*************** the necessary functions and macros to co
*** 47,60 ****
  image but it does not have any autoload triggers or databases
  loaded.
  <<build-depsys>>=
! (defun build-depsys (load-files spad build-interp-dir)
  #+:CCL
    (setq *package* (find-package "BOOT"))
  #+:AKCL
    (in-package "BOOT")
    (push :oldboot *features*)
    (mapcar #'load load-files)
-   (make-depsys build-interp-dir)
    (initroot spad)
    #+:AKCL
    (init-memory-config :cons 1000 :fixnum 400 :symbol 1000 :package 16
--- 47,59 ----
  image but it does not have any autoload triggers or databases
  loaded.
  <<build-depsys>>=
! (defun build-depsys (load-files spad)
  #+:CCL
    (setq *package* (find-package "BOOT"))
  #+:AKCL
    (in-package "BOOT")
    (push :oldboot *features*)
    (mapcar #'load load-files)
    (initroot spad)
    #+:AKCL
    (init-memory-config :cons 1000 :fixnum 400 :symbol 1000 :package 16
*************** loaded.
*** 66,107 ****
  
  @
  
- \subsubsection{make-depsys}
- 
- When we are building a {\bf depsys} image for AKCL (now GCL) we need
- need to initialize some optimization routines. Each time a file is
- compiled in GCL we collect some function information and write it
- out to a {\bf .fn} file. If this {\bf .fn} file exists at compile
- time then GCL will perform function call optimizations. These can
- be significant in terms of performance.
- 
- We comment out the load of collectfn because it is already preloaded
- into the image. It used to read:
- \begin{verbatim}
-    ((collectfn (concatenate 'string (string lsp) "/cmpnew/collectfn")))
-    (unless (probe-file (concatenate 'string collectfn ".o"))
-      (compile-file collectfn))
-    (load collectfn)
-    (compiler::emit-fn t)
- \end{verbatim}
- <<make-depsys>>=
- (defun make-depsys (build-interp-dir)
-   ;; perform system initializations for building a starter system
-   (init-memory-config)
-   #+:AKCL
-   (let ()
-    (mapcar
-      #'load
-      (directory (concatenate 'string build-interp-dir "/*.fn")))
-    (with-open-file
-     (out (concatenate 'string build-interp-dir "/proclaims.lisp" )
-       :direction :output)
-      (compiler::make-proclaims out))
-    (load (concatenate 'string build-interp-dir "/proclaims.lisp")))
-   )
- 
- @
- 
  \subsection{Building Interpsys (build-interpsys)}
  \begin{verbatim}
  ;############################################################################
--- 65,70 ----
*************** function assumes that \\ can only appear
*** 1620,1626 ****
  <<relative-library-directory-list>>
  <<directory-list>>
  <<library-directory-list>>
- <<make-depsys>>
  <<boottocl>>
  
  (in-package "BOOT")
--- 1583,1588 ----

\start
Date: Mon, 26 Mar 2007 10:30:06 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: [Axiom-mail] limits
Cc: Ondrej Certik

Hello,

On 03/26/2007 06:31 AM, Bill Page wrote:
 > On March 25, 2007 11:54 AM Ondrej Certik wrote:
 >> I am sorry for this stupid question - but how can I
 >> calculate the limit of:
 >>
 >> (3**x+5**x)**(1/x)
 >>
 >> for x->+infinity?

[snip]

 > In Axiom you should write:
 >
 >  limit((3**x+5**x)**(1/x), x=%plusInfinity)
 >
 > But if you got "failed" as a result you probably wrote
 > %plusInfinity and it's just a typo in your email.

 >> Also, this works correctly:
 >>
 >> simplify(2**x * 2**(2*x))
 >>
 >> simplifies to 2**(3x)
 >>
 >> but this doesn't simplify at all:
 >>
 >> simplify(2**(5*x)/2**(4*x))

But I don't think that expression simplification in general is Ondrej's 
point (see subject). In fact, he has implemented the algorithm of Gruntz 
  dissertation (http://www.cs.fh-aargau.ch/~gruntz/publications2.html) 
which is in Maple and there also seems to be an implementation in MuPad 
and Mathematica. Axiom is just lacking that new algorithm. Maybe we 
should also implement it and Ondrej could help to do so. (In fact, that 
would be a good small project for Google Summer.) Any volonteers out there?

Unfortunately, I haven't found a .pdf file of Gruntz thesis, but 
shouldn't we copy it to a section on 
http://portal.axiom-developer.org/refs ?

\start
Date: Mon, 26 Mar 2007 10:58:30 +0200
From: Ralf Hemmecke
To: Ondrej Certik
Subject: Limits in Axiom

Let me copy that to axiom-dev since others might jump in...

On 03/25/2007 11:16 PM, Ondrej Certik wrote:
> The Gruntz thesis is nice, it's cleanly written and I had no problems 
> with it.

>> I had a quick look at the Maple code of gruntz.pdf. Doesn't look overly
>> complicated, but it builds on some internals of Maple. I am quite

> It only looks like that. The only thing that is needed is a (good)
> series expansion facility. Nothing more than SymPy can do.

Ah, but that means formal power series with symbolic coefficients? Or 
does one need Laurant or even Puiseux series?
And for computing the coefficients one probably need differentiation of 
the (symbolic) expression and evaluation at some point (Taylor series 
expansion). Is my understanding correct?

>> curious, how do *you* actually represent the input in python. Just 
>> strings?

> Do you mean expressions? like    x+2 ?

Yes.

> as an instance of a respective class, for example x+2 is
> Add(2,x). More info is here:

> http://code.google.com/p/sympy/wiki/HowItWorks

Aha. It seems that Python makes it easy to deal with expressions.

However, I must say that your expression approach is limited in the 
sense that it can only deal with commuting objects. Simplifying b*a+a*b 
to 2*a*b is not correct if b is the differentiation operator D on x and 
a=X is the "multiplication by x"-operator. Then you would have D*X=X*D+1.

Anyway, could you list a few more detailed requirements of the Gruntz 
algorithm? What is simple, what do you think is complicated?

\start
Date: Mon, 26 Mar 2007 12:51:01 +0200
From: Ralf Hemmecke
To: Ondrej Certik
Subject: Commutative symbols  was: Re: Limits in Axiom

>> However, I must say that your expression approach is limited in the
>> sense that it can only deal with commuting objects. Simplifying b*a+a*b
>> to 2*a*b is not correct if b is the differentiation operator D on x and
>> a=X is the "multiplication by x"-operator. Then you would have D*X=X*D+1.
> 
> Of course. Try in SymPy:
> 
> In [2]: x*y+y*x
> Out[2]: 2*y*x
> 
> In [10]: a = Symbol("a", is_commutative=False)
> 
> In [11]: b = Symbol("b", is_commutative=False)

Hmmm, I would have thought that commutativity is a property of the 
multiplication of the domain you are working in and not a property of a 
symbol.

\start
Date: Mon, 26 Mar 2007 13:04:40 +0200
From: Ralf Hemmecke
To: Ondrej Certik
Subject: Re: Limits in Axiom

On 03/26/2007 12:08 PM, Ondrej Certik wrote:
>> Ah, but that means formal power series with symbolic coefficients? Or
>> does one need Laurant or even Puiseux series?
> 
> Depending on the limit, sometimes you need to know how to make a
> series of an expression like
> 
> log(1+1/x)
> 
> around x=0+
> 
> You can try it in Maple, the trick is to treat any possible log(x)
> that arise during the expansion as constants (as they are singular
> around x=0+) and then do normal laurent series.
> 
> log(1+1/x) is trivial, but there are more complicated examples.
> 
> log(x) are later substituted for something normal.

Aha. Do you have lots of testcases like that one in SymPy?

>> And for computing the coefficients one probably need differentiation of
>> the (symbolic) expression and evaluation at some point (Taylor series
>> expansion). Is my understanding correct?

> Right, but that's easy. But you need to know how to make a meaningful
> series of almost everything. (it's enough what maple or sympy does)

OK.

[snip]

>> Anyway, could you list a few more detailed requirements of the Gruntz
>> algorithm? What is simple, what do you think is complicated?

> I think in Axiom you have pretty much everything prepared already.
> Don't worry about the series expansion, you can use your current one,
> it will work for most limits (but not the one I was trying to do in my
> email for example).

> For someone who knows Axiom well, it should take like a week of a
> work. In SymPy I was doing it I think like 3 weeks, because I had to
> implement many other things and I was spending most of the time in the
> series facility.

I think one week is just too over-optimistic. Any new implementation in 
Axiom now requires to write in a literate programming style. So one 
actually has to understand the thesis first and then put that together 
with the program into a pamphlet (which is an article like form that 
contains the program). Maybe we should ask Gruntz whether we are allowed 
to include part of his thesis in an Axiom pamphlet then.

Isn't there someone interested in this limit stuff? I think this is not 
the main thing I want to follow now.

\start
Date: 26 Mar 2007 14:08:26 +0200
From: Martin Rubey
To: Ralf Hemmecke, Ondrej Certik
Subject: re: Limits in Axiom

> > For someone who knows Axiom well, it should take like a week of a work. In
> > SymPy I was doing it I think like 3 weeks, because I had to implement many
> > other things and I was spending most of the time in the series facility.

So, if you get help from an expert Axiom programmer :-), would you be prepared
to do it? If not, what would it take to get you interested?

In fact, I'd also have some other stuff that just waits to be implemented,
maybe of interest for people doing analysis, but also for combinatorialists
like myself...

\start
Date: Mon, 26 Mar 2007 12:49:36 +0000
From: Ondrej Certik
To: Ralf Hemmecke
Subject: Re: Limits in Axiom

> Aha. Do you have lots of testcases like that one in SymPy?

I tested all the limits in Demidovich, you can find SymPy testcases here:

http://sympy.googlecode.com/svn/trunk/tests/test_demidovich.py

(it should be easy to understand it, if not, just ask me)

And some more testcases (from Gruntz) are here:

http://sympy.googlecode.com/svn/trunk/tests/test_limits.py

> I think one week is just too over-optimistic. Any new implementation in
> Axiom now requires to write in a literate programming style. So one
> actually has to understand the thesis first and then put that together
> with the program into a pamphlet (which is an article like form that
> contains the program). Maybe we should ask Gruntz whether we are allowed
> to include part of his thesis in an Axiom pamphlet then.

We chose a different approach for a development of SymPy:

http://www.extremeprogramming.org/

basically, if the tests run, the code si fine. Whenever we find the
code ugly, we just refactor it - we can do whatever we want as long as
all the tests run.

So we have tests for every functionality that we want SymPy to have.

\start
Date: Mon, 26 Mar 2007 12:36:19 +0000
From: Ondrej Certik
To: Ralf Hemmecke
Subject: Re: Commutative symbols was: Re: Limits in Axiom

> Hmmm, I would have thought that commutativity is a property of the
> multiplication of the domain you are working in and not a property of a
> symbol.

I know - originaly I had a special class NCMul, for noncommutative
multiplication. But first it duplicates some code and second - some
symbols are commutative and some are not and I want to mix that. It's
like when computing with matrices, like:

A*3*x*B,

where x is a variable and A,B matrices, then you want this to evaluate to:

3*x *A*B

and when you think about it, it's actually the symbols, that have this
property - either you can commute it out of the expression, or you
cannot.

\start
Date: Mon, 26 Mar 2007 12:08:47 +0200
From: Ondrej Certik
To: Ralf Hemmecke
Subject: Re: Limits in Axiom

> Ah, but that means formal power series with symbolic coefficients? Or
> does one need Laurant or even Puiseux series?

Depending on the limit, sometimes you need to know how to make a
series of an expression like

log(1+1/x)

around x=0+

You can try it in Maple, the trick is to treat any possible log(x)
that arise during the expansion as constants (as they are singular
around x=0+) and then do normal laurent series.

log(1+1/x) is trivial, but there are more complicated examples.

log(x) are later substituted for something normal.

> And for computing the coefficients one probably need differentiation of
> the (symbolic) expression and evaluation at some point (Taylor series
> expansion). Is my understanding correct?

Right, but that's easy. But you need to know how to make a meaningful
series of almost everything. (it's enough what maple or sympy does)


> However, I must say that your expression approach is limited in the
> sense that it can only deal with commuting objects. Simplifying b*a+a*b
> to 2*a*b is not correct if b is the differentiation operator D on x and
> a=X is the "multiplication by x"-operator. Then you would have D*X=X*D+1.

Of course. Try in SymPy:

In [2]: x*y+y*x
Out[2]: 2*y*x

In [10]: a = Symbol("a", is_commutative=False)

In [11]: b = Symbol("b", is_commutative=False)

In [12]: a*b+b*a
Out[12]: b*a+a*b

In [13]: (a+b)**2
Out[13]: (b+a)**2

In [14]: ((a+b)**2).expand()
Out[14]: b*a+a**2+a*b+b**2

In [15]: ((x+y)**2).expand()
Out[15]: x**2+y**2+2*y*x


And you can play with Pauli algebra, that I implemented in exactly this way.

> Anyway, could you list a few more detailed requirements of the Gruntz
> algorithm? What is simple, what do you think is complicated?

I think in Axiom you have pretty much everything prepared already.
Don't worry about the series expansion, you can use your current one,
it will work for most limits (but not the one I was trying to do in my
email for example).

For someone who knows Axiom well, it should take like a week of a
work. In SymPy I was doing it I think like 3 weeks, because I had to
implement many other things and I was spending most of the time in the
series facility.

\start
Date: 26 Mar 2007 07:05:20 -0500
From: Gabriel Dos Reis
To: list
Subject: [build-improvements] depsys

Hi,

  Currently we build four Lisp images in src/

    (1) bootsys: this is based directly on either the value of
          --with-lisp or autodetected GCL.
          Previously, that image included symbols from libspad.a,
          which were not needed.

    (2) depsys: this is based on either the value of --with-lisp or
          or autodetected GCL *augmented* with symbols from libspad.a
          This image is used translate old Boot to Lisp, and compile
          all Lisp files in src/interp.  In fact, the symbols from
          libspad.a are not needed at all for that job.

    (3) interpsys: this is based on either the value of --with-lisp or
          or autodetected GCL *augmented* with symbols from libspad.a
          This image is used to compiler algebra files

    (4) AXIOMsys: this is based on either the value of --with-lisp or
          or autodetected GCL *augmented* with symbols from libspad.a
          This is the final image we install for Axiom interpreter and
          compiler.  Only this image really needs the symbols from libspad.a

This patch makes us NOT include symbols from libspad.a in depsys --
they are not needed.  I tried to do that for interpsys (strictly
speaking, the symbols are not needed for compiling algebra files), but
did not succeed probably because I was tired.  But, I did a little bit
of clean up.  In particular, I've commented out the defentry
declaration for |findString| and the definition of |findStringInFile|.
The latter appears not to be used or needed at all.  This is a small
step forward, in the effort making Axiom buildable with ANSI Common Lisp
implementation. 

Bootstrapping is in progress.  I'll commit when I wake up and testing
is successful. 


-- Gaby

*** ChangeLog.build-improvements	(revision 19359)
--- ChangeLog.build-improvements	(local)
***************
*** 1,3 ****
--- 1,10 ----
+ 2007-03-26  Gabriel Dos Reis  Gabriel Dos Reis
+ 
+ 	* Makefile.pamphlet (all-boot all-lisp all-depsys all-interpsys
+ 	all-axiomsysall-algebra all-input):  Make all-gcl a prerequisite
+ 	when GCL must be included.
+ 	* Makefile.in: Regenerate.
+ 
  2007-03-25  Gabriel Dos Reis  Gabriel Dos Reis
  
  	* Makefile.pamphlet (AXIOM_SRC_TARGETS): Add all-depsys.
*** Makefile.in	(revision 19359)
--- Makefile.in	(local)
*************** all-ax: all-src
*** 32,37 ****
--- 32,42 ----
  
  all-src: stamp-rootdirs @axiom_all_prerequisites@
  
+ ifeq ($(strip $(axiom_include_gcl)),yes)
+ all-boot all-lisp all-depsys all-interpsys all-axiomsys \
+   all-algebra all-input: all-gcl
+ endif
+ 
  $(AXIOM_SRC_TARGETS):
  	cd $(build_srcdir) && \
  		$(MAKE) $(AX_FLAGS) \
*** Makefile.pamphlet	(revision 19359)
--- Makefile.pamphlet	(local)
*************** all-ax: all-src
*** 330,335 ****
--- 330,340 ----
  
  all-src: stamp-rootdirs @axiom_all_prerequisites@
  
+ ifeq ($(strip $(axiom_include_gcl)),yes)
+ all-boot all-lisp all-depsys all-interpsys all-axiomsys \
+   all-algebra all-input: all-gcl
+ endif
+ 
  $(AXIOM_SRC_TARGETS):
  	cd $(build_srcdir) && \
  		$(MAKE) $(AX_FLAGS) \
*** src/ChangeLog.build-improvements	(revision 19359)
--- src/ChangeLog.build-improvements	(local)
***************
*** 1,3 ****
--- 1,11 ----
+ 2007-03-26  Gabriel Dos Reis  Gabriel Dos Reis
+ 
+ 	* Makefile.pamphlet (all-boot): Don't make all-lisp a prerequisite.
+ 	(all-depsys): Require only all-boot.
+ 	(all-interpsys): Additionally require all-lisp.
+ 	(all-lisp): Additionally require all-boot.
+ 	* Makefile.in: Regenerate.
+ 
  2007-03-25  Gabriel Dos Reis  Gabriel Dos Reis
  
  	* Makefile.pamphlet (all-depsys): New target. 
*** src/Makefile.in	(revision 19359)
--- src/Makefile.in	(local)
*************** all-book:
*** 38,57 ****
  all-lib:
  	$(mkinstalldirs) $(OUT)
  	@cd lib && ${MAKE} $(AX_FLAGS)
! all-lisp: all-lib
  	$(mkinstalldirs) $(axiom_build_bindir)
  	cd lisp && $(MAKE) $(AX_FLAGS) all-lisp
- ifeq ($(strip $(axiom_include_gcl)),yes)
- all-boot: all-lisp
- else
  all-boot:
- endif
  	$(mkinstalldirs) $(axiom_build_bindir)
  	@cd boot && ${MAKE} $(AX_FLAGS)
! all-depsys: all-lisp all-boot
  	cd interp && $(MAKE) $(AX_FLAGS) all-depsys
  
! all-interpsys: all-depsys
  	cd interp && ${MAKE} $(AX_FLAGS) all-interpsys
  
  all-axiomsys: all-asq
--- 38,53 ----
  all-lib:
  	$(mkinstalldirs) $(OUT)
  	@cd lib && ${MAKE} $(AX_FLAGS)
! all-lisp: all-lib all-boot
  	$(mkinstalldirs) $(axiom_build_bindir)
  	cd lisp && $(MAKE) $(AX_FLAGS) all-lisp
  all-boot:
  	$(mkinstalldirs) $(axiom_build_bindir)
  	@cd boot && ${MAKE} $(AX_FLAGS)
! all-depsys: all-boot
  	cd interp && $(MAKE) $(AX_FLAGS) all-depsys
  
! all-interpsys: all-depsys all-lisp
  	cd interp && ${MAKE} $(AX_FLAGS) all-interpsys
  
  all-axiomsys: all-asq
*** src/Makefile.pamphlet	(revision 19359)
--- src/Makefile.pamphlet	(local)
*************** the whole process to start we need certa
*** 128,138 ****
  common lisp form. This directory contains those files.
  
  <<bootdir>>=
- ifeq ($(strip $(axiom_include_gcl)),yes)
- all-boot: all-lisp
- else
  all-boot:
- endif
  	$(mkinstalldirs) $(axiom_build_bindir)
  	@cd boot && ${MAKE} $(AX_FLAGS)
  @
--- 128,134 ----
*************** and \Tool{interpsys}. Since these two im
*** 144,153 ****
  files they are built in the interp subdirectory using the
  same Makefile.
  <<interpdir>>=
! all-depsys: all-lisp all-boot
  	cd interp && $(MAKE) $(AX_FLAGS) all-depsys
  
! all-interpsys: all-depsys
  	cd interp && ${MAKE} $(AX_FLAGS) all-interpsys
  
  all-axiomsys: all-asq
--- 140,149 ----
  files they are built in the interp subdirectory using the
  same Makefile.
  <<interpdir>>=
! all-depsys: all-boot
  	cd interp && $(MAKE) $(AX_FLAGS) all-depsys
  
! all-interpsys: all-depsys all-lisp
  	cd interp && ${MAKE} $(AX_FLAGS) all-interpsys
  
  all-axiomsys: all-asq
*************** Aldor compiler.
*** 171,181 ****
  
  \subsection{The \File{lisp/} directory}
  
! We need a fresh Lisp image to use for building the Boot translator,
! the \Tool{Axiom} interpreter and compiler.
  
  <<lispdir>>=
! all-lisp: all-lib
  	$(mkinstalldirs) $(axiom_build_bindir)
  	cd lisp && $(MAKE) $(AX_FLAGS) all-lisp
  @
--- 167,178 ----
  
  \subsection{The \File{lisp/} directory}
  
! We need a local Lisp image, augmented with specific routines, to use for 
! building the \Tool{Axiom} interpreter and compiler.  That Lisp image
! comes from the local Lisp image used to initiate \Tool{bootsys}.
  
  <<lispdir>>=
! all-lisp: all-lib all-boot
  	$(mkinstalldirs) $(axiom_build_bindir)
  	cd lisp && $(MAKE) $(AX_FLAGS) all-lisp
  @
*** src/algebra/Makefile.in	(revision 19359)
--- src/algebra/Makefile.in	(local)
*************** all: all-ax
*** 836,842 ****
  all-ax all-algebra: stamp
  	@ echo finished $(builddir)
  
! stamp: $(OUTSRC) ${SPADFILES} bootstrap-stamp ${TESTS}
  	-rm -f stamp
  	$(STAMP) stamp
  
--- 836,842 ----
  all-ax all-algebra: stamp
  	@ echo finished $(builddir)
  
! stamp: ${SPADFILES} bootstrap-stamp ${TESTS}
  	-rm -f stamp
  	$(STAMP) stamp
  
*************** user-stamp: 23-stamp $(axiom_algebra_lay
*** 1136,1142 ****
  
  # bootstrap-post: bootstrap-pre $(axiom_algebra_bootstrap_objects)
  
! bootstrap-stamp: user-stamp $(axiom_algebra_bootstrap_objects)
  	@ rm -f bootstrap-stamp
  	@ $(STAMP) bootstrap-stamp
  	@ echo ==================================
--- 1136,1142 ----
  
  # bootstrap-post: bootstrap-pre $(axiom_algebra_bootstrap_objects)
  
! bootstrap-stamp: $(axiom_algebra_bootstrap_objects)
  	@ rm -f bootstrap-stamp
  	@ $(STAMP) bootstrap-stamp
  	@ echo ==================================
*** src/algebra/Makefile.pamphlet	(revision 19359)
--- src/algebra/Makefile.pamphlet	(local)
*************** user-stamp: 23-stamp $(axiom_algebra_lay
*** 2219,2225 ****
  
  # bootstrap-post: bootstrap-pre $(axiom_algebra_bootstrap_objects)
  
! bootstrap-stamp: user-stamp $(axiom_algebra_bootstrap_objects)
  	@ rm -f bootstrap-stamp
  	@ $(STAMP) bootstrap-stamp
  	@ echo ==================================
--- 2219,2225 ----
  
  # bootstrap-post: bootstrap-pre $(axiom_algebra_bootstrap_objects)
  
! bootstrap-stamp: $(axiom_algebra_bootstrap_objects)
  	@ rm -f bootstrap-stamp
  	@ $(STAMP) bootstrap-stamp
  	@ echo ==================================
*************** all: all-ax
*** 2271,2277 ****
  all-ax all-algebra: stamp
  	@ echo finished $(builddir)
  
! stamp: $(OUTSRC) ${SPADFILES} bootstrap-stamp ${TESTS}
  	-rm -f stamp
  	$(STAMP) stamp
  
--- 2271,2277 ----
  all-ax all-algebra: stamp
  	@ echo finished $(builddir)
  
! stamp: ${SPADFILES} bootstrap-stamp ${TESTS}
  	-rm -f stamp
  	$(STAMP) stamp
  
*** src/interp/ChangeLog.build-improvements	(revision 19359)
--- src/interp/ChangeLog.build-improvements	(local)
***************
*** 1,3 ****
--- 1,24 ----
+ 2007-03-26  Gabriel Dos Reis  Gabriel Dos Reis
+ 
+ 	* util.lisp.pamphlet (boottocl): Remove prefix.  Do pretty print
+ 	translations.
+ 	* sys-pkg.lisp.pamphlet (BOOTTRAN): Don't define here.
+ 	* interp-proclaims.lisp (BOOT::|findStringInFile|): Comment out
+ 	proclamation. 
+ 	* cfuns.lisp.pamphlet (|findString|): Comment out external linkage
+ 	declaration. 
+ 	(|findStringInFile|): Comment out definition.	
+ 	* Makefile.pamphlet:  Use implicit rules to compiler .clisp files
+ 	to native object codes.  Remove redundant special cased rules.
+ 	(YEARWEEK): Qualify symbols names.
+ 	(<<save depsys image>>): Use local Lisp image.
+ 	(makeint.lisp): Remove in-package declaration.  Qualify symbol
+ 	names. Turn on stratified garbage collection.
+ 	(${SAVESYS}): Use axiom_build_document to build interpsys.
+ 	(${AXIOMSYS}): Garbage collection is already turned on in
+ 	makeint.lisp. 
+ 	* Makefile.in: Regenerate.
+ 
  2007-03-25  Gabriel Dos Reis  Gabriel Dos Reis
  
  	* Makefile.pamphlet (${DEPSYS}): Adjust call to build-depsys.
*** src/interp/Makefile.in	(revision 19359)
--- src/interp/Makefile.in	(local)
*************** ASAUTO= ${AUTO}/ax.$(OBJEXT)
*** 207,215 ****
  
  autoload_objects += $(ASAUTO)
  TIMESTAMP=$(axiom_targetdir)/timestamp
! YEARWEEK=(progn (setq timestamp "${TIMESTAMP}") \
                  (setq boot::*build-version* "$(PACKAGE_STRING)") \
!                 (yearweek))
  
  
  .PRECIOUS:	${DEPSYS}
--- 207,215 ----
  
  autoload_objects += $(ASAUTO)
  TIMESTAMP=$(axiom_targetdir)/timestamp
! YEARWEEK=(progn (setq boot::timestamp "${TIMESTAMP}") \
                  (setq boot::*build-version* "$(PACKAGE_STRING)") \
!                 (boot::yearweek))
  
  
  .PRECIOUS:	${DEPSYS}
*************** makeint.lisp:	${DEPSYS} ${OBJS} bookvol5
*** 299,322 ****
  	$(INSTALL_DATA) $(axiom_src_docdir)/msgs/s2-us.msgs \
  		 $(axiom_target_datadir)/msgs
  	@ echo '${PROCLAIMS}' > makeint.lisp
  	@ echo '(load "nocompil.lisp")' >> makeint.lisp
  	@ echo '(load "bookvol5")' >> makeint.lisp
  	@ echo '(load "util")' >> makeint.lisp
  	@ echo '(in-package "BOOT")' >> makeint.lisp
  	@ touch ${TIMESTAMP}
  	@ echo '${YEARWEEK}' >> makeint.lisp
! 	@ echo '(build-interpsys (append (quote ($(patsubst %, "%", ${OBJS}))) (quote ($(patsubst %, "%", ${ASCOMP}))) (quote ($(patsubst %, "%", ${INOBJS})))) (quote ($(patsubst %, "%", ${OPOBJS}))) (quote ($(patsubst %, "%", ${OCOBJS}))) (quote ($(patsubst %, "%", ${BROBJS}))) (quote ($(patsubst %, "%", ${TRANOBJS}))) (quote ($(patsubst %, "%", ${NAGBROBJS}))) (quote ($(patsubst %, "%", ${ASAUTO})))  "${AXIOM}")' >> makeint.lisp
! 	@ echo '(in-package "SCRATCHPAD-COMPILER")' >> makeint.lisp
  	@ echo '(boot::set-restart-hook)' >> makeint.lisp
  	@ echo '(in-package "BOOT")' >> makeint.lisp
  	@ echo '(load "../algebra/warm.data")' >> makeint.lisp
! 	@ echo '(|clearClams|)' >> makeint.lisp
  	@ echo '(load "obey")' >> makeint.lisp
  	@ echo '#+:akcl (setq compiler::*suppress-compiler-notes* t)' >> makeint.lisp
  	@ echo '#+:akcl (si::gbc-time 0)' >> makeint.lisp
  
  ${SAVESYS}: makeint.lisp
! 	echo '(progn (gbc t) (load "makeint.lisp") (gbc t) (user::spad-save "$@"))' | AXIOM="$(AXIOM)" DAASE="$(axiom_src_datadir)" ${LISPSYS}
  	@ echo 6 ${SAVESYS} created
  	$(mkinstalldirs) $(axiom_target_bindir)
  depsys_lisp_sources += parsing.lisp metalex.lisp bootlex.lisp \
--- 299,325 ----
  	$(INSTALL_DATA) $(axiom_src_docdir)/msgs/s2-us.msgs \
  		 $(axiom_target_datadir)/msgs
  	@ echo '${PROCLAIMS}' > makeint.lisp
+ 	@ echo '(gbc t)' >> makeint.lisp
  	@ echo '(load "nocompil.lisp")' >> makeint.lisp
  	@ echo '(load "bookvol5")' >> makeint.lisp
  	@ echo '(load "util")' >> makeint.lisp
  	@ echo '(in-package "BOOT")' >> makeint.lisp
  	@ touch ${TIMESTAMP}
  	@ echo '${YEARWEEK}' >> makeint.lisp
! 	@ echo '(boot::build-interpsys (append (quote ($(patsubst %, "%", ${OBJS}))) (quote ($(patsubst %, "%", ${ASCOMP}))) (quote ($(patsubst %, "%", ${INOBJS})))) (quote ($(patsubst %, "%", ${OPOBJS}))) (quote ($(patsubst %, "%", ${OCOBJS}))) (quote ($(patsubst %, "%", ${BROBJS}))) (quote ($(patsubst %, "%", ${TRANOBJS}))) (quote ($(patsubst %, "%", ${NAGBROBJS}))) (quote ($(patsubst %, "%", ${ASAUTO})))  "${AXIOM}")' >> makeint.lisp
  	@ echo '(boot::set-restart-hook)' >> makeint.lisp
  	@ echo '(in-package "BOOT")' >> makeint.lisp
  	@ echo '(load "../algebra/warm.data")' >> makeint.lisp
! 	@ echo '(boot::|clearClams|)' >> makeint.lisp
  	@ echo '(load "obey")' >> makeint.lisp
  	@ echo '#+:akcl (setq compiler::*suppress-compiler-notes* t)' >> makeint.lisp
  	@ echo '#+:akcl (si::gbc-time 0)' >> makeint.lisp
+ 	@ echo '(gbc t)' >> makeint.lisp
  
  ${SAVESYS}: makeint.lisp
! 	AXIOM="$(AXIOM)" DAASE="$(axiom_src_datadir)" \
! 		$(axiom_build_document) --tag=lisp --mode=save-image \
! 		--use=$(LOADSYS) --output=$@ makeint.lisp
  	@ echo 6 ${SAVESYS} created
  	$(mkinstalldirs) $(axiom_target_bindir)
  depsys_lisp_sources += parsing.lisp metalex.lisp bootlex.lisp \
*************** ${DEPSYS}:	${DEP} sys-pkg.lisp nocompil.
*** 389,405 ****
  	@ echo '(load "c-util")' >> makedep.lisp
  	@ echo '(unless (probe-file "g-util.$(OBJEXT)") (compile-file "g-util.${LISP}" :output-file "g-util.$(OBJEXT)"))' >> makedep.lisp
  	@ echo '(load "g-util")' >> makedep.lisp
! 	@ echo '(progn (load "makedep.lisp") (spad-save "$@"))' \
!                | AXIOM="$(AXIOM)" $(LISPSYS)
  	@ echo 4 ${DEPSYS} created
  .PHONY: all-axiomsys
  
  all-axiomsys: ${AXIOMSYS}
  
  ${AXIOMSYS}: makeint.lisp
! 	echo '(progn (gbc t) (load "makeint.lisp") (gbc t)' \
! 	   '(user::spad-save "$@"))' | \
! 		AXIOM="$(AXIOM)" DAASE="$(axiom_targetdir)" ${LISPSYS}
  	@ echo 6a ${AXIOMSYS} created
  ${DEBUGSYS}: debugsys.lisp
  	@ echo 7 building debugsys
--- 392,407 ----
  	@ echo '(load "c-util")' >> makedep.lisp
  	@ echo '(unless (probe-file "g-util.$(OBJEXT)") (compile-file "g-util.${LISP}" :output-file "g-util.$(OBJEXT)"))' >> makedep.lisp
  	@ echo '(load "g-util")' >> makedep.lisp
! 	$(axiom_build_document) --tag=lisp --mode=save-image --output=$@ \
! 		--use=../boot/local-lisp makedep.lisp
  	@ echo 4 ${DEPSYS} created
  .PHONY: all-axiomsys
  
  all-axiomsys: ${AXIOMSYS}
  
  ${AXIOMSYS}: makeint.lisp
! 	echo '(progn (load "makeint.lisp") (user::spad-save "$@"))' | \
! 		AXIOM="$(AXIOM)" DAASE="$(axiom_targetdir)" $(LOADSYS)
  	@ echo 6a ${AXIOMSYS} created
  ${DEBUGSYS}: debugsys.lisp
  	@ echo 7 building debugsys
*************** ${AUTO}/apply.$(OBJEXT): apply.$(OBJEXT)
*** 428,441 ****
  	@ echo 9 making ${AUTO}/apply.$(OBJEXT) from apply.$(OBJEXT)
  	@ cp apply.$(OBJEXT) ${AUTO}
  
- apply.$(OBJEXT): apply.clisp 
- 	@ echo 10 making apply.$(OBJEXT) from apply.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "apply.clisp" :output-file "apply.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "apply.clisp" :output-file "apply.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  apply.clisp: apply.boot
  	@ echo 11 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 430,435 ----
*************** apply.clisp: apply.boot
*** 445,458 ****
             fi ;
  
  
- as.$(OBJEXT): as.clisp 
- 	@ echo 416 making as.$(OBJEXT) from as.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "as.clisp" :output-file "as.$(OBJEXT)"))' |  ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "as.clisp" :output-file "as.$(OBJEXT)"))' |  ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  as.clisp: as.boot
  	@ echo 417 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 439,444 ----
*************** ${AUTO}/ax.$(OBJEXT): ax.$(OBJEXT)
*** 466,479 ****
  	@ echo 461 making ${AUTO}/ax.$(OBJEXT) from ax.$(OBJEXT)
  	@ cp ax.$(OBJEXT) ${AUTO}
  
- ax.$(OBJEXT): ax.clisp 
- 	@ echo 462 making ax.$(OBJEXT) from ax.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "ax.clisp" :output-file "ax.$(OBJEXT)"))' |  ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "ax.clisp" :output-file "ax.$(OBJEXT)"))' |  ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  ax.clisp: ax.boot
  	@ echo 463 making $@ $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 452,457 ----
*************** ${AUTO}/bc-matrix.$(OBJEXT): bc-matrix.$
*** 487,500 ****
  	@ echo 422 making ${AUTO}/bc-matrix.$(OBJEXT) from bc-matrix.$(OBJEXT)
  	@ cp bc-matrix.$(OBJEXT) ${AUTO}
  
- bc-matrix.$(OBJEXT): bc-matrix.clisp 
- 	@ echo 423 making bc-matrix.$(OBJEXT) from bc-matrix.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "bc-matrix.clisp" :output-file "bc-matrix.$(OBJEXT)"))' |  ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "bc-matrix.clisp" :output-file "bc-matrix.$(OBJEXT)"))' |  ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  bc-matrix.clisp: bc-matrix.boot
  	@ echo 424 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 465,470 ----
*************** ${AUTO}/bc-misc.$(OBJEXT): bc-misc.$(OBJ
*** 508,521 ****
  	@ echo 426 making ${AUTO}/bc-misc.$(OBJEXT) from bc-misc.$(OBJEXT)
  	@ cp bc-misc.$(OBJEXT) ${AUTO}
  
- bc-misc.$(OBJEXT): bc-misc.clisp 
- 	@ echo 427 making bc-misc.$(OBJEXT) from bc-misc.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "bc-misc.clisp" :output-file "bc-misc.$(OBJEXT)"))' |  ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "bc-misc.clisp" :output-file "bc-misc.$(OBJEXT)"))' |  ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  bc-misc.clisp: bc-misc.boot
  	@ echo 428 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 478,483 ----
*************** ${AUTO}/bc-solve.$(OBJEXT): bc-solve.$(O
*** 529,542 ****
  	@ echo 430 making ${AUTO}/bc-solve.$(OBJEXT) from bc-solve.$(OBJEXT)
  	@ cp bc-solve.$(OBJEXT) ${AUTO}
  
- bc-solve.$(OBJEXT): bc-solve.clisp 
- 	@ echo 431 making bc-solve.$(OBJEXT) from bc-solve.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "bc-solve.clisp" :output-file "bc-solve.$(OBJEXT)"))' |  ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "bc-solve.clisp" :output-file "bc-solve.$(OBJEXT)"))' |  ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  bc-solve.clisp: bc-solve.boot
  	@ echo 432 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 491,496 ----
*************** ${AUTO}/bc-util.$(OBJEXT): bc-util.$(OBJ
*** 550,563 ****
  	@ echo 434 making ${AUTO}/bc-util.$(OBJEXT) from bc-util.$(OBJEXT)
  	@ cp bc-util.$(OBJEXT) ${AUTO}
  
- bc-util.$(OBJEXT): bc-util.clisp 
- 	@ echo 435 making bc-util.$(OBJEXT) from bc-util.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "bc-util.clisp" :output-file "bc-util.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "bc-util.clisp" :output-file "bc-util.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  bc-util.clisp: bc-util.boot
  	@ echo 436 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 504,509 ----
*************** ${AUTO}/br-con.$(OBJEXT): br-con.$(OBJEX
*** 576,589 ****
  	@ echo 465 making ${AUTO}/br-con.$(OBJEXT) from br-con.$(OBJEXT)
  	@ cp br-con.$(OBJEXT) ${AUTO}
  
- br-con.$(OBJEXT): br-con.clisp 
- 	@ echo 466 making br-con.$(OBJEXT) from br-con.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "br-con.clisp" :output-file "br-con.$(OBJEXT)"))' |  ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "br-con.clisp" :output-file "br-con.$(OBJEXT)"))' |  ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  br-con.clisp: br-con.boot
  	@ echo 467 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 522,527 ----
*************** ${AUTO}/br-data.$(OBJEXT): br-data.$(OBJ
*** 597,610 ****
  	@ echo 481 making ${AUTO}/br-data.$(OBJEXT) from br-data.$(OBJEXT)
  	@ cp br-data.$(OBJEXT) ${AUTO}
  
- br-data.$(OBJEXT): br-data.clisp 
- 	@ echo 482 making br-data.$(OBJEXT) from br-data.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "br-data.clisp" :output-file "br-data.$(OBJEXT)"))' |  ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "br-data.clisp" :output-file "br-data.$(OBJEXT)"))' |  ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  br-data.clisp: br-data.boot
  	@ echo 483 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 535,540 ----
*************** ${AUTO}/br-op1.$(OBJEXT): br-op1.$(OBJEX
*** 618,631 ****
  	@ echo 473 making ${AUTO}/br-op1.$(OBJEXT) from br-op1.$(OBJEXT)
  	@ cp br-op1.$(OBJEXT) ${AUTO}
  
- br-op1.$(OBJEXT): br-op1.clisp 
- 	@ echo 474 making br-op1.$(OBJEXT) from br-op1.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "br-op1.clisp" :output-file "br-op1.$(OBJEXT)"))' |  ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "br-op1.clisp" :output-file "br-op1.$(OBJEXT)"))' |  ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  br-op1.clisp: br-op1.boot
  	@ echo 475 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 548,553 ----
*************** ${AUTO}/br-op2.$(OBJEXT): br-op2.$(OBJEX
*** 639,652 ****
  	@ echo 477 making ${AUTO}/br-op2.$(OBJEXT) from br-op2.$(OBJEXT)
  	@ cp br-op2.$(OBJEXT) ${AUTO}
  
- br-op2.$(OBJEXT): br-op2.clisp 
- 	@ echo 478 making br-op2.$(OBJEXT) from br-op2.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "br-op2.clisp" :output-file "br-op2.$(OBJEXT)"))' |  ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "br-op2.clisp" :output-file "br-op2.$(OBJEXT)"))' |  ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  br-op2.clisp: br-op2.boot
  	@ echo 479 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 561,566 ----
*************** ${AUTO}/br-prof.$(OBJEXT): br-prof.$(OBJ
*** 660,673 ****
  	@ echo 497 making ${AUTO}/br-prof.$(OBJEXT) from br-prof.$(OBJEXT)
  	@ cp br-prof.$(OBJEXT) ${AUTO}
  
- br-prof.$(OBJEXT): br-prof.clisp 
- 	@ echo 498 making br-prof.$(OBJEXT) from br-prof.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "br-prof.clisp" :output-file "br-prof.$(OBJEXT)"))' |  ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "br-prof.clisp" :output-file "br-prof.$(OBJEXT)"))' |  ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  br-prof.clisp: br-prof.boot
  	@ echo 499 making $@ from $<
  	@ ($(axiom_build_document) --tangle --output=br-prof.boot $< ;\
--- 574,579 ----
*************** ${AUTO}/br-saturn.$(OBJEXT): br-saturn.$
*** 683,696 ****
  	@ echo 489 making ${AUTO}/br-saturn.$(OBJEXT) from br-saturn.$(OBJEXT)
  	@ cp br-saturn.$(OBJEXT) ${AUTO}
  
- br-saturn.$(OBJEXT): br-saturn.clisp 
- 	@ echo 490 making br-saturn.$(OBJEXT) from br-saturn.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "br-saturn.clisp" :output-file "br-saturn.$(OBJEXT)"))' |  ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "br-saturn.clisp" :output-file "br-saturn.$(OBJEXT)"))' |  ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  br-saturn.clisp: br-saturn.boot
  	@ echo 491 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 589,594 ----
*************** ${AUTO}/br-search.$(OBJEXT): br-search.$
*** 704,717 ****
  	@ echo 469 making ${AUTO}/br-search.$(OBJEXT) from br-search.$(OBJEXT)
  	@ cp br-search.$(OBJEXT) ${AUTO}
  
- br-search.$(OBJEXT): br-search.clisp 
- 	@ echo 470 making br-search.$(OBJEXT) from br-search.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "br-search.clisp" :output-file "br-search.$(OBJEXT)"))' |  ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "br-search.clisp" :output-file "br-search.$(OBJEXT)"))' |  ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  br-search.clisp: br-search.boot
  	@ echo 471 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 602,607 ----
*************** ${AUTO}/br-util.$(OBJEXT): br-util.$(OBJ
*** 725,738 ****
  	@ echo 485 making ${AUTO}/br-util.$(OBJEXT) from br-util.$(OBJEXT)
  	@ cp br-util.$(OBJEXT) ${AUTO}
  
- br-util.$(OBJEXT): br-util.clisp 
- 	@ echo 486 making br-util.$(OBJEXT) from br-util.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "br-util.clisp" :output-file "br-util.$(OBJEXT)"))' |  ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "br-util.clisp" :output-file "br-util.$(OBJEXT)"))' |  ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  br-util.clisp: br-util.boot
  	@ echo 487 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 615,620 ----
*************** br-util.clisp: br-util.boot
*** 742,755 ****
  	  fi 
  
  
- buildom.$(OBJEXT): buildom.clisp 
- 	@ echo 142 making buildom.$(OBJEXT) from buildom.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "buildom.clisp" :output-file "buildom.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "buildom.clisp" :output-file "buildom.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  buildom.clisp: buildom.boot
  	@ echo 143 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 624,629 ----
*************** ${AUTO}/category.$(OBJEXT): category.$(O
*** 763,776 ****
  	@ echo 210 making ${AUTO}/ category.$(OBJEXT) from category.$(OBJEXT)
  	@ cp category.$(OBJEXT) ${AUTO}
  
- category.$(OBJEXT): category.clisp 
- 	@ echo 211 making category.$(OBJEXT) from category.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "category.clisp" :output-file "category.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "category.clisp" :output-file "category.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  category.clisp: category.boot
  	@ echo 212 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 637,642 ----
*************** category.clisp: category.boot
*** 780,793 ****
  	  fi 
  
  
- cattable.$(OBJEXT): cattable.clisp 
- 	@ echo 214 making cattable.$(OBJEXT) from cattable.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "cattable.clisp" :output-file "cattable.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "cattable.clisp" :output-file "cattable.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  cattable.clisp: cattable.boot
  	@ echo 215 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 646,651 ----
*************** ${AUTO}/c-doc.$(OBJEXT): c-doc.$(OBJEXT)
*** 801,814 ****
  	@ echo 217 making ${AUTO}/c-doc.$(OBJEXT) from c-doc.$(OBJEXT)
  	@ cp c-doc.$(OBJEXT) ${AUTO}
  
- c-doc.$(OBJEXT): c-doc.clisp 
- 	@ echo 218 making c-doc.$(OBJEXT) from c-doc.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "c-doc.clisp" :output-file "c-doc.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "c-doc.clisp" :output-file "c-doc.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  c-doc.clisp: c-doc.boot
  	@ echo 219 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 659,664 ----
*************** clam.${LISP}: $(srcdir)/clam.boot.pamphl
*** 822,835 ****
  	@ echo 221 making clam.${LISP} from $(srcdir)/clam.boot.pamphlet
  	@ rm -f clam.$(OBJEXT)
  	$(axiom_build_document) --tangle=clam.clisp --output=$@ $<
- clam.$(OBJEXT): clam.clisp 
- 	@ echo 222 making clam.$(OBJEXT) from clam.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "clam.clisp" :output-file "clam.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "clam.clisp" :output-file "clam.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  clam.clisp: clam.boot
  	@ echo 223 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 672,677 ----
*************** clam.clisp: clam.boot
*** 839,852 ****
  	  fi 
  
  
- clammed.$(OBJEXT): clammed.clisp 
- 	@ echo 225 making clammed.$(OBJEXT) from clammed.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "clammed.clisp" :output-file "clammed.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "clammed.clisp" :output-file "clammed.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  clammed.clisp: clammed.boot
  	@ echo 226 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 681,686 ----
*************** clammed.clisp: clammed.boot
*** 856,869 ****
  	  fi 
  
  
- compat.$(OBJEXT): compat.clisp 
- 	@ echo 228 making compat.$(OBJEXT) from compat.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "compat.clisp" :output-file "compat.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "compat.clisp" :output-file "compat.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  compat.clisp: compat.boot
  	@ echo 229 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 690,695 ----
*************** ${AUTO}/compiler.$(OBJEXT): compiler.$(O
*** 877,890 ****
  	@ echo 231 making ${AUTO}/compiler.$(OBJEXT) from compiler.$(OBJEXT)
  	@ cp compiler.$(OBJEXT) ${AUTO}
  
- compiler.$(OBJEXT): compiler.clisp 
- 	@ echo 232 making compiler.$(OBJEXT) from compiler.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "compiler.clisp" :output-file "compiler.$(OBJEXT)"))' | ${DEPSYS} ; \
-           else \
- 	   echo '(progn  (compile-file "compiler.clisp" :output-file "compiler.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  compiler.clisp: compiler.boot
  	@ echo 233 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 703,708 ----
*************** compiler.clisp: compiler.boot
*** 895,906 ****
  
  
  compress.$(OBJEXT): compress.clisp 
! 	@ echo 239 making compress.$(OBJEXT) from compress.clisp
! 	@ if [ -z "${NOISE}" ] ; then \
! 	   echo '(progn  (compile-file "compress.clisp" :output-file "compress.$(OBJEXT)"))' | ${DEPSYS} ; \
! 	  else \
! 	   echo '(progn  (compile-file "compress.clisp" :output-file "compress.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
! 	  fi
  
  compress.clisp: compress.boot
  	@ echo 240 making $@ from $<
--- 713,719 ----
  
  
  compress.$(OBJEXT): compress.clisp 
! 	$(COMPILE_LISP)
  
  compress.clisp: compress.boot
  	@ echo 240 making $@ from $<
*************** c-util.${LISP}: $(srcdir)/c-util.boot.pa
*** 920,933 ****
  	@ rm -f c-util.$(OBJEXT)
  	$(axiom_build_document) --tangle=c-util.clisp --output=$@ $<
  
- c-util.$(OBJEXT): c-util.clisp 
- 	@ echo 147 making c-util.$(OBJEXT) from c-util.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "c-util.clisp" :output-file "c-util.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "c-util.clisp" :output-file "c-util.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  c-util.clisp: c-util.boot
  	@ echo 148 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 733,738 ----
*************** c-util.clisp: c-util.boot
*** 937,950 ****
  	  fi
  
  
- database.$(OBJEXT): database.clisp 
- 	@ echo 242 making database.$(OBJEXT) from database.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "database.clisp" :output-file "database.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "database.clisp" :output-file "database.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  database.clisp: database.boot
  	@ echo 243 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 742,747 ----
*************** ${AUTO}/define.$(OBJEXT): define.$(OBJEX
*** 966,979 ****
  	@ echo 245 making ${AUTO}/define.$(OBJEXT) from define.$(OBJEXT)
  	@ cp define.$(OBJEXT) ${AUTO}
  
- define.$(OBJEXT): define.clisp 
- 	@ echo 246 making define.$(OBJEXT) from define.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "define.clisp" :output-file "define.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "define.clisp" :output-file "define.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  define.clisp: define.boot
  	@ echo 247 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 763,768 ----
*************** ${AUTO}/fnewmeta.$(OBJEXT): fnewmeta.$(O
*** 988,1001 ****
  	@ cp fnewmeta.$(OBJEXT) ${AUTO}
  
  
- format.$(OBJEXT): format.clisp 
- 	@ echo 249 making format.$(OBJEXT) from format.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "format.clisp" :output-file "format.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "format.clisp" :output-file "format.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  format.clisp: format.boot
  	@ echo 250 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 777,782 ----
*************** format.clisp: format.boot
*** 1005,1018 ****
  	  fi
  
  
- fortcall.$(OBJEXT): fortcall.clisp 
- 	@ echo 54 making fortcall.$(OBJEXT) from fortcall.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "fortcall.clisp" :output-file "fortcall.$(OBJEXT)"))' |  ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "fortcall.clisp" :output-file "fortcall.$(OBJEXT)"))' |  ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  fortcall.clisp: fortcall.boot
  	@ echo 55 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 786,791 ----
*************** ${AUTO}/functor.$(OBJEXT): functor.$(OBJ
*** 1026,1039 ****
  	@ echo 252 making ${AUTO}/functor.$(OBJEXT) from functor.$(OBJEXT)
  	@ cp functor.$(OBJEXT) ${AUTO}
  
- functor.$(OBJEXT): functor.clisp 
- 	@ echo 253 making functor.$(OBJEXT) from functor.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "functor.clisp" :output-file "functor.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "functor.clisp" :output-file "functor.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  functor.clisp: functor.boot
  	@ echo 254 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 799,804 ----
*************** g-boot.${LISP}: $(srcdir)/g-boot.boot.pa
*** 1047,1060 ****
  	@ echo 256 making g-boot.${LISP} from $(srcdir)/g-boot.boot.pamphlet
  	@ rm -f g-boot.$(OBJEXT)
  	$(axiom_build_document) --tangle=g-boot.clisp --output=$@ $<
- g-boot.$(OBJEXT): g-boot.clisp 
- 	@ echo 257 making g-boot.$(OBJEXT) from g-boot.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "g-boot.clisp" :output-file "g-boot.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "g-boot.clisp" :output-file "g-boot.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  g-boot.clisp: g-boot.boot
  	@ echo 258 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 812,817 ----
*************** g-boot.clisp: g-boot.boot
*** 1064,1077 ****
  	  fi
  
  
- g-cndata.$(OBJEXT): g-cndata.clisp 
- 	@ echo 260 making g-cndata.$(OBJEXT) from g-cndata.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "g-cndata.clisp" :output-file "g-cndata.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "g-cndata.clisp" :output-file "g-cndata.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  g-cndata.clisp: g-cndata.boot
  	@ echo 261 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 821,826 ----
*************** g-cndata.clisp: g-cndata.boot
*** 1081,1094 ****
  	  fi
  
  
- g-error.$(OBJEXT): g-error.clisp 
- 	@ echo 263 making g-error.$(OBJEXT) from g-error.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "g-error.clisp" :output-file "g-error.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "g-error.clisp" :output-file "g-error.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  g-error.clisp: g-error.boot
  	@ echo 264 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 830,835 ----
*************** g-error.clisp: g-error.boot
*** 1098,1111 ****
  	  fi
  
  
- g-opt.$(OBJEXT): g-opt.clisp 
- 	@ echo 266 making g-opt.$(OBJEXT) from g-opt.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "g-opt.clisp" :output-file "g-opt.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "g-opt.clisp" :output-file "g-opt.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  g-opt.clisp: g-opt.boot
  	@ echo 267 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 839,844 ----
*************** g-opt.clisp: g-opt.boot
*** 1115,1128 ****
  	  fi
  
  
- g-timer.$(OBJEXT): g-timer.clisp 
- 	@ echo 269 making g-timer.$(OBJEXT) from g-timer.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "g-timer.clisp" :output-file "g-timer.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "g-timer.clisp" :output-file "g-timer.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  g-timer.clisp: g-timer.boot
  	@ echo 270 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 848,853 ----
*************** g-util.${LISP}: $(srcdir)/g-util.boot.pa
*** 1136,1149 ****
  	@ echo 272 making g-util.${LISP} from $(srcdir)/g-util.boot.pamphlet
  	@ rm -f g-util.$(OBJEXT)
  	$(axiom_build_document) --tangle=g-util.clisp --output=$@ $<
- g-util.$(OBJEXT): g-util.clisp 
- 	@ echo 273 making g-util.$(OBJEXT) from g-util.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "g-util.clisp" :output-file "g-util.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "g-util.clisp" :output-file "g-util.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  g-util.clisp: g-util.boot
  	@ echo 274 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 861,866 ----
*************** g-util.clisp: g-util.boot
*** 1153,1167 ****
  	  fi
  
  
- 
- hashcode.$(OBJEXT): hashcode.clisp 
- 	@ echo 583 making hashcode.$(OBJEXT) from hashcode.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "hashcode.clisp" :output-file "hashcode.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "hashcode.clisp" :output-file "hashcode.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  hashcode.clisp: hashcode.boot
  	@ echo 584 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 870,875 ----
*************** ${AUTO}/htcheck.$(OBJEXT): htcheck.$(OBJ
*** 1175,1188 ****
  	@ echo 453 making ${AUTO}/htcheck.$(OBJEXT) from htcheck.$(OBJEXT)
  	@ cp htcheck.$(OBJEXT) ${AUTO}
  
- htcheck.$(OBJEXT): htcheck.clisp 
- 	@ echo 454 making htcheck.$(OBJEXT) from htcheck.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "htcheck.clisp" :output-file "htcheck.$(OBJEXT)"))' |  ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "htcheck.clisp" :output-file "htcheck.$(OBJEXT)"))' |  ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  htcheck.clisp: htcheck.boot
  	@ echo 455 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 883,888 ----
*************** ${AUTO}/ht-root.$(OBJEXT): ht-root.$(OBJ
*** 1196,1209 ****
  	@ echo 449 making ${AUTO}/ht-root.$(OBJEXT) from ht-root.$(OBJEXT)
  	@ cp ht-root.$(OBJEXT) ${AUTO}
  
- ht-root.$(OBJEXT): ht-root.clisp 
- 	@ echo 450 making ht-root.$(OBJEXT) from ht-root.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "ht-root.clisp" :output-file "ht-root.$(OBJEXT)"))' |  ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "ht-root.clisp" :output-file "ht-root.$(OBJEXT)"))' |  ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  ht-root.clisp: ht-root.boot
  	@ echo 451 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 896,901 ----
*************** ${AUTO}/htsetvar.$(OBJEXT): htsetvar.$(O
*** 1217,1230 ****
  	@ echo 442 making ${AUTO}/htsetvar.$(OBJEXT) from htsetvar.$(OBJEXT)
  	@ cp htsetvar.$(OBJEXT) ${AUTO}
  
- htsetvar.$(OBJEXT): htsetvar.clisp 
- 	@ echo 443 making htsetvar.$(OBJEXT) from htsetvar.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "htsetvar.clisp" :output-file "htsetvar.$(OBJEXT)"))' |  ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "htsetvar.clisp" :output-file "htsetvar.$(OBJEXT)"))' |  ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  htsetvar.clisp: htsetvar.boot
  	@ echo 444 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 909,914 ----
*************** ${AUTO}/ht-util.$(OBJEXT): ht-util.$(OBJ
*** 1238,1251 ****
  	@ echo 438 making ${AUTO}/ht-util.$(OBJEXT) from ht-util.$(OBJEXT)
  	@ cp ht-util.$(OBJEXT) ${AUTO}
  
- ht-util.$(OBJEXT): ht-util.clisp 
- 	@ echo 439 making ht-util.$(OBJEXT) from ht-util.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "ht-util.clisp" :output-file "ht-util.$(OBJEXT)"))' |  ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "ht-util.clisp" :output-file "ht-util.$(OBJEXT)"))' |  ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  ht-util.clisp: ht-util.boot
  	@ echo 440 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 922,927 ----
*************** ht-util.clisp: ht-util.boot
*** 1255,1268 ****
  	  fi
  
  
- hypertex.$(OBJEXT): hypertex.clisp 
- 	@ echo 276 making hypertex.$(OBJEXT) from hypertex.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "hypertex.clisp" :output-file "hypertex.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "hypertex.clisp" :output-file "hypertex.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  hypertex.clisp: hypertex.boot
  	@ echo 277 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 931,936 ----
*************** hypertex.clisp: hypertex.boot
*** 1272,1285 ****
  	  fi
  
  
- i-analy.$(OBJEXT): i-analy.clisp 
- 	@ echo 279 making i-analy.$(OBJEXT) from i-analy.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "i-analy.clisp" :output-file "i-analy.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "i-analy.clisp" :output-file "i-analy.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  i-analy.clisp: i-analy.boot
  	@ echo 280 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 940,945 ----
*************** i-analy.clisp: i-analy.boot
*** 1289,1302 ****
  	  fi
  
  
- i-code.$(OBJEXT): i-code.clisp 
- 	@ echo 282 making i-code.$(OBJEXT) from i-code.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "i-code.clisp" :output-file "i-code.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "i-code.clisp" :output-file "i-code.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  i-code.clisp: i-code.boot
  	@ echo 283 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 949,954 ----
*************** i-code.clisp: i-code.boot
*** 1306,1319 ****
  	  fi
  
  
- i-coerce.$(OBJEXT): i-coerce.clisp 
- 	@ echo 285 making i-coerce.$(OBJEXT) from i-coerce.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "i-coerce.clisp" :output-file "i-coerce.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "i-coerce.clisp" :output-file "i-coerce.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  i-coerce.clisp: i-coerce.boot
  	@ echo 286 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 958,963 ----
*************** i-coerce.clisp: i-coerce.boot
*** 1323,1336 ****
  	  fi
  
  
- i-coerfn.$(OBJEXT): i-coerfn.clisp 
- 	@ echo 288 making i-coerfn.$(OBJEXT) from i-coerfn.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "i-coerfn.clisp" :output-file "i-coerfn.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "i-coerfn.clisp" :output-file "i-coerfn.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  i-coerfn.clisp: i-coerfn.boot
  	@ echo 289 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 967,972 ----
*************** i-coerfn.clisp: i-coerfn.boot
*** 1340,1353 ****
  	  fi
  
  
- i-eval.$(OBJEXT): i-eval.clisp 
- 	@ echo 291 making i-eval.$(OBJEXT) from i-eval.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "i-eval.clisp" :output-file "i-eval.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "i-eval.clisp" :output-file "i-eval.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  i-eval.clisp: i-eval.boot
  	@ echo 292 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 976,981 ----
*************** i-eval.clisp: i-eval.boot
*** 1357,1370 ****
  	  fi
  
  
- i-funsel.$(OBJEXT): i-funsel.clisp 
- 	@ echo 294 making i-funsel.$(OBJEXT) from i-funsel.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "i-funsel.clisp" :output-file "i-funsel.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "i-funsel.clisp" :output-file "i-funsel.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  i-funsel.clisp: i-funsel.boot
  	@ echo 295 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 985,990 ----
*************** i-funsel.clisp: i-funsel.boot
*** 1374,1399 ****
  	  fi
  
  
- bookvol5.$(OBJEXT): bookvol5.lisp
- 	@ echo 297 making $@ from $<
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "bookvol5.lisp" :output-file "bookvol5.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "bookvol5.lisp" :output-file "bookvol5.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  bookvol5.lisp: $(srcdir)/bookvol5.pamphlet
  	@ echo 298 making $@ from $<
  	$(axiom_build_document) --tangle=Interpreter --output=$@ $<
  
- i-intern.$(OBJEXT): i-intern.clisp 
- 	@ echo 300 making i-intern.$(OBJEXT) from i-intern.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "i-intern.clisp" :output-file "i-intern.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "i-intern.clisp" :output-file "i-intern.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	 fi
- 
  i-intern.clisp: i-intern.boot
  	@ echo 301 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 994,1003 ----
*************** i-intern.clisp: i-intern.boot
*** 1403,1416 ****
  	  fi
  
  
- interop.$(OBJEXT): interop.clisp
- 	@ echo 586 making interop.$(OBJEXT) from interop.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "interop.clisp" :output-file "interop.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "interop.clisp" :output-file "interop.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  interop.clisp: interop.boot
  	@ echo 587 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 1007,1012 ----
*************** interop.clisp: interop.boot
*** 1420,1433 ****
  	  fi
  
  
- i-map.$(OBJEXT): i-map.clisp 
- 	@ echo 303 making i-map.$(OBJEXT) from i-map.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "i-map.clisp" :output-file "i-map.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "i-map.clisp" :output-file "i-map.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  i-map.clisp: i-map.boot
  	@ echo 304 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 1016,1021 ----
*************** ${AUTO}/info.$(OBJEXT): info.$(OBJEXT)
*** 1441,1454 ****
  	@ echo 327 making ${AUTO}/info.$(OBJEXT) from info.$(OBJEXT)
  	@ cp info.$(OBJEXT) ${AUTO}
  
- info.$(OBJEXT): info.clisp 
- 	@ echo 328 making info.$(OBJEXT) from info.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "info.clisp" :output-file "info.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "info.clisp" :output-file "info.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  info.clisp: info.boot
  	@ echo 329 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 1029,1034 ----
*************** info.clisp: info.boot
*** 1458,1471 ****
  	  fi
  
  
- i-output.$(OBJEXT): i-output.clisp 
- 	@ echo 306 making i-output.$(OBJEXT) from i-output.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "i-output.clisp" :output-file "i-output.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "i-output.clisp" :output-file "i-output.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  i-output.clisp: i-output.boot
  	@ echo 307 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 1038,1043 ----
*************** i-output.clisp: i-output.boot
*** 1475,1488 ****
  	  fi 
  
  
- i-resolv.$(OBJEXT): i-resolv.clisp 
- 	@ echo 309 making i-resolv.$(OBJEXT) from i-resolv.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "i-resolv.clisp" :output-file "i-resolv.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "i-resolv.clisp" :output-file "i-resolv.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  i-resolv.clisp: i-resolv.boot
  	@ echo 310 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 1047,1052 ----
*************** i-resolv.clisp: i-resolv.boot
*** 1492,1505 ****
  	  fi
  
  
- i-spec1.$(OBJEXT): i-spec1.clisp 
- 	@ echo 312 making i-spec1.$(OBJEXT) from i-spec1.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "i-spec1.clisp" :output-file "i-spec1.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "i-spec1.clisp" :output-file "i-spec1.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  i-spec1.clisp: i-spec1.boot
  	@ echo 313 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 1056,1061 ----
*************** i-spec1.clisp: i-spec1.boot
*** 1509,1522 ****
  	  fi
  
  
- i-spec2.$(OBJEXT): i-spec2.clisp 
- 	@ echo 315 making i-spec2.$(OBJEXT) from i-spec2.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "i-spec2.clisp" :output-file "i-spec2.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "i-spec2.clisp" :output-file "i-spec2.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  i-spec2.clisp: i-spec2.boot
  	@ echo 316 making $@ from i-spec2.boot
  	@ if [ -z "${NOISE}" ] ; then \
--- 1065,1070 ----
*************** i-spec2.clisp: i-spec2.boot
*** 1526,1539 ****
  	  fi
  
  
- i-syscmd.$(OBJEXT): i-syscmd.clisp 
- 	@ echo 318 making i-syscmd.$(OBJEXT) from i-syscmd.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "i-syscmd.clisp" :output-file "i-syscmd.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "i-syscmd.clisp" :output-file "i-syscmd.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  i-syscmd.clisp: i-syscmd.boot
  	@ echo 319 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 1074,1079 ----
*************** ${AUTO}/iterator.$(OBJEXT): iterator.$(O
*** 1547,1560 ****
  	@ echo 331 making ${AUTO}/iterator.$(OBJEXT) from iterator.$(OBJEXT)
  	@ cp iterator.$(OBJEXT) ${AUTO}
  
- iterator.$(OBJEXT): iterator.clisp 
- 	@ echo 332 making iterator.$(OBJEXT) from iterator.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "iterator.clisp" :output-file "iterator.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "iterator.clisp" :output-file "iterator.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  iterator.clisp: iterator.boot
  	@ echo 333 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 1087,1092 ----
*************** iterator.clisp: iterator.boot
*** 1564,1577 ****
  	  fi
  
  
- i-toplev.$(OBJEXT): i-toplev.clisp 
- 	@ echo 321 making i-toplev.$(OBJEXT) from i-toplev.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "i-toplev.clisp" :output-file "i-toplev.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "i-toplev.clisp" :output-file "i-toplev.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
-           fi
- 
  i-toplev.clisp: i-toplev.boot
  	@ echo 322 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 1096,1101 ----
*************** i-toplev.clisp: i-toplev.boot
*** 1581,1594 ****
  	  fi
  
  
- i-util.$(OBJEXT): i-util.clisp 
- 	@ echo 324 making i-util.$(OBJEXT) from i-util.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "i-util.clisp" :output-file "i-util.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "i-util.clisp" :output-file "i-util.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
-           fi
- 
  i-util.clisp: i-util.boot
  	@ echo 325 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 1105,1110 ----
*************** i-util.clisp: i-util.boot
*** 1598,1611 ****
  	  fi
  
  
- lisplib.$(OBJEXT): lisplib.clisp 
- 	@ echo 335 making lisplib.$(OBJEXT) from lisplib.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "lisplib.clisp" :output-file "lisplib.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "lisplib.clisp" :output-file "lisplib.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  lisplib.clisp: lisplib.boot
  	@ echo 336 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 1114,1119 ----
*************** lisplib.clisp: lisplib.boot
*** 1616,1627 ****
  
  
  ${AUTO}/mark.$(OBJEXT): mark.clisp 
! 	@ echo 604 making ${AUTO}/mark.$(OBJEXT) from mark.clisp
! 	@ if [ -z "${NOISE}" ] ; then \
! 	   echo '(progn  (compile-file "mark.clisp" :output-file "${AUTO}/mark.$(OBJEXT)"))' | ${DEPSYS} ; \
! 	  else \
! 	   echo '(progn  (compile-file "mark.clisp" :output-file "${AUTO}/mark.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
! 	  fi
  
  mark.clisp: mark.boot
  	@ echo 605 making $@ from $<
--- 1124,1130 ----
  
  
  ${AUTO}/mark.$(OBJEXT): mark.clisp 
! 	$(COMPILE_LISP)
  
  mark.clisp: mark.boot
  	@ echo 605 making $@ from $<
*************** mark.clisp: mark.boot
*** 1632,1645 ****
  	  fi
  
  
- match.$(OBJEXT): match.clisp 
- 	@ echo 338 making match.$(OBJEXT) from match.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "match.clisp" :output-file "match.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "match.clisp" :output-file "match.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  match.clisp: match.boot
  	@ echo 339 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 1135,1140 ----
*************** ${AUTO}/modemap.$(OBJEXT): modemap.$(OBJ
*** 1663,1676 ****
  	@ echo 341 making ${AUTO}/modemap.$(OBJEXT) from modemap.$(OBJEXT)
  	@ cp modemap.$(OBJEXT) ${AUTO}
  
- modemap.$(OBJEXT): modemap.clisp 
- 	@ echo 342 making modemap.$(OBJEXT) from modemap.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "modemap.clisp" :output-file "modemap.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "modemap.clisp" :output-file "modemap.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  modemap.clisp: modemap.boot
  	@ echo 343 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 1158,1163 ----
*************** modemap.clisp: modemap.boot
*** 1680,1693 ****
  	  fi
  
  
- msgdb.$(OBJEXT): msgdb.clisp 
- 	@ echo 345 making msgdb.$(OBJEXT) from msgdb.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "msgdb.clisp" :output-file "msgdb.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "msgdb.clisp" :output-file "msgdb.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  msgdb.clisp: msgdb.boot
  	@ echo 346 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 1167,1172 ----
*************** ${AUTO}/nag-c02.$(OBJEXT): nag-c02.$(OBJ
*** 1701,1714 ****
  	@ echo 150 making${AUTO}/nag-c02.$(OBJEXT) from nag-c02.$(OBJEXT)
  	@ cp nag-c02.$(OBJEXT) ${AUTO}
  
- nag-c02.$(OBJEXT): nag-c02.clisp
- 	@ echo 151 making nag-c02.$(OBJEXT) from nag-c02.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
-            echo '(progn  (compile-file "nag-c02.clisp" :output-file "nag-c02.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
-            echo '(progn  (compile-file "nag-c02.clisp" :output-file "nag-c02.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  nag-c02.clisp: nag-c02.boot
  	@ echo 152 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 1180,1185 ----
*************** ${AUTO}/nag-c05.$(OBJEXT): nag-c05.$(OBJ
*** 1722,1735 ****
  	@ echo 154 making ${AUTO}/nag-c05.$(OBJEXT) from nag-c05.$(OBJEXT)
  	@ cp nag-c05.$(OBJEXT) ${AUTO}
  
- nag-c05.$(OBJEXT): nag-c05.clisp
- 	@ echo 155 making nag-c05.$(OBJEXT) from nag-c05.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "nag-c05.clisp" :output-file "nag-c05.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "nag-c05.clisp" :output-file "nag-c05.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  nag-c05.clisp: nag-c05.boot
  	@ echo 156 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 1193,1198 ----
*************** ${AUTO}/nag-c06.$(OBJEXT): nag-c06.$(OBJ
*** 1743,1756 ****
  	@ echo 158 making${AUTO}/nag-c06.$(OBJEXT) from nag-c06.$(OBJEXT)
  	@ cp nag-c06.$(OBJEXT) ${AUTO}
  
- nag-c06.$(OBJEXT): nag-c06.clisp
- 	@ echo 159 making nag-c06.$(OBJEXT) from nag-c06.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "nag-c06.clisp" :output-file "nag-c06.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "nag-c06.clisp" :output-file "nag-c06.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  nag-c06.clisp: nag-c06.boot
  	@ echo 160 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 1206,1211 ----
*************** ${AUTO}/nag-d01.$(OBJEXT): nag-d01.$(OBJ
*** 1764,1777 ****
  	@ echo 162 making${AUTO}/nag-d01.$(OBJEXT) from nag-d01.$(OBJEXT)
  	@ cp nag-d01.$(OBJEXT) ${AUTO}
  
- nag-d01.$(OBJEXT): nag-d01.clisp
- 	@ echo 163 making nag-d01.$(OBJEXT) from nag-d01.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "nag-d01.clisp" :output-file "nag-d01.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "nag-d01.clisp" :output-file "nag-d01.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  nag-d01.clisp: nag-d01.boot
  	@ echo 164 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 1219,1224 ----
*************** ${AUTO}/nag-d02.$(OBJEXT): nag-d02.$(OBJ
*** 1785,1798 ****
  	@ echo 166 making${AUTO}/nag-d02.$(OBJEXT) from nag-d02.$(OBJEXT)
  	@ cp nag-d02.$(OBJEXT) ${AUTO}
  
- nag-d02.$(OBJEXT): nag-d02.clisp
- 	@ echo 167 making nag-d02.$(OBJEXT) from nag-d02.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
-            echo '(progn  (compile-file "nag-d02.clisp" :output-file "nag-d02.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
-            echo '(progn  (compile-file "nag-d02.clisp" :output-file "nag-d02.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  nag-d02.clisp: nag-d02.boot
  	@ echo 168 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 1232,1237 ----
*************** ${AUTO}/nag-d03.$(OBJEXT): nag-d03.$(OBJ
*** 1806,1819 ****
  	@ echo 170 making${AUTO}/nag-d03.$(OBJEXT) from nag-d03.$(OBJEXT)
  	@ cp nag-d03.$(OBJEXT) ${AUTO}
  
- nag-d03.$(OBJEXT): nag-d03.clisp
- 	@ echo 171 making nag-d03.$(OBJEXT) from nag-d03.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
-            echo '(progn  (compile-file "nag-d03.clisp" :output-file "nag-d03.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
-            echo '(progn  (compile-file "nag-d03.clisp" :output-file "nag-d03.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  nag-d03.clisp: nag-d03.boot
  	@ echo 172 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 1245,1250 ----
*************** ${AUTO}/nag-e01.$(OBJEXT): nag-e01.$(OBJ
*** 1827,1840 ****
  	@ echo 174 making ${AUTO}/nag-e01.$(OBJEXT) from nag-e01.$(OBJEXT)
  	@ cp nag-e01.$(OBJEXT) ${AUTO}
  
- nag-e01.$(OBJEXT): nag-e01.clisp
- 	@ echo 175 making nag-e01.$(OBJEXT) from nag-e01.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "nag-e01.clisp" :output-file "nag-e01.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "nag-e01.clisp" :output-file "nag-e01.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  nag-e01.clisp: nag-e01.boot
  	@ echo 176 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 1258,1263 ----
*************** ${AUTO}/nag-e02.$(OBJEXT): nag-e02.$(OBJ
*** 1848,1861 ****
  	@ echo 182 making ${AUTO}/nag-e02.$(OBJEXT) from nag-e02.$(OBJEXT)
  	@ cp nag-e02.$(OBJEXT) ${AUTO}
  
- nag-e02.$(OBJEXT): nag-e02.clisp
- 	@ echo 183 making nag-e02.$(OBJEXT) from nag-e02.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "nag-e02.clisp" :output-file "nag-e02.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "nag-e02.clisp" :output-file "nag-e02.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  nag-e02.clisp: nag-e02.boot
  	@ echo 184 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 1271,1276 ----
*************** ${AUTO}/nag-e04.$(OBJEXT): nag-e04.$(OBJ
*** 1869,1882 ****
  	@ echo 186 making ${AUTO}/nag-e04.$(OBJEXT) from nag-e04.$(OBJEXT)
  	@ cp nag-e04.$(OBJEXT) ${AUTO}
  
- nag-e04.$(OBJEXT): nag-e04.clisp
- 	@ echo 187 making nag-e04.$(OBJEXT) from nag-e04.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
-            echo '(progn  (compile-file "nag-e04.clisp" :output-file "nag-e04.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
-            echo '(progn  (compile-file "nag-e04.clisp" :output-file "nag-e04.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  nag-e04.clisp: nag-e04.boot
  	@ echo 188 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 1284,1289 ----
*************** ${AUTO}/nag-f01.$(OBJEXT): nag-f01.$(OBJ
*** 1890,1903 ****
  	@ echo 190 making ${AUTO}/nag-f01.$(OBJEXT) from nag-f01.$(OBJEXT)
  	@ cp nag-f01.$(OBJEXT) ${AUTO}
  
- nag-f01.$(OBJEXT): nag-f01.clisp
- 	@ echo 191 making nag-f01.$(OBJEXT) from nag-f01.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
-            echo '(progn  (compile-file "nag-f01.clisp" :output-file "nag-f01.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
-            echo '(progn  (compile-file "nag-f01.clisp" :output-file "nag-f01.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  nag-f01.clisp: nag-f01.boot
  	@ echo 192 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 1297,1302 ----
*************** ${AUTO}/nag-f02.$(OBJEXT): nag-f02.$(OBJ
*** 1911,1924 ****
  	@ echo 194 making ${AUTO}/nag-f02.$(OBJEXT) from nag-f02.$(OBJEXT)
  	@ cp nag-f02.$(OBJEXT) ${AUTO}
  
- nag-f02.$(OBJEXT): nag-f02.clisp
- 	@ echo 195 making nag-f02.$(OBJEXT) from nag-f02.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
-            echo '(progn  (compile-file "nag-f02.clisp" :output-file "nag-f02.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
-            echo '(progn  (compile-file "nag-f02.clisp" :output-file "nag-f02.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  nag-f02.clisp: nag-f02.boot
  	@ echo 196 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 1310,1315 ----
*************** ${AUTO}/nag-f04.$(OBJEXT): nag-f04.$(OBJ
*** 1932,1945 ****
  	@ echo 198 making ${AUTO}/nag-f04.$(OBJEXT) from nag-f04.$(OBJEXT)
  	@ cp nag-f04.$(OBJEXT) ${AUTO}
  
- nag-f04.$(OBJEXT): nag-f04.clisp
- 	@ echo 199 making nag-f04.$(OBJEXT) from nag-f04.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "nag-f04.clisp" :output-file "nag-f04.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "nag-f04.clisp" :output-file "nag-f04.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  nag-f04.clisp: nag-f04.boot
  	@ echo 200 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 1323,1328 ----
*************** ${AUTO}/nag-f07.$(OBJEXT): nag-f07.$(OBJ
*** 1953,1966 ****
  	@ echo 202 making ${AUTO}/nag-f07.$(OBJEXT) from nag-f07.$(OBJEXT)
  	@ cp nag-f07.$(OBJEXT) ${AUTO}
  
- nag-f07.$(OBJEXT): nag-f07.clisp
- 	@ echo 203 making nag-f07.$(OBJEXT) from nag-f07.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
-            echo '(progn  (compile-file "nag-f07.clisp" :output-file "nag-f07.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
-            echo '(progn  (compile-file "nag-f07.clisp" :output-file "nag-f07.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  nag-f07.clisp: nag-f07.boot
  	@ echo 204 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 1336,1341 ----
*************** ${AUTO}/nag-s.$(OBJEXT): nag-s.$(OBJEXT)
*** 1974,1987 ****
  	@ echo 206 making ${AUTO}/nag-s.$(OBJEXT) from nag-s.$(OBJEXT)
  	@ cp nag-s.$(OBJEXT) ${AUTO}
  
- nag-s.$(OBJEXT): nag-s.clisp
- 	@ echo 207 making nag-s.$(OBJEXT) from nag-s.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "nag-s.clisp" :output-file "nag-s.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "nag-s.clisp" :output-file "nag-s.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  nag-s.clisp: nag-s.boot
  	@ echo 208 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 1349,1354 ----
*************** nag-s.clisp: nag-s.boot
*** 1991,2004 ****
  	  fi
  
  
- newaux.$(OBJEXT): newaux.lisp
- 	@ echo 79 making newaux.$(OBJEXT) from newaux.lisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "newaux.lisp" :output-file "newaux.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "newaux.lisp" :output-file "newaux.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  newaux.${LISP}: newaux.lisp
  	@ echo 80 making newaux.${LISP} from newaux.lisp
  	@cp newaux.lisp newaux.${LISP}
--- 1358,1363 ----
*************** newaux.${LISP}: newaux.lisp
*** 2006,2019 ****
  newaux.lisp: $(srcdir)/newaux.lisp.pamphlet
  	$(axiom_build_document) --tangle --output=$@ $<
  
- newfort.$(OBJEXT): newfort.clisp 
- 	@ echo 348 making newfort.$(OBJEXT) from newfort.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "newfort.clisp" :output-file "newfort.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "newfort.clisp" :output-file "newfort.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  newfort.clisp: newfort.boot
  	@ echo 349 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 1365,1370 ----
*************** ${AUTO}/nruncomp.$(OBJEXT): nruncomp.$(O
*** 2027,2040 ****
  	@ echo 351 making ${AUTO}/nruncomp.$(OBJEXT) from nruncomp.$(OBJEXT)
  	@ cp nruncomp.$(OBJEXT) ${AUTO}
  
- nruncomp.$(OBJEXT): nruncomp.clisp 
- 	@ echo 352 making nruncomp.$(OBJEXT) from nruncomp.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "nruncomp.clisp" :output-file "nruncomp.$(OBJEXT)"))' |  ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "nruncomp.clisp" :output-file "nruncomp.$(OBJEXT)"))' |  ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  nruncomp.clisp: nruncomp.boot
  	@ echo 353 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 1378,1383 ----
*************** nruncomp.clisp: nruncomp.boot
*** 2044,2057 ****
  	  fi
  
  
- nrunfast.$(OBJEXT): nrunfast.clisp 
- 	@ echo 355 making nrunfast.$(OBJEXT) from nrunfast.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "nrunfast.clisp" :output-file "nrunfast.$(OBJEXT)"))' |  ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "nrunfast.clisp" :output-file "nrunfast.$(OBJEXT)"))' |  ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  nrunfast.clisp: nrunfast.boot
  	@ echo 356 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 1387,1392 ----
*************** nrunfast.clisp: nrunfast.boot
*** 2061,2074 ****
  	  fi
  
  
- nrungo.$(OBJEXT): nrungo.clisp 
- 	@ echo 358 making nrungo.$(OBJEXT) from nrungo.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "nrungo.clisp" :output-file "nrungo.$(OBJEXT)"))' |  ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "nrungo.clisp" :output-file "nrungo.$(OBJEXT)"))' |  ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  nrungo.clisp: nrungo.boot
  	@ echo 359 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 1396,1401 ----
*************** nrungo.clisp: nrungo.boot
*** 2078,2091 ****
  	  fi
  
  
- nruntime.$(OBJEXT): nruntime.clisp 
- 	@ echo 361 making nruntime.$(OBJEXT) from nruntime.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "nruntime.clisp" :output-file "nruntime.$(OBJEXT)"))' |  ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "nruntime.clisp" :output-file "nruntime.$(OBJEXT)"))' |  ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  nruntime.clisp: nruntime.boot
  	@ echo 362 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 1405,1410 ----
*************** nruntime.clisp: nruntime.boot
*** 2095,2108 ****
  	  fi
  
  
- nrunopt.$(OBJEXT): nrunopt.clisp 
- 	@ echo 364 making nrunopt.$(OBJEXT) from nrunopt.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "nrunopt.clisp" :output-file "nrunopt.$(OBJEXT)"))' |  ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "nrunopt.clisp" :output-file "nrunopt.$(OBJEXT)"))' |  ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  nrunopt.clisp: nrunopt.boot
  	@ echo 365 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 1414,1419 ----
*************** ${AUTO}/package.$(OBJEXT): package.$(OBJ
*** 2121,2134 ****
  	@ echo 370 making ${AUTO}/package.$(OBJEXT) from package.$(OBJEXT)
  	@ cp package.$(OBJEXT) ${AUTO}
  
- package.$(OBJEXT): package.clisp 
- 	@ echo 371 making package.$(OBJEXT) from package.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "package.clisp" :output-file "package.$(OBJEXT)"))' |  ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "package.clisp" :output-file "package.$(OBJEXT)"))' |  ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  package.clisp: package.boot
  	@ echo 372 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 1432,1437 ----
*************** ${AUTO}/parse.$(OBJEXT): parse.$(OBJEXT)
*** 2142,2155 ****
  	@ echo 374 making ${AUTO}/parse.$(OBJEXT) from parse.$(OBJEXT)
  	@ cp parse.$(OBJEXT) ${AUTO}
  
- parse.$(OBJEXT): parse.clisp 
- 	@ echo 375 making parse.$(OBJEXT) from parse.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "parse.clisp" :output-file "parse.$(OBJEXT)"))' |  ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "parse.clisp" :output-file "parse.$(OBJEXT)"))' |  ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  parse.clisp: $(srcdir)/parse.boot.pamphlet
  	@ echo 376 making $@ from $<
  	@ rm -f parse.$(OBJEXT)
--- 1445,1450 ----
*************** ${AUTO}/parsing.$(OBJEXT): parsing.$(OBJ
*** 2171,2184 ****
  	@ cp parsing.$(OBJEXT) ${AUTO}
  
  
- pathname.$(OBJEXT): pathname.clisp 
- 	@ echo 379 making pathname.$(OBJEXT) from pathname.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "pathname.clisp" :output-file "pathname.$(OBJEXT)"))' |  ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "pathname.clisp" :output-file "pathname.$(OBJEXT)"))' |  ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  pathname.clisp: pathname.boot
  	@ echo 380 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 1466,1471 ----
*************** postpar.clisp: $(srcdir)/postpar.boot.pa
*** 2196,2209 ****
  	@ echo 383 making $@ from $<
  	@ rm -f postpar.$(OBJEXT)
  	$(axiom_build_document) --tangle=postpar.clisp --output=$@ $<
- postpar.$(OBJEXT): postpar.clisp 
- 	@ echo 384 making $@ from $<
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "postpar.clisp" :output-file "postpar.$(OBJEXT)"))' |  ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "postpar.clisp" :output-file "postpar.$(OBJEXT)"))' |  ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  ## FIXME: temporarily commented
  # postpar.clisp: $(srcdir)/postpar.boot.pamphlet
  # 	@ echo 385 making postpar.clisp from $(srcdir)/postpar.boot.pamphlet
--- 1483,1488 ----
*************** ${AUTO}/profile.$(OBJEXT): profile.$(OBJ
*** 2230,2243 ****
  	@ echo 235 making ${AUTO}/profile.$(OBJEXT) from profile.$(OBJEXT)
  	@ cp profile.$(OBJEXT) ${AUTO}
  
- profile.$(OBJEXT): profile.clisp 
- 	@ echo 236 making profile.$(OBJEXT) from profile.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "profile.clisp" :output-file "profile.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "profile.clisp" :output-file "profile.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  profile.clisp: profile.boot
  	@ echo 237 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 1509,1514 ----
*************** profile.clisp: profile.boot
*** 2248,2259 ****
  
  
  ${AUTO}/pspad1.$(OBJEXT): pspad1.clisp 
! 	@ echo 598 making ${AUTO}/pspad1.$(OBJEXT) from pspad1.clisp
! 	@ if [ -z "${NOISE}" ] ; then \
! 	   echo '(progn  (compile-file "pspad1.clisp" :output-file "${AUTO}/pspad1.$(OBJEXT)"))' | ${DEPSYS} ; \
! 	  else \
! 	   echo '(progn  (compile-file "pspad1.clisp" :output-file "${AUTO}/pspad1.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
! 	  fi
  
  pspad1.clisp: pspad1.boot
  	@ echo 599 making $@ from $<
--- 1519,1525 ----
  
  
  ${AUTO}/pspad1.$(OBJEXT): pspad1.clisp 
! 	$(COMPILE_LISP)
  
  pspad1.clisp: pspad1.boot
  	@ echo 599 making $@ from $<
*************** pspad1.clisp: pspad1.boot
*** 2265,2276 ****
  
  
  ${AUTO}/pspad2.$(OBJEXT): pspad2.clisp 
! 	@ echo 601 making ${AUTO}/pspad2.$(OBJEXT) from pspad2.clisp
! 	@ if [ -z "${NOISE}" ] ; then \
! 	   echo '(progn  (compile-file "pspad2.clisp" :output-file "${AUTO}/pspad2.$(OBJEXT)"))' | ${DEPSYS} ; \
! 	  else \
! 	   echo '(progn  (compile-file "pspad2.clisp" :output-file "${AUTO}/pspad2.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
! 	  fi
  
  pspad2.clisp: pspad2.boot
  	@ echo 602 making $@ from $<
--- 1531,1537 ----
  
  
  ${AUTO}/pspad2.$(OBJEXT): pspad2.clisp 
! 	$(COMPILE_LISP)
  
  pspad2.clisp: pspad2.boot
  	@ echo 602 making $@ from $<
*************** pspad2.clisp: pspad2.boot
*** 2281,2294 ****
  	  fi 
  
  
- record.$(OBJEXT): record.clisp 
- 	@ echo 446 making record.$(OBJEXT) from record.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "record.clisp" :output-file "record.$(OBJEXT)"))' |  ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "record.clisp" :output-file "record.$(OBJEXT)"))' |  ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  record.clisp: record.boot
  	@ echo 447 making $@ $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 1542,1547 ----
*************** record.clisp: record.boot
*** 2298,2311 ****
  	  fi
  
  
- rulesets.$(OBJEXT): rulesets.clisp 
- 	@ echo 387 making rulesets.$(OBJEXT) from rulesets.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "rulesets.clisp" :output-file "rulesets.$(OBJEXT)"))' |  ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "rulesets.clisp" :output-file "rulesets.$(OBJEXT)"))' |  ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  rulesets.clisp: rulesets.boot
  	@ echo 388 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 1551,1556 ----
*************** rulesets.clisp: rulesets.boot
*** 2315,2328 ****
  	  fi
  
  
- server.$(OBJEXT): server.clisp 
- 	@ echo 390 making server.$(OBJEXT) from server.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "server.clisp" :output-file "server.$(OBJEXT)"))' |  ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "server.clisp" :output-file "server.$(OBJEXT)"))' |  ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  server.clisp: server.boot
  	@ echo 391 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 1560,1565 ----
*************** server.clisp: server.boot
*** 2332,2345 ****
  	  fi
  
  
- setvars.$(OBJEXT): setvars.clisp 
- 	@ echo 394 making setvars.$(OBJEXT) from setvars.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "setvars.clisp" :output-file "setvars.$(OBJEXT)"))' |  ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "setvars.clisp" :output-file "setvars.$(OBJEXT)"))' |  ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  setvars.${LISP}: $(srcdir)/setvars.boot.pamphlet
  	@ echo 393 making setvars.${LISP} from $(srcdir)/setvars.boot.pamphlet
  	@ rm -f setvars.$(OBJEXT)
--- 1569,1574 ----
*************** setvars.clisp: setvars.boot
*** 2353,2366 ****
  	  fi
  
  
- setvart.$(OBJEXT): setvart.clisp 
- 	@ echo 397 making setvart.$(OBJEXT) from setvart.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "setvart.clisp" :output-file "setvart.$(OBJEXT)"))' |  ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "setvart.clisp" :output-file "setvart.$(OBJEXT)"))' |  ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  setvart.clisp: setvart.boot
  	@ echo 398 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 1582,1587 ----
*************** ${AUTO}/showimp.$(OBJEXT): showimp.$(OBJ
*** 2375,2388 ****
  	@ cp showimp.$(OBJEXT) ${AUTO}
  
  
- simpbool.$(OBJEXT): simpbool.clisp 
- 	@ echo 400 making simpbool.$(OBJEXT) from simpbool.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "simpbool.clisp" :output-file "simpbool.$(OBJEXT)"))' |  ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "simpbool.clisp" :output-file "simpbool.$(OBJEXT)"))' |  ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  simpbool.clisp: simpbool.boot
  	@ echo 401 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 1596,1601 ----
*************** simpbool.clisp: simpbool.boot
*** 2392,2405 ****
  	  fi
  
  
- slam.$(OBJEXT): slam.clisp 
- 	@ echo 404 making slam.$(OBJEXT) from slam.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "slam.clisp" :output-file "slam.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "slam.clisp" :output-file "slam.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  slam.clisp: slam.boot
  	@ echo 405 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 1605,1610 ----
*************** slam.${LISP}: $(srcdir)/slam.boot.pamphl
*** 2413,2426 ****
  	@ rm -f slam.$(OBJEXT)
  	$(axiom_build_document) --tangle=slam.clisp --output=$@ $<
  
- template.$(OBJEXT): template.clisp 
- 	@ echo 407 making template.$(OBJEXT) from template.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "template.clisp" :output-file "template.$(OBJEXT)"))' |  ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "template.clisp" :output-file "template.$(OBJEXT)"))' |  ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  template.clisp: template.boot
  	@ echo 408 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 1618,1623 ----
*************** template.clisp: template.boot
*** 2430,2443 ****
  	  fi
  
  
- termrw.$(OBJEXT): termrw.clisp 
- 	@ echo 410 making termrw.$(OBJEXT) from termrw.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "termrw.clisp" :output-file "termrw.$(OBJEXT)"))' |  ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "termrw.clisp" :output-file "termrw.$(OBJEXT)"))' |  ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  termrw.clisp: termrw.boot
  	@ echo 411 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 1627,1632 ----
*************** ${AUTO}/topics.$(OBJEXT): topics.$(OBJEX
*** 2451,2464 ****
  	@ echo 493 making ${AUTO}/topics.$(OBJEXT) from topics.$(OBJEXT)
  	@ cp topics.$(OBJEXT) ${AUTO}
  
- topics.$(OBJEXT): topics.clisp 
- 	@ echo 494 making topics.$(OBJEXT) from topics.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "topics.clisp" :output-file "topics.$(OBJEXT)"))' |  ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "topics.clisp" :output-file "topics.$(OBJEXT)"))' |  ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  topics.clisp: topics.boot
  	@ echo 495 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 1640,1645 ----
*************** topics.clisp: topics.boot
*** 2468,2481 ****
  	  fi 
  
  
- trace.$(OBJEXT): trace.clisp 
- 	@ echo 413 making trace.$(OBJEXT) from trace.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "trace.clisp" :output-file "trace.$(OBJEXT)"))' |  ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "trace.clisp" :output-file "trace.$(OBJEXT)"))' |  ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  trace.clisp: trace.boot
  	@ echo 414 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 1649,1654 ----
*************** trace.clisp: trace.boot
*** 2491,2502 ****
  
  
  ${AUTO}/wi1.$(OBJEXT): wi1.clisp 
! 	@ echo 592 making ${AUTO}/wi1.$(OBJEXT) from wi1.clisp
! 	@ if [ -z "${NOISE}" ] ; then \
! 	   echo '(progn  (compile-file "wi1.clisp" :output-file "${AUTO}/wi1.$(OBJEXT)"))' | ${DEPSYS} ; \
! 	  else \
! 	   echo '(progn  (compile-file "wi1.clisp" :output-file "${AUTO}/wi1.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
! 	  fi
  
  wi1.clisp: wi1.boot
  	@ echo 593 making $@ from $<
--- 1664,1670 ----
  
  
  ${AUTO}/wi1.$(OBJEXT): wi1.clisp 
! 	$(COMPILE_LISP)
  
  wi1.clisp: wi1.boot
  	@ echo 593 making $@ from $<
*************** wi1.clisp: wi1.boot
*** 2508,2519 ****
  
  
  ${AUTO}/wi2.$(OBJEXT): wi2.clisp 
! 	@ echo 595 making ${AUTO}/wi2.$(OBJEXT) from wi2.clisp
! 	@ if [ -z "${NOISE}" ] ; then \
! 	   echo '(progn  (compile-file "wi2.clisp" :output-file "${AUTO}/wi2.$(OBJEXT)"))' | ${DEPSYS} ; \
! 	  else \
! 	   echo '(progn  (compile-file "wi2.clisp" :output-file "${AUTO}/wi2.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
! 	  fi
  
  wi2.clisp: wi2.boot
  	@ echo 596 making $@ from $<
--- 1676,1682 ----
  
  
  ${AUTO}/wi2.$(OBJEXT): wi2.clisp 
! 	$(COMPILE_LISP)
  
  wi2.clisp: wi2.boot
  	@ echo 596 making $@ from $<
*************** wi2.clisp: wi2.boot
*** 2524,2537 ****
  	  fi
  
  
- xrun.$(OBJEXT): xrun.clisp 
- 	@ echo 589 making xrun.$(OBJEXT) from xrun.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "xrun.clisp" :output-file "xrun.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	   else \
- 	   echo '(progn  (compile-file "xrun.clisp" :output-file "xrun.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	   fi
- 
  xrun.clisp: xrun.boot
  	@ echo 590 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 1687,1692 ----
*************** ${AUTO}/xruncomp.$(OBJEXT): xruncomp.$(O
*** 2545,2558 ****
  	@ echo 457 making ${AUTO}/xruncomp.$(OBJEXT) from xruncomp.$(OBJEXT)
  	@ cp xruncomp.$(OBJEXT) ${AUTO}
  
- xruncomp.$(OBJEXT): xruncomp.clisp 
- 	@ echo 458 making xruncomp.$(OBJEXT) from xruncomp.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "xruncomp.clisp" :output-file "xruncomp.$(OBJEXT)"))' |  ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "xruncomp.clisp" :output-file "xruncomp.$(OBJEXT)"))' |  ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
  xruncomp.clisp: xruncomp.boot
  	@ echo 459 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 1700,1705 ----
*** src/interp/Makefile.pamphlet	(revision 19359)
--- src/interp/Makefile.pamphlet	(local)
*************** A new variable [[boot::*build-version*]]
*** 601,609 ****
  This information is set by hand in the top level Makefile.
  <<environment>>=
  TIMESTAMP=$(axiom_targetdir)/timestamp
! YEARWEEK=(progn (setq timestamp "${TIMESTAMP}") \
                  (setq boot::*build-version* "$(PACKAGE_STRING)") \
!                 (yearweek))
  
  @
  
--- 601,609 ----
  This information is set by hand in the top level Makefile.
  <<environment>>=
  TIMESTAMP=$(axiom_targetdir)/timestamp
! YEARWEEK=(progn (setq boot::timestamp "${TIMESTAMP}") \
                  (setq boot::*build-version* "$(PACKAGE_STRING)") \
!                 (boot::yearweek))
  
  @
  
*************** the compiled form will get loaded.
*** 776,789 ****
  \subsection{save depsys image}
  
  Once the appropriate commands are in the [[makedep.lisp]] file
! we can load the file into a fresh image and save it. At least that's
! how it used to work. In freebsd we cannot do this so we have to use
  a much more complicated procedure.
  This code used to read:
  \begin{verbatim}
  <<save depsys image>>=
! 	@ echo '(progn (load "makedep.lisp") (spad-save "$@"))' \
!                | AXIOM="$(AXIOM)" $(LISPSYS)
  @
  \end{verbatim}
  
--- 776,789 ----
  \subsection{save depsys image}
  
  Once the appropriate commands are in the [[makedep.lisp]] file
! we can load the file into an initial Lisp image and save it.
! In freebsd we cannot do this so we have to use
  a much more complicated procedure.
  This code used to read:
  \begin{verbatim}
  <<save depsys image>>=
! 	$(axiom_build_document) --tag=lisp --mode=save-image --output=$@ \
! 		--use=../boot/local-lisp makedep.lisp
  @
  \end{verbatim}
  
*************** makeint.lisp:	${DEPSYS} ${OBJS} bookvol5
*** 1089,1112 ****
  	$(INSTALL_DATA) $(axiom_src_docdir)/msgs/s2-us.msgs \
  		 $(axiom_target_datadir)/msgs
  	@ echo '${PROCLAIMS}' > makeint.lisp
  	@ echo '(load "nocompil.lisp")' >> makeint.lisp
  	@ echo '(load "bookvol5")' >> makeint.lisp
  	@ echo '(load "util")' >> makeint.lisp
  	@ echo '(in-package "BOOT")' >> makeint.lisp
  	@ touch ${TIMESTAMP}
  	@ echo '${YEARWEEK}' >> makeint.lisp
! 	@ echo '(build-interpsys (append (quote ($(patsubst %, "%", ${OBJS}))) (quote ($(patsubst %, "%", ${ASCOMP}))) (quote ($(patsubst %, "%", ${INOBJS})))) (quote ($(patsubst %, "%", ${OPOBJS}))) (quote ($(patsubst %, "%", ${OCOBJS}))) (quote ($(patsubst %, "%", ${BROBJS}))) (quote ($(patsubst %, "%", ${TRANOBJS}))) (quote ($(patsubst %, "%", ${NAGBROBJS}))) (quote ($(patsubst %, "%", ${ASAUTO})))  "${AXIOM}")' >> makeint.lisp
! 	@ echo '(in-package "SCRATCHPAD-COMPILER")' >> makeint.lisp
  	@ echo '(boot::set-restart-hook)' >> makeint.lisp
  	@ echo '(in-package "BOOT")' >> makeint.lisp
  	@ echo '(load "../algebra/warm.data")' >> makeint.lisp
! 	@ echo '(|clearClams|)' >> makeint.lisp
  	@ echo '(load "obey")' >> makeint.lisp
  	@ echo '#+:akcl (setq compiler::*suppress-compiler-notes* t)' >> makeint.lisp
  	@ echo '#+:akcl (si::gbc-time 0)' >> makeint.lisp
  
  ${SAVESYS}: makeint.lisp
! 	echo '(progn (gbc t) (load "makeint.lisp") (gbc t) (user::spad-save "$@"))' | AXIOM="$(AXIOM)" DAASE="$(axiom_src_datadir)" ${LISPSYS}
  	@ echo 6 ${SAVESYS} created
  	$(mkinstalldirs) $(axiom_target_bindir)
  @
--- 1089,1115 ----
  	$(INSTALL_DATA) $(axiom_src_docdir)/msgs/s2-us.msgs \
  		 $(axiom_target_datadir)/msgs
  	@ echo '${PROCLAIMS}' > makeint.lisp
+ 	@ echo '(gbc t)' >> makeint.lisp
  	@ echo '(load "nocompil.lisp")' >> makeint.lisp
  	@ echo '(load "bookvol5")' >> makeint.lisp
  	@ echo '(load "util")' >> makeint.lisp
  	@ echo '(in-package "BOOT")' >> makeint.lisp
  	@ touch ${TIMESTAMP}
  	@ echo '${YEARWEEK}' >> makeint.lisp
! 	@ echo '(boot::build-interpsys (append (quote ($(patsubst %, "%", ${OBJS}))) (quote ($(patsubst %, "%", ${ASCOMP}))) (quote ($(patsubst %, "%", ${INOBJS})))) (quote ($(patsubst %, "%", ${OPOBJS}))) (quote ($(patsubst %, "%", ${OCOBJS}))) (quote ($(patsubst %, "%", ${BROBJS}))) (quote ($(patsubst %, "%", ${TRANOBJS}))) (quote ($(patsubst %, "%", ${NAGBROBJS}))) (quote ($(patsubst %, "%", ${ASAUTO})))  "${AXIOM}")' >> makeint.lisp
  	@ echo '(boot::set-restart-hook)' >> makeint.lisp
  	@ echo '(in-package "BOOT")' >> makeint.lisp
  	@ echo '(load "../algebra/warm.data")' >> makeint.lisp
! 	@ echo '(boot::|clearClams|)' >> makeint.lisp
  	@ echo '(load "obey")' >> makeint.lisp
  	@ echo '#+:akcl (setq compiler::*suppress-compiler-notes* t)' >> makeint.lisp
  	@ echo '#+:akcl (si::gbc-time 0)' >> makeint.lisp
+ 	@ echo '(gbc t)' >> makeint.lisp
  
  ${SAVESYS}: makeint.lisp
! 	AXIOM="$(AXIOM)" DAASE="$(axiom_src_datadir)" \
! 		$(axiom_build_document) --tag=lisp --mode=save-image \
! 		--use=$(LOADSYS) --output=$@ makeint.lisp
  	@ echo 6 ${SAVESYS} created
  	$(mkinstalldirs) $(axiom_target_bindir)
  @
*************** are re-generated after leaving \File{int
*** 1124,1132 ****
  all-axiomsys: ${AXIOMSYS}
  
  ${AXIOMSYS}: makeint.lisp
! 	echo '(progn (gbc t) (load "makeint.lisp") (gbc t)' \
! 	   '(user::spad-save "$@"))' | \
! 		AXIOM="$(AXIOM)" DAASE="$(axiom_targetdir)" ${LISPSYS}
  	@ echo 6a ${AXIOMSYS} created
  @
  
--- 1127,1134 ----
  all-axiomsys: ${AXIOMSYS}
  
  ${AXIOMSYS}: makeint.lisp
! 	echo '(progn (load "makeint.lisp") (user::spad-save "$@"))' | \
! 		AXIOM="$(AXIOM)" DAASE="$(axiom_targetdir)" $(LOADSYS)
  	@ echo 6a ${AXIOMSYS} created
  @
  
*************** ${AUTO}/apply.$(OBJEXT): apply.$(OBJEXT)
*** 1160,1175 ****
  	@ cp apply.$(OBJEXT) ${AUTO}
  
  @
- <<apply.o (OUT from MID)>>=
- apply.$(OBJEXT): apply.clisp 
- 	@ echo 10 making apply.$(OBJEXT) from apply.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "apply.clisp" :output-file "apply.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "apply.clisp" :output-file "apply.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<apply.clisp>>=
  apply.clisp: apply.boot
  	@ echo 11 making $@ from $<
--- 1162,1167 ----
*************** ${AUTO}/fnewmeta.$(OBJEXT): fnewmeta.$(O
*** 1229,1244 ****
  
  \subsection{fortcall.boot \cite{16}}
  
- <<fortcall.o (OUT from MID)>>=
- fortcall.$(OBJEXT): fortcall.clisp 
- 	@ echo 54 making fortcall.$(OBJEXT) from fortcall.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "fortcall.clisp" :output-file "fortcall.$(OBJEXT)"))' |  ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "fortcall.clisp" :output-file "fortcall.$(OBJEXT)"))' |  ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<fortcall.clisp>>=
  fortcall.clisp: fortcall.boot
  	@ echo 55 making $@ from $<
--- 1221,1226 ----
*************** ${AUTO}/metameta.$(OBJEXT): metameta.$(O
*** 1270,1285 ****
  
  \subsection{newaux.lisp \cite{25}}
  
- <<newaux.o (OUT from MID)>>=
- newaux.$(OBJEXT): newaux.lisp
- 	@ echo 79 making newaux.$(OBJEXT) from newaux.lisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "newaux.lisp" :output-file "newaux.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "newaux.lisp" :output-file "newaux.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<newaux.lisp (OUT from MID)>>=
  newaux.${LISP}: newaux.lisp
  	@ echo 80 making newaux.${LISP} from newaux.lisp
--- 1252,1257 ----
*************** ${AUTO}/preparse.$(OBJEXT): preparse.$(O
*** 1329,1344 ****
  
  \subsection{buildom.boot \cite{41}}
  
- <<buildom.o (OUT from MID)>>=
- buildom.$(OBJEXT): buildom.clisp 
- 	@ echo 142 making buildom.$(OBJEXT) from buildom.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "buildom.clisp" :output-file "buildom.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "buildom.clisp" :output-file "buildom.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<buildom.clisp>>=
  buildom.clisp: buildom.boot
  	@ echo 143 making $@ from $<
--- 1301,1306 ----
*************** c-util.${LISP}: $(srcdir)/c-util.boot.pa
*** 1374,1389 ****
  	$(axiom_build_document) --tangle=c-util.clisp --output=$@ $<
  
  @
- <<c-util.o (OUT from MID)>>=
- c-util.$(OBJEXT): c-util.clisp 
- 	@ echo 147 making c-util.$(OBJEXT) from c-util.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "c-util.clisp" :output-file "c-util.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "c-util.clisp" :output-file "c-util.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<c-util.clisp>>=
  c-util.clisp: c-util.boot
  	@ echo 148 making $@ from $<
--- 1336,1341 ----
*************** ${AUTO}/nag-c02.$(OBJEXT): nag-c02.$(OBJ
*** 1403,1418 ****
  	@ cp nag-c02.$(OBJEXT) ${AUTO}
  
  @
- <<nag-c02.o (OUT from MID)>>=
- nag-c02.$(OBJEXT): nag-c02.clisp
- 	@ echo 151 making nag-c02.$(OBJEXT) from nag-c02.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
-            echo '(progn  (compile-file "nag-c02.clisp" :output-file "nag-c02.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
-            echo '(progn  (compile-file "nag-c02.clisp" :output-file "nag-c02.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<nag-c02.clisp>>=
  nag-c02.clisp: nag-c02.boot
  	@ echo 152 making $@ from $<
--- 1355,1360 ----
*************** ${AUTO}/nag-c05.$(OBJEXT): nag-c05.$(OBJ
*** 1432,1447 ****
  	@ cp nag-c05.$(OBJEXT) ${AUTO}
  
  @
- <<nag-c05.o (OUT from MID)>>=
- nag-c05.$(OBJEXT): nag-c05.clisp
- 	@ echo 155 making nag-c05.$(OBJEXT) from nag-c05.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "nag-c05.clisp" :output-file "nag-c05.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "nag-c05.clisp" :output-file "nag-c05.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<nag-c05.clisp>>=
  nag-c05.clisp: nag-c05.boot
  	@ echo 156 making $@ from $<
--- 1374,1379 ----
*************** ${AUTO}/nag-c06.$(OBJEXT): nag-c06.$(OBJ
*** 1461,1476 ****
  	@ cp nag-c06.$(OBJEXT) ${AUTO}
  
  @
- <<nag-c06.o (OUT from MID)>>=
- nag-c06.$(OBJEXT): nag-c06.clisp
- 	@ echo 159 making nag-c06.$(OBJEXT) from nag-c06.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "nag-c06.clisp" :output-file "nag-c06.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "nag-c06.clisp" :output-file "nag-c06.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<nag-c06.clisp>>=
  nag-c06.clisp: nag-c06.boot
  	@ echo 160 making $@ from $<
--- 1393,1398 ----
*************** ${AUTO}/nag-d01.$(OBJEXT): nag-d01.$(OBJ
*** 1490,1505 ****
  	@ cp nag-d01.$(OBJEXT) ${AUTO}
  
  @
- <<nag-d01.o (OUT from MID)>>=
- nag-d01.$(OBJEXT): nag-d01.clisp
- 	@ echo 163 making nag-d01.$(OBJEXT) from nag-d01.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "nag-d01.clisp" :output-file "nag-d01.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "nag-d01.clisp" :output-file "nag-d01.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<nag-d01.clisp>>=
  nag-d01.clisp: nag-d01.boot
  	@ echo 164 making $@ from $<
--- 1412,1417 ----
*************** ${AUTO}/nag-d02.$(OBJEXT): nag-d02.$(OBJ
*** 1519,1534 ****
  	@ cp nag-d02.$(OBJEXT) ${AUTO}
  
  @
- <<nag-d02.o (OUT from MID)>>=
- nag-d02.$(OBJEXT): nag-d02.clisp
- 	@ echo 167 making nag-d02.$(OBJEXT) from nag-d02.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
-            echo '(progn  (compile-file "nag-d02.clisp" :output-file "nag-d02.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
-            echo '(progn  (compile-file "nag-d02.clisp" :output-file "nag-d02.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<nag-d02.clisp>>=
  nag-d02.clisp: nag-d02.boot
  	@ echo 168 making $@ from $<
--- 1431,1436 ----
*************** ${AUTO}/nag-d03.$(OBJEXT): nag-d03.$(OBJ
*** 1548,1563 ****
  	@ cp nag-d03.$(OBJEXT) ${AUTO}
  
  @
- <<nag-d03.o (OUT from MID)>>=
- nag-d03.$(OBJEXT): nag-d03.clisp
- 	@ echo 171 making nag-d03.$(OBJEXT) from nag-d03.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
-            echo '(progn  (compile-file "nag-d03.clisp" :output-file "nag-d03.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
-            echo '(progn  (compile-file "nag-d03.clisp" :output-file "nag-d03.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<nag-d03.clisp>>=
  nag-d03.clisp: nag-d03.boot
  	@ echo 172 making $@ from $<
--- 1450,1455 ----
*************** ${AUTO}/nag-e01.$(OBJEXT): nag-e01.$(OBJ
*** 1577,1592 ****
  	@ cp nag-e01.$(OBJEXT) ${AUTO}
  
  @
- <<nag-e01.o (OUT from MID)>>=
- nag-e01.$(OBJEXT): nag-e01.clisp
- 	@ echo 175 making nag-e01.$(OBJEXT) from nag-e01.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "nag-e01.clisp" :output-file "nag-e01.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "nag-e01.clisp" :output-file "nag-e01.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<nag-e01.clisp>>=
  nag-e01.clisp: nag-e01.boot
  	@ echo 176 making $@ from $<
--- 1469,1474 ----
*************** ${AUTO}/nag-e02.$(OBJEXT): nag-e02.$(OBJ
*** 1606,1621 ****
  	@ cp nag-e02.$(OBJEXT) ${AUTO}
  
  @
- <<nag-e02.o (OUT from MID)>>=
- nag-e02.$(OBJEXT): nag-e02.clisp
- 	@ echo 183 making nag-e02.$(OBJEXT) from nag-e02.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "nag-e02.clisp" :output-file "nag-e02.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "nag-e02.clisp" :output-file "nag-e02.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<nag-e02.clisp>>=
  nag-e02.clisp: nag-e02.boot
  	@ echo 184 making $@ from $<
--- 1488,1493 ----
*************** ${AUTO}/nag-e04.$(OBJEXT): nag-e04.$(OBJ
*** 1635,1650 ****
  	@ cp nag-e04.$(OBJEXT) ${AUTO}
  
  @
- <<nag-e04.o (OUT from MID)>>=
- nag-e04.$(OBJEXT): nag-e04.clisp
- 	@ echo 187 making nag-e04.$(OBJEXT) from nag-e04.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
-            echo '(progn  (compile-file "nag-e04.clisp" :output-file "nag-e04.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
-            echo '(progn  (compile-file "nag-e04.clisp" :output-file "nag-e04.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<nag-e04.clisp>>=
  nag-e04.clisp: nag-e04.boot
  	@ echo 188 making $@ from $<
--- 1507,1512 ----
*************** ${AUTO}/nag-f01.$(OBJEXT): nag-f01.$(OBJ
*** 1664,1679 ****
  	@ cp nag-f01.$(OBJEXT) ${AUTO}
  
  @
- <<nag-f01.o (OUT from MID)>>=
- nag-f01.$(OBJEXT): nag-f01.clisp
- 	@ echo 191 making nag-f01.$(OBJEXT) from nag-f01.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
-            echo '(progn  (compile-file "nag-f01.clisp" :output-file "nag-f01.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
-            echo '(progn  (compile-file "nag-f01.clisp" :output-file "nag-f01.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<nag-f01.clisp>>=
  nag-f01.clisp: nag-f01.boot
  	@ echo 192 making $@ from $<
--- 1526,1531 ----
*************** ${AUTO}/nag-f02.$(OBJEXT): nag-f02.$(OBJ
*** 1693,1708 ****
  	@ cp nag-f02.$(OBJEXT) ${AUTO}
  
  @
- <<nag-f02.o (OUT from MID)>>=
- nag-f02.$(OBJEXT): nag-f02.clisp
- 	@ echo 195 making nag-f02.$(OBJEXT) from nag-f02.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
-            echo '(progn  (compile-file "nag-f02.clisp" :output-file "nag-f02.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
-            echo '(progn  (compile-file "nag-f02.clisp" :output-file "nag-f02.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<nag-f02.clisp>>=
  nag-f02.clisp: nag-f02.boot
  	@ echo 196 making $@ from $<
--- 1545,1550 ----
*************** ${AUTO}/nag-f04.$(OBJEXT): nag-f04.$(OBJ
*** 1722,1737 ****
  	@ cp nag-f04.$(OBJEXT) ${AUTO}
  
  @
- <<nag-f04.o (OUT from MID)>>=
- nag-f04.$(OBJEXT): nag-f04.clisp
- 	@ echo 199 making nag-f04.$(OBJEXT) from nag-f04.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "nag-f04.clisp" :output-file "nag-f04.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "nag-f04.clisp" :output-file "nag-f04.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<nag-f04.clisp>>=
  nag-f04.clisp: nag-f04.boot
  	@ echo 200 making $@ from $<
--- 1564,1569 ----
*************** ${AUTO}/nag-f07.$(OBJEXT): nag-f07.$(OBJ
*** 1751,1766 ****
  	@ cp nag-f07.$(OBJEXT) ${AUTO}
  
  @
- <<nag-f07.o (OUT from MID)>>=
- nag-f07.$(OBJEXT): nag-f07.clisp
- 	@ echo 203 making nag-f07.$(OBJEXT) from nag-f07.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
-            echo '(progn  (compile-file "nag-f07.clisp" :output-file "nag-f07.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
-            echo '(progn  (compile-file "nag-f07.clisp" :output-file "nag-f07.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<nag-f07.clisp>>=
  nag-f07.clisp: nag-f07.boot
  	@ echo 204 making $@ from $<
--- 1583,1588 ----
*************** ${AUTO}/nag-s.$(OBJEXT): nag-s.$(OBJEXT)
*** 1780,1795 ****
  	@ cp nag-s.$(OBJEXT) ${AUTO}
  
  @
- <<nag-s.o (OUT from MID)>>=
- nag-s.$(OBJEXT): nag-s.clisp
- 	@ echo 207 making nag-s.$(OBJEXT) from nag-s.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "nag-s.clisp" :output-file "nag-s.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "nag-s.clisp" :output-file "nag-s.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<nag-s.clisp>>=
  nag-s.clisp: nag-s.boot
  	@ echo 208 making $@ from $<
--- 1602,1607 ----
*************** ${AUTO}/category.$(OBJEXT): category.$(O
*** 1809,1824 ****
  	@ cp category.$(OBJEXT) ${AUTO}
  
  @
- <<category.o (OUT from MID)>>=
- category.$(OBJEXT): category.clisp 
- 	@ echo 211 making category.$(OBJEXT) from category.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "category.clisp" :output-file "category.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "category.clisp" :output-file "category.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<category.clisp>>=
  category.clisp: category.boot
  	@ echo 212 making $@ from $<
--- 1621,1626 ----
*************** category.clisp: category.boot
*** 1832,1847 ****
  
  \subsection{cattable.boot \cite{59}}
  
- <<cattable.o (OUT from MID)>>=
- cattable.$(OBJEXT): cattable.clisp 
- 	@ echo 214 making cattable.$(OBJEXT) from cattable.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "cattable.clisp" :output-file "cattable.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "cattable.clisp" :output-file "cattable.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<cattable.clisp>>=
  cattable.clisp: cattable.boot
  	@ echo 215 making $@ from $<
--- 1634,1639 ----
*************** ${AUTO}/c-doc.$(OBJEXT): c-doc.$(OBJEXT)
*** 1861,1876 ****
  	@ cp c-doc.$(OBJEXT) ${AUTO}
  
  @
- <<c-doc.o (OUT from MID)>>=
- c-doc.$(OBJEXT): c-doc.clisp 
- 	@ echo 218 making c-doc.$(OBJEXT) from c-doc.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "c-doc.clisp" :output-file "c-doc.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "c-doc.clisp" :output-file "c-doc.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<c-doc.clisp>>=
  c-doc.clisp: c-doc.boot
  	@ echo 219 making $@ from $<
--- 1653,1658 ----
*************** clam.${LISP}: $(srcdir)/clam.boot.pamphl
*** 1900,1915 ****
  	$(axiom_build_document) --tangle=clam.clisp --output=$@ $<
  @
  
- <<clam.o (OUT from MID)>>=
- clam.$(OBJEXT): clam.clisp 
- 	@ echo 222 making clam.$(OBJEXT) from clam.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "clam.clisp" :output-file "clam.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "clam.clisp" :output-file "clam.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<clam.clisp>>=
  clam.clisp: clam.boot
  	@ echo 223 making $@ from $<
--- 1682,1687 ----
*************** clam.clisp: clam.boot
*** 1923,1938 ****
  
  \subsection{clammed.boot \cite{62}}
  
- <<clammed.o (OUT from MID)>>=
- clammed.$(OBJEXT): clammed.clisp 
- 	@ echo 225 making clammed.$(OBJEXT) from clammed.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "clammed.clisp" :output-file "clammed.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "clammed.clisp" :output-file "clammed.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<clammed.clisp>>=
  clammed.clisp: clammed.boot
  	@ echo 226 making $@ from $<
--- 1695,1700 ----
*************** clammed.clisp: clammed.boot
*** 1946,1961 ****
  
  \subsection{compat.boot \cite{63}}
  
- <<compat.o (OUT from MID)>>=
- compat.$(OBJEXT): compat.clisp 
- 	@ echo 228 making compat.$(OBJEXT) from compat.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "compat.clisp" :output-file "compat.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "compat.clisp" :output-file "compat.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<compat.clisp>>=
  compat.clisp: compat.boot
  	@ echo 229 making $@ from $<
--- 1708,1713 ----
*************** ${AUTO}/compiler.$(OBJEXT): compiler.$(O
*** 1975,1990 ****
  	@ cp compiler.$(OBJEXT) ${AUTO}
  
  @
- <<compiler.o (OUT from MID)>>=
- compiler.$(OBJEXT): compiler.clisp 
- 	@ echo 232 making compiler.$(OBJEXT) from compiler.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "compiler.clisp" :output-file "compiler.$(OBJEXT)"))' | ${DEPSYS} ; \
-           else \
- 	   echo '(progn  (compile-file "compiler.clisp" :output-file "compiler.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<compiler.clisp>>=
  compiler.clisp: compiler.boot
  	@ echo 233 making $@ from $<
--- 1727,1732 ----
*************** ${AUTO}/profile.$(OBJEXT): profile.$(OBJ
*** 2004,2019 ****
  	@ cp profile.$(OBJEXT) ${AUTO}
  
  @
- <<profile.o (OUT from MID)>>=
- profile.$(OBJEXT): profile.clisp 
- 	@ echo 236 making profile.$(OBJEXT) from profile.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "profile.clisp" :output-file "profile.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "profile.clisp" :output-file "profile.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<profile.clisp>>=
  profile.clisp: profile.boot
  	@ echo 237 making $@ from $<
--- 1746,1751 ----
*************** profile.clisp: profile.boot
*** 2029,2040 ****
  
  <<compress.o (OUT from MID)>>=
  compress.$(OBJEXT): compress.clisp 
! 	@ echo 239 making compress.$(OBJEXT) from compress.clisp
! 	@ if [ -z "${NOISE}" ] ; then \
! 	   echo '(progn  (compile-file "compress.clisp" :output-file "compress.$(OBJEXT)"))' | ${DEPSYS} ; \
! 	  else \
! 	   echo '(progn  (compile-file "compress.clisp" :output-file "compress.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
! 	  fi
  
  @
  <<compress.clisp>>=
--- 1761,1767 ----
  
  <<compress.o (OUT from MID)>>=
  compress.$(OBJEXT): compress.clisp 
! 	$(COMPILE_LISP)
  
  @
  <<compress.clisp>>=
*************** compress.clisp: compress.boot
*** 2050,2065 ****
  
  \subsection{database.boot \cite{67}}
  
- <<database.o (OUT from MID)>>=
- database.$(OBJEXT): database.clisp 
- 	@ echo 242 making database.$(OBJEXT) from database.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "database.clisp" :output-file "database.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "database.clisp" :output-file "database.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<database.clisp>>=
  database.clisp: database.boot
  	@ echo 243 making $@ from $<
--- 1777,1782 ----
*************** ${AUTO}/define.$(OBJEXT): define.$(OBJEX
*** 2079,2094 ****
  	@ cp define.$(OBJEXT) ${AUTO}
  
  @
- <<define.o (OUT from MID)>>=
- define.$(OBJEXT): define.clisp 
- 	@ echo 246 making define.$(OBJEXT) from define.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "define.clisp" :output-file "define.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "define.clisp" :output-file "define.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<define.clisp>>=
  define.clisp: define.boot
  	@ echo 247 making $@ from $<
--- 1796,1801 ----
*************** define.clisp: define.boot
*** 2102,2117 ****
  
  \subsection{format.boot}
  
- <<format.o (OUT from MID)>>=
- format.$(OBJEXT): format.clisp 
- 	@ echo 249 making format.$(OBJEXT) from format.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "format.clisp" :output-file "format.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "format.clisp" :output-file "format.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<format.clisp>>=
  format.clisp: format.boot
  	@ echo 250 making $@ from $<
--- 1809,1814 ----
*************** ${AUTO}/functor.$(OBJEXT): functor.$(OBJ
*** 2131,2146 ****
  	@ cp functor.$(OBJEXT) ${AUTO}
  
  @
- <<functor.o (OUT from MID)>>=
- functor.$(OBJEXT): functor.clisp 
- 	@ echo 253 making functor.$(OBJEXT) from functor.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "functor.clisp" :output-file "functor.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "functor.clisp" :output-file "functor.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<functor.clisp>>=
  functor.clisp: functor.boot
  	@ echo 254 making $@ from $<
--- 1828,1833 ----
*************** g-boot.${LISP}: $(srcdir)/g-boot.boot.pa
*** 2169,2184 ****
  	@ rm -f g-boot.$(OBJEXT)
  	$(axiom_build_document) --tangle=g-boot.clisp --output=$@ $<
  @
- <<g-boot.o (OUT from MID)>>=
- g-boot.$(OBJEXT): g-boot.clisp 
- 	@ echo 257 making g-boot.$(OBJEXT) from g-boot.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "g-boot.clisp" :output-file "g-boot.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "g-boot.clisp" :output-file "g-boot.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<g-boot.clisp>>=
  g-boot.clisp: g-boot.boot
  	@ echo 258 making $@ from $<
--- 1856,1861 ----
*************** g-boot.clisp: g-boot.boot
*** 2192,2207 ****
  
  \subsection{g-cndata.boot}
  
- <<g-cndata.o (OUT from MID)>>=
- g-cndata.$(OBJEXT): g-cndata.clisp 
- 	@ echo 260 making g-cndata.$(OBJEXT) from g-cndata.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "g-cndata.clisp" :output-file "g-cndata.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "g-cndata.clisp" :output-file "g-cndata.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<g-cndata.clisp>>=
  g-cndata.clisp: g-cndata.boot
  	@ echo 261 making $@ from $<
--- 1869,1874 ----
*************** g-cndata.clisp: g-cndata.boot
*** 2215,2230 ****
  
  \subsection{g-error.boot}
  
- <<g-error.o (OUT from MID)>>=
- g-error.$(OBJEXT): g-error.clisp 
- 	@ echo 263 making g-error.$(OBJEXT) from g-error.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "g-error.clisp" :output-file "g-error.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "g-error.clisp" :output-file "g-error.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<g-error.clisp>>=
  g-error.clisp: g-error.boot
  	@ echo 264 making $@ from $<
--- 1882,1887 ----
*************** g-error.clisp: g-error.boot
*** 2238,2253 ****
  
  \subsection{g-opt.boot}
  
- <<g-opt.o (OUT from MID)>>=
- g-opt.$(OBJEXT): g-opt.clisp 
- 	@ echo 266 making g-opt.$(OBJEXT) from g-opt.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "g-opt.clisp" :output-file "g-opt.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "g-opt.clisp" :output-file "g-opt.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<g-opt.clisp>>=
  g-opt.clisp: g-opt.boot
  	@ echo 267 making $@ from $<
--- 1895,1900 ----
*************** g-opt.clisp: g-opt.boot
*** 2261,2276 ****
  
  \subsection{g-timer.boot}
  
- <<g-timer.o (OUT from MID)>>=
- g-timer.$(OBJEXT): g-timer.clisp 
- 	@ echo 269 making g-timer.$(OBJEXT) from g-timer.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "g-timer.clisp" :output-file "g-timer.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "g-timer.clisp" :output-file "g-timer.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<g-timer.clisp>>=
  g-timer.clisp: g-timer.boot
  	@ echo 270 making $@ from $<
--- 1908,1913 ----
*************** g-util.${LISP}: $(srcdir)/g-util.boot.pa
*** 2299,2314 ****
  	@ rm -f g-util.$(OBJEXT)
  	$(axiom_build_document) --tangle=g-util.clisp --output=$@ $<
  @
- <<g-util.o (OUT from MID)>>=
- g-util.$(OBJEXT): g-util.clisp 
- 	@ echo 273 making g-util.$(OBJEXT) from g-util.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "g-util.clisp" :output-file "g-util.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "g-util.clisp" :output-file "g-util.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<g-util.clisp>>=
  g-util.clisp: g-util.boot
  	@ echo 274 making $@ from $<
--- 1936,1941 ----
*************** g-util.clisp: g-util.boot
*** 2322,2337 ****
  
  \subsection{hypertex.boot}
  
- <<hypertex.o (OUT from MID)>>=
- hypertex.$(OBJEXT): hypertex.clisp 
- 	@ echo 276 making hypertex.$(OBJEXT) from hypertex.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "hypertex.clisp" :output-file "hypertex.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "hypertex.clisp" :output-file "hypertex.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<hypertex.clisp>>=
  hypertex.clisp: hypertex.boot
  	@ echo 277 making $@ from $<
--- 1949,1954 ----
*************** hypertex.clisp: hypertex.boot
*** 2345,2360 ****
  
  \subsection{i-analy.boot}
  
- <<i-analy.o (OUT from MID)>>=
- i-analy.$(OBJEXT): i-analy.clisp 
- 	@ echo 279 making i-analy.$(OBJEXT) from i-analy.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "i-analy.clisp" :output-file "i-analy.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "i-analy.clisp" :output-file "i-analy.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<i-analy.clisp>>=
  i-analy.clisp: i-analy.boot
  	@ echo 280 making $@ from $<
--- 1962,1967 ----
*************** i-analy.clisp: i-analy.boot
*** 2368,2383 ****
  
  \subsection{i-code.boot}
  
- <<i-code.o (OUT from MID)>>=
- i-code.$(OBJEXT): i-code.clisp 
- 	@ echo 282 making i-code.$(OBJEXT) from i-code.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "i-code.clisp" :output-file "i-code.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "i-code.clisp" :output-file "i-code.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<i-code.clisp>>=
  i-code.clisp: i-code.boot
  	@ echo 283 making $@ from $<
--- 1975,1980 ----
*************** i-code.clisp: i-code.boot
*** 2391,2406 ****
  
  \subsection{i-coerce.boot}
  
- <<i-coerce.o (OUT from MID)>>=
- i-coerce.$(OBJEXT): i-coerce.clisp 
- 	@ echo 285 making i-coerce.$(OBJEXT) from i-coerce.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "i-coerce.clisp" :output-file "i-coerce.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "i-coerce.clisp" :output-file "i-coerce.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<i-coerce.clisp>>=
  i-coerce.clisp: i-coerce.boot
  	@ echo 286 making $@ from $<
--- 1988,1993 ----
*************** i-coerce.clisp: i-coerce.boot
*** 2414,2429 ****
  
  \subsection{i-coerfn.boot}
  
- <<i-coerfn.o (OUT from MID)>>=
- i-coerfn.$(OBJEXT): i-coerfn.clisp 
- 	@ echo 288 making i-coerfn.$(OBJEXT) from i-coerfn.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "i-coerfn.clisp" :output-file "i-coerfn.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "i-coerfn.clisp" :output-file "i-coerfn.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<i-coerfn.clisp>>=
  i-coerfn.clisp: i-coerfn.boot
  	@ echo 289 making $@ from $<
--- 2001,2006 ----
*************** i-coerfn.clisp: i-coerfn.boot
*** 2437,2452 ****
  
  \subsection{i-eval.boot}
  
- <<i-eval.o (OUT from MID)>>=
- i-eval.$(OBJEXT): i-eval.clisp 
- 	@ echo 291 making i-eval.$(OBJEXT) from i-eval.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "i-eval.clisp" :output-file "i-eval.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "i-eval.clisp" :output-file "i-eval.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<i-eval.clisp>>=
  i-eval.clisp: i-eval.boot
  	@ echo 292 making $@ from $<
--- 2014,2019 ----
*************** i-eval.clisp: i-eval.boot
*** 2460,2475 ****
  
  \subsection{i-funsel.boot}
  
- <<i-funsel.o (OUT from MID)>>=
- i-funsel.$(OBJEXT): i-funsel.clisp 
- 	@ echo 294 making i-funsel.$(OBJEXT) from i-funsel.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "i-funsel.clisp" :output-file "i-funsel.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "i-funsel.clisp" :output-file "i-funsel.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<i-funsel.clisp>>=
  i-funsel.clisp: i-funsel.boot
  	@ echo 295 making $@ from $<
--- 2027,2032 ----
*************** i-funsel.clisp: i-funsel.boot
*** 2483,2498 ****
  
  \subsection{bookvol5.lsp}
  
- <<bookvol5.o (OUT from MID)>>=
- bookvol5.$(OBJEXT): bookvol5.lisp
- 	@ echo 297 making $@ from $<
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "bookvol5.lisp" :output-file "bookvol5.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "bookvol5.lisp" :output-file "bookvol5.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  
  <<bookvol5.lisp>>=
  bookvol5.lisp: $(srcdir)/bookvol5.pamphlet
--- 2040,2045 ----
*************** bookvol5.lisp: $(srcdir)/bookvol5.pamphl
*** 2502,2517 ****
  
  \subsection{i-intern.boot}
  
- <<i-intern.o (OUT from MID)>>=
- i-intern.$(OBJEXT): i-intern.clisp 
- 	@ echo 300 making i-intern.$(OBJEXT) from i-intern.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "i-intern.clisp" :output-file "i-intern.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "i-intern.clisp" :output-file "i-intern.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	 fi
- 
- @
  <<i-intern.clisp>>=
  i-intern.clisp: i-intern.boot
  	@ echo 301 making $@ from $<
--- 2049,2054 ----
*************** i-intern.clisp: i-intern.boot
*** 2525,2540 ****
  
  \subsection{i-map.boot}
  
- <<i-map.o (OUT from MID)>>=
- i-map.$(OBJEXT): i-map.clisp 
- 	@ echo 303 making i-map.$(OBJEXT) from i-map.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "i-map.clisp" :output-file "i-map.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "i-map.clisp" :output-file "i-map.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<i-map.clisp>>=
  i-map.clisp: i-map.boot
  	@ echo 304 making $@ from $<
--- 2062,2067 ----
*************** i-map.clisp: i-map.boot
*** 2548,2563 ****
  
  \subsection{i-output.boot}
  
- <<i-output.o (OUT from MID)>>=
- i-output.$(OBJEXT): i-output.clisp 
- 	@ echo 306 making i-output.$(OBJEXT) from i-output.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "i-output.clisp" :output-file "i-output.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "i-output.clisp" :output-file "i-output.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<i-output.clisp>>=
  i-output.clisp: i-output.boot
  	@ echo 307 making $@ from $<
--- 2075,2080 ----
*************** i-output.clisp: i-output.boot
*** 2571,2586 ****
  
  \subsection{i-resolv.boot}
  
- <<i-resolv.o (OUT from MID)>>=
- i-resolv.$(OBJEXT): i-resolv.clisp 
- 	@ echo 309 making i-resolv.$(OBJEXT) from i-resolv.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "i-resolv.clisp" :output-file "i-resolv.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "i-resolv.clisp" :output-file "i-resolv.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<i-resolv.clisp>>=
  i-resolv.clisp: i-resolv.boot
  	@ echo 310 making $@ from $<
--- 2088,2093 ----
*************** i-resolv.clisp: i-resolv.boot
*** 2594,2609 ****
  
  \subsection{i-spec1.boot}
  
- <<i-spec1.o (OUT from MID)>>=
- i-spec1.$(OBJEXT): i-spec1.clisp 
- 	@ echo 312 making i-spec1.$(OBJEXT) from i-spec1.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "i-spec1.clisp" :output-file "i-spec1.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "i-spec1.clisp" :output-file "i-spec1.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<i-spec1.clisp>>=
  i-spec1.clisp: i-spec1.boot
  	@ echo 313 making $@ from $<
--- 2101,2106 ----
*************** i-spec1.clisp: i-spec1.boot
*** 2617,2632 ****
  
  \subsection{i-spec2.boot}
  
- <<i-spec2.o (OUT from MID)>>=
- i-spec2.$(OBJEXT): i-spec2.clisp 
- 	@ echo 315 making i-spec2.$(OBJEXT) from i-spec2.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "i-spec2.clisp" :output-file "i-spec2.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "i-spec2.clisp" :output-file "i-spec2.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<i-spec2.clisp>>=
  i-spec2.clisp: i-spec2.boot
  	@ echo 316 making $@ from i-spec2.boot
--- 2114,2119 ----
*************** i-spec2.clisp: i-spec2.boot
*** 2640,2655 ****
  
  \subsection{i-syscmd.boot}
  
- <<i-syscmd.o (OUT from MID)>>=
- i-syscmd.$(OBJEXT): i-syscmd.clisp 
- 	@ echo 318 making i-syscmd.$(OBJEXT) from i-syscmd.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "i-syscmd.clisp" :output-file "i-syscmd.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "i-syscmd.clisp" :output-file "i-syscmd.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<i-syscmd.clisp>>=
  i-syscmd.clisp: i-syscmd.boot
  	@ echo 319 making $@ from $<
--- 2127,2132 ----
*************** i-syscmd.clisp: i-syscmd.boot
*** 2663,2678 ****
  
  \subsection{i-toplev.boot}
  
- <<i-toplev.o (OUT from MID)>>=
- i-toplev.$(OBJEXT): i-toplev.clisp 
- 	@ echo 321 making i-toplev.$(OBJEXT) from i-toplev.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "i-toplev.clisp" :output-file "i-toplev.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "i-toplev.clisp" :output-file "i-toplev.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
-           fi
- 
- @
  <<i-toplev.clisp>>=
  i-toplev.clisp: i-toplev.boot
  	@ echo 322 making $@ from $<
--- 2140,2145 ----
*************** i-toplev.clisp: i-toplev.boot
*** 2686,2701 ****
  
  \subsection{i-util.boot}
  
- <<i-util.o (OUT from MID)>>=
- i-util.$(OBJEXT): i-util.clisp 
- 	@ echo 324 making i-util.$(OBJEXT) from i-util.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "i-util.clisp" :output-file "i-util.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "i-util.clisp" :output-file "i-util.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
-           fi
- 
- @
  <<i-util.clisp>>=
  i-util.clisp: i-util.boot
  	@ echo 325 making $@ from $<
--- 2153,2158 ----
*************** ${AUTO}/info.$(OBJEXT): info.$(OBJEXT)
*** 2715,2730 ****
  	@ cp info.$(OBJEXT) ${AUTO}
  
  @
- <<info.o (OUT from MID)>>=
- info.$(OBJEXT): info.clisp 
- 	@ echo 328 making info.$(OBJEXT) from info.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "info.clisp" :output-file "info.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "info.clisp" :output-file "info.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<info.clisp>>=
  info.clisp: info.boot
  	@ echo 329 making $@ from $<
--- 2172,2177 ----
*************** ${AUTO}/iterator.$(OBJEXT): iterator.$(O
*** 2744,2759 ****
  	@ cp iterator.$(OBJEXT) ${AUTO}
  
  @
- <<iterator.o (OUT from MID)>>=
- iterator.$(OBJEXT): iterator.clisp 
- 	@ echo 332 making iterator.$(OBJEXT) from iterator.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "iterator.clisp" :output-file "iterator.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "iterator.clisp" :output-file "iterator.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<iterator.clisp>>=
  iterator.clisp: iterator.boot
  	@ echo 333 making $@ from $<
--- 2191,2196 ----
*************** iterator.clisp: iterator.boot
*** 2767,2782 ****
  
  \subsection{lisplib.boot}
  
- <<lisplib.o (OUT from MID)>>=
- lisplib.$(OBJEXT): lisplib.clisp 
- 	@ echo 335 making lisplib.$(OBJEXT) from lisplib.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "lisplib.clisp" :output-file "lisplib.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "lisplib.clisp" :output-file "lisplib.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<lisplib.clisp>>=
  lisplib.clisp: lisplib.boot
  	@ echo 336 making $@ from $<
--- 2204,2209 ----
*************** lisplib.clisp: lisplib.boot
*** 2790,2805 ****
  
  \subsection{match.boot}
  
- <<match.o (OUT from MID)>>=
- match.$(OBJEXT): match.clisp 
- 	@ echo 338 making match.$(OBJEXT) from match.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "match.clisp" :output-file "match.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "match.clisp" :output-file "match.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<match.clisp>>=
  match.clisp: match.boot
  	@ echo 339 making $@ from $<
--- 2217,2222 ----
*************** ${AUTO}/modemap.$(OBJEXT): modemap.$(OBJ
*** 2819,2834 ****
  	@ cp modemap.$(OBJEXT) ${AUTO}
  
  @
- <<modemap.o (OUT from MID)>>=
- modemap.$(OBJEXT): modemap.clisp 
- 	@ echo 342 making modemap.$(OBJEXT) from modemap.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "modemap.clisp" :output-file "modemap.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "modemap.clisp" :output-file "modemap.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<modemap.clisp>>=
  modemap.clisp: modemap.boot
  	@ echo 343 making $@ from $<
--- 2236,2241 ----
*************** modemap.clisp: modemap.boot
*** 2842,2857 ****
  
  \subsection{msgdb.boot}
  
- <<msgdb.o (OUT from MID)>>=
- msgdb.$(OBJEXT): msgdb.clisp 
- 	@ echo 345 making msgdb.$(OBJEXT) from msgdb.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "msgdb.clisp" :output-file "msgdb.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "msgdb.clisp" :output-file "msgdb.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<msgdb.clisp>>=
  msgdb.clisp: msgdb.boot
  	@ echo 346 making $@ from $<
--- 2249,2254 ----
*************** msgdb.clisp: msgdb.boot
*** 2865,2880 ****
  
  \subsection{newfort.boot}
  
- <<newfort.o (OUT from MID)>>=
- newfort.$(OBJEXT): newfort.clisp 
- 	@ echo 348 making newfort.$(OBJEXT) from newfort.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "newfort.clisp" :output-file "newfort.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "newfort.clisp" :output-file "newfort.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<newfort.clisp>>=
  newfort.clisp: newfort.boot
  	@ echo 349 making $@ from $<
--- 2262,2267 ----
*************** ${AUTO}/nruncomp.$(OBJEXT): nruncomp.$(O
*** 2894,2909 ****
  	@ cp nruncomp.$(OBJEXT) ${AUTO}
  
  @
- <<nruncomp.o (OUT from MID)>>=
- nruncomp.$(OBJEXT): nruncomp.clisp 
- 	@ echo 352 making nruncomp.$(OBJEXT) from nruncomp.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "nruncomp.clisp" :output-file "nruncomp.$(OBJEXT)"))' |  ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "nruncomp.clisp" :output-file "nruncomp.$(OBJEXT)"))' |  ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<nruncomp.clisp>>=
  nruncomp.clisp: nruncomp.boot
  	@ echo 353 making $@ from $<
--- 2281,2286 ----
*************** nruncomp.clisp: nruncomp.boot
*** 2917,2932 ****
  
  \subsection{nrunfast.boot}
  
- <<nrunfast.o (OUT from MID)>>=
- nrunfast.$(OBJEXT): nrunfast.clisp 
- 	@ echo 355 making nrunfast.$(OBJEXT) from nrunfast.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "nrunfast.clisp" :output-file "nrunfast.$(OBJEXT)"))' |  ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "nrunfast.clisp" :output-file "nrunfast.$(OBJEXT)"))' |  ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<nrunfast.clisp>>=
  nrunfast.clisp: nrunfast.boot
  	@ echo 356 making $@ from $<
--- 2294,2299 ----
*************** nrunfast.clisp: nrunfast.boot
*** 2940,2955 ****
  
  \subsection{nrungo.boot}
  
- <<nrungo.o (OUT from MID)>>=
- nrungo.$(OBJEXT): nrungo.clisp 
- 	@ echo 358 making nrungo.$(OBJEXT) from nrungo.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "nrungo.clisp" :output-file "nrungo.$(OBJEXT)"))' |  ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "nrungo.clisp" :output-file "nrungo.$(OBJEXT)"))' |  ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<nrungo.clisp>>=
  nrungo.clisp: nrungo.boot
  	@ echo 359 making $@ from $<
--- 2307,2312 ----
*************** nrungo.clisp: nrungo.boot
*** 2963,2978 ****
  
  \subsection{nruntime.boot}
  
- <<nruntime.o (OUT from MID)>>=
- nruntime.$(OBJEXT): nruntime.clisp 
- 	@ echo 361 making nruntime.$(OBJEXT) from nruntime.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "nruntime.clisp" :output-file "nruntime.$(OBJEXT)"))' |  ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "nruntime.clisp" :output-file "nruntime.$(OBJEXT)"))' |  ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<nruntime.clisp>>=
  nruntime.clisp: nruntime.boot
  	@ echo 362 making $@ from $<
--- 2320,2325 ----
*************** nruntime.clisp: nruntime.boot
*** 2986,3001 ****
  
  \subsection{nrunopt.boot}
  
- <<nrunopt.o (OUT from MID)>>=
- nrunopt.$(OBJEXT): nrunopt.clisp 
- 	@ echo 364 making nrunopt.$(OBJEXT) from nrunopt.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "nrunopt.clisp" :output-file "nrunopt.$(OBJEXT)"))' |  ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "nrunopt.clisp" :output-file "nrunopt.$(OBJEXT)"))' |  ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<nrunopt.clisp>>=
  nrunopt.clisp: nrunopt.boot
  	@ echo 365 making $@ from $<
--- 2333,2338 ----
*************** ${AUTO}/package.$(OBJEXT): package.$(OBJ
*** 3015,3030 ****
  	@ cp package.$(OBJEXT) ${AUTO}
  
  @
- <<package.o (OUT from MID)>>=
- package.$(OBJEXT): package.clisp 
- 	@ echo 371 making package.$(OBJEXT) from package.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "package.clisp" :output-file "package.$(OBJEXT)"))' |  ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "package.clisp" :output-file "package.$(OBJEXT)"))' |  ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<package.clisp>>=
  package.clisp: package.boot
  	@ echo 372 making $@ from $<
--- 2352,2357 ----
*************** ${AUTO}/parse.$(OBJEXT): parse.$(OBJEXT)
*** 3050,3065 ****
  	@ cp parse.$(OBJEXT) ${AUTO}
  
  @
- <<parse.o (OUT from MID)>>=
- parse.$(OBJEXT): parse.clisp 
- 	@ echo 375 making parse.$(OBJEXT) from parse.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "parse.clisp" :output-file "parse.$(OBJEXT)"))' |  ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "parse.clisp" :output-file "parse.$(OBJEXT)"))' |  ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
  
- @
  Note that the {\bf parse.boot.pamphlet} file contains both the
  original {\bf boot} code and a saved copy of the {\bf parse.clisp}
  code. We need to keep the translated code around so we can bootstrap
--- 2377,2383 ----
*************** two things need to be done to create an 
*** 3102,3117 ****
  if these two things are done then a obootsys image can be bootstrapped
  to a new platform.
  \end{verbatim}
- <<pathname.o (OUT from MID)>>=
- pathname.$(OBJEXT): pathname.clisp 
- 	@ echo 379 making pathname.$(OBJEXT) from pathname.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "pathname.clisp" :output-file "pathname.$(OBJEXT)"))' |  ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "pathname.clisp" :output-file "pathname.$(OBJEXT)"))' |  ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<pathname.clisp>>=
  pathname.clisp: pathname.boot
  	@ echo 380 making $@ from $<
--- 2420,2425 ----
*************** postpar.clisp: $(srcdir)/postpar.boot.pa
*** 3152,3167 ****
  	@ rm -f postpar.$(OBJEXT)
  	$(axiom_build_document) --tangle=postpar.clisp --output=$@ $<
  @
- <<postpar.o (OUT from MID)>>=
- postpar.$(OBJEXT): postpar.clisp 
- 	@ echo 384 making $@ from $<
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "postpar.clisp" :output-file "postpar.$(OBJEXT)"))' |  ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "postpar.clisp" :output-file "postpar.$(OBJEXT)"))' |  ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
  
- @
  \begin{verbatim}
  NOTE: the .clisp file is copies back into the src directory so that
  it is possible to create a new DEPSYS system from scratch for a 
--- 2460,2466 ----
*************** to a new platform.
*** 3189,3204 ****
  
  \subsection{rulesets.boot}
  
- <<rulesets.o (OUT from MID)>>=
- rulesets.$(OBJEXT): rulesets.clisp 
- 	@ echo 387 making rulesets.$(OBJEXT) from rulesets.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "rulesets.clisp" :output-file "rulesets.$(OBJEXT)"))' |  ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "rulesets.clisp" :output-file "rulesets.$(OBJEXT)"))' |  ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<rulesets.clisp>>=
  rulesets.clisp: rulesets.boot
  	@ echo 388 making $@ from $<
--- 2488,2493 ----
*************** rulesets.clisp: rulesets.boot
*** 3212,3227 ****
  
  \subsection{server.boot}
  
- <<server.o (OUT from MID)>>=
- server.$(OBJEXT): server.clisp 
- 	@ echo 390 making server.$(OBJEXT) from server.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "server.clisp" :output-file "server.$(OBJEXT)"))' |  ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "server.clisp" :output-file "server.$(OBJEXT)"))' |  ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<server.clisp>>=
  server.clisp: server.boot
  	@ echo 391 making $@ from $<
--- 2501,2506 ----
*************** setvars.${LISP}: $(srcdir)/setvars.boot.
*** 3250,3265 ****
  	@ rm -f setvars.$(OBJEXT)
  	$(axiom_build_document) --tangle=setvars.clisp --output=$@ S<
  @
- <<setvars.o (OUT from MID)>>=
- setvars.$(OBJEXT): setvars.clisp 
- 	@ echo 394 making setvars.$(OBJEXT) from setvars.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "setvars.clisp" :output-file "setvars.$(OBJEXT)"))' |  ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "setvars.clisp" :output-file "setvars.$(OBJEXT)"))' |  ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<setvars.clisp>>=
  setvars.clisp: setvars.boot
  	@ echo 395 making $@ from $<
--- 2529,2534 ----
*************** setvars.clisp: setvars.boot
*** 3273,3288 ****
  
  \subsection{setvart.boot}
  
- <<setvart.o (OUT from MID)>>=
- setvart.$(OBJEXT): setvart.clisp 
- 	@ echo 397 making setvart.$(OBJEXT) from setvart.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "setvart.clisp" :output-file "setvart.$(OBJEXT)"))' |  ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "setvart.clisp" :output-file "setvart.$(OBJEXT)"))' |  ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<setvart.clisp>>=
  setvart.clisp: setvart.boot
  	@ echo 398 making $@ from $<
--- 2542,2547 ----
*************** setvart.clisp: setvart.boot
*** 3296,3311 ****
  
  \subsection{simpbool.boot}
  
- <<simpbool.o (OUT from MID)>>=
- simpbool.$(OBJEXT): simpbool.clisp 
- 	@ echo 400 making simpbool.$(OBJEXT) from simpbool.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "simpbool.clisp" :output-file "simpbool.$(OBJEXT)"))' |  ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "simpbool.clisp" :output-file "simpbool.$(OBJEXT)"))' |  ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<simpbool.clisp>>=
  simpbool.clisp: simpbool.boot
  	@ echo 401 making $@ from $<
--- 2555,2560 ----
*************** slam.${LISP}: $(srcdir)/slam.boot.pamphl
*** 3334,3349 ****
  	@ rm -f slam.$(OBJEXT)
  	$(axiom_build_document) --tangle=slam.clisp --output=$@ $<
  @
- <<slam.o (OUT from MID)>>=
- slam.$(OBJEXT): slam.clisp 
- 	@ echo 404 making slam.$(OBJEXT) from slam.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "slam.clisp" :output-file "slam.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "slam.clisp" :output-file "slam.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<slam.clisp>>=
  slam.clisp: slam.boot
  	@ echo 405 making $@ from $<
--- 2583,2588 ----
*************** slam.clisp: slam.boot
*** 3357,3372 ****
  
  \subsection{template.boot}
  
- <<template.o (OUT from MID)>>=
- template.$(OBJEXT): template.clisp 
- 	@ echo 407 making template.$(OBJEXT) from template.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "template.clisp" :output-file "template.$(OBJEXT)"))' |  ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "template.clisp" :output-file "template.$(OBJEXT)"))' |  ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<template.clisp>>=
  template.clisp: template.boot
  	@ echo 408 making $@ from $<
--- 2596,2601 ----
*************** template.clisp: template.boot
*** 3380,3395 ****
  
  \subsection{termrw.boot}
  
- <<termrw.o (OUT from MID)>>=
- termrw.$(OBJEXT): termrw.clisp 
- 	@ echo 410 making termrw.$(OBJEXT) from termrw.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "termrw.clisp" :output-file "termrw.$(OBJEXT)"))' |  ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "termrw.clisp" :output-file "termrw.$(OBJEXT)"))' |  ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<termrw.clisp>>=
  termrw.clisp: termrw.boot
  	@ echo 411 making $@ from $<
--- 2609,2614 ----
*************** termrw.clisp: termrw.boot
*** 3403,3418 ****
  
  \subsection{trace.boot}
  
- <<trace.o (OUT from MID)>>=
- trace.$(OBJEXT): trace.clisp 
- 	@ echo 413 making trace.$(OBJEXT) from trace.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "trace.clisp" :output-file "trace.$(OBJEXT)"))' |  ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "trace.clisp" :output-file "trace.$(OBJEXT)"))' |  ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<trace.clisp>>=
  trace.clisp: trace.boot
  	@ echo 414 making $@ from $<
--- 2622,2627 ----
*************** trace.clisp: trace.boot
*** 3426,3441 ****
  
  \subsection{as.boot}
  
- <<as.o (OUT from MID)>>=
- as.$(OBJEXT): as.clisp 
- 	@ echo 416 making as.$(OBJEXT) from as.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "as.clisp" :output-file "as.$(OBJEXT)"))' |  ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "as.clisp" :output-file "as.$(OBJEXT)"))' |  ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<as.clisp>>=
  as.clisp: as.boot
  	@ echo 417 making $@ from $<
--- 2635,2640 ----
*************** ${AUTO}/bc-matrix.$(OBJEXT): bc-matrix.$
*** 3455,3470 ****
  	@ cp bc-matrix.$(OBJEXT) ${AUTO}
  
  @
- <<bc-matrix.o (OUT from MID)>>=
- bc-matrix.$(OBJEXT): bc-matrix.clisp 
- 	@ echo 423 making bc-matrix.$(OBJEXT) from bc-matrix.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "bc-matrix.clisp" :output-file "bc-matrix.$(OBJEXT)"))' |  ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "bc-matrix.clisp" :output-file "bc-matrix.$(OBJEXT)"))' |  ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<bc-matrix.clisp>>=
  bc-matrix.clisp: bc-matrix.boot
  	@ echo 424 making $@ from $<
--- 2654,2659 ----
*************** ${AUTO}/bc-misc.$(OBJEXT): bc-misc.$(OBJ
*** 3484,3499 ****
  	@ cp bc-misc.$(OBJEXT) ${AUTO}
  
  @
- <<bc-misc.o (OUT from MID)>>=
- bc-misc.$(OBJEXT): bc-misc.clisp 
- 	@ echo 427 making bc-misc.$(OBJEXT) from bc-misc.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "bc-misc.clisp" :output-file "bc-misc.$(OBJEXT)"))' |  ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "bc-misc.clisp" :output-file "bc-misc.$(OBJEXT)"))' |  ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<bc-misc.clisp>>=
  bc-misc.clisp: bc-misc.boot
  	@ echo 428 making $@ from $<
--- 2673,2678 ----
*************** ${AUTO}/bc-solve.$(OBJEXT): bc-solve.$(O
*** 3513,3528 ****
  	@ cp bc-solve.$(OBJEXT) ${AUTO}
  
  @
- <<bc-solve.o (OUT from MID)>>=
- bc-solve.$(OBJEXT): bc-solve.clisp 
- 	@ echo 431 making bc-solve.$(OBJEXT) from bc-solve.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "bc-solve.clisp" :output-file "bc-solve.$(OBJEXT)"))' |  ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "bc-solve.clisp" :output-file "bc-solve.$(OBJEXT)"))' |  ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<bc-solve.clisp>>=
  bc-solve.clisp: bc-solve.boot
  	@ echo 432 making $@ from $<
--- 2692,2697 ----
*************** ${AUTO}/bc-util.$(OBJEXT): bc-util.$(OBJ
*** 3542,3557 ****
  	@ cp bc-util.$(OBJEXT) ${AUTO}
  
  @
- <<bc-util.o (OUT from MID)>>=
- bc-util.$(OBJEXT): bc-util.clisp 
- 	@ echo 435 making bc-util.$(OBJEXT) from bc-util.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "bc-util.clisp" :output-file "bc-util.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "bc-util.clisp" :output-file "bc-util.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<bc-util.clisp>>=
  bc-util.clisp: bc-util.boot
  	@ echo 436 making $@ from $<
--- 2711,2716 ----
*************** ${AUTO}/ht-util.$(OBJEXT): ht-util.$(OBJ
*** 3571,3586 ****
  	@ cp ht-util.$(OBJEXT) ${AUTO}
  
  @
- <<ht-util.o (OUT from MID)>>=
- ht-util.$(OBJEXT): ht-util.clisp 
- 	@ echo 439 making ht-util.$(OBJEXT) from ht-util.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "ht-util.clisp" :output-file "ht-util.$(OBJEXT)"))' |  ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "ht-util.clisp" :output-file "ht-util.$(OBJEXT)"))' |  ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<ht-util.clisp>>=
  ht-util.clisp: ht-util.boot
  	@ echo 440 making $@ from $<
--- 2730,2735 ----
*************** ${AUTO}/htsetvar.$(OBJEXT): htsetvar.$(O
*** 3600,3615 ****
  	@ cp htsetvar.$(OBJEXT) ${AUTO}
  
  @
- <<htsetvar.o (OUT from MID)>>=
- htsetvar.$(OBJEXT): htsetvar.clisp 
- 	@ echo 443 making htsetvar.$(OBJEXT) from htsetvar.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "htsetvar.clisp" :output-file "htsetvar.$(OBJEXT)"))' |  ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "htsetvar.clisp" :output-file "htsetvar.$(OBJEXT)"))' |  ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<htsetvar.clisp>>=
  htsetvar.clisp: htsetvar.boot
  	@ echo 444 making $@ from $<
--- 2749,2754 ----
*************** htsetvar.clisp: htsetvar.boot
*** 3623,3638 ****
  
  \subsection{record.boot}
  
- <<record.o (OUT from MID)>>=
- record.$(OBJEXT): record.clisp 
- 	@ echo 446 making record.$(OBJEXT) from record.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "record.clisp" :output-file "record.$(OBJEXT)"))' |  ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "record.clisp" :output-file "record.$(OBJEXT)"))' |  ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<record.clisp>>=
  record.clisp: record.boot
  	@ echo 447 making $@ $<
--- 2762,2767 ----
*************** ${AUTO}/ht-root.$(OBJEXT): ht-root.$(OBJ
*** 3652,3667 ****
  	@ cp ht-root.$(OBJEXT) ${AUTO}
  
  @
- <<ht-root.o (OUT from MID)>>=
- ht-root.$(OBJEXT): ht-root.clisp 
- 	@ echo 450 making ht-root.$(OBJEXT) from ht-root.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "ht-root.clisp" :output-file "ht-root.$(OBJEXT)"))' |  ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "ht-root.clisp" :output-file "ht-root.$(OBJEXT)"))' |  ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<ht-root.clisp>>=
  ht-root.clisp: ht-root.boot
  	@ echo 451 making $@ from $<
--- 2781,2786 ----
*************** ${AUTO}/htcheck.$(OBJEXT): htcheck.$(OBJ
*** 3681,3696 ****
  	@ cp htcheck.$(OBJEXT) ${AUTO}
  
  @
- <<htcheck.o (OUT from MID)>>=
- htcheck.$(OBJEXT): htcheck.clisp 
- 	@ echo 454 making htcheck.$(OBJEXT) from htcheck.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "htcheck.clisp" :output-file "htcheck.$(OBJEXT)"))' |  ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "htcheck.clisp" :output-file "htcheck.$(OBJEXT)"))' |  ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<htcheck.clisp>>=
  htcheck.clisp: htcheck.boot
  	@ echo 455 making $@ from $<
--- 2800,2805 ----
*************** ${AUTO}/xruncomp.$(OBJEXT): xruncomp.$(O
*** 3710,3725 ****
  	@ cp xruncomp.$(OBJEXT) ${AUTO}
  
  @
- <<xruncomp.o (OUT from MID)>>=
- xruncomp.$(OBJEXT): xruncomp.clisp 
- 	@ echo 458 making xruncomp.$(OBJEXT) from xruncomp.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "xruncomp.clisp" :output-file "xruncomp.$(OBJEXT)"))' |  ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "xruncomp.clisp" :output-file "xruncomp.$(OBJEXT)"))' |  ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<xruncomp.clisp>>=
  xruncomp.clisp: xruncomp.boot
  	@ echo 459 making $@ from $<
--- 2819,2824 ----
*************** ${AUTO}/ax.$(OBJEXT): ax.$(OBJEXT)
*** 3739,3754 ****
  	@ cp ax.$(OBJEXT) ${AUTO}
  
  @
- <<ax.o (OUT from MID)>>=
- ax.$(OBJEXT): ax.clisp 
- 	@ echo 462 making ax.$(OBJEXT) from ax.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "ax.clisp" :output-file "ax.$(OBJEXT)"))' |  ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "ax.clisp" :output-file "ax.$(OBJEXT)"))' |  ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<ax.clisp>>=
  ax.clisp: ax.boot
  	@ echo 463 making $@ $<
--- 2838,2843 ----
*************** ${AUTO}/br-con.$(OBJEXT): br-con.$(OBJEX
*** 3768,3783 ****
  	@ cp br-con.$(OBJEXT) ${AUTO}
  
  @
- <<br-con.o (OUT from MID)>>=
- br-con.$(OBJEXT): br-con.clisp 
- 	@ echo 466 making br-con.$(OBJEXT) from br-con.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "br-con.clisp" :output-file "br-con.$(OBJEXT)"))' |  ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "br-con.clisp" :output-file "br-con.$(OBJEXT)"))' |  ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<br-con.clisp>>=
  br-con.clisp: br-con.boot
  	@ echo 467 making $@ from $<
--- 2857,2862 ----
*************** ${AUTO}/br-search.$(OBJEXT): br-search.$
*** 3797,3812 ****
  	@ cp br-search.$(OBJEXT) ${AUTO}
  
  @
- <<br-search.o (OUT from MID)>>=
- br-search.$(OBJEXT): br-search.clisp 
- 	@ echo 470 making br-search.$(OBJEXT) from br-search.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "br-search.clisp" :output-file "br-search.$(OBJEXT)"))' |  ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "br-search.clisp" :output-file "br-search.$(OBJEXT)"))' |  ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<br-search.clisp>>=
  br-search.clisp: br-search.boot
  	@ echo 471 making $@ from $<
--- 2876,2881 ----
*************** ${AUTO}/br-op1.$(OBJEXT): br-op1.$(OBJEX
*** 3826,3841 ****
  	@ cp br-op1.$(OBJEXT) ${AUTO}
  
  @
- <<br-op1.o (OUT from MID)>>=
- br-op1.$(OBJEXT): br-op1.clisp 
- 	@ echo 474 making br-op1.$(OBJEXT) from br-op1.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "br-op1.clisp" :output-file "br-op1.$(OBJEXT)"))' |  ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "br-op1.clisp" :output-file "br-op1.$(OBJEXT)"))' |  ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<br-op1.clisp>>=
  br-op1.clisp: br-op1.boot
  	@ echo 475 making $@ from $<
--- 2895,2900 ----
*************** ${AUTO}/br-op2.$(OBJEXT): br-op2.$(OBJEX
*** 3855,3870 ****
  	@ cp br-op2.$(OBJEXT) ${AUTO}
  
  @
- <<br-op2.o (OUT from MID)>>=
- br-op2.$(OBJEXT): br-op2.clisp 
- 	@ echo 478 making br-op2.$(OBJEXT) from br-op2.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "br-op2.clisp" :output-file "br-op2.$(OBJEXT)"))' |  ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "br-op2.clisp" :output-file "br-op2.$(OBJEXT)"))' |  ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<br-op2.clisp>>=
  br-op2.clisp: br-op2.boot
  	@ echo 479 making $@ from $<
--- 2914,2919 ----
*************** ${AUTO}/br-data.$(OBJEXT): br-data.$(OBJ
*** 3884,3899 ****
  	@ cp br-data.$(OBJEXT) ${AUTO}
  
  @
- <<br-data.o (OUT from MID)>>=
- br-data.$(OBJEXT): br-data.clisp 
- 	@ echo 482 making br-data.$(OBJEXT) from br-data.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "br-data.clisp" :output-file "br-data.$(OBJEXT)"))' |  ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "br-data.clisp" :output-file "br-data.$(OBJEXT)"))' |  ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<br-data.clisp>>=
  br-data.clisp: br-data.boot
  	@ echo 483 making $@ from $<
--- 2933,2938 ----
*************** ${AUTO}/br-util.$(OBJEXT): br-util.$(OBJ
*** 3913,3928 ****
  	@ cp br-util.$(OBJEXT) ${AUTO}
  
  @
- <<br-util.o (OUT from MID)>>=
- br-util.$(OBJEXT): br-util.clisp 
- 	@ echo 486 making br-util.$(OBJEXT) from br-util.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "br-util.clisp" :output-file "br-util.$(OBJEXT)"))' |  ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "br-util.clisp" :output-file "br-util.$(OBJEXT)"))' |  ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<br-util.clisp>>=
  br-util.clisp: br-util.boot
  	@ echo 487 making $@ from $<
--- 2952,2957 ----
*************** ${AUTO}/br-saturn.$(OBJEXT): br-saturn.$
*** 3942,3957 ****
  	@ cp br-saturn.$(OBJEXT) ${AUTO}
  
  @
- <<br-saturn.o (OUT from MID)>>=
- br-saturn.$(OBJEXT): br-saturn.clisp 
- 	@ echo 490 making br-saturn.$(OBJEXT) from br-saturn.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "br-saturn.clisp" :output-file "br-saturn.$(OBJEXT)"))' |  ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "br-saturn.clisp" :output-file "br-saturn.$(OBJEXT)"))' |  ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<br-saturn.clisp>>=
  br-saturn.clisp: br-saturn.boot
  	@ echo 491 making $@ from $<
--- 2971,2976 ----
*************** ${AUTO}/topics.$(OBJEXT): topics.$(OBJEX
*** 3971,3986 ****
  	@ cp topics.$(OBJEXT) ${AUTO}
  
  @
- <<topics.o (OUT from MID)>>=
- topics.$(OBJEXT): topics.clisp 
- 	@ echo 494 making topics.$(OBJEXT) from topics.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "topics.clisp" :output-file "topics.$(OBJEXT)"))' |  ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "topics.clisp" :output-file "topics.$(OBJEXT)"))' |  ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<topics.clisp>>=
  topics.clisp: topics.boot
  	@ echo 495 making $@ from $<
--- 2990,2995 ----
*************** ${AUTO}/br-prof.$(OBJEXT): br-prof.$(OBJ
*** 4000,4015 ****
  	@ cp br-prof.$(OBJEXT) ${AUTO}
  
  @
- <<br-prof.o (OUT from MID)>>=
- br-prof.$(OBJEXT): br-prof.clisp 
- 	@ echo 498 making br-prof.$(OBJEXT) from br-prof.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "br-prof.clisp" :output-file "br-prof.$(OBJEXT)"))' |  ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "br-prof.clisp" :output-file "br-prof.$(OBJEXT)"))' |  ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<br-prof.clisp>>=
  br-prof.clisp: br-prof.boot
  	@ echo 499 making $@ from $<
--- 3009,3014 ----
*************** ${AUTO}/showimp.$(OBJEXT): showimp.$(OBJ
*** 4035,4052 ****
  
  \subsection{hashcode.boot}
  
- files for the new compiler
- <<hashcode.o (OUT from MID)>>=
- 
- hashcode.$(OBJEXT): hashcode.clisp 
- 	@ echo 583 making hashcode.$(OBJEXT) from hashcode.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "hashcode.clisp" :output-file "hashcode.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "hashcode.clisp" :output-file "hashcode.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<hashcode.clisp>>=
  hashcode.clisp: hashcode.boot
  	@ echo 584 making $@ from $<
--- 3034,3039 ----
*************** hashcode.clisp: hashcode.boot
*** 4060,4075 ****
  
  \subsection{interop.boot}
  
- <<interop.o (OUT from MID)>>=
- interop.$(OBJEXT): interop.clisp
- 	@ echo 586 making interop.$(OBJEXT) from interop.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "interop.clisp" :output-file "interop.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn  (compile-file "interop.clisp" :output-file "interop.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
  <<interop.clisp>>=
  interop.clisp: interop.boot
  	@ echo 587 making $@ from $<
--- 3047,3052 ----
*************** interop.clisp: interop.boot
*** 4083,4098 ****
  
  \subsection{xrun.boot}
  
- <<xrun.o (OUT from MID)>>=
- xrun.$(OBJEXT): xrun.clisp 
- 	@ echo 589 making xrun.$(OBJEXT) from xrun.clisp
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn  (compile-file "xrun.clisp" :output-file "xrun.$(OBJEXT)"))' | ${DEPSYS} ; \
- 	   else \
- 	   echo '(progn  (compile-file "xrun.clisp" :output-file "xrun.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	   fi
- 
- @
  <<xrun.clisp>>=
  xrun.clisp: xrun.boot
  	@ echo 590 making $@ from $<
--- 3060,3065 ----
*************** xrun.clisp: xrun.boot
*** 4109,4120 ****
  translate files
  <<wi1.o (AUTO from MID)>>=
  ${AUTO}/wi1.$(OBJEXT): wi1.clisp 
! 	@ echo 592 making ${AUTO}/wi1.$(OBJEXT) from wi1.clisp
! 	@ if [ -z "${NOISE}" ] ; then \
! 	   echo '(progn  (compile-file "wi1.clisp" :output-file "${AUTO}/wi1.$(OBJEXT)"))' | ${DEPSYS} ; \
! 	  else \
! 	   echo '(progn  (compile-file "wi1.clisp" :output-file "${AUTO}/wi1.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
! 	  fi
  
  @
  <<wi1.clisp>>=
--- 3076,3082 ----
  translate files
  <<wi1.o (AUTO from MID)>>=
  ${AUTO}/wi1.$(OBJEXT): wi1.clisp 
! 	$(COMPILE_LISP)
  
  @
  <<wi1.clisp>>=
*************** wi1.clisp: wi1.boot
*** 4132,4143 ****
  
  <<wi2.o (AUTO from MID)>>=
  ${AUTO}/wi2.$(OBJEXT): wi2.clisp 
! 	@ echo 595 making ${AUTO}/wi2.$(OBJEXT) from wi2.clisp
! 	@ if [ -z "${NOISE}" ] ; then \
! 	   echo '(progn  (compile-file "wi2.clisp" :output-file "${AUTO}/wi2.$(OBJEXT)"))' | ${DEPSYS} ; \
! 	  else \
! 	   echo '(progn  (compile-file "wi2.clisp" :output-file "${AUTO}/wi2.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
! 	  fi
  
  @
  <<wi2.clisp>>=
--- 3094,3100 ----
  
  <<wi2.o (AUTO from MID)>>=
  ${AUTO}/wi2.$(OBJEXT): wi2.clisp 
! 	$(COMPILE_LISP)
  
  @
  <<wi2.clisp>>=
*************** wi2.clisp: wi2.boot
*** 4155,4166 ****
  
  <<pspad1.o (AUTO from MID)>>=
  ${AUTO}/pspad1.$(OBJEXT): pspad1.clisp 
! 	@ echo 598 making ${AUTO}/pspad1.$(OBJEXT) from pspad1.clisp
! 	@ if [ -z "${NOISE}" ] ; then \
! 	   echo '(progn  (compile-file "pspad1.clisp" :output-file "${AUTO}/pspad1.$(OBJEXT)"))' | ${DEPSYS} ; \
! 	  else \
! 	   echo '(progn  (compile-file "pspad1.clisp" :output-file "${AUTO}/pspad1.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
! 	  fi
  
  @
  <<pspad1.clisp>>=
--- 3112,3118 ----
  
  <<pspad1.o (AUTO from MID)>>=
  ${AUTO}/pspad1.$(OBJEXT): pspad1.clisp 
! 	$(COMPILE_LISP)
  
  @
  <<pspad1.clisp>>=
*************** pspad1.clisp: pspad1.boot
*** 4178,4189 ****
  
  <<pspad2.o (AUTO from MID)>>=
  ${AUTO}/pspad2.$(OBJEXT): pspad2.clisp 
! 	@ echo 601 making ${AUTO}/pspad2.$(OBJEXT) from pspad2.clisp
! 	@ if [ -z "${NOISE}" ] ; then \
! 	   echo '(progn  (compile-file "pspad2.clisp" :output-file "${AUTO}/pspad2.$(OBJEXT)"))' | ${DEPSYS} ; \
! 	  else \
! 	   echo '(progn  (compile-file "pspad2.clisp" :output-file "${AUTO}/pspad2.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
! 	  fi
  
  @
  <<pspad2.clisp>>=
--- 3130,3136 ----
  
  <<pspad2.o (AUTO from MID)>>=
  ${AUTO}/pspad2.$(OBJEXT): pspad2.clisp 
! 	$(COMPILE_LISP)
  
  @
  <<pspad2.clisp>>=
*************** pspad2.clisp: pspad2.boot
*** 4201,4212 ****
  
  <<mark.o (AUTO from MID)>>=
  ${AUTO}/mark.$(OBJEXT): mark.clisp 
! 	@ echo 604 making ${AUTO}/mark.$(OBJEXT) from mark.clisp
! 	@ if [ -z "${NOISE}" ] ; then \
! 	   echo '(progn  (compile-file "mark.clisp" :output-file "${AUTO}/mark.$(OBJEXT)"))' | ${DEPSYS} ; \
! 	  else \
! 	   echo '(progn  (compile-file "mark.clisp" :output-file "${AUTO}/mark.$(OBJEXT)"))' | ${DEPSYS} >> ${TMP}/trace ; \
! 	  fi
  
  @
  <<mark.clisp>>=
--- 3148,3154 ----
  
  <<mark.o (AUTO from MID)>>=
  ${AUTO}/mark.$(OBJEXT): mark.clisp 
! 	$(COMPILE_LISP)
  
  @
  <<mark.clisp>>=
*************** distclean-local: clean-local
*** 4322,4413 ****
  <<databases>>
  
  <<apply.o (AUTO from OUT)>>
- <<apply.o (OUT from MID)>>
  <<apply.clisp>>
  
- <<as.o (OUT from MID)>>
  <<as.clisp>>
  
  <<ax.o (AUTO from OUT)>>
- <<ax.o (OUT from MID)>>
  <<ax.clisp>>
  
  <<bc-matrix.o (AUTO from OUT)>>
- <<bc-matrix.o (OUT from MID)>>
  <<bc-matrix.clisp>>
  
  <<bc-misc.o (AUTO from OUT)>>
- <<bc-misc.o (OUT from MID)>>
  <<bc-misc.clisp>>
  
  <<bc-solve.o (AUTO from OUT)>>
- <<bc-solve.o (OUT from MID)>>
  <<bc-solve.clisp>>
  
  <<bc-util.o (AUTO from OUT)>>
- <<bc-util.o (OUT from MID)>>
  <<bc-util.clisp>>
  
  <<bootlex.o (AUTO from OUT)>>
  
  <<br-con.o (AUTO from OUT)>>
- <<br-con.o (OUT from MID)>>
  <<br-con.clisp>>
  
  <<br-data.o (AUTO from OUT)>>
- <<br-data.o (OUT from MID)>>
  <<br-data.clisp>>
  
  <<br-op1.o (AUTO from OUT)>>
- <<br-op1.o (OUT from MID)>>
  <<br-op1.clisp>>
  
  <<br-op2.o (AUTO from OUT)>>
- <<br-op2.o (OUT from MID)>>
  <<br-op2.clisp>>
  
  <<br-prof.o (AUTO from OUT)>>
- <<br-prof.o (OUT from MID)>>
  <<br-prof.clisp>>
  
  <<br-saturn.o (AUTO from OUT)>>
- <<br-saturn.o (OUT from MID)>>
  <<br-saturn.clisp>>
  
  <<br-search.o (AUTO from OUT)>>
- <<br-search.o (OUT from MID)>>
  <<br-search.clisp>>
  
  <<br-util.o (AUTO from OUT)>>
- <<br-util.o (OUT from MID)>>
  <<br-util.clisp>>
  
- <<buildom.o (OUT from MID)>>
  <<buildom.clisp>>
  
  <<category.o (AUTO from OUT)>>
- <<category.o (OUT from MID)>>
  <<category.clisp>>
  
- <<cattable.o (OUT from MID)>>
  <<cattable.clisp>>
  
  <<c-doc.o (AUTO from OUT)>>
- <<c-doc.o (OUT from MID)>>
  <<c-doc.clisp>>
  
  <<clam.lisp (OUT from IN)>>
- <<clam.o (OUT from MID)>>
  <<clam.clisp>>
  
- <<clammed.o (OUT from MID)>>
  <<clammed.clisp>>
  
- <<compat.o (OUT from MID)>>
  <<compat.clisp>>
  
  <<compiler.o (AUTO from OUT)>>
- <<compiler.o (OUT from MID)>>
  <<compiler.clisp>>
  
  <<compress.o (OUT from MID)>>
--- 3264,3332 ----
*************** distclean-local: clean-local
*** 4415,4424 ****
  
  <<c-util.o (AUTO from OUT)>>
  <<c-util.lisp (OUT from IN)>>
- <<c-util.o (OUT from MID)>>
  <<c-util.clisp>>
  
- <<database.o (OUT from MID)>>
  <<database.clisp>>
  
  <<debugsys.lisp>>
--- 3334,3341 ----
*************** distclean-local: clean-local
*** 4426,4554 ****
  <<def.o (AUTO from OUT)>>
  
  <<define.o (AUTO from OUT)>>
- <<define.o (OUT from MID)>>
  <<define.clisp>>
  
  <<fnewmeta.o (AUTO from OUT)>>
  
- <<format.o (OUT from MID)>>
  <<format.clisp>>
  
- <<fortcall.o (OUT from MID)>>
  <<fortcall.clisp>>
  
  <<functor.o (AUTO from OUT)>>
- <<functor.o (OUT from MID)>>
  <<functor.clisp>>
  
  <<g-boot.lisp (OUT from IN)>>
- <<g-boot.o (OUT from MID)>>
  <<g-boot.clisp>>
  
- <<g-cndata.o (OUT from MID)>>
  <<g-cndata.clisp>>
  
- <<g-error.o (OUT from MID)>>
  <<g-error.clisp>>
  
- <<g-opt.o (OUT from MID)>>
  <<g-opt.clisp>>
  
- <<g-timer.o (OUT from MID)>>
  <<g-timer.clisp>>
  
  <<g-util.lisp (OUT from IN)>>
- <<g-util.o (OUT from MID)>>
  <<g-util.clisp>>
  
- <<hashcode.o (OUT from MID)>>
  <<hashcode.clisp>>
  
  <<htcheck.o (AUTO from OUT)>>
- <<htcheck.o (OUT from MID)>>
  <<htcheck.clisp>>
  
  <<ht-root.o (AUTO from OUT)>>
- <<ht-root.o (OUT from MID)>>
  <<ht-root.clisp>>
  
  <<htsetvar.o (AUTO from OUT)>>
- <<htsetvar.o (OUT from MID)>>
  <<htsetvar.clisp>>
  
  <<ht-util.o (AUTO from OUT)>>
- <<ht-util.o (OUT from MID)>>
  <<ht-util.clisp>>
  
- <<hypertex.o (OUT from MID)>>
  <<hypertex.clisp>>
  
- <<i-analy.o (OUT from MID)>>
  <<i-analy.clisp>>
  
- <<i-code.o (OUT from MID)>>
  <<i-code.clisp>>
  
- <<i-coerce.o (OUT from MID)>>
  <<i-coerce.clisp>>
  
- <<i-coerfn.o (OUT from MID)>>
  <<i-coerfn.clisp>>
  
- <<i-eval.o (OUT from MID)>>
  <<i-eval.clisp>>
  
- <<i-funsel.o (OUT from MID)>>
  <<i-funsel.clisp>>
  
- <<bookvol5.o (OUT from MID)>>
  <<bookvol5.lisp>>
  
- <<i-intern.o (OUT from MID)>>
  <<i-intern.clisp>>
  
- <<interop.o (OUT from MID)>>
  <<interop.clisp>>
  
- <<i-map.o (OUT from MID)>>
  <<i-map.clisp>>
  
  <<info.o (AUTO from OUT)>>
- <<info.o (OUT from MID)>>
  <<info.clisp>>
  
- <<i-output.o (OUT from MID)>>
  <<i-output.clisp>>
  
- <<i-resolv.o (OUT from MID)>>
  <<i-resolv.clisp>>
  
- <<i-spec1.o (OUT from MID)>>
  <<i-spec1.clisp>>
  
- <<i-spec2.o (OUT from MID)>>
  <<i-spec2.clisp>>
  
- <<i-syscmd.o (OUT from MID)>>
  <<i-syscmd.clisp>>
  
  <<iterator.o (AUTO from OUT)>>
- <<iterator.o (OUT from MID)>>
  <<iterator.clisp>>
  
- <<i-toplev.o (OUT from MID)>>
  <<i-toplev.clisp>>
  
- <<i-util.o (OUT from MID)>>
  <<i-util.clisp>>
  
- <<lisplib.o (OUT from MID)>>
  <<lisplib.clisp>>
  
  <<mark.o (AUTO from MID)>>
  <<mark.clisp>>
  
- <<match.o (OUT from MID)>>
  <<match.clisp>>
  
  <<metalex.o (AUTO from OUT)>>
--- 3343,3434 ----
*************** distclean-local: clean-local
*** 4556,4665 ****
  <<metameta.o (AUTO from OUT)>>
  
  <<modemap.o (AUTO from OUT)>>
- <<modemap.o (OUT from MID)>>
  <<modemap.clisp>>
  
- <<msgdb.o (OUT from MID)>>
  <<msgdb.clisp>>
  
  <<nag-c02.o (AUTO from OUT)>>
- <<nag-c02.o (OUT from MID)>>
  <<nag-c02.clisp>>
  
  <<nag-c05.o (AUTO from OUT)>>
- <<nag-c05.o (OUT from MID)>>
  <<nag-c05.clisp>>
  
  <<nag-c06.o (AUTO from OUT)>>
- <<nag-c06.o (OUT from MID)>>
  <<nag-c06.clisp>>
  
  <<nag-d01.o (AUTO from OUT)>>
- <<nag-d01.o (OUT from MID)>>
  <<nag-d01.clisp>>
  
  <<nag-d02.o (AUTO from OUT)>>
- <<nag-d02.o (OUT from MID)>>
  <<nag-d02.clisp>>
  
  <<nag-d03.o (AUTO from OUT)>>
- <<nag-d03.o (OUT from MID)>>
  <<nag-d03.clisp>>
  
  <<nag-e01.o (AUTO from OUT)>>
- <<nag-e01.o (OUT from MID)>>
  <<nag-e01.clisp>>
  
  <<nag-e02.o (AUTO from OUT)>>
- <<nag-e02.o (OUT from MID)>>
  <<nag-e02.clisp>>
  
  <<nag-e04.o (AUTO from OUT)>>
- <<nag-e04.o (OUT from MID)>>
  <<nag-e04.clisp>>
  
  <<nag-f01.o (AUTO from OUT)>>
- <<nag-f01.o (OUT from MID)>>
  <<nag-f01.clisp>>
  
  <<nag-f02.o (AUTO from OUT)>>
- <<nag-f02.o (OUT from MID)>>
  <<nag-f02.clisp>>
  
  <<nag-f04.o (AUTO from OUT)>>
- <<nag-f04.o (OUT from MID)>>
  <<nag-f04.clisp>>
  
  <<nag-f07.o (AUTO from OUT)>>
- <<nag-f07.o (OUT from MID)>>
  <<nag-f07.clisp>>
  
  <<nag-s.o (AUTO from OUT)>>
- <<nag-s.o (OUT from MID)>>
  <<nag-s.clisp>>
  
- <<newaux.o (OUT from MID)>>
  <<newaux.lisp (OUT from MID)>>
  <<newaux.lisp>>
  
- <<newfort.o (OUT from MID)>>
  <<newfort.clisp>>
  
  <<nruncomp.o (AUTO from OUT)>>
- <<nruncomp.o (OUT from MID)>>
  <<nruncomp.clisp>>
  
- <<nrunfast.o (OUT from MID)>>
  <<nrunfast.clisp>>
  
- <<nrungo.o (OUT from MID)>>
  <<nrungo.clisp>>
  
- <<nruntime.o (OUT from MID)>>
  <<nruntime.clisp>>
  
- <<nrunopt.o (OUT from MID)>>
  <<nrunopt.clisp>>
  
  <<nspadaux.o (AUTO from OUT)>>
  
  <<package.o (AUTO from OUT)>>
- <<package.o (OUT from MID)>>
  <<package.clisp>>
  
  <<parse.o (AUTO from OUT)>>
- <<parse.o (OUT from MID)>>
  <<parse.lisp (OUT from IN)>>
  <<parse.clisp>>
  
  <<parsing.o (AUTO from OUT)>>
  
- <<pathname.o (OUT from MID)>>
  <<pathname.clisp>>
  
  <<postpar.o (AUTO from OUT)>>
  <<postpar.lisp (OUT from IN)>>
- <<postpar.o (OUT from MID)>>
  <<postpar.clisp>>
  
  <<postprop.lisp (AUTO from OUT)>>
--- 3436,3518 ----
*************** distclean-local: clean-local
*** 4667,4673 ****
  <<preparse.o (AUTO from OUT)>>
  
  <<profile.o (AUTO from OUT)>>
- <<profile.o (OUT from MID)>>
  <<profile.clisp>>
  
  <<pspad1.o (AUTO from MID)>>
--- 3520,3525 ----
*************** distclean-local: clean-local
*** 4676,4717 ****
  <<pspad2.o (AUTO from MID)>>
  <<pspad2.clisp>>
  
- <<record.o (OUT from MID)>>
  <<record.clisp>>
  
- <<rulesets.o (OUT from MID)>>
  <<rulesets.clisp>>
  
- <<server.o (OUT from MID)>>
  <<server.clisp>>
  
- <<setvars.o (OUT from MID)>>
  <<setvars.lisp (OUT from IN)>>
  <<setvars.clisp>>
  
- <<setvart.o (OUT from MID)>>
  <<setvart.clisp>>
  
  <<showimp.o (AUTO from OUT)>>
  
- <<simpbool.o (OUT from MID)>>
  <<simpbool.clisp>>
  
- <<slam.o (OUT from MID)>>
  <<slam.clisp>>
  <<slam.lisp (OUT from IN)>>
  
- <<template.o (OUT from MID)>>
  <<template.clisp>>
  
- <<termrw.o (OUT from MID)>>
  <<termrw.clisp>>
  
  <<topics.o (AUTO from OUT)>>
- <<topics.o (OUT from MID)>>
  <<topics.clisp>>
  
- <<trace.o (OUT from MID)>>
  <<trace.clisp>>
  
  <<warm.data.stanza>>
--- 3528,3558 ----
*************** distclean-local: clean-local
*** 4722,4732 ****
  <<wi2.o (AUTO from MID)>>
  <<wi2.clisp>>
  
- <<xrun.o (OUT from MID)>>
  <<xrun.clisp>>
  
  <<xruncomp.o (AUTO from OUT)>>
- <<xruncomp.o (OUT from MID)>>
  <<xruncomp.clisp>>
  
  <<DVI from pamphlet>>
--- 3563,3571 ----
*** src/interp/cfuns.lisp.pamphlet	(revision 19359)
--- src/interp/cfuns.lisp.pamphlet	(local)
***************
*** 50,56 ****
  
  #+(and :Lucid (not :ibm/370))
  (progn
!   (system:define-foreign-function :c '|findString| :fixnum)
    (system:define-foreign-function :c '|addtopath|  :fixnum)
    (system:define-foreign-function :c '|chdir|      :fixnum)
    (system:define-foreign-function :c '|writeablep| :fixnum)
--- 50,56 ----
  
  #+(and :Lucid (not :ibm/370))
  (progn
! ;  (system:define-foreign-function :c '|findString| :fixnum)
    (system:define-foreign-function :c '|addtopath|  :fixnum)
    (system:define-foreign-function :c '|chdir|      :fixnum)
    (system:define-foreign-function :c '|writeablep| :fixnum)
***************
*** 62,68 ****
  (progn
    (defentry |directoryp| (string)        (int "directoryp"))
    (defentry |writeablep| (string)        (int "writeablep"))
!   (defentry |findString| (string string) (int "findString"))
    )
  
  #+:CCL
--- 62,68 ----
  (progn
    (defentry |directoryp| (string)        (int "directoryp"))
    (defentry |writeablep| (string)        (int "writeablep"))
! ;  (defentry |findString| (string string) (int "findString"))
    )
  
  #+:CCL
***************
*** 73,80 ****
  
  
  
! (defun |findStringInFile| (str p) 
!     (|findString| (namestring p) str) )
  
  
  (defun |getEnv| (var-name)  (system::getenv var-name))
--- 73,80 ----
  
  
  
! ; (defun |findStringInFile| (str p) 
! ;     (|findString| (namestring p) str) )
  
  
  (defun |getEnv| (var-name)  (system::getenv var-name))
*** src/interp/interp-proclaims.lisp	(revision 19359)
--- src/interp/interp-proclaims.lisp	(local)
***************
*** 2634,2640 ****
              BOOT::|htKill| BOOT::|htFunctionSetLiteral|
              BOOT::|htShowSetPage| BOOT::ADDCLOSE BOOT::|htSetLiteral|
              BOOT:|LispCompileFileQuietlyToObject|
!             BOOT::|findStringInFile| BOOT::|ppPair|
              BOOT::|getMinimalVarMode| BOOT::|checkAddSpaceSegments|
              BOOT::|checkAddIndented| BOOT::|alistSize,count|
              BOOT::|dbConformGen1| BOOT::|pickitForm|
--- 2634,2641 ----
              BOOT::|htKill| BOOT::|htFunctionSetLiteral|
              BOOT::|htShowSetPage| BOOT::ADDCLOSE BOOT::|htSetLiteral|
              BOOT:|LispCompileFileQuietlyToObject|
!             ; BOOT::|findStringInFile| 
! 	    BOOT::|ppPair|
              BOOT::|getMinimalVarMode| BOOT::|checkAddSpaceSegments|
              BOOT::|checkAddIndented| BOOT::|alistSize,count|
              BOOT::|dbConformGen1| BOOT::|pickitForm|
***************
*** 3388,3391 ****
  (PROCLAIM
      '(FTYPE (FUNCTION NIL (VALUES T T)) BOOT::MAKE-CLOSEDFN-NAME
              BOOT::|genVariable| BOOT::|genSomeVariable|
!             BOOT::|genDomainVar| BOOT:GENVAR)) 
\ No newline at end of file
--- 3389,3392 ----
  (PROCLAIM
      '(FTYPE (FUNCTION NIL (VALUES T T)) BOOT::MAKE-CLOSEDFN-NAME
              BOOT::|genVariable| BOOT::|genSomeVariable|
!             BOOT::|genDomainVar| BOOT:GENVAR)) 
*** src/interp/sys-pkg.lisp.pamphlet	(revision 19359)
--- src/interp/sys-pkg.lisp.pamphlet	(local)
*************** idioms from prior ports (like [[rdefiost
*** 58,78 ****
  We plan to move the content of [[VMLISP]] to [[BOOT]].
  
  
- \subsection{The [[BOOTTRAN]] package}
- 
- This is the old Boot to Lisp translator package.
- <<*>>=
- (make-package "BOOTTRAN")
- (in-package "BOOTTRAN")
- (lisp::use-package '("LISP"))
- 
- @
- 
- Note that the directory \File{src/boot} defines similar package
- for ``new Boot'' (or Shoe).  Eventually, the old Boot to Lisp 
- translator will disappear so that the [[BOOTTRAN]] package will 
- not be created here anymore.
- 
  
  \subsection{The [[BOOT]] package}
  
--- 58,63 ----
*** src/interp/util.lisp.pamphlet	(revision 19359)
--- src/interp/util.lisp.pamphlet	(local)
*************** because of {\bf *print-level*} or {\bf *
*** 945,956 ****
  (in-package "BOOTTRAN") 
  
  #+:oldboot
! (defun boottran::boottocl (file) ;; translates a single boot file
  #+:CCL
    (setq *package* (find-package "BOOT"))
  #+:AKCL
    (in-package "BOOT")
!   (let (*print-level* *print-length* (fn (pathname-name file)))
      (declare (special *print-level* *print-length*))
      (boot::boot
        file
--- 945,959 ----
  (in-package "BOOTTRAN") 
  
  #+:oldboot
! (defun boottocl (file) ;; translates a single boot file
  #+:CCL
    (setq *package* (find-package "BOOT"))
  #+:AKCL
    (in-package "BOOT")
!   (let (*print-level* 
! 	*print-length* 
! 	(fn (pathname-name file))
! 	(*print-pretty* t))
      (declare (special *print-level* *print-length*))
      (boot::boot
        file
*** src/lisp/ChangeLog.build-improvements	(revision 19359)
--- src/lisp/ChangeLog.build-improvements	(local)
***************
*** 1,3 ****
--- 1,11 ----
+ 2007-03-26  Gabriel Dos Reis  Gabriel Dos Reis
+ 
+ 	* Makefile.pamphlet ($(OUT)/lisp$(EXEEXT)): Dont' depend on
+ 	$(AXIOM_LISP).  Load ../boot/initial-env.lisp before saving to
+ 	disk. Remove obsolete GCL build description.
+ 	(mostlyclean-local): Remove saved Lisp image.
+ 	* Makefile.in: Regenerate.
+ 
  2007-03-04  Gabriel Dos Reis  Gabriel Dos Reis
  
  	* Makefile.pamphlet ($(OUT)/lisp$(EXEEXT)): Conditionally depend
*** src/lisp/Makefile.in	(revision 19359)
--- src/lisp/Makefile.in	(local)
*************** all: all-ax all-lisp
*** 15,21 ****
  
  all-ax all-lisp: $(OUT)/lisp$(EXEEXT)
  
! ## Create a fresh image for building Boot
  ## These objects files are the C runtime support
  ## and must be compiled into the Lisp image,
  ## as they must be present in the final interpreter
--- 15,21 ----
  
  all-ax all-lisp: $(OUT)/lisp$(EXEEXT)
  
! ## Create a fresh image for building interpsys and AXIOMsys
  ## These objects files are the C runtime support
  ## and must be compiled into the Lisp image,
  ## as they must be present in the final interpreter
*************** lisp_c_objects = \
*** 25,37 ****
  		$(build_libdir)/cfuns-c.o \
  		$(build_libdir)/sockio-c.o
  
- ifeq ($(strip $(axiom_include_gcl)),yes)
- $(OUT)/lisp$(EXEEXT): $(AXIOM_LISP)
- else
  $(OUT)/lisp$(EXEEXT):
- endif
  	@axiom_gcl_rsym_hack@
! 	echo '(compiler::link nil "lisp" ' \
                ' (format nil "(progn (let ((*load-path* (cons ~S *load-path*))'\
                                          ' (si::*load-types* ~S))' \
                                         ' (compiler::emit-fn t))' \
--- 25,33 ----
  		$(build_libdir)/cfuns-c.o \
  		$(build_libdir)/sockio-c.o
  
  $(OUT)/lisp$(EXEEXT):
  	@axiom_gcl_rsym_hack@
! 	echo '(compiler::link (quote ("../boot/initial-env.lisp")) "lisp" ' \
                ' (format nil "(progn (let ((*load-path* (cons ~S *load-path*))'\
                                          ' (si::*load-types* ~S))' \
                                         ' (compiler::emit-fn t))' \
*************** endif
*** 44,55 ****
  	$(INSTALL_PROGRAM) lisp$(EXEEXT) $(OUT)
  
  
- # Build GCL takes quite a while, so we don't remove the
- # diretcory in mostlyclean.  Rather, we do that in clean.
  mostlyclean-local:
  
  clean-local: mostlyclean
- 	-rm -f $(OUT)/lisp$(EXEEXT)
  
  distclean-local: clean-local
  	-rm -f Makefile
--- 40,49 ----
  	$(INSTALL_PROGRAM) lisp$(EXEEXT) $(OUT)
  
  
  mostlyclean-local:
+ 	-rm -f $(OUT)/lisp$(EXEEXT)
  
  clean-local: mostlyclean
  
  distclean-local: clean-local
  	-rm -f Makefile
*** src/lisp/Makefile.pamphlet	(revision 19359)
--- src/lisp/Makefile.pamphlet	(local)
***************
*** 2,8 ****
  \documentclass{article}
  \usepackage{axiom}
  
! \title{\File{src/lisp/Makefile}}
  \author{The Axiom Team}
  
  \begin{document}
--- 2,8 ----
  \documentclass{article}
  \usepackage{axiom}
  
! \title{\File{src/lisp/Makefile} Pamphlet}
  \author{The Axiom Team}
  
  \begin{document}
***************
*** 18,67 ****
  \section{The Makefile}
  
  The purpose of this Makefile is to create a fresh Lisp image, [[$(OUT)/lisp]],
! for use in make [[boot]].  To that end, it augments a existing Lisp
! image, at the moment \Tool{GCL}, with some specific C-routines.
! 
! If \Tool{GCL} is not existing in the build environment, we build one and
! install it a separate directory and carry on the build process has if it had 
! existed.
! 
! \section{Configure and build \Tool{GCL}}
! We enable several features of \Tool{GCL}.
! The [[--enable-readline]] uses GNU readline for the prompts. It has been
! removed and replaced with clef which is Axiom's version of readline.
! The [[--enable-maxpage]] is set to allow the image to grow 4 times
! what it would by default.
! The [[--enable-vssize]] allows virtual stack to grow by twice the normal size.
! The [[--enable-statsysbfd]] uses a static system bfd library for loading and
! relocating object files.
! 
! We would like to have the following done for all \Tool{GCL} (either built 
! from Axiom sources or system-installed).
! Finally we load some routines for performance reasons. [[lsp/sys-proclaim]]
! contains common lisp proclaim statements for the various \Tool{GCL} lisp 
! routines.
! [[cmpnew/gcl_collectfn]] contains modifications to the common lisp compiler
! to collect compile-time type information which will be written to [[.fn]]
! files as common lisp structs. These [[.fn]] files can be loaded and turned
! into common lisp proclaim statements which the compiler can use to generate
! faster code, mostly fast-path function calls. The call to [[compiler::emit-fn]]
! enables the [[.fn]] file generation whenever compile-file is called. We
! default this code into the image so it is always avaiable.
! 
! \begin{verbatim}
! 	echo '(progn (load "cmpnew/gcl_collectfn.lsp")' \
! 		   ' (load "lsp/sys-proclaim.lisp")' \
! 		   ' (compiler::emit-fn t)' \
!                    ' (system::save-system "${OUT}/lisp"))' \
!              | $(AXIOM_LISP))
! \end{verbatim}
  
  \section{The Makefile}
  
! \subsection{\Tool{GCL} already installed or built}
! 
! <<build lisp for boot>>=
! ## Create a fresh image for building Boot
  ## These objects files are the C runtime support
  ## and must be compiled into the Lisp image,
  ## as they must be present in the final interpreter
--- 18,31 ----
  \section{The Makefile}
  
  The purpose of this Makefile is to create a fresh Lisp image, [[$(OUT)/lisp]],
! for use to make \Tool{interpsys} and \Tool{AXIOMsys}.  To that end, 
! it augments an existing Lisp image, at the moment \Tool{GCL}, with 
! some specific C-routines. 
  
  \section{The Makefile}
  
! <<build augmented lisp>>=
! ## Create a fresh image for building interpsys and AXIOMsys
  ## These objects files are the C runtime support
  ## and must be compiled into the Lisp image,
  ## as they must be present in the final interpreter
*************** lisp_c_objects = \
*** 71,83 ****
  		$(build_libdir)/cfuns-c.o \
  		$(build_libdir)/sockio-c.o
  
- ifeq ($(strip $(axiom_include_gcl)),yes)
- $(OUT)/lisp$(EXEEXT): $(AXIOM_LISP)
- else
  $(OUT)/lisp$(EXEEXT):
- endif
  	@axiom_gcl_rsym_hack@
! 	echo '(compiler::link nil "lisp" ' \
                ' (format nil "(progn (let ((*load-path* (cons ~S *load-path*))'\
                                          ' (si::*load-types* ~S))' \
                                         ' (compiler::emit-fn t))' \
--- 35,43 ----
  		$(build_libdir)/cfuns-c.o \
  		$(build_libdir)/sockio-c.o
  
  $(OUT)/lisp$(EXEEXT):
  	@axiom_gcl_rsym_hack@
! 	echo '(compiler::link (quote ("../boot/initial-env.lisp")) "lisp" ' \
                ' (format nil "(progn (let ((*load-path* (cons ~S *load-path*))'\
                                          ' (si::*load-types* ~S))' \
                                         ' (compiler::emit-fn t))' \
*************** all: all-ax all-lisp
*** 109,122 ****
  
  all-ax all-lisp: $(OUT)/lisp$(EXEEXT)
  
! <<build lisp for boot>>
  
- # Build GCL takes quite a while, so we don't remove the
- # diretcory in mostlyclean.  Rather, we do that in clean.
  mostlyclean-local:
  
  clean-local: mostlyclean
- 	-rm -f $(OUT)/lisp$(EXEEXT)
  
  distclean-local: clean-local
  	-rm -f Makefile
--- 69,80 ----
  
  all-ax all-lisp: $(OUT)/lisp$(EXEEXT)
  
! <<build augmented lisp>>
  
  mostlyclean-local:
+ 	-rm -f $(OUT)/lisp$(EXEEXT)
  
  clean-local: mostlyclean
  
  distclean-local: clean-local
  	-rm -f Makefile
*** src/scripts/ChangeLog.build-improvements	(revision 19359)
--- src/scripts/ChangeLog.build-improvements	(local)
***************
*** 1,3 ****
--- 1,7 ----
+ 2007-03-26  Gabriel Dos Reis  Gabriel Dos Reis
+ 
+ 	* document.in (load_lisp_and_save_image): Don't use quiet mode.
+ 
  2007-03-24  Gabriel Dos Reis  Gabriel Dos Reis
  
  	* document.in (lisp_flavor): Don't print debug information.
*** src/scripts/document.in	(revision 19359)
--- src/scripts/document.in	(local)
*************** compile_lisp_file() {
*** 113,119 ****
  load_lisp_and_save_image() {
      case $lisp_flavor in
  	gcl|sbcl|clisp)
!            $command $quiet $eval_flags "(load \"$1\")" \
  	       $eval_flags "(boottran::save-core \"$output\")"
  	   ;;
  	*)
--- 113,123 ----
  load_lisp_and_save_image() {
      case $lisp_flavor in
  	gcl|sbcl|clisp)
!            ## Ideally we would like the loading to be quiet.
!            ## However, the GCL saved image would remain a batch-only
!            ## image.  Consequently, we don't supply the $quiet flags
!            ## when loading-and-saving.
!            $command $eval_flags "(load \"$1\")" \
  	       $eval_flags "(boottran::save-core \"$output\")"
  	   ;;
  	*)

\start
Date: Mon, 26 Mar 2007 17:02:24 +0200
From: Ralf Hemmecke
To: Ondrej Certik
Subject: Re: Commutative symbols

On 03/26/2007 02:36 PM, Ondrej Certik wrote:
>> Hmmm, I would have thought that commutativity is a property of the
>> multiplication of the domain you are working in and not a property of a
>> symbol.
> 
> I know - originaly I had a special class NCMul, for noncommutative
> multiplication. But first it duplicates some code and second - some
> symbols are commutative and some are not and I want to mix that. It's
> like when computing with matrices, like:
> 
> A*3*x*B,
> 
> where x is a variable and A,B matrices, then you want this to evaluate to:
> 
> 3*x *A*B

Maybe this is not what you want...

(6) -> A: Matrix Integer := [[1,2],[5,9],[7,11],[3,1]]
(6) ->
         +1  2 +
         |     |
         |5  9 |
    (6)  |     |
         |7  11|
         |     |
         +3  1 +
                              Type: Matrix Integer
(7) -> B: Matrix Integer := [[1,2,3],[5,7,9]]
(7) ->
         +1  2  3+
    (7)  |       |
         +5  7  9+
                              Type: Matrix Integer
(8) -> A*3*x*B
         +33x   48x   63x +
         |                |
         |150x  219x  288x|
    (8)  |                |
         |186x  273x  360x|
         |                |
         +24x   39x   54x +
                               Type: Matrix Polynomial Integer
(11) -> B*3*x*A
  11) ->
    >> Error detected within library code:
    can't multiply matrices of incompatible dimensions

> and when you think about it, it's actually the symbols, that have this
> property - either you can commute it out of the expression, or you
> cannot.

Yes, here A and B are actually matrices, not symbols. It depends on what 
you want.

\start
Date: Mon, 26 Mar 2007 17:17:51 +0200
From: Ondrej Certik
To: Ralf Hemmecke
Subject: Re: Commutative symbols

On 3/26/07, Ralf Hemmecke wrote:
> On 03/26/2007 02:36 PM, Ondrej Certik wrote:
> >> Hmmm, I would have thought that commutativity is a property of the
> >> multiplication of the domain you are working in and not a property of a
> >> symbol.
> >
> > I know - originaly I had a special class NCMul, for noncommutative
> > multiplication. But first it duplicates some code and second - some
> > symbols are commutative and some are not and I want to mix that. It's
> > like when computing with matrices, like:
> >
> > A*3*x*B,
> >
> > where x is a variable and A,B matrices, then you want this to evaluate to:
> >
> > 3*x *A*B
>
> Maybe this is not what you want...
>
> (6) -> A: Matrix Integer := [[1,2],[5,9],[7,11],[3,1]]
> (6) ->
>          +1  2 +
>          |     |
>          |5  9 |
>     (6)  |     |
>          |7  11|
>          |     |
>          +3  1 +
>                               Type: Matrix Integer
> (7) -> B: Matrix Integer := [[1,2,3],[5,7,9]]
> (7) ->
>          +1  2  3+
>     (7)  |       |
>          +5  7  9+
>                               Type: Matrix Integer
> (8) -> A*3*x*B
>          +33x   48x   63x +
>          |                |
>          |150x  219x  288x|
>     (8)  |                |
>          |186x  273x  360x|
>          |                |
>          +24x   39x   54x +
>                                Type: Matrix Polynomial Integer
> (11) -> B*3*x*A
>   11) ->
>     >> Error detected within library code:
>     can't multiply matrices of incompatible dimensions
>
> > and when you think about it, it's actually the symbols, that have this
> > property - either you can commute it out of the expression, or you
> > cannot.
>
> Yes, here A and B are actually matrices, not symbols. It depends on what
> you want.
>
> Ralf

You can do the same in SymPy:

In [1]: A = Matrix([[1,2],[5,9],[7,11],[3,1]])

In [2]: A
Out[2]:
1 2
5 9
7 11
3 1


In [3]: B = Matrix([[1,2,3],[5,7,9]])

In [4]: B
Out[4]:
1 2 3
5 7 9


In [5]: A*3*x*B
Out[5]:
33*x 48*x
150*x 219*x
186*x 273*x
24*x 39*x


In [6]: B*3*x*A
---------------------------------------------------------------------------
exceptions.AssertionError                            Traceback (most
recent call last)

/home/ondra/sympy/<ipython console>

/home/ondra/sympy/sympy/modules/matrices.py in __mul__(self, a)
    157     def __mul__(self,a):
    158         if isinstance(a,Matrix):
--> 159             return self.multiply(a)

.....

and a traceback. When there is something wrong, SymPy just raises an
exception, and the Python console then shows you a full traceback (if
the user wants).

But matrices are different kind of objects. I was talking about just
noncommutative symbols, for example the  Pauli algebra:

http://en.wikipedia.org/wiki/Pauli_matrices


In [1]: from sympy.modules.paulialgebra import Pauli

In [2]: sigma1=Pauli(1)

In [3]: sigma2=Pauli(2)

In [4]: sigma3=Pauli(3)

In [5]: sigma1*sigma2
Out[5]: I*sigma3

In [6]: sigma1*2*sigma1
Out[6]: 2

In [7]: sigma1**1
Out[7]: sigma1

In [8]: sigma1**2
Out[8]: 1

In [9]: sigma1*sigma2
Out[9]: I*sigma3

In [10]: sigma2*sigma1
Out[10]: -I*sigma3

In [11]: sigma1*sigma2+sigma2*sigma1
Out[11]: 0

In [12]: sigma1*sigma2-sigma2*sigma1
Out[12]: 2*I*sigma3

In [13]: (sigma1+sigma2)**2
Out[13]: (sigma2+sigma1)**2

In [14]: ((sigma1+sigma2)**2).expand()
Out[14]: 2

In [15]: ((sigma1-sigma2)**2).expand()
Out[15]: 2


But anyway, those are just minor details. I am sure every CAS can work
with such objects in some way.

\start
Date: Mon, 26 Mar 2007 17:24:49 +0200
From: Ondrej Certik
To: Ralf Hemmecke
Subject: Re: Commutative symbols

> But matrices are different kind of objects. I was talking about just
> noncommutative symbols, for example the  Pauli algebra:
>
> http://en.wikipedia.org/wiki/Pauli_matrices
>

If you want to look at the actual implementation:

http://sympy.googlecode.com/svn/trunk/sympy/modules/paulialgebra.py

the relevant code (if we won't count comments and helper functions
like delta and epsilon) is below 20 lines. That's what I mean when I
want to have a CAS, that is easily extensible.

\start
Date: Mon, 26 Mar 2007 13:05:59 -0400
From: Bill Page
To: Tim Daly, Gabriel Dos Reis,	Martin Rubey, Ralf Hemmecke
Subject: RE: SoC mentors and application deadline: March 27th

Dear Axiom Developers;

Well, we are nearly at the end of the SoC application phase and so far we
only have one very weak but still surviving application concerning Groebner
Basis in Lisp (or maybe Axiom). This is very disappointing to me. :-( Surely
there are some students out there somewhere who would want to spend the
summer learning and doing something about computer algebra with Axiom! After
all $US 4,500 for 3 months work is not that trivial, I think.

If you can spare any time immediately today to invite anyone you know who
might have at least some interest in this to submit a brief application as
soon as possible today at:

In the conference this morning LispNYC agreed to wait until midnight
(Eastern Daylight Time), today, 26 March before closing the applications and
final evaluation. Please do whatever you can do today to encourage more
people to apply.

\start
Date: Mon, 26 Mar 2007 13:09:07 -0400
From: Bill Page
To: Tim Daly, Gabriel Dos Reis, Martin Rubey, Ralf Hemmecke
Subject: FW: Mentor Meeting Wrapup

Correction: Please note the deadline:

  - midnight UTC (5:00 PM Pacific, 8:00 PM Eastern)

-----Original Message-----
From: Heow Eide-Goodman [mailto:Heow Eide-Goodman] 

Guys,

In attendance was:

  Bill Page
  Christophe Rhodes
  Francois-Rene Rideau
  Frank Klassner
  Gary Warren King
  Rahul Jain

Some of the more interesting proposals that stood out and got some
mentors are:

  Purely Functional Data Structure in CL by Andrew Baine 
     (mentor: Rahul)
  Gsharp interchange  by Andreas Fuchs 
     (mentor: Christophe)
  Music interchange format support for Gsharp by Brian Gruber 
     (mentor: Christophe)
  Nuff by Doug Hoyte
  Metaobject Sealing for CLOS by Luis Manuel Borges de Oliveria 
     (mentor: Christophe and Gary King)
  Enhancing Excribe by Maciei Pawel Pasternacki 
     (mentor: Fahree)
  NXT Lisp by Milan Cermak 
     (mentor: Frank Klassner)

Said projects will get modded up.

What we need to go is rate the rest of the projects and ensure that all
of our highest rated proposals HAVE A MENTOR.  No mentor, no money.
Although I'm positive that we can get mentors after the fact, at least
one has to be on paper for Google to fund it.

Rating stops at midnight UTC (5:00 PM Pacific, 8:00 PM Eastern).

- Heow

\start
Date: Mon, 26 Mar 2007 13:14:51 -0400
From: Bill Page
To: Bill Page, Tim Daly, Gabriel Dos Reis, Martin Rubey, Ralf Hemmecke
Subject: RE: SoC mentors and application deadline

On March 26, 2007 1:06 PM I wrote:
> ...
> If you can spare any time immediately today to invite anyone
> you know who might have at least some interest in this to submit
> a brief application as soon as possible today at:
> ...

I intended to also provide this link to the online Google Summer
of Code application form:


http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-student-applicants

\start
Date: Mon, 26 Mar 2007 22:47:05 +0200
From: Ondrej Certik
To: Martin Rubey
Subject: re: Limits in Axiom

On 26 Mar 2007 14:08:26 +0200, Martin Rubey wrote:
>

> > > For someone who knows Axiom well, it should take like a week of
> > > a work. In SymPy I was doing it I think like 3 weeks, because I
> > > had to implement many other things and I was spending most of
> > > the time in the series facility.

> So, if you get help from an expert Axiom programmer :-), would you
> be prepared to do it? If not, what would it take to get you
> interested?

> In fact, I'd also have some other stuff that just waits to be implemented,
> maybe of interest for people doing analysis, but also for combinatorialists
> like myself...

Well, I also have many nice ideas for SymPy. But currently, I don't
have much time even for SymPy either, but fortunately, I hopefully got
some students interested, so I am curious how all this turns out.

\start
Date: Mon, 26 Mar 2007 22:55:40 +0200
From: Ondrej Certik
To: Ralf Hemmecke
Subject: Re: [Axiom-mail] limits

> Unfortunately, I haven't found a .pdf file of Gruntz thesis, but

http://sympy.googlecode.com/svn/trunk/doc/gruntz.pdf

Ondrej

\start
Date: 27 Mar 2007 11:05:40 -0500
From: Gabriel Dos Reis
To: list
Subject: depsys and SBCL

  In my local tree, I was able to eventually twist Axiom to get it
compilable by SBCL.  During that process, I unconvered various dubious
practices in the current system (mainly between vmlisp.lisp and
macro.lisp).  SBCL will accept to compile depsys only if I tell it to
ignore many redefinitions of Common Lisp symbols (I'll discuss that in
a separate message).

  CLISP almost compiles SBCL -- it errors out on def.lisp saying
that there is an illegal character #\Stx in the source file -- I have
no idea of what that means.  If I omit def.lisp, the depsys
compiles fine -- I have not tried the resulting translator however.

This is just a head up.  If you know anything about the illegal
character \#Stx, please let me know.

Ah, one more thing: Currently, there is this dubious definition in
foam_l.lisp: 

   #+:AKCL
   (deftype |DFlo| () t)
   #-:AKCL
   (deftype |DFlo| () 'long-float)

followed by

   (defconstant |DFloInit| (the |DFlo| 0.0d0))

which is an error because 0.0d0 is not long-float -- rather a double-float.

Looking more at this, I think the |DFlo| should not be conditional.
Furthermore, I think we should use double-float instead of long-float
-- it fits more in most modern FPU and its underyling representation
is more widely uniform.
This is a change for people connecting Axiom to Aldor through FOAM.
Please speak up.

\start
Date: Tue, 27 Mar 2007 19:37:22 -0600
From: Tim Daly
To: list
Subject: Axiom startup

Paul Graham, a noted lisper, has an interesting web page up
about the reasons that keep people from forming a startup.
<http://www.paulgraham.com/notnot.html>

I've long pondered the possible paths to making Axiom into
something that lives and I've tried to gain various forms of
funding, all to no result.

I contacted the National Science Foundation. Their basic position
is that as long as there are commercial offerings they will not
fund research. Of course, if you've been listening to the latest
SymPy debate you'll see that Axiom is a world apart from other
computer algebra systems. And, in that realm, there are no commercial
offerings. But, from the outside, a CAS is a CAS is a CAS so the NSF
doesn't consider this a worthwhile research project.

Paul's essay tweeked my long-term vision nerve yet again, even as I
wrestle with the mundane release issues. I don't see Axiom on a path
for "commercial success" but rather a path of "research success"; a
long term, large-science kind of project; the big-ticket physics
project of computational mathematics. In the long term I would like
to see Axiom as a source of thesis work, as a central pillar of a
research institute, as a base for computational mathematics. 

RISC-Linz, under Buchberger, made money by focusing on gaining
industry support for solving real-world problems at his institute.
I think such a path could be very lucrative, certainly enough to
support a group of full time people who can solve real industry
problems while generating new computational mathematics.

Of course, it's a long, slow, and very poverty-laden path between
here and such an institute. And clearly Paul is not in that kind
of an investment chain.

But he has again "raised an ache" for doing Axiom full time.

\start
Date: Tue, 27 Mar 2007 23:04:30 -0600
From: Tim Daly
To: Gabriel Dos Reis
Subject: CAS for the masses

Gaby writes:

> I suspect that agruments about typed language  in CAS may be more
> convincing by studying cases where the type system does add value

I think that one canonical case is that Axiom strongly highlights the
interaction between type, representation, and "simplification".

The usual example is:

  (1/2)*x^2 + (1/3)*x + 3
                            Type: Polynomial Fraction Integer

%::Fraction(Polynomial(Integer))

      2
    3x  + 2x + 18
    -------------
          6
                            Type: Fraction Polynomial Integer


Simplification is a hard problem because it is usually weakly defined
(among other reasons such as the zero equivalence problem). Strong 
typing allows you to define what "simple" means in a given type tower.
This kinds of simplification could be done using decomposition of the
"string" form of the equation but that steps around the semantics.

Though not yet apparent strong typing really comes to the foreground
when provisos are used. 

When you read a maths book most of the equations are actually just
"icons". The real meaning of the equation is in the surrounding text
and context. Axiom carries that surrounding information in the type
whereas other systems focus on the "icons" and syntactic manipulations.
This is the primary reason why it makes no sense to "export" an equation
from Axiom and the "import" it again. Much is lost when the type is
removed in favor of the text iconic representation.

\start
Date: 28 Mar 2007 03:35:00 -0500
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: CAS for the masses

Tim Daly writes:

| Gaby writes:
| 
| > I suspect that agruments about typed language  in CAS may be more
| > convincing by studying cases where the type system does add value
| 
| I think that one canonical case is that Axiom strongly highlights the
| interaction between type, representation, and "simplification".
| 
| The usual example is:
| 
|   (1/2)*x^2 + (1/3)*x + 3
|                             Type: Polynomial Fraction Integer
| 
| %::Fraction(Polynomial(Integer))
| 
|       2
|     3x  + 2x + 18
|     -------------
|           6
|                             Type: Fraction Polynomial Integer
| 
| 
| Simplification is a hard problem because it is usually weakly defined
| (among other reasons such as the zero equivalence problem). Strong 
| typing allows you to define what "simple" means in a given type tower.

Thanks for the example, Tim.

The reason I asked for such example is that, from my experience with
teaching and working on programming languages, most people tend not to
see the value of typing in "abstract arguments".  They find it more
convincing when looking at more concrete examples -- many people have
grown up programming in typeless or scripting languages which let thme
quickly cook their solutions, and have trouble sitting down come up
with a solution that pleases arbitrary wishes of what they perceive as
obscure type system. 

| This kinds of simplification could be done using decomposition of the
| "string" form of the equation but that steps around the semantics.
| 
| Though not yet apparent strong typing really comes to the foreground
| when provisos are used. 

yes, but they ar ento yet in Axiom, so it is hard to make concrete
arrguments with it :-)

\start
Date: 28 Mar 2007 10:38:13 +0200
From: Martin Rubey
To: Waldek Hebisch
Subject: patch for binomial coefficient / bug 336

I just did svn up, many thanks for including the patches. However, for some
reason the documentation I provided for iibinom was not included. I take the
oportunity to elaborate, here is the documentation patch:

Martin

Index: combfunc.spad.pamphlet
===================================================================
--- combfunc.spad.pamphlet	(Revision 470)
+++ combfunc.spad.pamphlet	(Arbeitskopie)
@@ -1,5 +1,5 @@
 \documentclass{article}
-\usepackage{axiom}
+\usepackage{axiom, amsmath, amsfonts}
 \begin{document}
 \title{\$SPAD/src/algebra combfunc.spad}
 \author{Manuel Bronstein, Martin Rubey}
@@ -88,6 +88,53 @@
     binomial   : (F, F) -> F
       ++ binomial(n, r) returns the number of subsets of r objects
       ++ taken among n objects, i.e. n!/(r! * (n-r)!);
+@
+
+We currently simplify binomial coefficients only for non-negative integral
+second argument, using the formula
+$$ \binom{n}{k}=\frac{1}{k!}\prod_{i=0..k-1} (n-i),$$
+except if the second argument is symbolic: in this case [[binomial(n,n)]] is
+simplified to one.
+ 
+Note that there are at least two different ways to define binomial coefficients
+for negative integral second argument. One way, particular suitable for
+combinatorics, is to set the binomial coefficient equal to zero for negative
+second argument. This is, partially, also the approach taken in
+[[combinat.spad]], where we find
+
+\begin{verbatim}
+   binomial(n, m) ==
+      n < 0 or m < 0 or m > n => 0
+      m = 0 => 1
+\end{verbatim}
+
+Of course, here [[n]] and [[m]] are integers. This definition agrees with the
+recurrence
+
+$$\binom{n}{k}+\binom{n}{k+1}=\binom{n+1}{k+1}.$$
+
+Alternatively, one can use the formula
+$$ \binom{n}{k}=\frac{\Gamma(n+1)}{\Gamma(k+1)\Gamma(n-k+1)}, $$
+and leave the case where $k\in\mathbb Z$, $n\in\mathbb Z$ and $k \leq n < 0$
+undefined, since the limit does not exist in this case:
+
+Since we then have that $n-k+1\geq 1$, $\Gamma(n-k+1)$ is finite. So it is
+sufficient to consider $\frac{\Gamma(n+1)}{\Gamma(k+1)}$. On the one hand, we
+have
+$$\lim_{n_0\to n} \lim_{k_0\to k}\frac{\Gamma(n_0+1)}{\Gamma(k_0+1)} = 0,$$
+since for any non-integral $n_0$, $\Gamma(n_0+1)$ is finite. On the other
+hand,
+$$\lim_{k_0\to k} \lim_{n_0\to n}\frac{\Gamma(n_0+1)}{\Gamma(k_0+1)}$$
+does not exist, since for non-integral $k_0$, $\Gamma(k_0+1)$ is finite while
+$\Gamma(n_0+1)$ is unbounded.
+
+However, since for $k\in\mathbb Z$, $n\in\mathbb Z$ and $0 < k < n$ both
+definitions agree, one could also combine them. This is what, for example,
+Mathematica does. It seems that MuPAD sets [[binomial(n,n)=1]] for all
+arguments [[n]], and returns [[binomial(-2, n)]] unevaluated. Provisos may help
+here.
+
+<<package COMBF CombinatorialFunction>>=
     permutation: (F, F) -> F
       ++ permutation(n, r) returns the number of permutations of
       ++ n objects taken r at a time, i.e. n!/(n-r)!;
@@ -539,6 +586,16 @@
                => ibinom l
            binomial(r1::R, r2::R)::F
 
+@
+
+[[iibinom]] checks those cases in which the binomial coefficient may be
+evaluated explicitly. Note that up to [[patch--51]], the case where the second
+argument is a positive integer was not checked.(Issue~\#336) Currently, the
+naive iterative algorithm is used to calculate the coefficient, there is room
+for improvement here.
+
+<<package COMBF CombinatorialFunction>>=
+
       else
          iibinom l ==
            (r1 := retractIfCan(first l)@Union(R,"failed")) case "failed" or

\start
Date: 28 Mar 2007 10:45:53 +0200
From: Martin Rubey
To: Gabriel Dos Reis
Subject: Re: Examples for good types

Dear all,

Please reply only to axiom-math.

I very recently discovered another example, which I find (personally) more
convincing.

Axiom has a (rather weak, but still) domain for symmetric functions. 
The multiplication of two symmetric functions goes as follows:

(7) -> powerSum 4 * powerSum 2 * powerSum 2 * powerSum 2

            3
   (7)  (4 2 )
                                   Type: SymmetricPolynomial Fraction Integer

(i.e., it is represented as an integer partition, where equal parts are, as
customary, written as exponents.)

Symmetric Functions like determinants a lot, especially in Axiom:

m := matrix [[complete 1, complete 0],[complete 2, complete 1]]

        +     (1)        [] +
        |                   |
   (2)  |1       1   2      |
        |- (2) + - (1 )  (1)|
        +2       2          +
                            Type: Matrix SymmetricPolynomial Fraction Integer
(3) -> determinant m

          1       1   2
   (3)  - - (2) + - (1 )
          2       2
                                   Type: SymmetricPolynomial Fraction Integer

Note that Axiom uses the product in the ring of symmetric functions to compute
the determinant. To check, by Jacobi-Trudi the result should coincide with the
Schur function corresponding to the partition $(1,1)$:

(4) -> SFunction [1,1]

          1       1   2
   (4)  - - (2) + - (1 )
          2       2
                                   Type: SymmetricPolynomial Fraction Integer

\start
Date: 28 Mar 2007 10:53:02 +0200
From: Martin Rubey
To: Waldek Hebisch
Subject: new problem compiling wh-sandbox,

Dear Waldek,

I just tried to compile wh-sandbox on my laptop.

I used the preinstalled noweb, but copied gcl into the source tree.  Then I
said:

-------------------------------------------------------------------------------
cd /tmp
make ax-build
~/wh-sandbox/configure --prefix=$HOME
make
-------------------------------------------------------------------------------

However, make failed, with the message

Stage 2 copy
cp: cannot stat 'ALIST.NRLIB/code.o': No such file or directory

indeed, ALIST.NRLIB is missing, although many other NRLIB's are present:

./int/algebra/AHYP.NRLIB
./int/algebra/ATTREG.NRLIB
./int/algebra/CFCAT.NRLIB
./int/algebra/ELTAB.NRLIB
./int/algebra/KOERCE.NRLIB
./int/algebra/OM.NRLIB
./int/algebra/KONVERT.NRLIB
./int/algebra/SPFCAT.NRLIB
./int/algebra/PRIMCAT.NRLIB
./int/algebra/PTRANFN.NRLIB
./int/algebra/TYPE.NRLIB
./int/algebra/AGG.NRLIB
./int/algebra/BASTYPE.NRLIB
./int/algebra/IEVALAB.NRLIB
./int/algebra/EVALAB.NRLIB
./int/algebra/SETCAT.NRLIB
./int/algebra/HOAGG.NRLIB
./int/algebra/CLAGG.NRLIB
./int/algebra/RADCAT.NRLIB
./int/algebra/ATRIG.NRLIB
./int/algebra/RETRACT.NRLIB
./int/algebra/TRIGCAT.NRLIB
./int/algebra/HYPCAT.NRLIB
./int/algebra/ELTAGG.NRLIB
./int/algebra/ELEMFUN.NRLIB
./int/algebra/IXAGG.NRLIB
./int/algebra/LNAGG.NRLIB
./int/algebra/ORDSET.NRLIB
./int/algebra/FLAGG.NRLIB
./int/algebra/A1AGG.NRLIB
./int/algebra/ABELSG.NRLIB
./int/algebra/CABMON.NRLIB
./int/algebra/ABELMON.NRLIB
./int/algebra/MODULE.NRLIB
./int/algebra/ABELGRP.NRLIB
./int/algebra/LMODULE.NRLIB
./int/algebra/RMODULE.NRLIB
./int/algebra/BMODULE.NRLIB
./int/algebra/SGROUP.NRLIB
./int/algebra/MONOID.NRLIB
./int/algebra/RNG.NRLIB
./int/algebra/RING.NRLIB
./int/algebra/INTDOM.NRLIB
./int/algebra/ALGEBRA.NRLIB
./int/algebra/COMRING.NRLIB
./int/algebra/ENTIRER.NRLIB
./int/algebra/DIVRING.NRLIB
./int/algebra/GCDDOM.NRLIB
./int/algebra/PID.NRLIB
./int/algebra/EUCDOM.NRLIB
./int/algebra/UFD.NRLIB
./int/algebra/FIELD.NRLIB
./int/algebra/ACF.NRLIB
./int/algebra/CHARNZ.NRLIB
./int/algebra/CHARZ.NRLIB
./int/algebra/ES.NRLIB
./int/algebra/LINEXP.NRLIB
./int/algebra/PATMAB.NRLIB
./int/algebra/FLINEXP.NRLIB
./int/algebra/GROUP.NRLIB
./int/algebra/FPATMAB.NRLIB
./int/algebra/FRETRCT.NRLIB
./int/algebra/PDRING.NRLIB
./int/algebra/PATAB.NRLIB
./int/algebra/FS.NRLIB
./int/algebra/ACFS.NRLIB
./int/algebra/BGAGG.NRLIB
./int/algebra/DIOPS.NRLIB
./int/algebra/DIAGG.NRLIB
./int/algebra/ELAGG.NRLIB
./int/algebra/KDAGG.NRLIB
./int/algebra/RCAGG.NRLIB
./int/algebra/URAGG.NRLIB
./int/algebra/STAGG.NRLIB
./int/algebra/LSAGG.NRLIB
./int/algebra/TBAGG.NRLIB
./int/algebra/ALAGG.NRLIB
./int/algebra/AMR.NRLIB
./int/algebra/BRAGG.NRLIB
./int/algebra/ARR2CAT.NRLIB
./int/algebra/LOGIC.NRLIB
./int/algebra/BTAGG.NRLIB
./int/algebra/BTCAT.NRLIB
./int/algebra/DIFEXT.NRLIB
./int/algebra/CACHSET.NRLIB
./int/algebra/COMBOPC.NRLIB
./int/algebra/DIFRING.NRLIB
./int/algebra/FPC.NRLIB
./int/algebra/FINITE.NRLIB
./int/algebra/STEP.NRLIB
./int/algebra/PFECAT.NRLIB
./int/algebra/FFIELDC.NRLIB
./int/algebra/FINRALG.NRLIB
./int/algebra/FRAMALG.NRLIB
./int/algebra/FEVALAB.NRLIB
./int/algebra/MONOGEN.NRLIB
./int/algebra/OASGP.NRLIB
./int/algebra/TRANFUN.NRLIB
./int/algebra/COMPCAT.NRLIB
./int/algebra/OAMON.NRLIB
./int/algebra/OCAMON.NRLIB
./int/algebra/OAMONS.NRLIB
./int/algebra/OAGROUP.NRLIB
./int/algebra/VSPACE.NRLIB
./int/algebra/ORDRING.NRLIB
./int/algebra/DLAGG.NRLIB
./int/algebra/DIRPCAT.NRLIB
./int/algebra/FAMR.NRLIB
./int/algebra/QUAGG.NRLIB
./int/algebra/POLYCAT.NRLIB
./int/algebra/DPOLCAT.NRLIB
./int/algebra/SKAGG.NRLIB
./int/algebra/DQAGG.NRLIB
./int/algebra/FAMONC.NRLIB
./int/algebra/DVARCAT.NRLIB
./int/algebra/XF.NRLIB
./int/algebra/FAXF.NRLIB
./int/algebra/FFCAT.NRLIB
./int/algebra/FDIVCAT.NRLIB
./int/algebra/MONAD.NRLIB
./int/algebra/FILECAT.NRLIB
./int/algebra/NARNG.NRLIB
./int/algebra/NAALG.NRLIB
./int/algebra/LIECAT.NRLIB
./int/algebra/FINAALG.NRLIB
./int/algebra/FLALG.NRLIB
./int/algebra/FMC.NRLIB
./int/algebra/FORTCAT.NRLIB
./int/algebra/FMCAT.NRLIB
./int/algebra/FMFUN.NRLIB
./int/algebra/FMTC.NRLIB
./int/algebra/FNCAT.NRLIB
./int/algebra/FORTFN.NRLIB
./int/algebra/REAL.NRLIB
./int/algebra/RNS.NRLIB
./int/algebra/FPS.NRLIB
./int/algebra/SETAGG.NRLIB
./int/algebra/FRNAALG.NRLIB
./int/algebra/FSAGG.NRLIB
./int/algebra/FVC.NRLIB
./int/algebra/FVFUN.NRLIB
./int/algebra/GRMOD.NRLIB
./int/algebra/GRALG.NRLIB
./int/algebra/IDPC.NRLIB
./int/algebra/INS.NRLIB
./int/algebra/OINTDOM.NRLIB
./int/algebra/INTCAT.NRLIB
./int/algebra/LALG.NRLIB
./int/algebra/LFCAT.NRLIB
./int/algebra/MATCAT.NRLIB
./int/algebra/OREPCAT.NRLIB
./int/algebra/LODOCAT.NRLIB
./int/algebra/LZSTAGG.NRLIB
./int/algebra/MDAGG.NRLIB
./int/algebra/MLO.NRLIB
./int/algebra/PSCAT.NRLIB
./int/algebra/MONADWU.NRLIB
./int/algebra/MSETAGG.NRLIB
./int/algebra/MTSCAT.NRLIB
./int/algebra/NTSCAT.NRLIB
./int/algebra/NASRING.NRLIB
./int/algebra/PSETCAT.NRLIB
./int/algebra/TSETCAT.NRLIB
./int/algebra/RSETCAT.NRLIB
./int/algebra/NUMINT.NRLIB
./int/algebra/OC.NRLIB
./int/algebra/ODECAT.NRLIB
./int/algebra/PRQAGG.NRLIB
./int/algebra/OMSAGG.NRLIB
./int/algebra/OPTCAT.NRLIB
./int/algebra/ORDFIN.NRLIB
./int/algebra/ORDMON.NRLIB
./int/algebra/PDECAT.NRLIB
./int/algebra/PADICCT.NRLIB
./int/algebra/PTCAT.NRLIB
./int/algebra/PERMCAT.NRLIB
./int/algebra/PPCURVE.NRLIB
./int/algebra/PSCURVE.NRLIB
./int/algebra/VECTCAT.NRLIB
./int/algebra/QFCAT.NRLIB
./int/algebra/RRCC.NRLIB
./int/algebra/QUATCAT.NRLIB
./int/algebra/RCFIELD.NRLIB
./int/algebra/RMATCAT.NRLIB
./int/algebra/RPOLCAT.NRLIB
./int/algebra/SEGCAT.NRLIB
./int/algebra/SEXCAT.NRLIB
./int/algebra/SEGXCAT.NRLIB
./int/algebra/SPACEC.NRLIB
./int/algebra/SFRTCAT.NRLIB
./int/algebra/SMATCAT.NRLIB
./int/algebra/SNTSCAT.NRLIB
./int/algebra/SRAGG.NRLIB
./int/algebra/UPSCAT.NRLIB
./int/algebra/STRICAT.NRLIB
./int/algebra/ULSCAT.NRLIB
./int/algebra/UPOLYC.NRLIB
./int/algebra/ULSCCAT.NRLIB
./int/algebra/UTSCAT.NRLIB
./int/algebra/UPXSCAT.NRLIB
./int/algebra/UPXSCCA.NRLIB
./int/algebra/XALG.NRLIB
./int/algebra/XFALG.NRLIB
./int/algebra/XPOLYC.NRLIB
./int/algebra/BASTYPE-.NRLIB
./int/algebra/IEVALAB-.NRLIB
./int/algebra/AGG-.NRLIB
./int/algebra/EVALAB-.NRLIB
./int/algebra/SETCAT-.NRLIB
./int/algebra/HOAGG-.NRLIB
./int/algebra/CLAGG-.NRLIB
./int/algebra/RADCAT-.NRLIB
./int/algebra/RETRACT-.NRLIB
./int/algebra/TRIGCAT-.NRLIB
./int/algebra/ATRIG-.NRLIB
./int/algebra/HYPCAT-.NRLIB
./int/algebra/ELEMFUN-.NRLIB
./int/algebra/ELTAGG-.NRLIB
./int/algebra/IXAGG-.NRLIB
./int/algebra/LNAGG-.NRLIB
./int/algebra/ORDSET-.NRLIB
./int/algebra/FLAGG-.NRLIB
./int/algebra/A1AGG-.NRLIB
./int/algebra/ABELSG-.NRLIB
./int/algebra/ABELMON-.NRLIB
./int/algebra/ABELGRP-.NRLIB
./int/algebra/MODULE-.NRLIB
./int/algebra/SGROUP-.NRLIB
./int/algebra/MONOID-.NRLIB
./int/algebra/RING-.NRLIB
./int/algebra/ALGEBRA-.NRLIB
./int/algebra/DIVRING-.NRLIB
./int/algebra/INTDOM-.NRLIB
./int/algebra/GCDDOM-.NRLIB
./int/algebra/EUCDOM-.NRLIB
./int/algebra/UFD-.NRLIB
./int/algebra/FIELD-.NRLIB
./int/algebra/ACF-.NRLIB
./int/algebra/ES-.NRLIB
./int/algebra/FLINEXP-.NRLIB
./int/algebra/FRETRCT-.NRLIB
./int/algebra/GROUP-.NRLIB
./int/algebra/PDRING-.NRLIB
./int/algebra/FS-.NRLIB
./int/algebra/ACFS-.NRLIB
./int/algebra/BGAGG-.NRLIB
./int/algebra/DIOPS-.NRLIB
./int/algebra/DIAGG-.NRLIB
./int/algebra/ELAGG-.NRLIB
./int/algebra/KDAGG-.NRLIB
./int/algebra/RCAGG-.NRLIB
./int/algebra/URAGG-.NRLIB
./int/algebra/STAGG-.NRLIB
./int/algebra/LSAGG-.NRLIB
./int/algebra/TBAGG-.NRLIB
./int/algebra/AMR-.NRLIB
./int/algebra/ARR2CAT-.NRLIB
./int/algebra/BRAGG-.NRLIB
./int/algebra/LOGIC-.NRLIB
./int/algebra/BTAGG-.NRLIB
./int/algebra/BTCAT-.NRLIB
./int/algebra/DIFRING-.NRLIB
./int/algebra/DIFEXT-.NRLIB
./int/algebra/FPC-.NRLIB
./int/algebra/FFIELDC-.NRLIB
./int/algebra/FINRALG-.NRLIB
./int/algebra/FRAMALG-.NRLIB
./int/algebra/FEVALAB-.NRLIB
./int/algebra/MONOGEN-.NRLIB
./int/algebra/PFECAT-.NRLIB
./int/algebra/TRANFUN-.NRLIB
./int/algebra/COMPCAT-.NRLIB
./int/algebra/ORDRING-.NRLIB
./int/algebra/VSPACE-.NRLIB
./int/algebra/DIRPCAT-.NRLIB
./int/algebra/FAMR-.NRLIB
./int/algebra/POLYCAT-.NRLIB
./int/algebra/DPOLCAT-.NRLIB
./int/algebra/DVARCAT-.NRLIB
./int/algebra/XF-.NRLIB
./int/algebra/FAXF-.NRLIB
./int/algebra/FDIVCAT-.NRLIB
./int/algebra/FFCAT-.NRLIB

\start
Date: Wed, 28 Mar 2007 10:56:04 +0200
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: Re: CAS for the masses

> | The usual example is:
> | 
> |   (1/2)*x^2 + (1/3)*x + 3
> |                             Type: Polynomial Fraction Integer
> | 
> | %::Fraction(Polynomial(Integer))
> | 
> |       2
> |     3x  + 2x + 18
> |     -------------
> |           6
> |                             Type: Fraction Polynomial Integer

I've just cooked up another one...

(1) -> P := Polynomial FiniteField(5,1)
(1) ->
    (1)  Polynomial FiniteField(5,1)
                            Type: Domain
(2) -> p: P := x+y
    (2)  y + x
                            Type: Polynomial FiniteField(5,1)
(3) -> p^5
          5    5
    (3)  y  + x
(4) -> a: FiniteField(2,1) := 1
    (4)  1
                            Type: FiniteField(2,1)
(5) -> a+a
(5) ->
    (5)  0

\start
Date: 28 Mar 2007 04:17:12 -0500
From: Gabriel Dos Reis
To: Martin Rubey
Subject: Re: new problem compiling wh-sandbox,
Cc: Waldek Hebisch

Martin Rubey writes:

| Dear Waldek,
| 
| I just tried to compile wh-sandbox on my laptop.
| 
| I used the preinstalled noweb, but copied gcl into the source tree.  Then I
| said:
| 
| -------------------------------------------------------------------------------
| cd /tmp
| make ax-build
| ~/wh-sandbox/configure --prefix=$HOME
| make
| -------------------------------------------------------------------------------
| 
| However, make failed, with the message
| 
| Stage 2 copy
| cp: cannot stat 'ALIST.NRLIB/code.o': No such file or directory

It is likely that its compilation produced an error -- cuirrently we
miss the functionality of stopping the build process if an error is
encountered with the Lisp translator/compiler.
(I hope to fix that soon).

Could you look at the build log, especially build/i686-pc-linux-gnu/trace
(assuming you're running GNU/Linux and your laptop is x86 based?)

\start
Date: Wed, 28 Mar 2007 12:29:48 +0200
From: Ondrej Certik
To: Tim Daly
Subject: Re: CAS for the masses
Cc: Gabriel Dos Reis

> The usual example is:
>
>   (1/2)*x^2 + (1/3)*x + 3
>                             Type: Polynomial Fraction Integer
>
> %::Fraction(Polynomial(Integer))
>
>       2
>     3x  + 2x + 18
>     -------------
>           6
>                             Type: Fraction Polynomial Integer
>
>
> When you read a maths book most of the equations are actually just
> "icons". The real meaning of the equation is in the surrounding text
> and context. Axiom carries that surrounding information in the type
> whereas other systems focus on the "icons" and syntactic manipulations.


I have this question:

The above expressions can be assembled just from these 4 types (or
classes in SymPy): Add, Mul, Pow, Integer

what is the advantage to introduce more classes, like Polynomial
Fraction Integer or Fraction Polynomial Integer?

Because having the expression in the form of the 4 basic classes (Add,
Mul, Pow, Integer), everything else can be easily inferred from this.

\start
Date: Wed, 28 Mar 2007 12:50:19 +0200
From: Ralf Hemmecke
To: Ondrej Certik
Subject: Re: CAS for the masses
Cc: Gabriel Dos Reis

On 03/28/2007 12:29 PM, Ondrej Certik wrote:
>> The usual example is:
>>
>>   (1/2)*x^2 + (1/3)*x + 3
>>                             Type: Polynomial Fraction Integer
>>
>> %::Fraction(Polynomial(Integer))
>>
>>       2
>>     3x  + 2x + 18
>>     -------------
>>           6
>>                             Type: Fraction Polynomial Integer
>>
>>
>> When you read a maths book most of the equations are actually just
>> "icons". The real meaning of the equation is in the surrounding text
>> and context. Axiom carries that surrounding information in the type
>> whereas other systems focus on the "icons" and syntactic manipulations.
> 
> 
> I have this question:
> 
> The above expressions can be assembled just from these 4 types (or
> classes in SymPy): Add, Mul, Pow, Integer
> 
> what is the advantage to introduce more classes, like Polynomial
> Fraction Integer or Fraction Polynomial Integer?
> 
> Because having the expression in the form of the 4 basic classes (Add,
> Mul, Pow, Integer), everything else can be easily inferred from this.

Even mathematically
   Fraction Polynomial Integer    ---- QQ(Z[x,y,z,...])
and
   Polynomial Fraction Integer    ---- Q[x,y,z,...]
are not the same.
1/x lies in the first, but not in the second domain.
(By QQ I mean the operator to form the field of fractions.)

But there is something else with that example. Some people prefer the 
first and some the second form. There is simply not THE simplest form.

Suppose you have the equations

3*x*p-1=0

and you want to solve it for p.

Clearly, the solution in QQ(Z[x]) is 1/(3*x).
The solution in Q[x] is... *no solution*.

Do you see that there is a difference.

\start
Date: 28 Mar 2007 12:59:15 +0200
From: Martin Rubey
To: Ondrej Certik
Subject: Re: Advantage of Types and different representations
Cc: Gabriel Dos Reis

Dear all,


Please reply to axiom-math@nongnu.org.

Ondrej Certik writes:

> >       2
> >     3x  + 2x + 18
> >     -------------
> >           6
> >                             Type: Fraction Polynomial Integer

> The above expressions can be assembled just from these 4 types (or classes in
> SymPy): Add, Mul, Pow, Integer
> 
> what is the advantage to introduce more classes, like Polynomial Fraction
> Integer or Fraction Polynomial Integer?

You get a normal form for free, keeping a lot of flexibility. Apart from that,
it is not correct that we introduce a class "Fraction Polynomial Integer". We
introduce a function "Fraction", a function "Polynomial" and a function
"Integer".

A normal form for "expressions" composed with Add, Mul, Pow, Integer does not
exist, if I am not mistaken. Using types, you can very easily restrict
"attention" to classes where normal forms do exist.

Maybe polynomials are a bad example, since they are so well known. I propose
another example: Algebraic Differential Equations. Although they do not allow a
normal form, it seems. But you can still test for zero.

It would not take so much time to implement a domain that deals with such
functions. And, I guess, in SymPy, you would not be able to distinguish an ADE
from any other "expression", because in SymPy, I guess, objects are not typed.

Another example, again: how would you multiply symmetric functions in SymPy? Or
Maple or Mathematica, if you prefer.

> Because having the expression in the form of the 4 basic classes (Add, Mul,
> Pow, Integer), everything else can be easily inferred from this.

I should add: it is indeed useful to have such a representation, too. (called:
ExpressionTree). Many things are easier to do with ExpressionTrees. But even
better is to have both, as we do in Axiom/Aldor.

\start
Date: 28 Mar 2007 13:01:57 +0200
From: Martin Rubey
To: Gabriel Dos Reis
Subject: Re: new problem compiling wh-sandbox,	rev 470 (urgent...)
Cc: Waldek Hebisch

Dear Gaby,

thanks for the hint. It seems, however, that I had a singular problem. Wiping
out tmp and starting fresh seems to work. 

Sorry to alert you,

Martin

Gabriel Dos Reis writes:

> Martin Rubey writes:
> 
> | Dear Waldek,
> | 
> | I just tried to compile wh-sandbox on my laptop.
> | 
> | I used the preinstalled noweb, but copied gcl into the source tree.  Then I
> | said:
> | 
> | -------------------------------------------------------------------------------
> | cd /tmp
> | make ax-build
> | ~/wh-sandbox/configure --prefix=$HOME
> | make
> | -------------------------------------------------------------------------------
> | 
> | However, make failed, with the message
> | 
> | Stage 2 copy
> | cp: cannot stat 'ALIST.NRLIB/code.o': No such file or directory
> 
> It is likely that its compilation produced an error -- cuirrently we
> miss the functionality of stopping the build process if an error is
> encountered with the Lisp translator/compiler.
> (I hope to fix that soon).
> 
> Could you look at the build log, especially build/i686-pc-linux-gnu/trace
> (assuming you're running GNU/Linux and your laptop is x86 based?)

\start
Date: 28 Mar 2007 06:19:10 -0500
From: Gabriel Dos Reis
To: Ondrej Certik
Subject: Re: CAS for the masses

Ondrej Certik writes:

| > The usual example is:
| >
| >   (1/2)*x^2 + (1/3)*x + 3
| >                             Type: Polynomial Fraction Integer
| >
| > %::Fraction(Polynomial(Integer))
| >
| >       2
| >     3x  + 2x + 18
| >     -------------
| >           6
| >                             Type: Fraction Polynomial Integer
| >
| >
| > When you read a maths book most of the equations are actually just
| > "icons". The real meaning of the equation is in the surrounding text
| > and context. Axiom carries that surrounding information in the type
| > whereas other systems focus on the "icons" and syntactic manipulations.
| 
| 
| I have this question:
| 
| The above expressions can be assembled just from these 4 types (or
| classes in SymPy): Add, Mul, Pow, Integer
| 
| what is the advantage to introduce more classes, like Polynomial
| Fraction Integer or Fraction Polynomial Integer?


I see Add, Mul, Pow, and Integer as members of the low-level Symbolic
and Algebraic Instruction Set (similar to usual ISA for chips).  So
your question, if I understanding it correctly, is what is the
advantage of writing the above in a high level typed language, over a
simple stream of assembly instructions. 

I suspect a definitive convincing argument is hard to make on a very
simple example like the above  -- though it is definitively convincing
to the eyes of the seasoned CAS implementer and practioner.

However, like is the case for uses of strongly typed programming
languages in software development, I suspect the answer is in the use
of programming-in-the-large, i.e. developing libraries to attack
larger and harder problems in Computational sciences.  My usual
references for rationale of types in software development are these
two excellent papers of Luca Cardelli:

  * On Understanding Types, Data Abstraction, and Polymorphism
    http://lucacardelli.name/Papers/OnUnderstanding.A4.pdf

  * Typeful Programming
    http://www.lucacardelli.name/Papers/TypefulProg.pdf

| Because having the expression in the form of the 4 basic classes (Add,
| Mul, Pow, Integer), everything else can be easily inferred from this.

Tim mentioned the problem of zero-equivalence, which is known to be
undecidable in general.  However, they are classes of expressions for
which it is decidable and algorithms are known.  Types let you easily 
identify and *label* members of those expressions, *independently of
they low-level representations* in terms of the Symbolic and Algebraic
Instruction Set.  The use of type conveys additional meaning, usually
lost in explanations (or surrounding text as Tim put it), into object
representations.  You may be able to infer those meaning through
through ad-hoc informal reading, such as "it is obvious that

   (1/2)*x^2 + (1/3)*x + 3

and

       2
     3x  + 2x + 18
     -------------
           6

represents the same entity and only the representation changes.
However, the former attaches to the representation the crucial
information that it is polynomial over fractions of integer, and the
latter is a fraction of polynomial over integers.  Those crucial
information are part of the representation of the object, and not
something left to be inferred by an external tool that would rely
on "common sense" or "ad hoc reading".  Whether those information are
relevant or not depend on the context of uses.  And definitely in a
large scale library or problem, they do matter.  For example, they act
as control over which operations can be meaningfully applied to the
objects.  Again, I refer back to Luca Cardelli's paper about the value
of types in software development.

\start
Date: Wed, 28 Mar 2007 13:42:26 +0200
From: Ondrej Certik
To: Gabriel Dos Reis
Subject: Re: CAS for the masses

Hi, those are arguments for using types, I understand that.

Expression tree (Add, Mul,...) are very low level types, and you have
many algorithms, that work with high level types like Polynomial,
Fraction, ODE, DAE, PDE, etc. I understand that.

The question is - how the Axiom converts from the low level
representation to the high level?

A place that occurs to me to do it is just right after the evaluation
to the canonical form:

like Add(x,x) automatically converts to Mul(2,x)  and here, at this
place, the CAS would check the expression and says: hey - the Mul(2,x)
is a polynomial, let's return a Polynomial class instead.

This would make sense to me, and we could do it in SymPy as well.

Ondrej

On 28 Mar 2007 06:19:10 -0500, Gabriel Dos Reis wrote:
> Ondrej Certik writes:
>
> | > The usual example is:
> | >
> | >   (1/2)*x^2 + (1/3)*x + 3
> | >                             Type: Polynomial Fraction Integer
> | >
> | > %::Fraction(Polynomial(Integer))
> | >
> | >       2
> | >     3x  + 2x + 18
> | >     -------------
> | >           6
> | >                             Type: Fraction Polynomial Integer
> | >
> | >
> | > When you read a maths book most of the equations are actually just
> | > "icons". The real meaning of the equation is in the surrounding text
> | > and context. Axiom carries that surrounding information in the type
> | > whereas other systems focus on the "icons" and syntactic manipulations.
> |
> |
> | I have this question:
> |
> | The above expressions can be assembled just from these 4 types (or
> | classes in SymPy): Add, Mul, Pow, Integer
> |
> | what is the advantage to introduce more classes, like Polynomial
> | Fraction Integer or Fraction Polynomial Integer?
>
>
> I see Add, Mul, Pow, and Integer as members of the low-level Symbolic
> and Algebraic Instruction Set (similar to usual ISA for chips).  So
> your question, if I understanding it correctly, is what is the
> advantage of writing the above in a high level typed language, over a
> simple stream of assembly instructions.
>
> I suspect a definitive convincing argument is hard to make on a very
> simple example like the above  -- though it is definitively convincing
> to the eyes of the seasoned CAS implementer and practioner.
>
> However, like is the case for uses of strongly typed programming
> languages in software development, I suspect the answer is in the use
> of programming-in-the-large, i.e. developing libraries to attack
> larger and harder problems in Computational sciences.  My usual
> references for rationale of types in software development are these
> two excellent papers of Luca Cardelli:
>
>   * On Understanding Types, Data Abstraction, and Polymorphism
>     http://lucacardelli.name/Papers/OnUnderstanding.A4.pdf
>
>   * Typeful Programming
>     http://www.lucacardelli.name/Papers/TypefulProg.pdf
>
> | Because having the expression in the form of the 4 basic classes (Add,
> | Mul, Pow, Integer), everything else can be easily inferred from this.
>
> Tim mentioned the problem of zero-equivalence, which is known to be
> undecidable in general.  However, they are classes of expressions for
> which it is decidable and algorithms are known.  Types let you easily
> identify and *label* members of those expressions, *independently of
> they low-level representations* in terms of the Symbolic and Algebraic
> Instruction Set.  The use of type conveys additional meaning, usually
> lost in explanations (or surrounding text as Tim put it), into object
> representations.  You may be able to infer those meaning through
> through ad-hoc informal reading, such as "it is obvious that
>
>    (1/2)*x^2 + (1/3)*x + 3
>
> and
>
>        2
>      3x  + 2x + 18
>      -------------
>            6
>
> represents the same entity and only the representation changes.
> However, the former attaches to the representation the crucial
> information that it is polynomial over fractions of integer, and the
> latter is a fraction of polynomial over integers.  Those crucial
> information are part of the representation of the object, and not
> something left to be inferred by an external tool that would rely
> on "common sense" or "ad hoc reading".  Whether those information are
> relevant or not depend on the context of uses.  And definitely in a
> large scale library or problem, they do matter.  For example, they act
> as control over which operations can be meaningfully applied to the
> objects.  Again, I refer back to Luca Cardelli's paper about the value
> of types in software development.

\start
Date: 28 Mar 2007 14:28:19 +0200
From: Martin Rubey
To: list
Subject: Re: new problem compiling wh-sandbox, rev 470 (urgent...)
Cc: Waldek Hebisch, Gabriel Dos Reis

Martin Rubey writes:

> Dear Gaby,
> 
> thanks for the hint. It seems, however, that I had a singular problem. Wiping
> out tmp and starting fresh seems to work. 

Ai, it does not. Now it fails for ISUPS. Please help, I need it tomorrow for a
presentation!


compiling ISUPS.c by hand using


gcc -c -Wall -DVOL=volatile -fsigned-char -pipe
-I/home/martin/ax-build/build/i686-pc-linux/lib/gcl-2.6.8/unixport/../h  -O3
-fomit-frame-pointer -c "ISUPS.NRLIB/ISUPS.c" -o "ISUPS.NRLIB/ISUPS.o" -w

produced an ISUPS.o, but running make again failed at the same point.

Martin

gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.0 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-java-awt=gtk-default --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre --enable-mpfr
--disable-werror --with-tune=pentium4 --enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.0.3 (Ubuntu 4.0.3-1ubuntu5)

here is the end of the trace file:

(1) -> GCL (GNU Common Lisp)  2.6.8 CLtL1    Mar 28 2007 11:19:58
Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
Binary License:  GPL due to GPL'ed components: (BFD UNEXEC)
Modifications of this banner must retain notice of a compatible license
Dedicated to the memory of W. Schelter

Use (help) to get some basic information on how to use GCL.
Temporary directory for compiler files set to /tmp/
                        AXIOM Computer Algebra System 
             Version: Axiom build-improvements branch 2006-11-26
              Timestamp: Wednesday March 28, 2007 at 11:41:41 
-----------------------------------------------------------------------------
   Issue )copyright to view copyright notices.
   Issue )summary for a summary of useful system commands.
   Issue )quit to leave AXIOM and return to shell.
-----------------------------------------------------------------------------
 
   Using local database /home/martin/wh-sandbox/src/share/algebra/compress.daase..   Using local database /home/martin/wh-sandbox/src/share/algebra/interp.daase..
   Using local database /home/martin/wh-sandbox/src/share/algebra/operation.daase..
   Using local database /home/martin/wh-sandbox/src/share/algebra/category.daase..
   Using local database /home/martin/wh-sandbox/src/share/algebra/browse.daase..
(1) ->    Loading /home/martin/ax-build/target/i686-pc-linux/autoload/apply.
   Loading /home/martin/ax-build/target/i686-pc-linux/autoload/c-doc.
   Loading /home/martin/ax-build/target/i686-pc-linux/autoload/c-util.
   Loading /home/martin/ax-build/target/i686-pc-linux/autoload/profile.
   Loading /home/martin/ax-build/target/i686-pc-linux/autoload/category.
   Loading /home/martin/ax-build/target/i686-pc-linux/autoload/compiler.
   Loading /home/martin/ax-build/target/i686-pc-linux/autoload/define.
   Loading /home/martin/ax-build/target/i686-pc-linux/autoload/functor.
   Loading /home/martin/ax-build/target/i686-pc-linux/autoload/info.
   Loading /home/martin/ax-build/target/i686-pc-linux/autoload/iterator.
   Loading /home/martin/ax-build/target/i686-pc-linux/autoload/modemap.
   Loading /home/martin/ax-build/target/i686-pc-linux/autoload/nruncomp.
   Loading /home/martin/ax-build/target/i686-pc-linux/autoload/package.
   Loading /home/martin/ax-build/target/i686-pc-linux/autoload/htcheck.
Warning: macro table not found
   Compiling AXIOM source code from file 
      /home/martin/ax-build/int/algebra/ISUPS.spad using old system 
      compiler.
   Loading /home/martin/ax-build/target/i686-pc-linux/autoload/parsing.
   Loading /home/martin/ax-build/target/i686-pc-linux/autoload/bootlex.
   Loading /home/martin/ax-build/target/i686-pc-linux/autoload/def.
   Loading /home/martin/ax-build/target/i686-pc-linux/autoload/fnewmeta.
   Loading /home/martin/ax-build/target/i686-pc-linux/autoload/metalex.
   Loading /home/martin/ax-build/target/i686-pc-linux/autoload/metameta.
   Loading /home/martin/ax-build/target/i686-pc-linux/autoload/parse.
   Loading /home/martin/ax-build/target/i686-pc-linux/autoload/postpar.
   Loading /home/martin/ax-build/target/i686-pc-linux/autoload/preparse.
   ISUPS abbreviates domain InnerSparseUnivariatePowerSeries 
   processing macro definition B ==> Boolean 
   processing macro definition COM ==> OrderedCompletion Integer 
   processing macro definition I ==> Integer 
   processing macro definition L ==> List 
   processing macro definition NNI ==> NonNegativeInteger 
   processing macro definition OUT ==> OutputForm 
   processing macro definition PI ==> PositiveInteger 
   processing macro definition REF ==> Reference OrderedCompletion Integer 
   processing macro definition RN ==> Fraction Integer 
   processing macro definition Term ==> Record(k: Integer,c: Coef) 
   processing macro definition SG ==> String 
   processing macro definition ST ==> Stream Record(k: Integer,c: Coef) 
   processing macro definition Exports ==> -- the constructor category 
   processing macro definition Implementation ==> -- the constructor capsule 
------------------------------------------------------------------------
   initializing NRLIB ISUPS for InnerSparseUnivariatePowerSeries 
   compiling into NRLIB ISUPS 
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/UPSCAT.o 
      for category UnivariatePowerSeriesCategory 
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/PSCAT.o 
      for category PowerSeriesCategory 
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/AMR.o for
      category AbelianMonoidRing 
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/RING.o 
      for category Ring 
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/RNG.o for
      category Rng 
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/ABELGRP.o
      for category AbelianGroup 
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/CABMON.o 
      for category CancellationAbelianMonoid 
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/ABELMON.o
      for category AbelianMonoid 
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/ABELSG.o 
      for category AbelianSemiGroup 
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/SETCAT.o 
      for category SetCategory 
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/BASTYPE.o
      for category BasicType 
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/KOERCE.o 
      for category CoercibleTo 
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/SGROUP.o 
      for category SemiGroup 
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/MONOID.o 
      for category Monoid 
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/LMODULE.o
      for category LeftModule 
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/BMODULE.o
      for category BiModule 
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/RMODULE.o
      for category RightModule 
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/COMRING.o
      for category CommutativeRing 
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/ALGEBRA.o
      for category Algebra 
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/MODULE.o 
      for category Module 
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/CHARZ.o 
      for category CharacteristicZero 
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/CHARNZ.o 
      for category CharacteristicNonZero 
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/INTDOM.o 
      for category IntegralDomain 
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/ENTIRER.o
      for category EntireRing 
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/ELTAB.o 
      for category Eltable 
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/DIFRING.o
      for category DifferentialRing 
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/PDRING.o 
      for category PartialDifferentialRing 
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/INS.o for
      category IntegerNumberSystem 
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/UFD.o for
      category UniqueFactorizationDomain 
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/GCDDOM.o 
      for category GcdDomain 
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/EUCDOM.o 
      for category EuclideanDomain 
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/PID.o for
      category PrincipalIdealDomain 
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/OINTDOM.o
      for category OrderedIntegralDomain 
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/ORDRING.o
      for category OrderedRing 
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/OAGROUP.o
      for category OrderedAbelianGroup 
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/OCAMON.o 
      for category OrderedCancellationAbelianMonoid 
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/OAMON.o 
      for category OrderedAbelianMonoid 
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/OASGP.o 
      for category OrderedAbelianSemiGroup 
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/ORDSET.o 
      for category OrderedSet 
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/KONVERT.o
      for category ConvertibleTo 
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/RETRACT.o
      for category RetractableTo 
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/LINEXP.o 
      for category LinearlyExplicitRingOver 
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/PATMAB.o 
      for category PatternMatchable 
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/CFCAT.o 
      for category CombinatorialFunctionCategory 
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/REAL.o 
      for category RealConstant 
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/STEP.o 
      for category StepThrough 
   importing Reference OrderedCompletion Integer
   compiling local makeTerm : (Integer,Coef) -> Record(k: Integer,c: Coef)
      ISUPS;makeTerm is replaced by CONS 
Time: 0.13 SEC.

   compiling local getCoef : Record(k: Integer,c: Coef) -> Coef
      ISUPS;getCoef is replaced by QCDR 
Time: 0 SEC.

   compiling local getExpon : Record(k: Integer,c: Coef) -> Integer
      ISUPS;getExpon is replaced by QCAR 
Time: 0.01 SEC.

   compiling exported makeSeries : (Reference OrderedCompletion Integer,Stream Record(k: Integer,c: Coef)) -> $
      ISUPS;makeSeries;RS$;4 is replaced by CONS 
Time: 0.10 SEC.

   compiling exported getRef : $ -> Reference OrderedCompletion Integer
      ISUPS;getRef;$R;5 is replaced by QCAR 
Time: 0 SEC.

   compiling exported getStream : $ -> Stream Record(k: Integer,c: Coef)
      ISUPS;getStream;$S;6 is replaced by QCDR 
Time: 0.01 SEC.

   compiling exported monomial : (Coef,Integer) -> $
Time: 0.01 SEC.

   compiling exported monomial? : $ -> Boolean
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/BOOLEAN.o
      for domain Boolean 
Time: 0.01 SEC.

   compiling exported coerce : Integer -> $
Time: 0.01 SEC.

   compiling exported coerce : Coef -> $
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/INT.o for
      domain Integer 
Time: 0.01 SEC.

   compiling local iSeries : (Stream Record(k: Integer,c: Coef),Reference OrderedCompletion Integer) -> Stream Record(k: Integer,c: Coef)
Time: 0.03 SEC.

   compiling exported series : Stream Record(k: Integer,c: Coef) -> $
Time: 0.02 SEC.

   compiling exported characteristic : () -> NonNegativeInteger
Time: 0 SEC.

   compiling exported Zero : () -> $
Time: 0.01 SEC.

   compiling exported One : () -> $
Time: 0 SEC.

   compiling local iExtend : (Stream Record(k: Integer,c: Coef),OrderedCompletion Integer,Reference OrderedCompletion Integer) -> Stream Record(k: Integer,c: Coef)
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/OM.o for 
      category OpenMath 
Time: 0.02 SEC.

   compiling exported extend : ($,Integer) -> $
Time: 0.02 SEC.

   compiling exported complete : $ -> $
Time: 0.01 SEC.

   compiling local iTruncate0 : (Stream Record(k: Integer,c: Coef),Reference OrderedCompletion Integer,Reference OrderedCompletion Integer,OrderedCompletion Integer,Integer,Integer) -> Stream Record(k: Integer,c: Coef)
Time: 0.28 SEC.

   compiling local iTruncate : ($,OrderedCompletion Integer,Integer) -> $
Time: 0.03 SEC.

   compiling exported truncate : ($,Integer) -> $
Time: 0.01 SEC.

   compiling exported truncate : ($,Integer,Integer) -> $
Time: 0.01 SEC.

   compiling local iCoefficient : (Stream Record(k: Integer,c: Coef),Integer) -> Coef
Time: 0.02 SEC.

   compiling exported coefficient : ($,Integer) -> Coef
Time: 0.01 SEC.

   compiling exported elt : ($,Integer) -> Coef
Time: 0.01 SEC.

   compiling local iOrder : (Stream Record(k: Integer,c: Coef),OrderedCompletion Integer,Reference OrderedCompletion Integer) -> Integer
Time: 0.04 SEC.

   compiling exported order : $ -> Integer
Time: 0.02 SEC.

   compiling exported order : ($,Integer) -> Integer
Time: 0.01 SEC.

   compiling exported terms : $ -> Stream Record(k: Integer,c: Coef)
Time: 0.09 SEC.

   compiling exported zero? : $ -> Boolean
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/SINT.o 
      for domain SingleInteger 
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/NNI.o for
      domain NonNegativeInteger 
Time: 0.06 SEC.

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

   compiling local iMap1 : ((Coef,Integer) -> Coef,Integer -> Integer,Boolean,Stream Record(k: Integer,c: Coef),Reference OrderedCompletion Integer,Reference OrderedCompletion Integer,Integer) -> Stream Record(k: Integer,c: Coef)
Time: 0.73 SEC.

   compiling local iMap2 : ((Coef,Integer) -> Coef,Integer -> Integer,Boolean,$) -> $
Time: 0.07 SEC.

   compiling exported map : (Coef -> Coef,$) -> $
Time: 0 SEC.

   compiling exported differentiate : $ -> $
Time: 0.02 SEC.

   compiling exported multiplyCoefficients : (Integer -> Coef,$) -> $
Time: 0.01 SEC.

   compiling exported multiplyExponents : ($,PositiveInteger) -> $
Time: 0.01 SEC.

   compiling local iPlus1 : ((Coef,Coef) -> Coef,Stream Record(k: Integer,c: Coef),Reference OrderedCompletion Integer,Stream Record(k: Integer,c: Coef),Reference OrderedCompletion Integer,Reference OrderedCompletion Integer,Integer) -> Stream Record(k: Integer,c: Coef)
Time: 2.06 SEC.

   compiling local iPlus2 : ((Coef,Coef) -> Coef,$,$) -> $
Time: 0.19 SEC.

   compiling exported + : ($,$) -> $
Time: 0.01 SEC.

   compiling exported - : ($,$) -> $
Time: 0 SEC.

   compiling exported - : $ -> $
Time: 0.01 SEC.

   compiling exported * : (Integer,$) -> $
Time: 0.01 SEC.

   compiling exported * : (NonNegativeInteger,$) -> $
Time: 0.02 SEC.

   compiling exported * : (PositiveInteger,$) -> $
Time: 0.02 SEC.

   compiling local productByTerm : (Coef,Integer,Stream Record(k: Integer,c: Coef),Reference OrderedCompletion Integer,Reference OrderedCompletion Integer,Integer) -> Stream Record(k: Integer,c: Coef)
Time: 0.01 SEC.

   compiling local productLazyEval : (Stream Record(k: Integer,c: Coef),Reference OrderedCompletion Integer,Stream Record(k: Integer,c: Coef),Reference OrderedCompletion Integer,OrderedCompletion Integer) -> Void
Time: 0.06 SEC.

   compiling local iTimes : (Stream Record(k: Integer,c: Coef),Reference OrderedCompletion Integer,Stream Record(k: Integer,c: Coef),Reference OrderedCompletion Integer,Reference OrderedCompletion Integer,Integer) -> Stream Record(k: Integer,c: Coef)
Time: 1.44 SEC.

   compiling exported * : ($,$) -> $
Time: 0.20 SEC.

   compiling local iDivide : (Stream Record(k: Integer,c: Coef),Reference OrderedCompletion Integer,Stream Record(k: Integer,c: Coef),Reference OrderedCompletion Integer,Coef,Integer,Reference OrderedCompletion Integer,Integer) -> Stream Record(k: Integer,c: Coef)
Time: 3.32 SEC.

   compiling local divide : ($,Integer,$,Integer,Coef) -> $
Time: 0.05 SEC.

   compiling exported iExquo : ($,$,Boolean) -> Union($,failed)
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/PI.o for 
      domain PositiveInteger 
Time: 0.13 SEC.

   compiling exported taylorQuoByVar : $ -> $
Time: 0.01 SEC.

   compiling local compose0 : (Stream Record(k: Integer,c: Coef),Reference OrderedCompletion Integer,Stream Record(k: Integer,c: Coef),Reference OrderedCompletion Integer,Integer,$,$,Integer,Reference OrderedCompletion Integer,Integer) -> Stream Record(k: Integer,c: Coef)
Time: 4.92 SEC.

   compiling exported iCompose : ($,$) -> $
Time: 0.15 SEC.

****** Domain: Coef already in scope
augmenting Coef: (Algebra (Fraction (Integer)))
augmenting $: (SIGNATURE $ integrate ($ $))
augmenting $: (SIGNATURE $ cPower ($ $ Coef))
augmenting $: (SIGNATURE $ cRationalPower ($ $ (Fraction (Integer))))
augmenting $: (SIGNATURE $ cExp ($ $))
augmenting $: (SIGNATURE $ cLog ($ $))
augmenting $: (SIGNATURE $ cSin ($ $))
augmenting $: (SIGNATURE $ cCos ($ $))
augmenting $: (SIGNATURE $ cTan ($ $))
augmenting $: (SIGNATURE $ cCot ($ $))
augmenting $: (SIGNATURE $ cSec ($ $))
augmenting $: (SIGNATURE $ cCsc ($ $))
augmenting $: (SIGNATURE $ cAsin ($ $))
augmenting $: (SIGNATURE $ cAcos ($ $))
augmenting $: (SIGNATURE $ cAtan ($ $))
augmenting $: (SIGNATURE $ cAcot ($ $))
augmenting $: (SIGNATURE $ cAsec ($ $))
augmenting $: (SIGNATURE $ cAcsc ($ $))
augmenting $: (SIGNATURE $ cSinh ($ $))
augmenting $: (SIGNATURE $ cCosh ($ $))
augmenting $: (SIGNATURE $ cTanh ($ $))
augmenting $: (SIGNATURE $ cCoth ($ $))
augmenting $: (SIGNATURE $ cSech ($ $))
augmenting $: (SIGNATURE $ cCsch ($ $))
augmenting $: (SIGNATURE $ cAsinh ($ $))
augmenting $: (SIGNATURE $ cAcosh ($ $))
augmenting $: (SIGNATURE $ cAtanh ($ $))
augmenting $: (SIGNATURE $ cAcoth ($ $))
augmenting $: (SIGNATURE $ cAsech ($ $))
augmenting $: (SIGNATURE $ cAcsch ($ $))
   compiling exported integrate : $ -> $
Time: 0.06 SEC.

   processing macro definition Ys ==> elt(ParadoxicalCombinatorsForStreams Record(k: Integer,c: Coef),Y) 
   compiling local integ0 : (Stream Record(k: Integer,c: Coef),Reference OrderedCompletion Integer,Reference OrderedCompletion Integer,Integer) -> Stream Record(k: Integer,c: Coef)
Time: 1.13 SEC.

   compiling local integ1 : (Stream Record(k: Integer,c: Coef),Reference OrderedCompletion Integer,Reference OrderedCompletion Integer) -> Stream Record(k: Integer,c: Coef)
Time: 0.02 SEC.

   compiling local lazyInteg : (Coef,() -> Stream Record(k: Integer,c: Coef),Reference OrderedCompletion Integer,Reference OrderedCompletion Integer) -> Stream Record(k: Integer,c: Coef)
Time: 0.03 SEC.

   compiling exported cPower : ($,Coef) -> $
Time: 0.14 SEC.

   compiling local iExp : ($,Coef) -> $
Time: 0.07 SEC.

   compiling local sincos0 : (Coef,Coef,List Stream Record(k: Integer,c: Coef),Reference OrderedCompletion Integer,Reference OrderedCompletion Integer,Stream Record(k: Integer,c: Coef),Reference OrderedCompletion Integer,Stream Record(k: Integer,c: Coef),Reference OrderedCompletion Integer) -> List Stream Record(k: Integer,c: Coef)
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/LIST.o 
      for domain List 
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/ILIST.o 
      for domain IndexedList 
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/LSAGG-.o 
      for domain ListAggregate& 
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/STAGG-.o 
      for domain StreamAggregate& 
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/ELAGG-.o 
      for domain ExtensibleLinearAggregate& 
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/FLAGG-.o 
      for domain FiniteLinearAggregate& 
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/URAGG-.o 
      for domain UnaryRecursiveAggregate& 
Time: 0.10 SEC.

   compiling local iSincos : ($,Coef,Coef,Integer) -> Record(%sin: $,%cos: $)
Time: 0.12 SEC.

   compiling local tan0 : (Coef,Stream Record(k: Integer,c: Coef),Reference OrderedCompletion Integer,Stream Record(k: Integer,c: Coef),Reference OrderedCompletion Integer,Integer) -> Stream Record(k: Integer,c: Coef)
Time: 0.06 SEC.

   compiling local iTan : ($,$,Coef,Integer) -> $
Time: 0.05 SEC.

   compiling local orderOrFailed : $ -> Union(Integer,failed)
Time: 0.06 SEC.

augmenting Coef: (SIGNATURE Coef ** (Coef Coef (Fraction (Integer))))
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/TRANFUN.o
      for category TranscendentalFunctionCategory 
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/TRIGCAT.o
      for category TrigonometricFunctionCategory 
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/ATRIG.o 
      for category ArcTrigonometricFunctionCategory 
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/HYPCAT.o 
      for category HyperbolicFunctionCategory 
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/AHYP.o 
      for category ArcHyperbolicFunctionCategory 
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/ELEMFUN.o
      for category ElementaryFunctionCategory 
****** Domain: Coef already in scope
augmenting Coef: (TranscendentalFunctionCategory)
   compiling exported cRationalPower : ($,Fraction Integer) -> $
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/STRING.o 
      for domain String 
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/CHAR.o 
      for domain Character 
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/OUTFORM.o
      for domain OutputForm 
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/PRIMARR.o
      for domain PrimitiveArray 
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/A1AGG-.o 
      for domain OneDimensionalArrayAggregate& 
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/ISTRING.o
      for domain IndexedString 
Time: 0.45 SEC.

   compiling exported cExp : $ -> $
Time: 0.10 SEC.

   compiling exported cLog : $ -> $
Time: 0.22 SEC.

   compiling local sincos : $ -> Record(%sin: $,%cos: $)
Time: 0.04 SEC.

   compiling exported cSin : $ -> $
Time: 0.01 SEC.

   compiling exported cCos : $ -> $
Time: 0 SEC.

   compiling exported cTan : $ -> $
Time: 0.22 SEC.

   compiling exported cCot : $ -> $
Time: 0.12 SEC.

   compiling exported cSec : $ -> $
Time: 0.24 SEC.

   compiling exported cCsc : $ -> $
Time: 0.13 SEC.

   compiling exported cAsin : $ -> $
Time: 1.70 SEC.

   compiling exported cAcos : $ -> $
Time: 2.10 SEC.

   compiling exported cAtan : $ -> $
Time: 0.24 SEC.

   compiling exported cAcot : $ -> $
Time: 0.09 SEC.

   compiling exported cAsec : $ -> $
Time: 2.22 SEC.

   compiling exported cAcsc : $ -> $
Time: 2.24 SEC.

   compiling local sinhcosh : $ -> Record(%sinh: $,%cosh: $)
Time: 0.04 SEC.

   compiling exported cSinh : $ -> $
Time: 0.01 SEC.

   compiling exported cCosh : $ -> $
Time: 0.01 SEC.

   compiling exported cTanh : $ -> $
Time: 0.12 SEC.

   compiling exported cCoth : $ -> $
Time: 0.13 SEC.

   compiling exported cSech : $ -> $
Time: 0.12 SEC.

   compiling exported cCsch : $ -> $
Time: 0.12 SEC.

   compiling exported cAsinh : $ -> $
Time: 0.23 SEC.

   compiling exported cAcosh : $ -> $
Time: 0.32 SEC.

   compiling exported cAtanh : $ -> $
Time: 0.26 SEC.

   compiling exported cAcoth : $ -> $
Time: 0.21 SEC.

   compiling exported cAsech : $ -> $
Time: 2.84 SEC.

   compiling exported cAcsch : $ -> $
Time: 1.16 SEC.

   compiling local factorials? : () -> Boolean
      ISUPS;factorials? is replaced by QUOTE 
Time: 0 SEC.

   compiling local termOutput : (Fraction Integer,Coef,OutputForm) -> OutputForm
Time: 0.03 SEC.

   compiling local showAll? : () -> Boolean
      ISUPS;showAll? is replaced by QUOTET 
Time: 0 SEC.

   compiling exported seriesToOutputForm : (Stream Record(k: Integer,c: Coef),Reference OrderedCompletion Integer,Symbol,Coef,Fraction Integer) -> OutputForm
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/SYMBOL.o 
      for domain Symbol 
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/REF.o for
      domain Reference 
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/ALIST.o 
      for domain AssociationList 
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/SRAGG-.o 
      for domain StringAggregate& 
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/LNAGG-.o 
      for domain LinearAggregate& 
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/LSAGG.o 
      for category ListAggregate 
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/STAGG.o 
      for category StreamAggregate 
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/URAGG.o 
      for category UnaryRecursiveAggregate 
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/RCAGG.o 
      for category RecursiveAggregate 
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/HOAGG.o 
      for category HomogeneousAggregate 
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/AGG.o for
      category Aggregate 
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/TYPE.o 
      for category Type 
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/EVALAB.o 
      for category Evalable 
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/IEVALAB.o
      for category InnerEvalable 
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/LNAGG.o 
      for category LinearAggregate 
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/IXAGG.o 
      for category IndexedAggregate 
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/ELTAGG.o 
      for category EltableAggregate 
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/CLAGG.o 
      for category Collection 
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/FLAGG.o 
      for category FiniteLinearAggregate 
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/ELAGG.o 
      for category ExtensibleLinearAggregate 
Time: 1.01 SEC.

****** Domain: Coef already in scope
augmenting Coef: (PartialDifferentialRing (Symbol))
augmenting Coef: (SIGNATURE Coef ** (Coef Coef (Integer)))
augmenting Coef: (SIGNATURE Coef coerce (Coef (Symbol)))
****** Domain: Coef already in scope
augmenting Coef: (Algebra (Fraction (Integer)))
augmenting $: (SIGNATURE $ integrate ($ $))
augmenting $: (SIGNATURE $ cPower ($ $ Coef))
augmenting $: (SIGNATURE $ cRationalPower ($ $ (Fraction (Integer))))
augmenting $: (SIGNATURE $ cExp ($ $))
augmenting $: (SIGNATURE $ cLog ($ $))
augmenting $: (SIGNATURE $ cSin ($ $))
augmenting $: (SIGNATURE $ cCos ($ $))
augmenting $: (SIGNATURE $ cTan ($ $))
augmenting $: (SIGNATURE $ cCot ($ $))
augmenting $: (SIGNATURE $ cSec ($ $))
augmenting $: (SIGNATURE $ cCsc ($ $))
augmenting $: (SIGNATURE $ cAsin ($ $))
augmenting $: (SIGNATURE $ cAcos ($ $))
augmenting $: (SIGNATURE $ cAtan ($ $))
augmenting $: (SIGNATURE $ cAcot ($ $))
augmenting $: (SIGNATURE $ cAsec ($ $))
augmenting $: (SIGNATURE $ cAcsc ($ $))
augmenting $: (SIGNATURE $ cSinh ($ $))
augmenting $: (SIGNATURE $ cCosh ($ $))
augmenting $: (SIGNATURE $ cTanh ($ $))
augmenting $: (SIGNATURE $ cCoth ($ $))
augmenting $: (SIGNATURE $ cSech ($ $))
augmenting $: (SIGNATURE $ cCsch ($ $))
augmenting $: (SIGNATURE $ cAsinh ($ $))
augmenting $: (SIGNATURE $ cAcosh ($ $))
augmenting $: (SIGNATURE $ cAtanh ($ $))
augmenting $: (SIGNATURE $ cAcoth ($ $))
augmenting $: (SIGNATURE $ cAsech ($ $))
augmenting $: (SIGNATURE $ cAcsch ($ $))
****** Domain: Coef already in scope
augmenting Coef: (CharacteristicNonZero)
****** Domain: Coef already in scope
augmenting Coef: (CommutativeRing)
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/FIELD.o 
      for category Field 
   Loading /home/martin/ax-build/target/i686-pc-linux/algebra/DIVRING.o
      for category DivisionRing 
****** Domain: Coef already in scope
augmenting Coef: (Field)
****** Domain: Coef already in scope
augmenting Coef: (IntegralDomain)
augmenting Coef: (SIGNATURE Coef ** (Coef Coef (Integer)))
(time taken in buildFunctor:  29)

;;;     ***       |InnerSparseUnivariatePowerSeries| REDEFINED

;;;     ***       |InnerSparseUnivariatePowerSeries| REDEFINED
Time: 0.31 SEC.

 
   Warnings: 
      [1] cSin:  %sin has no value
      [2] cCos:  %cos has no value
      [3] sinhcosh:  %sin has no value
      [4] sinhcosh:  %cos has no value
      [5] cSinh:  %sinh has no value
      [6] cCosh:  %cosh has no value
 

   Cumulative Statistics for Constructor InnerSparseUnivariatePowerSeries
      Time: 33.32 seconds
 
   Loading /home/martin/ax-build/target/i686-pc-linux/autoload/bc-matrix.
   Loading /home/martin/ax-build/target/i686-pc-linux/autoload/bc-misc.
   Loading /home/martin/ax-build/target/i686-pc-linux/autoload/bc-solve.
   Loading /home/martin/ax-build/target/i686-pc-linux/autoload/bc-util.
   Loading /home/martin/ax-build/target/i686-pc-linux/autoload/ht-util.
   Loading /home/martin/ax-build/target/i686-pc-linux/autoload/htsetvar.
   Loading /home/martin/ax-build/target/i686-pc-linux/autoload/ht-root.
   Loading /home/martin/ax-build/target/i686-pc-linux/autoload/br-con.
   Loading /home/martin/ax-build/target/i686-pc-linux/autoload/br-data.
   Loading /home/martin/ax-build/target/i686-pc-linux/autoload/showimp.
   Loading /home/martin/ax-build/target/i686-pc-linux/autoload/br-op1.
   Loading /home/martin/ax-build/target/i686-pc-linux/autoload/br-op2.
   Loading /home/martin/ax-build/target/i686-pc-linux/autoload/br-search.
   Loading /home/martin/ax-build/target/i686-pc-linux/autoload/br-util.
   Loading /home/martin/ax-build/target/i686-pc-linux/autoload/topics.
   Loading /home/martin/ax-build/target/i686-pc-linux/autoload/br-prof.
   Loading /home/martin/ax-build/target/i686-pc-linux/autoload/br-saturn.
   finalizing NRLIB ISUPS 
   Processing InnerSparseUnivariatePowerSeries for Browser database:
--------(makeSeries (% REF ST))---------
--->-->InnerSparseUnivariatePowerSeries((makeSeries (% REF ST))): Unexpected HT command: \spad
--->-->InnerSparseUnivariatePowerSeries((makeSeries (% REF ST))): Unexpected HT command: \spad
--->-->InnerSparseUnivariatePowerSeries((makeSeries (% REF ST))): Unexpected HT command: \spad
"\\spad{makeSeries(refer,{}str)} creates a power series from the reference \\spad{refer} and the stream \\spad{str}."
--------(getRef (REF %))---------
--->-->InnerSparseUnivariatePowerSeries((getRef (REF %))): Unexpected HT command: \spad
"\\spad{getRef(f)} returns a reference containing the order to which the terms of \\spad{f} have been computed."
--------(getStream (ST %))---------
--->-->InnerSparseUnivariatePowerSeries((getStream (ST %))): Unexpected HT command: \spad
"\\spad{getStream(f)} returns the stream of terms representing the series \\spad{f}."
--------(series (% ST))---------
--->-->InnerSparseUnivariatePowerSeries((series (% ST))): Unexpected HT command: \spad
"\\spad{series(st)} creates a series from a stream of non-zero terms,{} where a term is an exponent-coefficient pair. The terms in the stream should be ordered by increasing order of exponents."
--------(monomial? (B %))---------
--->-->InnerSparseUnivariatePowerSeries((monomial? (B %))): Unexpected HT command: \spad
"\\spad{monomial?(f)} tests if \\spad{f} is a single monomial."
--------(multiplyCoefficients (% (Mapping Coef I) %))---------
--->-->InnerSparseUnivariatePowerSeries((multiplyCoefficients (% (Mapping Coef I) %))): Unexpected HT command: \spad
--->-->InnerSparseUnivariatePowerSeries((multiplyCoefficients (% (Mapping Coef I) %))): Unexpected HT command: \spad
--->-->InnerSparseUnivariatePowerSeries((multiplyCoefficients (% (Mapping Coef I) %))): Unexpected HT command: \spad
"\\spad{multiplyCoefficients(fn,{}f)} returns the series \\spad{sum(fn(n) * an * x^n,{}n = n0..)},{} where \\spad{f} is the series \\spad{sum(an * x^n,{}n = n0..)}."
--------(iExquo ((Union % failed) % % B))---------
--->-->InnerSparseUnivariatePowerSeries((iExquo ((Union % failed) % % B))): Unexpected HT command: \spad
--->-->InnerSparseUnivariatePowerSeries((iExquo ((Union % failed) % % B))): Unexpected HT command: \spad
--->-->InnerSparseUnivariatePowerSeries((iExquo ((Union % failed) % % B))): Unexpected HT command: \spad
--->-->InnerSparseUnivariatePowerSeries((iExquo ((Union % failed) % % B))): Unexpected HT command: \spad
"\\spad{iExquo(f,{}g,{}taylor?)} is the quotient of the power series \\spad{f} and \\spad{g}. If \\spad{taylor?} is \\spad{true},{} then we must have \\spad{order(f) >= order(g)}."
--------(taylorQuoByVar (% %))---------
--->-->InnerSparseUnivariatePowerSeries((taylorQuoByVar (% %))): Unexpected HT command: \spad
--->-->InnerSparseUnivariatePowerSeries((taylorQuoByVar (% %))): Unexpected HT command: \spad
"\\spad{taylorQuoByVar(a0 + a1 x + a2 x**2 + ...)} returns \\spad{a1 + a2 x + a3 x**2 + ...}"
--------(iCompose (% % %))---------
--->-->InnerSparseUnivariatePowerSeries((iCompose (% % %))): Unexpected HT command: \spad
--->-->InnerSparseUnivariatePowerSeries((iCompose (% % %))): Unexpected HT command: \spad
--->-->InnerSparseUnivariatePowerSeries((iCompose (% % %))): Unexpected HT command: \spad
--->-->InnerSparseUnivariatePowerSeries((iCompose (% % %))): Unexpected HT command: \spad
--->-->InnerSparseUnivariatePowerSeries((iCompose (% % %))): Unexpected HT command: \spad
"\\spad{iCompose(f,{}g)} returns \\spad{f(g(x))}. This is an internal function which should only be called for Taylor series \\spad{f(x)} and \\spad{g(x)} such that the constant coefficient of \\spad{g(x)} is zero."
--------(seriesToOutputForm ((OutputForm) ST REF (Symbol) Coef RN))---------
--->-->InnerSparseUnivariatePowerSeries((seriesToOutputForm ((OutputForm) ST REF (Symbol) Coef RN))): Unexpected HT command: \spad
--->-->InnerSparseUnivariatePowerSeries((seriesToOutputForm ((OutputForm) ST REF (Symbol) Coef RN))): Unexpected HT command: \spad
"\\spad{seriesToOutputForm(st,{}refer,{}var,{}cen,{}r)} prints the series \\spad{f((var - cen)^r)}."
--------(integrate (% %))---------
--->-->InnerSparseUnivariatePowerSeries((integrate (% %))): Unexpected HT command: \spad
--->-->InnerSparseUnivariatePowerSeries((integrate (% %))): Unexpected HT command: \spad
"\\spad{integrate(f(x))} returns an anti-derivative of the power series \\spad{f(x)} with constant coefficient 0. Warning: function does not check for a term of degree \\spad{-1}."
--------(cPower (% % Coef))---------
--->-->InnerSparseUnivariatePowerSeries((cPower (% % Coef))): Unexpected HT command: \spad
--->-->InnerSparseUnivariatePowerSeries((cPower (% % Coef))): Unexpected HT command: \spad
"\\spad{cPower(f,{}r)} computes \\spad{f^r},{} where \\spad{f} has constant coefficient 1. For use when the coefficient ring is commutative."
--------(cRationalPower (% % RN))---------
--->-->InnerSparseUnivariatePowerSeries((cRationalPower (% % RN))): Unexpected HT command: \spad
--->-->InnerSparseUnivariatePowerSeries((cRationalPower (% % RN))): Unexpected HT command: \spad
"\\spad{cRationalPower(f,{}r)} computes \\spad{f^r}. For use when the coefficient ring is commutative."
--------(cExp (% %))---------
--->-->InnerSparseUnivariatePowerSeries((cExp (% %))): Unexpected HT command: \spad
"\\spad{cExp(f)} computes the exponential of the power series \\spad{f}. For use when the coefficient ring is commutative."
--------(cLog (% %))---------
--->-->InnerSparseUnivariatePowerSeries((cLog (% %))): Unexpected HT command: \spad
"\\spad{cLog(f)} computes the logarithm of the power series \\spad{f}. For use when the coefficient ring is commutative."
--------(cSin (% %))---------
--->-->InnerSparseUnivariatePowerSeries((cSin (% %))): Unexpected HT command: \spad
"\\spad{cSin(f)} computes the sine of the power series \\spad{f}. For use when the coefficient ring is commutative."
--------(cCos (% %))---------
--->-->InnerSparseUnivariatePowerSeries((cCos (% %))): Unexpected HT command: \spad
"\\spad{cCos(f)} computes the cosine of the power series \\spad{f}. For use when the coefficient ring is commutative."
--------(cTan (% %))---------
--->-->InnerSparseUnivariatePowerSeries((cTan (% %))): Unexpected HT command: \spad
"\\spad{cTan(f)} computes the tangent of the power series \\spad{f}. For use when the coefficient ring is commutative."
--------(cCot (% %))---------
--->-->InnerSparseUnivariatePowerSeries((cCot (% %))): Unexpected HT command: \spad
"\\spad{cCot(f)} computes the cotangent of the power series \\spad{f}. For use when the coefficient ring is commutative."
--------(cSec (% %))---------
--->-->InnerSparseUnivariatePowerSeries((cSec (% %))): Unexpected HT command: \spad
"\\spad{cSec(f)} computes the secant of the power series \\spad{f}. For use when the coefficient ring is commutative."
--------(cCsc (% %))---------
--->-->InnerSparseUnivariatePowerSeries((cCsc (% %))): Unexpected HT command: \spad
"\\spad{cCsc(f)} computes the cosecant of the power series \\spad{f}. For use when the coefficient ring is commutative."
--------(cAsin (% %))---------
--->-->InnerSparseUnivariatePowerSeries((cAsin (% %))): Unexpected HT command: \spad
"\\spad{cAsin(f)} computes the arcsine of the power series \\spad{f}. For use when the coefficient ring is commutative."
--------(cAcos (% %))---------
--->-->InnerSparseUnivariatePowerSeries((cAcos (% %))): Unexpected HT command: \spad
"\\spad{cAcos(f)} computes the arccosine of the power series \\spad{f}. For use when the coefficient ring is commutative."
--------(cAtan (% %))---------
--->-->InnerSparseUnivariatePowerSeries((cAtan (% %))): Unexpected HT command: \spad
"\\spad{cAtan(f)} computes the arctangent of the power series \\spad{f}. For use when the coefficient ring is commutative."
--------(cAcot (% %))---------
--->-->InnerSparseUnivariatePowerSeries((cAcot (% %))): Unexpected HT command: \spad
"\\spad{cAcot(f)} computes the arccotangent of the power series \\spad{f}. For use when the coefficient ring is commutative."
--------(cAsec (% %))---------
--->-->InnerSparseUnivariatePowerSeries((cAsec (% %))): Unexpected HT command: \spad
"\\spad{cAsec(f)} computes the arcsecant of the power series \\spad{f}. For use when the coefficient ring is commutative."
--------(cAcsc (% %))---------
--->-->InnerSparseUnivariatePowerSeries((cAcsc (% %))): Unexpected HT command: \spad
"\\spad{cAcsc(f)} computes the arccosecant of the power series \\spad{f}. For use when the coefficient ring is commutative."
--------(cSinh (% %))---------
--->-->InnerSparseUnivariatePowerSeries((cSinh (% %))): Unexpected HT command: \spad
"\\spad{cSinh(f)} computes the hyperbolic sine of the power series \\spad{f}. For use when the coefficient ring is commutative."
--------(cCosh (% %))---------
--->-->InnerSparseUnivariatePowerSeries((cCosh (% %))): Unexpected HT command: \spad
"\\spad{cCosh(f)} computes the hyperbolic cosine of the power series \\spad{f}. For use when the coefficient ring is commutative."
--------(cTanh (% %))---------
--->-->InnerSparseUnivariatePowerSeries((cTanh (% %))): Unexpected HT command: \spad
"\\spad{cTanh(f)} computes the hyperbolic tangent of the power series \\spad{f}. For use when the coefficient ring is commutative."
--------(cCoth (% %))---------
--->-->InnerSparseUnivariatePowerSeries((cCoth (% %))): Unexpected HT command: \spad
"\\spad{cCoth(f)} computes the hyperbolic cotangent of the power series \\spad{f}. For use when the coefficient ring is commutative."
--------(cSech (% %))---------
--->-->InnerSparseUnivariatePowerSeries((cSech (% %))): Unexpected HT command: \spad
"\\spad{cSech(f)} computes the hyperbolic secant of the power series \\spad{f}. For use when the coefficient ring is commutative."
--------(cCsch (% %))---------
--->-->InnerSparseUnivariatePowerSeries((cCsch (% %))): Unexpected HT command: \spad
"\\spad{cCsch(f)} computes the hyperbolic cosecant of the power series \\spad{f}. For use when the coefficient ring is commutative."
--------(cAsinh (% %))---------
--->-->InnerSparseUnivariatePowerSeries((cAsinh (% %))): Unexpected HT command: \spad
"\\spad{cAsinh(f)} computes the inverse hyperbolic sine of the power series \\spad{f}. For use when the coefficient ring is commutative."
--------(cAcosh (% %))---------
--->-->InnerSparseUnivariatePowerSeries((cAcosh (% %))): Unexpected HT command: \spad
"\\spad{cAcosh(f)} computes the inverse hyperbolic cosine of the power series \\spad{f}. For use when the coefficient ring is commutative."
--------(cAtanh (% %))---------
--->-->InnerSparseUnivariatePowerSeries((cAtanh (% %))): Unexpected HT command: \spad
"\\spad{cAtanh(f)} computes the inverse hyperbolic tangent of the power series \\spad{f}. For use when the coefficient ring is commutative."
--------(cAcoth (% %))---------
--->-->InnerSparseUnivariatePowerSeries((cAcoth (% %))): Unexpected HT command: \spad
"\\spad{cAcoth(f)} computes the inverse hyperbolic cotangent of the power series \\spad{f}. For use when the coefficient ring is commutative."
--------(cAsech (% %))---------
--->-->InnerSparseUnivariatePowerSeries((cAsech (% %))): Unexpected HT command: \spad
"\\spad{cAsech(f)} computes the inverse hyperbolic secant of the power series \\spad{f}. For use when the coefficient ring is commutative."
--------(cAcsch (% %))---------
--->-->InnerSparseUnivariatePowerSeries((cAcsch (% %))): Unexpected HT command: \spad
"\\spad{cAcsch(f)} computes the inverse hyperbolic cosecant of the power series \\spad{f}. For use when the coefficient ring is commutative."
--------constructor---------
--->-->InnerSparseUnivariatePowerSeries(constructor): Unexpected HT command: \indented
"InnerSparseUnivariatePowerSeries is an internal domain \\indented{2}{used for creating sparse Taylor and Laurent series.}"
 
   >> System error:
   (SYSTEM "gcc -c -Wall -DVOL=volatile -fsigned-char -pipe  -I/home/martin/ax-build/build/i686-pc-linux/lib/gcl-2.6.8/unixport/../h  -O3 -fomit-frame-pointer -c \"ISUPS.NRLIB/ISUPS.c\" -o \"ISUPS.NRLIB/ISUPS.o\" -w") returned a non-zero value 255.

(1) -> 

\start
Date: Wed, 28 Mar 2007 16:46:40 +0200 (CEST)
From: Waldek Hebisch
To: Martin Rubey
Subject: Re: new problem compiling wh-sandbox,	rev 470 (urgent...)
Cc: Gabriel Dos Reis, Waldek Hebisch

Martin Rubey wrote:
> Martin Rubey writes:
> 
> > Dear Gaby,
> > 
> > thanks for the hint. It seems, however, that I had a singular problem. Wiping
> > out tmp and starting fresh seems to work. 
> 
> Ai, it does not. Now it fails for ISUPS. Please help, I need it tomorrow for a
> presentation!
> 
> 
> compiling ISUPS.c by hand using
> 
> 
> gcc -c -Wall -DVOL=volatile -fsigned-char -pipe
> -I/home/martin/ax-build/build/i686-pc-linux/lib/gcl-2.6.8/unixport/../h  -O3
> -fomit-frame-pointer -c "ISUPS.NRLIB/ISUPS.c" -o "ISUPS.NRLIB/ISUPS.o" -w
> 
> produced an ISUPS.o, but running make again failed at the same point.
> 
<From log>
>    >> System error:
>    (SYSTEM "gcc -c -Wall -DVOL=volatile -fsigned-char -pipe  -I/home/martin/ax-build/build/i686-pc-linux/lib/gcl-2.6.8/unixport/../h  -O3 -fomit-frame-pointer -c \"ISUPS.NRLIB/ISUPS.c\" -o \"ISUPS.NRLIB/ISUPS.o\" -w") returned a non-zero value 255.
> 
> (1) -> 


That looks weird.  I would check basic things (do you have free disc
space, enough memory ...).  But I must admit that I saw quite a few
weird build problems -- most of the time problem went away re-running
make but some were repeatable.  I was able to track some problems to
real bugs (at some point Axiom generated wrong data structure, causing
memory corruption later and finally a weird crash), but some went away
due to seemingly unrelated changes (and most is not repeatable).
Since I suspect that we still may corrupt memory I tried to build
Axiom setting GCL safety to 3.  After 16 hours the build stopped
in guessing package with report about symbol having undefined value
(I still have to investigate this deeper), but the previous parts
build OK.

To resolve immediate problem you may try to copy ISUPS.o to
the target/i686-pc-linux/algebra directory and also copy it to
code.o file (if all files related to ISUPS are in place and
look up to date make should go on to the next file).

\start
Date: Thu, 29 Mar 2007 00:10:12 +0200
From: Gregory Vanuxem
To: Gabriel Dos Reis
Subject: Re: depsys and SBCL

Le mardi 27 mars 2007 =E0 11:05 -0500, Gabriel Dos Reis a =E9crit :
> Hello,
>
>   In my local tree, I was able to eventually twist Axiom to get it
> compilable by SBCL.  During that process, I unconvered various dubious
> practices in the current system (mainly between vmlisp.lisp and
> macro.lisp).  SBCL will accept to compile depsys only if I tell it to
> ignore many redefinitions of Common Lisp symbols (I'll discuss that in
> a separate message).
>
>   CLISP almost compiles SBCL -- it errors out on def.lisp saying
> that there is an illegal character #\Stx in the source file -- I have
> no idea of what that means.  If I omit def.lisp, the depsys
> compiles fine --

Hmm... I forgot to add this issue to my TODO list. I temporary followed
how GCL behaves i.e omit it. I was/am pretty sure this is incorrect but
as far as I know this part of code is not used. I just commented out
this function. ^L is also used at several places.

>I have not tried the resulting translator however.

Did you modify the "funcalled symbols" FUNCALL('FOO) -> FUNCALL(function
(foo)) as done by Juergen Weiss ? I based my work on his work and this
version does not contain all the src/interp file that we can find in
Gold. Adding a new file is always difficult because of this issue (that
must be done carefully).

> This is just a head up.  If you know anything about the illegal
> character \#Stx, please let me know.

No idea.

> Ah, one more thing: Currently, there is this dubious definition in
> foam_l.lisp:
>
>    #+:AKCL
>    (deftype |DFlo| () t)
>    #-:AKCL
>    (deftype |DFlo| () 'long-float)
>
> followed by
>
>    (defconstant |DFloInit| (the |DFlo| 0.0d0))
>
> which is an error because 0.0d0 is not long-float -- rather a double-fl=
oat.
>
> Looking more at this, I think the |DFlo| should not be conditional.

I don't know why the Aldor implementers used the t type to define DFlo
on AKCL and since we do not have access to the Aldor source code it's
difficult to know why. There are other issues in this file, for example
it _seems_ that the SInt type has to be a 32 bits integer (on a 32bit
arch) but they defined it to be a fixnum. This is clearly wrong on CMUCL
and Clisp (and probably other), their fixnums are 29 bits integers if I
remember correctly (and if log2 MOST-POSITIVE-FIXNUM really represents
that). For other issues you can look at the tarball that I uploaded [1].
A quick note here, the last (beta) version of Aldor comes without an
indispensable file, runtime.lsp [2]. I hope they will continue to
support the lisp backend though I rarely use it.

> Furthermore, I think we should use double-float instead of long-float
> -- it fits more in most modern FPU and its underyling representation
> is more widely uniform.
> This is a change for people connecting Axiom to Aldor through FOAM.

I totally agree, this should be done everywhere (in the algebra too:
DFLOAT.spad). From what I know the Lisp double-float type is generally a
hardware float (see for example
http://www.cs.berkeley.edu/~mhoemmen/matlisp/floating-point.html). But
this is not the case for long-float on Clisp (arbitrary precision). We
might add a new type that represent hardware float.


Greg

[1] Do not take into account my definition of the SInt type, I use
    a 32 bit CMUCL in a 64 bit environment (64 bits aldor)
[1] This is, apparently, a generated file (from a as file).

\start
Date: Thu, 29 Mar 2007 02:03:25 +0200
From: Ralf Hemmecke
To: list
Subject: kTuple wish

The following text describes a weakness of the Aldor language.

Suppose I want to write a domain that takes a finite number of domains
satisfying a certain category "LabelType".

I write kTuple instead of Tuple, because the Aldor-Tuple constructor
is not suitable for what I want. In particular, if

   T: Tuple PrimitiveType

then I T = (Integer, String, Boolean, String) would be one possible
value for T. However, an element of T is not a Tuple, since T (not its
type) is non-homogeneous. So I would rather need something like
"Cross", but I cannot even ask about the number of arguments of Cross.


Let us give a rough outline of the domain Multiset which should be
seen as a constructor to construct k-tuples of sets over different domains.
Note that "SetSpecies" is just a special instance. I need something
for arbitrary S: LabelType -> LabelType.


Multiset(M: kTuple LabelType): with {
         <<exports: Multiset>>
} == add {
         macro S == SetSpecies;
         <<representation: Multiset>>
         <<implementation: Multiset>>
}
@




Section: <<representation: Multiset>>
--------------------------------------

The representation will be a kTuple.

By M.i I mean something like "element(M, i)" exported by the Tuple
constructor, but rather supported by the language (not the library).
If

   T: Tuple PrimitiveType == (Integer, String);

then element(T, 1) cannot be identified with Integer
at compile time, since the function "element" could be
non-terminating.

So the representation should informally be something like

   Rep == (S M.1, S M.2, ..., S M.k);

Since elipses are not a rigorous concept it should perhaps rather look
like

   Rep == MapOver(S)(M);


The "MapOver" constructor should be understood by applying the
constructor

   S = SetSpecies: LabelType -> LabelType

to each element of the tuple.

The above Rep could still be done via Aldor-Tuple, but I don't know
how to map a constructor S over a tuple whose size is not given at
compile time.



Section: <<exports: Multiset>> + <<implementation: Multiset>>
-------------------------------------------------------------

I somehow want that the Multiset constructor can be seen as a function
from kTuple to kTuple, i.e. the input and output tuple should have the
same arity.

  #: I == # $ M; -- arity doesn't change

It would simply be overcool if I'd have a function definition that
informally looks like

   multiset: (S M.1, ..., S M.k) -> %;

or rather

   multiset: MapOver(S)(M) -> %;

so that I could write

   multiset(sm1: S M.1, ..., smk: S M.k): % == per (sm1, ..., smk);

or rather

   multiset(sm: MapOver(S)(M)): % == per sm;

and later use it as

   T == Multiset(Integer, String);
   a: SetSpecies Integer := set [1,3,5];
   b: SetSpecies String := set ["a", "x", "free", "open"];
   t: T := multiset(a, b);

   U == Multiset(String, Boolean, Integer);
   c: SetSpecies Boolean := set [true];
   w: W := multiset(b, c, a);

The compiler should reject a statement like

   u: T := multiset(a, a);

at compile time.

If the constructor "MapOver" where built into the Aldor language that
should be doable at compile time. If I construct it as an ordinary
domain constructor (I still don't know how to do this with all the
"nice" properties I describe above), then the compiler has no good
chance to check at compile time since I might have made my constructor
non-terminating.

Is such a "MapOver" a bad idea? Or are there perhaps similar concepts
in other programming languages that would allow to reject a statement
like

   u: T := multiset(a, a);

at compile time.

Hmmm, maybe it is a bit tricky. Take, for example, the program aaa.as.

---BEGIN aaa.as
#include "aldor"
I ==> MachineInteger;
S(T: PrimitiveType): PrimitiveType == I;
main(): () == {
	A ==> S Integer;
	B ==> S String;
	a: A := (0$I) pretend A; -- I need some value ...
	b: B := (1$I) pretend B; -- forgive the "pretend" ...
	equal?: Boolean := a = b;
}
main();
---END aaa.as

It currently dose not compile (Aldor 1.0.3):

aldor -fx -laldor aaa.as
"aaa.as", line 10:         equal?: Boolean := a = b;
                    ...........................^
[L10 C28] #1 (Error) Argument 1 of `=' did not match any possible 
parameter type.
     The rejected type is S(AldorInteger).
     Expected one of:
       -- Boolean
       -- S(String)

The reason is clear, even though A = S Integer = S String = B = I, the
compiler will not evaluate S and thus consider A as unequal to B.

Being in that light, the compiler could reject

   u: T := multiset(a, a);

but if S maps everything to the same domain, should it reject it?
I'd rather live with "rejection", but since I am not a compiler
developer, I would like to hear people with more inside.

\start
Date: Thu, 29 Mar 2007 02:19:08 -0400
From: Bill Page
To: Ondrej Certik, Gabriel Dos Reis
Subject: RE: CAS for the masses

On March 28, 2007 7:42 AM Ondrej Certik wrote:
> ...
> Expression tree (Add, Mul,...) are very low level types, and
> you have many algorithms, that work with high level types like
> Polynomial, Fraction, ODE, DAE, PDE, etc. I understand that.
>

I think that there may be two problems with this discussion so
far.

I think the first problem is that Axiom developers and Python
programmers may not appreciate just how similar SPAD (or Aldor)
and Python really is. Although Python is dynamically typed
while Axiom is statically typed, both Python classes and Axiom
domains support object-oriented programming in similar ways.

I have been promising myself for some time now to take the time
to write a more accessible introduction. So here is at least a
start at this.

A draft containing the examples below is available on the Axiom
wiki as:

http://wiki.axiom-developer.org/SandBoxSPADForPython

For example, in Python we might define a simple class implementing
complex numbers something like the following:

### file: complex.py
class Complex:
    "Example to demonstrate SPAD equivalent of Python Classes"
    def __init__(self, realpart, imagpart):
        self.r = realpart
        self.i = imagpart
    def real(self):
      return self.r
    def imag(self):
      return self.i
    def __str__(self):
      if self.i<0:
        return "%g - i %g"%(self.real(),-self.imag())
      else:
        return "%g + i %g"%(self.real(),self.imag())
    def __coerce__(self,b):
      if isinstance(b,Complex):
         return(self,b)
      else:
         return(self,Complex(b,0))
    def __add__(self,b):
      return Complex(self.real()+b.real(), self.imag()+b.imag())
    def __mul__(self,b):
      return Complex(self.real()*b.real() - self.imag()*b.imag(),
                     self.real()*b.imag() + self.imag()*b.real())
###

>>> x = Complex(3.0, -4.5)
>>> y = Complex(-2.0, 5.4)
>>> print x
  3.0 - i 4.5
>>> print x+y
  1 + i 0.9
>>> print x*y
  18.3 + i 25.2
>>> print x+1.0
  4 - i 4.5

------

You can find details of how operator overloading in Python is done
by using special names like __op__ explained here:

http://docs.python.org/ref/customization.html

In SPAD a domain equivalent to this Python class would be:

--- file: complex.spad
)abbrev domain CMPLXS ComplexSpad
+++ Example of SPAD equivalent of Python Class
ComplexSpad(): with
    new: (Float,Float) -> %     ++ __init__   in Python
    coerce: Float -> %          ++ __coerce__ in Python
    real: % -> Float            ++ real       in Python
    imag: % -> Float            ++ imag       in Python
    _+: (%,%) -> %              ++ __add__    in Python
    _*: (%,%) -> %              ++ __mul__    in Python
    coerce: % -> OutputForm     ++ __str__    in Python
  == add
    Rep ==> Record(r:Float,i:Float)
    import Rep, OutputForm, Symbol

    new(realpart:Float,imagpart:Float):% == [realpart,imagpart] =
pretend %
    coerce(x:Float):% == new(x,0)
    real(x:%):Float == (x pretend Rep).r
    imag(x:%):Float == (x pretend Rep).i
    _+(x:%, y:%):% ==
      new(real(x)+real(y), imag(x)+imag(y))
    _*(x:%, y:%):% ==
       new(real(x)*real(y) - imag(x)*imag(y),
           real(x)*imag(y) + imag(x)*real(y))
    coerce(x:%):OutputForm ==
      if imag(x)<0 then
        real(x)::OutputForm - outputForm("i"::Symbol) *
(-imag(x))::OutputForm
      else
        real(x)::OutputForm + outputForm("i"::Symbol) * =
imag(x)::OutputForm
---

I have indicated the equivalent Python function by the ++
comment in each export.

This would be compiled in Axiom using the command:

(1) -> )compile complex.spad
   Compiling AXIOM source code from file
      C:/Documents and Settings/Administrator.ASUS/My =
Documents/complex.spad
      using old system compiler.
   CMPLXS abbreviates domain ComplexSpad
   ...

Then we may use this new domain like this:

(1) -> x := new(3.0, -4.5)$ComplexSpad

   (1)  3.0 - i 4.5
                                                Type: ComplexSpad
(2) -> y := new(-2.0, 5.4)$ComplexSpad

   (2)  - 2.0 + i 5.4
                                                Type: ComplexSpad
(3) -> x+y

   (3)  1.0 + i 0.9
                                                Type: ComplexSpad
(4) -> x*y

   (4)  18.3 + i 25.2
                                                Type: ComplexSpad
(5) -> x+1.0

   (5)  4.0 - i 4.5
                                                Type: ComplexSpad

There are a lot of good references to Python classes on the web
and in numerous books. Although the emphasis is on numerical
applications of Python I think a good introduction for Axiom
developers might be the following book:

  Python Scripting for Computational Science
  by Langtangen, Hans Petter
  2nd ed., 2006, XXIV, 736 p., 33 illus., Hardcover
  ISBN: 978-3-540-29415-3

http://www.springer.com/sgw/cda/frontpage/0,11855,1-40109-22-83511316-0,0=
0.h
tml

See especially section 8.6 on Classes.

Or for a more detailed and technical description of Python
classes with a C++ flavour you could try:

http://docs.python.org/tut/node11.html

For Python programmers the best introduction to domains and
categories in Axiom is probably the Axiom book:

http://wiki.axiom-developer.org/public/book2.pdf#page=940

You might want to consult the Aldor user's guide:

http://www.aldor.org/docs/HTML/index.html

Most of what is written here about Aldor also applies to the SPAD
programming language in Axiom. See especially chapter 7 on Types:

http://www.aldor.org/docs/HTML/chap7.html

Unfortunately this document might be overly technical as an
introduction and uses terms that might not be very familiar to
Python programmers.

> The question is - how the Axiom converts from the low level
> representation to the high level?
>

Now this question suggests to me the second problem. What we are
missing here is the distinction between symbolic computation and
computer algebra that has been discussed by Steven Watt (the
developer of Aldor) in several recent papers. See especially his
paper:

Making Computer Algebra More Symbolic

http://www.csd.uwo.ca/~watt/pub/reprints/2006-tc-sympoly.pdf

Abstract

This paper is a step to bring closer together two views of computing
with mathematical objects: the view of "symbolic computation" and
the view of "computer algebra". Symbolic computation may be seen as
working with expression trees representing mathematical formulae
and applying various rules to transform them. Computer algebra may
be seen as developing constructive algorithms to compute algebraic
quantities in various arithmetic domains, possibly involving
indeterminates. Symbolic computation allows a wider range of
expression, while computer algebra admits greater algorithmic
precision. ...

-----

So what Axiom does is basically "computer algebra" in the above
sense while what many other so called computer algebra systems
are doing is really better described at "symbolic computation".
What makes things a little fuzzy here is that Axiom also has an
algebraic domain called Expression which has many (but not all!)
of the characteristics as symbolic computation in these other
systems.

But from this point of view what Axiom is doing is fundamentally
different than what I think SymPy is doing. SymPy is doing
symbolic computation using a set of Python domains that implement
an Expression tree structure. But what Axiom is doing with it's
Expression domain is trying to define a mathematical object
starting with rational functions (Fraction Polynomial) and adding
a large number of special functions.

> A place that occurs to me to do it is just right after the
> evaluation to the canonical form:
>
> like Add(x,x) automatically converts to Mul(2,x)  and here, at
> this place, the CAS would check the expression and says: hey -
> the Mul(2,x) is a polynomial, let's return a Polynomial class
> instead.
>
> This would make sense to me, and we could do it in SymPy as well.
>

I think what Axiom is doing is very different.

\start
Date: 29 Mar 2007 09:03:20 +0200
From: Martin Rubey
To: Waldek Hebisch
Subject: Re: new problem compiling wh-sandbox, rev 470 (urgent...)
Cc: Gabriel Dos Reis

Waldek Hebisch writes:

> But I must admit that I saw quite a few weird build problems -- most of the
> time problem went away re-running make but some were repeatable.

Oh dear. So, why doesn't this happen with "GoldenAxiom"? Is the new build
procedure more sensitive to sloppy programming bugs?

> I was able to track some problems to real bugs (at some point Axiom generated
> wrong data structure, causing memory corruption later and finally a weird
> crash), but some went away due to seemingly unrelated changes (and most is
> not repeatable).  Since I suspect that we still may corrupt memory I tried to
> build Axiom setting GCL safety to 3.  After 16 hours the build stopped in
> guessing package with report about symbol having undefined value (I still
> have to investigate this deeper), but the previous parts build OK.

Well, meanwhile I was able to build most of axiom by building and installing
GCL (from build-improvements) separately. Before that, I almost consistently
got the error about missing ALIST.o. Might that help to track down the bug?

However, now the build stops in guess-pkg: FAMR2.NRLIB/code.o is missing.

Looking at trace, the problem seens to start in SUPEXPR, I get a "non extending
category" message there, albeit without any error message. The next domain
which is compiled is FAMR2, and there it says 

System error:
Cannot create the file FAMR2.erlib/index.KAF.

(Note that FAMR2 does *not* depend on SUPEXPR...)

\start
Date: Thu, 29 Mar 2007 01:28:29 -0600
From: Tim Daly
To: Martin Rubey
Subject: new problem compiling wh-sandbox

Martin,

In fact you've encountered the same problem I have been having
trying to merge gold, build-improvements, and wh-sandbox.
Along the way the algebra build stops working. I have yet to
find the exact source of the problem.

In frustration I've started from gold and built some tools 
to give me more information. In particular I now have machinery
that does automatic regression testing of the algebra input files.
The next release of the gold version is going to come out in 
smaller, more thoroughly tested pieces than I anticipated and
will initially contain fewer parts from build-improvements and
wh-sandbox than I wanted. I'm hoping to have gold-51 up this
weekend, including the new regression testing machinery.

The breakage is subtle. I'm trying to form small changesets,
apply each one, and then fully check the system. It is a slow,
tedious process and, unfortunately, won't have results in time
for your needs.

\start
Date: 29 Mar 2007 10:11:00 +0200
From: Martin Rubey
To: Tim Daly
Subject: Re: new problem compiling wh-sandbox
Cc: Christian Aistleitner

Tim Daly writes:

> Martin,
> 
> In fact you've encountered the same problem I have been having trying to
> merge gold, build-improvements, and wh-sandbox.  Along the way the algebra
> build stops working. I have yet to find the exact source of the problem.

OK. In fact, this demonstrates that it is *very* good to have a few (but not
too many) different versions of Axiom. Otherwise, we wouldn't even have noticed
that there might be a problem somewhere.

> In particular I now have machinery that does automatic regression testing of
> the algebra input files.

Very good! I hope that you had a look at Christian Aistleitner's package
AldorUnit. In case you had not, I copy a piece of test code from the species
project below, that might give you an idea of its power.

> The next release of the gold version is going to come out in smaller, more
> thoroughly tested pieces than I anticipated and will initially contain fewer
> parts from build-improvements and wh-sandbox than I wanted. I'm hoping to
> have gold-51 up this weekend, including the new regression testing machinery.

I'm glad that you are doing this!

> The breakage is subtle. I'm trying to form small changesets, apply each one,
> and then fully check the system. It is a slow, tedious process and,
> unfortunately, won't have results in time for your needs.

Don't worry, I found a well-working workaround: ssh -X aquin, where I have a
working system.

Below part of the "gseries.as.nw" test file. Note that the machinery of
AldorUnit automatically creates a file "gseries.signatures.as", which contains
the signatures necessary to compile "gseries.as".

%------------------------------------------------------------------
%---
%--- Combinat
%--- Copyright (C) Ralf Hemmecke
%--- svn co svn://svn.risc.uni-linz.ac.at/hemmecke/combinat/
%---
%------------------------------------------------------------------


This file test generating series.
Since our implementations of \useterm[ordinary]{ordinary generating series} and
\useterm{exponential generating series} rely on the implementation of
\useterm{formal power series} as given in \srcfile{src/gseries.as} we
only test \adname[ExponentialGeneratingSeries]{factorialStream} and
some \useterm{cycle index series}.



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Test Generating Series}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\addescribetype{TestGeneratingSeries}
%CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
<<*>>=
-------------------------------------------------------------------
----
---- Combinat
---- Copyright (C) Ralf Hemmecke
---- svn co svn://svn.risc.uni-linz.ac.at/hemmecke/combinat/
----
-------------------------------------------------------------------

#assert DontNeedLibraryTestCases
#include "testcases"

TestGeneratingSeries: TestCaseType with {
#include "gseries.signatures.as"
} == add {
        import from TestCaseTools;
        import from Integer, DataStream Integer, I;
        <<test series>>
}
@ %def TestGeneratingSeries
%TTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT



%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsubsection{Test FactorialStream}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%


The \useterm[Bell numbers]{Bell number} are given by the
\useterm{exponential generating series} $e^{(e^x-1)}$.

\addefinename{testComposeBell:()->()}%
%CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
<<test series>>=
testComposeBell(): () == {
        macro S == ExponentialGeneratingSeries;
        import from S, Q, DataStream Q;
        expx: S := stream(inv(fn) for fn in factorialStream) :: S;
        e: S := term(-1, 0);
        t: S := e + expx; -- (-1+exp(x))
        assertEquals(Integer, 0, count(t, 0));
        u := compose(expx, t);
        l1: List Integer := [1,1,2,5,15,52,203,877,4140,21147,115975];
        l2: List Integer := [count(u, i) for i in 0..prev #l1];
        assertEquals(List Integer, l1, l2);
}
@
%TTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT

\start
Date: Thu, 29 Mar 2007 10:40:15 +0200
From: Ralf Hemmecke
To: Martin Rubey
Subject: re: new problem compiling wh-sandbox
Cc: Christian Aistleitner

Hello,

> Below part of the "gseries.as.nw" test file. Note that the machinery of
> AldorUnit automatically creates a file "gseries.signatures.as", which contains
> the signatures necessary to compile "gseries.as".

To make it a bit more correct. gseries.signatures.as is *not* generated 
by AldorUnit, but rather by ALLPROSE or if you use AldorUnit in 
Christian's environment, then LibModel is generating the file. Both, 
ALLPROSE and LibModel (http://www.risc.uni-linz.ac.at/software/aldor/) 
are doing it by scanning patterns of the form

   testFUNCTIONNAME(): () == {

in the corresponding file. But that is a simple thing.

AldorUnit is great. Without it we wouldn't have been so far with 
Aldor-Combinat. It seems however not so totally trivial to adapt 
AldorUnit for Axiom since Axiom does not have exception handling. And 
there are some more details which Christian could report about.

Ralf

> %------------------------------------------------------------------
> %---
> %--- Combinat
> %--- Copyright (C) Ralf Hemmecke
> %--- svn co svn://svn.risc.uni-linz.ac.at/hemmecke/combinat/
> %---
> %------------------------------------------------------------------
> 
> 
> This file test generating series.
> Since our implementations of \useterm[ordinary]{ordinary generating series} and
> \useterm{exponential generating series} rely on the implementation of
> \useterm{formal power series} as given in \srcfile{src/gseries.as} we
> only test \adname[ExponentialGeneratingSeries]{factorialStream} and
> some \useterm{cycle index series}.
> 
> 
> 
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> \subsection{Test Generating Series}
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> \addescribetype{TestGeneratingSeries}
> %CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
> <<*>>=
> -------------------------------------------------------------------
> ----
> ---- Combinat
> ---- Copyright (C) Ralf Hemmecke
> ---- svn co svn://svn.risc.uni-linz.ac.at/hemmecke/combinat/
> ----
> -------------------------------------------------------------------
> 
> #assert DontNeedLibraryTestCases
> #include "testcases"
> 
> TestGeneratingSeries: TestCaseType with {
> #include "gseries.signatures.as"
> } == add {
>         import from TestCaseTools;
>         import from Integer, DataStream Integer, I;
>         <<test series>>
> }
> @ %def TestGeneratingSeries
> %TTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT
> 
> 
> 
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> \subsubsection{Test FactorialStream}
> %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
> 
> 
> The \useterm[Bell numbers]{Bell number} are given by the
> \useterm{exponential generating series} $e^{(e^x-1)}$.
> 
> \addefinename{testComposeBell:()->()}%
> %CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
> <<test series>>=
> testComposeBell(): () == {
>         macro S == ExponentialGeneratingSeries;
>         import from S, Q, DataStream Q;
>         expx: S := stream(inv(fn) for fn in factorialStream) :: S;
>         e: S := term(-1, 0);
>         t: S := e + expx; -- (-1+exp(x))
>         assertEquals(Integer, 0, count(t, 0));
>         u := compose(expx, t);
>         l1: List Integer := [1,1,2,5,15,52,203,877,4140,21147,115975];
>         l2: List Integer := [count(u, i) for i in 0..prev #l1];
>         assertEquals(List Integer, l1, l2);
> }
> @
> %TTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT

\start
Date: Thu, 29 Mar 2007 13:10:05 +0200
From: Ralf Hemmecke
To: list
Subject: Bug?

Am I doing something wrong?

Ralf

 >axiom
                         AXIOM Computer Algebra System
                        Version: Axiom (September 2006)
               Timestamp: Friday September 29, 2006 at 14:21:21
-----------------------------------------------------------------------------
    Issue )copyright to view copyright notices.
    Issue )summary for a summary of useful system commands.
    Issue )quit to leave AXIOM and return to shell.
-----------------------------------------------------------------------------

    Re-reading compress.daase   Re-reading interp.daase
    Re-reading operation.daase
    Re-reading category.daase
    Re-reading browse.daase
(1) ->
(1) -> )r abc
MyRing ==> with
             0: %
             -: % -> %


    >> System error:
    Caught fatal error [memory may be damaged]


------------------------
---BEGIN abc.input
MyRing ==> with
	    0: %
	    -: % -> %
---END abc.input


\start
Date: Thu, 29 Mar 2007 14:32:04 +0200
From: Ondrej Certik
To: Bill Page
Subject: Re: CAS for the masses
Cc: Gabriel Dos Reis

Thanks for your explanation - I didn't know there is a distinction
between symbolic manipulation (computation) and computer algebra
system.  But it makes sense.

I also think what can be done in Aldor can be pretty much done in
Python and vice versa. Ralf sent me a code that he thinks cannot be
easily rewritten in Python, but I still didn't have time to get
through it. But as you know Python - what exactly can be done in Aldor
that cannot be done in Python?

Ondrej

On 3/29/07, Bill Page wrote:
> On March 28, 2007 7:42 AM Ondrej Certik wrote:
> > ...
> > Expression tree (Add, Mul,...) are very low level types, and
> > you have many algorithms, that work with high level types like
> > Polynomial, Fraction, ODE, DAE, PDE, etc. I understand that.
> >
>
> I think that there may be two problems with this discussion so
> far.
>
> I think the first problem is that Axiom developers and Python
> programmers may not appreciate just how similar SPAD (or Aldor)
> and Python really is. Although Python is dynamically typed
> while Axiom is statically typed, both Python classes and Axiom
> domains support object-oriented programming in similar ways.
>
> I have been promising myself for some time now to take the time
> to write a more accessible introduction. So here is at least a
> start at this.
>
> A draft containing the examples below is available on the Axiom
> wiki as:
>
> http://wiki.axiom-developer.org/SandBoxSPADForPython
>
> For example, in Python we might define a simple class implementing
> complex numbers something like the following:
>
> ### file: complex.py
> class Complex:
>     "Example to demonstrate SPAD equivalent of Python Classes"
>     def __init__(self, realpart, imagpart):
>         self.r = realpart
>         self.i = imagpart
>     def real(self):
>       return self.r
>     def imag(self):
>       return self.i
>     def __str__(self):
>       if self.i<0:
>         return "%g - i %g"%(self.real(),-self.imag())
>       else:
>         return "%g + i %g"%(self.real(),self.imag())
>     def __coerce__(self,b):
>       if isinstance(b,Complex):
>          return(self,b)
>       else:
>          return(self,Complex(b,0))
>     def __add__(self,b):
>       return Complex(self.real()+b.real(), self.imag()+b.imag())
>     def __mul__(self,b):
>       return Complex(self.real()*b.real() - self.imag()*b.imag(),
>                      self.real()*b.imag() + self.imag()*b.real())
> ###
>
> >>> x = Complex(3.0, -4.5)
> >>> y = Complex(-2.0, 5.4)
> >>> print x
>   3.0 - i 4.5
> >>> print x+y
>   1 + i 0.9
> >>> print x*y
>   18.3 + i 25.2
> >>> print x+1.0
>   4 - i 4.5
>
> ------
>
> You can find details of how operator overloading in Python is done
> by using special names like __op__ explained here:
>
> http://docs.python.org/ref/customization.html
>
> In SPAD a domain equivalent to this Python class would be:
>
> --- file: complex.spad
> )abbrev domain CMPLXS ComplexSpad
> +++ Example of SPAD equivalent of Python Class
> ComplexSpad(): with
>     new: (Float,Float) -> %     ++ __init__   in Python
>     coerce: Float -> %          ++ __coerce__ in Python
>     real: % -> Float            ++ real       in Python
>     imag: % -> Float            ++ imag       in Python
>     _+: (%,%) -> %              ++ __add__    in Python
>     _*: (%,%) -> %              ++ __mul__    in Python
>     coerce: % -> OutputForm     ++ __str__    in Python
>   == add
>     Rep ==> Record(r:Float,i:Float)
>     import Rep, OutputForm, Symbol
>
>     new(realpart:Float,imagpart:Float):% == [realpart,imagpart] pretend %
>     coerce(x:Float):% == new(x,0)
>     real(x:%):Float == (x pretend Rep).r
>     imag(x:%):Float == (x pretend Rep).i
>     _+(x:%, y:%):% ==
>       new(real(x)+real(y), imag(x)+imag(y))
>     _*(x:%, y:%):% ==
>        new(real(x)*real(y) - imag(x)*imag(y),
>            real(x)*imag(y) + imag(x)*real(y))
>     coerce(x:%):OutputForm ==
>       if imag(x)<0 then
>         real(x)::OutputForm - outputForm("i"::Symbol) *
> (-imag(x))::OutputForm
>       else
>         real(x)::OutputForm + outputForm("i"::Symbol) * imag(x)::OutputForm
> ---
>
> I have indicated the equivalent Python function by the ++
> comment in each export.
>
> This would be compiled in Axiom using the command:
>
> (1) -> )compile complex.spad
>    Compiling AXIOM source code from file
>       C:/Documents and Settings/Administrator.ASUS/My Documents/complex.spad
>       using old system compiler.
>    CMPLXS abbreviates domain ComplexSpad
>    ...
>
> Then we may use this new domain like this:
>
> (1) -> x := new(3.0, -4.5)$ComplexSpad
>
>    (1)  3.0 - i 4.5
>                                                 Type: ComplexSpad
> (2) -> y := new(-2.0, 5.4)$ComplexSpad
>
>    (2)  - 2.0 + i 5.4
>                                                 Type: ComplexSpad
> (3) -> x+y
>
>    (3)  1.0 + i 0.9
>                                                 Type: ComplexSpad
> (4) -> x*y
>
>    (4)  18.3 + i 25.2
>                                                 Type: ComplexSpad
> (5) -> x+1.0
>
>    (5)  4.0 - i 4.5
>                                                 Type: ComplexSpad
>
> There are a lot of good references to Python classes on the web
> and in numerous books. Although the emphasis is on numerical
> applications of Python I think a good introduction for Axiom
> developers might be the following book:
>
>   Python Scripting for Computational Science
>   by Langtangen, Hans Petter
>   2nd ed., 2006, XXIV, 736 p., 33 illus., Hardcover
>   ISBN: 978-3-540-29415-3
>
> http://www.springer.com/sgw/cda/frontpage/0,11855,1-40109-22-83511316-0,00.h
> tml
>
> See especially section 8.6 on Classes.
>
> Or for a more detailed and technical description of Python
> classes with a C++ flavour you could try:
>
> http://docs.python.org/tut/node11.html
>
> For Python programmers the best introduction to domains and
> categories in Axiom is probably the Axiom book:
>
> http://wiki.axiom-developer.org/public/book2.pdf#page=940
>
> You might want to consult the Aldor user's guide:
>
> http://www.aldor.org/docs/HTML/index.html
>
> Most of what is written here about Aldor also applies to the SPAD
> programming language in Axiom. See especially chapter 7 on Types:
>
> http://www.aldor.org/docs/HTML/chap7.html
>
> Unfortunately this document might be overly technical as an
> introduction and uses terms that might not be very familiar to
> Python programmers.
>
> > The question is - how the Axiom converts from the low level
> > representation to the high level?
> >
>
> Now this question suggests to me the second problem. What we are
> missing here is the distinction between symbolic computation and
> computer algebra that has been discussed by Steven Watt (the
> developer of Aldor) in several recent papers. See especially his
> paper:
>
> Making Computer Algebra More Symbolic
>
> http://www.csd.uwo.ca/~watt/pub/reprints/2006-tc-sympoly.pdf
>
> Abstract
>
> This paper is a step to bring closer together two views of computing
> with mathematical objects: the view of "symbolic computation" and
> the view of "computer algebra". Symbolic computation may be seen as
> working with expression trees representing mathematical formulae
> and applying various rules to transform them. Computer algebra may
> be seen as developing constructive algorithms to compute algebraic
> quantities in various arithmetic domains, possibly involving
> indeterminates. Symbolic computation allows a wider range of
> expression, while computer algebra admits greater algorithmic
> precision. ...
>
> -----
>
> So what Axiom does is basically "computer algebra" in the above
> sense while what many other so called computer algebra systems
> are doing is really better described at "symbolic computation".
> What makes things a little fuzzy here is that Axiom also has an
> algebraic domain called Expression which has many (but not all!)
> of the characteristics as symbolic computation in these other
> systems.
>
> But from this point of view what Axiom is doing is fundamentally
> different than what I think SymPy is doing. SymPy is doing
> symbolic computation using a set of Python domains that implement
> an Expression tree structure. But what Axiom is doing with it's
> Expression domain is trying to define a mathematical object
> starting with rational functions (Fraction Polynomial) and adding
> a large number of special functions.
>
> > A place that occurs to me to do it is just right after the
> > evaluation to the canonical form:
> >
> > like Add(x,x) automatically converts to Mul(2,x)  and here, at
> > this place, the CAS would check the expression and says: hey -
> > the Mul(2,x) is a polynomial, let's return a Polynomial class
> > instead.
> >
> > This would make sense to me, and we could do it in SymPy as well.
> >
>
> I think what Axiom is doing is very different.

\start
Date: 29 Mar 2007 09:20:36 -0500
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: new problem compiling wh-sandbox

Tim Daly writes:

| Martin,
| 
| In fact you've encountered the same problem I have been having
| trying to merge gold, build-improvements, and wh-sandbox.

I would be interested in understanding why I'm not seeing the build
failure.  This is important because it would be good to have fixes
from wh-sandbox in build-improvements.

Do you have initial guesses?

\start
Date: 29 Mar 2007 09:26:42 -0500
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: Bug?

Ralf Hemmecke writes:

| Am I doing something wrong?
| 
| Ralf
| 
|  >axiom
|                          AXIOM Computer Algebra System
|                         Version: Axiom (September 2006)
|                Timestamp: Friday September 29, 2006 at 14:21:21
| -----------------------------------------------------------------------------
|     Issue )copyright to view copyright notices.
|     Issue )summary for a summary of useful system commands.
|     Issue )quit to leave AXIOM and return to shell.
| -----------------------------------------------------------------------------
| 
|     Re-reading compress.daase   Re-reading interp.daase
|     Re-reading operation.daase
|     Re-reading category.daase
|     Re-reading browse.daase
| (1) ->
| (1) -> )r abc
| MyRing ==> with
|              0: %
|              -: % -> %
| 
| 
|     >> System error:
|     Caught fatal error [memory may be damaged]

I may be wrong but I don't think the "Input" language supports
category, domains and package expressions.

\start
Date: Thu, 29 Mar 2007 10:29:17 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: RE: Bug?

On March 29, 2007 7:10 AM Ralf Hemmecke wrote:
> 
> Am I doing something wrong?
>

That depends on what you are trying to do. You did not
explain and your example is not self explanatory (to me
at least).
 
> ...
> (1) -> )r abc
> MyRing ==> with
>              0: %
>              -: % -> %
> 
> 
>     >> System error:
>     Caught fatal error [memory may be damaged]
> 
> 
> ------------------------
> ---BEGIN abc.input
> MyRing ==> with
> 	    0: %
> 	    -: % -> %
> ---END abc.input
> 

You seem to be trying to define a macro in the Axiom
interpreter that would normally only be used in the
SPAD compiler. The interpreter does not directly support
the notation for categories, domains or packages.

What you are trying to do might work if the file is
named 'abc.spad' and you enter the command:

)co abc.spad

---------

Or do I misunderstand your intentions?

\start
Date: Thu, 29 Mar 2007 16:37:49 +0200 (CEST)
From: Waldek Hebisch
To: Martin Rubey
Subject: Re: new problem compiling wh-sandbox,	rev 470 (urgent...)
Cc: Gabriel Dos Reis

Martin Rubey wrote:
Waldek Hebisch writes:
> 
> > But I must admit that I saw quite a few weird build problems -- most of the
> > time problem went away re-running make but some were repeatable.
> 
> Oh dear. So, why doesn't this happen with "GoldenAxiom"? Is the new build
> procedure more sensitive to sloppy programming bugs?
>

I belive that Gold really has the same problems.  To tigger rarely occuring
bugs one have to vary parameters.  Since Gold is essentially frozen
there is probably not enough variation to see such bugs during
build.  But we do have bug reports about "System error", so I would
say that get weird errors at runtime.

Also, on my main test machines Gold does not build (it builds after small
changes, but then it is not Gold any more).  It is possible that only
few people build Axiom on machines which are likely to have such
problems

FYI I noticed first problems few months ago, working on small variation
of build-improvements.  I first thought that the problem is with
test machines (it is still one possibility that I consider).  But
since later I tracked similar problems to real bugs I now think that
we probably have more such bugs.

> Well, meanwhile I was able to build most of axiom by building and installing
> GCL (from build-improvements) separately. Before that, I almost consistently
> got the error about missing ALIST.o. Might that help to track down the bug?
> 

Missing ALIST.o typically means error during compilation.  The error
may be in compilation of ALIST.spad (which is already too general
to be useful), but it may be also in some other file: bootstrap compiles
files in special order (to satisfy dependencies), but errors are
discovered only during copy (which works in alphabltical order).

So one really has to look at trace to find out what happened.

> However, now the build stops in guess-pkg: FAMR2.NRLIB/code.o is missing.
> 
> Looking at trace, the problem seens to start in SUPEXPR, I get a "non extending
> category" message there, albeit without any error message.

I think this is normal



> The next domain
> which is compiled is FAMR2, and there it says 
> 
> System error:
> Cannot create the file FAMR2.erlib/index.KAF.
> 

The only regularity I see is that your problems involve system calls.

\start
Date: Thu, 29 Mar 2007 10:40:05 -0400
From: Bill Page
To: Gabriel Dos Reis, Tim Daly
Subject: RE: new problem compiling wh-sandbox

On March 29, 2007 10:21 AM Gabriel Dos Reis wrote:
> 
> Tim Daly writes:
> 
> | Martin,
> | 
> | In fact you've encountered the same problem I have been
> | having trying to merge gold, build-improvements, and
> | wh-sandbox.
> 
> I would be interested in understanding why I'm not seeing
> the build failure.  This is important because it would be
> good to have fixes from wh-sandbox in build-improvements.
> 
> Do you have initial guesses?
> 

I have seen problems similar to what Martin describes when
I build Axiom Gold (patch-49 and patch-50), build-improvements
and wh-sandbox on the axiom-developer.org server. The same
source codes build properly for me on SuSE 10.2.

The axiom-developer.org server runs as a shared virtual host
using a variant of the Red Hat linux kernel I am not exactly
sure the of details, but the upshot is that the linux memory
management in this configuration is a little different. As a
result it does not support the configure option

 --maxpages=256*1024

I have to manually build gcl with a smaller memory size. With
gcl-2.6.8pre it is possible to use values that are not powers
of 2 and it seems that almost any size less than 256*1024 will
work. Right now I am using

  --maxpages=196*1024

and the build completes normally.

I am not sure whether this is related to Martin and Tim's
problem or not but it is my initial guess.

\start
Date: 29 Mar 2007 09:47:33 -0500
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: new problem compiling wh-sandbox

Bill Page writes:

| On March 29, 2007 10:21 AM Gabriel Dos Reis wrote:
| > 
| > Tim Daly writes:
| > 
| > | Martin,
| > | 
| > | In fact you've encountered the same problem I have been
| > | having trying to merge gold, build-improvements, and
| > | wh-sandbox.
| > 
| > I would be interested in understanding why I'm not seeing
| > the build failure.  This is important because it would be
| > good to have fixes from wh-sandbox in build-improvements.
| > 
| > Do you have initial guesses?
| > 
| 
| I have seen problems similar to what Martin describes when
| I build Axiom Gold (patch-49 and patch-50), build-improvements
| and wh-sandbox on the axiom-developer.org server. The same
| source codes build properly for me on SuSE 10.2.

All my boxes have been upgraded in the last two weeks to SuSE 10.2...
I'm installing solaris 11 on 64bit intel-based machine I just
acquired, once I'm finished I'll try testing there.

| The axiom-developer.org server runs as a shared virtual host
| using a variant of the Red Hat linux kernel I am not exactly
| sure the of details, but the upshot is that the linux memory
| management in this configuration is a little different. As a
| result it does not support the configure option
| 
|  --maxpages=256*1024
| 
| I have to manually build gcl with a smaller memory size. With
| gcl-2.6.8pre it is possible to use values that are not powers
| of 2 and it seems that almost any size less than 256*1024 will
| work. Right now I am using
| 
|   --maxpages=196*1024
| 
| and the build completes normally.

OK.

| I am not sure whether this is related to Martin and Tim's
| problem or not but it is my initial guess.

Anyway, it is useful configuration information to have.
Did we have Axiom buildable with another Lisp system we would have a
different angle from which to attack the issue...

\start
Date: 29 Mar 2007 09:48:42 -0500
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: Bug?

Bill Page writes:

|                The interpreter does not directly support
| the notation for categories, domains or packages.

Yes, and I consider that a bug.  But, I've already said that. :-)

\start
Date: 29 Mar 2007 10:05:48 -0500
From: Gabriel Dos Reis
To: Gregory Vanuxem
Subject: Re: depsys and SBCL

Gregory Vanuxem writes:

| Le mardi 27 mars 2007 =E0 11:05 -0500, Gabriel Dos Reis a =E9crit :
| > Hello,
| >
| >   In my local tree, I was able to eventually twist Axiom to get it
| > compilable by SBCL.  During that process, I unconvered various dubious
| > practices in the current system (mainly between vmlisp.lisp and
| > macro.lisp).  SBCL will accept to compile depsys only if I tell it to
| > ignore many redefinitions of Common Lisp symbols (I'll discuss that in
| > a separate message).
| >
| >   CLISP almost compiles SBCL -- it errors out on def.lisp saying
| > that there is an illegal character #\Stx in the source file -- I have
| > no idea of what that means.  If I omit def.lisp, the depsys
| > compiles fine --
|
| Hmm... I forgot to add this issue to my TODO list. I temporary followed
| how GCL behaves i.e omit it. I was/am pretty sure this is incorrect but
| as far as I know this part of code is not used. I just commented out
| this function. ^L is also used at several places.


Hi Greg,

   Thanks for sharing your thoughts on this.

| >I have not tried the resulting translator however.
|
| Did you modify the "funcalled symbols" FUNCALL('FOO) -> FUNCALL(function
| (foo)) as done by Juergen Weiss ? I based my work on his work and this
| version does not contain all the src/interp file that we can find in
| Gold. Adding a new file is always difficult because of this issue (that
| must be done carefully).

I did not get into that issue -- and where can I find Juergen Weiss' work?

| > This is just a head up.  If you know anything about the illegal
| > character \#Stx, please let me know.
|
| No idea.

OK.

| > Ah, one more thing: Currently, there is this dubious definition in
| > foam_l.lisp:
| >
| >    #+:AKCL
| >    (deftype |DFlo| () t)
| >    #-:AKCL
| >    (deftype |DFlo| () 'long-float)
| >
| > followed by
| >
| >    (defconstant |DFloInit| (the |DFlo| 0.0d0))
| >
| > which is an error because 0.0d0 is not long-float -- rather a double-fl=
oat.
| >
| > Looking more at this, I think the |DFlo| should not be conditional.
|
| I don't know why the Aldor implementers used the t type to define DFlo
| on AKCL and since we do not have access to the Aldor source code it's
| difficult to know why. There are other issues in this file, for example
| it _seems_ that the SInt type has to be a 32 bits integer (on a 32bit
| arch) but they defined it to be a fixnum. This is clearly wrong on CMUCL
| and Clisp (and probably other), their fixnums are 29 bits integers if I
| remember correctly (and if log2 MOST-POSITIVE-FIXNUM really represents
| that). For other issues you can look at the tarball that I uploaded [1].

Please, could you point me (again!) to your tarball?  My memory is
volatile and I cannot find a record in my mailbox.  Sorry about that.

| A quick note here, the last (beta) version of Aldor comes without an
| indispensable file, runtime.lsp [2]. I hope they will continue to
| support the lisp backend though I rarely use it.

I have not installed Aldor on my machine.

| > Furthermore, I think we should use double-float instead of long-float
| > -- it fits more in most modern FPU and its underyling representation
| > is more widely uniform.
| > This is a change for people connecting Axiom to Aldor through FOAM.
|
| I totally agree, this should be done everywhere (in the algebra too:
| DFLOAT.spad). From what I know the Lisp double-float type is generally a
| hardware float (see for example
| http://www.cs.berkeley.edu/~mhoemmen/matlisp/floating-point.html). But
| this is not the case for long-float on Clisp (arbitrary precision). We
| might add a new type that represent hardware float.

OK.  Thanks for your feedback.

\start
Date: Thu, 29 Mar 2007 11:13:48 -0400
From: Bill Page
To: Ondrej Certik
Subject: RE: CAS for the masses
Cc: Gabriel Dos Reis

On March 29, 2007 8:32 AM Ondrej Certik wrote:
> 
> Thanks for your explanation - I didn't know there is a
> distinction between symbolic manipulation (computation) and
> computer algebra system.  But it makes sense.

Not everyone agrees with Steven Watt about this, but I do. :-)

> 
> I also think what can be done in Aldor can be pretty much done
> in Python and vice versa. Ralf sent me a code that he thinks
> cannot be easily rewritten in Python, but I still didn't have
> time to get through it. But as you know Python - what exactly
> can be done in Aldor that cannot be done in Python?
> 

Well as Ralf said, it is a matter of how "easy" or "difficult"
it might be, not whether it is possible or not since both Python
and SPAD (and Aldor) are general purpose programming languages
that can, in principle given enough memory and time, be used to
implement anything that is computable.

Python lacks the concept of "category" that is essential to the
structure of the Axiom library. Categories in SPAD and Aldor are
said to be like "interfaces" in Java. Domains belong to categories
in a manner similar to the way instances (members) belong to
domains. But there are subtle differences in the 'with' inheritance
between categories, the 'has' inheritance between domains and
categories and the "add" inheritance between domains. The result
is not the same as inheritance of classes in Python which
corresponds most directly to "add" inheritance in SPAD and Aldor.
Refer to the discussion in chapter 7 of the Aldor users guide.

The Axiom library makes extensive use of categories to represent
abstract mathematical concepts, e.g. SetCategory,
FiniteFieldCategory, etc. and to support generic programming,
i.e. algorithms that can be applied to large classes of domains.
In Aldor categories are also used to represent mathematical
"axioms" or properties which are associated with Axiom domains.

On the other hand Python does directly support building classes
at run time while domains and categories can only be defined at
compile-time in Axiom. As a result it is likely that categories
can be effectively represented in Python with a little more
coding. In fact, I think that is essentially what is done in
Sage with their concept of the "parent" class that is distinct
from class inheritance (but I have not looked at this closely
enough yet).

Section 8.9.5 of the Langtangen book has a discussion of C++
style generic programming (templates) and how this can be
implemented in Python. Most of the differences and difficulties
have to do with static typing in C++, SPAD and Aldor versus the
dynamic typing of Python. In Python it is necessary to use
some form of type reflection, e.g. isinstance. Because of this
the claim is that it is diffcult (but maybe not impossible) to
write efficient generic code in the current versions of Python.

\start
Date: Thu, 29 Mar 2007 11:32:50 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: RE: Bug?

On March 29, 2007 11:03 AM Ralf Hemmecke wrote:
> ... 
> I was about extending the page
> 
> http://wiki.axiom-developer.org/SandBoxSPADForPython
> 
> showing that Aldor allows parametrized domains and did not
> want to introduce a new category MyRing, so I made it a macro.
> Aldor could equally compile the code, but I had problems in
> using it from inside Axiom. Axiom always claimed that Complex2
> was not available.

Yes. I did not have time last night to add a section to my
email about "functors", i.e. parameterized domains. But it is
important for Python programmers to understand that the Complex
domain in Axiom is not implemented the way I showed in my
example. In fact, Complex is a domain constructor that takes
a type as an argument, e.g.

  x:Complex(Float)

and that we automatically have Complex of any other domain
that has the category CommutativeRing.

> 
> Do you want me to repoduce the behaviour on the Sandbox?
> 

I think what you were trying to show is easily possible.
Yes please reproduce on another SandBox page and a little
later today I will see if I can solve the problem.

\start
Date: Thu, 29 Mar 2007 09:46:15 -0600
From: Tim Daly
To: Martin Rubey
Subject: root cause

the "root cause" of the failure is unknown, but it first
shows up when i merged the changes for xrun and xruncomp.
these seemed to be ok but they might have triggered another
bug somewhere else. so far i've been unsuccessful in finding
the bug so i've started over.

\start
Date: Thu, 29 Mar 2007 09:51:52 -0600
From: Tim Daly
To: Martin Rubey, Ralf Hemmecke
Subject: aldorunit vs regression tests

the AldorUnit package is testing algebra functions for correct results.
this kind of unit testing is certainly needed but is well beyond my
powers for portions of axiom's algebra.

my regression test code simply compares prior results to current results
to highlight things that have changed. it makes no distinction between
a correct result and an incorrect result. only different results matter.
regression testing is much weaker than unit testing but attacks the 
problem at hand, i.e. does this break something?

\start
Date: Thu, 29 Mar 2007 17:54:41 +0200
From: Gregory Vanuxem
To: Gabriel Dos Reis
Subject: Re: depsys and SBCL

Le jeudi 29 mars 2007 =E0 10:05 -0500, Gabriel Dos Reis a =E9crit :
[...]
> |
> | Did you modify the "funcalled symbols" FUNCALL('FOO) -> FUNCALL(function
> | (foo)) as done by Juergen Weiss ? I based my work on his work and this
> | version does not contain all the src/interp file that we can find in
> | Gold. Adding a new file is always difficult because of this issue (that
> | must be done carefully).
>
> I did not get into that issue -- and where can I find Juergen Weiss' work?

Here are the Juergen Weiss sources:

http://www.staff.uni-mainz.de/weiss/axiom_cmu.tgz

and mine

http://perso.orange.fr/parabola/axiom-cl.tar.gz

\start
Date: Thu, 29 Mar 2007 18:04:45 +0200
From: Gregory Vanuxem
To: Gabriel Dos Reis
Subject: Re: depsys and SBCL

And see also this message if you want to build it:

http://lists.gnu.org/archive/html/axiom-developer/2007-02/msg00202.html

(this version is very handy when you want to debug Axiom)

Le jeudi 29 mars 2007 =E0 17:54 +0200, Gregory Vanuxem a =E9crit :
> Le jeudi 29 mars 2007 =E0 10:05 -0500, Gabriel Dos Reis a =E9crit :
> [...]
> > |
> > | Did you modify the "funcalled symbols" FUNCALL('FOO) -> FUNCALL(function
> > | (foo)) as done by Juergen Weiss ? I based my work on his work and this
> > | version does not contain all the src/interp file that we can find in
> > | Gold. Adding a new file is always difficult because of this issue (that
> > | must be done carefully).
> >
> > I did not get into that issue -- and where can I find Juergen Weiss' work?
>
> Here are the Juergen Weiss sources:
>
> http://www.staff.uni-mainz.de/weiss/axiom_cmu.tgz
>
> and mine
>
> http://perso.orange.fr/parabola/axiom-cl.tar.gz

\start
Date: Thu, 29 Mar 2007 18:13:42 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: Bug?

>> Do you want me to repoduce the behaviour on the Sandbox?
>>
> 
> I think what you were trying to show is easily possible.
> Yes please reproduce on another SandBox page and a little
> later today I will see if I can solve the problem.

On
http://wiki.axiom-developer.org/SandBoxDomainNotValid
you'll find the construction with the macro instead of the category.

a: CI := new(2, 1)
    Complex2 Integer is not a valid type.

Interestingly, if one really expends the macro by hand, then Aldor 
allows a construction of the form

A: with {foo: % -> %} with == add {...}

Well, it looks weird, but I think the language definition doesn't forbid 
that.

\start
Date: Thu, 29 Mar 2007 11:13:03 -0500
From: Gabriel Dos Reis
To: Gregory Vanuxem
Subject: Re: depsys and SBCL

Quoting Gregory Vanuxem:

> Le jeudi 29 mars 2007 =E0 10:05 -0500, Gabriel Dos Reis a =E9crit :
> [...]
>> |
>> | Did you modify the "funcalled symbols" FUNCALL('FOO) -> FUNCALL(functi=
on
>> | (foo)) as done by Juergen Weiss ? I based my work on his work and this
>> | version does not contain all the src/interp file that we can find in
>> | Gold. Adding a new file is always difficult because of this issue (tha=
t
>> | must be done carefully).
>>
>> I did not get into that issue -- and where can I find Juergen Weiss' wor=
k?
>
> Here are the Juergen Weiss sources:
>
> http://www.staff.uni-mainz.de/weiss/axiom_cmu.tgz
>
> and mine
>
> http://perso.orange.fr/parabola/axiom-cl.tar.gz
>

\start
Date: Thu, 29 Mar 2007 19:02:37 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: CAS for the masses
Cc: Gabriel Dos Reis

Hallo Bill,

> On the other hand Python does directly support building classes
> at run time while domains and categories can only be defined at
> compile-time in Axiom.

Could you elaborate on this (on the python and aldor side). Can you give 
a small example what you think is possible in python that cannot be done 
with aldor. At first glance I have my doubts that "domains can only be 
defined at compile time in aldor". Already Aldor's ability to write 
domain-constructing functions is a counter example. But you probably 
meant something else.

\start
Date: 29 Mar 2007 19:37:00 +0200
From: Martin Rubey
To: Ralf Hemmecke
Subject: Re: kTuple wish

Ralf Hemmecke writes:

> Suppose I want to write a domain that takes a finite number of domains
> satisfying a certain category "LabelType".
> 
> I write kTuple instead of Tuple, because the Aldor-Tuple constructor
> is not suitable for what I want. In particular, if
> 
>    T: Tuple PrimitiveType
> 
> then I T = (Integer, String, Boolean, String) would be one possible
> value for T. 

I guess that "I T" should be "T"? 

> However, an element of T is not a Tuple, since T (not its
> type) is non-homogeneous. 

Did you want to say: "an element of T is not a PrimitiveType"? I do not
understand either, in fact:

%1 >> #include "aldor"
                                           Comp: 200 msec, Interp: 40 msec
%2 >> #include "aldorinterp"
                                           Comp: 80 msec, Interp: 0 msec
%3 >> import from Tuple PrimitiveType
                                           Comp: 0 msec, Interp: 0 msec
%4 >> T: Tuple PrimitiveType := (Integer, String, Boolean, String)
  () @ Tuple(PrimitiveType)
                                           Comp: 10 msec, Interp: 60 msec
%5 >> Tuple PrimitiveType
  () @ Join(
 with 
    ==  add ()
, 
 with 
        element: (%, MachineInteger) -> PrimitiveType
        dispose!: % -> ()
        length: % -> MachineInteger
        tuple: (MachineInteger, Pointer) -> %
    ==  add ()
)
                                           Comp: 10 msec, Interp: 80 msec
%6 >> import from MachineInteger
                                           Comp: 30 msec, Interp: 0 msec
%7 >> element(T, machine 1)
  () @ PrimitiveType
                                           Comp: 0 msec, Interp: 30 msec

\start
Date: Thu, 29 Mar 2007 20:39:09 +0200
From: Ralf Hemmecke
To: Martin Rubey
Subject: Re: kTuple wish

On 03/29/2007 07:37 PM, Martin Rubey wrote:
> Dear Ralf,
> 
> Ralf Hemmecke writes:
> 
>> Suppose I want to write a domain that takes a finite number of domains
>> satisfying a certain category "LabelType".
>>
>> I write kTuple instead of Tuple, because the Aldor-Tuple constructor
>> is not suitable for what I want. In particular, if
>>
>>    T: Tuple PrimitiveType
>>
>> then I T = (Integer, String, Boolean, String) would be one possible
>> value for T. 

> I guess that "I T" should be "T"? 

Of course.

>> However, an element of T is not a Tuple, since T (not its
>> type) is non-homogeneous. 

> Did you want to say: "an element of T is not a PrimitiveType"?

If T = (Integer, String) then by "element" I neither meant Integer nor 
String, but rather a t so that t: T.

Try to show me such a t. And then try to convince me that it is a Tuple.

\start
Date: 29 Mar 2007 22:05:02 +0200
From: Martin Rubey
To: Ralf Hemmecke
Subject: Re: kTuple wish

I cannot find the mail anymore in which you explained why you want to have
several labeltypes for multisort species. I think the argument was because of
functorial composition, but I cannot remember well...

\start
Date: Thu, 29 Mar 2007 17:21:52 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: Re: Bug?

Quoting Ralf Hemmecke:

> ...
> On
> http://wiki.axiom-developer.org/SandBoxDomainNotValid
> you'll find the construction with the macro instead of the category.
>
> a: CI := new(2, 1)
>     Complex2 Integer is not a valid type.
>

Axiom says Complex2(Integer) is not valid because it thinks Integer
does not satisfy the category which you denoted by the macro MyRing.

macro MyRing == with
     0: %
     -: % -> %
     -: (%,%) -> %
     +: (%,%) -> %
     *: (%,%) -> %
     coerce: % -> OutputForm

But Integer has Ring so if you add 3 new functions to Complex2,  1, =
and characteristic() then both Integer and Complex2 can satisfy Ring.
See my revised code here:

http://wiki.axiom-developer.org/SandBoxDomainNowValid

> Interestingly, if one really expends the macro by hand, then Aldor
> allows a construction of the form
>
> A: with {foo: % -> %} with == add {...}
>
> Well, it looks weird, but I think the language definition doesn't forbid
> that.
>

You are right that this is valid Aldor code even if you use the macro.
That is not the problem. The actual problem is that you are trying
to use what in Aldor is called an anonymous category, i.e. a category
with no real name (The macro name is not the name of a category,
it is only the name of some string of characters.) in the Axiom interpreter.
Apparently the interpreter does not understand how to evaluate Aldor
anonymous categories.

I guess once Aldor becomes open source we could classify this as
a bug. :-)

\start
Date: Fri, 30 Mar 2007 00:24:12 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: Bug?

> But Integer has Ring so if you add 3 new functions to Complex2,  1, =
> and characteristic() then both Integer and Complex2 can satisfy Ring.

I feared that the anonymous category or the "0: %" were the problem.
But now it is good to know that I should currently avoid the use of 
anonymous categories if I want my code to run in Axiom.

> Apparently the interpreter does not understand how to evaluate Aldor
> anonymous categories.

> I guess once Aldor becomes open source

According to
http://www.aldor.org/pipermail/aldor-l/2007-March/000620.html
we should have some news at the end of this week.

> we could classify this as a bug. :-)

So if SPAD cannot handle anonymous categories and is seems it cannot
http://wiki.axiom-developer.org/SandboxNoAnonymousCategoryMacro
then this is a bug even without free Aldor.

\start
Date: Thu, 29 Mar 2007 19:04:18 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: Re: Bug?

Quoting Ralf Hemmecke:

>> But Integer has Ring so if you add 3 new functions to Complex2,  1, =
>> and characteristic() then both Integer and Complex2 can satisfy Ring.
>
> I feared that the anonymous category or the "0: %" were the problem.
> But now it is good to know that I should currently avoid the use of
> anonymous categories if I want my code to run in Axiom.

I think the problem is confined to just the Axiom interpreter.

>
>> Apparently the interpreter does not understand how to evaluate Aldor
>> anonymous categories.
>
>> I guess once Aldor becomes open source
>
> According to
> http://www.aldor.org/pipermail/aldor-l/2007-March/000620.html
> we should have some news at the end of this week.
>

I certainly hope so and I hope the "news" is good, but considering the
history of this project I don't think that we can necessarily depend on it.

>> we could classify this as a bug. :-)

Of course it is a bug in any case.

>
> So if SPAD cannot handle anonymous categories and is seems it cannot
> http://wiki.axiom-developer.org/SandboxNoAnonymousCategoryMacro
> then this is a bug even without free Aldor.
>

No, this construction is ok in both SPAD and Aldor, but in SPAD you
need to escape some special characters. I have added the necessary
_ and now it compiles.

http://wiki.axiom-developer.org/SandboxNoAnonymousCategoryMacro/diff

\start
Date: 29 Mar 2007 18:37:34 -0500
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: Bug?

Ralf Hemmecke writes:

| > But Integer has Ring so if you add 3 new functions to Complex2,  1, =
| > and characteristic() then both Integer and Complex2 can satisfy Ring.
| 
| I feared that the anonymous category or the "0: %" were the problem.
| But now it is good to know that I should currently avoid the use of
| anonymous categories if I want my code to run in Axiom.

You can use unnamed categories in Spad -- and in fact the Axiom
algebra does, and that is the way you build new catgories that extends
only Category.  However you do need to distinguish between ".input"
files and ".spad" files.  

".input" files can contain only a very simplified and losely typed
programs. 

".spad" files are where you really want to put your libraries -- you
get the full Spad language.

[...]

| > we could classify this as a bug. :-)
| 
| So if SPAD cannot handle anonymous categories and is seems it cannot

It appears to me that you're confusing the Spad language and the
language you can use at the interpreter level (i.e. in ".input"
files).

\start
Date: Thu, 29 Mar 2007 23:07:10 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: domains with parameters versus Python classes

Ralf,

I have moved your example of a domain with parameters to a
new page and added some explanatory text plus an new example
in Python that does the same thing apparently without the
complication of defining categories. See:

http://wiki.axiom-developer.org/SandBoxSPADForPython2

For Python developers this might be interpreted as an
argument in favor of Python and against Aldor/Spad. So
I think we need to find another more convincing example. :-)

\start
Date: 29 Mar 2007 22:12:24 -0500
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: domains with parameters versus Python classes

Bill Page writes:

| Ralf,
| 
| I have moved your example of a domain with parameters to a
| new page and added some explanatory text plus an new example
| in Python that does the same thing apparently without the
| complication of defining categories. See:
| 
| http://wiki.axiom-developer.org/SandBoxSPADForPython2
| 
| For Python developers this might be interpreted as an
| argument in favor of Python and against Aldor/Spad. So
| I think we need to find another more convincing example. :-)

Just be aware that that is a slippery slot...

\start
Date: Thu, 29 Mar 2007 23:30:16 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: Re: domains with parameters versus Python classes

Quoting Gabriel Dos Reis:

> Bill Page writes:
> ...
> | See:
> |
> | http://wiki.axiom-developer.org/SandBoxSPADForPython2
> |
> | For Python developers this might be interpreted as an
> | argument in favor of Python and against Aldor/Spad. So
> | I think we need to find another more convincing example. :-)
>
> Just be aware that that is a slippery slot...
>

Hmmm... "a slippery slot"?

I presume you mean that we could easily get stuck endlessly
trying to making such comparisons without advancing the
Axiom project in any substantial way? Perhaps.

But the point of this exercise for me is still to present Spad
for Python programmers - not really an argument for or against
one or the other. Presenting it this way as a challenge seems
like a way of motivating more interest in this subject. I think this
is important for some of the same reasons that people currently
doing computer algebra and symbolic computation in Python
(e.g. SymPy and Sage) think it is important: because there are
a *lot* of people who know or are learning to program in Python
while there is a much much smaller number of people who have
or are developing the skills to program in Axiom. If Axiom (and
Aldor) has a future, I think we have to find some way to interest
even a small share of that talent.

\start
Date: Fri, 30 Mar 2007 00:01:07 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: Re: CAS for the masses
Cc: Gabriel Dos Reis

Quoting Ralf Hemmecke:

> Bill Page wrote:
>> On the other hand Python does directly support building classes
>> at run time while domains and categories can only be defined at
>> compile-time in Axiom.
>
> Could you elaborate on this (on the python and aldor side). Can you give
> a small example what you think is possible in python that cannot be done
> with aldor. At first glance I have my doubts that "domains can only be
> defined at compile time in aldor". Already Aldor's ability to write
> domain-constructing functions is a counter example. But you probably
> meant something else.
>

You are right that I did not state this properly. Of course we can
evaluate expressions (including functions) that return domains
and categories. What I was trying to say is that domains in Spad
and Aldor are immutable during run-time. Once constructed their
"value" is constant and can not be changed. For example we
can not insert or remove anything in the list of exports or even
replace one exported function with another during the execution
of the program. This is possible in Python.

Note: I am not talking about the post facto library extension feature
in Aldor. 'extend' is a compile-time operation.

In Python on the other hand new classes can be created dynamically.
See for example the method '__new__'  in

http://docs.python.org/ref/customization.html

and the module 'new' here:

http://docs.python.org/lib/module-new.html

\start
Date: Fri, 30 Mar 2007 00:49:02 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: Re: domains with parameters versus Python classes

Quoting Bill Page:

> I have moved your example of a domain with parameters to a
> new page and added some explanatory text plus an new
> example in Python that does the same thing apparently
> without the complication of defining categories. See:
>
> http://wiki.axiom-developer.org/SandBoxSPADForPython2
>
> For Python developers this might be interpreted as an
> argument in favor of Python and against Aldor/Spad. So
> I think we need to find another more convincing example. :-)
>

We have been talking about Spad and Aldor versus Python
so I thought it might be interesting to see what Python
developers think about static typing. Here is a fairly recent
(December 23, 2004) and interesting post by Guido van
Rossum, the inventor of Python:

Adding Optional Static Typing to Python

http://www.artima.com/weblogs/viewpost.jsp?thread=85551

In part Guido writes:

What is Optional Static Typing?

The Python compiler doesn't know about the types of the objects you 
pass around
in a Python program; only the run-time (the Virtual Machine) does. This makes
Python expressive and flexible, but sometimes means that bugs of a rather
trivial kind (like typos in method names) are found later than the developer
would have liked. Without losing the benefits of Python's dynamic typing, it
would be nice if you had the option to add type declarations for your method
arguments, variables and so on, and then the compiler would give you a warning
if you did something that wasn't possible given what the compiler knows about
those types. While there are third-party program checkers that find a lot of
problems without type declarations, e.g. pychecker (
http://pychecker.sourceforge.net ), it would be nice if (a) this 
capability was
built into the Python compiler and (b) you could give it hints in cases where
its type inference broke down.

---------

There are also a lot of interesting comments from other people
about this article:

http://www.artima.com/forums/flat.jsp?forum=106&thread=85551

To me this article reads something like:"Python re-discovers
Spad 20 years later.". Of course there is more to it than that
but I still think a comparison between Axiom's Spad and Aldor
versus Python is a useful exercise.

\start
Date: Fri, 30 Mar 2007 06:58:25 +0200
From: Ralf Hemmecke
To: Gabriel Dos Reis
Subject: Re: Bug?

> | > we could classify this as a bug. :-)
> | 
> | So if SPAD cannot handle anonymous categories and is seems it cannot
> 
> It appears to me that you're confusing the Spad language and the
> language you can use at the interpreter level (i.e. in ".input"
> files).

Certainly not. I rather forgot to escape +, -, and * to _+, _-, _*. In 
Aldor that is not necessary. The special symbols +,-,*, 0, 1 can be used 
as identifiers. I hope that some day SPAD also treats them more 
naturally, i.e. without the need to escape them. And I also hope that 
something like

CardinalNumber: Join(OrderedSet, AbelianMonoid, Monoid,
                      RetractableTo NonNegativeInteger) with
     commutative "*"
        ++ a domain D has \spad{commutative("*")} if it has an operation
        ++ \spad{"*": (D,D) -> D} which is commutative.
     "-": (%,%) -> Union(%,"failed")
        ++ \spad{x - y} returns an element z such that \spad{z+y=x} or 
"failed"
     ...

where the escape mechanism is by double quotes will go away in the 
future, since it looks too string-like.

\start
Date: Fri, 30 Mar 2007 08:28:59 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: CAS for the masses
Cc: Gabriel Dos Reis

On 03/30/2007 06:01 AM, Bill Page wrote:
> Quoting Ralf Hemmecke:
> 
>> Bill Page wrote:
>>> On the other hand Python does directly support building classes
>>> at run time while domains and categories can only be defined at
>>> compile-time in Axiom.
>>
>> Could you elaborate on this (on the python and aldor side). Can you give
>> a small example what you think is possible in python that cannot be done
>> with aldor. At first glance I have my doubts that "domains can only be
>> defined at compile time in aldor". Already Aldor's ability to write
>> domain-constructing functions is a counter example. But you probably
>> meant something else.
>>
> 
> You are right that I did not state this properly. Of course we can
> evaluate expressions (including functions) that return domains
> and categories. What I was trying to say is that domains in Spad
> and Aldor are immutable during run-time.

I would agree in principle, but not in practice. Currently categories 
are immutable and that might be a good thing if one reads the article

http://portal.axiom-developer.org/refs/articles/define.pdf

For domains your statement is basically true. That is the reason why the 
compiler is allowed to create only one instance of Comple2(MyInteger) 
even if that piece of code appears several several times in your program.

But aldor/spad allows to modify the domain. Here some piece of code 
which even uses this in the Axiom algebra library:

IntegerCombinatoricFunctions(I:IntegerNumberSystem): with
    binomial: (I, I) -> I
       ++ \spad{binomial(n,r)} returns the binomial coefficient
       ++ \spad{C(n,r) = n!/(r! (n-r)!)}, where \spad{n >= r >= 0}.
       ++ This is the number of combinations of n objects taken r
       ++ at a time.
    [... left out some exports ...]
  == add
    [... left out some code ...]
    B : Record(Bn:I, Bm:I, Bv:I) := [0,0,0]
    [... left out some code ...]
    binomial(n, m) ==
       s,b:I
       n < 0 or m < 0 or m > n => 0
       m = 0 => 1
       n < 2*m => binomial(n, n-m)
       (s,b) := (0,1)
       if B.Bn = n then
          B.Bm = m+1 =>
             b := (B.Bv * (m+1)) quo (n-m)
             B.Bn := n
             B.Bm := m
             return(B.Bv := b)
          if m >= B.Bm then (s := B.Bm; b := B.Bv) else (s,b) := (0,1)
       for k in convert(s+1)@Z .. convert(m)@Z repeat
         b := (b*(n-k::I+1)) quo k::I
       B.Bn := n
       B.Bm := m
       B.Bv := b

You could argue that B is a local variable. But then define it with == 
to be a constant and export it. Since "B.Bn := n" is a destructive 
operation, one can also modify constants.

In Aldor-Combinat I even have to use this destructiveness in order to 
allow recursive definitions of combinatorial species a la

B == X + B*B

internally that first defines a (dummy) constant for the value of the 
exported symbol
   generatingFunction
of the domain B, and immediately (at instantiation time of B) fills it 
with appropriate data. So the code inside the + and * constructor looks like

generatingSeries: ExponentialGeneratingSeries == new();
set!(
      generatingSeries $ %,
      generatingSeries $ F(L) * generatingSeries $ G(L)
);

where F and G are equal to B for the above equation.

Again, since this set! function is destructive, I can apply it even 
later, after the creation of the domain B. In that sense I would at 
least modify an attribute of the domain.

However, you are right in the sense that what I just described is not 
the most common usage of a domain. And I would even argue, to avoid that 
option unless you have *very* good reason to use it. (I had, since 
otherwise recursion were impossible.

But anyway that brings me to yet another example.
Didn't we have a running example of Even and Odd?

This here only shows a problem.
http://wiki.axiom-developer.org/MutualRecursion
But it's rather a minor problem, I guess.

    >> System error:
    Cannot rename the file #p"EVEN.erlib" to #p"EVEN.NRLIB".

I have also found
http://wiki.axiom-developer.org/SandBoxAldorSemantics
but maybe that is a bit too much for a contact between Aldor and Python.

> Once constructed their "value" is constant and can not be changed.

Are my examples convincing, that this is not true in general.

 > For example we
> can not insert or remove anything in the list of exports or even
> replace one exported function with another during the execution
> of the program. This is possible in Python.

This is on the category level. And it is true.
I also agree that after a definition

foo(x: %): % == ... some code ...

in a domain and the instantiation of that domain, it is impossible to 
make that function to use other code. It might depend on some internal 
state, though, as binomial above, but the function foo always executes 
the same "... some code ...".

> Note: I am not talking about the post facto library extension feature
> in Aldor. 'extend' is a compile-time operation.

Then certainly 'extend' is possible in Python although not at compile-time.

> In Python on the other hand new classes can be created dynamically.
> See for example the method '__new__'  in

With a bit of work one can also achieve arbitrarily many instances of 
Complex2(Integer). I think one just has to wrap the creation by a function.

\start
Date: 30 Mar 2007 08:46:25 +0200
From: Martin Rubey
To: Ralf Hemmecke
Subject: Re: CAS for the masses
Cc: Gabriel Dos Reis

Ralf Hemmecke writes:

> In Aldor-Combinat I even have to use this destructiveness in order to allow
> recursive definitions of combinatorial species a la
> 
> B == X + B*B

In fact, we even create domains from a given string in axiom-combinat! Try

B ==> Interpret([parse "Plus(Self, Times(Self, Self))"], ACINT)

generatingSeries()$B

and keep in mind that "Plus(Self, Times(Self, Self))" is a String!

\start
Date: Fri, 30 Mar 2007 10:30:01 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: domains with parameters versus Python classes

On 03/30/2007 05:07 AM, Bill Page wrote:
> Ralf,
> 
> I have moved your example of a domain with parameters to a
> new page and added some explanatory text plus an new example
> in Python that does the same thing apparently without the
> complication of defining categories. See:
> 
> http://wiki.axiom-developer.org/SandBoxSPADForPython2
> 
> For Python developers this might be interpreted as an
> argument in favor of Python and against Aldor/Spad. So
> I think we need to find another more convincing example. :-)

Oh, I seem to learn python... ;-)

Obviously, having the compiler telling me errors just because the types 
do not match is not a big argument to Python programmers.

And since Python also allows reflection (cited from 
http://wiki.axiom-developer.org/SandBoxSPADForPython2):

   if '__cmp__' in dir(self.i):

it allows to do quite a lot of things. For example, a python class can 
certainly hold an axiom, like, for example, that the class denotes a 
(mathematical) field. So with similar statements one can certainly ask a 
class something like:

   if R has Field then ...

So a python class knows about its exports and thus can simulate a 
category. In Aldor the management of the category information is done 
automatically, I Python one would have to call a function if a class 
inherits from two or more other classes.

As far as I have understood Python up to now. I Python programmer even 
does not need 'information hiding'. A category basically does this, for 
example.

MyStupidInteger: with {
     0: %;
     +: (%, %) -> %;
     coerce: Integer -> %;
     coerce: % -> Integer;
} == Integer add {
     Rep == Integer;
     coerce(i: Integer): % == per i;
     coerce(x: %): Integer == rep i;
}

This domain basically behaves like Integer, but you cannot multiply 
elements since MyStupidInteger does *not* export a multiplication function.

Is this a good thing?

Yes it is. Take the constructor "SortedList" which takes an argument 
that must export an ordering function.

SortedList(T: PartiallyOrderedType): with {
     BoundedFiniteLinearStructureType T;
     DynamicDataStructureType T
} == add {
     ...
}

If you look up the actual functions that are exported, you won't find:

   cons: (T, %) -> %

because with that function you could destroy the properties that the 
elements of SortedList(Integer) are (ascendingly) ordered lists of integers.

So if I have SortedList(Integer) there is no way (except for being very 
nasty) to create an element which is *not* sorted.

But I guess, that is not a convincing argument to Python programmers.

\start
Date: Fri, 30 Mar 2007 05:00:00 -0400
From: Bill Page
To: Ralf Hemmecke
Subject: Re: CAS for the masses

Quoting Ralf Hemmecke:

> ...
> But aldor/spad allows to modify the domain. Here some piece of code
> which even uses this in the Axiom algebra library:
>
> IntegerCombinatoricFunctions(I:IntegerNumberSystem): with
>     binomial: (I, I) -> I
>     [... left out some exports ...]
>   == add
>     [... left out some code ...]
>     B : Record(Bn:I, Bm:I, Bv:I) := [0,0,0]
>     [... left out some code ...]
>     binomial(n, m) ==
>        s,b:I
>        n < 0 or m < 0 or m > n => 0
>        m = 0 => 1
>        n < 2*m => binomial(n, n-m)
>        (s,b) := (0,1)
>        if B.Bn = n then
>           B.Bm = m+1 =>
>              b := (B.Bv * (m+1)) quo (n-m)
>              B.Bn := n
>              B.Bm := m
>              return(B.Bv := b)
>           if m >= B.Bm then (s := B.Bm; b := B.Bv) else (s,b) := (0,1)
>        for k in convert(s+1)@Z .. convert(m)@Z repeat
>          b := (b*(n-k::I+1)) quo k::I
>        B.Bn := n
>        B.Bm := m
>        B.Bv := b
>

I don't understand your example. Why do you say that it "allows to
modify the domain"? As far as I can see in

http://wiki.axiom-developer.org/images/axiom--test--1/src/algebra/combinat.spad.pamphlet

IntegerCombinatoricFunctions is a package not a domain. But in
any case, all I see is that the binomial function has a side-effect of
modifying the variable B and in turn that what it actually does depends
on this stored value when it is called again.

> You could argue that B is a local variable.

Technically B is not a "local" variable but rather a variable of the
instance of this package. Because of these variables the instance
has a "state". Apparently it is used here to cache the return value
to make the computation more efficient.

> But then define it with == to be a constant and export it. Since
> "B.Bn := n" is a destructive operation, one can also modify constants.
>

I don't understand this statement. If I write B.Bn := n, then B is not
constant. This statement can be executed anytime during the
execution of the program. If I remember correctly the semantics of
  == on the other hand is that the value of the lhs is set just once at
the time the instance is created.

> In Aldor-Combinat I even have to use this destructiveness in order to
> allow recursive definitions of combinatorial species a la
>
> B == X + B*B
>
> internally that first defines a (dummy) constant for the value of the
> exported symbol
>    generatingFunction
> of the domain B, and immediately (at instantiation time of B) fills it
> with appropriate data. So the code inside the + and * constructor looks
> like
>
> generatingSeries: ExponentialGeneratingSeries == new();
> set!(
>       generatingSeries $ %,
>       generatingSeries $ F(L) * generatingSeries $ G(L)
> );
>
> where F and G are equal to B for the above equation.
>
> Again, since this set! function is destructive, I can apply it even
> later, after the creation of the domain B. In that sense I would at
> least modify an attribute of the domain.
>

I guess I understand what this code is doing. The key is to remember
that an == statement is executed exactly once during the initialization
phase of creating an instance but in other respects it is the same as an
assignment. I think somewhere in the Aldor Users Guide it also says
that the order in which the initializations are done is not defined so you
must be very careful with initializations that can have side-effects. But
in the end, after this initialization is done, the value of B does not
change, right?

Still, the fact that an instance of a domain or package or category
can have a state does not make the code different. Of course one
might carry this to an extreme such as having a domain that
implements a Lisp interpreter and an internal state that corresponds
to some Lisp sexpression that gets interpreted when some function
is installed. But in Aldor once the domain is compiled that actual
code of the domain that implements the Lisp interpreter is fixed
even though the function could return any result what so ever based
on it's internal state.

> However, you are right in the sense that what I just described is not
> the most common usage of a domain. And I would even argue, to
> avoid that option unless you have *very* good reason to use it. (I had,
> since otherwise recursion were impossible.
>
> But anyway that brings me to yet another example.
> Didn't we have a running example of Even and Odd?
>
> This here only shows a problem.
> http://wiki.axiom-developer.org/MutualRecursion
> But it's rather a minor problem, I guess.

Yes, this was due to the file rename problem in an earlier version
of Axiom. All that was needed was to click the 'refresh' button.
But I don't see this as an example of a sitation which allows to
modify the domain.

>
>     >> System error:
>     Cannot rename the file #p"EVEN.erlib" to #p"EVEN.NRLIB".
>
> I have also found
> http://wiki.axiom-developer.org/SandBoxAldorSemantics
> but maybe that is a bit too much for a contact between Aldor and Python.
>
>> Once constructed their "value" is constant and can not be changed.
>
> Are my examples convincing, that this is not true in general.
>

No not really. These functions are really the *same* in the sense that
they execute the same code (as you say below). But the situation is
complicated by the fact that these functions can depend on internal
state variables.

>  > For example we
>> can not insert or remove anything in the list of exports or even
>> replace one exported function with another during the execution
>> of the program. This is possible in Python.
>
> This is on the category level. And it is true.
> I also agree that after a definition
>
> foo(x: %): % == ... some code ...
>
> in a domain and the instantiation of that domain, it is impossible to
> make that function to use other code. It might depend on some internal
> state, though, as binomial above, but the function foo always executes
> the same "... some code ...".
>

Yes! That is exactly what I mean.

>> Note: I am not talking about the post facto library extension feature
>> in Aldor. 'extend' is a compile-time operation.
>
> Then certainly 'extend' is possible in Python although not at compile-time.
>

Yes.

>> In Python on the other hand new classes can be created dynamically.
>> See for example the method '__new__'  in
>
> With a bit of work one can also achieve arbitrarily many instances of
> Complex2(Integer). I think one just has to wrap the creation by a function.
>

Yes, but that is not what '__new__' does. It creates whatever class you
tell it to create at run-time. During the execution of the program you can
add new properties and methods to the class.

\start
Date: Fri, 30 Mar 2007 13:41:42 +0200
From: Ralf Hemmecke
To: Bill Page
Subject: Re: CAS for the masses

On 03/30/2007 11:00 AM, Bill Page wrote:
> Quoting Ralf Hemmecke:
> 
>> ...
>> But aldor/spad allows to modify the domain. Here some piece of code
>> which even uses this in the Axiom algebra library:
>>
>> IntegerCombinatoricFunctions(I:IntegerNumberSystem): with
>>     binomial: (I, I) -> I
>>     [... left out some exports ...]
>>   == add
>>     [... left out some code ...]
>>     B : Record(Bn:I, Bm:I, Bv:I) := [0,0,0]
>>     [... left out some code ...]
>>     binomial(n, m) ==
>>        s,b:I
>>        n < 0 or m < 0 or m > n => 0
>>        m = 0 => 1
>>        n < 2*m => binomial(n, n-m)
>>        (s,b) := (0,1)
>>        if B.Bn = n then
>>           B.Bm = m+1 =>
>>              b := (B.Bv * (m+1)) quo (n-m)
>>              B.Bn := n
>>              B.Bm := m
>>              return(B.Bv := b)
>>           if m >= B.Bm then (s := B.Bm; b := B.Bv) else (s,b) := (0,1)
>>        for k in convert(s+1)@Z .. convert(m)@Z repeat
>>          b := (b*(n-k::I+1)) quo k::I
>>        B.Bn := n
>>        B.Bm := m
>>        B.Bv := b
>>
> 
> I don't understand your example. Why do you say that it "allows to
> modify the domain"? As far as I can see in
> 
> http://wiki.axiom-developer.org/images/axiom--test--1/src/algebra/combinat.spad.pamphlet 
> 
> 
> IntegerCombinatoricFunctions is a package not a domain.

You certainly know that a package is nothing else than a domain that 
does not use %.

> But in
> any case, all I see is that the binomial function has a side-effect of
> modifying the variable B and in turn that what it actually does depends
> on this stored value when it is called again.

>> You could argue that B is a local variable.

> Technically B is not a "local" variable but rather a variable of the
> instance of this package.

So, it's a local variable for the

   add { ... }

one cannot see it outside unless you export it.

In fact, if you don't say

   local B: ...

then the anonymous add {...} domain exports B, but usually we restrict 
that through some category by naming the domain.

 > Because of these variables the instance
> has a "state". Apparently it is used here to cache the return value
> to make the computation more efficient.

Yep, in OO-term it's probably better called a state.

>> But then define it with == to be a constant and export it. Since
>> "B.Bn := n" is a destructive operation, one can also modify constants.
>>
> 
> I don't understand this statement. If I write B.Bn := n, then B is not
> constant. This statement can be executed anytime during the
> execution of the program. If I remember correctly the semantics of
>  == on the other hand is that the value of the lhs is set just once at
> the time the instance is created.

Right. But == does not forbid that you do nasty things with the lhs. And 
using a destructive operation like set! is "nasty" and thus can modify 
constants. Well in Aldor identifiers that are defined by via == are thus 
not really constants.

>> In Aldor-Combinat I even have to use this destructiveness in order to
>> allow recursive definitions of combinatorial species a la
>>
>> B == X + B*B
>>
>> internally that first defines a (dummy) constant for the value of the
>> exported symbol
>>    generatingFunction
>> of the domain B, and immediately (at instantiation time of B) fills it
>> with appropriate data. So the code inside the + and * constructor looks
>> like
>>
>> generatingSeries: ExponentialGeneratingSeries == new();
>> set!(
>>       generatingSeries $ %,
>>       generatingSeries $ F(L) * generatingSeries $ G(L)
>> );
>>
>> where F and G are equal to B for the above equation.
>>
>> Again, since this set! function is destructive, I can apply it even
>> later, after the creation of the domain B. In that sense I would at
>> least modify an attribute of the domain.
>>
> 
> I guess I understand what this code is doing. The key is to remember
> that an == statement is executed exactly once during the initialization
> phase of creating an instance but in other respects it is the same as an
> assignment. I think somewhere in the Aldor Users Guide it also says
> that the order in which the initializations are done is not defined so you
> must be very careful with initializations that can have side-effects. But
> in the end, after this initialization is done, the value of B does not
> change, right?

But see, generatingSeries is like the B that is used in binomial. It is 
nothing like an exported constand that has a Record structure 
underneath. I just modify something inside the Record. Of course the 
place of the record itself cannot be changed. generatingSeries is just a 
pointer to that record. I cannot change that pointer, but I can change 
the data that it points to.

Who would forbid me to use set! on generatingSeries again after the 
domain B (now from B == X + B*B) was instantiated. set! is destructive 
so the programmer should know what s/he is doing. It is dangerous in 
general, but used wisely, it sometimes helps, like in this series case.

> Still, the fact that an instance of a domain or package or category
> can have a state does not make the code different. Of course one
> might carry this to an extreme such as having a domain that
> implements a Lisp interpreter and an internal state that corresponds
> to some Lisp sexpression that gets interpreted when some function
> is installed. But in Aldor once the domain is compiled that actual
> code of the domain that implements the Lisp interpreter is fixed
> even though the function could return any result what so ever based
> on it's internal state.

I already agreed on that one.

>> However, you are right in the sense that what I just described is not
>> the most common usage of a domain. And I would even argue, to
>> avoid that option unless you have *very* good reason to use it. (I had,
>> since otherwise recursion were impossible.

>> But anyway that brings me to yet another example.
>> Didn't we have a running example of Even and Odd?

>> This here only shows a problem.
>> http://wiki.axiom-developer.org/MutualRecursion
>> But it's rather a minor problem, I guess.
> 
> Yes, this was due to the file rename problem in an earlier version
> of Axiom. All that was needed was to click the 'refresh' button.
> But I don't see this as an example of a sitation which allows to
> modify the domain.

No, but is that possible in Python?

>>> In Python on the other hand new classes can be created dynamically.
>>> See for example the method '__new__'  in
>>
>> With a bit of work one can also achieve arbitrarily many instances of
>> Complex2(Integer). I think one just has to wrap the creation by a 
>> function.

> Yes, but that is not what '__new__' does. It creates whatever class you
> tell it to create at run-time. During the execution of the program you can
> add new properties and methods to the class.

Right, modifying a domain by adding or removing functions from it is not 
possible in Aldor. Is this good or bad or just different?

\start
Date: Fri, 30 Mar 2007 13:00:54 +0200 (CEST)
From: Waldek Hebisch
To: Bill Page
Subject: Re: CAS for the masses
Cc: Gabriel Dos Reis

Bill Page wrote:
> You are right that I did not state this properly. Of course we can
> evaluate expressions (including functions) that return domains
> and categories. What I was trying to say is that domains in Spad
> and Aldor are immutable during run-time. Once constructed their
> "value" is constant and can not be changed. For example we
> can not insert or remove anything in the list of exports or even
> replace one exported function with another during the execution
> of the program. This is possible in Python.
> 
> Note: I am not talking about the post facto library extension feature
> in Aldor. 'extend' is a compile-time operation.
>

I want comment about Alder, but in current Axiom runtime domains are
mutable.  In fact I think that ability to redefine domain at runtime
was an important design goal (otherwise a sigificant part of Axiom
runtime activities would be useless).

I think that biggest problem in impementing 'extend' is to provide
sane behaviour during redefinition.

\start
Date: Fri, 30 Mar 2007 11:17:02 +0000
From: Ondrej Certik
To: Bill Page
Subject: Re: domains with parameters versus Python classes
Cc: Gabriel Dos Reis

> But the point of this exercise for me is still to present Spad
> for Python programmers - not really an argument for or against
> one or the other. Presenting it this way as a challenge seems
> like a way of motivating more interest in this subject. I think this
> is important for some of the same reasons that people currently
> doing computer algebra and symbolic computation in Python
> (e.g. SymPy and Sage) think it is important: because there are
> a *lot* of people who know or are learning to program in Python
> while there is a much much smaller number of people who have
> or are developing the skills to program in Axiom. If Axiom (and
> Aldor) has a future, I think we have to find some way to interest
> even a small share of that talent.

I agree with this completely. And I think it is influencing to Aldor
users as well, to know, that Aldor is not the only possible way of
doing things and that many of the functionalities of Aldor they
thought are unique to it, can actually be done in for example Python
quite easily as well.

Of course, those comparisons of languages are always kind of a flame
war (try to find Python vs Ruby in google for example). I know Python,
but as I understand you can do almost all things in Ruby as well and
vice versa. As to Python vs Aldor, it's just my personal opinion, I
think the differences are also small in a sense, that what can be done
in Aldor could be done in Python (maybe using a different way of
programming, unusual for Aldor developers) and vice versa. But if you
find an example, that shows that really Aldor can do things better, I
am interested in that.

But if you don't, then (again just my opinion), I think it's not wise
to use a language that almost noone uses. The question really stands:
do some features of Aldor really make it worthy enough to use it
instead of some other language, that is used by 1000 (or maybe even
10000) times more people?

Please, don't take my questions as a provocation, I am just interested
in pure discussion, I just want to know all reasons why you chose
Aldor, as I think it's not wise and you also think that Python is not
wise (otherwise you would already used it), thus I want to understand
and point out each other's arguments.

\start
Date: Fri, 30 Mar 2007 07:20:47 -0400
From: Bill Page
To: Waldek Hebisch
Subject: Re: CAS for the masses
Cc: Gabriel Dos Reis

Quoting Waldek Hebisch:

> Bill Page wrote:
>> You are right that I did not state this properly. Of course we can
>> evaluate expressions (including functions) that return domains
>> and categories. What I was trying to say is that domains in Spad
>> and Aldor are immutable during run-time. Once constructed their
>> "value" is constant and can not be changed. For example we
>> can not insert or remove anything in the list of exports or even
>> replace one exported function with another during the execution
>> of the program. This is possible in Python.
>>
>> Note: I am not talking about the post facto library extension feature
>> in Aldor. 'extend' is a compile-time operation.
>>
>
> I want comment about Alder, but in current Axiom runtime domains are
> mutable.  In fact I think that ability to redefine domain at runtime
> was an important design goal (otherwise a sigificant part of Axiom
> runtime activities would be useless).
>

Could you give an example of how to modify a domain during the exectuion
of a Spad program? Is is possible without calling low-level Lisp functions?

> I think that biggest problem in impementing 'extend' is to provide
> sane behaviour during redefinition.
>

I thought Aldor 'extend' only produced new loadable object code during
compilation. Is that wrong?

\start
Date: 30 Mar 2007 08:33:48 -0500
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: Bug?

Ralf Hemmecke writes:

| > | > we could classify this as a bug. :-)
| > | | So if SPAD cannot handle anonymous categories and is seems it
| > cannot
| > It appears to me that you're confusing the Spad language and the
| > language you can use at the interpreter level (i.e. in ".input"
| > files).
| 
| Certainly not.

Well, you wanted the interpreter to swallow something that can be used
only in the compiler.  And if you were aware that they were different
languages, what did you expect?

\start
Date: 30 Mar 2007 08:35:16 -0500
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: domains with parameters versus Python classes

Bill Page writes:

[...]

| There are also a lot of interesting comments from other people
| about this article:
| 
| http://www.artima.com/forums/flat.jsp?forum=106&thread=85551
| 
| To me this article reads something like:"Python re-discovers
| Spad 20 years later.".

I believe Guido was aware of Scratchpad.

\start
Date: 30 Mar 2007 08:40:02 -0500
From: Gabriel Dos Reis
To: Ralf Hemmecke
Subject: Re: CAS for the masses

Ralf Hemmecke writes:

| You certainly know that a package is nothing else than a domain that
| does not use %.

Yes, and it is important that Rep does not change at whim.

\start
Date: 30 Mar 2007 08:44:27 -0500
From: Gabriel Dos Reis
To: Ondrej Certik
Subject: Re: domains with parameters versus Python classes

Ondrej Certik writes:

| > But the point of this exercise for me is still to present Spad
| > for Python programmers - not really an argument for or against
| > one or the other. Presenting it this way as a challenge seems
| > like a way of motivating more interest in this subject. I think this
| > is important for some of the same reasons that people currently
| > doing computer algebra and symbolic computation in Python
| > (e.g. SymPy and Sage) think it is important: because there are
| > a *lot* of people who know or are learning to program in Python
| > while there is a much much smaller number of people who have
| > or are developing the skills to program in Axiom. If Axiom (and
| > Aldor) has a future, I think we have to find some way to interest
| > even a small share of that talent.
| 
| I agree with this completely. And I think it is influencing to Aldor
| users as well, to know, that Aldor is not the only possible way of
| doing things and that many of the functionalities of Aldor they
| thought are unique to it, can actually be done in for example Python
| quite easily as well.

Very few poeple think that many functionalities in Aldor are unique to
Aldor. 

[...]

| Please, don't take my questions as a provocation, I am just interested
| in pure discussion, I just want to know all reasons why you chose
| Aldor, as I think it's not wise and you also think that Python is not
| wise (otherwise you would already used it), thus I want to understand
| and point out each other's arguments.

Aldor is the continuation of the Scratchpad library extension language.
Scratchpad is a project started beginning of seventies, long before
Python was dreamt of.  And Python was influced by Scratchpad.


Anyway, I find the idea of luring Python developers into Axiom by
showing them how you can write Spad/Aldor programs in Python and vice
versa very, let say, curious.

\start
Date: 30 Mar 2007 09:20:21 -0500
From: Gabriel Dos Reis
To: Gregory Vanuxem
Subject: Re: depsys and SBCL

Gregory Vanuxem writes:

[...]

| > This is just a head up.  If you know anything about the illegal
| > character \#Stx, please let me know.
| 
| No idea.

I believe I nailed down where the error is coming from.

Have a loot at line 368 in src/interp/def.lisp.pamphlet.  There are two
uses of character Conotrol-B there (at least that is what Emacs shows
me).  I'm curious about what could have been intended.  Tim?

\start
Date: Fri, 30 Mar 2007 11:19:59 -0400
From: Bill Page
To: Gabriel Dos Reis
Subject: Re: domains with parameters versus Python classes

Quoting Gabriel Dos Reis:

> ...
> Anyway, I find the idea of luring Python developers into Axiom by
> showing them how you can write Spad/Aldor programs in Python
> and vice versa very, let say, curious.
>

I suppose by "very, let say, curious" you mean something like
"crazy", "silly", "doubtful", "waste of time", etc. ?

I am not sure why you should feel this way. Do you think that
there is no hope that proponents of Python will ever find any
advantage in static typing? Certainly programming in Python
seems (at least initially) much easier and faster than in Aldor
because there is no need to specify types.Specifying correct
types requires extra discipline and analysis at the start of
a project. Similarly, ignoring types until run-time testing can
(in principle) lead to requiring more time in testing and
debugging in the last stage of a project. There was a lot of
discussion of this by Python users a few years ago and some
from of static typing is apparently scheduled to be part of
Python 3.

As Axiom users we have an additional reason to be concerned
with types upfront that has to do with mathematical rigour.
Not only do we want the program to be correct but we also
want it to accurately reflect or represent the formal structure
of the matematical objects that we are manipulating.

On the other hand, showing Axiom programmers that in
some ways Spad and Aldor are not so ancient and unique
might also be a good thing.

Could you elaborate on why you say it is "very, let say,
curious"?

\start
Date: 30 Mar 2007 10:49:11 -0500
From: Gabriel Dos Reis
To: Bill Page
Subject: Re: domains with parameters versus Python classes

Bill Page writes:

| Quoting Gabriel Dos Reis:
| 
| > ...
| > Anyway, I find the idea of luring Python developers into Axiom by
| > showing them how you can write Spad/Aldor programs in Python
| > and vice versa very, let say, curious.
| >
| 
| I suppose by "very, let say, curious" you mean something like
| "crazy", "silly", "doubtful", "waste of time", etc. ?

"waste of time" and "doubtful".

| I am not sure why you should feel this way. Do you think that
| there is no hope that proponents of Python will ever find any
| advantage in static typing?

First I don't think you're going to gain much in entering the debate
"static typing" when you go to the scripting language community.
There are reasons why scripting languages are so popular.

Second, I don't believe in intrinsic merits of programming languages.
I believe in their effectiveness at letting people *solve problems*, 
express their ideas in natural ways, programming techniques and scalability.


Showing how non-trivial problems are simply and elegantly solved by
given tools is much more convincing and productive than showing
transliteration of a program in different languages.  What is going
to attract people to Axiom is its effectiveness at solving non-trivial
programs, and how the techniques used scale.


| Certainly programming in Python
| seems (at least initially) much easier and faster than in Aldor
| because there is no need to specify types.  

And in many cases, that is just sufficient to solve the problem at hand.

| Specifying correct
| types requires extra discipline and analysis at the start of
| a project.

Yes, but if the problem to be solved does not require scalable
techniques, why bother with extra straight jackets?

|  Similarly, ignoring types until run-time testing can
| (in principle) lead to requiring more time in testing and
| debugging in the last stage of a project. 

Yes, but using types is not a guarantee of absence of bugs.

| There was a lot of
| discussion of this by Python users a few years ago and some
| from of static typing is apparently scheduled to be part of
| Python 3.

I'm very well aware of those discussions, not only in the Python
community, but also in various other scripting language communities. 

| As Axiom users we have an additional reason to be concerned
| with types upfront that has to do with mathematical rigour.

Mostly because we have to come up with techniques that *scale*, and we
are attacking *non-trivial problems at very abstract level*.
Consequently, we need to pin point our thinking.  Types just happen
to be very useful tools for that.  Note that, that in itself does not
mean we must use explicit typing -- we may very well rely on
sufficiently advanced type inference mechanisms -- but yes, explicit
type annotations do make life easier.

| Not only do we want the program to be correct but we also
| want it to accurately reflect or represent the formal structure
| of the matematical objects that we are manipulating.

Note that it is possible to write correct programs without explicit
type annotation.  The issue relates to scale, difficulty, and
generality of the problems and solutions.

| On the other hand, showing Axiom programmers that in
| some ways Spad and Aldor are not so ancient and unique
| might also be a good thing.

I don't understand why that is an important factor.  There are very
few programming languages that have invented anything new in the last
decade or so.  The majority of them just copy over from existing languages
and add some improvements.  The idea that Axiom and Spad
programmers should feel like their language is ancient or unique
suggests that there is a problem with Axiom and Spad users who might
be leaving in a black hole, but I don't believe the solution to that
problem is what I've seen in this thread.

\start
Date: Fri, 30 Mar 2007 17:59:59 +0200 (CEST)
From: Waldek Hebisch
To: Bill Page
Subject: Re: CAS for the masses
Cc: Gabriel Dos Reis

Bill Page wrote:
> Quoting Waldek Hebisch:
> 
> > Bill Page wrote:
> >> You are right that I did not state this properly. Of course we can
> >> evaluate expressions (including functions) that return domains
> >> and categories. What I was trying to say is that domains in Spad
> >> and Aldor are immutable during run-time. Once constructed their
> >> "value" is constant and can not be changed. For example we
> >> can not insert or remove anything in the list of exports or even
> >> replace one exported function with another during the execution
> >> of the program. This is possible in Python.
> >>
> >> Note: I am not talking about the post facto library extension feature
> >> in Aldor. 'extend' is a compile-time operation.
> >>
> >
> > I want comment about Alder, but in current Axiom runtime domains are
> > mutable.  In fact I think that ability to redefine domain at runtime
> > was an important design goal (otherwise a sigificant part of Axiom
> > runtime activities would be useless).
> >
> 
> Could you give an example of how to modify a domain during the exectuion
> of a Spad program? Is is possible without calling low-level Lisp functions?
> 

1) via system commands
2) via Lisp

I am not aware of any Spad level support for runtime modification of
domains.  OTOH it is hard to do _anything_ in pure Spad without using
Lisp domain (note that Axiom library implements most of its primitive
operations via Lisp, so pure Spad in practice implies using no
of Axiom library ).

> > I think that biggest problem in impementing 'extend' is to provide
> > sane behaviour during redefinition.
> >
> 
> I thought Aldor 'extend' only produced new loadable object code during
> compilation. Is that wrong?
> 

AFAIK this is correct.  Axiom can call compiler at runtime.  And I belive
that it the intended mode of development for Axiom is to re-compile
changed files and then load them into to same Axiom image.  Such
style of developement has serious problems due to static typing
but Axiom runtime apparently supports it.

BTW: My comment is specifically about Axiom, I do not know if Aldor
is different here.

\start
Date: 30 Mar 2007 11:17:52 -0500
From: Gabriel Dos Reis
To: Waldek Hebisch
Subject: Re: CAS for the masses

Waldek Hebisch writes:

[...]

| I am not aware of any Spad level support for runtime modification of
| domains.  OTOH it is hard to do _anything_ in pure Spad without using
| Lisp domain (note that Axiom library implements most of its primitive
| operations via Lisp, so pure Spad in practice implies using no
| of Axiom library ).

I would like to see the use of the Lisp domain significantly reduced.

Think of Lisp as the assembly language for the Axiom abstract machine;
we would like the direct use of assembly instructions reduced the bare
minimum.  We should augment Spad with constructs that we think are
missing. 

\start
Date: Fri, 30 Mar 2007 12:52:11 -0400
From: Alfredo Portes
To: Gabriel Dos Reis
Subject: Re: domains with parameters versus Python classes

On 30 Mar 2007 10:49:11 -0500, Gabriel Dos Reis wrote:
> Bill Page writes:
>
> | Quoting Gabriel Dos Reis:
> |
> | > ...
> | > Anyway, I find the idea of luring Python developers into Axiom by
> | > showing them how you can write Spad/Aldor programs in Python
> | > and vice versa very, let say, curious.
> | >
> |
> | I suppose by "very, let say, curious" you mean something like
> | "crazy", "silly", "doubtful", "waste of time", etc. ?
>
> "waste of time" and "doubtful".

Funny enough, the python webpage used to have something similar to show
the similarities with Lisp :-).

\start
Date: Fri, 30 Mar 2007 19:03:15 +0200
From: Ondrej Certik
To: Gabriel Dos Reis
Subject: Re: domains with parameters versus Python classes

> | Not only do we want the program to be correct but we also
> | want it to accurately reflect or represent the formal structure
> | of the matematical objects that we are manipulating.
>
> Note that it is possible to write correct programs without explicit
> type annotation.  The issue relates to scale, difficulty, and
> generality of the problems and solutions.

I agree.

> I don't understand why that is an important factor.  There are very
> few programming languages that have invented anything new in the last
> decade or so.  The majority of them just copy over from existing languages
> and add some improvements.  The idea that Axiom and Spad
> programmers should feel like their language is ancient or unique
> suggests that there is a problem with Axiom and Spad users who might
> be leaving in a black hole, but I don't believe the solution to that
> problem is what I've seen in this thread.

I agree witht the arguments that you presented. Especially with "There are very
few programming languages that have invented anything new in the last
decade or so". But now comes the point, which seems natural to me, but
where we disagree - why don't we then just use a language which is the
most popular? (It doesn't have to be Python, it can be Ruby, or any
other, but I think Python is the most popular).

\start
Date: Fri, 30 Mar 2007 13:21:21 -0400
From: Bill Page
To: Alfredo Portes
Subject: Re: domains with parameters versus Python classes
Cc: Gabriel Dos Reis

Quoting Alfredo Portes:

> On 30 Mar 2007 10:49:11 -0500, Gabriel Dos Reis wrote:
>> | > Anyway, I find the idea of luring Python developers into Axiom by
>> | > showing them how you can write Spad/Aldor programs in Python
>> | > and vice versa very, let say, curious.
>> ...
>> "waste of time" and "doubtful".
>
> Funny enough, the python webpage used to have something similar to show
> the similarities with Lisp :-).
>

I think it was this article. I believe I have referred to it before on this
list.

http://norvig.com/python-lisp.html

Python for Lisp Programmers
by Peter Norvig

This is a brief introduction to Python for Lisp programmers. (Although 
it wasn't
my intent, Python programers have told me this page has helped them 
learn Lisp.)
Basically, Python can be seen as a dialect of Lisp with "traditional" syntax
(what Lisp people call "infix" or "m-lisp" syntax). One message on
comp.lang.python said "I never understood why LISP was a good idea until I
started playing with python." Python supports all of Lisp's essential features
except macros, and you don't miss macros all that much because it does have
eval, and operator overloading, and regular expression parsing, so you can
create custom languages that way.

-------

I think this article has two lessons for us. First: the removal of
the link to this article from www.python.org probably reflects
the reality that an association with Lisp is no longer of much
relevance to Python programmers. I hope for a similar evolution
of Axiom.

Second: it adds some credibility to the idea that an introduction
to SPAD for Python programmers might be beneficial for both
Axiom and Python developers.

\start
Date: Fri, 30 Mar 2007 11:39:41 -0600
From: Tim Daly
To: Ondrej Certik
Subject: python vs lisp

Python has one major flaw, suffered by all of the lisp-with-parens
languages. Lisp can read, manipulate, and write lisp programs as
data structures in a trivial, natural way. No parser is required.
The program-data equivalence is a non-trivial difference.

This is widely used within Axiom and in a fundamental way.
This would require major design rewrites to accomplish in Python.
Given that they are turing equivalent it is not a theoretical problem.

But Axiom rewrites expressions, rewrites them again, turns them into
functions, unparses them, reads and writes them to files, and generally 
slices and dices the code in many structural ways. You COULD do this 
in Python but you'd get a factor of 10 expansion because you'd
need parsers and compilers for the various intermediate mini-languages.

\start
Date: Fri, 30 Mar 2007 11:59:30 -0600
From: Tim Daly
To: Ondrej Certik
Subject: static vs dynamic typing

I don't believe that the issue is types at all, neither static
nor dynamic types. After all, lisp is dynamically typed and spad
lives on top of it (static types). The issue is the choice of types
and their possible interactions.

I believe that Axiom is mildly unique in the CAS world because
the type (category, domain) hierarchy attempts to mirror the
mathematical structures. I believe that this gives Axiom a
pre-existing design scaffold which should allow it to grow in
linear complexity as it grows linearly in size.

Designs (or lack thereof) that do not mirror the mathematical
hierarchy have nonlinear interactions that eventually limit
their size and complexity. Maple and MMA programs tend to suffer
this kind of pain when they start mixing user packages.

That's not to say that Axiom gets it right, but at least it tries.

\start
Date: Fri, 30 Mar 2007 12:00:40 -0600
From: Tim Daly
To: Ondrej Certik
Subject: life and death

For a few years I maintained a CD collection called Rosetta. 
I collected every computer algebra system I could find and the
list numbered over 100. Most of them (over 80%) were started by
people who unified the idea of language typing and the idea of
operator overloading to get a CAS. Most of them were in C++.
Almost all of them stopped after implementing some form of
polymorphic polynomials. Almost all of them cannot handle
issues of non-commutative arithmetic. All of them die when
the author moves on to something else.

The Rosetta project shows that there are hundreds of man-years
wasted making new systems (each project being about 2 semesters
long). If the same effort was put into a single Axiom domain
it would live longer, be generally more useful, and if properly
documented it could even be maintained.

I find it frustrating to watch yet-another-CAS being born.
There are 30 years and hundreds of man-years invested in a
system the size of Axiom. No single person, and likely no single
group, is going to get the long-term, expensive support to do
this again from scratch. There are no funding visionaries left.

So the issue isn't really python-vs-spad. The issue is whether
you care to spend your time writing code that will die or code
that will live.

\start
Date: Fri, 30 Mar 2007 13:02:06 -0500
From: Gabriel Dos Reis
To: Ondrej Certik
Subject: Re: domains with parameters versus Python classes

Quoting Ondrej Certik:

> I agree witht the arguments that you presented. Especially with 
> "There are very
> few programming languages that have invented anything new in the last
> decade or so". But now comes the point, which seems natural to me, but
> where we disagree - why don't we then just use a language which is the
> most popular? (It doesn't have to be Python, it can be Ruby, or any
> other, but I think Python is the most popular).

I'm sure the question is well-posed.

How dos popularity relates to effectiveness at solving programs?


By the way, how do you measure popularity?  By numbers published a
couple of years ago, there would be about 9 millions programmers
on the planet, out of which 3 millions are claimed to be C++
programmers.

\start
Date: Fri, 30 Mar 2007 21:30:46 +0200
From: Ondrej Certik
To: Gabriel Dos Reis
Subject: Re: domains with parameters versus Python classes

> > I agree witht the arguments that you presented. Especially with
> > "There are very
> > few programming languages that have invented anything new in the last
> > decade or so". But now comes the point, which seems natural to me, but
> > where we disagree - why don't we then just use a language which is the
> > most popular? (It doesn't have to be Python, it can be Ruby, or any
> > other, but I think Python is the most popular).
>
> I'm sure the question is well-posed.
>
> How dos popularity relates to effectiveness at solving programs?

First, this question is under the assumption, that "There are very
few programming languages that have invented anything new in the last
decade or so" and second - the popular language has a well tested
compilers/interpreters, that is a huge plus. So it is effective, as
you can ask many people.

> By the way, how do you measure popularity?  By numbers published a
> couple of years ago, there would be about 9 millions programmers
> on the planet, out of which 3 millions are claimed to be C++
> programmers.

Right, C/C++ is probably the most popular. But it's quite low level,
we are interested in something higher level, thus we need to look
among Python, Ruby, C#, Aldor etc. You can measure the popularity by
anything of these: number of endusers, number of developers, number of
compilers/interpreters, number of jobs offerings (demaning a knowledge
of the particular language),......

\start
Date: Fri, 30 Mar 2007 21:41:58 +0200
From: Ondrej Certik
To: Tim Daly
Subject: Re: life and death

> I find it frustrating to watch yet-another-CAS being born.
> There are 30 years and hundreds of man-years invested in a
> system the size of Axiom. No single person, and likely no single
> group, is going to get the long-term, expensive support to do
> this again from scratch. There are no funding visionaries left.
>
> So the issue isn't really python-vs-spad. The issue is whether
> you care to spend your time writing code that will die or code
> that will live.

I care to spend my time working on something, that I can actually use
to help me do what I wanted, in my case I wanted to play with the
differential geometry and stuff in quantum field theory. And also I
wanted to have something very simple to understand and callable from a
popular high level language.

I cannot use Axiom as I would spent more time creating a python
bindings than writing everything from scratch. And also, as I wrote in
some other email, I spent most of the time not reinventing something,
that you already wrote, but by designing the interface, and the
interface is completely different from Axiom. I thought that the
difficult part is to make everything work, but that is not true, the
difficult part is to think, how the interface should look like.

I am already repeating myself, so I think I already said all my
opinions on this issue, but I really think that what is needed is a
CAS that could be used as a library in some major language. And I fear
that Axiom couldn't easily be used this way.

\start
Date: Fri, 30 Mar 2007 14:44:31 -0500
From: Gabriel Dos Reis
To: Ondrej Certik
Subject: Re: domains with parameters versus Python classes

Quoting Ondrej Certik:

>> By the way, how do you measure popularity?  By numbers published a
>> couple of years ago, there would be about 9 millions programmers
>> on the planet, out of which 3 millions are claimed to be C++
>> programmers.
>
> Right, C/C++ is probably the most popular. But it's quite low level,
> we are interested in something higher level, thus we need to look
> among Python, Ruby, C#, Aldor etc. You can measure the popularity by
> anything of these: number of endusers, number of developers, number of
> compilers/interpreters, number of jobs offerings (demaning a knowledge
> of the particular language),......

I'm sorry to say but in my experience, I don't see Python, Ruby, C#
being higher level than C++.  The thing that distinguishes Aldor
from C++ is dependent types.  Apart from that, I don't see much difference
that would make me qualify Aldor as higher level than C++.

Notice that I'm specifically talking of C++, not an imaginary C/C++.

\start
Date: Fri, 30 Mar 2007 21:50:10 +0200
From: Ondrej Certik
To: Gabriel Dos Reis
Subject: Re: domains with parameters versus Python classes

> I'm sorry to say but in my experience, I don't see Python, Ruby, C#
> being higher level than C++.  The thing that distinguishes Aldor
> from C++ is dependent types.  Apart from that, I don't see much difference
> that would make me qualify Aldor as higher level than C++.
>
> Notice that I'm specifically talking of C++, not an imaginary C/C++.

Well, at least Python and Ruby are much higher level than C++ (there
are lists, dictionaries, garbage collector, no pointers, it's dynamic,
etc.). And also many times slower.

\start
Date: Fri, 30 Mar 2007 16:00:00 -0400
From: Bill Page
To: Tim Daly
Subject: Re: python vs lisp
Cc: Ondrej Certik

Quoting Tim Daly:

> Python has one major flaw, suffered by all of the lisp-with-parens
> languages. Lisp can read, manipulate, and write lisp programs as
> data structures in a trivial, natural way. No parser is required.
> The program-data equivalence is a non-trivial difference.
>
> This is widely used within Axiom and in a fundamental way.
> This would require major design rewrites to accomplish in Python.
> Given that they are turing equivalent it is not a theoretical problem.
>

Actually as Peter Norvig's article points out, Python is really very
similar to Lisp in this respect. Python has

   eval(repr(x)) = x

for (most) objects.

Each class defines a __repr__ method which is supposed to provide an
evalable string representation of instances of the class. This is similar
to Axiom's InputForm domain where we also have

    interpret(x::InputForm) = x

for (most) domains.

> But Axiom rewrites expressions, rewrites them again, turns them into
> functions, unparses them, reads and writes them to files, and generally
> slices and dices the code in many structural ways. You COULD do this
> in Python but you'd get a factor of 10 expansion because you'd
> need parsers and compilers for the various intermediate mini-languages.
>

Python provides built-in tools for object serialization such as pickle and
unpickle:

  http://docs.python.org/lib/module-pickle.html

Pickeling and unpickeling quite efficient. It is used for example in the
Zope database that we use for the Axiom wiki website.

\start
Date: Fri, 30 Mar 2007 14:14:55 -0600
From: Tim Daly
To: Ondrej Certik
Subject: SymPy code

Is your python algebra code available?
It might be an interesting exercise to rewrite it into spad
and see a head-to-head comparison. And, as a major side-effect,
increase the range of Axiom

\start
Date: 30 Mar 2007 15:14:24 -0500
From: Gabriel Dos Reis
To: Tim Daly
Subject: Re: static vs dynamic typing
Cc: Ondrej Certik

Tim Daly writes:

| I don't believe that the issue is types at all, neither static
| nor dynamic types. After all, lisp is dynamically typed and spad
| lives on top of it (static types). The issue is the choice of types
| and their possible interactions.

Yes, the fundamental issue is that of scale.

\start
Date: 30 Mar 2007 15:17:36 -0500
From: Gabriel Dos Reis
To: Ondrej Certik
Subject: Re: life and death

Ondrej Certik writes:

[...]

| I am already repeating myself, so I think I already said all my
| opinions on this issue, but I really think that what is needed is a
| CAS that could be used as a library in some major language. And I fear
| that Axiom couldn't easily be used this way.

Axiom can and should be made interoperating with languages like C++ or
Lisp,  which is a good starting gate to other galaxies.

\start
Date: Fri, 30 Mar 2007 13:22:02 -0700 (PDT)
From: Cliff Yapp
To: Tim Daly, Ondrej Certik
Subject: Re: SymPy code

Is this it?

http://code.google.com/p/sympy/

--- Tim Daly wrote:

> Is your python algebra code available?
> It might be an interesting exercise to rewrite it into spad
> and see a head-to-head comparison. And, as a major side-effect,
> increase the range of Axiom

\start
Date: 30 Mar 2007 15:24:13 -0500
From: Gabriel Dos Reis
To: Ondrej Certik
Subject: Re: domains with parameters versus Python classes

Ondrej Certik writes:

| > I'm sorry to say but in my experience, I don't see Python, Ruby, C#
| > being higher level than C++.  The thing that distinguishes Aldor
| > from C++ is dependent types.  Apart from that, I don't see much difference
| > that would make me qualify Aldor as higher level than C++.
| >
| > Notice that I'm specifically talking of C++, not an imaginary C/C++.
| 
| Well, at least Python and Ruby are much higher level than C++ (there
| are lists, dictionaries, garbage collector, no pointers, it's dynamic,
| etc.). And also many times slower.

I don't know which C++ you're talking about, but the one that I use on
daily basis and work on has lists (std::list), dictionaries (std::map, 
std::multimap, etc.), has many garbage collectors as libraries with 
a popular one freely available from Hans Boehm's web site -- industrial
strengh.  You don't have to use pointers in C++ if you don't need to.
Many  languages claim they don't have pointers, but represent
everything as pointers.  You can have everything dynamic in C++ if
that really is hat you want.  And, by the way it has a library for
easly interfacing with Python -- check out Boost.Python from Boost.

Let's our ignorance not interfer with reality.

\start
Date: Fri, 30 Mar 2007 23:01:17 +0200 (CEST)
From: Waldek Hebisch
To: Tim Daly
Subject: Re: SymPy code

> Is your python algebra code available?
> It might be an interesting exercise to rewrite it into spad
> and see a head-to-head comparison. And, as a major side-effect,
> increase the range of Axiom
> 

AFAICS the only part of SymPy which is not implemented in Axiom
is Gruntz algorithm for limits.  After quick look at limits.py
I think that it would be not hard to add similar code to Axiom.
However it looks that SymPy code ignores many real-life issues:
1) algebraic expressions
2) special functions
3) parameters

Especially determining sign in presence of parameters is troublesome
(undecidable).

\start
Date: Sat, 31 Mar 2007 00:26:30 +0200
From: Ondrej Certik
To: Gabriel Dos Reis
Subject: Re: domains with parameters versus Python classes

> I don't know which C++ you're talking about, but the one that I use on
> daily basis and work on has lists (std::list), dictionaries (std::map,
> std::multimap, etc.), has many garbage collectors as libraries with
> a popular one freely available from Hans Boehm's web site -- industrial
> strengh.  You don't have to use pointers in C++ if you don't need to.
> Many  languages claim they don't have pointers, but represent
> everything as pointers.  You can have everything dynamic in C++ if
> that really is hat you want.  And, by the way it has a library for
> easly interfacing with Python -- check out Boost.Python from Boost.
>
> Let's our ignorance not interfer with reality.

I also use C++ frequently, Boot.Python is very, very slow to compile,
better is to use SWIG. Hans Boehm garbage collector is of course a
nice thing, but the STL lists, map and stuff is very cumbersome to use
compared to python. Compare for example GiNaC and SymPy's
implementation of the same algorithms - SymPy is like 1/2 (or even
more) smaller, because C++ is very, very verbose.

Of course you can program in OO way in C as well, because programming
is just one, no matter which language you use, but Python is much
higher level than C++, I think noone really doubts about it.

\start
Date: Sat, 31 Mar 2007 00:31:24 +0200
From: Ondrej Certik
To: Waldek Hebisch
Subject: Re: SymPy code

Yes, SymPy is here:

http://code.google.com/p/sympy/

and the only think it can do now better than axiom is limits. Yes, it
ignores many special cases, but on the other hand it does work for the
most common cases, like power simplifications and simple limits (all
in Demidovich that I tried, for example).

What do you mean by algebraic expressions?

Ondrej

On 3/30/07, Waldek Hebisch wrote:
> > Is your python algebra code available?
> > It might be an interesting exercise to rewrite it into spad
> > and see a head-to-head comparison. And, as a major side-effect,
> > increase the range of Axiom
> >
>
> AFAICS the only part of SymPy which is not implemented in Axiom
> is Gruntz algorithm for limits.  After quick look at limits.py
> I think that it would be not hard to add similar code to Axiom.
> However it looks that SymPy code ignores many real-life issues:
> 1) algebraic expressions
> 2) special functions
> 3) parameters
>
> Especially determining sign in presence of parameters is troublesome
> (undecidable).

\start
Date: Sat, 31 Mar 2007 00:46:26 +0200
From: Ondrej Certik
To: Gabriel Dos Reis
Subject: Re: life and death

Is it possible to use Axiom from C++? Then it could also be used from
Python. But I fear that the only easy way of doing it is through
"string interface", like SAGE does for Maple for example.

Ondrej

On 30 Mar 2007 15:17:36 -0500, Gabriel Dos Reis wrote:
> Ondrej Certik writes:
>
> [...]
>
> | I am already repeating myself, so I think I already said all my
> | opinions on this issue, but I really think that what is needed is a
> | CAS that could be used as a library in some major language. And I fear
> | that Axiom couldn't easily be used this way.
>
> Axiom can and should be made interoperating with languages like C++ or
> Lisp,  which is a good starting gate to other galaxies.

\start
Date: Sat, 31 Mar 2007 00:52:02 +0200
From: Ondrej Certik
To: Tim Daly
Subject: Re: SymPy code

I would like to see a head-to-head comparison. If you need some help
with understanding the code, just ask.

Ondrej

On 3/30/07, Tim Daly wrote:
> Is your python algebra code available?
> It might be an interesting exercise to rewrite it into spad
> and see a head-to-head comparison. And, as a major side-effect,
> increase the range of Axiom

\start
Date: 30 Mar 2007 20:47:29 -0500
From: Gabriel Dos Reis
To: Ondrej Certik
Subject: Re: domains with parameters versus Python classes

Ondrej Certik writes:

| > I don't know which C++ you're talking about, but the one that I use on
| > daily basis and work on has lists (std::list), dictionaries (std::map,
| > std::multimap, etc.), has many garbage collectors as libraries with
| > a popular one freely available from Hans Boehm's web site -- industrial
| > strengh.  You don't have to use pointers in C++ if you don't need to.
| > Many  languages claim they don't have pointers, but represent
| > everything as pointers.  You can have everything dynamic in C++ if
| > that really is hat you want.  And, by the way it has a library for
| > easly interfacing with Python -- check out Boost.Python from Boost.
| >
| > Let's our ignorance not interfer with reality.
| 
| I also use C++ frequently, Boot.Python is very, very slow to compile,
| better is to use SWIG. Hans Boehm garbage collector is of course a
| nice thing, but the STL lists, map and stuff is very cumbersome to use
| compared to python.

That is a remarkably different statement that the ones you made earlier.

  # Well, at least Python and Ruby are much higher level than C++ (there
  # are lists, dictionaries, garbage collector, no pointers, it's dynamic,
  # etc.). And also many times slower.

I should have guessed.

| Compare for example GiNaC and SymPy's
| implementation of the same algorithms - SymPy is like 1/2 (or even
| more) smaller, because C++ is very, very verbose.

Now, you're elevating the properties of a particular library to that
of a language and language library.  I'll refrain from qualifying that
process and leave it at that.

\start
Date: Fri, 30 Mar 2007 22:22:00 -0400
From: Bill Page
To: list
Subject: SymPy on Axiom Wiki

Axiom Developers;

The Axiom wiki provides an online interface to Sage. Since Sage is
really "just Python" is a customized IPython front-end, it is also
possible to run most Python programs and to display the output
on the wiki. I have installed SymPy on the axiom-developer.org
server, so now it is also possible to display wiki pages containing
SymPy code and output. For example see:

http://wiki.axiom-developer.org/SandBoxSymPy

If you would like to experiment with SymPy and contribute to the
online documentation about the relationship betweeen SymPy,
Python, Axiom and other computer algebra systems please feel
free to create some new SandBox pages and expand on the
examples.

Creating a SandBox page on the Axiom wiki is easy. Just enter a
new page name in the 'Add Comments' box at the bottom of a page,
or after you click 'edit' to modify a page. For example:

  [SandBox SymPy Test 2]

After you click 'Save' a link will be displayed to the new page will
be displayed with a blue ? beside it. Clicking the ? will let you
enter text of the new page. If you use 'SandBox' as the prefix of
the name, your changes and experiments will not be sent out as
email to the wiki subscribers. Be Bold.

\start
Date: 31 Mar 2007 02:01:14 -0500
From: Gabriel Dos Reis
To: Gregory Vanuxem
Subject: Re: depsys and SBCL

Gabriel Dos Reis writes:

| Gregory Vanuxem writes:
|
| [...]
|
| | > This is just a head up.  If you know anything about the illegal
| | > character \#Stx, please let me know.
| |
| | No idea.
|
| I believe I nailed down where the error is coming from.
|
| Have a loot at line 368 in src/interp/def.lisp.pamphlet.  There are two
| uses of character Conotrol-B there (at least that is what Emacs shows
| me).  I'm curious about what could have been intended.  Tim?

I finally got my head around the def.lisp file.


The particular line at fault was trying to use a temporary placeholder
during the local transformation (DEFTRAN), and then replace that
placeholder with the value that was being decomposed.  The patch
below uses a gensym symbols instead of the non-portable (it appears
ANSI CL-2.2 forbids it) control-b character.  Note also that this
particular function appears to be effectively unexecuted because its
call is guarded by a variable which is globally set no nil and never
set again.

built on x86_64-suse-linux.
Applied to build-improvements.

-- Gaby

2007-03-30  Gabriel Dos Reis  Gabriel Dos Reis

	* def.lisp.pamphlet (|defLETdcq|): Use a gensym'd variable name
	instead of special character control-b.

*** src/interp/def.lisp.pamphlet	(revision 15421)
--- src/interp/def.lisp.pamphlet	(local)
***************
*** 1,3 ****
--- 1,4 ----
+ %% Oh Emacs, this is a -*- Lisp -*- file, despite appearance.
  \documentclass{article}
  \usepackage{axiom}
  \begin{document}
*************** foo defined inside of fum gets renamed a
*** 367,373 ****
                     (LIST ''T (LIST 'LET_ERROR (LIST 'MAKESTRING
                                                      (MK_LEFORM FORM)) R=
HS))))
      ((AND (EQ (CAR RHS) 'SPADLET) (IDENTP (SETQ NAME (CADR RHS)) ))
!        (LIST 'COND (LIST (SUBST RHS '=02 (DEFTRAN (LIST 'IS '=02 FORM))=
) NAME)
                     (LIST ''T (LIST 'LET_ERROR (LIST 'MAKESTRING
                                                      (MK_LEFORM FORM)) N=
AME))))
      ('T (SPADLET G (GENSYM))
--- 368,375 ----
                     (LIST ''T (LIST 'LET_ERROR (LIST 'MAKESTRING
                                                      (MK_LEFORM FORM)) R=
HS))))
      ((AND (EQ (CAR RHS) 'SPADLET) (IDENTP (SETQ NAME (CADR RHS)) ))
!        (SPADLET G (GENSYM))
!        (LIST 'COND (LIST (SUBST RHS G (DEFTRAN (LIST 'IS G FORM))) NAME=
)
                     (LIST ''T (LIST 'LET_ERROR (LIST 'MAKESTRING
                                                      (MK_LEFORM FORM)) N=
AME))))
      ('T (SPADLET G (GENSYM))



\start
Date: 31 Mar 2007 09:03:05 +0200
From: Martin Rubey
To: Waldek Hebisch, Ondrej Certik
Subject: Re: SymPy code

Since my department (Faculty for Mathematics, University Vienna) meanwhile
expressed interest in using Axiom, I'd be ready to support anybody who'd be
willing to implement Gruntz algorithm.  Please tell me what is necessary to get
you interested! (Money? Fame?)

\start
Date: Sat, 31 Mar 2007 14:20:55 +0200
From: Ondrej Certik
To: Gabriel Dos Reis
Subject: Re: domains with parameters versus Python classes

> | Compare for example GiNaC and SymPy's
> | implementation of the same algorithms - SymPy is like 1/2 (or even
> | more) smaller, because C++ is very, very verbose.
>
> Now, you're elevating the properties of a particular library to that
> of a language and language library.  I'll refrain from qualifying that
> process and leave it at that.

I just want to make sure I understand your point of view - so you
think that C++ and Python are at the same level?

\start
Date: Sat, 31 Mar 2007 14:51:54 +0200
From: Ondrej Certik
To: Bill Page
Subject: Re: SymPy on Axiom Wiki

I created another example in the Sandbox to show how to compute a
limit in SymPy, as this is probably the only feature of SymPy that can
be interesting, from the algorithms point of view.

Another easy way to play with SymPy is just to download it and start
bin/isympy. No installation is needed, just a standard python
interpreter.

If anyone of you plays with it, I am very interested in your opinions
(interface, features, etc.).

Ondrej

On 3/31/07, Bill Page wrote:
> Axiom Developers;
>
> The Axiom wiki provides an online interface to Sage. Since Sage is
> really "just Python" is a customized IPython front-end, it is also
> possible to run most Python programs and to display the output
> on the wiki. I have installed SymPy on the axiom-developer.org
> server, so now it is also possible to display wiki pages containing
> SymPy code and output. For example see:
>
> http://wiki.axiom-developer.org/SandBoxSymPy
>
> If you would like to experiment with SymPy and contribute to the
> online documentation about the relationship betweeen SymPy,
> Python, Axiom and other computer algebra systems please feel
> free to create some new SandBox pages and expand on the
> examples.
>
> Creating a SandBox page on the Axiom wiki is easy. Just enter a
> new page name in the 'Add Comments' box at the bottom of a page,
> or after you click 'edit' to modify a page. For example:
>
>   [SandBox SymPy Test 2]
>
> After you click 'Save' a link will be displayed to the new page will
> be displayed with a blue ? beside it. Clicking the ? will let you
> enter text of the new page. If you use 'SandBox' as the prefix of
> the name, your changes and experiments will not be sent out as
> email to the wiki subscribers. Be Bold.

\start
Date: 31 Mar 2007 14:03:24 -0500
From: Gabriel Dos Reis
To: list
Subject: [build-improvements] depsys and systemError

  depsys uses systemError, but no definition is provided in the
set of files we currently compile to it.  Curious.  The actual 
definitions are to be found in g-error.boot.  This patch adds that
file to the contituents of depsys.

Tested on an i686-pc-linux-gnu.
Applied to build-improvements.

-- Gaby

2007-03-31  Gabriel Dos Reis  Gabriel Dos Reis
  
	* g-error.boot.pamphlet: Explicitly puch into package "BOOT".

	* Makefile.pamphlet (${DEPSYS}): Add g-error.clisp to
	requirements.  Load it g-error.$(FASLEXT) too.
	(depsys_objects): Include g-error.$(FASLEXT).
	(depsys_boot_sources): Icnlude g-error.boot.
	(<<g-error.clisp>>): Remove.
	* Makefile.in: Regenerate.

*** src/interp/Makefile.in	(revision 19368)
--- src/interp/Makefile.in	(local)
*************** depsys_lisp_sources = $(depsys_lisp_nonc
*** 36,42 ****
  			$(depsys_lisp_compiled_sources)
  
  depsys_boot_sources = postpar.boot parse.boot clam.boot slam.boot \
! 	g-boot.boot c-util.boot g-util.boot
  DEP=	vmlisp.lisp	ggreater.lisp	\
  	hash.lisp	bootfuns.lisp	\
  	union.lisp	nlib.lisp	\
--- 36,42 ----
  			$(depsys_lisp_compiled_sources)
  
  depsys_boot_sources = postpar.boot parse.boot clam.boot slam.boot \
! 	g-boot.boot g-error.boot c-util.boot g-util.boot
  DEP=	vmlisp.lisp	ggreater.lisp	\
  	hash.lisp	bootfuns.lisp	\
  	union.lisp	nlib.lisp	\
*************** depsys_lisp_sources += parsing.lisp meta
*** 327,337 ****
  			metameta.lisp fnewmeta.lisp
  
  depsys_boot_sources = postpar.boot parse.boot clam.boot slam.boot \
! 			g-boot.boot c-util.boot g-util.boot
  
  depsys_SOURCES = $(depsys_lisp_SOURCES) $(depsys_boot_SOURCES)
  
! depsys_objects = nocompil.$(FASLEXT) bookvol5.$(FASLEXT) \
  		util.$(FASLEXT) postpar.$(FASLEXT) parse.$(FASLEXT) \
  		parsing.$(FASLEXT) metalex.$(FASLEXT) bootlex.$(FASLEXT) \
  		newaux.$(FASLEXT) preparse.$(FASLEXT) postprop.$(FASLEXT) \
--- 327,337 ----
  			metameta.lisp fnewmeta.lisp
  
  depsys_boot_sources = postpar.boot parse.boot clam.boot slam.boot \
! 			g-boot.boot g-error.boot c-util.boot g-util.boot
  
  depsys_SOURCES = $(depsys_lisp_SOURCES) $(depsys_boot_SOURCES)
  
! depsys_objects = nocompil.$(FASLEXT) bookvol5.$(FASLEXT) g-error.$(FASLEXT) \
  		util.$(FASLEXT) postpar.$(FASLEXT) parse.$(FASLEXT) \
  		parsing.$(FASLEXT) metalex.$(FASLEXT) bootlex.$(FASLEXT) \
  		newaux.$(FASLEXT) preparse.$(FASLEXT) postprop.$(FASLEXT) \
*************** ${DEPSYS}:	${DEP} sys-pkg.lisp nocompil.
*** 347,352 ****
--- 347,353 ----
  	        preparse.lisp \
  	        postprop.lisp def.lisp \
  	        metameta.lisp fnewmeta.lisp \
+ 		g-error.clisp \
  	        g-boot.${LISP} c-util.${LISP} \
  	        g-util.clisp \
  	        clam.${LISP} \
*************** ${DEPSYS}:	${DEP} sys-pkg.lisp nocompil.
*** 386,391 ****
--- 387,394 ----
  	@ echo '(load "clam")' >> makedep.lisp
  	@ echo '(unless (probe-file "slam.$(FASLEXT)") (compile-file "slam.clisp" :output-file "slam.$(FASLEXT)"))' >> makedep.lisp
  	@ echo '(load "slam")' >> makedep.lisp
+ 	@ echo '(unless (probe-file "g-error.$(FASLEXT)") (compile-file "g-error.clisp" :output-file "g-error.$(FASLEXT)"))' >> makedep.lisp
+ 	@ echo '(load "g-error")' >> makedep.lisp
  	@ echo '(unless (probe-file "g-boot.$(FASLEXT)") (compile-file "g-boot.${LISP}" :output-file "g-boot.$(FASLEXT)"))' >> makedep.lisp
  	@ echo '(load "g-boot")' >> makedep.lisp
  	@ echo '(unless (probe-file "c-util.$(FASLEXT)") (compile-file "c-util.${LISP}" :output-file "c-util.$(FASLEXT)"))' >> makedep.lisp
*************** g-cndata.clisp: g-cndata.boot
*** 830,844 ****
  	  fi
  
  
- g-error.clisp: g-error.boot
- 	@ echo 264 making $@ from $<
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn (boottran::boottocl "g-error.boot"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn (boottran::boottocl "g-error.boot"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- 
  g-opt.clisp: g-opt.boot
  	@ echo 267 making $@ from $<
  	@ if [ -z "${NOISE}" ] ; then \
--- 833,838 ----
*** src/interp/Makefile.pamphlet	(revision 19368)
--- src/interp/Makefile.pamphlet	(local)
*************** depsys_lisp_sources = $(depsys_lisp_nonc
*** 277,283 ****
  			$(depsys_lisp_compiled_sources)
  
  depsys_boot_sources = postpar.boot parse.boot clam.boot slam.boot \
! 	g-boot.boot c-util.boot g-util.boot
  @
  
  The {\bf DEP} variable contains the list of files that
--- 277,283 ----
  			$(depsys_lisp_compiled_sources)
  
  depsys_boot_sources = postpar.boot parse.boot clam.boot slam.boot \
! 	g-boot.boot g-error.boot c-util.boot g-util.boot
  @
  
  The {\bf DEP} variable contains the list of files that
*************** depsys_lisp_sources += parsing.lisp meta
*** 990,1000 ****
  			metameta.lisp fnewmeta.lisp
  
  depsys_boot_sources = postpar.boot parse.boot clam.boot slam.boot \
! 			g-boot.boot c-util.boot g-util.boot
  
  depsys_SOURCES = $(depsys_lisp_SOURCES) $(depsys_boot_SOURCES)
  
! depsys_objects = nocompil.$(FASLEXT) bookvol5.$(FASLEXT) \
  		util.$(FASLEXT) postpar.$(FASLEXT) parse.$(FASLEXT) \
  		parsing.$(FASLEXT) metalex.$(FASLEXT) bootlex.$(FASLEXT) \
  		newaux.$(FASLEXT) preparse.$(FASLEXT) postprop.$(FASLEXT) \
--- 990,1000 ----
  			metameta.lisp fnewmeta.lisp
  
  depsys_boot_sources = postpar.boot parse.boot clam.boot slam.boot \
! 			g-boot.boot g-error.boot c-util.boot g-util.boot
  
  depsys_SOURCES = $(depsys_lisp_SOURCES) $(depsys_boot_SOURCES)
  
! depsys_objects = nocompil.$(FASLEXT) bookvol5.$(FASLEXT) g-error.$(FASLEXT) \
  		util.$(FASLEXT) postpar.$(FASLEXT) parse.$(FASLEXT) \
  		parsing.$(FASLEXT) metalex.$(FASLEXT) bootlex.$(FASLEXT) \
  		newaux.$(FASLEXT) preparse.$(FASLEXT) postprop.$(FASLEXT) \
*************** ${DEPSYS}:	${DEP} sys-pkg.lisp nocompil.
*** 1010,1015 ****
--- 1010,1016 ----
  	        preparse.lisp \
  	        postprop.lisp def.lisp \
  	        metameta.lisp fnewmeta.lisp \
+ 		g-error.clisp \
  	        g-boot.${LISP} c-util.${LISP} \
  	        g-util.clisp \
  	        clam.${LISP} \
*************** ${DEPSYS}:	${DEP} sys-pkg.lisp nocompil.
*** 1049,1054 ****
--- 1050,1057 ----
  	@ echo '(load "clam")' >> makedep.lisp
  	@ echo '(unless (probe-file "slam.$(FASLEXT)") (compile-file "slam.clisp" :output-file "slam.$(FASLEXT)"))' >> makedep.lisp
  	@ echo '(load "slam")' >> makedep.lisp
+ 	@ echo '(unless (probe-file "g-error.$(FASLEXT)") (compile-file "g-error.clisp" :output-file "g-error.$(FASLEXT)"))' >> makedep.lisp
+ 	@ echo '(load "g-error")' >> makedep.lisp
  	@ echo '(unless (probe-file "g-boot.$(FASLEXT)") (compile-file "g-boot.${LISP}" :output-file "g-boot.$(FASLEXT)"))' >> makedep.lisp
  	@ echo '(load "g-boot")' >> makedep.lisp
  	@ echo '(unless (probe-file "c-util.$(FASLEXT)") (compile-file "c-util.${LISP}" :output-file "c-util.$(FASLEXT)"))' >> makedep.lisp
*************** g-cndata.clisp: g-cndata.boot
*** 1880,1898 ****
  
  @
  
- \subsection{g-error.boot}
- 
- <<g-error.clisp>>=
- g-error.clisp: g-error.boot
- 	@ echo 264 making $@ from $<
- 	@ if [ -z "${NOISE}" ] ; then \
- 	   echo '(progn (boottran::boottocl "g-error.boot"))' | ${DEPSYS} ; \
- 	  else \
- 	   echo '(progn (boottran::boottocl "g-error.boot"))' | ${DEPSYS} >> ${TMP}/trace ; \
- 	  fi
- 
- @
- 
  \subsection{g-opt.boot}
  
  <<g-opt.clisp>>=
--- 1883,1888 ----
*************** distclean-local: clean-local
*** 3304,3311 ****
  
  <<g-cndata.clisp>>
  
- <<g-error.clisp>>
- 
  <<g-opt.clisp>>
  
  <<g-timer.clisp>>
--- 3294,3299 ----
*** src/interp/g-error.boot.pamphlet	(revision 19368)
--- src/interp/g-error.boot.pamphlet	(local)
***************
*** 1,14 ****
  \documentclass{article}
  \usepackage{axiom}
! \begin{document}
! \title{\$SPAD/src/interp g-error.boot}
  \author{The Axiom Team}
  \maketitle
  \begin{abstract}
  \end{abstract}
  \eject
  \tableofcontents
  \eject
  \section{License}
  <<license>>=
  -- Copyright (c) 1991-2002, The Numerical ALgorithms Group Ltd.
--- 1,17 ----
  \documentclass{article}
  \usepackage{axiom}
! 
! \title{\File{src/interp/g-error.boot} Pamphlet}
  \author{The Axiom Team}
+ 
+ \begin{document}
  \maketitle
  \begin{abstract}
  \end{abstract}
  \eject
  \tableofcontents
  \eject
+ 
  \section{License}
  <<license>>=
  -- Copyright (c) 1991-2002, The Numerical ALgorithms Group Ltd.
***************
*** 46,51 ****
--- 49,56 ----
  <<*>>=
  <<license>>
  
+ )package "BOOT"
+ 
  -- This file contains the error printing code used in BOOT and SPAD.
  -- While SPAD only calls "error" (which is then labeled as an algebra
  -- error, BOOT calls "userError" and "systemError" when a problem is


\start
Date: Sat, 31 Mar 2007 18:25:15 -0400
From: Bill Page
To: Ondrej Certik
Subject: RE: SymPy on Axiom Wiki

On March 31, 2007 8:52 AM Ondrej Certik
> 
> I created another example in the Sandbox to show how to
> compute a limit in SymPy, as this is probably the only
> feature of SymPy that can be interesting, from the
> algorithms point of view.

Well actually I think SymPy might be interesting to Axiom
developers specifically because Axiom does not currently
have a purely symbolic domain, i.e. a domain where one can
do just symbolic manipulations without regard to what
mathematical object an expression might represent. Of that
is not quite true because underlying Axiom is Lisp and
Lisp SExpression is available as a domain. And there is
the InputForm domain to which almost all Axiom objects can
be coerced. Right now InputForm looks and behaves very much
like SExpression but the OutputForm that corresponds to both
of these domains is much too Lisp-ish for my taste. I think
it would be much better if the coercion to OutputForm from
InputForm looked more (or even exactly) like the syntax of
input to the Axiom interpreter. Then we could add symbolic
manipulations such as are done in SymPy directly to Axiom.
In fact this would be very easy to do and the fact that it
has not yet been done in Axiom can only related to the
pre-occupation of the original Axiom developers with what
Stephen Watt calls "computer algebra" as opposed to the
much simpler problem of symbolic computation. But I think
symbolic computation has an important place in Axiom.

I would like to discuss this more with other active Axiom
developers.

> 
> Another easy way to play with SymPy is just to download it
> and start bin/isympy. No installation is needed, just a
> standard python interpreter.

Well I did have a bit of time installing the pygame dependency
since axiom-developer.org is not a Debian machine. The secondary
SDL dependencies of pygame where a small challenge but it was
not that hard.

Is 'isympy' based on IPython like Sage? (Sorry, I have read all
the SymPy docs yet). 

> 
> If anyone of you plays with it, I am very interested in your
> opinions (interface, features, etc.).
>

I plan to do some direct comparisons between Axiom's Factor
domain and SymPy factor in the near future so I am likely to
have comments. Would you like me to cross post them to the
SymPy list or is the axiom-developer list sufficient?

Regards,
Bill Page.
 
\start
Date: 31 Mar 2007 18:10:04 -0500
From: Gabriel Dos Reis
To: Bill Page
Subject: re: SymPy on Axiom Wiki

Bill Page writes:

[...]

| I would like to discuss this more with other active Axiom
| developers.

Why should InputForm be preferable over Expression T?

-- Gaby



\end{verbatim}
\eject
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\cleardoublepage
%\phantomsection
\addcontentsline{toc}{chapter}{Bibliography}
\bibliographystyle{axiom}
\bibliography{axiom}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\cleardoublepage
%\phantomsection
\addcontentsline{toc}{chapter}{Index}
\printindex
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\end{document}
