| --- Log opened Fri May 28 00:00:16 2010 |
| 00:08 | | Derakon [Derakon@Nightstar-5213d778.ca.comcast.net] has quit [Ping timeout: 121 seconds] |
| 01:51 | | Derakon [Derakon@Nightstar-5213d778.ca.comcast.net] has joined #code |
| 01:51 | | mode/#code [+o Derakon] by Reiver |
| 02:00 | | Zed [Zed@Nightstar-e4835f03.or.comcast.net] has quit [Ping timeout: 121 seconds] |
| 02:26 | | Kazriko [kaz@Nightstar-e09690fa.client.bresnan.net] has joined #code |
| 02:26 | | mode/#code [+o Kazriko] by Reiver |
| 02:28 | | Reiv[Graduate] [orthianz@Nightstar-2faea954.xnet.co.nz] has joined #code |
| 02:30 | | Thaqui [Thaqui@27B34E.D54D49.F53FA1.6A113C] has joined #code |
| 02:47 | | gnolam [lenin@Nightstar-38637aa0.priv.bahnhof.se] has quit [[NS] Quit: Z?] |
| 03:44 | | Orth [orthianz@Nightstar-4dd10d2b.xnet.co.nz] has joined #code |
| 03:44 | | Serah [Z@3A600C.A966FF.5BF32D.8E7ABA] has quit [Ping timeout: 121 seconds] |
| 03:45 | | Reiv[Graduate] [orthianz@Nightstar-2faea954.xnet.co.nz] has quit [Ping timeout: 121 seconds] |
| 04:16 | | celticminstrel [celticminstre@Nightstar-f8b608eb.cable.rogers.com] has quit [Connection closed] |
| 04:16 | | celticminstrel [celticminstre@Nightstar-f8b608eb.cable.rogers.com] has joined #code |
| 05:48 | | cpux is now known as cpux|whump|zzzz |
| 05:52 | | Orth [orthianz@Nightstar-4dd10d2b.xnet.co.nz] has quit [Client closed the connection] |
| 05:59 | | Reiv[Graduate] [orthianz@Nightstar-4dd10d2b.xnet.co.nz] has joined #code |
| 06:08 | | AnnoDomini [annodomini@Nightstar-9440674e.adsl.tpnet.pl] has joined #code |
| 06:08 | | mode/#code [+o AnnoDomini] by Reiver |
| 06:37 | | Derakon is now known as Derakon[AFK] |
| 06:44 | | Reiv[Graduate] [orthianz@Nightstar-4dd10d2b.xnet.co.nz] has quit [Connection reset by peer] |
| 06:51 | | Reiv[Graduate] [orthianz@Nightstar-4dd10d2b.xnet.co.nz] has joined #code |
| 07:01 | | celticminstrel [celticminstre@Nightstar-f8b608eb.cable.rogers.com] has quit [[NS] Quit: *whistles* Did you hear something?] |
| 09:06 | | You're now known as TheWatcher |
| 09:18 | | Reiv[Graduate] is now known as Reivles |
| 09:22 | | Rhamphoryncus [rhamph@Nightstar-bbc709c4.abhsia.telus.net] has quit [Client exited] |
| 10:36 | | Serah [Z@3A600C.A966FF.5BF32D.8E7ABA] has joined #code |
| 11:42 | | Reiv[Graduate] [orthianz@Nightstar-33a5db92.xnet.co.nz] has joined #code |
| 11:44 | | Reivles [orthianz@Nightstar-4dd10d2b.xnet.co.nz] has quit [Ping timeout: 121 seconds] |
| 12:08 | | cpux|whump|zzzz is now known as shade_of_cpux |
| 12:29 | | Orth [orthianz@Nightstar-b72c52ad.xnet.co.nz] has joined #code |
| 12:30 | | Reiv[Graduate] [orthianz@Nightstar-33a5db92.xnet.co.nz] has quit [Ping timeout: 121 seconds] |
| 13:26 | | Thaqui [Thaqui@27B34E.D54D49.F53FA1.6A113C] has quit [Connection reset by peer] |
| 14:18 | | gnolam [lenin@Nightstar-38637aa0.priv.bahnhof.se] has joined #code |
| 14:48 | | Orth [orthianz@Nightstar-b72c52ad.xnet.co.nz] has quit [Connection reset by peer] |
| 14:54 | | Reiv[Graduate] [orthianz@Nightstar-b72c52ad.xnet.co.nz] has joined #code |
| 16:03 | | celticminstrel [celticminstre@Nightstar-f8b608eb.cable.rogers.com] has joined #code |
| 16:32 | | gnolam [lenin@Nightstar-38637aa0.priv.bahnhof.se] has quit [[NS] Quit: Lightning] |
| 16:47 | | gnolam [lenin@Nightstar-38637aa0.priv.bahnhof.se] has joined #code |
| 17:09 | | Attilla [Attilla@Nightstar-d665c003.threembb.co.uk] has joined #code |
| 17:09 | | mode/#code [+o Attilla] by Reiver |
| 17:37 | | Rhamphoryncus [rhamph@Nightstar-bbc709c4.abhsia.telus.net] has joined #code |
| 17:38 | | Serah [Z@3A600C.A966FF.5BF32D.8E7ABA] has quit [Ping timeout: 121 seconds] |
| 18:06 | | PinkCoffeeZombie is now known as PinkFreud |
| 18:09 | | AnnoDomini [annodomini@Nightstar-9440674e.adsl.tpnet.pl] has quit [Ping timeout: 121 seconds] |
| 18:11 | | AnnoDomini [annodomini@Nightstar-d8256a85.adsl.tpnet.pl] has joined #code |
| 18:11 | | mode/#code [+o AnnoDomini] by Reiver |
| 18:17 | | Serah [Z@26ECB6.A4B64C.298B52.D80DA0] has joined #code |
| 18:18 | < celticminstrel> | What do user-modes i, s, w do? Particularly i. |
| 18:32 | < gnolam> | Invisible. |
| 18:33 | < celticminstrel> | Yeah, but what does that actually mean? |
| 18:36 | < gnolam> | Prevents you from showing up in a /who query. |
| 18:37 | < celticminstrel> | Ah. That's all? |
| 18:38 | < gnolam> | Yup. |
| 18:38 | < celticminstrel> | Can anyone set it, or just ops? |
| 18:38 | < celticminstrel> | (And by ops I mean IRCops.) |
| 18:39 | < gnolam> | Anyone. |
| 18:40 | < gnolam> | celticminstrel: http://tools.ietf.org/html/rfc1459#section-4.2.3.2 |
| 18:40 | < celticminstrel> | Ooh, that looks like a better RFC source than the one I found. |
| 18:46 | < PinkFreud> | who the hell writes an imap client which chokes on a tab in a server response? |
| 18:46 | < PinkFreud> | er, other than Google. *sigh* |
| 18:46 | | * Tarinaky blinks. You managed to kill a connection with whitespace? |
| 18:46 | < Tarinaky> | Impressive! |
| 18:47 | < PinkFreud> | http://code.google.com/p/android/issues/detail?id=5685#c8 |
| 18:52 | < gnolam> | http://www.engadget.com/2010/05/28/opera-parodies-googles-chrome-speed-tests-mer cilessly-video/ |
| 18:55 | | Reiv[Graduate] [orthianz@Nightstar-b72c52ad.xnet.co.nz] has quit [Ping timeout: 121 seconds] |
| 18:59 | < celticminstrel> | Yay, RFC2811 seems to describe what all the channel modes mean in detail. |
| 18:59 | < PinkFreud> | standard channel modes, yes |
| 18:59 | < celticminstrel> | Right. |
| 19:00 | < PinkFreud> | you said 'all'. There are often far more channel modes available than the ones defined in the rfc |
| 19:00 | < celticminstrel> | Oh, well, close enough. |
| 19:00 | < PinkFreud> | just making sure you knew the difference :) |
| 19:00 | < celticminstrel> | And RFC2812 looks like a replacement/extension for RFC1459... |
| 19:01 | < Tarinaky> | Well. IRC as a whole is the combination of about three different RFCs isn't it? |
| 19:01 | < celticminstrel> | There's apparently 2810..2813. |
| 19:01 | < celticminstrel> | Plus 1459, and the CTCP specification. |
| 19:01 | < PinkFreud> | http://wiki.inspircd.org/Channel_Modes |
| 19:01 | < celticminstrel> | Looks like I won't care about 2813. |
| 19:02 | < PinkFreud> | that's a specific example, and one that's relevant to this network |
| 19:02 | < celticminstrel> | You can't +q on this network, I discovered. |
| 19:02 | < PinkFreud> | that's because it's set by servers |
| 19:02 | | Derakon [Derakon@Nightstar-1ffd02e6.ucsf.edu] has joined #code |
| 19:02 | | mode/#code [+o Derakon] by Reiver |
| 19:03 | < celticminstrel> | You can on some networks. |
| 19:03 | <@Derakon> | % grep -r numExtHdrFloats * |
| 19:03 | <@Derakon> | experiment/helpers.py:from sebH import numExtHdrFloats |
| 19:03 | <@Derakon> | experiment/helpers.py: extHdrNfloats=numExtHdrFloats |
| 19:03 | <@Derakon> | sebH.py:numExtHdrFloats=8 |
| 19:03 | < PinkFreud> | it's one of the modular modes listed on that page, provided by the m_chanprotect module for insp |
| 19:03 | | * Derakon mutters imprecations under his breath. |
| 19:03 | < PinkFreud> | and +q does work here, if you're a server. :) |
| 19:03 | < celticminstrel> | Yeah, but when I say "you" I assume "you" are a user. |
| 19:03 | < celticminstrel> | Otherwise I'd say "it" or something. |
| 19:08 | < PinkFreud> | heh, indeed |
| 19:12 | < celticminstrel> | By the way, is their any documentation of CTCP SED anywhere? Do any clients even support it? |
| 19:12 | < celticminstrel> | ^there |
| 19:13 | < PinkFreud> | dunno |
| 19:13 | < celticminstrel> | Supposedly it's a way to send encrypted messages. |
| 19:14 | < celticminstrel> | Also, CTCP ACTION in a NOTICE rather than a PRIVMSG... is that invalid? |
| 19:15 | < PinkFreud> | probably, since clients dhouldn't respond to ctcp action |
| 19:16 | < celticminstrel> | I tested, and my client interprets incoming ones as a normal action message, but it seems other clients don't. |
| 19:16 | < Namegduf> | It's meaningless. |
| 19:16 | < PinkFreud> | 14:15 [Nightstar] CTCP ACTION reply from PinkFreud: foobar |
| 19:17 | < Namegduf> | CTCP in a NOTICE is a CTCP reply. |
| 19:17 | < celticminstrel> | 'kay |
| 19:17 | < PinkFreud> | irssi processes it as a response |
| 19:17 | < PinkFreud> | yep |
| 19:17 | < Namegduf> | A reply to a message you've sene. |
| 19:17 | < Namegduf> | This is, for actions, basically meaningless |
| 19:17 | < Namegduf> | You're not expecting a reply |
| 19:17 | < Namegduf> | It carries no meaning within the protocol. |
| 19:17 | < celticminstrel> | 'kay :) |
| 19:51 | | * Derakon finds a typo through the judicious use of sort, uniq, and perl. |
| 19:51 | <@Derakon> | curCamEMconvMod is not curCamEMconvMode |
| 19:52 | <@Derakon> | (Net effect: if you were to connect any new cameras after setting the camera mode to electron-multiplied 16-bit mode, they wouldn't work properly. Fortunately nobody ever uses EM16 mode) |
| 20:21 | <@Derakon> | Down to 100 unique global variables... |
| 21:06 | < celticminstrel> | RFC2811 defines +q as "quiet", but here +q is "founder"... is it normal for "quiet" to be unsupported? |
| 21:08 | | * Derakon aughs as he discovers the global variable name "f". |
| 21:08 | <@Derakon> | Seriously, Sebastian, is it that fucking hard to write out "filehandle"? |
| 21:08 | <@Derakon> | Or even just "file"! |
| 21:08 | <@Derakon> | And you only use it in one module anyway! |
| 21:09 | < celticminstrel> | I have used "file" in the past, but I try to avoid it because it's also the name of a class. |
| 21:09 | <@Derakon> | Not only that, you use it in a single module that already has an associated data structure it stores all its other state in. |
| 21:10 | < celticminstrel> | I might use "f" as a variable name, but only a local variable. |
| 21:12 | <@Derakon> | The only single-letter variable names I use are i and j (and rarely k), and at that I generally try to use more descriptive names. |
| 21:13 | < celticminstrel> | I mostly use ijknmx for single-letter names, and only for indices (x usually for foreach loops). |
| 21:13 | <@Derakon> | Oh, I tell a lie. I use x and y when appropriate as positional variables. |
| 21:13 | < celticminstrel> | That too. |
| 21:14 | <@ToxicFrog> | I've been known to use ijk, xy, wh, rc, provided they're short-lived. |
| 21:15 | <@Derakon> | Yeah. |
| 21:15 | <@Derakon> | A variable's name should be directly proportional to its scope. |
| 21:15 | <@ToxicFrog> | Files are generally fin/fout for brief stuff. |
| 21:16 | <@Derakon> | s/name/name length/ |
| 21:16 | < celticminstrel> | The problem with the fin/fout naming convention is when you apply it to stringstreams. |
| 21:16 | <@Derakon> | sin/sout~? |
| 21:17 | < celticminstrel> | Yeah. sin is a math function. |
| 21:17 | <@Derakon> | Also a measure of AI naughtiness. |
| 21:17 | < celticminstrel> | Huh? |
| 21:17 | < celticminstrel> | Oh. XD |
| 21:17 | < celticminstrel> | Yeah, sure. :P |
| 21:21 | <@ToxicFrog> | I don't use stringstreams, so~ |
| 21:26 | <@Derakon> | Down to 97 global variables... |
| 21:32 | <@Derakon> | I'm at 20 checkins today. Almost all of them are excisions. |
| 21:48 | <@McMartin> | If you're taking an stringistream, there's no excuse to not just make it be a generic istream |
| 21:48 | < celticminstrel> | ...wait. Is 005 "server support" or "bounce"? Is there yet another standard that changes it to "server support"? |
| 21:48 | <@McMartin> | This is what istreams are for. |
| 21:48 | | * McMartin tends to name is "souts" "result", though. |
| 21:48 | <@McMartin> | *his "sout"s |
| 22:02 | <@ToxicFrog> | celticminstrel: 005 is nonstandard. It was RPL_BOUNCE on IRCnet at some point. |
| 22:03 | <@ToxicFrog> | It's also RPL_MAP and RPL_PROTOCTL depending on what ircd you connect to! |
| 22:03 | < celticminstrel> | What are those two? |
| 22:03 | <@ToxicFrog> | No idea. |
| 22:03 | < celticminstrel> | <_< |
| 22:03 | <@ToxicFrog> | ...actually, no, RPL_MAP is probably a reply to the MAP command |
| 22:04 | <@ToxicFrog> | However, for that, we have the more widely accepted 006 RPL_MAPMORE and 007 RPL_MAPEND numerics. |
| 22:35 | < celticminstrel> | Okay, so if I receive a 'MODE <channel> -o <nick>' message, is there a simple way to determine if the nick currently has voice? |
| 22:37 | <@Vornicus> | Usually I think that's done with state. |
| 22:38 | < celticminstrel> | Just by remembering if they had voice when they were opped? |
| 22:42 | < celticminstrel> | But how would that work if they were already opped when you joined? |
| 22:42 | <@Vornicus> | Yeah, though... that doesn't work very well when there's... yeah |
| 22:49 | < celticminstrel> | I guess sending NAMES in response to MODE will have to do, then. |
| 22:53 | <@Vornicus> | Only in the -o, -q, -v, -h, and -...shit, I don't remember the last one... cases. |
| 22:53 | < celticminstrel> | Only in subtract cases, eh? |
| 22:56 | < celticminstrel> | The last one would be -a, I think. |
| 22:56 | <@Vornicus> | yes. |
| 22:56 | <@Vornicus> | Because adding modes won't reveal ones you haven't seen. |
| 22:56 | < celticminstrel> | True. |
| 22:56 | < celticminstrel> | That means I need to know the symbols for qha |
| 22:58 | <@Vornicus> | q ~; a &; o @; h %; v +, in that order. |
| 22:58 | < celticminstrel> | :) |
| 23:02 | | Derakon [Derakon@Nightstar-1ffd02e6.ucsf.edu] has quit [[NS] Quit: Leaving] |
| 23:09 | <@Vornicus> | actually you never need to check -v, either |
| 23:09 | <@Vornicus> | (because it can't hide anything) |
| 23:10 | < celticminstrel> | ...well, if you -v when they're already opped... |
| 23:10 | < celticminstrel> | Still, that could be handled by checking the existing mode. |
| 23:15 | <@Vornicus> | Also true. If -h comes when you've got +o on the guy, you know that you won't reveal any new modes. |
| 23:44 | <@ToxicFrog> | Hmm. Let me test something. |
| 23:44 | | mode/#code [+v celticminstrel] by ToxicFrog |
| 23:44 | | mode/#code [+o celticminstrel] by ToxicFrog |
| 23:45 | | mode/#code [-o celticminstrel] by ToxicFrog |
| 23:45 | | mode/#code [-v celticminstrel] by ToxicFrog |
| 23:45 | <@ToxicFrog> | Ok! Use NAMES when you enter the channel. |
| 23:45 | <@ToxicFrog> | If someone is +ov they'll be prefixed with both "@" and "+". |
| 23:45 | < celticminstrel> | Really? |
| 23:45 | < Namegduf> | No. |
| 23:45 | <@ToxicFrog> | They are on this ircd. |
| 23:45 | < Namegduf> | No. :P |
| 23:46 | < Namegduf> | 1) Get a working CAP implementation, request CAP multi-prefix |
| 23:46 | < Namegduf> | 2) Send PROTOCTL NAMESX after registratino |
| 23:46 | < Namegduf> | And then they will be. |
| 23:46 | < Namegduf> | Most clients do this. |
| 23:46 | < celticminstrel> | ...how do I do step 1? |
| 23:46 | < Namegduf> | (2 is more common, has more IRCD support) |
| 23:46 | < celticminstrel> | Oh, never mind. |
| 23:46 | < celticminstrel> | I didn't realize they were alternates. |
| 23:46 | | You're now known as TheWatcher[T-2] |
| 23:47 | < Namegduf> | Yeah. |
| 23:47 | <@ToxicFrog> | Aah. |
| 23:47 | < Namegduf> | It's a non-backwards-compatible protocol change |
| 23:47 | < Namegduf> | 2 is the kinda hacky way implemented |
| 23:47 | < Namegduf> | 1 is the real connection capability negotiation |
| 23:47 | <@ToxicFrog> | And see, this is one of the reasons I like using xchat for bots: it handles this stuff for me |
| 23:47 | < Namegduf> | Yeah, a good framework should. |
| 23:48 | <@ToxicFrog> | By extension, any decent IRC bot library should also handle this stuff automatically |
| 23:48 | < celticminstrel> | How do I do #1? |
| 23:48 | < Namegduf> | celticminstrel: Lemme see if I can find docs on 1) |
| 23:48 | < Namegduf> | But it isn't worth it if you only want to do this and don't want to use SASL |
| 23:49 | < celticminstrel> | SASL? |
| 23:49 | < celticminstrel> | #2 works here but not on the other network. |
| 23:49 | < Namegduf> | SASL authentication; login to Services during registration, before full connection to te network.. |
| 23:49 | | You're now known as TheWatcher[zZzZ] |
| 23:49 | < Namegduf> | What's "the other network"? |
| 23:49 | < celticminstrel> | The one the bot is running on. |
| 23:49 | < Namegduf> | It may be sufficiently antiquated as to not permit NAMESX at all. |
| 23:49 | < Namegduf> | What IRCD? |
| 23:49 | < celticminstrel> | sorircd |
| 23:50 | < celticminstrel> | I think. |
| 23:50 | < Namegduf> | I'm thinking it's likely not to have CAP either |
| 23:50 | < celticminstrel> | Likely. |
| 23:50 | < Namegduf> | Which may mean the information isn't available and you're kinda stuck if it really matters |
| 23:50 | < Namegduf> | QuakeNet doesn't support CAP either |
| 23:51 | < Namegduf> | For their webclient, they hacked up a server to return NAMESX-like results always |
| 23:51 | < Namegduf> | And ran the webclient on that. |
| 23:52 | < Namegduf> | I don't think you're likely to see 1 available without 2 |
| 23:52 | < Namegduf> | I could be betraying my level of unfamiliarity with IRCDs I don't regularly use, though, potentially, but I doubt it. |
| 23:52 | < celticminstrel> | Does 'string'.format work if passed extraneous keys? |
| 23:53 | < celticminstrel> | ...wait. I can test this. |
| 23:53 | < celticminstrel> | It does not. |
| 23:53 | < celticminstrel> | Yay. |
| 23:53 | < celticminstrel> | . |
| 23:53 | < Namegduf> | ToxicFrog: I entirely agree that liking it because it happens to be a "decent IRC bo framework" by providing attributes we agree should be in one |
| 23:53 | < Namegduf> | ToxicFrog: Is totallyy reasonable |
| 23:54 | < Namegduf> | Sorry, netbook keyboard. |
| 23:55 | < Namegduf> | ToxicFrog: Really, my personal favourite bot framework |
| 23:55 | < Namegduf> | ToxicFrog: Is Atheme IRC Services |
| 23:55 | < Namegduf> | But that imposes a lot of constraints on where you expect to be running bots. |
| 23:56 | | * ToxicFrog nods |
| 23:56 | < Namegduf> | Just because integrated read-only mode for backup operation and authentication systems is really handy, for stuff I tend to be doing. |
| 23:57 | <@ToxicFrog> | Whereas I tend to be writing small, unimportant bots that don't really need authentication or backups :P |
| 23:57 | < Namegduf> | Yeah. |
| 23:58 | | shade_of_cpux is now known as cpux |
| --- Log closed Sat May 29 00:00:17 2010 |