00:07:34  * loladirojoined
00:23:04  * isaacsquit (Remote host closed the connection)
00:26:32  <piscisaureus_>time to go. later
00:33:59  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
00:48:59  * orlandovftwquit (Ping timeout: 256 seconds)
00:50:46  * mjr_joined
00:51:37  * dapquit (Quit: Leaving.)
01:09:05  * isaacsjoined
01:18:47  * isaacschanged nick to SubStack_
01:19:10  * SubStack_changed nick to isaacs
01:27:04  * orlandovftwjoined
01:32:58  * pieternquit (Quit: pietern)
01:33:42  * ericktquit (Ping timeout: 244 seconds)
01:40:38  * abraxasjoined
01:42:49  * c4milojoined
01:58:41  * orlandovftwquit (Ping timeout: 245 seconds)
02:04:22  * pieternjoined
02:09:11  * brsonquit (Quit: leaving)
02:20:52  * orlandovftwjoined
02:48:44  * isaacsquit (Remote host closed the connection)
02:51:02  * orlandovftwquit (Ping timeout: 250 seconds)
03:09:22  * isaacsjoined
03:40:26  * c4miloquit (Ping timeout: 250 seconds)
03:49:13  * isaacsquit (Remote host closed the connection)
03:53:08  * pieternquit (Quit: pietern)
04:00:29  * mjr_quit (Quit: mjr_)
04:06:20  * isaacsjoined
04:07:43  * isaacsquit (Remote host closed the connection)
04:13:18  * orlandovftwjoined
04:20:47  * AlbireoXquit (Ping timeout: 276 seconds)
04:36:14  * AlbireoXjoined
05:22:02  * toothrquit (*.net *.split)
05:22:02  * russell_hquit (*.net *.split)
05:22:03  * saghulquit (*.net *.split)
05:22:03  * elijah-mbpquit (*.net *.split)
05:22:04  * tjfontainequit (*.net *.split)
05:22:04  * DrPizzaquit (*.net *.split)
05:22:05  * dshaw_quit (*.net *.split)
05:22:05  * AvianFluquit (*.net *.split)
05:22:05  * jcequit (*.net *.split)
05:22:06  * orlandovftwquit (*.net *.split)
05:22:06  * TooTallNatequit (*.net *.split)
05:22:06  * luvit-irc-botquit (*.net *.split)
05:22:07  * ryah_quit (*.net *.split)
05:22:08  * kohaiquit (*.net *.split)
05:22:09  * chiltsquit (*.net *.split)
05:22:09  * igorziquit (*.net *.split)
05:22:40  * orlandovftwjoined
05:22:40  * kohaijoined
05:22:40  * TooTallNatejoined
05:22:40  * saghuljoined
05:22:40  * elijah-mbpjoined
05:22:40  * luvit-irc-botjoined
05:22:40  * jcejoined
05:22:40  * DrPizzajoined
05:22:40  * tjfontainejoined
05:22:40  * toothrjoined
05:22:40  * russell_hjoined
05:22:40  * ryah_joined
05:22:40  * chiltsjoined
05:23:16  * philipsquit (Changing host)
05:23:16  * philipsjoined
05:23:47  * TooTallNatequit (Quit: Linkinus - http://linkinus.com)
05:28:20  * AvianFlujoined
05:41:26  * loladiropart
05:50:44  * paddybyersjoined
06:49:07  * stephankquit (Quit: *Poof!*)
07:29:18  * rendarjoined
07:32:30  * mjr_joined
08:03:46  * AvianFluquit (Ping timeout: 244 seconds)
08:04:51  * AvianFlujoined
08:32:52  * irajoined
08:47:12  * orlandovftwquit (Ping timeout: 250 seconds)
09:00:10  * mjr_quit (Quit: mjr_)
09:10:28  * toothrquit (*.net *.split)
09:10:28  * russell_hquit (*.net *.split)
09:11:52  * toothrjoined
09:13:16  * russell_hjoined
09:26:18  * iraquit (Ping timeout: 248 seconds)
10:21:27  * abraxasquit (Remote host closed the connection)
10:32:04  * mmalecki[away]quit (Ping timeout: 272 seconds)
10:40:03  * avsejquit (Quit: Quit)
10:40:45  * avsejjoined
11:16:22  * c4milojoined
12:23:33  * loladirojoined
12:38:22  * bnoordhuisjoined
12:54:50  * piscisaureus_joined
12:59:05  <piscisaureus_>bnoordhuis: did you take a look at the benchmark yet?
12:59:12  <bnoordhuis>piscisaureus_: hey
12:59:19  <piscisaureus_>bnoordhuis: I would like to proceed, fix and land
12:59:34  <piscisaureus_>(and "fix" bytesWritten)
12:59:34  <bnoordhuis>you mean the bytes/xxx thing with non-ascii?
12:59:44  <piscisaureus_>yerp
13:00:16  <bnoordhuis>50% yes - i patched http_simple_auto, then got distracted by other things
13:01:16  <piscisaureus_>bnoordhuis: I also found an issue with v8 which gives +10% for non-unicode bytes/10240
13:01:26  <piscisaureus_>bnoordhuis: they landed a fix already in v8 trunk
13:01:43  <piscisaureus_>bnoordhuis: (on windows, that is. not sure about unix)
13:02:16  <bnoordhuis>can you link me to the commit?
13:02:21  <piscisaureus_>https://github.com/v8/v8/commit/29862e81b67a2e778ad63fdf4dadcd07cb3dc1a0
13:02:41  <piscisaureus_>bnoordhuis: the problem was that msvc was not inlining something that really should be inlined
13:03:37  <bnoordhuis>that rascal msvc
13:03:53  <bnoordhuis>i've never seen Get() or CopyChars() in any profiles
13:03:58  <bnoordhuis>so presumably it's not an issue with gcc
13:04:08  <piscisaureus_>then for you it probably already worked :-)
13:04:29  <piscisaureus_>Get() is a function with a big switch statement
13:04:39  <piscisaureus_>msvc has the tendency not to inline those
13:05:03  <piscisaureus_>which is really lame in this case, since the calling functions also read the field that it switched on
13:05:21  <piscisaureus_>(and do `if`s with it0
13:06:24  <bnoordhuis>okay, the difference with non-ascii strings is quite convincing
13:06:39  <bnoordhuis>like a 130% speedup
13:07:13  <piscisaureus_>that works mostly because it avoids flattening the string twice
13:07:24  <bnoordhuis>2.55 times faster
13:07:41  <piscisaureus_>maybe we can add some benchmarks
13:07:47  <piscisaureus_>like unicode/xxx and flat/xxx
13:07:51  <bnoordhuis>benchmarks would be good
13:08:01  <piscisaureus_>(where flat/xxx is a string that is forcefully flattened
13:09:56  <bnoordhuis>bytes/1024 is less brutal but still a ~35% speedup
13:10:08  <bnoordhuis>that v8
13:10:28  <piscisaureus_>bnoordhuis: unfortunately I didn't find the time to write a more efficient flattener for unicode cons strings
13:10:41  <piscisaureus_>bnoordhuis: or rather, I never finished it
13:12:23  <bnoordhuis>7-8% speedup on bytes/64
13:12:25  <bnoordhuis>nice
13:12:42  <piscisaureus_>bytes/64 is mostly dominated by io
13:12:52  <piscisaureus_>and if not, it's dominated by writing headers
13:13:03  <piscisaureus_>it's hard to make a big difference there
13:13:22  <bnoordhuis>yeah, i can see that
13:16:07  <bnoordhuis>i see a 15% speedup on bytes/10240 with mostly ascii output (10240 bytes of ascii + one unicode char)
13:16:38  <piscisaureus_>bnoordhuis: funny, I got almost twice as fast there
13:16:49  <piscisaureus_>bnoordhuis: it may depend on where the unicode char appears in your string
13:17:23  <bnoordhuis>piscisaureus_: sounds likely. if the string is fully unicode, i see that 2.55x difference
13:18:56  <bnoordhuis>piscisaureus_: since you're hacking v8, can you fix this too? /(.*)+{/.test(Array(24).join("x"))
13:19:14  <piscisaureus_>bnoordhuis: what's up with that? Is there a v8 bug for it?
13:19:50  <bnoordhuis>piscisaureus_: don't know. ruben found it
13:20:01  <piscisaureus_>I can try
13:20:06  <bnoordhuis>at first i thought it was a worst-case regex
13:20:25  <bnoordhuis>but spidermonkey handles it well, v8 doesn't
13:20:25  <piscisaureus_>bnoordhuis: is it slow or is it broken?
13:20:30  <bnoordhuis>really, really slow
13:20:34  <piscisaureus_>v8 may not flatten the string
13:20:34  <bnoordhuis>just try it
13:20:49  <piscisaureus_>ouch
13:20:57  <piscisaureus_>does it work for literals too?
13:21:23  <piscisaureus_>yeah, is not flattening dependent
13:21:39  <piscisaureus_>I will bench it
13:21:44  <piscisaureus_>see if I can do something about it
13:23:25  <bnoordhuis>let's see what callgrind has to say about it
13:23:39  <piscisaureus_>I think these regexes are compiled
13:23:49  <piscisaureus_>so I doubt that callgrind will help you in any way
13:23:51  <piscisaureus_>but sure, try
13:25:18  <piscisaureus_>bnoordhuis: I think v8 should be able to easily detect that pattern even
13:25:30  <piscisaureus_>I mean, { does not even appear in the string
13:27:09  <bnoordhuis>1,103,099,802 ???:0x000010b97f287840 [???] <- yep :)
13:27:22  <piscisaureus_>bnoordhuis: how many runs?
13:27:24  <piscisaureus_>one?
13:27:37  <piscisaureus_>yeah that's definitely a bug ;-)
13:27:46  <piscisaureus_>I will investigate
13:28:27  * ericktjoined
13:28:34  <bnoordhuis>is there a way to force v8 to use the regex interpreter instead of the assembler?
13:29:25  <piscisaureus_>yeah there's a compile flag for that
13:29:33  <piscisaureus_>but I know only to do that with scons
13:29:34  <bnoordhuis>V8_INTERPRETED_REGEXP :(
13:29:44  <bnoordhuis>i hate recompiling v8, it's so slow
13:29:46  <piscisaureus_>use --trace-regexp-macro-assembler
13:29:54  <piscisaureus_>and --print-code
13:29:55  <kohai>and has -1 beer
13:30:02  <piscisaureus_>^-- that's what Erik just told me
13:30:27  <bnoordhuis>you're idling in #v8?
13:30:45  <piscisaureus_>bnoordhuis: I have direct lines with Erik
13:30:57  <piscisaureus_>:-p
13:33:58  <piscisaureus_>bnoordhuis: the issue is know. It's known as 'catastrophic backtracking'
13:36:22  <piscisaureus_>bnoordhuis: http://code.google.com/p/v8/issues/detail?id=430
13:36:24  <bnoordhuis>will they have it fixed by 4 pm?
13:36:35  <bnoordhuis>going by the issue id... no
13:37:06  <piscisaureus_>bnoordhuis: Erik says that perl made all regex 2x slower by trying to detect it. But it has been proven that reliable detection of this pattern is undetectable.
13:37:22  <piscisaureus_>bnoordhuis: the regex should be rewrittend as (.+){ and it would be all fine
13:37:54  <bnoordhuis>right, i understand that the regex goes exponential
13:38:11  * felixgejoined
13:38:11  * felixgequit (Changing host)
13:38:11  * felixgejoined
13:42:40  <piscisaureus_>Hmm
13:42:50  <piscisaureus_>compiled regexes seem to confuse the sampling profiler is msvc
13:44:09  <bnoordhuis>piscisaureus_: did erik mention why they can't simply abort after x iterations, like spidermonkey does?
13:44:26  <piscisaureus_>No, I didn't ask
13:44:37  <piscisaureus_>I think it's a correctness issue :-)
13:47:44  <felixge>I'm currently looking into: "throw e; // process.nextTick error, or 'error' event on first tick"
13:47:52  <felixge>it would be really nice if we could show the real call site
13:47:57  <felixge>instead of this one for those errors
13:49:17  <felixge>the real problem is the 'uncaughtException' feature
13:49:27  <felixge>if it wasn't for that we wouldn't need to catch process.nextTick exceptions
13:50:15  <felixge>If we did stop to support this use case, we would get good errors again: https://github.com/joyent/node/commit/57642e23497d5698aa4c5b8a44edff7b265c2283
13:50:53  <felixge>using 'uncaughtException' is really unsafe anyway
13:52:01  <felixge>that being said … I may have an idea that doesn't hurt performance, will try
14:00:32  * ericktquit (Quit: erickt)
14:04:32  <CIA-155>node: Ben Noordhuis master * r78e831a / (src/node.cc src/node_crypto.cc src/node_extensions.cc):
14:04:32  <CIA-155>node: Don't use _snprintf() on Windows, it's not safe.
14:04:32  <CIA-155>node: - http://git.io/-Fm2pA
14:05:40  <bnoordhuis>piscisaureus_: is this code in node_crypto.cc still necessary?
14:05:40  <bnoordhuis> 40 #ifdef _WIN32 | 9 va_start(ap, fmt);
14:05:41  <bnoordhuis> 41 # include <windows.h> | 8 int n = _vsprintf_p(buf, len, fmt, ap);
14:05:41  <bnoordhuis> 42 #else | 7 if (len) buf[len - 1] = '\0';
14:05:41  <bnoordhuis> 43 # include <pthread.h> | 6 va_end(ap);
14:05:44  <bnoordhuis> 44 #endif
14:06:03  <bnoordhuis>ignore the bits from my second tab :)
14:06:37  <tjfontaine>how many vims cna you fit in your terminal
14:07:44  <felixge>I think I got something really neat
14:08:16  <bnoordhuis>tjfontaine: 3 or 4. 28" screens ftw
14:09:42  <tjfontaine>I usually max out at 4, but mostly stay at 3
14:11:29  <felixge>ok, here it is: https://github.com/felixge/node/commit/2d104e1189e8ac9e44afd37cacfb54968687f6a2
14:11:43  <felixge>bnoordhuis / piscisaureus_ : ^--- could I get your opinion on this?
14:12:48  <bnoordhuis>felixge: it'll have to be piscisaureus_, i'm afk for the next two hours
14:13:07  <felixge>bnoordhuis: ok. Doesn't need to be rushed, would be bad to fuck this up : )
14:13:23  <felixge>bnoordhuis: so would also like to get your input when u get back
14:15:10  <piscisaureus_>felixge: the problem with that patch is that if an exception is ignored by an uncaughtException handler then the nextTickQueue is not processed further
14:15:20  <felixge>piscisaureus_: yeah, but that should be fixable
14:15:33  <felixge>I'll simply set the needs_next_tick flag in node.cc on uncaught exceptions
14:15:45  <felixge>worst case: the queue is empty and still gets processed after an uncaught exception
14:16:08  <felixge>need_tick_cb
14:16:47  <piscisaureus_>felixge: yeah. We could also just just do:
14:16:48  <piscisaureus_>if (process.listeners('uncaughtException').length)
14:17:01  <piscisaureus_>oh wait
14:17:05  <piscisaureus_>the problem is in rethrowing
14:17:10  <felixge>y
14:17:13  <piscisaureus_>maybe we can salvage the stack somehow
14:17:15  <felixge>the re-throwing breaks the call site
14:17:47  <piscisaureus_>I agree that this would be a big win
14:17:53  <felixge>weirdly, this patch seems to break 'test/simple/test-child-process-cwd.js' and others right now
14:18:04  <felixge>but I think it's fixable, looking into that now
14:18:16  <felixge>piscisaureus_: yeah, I'll see if I can get this into a shape where I think the edge cases are covered
14:18:30  <felixge>but it seems that at least in theory we can do with catch/re-throw
14:18:32  <felixge>and simplify things
14:18:37  <felixge>* can do without
14:19:58  <piscisaureus_>felixge: I think nextTickIndex should be reset to 0 too
14:20:08  <felixge>fuck yes
14:20:08  <piscisaureus_>felixge: when you do nextTickQueue = []
14:20:10  <felixge>yeah
14:20:21  <felixge>had that in before
14:20:25  <felixge>this fixes the breaking tests
14:22:29  <felixge>piscisaureus_: https://github.com/felixge/node/commit/7718a8fd8fe8bf381cb3316d7d6228ab668a3962
14:23:09  <felixge>one remaining issue: if a process.nextTick creates another process.nextTick it will create a tight infinite loop
14:23:27  <felixge>rather than a "loose" infinite loop with other events still being processed
14:23:33  <piscisaureus_>hmm
14:23:36  <felixge>will write a test for that / see if it can be fixed
14:23:44  <felixge>generally speaking people shouldn't do that
14:23:48  <piscisaureus_>felixge: I think you can store the length of the nextTick queue
14:23:50  <felixge>but we also shouldn't change behavior here if possible
14:24:00  <piscisaureus_>and break out of the loop when nextTickIndex reaches that number
14:24:16  <felixge>piscisaureus_: but then clearing the array and resetting the index to 0 is wrong
14:24:24  <piscisaureus_>felixge: yeah so you would do
14:24:28  <felixge>because one of the nextTick callbacks could have pushed things into the array
14:24:34  <piscisaureus_>nextTickQueue.splice(0, nextTickIndex)
14:24:37  <piscisaureus_>nextTickIndex = 0;
14:24:39  <piscisaureus_>easy
14:25:03  <piscisaureus_>felixge: also, about "need_tick_callback = true" in FatalException
14:25:14  <piscisaureus_>are you sure that the tick spinner is always running when that happens?
14:25:28  <piscisaureus_>otherwise you'd have to call NeedTickCallback() instread
14:25:31  <felixge>piscisaureus_: no
14:25:33  <felixge>good point
14:25:34  <felixge>thanks
14:25:42  <piscisaureus_>or otherwise make sure that the tick spinner is started
14:25:43  <piscisaureus_>if (!uv_is_active((uv_handle_t*) &tick_spinner)) {
14:25:43  <piscisaureus_> uv_idle_start(&tick_spinner, Spin);
14:25:43  <piscisaureus_> uv_ref(uv_default_loop());
14:25:43  <piscisaureus_> }
14:26:00  <piscisaureus_>maybe move that code into a separate function
14:26:29  <piscisaureus_>the tick spinner is rather lame btw
14:26:40  <piscisaureus_>we should be able to do without an uv_idle completely
14:26:58  <piscisaureus_>that would also speed up ndoe
14:27:50  <felixge>piscisaureus_: how should I call that function?
14:27:57  <felixge>or would you want to do that?
14:28:37  <piscisaureus_>felixge: you don't. Just make another function "startTickCallback" or something that does the same as NeedTickCallback
14:28:45  <piscisaureus_>felixge: then change NeedTickCallback to do this
14:29:20  <piscisaureus_>Handle<Value> NeedTickCallback(const Arguments& args) {
14:29:20  <piscisaureus_> startTickSpinner();
14:29:20  <piscisaureus_> return v8::Undefined();
14:29:20  <piscisaureus_>}
14:29:25  * isaacsjoined
14:30:01  <felixge>ok
14:30:24  <piscisaureus_>felixge: btw - I think we can rid of the idle callback entirely
14:30:39  <piscisaureus_>but it can cause subtle behavior changes so I'd want to do that in 0.8
14:31:28  <felixge>ok
14:31:41  <felixge>I'd like to land the call site patch for 0.6 if possible so
14:31:46  <felixge>it really helps debugging node apps
14:31:49  <felixge>and should cause no issues
14:32:11  <piscisaureus_>that would be nice
14:32:12  <felixge>https://github.com/felixge/node/commit/0878cb8ad9a5d567626e3bb3512d5ccc020bbffa
14:32:15  <felixge>piscisaureus_: ^---
14:32:20  <felixge>potential candidate for merging
14:32:23  <piscisaureus_>Although I would want to have isaacs' second opinion
14:32:53  <piscisaureus_>felixge: drop ther handleScope at line 272 :-)
14:33:01  <piscisaureus_>felixge: it's just a time sink
14:33:05  <felixge>piscisaureus_: lol
14:33:41  <piscisaureus_>felixge: s/interfer/interfere/
14:33:44  <felixge>dropped it
14:33:45  <felixge>https://github.com/felixge/node/commit/d1d4cce9f8e3dee0a1341398eaed8502e3232e75
14:33:57  <felixge>ok will fix
14:34:25  <felixge>https://github.com/felixge/node/commit/e73b9e031fd4ef42e4841f29021a786b1a5b04f9
14:34:28  <isaacs>g'morning
14:34:30  <felixge>now with less spelling errors: ^---
14:34:35  <felixge>isaacs: hey
14:34:44  <felixge>isaacs: how are you?
14:35:44  <isaacs>great
14:36:03  <piscisaureus_>felixge: hmm
14:36:17  <piscisaureus_>oh nvm
14:36:50  <felixge>isaacs: check out that patch I just linked when you get a chance
14:37:05  <felixge>it fixes throw call sites for process.nextTick
14:37:06  <piscisaureus_>felixge: yeah that patch looks good
14:37:07  <felixge>and simplifies the code
14:37:13  <isaacs>yeah, reading it now
14:37:22  <isaacs>yeah, this is good.
14:37:39  <isaacs>felixge: so, just to make sure..
14:38:17  <isaacs>felixge: process.on('uncaughtException', function (er) { console.log(er) }); function thrower () { throw 'hi' }; process.nextTick(thrower); process.nextTick(thrower)
14:38:21  <isaacs>felixge: that should log twice, not once
14:38:22  * philipsquit (Excess Flood)
14:38:45  <piscisaureus_>This patch should not interfere with that.
14:38:48  <isaacs>i know
14:38:50  <felixge>yes
14:38:52  <felixge>https://github.com/joyent/node/commit/57642e23497d5698aa4c5b8a44edff7b265c2283
14:38:55  <piscisaureus_>isaacs: but that is actually a good test :-)
14:38:56  <felixge>^--- this is when this behavior introduced
14:39:07  <felixge>I'd like to get rid of uncaughtException entirely as it's really fucked
14:39:11  <isaacs>yeah
14:39:12  <felixge>and people don't understand how fucked it is
14:39:13  <felixge>:)
14:39:17  <isaacs>felixge: domains are the replacement
14:39:19  <isaacs>but domains use it
14:39:21  * philipsjoined
14:39:29  <felixge>I don't know if domains are fucked yet, need to play with them
14:39:30  <felixge>:)
14:39:33  * philipsquit (Changing host)
14:39:33  * philipsjoined
14:39:45  <felixge>but exceptions / error handling is always riddled with subtle problems
14:39:46  <felixge>anyway
14:39:50  <isaacs>and with domains + cluster, you can easily run a server that gracefully exits after sending a 500 response to the request that got the error, without disturbing the rest of the site.
14:39:53  <felixge>let me try your use case
14:40:39  <felixge>isaacs: yeah, my patch passes your one-liner ('hi' is logged twice)
14:40:40  <isaacs>in fact, with domains and the cluster-master module, you can find an error in development, fix it, and press cmd-R to refresh until all the busted workers are dead and restarted :)
14:40:43  <isaacs>felixge: great.
14:40:49  <isaacs>felixge: i think that's roughly what the test does, too
14:41:10  <isaacs>felixge: there'll be a few message tests that fail, make sure you update those as well.
14:41:25  <isaacs>since this changes the reported stack of the error
14:41:32  <felixge>yeah
14:41:41  <felixge>running the full test suite before/after now
14:41:45  <isaacs>kewl
14:41:49  <felixge>to make sure nothing slips through
14:41:52  <isaacs>make test-all should catch them.
14:41:56  <felixge>but otherwise I'm hoping this could be a 0.6 candidate ?
14:41:58  <isaacs>yes.
14:42:17  <felixge>one thing so: It won't cleanly merge into 0.8 because of the domain code, but it should be easy to rebase on 0.8 as well
14:42:29  <felixge>not sure how you manage that, but let me know if I can help
14:42:45  <isaacs>i'll merge it in from 0.6
14:42:57  <isaacs>as long as there's no other code changes required, though, go ahead and land it.
14:43:14  <isaacs>it's pretty simple and clearly winful.
14:43:53  <felixge>ok, running double checks on tests so
14:44:02  <felixge>will ping you when rdy with final patch for a last look
14:46:27  <piscisaureus_>felixge: it would be nice to land isaac's test as a test
14:46:36  <isaacs>piscisaureus_: the test that's in there is basically that
14:46:40  <piscisaureus_>felixge: maybe also one for process.nextTick not busylooping
14:46:46  <isaacs>ryah_ and i think alike, apparently
14:47:25  <felixge>piscisaureus_: I'm not quite sure how to test for non-busylooping, maybe with a timer?
14:47:31  <piscisaureus_>felixge: that would be something like:
14:47:32  <piscisaureus_>setTimeout(process.exit, 10);
14:47:32  <piscisaureus_>function onNextTick() { process.nextTick(onNextTick));
14:47:32  <piscisaureus_>onNextTick();
14:48:08  <isaacs>actually, it's a bit more thorough than that: https://github.com/joyent/node/blob/v0.6/test/simple/test-next-tick-errors.js
14:48:29  <piscisaureus_>felixge: actually, that test is also there I think
14:48:30  <piscisaureus_>test-next-tick-starvation.js
14:48:34  <isaacs>piscisaureus_: https://github.com/joyent/node/blob/v0.6/test/simple/test-next-tick-starvation.js
14:48:35  <isaacs>yeah
14:48:42  <isaacs>the tests we have are sufficient, i think
14:48:45  <felixge>isaacs: that patch was done by ben: https://github.com/joyent/node/commit/57642e23497d5698aa4c5b8a44edff7b265c2283
14:48:47  <isaacs>just the message tests might have to change.
14:48:56  <isaacs>oh, haha
14:49:02  <isaacs>bentomas and i think alike, then ;)
14:49:06  <felixge>I tracked down the history to see when the try..catch was introduced
14:49:07  <felixge>:)
14:49:34  <felixge>and was really upset when I discovered it was just there to fix the complexity of uncaughtException :)
14:50:07  <piscisaureus_>felixge: but I really like that you're fixing this. It is so important and the test seems so simple.
14:50:14  <piscisaureus_>s/test/fix/
14:50:51  <felixge>isaacs: the tests you linked seem to cover the scenarios we discussed
14:51:02  <isaacs>felixge: well, it's really just there to fix the fact that throwing gets you completely out of the territory
14:51:03  <felixge>not sure if there is value in adding more starvation / uncaughtException tests
14:51:07  <isaacs>nah
14:51:20  <isaacs>more tests isn't always better.
14:51:21  <felixge>in that case I'll just fix the message tests
14:51:28  <felixge>those are the only ones broken
14:51:28  <isaacs>kewl
14:51:32  <isaacs>thanks felixge :)
14:55:55  * TheJHjoined
14:56:43  <felixge>https://github.com/felixge/node/commit/77def43c283dbc215b357560b5256e7c44c7708d
14:56:45  <felixge>^--- new version
14:57:00  <felixge>turns out we have another stupid re-throw thingie in module.js
14:57:04  <felixge>that obfuscates errors
14:57:05  <felixge>*sigh*
14:57:14  <felixge>lets see if we can make that go away as well
14:57:15  <felixge>:0
14:57:16  <felixge>:)
14:59:22  <felixge>seems like I'm to blame for all the bad error reporting in node: 66601f13d9f841fe4e644a0b106ea3106054f46a
14:59:23  <felixge>:'(
15:00:45  <piscisaureus_>felixge: maybe you can salvage the stack.
15:01:27  <felixge>piscisaureus_: I'm hoping this try…catch isn't even needed and we can change the order on the cache population
15:01:41  <felixge>but I have a feeling it runs into conflict with circular require()
15:01:52  <piscisaureus_>felixge: yeah I think that will break stuff
15:01:58  <felixge>(which IMO we shouldn't allow, it almost always doesn't work the way you want it to)
15:02:24  <felixge>yeah
15:02:28  <felixge>breaks some module loading tests
15:02:29  <piscisaureus_>felixge: "not allowing" is not that easy, because we would have to scan the require stack
15:02:45  <felixge>piscisaureus_: we may need to salvage the stack here
15:02:49  <felixge>but I'm not aware of how to do that
15:02:53  <felixge>at least not without v8 magic
15:02:53  <piscisaureus_>me neither
15:03:02  <felixge>so hopefully I can find something better
15:03:35  <piscisaureus_>felixge: I think an Error object captures a stack trace always. So maybe if we throw from c++ the stack will not be changed.
15:03:53  <piscisaureus_>felixge: we could have something like process._rethrow(err)
15:04:06  <felixge>well, but the capture stack trace is where the Error object was created
15:04:09  <felixge>not where it was thrown
15:04:23  <felixge>(I could be wrong)
15:04:35  <piscisaureus_>yeah
15:04:54  <piscisaureus_>felixge: so, why does the original stack not show up, then?
15:05:01  <piscisaureus_>when we rethrow
15:06:32  <piscisaureus_>felixge: btw - this also breaks in bad ways when caching a module is combined with circular deps
15:06:48  <felixge>piscisaureus_: what breaks?
15:06:52  <felixge>changing the order?
15:06:56  <felixge>yeah, that's not gonna work
15:07:00  <piscisaureus_>no
15:07:07  <piscisaureus_>felixge: what is going on now
15:07:25  <felixge>piscisaureus_: got a test case?
15:07:34  <felixge>circular deps tangle my brainz
15:07:38  <felixge>:)
15:08:22  <piscisaureus_>felixge: consider this thing:
15:08:22  <piscisaureus_>// a.js:
15:08:22  <piscisaureus_>var B = require('b');
15:08:22  <piscisaureus_>throw "foo";
15:08:22  <piscisaureus_>// b.js
15:08:23  <piscisaureus_>var A = require('b');
15:08:23  <piscisaureus_>// master.js
15:08:24  <piscisaureus_>require('a');
15:08:37  <piscisaureus_>felixge: b.js is still cached
15:08:52  <piscisaureus_>felixge: but it is using the broken & throwing copy of a
15:08:55  <felixge>you mean './'
15:09:02  <felixge>in all your requires?
15:09:23  <piscisaureus_>felixge: yeah so whenever you require('b') it will use the broken copy of a
15:09:47  <piscisaureus_>er well there's some bugs in my code
15:09:55  <piscisaureus_>let me create a real test case
15:10:03  <felixge>piscisaureus_: that'd be great
15:10:15  <piscisaureus_>felixge: I think it is unfixable though
15:10:37  <felixge>piscisaureus_: I thought that about process.nextTick as well for a long time
15:11:12  <felixge>piscisaureus_: I'd like to at least see if I can get somewhere with it
15:12:39  * loladiroquit (Quit: loladiro)
15:17:31  <piscisaureus_>felixge: https://github.com/piscisaureus/forfelix
15:17:49  <piscisaureus_>felixge: if it is correct, you `node main.js` should output "ok" twice
15:18:00  <piscisaureus_>felixge: good luck with that. I think this is unfixable.
15:18:31  <felixge>piscisaureus_: and this is with the current module system without mods, right?
15:18:47  <piscisaureus_>felixge: yep
15:19:27  <felixge>ok
15:19:34  <felixge>I like unfixable
15:19:37  <felixge>will have a look
15:19:47  <piscisaureus_>isaacs: you too - try that: https://github.com/piscisaureus/forfelix
15:22:35  <felixge>piscisaureus_: brain hurts
15:22:36  <felixge>:)
15:23:25  <felixge>I would actually expect b.getStateOfA() to report 'broken'
15:24:04  <felixge>but: console.log(a.getState()); should report 'ok'
15:24:07  <felixge>in your example
15:24:17  <piscisaureus_>felixge: well it does report ok, right?
15:24:17  <felixge>at least that would seem like the correct/best behavior to me
15:24:34  <felixge>oh shit
15:24:41  <felixge>hah, was running wrong node build
15:24:41  <felixge>yes
15:24:43  <piscisaureus_>felixge: but how would b.js have know that a.js is broken
15:25:03  <piscisaureus_>felixge: require('a.js') succeeded without throwing for it
15:25:04  <felixge>because it was broken at the time it required it
15:25:45  <piscisaureus_>felixge: well, normally that could never happen. require() would throw, and the module would not be cached
15:25:57  <piscisaureus_>felixge: but in the presence of circular deps, that doesn't work
15:26:06  * dshaw_joined
15:26:39  <piscisaureus_>felixge: because a.js *is* cached for a while and is then removed from the cache again when it throws
15:26:48  <felixge>yes
15:26:59  <felixge>this whole caching business is very fucked up :)
15:27:10  <piscisaureus_>yup
15:27:31  <felixge>that's why I'd rather have circular deps report call stack size exceeded
15:27:38  <felixge>and say fuck it to those who think they need it
15:27:39  <felixge>:)
15:27:42  <piscisaureus_>what we maybe could do is expunge b.js from the cache too
15:27:48  <piscisaureus_>somehow
15:27:53  <piscisaureus_>when a throws
15:28:01  <felixge>piscisaureus_: I had a patch for cascading caches a long time ago
15:28:07  <felixge>where each module had it's own cache
15:28:12  <felixge>and things could branch off
15:28:21  <felixge>IMO that would have made things like this simpler
15:28:34  <piscisaureus_>you'd have to talk to isaacs about that
15:28:47  <felixge>piscisaureus_: actually I sworn to myself never to talk about it again : p
15:28:57  <felixge>as it was a similar time sink as my work on promises
15:29:13  <felixge>30-40 hours down the train without much to show for it :p
15:29:17  <piscisaureus_>:-)
15:29:28  <tjfontaine>last I heard isaacs doesn't want to touch the module stuff anymore :)
15:29:34  <piscisaureus_>Hows does tc39 define caching for their ES.next module system?
15:29:47  <pfox__>Morning. /w 2
15:29:52  <pfox__>heh. whoops.
15:29:58  <felixge>so for now … all I'm interested in is to see if I can fix stack trace output without changing existing behavior
15:30:24  <piscisaureus_>right
15:30:30  <piscisaureus_>felixge: well you have a test here :-0
15:30:47  <piscisaureus_>Imma finish up the string speed patch
15:30:58  <felixge>piscisaureus_: YES!
15:31:01  <felixge>please do that
15:31:02  <felixge>:)
15:31:09  <piscisaureus_>felixge: oh - not that one ...
15:31:19  <piscisaureus_>felixge: this one speeds up string writes to a socket
15:31:25  <felixge>that I like too!
15:31:25  <felixge>:)
15:31:51  <felixge>right now there is no intelligent batching when doing lots of small write()'s
15:32:18  <felixge>I helped the VoltDB guys get their insert / sec performance from 7k / sec to ~12k / sec doing write batching in user land
15:32:27  <felixge>(assuming this is kind of what you're going to do as well)
15:32:28  <felixge>oh wait
15:32:34  <felixge>you mean copying data out of a v8 string
15:32:38  <felixge>the old problem
15:32:38  <felixge>nvm
15:32:39  <felixge>:)
15:32:52  <piscisaureus_>felixge: well... let's just say it's something :-)
15:33:19  <piscisaureus_>felixge: the intelligent batching we could do too... But only for strings, and not for buffers
15:36:53  <isaacs>piscisaureus_: can you explain this test? i'm kind of confused.
15:36:54  <isaacs>what's the issue?
15:37:24  <piscisaureus_>isaacs: so modules that throw are not supposed to be cached
15:37:34  <piscisaureus_>isaacs: but a.js does get cached
15:37:36  <isaacs>you'd expect the require('./a.js') from b.js to re-load it?
15:37:43  <isaacs>who says that modules that throw are not supposed to be cached?
15:37:50  <piscisaureus_>isaacs: module.js says that
15:37:55  <isaacs>hrm...
15:38:00  <isaacs>where?
15:38:09  <isaacs>cuz i think it module.js says that a.js should be cached ;P
15:38:14  <isaacs>since it's getting cached.
15:38:15  <piscisaureus_>umm felix came up with that
15:38:23  <piscisaureus_>isaacs: have to run now. bb in 20 minutes.
15:38:26  <piscisaureus_>sorry
15:38:57  <isaacs>k
15:38:59  <isaacs> Module._cache[filename] = module;
15:38:59  <isaacs> try {
15:38:59  <isaacs> module.load(filename);
15:39:01  <isaacs> } catch (err) {
15:39:03  <isaacs> delete Module._cache[filename];
15:39:05  <isaacs> throw err;
15:39:07  <isaacs> }
15:39:09  <isaacs>this bit?
15:41:32  <isaacs>ohh.... i see.
15:41:48  <isaacs>so, modules that throw ARE removed from the cache. however, that doesn't mean that all their CHILDREN are removed from teh cache.
15:42:09  <isaacs>or that their children won't already have a reference to the module contents that were in the cache in the first place.
15:43:06  <isaacs>after first require, cache= [ '/Users/isaacs/dev/js/forfelix/main.js',
15:43:06  <isaacs> '/Users/isaacs/dev/js/forfelix/b.js' ]
15:44:37  <felixge>isaacs: ^--- yes, afaik that's what is being discussed (slightly confused myself with bert's brain twister)
15:44:43  <felixge>unfortunately headed out for food now
15:44:46  <isaacs>ok
15:44:50  <felixge>will be back later today
15:44:55  <isaacs>well, i have a small fix that seems correct.
15:45:10  <isaacs>this does seem like a bug, but it's enough of an edge case that i think we can justify not fixing it, maybe.
15:45:37  <felixge>isaacs: looking forward to discuss in a bit. I was mostly interested in getting rid of the re-throw to stop obfuscating exceptions that are thrown during module loading
15:45:48  <felixge>so if your patch helps with that as well, that'd be insanely great
15:45:51  <felixge>ok ttyl
15:45:54  <isaacs>felixge: no, it makes it worse :)
15:45:59  <isaacs>enjoy your food
15:46:38  * stephankjoined
15:51:02  * c4miloquit (Read error: Connection reset by peer)
15:51:42  * dapjoined
15:55:41  * felixgequit (Quit: felixge)
15:56:46  * c4milojoined
16:00:52  * stephankquit (Read error: No route to host)
16:01:34  <bnoordhuis>back
16:03:34  <bnoordhuis>oh, felixge is gone again
16:05:17  * mmaleckijoined
16:19:50  * orlandovftwjoined
16:22:55  <isaacs>i've got a fix that i think makes this work like we all want.
16:23:06  <isaacs>unfortunately, it changes module.js /o\
16:23:12  <isaacs>but i don't think there's a way around that
16:24:35  <piscisaureus_>bnoordhuis: does gcc support the c++ keyword "decltype" ?
16:24:40  <piscisaureus_>or __typeof__ / typeof ?
16:25:08  <bnoordhuis>piscisaureus_: gcc has a typeof operator
16:25:27  <bnoordhuis>decltype is a c++11 thing btw
16:25:35  <piscisaureus_>bnoordhuis: I know...
16:26:43  <bnoordhuis>piscisaureus_: so what are you trying to do?
16:27:16  <piscisaureus_>bnoordhuis: check if buf.len doesn't overflow
16:28:23  <piscisaureus_>bnoordhuis: so basically, assert((typeof(buf.len)) size == size)
16:28:51  <piscisaureus_>bnoordhuis: but I will do the bit twiddling instead... that's more supported
16:32:54  <isaacs>piscisaureus_: https://github.com/isaacs/node/commit/790fe6253f529d32c20c5d29a855a86798356d35
16:35:03  <piscisaureus_>isaacs: so now what happens if the user does
16:35:04  <piscisaureus_>try {
16:35:04  <piscisaureus_> require('a');
16:35:04  <piscisaureus_>} catch(e) {
16:35:04  <piscisaureus_> require('a');
16:35:04  <piscisaureus_>}
16:35:21  <piscisaureus_>isaacs: does the second require make another attempt or does it return the broken module
16:35:37  <piscisaureus_>isaacs: (these cases are so edge-y that they are hardly worth thinking of)
16:36:00  <isaacs>piscisaureus_: nono, they're definitely worth thinking of.
16:36:02  <isaacs>it tries again
16:36:15  <piscisaureus_>isaacs: are you sure?
16:36:16  <isaacs>which is what it would have done last time, as well, except that the *child* caused another cached copy to be created.
16:36:23  <piscisaureus_>isaacs: it depends on when the finally block runs right?
16:36:34  <isaacs>piscisaureus_: the finally block runs after everything.
16:36:41  <isaacs>piscisaureus_: but before teh return
16:36:46  <piscisaureus_>ah, right, ok
16:36:51  <piscisaureus_>then it works
16:37:01  * c4miloquit (Ping timeout: 252 seconds)
16:37:04  <piscisaureus_>I never realized that you could do this stuff with try..finally
16:37:05  <isaacs>the key is that the line after the load in the try block
16:37:10  <isaacs>gets skipped over
16:37:15  <isaacs>piscisaureus_: wanna see a *really* awesome trick?
16:37:17  <piscisaureus_>actually it's pretty powerful
16:37:24  <isaacs>and by awesome, i mean, "don't ever do this ever"?
16:37:28  <piscisaureus_>sure
16:38:17  <isaacs>> var y; function x () { y = 100; try { return y } finally { y = 0 } }; x()
16:38:17  <isaacs>100
16:38:17  <isaacs>> y
16:38:18  <isaacs>0
16:38:45  <piscisaureus_>heh
16:38:46  <piscisaureus_>orly
16:38:56  <piscisaureus_>lol
16:39:02  <piscisaureus_>is that in the spec?
16:39:03  <isaacs>function x () { y = {foo:'bar'}; try { return y } finally { delete y.foo } }; x().foo
16:39:05  <isaacs>oh, yeah
16:39:18  <isaacs>so, pop quiz: does this eval to 'bar', or undefined?
16:39:45  <piscisaureus_>undefined
16:39:49  <isaacs>piscisaureus_++
16:39:50  <kohai>piscisaureus_ has 10 beers
16:39:57  <piscisaureus_>that makes sense
16:40:17  <isaacs>the semantics of return are that it marks the object as the return value, then evaluates the finally block, then resolves to the eventual return value
16:40:18  <piscisaureus_>it should not push the (.foo) resolution into the function obdy
16:40:42  <isaacs>however, it's not a matter of moving the finally block above the return statement
16:40:52  <isaacs>simple values are not changed
16:41:06  <piscisaureus_>isaacs: because they are primitives
16:41:09  <isaacs>right
16:41:13  <piscisaureus_>isaacs: I wonder what happens with ValueObjects
16:41:56  <isaacs>> var y; function x () { y = new Number(100); try { return y } finally { y.valueOf = function () { return 0 } } }; +x()
16:41:56  <isaacs>0
16:42:12  <isaacs>assigning the ref to a new thing won't chagne it
16:42:29  <isaacs>> var y; function x () { y = new Number(100); try { return y } finally { y = new Number(0) } }; +x()
16:42:29  <isaacs>100
16:42:40  <isaacs>the return statement captures a reference to a specific object or value.
16:43:21  <isaacs>uglify abuses this trick like crazy
16:43:29  <piscisaureus_>I have the feeling that we could find a spec violation here if we look hard enough
16:43:35  <isaacs>try { return node } finally { parse(node.children) }
16:43:51  <isaacs>piscisaureus_: i doubt it
16:44:23  <piscisaureus_>isaacs: something with the arguments is always a win
16:49:14  * theColejoined
16:53:12  * igorzijoined
16:53:21  * `3rdEdenjoined
16:58:20  <isaacs>ircretary: tell felixge https://github.com/joyent/node/issues/3235
16:58:20  <ircretary>isaacs: I'll be sure to tell felixge
17:00:39  * theColequit (Quit: theCole)
17:03:45  * isaacsquit (Remote host closed the connection)
17:11:05  * philipsquit (Excess Flood)
17:12:02  * orlandovftwquit (Ping timeout: 265 seconds)
17:13:50  * philipsjoined
17:29:30  * TooTallNatejoined
17:33:15  * CoverSlidejoined
17:36:49  * ericktjoined
17:43:24  * avalanche123joined
17:45:58  * dshaw_quit (Quit: Leaving.)
17:57:33  * orlandovftwjoined
18:05:36  * ljacksonquit (Read error: Operation timed out)
18:07:45  * ljacksonjoined
18:09:36  * brsonjoined
18:10:21  * dshaw_joined
18:11:18  * c4milojoined
18:13:38  * isaacsjoined
18:22:08  <piscisaureus_>bnoordhuis: yt?
18:31:16  * mjr_joined
18:32:40  * indexzerojoined
18:41:40  * mikealjoined
18:59:30  * mikealquit (Quit: Leaving.)
19:01:47  <igorzi>piscisaureus_: hey.. yt?
19:01:51  * brsonquit (Ping timeout: 255 seconds)
19:02:03  <piscisaureus_>igorzi: yep. sup?
19:02:55  <igorzi>piscisaureus_: for junction points.. your original patch only worked if the source path is absolute.. i'm making it work with relative path as well (prepending cwd).. just wanted to confirm with you
19:03:07  <piscisaureus_>igorzi: oh, that's okay
19:03:29  <igorzi>piscisaureus_: k.. i'll have a patch for you to review in a couple of hours
19:03:30  <piscisaureus_>igorzi: I think junction points can just be relative if you don't prepend \\.\
19:03:47  <piscisaureus_>igorzi: but if they're absolute this thing has to be prepended
19:04:09  <piscisaureus_>igorzi: I don't think we should be making junctions absolute ourselves since that breaks moving them
19:04:35  <igorzi>piscisaureus_: i see
19:04:55  <igorzi>piscisaureus_: ok, i'll try that
19:05:28  <piscisaureus_>igorzi: also, we shouldn't prepend \\?\ if it already has that :-)
19:05:37  <piscisaureus_>igorzi: I think my version doesn't account for that
19:05:45  <igorzi>piscisaureus_: yep
19:05:58  <piscisaureus_>igorzi: kewl. I'll leave it to you from here.
19:06:15  <piscisaureus_>bnoordhuis: still watching tv?
19:11:12  * theColejoined
19:12:46  * indexzeroquit (Quit: indexzero)
19:15:08  * theColequit (Client Quit)
19:17:17  * theColejoined
19:28:16  * `3rdEdenquit (Quit: Leaving...)
19:28:53  * theColequit (Quit: theCole)
19:39:41  * felixgejoined
19:39:41  * felixgequit (Changing host)
19:39:41  * felixgejoined
19:42:56  * mikealjoined
19:44:38  * indexzerojoined
19:52:34  * TheJHquit (Ping timeout: 272 seconds)
19:53:37  <felixge>isaacs: finally !!!
19:53:42  <felixge>never had a good use for this
19:54:11  <felixge>https://github.com/isaacs/node/commit/790fe6253f529d32c20c5d29a855a86798356d35
19:54:13  <felixge>^--- <3
19:57:17  <felixge>isaacs: I dislike the added complexity
19:57:20  <felixge>but love the end result
19:57:27  <felixge>so +1 on merging
19:57:51  <felixge>also https://github.com/felixge/node/commit/77def43c283dbc215b357560b5256e7c44c7708d (my commit) is done from my PoV
19:58:05  <felixge>so those two would go together really well :)
19:58:45  <piscisaureus_>felixge's commit lgtm
19:59:19  <felixge>piscisaureus_: looks like isaacs patch also fixes your "unfixable" problem? :)
19:59:33  <piscisaureus_>felixge: I am sure there is an edge case it doesn't cover :-)
19:59:54  <piscisaureus_>but it's an improvement so _1
19:59:56  <piscisaureus_>+1
20:00:01  <felixge>I'm actually not sure if I want to fix your problem and do the throw thing in one patch
20:00:10  <felixge>I think the 'finally' trick itself fixes the call site issue
20:00:16  <felixge>and would be much simpler / less risky patch
20:00:37  <felixge>unless I'm missing something
20:00:51  <felixge>but I feel like isaacs patch seems more 0.8ish
20:00:54  <felixge>than 0.6
20:00:59  <felixge>but a small part of it could go into 0.6
20:00:59  <piscisaureus_>maybe the patch can be broken up
20:01:02  <felixge>yeah
20:01:04  <felixge>let me try that
20:01:08  <piscisaureus_>so we can port the try...finally thing to 0.6
20:02:59  <felixge>ok, doesn't seem to be quite that easy
20:03:21  <felixge>https://github.com/felixge/node/commit/9f146953bc6dd34c2f6c7f78842b97fb7954b7a2
20:03:27  <felixge>^--- fails the module loading test for me
20:03:34  <felixge>AssertionError: false == true
20:03:35  <felixge> at Object.<anonymous> (/Users/Felix/code/node/test/simple/test-module-loading.js:80:8)
20:03:48  <felixge>oh wait I know why
20:04:00  <felixge>I have to somehow know if finally was triggered by an exception or not
20:04:38  <piscisaureus_>hmm
20:05:01  <piscisaureus_>how does isaac know?
20:05:24  <felixge>not sure
20:05:26  <felixge>but this is how I do:
20:05:34  <felixge>https://github.com/felixge/node/commit/d2e59d85e867a352806190d72ee8ec447a4e2eff
20:05:40  <felixge>piscisaureus_: ^----
20:05:59  <piscisaureus_>that works
20:06:01  <piscisaureus_>:-)
20:06:03  <felixge>:)
20:06:05  <felixge>yeah, a bit hacky
20:06:13  <felixge>but I'd feel much more comfortable with this for 0.6
20:06:17  <felixge>in combination with my other patch
20:06:34  <felixge>as it purely addresses stack output
20:06:39  <felixge>but has no impact on behavior
20:08:06  <felixge>ok, will give this a better commit message and put it in a pull
20:08:21  <felixge>will be headed offline after that, but hopefully isaac can comment
20:08:22  * brsonjoined
20:08:37  <piscisaureus_>yeah
20:08:46  <piscisaureus_>Mention him in the pr
20:08:51  <piscisaureus_>or let's just get it landed :-p
20:09:07  <piscisaureus_>actually isaac is into that stuff so he should probably take a look
20:13:29  <mjr_>isaacs: I think your recent http parser free change might not be working right. We get a lot of these after upgrading:
20:13:29  <mjr_>https://gist.github.com/2638935
20:13:55  <piscisaureus_>mjr_: I think it has been addresses
20:13:59  <piscisaureus_>*addressed
20:14:34  <mjr_>piscisaureus_: post 0.6.17 you mean?
20:14:47  <piscisaureus_>mjr_: hmm, I heard they had to fix some fallout bugs
20:14:55  <piscisaureus_>mjr_: but this particular one I don't know
20:15:10  <mjr_>The previous parser free fix I had in place didn't seem to cause these.
20:16:13  * indexzeroquit (Quit: indexzero)
20:19:40  <felixge>https://github.com/joyent/node/pull/3238
20:19:53  <felixge>isaacs / piscisaureus_ : ^-----
20:20:06  * mralephjoined
20:20:10  <piscisaureus_>yup, seen
20:20:23  <felixge>I'm headed offline now, so if there needs to be more discussion, I'll be back tomorrow. Otherwise feel free to merge/tweak
20:20:46  <piscisaureus_>alright. Felixge: sleep well
20:20:57  <piscisaureus_>I am also about to head out. bnoordhuisL: still not there?
20:21:10  <piscisaureus_>*bnoordhuis
20:22:02  <isaacs>piscisaureus_: felixge: hey
20:22:04  <isaacs>oh you
20:22:06  <felixge>isaacs: hey
20:22:08  <isaacs>you're heading offline
20:22:16  <felixge>I can hang here for a few more minutes
20:22:17  <isaacs>real quick: yeah, my module.js thing cannot be done in 0.6
20:22:21  <isaacs>it subtly changes semantics.
20:22:25  <felixge>was just heading off since I thought you weren't coming back right away
20:22:41  <felixge>isaacs: yeah
20:22:42  <isaacs>it's not allowed change behavior in 0.6, even if it's right.
20:22:46  <felixge>but that 'finally' thing was genius
20:22:52  <felixge>I never considered finally for this
20:22:58  <isaacs>yeah, i'm quite proud of it :)
20:23:00  <felixge>:)
20:23:23  <isaacs>it's like actually a completely valid use case for exactly what try/finally is *supposed* to be used for: cleaning up after an error, without trapping the error itself
20:23:31  <felixge>yes
20:23:39  <felixge>never seen it used for that before so
20:23:53  <felixge>which is why I always dismissed it as useless
20:23:54  <felixge>:)
20:24:20  <felixge>isaacs: so how do you feel about my simplified patch?
20:24:31  <felixge>isaacs: https://github.com/felixge/node/commit/13afa9fac1b1ddbc79dce8c42d638047b0ba6d60
20:25:25  <isaacs>felixge: i'm ok on the approach. need to study more carefully before i lgtm it
20:26:29  <felixge>isaacs: sure
20:28:15  <felixge>isaacs: I can stick around for another ~5min, otherwise we can re-connect tomorrow if you want more discussion
20:30:29  * loladirojoined
20:30:49  <isaacs>felixge: i've got some other stuff to do right now, let's touch base tomorrow.
20:30:55  <isaacs>have a good evening :)
20:30:56  <felixge>isaacs: SGTM
20:30:56  <isaacs>thanks
20:30:58  <felixge>you too
20:31:17  <felixge>thanks for the review on this stuff and coming up with using 'finally ' :)
20:31:23  <felixge>very happy with this if we can land it
20:31:41  <felixge>piscisaureus_: also huge thanks for your input on the nextTickQueue handling
20:31:46  <piscisaureus_>felixge: np
20:31:57  <piscisaureus_>felixge: this is a good think to do :-)
20:32:47  <felixge>yeah, it annoyed the fuck out of me for ages :)
20:32:50  <felixge>alright, good night
20:33:19  <piscisaureus_>felixge: you too
20:33:47  * felixgequit (Quit: http://www.debuggable.com/)
20:40:55  <isaacs>i think maybe my patch on 0.8 is not so great. i'll try a re-merge once i review felixge's more.
20:52:14  * igorziquit (Quit: Page closed)
21:01:40  * indexzerojoined
21:11:21  <mjr_>isaacs: did you see my earlier note about the HTTP parser exception?
21:12:31  <isaacs>mjr_: yeah, that seems impossible.
21:12:35  <isaacs>mjr_: i think your servers are lying to you.
21:12:51  <mjr_>Oh, maybe I should get them drunk and see if they tell me the truth.
21:12:56  <isaacs>mjr_: could help!
21:13:03  <mjr_>servers++
21:13:03  <kohai>servers has 1 beer
21:14:50  <mjr_>isaacs: so presumably this is because onIncoming is set to null in freeParser
21:15:34  <isaacs>mjr_: yes, of course.
21:15:53  <mjr_>But it does seem that the timing of whatever this bullshit is has changed.
21:15:55  <isaacs>mjr_: but if it's getting called anywhere between freeParser and being re-set-up for a new request, then there's big problems.
21:16:25  <mjr_>On my previous fix for this, I did not see these exceptions.
21:16:28  <isaacs>mjr_: onIncoming gets set when the parser is assigned to a socket, and removed when the parser is put back to the pool.
21:16:38  <isaacs>mjr_: you also saw memory leaks with your previous fix ;)
21:16:48  <mjr_>Tradeoffs.
21:17:20  <mjr_>So would it help to slather some logging in there when this happens?
21:18:51  <piscisaureus_>the http connection is somehow cleaned up, but data still arrives at the socket
21:19:10  <piscisaureus_>I think the http parser is not properly disconnected from the socket object
21:20:19  <piscisaureus_>it would probably help to do
21:20:20  <piscisaureus_>socket.removeAllListeners('data');
21:20:24  <isaacs>mjr_: what's like 1176 of lib/http.js
21:20:32  <piscisaureus_>whenever onIncoming is set to nul
21:20:51  <mjr_> var ret = parser.execute(d, start, end - start);
21:21:25  <mjr_>net.js:374 is: if (self.ondata) self.ondata(buffer, offset, end);
21:22:29  <isaacs>mjr_: so, there's this in http.js:
21:22:31  <isaacs> parser.onIncoming = null;
21:22:31  <isaacs> if (parser.socket) {
21:22:31  <isaacs> parser.socket.onend = null;
21:22:33  <isaacs> parser.socket.ondata = null;
21:22:34  <isaacs> }
21:22:42  <isaacs>so how would ondata get called when onIncoming is null??
21:22:51  <isaacs>i have to run to a meetin
21:22:52  <isaacs>g
21:23:30  <mjr_>yeah, crazy
21:24:10  <mjr_>perhaps some silly thing like parser.socket isn't truthy, or even the incoming parser param isn't truthy?
21:24:20  <mjr_>That would be dumb.
21:25:03  <piscisaureus_>or maybe "parser.socket" got patched somehow
21:25:19  <piscisaureus_>but data is still flowing off an old socket
21:41:15  * indexzeroquit (Ping timeout: 265 seconds)
21:41:42  * mikealquit (Quit: Leaving.)
21:45:07  * rendarquit
21:48:58  * mikealjoined
21:56:31  * igorzijoined
21:57:28  <igorzi>piscisaureus_: hey.. are you sure that you had junctions working with relative paths?
21:58:38  <piscisaureus_>igorzi: lemme try
21:58:52  <igorzi>piscisaureus_: doesn't work for me
21:59:37  <piscisaureus_>igorzi: they can be relative for sure
21:59:50  <piscisaureus_>igorzi: try this
22:00:27  <piscisaureus_>mkdir foo\bar
22:00:27  <piscisaureus_>cd foo
22:00:27  <piscisaureus_>mklink /j bar2 bar
22:00:27  <piscisaureus_>cd ..
22:00:30  <piscisaureus_>ren foo foo2
22:00:35  <piscisaureus_>dir foo2/bar2
22:00:47  <piscisaureus_>oh wait
22:00:48  <piscisaureus_>heh
22:00:56  <piscisaureus_>how lame
22:01:01  <piscisaureus_>well, that settles it, then :-)
22:01:09  <igorzi>:)
22:03:00  <piscisaureus_>igorzi: sorry
22:03:05  <piscisaureus_>igorzi: btw - are you going to nodeconf?
22:03:11  <igorzi>np
22:03:12  <igorzi>piscisaureus_: so the question is what do we do if symlink is called with relative path.. to we just make it into absolute with cwd? (this is probably what mklink does)
22:04:22  <igorzi>piscisaureus_: probably not unfortunately.. i've got relatives visiting from outside US exactly at the time of nodeconf
22:04:25  <igorzi>piscisaureus_: are you?
22:04:49  <piscisaureus_>igorzi: re absolutize - I think so. But I think we shouldn't make junctions the default, then.
22:04:57  <piscisaureus_>igorzi: I am. I was hoping to meet you there.
22:05:05  <piscisaureus_>igorzi: no luck so it seems
22:05:44  <igorzi>piscisaureus_: i might come down for 1 day (it's about 3 hour drive)
22:07:24  <piscisaureus_>igorzi: ah, right. I can also try to be there a little earlier (I might be there for oscon about a week earlier, so maybe I'll just stay there)
22:15:07  * paddybyersquit (Quit: paddybyers)
22:15:51  * paddybyersjoined
22:21:42  <mjr_>piscisaureus_ / isaacs: looks like we are also seeing a different error that seems related:
22:21:43  <mjr_>https://gist.github.com/2638935
22:22:03  <piscisaureus_>aha
22:22:07  <mjr_>And perhaps this is what's really going on.
22:22:16  <piscisaureus_>so it seems that halfway the headers the parser throws up
22:22:36  <piscisaureus_>and the parser gets recycled
22:22:42  <mjr_>oh right
22:22:49  <mjr_>But it's not really done.
22:22:58  <piscisaureus_>but the socket can still receive more data which gets pumped into the parser
22:23:00  <mjr_>And before when we would leak them, it didn't matter.
22:23:03  <piscisaureus_>that's supposed to be recycled
22:24:44  <piscisaureus_>it looks good though
22:25:38  <piscisaureus_>weird
22:25:39  <piscisaureus_>parser.reinitialize(HTTPParser.RESPONSE);
22:25:45  <piscisaureus_>that apparently throws somehow?
22:25:56  <mjr_>Yeah, I guess. I kind of stopped following it at that point.
22:27:15  <piscisaureus_>mjr_: which node is that? vanilla 0.6.17?
22:27:30  <mjr_>It's node 0.6.17 with the no idle patch applied.
22:27:56  <mjr_>https://github.com/Voxer/node
22:28:16  <mjr_>Maybe a couple of days behind v0.6 now.
22:28:36  * mralephquit (Quit: Leaving.)
22:29:20  <piscisaureus_>so that's in ClientRequest
22:29:38  <piscisaureus_>and the parser borks on receiving wrong headers
22:29:42  <piscisaureus_>lemme try to reproduce
22:30:27  <mjr_>We apparently have the ultimate continuous integration system: actual users
22:30:44  <piscisaureus_>yep. Please capture them in a bottle for me.
22:43:10  <piscisaureus_>hmm
22:43:12  <piscisaureus_>node.js:201
22:43:12  <piscisaureus_> throw e; // process.nextTick error, or 'error' event on first tick
22:43:12  <piscisaureus_> ^
22:43:12  <piscisaureus_>Error: Parse Error
22:43:12  <piscisaureus_> at Socket.<anonymous> (http.js:1176:24)
22:43:13  <piscisaureus_> at TCP.onread (net.js:374:27)
22:43:15  <piscisaureus_>I can reproduce that
22:43:23  <piscisaureus_>which, unfortunately, does not seem to be catchable
22:47:46  <piscisaureus_>https://gist.github.com/2640099
22:47:47  * mikealquit (Quit: Leaving.)
22:48:03  * erickt_joined
22:48:09  <piscisaureus_>^-- mjr_: how are you guys catching these errors?
22:48:17  <piscisaureus_>mjr_: or are you just crashing the process?
22:49:24  * mikealjoined
22:50:13  <mjr_>piscisaureus_: we have an uncaught exception handler that logs, then exits.
22:50:38  <mjr_>Neat that you have a repro.
22:50:55  <piscisaureus_>mjr_: ah, right. So the parse error is not happening in the same instance as the onIncoming null error?
22:51:10  <piscisaureus_>mjr_: well, the line number for the parse error is different than yours
22:51:11  * ericktquit (Ping timeout: 245 seconds)
22:51:11  * erickt_changed nick to erickt
22:51:55  <piscisaureus_>mjr_: are you sure that these errors come from node 0.6.17 with no patches applied to http.js?
22:55:21  <mjr_>let me double check that there's nothing else different
22:57:40  <mjr_>http.js is unchanged. Our only changes are in src/node.cc
22:58:51  <mjr_>Note that we are on 992e3464b8997210ea7f40f03f0386f8dd4f4f86, which is a couple of commits behind, and one of those did change http.js
22:58:58  <mjr_>Does that explain the line number difference?
23:01:03  <piscisaureus_>it could
23:03:10  <piscisaureus_>mjr_: the funny thing is... this would mean they you are talking to an http server that sends broken responses
23:03:18  <piscisaureus_>mjr_: is that any likely ?
23:03:33  <mjr_>Entirely possible
23:03:41  <piscisaureus_>mjr_: otherwise we are looking at some internal state fuckup in node
23:03:45  <mjr_>We mostly talk to node, but our processes crash all the time.
23:03:54  <mjr_>They crash due to bugs like this. :)
23:04:05  <mjr_>Crashes beget crashes.
23:04:21  <piscisaureus_>mjr_: if the server just hangs up I *also* trigger an uncatchable exception
23:04:45  <piscisaureus_>mjr_: but that shows as [Error: socket hang up] code: 'ECONNRESET'
23:05:27  <mjr_>The only HTTP server we talk to from this process is node.
23:06:19  <piscisaureus_>it could happen when you are using a keepalive http server
23:06:28  <piscisaureus_>but not set the Content-Length correctly
23:07:29  <mjr_>We never explicitly set the content-length in our code. It should all be using chunked encoding.
23:09:41  <piscisaureus_>hmm
23:11:18  <piscisaureus_>server-size keepalive bugs sound highly unlikely
23:11:26  <piscisaureus_>*side
23:14:38  <igorzi>piscisaureus_: https://github.com/igorzi/libuv/commit/52553cddbcb2f7c5a135d5beac1638ef938393ec
23:14:44  <igorzi>piscisaureus_: pls review when you get a chance
23:14:58  <igorzi>isaacs: FYI ^
23:15:01  <piscisaureus_>mjr_: I don't know atm. I will file a node bug. We should get these uncatchable errors rounded up first
23:15:40  <mjr_>piscisaureus_: OK, thanks. If you want me to try anything, I'm open. This is happening about 100 times / day right now.
23:23:31  <piscisaureus_>igorzi: you should probably take another approach
23:23:42  <piscisaureus_>igorzi: with this you will stat the link target
23:24:31  <igorzi>piscisaureus_: you mean take another approach for lstat?
23:24:48  <piscisaureus_>With this approach you will stat the symlink target
23:24:54  <piscisaureus_>igorzi: thats not what unix does
23:25:26  <piscisaureus_>igorzi: what you need to do is CreateFile with that flags that inhibits reparse points
23:26:01  <igorzi>piscisaureus_: are you talking about stat or lstat?
23:26:12  <piscisaureus_>igorzi: lstat
23:26:27  * mikealquit (Quit: Leaving.)
23:26:28  <piscisaureus_>igorzi: I think it is easiest to create a function that can do both stat and lstat
23:26:37  <piscisaureus_>igorzi: (an internal one)
23:26:51  * toothrquit (Read error: Connection reset by peer)
23:26:57  <igorzi>piscisaureus_: what's the unix behavior? when you lstat a file - you get same results as stat?
23:27:05  <piscisaureus_>igorzi: nope
23:27:13  <piscisaureus_>igorzi: lemme give an example
23:27:20  * piscisaureus_boots up vm
23:27:20  <igorzi>piscisaureus_: k, thanks
23:28:27  * paddybyersquit (Quit: paddybyers)
23:28:37  * toothrjoined
23:29:18  * perezdjoined
23:32:20  <piscisaureus_>igorzi: https://gist.github.com/2640399
23:38:03  <igorzi>piscisaureus_: what about require('fs').lstatSync('file') ? is that the same thing as require('fs').statSync('file') ?
23:38:13  <piscisaureus_>igorzi: yep
23:38:25  <igorzi>piscisaureus_: ok, thanks
23:42:41  <piscisaureus_>igorzi: sorry for the spam. I keep hitting ctrl+enter accidentally
23:43:59  * isaacsback
23:46:54  <piscisaureus_>igorzi: +1 for having tests btw!
23:51:12  <bnoordhuis>back
23:51:15  <bnoordhuis>piscisaureus_: looking for me?
23:56:40  <piscisaureus_>damn bnoordhuis
23:56:47  <piscisaureus_>where have you been :-p
23:57:13  <piscisaureus_>bnoordhuis: anyway, can you review https://github.com/piscisaureus/node/compare/master...netwrite
23:57:23  <bnoordhuis>is that the fixed-up version?
23:57:39  <piscisaureus_>bnoordhuis: I has fixup commits. I will squash after your review
23:57:57  <piscisaureus_>bnoordhuis: (I can also do that already but I suppose that makes reviewing more difficult)