00:00:00  * ircretaryquit (Remote host closed the connection)
00:00:08  * ircretaryjoined
00:05:58  <M28>is porting node.js to spidermonkey something that's actually being thought about, or it's just "yeah that'd be cool I guess"?
00:08:42  * loladirojoined
00:13:48  * loladiroquit (Quit: loladiro)
00:26:18  <tjfontaine>M28: bnoordhuis has some code
00:26:40  <M28>but are there plans to actually implement it? :O
00:27:13  <M28>a cool idea would be abstracting away the javascript engine, so it'd be possible to toggle between the two with a #define
00:28:11  <tjfontaine>it's certainly something we've talked about, plenty of other things that need to happen before then
00:28:56  <M28>any special reason though? perfomance?
00:29:12  <tjfontaine>special reason why we haven't done it yet?
00:29:21  <M28>special reason to switch
00:29:38  <tjfontaine>oh, good to keep your options open :)
00:29:44  <M28>oh well
00:29:54  <M28>also, I have a question about v8's api, if you don't mind
00:29:59  <M28>#v8 is kinda slow... you know
00:30:14  <M28>is calling C++ functions relatively slow?
00:30:22  <tjfontaine>actually, not really
00:30:39  <tjfontaine>for purposes of the conversation we'll just call it crosssing the boundary I guess
00:31:55  <M28>in a lot of interpreted languages, crossing the boundary is kinda slow
00:31:57  <tjfontaine>it's really not that bad to cross, it's actually generally more expensive to do a lot of object creation and manipulation on the far side, as the JIT is pretty damn good at its job
00:32:15  <tjfontaine>I'm not going to say it comes at 0 cost, it has a cost
00:32:44  <tjfontaine>but it's easy to do things that seem cheap, that are accumulatively more expensive
00:32:52  <M28>I see
00:33:35  * kazuponjoined
00:33:37  <tjfontaine>trevnorris had some numbers, somewhere
00:33:56  <M28>oh cool
00:34:51  <M28>I already used v8 for modding in a game, I'm still thinking if I should use it for the server side of my current project
00:35:14  <tjfontaine>so, one of things in that blog post was a "best principles" idea for addons
00:35:46  <tjfontaine>the best thing you can do, is have a rule that you only operate on primitives
00:36:11  <tjfontaine>pass exactly what you want across the boundary, and only return what you need back
00:36:27  <tjfontaine>but avoid lots of ->Get and ->Sets
00:37:22  * st_lukequit (Remote host closed the connection)
00:38:58  * kazuponquit (Ping timeout: 276 seconds)
00:42:30  * bnoordhuisjoined
00:47:01  * bnoordhuisquit (Ping timeout: 248 seconds)
00:57:03  * dominictarrquit (Quit: dominictarr)
01:05:57  * mikealquit (Quit: Leaving.)
01:23:22  * hzquit
01:34:11  * kazuponjoined
01:36:13  * mikealjoined
01:39:25  * kazuponquit (Ping timeout: 276 seconds)
02:00:51  * pooyaquit (Quit: pooya)
02:03:32  * AvianFlujoined
02:11:21  <M28>is it normal that uv_now() gets cached after a second or so and never gets updated (even with the loop running)?
02:11:32  <M28>it's probably not updating because I'm not doing any io after that time
02:12:06  <tjfontaine>if the loop is ticking it should be advancing, are you inspecting from outside the thread?
02:18:20  <M28>no
02:18:35  <M28>running uv_run(m_pLoop, UV_RUN_NOWAIT); every 16 ms
02:18:59  * kazuponjoined
02:19:01  <M28>and outside that function I was using uv_now() and I was getting the cached value
02:19:11  <M28>I had to add uv_update_time to my main loop
02:20:47  <tjfontaine>the first thing each loop does (win/unix) is update the time, so if you're not seeing it advance, than you're not really spinning every 16ms and instead spending too much time in a cb, or you actually have found a legit bug
02:21:21  <tjfontaine>is this unix or win?
02:21:39  * jmar777joined
02:22:43  <M28>win
02:23:03  <M28>lemme show you
02:23:32  <tjfontaine>I had a feeling
02:24:52  <M28>tjfontaine: http://puu.sh/3wN8t/08a91c707a.png
02:25:10  <M28>I'm casting it to an int so I can print it, but it doesn't change the result
02:25:19  <M28>for the first second, when I'm doing a tcp request, it's updating just fine
02:25:38  <M28>after the request times out (because my server is down), the loop stops updating the time
02:26:01  <tjfontaine>https://github.com/joyent/libuv/blob/master/src/win/timer.c#L31-L59
02:26:21  <tjfontaine>M28: try and work up a small test case, it sounds like a legit bug
02:26:58  <M28>if I add uv_update_time() to right before the uv_run (haven't tested after, should work too), it works fine: http://puu.sh/3wNbJ/31d7c43f7d.png
02:27:19  <M28>(I was printing the value of uv_now twice before, ignore that)
02:27:46  <M28>why not simply put uv_update_time at the beginning of uv_run?
02:28:17  <M28>the problem is in uv_run, not uv_update_time
02:28:56  <tjfontaine>https://github.com/joyent/libuv/blob/master/src/win/core.c#L282
02:28:57  <tjfontaine>it is
02:29:15  <M28>that thing should be moved outside the loop
02:29:27  <tjfontaine>it needs to happen in both
02:29:38  <tjfontaine>you want it going for every iteration of the loop
02:30:28  <tjfontaine>but yes, you're seeing that in the (*poll)()
02:31:58  <tjfontaine>M28: file a bug, saying you're getting stale time in the IO cbs at the start of the loop
02:32:22  <M28>I'm not good at writing bugs >_>
02:32:26  <M28>I mean
02:32:28  <M28>bug reports
02:32:31  <M28>bugs I'm great at
02:33:02  <tjfontaine>well, just boil it down to a single file test the rest will speak for itself
02:34:46  * c4milojoined
02:38:12  <tjfontaine>so you're saying you have no open read/write requests, or streams?
02:39:14  <M28>tjfontaine: https://github.com/joyent/libuv/issues/846
02:39:35  <M28>yes, after my tcp connection dies, I have nothing open anymore
02:40:25  <M28>alright, just tested in smaller environment, with only that code, and it still happens
02:40:37  <M28>the bug report has a test case
02:41:24  <tjfontaine>good work
02:41:37  <tjfontaine>that wasn't so hard was it? :)
02:41:41  <M28>meh
02:41:46  <M28>I'm better at writing bugs
02:44:14  <M28>now gimme recursive mutexes
02:51:50  * timoxleyjoined
03:16:25  <M28>just to confirm, uv_run with UV_RUN_DEFAULT will only return when all IO operations have ended, right?
03:25:13  * kazuponquit (Remote host closed the connection)
03:25:42  * kazuponjoined
03:30:13  * kazuponquit (Ping timeout: 248 seconds)
03:30:43  * dominictarrjoined
03:35:24  <tjfontaine>M28: when there are no more open reqs/handles
03:36:03  <M28>alright, ty
03:36:21  * amartensquit (Quit: Leaving.)
03:36:26  * loladirojoined
04:03:45  * timoxleyquit (Ping timeout: 264 seconds)
04:06:44  * amartensjoined
04:14:07  * amartensquit (Ping timeout: 276 seconds)
04:18:54  * c4miloquit (Remote host closed the connection)
04:33:47  * niska`changed nick to niska
04:38:45  * jmar777quit (Remote host closed the connection)
04:51:56  * kazuponjoined
05:08:25  * AvianFluquit (Remote host closed the connection)
05:11:20  * amartensjoined
05:14:19  * amartensquit (Read error: Connection reset by peer)
05:14:33  * amartensjoined
05:14:42  * timoxleyjoined
05:16:54  * mikealquit (Quit: Leaving.)
05:18:21  * mikealjoined
05:21:44  * kazuponquit (Remote host closed the connection)
05:22:11  * kazuponjoined
05:22:28  * kazuponquit (Read error: Connection reset by peer)
05:22:51  * kazuponjoined
05:29:11  * defunctzombie_zzchanged nick to defunctzombie
05:38:39  * defunctzombiechanged nick to defunctzombie_zz
05:52:14  * mikealquit (Quit: Leaving.)
05:52:21  * timoxleyquit (Ping timeout: 264 seconds)
05:54:53  * kazuponquit (Remote host closed the connection)
05:55:20  * kazuponjoined
06:00:09  * kazuponquit (Ping timeout: 264 seconds)
06:12:48  * mikealjoined
06:21:47  * pooyajoined
06:32:24  * pooyaquit (Quit: pooya)
06:33:36  * timoxleyjoined
06:37:56  * chrisdicojoined
06:38:14  * mikeal1joined
06:38:39  * isaacs_joined
06:38:46  * chrisdicoquit (Client Quit)
06:38:51  * tjfontai1ejoined
06:39:02  * isaacs_changed nick to Guest80162
06:43:45  * mikealquit (*.net *.split)
06:43:47  * philipsquit (*.net *.split)
06:43:49  * tjfontainequit (*.net *.split)
06:43:49  * isaacsquit (*.net *.split)
06:43:49  * chrisdickinsonquit (*.net *.split)
06:44:45  * philipsjoined
06:47:57  * rendarjoined
06:54:24  * groundwaterquit (Quit: groundwater)
07:12:24  * chrisdickinsonjoined
07:20:24  * defunctzombie_zzchanged nick to defunctzombie
07:25:47  * kazuponjoined
07:25:49  * defunctzombiechanged nick to defunctzombie_zz
07:30:45  * kazuponquit (Ping timeout: 264 seconds)
08:27:02  * kazuponjoined
08:29:42  * timoxleyquit (Quit: Textual IRC Client: www.textualapp.com)
08:31:57  * kazuponquit (Ping timeout: 264 seconds)
08:38:26  * timoxleyjoined
08:49:03  * loladiroquit (Quit: loladiro)
08:51:02  * amartensquit (Quit: Leaving.)
08:52:42  * dominictarrquit (Quit: dominictarr)
09:27:37  * kazuponjoined
09:32:33  * kazuponquit (Ping timeout: 264 seconds)
09:51:19  * amartensjoined
09:56:49  * kazuponjoined
09:57:34  * kazuponquit (Remote host closed the connection)
09:58:01  * kazuponjoined
09:58:17  * amartensquit (Ping timeout: 256 seconds)
10:02:42  * kazupon_joined
10:03:10  * kazuponquit (Ping timeout: 276 seconds)
10:11:23  * stagasjoined
10:51:49  * hzjoined
10:55:53  * amartensjoined
11:01:01  * amartensquit (Ping timeout: 276 seconds)
11:46:31  * stagasquit (Ping timeout: 252 seconds)
11:56:12  * amartensjoined
12:00:37  * amartensquit (Ping timeout: 248 seconds)
12:56:37  * amartensjoined
13:00:56  * amartensquit (Ping timeout: 252 seconds)
13:34:51  * kazupon_quit (Remote host closed the connection)
13:35:18  * kazuponjoined
13:40:21  * kazuponquit (Ping timeout: 264 seconds)
13:49:22  * kazuponjoined
13:56:57  * amartensjoined
13:59:03  * AvianFlujoined
14:01:13  * kazuponquit (Remote host closed the connection)
14:01:42  * kazuponjoined
14:01:43  * amartensquit (Ping timeout: 276 seconds)
14:05:57  * kazuponquit (Ping timeout: 248 seconds)
14:12:09  * hzquit (Read error: Connection reset by peer)
14:12:21  * hzjoined
14:22:11  * hzquit
14:42:55  * bradleymeckjoined
14:55:17  * jmar777joined
14:56:04  * kazuponjoined
14:57:15  * amartensjoined
15:01:44  * amartensquit (Ping timeout: 256 seconds)
15:05:27  * pachetjoined
15:05:27  * pachetquit (Changing host)
15:05:27  * pachetjoined
15:11:40  * AvianFluquit (Remote host closed the connection)
15:31:29  * jmar777quit (Remote host closed the connection)
15:49:20  * jmar777joined
15:51:30  * jmar777quit (Remote host closed the connection)
15:57:33  * amartensjoined
16:02:37  * amartensquit (Ping timeout: 276 seconds)
16:07:14  * groundwaterjoined
16:20:54  * bnoordhuisjoined
16:23:41  * tjfontai1echanged nick to tjfontaine
16:23:47  * tjfontainequit (Changing host)
16:23:47  * tjfontainejoined
16:29:14  * defunctzombie_zzchanged nick to defunctzombie
16:36:22  * bnoordhuisquit (Ping timeout: 256 seconds)
16:38:30  * st_lukejoined
16:43:46  * dsantiagoquit (Quit: Computer has gone to sleep.)
16:57:55  * amartensjoined
16:59:42  * amartensquit (Read error: Connection reset by peer)
16:59:44  * amartens1joined
17:01:11  * dominictarrjoined
17:11:10  * kazuponquit (Remote host closed the connection)
17:11:37  * kazuponjoined
17:16:21  * kazuponquit (Ping timeout: 248 seconds)
17:23:56  * st_lukequit (Remote host closed the connection)
17:41:42  * bradleymeckquit (Quit: bradleymeck)
17:43:08  * bnoordhuisjoined
17:47:29  * bnoordhuisquit (Ping timeout: 256 seconds)
17:48:21  * bradleymeckjoined
17:53:58  * bnoordhuisjoined
17:57:38  * mikeal1quit (Quit: Leaving.)
17:58:16  * mikealjoined
18:19:49  * bnoordhuisquit (Ping timeout: 248 seconds)
18:41:53  * amartens1quit (Quit: Leaving.)
18:42:02  * kazuponjoined
18:46:29  * kazuponquit (Ping timeout: 248 seconds)
18:47:18  * timoxleyquit (Quit: Computer has gone to sleep.)
18:50:51  * st_lukejoined
18:58:06  * bradleymeckquit (Quit: bradleymeck)
19:04:38  * defunctzombiechanged nick to defunctzombie_zz
19:09:38  * stagasjoined
19:12:23  * dominictarrquit (Quit: dominictarr)
19:13:45  * c4milojoined
19:20:14  * c4miloquit (Remote host closed the connection)
19:20:36  * defunctzombie_zzchanged nick to defunctzombie
19:21:46  * stagas_joined
19:25:21  * stagasquit (Ping timeout: 264 seconds)
19:25:25  * stagas_changed nick to stagas
19:26:04  * bnoordhuisjoined
19:26:16  * c4milojoined
19:28:39  * bnoordhuisquit (Read error: Operation timed out)
19:29:42  * st_lukequit (Remote host closed the connection)
19:33:37  * c4miloquit (Remote host closed the connection)
19:42:11  * amartensjoined
19:42:45  * kazuponjoined
19:46:45  * amartensquit (Ping timeout: 248 seconds)
19:47:33  * kazuponquit (Ping timeout: 264 seconds)
19:56:52  * pooyajoined
20:02:03  * TooTallNatejoined
20:03:14  * defunctzombiechanged nick to defunctzombie_zz
20:08:41  * stagas_joined
20:09:41  * st_lukejoined
20:10:43  * stagasquit (Ping timeout: 246 seconds)
20:14:37  * stagas_quit (Ping timeout: 268 seconds)
20:14:38  * amartensjoined
20:20:47  * TooTallNatequit (Quit: ["Textual IRC Client: www.textualapp.com"])
20:37:54  * loladirojoined
20:43:50  * kazuponjoined
20:44:44  * pooyaquit (Quit: pooya)
20:47:31  * defunctzombie_zzchanged nick to defunctzombie
20:48:20  * stagas__joined
20:48:25  * stagas__changed nick to stagas
20:48:32  * kazuponquit (Ping timeout: 268 seconds)
20:49:34  * bradleymeckjoined
20:49:57  <juliangruber>is npmjs.org down?
20:58:08  * stagasquit (Quit: Bye)
21:07:36  * dominictarrjoined
21:09:20  * defunctzombiechanged nick to defunctzombie_zz
21:11:39  * loladiroquit (Quit: loladiro)
21:13:08  * loladirojoined
21:14:52  * defunctzombie_zzchanged nick to defunctzombie
21:20:18  * rendarquit
21:21:59  <mmalecki>juliangruber: https://twitter.com/nodejitsu/status/353986040182218752
21:22:18  <mmalecki>juliangruber: not anymore
21:22:24  <juliangruber>mmalecki: sweet
21:22:33  <juliangruber>mmalecki: so you guys are actively fixing npm bugs too?
21:23:01  <mmalecki>juliangruber: JasonSmith is, so yeah :)
21:23:11  <juliangruber>mmalecki: aaaaawesome!
21:24:17  * defunctzombiechanged nick to defunctzombie_zz
21:36:26  * defunctzombie_zzchanged nick to defunctzombie
21:40:05  * pachetquit (Ping timeout: 252 seconds)
21:41:03  * dominictarrquit (Ping timeout: 260 seconds)
21:44:25  * kazuponjoined
21:48:55  * defunctzombiechanged nick to defunctzombie_zz
21:49:11  * kazuponquit (Ping timeout: 256 seconds)
21:54:04  * defunctzombie_zzchanged nick to defunctzombie
21:58:12  * loladiroquit (Quit: loladiro)
22:00:04  * AvianFlujoined
22:01:39  * bradleymeckquit (Quit: bradleymeck)
22:02:34  * loladirojoined
22:03:52  <trevnorris>who what?
22:03:57  <trevnorris>M28: you need something?
22:04:21  * loladiroquit (Client Quit)
22:04:45  <tjfontaine>he was asking about the cost of crossing the boundary
22:04:47  * pooyajoined
22:05:03  <trevnorris>ah, haven't tested w/ 3.20 upgrade, but it's pretty slim now.
22:05:24  <tjfontaine>answering with the numbers froms table are what he probably cares about for now
22:05:31  <tjfontaine>but that's basically what I said
22:05:36  <M28>meh, if it's really slim then I don't care a lot
22:05:37  <trevnorris>cool.
22:05:48  <trevnorris>M28: ping me and I'll give you some actual number :)
22:05:48  <tjfontaine>and that object manipulation was the expensive part
22:05:54  <trevnorris>heh, yeah.
22:07:30  <trevnorris>tjfontaine: i'll add one more to your list. immediate, basically to do what nextTick does now.
22:07:41  <trevnorris>tjfontaine: i like the idea of turn and schedule.
22:07:56  <trevnorris>tjfontaine: though I think setTimeout and setInterval will have to stick around.
22:08:12  <trevnorris>you'll get a lot of flack trying to deprecate those, and they make enough sense
22:08:18  <tjfontaine>how is immediate different than turn
22:08:35  <tjfontaine>yes, the upheaval on removing those globals would be noisey
22:08:57  <trevnorris>it's the same difference of how nextTick and setImmediate work now.
22:09:10  <trevnorris>nextTick is more "immediate" than setImmediate
22:09:12  <tjfontaine>but that's an implementation detail of how it consumes a turn
22:09:28  <trevnorris>how do you mean "consumes a turn"
22:09:32  <trevnorris>you mean one turn on uv_run?
22:09:36  <tjfontaine>yes
22:09:44  <trevnorris>but nextTick bypasses uv_run
22:10:00  <trevnorris>it's bascially a while loop that runs scripts in an array queue
22:10:21  <tjfontaine>yes, that gets cleared at the moment (in v0.11) at the end of a turn, right?
22:10:28  <trevnorris>no.
22:10:38  <tjfontaine>when is that queue processed?
22:10:39  <trevnorris>either all the functions run
22:10:53  <trevnorris>or if there's an error then it breaks for I/O then resumes on the next tick
22:11:15  <tjfontaine>ok, but again that's an implementation detail of nextTick, when does nextTick fire in terms of a turn
22:11:49  <trevnorris>nextTick queue'd callbacks run immediately after a function has been called by MakeCallback
22:12:10  <tjfontaine>so the queue is processed (ignoring errors) on every make callback?
22:12:26  * bnoordhuisjoined
22:14:16  <trevnorris>tjfontaine: It'll break on any error thrown, but other than that it will continue to run scripts in the nextTickQueue until complete: http://git.io/lAiaiQ
22:14:34  <tjfontaine>yes, I get *how* the queue is cleared, I don't care about that part of it
22:14:35  <tjfontaine>:)
22:14:37  <trevnorris>heh
22:15:02  <tjfontaine>the question is when consumers (not core) would expect nextTick to fire
22:15:33  <trevnorris>after any callback that is passed to MakeCallback (e.g. oncomplete())
22:16:11  <tjfontaine>right, so anything that calls makecallback (ironically check immediate etc)
22:16:24  <tjfontaine>which is how core expects it to work
22:17:31  <tjfontaine>but what matters more to external consumers is that we specify the concept of a true tick
22:17:42  <tjfontaine>or turn really, since ticks mean something else entirely
22:18:20  <trevnorris>setImmediate does only work on a true uv_run tick
22:18:35  <tjfontaine>yes, it's the only one that has knowledge of a turn
22:19:03  <trevnorris>yeah, and MakeCallback can run an almost any point in uv_run, which is necessary but difficult to explain.
22:19:16  <tjfontaine>right, and noone externally should be relying on that behavior
22:19:34  <tjfontaine>what process.nextTick should actually be, is this non-recursive list
22:20:11  <tjfontaine>run an entire queue of functions on the next turn of the event loop (doesn't exist today)
22:20:15  <trevnorris>to clarify, what process.nextTick _does_ is necessary for developers. what it's called I really don't care.
22:20:34  <tjfontaine>the non-deterministic nature of nextTick is not what developers want
22:20:57  <trevnorris>it's necessary if the developer needs to run a script before any I/O has been preformed.
22:21:52  <tjfontaine>it's not really that simple though is it
22:21:57  <trevnorris>how not?
22:22:05  <tjfontaine>that is certainly how core uses it, in very tight circumstances
22:23:03  <tjfontaine>if an error happens you can get delayed until after the io has happened, right?
22:23:26  * c4milojoined
22:23:27  <trevnorris>very tight is sort of arbitrary here. process.nextTick exists in the context of the callback in which it's being called. not in the context of the event loop.
22:24:10  <trevnorris>I have a callback, and I need other callbacks to run after the current but before anything else. so I use process.nextTick. very simple.
22:24:44  <tjfontaine>ok, so lets talk about what happens when something errors in nextTick
22:25:06  * dapjoined
22:25:30  <tjfontaine>we keep churning through as io cbs happen, but the order in which you're fired is certainly not a mortal lock
22:25:39  <tjfontaine>sorry
22:25:45  <tjfontaine>the order wrt to the io cb happening
22:25:55  <trevnorris>heh :)
22:26:08  <tjfontaine>the order of queued cbs of course has to be determined
22:26:28  <trevnorris>technically it is, but isaacs has determined we don't want to officially support it.
22:26:47  <trevnorris>each callback is called in the order in which it was called.
22:27:17  <tjfontaine>so while internally in core we have a pretty good idea where and when to use nextTick, external usage of that should not rely on any significant behavior other than not happening synchronously
22:28:54  <trevnorris>only when an error is thrown. but how much do we guarantee if that happens?
22:28:55  <bnoordhuis>trevnorris: besides the object() thing, any other comments on the v8 upgrade?
22:29:31  <tjfontaine>trevnorris: we don't guarantee much of anything to the external consumer of nextTick
22:29:31  <trevnorris>bnoordhuis: not that I could see immediately. it'll take me a week to really go though, but lgtm as is.
22:29:33  <bnoordhuis>also, hi :)
22:30:37  <trevnorris>bnoordhuis: hey :)
22:31:42  <trevnorris>tjfontaine: we guarantee that if there are no errors that the cb passed will run before any other I/O
22:32:02  <tjfontaine>trevnorris: which in reality, is not really much at all
22:32:33  <tjfontaine>if we care about such things, we should first class start-of-turn and end-of-turn events
22:33:16  <tjfontaine>or rather, if we want to let the user care about such things
22:33:51  <trevnorris>if i'm understanding correctly, you're saying these should only work in context of the event loop?
22:34:32  <tjfontaine>for external consumers, I think it's the only part that makes sense
22:35:02  <tjfontaine>as it is, nextTick is very hard for end users to reason about
22:35:21  <tjfontaine>especially given the fact that you can recurse your way into hell
22:35:41  * bradleymeckjoined
22:36:29  <trevnorris>well, to me it's the same as telling a developer to not use an infinite loop.
22:37:00  <tjfontaine>except that we do things in core that they don't necessarily realize, so we don't help prevent the behavior, we can make it worse
22:37:04  <trevnorris>and they shouldn't be reasoning it in terms of the event loop, but instead of the callback that's calling it.
22:37:49  <tjfontaine>maybe, but then it absolutely shouldn't be called nexttick :P
22:37:59  <trevnorris>oh, that i'm totally fine with
22:38:10  <trevnorris>and actually something that tripped me up when I started working on it.
22:38:29  <trevnorris>i mean. runImmediate() or something makes more sense in this case.
22:41:19  <tjfontaine>I also fall in the group that we need fewer globals :)
22:41:27  <tjfontaine>though, that won't make anyone happy
22:41:51  <trevnorris>and i'm not arguing with that either :)
22:42:19  <trevnorris>but the fall out of making Buffers not work with Typed Arrays was not small.
22:42:33  <tjfontaine>well sure, because people don't get it :)
22:43:58  <trevnorris>and even a year ago i'd be more open, but the amount of code that depends on a stable js api has grown ridiculously since then.
22:45:34  * kazuponjoined
22:46:41  <trevnorris>bnoordhuis: do you know why they're removing the ability to simply dereference a Persistent's val_?
22:47:29  <trevnorris>or whatever it uses now.
22:48:44  * defunctzombiechanged nick to defunctzombie_zz
22:49:56  * kazuponquit (Ping timeout: 246 seconds)
22:54:36  * kazuponjoined
22:56:11  * kazuponquit (Remote host closed the connection)
22:56:38  * kazuponjoined
22:59:45  * jmar777joined
23:00:32  * jmar777quit (Remote host closed the connection)
23:01:52  * kazuponquit (Ping timeout: 276 seconds)
23:03:25  * defunctzombie_zzchanged nick to defunctzombie
23:08:45  * mikealquit (Quit: Leaving.)
23:12:25  * mikealjoined
23:12:57  * kazuponjoined
23:13:27  <bnoordhuis>trevnorris: i don't
23:13:35  <trevnorris>:(
23:13:48  <trevnorris>seems like they made that more complicated than necessary, imho
23:14:04  <bnoordhuis>i speculate that the val_ field will disappear in the future
23:14:20  <trevnorris>hm makes sense.
23:17:08  <bnoordhuis>apropos nothing, i think i'm going to eradicate the use of persistents to cache strings
23:17:58  <bnoordhuis>i'm reasonably sure caching all those strings in strong gc roots is pretty much a deoptimization
23:18:21  <tjfontaine>I can see how that might be
23:18:22  <trevnorris>hm. well performance tests show that not caching them causes a regression.
23:18:43  <bnoordhuis>how have you tested that?
23:18:44  <trevnorris>but they're the experts ;)
23:19:10  <trevnorris>bnoordhuis: the only folder in here (so far): https://github.com/trevnorris/talks
23:19:12  <bnoordhuis>btw, my plan is to use array indices rather than strings for MakeCallback stuff
23:19:30  <trevnorris>ooh. sounds interesting.
23:19:48  <trevnorris>the readme here explains the tests: http://git.io/y9HyvQ
23:20:20  <bnoordhuis>ah, right
23:21:24  <trevnorris>and if you MarkIndependent on the syms then it shouldn't have as much impact on the gc, right?
23:22:43  * bradleymeckquit (Quit: bradleymeck)
23:24:29  * kazuponquit (Remote host closed the connection)
23:24:58  * kazuponjoined
23:28:42  <bnoordhuis>trevnorris: well, that's the theory
23:29:11  <bnoordhuis>but i believe that what it actually does, is make weak handles collectable during scavenging
23:29:27  <bnoordhuis>rather than only during full gc rounds
23:29:47  * kazuponquit (Ping timeout: 260 seconds)
23:30:15  <bnoordhuis>but most of persistent handles aren't weak, they're strong
23:30:47  <bnoordhuis>most, not most of. unless it's 'most of our'
23:47:59  * c4miloquit (Remote host closed the connection)
23:57:57  * defunctzombiechanged nick to defunctzombie_zz