RC wrote:
> I'm trying to get portable aserve to work with Clisp
> but I'm seeing the following problem:
>
> ---------------------------------------------------
> $ clisp -K full
>
> [1]> *features*
> (:CLOS :LOOP :COMPILER :CLISP :ANSI-CL :COMMON-LISP :LISP=CL :INTERPRETER
> :SOCKETS :GENERIC-STREAMS :LOGICAL-PATHNAMES
> :SCREEN :FFI :UNICODE :BASE-CHAR=CHARACTER :SYSCALLS :UNIX)
>
> [2]> (load "INSTALL.lisp")
> ;; Loading file INSTALL.lisp ...
> ;; Loading file /home/bsd/portableaserve/libs/asdf.lisp ...
> ;; Loaded file /home/bsd/portableaserve/libs/asdf.lisp
> ;; Loading file /home/bsd/portableaserve/libs/puri-1.3.1/puri.asd ...
> ;; Loaded file /home/bsd/portableaserve/libs/puri-1.3.1/puri.asd
> .
> .
> .
> ;; Loading file /home/bsd/portableaserve/aserve/htmlgen/htmlgen.fas ...
> ;; Loaded file /home/bsd/portableaserve/aserve/htmlgen/htmlgen.fas
> ;; Loading file /home/bsd/portableaserve/aserve/packages.fas ...
> ;; Loaded file /home/bsd/portableaserve/aserve/packages.fas
> ;; Loading file /home/bsd/portableaserve/aserve/macs.fas ...
> ;; Loaded file /home/bsd/portableaserve/aserve/macs.fas
> Compiling file /home/bsd/portableaserve/aserve/main.cl ...
> *** - READ from #<INPUT BUFFERED FILE-STREAM CHARACTER
> #P"/home/bsd/portableaserve/aserve/main.cl" @217>: there is no package
> with name "UNIX"
> The following restarts are available:
> R1 = Retry performing #.(FUNCALL #<COMPILED-CLOSURE NIL>) on #.(FUNCALL #
> <COMPILED-CLOSURE NIL>).
> R2 = Continue, treating #.(FUNCALL #<COMPILED-CLOSURE NIL>) on #.(FUNCALL
> #<COMPILED-CLOSURE NIL>) as having been successful.
>
> 1. Break NET.ASERVE[3]>
Hi,
I just got it to run this moment using SBCL/Linux, and the key was not
to use the normal Sourceforge download, but rather to get it from CVS:
cvs ····················@cvs.sourceforge.net:/cvsroot/portableaserve
login
cvs -z3
····················@cvs.sourceforge.net:/cvsroot/portableaserve co -P
portableaserve
Maybe also the following for good measure, though I doubt it's useful:
cvs -z3
····················@cvs.sourceforge.net:/cvsroot/portableaserve co -P
cl-ssl
Please get back to us on whether this works; I'm thinking of making a
little wiki page on "Practical Common Lisp Gotchas", since that book
refers to Portable Allegroserve...
Tayssir
"Tayssir John Gabbour" <···········@yahoo.com> wrote in
·····························@g47g2000cwa.googlegroups.com:
> RC wrote:
>> I'm trying to get portable aserve to work with Clisp
>> but I'm seeing the following problem:
>>
>> ---------------------------------------------------
>> $ clisp -K full
>>
>> [1]> *features*
>> (:CLOS :LOOP :COMPILER :CLISP :ANSI-CL :COMMON-LISP :LISP=CL
>> :INTERPRETER
>> :SOCKETS :GENERIC-STREAMS :LOGICAL-PATHNAMES
>> :SCREEN :FFI :UNICODE :BASE-CHAR=CHARACTER :SYSCALLS :UNIX)
>>
>> [2]> (load "INSTALL.lisp")
>> ;; Loading file INSTALL.lisp ...
>> ;; Loading file /home/bsd/portableaserve/libs/asdf.lisp ...
>> ;; Loaded file /home/bsd/portableaserve/libs/asdf.lisp
>> ;; Loading file /home/bsd/portableaserve/libs/puri-1.3.1/puri.asd
>> ... ;; Loaded file /home/bsd/portableaserve/libs/puri-1.3.1/puri.asd
>> .
>> .
>> .
>> ;; Loading file /home/bsd/portableaserve/aserve/htmlgen/htmlgen.fas
>> ... ;; Loaded file
>> /home/bsd/portableaserve/aserve/htmlgen/htmlgen.fas ;; Loading file
>> /home/bsd/portableaserve/aserve/packages.fas ... ;; Loaded file
>> /home/bsd/portableaserve/aserve/packages.fas ;; Loading file
>> /home/bsd/portableaserve/aserve/macs.fas ... ;; Loaded file
>> /home/bsd/portableaserve/aserve/macs.fas Compiling file
>> /home/bsd/portableaserve/aserve/main.cl ... *** - READ from #<INPUT
>> BUFFERED FILE-STREAM CHARACTER
>> #P"/home/bsd/portableaserve/aserve/main.cl" @217>: there is no
>> package with name "UNIX"
>> The following restarts are available:
>> R1 = Retry performing #.(FUNCALL #<COMPILED-CLOSURE NIL>) on
>> #.(FUNCALL # <COMPILED-CLOSURE NIL>).
>> R2 = Continue, treating #.(FUNCALL #<COMPILED-CLOSURE NIL>) on
>> #.(FUNCALL #<COMPILED-CLOSURE NIL>) as having been successful.
>>
>> 1. Break NET.ASERVE[3]>
>
> Hi,
>
> I just got it to run this moment using SBCL/Linux, and the key was not
> to use the normal Sourceforge download, but rather to get it from CVS:
>
> cvs ····················@cvs.sourceforge.net:/cvsroot/portableaserve
> login
> cvs -z3
> ····················@cvs.sourceforge.net:/cvsroot/portableaserve co -P
> portableaserve
>
> Maybe also the following for good measure, though I doubt it's useful:
> cvs -z3
> ····················@cvs.sourceforge.net:/cvsroot/portableaserve co -P
> cl-ssl
>
>
> Please get back to us on whether this works; I'm thinking of making a
> little wiki page on "Practical Common Lisp Gotchas", since that book
> refers to Portable Allegroserve...
>
>
> Tayssir
>
>
I don't have SBCL installed at the moment but I did try it
with CMUCL 19a and it does work. The only issue is to
(unlock-all-packages) before installing if you don't
want it to stop in the middle of the installation.
The problem with CLISP seems to be related to this
section in aserve/main.cl:
#+(and clisp unix)
(defun getpid () (unix:getpid))
There does not seem to be a getpid in my version of CLISP.
RC <··········@pvoalfotpmezsaq.net> writes:
> The problem with CLISP seems to be related to this
> section in aserve/main.cl:
>
> #+(and clisp unix)
> (defun getpid () (unix:getpid))
>
> There does not seem to be a getpid in my version of CLISP.
>$ clisp --version -K full
>GNU CLISP 2.30 (released 2002-09-15) (built 3326310440) (memory
>$ /usr/local/clisp/bin/clisp --version -K full
>GNU CLISP 2.33.2 (2004-06-02) (built 3326301126) (memory 3326302668)
Please look up sys::program-id in your ancient clisp. It's getenv.
It's been there for some years (but depending on compilation options)
under UNIX.
With a clisp>March 2005, sys::process-id is there on both MS-Windows and UNIX.
Ir probably should be moved to the EXT package.
Regards,
Jorg Hohle
Telekom/T-Systems Technology Center
Joerg Hoehle <······@users.sourceforge.net> wrote in
··················@users.sourceforge.net:
> Please look up sys::program-id in your ancient clisp. It's getenv.
> It's been there for some years (but depending on compilation options)
> under UNIX.
>
> With a clisp>March 2005, sys::process-id is there on both MS-Windows
> and UNIX. Ir probably should be moved to the EXT package.
>
> Regards,
> Jorg Hohle
> Telekom/T-Systems Technology Center
>
Yes, thank you.
I also found that if you build CLISP with
--with-module=bindings/glibc
then you get the function (unix:getpid) included
but it's only working under linux. With Freebsd
you get errors about bits/errno.h not being found.
RC
RC <··········@pvoalfotpmezsaq.net> writes:
> I also found that if you build CLISP with
> --with-module=bindings/glibc
> then you get the function (unix:getpid) included
> but it's only working under linux. With Freebsd
> you get errors about bits/errno.h not being found.
Is FreeBSD a glibc based-system?
Could you please investigate where errno and its values are defined?
Is that the only part of linux.lisp that fails?
linux.lisp says
;; in GNU, errno is a per-thread variable, so def-c-var is not appropriate
;; (def-c-var errno (:type ffi:int))
;; link error: "undefined reference to `errno'"
What if you uncomment this alternate definition and remove the line
causing inclusion of <bits/errno.h> and the other errno symbol macro?
Does it load, does linux:errno work then?
Please report results to either ···········@lists.sourceforge.net or
···········@lists.sourceforge.net
Regards,
Jorg Hohle
Telekom/T-Systems Technology Center
Joerg Hoehle <······@users.sourceforge.net> wrote:
+---------------
| RC <··········@pvoalfotpmezsaq.net> writes:
| > I also found that if you build CLISP with
| > --with-module=bindings/glibc
| > then you get the function (unix:getpid) included
| > but it's only working under linux. With Freebsd
| > you get errors about bits/errno.h not being found.
|
| Is FreeBSD a glibc based-system?
+---------------
No, or at least not by default. The BSD libc predates glibc by some years.
There are versions of glibc used in the Linux compatibility libraries
[since FreeBSD supports running (most) precompiled Linux applications],
and there may be some projects to get glibc on BSD "natively" [e.g., see
http://lists.freebsd.org/pipermail/freebsd-ports/2005-January/019839.html
and http://lists.freebsd.org/pipermail/freebsd-ports/2005-January/019844.html].
+---------------
| Could you please investigate where errno and its values are defined?
+---------------
On a stock FreeBSD-4.10 they're in "/usr/include/errno.h" [there
is no such file as <bits/errno.h>], and "errno" is defined as a
C macro that calls the procedure "__error()". As it says in the
"errno(2)" man page:
The __error() function returns a pointer to a field in the
thread specific structure for threads other than the initial
thread. For the initial thread and non-threaded processes,
__error() returns a pointer to a global errno variable that
is compatible with the previous definition.
Does that help?
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
"Tayssir John Gabbour" <···········@yahoo.com> writes:
> Please get back to us on whether this works; I'm thinking of making a
> little wiki page on "Practical Common Lisp Gotchas", since that book
> refers to Portable Allegroserve...
That'd be excellent. I'm ashamed that I ran out of time to do proper
testing with Portable AllegroServe--I did use it early on with OpenMCL
on my Mac but didn't actually have time to circle around and retest
all the code from teh book on both normal AllegroServe and Portable
AllegroServe.
I'd also happily accept patches against the example code that can be
downloaded at:
<http://www.gigamonkeys.com/book/practicals-1.0.3.tar.gz>
<http://www.gigamonkeys.com/book/practicals-1.0.3.zip>
to make things run more smoothly on Portable AllegroServe.
-Peter
--
Peter Seibel ·····@gigamonkeys.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel wrote:
> "Tayssir John Gabbour" <···········@yahoo.com> writes:
>
> > Please get back to us on whether this works; I'm thinking of making a
> > little wiki page on "Practical Common Lisp Gotchas", since that book
> > refers to Portable Allegroserve...
>
> That'd be excellent. I'm ashamed that I ran out of time to do proper
> testing with Portable AllegroServe--I did use it early on with OpenMCL
> on my Mac but didn't actually have time to circle around and retest
> all the code from teh book on both normal AllegroServe and Portable
> AllegroServe.
After I posted that, I hoped it wouldn't be taken in a sad way. There
are so many testing scenarios when talking about CL: the curse of
choice.
Maybe people can complement your book with "current" info on helping
people to install stuff, and whatnot.
And the computing world always sweeps under the rug how hard installing
things can be, CL or no. The first time I tested out Installshield and
Wise...
Not to mention software economics are, um... suboptimal. ;) Forcing
lots of usability problems.
Tayssir
Peter Seibel <·····@gigamonkeys.com> wrote in
···················@gigamonkeys.com:
>
> I'd also happily accept patches against the example code that can be
> downloaded at:
>
> <http://www.gigamonkeys.com/book/practicals-1.0.3.tar.gz>
> <http://www.gigamonkeys.com/book/practicals-1.0.3.zip>
>
> to make things run more smoothly on Portable AllegroServe.
>
> -Peter
>
There seems to be a glitch when untaring practicals-1.0.3.tar.gz
with both winzip and tar under Freebsd 4.9.
I saw no problems with practicals-1.0.3.zip.
RC wrote:
> There seems to be a glitch when untaring practicals-1.0.3.tar.gz
> with both winzip and tar under Freebsd 4.9.
>
> I saw no problems with practicals-1.0.3.zip.
I saw the same think. The last file, though unnecessary, is truncated
and screws up the archive.
"jonathon" <···········@bigfoot.com> writes:
> RC wrote:
>
>> There seems to be a glitch when untaring practicals-1.0.3.tar.gz
>> with both winzip and tar under Freebsd 4.9.
>>
>> I saw no problems with practicals-1.0.3.zip.
>
> I saw the same think. The last file, though unnecessary, is
> truncated and screws up the archive.
Hmmm. What do you mean by "last file" and "truncated"? According to
"tar tzf" the last file is .p4change and when I unpack the tar with
"tar xzf" the file looks fine. It's just one line long.
-Peter
--
Peter Seibel ·····@gigamonkeys.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel <·····@gigamonkeys.com> wrote in
···················@gigamonkeys.com:
> "jonathon" <···········@bigfoot.com> writes:
>
>> RC wrote:
>>
>>> There seems to be a glitch when untaring practicals-1.0.3.tar.gz
>>> with both winzip and tar under Freebsd 4.9.
>>>
>>> I saw no problems with practicals-1.0.3.zip.
>>
>> I saw the same think. The last file, though unnecessary, is
>> truncated and screws up the archive.
>
> Hmmm. What do you mean by "last file" and "truncated"? According to
> "tar tzf" the last file is .p4change and when I unpack the tar with
> "tar xzf" the file looks fine. It's just one line long.
>
> -Peter
>
I'm unpacking with "tar xvzf".
Any difference with that?
RC <··········@pvoalfotpmezsaq.net> writes:
> Peter Seibel <·····@gigamonkeys.com> wrote in
> ···················@gigamonkeys.com:
>
>> "jonathon" <···········@bigfoot.com> writes:
>>
>>> RC wrote:
>>>
>>>> There seems to be a glitch when untaring practicals-1.0.3.tar.gz
>>>> with both winzip and tar under Freebsd 4.9.
>>>>
>>>> I saw no problems with practicals-1.0.3.zip.
>>>
>>> I saw the same think. The last file, though unnecessary, is
>>> truncated and screws up the archive.
>>
>> Hmmm. What do you mean by "last file" and "truncated"? According to
>> "tar tzf" the last file is .p4change and when I unpack the tar with
>> "tar xzf" the file looks fine. It's just one line long.
>>
>> -Peter
>>
>
> I'm unpacking with "tar xvzf".
> Any difference with that?
Shouldn't be. I have observed some problems with tar xzf (and
presumably the "v" doesn't matter) on OS X due to gzip complaining
about trailing garbage. You might try "gzip -cdq | tar xf -" and let
me know if that works.
-Peter
--
Peter Seibel ·····@gigamonkeys.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel wrote:
> Shouldn't be. I have observed some problems with tar xzf (and
> presumably the "v" doesn't matter) on OS X due to gzip complaining
> about trailing garbage. You might try "gzip -cdq | tar xf -" and let
> me know if that works.
That's because Gnu tar writes archives in a slightly non-standard
format, which emits said error from non-Gnu tar/pax (not from gzip).
It's usually harmless but you might want to use Gnu cpio with the -H
ustar option for writing POSIX compliant archives to avoid this, if you
only have the Gnu version of tar installed (amazingly, Gnu cpio can
write correct tar archives, while Gnu tar cannot).
mkb.
Peter Seibel <·····@gigamonkeys.com> wrote in
···················@gigamonkeys.com:
> RC <··········@pvoalfotpmezsaq.net> writes:
>
>> Peter Seibel <·····@gigamonkeys.com> wrote in
>> ···················@gigamonkeys.com:
>>
>>> "jonathon" <···········@bigfoot.com> writes:
>>>
>>>> RC wrote:
>>>>
>>>>> There seems to be a glitch when untaring practicals-1.0.3.tar.gz
>>>>> with both winzip and tar under Freebsd 4.9.
>>>>>
>>>>> I saw no problems with practicals-1.0.3.zip.
>>>>
>>>> I saw the same think. The last file, though unnecessary, is
>>>> truncated and screws up the archive.
>>>
>>> Hmmm. What do you mean by "last file" and "truncated"? According to
>>> "tar tzf" the last file is .p4change and when I unpack the tar with
>>> "tar xzf" the file looks fine. It's just one line long.
>>>
>>> -Peter
>>>
>>
>> I'm unpacking with "tar xvzf".
>> Any difference with that?
>
> Shouldn't be. I have observed some problems with tar xzf (and
> presumably the "v" doesn't matter) on OS X due to gzip complaining
> about trailing garbage. You might try "gzip -cdq | tar xf -" and let
> me know if that works.
>
> -Peter
>
It does work.
"-q --quiet Suppress all warnings." Suppresses all warnings from
gzip.
This is from the gzip FAQ:
<quote>
gzip complains with trailing garbage ignored
Some tar.gz files are padded with zeroes to have a size which
is a multiple of a certain block size. This occurs in particular
when the compressed tar file is on a device such as a magnetic tape.
When such files are extracted with a command such as
gunzip < file.tar.gz | tar xvf -
gtar xvzf /dev/rmt/0
gunzip decompresses correctly the tar.gz file, then attempts to
decompress the rest of the input which consists of zeroes.
Since those zeroes are not in gzip format, gzip ignores them.
The tar extract command still works correctly, since gzip has sent
through the pipe all the data that tar needs.
You can avoid this harmless warning by using the -q option of gzip, as
in:
gunzip -q < file.tar.gz | tar xvf -
GZIP=-q gtar xvzf /dev/rmt/0 # for bash, ksh, sh
...
(setenv GZIP -q; gtar xvzf /dev/rmt/0) # for csh, tcsh, ...
</quote>
Apparently there are additional bytes added to the gzipped file
by whatever utility you're using to zip the archive.
here's a hexdump of your tar.gz:
-bash-2.05b$ hexdump -C practicals-1.0.3.tar.gz |tail
00030c70 fc 9c 06 52 e3 8a 0a 14 65 c3 13 a9 00 94 ee c2
|...R....e.......|
00030c80 1d 5c 71 b2 36 ab e7 41 97 81 7c 59 56 da 53 7f |.\q.6..A..
|YV.S.|
00030c90 f2 2d bf f1 ca f9 7f 95 e0 74 4a 55 c0 df 6f 0e
|.-.......tJU..o.|
00030ca0 e1 ff 9d 6e f3 ff f0 15 80 e8 ff 35 6b 67 2f 4e
|...n.......5kg/N|
00030cb0 4f 4f 5f 0a ff ef ec c9 ff fb 11 97 ac f8 6e 34
|OO_...........n4|
00030cc0 1b 4d 3c 3e 25 5e c6 77 5a ad d7 9e 24 eb e9 7a |.M<>%^.wZ...
$..z|
00030cd0 ba 9e ae a7 eb 5f fa fa 1f d7 99 11 df 00 90 1a |.....
_..........|
00030ce0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|................|
*
00032000
-bash-2.05b$
here's one from a test archive I created using
tar cvzf practicals-test.tar.gz practicals-1.0.3
-bash-2.05b$ hexdump -C practicals-test.tar.gz |tail
00030c40 9e 63 e9 aa 1f d0 ee 63 aa c0 1c 01 99 e1 3b 9d
|.c.....c......;.|
00030c50 e7 2a d5 34 f5 fd 2f 78 6e 1a df fc 9c 06 52 e3 |.
*.4../xn.....R.|
00030c60 8a 0a 14 65 c3 63 a9 00 94 ee c2 1d 5c 71 b2 36 |...e.c......
\q.6|
00030c70 af e7 41 97 81 7c 59 56 da 53 7f f4 2d bf f1 2a |..A..
|YV.S..-..*|
00030c80 f8 7f b5 e0 74 46 55 c0 df 6f 0e e1 ff 9d 6e f3
|....tFU..o....n.|
00030c90 ff f0 15 80 e8 ff b5 4e 9e bf 38 45 c7 8f fc bf
|.......N..8E....|
00030ca0 e7 8f fe df 8f b8 64 c5 77 b3 d5 6c e1 f1 29 f1
|......d.w..l..).|
00030cb0 32 be d3 7a e3 e4 51 b2 1e af c7 eb f1 7a bc fe |
2..z..Q......z..|
00030cc0 a5 af ff 01 c1 80 a9 15 00 90 1a 00 |............
|
00030ccc
-bash-2.05b$
RC
RC schrieb:
> I'm trying to get portable aserve to work with Clisp
> but I'm seeing the following problem:
Did you see my posting about this issue that I made eight days ago?
Try google groups with this search:
clisp group:comp.lang.lisp author:Thieme
Andr�
--
=?ISO-8859-15?Q?Andr=E9_Thieme?= <address.good.until.2005.jul.05
@justmail.de> wrote in ·················@ulric.tng.de:
> RC schrieb:
>> I'm trying to get portable aserve to work with Clisp
>> but I'm seeing the following problem:
>
> Did you see my posting about this issue that I made eight days ago?
> Try google groups with this search:
> clisp group:comp.lang.lisp author:Thieme
>
>
> Andr�
Ok, took a look at your posting and it seems
we are on the bleeding edge (to say the least)
of this project.
I would like to see PAS work with Clisp for these reasons:
1) Clisp seems to perform well even though it is not
compiled to native code as is CMUCL. I would
like to confirm this.
2) Going the PAS route seems to avoid all those layers
of Apache + ... + ... + ... ad infinitum. Easier
to deploy conceptually and adequate for small projects.
3) Connection to an Oracle database server seems straight
forward. I have been able to do this without too many
problems. I suspect connection to Postgresql is also
supported but I have not tried it yet.
4) I don't know that the ACL trial has any DB support.
Under Python I have been able to do small DB projects
using Cherrypy and DCOracle2. PAS + Clisp seems
to be close to the Python scenario.
As far as the Clisp INSTALL of PAS, I'm getting
a pretty clean compilation up to the point
where it can't find a package named "POSIX"
or "UNIX" and a function name getpid.
RC
RC <··········@pvoalfotpmezsaq.net> writes:
>
> 2) Going the PAS route seems to avoid all those layers
> of Apache + ... + ... + ... ad infinitum. Easier
> to deploy conceptually and adequate for small projects.
Yes but...
Apache is generally already well-known to most folks doing web
development, so it's not an issue of learning Apache (which is
admittedly tough), but rather of learning something else.
Also, inevitably one will wish to start adding X and Y--and eventually
will want to start using Apache, since it's essentially The Standard
HTTPD these days.
--
Robert Uhl <http://public.xdi.org/=ruhl>
Christos Anesti! Alithos Anesti!