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

[cl-irc-devel] Regarding the recent 'invalidate-me' commit
by Erik Huelsmann 29 Aug '04

29 Aug '04

Brian, I have 2 things I want to ask you about the 'invalidate-me' condition: - Did you consider closing the stream which has to be invalidated next to invalidating the handle? That way callers will know the input-reading subsystem gave up on that stream. - The invalidate-me condition can leak from the package, because in any of the cases not addressed by #+(and sbcl (not sb-thread)) the condition will not be cought within the package. Yet the symbol has not been exported. Did you plan to keep the condition within the package? bye, Erik. -- Superg�nstige DSL-Tarife + WLAN-Router f�r 0,- EUR* Jetzt zu GMX wechseln und sparen http://www.gmx.net/de/go/dsl

1 0

[cl-irc-devel] Implementing MODE messages and mode tracking
by Erik Huelsmann 23 Aug '04

23 Aug '04

Hi, For my application I wanted to track user modes (mostly the operator mode actually). So I decided to jump into the different modes in different networks. It turned out to be a challenge :-) So I decided to implement (for now) only the modes in the RFC since those seem to be common for all networks. The framework should be really easy to expand later on. This is what I did: Both channels and users have a 'modes' slot which is of type plist (because they are typically small lists). Channel modes can have zero or one argument. Some modes messages set one value, others add to a list of values. The channel key being in the first category, ban lists in the second. This means there are 3 different mode types with 2 major categories: * modes which are either on or off * modes with a value, which are divided into two groups too: - modes with exactly one value - modes with a list of values In order to know how to process the MODE arguments, a structure is required which holds the mode message description. I chose an assoc list for that. In order to hide the differences between the networks (using different characters for different modes), I introduced a 'character -> keyword' mapping. Applications can use the keywords instead of the mode characters in order to become network independent. The library will have to select the right mapping upon connection to the server (or pick the default and only support the RFC). The code is adapted to: * A new 'default-hook' with an irc-mode-message argument is implemented to handle (known) mode changes. * The names-reply is adapted to pick out nicks with the @-sign to be added to the channels op-list. * The quit- and part-message hooks are updated to update any modes on the user and channels he parted. * The library user and channel management routines updated to update modes according to the action required. Anybody interested in seeing a patch? bye, Erik. -- Superg�nstige DSL-Tarife + WLAN-Router f�r 0,- EUR* Jetzt zu GMX wechseln und sparen http://www.gmx.net/de/go/dsl

3 3

[cl-irc-devel] Latest commit = Fix non-threaded SBCL && remove 'server-socket' slot (again)
by Erik Huelsmann 21 Aug '04

21 Aug '04

Hi all, I don't think my commit came through with a commit message, but the code Brian checked in to detect stream failure did not work on my (non-threaded) SBCL 0.8.12 and .13. What I saw was endless looping and the code I had to detect connection-loss was not working anymore. I fixed that and I removed the server-socket field from the connection class again. I still believe that a slot which is only used on one platform (and only in a special case at that: SBCL + non-threading) should not be part of any classes public parts. Hope you don't mind me doing so. I saw that I'll also have to remove the 'socket' slot from the dcc-connection class. I will do that later. bye, Erik. -- NEU: Bis zu 10 GB Speicher f�r e-mails & Dateien! 1 GB bereits bei GMX FreeMail http://www.gmx.net/de/go/mail

1 0