00:00:00  * ircretaryquit (Remote host closed the connection)
00:00:08  * ircretaryjoined
00:03:58  * paulfryzelquit (Ping timeout: 256 seconds)
00:13:36  * bnoordhuisquit (Ping timeout: 256 seconds)
00:23:36  * groundwaterquit (Quit: groundwater)
00:34:39  * amartensquit (Quit: Leaving.)
00:37:05  <mordy___>hrm; is there some kind of estimate to determine how much memory it *should* be using?
00:37:33  <mordy___>i just want to rule out anything that's causing issues.. recompiling everything so i can use VS' malloc doesn't seem like a nice option
00:37:44  <mordy___>there's something called 'drmemory' but node won't run nicely under it
00:39:15  <mordy___>now it seems to be jumping from 37M -> 47M; and apparently something is freed when it reaches 47M and goes back to 37
00:57:51  * hueniverse1joined
00:57:51  * hueniversequit (Ping timeout: 264 seconds)
01:00:58  * kazuponjoined
01:02:30  * dapquit (Quit: Leaving.)
01:09:30  * indexzerojoined
01:19:23  * bnoordhuisjoined
01:25:45  * bnoordhuisquit (Ping timeout: 256 seconds)
02:03:41  * indexzeroquit (Quit: indexzero)
02:11:15  * brsonquit (Ping timeout: 245 seconds)
03:04:42  * defunctzombiechanged nick to defunctzombie_zz
03:08:37  * indexzerojoined
03:37:07  * stagasquit (Ping timeout: 246 seconds)
03:58:40  * c4miloquit (Remote host closed the connection)
04:24:51  * kazuponquit (Remote host closed the connection)
04:29:57  * st_lukejoined
04:40:12  * st_lukequit (Remote host closed the connection)
04:53:19  * defunctzombie_zzchanged nick to defunctzombie
04:54:29  * kazuponjoined
05:11:05  * txdvquit (Read error: Operation timed out)
05:14:09  * indexzeroquit (Quit: indexzero)
05:16:15  * Guest85773quit (Ping timeout: 245 seconds)
05:21:48  * Damn3djoined
05:52:53  * amartensjoined
05:58:35  * AvianFlujoined
05:59:09  * amartensquit (Quit: Leaving.)
06:05:19  * amartensjoined
06:06:23  * amartensquit (Client Quit)
06:16:25  * amartensjoined
06:16:34  * amartensquit (Client Quit)
06:25:46  * felixgejoined
06:25:46  * felixgequit (Changing host)
06:25:46  * felixgejoined
06:28:41  * AvianFluquit (Remote host closed the connection)
06:37:56  * defunctzombiechanged nick to defunctzombie_zz
07:16:43  * spolujoined
07:25:54  * hueniverse1quit (Read error: Connection reset by peer)
07:32:30  * hueniversejoined
07:34:00  * bajtosjoined
07:35:22  * hzjoined
07:56:23  * dsantiagoquit (Ping timeout: 240 seconds)
08:00:05  * hzquit (Ping timeout: 268 seconds)
08:00:13  * rendarjoined
08:03:36  * defunctzombie_zzchanged nick to defunctzombie
08:23:46  * `3E|Zzzchanged nick to `3rdEden
08:26:20  * saghul[afk]changed nick to saghul
08:35:25  * dsantiagojoined
08:35:28  * piscisaureus_joined
08:43:22  * piscisaureus_quit (Ping timeout: 246 seconds)
08:52:28  * Damn3dquit (Ping timeout: 246 seconds)
08:53:59  * Damn3djoined
08:56:33  * stagasjoined
09:02:24  * perezdquit (Quit: perezd)
09:15:19  * defunctzombiechanged nick to defunctzombie_zz
09:23:29  * kazuponquit (Remote host closed the connection)
09:27:04  * piscisaureus_joined
09:30:56  * mralephquit (Read error: Connection reset by peer)
09:31:28  <rendar>i'm studying libuv code, and on the linux's epoll dispatch function, i'm stuck on w->cb(loop, w, pe->events); what that 'cb' points to?
09:32:03  * defunctzombie_zzchanged nick to defunctzombie
09:33:16  * defunctzombiechanged nick to defunctzombie_zz
09:39:58  * dominictarrjoined
09:47:26  * bnoordhuisjoined
09:50:53  <rendar>i'm studying libuv code, and on the linux's epoll dispatch function, i'm stuck on w->cb(loop, w, pe->events); what that 'cb' points to? i know that 'w' is a uv__io_t, but where 'cb' points to there?
09:51:45  * wolfeidaujoined
09:57:49  <bnoordhuis>rendar: an internal libuv callback
09:58:04  <bnoordhuis>rendar: usually uv__stream_io or uv__server_io
09:59:05  <rendar>bnoordhuis, thanks, where are those defined? basically i want to understand how libuv can abstract epoll/kqueue/etc to iocp, since their design is completely different...
09:59:30  <bnoordhuis>rendar: the two i mentioned live in src/unix/stream.c
09:59:44  <rendar>thanks
09:59:48  <bnoordhuis>there's also uv__udp_something in src/unix/udp.c
10:00:06  <bnoordhuis>basically, grep for calls to uv__io_init and you'll find the callbacks
10:01:49  <rendar>bnoordhuis, cool! what i can't understand is how some facility which tells you that an fd is *ready* to be written or read, can be abstracted with iocp which tells you that the reading/writing are completed, within the buffer pointer and n bytes... i guess you have to save those 2 values somewhere...
10:03:18  <bnoordhuis>rendar: i'm not sure i understand i question. are you asking how uv-unix simulates completion-based i/o?
10:03:42  <rendar>yes exactly
10:04:05  <rendar>just some hint to understand the "big picture"
10:04:29  <bnoordhuis>rendar: right. it's easy really
10:04:44  <bnoordhuis>i/o on unices is readiness based
10:04:56  <rendar>yep
10:04:57  <bnoordhuis>libuv just has to execute the reads and writes on your behalf
10:05:07  <bnoordhuis>and when it's done reading/writing, ping you
10:05:13  <bnoordhuis>et voila, you have completion-based i/o :)
10:05:31  <rendar>hmmm, yeah pretty simple :)
10:07:17  <rendar>bnoordhuis, so when i perform a read, libuv saves that i have performed that read on buffer 'buf' and 'n' bytes. instead of calling *mimmediately* unix's read() it waits until it receives a you-can-read-now notify, then libuv calls unix's read() under the hood, and when its finished, it pings you, calling e.g. on_read(buf, n)
10:10:43  * bajtosquit (Quit: bajtos)
10:14:41  <bnoordhuis>rendar: that's pretty much how it works
10:15:00  <bnoordhuis>uv_read_start() tells libuv to start waiting for read readiness
10:15:33  <bnoordhuis>once that happens it calls your alloc_cb to get a buffer to read into, then it does the actual read, then it calls your read_cb
10:16:01  <bnoordhuis>the order on windows is a little different: you provide the buffer up front (usually) and then wait until data's received
10:16:44  <bnoordhuis>uv-unix doesn't emulate that particular windows behavior because it means you'll generally have a higher memory footprint
10:18:15  <piscisaureus_>hey bnoordhuis
10:19:13  <piscisaureus_>is it true that the slab allocator is now ripped out?
10:19:53  <piscisaureus_>ab w/ keepalive got 20% slower (again!) between 0.10 and master
10:20:24  <bnoordhuis>piscisaureus_: yes and that shouldn't be the case
10:21:31  <bnoordhuis>did you check what in particular got slower?
10:21:40  <bnoordhuis>i.e. ran any profiling?
10:22:19  <piscisaureus_>no i just ran into it
10:22:31  <piscisaureus_>I will plan doing that but first I have to finish execSync :)
10:24:09  * spoluquit (Ping timeout: 264 seconds)
10:28:46  <rendar>i see
10:30:50  <rendar>bnoordhuis, so if i got it, in unix on_read will receive the buffer allocated with alloc_cb? and not the buffer passed by the user?
10:40:23  <bnoordhuis>rendar: read_cb gets the buffer that alloc_cb returned
10:40:40  <bnoordhuis>where else would it get the buffer from? :)
10:41:54  <rendar>well, if you have e.g. ssize_t uv_read(uv_tcp_t*, uv_buf_t* buf); the user himself can pass a buffer that will be used for reading, right?
10:44:12  * kazuponjoined
10:44:37  <bnoordhuis>rendar: yes. but there is no uv_read()
10:45:47  * hzjoined
10:46:19  <rendar>oh
10:46:24  <rendar>so there is for example uv_fs_read()
10:46:27  <rendar>and so on..
10:48:16  <bnoordhuis>yeah, but the fs part should be a strong hint as to what it does :)
10:49:30  <rendar>yeah
10:49:48  <rendar>instead with networking we have read_start_* and read_stop_*, right?
10:50:08  <bnoordhuis>yep
10:50:12  <rendar>read_start_ allocate the buffer with alloc_cb, and read_stop_ will deallocate it
10:50:17  <bnoordhuis>no
10:50:33  <bnoordhuis>uv_read_start() just tells libuv to start watching for read readiness
10:50:50  <bnoordhuis>when the socket is readable, it does the alloc_cb/read_cb dance
10:50:59  <rendar>oh
10:51:02  <bnoordhuis>it's up to the read_cb to free the buffer again, if necessary
10:51:22  <bnoordhuis>uv_read_stop() is just the counterpart of uv_read_start()
10:51:46  <rendar>this will be a less memory footprint because the buffer is allocated only when is needed, instead that each open connection has a buffer
10:52:26  <bnoordhuis>yes, correct
10:53:03  <rendar>but what about a connection does high and frequent reads? in that case you'll have many allocations/deallocations?
10:53:37  <indutny>piscisaureus_: hoya
10:53:47  <indutny>piscisaureus_: I'm trying to reproduce this fs.watch issue on mac
10:53:48  <bnoordhuis>rendar: yes. that's why node uses (or used to use) a slab allocator
10:53:56  <indutny>bnoordhuis: hi
10:53:56  <rendar>bnoordhuis, i see now
10:54:04  <indutny>piscisaureus_: having a bit of trouble with this, though
10:54:19  <indutny>https://gist.github.com/indutny/2ccdd6cee4b97ddbefbb
10:54:29  <indutny>it seems to be generally working on master
10:54:45  <rendar>bnoordhuis, i see
10:54:51  <indutny>and 0.10.13
10:55:11  <bnoordhuis>"Also bringing up these topics in unrelated conversations is kind of annoying and people should refrain from that. Hello MichaĆ«l Rouges, we can all read the topic index ourselves, thanks."
10:55:15  <bnoordhuis>oh snap!
10:55:50  <rendar>bnoordhuis, well, doesn't the slab allocator generate some bottleneck since (i guess) it must be export an *interlocked* allocation, in order to work with multiple threads?
10:56:22  <bnoordhuis>rendar: not an issue for node, it's single-threaded
10:56:34  <rendar>oh, ok
10:57:21  * piscisaureus_quit (Ping timeout: 276 seconds)
10:58:58  <indutny>bnoordhuis: is bert anywhere around you?
10:58:59  <indutny>:)
10:59:21  <bnoordhuis>indutny: no, he's in 020
10:59:21  <rendar>bnoordhuis, isn't this thing of slab allocator and on-readyness allocated buffers similar to that libevent2's buffered abstraction?
10:59:32  <indutny>http://en.wikipedia.org/wiki/020 ?
10:59:34  <indutny>london?
10:59:41  <bnoordhuis>indutny: no, amsterdam :)
10:59:46  <indutny>oh
10:59:46  <indutny>ok
10:59:47  <indutny>;)
10:59:53  <bnoordhuis>rendar: possibly. i don't know libevent2 that well
10:59:57  <rendar>ok
11:00:06  <bnoordhuis>worked with the original libevent for quite some time
11:00:15  <bnoordhuis>and that kind of turned me off
11:00:58  <rendar>bnoordhuis, eheh i see, why?
11:01:27  <bnoordhuis>rendar: oh, mostly because everything takes just a little too much effort
11:01:35  <bnoordhuis>and libevent sits at just the wrong level of abstraction
11:01:49  <rendar>i definitely think so
11:02:09  <rendar>i saw some libevent's apis and examples time ago, they where just very difficult to use
11:03:48  <rendar>bnoordhuis, i think libev is far better than libevent, unfortunately it doesn't support win nt
11:04:09  * hzquit (Remote host closed the connection)
11:04:34  <bnoordhuis>rendar: no, and it never will - well, not efficiently anyway
11:04:52  <bnoordhuis>it's very much built around the concept of readiness-bases i/o, not completion-based i/o
11:05:09  <bnoordhuis>also, and apropos nothing, its author is an annoying german
11:05:10  <rendar>mmm yeah
11:05:16  <rendar>lol
11:05:20  * hzjoined
11:08:17  * abraxasquit (Remote host closed the connection)
11:10:21  <rendar>bnoordhuis, how much is the memory footprint shrunk by this optimization of that buffer is allocated only when fd are ready to be read/write?
11:11:41  <bnoordhuis>rendar: ah, that's the kind of question to which there's no exact answer
11:11:54  <bnoordhuis>it's somewhere in the range of 'nothing' to 'a lot'
11:12:13  <rendar>yeah i guess so
11:13:39  <rendar>bnoordhuis, consider if we didn't have that..so the user passed its own buffer to uv_start_read()...so the {buf,size} passed by the user should have been saved somewhere, so when epoll_wait() returns, and there is a readyness for read, libuv could have used that {buf,size} to call unix's read() -- right?
11:14:36  <saghul>rendar FWIW,in pyuv I use a statically allocated buffer in alloc_cb, so it's up to read_cb to copy it
11:14:49  <bnoordhuis>rendar: sorry, have to run - back in ~1 hour
11:14:56  <rendar>bnoordhuis, ok
11:15:00  <rendar>saghul, hmmm i see
11:15:45  <rendar>saghul, but i was wondering if libuv had these static buffer, then its design could have be different
11:16:17  <saghul>rendar the way it is, it allows you to choose how to do it, doesn't it?
11:16:48  * piscisaureus_joined
11:17:23  <rendar>saghul, not really because you still have to call alloc_cb, and you still have uv_start_read()..instead i was wondering about specifying user's {buf,size} and save them internally
11:18:05  <saghul>ah, and reuse the buffer every time?
11:19:07  * bnoordhuisquit (Ping timeout: 246 seconds)
11:19:26  <saghul>rendar I think you can achieve that by returning the same thing in alloc_cb all the time, you have the extra callback function though
11:20:26  <rendar>yeah
11:26:50  * hzquit (Remote host closed the connection)
11:27:44  * hzjoined
11:37:17  <piscisaureus_>13:37 guys
11:44:06  <indutny>piscisaureus_: hoya
11:44:19  <piscisaureus_>hey fedor
11:44:22  <indutny>piscisaureus_: I think I know what's causing fs.watch problems that you observe
11:44:31  <piscisaureus_>indutny: what is it?
11:44:33  <indutny>that's my stupid thread-safety assumptions about FSEvents API
11:44:47  <piscisaureus_>is it fixable?
11:44:49  <indutny>I think the callback invokes after FSEventStreamStop
11:44:56  <indutny>piscisaureus_: yeah, I'll rewrite that piece of code :P
11:45:05  <indutny>to do all the stuff from CF thread
11:45:06  <piscisaureus_>I could tell that the arguments passed to the callback were garbage
11:45:15  <indutny>piscisaureus_: that's quite obvious
11:45:22  <indutny>piscisaureus_: from disassembly dump you gave me
11:45:28  <indutny>it seems that handle->realpath is NULL
11:45:49  <indutny>and the only condition when it could happen is after uv_close() of handle
11:53:07  <piscisaureus_>right
11:53:15  <piscisaureus_>well atleast I asked the right question then :-p
11:54:31  <indutny>haha
11:56:45  <piscisaureus_>why does uv_buf_init take a const char* ?
11:57:00  <piscisaureus_>oh nevermind it doesn't
11:57:05  <piscisaureus_>msvc is just confused
12:00:15  * hzquit (Ping timeout: 256 seconds)
12:09:42  * kazuponquit (Remote host closed the connection)
12:32:16  * rendarquit (Ping timeout: 276 seconds)
12:38:38  * spolujoined
12:46:42  * piscisaureus_quit (Ping timeout: 256 seconds)
13:10:41  * M28quit (Read error: Connection reset by peer)
13:11:41  * M28joined
13:20:11  * piscisaureus_joined
13:23:18  <indutny>piscisaureus_: bertje
13:23:29  <indutny>piscisaureus_: can you please try out a patch from https://github.com/joyent/libuv/pull/880
13:37:49  <piscisaureus_>indutny: fedorretje :)
13:38:12  <piscisaureus_>indutny: it was hard for me to reproduce, but the c9 folks could consistently
13:38:20  <piscisaureus_>indutny: iow, I'm going to delegate that
13:41:07  * mcavage_joined
13:41:08  * mcavagequit (Read error: Connection reset by peer)
13:43:36  * c4milojoined
13:44:52  <piscisaureus_>indutny: but it seems that I have to backport it first
13:45:36  <piscisaureus_>which I cant do right now because I'd have to run os x but I have a meeting in 10 minutes
13:45:39  <piscisaureus_>sorry
13:48:02  * rendarjoined
13:58:12  * pachetjoined
14:12:50  * bajtosjoined
14:23:21  * bnoordhuisjoined
14:40:49  * inolenquit (Read error: Connection reset by peer)
14:40:58  * inolenjoined
14:52:36  * bradleymeckjoined
14:53:04  <indutny>piscisaureus_: haha
14:53:09  <indutny>piscisaureus_: I can backport it for you
14:57:37  * pachetquit (Quit: leaving)
14:57:58  * pachetjoined
14:58:00  * kenperkins_changed nick to kenperkins
15:04:05  * paulfryzeljoined
15:05:09  * piscisaureus_quit (Read error: No route to host)
15:06:22  * piscisaureus_joined
15:08:32  * AvianFlujoined
15:12:17  <piscisaureus_>inolen: yeah, sorry, I removed the issue number since you already mentioned it too
15:12:22  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
15:12:42  * piscisaureus_joined
15:12:54  <piscisaureus_>indutny: ^-- sorry, that was for you obviously
15:12:58  * piscisaureus_quit (Client Quit)
15:13:38  * dapjoined
15:13:38  * kazuponjoined
15:15:21  * `3rdEdenchanged nick to `3E|SHOPPA
15:27:02  * groundwaterjoined
15:35:35  * piscisaureus_joined
15:38:33  <bnoordhuis>https://github.com/joyent/node/issues/6041#issuecomment-22644347 <- am i missing anything here? streams cannot be that broken in v0.10, can they?
15:44:20  * dominictarrquit (Quit: dominictarr)
15:45:45  * jmar777joined
15:46:17  <indutny>piscisaureus_: yt?
15:46:33  <piscisaureus_>indutny: in limited fashion. I'm in a "background meeting"
15:46:40  <indutny>oh god
15:46:45  <indutny>I'm not even going to ask what it is
15:46:46  <indutny>whatever
15:46:54  <indutny>I'm running tests on backported fix for fsevents
15:46:56  <piscisaureus_>I mean, I'm in a meeting but I can & quite easily
15:47:05  <piscisaureus_>kewl
15:47:06  <indutny>if it'll go fine - I'll send you a gist
15:47:24  <piscisaureus_>Naais
15:47:55  <indutny>piscisaureus_: https://gist.github.com/indutny/6232342
15:54:14  <bnoordhuis>ah... that file.pipe(response) thing is even being discussed on the mailing list
15:54:25  <bnoordhuis>so, apparently streams really is that broken?
15:54:55  * hzjoined
15:56:28  <indutny>bnoordhuis: does it surprise you?
15:58:19  <MI6>joyent/node: piscisaureus created branch fsevents-fix - http://git.io/U6kSvg
15:58:48  <piscisaureus_>that's why EEs are evil
15:58:52  <piscisaureus_>:)
15:59:40  <bnoordhuis>indutny: yes
15:59:47  <bnoordhuis>it wasn't broken in v0.8
16:00:00  <indutny>ah
16:00:01  <indutny>well
16:00:08  <rendar>EEs?
16:00:09  <indutny>that is old time
16:00:11  <indutny>good old time
16:00:17  <indutny>but it was a bit inconsistent
16:00:18  <bnoordhuis>when things just worked :-/
16:00:20  <indutny>and hacky
16:00:39  <bnoordhuis>i'm just wondering if this is a bug or a fundamental design flaw
16:00:52  <bnoordhuis>if it's the latter, i will cry tiny tears
16:01:20  * indexzerojoined
16:01:30  <bnoordhuis>rendar: EE = EventEmitter
16:01:52  <rendar>i see
16:07:18  * bajtosquit (Quit: bajtos)
16:09:00  <MI6>joyent/node: Ben Noordhuis master * 2669966 : http: speed up callbacks, use array indices (+1 more commits) - http://git.io/4OKjNg
16:09:17  * AvianFluquit (Remote host closed the connection)
16:10:04  * piscisaureus_quit (Ping timeout: 264 seconds)
16:15:10  * indexzeroquit (Quit: indexzero)
16:16:06  * inolenquit (Quit: Leaving.)
16:16:40  * perezdjoined
16:22:07  <isaacs>the last 10 tests are always the worst.
16:27:13  <tjfontaine>isaacs: the waiting is the hardest part?
16:27:42  <isaacs>tjfontaine: actually, i'm down to 7 now
16:27:51  <isaacs>our http test suite is really nice.
16:30:08  <isaacs>it *does* test a lot of internal garbage, which is kind of unfortunate.
16:32:09  <tjfontaine>indeed
16:34:45  * indexzerojoined
16:36:39  * indexzeroquit (Client Quit)
16:37:58  * bajtosjoined
16:38:12  <MI6>nodejs-v0.10: #1413 UNSTABLE smartos-ia32 (3/594) smartos-x64 (4/594) http://jenkins.nodejs.org/job/nodejs-v0.10/1413/
16:40:38  <MI6>nodejs-master: #420 UNSTABLE linux-x64 (5/622) linux-ia32 (5/622) smartos-ia32 (1/622) osx-ia32 (1/622) osx-x64 (1/622) smartos-x64 (9/622) http://jenkins.nodejs.org/job/nodejs-master/420/
16:40:40  <bradleymeck>bnoordhuis: "never trust a string" was a quote I heard yesterday
16:40:45  <bradleymeck>makes me think of EEs
16:41:08  <indutny>bnoordhuis: https://github.com/joyent/node/pull/6009
16:41:11  <indutny>bnoordhuis: please review
16:44:06  <MI6>nodejs-v0.10-windows: #143 UNSTABLE windows-x64 (8/594) windows-ia32 (11/594) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/143/
16:49:55  * M28_joined
16:49:55  * M28quit (Read error: Connection reset by peer)
16:50:44  <MI6>nodejs-master-windows: #216 UNSTABLE windows-x64 (20/622) windows-ia32 (19/622) http://jenkins.nodejs.org/job/nodejs-master-windows/216/
16:52:22  * hzquit (Disconnected by services)
16:52:24  * M28_quit (Read error: Connection reset by peer)
16:52:33  * hzjoined
16:52:51  * M28joined
16:55:21  * mikealjoined
17:07:17  * TooTallNatejoined
17:07:20  * c4miloquit (Remote host closed the connection)
17:07:30  * mcavage_quit (Remote host closed the connection)
17:08:39  * `3E|SHOPPAchanged nick to `3E
17:08:48  * amartensjoined
17:10:05  <bajtos>isaacs: are you around?
17:10:40  <MI6>joyent/node: Fedor Indutny master * c50750e : tls: handle errors on socket before releasing it - http://git.io/SOFNAg
17:15:31  * brsonjoined
17:17:28  <isaacs>bajtos: yo
17:17:39  <isaacs>[00:25|% 100|+ 134|- 0]: Done <-- http tests on new OutgoingMessage class.
17:17:44  * isaacs\o/
17:17:54  <isaacs>running all the other tests now to see what else I broke :)
17:18:18  <bajtos>isaacs: have you had a chance to look at that caching http client I am writing for multi-registry support in npm client?
17:18:31  <isaacs>bajtos: no, i hadn't had a chance to see it. got a link?
17:18:31  <bajtos>isaacs: https://github.com/strongloop/strong-caching-http-client/tree/impl
17:19:32  <bajtos>isaacs: I have the first version that should allow us to start working on other parts of the solution
17:19:46  <MI6>nodejs-master: #421 UNSTABLE linux-x64 (1/622) linux-ia32 (1/622) smartos-ia32 (3/622) osx-ia32 (2/622) osx-x64 (2/622) smartos-x64 (9/622) http://jenkins.nodejs.org/job/nodejs-master/421/
17:20:15  <bajtos>isaacs: I prefer to work vertically, i.e. implement the first round of changes in all modules involved, to make sure we are going in the right direction
17:20:30  <isaacs>bajtos: yeah, that's how i usually work, too
17:20:36  <bajtos>isaacs: and implement all edge cases, etc. as the second.
17:20:38  <isaacs>build the base, then build up in all directions kinda together
17:20:48  <isaacs>easier to keep all on the same track that way
17:20:49  <bajtos>isaacs: cool, it's good to be aligned on this
17:20:55  <isaacs>i'll review this today.
17:21:04  <bajtos>excellent, thanks
17:21:11  <isaacs>i've been working on the core http stuff for v0.12, so my brain is full of http knowledge right now :)
17:21:23  <isaacs>very much in that mode :)
17:21:29  * c4milojoined
17:21:52  <bajtos> isaacs: I see, sorry for interrupting you. I've created a pull request so that it's easier to track the discussion: https://github.com/strongloop/strong-caching-http-client/pull/1
17:24:09  * bradleymeckquit (Quit: bradleymeck)
17:24:33  <isaacs>bajtos: oh, no worries, this is the perfect time to review this :)
17:24:48  <isaacs>bajtos: all the edge cases are fresh in my mind righ tnow
17:26:23  * defunctzombie_zzchanged nick to defunctzombie
17:29:47  <MI6>nodejs-master-windows: #217 UNSTABLE windows-x64 (17/622) windows-ia32 (18/622) http://jenkins.nodejs.org/job/nodejs-master-windows/217/
17:34:30  * st_lukejoined
17:43:21  * brsonquit (Ping timeout: 264 seconds)
17:46:08  * brsonjoined
17:47:41  * bradleymeckjoined
17:52:36  * pachetquit (Quit: leaving)
17:54:02  <MI6>libuv-master: #163 UNSTABLE windows (3/193) smartos (9/192) http://jenkins.nodejs.org/job/libuv-master/163/
17:54:25  * brsonquit (Quit: leaving)
17:54:39  * brsonjoined
17:57:11  <isaacs>nice. so, the one failing test at this point is the simple/test-domain-multi, because OutgoingMessage no longer lets you accidentally write invalid chunks.
18:01:07  * dominictarrjoined
18:04:04  * mcavagejoined
18:06:25  <isaacs>so, the commits are a godawful mess, but if anyone wants to review the code, here it is: https://github.com/isaacs/node/compare/http-outgoing-refactor
18:07:10  <isaacs>tjfontaine, bnoordhuis ^
18:07:29  <MI6>libuv-node-integration: #145 UNSTABLE osx-x64 (1/622) linux-x64 (1/622) linux-ia32 (2/622) smartos-ia32 (3/622) smartos-x64 (9/622) osx-ia32 (1/622) http://jenkins.nodejs.org/job/libuv-node-integration/145/
18:09:30  * bradleymeckquit (Quit: bradleymeck)
18:10:06  <bnoordhuis>isaacs: maybe tomorrow, it's been a pretty long day for me already
18:10:56  * bradleymeckjoined
18:11:33  <isaacs>bnoordhuis: sure. i'll try to clean up the commit history this afternoon.
18:11:52  * hzquit (Disconnected by services)
18:11:56  <isaacs>bnoordhuis: the code is just kind of disorganized and terrible, so it's a bear of a patch no matter how you slice it.
18:12:05  * hzjoined
18:12:11  <isaacs>(i mean, the code that we have now. the code that i wrote is only slightly disorganized, and modestly bad.)
18:14:01  * mikealquit (Quit: Leaving.)
18:14:48  * mikealjoined
18:16:00  * hzquit (Client Quit)
18:23:52  * pachetjoined
18:23:59  * pachetquit (Changing host)
18:23:59  * pachetjoined
18:26:25  * defunctzombiechanged nick to defunctzombie_zz
18:28:26  <trevnorris>morning
18:28:29  * pachetquit (Read error: Connection reset by peer)
18:29:01  * c4miloquit (Remote host closed the connection)
18:31:41  <isaacs>interesting. so, the benchmark is triggering a bunch of EPIPE errors. must've missed a bug somewhere.
18:32:49  * mikealquit (Quit: Leaving.)
18:34:04  * bnoordhuisquit (Ping timeout: 264 seconds)
18:34:14  * brsonquit (Ping timeout: 240 seconds)
18:38:07  * paulfryz_joined
18:38:13  * defunctzombie_zzchanged nick to defunctzombie
18:40:54  * isaacs&
18:40:54  <LOUDBOT>ANYHOW I'LL REFRAIN FROM SPEAKING MUCH ON ##TURTLES TODAY, BUT I WILL BE HERE, SILENTLY WATCHING, WAITING FOR THE BEST COMICAL MOMENT TO TALK AND BE KICKED
18:41:02  * paulfryzelquit (Ping timeout: 240 seconds)
18:41:31  * brsonjoined
18:43:31  * kazuponquit (Remote host closed the connection)
18:45:39  * c4milojoined
18:45:50  * brsonquit (Ping timeout: 245 seconds)
18:46:27  <MI6>nodejs-master-windows: #218 UNSTABLE windows-x64 (18/622) windows-ia32 (19/622) http://jenkins.nodejs.org/job/nodejs-master-windows/218/
19:00:55  * st_lukequit (Remote host closed the connection)
19:01:23  * st_lukejoined
19:02:01  * AvianFlujoined
19:06:07  * mikealjoined
19:06:29  * pachetjoined
19:11:24  * bajtosquit (Quit: bajtos)
19:27:14  * dapquit (Quit: Leaving.)
19:29:35  * sblomquit (Ping timeout: 245 seconds)
19:36:09  <trevnorris>ircretary: tell bnoordhuis ping me when you get in. have a few changes you might want to incorporate into your multi-context branch
19:36:09  <ircretary>trevnorris: I'll be sure to tell bnoordhuis
19:41:00  <groundwater>does libuv catch all signals by default? or does one explicitly have to set a handler form the node layer?
19:41:36  <groundwater>i am messing around with TTY stuff, and node appears to be ignoring SIGTTIN/SIGTTOU
19:41:56  <groundwater>which causes an EIO exception when reading from the TTY
19:43:58  * mikealquit (Quit: Leaving.)
19:53:23  * paulfryz_quit (Remote host closed the connection)
20:04:34  * dapjoined
20:14:30  * spoluquit (Ping timeout: 264 seconds)
20:19:21  <Raynos>Where's the current issue / branch / work on the new native add on C thing ?
20:20:03  <tjfontaine>github.com/tjfontaine/node-addon-layer
20:20:50  <tjfontaine>github.com/tjfontaine/node-addon-layer-test as an "example" of it at the moment
20:24:05  <tjfontaine>Raynos: is that what you were looking for?
20:24:13  <Raynos>Oh cool
20:25:36  <Raynos>I think so.
20:26:40  <tjfontaine>after some discussion with some C++ folk about my entry point that will be changing, but so far things have been going well
20:28:11  * brsonjoined
20:28:33  * bnoordhuisjoined
20:30:50  <bnoordhuis>trevnorris: pong - i'm not really working though
20:32:15  <trevnorris>bnoordhuis: that's fine. whenever you have time, there're a few things I'm doing for the new domain public api stuff that require ripping out some old code. just wanted to cross check with you so there was no unnecessary effort
20:32:25  <bnoordhuis>trevnorris: okay, shoot
20:33:11  <trevnorris>well, MakeDomainCallback and _tickDomainCallback are out
20:33:40  <bnoordhuis>what replaces them (if anything)?
20:34:33  <trevnorris>nothing. just did a little rework on the old ones to get them working.
20:34:42  <trevnorris>but didn't introduce any overhead.
20:34:57  <trevnorris>so instead of lazy loading _tickCallback i'm calling a function and passing it in.
20:35:10  <tjfontaine>were we exporting MakeDomainCallback?
20:35:19  <trevnorris>no
20:35:38  <bnoordhuis>trevnorris: calling a function where (and where from, js or c++)?
20:35:47  <trevnorris>bnoordhuis: just noticed you had the comment: "Factor out call to has_tick_callback_function()"
20:35:56  <trevnorris>like how it's done with domains
20:36:01  <trevnorris>process._setupDomainUse
20:36:26  <trevnorris>there's no need to lazy load tickCallback since we know w/o question it'll always be needed
20:36:38  <bnoordhuis>right
20:37:03  <trevnorris>it's the best way I could figure to get it from js to c++, but if there's a better way i'm all ears
20:37:49  <bnoordhuis>sounds good to me
20:38:05  <trevnorris>cool. almost have it working on top of your patch
20:38:38  <trevnorris>then the domain module will not require access to any of the core internals to work
21:01:37  * pachetquit (Quit: leaving)
21:08:48  * bradleymeckquit (Quit: bradleymeck)
21:09:05  * abraxasjoined
21:13:52  * abraxasquit (Ping timeout: 256 seconds)
21:15:59  <bnoordhuis>i am _seriously_ annoyed by the amount of duplication between the old and the new tls implementations
21:17:17  * mikealjoined
21:24:51  * isaacsfg
21:25:24  <isaacs>bnoordhuis: i haven't looked into it much. afaik, indutny just kinda shoved the old one into a corner, and rebuilt it
21:25:46  <isaacs>bnoordhuis: but if you wanna re-factor it so that they share some stuff, then that's fine. there's probably better ways to spend your time, though
21:25:57  <bnoordhuis>i opened an issue and fedor promised to look into it sometime soon
21:26:28  <bnoordhuis>refactoring is not optional though. we're talking 1000+ lines of almost verbatim copied code
21:26:36  <bnoordhuis>complex crypto code to boot
21:26:39  * c4miloquit (Remote host closed the connection)
21:30:59  <isaacs>bnoordhuis: copied from JS to C++, you mean, or duplicates in teh same language?
21:32:16  <bnoordhuis>isaacs: same language
21:32:38  <bnoordhuis>i.e. node_crypto.cc and tls_wrap.cc are like 50% identical
21:32:54  <bnoordhuis>_tls_legacy.js and _tls_wrap.js share a lot of code as well
21:33:22  <bnoordhuis>it's basically one big copy/paste job that was then massaged into something that works better with stream_wraps
21:34:22  * AvianFluquit (Remote host closed the connection)
21:34:26  * philipsquit (Ping timeout: 264 seconds)
21:35:35  <isaacs>oh, ok
21:35:49  <isaacs>yeah, that needs to be factored out, then
21:39:05  <indutny>heh
21:39:25  <indutny>bnoordhuis: I must say that it was originally your idea
21:39:40  <indutny>though, I admit that deduplication is necessary
21:44:05  <bnoordhuis>indutny: i can't imagine i suggested to just copy it
21:47:22  <isaacs>tjfontaine: you doing anything with smartos.nodejs.org?
21:48:26  <tjfontaine>isaacs: there's a pull request building on it atm
21:48:45  * mcavagequit (Remote host closed the connection)
21:49:15  <isaacs>ok
21:49:59  <tjfontaine>isaacs: would you like me to kill it? I can also follow up again here in office about making a baremetal reservation in the SF lab
21:50:19  <isaacs>tjfontaine: you don't have to kill it, butit might go slowly
21:50:26  <tjfontaine>that's fine
21:50:26  <isaacs>tjfontaine: also, yes, a baremetal reservation would be wonderfu.
21:50:39  <isaacs>tjfontaine: i'm testign http, so it's not so bad. fs is the real killer.
21:50:43  <tjfontaine>nod
21:52:18  * philipsjoined
21:52:24  <MI6>joyent/node: Ben Noordhuis master * dce02a1 : zlib: replace C cast with static_cast - http://git.io/khAXnw
21:54:04  <bnoordhuis>https://github.com/v8/v8/pull/10 <- wow
21:56:54  * c4milojoined
22:03:43  * rendarquit (Quit: Leaving)
22:04:07  <isaacs>ok, need to back this out and try a different path, i think
22:07:00  <MI6>nodejs-master: #422 UNSTABLE linux-x64 (4/622) linux-ia32 (6/622) smartos-ia32 (3/622) osx-ia32 (2/622) osx-x64 (2/622) smartos-x64 (8/622) http://jenkins.nodejs.org/job/nodejs-master/422/
22:07:05  <isaacs>my hope was to simplify the organization and logic by making http.OutgoingMessage a fully first-class stream.Writable subclass.
22:07:12  <isaacs>rather than justa facade around a net.Socket
22:07:15  <trevnorris>bnoordhuis: i'm at a loss figuring out what that massive change set does
22:07:15  <tjfontaine>right
22:07:29  <isaacs>since, after all, we end up duplicating some of teh functionality and such anyway
22:07:44  <isaacs>however, turns out, that's just too much JS object stuff being passed around and intialized andshit
22:08:04  <tjfontaine>trevnorris: port of v8 to http://en.wikipedia.org/wiki/ARM_architecture#Thumb
22:08:22  <isaacs>there's no one spot where we're spending all our time. just more of all the same stuff.
22:08:25  <tjfontaine>isaacs: hm, do we need to profile it?
22:08:32  <tjfontaine>oh
22:08:33  <isaacs>tjfontaine: i'm profiling it
22:08:36  <tjfontaine>k
22:08:50  <trevnorris>ah, ok. just the title "thumb backend" gave me a strange visual
22:09:03  <bnoordhuis>trevnorris: it makes everything better
22:09:07  <bnoordhuis>with more unicorn
22:09:21  <trevnorris>I LOVE UNICORNS!!!
22:09:21  <LOUDBOT>FUCK YOU MOFINO YOU'RE NOT MY BRO ANYMORE
22:09:39  <bnoordhuis>also, it moves globals into per-thread or per-context structures
22:09:44  <trevnorris>ah, don't be like that LOUDBOT
22:09:56  <isaacs>LOUDBOT: you know trevnorris loves you.
22:09:56  <LOUDBOT>isaacs: IF I CAN GET HIM TO COME OUT OF THE FUCKING CLOSET
22:10:02  <isaacs>LOUDBOT: srsly
22:10:02  <LOUDBOT>isaacs: I HAVE ABSORBED ALL OF THE CUTE AND NOW I HUNGER
22:10:04  <bnoordhuis>haha
22:11:04  * indexzerojoined
22:12:08  * felixgequit (Quit: felixge)
22:12:11  * DrPizzaquit (Ping timeout: 276 seconds)
22:12:17  * DrPizzajoined
22:12:41  <isaacs>ok. i guess making http.OutgoingMessage a less-bad facade around net.Socket will have to do.
22:12:46  <isaacs>a first-class Writable, it is not.
22:14:11  * mikealquit (Quit: Leaving.)
22:19:36  <MI6>nodejs-master-windows: #219 UNSTABLE windows-x64 (19/622) windows-ia32 (24/622) http://jenkins.nodejs.org/job/nodejs-master-windows/219/
22:20:33  <bnoordhuis>trevnorris: in all seriousness, if you have questions, don't hesitate to ask
22:21:37  <trevnorris>bnoordhuis: you mean about the PR? maybe after i've pulled my brain out of this domain api i'll have brain cells to spare :)
22:22:48  * stagas_joined
22:22:55  <trevnorris>actually, just realized haven't left my chair in around 6 hours and I really need to pee
22:24:35  * stagasquit (Ping timeout: 245 seconds)
22:24:43  * stagas_changed nick to stagas
22:31:40  * stagasquit (Ping timeout: 264 seconds)
22:32:05  * c4miloquit (Remote host closed the connection)
22:33:27  * stagasjoined
22:35:50  * wolfeidauquit (Remote host closed the connection)
22:35:51  * c4milojoined
22:41:18  * bnoordhuisquit (Ping timeout: 268 seconds)
22:44:23  * mikealjoined
22:49:15  * c4miloquit (Remote host closed the connection)
23:01:58  <trevnorris>maybe there should be a mailing list for everyone who uses node, that doesn't want it to look like node.
23:02:25  <tjfontaine>that's HN ;)
23:02:40  <trevnorris>hah
23:09:23  * abraxasjoined
23:13:59  * abraxasquit (Ping timeout: 268 seconds)
23:16:30  * dominictarrquit (Quit: dominictarr)
23:17:38  * c4milojoined
23:20:11  * jmar777quit (Remote host closed the connection)
23:42:59  * groundwaterquit (Quit: groundwater)