00:00:01  * ircretaryquit (Remote host closed the connection)
00:00:09  * ircretaryjoined
00:01:25  * qardquit (Quit: Leaving.)
00:04:33  <MI6>libuv-node-integration: #116 FAILURE http://jenkins.nodejs.org/job/libuv-node-integration/116/
00:07:09  <tjfontaine>heh, nice, so trevnorris your buffer changes changed the speed at which stuff was flowing through the stdio pipes, which makes the windows tests for master a little happier
00:09:44  <tjfontaine>indutny: this assertion is blowing a lot on windows "Assertion failed: read_head_ != write_head_, file src\node_crypto_bio.cc, line 213" http://jenkins.nodejs.org//job/nodejs-master-windows/75/DESTCPU=x64,label=windows//tapTestReport/test.tap-301/
00:19:13  * timoxleyjoined
00:25:18  * HenryRawasquit (Ping timeout: 264 seconds)
00:27:56  * qardjoined
00:29:00  * inolenquit (Ping timeout: 252 seconds)
00:29:27  * inolenjoined
00:34:12  * inolen1joined
00:34:14  * inolenquit (Read error: Connection reset by peer)
00:37:45  * amartensquit (Quit: Leaving.)
00:57:11  * defunctzombie_zzchanged nick to defunctzombie
01:01:01  * CAPSLOCKBOTjoined
01:01:06  * LOUDBOTjoined
01:06:57  * defunctzombiechanged nick to defunctzombie_zz
01:11:29  * amartensjoined
01:11:40  * CAPSLOCKBOTquit (Remote host closed the connection)
01:11:41  * LOUDBOTquit (Remote host closed the connection)
01:11:49  * CAPSLOCKBOTjoined
01:11:56  * LOUDBOTjoined
01:13:01  * LOUDBOTquit (Remote host closed the connection)
01:13:01  * CAPSLOCKBOTquit (Read error: Connection reset by peer)
01:13:09  * CAPSLOCKBOTjoined
01:13:18  * LOUDBOTjoined
01:14:11  * LOUDBOTquit (Remote host closed the connection)
01:14:11  * CAPSLOCKBOTquit (Remote host closed the connection)
01:14:21  * CAPSLOCKBOTjoined
01:14:21  * LOUDBOTjoined
01:27:26  * abraxasjoined
01:36:34  * LOUDBOTquit (Remote host closed the connection)
01:36:35  * CAPSLOCKBOTquit (Remote host closed the connection)
01:36:42  * CAPSLOCKBOTjoined
01:36:42  * LOUDBOTjoined
01:38:33  * CAPSLOCKBOTquit (Remote host closed the connection)
01:38:33  * LOUDBOTquit (Remote host closed the connection)
01:38:42  * LOUDBOTjoined
01:38:42  * CAPSLOCKBOTjoined
01:41:02  * TooTallNatequit (Quit: Computer has gone to sleep.)
01:42:48  * wolfeidauquit (Remote host closed the connection)
01:43:16  * TooTallNatejoined
01:43:45  * CAPSLOCKBOTquit (Remote host closed the connection)
01:43:45  * LOUDBOTquit (Remote host closed the connection)
01:43:52  * LOUDBOTjoined
01:43:52  * CAPSLOCKBOTjoined
01:45:59  * CAPSLOCKBOTquit (Remote host closed the connection)
01:45:59  * LOUDBOTquit (Remote host closed the connection)
01:46:09  * LOUDBOTjoined
01:46:09  * CAPSLOCKBOTjoined
01:51:10  * LOUDBOTquit (Remote host closed the connection)
01:51:11  * CAPSLOCKBOTquit (Remote host closed the connection)
01:51:18  * CAPSLOCKBOTjoined
01:51:23  * LOUDBOTjoined
01:53:16  * CAPSLOCKBOTquit (Remote host closed the connection)
01:53:16  * LOUDBOTquit (Remote host closed the connection)
01:53:25  * LOUDBOTjoined
01:53:30  * CAPSLOCKBOTjoined
01:57:03  * TooTallNatequit (Quit: ["Textual IRC Client: www.textualapp.com"])
01:58:28  * CAPSLOCKBOTquit (Remote host closed the connection)
01:58:28  * LOUDBOTquit (Remote host closed the connection)
01:58:35  * LOUDBOTjoined
01:58:35  * CAPSLOCKBOTjoined
02:03:38  * CAPSLOCKBOTquit (Remote host closed the connection)
02:03:38  * LOUDBOTquit (Remote host closed the connection)
02:03:45  * CAPSLOCKBOTjoined
02:03:45  * LOUDBOTjoined
02:05:02  * CAPSLOCKBOTquit (Remote host closed the connection)
02:05:02  * LOUDBOTquit (Remote host closed the connection)
02:05:11  * CAPSLOCKBOTjoined
02:05:17  * LOUDBOTjoined
02:09:23  * CAPSLOCKBOTquit (Remote host closed the connection)
02:09:23  * LOUDBOTquit (Remote host closed the connection)
02:09:30  * CAPSLOCKBOTjoined
02:09:35  * LOUDBOTjoined
02:24:43  * defunctzombie_zzchanged nick to defunctzombie
02:41:13  * dapquit (Quit: Leaving.)
02:52:57  * wolfeidaujoined
02:53:39  * kevinswiberjoined
02:55:30  * brsonquit (Quit: leaving)
03:02:38  * wolfeidauquit (Remote host closed the connection)
03:24:12  * qardpart
03:28:46  * kevinswiberquit (Remote host closed the connection)
03:39:26  * c4miloquit (Remote host closed the connection)
03:41:56  * st_lukequit (Remote host closed the connection)
03:50:46  * Benviequit (*.net *.split)
03:50:46  * jez0990quit (*.net *.split)
03:50:46  * defunctzombiequit (*.net *.split)
03:50:46  * qmxquit (*.net *.split)
03:50:46  * joshthecoderquit (*.net *.split)
03:50:46  * luigy_quit (*.net *.split)
03:50:46  * trevnorrisquit (*.net *.split)
03:51:54  * inolen1quit (*.net *.split)
03:51:54  * mmaleckiquit (*.net *.split)
03:51:54  * rvaggquit (*.net *.split)
03:52:43  * Benviejoined
03:52:43  * jez0990joined
03:52:43  * defunctzombiejoined
03:52:43  * qmxjoined
03:52:43  * joshthecoderjoined
03:52:43  * luigy_joined
03:52:43  * trevnorrisjoined
03:53:48  * inolen1joined
03:53:48  * mmaleckijoined
03:53:48  * rvaggjoined
03:53:59  * Benviequit (*.net *.split)
03:53:59  * jez0990quit (*.net *.split)
03:53:59  * defunctzombiequit (*.net *.split)
03:53:59  * qmxquit (*.net *.split)
03:53:59  * joshthecoderquit (*.net *.split)
03:53:59  * luigy_quit (*.net *.split)
03:53:59  * trevnorrisquit (*.net *.split)
03:55:37  * kazuponjoined
03:55:41  * Benviejoined
03:55:41  * jez0990joined
03:55:41  * defunctzombiejoined
03:55:41  * qmxjoined
03:55:41  * joshthecoderjoined
03:55:41  * luigy_joined
03:55:41  * trevnorrisjoined
04:05:59  <isaacs>this npm+manta thingie is going very well
04:06:16  <isaacs>the net breakage is basically already fixed, now just have to wait for replication to finish to test it more thoroughly
04:26:17  <isaacs>ugh, scratch that :)
04:29:37  * defunctzombiechanged nick to defunctzombie_zz
04:30:25  * dominictarrjoined
04:34:45  * groundwaterquit (Ping timeout: 248 seconds)
04:37:17  * groundwaterjoined
04:40:03  <mmalecki>isaacs: oh, I was wondering if you'd try it out for packages
04:40:23  <mmalecki>isaacs: what's your opinion on manta :) ?
04:40:52  <isaacs>mmalecki: it's rad
04:40:59  <isaacs>mmalecki: still going throuh birthing pains :)
04:41:20  <mmalecki>yeah, I figured :)
04:43:50  * bajtosjoined
04:49:53  * bajtosquit (Ping timeout: 240 seconds)
04:50:38  * wolfeidaujoined
04:55:12  * timoxleyquit (Ping timeout: 252 seconds)
05:22:09  * dominictarrquit (Quit: dominictarr)
05:22:41  * dominictarrjoined
05:32:35  * paddybyersjoined
06:08:40  * loladiroquit (Quit: loladiro)
06:09:55  * creationix_joined
06:09:58  * creationixquit (Read error: Operation timed out)
06:09:59  * creationix_changed nick to creationix
06:38:44  * timoxleyjoined
06:39:42  * dapjoined
06:47:56  * rendarjoined
06:54:09  * dapquit (Quit: Leaving.)
06:59:16  * bajtosjoined
07:08:53  * paddybyersquit (Ping timeout: 246 seconds)
07:12:48  * wolfeidauquit (Remote host closed the connection)
07:13:34  * paddybyersjoined
07:34:03  * csaohjoined
07:47:40  * amartensquit (Quit: Leaving.)
08:12:38  * bajtosquit (Quit: bajtos)
08:17:45  * `3E|ZZZchanged nick to `3E
08:46:25  * bnoordhuisjoined
08:47:59  * amartensjoined
08:52:05  * amartensquit (Ping timeout: 240 seconds)
09:19:26  * bajtosjoined
09:24:24  * bajtosquit (Ping timeout: 240 seconds)
09:34:43  * groundwaterquit (Ping timeout: 264 seconds)
09:37:47  * groundwaterjoined
09:45:15  * kazuponquit (Remote host closed the connection)
09:48:16  * amartensjoined
09:52:37  * amartensquit (Ping timeout: 248 seconds)
09:53:39  * saghulquit (Remote host closed the connection)
10:00:06  * saghuljoined
10:04:35  * wolfeidaujoined
10:16:01  * inolenjoined
10:16:23  * inolen1quit (Read error: Connection reset by peer)
10:20:56  * bajtosjoined
10:21:23  * timoxleyquit (Ping timeout: 246 seconds)
10:25:24  * bajtosquit (Ping timeout: 240 seconds)
10:33:41  * groundwaterquit (Ping timeout: 248 seconds)
10:37:04  * groundwaterjoined
10:38:54  * kazuponjoined
10:42:58  * hzjoined
10:49:14  * amartensjoined
10:50:30  * wolfeidauquit (Remote host closed the connection)
10:50:55  * wolfeidaujoined
10:52:31  * wolfeidauquit (Remote host closed the connection)
10:52:52  * abraxasquit (Remote host closed the connection)
10:53:26  * abraxasjoined
10:53:48  * amartensquit (Ping timeout: 252 seconds)
10:56:23  * piscisaureus_joined
10:58:22  * abraxasquit (Ping timeout: 276 seconds)
11:00:43  * csaohquit (Quit: csaoh)
11:08:41  * piscisaureus_quit (Read error: Connection reset by peer)
11:09:43  * piscisaureus_joined
11:14:56  * bnoordhuisquit (Ping timeout: 246 seconds)
11:21:35  * bajtosjoined
11:22:24  * csaohjoined
11:25:53  * bajtosquit (Ping timeout: 240 seconds)
11:40:33  * stagasjoined
11:49:29  * amartensjoined
11:54:00  * amartensquit (Ping timeout: 256 seconds)
11:59:49  * bajtosjoined
11:59:56  * piscisaureus_quit (Ping timeout: 256 seconds)
12:06:12  * bnoordhuisjoined
12:09:22  * kazuponquit (Remote host closed the connection)
12:27:40  * dominictarrquit (Quit: dominictarr)
12:27:59  * csaohquit (Remote host closed the connection)
12:30:59  * dominictarrjoined
12:31:57  * kevinswiberjoined
12:34:19  * dominictarrquit (Client Quit)
12:35:30  * csaohjoined
12:46:55  * piscisaureus_joined
12:49:33  * wolfeidaujoined
12:49:51  * amartensjoined
12:54:19  * amartensquit (Ping timeout: 246 seconds)
13:01:39  * dominictarrjoined
13:08:22  * stagasquit (Ping timeout: 276 seconds)
13:20:10  * kazuponjoined
13:25:21  * kazuponquit (Ping timeout: 248 seconds)
13:26:04  * bajtosquit (Quit: bajtos)
13:36:10  * kevinswiberquit (Remote host closed the connection)
13:40:45  * c4milojoined
13:42:21  * loladirojoined
13:42:42  * loladiroquit (Client Quit)
13:50:08  * amartensjoined
13:53:47  * defunctzombie_zzchanged nick to defunctzombie
13:54:42  * amartensquit (Ping timeout: 264 seconds)
14:11:06  * defunctzombiechanged nick to defunctzombie_zz
14:12:54  * kevinswiberjoined
14:15:52  * bajtosjoined
14:16:40  * pachetjoined
14:18:03  * bajtosquit (Client Quit)
14:20:14  * bajtosjoined
14:25:29  * hzquit
14:31:26  * timoxleyjoined
14:32:06  * papertigersjoined
14:46:19  * AvianFlujoined
14:50:28  * amartensjoined
14:54:42  * amartensquit (Ping timeout: 246 seconds)
14:57:27  * bnoordhuisquit (Ping timeout: 252 seconds)
15:06:04  * defunctzombie_zzchanged nick to defunctzombie
15:13:36  * hzjoined
15:16:39  <isaacs>good morning
15:20:21  * `3Echanged nick to `3E|BBQ
15:22:33  * defunctzombiechanged nick to defunctzombie_zz
15:24:50  * dominictarrquit (Quit: dominictarr)
15:26:03  * bajtosquit (Quit: bajtos)
15:36:23  * dapjoined
15:36:57  * bnoordhuisjoined
15:37:29  * dominictarrjoined
15:42:22  * AvianFluquit (Remote host closed the connection)
15:43:54  * bnoordhuisquit (Ping timeout: 264 seconds)
15:46:00  * HenryRjoined
16:06:25  * amartensjoined
16:15:33  * TooTallNatejoined
16:16:22  * piscisaureus_quit (Ping timeout: 256 seconds)
16:20:40  * kevinswiberquit (Remote host closed the connection)
16:28:38  <indutny>morning
16:31:33  * qardjoined
16:32:47  * qardpart
16:33:03  * qardjoined
16:34:27  * loladirojoined
16:38:30  * piscisaureus_joined
16:38:31  * kevinswiberjoined
16:42:05  * timoxleyquit (Quit: Computer has gone to sleep.)
16:44:48  * TooTallNatequit (Quit: Computer has gone to sleep.)
16:48:47  * dominictarrquit (Quit: dominictarr)
16:54:56  * csaohquit (Quit: csaoh)
16:56:23  <tjfontaine>dear jenkins oh jenkins, why have you forsaken me
16:57:26  * defunctzombie_zzchanged nick to defunctzombie
17:00:00  * piscisaureus_quit (Ping timeout: 246 seconds)
17:01:17  * kazuponjoined
17:03:30  * TooTallNatejoined
17:04:45  * bnoordhuisjoined
17:08:32  * dominictarrjoined
17:09:38  * piscisaureus_joined
17:10:02  * dominictarrquit (Client Quit)
17:14:08  * kevinswiberquit (Remote host closed the connection)
17:17:17  * loladiroquit (Quit: loladiro)
17:17:46  * kazuponquit (Remote host closed the connection)
17:19:38  * kevinswiberjoined
17:19:42  * kazuponjoined
17:28:26  <trevnorris>morning
17:28:43  <trevnorris>tjfontaine: so noticable difference on the windows tests?
17:29:03  <MI6>joyent/node: piscisaureus created branch jenkins-please-test-this - http://git.io/FY4OOg
17:31:52  <tjfontaine>trevnorris: well it cleaned up some parts interestingly
17:31:58  <piscisaureus_>tjfontaine: did you secretly start job node-review/14 manually? :)
17:32:08  <trevnorris>hm. that was unexpected. :)
17:32:31  <tjfontaine>piscisaureus_: yes I need to change the way jankins submits the ref
17:32:40  <tjfontaine>trevnorris: well the tests in particular are timing sensitive
17:32:53  <piscisaureus_>tjfontaine: don't worry about it. It's just me being lazy. I can submit pull requests also
17:33:36  <tjfontaine>piscisaureus_: well the difference between a PR and the review job is that the PR won't test on windows
17:33:49  <piscisaureus_>tjfontaine: oh really?
17:33:55  <piscisaureus_>tjfontaine: I never realized ...
17:34:12  <piscisaureus_>tjfontaine: why doesn't it?
17:34:28  <amartens>I've been messing around with ngx_queue_foreach() and ngx_queue_remove(), and while I was running valgrind on some code (which was working fine), I ended up running into this: https://github.com/joyent/libuv/issues/646
17:34:47  <amartens>where bnoordhuis ended up saying, "The reason it doesn't actually crash (without the patch) is that the handle remains valid for one more tick. Still, even if it's not an actual bug, it's still sloppy."
17:35:03  <tjfontaine>piscisaureus_: because breaking the build slightly on windows fucks future job builds because you'll probably end up with hanging processes around
17:35:29  <tjfontaine>piscisaureus_: unless (aside from job objects) you can tell me how a parent process can get notified for all created grand children pid's'
17:35:30  <amartens>any good way around this? Or just "don't remove elements from the queue while within a foreach loop"?
17:36:21  * loladirojoined
17:38:37  * loladiroquit (Client Quit)
17:49:12  * sblomjoined
17:49:22  * loladirojoined
17:53:48  <piscisaureus_>amartens: I don't know. We replaced ngx-queue.h by queue.h which may or may not fix this. bnoordhuis knows
17:54:24  <piscisaureus_>tjfontaine: how are these processes escaping job control?
17:55:28  <tjfontaine>piscisaureus_: well some tests actively say they want detached
17:55:46  <piscisaureus_>tjfontaine: well then you're gettng what you want huh? :)
17:55:55  <TooTallNate>trevnorris: did your Buffer stuff land on master yesterday?
17:55:59  <bnoordhuis>amartens, piscisaureus_: it still happens. it's not that hard to fix, i just haven't gotten around to it
17:56:04  <trevnorris>TooTallNate: yep :)
17:56:06  <tjfontaine>piscisaureus_: the test is getting it, the job runner needs to still clean it all up
17:56:10  * c4miloquit (Remote host closed the connection)
17:56:13  <TooTallNate>trevnorris: awesome :) time to play :)
17:56:41  <piscisaureus_>tjfontaine: how does it do that on unix?
17:57:15  <tjfontaine>piscisaureus_: it doesn't really, but the failure state is more tolerable on unix than it is on windows generally
17:57:47  <piscisaureus_>tjfontaine: ah, right. I would suppose that we should just fix those tests to clean themselves up.
17:57:50  <tjfontaine>on unix I generally just get more test failures, on windows I'll get full build failures because it can't clean up
17:58:18  <piscisaureus_>tjfontaine: I mean, you're creating a detached process - and you're getting what you (the test) asked for
17:58:25  <tjfontaine>right, I dont' disagree
17:58:38  <tjfontaine>but I'd like a way to taskill at the end of the jenkins job any left over shit
17:59:01  <tjfontaine>job is over, just shoot it all in the head
17:59:40  <piscisaureus_>tjfontaine: if you run all the tests in a "root" process
17:59:46  <piscisaureus_>e.g. cmd.exe
17:59:48  <sblom>tjfontaine: On Windows it's possible to rename node.exe even when an out of control test keeps it locked, even if not delete it.
18:00:06  <sblom>So it might be possible to use that hack to at least enable a build.
18:00:43  <sblom>Or, yeah, maybe start with a `taskkill /im node.exe` before cleanup? Or post unit-tests?
18:00:45  <tjfontaine>sblom: the problem is that eventually I'll probably just run out of space while I'm waiting for things to actually die so they can be cleaned up
18:01:00  <tjfontaine>sblom: but we may have multiple jobs running at the same time
18:01:10  <sblom>tjfontaine: Oh, dang--I remember now.
18:01:38  <sblom>We could teach the tests to journal the PIDs that they spawn somewhere?
18:01:58  <sblom>(Sounds like a ton of unit test source touches to make that happen.)
18:02:13  <MI6>node-review: #14 UNSTABLE windows-x64 (21/604) smartos-x64 (6/604) smartos-ia32 (2/604) windows-ia32 (19/604) osx-x64 (1/604) http://jenkins.nodejs.org/job/node-review/14/
18:02:29  <tjfontaine>well that's sorta what my initial question was, can I get notification of any created grandchild pids
18:03:07  <tjfontaine>I guess the easiest thing is to spawn the tests in a user and taskill based on that user
18:03:08  <trevnorris>piscisaureus_: fyi, i'll be throwing up a pr sometime today you'll want to be involved with.
18:03:42  <tjfontaine>trevnorris: have you looked at that windows test-buffer-ascii failure yet?
18:03:58  <amartens>piscisaureus_, bnoordhuis: thanks for the feedback; I hadn't seen that ngx-queue.h had been replaced with queue.h. I'll take a look for that
18:04:04  <piscisaureus_>sblom: tjfontaine: if you spawn all tests from a "root" container you can clean that up afterwards.
18:04:20  <tjfontaine>piscisaureus_: well there is a root node.exe that launches this
18:04:31  <tjfontaine>there's also the root python.exe
18:04:56  <piscisaureus_>tjfontaine: yes so you probably either of these processes to self-destruct
18:05:01  <trevnorris>tjfontaine: yeah. though I don't have access to a windows box.
18:05:13  <piscisaureus_>with taskkill /f /t /pid 1234
18:05:13  <trevnorris>tjfontaine: it might be a bug in v8's new "WriteOneByte" api
18:05:20  <trevnorris>but not sure.
18:05:27  <piscisaureus_>where 1234 is the pid of the container process
18:05:28  <amartens>(or rather, I was looking in node's source tree, so maybe that's my problem)
18:05:29  <tjfontaine>piscisaureus_: except for the case of a detached process whose intermediate parent has been lost?
18:05:55  <piscisaureus_>tjfontaine: on windows processes get reparented to it's grandparent, not to init like unix
18:06:07  <tjfontaine>ok
18:06:08  <piscisaureus_>tjfontaine: so as long as that process didn't die you can still taskkill /t it
18:06:18  <piscisaureus_>and it will clean up the entire tree
18:07:24  <tjfontaine>trevnorris: ok I'll look into it
18:07:27  <tjfontaine>piscisaureus_: ok
18:08:11  <trevnorris>tjfontaine: quickest way I can think to test is to first check that 'binary' input/output match. that will verify if it's v8 or node.
18:08:38  <trevnorris>tjfontaine: if it's node then it's something to do w/ the force_ascii function on string_bytes.cc
18:08:46  <trevnorris>s/on/in
18:08:59  * dlmanningjoined
18:09:36  * `3E|BBQchanged nick to `3E
18:18:33  * HenryRquit
18:22:27  * c4milojoined
18:23:23  * brsonjoined
18:26:58  <trevnorris>bnoordhuis, piscisaureus_: fyi, beginning of next set of perf enhancements: PR-5720
18:28:17  <tjfontaine>is github sucking right now?
18:30:24  * mikealjoined
18:30:36  * AvianFlujoined
18:37:39  * brsonquit (Ping timeout: 246 seconds)
18:38:23  * TooTallNatequit (Ping timeout: 246 seconds)
18:39:01  <trevnorris>isaacs: fyi, vacation next week. i'll be on and off, and still in standup.
18:41:45  * HenryRjoined
18:45:06  <tjfontaine>trevnorris: haven't actually looked at test-buffer-ascii yet, but it doesn't fail when I launch it from the command prompt, so "yay"
18:45:24  <tjfontaine>that will make it fun to figure out
18:45:42  <trevnorris>heh, yeah. those are awesome.
18:53:24  <tjfontaine>github gfy
18:57:31  * perezdjoined
18:59:24  * pachetquit (Ping timeout: 240 seconds)
19:12:23  * kazuponquit (Remote host closed the connection)
19:13:56  * TooTallNatejoined
19:25:12  * brsonjoined
19:33:43  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
19:42:43  * kazuponjoined
19:48:26  * HenryRquit (Read error: Connection reset by peer)
19:48:35  * HenryRjoined
19:51:31  * kazuponquit (Ping timeout: 271 seconds)
19:53:34  * c4miloquit (Remote host closed the connection)
20:03:21  <MI6>joyent/node: Fedor Indutny master * bf8dc07 : crypto: change assertion to condition in bio - http://git.io/Ym9Zhw
20:06:25  * pachetjoined
20:06:25  * pachetquit (Changing host)
20:06:25  * pachetjoined
20:08:38  <tjfontaine>erm well
20:10:46  <trevnorris>lgtm anyone? https://github.com/trevnorris/node/commit/35f18b8
20:13:09  <indutny>trevnorris: may be just default argument?
20:13:18  <indutny>why spawn a lot of functions
20:13:28  <trevnorris>indutny: ah, yeah.
20:13:36  <trevnorris>forget I can do that in cpp.
20:15:50  <trevnorris>indutny: how about this: https://github.com/trevnorris/node/commit/f5e13ae
20:18:06  <indutny>well, are tests passing?
20:18:12  <indutny>if yes - then lgtm
20:18:18  <trevnorris>cool. thanks. :)
20:18:44  <trevnorris>and they'd have to be. this isn't used by node-core. it's a user-land api. :P
20:19:09  <trevnorris>(at least for now, might have a use case for it. hence the love)
20:19:55  * AvianFluquit (Remote host closed the connection)
20:21:24  <MI6>joyent/node: Trevor Norris master * f5e13ae : buffer: write strings directly from call - http://git.io/KvHCeQ
20:22:35  <indutny>trevnorris: we need test
20:22:56  <trevnorris>indutny: how do you add tests for cpp only functionality?
20:23:04  <trevnorris>(haven't needed to do that before)
20:23:06  <indutny>oh… that's a good question
20:23:16  <indutny>we need to figure it out… eventually
20:23:19  <indutny>or
20:23:22  <indutny>fuck it
20:23:23  <indutny>:P
20:23:25  <trevnorris>heh
20:23:30  <trevnorris>well, I think you're right.
20:23:49  <trevnorris>since they're talk about standardizing a cpp api for v1 it'd be necessary to do that.
20:23:55  <trevnorris>tjfontaine: have an idea?
20:24:05  <trevnorris>because we love making jenkins do more. ;)
20:24:43  <tjfontaine>trevnorris: I guess they live in test/addons
20:24:57  <tjfontaine>though it's not plugged in
20:25:27  <trevnorris>yeah
20:25:50  <tjfontaine>it should be doable though really
20:26:05  <trevnorris>i'll make an issue for it! :P
20:27:41  <MI6>nodejs-master: #267 UNSTABLE smartos-x64 (7/604) osx-ia32 (1/604) smartos-ia32 (2/604) http://jenkins.nodejs.org/job/nodejs-master/267/
20:30:26  * kevinswiberquit (Remote host closed the connection)
20:31:57  <MI6>nodejs-master-windows: #76 UNSTABLE windows-x64 (20/604) windows-ia32 (21/604) http://jenkins.nodejs.org/job/nodejs-master-windows/76/
20:32:10  * mikealquit (Quit: Leaving.)
20:33:00  <tjfontaine>indutny: fwiw, I hadn't actually lgtm that push, now a lot of tls tests fail on windows because of timeouts http://jenkins.nodejs.org/job/nodejs-master-windows/76/testReport/
20:44:02  <trevnorris>tjfontaine: wried?
20:45:10  <tjfontaine>trevnorris: hm?
20:45:33  <trevnorris>"but they are not wried up in any meaningful way"
20:45:40  <tjfontaine>*wired
20:45:44  <trevnorris>ah, ok.
20:46:00  <trevnorris>since that's actually a word, didn't know if you were making a joke or not.
20:47:09  <tjfontaine>I've never heard anyone use wry in the past tense like that
20:47:56  * kevinswiberjoined
20:47:57  * kazuponjoined
20:48:10  <trevnorris>heh
20:48:36  <tjfontaine>I'm really confused about the internet situation at my house right now, github clones to it are going at 40~100K/s
20:48:51  <trevnorris>sounds painful.
20:48:54  <indutny>hahaha
20:49:04  <tjfontaine>painful for all of us because that's where the osx build slave is :)
20:49:10  <indutny>tjfontainet: wtf?
20:49:25  <tjfontaine>indutny: indeed
20:49:33  <indutny>do you mean trevor's stuff?
20:49:37  <indutny>or crypto bio thingy?
20:49:54  <tjfontaine>indutny: no, your crypto bio stuff fixed the assert that was blowing but doesn't seem to have really fixed tls on windows
20:50:02  <indutny>ah, so its trevor's stuff
20:50:07  <tjfontaine>I doubt it
20:50:11  <tjfontaine>but maybe
20:50:16  <trevnorris>eh? you mean the buffer string commit I just did?
20:50:19  <tjfontaine>no
20:50:31  <trevnorris>ah. the _other_ stuff. ok. :)
20:51:03  <tjfontaine>that's what I mean, I don't know what indutny means, but I don't think they're related, but I could rollback beyond your buffer changes and apply that patch
20:51:47  <trevnorris>i'm still not even sure what the problem is. so many tests are failing on windows, not sure how you can tell them all apart. :P
20:52:05  <MI6>nodejs-master: #268 UNSTABLE smartos-x64 (5/604) smartos-ia32 (1/604) linux-x64 (1/604) http://jenkins.nodejs.org/job/nodejs-master/268/
20:52:31  <tjfontaine>windows is definitely the redheaded step child
20:52:39  * kazuponquit (Ping timeout: 252 seconds)
20:52:46  <trevnorris>lol
20:53:44  <tjfontaine>still not sure why the fuck buffer-ascii fails in the test runner on jenkins but not command line, that's frustrating
20:54:18  <trevnorris>tjfontaine: can you modify the test to print out the Buffer?
20:54:29  <trevnorris>the partial strings the assertion is showing are useless
20:57:20  <MI6>nodejs-master-windows: #77 UNSTABLE windows-x64 (21/604) windows-ia32 (19/604) http://jenkins.nodejs.org/job/nodejs-master-windows/77/
20:57:47  <tjfontaine>oh you know what
20:57:50  <tjfontaine>lemme verify something
20:58:18  <tjfontaine>trevnorris: ok, good news, it's just a x64 failure, so probably some bad pointer math that is only exhibiting in msvc
20:58:43  <tjfontaine>probably happened with stringbytes refactor not you
20:59:03  <tjfontaine>but maybe your onebyte stuff
20:59:22  <trevnorris>oh, the v8 api change? yeah. that might be doing it too. you can verify that by:
21:00:35  <trevnorris>(sec. verifying the verification :P
21:03:49  * c4milojoined
21:04:49  <trevnorris>tjfontaine: can you post the output of the buffers from that test?
21:04:58  <trevnorris>might have an idea where it's coming from.
21:05:44  <tjfontaine>ya, it'll take a bit rebuilding the 64bit on windows
21:10:36  <trevnorris>tjfontaine: what's strange is that it doesn't burn on the double byte utf8 sequence above. but below on the triple byte sequence all hell breaks loose.
21:11:50  * rendarquit
21:12:00  <trevnorris>tjfontaine: when it's done just show me the output of: Buffer(Buffer('�').toString('binary'), 'binary')
21:12:03  * AvianFlujoined
21:12:18  <trevnorris>(the character there is a triple byte. so hopefully it copies ok :)
21:12:30  * mikealjoined
21:13:43  * tjfontainegrumbles about the stupid fucking windows build
21:13:53  <trevnorris>lol
21:14:24  <tjfontaine>LINK : fatal error LNK1181: cannot open input file 'winmm.lib' [g:\scratch\node
21:14:26  <tjfontaine>\deps\v8\tools\gyp\mksnapshot.x64.vcxproj]
21:15:24  <trevnorris>ooh. free ice cream!
21:15:28  * trevnorrisruns off
21:27:08  <Raynos>I've excited myself too much with --harmony-generators. When will 0.11 go into "people should start trying this in production so we can get bug reports" ?
21:27:45  <tjfontaine>I'm not sure when the next 0.11 release will be, but there are some nightlies you can always play with
21:36:10  <TooTallNate>Raynos: when v0.12.x is out :p
21:36:40  <Raynos>TooTallNate: 2months, 4 months, 6 months?
21:36:52  <Raynos>tjfontaine: I am already doing generators with 0.11.2 it works quite nicely
21:37:01  <Raynos>TooTallNate: forgot the 1 year option, that's valid too
21:37:10  <TooTallNate>Raynos: c'mon you know we all hate dates :p
21:37:17  <tjfontaine>Raynos: I'm just saying stay up on the nightlies and you can prevent us causing you regressions :)
21:37:18  <TooTallNate>Raynos: you'd have to ask isaacs for a realistic answer :)
21:37:20  <Raynos>I'm not asking for a date
21:37:23  <Raynos>I'm asking for an order of magnitude
21:37:47  <tjfontaine>I can't see it being in 2, and 6 seems like the outside, but who knows this is the last real chance for api changes :)
21:38:11  <Raynos>this reminds me
21:38:39  <trevnorris>Raynos: problem w/ generators is that they're run right now, but very un-performant.
21:38:53  <trevnorris>v8 can't inline calls to .next() the way it can w/ normal callbacks
21:40:33  <Raynos>oh
21:40:43  <Raynos>yeah that's going to be a pain point
21:40:51  <Raynos>but im not using generators for performance
21:41:00  <Raynos>I'm using them for "my callbacks are 6 levels deep"
21:41:41  <trevnorris>tjfontaine: agreed. imo we should also wait for v8 to official deprecate the many things currently marked in include/v8.h
21:41:55  <trevnorris>that is going to be a massive api shift for module developers.
21:42:02  <tjfontaine>ya well
21:42:17  * TooTallNateshoots self in head
21:42:21  <trevnorris>lol
21:42:33  <trevnorris>sorry TooTallNate. it's going to be a world of hurt.
21:42:40  <TooTallNate>trevnorris: so to double-check... Buffer C++ class is gone, ya?
21:42:45  <tjfontaine>deprecation will still mean the compile
21:42:54  <tjfontaine>the class is gone, it's all a namespace now
21:42:58  <trevnorris>yup
21:43:37  <TooTallNate>trevnorris: tjfontaine: wouldn't there be a way to leave it hanging around for a little while (as basically just a wrapper, with a deprecation warning) while people upgrade?
21:44:10  <tjfontaine>I'm not sure how feasible that is, but it sounds like a good idea
21:44:13  <TooTallNate>while modules update their code i mean
21:44:22  <trevnorris>TooTallNate: sorry. I explored that for a while. I couldn't figure out a way.
21:44:30  <tjfontaine>TooTallNate: does ref compile against master right now?
21:44:33  <trevnorris>that's not saying it can't be done.
21:44:33  <TooTallNate>trevnorris: cause of the Persistent stuff?
21:44:39  <TooTallNate>tjfontaine: no
21:44:44  <tjfontaine>k
21:45:07  <TooTallNate>this is the first error:
21:45:08  <TooTallNate> Buffer *buf = Buffer::New(ptr, buf_size, unref_null_cb, user_data);
21:45:17  <TooTallNate>trevnorris: ^ which was the basis for my question :p
21:45:28  <tjfontaine>ya, ok that's a problem
21:45:29  <trevnorris>TooTallNate: oh yea. instead do: "Local<Object> buf = Buffer::New(...)"
21:46:02  <TooTallNate>trevnorris: ya migrating is fine... my question was more if it was possible to have an overloaded Buffer::New() that returns a Buffer* (i realize that no longer exists...)
21:46:12  <TooTallNate>just for backwards API compat
21:46:43  <tjfontaine>I don't think there's an easy way to do that
21:46:48  <trevnorris>The only difference between the two calls would be the return value. which can't be done.
21:46:56  <tjfontaine>just going to have to ifdef it
21:47:11  <TooTallNate>trevnorris: oh shit, i didn't realize that :\
21:47:17  <TooTallNate>damn overloading...
21:47:23  <trevnorris>yeah.
21:47:39  <trevnorris>and keeping the class around, even a minimalist version, kills all the perf gains.
21:48:02  <trevnorris>b/c you need to create the object in cpp, and tie the class to it. two very expensive operations.
21:48:13  <tjfontaine>well it doesn't have to make a full handlewrap :)
21:48:20  <TooTallNate>sure but it would only happen for addons using the old API
21:48:33  <TooTallNate>in any case, it doesn't seem possible, so that's that :p
21:48:47  * kazuponjoined
21:48:55  <trevnorris>yeah. sorry. :(
21:49:33  <trevnorris>TooTallNate: fwiw, all calls go though the js function Buffer()
21:49:39  <trevnorris>so it doesn't matter where you create it.
21:49:56  <trevnorris>TooTallNate: also, Buffer still pools, but you can create an un-pooled buffer using SlowBuffer now.
21:50:15  <trevnorris>I just re-purposed it.
21:50:43  <TooTallNate>noted
21:51:08  <trevnorris>tjfontaine: windows build ever finish?
21:51:43  <tjfontaine>trevnorris: sorry I got distracted, yes, I need to make sure this is what you expected
21:52:02  <trevnorris>yeah. that statement should let me know whether the bug's in v8 or node
21:52:02  <tjfontaine>actually, stick that stanza you want tested in a gist
21:52:07  <trevnorris>ok
21:53:25  * ryahjoined
21:53:30  * kazuponquit (Ping timeout: 264 seconds)
21:53:35  <trevnorris>tjfontaine: https://gist.github.com/trevnorris/5818478
21:53:55  <ryah>what do you guys think about freebsd's netmap
21:54:22  <ryah>i think it's the right interface to network i/o
21:55:01  <trevnorris>ryah: just to double check, you're talking at the libuv level right?
21:55:04  <tjfontaine>trevnorris: ok that's what it does
21:55:41  <trevnorris>tjfontaine: that would lead me to believe it's something to do w/ "force_ascii" in string_bytes.cc
21:55:56  <ryah>trevnorris: sure - as an api to do networking
21:56:05  * mikealquit (Quit: Leaving.)
21:56:08  <tjfontaine>trevnorris: right it's likely pointer maths
21:56:10  <ryah>networking could include udp, tcp, dns, etc
21:56:18  * dominictarrjoined
21:56:26  <trevnorris>ryah: if it's faster, then cool :)
21:57:01  * defunctzombiechanged nick to defunctzombie_zz
21:57:11  <tjfontaine>are you asking this because of megapipe?
21:57:59  <trevnorris>tjfontaine: not sure why but my gut says it's something to do w/ http://git.io/B_zz_g
21:58:33  <ryah>yeah
21:58:44  <ryah>saw bert's comment on there
21:58:45  <tjfontaine>trevnorris: was that there like that before your stuff?
21:58:52  <trevnorris>tjfontaine: yeah.
21:59:28  <tjfontaine>right so this may have broke in the merge way back when
22:00:13  <trevnorris>tjfontaine: possible fix (totally shooting in the dark) https://gist.github.com/trevnorris/5818478
22:00:32  <tjfontaine>well that can't be the right answer
22:00:38  <tjfontaine>I mean, I'll do it
22:00:43  <trevnorris>heh, ok :)
22:01:20  <trevnorris>tjfontaine: real quick, can you show the following output: Buffer('�', 'ascii');
22:02:04  <trevnorris>tjfontaine: then also the output of: Buffer('�a�', 'ascii');
22:02:26  <tjfontaine>it's already rebuilding, and put those in the gist, because copying from osx -> rdp -> cmd isn't a very fun path for utf8
22:02:33  <trevnorris>lol ok
22:03:12  <trevnorris>tjfontaine: ok. gist updated.
22:03:17  <tjfontaine>thanks
22:03:29  <trevnorris>thank you. :)
22:03:46  <trevnorris>almost makes me wish I had a win vm or something (emphasis on almost)
22:05:04  <tjfontaine>you should :)
22:05:13  <tjfontaine>all core devs should, I shouldn't be the only one suffering :P
22:05:47  <tjfontaine>the first one does not roundtrip, but it also has your other "change" :P
22:08:18  <trevnorris>tjfontaine: if you could provide a vm I could boot then I'll add it. just don't want to take the time figuring out how to build in windows.
22:08:36  <tjfontaine>heh, maybe that's what my blog should be
22:09:39  <tjfontaine>there are a couple things to make your life not suck in windows, 1) always install to the defaults [which we can't do in this case] 2) only ever install one version of VS [my fault]
22:10:24  <tjfontaine>g:\scratch\node>release\node.exe statement.js
22:10:25  <tjfontaine><Buffer e2 80 99 61 e2 80 99>
22:10:25  <tjfontaine><Buffer 19 61 19>
22:11:36  <tjfontaine>so those standalone tests are fine
22:16:16  * tjfontainerebuilds in vs so he can have a debugger
22:16:40  * c4miloquit (Remote host closed the connection)
22:20:07  <trevnorris>tjfontaine: eh? the first statement you posted is twice as long.
22:20:30  <tjfontaine>trevnorris: it's the same thing I get on osx
22:20:44  <trevnorris>for me:
22:20:44  <trevnorris><Buffer e2 80 99>
22:20:49  <trevnorris><Buffer 19 61 19>
22:20:53  * jez0990quit (Read error: Connection reset by peer)
22:20:59  * jez0990joined
22:22:00  <tjfontaine>the first one looks right to me, a round trip of binary should preserve the bits
22:22:24  <tjfontaine>15>LINK : fatal error LNK1104: cannot open file 'gdi32.lib'
22:22:29  <tjfontaine>wtf are you smoking vs
22:23:40  <trevnorris>tjfontaine: second example, if you replace 'ascii' w/ 'binary' what do you get?
22:24:40  <tjfontaine>19 61 91
22:24:42  <tjfontaine>er
22:24:45  <tjfontaine>dyslexia aside
22:24:50  <tjfontaine>on osx
22:25:23  <trevnorris>yeah. so the round trip for binary should not print <Buffer e2 80 99 61 e2 80 99>
22:25:34  <trevnorris>since it's only giving you half the data going in.
22:28:26  <trevnorris>tjfontaine: ah hell. nm
22:28:45  <trevnorris>tjfontaine: I didn't have you set the encoding on the string going in. one sec. updating the gist.
22:30:05  <trevnorris>tjfontaine: sorry, run this and post the output in the comments please: https://gist.github.com/trevnorris/5818478
22:30:27  <trevnorris>sorry again. that should give me the results I'm looking for.
22:32:06  <tjfontaine>g:\scratch\node>Debug\node.exe statement.js
22:32:07  <tjfontaine><Buffer 19 61 19 61>
22:32:07  <tjfontaine><Buffer 19 61 19 61>
22:32:07  <tjfontaine><Buffer 19 20 61 00 19 20 61 00>
22:32:07  <tjfontaine><Buffer 19 61 19 61>
22:32:09  <tjfontaine><Buffer 19 61 19 61>
22:32:11  <tjfontaine><Buffer 19 20 61 00 19 20 61 00>
22:32:30  * loladiroquit (Quit: loladiro)
22:33:53  <trevnorris>tjfontaine: so that's for windows?
22:34:10  <trevnorris>yeah, of course it is :P
22:35:03  <tjfontaine>:)
22:35:22  * hzquit
22:35:56  * `3Echanged nick to `3E|ZZZ
22:36:05  <trevnorris>oy, i'm on one. totally missed the final ) in the first three.
22:36:36  <tjfontaine>ya I'm a big boy though :)
22:36:48  <trevnorris>tjfontaine: ok. so. the buffer output looks fine. this is getting confusing.
22:36:58  <trevnorris>tjfontaine: oh, didn't you say it's only through the python script that fails?
22:37:14  <tjfontaine>nah fails from cli as well
22:37:18  <trevnorris>ah, ok.
22:38:09  * dominictarrquit (Quit: dominictarr)
22:38:34  <tjfontaine>it's on the 4th iteration
22:39:17  <tjfontaine>commented ont he gist
22:39:18  <trevnorris>tjfontaine: can you add this above the for loop: assert.equal(buf.toString('ascii'), expected);
22:39:35  <trevnorris>tjfontaine: thanks.
22:39:59  <trevnorris>that for loop seems really strange to me.
22:43:48  <trevnorris>tjfontaine: what's that top line in the comment from?
22:43:59  <trevnorris>tjfontaine: oh, nm.
22:44:19  <trevnorris>so they're inputing the string as utf8, but then processing it as ascii
22:49:34  * kazuponjoined
22:51:13  <trevnorris>tjfontaine: well, if those are the buffers generated by windows then they're all correct.
22:51:35  <trevnorris>tjfontaine: have you verified if that assert throws?
22:52:04  <tjfontaine>yes, it's really failing :)
22:54:37  * kazuponquit (Ping timeout: 256 seconds)
22:56:23  <trevnorris>ok. so it's in the toString that's failing.
22:56:31  <tjfontaine>yes
22:59:01  <tjfontaine>it's not hittin that uinptr mask portion, but src_unalign, but not dest_unalign and then force_ascii
22:59:34  <trevnorris>tjfontaine: fwiw this is the first time the failure shows up: http://jenkins.nodejs.org/job/nodejs-master-windows/53/testReport/
23:02:32  * inolen1joined
23:02:37  * inolenquit (Ping timeout: 268 seconds)
23:02:53  * c4milojoined
23:03:11  <trevnorris>tjfontaine: the range of commits between failures doesn't have any code changes that affect that test. possible something on the build side changed?
23:04:27  <trevnorris>tjfontaine: oh wait. bnoordhuis set of buffer changes are in there.
23:04:31  <tjfontaine>trevnorris: actually http://jenkins.nodejs.org/job/nodejs-master-windows/34/testReport/
23:04:46  <trevnorris>wtf?
23:04:56  * paddybyersquit (Ping timeout: 256 seconds)
23:05:36  <tjfontaine>http://jenkins.nodejs.org/job/nodejs-master-windows/33/
23:05:37  <trevnorris>tjfontaine: oh. wasn't checking the order of results. thought x64 always showed up at the bottom.
23:05:38  <tjfontaine>that one
23:05:48  <tjfontaine>which is the stringbytes refactor merge :P
23:05:53  <tjfontaine>like I expected :)
23:06:08  <trevnorris>ah, yeah.
23:06:27  <trevnorris>tjfontaine: well, force_ascii existed in node_buffer.cc before string_bytes.cc
23:06:36  <trevnorris>tjfontaine: but must have gone through some changes between the two.
23:06:41  <tjfontaine>I'm just explaining the path it is taking
23:07:16  <tjfontaine>it's unfortunately frustrating to actually see this in the debugger because we're using char* and then we get the \0 and it truncates it
23:07:25  <tjfontaine>visually anyway
23:07:46  <trevnorris>well. it's failing also on http://jenkins.nodejs.org/job/nodejs-v0.10-windows/32/testReport/
23:09:15  <trevnorris>ah, yup. first failure: http://jenkins.nodejs.org/job/nodejs-v0.10-windows/17/
23:11:42  <trevnorris>tjfontaine: here it is: "const unsigned bytes_per_word = BITS_PER_LONG / CHAR_BIT;" -> "const unsigned bytes_per_word = sizeof(void*);"
23:12:27  <trevnorris>well, maybe not.
23:12:44  <tjfontaine>well
23:12:50  * trevnorristries to remember to not speak so quickly :P
23:12:56  * amartensquit (Quit: Leaving.)
23:12:59  * mikealjoined
23:13:51  <trevnorris>tjfontaine: oh, is "word*" -> "uintptr_t*" what you were talking about earlier?
23:15:11  * kevinswiberquit (Read error: Connection reset by peer)
23:15:43  * kevinswiberjoined
23:16:27  * timoxleyjoined
23:17:54  * defunctzombie_zzchanged nick to defunctzombie
23:18:39  <tjfontaine>trevnorris: there is a difference between bytes_per_word but I don't think that's the piece
23:19:23  * pachetquit (Ping timeout: 240 seconds)
23:20:17  <tjfontaine>hm
23:20:19  <trevnorris>tjfontaine: hm. well. those are the only two I listed changes between the two. force_ascii_slow is the same.
23:27:39  <tjfontaine>ok so using both pieces together makes it pass
23:28:27  <trevnorris>tjfontaine:but not w/ just one of them?
23:28:46  <tjfontaine>that's correct
23:29:04  * jez0990quit (Quit: No Ping reply in 180 seconds.)
23:29:11  * jez0990joined
23:29:29  <tjfontaine>I'm reverifying atm
23:29:32  <trevnorris>tjfontaine: do you know the sizeof uintptr_t in win x64? (just curious)
23:30:46  <tjfontaine>should be 8
23:31:34  <tjfontaine>yes, it's 8
23:32:57  <trevnorris>tjfontaine: what about sizeof(void*)?
23:34:24  * HenryRquit
23:34:41  <tjfontaine>god it should be 8 as well :)
23:34:59  <tjfontaine>yes 8
23:35:20  <tjfontaine>fwiw BITS_PER_LONG / CHAR_BIT is 4
23:36:23  <trevnorris>tjfontaine: eh? it should be 8, shouldn't it? 64 / 8
23:37:59  * kevinswiberquit (Remote host closed the connection)
23:38:37  <trevnorris>tjfontaine: the only way I could see that happening is if "#if defined(__x86_64__)" was false on win x64, which would lead to 32 / 8
23:39:13  <tjfontaine>bits_per_long is 32 :)
23:39:46  <trevnorris>tjfontaine: yup. that's a problem should be 64
23:40:06  <trevnorris>erm, wait. so it worked when it was 32
23:40:07  <bnoordhuis>it's a windows thing
23:40:13  <trevnorris>but now that it's 64 it's failing?
23:40:28  <bnoordhuis>on all 64 bits platforms sizeof(long) == sizeof(void*) - except on windows
23:40:44  <bnoordhuis>ms stuck to sizeof(long) == sizeof(int) for backward compat reasons
23:40:49  <tjfontaine>ok setting the check for BITS_PER_LONG to 32 works
23:41:58  * amartensjoined
23:42:41  <tjfontaine>bnoordhuis: should there be a second check there for _WIN64?
23:43:25  <bnoordhuis>tjfontaine: where?
23:43:59  <trevnorris>ah. so that means it's using the 32 bit mask but processing it 8 bits at a time, instead of 4?
23:44:13  <tjfontaine>yes
23:44:22  <tjfontaine>bnoordhuis: https://github.com/joyent/node/blob/v0.10/src/string_bytes.cc#L390
23:45:55  <bnoordhuis>tjfontaine: yeah
23:46:11  <bnoordhuis>it's defined in node_internals.h
23:46:22  <trevnorris>wait. think I have that reversed. bytes_per_word == 4, but BITS_PER_LONG == 64, so the for loop processes 4 bits at a time using the 8 bit mask.
23:46:48  * mikealquit (Quit: Leaving.)
23:46:57  <trevnorris>tjfontaine: lol, and my tests would've failed anyways since len < 16...
23:47:06  <tjfontaine>nod
23:47:25  <bnoordhuis>tjfontaine: but wait... is sizeof(long)==8 on windows 64?
23:48:18  <tjfontaine>at least in this build it is reporting 4
23:49:22  <bnoordhuis>right. in that case the __x86_64__ check is still sufficient
23:49:23  <trevnorris>LONG A 32-bit signed integer
23:49:23  <trevnorris>http://msdn.microsoft.com/en-us/library/windows/desktop/aa383751%28v=vs.85%29.aspx
23:51:02  * amartensquit (Quit: Leaving.)
23:53:54  <tjfontaine>is __x86_64__ a valid symbol?
23:54:12  <tjfontaine>for gcc apparently
23:54:47  * kevinswiberjoined
23:56:58  * brsonquit (Read error: Operation timed out)
23:57:09  * sblomquit (Read error: Connection reset by peer)
23:57:21  * sblomjoined