August 2008 - cl-irc-devel - mailman3.common-lisp.net

[cl-irc-devel] irc reply 328
by R.Matthew Emerson 23 Sep '12

23 Sep '12

It appears that when a channel is "registered" on freenode, the server sends a reply of the following form to set the channel's URL: :zelazny.freenode.net 328 rme #ccl :http://ccl.clozure.com/ CL-IRC doesn't know about this, and signals an error when it encounters it. Anyway, it might be reasonable to add (328 :rpl_channel_url) to *REPLY-NAMES* in variables.lisp. This event is mentioned in a few places I found via Google: http://colloquy.info/project/browser/trunk/Chat%20Core/MVIRCNumerics.h http://www.mishscript.de/reference/rawhelp3.htm#raw328 http://www.alien.net.au/irc/irc2numerics.def

4 5

[cl-irc-devel] Make cl-irc non blocking ?
by Lionel Flandrin 24 Oct '08

24 Oct '08

Hi, I'd like to write a minimal curses IRC client, and cl-irc seems the way to go. However, irc:read-message blocks if there's nothing to process in the connection. Since I'm not fond of threads, I wondered if there could be a way to use cl-irc in a non-blocking fashion ? The function read-sequence-until seems to take a key parameter "non-blocking", I thought that maybe modifying read-irc-message and adding ":non-blocking t" would do what I want ? Anyway, I thought I'd ask for your advices first. Thanks for your good work, -- Lionel

2 2

[cl-irc-devel] Re: flexi-streams error when compiling cl-irc
by Erik Huelsmann 11 Aug '08

11 Aug '08

On Mon, Aug 11, 2008 at 7:49 PM, John Li <jli(a)circularly.org> wrote: > Hello, > > [I hope it's okay to mail you directly - I mailed cl-irc-devel > initially, but the list apparently requires subscription.] > > I tried to install cl-irc 0.8.1 through asdf-install on SBCL today and got > this error: > > ---------------------------------------------------------------- > ; compiling (DEFUN READ-MESSAGE-LOOP ...); compilation aborted because of fatal error: > ; READ failure in COMPILE-FILE: > ; SB-INT:SIMPLE-READER-PACKAGE-ERROR at 12354 (line 349, column 56) on #<SB-SYS:FD-STREAM for "file /home/jli/.sbcl/site/cl-irc-0.8.1/protocol.lisp" {B0B19E1}>: > ; Symbol "FLEXI-STREAM-ENCODING-ERROR" not found in the FLEXI-STREAMS package. > ; compilation aborted after 0:00:00 > > WARNING: > COMPILE-FILE warned while performing #<COMPILE-OP NIL {AE24061}> on > #<CL-SOURCE-FILE "protocol" {A8F0201}>. > > debugger invoked on a ASDF:COMPILE-FAILED in thread #<THREAD "initial thread" RUNNING {A834589}>: > erred while invoking #<COMPILE-OP NIL {AE24061}> on > #<CL-SOURCE-FILE "protocol" {A8F0201}> > ---------------------------------------------------------------- > > > Line 349 of protocol.lisp is in this function: > > ---------------------------------------------------------------- > (defun try-decode-line (line external-formats) > (loop for external-format in external-formats > for decoded = nil > for error = nil > do (multiple-value-setq (decoded error) > (handler-case > (flexi-streams:with-input-from-sequence (in line) > (let ((flexi (flexi-streams:make-flexi-stream in > ;; :element-type 'character > :external-format > (external-format-fixup external-format)))) > (read-line flexi nil nil))) > (flexi-streams:flexi-stream-encoding-error () ;; <-- line 349 > nil))) > if decoded > do (return decoded))) > ---------------------------------------------------------------- > > > The flexi-streams package that asdf-install automatically installed is > 1.0.5. The flexi-streams documentation > (http://weitz.de/flexi-streams/) doesn't refer to any > flexi-stream-encoding-error, though there is an > external-format-encoding-error. Replacing the former with the latter > allowed cl-irc to compile, though I haven't used cl-irc enough at this > point to tell if this is actually correct. > > Could someone [you :)] confirm that this is change is correct? I think this is indeed correct: the flexi-streams version cl-irc used to be based on was a pre-1.0 version. Apparently, some classes have been renamed. I'll check in the repository if this has already been updated. If not, consider it so. However, since there's some partially completed code in the trunk, I can't really create a new release the way it is now. So, until usocket has its 0.4 release, we're stuck with the version currently available on the web as the latest release. Bye, Erik.

1 0