00:00:01  * ircretaryquit (Remote host closed the connection)
00:00:10  * ircretaryjoined
00:05:00  * Petkaquit (Quit: L�hd�ss�)
00:05:49  <trevnorris>groundwater_: ok, the number of cases it getting to me. we don't fire uncaughtException if the Error was handled by an error callback, right?
00:06:13  <groundwater_>yes, by returning 'true'
00:06:22  <trevnorris>ah, ok.
00:06:59  <groundwater_>which i think is tested in test-asynclistener-error-multiple-handled.js
00:09:47  * jmar777joined
00:11:47  * c4milo_joined
00:12:11  * c4miloquit (Read error: Connection reset by peer)
00:13:14  * jmar777quit (Remote host closed the connection)
00:13:51  * jmar777joined
00:14:43  <trevnorris>ok guys. sorry. this is getting too complex. because in the case that one of the before's throws then i'd have to do something ridiculous like run it through the error callbacks, then also through the uncaughtExceptions, then finish executing the other before callbacks and do the same. then once they're all done executing allow the program to fail.
00:16:21  <trevnorris>so, i'll allow uncaughtException to run _once_ for the _first_ listener/before/after callback that throws, then the application dies.
00:16:31  <trevnorris>groundwater_, othiym23: ^
00:17:49  <othiym23>sounds pretty good
00:18:00  * jmar777quit (Ping timeout: 252 seconds)
00:18:01  <trevnorris>ok
00:22:28  <groundwater_>and i think we should slap a big "don't rely on error-in-error behavior" badge to this
00:22:36  <groundwater_>just in case we realize something needs to change
00:22:52  <trevnorris>how do you mean?
00:23:13  <groundwater_>when we document async-listeners
00:23:42  <groundwater_>we should make it clear that you should not be throwing errors in the middle of your asynclistener
00:23:47  <trevnorris>throwning and error from and error callback is equivalent to Sub-zero ripping out your spinal cord.
00:24:45  * c4milo_quit (Remote host closed the connection)
00:25:21  * c4milojoined
00:25:30  <groundwater_>i just had a flashback to '95
00:25:38  <trevnorris>:)
00:26:27  <othiym23>I was pretty explicit about throwing from error handlers being a bad plan when I was teaching everybody domains
00:26:40  <groundwater_>okay i'm gonna digest all this tonight, but it looks good
00:26:51  <groundwater_>if any of the tests fail, please let me know
00:29:57  * c4miloquit (Ping timeout: 248 seconds)
00:32:51  * bajtosquit (Quit: bajtos)
00:34:45  <trevnorris>will do
00:35:43  * AvianFluquit (Remote host closed the connection)
00:36:13  * AvianFlujoined
00:38:02  * octetcloudquit (Ping timeout: 264 seconds)
00:51:17  * Ralithquit (Ping timeout: 248 seconds)
00:51:48  * wolfeidauquit (Remote host closed the connection)
00:55:54  * mikealquit (Quit: Leaving.)
01:02:12  * dshaw_quit (Quit: Leaving.)
01:04:11  * kazuponjoined
01:04:52  * TooTallNatequit (Quit: Computer has gone to sleep.)
01:05:26  * dominictarr_quit (Quit: dominictarr_)
01:07:03  * wolfeidaujoined
01:14:40  * Ralithjoined
01:16:50  * dshaw_joined
01:19:44  * kazuponquit (Remote host closed the connection)
01:31:45  * dshaw_quit (Quit: Leaving.)
01:36:34  * jmar777joined
01:43:13  * c4milojoined
01:45:37  * abraxasquit (Remote host closed the connection)
01:51:05  * abraxasjoined
01:53:18  * jmar777quit (Remote host closed the connection)
01:56:01  * c4miloquit (Remote host closed the connection)
02:12:20  * inolenjoined
02:15:13  * inolen1joined
02:15:14  * inolenquit (Read error: Connection reset by peer)
02:28:17  * julianduquequit (Remote host closed the connection)
02:34:25  * TooTallNatejoined
02:35:21  * Benviejoined
02:47:13  * TooTallNatequit (Quit: ["Textual IRC Client: www.textualapp.com"])
03:06:28  * AvianFluquit (Remote host closed the connection)
03:06:57  * AvianFlujoined
03:17:15  * Domenic_quit (Ping timeout: 248 seconds)
03:18:53  * Domenic_joined
03:36:12  * AvianFluquit (Remote host closed the connection)
03:36:46  * AvianFlujoined
03:41:53  * dshaw_joined
03:43:10  * paulfryzelquit (Remote host closed the connection)
03:50:59  * AvianFluquit (Remote host closed the connection)
03:51:37  * AvianFlujoined
04:08:27  * kazuponjoined
04:15:36  * piscisaureus_quit (Ping timeout: 245 seconds)
04:24:41  * c4milojoined
04:49:41  * dshaw_quit (Quit: Leaving.)
04:51:14  * c4miloquit (Remote host closed the connection)
04:51:44  * c4milojoined
04:56:27  * c4miloquit (Ping timeout: 248 seconds)
04:56:52  * dshaw_joined
05:13:15  * dominictarr_joined
05:32:23  * paddybyersquit (Quit: paddybyers)
05:34:17  * paddybyersjoined
05:39:55  * abraxasquit (Remote host closed the connection)
05:43:07  * abraxasjoined
05:58:04  <groundwater_>trevnorris: ping
06:04:12  * amartensquit (Quit: Leaving.)
06:16:07  * c4milojoined
06:20:57  * c4miloquit (Ping timeout: 272 seconds)
06:25:51  * bajtosjoined
06:32:21  * bajtosquit (Quit: bajtos)
06:41:06  * mikealjoined
06:41:44  <MI6>nodejs-v0.10-windows: #279 UNSTABLE windows-ia32 (11/603) windows-x64 (10/603) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/279/
06:43:17  * AvianFluquit (Remote host closed the connection)
06:43:46  * AvianFlujoined
06:45:41  * brsonquit (Quit: leaving)
06:47:11  * rendarjoined
06:48:27  * AvianFluquit (Ping timeout: 248 seconds)
06:51:01  <groundwater_>trevnorris: this is a longer-term idea, but what do you think of this for error handling https://gist.github.com/jacobgroundwater/2b4203a18926ff051064
07:01:02  * hzjoined
07:08:04  * FROGGSjoined
07:50:41  * piscisaureus_joined
07:52:32  * piscisaureus_quit (Read error: Connection reset by peer)
08:04:18  * c4milojoined
08:09:08  * c4miloquit (Ping timeout: 265 seconds)
08:23:34  * kazuponquit (Remote host closed the connection)
08:30:32  <indutny>morning
08:37:44  * bnoordhuisjoined
08:41:45  * abraxasquit (Remote host closed the connection)
08:42:48  * abraxasjoined
09:06:06  * kazuponjoined
09:07:26  * kazuponquit (Read error: Connection reset by peer)
09:07:45  * kazuponjoined
09:19:11  * kazuponquit (Remote host closed the connection)
09:29:32  * kazuponjoined
09:30:03  <indutny>bnoordhuis: hi
09:30:05  <indutny>bnoordhuis: how are you?
09:35:00  <bnoordhuis>indutny: hey fedor. i'm fine. you?
09:35:04  <indutny>good too
09:35:10  <bnoordhuis>good
09:35:25  <indutny>I think I've an idea on how to fix stale events problem
09:35:35  <indutny>bnoordhuis: do you have a minute to discuss it?
09:35:38  <bnoordhuis>sure
09:35:50  <indutny>bnoordhuis: I'm going to add clean-up code to uv__io_stop
09:36:02  <indutny>bnoordhuis: it'll remove all stale events
09:36:28  <indutny>but that will require storing some info in loop
09:36:39  <bnoordhuis>what kind of cleanup code?
09:36:39  <indutny>which complicates with ABI compatibility
09:36:54  <indutny>bnoordhuis: well, code will walk through all epoll/kqueue/port events
09:36:59  <indutny>and remove ones with the same fd
09:37:12  <indutny>is it incorrect?
09:37:31  <bnoordhuis>not sure i follow. how is uv__io_stop() going to walk the list of events?
09:37:40  <indutny>well, it'll be stored in loop
09:37:41  <indutny>the list
09:37:52  <bnoordhuis>right
09:38:01  <indutny>perhaps not _stop()
09:38:06  <indutny>but rather uv__io_close
09:38:13  <bnoordhuis>that's a better place for it
09:38:26  <indutny>anyway, that's the only reasonable way to fight it
09:38:34  <indutny>there're no information about it in other places
09:39:04  <indutny>regarding ABI compatibility
09:39:29  <bnoordhuis>yes?
09:39:34  <indutny>it could be solved with hacks :P
09:39:37  * abraxasquit (Remote host closed the connection)
09:40:01  <indutny>like storing pointer to events in loop->watchers[loop->nfds]
09:40:08  <indutny>and growing watchers to loop->nfds + 1 length
09:40:13  * abraxasjoined
09:40:24  <bnoordhuis>hrm, that's an option
09:40:31  <indutny>yep
09:40:35  <indutny>do you like the plan?
09:40:55  <bnoordhuis>for v0.10? i guess it's workable. just remove that hack in master, will you? :)
09:41:13  <indutny>haha
09:41:18  <indutny>ok, after landing to v0.10
09:41:39  <indutny>starting doing it now then
09:44:43  <indutny>bnoordhuis: mind reviewing yesterday's patch?
09:45:01  <bnoordhuis>i don't but not now
09:49:24  <indutny>ok
09:49:26  <indutny>thanks
09:49:34  <indutny>bnoordhuis: btw, another solution to stale event problem
09:49:40  <indutny>bnoordhuis: would be to store events in watchers
09:49:51  <indutny>bnoordhuis: and execute them after processing all received events
09:50:14  <indutny>bnoordhuis: though, it could lead to starvation
09:50:16  <indutny>ah, it can't
09:50:28  <indutny>yeah, it might work
09:50:54  <indutny>probably has higher performance cost, though
09:51:08  <indutny>and memory
09:52:36  * c4milojoined
09:53:26  <indutny>bnoordhuis: thoughts?
09:53:44  * Kakerajoined
09:56:13  <bnoordhuis>indutny: you mean don't dispatch directly from uv__backend_poll()?
09:56:26  <indutny>sort of
09:56:31  <indutny>actually, dispatch in it
09:56:38  <indutny>but in separate loop
09:56:41  <bnoordhuis>i have a patch to that effect somewhere
09:57:02  <bnoordhuis>where uv__backend_poll() just polls for events and leaves it to uv_run() to actually dispatch them
09:57:16  * c4miloquit (Ping timeout: 245 seconds)
09:57:24  <bnoordhuis>the idea behind it is to coalesce events on kqueue-based platforms
09:57:37  <indutny>oh, that's nice
09:57:42  <indutny>bnoordhuis: why kqueue?
09:57:47  <indutny>ah
09:57:51  <indutny>its reporting separate read/write events?
09:57:53  <indutny>haha
09:57:54  <bnoordhuis>yes
09:58:01  <indutny>yes, idea is good
09:58:04  <indutny>and better than my approach
09:58:17  <bnoordhuis>let me look up that commit
09:59:17  <bnoordhuis>https://github.com/bnoordhuis/libuv/commit/bfa1b64
09:59:35  <bnoordhuis>"bnoordhuis authored 3 months ago" - i should learn to finish things
10:00:10  * kazuponquit (Remote host closed the connection)
10:00:39  * dshaw_quit (Quit: Leaving.)
10:03:08  <indutny>haha
10:03:17  <indutny>not ABI compatible
10:03:54  <bnoordhuis>no, it's purely for master
10:04:35  <indutny>bnoordhuis: ok
10:04:45  <indutny>bnoordhuis: does it work?
10:05:01  <indutny>seems to be generally looking good, but I may be unaware of some paths
10:05:45  <bnoordhuis>indutny: i only proof my code correct, i never test it
10:05:48  <bnoordhuis>(of course it works)
10:06:27  <indutny>why not landed then?
10:06:39  <bnoordhuis>that commit is an upbeat to usable edge triggered i/o support
10:06:45  <bnoordhuis>which i haven't finished yet
10:06:46  <indutny>aah
10:06:54  <indutny>well, better land it in parts
10:06:56  <indutny>;)
10:07:05  <bnoordhuis>yeah, i guess i could land it now
10:07:15  <indutny>I think we could try to use higher bits of events
10:07:23  <indutny>or break it into two uint16
10:07:32  <indutny>to keep it ABI compatible
10:07:43  <indutny>bnoordhuis: what do you think?
10:08:05  <bnoordhuis>that's making assumptions about the values of POLLIN/POLLOUT/etc.
10:08:19  <indutny>well, we're in charge of them
10:08:22  <indutny>ain't we?
10:08:24  <indutny>UV__POLLIN
10:08:29  <indutny>UV__POLLOUT
10:08:43  <bnoordhuis>they're mapped to the platform values now
10:08:51  <indutny>we can change it
10:09:06  <indutny>with no performance cost
10:09:16  <indutny>well, I agree that they way you did it - it is ok for master
10:09:26  <indutny>not even ok
10:09:27  <indutny>great
10:09:31  <bnoordhuis>thanks :)
10:09:33  <indutny>:)
10:09:36  <indutny>but for v0.10
10:09:41  <indutny>it won't work out
10:09:48  <indutny>as uv__io_t is part of many handles
10:09:57  <indutny>and will definitely break some code
10:10:10  <bnoordhuis>indeed
10:10:51  <bnoordhuis>i guess your trick of storing the list in loop->watchers[loop->nwatchers] is our best option
10:11:02  <bnoordhuis>linear scans make me sad though :-/
10:11:20  * dshaw_joined
10:11:24  <indutny>bnoordhuis: well, yeah
10:11:27  <indutny>or
10:11:32  <indutny>ah, yeah
10:11:35  <bnoordhuis>i was thinking about adding a generation counter but that won't work without abi changes either
10:11:43  <indutny>yeah
10:11:49  <indutny>probably we can try to merge events?
10:12:00  <indutny>in the array
10:12:12  <bnoordhuis>you mean the kevent list or?
10:12:13  <indutny>without taking up more storage
10:12:15  <indutny>yes
10:12:19  <indutny>epoll/kevent/port list
10:12:36  <bnoordhuis>epoll reports events just once for a fd
10:12:45  <indutny>hrm
10:12:50  <bnoordhuis>at least, i'm reasonably sure it does
10:13:06  <indutny>aaaaaaaah
10:13:08  <indutny>yeah, got i
10:13:15  <indutny>that won't help :)
10:13:20  <indutny>merging events
10:13:29  <indutny>sorry
10:13:37  <indutny>ok, I'll work out that bugfix
10:13:41  <bnoordhuis>cool :)
10:13:43  <indutny>with +1 watcher
10:15:55  * dshaw_quit (Ping timeout: 272 seconds)
10:17:53  <bnoordhuis>FATAL ERROR: Heap::ReserveSpace Allocation failed - process out of memory <- trying to create 10k vm contexts...
10:18:22  <bnoordhuis>takes almost a minute for it to hit that
10:18:46  <bnoordhuis>with v0.10, the test not only passes but it passes in under five seconds
10:19:15  <bnoordhuis>i don't know about vm2... it's not all roses
10:19:17  <indutny>haha
10:19:27  <indutny>wait
10:19:32  <indutny>I believe we fixed it?
10:19:43  <bnoordhuis>it's happening with today's master
10:19:44  <indutny>creating 10k contexts....
10:19:47  <indutny>god, not again
10:19:53  <bnoordhuis>i'll open an issue :)
10:20:14  <indutny>that'll be Inbox 13 for me
10:20:15  <indutny>:P
10:20:33  <indutny>in fact I don't have much interest in it
10:20:36  <indutny>but I'll fix it anyway
10:20:47  <indutny>just because I understand this code and see that other people want it to be there
10:25:28  * hzquit
10:26:54  <bnoordhuis>i have a fix that makes v8 more likely to clean up the full context
10:27:04  <bnoordhuis>but it doesn't help with this particular test :-/
10:28:05  <bnoordhuis>https://gist.github.com/bnoordhuis/8530cceca335b7a0469c <- that
10:31:44  * dshaw_joined
10:35:02  * mraleph1joined
10:35:03  * mralephquit (Read error: Connection reset by peer)
10:36:11  * bnoordhuisquit (Ping timeout: 248 seconds)
10:43:06  <MI6>nodejs-v0.10: #1553 FAILURE http://jenkins.nodejs.org/job/nodejs-v0.10/1553/
10:56:37  * dshaw_quit (Ping timeout: 248 seconds)
11:07:38  * bnoordhuisjoined
11:40:47  * c4milojoined
11:45:50  * c4miloquit (Ping timeout: 264 seconds)
11:51:39  * dshaw_joined
11:55:47  * abraxasquit (Remote host closed the connection)
11:56:32  * dshaw_quit (Ping timeout: 256 seconds)
11:57:04  * abraxasjoined
12:02:04  * bnoordhuisquit (Ping timeout: 268 seconds)
12:37:29  * Kakeraquit (Read error: Connection reset by peer)
12:38:08  * Kakerajoined
12:40:29  * bnoordhuisjoined
12:49:01  * dshaw_joined
12:49:40  * bnoordhuisquit (Ping timeout: 246 seconds)
12:53:10  * dshaw_quit (Ping timeout: 246 seconds)
12:54:08  * abraxasquit (Remote host closed the connection)
13:23:39  * dominictarr_quit (Quit: dominictarr_)
13:24:14  * dominictarrjoined
13:28:59  * c4milojoined
13:33:29  * c4miloquit (Ping timeout: 240 seconds)
13:56:36  * pachetjoined
13:56:37  * pachetquit (Changing host)
13:56:37  * pachetjoined
14:01:44  * c4milojoined
14:03:41  * bnoordhuisjoined
14:18:41  <MI6>joyent/node: Zarko Stankovic v0.10 * eb291de : doc: add nodejs.rs to the community page - http://git.io/0aKbDw
14:23:52  <MI6>nodejs-v0.10: #1554 FAILURE http://jenkins.nodejs.org/job/nodejs-v0.10/1554/
14:29:21  <bnoordhuis>make: *** No rule to make target `test/gc/node_modules/weak/build/'. Stop. <- wut?
14:33:27  <MI6>nodejs-v0.10-windows: #280 UNSTABLE windows-ia32 (12/603) windows-x64 (10/603) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/280/
14:33:39  <MI6>joyent/node: Ben Noordhuis v0.10 * 808a968 : build: fix test-gc weakref build rule - http://git.io/p9VzYg
14:38:14  <bnoordhuis>ircretary: tell piscisaureus https://github.com/joyent/libuv/pull/969 <- you should PTAL (Probably Take A Look)
14:38:14  <ircretary>bnoordhuis: I'll be sure to tell piscisaureus
14:38:47  <MI6>nodejs-v0.10: #1555 FAILURE http://jenkins.nodejs.org/job/nodejs-v0.10/1555/
14:41:12  <bnoordhuis>hrm, i guess it's up to tjfontaine to fix that
14:41:41  <bnoordhuis>i reckon it's the jenkins script that's executing that makefile rule
14:48:35  <MI6>nodejs-v0.10-windows: #281 UNSTABLE windows-ia32 (11/603) windows-x64 (11/603) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/281/
14:50:05  * c4miloquit (Remote host closed the connection)
14:50:40  * c4milojoined
14:54:46  * c4miloquit (Ping timeout: 245 seconds)
14:54:48  * abraxasjoined
14:59:39  * abraxasquit (Ping timeout: 252 seconds)
15:01:26  * paulfryzeljoined
15:11:28  * superjoejoined
15:19:57  <MI6>nodejs-master: #639 UNSTABLE osx-x64 (1/649) smartos-ia32 (6/649) smartos-x64 (8/649) osx-ia32 (1/649) http://jenkins.nodejs.org/job/nodejs-master/639/
15:29:39  * AvianFlujoined
15:30:38  * FROGGSquit (Quit: Verlassend)
15:32:46  <bnoordhuis>indutny: is #968 still the PR you want me to review for that stale event thing?
15:44:02  <MI6>joyent/libuv: maksqwe master * d964b53 : windows: incorrect check for SOCKET_ERROR (+2 more commits) - http://git.io/nKX2Hg
15:45:00  <bnoordhuis>ai
15:46:36  <MI6>joyent/libuv: Maks Naumov master * d170c91 : windows: incorrect check for SOCKET_ERROR (+2 more commits) - http://git.io/ZvU34Q
15:47:48  <MI6>libuv-master: #301 UNSTABLE windows (3/196) smartos (2/195) http://jenkins.nodejs.org/job/libuv-master/301/
15:49:38  <MI6>libuv-master-gyp: #242 FAILURE windows-x64 (3/196) windows-ia32 (3/196) http://jenkins.nodejs.org/job/libuv-master-gyp/242/
15:50:19  <MI6>libuv-node-integration: #286 FAILURE http://jenkins.nodejs.org/job/libuv-node-integration/286/
15:51:24  <MI6>libuv-master: #302 UNSTABLE osx (1/196) windows (3/196) smartos (2/195) http://jenkins.nodejs.org/job/libuv-master/302/
15:54:50  <MI6>libuv-master-gyp: #243 FAILURE windows-x64 (3/196) linux-ia32 (1/195) windows-ia32 (3/196) http://jenkins.nodejs.org/job/libuv-master-gyp/243/
15:55:26  * bnoordhuisquit (Ping timeout: 264 seconds)
15:55:42  * inolen1quit (Quit: Leaving.)
15:58:38  <MI6>libuv-node-integration: #287 FAILURE http://jenkins.nodejs.org/job/libuv-node-integration/287/
16:11:20  * jmar777joined
16:13:28  * dshaw_joined
16:15:28  * bajtosjoined
16:17:26  * jmar777quit (Remote host closed the connection)
16:18:02  * jmar777joined
16:18:59  * mikealquit (Quit: Leaving.)
16:22:37  * jmar777quit (Ping timeout: 272 seconds)
16:25:02  * Ralithquit (Read error: Connection reset by peer)
16:28:45  * FROGGSjoined
16:30:15  * sblomjoined
16:30:25  <sblom>tjfontaine: I just saw your twitter batlight.
16:30:31  <sblom>(I'm slow.)
16:30:34  <sblom>(Sorry.)
16:30:36  <sblom>Happy to help.
16:30:39  <sblom>And free all day.
16:32:03  * sblomstarts looking through the logs to get caught up in the meanwhile.
16:32:39  * defunctzombie_zzchanged nick to defunctzombie
16:33:03  <tjfontaine>sblom: try and build master please and thank you :)
16:33:19  <sblom>roger
16:33:49  <tjfontaine>sblom: there's something we're doing with persistents in object wrap and env-inl that's making msvc very cranky
16:35:27  <isaacs>anyone interested in merging v0.10 into master?
16:35:53  <MI6>joyent/node: isaacs v0.10 * f6f176e : [email protected] - http://git.io/hDefLw
16:36:06  <tjfontaine>isaacs: I am already doing it
16:36:18  <isaacs>tjfontaine: you rock, sir
16:36:24  <tjfontaine>I started last night, have one failure that I introduced in the merge that I need to track down
16:36:39  <isaacs>tjfontaine: make sure to get the new npms i just landed (sorry, probably bad timing)
16:36:50  <tjfontaine>it's fine, I'm probably going to re-start the merge anyway
16:37:12  <tjfontaine>also -- merges are easier if our changes come with test cases :/
16:41:08  <MI6>nodejs-v0.10: #1556 FAILURE http://jenkins.nodejs.org/job/nodejs-v0.10/1556/
16:42:45  <tjfontaine>argh
16:45:15  * bnoordhuisjoined
16:45:34  * amartensjoined
16:46:00  <tjfontaine>ugh. Ben Noordhuis v0.10 * 808a968 : build: fix test-gc weakref build rule
16:46:15  <tjfontaine>well my detection for that in the build scripts was relying ont he v8 upgrade
16:46:25  * mikealjoined
16:46:41  <tjfontaine>so I guess I will need to figure out a different way to differentiate when a build may have the old version vs the new
16:46:57  * bajtosquit (Quit: bajtos)
16:51:05  <MI6>nodejs-v0.10-windows: #282 UNSTABLE windows-ia32 (10/603) windows-x64 (11/603) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/282/
16:56:10  * abraxasjoined
16:56:57  * bnoordhuisquit (Ping timeout: 265 seconds)
16:58:01  * dshaw_quit (Quit: Leaving.)
17:00:37  * abraxasquit (Ping timeout: 246 seconds)
17:00:44  * brsonjoined
17:02:42  * dshaw_joined
17:04:58  * dshaw_quit (Client Quit)
17:07:58  * TooTallNatejoined
17:10:04  * bajtosjoined
17:10:38  <MI6>nodejs-v0.10: #1557 UNSTABLE smartos-x64 (6/603) smartos-ia32 (4/603) osx-ia32 (1/603) http://jenkins.nodejs.org/job/nodejs-v0.10/1557/
17:15:12  * julianduquejoined
17:22:10  <trevnorris>morning
17:30:15  * mikealquit (Quit: Leaving.)
17:36:34  * mcavagequit (Remote host closed the connection)
17:37:01  * mcavagejoined
17:39:55  <trevnorris>groundwater_: ping
17:41:47  * mcavagequit (Ping timeout: 260 seconds)
17:43:10  * mcavagejoined
17:43:25  * dshaw_joined
17:50:23  <trevnorris>i'm really getting tired of figuring out this stupid error handling in my error handlers.
17:50:39  <trevnorris>if your code is so bad that your error handlers are throwing then there's something seriously fucked up with your code
17:52:41  * mcavagequit (Remote host closed the connection)
17:53:13  <MI6>libuv-master: #303 UNSTABLE windows (4/196) smartos (2/195) http://jenkins.nodejs.org/job/libuv-master/303/
17:53:45  <trevnorris>isaacs: ping
17:54:05  <tjfontaine>heh
17:54:07  <tjfontaine>trevnorris: <3
17:59:17  * bajtosquit (Quit: bajtos)
18:00:35  <MI6>libuv-node-integration: #288 FAILURE http://jenkins.nodejs.org/job/libuv-node-integration/288/
18:03:06  * sblomquit (Ping timeout: 245 seconds)
18:06:09  * AvianFluquit (Remote host closed the connection)
18:07:44  * AvianFlujoined
18:09:06  * sblomjoined
18:09:33  * c4milojoined
18:13:15  * jmar777joined
18:15:08  <sblom>tjfontaine: I found a wire to clip that makes it compile. Unfortunately, it's in v8.h.
18:15:18  <sblom>Doing some blame-spelunking to figure out what changed to break this.
18:27:02  <tjfontaine>ok
18:34:18  * julianduquequit (Ping timeout: 240 seconds)
18:37:19  * julianduquejoined
18:39:15  <sblom>Starting to look like the notion of non-copyable `Persistent`s has been introduced in v8 recently, and that's the default behavior. I think we must be copying Persistents.
18:39:20  <sblom>I don't know why only VC++ is refusing to compile this. I have a set of changes to some of our own code that fixes the compile failures now, at least. Now I need to understand what's going on.
18:40:17  <sblom>(My fix depends on updating v8 to at least 16891, also. That's when they introduced `CopyablePersistentTrait`s, which is key to my fix.)
18:40:19  <tjfontaine>sblom: thanks so much for looking into this
18:40:28  <sblom>No problem. We're not out of the woods yet. :)
18:40:35  <tjfontaine>:)
18:40:47  <sblom>I'll grab my C++-ringer neighbor to make sure I've got this template crap deciphered correctly. :)
18:40:57  <tjfontaine>heh
18:41:28  <Domenic_>wat messages.js
18:41:33  <tjfontaine>inorite?
18:42:51  <tjfontaine>honestly though ... who's making 10k contexts in a single process ... :)
18:46:30  <trevnorris>who wants the ability to catch errors being thrown from their error handlers?
18:46:46  <trevnorris>there's a lot of crazy crap people want.
18:46:52  <MI6>nodejs-master-windows: #432 FAILURE http://jenkins.nodejs.org/job/nodejs-master-windows/432/
18:52:11  * mikealjoined
18:52:42  <sblom>Who knows much about the lifecycle of ownership of `v8::Persistent`s?
18:53:20  <sblom>It looks like my fix hasn't broken the hell out of unit tests or anything, but for all I know I'm now leaking Persistents all over the place.
18:54:03  <trevnorris>sblom: have a diff?
18:54:09  <sblom>Posting that now.
19:00:06  <sblom>trevnorris: https://github.com/MSOpenTech/node/commit/af12cebcbdc39878e05510128b3fc6c923588de2
19:00:39  <sblom>I _think_ this change exactly preserves our previous behavior.
19:01:10  <sblom>My read of v8's changes is that they're trying to make it hard to accidentally copy persistents, but it looks to me like we're signed up to deal with the consequences.
19:02:17  <sblom>And just to help you decipher what this is doing, v8::CopyablePersistentTraits<> doesn't actually have any runtime behavior, just compile time template fu.
19:02:47  <trevnorris>sblom: i'm not all that up w/ c++, but don't you need a space between the last >>; in node_object_wrap, at the top?
19:02:50  <sblom>v8::NonCopyablePersistentTraits<> is the default second parameter to v8::Persistent<>, and disables copying at compile time.
19:03:10  <sblom>trevnorris: good catch--you do in some compilers.
19:03:17  <sblom>Not in C++11, tho.
19:03:20  <trevnorris>i.e. clang :)
19:03:25  <sblom>Fair enough.
19:03:57  <trevnorris>sblom: so, i'm jumping into the middle of this. what's the issue?
19:04:38  <sblom>Main issue was that MSVC won't compile node#master after we updated deps/v8.
19:04:41  <sblom>Now it will.
19:04:53  <sblom>And I _think_ I haven't changed node's behavior at all.
19:05:01  <trevnorris>just curious, can MSVC compile v8 itself?
19:05:08  <sblom>Yes.
19:05:23  <sblom>All of the compile failures are happening in places where we include node_object_wrap.h
19:05:29  <trevnorris>well, imho if we need to float a patch to deps/v8 then our code is wrong.
19:05:31  <tjfontaine>or env-inl.h
19:05:32  <tjfontaine>?
19:05:40  <sblom>We don't have to patch v8.
19:05:42  <trevnorris>um... we shouldn't be including object_wrap anywhere
19:05:58  <sblom>I copied/pasted that struct from latest v8 trunk.
19:06:03  <sblom>So if we update v8, we're good.
19:06:13  <tjfontaine>we need to message that to v8, I think
19:06:28  <trevnorris>yeah. latest trunk is 3.22, this was a 3.21 upgrade
19:06:57  <sblom>Or to be more specific, if we update v8, we have struct CopyablePersistentTraits, which we need to re-enable copying of Persistents.
19:07:37  <tjfontaine>right ok so we'll need to figure out what the fuck we're doing :)
19:08:13  <trevnorris>sblom: so. is this not happening w/ weak-object-inl.h?
19:08:14  <sblom>trevnorris: node_object_wrap.h is included in node.h itself.
19:08:58  <trevnorris>oy. tjfontaine do we do that so users get access to ObjectWrap just by including node.h, or should they need to include node_object_wrap?
19:09:52  <trevnorris>sblom: because ObjectWrap is no longer being used by core. so if the later is the case then it can just be removed from node.h
19:10:26  <sblom>also removed from node_contextify, node_crypto, and node_stat_watcher?
19:10:47  <trevnorris>yeah. ObjectWrap is now no longer used by core
19:10:58  <sblom>okay.
19:11:02  <trevnorris>we switched it over to WeakObject class a little while ago.
19:11:49  <sblom>trevnorris: now I understand your previous question. This does _not_ seem to happen in weak-object-inl.h.
19:12:18  <trevnorris>ah, ok. then there's something strange, because that code you changed is the exact same in weak-object-inl.h
19:12:19  * dshaw_quit (Quit: Leaving.)
19:12:37  <trevnorris>so first we should remove the node_object_wrap.h includes from anywhere in core
19:12:41  <sblom>I'll double-check that it's participating in this build.
19:12:45  <sblom>Yeah--I'll try that change now.
19:15:24  <sblom>trevnorris: The offending code doesn't exist in weak-object-inl.h
19:15:35  <sblom>It's mostly dealing with Locals, not Persistents.
19:16:01  <sblom>There's only one mention of Persistent, but it's the one that I didn't have to patch in ObjectWrap.
19:16:31  <trevnorris>oh wait. man. been spending too much time in my 6011 patch. it's all the same to me now.
19:16:42  <trevnorris>well, that persistent() syntax is pretty much all over core
19:16:48  <sblom>Heh--no sweat.
19:17:03  <sblom>So very high chance that simply deleting node_object_wrap.h refs will fix this. Build is nearly done to prove that.
19:23:16  * jmar777quit (Remote host closed the connection)
19:23:52  * jmar777joined
19:27:08  * dap_joined
19:27:29  <trevnorris>sblom: so for node_object_wrap, there're only two differences between that and other uses of the same code. first is NODE_EXTERN, the second is that node_object_wrap isn't in node.gyp
19:28:04  * jmar777_joined
19:28:10  * jmar777quit (Ping timeout: 256 seconds)
19:28:32  * dshaw_joined
19:29:41  <trevnorris>i'm sure ben would have some sage wisdom about the linker and the new way persistent's work, but he's not here. :(
19:31:30  * jmar777_quit (Remote host closed the connection)
19:31:34  <sblom>Deleting node_object_wrap.h mentions _almost_ fixes things. env.h still declares Persistents.
19:31:43  <sblom>And they need to be CopyablePersistents.
19:32:06  <trevnorris>...
19:32:34  <trevnorris>what's the difference w/ CopyablePersistents?
19:33:03  <trevnorris>groundwater_, othiym23: here are your revised tests, I just squashed my changed onto your tests. hope that's ok :) http://git.io/5ovRRg
19:34:25  <sblom>trevnorris: I haven't hunted down our exact usage yet, but I think we're invoking the copy constructor in Persistent. Probably when we're assigning to the places that we store them? I think the copy constructor increments a reference count. And presumably we're being responsible and releasing them later.
19:34:44  <sblom>It looks like v8 made a change to Persistent to make them non-copyable by default.
19:35:00  <sblom>Probably to keep people like me who aren't v8 wizards from doing something stupid. :)
19:35:27  <trevnorris>sblom: ok. so you're getting a compiler error. what's the error exactly?
19:35:39  <trevnorris>sorry, I probably should already be caught up on this.
19:35:40  <sblom>It's possible to override declarations of v8::Persistent<> to be copyable (old behavior)
19:35:47  <sblom>Nah--it's fine.
19:36:02  <trevnorris>that's the compiler error?
19:36:14  <sblom>No.
19:36:48  * dap_quit (Quit: Leaving.)
19:37:20  <sblom>The compiler error is the nonsense caused by line 477 in v8.h.
19:37:37  <sblom>(With a TODO of "come up with a good compile error here."
19:37:47  <trevnorris>hahaha, thanks v8
19:37:49  <sblom>I'll paste the real error into a gist, but it's not really important here.
19:38:57  <sblom>https://gist.github.com/sblom/18223965e31eda6ff89b
19:39:54  <sblom>The intention of the code (and the forced nonsense error) is simply to prevent code from compiling that's using Copy().
19:40:56  <sblom>What's failing to compile is "NonCopyablePersistentTraits::Copy() { Uncompilable<Object>(); }", whose meaning is fairly clear. :)
19:41:47  <trevnorris>sblom: wtf. why does that error message still have node_object_wrap in the stack?
19:42:33  <sblom>yeah--very good question.
19:42:41  <sblom>I've been trying to figure that out for 30 minutes at this point.
19:42:47  <sblom>I'm going to scorch and rebuild.
19:42:55  <sblom>I still smell a pch cache or some damn thing.
19:43:24  <sblom>But pretty sure I fixed it by adding CopyablePersistentTraits to line 295 in env.h.
19:43:57  <sblom>Ooh.
19:43:59  <sblom>I figured it out.
19:44:00  <sblom>Not a cache.
19:44:11  <sblom>You said that node_object_wrap.h was in gyp?
19:44:23  <trevnorris>it's not in node.gyp
19:44:27  <sblom>Oh.
19:44:29  <sblom>Dang.
19:44:39  <sblom>There are a couple of template types that are instantiated in it.
19:45:20  <sblom>trevnorris: Alright--I'm back to my original theory of bogus cache. Let's see how this clean build goes.
19:46:13  <sblom>(I don't think I've ever seen pch cache problems before, though.)
19:50:17  <trevnorris>sblom: so the error has node_file.cc, but doesn't give a line number. or at least I don't see one.
19:51:25  <trevnorris>sblom: and i'll assume this is being generated by MSVC? c:\src\node\node\node.vcxproj
19:51:59  <sblom>trevnorris: yeah--that's a generated file (by GYP_GENERATOR=msvs).
19:52:15  <sblom>trevnorris: I also don't see a line number, but it's line 28.
19:52:23  <sblom>(Where env.h is being included.)
19:52:47  <sblom>That's what gets us onto that set of include hops.
19:54:18  <sblom>I need to go grab lunch. clean build is running.
19:54:26  <trevnorris>cool.
19:54:37  <sblom>thanks for your help
19:54:53  <trevnorris>sblom: np.
19:54:55  <trevnorris>i have a possible idea
19:55:15  <trevnorris>but i'll hash it out while you're away
19:57:39  * st_lukejoined
20:03:38  <trevnorris>sblom: so, the only way env.h could get included into node_object_wrap.h is via node.h. so if it's been removed there then it should be impossible for that error to happen.
20:09:00  <sblom>trevnorris: Found the problem by deleting node_object_wrap.h. There was one more place that it was being included. node_stat_watcher.h.
20:09:12  <sblom>Removing the #include there was causing node_stat_watcher.cc to break.
20:09:14  * mikealquit (Quit: Leaving.)
20:09:29  <sblom>But it turns out that was because node_stat_watcher.cc was getting node.h by way of node_object_wrap.h
20:09:34  <sblom>So switching it out has fixed things.
20:09:47  <sblom>I'll post my new changes as a PR.
20:09:53  <sblom>(Just deleting headers.)
20:09:54  <trevnorris>awesome.
20:12:51  <sblom>trevnorris: So do we need to keep node_object_wrap.h around at all?
20:13:04  <sblom>For module authors?
20:13:07  <trevnorris>yeah
20:13:08  <trevnorris>for that
20:13:23  <sblom>So we still need to make it compile.
20:13:26  <sblom>On Windows.
20:14:06  <trevnorris>eh, users should stop using ObjectWrap anyways. this will be a good incentive. :P
20:14:26  * st_lukequit (Remote host closed the connection)
20:14:42  <sblom>Well, thing is I know how to make it compile. If its template fu were working like it's designed, it would be breaking everywhere else, too.
20:14:55  * st_lukejoined
20:15:12  <trevnorris>i guess we can test build a module?
20:15:54  <trevnorris>problem is I don't know of any modules that work w/ the latest v8 AND use ObjectWrap.
20:15:54  <sblom>Yeah--I suppose we could.
20:15:58  <trevnorris>TooTallNate: do you?
20:15:59  <sblom>Okay.
20:16:32  <TooTallNate>trevnorris: i do not
20:18:04  * c4miloquit (Remote host closed the connection)
20:19:28  * st_lukequit (Ping timeout: 265 seconds)
20:23:16  <trevnorris>sblom: hm. ok guess I could write one up real quick. one minute.
20:24:56  * c4milojoined
20:29:19  <trevnorris>ircretary: tell bnoordhuis will we need to start parsing http headers in utf8 now? http://www.computerworld.com.au/article/529955/first_new_gtlds_added_root/
20:29:20  <ircretary>trevnorris: I'll be sure to tell bnoordhuis
20:35:17  <sblom>trevnorris: Won't they use punycode like unicode domains currently do?
20:36:07  <trevnorris>oh yeah. you're probably right.
20:37:14  * st_lukejoined
20:37:15  <trevnorris>tjfontaine: ok, this is dumb. so first thing I did after reinstalling my os was to do an npm install -g node-gyp, and it made ~/tmp root:root
20:37:16  <trevnorris>wtf
20:39:43  <sblom>trevnorris: Rubber stamp? https://github.com/joyent/node/pull/6411
20:41:03  <trevnorris>sblom: ah suck. docs show you only need to include node.h to get ObjectWrap: http://nodejs.org/api/addons.html
20:41:15  <sblom>d'oh
20:41:24  <trevnorris>what happens if you just include it in node.h?
20:41:46  <sblom>Pretty sure we go back to failing because it's included everywhere.
20:41:47  <trevnorris>I guess we could change that for v0.12
20:41:50  <sblom>I'll double-check that, but pretty sure.
20:41:59  <trevnorris>not like we haven't broken enough anyways.
20:42:04  <trevnorris>tjfontaine, isaacs: feedback?
20:43:55  <sblom>confirmed that we resume failing
20:44:02  <trevnorris>well suck it.
20:45:01  <trevnorris>same error in env.h?
20:48:48  * dshaw_quit (Quit: Leaving.)
20:48:58  <tjfontaine>sorry checking in from futurestack, looking into the pullreq now
20:49:03  <sblom>trevnorris: same error, different include stack.
20:49:32  <trevnorris>tjfontaine: well. won't work because we have documented that you only need node.h to get ObjectWrap. unless we change that for v0.12?
20:50:06  <sblom>trevnorris: I'm pretty confident that the v8::CopyablePersistentTraits fix was correct.
20:50:13  <sblom>I just haven't proven it.
20:50:29  <sblom>And it requires copying in a Traits struct from v8->next()
20:50:44  <trevnorris>sblom: so, would you say there's some sort of interaction between object_wrap and env that is causing this issue?
20:51:03  <sblom>trevnorris: I think the env thing was a red herring.
20:51:46  <trevnorris>ok. so there's just bad code in object_wrap
20:52:00  <trevnorris>because seriously, the exact same code in object_wrap exists elsewhere in core.
20:52:09  <trevnorris>that's why we were able to get rid of it
20:53:17  <trevnorris>sblom: and line 139 in object_wrap is nothing.
20:53:20  <trevnorris>it's a bracket
20:54:31  <trevnorris>sblom: also, for kicks. will it compile if you remove the #ifdef at the top of node_object_wrap?
20:59:37  * inolenjoined
21:00:24  <trevnorris>sblom: so, if I remove the ifdef in node_object_wrap, but leave the template class statements in, I get the exact same error.
21:01:30  <trevnorris>sblom: so it's because of the "template class NODE_EXTERN v8::Persistent<T>" statements that 's giving you the error.
21:02:20  <tjfontaine>so, I'm basically ok to drop object_wrap.h from node.h, as long as we update the documentation
21:02:23  * inolenquit (Client Quit)
21:02:37  <tjfontaine>it's not too unacceptable for people to have to include a separate header for it
21:02:48  * mikealjoined
21:02:50  <trevnorris>tjfontaine: well, if we can just remove the template statements at the top of object_wrap then we should be in the clear.
21:03:10  <trevnorris>i can reproduce the same error he's getting w/ clang.
21:03:16  <tjfontaine>ok
21:03:47  <tjfontaine>my cycles are limited atm talking with groundwater_
21:04:11  <trevnorris>tjfontaine: about what? tell that hoser I need to speak w/ him.
21:04:42  * st_lukequit (Remote host closed the connection)
21:05:11  * st_lukejoined
21:07:27  <tjfontaine>trevnorris: right message delivered
21:08:29  <trevnorris>thanks
21:09:04  <trevnorris>sblom: so, I still want most of that PR you posted, but just including node_object_wrap in node.h. it's good to not have it scattered throughout core if we're not using it.
21:09:22  * st_lukequit (Ping timeout: 241 seconds)
21:09:34  <trevnorris>sblom: then also, if you could let me know if you can compile just fine w/o those two template statements at the top of node_object_wrap.h then it should be done.
21:14:07  * inolenjoined
21:19:10  * inolenquit (Quit: Leaving.)
21:21:00  * st_lukejoined
21:23:59  * AvianFluquit (Remote host closed the connection)
21:24:06  * dshaw_joined
21:24:23  <sblom>trevnorris: the other failure that I get if I remove those two lines is on line 138 where handle_ is declared.
21:31:10  <trevnorris>sblom: ok, well we're getting somewhere. again, storing the persistent that way is done all over core. do you think not being added to node.gyp could be affecting it?
21:32:24  <sblom>_possibly_, but that's not making my spidey sense tingle.
21:32:35  <sblom>It's pretty rare to have a header explicitly in gyp.
21:32:37  <sblom>I think.
21:33:00  * hzjoined
21:33:07  * dominictarrquit (Quit: dominictarr)
21:33:39  <tjfontaine>having a header in gyp doesn't really matter, it's just to inform build system to watch if the file changes, or
21:33:50  <tjfontaine>for vs to be able to include it in the project
21:38:40  * AvianFlujoined
21:43:57  * rendarquit (Quit: Leaving)
21:50:09  * AvianFluquit (Ping timeout: 272 seconds)
21:51:27  <trevnorris>ok. well I'm going to go with we're simply using it wrong in this case. since we do the same thing elsewhere and it doesn't fail.
22:02:49  * st_lukequit (Ping timeout: 272 seconds)
22:02:52  <sblom>trevnorris: I'll fiddle around with this and see if I can figure out how to make it work without the Copyable trait.
22:03:27  <trevnorris>sblom: what's the error you get with handle_ ?
22:03:35  <sblom>tjfontaine: Is it worth checking one of our imperfect fixes just to make it build again?
22:03:51  <sblom>trevnorris: It's the same one. That Uncompilable<Object> thing.
22:04:15  <sblom>With most of the include stack being in v8.h
22:04:21  <sblom>I'll add it to that gist.
22:04:24  <trevnorris>thanks.
22:08:43  <sblom>Added error2.txt to taht gist.
22:09:04  * Kakera_joined
22:09:15  <sblom>https://gist.github.com/sblom/18223965e31eda6ff89b
22:10:01  <trevnorris>sblom: sorry, mind trying one more thing for me? remove the two template class lines, and remove the NODE_EXTERN in the class declaration.
22:11:25  <sblom>trevnorris: build started--this is promising...
22:11:28  * luxigojoined
22:12:16  <sblom>trevnorris: bingo
22:12:27  * Kakeraquit (Ping timeout: 260 seconds)
22:12:59  * Kakera_changed nick to Kaker
22:13:00  * Kakerchanged nick to Kakera
22:13:15  * st_lukejoined
22:13:15  <trevnorris>ok/ unfortunately I don't think users can build modules using it w/o that. let me post my test module.
22:18:00  * st_lukequit (Ping timeout: 259 seconds)
22:18:45  * dominictarrjoined
22:21:16  * st_lukejoined
22:24:35  * bnoordhuisjoined
22:27:47  * mcavagejoined
22:29:32  <bnoordhuis>oh dear. the internet just grew four non-ascii tlds?
22:30:06  <trevnorris>bnoordhuis: ah, the sage of wisdom. maybe you can shed light on this persistent handle issue in node_object_wrap on windows
22:31:00  <trevnorris>bnoordhuis: so, if we remove the template stuff at the top, and remove NODE_EXTERN from the class, node'll build on windows.
22:31:29  <trevnorris>I can't figure out what it is about NODE_EXTERN that would cause that error. here are sblom's compile errors: https://gist.github.com/sblom/18223965e31eda6ff89b
22:31:49  <bnoordhuis>trevnorris: truth be told, i was always rather surprised msvs required us to declare the templates upfront
22:32:01  <bnoordhuis>trevnorris: so if they go, great
22:32:24  <trevnorris>bnoordhuis: how about the NODE_EXTERN part? it give those strange errors if the class has it.
22:33:20  <bnoordhuis>i'm not sure. it marks the class as dllimport/dllexport, depending on whether you build an add-on
22:34:01  <bnoordhuis>removing it will probably break things but i don't pretend to understand the finer details
22:42:45  * pachetquit (Quit: leaving)
22:42:46  <bnoordhuis>#6411 looks fine to me btw
22:43:18  <trevnorris>sblom: ok, don't know if you want to try this, but here's a basic module using latest master and ObjectWrap https://gist.github.com/trevnorris/7146409
22:43:36  <trevnorris>sblom: if you can compile that w/ node-gyp and run run.js, then i'd say we're in the clear.
22:44:02  <trevnorris>bnoordhuis: ok. that'll require update to documentation
22:44:07  * AvianFlujoined
22:44:15  <trevnorris>right now it's documented that you get ObjectWrap from node.h
22:44:18  <bnoordhuis>trevnorris: err. why>
22:44:28  <bnoordhuis>eh. mac keyboard
22:44:37  <trevnorris>i dunno. :P
22:44:58  <bnoordhuis>oh sorry. your second-to-last comment took a while to arrive here
22:45:10  <bnoordhuis>seems my connection to freenode is laggy
22:45:53  <trevnorris>oh, hah
22:45:54  <bnoordhuis>if we document that node.h includes node_object_wrap.h, then yes, we should update that :)
22:46:23  <trevnorris>cool. but we'll still need to check if users can compile modules using node_object_wrap.h on windows.
22:46:37  <bnoordhuis>yeah. that's what the NODE_EXPORT thing is for
22:46:47  <trevnorris>i just can't understand why NODE_EXTERN is causing that error.
22:47:12  <bnoordhuis>me neither. but i have only a dim understanding of msvc's model of compilation/linking
22:49:19  <sblom>trevnorris, bnoordhuis: NODE_EXTERN is telling the compiler to make the class available to the consumer of a DLL, and it has no way to know that no one will want to use the assignment operator on v8::Persistent.
22:49:42  <sblom>So it's failing to compile now that v8 guards against uses of the assignment operator.
22:50:01  <trevnorris>ah.... well, that sucks.
22:50:08  * Kakera_joined
22:50:24  <trevnorris>sblom: awesome though. great we actually know why it's happening :)
22:51:33  <trevnorris>sblom: so, is there a way to tell MSVC not to worry about it?
22:52:10  * Kakeraquit (Ping timeout: 256 seconds)
22:54:26  <sblom>trevnorris: The options I can come up with are: 1) determine that we don't need this to be a NODE_EXPORT, 2) don't expose v8::Persistent pointers or references over a DLL boundary, 3) patch v8 to make this a runtime crash instead of a compile time failure, 4) use the CopyablePersistentTraits trait to ask the compiler to not guard against this (need v8 3.22 or a copied/pasted `struct CopyablePe
22:54:26  <sblom>rsistentTraits`).
22:55:11  <trevnorris>bnoordhuis: your thoughts?
22:55:17  <sblom>I'm thinking 4), frankly. Although it would be safest to sanity check that with some v8 developer who understands their intention behind the NonCopyable/Copyable traits thing.
22:55:42  <bnoordhuis>i think i agree
22:55:49  <bnoordhuis>1 and 2 don't seem very viable
22:56:12  <bnoordhuis>3 is probably out because we'd rather not carry v8 patches
22:56:26  <bnoordhuis>which leaves us with option 4
22:56:30  <tjfontaine>ya 3 is pretty much out
22:57:15  <trevnorris>so, does that mean we're upgrading to 3.22, or are we going to float a patch?
22:57:35  <tjfontaine>we can't really upgrade to 3.22 yet
22:57:56  <tjfontaine>and floating a patch we really really really don't want to do in general :)
22:58:11  <trevnorris>so it's between we don't want to, and we really really don't want to?
22:58:11  * Kakera_quit (Ping timeout: 260 seconds)
22:58:21  <bnoordhuis>i guess we could also revert the upgrade
22:58:21  <sblom>So we'll have to carry CopyablePersistentTraits on our own until then. Not awesome, but doesn't seem like the end of the world.
22:58:31  <tjfontaine>reverting the upgrade is probably the short term solution
22:58:38  * abraxasjoined
22:58:40  <sblom>Interesting.
22:58:47  <sblom>I'm okay with that.
22:58:52  <tjfontaine>we should talk to somebody
22:58:56  <sblom>But if we're motivated to upgrade, I think we have options...
22:58:58  <trevnorris>well, wait. if object_wrap is a self contained header file that just depends on v8, then why does it need NODE_EXTERN?
22:59:15  <bnoordhuis>good question. sblom?
22:59:21  <tjfontaine>trevnorris: if module authors want to use it, and be on windows, the symbol will need to be resolved?
22:59:39  <sblom>But I don't think it'll need to resolve across DLL boundaries, right?
22:59:45  <trevnorris>what symbol? node isn't using ObjectWrap anymore.
22:59:50  <trevnorris>yeah, shouldn't have to.
23:00:13  <sblom>Yeah--it really might not need to be NODE_EXPORT any more.
23:00:21  <sblom>I'll try trevnorris's test module.
23:00:23  <bnoordhuis>could there be an issue for add-ons that compile down to multiple dlls?
23:00:43  <sblom>bnoordhuis: Perhaps. Does that exist?
23:00:51  <bnoordhuis>i'm not 100% sure
23:01:13  <trevnorris>i say we run w/ this and wait for an issue to pop up. so far this seems like the best solution to me :)
23:01:29  <tjfontaine>plugging your ears and saying "la la la" is not really a solution :)
23:01:40  <sblom>tjfontaine: This isn't _quite_ that bad.
23:01:49  <sblom>:p
23:01:52  <tjfontaine>:)
23:02:43  <trevnorris>hey, if the dude that actually works at microsoft is willing to go this route, who am I to argue?
23:02:49  <tjfontaine>heh
23:03:02  * abraxasquit (Ping timeout: 240 seconds)
23:03:11  <bnoordhuis>well... if it turns out after v0.12 that there is some unforeseen corner case, then we have an issue
23:04:03  <trevnorris>bnoordhuis: by the time they get done upgrading their modules to the new v8 api, we'll be out with v1.0 :P
23:05:01  <sblom>Just saw tjfontaine and isaacs in the New Relic on Node video.
23:05:06  <bnoordhuis>that made me laugh but the point still stands :)
23:05:11  <tjfontaine>sblom: dun dun dun
23:06:00  <sblom>Alright--so here's what I'm going to do. I'm going to try building the test module without NODE_EXPORT and if it fails, we know this won't fly.
23:06:09  <tjfontaine>right
23:06:13  <trevnorris>*la la la*
23:06:13  <sblom>If it succeeds, we'll think harder.
23:06:21  <tjfontaine>indeed
23:06:44  <bnoordhuis>s/think/snore/ for me personally. signing off, sleep tight folks :)
23:06:50  <tjfontaine>bnoordhuis: night!
23:06:54  <trevnorris>night ben
23:07:40  <trevnorris>sblom: oh wait. if you're not using NODE_EXTERN you'll need to #include <node_object_wrap.h> at the top of basic.cc
23:07:52  <trevnorris>or else it'll definitely not compile.
23:09:57  * luxigoquit (Ping timeout: 272 seconds)
23:10:31  * AvianFlu_joined
23:10:33  * AvianFluquit (Remote host closed the connection)
23:10:48  * bnoordhuisquit (Ping timeout: 240 seconds)
23:12:30  <trevnorris>heh, that was funny. sblom so I applied your 6411 patch to test it out, compiled, then made a change and compiled again. told me nothing to be done.
23:12:36  <trevnorris>makes sense, but just wasn't expecting it.
23:16:08  * hzquit
23:16:10  <trevnorris>sblom: also, you'll probably want to remove #include "node.h" from node_object_wrap.h.
23:16:15  <trevnorris>it shouldn't be needed anymore.
23:16:41  <trevnorris>ah crap. other than they share the same namespace.
23:17:01  <trevnorris>but I guess that wouldn't cause any damage?
23:18:58  * defunctzombiechanged nick to defunctzombie_zz
23:20:11  <trevnorris>tjfontaine: you still around groundwater_?
23:35:29  * st_lukequit (Remote host closed the connection)
23:35:58  * st_lukejoined
23:39:01  * c4miloquit (Remote host closed the connection)
23:39:33  * c4milojoined
23:40:07  * st_lukequit (Ping timeout: 240 seconds)
23:40:50  * mikealquit (Quit: Leaving.)
23:40:57  * st_lukejoined
23:43:50  * c4miloquit (Ping timeout: 240 seconds)
23:43:55  * c4milo_joined
23:46:09  * st_lukequit (Remote host closed the connection)
23:51:07  * paddybyersquit (Ping timeout: 240 seconds)
23:51:16  * dominictarrquit (Quit: dominictarr)
23:56:00  <sblom>trevnorris: I'm having trouble getting this to build using node-gyp and have to run for now, but I'll pick up again later. Looking like NODE_EXTERN is going to be required.
23:56:08  <sblom>In which case, we're back to only option 4 being possible.
23:56:42  <trevnorris>sblom: ok. we'll talk later. I don't get why NODE_EXTERN would be required since I can just remove "node.h" from node_object_wrap completely
23:56:47  <trevnorris>it's basically a sand alone header file.
23:57:23  <trevnorris>also, that module is using your PR that's removed node_object_wrap from core
23:57:27  <trevnorris>just to be clear
23:58:59  * defunctzombie_zzchanged nick to defunctzombie
23:59:55  <MI6>libuv-master-gyp: #244 FAILURE windows-x64 (3/196) windows-ia32 (3/196) http://jenkins.nodejs.org/job/libuv-master-gyp/244/