#30 Problem with lisp:socket-connect?
I've just upgraded clisp from 2000-03-06 to 2.25.1.
Everything appears well
apart from one minor difference that I can't quite
fathom. The problem is
with <URL:http://www.davep.org/misc/nntp.lisp>, some
code I've been playing
with on and off the a short while.
That code worked fine with 2000-03-06 but gives an odd
result with 2.25.1.
To illustrate:
,----
| davep@hagbard:~/develop/lisp/nntp$ type cl
| cl is aliased to `clisp -K full -q -a'
|
| davep@hagbard:~/develop/lisp/nntp$ cl
| ;; Loading file /home/davep/.clisprc.lsp ...
| ;; Loading file /home/davep/lib/lisp/dp-lib.fas ...
| ;; Loading of file /home/davep/lib/lisp/dp-lib.fas
is finished.
| ;; Loading of file /home/davep/.clisprc.lsp is
finished.
| [1]> (load "nntp")
| ;; Loading file
/home/davep/develop/lisp/nntp/nntp.fas ...
| ;; Loading of file
/home/davep/develop/lisp/nntp/nntp.fas is finished.
| t
| [2]> (setq x (make-nntp-client))
| #<nntp-client localhost:119 (not connected)>
| [3]> (connect x)
|
| *** - funcall: the function socket-connect is
undefined
`----
The method connect looks like:
-- cut here
----------------------------------------------------------------
(defmethod connect ((nntp-client nntp-client))
"Connect the NNTP client to the NNTP server."
(setf (socket nntp-client)
#+clisp (lisp:socket-connect (port
nntp-client) (host nntp-client))
#+allegro (socket:make-socket :remote-host
(host nntp-client) :remote-po
rt (port nntp-client) :format :text)
#-(or clisp allegro) (error "You need to add
support for your CL environ
ment"))
(get-short-response nntp-client))
-- cut here
----------------------------------------------------------------
and worked fine with 2000-03-06 and works well with
allegro. What is odder
is that if I make the call to lisp:socket-connect "by
hand", it works:
,----
| [7]> (setf (socket x) (lisp:socket-connect (port x)
(host x)))
| #<unbuffered socket-stream character localhost:119>
`----
I can't obviously see anything wrong with my code
(although I'm open to
suggestions) and I can't see a reason why I'm seeing
different behaviour
between the older and current versions of clisp.
Am I tickling a bug in this release of clisp or is it
simply bad coding on
my part?
Logged In: YES
user_id=5735
1. I recommend that you use CLOCC/PORT
(http://clocc.sourceforge.net) for your
implementation-dependent stuff (see clocc/src/port/net.lisp)
2. Did you recompile your lisp file? CHANGES.LOG mentions
this requirement.
3. It is __VERY__ wise to have an in-package form in the
beginning of __EVERY__ lisp file. I cannot stress this too
much. This might not be absolutely necessary now, but it
__IS__ a good practice.
4. please try to create an isolated test file and produce an
explicit test sequence of commands to issue to get the error.
Thanks for reporting the bug.
Logged In: YES
user_id=1844
x
Logged In: YES
user_id=1844
[To SDS]
In response to point 1 of your followup. That really
wouldn't help get to the bottom of the problem at hand would
it?
In reponse to point 2 of your followup. Yes, I recompiled.
In reponse to point 3. Do you mean something like:
(in-package :common-lisp-user)?
I tried that just now and the problem went away. While I'm
happy to see that this cures me problem I'm confused as to
why this is only now required by clisp (and isn't a
requirement of other CLs I've tested with).
In response to point 4: I spent significant time and trouble
doing exactly that for my bug report. Perhaps you'd be kind
enough to follow the link to the example program and to
follow the quoted script of how to recreate the problem?
Logged In: YES
user_id=5735
1. using CLOCC/PORT would have shifted the blame from you to
me, at the very least. :-) Actually, it would have
probably fixed the problem too (there are in-package forms
in CLOCC/PORT).
2. Good!
3. actually, ACL5 does issue a warning when the file is is
compiling does not have an in-package statement.
This is now fixed in the CLISP sources. The reason for the
bug is that CLISP was saving the *fas files assuming that it
will be read in the same package settings as were in effect
at compilation time. This does help somewhat novice users,
but breaks some legitimate code, thus it was removed.
4. Actually, when I fixed the problem, the isolated test
case I created was a 3 line file. :-) There is always room
for improvement. :-)
I do appreciate your bug reports and I thank you for
reporting this particular bug.
Logged In: YES
user_id=1844
Glad to hear that the bug was nailed. Thanks for your time
and attention.