Ah, I see that this file is fixed in the subversion repository --- at least to the extent that it loads correctly.
You mean cl-irc still doesn't work for you?
Yes, cl-irc works with SBCL: I have a 0.8.0 image running for some time now and haven't seen any problems.
As far as documentation on the functions in allegro.lisp: for all methods and most functions, there's documentation in usocket.lisp. If that's insufficient, no problem, but I'll need directions on what's unclear so I can add it.
Looking at the sources, usocket doesn't account for the case when a NIL socket is returned by Allegro. I guess usocket should return NIL when Allegro does (and cl-irc should take into account NIL is a valid return value signalling 'no socket').
Do you have any idea what could have gone wrong so that no socket was created?
bye,
Erik. PS: Thanks for the report. Could you CC the mailing list too? I read that more often than this mail-address.
Erik Huelsmann wrote:
Ah, I see that this file is fixed in the subversion repository --- at least to the extent that it loads correctly.
You mean cl-irc still doesn't work for you?
Yes, cl-irc works with SBCL: I have a 0.8.0 image running for some time now and haven't seen any problems.
I got it to crash a couple of times. Per your suggestion below, this was in a case where Allegro returned a NIL value for a socket.
As far as documentation on the functions in allegro.lisp: for all methods and most functions, there's documentation in usocket.lisp. If that's insufficient, no problem, but I'll need directions on what's unclear so I can add it.
Looking at the sources, usocket doesn't account for the case when a NIL socket is returned by Allegro. I guess usocket should return NIL when Allegro does (and cl-irc should take into account NIL is a valid return value signalling 'no socket').
Do you have any idea what could have gone wrong so that no socket was created?
Not really. BEIRC got all bollixed up because I was already logged into freenode using my usual nick. It doesn't seem to rollover from the prespecified nick that happily.
I will see if I can replicate the behavior.
Should usocket return nil in this case, or raise an error?
Best, R
On 1/22/07, Robert P. Goldman rpgoldman@sift.info wrote:
Erik Huelsmann wrote:
Ah, I see that this file is fixed in the subversion repository --- at least to the extent that it loads correctly.
You mean cl-irc still doesn't work for you?
Yes, cl-irc works with SBCL: I have a 0.8.0 image running for some time now and haven't seen any problems.
I got it to crash a couple of times. Per your suggestion below, this was in a case where Allegro returned a NIL value for a socket.
As far as documentation on the functions in allegro.lisp: for all methods and most functions, there's documentation in usocket.lisp. If that's insufficient, no problem, but I'll need directions on what's unclear so I can add it.
Looking at the sources, usocket doesn't account for the case when a NIL socket is returned by Allegro. I guess usocket should return NIL when Allegro does (and cl-irc should take into account NIL is a valid return value signalling 'no socket').
Do you have any idea what could have gone wrong so that no socket was created?
Not really. BEIRC got all bollixed up because I was already logged into freenode using my usual nick. It doesn't seem to rollover from the prespecified nick that happily.
I will see if I can replicate the behavior.
Should usocket return nil in this case, or raise an error?
That's a good point. Well, I guess it should raise an error: the interface contract specifies it to return a socket and the interface contract for the returned socket is to contain an implementation defined socket reference. Since we can't return a valid socket, I guess socket-connect should raise 'unknown-error...
Having replicated behavior would be great! That way I'd be able to check for the same behavior in the other backends (and maybe in other allegro versions).
Thanks again for the report!
bye,
Erik.
Erik Huelsmann wrote:
On 1/22/07, Robert P. Goldman rpgoldman@sift.info wrote:
Erik Huelsmann wrote:
Ah, I see that this file is fixed in the subversion repository --- at least to the extent that it loads correctly.
You mean cl-irc still doesn't work for you?
Yes, cl-irc works with SBCL: I have a 0.8.0 image running for some
time now and haven't seen any problems.
I got it to crash a couple of times. Per your suggestion below, this was in a case where Allegro returned a NIL value for a socket.
As far as documentation on the functions in allegro.lisp: for all
methods and most functions, there's documentation in usocket.lisp. If that's insufficient, no problem, but I'll need directions on what's unclear so I can add it.
Looking at the sources, usocket doesn't account for the case when a
NIL socket is returned by Allegro. I guess usocket should return NIL when Allegro does (and cl-irc should take into account NIL is a valid return value signalling 'no socket').
Do you have any idea what could have gone wrong so that no socket
was created?
Not really. BEIRC got all bollixed up because I was already logged into freenode using my usual nick. It doesn't seem to rollover from the prespecified nick that happily.
I will see if I can replicate the behavior.
Should usocket return nil in this case, or raise an error?
That's a good point. Well, I guess it should raise an error: the interface contract specifies it to return a socket and the interface contract for the returned socket is to contain an implementation defined socket reference. Since we can't return a valid socket, I guess socket-connect should raise 'unknown-error...
I think that's right, as well. The problem with the current behavior is that the actual crash (when some code attempts to do something with the alleged socket of NIL) can come at an arbitrary distance from the actual error (returning NIL instead of a socket), making code that uses usocket more difficult to debug than necessary.
Should there be a more specific error class??
Having replicated behavior would be great! That way I'd be able to check for the same behavior in the other backends (and maybe in other allegro versions).
OK, I'll see what I can do. I was flailing around with beirc, so I may not be able to replicate this that easily (and, of course, a simple invocation of cl-irc, w/o involving beirc would make a better test case).
Best, R
Should usocket return nil in this case, or raise an error?
That's a good point. Well, I guess it should raise an error: the interface contract specifies it to return a socket and the interface contract for the returned socket is to contain an implementation defined socket reference. Since we can't return a valid socket, I guess socket-connect should raise 'unknown-error...
I think that's right, as well. The problem with the current behavior is that the actual crash (when some code attempts to do something with the alleged socket of NIL) can come at an arbitrary distance from the actual error (returning NIL instead of a socket), making code that uses usocket more difficult to debug than necessary.
Should there be a more specific error class??
I created 2 new errors: invalid-socket-error and invalid-socket-stream-error. These are raised when an implementation tries to create a socket with invalid (= NIL) slots for 'socket' or 'socket-stream' respectively. (This is still on trunk btw, I'll release 0.3.1 when we accumulate fixes or when enough time passes without accumulating new problems.)
Having replicated behavior would be great! That way I'd be able to check for the same behavior in the other backends (and maybe in other allegro versions).
OK, I'll see what I can do. I was flailing around with beirc, so I may not be able to replicate this that easily (and, of course, a simple invocation of cl-irc, w/o involving beirc would make a better test case).
bye,
Erik.
-
Erik Huelsmann -
Erik Huelsmann -
Robert P. Goldman