|
From: Lawrence M. <we...@gm...> - 2004-05-13 18:12:48
|
Lawrence Mitchell wrote: Right, I've now committed, should you not wish to run around with a buggy ERC, you can get the pre-changes tree by checking out files with the PRE_NEW_BACKEND symbolic tag (only those that I had to change have this tag, some files are unchanged). > well, I think I've just about ported all of ERC to a new backend > interface (I've been running without error for a few hours now). > erc-members.el has /not/ been ported, I think this is obsolete > anyway, with the advent of jbms' hashtable channel-members stuff. Anyone have any comments on this? [...] > All server response handlers should be defined with > `deferc-response-handler'. This defines functions and > corresponding hook variables. This is now define-erc-response-handler, it works exactly the same way though. [...] > (gethash (format (if (numberp command) "%03i" "%s") command) > erc-server-responses) > This will get a wrapper function, it doesn't have one yet. It has one, it's called `erc-get-hook', and takes as an argument, a server command, e.g. "MOTD", or a numeric response, e.g. 001. [...] This warning still applies :) > WARNING WARNING!! > I have not tested the new code with all bits of ERC, I've put > FIXMEs in a bunch of places where I'm not sure I correctly > interpreted the previous implementation's magic numbers (I > haven't waded through the IRC spec in great detail, lots of it > has been a trial-and-error thing). Please run with uncompiled > code and with debug-on-error set to t. The backtrace will > generally contain a complete `erc-response' struct, a copy of > this, and which ERC function caused the error are the two bits > of information most needed to fix things. I just compare what > the old code did with what the new code does with that test > case. -- Lawrence Mitchell <we...@gm...> |