00:02:12  * paddybyersquit (Quit: paddybyers)
00:02:25  <creationix>EPERM huh...
00:02:34  <creationix>If I run my script as root it's fine
00:02:50  <creationix>also the same script in node (using an older libuv) is fine even without root
00:03:03  <creationix>reading /dev/input/js0 :)
00:03:59  <creationix>I'm using latest libuv on luvit. This worked a couple of days ago. It could be something in luvit, but I can't seem to figure it out
00:08:54  <igorzi>isaacs: on windows there's ERROR_NOACCESS and ERROR_ACCESS_DENIED.. both are already mapped to UV_EACCES
00:11:04  <isaacs>igorzi: what's the difference between them?
00:11:18  * mikealjoined
00:14:39  <igorzi>isaacs: actually ERROR_NOACCESS usually means bad memory address, while ERROR_ACCESS_DENIED means the current user doesn't have enough permissions
00:17:34  <isaacs>huh
00:17:39  <isaacs>so neither is actually EPERM
00:18:01  <isaacs>igorzi: what happens when you try to unlink a directory or something else that is just incorrect?
00:19:33  <igorzi>isaacs: you mean unlink non-existent directory?
00:20:07  <isaacs>igorzi: i mean unlink rather than rmdir
00:20:57  <isaacs>igorzi: or chown something to 0,0 or something
00:21:02  <isaacs>(if your'e not root)
00:21:48  <isaacs>igorzi: the issue is that it kind of sucks to have to check for code==="EACCES"||code==="EPERM" if it actually is something that causes EPERM
00:21:53  <isaacs>since the semantics are different
00:21:58  <isaacs>but, i mean, it's not the end of the world.
00:22:12  <isaacs>as long as we can remove the UV_UNKNOWN error here, then that's what's important.
00:23:52  <igorzi>isaacs: just confirmed unlinking a dir causes ERROR_ACCESS_DENIED
00:24:07  <igorzi>isaacs: chown on windows is a noop
00:24:56  <igorzi>isaacs: we could make specific code-paths convert ERROR_ACCESS_DENIED to EPERM
00:25:18  <igorzi>isaacs: besides unlinking a dir and chown, is there anything else that can cause EPERM?
00:27:10  <isaacs>igorzi: you can get eperm in a few ways
00:27:35  <isaacs>it's kind of a generic "you can't do that" error that some filesystems raise
00:28:20  <isaacs>passing an invalid date to utimes can do it, too
00:28:46  * CIA-114joined
00:29:47  <igorzi>isaacs: hmm, i wonder if we should map ERROR_ACCESS_DENIED to EPERM instead
00:29:58  <igorzi>isaacs: we could try that and see if we break any tests
00:30:21  <isaacs>sounds reasonable.
00:31:19  <igorzi>isaacs: i'll try it
00:36:38  <isaacs>igorzi: i'm going to land https://github.com/joyent/libuv/pull/297 unless you have objections
00:37:31  <igorzi>isaacs: no objections
00:37:59  <CIA-114>libuv: Brandon Philips v0.6 * r4cfda74 / (include/uv.h src/unix/error.c test/test-fs.c): (log message trimmed)
00:37:59  <CIA-114>libuv: uv.h: add EPERM to errno map to fix regression
00:37:59  <CIA-114>libuv: EPERM isn't mapped in so chown returns an unknown error. This is a
00:37:59  <CIA-114>libuv: regression from 0.4.12.
00:37:59  <CIA-114>libuv: philips:node/ (master*) $ cat chown.js
00:38:00  <CIA-114>libuv: var fs = require('fs')
00:38:00  <CIA-114>libuv: fs.chown("/tmp/foobar", 100, 100, function(er){ console.log(er);})
00:38:34  <philips>woo! :)
00:39:40  * travis-cijoined
00:39:40  <travis-ci>[travis-ci] joyent/libuv#70 (v0.6 - 4cfda74 : Brandon Philips): The build is still failing.
00:39:40  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/3eb94e9...4cfda74
00:39:40  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/607210
00:39:40  * travis-cipart
00:41:11  <isaacs>philips: thanks
00:41:51  <philips>isaacs: Happy to do it. We are getting a lot of <3 out of libuv between nodejs and luvit at Rackspace :)
00:42:01  <isaacs>sweet
00:43:50  <creationix>strange, I can't seem to pull
00:43:57  <creationix>isaacs, you merged into master right?
00:44:40  <isaacs>creationix: v0.6 branch
00:45:43  <creationix>ahh
00:45:52  <creationix>should I be pulling from that instead of master?
00:45:55  <creationix>(for luvit)
00:46:02  <isaacs>creationix: depends :)
00:46:11  <isaacs>creationix: is luvit tracking node v0.6, or 0.7?
00:46:20  <creationix>probably v0.6
00:46:25  <isaacs>creationix: not tracking node, per se, of course, but i mean, which is it more "like"
00:46:45  <creationix>well, since I don't know what all goes into 0.7, I'd say 0.6
00:46:49  <isaacs>:)
00:47:15  <creationix>so what's the policy on copying into master
00:47:25  <creationix>will this patch get landed there too
00:47:28  <isaacs>creationix: pretty much the same in node.
00:47:30  <isaacs>yeah, it's a bugfix
00:47:50  <TooTallNate>creationix: you could merge 0.6 into master locally if you're impatient :)
00:47:58  <isaacs>they're not terribly divergent
00:48:05  <creationix>0.6 is probably more stable
00:49:24  <creationix>hmm, still getting "UNKNOWN, unknown error"
00:49:40  <isaacs>creationix: doing what?
00:49:58  <creationix>I open /dev/input/js0, that works and I get a file descriptor
00:50:14  <creationix>but when I try to read 8 bytes from it at offset null, it blows up with an unknown error
00:50:26  <creationix>doing the same thing in node v0.6.8 works with no error
00:51:08  <creationix>https://gist.github.com/1696353
00:51:17  <creationix>it works three days ago, so I'm not sure what changed
00:52:00  <creationix>It is possible it's something in luvit, I just can't seem to track it down
00:59:37  <pquerna>strace -f it?
01:00:36  <TooTallNate>isaacs: hey do you have any thoughs on https://github.com/joyent/node/pull/2443?
01:02:58  <creationix>pquerna, https://gist.github.com/777cffcfe31c91cf65bd
01:03:40  <creationix>looks like "ESPIPE (Illegal seek)"
01:06:03  <pquerna>oh yeah, pread ;_/
01:06:36  <isaacs>oh, espipe
01:06:38  <isaacs>nice
01:06:42  <isaacs>that's a good one
01:08:11  <creationix>now tell me why this worked three days ago, but not now
01:08:19  <creationix>I can't find anything meaningful that changed
01:08:29  <creationix>hmm, except I was on a 32-bit machine and now I'm on 64-bit
01:08:45  <creationix>both linux
01:10:25  <pquerna>its doing the pread with an 8 offset though?
01:10:31  <pquerna>prolly needs to be 0?
01:15:07  <creationix>hmm, mixed up the arguments?
01:15:14  <creationix>it's should be null offset and 8 bytes to read
01:22:44  * dap1quit (Quit: Leaving.)
01:27:05  <igorzi>isaacs: confirmed; mapping ERROR_ACCESS_DENIED to EPERM doesn't break any tests
01:27:51  <igorzi>isaacs: i'd want to see what piscisaureus has to say about this.. maybe he knows of some use cases this would break
01:29:50  * mikealquit (Quit: Leaving.)
01:30:09  <CIA-114>node: Andreas Madsen master * r33b7fc2 / (2 files in 2 dirs): (log message trimmed)
01:30:09  <CIA-114>node: child_process: do not disconnect on exit emit
01:30:09  <CIA-114>node: When using isolate the .fork would break because it had
01:30:09  <CIA-114>node: no .disconnect method. This remove the exit handler there
01:30:09  <CIA-114>node: would call .disconnect since it was not required.
01:30:09  <CIA-114>node: It also change .disconnect to throw if the channel is closed,
01:30:10  <CIA-114>node: this was not possible before because .disconnect would be called
01:32:14  <isaacs>igorzi: sure, we can put it off
01:32:39  <isaacs>igorzi: i mean, get it in 0.6.10 maybe
01:33:51  <isaacs>igorzi: i'm cutting a 0.7.2 build, anything you wanna land in master first?
01:36:16  <igorzi>isaacs: yes, i'm going to land the stream-sharing code (across isolates)
01:36:54  <isaacs>fantastic
01:38:32  <CIA-114>node: Dan VerWeire v0.6 * r35b3d15 / (2 files): (log message trimmed)
01:38:33  <CIA-114>node: test: dgram-{broadcast,multicast}-multi-process : prevent false failures
01:38:33  <CIA-114>node: * check exit code of child processes
01:38:33  <CIA-114>node: * wait 1000 ms to exit the child process
01:38:33  <CIA-114>node: * prefix log messages with [PARENT] or [CHILD] to help debugging
01:38:33  <CIA-114>node: * kill all child processes before exiting
01:38:34  <CIA-114>node: Conflicts:
01:40:26  <isaacs>grrr...
01:40:32  <isaacs>out/Release/node /Users/isaacs/dev/js/node-v0.6/test/simple/test-fs-chmod.js is failing so obscurely
01:40:34  <isaacs>and randomly
01:40:48  <isaacs>AssertionError: 511 == 420
01:41:28  <tjfontaine>511 is 0777
01:41:32  <isaacs>yeah
01:42:16  * pieternjoined
01:43:13  * mikealjoined
01:44:14  * travis-cijoined
01:44:14  <travis-ci>[travis-ci] joyent/node#346 (master - 33b7fc2 : Andreas Madsen): The build is still failing.
01:44:14  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/03c4aa6...33b7fc2
01:44:14  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/607271
01:44:14  * travis-cipart
01:46:27  * travis-cijoined
01:46:27  <travis-ci>[travis-ci] joyent/node#347 (v0.6 - 35b3d15 : Dan VerWeire): The build was fixed.
01:46:27  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/fa490f6...35b3d15
01:46:27  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/607305
01:46:27  * travis-cipart
01:49:34  <CIA-114>node: Igor Zinkovsky master * rdb3c4ef / (4 files in 2 dirs): support for sharing streams accross isolates - http://git.io/0W2xDw
01:49:47  <igorzi>isaacs: --^
01:49:48  <kohai>isaacs has 6 beers
01:50:01  <isaacs>sweet
01:50:03  <isaacs>thanks
01:51:00  <CIA-114>node: Paddy Byers v0.6 * r840229a / lib/module.js : Tidy _resolveFilename - http://git.io/n2exdg
01:51:02  <CIA-114>node: Paddy Byers v0.6 * r7e0bf7d / lib/module.js : Process symlinked shared library as .node - http://git.io/EX7T5A
01:53:28  <isaacs>ohhh... crap.
01:53:30  <isaacs>the docs.
01:53:33  <isaacs>oh, man.
01:53:41  <isaacs>i should NOT have put this off.
01:55:48  <TooTallNate>isaacs: interesting, when would you require a .dylib file?
01:56:11  <isaacs>TooTallNate: i dunno.
01:56:19  <isaacs>TooTallNate: but we ought to treat it as a dynamic library
01:59:09  * travis-cijoined
01:59:09  <travis-ci>[travis-ci] joyent/node#349 (v0.6 - 7e0bf7d : Paddy Byers): The build passed.
01:59:09  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/35b3d15...7e0bf7d
01:59:09  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/607346
01:59:09  * travis-cipart
02:00:41  <isaacs>igorzi: deps/uv/test/test-udp-options.c gone, that's expected, yes?
02:00:46  <isaacs>or am i screwing something up?
02:01:29  <isaacs>oh, wait, i didn't merge 0.6 inot libuv master first.
02:05:06  * travis-cijoined
02:05:06  <travis-ci>[travis-ci] joyent/node#348 (master - db3c4ef : Igor Zinkovsky): The build is still failing.
02:05:06  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/33b7fc2...db3c4ef
02:05:06  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/607334
02:05:06  * travis-cipart
02:08:37  * pieternquit (Quit: pietern)
02:12:40  <isaacs>igorzi: think it's safe/wise to merge libuv v0.6 into master?
02:13:30  <isaacs>merging node v0.6 into node master doesn't quite make sense without doing so.
02:17:21  <igorzi>isaacs: yep, that should be safe
02:17:30  <isaacs>k
02:17:52  <CIA-114>libuv: isaacs master * r243cfcd / (12 files in 5 dirs): Merge remote-tracking branch 'ry/v0.6' (+7 more commits...) - http://git.io/H-4Cdw
02:19:49  * travis-cijoined
02:19:49  <travis-ci>[travis-ci] joyent/libuv#71 (master - 243cfcd : isaacs): The build is still failing.
02:19:49  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/812e410...243cfcd
02:19:49  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/607441
02:19:49  * travis-cipart
02:22:37  * TooTallNatequit (Quit: Linkinus - http://linkinus.com)
02:23:20  <CIA-114>node: Paddy Byers master * r840229a / lib/module.js : Tidy _resolveFilename - http://git.io/n2exdg
02:23:20  <CIA-114>node: Paddy Byers master * r7e0bf7d / lib/module.js : Process symlinked shared library as .node - http://git.io/EX7T5A
02:23:21  <CIA-114>node: isaacs master * r18d179c / (152 files in 23 dirs): (log message trimmed)
02:23:21  <CIA-114>node: Merge remote-tracking branch 'ry/v0.6' into master
02:23:21  <CIA-114>node: Conflicts:
02:23:21  <CIA-114>node: ChangeLog
02:23:22  <CIA-114>node: deps/uv/src/unix/udp.c
02:23:22  <CIA-114>node: deps/uv/src/win/fs.c
02:23:23  <CIA-114>node: deps/uv/src/win/udp.c
02:23:23  <CIA-114>node: isaacs master * rbd21038 / (4 files in 2 dirs): Merge remote-tracking branch 'ry/master' into merge-v0.6 - http://git.io/3C6AbA
02:25:12  <isaacs>hm... that also updates libuv. kind of not as atomic as i should've done. oh well.
02:33:37  * brsonquit (Quit: leaving)
02:35:48  <CIA-114>node: isaacs master * r05471f5 / (91 files in 13 dirs): Update v8 to 3.8.9 - http://git.io/sk6qmA
02:37:31  <isaacs>ok, everything's basicaly in place to do the 0.7.2 build. i gotta run more tests on it and get home, though.
02:37:35  <isaacs>so many meetings today..
02:38:22  * travis-cijoined
02:38:22  <travis-ci>[travis-ci] joyent/node#350 (master - bd21038 : isaacs): The build is still failing.
02:38:22  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/db3c4ef...bd21038
02:38:22  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/607472
02:38:22  * travis-cipart
02:44:27  * mikealquit (Quit: Leaving.)
02:45:49  * isaacsquit (Remote host closed the connection)
02:48:25  * mikealjoined
02:50:30  * travis-cijoined
02:50:30  <travis-ci>[travis-ci] joyent/node#351 (master - 05471f5 : isaacs): The build is still failing.
02:50:30  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/bd21038...05471f5
02:50:30  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/607509
02:50:30  * travis-cipart
02:52:23  <creationix>so I narrowed down my weird "UNKNOWN" error
02:52:40  <creationix>the thing that triggers it is the luvit equivalent to console.log
02:54:26  <creationix>if I comment out 'p("start_read")' on line 37, the read works
02:54:27  <creationix>https://gist.github.com/8af27d5ab5535b01f40b#file_joystick2.lua
02:54:39  <creationix>otherwise it blows up with UNKNOWN error
02:55:42  <creationix>p() internally does a process.stdout.write call, but in the strace, it's the pread that's throwing the EPIPE error
02:58:20  * dapjoined
02:58:40  * dshaw_quit (Ping timeout: 245 seconds)
03:00:36  * AvianFluquit (Quit: Leaving)
03:06:09  * dapquit (Quit: Leaving.)
03:31:24  * isaacsjoined
03:44:31  <CIA-114>libuv: isaacs master * r6e995bd / AUTHORS : Update AUTHORS - http://git.io/CabFuA
03:46:32  * travis-cijoined
03:46:32  <travis-ci>[travis-ci] joyent/libuv#72 (master - 6e995bd : isaacs): The build is still failing.
03:46:32  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/243cfcd...6e995bd
03:46:32  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/607711
03:46:32  * travis-cipart
03:48:07  * logicalparadoxjoined
03:50:27  * isaacsquit (Ping timeout: 245 seconds)
03:57:10  * mikealquit (Quit: Leaving.)
04:39:46  * mikealjoined
04:47:30  * logicalp_joined
04:48:07  * logicalparadoxquit (Ping timeout: 248 seconds)
04:48:08  * logicalp_changed nick to logicalparadox
05:02:24  * mikealquit (Quit: Leaving.)
05:09:03  * dshaw_joined
05:14:08  * mikealjoined
06:01:22  * mikealquit (Quit: Leaving.)
06:04:41  * isaacsjoined
06:32:01  * paddybyersjoined
06:32:38  * isaacsquit (Remote host closed the connection)
07:03:41  * mralephjoined
07:07:13  * ErikCorryHomejoined
07:12:23  * mikealjoined
07:17:08  * paddybyersquit (Quit: paddybyers)
07:24:24  * mikealquit (Quit: Leaving.)
07:38:43  * paddybyersjoined
07:40:54  * isaacsjoined
07:53:04  * orlandovftwquit (Ping timeout: 260 seconds)
08:06:27  * mikealjoined
08:10:03  * mikealquit (Client Quit)
08:27:40  * mralephquit (Quit: Leaving.)
08:54:39  * mikealjoined
08:55:29  * isaacsquit (Remote host closed the connection)
08:58:30  * mikealquit (Client Quit)
09:07:09  * mralephjoined
09:12:19  * orlandovftwjoined
09:16:34  * ErikCorryHomequit (Ping timeout: 245 seconds)
09:21:36  * dshaw_quit (Quit: Leaving.)
09:24:33  * mikealjoined
09:46:13  * mikealquit (Quit: Leaving.)
09:48:27  * mikealjoined
10:10:09  * logicalparadoxquit (Quit: Peace, I'm out.)
10:56:41  * orlandovftwquit (Ping timeout: 272 seconds)
11:00:41  * igorziquit (Remote host closed the connection)
12:54:16  * logicalparadoxjoined
13:10:25  * indutny_sleepingchanged nick to indutny
13:50:18  * piscisaureus_joined
13:57:33  <piscisaureus_>mraleph: bnoordhuis: http://screencast.com/t/vtOdb1yz5wu
13:58:18  <piscisaureus_>^-- that's making an API call that does nothing whatsoever (except create a HandleScope and return Undefined()) in a tight loop
13:58:28  <mraleph>well yeah.
13:59:22  <mraleph>I have stared at this (well, minus the fact that I am not using windows) picture several times :-)
13:59:33  <piscisaureus_>It does a lot of synchronization
14:00:14  <mraleph>yeah, it does.
14:00:28  <piscisaureus_>InterlockedExchangeAdd seems to account for 30% of the total call overhead
14:00:55  <piscisaureus_>v8::Internal::TypeCheck is also quite hot
14:03:48  <mraleph>I am actually not sure that synchronisation is required.
14:04:40  <piscisaureus_>mraleph: if it is, it could be beneficial to use a single lock for all the synchronization instead of many
14:05:38  <mraleph>strictly speaking there should be no lock, there should be compare-and-swap primitive.
14:06:02  <mraleph>one can try to use compiler intrinsic instead of calling function
14:06:06  <piscisaureus_>mraleph: yeah... well that is also a sort of lock
14:06:15  <mraleph>yes, it is :-)
14:06:55  <mraleph>I wonder if we can make uncontended case cheaper.
14:08:04  <piscisaureus_>mraleph: but at least on 32 bit MSVC _InterlockedExchangeAdd is not treated as a compiler intrinsic
14:08:27  <mraleph>you can probably tweak some magical compilation options.
14:08:52  <piscisaureus_>I doubt it , but I will try]
14:09:23  <piscisaureus_>mraleph: I can confirm that InterlockedExchange *is* treated as a compiler intrinsict
14:09:30  <piscisaureus_>and _BitCountReverse etc
14:09:43  <piscisaureus_>so I am afraid the compiler just does not support it and falls back to a library call
14:09:59  <mraleph>this is just broken :-(
14:10:21  <mraleph>there should be CPU target configurable somewhere.
14:10:39  <indutny>I hope I won't write apps for win32
14:10:40  <indutny>ever
14:11:00  <mraleph>maybe it falls back because it wants to support 286 or something.
14:11:13  * bnoordhuisjoined
14:11:22  <mraleph>indutny: gcc also has different CPU targets available :-)
14:12:35  <mraleph>piscisaureus_: but more important question really is: can the same functionality be implemented without lock (or LOCK-prefixed instructions). My gut tells me it can but I would need to think about it carefully.
14:13:10  <piscisaureus_>mraleph: well, what are the purpose of the locks?
14:14:05  <mraleph>it's not a lock, it's atomic increment of a counter that tracks how many isolates are in JS right now and uses that counter to figure out whether runtime profiler should be suspended or continue to run.
14:14:50  <piscisaureus_>mraleph: is it really important that that counter is accurate at all times?
14:14:51  <mraleph>if runtime profiler is not suspended when nobody is in Chrome than Chrome's power consumption becomes very upsetting :-)
14:15:59  <mraleph>well it should not loose neither increments nor decrements because if it looses increment then some long running JS my be run without optimizations, if it loses decrement we might forget to suspend profiler.
14:16:45  <mraleph>but I think entirely different model can be used.
14:16:48  <indutny>mraleph: I suppose chrome doesn't have many isolates
14:16:58  <indutny>mraleph: you can just use bits for that
14:17:03  <piscisaureus_>mraleph: could you not make an array or something?
14:17:05  <mraleph>indutny: webworkers are isolates.
14:17:09  <indutny>mraleph: oooh
14:17:13  <indutny>righto
14:17:25  <mraleph>indutny: also making something into bits does not solve atomicity problem.
14:17:35  <indutny>mraleph: you don't need it
14:17:39  <indutny>mraleph: atomictiy
14:17:44  <indutny>mraleph: just check if value is zero
14:17:48  <piscisaureus_>mraleph: activeIsolates[isolate->Index()] = 1 ?
14:17:49  <mraleph>piscisaureus_: yep, I am thinking in that direction about that.
14:17:51  <indutny>ah, got it
14:18:06  <mraleph>indutny: clearing and setting bit would have to be atomic.
14:18:07  <indutny>anyway, bits, arrays
14:18:12  <indutny>are essentially the same
14:18:55  <piscisaureus_>mraleph: the only thing is - how does the profiler gets woken up when it is asleep?
14:19:13  <piscisaureus_>(excuse me for my terrible grammar)
14:19:57  <mraleph>piscisaureus_: by a semaphor signal
14:20:30  <mraleph>in any case, I have to do some work :-)
14:20:35  <piscisaureus_>ok
14:20:43  <mraleph>I will think about it more.
14:20:54  <indutny>piscisaureus_: I think v8 team is using semaphores just for everything :D
14:20:54  <piscisaureus_>mraleph: this does not count as "work" ?
14:21:04  <indutny>piscisaureus_: seen at least two in debugger
14:21:05  <mraleph>if you come up with something nice ping me.
14:21:38  <mraleph>piscisaureus_: this counts, but I have certain priorities and experiments in the pipeline of my brain :-)
14:21:53  <piscisaureus_>mraleph: ah. ok good luck
14:21:55  <bnoordhuis>piscisaureus_: https://github.com/joyent/libuv/issues/263#issuecomment-3750032
14:22:14  <indutny>brb
14:22:19  <bnoordhuis>i suppose that change needs to go in the gyp file as well?
14:22:38  <piscisaureus_>bnoordhuis: yep
14:22:57  <bnoordhuis>okay, i'll fix it
14:27:04  <CIA-114>libuv: Ben Noordhuis master * r65bbf02 / uv.gyp :
14:27:04  <CIA-114>libuv: build: bump _WIN32_WINNT to 0x600
14:27:04  <CIA-114>libuv: Commit b471b33 updated the Makefile, this commit updates the gyp file. - http://git.io/q4IZYQ
14:30:10  <bnoordhuis>paddybyers: Putting a lock around the call to getaddrinfo and then synchronising every other operation that potentially interferes on that lock would be as bad, or worse, since those operations would then interfere even if nobody is calling getaddrinfo.
14:30:32  <bnoordhuis>maybe i misunderstand but that mutex would only affect getaddrinfo calls, right?
14:31:34  * travis-cijoined
14:31:34  <travis-ci>[travis-ci] joyent/libuv#73 (master - 65bbf02 : Ben Noordhuis): The build is still failing.
14:31:34  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/6e995bd...65bbf02
14:31:34  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/609765
14:31:34  * travis-cipart
14:31:42  <paddybyers>well on Android I gather there's a more general problem; it's not just getaddrinfo calls interfering with other getaddrinfo calls
14:32:09  <paddybyers>so I don't even know what else you would need to synchronise. I can dig up some links
14:32:44  <paddybyers>our crash was when the non-event-loop thread called getaddrinfo while something else was using libc stuff
14:35:03  <paddybyers>bnoordhuis: btw do you know andres@joyent.com ? He reported the problem from testing on Android
14:35:35  <bnoordhuis>paddybyers: no, i don't know him
14:36:01  <bnoordhuis>paddybyers: so what's a good solution?
14:36:55  <paddybyers>bnoordhuis: I know one solution that works, which is to put the getaddrinfo call into the event loop
14:37:39  <paddybyers>I also saw the Mozilla did a different workaround that put some locking in to avoid doing the same thing, so I need to look at that and understand what they did
14:38:49  <bnoordhuis>paddybyers: 'put the getaddrinfo call into the event loop' means 'do the getaddrinfo call from inside the main thread'?
14:38:57  <paddybyers>yes
14:39:08  <paddybyers>I know that's bad
14:39:46  <paddybyers>this is the Mozilla bug: https://bugzilla.mozilla.org/show_bug.cgi?id=687367
14:40:48  <bnoordhuis>"In bionic (ugh), domain name functions (getaddrinfo, gethostbyname_r, et al) are not thread-safe because stdio is not thread-safe... These functions rely on stdio for reading from the /etc/hosts file."
14:40:54  <bnoordhuis>*sigh*
14:40:59  <paddybyers>the key bit seems to be: "reimplement _gethtent() without stdio calls"
14:41:54  <paddybyers>so what did the switch do in the old cares implementation? Just lock around getaddrinfo?
14:41:56  <piscisaureus_>we just need a single dedicated getaddrinfo thread for that I think
14:43:53  <paddybyers>so in later Androids they use mmap() instead of stdio
14:44:12  <bnoordhuis>paddybyers: i don't think c-ares uses getaddrinfo
14:45:24  <bnoordhuis>piscisaureus_: doing it from a separate thread may accidentally work
14:45:40  <bnoordhuis>but the real issue is apparently with stdio
14:45:50  <paddybyers>so why HAVE_GETADDRINFO_THREADSAFE then?
14:47:45  <bnoordhuis>paddybyers: i don't know but i'm quite sure that c-ares never used it
14:48:05  <paddybyers>it looks maybe like they just pinched all that from curl
14:48:25  <bnoordhuis>yeah, that wouldn't surprise me
14:49:08  <bnoordhuis>so you're proposing to pull in bionic's getaddrinfo() and rework the code that reads /etc/host?
14:49:21  <piscisaureus_>mraleph: by looking at winbase.h I can tell that the intrinsics are not supported on x32
14:49:32  <piscisaureus_>mraleph: that looks fucked up
14:50:19  <mraleph>yeah, that calls for some experiments with inline assembly :-)
14:51:04  <piscisaureus_>mraleph: I will try to figure out why they are not disabled. As far as I can tell winbase.h disables them but I am not sure they are not supported
14:51:23  <paddybyers>bnoordhuis: I don't think that would be a portable solution; but that's what you'd have to do on Android to avoid doing it in the event thread
14:51:54  <bnoordhuis>paddybyers: yeah, i'm not suggesting to do that for all platforms :)
14:52:00  <paddybyers>I was thinking that there was something there previously before the move to libuv, but obviously not
14:52:10  <bnoordhuis>no, indeed
14:52:42  <bnoordhuis>paddybyers: you can't use some linker overload magic to monkey-patch the stdio functions?
14:53:07  * bnoordhuishas no clue how the dynamic linker works on android
14:53:32  <paddybyers>me too :) I would worry about what else would break
14:54:26  <paddybyers>Since the older Androids will be obsolete soon enough I might stick with the current hack
14:54:43  <bnoordhuis>do people actually update their phones?
14:55:10  <bnoordhuis>i have this htc hero somewhere that i think is still running 1.5
14:55:23  <piscisaureus_>mraleph: chrome is also 32 bit on windows right?
14:56:00  <paddybyers>I will maybe do the same thing as Mozilla did
14:56:38  <paddybyers>my original question was to ask if there's something generic that you can do, but I guess the answer is no
14:56:46  <bnoordhuis>paddybyers: indeed
14:57:03  <bnoordhuis>if you can come up with a fix that's not too intrusive, i'll happily merge it
14:57:17  <mraleph>piscisaureus_: yep
14:58:07  <paddybyers>I can't think of anything generic. I'll close the issue then. thanks for looking anyway
14:59:01  <bnoordhuis>paddybyers: my pleasure. let me know if you come up with something
14:59:08  <paddybyers>thanks
15:31:03  <piscisaureus_>omg
15:31:17  <piscisaureus_>the compiler intrinsics story is so fucked up :-(
15:34:22  <piscisaureus_>So microsoft C compiler *does* support _Interlocked* intrinsics on x32 but C++ does not
15:34:39  <piscisaureus_>on x64 they are always supported
15:35:22  <piscisaureus_>And the SDK headers make no attempt to use the intrinsics on x32 ever, even when they are supported (because the C compiler is used)
15:36:01  <tjfontaine>you could always switch to managed :)
15:39:08  <piscisaureus_>what if I were writing a runtime
15:45:19  <creationix>piscisaureus_, clearly, the solution is to stop using C++ and stick to C ;)
15:45:29  <creationix>Tell the V8 team to get on that
15:45:33  <piscisaureus_>creationix: yeah tell the v8 guys that :-)
15:45:45  * logicalparadoxquit (Quit: Computer has gone to sleep.)
15:46:08  <piscisaureus_>creationix: the problem is still that the windows SDK headers are supposed to enable intrinsics whenever they are supported
15:46:18  <piscisaureus_>creationix: but clearly they don't on x32
16:03:58  <piscisaureus_>http://en.wikipedia.org/wiki/Wikipedia:Wikipedia_Signpost/2012-01-30/Technology_report
16:07:34  * isaacsjoined
16:14:13  <isaacs>good mornafternoon
16:15:41  <creationix>isaacs, get some sleep?
16:15:51  <isaacs>creationix: yeah
16:15:59  <creationix>good
16:16:08  <isaacs>creationix: but a lot of the people who hang in this room are in europe or other places.
16:18:20  <creationix>I understand. Most the luvit community is not in this hemisphere
16:20:28  * sh1mmerquit (Quit: sh1mmer)
16:23:17  <isaacs>orly? south america or australia?
16:23:36  <isaacs>or do you mean east/west?
16:24:06  <creationix>east-west
16:24:18  <creationix>though tim-smart is still in New Zealand right?
16:26:35  <isaacs>i'm not sure
16:31:07  * AvianFlujoined
16:37:53  * pieternjoined
17:01:43  <creationix>wow, my joystick program is good at finding "UNKNOWN" errors in libuv
17:01:55  <creationix>now I'm getting EINPROGRESS when connecting to a tcp server and it's throwing "UNKNOWN"
17:03:42  <piscisaureus_>creationix: wow. you should put a breakpoint where it generates UNKNOW
17:03:56  <piscisaureus_>creationix: then look at the system errno and figure out what it is
17:04:12  * isaacsquit (Ping timeout: 255 seconds)
17:05:08  <creationix>piscisaureus_, how do I set a breakpoint?
17:06:26  * isaacsjoined
17:08:45  <bnoordhuis>creationix: are you using gdb?
17:13:32  <isaacs>piscisaureus_, bnoordhuis: didn't we expose the system errno at some point?
17:13:48  <isaacs>piscisaureus_, bnoordhuis: i seem to remember that being a thing. but now when i get UNKNOWN, i can't seem to find it.
17:14:02  <piscisaureus_>isaacs: yeah I think it would also be available as uv_last_error(loop)._sys_errno
17:14:11  <piscisaureus_>isaacs: unless it got removed
17:14:16  <isaacs>piscisaureus_: hm, ok
17:14:23  <isaacs>we should put that on the Error objects we generate for node.
17:14:41  <isaacs>it's incredibly helpful in times when you need all the help you can get.
17:14:45  <piscisaureus_>isaacs: yeah
17:15:04  <piscisaureus_>isaacs: theyre not really useful on windows atm though
17:15:09  <piscisaureus_>but we could change that
17:15:24  <isaacs>they're more useful than "UNKNOWN" :)
17:16:04  <piscisaureus_>at least not less useful
17:16:10  <isaacs>piscisaureus_, bnoordhuis, igorzi, indutny: can you review the ChangeLog, please? https://gist.github.com/c680be6cf5489e9db8f8
17:16:16  <isaacs>bbiab
17:16:59  <bnoordhuis>lgtm
17:17:05  * dapjoined
17:19:38  <indutny>isaacs: commented on gist, otherwise lgtm
17:24:02  * sh1mmerjoined
17:24:26  <isaacs>indutny: ah! yes, the dictionary thing is a big deal. spdy is important.
17:24:28  <isaacs>thanks
17:25:25  <isaacs>even though it's a pretty minor bugfix, i think someone was asking about it directly
17:25:45  * dshaw_joined
17:26:21  <indutny>isaacs: thanks
17:27:41  <isaacs>indutny: can you tell me anything about 85a86b5 the node-waf target arch thing?
17:27:48  <isaacs>indutny: sorry, i'm not entirely clear on the actual issue.
17:30:20  * orlandovftwjoined
17:36:06  <indutny>isaacs: meh, nvm
17:36:15  <indutny>that's not so important, actually
17:36:33  <indutny>isaacs: problem is that node-waf build for system's arch
17:36:42  <indutny>while node is built for i386 on osx
17:36:54  <indutny>and while it builds fine
17:37:07  <indutny>x64 addons ain't working with i386 node
17:37:09  <indutny>that's it
17:37:11  <indutny>isaacs: ^
17:37:30  <isaacs>ohhh, ok
17:37:31  <isaacs>i get it
17:38:16  * isaacsfreaking 64 bit ruining everything everywhere.
17:39:19  <indutny>yeah
17:39:21  <tjfontaine>gotta make em fat
17:39:52  * lwillejoined
17:40:19  <isaacs>man, this is gonna suck for doing binary deployments, too
17:41:18  <tjfontaine>can't make them universal?
17:46:58  <isaacs>ok, yeah, that belongs in the changelog
17:50:02  <indutny>tjfontaine: could shared libraries be universal?
17:51:33  <tjfontaine>indutny: yes, first example http://paste.debian.net/hidden/fe0870c5/
17:51:40  <tjfontaine>(first example I found)
17:53:22  * `3rdEdenjoined
17:54:07  <indutny>tjfontaine: cool
17:54:07  <isaacs>indutny: ok, updated gist
17:55:08  <indutny>isaacs: lgtm
17:55:11  <indutny>thanks
17:57:45  * dshaw_quit (Quit: Leaving.)
17:57:49  * AndreasMadsenjoined
18:01:13  * `3rdEdenquit (Read error: Connection reset by peer)
18:07:22  <mmalecki>isaacs: hi! you've mentioned node's http is leaking. any news on this issue? any bug report regarding this?
18:07:46  <isaacs>mmalecki: should be fixed in 0.6.9
18:07:57  <mmalecki>isaacs: oh! ok! thanks
18:08:42  * dshaw_joined
18:09:34  * `3rdEdenjoined
18:11:26  <isaacs>mmalecki: was leaking parser instances under load.
18:12:23  <mmalecki>isaacs: I know, seen some small leaks in production
18:15:10  * mralephquit (Quit: Leaving)
18:18:43  * TooTallNatejoined
18:26:29  * indutnychanged nick to indutny_sleeping
18:26:31  <indutny_sleeping>ttyl
18:34:23  * mikealquit (Quit: Leaving.)
18:38:10  * mikealjoined
18:42:41  <piscisaureus_>mraleph: https://gist.github.com/1718568 <-- make msvc use intrinsics on x32
18:43:24  <piscisaureus_>mraleph: So this works for me - but since you are building stuff with different msvc / sdk versions the problem may not exist for you guys, or my patch may not work
18:43:33  <piscisaureus_>mraleph: so who should I talk to about it?
18:50:17  * mikealquit (Quit: Leaving.)
18:55:03  <isaacs>test, please: http://nodejs.org/dist/v0.7.2/node-v0.7.2-RC0.tar.gz
18:55:18  <isaacs>er, wait a second...
18:55:36  <isaacs>k, go go
18:56:58  * mikealjoined
18:58:02  * igorzijoined
18:59:17  * orlandovftwquit (Ping timeout: 272 seconds)
18:59:58  <igorzi>piscisaureus_: hey.. yt?
19:05:05  <piscisaureus_>igorzi: hey
19:05:13  <piscisaureus_>igorzi: sup?
19:05:57  <igorzi>piscisaureus_: are you opposed to mapping ERROR_ACCESS_DENIED to UV_EPERM instead of UV_EACCES ?
19:06:15  <igorzi>piscisaureus_: it doesn't break any tests
19:06:48  <piscisaureus_>igorzi: from the top of my head I can't think of anything.
19:06:52  <piscisaureus_>igorzi: why?
19:06:57  <piscisaureus_>bnoordhuis: so a v8 api call takes ~170 cycles on my machine
19:07:53  <igorzi>piscisaureus_: to get consistency between windows and unix.. on unix unlinking a directory causes EPERM.. on windows it's ERROR_ACCESS_DENIED
19:08:09  <piscisaureus_>igorzi: yeah, fine, do it
19:08:19  <igorzi>piscisaureus_: k
19:08:29  <igorzi>isaacs: ---^
19:08:30  <kohai>isaacs has 5 beers
19:08:43  <piscisaureus_>Isaacs: [06:05|% 100|+ 363|- 21]: Done
19:08:55  <isaacs> piscisaureus_: that's on windows?
19:09:33  <piscisaureus_>isaacs: yup
19:09:56  <isaacs>OS X: [04:00|% 100|+ 347|- 10]: Done
19:10:16  <isaacs>not so bad for an unstable release, i guess.
19:10:18  * brsonjoined
19:10:23  <piscisaureus_>depends :-)
19:10:27  <isaacs>there's one isolates test that occasionally does really weird things.
19:10:39  <piscisaureus_>isolates suck
19:10:40  <isaacs>looks like AndreasMadsen has some pull requests that might fix it, but that'll have to wait for 0.7.3
19:10:58  <isaacs>piscisaureus_: i hear you, man.
19:11:08  <igorzi>isaacs: which isolate test?
19:11:17  <isaacs>piscisaureus_: they're going to have to really earn their keep here very soon, i think.
19:11:42  <isaacs>igorzi: simple/test-isolates3
19:12:01  <isaacs>igorzi: simple/test-isolates2 as well
19:12:15  <isaacs>sometimes they fail on os x, but sometimes they go into some odd state that confuses the test runner and never times out.
19:12:27  <isaacs>went and made some coffee, came back, still hadn't timed out.
19:12:30  <isaacs>very odd.
19:12:35  <isaacs>ran again and it failed right away
19:13:38  <isaacs>out/Release/node test/simple/test-script-new.js <-- assertion error
19:13:45  <isaacs>DEBUG: invalid this
19:13:45  <isaacs>Assertion failed: (handle->InternalFieldCount() > 0), function Unwrap, file ../src/node_object_wrap.h, line 52.
19:13:45  <isaacs>Abort trap: 6
19:14:02  <igorzi>isaacs: simple/test-isolates2 hangs because kill isn't implemented for isolates (and i suspect that it won't :))
19:15:16  <bnoordhuis>piscisaureus_: 170 cycles? what does a non-inlined c function call cost?
19:15:33  <creationix>pquerna, libssh or libssh2?
19:15:42  <creationix>hmm, wrong window
19:15:42  <bnoordhuis>piscisaureus_: or a javascript to javascript function call, provided it doesn't get optimized away
19:15:46  <piscisaureus_>bnoordhuis: *shrug*
19:15:52  <piscisaureus_>didn't test
19:16:23  <igorzi>piscisaureus_: are you using windbg?
19:16:53  <piscisaureus_>igorzi: no I just count how long it takes to do 1B api calls
19:17:05  <piscisaureus_>igorzi: and then do the math
19:17:55  <AvianFlu>a few test failures from debian 6.02 for you: https://gist.github.com/ef612e5710a6c1e0f8ff
19:18:05  <igorzi>piscisaureus_: windbg has a nice "wt" command to do that
19:18:52  <bnoordhuis>simple/test-typed-arrays-typenames is known broken
19:19:15  <igorzi>piscisaureus_: you just run "wt" whan you're on a call instruction, and then it counts how many instructions are executed by doing the call
19:19:32  <bnoordhuis>simple/test-dgram-pingpong is a poor test that we should either fix or axe some time
19:19:51  <piscisaureus_>igorzi: k, will try. Haven't used windbg much
19:37:30  <AndreasMadsen>hi
19:38:05  * piscisaureus_leaves
19:38:08  * piscisaureus_bbl
19:38:12  <isaacs>whoops, forgot the version release flag
19:40:23  * orlandovftwjoined
19:42:49  * stephankjoined
19:47:58  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
19:54:35  * sh1mmerquit (Quit: sh1mmer)
19:59:29  * brsonquit (Quit: leaving)
19:59:55  * brsonjoined
19:59:59  * brsonquit (Client Quit)
20:09:50  <AndreasMadsen>isaacs: igorzi: do you know that when using isolates process.exit(0) need to be executed twice in a child
20:10:21  <isaacs>AndreasMadsen: that's weird.
20:10:30  <AndreasMadsen>sec
20:11:25  <AndreasMadsen>isaacs: https://gist.github.com/1719044
20:11:41  <AndreasMadsen>Tty with only one, it nothing happens
20:12:21  <isaacs>well.. that's clearly a bug.
20:12:23  <isaacs>:)
20:13:18  <AndreasMadsen>Should I post it?
20:13:37  <isaacs>yes, please.
20:17:16  <AndreasMadsen>https://github.com/joyent/node/issues/2665
20:17:35  <AndreasMadsen>There is just so many isolate issues :/
20:19:54  * mralephjoined
20:21:31  * piscisaureus_joined
20:22:51  <igorzi>piscisaureus_ isaacs: http://groups.google.com/group/nodejs/browse_thread/thread/efa1ecf5559317b7#
20:23:06  <igorzi>maybe unstable releases don't need an msi? just node.exe?
20:24:23  <isaacs>igorzi: hm.
20:24:31  <isaacs>can't you remove it manually through the control panel?
20:24:38  <igorzi>isaacs: yep
20:24:47  <igorzi>isaacs: maybe that's not really an issue
20:25:13  <isaacs>maybe the msi just isn't wise about downgrading automatically like it is about upgrading automatically?
20:25:14  <isaacs>i dunno.
20:25:28  <isaacs>i'm perfectly fine with not uploading an msi for unstable versions.
20:25:50  <igorzi>then people won't get npm automatcially.. hmm
20:25:55  <isaacs>right
20:26:02  <isaacs>and installing npm on windows is rather painful otherwise.
20:26:22  <isaacs>maybe we shouldn't even release binaries of unstable versions.
20:26:36  <isaacs>except... that sucks, because we *do* want people to use them.
20:26:42  <igorzi>right
20:26:59  <igorzi>maybe just binaries, but not installers is a good middle ground
20:27:01  <isaacs>except... that sucks, because we *do* want people to use them.?
20:27:04  <isaacs>can the MSI be made to uninstall *any* existing version, even if it's a "downgrade"?
20:27:36  <tjfontaine>my understanding is yes, but I'm not a windows release manager
20:27:43  <igorzi>isaacs: yes i think it can.. but it's still kind of pain.. i think what people would really want is to have both stable and unstable at the same time
20:27:54  <isaacs>hrm.
20:28:02  <isaacs>we need a nave for windows
20:28:34  <creationix>isaacs, does nvmw (or whatever it's called) not work?
20:28:46  <isaacs>creationix: i didn't know there was such a thing
20:28:56  <isaacs>does it compile stuff, or just fetch binaries?
20:28:58  <igorzi>if we just release the binary without installers - then people can put that binary anywhere they want without interfering with the global stable install
20:29:00  <tjfontaine>it was mentioned in that message
20:29:21  <isaacs>igorzi: yeah, but they don't get npm then
20:29:38  <isaacs>i guess we could say "install the stable, get npm that way, then put the unstable bin wherever"
20:29:52  <isaacs>but really, i want people to be using 0.7 and trying it out as if it's "real"
20:29:55  <creationix>I think this is it https://github.com/hakobera/nvmw
20:29:55  <isaacs>before we go stable with it
20:30:05  <igorzi>isaacs: right
20:31:13  <igorzi>another option is to have a separate install for unstable releases into programfiles/nodejs-unstable (or something like that), and not put that on the path
20:31:40  <isaacs>hmm...
20:31:52  <isaacs>this is all "don't let users use unstable versions" talk, though
20:32:00  <isaacs>that's the opposite of the goal.
20:32:03  <isaacs>:)
20:32:12  <isaacs>i mean, part of the goal is also for 0.7 to stabilize.
20:32:17  <isaacs>so we're in this rough patch.
20:32:27  <isaacs>i think just not having it as the default on the website is probably enouhg.
20:32:41  <tjfontaine>couldn't you ship with "open node 0.7.x" script that sets the path right for different npm?
20:33:30  <isaacs>igorzi: i don't wnat to have people download 0.7.11, then say "oh, this doesn't work" and go back to just using 0.6 forever.
20:33:34  <isaacs>that's how we ended up where we are today.
20:33:41  <isaacs>with 0.4 still in use all over the place.
20:34:02  <igorzi>isaacs: ok, like i said.. maybe this is not an issue at all.. people can always manually uninstall and install whatever they want
20:34:14  <igorzi>do we want to enable auto-downgrades?
20:34:15  <isaacs>yeah
20:34:34  <isaacs>i think if you download the x.y.z msi, it should run, and you should then have node x.y.z installed, period
20:36:13  <igorzi>ok, fair enough.. i think we can make that happen
20:37:58  <piscisaureus_>isaacs: when is 0.6.10 up?
20:38:23  <piscisaureus_>isaacs: today I did some perf work but we have to get the exists bug fixed asap
20:38:53  <isaacs>piscisaureus_: tomorrow
20:38:58  <piscisaureus_>hmm
20:38:59  <piscisaureus_>ok
20:39:24  <isaacs>piscisaureus_: i'm going to drop 0.7.2 right now
20:39:34  <piscisaureus_>isaacs: that's fine
20:39:39  <isaacs>man, something is severely weird on solaris
20:39:44  <isaacs>like every test is timing out
20:39:45  <piscisaureus_>isaacs: don't you get bored, doing 2 releases a week?
20:39:49  <piscisaureus_>ihmm
20:39:59  <igorzi>piscisaureus_: are you going to fix using CreateFile + GetFileInformationByHandle ?
20:40:06  <piscisaureus_>igorzi: if you are okay with it, yeas
20:40:09  <isaacs>piscisaureus_: yes, it's motivating me to figure out how to do this a different way
20:40:18  <isaacs>piscisaureus_: we need better CI asap
20:40:19  <igorzi>piscisaureus_: yep
20:40:24  <piscisaureus_>isaacs: we call that a buildbot :-)
20:40:37  <isaacs>piscisaureus_: yeah, but our buildbot is kind of neglected.
20:40:43  <piscisaureus_>does it even work?
20:40:46  <isaacs>sort of
20:40:56  <isaacs>most of the build slaves are awol
20:41:14  <isaacs>i'm trying to get joyent to throw some resources at it
20:41:19  <piscisaureus_>isaacs: CI systems require kind of continuous attention
20:41:30  <isaacs>also, i think that the stackvm guys might eventually deliver something really interesting there.
20:41:36  <isaacs>i'm trying to convince them to build us something better.
20:41:38  <igorzi>piscisaureus_: we also need to make the change in node so that path.exists uses _makeLong
20:41:54  <piscisaureus_>isaacs: you'd need to find someone who can spend a couple of hours a week maintaining the buildbot + slaves
20:41:57  <isaacs>every CI system sucks terribly. travis-ci is the nicest one i've seen, but it's not nearly enough for us.
20:42:11  <CIA-114>libuv: Igor Zinkovsky v0.6 * r495853e / src/win/error.c : windows: map ERROR_ACCESS_DENIED to UV_EPERM - http://git.io/GL8E6w
20:42:11  <piscisaureus_>travis-ci is linux only, that's the major issue
20:42:17  <piscisaureus_>igorzi: yes I will do that too
20:42:20  <isaacs>piscisaureus_: or we need to have a system in place that can provision and trash build slaves on demand.
20:42:27  <isaacs>piscisaureus_: i do work at a company that does that kind of thing :)
20:42:36  <piscisaureus_>like travis ;_)
20:42:52  <piscisaureus_>for windows we could run the stuff on azure
20:43:03  <isaacs>but there's missing bits in the technology stack. there's an api, and kvm, and smartos, but nothing tying it all together and giving us good reports in a single unified place.
20:43:13  * sh1mmerjoined
20:46:35  <igorzi>piscisaureus_: above when you say "making an API call" in V8, do you mean js -> c++ call?
20:46:54  <piscisaureus_>igorzi: yes.
20:47:09  <piscisaureus_>igorzi: and returning from it
20:48:17  * AvianFluquit (Quit: Leaving)
20:49:16  * travis-cijoined
20:49:17  <travis-ci>[travis-ci] joyent/libuv#74 (v0.6 - 495853e : Igor Zinkovsky): The build is still failing.
20:49:17  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/4cfda74...495853e
20:49:17  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/611504
20:49:17  * travis-cipart
20:51:20  <piscisaureus_>igorzi: you are still on isolates?
20:52:09  <igorzi>piscisaureus_: kind of.. though we should figure out where to go with that
20:52:27  <piscisaureus_>igorzi: yeah
20:52:38  <piscisaureus_>igorzi: well I kind of want all the multiplicity stuff in libuv to be complete
20:53:02  * mnemocjoined
20:53:52  <isaacs>yeah, looks like 0.7.1 is kind of awful on solaris, as well.
20:54:04  <isaacs>many tests just don't run, eventually python just gives up with resource unavailable.
20:54:25  <mnemoc>hi, can the tags of the releases be pushed to github? :)
20:54:33  <igorzi>piscisaureus_: what are the missing multiplicity pieces?
20:54:58  * sh1mmerquit (Remote host closed the connection)
20:55:16  * sh1mmerjoined
20:55:54  <piscisaureus_>igorzi: are uv_loop_destroy() etc done?
20:56:10  <piscisaureus_>igorzi: does uv-unix now support signals in "other" loops?
20:57:25  <igorzi>piscisaureus_: you mean force-closing handles? that's not done (on unix or windows)
20:57:43  <piscisaureus_>igorzi: oh that's not really the most important
20:58:07  <piscisaureus_>igorzi: so uv_loop_destroy does no longer assert(0 && "implement me")
20:59:40  <igorzi>piscisaureus_: no
20:59:52  <igorzi>piscisaureus_: you reviewed it :)
21:00:18  <piscisaureus_>igorzi: oh. sorry, my brain leaks
21:01:28  <igorzi>piscisaureus_: https://github.com/joyent/libuv/blob/52511b9ddca86afbb034b3db85ebcf4185c6e1eb/src/win/core.c
21:02:16  <piscisaureus_>so what parts of multiplicity are still missing? <-- bnoordhuis ?
21:02:58  <bnoordhuis>piscisaureus_: handling SIGCHLD
21:03:35  <bnoordhuis>mnemoc: we don't (yet) do real releases
21:06:50  * logicalparadoxjoined
21:07:50  <piscisaureus_>"�".length // test
21:11:30  <CIA-114>node: isaacs master * rec79acb / src/node_version.h : working on 0.7.3 now - http://git.io/DvhZ8g
21:11:32  <CIA-114>node: isaacs master * ra3efcd2 / (7 files in 6 dirs): (log message trimmed)
21:11:32  <CIA-114>node: 2012.02.01, Version 0.7.2 (unstable)
21:11:32  <CIA-114>node: * Update V8 to 3.8.9
21:11:32  <CIA-114>node: * Support for sharing streams across Isolates (Igor Zinkovsky)
21:11:32  <CIA-114>node: * #2636 - Fix case where http_parsers are freed too early (koichik)
21:11:32  <CIA-114>node: * url: Support for IPv6 addresses in URLs (Łukasz Walukiewicz)
21:11:33  <CIA-114>node: * child_process: Add disconnect() method to child processes (Andreas Madsen)
21:18:21  <isaacs>piscisaureus_: oh, wait, that DOES use more than 2 bytes.
21:18:47  <piscisaureus_>isaacs: yes, but only in the browser
21:19:10  <isaacs>> new Buffer("�")
21:19:10  <isaacs><Buffer ef bf bd>
21:19:31  <isaacs>wild
21:20:15  <piscisaureus_>isaacs: the problem is that v8 converts any non-bmp character to \ufffd
21:20:29  <piscisaureus_>isaacs: what you are seeing the the utf8 representation of that
21:20:57  <isaacs>i see
21:22:09  <piscisaureus_>isaacs: but we could have something that interprets the bytes in a buffer as utf8 and generates surrogate pairs as needed
21:22:19  <isaacs>piscisaureus_: yeah
21:22:28  <isaacs>this is a large sad topic.
21:22:40  <igorzi>piscisaureus_: https://gist.github.com/1719547
21:22:45  <igorzi>piscisaureus_: 397 instructions
21:22:58  <piscisaureus_>isaacs: in the browser the issue is exactly the same. nobody ever complains
21:22:58  <piscisaureus_>(roughly)
21:23:09  <piscisaureus_>isaacs: but browsers are smart enough to do exactly that :-)
21:23:18  <isaacs>right
21:24:18  <piscisaureus_>igorzi: weird. that is twice as much as on my machine
21:24:33  <piscisaureus_>or my machine should secretly run at 4 ghz but that seems unlikely
21:24:41  <piscisaureus_>or it is really super super scalar
21:25:06  * sh1mmerquit (Quit: sh1mmer)
21:25:27  <piscisaureus_>igorzi: btw I have a patch that makes kernel32!InterlockedExchangeAdd no longer show up
21:25:59  <piscisaureus_>igorzi: actually, do you know why that is? Why does winbase.h disable msvc intrinsics on x32?
21:26:37  * travis-cijoined
21:26:38  <travis-ci>[travis-ci] joyent/node#352 (master - ec79acb : isaacs): The build is still failing.
21:26:38  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/05471f5...ec79acb
21:26:38  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/611618
21:26:38  * travis-cipart
21:27:59  <igorzi>piscisaureus_: hmm. don't know... where does it do that?
21:29:09  <igorzi>piscisaureus_: but that just accounts for 10 instructions
21:29:12  <CIA-114>node: Ben Noordhuis master * ra9723df / lib/module.js :
21:29:12  <CIA-114>node: Revert "Process symlinked shared library as .node"
21:29:12  <CIA-114>node: This reverts commit 7e0bf7d57de318f45a097e05644efa49beb65209.
21:29:12  <CIA-114>node: It's possible to make GYP generate an XCode project that produces a .node file,
21:29:12  <CIA-114>node: hence this commit is no longer needed. - http://git.io/MSGZfA
21:32:31  <piscisaureus_>igorzi: yeah it's probably not that bad
21:32:39  <piscisaureus_>igorzi: but it looks like a bug in the windows sdk to me
21:33:07  <igorzi>piscisaureus_: which line in windows.h ?
21:33:22  <igorzi>*winbase.h
21:34:00  <igorzi>piscisaureus_: nm
21:36:30  <piscisaureus_>igorzi: it's difficult to point to stuff that's *not* there :-)
21:36:52  <igorzi>piscisaureus_: yep, got it :)
21:37:55  <piscisaureus_>igorzi: so I have a header (to be included after including windows.h) that fixes that -> https://gist.github.com/1718555
21:44:24  * travis-cijoined
21:44:24  <travis-ci>[travis-ci] joyent/node#353 (master - a9723df : Ben Noordhuis): The build is still failing.
21:44:24  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/ec79acb...a9723df
21:44:24  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/611656
21:44:24  * travis-cipart
21:48:31  <bnoordhuis>https://github.com/bnoordhuis/node/compare/v0.6...base64-decoder-fixes <- review anyone? the first commit fixes a pretty serious vulnerability
21:48:45  * sh1mmerjoined
21:49:01  * sh1mmerquit (Remote host closed the connection)
21:49:10  * sh1mmerjoined
21:51:21  <CIA-114>node: Ben Noordhuis v0.6 * r3deceaf / lib/module.js :
21:51:21  <CIA-114>node: Revert "Process symlinked shared library as .node"
21:51:21  <CIA-114>node: This reverts commit 7e0bf7d57de318f45a097e05644efa49beb65209.
21:51:21  <CIA-114>node: It's possible to make GYP generate an XCode project that produces a .node file,
21:51:21  <CIA-114>node: hence this commit is no longer needed. - http://git.io/cwtXqw
21:58:18  <mjr_>isaacs: I'm both happy and sad that you are grappling with the sadness of the unicode in JavaScript problem.
21:59:06  * travis-cijoined
21:59:07  <travis-ci>[travis-ci] joyent/node#354 (v0.6 - 3deceaf : Ben Noordhuis): The build passed.
21:59:07  <travis-ci>[travis-ci] Change view : https://github.com/joyent/node/compare/7e0bf7d...3deceaf
21:59:07  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/node/builds/611822
21:59:07  * travis-cipart
22:00:52  <isaacs>mjr_: there are many sad problems before us :)
22:04:04  * igorziquit (Ping timeout: 245 seconds)
22:05:01  * dshaw_1joined
22:08:07  * dshaw_quit (Ping timeout: 248 seconds)
22:09:24  <sh1mmer>mjr_: did that module from yesterday address what you need?
22:09:34  <mjr_>I haven't looked at it yet.
22:09:45  <mjr_>Seems like it might, but I haven't fully grappled with the implications.
22:09:52  <sh1mmer>it seems like you mostly need some kind of JSON.parse implemented in buffers
22:09:59  <sh1mmer>I mean it's all non-ideal
22:10:15  <mjr_>But we also need stringify, which is really shitty
22:10:53  <mjr_>So we take in JSON that has surrogate pair unicode in it. We fiddle with it, then route it around by sending it to a bunch of other processes.
22:10:59  <bnoordhuis>we were talking about that with the v8 guys yesterday...
22:11:03  <sh1mmer>right but if you can get parts of your JSON object back as buffers rather than strings
22:11:04  <mjr_>That means we re-stringify this again.
22:11:11  <sh1mmer>you can just serialize it in and out
22:11:20  <sh1mmer>I guess it depends what operands you perform on what
22:12:11  <mjr_>Yeah, I guess if JSON.parse could sometimes swap out some Strings as Buffers
22:12:31  <mjr_>And if JSON.stringify also does the ring thing for objects that have Buffers in them.
22:15:40  * piscisaureus__joined
22:17:40  <isaacs>mjr_: you can definitely do that
22:17:54  <isaacs>mjr_: you can pass an encoder and reviver functions to stringify and parse
22:18:15  * piscisaureus_quit (Ping timeout: 248 seconds)
22:18:41  <isaacs>mjr_: you could even have something that takes the message buffer, and makes it JSON by returning {type:"buffer", bytes:[].slice.call(this)}
22:19:09  <isaacs>mjr_: and then when you're reviving, if you have an object with type==="buffer", return new Buffer(obj.bytes)
22:19:32  <isaacs>mjr_: of course, the json-encoded string is way way huger than a unicode string.
22:19:36  <isaacs>like, around triple
22:19:46  <isaacs>er, json-encoded array
22:20:18  <mjr_>Hmm, yeah, I think that's not a general case solution.
22:20:36  <bnoordhuis>isaacs, piscisaureus__: https://github.com/bnoordhuis/node/compare/v0.6...base64-decoder-fixes <- can one of you review this today or tomorrow?
22:20:47  <bnoordhuis>first commit is a pretty serious bug
22:20:58  <bnoordhuis>or rather, it fixes a pretty serious bug :)
22:21:09  <piscisaureus__>bnoordhuis: you are pretty seriously bugging me
22:21:12  <mjr_>Honestly, there are only a handful of fields in our JSON that will ever have non-BMP characters. It'd be better to just have Buffers for those fields instead of Strings.
22:21:31  <bnoordhuis>piscisaureus__: that's what being a minion means
22:21:46  <bnoordhuis>now go get me coffee
22:23:29  * bnoordhuissigns off for the night
22:24:02  * igorzijoined
22:26:15  * bnoordhuisquit (Read error: Operation timed out)
22:26:41  <piscisaureus__>are there any solaris gurus in the house?
22:26:45  * piscisaureus__changed nick to piscisaureus
22:27:03  <isaacs>piscisaureus: maybe ask in #joyent?
22:33:29  <isaacs>how do you actually build those addon examples with gyp_addon?
22:33:33  <isaacs>in tests/addons?
22:33:44  <isaacs>i'm getting this:
22:33:44  <isaacs>Error: Unable to load shared library /Users/isaacs/dev/js/node-master/test/addons/hello-world/out/Debug/binding.node
22:34:22  <piscisaureus>isaacs: is binding.node actually there?
22:34:33  <piscisaureus>isaacs: and is it the same architecture as your node binary?
22:34:50  <isaacs>the file's there
22:35:02  <isaacs>aha, architecture, yes, that is the culprit
22:41:29  <isaacs>thanks
22:43:31  * skabbesjoined
22:48:02  <TooTallNate>isaacs: probably a result of this? https://github.com/joyent/node/issues/2392
22:48:32  <isaacs>TooTallNate: yeah, but also i had a 0.6.8 node in my path still
22:48:42  <isaacs>and was using the 0.7.2 gyp_addon
22:48:49  <TooTallNate>yup :) I've encountered that before
22:49:09  <TooTallNate>the gyp guys need to get those hard-codings taken care of
22:52:19  * AndreasMadsenquit (Remote host closed the connection)
22:57:04  <piscisaureus>anyway, I'm outta here
22:57:51  <piscisaureus>isaacs: I will do the exists fix tomorrow. Don't bother getting up too early for europe btw - we have meetings in the afternoon
23:07:36  * AvianFlujoined
23:08:02  <isaacs>piscisaureus: kewl, sounds good :)
23:08:05  <isaacs>thanks
23:10:14  <mmalecki>isaacs: seems like upgrading to 0.6.9 indeed fixed these leaks :)
23:10:15  * travis-cijoined
23:10:16  <travis-ci>[travis-ci] pjeweb/node#1 (master - 1cf8138 : pjeweb): The build failed.
23:10:16  <travis-ci>[travis-ci] Change view : https://github.com/pjeweb/node/compare/2217bda...1cf8138
23:10:16  <travis-ci>[travis-ci] Build details : http://travis-ci.org/pjeweb/node/builds/612125
23:10:16  * travis-cipart
23:11:10  <isaacs>mmalecki: that's fantastic.
23:11:38  * mmaleckidances happily
23:16:08  * brsonjoined
23:24:50  * piscisaureusquit (Quit: ~ Trillian Astra - www.trillian.im ~)
23:27:23  * travis-cijoined
23:27:24  <travis-ci>[travis-ci] pjeweb/node#2 (master - 4d6ffcf : pjeweb): The build is still failing.
23:27:24  <travis-ci>[travis-ci] Change view : https://github.com/pjeweb/node/compare/1cf8138...4d6ffcf
23:27:24  <travis-ci>[travis-ci] Build details : http://travis-ci.org/pjeweb/node/builds/612315
23:27:24  * travis-cipart
23:31:59  * stephankquit (Quit: *Poof!*)
23:32:25  * mralephquit (Quit: Leaving.)
23:36:49  * mmalecki_joined
23:37:19  * TooTallNatequit (Read error: Connection reset by peer)
23:37:36  * TooTallNatejoined
23:37:49  * mmaleckiquit (Read error: Operation timed out)
23:38:19  * mmalecki_quit (Client Quit)
23:38:23  * mmaleckijoined
23:56:26  <benvie>the windows msi should make a start menu folder with shortcuts for the repl and docs or something