00:03:19  * tim_smart|awaychanged nick to tim_smart
00:06:45  <luvit-bb>build #949 of virgo-windows2008_x64 is complete: Failure [failed integration tests] Build details are at https://virgo-bb.k1k.me/builders/virgo-windows2008_x64/builds/949
00:14:13  * tim_smartchanged nick to tim_smart|away
00:14:36  * tim_smart|awaychanged nick to tim_smart
00:26:54  <tim_smart>Hah, now http.request will not emit the end event
00:54:09  * el_tejonquit (Read error: Connection reset by peer)
00:55:35  * TheJHquit (Ping timeout: 246 seconds)
00:57:04  * tim_smartchanged nick to tim_smart|away
00:57:19  * tim_smart|awaychanged nick to tim_smart
00:58:39  * el_tejonjoined
01:01:36  * tsingjoined
01:05:53  * xmingquit (Ping timeout: 272 seconds)
01:24:11  * charetjcjoined
01:25:35  <charetjc>just ran into luvit and looking to build it on an x86 linux box. anyone here attempt this already and sorted out the build files?
01:33:23  <tim_smart>charetjc: My uname:
01:33:38  <tim_smart>Linux tim-macbook-arch 3.4.4-2-ARCH #1 SMP PREEMPT Sun Jun 24 18:59:47 CEST 2012 x86_64 GNU/Linux
01:34:00  <charetjc>Linux redbox 3.2.12-gentoo #3 PREEMPT Sat May 5 15:27:15 PDT 2012 i686 AMD Athlon(tm) 64 Processor 3500+ AuthenticAMD GNU/Linux
01:34:16  <charetjc>it's an old box
01:34:43  <tim_smart>charetjc: Have you tried building it? It should be fine
01:35:29  <charetjc>i was trying to build it with gyp, but just checked with make, it's going
01:35:51  <charetjc>gyp complained that openssl-config didn't have settings for my platform
01:36:01  <tim_smart>./configure && make && make install should be fine
01:36:18  <tim_smart>Hmm
01:36:30  <charetjc>hang on, i'll paste bin the exact error
01:37:53  <charetjc>http://pastebin.com/nFhA7dBe
01:39:25  <tim_smart>It should use the x64 config
01:39:54  <tim_smart>You can probably force the architecture somewhere
01:40:33  <charetjc>just noticed configure is a python script, i usually don't bother looking in an autotools configure
01:41:18  <charetjc>the "uname -p" is missing an x86 keyword i imagine
01:42:17  <tim_smart>charetjc: What if you ./configure --arch x86?
01:43:03  <charetjc>same error as before with "linux-x86" instead of "linux-AMD..."
01:43:25  <tim_smart>--arch x64
01:43:31  <tim_smart>My bad
01:44:41  <charetjc>still getting same error as before, now with "linux-x64"
01:44:55  <charetjc>also tried "--arch amd64" and "--arch x86_64"
01:47:23  <tim_smart>Hmm.. The configure scripts says it will check the x64 directory as well as the linux-x64 directory
01:47:28  <tim_smart>*script
01:49:01  <charetjc>maybe it's because i'm trying to use a build folder like i usually do with autotools builds ><
01:50:08  <charetjc>yeap, that fixed that error
01:51:13  <charetjc>new error: pointer size mismatch in cross-build
01:51:48  <charetjc>probably doesn't like "--arch x64" on my 32 bit system?
01:52:02  <tim_smart>charetjc: OH I thought is was 64 bit hah
01:52:22  <charetjc>na :D
01:52:45  <charetjc>./configure --arch ia32 && make -C out is going now
01:52:45  <tim_smart>--arch ia32
01:54:03  <charetjc>thanks for helping. while this compiles, I'm gonna grab dinner. cya around :)
01:59:07  * tim_smartchanged nick to tim_smart|away
02:12:57  * tim_smart|awaychanged nick to tim_smart
02:30:09  * AvianFlujoined
02:46:38  * tsingquit (Quit: Linkinus - http://linkinus.com)
03:01:29  * xmingjoined
03:21:08  * AvianFluquit (Quit: Leaving)
05:34:21  * charetjcquit (Read error: Operation timed out)
07:51:11  * xmingquit (Changing host)
07:51:12  * xmingjoined
08:02:27  * aliemjoined
11:47:11  * DarkGodjoined
11:54:49  * el_tejonquit (Ping timeout: 252 seconds)
11:56:43  <DarkGod>hi, I can not seem to find the method to close a net client (that I get from a callback of createServer)
11:56:51  <DarkGod>I tried finish, close but none work
11:57:22  <xming>:destroy()
11:57:48  * el_tejonjoined
11:58:08  <DarkGod>ahah :)
11:58:09  <DarkGod>thanks :)
11:58:42  <xming>universe:destroy() moahahahaha
11:59:56  <DarkGod>:>
12:00:08  <DarkGod>out of cheese error, please reboot universe
12:06:44  <luvit-bb>build #950 of virgo-windows2008_x64 is complete: Failure [failed integration tests] Build details are at https://virgo-bb.k1k.me/builders/virgo-windows2008_x64/builds/950
12:17:34  <DarkGod>loadfile() is not available in any way in luvit ?
12:35:23  <DarkGod>also is there a mysql connector that works in async mode with luvit ?
12:41:42  * TheJHjoined
13:14:21  <tim_smart>creationix: rphillips: https://github.com/luvit/luvit/pull/268
13:14:41  <tim_smart>Fix still needs to be made, but a failing test is there.
13:14:55  <tim_smart>Probably need to add some tests regarding http 1.0
13:15:03  <tim_smart>*some more
13:20:20  * AvianFlujoined
13:20:28  <tim_smart>DarkGod: ^
13:20:43  <tim_smart>There is a patch for that in that pull request
13:20:58  * AvianFluquit (Remote host closed the connection)
13:23:38  <DarkGod>for mysql async ?
13:26:08  <tim_smart>DarkGod: :done method on net.Socket
13:26:26  <tim_smart>And rename response:finish to response:done
13:26:51  <tim_smart>Cleans up the api a bit :)
13:27:10  <DarkGod>ah :)
13:27:25  <DarkGod>well I can live with :destroy() and it's FUN to *destroy* things :)
13:27:33  <tim_smart>Oh dear
13:29:22  <tim_smart>I can imagine you as the kind of person who destroys my legos or something
13:29:30  <tim_smart>Or card tower
13:31:26  <DarkGod>I feed on your tears!
13:32:55  <DarkGod>hum .. http.get, it returns me a stream
13:33:12  <DarkGod>or a request ? and what is the callback meant to do ?
13:35:55  <DarkGod>if I inspect the thing it returns it klooks like a requets, ith headers and all, but I dont have a body and I dont see how to get it
13:44:06  <tim_smart>I haven't used it DarkGod, let me check it out.
13:44:20  <DarkGod>thanks
13:44:38  <DarkGod>from looking at https://github.com/luvit/luvit/blob/master/lib/luvit/http.lua it seems I would need to bind req:on("data") but I receive nothing
13:56:24  <tim_smart>DarkGod: http.get('http://www.google.com/', function (response) response.on('data', function (chunk) end); response.on('end', function () end))
13:58:30  <DarkGod>ahah, I was doing :on on the return of http.get .. woops
13:58:31  <DarkGod>thanks
14:09:30  <DarkGod>huummm http.get doesnt send a Host: header
14:09:55  <DarkGod> _header = "GET /tome HTTP/1.1\r\nConnection: close\r\nTransfer-Encoding: chunked\r\n\r\n",
14:09:55  <DarkGod>even though I call it and specify a host="foo" field
14:11:13  <DarkGod>I can fix it by adding it to the headers myself but it sounds like something that should be automatic no ?
14:15:47  <creationix>tim_smart, don't need configure for Makefile
14:15:56  <creationix>./configure && make -C out
14:16:01  <creationix>or just make && make install
14:17:13  <tim_smart>creationix: ?
14:17:27  <tim_smart>I didn't have any issues building
14:17:41  <creationix>you were telling someone to use ./configure ; make; make install
14:17:47  <creationix>but vanilla make doesn't use ./configure
14:17:53  <creationix>just wanted to clarify
14:20:41  <tim_smart>right. Does make do its own architecture lookup?
14:20:42  <creationix>DarkGod, yes, that should be automatic. Feel free to file a bug. That API is supposed to mirror node and node auto-sends the host header
14:22:37  <creationix>tim_smart, the configure script hooks into gyp and generates a makefile in out
14:22:47  <creationix>the Makefile works on most unix systems and has lots of conditionals
14:22:57  <creationix>someday we'll unify the build systems
14:23:10  <creationix>xming is working on a unified system based on cmake
14:26:07  <DarkGod>creationix, I shall thanks :)
14:26:39  <DarkGod>any way to get the remote IP address of the socket in the net.createServer callback ?
14:26:45  <DarkGod>I inspected the stream but it doesnt have it
14:28:17  <DarkGod>(sorry I aask much questions, but I really like luvit :) )
14:37:26  * philipsquit (Excess Flood)
14:37:31  <creationix>DarkGod, is should be in the res stream
14:37:40  <creationix>I remember bindings that (I think)
14:38:07  <creationix>DarkGod, and questions are fine, luvit is still young, it makes me happy to see fresh people in here
14:39:15  <creationix>DarkGod, ok, so the bindings are here https://github.com/luvit/luvit/blob/master/src/luv_tcp.c#L86-156
14:39:24  <creationix>now to figure out how to use this from your lua app
14:40:13  * philipsjoined
14:40:39  <creationix>DarkGod, https://github.com/luvit/luvit/blob/master/lib/luvit/uv.lua#L91-94
14:40:50  <creationix>so there are two methods on all tcp streams
14:40:59  <creationix>so res:getSockName() or res:getPeerName()
14:41:00  <creationix>:)
14:41:21  <creationix>philips, I love your slides
14:41:22  <DarkGod>ah so simple :)
14:41:31  <creationix>I'm working on my luvit slides now
14:41:36  <creationix>philips, I may borrow some text
14:41:41  <philips>creationix: heh, thanks. The luvit ones?
14:41:43  <philips>creationix: yea, sure!
14:41:46  <creationix>luvit and libuv
14:41:49  <creationix>I liked them both
14:42:04  <creationix>my talk is about sharing my experience porting node to a new platform
14:42:05  <philips>:)
14:42:20  <creationix>I think I'll just use keynote this time though
14:42:31  <creationix>html5 slides take me so much longer because I like to play with the code
14:42:55  * DarkGod2quit (Ping timeout: 245 seconds)
14:43:56  * DarkGod2joined
15:06:24  <DarkGod>when I write to a stream (a fs stream in this case); can I just do:
15:06:32  <DarkGod>stream:write(data)
15:06:36  <DarkGod>stream:destroy()
15:06:45  <DarkGod>or doI need to destroy in a callback ?
15:14:22  * charetjcjoined
15:17:00  <xming>my arm aches from doing windows builds
15:34:11  <tim_smart>My eyes hurt from staring at http implementation
15:44:26  <creationix>tim_smart, why is that?
15:44:44  <tim_smart>All most 4am
15:44:46  <creationix>DarkGod, good question
15:45:09  <creationix>I always get confused between end/finish, close, and destroy
15:45:14  <creationix>(end in node, finish in luvit)
15:45:19  <tim_smart>creationix: I am trying to hook up ServerResponse to the http server
15:45:34  <tim_smart>creationix: It's done() in luvit now
15:45:49  <creationix>:done() is node's .end()?
15:45:55  <tim_smart>Yeah
15:45:56  <creationix>I vaguly remember that
15:46:02  <creationix>I need to find time to use luvit
15:46:23  <tim_smart>response:finish needs to be changed, its the only stream that has it
15:47:08  <tim_smart>I have a patch for it in a pull request, but it is part of a larger refactor
15:54:11  <creationix>tim_smart, cool, just coordinate with rphillips. I haven't touched that code in a while
15:57:13  <tim_smart>rphillips: When I'm back (sleeping now) we should talk about the http server and serverresponse
15:57:25  <tim_smart>Anyway, I'm out.
15:58:03  * tim_smartchanged nick to tim_smart|away
16:00:08  * paulsherwoodjoined
16:31:54  <DarkGod>hum got a segfault: http://pastebin.com/TLzRR5Zn
16:32:00  <DarkGod>does that speak to somebody ?
16:32:23  <DarkGod>(the server was under "heavy" load, a few hundred clients)
16:36:01  * AvianFlujoined
16:53:10  <creationix>DarkGod, unfortunately, nothing jumps out right now. I don't have time at the moment to help debug it
16:53:48  <DarkGod>:<
17:13:52  <charetjc>i'd check that handle variable at line 219 and verify it has a valid address
17:15:08  <CIA-113>Tim Caswell master * r4cd3d11 / (deps/luajit jit): Upgrade to luajit v2.0.0-beta10-62 - http://git.io/vOlnvQ
17:15:55  <charetjc>then i'd look into why the lua state L switched from 0x40000378 to 0x401ae390, DarkGod
17:16:51  <DarkGod>I'm using coroutines, probably why it switches states
17:16:53  <creationix>DarkGod, are you using coroutines?
17:17:00  <creationix>heh, I guess go
17:17:10  <DarkGod>is taht bad ?
17:17:14  <creationix>coroutines are still somewhat buggy
17:17:20  <creationix>they should work
17:17:22  <DarkGod>coroutines allow me to write code in a "natural" way instead of event-like
17:17:27  <creationix>but most people don't use them, so they get little testing
17:17:37  <creationix>DarkGod, are you using my fiber module?
17:17:43  <creationix>or raw lua coroutines
17:17:48  <DarkGod>nope, cooked my own thing before I found it
17:17:53  <creationix>cool
17:18:52  <charetjc>so the lua state makes sense, does that handle variable have a valid address?
17:18:59  <DarkGod>nothing complex, I bind on stream:data, push data to a buffer; my coroutine when it needs to read a line (its a SMTP-like protocol) will check the buffer, if not filled enough it yields and is resumed one next data
17:19:00  <DarkGod>and so on
17:20:07  <DarkGod>charetjc, I dont have the app running anymore, the only way to make it crash is to submit it to the real game load, but I cant let the server down for long in prod :/
17:20:20  <DarkGod>because obviously when testing it with 1/2 clienst I never got any craash
17:20:42  <charetjc>ah
17:21:01  <charetjc>how many clients were on when it crashed?
17:21:40  <DarkGod>about 100
17:22:03  <charetjc>so can't be exceeding the fd limit :/
17:22:04  <DarkGod>I can redeply it now and wait for an other crash
17:22:07  <DarkGod>(it comes very fast)
17:22:22  <DarkGod>na, I increased the fd limit to a lot a long while ago anyway
17:23:11  <DarkGod>running, waiting the the crash
17:24:13  * aliemquit (Remote host closed the connection)
17:25:20  <DarkGod>hum got a different one: http://pastebin.com/sFaWNwZ9
17:25:29  <DarkGod>the line line repeats a lot (the address changes)
17:25:53  <DarkGod>but the stacktrace doesnt show any of my code
17:28:17  <DarkGod>ah got the old error again: http://pastebin.com/gTEfY45x
17:28:26  <charetjc>i must have a different revision of fs.lua, because line 253 is the end) of a callback
17:28:30  <DarkGod>(gdb) p handle
17:28:30  <DarkGod>$2 = (uv_stream_t *) 0x0
17:29:22  <charetjc>so now the question is "why's the handle is null?"
17:29:23  <DarkGod>anything else I can check ?
17:30:00  <charetjc>at this point i browse the code looking for "handle = " lines starting with luv_write()
17:31:10  <charetjc>ouch, it's pulled from the Lua state
17:31:19  <DarkGod>hum
17:31:27  <charetjc>i hate bouncing back and forth between lua and c
17:31:32  <DarkGod>handle is a stream right ?
17:31:43  <DarkGod>could this be trying to write to a destroyed stream ?
17:31:53  <charetjc>possibly
17:32:13  <charetjc>either the stream was never created, or it was destroyed
17:32:24  <xming>just a wild shot, you :destroy() something that it's there any more?
17:32:37  <xming>isn't*
17:32:51  <DarkGod>xming, what do you mean ?
17:33:15  <xming>that the stream is already terminated
17:33:21  <xming>or vice versa
17:33:29  <DarkGod>I might have some code :destroy'ing a stram that was already closed or destroyed yes
17:33:39  <xming>don't do that :D
17:34:09  <DarkGod>shoudlnt it silently ignore the second destroy ?
17:35:11  <xming>I am not saying it's not a bug :D
17:35:28  <charetjc>from what I see in luv_stream.c, values pulled from udata aren't sanity checked, they're assumed to be valid.
17:35:51  <DarkGod>hum
17:39:17  <DarkGod>ah I see in the stream object there isa destroyed field, I can use that to check I suppose
17:42:10  <DarkGod>*test*
17:46:31  <DarkGod>hum I have protected all my destroy's and write's with an if not stream.destroyed
17:46:35  <DarkGod>but I still get it :/
17:50:21  <charetjc>i'm not sure what it is then. i'd be inclined to check whether the stream handle was never created or erroneously overwritten.
17:51:22  <DarkGod>how could it never be created ? the only streams are use are the ones I get from createServer callback
17:51:30  <DarkGod>and some fileoutput
17:51:47  <DarkGod>but I only use fs.writeFile so I dont even do the opening/writing myself
17:53:11  <charetjc>sorry, i'm not familiar enough with luvit to deduce where that particular bug is likely to occur.
17:53:31  <DarkGod>:<
17:53:53  <charetjc>i mean, you have no stream when the segfault occurs, handle == NULL.
17:54:17  <charetjc>if the stream isn't destroyed like you said, how else is that handle set to NULL
17:55:56  <DarkGod>well I read stream.destroyed; maybe it is not correctly set when the stream dies in some way ?
17:56:05  <charetjc>that's also a possibility
17:56:48  <charetjc>i'm still sorting through the luv_write() function
17:57:36  <charetjc>what i find wierd... luv_write() calls luv_checkudata(L, 1, "stream")...
17:57:55  <charetjc>but luv_checkudata() nevery uses that third argument, "stream".
17:58:06  <charetjc>*never
17:58:11  <charetjc>fat fingers ><
17:58:35  <DarkGod>heh hum
18:01:19  <charetjc>if the stream object, T, is a lua table, then I imagine the uv_handle_t* is stored T["userdata"] according to luv_checkudata()
18:02:03  <charetjc>when you check for stream.destroyed, you might also check stream.userdata
18:02:56  <DarkGod>I can try that after eating :)
18:03:16  <charetjc>sure. bon appetite
19:09:20  <DarkGod>re
19:09:29  <charetjc>w
19:09:30  <charetjc>wb
19:09:39  <DarkGod>I checked stream._handle.userdata but no luck :/
19:10:59  <charetjc>why the _handle?
19:11:31  <DarkGod>because stream.userdata just doestn exist, ever
19:11:42  <DarkGod>I did, p(stream) and it's never listed
19:12:02  <charetjc>ah
19:12:20  <charetjc>well, i'm lost then
19:12:57  <DarkGod>:<
19:14:05  <charetjc>i've been trying to figure out where this userdata that luv_checkudata() uses comes from, with no luck
19:14:53  <charetjc>but then again, luv_checkudata() only accesses t.userdata if t is a table.
19:15:04  <charetjc>i guess t isn't a table then ><
19:20:02  <DarkGod>humm
19:22:37  <charetjc>any idea which line of your lua code is producing this segfault?
19:26:01  <DarkGod>no :/
19:26:20  <DarkGod>I wonder if it would be opssible to get a lua traceback on crash with gdb, any ideas?
19:26:24  <charetjc>do you have a sample line of lua using the write function?
19:26:46  <xming>is it the destroy()? Does it happen when you don't destroy?
19:26:56  <charetjc>no clue on that traceback
19:26:57  <xming>you will probably running out of fd :d
19:27:54  <charetjc>we considered lack of fd's earlier
19:28:33  <charetjc>but then again, DarkGod, when you increased the fd limit, are you sure you set it to a higher number?
19:28:35  <xming>it heppends with write(), is it trying to write to an destroyed stream?
19:28:53  <DarkGod>seems to
19:28:57  <DarkGod> if not self.stream.destroyed and self.stream._handle.userdata and not self.stream:write(s:format(...)) then
19:29:26  * philipsquit (Excess Flood)
19:29:45  <charetjc>the userdata thing was my idea, i think we can toss that out now
19:30:18  <charetjc>xming, how would you check whether a stream is destroyed before writing to it?
19:30:25  <xming>where do you use destroy? If I am correct the connection is shutdown automatically unless errors happens
19:31:02  <xming>charetjc: I onlt destroy on error, I I would never write to a manually destroyed stream
19:31:53  <DarkGod>well when the server receives a QUIT comand it needs to destroy the connection
19:32:00  <DarkGod>you cant trust the client to do it
19:32:47  * philipsjoined
19:33:32  <xming>so why are you writing tot the destroyed stream?
19:34:16  <xming>yeas I forgot that I do destroy and on:end too
19:35:24  <DarkGod>but I dont :/
19:35:38  <DarkGod>I'm in a coroutine, running a while loop; when the loop ends the connection is destroyed
19:35:46  <DarkGod>and writes can only be called inside the while
19:36:31  * TheJHquit (Ping timeout: 265 seconds)
19:37:34  <xming>but you can still use a conn:on("end", func() ...)
19:37:47  <xming>to catch the case where the stream is down w/o probper shutdowns
19:39:34  <xming>I am just guessing that you write() to a timeout/broken stream
19:40:35  <DarkGod>but how can I test for it ?
19:45:52  <xming>with what you did :|
19:46:45  <xming>Can you start to reproduce this with just 1~2 client? Force shutdown the connection?
19:46:57  <xming>is it TCP?
19:46:57  <philips>DarkGod: can you post the code or something so I can reproduce?
19:47:24  <xming>philips: for started ATM he need live env to have this triggered
19:47:51  <DarkGod>the code needsa database & many other htings connected to work :/ I'm trying to get a minimal example of failure but it's kinda hard since I dont know whats wrong :/
19:48:03  <philips>ah, ok
19:48:16  <DarkGod>I did earlier a simple test taht ran thousands of connections that opened/pinged/closed; and it never failed
19:48:23  <philips>I bet it has something to do with destroying and then some other part of the code being naive
19:48:53  <philips>You are using coroutines so it probably isn't related to the gc avoiding code I did for callbacks
19:51:33  <xming>oh great, clicked wrong button and VS is rebuilding everything :/
19:51:51  <xming>GUI for development, seriously?
19:53:24  <DarkGod>:>
19:56:34  <xming>philips: are you guys using VS and mingw?
19:57:01  <philips>xming: we are using msys git and vs 2010
19:57:50  <xming>I thought someone here needed mingw support too
19:58:33  <philips>xming: It wasn't me.
19:58:41  <xming>roger
19:59:25  <philips>xming: pancake was aking about it in march according to my logs
19:59:31  <philips>other than that I don't see much
19:59:39  <xming>ty
20:00:31  <xming>philips: I was thinking about to let luajit to generate .c instead of .o/.ojb so we can eliminate the export hack
20:00:57  <philips>xming: what is the export hack?
20:01:30  <xming>luvit_exports.c
20:02:10  <philips>xming: ah, right. Getting rid of that hack would be nice
20:03:00  <xming>I don' know about beta9 but beta10 of luajit can generate bytecode embeded in a .c
20:04:25  <philips>xming: the changelog seems to have that as a beta9 feature
20:04:28  <philips>would be cool
20:05:03  <xming>I get unresolved symbols of those bytecodes with VS :/
20:05:19  <xming>and since I also wanted corss compiling this makes sense
20:05:31  <xming>this will facilitate cross-compiling
20:40:25  <creationix>wow, our API really does match node's
20:40:34  <creationix>check out this slide from my preso next week http://creationix.com/compare.png
20:41:02  <creationix>yes, the projectors wil be 1080p :)
20:58:16  <philips>creationix: we should create a console table with log = print :)
20:59:21  <creationix>I guess
20:59:23  <creationix>I prefer print
20:59:52  <creationix>but yeah, that's the only API diff in the slide
21:00:12  <creationix>it's just that console.log is a lot more than just print
21:47:54  <xming>charetjc: it fits my screen :D
21:48:04  <xming>creationix: it fits my screen :D
21:48:19  <creationix>yeah, both my desktops are 1080p
21:48:23  <creationix>it's quite convenient
21:51:21  <xming>2560x1440 is even better
21:51:44  <xming>I bought a IPS 27" for less than 300 euro
21:54:32  * indexzerojoined
22:13:03  <creationix>did we never bind uv_get_process_title?
22:13:10  <creationix>process.title is nil
22:13:25  <xming>apparently those kind of monitor only costs 200 USD retail in korea (abeit not a+ panel but A/A-
22:13:40  <xming>apple and dell are selling them with huge margins
22:16:38  * indexzeroquit (Quit: indexzero)
22:58:44  <DarkGod>about the error I am having, I narrowed it down a bit; my clients have two sockets each, one for commands and one for random data push; it bugs when (somtimes) I send a push to a client
22:59:05  <DarkGod>I inspect the push stream jsut before sending and it's not set as destroyed though
23:00:11  <DarkGod>when it disconnects I kill the stream AND set a special field so I know it's one; so I dont push after death
23:11:55  * indexzerojoined
23:19:58  <DarkGod>http://pastebin.com/qGCv0dun
23:20:11  <DarkGod>I put a stackdump right before t he crash
23:20:43  <DarkGod>handle is null and yet the 1 stack item is a userdata (and handle is gotten form stack item 1)
23:24:10  <DarkGod> uv_stream_t* handle = (uv_stream_t*)luv_checkudata(L, 1, "stream");
23:24:24  <DarkGod>it seems this actually returns [stack item1]->handle
23:24:47  <DarkGod>so the stack item is indeed there but it missed an initialization ? or somesuch
23:25:28  <DarkGod>philips, creationix , xming; does this help ?
23:27:02  <creationix>DarkGod: I really do wish I had time to help right now, but I'm up against a tight deadline at the moment
23:27:14  <creationix>I can tell you that I call all callbacks in the main "thread"
23:27:21  <creationix>even if they were registered from a coroutine
23:27:43  <creationix>not sure if this issue is coroutine related though
23:29:27  <DarkGod>why not call them in the thread that registered them ? but anyway I dont think this should be the problem; the callbacks I use are in the main thread
23:29:57  <DarkGod>I put a simple : if (!handle) return 0;
23:29:57  <DarkGod>in the function; we'll see if this still crashes; still I feel this is the wrong solution :)
23:34:29  <DarkGod>did the same in luv_write_queue_size
23:34:34  <DarkGod>seems to not crash anymore
23:35:31  <creationix>if you could, file an issue on github detailing what you found. I'll look into it when I get a chance
23:36:38  <DarkGod>sure
23:48:16  * hij1nxjoined