From michaelb@ieee.org Wed Sep 1 07:53:34 1999 Received: from vasquez.zip.com.au (mail@vasquez.zip.com.au [203.12.97.41]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id HAA28880 for ; Wed, 1 Sep 1999 07:53:32 -0700 (PDT) Received: from cthulhu.arkham.org.au (stan15.zip.com.au [61.8.17.15]) by vasquez.zip.com.au (8.9.2/8.9.1) with SMTP id AAA19227 for ; Thu, 2 Sep 1999 00:51:07 +1000 (EST) From: Michael Beach To: clisp-list@clisp.cons.org Subject: Dynamic libraries and the --with-dynamic-modules and --with-dynamic-ffi options Date: Thu, 2 Sep 1999 11:47:58 +1000 X-Mailer: KMail [version 1.0.20] Content-Type: text/plain MIME-Version: 1.0 Message-Id: <99090212013102.00620@cthulhu.arkham.org.au> Content-Transfer-Encoding: 8bit Salutations all! I'm new to this list, but I'll dispense with the customary lurking and get straight onto some questions if that's all right... I've recently started to tinker with clisp, and lately I was looking at the foreign function interface. From the notes at the end of the implementation.html file, it seems that to use an external module one has to compile the .lsp file containing the declarations of the foreign functions, then compile the .c file that is produced. Then you have to build a new memory image for clisp and ensure that the results of compiling the .c file are linked to the driver program. But after seeing the options --with-dynamic-modules and --with-dynamic-ffi I was wondering if there might not be another way that doesn't require rebuilding a new memory image or relinking the driver program. However I can't seem to find any documentation on what these options do. I'd greatly appreciate it if someone could explain to me (or point me to a manual that explains) how to achieve what I just outlined, or at least the meaning of those two options. Thanks in advance! Regards M.Beach From marcoxa@parades.rm.cnr.it Wed Sep 1 08:20:23 1999 Received: from leonardo (leonardo.parades.rm.cnr.it [150.146.37.11]) by seagull.cdrom.com (8.8.8/8.7.3) with SMTP id IAA29723 for ; Wed, 1 Sep 1999 08:20:05 -0700 (PDT) Received: from copernico.parades.rm.cnr.it by leonardo (SMI-8.6/SMI-SVR4) id RAA06602; Wed, 1 Sep 1999 17:24:10 +0200 Received: by copernico.parades.rm.cnr.it (SMI-8.6/SMI-SVR4) id RAA09318; Wed, 1 Sep 1999 17:27:55 +0200 Date: Wed, 1 Sep 1999 17:27:55 +0200 Message-Id: <199909011527.RAA09318@copernico.parades.rm.cnr.it> From: Marco Antoniotti To: ilisp@cons.org CC: clisp-list@clisp.cons.org, cmucl-help@cons.org, cmucl-imp@cons.org, lug@lisp.de Subject: ANNOUNCEMENT: ILISP 5.9 Released Reply-to: ilisp@seagull.cons.org This is the official announcement of the availability of version 5.9 of ILISP, a comprehensive Inferior Lisp replacement for Emacs and XEmacs. ILISP 5.9 has a new official home at http://ilisp.cons.org You can download it from there. Instructions about subscribing to the `ilisp@cons.org' mailing list can also be found in that site. We encourage all the ILISP users to upgrade and to send feedback to the maintainers. This new release has been made possible especially thanks to Martin Atzmueller, Paolo Amoroso, Martin Cracauer, Christian Lynbech and many others, who are allowed to hold a grudge to the poster because of his forgetfulness. Here is the History file for ILISP 5.9. ============================================================================== ILISP HISTORY Version 5.9 The major change in this release concerns the new Home for ILISP at CONS.ORG. Fixes and enhancements since 5.8 alpha -- Changed behavior of package definitions in buffers thanks to Martin Atzmueller. Now (DEFPACKAGE "ZUT" ...) (IN-PACKAGE "ZUT") works as expected/desired. -- New Menus (thanks to Martin Atzmueller). -- Major Change for toplevel dialect: it is now called 'common-lisp' (it used to be 'clisp'). Note however, that for the time being, the name of the CLISP dialect remains 'clisp-hs'. -- Many bug fixes to CLISP dialect. -- The 'hyperspec' package and new 'ilisp-easy-menus' are distributed with ILISP. They are not loaded by default. -- Fixed loading of compatibility files for Emacs 20.xx. -- Fixed compilation and loading of 'ilisp-chs'. -- Fixed missing EXCL::FN_SYMDEF in ACL 5.0 (Larry Hunter) -- ILD Debugger interface by J. M. Siskind has been integrated in the dialect definitions. Please report any problems you may have with it. -- Changed default binding for 'clisp-hs-program' form "clisp" to "clisp -I" to account for buffer flushing behavior of this implementation. -- Added several Scheme dialects (thanks to Christian Lynbech). ============================================================================== Please check out the README files, especially in the `extra' directory (regarding the nature of the `hyperspec.el' software and site). Enjoy Marco Antoniotti and the ILISP maintainers -- Marco Antoniotti =========================================== PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26 http://www.parades.rm.cnr.it/~marcoxa From pvaneynd@inthan.be Wed Sep 1 08:51:29 1999 Received: from bashir.belgium.eu.net (bashir.Belgium.EU.net [193.74.208.147]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id IAA01196 for ; Wed, 1 Sep 1999 08:51:28 -0700 (PDT) Received: from (mail.inthan.be [193.121.48.18]) by bashir.belgium.eu.net with ESMTP id SAA26049 for ; Wed, 1 Sep 1999 18:00:47 +0200 (MET DST) Received: from pvaneynd by mail.inthan.be with local (Exim 2.05 #1 (Debian)) id 11MCg1-0004Lu-00; Wed, 1 Sep 1999 17:51:57 +0200 Date: Wed, 1 Sep 1999 17:51:56 +0200 From: Peter Van Eynde To: clisp-list@seagull.cons.org Subject: Re: ANNOUNCEMENT: ILISP 5.9 Released Message-ID: <19990901175156.A16621@mail.inthan.be> References: <199909011527.RAA09318@copernico.parades.rm.cnr.it> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: <199909011527.RAA09318@copernico.parades.rm.cnr.it>; from Marco Antoniotti on Wed, Sep 01, 1999 at 08:20:40AM -0700 Sender: Peter Van Eynde On Wed, Sep 01, 1999 at 08:20:40AM -0700, Marco Antoniotti wrote: > > This is the official announcement of the availability of version 5.9 of > ILISP, a comprehensive Inferior Lisp replacement for Emacs and XEmacs. Auguri! Groetjes, Peter -- It's logic Jim, but not as we know it. | pvaneynd@debian.org for pleasure, "God, root, what is difference?" - Pitr| pvaneynd@inthan.be for more pleasure! "God is more forgiving." - Dave Aronson| http://cvs2.cons.org/~pvaneynd From haible@ilog.fr Thu Sep 2 10:58:50 1999 Received: from sceaux.ilog.fr (sceaux.ilog.fr [193.55.64.10]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id KAA19780 for ; Thu, 2 Sep 1999 10:58:48 -0700 (PDT) Received: from laposte.ilog.fr (laposte [172.17.1.6]) by sceaux.ilog.fr (8.9.3/8.9.3) with ESMTP id UAA00798 for ; Thu, 2 Sep 1999 20:07:34 +0200 (MET DST) Received: from jaures.ilog.fr ([172.17.4.19]) by laposte.ilog.fr (8.9.3/8.9.3) with ESMTP id UAA01825; Thu, 2 Sep 1999 20:08:15 +0200 (MET DST) From: Bruno Haible Received: (from haible@localhost) by jaures.ilog.fr (8.9.3/8.9.3) id UAA29233; Thu, 2 Sep 1999 20:06:53 +0200 (MET DST) Date: Thu, 2 Sep 1999 20:06:53 +0200 (MET DST) Message-Id: <199909021806.UAA29233@jaures.ilog.fr> To: clisp-list@seagull.cons.org Subject: Re: Dynamic libraries and the --with-dynamic-modules and --with-dynamic-ffi options In-Reply-To: <99090212013102.00620@cthulhu.arkham.org.au> References: <99090212013102.00620@cthulhu.arkham.org.au> Michael Beach writes: > But after seeing the options --with-dynamic-modules and --with-dynamic-ffi I > was wondering if there might not be another way that doesn't require rebuilding > a new memory image or relinking the driver program. However I can't seem to > find any documentation on what these options do. --with-dynamic-ffi is needed for using the FFI at all. It is a recommended setting on all reasonable platforms. If you configured and compiled clisp with --with-dynamic-modules, you can skip the relinking and new memory image steps by using the "clisp-link run srcdir module1 module2 ..." command. It's a little bit documented in impnotes.html (search for "clisp-link run"). Bruno From mmertens@akam.be Mon Sep 6 12:30:18 1999 Received: from bashir.belgium.eu.net (bashir.Belgium.EU.net [193.74.208.147]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id MAA20160 for ; Mon, 6 Sep 1999 12:30:16 -0700 (PDT) Received: from (marc@idialup029.antwerp.eunet.be [193.121.237.29]) by bashir.belgium.eu.net with ESMTP id VAA28137 for ; Mon, 6 Sep 1999 21:40:28 +0200 (MET DST) Sender: marc@bashir.belgium.eu.net Message-ID: <37D418BE.B305146B@akam.be> Date: Mon, 06 Sep 1999 21:40:46 +0200 From: Marc Mertens X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.35 i686) X-Accept-Language: en MIME-Version: 1.0 To: clisp-list@seagull.cons.org Subject: CLISP and 'listen','read-char' Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, I have two questions about *standard-input* on CLISP. 1. Is about 'listen' and 'read-char' When I define the following functions (I want to do some processing during reading) I get some strange behaviour (see below). (defun test-read-char () (loop (when (listen) (return (read-char))) (process-incoming))) (defun test-read () (let ((result nil) (chr nil)) (loop (setf chr (test-read-char)) (if (char= chr #\newline) (return (reverse result)) (push chr result))))) (defun process-incoming () ;; Do some processing during read ) The first time I execute (test-read) and type in 123 the result is (#\2 #\3), #\1 is missing. [4]> (test-read) 123 (#\2 #\3) The second , third ... time I execute (test-read) and type in 123 I get the correct result (#\1 #\2 #\3). [5]> (test-read) 123 (#\1 #\2 #\3) [6]> If I force CLISP in debug and do a unwind executing (test-read) will again miss the first character during the first execution and then always a correct result. Can someone explain this to me or tell me how to make sure that I always get the correct result. PS. If I define test-read-char to do just a (read-char) with no listen I get a correct behavior. 2. Is about 'gray streams' and '*standard-input*'. If I try to create a gray stream where essential I change stream-read-char to do some processing when nothing can be read (see definition of test-read-char) and then redefine '*standard-input*' to be the gray stream I must always press return twice before CLISP evaluates expressions, also after some time CLISP will crash. My question is now do you have to do something special when you replace *standard-input* by a gray stream. The version of CLISP I'm using is clisp-1999-07-22. Any help is appreciated. Marc Mertens mmertens@akam.be From afreitas@imes.com.br Mon Sep 6 18:02:42 1999 Received: from imes.com.br ([200.245.82.129]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id SAA24067 for ; Mon, 6 Sep 1999 18:02:38 -0700 (PDT) Received: from l0w9f8 (pppremoto16 [200.245.82.112]) by imes.com.br (8.7.1/8.7.1) with ESMTP id WAA16600; Mon, 6 Sep 1999 22:15:52 -0300 (EST) Message-ID: <37D46700.8763C7E6@imes.com.br> Date: Mon, 06 Sep 1999 22:14:40 -0300 From: Aparecido Valdemir de Freitas Reply-To: afreitas@imes.com.br X-Mailer: Mozilla 4.01 [en] (Win95; I) MIME-Version: 1.0 To: "clisp-list@seagull.cons.org" CC: Aparecido Valdemir de Freitas Subject: CLISP - DLL Interface X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, I am working at a research project with the goal of became the task of to integrate several programming paradigms more easily. My environment is Win32. I am writing a simple application composed with several programming languages. One module was written with Prolog and other with C. (I will write other module with CLISP) To interface these languages I wrote a DLL (with Win32 API) that implements a memory shared area that is used to communicate the modules. My Prolog program writes in the buffer of the environment and C module reads the contents of the buffer. (and vice-versa) Now, I need to write a CLISP routine that will be part of the my multiparadigm application, and I need that this CLISP routine call the DLL of my environment. (Win32) My question is: How the CLISP module calls the DLL foreign function written in C ? Could anybody help me?? Best Regards. Aparecido Valdemir de Freitas From haible@ilog.fr Wed Sep 8 10:57:42 1999 Received: from sceaux.ilog.fr (sceaux.ilog.fr [193.55.64.10]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id KAA18072 for ; Wed, 8 Sep 1999 10:57:40 -0700 (PDT) Received: from laposte.ilog.fr (laposte [172.17.1.6]) by sceaux.ilog.fr (8.9.3/8.9.3) with ESMTP id UAA29884 for ; Wed, 8 Sep 1999 20:07:18 +0200 (MET DST) Received: from jaures.ilog.fr ([172.17.4.17]) by laposte.ilog.fr (8.9.3/8.9.3) with ESMTP id UAA11177; Wed, 8 Sep 1999 20:08:04 +0200 (MET DST) From: Bruno Haible Received: (from haible@localhost) by jaures.ilog.fr (8.9.3/8.9.3) id UAA17886; Wed, 8 Sep 1999 20:08:02 +0200 (MET DST) Date: Wed, 8 Sep 1999 20:08:02 +0200 (MET DST) Message-Id: <199909081808.UAA17886@jaures.ilog.fr> To: clisp-list@seagull.cons.org Subject: Re: CLISP - DLL Interface In-Reply-To: <37D46700.8763C7E6@imes.com.br> References: <37D46700.8763C7E6@imes.com.br> > Now, I need to write a CLISP routine that will be part of the my > multiparadigm application, and I need that this CLISP routine call the > DLL of my environment. (Win32) > > My question is: How the CLISP module calls the DLL foreign function > written in C ? Using CLISP's FFI, documented in impnotes.html, you can write calls to external C functions. When you `compile-file' a Lisp file which contains FFI declarations, a .c file is generated, which is intended to be compiled by the same C compiler as was used to build the CLISP binary, and linked with the clisp core. Normally, this is done by the clisp-link script, but it requires a Unix shell, for example the Cygwin port of GNU bash. Since you will have to relink the clisp executable, you will most probably start by rebuilding clisp from source yourself, and then tweak the Makefile so it fits your needs. It's not an easy task. All this is Windows specific. On Unix, the binary distributions of clisp contain the necessary libraries for quickly relinking clisp without rebuilding it. Bruno From mmertens@akam.be Sat Sep 11 02:49:49 1999 Received: from chekov.Belgium.EU.net (chekov.belgium.eu.net [193.74.208.161]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id CAA27362 for ; Sat, 11 Sep 1999 02:49:49 -0700 (PDT) Received: from (marc@jdialup124.antwerp.eunet.be [195.207.95.124]) by chekov.Belgium.EU.net with ESMTP id MAA04474; Sat, 11 Sep 1999 12:00:32 +0200 (MET DST) Sender: marc@chekov.Belgium.EU.net Message-ID: <37DA284D.CA1C1BAA@akam.be> Date: Sat, 11 Sep 1999 12:00:45 +0200 From: Marc Mertens X-Mailer: Mozilla 4.6 [en] (X11; I; Linux 2.0.35 i686) X-Accept-Language: en MIME-Version: 1.0 To: clisp-list@clisp.cons.org, clisp-list@seagull.cons.org Subject: Possible bug in 'listen' and 'read-char' Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello, I have two questions about *standard-input* on CLISP. 1. Is about 'listen' and 'read-char' When I define the following functions (I want to do some processing during reading) I get some strange behaviour (see below). (defun test-read-char () (loop (when (listen) (return (read-char))) (process-incoming))) (defun test-read () (let ((result nil) (chr nil)) (loop (setf chr (test-read-char)) (if (char= chr #\newline) (return (reverse result)) (push chr result))))) (defun process-incoming () ;; Do some processing during read ) The first time I execute (test-read) and type in 123 the result is (#\2 #\3), #\1 is missing. [4]> (test-read) 123 (#\2 #\3) The second , third ... time I execute (test-read) and type in 123 I get the correct result (#\1 #\2 #\3). [5]> (test-read) 123 (#\1 #\2 #\3) [6]> If I force CLISP in debug and do a unwind executing (test-read) will again miss the first character during the first execution and then always a correct result. Can someone explain this to me or tell me how to make sure that I always get the correct result. PS. If I define test-read-char to do just a (read-char) with no listen I get a correct behavior. 2. Is about 'gray streams' and '*standard-input*'. If I try to create a gray stream where essential I change stream-read-char to do some processing when nothing can be read (see definition of test-read-char) and then redefine '*standard-input*' to be the gray stream I must always press return twice before CLISP evaluates expressions, also after some time CLISP will crash. My question is now do you have to do something special when you replace *standard-input* by a gray stream. The version of CLISP I'm using is clisp-1999-07-22. Any help is appreciated. Marc Mertens mmertens@akam.be PS. If this message appear twice , I'm sorry but I'm not sure if my first message arrives at all. From haible@ilog.fr Mon Sep 13 04:59:39 1999 Received: from sceaux.ilog.fr (sceaux.ilog.fr [193.55.64.10]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id EAA25685 for ; Mon, 13 Sep 1999 04:59:33 -0700 (PDT) Received: from laposte.ilog.fr (laposte [172.17.1.6]) by sceaux.ilog.fr (8.9.3/8.9.3) with ESMTP id OAA17343 for ; Mon, 13 Sep 1999 14:09:37 +0200 (MET DST) Received: from jaures.ilog.fr ([172.17.4.17]) by laposte.ilog.fr (8.9.3/8.9.3) with ESMTP id OAA15949; Mon, 13 Sep 1999 14:10:23 +0200 (MET DST) From: Bruno Haible Received: (from haible@localhost) by jaures.ilog.fr (8.9.3/8.9.3) id OAA17332; Mon, 13 Sep 1999 14:10:21 +0200 (MET DST) Date: Mon, 13 Sep 1999 14:10:21 +0200 (MET DST) Message-Id: <199909131210.OAA17332@jaures.ilog.fr> To: clisp-list@seagull.cons.org Subject: Re: CLISP and 'listen','read-char' In-Reply-To: <37D418BE.B305146B@akam.be> References: <37D418BE.B305146B@akam.be> Marc Mertens asked: > 1. Is about 'listen' and 'read-char' > > When I define the following functions (I want to do > some processing during reading) I get some strange > behaviour (see below). > > ... [easily reproducible code snipped] > > 2. Is about 'gray streams' and '*standard-input*'. > If I try to create a gray stream ... after some time CLISP will crash. Both of these problems should be fixed in a new snapshot, ftp://ftp.ilog.fr/pub/Users/haible/lisp/clisp-1999-09-13.tar.gz. Thanks for bringing it to my attention. > (defun test-read-char () > (loop > (when (listen) > (return (read-char))) > (process-incoming))) By doing this, you will effectively disable the readline library, because the `read-char' will only be called when the system says that a character is available, and this is when the user has completed a line and typed "Return". Haven't had time yet to look at the third problem you mentioned. Bruno From haible@ilog.fr Mon Sep 13 12:46:14 1999 Received: from sceaux.ilog.fr (sceaux.ilog.fr [193.55.64.10]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id MAA01752 for ; Mon, 13 Sep 1999 12:46:10 -0700 (PDT) Received: from laposte.ilog.fr (laposte [172.17.1.6]) by sceaux.ilog.fr (8.9.3/8.9.3) with ESMTP id VAA00401 for ; Mon, 13 Sep 1999 21:56:23 +0200 (MET DST) Received: from jaures.ilog.fr ([172.17.4.17]) by laposte.ilog.fr (8.9.3/8.9.3) with ESMTP id VAA18928; Mon, 13 Sep 1999 21:57:11 +0200 (MET DST) From: Bruno Haible Received: (from haible@localhost) by jaures.ilog.fr (8.9.3/8.9.3) id VAA20713; Mon, 13 Sep 1999 21:57:09 +0200 (MET DST) Date: Mon, 13 Sep 1999 21:57:09 +0200 (MET DST) Message-Id: <199909131957.VAA20713@jaures.ilog.fr> To: clisp-list@clisp.cons.org Subject: Platform poll Hello, Is there still interest for CLISP on the following platforms: - MS-DOS, Windows 3.1 superseded since 1995 - OS/2 last binaries made in 1997 - AmigaOS last binaries made in 1996 - NeXTstep last binaries made in 1996 If you wish that CLISP continues to run on any of these platforms, please send me mail. Otherwise I'll remove the old crufty code for the corresponding platform, making room for new improvements. Bruno From sds@goems.com Mon Sep 13 13:36:22 1999 Received: from smtp6.mindspring.com (smtp6.mindspring.com [207.69.200.74]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id NAA02642 for ; Mon, 13 Sep 1999 13:36:21 -0700 (PDT) Received: from SAM.ksp.com (user-2ive9nn.dialup.mindspring.com [165.247.38.247]) by smtp6.mindspring.com (8.8.5/8.8.5) with ESMTP id QAA24226 for ; Mon, 13 Sep 1999 16:47:33 -0400 (EDT) To: clisp-list@seagull.cons.org Subject: Re: Platform poll References: <199909131957.VAA20713@jaures.ilog.fr> Return-Receipt-To: sds@goems.com Reply-To: sds@goems.com X-Attribution: Sam X-Disclaimer: You should not expect anyone to agree with me. Mail-Copies-To: never From: Sam Steingold In-Reply-To: Bruno Haible's message of "Mon Sep 13 14:48:41 EDT 1999" Date: 13 Sep 1999 16:46:47 -0400 Message-ID: Lines: 7 X-Mailer: Gnus v5.7/Emacs 20.4 I suggest keeping the DOS support. it is nice to have CLISP on an 8088. -- Sam Steingold (http://www.podval.org/~sds/) Micros**t is not the answer. Micros**t is a question, and the answer is Linux, (http://www.linux.org) the choice of the GNU (http://www.gnu.org) generation. MS: Brain off-line, please wait. From haible@ilog.fr Mon Sep 13 13:58:05 1999 Received: from sceaux.ilog.fr (sceaux.ilog.fr [193.55.64.10]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id NAA03046 for ; Mon, 13 Sep 1999 13:58:03 -0700 (PDT) Received: from laposte.ilog.fr (laposte [172.17.1.6]) by sceaux.ilog.fr (8.9.3/8.9.3) with ESMTP id XAA01710 for ; Mon, 13 Sep 1999 23:08:14 +0200 (MET DST) Received: from jaures.ilog.fr ([172.17.4.17]) by laposte.ilog.fr (8.9.3/8.9.3) with ESMTP id XAA21425; Mon, 13 Sep 1999 23:09:01 +0200 (MET DST) From: Bruno Haible Received: (from haible@localhost) by jaures.ilog.fr (8.9.3/8.9.3) id XAA20737; Mon, 13 Sep 1999 23:08:59 +0200 (MET DST) Date: Mon, 13 Sep 1999 23:08:59 +0200 (MET DST) Message-Id: <199909132108.XAA20737@jaures.ilog.fr> To: clisp-list@seagull.cons.org Subject: Re: Platform poll In-Reply-To: References: Sam Steingold writes: > I suggest keeping the DOS support. > it is nice to have CLISP on an 8088. Your vote doesn't count, because CLISP never ran on an 8088. If you want a halfway decent Lisp which runs on such a machine, you can get PC-Scheme. What is an 8088 anyway? Today, phone answering machines are already running Linux. Bruno From viking@cit.org.by Tue Sep 14 11:08:59 1999 Received: from lxms.cit.org.by (root@lxms.cit.org.by [194.85.255.34]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id LAA15662 for ; Tue, 14 Sep 1999 11:08:32 -0700 (PDT) Received: from cit.org.by (cyberdata.cit [172.17.2.23]) by lxms.cit.org.by (8.9.3/8.9.3/Debian/GNU) with ESMTP id VAA11222 for ; Tue, 14 Sep 1999 21:15:32 +0300 Sender: viking@lxms.cit.org.by Message-ID: <37DE9199.4D6585F6@cit.org.by> Date: Tue, 14 Sep 1999 21:19:05 +0300 From: Eugene Zaikonnikov Organization: Center of Information Technology X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.5-15 i586) X-Accept-Language: en, ru MIME-Version: 1.0 To: clisp-list@seagull.cons.org Subject: Re: Platform poll References: <199909131957.VAA20713@jaures.ilog.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bruno Haible wrote: > > Hello, > > Is there still interest for CLISP on the following platforms: > > - MS-DOS, Windows 3.1 superseded since 1995 I used the DOS version of CLISP about ten months ago to implement semester project. Here is still many DOS boxes in universities. But IMO the last DOS version is good enough for educational purposes. -- Eugene. From hoehle@mmkmail.gmd.de Wed Sep 15 02:30:07 1999 Received: from mail.gmd.de (mail.gmd.de [129.26.8.90]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id CAA25393 for ; Wed, 15 Sep 1999 02:29:57 -0700 (PDT) Received: from zeus.gmd.de (zeus.gmd.de [129.26.165.1]) by mail.gmd.de (8.8.8/8.8.8) with ESMTP id LAA20835 for ; Wed, 15 Sep 1999 11:40:54 +0200 (MET DST) Received: from localhost (hoehle@localhost) by zeus.gmd.de (8.9.1/8.9.3) with SMTP id LAA06996 for ; Wed, 15 Sep 1999 11:40:57 +0200 (MET DST) X-Authentication-Warning: zeus.gmd.de: hoehle owned process doing -bs Date: Wed, 15 Sep 1999 11:40:57 +0200 (MET DST) From: Joerg Hoehle X-Sender: hoehle@zeus To: clisp-list@seagull.cons.org Subject: Re: Platform poll In-Reply-To: <199909131957.VAA20713@jaures.ilog.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 13 Sep 1999, Bruno Haible wrote: > - AmigaOS last binaries made in 1996 Wrong, binaries were made in 1997 and 1998 as well. They are just not up on the ftp server that you looked at. > send me mail. Otherwise I'll remove the old crufty code for the corresponding > platform, making room for new improvements. I don't see why it's necessary to remove old code to make room for new improvements. These seem like orthogonal concepts to me. Basically you raise the question of whether any old version of CLISP once released is "good enough" for somebody else's purposes. I'd be tempted to respond with yes but will get flamed for such demonstrated lack of interested in what's called progress. On some of the Suns I use, there's still a CLISP from 1995 working perfectly well. OTOH, some people feel "xyz is dead" (XIT, Garnet, GINA, Amulet, CLUE, CLIO, CLM ...) because it hasn't changed since 1995. I keep hearing people around me say "Ada is dead", Smalltalk is dead, Lisp is dead, ... :-( Regards, Jo"rg Ho"hle. Joerg.Hoehle@gmd.de http://fit.gmd.de/~hoehle/amiga.html From haible@ilog.fr Wed Sep 15 05:19:47 1999 Received: from sceaux.ilog.fr (sceaux.ilog.fr [193.55.64.10]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id FAA27092 for ; Wed, 15 Sep 1999 05:19:42 -0700 (PDT) Received: from laposte.ilog.fr (laposte [172.17.1.6]) by sceaux.ilog.fr (8.9.3/8.9.3) with ESMTP id OAA14048 for ; Wed, 15 Sep 1999 14:30:07 +0200 (MET DST) Received: from jaures.ilog.fr ([172.17.4.4]) by laposte.ilog.fr (8.9.3/8.9.3) with ESMTP id OAA13162; Wed, 15 Sep 1999 14:30:54 +0200 (MET DST) From: Bruno Haible Received: (from haible@localhost) by jaures.ilog.fr (8.9.3/8.9.3) id OAA06680; Wed, 15 Sep 1999 14:30:51 +0200 (MET DST) Date: Wed, 15 Sep 1999 14:30:51 +0200 (MET DST) Message-Id: <199909151230.OAA06680@jaures.ilog.fr> To: clisp-list@seagull.cons.org Subject: Re: Platform poll In-Reply-To: References: Joerg Hoehle writes: > > - AmigaOS last binaries made in 1996 > Wrong, binaries were made in 1997 and 1998 as well. They are just not up > on the ftp server that you looked at. Sorry, I meant "binaries made and uploaded". > I don't see why it's necessary to remove old code to make room for new > improvements. These seem like orthogonal concepts to me. For example if you want to assume that the OS has dynamic loading. For this, you need to drop support of Linux/a.out and AmigaOS. > OTOH, some people feel "xyz is dead" (XIT, ...) because it hasn't > changed since 1995. XIT is dead because it has a copyright which forbids you to distribute modified versions. Its authors wanted it to die once they would not be able to maintain it themselves. > I keep hearing people around me say "Ada is dead", ... That's because the people around you are getting older, and the older they get, the more depressive. Ada95 had Unicode support before CLISP had it. Looks pretty alive. Bruno From vkyr@lavielle.com Wed Sep 15 06:24:52 1999 Received: from vampire.lavielle.com (vampire.lavielle.com [194.64.21.10]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id GAA28047 for ; Wed, 15 Sep 1999 06:24:51 -0700 (PDT) Received: from lispworks (lispworks.lavielle.com [194.64.21.80]) by vampire.lavielle.com (8.9.3/8.9.3) with SMTP id PAA05063 for ; Wed, 15 Sep 1999 15:36:02 +0200 (MET DST) From: "Valentino Kyriakides" To: Subject: Re: Platform poll Date: Wed, 15 Sep 1999 15:35:07 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <199909131957.VAA20713@jaures.ilog.fr> Hello, Bruno asked: > Is there still interest for CLISP on the following platforms: > > ... > - NeXTstep last binaries made in 1996 I would like to see in CLISP continued NeXTstep support, since there isn't any other up to date CommonLisp available for NS. So far CLISP is the only good CL implementation available for NS. If Clisp is discontinuing to support NS, there wouldn't be any moderate CL implementation for NS under Motorola or Intel CPUs. However, I can offer to try to build an upto date CLISP NS m68k version. BTW, I also have newer CLISP NS binaries than those made in 1996. Greetings Valentino From joswig@lavielle.com Thu Sep 16 02:27:50 1999 Received: from vampire.lavielle.com (vampire.lavielle.com [194.64.21.10]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id CAA10137 for ; Thu, 16 Sep 1999 02:27:48 -0700 (PDT) Received: from [194.64.21.18] (pbg3.lavielle.com [194.64.21.18]) by vampire.lavielle.com (8.9.3/8.9.3) with ESMTP id LAA09214 for ; Thu, 16 Sep 1999 11:39:09 +0200 (MET DST) Mime-Version: 1.0 X-Sender: joswig@194.64.21.10 Message-Id: In-Reply-To: References: X-Priority: 5 (Lowest) Date: Thu, 16 Sep 1999 11:39:07 +0200 To: clisp-list@seagull.cons.org From: Rainer Joswig Subject: Re: Platform poll Content-Type: text/plain; charset="us-ascii" At 2:30 Uhr -0700 15.09.1999, Joerg Hoehle wrote: >I keep hearing people around me say "Ada is dead", Smalltalk is dead, Lisp >is dead, ... :-( Partly off topic: Lisp can't be dead. We are still using it and we like CLisp (we are using it on Solaris - mostly SPARC nowadays). Thanks to the developers and maintainers of CLisp! Rainer Joswig Rainer Joswig, "Lavielle" EDV Systemberatung GmbH & Co. KG, Lotharstrasse 2b, 22041 Hamburg, Germany, Tel: +49 40 658088, Fax: +49 40 65808-202, Email: joswig@lavielle.com , WWW: http://www.lavielle.de/ From tl@exotica.inesc.pt Thu Sep 16 06:17:48 1999 Received: from inesc.inesc.pt (inesc.inesc.pt [146.193.0.1]) by seagull.cdrom.com (8.8.8/8.7.3) with SMTP id GAA12216 for ; Thu, 16 Sep 1999 06:17:46 -0700 (PDT) Received: from exotica.inesc.pt by inesc.inesc.pt with SMTP; id AA18104 (/); Thu, 16 Sep 1999 14:29:04 +0100 Received: from exotica (tl@localhost [127.0.0.1]) by exotica.inesc.pt (8.8.7/8.8.7) with ESMTP id OAA09444 for ; Thu, 16 Sep 1999 14:29:06 +0100 Message-Id: <199909161329.OAA09444@exotica.inesc.pt> To: clisp-list@clisp.cons.org Subject: clisp as cgi script Reply-To: thibault.langlois@inesc.pt Date: Thu, 16 Sep 1999 14:29:06 +0100 From: Thibault Langlois Hello, I'm trying to use clisp to process cgi scripts arguments and build responses (html pages). After some failed tentatives I decided to use a shell script that calls clisp. The query string is passed via a file and the response is also writen to a file: #!/bin/bash echo $QUERY_STRING > /tmp/querystring clisp -q -x '(load "/etc/httpd/cgi-bin/test.lisp")' > /tmp/debug cat /tmp/out.html When I run this script from a shell everything is ok. When it is run by the server (apache) I get the following error in /tmp/debug : *** - UNIX error 25 (ENOTTY): Inappropriate ioctl for device What does it mean ? The error is not (I think) in test.lisp as it occurs before the first form is read. When I get this problem solved, I'll come back to a cleaner solution i.e. without temporary files. Any advice would be greatly appreciated. Thanks. Thibault Langlois PS: I am using: > (lisp-implementation-version) "1997-08-07 (August 1997)" on a GNU/Linux RedHat 5.1 PC. From fc@all.net Thu Sep 16 06:57:19 1999 Received: from all.net (c118194-a.lvrmr1.sfba.home.com [24.1.84.100]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id GAA12718 for ; Thu, 16 Sep 1999 06:57:10 -0700 (PDT) Received: (from fc@localhost) by all.net (8.9.3/8.9.3) id HAA04780 for clisp-list@seagull.cons.org; Thu, 16 Sep 1999 07:08:16 -0700 Message-Id: <199909161408.HAA04780@all.net> Subject: Re: clisp as cgi script To: clisp-list@seagull.cons.org Date: Thu, 16 Sep 1999 07:08:16 -0700 (PDT) In-Reply-To: <199909161329.OAA09444@exotica.inesc.pt> from "Thibault Langlois" at Sep 16, 1999 06:18:09 AM From: Fred Cohen Reply-To: fc@all.net Organization: I'm not allowed to say X-Mailer: don't even ask X-Mailer: ELM [version 2.5 PL0pre8] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In reference to the following view expressed by Thibault Langlois: > > > Hello, > > I'm trying to use clisp to process cgi scripts arguments and build > responses (html pages). After some failed tentatives I decided to use > a shell script that calls clisp. The query string is passed via a file > and the response is also writen to a file: ... Here's what I did: I use TCP wrappers to feed a perl script that feeds Clisp: /etc/hosts.allow: Web.pl: all: twist /usr/fred/bin/Web.pl %a %u %d The %a %u %d is strictly for audit purposes and will be ignored for this example. Then, in /usr/fred/bin/Web.pl: ... $LISP="/usr/fred/clisp/clisp-1998-09-09/src/base/lisp.run"; ... system("echo '$move\n' | $LISP -M /usr/fred/lisp/realtime/games.mem"); where $move is a properly filtered extract of the original input string. FC -- Fred Cohen at Sandia National Laboratories at tel:925-294-2087 fax:925-294-1225 Fred Cohen & Associates: http://all.net - fc@all.net - tel/fax:925-454-0171 Fred Cohen - Practitioner in Residence - The University of New Haven Have a great day!!! Per the official policy of Sandia National Laboratories, the reader should be aware that: - Fred Cohen of Fred Cohen & Associates is the same Fred Cohen who is a Principal Member of Technical Staff at Sandia National Laboratories. - Fred Cohen & Associates - is owned and operated by Fred Cohen and is separate and independent from the work done by Fred Cohen at Sandia National Laboratories. From dtillman@ozarkaircraftsystems.com Thu Sep 16 07:26:39 1999 Received: from stargate.ozarkaircraftsystems.com (fwall.ozarkaircraftsystems.com [12.10.100.210] (may be forged)) by seagull.cdrom.com (8.8.8/8.7.3) with SMTP id HAA13354 for ; Thu, 16 Sep 1999 07:26:38 -0700 (PDT) From: dtillman@ozarkaircraftsystems.com Received: (from dtillman@localhost) by stargate.ozarkaircraftsystems.com (8.9.3/8.9.3) id JAA05254; Thu, 16 Sep 1999 09:29:15 -0500 Date: Thu, 16 Sep 1999 09:29:15 -0500 Message-Id: <199909161429.JAA05254@stargate.ozarkaircraftsystems.com> X-Authentication-Warning: stargate.ozarkaircraftsystems.com: dtillman set sender to dtillman@stargate.ozarkaircraftsystems.com using -f To: clisp-list@seagull.cons.org In-reply-to: <199909161329.OAA09444@exotica.inesc.pt> (message from Thibault Langlois on Thu, 16 Sep 1999 06:18:00 -0700 (PDT)) Subject: Re: clisp as cgi script References: <199909161329.OAA09444@exotica.inesc.pt> > I'm trying to use clisp to process cgi scripts arguments and build > responses (html pages). After some failed tentatives I decided to use > a shell script that calls clisp. The query string is passed via a file > and the response is also writen to a file: This is not an answer to your question (don't you hate when people do that?). Speaking as someone who has been through this before, you would be better off using a named pipe. Have the clisp proccess run constantly witing for input on the pipe. Write the query out to the pipe. Doing this discards the delay from waiting for lisp to start. I also played around with having a dedicated "CGI server". This listened on a port (such as 1080) and all cgi requests were directed to it while Apache handled normal html GET requests. Doing this worked OK, but I eventually wrote the entire server in LISP and bypassed Apache alltogether. I have written two webservers. "Shadow" written in Guile and "Menace" written in CMUCL. Shadow is broken since Guile 1.3 and I haven't taken the time to fix it up. Menace still needs some work as it is a bit of a dog. I now do all off my cgi scripts in STk (a scheme variant). One more note: Once you start doing html in CLOS you will never want to use anything else. PERL (if not already) will become an abomination to you. This is a stripped down example (scheme, not lisp): (define foo (make html-doc :title "OAS MIS [request]" :bg-color "#f5deb3")) (add-child (center (h2 "OAS MIS")) foo) (add-child (center (h3 "Request for Computing or Telecom Services")) foo) (define table (make html-table :border "0")) (add-child table foo) (html-output foo) It is trivial to add a text-output method for html-doc and not quite so trivial to add a postscript-output method (like (postscript-output foo :file "/tmp/foo.ps")). Sorry for rambling so - it is just that it pains me to see PERL considered to be the only choice for serious CGI development by so many. -Dave From haible@ilog.fr Thu Sep 16 07:27:13 1999 Received: from sceaux.ilog.fr (sceaux.ilog.fr [193.55.64.10]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id HAA13399 for ; Thu, 16 Sep 1999 07:27:09 -0700 (PDT) Received: from laposte.ilog.fr (laposte [172.17.1.6]) by sceaux.ilog.fr (8.9.3/8.9.3) with ESMTP id QAA22296 for ; Thu, 16 Sep 1999 16:37:40 +0200 (MET DST) Received: from jaures.ilog.fr ([172.17.4.4]) by laposte.ilog.fr (8.9.3/8.9.3) with ESMTP id QAA15097; Thu, 16 Sep 1999 16:38:28 +0200 (MET DST) From: Bruno Haible Received: (from haible@localhost) by jaures.ilog.fr (8.9.3/8.9.3) id QAA14955; Thu, 16 Sep 1999 16:38:28 +0200 (MET DST) Date: Thu, 16 Sep 1999 16:38:28 +0200 (MET DST) Message-Id: <199909161438.QAA14955@jaures.ilog.fr> To: clisp-list@seagull.cons.org Subject: Re: clisp as cgi script In-Reply-To: <199909161329.OAA09444@exotica.inesc.pt> References: <199909161329.OAA09444@exotica.inesc.pt> Thibault Langlois writes: > > clisp -q -x '(load "/etc/httpd/cgi-bin/test.lisp")' > /tmp/debug > When I run this script from a shell everything is ok. When it is run > by the server (apache) I get the following error in /tmp/debug : > > *** - UNIX error 25 (ENOTTY): Inappropriate ioctl for device > > What does it mean ? > > (lisp-implementation-version) > "1997-08-07 (August 1997)" Probably clisp tried to allocate a keyboard stream, and does not succeed because standard input is not a tty. Newer versions of clisp allocate the keyboard stream lazily (i.e. the first time you use the `with-keyboard' macro); therefore they shouldn't exhibit the error. Bruno From erik@inanna.starseed.com Thu Sep 16 08:05:46 1999 Received: from inanna.starseed.com (root@inanna.starseed.com [206.151.157.197]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id IAA14306 for ; Thu, 16 Sep 1999 08:05:42 -0700 (PDT) Received: (from erik@localhost) by inanna.starseed.com (8.9.3/8.9.3) id IAA32004; Thu, 16 Sep 1999 08:21:15 -0700 From: Erik Arneson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14305.2795.126662.799715@inanna.starseed.com> Date: Thu, 16 Sep 1999 08:21:15 -0700 (PDT) To: clisp-list@seagull.cons.org Cc: Thibault Langlois Subject: Re: clisp as cgi script In-Reply-To: <199909161329.OAA09444@exotica.inesc.pt> References: <199909161329.OAA09444@exotica.inesc.pt> X-Mailer: VM 6.75 under 21.2 (beta19) "Shinjuku" XEmacs Lucid X-Fnord: http://inanna.starseed.com/~erik/ On 16 Sep 99, Thibault Langlois wrote: > I'm trying to use clisp to process cgi scripts arguments and build > responses (html pages). After some failed tentatives I decided to use > a shell script that calls clisp. The query string is passed via a file > and the response is also writen to a file: I was working on writing some CLISP cgi scripts using the #!/usr/bin/clisp method and accessing the query string directly. I wrote a function like this: (defun get-form () (let ((query (cond ((string= (system::getenv "REQUEST_METHOD") "GET") (system::getenv "QUERY_STRING")) ((string= (system::getenv "REQUEST_METHOD") "POST") (system::read *standard-input*))))) (mapcar #'(lambda (cell) (let ((key (split-string cell "="))) (cons (car key) (html::decode (cadr key))))) (split-string query "[\:&]")))) It requires the REGEXP package, and `split-string' is a little function I stole/ported from Emacs Lisp that looks like this: (defun split-string (string &optional pattern) "Splits STRING with tokens delimited by PATTERN." (or pattern (setf pattern "[ \f\t\n\r\v]+")) (let (parts smatch (start 0)) (do () ((not (setf smatch (match pattern string :start start)))) (setf parts (cons (substring string start (match-start smatch)) parts) start (match-end smatch))) (nreverse (cons (substring string start) parts)))) You might be able to get some use out of it. The one part I was still having trouble with was decoding the query string (i.e. turning %20 into a space and such). Since I'm coming from Perl, it seemed like a lot of work for me...I got a little ways, and then suddenly my real job got more demanding. :) Anybody have a solution for query string decoding that I could use, by the way? -- # Erik Arneson erik@starseed.com Webring Software Engineer # # Yahoo! Inc. PGP ID: 2048/84413E19 (541) 482-3000x114 # # "There's such a fine line between stupid and clever." Spinal Tap # From erik@inanna.starseed.com Thu Sep 16 08:12:51 1999 Received: from inanna.starseed.com (root@inanna.starseed.com [206.151.157.197]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id IAA14521 for ; Thu, 16 Sep 1999 08:12:50 -0700 (PDT) Received: (from erik@localhost) by inanna.starseed.com (8.9.3/8.9.3) id IAA32029; Thu, 16 Sep 1999 08:28:20 -0700 From: Erik Arneson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14305.3220.117139.743983@inanna.starseed.com> Date: Thu, 16 Sep 1999 08:28:20 -0700 (PDT) To: clisp-list@seagull.cons.org Subject: Re: clisp as cgi script In-Reply-To: <14305.2795.126662.799715@inanna.starseed.com> References: <14305.2795.126662.799715@inanna.starseed.com> X-Mailer: VM 6.75 under 21.2 (beta19) "Shinjuku" XEmacs Lucid X-Fnord: http://inanna.starseed.com/~erik/ On 16 Sep 99, Erik Arneson wrote: > I was working on writing some CLISP cgi scripts using the > #!/usr/bin/clisp method and accessing the query string directly. I > wrote a function like this: > > (defun get-form () > (let ((query (cond ((string= (system::getenv "REQUEST_METHOD") "GET") > (system::getenv "QUERY_STRING")) > ((string= (system::getenv "REQUEST_METHOD") "POST") > (system::read *standard-input*))))) > (mapcar #'(lambda (cell) > (let ((key (split-string cell "="))) > (cons (car key) (html::decode (cadr key))))) > (split-string query "[\:&]")))) In case I wasn't very clear with this later in my message, what I am trying to say is that the `html::decode' function isn't written yet. So if anybody tries to use `get-form' they'll get an error unless they write one on their own. :) FWIW, I have a partly completed `replace-in-string' also stolen/ported from Emacs Lisp. If anybody is interested, please drop me a line. -- # Erik Arneson erik@starseed.com Webring Software Engineer # # Yahoo! Inc. PGP ID: 2048/84413E19 (541) 482-3000x114 # # "There's such a fine line between stupid and clever." Spinal Tap # From fc@all.net Thu Sep 16 08:28:54 1999 Received: from all.net (c118194-a.lvrmr1.sfba.home.com [24.1.84.100]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id IAA14884 for ; Thu, 16 Sep 1999 08:28:45 -0700 (PDT) Received: (from fc@localhost) by all.net (8.9.3/8.9.3) id IAA07722 for clisp-list@seagull.cons.org; Thu, 16 Sep 1999 08:39:52 -0700 Message-Id: <199909161539.IAA07722@all.net> Subject: Re: clisp as cgi script To: clisp-list@seagull.cons.org Date: Thu, 16 Sep 1999 08:39:51 -0700 (PDT) In-Reply-To: <14305.2795.126662.799715@inanna.starseed.com> from "Erik Arneson" at Sep 16, 1999 08:06:07 AM From: Fred Cohen Reply-To: fc@all.net Organization: I'm not allowed to say X-Mailer: don't even ask X-Mailer: ELM [version 2.5 PL0pre8] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit In reference to the following view expressed by Erik Arneson: > > On 16 Sep 99, Thibault Langlois wrote: > > I'm trying to use clisp to process cgi scripts arguments and build > > responses (html pages). After some failed tentatives I decided to use > > a shell script that calls clisp. The query string is passed via a file > > and the response is also writen to a file: > > I was working on writing some CLISP cgi scripts using the > #!/usr/bin/clisp method and accessing the query string directly. I > wrote a function like this: > > (defun get-form () ... > Anybody have a solution for query string decoding that I could use, by > the way? ... I did this ugly thing: ... (defun sed (from to string &aux start end) (setq start (search from string)) (cond ((null start) string) (t (setq end (+ start (length from))) (concatenate 'string (subseq string 0 start) to (sed from to (subseq string end (length string)))) ) ) ) ... (defun fixurl (url) (sed "GET /game/RoomsMove?Move=" "GET /rooms/" (sed "GET /game/HackMove?answers-" "answer " (sed "/game/HackMove?Q0=" "/Hack/" (sed "%2F" "/" (sed "%3A" ":" (sed "%3D" "=" (sed "%3F" "?" (sed "State=" " " (sed "GET /test/HackMove?Q0=" "test /Hack/" (sed "+" "" url )))))))))) ) -- Fred Cohen at Sandia National Laboratories at tel:925-294-2087 fax:925-294-1225 Fred Cohen & Associates: http://all.net - fc@all.net - tel/fax:925-454-0171 Fred Cohen - Practitioner in Residence - The University of New Haven Have a great day!!! Per the official policy of Sandia National Laboratories, the reader should be aware that: - Fred Cohen of Fred Cohen & Associates is the same Fred Cohen who is a Principal Member of Technical Staff at Sandia National Laboratories. - Fred Cohen & Associates - is owned and operated by Fred Cohen and is separate and independent from the work done by Fred Cohen at Sandia National Laboratories. From rmz@dunk.follo.net Thu Sep 16 09:30:47 1999 Received: from dunk.follo.net (dunk.follo.net [195.204.143.225]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id JAA15625 for ; Thu, 16 Sep 1999 09:30:45 -0700 (PDT) Received: (from rmz@localhost) by dunk.follo.net (8.9.3/8.9.3) id SAA98694 for clisp-list@clisp.cons.org; Thu, 16 Sep 1999 18:42:07 +0200 (CEST) (envelope-from rmz) Date: Thu, 16 Sep 1999 18:42:07 +0200 From: =?iso-8859-1?Q?Bj=F8rn_Remseth?= To: clisp-list@clisp.cons.org Subject: postgresql on FreeBSD Message-ID: <19990916184207.G71941@dunk.follo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i Organization: Yes Interactive AS Hi. I have a problem: o Don't know how to access postgresql from clisp. o I run FreeBSD 3.2-19990804-STABLE o I run postgresql 6.5.1 o I installed the postgresql642 module (ok, so version mismatch is probably the problem, but I want to be certain). o I added the text "-L/usr/local/pgsql /lib/ -lpq" to LIBS in the makefile to make things link properly. o I then try to check the installation: [1]> (load "postgresql.lsp") ;; Loading file postgresql.lsp ... *** - A foreign variable "pgresStatus" does not exist 1. Break SQL[2]> [3]> Bye. The file being loaded is clisp-1999-07-22/modules/postgresql642/postgresql.lsp. o Just to see if the pgresStatus is present I did a little 'nm'-ing. % nm /usr/local/pgsql/lib/libpq.a | grep pgresStatus 00000000 D pgresStatus % nm /usr/local/pgsql/lib/libpq.so | grep pgresStatus 0000abd4 D pgresStatus % nm /usr/local/pgsql/lib/libpq.so.2 | grep pgresStatus 0000abd4 D pgresStatus Does any of you have a clue where I should start looking for solutions? (Rmz) From unk6@rz.uni-karlsruhe.de Thu Sep 16 15:21:32 1999 Received: from mailgate.rz.uni-karlsruhe.de (nz40.rz.uni-karlsruhe.de [129.13.197.4]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id PAA19454 for ; Thu, 16 Sep 1999 15:21:30 -0700 (PDT) Received: from rz114s0.uni-karlsruhe.de (isdn216-132.rz.uni-karlsruhe.de [129.13.216.132]) by mailgate.rz.uni-karlsruhe.de with smtp (Exim 3.02 #2) id 11Rk4h-0000Xf-00; Fri, 17 Sep 1999 00:32:19 +0200 To: clisp-list@seagull.cons.org Subject: Re: clisp as cgi script References: <14305.2795.126662.799715@inanna.starseed.com> From: Gilbert Baumann Date: 17 Sep 1999 00:25:04 +0200 In-Reply-To: Erik Arneson's message of "Thu, 16 Sep 1999 08:05:51 -0700 (PDT)" Lines: 18 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=ISO-8859-1 Message-Id: Erik Arneson writes: > [...] The one part I was still > having trouble with was decoding the query string (i.e. turning %20 into > a space and such). [...] > > Anybody have a solution for query string decoding that I could use, by > the way? My Browser contains a pretty solid implementation of an URL data type. There is also a lot other useful WWW stuff in there. And what you can't find in Closure's code base, you may find in CL-HTTP's. CL-HTTP: http://www.ai.mit.edu/projects/iiip/doc/cl-http/home-page.html Closure: http://www.uni-karlsruhe.de/~unk6/closure/ Gilbert. From jon@totient.demon.co.uk Thu Sep 16 15:30:18 1999 Received: from totient.demon.co.uk (jon@totient.demon.co.uk [158.152.119.202]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id PAA19538 for ; Thu, 16 Sep 1999 15:30:16 -0700 (PDT) Received: (from jon@localhost) by totient.demon.co.uk (8.8.7/8.8.7) id XAA01820; Thu, 16 Sep 1999 23:32:32 +0100 From: Jon Dyte MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 16 Sep 1999 23:32:31 +0100 (BST) To: clisp-list@seagull.cons.org Subject: clisp as cgi script In-Reply-To: <199909161329.OAA09444@exotica.inesc.pt> References: <199909161329.OAA09444@exotica.inesc.pt> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14305.28561.532905.929738@eco.totient.co.uk> I have set up a script called qclisp (quiet clisp) This runs clisp with the options -norc -q like this #!/bin/sh exec /usr/local/lib/lisp/lisp.run -M /usr/local/lib/lisp/lispinit.mem -norc -q "$@" I called this script qclisp I then write cgi scripts like #!/usr/bin/env qclisp ;;;; the space between env and qclisp is important (format *standard-output* "Content-type: text/plain~%") (format *standard-output* "~%Hello World From Clisp ~%") (mapc #'(lambda (name) (format *standard-output* "~% ~A = ~A" name (system::getenv name))) '("SERVER_SOFTWARE" "SERVER_NAME" "GATEWAY_INTERFACE" "SERVER_PROTOCOL" "SERVER_PORT" "REQUEST_METHOD" "HTTP_ACCEPT" "PATH_INFO" "PATH_TRANSLATED" "SCRIPT_NAME" "QUERY_STRING" "REMOTE_HOST" "REMOTE_ADDR" "REMOTE_USER" "AUTH_TYPE" "CONTENT_TYPE" "CONTENT_LENGTH" )) From emarsden@laas.fr Fri Sep 17 01:19:52 1999 Received: from laas.laas.fr (root@laas.laas.fr [140.93.0.15]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id BAA25661 for ; Fri, 17 Sep 1999 01:19:50 -0700 (PDT) Received: from dukas.laas.fr (dukas [140.93.21.58]) by laas.laas.fr (8.9.3/8.9.3) with ESMTP id KAA23274; Fri, 17 Sep 1999 10:31:12 +0200 (MET DST) Received: (from emarsden@localhost) by dukas.laas.fr (8.9.3/8.9.3) id KAA03619; Fri, 17 Sep 1999 10:31:10 +0200 (MET DST) To: Erik Arneson Cc: Multiple recipients of list Subject: Re: clisp as cgi script References: <14305.2795.126662.799715@inanna.starseed.com> Organization: LAAS-CNRS http://www.laas.fr/ MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Eric-Conspiracy: there is no conspiracy X-Attribution: ecm X-URL: http://www.chez.com/emarsden/ From: Eric Marsden Date: 17 Sep 1999 10:31:10 +0200 In-Reply-To: Erik Arneson's message of "Thu, 16 Sep 1999 08:06:05 -0700 (PDT)" Message-ID: Lines: 88 X-Mailer: Gnus v5.7/Emacs 20.4 >>>>> "ea" == Erik Arneson writes: ea> Anybody have a solution for query string decoding that I could ea> use, by the way? here is what I use (this is from a web server I wrote which is based on the design of the su-net server, which I find very elegant). The code isn't really release quality, though. ;; url-encodings.lsp ;; ;; Copyright: (C) 1999 Eric Marsden ;; Author: Eric Marsden ;; Time-stamp: <1999-09-16 ecm> (defpackage "URL-ENCODINGS" (:documentation "Url encoding/decoding routines") (:use "SCSH" "COMMON-LISP") (:export "WWW-ENCODE" "WWW-DECODE" "WWW-ENCODE-STRING" "WWW-DECODE-STRING")) (in-package :url-encodings) (defconstant url-unreserved-chars '( #\a #\b #\c #\d #\e #\f #\g #\h #\i #\j #\k #\l #\m #\n #\o #\p #\q #\r #\s #\t #\u #\v #\w #\x #\y #\z #\A #\B #\C #\D #\E #\F #\G #\H #\I #\J #\K #\L #\M #\N #\O #\P #\Q #\R #\S #\T #\U #\V #\W #\X #\Y #\Z #\0 #\1 #\2 #\3 #\4 #\5 #\6 #\7 #\8 #\9 #\$ #\- #\_ #\. #\! #\~ #\* #\' #\( #\) #\,)) (defun hex-char-p (ch) (declare (character ch)) (let ((hexchars '(#\0 #\1 #\2 #\3 #\4 #\5 #\6 #\7 #\8 #\9 #\A #\B #\C #\D #\E #\F))) (member (char-upcase ch) hexchars :test #'char=))) ;; decode %xx to the corresponding character and + to ' ' (defun www-decode-string (str) (declare (simple-string str)) (do ((i 0) (len (length str)) (decoded '())) ((>= i len) (concatenate 'string (nreverse decoded))) (let ((ch (aref str i))) (cond ((char= #\+ ch) (push #\space decoded) (incf i)) ((and (char= #\% ch) (< (+ i 2) len) (hex-char-p (aref str (+ i 1))) (hex-char-p (aref str (+ i 2)))) (let ((hex (parse-integer str :radix 16 :start (+ i 1) :end (+ i 3)))) (push (int-char hex) decoded) (incf i 3))) (t (push ch decoded) (incf i)))))) (defun www-encode-string (str) (declare (simple-string str)) (apply #'concatenate 'string (loop for ch across str collect (cond ((member ch url-unreserved-chars :test #'char=) (string ch)) ((char= #\space ch) (string #\+)) (t (format nil "%~2,'0x" (char-int ch))))))) (defun www-encode (alist) (www-encode-string (join-strings (mapcar #'(lambda (p) (format nil "~s=~s" (car p) (cdr p))) alist) "&"))) ;; Parse "foo=x&bar=y+re" into (("foo" . "x") ("bar" . "y re")) ;; Substrings are plus-decoded and then URI-decoded. (defun www-decode (q) (declare (simple-string q)) (flet ((split-= (str) (let ((pos (or (position #\= str) 0))) (cons (subseq str 0 pos) (subseq str (+ pos 1)))))) (mapcar #'split-= (funcall (infix-splitter #\&) (www-decode-string q))))) ;; EOF From haible@ilog.fr Fri Sep 17 02:44:00 1999 Received: from sceaux.ilog.fr (sceaux.ilog.fr [193.55.64.10]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id CAA26785 for ; Fri, 17 Sep 1999 02:43:55 -0700 (PDT) Received: from laposte.ilog.fr (laposte [172.17.1.6]) by sceaux.ilog.fr (8.9.3/8.9.3) with ESMTP id LAA17707 for ; Fri, 17 Sep 1999 11:54:29 +0200 (MET DST) Received: from jaures.ilog.fr ([172.17.4.4]) by laposte.ilog.fr (8.9.3/8.9.3) with ESMTP id LAA11805; Fri, 17 Sep 1999 11:55:18 +0200 (MET DST) From: Bruno Haible Received: (from haible@localhost) by jaures.ilog.fr (8.9.3/8.9.3) id LAA26551; Fri, 17 Sep 1999 11:55:17 +0200 (MET DST) Date: Fri, 17 Sep 1999 11:55:17 +0200 (MET DST) Message-Id: <199909170955.LAA26551@jaures.ilog.fr> To: clisp-list@clisp.cons.org Subject: Re: clisp as cgi script [Mail forwarded from Erann Gat .] On Thu, 16 Sep 1999, Erik Arneson wrote: > You might be able to get some use out of it. The one part I was still > having trouble with was decoding the query string (i.e. turning %20 into > a space and such). Since I'm coming from Perl, it seemed like a lot of > work for me...I got a little ways, and then suddenly my real job got > more demanding. :) > > Anybody have a solution for query string decoding that I could use, by > the way? (defun parse-url-encoded-string (s) (with-output-to-string (out) (do ( (i 0 (1+ i)) ) ( (>= i (length s)) out ) (let ( (c (char s i)) ) (case c (#\% (setf c (code-char (parse-integer s :start (+ i 1) :end (+ i 3) :radix 16 :junk-allowed t))) (unless (or (null c) (eql c #\linefeed)) (princ c out)) (incf i 2)) (#\+ (princ #\Space out)) (otherwise (princ c out))))))) You may find the following useful also: (defun parse-http-header (h) (let ( (index (position #\: h)) ) (and index (list (intern (string-upcase (subseq h 0 index))) (subseq h (+ index 2)))))) (defun parse-url (s) (let* ( (index1 (position #\Space s)) (index2 (position #\Space s :from-end t)) ) (and index1 index2 (> index2 index1) (let ( (method (intern (subseq s 0 index1))) (url (subseq s (+ index1 2) index2)) (form-slots "") ) (when (and (eq method 'get) (setf index1 (position #\? url))) (setf form-slots (subseq url (1+ index1))) (setf url (subseq url 0 index1))) (values url (parse-form-slots form-slots)))))) (defun parse-form-slots (s) (let* ( (index1 (position #\= s)) (index2 (position #\& s)) ) (cond ( index1 (cons (intern (string-upcase (subseq s 0 index1))) (cons (parse-url-encoded-string (subseq s (1+ index1) index2)) (and index2 (parse-form-slots (subseq s (1+ index2)))))) ) ( (string= s "") nil ) (t s)))) E. From haible@ilog.fr Fri Sep 17 02:45:59 1999 Received: from sceaux.ilog.fr (sceaux.ilog.fr [193.55.64.10]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id CAA26867 for ; Fri, 17 Sep 1999 02:45:57 -0700 (PDT) Received: from laposte.ilog.fr (laposte [172.17.1.6]) by sceaux.ilog.fr (8.9.3/8.9.3) with ESMTP id LAA17836 for ; Fri, 17 Sep 1999 11:56:34 +0200 (MET DST) Received: from jaures.ilog.fr ([172.17.4.4]) by laposte.ilog.fr (8.9.3/8.9.3) with ESMTP id LAA12042; Fri, 17 Sep 1999 11:57:22 +0200 (MET DST) From: Bruno Haible Received: (from haible@localhost) by jaures.ilog.fr (8.9.3/8.9.3) id LAA26554; Fri, 17 Sep 1999 11:57:21 +0200 (MET DST) Date: Fri, 17 Sep 1999 11:57:21 +0200 (MET DST) Message-Id: <199909170957.LAA26554@jaures.ilog.fr> To: clisp-list@clisp.cons.org Subject: Re: clisp as cgi script [Message forwarded from Erann Gat .] On Thu, 16 Sep 1999 dtillman@ozarkaircraftsystems.com wrote: > One more note: Once you start doing html in CLOS you will > never want to use anything else. Here here. I've been hacking on a CL-based object-oriented web server in my spare time. I can do things like: (defun make-date-selector () (list (make-html-menu :id 'month :items *months*) (make-html-menu :id 'day :items (loop for i from 1 to 31 collect i)) (make-html-menu :id 'year :items '(1999 2000 2001 2002)))) Now whenever I need an HTML form with a date input widget I just do: (make-html-form :items (list (make-date-selector) ...)) Instead of a "home page" my server serves up *http-root-object*. I can embed s-expressions in my url's so my server essentially just parses the URL and evals it. (It's a little more complicated than that because it has to handle errors and provide some security, but that's the gist of it.) I could have used cl-http, but I found it to be much to heavyweight for my tastes. The core of my server is only about two pages of code, and I have about eight pages of code defining different kinds of htmLISP object classes. Maybe we should get together and standardize some of this stuff. We may be able to avoid reinventing some wheels. If there's enough interest I'll polish up my server, document it, and put it on the web as a start. Erann Gat gat@jpl.nasa.gov From haible@ilog.fr Fri Sep 17 03:35:13 1999 Received: from sceaux.ilog.fr (sceaux.ilog.fr [193.55.64.10]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id DAA27666 for ; Fri, 17 Sep 1999 03:35:08 -0700 (PDT) Received: from laposte.ilog.fr (laposte [172.17.1.6]) by sceaux.ilog.fr (8.9.3/8.9.3) with ESMTP id MAA19149 for ; Fri, 17 Sep 1999 12:45:43 +0200 (MET DST) Received: from jaures.ilog.fr ([172.17.4.4]) by laposte.ilog.fr (8.9.3/8.9.3) with ESMTP id MAA15881; Fri, 17 Sep 1999 12:46:31 +0200 (MET DST) From: Bruno Haible Received: (from haible@localhost) by jaures.ilog.fr (8.9.3/8.9.3) id MAA26663; Fri, 17 Sep 1999 12:46:30 +0200 (MET DST) Date: Fri, 17 Sep 1999 12:46:30 +0200 (MET DST) Message-Id: <199909171046.MAA26663@jaures.ilog.fr> To: clisp-list@seagull.cons.org Subject: Re: postgresql on FreeBSD In-Reply-To: <19990916184207.G71941@dunk.follo.net> References: <19990916184207.G71941@dunk.follo.net> Björn Remseth writes: > o I then try to check the installation: > > [1]> (load "postgresql.lsp") > ;; Loading file postgresql.lsp ... > *** - A foreign variable "pgresStatus" does not exist > 1. Break SQL[2]> > [3]> > Bye. > > The file being loaded is > clisp-1999-07-22/modules/postgresql642/postgresql.lsp. Code which uses the CLISP FFI has to be first compiled (using compile-file), you can't load it in interpreted mode. The easiest way to load the module is to execute $ clisp-link run /usr/local/lib/clisp/base .../modules/postgresql642 Bruno From tl@exotica.inesc.pt Fri Sep 17 06:22:03 1999 Received: from inesc.inesc.pt (inesc.inesc.pt [146.193.0.1]) by seagull.cdrom.com (8.8.8/8.7.3) with SMTP id GAA29570 for ; Fri, 17 Sep 1999 06:22:00 -0700 (PDT) Received: from exotica.inesc.pt by inesc.inesc.pt with SMTP; id AA17745 (/); Fri, 17 Sep 1999 14:33:24 +0100 Received: from exotica (tl@localhost [127.0.0.1]) by exotica.inesc.pt (8.8.7/8.8.7) with ESMTP id OAA19750 for ; Fri, 17 Sep 1999 14:33:27 +0100 Message-Id: <199909171333.OAA19750@exotica.inesc.pt> To: clisp-list@clisp.cons.org Subject: clisp as cgi script Reply-To: thibault.langlois@inesc.pt Date: Fri, 17 Sep 1999 14:33:26 +0100 From: Thibault Langlois Thanks for all these responses ! 1. Bruno Haible was right, the last version of clisp solved the "*** - UNIX error 25 (ENOTTY): Inappropriate ioctl for device" error. Now it works as a clisp script (using #!/usr/local/bin/clisp). 2. Dave Tillman suggested to have clisp process continually running, that listen to a named pipe. The cgi script would just write the query string to that pipe. The benefit is that clisp is not loaded into memory on each request. Having a port specialized for cgi request would be a nice solution, unfortunately have no time to make it work. 3. I finnally used Eric Marsden's code. thanks. Unlike Erik Arneson's it does not require the regexp package. 4. Gilbert Baumann suggested to look at closure or cl-http code. I do not know closure but I think cl-http is Big and hard to read (maybe I just have to try harder...). Anyway, I agree, it is better not to re-invent the wheel. Thanks again. Thibault From emarsden@laas.fr Fri Sep 17 06:48:40 1999 Received: from laas.laas.fr (root@laas.laas.fr [140.93.0.15]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id GAA00165 for ; Fri, 17 Sep 1999 06:48:37 -0700 (PDT) Received: from dukas.laas.fr (dukas [140.93.21.58]) by laas.laas.fr (8.9.3/8.9.3) with ESMTP id PAA06337 for ; Fri, 17 Sep 1999 15:59:48 +0200 (MET DST) Received: (from emarsden@localhost) by dukas.laas.fr (8.9.3/8.9.3) id PAA09487; Fri, 17 Sep 1999 15:59:46 +0200 (MET DST) To: Multiple recipients of list Subject: Re: clisp as cgi script References: <199909170957.LAA26554@jaures.ilog.fr> Organization: LAAS-CNRS http://www.laas.fr/ MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Eric-Conspiracy: there is no conspiracy X-Attribution: ecm X-URL: http://www.chez.com/emarsden/ From: Eric Marsden Date: 17 Sep 1999 15:59:46 +0200 In-Reply-To: Bruno Haible's message of "Fri, 17 Sep 1999 02:48:22 -0700 (PDT)" Message-ID: Lines: 18 X-Mailer: Gnus v5.7/Emacs 20.4 >>>>> "eg" == Bruno Haible writes: eg> Maybe we should get together and standardize some of this stuff. eg> We may be able to avoid reinventing some wheels. If there's enough eg> interest I'll polish up my server, document it, and put it on the eg> web as a start. excellent idea. Maybe it would also be worth putting together a web page too containing sample code and tricks such as "write to named pipe" or "use X for static pages and dispatch scripts to CLISP" which might be useful to people. I agree that there is room for a simple, understandable CL web server code base (with a reasonable licence!). -- Eric Marsden It's elephants all the way down From erik@inanna.starseed.com Fri Sep 17 08:01:54 1999 Received: from inanna.starseed.com (root@inanna.starseed.com [206.151.157.197]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id IAA00984 for ; Fri, 17 Sep 1999 08:01:51 -0700 (PDT) Received: (from erik@localhost) by inanna.starseed.com (8.9.3/8.9.3) id IAA32513; Fri, 17 Sep 1999 08:17:19 -0700 From: Erik Arneson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14306.23423.160478.922588@inanna.starseed.com> Date: Fri, 17 Sep 1999 08:17:19 -0700 (PDT) To: clisp-list@seagull.cons.org Cc: Multiple recipients of list Subject: Re: clisp as cgi script In-Reply-To: <199909170955.LAA26551@jaures.ilog.fr> References: <199909170955.LAA26551@jaures.ilog.fr> X-Mailer: VM 6.75 under 21.2 (beta19) "Shinjuku" XEmacs Lucid X-Fnord: http://inanna.starseed.com/~erik/ On 17 Sep 99, Bruno Haible wrote: > (defun parse-url-encoded-string (s) > ... Thank you so much! I guess I should have seen that was the way to do it, I've just been so busy lately that I haven't had time to wrap my brain around it. On 17 Sep 99, Eric Marsden wrote: > >>>>> "eg" == Bruno Haible writes: > eg> Maybe we should get together and standardize some of this stuff. > eg> We may be able to avoid reinventing some wheels. If there's enough > eg> interest I'll polish up my server, document it, and put it on the > eg> web as a start. > > excellent idea. Maybe it would also be worth putting together a web > page too containing sample code and tricks such as "write to named > pipe" or "use X for static pages and dispatch scripts to CLISP" which > might be useful to people. > > I agree that there is room for a simple, understandable CL web server > code base (with a reasonable licence!). I could definitely use one. I love CL and have really wanted to start using it for some more substantial, public stuff. Now that there's a PostgreSQL interface for CLISP (which I haven't actually tried out yet, but I sure plan on doing so), we could have a lot of fun and get a lot of use out of an easier-to-use web server. -- # Erik Arneson erik@starseed.com Webring Software Engineer # # Yahoo! Inc. PGP ID: 2048/84413E19 (541) 482-3000x114 # # "There's such a fine line between stupid and clever." Spinal Tap # From hoehle@mmkmail.gmd.de Fri Sep 17 09:25:46 1999 Received: from mail.gmd.de (mail.gmd.de [129.26.8.90]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id JAA02055 for ; Fri, 17 Sep 1999 09:25:42 -0700 (PDT) Received: from zeus.gmd.de (zeus.gmd.de [129.26.165.1]) by mail.gmd.de (8.8.8/8.8.8) with ESMTP id SAA01287 for ; Fri, 17 Sep 1999 18:36:57 +0200 (MET DST) Received: from localhost (hoehle@localhost) by zeus.gmd.de (8.9.1/8.9.3) with SMTP id SAA16976 for ; Fri, 17 Sep 1999 18:37:00 +0200 (MET DST) X-Authentication-Warning: zeus.gmd.de: hoehle owned process doing -bs Date: Fri, 17 Sep 1999 18:37:00 +0200 (MET DST) From: Joerg Hoehle X-Sender: hoehle@zeus To: clisp-list@seagull.cons.org Subject: Re: Platform poll In-Reply-To: <199909151230.OAA06680@jaures.ilog.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 15 Sep 1999, Bruno Haible wrote: > For example if you want to assume that the OS has dynamic loading. For this, > you need to drop support of Linux/a.out and AmigaOS. [I'd have accepted this argument if you'd said that the next version of CLISP requires mprotect() and will support generational GC only.] IMHO, AmigaOS-CLISP has dynamic loading of foreign libraries since 1995. It's just a different kind of dynamic loading than on UNIX. On UNIX, you need a *.a or *.o (*.so?), while on the Amiga, you want a *.library. Where's the problem? I should repeat here that I'm willing to offer any help about CLISP internals and FFI design to anybody willing to try to make *.dll work in MS-Win*. I can't compile, build or debug MS-Win* myself though, but I know the guts (sp?) and wood of CLISP. I think there's little modification needed to what's already in CLISP to add support for MS-Win* .dll dynamic loading. I believe it to be similar to AmigaOS. >>I keep hearing people around me say "Ada is dead", Smalltalk is dead, >>Lisp is dead, ... :-( Rainer Joswig>Partly off topic: Lisp can't be dead. I choose these 3 because there are colleagues in my small department (myself included) fluent in and using these languages (not at the same time :). BTW, anybody doing a port to a native Mac? :-) I'd have my wife use that! Regards, Jo"rg Ho"hle. Joerg.Hoehle@gmd.de http://fit.gmd.de/~hoehle/amiga.html From hoehle@mmkmail.gmd.de Fri Sep 17 09:46:15 1999 Received: from mail.gmd.de (mail.gmd.de [129.26.8.90]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id JAA02402 for ; Fri, 17 Sep 1999 09:46:08 -0700 (PDT) Received: from zeus.gmd.de (zeus.gmd.de [129.26.165.1]) by mail.gmd.de (8.8.8/8.8.8) with ESMTP id SAA03295; Fri, 17 Sep 1999 18:57:30 +0200 (MET DST) Received: from localhost (hoehle@localhost) by zeus.gmd.de (8.9.1/8.9.3) with SMTP id SAA17035; Fri, 17 Sep 1999 18:57:32 +0200 (MET DST) X-Authentication-Warning: zeus.gmd.de: hoehle owned process doing -bs Date: Fri, 17 Sep 1999 18:57:32 +0200 (MET DST) From: Joerg Hoehle X-Sender: hoehle@zeus To: clisp-list@seagull.cons.org cc: lug@lisp.de Subject: code sharing (was: clisp as cgi script) In-Reply-To: <199909170957.LAA26554@jaures.ilog.fr> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Erann Gat wrote: [about simple CLOS web server] > Maybe we should get together and standardize some of this stuff. > We may be able to avoid reinventing some wheels. If there's enough > interest I'll polish up my server, document it, and put it on the > web as a start. I'm under the impression that not enough code is shared by the Lisp community. The AI repository seems dead and I've seen nothing else where to get code snippets that all people (from beginners to experts) can benefit from -- except closely following comp.lang.lisp. For more than a decade I've heard the "polish up & document" argument, and for as long I've "seen" lost source code of possibly interesting but now unusable systems. I don't know about the CPAN except for the name, but I bet it's not only top-quality code that's to be found there. Given the curent situation, my impression is that it would be better to be flooded by code (like Emacs-Lisp archives) than not at all -- which is currently the case. I'd be very happy if there could be ready-made snippets of and concepts for x and y to use. E.g., I also have plans to write a special but simple server and would probably reinvent many wheels once again :-( :-( E.g., defsystem probably contains a topological sort. Why can't I find some place (library?) where I knew I would find a topological sort the day I needed one instead of again writing my own? In c.l.functional, somebody recently asked why e.g. Python was used over Haskell -- I believe code snippets is part of the answer. But I don't wish to go into the "working 90%" discussion. Regards, Jo"rg Ho"hle. Joerg.Hoehle@gmd.de http://fit.gmd.de/~hoehle/amiga.html From erik@inanna.starseed.com Fri Sep 17 10:16:08 1999 Received: from inanna.starseed.com (root@inanna.starseed.com [206.151.157.197]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id KAA02958 for ; Fri, 17 Sep 1999 10:16:07 -0700 (PDT) Received: (from erik@localhost) by inanna.starseed.com (8.9.3/8.9.3) id KAA00583; Fri, 17 Sep 1999 10:31:36 -0700 From: Erik Arneson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14306.31480.137464.137266@inanna.starseed.com> Date: Fri, 17 Sep 1999 10:31:36 -0700 (PDT) To: clisp-list@seagull.cons.org Cc: Multiple recipients of list Subject: Re: code sharing (was: clisp as cgi script) In-Reply-To: References: X-Mailer: VM 6.75 under 21.2 (beta19) "Shinjuku" XEmacs Lucid X-Fnord: http://inanna.starseed.com/~erik/ On 17 Sep 99, Joerg Hoehle wrote: > In c.l.functional, somebody recently asked why e.g. Python was used over > Haskell -- I believe code snippets is part of the answer. But I don't > wish to go into the "working 90%" discussion. I gotta agree with this one. Being able to get your hands on some free code is one of the things that makes learning a new language easy. Especially for those of us who are forced by our occupation to spend so much time working in another language. I don't have a lot of free time during the week where I can sit down and try to puzzle out new languages on my own, but if I can get ahold of some quick examples it's much easier for me to start working on projects. A CPAN-like repository for Common Lisp code would be very cool and probably get a ridiculous amount of use. -- # Erik Arneson erik@starseed.com Webring Software Engineer # # Yahoo! Inc. PGP ID: 2048/84413E19 (541) 482-3000x114 # # "There's such a fine line between stupid and clever." Spinal Tap # From gat@jpl.nasa.gov Fri Sep 17 11:42:55 1999 Received: from mail3.jpl.nasa.gov (eis-msg-024.jpl.nasa.gov [137.78.160.181]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id LAA04470 for ; Fri, 17 Sep 1999 11:42:54 -0700 (PDT) Received: from binkley ([128.149.8.194]) by mail3.jpl.nasa.gov (Netscape Messaging Server 3.6) with SMTP id AAA3E5F for ; Fri, 17 Sep 1999 11:54:12 -0700 Date: Fri, 17 Sep 1999 11:53:49 -0700 (PDT) From: Erann Gat X-Sender: gat@binkley To: clisp-list@seagull.cons.org Subject: Re: clisp as cgi script In-Reply-To: <14306.23423.160478.922588@inanna.starseed.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Fri, 17 Sep 1999, Erik Arneson wrote: > > I agree that there is room for a simple, understandable CL web server > > code base (with a reasonable licence!). > > I could definitely use one. I love CL and have really wanted to start > using it for some more substantial, public stuff. Now that there's a > PostgreSQL interface for CLISP (which I haven't actually tried out yet, > but I sure plan on doing so), we could have a lot of fun and get a lot > of use out of an easier-to-use web server. OK, I'm on my way out of town for the weekend, but when I get back I'll clean up and document what I've got and put it on the Web. BTW, one of the biggest obstacles to making a real web server out of CLisp is its lack of multithreading. I know that this topic has come up on and off over the years. Has any progress been made on it? Erann gat@jpl.nasa.gov From russe@ms.com Fri Sep 17 14:30:25 1999 Received: from piinbh1.ms.com (piinbh1.ms.com [199.89.64.71]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id OAA06486 for ; Fri, 17 Sep 1999 14:30:24 -0700 (PDT) Received: (from uucp@localhost) by piinbh1.ms.com (8.8.6/fw v1.22) id RAA18126 for ; Fri, 17 Sep 1999 17:41:46 -0400 (EDT) Received: from unknown(144.14.232.23) by piinbh1 via smap (4.1) id xma017714; Fri, 17 Sep 99 17:41:24 -0400 Received: from hqiedaj51 (hqiedaj51.morgan.com [144.14.168.184]) by hqsmh3.ms.com (8.8.5/imap+ldap v2.3) with ESMTP id RAA07037 for ; Fri, 17 Sep 1999 17:41:23 -0400 (EDT) Date: Fri, 17 Sep 1999 17:41:23 -0400 (EDT) Message-Id: <199909172141.RAA07037@hqsmh3.ms.com> From: Russell McManus To: clisp-list@clisp.cons.org Subject: running CLISP as an Internet daemon? Does anyone know how to run CLISP as an internet daemon, using either select or threads to handle multiple file descriptors? Things like this make me think that it's possible: (lisp:socket-server &optional [port-or-socket]) But I didn't find any 'select' like facility in the impnotes or in the code. Thanks, -russ -- October. This is one of the peculiarly dangerous months to invest in stocks. The others are July, January, September, April, November, May, March, June, December, August, and February. -- Mark Twain From amoroso@mclink.it Sat Sep 18 02:37:55 1999 Received: from mail1.mclink.it (net128-007.mclink.it [195.110.128.7]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id CAA13157 for ; Sat, 18 Sep 1999 02:37:54 -0700 (PDT) Received: from net145-047.mclink.it (net145-047.mclink.it [195.110.145.47]) by mail1.mclink.it (8.9.1/8.9.0) with SMTP id LAA05081; Sat, 18 Sep 1999 11:49:27 +0200 (CEST) From: amoroso@mclink.it (Paolo Amoroso) To: clisp-list@seagull.cons.org Cc: gat@jpl.nasa.gov Subject: Re: clisp as cgi script Date: Sat, 18 Sep 1999 09:48:28 GMT Organization: Paolo Amoroso - Milan, ITALY Message-ID: <37e85ef8.287358@mail.mclink.it> References: <199909170957.LAA26554@jaures.ilog.fr> In-Reply-To: <199909170957.LAA26554@jaures.ilog.fr> X-Mailer: Forte Agent 1.5/32.451 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit On Fri, 17 Sep 1999 02:48:23 -0700 (PDT), you wrote: > [Message forwarded from Erann Gat .] > Maybe we should get together and standardize some of this stuff. > We may be able to avoid reinventing some wheels. If there's enough > interest I'll polish up my server, document it, and put it on the > web as a start. It would be great. Paolo -- EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/ From stig@ii.uib.no Sat Sep 18 07:11:30 1999 Received: from ii.uib.no (eik.ii.uib.no [129.177.16.3]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id HAA17052 for ; Sat, 18 Sep 1999 07:11:26 -0700 (PDT) Received: from ara.ii.uib.no (ara.ii.uib.no [129.177.17.215]) by ii.uib.no (8.8.7/8.8.7) with ESMTP id QAA11507 for ; Sat, 18 Sep 1999 16:22:55 +0200 (MET DST) Received: (from stig@localhost) by ara.ii.uib.no (8.8.8+Sun/8.8.7) id QAA13252; Sat, 18 Sep 1999 16:22:54 +0200 (MET DST) Date: Sat, 18 Sep 1999 16:22:54 +0200 (MET DST) From: Stig Erik Sandoe To: clisp-list@clisp.cons.org Subject: Making CLISP run faster Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII hi, I am currently somewhat frustrated with some code which imho uses too long time in CLISP compared to e.g ACL. I have a set of test-cases which takes at least three times as long on CLISP (40 sec) than on ACL (12 sec). The code has been regularly profiled on ACL which imho has a decent profiler and the code might therefore be more to ACL's taste, but still I find a 3:1 ratio pretty gross. Obviously I need to learn more about CLISP and how it performs in various parts of the code and what to avoid in CLISP. Hopefully you can answer some of my questions: 1) I liked the space-macro which gave me a few hints on where to optimize parts, but are there any recommended tools for profiling which work well with CLISP? Hopefully tools that people actually use.. 2) The implementation notes says: " The declarations (type type var ...), (ftype type fun ...), (function name arglist result-type), (optimize (quality value) ...) are ignored by the interpreter and the compiler. " A later example uses (declare (type foo var)) though.. Are my type-declarations worthless in CLISP, and this is the wrong way to go for getting faster code? 3) Has anything been written on performance in CLISP which is still available? I kindof like a GPLed CL-system and would love my code to have acceptable speed for those not using Linux and using ACL's trial version. The above-mentioned 12 sec on ACL is tolerable speed, but 40 sec is unacceptable.. :( -- ------------------------------------------------------------------ Stig Erik Sandoe Institute of Informatics, University of Bergen stig@ii.uib.no http://www.ii.uib.no/~stig/ From jon@totient.demon.co.uk Sat Sep 18 13:55:15 1999 Received: from totient.demon.co.uk (jon@totient.demon.co.uk [158.152.119.202]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id NAA20668 for ; Sat, 18 Sep 1999 13:55:12 -0700 (PDT) Received: (from jon@localhost) by totient.demon.co.uk (8.8.7/8.8.7) id VAA02733; Sat, 18 Sep 1999 21:57:49 +0100 From: Jon Dyte MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sat, 18 Sep 1999 21:57:48 +0100 (BST) To: clisp-list@seagull.cons.org Subject: Re: clisp as cgi script In-Reply-To: References: X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14307.63491.220564.695670@eco.totient.co.uk> Erann Gat writes: > > On Fri, 17 Sep 1999, Erik Arneson wrote: > > > > I agree that there is room for a simple, understandable CL web server > > > code base (with a reasonable licence!). > > > > I could definitely use one. I love CL and have really wanted to start > > using it for some more substantial, public stuff. Now that there's a > > PostgreSQL interface for CLISP (which I haven't actually tried out yet, > > but I sure plan on doing so), we could have a lot of fun and get a lot > > of use out of an easier-to-use web server. > > OK, I'm on my way out of town for the weekend, but when I get back > I'll clean up and document what I've got and put it on the Web. > > BTW, one of the biggest obstacles to making a real web server out > of CLisp is its lack of multithreading. I know that this topic has > come up on and off over the years. Has any progress been made on it? > > Erann > gat@jpl.nasa.gov HI A while ago I posted on clisp-list a question about the feasibility of building clisp as shared library and then using that to make an apache lisp module. I think this is possible but I don't know enough of the clisp internels to rebuild it as libary. Does any of the maintainers (Bruno,Sam?) have time to look at this or explain it. The code has some comments in german, but I can't read that language. There is also assember in the clisp sources and this might cause problems in a shared libary (well it did for the Gwydion Dylan implementation). If we could do this we could have compiled lisp in the apache webserver and just configure apache to call the appropriate lisp. The apache modules book by oreilly explains how to do this for perl and C. Somewhere on the web there is the code to make a module for Python(PyApache) so I'm pretty sure it's possible given enough info on what to change in clisp (I think it's the file spvw.c). Contributed lisp code would be great under a sufficiently open license. CL-HTTP licensing is strange and as the latest survey shows at http://www.netcraft.com is not used on many internet sites (15 last count). I think a clisp/apache solution would get more punters. As it is these threads have shown it's relatively easy to get clisp serving pages via cgi, but some work is needed on a framework around it plus integration into other webservers. Jon From dobes@mindless.com Sat Sep 18 15:02:04 1999 Received: from mail.rdc1.bc.home.com (imail@ha1.rdc1.bc.wave.home.com [24.2.10.66]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id PAA21470 for ; Sat, 18 Sep 1999 15:02:04 -0700 (PDT) Received: from cr594972-a.surrey1.bc.wave.home.com ([24.112.126.47]) by mail.rdc1.bc.home.com (InterMail v4.01.01.07 201-229-111-110) with SMTP id <19990918221343.DEPV26817.mail.rdc1.bc.home.com@cr594972-a.surrey1.bc.wave.home.com> for ; Sat, 18 Sep 1999 15:13:43 -0700 Received: (qmail 17081 invoked from network); 18 Sep 1999 22:13:41 -0000 Received: from sludge.localdomain (HELO mindless.com) (192.168.0.2) by nexus.localdomain with SMTP; 18 Sep 1999 22:13:41 -0000 Message-ID: <37E40ED2.DAEA3E65@mindless.com> Date: Sat, 18 Sep 1999 15:14:42 -0700 From: Dobes Vandermeer X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en,zh,zh-CN,zh-TW,fr,fr-BE,fr-CA,fr-FR,fr-CH,ja,af MIME-Version: 1.0 To: clisp-list@seagull.cons.org CC: Multiple recipients of list Subject: Re: Making CLISP run faster References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Stig Erik Sandoe wrote: > > hi, > > I am currently somewhat frustrated with some code which imho uses > too long time in CLISP compared to e.g ACL. I have a set of > test-cases which takes at least three times as long on CLISP > (40 sec) than on ACL (12 sec). Allegro compiles to native code, but CLISP does not (AFAIK). Thus Allegro will inevitably be X times faster than CLISP. Dynamic compilers (like ACL) are not trivial to write in comparison to a regular script interpreter (like CLISP) so you are facing the old "Yu get what you paid for" problem. I myself am working on a GPL dynamic compiler for Intel's, I am mostly done the core components; I basically just have to implement enclosed variables, exception handling, and the CL library :) CU Dobes From michaelb@ieee.org Sun Sep 19 00:28:34 1999 Received: from vasquez.zip.com.au (mail@vasquez.zip.com.au [203.12.97.41]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id AAA25646 for ; Sun, 19 Sep 1999 00:28:31 -0700 (PDT) Received: from cthulhu.arkham.org.au (itchy30.zip.com.au [61.8.12.30]) by vasquez.zip.com.au (8.9.2/8.9.1) with SMTP id RAA16201 for ; Sun, 19 Sep 1999 17:26:11 +1000 (EST) From: Michael Beach To: clisp-list@seagull.cons.org Subject: Re: clisp as cgi script Date: Mon, 20 Sep 1999 04:30:19 +1000 X-Mailer: KMail [version 1.0.20] Content-Type: text/plain References: <14307.63491.220564.695670@eco.totient.co.uk> MIME-Version: 1.0 Message-Id: <99092004383800.00731@cthulhu.arkham.org.au> Content-Transfer-Encoding: 8bit > A while ago I posted on clisp-list a question about the feasibility of > building clisp as shared library and then using that to make an apache > lisp module. I think this is possible but I don't know enough of the clisp > internels to rebuild it as libary. Does any of the maintainers > (Bruno,Sam?) have time to look at this or explain it. The code has > some comments in german, but I can't read that language. There is also > assember in the clisp sources and this might cause problems in a > shared libary (well it did for the Gwydion Dylan implementation). > > If we could do this we could have compiled lisp in the apache webserver and > just configure apache to call the appropriate lisp. The apache modules > book by oreilly explains how to do this for perl and C. Somewhere on > the web there is the code to make a module for Python(PyApache) so I'm > pretty sure it's possible given enough info on what to change in > clisp (I think it's the file spvw.c). > > Contributed lisp code would be great under a sufficiently open > license. CL-HTTP licensing is strange and as the latest survey shows at > http://www.netcraft.com is not used on many internet sites (15 last > count). I think a clisp/apache solution would get more punters. > > As it is these threads have shown it's relatively easy to get clisp > serving pages via cgi, but some work is needed on a framework around > it plus integration into other webservers. > > Jon Instead of trying to get CLisp linked into Apache, what about just using FastCGI to call (from Apache) an external daemon (written in CLisp) to handle the CGI stuff. This would probably require less changes to CLisp, and would have the advantage of working with any other web server which has support for FastCGI too. Or another alternative would be to use that apache module which maps requests to CORBA calls, and then get ILU going with CLisp so it can be used to service the CORBA-mapped requests. Mind you, a 100% Lisp web server would be a cool thing, but making a dent in the Apache mindshare would be a bit problematic. Regards M.Beach From ds26@gte.com Sun Sep 19 07:05:55 1999 Received: from newman.gte.com ([132.197.8.26]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id HAA28972 for ; Sun, 19 Sep 1999 07:05:54 -0700 (PDT) Received: from bunny.gte.com (bunny.gte.com [132.197.8.1]) by newman.gte.com (8.9.1/8.9.1) with ESMTP id KAA22928; Sun, 19 Sep 1999 10:17:05 -0400 (EDT) From: Dorai Sitaram Received: (ds26@localhost) by bunny.gte.com (8.6.9/8.6.9) id KAA29115; Sun, 19 Sep 1999 10:17:04 -0400 Message-Id: <199909191417.KAA29115@bunny.gte.com> Subject: set-dispatch-macro-character error? (clisp-1999.05.15) To: clisp-list@seagull.cons.org Date: Sun, 19 Sep 1999 10:17:04 -0400 (EDT) In-Reply-To: <99092004383800.00731@cthulhu.arkham.org.au> from "Michael Beach" at Sep 19, 99 00:28:52 am X-Mailer: ELM [version 2.4 PL3] Content-Type: text Hi. I'm using Sam's 1999.05.15 CLISP rpm for Red Hat. The following code used to work in previous releases of CLISP. Now it doesn't. (I needed this to automatically read code from another s-expression-based language.) ;read #t and #f as t and nil resply (set-dispatch-macro-character #\# #\t #'(lambda (p ig ig2) (declare (ignore p ig ig2)) t)) (set-dispatch-macro-character #\# #\f #'(lambda (p ig ig2) (declare (ignore p ig ig2)) nil)) While this still loads, it doesn't behave as expected (by me). E.g., #t doesn't read as t but produces error. [3]> #t *** - read from # #>: After #\# is #\t an undefined dispatch macro character 1. Break [4]> Suggestions? (For comparison, the code works on Allegro CL 5.0 for Linux.) --d From emarsden@laas.fr Sun Sep 19 09:36:45 1999 Received: from laas.laas.fr (root@laas.laas.fr [140.93.0.15]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id JAA00509 for ; Sun, 19 Sep 1999 09:36:44 -0700 (PDT) Received: from dukas.laas.fr (dukas [140.93.21.58]) by laas.laas.fr (8.9.3/8.9.3) with ESMTP id SAA29679 for ; Sun, 19 Sep 1999 18:48:25 +0200 (MET DST) Received: (from emarsden@localhost) by dukas.laas.fr (8.9.3/8.9.3) id SAA13543; Sun, 19 Sep 1999 18:48:24 +0200 (MET DST) To: Multiple recipients of list Subject: Re: Making CLISP run faster References: <37E40ED2.DAEA3E65@mindless.com> Organization: LAAS-CNRS http://www.laas.fr/ MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Eric-Conspiracy: there is no conspiracy X-Attribution: ecm X-URL: http://www.chez.com/emarsden/ From: Eric Marsden Date: 19 Sep 1999 18:48:24 +0200 In-Reply-To: Dobes Vandermeer's message of "Sat, 18 Sep 1999 15:02:25 -0700 (PDT)" Message-ID: Lines: 16 X-Mailer: Gnus v5.7/Emacs 20.4 >>>>> "dv" == Dobes Vandermeer writes: dv> Allegro compiles to native code, but CLISP does not (AFAIK). dv> Thus Allegro will inevitably be X times faster than CLISP. dv> Dynamic compilers (like ACL) are not trivial to write in dv> comparison to a regular script interpreter (like CLISP) so you dv> are facing the old "Yu get what you paid for" problem. hey, you can use CMUCL, which is not only free of charge but public domain, and it runs faster than ACL on most stuff. -- Eric Marsden From emarsden@laas.fr Sun Sep 19 09:43:42 1999 Received: from laas.laas.fr (root@laas.laas.fr [140.93.0.15]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id JAA00722 for ; Sun, 19 Sep 1999 09:43:41 -0700 (PDT) Received: from dukas.laas.fr (dukas [140.93.21.58]) by laas.laas.fr (8.9.3/8.9.3) with ESMTP id SAA29702 for ; Sun, 19 Sep 1999 18:55:23 +0200 (MET DST) Received: (from emarsden@localhost) by dukas.laas.fr (8.9.3/8.9.3) id SAA13552; Sun, 19 Sep 1999 18:55:22 +0200 (MET DST) To: CLISP Subject: Re: clisp as cgi script References: <14307.63491.220564.695670@eco.totient.co.uk> Organization: LAAS-CNRS http://www.laas.fr/ MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Eric-Conspiracy: there is no conspiracy X-Attribution: ecm X-URL: http://www.chez.com/emarsden/ From: Eric Marsden Date: 19 Sep 1999 18:44:26 +0200 In-Reply-To: Jon Dyte's message of "Sat, 18 Sep 1999 13:56:04 -0700 (PDT)" Message-ID: Lines: 25 X-Mailer: Gnus v5.7/Emacs 20.4 >>>>> "jd" == Jon Dyte writes: [clisp as an Apache module] I'm not convinced that this is the best way to go. The first obvious problem is memory consumption: for a mildly busy site you need at least 20 httpd processes, and even if parts of the CLISP image are shareable, a lot of RAM is necessary (sure, it's cheap). More fundamentally, the forking model prevents the different invocations from communicating (without using IPC, anyway), which prevents the most interesting things you could do with a web server. An alternative approach would be to have CLISP serving up only dynamic pages, running behind Apache -- or something faster like khttpd -- and protected by a cacheing proxy (possibly load balancing to dispatch requests to a number of CLISP servers). That way you don't have to worry about a single slow client blocking processing for a long time, and you don't have to deal with things like HTTP/1.1 chunking, keepalive etc. Still, I'd give mod_clisp a fly if it existed ! -- Eric Marsden From jon@totient.demon.co.uk Sun Sep 19 11:42:49 1999 Received: from totient.demon.co.uk (jon@totient.demon.co.uk [158.152.119.202]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id LAA02611 for ; Sun, 19 Sep 1999 11:42:47 -0700 (PDT) Received: (from jon@localhost) by totient.demon.co.uk (8.8.7/8.8.7) id TAA03572; Sun, 19 Sep 1999 19:45:37 +0100 From: Jon Dyte MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sun, 19 Sep 1999 19:45:36 +0100 (BST) To: clisp-list@seagull.cons.org Subject: Re: clisp as cgi script In-Reply-To: References: X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14309.10800.659876.155442@eco.totient.co.uk> Eric Marsden writes: > >>>>> "jd" == Jon Dyte writes: > > [clisp as an Apache module] > > I'm not convinced that this is the best way to go. The first obvious > problem is memory consumption: for a mildly busy site you need at least > 20 httpd processes, and even if parts of the CLISP image are > shareable, a lot of RAM is necessary (sure, it's cheap). > More fundamentally, the forking model prevents the different > invocations from communicating (without using IPC, anyway), which > prevents the most interesting things you could do with a web server. > An alternative approach would be to have CLISP serving up only dynamic > pages, running behind Apache -- or something faster like khttpd -- and > protected by a cacheing proxy (possibly load balancing to dispatch > requests to a number of CLISP servers). That way you don't have to > worry about a single slow client blocking processing for a long time, > and you don't have to deal with things like HTTP/1.1 chunking, > keepalive etc. > > Still, I'd give mod_clisp a fly if it existed ! > > -- > Eric Marsden Eric Thanks for these points and comments. Really I was coming from the "it's been done in for perl why not lisp" angle. Perl would have the same forking/ipc/memory problems you mention though I'm even less familiar with the perl internals than clisp. (Though perl does already support ipc) If a mod_clisp could be implemented, maybe a second version of the oreilly book could have chapters on that as well as perl/c. This might do something to get lisp (and clisp especially) more visibility. Lisp as emacs' extension language has gained acceptance. Maybe clisp as apache module it could do too. The other advantage to an apache module would be the api could be explained/implemented in way similar to the perl/C api's for apache so it could be described in a terminology that other mod_perl users where already familiar with. If you need to the invocations to communicate you get back to really implementing a server in lisp, with appropriate synchronisation and resource control. This is in a way immediately suggests using cl-http or writing your own, which implies re-writing a lot of lisp because of the uncertainties about licensing. Jon From joswig@lavielle.com Sun Sep 19 14:00:39 1999 Received: from vampire.lavielle.com (vampire.lavielle.com [194.64.21.10]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id OAA04637 for ; Sun, 19 Sep 1999 14:00:38 -0700 (PDT) Received: from [194.163.195.67] ([194.163.195.67]) by vampire.lavielle.com (8.9.3/8.9.3) with ESMTP id XAA16484; Sun, 19 Sep 1999 23:12:23 +0200 (MET DST) Mime-Version: 1.0 X-Sender: joswig@194.64.21.10 Message-Id: In-Reply-To: References: Date: Sun, 19 Sep 1999 23:12:08 +0200 To: clisp-list@seagull.cons.org, Multiple recipients of list From: Rainer Joswig Subject: Re: Making CLISP run faster Content-Type: text/plain; charset="us-ascii" At 9:37 Uhr -0700 19.09.1999, Eric Marsden wrote: > >>>>> "dv" == Dobes Vandermeer writes: > > dv> Allegro compiles to native code, but CLISP does not (AFAIK). > dv> Thus Allegro will inevitably be X times faster than CLISP. > dv> Dynamic compilers (like ACL) are not trivial to write in > dv> comparison to a regular script interpreter (like CLISP) so you > dv> are facing the old "Yu get what you paid for" problem. > >hey, you can use CMUCL, which is not only free of charge but public >domain, and it runs faster than ACL on most stuff. Hmm, has anybody done meaningful benchmarking lately? Rainer Joswig, "Lavielle" EDV Systemberatung GmbH & Co. KG, Lotharstrasse 2b, 22041 Hamburg, Germany, Tel: +49 40 658088, Fax: +49 40 65808-202, Email: joswig@lavielle.com , WWW: http://www.lavielle.de/ From joswig@lavielle.com Sun Sep 19 14:23:59 1999 Received: from vampire.lavielle.com (vampire.lavielle.com [194.64.21.10]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id OAA05223 for ; Sun, 19 Sep 1999 14:23:54 -0700 (PDT) Received: from [194.163.195.67] ([194.163.195.67]) by vampire.lavielle.com (8.9.3/8.9.3) with ESMTP id XAA16886; Sun, 19 Sep 1999 23:35:38 +0200 (MET DST) Mime-Version: 1.0 X-Sender: joswig@194.64.21.10 Message-Id: In-Reply-To: <14306.31480.137464.137266@inanna.starseed.com> References: <14306.31480.137464.137266@inanna.starseed.com> Date: Sun, 19 Sep 1999 23:35:12 +0200 To: clisp-list@seagull.cons.org, Multiple recipients of list From: Rainer Joswig Subject: Re: code sharing (was: clisp as cgi script) Content-Type: text/plain; charset="us-ascii" At 10:16 Uhr -0700 17.09.1999, Erik Arneson wrote: >On 17 Sep 99, Joerg Hoehle wrote: > > In c.l.functional, somebody recently asked why e.g. Python was used over > > Haskell -- I believe code snippets is part of the answer. But I don't > > wish to go into the "working 90%" discussion. > >I gotta agree with this one. Being able to get your hands on some free >code is one of the things that makes learning a new language easy. >Especially for those of us who are forced by our occupation to spend so >much time working in another language. I don't have a lot of free time >during the week where I can sit down and try to puzzle out new languages >on my own, but if I can get ahold of some quick examples it's much >easier for me to start working on projects. > >A CPAN-like repository for Common Lisp code would be very cool and >probably get a ridiculous amount of use. I agree completely. There are a couple of things that need a breath of life: the www.lisp.org website, a tools archive, an application archive, a documentation site, the FAQ, ... (Fortunately, guys like Marting Cracauer are making web space available - for example the one for CLisp.) The ANSI CL meeting is early October in San Francisco. John Mallery (the author of CL-HTTP) is going to propose to develop a process to publish and review extensions to Common Lisp. We would like to move more quickly in some areas than what was possible in the past. This would also mean some site for sharing code and information about that code. If this process not possible with ANSI (which I'd expect) - we will find another way to make that happen. Since I'm trying to be at the ANSI CL meeting too, you can send me ideas and ammunition you have in this direction - just by private mail would be sufficient. I'd like to collect ideas you have, so that we all can move forward. Rainer Joswig Rainer Joswig, "Lavielle" EDV Systemberatung GmbH & Co. KG, Lotharstrasse 2b, 22041 Hamburg, Germany, Tel: +49 40 658088, Fax: +49 40 65808-202, Email: joswig@lavielle.com , WWW: http://www.lavielle.de/ From donc@ISI.EDU Sun Sep 19 15:04:49 1999 Received: from tnt.isi.edu (tnt.isi.edu [128.9.128.128]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id PAA05758 for ; Sun, 19 Sep 1999 15:04:49 -0700 (PDT) Received: from ISI.EDU (tnt.isi.edu [128.9.128.128]) by tnt.isi.edu (8.8.7/8.8.6) with ESMTP id PAA10362; Sun, 19 Sep 1999 15:16:20 -0700 (PDT) Message-Id: <199909192216.PAA10362@tnt.isi.edu> To: clisp-list@seagull.cons.org cc: Multiple recipients of list Subject: Re: clisp as cgi script In-reply-to: Your message of "Sun, 19 Sep 1999 09:45:20 PDT." Date: Sun, 19 Sep 1999 15:16:20 -0700 From: Don Cohen Franz has a simple web server on public ftp. I made a few improvements to it - security and robustness. Since there's so much interest I include the code below. It currently runs only in acl, but I expect it will be easy to fix for clisp. The socket stuff is almost the same. The only thing I worry about is the regexp stuff. The only other problem I had when I ran this was that hup's would kill the server. I got around that by running from inside a shell script that ignored hup: trap "echo got signal 1" 1 ==== test-form.html ==== Form Test

Enter a number in each area and submit to get the answer:

X =

==== cgi.lsp ==== ;; This is the "CGI method" associated with test-form.html ;; It should be loaded into lisp before trying to serve that page. (in-package :user) (defun multiply (args stream) (let ((number1 (read-from-string (cdr (first args)))) (number2 (read-from-string (cdr (second args))))) (format stream "HTTP/1.0 200 OK") (endline stream) (format stream "Content-type: text/html") (endline stream) (endline stream) (format stream " Answer

The answer is: ~s " (* number1 number2)) (force-output stream))) ==== webserver.lsp ==== ;; simple web server ;; Copyright Franz Inc., 1997 ;; Permission is granted to copy, modify, or use the code ;; in this file freely, provided the copyright notice is preserved. ;; *** modifications by donc marked with *** #| general directions: 1. Load this file (which in turn requires socket and regexp libraries). 2. Set *allowed-commands* to a list of symbols that are allowed to be FUNCALLed by the webserver. These can be in any package, but two symbols with the same name in different packages won't work. (On input only the function name is available, not the package.) 3. Set log-file to the name of a file if you want a log kept. (To customize the contents see calls to log- below.) 4. Set *server-root* to a pathname of a directory. The server will only retrieve files below that directory. 5. (start-server :port ...)) |# ;; This demonstration server works under these versions of Allegro CL: ;; ACLWin 3.0.1 Lite ;; ACLWin 3.0.2 Lite ;; ACLWin 3.0.2 Professional ;; ACL 4.3 for Unix (in-package :user) (eval-when (compile load eval) (require :socket #+aclpc "fsl\\socket.fsl") ; load the socket code (require :regexp #+aclpc "fsl\\regexp.fsl") ; load the regular expression matcher ) ;; All files should be in this directory and below (defparameter *server-root* (pathname #+aclpc "c:\\tmp\\" #-aclpc "/usr/tmp/web/")) (defvar *webserver-commands* nil) ;; set this to the list of commands that are allowed ;; *** changed all the format t 's below to log's (defvar log-file nil) ;; set this to a file name in order to log transactions to that file (defun log- (&rest args) (when log-file (with-open-file (log log-file :direction :output :if-does-not-exist :create :if-exists :append) (apply 'format log args)))) (defun print-current-time (&optional (stream *standard-output*)) (multiple-value-bind (second minute hour day month year) (get-decoded-time) (format stream "~@?" "~d/~d/~d ~2,'0d:~2,'0d:~2,'0d" month day year hour minute second))) (defun start-server (&key (port 8000)) ;; start the web server running on the given port. ;; Note that on unix, ports below 1024 can only be obtained by ;; programs running as root. ;; The default port number for web browsers is 80, to use any other ;; port number in a url you have to put that port number after the ;; machine name as in http://www.foo.com:8000/the/url/I/want ;; (let ((websocket (socket:make-socket :connect :passive :local-port port))) (unwind-protect (loop ;; It turns out that all the stream operations can and in ;; practice do generate errors. ;; The practical solution is to put an ignore-errors ;; at a pretty high level. (multiple-value-bind (ans err) ;; *** (ignore-errors (let ((connection (socket:accept-connection websocket))) (unwind-protect (do-command connection #'(lambda () (return-from start-server))) (close connection)))) (when err (log- "~%error : ~A" err)))) (close websocket)))) (defun do-command (stream exit-fcn) ;; Read the command from the web browser and execute it. ;; If the command indicates that the web server should go away, ;; then funcall the exit-fcn. (let ((command (read-line stream nil ""))) ;; got eof ?? *** (log- "~%Got command on ~s of ~s" stream command) ;; ;; A command from the browser is one line containing ;; two or three items separated by spaces. ;; The first item is the command (get, put, post) and the ;; second item is the url. ;; The third (and optional) item is the protocol. ;; The protocol determines how we must respond to the command. ;; If the protocol item is missing we assume http/0.9. If it is preset ;; then we only support http/1.0 ;; ;; For brevity, we use the new regular expression parser to break up the ;; command line into items, but this could also be done with ;; standard Common Lisp functions. ;; (multiple-value-bind (matched whole-match cmd url protocol) (match-regexp "^\\([^ ]+\\) +\\([^ ]+\\) *\\([a-zA-Z/0-9.]*\\)" command) (declare (ignore whole-match)) (if* matched then (if* (equalp cmd "GET") then (log- "~%at ~A get ~s with protocol ~s" (print-current-time nil) url protocol) (when (equal url "/quit") (funcall exit-fcn)) (send-file stream url protocol) elseif (equalp cmd "POST") then (log- "~%at ~A post ~s with protocol~s" (print-current-time nil) url protocol) (post-command url stream) else (send-failure stream (format nil "I can't do command ~s" cmd) protocol)) else (log- "~%command ~s is not in the right format" command))) (finish-output stream) ;; *** added - I don't know if it really matters ;; but I was getting clients thinking they had not seen complete files. )) (defun send-file (stream url protocol) ;; we've been given a 'get' command. We now must get the requested ;; item and send it to the web browser. ;; We're assuming that all items requested are html, gif, jpg, or jpeg. ;; We should check that '..' doesn't appear in a directory name ;; or a user could use that to navigate out of the *server-root* ;; directory and into any directory on the machine. (let ((file-location (merge-pathnames (pathname (subseq url 1)) *server-root*))) (if* (let ((probe (probe-file file-location))) (or (not probe) ;; *** test that we're under *server-root* (< (length (pathname-directory probe)) (length (pathname-directory *server-root*))) (loop for x in (pathname-directory probe) as y in (pathname-directory *server-root*) thereis (not (equal x y))) ;; *** also reject directories, since otherwise open errs (null (pathname-name probe)))) then (send-failure stream (format nil "url ~s doesn't exist" url) protocol) else (let ((binaryp nil) (type (pathname-type file-location))) (cond ((or (string-equal type "jpg") (string-equal type "jpeg")) (setq binaryp t type "image/jpeg")) ((string-equal type "gif") (setq binaryp t type "image/gif")) (t ;html? -- hope for the best (setq type "text/html"))) (when (equalp protocol "http/1.0") (format stream "HTTP/1.0 200 OK") (endline stream) (format stream "Content-type: ~a" type) (endline stream) (endline stream)) (with-open-file (f file-location) (loop as ch = (read-char f nil nil) while ch as i from 0 ;; debugging do ;;(write-char ch) ;; debugging (when (eq ch #\newline) (unless binaryp (write-char #\return stream))) (write-char ch stream) finally (log- "~%~A chars sent" i) ;; debugging ) ;;(sleep 1) ;; debugging ))))) (defun endline (stream) ;; most network protocols require that lines end with a ;; #\return character followed by a #\newline character (write-char #\return stream) (write-char #\linefeed stream)) (defun send-failure (stream message protocol) ;; something was wrong with the browser's request so send back a ;; message (when (equalp protocol "http/1.0") (format stream "HTTP/1.0 200 OK") (endline stream) (format stream "Content-type: text/plain") (endline stream) (endline stream)) (write-string message stream)) (defun post-command (url stream) ;; first we strip off the leading "\" from the url ;; then we look up the lisp function corresponding to the remaining string (let ((function ;; *** (read-from-string (subseq url 1 (length url))) ;; read-from-string is a really bad security hole ;; find-symbol would be better, but in order to allow ;; functions from different packages I prefer (loop for c in *allowed-commands* with name = (subseq url 1 (length url)) thereis (and (equal name (symbol-name c)) c)))) ;; parse through the header information until we get a blank line ;; which separates the data from the header (loop until (zerop (length (string-trim '(#\return) (read-line stream nil ""))))) ;*** ;; Now comes the form input. (let ((input (read-line stream nil ""))); *** ;; (log- "~%Input is ~s" input) (let ((args (parse-form-contents input))) (log- "~%Args are ~s" args) (if function ;; *** (funcall function args stream) (log- "~%~illegal function - ~A" url)))))) (defun parse-form-contents (contents) ;; input values come in the pairs name=value, delimited by & name is a ;; "name" specified in the HTML form value is the string input or ;; selection by the user on this form special cases like ? and & are ;; ignored in this parser. ;; return a list of dotted pairs (("name" . "value") ....) (loop with len = (length contents) with start = 0 for sep = (position #\& contents :start start) for end = (or sep len) for varend = (position #\= contents :start start) for sym = (subseq contents start varend) for val = (subseq contents (1+ varend) end) collect (cons sym (html-to-ascii val)) ;; *** until (null sep) do (setq start (1+ sep)))) ;; *** (defun html-to-ascii (string) ;; recover the real chars the user sent ;; translate + to space and %xx where xx is two hex digits ;; to that character in hex (let* ((chars (loop with pos = 0 while (< pos (length string)) collect (if (eql (char string pos) #\+) (progn (incf pos) #\space) (if (eql (char string pos) #\%) (prog1 (code-char (parse-integer string :start (+ pos 1) :end (+ pos 3) :radix 16)) (incf pos 3)) (prog1 (char string pos) (incf pos)))))) (ans (make-string (length chars)))) (loop for i from 0 as c in chars do (setf (char ans i) c)) ans)) From joswig@lavielle.com Sun Sep 19 15:13:39 1999 Received: from vampire.lavielle.com (vampire.lavielle.com [194.64.21.10]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id PAA05835 for ; Sun, 19 Sep 1999 15:13:37 -0700 (PDT) Received: from [194.163.195.67] ([194.163.195.67]) by vampire.lavielle.com (8.9.3/8.9.3) with ESMTP id AAA18003 for ; Mon, 20 Sep 1999 00:25:22 +0200 (MET DST) Mime-Version: 1.0 X-Sender: joswig@194.64.21.10 Message-Id: In-Reply-To: <14307.63491.220564.695670@eco.totient.co.uk> References: <14307.63491.220564.695670@eco.totient.co.uk> Date: Mon, 20 Sep 1999 00:24:32 +0200 To: clisp-list@seagull.cons.org From: Rainer Joswig Subject: Re: clisp as cgi script Content-Type: text/plain; charset="us-ascii" >Contributed lisp code would be great under a sufficiently open >license. CL-HTTP licensing is strange and as the latest survey shows at >http://www.netcraft.com is not used on many internet sites (15 last >count). There are more sites and a couple of very interesting applications. But part of the problem is CL-HTTP (which is big and it is big because it does a lot of things, like HTTP 1.1, being a real client and server, ...). But there is CL-HTTP and then there are which other Lisp-based web servers out there? I know of atleast two others which are mostly invisible. So CL-HTTP atleast is a prove of concept and many Lisp vendors had to update their Lisp systems to be able to support CL-HTTP. The more important part of the problem is: few Lisps are up to the level to implement a real web server (threads, locks, TCP/IP, GC, speed, etc. are the issues). And if they may be able to support a web server, they are costing *huge* amounts of money for development and often *huge* amounts of money for delivery. So, even if you have CL-HTTP (or whatever else webserver) and it *might* be perfect for the job - you'd have a delivery problem. > I think a clisp/apache solution would get more punters. It's **definitely** worth to be looked at. I'd expect it to be really popular. Rainer Joswig, "Lavielle" EDV Systemberatung GmbH & Co. KG, Lotharstrasse 2b, 22041 Hamburg, Germany, Tel: +49 40 658088, Fax: +49 40 65808-202, Email: joswig@lavielle.com , WWW: http://www.lavielle.de/ From haible@ilog.fr Mon Sep 20 03:16:54 1999 Received: from sceaux.ilog.fr (sceaux.ilog.fr [193.55.64.10]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id DAA14102 for ; Mon, 20 Sep 1999 03:16:53 -0700 (PDT) Received: from laposte.ilog.fr (laposte [172.17.1.6]) by sceaux.ilog.fr (8.9.3/8.9.3) with ESMTP id MAA08832 for ; Mon, 20 Sep 1999 12:27:49 +0200 (MET DST) Received: from jaures.ilog.fr ([172.17.4.4]) by laposte.ilog.fr (8.9.3/8.9.3) with ESMTP id MAA15243; Mon, 20 Sep 1999 12:28:41 +0200 (MET DST) From: Bruno Haible Received: (from haible@localhost) by jaures.ilog.fr (8.9.3/8.9.3) id MAA05280; Mon, 20 Sep 1999 12:28:39 +0200 (MET DST) Date: Mon, 20 Sep 1999 12:28:39 +0200 (MET DST) Message-Id: <199909201028.MAA05280@jaures.ilog.fr> To: clisp-list@seagull.cons.org Subject: Re: set-dispatch-macro-character error? (clisp-1999.05.15) In-Reply-To: <199909191417.KAA29115@bunny.gte.com> References: <199909191417.KAA29115@bunny.gte.com> Dorai Sitaram writes: > The following code used to work in previous releases of > CLISP. Now it doesn't. Oh yes. To work around it, you have to use the uppercase equivalent #\T and #\F. To fix it, in clisp/src/io.d, functions SET-DISPATCH-MACRO-CHARACTER and GET-DISPATCH-MACRO-CHARACTER, replace the expression char_code(STACK_0) with up_case(char_code(STACK_0)). Will be fixed in the next release. Thanks. Bruno From erik@inanna.starseed.com Mon Sep 20 08:23:59 1999 Received: from inanna.starseed.com (root@inanna.starseed.com [206.151.157.197]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id IAA17394 for ; Mon, 20 Sep 1999 08:23:59 -0700 (PDT) Received: (from erik@localhost) by inanna.starseed.com (8.9.3/8.9.3) id IAA11864; Mon, 20 Sep 1999 08:39:27 -0700 From: Erik Arneson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14310.21807.20665.25755@inanna.starseed.com> Date: Mon, 20 Sep 1999 08:39:27 -0700 (PDT) To: clisp-list@seagull.cons.org Subject: Re: clisp as cgi script In-Reply-To: References: X-Mailer: VM 6.75 under 21.2 (beta19) "Shinjuku" XEmacs Lucid X-Fnord: http://inanna.starseed.com/~erik/ On 19 Sep 99, Eric Marsden wrote: > >>>>> "jd" == Jon Dyte writes: > [clisp as an Apache module] > > I'm not convinced that this is the best way to go. The first obvious > problem is memory consumption: for a mildly busy site you need at least > 20 httpd processes, and even if parts of the CLISP image are > shareable, a lot of RAM is necessary (sure, it's cheap). I think Jon was comparing this mostly to mod_perl. Have you taken a look at that? It's one of the most amazing tools I've ever used when it comes to web development, and if it weren't for mod_perl I'd be going out of my way to really try and convince my coworkers to start using Lisp for most of our CGI. Not that they'd listen, but it'd be worth a shot! :) mod_perl does manage to get around a lot of those problems. Sure, the httpd processes each get up to around 6-8MB, but most of it is shared. And the speed increase is incredible. > Still, I'd give mod_clisp a fly if it existed ! Me too! I've been wondering why something like that didn't exist, and been wishing that I had the skill to write it. :) -- # Erik Arneson erik@starseed.com Webring Software Engineer # # Yahoo! Inc. PGP ID: 2048/84413E19 (541) 482-3000x114 # # "There's such a fine line between stupid and clever." Spinal Tap # From amoroso@mclink.it Mon Sep 20 11:28:36 1999 Received: from mail.ppp.net (mail.ppp.net [194.64.12.35]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id LAA19956 for ; Mon, 20 Sep 1999 11:28:34 -0700 (PDT) Received: from mail1.mclink.it (net128-007.mclink.it [195.110.128.7]) by mail.ppp.net (8.8.8/8.8.8) with ESMTP id UAA24347 for ; Mon, 20 Sep 1999 20:40:25 +0200 Received: from net145-062.mclink.it (net145-062.mclink.it [195.110.145.62]) by mail1.mclink.it (8.9.1/8.9.0) with SMTP id UAA24954 for ; Mon, 20 Sep 1999 20:36:49 +0200 (CEST) From: amoroso@mclink.it (Paolo Amoroso) To: clisp-list@seagull.cons.org Subject: Re: Making CLISP run faster Date: Mon, 20 Sep 1999 18:35:46 GMT Organization: Paolo Amoroso - Milan, ITALY Message-ID: <37e62ee1.945605@mail.mclink.it> References: In-Reply-To: X-Mailer: Forte Agent 1.5/32.451 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit On Sat, 18 Sep 1999 07:13:29 -0700 (PDT), you wrote: > optimize parts, but are there any recommended tools for profiling > which work well with CLISP? Hopefully tools that people actually > use.. Mark Kantrowitz's METERING utility supports CLISP. I don't know how popular is it. Paolo -- EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/ From erik@inanna.starseed.com Mon Sep 20 12:58:38 1999 Received: from inanna.starseed.com (root@inanna.starseed.com [206.151.157.197]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id MAA21511 for ; Mon, 20 Sep 1999 12:58:36 -0700 (PDT) Received: (from erik@localhost) by inanna.starseed.com (8.9.3/8.9.3) id NAA29038; Mon, 20 Sep 1999 13:14:00 -0700 From: Erik Arneson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14310.38280.23610.670782@inanna.starseed.com> Date: Mon, 20 Sep 1999 13:14:00 -0700 (PDT) To: clisp-list@seagull.cons.org Subject: Load path? X-Mailer: VM 6.75 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Fnord: http://inanna.starseed.com/~erik/ Howdy, Please excuse my ignorance, but is there a `load-path' variable similar to the one used in Emacs which allows me to specify custom directories for my lisp libraries? For example, I don't want to have to use (load "/some/incredibly/long/path/to/file") every time. I'd rather just do (load "file"). -- # Erik Arneson erik@starseed.com Webring Software Engineer # # Yahoo! Inc. PGP ID: 2048/84413E19 (541) 482-3000x114 # # "There's such a fine line between stupid and clever." Spinal Tap # From russell@coulee.tdb.com Mon Sep 20 13:04:03 1999 Received: from coulee.tdb.com (root@idslppp241.ptld.uswest.net [63.224.252.241]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id NAA21777 for ; Mon, 20 Sep 1999 13:04:03 -0700 (PDT) Received: by coulee.tdb.com via sendmail from stdin id (Debian Smail3.2.0.101) for clisp-list@seagull.cons.org; Mon, 20 Sep 1999 13:15:51 -0700 (PDT) To: clisp-list@seagull.cons.org Subject: Re: Load path? References: <14310.38280.23610.670782@inanna.starseed.com> From: Russell Senior Date: 20 Sep 1999 13:15:50 -0700 In-Reply-To: Erik Arneson's message of "Mon, 20 Sep 1999 12:59:06 -0700 (PDT)" Message-ID: <869061gwzt.fsf@coulee.tdb.com> Lines: 17 X-Mailer: Gnus v5.6.39/Emacs 20.4 >>>>> "Erik" == Erik Arneson writes: Erik> Howdy, Please excuse my ignorance, but is there a `load-path' Erik> variable similar to the one used in Emacs which allows me to Erik> specify custom directories for my lisp libraries? Erik> For example, I don't want to have to use (load Erik> "/some/incredibly/long/path/to/file") every time. I'd rather Erik> just do (load "file"). *load-paths* -- Russell Senior ``The two chiefs turned to each other. seniorr@teleport.com Bellison uncorked a flood of horrible profanity, which, translated meant, `This is extremely unusual.' '' From Klaus.Schilling@home.ivm.de Mon Sep 20 18:26:47 1999 Received: from mail.ivm.net (mail.ivm.net [62.204.1.4]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id SAA26444 for ; Mon, 20 Sep 1999 18:26:46 -0700 (PDT) Received: from debian (port49.bonn.ivm.de [195.247.226.49]) by mail.ivm.net (8.8.8/8.8.8) with ESMTP id DAA13627 for ; Tue, 21 Sep 1999 03:38:26 +0200 X-To: Received: by debian via sendmail from stdin id (Debian Smail3.2.0.102) for clisp-list@clisp.cons.org; Tue, 21 Sep 1999 10:53:15 +0200 (CEST) Message-Id: Date: Tue, 21 Sep 1999 10:53:15 +0200 (CEST) From: Klaus Schilling To: clisp-list@clisp.cons.org Subject: widgets sets for screen package Reply-to: Klaus.Schilling@home.ivm.de Is it possible to provide widget sets , like radiolists, checkboxes, buttons, input lines etc. for the termcap-based screen package that comes with clisp? The emacs widget package by Abrahamsen, which is used by the emacs webbrowser w3, might be a good example of what to do. Klaus Schilling From marcoxa@parades.rm.cnr.it Tue Sep 21 06:51:37 1999 Received: from leonardo (leonardo.parades.rm.cnr.it [150.146.37.11]) by seagull.cdrom.com (8.8.8/8.7.3) with SMTP id GAA04117 for ; Tue, 21 Sep 1999 06:51:35 -0700 (PDT) Received: from copernico.parades.rm.cnr.it by leonardo (SMI-8.6/SMI-SVR4) id QAA00450; Tue, 21 Sep 1999 16:04:54 +0200 Received: by copernico.parades.rm.cnr.it (SMI-8.6/SMI-SVR4) id QAA02400; Tue, 21 Sep 1999 16:04:53 +0200 Date: Tue, 21 Sep 1999 16:04:53 +0200 Message-Id: <199909211404.QAA02400@copernico.parades.rm.cnr.it> From: Marco Antoniotti To: clisp-list@seagull.cons.org Subject: Re: Load path? Reply-to: marcoxa@parades.rm.cnr.it > Topic No. 4 > > Date: 20 Sep 1999 13:15:50 -0700 > From: Russell Senior > To: clisp-list@seagull.cons.org > Subject: Re: Load path? > Message-ID: <869061gwzt.fsf@coulee.tdb.com> > > >>>>> "Erik" == Erik Arneson writes: > > Erik> Howdy, Please excuse my ignorance, but is there a `load-path' > Erik> variable similar to the one used in Emacs which allows me to > Erik> specify custom directories for my lisp libraries? > > Erik> For example, I don't want to have to use (load > Erik> "/some/incredibly/long/path/to/file") every time. I'd rather > Erik> just do (load "file"). > > *load-paths* Is it this the variable containing the logical pathname translations or the place where to load them? Cheers -- Marco Antoniotti =========================================== PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26 http://www.parades.rm.cnr.it/~marcoxa From hoehle@mmkmail.gmd.de Tue Sep 21 08:33:27 1999 Received: from mail.gmd.de (mail.gmd.de [129.26.8.90]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id IAA05830 for ; Tue, 21 Sep 1999 08:33:25 -0700 (PDT) Received: from zeus.gmd.de (zeus.gmd.de [129.26.165.1]) by mail.gmd.de (8.8.8/8.8.8) with ESMTP id RAA05376 for ; Tue, 21 Sep 1999 17:45:15 +0200 (MET DST) Received: from localhost (hoehle@localhost) by zeus.gmd.de (8.9.1/8.9.3) with SMTP id RAA28351 for ; Tue, 21 Sep 1999 17:45:14 +0200 (MET DST) X-Authentication-Warning: zeus.gmd.de: hoehle owned process doing -bs Date: Tue, 21 Sep 1999 17:45:14 +0200 (MET DST) From: Joerg Hoehle X-Sender: hoehle@zeus To: clisp-list@seagull.cons.org Subject: Re: Making CLISP run faster In-Reply-To: <37e62ee1.945605@mail.mclink.it> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 20 Sep 1999, Paolo Amoroso wrote: > Mark Kantrowitz's METERING utility supports CLISP. I don't know how popular > is it. Well, at least I used it and it gave satisfying results (except for recursion, as documented). But I believe commercial CL implementations have better tools. My experience with profiling is that while the usual advice is too optimize the algorithms first, then the details, I found no solution with tiny functions which got called extremely often and thus cost time as well. Open coding was not a solution, as it would only distribute the cost and I still found no way how to get rid of the many calls. BTW, I think a proper OO approach leads to many tiny functions. Regards, Jo"rg Ho"hle. Joerg.Hoehle@gmd.de http://fit.gmd.de/~hoehle/amiga.html From hoehle@mmkmail.gmd.de Tue Sep 21 08:46:51 1999 Received: from mail.gmd.de (mail.gmd.de [129.26.8.90]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id IAA06248 for ; Tue, 21 Sep 1999 08:46:45 -0700 (PDT) Received: from zeus.gmd.de (zeus.gmd.de [129.26.165.1]) by mail.gmd.de (8.8.8/8.8.8) with ESMTP id RAA07395 for ; Tue, 21 Sep 1999 17:58:34 +0200 (MET DST) Received: from localhost (hoehle@localhost) by zeus.gmd.de (8.9.1/8.9.3) with SMTP id RAA28398 for ; Tue, 21 Sep 1999 17:58:33 +0200 (MET DST) X-Authentication-Warning: zeus.gmd.de: hoehle owned process doing -bs Date: Tue, 21 Sep 1999 17:58:33 +0200 (MET DST) From: Joerg Hoehle X-Sender: hoehle@zeus To: clisp-list@seagull.cons.org Subject: Re: Making CLISP run faster In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sat, 18 Sep 1999, Stig Erik Sandoe wrote: > be more to ACL's taste, but still I find a 3:1 ratio pretty gross. I find it good and would have expected a native-code to byte-code at 5:1 instead. 2. type declarations are ignored. It doesn't make sense in CLISP's model. E.g., CLISP does the dispatch for +, = etc. internally (in C), while CMUCL and ACL would use type information to call the appropriate + or = method directly (or open code it immediately). > 3) Has anything been written on performance in CLISP which is None that I know of. The only thing I can remember is a criticism by some in c.l.lisp recently that CLISP's built-in (written in C) functions being by nature several times faster than any you could write in Lisp which would suffer the overhead of byte-code interpretation doesn't encourage programmers who wish to optimize for CLISP to use abstractions. I.e. you write much faster code using built-in CL functions than redefining your own accessors in Lisp. Also, the compiler can inline some well-known constructs like (mapcar #'(lambda ...)) which it wouldn't with your own mapping functions. We're entering the topic of compiler technology and optimization here - quite difficult. Regards, Jo"rg Ho"hle. Joerg.Hoehle@gmd.de http://fit.gmd.de/~hoehle/amiga.html From hoehle@mmkmail.gmd.de Tue Sep 21 08:52:17 1999 Received: from mail.gmd.de (mail.gmd.de [129.26.8.90]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id IAA06562 for ; Tue, 21 Sep 1999 08:52:06 -0700 (PDT) Received: from zeus.gmd.de (zeus.gmd.de [129.26.165.1]) by mail.gmd.de (8.8.8/8.8.8) with ESMTP id SAA06673 for ; Tue, 21 Sep 1999 18:03:40 +0200 (MET DST) Received: from localhost (hoehle@localhost) by zeus.gmd.de (8.9.1/8.9.3) with SMTP id SAA28496 for ; Tue, 21 Sep 1999 18:03:40 +0200 (MET DST) X-Authentication-Warning: zeus.gmd.de: hoehle owned process doing -bs Date: Tue, 21 Sep 1999 18:03:40 +0200 (MET DST) From: Joerg Hoehle X-Sender: hoehle@zeus To: clisp-list@seagull.cons.org Subject: Re: clisp as cgi script In-Reply-To: <14307.63491.220564.695670@eco.totient.co.uk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sat, 18 Sep 1999, Jon Dyte wrote: > building clisp as shared library and then using that to make an apache > lisp module. I think this is possible but I don't know enough of the clisp I think it's hard and would advise other communication methods. > As it is these threads have shown it's relatively easy to get clisp > serving pages via cgi, but some work is needed on a framework around > it plus integration into other webservers. I read about the Squid proxy & cache that it supports communicating with single-threaded servers like one you'd build with CLISP without threads and offers the benefit of separating slow reads by clients from the single threaded server which can talk full speed with Squid and then serve the next request. So, depending on your needs, this may be what you need. (probably UNIX only). Regards, Jo"rg Ho"hle. Joerg.Hoehle@gmd.de http://fit.gmd.de/~hoehle/amiga.html From johann@ai.univie.ac.at Tue Sep 21 09:40:39 1999 Received: from toledo.ai.univie.ac.at (toledo.ai.univie.ac.at [192.76.244.166]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id JAA07455 for ; Tue, 21 Sep 1999 09:40:35 -0700 (PDT) Received: from ai.univie.ac.at (bluebox.ai.univie.ac.at [192.76.244.189]) by toledo.ai.univie.ac.at (8.9.3/8.9.3) with ESMTP id SAA17342 for ; Tue, 21 Sep 1999 18:52:26 +0200 (MET DST) Sender: johann@mail4.ai.univie.ac.at Message-ID: <37E7B7C6.7E15EA1D@ai.univie.ac.at> Date: Tue, 21 Sep 1999 18:52:22 +0200 From: Johann Petrak Organization: OFAI X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: Spanish, es, German, de, en, Japanese, ja MIME-Version: 1.0 To: clisp-list@clisp.cons.org Subject: Binaries for Solaris 5.6, sparc (ELF) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Is there anywhere a binary distribution for Solaris 5.5 or 5.6 on a Sparc architecture with ELF object format? The binary distribution in clisp.cons.org just seems to be linked to sunos non-ELF binaries. I dont seem to be able to use that one with my Solaris machine and the gcc/egcs compiler (egcs-2.91.60 19981201 (egcs-1.1.1 release)) I tried to compile the 07-22 sources with that compiler, but it didnt work either. Any known pitfalls/solutions here? Many thanks, Johann Petrak -- Johann Petrak Email: johann@ai.univie.ac.at Austrian Research Institute for AI Phone: +43-1-533-61-12/13 Schottengasse 3 Fax: +43-1-532-61-12/77 A-1010 Vienna, AUSTRIA http://www.ai.univie.ac.at/~johann From haible@ilog.fr Tue Sep 21 10:40:09 1999 Received: from sceaux.ilog.fr (sceaux.ilog.fr [193.55.64.10]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id KAA08621 for ; Tue, 21 Sep 1999 10:40:03 -0700 (PDT) Received: from laposte.ilog.fr (laposte [172.17.1.6]) by sceaux.ilog.fr (8.9.3/8.9.3) with ESMTP id TAA27556 for ; Tue, 21 Sep 1999 19:51:09 +0200 (MET DST) Received: from jaures.ilog.fr ([172.17.4.4]) by laposte.ilog.fr (8.9.3/8.9.3) with ESMTP id TAA11615; Tue, 21 Sep 1999 19:52:00 +0200 (MET DST) From: Bruno Haible Received: (from haible@localhost) by jaures.ilog.fr (8.9.3/8.9.3) id TAA15507; Tue, 21 Sep 1999 19:51:59 +0200 (MET DST) Date: Tue, 21 Sep 1999 19:51:59 +0200 (MET DST) Message-Id: <199909211751.TAA15507@jaures.ilog.fr> To: clisp-list@seagull.cons.org Subject: Re: Binaries for Solaris 5.6, sparc (ELF) In-Reply-To: <37E7B7C6.7E15EA1D@ai.univie.ac.at> References: <37E7B7C6.7E15EA1D@ai.univie.ac.at> Johann Petrak asks: > Is there anywhere a binary distribution for Solaris 5.5 or 5.6 on a > Sparc architecture with ELF object format? Sure, for SunOS 5.5 in the binaries/sun4-sunos55/ directory. The binary there is only for UltraSparc. > The binary distribution in clisp.cons.org just seems to be linked to > sunos non-ELF binaries. Ouch, yes, in the binaries/sun4-sunos551/ directory I made a wrong symbolic link. It is now corrected and points to the sun4-sunos54/ directory. > I dont seem to be able to use that one with my Solaris machine and > the gcc/egcs compiler (egcs-2.91.60 19981201 (egcs-1.1.1 release)) > > I tried to compile the 07-22 sources with that compiler, but it > didnt work either. What problems did you encounter? Bruno From yoda@pixie.isr.ist.utl.pt Tue Sep 21 10:53:47 1999 Received: from pixie.isr.ist.utl.pt (root@pixie.isr.ist.utl.pt [193.136.138.97]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id KAA08912 for ; Tue, 21 Sep 1999 10:53:15 -0700 (PDT) Received: (from yoda@localhost) by pixie.isr.ist.utl.pt (8.8.8/8.8.8) id TAA12809; Tue, 21 Sep 1999 19:08:12 GMT To: clisp-list@seagull.cons.org Subject: Re: Making CLISP run faster Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Rodrigo Ventura Date: 21 Sep 1999 19:08:11 +0000 In-Reply-To: clisp-list@seagull.cons.org's message of "Tue, 21 Sep 1999 09:12:00 -0700 (PDT)" Message-ID: Lines: 24 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" I've read somewhere about the benefits of having byte-code compilation instead of native core. But has anyone thought about some possible solutions to acomplish native code performance without changing CLISP architecture? namely: 1. JIT (just-in-time) compilation of selected fragments, transparently to the user) to native code; 2. Second-order compiler, that compiles byte-code lambda's into native code. Is any of these solutions feasible? If not, why? Cheers, -- *** Rodrigo Martins de Matos Ventura *** Teaching Assistant and MSc. Student at ISR: *** Instituto de Sistemas e Robotica, Polo de Lisboa *** Instituto Superior Tecnico, Lisboa, Portugal *** PGP Public Key available on my homepage: *** http://www.isr.ist.utl.pt/~yoda *** Key fingerprint = 0C 0A 25 58 46 CF 14 99 CF 9C AF 9E 10 02 BB 2A From johann@ai.univie.ac.at Wed Sep 22 07:34:48 1999 Received: from toledo.ai.univie.ac.at (toledo.ai.univie.ac.at [192.76.244.166]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id HAA21919 for ; Wed, 22 Sep 1999 07:34:46 -0700 (PDT) Received: from ai.univie.ac.at (bluebox.ai.univie.ac.at [192.76.244.189]) by toledo.ai.univie.ac.at (8.9.3/8.9.3) with ESMTP id QAA16075 for ; Wed, 22 Sep 1999 16:46:45 +0200 (MET DST) Sender: johann@mail4.ai.univie.ac.at Message-ID: <37E8EBCF.CA6DEB56@ai.univie.ac.at> Date: Wed, 22 Sep 1999 16:46:39 +0200 From: Johann Petrak Organization: OFAI X-Mailer: Mozilla 4.5 [en] (X11; I; SunOS 5.6 sun4u) X-Accept-Language: Spanish, es, German, de, en, Japanese, ja MIME-Version: 1.0 To: clisp-list@seagull.cons.org Subject: Re: Binaries for Solaris 5.6, sparc (ELF) References: <199909211751.TAA15507@jaures.ilog.fr> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bruno Haible wrote: > > Johann Petrak asks: > > Is there anywhere a binary distribution for Solaris 5.5 or 5.6 on a > > Sparc architecture with ELF object format? > > Sure, for SunOS 5.5 in the binaries/sun4-sunos55/ directory. The binary > there is only for UltraSparc. > > > The binary distribution in clisp.cons.org just seems to be linked to > > sunos non-ELF binaries. > > Ouch, yes, in the binaries/sun4-sunos551/ directory I made a wrong > symbolic link. It is now corrected and points to the sun4-sunos54/ > directory. > Thanks a lot. It did work fine! I just noticed that the source of the driver program clisp.c isn't included in this tar (as it is in the sunos4 binary tar) - just the binary clisp program. A reason why one could want this is maybe to change the source to use the "full" instead of the "base" version of lisp.run To do this I just copied the source from the Sunos4 distribution, changed the "base" to "full" definition and removed the declaration for perror. > > I dont seem to be able to use that one with my Solaris machine and > > the gcc/egcs compiler (egcs-2.91.60 19981201 (egcs-1.1.1 release)) > > > > I tried to compile the 07-22 sources with that compiler, but it > > didnt work either. > > What problems did you encounter? > I did: In the clisp-1999-07-22 directory: ./configure BUILD-solaris cd BUILD-solaris ./makemake --with-readline --with-dynamic-ffi --with-dynamic-modules --with-export-syscalls --with-module=wildcard --with-module=regexp > Makefile gnumake ... after quite a while I get: ... test -d full || CLISP_LINKKIT=. ./clisp-link add-module-sets base full wildcard regexp || (rm -f -r full ; exit 1) gcc -O -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -fomit-frame-pointer -Wno-sign-compare -O2 -fno-schedule-insns -DUNIX_BINARY_DISTRIB -DUNICODE -DDYNAMIC_FFI -DDYNAMIC_MODULES -fPIC -I/bluebox/johann_tmp/source/clisp-1999-07-22/BUILD-solaris -c modules.c In file included from modules.d:11: /bluebox/johann_tmp/source/clisp-1999-07-22/BUILD-solaris/clisp.h:2750: warning: call-clobbered register used for global register variable gcc -O -W -Wswitch -Wcomment -Wpointer-arith -Wimplicit -Wreturn-type -fomit-frame-pointer -Wno-sign-compare -O2 -fno-schedule-insns -DUNIX_BINARY_DISTRIB -DUNICODE -DDYNAMIC_FFI -DDYNAMIC_MODULES -fPIC -x none -Wl,-export-dynamic modules.o regexp.o regexi.o regex.o wildcard.o fnmatch.o lisp.a libsigsegv.a libintl.a libreadline.a libavcall.a libcallback.a -lnsl -lsocket -ltermcap -ldl -o lisp.run ld: fatal: entry point symbol `xport-dynamic' is undefined collect2: ld returned 1 exit status gnumake: *** [full] Error 1 Exit 2 Oddly, after I did 'gnumake clean' and 'gnumake' another time (this time I added -v to the gcc command) everything completed fine. Maybe its just a problem with our configuration ... Cheers, Johann From hoehle@mmkmail.gmd.de Thu Sep 23 02:25:34 1999 Received: from mail.gmd.de (mail.gmd.de [129.26.8.90]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id CAA04415 for ; Thu, 23 Sep 1999 02:24:54 -0700 (PDT) Received: from zeus.gmd.de (zeus.gmd.de [129.26.165.1]) by mail.gmd.de (8.8.8/8.8.8) with ESMTP id LAA01996 for ; Thu, 23 Sep 1999 11:36:53 +0200 (MET DST) Received: from localhost (hoehle@localhost) by zeus.gmd.de (8.9.1/8.9.3) with SMTP id LAA17987 for ; Thu, 23 Sep 1999 11:36:53 +0200 (MET DST) X-Authentication-Warning: zeus.gmd.de: hoehle owned process doing -bs Date: Thu, 23 Sep 1999 11:36:53 +0200 (MET DST) From: Joerg Hoehle X-Sender: hoehle@zeus To: clisp-list@seagull.cons.org Subject: Re: clisp as cgi script In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Mon, 20 Sep 1999, Rainer Joswig wrote: > > I think a clisp/apache solution would get more punters. > > It's **definitely** worth to be looked at. I'd expect it > to be really popular. Rainer, could you please explain what you expect from that except hype? "Apache is (popular thus) good, so this site using Apache + some strange stuff is good as well"? What's the benefit of Apache over a caching proxy like khttp (cited by Erik Marsden) or squid? One of the ideas of UNIX once was to have many small tools that work well together. I feel comfortable with the idea of having a dedicated tool handle HTTP (esp. 1.1) and leaving to some kind of dynamic DB server written in Lisp the job to serve contents -- given some good way for these two to communicate. As far as security is concerned, one could debate whether a SSL connection would stop at the proxy or must be passed down to the DB in Lisp. Or what the real advantages of keeping a TCP session alive are (together with more session state). OTOH, we nowadays see lots of monolithic systems which apparently must be able to do all themselves. I distinguish some huge communication failure here -- or possibly the unability to handle complexity. Regards, Jo"rg Ho"hle. Joerg.Hoehle@gmd.de http://fit.gmd.de/~hoehle/amiga.html From haible@ilog.fr Thu Sep 23 03:30:15 1999 Received: from sceaux.ilog.fr (sceaux.ilog.fr [193.55.64.10]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id DAA05158 for ; Thu, 23 Sep 1999 03:30:13 -0700 (PDT) Received: from laposte.ilog.fr (laposte [172.17.1.6]) by sceaux.ilog.fr (8.9.3/8.9.3) with ESMTP id MAA04995 for ; Thu, 23 Sep 1999 12:41:30 +0200 (MET DST) Received: from jaures.ilog.fr ([172.17.4.92]) by laposte.ilog.fr (8.9.3/8.9.3) with ESMTP id MAA18906; Thu, 23 Sep 1999 12:42:21 +0200 (MET DST) From: Bruno Haible Received: (from haible@localhost) by jaures.ilog.fr (8.9.3/8.9.3) id MAA26835; Thu, 23 Sep 1999 12:42:19 +0200 (MET DST) Date: Thu, 23 Sep 1999 12:42:19 +0200 (MET DST) Message-Id: <199909231042.MAA26835@jaures.ilog.fr> To: clisp-list@seagull.cons.org Subject: Re: Binaries for Solaris 5.6, sparc (ELF) In-Reply-To: <37E8EBCF.CA6DEB56@ai.univie.ac.at> References: <37E8EBCF.CA6DEB56@ai.univie.ac.at> Johann Petrak writes: > I just noticed that the source of the driver program clisp.c isn't > included in this tar (as it is in the sunos4 binary tar) - just > the binary clisp program. Yes, this is because Solaris ships without a C compiler, therefore the clisp.c source would be useless to a "normal" Solaris user. > A reason why one could want this is maybe to change the source to > use the "full" instead of the "base" version of lisp.run You can edit the `clisp' binary using emacs. Fortunately "base" and "full" each consist of 4 bytes, so it fits nicely :-) > ld: fatal: entry point symbol `xport-dynamic' is undefined > Oddly, after I did 'gnumake clean' and 'gnumake' another time > (this time I added -v to the gcc command) everything completed fine. It looks like you had GNU ld in your $PATH when you ran "makemake" but not later when you run "gnumake" for the first time. Bruno From jon@totient.demon.co.uk Thu Sep 23 15:49:52 1999 Received: from totient.demon.co.uk (jon@totient.demon.co.uk [158.152.119.202]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id PAA13471 for ; Thu, 23 Sep 1999 15:49:50 -0700 (PDT) Received: (from jon@localhost) by totient.demon.co.uk (8.8.7/8.8.7) id XAA02118; Thu, 23 Sep 1999 23:53:01 +0100 From: Jon Dyte MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 23 Sep 1999 23:53:01 +0100 (BST) To: clisp-list@seagull.cons.org Subject: Re: clisp as cgi script Message-ID: <14314.42691.61797.246562@eco.totient.co.uk> I only suggested apache/clisp as a possibility because of the availability of perl/python modules for apache. Lisp has appalling visibility at the moment, though vendors might report differently. There are no recent books to buy (execept Grahams) and I was really suggesting it might get people using clisp or something and maybe even oreilly would get interested by placing it in the context of something new (ie internet etc etc). I really have no idea whether it would be popular or not. Nearly every one has killed this idea dead saying do it another way with sockets etc etc. I havent followed the discussions that lead to mod_perl or PyApache but if the response had been this pessimistic I wonder if they'd have got done at all. Incidently I had a go at building a shared library from Allegro lisp such that this would be callable from C as needed for apache. This did illustrate a few potential problems. Unfortunately because I had also loaded other shared object files into the lisp allegro will not work using (dumplisp .....). As the trial edition has disabled this feature when shared objects are loaded into an image, I suspect due to licensing issues. I also had a go at building a clisp library, mainly by removing main(). This appeared to work, but what is really needed is a global lisp system initialisation call and then a seperate call to read/eval. The current implementation of main seems to initialise things on the stack and then call read-eval-print (which never returns) so obviously those stack based objects would have to moved somewhere global in a library. I'll let you know if I get any further. Jon From gat@jpl.nasa.gov Thu Sep 23 19:05:39 1999 Received: from mail3.jpl.nasa.gov (eis-msg-024.jpl.nasa.gov [137.78.160.181]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id TAA15302 for ; Thu, 23 Sep 1999 19:05:38 -0700 (PDT) Received: from binkley ([128.149.8.194]) by mail3.jpl.nasa.gov (Netscape Messaging Server 3.6) with SMTP id AAABB8 for ; Thu, 23 Sep 1999 19:17:50 -0700 Date: Thu, 23 Sep 1999 19:17:49 -0700 (PDT) From: Erann Gat X-Sender: gat@binkley To: clisp-list@clisp.cons.org Subject: HTTP server available Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII (Sorry if this is a repeat.) My mini http server is now available at: http://www-aig.jpl.nasa.gov/public/home/gat/ftp/http.lsp. It comes with rudimentary documentation and a working example. It has been tested only under the most recent version of CLisp (1999-07-22) and probably will not work with earlier versions. Feedback welcome. Erann Gat gat@jpl.nasa.gov From rmz@dunk.follo.net Fri Sep 24 00:49:27 1999 Received: from dunk.follo.net (dunk.follo.net [195.204.143.225]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id AAA18799 for ; Fri, 24 Sep 1999 00:49:26 -0700 (PDT) Received: (from rmz@localhost) by dunk.follo.net (8.9.3/8.9.3) id KAA39672 for clisp-list@seagull.cons.org; Fri, 24 Sep 1999 10:01:29 +0200 (CEST) (envelope-from rmz) Date: Fri, 24 Sep 1999 10:01:29 +0200 From: =?iso-8859-1?Q?Bj=F8rn_Remseth?= To: clisp-list@seagull.cons.org Subject: Re: clisp as cgi script Message-ID: <19990924100129.B38113@dunk.follo.net> References: <14314.42691.61797.246562@eco.totient.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: <14314.42691.61797.246562@eco.totient.co.uk>; from Jon Dyte on Fri, Sep 24, 1999 at 12:01:31AM -0700 Organization: Yes Interactive AS On Fri, Sep 24, 1999 at 12:01:31AM -0700, Jon Dyte wrote: > > I only suggested apache/clisp as a possibility because of the > availability of perl/python modules for apache. Lisp has appalling > visibility at the moment, though vendors might report differently. > There are no recent books to buy (execept Grahams) and I was really > suggesting it might get people using clisp or something and maybe > even oreilly would get interested by placing it in the context of > something new (ie internet etc etc). I really have no idea whether it > would be popular or not. I believe it's a good idea. Serving static pages, integrating legacy-services on the same server, handling tricky client-HTML stacks and all kinds of strange authentication schemes. All of these things can be handled by Apache without cluttering up the Common Lisp code. These are -exactly- the same advantages offered to mod_perl - programmers using Apache as a delivery plattform. They can concentrate on adding value, not writing and maintaining low level HTTP code in Perl (which is perfectly possible, by the way, it just takes -way- to much time ;) (Rmz) From prabakar@wipinfo.soft.net Fri Sep 24 04:23:06 1999 Received: from agni.wipinfo.soft.net (agni.wipinfo.soft.net [164.164.6.20]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id EAA20730 for ; Fri, 24 Sep 1999 04:22:57 -0700 (PDT) Received: from vayu.wipinfo.soft.net (vayu [192.168.200.170]) by agni.wipinfo.soft.net (8.9.3/8.9.3) with ESMTP id NAA21063 for ; Fri, 24 Sep 1999 13:52:32 -0500 (GMT) Received: from alcatel-gw.wipinfo.soft.net (root@alcatel-gw.wipinfo.soft.net [192.168.220.200]) by vayu.wipinfo.soft.net (8.9.3/8.9.3) with ESMTP id NAA29854 for ; Fri, 24 Sep 1999 13:51:02 -0500 (GMT) Received: from wipinfo.soft.net (prabakar@[192.168.221.93]) by alcatel-gw.wipinfo.soft.net (8.7.5/8.9.3) with ESMTP id NAA20008 for ; Fri, 24 Sep 1999 13:54:13 +0530 Sender: prabakar@wipinfo.soft.net Message-ID: <37EB58ED.195BEC5@wipinfo.soft.net> Date: Fri, 24 Sep 1999 16:26:45 +0530 From: Prabakar Venkataraman Organization: Wipro X-Mailer: Mozilla 4.03 [en] (X11; I; Linux 2.0.36 i686) MIME-Version: 1.0 To: clisp-list@seagull.cons.org Subject: Parellel initialization Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit *, Can someone tell me how the parallel initialization constructs in LISP are implemented ? I am referring to (PSETQ ...) (LET ...) etc. Is there an inherent assumption about underlying processor capabilities in the design of the Language ? -Prabu. From haible@ilog.fr Fri Sep 24 05:17:56 1999 Received: from sceaux.ilog.fr (sceaux.ilog.fr [193.55.64.10]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id FAA21357 for ; Fri, 24 Sep 1999 05:17:54 -0700 (PDT) Received: from laposte.ilog.fr (laposte [172.17.1.6]) by sceaux.ilog.fr (8.9.3/8.9.3) with ESMTP id OAA23511 for ; Fri, 24 Sep 1999 14:29:18 +0200 (MET DST) Received: from jaures.ilog.fr ([172.17.4.92]) by laposte.ilog.fr (8.9.3/8.9.3) with ESMTP id OAA24144; Fri, 24 Sep 1999 14:30:10 +0200 (MET DST) From: Bruno Haible Received: (from haible@localhost) by jaures.ilog.fr (8.9.3/8.9.3) id OAA20996; Fri, 24 Sep 1999 14:30:08 +0200 (MET DST) Date: Fri, 24 Sep 1999 14:30:08 +0200 (MET DST) Message-Id: <199909241230.OAA20996@jaures.ilog.fr> To: clisp-list@seagull.cons.org Subject: Re: Parellel initialization In-Reply-To: <37EB58ED.195BEC5@wipinfo.soft.net> References: <37EB58ED.195BEC5@wipinfo.soft.net> Prabakar Venkataraman writes: > Can someone tell me how the parallel > initialization constructs in LISP are > implemented ? > > I am referring to (PSETQ ...) (LET ...) Note that only the assignment (in the case of PSETQ) or bindings (in the case of LET) are performed "in parallel", i.e. all at once. The subforms (values to assign or bind) are evaluated sequentially, in left-to-right order. These constructs are implemented by saving the values in intermediate locations. To understand how PSETQ works, try macroexpansion, for example (macroexpand-1 '(psetq a (+ a b 1) b (+ a b 2))) > Is there an inherent assumption about > underlying processor capabilities in > the design of the Language ? No. Bruno From tkunze@ccrma.stanford.edu Fri Sep 24 09:27:22 1999 Received: from bart.cmgnet.com (root@bart.cmgnet.com [205.166.5.5]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id JAA24204 for ; Fri, 24 Sep 1999 09:27:21 -0700 (PDT) Received: from ccrma.stanford.edu (modem1400.spectrum2.com [216.32.67.143]) by bart.cmgnet.com (8.8.5/8.8.5) with ESMTP id MAA13987 for ; Fri, 24 Sep 1999 12:38:50 -0400 Sender: tkunze@bart.cmgnet.com Message-ID: <37EBA931.8420B277@ccrma.stanford.edu> Date: Fri, 24 Sep 1999 12:39:13 -0400 From: Tobias Kunze X-Mailer: Mozilla 4.61C-SGI [en] (X11; U; IRIX 6.5 IP22) X-Accept-Language: en MIME-Version: 1.0 To: clisp-list@seagull.cons.org Subject: Re: Parellel initialization References: <37EB58ED.195BEC5@wipinfo.soft.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Prabakar Venkataraman wrote: > > *, > > Can someone tell me how the parallel > initialization constructs in LISP are > implemented ? > > I am referring to (PSETQ ...) (LET ...) > etc. > > Is there an inherent assumption about > underlying processor capabilities in > the design of the Language ? > > -Prabu. no, "parallel" means nothing more than that variable bindings are taken from the _parent_ environment, not the currently being initialized one. there is nothing going on "in parallel". -Tobias From amoroso@mclink.it Sat Sep 25 11:19:34 1999 Received: from mail1.mclink.it (net128-007.mclink.it [195.110.128.7]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id LAA10454 for ; Sat, 25 Sep 1999 11:19:32 -0700 (PDT) Received: from net145-020.mclink.it (net145-020.mclink.it [195.110.145.20]) by mail1.mclink.it (8.9.1/8.9.0) with SMTP id UAA04583 for ; Sat, 25 Sep 1999 20:31:54 +0200 (CEST) From: amoroso@mclink.it (Paolo Amoroso) To: clisp-list@seagull.cons.org Subject: Re: HTTP server available Date: Sat, 25 Sep 1999 18:30:44 GMT Organization: Paolo Amoroso - Milan, ITALY Message-ID: <37eec3f4.832425@mail.mclink.it> References: In-Reply-To: X-Mailer: Forte Agent 1.5/32.451 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit On Fri, 24 Sep 1999 00:01:59 -0700 (PDT), you (Erann Gat ) wrote: > My mini http server is now available at: [...] > Feedback welcome. I have a problem apparently related to SOCKET-SERVER. I include below a sample session (I use the latest version of CLISP, compiled from source, with Red Hat Linux 5.2): 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 ;; Loading file /home/paolo/.clisprc ... ;; Loading of file /home/paolo/.clisprc is finished. [1]> (lisp-implementation-version) "1999-07-22 (July 1999)" [2]> (load "http") ;; Loading file /home/paolo/lisp/http.lsp ... ;; Loading of file /home/paolo/lisp/http.lsp is finished. T [3]> (compile-file "http") Compiling file /home/paolo/lisp/http.lsp ... Compilation of file /home/paolo/lisp/http.lsp is finished. 0 errors, 0 warnings #P"/home/paolo/lisp/http.fas" ; NIL ; NIL [4]> (load "http") ;; Loading file /home/paolo/lisp/http.fas ... WARNING: Replacing method #)> in # ;;; ;;; Many more warnings... ;;; WARNING: Replacing method #)> in # ;; Loading of file /home/paolo/lisp/http.fas is finished. T [5]> (serve) *** - UNIX error 22 (EINVAL): Invalid argument 1. Break [6]> abort [7]> (socket-server 12345) *** - UNIX error 22 (EINVAL): Invalid argument 1. Break [8]> I tried calling SERVE as root, and as a regular user on unprivileged ports. Am I missing something obvious? By the way, contrarily to what is stated in the comments, SERVE does not accept any arguments. Paolo -- EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/ From Klaus.Schilling@munich.netsurf.de Sat Sep 25 23:51:38 1999 Received: from laurin.munich.netsurf.de (laurin.munich.netsurf.de [194.64.166.1]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id XAA17665 for ; Sat, 25 Sep 1999 23:51:37 -0700 (PDT) Received: from debian (root@ns1053.munich.netsurf.de [195.180.235.53]) by laurin.munich.netsurf.de (8.9.3/8.9.3) with ESMTP id JAA13363 for ; Sun, 26 Sep 1999 09:04:07 +0200 (MET DST) Received: by debian via sendmail from stdin id (Debian Smail3.2.0.102) for clisp-list@clisp.cons.org; Sun, 26 Sep 1999 16:52:27 +0200 (CEST) Message-Id: Date: Sun, 26 Sep 1999 16:52:27 +0200 (CEST) From: Klaus Schilling To: clisp-list@clisp.cons.org Subject: cl-http with clisp Reply-to: Klaus.Schilling@munich.netsurf.de is it possible to run cl-http under c-lisp? I didn't find clisp mentioned on the cl-http homepage. Klaus Schilling From joswig@lavielle.com Sun Sep 26 00:28:14 1999 Received: from vampire.lavielle.com (vampire.lavielle.com [194.64.21.10]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id AAA18144 for ; Sun, 26 Sep 1999 00:28:13 -0700 (PDT) Received: from [194.64.21.18] ([194.163.195.67]) by vampire.lavielle.com (8.9.3/8.9.3) with ESMTP id JAA05431; Sun, 26 Sep 1999 09:40:43 +0200 (MET DST) Mime-Version: 1.0 X-Sender: joswig@194.64.21.10 Message-Id: In-Reply-To: References: Date: Sun, 26 Sep 1999 09:40:30 +0200 To: clisp-list@seagull.cons.org, Multiple recipients of list From: Rainer Joswig Subject: Re: cl-http with clisp Content-Type: text/plain; charset="us-ascii" At 23:52 Uhr -0700 25.09.1999, Klaus Schilling wrote: >is it possible to run cl-http under c-lisp? AFAIK, not. Although a single-threaded port *might* be possible (there were other single threaded ports before). It would be a bit of work to do so, I guess. > I didn't find clisp >mentioned on the cl-http homepage. Rainer Joswig, "Lavielle" EDV Systemberatung GmbH & Co. KG, Lotharstrasse 2b, 22041 Hamburg, Germany, Tel: +49 40 658088, Fax: +49 40 65808-202, Email: joswig@lavielle.com , WWW: http://www.lavielle.de/ From gat@jpl.nasa.gov Sun Sep 26 01:03:13 1999 Received: from mail3.jpl.nasa.gov (eis-msg-024.jpl.nasa.gov [137.78.160.181]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id BAA18557 for ; Sun, 26 Sep 1999 01:03:13 -0700 (PDT) Received: from binkley ([128.149.8.194]) by mail3.jpl.nasa.gov (Netscape Messaging Server 3.6) with SMTP id AAA93A; Sun, 26 Sep 1999 01:15:45 -0700 Date: Sun, 26 Sep 1999 01:15:43 -0700 (PDT) From: Erann Gat X-Sender: gat@binkley To: clisp-list@seagull.cons.org cc: Multiple recipients of list Subject: Re: HTTP server available In-Reply-To: <37eec3f4.832425@mail.mclink.it> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Sat, 25 Sep 1999, Paolo Amoroso wrote: > I have a problem apparently related to SOCKET-SERVER. I include below a > sample session (I use the latest version of CLISP, compiled from source, > with Red Hat Linux 5.2): > ;; Loading file /home/paolo/.clisprc ... > ;; Loading of file /home/paolo/.clisprc is finished. > [1]> (lisp-implementation-version) > "1999-07-22 (July 1999)" etc... > [7]> (socket-server 12345) > > *** - UNIX error 22 (EINVAL): Invalid argument > 1. Break [8]> That's pretty weird. The only thing I can think of is that there's something in your .clisprc file that's messing things up somehow. Have you tried calling socket-server without loading anything? (BTW, it's not a permission problem. If it were you'd get a different error.) Socket-server is a CLisp builtin so Bruno would be the one to ask. > By the way, contrarily to what is stated in the comments, SERVE does not > accept any arguments. I fixed this. E. From amoroso@mclink.it Sun Sep 26 12:08:46 1999 Received: from mail1.mclink.it (net128-007.mclink.it [195.110.128.7]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id MAA24797 for ; Sun, 26 Sep 1999 12:04:33 -0700 (PDT) Received: from net145-003.mclink.it (net145-003.mclink.it [195.110.145.3]) by mail1.mclink.it (8.9.1/8.9.0) with SMTP id VAA27447 for ; Sun, 26 Sep 1999 21:16:59 +0200 (CEST) From: amoroso@mclink.it (Paolo Amoroso) To: clisp-list@seagull.cons.org Subject: Re: HTTP server available Date: Sun, 26 Sep 1999 20:15:46 GMT Organization: Paolo Amoroso - Milan, ITALY Message-ID: <37ee7c00.258821@mail.mclink.it> References: In-Reply-To: X-Mailer: Forte Agent 1.5/32.451 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit On Sun, 26 Sep 1999 01:03:34 -0700 (PDT), you wrote: > That's pretty weird. The only thing I can think of is that there's > something in your .clisprc file that's messing things up somehow. This is unlikely. My .clisprc file looks harmless: (when (boundp 'system::*source-file-types*) (pushnew (pathname ".lisp") system::*source-file-types*)) > Have you tried calling socket-server without loading anything? Yes. The problem does not go away. Here's a session with a freshly started CLISP that does not load my .clisprc: [1]> (socket-server 1234) *** - UNIX error 22 (EINVAL): Invalid argument 1. Break [2]> abort [3]> (socket-server 56789) *** - UNIX error 22 (EINVAL): Invalid argument 1. Break [4]> > different error.) Socket-server is a CLisp builtin so Bruno > would be the one to ask. I don't know if it's useful, but I built CLISP from source. I configured it as follows: --prefix=/usr/local/clisp --with-readline --with-gettext --with-dynamic-ffi --with-export-syscalls --with-module-wildcard --with-module-regexp --with-module=bindings/linuxlibc6 and added clx/new-clx to the MODULES macro in the makefile. Paolo -- EncyCMUCLopedia * Extensive collection of CMU Common Lisp documentation http://cvs2.cons.org:8000/cmucl/doc/EncyCMUCLopedia/ From emarsden@laas.fr Sun Sep 26 12:29:48 1999 Received: from laas.laas.fr (root@laas.laas.fr [140.93.0.15]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id MAA25246 for ; Sun, 26 Sep 1999 12:29:46 -0700 (PDT) Received: from dukas.laas.fr (dukas [140.93.21.58]) by laas.laas.fr (8.9.3/8.9.3) with ESMTP id VAA20336 for ; Sun, 26 Sep 1999 21:42:07 +0200 (MET DST) Received: (from emarsden@localhost) by dukas.laas.fr (8.9.3/8.9.3) id VAA14045; Sun, 26 Sep 1999 21:42:06 +0200 (MET DST) To: clisp-list@seagull.cons.org Subject: Re: HTTP server available References: Organization: LAAS-CNRS http://www.laas.fr/ MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Eric-Conspiracy: there is no conspiracy X-Attribution: ecm X-URL: http://www.chez.com/emarsden/ From: Eric Marsden Date: 26 Sep 1999 21:42:06 +0200 In-Reply-To: Erann Gat's message of "Fri, 24 Sep 1999 00:01:52 -0700 (PDT)" Message-ID: Lines: 22 X-Mailer: Gnus v5.7/Emacs 20.4 >>>>> "eg" == Erann Gat writes: eg> My mini http server is now available at: and I have likewise put my code at It's useless as-is, since I developed it using a really old version of CLISP (1997-something; I haven't worked on the code since). There's also no documentation. However, it does have a nice extensible architecture based on path handlers, inspired from the su-net web server, and makes some attempts at sending a correct MIME type etc. I originally had the idea of using the code for a comment server (which allows users to add threaded commentary to a web page, with comments stored in a database), which explains the stuff in cserv.lsp. -- Eric Marsden It's elephants all the way down From abecerra@iie.ufro.cl Mon Sep 27 06:55:35 1999 Received: from lautaro.enlaces.ufro.cl (lautaro.enlaces.ufro.cl [200.13.0.1]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id GAA06625 for ; Mon, 27 Sep 1999 06:55:27 -0700 (PDT) Received: from anita (tch61-110.cnt.entelchile.net [206.84.84.110]) by lautaro.enlaces.ufro.cl (8.8.8/8.8.8) with SMTP id LAA22824 for ; Mon, 27 Sep 1999 11:04:56 -0400 (SAT) Message-ID: <000d01bf08f0$a84f3640$6e5454ce@anita> From: "Anita Becerra Lagos" To: Subject: questions of features clisp Date: Mon, 27 Sep 1999 10:00:27 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000A_01BF08CF.20310840" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.5 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 This is a multi-part message in MIME format. ------=_NextPart_000_000A_01BF08CF.20310840 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable hi I am intereting infeatures clisp what means "PCL" in: Package running in clisp include PCL and another questios is: the user interface comes in spanish it is available ? thanks. Anita.lisp ------=_NextPart_000_000A_01BF08CF.20310840 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

hi
 

I am = intereting infeatures=20 clisp
 
what means = "PCL"=20 in:
 
Package running = in clisp=20 include PCL
 

and another = questios=20 is:
the user interface comes in spanish
it is available=20 ?
 
thanks.
 
Anita.lisp
------=_NextPart_000_000A_01BF08CF.20310840-- From haible@ilog.fr Mon Sep 27 07:17:12 1999 Received: from sceaux.ilog.fr (sceaux.ilog.fr [193.55.64.10]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id HAA07017 for ; Mon, 27 Sep 1999 07:17:11 -0700 (PDT) Received: from laposte.ilog.fr (laposte [172.17.1.6]) by sceaux.ilog.fr (8.9.3/8.9.3) with ESMTP id QAA17897 for ; Mon, 27 Sep 1999 16:28:46 +0200 (MET DST) Received: from jaures.ilog.fr ([172.17.4.92]) by laposte.ilog.fr (8.9.3/8.9.3) with ESMTP id QAA00750; Mon, 27 Sep 1999 16:29:40 +0200 (MET DST) From: Bruno Haible Received: (from haible@localhost) by jaures.ilog.fr (8.9.3/8.9.3) id QAA10600; Mon, 27 Sep 1999 16:29:39 +0200 (MET DST) Date: Mon, 27 Sep 1999 16:29:39 +0200 (MET DST) Message-Id: <199909271429.QAA10600@jaures.ilog.fr> To: clisp-list@seagull.cons.org Subject: Re: questions of features clisp In-Reply-To: <000d01bf08f0$a84f3640$6e5454ce@anita> References: <000d01bf08f0$a84f3640$6e5454ce@anita> Anita Becerra Lagos writes: > I am intereting infeatures clisp > > what means "PCL" in: > > Package running in clisp include PCL PCL, meaning "Portable Common Loops", is an early implementation of a subset of CLOS. It runs in CLISP, but the built-in CLOS in much faster. > and another questios is: > the user interface comes in spanish > it is available ? On Unix, after you set your environment variable LANG to "es_CL", clisp will use spanish instead of english messages for errors, prompts, etc. This feature is not yet available on Windows. Bruno From abecerra@iie.ufro.cl Mon Sep 27 08:46:07 1999 Received: from lautaro.enlaces.ufro.cl (lautaro.enlaces.ufro.cl [200.13.0.1]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id IAA08240 for ; Mon, 27 Sep 1999 08:45:12 -0700 (PDT) Received: from anita.dis.ufro.cl ([200.10.21.82]) by lautaro.enlaces.ufro.cl (8.8.8/8.8.8) with SMTP id MAA25701 for ; Mon, 27 Sep 1999 12:55:16 -0400 (SAT) Message-ID: <005701bf08f7$81b79660$52150ac8@anita.dis.ufro.cl> From: "Anita Lilian Becerra Lagos" To: Subject: RE: questions of features clisp Date: Mon, 27 Sep 1999 11:49:31 -0300 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.2106.4 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 thanks !!! >Anita Becerra Lagos writes: > >> I am intereting infeatures clisp >> >> what means "PCL" in: >> >> Package running in clisp include PCL > >PCL, meaning "Portable Common Loops", is an early implementation of a >subset of CLOS. It runs in CLISP, but the built-in CLOS in much faster. > >> and another questios is: >> the user interface comes in spanish >> it is available ? > >On Unix, after you set your environment variable LANG to "es_CL", clisp >will use spanish instead of english messages for errors, prompts, etc. > >This feature is not yet available on Windows. > >Bruno > From PJRHusbands@lbl.gov Mon Sep 27 11:51:28 1999 Received: from postal1.lbl.gov (postal1.lbl.gov [128.3.7.82]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id LAA11690 for ; Mon, 27 Sep 1999 11:51:27 -0700 (PDT) Received: from SpamWall.lbl.gov (localhost [127.0.0.1]) by postal1.lbl.gov (8.9.3/8.9.3) with ESMTP id MAA03247 for ; Mon, 27 Sep 1999 12:04:09 -0700 (PDT) Received: from husbands.lbl.gov.Lawrence (husbands.lbl.gov [131.243.240.194]) by SpamWall.lbl.gov (8.9.3/8.9.3) with SMTP id MAA03232; Mon, 27 Sep 1999 12:04:08 -0700 (PDT) Sender: parry@husbands.lbl.gov To: clisp-list@clisp.cons.org Subject: Sending double-floats down sockets... (Take 2) From: Parry Husbands Date: 27 Sep 1999 12:04:08 -0700 Message-ID: Lines: 14 User-Agent: Gnus/5.070083 (Pterodactyl Gnus v0.83) XEmacs/20.4 (Emerald) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Hi. My apologies if you see this twice. I didn't see the first version I sent last week: Is there an easy way to get at the 8 bytes of a double-float? I'm trying to communicate with a remote server that accepts floating point numbers as the 8 bytes of their IEEE representation so I need to send these down the socket stream. I've been able to deal with integers (using write-byte and ldb), but am having trouble with floats. By the way, I'm using the 1997-07-22 version on a Sun Ultra (Solaris 5.7). Thanks. Parry From haible@ilog.fr Mon Sep 27 12:21:47 1999 Received: from sceaux.ilog.fr (sceaux.ilog.fr [193.55.64.10]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id MAA12308 for ; Mon, 27 Sep 1999 12:21:45 -0700 (PDT) Received: from laposte.ilog.fr (laposte [172.17.1.6]) by sceaux.ilog.fr (8.9.3/8.9.3) with ESMTP id VAA26596 for ; Mon, 27 Sep 1999 21:33:28 +0200 (MET DST) Received: from jaures.ilog.fr ([172.17.4.92]) by laposte.ilog.fr (8.9.3/8.9.3) with ESMTP id VAA20789; Mon, 27 Sep 1999 21:34:23 +0200 (MET DST) From: Bruno Haible Received: (from haible@localhost) by jaures.ilog.fr (8.9.3/8.9.3) id VAA12642; Mon, 27 Sep 1999 21:34:22 +0200 (MET DST) Date: Mon, 27 Sep 1999 21:34:22 +0200 (MET DST) Message-Id: <199909271934.VAA12642@jaures.ilog.fr> To: clisp-list@seagull.cons.org Subject: Re: Sending double-floats down sockets... (Take 2) In-Reply-To: References: Parry Husbands asks: > Is there an easy way to get at the 8 bytes of a double-float? I'm > trying to communicate with a remote server that accepts floating point > numbers as the 8 bytes of their IEEE representation so I need to send > these down the socket stream. I've been able to deal with integers > (using write-byte and ldb), but am having trouble with floats. > > By the way, I'm using the 1997-07-22 version on a Sun Ultra (Solaris 5.7). In the newest snapshots [1] [2], there is a function WRITE-FLOAT. First, you would have to set the element-type of your socket-stream to (UNSIGNED-BYTE 8). Then, you can call (WRITE-FLOAT number stream 'DOUBLE-FLOAT endianness) where the endianness is either :LITTLE or :BIG. READ-FLOAT and WRITE-FLOAT were suggested by Marco Antoniotti. Bruno [1] ftp://cellar.goems.com/pub/clisp/clisp-snap.tgz [2] ftp://ftp.ilog.fr/pub/Users/haible/lisp/clisp-1999-09-13.tar.gz ! To unsubscribe from the clisp-list mailing list, send mail to ! ! listproc@clisp.cons.org ! ! including the two words "unsubscribe clisp-list" as message body. ! From hoehle@tzd.telekom.de Tue Sep 28 06:04:38 1999 Received: from fw1a.telekom.de (gw1.telekom.de [194.25.15.11]) by seagull.cdrom.com (8.8.8/8.7.3) with SMTP id GAA24038 for ; Tue, 28 Sep 1999 06:04:37 -0700 (PDT) Received: by fw1a.telekom.de; (5.65v4.0/1.3/10May95) id AA30569; Tue, 28 Sep 1999 15:17:24 +0200 Received: from G8PXB.blf01.telekom.de by U8PW4.blf01.telekom.de with ESMTP for clisp-list@clisp.cons.org; Tue, 28 Sep 1999 15:18:16 +0200 Received: from q9f09.dmst02.telekom.de by G8PXB.blf01.telekom.de with ESMTP; Tue, 28 Sep 1999 15:17:04 +0200 Received: from w9f00992.dmst02.telekom.de (W9F00992.dmst02.telekom.de [164.27.121.145]) by q9f09.dmst02.telekom.de (8.8.5/8.8.5) with SMTP id NAA16596; Tue, 28 Sep 1999 13:55:44 +0100 Received: from tzd.telekom.de by w9f00992.dmst02.telekom.de (SMI-8.6/SMI-SVR4) id PAA10047; Tue, 28 Sep 1999 15:16:47 +0200 Message-Id: <37F0BFBF.BA330485@tzd.telekom.de> Date: Tue, 28 Sep 1999 15:16:47 +0200 From: "J`o'rg-Cyril H`o'hle" Organization: Deutsche Telekom AG X-Mailer: Mozilla 4.08 [en] (WinNT; I) Mime-Version: 1.0 To: clisp-list@clisp.cons.org Subject: Re: CLISP - DLL Interface Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, here I'm trying to give some information about how CLISP on MS- platforms could provide access to .dll. I hope that I'll rise interest enough that we'll finally find somebody with some MS- experience and a compiler on a MS- platform willing to take the effort and do the real implementation work, reusing as much as possible of what's already in the FFI. I believe it shouldn't be that much trouble, er, I mean no more trouble than you usually get for touching some MS-* system. I describe how the FFI works on AmigaOS (not the AFFI: Amiga-CLISP can contain two FFIs at the same time!) and how I can imagine things would work extremely similarly on MS-*. Bruno Haible said: > When you `compile-file' a Lisp file which contains FFI declarations, > a .c file is generated, which is intended to be compiled [...] and > linked with the clisp core. When using DEF-LIB-CALL-OUT on AmigaOS, no compilation is necessary, neither of Lisp nor C files, everything runs also in interpreted mode, no glue code, no linking of object files is necessary. IMHO, the same could be possible on MS-*. Enough hype, here it comes ;) (def-lib-call-out Regexp-Compile "regexp.library" (:offset -30) (:name "RegComp") ;unneeded but for documentation (:arguments (pattern c-string :in :alloca :a0)) (:return-type c-pointer)) ;we need c-pointer-nil! On AmigaOS, a function of a shared library is "known" by its library name, an offset towards the library object and of course the argument and return types and registers, so the above is enough to be able to define the function. On MS-*, I believe the function name would be mandatory, since I believe there's a call which will return the address of a function in a shared library, given its name. There's probably no such thing like an offset. So foreign_library_function() needs to be modified accordingly. foreign_library() needs to be modified as well. It kees track of opened libraries by name so they get only opended once and can be closed at program exit (if you don't feel that this is useless burden). So far, there's no provision in CLISP for closing libraries during run-time, I didn't implement this kind of resource tracking. It wouldn't fit anyway the FFI producing first class function objects with indefinite extent. I won't for now expand more into what happens to the foreign library and function objects dynamically created by CLISP: the implementor will have to decide what's happening to these when they are saved in a .mem image, more esp. what is to happen when such an image is loaded. I can't remember now whether Amiga-CLISP will (a) attempt to re-open the libraries at program start or (b) lazily, when the function is invoked or (c) mark the function as dead (like a former *terminal-io* stream is sadly marked dead). Appended is a working example (Amiga-CLISP 1996-05-30, FFI version) of regexp matching for one of the four shared libraries that I found to implement some form of regexps (GNU, POSIX, Apache 1.3.4, custom). Once the foreign functions work, we can start again to discuss small additions to the FFI to be able to make an easier usage of it, as observed in the sample code below (C-POINTER-NIL, NULL pointer test, SETF VALIDP, conversions and partial dereferences, cost of nested deconversions, foreign-address-variable as primitive object, non-run-time C-type computations, ...). Not requiring glue code doesn't mean that I wouldn't favour "thick bindings" (in Ada speak) over "thin" ones. Esp. with C interfaces, it's much easier to write small wrappers in C that will return proper objects instead of having to deal in Lisp with numbers that are mostly positive, except for the error return signified when the (long)(ulong)value is -1 (e.g. socket or regexp interface). OTOH, I favour using shared libraries as is. In some future, a similar interface could be used to load UNIX .so shared objects and libraries without compilation, just linking, like CMUCL and Allegro do -- or is this already implemented? ;;; Regexp matching ;;; for use with regexp.library 1998 by M.Bethke, ;;; said to be based on NetBSD v1.7 code ;;; aminet/util/libs/regexp.lha ;;; http://ftp.rrze.uni-erlangen.de/cgi-bin/view/pub/amiga/aminet/util/libs/regexp.lha (defpackage "REGEXP" (:export "MATCH-ONCE") (:use "LISP" "FFI")) (in-package "REGEXP") (def-lib-call-out Regexp-Compile "regexp.library" (:offset -30) (:name "RegComp") ;unneeded but for documentation (:arguments (pattern c-string :in :alloca :a0)) (:return-type c-pointer)) ;we need c-pointer-nil! ;; Using C-POINTER, we are able to delay the otherwise immediate ;; conversion of the returned structure into Lisp data until the ;; structure reference (consider it an object) will actually be filled ;; with valid values by subsequent FFI calls on that object. ;; a FOREIGN-ADDRESS (c-pointer return type) can only be tested for ;; NULL with EQUALP against a known NULL address. ;; Where to get this first one? ;; FOREIGN-VALUE only works on FOREIGN-VARIABLE, not -ADDRESS (defun nzero-pointer (p) ;? (not (eq (foreign-value p) 0)) p) ; doesn't work (def-lib-call-out Regexp-Match "regexp.library" (:offset -42) (:name "RegExec") (:arguments (handle c-pointer :in :none :a0) (expression c-string :in :alloca :a1)) (:return-type long)) (def-lib-call-out Regexp-Free "regexp.library" (:offset -36) (:name "RegFree") (:arguments (handle c-pointer :in :none :a1)) (:return-type nil)) (def-lib-call-out Regexp-errortext "regexp.library" (:offset -48) (:name "RegXlatError") (:arguments (code long :in :none :d0)) ;obtained from dos.library/IoErr() (:return-type c-string :none)) (def-lib-call-out IoErr "dos.library" (:offset -132) (:return-type long)) (defun match-once0 (pattern string) (let (handle) (unwind-protect (if (nzero-pointer (setq handle (regexp-compile pattern))) (case (regexp-match handle string) (1 T) ;match (0 NIL) ;no match (-1 (regexp-errortext (ioerr)))) (regexp-errortext (ioerr))) (when (nzero-pointer handle) (regexp-free handle))))) (defun match-once (pattern string) (let ((result (match-once0 pattern strin))) (if (stringp result) (error "~S: ~A" 'match-once result) result))) ;; Another implementation of match-once0 could return T/NIL/IoErr() ;; and leave regexp-errortext to match-once, given that the library is ;; kept open until program exit anyway by the FFI. ;;; Typical pattern for finalizers: (defun regexp-free-finally (handle) (when (validp handle) ;; but that won't mark it as invalid (regexp-free handle))) ;(finalize handle #'regexp-free-finally) ;; Optionally, the handle can be inspected instead of being opaque ;; and up to 10 start and end match positions be extracted... ;; The macro comes in handy when converting useless opaque c-pointer ;; FOREIGN-ADDRESS to FOREIGN-VARIABLE objects that can be peeked at. ;; Sadly, FFI::FOREIGN-ADDRESS-VARIABLE exists only on the Amiga and ;; was later renamed FOREIGN-LIBRARY-VARIABLE, a misnomer IMHO. (defmacro WITH-FOREIGN-VALUE ((var object type &optional (offset 0)) &body body) (let ((fvar (gensym))) `(LET ((,fvar (FFI::FOREIGN-ADDRESS-VARIABLE "unnamed" ,object ,offset ,(if (consp type) (list 'QUOTE (ffi::parse-c-type type)) ; assume a (STRUCT ...) ;; don't deparse DEF-C-STRUCT types at macroexpansion time `(FFI::PARSE-C-TYPE ',type))))) (SYMBOL-MACROLET ((,var (FFI::FOREIGN-VALUE ,fvar))) ,@body)))) #| regexp.h #define NSUBEXP 10 typedef struct regexp { STRPTR startp[NSUBEXP]; STRPTR endp[NSUBEXP]; ... } regexp; |# ;; Since these are pointers, not indices, we get in trouble here since ;; we stack-allocated the string. Better choose another regex library ;; with a different API -- I hope I just showed dynamic libraries. ;; BTW, M.Bethke, the author of this regexp library has since ;; responded to my suggestions and added a RegGetMatch() call which ;; returns 0-based indices, to library version 39. (defun match-data (handle index) "Doesn't work, string pointer to no man's land" (assert (<= 0 index 10)) (with-foreign-value (match-data handle (c-array uint32 20) 0) (values (element match-data index) (element match-data (+ index 10))))) ;; These are the internals for the curious #| (setq foo (regexp-compile "foo")) (ffi::foreign-value (ffi::foreign-address-variable "regexp" foo 0 '#.(ffi::parse-c-type '(c-array uint32 20))) ) (ffi::foreign-value (ffi::%element (ffi::foreign-address-variable "regexp" foo 0 '#.(ffi::parse-c-type '(c-array uint32 20))) 0)) |# Regards, Joerg Hoehle. Sugestions are welcome! From Paul.Moore@uk.origin-it.com Tue Sep 28 08:09:08 1999 Received: from gw-nl1.origin-it.com (gw-nl1.origin-it.com [193.79.128.34]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id IAA25797 for ; Tue, 28 Sep 1999 08:09:06 -0700 (PDT) Received: from mail.origin-it.com (localhost.origin-it.com [127.0.0.1]) by gw-nl1.origin-it.com with ESMTP id RAA03753 for ; Tue, 28 Sep 1999 17:21:52 +0200 (MEST) (envelope-from Paul.Moore@uk.origin-it.com) Received: from mail.origin-it.com(172.16.127.3) by gw-nl1.origin-it.com via mwrap (4.0a) id xma003751; Tue, 28 Sep 99 17:21:52 +0200 Received: from ukrax001.ras.uk.origin-it.com (ukrax001.ras.uk.origin-it.com [172.16.201.234]) by mail.origin-it.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id RAA19508 for ; Tue, 28 Sep 1999 17:21:47 +0200 (MET DST) Received: by ukrax001.ras.uk.origin-it.com with Internet Mail Service (5.5.2448.0) id ; Tue, 28 Sep 1999 16:21:45 +0100 Message-ID: <714DFA46B9BBD0119CD000805FC1F53BB4155D@UKRUX002.rundc.uk.origin-it.com> From: "Moore, Paul" To: "'clisp-list@seagull.cons.org'" Subject: RE: CLISP - DLL Interface Date: Tue, 28 Sep 1999 16:21:37 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" From: clisp-list@clisp.cons.org [mailto:clisp-list@clisp.cons.org] > here I'm trying to give some information about how CLISP on MS- > platforms could provide access to .dll. I hope that I'll rise > interest enough that we'll finally find somebody with some MS- > experience and a compiler on a MS- platform willing to take the effort > and do the real implementation work, reusing as much as possible of > what's already in the FFI. I am very interested in having a working FFI on MS platforms. From my point of view, CLISP without a FFI capable of calling DLL functions is of little value. I'd go further and say that I'd want access to COM/OLE Automation (which isn't much harder to add once the basic infrastructure is there). Of course, my requirements may well not be the same as the general CLISP community. > I believe it shouldn't be that much trouble, er, I mean no more > trouble than you usually get for touching some MS-* system. Correct. To call a function in a DLL, you need to do lib = LoadLibrary("libname.dll"); fn = GetProcAddress(lib, "functionname"); ret = fn(a,b,c); /* Indirect call through the pointer 'fn' */ FreeLibrary(lib); COM/OLE is more complex, but only in the protocols, not in the details. I could (and would) do this myself, but the obscure coding of the CLISP internals (and the use of German for the comments, but that's my problem :-) makes it impossible for me to see what is going on. I simply haven't got the time or inclination to try to get my head round the internals of CLISP, to add a small amount of Windows-specific code. > I describe how the FFI works on AmigaOS (not the AFFI: Amiga-CLISP can > contain two FFIs at the same time!) and how I can imagine things would > work extremely similarly on MS-*. I would imagine that this is true. > When using DEF-LIB-CALL-OUT on AmigaOS, no compilation is necessary, > neither of Lisp nor C files, everything runs also in interpreted mode, > no glue code, no linking of object files is necessary. IMHO, the > same could be possible on MS-*. Correct. In fact, I'd say that this would be the only sensible idea. > Enough hype, here it comes ;) > > (def-lib-call-out Regexp-Compile > "regexp.library" > (:offset -30) > (:name "RegComp") ;unneeded but for documentation > (:arguments (pattern c-string :in :alloca :a0)) > (:return-type c-pointer)) ;we need c-pointer-nil! > > On AmigaOS, a function of a shared library is "known" by its library > name, an offset towards the library object and of course the argument > and return types and registers, so the above is enough to be able to > define the function. > > On MS-*, I believe the function name would be mandatory, since I > believe there's a call which will return the address of a function in > a shared library, given its name. There's probably no such thing like > an offset. So foreign_library_function() needs to be modified > accordingly. Exactly correct. > foreign_library() needs to be modified as well. It kees track of > opened libraries by name so they get only opended once and can be > closed at program exit (if you don't feel that this is useless > burden). So far, there's no provision in CLISP for closing libraries > during run-time, I didn't implement this kind of resource tracking. > It wouldn't fit anyway the FFI producing first class function objects > with indefinite extent. Again, correct. FreeLibrary should be deferred as you suggest. Although I would prefer libraries to be freed when there are no outstanding references - I assume the resource management issues are similar in AmigaOS, though, so the two cases go together. > I won't for now expand more into what happens to the foreign library > and function objects dynamically created by CLISP: the implementor > will have to decide what's happening to these when they are saved in a > .mem image, more esp. what is to happen when such an image is loaded. > I can't remember now whether Amiga-CLISP will (a) attempt to re-open > the libraries at program start or (b) lazily, when the function is > invoked or (c) mark the function as dead (like a former *terminal-io* > stream is sadly marked dead). Hmm, this is precisely the sort of area where I cannot begin to understand the internals of CLISP, to comment. I'd say that option (c) is not workable in practice, though. My uneducated view is that option (b) is correct, but harder to implement. Option (a) is a cheap work-around, but it risks becoming expensive if (as is likely on Win32) FFI calls to dynamic libraries are common. Being able to implement callbacks to Lisp from C is also critical (I want to be able to write a window procedure in Lisp). > Once the foreign functions work, we can start again to discuss small > additions to the FFI to be able to make an easier usage of it, as > observed in the sample code below (C-POINTER-NIL, NULL pointer test, > SETF VALIDP, conversions and partial dereferences, cost of nested > deconversions, foreign-address-variable as primitive object, > non-run-time C-type computations, ...). My first priority would be a much bigger extension - OLE automation. I would want to see some LISP-like way of calling COM, so that you could do the equivalent of excel = CreateObject('Excel.Application') excel.LoadWorkbook('file.xls') excel.Cell('A1') = 12 excel.Recalculate excel.Select('A1F9') excel.PrintSelection excel.Quit but while I could code the internals, I don't have the first clue about a suitable "lisp-like" syntax for this. (CLOS is probably very relevant here). My problem is a chicken-and-egg one: until CLISP lets me do the sort of things I'm interested in (DLL calls for GUI management, OLE/COM, OS-specific interfacing), I don't have the application to make it worth me learning more than the basics of lisp. I personally find the implementation of CLISP to be pretty hostile to "random" coders (ie ones who are not intimately familiar with the CLISP internals) writing C extensions. My interest is in *using* CLISP, to find out what Common Lisp "feels" like as a glue/scripting language like Perl, Python, Haskell, etc. Is it nicer to use, more powerful, more flexible, ...? Implementing the interfaces puts me "too close" to properly evaluate the language from a usage point of view... So, while it may be an interesting exercise, it is diametrically opposed to my real interest. > Not requiring glue code doesn't mean that I wouldn't favour "thick > bindings" (in Ada speak) over "thin" ones. Esp. with C interfaces, > it's much easier to write small wrappers in C that will return proper > objects instead of having to deal in Lisp with numbers that are mostly > positive, except for the error return signified when the > (long)(ulong)value is -1 (e.g. socket or regexp interface). OTOH, I > favour using shared libraries as is. COM/OLE is effectively a generic thick binding. Hope this helps. I agree with everything you say, but personally don't want to climb the learning curve of the CLISP internals, just to implement a FFI myself. I will happily help others (with advice and comments) who wish to do so, though. Paul Moore. From Paul.Moore@uk.origin-it.com Tue Sep 28 08:17:50 1999 Received: from gw-nl1.origin-it.com (gw-nl1.origin-it.com [193.79.128.34]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id IAA26085 for ; Tue, 28 Sep 1999 08:17:49 -0700 (PDT) Received: from mail.origin-it.com (localhost.origin-it.com [127.0.0.1]) by gw-nl1.origin-it.com with ESMTP id RAA06883 for ; Tue, 28 Sep 1999 17:30:32 +0200 (MEST) (envelope-from Paul.Moore@uk.origin-it.com) Received: from mail.origin-it.com(172.16.127.3) by gw-nl1.origin-it.com via mwrap (4.0a) id xma006881; Tue, 28 Sep 99 17:30:32 +0200 Received: from ukrax001.ras.uk.origin-it.com (ukrax001.ras.uk.origin-it.com [172.16.201.234]) by mail.origin-it.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id RAA21764 for ; Tue, 28 Sep 1999 17:30:31 +0200 (MET DST) Received: by ukrax001.ras.uk.origin-it.com with Internet Mail Service (5.5.2448.0) id ; Tue, 28 Sep 1999 16:30:31 +0100 Message-ID: <714DFA46B9BBD0119CD000805FC1F53BB4155E@UKRUX002.rundc.uk.origin-it.com> From: "Moore, Paul" To: "'clisp-list@seagull.cons.org'" Subject: RE: CLISP - DLL Interface Date: Tue, 28 Sep 1999 16:30:24 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" From: Bruno Haible [mailto:haible@ilog.fr] > Using CLISP's FFI, documented in impnotes.html, you can write calls to > external C functions. When you `compile-file' a Lisp file > which contains FFI declarations, a .c file is generated, which > is intended to be compiled by the same C compiler as was used to > build the CLISP binary, and linked with the clisp core. Oh, yes. This reminds me of the other reason why an Amiga-style FFI is the only way to go for Windows. You cannot assume that any particular Windows user has access to a C compiler (not even mingw/gcc - see below), nor that they can build CLISP for themselves in any case (AFAIK, it doesn't build on Win95, only on NT). Even though gcc/mingw is available for free on Win32, making users of CLISP download and install it, just to do FFI calls from CLISP, is not realistically going to encourage the use of CLISP on Win32. Paul. From hoehle@mmkmail.gmd.de Tue Sep 28 09:22:29 1999 Received: from mail.gmd.de (mail.gmd.de [129.26.8.90]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id JAA27211 for ; Tue, 28 Sep 1999 09:22:27 -0700 (PDT) Received: from zeus.gmd.de (zeus.gmd.de [129.26.165.1]) by mail.gmd.de (8.8.8/8.8.8) with ESMTP id SAA15399; Tue, 28 Sep 1999 18:35:09 +0200 (MET DST) Received: from localhost (hoehle@localhost) by zeus.gmd.de (8.9.1/8.9.3) with SMTP id SAA18749; Tue, 28 Sep 1999 18:35:09 +0200 (MET DST) X-Authentication-Warning: zeus.gmd.de: hoehle owned process doing -bs Date: Tue, 28 Sep 1999 18:35:08 +0200 (MET DST) From: Joerg Hoehle X-Sender: hoehle@zeus To: clisp-list@seagull.cons.org Subject: RE: CLISP - DLL Interface In-Reply-To: <714DFA46B9BBD0119CD000805FC1F53BB4155D@UKRUX002.rundc.uk.origin-it.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Hi again, On Tue, 28 Sep 1999, Moore, Paul wrote: > Again, correct. FreeLibrary should be deferred as you suggest. Although I > would prefer libraries to be freed when there are no outstanding references > - I assume the resource management issues are similar in AmigaOS, though, so > the two cases go together. Another possibility would make heavy use of finalize *and* ensure that finalizers get called when CLISP exists, which is currently not the case. Yet finalizers are not all the answer, e.g. in your excel example below, the programmer probably would have to tell that this excel object comes from a given .dll which therefore probably should not disappear before the object goes away as well. > > .mem image, more esp. what is to happen when such an image is loaded. > > I can't remember now whether Amiga-CLISP will (a) attempt to re-open > > the libraries at program start or (b) lazily, when the function is > > invoked or (c) mark the function as dead (like a former *terminal-io* > > stream is sadly marked dead). > > Hmm, this is precisely the sort of area where I cannot begin to understand > the internals of CLISP, to comment. I'd say that option (c) is not workable > in practice, though. My uneducated view is that option (b) is correct, but > harder to implement. Option (a) is a cheap work-around, but it risks > becoming expensive if (as is likely on Win32) FFI calls to dynamic libraries > are common. FFI calls being common or not is not directly related to building an own .mem file (called image or core). Applications ought to be written in such a way that they don't rely on CLISP reopening libraries for them, and they rather reinitialize themselves what is needed (like the httpd main function allocates a server socket anew). E.g. my AFFI puts the burden and responsibility of opening and closing libraries on the programmer. But what I have to check is at what time the library is actually opened when loading a .lsp or .fas file for the first time: it may well be at load time, instead of call-time. This could be annoying?? That's a design issue which should be solved before implementing something. So far, the FFI doesn't provide means to explicitly control opening and closing of libraries under program control, since it puts this automation layer on top of it: IIRC, foreign_library() is being called at function declaration time (i.e. load time) instead of call time - which is no problem with statically linked functions. This could be changed of course. > Being able to implement callbacks to Lisp from C is also critical (I want to > be able to write a window procedure in Lisp). Indeed I didn't cover callbacks at all, as I have never tried them out in CLISP. I'm not even sure the callback/ subdirectory of ffcall/ existed in 1996. > excel = CreateObject('Excel.Application') > excel.LoadWorkbook('file.xls') > excel.Quit > > but while I could code the internals, I don't have the first clue about a > suitable "lisp-like" syntax for this. (CLOS is probably very relevant here). This syntax is typical with single dispatch OO, where you can consider methods as being attached to instances or classes, which is not the case with the CLOS - generic function approach. History and many OO systems often have seen (send excel 'LoadWorkBook "file.xls") for such things. CLOS would say (LoadWorkBook excel "file.xls") BTW, is case significant here? But at this stage, you're not discussing the FFI anymore but rather how to interact nicely in Lisp with some objects: you can design anything you wish and find useful. Regards, Jo"rg Ho"hle. From Paul.Moore@uk.origin-it.com Wed Sep 29 01:25:57 1999 Received: from gw-nl1.origin-it.com (gw-nl1.origin-it.com [193.79.128.34]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id BAA07741 for ; Wed, 29 Sep 1999 01:25:55 -0700 (PDT) Received: from mail.origin-it.com (localhost.origin-it.com [127.0.0.1]) by gw-nl1.origin-it.com with ESMTP id KAA28777 for ; Wed, 29 Sep 1999 10:38:47 +0200 (MEST) (envelope-from Paul.Moore@uk.origin-it.com) Received: from mail.origin-it.com(172.16.127.3) by gw-nl1.origin-it.com via mwrap (4.0a) id xma028772; Wed, 29 Sep 99 10:38:47 +0200 Received: from ukrax001.ras.uk.origin-it.com (ukrax001.ras.uk.origin-it.com [172.16.201.234]) by mail.origin-it.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id KAA26466 for ; Wed, 29 Sep 1999 10:38:46 +0200 (MET DST) Received: by ukrax001.ras.uk.origin-it.com with Internet Mail Service (5.5.2448.0) id ; Wed, 29 Sep 1999 09:38:45 +0100 Message-ID: <714DFA46B9BBD0119CD000805FC1F53BB4155F@UKRUX002.rundc.uk.origin-it.com> From: "Moore, Paul" To: "'clisp-list@seagull.cons.org'" Subject: RE: CLISP - DLL Interface Date: Wed, 29 Sep 1999 09:38:39 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" From: Joerg Hoehle [mailto:Joerg.Hoehle@gmd.de] > Another possibility would make heavy use of finalize *and* ensure that > finalizers get called when CLISP exists, which is currently > not the case. Oh. That's a pity - I'd think that finalizers should be called on CLISP exit, but that's a design issue with finalizers. > > Yet finalizers are not all the answer, e.g. in your excel > example below, the programmer probably would have to tell that this excel > object comes from a given .dll which therefore probably should not > disappear before the object goes away as well. No. The nice thing about COM (and automation) is that DLLs and applications are closed down automatically when the last reference to the server is released. So this case *requires* finalization in that when the Lisp reference to Excel goes away, the COM pointer needs to have Release() called on it. This takes care of all the gory details of unloading DLLs and closing down application servers, etc. > FFI calls being common or not is not directly related to > building an own .mem file (called image or core). Applications > ought to be written in such a way that they don't rely on CLISP > reopening libraries for them, and they rather reinitialize > themselves what is needed (like the httpd main function > allocates a server socket anew). E.g. my AFFI puts the burden and > responsibility of opening and closing libraries on the programmer. I disagree. Applications should be written to take advantage of whatever guarantees the language gives them. If CLISP does not guarantee that libraries are reopened, then certainly applications cannot rely on that. However, *whether* CLISP provides this guarantee is an important design issue with the FFI, as it determines how applications can (or should) be written, which directly impacts on the usability/usefulness of the FFI. > But what I have to check is at what time the library is > actually opened when loading a .lsp or .fas file for the > first time: it may well be at load time, instead of > call-time. This could be annoying?? > > That's a design issue which should be solved before implementing > something. The distinction between load and call time (and compile time?) is one of the Lisp subtleties that I'd need to actually *use* Lisp in some real cases before I'd be able to comment on properly... > > Being able to implement callbacks to Lisp from C is also > > critical (I want to be able to write a window procedure in Lisp). > > Indeed I didn't cover callbacks at all, as I have never tried > them out in CLISP. I'm not even sure the callback/ subdirectory of > ffcall/ existed in 1996. There's plenty that can be done without callbacks, but there are some important API functions which rely on them. The lack of a straightforward way of writing C extensions means that if they aren't in the FFI, they probably won't be available at all. I'd rather an implementation with no callbacks than no implementation at all. > > excel = CreateObject('Excel.Application') > > excel.LoadWorkbook('file.xls') > > excel.Quit > > > > but while I could code the internals, I don't have the > > first clue about a suitable "lisp-like" syntax for this. > > (CLOS is probably very relevant here). > > This syntax is typical with single dispatch OO, where you can consider > methods as being attached to instances or classes, which is > not the case with the CLOS - generic function approach. History and many > OO systems often have seen > (send excel 'LoadWorkBook "file.xls") > for such things. CLOS would say > (LoadWorkBook excel "file.xls") > BTW, is case significant here? That looks fair enough. IIRC, case is significant for the method lookups (ie, when I ask the excel object for a pointer to its LoadWorkBook method, I need to get the case right), but not for calls (ie, there are no real cases where two methods have names which differ only in case). Visual Basic is not case-sensitive, so by design OLE Automation can't be... > But at this stage, you're not discussing the FFI anymore but > rather how to interact nicely in Lisp with some objects: you > can design anything you wish and find useful. Actually, I'd say that an OLE Automation interface is a "thick" FFI binding to the most useful areas of FFI functionality in Windows. It's possible to do (a lot of) useful work in a language with an Automation interface but no low-level FFI (witness JScript, VBScript, ...) However, it's fairly hard to layer an Automation interface solely on top of a low-level FFI, and a language with a FFI but no Automation support is quite nasty to program in (witness C - OLE programming in C is a horrible job!) So in my view, an Automation interface would make CLISP a serious proposition on Windows. A low-level FFI would offer complete OS access, but would leave people spending time trying to write Automation interfaces using the FFI, rather than being able to do real work. But both of them constitute what is required of "FFI access" under Windows (in different problem domains). Hope this discussion is of use, Paul. From hoehle@mmkmail.gmd.de Wed Sep 29 02:00:41 1999 Received: from mail.gmd.de (mail.gmd.de [129.26.8.90]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id CAA08269 for ; Wed, 29 Sep 1999 02:00:29 -0700 (PDT) Received: from zeus.gmd.de (zeus.gmd.de [129.26.165.1]) by mail.gmd.de (8.8.8/8.8.8) with ESMTP id LAA04337 for ; Wed, 29 Sep 1999 11:12:34 +0200 (MET DST) Received: from localhost (hoehle@localhost) by zeus.gmd.de (8.9.1/8.9.3) with SMTP id LAA23452 for ; Wed, 29 Sep 1999 11:12:33 +0200 (MET DST) X-Authentication-Warning: zeus.gmd.de: hoehle owned process doing -bs Date: Wed, 29 Sep 1999 11:12:33 +0200 (MET DST) From: Joerg Hoehle X-Sender: hoehle@zeus To: clisp-list@clisp.cons.org Subject: RE: CLISP - DLL Interface In-Reply-To: <14321.922.852874.548562@santorini> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Tue, 28 Sep 1999, Don Cohen wrote: > Supply user level functions for opening and closing libraries. > Defining a function should probably look it up just so you can get an > error if it's not there. The lookup result should be cached for later DEF-LIB-CALL-OUT looks declarative, yet it has side effects outside of CLISP. That means that the library must have been opened either by the programmer or automatically before the definition is processed (since you can only get an address once its opened). Are you be willing to accept the latter? The effect currently is that libraries will be opened by loading .lsp or .fas files, i.e. while loading a system, that is, before this system is fully initialized (e.g. MAIN has not been called yet since we are still in the load phase). BTW, are all .dll in one (or several) system directories, or is it possible to require a .dll from a specific directory? > calls. Calling a function should, if the cache is not filled, also > look it up and fill the cache, giving an error if it cannot be found So that's in effect late binding. > Closing a library should decache all functions that were found in that > library. > > As for saving images with libraries loaded, I recommend that the save > effectively unload all the libraries, which means decache all the functions. > Then on restart you try to reopen the libraries. I'd rather find out > at startup about missing libraries than later when the functions are > called. So the cache would only be empty when starting from an image with former functions, since declaring a function in a bare CLISP will immediately check it and thus fill the cache? That is, you advocate immediate binding when declaring functions but late binding when resurrecting them from an image? And also late binding when calling a function from a library that was closed intermittently in the same session? Well, nothing impossible. a validate_faddress() is needed, similar to validate_fpointer(), or better some validate_ffunction() that has access to the function name so the address can be restored. It's merely a little bit more complicate than on AmigaOS where validity of the library gives immediate validity to all functions, since they are related through a constant offset. Review: Opening libraries under program control is currently possible in the Amiga version of the FFI, but undocumented: (FFI::foreign-library name &optional version) does the job. Would this be enough for MS-* as well? Then DEF-LIB-CALL-OUT opens the library if it hasn't been opened anyway and immediately checks for the existance of the function. Afterwards, closing the library is not yet possible but automatic when CLISP exists. Part of the effect of closing the library would be achieved if (SETF VALIDP) would exist, as on AmigaOS this would invalidate the library base and thus all functions derived from it. On MS-* this would be somewhat more complex. The other half of the effect would be achieved by using the FFI itself to call FreeLibrary(), if the FFI were able to accept the object returned by FFI::FOREIGN-LIBRARY as argument (currently a simple FOREIGN-POINTER on AmigaOS so this should work for me). In the past, I had already thought that it would be nice if the following were possible from within Lisp instead of C code (glue or wrappers): (def-foreign-resource library ... ... ;; /* done with it */ call declared finalizer (e.g. FreeLibrary) on object mark_fp_invalid(TheFpointer(obj)) ) The finalizer call + mark invalid is a pattern that's not found in the FFI (and my AFFI doesn't provide it either). Then you'd do something like (def-foreign-resource window (:initalize (ffi-foreign-function (OpenWindow &optional args))) ;; not only by GC but also at program exit (:finalize (ffi-foreign-function 'CloseWindow))) and (SETF (VALIDP obj) nil) would be managed as well. Sometimes I think I should hit the bones and use the internal CLISP record accessors to provide the missing functionality until it's made available properly, so it's maybe possible to supply NON-NULL-POINTER? and (setf validp) now already by going directly to the slots?? Regards, Jo"rg Ho"hle. Joerg.Hoehle@gmd.de http://fit.gmd.de/~hoehle/amiga.html From emarsden@laas.fr Wed Sep 29 02:11:56 1999 Received: from laas.laas.fr (root@laas.laas.fr [140.93.0.15]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id CAA08580 for ; Wed, 29 Sep 1999 02:11:54 -0700 (PDT) Received: from dukas.laas.fr (dukas [140.93.21.58]) by laas.laas.fr (8.9.3/8.9.3) with ESMTP id LAA04050 for ; Wed, 29 Sep 1999 11:24:38 +0200 (MET DST) Received: (from emarsden@localhost) by dukas.laas.fr (8.9.3/8.9.3) id LAA23083; Wed, 29 Sep 1999 11:24:37 +0200 (MET DST) To: clisp-list@seagull.cons.org Subject: Re: CLISP - DLL Interface References: Organization: LAAS-CNRS http://www.laas.fr/ MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Eric-Conspiracy: there is no conspiracy X-Attribution: ecm X-URL: http://www.chez.com/emarsden/ From: Eric Marsden Date: 29 Sep 1999 11:24:37 +0200 In-Reply-To: Joerg Hoehle's message of "Wed, 29 Sep 1999 02:01:17 -0700 (PDT)" Message-ID: Lines: 56 X-Mailer: Gnus v5.7/Emacs 20.4 >>>>> "jh" == Joerg Hoehle writes: jh> The effect currently is that libraries will be opened by loading jh> .lsp or .fas files, i.e. while loading a system, that is, before jh> this system is fully initialized (e.g. MAIN has not been called jh> yet since we are still in the load phase). I did this differently in the attempt I made at dynamic linking for linux: each external call started by checking whether the library had been loaded and the symbol resolved, before calling the function. Perhaps the overhead of such an approach is a little high. (defvar *loaded-libraries* (make-hash-table :test #'equal)) (defvar *loaded-symbols* (make-hash-table :test #'equal)) (defun ensure-library (library-name) (let ((lib (gethash library-name *loaded-libraries*))) (unless lib (setq lib (dli::dlopen library-name dli::RTLD_LAZY)) (let ((err (dli::dlerror))) (if err (error "dlopen: ~s" err))) (setf (gethash library-name *loaded-libraries*) lib)) (or lib (error "Couldn't load the library ~s" library-name)))) (defun ensure-symbol (library function-name) (let ((sym (gethash function-name *loaded-symbols*))) (unless sym (setq sym (dli::dlsym library function-name)) (let ((err (dli::dlerror))) (if err (error "dlsym: ~s" err))) (setf (gethash function-name *loaded-symbols*) sym)) (or sym (error "Couldn't find the symbol ~s in library ~s" function-name library)))) (defmacro defexternal (name param-list &key return-type entry-name (library-name "libc.so")) (let* ((return-func (get-returner return-type)) (arg-names (mapcar #'first param-list)) (arg-types (mapcar #'second param-list)) (push-defs (loop for type in arg-types for arg in arg-names and push-func = (get-pusher type) collect `(,push-func ,arg)))) (unless entry-name (setq entry-name (symbol-name name))) `(PROGN ;; EVAL-WHEN (COMPILER::COMPILE-ONCE-ONLY) (DEFUN ,name (,@arg-names) (LET* ((lib (dl::ensure-library ,library-name)) (sym (dl::ensure-symbol lib ,entry-name))) (dli::init-external-call) ,@push-defs (,return-func sym)))))) -- Eric Marsden It's elephants all the way down From hoehle@mmkmail.gmd.de Wed Sep 29 02:33:49 1999 Received: from mail.gmd.de (mail.gmd.de [129.26.8.90]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id CAA08933 for ; Wed, 29 Sep 1999 02:33:46 -0700 (PDT) Received: from zeus.gmd.de (zeus.gmd.de [129.26.165.1]) by mail.gmd.de (8.8.8/8.8.8) with ESMTP id LAA07613 for ; Wed, 29 Sep 1999 11:46:28 +0200 (MET DST) Received: from localhost (hoehle@localhost) by zeus.gmd.de (8.9.1/8.9.3) with SMTP id LAA24119 for ; Wed, 29 Sep 1999 11:46:27 +0200 (MET DST) X-Authentication-Warning: zeus.gmd.de: hoehle owned process doing -bs Date: Wed, 29 Sep 1999 11:46:27 +0200 (MET DST) From: Joerg Hoehle X-Sender: hoehle@zeus To: clisp-list@seagull.cons.org Subject: RE: CLISP - DLL Interface In-Reply-To: <714DFA46B9BBD0119CD000805FC1F53BB4155F@UKRUX002.rundc.uk.origin-it.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 29 Sep 1999, Moore, Paul wrote: > reference to Excel goes away, the COM pointer needs to have Release() called > on it. This takes care of all the gory details of unloading DLLs and closing > down application servers, etc. I think it takes care of .dll that were opened indirectly by the object only, not those opened directly by you, which could be few (e.g. just OLE.dll). BTW, why did you call excel.Quit in your example if Release() must be called? Several layers? Could you please elaborate? > However, *whether* CLISP provides this guarantee is an important design > issue with the FFI, as it determines how applications can (or should) be Yes. > written, which directly impacts on the usability/usefulness of the FFI. I don't see such a strong influence on the usefulness, as opening libraries is a tiny part of using them. E.g., C compilers on AmigaOS provide so called autoinit and autoexits which will automatically open shared libraries even before main() is invoked -- it suffices to leave the library base undefined: extern struct Library * RegexpBase; Some like it and use it, some don't and prefer to stay in control. > There's plenty that can be done without callbacks, but there are some > important API functions which rely on them. The lack of a straightforward Callbacks are in FFI newer than 1996 so I'm confident there's also a way to make these work in a dynamic context (without glue code and stubs). > > > excel = CreateObject('Excel.Application') > > > excel.LoadWorkbook('file.xls') > > > excel.Quit > That looks fair enough. IIRC, case is significant for the method lookups > (ie, when I ask the excel object for a pointer to its LoadWorkBook method, I Does that mean that you need to call functions at arbitrary addresses, not constant for the class of the object? I.e. to call LoadWorkBook on excel and excel2, you need to jump to different addresses? In other words, you need to dispatch yourself instead of using a generic interface from MS-* sort like OLE_invoke_upon(excel,"LoadWorkBook","file.xls") or LoadWorkBook(excel,"file.xls"), where LoadWorkBook would also be appliable to excel2? That would have a major impact on the FFI (require more dynamism), since many more functions would need to be created than for e.g. the 5000 known interface functions directly found in libraries. In such a case I wouldn't make functions first class objects as is currently required (where you need to create such an object first before being able to invoke it), but rather provide a mechanism to call an arbitrary foreign function on the fly (like I did in the AFFI: (mlibcall LoadWorkBook excel "file.xls")). > need to get the case right), but not for calls (ie, there are no real cases > where two methods have names which differ only in case). Visual Basic is not > case-sensitive, so by design OLE Automation can't be... That just means that you can comfortably use Lisp symbols to refer to them -- once they have been declared using strings for the case. > Hope this discussion is of use, Do you think you're wasting your time? Regards, Jo"rg Ho"hle. http://fit.gmd.de/~hoehle/amiga-clisp.html From hoehle@mmkmail.gmd.de Wed Sep 29 03:40:06 1999 Received: from mail.gmd.de (mail.gmd.de [129.26.8.90]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id DAA09619 for ; Wed, 29 Sep 1999 03:39:39 -0700 (PDT) Received: from zeus.gmd.de (zeus.gmd.de [129.26.165.1]) by mail.gmd.de (8.8.8/8.8.8) with ESMTP id MAA01438 for ; Wed, 29 Sep 1999 12:52:04 +0200 (MET DST) Received: from localhost (hoehle@localhost) by zeus.gmd.de (8.9.1/8.9.3) with SMTP id MAA25293 for ; Wed, 29 Sep 1999 12:52:04 +0200 (MET DST) X-Authentication-Warning: zeus.gmd.de: hoehle owned process doing -bs Date: Wed, 29 Sep 1999 12:52:03 +0200 (MET DST) From: Joerg Hoehle X-Sender: hoehle@zeus To: clisp-list@seagull.cons.org Subject: Re: CLISP - DLL Interface In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 29 Sep 1999, Eric Marsden wrote: > I did this differently in the attempt I made at dynamic linking for > linux: each external call started by checking whether the library had > been loaded and the symbol resolved, before calling the function. > Perhaps the overhead of such an approach is a little high. > (dli::init-external-call) > ,@push-defs > (,return-func sym)))))) I see. You don't make first class foreign function objects but provide a mechanism to call arbitrary foreign functions, like the AFFI does. This mechanism can then control such details like late opening of libraries (which the AFFI does not, but at this level it is just a question of additional interface functions or macros). With first class foreign function objects, you need to put the functionality in the lower level (the representation of the object), thus you have to decide there (in C code) what to do. If you want to open libraries at call time, then obviously some sort of validate_foreign_function() is needed that has access to the Ffunction object which contains the name and the library. Well, maybe this is not a question of first class or not but rather of the granularity of the interface. The more generic a function based interface is, the more one can extend it in ways other people didn't think of first. Being able to call a function at an arbitrary address is the most generic you get, and this is in essence what the AFFI and your dli::init-external-call and return-func manage. The FFI provides a less generic interface. FFI::FOREIGN-CALL-OUT is how you finally call something but its usefulness is limited in that you must supply a FOREIGN-FUNCTION object, and the ways to obtain such an object are limited by the FFI: this is sad. E.g. FFI::FOREIGN-LIBRARY-FUNCTION is specific so far to AmigaOS and used by DEF-LIB-CALL-OUT. Another creator is only called via glue code. Maybe the easiest way to create a FOREIGN-FUNCTION object for an arbitrary address under the current FFI (so you don't have to wait until another design is finalized and released) is to have a C identity function declared as returning the appropriate function return type, CLISP will then build a foreign function object upon return. Then you just need to be able to initially call that C identity function. Maybe by using a callback on the built-in IDENTITY?? You see that's complicated but my experience is indeed that advanced interfaces (esp. macro based) actually limit the programmers freedom to extend functionality in unexpected ways. But all of this won't be necessary the day we settle on a useable design for dynamic foreign calls for AmigaOS, MS-* and UNIX within the FFI. Regards, Jo"rg Ho"hle. http://fit.gmd.de/~hoehle/amiga.html From Paul.Moore@uk.origin-it.com Wed Sep 29 03:52:20 1999 Received: from gw-nl1.origin-it.com (gw-nl1.origin-it.com [193.79.128.34]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id DAA09932 for ; Wed, 29 Sep 1999 03:52:19 -0700 (PDT) Received: from mail.origin-it.com (localhost.origin-it.com [127.0.0.1]) by gw-nl1.origin-it.com with ESMTP id NAA29301 for ; Wed, 29 Sep 1999 13:05:10 +0200 (MEST) (envelope-from Paul.Moore@uk.origin-it.com) Received: from mail.origin-it.com(172.16.127.3) by gw-nl1.origin-it.com via mwrap (4.0a) id xma029299; Wed, 29 Sep 99 13:05:10 +0200 Received: from ukrax001.ras.uk.origin-it.com (ukrax001.ras.uk.origin-it.com [172.16.201.234]) by mail.origin-it.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id NAA28851 for ; Wed, 29 Sep 1999 13:05:09 +0200 (MET DST) Received: by ukrax001.ras.uk.origin-it.com with Internet Mail Service (5.5.2448.0) id ; Wed, 29 Sep 1999 12:05:01 +0100 Message-ID: <714DFA46B9BBD0119CD000805FC1F53BB41561@UKRUX002.rundc.uk.origin-it.com> From: "Moore, Paul" To: "'clisp-list@seagull.cons.org'" Subject: RE: CLISP - DLL Interface Date: Wed, 29 Sep 1999 12:05:07 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" From: Joerg Hoehle [mailto:Joerg.Hoehle@gmd.de] > I think it takes care of .dll that were opened indirectly by > the object only, not those opened directly by you, which > could be few (e.g. just OLE.dll). I'm assuming that the built-in code which provides the automation interface (whether written in CLISP or in C) provides this functionality. I'm writing from the point of view of an automation *user* not an implementer here. But you're right, the automation implementation needs to manage loading and unloading of the COM DLLs. > BTW, why did you call excel.Quit in your example if Release() must be > called? Several layers? Could you please elaborate? Basically, because I couldn't remember precisely what Excel does if you release the last interface pointer to it without unloading all spreadheets, etc etc. Again, Quit is the automation user level "I've finished" command. At this point, the underlying COM code has not got rid of the Excel pointer (and theoretically, could call further methods on it). The low-level pxl->Release() reference counting call is inside the gory internals of the automation implementation. > Does that mean that you need to call functions at arbitrary > addresses, not constant for the class of the object? I.e. to > call LoadWorkBook on excel and excel2, you need to jump to > different addresses? > > In other words, you need to dispatch yourself instead of > using a generic interface from MS-* sort like > OLE_invoke_upon(excel,"LoadWorkBook","file.xls") or > LoadWorkBook(excel,"file.xls"), where LoadWorkBook would also > be appliable to excel2? OK, gory details time. All of this can be built on top of ffcall's avcall() function, one way or another. It's just a matter of getting an address. Given: a COM pointer, IExcelApplication *xl, to an already-created instance of Excel (I'll discuss how you get this later), the process of calling a method, say Load("file.xls"), goes as follows: [Can I do this in C++, please - the transformations to C are trivial but messy...] IWorkbook *wb = NULL; OLECHAR *names[] = { "Load"L }; DISPID ids[1]; LCID locale = /* The user's current locale */; HRESULT hr = xl->GetIDsOfNames(IID_NULL, names, 1, locale, ids); if (SUCCEEDED(hr)) { VARIANT arg; DISPPARAMS args = { &arg, 0, 1, 0 }; VARIANT result; EXCEPINFO err; int err_id; VariantInit(arg); arg.vt = VT_BSTR; arg.bstrVal = SysAllocString("file.xls"L); hr = xl->Invoke(ids[0], IID_NULL, locale, DISPATCH_METHOD, &args, &result, &err, &err_id); VariantClear(arg); if (SUCCEEDED(hr)) wb = result.ppdispVal; } You can probably see why I'd want this implemented in a library... (and for multiple arguments, proper error handling, etc, you'd need more complex code!) BTW, you see that GetIDsOfNames() call? That's the point where we find out if a method exists on the pointer. How would CLOS cope with something like (ArgleBargle comptr ...) where we cannot know if ArgleBargle is a valid function to call unless we *ask* comptr (at runtime, presumably, as that's the first time we have a valid comptr). But the returned DISPID is valid for the lifetime of the program, so we can cache it. OTOH, given 2 IDispatch pointers, p1 and p2, there is no way (short of doing the queries) of knowing that they support the same methods. This is IDispatch late binding, by the way. There is also early binding, which is far more efficient, and far simpler at runtime. But it requires type information (declaring a COM pointer as an instance of a particular COM type) at application compile time - how would you do this in CLISP? I'm thinking of the equivalent of Visual Basic's Dim xl as Excel.Application where xl is going to be an Excel pointer (but it hasn't been initialised yet - this is compile time), and "Excel.Application" is effectively a type name which must be dynamically looked up using COM calls. To get that initial Excel pointer you need something like: CoInitializeEx(...); /* once per process, before any COM calls */ IExcelApplication *xl = NULL; REFCLSID excel = CLSIDfromProgID("Excel.Application"L); HRESULT hr = CoCreateInstance(excel, 0, IID_IDISPATCH, (void**)(&xl)); if (FAILED(hr)) /* Error... */ /* ... we can now use xl, for instance as above ... */ xl->Release(); /* Once we have finished with xl */ CoUninitialize(); /* At end of process, no COM calls after this */ Again, the bookkeeping is very messy, but manageable. And it cries out for encapsulation once and for all. > That would have a major impact on the FFI (require more > dynamism), since many more functions would need to be created than for e.g. > the 5000 known interface functions directly found in libraries. Yes. You couldn't pre-create Automation methods - they'd have to be created on demand - either at compile time with early binding, or at runtime with late binding. > In such a case I wouldn't make functions first class objects as is > currently required (where you need to create such an object > first before being able to invoke it), but rather provide a mechanism > to call an arbitrary foreign function on the fly (like I did in the AFFI: > (mlibcall LoadWorkBook excel "file.xls")). You start to lose the simplicity of use which is (probaly) critical if all of this is to be worth it. You haven't gone too far yet, but remember that you are competing in many ways with the simplicity of VB: xl.Load "File.xls" JScript: xl.Load("File.xls"); Perl: $xl->Load("File.xls"); Haskell: xl # Load "File.xls" Python: xl.Load("File.xls") I'd like to see something Lisp-ish like (Load xl "File.xls") or at worst (send xl "Load" "File.xls") [but I could see writing send all the time becoming tedious...] Any scope for macro magic here? > > Hope this discussion is of use, > Do you think you're wasting your time? Definitely not, although I think we're still missing someone who can actually *implement* the CLISP end of this (or are you willing to do so - I got the impression that you don't have access to a Win32 compiler). Paul. From Paul.Moore@uk.origin-it.com Wed Sep 29 04:04:15 1999 Received: from gw-nl1.origin-it.com (gw-nl1.origin-it.com [193.79.128.34]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id EAA10244 for ; Wed, 29 Sep 1999 04:04:14 -0700 (PDT) Received: from mail.origin-it.com (localhost.origin-it.com [127.0.0.1]) by gw-nl1.origin-it.com with ESMTP id NAA03765 for ; Wed, 29 Sep 1999 13:17:04 +0200 (MEST) (envelope-from Paul.Moore@uk.origin-it.com) Received: from mail.origin-it.com(172.16.127.3) by gw-nl1.origin-it.com via mwrap (4.0a) id xma003763; Wed, 29 Sep 99 13:17:04 +0200 Received: from ukrax001.ras.uk.origin-it.com (ukrax001.ras.uk.origin-it.com [172.16.201.234]) by mail.origin-it.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id NAA01532 for ; Wed, 29 Sep 1999 13:17:02 +0200 (MET DST) Received: by ukrax001.ras.uk.origin-it.com with Internet Mail Service (5.5.2448.0) id ; Wed, 29 Sep 1999 12:16:55 +0100 Message-ID: <714DFA46B9BBD0119CD000805FC1F53BB41562@UKRUX002.rundc.uk.origin-it.com> From: "Moore, Paul" To: "'clisp-list@seagull.cons.org'" Subject: RE: CLISP - DLL Interface Date: Wed, 29 Sep 1999 12:17:02 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" From: Joerg Hoehle [mailto:Joerg.Hoehle@gmd.de] > On Wed, 29 Sep 1999, Eric Marsden wrote: > > I did this differently in the attempt I made at dynamic linking for > > linux: [...] > Well, maybe this is not a question of first class or not but > rather of the granularity of the interface. The more generic a function > based interface is, the more one can extend it in ways other people didn't > think of first. Agreed > Being able to call a function at an arbitrary address is the > most generic you get, This is exactly true, and is the most critical piece of missing functionality. > You see that's complicated but my experience is indeed that advanced > interfaces (esp. macro based) actually limit the programmers > freedom to extend functionality in unexpected ways. If all there is, is the advanced interface, I'd agree. But on the other hand, providing *only* a low-level interface, and expecting the programmer to build his own higher-level abstractions every time, is nearly as bad. We need a layered approach. The lowest level must be both well-defined and solid. Higher-levels can be focussed, and can omit certain areas in exchange for convenience. Higher levels can also afford to be platform specific. But I don't think it's enough to build all the layers in Lisp. You have to accept that there may be higher-level interfaces, with all the provisos above, which are *still* better written in C. > But all of this won't be necessary the day we settle on a > useable design for dynamic foreign calls for AmigaOS, MS-* and > UNIX within the FFI. I agree - that must be the first step. My messages on OLE and COM are very much an aside, in the sense that getting the "call an arbitrary address" (and preferably also "make a callable address from a Lisp function") interface is priority 1, by a long way. But I don't want to see things stop at that level, with some sort of implied "you can do the rest yourself in Lisp". That way lies Scheme, not Common Lisp. [BTW, some of the Scheme implementations - MzScheme being one, I think - have OLE interfaces on Win32. Maybe we can learn from them]. Paul. From hoehle@mmkmail.gmd.de Wed Sep 29 04:17:14 1999 Received: from mail.gmd.de (mail.gmd.de [129.26.8.90]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id EAA10593 for ; Wed, 29 Sep 1999 04:17:03 -0700 (PDT) Received: from zeus.gmd.de (zeus.gmd.de [129.26.165.1]) by mail.gmd.de (8.8.8/8.8.8) with ESMTP id NAA18438 for ; Wed, 29 Sep 1999 13:29:45 +0200 (MET DST) Received: from localhost (hoehle@localhost) by zeus.gmd.de (8.9.1/8.9.3) with SMTP id NAA25581 for ; Wed, 29 Sep 1999 13:29:44 +0200 (MET DST) X-Authentication-Warning: zeus.gmd.de: hoehle owned process doing -bs Date: Wed, 29 Sep 1999 13:29:43 +0200 (MET DST) From: Joerg Hoehle X-Sender: hoehle@zeus To: clisp-list@seagull.cons.org Subject: RE: CLISP - DLL Interface: other systems OLE interfaces? In-Reply-To: <714DFA46B9BBD0119CD000805FC1F53BB41562@UKRUX002.rundc.uk.origin-it.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 29 Sep 1999, Moore, Paul wrote: > Lisp. [BTW, some of the Scheme implementations - MzScheme being one, I think > - have OLE interfaces on Win32. Maybe we can learn from them]. I was going to ask if somebody wih knowledge of other Lispish systems could post in an understanable form what their interfaces look like. Corman Common Lisp may also include such a thing since AFAIK it specifically targets MS-*. Every CL already has differing FFIs, it would be nice for the MS-* users if the access to .dll or OLE functionality would not differ that much. Thanks for any enlightment, Jo"rg Ho"hle. http://fit.gmd.de/~hoehle/amiga.html From hoehle@mmkmail.gmd.de Wed Sep 29 05:31:52 1999 Received: from mail.gmd.de (mail.gmd.de [129.26.8.90]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id FAA11460 for ; Wed, 29 Sep 1999 05:31:41 -0700 (PDT) Received: from zeus.gmd.de (zeus.gmd.de [129.26.165.1]) by mail.gmd.de (8.8.8/8.8.8) with ESMTP id OAA25577 for ; Wed, 29 Sep 1999 14:44:20 +0200 (MET DST) Received: from localhost (hoehle@localhost) by zeus.gmd.de (8.9.1/8.9.3) with SMTP id OAA26980 for ; Wed, 29 Sep 1999 14:44:17 +0200 (MET DST) X-Authentication-Warning: zeus.gmd.de: hoehle owned process doing -bs Date: Wed, 29 Sep 1999 14:44:17 +0200 (MET DST) From: Joerg Hoehle X-Sender: hoehle@zeus To: clisp-list@seagull.cons.org Subject: RE: CLISP - DLL Interface In-Reply-To: <714DFA46B9BBD0119CD000805FC1F53BB41561@UKRUX002.rundc.uk.origin-it.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 29 Sep 1999, Moore, Paul wrote: > OK, gory details time. All of this can be built on top of ffcall's avcall() Thanks, that looked really awful :-) > function, one way or another. It's just a matter of getting an address. Which, as explained in a later message of mine, the FFI currently doesn't allow you arbitrarily. > if a method exists on the pointer. How would CLOS cope with something like > (ArgleBargle comptr ...) where we cannot know if ArgleBargle is a valid > function to call unless we *ask* comptr (at runtime, presumably, as that's > the first time we have a valid comptr). In Smalltalk they'd add an exception handler for MethodNotImplemented and would get back the method name and arguments, then try to locate it (or send it away via CORBA or whatever). In Common Lisp, an error handler for such a case could be devised as well (but implementation dependent, since I don't know of a condition named undefined-function-error). But in Common Lisp, I'm not sure you really want to use (Load excel "file.xls") because of name conflicts with non-generic functions like the existing LOAD. So some read-macrology might help here and you'd type (#!Load excel "file.xls") or some such (which internally would expand to (OLE/COM-call 'Load excel "file.xls") or (OLE/COM-call (OLE-description :name "Load" . argument-types) excel "file.xls") or whatever. Another syntax: typical Schemes use object == closure, so you'd get (funcall excel 'Load "file.xls") in CL. It's time to see what other implementations do. BTW, with the call being wholly dynamic, who does type checking? Let's say you'd write SysAllocInt(4) instead of SysAllocString() and try to execute xl.Load(4). Does the arg structure contain tags like Lisp systems do? Is there always a simple mapping from Lisp objects to OLE argument types so that a Lisp side description of the arguments would not be needed? This is not easy, even with integers: consider the current discussion in comp.lang.lisp about mapping 256 and -1. > This is IDispatch late binding, by the way. There is also early binding, > which is far more efficient, and far simpler at runtime. But it requires > type information (declaring a COM pointer as an instance of a particular COM > type) at application compile time - how would you do this in CLISP? I'm Possible in theory, but you'd have to be to be more explicit about what exactly could be fixed at compile time, since I don't know whether you're talking here about C++ tricks (e.g. whether sysAllocString() could be allocated on the stack instead or whatever could be fixed at compile time instead of run-time). But then, don't waste too much time explaining this level of details to me who's not knowledgeable with COM/OLE and MS-* interprocess communication anyway. > Yes. You couldn't pre-create Automation methods - they'd have to be created > on demand - either at compile time with early binding, or at runtime with > late binding. Same here about compile time. > Definitely not, although I think we're still missing someone who can Yes. My thread was a call for such a person. I'd wish to add that I have the feeling that this person wouldn't need to get to deep into CLISP internals -- only manage to compile it on a MS-* platform -- and be scared away by the size of the source, the nesting of macros and the german comments. There are nice people here who can explain all these details. What's missing IMHO is not another level of CLISP details in the source code, but rather a level of MS-* API details added to the source code. > actually *implement* the CLISP end of this (or are you willing to do so - I > got the impression that you don't have access to a Win32 compiler). I simply don't qualify as I also have zero knowledge about MS-* programmer internals: somebody with experience in compiling and debugging programs with MS-* and doing a little bit of OLE/COM should do that. Regards, Jo"rg Ho"hle. From Paul.Moore@uk.origin-it.com Wed Sep 29 05:34:34 1999 Received: from gw-nl1.origin-it.com (gw-nl1.origin-it.com [193.79.128.34]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id FAA11636 for ; Wed, 29 Sep 1999 05:34:33 -0700 (PDT) Received: from mail.origin-it.com (localhost.origin-it.com [127.0.0.1]) by gw-nl1.origin-it.com with ESMTP id OAA09873 for ; Wed, 29 Sep 1999 14:47:21 +0200 (MEST) (envelope-from Paul.Moore@uk.origin-it.com) Received: from mail.origin-it.com(172.16.127.3) by gw-nl1.origin-it.com via mwrap (4.0a) id xma009869; Wed, 29 Sep 99 14:47:22 +0200 Received: from ukrax001.ras.uk.origin-it.com (ukrax001.ras.uk.origin-it.com [172.16.201.234]) by mail.origin-it.com (8.9.3/8.8.5-1.2.2m-19990317) with ESMTP id OAA24147 for ; Wed, 29 Sep 1999 14:47:20 +0200 (MET DST) Received: by ukrax001.ras.uk.origin-it.com with Internet Mail Service (5.5.2448.0) id ; Wed, 29 Sep 1999 13:47:19 +0100 Message-ID: <714DFA46B9BBD0119CD000805FC1F53BB41564@UKRUX002.rundc.uk.origin-it.com> From: "Moore, Paul" To: "'clisp-list@seagull.cons.org'" Subject: RE: CLISP - DLL Interface: other systems OLE interfaces? Date: Wed, 29 Sep 1999 13:47:19 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" From: Joerg Hoehle [mailto:Joerg.Hoehle@gmd.de] > I was going to ask if somebody wih knowledge of other Lispish systems > could post in an understanable form what their interfaces look like. > Corman Common Lisp may also include such a thing since AFAIK it > specifically targets MS-*. MzScheme has an OLE interface called MysterX. Briefly, it uses constructs like (com-invoke a-com-object "Method" arg1 arg2 ...) (com-get-property a-com-object "Property") (com-set-property! a-com-object "Property" value) Basically, a variant on the (send obj method ...) approach. No (basic) FFI that I could find. I can't get at the Corman Lisp documentation just now, but from what I recall, (a) the interfaces are pretty complete and (b) the documentation isn't :-( I'll get the docs when I get home tonight, and see what I can distil. Paul. From prabakar@wipinfo.soft.net Thu Sep 30 05:17:17 1999 Received: from agni.wipinfo.soft.net (agni.wipinfo.soft.net [164.164.6.20]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id FAA25938 for ; Thu, 30 Sep 1999 05:17:14 -0700 (PDT) Received: from vayu.wipinfo.soft.net (vayu [192.168.200.170]) by agni.wipinfo.soft.net (8.9.3/8.9.3) with ESMTP id SAA11924 for ; Thu, 30 Sep 1999 18:00:51 +0500 (GMT) Received: from alcatel-gw.wipinfo.soft.net (root@alcatel-gw.wipinfo.soft.net [192.168.220.200]) by vayu.wipinfo.soft.net (8.9.3/8.9.3) with ESMTP id RAA05444 for ; Thu, 30 Sep 1999 17:59:53 +0500 (GMT) Received: from wipinfo.soft.net (prabakar@[192.168.221.93]) by alcatel-gw.wipinfo.soft.net (8.7.5/8.9.3) with ESMTP id SAA31926 for ; Thu, 30 Sep 1999 18:03:18 +0530 Sender: prabakar@wipinfo.soft.net Message-ID: <37F37C72.8C727628@wipinfo.soft.net> Date: Thu, 30 Sep 1999 20:36:27 +0530 From: Prabakar Venkataraman Organization: Wipro X-Mailer: Mozilla 4.03 [en] (X11; I; Linux 2.0.36 i686) MIME-Version: 1.0 To: clisp-list@seagull.cons.org Subject: Sockets Query Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit *, Are there socket implementations of Harlequin CommonLisp ? Could you please give me pointers to it ? -Prabu. From hoehle@mmkmail.gmd.de Thu Sep 30 07:26:04 1999 Received: from mail.gmd.de (mail.gmd.de [129.26.8.90]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id HAA27174 for ; Thu, 30 Sep 1999 07:25:10 -0700 (PDT) Received: from zeus.gmd.de (zeus.gmd.de [129.26.165.1]) by mail.gmd.de (8.8.8/8.8.8) with ESMTP id QAA24832 for ; Thu, 30 Sep 1999 16:37:43 +0200 (MET DST) Received: from localhost (hoehle@localhost) by zeus.gmd.de (8.9.1/8.9.3) with SMTP id QAA10301 for ; Thu, 30 Sep 1999 16:37:40 +0200 (MET DST) X-Authentication-Warning: zeus.gmd.de: hoehle owned process doing -bs Date: Thu, 30 Sep 1999 16:37:40 +0200 (MET DST) From: Joerg Hoehle X-Sender: hoehle@zeus To: clisp-list@seagull.cons.org Subject: CLISP - DLL Interface: calling convention (not (= OLE DLL)? In-Reply-To: <714DFA46B9BBD0119CD000805FC1F53BB41561@UKRUX002.rundc.uk.origin-it.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 29 Sep 1999, Moore, Paul wrote: > OK, gory details time. > Given: a COM pointer, IExcelApplication *xl, to an already-created instance > HRESULT hr = xl->GetIDsOfNames(IID_NULL, names, 1, locale, ids); > DISPPARAMS args = { &arg, 0, 1, 0 }; > VARIANT result; > EXCEPINFO err; > arg.bstrVal = SysAllocString("file.xls"L); This seems to imply that in fact two mechanisms are needed, one for making regular DLL calls, and another one for calling OLE/COM objects? Or is argument passing, exception handling and getting return values always the same, and it's just xl->Invoke(...) which is specific to OLE/COM? A possible approach using most of the current FFI would be to consider every COM object as a library of functions (and maybe variables), so method calls could be derived from each such library. That's similar to the "object is dictionary" approach which one could image below Smalltalk or Python. > You start to lose the simplicity of use which is (probaly) critical if all > of this is to be worth it. You haven't gone too far yet, but remember that > you are competing in many ways with the simplicity of > > VB: xl.Load "File.xls" > JScript: xl.Load("File.xls"); > Perl: $xl->Load("File.xls"); > Haskell: xl # Load "File.xls" > Python: xl.Load("File.xls") I don't think the competition is on syntax. I believe the application is more than just manipulating OLE objects which is a facility provided by many implementations, as you show. The programming language used to glue all these objects can still make a difference. Regards, Jo"rg Ho"hle. From Klaus.Schilling@munich.netsurf.de Thu Sep 30 07:57:15 1999 Received: from laurin.munich.netsurf.de (laurin.munich.netsurf.de [194.64.166.1]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id HAA27695 for ; Thu, 30 Sep 1999 07:57:14 -0700 (PDT) Received: from debian (root@ns1038.munich.netsurf.de [195.180.235.38]) by laurin.munich.netsurf.de (8.9.3/8.9.3) with ESMTP id RAA28067 for ; Thu, 30 Sep 1999 17:10:12 +0200 (MET DST) Received: by debian via sendmail from stdin id (Debian Smail3.2.0.102) for clisp-list@seagull.cons.org; Fri, 1 Oct 1999 00:02:33 +0200 (CEST) Message-Id: Date: Fri, 1 Oct 1999 00:02:33 +0200 (CEST) From: Klaus Schilling To: clisp-list@seagull.cons.org Subject: ILU or ORBit for Clisp Reply-to: Klaus.Schilling@munich.netsurf.de Is it possible to provide interfaces for Clisp to object request broker systems like ILU or ORBit? I've seen that ilu supports some different common lisp imp (Franz' ACL?), but this sure won't work straight for arbitray CL imps. Klaus Schilling From yoda@pixie.isr.ist.utl.pt Thu Sep 30 10:58:48 1999 Received: from pixie.isr.ist.utl.pt (root@pixie.isr.ist.utl.pt [193.136.138.97]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id KAA29915 for ; Thu, 30 Sep 1999 10:58:42 -0700 (PDT) Received: (from yoda@localhost) by pixie.isr.ist.utl.pt (8.8.8/8.8.8) id TAA20190; Thu, 30 Sep 1999 19:09:44 GMT To: clisp-list@seagull.cons.org Subject: shared object and dynamic loading query Mime-Version: 1.0 (generated by tm-edit 7.108) Content-Type: text/plain; charset=US-ASCII From: Rodrigo Ventura Date: 30 Sep 1999 19:09:40 +0000 Message-ID: Lines: 20 X-Mailer: Gnus v5.5/XEmacs 20.4 - "Emerald" Hi. I guess this is a recurrent topic on this list, but I was wondering if anyone is working or has done any work on CLISP dynamic loading of shared objects. It's such a neat feature that I feel almost a shame CLISP doesn't support it yet. Some time ago I read a message about some very preliminary code to do that. Is there any theoretic infeasibility? Cheers, -- *** Rodrigo Martins de Matos Ventura *** Web page: http://www.isr.ist.utl.pt/~yoda *** Teaching Assistant and MSc Student at ISR: *** Instituto de Sistemas e Robotica, Polo de Lisboa *** Instituto Superior Tecnico, Lisboa, PORTUGAL *** PGP fingerprint = 0119 AD13 9EEE 264A 3F10 31D3 89B3 C6C4 60C6 4585 From erik@inanna.starseed.com Thu Sep 30 13:02:33 1999 Received: from inanna.starseed.com (root@inanna.starseed.com [206.151.157.197]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id NAA01564 for ; Thu, 30 Sep 1999 13:02:21 -0700 (PDT) Received: (from erik@localhost) by inanna.starseed.com (8.9.3/8.9.3) id NAA25396; Thu, 30 Sep 1999 13:17:10 -0700 From: Erik Arneson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14323.50502.180709.796393@inanna.starseed.com> Date: Thu, 30 Sep 1999 13:17:10 -0700 (PDT) To: clisp-list@seagull.cons.org Subject: Unbuffered *terminal-io*? X-Mailer: VM 6.75 under 21.1 (patch 6) "Big Bend" XEmacs Lucid I have a stupid question today. How do I switch off the buffering of *terminal-io*? I'm having problems with (read-char-no-hang) hanging if there's nothing waiting on the input end of *terminal-io*. -- # Erik Arneson erik@starseed.com Webring Software Engineer # # Yahoo! Inc. PGP ID: 2048/84413E19 (541) 482-3000x114 # # "There's such a fine line between stupid and clever." Spinal Tap # From haible@ilog.fr Thu Sep 30 13:18:21 1999 Received: from sceaux.ilog.fr (sceaux.ilog.fr [193.55.64.10]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id NAA01938 for ; Thu, 30 Sep 1999 13:18:13 -0700 (PDT) Received: from laposte.ilog.fr (laposte [172.17.1.6]) by sceaux.ilog.fr (8.9.3/8.9.3) with ESMTP id WAA16376 for ; Thu, 30 Sep 1999 22:30:19 +0200 (MET DST) Received: from jaures.ilog.fr ([172.17.4.92]) by laposte.ilog.fr (8.9.3/8.9.3) with ESMTP id WAA29896; Thu, 30 Sep 1999 22:31:14 +0200 (MET DST) From: Bruno Haible Received: (from haible@localhost) by jaures.ilog.fr (8.9.3/8.9.3) id WAA05094; Thu, 30 Sep 1999 22:31:14 +0200 (MET DST) Date: Thu, 30 Sep 1999 22:31:14 +0200 (MET DST) Message-Id: <199909302031.WAA05094@jaures.ilog.fr> To: clisp-list@seagull.cons.org Subject: Re: Unbuffered *terminal-io*? In-Reply-To: <14323.50502.180709.796393@inanna.starseed.com> References: <14323.50502.180709.796393@inanna.starseed.com> Erik Arneson writes: > How do I switch off the buffering of *terminal-io*? $ clisp -q | cat But then you lose the GNU readline features. > I'm having problems with (read-char-no-hang) hanging if there's > nothing waiting on the input end of *terminal-io*. This is a bug, and is fixed in recent snapshots (ftp://cellar.goems.com/pub/clisp/). Bruno From erik@inanna.starseed.com Thu Sep 30 13:26:11 1999 Received: from inanna.starseed.com (root@inanna.starseed.com [206.151.157.197]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id NAA02194 for ; Thu, 30 Sep 1999 13:26:09 -0700 (PDT) Received: (from erik@localhost) by inanna.starseed.com (8.9.3/8.9.3) id NAA25507; Thu, 30 Sep 1999 13:41:17 -0700 From: Erik Arneson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14323.51949.744367.90669@inanna.starseed.com> Date: Thu, 30 Sep 1999 13:41:17 -0700 (PDT) To: clisp-list@seagull.cons.org Subject: Re: Unbuffered *terminal-io*? In-Reply-To: <199909302031.WAA05094@jaures.ilog.fr> References: <199909302031.WAA05094@jaures.ilog.fr> X-Mailer: VM 6.75 under 21.1 (patch 6) "Big Bend" XEmacs Lucid On 30 Sep 99, Bruno Haible wrote: > Erik Arneson writes: > > I'm having problems with (read-char-no-hang) hanging if there's > > nothing waiting on the input end of *terminal-io*. > > This is a bug, and is fixed in recent snapshots > (ftp://cellar.goems.com/pub/clisp/). Aha!! Thank you so much. :) -- # Erik Arneson erik@starseed.com Webring Software Engineer # # Yahoo! Inc. PGP ID: 2048/84413E19 (541) 482-3000x114 # # "There's such a fine line between stupid and clever." Spinal Tap # From erik@inanna.starseed.com Thu Sep 30 14:44:05 1999 Received: from inanna.starseed.com (root@inanna.starseed.com [206.151.157.197]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id OAA03327 for ; Thu, 30 Sep 1999 14:44:04 -0700 (PDT) Received: (from erik@localhost) by inanna.starseed.com (8.9.3/8.9.3) id OAA09344; Thu, 30 Sep 1999 14:59:11 -0700 From: Erik Arneson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14323.56622.789657.986325@inanna.starseed.com> Date: Thu, 30 Sep 1999 14:59:10 -0700 (PDT) To: clisp-list@seagull.cons.org Subject: Re: Unbuffered *terminal-io*? In-Reply-To: <199909302031.WAA05094@jaures.ilog.fr> References: <199909302031.WAA05094@jaures.ilog.fr> X-Mailer: VM 6.75 under 21.1 (patch 6) "Big Bend" XEmacs Lucid On 30 Sep 99, Bruno Haible wrote: > Erik Arneson writes: > > > How do I switch off the buffering of *terminal-io*? > > $ clisp -q | cat > > But then you lose the GNU readline features. > > > I'm having problems with (read-char-no-hang) hanging if there's > > nothing waiting on the input end of *terminal-io*. > > This is a bug, and is fixed in recent snapshots > (ftp://cellar.goems.com/pub/clisp/). Here's the situation: I'm writing an IRC interface for a project I"m working on. I need to be able to process incoming stuff from the IRC server and still check to see if the user has typed in any commands. Is there a way to keep the GNU readline features without having "hanging" functions checking for user input? Currently I'm using `read-char-no-hang' on *terminal-io*, which does seem to axe readline. (BTW, I'm using the 09-30 snapshot.) -- # Erik Arneson erik@starseed.com Webring Software Engineer # # Yahoo! Inc. PGP ID: 2048/84413E19 (541) 482-3000x114 # # "There's such a fine line between stupid and clever." Spinal Tap # From haible@ilog.fr Thu Sep 30 15:15:24 1999 Received: from sceaux.ilog.fr (sceaux.ilog.fr [193.55.64.10]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id PAA03766 for ; Thu, 30 Sep 1999 15:15:23 -0700 (PDT) Received: from laposte.ilog.fr (laposte [172.17.1.6]) by sceaux.ilog.fr (8.9.3/8.9.3) with ESMTP id AAA18860 for ; Fri, 1 Oct 1999 00:27:31 +0200 (MET DST) Received: from jaures.ilog.fr ([172.17.4.92]) by laposte.ilog.fr (8.9.3/8.9.3) with ESMTP id AAA04465; Fri, 1 Oct 1999 00:28:26 +0200 (MET DST) From: Bruno Haible Received: (from haible@localhost) by jaures.ilog.fr (8.9.3/8.9.3) id AAA05460; Fri, 1 Oct 1999 00:28:26 +0200 (MET DST) Date: Fri, 1 Oct 1999 00:28:26 +0200 (MET DST) Message-Id: <199909302228.AAA05460@jaures.ilog.fr> To: clisp-list@seagull.cons.org Subject: Re: Unbuffered *terminal-io*? In-Reply-To: <14323.56622.789657.986325@inanna.starseed.com> References: <14323.56622.789657.986325@inanna.starseed.com> Erik Arneson writes: > Here's the situation: I'm writing an IRC interface for a project I"m > working on. I need to be able to process incoming stuff from the IRC > server and still check to see if the user has typed in any commands. Checking if the user has typed something can be done through (read-char-no-hang *keyboard-input*). This totally bypasses readline. Checking if the IRC server has sent something can be done through (read-char-no-hang socket) or (when (sys::listen-byte socket) (read-byte socket)). In order to multiplex these, you can write a loop which polls one and the other and then does a (sleep 0.01) in order not to burn CPU time. > Is there a way to keep the GNU readline features without having > "hanging" functions checking for user input? Currently I'm using > `read-char-no-hang' on *terminal-io*, which does seem to axe readline. Not for the moment, but newer versions of the readline library permit this, if clisp is modified appropriately, which I plan to do. Bruno From erik@inanna.starseed.com Thu Sep 30 15:51:13 1999 Received: from inanna.starseed.com (root@inanna.starseed.com [206.151.157.197]) by seagull.cdrom.com (8.8.8/8.7.3) with ESMTP id PAA04333 for ; Thu, 30 Sep 1999 15:51:10 -0700 (PDT) Received: (from erik@localhost) by inanna.starseed.com (8.9.3/8.9.3) id QAA09606; Thu, 30 Sep 1999 16:06:00 -0700 From: Erik Arneson MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14323.60631.800248.171951@inanna.starseed.com> Date: Thu, 30 Sep 1999 16:05:59 -0700 (PDT) To: clisp-list@seagull.cons.org Subject: Re: Unbuffered *terminal-io*? In-Reply-To: <199909302228.AAA05460@jaures.ilog.fr> References: <199909302228.AAA05460@jaures.ilog.fr> X-Mailer: VM 6.75 under 21.1 (patch 6) "Big Bend" XEmacs Lucid On 30 Sep 99, Bruno Haible wrote: > Checking if the user has typed something can be done through > (read-char-no-hang *keyboard-input*). This totally bypasses readline. > Checking if the IRC server has sent something can be done through > (read-char-no-hang socket) or > (when (sys::listen-byte socket) (read-byte socket)). Thanks! This works beautifully. > > Is there a way to keep the GNU readline features without having > > "hanging" functions checking for user input? Currently I'm using > > `read-char-no-hang' on *terminal-io*, which does seem to axe readline. > > Not for the moment, but newer versions of the readline library permit > this, if clisp is modified appropriately, which I plan to do. That would be a really neat feature. I have another question regarding conditions and error-catching stuff. I have a long list of servers, and I'm trying to cycle through the list and connect/authenticate to each. The problem is, with my limited experience with TCP/IP sockets, I'm not quite sure how to go about testing if the connection succeeded. There doesn't seem to be anything equivalent to `socket-open-p', or something like that. I'm sure I could probably figure out something with `handler-bind' if I knew what errors I was looking for. Does anybody have some example code that I could look at and learn from using CLISP's socket stuff? -- # Erik Arneson erik@starseed.com Webring Software Engineer # # Yahoo! Inc. PGP ID: 2048/84413E19 (541) 482-3000x114 # # "There's such a fine line between stupid and clever." Spinal Tap #