| --- Log opened Wed Apr 24 00:00:19 2013 |
| 00:29 | | ToxicFrog|W`rkn is now known as ToxicFrog |
| 00:31 | | Chutzpah [Moltare@583787.FF2A18.190FE2.4D81A1] has quit [Ping timeout: 121 seconds] |
| 00:32 | | Chutzpah [Moltare@583787.FF2A18.190FE2.4D81A1] has joined #code |
| 00:50 | | Derakon[AFK] is now known as Derakon |
| 00:59 | | himi [fow035@D741F1.243F35.CADC30.81D435] has joined #code |
| 00:59 | | mode/#code [+o himi] by ChanServ |
| 01:55 | | Turaiel[Offline] is now known as Turaiel |
| 02:40 | | VirusJTG__ [VirusJTG@Nightstar-09c31e7a.sta.comporium.net] has joined #code |
| 02:43 | | VirusJTG_ [VirusJTG@Nightstar-09c31e7a.sta.comporium.net] has quit [Ping timeout: 121 seconds] |
| 03:06 | | Kindamoody[zZz] is now known as Kindamoody |
| 03:32 | <&Derakon> | Hey RichyB, could you explain the queue system you wrote for that heatmap code? |
| 03:33 | <&Derakon> | It's not clear to me how tail and head relate; it seems like tail has the lower memory address, which seems odd... |
| 03:33 | <&Derakon> | But then you sometimes set tail to 0, which means it loops around...? |
| 03:35 | < RichyB> | It's a circular queue. head is the position of the zeroeth queue item, tail is the position *after* the final item currently in the queue, and both are taken modulo q->size |
| 03:36 | < RichyB> | So the first edge cases is that if head==tail then the queue's empty. |
| 03:37 | <&Derakon> | Okay, that helps. |
| 03:37 | < RichyB> | The idea is that you should be able to en/de-queue an object in O(1) by advancing one of those two pointers. |
| 03:37 | <&Derakon> | (Your code is entirely undocumented, so I have to go in and understand it and document it. :) ) |
| 03:37 | < RichyB> | Only documentation's in the names. |
| 03:38 | < RichyB> | The other edge case is that because I didn't quite work it out perfectly, it currently wastes one pair's worth of memory, because if tail got far enough ahead to loop all the way around to head, I wouldn't be able to tell that the queue wasn't empty. |
| 03:39 | < RichyB> | That could be fixed, but I couldn't fit the necessary manipulations in my head at the time. |
| 03:40 | <&Derakon> | That's not a huge concern. One pair's worth of memory is not noticeable. |
| 03:40 | <&Derakon> | What is a concern is the hang lurking somewhere in there. :) |
| 03:40 | < RichyB> | Perfectionism ?ber alles! |
| 03:40 | < RichyB> | Derakon: is it deterministic? |
| 03:40 | <&Derakon> | Not sure yet... |
| 03:41 | < RichyB> | a) Do you have input which reliably triggers it? |
| 03:41 | < RichyB> | b) Regardless of whether the C module's built with -O2 or -O0? |
| 03:41 | <&Derakon> | Ah, yes, the maze test you wrote will trigger it. |
| 03:42 | <&Derakon> | Even if using -O0. |
| 03:42 | < RichyB> | Really? Dammit. |
| 03:44 | <&ToxicFrog> | No, that's awesome |
| 03:44 | <&ToxicFrog> | It means when it happens you can whack it into gdb and get sensible results |
| 03:44 | | Alek [omegaboot@Nightstar-56dbba0f.in.comcast.net] has quit [[NS] Quit: ] |
| 03:44 | <&Derakon> | I'm gonna finish whacking it into Pyrel's style guide first; maybe I'll notice the bug in the process. |
| 03:45 | < RichyB> | ToxicFrog: no, it's sucktastic because the same input doesn't trigger it for me. |
| 03:46 | | * Derakon eyes realloc, tries to figure out how much memory it copies from the old location. |
| 03:49 | < RichyB> | Derakon: precisely old_size*sizeof(pair) bytes, since that's how many were previously allocated. |
| 03:49 | <&Derakon> | How can it tell? |
| 03:49 | < RichyB> | realloc(3) says " The contents will be unchanged in the range from the start of the region up to the minimum of the old and new sizes." |
| 03:49 | <&Derakon> | I didn't think that the *alloc functions knew how much memory had been allocated in previous operations. |
| 03:50 | < RichyB> | Same way that free(3) remembers how big is the block that you pass to it by just a pointer. |
| 03:50 | <&Derakon> | Hunh, guess it's been awhile for me. |
| 03:52 | < RichyB> | Eh, splint really is amazingly stupid. |
| 03:53 | < RichyB> | Derakon: does yonder infinite loop go away if you change "memcpy" to "memmove" on line 24 of _cmap.c? |
| 03:53 | <&Derakon> | Nyet. |
| 03:54 | < RichyB> | Good. |
| 03:57 | < RichyB> | Derakon: you're on... Windows with MSYS or something? |
| 03:58 | <&Derakon> | OSX, gcc. |
| 03:58 | <&Derakon> | I should try to remember how to run things in gdb... |
| 04:00 | <&Derakon> | But it looks like the queue keeps looping over the same set of nodes over and over again. |
| 04:00 | <&Derakon> | 8,2 -> 4,0 -> 4,1 -> 3,1 -> 3,2 -> 2,2 -> 1,1 -> 1,2 -> 8,2 -> repeat |
| 04:01 | <&Derakon> | So I'd guess that tracking which positions are "used" isn't working properly. |
| 04:01 | <&Derakon> | BBIAB; dinner. |
| 04:06 | <&ToxicFrog> | Derakon: gdb; file <executable>; run |
| 04:07 | | VirusJTG__ [VirusJTG@Nightstar-09c31e7a.sta.comporium.net] has quit [[NS] Quit: Program Shutting down] |
| 04:13 | <&Derakon> | TF: complicated slightly by the fact that the executable is Python. |
| 04:14 | <&Derakon> | But anyway, I'm not certain how useful gdb will be for deciphering why tracking of used cells isn't working properly, seeing as RichyB decided to pack 8 booleans into every byte of memory~ |
| 04:14 | <&Derakon> | (By which I mean, deciphering things is more than just looking up memory values) |
| 04:14 | < RichyB> | "gdb --args python cmap.py" |
| 04:15 | < RichyB> | It's a bit-set. By definition if you use any more than one bit to represent one element, you've lost at compactness. :P |
| 04:16 | <&Derakon> | Memory is cheap. :p |
| 04:16 | <~Vornicus> | pdb |
| 04:16 | <~Vornicus> | but, uh |
| 04:17 | <&Derakon> | Vorn: I'm debugging a C library called from Python. |
| 04:17 | <~Vornicus> | ew |
| 04:17 | <~Vornicus> | Um |
| 04:17 | <~Vornicus> | Why the entire shit are you optimizing for space here? |
| 04:17 | <&Derakon> | Ask RichyB that! |
| 04:17 | <~Vornicus> | RichyB: why the entire shit are you optimizing for space here? |
| 04:18 | < RichyB> | Space is time; you have finite caches. |
| 04:19 | <~Vornicus> | ...is this an edge-weighted, or unweighted, graph? |
| 04:19 | < RichyB> | Show me using whole bytes or ints going any faster and I'll be very surprised. |
| 04:19 | <&Derakon> | Unweighted. |
| 04:19 | <~Vornicus> | Okay, so |
| 04:20 | <~Vornicus> | Absolute worst-case scenario, packing naked coordinates into bytes for a 256x256 realm, you're at absolute maximum 128kB. |
| 04:22 | <~Vornicus> | But it doesn't look like you have the code 'right' yet. are you sure you need to hop all the way down to bits? |
| 04:27 | <~Vornicus> | And if you do decide to, make it easier on yourself at least: make getters and setters for byte style visited-lists and use those, and then replace them with bit style lists. |
| 04:28 | <&Derakon> | I've done that now; no change in behavior. |
| 04:33 | <&Derakon> | Okay, looks like the actual problem is not recognizing that the queue is empty. |
| 04:37 | <&Derakon> | Hm, tail is 8, head is 0, size is 8. Should that even be possible? |
| 04:38 | <&Derakon> | tail should be the index of the last element in the queue, right? So it should never be equal to the size, which is the number of elements in the queue. |
| 04:40 | < RichyB> | tail can go briefly off the end before wrapping |
| 04:40 | < RichyB> | (it'll get wrapped on next queue_append) |
| 04:40 | < RichyB> | tail's meant to be the position *after* the last valid element, not the position *of* the last valid element. |
| 04:41 | <&Derakon> | But next queue_append never happens, because at the time we pop the last element, (tail - head) == size. |
| 04:41 | <&Derakon> | And the "get number of elements in queue" function doesn't handle that case properly. |
| 04:41 | <&Derakon> | (I renamed that function to getNumUsedElements) |
| 04:42 | < RichyB> | head, tail, size at (0, 8, 8) shouldn't be possible because queue_append should attempt a resize when you queue_append with (0, 7, 8). |
| 04:42 | <&Derakon> | Well, it's happening. |
| 04:43 | <&Derakon> | Adding a special case to the get-size-of-queue function fixed the infinite loop. |
| 04:43 | < RichyB> | I'm still confused by the fact that I haven't seen this infinite loop but it triggers reliably for you. |
| 04:43 | <&Derakon> | And again, remember we're reaching this state backwards, by popping off the queue. |
| 04:44 | < RichyB> | Uh, in which case - oh, right, that makes sense. |
| 04:44 | < RichyB> | tail got left at 8, head advanced up to it and then wrapped |
| 04:44 | <&Derakon> | :) |
| 04:45 | <&Derakon> | Would the proper solution here be to modify popLeft to set tail = head if tail % size == head? |
| 04:45 | < RichyB> | I think that a better fix is to reorder a few statements; put (if (q->tail == q->size) {...} *after* q->tail++; |
| 04:46 | <&Derakon> | Yeah, that makes sense. |
| 04:46 | <&Derakon> | And it passes the tests. |
| 04:46 | <&Derakon> | \o/ |
| 04:46 | < RichyB> | queue_used gets called more often than queue_append, I'd prefer having queue_used only have to deal with valid input than for it to tolerate a fuckup left behind by queue_append. |
| 04:47 | <&Derakon> | Makes sense. |
| 04:47 | | * RichyB headscratch. |
| 04:47 | < RichyB> | But how the FUCK does that never trigger for me? |
| 04:48 | <&Derakon> | An excellent question. I didn't see anything obviously platform-dependent in the code. |
| 04:49 | < RichyB> | Are you sure you didn't change the maze? Suddenly it manifests if I add one row to the right-hand-side of the maze. |
| 04:50 | <&Derakon> | Here's my modified version of the file: http://pastebin.com/t5cWb2fp |
| 04:50 | <&Derakon> | (Which reminds me to do :retab...) |
| 04:51 | < RichyB> | Ugh, your naming convention. |
| 04:51 | <&Derakon> | Heh. |
| 04:51 | < RichyB> | "freeQueue"? No, "queue_free". It's halfassed OO. |
| 04:51 | < RichyB> | Name of the type, then name of the operation. |
| 04:52 | < RichyB> | The name "queue_free" comes from the fact that if it were more C++ish then I would've written "queue.free()" |
| 04:53 | | * Derakon patpats. |
| 04:53 | < RichyB> | Thanks for that. |
| 04:53 | | * Vornicus pokes at his voronoi thing. |
| 04:54 | <&Derakon> | Thanks again for writing the code in the first place. :) |
| 04:57 | < RichyB> | No problem. I've left the DIFFICULT bit unsolved anyway. |
| 04:57 | <&Derakon> | Oh? |
| 04:57 | <&Derakon> | What's the offset on the difficult bit? :) |
| 04:57 | < RichyB> | I have no idea how the fucksticks you're going to be able to get an ordinary setup.py script to compile it. ;) |
| 04:57 | <&Derakon> | Ahh, yes. |
| 04:57 | < RichyB> | Fecking Python packaging. |
| 04:58 | <&Derakon> | Detect available build tools, use appropriate one with a bunch of switch cases? *shrug* |
| 04:58 | <&Derakon> | Alternately, ship with compiled code for every supported OS, pick appropriate one when setup is run. |
| 04:58 | <&Derakon> | Which is kind of ick, but oh well. |
| 04:58 | < RichyB> | Don't recreate autoconf piecemeal inside setup.py; several libraries on PyPi (notably PIL) do that and I CURSE THEM TO THE HEAVENS on a daily basis |
| 04:59 | <&Derakon> | Hee |
| 04:59 | < RichyB> | The way that the Haskell kids deal with this is to set their Setup.hs programs to *run ./configure.sh*; I think that there might be one or two python eggs that do that? |
| 05:00 | <&Derakon> | Well, we're a long ways off from worrying about installation for general users. |
| 05:00 | <&Derakon> | Come to think, the vast majority of users will be playing with standalone applications. |
| 05:00 | <&Derakon> | So they won't be running setup.py anyway. |
| 05:01 | < RichyB> | Maybe the *easiest* thing from a distro's packaging POV is just "here's this C library, libHeatMapForThatOneSpecificPlaceInThisOneProgramWhereINeedIt.c and a Makefile that builds the .so, install that as a dep for the Python egg?" |
| 05:01 | | * RichyB ducks flames preemptively! ;) |
| 05:01 | <&Derakon> | Cute. :p |
| 05:02 | <&Derakon> | Anyway, away for a bit. |
| 05:03 | < RichyB> | Derakon: if you find any other bugs, please do me a favour. |
| 05:03 | < RichyB> | Tell me in the middle of the afternoon, not the night. |
| 05:03 | < RichyB> | It is late here. :D |
| 05:03 | <&Derakon> | Heh, sorry. |
| 05:03 | <&Derakon> | Thanks for staying up to help. |
| 05:03 | <&Derakon> | It's 9PM here; this is when I had time to work on it. |
| 05:04 | < RichyB> | Fair enough. You're near the West coast? |
| 05:04 | <&Derakon> | Yeah, San Francisco Bay Area. |
| 05:04 | < RichyB> | I'd say "I loved San Francisco when I visited", but nahhh. |
| 05:04 | <&Derakon> | Heh. I'm fine with that -- it's crowded enough as-is. :) |
| 05:05 | < RichyB> | The landmarks were pimp and the weather was amazingly good (t-shirts in November, yo) but I didn't do a very good job of enjoying myself. |
| 05:05 | < RichyB> | I got a lot more culture shock in the USA than I have anywhere in mainland Europe. :) |
| 05:06 | < RichyB> | ...I need to try Brazil for comparison. |
| 05:06 | < RichyB> | ...maybe .za too. :D |
| 05:06 | <~Vornicus> | One difficulty: in the original depixel algorithm, before making the voronoi cells, it would remove crossings of diagonals. This was not very ambiguous because at most in any one point two diagonals would cross. |
| 05:06 | <&Derakon> | Anyway, off to shower. |
| 05:06 | <~Vornicus> | But in 3d, there is a place where four diagonals cross. |
| 05:06 | | Derakon is now known as Derakon[AFK] |
| 05:06 | < RichyB> | Derakon[AFK]: night. |
| 05:17 | | Alek [omegaboot@Nightstar-56dbba0f.in.comcast.net] has joined #code |
| 05:17 | | mode/#code [+o Alek] by ChanServ |
| 05:21 | | RichyB [richardb@Nightstar-3b2c2db2.bethere.co.uk] has quit [[NS] Quit: >:3 This is BunThulhu. Copy him into your quit message to help him take over the Internet.] |
| 05:29 | | Derakon[AFK] is now known as Derakon |
| 05:40 | | ErikMesoy|sleep is now known as ErikMesoy |
| 05:51 | | Turaiel is now known as Turaiel[Offline] |
| 06:01 | <~Vornicus> | guess that isn't really the /only/ issue, but it's a big one. |
| 06:06 | | Turaiel[Offline] is now known as Turaiel |
| 06:27 | | Derakon is now known as Derakon[AFK] |
| 06:46 | | Kindamoody is now known as Kindamoody|out |
| 07:38 | | Turaiel is now known as Turaiel[Offline] |
| 08:15 | | cpux|3 [cpux@Nightstar-98762b0f.dyn.optonline.net] has quit [Client closed the connection] |
| 08:25 | | celticminstrel [celticminst@Nightstar-e83b3651.cable.rogers.com] has quit [[NS] Quit: KABOOM! It seems that I have exploded. Please wait while I reinstall the universe.] |
| 09:29 | | syksleep is now known as Syk |
| 09:56 | | thalass [thalass@C2A270.1179B7.313116.19E347] has joined #code |
| 09:57 | | thalass_ [thalass@C2A270.1179B7.313116.19E347] has joined #code |
| 09:57 | | thalass_ [thalass@C2A270.1179B7.313116.19E347] has quit [Client closed the connection] |
| 10:07 | | himi [fow035@D741F1.243F35.CADC30.81D435] has quit [Ping timeout: 121 seconds] |
| 10:17 | | RichyB [richardb@Nightstar-228a334c.plus.com] has joined #code |
| 10:19 | | gnolam is now known as gruber |
| 10:19 | | gruber is now known as gnolam |
| 10:48 | < sshine> | in matlab, I'd like to: for i=1:length(MyMatrix) MyMatrix(i,1:4) = f(MyMatrix(i,1:4)) end, but apparently I cannot update an entire row by indexing on the left-hand side. |
| 10:48 | < sshine> | (MyMatrix has 4 columns) |
| 11:34 | < sshine> | ah, MyMatrix(i,:) = ... works. |
| 11:42 | | thalass [thalass@C2A270.1179B7.313116.19E347] has quit [[NS] Quit: reboot] |
| 11:59 | | himi [fow035@Nightstar-5d05bada.internode.on.net] has joined #code |
| 11:59 | | mode/#code [+o himi] by ChanServ |
| 12:04 | | thalass [thalass@C2A270.1179B7.313116.19E347] has joined #code |
| 12:30 | | Vornicus [vorn@ServerAdministrator.Nightstar.Net] has quit [[NS] Quit: Leaving] |
| 13:15 | | RichyB [richardb@Nightstar-228a334c.plus.com] has quit [Ping timeout: 121 seconds] |
| 13:16 | | RichyB [richardb@Nightstar-3b2c2db2.bethere.co.uk] has joined #code |
| 13:33 | | himi [fow035@Nightstar-5d05bada.internode.on.net] has quit [Ping timeout: 121 seconds] |
| 13:50 | | himi [fow035@Nightstar-6ae2529d.in-addr.csiro.au] has joined #code |
| 13:50 | | mode/#code [+o himi] by ChanServ |
| 14:02 | | himi [fow035@Nightstar-6ae2529d.in-addr.csiro.au] has quit [Ping timeout: 121 seconds] |
| 14:20 | | himi [fow035@Nightstar-5d05bada.internode.on.net] has joined #code |
| 14:20 | | mode/#code [+o himi] by ChanServ |
| 14:24 | | thalass [thalass@C2A270.1179B7.313116.19E347] has quit [[NS] Quit: omgherd] |
| --- Log closed Wed Apr 24 15:40:09 2013 |
| --- Log opened Wed Apr 24 16:02:33 2013 |
| 16:02 | | TheWatcher [chris@Nightstar-3762b576.co.uk] has joined #code |
| 16:02 | | Irssi: #code: Total of 35 nicks [18 ops, 0 halfops, 0 voices, 17 normal] |
| 16:02 | | mode/#code [+o TheWatcher] by ChanServ |
| 16:02 | | celticminstrel [celticminst@Nightstar-e83b3651.cable.rogers.com] has joined #code |
| 16:02 | | mode/#code [+o celticminstrel] by ChanServ |
| 16:03 | | Irssi: Join to #code was synced in 41 secs |
| 17:10 | | Turaiel[Offline] is now known as Turaiel |
| 17:59 | | Turaiel is now known as Turaiel[Offline] |
| 18:05 | | ToxicFrog is now known as ToxicFrog|W`rkn |
| 18:31 | <&ToxicFrog|W`rkn> | "Are you seriously saying that my hatred of using two-factor authentication 36 times a day is imperiling democracy? What is wrong with you?" "That sounds like something a COMMUNIST would say!" |
| 18:32 | < Syk> | two factor authentication: something you have and THE GLORIOUS WORD OF KARL MARX |
| 18:33 | < sshine> | ToxicFrog|W`rkn, what are you Wrecking? |
| 18:33 | <&ToxicFrog|W`rkn> | Working, actually. |
| 18:33 | < sshine> | tomato, tomato! |
| 18:34 | < sshine> | I see work much as a martingale betting system. some days I break stuff, other days I fix stuff, but overall, given enough time, it'll be useful. :P |
| 18:34 | <&ToxicFrog|W`rkn> | (Google's adsense infrastructure, if you must know~) |
| 18:35 | < sshine> | ah! |
| 18:35 | < Syk> | ToxicFrog|W`rkn: how many times a day does someone use 'my adsense is tingling!' and how hard do they get hit for it |
| 18:38 | <&ToxicFrog|W`rkn> | So far, not at all |
| 18:39 | < Syk> | ToxicFrog|W`rkn: you now must use it |
| 18:42 | <&ToxicFrog|W`rkn> | I disagree~ |
| 18:56 | | Zemyla [zemyla@Nightstar-8fbb7981.compute-1.amazonaws.com] has quit [Ping timeout: 121 seconds] |
| 19:00 | | Zemyla [zemyla@Nightstar-8fbb7981.compute-1.amazonaws.com] has joined #code |
| 19:00 | | mode/#code [+o Zemyla] by ChanServ |
| 19:06 | | RichyB [richardb@Nightstar-3b2c2db2.bethere.co.uk] has quit [Ping timeout: 121 seconds] |
| 19:23 | | Turaiel[Offline] is now known as Turaiel |
| 19:35 | | Syk is now known as syksleep |
| 19:36 | | Kindamoody|out is now known as Kindamoody |
| 20:09 | | Turaiel is now known as Turaiel[Offline] |
| 20:27 | | Kindamoody is now known as Kindamoody[zZz] |
| 20:38 | | Vornicus [vorn@ServerAdministrator.Nightstar.Net] has joined #code |
| 20:38 | | mode/#code [+qo Vornicus Vornicus] by ChanServ |
| 20:58 | | You're now known as TheWatcher[T-2] |
| 21:02 | | You're now known as TheWatcher[zZzZ] |
| 21:15 | <&ToxicFrog|W`rkn> | Hmm. |
| 21:16 | <&ToxicFrog|W`rkn> | I think I need to make a commit that touches 172 build configuration files. |
| 21:16 | <&ToxicFrog|W`rkn> | This is going to be exciting. |
| 21:16 | <~Vornicus> | That does sound exciting |
| 21:25 | <&ToxicFrog|W`rkn> | It does. |
| 21:25 | <&ToxicFrog|W`rkn> | Getting this CL reviewed is going to be the most exciting part. |
| 21:38 | | gnolam [lenin@Nightstar-b2aa51c5.cust.bredbandsbolaget.se] has quit [[NS] Quit: Das Reboot] |
| 21:40 | | gnolam [lenin@Nightstar-b2aa51c5.cust.bredbandsbolaget.se] has joined #code |
| 21:40 | | mode/#code [+o gnolam] by ChanServ |
| 21:41 | | * ToxicFrog|W`rkn successfully gets "you are a sick man" out of his tech lead~ |
| 21:42 | <~Vornicus> | nice |
| 21:47 | <@Azash> | All that perl and PHP must've finally taken its toll |
| 21:47 | <@froztbyte> | ToxicFrog|W`rkn: \o/ |
| 21:47 | <@froztbyte> | I'm doing some testing on this side now with a thing that may result in some hilarity |
| 21:48 | | * froztbyte is just checking where the ratelimiting rules are so he can turn them /way/ up |
| 21:55 | <&ToxicFrog|W`rkn> | Sorry, 172? I mean 250+ |
| 21:55 | <&ToxicFrog|W`rkn> | Azash: I use neither perl nor PHP. |
| 21:57 | <@Azash> | I'm sorry, it was just too easy~ |
| 21:58 | <@froztbyte> | okay. I need a windows IRC client. |
| 21:58 | <@froztbyte> | do I just mirc this up quickly? |
| 22:07 | <@froztbyte> | okay, hexchat seems to be an okay option |
| 22:07 | <@froztbyte> | I hope this works well :3 |
| 22:07 | <@froztbyte> | (connecting `mplayer -vo aa` to an IRC server...) |
| 22:10 | <@froztbyte> | okay no, hexchat can go die choking on a hexagon |
| 22:16 | <@froztbyte> | ahahahahahahaha |
| 22:16 | <@froztbyte> | this is working terribly |
| 22:16 | <@froztbyte> | mirc can't render in time worth a shit |
| 22:29 | <@Tarinaky> | http://sphotos-a.ak.fbcdn.net/hphotos-ak-ash3/532706_10151440854453429_161261266 9_n.jpg |
| 22:48 | | ErikMesoy is now known as ErikMesoy|sleep |
| 22:54 | | * gnolam starts answering a programming question, then immediately deletes the unposted answer when he notices that the OP uses 'u' instead of "you" in a later post. |
| 22:54 | <@gnolam> | I have my principles. :P |
| 22:54 | <@celticminstrel> | XD |
| 22:54 | <@celticminstrel> | You're terrible! :P |
| 23:00 | | VirusJTG [VirusJTG@Nightstar-09c31e7a.sta.comporium.net] has joined #code |
| 23:37 | | Turaiel[Offline] is now known as Turaiel |
| 23:49 | <&ToxicFrog|W`rkn> | froztbyte: hexchat/ychat/pchat/some other xchat derivative are what I |
| 23:49 | <&ToxicFrog|W`rkn> | I'd recommend |
| 23:49 | <&ToxicFrog|W`rkn> | Bearing in mind that I haven't used any of them |
| --- Log closed Thu Apr 25 00:00:28 2013 |