00:00:01  * ircretaryquit (Remote host closed the connection)
00:00:09  * ircretaryjoined
00:00:25  <MI6>libuv-master-gyp: #206 FAILURE windows-x64 (3/195) windows-ia32 (3/195) linux-x64 (1/194) osx-ia32 (1/195) http://jenkins.nodejs.org/job/libuv-master-gyp/206/
00:23:06  <trevnorris>for anyone who'd like to help, i'm not sure how to finish this commit: http://git.io/T42Tfg
00:23:27  <trevnorris>possibly i'm oversimplifying how it can be done, but at least figured I'd start there before trying anything else.
00:25:12  <othiym23>trevnorris: is there any restriction on what range of types the handle can have?
00:26:01  <othiym23>this would be pretty easy in some languages; you'd just introspect the class / type off the object
00:26:20  * mikealquit (Quit: Leaving.)
00:27:08  * mikealjoined
00:28:07  * EhevuTovquit (Quit: This computer has gone to sleep)
00:30:19  * brsonquit (Ping timeout: 248 seconds)
00:40:28  * bradleymeckjoined
00:50:16  * kazuponjoined
01:04:36  * bradleymeckquit (Ping timeout: 245 seconds)
01:06:20  * bradleymeckjoined
01:14:56  * kazuponquit (Remote host closed the connection)
01:16:52  * bradleymeckquit (Quit: bradleymeck)
01:17:45  * mikealquit (Quit: Leaving.)
01:20:49  * kazuponjoined
01:28:07  * c4milojoined
01:32:50  * amartensquit (Quit: Leaving.)
01:42:13  * c4miloquit (Remote host closed the connection)
01:43:48  * kazuponquit (Remote host closed the connection)
01:44:06  * abraxasjoined
01:55:53  * c4milojoined
02:03:17  * amartensjoined
02:05:52  * dapquit (Quit: Leaving.)
02:07:13  * kazuponjoined
02:18:32  * c4miloquit (Remote host closed the connection)
02:31:57  * c4milojoined
02:33:47  * kazuponquit (Remote host closed the connection)
02:43:14  * kazuponjoined
02:44:47  * kazuponquit (Remote host closed the connection)
02:53:02  * jxsjoined
02:54:52  * kazuponjoined
03:01:08  * ircretaryquit (Ping timeout: 240 seconds)
03:01:28  * ircretaryjoined
03:15:41  * bnoordhuisjoined
03:23:28  * ircretaryquit (Ping timeout: 240 seconds)
03:23:41  * mikealjoined
03:23:51  * julianduquequit (Quit: leaving)
03:35:45  * kazuponquit (Remote host closed the connection)
03:51:02  * kazuponjoined
04:28:07  * c4miloquit (Remote host closed the connection)
04:45:26  * bnoordhuisquit (Ping timeout: 245 seconds)
04:56:47  * defunctzombiechanged nick to defunctzombie_zz
05:28:01  * paddybyersjoined
05:51:22  * bnoordhuisjoined
05:54:08  * Damn3dquit (Ping timeout: 260 seconds)
05:55:56  * bnoordhuisquit (Ping timeout: 256 seconds)
05:58:52  * Damn3djoined
06:15:20  * octetcloudquit (Ping timeout: 246 seconds)
06:32:27  * blissdevquit (Ping timeout: 248 seconds)
06:38:04  * blissdevjoined
06:42:05  * amartensquit (Quit: Leaving.)
06:52:26  <MI6>nodejs-v0.10-windows: #239 UNSTABLE windows-ia32 (8/600) windows-x64 (7/600) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/239/
06:52:29  * rendarjoined
07:16:50  * bnoordhuisjoined
07:32:21  * hzjoined
07:43:30  * bnoordhuisquit (Ping timeout: 252 seconds)
07:59:04  * paddybyersquit (Quit: paddybyers)
08:06:35  * paddybyersjoined
08:24:29  * AvianFlujoined
08:28:52  * bnoordhuisjoined
09:45:01  * AvianFluquit (Remote host closed the connection)
09:53:28  * Domenic_quit (Ping timeout: 240 seconds)
09:54:29  * kazuponquit (Remote host closed the connection)
09:54:36  * `3rdEdenquit (Ping timeout: 245 seconds)
10:08:58  <indutny>bnoordhuis: I was able to reproduce that fsevents thingy
10:09:10  <indutny>bnoordhuis: looking
10:09:51  * `3Ejoined
10:11:23  * Chip_Zeroquit (Ping timeout: 245 seconds)
10:13:43  * Kakerajoined
10:20:08  * philipsquit (Ping timeout: 240 seconds)
10:34:19  * philipsjoined
10:43:43  * abraxasquit (Remote host closed the connection)
10:44:18  * abraxasjoined
10:46:15  <MI6>nodejs-v0.10: #1513 UNSTABLE linux-ia32 (2/600) smartos-x64 (1/600) http://jenkins.nodejs.org/job/nodejs-v0.10/1513/
10:48:05  <indutny>bnoordhuis: please review https://github.com/joyent/libuv/pull/946
10:48:11  <indutny>seems to be fixing a problem
10:48:40  * abraxasquit (Ping timeout: 246 seconds)
11:09:28  <bnoordhuis>looking
11:24:11  * bnoordhuisquit (Ping timeout: 248 seconds)
11:35:33  * Domenic_joined
11:56:18  * bnoordhuisjoined
12:00:04  * hzquit (Disconnected by services)
12:00:08  * hzjoined
12:07:40  * bnoordhuisquit (Ping timeout: 256 seconds)
12:07:55  * swajquit (Ping timeout: 245 seconds)
12:10:14  * swajjoined
12:49:58  * piscisaureus_joined
12:54:29  * hzquit
13:14:32  * bnoordhuisjoined
13:18:46  * bnoordhuisquit (Ping timeout: 245 seconds)
13:30:35  * bnoordhuisjoined
13:57:14  * vptrjoined
13:57:20  * vptrquit (Changing host)
13:57:20  * vptrjoined
14:04:24  * bnoordhuisquit (Ping timeout: 256 seconds)
14:22:20  * defunctzombie_zzchanged nick to defunctzombie
14:22:29  * mikealquit (Quit: Leaving.)
14:34:43  * superdeallocjoined
14:44:45  * superdeallocpart ("Linkinus - http://linkinus.com")
14:45:26  * c4milojoined
14:46:56  * defunctzombiechanged nick to defunctzombie_zz
15:00:48  * bradleymeckjoined
15:05:04  * c4miloquit (Remote host closed the connection)
15:12:24  * kazuponjoined
15:15:45  * c4milojoined
15:17:41  <MI6>nodejs-master: #591 UNSTABLE smartos-x64 (7/644) http://jenkins.nodejs.org/job/nodejs-master/591/
15:23:44  * superjoejoined
15:24:00  <superjoe>hi, what's the difference between a mutex and an rwlock?
15:24:41  <superjoe>looks like I should pretty much always use an rwlock to protect shared memory, yes?
15:25:23  * kazuponquit (Remote host closed the connection)
15:25:35  * mikealjoined
15:35:54  * dapjoined
15:37:18  * mikealquit (Quit: Leaving.)
15:39:39  * hzjoined
15:42:55  * bnoordhuisjoined
15:50:35  * bajtosjoined
16:02:16  <bnoordhuis>superjoe: a mutex is a full lock, an rwlock allows multiple readers but only one writer
16:02:45  <superjoe>perfect
16:03:04  <bnoordhuis>if you're unsure which one to pick, go for a mutex
16:03:43  <superjoe>I can't think of when I would ever want a mutex and not an rwlock
16:06:14  <superjoe>seems like a mutex is identical to an rwlock where you can't use the rdlock and rdunlock functions
16:06:27  <bnoordhuis>a mutex is safe wherever a rwlock is safe. not so the other way around
16:06:57  <bnoordhuis>if all consumers are writers, then rwlocks are probably deoptimizations, they've a bit more overhead
16:07:04  <bnoordhuis>s/all/most/
16:07:40  <superjoe>ah, I see - write starvation could be an issue
16:08:00  <superjoe>that's a pretty subtle difference
16:11:36  <bnoordhuis>isn't everything that involves threads? :)
16:12:03  * AvianFlujoined
16:22:51  * vptrquit (Ping timeout: 248 seconds)
16:23:22  * kazuponjoined
16:25:52  <superjoe>yep
16:26:17  * amartensjoined
16:33:50  * mikealjoined
16:37:02  * bnoordhuisquit (Ping timeout: 240 seconds)
16:37:36  <trevnorris>morning all
16:38:02  <superjoe>morning
16:38:06  <trevnorris>had a moment of inspiration in the shower this morning. Think I finally know how to get rid of domains!
16:38:35  <trevnorris>(just need to read this article on the xbox one first :P )
16:38:45  * wwicksquit (Quit: I'm sure we'll meet again)
16:38:47  <superjoe>uv_async_init says it returns a handle that should be uv_close()'d. where exactly is that handle?
16:39:51  <superjoe>can I pass uv_async_t to uv_close ?
16:43:23  * AvianFluquit (Remote host closed the connection)
16:43:42  <superjoe>trevnorris, I thought domains were considered "good" - did I miss something?
16:44:59  * c4miloquit (Remote host closed the connection)
16:45:07  <trevnorris>superjoe: i've always hated domains. bits and pieces are scattered all throughout core code, making it more complex and slower.
16:45:07  <trevnorris>so I've been working on a cleaner hook API that domains'll use instead.
16:45:24  <superjoe>I see
16:45:28  <trevnorris>understand, domains'll still ship with core. but they'll effectively be a userland module
16:45:49  <superjoe>wow it's possible to do domains in userland?
16:46:22  <trevnorris>superjoe: yeah. here's the pr for what i've been working on: https://github.com/joyent/node/pull/6011
16:46:34  <trevnorris>it's a lot more powerful than domains too.
16:47:41  <trevnorris>superjoe: here's an example script I created using the new api to generate long stack traces.
16:47:43  <trevnorris>https://gist.github.com/trevnorris/6784855
16:48:37  <superjoe>this is powerful stuff
16:49:16  <trevnorris>using it can have ridiculous performance implications, but the point was that if you don't use it, there'll be no impact.
16:49:32  <trevnorris>whereas with domains now, there is.
16:50:02  * octetcloudjoined
16:50:05  <superjoe>there is now, as in, there are a bunch of if statements?
16:50:46  <trevnorris>yeah. a lot of internal checks to see if domains exist on an event emitter. needing to check the process.domain state, etc. etc.
16:51:01  <superjoe>sounds like this is a pretty substantial cleanup
16:51:30  <trevnorris>othiym23: ping
16:53:07  * piscisaureus_quit (Ping timeout: 260 seconds)
16:56:40  * wwicksjoined
16:57:47  * defunctzombie_zzchanged nick to defunctzombie
16:57:58  <superjoe>so how do I get from a uv_async_t* to a uv_handle_t * ?
16:58:04  <superjoe>just reinterpret the pointer?
16:59:19  <trevnorris>superjoe: in libuv/include/uv.h you'll see
16:59:20  <trevnorris>struct uv_async_s {
16:59:20  <trevnorris> UV_HANDLE_FIELDS
16:59:20  <trevnorris> UV_ASYNC_PRIVATE_FIELDS
16:59:20  <trevnorris>};
16:59:21  <LOUDBOT>NO SHIT THAT'S TOO FUCKIN' WEIRD FOR ME. I'M GONNA GO MASTURBATE UNTIL IT'S FRIDAY AGAIN.
16:59:21  <LOUDBOT>CHECKING FOR UNIQUENESS IS TOO SLOW
16:59:48  <trevnorris>superjoe: and the UV_HANDLE_FIELDS are all the fields that make up uv_handle_t
17:00:05  <trevnorris>so yeah, just reinterpret the pointer.
17:00:15  <superjoe>ok
17:00:37  <superjoe>I'm always wary to do that because something something memory alignment something something, but if the docs say to do it, that's fine by me
17:00:58  <trevnorris>yeah. it's how uv was setup.
17:01:22  <trevnorris>all their fields are setup in define's, and only those are used to define the uv_*_s
17:01:47  * vptrjoined
17:05:42  * mikealquit (Quit: Leaving.)
17:18:08  * piscisaureus_joined
17:22:58  * c4milojoined
17:26:41  * inolenjoined
17:28:03  * piscisaureus_quit (Ping timeout: 240 seconds)
17:28:51  * bnoordhuisjoined
17:30:41  <trevnorris>bnoordhuis: sup man? get much sleep last night?
17:30:44  <MI6>joyent/libuv: Ben Noordhuis v0.10 * 11d8011 : unix: don't close inherited fds on uv_spawn() fail (+1 more commits) - http://git.io/mkxnPw
17:31:05  <bnoordhuis>trevnorris: not as much as i'd like but i'll manage :)
17:31:20  <trevnorris>bnoordhuis: heh, know how that goes. but, you still remain a coding machine. :)
17:31:45  <trevnorris>think I came up with a good way to emulate the domain stuff. might just have it in place before final review.
17:32:05  <trevnorris>all you're c++ training has really done a lot for me. thanks :)
17:32:12  <bnoordhuis>hah, no problem :)
17:32:20  <bnoordhuis>what's the solution you came up with?
17:32:55  <trevnorris>bnoordhuis: this'll explain it better than I can http://git.io/2tX-bg
17:33:20  <MI6>libuv-v0.10: #118 UNSTABLE windows (5/188) smartos (2/187) http://jenkins.nodejs.org/job/libuv-v0.10/118/
17:35:44  * kazuponquit (Remote host closed the connection)
17:36:22  * mikealjoined
17:37:36  <MI6>libuv-v0.10-gyp: #82 FAILURE linux-x64 (2/187) linux-ia32 (2/187) osx-ia32 (2/188) windows-x64 (5/188) windows-ia32 (5/188) http://jenkins.nodejs.org/job/libuv-v0.10-gyp/82/
17:39:11  <rendar>bnoordhuis: hi, what about that uv_fs_can_watch_file_creation() thing?
17:39:23  <bnoordhuis>rendar: hey. hum, maybe
17:39:41  <rendar>i don't see any drawbacks, but maybe i'm wrong :)
17:39:44  <bnoordhuis>can you give me a quick rundown of what you have in mind?
17:40:33  <rendar>bnoordhuis: basically just a function which returns true/false if the underlying system can watch file creation or deletion, if true, the user can exploit that, otherwise the user must code the polling of the directory
17:41:10  <bnoordhuis>coupled with a UV_CREATE event iirc?
17:41:16  <rendar>yeah
17:41:42  <rendar>if the underlying system supports watch file creation/deletion it can surely send UV_CREATE or UV_DELETE events for files..
17:42:10  <bnoordhuis>well, it's tricky
17:42:21  <rendar>i see, why?
17:43:01  <bnoordhuis>say another process does a real quick unlink() + creat()
17:43:22  <bnoordhuis>it's anybody's guess how that gets reported to the file path watcher
17:43:36  <rendar>hmm
17:43:38  <bnoordhuis>what i mean is you may not always get UV_CREATE events where you'd expect them
17:44:25  <rendar>well, you get UV_CREATE events in windows NT and linux, for other platforms they just won't be sent, because that true/false function returns indeed false
17:44:25  <rendar>:)
17:44:28  <bnoordhuis>that aside, i'm not against the idea - as long as i don't have to write the code :)
17:44:38  <rendar>eheh
17:44:41  <rendar>ok
17:45:12  * mikealquit (Ping timeout: 252 seconds)
17:45:40  <rendar>you mean that even in windows or linux where ReadFilechangesW or inotify supports file creation, they may be wrong with a quick unlink() + creat()? dunno, but i don't think so, expecially in linux
17:46:05  <bnoordhuis>the kernel's event queue may overflow or coalesce
17:46:12  <rendar>mmm
17:46:33  <rendar>i'll try that on linux, btw
17:46:36  <bnoordhuis>iow that unlink() + creat() sequence may get reported as e.g. just a change event rather than a creation event
17:46:47  <rendar>yeah
17:47:03  <trevnorris>bnoordhuis: oh, btw. there's a c++ api missing. something like a MakeAsyncCallback() that'll run the callback asynchronously.
17:47:03  <trevnorris>there are places in core you've pointed out that shouldn't be running the js callback immediately.
17:47:03  <rendar>but in such case who cares? it could be considered as a modify
17:47:04  <rendar>:)
17:47:29  * mikealjoined
17:48:05  <bnoordhuis>rendar: i don't disagree but i just know people will open bug reports for it
17:48:18  <rendar>bnoordhuis: hmm i see
17:48:47  <bnoordhuis>trevnorris: that should probably be handled in js land. for one, the argv vector will be out of scope by the time the callback runs
17:49:20  <trevnorris>bnoordhuis: so, you think just make a c++ binding to process.nextTick?
17:49:26  <trevnorris>that should be easy enough.
17:49:36  <bnoordhuis>something like that, yes
17:49:42  <rendar>bnoordhuis: also, does libuv has a recursive file remover? e.g. remove also full directoriy trees
17:49:48  <trevnorris>cool. even easier than what I was thinking. :)
17:50:07  <bnoordhuis>rendar: no. that's something that's out of scope
17:50:17  <rendar>bnoordhuis: ok, yeah i agree
17:50:59  <rendar>bnoordhuis: you mean that in such a case you call a new process "rm -rf dir/", and wait for it
17:51:02  <rendar>:)
17:51:10  <bnoordhuis>yeah, something like that :)
17:52:41  <bnoordhuis>hah, you guys seen this? http://hover.ie/
17:52:58  <bnoordhuis>doesn't work well if you have vimperator installed though :)
17:53:05  <rendar>oh this brings another problem to my mind: is that possible waiting asynchronously for a process completion? i mean, waitpid() is sync, and you can use it with an async way with signals and with SIGCHLD iirc, but what about waiting that with epoll()/kqueue? dunno if its possible
17:54:01  <bnoordhuis>rendar: libuv already supports that
17:54:10  <bnoordhuis>albeit not in the most optimized way possible
17:54:12  <MI6>libuv-master: #267 UNSTABLE windows (4/195) smartos (2/194) http://jenkins.nodejs.org/job/libuv-master/267/
17:54:45  <bnoordhuis>it works well enough that it scales up to 1,000s of processes though
17:55:37  <MI6>libuv-node-integration: #251 UNSTABLE smartos-ia32 (1/600) linux-ia32 (1/600) smartos-x64 (2/600) http://jenkins.nodejs.org/job/libuv-node-integration/251/
17:57:01  <rendar>bnoordhuis: oh, really? how it works?
17:58:25  <rendar>bnoordhuis: is that something about signal_fd?
17:58:28  <bnoordhuis>rendar: unelegantly. :-/ it catches SIGCHLD, then calls waitpid(WNOHANG) and looks up the process in a tree structure
17:58:40  <rendar>oh
17:58:46  <bnoordhuis>sadly, no. we can't really use signalfd in libuv
17:58:56  <rendar>really? why?
17:59:06  <bnoordhuis>it only works reliably when all other threads block the signal
17:59:16  <bnoordhuis>libuv is a library so it doesn't have control over that
17:59:17  <rendar>oh..i see
17:59:51  <rendar>so there must be a specific thread who waits for SIGCHLD?
18:03:38  <bnoordhuis>rendar: not quite a thread. libuv installs a SIGCHLD signal handler and signal handlers are global to the process
18:04:09  <bnoordhuis>it then works some magic to make the signal get reported to the right event loop
18:04:28  <rendar>bnoordhuis: yeah basically in unix signals are sent to the process and not to the threads, and iirc the kernel send the completion to a random(?) thread?
18:06:27  <bnoordhuis>yes, that's pretty much how it works
18:06:32  * hzquit
18:07:19  <rendar>bnoordhuis: so basically *every* thread could be interrupted to execute that SIGCHLD callback, which in turn must see to which event loop belongs the process to, with a rb-tree i guess
18:08:10  <bnoordhuis>correct
18:08:19  <rendar>interesting
18:08:33  <bnoordhuis>yeah. like i say, it's not very elegant but it gets the job done
18:08:39  <rendar>so that rb tree must also be interlocked with a mutex, because potentially all thread can be woken up to do that
18:09:04  <MI6>libuv-node-integration: #252 UNSTABLE smartos-x64 (7/644) linux-x64 (1/644) http://jenkins.nodejs.org/job/libuv-node-integration/252/
18:09:15  <bnoordhuis>we don't use a mutex because that'd be unsafe, easy to deadlock yourself that way
18:09:43  <bnoordhuis>there's some trickery with pipes that accomplishes mutex-like behavior but without the possibility of deadlock
18:09:53  <bnoordhuis>at the cost of a few extra system calls
18:10:05  <rendar>bnoordhuis: oh, but how? i mean, how lock(); rb_tree_add_process_to_loop_map(pid, loop); unlock(); could be deadlocking?
18:10:08  <bnoordhuis>i'll probably switch it to atomic ops someday
18:10:43  <bnoordhuis>rendar: because of this -> lock(); /* SIGHCLD */ void sighandler() { lock(); // deadlock
18:10:59  <rendar>oh..i see
18:11:04  <bnoordhuis>iow, your thread locks the mutex, then a signal arrives and your handler tries to lock the mutex again
18:11:09  <bnoordhuis>and bam, you're dead
18:11:19  <rendar>yeah right
18:11:42  <rendar>there isn't a way in unix to tell the system: "look, if i get SIGCHLD, send it ONLY to the thread with id=xyz" ?
18:12:14  <bnoordhuis>alas, no
18:12:26  <bnoordhuis>well, you could by blocking the signal in all other threads
18:12:31  <rendar>that would solve the problems between signals and threads i guess
18:12:34  <bnoordhuis>but that's not an option for libuv of course
18:12:49  <rendar>hmm why not? because its a library?
18:13:36  <bnoordhuis>yes
18:13:55  <rendar>i see
18:14:00  <bnoordhuis>you can't go around changing the signal mask of random threads, you'll break your user's application :)
18:14:14  <bnoordhuis>and then they'll come and scream at you
18:14:19  <rendar>eheh
18:15:03  <rendar>what about documenting it? i mean, telling the users: "look, we need one single thead listenin SIGCHLD, so we clear the mask to all other ones! if you create an your own thread, keep this in mind"
18:15:27  <bnoordhuis>then someone will pop up and say 'yes, but i _need_ to catch SIGCHLD in this other thread'
18:15:30  <trevnorris>bnoordhuis: you're node-backtrace module gave me a ridiculous idea, that'll hate myself for later. but just need to see if it can be done.
18:15:30  <trevnorris>the asyncListener api pretty easily allows infinite stacks (https://gist.github.com/trevnorris/6784855) but i'd like to use your code and get a _real_ full stack. :P
18:15:46  <rendar>bnoordhuis: lol, thats right
18:16:37  <bnoordhuis>trevnorris: that's a big stack trace
18:17:10  <trevnorris>bnoordhuis: yeah. it'll literally track every call, through async events, from the start of your program until it crashes.
18:17:16  <bnoordhuis>trevnorris: what would you want to capture though? node-backtrace just walks the current stack
18:18:02  <trevnorris>bnoordhuis: if you notice in the before() above, it also just walks the current stack. then the ability to persist the stack with the call allows me to append them as we go.
18:18:26  <trevnorris>bnoordhuis: so i'd be able to walk the entire stack on every async call, and store it for when the call returns.
18:18:51  <bnoordhuis>trevnorris: but how's that different from (new Error).stack?
18:19:09  <bnoordhuis>or was node-backtrace just the inspiration?
18:19:57  <trevnorris>bnoordhuis: I thought node-backtrace also dumps the c++ calls in the current stack.
18:20:29  <bnoordhuis>it does
18:20:46  <trevnorris>yeah, and new Error.stack only shows the js calls
18:20:47  <bnoordhuis>it basically walks the stack by following the chain of EBP/RBP pointers
18:21:14  <trevnorris>so this way i'd have a full js + c++ stack trace from the beginning of the program until it crashes.
18:21:16  <bnoordhuis>matching addresses to symbol names on the c++ side of things is pretty expensive though
18:21:49  <trevnorris>heh, this is all just a proof of concept. like, it challenged me in a dream last night.
18:22:16  <bnoordhuis>oh, i know the feeling. i was trapped in a maze of red-black tree nodes last night, all alike
18:22:33  <trevnorris>haha
18:22:34  <bnoordhuis>half tongue-in-cheek, i did dream of tree rotations last week
18:22:46  <trevnorris>lol, awesome.
18:24:48  <trevnorris>oop. of course the api has changed since you wrote this. segfaults in 0.10.20
18:25:23  <bnoordhuis>oh, yeah. i guess it's bitrotted by now
18:25:38  <bnoordhuis>i was thinking of doing a new implementation that also knows how to decode function arguments
18:26:02  <trevnorris>aah. seriously? that would be ridiculous.
18:26:32  <bnoordhuis>for js functions, anyway
18:26:44  <bnoordhuis>either that or write a gdb plugin
18:27:00  <trevnorris>eh, the js functions would be enough imho.
18:29:17  <trevnorris>but still. i'm sure that combined w/ the long stack traces would make othiym23 wet his pants.
18:29:18  * TooTallNatejoined
18:31:03  * TooTallNatequit (Client Quit)
18:35:40  * TooTallNatejoined
18:38:47  <trevnorris>bnoordhuis: do you know if it's standard in core for all the *Wrap instances to be attached to the js objects via ._handle ?
18:39:03  * indexzerojoined
18:39:03  <trevnorris>that's all I've seen so far, but could be missing something.
18:40:06  * TooTallNatequit (Ping timeout: 240 seconds)
18:40:51  * bajtosquit (Quit: bajtos)
18:46:12  * kazuponjoined
18:48:41  <MI6>nodejs-master-windows: #384 UNSTABLE windows-x64 (23/644) windows-ia32 (22/644) http://jenkins.nodejs.org/job/nodejs-master-windows/384/
18:51:16  * kazuponquit (Ping timeout: 245 seconds)
18:51:33  * TooTallNatejoined
18:52:45  <bnoordhuis>trevnorris: yes, _handle is the standard
18:52:58  <trevnorris>awesome, thanks. makes my life much easier.
18:57:56  * TooTallNatequit (Ping timeout: 245 seconds)
19:05:48  <othiym23>trevnorris: I resent the implication that I'm partially incontinent
19:05:52  <othiym23>trevnorris: ;) what's up?
19:07:08  * EhevuTovjoined
19:07:35  <trevnorris>othiym23: so, bnoordhuis created node-backtrace that'll show you the entire stack, including all the c++ calls.
19:07:36  <trevnorris>include that ability with the example long stack trace (https://gist.github.com/trevnorris/6784855) and you'll have one freakishly large stack.
19:08:59  * TooTallNatejoined
19:09:23  * wwicksquit (Quit: wwicks)
19:09:35  <othiym23>that's pretty useful!
19:09:43  * indexzeroquit (Quit: indexzero)
19:09:44  <othiym23>almost as useful as jstack helpers would be on OS X
19:11:12  <trevnorris>othiym23: and I figured out the final piece to attach existing listeners to existing handles. so maybe i'll be able to finish the domain part before v0.12 is released.
19:11:12  <trevnorris>that is, if I can stop messing around with IRHydra...
19:12:06  * indexzerojoined
19:12:14  <othiym23>awesome!
19:12:35  <othiym23>I appear to have b0rked EventEmitter with by bindEmitter change for CLS, so I have to sort that out quick
19:12:41  <othiym23>so many ways to break a Node program
19:13:33  <trevnorris>haha
19:15:10  * EhevuTovquit (Quit: This computer has gone to sleep)
19:15:48  * EhevuTovjoined
19:16:08  * indexzeroquit (Ping timeout: 240 seconds)
19:16:56  * bajtosjoined
19:22:03  * bajtosquit (Quit: bajtos)
19:27:07  * octetcloudquit (Ping timeout: 260 seconds)
19:30:04  <trevnorris>alright, here we go. here's attempt number 3 at removing domains.
19:35:15  * mikealquit (Quit: Leaving.)
19:38:02  <othiym23>gambatte!
19:38:51  * julianduquejoined
19:42:25  <superjoe>I wonder how I'll go about debugging this... https://gist.github.com/superjoe30/6799427
19:42:42  <superjoe>print statements everywhere!
19:45:46  * c4miloquit (Remote host closed the connection)
19:47:22  * TooTallNatequit (Quit: Computer has gone to sleep.)
19:49:41  <superjoe>is it safe to release memory that an async handle might need immediately after uv_close() on the handle? or do I have to put the memory freeing in the callback to uv_close() ?
19:50:45  <superjoe>empirical analysis says put the freeing in the callback.
19:51:42  * c4milojoined
19:53:06  * TooTallNatejoined
20:08:23  * wwicksjoined
20:14:32  <bnoordhuis>superjoe: from the callback, yes
20:14:58  <bnoordhuis>true for any libuv handle btw
20:24:56  <superjoe>good to know
20:25:54  <superjoe>programming with libuv has been great
20:26:14  <superjoe>somehow I haven't seemed to run into the weird impossible to duplicate race conditions
20:26:21  <superjoe>that you normally do with multithreaded programming
20:33:20  * TooTallNatequit (Quit: Computer has gone to sleep.)
20:44:02  * `3Echanged nick to `3E|ZZZ
20:54:07  <trevnorris>othiym23: ps, if you try to rebase off my branch, remove the last commit. i'm in the middle of removing all the domain specific code.
20:54:12  <trevnorris>and the world is horribly broken.
21:00:21  * trevnorrispart ("Leaving")
21:00:29  * trevnorrisjoined
21:09:59  * indexzerojoined
21:16:50  * austoquit (Quit: Leaving)
21:22:46  * bradleymeckquit (Quit: bradleymeck)
21:27:32  * TooTallNatejoined
21:28:34  * octetcloudjoined
21:37:26  * TooTallNatequit (Quit: Computer has gone to sleep.)
21:39:30  * Benviequit (Ping timeout: 252 seconds)
21:39:56  * Benviejoined
21:43:08  * bnoordhuisquit (Ping timeout: 240 seconds)
21:44:08  * wolfeidauquit (Remote host closed the connection)
21:54:24  * rendarquit
22:01:58  <trevnorris>tjfontaine: have a moment?
22:02:25  <tjfontaine>sure I'm between context switches atm
22:03:09  <tjfontaine>trevnorris.
22:03:23  <trevnorris>tjfontaine: ah, nm. i was confused for a moment because ProcessWrap seemed like it might have been for the process object, but it's for child_process
22:03:34  <tjfontaine>right
22:03:54  <trevnorris>tjfontaine: it's a bit of a confusing api. but right now there's process.{create,add,remove}AsyncListener()
22:04:11  <trevnorris>tjfontaine: but i'm also adding handle specific {add,remove}AsyncListener()
22:04:16  <tjfontaine>trevnorris: do you have any documentation I can read as a first pass for understanding it?
22:04:37  <tjfontaine>trevnorris: does it make sense for it to hang off process.?
22:05:17  <trevnorris>tjfontaine: well, it needs to be in src/node.js. and it seemed like everything in there hangs off process.
22:05:22  <trevnorris>it can't be a module, basically.
22:05:55  <tjfontaine>anyway, is there documentation for me to get an idea about?
22:06:52  * defunctzombiechanged nick to defunctzombie_zz
22:07:04  <trevnorris>tjfontaine: well, the pr has the up-to-date API: https://github.com/joyent/node/pull/6011
22:07:04  <trevnorris>and this is probably the longest commit message in node history :P https://github.com/trevnorris/node/commit/750dae79f21d18545946b311d54c1ffdadc6e90c
22:07:13  <tjfontaine>it could be a module though, in the sense that they are exported through that interface, but not necessarily defined in that file -- for instance the demacro-fication of the tracing stuff was scheduled to land in _trace, we could just push them into it from node.js
22:07:46  <tjfontaine>jeepers that's a lot of failing tests :)
22:07:46  * mikealjoined
22:08:10  <trevnorris>oh yeah. right now domains are botched.
22:08:17  <trevnorris>i'm surprised even that many are passing.
22:08:47  <trevnorris>finally figured out a way to remove domain code from c++, but it's like tweezing individual pubic hairs.
22:09:37  <tjfontaine>that's specific
22:10:00  <trevnorris>eh, right now that's how it feels.
22:10:14  <tjfontaine> Adding an async listener will immediately add it to the queue and
22:10:15  <tjfontaine> * being listening for events
22:10:17  <tjfontaine>*begin :P
22:10:42  <trevnorris>... right. i'll fix that sometime before it goes in.
22:10:57  <trevnorris>honestly that should all be docs somewhere, and have a much shorter commit message
22:11:01  <trevnorris>not sure what I was thinking.
22:11:59  <tjfontaine>blah I wish Ic ould easily except out commits from github's ui
22:12:19  <othiym23>trevnorris: just lemme know when it's safe to rebase and I won't touch it until then
22:12:25  <tjfontaine>?w=1 is somewhat helpful, but the rest of the comment styling shit in domain.js I dont' care about
22:12:43  <trevnorris>tjfontaine: hah, yeah.
22:12:53  <trevnorris>othiym23: ok. might not be for a while. :)
22:12:58  <tjfontaine>dammit github you suck
22:13:22  * indexzeroquit (Quit: indexzero)
22:14:22  <trevnorris>i wish the v8 api had indexOf()
22:14:37  <tjfontaine>you can always eval'it
22:15:11  <othiym23>tjfontaine, are you trolling trevnorris
22:15:19  <trevnorris>that just made me shutter a little.
22:16:23  <tjfontaine>heh, well what I mean is: ->Get('indexOf')->As<Function>().Call()
22:16:28  <tjfontaine>that's what I mean as 'eval'
22:16:39  <trevnorris>ah, ok.
22:17:00  <trevnorris>thought you meant literally writing a script as a char* and running it from the v8 script api
22:17:20  <tjfontaine>you could do it that way as well, but you know, whatever
22:17:30  <tjfontaine>would be pretty interesting to see which is faster
22:18:11  <trevnorris>fortunately this is an operation that won't be done much.
22:18:22  <trevnorris>or at least I hope it wouldn't
22:18:23  <tjfontaine>where you just make a context with a script contents of "return Array.prototype.indexOf" and then .As<Function>()->Call that
22:18:26  * trevnorrislooks at othiym23
22:19:40  <othiym23>good, good
22:20:16  <trevnorris>othiym23: basically, i'm adding the ability to add/remove listeners on an individual handle
22:20:33  <trevnorris>don't like it, but needs to be done if we're properly going to emulate domains.
22:20:36  <othiym23>right
22:20:45  <othiym23>is that going to remain confined to the C++ side of things?
22:20:48  <tjfontaine>you mean: foo._handle.[add|remove]AsyncListener?
22:20:57  <trevnorris>tjfontaine: yeah
22:21:01  <tjfontaine>hrm.
22:21:15  <trevnorris>tjfontaine: it's for internal use only
22:21:29  <tjfontaine>ha h
22:21:30  <tjfontaine>a
22:22:04  <trevnorris>tjfontaine: specifically so when a user runs the .listen() command, if a domain has been bound to the event emitter we can bind the listener to the handle after it's been instantiated.
22:22:07  <othiym23>I can't not promise you that I won't not totally abuse that API if I have easy access to it
22:22:37  <trevnorris>la la la *plugs ears*
22:22:52  <tjfontaine>trevnorris: ya, no I get it's use case, I actually wonder if it shouldn't be first class in the form of this concept
22:23:15  <trevnorris>tjfontaine: well, it will be with some plans I have for v0.13.
22:23:33  <trevnorris>but right now with the way everything is abstracted through the event emitter, makes life a bitgh
22:23:33  <tjfontaine>well then I think we need to make sure we do that now, instead of adding api in 0.13
22:23:36  <trevnorris>bitch
22:24:05  <trevnorris>hah, then v0.12's going to have to wait another 2 months at the least.
22:24:21  <tjfontaine>then I would say first class of this async listener would have to wait until after 1.0
22:24:26  <tjfontaine>because it's a real feature
22:24:57  <tjfontaine>would *really* just like to fix on bugs and perf for 0.13, which certainly involves ripping out and reimplementing things like domains/http/tls
22:25:09  <trevnorris>tjfontaine: well, the api that's exposed to the user is feature complete.
22:25:18  <tjfontaine>but doesn't necessarily include a whole new api feature
22:25:30  <trevnorris>right now i'm working around internals trying to separate domains from c++ core code.
22:25:38  <trevnorris>just like to get that done before the v0.12 release.
22:25:58  <tjfontaine>right, completely internal things are all fair game, but a whole new first class feature I would really like to punt on
22:26:28  <tjfontaine>so here's a question that came up today
22:26:42  <trevnorris>tjfontaine: read the first "experimental" tag here: https://github.com/joyent/node/issues/6252
22:26:57  <trevnorris>that's something I'd like to get done before v1.0.
22:27:31  <tjfontaine>given an http.request, which has a content-length, if we might emit end but haven't yet seen all data, should we emit an error instead of end
22:28:50  * defunctzombie_zzchanged nick to defunctzombie
22:29:03  <trevnorris>tjfontaine: um. if the data coming in doesn't match the content-length in the header, I don't think there should be any type of error that causes the application to crash.
22:29:18  * defunctzombiechanged nick to defunctzombie_zz
22:29:28  <tjfontaine>I didn't say cause the application to crash, but instead to emit an error
22:29:40  <tjfontaine>just like we emit if the connection was reset
22:30:56  <trevnorris>tjfontaine: well, thinking about it at a lower level, does request() use keepalive?
22:31:03  <tjfontaine>it may
22:32:37  <trevnorris>give me a sec. reading up on tcp
22:32:43  <tjfontaine>it's not about tcp
22:33:12  <tjfontaine>you do http.get in node, you get back a response with a content-length of 100mb, remote side sends you 10mb, then closes the connection
22:33:16  <trevnorris>well, if not using keepalive then who/when closes the connection
22:33:18  <tjfontaine>in this scenario we emit end, and then close
22:33:31  <trevnorris>ok, yeah.
22:34:06  <tjfontaine>if we're about to emit end on an http request response, and we had a content length and haven't seen all of it yet -- it really seems like that should be an error
22:34:16  <tjfontaine>because content-length is not an advisory field
22:34:32  <trevnorris>um. I might ask, what do browsers do?
22:34:43  <tjfontaine>well I am more curious what python/ruby/perl do
22:35:12  <tjfontaine>but you could fake this up in node really easy to find out what your browser says
22:42:00  <tjfontaine>Error code: ERR_CONTENT_LENGTH_MISMATCH
22:42:03  <tjfontaine>on chrome
22:42:11  <tjfontaine>firefox just soldiers on
22:42:22  <trevnorris>hah, ok.
22:42:53  * Kakeraquit (Ping timeout: 240 seconds)
22:44:08  <tjfontaine>python urllib2.urlopen doesn't care though
22:44:12  <trevnorris>tjfontaine: ok, well. if there's too much data I say we emit the exact amount of data in the header, then emit an error
22:44:19  <tjfontaine>at least not urllib2.urlopen('http://localhost:3000').read()
22:44:29  <tjfontaine>trevnorris: right I agree
22:44:30  <trevnorris>if they ignore the error, then they'll just get the amount of data they were told to expect
22:44:42  <tjfontaine>it's not something we can change for 0.10 of course
22:45:03  <tjfontaine>but I think it's something we [c|sh]ould change for 0.12
22:46:45  <trevnorris>nod
22:46:52  <tjfontaine>ah
22:46:53  <tjfontaine>Changed in version 2.5: urlretrieve() will raise ContentTooShortError when it detects that the amount of data available was less than the expected amount (which is the size reported by a Content-Length header). This can occur, for example, when the download is interrupted.
22:47:04  <tjfontaine>so it depends on what path you're in on python
22:47:31  <tjfontaine>the next line is wrong, but probably also how we would handle it
22:47:32  <tjfontaine>The Content-Length is treated as a lower bound: if there‚Äôs more data to read, urlretrieve() reads more data, but if less data is available, it raises the exception
22:48:09  <trevnorris>interesting.
22:48:15  <trevnorris>but is that what the spec says?
22:49:12  * bnoordhuisjoined
22:49:25  <tjfontaine>When a Content-Length is given in a message where a message-body is allowed, its field value MUST exactly match the number of OCTETs in the message-body. HTTP/1.1 user agents MUST notify the user when an invalid length is received and detected.
22:49:45  <tjfontaine>so in that regard, we're not following the spec
22:50:28  <trevnorris>tjfontaine: ok. so my understanding from that wording is that we can choose to continue accepting the data, we just need to let the user know it's been exceeded.
22:50:43  <tjfontaine>for exceeded yes
22:50:56  <trevnorris>yeah. so emit an error, but continue accepting data.
22:50:58  <tjfontaine>either way, if it's a mismatch we need to be notifying the user
22:50:59  <trevnorris>sounds fine.
22:51:06  <trevnorris>yeah. sounds correct.
22:53:26  * bnoordhuisquit (Ping timeout: 240 seconds)
23:18:25  * austojoined
23:26:18  * st_lukejoined
23:26:45  * inolenquit (Read error: Connection reset by peer)
23:27:51  * inolenjoined
23:29:45  * c4miloquit (Remote host closed the connection)
23:30:24  <trevnorris>tjfontaine: we should do something about --max-opt-count, meaning, node processes are supposed to be long-running. but if a function de-opts max-opt-count times then it won't try to be optimized again. even if it's only happened once in a while.
23:32:42  <tjfontaine>hm
23:33:10  <trevnorris>also, theirs --deopt-every-n-times.
23:33:19  <trevnorris>i feel like there's optimizing we can do there.
23:33:29  <tjfontaine>wouldn't it be better if we could have multiple opts in place? :)
23:34:42  <trevnorris>well, it bothers me that there's no option for, never stop.
23:35:23  <tjfontaine>nod
23:40:40  <trevnorris>tjfontaine: ah, would you look at that. --always_opt
23:40:48  <trevnorris>there are so many freakin flags.
23:41:23  <tjfontaine>yes
23:41:36  <tjfontaine>also, not all of their operation is sensible
23:41:46  * st_lukequit (Read error: Connection reset by peer)
23:42:11  <trevnorris>i just want an --unsafe-but-performant-awesomeness flag
23:42:33  <tjfontaine>node --go-fast
23:42:36  <tjfontaine>:P
23:42:42  <trevnorris>whoot! I like it.
23:43:46  <trevnorris>ooh, and this looks interesting: --always_inline_smi_code
23:43:54  <trevnorris>just wish there was a manual for all of these.
23:44:06  <trevnorris>the brief descriptions they give are almost useless to me
23:44:24  <tjfontaine>yes, and you never know from release to release how meaningful they'll even be
23:44:43  <trevnorris>seriously.
23:50:33  <othiym23>Readable does some seriously weird shit to EEs
23:50:45  <tjfontaine>in which way?
23:51:02  <othiym23>suddenly! you call .on on a Readable! and .on changes to a different function after the call!
23:51:08  <othiym23>that's *my* job
23:51:16  <tjfontaine>oh hah
23:52:41  * st_lukejoined
23:53:02  * qardjoined
23:58:07  <othiym23>tjfontaine: what the hell is going on here? https://github.com/joyent/node/blob/master/lib/_stream_readable.js#L662-L693
23:58:20  <othiym23>this kind of self-modifying code makes me kinda ill
23:59:22  <tjfontaine>ya, I understand
23:59:43  * c4milojoined
23:59:51  <MI6>libuv-master-gyp: #207 FAILURE windows-x64 (3/195) windows-ia32 (3/195) linux-ia32 (1/194) http://jenkins.nodejs.org/job/libuv-master-gyp/207/
23:59:57  <tjfontaine>but it's not an uncommon pattern to find