00:00:02  * ircretaryquit (Remote host closed the connection)
00:00:06  <MI6>libuv-master-gyp: #103 UNSTABLE smartos-x64 (2/192) smartos-ia32 (2/192) windows-x64 (3/193) windows-ia32 (3/193) http://jenkins.nodejs.org/job/libuv-master-gyp/103/
00:00:11  * ircretaryjoined
00:07:45  * indexzeroquit (Quit: indexzero)
00:10:03  * bradleymeckjoined
00:13:32  * brsonquit (Quit: leaving)
00:13:49  * brsonjoined
00:29:40  * mikealquit (Read error: Connection reset by peer)
00:45:54  * amartensquit (Quit: Leaving.)
00:48:50  * mikealjoined
01:13:39  * mikealquit (Quit: Leaving.)
01:16:19  * stagasquit (Ping timeout: 246 seconds)
01:18:49  * mikealjoined
01:28:41  * mikealquit (Quit: Leaving.)
01:30:56  * TooTallNatequit (Quit: Computer has gone to sleep.)
01:36:22  * abraxasjoined
01:48:44  * dap1joined
01:48:44  * dapquit (Read error: Connection reset by peer)
01:58:05  * c4miloquit (Remote host closed the connection)
01:59:41  * c4milojoined
02:12:28  * mikealjoined
02:13:18  * kazuponjoined
02:21:56  * kazuponquit (Remote host closed the connection)
02:41:40  * stagasjoined
02:47:51  * TooTallNatejoined
03:03:13  * st_lukequit (Remote host closed the connection)
03:05:20  * st_lukejoined
03:16:26  * st_lukequit (Remote host closed the connection)
03:22:30  * mikealquit (Quit: Leaving.)
03:30:54  * stagasquit (Read error: Connection reset by peer)
03:43:07  * indexzerojoined
03:47:21  * TooTallNatequit (Quit: ["Textual IRC Client: www.textualapp.com"])
03:54:39  <isaacs>trevnorris: you around?
03:55:13  * kazuponjoined
03:59:11  * defunctzombiechanged nick to defunctzombie_zz
04:04:24  * bradleymeckquit (Quit: bradleymeck)
04:08:00  * defunctzombie_zzchanged nick to defunctzombie
04:09:29  * indexzeroquit (Quit: indexzero)
04:39:38  * wolfeidaujoined
04:54:52  * c4miloquit (Remote host closed the connection)
04:58:38  * st_lukejoined
05:15:05  * wolfeidauquit (Remote host closed the connection)
05:15:13  * bajtosjoined
05:25:55  * julianduquequit (Read error: Operation timed out)
05:46:07  * szhangjoined
05:47:06  <szhang>hi
05:47:16  <tjfontaine>hi
05:47:25  <szhang>how can I compile libuv to iOS?
05:48:17  <tjfontaine>I know some people have done it, but I don't have a reference off hand, I would start by using gyp to generate an xcode build for libuv as a static library
05:49:24  <szhang>OK, I'll have a try
06:01:50  * brsonquit (Quit: leaving)
06:25:40  * felixgejoined
06:25:40  * felixgequit (Changing host)
06:25:40  * felixgejoined
06:34:05  * st_lukequit (Ping timeout: 240 seconds)
06:40:20  * st_lukejoined
06:42:36  <MI6>nodejs-v0.10-windows: #144 UNSTABLE windows-x64 (8/594) windows-ia32 (7/594) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/144/
06:50:35  * rendarjoined
06:58:46  * st_lukequit (Remote host closed the connection)
07:02:38  * st_lukejoined
07:03:20  * Damn3dquit (Ping timeout: 245 seconds)
07:05:01  * Damn3djoined
07:11:16  * Benviequit (Remote host closed the connection)
07:11:35  * Benviejoined
07:22:26  <szhang>hi, I have got libuv compiled with iOS SDK, but I have to modify darwin-proctitle.h
07:52:57  * st_lukequit (Remote host closed the connection)
07:55:21  * st_lukejoined
08:23:29  * hzjoined
08:50:32  * hzquit (Read error: Connection reset by peer)
08:51:47  * bnoordhuisjoined
08:54:42  * hzjoined
08:59:35  * st_lukequit (Remote host closed the connection)
09:02:20  * st_lukejoined
09:18:33  * st_lukequit (Remote host closed the connection)
09:31:38  * dominictarrjoined
09:44:21  * kazuponquit (Remote host closed the connection)
09:44:57  * perezdquit (Quit: perezd)
10:10:09  * st_lukejoined
10:14:52  * st_lukequit (Ping timeout: 264 seconds)
10:25:43  * kazuponjoined
10:31:48  * defunctzombiechanged nick to defunctzombie_zz
10:35:53  * kazuponquit (Ping timeout: 240 seconds)
10:52:02  * hzquit (Remote host closed the connection)
10:57:03  * felixgequit (Quit: felixge)
11:09:35  * hzjoined
11:15:34  * hzquit (Remote host closed the connection)
11:16:57  * hzjoined
11:19:42  * bajtosquit (Quit: bajtos)
11:52:06  * hzquit (Remote host closed the connection)
11:55:57  * hzjoined
12:02:52  <indutny>hoya
12:16:05  <bnoordhuis>sup fedor?
12:18:05  * hzquit (Remote host closed the connection)
12:21:53  * hzjoined
12:22:53  <MI6>joyent/node: Ben Noordhuis master * 98c5424 : tools: cpplint: fix NOLINT(build/include_order) - http://git.io/YVH2uQ
12:34:28  * hzquit (Remote host closed the connection)
12:35:18  * pachetjoined
12:35:46  <indutny>bnoordhuis: everything is fine
12:35:51  <indutny>deduplicating crypto right now
12:37:22  <indutny>bnoordhuis: need some help
12:37:32  <indutny>Undefined symbols for architecture x86_64:
12:37:32  <indutny> "node::crypto::VerifyCallback", referenced from:Undefined symbols for architecture x86_64:
12:37:32  <indutny> "node::crypto::VerifyCallback", referenced from:
12:37:41  <indutny>(maybe you meant: __ZN4node6crypto14VerifyCallbackEiP17x509_store_ctx_st)
12:37:55  <indutny>it seems like its trying to lookup non-mangled name?
12:39:31  <indutny>nvm
12:39:33  <indutny>figured it out
12:39:56  * hzjoined
12:46:57  <indutny>brb
12:48:44  * felixgejoined
12:55:05  * bradleymeckjoined
13:03:47  * stagasjoined
13:04:18  * bajtosjoined
13:05:49  * hzquit (Remote host closed the connection)
13:14:42  * hzjoined
13:22:35  * bradleymeckquit (Quit: bradleymeck)
13:37:05  <Domenic_>so for vm2, two questions:
13:37:36  <Domenic_>1) is getting rid of node_script actually a good idea? or should we leave it alone, since it's so core to the platform?
13:38:15  <Domenic_>and 2) any help debugging the assertion failure at https://github.com/domenic/node/commit/1a8210c804ec9cacfb5b689e53393bc765a2d89a would be lovely. I was told "probably a race condition" "something going out of scope" but not really sure what to do with it.
13:41:08  <bnoordhuis>Domenic_: you mean process.binding('node_script')?
13:47:51  * hzquit
13:48:56  * stagasquit (Ping timeout: 256 seconds)
13:49:23  <Domenic_>bnoordhuis: process.binding('evals'), but yeah.
13:49:28  * szhangpart ("ERC Version 5.3 (IRC client for Emacs)")
13:50:12  * stagasjoined
13:56:28  <Domenic_>bnoordhuis: this was my first attempt, although it's causing some test failures so I need to fix it a bit. https://github.com/domenic/node/commit/e47670905c18d957d7d1310c2ed9de56bcf13f84
13:56:58  * stagas_joined
13:57:55  * stagasquit (Ping timeout: 245 seconds)
13:57:59  * stagas_changed nick to stagas
14:03:59  <bnoordhuis>Domenic_: bindings are internal. you can remove it as long as it doesn't break anything in core
14:04:20  <bnoordhuis>if it breaks something in someone's code, tough luck - that's what you get for depending on internals
14:04:44  <Domenic_>bnoordhuis: yeah that makes sense. just wasn't sure if touching something so core to the module system etc. might be frowned upon.
14:05:02  * stagasquit (Ping timeout: 240 seconds)
14:09:31  <rendar>what happen when a signal interrupts a slow syscall (like read() or write()) in the middle of i/o? if it happens *before* i/o starts, you can just call again read() or write(), but in the middle of i/o? i guess the read() or write() returns the number of bytes processed but after how to read (or write) the remaining ones? how libuv solve this?
14:10:26  <bnoordhuis>rendar: EINTR means nothing has been read or written
14:11:03  <bnoordhuis>barring kernel bugs, of course (which has happened in the past - solaris, i'm looking at you!)
14:11:18  <rendar>eheh
14:11:41  * bradleymeckjoined
14:11:52  <rendar>yes exactly, so when the i/o is in the middle of processing, read() and write() returns the number of bytes processed, but then, will the fd noticed up again, by epoll/kqueue/etc ?
14:12:17  <rendar>i mean, epoll/kqueue/etc *already* noticed the fd is ready for read
14:12:20  <bnoordhuis>rendar: yes (for epoll, yes when the fd is in level-triggered mode)
14:12:24  <rendar>they do not know nothing about signals, i guess
14:12:38  <rendar>bnoordhuis, oh, when EPOLLET is specified?
14:12:46  <bnoordhuis>no, the other way around :)
14:13:12  <bnoordhuis>most unix poll apis are level-triggered. an event keeps on being reported until it's consumed
14:13:23  <bnoordhuis>the exception is epoll in EPOLLET mode
14:13:39  <bnoordhuis>that's edge-triggered mode, meaning the kernel reports the event once and it's up to you to keep track
14:14:26  <rendar>hmm yeah right
14:14:43  <rendar>bnoordhuis, so why it seems everyone uses EPOLLET instead of level-triggering?
14:14:51  <bnoordhuis>because it's faster
14:14:53  <bnoordhuis>well, usually
14:15:17  <bnoordhuis>in theory, you don't have to make as many syscalls as in level-triggered mode
14:15:36  <rendar>hmm
14:15:46  <bnoordhuis>because you don't have to call epoll_ctl() all the time to update the event mask
14:15:50  <rendar>i saw that libuv swaps from level to edge triggering? am i right?
14:15:59  <bnoordhuis>maybe
14:16:05  <bnoordhuis>i have patches sitting in a tree
14:16:13  * mcavagejoined
14:16:25  <bnoordhuis>however, there are some corner cases where edge-triggered mode is actually slower due to lock contention in the kernel
14:16:42  <rendar>i see
14:16:52  <rendar>this is for epoll, what about kqueue and others?
14:17:09  <bnoordhuis>i've considered fixing it and sending patches to the LKML - but that doesn't help with existing kernels :-/
14:17:19  <bnoordhuis>the other poll apis are all level-triggered
14:17:33  <bnoordhuis>kqueue in theory can work in edge-triggered mode
14:17:48  <bnoordhuis>but that's basically a kind of one-shot mode where you have to re-add the fd yourself every time
14:17:48  <rendar>hmm
14:18:00  <bnoordhuis>so it doesn't save you syscalls
14:18:33  <rendar>i see, so how about read() write() are interrupted and you're in level triggering mode? how you can know that you have to keep reading/wiritng?
14:19:13  <bnoordhuis>rendar: it doesn't matter in LT mode, the kernel will keep reporting the event until there is no more data to read / write
14:19:37  <bnoordhuis>even so, libuv wraps calls to read() and write() in a do { ... } while (r == -1 && errno == EINTR) loop
14:19:53  <bnoordhuis>i.e. it retries the syscall
14:19:53  <rendar>oh ok
14:20:28  <bnoordhuis>i should note that - in theory - that means you could starve an application if you deliver signals so fast the syscall never completes
14:20:30  <rendar>bnoordhuis, so in LT mode (the default mode of all unices) until you don't read ALL the data pending, the fd will be reported in the next wave of data arrival
14:20:38  <bnoordhuis>in practice that means you probably have bigger issues to worry about
14:20:46  <bnoordhuis>rendar: correct
14:21:02  <rendar>hmm
14:21:57  <rendar>bnoordhuis, i agree to the starving thing, that should be pondered about
14:22:28  <rendar>bnoordhuis, once time ago, the author of libev told me "just disable *all* signals facilities in unix"
14:22:44  <bnoordhuis>well, yeah
14:22:59  <bnoordhuis>you can't do away completely with signals, you need them for some things
14:23:18  <bnoordhuis>but in general they're a pain. adding signals probably seemed like a good idea at the time
14:23:31  <rendar>yeah i totally agree
14:23:31  <bnoordhuis>when applications were always single-threaded
14:23:35  <rendar>nowadays they're not used anymore
14:23:48  <rendar>expecially with multithreaded applications
14:24:00  <bnoordhuis>i don't know about 'not used'
14:24:08  <bnoordhuis>when you press ^C, that generates a SIGINT
14:24:34  <bnoordhuis>likewise, profiling is traditionally done by instrumenting your application and sending it SIGPROFs at fixed intervals
14:24:49  <bnoordhuis>terminating applications, SIGTERM or SIGKILL
14:24:59  <bnoordhuis>SIGWINCH when the terminal is resized
14:25:02  <bnoordhuis>i can go on :)
14:25:13  <rendar>hmmm yeah..
14:25:44  <rendar>well, i just think that the stupid thing is just EINTR, because signals themself are still useful/used
14:26:14  <rendar>but if we don't have that fucked EINTR, or btw the possibility to disable interrupting syscall by signals, would be great..
14:26:45  <bnoordhuis>i don't entirely disagree
14:27:02  <bnoordhuis>the thing that annoys me the most is that you still have to deal with EINTR even if the fd is non-blocking
14:27:12  <rendar>yeah
14:27:19  <bnoordhuis>i blame posix
14:27:31  <rendar>yeah, very bad design decision
14:27:52  <bnoordhuis>that was somewhat tongue-in-cheek
14:28:07  <bnoordhuis>posix just rounds up what unices do and puts that in a specification
14:28:17  <isaacs>good morning
14:28:22  <bnoordhuis>hey isaac
14:28:54  <bnoordhuis>rendar: if you want to blame someone or something, it should probably be BSD
14:29:04  <bnoordhuis>i'm reasonably sure they started it
14:29:26  <rendar>i see
14:29:31  <rendar>like select() :)
14:29:37  <rendar>instead sysV used poll()
14:30:16  <isaacs>Domenic_: Yes, touching something as core to node's system as node_script.cc is frowned upon, but it's frowning that we'll just have to accept, because it needs some deep touching.
14:30:25  <rendar>isaacs, hi
14:30:31  <isaacs>rendar: hola
14:33:08  * mordy___quit (Ping timeout: 256 seconds)
14:37:28  <isaacs>bnoordhuis: so, we have this "optimization" in lib/_http_outgoing.js: https://github.com/joyent/node/blob/master/lib/_http_outgoing.js#L175-L182
14:38:01  <isaacs>bnoordhuis: it's... odd. if you do res.write('aaaa', 'hex'); res.write('b'); then you'll get 'aaaab' sent to the client.
14:38:24  <bnoordhuis>that'd be a bug, wouldn't it?
14:39:01  <isaacs>bnoordhuis: yeah. i was wondering if you had any insights into it, but now that i git-blame it, it was written by ryah in 2010.
14:39:08  <rendar>why? isn't that correct? you first write 'aaaa' then 'b'
14:39:17  <isaacs>rendar: you're writing 'aaaa' as 'hex'
14:39:18  <isaacs>not as utf8
14:39:22  <rendar>oh sorry
14:39:25  <rendar>didn't read that
14:39:58  <bnoordhuis>Error: spawn EMFILE at exports._errnoException (util.js:676:11)
14:40:02  <isaacs>bnoordhuis: so, i've backed out of my big http-outgoing-refactor, and i'm just making smaller improvements to get to the API i want
14:40:19  <bnoordhuis>opinions on raising the fd rlimit in node to rlim_max?
14:40:35  <bnoordhuis>isaacs: oh. that sounds like a bummer
14:41:44  <isaacs>bnoordhuis: yeah, it was a very educational journey. but unless we have a this._handle=process.binding('http_wrap'), we can't afford two buffering back-pressuring drain-emitting Writable objects in the http.OutgoingMessage flow
14:41:51  <isaacs>and we already ahve a net.Socket
14:42:42  <isaacs>the header management changes were faster in many common use-cases, and fixed some common user requests, but the overall approach is not sound, unfortunately. OutgoingMessage needs to be a light facade around a Socket
14:42:43  * AvianFlujoined
14:42:56  <isaacs>(like it is now, but... not so broken.)
14:44:11  * stagasjoined
14:48:35  <MI6>joyent/node: Ben Noordhuis master * 9c59978 : smalloc: don't do Has(key), then Get(key) - http://git.io/KBjq7w
14:49:14  <bnoordhuis>isaacs: by the way, did you see that issue i assigned to you?
14:49:33  <bnoordhuis>the one about fs.ReadStream not closing the fd when the destination closes
14:51:48  * c4milojoined
14:53:10  <bnoordhuis>trevnorris: ping. is smalloc.h a public header?
14:53:22  <bnoordhuis>(i'm fearing the answer is yes)
14:56:52  <indutny>bnoordhuis: yt?
14:57:01  <indutny>bnoordhuis: mind helping me a bit
14:57:02  <indutny>?
15:04:51  <bnoordhuis>indutny: sorry, at dinner. biab
15:04:57  <indutny>bnoordhuis: see ya
15:06:23  <isaacs>bnoordhuis: i did not. i'll take a look.
15:06:41  <isaacs>bnoordhuis: is that what eldar was complaining about?
15:08:08  * mordy__joined
15:10:04  * bnoordhuisquit (Ping timeout: 264 seconds)
15:10:06  * c4miloquit (Remote host closed the connection)
15:10:45  <isaacs>oh, no, this is different.
15:18:03  * spolujoined
15:27:40  * jmar777joined
16:00:25  * dominictarrquit (Quit: dominictarr)
16:11:03  * AvianFluquit (Remote host closed the connection)
16:15:17  * bnoordhuisjoined
16:19:35  * bnoordhuisquit (Ping timeout: 245 seconds)
16:34:00  * bradleymeckquit (Quit: bradleymeck)
16:37:14  * bnoordhuisjoined
16:39:09  * julianduquejoined
16:41:25  * AvianFlujoined
16:41:41  * piscisaureus_joined
16:42:10  <piscisaureus_>ircretary: tell sblom where are you? :)
16:42:10  <ircretary>piscisaureus_: I'll be sure to tell sblom
16:42:42  * c4milojoined
16:44:03  * sblomjoined
16:44:41  <sblom>@piscisaureus_: I'm here.
16:44:45  <sblom>And I'm hacking on unit tests.
16:44:56  <piscisaureus_>sblom: ah, kewl
16:45:05  <piscisaureus_>sblom: I'm "around" as we agreed :)
16:46:28  <sblom>piscisaureus_: And I seriously appreciate it.
16:46:50  <piscisaureus_>sblom: you're welcome :)
16:47:49  <sblom>I even have a starter question.
16:48:57  <sblom>piscisaureus_: I'm investigating test-cluster-bind-twice. And I see that one of the child processes is the one with the headache. Do you have a good trick for getting a debugger attached to it?
16:49:05  * AvianFluquit (Read error: Operation timed out)
16:49:24  <sblom>I wish Visual Studio had some "automatically attach to child processes" feature.
16:49:38  <piscisaureus_>yeah I miss that too...
16:49:57  <piscisaureus_>sblom: I think that if you build the debug build then the 'debug;' javascript statement will break
16:50:16  <sblom>Oh, neat.
16:50:55  <piscisaureus_>sblom: what you could also do is have some sort of "pause" when node starts
16:51:00  <piscisaureus_>e.g wait for a keypress
16:51:05  <piscisaureus_>and then manually attach the debugger
16:51:42  <sblom>piscisaureus_: fair enough. \
16:53:12  <piscisaureus_>sblom: or... windbg
16:53:48  <sblom>very good point on that last one. I used to feel about half comfortable inside windbg, but that muscle is seriously atrophied at this point.
16:54:18  <sblom>I'll give it a shot if the other tricks are too painful.
16:54:50  * hzjoined
17:05:14  * TooTallNatejoined
17:06:43  * hzquit (Remote host closed the connection)
17:08:06  * brsonjoined
17:12:06  * amartensjoined
17:12:39  * mcavagequit (Remote host closed the connection)
17:17:22  * mcavagejoined
17:18:05  * perezdjoined
17:22:55  * hzjoined
17:24:34  * c4miloquit (Remote host closed the connection)
17:31:50  * AvianFlujoined
17:32:49  * mcavagequit (Remote host closed the connection)
17:35:57  * pachetquit (Quit: leaving)
17:37:12  * spoluquit (Ping timeout: 268 seconds)
17:39:29  * philipsquit (Changing host)
17:39:30  * philipsjoined
17:40:17  * julianduquequit (Ping timeout: 268 seconds)
17:41:30  <indutny>bnoordhuis: hoooya
17:41:38  <indutny>bnoordhuis:any thoughts https://github.com/joyent/node/pull/6057/files ?
17:42:17  <indutny>bnoordhuis: There're a couple of functions that could be merged, but that's mostly it
17:42:46  <indutny>bnoordhuis: and all other functions are diverging too much to be easily merged
17:42:59  * st_lukejoined
17:48:41  <sblom>piscisaureus_: Wow--there's a lot going on in this test. http://jenkins.nodejs.org/job/nodejs-master-windows/219/DESTCPU=ia32,label=windows/tapTestReport/test.tap-46/
17:49:15  <sblom>I've traced in pretty far, and the surprising failure seems to be in uv_tcp_set_socket during a uv_pipe_accept.
17:49:52  <sblom>Getting a UV_ENOTSOCK while trying to set the socket to nonblocking mode.
17:50:23  <sblom>Are the IPC pipes between parent and child processes in cluster supposed to be TCP sockets?
17:50:42  <sblom>I don't understand all of what's going on, but it sorta looks like something thinks that's true when it's not.
17:51:32  * AvianFluquit (Remote host closed the connection)
17:52:52  <sblom>http://gist.github.com/anonymous/42d47a4802d30bf990dc
17:52:52  <piscisaureus_>sblom: no, they are pipes
17:52:55  <piscisaureus_>sblom: names pipes
17:53:36  <piscisaureus_>sblom: but I think that stack trace is where it accepts a handle
17:54:50  * mcavagejoined
17:55:12  <MI6>libuv-master: #164 UNSTABLE windows (3/193) smartos (9/192) linux (1/192) http://jenkins.nodejs.org/job/libuv-master/164/
17:55:14  <piscisaureus_>sblom: it should have created a valid socket handle from the WSAPROTOCOL_INFOW structure that we sent over the pipe
17:57:58  <sblom>piscisaureus_: Ahh. That helps. From the test failure, it's clearly IPC that's failing: http://jenkins.nodejs.org/job/nodejs-master-windows/219/DESTCPU=ia32,label=windows/tapTestReport/test.tap-46/
17:58:01  <bnoordhuis>indutny: reviewed. -400 lines of code is a good start
17:58:19  <sblom>piscisaureus_: but what I'm seeing is definitely an abort() caused while unwinding that stack I gisted.
17:58:43  <sblom>piscisaureus_: but the IPC failure is consistent with the child process aborting out from under some attempt to send to it, right?
17:58:44  <indutny>bnoordhuis: how much do you want?
17:58:59  <piscisaureus_>sblom: yeah
17:59:09  <piscisaureus_>sblom: the pipe errs if you close it that way
17:59:19  <bnoordhuis>indutny: how much can i get?
17:59:24  <indutny>bnoordhuis: all of it
17:59:30  <indutny>hahaha
17:59:38  <indutny>well, I don't think there's a big point in it
17:59:43  <sblom>piscisaureus_: Okay. So I need to figure out how to check up on that handle on the parent side of this cluster.fork.
17:59:46  <indutny>that code in node_crypto.cc is a subject for removal
17:59:51  <indutny>hopefuly in 1.0
17:59:54  * dominictarrjoined
18:00:14  <indutny>I don't really enjoy having two ways of using the same functionality
18:00:23  <indutny>also it generics complicates things
18:00:30  <sblom>This'll be really fun. :-S
18:00:37  <piscisaureus_>sblom: I'm not sure, I don't really know what's happening :)
18:00:53  <sblom>piscisaureus_: I was more thinking out loud there.
18:00:57  <piscisaureus_>sblom: I have to go now, bb in 5
18:03:01  * bajtosquit (Quit: bajtos)
18:03:13  <bnoordhuis>indutny: better than replicating reams of code
18:03:25  <bnoordhuis>i don't want to be fixing the same bug twice all the time
18:03:39  <indutny>bnoordhuis: heh
18:03:42  <indutny>speaking of bugs
18:03:46  <indutny>there's one in crypto_bio
18:03:52  <indutny>that isn't reproducible in node yet
18:04:01  <indutny>but was reproducible in my port of crypto_bio.cc to C
18:05:02  * piscisaureus_quit (Ping timeout: 240 seconds)
18:06:12  <bnoordhuis>indutny: go on
18:06:30  <indutny>bnoordhuis: I'm trying to find it :)
18:06:34  <indutny>one sec
18:07:02  <indutny>oh, I believe that's it https://github.com/Voxer/stud/commit/1190e35d403994ee9f8f1935ab41ea2ac171913a#L3R95
18:07:16  <indutny>basically, sometimes read head is stuck
18:07:22  <indutny>and Peek() will return 0-length chunk
18:07:35  <indutny>that happens because we don't move head in Peek()
18:07:41  <indutny>and that's what's wrong here
18:08:15  <bnoordhuis>when would that happen?
18:09:07  <indutny>1. Write() should fill one Buffer instance
18:09:12  <indutny>2. Read() should fully read it
18:09:18  * piscisaureus_joined
18:09:20  <indutny>3. Write() could write any data now
18:09:23  <piscisaureus_>back
18:09:27  <indutny>4. Peek() will return 0
18:10:32  * defunctzombie_zzchanged nick to defunctzombie
18:11:44  <bnoordhuis>indutny: and we've never hit that so far? that sounds... unlikely
18:11:50  <indutny>no, not really
18:12:06  <indutny>I hit it only once in a voxer's version of stud
18:12:31  <bnoordhuis>hrm, weird
18:12:37  <bnoordhuis>but okay, let's fix it
18:15:12  <indutny>yeah
18:17:03  <indutny>but first
18:17:08  <indutny>I need to watch cartoons
18:20:51  * kenperkinsquit (Quit: Computer has gone to sleep.)
18:20:59  * AvianFlujoined
18:21:33  <sblom>piscisaureus_: Jonathan and I are in the same room now. He's working on incorporating the feedback on his pull request from last week.
18:21:53  <piscisaureus_>sblom: cool. Is he swearing and shouting already?
18:22:07  <sblom>piscisaureus_: Not too much. :)
18:22:21  <piscisaureus_>:D
18:22:53  <piscisaureus_>sblom: while you're at my disposal, can you fix office 2013 to be not sluggish?
18:23:39  <sblom>piscisaureus_: Man--I'd love to, but I don't think they'll accept my pull requests. :p
18:24:33  * indexzerojoined
18:25:38  <piscisaureus_>dang
18:26:06  * c4milojoined
18:30:02  * st_lukequit (Read error: Connection reset by peer)
18:30:30  * st_lukejoined
18:34:03  <sblom>piscisaureus_: I'm going to be busy for a while trying to debug across these two processes to figure out what's going on. I don't know if it's fair for me to keep you here much longer today. But I'll hopefully have 100 more questions tomorrow for you.
18:34:35  <piscisaureus_>sblom: alright. I'll be around (but maybe afk intermittently) for 1,5 more ours
18:34:37  <piscisaureus_>*hours
18:34:58  <piscisaureus_>sblom: so bug if I'm still there and, yes, poke my another way if not
18:35:01  <sblom>piscisaureus_: cool--I'll hurry. :P
18:35:10  <sblom>Okay--appreciate it very much.
18:37:44  * AvianFlu_joined
18:40:30  * pachetjoined
18:41:15  * AvianFluquit (Ping timeout: 245 seconds)
18:43:52  * julianduquejoined
18:46:35  <MI6>nodejs-master-windows: #220 UNSTABLE windows-x64 (19/622) windows-ia32 (18/622) http://jenkins.nodejs.org/job/nodejs-master-windows/220/
18:50:43  <piscisaureus_>bnoordhuis: on unix, does libuv implicitly stop readon upon EOF ?
18:54:09  * M28quit (Ping timeout: 264 seconds)
18:55:19  <bnoordhuis>ERROR: Error cloning remote repo 'origin' : Could not clone https://github.com/joyent/node.git
18:55:22  <bnoordhuis>hudson.plugins.git.GitException: Could not clone https://github.com/joyent/node.git
18:55:25  <bnoordhuis>^ sigh
18:56:03  <bnoordhuis>piscisaureus_: it does in master
18:56:08  * M28joined
18:56:14  <piscisaureus_>bnoordhuis: cool!
18:56:39  <bnoordhuis>in v0.10 too, it seems - guess i back-ported that
18:56:40  <piscisaureus_>bnoordhuis: on any error or just EOF
18:57:26  * st_lukequit (Read error: Connection reset by peer)
18:57:27  <bnoordhuis>piscisaureus_: no, only on EOF. with other errors, the user should just always close the handle
18:57:30  * st_luke_joined
18:58:00  <piscisaureus_>bnoordhuis: I'd like it to implicitly stop reading there too, but that's for another day :)
18:58:00  <bnoordhuis>or call uv_read_stop()
18:58:11  <piscisaureus_>bnoordhuis: ok - so if uv_read_stop is okay then I'll go with that.
18:58:24  <bnoordhuis>uv-unix enforces that you stop the handle on error, it asserts when you don't
18:59:33  <MI6>joyent/node: Ben Noordhuis master * 0aa1335 : timers: dispatch ontimeout callback by array index (+1 more commits) - http://git.io/f4ah6A
19:03:20  <bnoordhuis>piscisaureus_: check your email (and reply)
19:03:32  <piscisaureus_>bnoordhuis: tomorrow
19:03:52  <piscisaureus_>manjana manjana
19:04:01  <bnoordhuis>the right reply is 'you're 100% correct and full of awesome' btw
19:04:14  <bnoordhuis>'i want to have your babies' is acceptable too
19:04:43  <piscisaureus_>bnoordhuis: I'm not sure but I guess jeugdzorg wants your babies
19:04:55  <piscisaureus_>where I meant:
19:05:07  <piscisaureus_>I'm not sure about myself but etc.
19:08:05  * mcavagequit (Remote host closed the connection)
19:08:34  <MI6>nodejs-master: #424 UNSTABLE osx-ia32 (2/622) smartos-ia32 (5/622) linux-ia32 (2/622) smartos-x64 (11/622) linux-x64 (3/622) osx-x64 (2/622) http://jenkins.nodejs.org/job/nodejs-master/424/
19:18:55  <MI6>nodejs-master-windows: #221 UNSTABLE windows-x64 (20/622) windows-ia32 (20/622) http://jenkins.nodejs.org/job/nodejs-master-windows/221/
19:19:08  <isaacs>ok, got http outgoing messages to behave like a proper Writable stream, with callbacks, a proper 'finish' event, and correct behavior for base64 and hex encodings.
19:19:16  <trevnorris>bnoordhuis: sup, and yes
19:19:21  <isaacs>and afaict, still the only perf impact is noise
19:19:42  <isaacs>(running a NODE_BENCH_RUNS=10 benchmark just to be sure)
19:21:33  <trevnorris>isaacs: how's it be?
19:21:52  <isaacs>trevnorris: pretty good
19:22:01  <trevnorris>needed me for something?
19:22:02  <isaacs>trevnorris: i'd pinged you about some performance questino, but i figured it out.
19:22:08  <trevnorris>ah, cool
19:22:26  <isaacs>trevnorris: there's a really weird optimization in http.OutgoingMessage that i wanted to knwo if you understood, but it's pretty clearly just an old bug.
19:25:55  * hzquit
19:28:11  * c4miloquit (Remote host closed the connection)
19:30:20  <trevnorris>anyone know why test/message/timeout_throw.js might be failing?
19:31:54  <roxlu>hi guys, someone -maybe- knows a fast hex to decimal conversion? (esp. hex to uint16_t)
19:36:41  * c4milojoined
19:37:11  <isaacs>roxlu: in javascript? var int = parseInt(hexStr, 16)
19:37:20  <roxlu>oh sorry in C/C++
19:37:28  <roxlu>(I know .. a bit off topic)
19:38:50  * mralephjoined
19:40:34  <bnoordhuis>roxlu: grep for hex2bin in src/string_bytes.cc
19:41:20  <bnoordhuis>it's not ultra-fast (three branches) but it should be fast enough for most everything
19:41:59  <trevnorris>bnoordhuis: why the worry about public smalloc?
19:42:18  <bnoordhuis>roxlu: i actually did some benchmarking to see what's faster, comparisons or a lookup in a table
19:43:03  <bnoordhuis>the answer is 'it depends' - mostly on the type of cpu
19:43:07  <roxlu>ok
19:43:16  <roxlu>I need to process quite some data, using std::stringstream now
19:43:20  <roxlu>which is incredibly slow
19:43:29  <bnoordhuis>trevnorris: i wasn't worrying, just wondering if i can change the prototypes without fuss
19:43:54  <bnoordhuis>roxlu: i'm pretty sure hex2bin will outperform std::stringstream by a wide margin :)
19:44:06  <trevnorris>bnoordhuis: well, it's still marked experimental, and hasn't even been in a stable release yet, so I wouldn't worry about it.
19:44:10  <roxlu>awesome!
19:44:18  <roxlu>but it only works on single chars?
19:45:48  <bnoordhuis>roxlu: yeah, just iterate over the string to decode it in full
19:46:01  <bnoordhuis>see string_bytes.cc for an example
19:46:24  <bnoordhuis>trevnorris: nah, i want to add versions that take an Environment* as their first arg
19:46:32  <bnoordhuis>but that class definitely needs to stay internal
19:47:06  <bnoordhuis>don't worry about it, i'll figure something out
19:47:08  <trevnorris>ah, I see. well, do as v8 and add an smalloc::internall:: ;)
19:47:16  <bnoordhuis>yeah, something like that :)
19:54:55  <piscisaureus_>ok this is the time I check out
19:54:59  <piscisaureus_>\o
19:55:19  <piscisaureus_>good luck sblom, keep up the good work.
19:55:30  <piscisaureus_>and give dear john a hug
19:55:38  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
19:55:39  <MI6>joyent/libuv: Ben Noordhuis master * 5ff6f85 : darwin: call pthread_setname_np() if available - http://git.io/IdrWkw
19:59:40  <trevnorris>bnoordhuis: any opposition? https://github.com/trevnorris/node/compare/remove-unused-nt-vars
20:00:28  <bnoordhuis>trevnorris: does that mean the infoBox thingy is completely gone?
20:00:47  <bnoordhuis>ah no
20:00:59  <MI6>libuv-master: #165 UNSTABLE windows (3/193) smartos (9/192) http://jenkins.nodejs.org/job/libuv-master/165/
20:01:02  <bnoordhuis>no, no opposition
20:01:08  <trevnorris>cool, thanks
20:01:26  * pachetquit (Quit: leaving)
20:01:58  <MI6>libuv-master-gyp: #104 UNSTABLE windows-x64 (3/193) windows-ia32 (4/193) smartos-x64 (2/192) smartos-ia32 (2/192) http://jenkins.nodejs.org/job/libuv-master-gyp/104/
20:02:44  <MI6>joyent/node: Trevor Norris master * ab5dabf : node: remove duplicate infoBox checks - http://git.io/cet0mQ
20:04:36  * mcavagejoined
20:07:10  * dominictarrquit (Ping timeout: 240 seconds)
20:07:32  * dominictarrjoined
20:08:06  * bnoordhuisgoes fix some merge conflicts
20:08:49  <bnoordhuis>hrm, some are caused by my own patches to master
20:09:29  <trevnorris>heh
20:13:35  <MI6>nodejs-master: #425 UNSTABLE osx-ia32 (2/622) smartos-ia32 (3/622) linux-ia32 (3/622) smartos-x64 (10/622) linux-x64 (52/622) osx-x64 (52/622) http://jenkins.nodejs.org/job/nodejs-master/425/
20:17:34  * st_luke_quit (Read error: Connection reset by peer)
20:17:56  * st_lukejoined
20:19:32  <MI6>libuv-node-integration: #147 UNSTABLE smartos-ia32 (4/622) osx-ia32 (69/622) smartos-x64 (12/622) osx-x64 (2/622) linux-x64 (2/622) linux-ia32 (31/622) http://jenkins.nodejs.org/job/libuv-node-integration/147/
20:20:33  <trevnorris>bnoordhuis: no worries. i have several others just waiting for multi-context to land :)
20:21:38  <bnoordhuis>trevnorris: yeah, i'll try to get it in mergeable state soon
20:21:56  <bnoordhuis>it's kind of a bummer i didn't really had time to work on it yesterday and the day before
20:22:21  <trevnorris>bnoordhuis: no worries. took me about an hour to wrap my head around, but now doesn't take much effort to convert small changes over.
20:22:27  <isaacs>trevnorris: in the meantime, care to review either of these? https://github.com/joyent/node/pulls/isaacs
20:22:38  <trevnorris>will do
20:22:44  <isaacs>thanks!
20:22:46  <MI6>joyent/node: Ben Noordhuis master * a1ea8a2 : test: update tests after internal api change - http://git.io/mxC_mQ
20:22:53  <MI6>nodejs-master-windows: #222 UNSTABLE windows-x64 (20/622) windows-ia32 (20/622) http://jenkins.nodejs.org/job/nodejs-master-windows/222/
20:28:01  * brsonquit (Ping timeout: 268 seconds)
20:29:03  * AvianFlu_quit (Remote host closed the connection)
20:29:32  * AvianFlujoined
20:31:43  <MI6>nodejs-master: #426 UNSTABLE osx-ia32 (1/622) smartos-ia32 (3/622) linux-ia32 (1/622) smartos-x64 (11/622) linux-x64 (1/622) osx-x64 (1/622) http://jenkins.nodejs.org/job/nodejs-master/426/
20:32:51  * st_lukequit (Ping timeout: 240 seconds)
20:33:52  * brsonjoined
20:36:37  <trevnorris>isaacs: done and done
20:36:40  <trevnorris>do have to say, all these optimizations recently are really going to give me a lot to talk about at nodeconf.eu
20:37:26  <isaacs>trevnorris: that's rad. people eat that shit up.
20:37:40  <trevnorris>bnoordhuis: want to make sure i'm not replicating work. the object in the nextTickQueue would be more easily accessible from c++ if the domain field was also an index.
20:38:19  <trevnorris>isaacs: looking forward to it. just hoping my brain isn't fried from all the awesomeness by the time I talk
20:39:49  <bnoordhuis>trevnorris: go for it
20:46:03  <MI6>nodejs-master-windows: #223 UNSTABLE windows-x64 (18/622) windows-ia32 (20/622) http://jenkins.nodejs.org/job/nodejs-master-windows/223/
20:47:11  * st_lukejoined
20:52:49  <isaacs>trevnorris: to answer your question, the test uses setTimeout instead of setImmediate because of timing
20:52:58  <isaacs>trevnorris: setImmediate is too fast
20:53:22  <isaacs>trevnorris: i added 100ms timeout on it, just to avdoid the failures you still sometimes get with setTimeout
20:53:35  <trevnorris>isaacs: interesting.
20:53:48  <isaacs>yeah, i don't remember why that was
20:53:58  <isaacs>localhost is nearly-immediate, but not quite
20:55:12  <MI6>joyent/node: isaacs master * 1eedbdc : doc: http keepalive, agent options (+1 more commits) - http://git.io/CyBeVw
21:09:00  <MI6>nodejs-master: #427 UNSTABLE osx-ia32 (5/623) smartos-ia32 (4/623) linux-ia32 (2/623) smartos-x64 (9/623) linux-x64 (2/623) osx-x64 (2/623) http://jenkins.nodejs.org/job/nodejs-master/427/
21:10:12  <Raynos>Is it possible to peek at HTTP headers on a TCP handle without consuming bytes? I want to do something like cluster but load balance based on headers (sticky)
21:15:00  <MI6>nodejs-master-windows: #224 UNSTABLE windows-x64 (20/623) windows-ia32 (20/623) http://jenkins.nodejs.org/job/nodejs-master-windows/224/
21:15:33  <trevnorris>um... somehow the file "\033\033\033q" got created in my repo root. strange.
21:16:24  * AvianFluquit (Remote host closed the connection)
21:19:06  * AvianFlujoined
21:21:11  <indutny>bnoordhuis: still there?
21:21:18  * indexzeroquit (Quit: indexzero)
21:22:04  <MI6>joyent/node: isaacs master * 7304a62 : doc: http rawHeaders/rawTrailers (+1 more commits) - http://git.io/UAQL4A
21:22:12  <isaacs>trevnorris: thank you kindly, sir
21:22:32  <bnoordhuis>indutny: partially
21:23:06  <indutny>finishing patch for crypto-bio
21:23:12  <indutny>sorry, was watching movies before it
21:23:25  <trevnorris>isaacs: not a problem
21:24:05  <trevnorris>strange, somewhere the "domain" attribute is being set on the object passed to MakeCallback that's not in req_wrap
21:24:08  <trevnorris>but I can't find it
21:31:34  <MI6>nodejs-master: #428 UNSTABLE osx-ia32 (2/624) smartos-ia32 (5/624) linux-ia32 (3/624) smartos-x64 (11/624) linux-x64 (3/624) osx-x64 (3/624) http://jenkins.nodejs.org/job/nodejs-master/428/
21:33:02  <indutny>bnoordhuis: https://github.com/joyent/node/pull/6061
21:33:10  <indutny>bnoordhuis: please take a look if you'll have a minute
21:35:31  <isaacs>trevnorris: while you're on a roll: https://github.com/joyent/node/pull/6062
21:35:33  <isaacs>trevnorris: :D
21:35:42  * amartensquit (Quit: Leaving.)
21:35:49  <isaacs>i'm going to back-port 6d3d60a
21:35:51  <isaacs>to v0.10
21:35:55  <isaacs>so there'll be another one of those coming soon
21:38:06  * mraleph1joined
21:38:52  * mralephquit (Read error: Connection reset by peer)
21:39:03  <indutny>isaacs: what's 6d3d60a ?
21:39:14  <indutny>hm...
21:39:18  <indutny>somehow I don't have it in my tree
21:39:22  <indutny>what's up with you, git
21:42:08  <MI6>nodejs-master-windows: #225 UNSTABLE windows-x64 (23/624) windows-ia32 (22/624) http://jenkins.nodejs.org/job/nodejs-master-windows/225/
21:44:28  <bnoordhuis>indutny: i'll look at it tomorrow
21:46:54  <trevnorris>isaacs: done
21:47:18  <isaacs>trevnorris: thanks
21:47:30  <isaacs>trevnorris: yeah, so, i can avoid the Buffer.byteLength for everything except base64
21:47:36  <isaacs>since hex is always 1/2 length
21:47:42  <trevnorris>erm. and utf8
21:47:54  <isaacs>if it's utf8 in that case, it's already been handled.
21:47:58  <trevnorris>ah, great.
21:48:02  * groundwaterjoined
21:48:27  <isaacs>binary, base64, and hex, i guess.
21:48:56  <Raynos>indutny: ( https://github.com/indutny/sticky-session/issues/3 ) "that its possible" any suggestion on how to do this?
21:49:08  <trevnorris>binary's handled.
21:49:12  <isaacs>oh, wait, no
21:49:16  <isaacs>that's a different spot
21:49:18  <isaacs>yeah, it's utf8
21:49:22  <trevnorris>ah, ok
21:49:42  <isaacs>trevnorris: i'd rather not unroll every possible encoding everywehre we need the length, though
21:49:45  <isaacs>that's hideous
21:50:11  <isaacs>trevnorris: what if Buffer.byteLength just did this, and only called into C++ for utf8 and base64?
21:50:18  <trevnorris>can do.
21:50:27  <trevnorris>want me to write that up real fast, or you want to take care of it?
21:50:34  <isaacs>if you wanna, go for it
21:50:43  <trevnorris>will do, have it done in a minute
21:50:46  <isaacs>i'll avoid the check at all in the cases where we know it's either hex or base64
21:51:33  * bnoordhuisquit (Ping timeout: 240 seconds)
21:51:34  <trevnorris>sounds good
21:52:54  <isaacs>trevnorris: oh... actually... if Buffer.byteLength has that optimziation that the JIT can chew on, what's the point?
21:53:21  <trevnorris>isaacs: true true. ok, don't worry about it for your patch and I'll do it in buffer.js
21:53:29  <isaacs>great!
21:53:58  <isaacs>trevnorris: i'll just s/ascii/binary/ then
21:54:19  * rendarquit (Quit: Leaving)
21:54:45  <trevnorris>sounds and looks good
21:56:13  <isaacs>trevnorris: pushed.
21:56:36  <trevnorris>awesome.
21:57:09  <isaacs>trevnorris: binary being faster than ascii, is that new in master, or applies to v0.10 as well?
21:57:58  <trevnorris>isaacs: just master. that's when we move to the OneByte api
21:58:06  <trevnorris>it's hideously slow in v0.10
21:58:07  <isaacs>oh, ok
21:58:12  <isaacs>that's what i thought.
21:58:31  <trevnorris>like, the upgrade to the OneByte api made binary encoding 2600% faster
21:58:33  <isaacs>it was kind of surprising to me that binary would be faster. i remember it being like, the reason we have buffers, because it's so terribly slow.
21:58:37  <isaacs>hahahha awesome
21:58:45  <isaacs>good thing we ddn't deprecate it, eh?
21:58:47  * jmar777quit (Remote host closed the connection)
21:58:51  <trevnorris>it happened when v8 decided to natively support latin1
21:58:55  <trevnorris>heh, yeah
21:59:02  <trevnorris>technically binary encoding is now latin1 encoding
21:59:05  <trevnorris>that's how v8 handles it
22:00:09  <isaacs>oh, right, becasue we used to have to have a 2-byte string and throw away every other byte.
22:00:16  <trevnorris>yup
22:00:24  <isaacs>oh, god, 0.10 is so old.
22:00:28  <isaacs>it's painful to use now.
22:00:30  <isaacs>i'm so over it.
22:00:38  <isaacs>http all in one file?? srsly?
22:00:42  <isaacs>who thought THAT was a good idea?
22:00:43  <isaacs>;)
22:00:44  <trevnorris>haha
22:01:02  <isaacs>i'm so used to the new organization, i can't even barely remember how i used to debug it.
22:01:38  <trevnorris>no kidding. tried to help someone with the native Buffer api. took me a few minutes.
22:02:37  <trevnorris>isaacs: the best part, with external strings that gives us the ability to create mutable binary strings. sure that has some use somewhere :P
22:03:01  <isaacs>yeah, i want to explore that a lot more post-v0.12
22:03:25  <isaacs>forget buffers, man
22:03:29  <isaacs>binary strings. old school.
22:03:33  <isaacs>return to node 0.1 apis
22:03:33  <trevnorris>heh
22:03:37  <trevnorris>haha
22:04:08  <isaacs>trevnorris: so OutgoingMessage-refactor-part1 lgty?
22:04:14  <isaacs>trevnorris: backported for v0.10: https://github.com/joyent/node/pull/6064
22:04:55  <trevnorris>isaacs: yeah. lgtm
22:05:01  <isaacs>kewl, thanks
22:05:44  <trevnorris>not a problem.
22:05:50  <indutny>Raynos: handle._readStop, I guess
22:06:03  <indutny>Raynos: probably some easier way
22:06:16  <indutny>I don't really feel like I would like to investigate it that much :D
22:06:17  <indutny>sorry
22:06:26  <trevnorris>isaacs: i've been able to make the domain module not dependent on core internals w/ the new api. as soon as the multi-context stuff is merged i'll throw up the pr
22:06:42  <isaacs>trevnorris: i'm super psyched for that.
22:06:49  <isaacs>trevnorris: i know othiym23 will probably dig it as well.
22:07:04  <trevnorris>isaacs: yeah, me too. but probably for different reasons ;)
22:07:36  * bnoordhuisjoined
22:08:34  * dominictarrquit (Quit: dominictarr)
22:10:10  <MI6>joyent/node: isaacs master * 1f9f863 : http: Prefer 'binary' over 'ascii' (+5 more commits) - http://git.io/ZyF3Yg
22:11:05  <MI6>joyent/node: isaacs v0.10 * 255650f : http: Handle hex/base64 encodings properly - http://git.io/dZGU1w
22:11:09  <trevnorris>isaacs: awesome. looks good.
22:11:12  <isaacs>sweet. so now that works :)
22:11:45  <isaacs>i'm kinda tempted to just not care about the setHeaders/getHeaders outgoingmessage stuff.
22:11:54  <isaacs>i mean... it's not really hurting anyone right now, it's just ugly to read.
22:12:33  * dominictarrjoined
22:13:15  <trevnorris>well, that sounds more like code cleanup stuff for v0.13
22:14:17  <isaacs>yeah, sort of
22:14:21  <isaacs>but it does probably add/change api
22:14:38  <isaacs>ie, we might have outgoing.getHeader() or outgoing.addHeader()
22:15:01  <isaacs>also, i already wrote the code, but the patch was biting off way more than i could chew
22:18:40  <trevnorris>know how that goes.
22:22:09  * amartensjoined
22:25:23  <MI6>nodejs-v0.10: #1415 UNSTABLE smartos-x64 (1/595) http://jenkins.nodejs.org/job/nodejs-v0.10/1415/
22:25:36  <MI6>nodejs-master: #429 UNSTABLE osx-ia32 (3/627) smartos-ia32 (5/627) linux-ia32 (5/627) smartos-x64 (10/627) linux-x64 (4/627) osx-x64 (3/627) http://jenkins.nodejs.org/job/nodejs-master/429/
22:31:06  * c4miloquit (Remote host closed the connection)
22:32:52  <MI6>nodejs-v0.10-windows: #145 UNSTABLE windows-ia32 (7/595) windows-x64 (10/595) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/145/
22:34:34  <trevnorris>suck.
22:34:37  * wolfeidaujoined
22:35:04  <trevnorris>oh well, pipe dream.
22:35:12  <trevnorris>can't touch EventEmitter anymore...
22:37:43  <MI6>nodejs-master-windows: #226 UNSTABLE windows-x64 (22/627) windows-ia32 (24/627) http://jenkins.nodejs.org/job/nodejs-master-windows/226/
22:40:54  * AvianFluquit (Remote host closed the connection)
22:44:53  * amartensquit (Quit: Leaving.)
22:50:27  <isaacs>trevnorris: oh?
22:51:22  <trevnorris>isaacs: wanted to switch the nextTick object to indexed, since it's a lot faster to access from c++, but timers pass the event emitter as the object to ReqWrap, which has it pre-set on .domain
22:51:52  <trevnorris>forgot that the event emitter directly attaches the domain object to the instance.
22:52:03  <isaacs>right
22:54:11  <isaacs>trevnorris: so... you'd have to have EventEmitter do this[0] = domain or something?
22:54:19  <isaacs>trevnorris: that sounds weird.
22:54:32  <trevnorris>isaacs: basically yeah. more like this[kDomain] = domain;
22:54:43  <isaacs>sure
22:54:58  <trevnorris>realize it looks strange, it's just heck a lot faster
22:55:07  <isaacs>trevnorris: yeah
22:55:15  <isaacs>trevnorris: you could still do that with timers and ticks, though
22:55:22  <isaacs>trevnorris: just have to checkboth, i guess
22:55:49  <trevnorris>hm. I could replicate the .domain property to [0]. not very pretty, but would get the job done.
22:56:05  <isaacs>we can't do that with EventEmitters, though
22:56:11  <trevnorris>eh, not sure how I feel about that. going to sleep on it and try to come up with something better.
22:56:14  <isaacs>yeah
22:56:16  <trevnorris>understood
22:56:44  <isaacs>speaking of sleep,i got up too early this morning, and i'm out of steam, i think. it's scotch o'clock
22:57:06  <trevnorris>sounds good. enjoy yourself.
22:57:50  <othiym23>I do dig that!
22:59:43  * hueniversequit (Ping timeout: 268 seconds)
22:59:51  * hueniversejoined
23:01:20  * c4milojoined
23:03:55  * julianduquequit (Ping timeout: 240 seconds)
23:07:24  * julianduquejoined
23:07:39  * amartensjoined
23:18:00  <trevnorris>isaacs: 65f6f06 is causing test-http-client-agent to fail, investigating now
23:20:07  <kellabyte>bnoordhuis: what would cause uv_rwlock_wrlock() to hang on the first call? I called uv_rwlock_init() first to init it
23:25:17  * kenperkinsjoined
23:27:15  * kenperkinsquit (Client Quit)
23:28:24  * dominictarrquit (Quit: dominictarr)
23:30:54  * EhevuTovjoined
23:32:11  <TooTallNate>tjfontaine: trevnorris so what's the status on the "blessed" native abstraction layeR?
23:32:20  <TooTallNate>i've been getting lots of bug reports asking me to use "nan"
23:32:58  <trevnorris>... I have nothing to do w/ that, and i'd so some benchmarking if you decide to use nan
23:36:12  <trevnorris>TooTallNate: also, I think isaacs said that if we do decide to integrate a "blessed" native abstraction it won't have backwards compatibility.
23:36:23  <trevnorris>so you'd have to use tjfontaine's userland module
23:38:22  * kazuponjoined
23:38:41  * AvianFlujoined
23:41:18  <bnoordhuis>kellabyte: i don't know
23:43:52  <mordy__>hrm; i'm forgetting now -- does node spawn any threads? (unix) -- or is that a sign of something "special" being done
23:44:14  <bnoordhuis>mordy__: it has a thread pool for fs operations and stuff like that
23:44:55  <trevnorris>bnoordhuis: oh, fwiw i'm meeting up with some guys I know at Oracle on Tues to talk about them using libuv in their latest project.
23:45:24  <bnoordhuis>trevnorris: not node.jar per chance?
23:45:59  <trevnorris>bnoordhuis: nope. they're working on Oracle's latest product (his business was acquired for it) and the entire thing is in C.
23:46:44  <kellabyte>bnoordhuis: the write lock call is on another thread than the init, does that matter?
23:47:02  <bnoordhuis>trevnorris: okay, interesting. what kind of product is it?
23:47:17  <bnoordhuis>kellabyte: depends. did you start the thread before or after intializing the lock?
23:47:23  <bnoordhuis>*initializing
23:48:19  <trevnorris>bnoordhuis: it's an in memory distributed sql database, iirc
23:49:14  <kellabyte>bnoordhuis: before, the other threads aren't started yet
23:50:28  <bnoordhuis>kellabyte: are you locking the rwlock on one thread, then unlocking it from another?
23:51:12  <bnoordhuis>trevnorris: interesting. let me know how it works out for them
23:51:36  <kellabyte>bnoordhuis: naa, I'm not even getting to the unlock part, the writer lock hangs
23:52:37  <bnoordhuis>kellabyte: i guess some example code is in order because i have no idea
23:53:36  <trevnorris>bnoordhuis: will do. pretty sure I won't be able to answer their very technical questions. from what he's explained to me, it's pretty intense. but hey, major oracle product using libuv sounds cool. :)
23:54:02  <kellabyte>bnoordhuis: https://github.com/kellabyte/Haywire/blob/master/src/haywire/http_response_cache.c#L82 if I uncomment that it hangs on that line
23:55:26  <bnoordhuis>kellabyte: apropos nothing, void initialize_http_request_cache() is a minor faux pas in c
23:55:44  <bnoordhuis>at least, i assume your intention is to declare a function that takes no arguments
23:56:00  <bnoordhuis>but what you're actually declaring is a function that takes any number of arguments, including none
23:56:55  <bnoordhuis>back on topic, i don't see anything obviously wrong with how you use the lock
23:57:26  <bnoordhuis>has something called uv_rwlock_rdlock() yet?
23:57:52  <trevnorris>bnoordhuis: heh, keep forgetting to have you look over my moch node.c api. tomorrow then! :)
23:58:16  <kellabyte>bnoordhuis: ah yes
23:58:29  <kellabyte>bnoordhuis: which then calls the method doing the writer lock lol
23:58:52  <MI6>libuv-master-gyp: #105 UNSTABLE windows-x64 (4/193) windows-ia32 (3/193) smartos-x64 (2/192) smartos-ia32 (2/192) linux-x64 (1/192) http://jenkins.nodejs.org/job/libuv-master-gyp/105/
23:59:18  <bnoordhuis>hah
23:59:19  <kellabyte>bnoordhuis: thats what it was, thanks for the code review! lol
23:59:25  <bnoordhuis>no problem :)
23:59:56  * AvianFluquit (Remote host closed the connection)