00:00:01  * ircretaryquit (Remote host closed the connection)
00:00:08  * ircretaryjoined
00:06:45  * AvianFlu_quit (Remote host closed the connection)
00:07:15  * AvianFlujoined
00:15:01  * amartensquit (Quit: Leaving.)
00:21:09  * AvianFlu_joined
00:22:27  <isaacs>trevnorris: pong
00:23:01  * st_lukejoined
00:23:59  * defunctzombiechanged nick to defunctzombie_zz
00:25:51  * AvianFlu_quit (Ping timeout: 260 seconds)
00:30:54  * dominictarrjoined
00:52:37  * c4milo_quit (Remote host closed the connection)
00:53:13  * c4milojoined
00:58:09  * c4miloquit (Ping timeout: 272 seconds)
00:59:38  * abraxasjoined
01:00:45  * amartensjoined
01:00:52  * dominictarrpart
01:03:49  * abraxasquit (Ping timeout: 241 seconds)
01:04:40  * st_luke_joined
01:06:45  * st_lukequit (Remote host closed the connection)
01:07:10  * st_lukejoined
01:08:31  * amartensquit (Read error: Connection reset by peer)
01:09:36  * sblomquit (Ping timeout: 252 seconds)
01:10:27  * st_luke_quit (Ping timeout: 265 seconds)
01:12:15  * c4milojoined
01:13:43  * dshaw_quit (Quit: Leaving.)
01:15:46  * st_lukequit (Remote host closed the connection)
01:16:16  * st_lukejoined
01:20:55  * st_lukequit (Ping timeout: 260 seconds)
01:27:12  * defunctzombie_zzchanged nick to defunctzombie
01:29:48  * abraxasjoined
01:40:30  * philipsquit (Quit: http://ifup.org)
01:42:52  * philipsjoined
01:59:42  * defunctzombiechanged nick to defunctzombie_zz
02:03:37  * TooTallNatequit (Quit: Computer has gone to sleep.)
02:06:26  * TooTallNatejoined
02:07:12  * TooTallNatequit (Client Quit)
02:28:43  * paulfryzelquit (Remote host closed the connection)
02:29:19  * paulfryzeljoined
02:31:47  * c4miloquit (Remote host closed the connection)
02:32:23  * c4milojoined
02:33:11  * c4milo_joined
02:33:14  * c4miloquit (Read error: Connection reset by peer)
02:33:26  * paulfryzelquit (Ping timeout: 240 seconds)
02:39:10  * inolenjoined
02:53:16  * kazuponjoined
02:58:10  * kazuponquit (Remote host closed the connection)
03:12:37  * paulfryzeljoined
03:26:55  * superjoequit (Quit: Leaving)
03:32:41  * brsonquit (Ping timeout: 272 seconds)
03:44:49  * c4milo_quit (Remote host closed the connection)
03:45:23  * c4milojoined
03:49:26  * c4miloquit (Ping timeout: 240 seconds)
03:50:27  * paulfryzelquit (Remote host closed the connection)
03:53:03  * AvianFlu_joined
03:57:06  * mikealjoined
03:58:48  * kazuponjoined
04:05:55  * kazuponquit (Remote host closed the connection)
04:08:46  * kazuponjoined
04:09:18  * inolenquit (Quit: Leaving.)
04:11:26  <trevnorris>isaacs: pong
04:35:46  * mikealquit (Quit: Leaving.)
04:37:55  * mikealjoined
04:40:41  * Benvie_quit (Ping timeout: 252 seconds)
04:40:58  * Benvie_joined
05:32:14  * julianduquequit (Ping timeout: 256 seconds)
05:40:18  * FROGGSquit (Quit: Verlassend)
05:58:07  * dshaw_joined
06:06:58  <groundwater_>trevnorris: ping
06:07:04  <trevnorris>groundwater_: pong
06:07:13  <groundwater_>it's been a long day
06:07:26  <groundwater_>i prob. won't have a chance to look at your commits until saturday
06:07:37  <groundwater_>or friday evening
06:08:34  <trevnorris>groundwater_: no worries. just wait until monday.
06:08:43  <trevnorris>the code review won't be done before then anyways.
06:10:29  <groundwater_>sounds good, i just wanted to sync up
06:10:37  <trevnorris>coolio.
06:15:50  * dshaw_quit (Ping timeout: 240 seconds)
06:23:44  * abraxasquit (Remote host closed the connection)
06:37:23  * paddybyersjoined
06:42:05  <MI6>nodejs-v0.10-windows: #283 UNSTABLE windows-ia32 (10/603) windows-x64 (9/603) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/283/
06:49:06  * rendarjoined
07:07:26  * FROGGSjoined
07:10:03  * st_lukejoined
07:11:10  * dshaw_joined
07:14:15  * st_lukequit (Ping timeout: 252 seconds)
07:15:50  * luxigo_joined
07:15:56  * dshaw_quit (Ping timeout: 256 seconds)
07:23:26  * abraxasjoined
07:24:29  * Kakera_joined
07:32:25  * AvianFluquit (Remote host closed the connection)
07:32:55  * AvianFlujoined
07:37:01  * AvianFluquit (Ping timeout: 240 seconds)
08:08:47  * inolenjoined
08:11:47  * dshaw_joined
08:16:14  * dshaw_quit (Ping timeout: 240 seconds)
08:28:40  * mralephjoined
08:28:51  * mraleph1quit (Read error: Connection reset by peer)
08:31:11  * AvianFlu_quit (Remote host closed the connection)
08:40:25  * abraxasquit (Remote host closed the connection)
08:45:58  * dsantiagoquit (Ping timeout: 245 seconds)
08:58:51  * Kakera_quit (Ping timeout: 272 seconds)
08:58:54  * abraxasjoined
09:01:43  * AvianFlujoined
09:05:25  * dsantiagojoined
09:06:45  * luxigo_quit (Ping timeout: 248 seconds)
09:09:50  * AvianFluquit (Ping timeout: 240 seconds)
09:12:30  * dshaw_joined
09:17:12  * dshaw_quit (Ping timeout: 256 seconds)
09:26:55  * kazuponquit (Remote host closed the connection)
09:27:23  * kazuponjoined
09:31:45  * kazuponquit (Ping timeout: 240 seconds)
09:56:50  <MI6>joyent/node: Maxim Bogushevich v0.10 * 9c6e06b : debugger: Fix bug in sb() with unnamed script - http://git.io/S1mJwg
09:57:08  <mmalecki>`3rdEden: yo
09:57:12  <mmalecki>er, wrong channel
09:57:23  <`3rdEden>mmalecki: OHAI, oh, okay
10:07:21  <MI6>nodejs-v0.10: #1558 UNSTABLE smartos-x64 (4/603) smartos-ia32 (4/603) linux-ia32 (1/603) http://jenkins.nodejs.org/job/nodejs-v0.10/1558/
10:11:04  <indutny>heya
10:12:12  <MI6>nodejs-v0.10-windows: #284 UNSTABLE windows-ia32 (10/603) windows-x64 (10/603) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/284/
10:12:50  * abraxasquit (Remote host closed the connection)
10:13:15  * dshaw_joined
10:17:39  * dshaw_quit (Ping timeout: 260 seconds)
10:23:53  * kazuponjoined
10:35:45  * abraxasjoined
10:47:57  <MI6>nodejs-v0.10: #1559 UNSTABLE smartos-x64 (4/603) smartos-ia32 (4/603) osx-x64 (1/603) http://jenkins.nodejs.org/job/nodejs-v0.10/1559/
10:54:47  * abraxasquit (Remote host closed the connection)
10:55:34  * bnoordhuisjoined
10:57:00  * abraxasjoined
11:03:44  <MI6>joyent/libuv: Sean Farrell master * ee434b3 : test: remove replacement snprintf for mingw (+2 more commits) - http://git.io/Hl85ag
11:04:49  <indutny>bnoordhuis: heya
11:05:58  <bnoordhuis>indutny: hoya
11:06:15  <indutny>bnoordhuis: how are you?
11:06:48  <bnoordhuis>indutny: i'm fine, thanks for asking :) you?
11:06:52  <indutny>fine too
11:06:58  <indutny>just finished candy box 2
11:07:02  <indutny>it was devastating
11:07:25  <MI6>libuv-master: #304 UNSTABLE windows (3/196) smartos (2/195) http://jenkins.nodejs.org/job/libuv-master/304/
11:08:36  <bnoordhuis>what's a candy box 2?
11:08:49  <indutny>oh
11:08:49  * indutnyhttp://candybox2.net/
11:08:55  <indutny>but
11:08:57  <indutny>be aware
11:08:59  <indutny>its time consuming
11:09:14  <MI6>libuv-master-gyp: #245 FAILURE windows-x64 (3/196) windows-ia32 (3/196) http://jenkins.nodejs.org/job/libuv-master-gyp/245/
11:09:32  <bnoordhuis>not when you have noscript installed
11:09:52  <indutny>ahhaha
11:14:00  * dshaw_joined
11:14:48  <MI6>libuv-node-integration: #289 FAILURE http://jenkins.nodejs.org/job/libuv-node-integration/289/
11:15:25  <bnoordhuis>grr, jenkins
11:15:52  <indutny>bnoordhuis: anyway, any other comments about fsevents?
11:15:58  <indutny>or can I land it?
11:16:06  <bnoordhuis>../src/fs_event_wrap.cc: In static member function ‘static void node::FSEventWrap::Start(const v8::FunctionCallbackInfo<v8::Value>&)’:
11:16:09  <bnoordhuis>../src/fs_event_wrap.cc:114:31: error: too many arguments to function ‘int uv_fs_event_init(uv_loop_t*, uv_fs_event_t*)’
11:16:12  <bnoordhuis>../deps/uv/include/uv.h:1896:15: note: declared here
11:16:13  <bnoordhuis>^ guess that's a legitimate failure
11:16:27  <indutny>too many argumenst?
11:16:30  <indutny>haha
11:16:39  <bnoordhuis>yeah, i bet it's saghul's commit from earlier this week
11:17:00  <bnoordhuis>i'll probably do a libuv release today and fix it up
11:17:10  <indutny>odd
11:17:10  <indutny>UV_EXTERN int uv_fs_event_init(uv_loop_t* loop, uv_fs_event_t* handle);
11:17:12  <bnoordhuis>as to your PR, i haven't looked at it again after yesterday
11:17:23  <indutny>bnoordhuis: ok
11:17:41  <bnoordhuis>uv_fs_event_init() used to take a third argument but that moved to uv_fs_event_start()
11:18:01  <bnoordhuis>okay, i have to go back to being a gracious host. back in a few hours
11:18:09  <saghul>bnoordhuis yep
11:18:47  <indutny>ah
11:18:49  * dshaw_quit (Ping timeout: 272 seconds)
11:19:08  <indutny>ok, and I'm going to look at that UDP DDoS
11:19:09  <indutny>hahaha
11:19:10  <indutny>:D
11:19:31  <indutny>huh
11:19:35  <indutny>seems to be throwing now
11:19:44  <indutny>bnoordhuis: have you changed anything in udp.c recently?
11:21:19  <bnoordhuis>indutny: git log :)
11:21:26  <indutny>yes, I just curious
11:21:27  <indutny>359d6678
11:21:34  <indutny>it was crashing yesterday
11:21:43  <indutny>now it returns -EBADF
11:21:46  <indutny>hm...
11:21:49  <bnoordhuis>v0.10 or master?
11:21:53  <indutny>master today
11:21:58  <indutny>perhaps v0.10 yesterday
11:22:06  <indutny>that's the only explanation, that I've so far
11:22:31  <bnoordhuis>the bug report was against v0.10, right?
11:24:32  <indutny>I think so
11:24:37  <indutny>but I thought I reproduced it on master
11:24:39  <indutny>yesterday
11:24:42  <indutny>so, please nvm
11:27:02  <indutny>hahaha
11:27:04  <indutny>its not crashing
11:27:05  <indutny>god
11:28:12  <indutny>ah
11:28:13  <indutny>I see now
11:28:28  <indutny>happening with both master and v0.10
11:28:35  * bnoordhuisquit (Ping timeout: 260 seconds)
11:28:36  <indutny>it wasn't happening because I was getting EMFILE
11:32:02  * Kakerajoined
11:32:43  * Rabenklauejoined
11:37:55  <Rabenklaue>Hi, I've got a question regarding lifetime and correctly freeing uv_handle_t structs. At http://codepad.org/ssyjGpor you can see a minimalistic C++ wrapper around uv_loop and uv_timer. Now I'm facing the problem that I'm not able to "close" the handle after the loop is done. Only stopping the timer decrements the ref-count of loop and let it stop, but then I got no chance of ever getting the resources of timer being freed.
11:39:36  <Rabenklaue>Isn't there a kind of "hook"/callback, which gets called right before the uv_loop is about to stop, so I can "close" all instances of timer there? Then I should be safe that all close callbacks are fired within the loop.
11:43:02  * kazuponquit (Remote host closed the connection)
12:14:41  * dshaw_joined
12:17:40  * kazuponjoined
12:18:07  <indutny>Rabenklaue: first of all, you can uv_unref() your timer
12:18:32  <indutny>Rabenklaue: then, after uv_run() you can uv_ref() it again call uv_close() on it and do uv_run() again
12:18:46  <indutny>Rabenklaue: is that what you want?
12:19:17  * dshaw_quit (Ping timeout: 248 seconds)
12:22:23  <Rabenklaue>indutny: Not exactly, I do want the loop to block (run) until the timer (or later any handle type) is stopped correctly. That's why I call uv_timer_stop() in the timer callback (with some c++ indirection).
12:28:54  <indutny>sorry
12:28:59  <indutny>will look at your code in a bit
12:29:00  <indutny>brb
12:32:00  * AvianFlujoined
12:34:43  * bnoordhuisjoined
12:36:47  * AvianFluquit (Ping timeout: 265 seconds)
12:39:30  * bnoordhuisquit (Ping timeout: 256 seconds)
12:42:23  * spionpart ("Leaving")
12:46:34  <Rabenklaue>Btw, the same problem seems to affect node.native (c++ified nodejs build around libuv) as http::~http is called after uv_run() has been completed, and in the destructor the socket is closed whereas the actual delete routine for the underlying handler will never be executed. But I cannot reproduce the memory leak, as node.native won't compile against current libuv because the new error handling.
12:48:29  <indutny>Rabenklaue: hm... you're trying to uv_close() in destructor
12:48:33  <indutny>that's not going to work
12:49:00  <indutny>though, not related
12:49:18  <indutny>Rabenklaue: why not start loop once again?
12:49:22  <indutny>to get close cb called?
12:51:54  * abraxasquit (Remote host closed the connection)
12:53:19  * kazuponquit (Remote host closed the connection)
12:53:47  <Rabenklaue>indutny: The uv_close in destructor does not affect the actual libuv handle which is still alive until the close-callback deletes it. Restarting the loop would be an option (after all handles are closed correctly), but this would corrupt my whole design (even the last timer.close() should be omitted, therefore the uv_close in destructor). :( It seems, I have to rethink the design.
12:53:47  * kazuponjoined
12:54:07  <indutny>ok
12:58:11  * kazuponquit (Ping timeout: 240 seconds)
13:04:20  * abraxasjoined
13:15:34  * dshaw_joined
13:20:25  * dshaw_quit (Ping timeout: 272 seconds)
13:24:21  * kazuponjoined
13:26:18  * kazuponquit (Read error: Connection reset by peer)
13:26:20  * kazupon_joined
13:44:23  * abraxasquit (Remote host closed the connection)
13:44:43  * bnoordhuisjoined
13:45:51  * kazupon_quit (Ping timeout: 252 seconds)
13:50:27  <kaeso>is there any plan/schedule for a 0.11.14?
13:50:35  <kaeso>(if it's ever going to happen)
13:50:55  <kaeso>I'd like to have the rust submodule synch'd to a tag on master
13:51:31  <bnoordhuis>kaeso: i was planning to do a release today actually
13:52:06  <kaeso>bnoordhuis: no hurry, but it would be great :)
13:52:29  <indutny>bnoordhuis: you're back?
13:52:35  <kaeso>(I'd also like to give it a spin on debian autobuilders this weekend)
13:53:14  <bnoordhuis>indutny: yes. btw: 'Lets keep it ABI compatible anyway, I like that it eats less memory for an event' <- i don't understand that comment
13:53:33  <indutny>bnoordhuis: well, you propose to use QUEUE* instead of void* next
13:53:34  <indutny>right?
13:53:51  <bnoordhuis>indutny: oh, right - if you change it to a queue
13:54:09  <bnoordhuis>indutny: my first comment was about changing the type of the pointer from void* to uv__fsevents_event_t*
13:54:17  <indutny>yes, I did it
13:54:20  <bnoordhuis>okay
13:54:50  <bnoordhuis>as to whether a queue or a single pointer is preferable, O(1) < O(n) and therefore O(1) > O(n), right?
13:55:16  <bnoordhuis>(clever pun that, eh?)
13:55:39  <indutny>huh?
13:55:45  <indutny>well
13:55:47  <bnoordhuis>too clever maybe :)
13:55:54  <indutny>looks like so :)
13:56:12  <indutny>anyway
13:56:15  <bnoordhuis>insertion into a queue is O(1) whereas insertion in a singly linked list is O(n)
13:56:16  <indutny>lets talk a bit about other thing
13:56:31  <bnoordhuis>let's finish this discussion first :)
13:56:35  <indutny>ok :)
13:56:38  <indutny>I'm just going to leave soon
13:56:46  <bnoordhuis>i'm trying to decide whether to land that fsevents patch in today's release
13:57:13  <indutny>for v0.11?
13:57:15  <indutny>why not?
13:57:42  <bnoordhuis>because i'm trying to understand why you're using a singly linked list rather than a queue
13:58:53  <indutny>ah, that was only for ABI compatibility
13:58:59  <indutny>because it was developed for v0.10, initially
13:59:06  <indutny>and there was no space
13:59:11  <indutny>in fs_event_t handle
13:59:18  <bnoordhuis>okay
14:00:03  <bnoordhuis>i'm not sure if that PR is eligible for v0.10, it's a fairly big change in behavior
14:00:12  <indutny>well
14:00:19  <indutny>you already did a big change in behaviour :)
14:00:25  <indutny>making it not work for some people in v0.10
14:00:40  <indutny>now it can make it work again
14:00:42  <indutny>but
14:00:51  <bnoordhuis>what do you mean?
14:00:52  <indutny>that doesn't mean that we shouldn't test it in v0.11 for a bit
14:00:58  <bnoordhuis>that thread stack size thing?
14:01:06  <indutny>bnoordhuis: no, watching multiple dirs
14:01:14  <indutny>bnoordhuis: it was failing before I introduced shared stream
14:01:36  <bnoordhuis>not following
14:01:37  <indutny>bnoordhuis: < 200 dirs are working now
14:01:46  <indutny>but if you'll try to watch 1000 dirs simultaneously
14:01:52  <indutny>v0.10 will definitely fail now
14:01:59  * abraxasjoined
14:01:59  <indutny>because you reverted changes that was fixing it
14:02:08  <indutny>and by coincidence those changes are still in master
14:02:22  <bnoordhuis>you know why i reverted it
14:02:31  <indutny>I know, but that doesn't mean that I agree
14:02:48  <bnoordhuis>you're free to disagree with me so long as you are wrong :)
14:03:12  <bnoordhuis>i kid, but landing those changes in v0.10 was a bad idea in hindsight
14:03:23  <indutny>ok, that doesn't matter right now
14:03:27  <indutny>lets land it in master
14:03:28  <bnoordhuis>if it's broken (again) for some people on os x, too bad for them
14:03:32  <indutny>and then return back to the problem
14:03:37  <bnoordhuis>right
14:03:41  <indutny>bnoordhuis: why do you care about it at all then? :D
14:03:41  <bnoordhuis>so, linked list or queue?
14:03:41  <indutny>haha
14:03:48  <indutny>bnoordhuis: I like linked list
14:03:56  <indutny>there're not that much events happening anyway
14:04:11  <bnoordhuis>how much is 'not that much' and how do you know that?
14:04:30  <indutny>haha
14:05:00  <indutny>that was mostly a joke
14:05:06  <indutny>I think we should land it
14:05:09  <indutny>and address it later
14:05:20  <indutny>I'll create follow-up PR
14:05:36  <bnoordhuis>we can address it now, now that the original PR is still open
14:05:44  <indutny>hahaha
14:05:49  <indutny>ok, do whatever you want
14:05:55  <indutny>I've another thing on the list:
14:05:55  <indutny>https://github.com/joyent/libuv/blob/master/src/unix/kqueue.c#L76-L118
14:06:06  * pachetjoined
14:06:06  * pachetquit (Changing host)
14:06:06  * pachetjoined
14:06:07  <indutny>what do you think about moving that loop ^
14:06:10  <indutny>into this one: https://github.com/joyent/libuv/blob/master/src/unix/kqueue.c#L124
14:06:32  <bnoordhuis>and then?
14:06:34  <indutny>basically, what I'm observing is that watchers are stopped between two kevent() calls
14:06:54  <indutny>and EV_DELETE isn't happening because both kevent()s are happening in one loop
14:07:07  <indutny>that leads to callbacks invoked for udp handles
14:07:10  <indutny>after stopping them
14:07:19  <indutny>perhaps, same thing is happening on linux
14:07:27  <bnoordhuis>okay, that's bad. couple of questions though
14:07:35  <bnoordhuis>'are happening in one loop' <- one loop of what?
14:07:42  <indutny>for (;; ...) {
14:07:44  <indutny>https://github.com/joyent/libuv/blob/master/src/unix/kqueue.c#L124
14:07:49  <bnoordhuis>okay
14:08:10  <indutny>is it ok for you?
14:08:13  <indutny>if yes - I'll open PR
14:08:17  <indutny>in a hour or so
14:08:23  <bnoordhuis>why is that? that first for loop only adds events to the kevent fd, it doesn't invoke callbacks
14:08:26  <indutny>going to leave in a couple of minutes
14:08:33  <indutny>bnoordhuis: first loop not only adds
14:08:37  <indutny>but also removes fds
14:08:41  <indutny>and that's what isn't happening
14:08:50  <indutny>because in second loop watchers are stopped
14:08:54  <indutny>and kevent() is called again
14:09:00  <indutny>and there're events on stopped watchers
14:09:13  <bnoordhuis>eh?
14:09:23  <indutny>well
14:09:27  <bnoordhuis>it only calls kevent() with EV_ADD or EV_ADD | EV_ONESHOT
14:09:46  <indutny>EV_ADD
14:09:50  <indutny>and also
14:09:51  <indutny>EV_DELETE
14:10:01  <indutny>oh, wait
14:10:05  <indutny>aaah
14:10:07  <indutny>I know what I meant
14:10:12  <indutny>w->events isn't updated
14:10:16  <indutny>from w->pevents
14:10:17  <indutny>:)
14:10:32  <bnoordhuis>in the first or the second for loop?
14:10:36  <indutny>second
14:11:08  <bnoordhuis>okay. where exactly would you expect that to happen?
14:11:12  <indutny>gtg now
14:11:12  <indutny>sorry
14:11:18  <bnoordhuis>okay, we'll talk more later
14:11:21  <bnoordhuis>run, fedor, run!
14:11:24  <indutny>sure
14:11:26  <indutny>I'll do
14:16:18  * dshaw_joined
14:19:15  <roxlu>hey guys I'm trying to compile libuv on arch linux, but I get an error 'Error running GYP', when running "./gyp_uv -f make"
14:20:10  <roxlu>oh :) I'm using python 3
14:20:34  * dshaw_quit (Ping timeout: 246 seconds)
14:24:01  * roxluwill uses autogen.sh
14:38:00  * julianduquejoined
14:39:51  * AvianFlujoined
14:40:26  * AvianFluquit (Remote host closed the connection)
14:42:42  * kazuponjoined
14:47:49  * kazuponquit (Ping timeout: 272 seconds)
14:48:22  * paulfryzeljoined
14:49:41  * defunctzombie_zzchanged nick to defunctzombie
14:58:51  * amartensjoined
14:59:01  * kazuponjoined
15:03:43  * octetcloudjoined
15:11:44  * abraxasquit (Remote host closed the connection)
15:15:39  * mikealquit (Quit: Leaving.)
15:16:54  * dshaw_joined
15:20:33  <MI6>nodejs-master: #640 UNSTABLE osx-x64 (1/649) smartos-ia32 (5/649) smartos-x64 (8/649) osx-ia32 (1/649) http://jenkins.nodejs.org/job/nodejs-master/640/
15:21:08  * dshaw_quit (Ping timeout: 240 seconds)
15:30:09  * inolenquit (Quit: Leaving.)
15:42:46  * hueniversequit (Quit: Leaving.)
15:42:59  * hueniversejoined
15:46:38  * FROGGSquit (Quit: Verlassend)
15:47:27  * bnoordhuisquit (Ping timeout: 272 seconds)
15:50:30  * dshaw_joined
15:50:36  * AvianFlujoined
15:51:36  * AvianFlu_joined
15:54:59  * dshaw_quit (Ping timeout: 260 seconds)
15:55:06  * AvianFluquit (Ping timeout: 252 seconds)
15:55:18  * AvianFlu_changed nick to AvianFlu
15:57:47  * Rabenklauequit (Ping timeout: 255 seconds)
15:59:47  * Rabenklauejoined
16:17:48  * dshaw_joined
16:18:49  <indutny>and I'm back
16:19:36  * st_lukejoined
16:19:47  * TooTallNatejoined
16:22:50  * dshaw_quit (Ping timeout: 268 seconds)
16:24:57  * abraxasjoined
16:28:21  * rendarquit (Quit: Leaving)
16:29:23  * dshaw_joined
16:31:25  * TooTallNatequit (Quit: Computer has gone to sleep.)
16:43:04  * st_lukequit (Read error: Connection reset by peer)
16:43:20  * st_lukejoined
16:45:39  * abraxasquit (Remote host closed the connection)
16:51:04  * rendarjoined
16:53:08  * c4milojoined
16:53:58  * bnoordhuisjoined
16:59:13  * bnoordhuisquit (Ping timeout: 268 seconds)
17:01:54  * rendarquit (Quit: Leaving)
17:06:35  * TooTallNatejoined
17:09:10  * c4miloquit (Remote host closed the connection)
17:09:44  * c4milojoined
17:13:56  * c4miloquit (Ping timeout: 245 seconds)
17:20:42  * abraxasjoined
17:30:57  * mikealjoined
17:33:47  <MI6>joyent/node: Brian White v0.10 * 21265e2 : doc: streams: document default objectMode setting - http://git.io/b6vkiw
17:44:04  <MI6>nodejs-v0.10: #1560 UNSTABLE smartos-x64 (5/603) smartos-ia32 (4/603) linux-ia32 (1/603) http://jenkins.nodejs.org/job/nodejs-v0.10/1560/
17:49:08  <MI6>nodejs-v0.10-windows: #285 UNSTABLE windows-ia32 (10/603) windows-x64 (10/603) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/285/
17:53:00  <MI6>libuv-master: #305 UNSTABLE windows (3/196) smartos (2/195) http://jenkins.nodejs.org/job/libuv-master/305/
17:55:01  * st_lukequit (Remote host closed the connection)
17:55:29  * st_lukejoined
17:59:16  * dshaw_quit (Quit: Leaving.)
17:59:46  * st_lukequit (Ping timeout: 245 seconds)
18:00:25  <MI6>libuv-node-integration: #290 FAILURE http://jenkins.nodejs.org/job/libuv-node-integration/290/
18:01:08  * st_lukejoined
18:01:13  * abraxasquit (Remote host closed the connection)
18:01:57  * superjoejoined
18:06:30  * brsonjoined
18:10:57  * FROGGSjoined
18:26:36  <MI6>joyent/node: Timothy J Fontaine master * 61ccaf9 : Merge remote-tracking branch 'upstream/v0.10' (+37 more commits) - http://git.io/_kiTJg
18:30:09  * dshaw_joined
18:36:07  <MI6>nodejs-master-windows: #433 FAILURE http://jenkins.nodejs.org/job/nodejs-master-windows/433/
18:43:02  <MI6>nodejs-master: #641 UNSTABLE osx-x64 (1/651) smartos-ia32 (7/651) smartos-x64 (10/651) osx-ia32 (1/651) http://jenkins.nodejs.org/job/nodejs-master/641/
18:46:03  <MI6>nodejs-master-windows: #434 FAILURE http://jenkins.nodejs.org/job/nodejs-master-windows/434/
18:49:51  * st_lukequit (Read error: Connection reset by peer)
18:50:13  * st_lukejoined
19:01:48  * kazuponquit (Remote host closed the connection)
19:02:18  * kazuponjoined
19:07:29  * kazuponquit (Ping timeout: 268 seconds)
19:13:29  * AvianFluquit (Remote host closed the connection)
19:25:42  * AvianFlujoined
19:29:39  * c4milojoined
19:32:51  * kazuponjoined
19:34:08  <indutny>heya
20:03:33  * kazuponquit (Read error: Connection reset by peer)
20:03:52  * kazuponjoined
20:04:14  * TooTallNatequit (Quit: Computer has gone to sleep.)
20:06:18  * c4miloquit (Remote host closed the connection)
20:07:25  * superjoequit (Read error: Connection reset by peer)
20:08:40  * dap_joined
20:09:45  <isaacs>hols
20:09:47  <isaacs>hola
20:21:10  * superjoejoined
20:21:41  * bnoordhuisjoined
20:21:43  <tjfontaine>what sort of hols?
20:25:43  <bnoordhuis>has anyone sent that gyp solaris fix upstream?
20:26:13  <tjfontaine>no, I will do it right now, and then try and hotpatch in the meantime
20:27:25  <tjfontaine>is https://code.google.com/p/gyp/issues/list the canonical location for this?
20:30:18  * dap_quit (Quit: Leaving.)
20:32:15  <bnoordhuis>tjfontaine: i'm not sure, i usually post patches to the mailing list with `git send-email`
20:32:37  <tjfontaine>I'll just harass thakis on irc
20:32:37  <bnoordhuis>tjfontaine: in my experience, issues in their bug tracker go unanswered for the longest time. if they get answered at all
20:32:52  <bnoordhuis>yeah, that's probably a good strategy :)
20:36:02  <tjfontaine>woah. https://code.google.com/p/gyp/source/detail?r=1765
20:36:09  <tjfontaine>oh for ninja
20:37:31  * kazuponquit (Ping timeout: 272 seconds)
20:38:08  <bnoordhuis>now fix CC!
20:38:19  <tjfontaine>heh
20:39:05  <tjfontaine>bnoordhuis: [10-25] 20:38:43 < thakis> tjfontaine: whoops, sorry. merged in gyp r1771
20:39:57  <isaacs>anyone wanna dig into a v8 bug?
20:39:58  <isaacs>> var o = vm.createContext({}); vm.runInContext('function f(){}', o, 'f.js'); o.f
20:39:58  <isaacs>undefined
20:39:58  <isaacs>> var o = vm.createContext({}); vm.runInContext('var f = function f(){}', o, 'f.js'); o.f
20:40:01  <isaacs>[Function: f]
20:41:22  <tjfontaine>you sure that's v8 and not vm2?
20:47:09  * dap_joined
20:49:21  <indutny>bnoordhuis: heya
20:57:05  <indutny>isaacs: I think it could be a vm2 thing
20:57:19  <isaacs>indutny: i'm building v8 to test now
21:01:13  <indutny>bnoordhuis: yt?
21:05:32  <isaacs>hm. yeah, it does look like a Vm2 thing
21:07:45  <bnoordhuis>tjfontaine: nice
21:08:19  <bnoordhuis>indutny: ih. looking at #965 again (even though that's against my new review rule)
21:08:28  <indutny>haha
21:08:29  <indutny>thanks
21:08:39  <indutny>bnoordhuis: I also wanted to discuss that polling thing
21:08:46  <indutny>isaacs: obviously
21:08:58  <indutny>isaacs: I believe it could be related to global proxy
21:09:05  <bnoordhuis>indutny: okay, shoot
21:09:10  <indutny>isaacs: and could be a v8 bug in the end, but it won't be visible without vm2
21:09:15  <bnoordhuis>or rather, give me five
21:09:38  <isaacs>indutny: yeah, i'm digging into it now
21:09:55  <indutny>isaacs: logging from proxy methods in C++ should give you enough introspection
21:10:01  <indutny>isaacs: probably, you already figured it out
21:10:02  <isaacs>indutny: gonna try to write a standalone program that does the same basic thing that vm2 does
21:10:04  <indutny>sorry for bothering
21:10:07  <isaacs>indutny: no, no problem
21:10:12  <bnoordhuis>indutny: the way you're dealing with that queue could be a little less... idiosyncratic
21:10:50  <indutny>bnoordhuis: well, I don't want to lock too much
21:11:01  <indutny>and too often
21:11:13  <indutny>btw, "idiosyncratic" is a new word to me
21:11:21  * indutnylooks up in thesaurus
21:11:43  <indutny>you said that my code is quirky?
21:11:44  <indutny>:)
21:12:09  <bnoordhuis>quirky, hm? i'd translate it as 'unique'
21:12:33  <indutny>oh
21:12:57  <indutny>bnoordhuis: anyway, you don't like it?
21:13:04  <bnoordhuis>oh, i'm not saying that
21:13:18  <bnoordhuis>but there's a bit of code at the top that looks like it's merging two lists, i think?
21:13:51  <bnoordhuis>that could be done by simply appending the head of list A to list B
21:14:16  <indutny>hm...
21:14:20  <indutny>I don't think that it work out
21:14:28  <bnoordhuis>why not?
21:15:09  <indutny>let me think about it for a bit
21:15:22  <indutny>because you'll change PREV and NEXT of it
21:15:27  <indutny>and I'll put only head there
21:15:40  <indutny>discarding the rest of elements
21:16:23  <bnoordhuis>for the record, you are trying to append one list to another, right?
21:16:52  <indutny>btw
21:16:58  <bnoordhuis>in that case, you could simply use QUEUE_ADD
21:17:08  <indutny>bnoordhuis: sorry, just noticed that we're talking about different code
21:17:13  <indutny>oooh
21:17:15  <indutny>QUEUE_ADD
21:17:18  <bnoordhuis>yes :)
21:17:21  <indutny>shit
21:17:22  <indutny>:)
21:17:25  <bnoordhuis>haha :)
21:17:29  <indutny>bnoordhuis: anyway
21:17:33  <indutny>bnoordhuis: at the top of the file
21:17:38  <indutny>where you're watching right now
21:17:39  <indutny>I suppose
21:17:46  <indutny>the code is detaching queue from head
21:18:09  <indutny>perhaps, I should use QUEUE_ADD there too
21:18:12  <indutny>and QUEUE_FOREACH loop
21:18:37  <bnoordhuis>ah
21:19:05  <bnoordhuis>are you just detaching the head node?
21:19:29  <bnoordhuis>or is the intention to empty handle->cf_events but preserve the queue?
21:19:42  <bnoordhuis>er, awkward wording
21:19:54  <indutny>I think QUEUE_ADD in the pair with QUEUE_INIT should do the work
21:20:00  <indutny>move all elements to other list
21:20:04  <indutny>and empty original one
21:20:09  <bnoordhuis>what about QUEUE_SPLIT?
21:20:16  <indutny>its for loosers
21:20:33  <bnoordhuis>:)
21:20:40  <bnoordhuis>also, *losers :)
21:20:51  <indutny>shit
21:20:52  <indutny>:)
21:21:14  <bnoordhuis>QUEUE_SPLIT does an implicit QUEUE_INIT so i think you're good then
21:21:19  * c4milojoined
21:21:31  * dap_quit (Quit: Leaving.)
21:22:09  <indutny>bnoordhuis: yeah, my previous comment was a joke, basically
21:22:15  <indutny>I was writing this code in a car
21:22:20  <indutny>thankfully I wasn't a driver
21:22:27  <indutny>and am not
21:22:32  <indutny>which is pretty fortunate to
21:22:34  <indutny>s/to/too/
21:22:54  <bnoordhuis>indeed :)
21:23:10  <bnoordhuis>and don't worry, i figured it was a joke
21:23:33  <bnoordhuis>though i have to admit, humor coming from russians is always unexpected
21:24:06  <bnoordhuis>very serious people, the russians. last country in the world to discover standup comedy
21:24:14  <bnoordhuis>okay, i'll get back to work now
21:25:40  <indutny>standup comedy, you say
21:25:44  <indutny>I say bullshit
21:25:49  * c4miloquit (Ping timeout: 246 seconds)
21:25:53  <indutny>well, I mean in russia
21:26:04  <indutny>there was better tries
21:26:13  <bnoordhuis>oh? do tell!
21:26:35  <indutny>the show was called KVN (CFR - Club of Funny and Resourceful)
21:26:43  <indutny>though, it sounds a bit better on russian
21:26:45  * TooTallNatejoined
21:26:47  <indutny>mraleph: yt?
21:26:47  <indutny>:)
21:26:52  <indutny>anyway
21:26:57  <indutny>its a student humour
21:27:12  <indutny>teams from different universities were having a competition on stage
21:27:19  <bnoordhuis>can you give an example?
21:27:36  <indutny>http://en.wikipedia.org/wiki/KVN
21:28:00  <indutny>started in 1961
21:28:07  <indutny>was funny until 2000
21:28:18  <bnoordhuis>wow, it's really old
21:28:46  <bnoordhuis>the show itself, i mean, not necessarily the humor in it
21:29:25  <indutny>let me find a video
21:29:53  <bnoordhuis>you know, my russian isn't what it used to be
21:31:18  <indutny>http://www.youtube.com/watch?v=XGLTiYbb_8Y
21:31:23  <indutny>can't find english subs
21:33:12  <indutny>oh, found one
21:33:13  <indutny>http://www.youtube.com/watch?v=pcKu9yP0ysQ
21:33:14  <indutny>not as funny
21:33:17  * dap_joined
21:33:54  * kazuponjoined
21:34:09  * bnoordhuisbraces himself for russian college humor
21:35:41  <bnoordhuis>i am suitably impressed
21:37:23  <indutny>heh
21:38:23  * mikealquit (Quit: Leaving.)
21:38:31  * kazuponquit (Ping timeout: 245 seconds)
21:39:18  * mikealjoined
21:40:10  * Rabenklauequit (Ping timeout: 246 seconds)
21:40:59  <MI6>joyent/node: Sam Roberts v0.10 * a60f671 : doc: fix missing backtick in 2e16037 - http://git.io/Ik8_qA
21:41:07  * Collinjoined
21:42:46  <Collin>I'm using libuv with CURL on Windows, and I'm finding that the uv_run loop is bottlenecking my I/O
21:43:19  <Collin>If I attempt to use 4 concurrent CURL handles, I get capped around 1 MBps throughput. If I up that number to 20 concurrent handles, my throughput goes up to about 5 MBps
21:43:24  <Collin>Has anyone encountered this, or any idea what it might be?
21:43:33  <Collin>It seems like libuv isn't calling my callbacks often enough
21:44:08  <bnoordhuis>Collin: how have you integrated curl and libuv?
21:44:24  <Collin>I'd be able to answer that better if I wrote this code
21:45:37  <bnoordhuis>i guess we're at something of an impasse then :)
21:46:45  <Collin>Whenever CURL creates a socket, I call uv_poll_start with the handle and a callback, which forwards the event to CURL
21:47:08  * mikealquit (Quit: Leaving.)
21:47:25  <Collin>I'm just wondering if there's an obvious reason why libuv isn't polling the sockets fast enough
21:48:22  <bnoordhuis>i don't know. have you tried it on a unix system?
21:48:32  <indutny>bnoordhuis: added QUEUE_SPLIT and QUEUE_ADD
21:48:42  <indutny>bnoordhuis: just in case if you're going to take a look at it again
21:48:45  <bnoordhuis>indutny: review windows for today is up :)
21:48:52  <indutny>ok :)
21:49:02  <indutny>will you turn on your laptop tomorrow?
21:49:21  <Collin>We use it on OS X as well, but I'm not sure if it's exhibiting the same behavior
21:49:24  <bnoordhuis>most definitely. my inlaws are coming over
21:49:36  <indutny>bnoordhuis: you should concentrate yourself on review then
21:49:41  <indutny>bnoordhuis: pretend you're super-busy
21:49:45  <indutny>(friendly advice)
21:49:50  <bnoordhuis>Collin: i guess what happens is that libuv determines the handle is not suitable to fast polling so it falls back to thread-based polling
21:49:57  <bnoordhuis>indutny: i will :)
21:50:07  <isaacs>Weird. the GlobalPropertySetterCallback isn't being called for function declarations
21:50:10  <indutny>cool
21:50:41  <indutny>ok, seems like its time to finish up things
21:50:43  <indutny>ttyl
21:50:46  <indutny>and thanks for everything
21:50:52  <bnoordhuis>*suitable for. damnit, it's getting late and i'm starting to make stupid grammar errors
21:51:12  * dap_quit (Quit: Leaving.)
21:51:14  <bnoordhuis>cheers fedor, say hi to the misses from me
21:51:16  <MI6>nodejs-v0.10: #1561 UNSTABLE smartos-x64 (4/603) smartos-ia32 (4/603) osx-x64 (1/603) http://jenkins.nodejs.org/job/nodejs-v0.10/1561/
21:52:14  <indutny>bnoordhuis: erm?
21:52:29  <indutny>you meant missis?
21:52:37  <indutny>anyway
21:52:48  <indutny>ah
21:52:55  <indutny>misses is almost the same as ladies
21:52:57  <indutny>god
21:53:15  <bnoordhuis>english eh? :)
21:53:19  <indutny>bnoordhuis: I bet you're laughing now
21:53:23  <bnoordhuis>always
21:55:23  <isaacs>ok, this is weird: https://gist.github.com/isaacs/7162414
21:56:38  * c4milojoined
21:57:10  <indutny>haha
21:57:24  <isaacs>if you define a function, and there's a global setter, it just fraks the fuck out
21:57:35  <indutny>never know there was such message
21:57:39  <indutny>s/know/knew/
21:57:43  <isaacs>yeah
21:57:54  <indutny>sorry
21:57:56  <indutny>heading out
21:57:59  <indutny>straight into bed
21:58:02  <indutny>:)
21:58:08  <indutny>see ya tomorrow or at monday
21:58:11  <indutny>ttyl
21:58:29  * mikealjoined
21:58:43  <isaacs>indutny: have a good weekend and sleep :)
22:02:13  <Collin>Hmm
22:02:23  <Collin>The code I'm using is essentially the same as http://nikhilm.github.io/uvbook/utilities.html#external-i-o-with-polling
22:02:31  <Collin>I guess libuv just isn't suitable for this on Windows
22:04:32  <bnoordhuis>Collin: yeah, not all handle types work with the fast poll path
22:04:45  <bnoordhuis>if that's an issue, you could either do the polling yourself in a thread or something
22:04:47  <MI6>nodejs-v0.10-windows: #286 UNSTABLE windows-ia32 (11/603) windows-x64 (11/603) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/286/
22:05:08  <bnoordhuis>or run it on unix only and call it a day. unices don't have that issue
22:07:56  * pachetquit (Quit: leaving)
22:15:10  * defunctzombiechanged nick to defunctzombie_zz
22:17:55  <trevnorris>afternoon all
22:32:15  * dshaw_quit (Quit: Leaving.)
22:34:55  * kazuponjoined
22:36:06  <isaacs>good afternoon
22:59:01  <tjfontaine>good day
22:59:57  * AvianFlu_joined
23:00:24  * AvianFlu_quit (Remote host closed the connection)
23:03:27  * AvianFluquit (Ping timeout: 272 seconds)
23:07:52  * c4miloquit (Remote host closed the connection)
23:08:01  * kazuponquit (Ping timeout: 246 seconds)
23:08:25  * c4milojoined
23:11:48  <trevnorris>how things going for everyone?
23:12:05  <trevnorris>tjfontaine: how was the meeting w/ groundwater_?
23:13:19  * c4miloquit (Ping timeout: 272 seconds)
23:15:46  <isaacs>anyone know if there is a corrollary to SetNamedPropertyHandler and SetAccessCheckCallbacks to use for configured properties?
23:15:47  <tjfontaine>sok, he wanted to talk about CI
23:17:36  * paddybyersquit (Quit: paddybyers)
23:18:07  <trevnorris>isaacs: not following the "configured properties" part
23:18:22  <isaacs>trevnorris: ie, defined with Object.defineProperty(obj, 'x', {... })
23:19:01  <isaacs>trevnorris: https://gist.github.com/isaacs/7163071
23:19:22  <isaacs>trevnorris: properties created in that way are not copied out of the vm.runInContext
23:19:32  <isaacs>trevnorris: because they never invoke the callbacks in C++
23:19:41  <trevnorris>hm. strange.
23:19:49  <isaacs>trevnorris: see also: /join v8 :)
23:19:57  <isaacs>trevnorris: where i asked the same question, and no one has responded
23:20:43  <trevnorris>heh, you'd be lucky to ever get a response in there. never gotten on myself.
23:21:16  <isaacs>yeah
23:24:28  * c4milojoined
23:25:27  <trevnorris>isaacs: so is this a bug in v8, or a bug in the vm implementation?
23:26:20  <isaacs>trevnorris: it's a bug in the VM implementation, and (afaict?) a shortcoming in V8's C++ api
23:26:29  <trevnorris>ah ok
23:33:02  * mikealquit (Quit: Leaving.)
23:33:49  * mikealjoined
23:34:24  <trevnorris>tjfontaine: about the windows build issue. I like https://github.com/joyent/node/pull/6411 as the solution, also removing NODE_EXTERN from ObjectWrap.
23:34:25  <trevnorris>MSVC is a mystery to me, but logically it seems that should work.
23:38:09  <tjfontaine>ok I will do it tonight
23:39:06  * octetcloudquit (Ping timeout: 256 seconds)
23:39:31  <trevnorris>well, i'm in no hurry :P
23:39:31  <trevnorris>but we'll need to check that a simple module can be compiled with that patch. here's the simple test case for that: https://gist.github.com/trevnorris/7146409
23:40:09  <tjfontaine>thanks!
23:40:48  * julianduquequit (Ping timeout: 256 seconds)
23:40:55  * julianduquejoined
23:41:08  <trevnorris>np. hate to dish this off though. you wouldn't happen to have a vm that would let me compile node stuff for windows?
23:41:33  <tjfontaine>I have a vm, but I'm pretty protective of it, because that's what I use for releases
23:41:47  <tjfontaine>we need to communicate with azure folk though so we can get more
23:41:55  <tjfontaine>and more varied
23:42:14  <trevnorris>true. we probably aren't doing builds for win8 right now, huh?
23:42:36  <tjfontaine>well, our builds do work on 8, but we don't do tests :)
23:42:43  <trevnorris>heh
23:43:15  * dshaw_joined
23:43:31  <tjfontaine>but for as many as I want to do this the RightWay(tm) I think it should be coming from azure
23:43:37  <tjfontaine>I will send an email this weekend for it
23:44:30  <trevnorris>sounds good. while I don't personally care for windows, it'd be nice to have an env were I can test.
23:44:37  <isaacs>so, one option is to copy the fields over after the script runs...
23:44:42  <isaacs>but... ew.
23:47:47  * dshaw_quit (Ping timeout: 272 seconds)
23:48:27  * dshaw_joined
23:49:54  <trevnorris>isaacs: just curious. that issue doesn't happen in 0.10.21.
23:50:06  <trevnorris>so, i'd believe it has something to do w/ the new vm implementation?
23:54:09  * FROGGSquit (Ping timeout: 252 seconds)
23:55:10  * FROGGSjoined
23:58:05  * defunctzombie_zzchanged nick to defunctzombie