gcl, shared libraries, was [Axiom-developer] Lisp portability

[Camm Maguire]

Greetings, and thanks for including me in this thread. Unfortunately,
axiom-developer mail is still not getting through my ISP for some
reason.

In my private tree Axiom is nicely working on top of sbcl and clisp.
The remaining known problems are sockets and writeablep function.

Great! It is always nice to have more options. But I do have a
general question here. Work in this direction obviously makes sense
if 1) GCL is currently deficient for axiom use in some regard and 2)
we have difficulties addressing said deficiencies via changes to GCL.
If both of these are true, I would greatly appreciate you and/or
others letting me know the details, as it is and has been a goal of
mine to ensure that gcl remains optimal for axiom use. As in the
past, I pledge that if axiom needs anything from GCL which is
currently unavailable, I will make sure said functionality works in
GCL. What I would like to avoid is chasing every random package which
no one has any serious intention of deploying in a real shipped
program.

If either 1) or 2) above are not true, may I suggest that significant
work in this regard is a distraction from the real goals of the axiom
project -- to deliver the best symbolic algebra package in the open
source world. In our company, we manage approx. $70 billion dollars
using open source software and code we've written on top of it. We
would get nowhere if we spent any time at all making sure our code
works both on gcc and icc, etc. Rather we pick a platform that
appears flexible, stick to it, and get the results we want out of it
quickly. We do almost everything using gcc, gdb and emacs, not
because they are the slickest or hottest or even fastest, but because
they have good portable performance, they can be changed at the source
level if necessary, and they will be available forever, making our
payoff period for the learning curve essentially last a whole
lifetime.

I'd really love to help the axiom project by offering a similar setup
for use by the developers. Even one better -- axiom has its own
personal compiler developer to tailor the compiler to its needs if
necessary. This only pays off if my work on GCL frees axiom developer
hours for work on the core system.

Also, currently for clisp I need cl-fad library, which I consider
problematic. Namely, cl-fad does not work with gcl, so for gcl
we need separate code. We need only few functions from cl-fad,
to work around clisp weirdness (clisp makes strong distinction
between paths to files and paths to directories and refuses
to perform file operations on directories). So my current plan
is to eliminate use of cl-fad and provide the needed functions
directly. Related problem is performing operations on

I think this is a wise choice, but needless to say, if you need
cl-fad, I'll make sure it works.

I must say I'm less than enamored with the cl-foo library development
model. Its source level as opposed to binary, and there is no shared
library memory savings. Beyond which, there really doesn't appear to
be much of anything available which is not provided elsewhere in
faster, smaller, shareable C libraries, though I haven't made any
exhaustive study here.

I love lisp, obviously, and primarily for the magnitude and quality of
AI-type code which has been developed and has recently entered into
the open source world. But lisp is not going to compete with perl,
python, java, or C, IMHO. The primary goal should be in fulfilling
the ansi-standard and supporting applications from the past, while
offering non-standard interfaces to newer functionality in external
shared C libraries. Do we really think cl-fad has a thirty year
lifetime ahead of it? How will we coordinate with all these cl-
library developers external to the axiom project when they move on to
other things in life? Will we read all their source and maintain it
ourselves?

Thankfully, the ansi-standard is written down, and with all its warts,
will last > 30 years, IMHO. If we need items outside the standard, we
should rely on implementations in C shared libraries, as these will
have a longer lifetime and in general will be technically superior.
We should then pick one again non-standard glue between lisp and C,
and stick to it, and call all the shared library routines from within
lisp. These of course are just my opinions.

It is good you brought this up, as gclcvs has followed clisp-style
directory usage, at least at present. We can undo this if required.
Pathnames with spaces are also fully supported in gclcvs. These can
be backported to 2.6.8pre if necessary.

directories -- to gain portability between Unix and Windows
I tried to use Lisp code. But each Lisp is doing them
differently (and apparently some operations sometimes are missing).
So I got a maze of conditionals over Lisp implementations.
Looking at resulting code I feel that it is better to
call operationg system utilities and have just use
conditionals to choose between Unix and Windows versions
of file utilities.

In C, we call this #ifdef hell. There is no good reason for it, in my
experience.

Concerning sockets, we need Unix domain sockets and select. It
seems that clisp provide both, but to get Unix domain sockets
one needs version including rawsock module, which is not included
in default clisp configuration.
sbcl offers sb-bsd-sockets which seem to have basic functions,
but I do not see select.
gcl documentation suggest that Unix domain sockets are unsupported.
Also, I see no traces of select.

gclcvs has a select/fork based parallel processing system:

