Subject: [clisp-list] Re: [clisp-announce] GNU CLISP 2.31 release

From: Michael Koehne <[email-masked]>
Date: Wed Sep 3 17:40:31 2003

Moin Sam Steingold,
  
> GNU CLISP 2.31 (2003-09-01) is now available from the usual distribution
> sites.

  I just tried them, and I have bad news ;( 2.31 failed regression test
  with a segmentation fault on Debian/Woody (stable / gcc 2.95.4) and
  much before on Debian/Sarge (unstable / gcc 3.3.2). The Woody system
  is still able to compile 2.30 - while the Sarge system also fails on
  on clisp 2.30 - I'll step back to gcc 3.2.3 tomorrow.

Woody
    (PPRINT-DISPATCH NIL T) 
    OK: TYPE-ERROR
    (PPRINT-EXIT-IF-LIST-EXHAUSTED) 
    OK: ERROR
    (PPRINT-INDENT NIL 2) 
    OK: ERROR
    (LET ((X (MAKE-STRING-OUTPUT-STREAM))) (PPRINT-LOGICAL-BLOCK (X NIL :PREFIX 24))) 
    OK: TYPE-ERROR
    (LET ((X (MAKE-STRING-OUTPUT-STREAM))) (PPRINT-LOGICAL-BLOCK (X NIL :PREFIX "a" :PER-LINE-PREFIX "b"))) 
    OK: ERROR
    (PPRINT-NEWLINE :FRESH) 
    OK: TYPE-ERROR
    (PPRINT-POP) 
    OK: ERROR
    (PPRINT-TAB :PARAGRAPH 0 1) 
    OK: ERROR
    (LET ((*PRINT-READABLY* T)) (PRINT-UNREADABLE-OBJECT (NIL *STANDARD-OUTPUT*))) 
    OK: PRINT-NOT-READABLE
    (PRINT 1 2) make[1]: *** [tests] Segmentation fault
    make[1]: Leaving directory `/bakunin/export/home/kraehe/lisp/clisp-2.31/src/suite'
    make: *** [testsuite] Error 2
    bakunin:~/lisp/clisp-2.31/src $ 

Sarge
    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-2003

    ;; Loading file defseq.lisp ...
    ;; Loaded file defseq.lisp
    ;; Loading file backquote.lisp ...
    ;; Loaded file backquote.lisp
    ;; Loading file defmacro.lisp ...
    ;; Loaded file defmacro.lisp
    ;; Loading file macros1.lisp ...
    ;; Loaded file macros1.lisp
    ;; Loading file macros2.lisp ...
    ;; Loaded file macros2.lisp
    ;; Loading file defs1.lisp ...
    ;; Loaded file defs1.lisp
    ;; Loading file places.lisp ...
    ;; Loaded file places.lisp
    ;; Loading file floatprint.lisp ...
    ;; Loaded file floatprint.lisp
    ;; Loading file type.lisp ..../lisp.run: relocation error: /usr/lib/gconv/CP932.so: undefined symbol: STANDARD_ERR_HANDLER
    make: *** [interpreted.mem] Error 127
    makhno:~/clisp-2.31/src $ 

Sarge - clisp 2.30
    installing clisplow_fr.gmo as ../locale/fr/LC_MESSAGES/clisplow.mo
    installing es.gmo as ../locale/es/LC_MESSAGES/clisp.mo
    installing clisplow_es.gmo as ../locale/es/LC_MESSAGES/clisplow.mo
    installing nl.gmo as ../locale/nl/LC_MESSAGES/clisp.mo
    installing clisplow_nl.gmo as ../locale/nl/LC_MESSAGES/clisplow.mo
    installing ru.gmo as ../locale/ru/LC_MESSAGES/clisp.mo
    installing clisplow_ru.gmo as ../locale/ru/LC_MESSAGES/clisplow.mo
    make[1]: Leaving directory `/home/kraehe/clisp-2.30/src/po'
    rm -rf data
    mkdir data
    cd data && ln -s ../../utils/unicode/ftp.unicode.org/UnicodeData.txt .
    cd data && ln -s ../../src/clhs.txt .
    gcc -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type  -fomit-frame-pointer -Wno-sign-compare -O2 -fexpensive-optimizations -DUNICODE -DDYNAMIC_FFI -DNO_SIGSEGV -x none spvw.o spvwtabf.o spvwtabs.o spvwtabo.o eval.o control.o encoding.o pathname.o stream.o socket.o io.o array.o hashtabl.o list.o package.o record.o sequence.o charstrg.o debug.o error.o misc.o time.o predtype.o symbol.o lisparit.o i18n.o foreign.o unixaux.o ari80386.o modules.o libcharset.a libavcall.a libcallback.a -lreadline -lncurses  -ldl   -o lisp.run
    sync
    ./lisp.run -B . -N locale -Efile UTF-8 -Eterminal UTF-8 -norc -m 750KW -x "(load \"init.lisp\") (sys::%saveinitmem) (exit)"

    *** - FUNCALL: the function GRAY::STREAM-WRITE-CHAR-SEQUENCE is undefined
    1. Break> 

-- 
  mailto:[email-masked]             UNA:+.? 'CED+2+:::Linux:2.4.18'UNZ+1'
  http://www.xml-edifact.org/           CETERUM CENSEO WINDOWS ESSE DELENDAM

---

From: amit phalgune <[email-masked]>
Date: Wed Sep 3 17:53:08 2003

Hi CLISP users,

I am trying to create a clinet server application.
The server side is in CLISP and the client is java. There are calls sent
from Java to CLISP ( the server side).
I have been through the impnotes.html about the Socket Streams. I am using
the socket-server function with the port number as a parameter. The
function returns me a socket number like :
#<SOCKET-SERVER 0.0.0.0:49152> , where 49152 is the port number ,I sent to
te socket-server function.
Now the client , when connecting to the LISP side ( I guess looks for a
numeric value like : 6 or 7 ( basically the socket number in a numeric
format.) I cannot change the client side code to accept the new format of
the socket number.
Can you guys suggest me how I can go about this whole thing, with the
CLISP calls returning me a socket number ( numeric).
If that is not poosible, can u let me know if I am using the correct
function ( socket-server). Am I supposed to use socket-connect or
socket-accept.

P.S : I am trying the whole procedure on a windows machine.

Thanks
Amit

---

From: "John K. Hinsdale" <[email-masked]>
Date: Wed Sep 3 18:58:04 2003

> The server side is in CLISP and the client is java.

I think these days if you have such a setup you are encouraged to use
the "SOAP" standard which lets you define a "web service."  However, I
know of no SOAP implementation for Lisp.  Maybe I could do what I did
w/ FastCGI and make bindings for a "C" implementation such as Apache
Axis.  Hmmmm...

 > I am using the socket-server function with the port number as a
 > parameter.

Yes that it probably what you want for the server side in Lisp.

 > The function returns me a socket number like : #<SOCKET-SERVER
 > 0.0.0.0:49152> , where 49152 is the port number ,I sent to te
 > socket-server function.

Actually the function SOCKET-SERVER does not returna number, but
rather a Lisp of a special type, also called SOCKET-SERVER.  E.g.:

    [1]> (setf s (socket-server 49152))
    #<SOCKET-SERVER 0.0.0.0:49152>
    [2]> (type-of s)
    SOCKET-SERVER
    [3]> (describe s)
    
    #<SOCKET-SERVER 0.0.0.0:49152> is 
    *** - The value of (TYPE-OF SYSTEM::OBJ) must be one of FOREIGN-POINTER, FFI:FOREIGN-ADDRESS, FFI:FOREIGN-VARIABLE, FFI:FOREIGN-FUNCTION, BYTE, SPECIAL-OPERATOR, LOAD-TIME-EVAL, SYMBOL-MACRO, MACRO, FUNCTION-MACRO, ENCODING, WEAK-POINTER, SYSTEM::READ-LABEL, SYSTEM::FRAME-POINTER, SYSTEM::SYSTEM-INTERNAL, ADDRESS
    The value is: SOCKET-SERVER
    1. Break [4]> 

As you can see, a SOCKET-SERVER cannot be described; looks like a
CLISP glitch since I believe you should be able to describe anything.

 > Now the client , when connecting to the LISP side ( I guess looks for
 > a numeric value like : 6 or 7 ( basically the socket number in a
 > numeric format.)

What the client is really trying to do is establish the connection
using two pieces of info: the IP address and the port number.  The IP
address and port the Java client uses is determined on the Java side.
The port number used to create the SERVER-SOCKET in Lisp must agree
with the port number used by the Java client.  You are sure that port
number 49152 is what is being used by Java?

Is your Java client documented?  If so it should tell you what port it
users.  If not, there are tools for GNU/Linux (tcpdump) that will let
you observe what port Java is using.  Consider GNU/Linux.

 > I cannot change the client side code to accept the new format of the
 > socket number.  Can you guys suggest me how I can go about this whole
 > thing, with the CLISP calls returning me a socket number ( numeric).

Once the CLISP function SOCKET-SERVER returns, your Lisp server
program is in a state where it is not "listening" for connections.  At
this point the custom is to create a loop where you "accept" client
connections.  After each connection is accepted, you then handle the
data traffic over the socket connection.  Then the loop continues.
FYI, there are two important flavors of such a loop: (1) where the
handling of the connection is done in a separate thread of processing,
launched by calling fork() or other call, and (2) where the handling
is all done completely before the loop continues and accepts a new
connection.  But don't worry about this for now.

 > function ( socket-server). Am I supposed to use socket-connect or

On the CLISP side, because it is the server, you would be using
SOCKET-SERVER to being listening on the TCP port, and, in your loop,
SOCKET-ACCEPT to handle connections from the client.  You would not
use SOCKET-CONNECT which is only relevant for the client side.

 > P.S : I am trying the whole procedure on a windows machine.

The concepts for how TCP and sockets work are the same on Unix and
windows.  TCP/IP is the great bridge b/w Unix and Windows really.  If
I had a nickel for every time a Windows-based browser connected to a
Unix-based Web server I'd be richer than Bill Gates. or maybe not.

Hope this helps.  Good luck.

---
John Hinsdale, Alma Mater Software, Inc., Tarrytown, NY 10591-3710 USA
[email-masked] | http://www.alma.com/staff/hin | +1 914 631 4690

---

From: "John K. Hinsdale" <[email-masked]>
Date: Wed Sep 3 19:03:11 2003

> program is in a state where it is not "listening" for connections.

Oops, I meant to say:

Once the CLISP function SOCKET-SERVER returns, your Lisp server
program is in a state where it is NOW "listening" for connections.

---

From: amit phalgune <[email-masked]>
Date: Wed Sep 3 23:39:05 2003

Hi,
I am looking for a LISP implementation ( preferably free ) (open source)
which supports multithreading and runs on windows, Max OS 10 , Unix and or
Sun machines.

Any pointers on this will be of great help

Thanks in advance
Amit

---

From: Russell Senior <[email-masked]>
Date: Thu Sep 4 01:51:03 2003

I am having a problem building CLISP 2.31 on a gentoo system
(linux-2.4.20-gentoo-r6) with glibc-2.3.2.  It is failing at:

gcc -O3 -mcpu=pentium3 -funroll-loops -pipe -I. -I../../../ffcall/callback/trampoline_r -c ../../../ffcall/callback/trampoline_r/trampoline.c -o trampoline.o
../../../ffcall/callback/trampoline_r/trampoline.c: In function `alloc_trampoline_r':
../../../ffcall/callback/trampoline_r/trampoline.c:455: `MAP_VARIABLE' undeclared (first use in this function)
../../../ffcall/callback/trampoline_r/trampoline.c:455: (Each undeclared identifier is reported only once
../../../ffcall/callback/trampoline_r/trampoline.c:455: for each function it appears in.)
make[2]: *** [trampoline.lo] Error 1
make[2]: Leaving directory `/var/tmp/portage/clisp-2.31/work/clisp-2.31/src/callback/trampoline_r'
make[1]: *** [all-subdirs] Error 2
make[1]: Leaving directory `/var/tmp/portage/clisp-2.31/work/clisp-2.31/src/callback'
make: *** [callback.h] Error 2

Grepping the the CLISP source I don't find a MAP_VARIABLE and grepping
in /usr/include/ (on either the Gentoo or a Debian system) I don't
find it either.  Help?

-- 
Russell Senior         ``shtal latta wos ba padre u prett tu nashtonfi
[email-masked]      mrlosh''  -- Bashgali Kafir for ``If you have
                         had diarrhoea many days you will surely die.''

---

From: Michael Koehne <[email-masked]>
Date: Thu Sep 4 06:21:08 2003

Moin Amit,

> Sun machines. Any pointers on this will be of great help

  *hm* 2105 Jan 5 1999 clisp-2.31/doc/multithread.txt :
: is currently being developed and does not work yet.

  this quote is ages old. And i dont know, if its true, because
  ./src/threads.lisp is from Jan 2003. You can try to get/patch
  the existing clisp code up and running *nudge*

  the other pointer I know about is someone on irc.freenode.net#lisp,
  who has his own multithreaded SBCL. But I doubt, that that his SBCL
  is portable accross named platforms.

Bye Michael

---

From: Michael Koehne <[email-masked]>
Date: Thu Sep 4 06:56:21 2003

Moin Russell Senior,

> in /usr/include/ (on either the Gentoo or a Debian system) I don't

  this is probately because, ./ffcall/trampoline.c tries :
       MAP_ANONYMOUS | MAP_VARIABLE
  while ./configure checked for :
       MAP_ANONYMOUS | MAP_PRIVATE

  the fix needs to be done starting at ./src/autoconf/aclocal.m4 and
  ffcall/autoconf/aclocal.m4 with great care, because MAP_PRIVATE flag
  has other semantics in other sources.
  
  The ugly fix would be to define in trampoline:

    #ifdef MAP_FIXED
    #ifndef MAP_VARIABLE                                                           
    #define MAP_VARIABLE 0                                                         
    #endif                                                                         
    #endif                                                                         

  MAP_VARIABLE is defined as the oposite of MAP_FIXED - its therefore
  zero, on systems that do not define it.

  btw: this did'nt happen on my Debian systems. But 2.31 failed
  regression test on both systems.

Bye Michael

---

From: Sam Steingold <[email-masked]>
Date: Thu Sep 4 07:22:18 2003

> * In message <[email-masked]>
> * On the subject of "Re: [clisp-announce] GNU CLISP 2.31 release"
> * Sent on Thu, 4 Sep 2003 02:39:13 +0200
> * Honorable Michael Koehne <[email-masked]> writes:
>
>   I just tried them, and I have bad news ;( 2.31 failed regression
>   test with a segmentation fault on Debian/Woody (stable / gcc 2.95.4)
>   and much before on Debian/Sarge (unstable / gcc 3.3.2). The Woody
>   system is still able to compile 2.30 - while the Sarge system also
>   fails on on clisp 2.30 - I'll step back to gcc 3.2.3 tomorrow.
>

see
<http://sourceforge.net/tracker/index.php?func=detail&aid=785605&group_id=1355&atid=101355>
<http://sourceforge.net/tracker/index.php?func=detail&aid=726433&group_id=1355&atid=101355>
Can you debug this?

>     ;; Loading file type.lisp ..../lisp.run: relocation error: /usr/lib/gconv/CP932.so: undefined symbol: STANDARD_ERR_HANDLER

I have no idea what this might mean.
are you using libiconv?  what is your glibc version?

>     *** - FUNCALL: the function GRAY::STREAM-WRITE-CHAR-SEQUENCE is undefined

no idea.
Bruno?

-- 
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.honestreporting.com>
Lisp is a way of life.  C is a way of death.

---

From: Will Newton <[email-masked]>
Date: Thu Sep 4 07:50:30 2003

On Thursday 04 September 2003 15:20, Sam Steingold wrote:

> >     ;; Loading file type.lisp ..../lisp.run: relocation error:
> > /usr/lib/gconv/CP932.so: undefined symbol: STANDARD_ERR_HANDLER
>

This is a Debian unstable glibc issue. Get the latest version.

---

From: Sam Steingold <[email-masked]>
Date: Thu Sep 4 08:20:21 2003

> * In message <[email-masked]>
> * Sent on 04 Sep 2003 01:50:11 -0700
> * Honorable Russell Senior <[email-masked]> writes:
>

CLISP checks for MAP_VARIABLE and thinks that if it it works then
MAP_VARIABLE is also present and works.

I wonder why...

-- 
Sam Steingold (http://www.podval.org/~sds) running w2k
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.honestreporting.com>
Warning! Dates in calendar are closer than they appear!

---

From: Michael Koehne <[email-masked]>
Date: Thu Sep 4 10:04:36 2003

Moin Sam Steingold,

> <http://sourceforge.net/tracker/index.php?func=detail&aid=726433&group_id=1355&atid=101355>

  those are a different can of worms, imho - my is related to streams.

> Can you debug this?

  [1]> (print "*STANDARD-OUTPUT*" *STANDARD-OUTPUT*)
  "*STANDARD-OUTPUT*" 
  "*STANDARD-OUTPUT*"
  [2]> (print "*STANDARD-OUTPUT*" 1)
  Segmentation fault
  bakunin:~ $ 

  bakunin:~ $ gdb /usr/local/lib/clisp/base/lisp.run core
  Core was generated by `/usr/local/lib/clisp/base/lisp.run -B
  /usr/local/lib/clisp -M /usr/local/lib/cl'.
  Program terminated with signal 11, Segmentation fault.
  [...]
  #0  0x08097097 in test_ostream ()
  (gdb) bt
  #0  0x08097097 in test_ostream ()
  #1  0xbffff4c0 in ?? ()
  #2  0x0805b0a4 in funcall_closure ()
  #3  0x202b4305 in ?? ()
  #4  0x08172f52 in subr_tab_data ()
  #5  0x202b4331 in ?? ()
  #6  0x202dc4d5 in ?? ()
  (gdb) 

Bye Michael

---

From: Bruno Haible <[email-masked]>
Date: Thu Sep 4 10:16:35 2003

> > /usr/lib/gconv/CP932.so: undefined symbol: STANDARD_ERR_HANDLER

That's a glibc bug introduced on 2003-07-14 and fixed on 2003-07-20.
You must be using a glibc snapshot.

Bruno

---

From: Michael Koehne <[email-masked]>
Date: Thu Sep 4 12:53:03 2003

Moin Bruno Haible,

> You must be using a glibc snapshot.

  clisp 2.31 now works on my Sarge, after a dselect. But still not on Woody.

Moin Sam Steingold,

> <http://sourceforge.net/tracker/index.php?func=detail&aid=785605&group_id=1355&atid=101355>

  [1]> (streamp 1)
  NIL

  *hm* I wonder, why streamp in src/io.d thinks that an integer is a
  stream, if using gcc 2.95.4, because streamp is lisp specific and
  not C(++) specific, iirc. Unfortunately, I dont understand the .d
  concept, to help here.

Bye Michael