00:00:38  * dapjoined
00:01:52  <bnoordhuis>isaacs: what problems did you run into?
00:03:01  <isaacs>bnoordhuis: explosions of test failures :)
00:03:34  <bnoordhuis>hah, okay
00:04:19  <isaacs>test-domain-multi is being a bit of a jerk.
00:06:25  * joeandaverdejoined
00:06:30  * chobi_echanged nick to chobi_e_
00:14:46  * mikealquit (Quit: Leaving.)
00:32:52  * xaqquit (Read error: Connection reset by peer)
00:33:17  * xaqjoined
00:35:52  * felixgejoined
00:35:52  * felixgequit (Changing host)
00:35:52  * felixgejoined
00:37:55  * felixgequit (Client Quit)
00:42:56  * EhevuTovquit (Quit: Leaving)
00:44:52  * txdvquit (Read error: Operation timed out)
00:49:30  * txdvjoined
00:50:23  * ericktquit (Ping timeout: 248 seconds)
00:57:32  <joeandaverde>if uv_read_cb is called multiple times for a tcp connection and i want the data in its entirety before responding does it make sense to append the uv_buf_t base to another spot in memory?
00:57:48  <joeandaverde>is there a better way of doing this?
00:58:23  <mitsuhiko>joeandaverde: depends on your protocol really
00:58:51  <joeandaverde>mitsuhiko: I'm buffering an entire http request (intentionally not parsing as the request comes in)
00:59:10  <mitsuhiko>in that case go nuts and make a overallocating buffer
00:59:27  <joeandaverde>what i'm working on is merely for demonstration purposes and not actually practical
00:59:47  <mitsuhiko>joeandaverde: all uv_* things have a data attribute you can assign arbitrary stuff to
00:59:49  <joeandaverde>when you say over allocating buffer do you mean from the alloc callback?
00:59:59  <mitsuhiko>you can put a struct on there and manage your own buffer on it
01:00:14  <joeandaverde>indeed
01:00:15  <mitsuhiko>joeandaverde: na, that buffer has to go away eventually, make a second one
01:00:51  <joeandaverde>is it common practice to do this?
01:01:09  <mitsuhiko>joeandaverde: by overallocating i mean start out with N bytes, each time you hit the limit increase the size by a certain factor
01:01:11  <mitsuhiko>(for instance 50%)
01:01:24  <joeandaverde>oh, i got ya
01:02:19  <joeandaverde>when i ask if it's common practice… i mean is it common to buffer multiple read callbacks before acting?
01:02:55  <mitsuhiko>joeandaverde: depends on the level you're buffering
01:03:03  <mitsuhiko>at the end of the day: i am buffering, but i am not buffering bytes
01:03:32  <mitsuhiko>i'm feeing bytes piece by piece into a parser, the resulting things are then buffered up
01:03:51  <joeandaverde>ahh
01:04:15  <joeandaverde>it could do advanced things like free the already parsed bytes and continue accepting new bytes
01:04:30  <joeandaverde>i imagine that's how ry's http parser works
01:05:55  * dapquit (Quit: Leaving.)
01:06:05  <joeandaverde>mitsuhiko: thanks for your help
01:07:01  <isaacs>bnoordhuis: just pushed less-chatty domain-leak branch
01:07:02  <mitsuhiko>joeandaverde: ry's http parser == https://github.com/joyent/http-parser?
01:07:12  <joeandaverde>yes
01:07:41  <mitsuhiko>joeandaverde: that one does zero buffering
01:07:45  <isaacs>https://github.com/isaacs/node/commit/d6b78d0e3769e4af1b1a60e89f53faf20e4bb2b3
01:07:48  <mitsuhiko>which also makes it very, very awkward to use
01:08:08  <joeandaverde>probably to keep a low memory profile?
01:08:11  <mitsuhiko>joeandaverde: your callback for a header could be called for every single byte in worst case
01:08:17  <mitsuhiko>joeandaverde: yes
01:08:50  <joeandaverde>interesting decision… the tradeoff's between callbacks and memory consumption
01:09:42  <mitsuhiko>joeandaverde: http parser could work better if it would not have callbacks though
01:09:57  <mitsuhiko>imo the parsing state should just be a struct that you can inspect after calling a tryparse function
01:10:05  <mitsuhiko>(in case you want to do something inspired by it)
01:11:06  <joeandaverde>interestingly i'm creating a super simplified clone of node.js. I'm doing this firstly to learn and secondly to easily demonstrate how node.js uses libuv and v8.
01:12:36  <joeandaverde>essentially javascript will get the entire HTTP request and return a HTTP response to c++
01:12:49  <isaacs>mitsuhiko, joeandaverde: I'm flirting with the idea of porting it to JS
01:12:57  <isaacs>mostly for speed, but also for simpler GC management
01:13:11  <mitsuhiko>isaacs: it being http-parser?
01:13:16  <isaacs>mitsuhiko: yes
01:13:27  <joeandaverde>isaacs: i was just listening to your nodeup about the lack of an offset after reading http headers
01:13:40  <joeandaverde>the guy on the show said he rolled his own js parser
01:13:51  <joeandaverde>and got about 90% of the performance of the c version
01:13:53  <isaacs>joeandaverde: substack
01:14:00  <mitsuhiko>isaacs: makes sense for node, but not everything in the world is node :)
01:14:02  <isaacs>joeandaverde: yeah, and i think we can get 100% of the performance, or close enough to it
01:14:05  <isaacs>mitsuhiko: sure.
01:14:21  <mitsuhiko>isaacs: you should be able to get faster
01:14:24  <isaacs>also, i'd really like to make node eventually be js+libuv, and that's it
01:14:36  <joeandaverde>do you expect to exceed 100%? Would v8 be able to optimize sufficiently?
01:14:41  <isaacs>like, javascript + v8 bindings + libuv
01:15:02  <isaacs>joeandaverde: i'm not sure. it's not hte kind of thing you can realiably say before doing the work to find out
01:15:13  <mitsuhiko>joeandaverde: http-parser is (for not sure what reason) not very fast
01:15:21  <mitsuhiko>i suspect it might be because it's callback based
01:15:41  <mitsuhiko>or i am doing something really wrong, but a naive python based http parser is faster here
01:15:42  <joeandaverde>yeah, i imagine setting up a new stack for each callback can be expensive...
01:16:55  <joeandaverde>do the callbacks ultimately trickle back to javascript land?
01:17:32  <mitsuhiko>i don't think node uses actual javascript callbacks there
01:17:59  <mitsuhiko>joeandaverde: i'm not using node, so i would not know. the timing came from my c based tests
01:18:07  <joeandaverde>gotcha
01:19:27  <joeandaverde>isaacs: if doing a "deep dive" into the node source do you have any suggestions for the most interesting parts to cover? I think domains is on that list somewhere.
01:19:52  * xaqquit (Remote host closed the connection)
01:20:17  <isaacs>yeah, domain is kinda interesting
01:21:55  <joeandaverde>I think understanding how require works would also be essential
01:30:55  <bnoordhuis>mitsuhiko: http-parser is not very cache friendly :/
01:31:32  <bnoordhuis>isaacs: lgtm
01:33:11  <isaacs>bnoordhuis: thanks
01:33:56  * abraxasjoined
01:33:57  <CIA-108>node: isaacs v0.8 * rd6b78d0 / (lib/domain.js test/simple/test-domain-stack.js): domain: Fix stack leak on error - http://git.io/9n4flA
01:34:36  <CIA-108>node: Pavel Lang master * rff14007 / (3 files in 3 dirs): Enable color customization of `util.inspect` - http://git.io/mS_LGA
01:36:37  <CIA-108>node: George Shank master * r8721667 / (doc/index.html doc/images/forkme.png): doc: update 'Fork me at Github' ribbon - http://git.io/3txOsA
01:36:37  <CIA-108>node: Bert Belder master * r23dc099 / benchmark/tls-connect.js : benchmark: add single process tls connection benchmark - http://git.io/_Eo99A
01:36:40  <CIA-108>node: Mike Morearty master * r19aa05f / doc/api/child_process.markdown : doc: fix bug in child_process.spawn() sample code - http://git.io/IvYvsQ
01:36:44  <CIA-108>node: isaacs master * rd6b78d0 / (lib/domain.js test/simple/test-domain-stack.js): domain: Fix stack leak on error - http://git.io/9n4flA
01:36:46  <CIA-108>node: isaacs master * r8973c3d / (4 files in 4 dirs): Merge remote-tracking branch 'ry/v0.8' - http://git.io/YioPvA
01:38:41  <isaacs>bnoordhuis: https://github.com/joyent/node/pull/3722 <-- just the "makecallback" change, without all the other nextTick stuff.
01:45:20  <isaacs>bnoordhuis: String::New, not String::NewSymbol?
01:45:34  * isaacsis never really clear about which one is better
01:46:45  <bnoordhuis>isaacs: in this case yes :)
01:47:03  <isaacs>is NewSymbol only for cases where it's used more times?
01:47:06  <bnoordhuis>yes
01:47:42  <isaacs>kewl, thanks
01:48:11  <bnoordhuis>otherwise lgtm
01:49:25  <isaacs>k, fixed, landing
01:51:57  <CIA-108>node: isaacs master * r0109a9f / (src/node.cc src/node.js): Move MakeCallback to JS - http://git.io/Y8ldFw
02:11:06  * arlolraquit (Quit: Linkinus - http://linkinus.com)
02:20:32  * beachdogquit (Read error: Connection reset by peer)
02:20:33  * beachdog_joined
02:25:59  * philips_quit (Excess Flood)
02:29:08  * philips_joined
02:38:15  * ericktjoined
02:39:24  * mikealjoined
02:44:36  * EhevuTovjoined
02:47:14  * felixgejoined
02:47:14  * felixgequit (Changing host)
02:47:14  * felixgejoined
02:59:57  * isaacschanged nick to isaacs[dinnertie
03:13:38  * mikealquit (Quit: Leaving.)
03:16:37  * mjr__joined
03:35:00  * isaacs[dinnertiechanged nick to isaacs
03:44:59  * bnoordhuisquit (Ping timeout: 240 seconds)
04:09:40  * benviequit (Ping timeout: 244 seconds)
04:10:13  * benviejoined
04:11:13  * felixgequit (Quit: felixge)
04:29:20  * benviequit
04:30:20  * piscisaureus_joined
04:35:01  * piscisaureus_quit (Client Quit)
04:35:23  * mjr__quit (Quit: mjr__)
04:44:17  * mmaleckijoined
04:46:54  <ryah>isaacs: i noticed you're running lint after "make test"
04:47:02  <ryah>what about getting c++ linting going too?
04:47:07  * mikealjoined
04:47:21  <ryah>we're quite far from passing lint in c++
04:47:37  <ryah>but i think it would be good if we did
04:47:54  <ryah>there is some hope that lint can catch errors
04:48:50  <ryah>isaacs: also - might make sense to pull all of the c-ares stuff out of core
04:48:57  <ryah>and make an external module for that
04:49:29  <ik>what's a child aviation restraint system doing in libultraviolet anyway
04:49:54  <ryah>it's for dns
04:50:10  <ryah>turns out we just use getaddrinfo() in a thread pool most of the time
04:50:57  <ryah>(unfortunately - dns it seems is not something that can be done sufficently outside of the core OS)
04:51:15  <ryah>too many hooks
04:51:35  <ryah>TooTallNate: it would be great to have a screencast about node-gyp
04:51:44  <ryah>TooTallNate: especially if you should how it works on windows
04:52:17  <TooTallNate>ryah: that would definitely be a good thing
04:52:27  <TooTallNate>i'll put it on the todo list
04:53:16  <ryah>npm runs node-gyp automatically?
04:53:28  <TooTallNate>https://github.com/TooTallNate/node-gyp/issues/106
04:53:30  <TooTallNate>yes
04:53:36  <ryah>if so it would be best to show it working with npm first
04:53:42  <ryah>install and build on both a mac and windows
04:53:56  <ryah>emphasis that this is to support a good cross platform situation
04:54:16  <TooTallNate>maybe even start out with fresh OS's
04:54:19  <ryah>install an addon module that is
04:54:38  <ryah>for node-gyp to work on windows you need to have visual studio?
04:54:46  <TooTallNate>ya
04:54:51  <ryah>what if you have mingw?
04:55:02  <TooTallNate>i don't think gyp supports it
04:55:05  <ryah>would be great to detect if you have visual studio, prefer that
04:55:07  <ryah>oh yeah, true
04:55:11  <ryah>fucking gyp.
04:55:15  <TooTallNate>haha
04:55:32  <ryah>yeah, so obivously mention that you need to have msvs installed
04:55:35  <TooTallNate>i've been asked about that a lot though, so it would be cool
04:55:51  <ryah>then once you show how it works from a user's perspective
04:56:03  <ryah>show the gyp file. explain it's more declaritive than waf
04:56:12  <ryah>no need to understand compiler flags, for the most part
04:56:40  <ryah>also, would be nice to suggest that people statically compile the libraries they are wrapping
04:56:47  <ryah>inside the build of the addon
04:56:54  * ericktquit (Quit: erickt)
04:56:56  <TooTallNate>indeed
04:57:06  <ryah>so that if someone goes to install a libxml binding that it doesn't give you a link error
04:57:11  <ryah>(most users don't know what a link error means)
04:57:18  <ryah>(or what to do when they get that)
04:57:41  <ryah>actually - it would be awesome to do a simple addon during the screencast for a real-life library
04:58:16  * mmaleckiquit (Ping timeout: 248 seconds)
04:59:47  <TooTallNate>something easy to convert to gyp
04:59:50  <ryah>yeah...
04:59:51  <TooTallNate>with few source files
05:00:02  <TooTallNate>or already gyp-ified :p
05:00:11  <ryah>maybe the geoip lib?
05:00:30  <ryah>http://www.maxmind.com/app/c
05:01:00  <ryah>i think there is just one function to wrap
05:01:06  * ericktjoined
05:01:33  <TooTallNate>kewl, i'll take a look at it
05:02:07  <ryah>gyp file for that should be trivial
05:03:14  * beachdog_quit (Quit: beachdog_)
05:04:27  <ryah>TooTallNate: make sure you use a readable font
05:05:00  <ryah>let's post-edit too
05:05:06  <ryah>to make it short and crisp
05:05:12  <ryah>maybe mikeal can help with that
05:05:27  <TooTallNate>well we'd have to to include multiple os's
05:06:14  <TooTallNate>omg, this gives me an excuse to get Final Cut for the new MBP
05:06:26  <ryah>mikeal has really good microphones
05:06:37  <ryah>maybe he can set you up with them
05:06:50  <ryah>if we put a plug for node summer camp in the screencast :)
05:08:49  <TooTallNate>haha
05:08:51  * joeandaverdequit (Quit: joeandaverde)
05:12:28  * ericktquit (Quit: erickt)
05:35:40  * TooTallNatequit (Quit: ["Textual IRC Client: www.textualapp.com"])
06:16:06  * AvianFluquit (Ping timeout: 250 seconds)
06:20:20  * paddybyersjoined
06:52:41  * rendarjoined
06:57:56  * stephankquit (Quit: *Poof!*)
07:16:50  * paddybyersquit (Quit: paddybyers)
07:53:34  * loladirojoined
08:00:55  * paddybyersjoined
08:02:12  * paddybyers_joined
08:03:10  * piscisaureus_joined
08:03:20  * piscisaureus_quit (Client Quit)
08:05:28  * paddybyersquit (Ping timeout: 252 seconds)
08:05:28  * paddybyers_changed nick to paddybyers
08:15:27  * loladiroquit (Quit: loladiro)
08:41:00  * EhevuTovquit (Quit: This computer has gone to sleep)
08:46:43  * mmaleckijoined
09:24:38  * hzjoined
09:43:12  <mitsuhiko>a uv_timeout_add would be very convenient :)
09:51:37  * mmalecki_joined
09:52:12  * hzquit (Disconnected by services)
09:52:19  * hzjoined
09:53:12  * mmaleckiquit (Ping timeout: 248 seconds)
10:14:07  * Raynosquit (Read error: Connection reset by peer)
10:14:08  * indutnyquit (Remote host closed the connection)
10:18:24  * mmalecki_changed nick to mmalecki
10:49:56  * Raynosjoined
10:51:29  * toothrotquit (Ping timeout: 240 seconds)
10:59:12  * felixgejoined
10:59:12  * felixgequit (Changing host)
10:59:12  * felixgejoined
11:09:05  * hzquit (Disconnected by services)
11:09:10  * hzjoined
11:11:14  * abraxasquit (Remote host closed the connection)
11:16:04  * hzquit (Ping timeout: 272 seconds)
11:22:11  * indutnyjoined
11:42:52  * felixgequit (Quit: felixge)
11:46:16  * mmaleckiquit (Ping timeout: 248 seconds)
11:51:39  * bnoordhuisjoined
11:55:05  * mmaleckijoined
11:55:16  * toothrotjoined
12:13:46  * chobi_e_changed nick to chobi_e
12:17:02  * beachdogjoined
12:21:23  * felixgejoined
12:21:23  * felixgequit (Changing host)
12:21:23  * felixgejoined
12:24:11  * felixgequit (Client Quit)
12:28:37  * joeandaverdejoined
12:30:52  <mitsuhiko>i'm using hiredis with libuv through uv_poll. works fine, but if i kill the redis server and try to reconnect, it sometimes takes up to 10 seconds for it to come back
12:31:05  <mitsuhiko>(even though the console redis client can connect to the redis server immediately after the restart)
12:31:17  <mitsuhiko>any ideas what might cause that?
12:39:59  * beachdogquit (Quit: beachdog)
12:55:22  * mmaleckiquit (Read error: Connection reset by peer)
12:57:05  * mmaleckijoined
12:57:18  * beachdogjoined
13:09:32  * mmaleckiquit (Read error: Connection reset by peer)
13:18:50  <bnoordhuis>mitsuhiko: what do you see when you strace it?
13:19:16  * joeandaverdequit (Quit: joeandaverde)
13:19:57  <mitsuhiko>bnoordhuis: nothing interesting
13:20:08  <mitsuhiko>just some fcntl/setsockopt and failed conncet
13:20:17  <mitsuhiko>(that's os x with kevent)
13:20:27  <bnoordhuis>mitsuhiko: and what when you trace redis?
13:20:34  <mitsuhiko>sec
13:20:40  <bnoordhuis>maybe it just takes a while for it to get back online
13:22:28  <mitsuhiko>bnoordhuis: weird. does not happen if i dtruss the server
13:22:56  <mitsuhiko>i wonder if launchctl stop kills redis differently than me
13:23:23  <bnoordhuis>ah, a heisenbug - goes away when you observe it
13:23:52  <mitsuhiko>the redis launchctl config here however does not open the port through launchctl so that's not the issue
13:29:19  * mmaleckijoined
13:35:04  <mitsuhiko>bnoordhuis: yeah. i'm just going to ignore that for the time being
13:35:11  <mitsuhiko>os x socket layer so magical
13:35:49  * AvianFlujoined
13:36:56  * bnoordhuisquit (Ping timeout: 244 seconds)
13:39:20  * c4milojoined
13:55:14  <indutny>hi
14:11:04  <isaacs>ryah: the only blocker to running cpplint after make test is that cpplint fails so embarrassingly.
14:11:46  <isaacs>ryah: someone started a pull req to fix it, but it was long and tedious. but yes, linting does occasionally find valid errors.
14:12:52  <indutny>haha
14:12:54  <indutny>well, not only that
14:13:12  <indutny>node.js has a long history, and older files have different style
14:13:22  <indutny>and there're also some new files with modern style :)
14:13:28  <indutny>which I do not really accept
14:13:34  <tjfontaine>what we need is semantic linting
14:15:47  <isaacs>indutny: that's part of the reason why linting is important, actually
14:15:58  <isaacs>to keep consistency. but it's a big chore to bring it up to date
14:16:13  <isaacs>indutny: it's ok to not be happy with a style. you'll get over it.
14:16:21  <tjfontaine>and it ruins blame
14:16:38  <isaacs>tjfontaine: yeah, when you make the change the first time. but if we're consistent with it, then it is fine thereafter.
14:17:06  <isaacs>tjfontaine: we linted the js between 0.6 and 0.8. it's been kind of nice actually.
14:17:13  <tjfontaine>indeed
14:17:45  <isaacs>and it can sometimes make merges a bit cleaner (as long as your'e not merging from pre-lint world to post-lint world)
14:18:11  <indutny>oh
14:18:16  <indutny>well, the real problem is not blame
14:18:25  <indutny>the real problem is that we'll need to lint both 0.8 and 0.9
14:22:04  <mitsuhiko>Assertion failed: (!(handle->flags & UV_CLOSED)), function uv__finish_close
14:22:11  <mitsuhiko>any ideas why that would happen after my on_close?
14:22:24  <mitsuhiko>handle was properly initialized and closed via uv_close((uv_handle_t *)&client->handle, on_close);
14:22:35  <mitsuhiko>the on_close basically does a free on the client struct
14:22:47  <mitsuhiko>(handle is a uv_tcp_t)
14:23:53  <indutny>you haven't closed something, I suppose
14:24:02  <indutny>are you sure that you're closing correct handle?
14:24:25  <mitsuhiko>yes
14:24:26  <indutny>err
14:24:33  <indutny>I mean, you've closed something wrong :)
14:25:19  <mitsuhiko>hmm. the handle is a member on the struct
14:25:26  <mitsuhiko>how can that even work
14:25:37  <mitsuhiko>if i free the struct, the handle would be invalid
14:25:40  <mitsuhiko>guess i have to malloc that thing
14:26:18  * hzjoined
14:27:13  <mitsuhiko>ah never mind. something closed it twice
14:28:10  <indutny>or even that :)
14:30:24  * beachdogquit (Quit: beachdog)
14:31:47  <isaacs>wow, this case that shigeki found is super oddball
14:31:50  * beachdogjoined
14:32:01  <tjfontaine>hm?
14:32:28  <isaacs>oh, nvm.
14:32:39  <isaacs>it's just odd that console.error() and console.log() can apparently throw off the tick spinner.
14:33:51  <isaacs>if you're writing to both stdout, and stderr, then it's like the tick spinner is getting confused or something.
14:37:54  <isaacs>oh, ok, it's not that it's writing to two outputs, it's that ti's doing two writes
14:42:01  <chobi_e>hi, I'm playing my php libuv bindings. it works fine. but sometimes it causes timeout on OSX box like this. https://github.com/chobie/php-uv/issues/5
14:42:03  <chobi_e>did I forget some error handling? or just network problem?
14:47:41  <mitsuhiko><insert snarky php comment here>
14:47:50  <mitsuhiko>chobi_e: without code that whole thing won't help much
14:49:10  <chobi_e>yea that's right. wait a sec
15:05:21  <chobi_e>hmm, I couldn't pickup good example. is this error handling seems ok? https://github.com/chobie/php-uv/blob/master/examples/http.php#L95
15:26:16  * xaqjoined
15:32:01  <mitsuhiko>chobi_e: i don't think many people here use php
15:32:12  <mitsuhiko>i don't know how the php binding does cleanup and stuff
15:35:07  <indutny>I wonder how if it's moving GC
15:35:16  <indutny>it has
15:37:25  <mitsuhiko>indutny: php is reference counted
15:37:29  <indutny>oh
15:37:32  <indutny>even that
15:37:43  <indutny>yeah, I remember times when they solved circular reference problem
15:38:06  <mitsuhiko>they did?
15:38:17  <mitsuhiko>i don't think php has ways to break up cycles by itself
15:38:35  <mitsuhiko>oh, i am wrong
15:38:48  <indutny>yes, you're wrong
15:38:54  <indutny>:)
15:39:00  <indutny>still it's retarded
15:39:16  <mitsuhiko>php 5.3 introduced a cyclic garbage collector: http://www.php.net/manual/en/features.gc.php
15:39:55  <mitsuhiko>reference counting is awesome though if yuo don't have threads
15:40:14  <indutny>em... not really :)
15:40:22  <indutny>well, it works
15:40:33  <mitsuhiko>it's predictable memory consumption
15:41:03  <mitsuhiko>the problem with refcounts is that they require locking for object access and that they touch your pages which renders cow useless (unless you move the counts somewhere else)
15:41:06  <mitsuhiko>aside from that: awesome :)
15:42:13  <chobi_e>mitsuhiko: thanks, I think so. php is minority here. I'd like to wirte network programming more easily with php :)
15:44:12  * hzquit (Disconnected by services)
15:44:16  * hzjoined
15:46:57  * ericktjoined
15:47:33  <mitsuhiko>chobi_e: fair enough, but then i would ask the guy who wrote php-uv
15:52:06  <chobi_e>mitsuhiko: it's me. i'd like to make more robust php libuv extension.
15:52:33  <mitsuhiko>chobi_e: if you make a robust libuv extension, don't ever let the php developer handle cleanup
15:52:37  <mitsuhiko>the extension has to do that
15:55:22  * ericktquit (Ping timeout: 272 seconds)
15:55:41  * ericktjoined
15:59:53  * ericktquit (Ping timeout: 240 seconds)
16:01:41  * stephankjoined
16:02:24  <isaacs>cyclic gc in php?
16:02:26  <isaacs>feh.
16:02:31  <isaacs>if you need gc, you're doing php wrong
16:02:44  <isaacs>just use a bunch of memory, then trash the whole thing, every request.
16:03:08  <isaacs>it's not for writing programs, its' for writing templates
16:04:10  <chobi_e>mitsuhiko: yea. I'll keep your advice when I implement OOP interface.
16:06:52  <chobi_e>isaacs: hehe, there are some curious people in the world. I love php.
16:09:56  * hzquit
16:10:07  <chobi_e>anyway, node v0.8.2 and simple http server (https://gist.github.com/3130320) causes same problem on my OSX. i guess it's my network problem. i'll look into this problem in a few weeks.
16:20:42  * hzjoined
16:24:50  * ericktjoined
16:25:32  * dapjoined
16:32:39  * philips_quit (Excess Flood)
16:33:22  * hzquit (Ping timeout: 272 seconds)
16:35:11  * philips_joined
16:39:02  * hzjoined
16:40:22  * dapquit (*.net *.split)
16:40:22  * ericktquit (*.net *.split)
16:40:22  * mikealquit (*.net *.split)
16:40:22  * voodootikigodquit (*.net *.split)
16:40:34  * mikealjoined
16:58:11  * dapjoined
16:58:11  * voodootikigodjoined
17:06:18  * hzquit (Ping timeout: 272 seconds)
17:09:22  * felixgejoined
17:09:22  * felixgequit (Changing host)
17:09:22  * felixgejoined
17:09:56  * hzjoined
17:15:47  * mikealquit (Quit: Leaving.)
17:16:03  * TooTallNatejoined
17:16:37  * mikealjoined
17:17:01  * hzquit (Disconnected by services)
17:17:05  * hzjoined
17:21:44  * hzquit (Disconnected by services)
17:21:47  * hzjoined
17:58:24  * mikealquit (Quit: Leaving.)
18:02:55  * EhevuTovjoined
18:15:08  <TooTallNate>how do I debug segfaults on smartos?
18:15:12  <TooTallNate>no gdb :(
18:16:35  <dap>mdb
18:16:46  <dap>we do have gdb in pkgsrc, I think, but we all use mdb.
18:17:00  <dap>it's not source-level, though, and the syntax is somewhat arcane.
18:17:18  <dap>You may find this helpful: https://blogs.oracle.com/eschrock/entry/gdb_to_mdb
18:19:17  <dap>TooTallNate: ^
18:19:37  <TooTallNate>ohh thanks man
18:21:59  * chobi_echanged nick to chobi_e_
18:22:43  * arlolrajoined
18:25:17  * `3rdEdenjoined
18:33:53  * mikealjoined
18:45:40  <isaacs>making an 0.8.3
18:45:44  <isaacs>get ready!
18:45:53  <isaacs>there are basically no changes. i'ts so great.
18:47:01  <indutny>em
18:47:09  <indutny>if there're no changes, why are we releasing it? :)
18:54:27  <isaacs>indutny: there are a few changes :)
18:54:30  <isaacs>they're just all very minor
18:55:16  <indutny>that's good :)
18:56:31  <TooTallNate>indutny: it fixes a build error on quite a few platforms, so that's good
19:04:15  <CIA-108>node: isaacs v0.8.3-release * rc383bef / (182 files in 37 dirs): npm: Upgrade to 1.1.43 - http://git.io/ho0MYQ
19:04:15  <CIA-108>node: isaacs v0.8.3-release * r7397ab2 / (11 files in 5 dirs): uv: Upgrade to a9f6f06 - http://git.io/cD9JgQ
19:04:15  <CIA-108>node: isaacs v0.8.3-release * ra0a0062 / (7 files in 3 dirs): v8: upgrade to 3.11.10.15 - http://git.io/Zt26cg
19:04:16  <CIA-108>node: isaacs v0.8.3-release * r868ffed / deps/v8/build/common.gypi : v8: Reapply floating patches - http://git.io/DtsrXw
19:04:16  <CIA-108>node: isaacs v0.8.3-release * r799dda9 / (AUTHORS ChangeLog src/node_version.h): 2012.07.17, Version 0.8.3 (Stable) - http://git.io/Ce8WmA
19:04:38  <CIA-108>node: isaacs v0.8 * rc383bef / (182 files in 37 dirs): npm: Upgrade to 1.1.43 - http://git.io/ho0MYQ
19:04:39  <CIA-108>node: isaacs v0.8 * r7397ab2 / (11 files in 5 dirs): uv: Upgrade to a9f6f06 - http://git.io/cD9JgQ
19:04:39  <CIA-108>node: isaacs v0.8 * ra0a0062 / (7 files in 3 dirs): v8: upgrade to 3.11.10.15 - http://git.io/Zt26cg
19:04:39  <CIA-108>node: isaacs v0.8 * r868ffed / deps/v8/build/common.gypi : v8: Reapply floating patches - http://git.io/DtsrXw
19:04:49  <isaacs>UPGRADE ALL TEH THINGS!
19:04:50  <LOUDBOT>GUO WILL NOT STOP HUMMING
19:05:00  * loladirojoined
19:05:12  <isaacs>TooTallNate: the real question is how do you debug segfaults anywhere else
19:05:53  <isaacs>TooTallNate: i'm at the point in my growth as a sunos user that i've forgotten what I knew of gdb, but haven't quite managed to catch up with mdb.
19:06:11  <TooTallNate>well.. i'd like to get there :p
19:06:29  <isaacs>TooTallNate: start learning to love ::jsstack
19:06:47  <isaacs>dap: speaking of which, does that work on v0.8 yet? i remember it was busted a bit.
19:07:05  * isaacsis just being lazy, if you don't know offhand, I can check mysefl.
19:07:36  <dap>isaacs: That's currently on Bryan's queue, but no, it's not done yet :-/
19:07:39  <TooTallNate>well i got this: https://gist.github.com/452acae9cb42e8f17077
19:07:41  <isaacs>kewl
19:07:47  <TooTallNate>not quite sure that it says :p
19:08:14  <isaacs>TooTallNate: that's pretty juicy
19:08:17  <dap>TooTallNate: instead of ::stack for JS, first do "::load v8", then "::jsstack", although that's busted on 0.8 :-/
19:08:35  <dap>You can try it, but the debugger itself may crash.
19:08:38  <dap>Sorry about that.
19:08:41  <dap>Are you on 0.8?
19:08:58  <isaacs>dap: it *sometimes* works, i think
19:09:10  <isaacs>or at least, it was sometimes working somewhere between 0.7.12 and 0.8.0
19:09:21  <dap>It always worked on some middle 0.7 releases.
19:09:44  <TooTallNate>dap: do you know what changed?
19:09:53  <TooTallNate>probably some compiler switch...
19:10:12  <dap>TooTallNate: I think it was a V8 update that changed slightly how they access properties in objects, but I haven't dived too far into it yet.
19:10:21  <TooTallNate>ahhh
19:10:40  <dap>The compiler shouldn't affect it because we include in libv8.a (and the node binary) the various offsets we need. But if those offsets change semantically, we get broken.
19:18:38  <isaacs>test, please: http://nodejs.org/dist/v0.8.3/node-v0.8.3-RC0.tar.gz
19:23:58  <indutny>downloading
19:25:41  <indutny>building
19:26:16  * mikealquit (Quit: Leaving.)
19:32:30  <indutny>[02:20|% 100|+ 438|- 0]: Done
19:32:33  <indutny>congrats guys
19:32:33  <indutny>:)
19:32:49  <indutny>isaacs: ^
19:32:51  <indutny>osx
19:33:49  <tjfontaine>hmm I must be the only one getting test-child-process-customfd-bounded failure, I'll blame mountain lion
19:34:24  <tjfontaine>or I guess this is a master thing, vs 0.8
19:38:50  * arlolraquit (Quit: Linkinus - http://linkinus.com)
19:57:31  * mikealjoined
19:59:12  * mmalecki_joined
19:59:20  * `3rdEdenquit (Remote host closed the connection)
19:59:39  * EhevuTovquit (*.net *.split)
19:59:39  * TooTallNatequit (*.net *.split)
19:59:39  * mmaleckiquit (*.net *.split)
19:59:39  * einarosquit (*.net *.split)
19:59:39  * jcequit (*.net *.split)
19:59:47  * einarosjoined
19:59:57  * jcejoined
20:00:29  * mmalecki_quit (Client Quit)
20:00:49  * mmaleckijoined
20:04:38  * EhevuTovjoined
20:04:58  * mmalecki_joined
20:07:32  * TooTallNatejoined
20:08:13  <TooTallNate>dap: i have a SIGSEGV caught with mdb right now, care to walk me through it?
20:08:36  <TooTallNate>fwiw i have a feeling the cause is a native add-on we're using
20:10:28  <TooTallNate>::load v8
20:10:28  <TooTallNate>mdb: no module 'v8' could be found
20:11:07  * EhevuTovquit (Quit: Leaving)
20:11:21  <tjfontaine>If this fails, you’re running an older version of SmartOS and you’ll need to download the v8.so binary and use ::load /path/to/v8.so. (You have to use ::load ./v8.so even if the file is in the same directory so that MDB knows you’re giving it a relative path; by default, MDB searches the dynamic library path, which probably doesn’t include “.”.)
20:11:26  <tjfontaine>according to his blog
20:11:42  <tjfontaine>dunno how likely it is that you're running an older smartos though
20:11:48  <TooTallNate>good catch tj
20:11:50  <TooTallNate>it's very likely
20:11:56  <TooTallNate>this is on one of the old no.de boxes
20:12:13  * EhevuTovjoined
20:12:17  <TooTallNate>they still run node v0.4.x by default, but i've got v0.8.2 manually compiled
20:14:50  * mmaleckiquit (Quit: leaving)
20:14:50  * mmalecki_quit (Quit: leaving)
20:15:10  * mmaleckijoined
20:19:15  <dap>TooTallNate: Sorry, was afk. Yeah, you're on an ancient version of SmartOS
20:20:51  <TooTallNate>dap: ok that's cool. i'm pretty sure I know the culprit so i'll try swapping it out for another module
20:23:19  <ryah>isaacs: linux [02:03|% 100|+ 436|- 2]: Done
20:23:20  <isaacs>TooTallNate: it's ::load v8.so
20:23:22  <ryah>[02:03|% 100|+ 436|- 2]: Done
20:23:26  <isaacs>ryah: what failed?
20:23:34  <ryah>Command: out/Release/node /tmp/node-v0.8.3/test/simple/test-setproctitle.js
20:23:43  <ryah>Command: out/Release/node /tmp/node-v0.8.3/test/simple/test-net-connect-timeout.js
20:24:06  * `3rdEdenjoined
20:24:34  <ryah>isaacs: https://gist.github.com/410d42caa1c5b6466fb3
20:25:51  <isaacs>ryah: thanks!
20:26:04  <indutny>ryah: can you run process.title ='123' ?
20:26:07  <indutny>on that box
20:26:38  <indutny>nvm
20:26:41  <indutny>I'll do it myself
20:26:46  <indutny>I've few boxes around
20:26:46  <ryah>ryan 23862 0.5 0.2 660436 7752 pts/0 Sl+ 13:25 0:00 123 de
20:26:54  <ryah>^-- somehow adds some extra chars?
20:27:01  <ryah>"123 de" ?
20:27:41  <indutny>well
20:27:52  <indutny>looks like so
20:28:06  <indutny>what's your kernel version?
20:28:58  <ryah>indutny: 3.2.0-26-generic
20:29:17  <indutny>ok
20:29:44  <indutny>I've only 2.6.32 unfortunately
20:30:00  <indutny>but I'll try compiling on it
20:30:52  * EhevuTovquit (Quit: Leaving)
20:31:09  <TooTallNate>looks like a problem with null terminating
20:31:13  <indutny>indeed
20:31:27  <indutny>I think Ben changed copying function here
20:31:31  <indutny>before applying my patch
20:31:59  <indutny>yeah, it was using strncpy
20:32:18  <indutny>and using uv_strlcpy
20:32:21  <indutny>now
20:33:59  <TooTallNate>yes i see
20:34:04  <indutny>odd
20:34:10  <indutny>it should terminate it anyway
20:35:56  <indutny>ok, I'm going to look into it tomorrow
20:36:05  <indutny>time to continue working on Candor now :P
20:36:31  <indutny>ah
20:36:39  <indutny>so I know why it isn't working now :P
20:36:43  <isaacs>indutny: yeah, you can see if it you set the title to something short
20:36:55  <indutny>strncpy fills the rest of string with zeroes
20:36:59  <indutny>while uv_strlcpy doesn't
20:37:06  <indutny>so that's it
20:37:08  <isaacs>./node then do `process.title = 'xx'` and then in another session, ps aux | grep xx
20:38:09  <indutny>we should change it back to strncpy
20:38:21  <indutny>as it was here https://github.com/joyent/libuv/pull/492/files#L5R83
20:38:30  <TooTallNate>why do the remaining bytes need to be null?
20:38:38  <indutny>actually, only set title should be changed
20:38:42  <indutny>TooTallNate: who knows
20:39:03  <indutny>TooTallNate: may be ps is just printing strings of fixed size on some platforms
20:39:06  <indutny>it really depends
20:39:20  <indutny>isaacs: I don't have access, so we can either wait for tomorrow
20:39:27  <indutny>or you can push this change yourself
20:39:36  <isaacs>indutny: it works on os x
20:39:40  <indutny>yes, I know
20:39:45  <indutny>platform-dependent bug
20:39:53  <indutny>probably works on other unixes too
20:40:01  <isaacs>indutny: you've got a change you can push to your fork?
20:40:18  <indutny>isaacs: may be tomorrow?
20:40:29  <indutny>It's late in Moscow now
20:40:30  <isaacs>indutny: if bnoordhuis changed it from strncpy to uv_strlcpy, then presumably there's a reason of some sort
20:40:36  <indutny>well
20:40:41  <isaacs>we can do it tomorrow or later, whenever he's online.
20:40:42  <indutny>you can search irc logs
20:40:48  * ericktjoined
20:40:49  <indutny>there was like
20:41:01  <indutny>"oh, we're using strncpy... not good, we have uv_strlcpy for that stuff"
20:41:11  <indutny>nothing really sophisticated
20:41:18  <indutny>but yeah, waiting for tomorrow seems to be reasonable for me
20:41:20  <isaacs>well, strncpy has other issues on some platforms, i believe
20:41:45  <isaacs>don't recall why.
20:42:12  <isaacs>my concern, though, is that if this is a bug in uv_strlcpy, and we're using that somewhere else, then we probably have bugs elsewhere.
20:42:15  <isaacs>better to fix it at the root.
20:42:32  <isaacs>indutny, ryah: thanks for finding it :)
20:42:44  <indutny>well, that's not a bug
20:42:49  <indutny>that's how it inteded to work
20:42:59  <indutny>and it's just not suitable for changing title
20:43:07  <indutny>as we're hijacking char** argv passed to object
20:43:13  <indutny>and there're no documented API for that
20:43:50  <indutny>so if system thinks that there should be NULLs at the end of the string - we should put them there
20:43:56  <indutny>otherwise we'll be borked
20:44:39  * EhevuTovjoined
20:46:30  <isaacs>indutny: it looks like we're putting a " " at the end of the string
20:46:36  <indutny>no way
20:46:41  <indutny>look at the uv_strlcpy code
20:46:47  <indutny>it's always putting "\0"
20:46:50  <isaacs>oh, ok
20:46:51  <indutny>or
20:46:54  <indutny>there is a compiler bug
20:46:59  <indutny>:D
20:47:05  <isaacs>but we're not overwriting them all with \0's?
20:47:17  <indutny>we're not overwriting rest with \0's, right
20:47:51  <indutny>well, actually, I suppose that ps is using title length to output it
20:48:00  <indutny>and as we hijacked it - title length wasn't changed
20:48:09  <indutny>while contents has less length
20:48:15  <isaacs>ryah: that net test failure, i can't seem to reproduce
20:48:25  <isaacs>ryah: oh, wait, nvm, i only tried on CentOS, not on ubuntu
20:48:32  * philips_quit (Excess Flood)
20:49:46  * mikealquit (Quit: Leaving.)
20:50:57  <isaacs>indutny: https://github.com/joyent/node/issues/3726
20:51:06  <isaacs>hm, yeah, same on ubuntu
20:51:11  <isaacs>no net failure, just the proctitle thing
20:51:47  <indutny>ok
20:51:54  <indutny>you probably have new kernel to
20:52:11  * philips_joined
20:52:18  <indutny>what's your uname -v
20:54:10  <indutny>time to sleep
20:54:11  <indutny>:)
20:54:11  <indutny>ttyl
21:03:10  * hzquit (Ping timeout: 272 seconds)
21:03:36  * felixgequit (Quit: felixge)
21:08:30  * hzjoined
21:12:29  * hzquit (Read error: Connection reset by peer)
21:13:27  * hzjoined
21:14:05  <TooTallNate>indutny: sleep good
21:15:16  * hzquit (Client Quit)
21:15:51  * hzjoined
21:16:38  * felixgejoined
21:16:38  * felixgequit (Changing host)
21:16:38  * felixgejoined
21:19:56  * felixgequit (Client Quit)
21:23:37  * beachdogquit (Quit: beachdog)
21:28:17  * felixgejoined
21:28:17  * felixgequit (Changing host)
21:28:17  * felixgejoined
21:29:45  * felixgequit (Client Quit)
21:32:07  * felixgejoined
21:32:07  * felixgequit (Changing host)
21:32:08  * felixgejoined
21:32:10  * EhevuTovquit (Quit: This computer has gone to sleep)
21:32:34  * felixgequit (Client Quit)
21:33:17  * `3rdEdenquit (Quit: Leaving...)
21:33:33  * hzquit
21:34:48  * TooTallNatequit (Read error: Operation timed out)
21:41:35  * beachdogjoined
21:42:22  * rendarquit
21:43:24  * EhevuTovjoined
21:44:14  * TooTallNatejoined
21:48:54  * bnoordhuisjoined
22:00:38  * felixgejoined
22:00:38  * felixgequit (Changing host)
22:00:39  * felixgejoined
22:00:41  * c4miloquit (Remote host closed the connection)
22:16:47  * `3rdEdenjoined
22:24:14  * felixgequit (Quit: felixge)
22:24:58  * `3rdEdenquit (Quit: Leaving...)
22:27:53  <CIA-108>libuv: Ben Noordhuis v0.8 * rb49d6f7 / src/unix/proctitle.c : unix: fix uv_set_process_title() - http://git.io/dLYpZA
22:29:58  * travis-cijoined
22:29:59  <travis-ci>[travis-ci] joyent/libuv#494 (v0.8 - b49d6f7 : Ben Noordhuis): The build is still failing.
22:29:59  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/a9f6f06feaf0...b49d6f7c3042
22:29:59  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1889907
22:29:59  * travis-cipart
22:30:39  * hzjoined
22:32:07  * felixgejoined
22:32:07  * felixgequit (Changing host)
22:32:07  * felixgejoined
22:32:53  * mikealjoined
22:35:30  <TooTallNate>bnoordhuis: was happening on linux actually
22:35:55  <bnoordhuis>TooTallNate: yes? odd
22:36:18  <TooTallNate>something strange with the way ps reads the titles or something
22:36:22  <TooTallNate>not sure
22:37:28  * loladiroquit (Ping timeout: 248 seconds)
22:41:30  * loladirojoined
22:49:09  * hzquit
22:57:15  <CIA-108>node: Dave Pacheco v0.8 * r648fdc5 / tools/genv8constants.py : tools: speed up genv8constants - http://git.io/KT2V5Q
22:58:16  <dap>bnoordhuis: Thanks!
22:59:06  <bnoordhuis>dap: likewise :)
23:00:47  * mikealquit (Quit: Leaving.)
23:07:24  * dapquit (Quit: Leaving.)
23:10:19  * dapjoined
23:14:21  * xaqquit (Remote host closed the connection)
23:17:36  <bnoordhuis>https://github.com/joyent/node/issues/3613#issuecomment-7052401 <- thoughts anyone?
23:18:51  * chobi_e_changed nick to chobi_e
23:22:09  * loladiroquit (Ping timeout: 265 seconds)
23:28:30  * chobi_echanged nick to chobi_e_
23:39:57  * paddybyersquit (Quit: paddybyers)
23:54:32  * felixgequit (Ping timeout: 265 seconds)
23:56:11  * dapquit (Quit: Leaving.)
23:56:47  * dapjoined
23:57:42  * beachdogquit (Remote host closed the connection)
23:57:53  * beachdogjoined