00:00:35  * isaacstopic: liberal utopian vacation ~ "Shit came real!" --indutny ~ http://logs.libuv.org/libuv ~ http://groups.google.com/group/libuv
00:05:41  * c4miloquit (Remote host closed the connection)
00:07:06  <tjfontaine>bnoordhuis: seems to build
00:12:25  <bnoordhuis>tjfontaine: you have commit access to joyent/node?
00:12:56  <tjfontaine>bnoordhuis: nope, but I can work up a PR if you'd like
00:13:38  <tjfontaine>when I tried to `git revert` the main one I got all kinds of conflicts, I tried --strategy theirs and ours but nothing seemed to go cleanly, was I just doing that wrong?
00:14:47  <bnoordhuis>i don't know, let me try
00:15:32  <bnoordhuis>ah, style fixes in src/v8ustack.d
00:15:41  <tjfontaine>yes [02-25] 18:55:41 < tjfontaine> ugh all the whitespace changes
00:15:42  <bnoordhuis>that's why i hate style and lint commits
00:16:09  <tjfontaine>I believe I mentioned it should have been a separate commit :)
00:16:22  <bnoordhuis>guess i'll just partially revert it
00:16:30  <bnoordhuis>and make some scolding remarks in the commit log
00:20:15  <bnoordhuis>ah, screw it - i'll revert them all
00:20:23  <bnoordhuis>tjfontaine: or you can do it if you want the honors
00:22:00  <tjfontaine>bnoordhuis: either or, is the `git revert` the preferred repo way, or do you do something different?
00:23:06  <bnoordhuis>tjfontaine: `git revert` makes it easiest to roll back/reapply changes
00:23:24  <bnoordhuis>(usually)
00:23:58  <tjfontaine>ok, and do you normally keep the "Conflicts" section of the commit message?
00:24:35  <bnoordhuis>yes
00:24:36  <tjfontaine>k
00:32:04  <MI6>joyent/node: bnoordhuis created branch unbreak-sunos - http://git.io/Jc3X8g
00:32:31  <bnoordhuis>tjfontaine: ^ want to test it?
00:32:39  <tjfontaine>sure, here's mine as well https://github.com/tjfontaine/node/tree/dtrace64-revert
00:33:43  <tjfontaine>bnoordhuis: it seems to have built, but I'm going to clean and rebuild
00:33:57  <trevnorris>isaacs: in events.js, everything's being set to null when removed. is that an unchangeable thing?
00:34:24  <bnoordhuis>tjfontaine: yours also rolls back the freebsd fix, doesn't it?
00:34:34  <tjfontaine>probably
00:35:33  <tjfontaine>bnoordhuis: builds cleanly
00:36:05  <bnoordhuis>okay, cool - i'll land it
00:36:12  <bnoordhuis>too bad about the freebsd fix :/
00:36:29  <tjfontaine>python tools/test.py pummel/test-{post,dtrace}*
00:36:30  <tjfontaine>[00:14|% 100|+ 3|- 0]: Done
00:36:43  <MI6>joyent/node: Ben Noordhuis master * f80f3c5 : sunos: unbreak build after v8 downgrade Commit 3d67f89 ("fix generation - http://git.io/5XLe2Q
00:37:16  <trevnorris>bnoordhuis: so... i was testing the memory usage between pre and post 3.14 revert. uses just as much. the 50% additional mem usage must be from node.
00:37:30  <trevnorris>(against v0.8)
00:37:48  <trevnorris>(and net tests)
00:37:50  <bnoordhuis>you're not telling me i did all that for nothing, aren't you?
00:38:12  <tjfontaine>thank goodness I'm not in .nl to see bnoordhuis explode
00:39:08  <bnoordhuis>trevnorris: easy check, downgrade to the v8 that's in v0.8 and see if it makes a difference
00:39:16  <bnoordhuis>that's 3.11.15 iirc
00:39:50  <trevnorris>oh... i thought 3.14 was in v0.8. ok, i'll do that.
00:40:55  <bnoordhuis>oh, it's 3.11.10.25 - close enough
00:41:34  <trevnorris>just did a "git checkout origin/v0.8 -- deps/v8/" so that should do it.
00:42:01  <trevnorris>hm, some api changes needed to be worked out. might take me a bit but i'll let you know.
00:44:23  <trevnorris>bnoordhuis: well, that went a lot quicker than I thought.
00:44:45  <bnoordhuis>yeah, there weren't that many api changes between 3.11 and 3.14
00:45:11  <trevnorris>bnoordhuis: so against my tcp_net2_c2s: master - 250MB; 3.11 - 176MB
00:45:14  <trevnorris>so it is v8
00:45:46  <trevnorris>but doesn't seem to be much difference between 3.14 and 3.15.
00:49:56  * bradleymeckjoined
00:51:59  * dominictarrquit (Quit: dominictarr)
00:52:41  <bnoordhuis>trevnorris: hm, okay
00:52:59  <bnoordhuis>did 3.15 have the Utf8Length() regression? i forgot
00:53:08  <trevnorris>no, that started in 3.16
00:53:48  <bnoordhuis>okay, good. iirc i did see some spurious crashes with 3.15
00:54:00  <bnoordhuis>but i forgot the details
00:54:07  * bnoordhuislooks around for the core dump
00:54:43  <bnoordhuis>hah, apparenty i have collected 200+ core files over the years
00:56:25  <tjfontaine>congrats
00:58:02  <isaacs>bnoordhuis, trevnorris: How does 3.14 perform vs 3.11.15?
00:58:25  <isaacs>er, 3.11.10 or whatever 0.8 used
00:58:28  <trevnorris>so far 3.14 uses just as much memory as 3.15. running benchmarks now.
00:58:38  <trevnorris>3.11 uses ~50% memory
00:58:46  <trevnorris> *less memory
00:58:47  <isaacs>memory is no biggie
00:58:48  <isaacs>don't care muhc
00:58:55  <isaacs>performance is more important.
00:59:07  * isaacscan buy more space, but not more time
01:00:12  <bnoordhuis>epoll_ctl(5, EPOLL_CTL_ADD, 6, {...}) = 0 <- i hate this about strace master, it abbrevs the arguments
01:00:53  <tjfontaine>bnoordhuis: btw, do you think we could backport the two tap changes to libuv 0.8 as well?
01:01:09  <bnoordhuis>tjfontaine: sure
01:01:30  * c4milojoined
01:02:52  <tjfontaine>bnoordhuis: thanks
01:03:53  <isaacs>omg, this debugger-client test is killing me
01:04:14  <isaacs>i've finally figured out where it's actually failing and getting hung up, and now that i have the test script ready to gcore that sucker, it's refusing to fail.
01:04:42  <isaacs>it's literally shattering my joy
01:04:51  <tjfontaine>you shant see it again until next ground hogs day
01:04:55  <MI6>joyent/libuv: Timothy J Fontaine v0.8 * 23b9347 : test: don't rewind_cursor when using tap_output This is a back-port of c (+1 more commits) - http://git.io/AZ3z7Q
01:05:26  <trevnorris>isaacs: i'll need to let them run longer and a wider spread, but so far i'm seeing pretty much the same performance on tcp_net2_c2s from 3.11, 3.14 and 3.15 on master.
01:07:16  <bnoordhuis>epoll_ctl(5<anon_inode:[eventpoll]>, EPOLL_CTL_ADD, 6<pipe:[697182]>, {...}) = 0 <- this is very nice though, it tells you what kind of fd it is
01:07:41  <trevnorris>be back on later. out
01:07:42  * trevnorrisquit (Quit: Leaving)
01:10:39  <isaacs>it's literally shattering my joy
01:10:51  <isaacs>er, up-enter in the wrong terminal ;)
01:11:13  <tjfontaine>heh
01:11:27  <tjfontaine>isaacs: clearly it's *still* shattering your joy
01:14:09  * dominictarrjoined
01:18:05  * mikealquit (Quit: Leaving.)
01:18:14  * loladiroquit (Quit: loladiro)
01:19:01  * mikealjoined
01:24:02  * c4miloquit (Remote host closed the connection)
01:24:59  * loladirojoined
01:26:17  <isaacs>Hm.
01:26:55  <isaacs>So, the reason why test-debugger-client.js fails, apparently, is that it's locking up calling new DebuggerAgent in v8
01:27:45  <isaacs>also, there's occasionally a 'break' message, which we're not responding to.
01:27:45  * mikealquit (Quit: Leaving.)
01:27:46  <bnoordhuis>that strace thing where it abbreviated the args? that was a bug. it tries to be smart and use fancy new syscalls to copy the data from the traced process
01:27:48  <isaacs>but this is more troubling:
01:27:50  <bnoordhuis>but it did it wrong :)
01:27:50  <isaacs>08046688 libc.so.1`__lwp_park+0x19(fec52a40, 0, 88c21c0, 0)
01:27:50  <isaacs>080466c8 libc.so.1`mutex_lock_impl+0x163(88c21c0, 0, feda5880, 0, 8046750, fed3ceb6)
01:27:53  <isaacs>080466e8 libc.so.1`mutex_lock+0x10(88c21c0, fead9000, 8046728, feabc6bc)
01:27:56  <isaacs>08046728 libumem.so.1`umem_cache_alloc+0x51(88c2010, 0, 3, feabcb9a)
01:27:58  <isaacs>08046778 libumem.so.1`umem_alloc+0xcd(48, 0, 80467b8, feab998a)
01:28:01  <isaacs>080467a8 libumem.so.1`malloc+0x2a(40, feda0000, 80467f8, fed379e1, feda3c48, 0)
01:28:03  <isaacs>080467d8 libstdc++.so.6.0.16`operator new+0x29(40, 8640100, 0, fed29c9e, fec52a40, feda0000)
01:28:06  <isaacs>08046828 v8::internal::Debugger::StartAgent+0x6c(89d6ec8, 8645ecf, 16e2, 0, 0, fec52a40)
01:28:09  <isaacs>08046848 v8::Debug::EnableAgent+0x51(8645ecf, 16e2, 0, 888db20, fed19069, feda0000)
01:32:31  <tjfontaine>hm
01:38:00  * abraxasjoined
01:40:26  * bradleymeckquit (Quit: bradleymeck)
01:42:57  <isaacs>well. it's progress: https://code.google.com/p/v8/issues/detail?id=2555&thanks=2555&ts=1361842934
01:43:38  * loladiroquit (Quit: loladiro)
01:44:32  * loladirojoined
01:48:42  <bnoordhuis>isaacs: you mean it hangs in StartAgent()?
01:48:54  * kazuponjoined
01:49:04  * kazuponquit (Remote host closed the connection)
01:49:19  * kazuponjoined
01:51:11  <bnoordhuis>looking at that backtrace, it suggests it's not v8 that's at fault but libumem
01:51:33  <bnoordhuis>i mean, malloc is not supposed to block indefinitely
01:53:59  * TooTallNatequit (Ping timeout: 252 seconds)
01:54:43  * dapquit (Quit: Leaving.)
01:55:30  * sblompart
01:56:23  <isaacs>yeah, but it's hanging in os x as well.
01:56:25  <isaacs>which is... weird.
01:58:11  * TooTallNatejoined
01:59:27  <isaacs>though, it has been running MUCH nicer on my laptop now.
01:59:33  <isaacs>so i'm going ot call this at least a modest win
02:01:48  <isaacs>bnoordhuis: yeah, it's getting mutex locked on os x for sure.
02:02:07  * qmx|awaychanged nick to qmx
02:02:31  <bnoordhuis>i guess i should be able to reproduce that then
02:02:41  <bnoordhuis>what test do you run?
02:02:43  <isaacs>bnoordhuis: https://github.com/isaacs/node/compare/debugger-testy-fixy if you feel like banging on it
02:02:53  <isaacs>bnoordhuis: then: while ./node test/simple/test-debugger-client.js; do true; done
02:02:59  <isaacs>bnoordhuis: takes a few minutes to die
02:03:13  <isaacs>(as opposed to a few *runs* when we don't catch the break signal)
02:03:49  <bnoordhuis>isaacs: i need to apply that patch?
02:03:54  <isaacs>bnoordhuis: https://github.com/isaacs/node/commit/ddcf5759756fe60ca44473be04df18a031740ecb is the patch to apply
02:04:16  <isaacs>bnoordhuis: otherwise you'll never see the malloc/mutex lockup, because you'll go rage blind by the 'break' lockups
02:05:03  <isaacs>bnoordhuis: replace the kill/throw in the timeout function with `spawn('gcore', [nodeProcess.pid], {stdio:'inherit'}).on('close',function() { throw "timeout" })`
02:05:18  <isaacs>bnoordhuis: to get a core dump
02:06:40  * kazuponquit (Remote host closed the connection)
02:06:49  <isaacs>also seeing this once in a while, which is a bit infuriating, since it's clear indication of a lie:
02:06:52  <isaacs>got stderr data "Hit SIGUSR1 - starting debugger agent.\n"
02:06:54  <isaacs>got stderr data "debugger listening on port 5858\n"
02:06:55  <bnoordhuis>ah indeed, blocked in a malloc spinlock
02:06:57  <isaacs>>>> connecting...
02:06:59  <isaacs>events.js:69
02:07:02  <isaacs> throw arguments[1]; // Unhandled 'error' event
02:07:04  <isaacs> ^
02:07:07  <isaacs>Error: connect ECONNREFUSED
02:10:29  * kazuponjoined
02:10:43  <isaacs>so, words from some guys here: core problem is that we're doing this in a signal handling thread
02:12:21  <bnoordhuis>we do? ah
02:12:27  <isaacs>yep, that's the problem
02:13:15  <isaacs>i'm heading home.
02:13:23  <bnoordhuis>then the most surprising thing is that it still works so often...
02:13:29  <isaacs>haha, indeed
02:13:39  <bnoordhuis>i'll see if i can fix it
02:13:51  <isaacs>kewl. thanks
02:18:39  <bnoordhuis>isaacs: for tonight/tomorrow: https://gist.github.com/bnoordhuis/8ad33765b178502598ad
02:27:01  * wavdedjoined
02:27:15  * mikealjoined
02:31:24  <wavded>amongst the various operating systems, are events queued in a similar fashion (e.g. FIFO), or does it depend on the OS?
02:31:46  * mikealquit (Read error: Connection reset by peer)
02:34:51  * pooyaquit (Quit: pooya)
02:37:15  * bnoordhu1sjoined
02:37:50  * bnoordhuisquit (Ping timeout: 255 seconds)
02:44:32  * mikealjoined
02:44:51  <bnoordhu1s>wavded: what kind of events do you mean?
02:45:01  * bnoordhu1schanged nick to bnoordhuis
02:45:17  <wavded>e.g. an incoming connection on a socket
02:45:31  <wavded>does the os keeps those ordered and hand them off to libuv?
02:45:54  <wavded>or does it libuv get the whole slew of them at once or (say if there was like 100 incoming connections at once)
02:50:48  * TooTallNatequit (Quit: Computer has gone to sleep.)
02:51:30  <bnoordhuis>wavded: the latter, more or less
02:51:34  <bnoordhuis>there's no strict ordering
02:51:49  <bnoordhuis>though operating systems will usually use something like a fifo
02:51:57  <bnoordhuis>but there's no guarantee
02:53:15  * mikealquit (Ping timeout: 252 seconds)
02:55:59  <wavded>bnoordhuis: no guarantee that you'll get the connections in the order they were received?
02:58:55  <bnoordhuis>wavded: nope
02:59:47  <bnoordhuis>why do you ask btw?
03:01:04  <wavded>bnoordhuis: that's a great question :)
03:01:58  <wavded>i am working on writing up some stuff for the event loop that may or may not end up in a node.js book and the tech guy (who is solid JAVA guy) is asking me a bit of questions about the internals and getting to a lot of things I have no clue about, so I ask you guys :)
03:08:18  <bnoordhuis>ah okay
03:08:28  <bnoordhuis>it's not particular to node / libuv btw
03:12:07  <bnoordhuis>okay, off to bed - sleep tight, guys
03:12:10  <wavded>yep, OS notifications seem to be used a lot of places
03:12:18  <wavded>bnoordhuis: ok, thanks for your help
03:16:37  * bnoordhuisquit (Ping timeout: 248 seconds)
03:21:40  * wavdedquit (Quit: wavded)
03:28:05  * mikealjoined
03:30:07  * kazuponquit (Remote host closed the connection)
03:32:43  * kazuponjoined
03:32:44  * c4milojoined
03:44:12  * qmxchanged nick to qmx|away
03:50:34  * TooTallNatejoined
03:59:28  * TooTallNatequit (Quit: Computer has gone to sleep.)
04:00:16  * brsonquit (Quit: leaving)
04:02:56  * kazuponquit (Remote host closed the connection)
04:04:53  * kazuponjoined
04:05:04  * TooTallNatejoined
04:05:25  * kazuponquit (Remote host closed the connection)
04:06:36  * kazuponjoined
04:06:55  * kazuponquit (Remote host closed the connection)
04:08:02  * kazuponjoined
04:17:36  * dominictarr_joined
04:21:07  * dominictarrquit (Ping timeout: 276 seconds)
04:21:08  * dominictarr_changed nick to dominictarr
04:22:44  * bnoordhuisjoined
04:25:03  * abraxasquit (Remote host closed the connection)
04:25:19  * TooTallNatequit (Quit: ["Textual IRC Client: www.textualapp.com"])
04:27:34  * bnoordhuisquit (Ping timeout: 272 seconds)
04:32:46  * abraxasjoined
04:37:50  <isaacs>hmm.... so, seems like it actually works if we do the SIGUSR1 handler in JS
04:37:57  <isaacs>which is a bit crazy, but whatever.
04:38:07  <tjfontaine>right because I bet we do a uv_async_send for it
04:38:12  <isaacs>yeah
04:38:24  <isaacs>bnoordhuis whipped up a little something, but it halts node if you use it
04:38:29  <isaacs>i don't really see why that should be
04:38:47  <isaacs>i could just look at what signal_wrap.cc is doing
04:39:21  <isaacs>code duplication vs c->js->c++ silliness
04:39:23  <tjfontaine>he was basically using the uv stuff for signal handling instead of node hooking itself
04:39:30  <isaacs>yeah
04:39:50  <tjfontaine>it looks like it should have been semantically the same as setting it up in js
04:41:48  <isaacs>yeah, seems that way
04:42:06  <isaacs>it was keeping other uv handles from getting unrefed for some reason, though
04:42:07  <isaacs>really odd
04:42:21  <tjfontaine>ah
04:42:21  <isaacs>ok, 1000 runs of simple/test-debugger-client
04:42:26  <isaacs>100% passing
04:42:33  <tjfontaine>excellent
04:42:47  <tjfontaine>I don't think the js sig handler is a bad compriomise
04:42:51  <isaacs>still failing debugger-repl, though:
04:42:52  <isaacs>node(33321) malloc: *** mmap(size=18446744072116768768) failed (error code=12)
04:42:53  <isaacs>*** error: can't allocate region
04:42:54  <isaacs>*** set a breakpoint in malloc_error_break to debug
04:43:10  <tjfontaine>er
04:43:13  * trevnorrisjoined
04:43:49  <isaacs>same as without the patch
04:44:44  <tjfontaine>that mmap region seems huge
04:46:24  * pooyajoined
04:47:23  <isaacs>yeah
04:47:37  <tjfontaine>what's the back trace of that?
04:48:03  <isaacs>i'm seeing that on master
04:48:17  <tjfontaine>ya but you're not getting a stack trace to go along with it? or a core?
04:49:59  <isaacs>no, doens't look that way
04:50:12  <trevnorris>isaacs: noticed you posted something about "Error: connect ECONNREFUSED"
04:50:13  <trevnorris>tjfontaine: shot in the dark, but think it might be related to that ticker patch?
04:50:13  <isaacs>honestly, i've forgotten how to debug programs on not-smartos
04:50:15  <isaacs>heh
04:50:23  <isaacs>trevnorris: unlikely
04:50:33  <isaacs>trevnorris: it was a zombie
04:50:38  <tjfontaine>isaacs: start it in gdb, best way
04:50:56  <tjfontaine>isaacs: gdb $(which node) ... r script
04:50:58  <isaacs>right, but it's the child proc that's dying, and my breakpoint doesn't apply to it or something
04:51:15  <tjfontaine>ah
04:51:32  <tjfontaine>set follow-fork-mode child
04:51:34  <tjfontaine>I think
04:52:22  * c4miloquit (Remote host closed the connection)
04:54:19  <isaacs>hm.. https://gist.github.com/5036002
04:55:01  <tjfontaine>blerg
04:55:31  <isaacs>setting to parent is no different
04:55:48  <tjfontaine>there's also an "ask"
04:55:59  <tjfontaine>in case there's multiple levels of indirection
04:57:28  <tjfontaine>you're getting this on osx?
04:57:48  <isaacs>yeah
04:58:02  <isaacs>it shows even when the test succeeds, actually
04:58:12  <tjfontaine>is this in a branch I can test?
04:58:43  <isaacs>tjfontaine: master
05:06:14  <tjfontaine>wtf that was certainly not happening before
05:11:35  <isaacs>maybe it was
05:11:42  <isaacs>it doesn't actually make the test fail
05:11:47  <isaacs>so we might have just not noticed
05:11:55  <isaacs>and even when the test does fail, it's just a debugger test, who cares?
05:13:50  <tjfontaine>hmm don't see it when I'm runnign with dtrace
05:14:18  <isaacs>oh, maybe it is only new since 3.14
05:14:44  <tjfontaine>that's what I'm thinking
05:16:33  <tjfontaine>it certainly isn't happening while I'm watching syscall::mmap:entry
05:18:07  <tjfontaine>oh actually
05:18:16  <tjfontaine>it doesn't fail when I run it with sudo of course
05:20:44  * mikealquit (Quit: Leaving.)
05:20:58  * mikealjoined
05:24:19  <isaacs>de9ee2a483012c0dc3fb48930c1e96baaa466b65 is the first bad commit
05:24:19  <isaacs>commit de9ee2a483012c0dc3fb48930c1e96baaa466b65
05:24:19  <isaacs>Author: Ben Noordhuis <[email protected]>
05:24:19  <isaacs>Date: Sun Feb 24 04:03:49 2013 +0100
05:24:21  <isaacs>deps: upgrade libuv to e89aced
05:26:27  <tjfontaine>https://developer.apple.com/library/mac/#documentation/performance/Conceptual/ManagingMemory/Articles/MallocDebug.html seems useful but I don't know what to read the files with
05:33:47  <MI6>joyent/node: isaacs master * 88befa6 : bench: Make http easier to profile Do not run the http/simple.js server - http://git.io/p7E29Q
05:39:36  * loladiroquit (Quit: loladiro)
05:50:53  * mikealquit (Quit: Leaving.)
06:01:53  * wolfeidauquit (Remote host closed the connection)
06:09:44  <tjfontaine>isaacs: I was really hoping that I was going to see that debugger was setting the process title :)
06:11:20  <tjfontaine>oh it may still be
06:23:18  * loladirojoined
06:28:53  * kazuponquit (Remote host closed the connection)
06:30:41  * trevnorrisquit (Quit: Leaving)
06:31:58  * kazuponjoined
06:33:12  * mikealjoined
06:36:19  * AvianFluquit (Remote host closed the connection)
06:37:53  * mikealquit (Ping timeout: 248 seconds)
06:41:19  * csaohjoined
06:42:54  * nodejs-cijoined
06:43:22  * csaohquit (Client Quit)
06:44:58  <tjfontaine>nodejs-ci: help
06:45:06  <tjfontaine>interesting
06:45:33  * benoitcquit (Excess Flood)
06:54:02  * benoitcjoined
06:57:35  * dominictarrquit (Quit: dominictarr)
07:04:04  * mikealjoined
07:09:06  * mikealquit (Ping timeout: 264 seconds)
07:10:01  <nodejs-ci>Project nodejs-v0.8 » x64,linux build #2:FAILURE in 22 min: http://jenkins.nodejs.org/job/nodejs-v0.8/./DESTCPU=x64,label=linux/2/
07:10:01  <nodejs-ci>Failed tests:
07:10:16  <tjfontaine>wtg there jenkins
07:20:33  <nodejs-ci>Project nodejs-v0.8 » ia32,linux build #2:FAILURE in 33 min: http://jenkins.nodejs.org/job/nodejs-v0.8/./DESTCPU=ia32,label=linux/2/
07:20:33  <nodejs-ci>Failed tests:
07:21:24  * indexzerojoined
07:26:05  * rendarjoined
07:35:34  * mikealjoined
07:37:11  * pooyaquit (Quit: pooya)
07:39:18  * tellnesquit (*.net *.split)
07:39:18  * chobiequit (*.net *.split)
07:39:18  * pquernaquit (*.net *.split)
07:39:47  * mikealquit (Ping timeout: 246 seconds)
07:40:36  * mikealjoined
07:46:25  <indutny>hoya
07:46:33  <indutny>tjfontaine: so you guys have touched v8ustack.d?
07:51:05  * tellnesjoined
07:51:05  * chobiejoined
07:51:05  * pquernajoined
08:00:01  * Raltquit (Ping timeout: 248 seconds)
08:03:54  * Raltjoined
08:08:58  * indexzeroquit (Quit: indexzero)
08:16:56  * `3rdEdenjoined
08:18:05  <MI6>joyent/node: Fedor Indutny master * aa98539 : v8: fix postmortem and dtrace helper build Regardless of previous @bnoor (+1 more commits) - http://git.io/C6lrmQ
08:19:09  <indutny>ircretary: tell bnoordhuis that it was not wise to revert all code that I spent weeks on
08:19:09  <ircretary>indutny: I'll be sure to tell bnoordhuis
08:35:10  * csaohjoined
09:12:57  * loladiroquit (Quit: loladiro)
09:45:03  * loladirojoined
09:52:56  * loladiroquit (Quit: loladiro)
10:03:44  * kazuponquit (Remote host closed the connection)
10:04:11  * wolfeidaujoined
10:05:16  * kazuponjoined
10:07:41  * kazuponquit (Remote host closed the connection)
10:15:07  * hzjoined
10:22:44  * Raltquit (Ping timeout: 252 seconds)
10:25:14  * Raltjoined
10:27:58  <csaoh>hello, I have an issue with travis while compiling libuv. I get the following message: "/usr/bin/ld: libuv/libuv.a(async.o): relocation R_X86_64_32 against `.rodata' can not be used when making a shared object; recompile with -fPIC"
10:28:14  <csaoh>and turns out i get the same thing when trying on a x64 ubuntu
10:28:18  <indutny>I bet you're using makefile?
10:28:26  <csaoh>i got it fixed by adding -fPIC to makefile
10:28:28  <csaoh>yup
10:28:32  <csaoh>shouldn't I ?
10:28:41  <indutny>well, gyp is more supported
10:28:52  <indutny>but I'll try to fix makefile today
10:28:57  <indutny>seen it before too
10:29:30  <csaoh>great !
10:35:55  * hzquit (Disconnected by services)
10:35:58  * hzjoined
10:49:23  <csaoh>actually, just adding -fPIC to CFLAGS works, but I guess there has to be a less dirty way. Would you mind pinging me when you're on it ? thanks !
10:49:44  <indutny>well, I'll just to do the same
10:49:46  <indutny>but in makefile
10:52:30  * abraxasquit (Remote host closed the connection)
10:56:24  <csaoh>yep
11:18:28  * kazuponjoined
11:23:54  * kazuponquit (Ping timeout: 276 seconds)
11:28:23  * csaohquit (Quit: csaoh)
11:39:56  <dostoyevsky>Is there a way to use timers for each socket? So I could do somehting like: Write request to a server and then set a timer that will be fired if there is no response within the time limit. Or are timers always global and I would need to check for the timeouts myself by iterating over all sockets that I am using?
11:45:33  <dostoyevsky>I think If I were to use uv_timer_start() & al I could just use one uv_timer_t per connection and then have what I wanted... Can one use timeouts like 1-2ms with that interface?
11:47:02  <indutny>1-2ms is not really good thing
11:47:06  <indutny>though you can do it
11:47:24  <dostoyevsky>ok... we have low latency requirements
11:47:41  <indutny>I'm not sure what's exact precision, but I guess it my deviate a little bit out of it
11:47:44  <indutny>sometimes
11:47:58  <indutny>especially considering that you are doing some work in this thread
11:48:02  <dostoyevsky>Yeah, timers are very difficult on cpus AFAIU
11:48:07  <indutny>obviously
11:48:22  <indutny>so... you can either create one timer per connection
11:48:34  <indutny>or use one timer
11:48:37  <indutny>and rearm it periodically
11:49:00  * benoitcquit (Excess Flood)
11:49:01  <indutny>but you'll need to do a some book-keeping to figure out which connections was timed-out
11:49:18  <indutny>second way is the way we've chosen in node.js
11:49:43  <indutny>but you can still do it the simple way
11:50:51  <dostoyevsky>indutny: Ok... maybe I start simple and then see if I could do it globally.. I just fear that iteration over the active connections just slows things down and libuv might be more efficient internally.. but maybe not really
11:50:56  <indutny>yep
11:51:03  * benoitcjoined
11:51:12  <indutny>do not optimize prematurely
11:51:24  <indutny>have I answered your question, anyway?
11:51:34  <dostoyevsky>indutny: I think so :)
11:52:45  <indutny>good
11:56:10  * csaohjoined
12:19:30  <csaoh>i keep getting the "Assertion failed: (ngx_queue_empty(&loop->wq) && "thread pool work queue not empty!"), function uv__loop_delete, file src/unix/loop.c, line 108." message… obviously, looks like i forgot to delete or to stop something… is there a way to know what is it exactly ?
12:26:22  <indutny>interesting
12:47:43  <csaoh>the weird thing is that i haven't initialized any threads… i use timers and polls, but I'd say I stop them all...
13:06:20  <saghul>any fs operations?
13:08:08  <csaoh>yes
13:08:12  <csaoh>lots of them
13:08:49  <indutny>hm...
13:08:51  <indutny>interesting
13:08:54  <csaoh>fs_open, fs_read, fs_stat, fs_write, etc
13:09:08  <indutny>can you create a reduced test case to reproduce this problem?
13:09:13  <indutny>or just test case
13:09:57  <saghul>csaoh those run on the threadpool, any chance any of them is not done when you delete the loop?
13:10:48  <csaoh>hmmm that's some great leads, trying to reduce it now
13:19:12  <csaoh>seems to happen when i call fs_open and then either fs_write or fs_read on it
13:19:34  * karupaneruraquit (Excess Flood)
13:20:46  * karupanerurajoined
13:32:13  * philips_quit (Excess Flood)
13:35:13  * karupaneruraquit (Excess Flood)
13:35:21  * karupanerurajoined
13:36:56  <indutny>from fs_open's callback?
13:41:30  <csaoh>uyep
13:41:53  <csaoh>but i'm realizing i might have a problem elsewhere aswell
13:49:29  * philips_joined
13:50:00  * qmx|awaychanged nick to qmx
13:51:01  * bnoordhuisjoined
13:52:59  * kazuponjoined
13:53:47  <csaoh>alright, i guess i got it
13:54:30  <csaoh>i use a loop of uv_run_once instead of uv_run, and i guess the loop just ended too soon
14:00:57  * kazuponquit (Remote host closed the connection)
14:10:45  * `3rdEdenchanged nick to `3E|BRB
14:19:14  <MI6>joyent/node: Ben Noordhuis master * d4a297c : http: fix case in 505 response status line Fixes #4850. - http://git.io/ph-6bA
14:27:14  <bnoordhuis>is github broken?
14:27:38  <bnoordhuis>i can't push to any repos anymore
14:28:22  <bnoordhuis>and it works again...
14:28:30  <MI6>joyent/libuv: Saúl Ibarra Corretgé master * ae2b30a : windows: initialize stop_flag explicitly The default loop lives in the b - http://git.io/yESmlw
14:34:06  <MI6>joyent/node: Timothy J Fontaine master * 8fe72a7 : build: automatically add tag for nightly builds - http://git.io/tChj8g
14:36:54  * kazuponjoined
14:46:09  * loladirojoined
14:56:11  * c4milojoined
14:57:57  * TheJHjoined
15:20:56  * AvianFlujoined
15:22:13  * `3E|BRBchanged nick to `3rdEden
15:26:42  * mikealquit (Quit: Leaving.)
15:35:47  * pooyajoined
15:36:47  * bradleymeckjoined
15:40:37  * loladiroquit (Quit: loladiro)
15:43:16  * kazuponquit (Remote host closed the connection)
15:45:58  * pooyaquit (Quit: pooya)
15:49:31  <indutny>bnoordhuis: hey ben
15:49:41  <indutny>bnoordhuis: have you seen my revert revert commit?
15:51:42  <txdv>bnoordhuis: any comments on my udp pull request?
15:54:02  <bnoordhuis>indutny: eh, the dtrace thing?
15:54:06  <indutny>yes
15:54:15  <bnoordhuis>right. you beat me to it
15:54:31  <bnoordhuis>txdv: what udp pr?
15:55:04  <txdv>https://github.com/joyent/libuv/pull/708
15:56:44  <bnoordhuis>txdv: looks okay to me, i think
15:56:51  <bnoordhuis>did you test the windows changes?
15:57:16  <txdv>yes I did
15:57:19  <txdv>on windows8
15:57:36  <txdv>and I posted an issue where there are test failures on windows8
15:57:49  <txdv>but this pr doesn't add any more errors
15:58:38  <MI6>joyent/libuv: Andrius Bentkus master * c5101ae : unix, windows: add common uv_udp_* error checking - http://git.io/Im1EbA
15:59:11  <bnoordhuis>txdv: ^
15:59:27  <txdv>thanks
15:59:50  <bnoordhuis>#v8 must be the deadest channel i know
16:00:03  <bnoordhuis>i think the last time someone said something was 7 days ago
16:00:35  <bnoordhuis>also, sometimes i ramble on like an old man
16:00:52  <txdv>"back in the the days javascript used to be slow..."
16:01:42  * Raltquit (Ping timeout: 272 seconds)
16:02:21  * pooyajoined
16:03:45  <MI6>joyent/node: Andrei Sedoi master * 17c6fe2 : mips: fix openssl build - http://git.io/WYodlA
16:04:51  * Raltjoined
16:05:36  * mikealjoined
16:07:56  <MI6>joyent/node: Timothy J Fontaine master * 17a8126 : test: optionally set common.PORT via env variable - http://git.io/6FZuEQ
16:15:35  * `3rdEdenchanged nick to `3E|BRB
16:15:56  <indutny>good
16:16:06  <indutny>tjfontaine: is CI coming soon?
16:16:13  <indutny>I mean I seen it working for 0.8
16:16:16  <indutny>but not for master
16:20:07  * c4miloquit (Remote host closed the connection)
16:21:13  <bnoordhuis>(gdb) p sizeof("__CF_USER_TEXT_ENCODING=0x1F5:0:0") - 1
16:21:13  <bnoordhuis>You can't do that without a process to debug.
16:21:16  <bnoordhuis>^ why not?
16:21:28  <bnoordhuis>silly debugger is silly
16:29:55  <bradleymeck>is there some configure option im not seeing that activates _third_party_main.js instead of me readding it on every checkout?
16:31:07  * c4milojoined
16:32:41  * mikealquit (Quit: Leaving.)
16:33:42  * loladirojoined
16:34:18  <bnoordhuis>bradleymeck: no, none
16:34:32  * bradleymeckscampers off
16:35:01  * loladiroquit (Read error: Operation timed out)
16:37:20  <bnoordhuis>:)
16:38:05  <indutny>bnoordhuis: tell that to mdb
16:38:16  <indutny>bnoordhuis: it can't even read dwarf info to inspect stack frames
16:39:51  * bradleymeckquit (Quit: bradleymeck)
16:40:14  <bnoordhuis>indutny: tell what to mdb?
16:40:28  <indutny>"You can't do that without a process to debug."
16:40:32  <indutny>this was about this
16:40:37  <bnoordhuis>ah right
16:40:51  <bnoordhuis>the last thing i told mdb was "i'm leaving you for someone younger and more dynamic"
16:40:57  <bnoordhuis>and that was gdb, mind you
16:41:04  <bnoordhuis>that's saying something, right?
16:41:46  <indutny>yep
16:42:08  <indutny>they claim mdb to be production debugger
16:42:13  <indutny>which is good too
16:42:44  * pooyaquit (Quit: pooya)
16:45:34  * bradleymeckjoined
16:47:57  <bnoordhuis>the merengue cover of deep purple's "smoke on the water", it's really something
16:48:15  <indutny>yep
16:48:36  <bnoordhuis>if my career as a programmer doesn't work out, that's what i'm going to do - start a cover band
16:50:56  <indutny>invite me
16:51:12  <bnoordhuis>indutny: you play the piano right?
16:51:18  <indutny>I play everything
16:51:21  <indutny>but yes
16:51:30  <indutny>piano is main specialization
16:51:33  <bnoordhuis>cool. i'll reserve a spot for you
16:51:33  * dapjoined
16:51:46  <indutny>ok
16:51:51  <indutny>does bert play on any instrument?
16:52:00  <bnoordhuis>he does, the saxophone :)
16:53:43  * kazuponjoined
16:55:02  <isaacs>bnoordhuis: So, that sig handler debugger deadlock thing..
16:55:10  <isaacs>bnoordhuis: your patch makes node break in oddball ways.
16:55:51  <isaacs>bnoordhuis: i duct-taped together a "expose EnableDebug to JS, and set up the signal handler in src/node.js" approach, which actually passes the debugger client test 1000 times without fail.
16:55:55  <bnoordhuis>isaacs: whatever that patch does, at least is less wrong than the current behavior :)
16:56:09  <isaacs>bnoordhuis: yes, the fact that the current one works is kinda mysterious
16:56:25  <isaacs>bnoordhuis: and probably wrong.
16:56:31  <bnoordhuis>very much so
16:56:45  <isaacs>bnoordhuis: but i am confused as to why it's causing libuv to hold onto refs to the child proc and debugger client socket.
16:56:57  <isaacs>bnoordhuis: (your patch, i mean)
16:57:11  <bnoordhuis>hm, it might be because i don't unref the uv_signal_t
16:57:21  <bnoordhuis>(it was a quickie patch, not extensively tested)
16:57:26  <isaacs>bnoordhuis: clearly :)
16:57:46  <isaacs>bnoordhuis: you sent it after saying you were heading to bed. the fact that it builds was impressive :)
16:58:08  <isaacs>going through JS for this feels a bit klunky, but it's probably not the worst thign ever.
16:58:16  <isaacs>not like "start the debugger" is a hot path or anythign
16:58:23  * kazuponquit (Ping timeout: 260 seconds)
16:58:32  <isaacs>and then we're using the same code paths as the much more extensively tested `process.on('SIGWHATEVER')` code
16:59:14  <isaacs>it would also open the door to having userland code do it differently
16:59:27  <isaacs>ie, maybe you want to start the debugger on a different signal than SIGUSR1 or somethign
16:59:53  <bnoordhuis>sure. if you can make it work, i'm fine with that
17:01:39  * qmxchanged nick to qmx|lunch
17:03:13  * TooTallNatejoined
17:03:18  * mikealjoined
17:04:30  <isaacs>k, i'll clean up that patch and get it in today.
17:04:38  <tjfontaine>bnoordhuis: btw re: 4847 (malloc osx child proc) the issue goes away when I try to observe with dtrace (which requires sudo)
17:04:40  <isaacs>0.9.11 can have passing debugger tests :)
17:04:52  <tjfontaine>glorious days ahead
17:04:53  <isaacs>tjfontaine: oh, that's hapening on smartos as well?
17:05:00  <isaacs>tjfontaine: or you mean dtrace on osx
17:05:13  <tjfontaine>dtrace on osx
17:06:06  <bnoordhuis>tjfontaine: that's because tracing with dtrace changes the env
17:06:12  <bnoordhuis>the reduced env is what's the issue here
17:06:24  * brsonjoined
17:06:27  <bnoordhuis>it's pretty easy to fix really, i'll commit a patch later today
17:06:37  <tjfontaine>ah, I didn't realize dtrace would muck with the env there
17:06:54  <tjfontaine>I just chalked it up to "sudo lets me mmap whatever the hell I want" :P
17:10:35  <nodejs-ci>Project nodejs-master » ia32,smartos build #6:ABORTED in 4 min 52 sec: http://jenkins.nodejs.org/job/nodejs-master/./DESTCPU=ia32,label=smartos/6/
17:12:04  <tjfontaine>lets see how things go with parallel builds now
17:12:55  <indutny>woot
17:13:25  <tjfontaine>indutny: in short ci is indeed coming
17:14:08  * mikealquit (Ping timeout: 252 seconds)
17:14:25  <bnoordhuis>tjfontaine: are you running test and benchmarks as part of each build?
17:14:46  <bnoordhuis>or "are you going to run"
17:14:59  <tjfontaine>tests for each build, I'm not entirely sure how benchmarks are going to shake out just yet
17:15:16  <tjfontaine>as you saw from your merge I'm also planning on a full nightly which will run the pummel, gc, net tests
17:15:25  <bnoordhuis>nice
17:15:32  <tjfontaine>and then package and upload
17:15:38  <bnoordhuis>but being able to track perf regressions to a single commit would be nice too
17:15:46  <tjfontaine>yup, it's certainly coming
17:16:08  <tjfontaine>bench by commit by platform
17:16:20  <tjfontaine>back probably to the v0.9 branch
17:17:54  <bnoordhuis>that would be sweet
17:18:09  <indutny>bnoordhuis: https://github.com/bnoordhuis/node/commit/3c2c08e
17:18:12  <indutny>this looks good to me
17:18:16  <indutny>much better than my PR
17:18:39  <nodejs-ci>Project nodejs-master » ia32,smartos build #7:FAILURE in 7 min 14 sec: http://jenkins.nodejs.org/job/nodejs-master/./DESTCPU=ia32,label=smartos/7/
17:18:40  <nodejs-ci>Failed tests:
17:19:02  * csaohquit (Quit: csaoh)
17:19:07  <tjfontaine>blah 29 failures
17:19:16  <nodejs-ci>Project nodejs-master » x64,smartos build #7:FAILURE in 7 min 51 sec: http://jenkins.nodejs.org/job/nodejs-master/./DESTCPU=x64,label=smartos/7/
17:19:17  <nodejs-ci>Failed tests:
17:19:48  * trevnorrisjoined
17:19:57  <tjfontaine>long and the short of it, still a few more places to guard against multiple test suites running at the same time http://jenkins.nodejs.org//job/nodejs-master/DESTCPU=x64,label=smartos/7//tapTestReport/test.tap-278/
17:24:50  <bnoordhuis>indutny: want me to land it?
17:25:26  <bnoordhuis>tjfontaine: i was thinking about that. it would be nice to be able to run tests in parallel because the test suite takes several minutes to complete now
17:25:41  <bnoordhuis>easier said than done though
17:25:43  <tjfontaine>well, that's a separate thing, but it would be nice to have as well
17:25:45  <bnoordhuis>but now we have you!
17:25:48  <tjfontaine>hehe
17:26:04  <tjfontaine>I mean running the testsuite twice on the same machine (in different paths)
17:26:19  <bnoordhuis>yeah, won't work because of tcp ports
17:26:22  <indutny>bnoordhuis: yes
17:26:30  <bnoordhuis>indutny: okay, one sec
17:26:47  <tjfontaine>bnoordhuis: well that's what that common.PORT change was to start, last night things were looking good on my mac, but today smartos disagrees
17:27:49  <MI6>joyent/node: Ben Noordhuis master * c80bde1 : v8: work around String::WriteAscii segfault See http://code.google.com/p - http://git.io/F3Z6Zg
17:27:54  <bnoordhuis>indutny: ^
17:27:58  <indutny>good
17:28:40  <bnoordhuis>tjfontaine: how come? it looked to me like it should Just Work(TM)
17:28:53  <tjfontaine>512mb, -j4 x 2, c++ this probably isn't a good recipe
17:29:05  <tjfontaine>bnoordhuis: dunno, but a lot of smartos tests failed with EADDRINUSE
17:29:33  <bnoordhuis>are you sure the NODE_COMMON_PORT env var is getting through?
17:29:42  <tjfontaine>not entirely
17:29:49  <tjfontaine>it seemed to work last night
17:29:58  <bnoordhuis>i know that feeling :)
17:30:07  <tjfontaine>if [ "$DESTCPU" = "ia32" ]; then NODE_COMMON_PORT=10000; else NODE_COMMON_PORT=2000; fi; echo $NODE_COMMON_PORT; python tools/test.py --mode=release --progress=tap simple message < /dev/null | tee test.tap
17:30:17  <tjfontaine>I added the echo this morning and will requeue here in a second
17:30:23  <bnoordhuis>export?
17:30:41  <bnoordhuis>as in export NODE_COMMON_PORT=1337
17:30:42  <tjfontaine>I suppose it may not be making it through the levels
17:31:05  <nodejs-ci>Project nodejs-master » x64,linux build #7:ABORTED in 19 min: http://jenkins.nodejs.org/job/nodejs-master/./DESTCPU=x64,label=linux/7/
17:31:06  <nodejs-ci>Project nodejs-master » ia32,linux build #7:ABORTED in 19 min: http://jenkins.nodejs.org/job/nodejs-master/./DESTCPU=ia32,label=linux/7/
17:32:18  <trevnorris>bnoordhuis: have you ever gotten an answer on #v8? I usually have to jump into #chromium for any v8 questions.
17:33:35  <CoverSlide>I usually just get answers to questions about carrot juice
17:37:11  <bnoordhuis>trevnorris: i don't think i've ever asked a question in #v8, just answered them
17:37:21  <tjfontaine>haha
17:37:34  <bnoordhuis>#chromium is way too chatty btw, i can't stomach it
17:37:48  <tjfontaine>that's why I barely pay attention to #node.js :P
17:38:17  <bnoordhuis>yeah, ditto. thought #node.js is at least somewhat relevant to my interests
17:38:24  <tjfontaine>indeed
17:38:30  <bnoordhuis>but #chromium? i use firefox for $DEITY's sake
17:38:39  <tjfontaine>good god, today is promotional email day
17:39:19  <bnoordhuis>oh? do tell
17:39:43  <tjfontaine>nothing just a bunch of emails for hotels and flights and what not
17:39:44  <indutny>bnoordhuis: a question
17:39:52  <indutny>what does a??(0??) mean
17:40:04  <indutny>in C
17:40:15  <bnoordhuis>err, some more context, please?
17:40:17  <indutny>or my favourite one
17:40:23  <indutny>a??!b
17:40:38  <indutny>are you aware of trigrams and digrams?
17:40:42  <indutny>err
17:40:44  <indutny>trigraphs/digraphs
17:40:47  <bnoordhuis>are you talking about digraphs/trigraphs?
17:40:49  <indutny>http://en.wikipedia.org/wiki/Digraphs_and_trigraphs#C
17:40:51  <indutny>yeah
17:40:55  <indutny>quite interesting, isn't it
17:41:00  <indutny>I should definitely use them
17:41:04  <bnoordhuis>no, it's moronic
17:41:05  <indutny>in my next patch for libuv
17:41:14  <bnoordhuis>the people who thought them up should be taken outside and shot
17:41:16  <indutny>wtf??! 0
17:41:26  <indutny>bnoordhuis: they had no keyboards
17:41:35  <indutny>actually, they had no { } keys
17:41:39  <bnoordhuis>indeed
17:41:57  <bnoordhuis>so instead of having those people go to the store and spend $10 on a decent keyboard
17:42:02  <tjfontaine>hah
17:42:05  <bnoordhuis>they came up with {di,tri}graphs
17:42:34  <bnoordhuis>good thing gcc disables them by default
17:42:45  <indutny>aha
17:42:57  * pooyajoined
17:44:25  <MI6>joyent/node: [email protected] master * cfacde3 : v8: Hardfloat does not imply VFPv3, only VFPv2. Raspberry Pi is an examp - http://git.io/ME71SA
17:45:17  * mikealjoined
17:46:01  <bnoordhuis>man, i'm starting to look like TooTallNate - my hair is long enough to tie into a ponytail
17:46:13  <TooTallNate>:D
17:47:47  <nodejs-ci>Project nodejs-master » ia32,smartos build #8:STILL FAILING in 15 min: http://jenkins.nodejs.org/job/nodejs-master/./DESTCPU=ia32,label=smartos/8/
17:47:48  <nodejs-ci>info: v8: work around String::WriteAscii segfault
17:47:48  <nodejs-ci>Failed tests:
17:48:01  <nodejs-ci>Project nodejs-master » x64,smartos build #8:STILL FAILING in 15 min: http://jenkins.nodejs.org/job/nodejs-master/./DESTCPU=x64,label=smartos/8/
17:48:02  <nodejs-ci>info: v8: work around String::WriteAscii segfault
17:48:02  <nodejs-ci>Failed tests:
17:48:18  <tjfontaine>bnoordhuis: ok the export made things better
17:49:01  <tjfontaine>x64 had a debugger failure, and they both failed test-http-server-stale-close.js
17:49:03  * TheJHquit (Quit: goodbye)
17:50:08  <bnoordhuis>tjfontaine: ignore the debugger tests, they're not very reliable
17:50:15  <bnoordhuis>the http test should work though, i think
17:50:26  <trevnorris>tjfontaine: just curious. say there's a random problem that causes all tests to fail (forgot a semicolon or some such). will nodejs-ci spew out all tests?
17:50:32  <tjfontaine>nod, I've grown to ignore the debugger tests, though I have hope that isaacs will fix it all up
17:51:04  <tjfontaine>trevnorris: probably, depends, right now jenkins isn't display the test failures here anyway :)
17:51:26  <tjfontaine>(at least in irc)
17:52:49  <tjfontaine>bnoordhuis: I can't get that test-http-server-stale-close to reproduce manually
17:54:11  <tjfontaine>ah, NODE_TEST_FORK=1 ./node test/simple/test-http-server-stale-close.js
17:54:15  <tjfontaine>that fails reliably
17:54:55  <trevnorris>bnoordhuis, indutny: you know if there's much perf gain in doing if (!some_undefiend_var) vs if (some_undefined_var === undefined)?
17:55:02  <nodejs-ci>Project nodejs-master » x64,linux build #8:FAILURE in 22 min: http://jenkins.nodejs.org/job/nodejs-master/./DESTCPU=x64,label=linux/8/
17:55:03  <nodejs-ci>info: v8: work around String::WriteAscii segfault
17:55:03  <nodejs-ci>Failed tests:
17:55:04  <nodejs-ci>Project nodejs-master » ia32,linux build #8:FAILURE in 22 min: http://jenkins.nodejs.org/job/nodejs-master/./DESTCPU=ia32,label=linux/8/
17:55:05  <nodejs-ci>info: v8: work around String::WriteAscii segfault
17:55:05  <nodejs-ci>Failed tests:
17:55:06  <indutny>I'm not aware of this
17:55:08  <bnoordhuis>as of today, i have as many strace patches in as andi kleen
17:55:09  <bnoordhuis> 2 Andi Kleen
17:55:09  <bnoordhuis> 2 Ben Noordhuis
17:55:18  <tjfontaine>heh
17:55:19  <bnoordhuis>okay, not spectacular but still
17:55:51  <tjfontaine>linux failed the same test bnoordhuis
17:57:06  <bnoordhuis>tjfontaine: it's spawning a child process. i suspect it's not copying the env
17:57:22  <bnoordhuis>which is something we should fix in node but backwards compatibility, you know?
17:57:22  <tjfontaine>same bug as the osx issue?
17:57:46  <bnoordhuis>not quite - let's say same family
17:58:06  <tjfontaine>heh
17:58:43  <bnoordhuis>trevnorris: i believe false-y checks are slightly faster but it's probably a wash in the grand scheme of things
17:59:10  <bnoordhuis>trevnorris: also, i haven't benchmarke that in ages so i might be wrong
17:59:15  <bnoordhuis>*benchmarked
17:59:54  <trevnorris>yeah. hydrogen probably does type checking anyways, and if it's consistently undefined it probably doesn't do much anyways.
18:00:12  * qmx|lunchchanged nick to qmx
18:02:27  <trevnorris>i just usually favor typeof checks where I can because it never deopt's regardless of type, and still super fast.
18:03:29  * brsonquit (Ping timeout: 246 seconds)
18:03:39  * loladirojoined
18:04:58  * bradleymeckquit (Quit: bradleymeck)
18:07:44  <bnoordhuis>trevnorris: yeah, you can't go wrong with typeof checks
18:07:51  <bnoordhuis>v8 likes strong typing, the more, the merrier
18:08:08  * loladiroquit (Client Quit)
18:09:54  * `3E|BRBchanged nick to `3rdEden
18:12:52  * brsonjoined
18:13:30  <bnoordhuis>tjfontaine: https://gist.github.com/bnoordhuis/b34470aba1d1c4a0f864 <- does that work for you?
18:16:13  <tjfontaine>that doesn't seem to fix it when I run it from the command line
18:16:50  <tjfontaine>but it would generally be run from the python test suite via the jenkins env
18:19:05  <tjfontaine>bnoordhuis: I'm setting up a one off job to test, so gimmie a second
18:31:09  * loladirojoined
18:34:14  * loladiroquit (Client Quit)
18:37:18  <tjfontaine>bnoordhuis: that seems to fix it
18:37:38  <bnoordhuis>presumably there are more tests that are affected by it
18:37:51  <bnoordhuis>but i guess we'll fix them on a case-by-case basis
18:37:57  <tjfontaine>more than likely, it sounds like a problem for jenkins really
18:39:47  <bnoordhuis>no, it's a bug/feature in node
18:40:11  <bnoordhuis>when you call child_process.spawn(process_name, args, {env:env}) it overwrites the env instead of merging it
18:40:30  <bnoordhuis>it's daft really but backwards compatibility eh?
18:42:54  <MI6>joyent/node: Ben Noordhuis master * e505f91 : test: merge environment, don't overwrite The CI system requires that som - http://git.io/P5peNw
18:47:46  <tjfontaine>lets see if we get a green board :)
18:48:00  * loladirojoined
18:50:40  <MI6>joyent/node: Ben Noordhuis master * e505f91 : test: merge environment, don't overwrite The CI system requires that som (+2 more commits) - http://git.io/JLm52A
18:51:46  <MI6>joyent/node: Ben Noordhuis master * e505f91 : test: merge environment, don't overwrite The CI system requires that som (+2 more commits) - http://git.io/JLm52A
18:51:49  <bnoordhuis>um
18:51:59  <tjfontaine>those were isaacs playing with github for me
18:52:03  <bnoordhuis>ah okay
18:53:03  <MI6>joyent/node: Ben Noordhuis master * e505f91 : test: merge environment, don't overwrite The CI system requires that som (+2 more commits) - http://git.io/JLm52A
18:53:25  <isaacs>weird.
18:53:50  <MI6>joyent/libuv: Andrius Bentkus master * c5101ae : unix, windows: add common uv_udp_* error checking (+2 more commits) - http://git.io/9hWK5A
18:53:53  <isaacs>there we go
18:55:20  * roxlupart
19:00:36  <nodejs-ci>Yippie, build fixed!
19:00:36  <nodejs-ci>Project nodejs-master » ia32,smartos build #9:FIXED in 14 min: http://jenkins.nodejs.org/job/nodejs-master/./DESTCPU=ia32,label=smartos/9/
19:00:37  <nodejs-ci>* info: v8: Hardfloat does not imply VFPv3, only VFPv2.
19:00:37  <nodejs-ci>* info: test: merge environment, don't overwrite
19:00:51  <nodejs-ci>Project nodejs-master » x64,smartos build #9:STILL FAILING in 14 min: http://jenkins.nodejs.org/job/nodejs-master/./DESTCPU=x64,label=smartos/9/
19:00:52  <nodejs-ci>* info: v8: Hardfloat does not imply VFPv3, only VFPv2.
19:00:53  <nodejs-ci>* info: test: merge environment, don't overwrite
19:00:53  <nodejs-ci>Failed tests:
19:01:21  * qmxchanged nick to qmx|errands
19:07:26  <nodejs-ci>Project nodejs-master » x64,linux build #9:STILL FAILING in 21 min: http://jenkins.nodejs.org/job/nodejs-master/./DESTCPU=x64,label=linux/9/
19:07:26  <nodejs-ci>* info: v8: Hardfloat does not imply VFPv3, only VFPv2.
19:07:27  <nodejs-ci>* info: test: merge environment, don't overwrite
19:07:27  <nodejs-ci>Failed tests:
19:08:21  <nodejs-ci>Project nodejs-master » ia32,linux build #9:STILL FAILING in 22 min: http://jenkins.nodejs.org/job/nodejs-master/./DESTCPU=ia32,label=linux/9/
19:08:22  <nodejs-ci>* info: v8: Hardfloat does not imply VFPv3, only VFPv2.
19:08:22  <nodejs-ci>* info: test: merge environment, don't overwrite
19:08:23  <nodejs-ci>Failed tests:
19:12:43  * bradleymeckjoined
19:14:19  * `3rdEdenquit (Quit: (╯°□°)╯︵ ┻━┻ Gonna spend time with <3'd 1's)
19:22:19  * mikealquit (Quit: Leaving.)
19:31:28  <MI6>joyent/node: Ben Noordhuis master * 7bc449c : deps: upgrade libuv to a0c1d84 - http://git.io/nJoRiQ
19:31:30  <MI6>joyent/libuv: Ben Noordhuis master * a0c1d84 : linux, darwin: don't touch environ in uv_setup_args Don't overwrite the - http://git.io/ERYF1g
19:31:46  * loladiroquit (Quit: loladiro)
19:52:36  * mikealjoined
19:56:49  * mikealquit (Ping timeout: 248 seconds)
20:00:14  <nodejs-ci>Project nodejs-master » x64,smartos build #10:STILL FAILING in 9 min 23 sec: http://jenkins.nodejs.org/job/nodejs-master/./DESTCPU=x64,label=smartos/10/
20:00:15  <nodejs-ci>info: deps: upgrade libuv to a0c1d84
20:00:15  <nodejs-ci>Failed tests:
20:00:33  <tjfontaine>debugger failure
20:00:33  * skebcioquit (Quit: No Ping reply in 180 seconds.)
20:01:43  * skebciojoined
20:01:45  <nodejs-ci>Project libuv-master » smartos build #4:STILL FAILING in 5 min 24 sec: http://jenkins.nodejs.org/job/libuv-master/./label=smartos/4/
20:01:45  <nodejs-ci>* info: windows: initialize stop_flag explicitly
20:01:46  <nodejs-ci>* info: unix, windows: add common uv_udp_* error checking
20:01:46  <nodejs-ci>* info: linux, darwin: don't touch environ in uv_setup_args
20:01:47  <nodejs-ci>Failed tests:
20:02:03  <indutny>tjfontaine: will it like spam us like this for every commit?
20:02:11  * AvianFluquit (Remote host closed the connection)
20:02:21  <indutny>I'm not sure what others think about it, but I think one line would be enough to get into the problem
20:02:34  <indutny>especially, considering that it has a link inside it
20:02:43  <tjfontaine>indutny: guess you better fix the tests, but in reality it only spews on failures
20:03:02  <indutny>heh
20:03:05  <indutny>true
20:04:00  <tjfontaine>it's going to be less loud moving forward, but the frustrating thing is that it's not even telling us the test(s) that failed
20:04:17  <trevnorris>not sure what others think, but might be nice if slurp filtered those.
20:06:10  * AvianFlujoined
20:06:12  <tjfontaine>does slurp log channel notices?
20:06:41  <trevnorris>doesn't appear to
20:07:15  <tjfontaine>that could be an alternative solution
20:07:20  <trevnorris>fine w/ me.
20:07:49  <trevnorris>just anything to make catching up on irc logs less noisy.
20:07:54  * bnoordhuisquit (Ping timeout: 264 seconds)
20:09:19  * pooyaquit (Quit: pooya)
20:12:49  <nodejs-ci>Project nodejs-master » x64,linux build #10:STILL FAILING in 21 min: http://jenkins.nodejs.org/job/nodejs-master/./DESTCPU=x64,label=linux/10/
20:12:49  <nodejs-ci>info: deps: upgrade libuv to a0c1d84
20:12:50  <nodejs-ci>Failed tests:
20:13:30  <indutny>wait
20:13:37  <indutny>are you running it on all commits?
20:13:47  <indutny>err
20:13:53  <indutny>for each commit that happened before?
20:14:04  <nodejs-ci>Project nodejs-master » ia32,linux build #10:STILL FAILING in 23 min: http://jenkins.nodejs.org/job/nodejs-master/./DESTCPU=ia32,label=linux/10/
20:14:04  <nodejs-ci>info: deps: upgrade libuv to a0c1d84
20:14:05  <nodejs-ci>Failed tests:
20:14:19  <nodejs-ci>Project libuv-master » linux build #4:STILL FAILING in 17 min: http://jenkins.nodejs.org/job/libuv-master/./label=linux/4/
20:14:19  <nodejs-ci>* info: windows: initialize stop_flag explicitly
20:14:20  <nodejs-ci>* info: unix, windows: add common uv_udp_* error checking
20:14:20  <nodejs-ci>* info: linux, darwin: don't touch environ in uv_setup_args
20:14:21  <nodejs-ci>Failed tests:
20:27:04  * qmx|errandschanged nick to qmx
20:34:22  * sblomjoined
20:39:07  * txdvquit (Read error: Connection reset by peer)
20:39:14  * txdvjoined
20:40:27  * benoitcquit (Excess Flood)
20:40:31  * sblompart
20:41:01  * sblomjoined
20:47:36  * benoitcjoined
20:53:09  * mikealjoined
20:57:25  * mikealquit (Ping timeout: 248 seconds)
21:04:32  <tjfontaine>indutny: hmm? no we'll be benchmarking commit history, but only CI new commits going forward, it was just catching up today
21:12:57  * loladirojoined
21:23:54  * mikealjoined
21:28:54  * mikealquit (Ping timeout: 264 seconds)
21:30:52  * mikealjoined
21:37:19  * bradleymeckquit (Quit: bradleymeck)
21:54:48  <trevnorris>isaacs: fyi, spent 2 hours with out analysts last friday hashing out the best statistical method for the benchmarks.
21:55:44  <trevnorris>isaacs: the initial setup will require some analysis, but after some basic values are known the rest can be automated.
21:56:53  <trevnorris>will try to have the run-full-benchmark-analysis-before-release.js script done by the end of the week.
22:00:42  * qmxchanged nick to qmx|away
22:09:35  * wolfeidauquit (Remote host closed the connection)
22:10:42  * dominictarrjoined
22:11:46  * pooyajoined
22:12:33  <tjfontaine>sblom: is vs express 2012 for desktop sufficient for compiling node?
22:13:18  <TooTallNate>tjfontaine: last i checked yes
22:13:29  <tjfontaine>TooTallNate: ok thanks
22:17:22  * benoitcquit (Excess Flood)
22:17:51  * stagasjoined
22:18:07  * benoitcjoined
22:18:56  <isaacs>trevnorris: \o/
22:18:58  <isaacs>that's awesome
22:21:42  * pooyaquit (Ping timeout: 276 seconds)
22:23:17  * rendarquit
22:24:37  * dominictarrquit (Quit: dominictarr)
22:27:11  * stagasquit (Ping timeout: 255 seconds)
22:29:04  * wolfeidaujoined
22:29:59  * wolfeidauquit (Read error: Connection reset by peer)
22:30:15  * wolfeidaujoined
22:31:32  * indexzerojoined
22:33:01  * hzquit
22:39:02  * dominictarrjoined
22:42:19  * dominictarrquit (Client Quit)
22:44:15  * pooyajoined
22:57:48  <tjfontaine>TooTallNate, sblom: http://paste.debian.net/hidden/1131da49/ have you seen this before?
22:58:41  <sblom>tjfontaine: that one's new to me--let me see if I can find anything out about it.
22:59:50  <tjfontaine>sblom: thanks I'm on 2k8 std r2 64bit with a fresh express 2012
23:05:41  * c4miloquit (Remote host closed the connection)
23:15:25  * dominictarrjoined
23:33:21  * nodejs-ciquit
23:33:57  * nodejs-cijoined
23:48:06  * bradleymeckjoined
23:50:25  * benoitcquit (Excess Flood)
23:51:59  * c4milojoined
23:54:49  * loladiroquit (Quit: loladiro)
23:59:38  * benoitcjoined