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

[cl-irc-devel] [PATCH] keeping users administration synched
by Erik Huelsmann 23 Jun '04

23 Jun '04

While trying to implement the irc-mode-message hook (and thus modes) in the library, I found some instances defunct users are not cleaned. The patch below resolves that for the most part, but there is one instance which I can't clear up with a minimal patch. To clear up the workaround in the event.lisp handlers, I'd need to add a connection slot to the channel class. What is the general sentiment about this patch? bye, Erik. Index: event.lisp =================================================================== RCS file: /project/cl-irc/cvsroot/cl-irc/event.lisp,v retrieving revision 1.4 diff -u -5 -r1.4 event.lisp --- event.lisp 21 May 2004 19:12:06 -0000 1.4 +++ event.lisp 23 Jun 2004 19:10:26 -0000 @@ -85,11 +85,15 @@ (let* ((connection (connection message)) (channel (find-channel connection (first (arguments message)))) (user (find-user connection (source message)))) (if (self-message-p message) (remove-channel user channel) - (remove-user channel user)))) + (unless (remove-user channel user) + ;; workaround for remove-user on channel objects: + ;; if the user parts but does not stay in any other channels: + ;; remove the object from the connection + (remove-user connection user))))) (defmethod default-hook ((message irc-quit-message)) (let ((connection (connection message))) (remove-user-everywhere connection (find-user connection (source message))))) @@ -102,11 +106,15 @@ (let* ((connection (connection message)) (channel (find-channel connection (first (arguments message)))) (user (find-user connection (second (arguments message))))) (if (self-message-p message) (remove-channel user channel) - (remove-user channel user)))) + (unless (remove-user channel user) + ;; workaround for remove-user on channel objects: + ;; if the user parts but does not stay in any other channels: + ;; remove the object from the connection + (remove-user connection user))))) (defmethod default-hook ((message ctcp-time-message)) (multiple-value-bind (second minute hour date month year day) (get-decoded-time) (send-irc-message (connection message) Index: protocol.lisp =================================================================== RCS file: /project/cl-irc/cvsroot/cl-irc/protocol.lisp,v retrieving revision 1.9 diff -u -5 -r1.9 protocol.lisp --- protocol.lisp 22 Jun 2004 18:47:08 -0000 1.9 +++ protocol.lisp 23 Jun 2004 19:10:28 -0000 @@ -357,25 +357,35 @@ be found, return nil." (let ((channel-name (normalize-channel-name channel))) (gethash channel-name (channels connection)))) (defmethod remove-all-channels ((connection connection)) - "Remove all channels known to `connection'." + "Remove all channels known to `connection' keeping `user(s)' in sync." + (setf (channels (user connection)) nil) + (clrhash (users connection)) (clrhash (channels connection))) (defmethod add-channel ((connection connection) (channel channel)) "Add `channel' to `connection'." (setf (gethash (normalized-name channel) (channels connection)) channel)) (defmethod remove-channel ((connection connection) (channel channel)) - "Remove `channel' from `connection'." + "Remove `channel' from `connection' keeping `users' in sync." + (remove-users channel) (remhash (normalized-name channel) (channels connection))) (defmethod remove-users ((channel channel)) "Remove all users on `channel'." + (maphash #'(lambda (nick user) (remove-channel user channel)) + (users channel)) (clrhash (users channel))) +(defmethod real-user-count ((channel channel)) + (if (zerop (hash-table-count (users channel))) + (user-count channel) + (hash-table-count (users channel)))) + ;; ;; User ;; (defclass user () @@ -463,15 +473,19 @@ (defmethod add-user ((channel channel) (user user)) (setf (gethash (normalized-nickname user) (users channel)) user) (pushnew channel (channels user))) (defmethod remove-all-users ((connection connection)) - "Remove all users known to `connection'." + "Remove all users known to `connection' keeping `channels' in sync." + (maphash #'(lambda (key channel) (remove-users channel)) + (channels connection)) (clrhash (users connection))) (defmethod remove-user ((channel channel) (user user)) "Remove `user' from `channel' and `channel' from `user'." + ;;FIXME: remove this user from the connection when he has no channels! + ;; problem: there is no connection instance to remove from.... (remhash (normalized-nickname user) (users channel)) (setf (channels user) (remove channel (channels user)))) (defmethod remove-channel ((channel channel) (user user)) "Remove `channel' from `user'." @@ -480,12 +494,12 @@ "use of depricated API (remove-channel channel user): " "(remove-channel user channel) is now preferred")) (remove-channel user channel)) (defmethod remove-channel ((user user) (channel channel)) - "Remove `channel' from `user'." - (setf (channels user) (remove channel (channels user)))) + "Remove `channel' from `user' vice versa." + (remove-user channel user)) (defmethod remove-user ((connection connection) (user user)) "Remove `user' from `connection' but leave user in any channels he may be already be on." (remhash (normalized-nickname user) (users connection))) -- "Sie haben neue Mails!" - Die GMX Toolbar informiert Sie beim Surfen! Jetzt aktivieren unter http://www.gmx.net/info

1 0

[cl-irc-devel] No commit messages
by Erik Huelsmann 17 Apr '04

17 Apr '04

Several weeks ago I saw a commit mail comming through the cl-irc-cvs mailing list. Whenever I commit (yesterday and before the debian commit) I don't see a mail comming through the list. Is the repository configured in such a way that it does not always generate a commit mail? bye, Erik. -- NEU : GMX Internet.FreeDSL Ab sofort DSL-Tarif ohne Grundgebühr: http://www.gmx.net/info

1 0

[cl-irc-devel] RFC: Add modes to users and channels
by Erik Huelsmann 04 Apr '04

04 Apr '04

I found the TODO list and am trying to implement modes for channels and users. I have come up with a design which depends on the following preconditions: - user mode flags don't take arguments; - channel mode flags can have no argument, or - channel mode flags might have one argument, being one from the following types: * a single value (+/- l <max-users>) * a value to be added / removed from a list, which can either be + a nickname (+/- o <nick>) + some other value (+/- b <ban-mask>) - user modes which can be different per channel (chan-op for ex.) are channel characteristics I intend adding a 'mode' slot in the 'user' class. This slot can hold a string with all characters for modes which have been set on the user. Implicitly this means that any character not present in the mode string has not been a user characteristic or has been 'MODE -<char>'-ed. Further more do I intent do add a 'modes' slot to the 'channel' class. This slot will contain an assoc list of mode characters with their arguments. Each entry in the assoc list will be: - just the mode character itself if the mode does not take arguments; - a dotted list (#\<char> . <value>) if the mode is a single value; - a list (#\<char> &rest) if the mode maintains a list, where: * &rest are user objects if the mode takes a nickname for its argument; * &rest are strings otherwise. In order to know which channel modes take arguments a list of channel modes is to be composed. I think this list should be stored in the variables.lisp file. I thought to name it *channel-modes*. To be able to fill this list, there is the RFC which describes some modes, but to my understanding each network / ircd implements its own superset of what is in the RFC. To be able to process a MODE message, all these should be in the *channel-modes* list. Some questions remain: * If that list is not complete: What to do with unknown MODEs in a MODE message? (My first intuition: don't take action on it; other handlers still can) * Should a new kind of event be introduced to signal the application the results of the parsed MODE message? (first intuition: no, let it reparse any MODE messages itself, if it wants to, as with all other messages now) To be able to use mode names instead of mode identifiers (chars), I propose implementing two lists which map the identifiers to names like the *reply-names* list. (For channel modes this function can be integrated into the *channel-modes* list.) Is this a sound design? What do you think? Expecting problems/bad match with the current implementation? bye, Erik. -- +++ NEU bei GMX und erstmalig in Deutschland: TÜV-geprüfter Virenschutz +++ 100% Virenerkennung nach Wildlist. Infos: http://www.gmx.net/virenschutz

1 0

[cl-irc-devel] [PATCH] Add ChangeLog file
by Erik Huelsmann 16 Mar '04

16 Mar '04

Ok, the first commit in the ChangeLog I propose would contain the following: Now 's the time to object although I presume that the previous 'Ok' still stands. bye, Erik. +++ ChangeLog 2004-03-16 21:39:43.413843588 +0100 @@ -0,0 +1,9 @@ + + + * package.lisp (export): export symbols needed for manipulation + of the different objects + +2004-03-08: + Started tracking changes committed to the repository in this log. + + The ordering in this file is last-at-top. -- +++ NEU bei GMX und erstmalig in Deutschland: TÜV-geprüfter Virenschutz +++ 100% Virenerkennung nach Wildlist. Infos: http://www.gmx.net/virenschutz

1 0

[cl-irc-devel] [PATCH] make remove-channel api consistent
by Erik Huelsmann 14 Mar '04

14 Mar '04

Hi! On my quest for defmethods that needed defgenerics, I found an inconsistency in the API. I have no idea if this project has any provisions or policies about breaking APIs, so I'm mailing the list. The add-* apis use the object to add to as the first parameter and the object to be added as the second. So does the remove-channel api, except for one point: (remove-channel <channel-object> <user-object>). Resolving this item is not critical, but nice to have. Since parts of code of external parties might depend on the api, I decided to add a warn statement, but leave the api in place. I added a new defmethod which is the same, except that it has its parameters reversed. I'll rewrite the library (and possibly the examples) to use the new API ofcourse - given that there will be no objections. bye, Erik. PS: I don't think I can remember the changes I am committing some months from now, so I'll institute the ChangeLog as previously discussed. The patch: Index: protocol.lisp =================================================================== RCS file: /project/cl-irc/cvsroot/cl-irc/protocol.lisp,v diff -u -r1.2 protocol.lisp --- protocol.lisp 8 Jan 2004 23:11:47 -0000 1.2 +++ protocol.lisp 14 Mar 2004 18:34:35 -0000 @@ -437,6 +437,14 @@ (defmethod remove-channel ((channel channel) (user user)) "Remove `channel' from `user'." + (warn + (concat 'string + "use of depricated API (remove-channel channel user): " + "(remove-channel user channel) is now preferred")) + (remove-channel user channel)) + +(defmethod remove-channel ((user user) (channel channel)) + "Remove `channel' from `user'." (setf (channels user) (remove channel (channels user)))) (defmethod remove-user ((connection connection) (user user)) -- +++ NEU bei GMX und erstmalig in Deutschland: TÜV-geprüfter Virenschutz +++ 100% Virenerkennung nach Wildlist. Infos: http://www.gmx.net/virenschutz

1 0

[cl-irc-devel] [PATCH] Add defgeneric forms to eliminate style warnings
by Erik Huelsmann 14 Mar '04

14 Mar '04

Hi, Attached is the beginnings of a patch to eliminate style warnings which appear when compiled code is loaded using (asdf:operate 'asdf:load-op 'cl-irc). When using require these warnings don't occur, but that method is said to be only supported on SBCL. While trying to make my own application warning-free, I started doing cl-irc too. If anybody objects to me adding defgenerics, please say so. Also, the current patch adds these defgenerics in the middle of the protocol.lisp file. I think I prefer the beginning of the file, but if anybody has an opinion on that subject I'd like to know that too. bye, Erik. Index: event.lisp =================================================================== RCS file: /project/cl-irc/cvsroot/cl-irc/event.lisp,v --- event.lisp 5 Jan 2004 14:13:03 -0000 1.1.1.1 +++ event.lisp 10 Mar 2004 22:08:40 -0000 @@ -14,6 +14,12 @@ (apply-to-hooks message) (client-log (connection message) message "UNHANDLED-EVENT:")) + +(defgeneric default-hook (message) + (:documentation "Minimum action to be executed upon reception +of the IRC message to keep the connection, channel and user +objects in sync.")) + (defmethod default-hook ((message irc-rpl_whoisuser-message)) (let ((user (find-user (connection message) (second (arguments message)))) Index: protocol.lisp =================================================================== RCS file: /project/cl-irc/cvsroot/cl-irc/protocol.lisp,v --- protocol.lisp 8 Jan 2004 23:11:47 -0000 1.2 +++ protocol.lisp 10 Mar 2004 22:08:41 -0000 @@ -61,6 +61,23 @@ (print-unreadable-object (object stream :type t :identity t) (princ (server-name object) stream))) +(defgeneric add-default-hooks (connection)) +(defgeneric client-raw-log (connection message)) +(defgeneric connectedp (connection)) +(defgeneric read-message (connection)) +(defgeneric start-process (function name)) +(defgeneric start-background-message-handler (connection)) +;;(defgeneric stop-background-message-handler (process)) +(defgeneric read-message-loop (connection)) +(defgeneric read-irc-message (connection)) +(defgeneric send-irc-message (connection command + &optional trailing-argument &rest arguments)) +(defgeneric get-hooks (connection class)) +(defgeneric add-hook (connection class hook)) +(defgeneric remove-hook (connection class hook)) +(defgeneric remove-hoods (connection class)) +(defgeneric remove-all-hooks (connection)) + (defun make-connection (&key (user nil) (server-name "") (server-socket nil) @@ -239,6 +256,8 @@ #-sbcl (warn "make-dcc-connection not supported for this implementation.")) +(defgeneric dcc-close (connection)) + (defmethod read-message ((connection dcc-connection)) (let ((message (read-line (dcc-stream connection)))) (format (output-stream connection) "~A~%" message) @@ -323,6 +342,12 @@ (add-user channel user)) channel)) +(defgeneric find-channel (connection channel)) +(defgeneric remove-all-channels (connection)) +(defgeneric add-channel (connection channel)) +(defgeneric remove-channel (connection channel)) +(defgeneric remove-users (channel)) + (defmethod find-channel ((connection connection) (channel string)) "Return channel as designated by `channel'. If no such channel can be found, return nil." @@ -409,6 +434,16 @@ (new-string (substitute #\~ #\^ new-string))) (string-downcase new-string))) +(defgeneric find-user (connection nickname)) +(defgeneric add-user (object user)) +(defgeneric remove-all-users (connection)) +(defgeneric remove-user (object user)) +;;(defgeneric remove-channel (channel user)) +(defgeneric remove-user-everywhere (connection user)) +(defgeneric find-or-make-user (connection nickname + &key username hostname realname)) +(defgeneric change-nickname (connection user new-nickname)) + (defmethod find-user ((connection connection) (nickname string)) "Return user as designated by `nickname' or nil if no such user is known." @@ -513,6 +548,11 @@ (print-unreadable-object (object stream :type t :identity t) (format stream "~A ~A" (source object) (command object)))) +(defgeneric self-message-p (message)) +(defgeneric find-irc-message-class (type)) +(defgeneric client-log (connection message &optional prefix)) +(defgeneric apply-to-hooks (message)) + (defmethod self-message-p ((message irc-message)) "Did we send this message?" (string-equal (source message) @@ -577,6 +617,8 @@ :accessor ctcp-command))) (defclass standard-ctcp-message (ctcp-mixin message) ()) + +(defgeneric find-ctcp-message-class (type)) (defmacro define-ctcp-message (ctcp-command) (let ((name (intern-message-symbol :ctcp ctcp-command))) -- +++ NEU bei GMX und erstmalig in Deutschland: TÜV-geprüfter Virenschutz +++ 100% Virenerkennung nach Wildlist. Infos: http://www.gmx.net/virenschutz

1 0

Re: [cl-irc-devel] cl-irc-cvs commit mails?
by Erik Huelsmann 09 Mar '04

09 Mar '04

Hi Erik, > It seems that everything you are doing is correct. I see that the mail > went through fine in Exim also. No errors apparently. I just tried sending > on from my account and it went through so perhaps we just saw some > intermittent bugs of some sorts. Could you try again? I saw your test mail. It came to my box nicely. Did you see the commit mail itself? Anyway, I'll be committing the export of add-default-hooks and remove-all-hooks tonight, so I'll be able to see what happens... > > Also, I noticed there not being a ChangeLog or Changes file in the > > repository. I guess there is no protocol to keep track of commits to > > the repository then? Could someone please confirm (or deny :-) ) this? > > I don't think there is one. You can add one if you like. Well, I wasn't really looking for that kind of work :-) but if the the group thinks it's a good idea to add one, I'll be happy to start one. bye, Erik. -- +++ NEU bei GMX und erstmalig in Deutschland: TÜV-geprüfter Virenschutz +++ 100% Virenerkennung nach Wildlist. Infos: http://www.gmx.net/virenschutz

2 1

[cl-irc-devel] Next commit; no commit mail
by Erik Huelsmann 09 Mar '04

09 Mar '04

Hi. Sorry to intrude again. I committed my next commit (also a change to package.lisp) making available add-default-hooks and remove-all-hooks. As last time, I expected a mail from cl-irc-cvs@ to confirm the commit but like last time, I did not recieve one. I'm not concerned about this, but I like to review my own changes right after committing by reading the commit mail. It's also a check to see if I put in the right commit message. Anyway: further changes I will propose on the list first and commit after a few days (with no reaction) or after approval. bye, Erik. -- +++ NEU bei GMX und erstmalig in Deutschland: TÜV-geprüfter Virenschutz +++ 100% Virenerkennung nach Wildlist. Infos: http://www.gmx.net/virenschutz

1 0

[cl-irc-devel] cl-irc-cvs commit mails?
by Erik Huelsmann 09 Mar '04

09 Mar '04

Hi, Last night I committed the change I proposed on the list to the CVS repository at common-lisp.net. Before doing that I subscribed to cl-irc-cvs@.. but I didn't see any commit mail. Am I doing something wrong or should I not expect a commit mail this soon? Also, I noticed there not being a ChangeLog or Changes file in the repository. I guess there is no protocol to keep track of commits to the repository then? Could someone please confirm (or deny :-) ) this? Working to get past the initial quircks, but slowly getting there.... bye, Erik. -- +++ NEU bei GMX und erstmalig in Deutschland: TÜV-geprüfter Virenschutz +++ 100% Virenerkennung nach Wildlist. Infos: http://www.gmx.net/virenschutz

2 1

[cl-irc-devel] Not all package elements exported
by Erik Huelsmann 03 Mar '04

03 Mar '04

Hi, Working further with the cl-irc library, I found that not all methods and classes are exported. Is it intentional that the following keys are not exported from the package? - nickname - channel - users - name (as in the slot of the channel class) and maybe others I did not check. If it is not intentional, then is there a guideline on what should be exported? I can write a patch if there is something like that... Bye, Erik. -- +++ NEU bei GMX und erstmalig in Deutschland: TÜV-geprüfter Virenschutz +++ 100% Virenerkennung nach Wildlist. Infos: http://www.gmx.net/virenschutz

2 2