#pentagram@irc.freenode.net logs for 5 Dec 2003 (GMT)

Archive Today Yesterday Tomorrow
Pentagram homepage


[00:56:31] <-- Kirben has left IRC (Read error: 104 (Connection reset by peer))
[00:57:05] --> Kirben has joined #pentagram
[00:57:05] --- ChanServ gives channel operator status to Kirben
[00:58:59] --> watt has joined #pentagram
[01:09:16] <-- watt has left #pentagram ()
[02:30:17] <-- EsBee-Eks has left IRC (Read error: 54 (Connection reset by peer))
[02:32:26] --> EsBee-Eks has joined #pentagram
[03:01:52] --> sbx has joined #pentagram
[03:01:52] <-- EsBee-Eks has left IRC (Read error: 104 (Connection reset by peer))
[03:04:35] --> watt has joined #pentagram
[03:31:36] --> EsBee-Eks has joined #pentagram
[03:31:37] <-- sbx has left IRC (Read error: 104 (Connection reset by peer))
[05:28:35] <watt> const int NUM_MOUSEBUTTONS = 5; ......... oh. I believe this might be the cause of problems when clicking my side buttons on my mouse.
[05:29:50] <watt> yup clicking those buttons causes a nasty crash.
[05:39:46] <watt> yup.. setting it to 10 fixes that.. (although I only have 7 buttons (wheel up, down, and middle included). I have seen weird ones with 2 wheel which might add to up 10)
[07:36:51] <watt> hmm I was deleting null. I'm a little special.
[07:38:34] <watt> oh.. worse.. I was deleting something that already was deleted.
[07:38:45] <watt> that
[07:39:07] <watt> that's why we use FORGET_OBJECT
[07:49:50] <watt> cool. It works now.
[07:49:59] <-- EsBee-Eks has left IRC (Read error: 54 (Connection reset by peer))
[07:50:26] --> EsBee-Eks has joined #pentagram
[08:05:49] <watt> yikes.. tying in mouse input to the input manager is going to be a little difficult..
[09:47:30] --> SB-X has joined #pentagram
[09:58:49] <-- EsBee-Eks has left IRC (Read error: 60 (Operation timed out))
[10:49:57] --> Colourless has joined #Pentagram
[10:50:00] --- ChanServ gives channel operator status to Colourless
[10:55:09] <Colourless> hi
[11:39:59] <watt> hi
[11:40:22] <watt> (and only an hour late on the hello)
[11:41:33] <Colourless> you still have a long way to go yet... *only* 45 minutes according to my clock
[11:43:11] <watt> well true..
[11:45:06] <watt> hmm since I got your attention... OT: Is it more efficient to read from sockets in blocks or byte-by-byte?
[11:45:27] <watt> completely nothing to do with pentagram.
[11:45:29] <Colourless> hell if I know. I've never coded for sockets
[11:45:57] <Colourless> considering that sockets are buffered by the OS AFAIK, it shouldn't matter
[11:46:23] <Colourless> in general though, doesn't matter what you do, working is blocks is generally better
[11:47:37] <watt> crap. I've been trying to deal with a telnetish server/client system in java (which is a __HORRIBLE__ language for something that simple.) and I'm trying to get around using threads for both the input and output.
[11:49:22] <watt> I agree working in blocks is nice.
[11:55:37] <watt> well.. I think I'll try it.. anything's better than my sinThread(tm) (socket input thread)
[12:11:01] <-- Colourless has left IRC (calvino.freenode.net irc.freenode.net)
[12:11:40] --> Colourless has joined #Pentagram
[12:11:40] --- ChanServ gives channel operator status to Colourless
[12:13:37] <Darke> IIRC, there's also something about not reading blocks larger then around 1kb, or else on slow connections you may find yourself waiting for multiple packets to arrive over your connection before the data buffer is large enough.
[12:14:37] <Darke> Or even on fast, choked connections I suppose. I think the magical value is 1500bytes, which is the maximum data size of a tcp packet? *thinkiethink* I should remember this crud, CISCO has really tired me out, I did 4 hours of lectures and three tests tonight. *grin*
[12:15:32] <Colourless> Sounds like a FAIL is in order for you *evil grin*
[12:17:21] <Darke> What's *really* scary, is I passed the CISCO module on TCP/IP related stuff with flying colours (missing only one mark out of about 50)... without *any* study what so ever. Three way handshakes, which protocols run over which transport layers, I found everything amazingly easy, I couldn't believe it. *grin*
[12:17:54] <Colourless> I bet I know what you got wrong too :-)
[12:18:55] <Darke> I'm pretty sure I know, I botched up on the TCP/IP four way handshake. *grin*
[12:19:03] <Darke> s/four/three/ *grin*
[12:19:15] <Darke> Like I said, brane's not completely here. *grin*
[12:26:49] --> sbx has joined #pentagram
[12:26:49] <-- SB-X has left IRC (Read error: 54 (Connection reset by peer))
[12:47:44] <-- watt has left IRC ("using sirc version 2.211+KSIRC/1.2.4")
[13:37:48] * Darke decides that "After that, all hell breaks loose." is the most succinct way he's seen of someone describing the results of a compiler mis-generating code.
[13:40:23] <Colourless> although that isn't always entirely accurate, since some instances of the compiler 'mis-generating' code introduces very very subtle problems
[13:41:40] <Colourless> i might admit however, any occurances with the phenomenon i've encounted have been more of that "After that, all hell breaks loose." type
[13:55:36] <Darke> This particular bug had subtle 'infinate constructor loop' problems. *grin*
[14:18:26] <Colourless> can't say i've encounted anything like that
[14:31:49] <-- Kirben has left IRC (Read error: 104 (Connection reset by peer))
[14:49:55] --> EsBee-Eks has joined #pentagram
[14:49:55] <-- sbx has left IRC (Read error: 54 (Connection reset by peer))
[17:13:09] --> wjp has joined #pentagram
[17:13:09] --- ChanServ gives channel operator status to wjp
[17:13:09] <-- EsBee-Eks has left IRC (Read error: 54 (Connection reset by peer))
[17:13:17] --> EsBee-Eks has joined #pentagram
[17:13:37] <wjp> hi
[17:14:07] <Colourless> hi
[17:38:37] <-- Colourless has left IRC ("casts invisibility")
[21:20:58] --> Fingolfin has joined #pentagram
[21:20:58] --- ChanServ gives channel operator status to Fingolfin
[21:34:38] --> Dark-Star has joined #pentagram