SYSTEM>(walker::macroexpand-all '(p-let ((x (foo)) (y (bar))) (+ x y)))

(LET* (X Y)
(LET* ((#:G2306 3)
(#:G2301 (LIST (LET ((#:G2310 (FORK)))
(IF (EQL 0 (CAR #:G2310))
(PROGN
(WRITE-POINTER-OBJECT (FOO) #:G2310)
(BYE))
#:G2310))
(LET ((#:G2311 (FORK)))
(IF (EQL 0 (CAR #:G2311))
(PROGN
(WRITE-POINTER-OBJECT (BAR) #:G2311)
(BYE))
#:G2311)))))
(DECLARE ((INTEGER 0 3) #:G2306))
(UNWIND-PROTECT
(DO () ((= #:G2306 0))
(LET ((#:G2309 (SELECT-READ #:G2301 -1)))
(DECLARE ((INTEGER 0 3) #:G2309))
(DO ((#:G2299 0 (1+ #:G2299)) (#:G2307 1 (ASH #:G2307 1))
(#:G2308 #:G2301 (CDR #:G2308)))
((= #:G2299 2) (SETQ #:G2306 (LOGANDC2 #:G2306 #:G2309)))
(DECLARE ((INTEGER 0 2) #:G2299) ((INTEGER 1 4) #:G2307))
(IF (/= 0 (LOGAND #:G2307 #:G2309))
(PROGN
(LET ((#:G2300 (READ-POINTER-OBJECT (CAR #:G2308))))
(LET ((#:G2313 #:G2299))
(IF (EQL #:G2313 '0) (PROGN (SETQ X #:G2300))
(IF (EQL #:G2313 '1) (PROGN (SETQ Y #:G2300))
NIL)))))))))
(DO* ((#:G2314 #:G2301 (CDR #:G2314)))
((ENDP #:G2314) (CDR #:G2301))
(LET ((#:G2301 (CAR #:G2314))) (KILL #:G2301 0)))))
(+ X Y))


This can be adapted to whatever other interface one may desire.

Do you mean dgram (UDP) sockets? If you specify the interface, we'll
put them in.

There is "portable" cl-sockets library but the manual says it supports
Allegro CL, sbcl and cmucl. The manual does not say anything about
Unix domain sockets or select. The manual says that cl-sockets requires
UFFI, so presumably cl-sockets works on top of "portable" C library.
In short my finding is that portable Lisp sockets are a myth: all
implementations provide different interface and frequently miss
some essential services. People who want portablity between Lisp
implementations interface to C.

Agreed!

I've been working on a better interface to external shared C
libraries for GCL. The issue, as you may recall, is that GCL-compiled
code referring to external shared function addresses are statically
relocated to the value of said address at the time the .o file is
loaded. If one then saves the image and re-executes, the function is
likely in a different place.

I've figured out a persistent solution using dlopen. Still working on
the precise interface, but you can see the idea here. Comments are
marked with ***:

=============================================================================
GCL (GNU Common Lisp) 2.7.0 CLtL1 May 22 2007 16:39:58
Source License: LGPL(gcl,gmp,pargcl), GPL(unexec,bfd,xgcl)
Binary License: GPL due to GPL'ed components: (XGCL 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.

Temporary directory for compiler files set to /tmp/

(in-package 'si)

#<"SYSTEM" package>

SYSTEM>(show-lib-syms)

NIL

SYSTEM>(mdlsym "cosf" "libm.so")

|libm|:|cosf| ;;*** package autmatically created, lib automatically dlopened

SYSTEM>(mdlsym "dgemv_" "libblas.so")

|libblas|:|dgemv_|

SYSTEM>(show-lib-syms)

(LIB:|libblas| 6730696 #<"libblas" package>) ;;*** value of package
symbol is dlopen handle
(|libblas|:|dgemv_| 1080730284 NIL) ;;*** value of C symbol
is current address,
reset on system startup
(LIB:|libm| 1074174504 #<"libm" package>)
(|libm|:|cosf| 1094172320 NIL)
NIL

SYSTEM>(dladdr |libblas|:|dgemv_| ;;*** exact path resolution
)

#P"/usr/lib/atlas/sse2/libblas.so"

SYSTEM>(system "cat /tmp/dl2.l")
(in-package "libm")

(eval-when
(compile eval)
(defmacro defdl (sym)
(let* ((sym (si::mdlsym (string-downcase sym) "libm.so"))
(fsym (si::mdlsym (concatenate 'string (string sym) "f") "libm.so")))
`(progn
(defun ,sym (x) (si::dl-double-to-double ',sym x))
(defun ,fsym (x) (si::dl-float-to-float ',fsym x))))))

(defdl exp)
(defdl log)
(defdl sin)
(defdl cos)
(defdl tan)
(defdl asin)
(defdl acos)
(defdl atan)
(defdl sinh)
(defdl cosh)
(defdl tanh)
(defdl asinh)
(defdl acosh)
(defdl atanh)

SYSTEM>(load "/tmp/dl2.l")

;; Loading /tmp/dl2.l
;; Finished loading /tmp/dl2.l
T

SYSTEM>(show-lib-syms)

(LIB:|libblas| 6730696 #<"libblas" package>)
(|libblas|:|dgemv_| 1080730284 NIL)
(LIB:|libm| 1074174504 #<"libm" package>)
(|libm|:|atan| 1094141472
#<interpreted-function (LAMBDA-BLOCK |libm|:|atan| (|libm|::X)
(DL-DOUBLE-TO-DOUBLE '|libm|:|atan| ;;***
standard call to address denoted
by symbol value, one double arg, returning one double
|libm|::X))>)
(|libm|:|acosh| 1094146080
#<interpreted-function (LAMBDA-BLOCK |libm|:|acosh| (|libm|::X)
(DL-DOUBLE-TO-DOUBLE '|libm|:|acosh|
|libm|::X))>)
(|libm|:|expf| 1094176432
#<interpreted-function (LAMBDA-BLOCK |libm|:|expf| (|libm|::X)
(DL-FLOAT-TO-FLOAT '|libm|:|expf|
|libm|::X))>)
(|libm|:|atanhf| 1094176064
#<interpreted-function (LAMBDA-BLOCK |libm|:|atanhf| (|libm|::X)
(DL-FLOAT-TO-FLOAT '|libm|:|atanhf|
|libm|::X))>)
(|libm|:|acosf| 1094175504
#<interpreted-function (LAMBDA-BLOCK |libm|:|acosf| (|libm|::X)
(DL-FLOAT-TO-FLOAT '|libm|:|acosf|
|libm|::X))>)
(|libm|:|exp| 1094146864
#<interpreted-function (LAMBDA-BLOCK |libm|:|exp| (|libm|::X)
(DL-DOUBLE-TO-DOUBLE '|libm|:|exp|
|libm|::X))>)
(|libm|:|atanh| 1094146512
#<interpreted-function (LAMBDA-BLOCK |libm|:|atanh| (|libm|::X)
(DL-DOUBLE-TO-DOUBLE '|libm|:|atanh|
|libm|::X))>)
(|libm|:|cosh| 1094146672
#<interpreted-function (LAMBDA-BLOCK |libm|:|cosh| (|libm|::X)
(DL-DOUBLE-TO-DOUBLE '|libm|:|cosh|
|libm|::X))>)
(|libm|:|cosf| 1094172320
#<interpreted-function (LAMBDA-BLOCK |libm|:|cosf| (|libm|::X)
(DL-FLOAT-TO-FLOAT '|libm|:|cosf|
|libm|::X))>)
(|libm|:|atanf| 1094172032
#<interpreted-function (LAMBDA-BLOCK |libm|:|atanf| (|libm|::X)
(DL-FLOAT-TO-FLOAT '|libm|:|atanf|
|libm|::X))>)
(|libm|:|cos| 1094141792
#<interpreted-function (LAMBDA-BLOCK |libm|:|cos| (|libm|::X)
(DL-DOUBLE-TO-DOUBLE '|libm|:|cos|
|libm|::X))>)
(|libm|:|tanh| 1094145584
#<interpreted-function (LAMBDA-BLOCK |libm|:|tanh| (|libm|::X)
(DL-DOUBLE-TO-DOUBLE '|libm|:|tanh|
|libm|::X))>)
(|libm|:|tanf| 1094175168
#<interpreted-function (LAMBDA-BLOCK |libm|:|tanf| (|libm|::X)
(DL-FLOAT-TO-FLOAT '|libm|:|tanf|
|libm|::X))>)
(|libm|:|tan| 1094145536
#<interpreted-function (LAMBDA-BLOCK |libm|:|tan| (|libm|::X)
(DL-DOUBLE-TO-DOUBLE '|libm|:|tan|
|libm|::X))>)
(|libm|:|sinh| 1094150832
#<interpreted-function (LAMBDA-BLOCK |libm|:|sinh| (|libm|::X)
(DL-DOUBLE-TO-DOUBLE '|libm|:|sinh|
|libm|::X))>)
(|libm|:|asin| 1094146208
#<interpreted-function (LAMBDA-BLOCK |libm|:|asin| (|libm|::X)
(DL-DOUBLE-TO-DOUBLE '|libm|:|asin|
|libm|::X))>)
(|libm|:|sinf| 1094175120
#<interpreted-function (LAMBDA-BLOCK |libm|:|sinf| (|libm|::X)
(DL-FLOAT-TO-FLOAT '|libm|:|sinf|
|libm|::X))>)
(|libm|:|sin| 1094145488
#<interpreted-function (LAMBDA-BLOCK |libm|:|sin| (|libm|::X)
(DL-DOUBLE-TO-DOUBLE '|libm|:|sin|
|libm|::X))>)
(|libm|:|coshf| 1094176224
#<interpreted-function (LAMBDA-BLOCK |libm|:|coshf| (|libm|::X)
(DL-FLOAT-TO-FLOAT '|libm|:|coshf|
|libm|::X))>)
(|libm|:|tanhf| 1094175216
#<interpreted-function (LAMBDA-BLOCK |libm|:|tanhf| (|libm|::X)
(DL-FLOAT-TO-FLOAT '|libm|:|tanhf|
|libm|::X))>)
(|libm|:|acoshf| 1094175632
#<interpreted-function (LAMBDA-BLOCK |libm|:|acoshf| (|libm|::X)
(DL-FLOAT-TO-FLOAT '|libm|:|acoshf|
|libm|::X))>)
(|libm|:|asinh| 1094141232
#<interpreted-function (LAMBDA-BLOCK |libm|:|asinh| (|libm|::X)
(DL-DOUBLE-TO-DOUBLE '|libm|:|asinh|
|libm|::X))>)
(|libm|:|asinhf| 1094171792
#<interpreted-function (LAMBDA-BLOCK |libm|:|asinhf| (|libm|::X)
(DL-FLOAT-TO-FLOAT '|libm|:|asinhf|
|libm|::X))>)
(|libm|:|sinhf| 1094180368
#<interpreted-function (LAMBDA-BLOCK |libm|:|sinhf| (|libm|::X)
(DL-FLOAT-TO-FLOAT '|libm|:|sinhf|
|libm|::X))>)
(|libm|:|asinf| 1094175760
#<interpreted-function (LAMBDA-BLOCK |libm|:|asinf| (|libm|::X)
(DL-FLOAT-TO-FLOAT '|libm|:|asinf|
|libm|::X))>)
(|libm|:|logf| 1094179104
#<interpreted-function (LAMBDA-BLOCK |libm|:|logf| (|libm|::X)
(DL-FLOAT-TO-FLOAT '|libm|:|logf|
|libm|::X))>)
(|libm|:|log| 1094149536
#<interpreted-function (LAMBDA-BLOCK |libm|:|log| (|libm|::X)
(DL-DOUBLE-TO-DOUBLE '|libm|:|log|
|libm|::X))>)
(|libm|:|acos| 1094145952
#<interpreted-function (LAMBDA-BLOCK |libm|:|acos| (|libm|::X)
(DL-DOUBLE-TO-DOUBLE '|libm|:|acos|
|libm|::X))>)
NIL

SYSTEM>(compile-file "/tmp/dl2.l")

;; Compiling /tmp/dl2.l.
;; End of Pass 1.
;; End of Pass 2.
;; OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3, (Debug quality ignored)
;; Finished compiling /tmp/dl2.o.
#P"/tmp/dl2.o"
NIL
NIL

SYSTEM>(load *)

;; Loading /tmp/dl2.o
;; start address -T 0x66f480 ;; Finished loading /tmp/dl2.o
1460

SYSTEM>(show-lib-syms)

(LIB:|libblas| 6730696 #<"libblas" package>)
(|libblas|:|dgemv_| 1080730284 NIL)
(LIB:|libm| 1074174504 #<"libm" package>)
(|libm|:|atan| 1094141472 #<compiled-function |libm|:|atan|>)
(|libm|:|acosh| 1094146080 #<compiled-function |libm|:|acosh|>)
(|libm|:|expf| 1094176432 #<compiled-function |libm|:|expf|>)
(|libm|:|atanhf| 1094176064 #<compiled-function |libm|:|atanhf|>)
(|libm|:|acosf| 1094175504 #<compiled-function |libm|:|acosf|>)
(|libm|:|exp| 1094146864 #<compiled-function |libm|:|exp|>)
(|libm|:|atanh| 1094146512 #<compiled-function |libm|:|atanh|>)
(|libm|:|cosh| 1094146672 #<compiled-function |libm|:|cosh|>)
(|libm|:|cosf| 1094172320 #<compiled-function |libm|:|cosf|>)
(|libm|:|atanf| 1094172032 #<compiled-function |libm|:|atanf|>)
(|libm|:|cos| 1094141792 #<compiled-function |libm|:|cos|>)
(|libm|:|tanh| 1094145584 #<compiled-function |libm|:|tanh|>)
(|libm|:|tanf| 1094175168 #<compiled-function |libm|:|tanf|>)
(|libm|:|tan| 1094145536 #<compiled-function |libm|:|tan|>)
(|libm|:|sinh| 1094150832 #<compiled-function |libm|:|sinh|>)
(|libm|:|asin| 1094146208 #<compiled-function |libm|:|asin|>)
(|libm|:|sinf| 1094175120 #<compiled-function |libm|:|sinf|>)
(|libm|:|sin| 1094145488 #<compiled-function |libm|:|sin|>)
(|libm|:|coshf| 1094176224 #<compiled-function |libm|:|coshf|>)
(|libm|:|tanhf| 1094175216 #<compiled-function |libm|:|tanhf|>)
(|libm|:|acoshf| 1094175632 #<compiled-function |libm|:|acoshf|>)
(|libm|:|asinh| 1094141232 #<compiled-function |libm|:|asinh|>)
(|libm|:|asinhf| 1094171792 #<compiled-function |libm|:|asinhf|>)
(|libm|:|sinhf| 1094180368 #<compiled-function |libm|:|sinhf|>)
(|libm|:|asinf| 1094175760 #<compiled-function |libm|:|asinf|>)
(|libm|:|logf| 1094179104 #<compiled-function |libm|:|logf|>)
(|libm|:|log| 1094149536 #<compiled-function |libm|:|log|>)
(|libm|:|acos| 1094145952 #<compiled-function |libm|:|acos|>)
NIL

SYSTEM>(disassemble '|libm|:|log|)

;; Compiling /tmp/gazonk_27499_0.lsp.
;; End of Pass 1.
;; End of Pass 2.
;; OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3, (Debug quality ignored)
;; Finished compiling /tmp/gazonk_27499_0.o.

#include "gazonk_27499_0.h"
void init_code(){do_init((void *)VV);}
/* local entry for function CMP-ANON */

static object LI1(V2)

object V2;
{ VMB1 VMS1 VMV1
goto TTL;
TTL:; ;;**** fast link C call to generic interface
{object V3 = (/* DL-DOUBLE-TO-DOUBLE */(*LnkLI1)(((object)VV[0]),(V2)));VMR1
(V3);}
return Cnil;
}
static object LnkTLI1(object first,...){object V1;va_list ap;va_start(ap,first);V1=(object )call_proc_new(((object)VV[1]),0,0,(void **)(void *)&LnkLI1,2,first,ap);va_end(ap);return V1;} /* DL-DOUBLE-TO-DOUBLE */
#(#(log DL-DOUBLE-TO-DOUBLE
(%INIT
. #((LET ((*DISABLE-RECOMPILE* T))
(MFSFUN 'CMP-ANON 0 1 0)
(ADD-HASH 'CMP-ANON '((T) T)
'((DL-DOUBLE-TO-DOUBLE (T T) T))
SYSTEMCOMPILERCMP-ANON /!.log DL-DOUBLE-TO-DOUBL,QUOTE1-
'/tmp/gazonk_27499_0.lsp))
(DO-RECOMPILE)))))
static object LI1();
#define VMB1
#define VMS1
#define VMV1
#define VMR1(VMT1) return(VMT1);
#define VM1 0
static void * VVi[3]={
#define Cdata VV[2]
(void *)(LI1)
};
#define VV (VVi)
static object LnkTLI1(object,...);
static object (*LnkLI1)() = (object (*)()) LnkTLI1;

/tmp/gazonk_27499_0.o: file format elf32-i386

Disassembly of section .text:

00000000 <init_code>:
object
macro_def_int(object);

#include "gazonk_27499_0.h"
void init_code(){do_init((void *)VV);}
0: 55 push %ebp
1: 89 e5 mov %esp,%ebp
3: 83 ec 08 sub $0x8,%esp
6: b8 00 00 00 00 mov $0x0,%eax
b: 89 04 24 mov %eax,(%esp)
e: e8 fc ff ff ff call f <init_code+0xf>
13: c9 leave
14: c3 ret

00000015 <LI1>:
/* local entry for function CMP-ANON */

static object LI1(V2)

object V2;
{ VMB1 VMS1 VMV1
15: 55 push %ebp
16: 89 e5 mov %esp,%ebp
18: 83 ec 18 sub $0x18,%esp
goto TTL;
TTL:;
{object V3 = (/* DL-DOUBLE-TO-DOUBLE */(*LnkLI1)(((object)VV[0]),(V2)));VMR1
1b: 8b 0d 0c 00 00 00 mov 0xc,%ecx
21: a1 00 00 00 00 mov 0x0,%eax
26: 89 c2 mov %eax,%edx
28: 8b 45 08 mov 0x8(%ebp),%eax
2b: 89 44 24 04 mov %eax,0x4(%esp)
2f: 89 14 24 mov %edx,(%esp)
32: ff d1 call *%ecx
34: 89 45 fc mov %eax,0xfffffffc(%ebp)
37: 8b 45 fc mov 0xfffffffc(%ebp),%eax
(V3);}
return Cnil;
}
3a: c9 leave
3b: c3 ret

0000003c <LnkTLI1>:
static object LnkTLI1(object first,...){object V1;va_list ap;va_start(ap,first);V1=(object )call_proc_new(((object)VV[1]),0,0,(void **)(void *)&LnkLI1,2,first,ap);va_end(ap);return V1;} /* DL-DOUBLE-TO-DOUBLE */
3c: 55 push %ebp
3d: 89 e5 mov %esp,%ebp
3f: 53 push %ebx
40: 83 ec 34 sub $0x34,%esp
43: 8d 45 0c lea 0xc(%ebp),%eax
46: 89 45 f4 mov %eax,0xfffffff4(%ebp)
49: 8b 55 f4 mov 0xfffffff4(%ebp),%edx
4c: b9 0c 00 00 00 mov $0xc,%ecx
51: a1 04 00 00 00 mov 0x4,%eax
56: 89 c3 mov %eax,%ebx
58: 89 54 24 18 mov %edx,0x18(%esp)
5c: 8b 45 08 mov 0x8(%ebp),%eax
5f: 89 44 24 14 mov %eax,0x14(%esp)
63: c7 44 24 10 02 00 00 movl $0x2,0x10(%esp)
6a: 00
6b: 89 4c 24 0c mov %ecx,0xc(%esp)
6f: c7 44 24 08 00 00 00 movl $0x0,0x8(%esp)
76: 00
77: c7 44 24 04 00 00 00 movl $0x0,0x4(%esp)
7e: 00
7f: 89 1c 24 mov %ebx,(%esp)
82: e8 fc ff ff ff call 83 <LnkTLI1+0x47>
87: 89 45 f8 mov %eax,0xfffffff8(%ebp)
8a: 8b 45 f8 mov 0xfffffff8(%ebp),%eax
8d: 83 c4 34 add $0x34,%esp
90: 5b pop %ebx
91: 5d pop %ebp
92: c3 ret
NIL

SYSTEM>(defun foo (x) (declare (long-float x)) (|libm|:|log| x))

FOO

SYSTEM>(disassemble 'foo)

;; Compiling /tmp/gazonk_27499_0.lsp.
;; End of Pass 1.
;; End of Pass 2.
;; OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3, (Debug quality ignored)
;; Finished compiling /tmp/gazonk_27499_0.o.

#include "gazonk_27499_0.h"
void init_code(){do_init((void *)VV);}
/* local entry for function FOO */

static double LI1(V2)

double V2;
{ VMB1 VMS1 VMV1
goto TTL;
TTL:;
/*(log X)*/
{double V3;
V3= V2; ;;*** Automatic inlining through function pointer
{double V4 = ((double (*)(double))DLlog)(V3);VMR1
(V4);}}
/* END (log X)*/
}
/* global entry for the function FOO */

static void L1()
{ register object *base=vs_base;
base[0]=make_longfloat(LI1(lf(base[0])));
vs_top=(vs_base=base)+1;
}
#(#(log
(%INIT
. #((LET ((*DISABLE-RECOMPILE* T))
(MF 'FOO 0)
(ADD-HASH 'FOO '((LONG-FLOAT) LONG-FLOAT) '((log (T) T))
LISPLAMBDA!
!,DECLAR,OPTIMIZ,SAFETY
libmlog-
'/tmp/gazonk_27499_0.lsp)
(MDL 'log 'libm 1)) ;;*** function pointer set on load,
and reset on image startup
(DO-RECOMPILE)))))
static void L1();
static double LI1();
static void *DLlog;
#define VMB1
#define VMS1
#define VMV1
#define VMR1(VMT1) return(VMT1);
#define VM1 0
static void * VVi[2]={
#define Cdata VV[1]
(void *)(L1),
(void *)(&DLlog)
};
#define VV (VVi)

/tmp/gazonk_27499_0.o: file format elf32-i386

Disassembly of section .text:

00000000 <init_code>:
object
macro_def_int(object);

#include "gazonk_27499_0.h"
void init_code(){do_init((void *)VV);}
0: 55 push %ebp
1: 89 e5 mov %esp,%ebp
3: 83 ec 08 sub $0x8,%esp
6: b8 00 00 00 00 mov $0x0,%eax
b: 89 04 24 mov %eax,(%esp)
e: e8 fc ff ff ff call f <init_code+0xf>
13: c9 leave
14: c3 ret

00000015 <LI1>:
/* local entry for function FOO */

static double LI1(V2)

double V2;
{ VMB1 VMS1 VMV1
15: 55 push %ebp
16: 89 e5 mov %esp,%ebp
18: 83 ec 28 sub $0x28,%esp
1b: 8b 45 08 mov 0x8(%ebp),%eax
1e: 89 45 e8 mov %eax,0xffffffe8(%ebp)
21: 8b 45 0c mov 0xc(%ebp),%eax
24: 89 45 ec mov %eax,0xffffffec(%ebp)
goto TTL;
TTL:;
/*(log X)*/
{double V3;
V3= V2;
27: dd 45 e8 fldl 0xffffffe8(%ebp)
2a: dd 5d f0 fstpl 0xfffffff0(%ebp)
{double V4 = ((double (*)(double))DLlog)(V3);VMR1 ;;***
minimal call overhead possible
2d: a1 00 00 00 00 mov 0x0,%eax
32: dd 45 f0 fldl 0xfffffff0(%ebp)
35: dd 1c 24 fstpl (%esp)
38: ff d0 call *%eax
3a: dd 5d f8 fstpl 0xfffffff8(%ebp)
3d: dd 45 f8 fldl 0xfffffff8(%ebp)
(V4);}}
/* END (log X)*/
}
40: c9 leave
41: c3 ret

00000042 <L1>:
/* global entry for the function FOO */

static void L1()
{ register object *base=vs_base;
42: 55 push %ebp
43: 89 e5 mov %esp,%ebp
45: 53 push %ebx
46: 83 ec 14 sub $0x14,%esp
49: 8b 1d 00 00 00 00 mov 0x0,%ebx
base[0]=make_longfloat(LI1(lf(base[0])));
4f: 8b 03 mov (%ebx),%eax
51: dd 40 04 fldl 0x4(%eax)
54: dd 1c 24 fstpl (%esp)
57: e8 b9 ff ff ff call 15 <LI1>
5c: dd 1c 24 fstpl (%esp)
5f: e8 fc ff ff ff call 60 <L1+0x1e>
64: 89 03 mov %eax,(%ebx)
vs_top=(vs_base=base)+1;
66: 89 1d 00 00 00 00 mov %ebx,0x0
6c: a1 00 00 00 00 mov 0x0,%eax
71: 83 c0 04 add $0x4,%eax
74: a3 00 00 00 00 mov %eax,0x0
}
79: 83 c4 14 add $0x14,%esp
7c: 5b pop %ebx
7d: 5d pop %ebp
7e: c3 ret
NIL

SYSTEM>
=============================================================================

Each code block stores a list of its dlsym function pointers and the
symbol denoting the address to which they must be relocated on each
image startup:

=============================================================================
GCL (GNU Common Lisp) 2.7.0 CLtL1 May 22 2007 16:39:58
Source License: LGPL(gcl,gmp,pargcl), GPL(unexec,bfd,xgcl)
Binary License: GPL due to GPL'ed components: (XGCL 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.

Temporary directory for compiler files set to /tmp/

(in-package 'si)

#<"SYSTEM" package>

SYSTEM>(mdlsym "dgemv_" "libblas.so")

|libblas|:|dgemv_|

SYSTEM>(show-lib-syms)

(LIB:|libblas| 6603144 #<"libblas" package>)
(|libblas|:|dgemv_| 1080730284 NIL)
NIL

SYSTEM>(si::save-system "ff")
***@intech19:/fix/t1/camm/debian/gcl/tmp/tmp/foo1/unixport$ ldd saved_pre_gcl
libSM.so.6 => /usr/lib/libSM.so.6 (0x41443000)
libICE.so.6 => /usr/lib/libICE.so.6 (0x413d9000)
libXmu.so.6 => /usr/lib/libXmu.so.6 (0x413f3000)
libXt.so.6 => /usr/lib/libXt.so.6 (0x412d7000)
libXext.so.6 => /usr/lib/libXext.so.6 (0x41433000)
libXaw.so.7 => /usr/lib/libXaw.so.7 (0x4000f000)
libX11.so.6 => /usr/lib/libX11.so.6 (0x41136000)
libgmp.so.3 => /usr/lib/libgmp.so.3 (0x4006a000)
libreadline.so.5 => /lib/libreadline.so.5 (0x400ad000)
libncurses.so.5 => /lib/libncurses.so.5 (0x41329000)
libm.so.6 => /lib/libm.so.6 (0x4136c000)
libdl.so.2 => /lib/libdl.so.2 (0x4145f000)
libc.so.6 => /lib/libc.so.6 (0x41019000)
libXau.so.6 => /usr/lib/libXau.so.6 (0x41465000)
libXpm.so.4 => /usr/lib/libXpm.so.4 (0x41421000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x41458000)
/lib/ld-linux.so.2 (0x41000000)
***@intech19:/fix/t1/camm/debian/gcl/tmp/tmp/foo1/unixport$ ldd ff
libSM.so.6 => /usr/lib/libSM.so.6 (0x41443000)
libICE.so.6 => /usr/lib/libICE.so.6 (0x413d9000)
libXmu.so.6 => /usr/lib/libXmu.so.6 (0x413f3000)
libXt.so.6 => /usr/lib/libXt.so.6 (0x412d7000)
libXext.so.6 => /usr/lib/libXext.so.6 (0x41433000)
libXaw.so.7 => /usr/lib/libXaw.so.7 (0x4000f000)
libX11.so.6 => /usr/lib/libX11.so.6 (0x41136000)
libgmp.so.3 => /usr/lib/libgmp.so.3 (0x4006a000)
libreadline.so.5 => /lib/libreadline.so.5 (0x400ad000)
libncurses.so.5 => /lib/libncurses.so.5 (0x41329000)
libm.so.6 => /lib/libm.so.6 (0x4136c000)
libdl.so.2 => /lib/libdl.so.2 (0x4145f000)
libc.so.6 => /lib/libc.so.6 (0x41019000)
libXau.so.6 => /usr/lib/libXau.so.6 (0x41465000)
libXpm.so.4 => /usr/lib/libXpm.so.4 (0x41421000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x41458000)
/lib/ld-linux.so.2 (0x41000000)
./ff
GCL (GNU Common Lisp) 2.7.0 CLtL1 May 22 2007 16:39:58
Source License: LGPL(gcl,gmp,pargcl), GPL(unexec,bfd,xgcl)
Binary License: GPL due to GPL'ed components: (XGCL 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.

Temporary directory for compiler files set to /tmp/

(in-package 'si)

#<"SYSTEM" package>

SYSTEM>(show-lib-syms)

(LIB:|libblas| 6800592 #<"libblas" package>)
(|libblas|:|dgemv_| 1080730284 NIL)
NIL

SYSTEM>
=============================================================================

Suggestions most welcome. One thing I'm not planning at the moment is
"deregistering" dlopened libraries, but this is open to consultation.

Given that it seems that most reasonable way for Axiom is to use
existiong C code. There is are drawbacks: we need to interface to
C and typical Lisp implementation can only interface to shared
libraries via dlopen. So we need to handle issues related to making
shared library.

Hopefully, the above will be useful. It appears that libdl is quite
portable, but may require cygwin.

But AFAICS we will need C interface anyway, so we need to resolve
problems of C interface and shared libraries.

Thoughts most appreciated. The above was primarily motivated to
obsolete the plt.c mechanism, which appears fragile and is currently
broken on mips for example. But the implications for lisp extensions
appear quite attractive.

Take care,

[Gernot Hueber]

Dear Camm,

Great! Many thanks for working on the issue of calling shared lib functions
from gcl. I have struggled some time ago with this issue, with moderate
success.
Actually, I tried to call a shared lib function from Aldor/Axiom via gcl.

My trails were based und the gcl-loader package, which looks quite similar
to your way of importing and calling C libs.

How can I use your functions (BTW I am FreeBSD user - unfortunately the
ports tree offers only 2.6.7). Yet I had no luck (and little time) to use a
more current version of gcl.

Actually the main problem of calling external C functions was to pass
variables from and to gcl. As of gsl (gnu scientific library), there are
numerous variations - int, float, double, pointers to any of them, arrays,
multi dimensional array, ...
Can you assist me with defining how to use all of these types properly?

Many thanks

Gernot

Post by Camm Maguire
Greetings, and thanks for including me in this thread. Unfortunately,
axiom-developer mail is still not getting through my ISP for some
reason.

In my private tree Axiom is nicely working on top of sbcl and clisp.
The remaining known problems are sockets and writeablep function.

Great! It is always nice to have more options. But I do have a
general question here. Work in this direction obviously makes sense
if 1) GCL is currently deficient for axiom use in some regard and 2)
we have difficulties addressing said deficiencies via changes to GCL.
If both of these are true, I would greatly appreciate you and/or
others letting me know the details, as it is and has been a goal of
mine to ensure that gcl remains optimal for axiom use. As in the
past, I pledge that if axiom needs anything from GCL which is
currently unavailable, I will make sure said functionality works in
GCL. What I would like to avoid is chasing every random package which
no one has any serious intention of deploying in a real shipped
program.
If either 1) or 2) above are not true, may I suggest that significant
work in this regard is a distraction from the real goals of the axiom
project -- to deliver the best symbolic algebra package in the open
source world. In our company, we manage approx. $70 billion dollars
using open source software and code we've written on top of it. We
would get nowhere if we spent any time at all making sure our code
works both on gcc and icc, etc. Rather we pick a platform that
appears flexible, stick to it, and get the results we want out of it
quickly. We do almost everything using gcc, gdb and emacs, not
because they are the slickest or hottest or even fastest, but because
they have good portable performance, they can be changed at the source
level if necessary, and they will be available forever, making our
payoff period for the learning curve essentially last a whole
lifetime.
I'd really love to help the axiom project by offering a similar setup
for use by the developers. Even one better -- axiom has its own
personal compiler developer to tailor the compiler to its needs if
necessary. This only pays off if my work on GCL frees axiom developer
hours for work on the core system.

Also, currently for clisp I need cl-fad library, which I consider
problematic. Namely, cl-fad does not work with gcl, so for gcl
we need separate code. We need only few functions from cl-fad,
to work around clisp weirdness (clisp makes strong distinction
between paths to files and paths to directories and refuses
to perform file operations on directories). So my current plan
is to eliminate use of cl-fad and provide the needed functions
directly. Related problem is performing operations on

I think this is a wise choice, but needless to say, if you need
cl-fad, I'll make sure it works.
I must say I'm less than enamored with the cl-foo library development
model. Its source level as opposed to binary, and there is no shared
library memory savings. Beyond which, there really doesn't appear to
be much of anything available which is not provided elsewhere in
faster, smaller, shareable C libraries, though I haven't made any
exhaustive study here.
I love lisp, obviously, and primarily for the magnitude and quality of
AI-type code which has been developed and has recently entered into
the open source world. But lisp is not going to compete with perl,
python, java, or C, IMHO. The primary goal should be in fulfilling
the ansi-standard and supporting applications from the past, while
offering non-standard interfaces to newer functionality in external
shared C libraries. Do we really think cl-fad has a thirty year
lifetime ahead of it? How will we coordinate with all these cl-
library developers external to the axiom project when they move on to
other things in life? Will we read all their source and maintain it
ourselves?
Thankfully, the ansi-standard is written down, and with all its warts,
will last > 30 years, IMHO. If we need items outside the standard, we
should rely on implementations in C shared libraries, as these will
have a longer lifetime and in general will be technically superior.
We should then pick one again non-standard glue between lisp and C,
and stick to it, and call all the shared library routines from within
lisp. These of course are just my opinions.
It is good you brought this up, as gclcvs has followed clisp-style
directory usage, at least at present. We can undo this if required.
Pathnames with spaces are also fully supported in gclcvs. These can
be backported to 2.6.8pre if necessary.

directories -- to gain portability between Unix and Windows
I tried to use Lisp code. But each Lisp is doing them
differently (and apparently some operations sometimes are missing).
So I got a maze of conditionals over Lisp implementations.
Looking at resulting code I feel that it is better to
call operationg system utilities and have just use
conditionals to choose between Unix and Windows versions
of file utilities.

In C, we call this #ifdef hell. There is no good reason for it, in my
experience.

Concerning sockets, we need Unix domain sockets and select. It
seems that clisp provide both, but to get Unix domain sockets
one needs version including rawsock module, which is not included
in default clisp configuration.
sbcl offers sb-bsd-sockets which seem to have basic functions,
but I do not see select.
gcl documentation suggest that Unix domain sockets are unsupported.
Also, I see no traces of select.

SYSTEM>(walker::macroexpand-all '(p-let ((x (foo)) (y (bar))) (+ x y)))
(LET* (X Y)
(LET* ((#:G2306 3)
(#:G2301 (LIST (LET ((#:G2310 (FORK)))
(IF (EQL 0 (CAR #:G2310))
(PROGN
(WRITE-POINTER-OBJECT (FOO) #:G2310)
(BYE))
#:G2310))
(LET ((#:G2311 (FORK)))
(IF (EQL 0 (CAR #:G2311))
(PROGN
(WRITE-POINTER-OBJECT (BAR) #:G2311)
(BYE))
#:G2311)))))
(DECLARE ((INTEGER 0 3) #:G2306))
(UNWIND-PROTECT
(DO () ((= #:G2306 0))
(LET ((#:G2309 (SELECT-READ #:G2301 -1)))
(DECLARE ((INTEGER 0 3) #:G2309))
(DO ((#:G2299 0 (1+ #:G2299)) (#:G2307 1 (ASH #:G2307 1))
(#:G2308 #:G2301 (CDR #:G2308)))
((= #:G2299 2) (SETQ #:G2306 (LOGANDC2 #:G2306 #:G2309)))
(DECLARE ((INTEGER 0 2) #:G2299) ((INTEGER 1 4) #:G2307))
(IF (/= 0 (LOGAND #:G2307 #:G2309))
(PROGN
(LET ((#:G2300 (READ-POINTER-OBJECT (CAR #:G2308))))
(LET ((#:G2313 #:G2299))
(IF (EQL #:G2313 '0) (PROGN (SETQ X #:G2300))
(IF (EQL #:G2313 '1) (PROGN (SETQ Y #:G2300))
NIL)))))))))
(DO* ((#:G2314 #:G2301 (CDR #:G2314)))
((ENDP #:G2314) (CDR #:G2301))
(LET ((#:G2301 (CAR #:G2314))) (KILL #:G2301 0)))))
(+ X Y))
This can be adapted to whatever other interface one may desire.
Do you mean dgram (UDP) sockets? If you specify the interface, we'll
put them in.

There is "portable" cl-sockets library but the manual says it supports
Allegro CL, sbcl and cmucl. The manual does not say anything about
Unix domain sockets or select. The manual says that cl-sockets requires
UFFI, so presumably cl-sockets works on top of "portable" C library.
In short my finding is that portable Lisp sockets are a myth: all
implementations provide different interface and frequently miss
some essential services. People who want portablity between Lisp
implementations interface to C.

Agreed!
I've been working on a better interface to external shared C
libraries for GCL. The issue, as you may recall, is that GCL-compiled
code referring to external shared function addresses are statically
relocated to the value of said address at the time the .o file is
loaded. If one then saves the image and re-executes, the function is
likely in a different place.
I've figured out a persistent solution using dlopen. Still working on
the precise interface, but you can see the idea here. Comments are
=============================================================================
GCL (GNU Common Lisp) 2.7.0 CLtL1 May 22 2007 16:39:58
Source License: LGPL(gcl,gmp,pargcl), GPL(unexec,bfd,xgcl)
Binary License: GPL due to GPL'ed components: (XGCL 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.
Temporary directory for compiler files set to /tmp/

(in-package 'si)

#<"SYSTEM" package>
SYSTEM>(show-lib-syms)
NIL
SYSTEM>(mdlsym "cosf" "libm.so")
|libm|:|cosf| ;;*** package autmatically created, lib automatically dlopened
SYSTEM>(mdlsym "dgemv_" "libblas.so")
|libblas|:|dgemv_|
SYSTEM>(show-lib-syms)
(LIB:|libblas| 6730696 #<"libblas" package>) ;;*** value of package
symbol is dlopen handle
(|libblas|:|dgemv_| 1080730284 NIL) ;;*** value of C symbol
is current address,
reset on system startup
(LIB:|libm| 1074174504 #<"libm" package>)
(|libm|:|cosf| 1094172320 NIL)
NIL
SYSTEM>(dladdr |libblas|:|dgemv_| ;;*** exact path resolution
)
#P"/usr/lib/atlas/sse2/libblas.so"
SYSTEM>(system "cat /tmp/dl2.l")
(in-package "libm")
(eval-when
(compile eval)
(defmacro defdl (sym)
(let* ((sym (si::mdlsym (string-downcase sym) "libm.so"))
(fsym (si::mdlsym (concatenate 'string (string sym) "f") "libm.so")))
`(progn
(defun ,sym (x) (si::dl-double-to-double ',sym x))
(defun ,fsym (x) (si::dl-float-to-float ',fsym x))))))
(defdl exp)
(defdl log)
(defdl sin)
(defdl cos)
(defdl tan)
(defdl asin)
(defdl acos)
(defdl atan)
(defdl sinh)
(defdl cosh)
(defdl tanh)
(defdl asinh)
(defdl acosh)
(defdl atanh)
SYSTEM>(load "/tmp/dl2.l")
;; Loading /tmp/dl2.l
;; Finished loading /tmp/dl2.l
T
SYSTEM>(show-lib-syms)
(LIB:|libblas| 6730696 #<"libblas" package>)
(|libblas|:|dgemv_| 1080730284 NIL)
(LIB:|libm| 1074174504 #<"libm" package>)
(|libm|:|atan| 1094141472
#<interpreted-function (LAMBDA-BLOCK |libm|:|atan| (|libm|::X)
(DL-DOUBLE-TO-DOUBLE '|libm|:|atan| ;;***
standard call to address denoted
by symbol value, one double arg, returning one double
|libm|::X))>)
(|libm|:|acosh| 1094146080
#<interpreted-function (LAMBDA-BLOCK |libm|:|acosh| (|libm|::X)
(DL-DOUBLE-TO-DOUBLE '|libm|:|acosh|
|libm|::X))>)
(|libm|:|expf| 1094176432
#<interpreted-function (LAMBDA-BLOCK |libm|:|expf| (|libm|::X)
(DL-FLOAT-TO-FLOAT '|libm|:|expf|
|libm|::X))>)
(|libm|:|atanhf| 1094176064
#<interpreted-function (LAMBDA-BLOCK |libm|:|atanhf| (|libm|::X)
(DL-FLOAT-TO-FLOAT '|libm|:|atanhf|
|libm|::X))>)
(|libm|:|acosf| 1094175504
#<interpreted-function (LAMBDA-BLOCK |libm|:|acosf| (|libm|::X)
(DL-FLOAT-TO-FLOAT '|libm|:|acosf|
|libm|::X))>)
(|libm|:|exp| 1094146864
#<interpreted-function (LAMBDA-BLOCK |libm|:|exp| (|libm|::X)
(DL-DOUBLE-TO-DOUBLE '|libm|:|exp|
|libm|::X))>)
(|libm|:|atanh| 1094146512
#<interpreted-function (LAMBDA-BLOCK |libm|:|atanh| (|libm|::X)
(DL-DOUBLE-TO-DOUBLE '|libm|:|atanh|
|libm|::X))>)
(|libm|:|cosh| 1094146672
#<interpreted-function (LAMBDA-BLOCK |libm|:|cosh| (|libm|::X)
(DL-DOUBLE-TO-DOUBLE '|libm|:|cosh|
|libm|::X))>)
(|libm|:|cosf| 1094172320
#<interpreted-function (LAMBDA-BLOCK |libm|:|cosf| (|libm|::X)
(DL-FLOAT-TO-FLOAT '|libm|:|cosf|
|libm|::X))>)
(|libm|:|atanf| 1094172032
#<interpreted-function (LAMBDA-BLOCK |libm|:|atanf| (|libm|::X)
(DL-FLOAT-TO-FLOAT '|libm|:|atanf|
|libm|::X))>)
(|libm|:|cos| 1094141792
#<interpreted-function (LAMBDA-BLOCK |libm|:|cos| (|libm|::X)
(DL-DOUBLE-TO-DOUBLE '|libm|:|cos|
|libm|::X))>)
(|libm|:|tanh| 1094145584
#<interpreted-function (LAMBDA-BLOCK |libm|:|tanh| (|libm|::X)
(DL-DOUBLE-TO-DOUBLE '|libm|:|tanh|
|libm|::X))>)
(|libm|:|tanf| 1094175168
#<interpreted-function (LAMBDA-BLOCK |libm|:|tanf| (|libm|::X)
(DL-FLOAT-TO-FLOAT '|libm|:|tanf|
|libm|::X))>)
(|libm|:|tan| 1094145536
#<interpreted-function (LAMBDA-BLOCK |libm|:|tan| (|libm|::X)
(DL-DOUBLE-TO-DOUBLE '|libm|:|tan|
|libm|::X))>)
(|libm|:|sinh| 1094150832
#<interpreted-function (LAMBDA-BLOCK |libm|:|sinh| (|libm|::X)
(DL-DOUBLE-TO-DOUBLE '|libm|:|sinh|
|libm|::X))>)
(|libm|:|asin| 1094146208
#<interpreted-function (LAMBDA-BLOCK |libm|:|asin| (|libm|::X)
(DL-DOUBLE-TO-DOUBLE '|libm|:|asin|
|libm|::X))>)
(|libm|:|sinf| 1094175120
#<interpreted-function (LAMBDA-BLOCK |libm|:|sinf| (|libm|::X)
(DL-FLOAT-TO-FLOAT '|libm|:|sinf|
|libm|::X))>)
(|libm|:|sin| 1094145488
#<interpreted-function (LAMBDA-BLOCK |libm|:|sin| (|libm|::X)
(DL-DOUBLE-TO-DOUBLE '|libm|:|sin|
|libm|::X))>)
(|libm|:|coshf| 1094176224
#<interpreted-function (LAMBDA-BLOCK |libm|:|coshf| (|libm|::X)
(DL-FLOAT-TO-FLOAT '|libm|:|coshf|
|libm|::X))>)
(|libm|:|tanhf| 1094175216
#<interpreted-function (LAMBDA-BLOCK |libm|:|tanhf| (|libm|::X)
(DL-FLOAT-TO-FLOAT '|libm|:|tanhf|
|libm|::X))>)
(|libm|:|acoshf| 1094175632
#<interpreted-function (LAMBDA-BLOCK |libm|:|acoshf| (|libm|::X)
(DL-FLOAT-TO-FLOAT '|libm|:|acoshf|
|libm|::X))>)
(|libm|:|asinh| 1094141232
#<interpreted-function (LAMBDA-BLOCK |libm|:|asinh| (|libm|::X)
(DL-DOUBLE-TO-DOUBLE '|libm|:|asinh|
|libm|::X))>)
(|libm|:|asinhf| 1094171792
#<interpreted-function (LAMBDA-BLOCK |libm|:|asinhf| (|libm|::X)
(DL-FLOAT-TO-FLOAT '|libm|:|asinhf|
|libm|::X))>)
(|libm|:|sinhf| 1094180368
#<interpreted-function (LAMBDA-BLOCK |libm|:|sinhf| (|libm|::X)
(DL-FLOAT-TO-FLOAT '|libm|:|sinhf|
|libm|::X))>)
(|libm|:|asinf| 1094175760
#<interpreted-function (LAMBDA-BLOCK |libm|:|asinf| (|libm|::X)
(DL-FLOAT-TO-FLOAT '|libm|:|asinf|
|libm|::X))>)
(|libm|:|logf| 1094179104
#<interpreted-function (LAMBDA-BLOCK |libm|:|logf| (|libm|::X)
(DL-FLOAT-TO-FLOAT '|libm|:|logf|
|libm|::X))>)
(|libm|:|log| 1094149536
#<interpreted-function (LAMBDA-BLOCK |libm|:|log| (|libm|::X)
(DL-DOUBLE-TO-DOUBLE '|libm|:|log|
|libm|::X))>)
(|libm|:|acos| 1094145952
#<interpreted-function (LAMBDA-BLOCK |libm|:|acos| (|libm|::X)
(DL-DOUBLE-TO-DOUBLE '|libm|:|acos|
|libm|::X))>)
NIL
SYSTEM>(compile-file "/tmp/dl2.l")
;; Compiling /tmp/dl2.l.
;; End of Pass 1.
;; End of Pass 2.
;; OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3, (Debug quality ignored)
;; Finished compiling /tmp/dl2.o.
#P"/tmp/dl2.o"
NIL
NIL
SYSTEM>(load *)
;; Loading /tmp/dl2.o
;; start address -T 0x66f480 ;; Finished loading /tmp/dl2.o
1460
SYSTEM>(show-lib-syms)
(LIB:|libblas| 6730696 #<"libblas" package>)
(|libblas|:|dgemv_| 1080730284 NIL)
(LIB:|libm| 1074174504 #<"libm" package>)
(|libm|:|atan| 1094141472 #<compiled-function |libm|:|atan|>)
(|libm|:|acosh| 1094146080 #<compiled-function |libm|:|acosh|>)
(|libm|:|expf| 1094176432 #<compiled-function |libm|:|expf|>)
(|libm|:|atanhf| 1094176064 #<compiled-function |libm|:|atanhf|>)
(|libm|:|acosf| 1094175504 #<compiled-function |libm|:|acosf|>)
(|libm|:|exp| 1094146864 #<compiled-function |libm|:|exp|>)
(|libm|:|atanh| 1094146512 #<compiled-function |libm|:|atanh|>)
(|libm|:|cosh| 1094146672 #<compiled-function |libm|:|cosh|>)
(|libm|:|cosf| 1094172320 #<compiled-function |libm|:|cosf|>)
(|libm|:|atanf| 1094172032 #<compiled-function |libm|:|atanf|>)
(|libm|:|cos| 1094141792 #<compiled-function |libm|:|cos|>)
(|libm|:|tanh| 1094145584 #<compiled-function |libm|:|tanh|>)
(|libm|:|tanf| 1094175168 #<compiled-function |libm|:|tanf|>)
(|libm|:|tan| 1094145536 #<compiled-function |libm|:|tan|>)
(|libm|:|sinh| 1094150832 #<compiled-function |libm|:|sinh|>)
(|libm|:|asin| 1094146208 #<compiled-function |libm|:|asin|>)
(|libm|:|sinf| 1094175120 #<compiled-function |libm|:|sinf|>)
(|libm|:|sin| 1094145488 #<compiled-function |libm|:|sin|>)
(|libm|:|coshf| 1094176224 #<compiled-function |libm|:|coshf|>)
(|libm|:|tanhf| 1094175216 #<compiled-function |libm|:|tanhf|>)
(|libm|:|acoshf| 1094175632 #<compiled-function |libm|:|acoshf|>)
(|libm|:|asinh| 1094141232 #<compiled-function |libm|:|asinh|>)
(|libm|:|asinhf| 1094171792 #<compiled-function |libm|:|asinhf|>)
(|libm|:|sinhf| 1094180368 #<compiled-function |libm|:|sinhf|>)
(|libm|:|asinf| 1094175760 #<compiled-function |libm|:|asinf|>)
(|libm|:|logf| 1094179104 #<compiled-function |libm|:|logf|>)
(|libm|:|log| 1094149536 #<compiled-function |libm|:|log|>)
(|libm|:|acos| 1094145952 #<compiled-function |libm|:|acos|>)
NIL
SYSTEM>(disassemble '|libm|:|log|)
;; Compiling /tmp/gazonk_27499_0.lsp.
;; End of Pass 1.
;; End of Pass 2.
;; OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3, (Debug quality ignored)
;; Finished compiling /tmp/gazonk_27499_0.o.
#include "gazonk_27499_0.h"
void init_code(){do_init((void *)VV);}
/* local entry for function CMP-ANON */
static object LI1(V2)
object V2;
{ VMB1 VMS1 VMV1
goto TTL;
TTL:; ;;**** fast link C call to generic interface
{object V3 = (/* DL-DOUBLE-TO-DOUBLE */(*LnkLI1)(((object)VV[0]),(V2)));VMR1
(V3);}
return Cnil;
}
static object LnkTLI1(object first,...){object V1;va_list ap;va_start(ap,first);V1=(object )call_proc_new(((object)VV[1]),0,0,(void **)(void *)&LnkLI1,2,first,ap);va_end(ap);return V1;} /* DL-DOUBLE-TO-DOUBLE */
#(#(log DL-DOUBLE-TO-DOUBLE
(%INIT
. #((LET ((*DISABLE-RECOMPILE* T))
(MFSFUN 'CMP-ANON 0 1 0)
(ADD-HASH 'CMP-ANON '((T) T)
'((DL-DOUBLE-TO-DOUBLE (T T) T))
SYSTEMCOMPILERCMP-ANON /!.log DL-DOUBLE-TO-DOUBL,QUOTE1-
'/tmp/gazonk_27499_0.lsp))
(DO-RECOMPILE)))))
static object LI1();
#define VMB1
#define VMS1
#define VMV1
#define VMR1(VMT1) return(VMT1);
#define VM1 0
static void * VVi[3]={
#define Cdata VV[2]
(void *)(LI1)
};
#define VV (VVi)
static object LnkTLI1(object,...);
static object (*LnkLI1)() = (object (*)()) LnkTLI1;
/tmp/gazonk_27499_0.o: file format elf32-i386
object
macro_def_int(object);
#include "gazonk_27499_0.h"
void init_code(){do_init((void *)VV);}
0: 55 push %ebp
1: 89 e5 mov %esp,%ebp
3: 83 ec 08 sub $0x8,%esp
6: b8 00 00 00 00 mov $0x0,%eax
b: 89 04 24 mov %eax,(%esp)
e: e8 fc ff ff ff call f <init_code+0xf>
13: c9 leave
14: c3 ret
/* local entry for function CMP-ANON */
static object LI1(V2)
object V2;
{ VMB1 VMS1 VMV1
15: 55 push %ebp
16: 89 e5 mov %esp,%ebp
18: 83 ec 18 sub $0x18,%esp
goto TTL;
TTL:;
{object V3 = (/* DL-DOUBLE-TO-DOUBLE */(*LnkLI1)(((object)VV[0]),(V2)));VMR1
1b: 8b 0d 0c 00 00 00 mov 0xc,%ecx
21: a1 00 00 00 00 mov 0x0,%eax
26: 89 c2 mov %eax,%edx
28: 8b 45 08 mov 0x8(%ebp),%eax
2b: 89 44 24 04 mov %eax,0x4(%esp)
2f: 89 14 24 mov %edx,(%esp)
32: ff d1 call *%ecx
34: 89 45 fc mov %eax,0xfffffffc(%ebp)
37: 8b 45 fc mov 0xfffffffc(%ebp),%eax
(V3);}
return Cnil;
}
3a: c9 leave
3b: c3 ret
static object LnkTLI1(object first,...){object V1;va_list ap;va_start(ap,first);V1=(object )call_proc_new(((object)VV[1]),0,0,(void **)(void *)&LnkLI1,2,first,ap);va_end(ap);return V1;} /* DL-DOUBLE-TO-DOUBLE */
3c: 55 push %ebp
3d: 89 e5 mov %esp,%ebp
3f: 53 push %ebx
40: 83 ec 34 sub $0x34,%esp
43: 8d 45 0c lea 0xc(%ebp),%eax
46: 89 45 f4 mov %eax,0xfffffff4(%ebp)
49: 8b 55 f4 mov 0xfffffff4(%ebp),%edx
4c: b9 0c 00 00 00 mov $0xc,%ecx
51: a1 04 00 00 00 mov 0x4,%eax
56: 89 c3 mov %eax,%ebx
58: 89 54 24 18 mov %edx,0x18(%esp)
5c: 8b 45 08 mov 0x8(%ebp),%eax
5f: 89 44 24 14 mov %eax,0x14(%esp)
63: c7 44 24 10 02 00 00 movl $0x2,0x10(%esp)
6a: 00
6b: 89 4c 24 0c mov %ecx,0xc(%esp)
6f: c7 44 24 08 00 00 00 movl $0x0,0x8(%esp)
76: 00
77: c7 44 24 04 00 00 00 movl $0x0,0x4(%esp)
7e: 00
7f: 89 1c 24 mov %ebx,(%esp)
82: e8 fc ff ff ff call 83 <LnkTLI1+0x47>
87: 89 45 f8 mov %eax,0xfffffff8(%ebp)
8a: 8b 45 f8 mov 0xfffffff8(%ebp),%eax
8d: 83 c4 34 add $0x34,%esp
90: 5b pop %ebx
91: 5d pop %ebp
92: c3 ret
NIL
SYSTEM>(defun foo (x) (declare (long-float x)) (|libm|:|log| x))
FOO
SYSTEM>(disassemble 'foo)
;; Compiling /tmp/gazonk_27499_0.lsp.
;; End of Pass 1.
;; End of Pass 2.
;; OPTIMIZE levels: Safety=0 (No runtime error checking), Space=0, Speed=3, (Debug quality ignored)
;; Finished compiling /tmp/gazonk_27499_0.o.
#include "gazonk_27499_0.h"
void init_code(){do_init((void *)VV);}
/* local entry for function FOO */
static double LI1(V2)
double V2;
{ VMB1 VMS1 VMV1
goto TTL;
TTL:;
/*(log X)*/
{double V3;
V3= V2; ;;*** Automatic inlining through function pointer
{double V4 = ((double (*)(double))DLlog)(V3);VMR1
(V4);}}
/* END (log X)*/
}
/* global entry for the function FOO */
static void L1()
{ register object *base=vs_base;
base[0]=make_longfloat(LI1(lf(base[0])));
vs_top=(vs_base=base)+1;
}
#(#(log
(%INIT
. #((LET ((*DISABLE-RECOMPILE* T))
(MF 'FOO 0)
(ADD-HASH 'FOO '((LONG-FLOAT) LONG-FLOAT) '((log (T) T))
LISPLAMBDA!
!,DECLAR,OPTIMIZ,SAFETY
libmlog-
'/tmp/gazonk_27499_0.lsp)
(MDL 'log 'libm 1)) ;;*** function pointer set on load,
and reset on image startup
(DO-RECOMPILE)))))
static void L1();
static double LI1();
static void *DLlog;
#define VMB1
#define VMS1
#define VMV1
#define VMR1(VMT1) return(VMT1);
#define VM1 0
static void * VVi[2]={
#define Cdata VV[1]
(void *)(L1),
(void *)(&DLlog)
};
#define VV (VVi)
/tmp/gazonk_27499_0.o: file format elf32-i386
object
macro_def_int(object);
#include "gazonk_27499_0.h"
void init_code(){do_init((void *)VV);}
0: 55 push %ebp
1: 89 e5 mov %esp,%ebp
3: 83 ec 08 sub $0x8,%esp
6: b8 00 00 00 00 mov $0x0,%eax
b: 89 04 24 mov %eax,(%esp)
e: e8 fc ff ff ff call f <init_code+0xf>
13: c9 leave
14: c3 ret
/* local entry for function FOO */
static double LI1(V2)
double V2;
{ VMB1 VMS1 VMV1
15: 55 push %ebp
16: 89 e5 mov %esp,%ebp
18: 83 ec 28 sub $0x28,%esp
1b: 8b 45 08 mov 0x8(%ebp),%eax
1e: 89 45 e8 mov %eax,0xffffffe8(%ebp)
21: 8b 45 0c mov 0xc(%ebp),%eax
24: 89 45 ec mov %eax,0xffffffec(%ebp)
goto TTL;
TTL:;
/*(log X)*/
{double V3;
V3= V2;
27: dd 45 e8 fldl 0xffffffe8(%ebp)
2a: dd 5d f0 fstpl 0xfffffff0(%ebp)
{double V4 = ((double (*)(double))DLlog)(V3);VMR1 ;;***
minimal call overhead possible
2d: a1 00 00 00 00 mov 0x0,%eax
32: dd 45 f0 fldl 0xfffffff0(%ebp)
35: dd 1c 24 fstpl (%esp)
38: ff d0 call *%eax
3a: dd 5d f8 fstpl 0xfffffff8(%ebp)
3d: dd 45 f8 fldl 0xfffffff8(%ebp)
(V4);}}
/* END (log X)*/
}
40: c9 leave
41: c3 ret
/* global entry for the function FOO */
static void L1()
{ register object *base=vs_base;
42: 55 push %ebp
43: 89 e5 mov %esp,%ebp
45: 53 push %ebx
46: 83 ec 14 sub $0x14,%esp
49: 8b 1d 00 00 00 00 mov 0x0,%ebx
base[0]=make_longfloat(LI1(lf(base[0])));
4f: 8b 03 mov (%ebx),%eax
51: dd 40 04 fldl 0x4(%eax)
54: dd 1c 24 fstpl (%esp)
57: e8 b9 ff ff ff call 15 <LI1>
5c: dd 1c 24 fstpl (%esp)
5f: e8 fc ff ff ff call 60 <L1+0x1e>
64: 89 03 mov %eax,(%ebx)
vs_top=(vs_base=base)+1;
66: 89 1d 00 00 00 00 mov %ebx,0x0
6c: a1 00 00 00 00 mov 0x0,%eax
71: 83 c0 04 add $0x4,%eax
74: a3 00 00 00 00 mov %eax,0x0
}
79: 83 c4 14 add $0x14,%esp
7c: 5b pop %ebx
7d: 5d pop %ebp
7e: c3 ret
NIL
SYSTEM>
=============================================================================
Each code block stores a list of its dlsym function pointers and the
symbol denoting the address to which they must be relocated on each
=============================================================================
GCL (GNU Common Lisp) 2.7.0 CLtL1 May 22 2007 16:39:58
Source License: LGPL(gcl,gmp,pargcl), GPL(unexec,bfd,xgcl)
Binary License: GPL due to GPL'ed components: (XGCL 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.
Temporary directory for compiler files set to /tmp/

(in-package 'si)

#<"SYSTEM" package>
SYSTEM>(mdlsym "dgemv_" "libblas.so")
|libblas|:|dgemv_|
SYSTEM>(show-lib-syms)
(LIB:|libblas| 6603144 #<"libblas" package>)
(|libblas|:|dgemv_| 1080730284 NIL)
NIL
SYSTEM>(si::save-system "ff")
libSM.so.6 => /usr/lib/libSM.so.6 (0x41443000)
libICE.so.6 => /usr/lib/libICE.so.6 (0x413d9000)
libXmu.so.6 => /usr/lib/libXmu.so.6 (0x413f3000)
libXt.so.6 => /usr/lib/libXt.so.6 (0x412d7000)
libXext.so.6 => /usr/lib/libXext.so.6 (0x41433000)
libXaw.so.7 => /usr/lib/libXaw.so.7 (0x4000f000)
libX11.so.6 => /usr/lib/libX11.so.6 (0x41136000)
libgmp.so.3 => /usr/lib/libgmp.so.3 (0x4006a000)
libreadline.so.5 => /lib/libreadline.so.5 (0x400ad000)
libncurses.so.5 => /lib/libncurses.so.5 (0x41329000)
libm.so.6 => /lib/libm.so.6 (0x4136c000)
libdl.so.2 => /lib/libdl.so.2 (0x4145f000)
libc.so.6 => /lib/libc.so.6 (0x41019000)
libXau.so.6 => /usr/lib/libXau.so.6 (0x41465000)
libXpm.so.4 => /usr/lib/libXpm.so.4 (0x41421000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x41458000)
/lib/ld-linux.so.2 (0x41000000)
libSM.so.6 => /usr/lib/libSM.so.6 (0x41443000)
libICE.so.6 => /usr/lib/libICE.so.6 (0x413d9000)
libXmu.so.6 => /usr/lib/libXmu.so.6 (0x413f3000)
libXt.so.6 => /usr/lib/libXt.so.6 (0x412d7000)
libXext.so.6 => /usr/lib/libXext.so.6 (0x41433000)
libXaw.so.7 => /usr/lib/libXaw.so.7 (0x4000f000)
libX11.so.6 => /usr/lib/libX11.so.6 (0x41136000)
libgmp.so.3 => /usr/lib/libgmp.so.3 (0x4006a000)
libreadline.so.5 => /lib/libreadline.so.5 (0x400ad000)
libncurses.so.5 => /lib/libncurses.so.5 (0x41329000)
libm.so.6 => /lib/libm.so.6 (0x4136c000)
libdl.so.2 => /lib/libdl.so.2 (0x4145f000)
libc.so.6 => /lib/libc.so.6 (0x41019000)
libXau.so.6 => /usr/lib/libXau.so.6 (0x41465000)
libXpm.so.4 => /usr/lib/libXpm.so.4 (0x41421000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x41458000)
/lib/ld-linux.so.2 (0x41000000)
./ff
GCL (GNU Common Lisp) 2.7.0 CLtL1 May 22 2007 16:39:58
Source License: LGPL(gcl,gmp,pargcl), GPL(unexec,bfd,xgcl)
Binary License: GPL due to GPL'ed components: (XGCL 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.
Temporary directory for compiler files set to /tmp/

(in-package 'si)

#<"SYSTEM" package>
SYSTEM>(show-lib-syms)
(LIB:|libblas| 6800592 #<"libblas" package>)
(|libblas|:|dgemv_| 1080730284 NIL)
NIL
SYSTEM>
=============================================================================
Suggestions most welcome. One thing I'm not planning at the moment is
"deregistering" dlopened libraries, but this is open to consultation.

Given that it seems that most reasonable way for Axiom is to use
existiong C code. There is are drawbacks: we need to interface to
C and typical Lisp implementation can only interface to shared
libraries via dlopen. So we need to handle issues related to making
shared library.

Hopefully, the above will be useful. It appears that libdl is quite
portable, but may require cygwin.

But AFAICS we will need C interface anyway, so we need to resolve
problems of C interface and shared libraries.

Thoughts most appreciated. The above was primarily motivated to
obsolete the plt.c mechanism, which appears fragile and is currently
broken on mips for example. But the implications for lisp extensions
appear quite attractive.
Take care,
--
==========================================================================
"The earth is but one country, and mankind its citizens." -- Baha'u'llah
_______________________________________________
Axiom-developer mailing list
http://lists.nongnu.org/mailman/listinfo/axiom-developer

[C Y]

Post by Camm Maguire
if 1) GCL is currently deficient for axiom use in some regard and 2)
we have difficulties addressing said deficiencies via changes to GCL.
If both of these are true, I would greatly appreciate you and/or
others letting me know the details, as it is and has been a goal of
mine to ensure that gcl remains optimal for axiom use.

Camm, while it cannot (yet) be said to be part of Axiom, the cl-web
code does not work on GCL at the moment. There are two obvious things
I know of and probably others I don't (yet): 1) read-sequence doesn't
seem to be present in GCL 2) I'm using trivial-utf-8 for string->array
and array->string functionality, and I don't know how or if that would
work on GCL.

Post by Camm Maguire
I must say I'm less than enamored with the cl-foo library development
model. Its source level as opposed to binary, and there is no shared
library memory savings. Beyond which, there really doesn't appear to
be much of anything available which is not provided elsewhere in
faster, smaller, shareable C libraries, though I haven't made any
exhaustive study here.

I'm sure there are a lot of opinions on this one. I'm not quite clear
as to why the source level is objectionable (don't we simply compile it
at build time anyway?). I like the all-lisp solution for the simple
reason that it avoids any reliance on the behavior of the C language or
compilers, but that's just me.

Post by Camm Maguire
The primary goal should be in fulfilling the ansi-standard and
supporting applications from the past, while offering non-standard
interfaces to newer functionality in external shared C libraries.
Do we really think cl-fad has a thirty year lifetime ahead of it?

Is there any reason to suppose it does not? If it does not, why not?
Can it be improved to the point where it DOES have that lifetime ahead
of it? Will the problem it solves go away as Lisp implementations
improve?

Post by Camm Maguire
How will we coordinate with all these cl-library developers external
to the axiom project when they move on to other things in life?
Will we read all their source and maintain it ourselves?

If that source is literate (in the true literate programming sense)
this should actually be possible. Also, if the solutions developed are
good enought that not many changes NEED to be made, it becomes even
more viable.

The core of TeX has not changed in any major way for a LONG time, and
it is STILL the best tool for the problem it solves. This is the kind
of development I would like to see Axiom pursue - the solution of
problems in such a fashion that there is no need or incentive to solve
them again.

There should be NO dark corners or black magic anywhere in the software
chain. We should be able to look up the code for any point in the
process, and read the explanations for purpose and method wherever we
need to. I know this is not possible at the moment, and maybe not for
decades, but it is still a goal I would like to work towards.

Anyway. Thank you for the work you have been putting into GCL to help
support Axiom! My only concrete question at the moment really relates
to read-sequence - is this something GCL plans to add?

Cheers,
CY



____________________________________________________________________________________
It's here! Your new message!
Get new email alerts with the free Yahoo! Toolbar.
http://tools.search.yahoo.com/toolbar/features/mail/

[Camm Maguire]

Greetings!

Post by C Y

Post by Camm Maguire
if 1) GCL is currently deficient for axiom use in some regard and 2)
we have difficulties addressing said deficiencies via changes to GCL.
If both of these are true, I would greatly appreciate you and/or
others letting me know the details, as it is and has been a goal of
mine to ensure that gcl remains optimal for axiom use.

Camm, while it cannot (yet) be said to be part of Axiom, the cl-web
code does not work on GCL at the moment. There are two obvious things
I know of and probably others I don't (yet): 1) read-sequence doesn't
seem to be present in GCL 2) I'm using trivial-utf-8 for string->array
and array->string functionality, and I don't know how or if that would
work on GCL.

OK, these functions are in 2.6.8pre now. Please let me know if 2)
presents any problem.

Post by C Y

Post by Camm Maguire
I must say I'm less than enamored with the cl-foo library development
model. Its source level as opposed to binary, and there is no shared
library memory savings. Beyond which, there really doesn't appear to
be much of anything available which is not provided elsewhere in
faster, smaller, shareable C libraries, though I haven't made any
exhaustive study here.

I'm sure there are a lot of opinions on this one. I'm not quite clear

Yes -- by no means do I suppose mine is correct :-)

Post by C Y
as to why the source level is objectionable (don't we simply compile it
at build time anyway?). I like the all-lisp solution for the simple

source is not shareable (system memory)
source pushes on the user all compilation problems and time
source presumes more user expertise, particularly rare in lisp
source leaves more work for the user and less for the provider
source consumes more total system resources
source is less well separated from user code
source is easier to provide, and tends to therefore be more changeable
and less 'hardened'

These issues are reminiscent of gentoo vs. Debian, bash scripting
vs. C code, and even axiom's decision to ship binaries and not just
source.

Post by C Y
reason that it avoids any reliance on the behavior of the C language or
compilers, but that's just me.

All that is taken care of once a binary is loaded, in principle at
least. With source distributions, we depend on the behavior of lisp
*and* C compilers on said code before it can be used (efficiently).
And, sad as it may be, if rely we must, C is a much stabler target
than any lisp, alas.

Post by C Y

Post by Camm Maguire
The primary goal should be in fulfilling the ansi-standard and
supporting applications from the past, while offering non-standard
interfaces to newer functionality in external shared C libraries.
Do we really think cl-fad has a thirty year lifetime ahead of it?

Is there any reason to suppose it does not? If it does not, why not?
Can it be improved to the point where it DOES have that lifetime ahead
of it? Will the problem it solves go away as Lisp implementations
improve?

I think of this akin to the lifetime of my scripts, vs. the lifetime
of my portfolio optimization code. Or Joe's sawfish code to change the
color of icons consistently on kde and gnome, vs. the Linux kernel.
In general the quicker and easier the solution, and the more possible
implementors there are, the shorter the lifetime. It is a question of
weight. No one will ever rewrite axiom in a similar time frame.

Post by C Y

Post by Camm Maguire
How will we coordinate with all these cl-library developers external
to the axiom project when they move on to other things in life?
Will we read all their source and maintain it ourselves?

If that source is literate (in the true literate programming sense)
this should actually be possible. Also, if the solutions developed are
good enought that not many changes NEED to be made, it becomes even
more viable.
The core of TeX has not changed in any major way for a LONG time, and
it is STILL the best tool for the problem it solves. This is the kind
of development I would like to see Axiom pursue - the solution of
problems in such a fashion that there is no need or incentive to solve
them again.

Could not agree more here. So we should not rewrite TeX in lisp, but
rather find a way to use this excellent tool from within lisp.

Post by C Y
There should be NO dark corners or black magic anywhere in the software
chain. We should be able to look up the code for any point in the
process, and read the explanations for purpose and method wherever we
need to. I know this is not possible at the moment, and maybe not for
decades, but it is still a goal I would like to work towards.

Agreed.

Post by C Y
Anyway. Thank you for the work you have been putting into GCL to help
support Axiom! My only concrete question at the moment really relates

My pleasure. And thank you so much for your tremendous contributions
as well! Axiom owes so much to dedicated developers like yourself.

Take care,

Post by C Y
to read-sequence - is this something GCL plans to add?
Cheers,
CY
____________________________________________________________________________________
It's here! Your new message!
Get new email alerts with the free Yahoo! Toolbar.
http://tools.search.yahoo.com/toolbar/features/mail/

[Gabriel Dos Reis]

Camm Maguire <***@enhanced.com> writes:

[...]

| source is not shareable (system memory)
| source pushes on the user all compilation problems and time
| source presumes more user expertise, particularly rare in lisp
| source leaves more work for the user and less for the provider
| source consumes more total system resources
| source is less well separated from user code
| source is easier to provide, and tends to therefore be more changeable
| and less 'hardened'

Hear! Hear! Hear!

-- Gaby

[Gabriel Dos Reis]

Camm Maguire <***@enhanced.com> writes:

[...]

| > directories -- to gain portability between Unix and Windows
| > I tried to use Lisp code. But each Lisp is doing them
| > differently (and apparently some operations sometimes are missing).
| > So I got a maze of conditionals over Lisp implementations.
| > Looking at resulting code I feel that it is better to
| > call operationg system utilities and have just use
| > conditionals to choose between Unix and Windows versions
| > of file utilities.
|
| In C, we call this #ifdef hell. There is no good reason for it, in my
| experience.

Fully agreed.

Some of us would like to see Cpp disappear, but after spending time
and resources thinking of it, I don't see how to make it disappear in
the immediate future. The best I can offer is to avoid it as much as
possible.

If that can be of any consolation, I would like to offer this message
from Doug McIlroy on Cpp and similar stone-age constructs (when some
people suggested its inclusion in Haskell).

http://www.cs.dartmouth.edu/~doug/

For those who don't know Doug McIlroy, suffice it to say he knows what
he is talking about :-)

http://osdir.com/ml/lang.haskell.hugs.user/2006-01/msg00006.html

A recent posting that expressed a desire for #ifdef struck
me as perverse. A prime reason for using Haskell is its
elegance and clarity. To adopt the most inelegant and
turgid feature from C would be like encouraging graffiti
in a museum.

Most #ifdef's and #if's memorialize failures of imagination
or care, often in the name of "portability". Code is
NOT portable if it has to be rewritten according to the
conventions of each environment. Ifdef expresses just such
rewriting, and in an egregious style: it inverts the
logical structure of a program, bringing the tweaks to
the top while fragmenting the real architecture.

To make code portable, one should first get rid of system
dependencies to the greatest extent possible. Then treat
the recalcitrant residue with the same sense of style as
any other programming task.

Some standard methods that apply everywhere in programming
are equally helpful for portability:

Modularization (sweeping systemisms into a corner)
Generalization (rising above the systemisms)

For dealing with the recalcitrant residue, a method that
Haskellites should find specially sympathetic is

Specialization (freezing certain parameter values)

Ifdef, if course, is a specialization technique, but from
another era. If there really is a need for specialization,
it would be far better to employ a Ershovian specializer
that creates Haskell from Haskell rather than from
stone-age idioms. Is one available?

Doug McIlroy

What Doug says holds for Axiom word for word. An Ershovian
specializer exists for Lisp as used by Axiom: It is the Boot
translator.

It strikes as very disturbing that Axiomatizers would like to convert
people into thinking mathematically about software and yet would fail
to apply those same systematic thinkings to the programs they write;
and in particular would consider that long list of #+ and #- is a good
way to structure programs.

-- Gaby

[C Y]

Post by Camm Maguire
OK, these functions are in 2.6.8pre now. Please let me know if 2)
presents any problem.

Wow! Thanks! I'll let you know how it goes - I made a mistake and
started building cvs HEAD (2.7.0pre) so it'll be a bit longer... is it
in the ANSI version of 2.6.8pre? (so I know which one to build...)

Post by Camm Maguire
source is not shareable (system memory)

Erm. I'm not sure I follow you - do you mean functionality defined in
a source file takes up space it would not need to once compiled and is
not accessible in that form by other routines?

Post by Camm Maguire
source pushes on the user all compilation problems and time

Heh - I guess as a Gentoo user I'm no longer even remotely bothered by
that, but it is a point. I view it as the continuing reaffirmation of
ability to bootstrap.

Post by Camm Maguire
source presumes more user expertise, particularly rare in lisp

Well, knowing how to compile and load it I guess is a point. I'll
admit my first run-ins with Lisp were a bit confused...

Post by Camm Maguire
source leaves more work for the user and less for the provider

True.

Post by Camm Maguire
source consumes more total system resources

Only until it's compiled ;-). And disk space is cheap.

Post by Camm Maguire
source is less well separated from user code

Um. Not sure what you mean here? You mean there is less temptation to
"look inside" the guts of a library and violate library boundaries if
the provided file is a binary?

Post by Camm Maguire
source is easier to provide, and tends to therefore be more
changeable and less 'hardened'

But that's a key advantage! The trick is to make it so there is no
need or desire to change it, and I admit that's a doozie.

Post by Camm Maguire
These issues are reminiscent of gentoo vs. Debian, bash scripting
vs. C code, and even axiom's decision to ship binaries and not just
source.

I'm a Gentoo user and fan :-).

Post by Camm Maguire

Post by C Y
reason that it avoids any reliance on the behavior of the C
language or compilers, but that's just me.

All that is taken care of once a binary is loaded, in principle at
least. With source distributions, we depend on the behavior of lisp
*and* C compilers on said code before it can be used (efficiently).
And, sad as it may be, if rely we must, C is a much stabler target
than any lisp, alas.

My understanding is that sbcl and cmucl use a working lisp binary to
bootstrap themselves - I know GCL uses other means. Of course SOME
binary is necessary, and at some point in the distant past someone must
have written the first compilers in machine and assembly code. There
are discussions from time to time on what could constitute a minimum
bootstrap compiler for Lisp, and I confess to being interested in that
question. Hopefully we will never again have to bootstrap from bare
metal, but if we do it would be nice to know how to do it.

Post by Camm Maguire
I think of this akin to the lifetime of my scripts, vs. the lifetime
of my portfolio optimization code. Or Joe's sawfish code to change
the color of icons consistently on kde and gnome, vs. the Linux
kernel. In general the quicker and easier the solution, and the more
possible implementors there are, the shorter the lifetime. It is a
question of weight. No one will ever rewrite axiom in a similar
time frame.

True, but no one SHOULD need to rewrite either one. Rewriting is, by
definition, a duplication of effort. The less rewriting, the more
original work and the faster we can attack new and interesting
problems. (Of course, that means any new and useful code has to attack
the HARD problems, but still...)

If Freespec had been able to get off the ground, I would have liked to
see it follow up on some of the directions the ANSI committee pointed
out but never implemented, that would have solved a lot of the problems
we see today. Unfortunately, some less direct means than building off
of dpANS3 must be found and that will take a LOT longer :-(.

Post by Camm Maguire

Post by C Y
This is the kind of development I would like to see Axiom pursue -
the solution of problems in such a fashion that there is no need
or incentive to solve them again.

Could not agree more here. So we should not rewrite TeX in lisp, but
rather find a way to use this excellent tool from within lisp.

That's a point, and I think LaTeX will be by far the last non-lisp
dependency to go, if it ever does. I would be very happy to see such
an interface - was there a project somewhere working to expose more of
TeX for non-traditional uses? While I am in awe of the algorithms and
how well they work, I have always been a little puzzled by the software
"stack" of TeX. As I understand it, TeX is written in Pascal which is
then translated to C which is compiled. So it relies on the language
behavior definitions of Pascal AND C, or more specifically that the
translation routines of the behavior specified in the Pascal language
of the original author are faithfully translated into C code that is
interpreted by a modern compiler in the same way the original author of
the translation routine assumed it would. I am not all that familiar
with C and Pascal so perhaps this is reasonable, but it always struck
me as a little... odd. I admit it has been effective. I guess the
copyright restriction of no copying at all of the core TeX file unless
it is kept identical helps provide stability, even if the open source
advocate in me gets the jitters seeing it...

Actually, as I understand it cl-typesetting has already implemented
large bits of TeX's algorithms in Lisp, although not yet the
mathematical routines (darn it...) Of course, it's almost completely
undocumented, which is frustrating and ironic as all get out
considering its conceptual ancestor and the fact it's a typesetting
system... but at least its license is now compatible :-).

Whether it is worth bringing cl-typesetting up to the level of a true
TeX replacement I don't know (although I am sure everyone else would
quickly answer no, with good reasons behind it) but TeX does its job
well enough (and that job is hard enough) that I am content to leave
pondering that task for another day - there are enough low hanging
fruit to pluck.

Cheers,
CY



____________________________________________________________________________________Got a little couch potato?
Check out fun summer activities for kids.
http://search.yahoo.com/search?fr=oni_on_mail&p=summer+activities+for+kids&cs=bz

[Ralf Hemmecke]

Post by C Y

Post by Camm Maguire
Could not agree more here. So we should not rewrite TeX in lisp, but
rather find a way to use this excellent tool from within lisp.

That's a point, and I think LaTeX will be by far the last non-lisp
dependency to go, if it ever does. I would be very happy to see such
an interface - was there a project somewhere working to expose more of
TeX for non-traditional uses? While I am in awe of the algorithms and
how well they work, I have always been a little puzzled by the software
"stack" of TeX. As I understand it, TeX is written in Pascal which is
then translated to C which is compiled. So it relies on the language
behavior definitions of Pascal AND C, or more specifically that the
translation routines of the behavior specified in the Pascal language
of the original author are faithfully translated into C code that is
interpreted by a modern compiler in the same way the original author of
the translation routine assumed it would. I am not all that familiar
with C and Pascal so perhaps this is reasonable, but it always struck
me as a little... odd.

Just yesterday, I've read the first few pages of "TeX: The Program".
There you can read that TeX is written in WEB and that is translated to
Pascal-H, some variant of Pascal that Knuth used. You furthermore read
that Knuth deliberately avoided to use any fancy extensions of Pascal-H
and even of Pascal (Wirth) itself, since he wanted to make TeX "easily"
(i.e. with some minimal effort) translatable to other Pascal variants.
For example, he did not use definitions of procedures inside procedures.
There are a few other things mentioned, but the important thing is that
he mentions this at all. If you have to read that from the Pascal
sources that come out of WEB, good luck.

TeX is admittedly a strange language, but I don't think that that
TeXmacs is any easier. I've browsed through the documentation yesterday,
and I was a little surprised to find out that the style language of
TeXmacs is not Scheme (basically it is, but with a few differences). Yet
another reason why TeXmacs is not well accepted by the community. It is
simply too hard to have your old knowledge in your head (by which you
can do things in LaTeX (maybe not the Wysiwyg/m way)) and you would have
to find the appropriate commands in the TeXmacs manual. Often guessing
just works, but if not, you are stuck and that is more than frustrating.
(Just my recent experiences with TeXmacs.)

To be more precise. I wanted to define some TeXmacs macros as they are
described in the manual (Help->Manual->Writing your own style files).

Entering

<assign|hello|<macro|name|Hello <person|<arg|name>>!>>

as it is described there nearly drove me crazy. I did not get the
"person" macro entered as it was described just below that box.
(Even if I am to stupid to read clearly and follow the manual, I find it
quite hard to learn the "new" way. And that is frustrating. :-( )

So in some sense, TeXmacs fits perfectly well to Axiom in its steep
learning curve. ;-)

Hello TeXmacs, developers. I am certainly not the most usual user, so
you probably can ignore my comments. But I actually intended to add (or
help to add) some literate programming support to TeXmacs. My experience
from yesterday night really let's me think twice about whether I should
invest my time into TeXmacs. There is so many things to do (LP support,
syntax highlighting, indentation support, (automatic hyperlinking
between source files, I haven't yet seen a "back" button so that I could
use TeXmacs as a source code browser) and I find it overly hard to
achieve something myself in a reasonable amount of time.

Ralf

[Henri Lesourd]

Post by Ralf Hemmecke
TeX is admittedly a strange language, but I don't think that that
TeXmacs is any easier.

Honestly, TeX is an horror, you don't even have the possibility to
name local variables, you have only a fixed number of registers,
like in assembly language ! By the way, exactly what TeX is is
an assembly language.

As far as TeXmacs macro language is concerned, I don't know
if it is easier, but at least is a much cleaner and high level language,
which is meant to be as functional as possible (although functional
programming doesn't solves all the problems, but it is another debate).

Post by Ralf Hemmecke
I've browsed through the documentation yesterday, and I was a little
surprised to find out that the style language of TeXmacs is not Scheme
(basically it is, but with a few differences). Yet another reason why
TeXmacs is not well accepted by the community. It is simply too hard
to have your old knowledge in your head (by which you can do things in
LaTeX (maybe not the Wysiwyg/m way)) and you would have to find the
appropriate commands in the TeXmacs manual. Often guessing just works,
but if not, you are stuck and that is more than frustrating.
(Just my recent experiences with TeXmacs.)
To be more precise. I wanted to define some TeXmacs macros as they are
described in the manual (Help->Manual->Writing your own style files).
Entering
<assign|hello|<macro|name|Hello <person|<arg|name>>!>>
as it is described there nearly drove me crazy. I did not get the
"person" macro entered as it was described just below that box.
(Even if I am to stupid to read clearly and follow the manual, I find
it quite hard to learn the "new" way. And that is frustrating. :-( )

What you need is perhaps a more focussed and user-friendly kind
of documentation. You should at least try:
http://www.ags.uni-sb.de/~henri/texmacs/aTeXmacsTutorial.pdf

, all the people who used this as an introduction to TeXmacs programming
learned very quickly what needs to be known (the point is : the number
of things to know is *small*).

Post by Ralf Hemmecke
Hello TeXmacs, developers. I am certainly not the most usual user, so
you probably can ignore my comments. But I actually intended to add
(or help to add) some literate programming support to TeXmacs. My
experience from yesterday night really let's me think twice about
whether I should invest my time into TeXmacs. There is so many things
to do (LP support, syntax highlighting, indentation support,
(automatic hyperlinking between source files, I haven't yet seen a
"back" button so that I could use TeXmacs as a source code browser)
and I find it overly hard to achieve something myself in a reasonable
amount of time.

You should first give a try to the tutorial above : although
it remains incomplete, it has exactly been written for solving
the kinds of learning problem you are describing now.


Best, Henri

[Gabriel Dos Reis]

Camm --

I believe GCL-2.6.8pre is missing the ANSI Lisp function

ensure-directories-exist


As a subsidiary question, how do you delete a directory in ANSI Lisp?

Thanks!

-- Gaby

[Camm Maguire]

Greetings!

Post by Gabriel Dos Reis
Camm --
I believe GCL-2.6.8pre is missing the ANSI Lisp function
ensure-directories-exist

among many others, but is in 2.7.0. Do you need a backport? It is
simple.

Post by Gabriel Dos Reis
As a subsidiary question, how do you delete a directory in ANSI Lisp?

I see no such function in the standard, but am cc'ing Paul Dietz.

I therefore would suggest (system (format nil "rm -rf ~s" x))

Just to repeat, 2.7.0 is moving to the following usage of 'directory
akin to clisp unless someone objects:
=============================================================================
COMPILER>>(directory "/tmp")

NIL
COMPILER>>(directory "/tmp/")

(#P"/tmp/")
COMPILER>>(directory "/tmp/*")

(#P"/tmp/#gazonk_27762_21.c#" #P"/tmp/#ii#" #P"/tmp/#q.h#")
=============================================================================

This is what 2.6 has:

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

Post by Gabriel Dos Reis
(directory "/tmp")

(#p"/tmp")

Post by Gabriel Dos Reis
(directory "/tmp/")

(#p"/tmp/#gazonk_27762_21.c#" #p"/tmp/#ii#" #p"/tmp/#q.h#")

Post by Gabriel Dos Reis
(directory "/tmp/*")

(#p"/tmp/#gazonk_27762_21.c#" #p"/tmp/#ii#" #p"/tmp/#q.h#")
=============================================================================

[Bill Page]

Post by Camm Maguire
...
I see no such function in the standard, but am cc'ing Paul Dietz.
I therefore would suggest (system (format nil "rm -rf ~s" x))
...

I am really surprised that Lispers do not find this sort of
suggestion really revolting! Surely the point of an operating
system is to provide such services to programs at low level
without resorting to command line interpretation to pass
parameters and access such functions.

.. there's got to, there's got to be a better way ...

Regards,
Bill Page.

[Gabriel Dos Reis]

On Thu, 24 May 2007, Camm Maguire wrote:

| Greetings!
|
| Gabriel Dos Reis <***@cs.tamu.edu> writes:
|
| > Camm --
| >
| > I believe GCL-2.6.8pre is missing the ANSI Lisp function
| >
| > ensure-directories-exist
| >
|
| among many others, but is in 2.7.0. Do you need a backport? It is
| simple.

Yes, I would need a backport to 2.6.8pre.
For the moment, Axiom.build-improvements (and the next official release
of Axiom) is still using that version of GCL.

Mant thanks!

| >
| > As a subsidiary question, how do you delete a directory in ANSI Lisp?
|
| I see no such function in the standard, but am cc'ing Paul Dietz.
|
| I therefore would suggest (system (format nil "rm -rf ~s" x))

Thanks!

| Just to repeat, 2.7.0 is moving to the following usage of 'directory
| akin to clisp unless someone objects:
| =============================================================================
| COMPILER>>(directory "/tmp")
|
| NIL
| COMPILER>>(directory "/tmp/")
|
| (#P"/tmp/")
| COMPILER>>(directory "/tmp/*")
|
| (#P"/tmp/#gazonk_27762_21.c#" #P"/tmp/#ii#" #P"/tmp/#q.h#")
| =============================================================================

This will be helpful.

Many thanks.

-- Gaby

[Camm Maguire]

Greetings!

I am prepared to backport the clisp-style directory/truename behavior,
but this breaks current axiom, and I do not want to leave the project
even temporarily without a gcl to build it. Please advise.

2.7.0 (with the commits to go in shortly) appears to build wh-sandbox
save for this issue.

gcl
GCL (GNU Common Lisp) 2.6.7 CLtL1 Oct 29 2006 02:32:45
Source License: LGPL(gcl,gmp), GPL(unexec,bfd,xgcl)
Binary License: GPL due to GPL'ed components: (XGCL 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.
Temporary directory for compiler files set to /tmp/

(truename "AHYP.erlib")

#p"/fix/t1/camm/wh-sandbox/src/algebra/AHYP.erlib"



GCL_ANSI=t gclcvs
GCL (GNU Common Lisp) 2.7.0 ANSI Jul 2 2007 22:02:18
Source License: LGPL(gcl,gmp,pargcl), GPL(unexec,bfd,xgcl)
Binary License: GPL due to GPL'ed components: (XGCL 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.

Temporary directory for compiler files set to /tmp/

(truename "AHYP.erlib")

Error:
Fast links are on: do (si::use-fast-links nil) for debugging
Signalled by TRUENAME.
Condition in TRUENAME [or a callee]: INTERNAL-SIMPLE-FILE-ERROR: File error on #P"AHYP.erlib": File does not exist

Broken at TRUENAME. Type :H for Help.
1 (Continue) Return to top level.



clisp
i i i i i i i ooooo o ooooooo ooooo ooooo
I I I I I I I 8 8 8 8 8 o 8 8
I \ `+' / I 8 8 8 8 8 8
\ `-+-' / 8 8 8 ooooo 8oooo
`-__|__-' 8 8 8 8 8
| 8 o 8 8 o 8 8
------+------ ooooo 8oooooo ooo8ooo ooooo 8

Copyright (c) Bruno Haible, Michael Stoll 1992, 1993
Copyright (c) Bruno Haible, Marcus Daniels 1994-1997
Copyright (c) Bruno Haible, Pierpaolo Bernardi, Sam Steingold 1998
Copyright (c) Bruno Haible, Sam Steingold 1999-2000
Copyright (c) Sam Steingold, Bruno Haible 2001-2006

[1]> (truename "AHYP.erlib")

*** - TRUENAME: "/fix/t1/camm/wh-sandbox/src/algebra/AHYP.erlib" names a
directory, not a file
The following restarts are available:
ABORT :R1 ABORT
Break 1 [2]>

Take care,

| Greetings!
|
|
| > Camm --
| >
| > I believe GCL-2.6.8pre is missing the ANSI Lisp function
| >
| > ensure-directories-exist
| >
|
| among many others, but is in 2.7.0. Do you need a backport? It is
| simple.
Yes, I would need a backport to 2.6.8pre.
For the moment, Axiom.build-improvements (and the next official release
of Axiom) is still using that version of GCL.
Mant thanks!
| >
| > As a subsidiary question, how do you delete a directory in ANSI Lisp?
|
| I see no such function in the standard, but am cc'ing Paul Dietz.
|
| I therefore would suggest (system (format nil "rm -rf ~s" x))
Thanks!
| Just to repeat, 2.7.0 is moving to the following usage of 'directory
| =============================================================================
| COMPILER>>(directory "/tmp")
|
| NIL
| COMPILER>>(directory "/tmp/")
|
| (#P"/tmp/")
| COMPILER>>(directory "/tmp/*")
|
| (#P"/tmp/#gazonk_27762_21.c#" #P"/tmp/#ii#" #P"/tmp/#q.h#")
| =============================================================================
This will be helpful.
Many thanks.
-- Gaby

[Gregory Vanuxem]

Hello,

Le mardi 03 juillet 2007 à 15:36 -0400, Camm Maguire a écrit :

[...]

Post by Camm Maguire
clisp
i i i i i i i ooooo o ooooooo ooooo ooooo
I I I I I I I 8 8 8 8 8 o 8 8
I \ `+' / I 8 8 8 8 8 8
\ `-+-' / 8 8 8 ooooo 8oooo
`-__|__-' 8 8 8 8 8
| 8 o 8 8 o 8 8
------+------ ooooo 8oooooo ooo8ooo ooooo 8
Copyright (c) Bruno Haible, Michael Stoll 1992, 1993
Copyright (c) Bruno Haible, Marcus Daniels 1994-1997
Copyright (c) Bruno Haible, Pierpaolo Bernardi, Sam Steingold 1998
Copyright (c) Bruno Haible, Sam Steingold 1999-2000
Copyright (c) Sam Steingold, Bruno Haible 2001-2006
[1]> (truename "AHYP.erlib")
*** - TRUENAME: "/fix/t1/camm/wh-sandbox/src/algebra/AHYP.erlib" names a
directory, not a file
ABORT :R1 ABORT
Break 1 [2]>
Take care,

Yes, but


clisp
i i i i i i i ooooo o ooooooo ooooo ooooo
I I I I I I I 8 8 8 8 8 o 8 8
I \ `+' / I 8 8 8 8 8 8
\ `-+-' / 8 8 8 ooooo 8oooo
`-__|__-' 8 8 8 8 8
| 8 o 8 8 o 8 8
------+------ ooooo 8oooooo ooo8ooo ooooo 8

Copyright (c) Bruno Haible, Michael Stoll 1992, 1993
Copyright (c) Bruno Haible, Marcus Daniels 1994-1997
Copyright (c) Bruno Haible, Pierpaolo Bernardi, Sam Steingold 1998
Copyright (c) Bruno Haible, Sam Steingold 1999-2000
Copyright (c) Sam Steingold, Bruno Haible 2001-2006

[1]> (truename "Axiom")

*** - TRUENAME: "/home/greg/Axiom" names a directory, not a file
The following restarts are available:
ABORT :R1 ABORT
Break 1 [2]>
[3]> (truename "Axiom/")
#P"/home/greg/Axiom/"

(just in case)

Greg

[Camm Maguire]

Greetings!

Yes, and thanks!

(hopefully this is just a one line patch to the axiom sources
somewhere. Would be great to finish the test build with 2.7.0 ...)


GCL_ANSI=t gclcvs
GCL (GNU Common Lisp) 2.7.0 ANSI Jul 2 2007 22:02:18
Source License: LGPL(gcl,gmp,pargcl), GPL(unexec,bfd,xgcl)
Binary License: GPL due to GPL'ed components: (XGCL 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.

Temporary directory for compiler files set to /tmp/

(truename "AHYP.erlib/")

#P"/fix/t1/camm/wh-sandbox/src/algebra/AHYP.erlib/"

Hello,
[...]

Post by Camm Maguire
clisp
i i i i i i i ooooo o ooooooo ooooo ooooo
I I I I I I I 8 8 8 8 8 o 8 8
I \ `+' / I 8 8 8 8 8 8
\ `-+-' / 8 8 8 ooooo 8oooo
`-__|__-' 8 8 8 8 8
| 8 o 8 8 o 8 8
------+------ ooooo 8oooooo ooo8ooo ooooo 8
Copyright (c) Bruno Haible, Michael Stoll 1992, 1993
Copyright (c) Bruno Haible, Marcus Daniels 1994-1997
Copyright (c) Bruno Haible, Pierpaolo Bernardi, Sam Steingold 1998
Copyright (c) Bruno Haible, Sam Steingold 1999-2000
Copyright (c) Sam Steingold, Bruno Haible 2001-2006
[1]> (truename "AHYP.erlib")
*** - TRUENAME: "/fix/t1/camm/wh-sandbox/src/algebra/AHYP.erlib" names a
directory, not a file
ABORT :R1 ABORT
Break 1 [2]>
Take care,

Yes, but
clisp
i i i i i i i ooooo o ooooooo ooooo ooooo
I I I I I I I 8 8 8 8 8 o 8 8
I \ `+' / I 8 8 8 8 8 8
\ `-+-' / 8 8 8 ooooo 8oooo
`-__|__-' 8 8 8 8 8
| 8 o 8 8 o 8 8
------+------ ooooo 8oooooo ooo8ooo ooooo 8
Copyright (c) Bruno Haible, Michael Stoll 1992, 1993
Copyright (c) Bruno Haible, Marcus Daniels 1994-1997
Copyright (c) Bruno Haible, Pierpaolo Bernardi, Sam Steingold 1998
Copyright (c) Bruno Haible, Sam Steingold 1999-2000
Copyright (c) Sam Steingold, Bruno Haible 2001-2006
[1]> (truename "Axiom")
*** - TRUENAME: "/home/greg/Axiom" names a directory, not a file
ABORT :R1 ABORT
Break 1 [2]>
[3]> (truename "Axiom/")
#P"/home/greg/Axiom/"
(just in case)
Greg
_______________________________________________
Axiom-developer mailing list
http://lists.nongnu.org/mailman/listinfo/axiom-developer

[C Y]

Post by Bill Page

Post by Camm Maguire
...
I see no such function in the standard, but am cc'ing Paul Dietz.
I therefore would suggest (system (format nil "rm -rf ~s" x))
...

I am really surprised that Lispers do not find this sort of
suggestion really revolting!

I do (well, frustrating anyway). But apparently it's harder than it
seems to deal with across all possible cases. Cross platform issues
can really be a royal pain in the neck, regardless of language - the
CONCEPTS seem to be different in some cases. Sigh.

Post by Bill Page
Surely the point of an operating
system is to provide such services to programs at low level
without resorting to command line interpretation to pass
parameters and access such functions.
.. there's got to, there's got to be a better way ...

I would tend to agree, but looking at comp.lang.lisp suggests that
handling directories over all possible situations is not as simple as
it seems - if you take into account a wide variety of file system
concepts, at least.

CY



____________________________________________________________________________________Got a little couch potato?
Check out fun summer activities for kids.
http://search.yahoo.com/search?fr=oni_on_mail&p=summer+activities+for+kids&cs=bz

[Waldek Hebisch]

Post by Camm Maguire
Greetings, and thanks for including me in this thread. Unfortunately,
axiom-developer mail is still not getting through my ISP for some
reason.

In my private tree Axiom is nicely working on top of sbcl and clisp.
The remaining known problems are sockets and writeablep function.

Great! It is always nice to have more options. But I do have a
general question here. Work in this direction obviously makes sense
if 1) GCL is currently deficient for axiom use in some regard and 2)
we have difficulties addressing said deficiencies via changes to GCL.
If both of these are true, I would greatly appreciate you and/or
others letting me know the details, as it is and has been a goal of
mine to ensure that gcl remains optimal for axiom use. As in the
past, I pledge that if axiom needs anything from GCL which is
currently unavailable, I will make sure said functionality works in
GCL. What I would like to avoid is chasing every random package which
no one has any serious intention of deploying in a real shipped
program.
If either 1) or 2) above are not true, may I suggest that significant
work in this regard is a distraction from the real goals of the axiom
project -- to deliver the best symbolic algebra package in the open
source world. In our company, we manage approx. $70 billion dollars
using open source software and code we've written on top of it. We
would get nowhere if we spent any time at all making sure our code
works both on gcc and icc, etc. Rather we pick a platform that
appears flexible, stick to it, and get the results we want out of it
quickly. We do almost everything using gcc, gdb and emacs, not
because they are the slickest or hottest or even fastest, but because
they have good portable performance, they can be changed at the source
level if necessary, and they will be available forever, making our
payoff period for the learning curve essentially last a whole
lifetime.
I'd really love to help the axiom project by offering a similar setup
for use by the developers. Even one better -- axiom has its own
personal compiler developer to tailor the compiler to its needs if
necessary. This only pays off if my work on GCL frees axiom developer
hours for work on the core system.

That is very generous offer and I appreciate it. But I must disagree
with some of your assuptions. Namely, sticking to a single
platform/toolchain is perfectly good business decision. But,
especially for open source project, there are good reasons to
to seek portablity to other Lisps. Let me mention few reasons:

1) Code readability: for Ansi constructs it is reasonable to say
that behaviour is described by HyperSpec. But if we use non
Ansi things or depend on GCL specific aspects then this is
no longer the case. So it is good to separate Ansi part from
GCL specific ones.

Some people belive that such separation should be done via
extensive audit/review. I take pragmatic position here:
compiling with other Lisp implementations identifies
various dubious constructs much more cheaply than audit.

2) Sbcl port helped to make Axiom compatible with Ansi GCL. Together
with clisp port it significantly reduced chance for future
Ansi changes in GCL to break Axiom.

3) I have some personal intrest in other Lisp implementations.

4) Lisp developers seem to be attached to the implementation they
use. There is good chance that little effort spent on keeping
Axiom portable will be offset by extra contibutions possible
thanks to portability.

5) Ability to use already installed Lisp for Axiom development/
testing.

There are also some problems that I had with GCL based Axiom:

- Axiom is slow. To identify reasons I need a profiler. But I was
unable to use GCL profiler. I tried to follow sparse instruction
given in doc/profile, but I got no output.

-

[d***@axiom-developer.org]

Camm,

All versions of Axiom have a local copy of GCL cached
so it should be fine to do the transition.

Tim

[Camm Maguire]

Greetings!

Post by d***@axiom-developer.org
Camm,
All versions of Axiom have a local copy of GCL cached
so it should be fine to do the transition.

So if an external GCL with the new semantics is present, will this
break any of the axiom branches?

Take care,

Post by d***@axiom-developer.org
Tim
_______________________________________________
Axiom-developer mailing list
http://lists.nongnu.org/mailman/listinfo/axiom-developer

[d***@axiom-developer.org]

Camm,

Sorry, sent this to enhanced.com, which bounces.

All versions of Axiom have a local copy of GCL cached
so it should be fine to do the transition.

Tim

[d***@axiom-developer.org]

Camm,

Is therea conditional flag #+(and :GCL :xxx) we can use?

Tim

[Camm Maguire]

Greetings!

Post by d***@axiom-developer.org
Camm,
Is therea conditional flag #+(and :GCL :xxx) we can use?
Tim

Given the discussion, it appears best to limit the transition to 2.7.x
-- no need for conditionals. If axiom needs
ensure-directories-exist/mkdir in 2.6.x, then perhaps 2.6.9 is
warranted. This appears likely to break more than I had thought.

Take care,

[Waldek Hebisch]

Post by Camm Maguire
Greetings!
I am prepared to backport the clisp-style directory/truename behavior,
but this breaks current axiom, and I do not want to leave the project
even temporarily without a gcl to build it. Please advise.
2.7.0 (with the commits to go in shortly) appears to build wh-sandbox
save for this issue.

wh-sandbox builds using clisp. We need 21 clisp specific conditionals.
9 of those conditionals is due to file and directory handling. In some
cases current code uses gcl specific method that will work regardless of
the change, but in some cases gcl specific section will need update. So
one can estimate that change in gcl will require about between 10 to 60
lines of extra code (extra conditionals + code to handle extra case).

I belive that truename change affects only one place in wh-sandbox,
namely the 'axiom-probe-file' function in 'src/lisp/axiom-lisp.lisp.pamphlet'.
clisp variant needs 4 lines of code + 1 line for conditional, but
since different gcl versions work differently, gcl will probably
need 6-8 lines of extra code here.

Directory change also is problematic: in 'src/interp/daase.lisp.pamphlet'
in the function 'localdatabase' we need list of files matching
'*.NRLIB/index.KAF'. With all other Lisps we just use this pattern.
But gcl on Windows cannot handle it. So we use '*.NRLIB' and
append '/index.KAF' using string concatenation. We will have to
change this to '*.NRLIB/' for the new version (which is trivial)
and add proper conditional. How complex test is need will depend
on gcl -- in the worst case we will have to run a test program
from configure and propagate results to the Lisp, which will
take probably about 20 lines of code.

Important thing is that clisp file handling can loose some functionality
-- currently I do not know how to rename directory using clisp
(apparently clisp 'rename-file' does not work on directories).
Similarly, I do not not how to delete empty directory using clisp.

Another question is how to detect which version of functions is
present -- the old one or the new one. Note that for testing we
want Axiom sources to work with different gcl versions, so we
need automatic way to choose correct variant.

I would suggest that gcl _first_ adds nonstandard functions that
implement Posix style file handling and only later changes Ansi Lisp
functions to clisp semantic. That way users that want Posix
semantics can use Posix functions if presesnt and otherwise be assured
that they get old gcl semantics (which is closer to Posix than the
clisp way) from standard Lisp functions.

Some functions were added to gcl, but I am affraid that some
functions that Axiom needs are still missing. Let me try to
enumerate functions that Axiom uses:

change directory
make directory (done via C)
get current directory name
get absolute name of a directory
delete file or directory
rename file or directory
find all files matching pattern "*.NRLIB/index.KAF"
recursively copy directory with content (currently invokes the 'cp' program)
copy file (likewise)

[Camm Maguire]

Greetings!

Post by Waldek Hebisch

Post by Camm Maguire
Greetings!
I am prepared to backport the clisp-style directory/truename behavior,
but this breaks current axiom, and I do not want to leave the project
even temporarily without a gcl to build it. Please advise.
2.7.0 (with the commits to go in shortly) appears to build wh-sandbox
save for this issue.

wh-sandbox builds using clisp. We need 21 clisp specific conditionals.
9 of those conditionals is due to file and directory handling. In some
cases current code uses gcl specific method that will work regardless of
the change, but in some cases gcl specific section will need update. So
one can estimate that change in gcl will require about between 10 to 60
lines of extra code (extra conditionals + code to handle extra case).
I belive that truename change affects only one place in wh-sandbox,
namely the 'axiom-probe-file' function in 'src/lisp/axiom-lisp.lisp.pamphlet'.
clisp variant needs 4 lines of code + 1 line for conditional, but
since different gcl versions work differently, gcl will probably
need 6-8 lines of extra code here.
Directory change also is problematic: in 'src/interp/daase.lisp.pamphlet'
in the function 'localdatabase' we need list of files matching
'*.NRLIB/index.KAF'. With all other Lisps we just use this pattern.
But gcl on Windows cannot handle it. So we use '*.NRLIB' and
append '/index.KAF' using string concatenation. We will have to
change this to '*.NRLIB/' for the new version (which is trivial)
and add proper conditional. How complex test is need will depend
on gcl -- in the worst case we will have to run a test program
from configure and propagate results to the Lisp, which will
take probably about 20 lines of code.
Important thing is that clisp file handling can loose some functionality
-- currently I do not know how to rename directory using clisp
(apparently clisp 'rename-file' does not work on directories).
Similarly, I do not not how to delete empty directory using clisp.

This is all quite depressing. It appears the clspec is quite
deficient in this regard. Hence, I think the proper goal for GCL is
to be as close to posix and "intuition" in this regard while still
passing the spec.

The whole goal was 1) to support pathnames with spaces, ala mingw, and
2) to provide some natural means within the spec for distinguishing a
directory from a file. clisp seems appropriate for this, but does not
allow one to overlay delete-file et. al. for directories. This does
seem a good tradeoff on reflection, as any general overlay is going to
run afoul of all sorts of problems trying to #'open a directory and
#'read therefrom. If this perspective is the right one, all the spec
functions but #'directory should work only on files, and GCL should
provide functions in 'si to do the directory manipulations outside the
spec.

As they are outside the spec, is there any reason not to implement
these where possible with #'system? The bourne shell is likely at
least as portable as GCL is. I was worried about the following
directory implementation:

sprintf(command, "shopt -s dotglob; "
"IFS='' j=\"%s\"; for i in $j ; do ! [ -e \"$i\" ] || %c [ -d \"$i\" ] || echo \"$i\" ; done", filename, ch);

but I think it likely that this will even work on mingw.

Post by Waldek Hebisch
Another question is how to detect which version of functions is
present -- the old one or the new one. Note that for testing we
want Axiom sources to work with different gcl versions, so we
need automatic way to choose correct variant.
I would suggest that gcl _first_ adds nonstandard functions that
implement Posix style file handling and only later changes Ansi Lisp
functions to clisp semantic. That way users that want Posix
semantics can use Posix functions if presesnt and otherwise be assured
that they get old gcl semantics (which is closer to Posix than the
clisp way) from standard Lisp functions.
Some functions were added to gcl, but I am affraid that some
functions that Axiom needs are still missing. Let me try to
change directory
make directory (done via C)
get current directory name
get absolute name of a directory
delete file or directory
rename file or directory
find all files matching pattern "*.NRLIB/index.KAF"
recursively copy directory with content (currently invokes the 'cp' program)
copy file (likewise)

Thanks for this list. Will get these in.

Take care,

Post by Waldek Hebisch
--
Waldek Hebisch

[Bill Page]

Post by Camm Maguire
...
This is all quite depressing. It appears the clspec is quite
deficient in this regard. Hence, I think the proper goal for GCL is
to be as close to posix and "intuition" in this regard while still
passing the spec.

+1 for supporting posix.

Post by Camm Maguire
The whole goal was 1) to support pathnames with spaces, ala mingw, and
2) to provide some natural means within the spec for distinguishing a
directory from a file. clisp seems appropriate for this, but does not
allow one to overlay delete-file et. al. for directories. This does
seem a good tradeoff on reflection, as any general overlay is going to
run afoul of all sorts of problems trying to #'open a directory and
#'read therefrom. If this perspective is the right one, all the spec
functions but #'directory should work only on files, and GCL should
provide functions in 'si to do the directory manipulations outside the
spec.

Yes.

Post by Camm Maguire
As they are outside the spec, is there any reason not to implement
these where possible with #'system? The bourne shell is likely at
least as portable as GCL is. I was worried about the following
sprintf(command, "shopt -s dotglob; "
"IFS='' j=\"%s\"; for i in $j ; do ! [ -e \"$i\" ] || %c [ -d \"$i\" ] || echo \"$i\" ; done", filename, ch);
but I think it likely that this will even work on mingw.

Well, that depends on what you mean by "work". At the present time gcl
builds on MSYS/mingw as a *native* Windows application. MSYS/mingw is
only required to build gcl from source. Standard native windows does
not have any of these unix-oriented #system tools. Doing what you
suggest would result in gcl only working from within the MSYS/mingw
shell.

Of course there is also the issue of gcc on Windows which is needed
when compiling. In the case of installing a native Windows Axiom, the
install program includes the bare minimum mingw gcc components in a
separate directory along with Axiom. Installation of mingw is not a
prerequisite.

Although it requires a little more knowledge of Windows internals, I
strongly recommend that gcl on windows continue to call the windows
API instead of relying on external support for posix/unix commands in
a particular shell that is not native to Windows. For similar reasons
I also would not recommend trying to utilize the Windows non-posix
command interpreter for this purpose.

Regards,
Bill Page.

[Gabriel Dos Reis]

On Tue, 3 Jul 2007, Bill Page wrote:

| > As they are outside the spec, is there any reason not to implement
| > these where possible with #'system? The bourne shell is likely at
| > least as portable as GCL is. I was worried about the following
| > directory implementation:
| >
| > sprintf(command, "shopt -s dotglob; "
| > "IFS='' j=\"%s\"; for i in $j ; do ! [ -e \"$i\" ]
| > || %c [ -d \"$i\" ] || echo \"$i\" ; done",
| > filename, ch);
| >
| > but I think it likely that this will even work on mingw.
| >
|
| Well, that depends on what you mean by "work". At the present time gcl
| builds on MSYS/mingw as a *native* Windows application. MSYS/mingw is
| only required to build gcl from source. Standard native windows does
| not have any of these unix-oriented #system tools. Doing what you
| suggest would result in gcl only working from within the MSYS/mingw
| shell.

Note however that mingw/msys support for paths with embeeded space
is very limited -- this is not a suggestion that it should not be done
in GCL; rather it is a warning about what is be assumed.

| Of course there is also the issue of gcc on Windows which is needed
| when compiling. In the case of installing a native Windows Axiom, the
| install program includes the bare minimum mingw gcc components in a
| separate directory along with Axiom. Installation of mingw is not a
| prerequisite.

The Haskell distribution for windows ships with a build of gcc.
This is a general problem/nuisance on windows platforms for programs
that generate C codes and assumes availability of a C compiler.

-- Gaby

[Camm Maguire]

Greetings!

Post by Bill Page

Post by Camm Maguire
...
This is all quite depressing. It appears the clspec is quite
deficient in this regard. Hence, I think the proper goal for GCL is
to be as close to posix and "intuition" in this regard while still
passing the spec.

+1 for supporting posix.

Post by Camm Maguire
The whole goal was 1) to support pathnames with spaces, ala mingw, and
2) to provide some natural means within the spec for distinguishing a
directory from a file. clisp seems appropriate for this, but does not
allow one to overlay delete-file et. al. for directories. This does
seem a good tradeoff on reflection, as any general overlay is going to
run afoul of all sorts of problems trying to #'open a directory and
#'read therefrom. If this perspective is the right one, all the spec
functions but #'directory should work only on files, and GCL should
provide functions in 'si to do the directory manipulations outside the
spec.

Yes.

Post by Camm Maguire
As they are outside the spec, is there any reason not to implement
these where possible with #'system? The bourne shell is likely at
least as portable as GCL is. I was worried about the following
sprintf(command, "shopt -s dotglob; "
"IFS='' j=\"%s\"; for i in $j ; do ! [ -e \"$i\" ] || %c [ -d \"$i\" ] || echo \"$i\" ; done", filename, ch);
but I think it likely that this will even work on mingw.

Well, that depends on what you mean by "work". At the present time gcl
builds on MSYS/mingw as a *native* Windows application. MSYS/mingw is
only required to build gcl from source. Standard native windows does
not have any of these unix-oriented #system tools. Doing what you
suggest would result in gcl only working from within the MSYS/mingw
shell.
Of course there is also the issue of gcc on Windows which is needed
when compiling. In the case of installing a native Windows Axiom, the
install program includes the bare minimum mingw gcc components in a
separate directory along with Axiom. Installation of mingw is not a
prerequisite.

How big is the mingw-ex-gcc? Is it unreasonable to include the full
environment in the installer? Even macosx has bash.

Speaking of which, does anyone know how to make the mingw installer
for the next GCL release?

Post by Bill Page
Although it requires a little more knowledge of Windows internals, I
strongly recommend that gcl on windows continue to call the windows
API instead of relying on external support for posix/unix commands in
a particular shell that is not native to Windows. For similar reasons
I also would not recommend trying to utilize the Windows non-posix
command interpreter for this purpose.

I'm happy to go along with this, though I'm not sure what benefit the
user would see other than a little less disk space usage. I can only
justify minimal time learning anything windows specific for this
purpose, but of course will eagerly accept all offers of assistance in
this regard.

Now perhaps there is just a lower level api to which I could write
that would transparently be portable. E.g. implementing directory via
readdir and opendir. Re-implementing all the shell pattern matching
from scratch is certainly doable, but there should be some clear
benefit visible that would justify the work. Its hard for me to see
at the moment.

Please see related post regarding an extra-spec posix support function
proposal.

Take care,

Post by Bill Page
Regards,
Bill Page.

[Bill Page]

Post by Camm Maguire
...
How big is the mingw-ex-gcc? Is it unreasonable to include the full
environment in the installer? Even macosx has bash.

Well first of all you need to distinguish between MinGW and MSYS.

See: http://www.mingw.org

What is MinGW?

MinGW ("Minimalistic GNU for Windows") refers to a set of runtime
headers, used in building a compiler system based on the GNU GCC and
binutils projects. It compiles and links code to be run on Win32
platforms... providing C, C++ and Fortran compilers plus other related
tools. If you see references to "mingw32" instead of "MinGW", they are
referring to the same compiler system. The project's name changed from
mingw32 to MinGW is to prevent the implication that MinGW will only
works on 32 bit systems (as 64 and higher bit machines become more
common, MinGW will evolve to work with them). MinGW uses the Microsoft
runtime libraries, distributed with the Windows operating system.
Unlike other ports of GCC to Windows, the runtime libraries are not
distributed using Gnu's General Public License (GPL). You, therefore,
do not have to distribute your source code with your programs unless,
of course, you use a GPL library in your programs..

What is MSYS?

MSYS or Minimal SYStem is a POSIX and Bourne shell environment use
with MinGW. It provides a hand picked set of tools to allow a typical
configuration script with Bourne syntax to execute. This allows most
of the GNU packages to create a Makefile just from executing the
typical configure script which can then be used to build the package
using the native MinGW version of GCC.

The POSIX layer used by MSYS is a fork of the 1.3.3 version of Cygwin
. Cygwin is a full POSIX layer and UNIX-like environment for Win32
providing both server and client utilites.

-------

So in short MinGW is the gcc compiler system for windows and MSYS is
the rest of a simple posix-compliant development environment (unix
tools like ls, rm, mv and optionally bash). It is quite possible to
use MinGW without MSYS by relying on the Windows command line
environment or from an IDE that supports MinGW.

On my Windows system MinGW is 90 Mbytes and MSYS is 40 Mbytes. So, yes
I think it would be unreasonable to include all of this in a gcl
installer. The part of MinGW that is included with the Axiom on
Windows installer is only about 4 Mbytes. This provides only the gcc C
compiler and the necessary libraries required to compile code
generated by GCL. It does not include any of the MSYS components.

Post by Camm Maguire
Speaking of which, does anyone know how to make the mingw installer
for the next GCL release?

I forget exactly what installer Mike Thomas used for the last gcl
binary for Windows but there are seveal good open source ones to
choose from. We used NSIS for Axiom on Windows.

Post by Camm Maguire

Post by Bill Page
Although it requires a little more knowledge of Windows internals, I
strongly recommend that gcl on windows continue to call the windows
API instead of relying on external support for posix/unix commands in
a particular shell that is not native to Windows. For similar reasons
I also would not recommend trying to utilize the Windows non-posix
command interpreter for this purpose.

I'm happy to go along with this, though I'm not sure what benefit the
user would see other than a little less disk space usage. I can only
justify minimal time learning anything windows specific for this
purpose, but of course will eagerly accept all offers of assistance in
this regard.

Although MSYS can access the full Windows file system, it does so in a
way that would be unfamilar and somewhat unnatural to a Windows user.
It is better to think of MSYS as a porting environment rather than a
replacement posix shell for Windows users. Of course this probably
could be hidden by some clever programming in gcl but a fear that it
might also be a source of problems.

I understand your reluctance to spend much time learning windows
specific API details. In spite of limited available time, I am willing
to help with this where/when I can, but my only real experience is
that gained while working with Mike Thomas for a few months a few
years ago on the previous version Axiom on Windows. I do not think I
know enough about either Windows or GCL internals.

Post by Camm Maguire
Now perhaps there is just a lower level api to which I could write
that would transparently be portable. E.g. implementing directory via
readdir and opendir. Re-implementing all the shell pattern matching
from scratch is certainly doable, but there should be some clear
benefit visible that would justify the work. Its hard for me to see
at the moment.

Some of these things might be available in an MSYS library but I do
not know how accessible or adaptable to gcl it would be. In any case I
seriously doubt that it would end up being "transparently portable".

Post by Camm Maguire
Please see related post regarding an extra-spec posix support function
proposal.

Yes, I think that's good. Now we just need to find resources to help
implement this for gcl-2.7 on windows. I am also a little worried that
because of the extensive differences in 2.7 memory management and
other deep changes, there may be some more issues besides the file
system waiting to be discovered in the windows port. :-( Has anyone
actually attempted to build gcl-2.7 on Windows yet?

Regards,
Bill Page.

[Camm Maguire]

Greetings!

Post by Bill Page
I understand your reluctance to spend much time learning windows
specific API details. In spite of limited available time, I am willing
to help with this where/when I can, but my only real experience is
that gained while working with Mike Thomas for a few months a few
years ago on the previous version Axiom on Windows. I do not think I
know enough about either Windows or GCL internals.

Many thanks for the kind offer. It is much appreciated. I can step
you through any issue with GCL internals, as I did Mike Thomas when he
was first starting. But I do not wish to lay too great a burden here
as I'm sure you are quite busy.

My proposal is as follows -- if you can help here it would be great!

1) help debug read-char-no-hang to satisfy Vadim on 2.6.8
2) test mkdir et.al. auxiliary directory functions for axiom possibly
to be ported to 2.6.8.
3) generate a 2.6.8 installer.

4) ignore 2.7.0 for mingw until someone shows real interest in it, at
which time I'd be most happy to help. 2.6.8 will always be there
to suffice, and decoupling 2.7.0 from mingw will liberate
development. Who knows, with any luck, Windows itself will go the
way of histories dustbin by the time this is ever an issue.

Take care,

Post by Bill Page

Post by Camm Maguire
Now perhaps there is just a lower level api to which I could write
that would transparently be portable. E.g. implementing directory via
readdir and opendir. Re-implementing all the shell pattern matching
from scratch is certainly doable, but there should be some clear
benefit visible that would justify the work. Its hard for me to see
at the moment.

Some of these things might be available in an MSYS library but I do
not know how accessible or adaptable to gcl it would be. In any case I
seriously doubt that it would end up being "transparently portable".

Post by Camm Maguire
Please see related post regarding an extra-spec posix support function
proposal.

Yes, I think that's good. Now we just need to find resources to help
implement this for gcl-2.7 on windows. I am also a little worried that
because of the extensive differences in 2.7 memory management and
other deep changes, there may be some more issues besides the file
system waiting to be discovered in the windows port. :-( Has anyone
actually attempted to build gcl-2.7 on Windows yet?

Mike Thomas did briefly, and the major issues were worked out at some
point. But unless you know someone willing to put in the time at some
fraction of his level, I think the proposal above is the most sound.

Thoughts most welcome.

Take care,

Post by Bill Page
Regards,
Bill Page.
_______________________________________________
Axiom-developer mailing list
http://lists.nongnu.org/mailman/listinfo/axiom-developer

[Gabriel Dos Reis]

Camm Maguire <***@enhanced.com> writes:

[...]

| 4) ignore 2.7.0 for mingw until someone shows real interest in it, at
| which time I'd be most happy to help. 2.6.8 will always be there
| to suffice, and decoupling 2.7.0 from mingw will liberate
| development. Who knows, with any luck, Windows itself will go the
| way of histories dustbin by the time this is ever an issue.


To my mind, this suggests that Axiom would be better off:

(1) dropping Lisp as its base runtime system as soon as possible. or
(2) moving to other open source Lisp system as soon as possible, in
particular those that support Windows.

-- Gaby

[Gabriel Dos Reis]

On Tue, 3 Jul 2007, Camm Maguire wrote:

| This is all quite depressing. It appears the clspec is quite
| deficient in this regard. Hence, I think the proper goal for GCL is
| to be as close to posix and "intuition" in this regard while still
| passing the spec.

Hi Camm,

Indeed, I believe that where ANSI Common Lisp is silent and or
deficient in terms of system programming, it makes sense for GCL
to borrow from POSIX specification. Mainstream proramming languages
that support system building either borrow from POSIX or have bindings
to POSIX.

[There is also an ongoing effort to have a POSIX binding for C++, and
the C++ committee is also considering adding support for POSIX thread,
independently of whatever the binding group does. ]

-- Gaby

[Gabriel Dos Reis]

On Wed, 4 Jul 2007, Waldek Hebisch wrote:

| Important thing is that clisp file handling can loose some functionality
| -- currently I do not know how to rename directory using clisp
| (apparently clisp 'rename-file' does not work on directories).

I believe that is OK by ANSI spec.

| Similarly, I do not not how to delete empty directory using clisp.

There is nothing in ANSI spec for deleting directories -- you
can create them, but you can't remove them using only ANSI spec.

I believe Camm recently offered to provide an extension if sufficient
interest is expressed.

[...]

| change directory
| make directory (done via C)
| get current directory name
| get absolute name of a directory
| delete file or directory
| rename file or directory
| find all files matching pattern "*.NRLIB/index.KAF"
| recursively copy directory with content (currently invokes the 'cp' program)
| copy file (likewise)


OK.

-- Gaby

[Camm Maguire]

Greetings!

Post by Gabriel Dos Reis
| Important thing is that clisp file handling can loose some functionality
| -- currently I do not know how to rename directory using clisp
| (apparently clisp 'rename-file' does not work on directories).
I believe that is OK by ANSI spec.
| Similarly, I do not not how to delete empty directory using clisp.
There is nothing in ANSI spec for deleting directories -- you
can create them, but you can't remove them using only ANSI spec.
I believe Camm recently offered to provide an extension if sufficient
interest is expressed.
[...]
| change directory
| make directory (done via C)
| get current directory name
| get absolute name of a directory
| delete file or directory
| rename file or directory
| find all files matching pattern "*.NRLIB/index.KAF"
| recursively copy directory with content (currently invokes the 'cp' program)
| copy file (likewise)

Question 1) -- as there are workarounds for mingw now with 2.6.x, does
it make sense to implement this transition only in 2.7.x and above?
No need for conditionals, etc. I only went down this road re: 2.6.x
as Gaby said he needed a backport of ensure-directories-exist.

Proposal:

Functionality Function Origin Portable Implemented

change directory si::chdir libc Yes? Yes

make directory (done via C) si::mkdir libc Yes? >=2.7

get current directory name si::getcwd libc Yes? Not yet

get absolute name of a directory truename GCL Hopefully Yes,
different
semantic
in

Post by Gabriel Dos Reis
=2.7

(trailing
slash required)

delete file or directory delete-file GCL Hopefully Yes
si::rmdir libc Yes? Not yet

rename file or directory rename-file GCL Hopefully Yes
si::rename libc Yes? Not yet

find all files matching pattern directory GCL Not yet Partial(1)
"*.NRLIB/index.KAF"

recursively copy directory with si::cp-a GCL Should be Not yet
content (currently invokes the to be
'cp' program built on
directory and si::cp.
copy file (likewise) si::cp GCL Should be Not yet
to be
built on
si::copy-stream and open.

(1) To be decided -- reimplement shell globbing in C ontop of openddir
and readdir, or ship mingw shell along with gcc in Windows
installer (verifying that the "limited" space support is adequate.)
(2) perhaps put new functions in a posix:: package, though that name
would be quite misleading given the contents.


Once this is nailed down, the rest should not be too hard.

Take care,

Post by Gabriel Dos Reis
OK.
-- Gaby

[Gabriel Dos Reis]

On Wed, 4 Jul 2007, Camm Maguire wrote:

| Question 1) -- as there are workarounds for mingw now with 2.6.x, does
| it make sense to implement this transition only in 2.7.x and above?
| No need for conditionals, etc. I only went down this road re: 2.6.x
| as Gaby said he needed a backport of ensure-directories-exist.

If the backport to 2.6.8 is not as straighfoward as it shuld have been,
then I'm happy to wait for gcl-2.6.9. Thanks!

-- Gaby

[d***@axiom-developer.org]

Camm,

Post by Camm Maguire

Post by d***@axiom-developer.org
All versions of Axiom have a local copy of GCL cached
so it would be fine to do the transition

So if an external GCL with the new semantics is present, will this
break any of the windows branches?

Well that was the basis of my question about a conditional flag for
old/new semantics. A conditional flag would make it possible to
customize the compile-time code for GCL-2.6.8 vs GCL-2.7.0. Even
without this an Axiom branch can handle this case by using a
known-good cached version or using the built-in zips/patch mechanism
against Axiom sources.

As far as I'm aware all of the branches have cached versions of GCL
which are guaranteed to work.

Axiom can be configured to work with any version of the GCL via a
GCLVERSION flag. Based on the setting of this flag the axiom build
is patched as follows.

Axiom has a directory called zips which keeps a couple cached versions
of GCL, usually the current and previous versions. It also has patch
files which are applied for each specific GCL version. Thus if someone
chooses GCL-2.6.8
the GCL-2.6.8.tgz is expanded in a subdirectory,
axiom-specific patches are applied,
the patched GCL is built
Axiom builds on the patched version.

So without a conditional flag the "coping mechanism" is to create
GCL-2.7.0 specific patch files against GCL and Axiom sources which
would be applied if the GCLVERSION chosen is GCL-2.7.0.

So, in general, I don't see that your changes will cause a problem.
We have dealt with this before and have machinery in place to cope.

Tim

[d***@axiom-developer.org]

Camm,

I would love Tim's and all the other developers' blessings as to
which snapshot of which branch is worthy to represent axiom in
Debian. Do we have consensus yet? I can work with either, new or
old.

I don't think you're going to ever get consensus.
But you can have my opinion. :-)

In order to understand my response better let me rephrase your
question in terms of GCL. If there were several branches of GCL which
one should be "published" as "GCL"? My opinion is that it should be
the stable version of the trunk. Special needs people can always fetch
from a CVS latest trunk or branch. Both GCL-2.6.8pre and GCL-2.7.0
have features but are still changing.

Based on that I believe that the Debian version should be based on the
last stable version of the system which is available everywhere
else. Thus I believe that we should "publish" as "Axiom" the version
from ***@Savannah, ***@Sourceforge, or ***@axiom-developer, all of
which are identical. Thus, ***@Debian would also be identical.

When we promote silver to the gold version I will be pushing out a
new stable release to all of the sites. If Ondrej and you are able
to help we can also bring the Debian version up to date at that time.

Tim

[Ondrej Certik]

Post by d***@axiom-developer.org
When we promote silver to the gold version I will be pushing out a
new stable release to all of the sites. If Ondrej and you are able
to help we can also bring the Debian version up to date at that time.

We can put the axiom debian things into the svn.debian.org, so that we
can both access it and I am willing to help to make it compile, but
only from the Debian side, because I am busy. Unfortunately I don't
have time to fix bugs that are not related to Debian.

Ondrej

[d***@axiom-developer.org]

Ondrej, Camm,

I'm willing to fix Axiom problems, help with GCL and the Debian port.

So the problem is actually in GCL, that it is still not stable
enough to do some serious work on top of it?

GCL is stable enough for Axiom in the versions we are using.

The current Gold version of Axiom uses GCL-2.6.8pre2 which works
fine everywhere. The current Debian version uses GCL-2.6.7 which
will still work for Axiom. So I don't believe that GCL on Debian
will be an issue at all.

Tim

[Ondrej Certik]

Post by d***@axiom-developer.org
GCL is stable enough for Axiom in the versions we are using.
The current Gold version of Axiom uses GCL-2.6.8pre2 which works
fine everywhere. The current Debian version uses GCL-2.6.7 which
will still work for Axiom. So I don't believe that GCL on Debian
will be an issue at all.

Great. So there should be an official tar.gz of Axiom, and if Camm
agrees, I'll create the debian modifications (only) in svn.debian.org
and I am suggesting to use svn-buildpackage, that will apply the
debian changes to the orig.tar.gz.

Ondrej

[Bill Page]

Post by d***@axiom-developer.org
...
The current Gold version of Axiom uses GCL-2.6.8pre2 which works
fine everywhere.

What is 'GCL-2.6.8pre2'? I cannot find this tag in the gcl cvs. Did
you really mean 'GCL-2.6.8pre'?

http://cvs.savannah.gnu.org/viewvc/gcl/?root=gcl

I believe that gcl-2.6.8pre is still officially unreleased and subject
to change. Shouldn't this (finally!) be frozen as release 'gcl-2.6.8'
before building an official release of Axiom on it?

In the case of Debian isn't the policy that Axiom must be built using
only a separately released version of gcl as a dependency? I think
'gcl-2.6.7' is still the official release on Debian, right?

Regards,
Bill Page.

[Camm Maguire]

Greetings!

I agree 2.6.8 has taken way too long -- my apologies.

Comments like this:

http://lists.gnu.org/archive/html/gcl-devel/2007-05/msg00036.html

have kept me back, together with lack of time and volunteers, of
course, to address it.

GCL is quite stable, (at least 2.6.x), but is very low-level and
novel, and as such is subject to the same issues confronting atlas,
lapack, etc -- "bit rot".

At the moment, I'm using the Debian package version number and
autobuilders to verify that gcl and all applications build atop the
current toolchain. I'm about to release 2.6.7-34, which is a current
2.6.8pre snapshot.

As you can see, in Debian stable, we have 2.6.7-32.

2.6.7-33 is failing to build on some platforms due to an ld segfault:

http://buildd.debian.org/build.cgi?pkg=gcl

I'm hoping this is temporary.

Here are the changelog entries through -34:

gcl (2.6.7-34) unstable; urgency=low

* add read-byte,read-sequence,write-byte,write-sequence support
* fix some float parsing inaccuracies
* support GNU_HASH sections, Closes: #426135
* safety 2 for certain low level functions in gcl_listlib.lsp, CLoses:
#415266

-- Camm Maguire <***@enhanced.com> Wed, 4 Jul 2007 16:23:25 -0400

gcl (2.6.7-33) unstable; urgency=low

* Fix leading underscore behavior of my_plt
* add sqrt to plttest.c
* disable-nls added to the binutils subconfigures to avoid msgfmt
dependency
* remove -lintl from powerpc-macosx.defs
* update to make-user-init from cvs head to support hol88, fix link on
mingw
* solaris-i386 support
* fix read-char-no-hang on mingw
* fast compile without wrap-literals
* sigaltstack support
* fix cerror

-- Camm Maguire <***@enhanced.com> Wed, 16 May 2007 12:45:40 -0400


The only thing absolutely critical is the GNU_HASH section support,
without which GCL .o file loading is broken by the latest gcc output.

In addition, it is likely that the sparc compiler will ICE:

http://buildd.debian.org/fetch.cgi?pkg=gclcvs;ver=2.7.0-75;arch=sparc;stamp=1183559393

meaning that gcl and axiom and maxima and hol88 will not enter testing
until this is fixed or we drop sparc support.

My only plans for 2.6.8 prior to release were:

build verification across all 12.
ensure-directories-exist if and only if axiom must have it
intel mac support
satisfy vadim on mingw.

If axiom would prefer, I can drop the second and third to accelerate a
2.6.8 official .tar.gz

Once everything works, we need 10 days after the slowest machine
completes the build for migration into testing. We may get some
speedup with high priority, but this setting is routinely ignored if
the package is new in any way.

I for one agree with Tim's definition of what should go in, but dearly
hope we can pull together and incorporate the best ideas into one
place. As far as Debian goes, one typically needs a .tar.gz released
officially somewhere before one begins.

So my suggestions:

1) While I iron out the gcl build issues in Debian, Tim hopefully in
consultation with the other axiom developers finalize a .tar.gz
2) Depending on how long this takes, axiom decides whether to use
2.6.8 or 2.7.0. (I still have hope that this will be seen as
preferable soon and I can consolidate and only support one tree.
But I imagine that it will be at least September should 2.7.0 be
desired. )
3) I'm hoping the existing contents of debian/ will need little
change, and only simplification. I of course welcome any
suggestions/patches thereto from Ondrej or others interested.
Is there any reason it won't just work as is?
4) help with bug reports, build issue workarounds, etc. from all most
appreciated. There will likely be a period of at least a few weeks
during which we need to monitor the buildd web pages daily and
follow up on problems. If any of you have access to rare machines
(esp arm, alpha -- several of these are no longer available to
ordinary Debian devlopers) and have gdb skills, this is most
useful.

In any case, I do not think axiom uploads to Debian should occur until
at least gcl and maxima migrate into testing.

Just my quick thoughts -- pardon the incoherence.

Take care,

Post by Bill Page

Post by d***@axiom-developer.org
...
The current Gold version of Axiom uses GCL-2.6.8pre2 which works
fine everywhere.

What is 'GCL-2.6.8pre2'? I cannot find this tag in the gcl cvs. Did
you really mean 'GCL-2.6.8pre'?
http://cvs.savannah.gnu.org/viewvc/gcl/?root=gcl
I believe that gcl-2.6.8pre is still officially unreleased and subject
to change. Shouldn't this (finally!) be frozen as release 'gcl-2.6.8'
before building an official release of Axiom on it?
In the case of Debian isn't the policy that Axiom must be built using
only a separately released version of gcl as a dependency? I think
'gcl-2.6.7' is still the official release on Debian, right?
Regards,
Bill Page.

[Ondrej Certik]

Post by Camm Maguire
3) I'm hoping the existing contents of debian/ will need little
change, and only simplification. I of course welcome any
suggestions/patches thereto from Ondrej or others interested.
Is there any reason it won't just work as is?

Do you have the Debian repository somewhere? (The one which we will be
using for testing, before you upload it to Debian) I'll try to send
patches or test, only I don't know what the current way of doing
things is.

Ondrej

[Camm Maguire]

Greetings!

Just update /etc/apt/sources.list accordingly and

apt-get source axiom

Take care,

Post by Ondrej Certik

Post by Camm Maguire
3) I'm hoping the existing contents of debian/ will need little
change, and only simplification. I of course welcome any
suggestions/patches thereto from Ondrej or others interested.
Is there any reason it won't just work as is?

Do you have the Debian repository somewhere? (The one which we will be
using for testing, before you upload it to Debian) I'll try to send
patches or test, only I don't know what the current way of doing
things is.
Ondrej

[Ondrej Certik]

Post by Camm Maguire
Greetings!
Just update /etc/apt/sources.list accordingly and
apt-get source axiom

Yes, but that is the one, which is already in Debian, which is old. I
meant the one we will be working on. Or do you have some private
repository?

Ondrej

[d***@axiom-developer.org]

Bill,

GCL-2.6.8pre2 is an Axiom internal version number.
It contains fixes to GCL that Camm made for Axiom.
It differs from GCL-2.6.8pre because of these fixes.

Gold zips include GCL-2.6.7, GCL-2.6.8pre, and GCL-2.6.8pre2 tgz files
and their associated patches. Since GCL-2.6.8pre has been the working
version for so long there have been intermediate fixes of interest.
Each cached version is a "known good" snapshot for building Axiom.

Axiom should build properly (albeit lacking fixes) by setting
GCLVERSION to any one of the three choices. As Axiom steps up to
the next version of GCL the prior working version is in the cache.
This allows A-B testing of Axiom and failure recovery. Older versions
are removed from the cache but their associated axiom-only patch
files are retained.

Tim

[d***@axiom-developer.org]

Bill,

Post by Bill Page
In the case of Debian isn't the policy that Axiom must be built
using only a separately released version of gcl as a dependency? I
think gcl-2.6.7 is still the official release on Debian, right?

Technically, Axiom doesn't depend on "a separately released version of
gcl" since, as I read it a "dependency" implies that someone needs to
do an apt-get for gcl and have the dependency listed in the rpm. We
don't need to do this since Gold, at least, cannot use an external gcl.

If Camm and Ondrej want to use GCL-2.6.7 they only need to set the
GCLVERSION variable in the top level makefile or to type:

make GCLVERSION=gcl-2.6.7

and it should build using that version.

Tim

[Ondrej Certik]

Post by d***@axiom-developer.org
Technically, Axiom doesn't depend on "a separately released version of
gcl" since, as I read it a "dependency" implies that someone needs to
do an apt-get for gcl and have the dependency listed in the rpm. We
don't need to do this since Gold, at least, cannot use an external gcl.
If Camm and Ondrej want to use GCL-2.6.7 they only need to set the
make GCLVERSION=gcl-2.6.7
and it should build using that version.

Yes, but generally it is a good philosophy to let each particular
distribution to handle all external programs (be it Debian, Ubuntu,
Gentoo, Suse or Mac OS X). Because otherwise axiom is just duplicating
the job that the distribution should do.

Ondrej

[Bill Page]

Post by d***@axiom-developer.org

Post by Bill Page
In the case of Debian isn't the policy that Axiom must be built
using only a separately released version of gcl as a dependency? I
think gcl-2.6.7 is still the official release on Debian, right?

Technically, Axiom doesn't depend on "a separately released version of
gcl" since, as I read it a "dependency" implies that someone needs to
do an apt-get for gcl and have the dependency listed in the rpm. We
don't need to do this since Gold, at least, cannot use an external gcl.
If Camm and Ondrej want to use GCL-2.6.7 they only need to set the
make GCLVERSION=gcl-2.6.7
and it should build using that version.

That is not how the current release of Axiom is built on Debian. Camm
patches the build system to do things in a very different way so that
among other things it uses an externally installed version of gcl
(like build-improvements and wh-sandbox but without all the autoconf
magic).

I understood that it was necessary for Camm to do this in order to
conform to Debian packaging standards. Of course it was also more
convenient for him to do this since he is also the Debian maintainer
for gcl.

Perhaps I should just shut-up and let Camm address this issue ...

Regards,
Bill Page.

[d***@axiom-developer.org]

Ondrej,

Post by Ondrej Certik
Yes, but generally it is a good philosophy to let each particular
distribution to handle all external programs (be it Debian, Ubuntu,
Gentoo, Suse or Mac OS X). Because otherwise axiom is just duplicating
the job that the distribution should do.

This has been debated extensively on this list and there are other
people here who agree with you, most notably Bill Page, which is why
he asked the question. This view implicitly assumes that users have
tools like apt-get and yum which can resolve dependencies. At least
one of my systems is still RedHat 9 and all dependencies in rpm files
have to be searched and resolved by hand, a daunting task at best.

Consider the current case, that there are several fixes in GCL that
Axiom uses but they are still in GCL-2.6.8pre. In fact, there are
different, unmarked versions of GCL-2.6.8pre which contain additional
fixes.

If a user gets a copy of Axiom and tries to build it they would be
immediately confronted with the task of installing GCL. They would
naturally install GCL-2.6.7 since that is the released version. They
would then find that the Axiom build would fail, either because
(a) it had the bug that GCL-2.6.8pre (some snapshot) fixes
or (b) axiom needed GCL-2.6.8pre to build, not GCL-2.6.7

Reporting the bug (a) would get the reply "that's been fixed".
Reporting the bug (b) would get the reply "get the CVS GCL".

In either case the potential Axiom user is confronted with a
non-working Axiom system. Thus we lose a potential Axiom user.

My philosophy is that Axiom should "just work".

[Bill Page]

Post by d***@axiom-developer.org
...
This has been debated extensively on this list and there are other
people here who agree with you, most notably Bill Page, which is why
he asked the question. This view implicitly assumes that users have
tools like apt-get and yum which can resolve dependencies. At least
one of my systems is still RedHat 9 and all dependencies in rpm files
have to be searched and resolved by hand, a daunting task at best.

Both build-improvements and wh-sandbox allow these dependencies to be
satisfied by downloading the addtional gcl and/or noweb sources. If
they are present in the source tree, then local versions of these are
built and used in turn to build Axiom. In fact build-improvements
still includes a gcl directory containing a recent snapshot of
gcl-2.6.8pre which is only used if an externally installed gcl is not
present or if specifically requested by a configure option.

Post by d***@axiom-developer.org
Consider the current case, that there are several fixes in GCL that
Axiom uses but they are still in GCL-2.6.8pre. In fact, there are
different, unmarked versions of GCL-2.6.8pre which contain additional
fixes.

I would think that in this case neither Axiom nor GCL are ready for an
official release.

Post by d***@axiom-developer.org
If a user gets a copy of Axiom and tries to build it they would be
immediately confronted with the task of installing GCL. They would
naturally install GCL-2.6.7 since that is the released version. They
would then find that the Axiom build would fail, either because
(a) it had the bug that GCL-2.6.8pre (some snapshot) fixes
or (b) axiom needed GCL-2.6.8pre to build, not GCL-2.6.7
Reporting the bug (a) would get the reply "that's been fixed".
Reporting the bug (b) would get the reply "get the CVS GCL".

[Ondrej Certik]

Post by d***@axiom-developer.org
This has been debated extensively on this list and there are other
people here who agree with you, most notably Bill Page, which is why
he asked the question. This view implicitly assumes that users have
tools like apt-get and yum which can resolve dependencies. At least
one of my systems is still RedHat 9 and all dependencies in rpm files
have to be searched and resolved by hand, a daunting task at best.

Yes, that's why those distributions that cannot handle dependecies are
receding. But I think if someone is still using those, he already
knows how to do these things by hand.

Post by d***@axiom-developer.org
Consider the current case, that there are several fixes in GCL that
Axiom uses but they are still in GCL-2.6.8pre. In fact, there are
different, unmarked versions of GCL-2.6.8pre which contain additional
fixes.

Yep, these needs to get to Debian first and then Axiom.

Post by d***@axiom-developer.org
If a user gets a copy of Axiom and tries to build it they would be
immediately confronted with the task of installing GCL. They would
naturally install GCL-2.6.7 since that is the released version. They
would then find that the Axiom build would fail, either because
(a) it had the bug that GCL-2.6.8pre (some snapshot) fixes
or (b) axiom needed GCL-2.6.8pre to build, not GCL-2.6.7
Reporting the bug (a) would get the reply "that's been fixed".
Reporting the bug (b) would get the reply "get the CVS GCL".
In either case the potential Axiom user is confronted with a
non-working Axiom system. Thus we lose a potential Axiom user.

I agree, the patches should be accepted to GCL and the GCL should get
into distributions, so that Axiom works out of the box.

Post by d***@axiom-developer.org
My philosophy is that Axiom should "just work".

[Camm Maguire]

Greetings! How does one enable lisp debugging in axiom, and get more
than
Take care,

[Bill Page]

Post by Camm Maguire
Greetings! How does one enable lisp debugging in axiom, and get more
than

?? Do you mean gcl --enable-debug? I have previously used this option
without an problems. Could you describe how and when you get this
message? I will try to reproduce.

Regards,
Bill Page.

[Camm Maguire]

Greetings!

Post by Bill Page

Post by Camm Maguire
Greetings! How does one enable lisp debugging in axiom, and get more
than

?? Do you mean gcl --enable-debug? I have previously used this option
without an problems. Could you describe how and when you get this
message? I will try to reproduce.

This was in furthering the GCL 2.7/axiom test build -- I'm at the
truename/directory syntax step. Already patched axiom-probe-file.

Take care,

Post by Bill Page
Regards,
Bill Page.

[d***@axiom-developer.org]

Camm,

Any lisp command can be executed with
)lisp (any sexpr)

also you can have axiom fall into lisp on error with
)set break break
or not fall into lisp with
)set break resume


Tim

[Camm Maguire]

Greetings!

1) 'boot::|NRTassocIndex| (and others) calls elt on dotted lists of
the form ('|domain| s . s), whereas the spec says elt must take a
proper list. elt is automatically inlined.

2) somewhere in boot (by the depsys stage),
si::universal-error-handler is redefined to an old call sequence,
breaking 2.7 error reporting.

Workaround --

SYSTEM>(eval `(defun elt ,@(cdr (subst 'sequence 'proper-sequence (function-src 'elt)))))

Warning: SIMPLE-WARNING: ELT is being redefined.
ELT

SYSTEM>(si::function-src 'elt)

(LAMBDA (SEQ N)
(DECLARE (OPTIMIZE (SAFETY 1)))
(CHECK-TYPE N SEQIND)
(CHECK-TYPE SEQ SEQUENCE)
(BLOCK ELT
(BLOCK ELT
(BLOCK ELT
(LET ((Q 0) R)
(IF (IF (LISTP SEQ)
(PROGN
(BLOCK ()
(LET ((L SEQ) (I 0))
(TAGBODY
#:G32678
(IF (NOT (OR (ENDP L) (>= I N)))
(PROGN
(TAGBODY)
(LET* ((#:G32679 (CDR L))
(#:G32680 (+ I 1)))
(SETQ L #:G32679)
(SETQ I #:G32680)
NIL)
(GO #:G32678))
(RETURN-FROM () (PROGN (SETQ Q I R L)))))))))
(CAR R)
(IF (IF (< N (SETQ Q (LENGTH SEQ))) (PROGN (SETQ R SEQ)))
(LET* ((#:G32681 R) (#:G32682 (THE SEQIND N)))
(COMPILER::CMP-AREF #:G32681 #:G32682))
(VALUES (ERROR 'TYPE-ERROR :DATUM N :EXPECTED-TYPE
(LIST 'INTEGER 0 (LIST Q)))))))))))
NIL
ELT

SYSTEM>(compile 'elt)

;; Compiling /tmp/gazonk0.lsp.
; (DEFUN ELT ...) is being compiled.
;; Warning: arg type mismatch in auto-proclamation (PROPER-SEQUENCE
(INTEGER 0)) -> (SEQUENCE
(INTEGER
0))

;; End of Pass 1.
;; End of Pass 2.
;; OPTIMIZE levels: Safety=1 (No runtime error checking), Space=0, Speed=3, (Debug quality ignored)
;; Finished compiling /tmp/gazonk0.o.
;; Loading /tmp/gazonk0.o
;; start address -T 0x102e000 ;; Finished loading /tmp/gazonk0.o
#<compiled-function ELT>
NIL
NIL

SYSTEM>

Note the new debugging functions of interest:

(si::function-src 'symbol)
(si::file 'symbol)
(si::sig 'symbol)
(si::callers 'symbol)
(si::callees 'symbol)

compiled functions can also be disassembled and re-compiled without
redefining from source.

Can we please leave universal-error-handler alone?

Thanks for the report!

I'll try to get compiler::link to propagate the ambient setting of *disable-recompile*.

Take care,

Post by Camm Maguire
This was in furthering the GCL 2.7/axiom test build -- I'm at the
truename/directory syntax step. Already patched axiom-probe-file.

I updated 2.7 from cvs and retried build. gcl build now fine on
and64 (but still does not install all files). I am trying to set
si::*disable-recompile* in the inital image, which is made via
compiler:link, but it seems that this setting is lost -- I must
set si::*disable-recompile* to t later.
After setting si::*disable-recompile* to t interpsys build fine.
After change to axiom-probe-file first bootstrap stage works
fine. But in the second stage I am getting strange failure.
compiling exported ~= : (S,S) -> Boolean
Signalled by LAMBDA-CLOSURE.
Condition in SYSTEM::CHECK-TYPE-SYMBOL [or a callee]: INTERNAL-SIMPLE-PROGRAM-ERROR: LAMBDA-CLOSURE [or a callee] requires more than one argument.
Broken at SYSTEM::CHECK-TYPE-SYMBOL. Type :H for Help.
1 (Continue) supply a new value of SYSTEM::SEQ.
2 Return to top level.
BOOT>>^MBOOT>>:bt
^M
#0 CHECK-TYPE-SYMBOL {symbol=system::seq,value=(|domain| s . s),type=system::proper-sequence,type-str...} [ihs=123]
#1 NRTassocIndex {loc0=(|Boolean|),loc1=|value|,loc2=(((# # # ...))),loc3=(((# # # ...))),loc4=ni...} [ihs=122]
#2 NRTgetLocalIndex1 {loc0=(|Boolean|),loc1=nil,loc2=(|##1| (|BasicType|) nil),loc3=t,loc4=t} [ihs=121]
#3 NRTgetLocalIndex {loc0=(|Boolean|)} [ihs=120]
#4 genDeltaSig {loc0=(|Boolean|)} [ihs=119]
#5 genDeltaEntry {loc0=(= (s (|Boolean|) s ...) (t (elt s #))),loc1=#\$} [ihs=118]
I do not understand what 'system::seq' is doing here: Axiom extensively
uses SEQ macro which is defined in "VMLISP" package. SEQ from system
package should not be used here -- the axiom-lisp.lisp file tries to
limit imports to symbols from "COMMON-LISP" package.
As usual, all this is on 64-bit Debian etch.
--
Waldek Hebisch

[Waldek Hebisch]

Post by Camm Maguire
Greetings!
1) 'boot::|NRTassocIndex| (and others) calls elt on dotted lists of
the form ('|domain| s . s), whereas the spec says elt must take a
proper list. elt is automatically inlined.
2) somewhere in boot (by the depsys stage),
si::universal-error-handler is redefined to an old call sequence,
breaking 2.7 error reporting.
Workaround --

Thanks for finding this error. Concerning si::universal-error-handler,
this is done by ancient code in spaderror.lisp. wh-sandbox constains
code to handle errors using Ansi condition system, but for GCL I still
used old handler. The patch below unconditionally switches error
handling to Ansi way (so it will probably break non-Ansi GCL).
The algebra build should work with no error handler present.

diff -u /home/s/test/tt/axiom2/wh-sandbox/src/interp/bookvol5.pamphlet wh-sandbox/src/interp/bookvol5.pamphlet
--- /home/s/test/tt/axiom2/wh-sandbox/src/interp/bookvol5.pamphlet 2007-06-13 03:16:18.000000000 +0200
+++ wh-sandbox/src/interp/bookvol5.pamphlet 2007-07-07 14:00:38.000000000 +0200
@@ -682,9 +682,6 @@
(setq |$currentLine| nil)
(restart0)
(|readSpadProfileIfThere|)
- #+(or :GCL :CCL)
- (|spad|)
- #-(or :GCL :CCL)
(handler-bind ((error #'spad-system-error-handler))
(|spad|))
)
diff -u /home/s/test/tt/axiom2/wh-sandbox/src/interp/spaderror.lisp.pamphlet wh-sandbox/src/interp/spaderror.lisp.pamphlet
--- /home/s/test/tt/axiom2/wh-sandbox/src/interp/spaderror.lisp.pamphlet 2007-06-14 14:45:05.000000000 +0200
+++ wh-sandbox/src/interp/spaderror.lisp.pamphlet 2007-07-07 13:59:59.000000000 +0200
@@ -48,14 +48,14 @@

;; this files contains basic routines for error handling
(in-package "BOOT")
-
+#|
#+(or :GCL :CCL)
(defun error-format (message args)
(let ((|$BreakMode| '|break|))
(declare (special |$BreakMode|))
(if (stringp message) (apply #'format nil message args) nil)))
+|#

-#-(or :GCL :CCL)
(defun error-format (c)
(let ((|$BreakMode| '|break|))
(declare (special |$BreakMode|))
@@ -79,6 +79,7 @@

;; following macro evaluates form returning Union(type-of form, "failed")

+#|
#+:GCL
(defmacro |trapNumericErrors| (form)
`(let ((|$oldBreakMode| |$BreakMode|)
@@ -87,8 +88,8 @@
(setq val (catch '|trapNumerics| ,form))
(if (eq val |$numericFailure|) val
(cons 0 val))))
+|#

-#-(or :GCL :CCL)
(defmacro |trapNumericErrors| (form)
`(handler-case (cons 0 ,form)
(arithmetic-error () |$numericFailure|)))
@@ -99,7 +100,6 @@
;; (setq val (errorset ,form))
;; (if (NULL val) |$numericFailure| (cons 0 (car val)))))

-#-(or :GCL :CCL)
(defun spad-system-error-handler (c)
(block nil
(setq |$NeedToSignalSessionManager| T)
@@ -115,7 +115,7 @@
(throw '|letPrint2| nil))))))


-
+#|
;; the following form embeds around the akcl error handler
#+:GCL
(eval-when
@@ -148,7 +148,7 @@
(apply system:universal-error-handler type correctable? op
continue-string error-string args )))))

-
+|#

[Waldek Hebisch]

Post by Camm Maguire
Greetings!
1) 'boot::|NRTassocIndex| (and others) calls elt on dotted lists of
the form ('|domain| s . s), whereas the spec says elt must take a
proper list. elt is automatically inlined.

I tried to redefine elt in the initial image -- it did not work
(I probably made some silly error). So I changed |NRTassocIndex|
to use nth. I got a misterous build failure:

------------------------------------------------------------------------
FunctionSpace is now explicitly exposed in frame initial
FunctionSpace will be automatically loaded when needed from
/var/tmp/hebisch/axp7/ax-build4/src/algebra/FS.NRLIB/code

)compile "ACFS.spad"

Segmentation violation: c stack ok:signalling error
Condition in $FINDFILE [or a callee]: INTERNAL-SIMPLE-ERROR: Caught fatal error [memory may be damaged]: Segmentation violation.


When I did the compilation by hand it went OK. However later
I got another error. AFAICS DFLOAT.spad is miscompiled. In
the spad file we have:

base() == FLOAT_-RADIX(0$%)$Lisp


the resulting Lisp is:

(DEFUN |DFLOAT;base;Pi;7| ($)
(PROG () (RETURN (FLOAT-RADIX '#<OBJNULL>))))

Also, with Ansi gcl-2.7.0 we get subtly different code, other Lisps
(gcl 2.6.8, sbcl, clisp) just give:

(DEFUN |DFLOAT;base;Pi;7| ($) (FLOAT-RADIX 0.0))

that is the outer PROG and RETURN are missing (I see this difference
for many other functions).

[Camm Maguire]

Greetings, and thanks!

Please be advised that nth at safety 0 will still segfault if you try
to cdr past the dot.

I'd like to take a look at the below, but I'm not sure my tree is in
sync with yours. Have you committed everything? If so, how to I
update with svn? Anything else I need to reproduce the error below?

Thanks!

Post by Waldek Hebisch

Post by Camm Maguire
Greetings!
1) 'boot::|NRTassocIndex| (and others) calls elt on dotted lists of
the form ('|domain| s . s), whereas the spec says elt must take a
proper list. elt is automatically inlined.

I tried to redefine elt in the initial image -- it did not work
(I probably made some silly error). So I changed |NRTassocIndex|
------------------------------------------------------------------------
FunctionSpace is now explicitly exposed in frame initial
FunctionSpace will be automatically loaded when needed from
/var/tmp/hebisch/axp7/ax-build4/src/algebra/FS.NRLIB/code
)compile "ACFS.spad"
Segmentation violation: c stack ok:signalling error
Condition in $FINDFILE [or a callee]: INTERNAL-SIMPLE-ERROR: Caught fatal error [memory may be damaged]: Segmentation violation.
When I did the compilation by hand it went OK. However later
I got another error. AFAICS DFLOAT.spad is miscompiled. In
base() == FLOAT_-RADIX(0$%)$Lisp
(DEFUN |DFLOAT;base;Pi;7| ($)
(PROG () (RETURN (FLOAT-RADIX '#<OBJNULL>))))
Also, with Ansi gcl-2.7.0 we get subtly different code, other Lisps
(DEFUN |DFLOAT;base;Pi;7| ($) (FLOAT-RADIX 0.0))
that is the outer PROG and RETURN are missing (I see this difference
for many other functions).
--
Waldek Hebisch

[Ralf Hemmecke]

If so, how to I update with svn?

Go to the top of your checked out tree (the one which still has a .svn
subdirectory). Then say

svn update

That's it.

If you have locally changed your tree, svn does not override your
changes but rather merges them with the newest code from the repository.

If you want to make sure that your tree is as the one in the repository say

svn update
svn revert -R .

Ralf

[Stephen Wilson]

Hello Waldek, Camm,

Post by Waldek Hebisch
When I did the compilation by hand it went OK. However later
I got another error. AFAICS DFLOAT.spad is miscompiled. In
base() == FLOAT_-RADIX(0$%)$Lisp
(DEFUN |DFLOAT;base;Pi;7| ($)
(PROG () (RETURN (FLOAT-RADIX '#<OBJNULL>))))

This is strange. My current build using latest gclcvs and a private
tree (a modestly hacked Silver), does not have this issue.

Steve

[Waldek Hebisch]

Post by Camm Maguire
Greetings, and thanks!
Please be advised that nth at safety 0 will still segfault if you try
to cdr past the dot.
I'd like to take a look at the below, but I'm not sure my tree is in
sync with yours. Have you committed everything? If so, how to I
update with svn? Anything else I need to reproduce the error below?

I am working still with revision 636, the same tree where I applied
several patches:

1) change to axiom-probe-file
2) spaderror patch
3) in several places I set si::*disable-recompile* to t
4) in NRTassocIndex elt is changed to nth
5) I skip initializing memory parameters

I did not commit those changes because most of patches is ATM
not aproproate in public version: 2 and 3 is 2.7.0 specific
4 will need more analysis/testing, 5 increased safe build time
from 8 hours to 12 hours (measured using 2.6.8 on 1.86 Intel
Core Duo) -- again I feel that effect of parameters needs
more analysis/testing.

The segfault is in safety 1 code -- given your description
I expect that nth may still segfault at safety 1 if the dotted
list is too short.

I suspect that segfault may be non-reproducible: I got segfault
earlier and after restarting make the build went further.

I am somewhat reluctant to redo the step with segfault, as it
took 3 hours to go trough that stage and it seems that I will
be unable to debug the segfault even if I reproduce it

I am now checking if the second problem (miscompilation) is
reproducible.

Attached you will find diff between build tree and revision 636.

[Camm Maguire]

Greetings! Just a suggestion, when testing 2.7.0, omit calls to
(emit-fn t). This was an older signature discovery mechanism which
I'm trying to replace by an automatic algorithm in 2.7. Already found
and fixed a bug do to the conflicts between new and old.

Take care,

[Camm Maguire]

Greetings! Again, I get

--->-->PlaneAlgebraicCurvePlot(constructor): Unexpected HT command: \indented
"\\indented{1}{Plot a NON-SINGULAR plane algebraic curve \\spad{p}(\\spad{x},{}\\spad{y}) = 0.} Author: Clifton \\spad{J}. Williamson Date Created: Fall 1988 Date Last Updated: 27 April 1990 Keywords: algebraic curve,{} non-singular,{} plot Examples: References:"

Error:
Signalled by COMPILER::COMPILE-FILE1.
INTERNAL-SIMPLE-READER-ERROR: Stream error on stream #<input stream "ACPLOT.NRLIB/ACPLOT.lsp">: The default dispatch macro signalled an error.

Broken at COMPILER::COMPILE-FILE1. Type :H for Help.
1 (Continue) Retry compiling file "ACPLOT.NRLIB/ACPLOT.lsp".
2 Retry compiling file "ACPLOT.NRLIB/ACPLOT.lsp".
3 Return to top level.
BOOT>>
cat ACPLOT.NRLIB/ACPLOT.lsp

(/VERSIONCHECK 2)

(DEFUN |ACPLOT;NFtoSF| (|x| $)
(PROG ()
(RETURN
(+ '#1=#((|DoubleFloat|)
(#<compiled-function |lookupComplete|> #1#
#(~= 231 |zero?| 237 |wholePart| 242 |unitNormal| 247
...

Is this the same issue as you are reporting (or related)?

Take care,

[Waldek Hebisch]

Post by Camm Maguire
Greetings! Again, I get
--->-->PlaneAlgebraicCurvePlot(constructor): Unexpected HT command: \indented
"\\indented{1}{Plot a NON-SINGULAR plane algebraic curve \\spad{p}(\\spad{x},{}\\spad{y}) = 0.} Author: Clifton \\spad{J}. Williamson Date Created: Fall 1988 Date Last Updated: 27 April 1990 Keywords: algebraic curve,{} non-singular,{} plot Examples: References:"
Signalled by COMPILER::COMPILE-FILE1.
INTERNAL-SIMPLE-READER-ERROR: Stream error on stream #<input stream "ACPLOT.NRLIB/ACPLOT.lsp">: The default dispatch macro signalled an error.
Broken at COMPILER::COMPILE-FILE1. Type :H for Help.
1 (Continue) Retry compiling file "ACPLOT.NRLIB/ACPLOT.lsp".
2 Retry compiling file "ACPLOT.NRLIB/ACPLOT.lsp".
3 Return to top level.
BOOT>>
cat ACPLOT.NRLIB/ACPLOT.lsp
(/VERSIONCHECK 2)
(DEFUN |ACPLOT;NFtoSF| (|x| $)
(PROG ()
(RETURN
(+ '#1=#((|DoubleFloat|)
(#<compiled-function |lookupComplete|> #1#
#(~= 231 |zero?| 237 |wholePart| 242 |unitNormal| 247
...
Is this the same issue as you are reporting (or related)?

At safety 3 this function compiles just fine. At safty 1 I get an
error earlier, in DFLOAT.lsp I see:

(DEFUN |DFLOAT;base;Pi;7| ($)
(PROG () (RETURN (FLOAT-RADIX '#<OBJNULL>))))


Now, #<OBJNULL> is IMHO very strong indication of memory corruption
(I see no legal way to produce it). OTOH the vector (value of '#1')
you see is clearly wrong in this place, but it looks like normal
Axiom domain vector. So ATM it not clear if both failures are related.

[Camm Maguire]

Greetings!

I discovered that make clean was leaving NRLIB directories and source
present in src/algebra. So I started afresh:

svn co https://axiom.svn.sourceforge.net/svnroot/axiom/branches/wh-sandbox
...
svn update -r 636
D src/input/bugs2007.input.pamphlet
U src/input/Makefile.pamphlet
U src/input/Makefile.in
U src/interp/daase.lisp.pamphlet
U src/interp/Makefile.pamphlet
U src/interp/Makefile.in
U src/interp/i-output.boot.pamphlet
U src/interp/unlisp.lisp.pamphlet
U src/lisp/axiom-lisp.lisp.pamphlet
U src/lisp/Makefile.in
U src/lisp/Makefile.pamphlet
U ChangeLog.wh
Updated to revision 636.
cat ../../whd|patch -p0
patching file src/interp/spaderror.lisp.pamphlet
patching file src/interp/interp-proclaims.lisp
patching file src/interp/Makefile.pamphlet
patching file src/interp/Makefile.in
patching file src/interp/bookvol5.pamphlet
patching file src/interp/nruncomp.boot.pamphlet
patching file src/lisp/axiom-lisp.lisp.pamphlet
patching file src/lisp/Makefile.in
patching file src/lisp/Makefile.pamphlet
./configure --with-lisp=$(pwd)/../../foo2/unixport/saved_ansi_gcl
make
...
finalizing NRLIB UPOLYC-
Processing UnivariatePolynomialCategory& for Browser database:
--------(vectorise ((Vector R) % (NonNegativeInteger)))---------
--------(makeSUP ((SparseUnivariatePolynomial R) %))---------
--------(unmakeSUP (% (SparseUnivariatePolynomial R)))---------
--------(multiplyExponents (% % (NonNegativeInteger)))---------
--------(divideExponents ((Union % failed) % (NonNegativeInteger)))---------
--------(monicDivide ((Record (: quotient %) (: remainder %)) % %))---------
--------(karatsubaDivide ((Record (: quotient %) (: remainder %)) % (NonNegativeInteger)))---------
--------(shiftRight (% % (NonNegativeInteger)))---------
--------(shiftLeft (% % (NonNegativeInteger)))---------
--------(pseudoRemainder (% % %))---------
--------(differentiate (% % (Mapping R R) %))---------
--------(discriminant (R %))---------
--------(resultant (R % %))---------
--------(elt ((Fraction %) (Fraction %) (Fraction %)))---------
--------(order ((NonNegativeInteger) % %))---------
--------(subResultantGcd (% % %))---------
--------(composite ((Union % failed) % %))---------
--------(composite ((Union (Fraction %) failed) (Fraction %) %))---------
--------(pseudoQuotient (% % %))---------
--------(pseudoDivide ((Record (: coef R) (: quotient %) (: remainder %)) % %))---------
--------(separate ((Record (: primePart %) (: commonPart %)) % %))---------
--------(additiveValuation (attribute))---------
--------(elt (R (Fraction %) R))---------
--------(integrate (% %))---------
--------constructor---------

(still going)

In foo2, I have gcl ansi cvs head built with --enable-debug to try to
catch any segfault.

Is it possible we're not getting a clean start on your previously
reported safety 1 bug re: OBJNULL?

Take care,

Post by Waldek Hebisch

Post by Camm Maguire
Greetings! Again, I get
--->-->PlaneAlgebraicCurvePlot(constructor): Unexpected HT command: \indented
"\\indented{1}{Plot a NON-SINGULAR plane algebraic curve \\spad{p}(\\spad{x},{}\\spad{y}) = 0.} Author: Clifton \\spad{J}. Williamson Date Created: Fall 1988 Date Last Updated: 27 April 1990 Keywords: algebraic curve,{} non-singular,{} plot Examples: References:"
Signalled by COMPILER::COMPILE-FILE1.
INTERNAL-SIMPLE-READER-ERROR: Stream error on stream #<input stream "ACPLOT.NRLIB/ACPLOT.lsp">: The default dispatch macro signalled an error.
Broken at COMPILER::COMPILE-FILE1. Type :H for Help.
1 (Continue) Retry compiling file "ACPLOT.NRLIB/ACPLOT.lsp".
2 Retry compiling file "ACPLOT.NRLIB/ACPLOT.lsp".
3 Return to top level.
BOOT>>
cat ACPLOT.NRLIB/ACPLOT.lsp
(/VERSIONCHECK 2)
(DEFUN |ACPLOT;NFtoSF| (|x| $)
(PROG ()
(RETURN
(+ '#1=#((|DoubleFloat|)
(#<compiled-function |lookupComplete|> #1#
#(~= 231 |zero?| 237 |wholePart| 242 |unitNormal| 247
...
Is this the same issue as you are reporting (or related)?

At safety 3 this function compiles just fine. At safty 1 I get an
(DEFUN |DFLOAT;base;Pi;7| ($)
(PROG () (RETURN (FLOAT-RADIX '#<OBJNULL>))))
Now, #<OBJNULL> is IMHO very strong indication of memory corruption
(I see no legal way to produce it). OTOH the vector (value of '#1')
you see is clearly wrong in this place, but it looks like normal
Axiom domain vector. So ATM it not clear if both failures are related.
--
Waldek Hebisch
_______________________________________________
Axiom-developer mailing list
http://lists.nongnu.org/mailman/listinfo/axiom-developer

[Camm Maguire]

Greetings!

Previous message a false alarm, as my fresh build just failed, though
not with any segfault. Again, but in a different place:

(DEFUN |DFLOAT;base;Pi;7| ($)
(PROG ()
(RETURN
(FLOAT-RADIX
'#1=#((|DoubleFloat|)
(#<compiled-function |lookupComplete|> #1#


Same function that you found with the objnull. Question -- what
function(s) write this source?

Take care,

[Waldek Hebisch]

Post by Camm Maguire
Greetings!
Previous message a false alarm, as my fresh build just failed, though
(DEFUN |DFLOAT;base;Pi;7| ($)
(PROG ()
(RETURN
(FLOAT-RADIX
'#1=#((|DoubleFloat|)
(#<compiled-function |lookupComplete|> #1#
Same function that you found with the objnull. Question -- what
function(s) write this source?

There are several functions involved. In case of #<OBJNULL> using
traces I see that |compDefineCapsuleFunction| function (defined
in 'define.boot.pamphlet') gets:

1> (|compDefineCapsuleFunction|
(DEF (|base|) (NIL) (NIL)
((|elt| |Lisp| FLOAT-RADIX) (|elt| $ (|Zero|))))
...
...


It seems that (|elt| $ (|Zero|)) give us '#<OBJNULL>. |elt| is
handled in 'compiler.boot.pamphlet':


2> (|compForm1| ((|elt| |Lisp| FLOAT-RADIX) (|elt| $ (|Zero|)))

3> (|compElt| (|elt| $ (|Zero|)) |$EmptyMode|
....
....
<3 (|compElt|
((|call| (XLAM |ignore| '#<OBJNULL>)) $

[Waldek Hebisch]

Post by Waldek Hebisch

Post by Camm Maguire
Greetings!
Previous message a false alarm, as my fresh build just failed, though
(DEFUN |DFLOAT;base;Pi;7| ($)
(PROG ()
(RETURN
(FLOAT-RADIX
'#1=#((|DoubleFloat|)
(#<compiled-function |lookupComplete|> #1#
Same function that you found with the objnull. Question -- what
function(s) write this source?

There are several functions involved. In case of #<OBJNULL> using
traces I see that |compDefineCapsuleFunction| function (defined
1> (|compDefineCapsuleFunction|
(DEF (|base|) (NIL) (NIL)
((|elt| |Lisp| FLOAT-RADIX) (|elt| $ (|Zero|))))
...
...
It seems that (|elt| $ (|Zero|)) give us '#<OBJNULL>. |elt| is
2> (|compForm1| ((|elt| |Lisp| FLOAT-RADIX) (|elt| $ (|Zero|)))
3> (|compElt| (|elt| $ (|Zero|)) |$EmptyMode|
....
....
<3 (|compElt|
((|call| (XLAM |ignore| '#<OBJNULL>)) $

I have narrowed down the problem:

compiling exported base : () -> PositiveInteger
1> (|genDeltaEntry| (|Zero| ($ $) (T (CONST $ 18))))
2> (|optDeltaEntry| |Zero| ($) $ CONST)
3> (|compiledLookup| |Zero| ((|DoubleFloat|))
#<vector 0000000002b66f90>)
<3 (|compiledLookup|
(|makeSpadConstant|
#<compiled-function |DFLOAT;Zero;$;15|>
#<vector 0000000002b66f90> 25))
<2 (|optDeltaEntry| (XLAM |ignore| '#<OBJNULL>))
<1 (|genDeltaEntry| (XLAM |ignore| '#<OBJNULL>))


|makeSpadConstant| calls its argument. Checking this I get:

)lisp (|DFLOAT;Zero;$;15| nil)

Value = #<OBJNULL>

)lisp (disassemble '|DFLOAT;Zero;$;15|)
^M
Condition in DISASSEMBLE [or a callee]: INTERNAL-SIMPLE-END-OF-FILE: Stream error on stream #<input stream "/tmp/gazonk0.c">: Unexpected end of file:

Looking at "/tmp/gazonk0.c" I see:


#include "cmpinclude.h"
#include "gazonk0.h"
void init__tmp_gazonk0(){do_init((void *)VV);}
/* local entry for function DFLOAT;Zero;$;15 */

static double LI1__DFLOAT$Zero$$$15___gazonk0(V2)

object V2;
{ VMB1 VMS1 VMV1
goto TTL;
TTL:;
/*(FLOAT 0 MOST-POSITIVE-DOUBLE-FLOAT)*/
{fixnum V3;
V3= (fixnum)0;
V3= (fixnum)0;
{double V4 = ( 1. )*((fixnum)0);VMR1
(V4);}}
/* END (FLOAT 0 MOST-POSITIVE-DOUBLE-FLOAT)*/
{double V5 = lf(Cnil);VMR1
(V5);}
}
/* global entry for the function DFLOAT;Zero;$;15 */

static void L1__DFLOAT$Zero$$$15___gazonk0()
{ register object *base=vs_base;
check_arg(1);
base[0]=make_longfloat(LI1__DFLOAT$Zero$$$15___gazonk0((base[0])));
vs_top=(vs_base=base)+1;
}

#ifdef SYSTEM_SPECIAL_INIT
SYSTEM_SPECIAL_INIT
#endif


The assignment to V5 looks wrong...

The file DFLOAT.o where |DFLOAT;Zero;$;15| lives was compiled in
the previous step.

[Camm Maguire]

Greetings! And thanks for the report!

Post by Waldek Hebisch

Post by Waldek Hebisch

Post by Camm Maguire
Greetings!
Previous message a false alarm, as my fresh build just failed, though
(DEFUN |DFLOAT;base;Pi;7| ($)
(PROG ()
(RETURN
(FLOAT-RADIX
'#1=#((|DoubleFloat|)
(#<compiled-function |lookupComplete|> #1#
Same function that you found with the objnull. Question -- what
function(s) write this source?

There are several functions involved. In case of #<OBJNULL> using
traces I see that |compDefineCapsuleFunction| function (defined
1> (|compDefineCapsuleFunction|
(DEF (|base|) (NIL) (NIL)
((|elt| |Lisp| FLOAT-RADIX) (|elt| $ (|Zero|))))
...
...

In which package is this? Is it present in interpsys?

Post by Waldek Hebisch

Post by Waldek Hebisch
It seems that (|elt| $ (|Zero|)) give us '#<OBJNULL>. |elt| is
2> (|compForm1| ((|elt| |Lisp| FLOAT-RADIX) (|elt| $ (|Zero|)))
3> (|compElt| (|elt| $ (|Zero|)) |$EmptyMode|
....
....
<3 (|compElt|
((|call| (XLAM |ignore| '#<OBJNULL>)) $

Can you please post the full call to compElt in 3> above?

Post by Waldek Hebisch
compiling exported base : () -> PositiveInteger
1> (|genDeltaEntry| (|Zero| ($ $) (T (CONST $ 18))))
2> (|optDeltaEntry| |Zero| ($) $ CONST)
3> (|compiledLookup| |Zero| ((|DoubleFloat|))
#<vector 0000000002b66f90>)
<3 (|compiledLookup|
(|makeSpadConstant|
#<compiled-function |DFLOAT;Zero;$;15|>
#<vector 0000000002b66f90> 25))
<2 (|optDeltaEntry| (XLAM |ignore| '#<OBJNULL>))
<1 (|genDeltaEntry| (XLAM |ignore| '#<OBJNULL>))

Why are there 3 arguments above? The definition appears to take one.

Post by Waldek Hebisch
)lisp (|DFLOAT;Zero;$;15| nil)
Value = #<OBJNULL>
)lisp (disassemble '|DFLOAT;Zero;$;15|)
^M

This is a simple .h file naming bug I'll try to fix soon.

Post by Waldek Hebisch
#include "cmpinclude.h"
#include "gazonk0.h"
void init__tmp_gazonk0(){do_init((void *)VV);}
/* local entry for function DFLOAT;Zero;$;15 */
static double LI1__DFLOAT$Zero$$$15___gazonk0(V2)
object V2;
{ VMB1 VMS1 VMV1
goto TTL;
TTL:;
/*(FLOAT 0 MOST-POSITIVE-DOUBLE-FLOAT)*/
{fixnum V3;
V3= (fixnum)0;
V3= (fixnum)0;
{double V4 = ( 1. )*((fixnum)0);VMR1
(V4);}}
/* END (FLOAT 0 MOST-POSITIVE-DOUBLE-FLOAT)*/
{double V5 = lf(Cnil);VMR1
(V5);}

This is correct but unpleasant C which needs tidying. There can be
extra 'unwinds' scheduled currently in GCL -- these are harmless but
misleading. The function returns from the macro VMR1. I'll try to
clean this up too.

Why does this function take an argument which is ignored -- is this right?

The compElt above, together with which package it is in, the full call
from your trace output, and at what stage the function has appeared
(and is called) will I think do the trick -- thank you so much!!

Take care,

Post by Waldek Hebisch
}
/* global entry for the function DFLOAT;Zero;$;15 */
static void L1__DFLOAT$Zero$$$15___gazonk0()
{ register object *base=vs_base;
check_arg(1);
base[0]=make_longfloat(LI1__DFLOAT$Zero$$$15___gazonk0((base[0])));
vs_top=(vs_base=base)+1;
}
#ifdef SYSTEM_SPECIAL_INIT
SYSTEM_SPECIAL_INIT
#endif
The assignment to V5 looks wrong...
The file DFLOAT.o where |DFLOAT;Zero;$;15| lives was compiled in
the previous step.
--
Waldek Hebisch

[Waldek Hebisch]

Post by Camm Maguire

Post by Waldek Hebisch

Post by Waldek Hebisch
There are several functions involved. In case of #<OBJNULL> using
traces I see that |compDefineCapsuleFunction| function (defined
1> (|compDefineCapsuleFunction|
(DEF (|base|) (NIL) (NIL)
((|elt| |Lisp| FLOAT-RADIX) (|elt| $ (|Zero|))))
...
...

In which package is this? Is it present in interpsys?

First a little correction: there are two versions on
|compDefineCapsuleFunction|, one in 'define.boot.pamphlet' and
the second one in 'br-saturn.boot.pamphlet'. Normally version
from 'br-saturn.boot.pamphlet' is in use.

All functions in question are defined in "BOOT" package. The
files are autoloaded. To get the traces I did (in the algebra
build directory):

(export AXIOM=/h/axp62/ax-build2/target/x86_64-unknown-linux; export DAASE=/h/axp62/wh-sandbox/src/share; /h/axp62/ax-build2/build/x86_64-unknown-linux/bin/interpsys )
)lisp (|oldCompilerAutoloadOnceTrigger|)
)lisp (trace |compElt| |compileCases| |compDefineCapsuleFunction| |compForm1|)
)compile "DFLOAT.spad"

That produced about 150 Mb trace.

To be extra careful you may also do (before tracing):

)lisp (|browserAutoloadOnceTrigger|)

to load correct version of |compDefineCapsuleFunction|.

Post by Camm Maguire

Post by Waldek Hebisch

Post by Waldek Hebisch
It seems that (|elt| $ (|Zero|)) give us '#<OBJNULL>. |elt| is
2> (|compForm1| ((|elt| |Lisp| FLOAT-RADIX) (|elt| $ (|Zero|)))
3> (|compElt| (|elt| $ (|Zero|)) |$EmptyMode|
....
....
<3 (|compElt|
((|call| (XLAM |ignore| '#<OBJNULL>)) $

Can you please post the full call to compElt in 3> above?

The third argument is large (75 kb), so I have put call to |compElt|
and return value at:

http://www.math.uni.wroc.pl/~hebisch/compElt.txt

Post by Camm Maguire

Post by Waldek Hebisch
compiling exported base : () -> PositiveInteger
1> (|genDeltaEntry| (|Zero| ($ $) (T (CONST $ 18))))
2> (|optDeltaEntry| |Zero| ($) $ CONST)
3> (|compiledLookup| |Zero| ((|DoubleFloat|))
#<vector 0000000002b66f90>)
<3 (|compiledLookup|
(|makeSpadConstant|
#<compiled-function |DFLOAT;Zero;$;15|>
#<vector 0000000002b66f90> 25))
<2 (|optDeltaEntry| (XLAM |ignore| '#<OBJNULL>))
<1 (|genDeltaEntry| (XLAM |ignore| '#<OBJNULL>))

Why are there 3 arguments above? The definition appears to take one.

(|makeSpadConstant|
#<compiled-function |DFLOAT;Zero;$;15|>
#<vector 0000000002b66f90> 25)

is not a call, it is just a list of length four. This list is
passed to the SPADCALL macro with the effect that car of the list
is called with cdr as na argument (using SPADCALL is an abuse here...).

Post by Camm Maguire

Post by Waldek Hebisch
)lisp (|DFLOAT;Zero;$;15| nil)
Value = #<OBJNULL>
)lisp (disassemble '|DFLOAT;Zero;$;15|)
^M

This is a simple .h file naming bug I'll try to fix soon.

Post by Waldek Hebisch
#include "cmpinclude.h"
#include "gazonk0.h"
void init__tmp_gazonk0(){do_init((void *)VV);}
/* local entry for function DFLOAT;Zero;$;15 */
static double LI1__DFLOAT$Zero$$$15___gazonk0(V2)
object V2;
{ VMB1 VMS1 VMV1
goto TTL;
TTL:;
/*(FLOAT 0 MOST-POSITIVE-DOUBLE-FLOAT)*/
{fixnum V3;
V3= (fixnum)0;
V3= (fixnum)0;
{double V4 = ( 1. )*((fixnum)0);VMR1
(V4);}}
/* END (FLOAT 0 MOST-POSITIVE-DOUBLE-FLOAT)*/
{double V5 = lf(Cnil);VMR1
(V5);}

This is correct but unpleasant C which needs tidying. There can be
extra 'unwinds' scheduled currently in GCL -- these are harmless but
misleading. The function returns from the macro VMR1. I'll try to
clean this up too.

I mean that 'lf(Cnil)' looks strange -- Axiom expects double
precision 0 as the result.

Post by Camm Maguire
Why does this function take an argument which is ignored -- is this right?

Yes, |DFLOAT;Zero;$;15| is a Spad function. All Spad function receive
an extra argument: the domain or package to which they belong. This
extra argument appears last in the argument list. |DFLOAT;Zero;$;15|
does not need any extra information from its domain, so the
argument is ignored, but in general it may be used. If one wants
to pass "correct" value of the argument one has to do:

)lisp (|DoubleFloat|)
)lisp (|DFLOAT;Zero;$;15| (|DoubleFloat|))

the first call to |DoubleFloat| is triggers autolading of DFLOAT.o file.

If I do the above in 2.6.8 compiled interpsys I get floating point
0. In 2.7.0 compiled interpsys (the one from the failing build) I get
#<OBJNULL>

[Camm Maguire]

Greetings, and thanks! The problem is that the global entries to the
functions returning double float etc. are not being writtin into
DFLOAT.c. I'm trying to debug by reproducing the compile-file step on
DFLOAT.lsp. This fails at the lisp prompt:

(compile-file "DFLOAT.NRLIB/DFLOAT.lsp")

; (DEFUN |DFLOAT;manexp| ...) is being compiled.
;;; The tag #:G2017215 is undefined.
; (DEFUN |DFLOAT;rationalApproximation;$2NniF;84| ...) is being compiled.
;;; The tag #:G2017237 is undefined.
;;; The tag G190 is undefined.
; (DEFUN |DFLOAT;**;$F$;85| ...) is being compiled.
;;; The tag #:G2017246 is undefined.
;;; The tag #:G2017246 is undefined.
No FASL generated.

Error:
Fast links are on: do (si::use-fast-links nil) for debugging
Signalled by BREAK.
Condition in BREAK [or a callee]: INTERNAL-SIMPLE-PROGRAM-ERROR: Compilation of "DFLOAT.NRLIB/DFLOAT.lsp" failed.

Broken at BREAK. Type :H for Help.
1 Retry compiling file "DFLOAT.NRLIB/DFLOAT.lsp".
2 Retry compiling file "DFLOAT.NRLIB/DFLOAT.lsp".
3 (Abort) Return to debug level 2.
4 (Continue) Return from break.
5 Return to top level.
COMPILER>>

Then I try )co "DFLOAT.spad" from the axiom prompt:

)co "DFLOAT.spad"
Your command is ambiguous. The following are abbreviated by co :
compiler
copyright
(1) -> )quit
Please enter y or yes if you really want to leave the interactive
environment and return to the operating system:
y
You have chosen to remain in the AXIOM interactive environment.
(1) -> 
(1) ->
Program exited normally.

So I try a fresh interpsys, set the stage 1 bootstrap mode flag, And
find a very long chain of compiles which must proceed before I can
compile DFLOAT.

I'm sure I'm just making some simple mistake, but how can one rebuild
just DFLOAT from any given stage in the build? This will enable me to
fix this.

Take care,

Post by Waldek Hebisch

Post by Camm Maguire

Post by Waldek Hebisch

Post by Waldek Hebisch
There are several functions involved. In case of #<OBJNULL> using
traces I see that |compDefineCapsuleFunction| function (defined
1> (|compDefineCapsuleFunction|
(DEF (|base|) (NIL) (NIL)
((|elt| |Lisp| FLOAT-RADIX) (|elt| $ (|Zero|))))
...
...

In which package is this? Is it present in interpsys?

First a little correction: there are two versions on
|compDefineCapsuleFunction|, one in 'define.boot.pamphlet' and
the second one in 'br-saturn.boot.pamphlet'. Normally version
from 'br-saturn.boot.pamphlet' is in use.
All functions in question are defined in "BOOT" package. The
files are autoloaded. To get the traces I did (in the algebra
(export AXIOM=/h/axp62/ax-build2/target/x86_64-unknown-linux; export DAASE=/h/axp62/wh-sandbox/src/share; /h/axp62/ax-build2/build/x86_64-unknown-linux/bin/interpsys )
)lisp (|oldCompilerAutoloadOnceTrigger|)
)lisp (trace |compElt| |compileCases| |compDefineCapsuleFunction| |compForm1|)
)compile "DFLOAT.spad"
That produced about 150 Mb trace.
)lisp (|browserAutoloadOnceTrigger|)
to load correct version of |compDefineCapsuleFunction|.

Post by Camm Maguire

Post by Waldek Hebisch

Post by Waldek Hebisch
It seems that (|elt| $ (|Zero|)) give us '#<OBJNULL>. |elt| is
2> (|compForm1| ((|elt| |Lisp| FLOAT-RADIX) (|elt| $ (|Zero|)))
3> (|compElt| (|elt| $ (|Zero|)) |$EmptyMode|
....
....
<3 (|compElt|
((|call| (XLAM |ignore| '#<OBJNULL>)) $

Can you please post the full call to compElt in 3> above?

The third argument is large (75 kb), so I have put call to |compElt|
http://www.math.uni.wroc.pl/~hebisch/compElt.txt

Post by Camm Maguire

Post by Waldek Hebisch
compiling exported base : () -> PositiveInteger
1> (|genDeltaEntry| (|Zero| ($ $) (T (CONST $ 18))))
2> (|optDeltaEntry| |Zero| ($) $ CONST)
3> (|compiledLookup| |Zero| ((|DoubleFloat|))
#<vector 0000000002b66f90>)
<3 (|compiledLookup|
(|makeSpadConstant|
#<compiled-function |DFLOAT;Zero;$;15|>
#<vector 0000000002b66f90> 25))
<2 (|optDeltaEntry| (XLAM |ignore| '#<OBJNULL>))
<1 (|genDeltaEntry| (XLAM |ignore| '#<OBJNULL>))

Why are there 3 arguments above? The definition appears to take one.

(|makeSpadConstant|
#<compiled-function |DFLOAT;Zero;$;15|>
#<vector 0000000002b66f90> 25)
is not a call, it is just a list of length four. This list is
passed to the SPADCALL macro with the effect that car of the list
is called with cdr as na argument (using SPADCALL is an abuse here...).

Post by Camm Maguire

Post by Waldek Hebisch
)lisp (|DFLOAT;Zero;$;15| nil)
Value = #<OBJNULL>
)lisp (disassemble '|DFLOAT;Zero;$;15|)
^M

This is a simple .h file naming bug I'll try to fix soon.

Post by Waldek Hebisch
#include "cmpinclude.h"
#include "gazonk0.h"
void init__tmp_gazonk0(){do_init((void *)VV);}
/* local entry for function DFLOAT;Zero;$;15 */
static double LI1__DFLOAT$Zero$$$15___gazonk0(V2)
object V2;
{ VMB1 VMS1 VMV1
goto TTL;
TTL:;
/*(FLOAT 0 MOST-POSITIVE-DOUBLE-FLOAT)*/
{fixnum V3;
V3= (fixnum)0;
V3= (fixnum)0;
{double V4 = ( 1. )*((fixnum)0);VMR1
(V4);}}
/* END (FLOAT 0 MOST-POSITIVE-DOUBLE-FLOAT)*/
{double V5 = lf(Cnil);VMR1
(V5);}

This is correct but unpleasant C which needs tidying. There can be
extra 'unwinds' scheduled currently in GCL -- these are harmless but
misleading. The function returns from the macro VMR1. I'll try to
clean this up too.

I mean that 'lf(Cnil)' looks strange -- Axiom expects double
precision 0 as the result.

Post by Camm Maguire
Why does this function take an argument which is ignored -- is this right?

Yes, |DFLOAT;Zero;$;15| is a Spad function. All Spad function receive
an extra argument: the domain or package to which they belong. This
extra argument appears last in the argument list. |DFLOAT;Zero;$;15|
does not need any extra information from its domain, so the
argument is ignored, but in general it may be used. If one wants
)lisp (|DoubleFloat|)
)lisp (|DFLOAT;Zero;$;15| (|DoubleFloat|))
the first call to |DoubleFloat| is triggers autolading of DFLOAT.o file.
If I do the above in 2.6.8 compiled interpsys I get floating point
0. In 2.7.0 compiled interpsys (the one from the failing build) I get
#<OBJNULL>
--
Waldek Hebisch
_______________________________________________
Axiom-developer mailing list
http://lists.nongnu.org/mailman/listinfo/axiom-developer

[Camm Maguire]

Greetings! The disassemble bug we saw earlier (end of file) is due to
a redefinition of compiler::gazonk-name somewhere in your tree. (We
now have a different format for temporary file names.)

Would it be possible to summarize any gcl lisp functions for which
patching/redefinition is felt necessary in axiom, and work toward
eliminating same? The current situation will just create more work as
GCL and axiom evolve.

[Stephen Wilson]

Post by Camm Maguire
Greetings! The disassemble bug we saw earlier (end of file) is due to
a redefinition of compiler::gazonk-name somewhere in your tree. (We
now have a different format for temporary file names.)
Would it be possible to summarize any gcl lisp functions for which
patching/redefinition is felt necessary in axiom, and work toward
eliminating same? The current situation will just create more work as
GCL and axiom evolve.

Pending a full audit, I believe that with the current patchset against
silver there is no trampling on GCL functions or symbols. Between
compiler:link and exported syms there is no reason, as far as I can
tell, for Axiom to insist on trying to manage GCL internals or patch.

We can always work towards enriching exported interfaces if needed in
the future.


Sincerely,
Steve

[Waldek Hebisch]

Post by Camm Maguire
Greetings! The disassemble bug we saw earlier (end of file) is due to
a redefinition of compiler::gazonk-name somewhere in your tree. (We
now have a different format for temporary file names.)

gazonk-name is redefined in file 'util.lisp.pamphlet' at line 1531.
I considered removing this definition -- currently GCL version
is better. However, currently I decided to keep Axiom version,
because I belive that GCL version would just mask (but does not
really solve) problems with gazonk names.

Namely, there is a bug, see:

http://www.mail-archive.com/axiom-***@nongnu.org/msg09476.html

With GCL version we still would have a bug, just one extremally unlikely
(due to random names) to bite. As I wrote in the message at URL
above, I belive that for Axiom the best way would be to create
a gazonk directory, making sure it is owned by the user running Axiom
and to put gazonk file there.

Post by Camm Maguire
Would it be possible to summarize any gcl lisp functions for which
patching/redefinition is felt necessary in axiom, and work toward
eliminating same? The current situation will just create more work as
GCL and axiom evolve.

The general direction is to use umodified/unpatched gcl, and in general
to limit dependency on GCL internals. I belive that currently almost
all dependencies are conditional (otherwise sbcl/clisp port would not
work). My intension is keep non-portable (using conditionals) code
separately from the rest of Axiom.

[Stephen Wilson]

... I belive that for Axiom the best way would be to create
a gazonk directory, making sure it is owned by the user running Axiom
and to put gazonk file there.

Any reason why the exported si:*tmp-dir* does not suffice?

Thanks,
Steve

[Waldek Hebisch]

Post by Camm Maguire
Greetings, and thanks! The problem is that the global entries to the
functions returning double float etc. are not being writtin into
DFLOAT.c. I'm trying to debug by reproducing the compile-file step on
(compile-file "DFLOAT.NRLIB/DFLOAT.lsp")
; (DEFUN |DFLOAT;manexp| ...) is being compiled.
;;; The tag #:G2017215 is undefined.
; (DEFUN |DFLOAT;rationalApproximation;$2NniF;84| ...) is being compiled.
;;; The tag #:G2017237 is undefined.
;;; The tag G190 is undefined.
; (DEFUN |DFLOAT;**;$F$;85| ...) is being compiled.
;;; The tag #:G2017246 is undefined.
;;; The tag #:G2017246 is undefined.
No FASL generated.
Fast links are on: do (si::use-fast-links nil) for debugging
Signalled by BREAK.
Condition in BREAK [or a callee]: INTERNAL-SIMPLE-PROGRAM-ERROR: Compilation of "DFLOAT.NRLIB/DFLOAT.lsp" failed.
Broken at BREAK. Type :H for Help.
1 Retry compiling file "DFLOAT.NRLIB/DFLOAT.lsp".
2 Retry compiling file "DFLOAT.NRLIB/DFLOAT.lsp".
3 (Abort) Return to debug level 2.
4 (Continue) Return from break.
5 Return to top level.
COMPILER>>
)co "DFLOAT.spad"
compiler
copyright
(1) -> )quit
Please enter y or yes if you really want to leave the interactive
y
You have chosen to remain in the AXIOM interactive environment.
(1) -> 
(1) ->
Program exited normally.
So I try a fresh interpsys, set the stage 1 bootstrap mode flag, And
find a very long chain of compiles which must proceed before I can
compile DFLOAT.
I'm sure I'm just making some simple mistake, but how can one rebuild
just DFLOAT from any given stage in the build? This will enable me to
fix this.

All Axiom generated Lisp file use special macros, present in interpsys.
Theoretically all macros are also present in depsys image, but I did
not check if depsys works for Lisp compilation of algebra files.
Error messages from Lisp compilation probably can be explained by lack
of macros. But behavoir of ')co' (and also ')quit') command looks
strange -- I prefer to always use full version ')compile', but for
me ')co' starts compilation. Also the

"You have chosen to remain in the AXIOM interactive environment."

message looks like a bug.

Spad compilation is slightly more tricky: given spad file may require
that several other files are compiled earlier. When Spad compiler
operates in default mode there are cyclic dependencies. Basically the
whole bootstrap procedure is to fight with those cyclic dependencies.
Stage 1 of bootstrap must go in a rather rigid order. After stage 1 of
bootstrap it should be possible to compile all Spad files using special
|$bootstrapDomains| flag. Once Stage 2 is finished it should be
possible to compile all normal mode.

If you want to compile a single file after stage 1 finished do the following.

1) start interpsys, you need to correctly set up AXIOM and DAASE variables,
for me the it is below:

( export AXIOM=/h/axp62/ax-build2/target/x86_64-unknown-linux; export DAASE=/h/axp62/wh-sandbox/src/share; /h/axp62/ax-build2/build/x86_64-unknown-linux/bin/interpsys )

2) for stage 2 compilation set the |$bootstrapDomains| flag:

)lisp (setf |$bootstrapDomains| t)

Value = T

3) issue compilation command:

(2) -> )compile "DFLOAT.spad"


If you want you can also do Lisp compilation:

(1) -> )lisp (compile-file "DFLOAT.NRLIB/DFLOAT.lsp")

Value = #P"/h/axp62/ax-build2/src/algebra/DFLOAT.NRLIB/DFLOAT.o"
(1) ->

Trying the above I noticed that doing by hand stage 2 compilation of
"DFLOAT.spad" I can also do stage 3 compilation of "DFLOAT.spad".
So the problem seem to appear only if I do all compilations in a
single image...

Normally Lisp files from stage 2 compilation are deleted before
starting stage 3 compilation. I changed the Makefile to capture
the result from stage 2 compilation. Comparing with the Lisp file
obtained separately I see some differences, but none which can explain
different behavior of object code.

[Camm Maguire]

Greetings!

OK the issue is that you are setting the compiler::fixed-args property
-- a legacy function signature facility which may have even been
implemented to support axiom for all that I know. The short fix is to
stop setting this property and let GCL figure out the signature on its
own.

In more detail, this flag was intended to allow the user to assert a
signature of the form '((t t t) t). A better way follows acl2,
(declaim (ftype (function (t t t) t) foo)), which is supported by the
ansi standard and is compatible with the new automatic function
signature discovery mechanism. But either signature would be wrong
here as the functions in question return double float. These cannot
be supported via the fastlink mechanism as the return type does not
portably fit in one machine word. GCL compiles such (at safety <=2)
as a local C function returning double, and a global wrapper boxing
the double into a lisp object. GCL is incorrectly relying on
'fixed-args to determine that a wrapper is not necessary.

If 'fixed-args is to be kept, I need to make it compatible with the
automatic function signature discovery, but the simplest for me would
be to ignore the property, depending on axiom's needs. It seems
redundant with declaim anyway. Thoughts welcome.

Take care,

Post by Waldek Hebisch

Post by Camm Maguire
Greetings, and thanks! The problem is that the global entries to the
functions returning double float etc. are not being writtin into
DFLOAT.c. I'm trying to debug by reproducing the compile-file step on
(compile-file "DFLOAT.NRLIB/DFLOAT.lsp")
; (DEFUN |DFLOAT;manexp| ...) is being compiled.
;;; The tag #:G2017215 is undefined.
; (DEFUN |DFLOAT;rationalApproximation;$2NniF;84| ...) is being compiled.
;;; The tag #:G2017237 is undefined.
;;; The tag G190 is undefined.
; (DEFUN |DFLOAT;**;$F$;85| ...) is being compiled.
;;; The tag #:G2017246 is undefined.
;;; The tag #:G2017246 is undefined.
No FASL generated.
Fast links are on: do (si::use-fast-links nil) for debugging
Signalled by BREAK.
Condition in BREAK [or a callee]: INTERNAL-SIMPLE-PROGRAM-ERROR: Compilation of "DFLOAT.NRLIB/DFLOAT.lsp" failed.
Broken at BREAK. Type :H for Help.
1 Retry compiling file "DFLOAT.NRLIB/DFLOAT.lsp".
2 Retry compiling file "DFLOAT.NRLIB/DFLOAT.lsp".
3 (Abort) Return to debug level 2.
4 (Continue) Return from break.
5 Return to top level.
COMPILER>>
)co "DFLOAT.spad"
compiler
copyright
(1) -> )quit
Please enter y or yes if you really want to leave the interactive
y
You have chosen to remain in the AXIOM interactive environment.
(1) -> 
(1) ->
Program exited normally.
So I try a fresh interpsys, set the stage 1 bootstrap mode flag, And
find a very long chain of compiles which must proceed before I can
compile DFLOAT.
I'm sure I'm just making some simple mistake, but how can one rebuild
just DFLOAT from any given stage in the build? This will enable me to
fix this.

All Axiom generated Lisp file use special macros, present in interpsys.
Theoretically all macros are also present in depsys image, but I did
not check if depsys works for Lisp compilation of algebra files.
Error messages from Lisp compilation probably can be explained by lack
of macros. But behavoir of ')co' (and also ')quit') command looks
strange -- I prefer to always use full version ')compile', but for
me ')co' starts compilation. Also the
"You have chosen to remain in the AXIOM interactive environment."
message looks like a bug.
Spad compilation is slightly more tricky: given spad file may require
that several other files are compiled earlier. When Spad compiler
operates in default mode there are cyclic dependencies. Basically the
whole bootstrap procedure is to fight with those cyclic dependencies.
Stage 1 of bootstrap must go in a rather rigid order. After stage 1 of
bootstrap it should be possible to compile all Spad files using special
|$bootstrapDomains| flag. Once Stage 2 is finished it should be
possible to compile all normal mode.
If you want to compile a single file after stage 1 finished do the following.
1) start interpsys, you need to correctly set up AXIOM and DAASE variables,
( export AXIOM=/h/axp62/ax-build2/target/x86_64-unknown-linux; export DAASE=/h/axp62/wh-sandbox/src/share; /h/axp62/ax-build2/build/x86_64-unknown-linux/bin/interpsys )
)lisp (setf |$bootstrapDomains| t)
Value = T
(2) -> )compile "DFLOAT.spad"
(1) -> )lisp (compile-file "DFLOAT.NRLIB/DFLOAT.lsp")
Value = #P"/h/axp62/ax-build2/src/algebra/DFLOAT.NRLIB/DFLOAT.o"
(1) ->
Trying the above I noticed that doing by hand stage 2 compilation of
"DFLOAT.spad" I can also do stage 3 compilation of "DFLOAT.spad".
So the problem seem to appear only if I do all compilations in a
single image...
Normally Lisp files from stage 2 compilation are deleted before
starting stage 3 compilation. I changed the Makefile to capture
the result from stage 2 compilation. Comparing with the Lisp file
obtained separately I see some differences, but none which can explain
different behavior of object code.
--
Waldek Hebisch

[Gabriel Dos Reis]

Camm Maguire <***@enhanced.com> writes:

[...]

| If 'fixed-args is to be kept, I need to make it compatible with the
| automatic function signature discovery, but the simplest for me would
| be to ignore the property, depending on axiom's needs. It seems
| redundant with declaim anyway. Thoughts welcome.

Axiom should be fixed not to use 'fixed-args.

-- Gaby

[Waldek Hebisch]

Post by Camm Maguire
Greetings!
OK the issue is that you are setting the compiler::fixed-args property
-- a legacy function signature facility which may have even been
implemented to support axiom for all that I know. The short fix is to
stop setting this property and let GCL figure out the signature on its
own.

Thanks, I have disabled setting fixed-args property. This allowed
to go trough algebra at safety 1. To dump databases I needed to
upgrade gcl to current cvs. I see rather bad test results. It is
possible that some problems are due to upgraging gcl during the
build, so I started a fresh one.

Post by Camm Maguire
In more detail, this flag was intended to allow the user to assert a
signature of the form '((t t t) t). A better way follows acl2,
(declaim (ftype (function (t t t) t) foo)), which is supported by the
ansi standard and is compatible with the new automatic function
signature discovery mechanism. But either signature would be wrong
here as the functions in question return double float. These cannot
be supported via the fastlink mechanism as the return type does not
portably fit in one machine word. GCL compiles such (at safety <=2)
as a local C function returning double, and a global wrapper boxing
the double into a lisp object. GCL is incorrectly relying on
'fixed-args to determine that a wrapper is not necessary.
If 'fixed-args is to be kept, I need to make it compatible with the
automatic function signature discovery, but the simplest for me would
be to ignore the property, depending on axiom's needs. It seems
redundant with declaim anyway. Thoughts welcome.

I would like the 'fixed-args property to go away. However, we
need to some work to make Axiom faster and to know which
techniques are effective.