--- Log opened Mon Aug 20 00:00:51 2012
07:06 <@indutny> hey people
08:42 <@indutny> bweaver: 
08:42 <@indutny> oops
08:42 <@indutny> sorry
11:50 <@indutny> piscisaureus_: bert
11:50 <@indutny> hi
11:55 <@piscisaureus_> hi fedor
11:55 <@piscisaureus_> I am not on mac
11:56 <@indutny> piscisaureus_: well, when are you going to reboot?
11:57 <@indutny> I would like to ask you to finish reviewing that select patch
11:57 < bnoordhuis> piscisaureus_: uv_close(handle1, cb1); uv_close(handle2, cb2); <- all other things being equal, do the cbs run in order?
11:57 < bnoordhuis> i.e. first cb1, then cb2?
11:57 <@piscisaureus_> bnoordhuis: no, not even close
11:57 < bnoordhuis> yeah, i was afraid of that
12:03 < bnoordhuis> piscisaureus_: issue: uv_fs_poll_t embeds a timer
12:03 < bnoordhuis> that timer should be closed before the the parent handle is closed
12:03 < bnoordhuis> alternatively, i could just malloc the timer and be done with it
12:11 <@piscisaureus_> bnoordhuis: ah
12:11 < bnoordhuis> piscisaureus_: i think i'll go with mallocing the timer for now
12:11 <@piscisaureus_> bnoordhuis: or - you could could uv__handle_close from the close callback of the timer
12:12 <@piscisaureus_> bnoordhuis: that's probably easier even :-)
12:12 <@piscisaureus_> bnoordhuis: btw - you should review indutny's select patch
12:12 < bnoordhuis> piscisaureus_: that won't work for several reasons
12:12 <@piscisaureus_> bnoordhuis: several?
12:12 < bnoordhuis> well, at least two
12:13 < bnoordhuis> currently uv-unix runs close callbacks in lifo order
12:13 < bnoordhuis> i.e. last closed, first called
12:13 <@piscisaureus_> bnoordhuis: I know
12:14 < bnoordhuis> i could hack up something and work around that
12:14 < bnoordhuis> but that would break uv_is_closing()
12:14 < bnoordhuis> that's what you get for adding convenience methods...
12:14 < bnoordhuis> so malloc it is for now
12:14 <@piscisaureus_> bnoordhuis: so what you really want is not free() the uv_fs_poll_t before the timer is closed
12:14 <@piscisaureus_> anyway
12:14 <@piscisaureus_> whatever
12:14 <@piscisaureus_> you want
12:14 < bnoordhuis> i want
12:14 < bnoordhuis> and i want it now!
12:55 <@indutny> bnoordhuis: review!
12:55 <@indutny> select and async tls sessions
12:55 < bnoordhuis> indutny: later today
12:55 <@piscisaureus_> review review review
12:55 < bnoordhuis> busy fixing bugs
12:55 <@piscisaureus_> review
12:56 <@indutny> bugs bugs bugs
12:56 <@piscisaureus_> always those stupid bugs
13:11 <@piscisaureus_> indutny: bnoordhuis: does either of you understand why gcc does this? https://github.com/joyent/node/commit/e8fd808dfb0065466712e5115b25f2c6ce984c14#commitcomment-1733720
13:11 <@piscisaureus_> It seems to me that template functions are very commonly duplicated - it's not a good thing to complain about it.
13:12 <@indutny> hm...
13:12 <@indutny> this is odd
13:12 <@indutny> from first sight it looks like a gcc bug
13:12 < bnoordhuis> piscisaureus_: it probably means you're declaring XXX more than once
13:13 <@piscisaureus_> well, llvm has no problem with it and  msvc actually wants you to do this (but that is also related to how dlls work)
13:13 < bnoordhuis> or rather, defining
13:13 <@piscisaureus_> bnoordhuis: I know what it means
13:13 <@piscisaureus_> bnoordhuis: but this is sort of "expected" if you use templates right
13:14 <@piscisaureus_> if you have "template <typename T> void bar(T x) {}`
13:15 <@piscisaureus_> ... the compiler will compile an instatiation of this template into every object that uses that particular specialization
13:15 < bnoordhuis> so why do you need that?
13:16 <@piscisaureus_> bnoordhuis: because msvc otherwise starts whining
13:16 < bnoordhuis> isn't Persistent<> marked dllspec?
13:16 <@piscisaureus_> bnoordhuis: well, you can't mark a template for export
13:17 < bnoordhuis> indeed
13:17 < bnoordhuis> so why is it necessary?
13:18 <@piscisaureus_> bnoordhuis: well... msvc complains that if you mark node::ObjectWrap for dllexport then all the non-private embedded types also have to be dllexported
13:18 < bnoordhuis> oh, this is about the handle_ field?
13:19 <@piscisaureus_> bnoordhuis: yeah
13:19 <@piscisaureus_> bnoordhuis: and constructor_template
13:19 <@piscisaureus_> (and they are right btw :-))
13:44 <@piscisaureus_> bnoordhuis: so this timer closing thing... is that the cause of this "FSEvent memory corruption" bug?
13:53 < bnoordhuis> piscisaureus_: yes
13:53 <@piscisaureus_> ah
13:53 <@piscisaureus_> that one was pissing me off
14:33 < bnoordhuis> piscisaureus_: https://github.com/bnoordhuis/libuv/commit/58f152f <- can you try that on your windows computing device?
15:01 <@piscisaureus_> bnoordhuis: I will try
15:01 <@piscisaureus_> bnoordhuis: make test?
15:08 < bnoordhuis> piscisaureus_: wait one sec
15:09 < bnoordhuis> piscisaureus_: https://github.com/bnoordhuis/libuv/commit/447dab0
15:09 < bnoordhuis> and yes, make test
15:10 <@piscisaureus_> running
15:10 <@piscisaureus_> hmm
15:11 <@piscisaureus_> bnoordhuis:
15:11 <@piscisaureus_> [%  21|+  35|-   0]: tcp_unexpected_read
15:11 <@piscisaureus_> `tcp_unexpected_read` failed: exit code 3
15:11 <@piscisaureus_> Output from process `tcp_unexpected_read`:
15:11 <@piscisaureus_> Assertion failed in test\test-tcp-unexpected-read.c on line 110: ticks <= 10
15:11 <@piscisaureus_> =============================================================
15:11 <@piscisaureus_> [% 100|+ 159|-   1]: Done.
15:11 <@piscisaureus_> bnoordhuis: looks good
15:12 < bnoordhuis> cool
15:12 < bnoordhuis> re failing test, slowish computer?
15:12 <@piscisaureus_> bnoordhuis: not quite slow
15:12 <@piscisaureus_> bnoordhuis: this always fails on windows. On master I bumped the assert to <= 20
15:12 <@piscisaureus_> and that works
15:12 < bnoordhuis> ah okay
15:13 < bnoordhuis> the ticks == 10 was a guestimate
15:13 <@piscisaureus_> I saw that
15:13 <@indutny> bnoordhuis: piscisaureus_: anything I could do for you guys?
15:14 <@piscisaureus_> bnoordhuis: btw - it should me more "fastish" computer. You'll get more ticks if data is read from the socket in smaller chunks
15:14 <@piscisaureus_> indutny: sure. get me a coffee
15:14 <@piscisaureus_> indutny: -p
15:14 <@indutny> piscisaureus_: hangover again?
15:14 <@indutny> :D
15:14 <@piscisaureus_> indutny: yeah bnoordhuis is going to review your patches soon
15:14 <@indutny> good
15:14  * bnoordhuis will
15:15 <@indutny> I'm just searching for something to do meanwhile
15:15 <@indutny> and after
15:15 <@piscisaureus_> indutny: crack that crazy debugger bug?
15:15 <@indutny> aaah
15:15 <@indutny> that bug
15:15 <@indutny> ok
15:15 < bnoordhuis> which one? the failing test case?
15:16 <@piscisaureus_> bnoordhuis: https://github.com/piscisaureus/test-kill-inferior
15:16 <@piscisaureus_> bnoordhuis: crashes on mac
15:17 < bnoordhuis> piscisaureus_: crashes as in segfaults?
15:17 <@piscisaureus_> bnoordhuis: yup
15:17 < bnoordhuis> ai
15:17 < bnoordhuis> master or v0.8?
15:17 <@piscisaureus_> bnoordhuis: all
15:17 < bnoordhuis> ah okay
15:18 <@piscisaureus_> bnoordhuis: so, tl;dr - "A node process being debugged crashes when a child process is killed"
15:19 <@indutny> yeah, very interesting
15:19 <@piscisaureus_> my suspicion would be that somewhere within the debug handler in v8 EINTR isn't handled correctly
15:19 < bnoordhuis> that wouldn't surprise me
15:19 < bnoordhuis> i fixed a couple of similar v8 bugs a while ago
15:19 <@indutny> piscisaureus_: it's not really designed for that use :)
15:20 <@indutny> we're overloading it with a lot of stuff it's not supposed to handle
15:20 <@piscisaureus_> well, I don't know
15:20 <@indutny> though, no bugs - good code
15:20 <@piscisaureus_> I mean signals happen
15:20 <@piscisaureus_> a good unix program deals with them
15:20 <@piscisaureus_> Unix would be so nice if it had no signals
15:20 <@piscisaureus_> but something more sensible
15:21 <@indutny> what?
15:21 <@indutny> and you know it's legacy :)
15:21 <@piscisaureus_> structured exceptions :-p
15:22 <@piscisaureus_> and not using signals for exiting child processes
15:22 <@indutny> omg
15:22 <@indutny> well yeah
15:22 < travis-ci> [travis-ci] joyent/libuv#592 (v0.8 - 012cbda : Ben Noordhuis): The build was fixed.
15:22 < travis-ci> [travis-ci] Change view : https://github.com/joyent/libuv/compare/ce87b7e14cbf...012cbda719a1
15:22 < travis-ci> [travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/2178309
15:22 < bnoordhuis> \o/
15:22 <@indutny> signals are sent in many unexpected places
15:22 <@indutny> EPIPE is the most awful
15:22 <@indutny> bnoordhuis: ++
15:23 <@piscisaureus_> bnoordhuis: I am changing node to use uv_signal instead of ev_signal
15:23 <@piscisaureus_> just fyi
15:23 < bnoordhuis> piscisaureus_: good idea
15:23 < bnoordhuis> i was planning to do that :)
15:23 <@piscisaureus_> I am about to land it
15:35 <@indutny> ld: duplicate symbol v8::Persistent<v8::Object>::Persistent()in /Users/indutny/Code/indutny/node/out/Debug/obj.target/node/src/cares_wrap.o and /Users/indutny/Code/indutny/node/out/Debug/obj.target/node/src/fs_event_wrap.o
15:35 <@indutny> bnoordhuis: ^
15:35 < bnoordhuis> indutny: https://github.com/joyent/node/commit/e8fd808
15:35 <@indutny> I know
15:36 <@indutny> I've just reverted it
15:36 <@indutny> and it works
15:36 <@indutny> that's osx btw
15:36 < bnoordhuis> i know :)
15:36 <@piscisaureus_> let me guess - you're using gcc ?
15:36 <@indutny> yes
15:36 <@piscisaureus_> try llvm now
15:36 <@indutny> 4.2.1
15:36 < bnoordhuis> or gcc 4.5+
15:36 <@indutny> ok, how/
15:36 <@indutny> :D
15:37 <@indutny> CXX=llvm-g++ ?
15:37 < tjfontaine> ewww, clang++
15:38 <@piscisaureus_> reasonable
15:38 <@indutny> doing
15:38 <@piscisaureus_> bnoordhuis: so it was a gcc bug that was fixes in 4.5?
15:39 <@indutny> building v8
15:39 <@indutny> or openssl
15:39 <@indutny> not sure
15:39 <@indutny> a lot of stdout junk
15:42 <@indutny> em...
15:42 <@indutny> what's clang++?
15:43 < tjfontaine> llvm-g(cc|++) is gcc 4.2 with llvm codegen, clang(++) is a replacement toolchain (save for ld for now)
15:43 <@indutny> I've no clang++
15:43 <@indutny> probably old osx version
15:43 <@indutny> 10.6.8
15:43 < tjfontaine> what version of xcode?
15:43 <@indutny> 3.2.6
15:44 < tjfontaine> hmm I think it was introduced around then
15:44 <@indutny> idk
15:44 <@indutny> using lvm-g++ now for C++
15:44 <@indutny> and clang for C
15:44 <@indutny> I wonder if it'll work after all :D
15:45 < tjfontaine> it should its just that c++ in clang was young at that time
15:50 <@indutny> em...
15:51 <@indutny> it doesn't work with clang/lvm too
15:51 <@indutny> the same error
15:51 <@indutny> probably a linker bug
15:52 <@piscisaureus_> well, TooTallNate said that it caused no trouble for him with gcc-llvm
15:52 <@piscisaureus_> only with gcc-4.2
15:53 <@indutny> TooTallNate: defend yourself!
15:53 <@indutny> :)
15:53  * TooTallNate catching up with the backlog
15:53 <@indutny> how have you built it?
15:53 <@indutny> with gcc-lvm?
15:53 <@indutny> llvm*
15:54 <@TooTallNate> indutny: you're on snow leopard?
15:54 <@indutny> yes
15:54 <@TooTallNate> oh ya, i have a snow leopard VM i can fire up
15:58 <@TooTallNate> indutny: try to compile with CC=llvm-gcc CXX=llvm-g++
15:58 <@indutny> ok
15:58 <@indutny> that's what I did
15:58 <@indutny> what about LD?
15:58 <@TooTallNate> damn
15:58 <@TooTallNate> haha
15:58 <@TooTallNate> oh
15:58 <@TooTallNate> LD=llvm-g++
15:59 <@indutny> running it at the same time too
15:59 <@indutny> I was trying without LD
16:00 <@TooTallNate> in any case, let's just wrap that commit in a #ifndef like piscisaureus_ mentioned
16:00 <@indutny> sure
16:00 <@piscisaureus_> maybe just #ifdef _MSC_VER
16:00 <@indutny> yes
16:00 <@indutny> :)
16:00 <@indutny> probably GCC too
16:00 <@indutny> but not sure
16:01 <@piscisaureus_> I meant "only when _MSC_VER is defined|
16:01 <@TooTallNate> indutny: the original commit was to silence a windows warning
16:02 <@indutny> yes
16:02 <@indutny> I don't care
16:05 <@piscisaureus_> I'd do it but my working tree is dirty
16:06 <@piscisaureus_> I am tempted to use the github editor
16:06 <@isaacs> piscisaureus_: oh, no, don't do that
16:06 <@isaacs> piscisaureus_: maybe on your fork
16:06 <@piscisaureus_> isaacs is trying to troll me into doing it
16:06 <@isaacs> haha
16:07 <@isaacs> the github editor scares me
16:07 <@isaacs> it's so magical and unclear what it's actually doing, if it's committing, or sending a pull req, or what.
16:07 <@isaacs> and then yo uhave this commit that never saw your laptop
16:08 <@isaacs> i would actually love to go all linus on node and say that we can't accept any patches that aren't signed with a registered gpg key
16:08 < tjfontaine> amen.
16:09 < tjfontaine> that's part of my idea for git-dht actually
16:09 <@isaacs> except that signing patches is still a pita, since there's only very recently support for signing anything other than tags
16:09 < bnoordhuis> a slightly higher barrier to entry isn't an entirely bad idea imo
16:10 <@TooTallNate> indutny: did LD work?
16:11 < mmalecki> isaacs: please don't, that makes barrier of entry way higher
16:11 < creationix> bnoordhuis, could uv_poll be used to integrate with the android native activity system? https://gist.github.com/553308#file_native_activity.h
16:11 < mmalecki> I don't even have a gpg key
16:13 <@piscisaureus_> I am about to commit something edited in the github editor
16:13 <@piscisaureus_> and if it's any comfort
16:13 <@piscisaureus_> I will never do it again
16:14 <@isaacs> mmalecki: get on that.
16:14 <@isaacs> piscisaureus_: to where?
16:14 < bnoordhuis> piscisaureus_: git stash, you should try it
16:14  * deoxxa waits for the \r\n line endings
16:14 < bnoordhuis> creationix: what does it poll on?
16:14 <@isaacs> the github editor is for brogrammers who code on their ipads.
16:16 < travis-ci> [travis-ci] joyent/libuv#593 (master - 28ff142 : Ben Noordhuis): The build passed.
16:16 < travis-ci> [travis-ci] Change view : https://github.com/joyent/libuv/compare/201b8f935fc0...28ff1422e8f7
16:16 < travis-ci> [travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/2178948
16:16 <@TooTallNate> isaacs: hahaha, that was great
16:16 < creationix> bnoordhuis, I don't quite understand it
16:16 < creationix> I think it's how you get input events on android.  I read somewhere that people were running the event loop in another thread
16:20 < bnoordhuis> creationix: it doesn't look like it gives you anything to poll on
16:20 < bnoordhuis> more like the reverse, you can add stuff to poll on
16:21 < creationix> hmm, does libuv allow integrating that direction?
16:23 <@piscisaureus_> isaacs: https://github.com/joyent/node/commit/772b3bf4c806f881528718d1e0240392d0228c19
16:24 <@piscisaureus_> creationix: I suppose you could write a libuv backend for that
16:25 <@isaacs> piscisaureus_: only 12 characters too long on the subject line.  nicely done :)
16:26 <@isaacs> piscisaureus_: most github editor commits have 200-character headers.
16:26 <@piscisaureus_> isaacs: 50 characters is really too short
16:26 <@piscisaureus_> unless we go down the road of "Fix bug in xxx"
16:26 <@isaacs> i like 50 chars, but being descriptive is good.
16:27 <@isaacs> if there's a bug number in the title, i don't think it should count
16:27 <@indutny> TooTallNate: nope
16:27 <@TooTallNate> what's up with CIA?
16:27 <@piscisaureus_> To be honest: I think it's okay if it fits on one 80-char line when git log --oneline is used
16:28 < tjfontaine> TooTallNate: they changed some of their hosting, and have been down for most of the weekend
16:29 <@TooTallNate> tjfontaine: ahhh
16:30  * bnoordhuis is off to dinner
16:57 <@piscisaureus_> I really miss the CIA
16:58 <@piscisaureus_> (some alarm sounds in Langley, VA)
17:12 < bradleymeck> does support for specifying which outbound network interface to use exist?
17:12 <@piscisaureus_> bradleymeck: where?
17:12 <@piscisaureus_> bnoordhuis: in node or in libuv?
17:12 < bradleymeck> piscisaureus_: libuv, im fairly sure node doesnt
17:12 <@piscisaureus_> bradleymeck: you can uv_bind the socket to a particular ip
17:14 <@piscisaureus_> bradleymeck: support for specifying the interface using IPV6_UNICAST_IF and that sort of thing isn't there
17:14 <@indutny> yeah,
17:14 <@indutny> usually different interfaces have different IPs
17:14 <@indutny> otherwise it's generally quite a problem
17:15 < bradleymeck> yea, im just reading, trying to see if patching node makes sense even
17:16 < bradleymeck> we are going to want npm to be using a specific interface it looks like so might just have to write a small proxy, which would not be terrible, just not ideal
17:16 <@piscisaureus_> there are internal, undocumented interfaces for doing this
17:16 <@piscisaureus_> :-)
17:17 < bradleymeck> piscisaureus_: me no likey undocumented stuff if i can just write a proxy i know wont break
17:17 <@piscisaureus_> bradleymeck: good
17:20 < travis-ci> [travis-ci] joyent/libuv#595 (master - 8073a26 : Bert Belder): The build was broken.
17:20 < travis-ci> [travis-ci] Change view : https://github.com/joyent/libuv/compare/28ff1422e8f7...8073a2637f82
17:20 < travis-ci> [travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/2179181
17:21 < travis-ci> [travis-ci] joyent/libuv#595 (master - 8073a26 : Bert Belder): The build was broken.
17:21 < travis-ci> [travis-ci] Change view : https://github.com/joyent/libuv/compare/28ff1422e8f7...8073a2637f82
17:21 < travis-ci> [travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/2179181
17:22 <@piscisaureus_> The build was broken?
17:22 <@piscisaureus_> I'm sorry but the VM stalled during your build and was not recoverable.
17:22 <@piscisaureus_> We are continuosly working on test run stability, please email support@travis-ci.org if this issue persists.
17:22 <@piscisaureus_> Travis was broken!
17:26 <@isaacs> i got kinda fed up with travis lately, actually
17:27 <@isaacs> it reports test failures just sporadically enough that i stopped trusting them
17:27 < ik> man
17:27 < ik> fuck travis
17:27 < ik> you know!?
17:28 <@piscisaureus_> isaacs: what do you mean? Does it have too many false-positives or too many false-negatives?
17:39 <@isaacs> piscisaureus_: false negatives
17:39 <@isaacs> er, false "test failed"s
17:40 <@isaacs> the fourth or fifth time that i got the failure email, and went "oh shit!" and ran the tests a bunch of tiems, and found that it only failed because of some peculiar setup or network hiccup on travis's side, i stopped caring, and just started marking the emails as read automatically.
17:41 <@isaacs> it's a good idea, and great for fully-isolated unit-test style testing, but for something like npm, i really need functional tests that use the network, or else it's not actually a valid test of very much
17:41 <@isaacs> and i don't want to piece through which specific environment var is missing or wrong that makes me unable to access the $TMPDIR, etc.
17:42 < bradleymeck> isaacs: any complaint if i add localAddress to npm? it should fail silently on <0.8.0 for node but i think thats fine
17:52 <@isaacs> bradleymeck: you don't need my permission to add packages to npm, that's the whole point ;)
17:52 < bradleymeck> isaacs: i meant to the client
17:52 <@isaacs> ohhh, um... what for?
17:53 <@isaacs> like, send the localAddress in the package docs when you publish?
17:53  * isaacs confused
17:53 < bradleymeck> isaacs: we have an NIC to a private npm that we want to be sure npm sends using, so binding to that NIC's address would be needed
17:54 <@isaacs> bradleymeck: so, what would this entail, exactly
17:56 < bradleymeck> isaacs: https://github.com/isaacs/npm-registry-client/blob/master/lib/request.js#L192 needs to accept a localAddress option in opts somehow
17:57 <@isaacs> bradleymeck: does request do anything with localAddress?
17:57 < bradleymeck> isaacs: it has a closed issue about it, but i can check the code
17:57 <@isaacs> k
17:58 <@isaacs> i'm not opposed to it.  as long as it defaults to the current behavior that's fine
18:01 < bradleymeck> isaacs, it should, will send PR in a bit https://github.com/mikeal/request/blob/master/main.js#L92 https://github.com/mikeal/request/blob/master/main.js#L510
18:09 <@isaacs> bradleymeck: k.  add a `local-address` config in npmconf, and have npm-registry-client use that.  also update npm's lib/utils/fetch.js (still haven't abstracted that part out fully yet)
18:53 <@indutny> bnoordhuis: yt?
18:54 <@indutny> or still on a siesta? :D
20:00 <@bnoordhuis> indutny: here
21:37 < travis-ci> [travis-ci] joyent/libuv#596 (master - 5da380a : Fedor Indutny): The build was fixed.
21:37 < travis-ci> [travis-ci] Change view : https://github.com/joyent/libuv/compare/8073a2637f82...5da380a5ca7f
21:37 < travis-ci> [travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/2181934
21:57 <@piscisaureus_> hey bnoordhuis or isaacs
21:57 <@piscisaureus_> can either of you review https://github.com/joyent/node/pull/3890 ?
21:57 <@bnoordhuis> piscisaureus_: yes
22:03 <@piscisaureus_> also, any objections to node_signal_watcher, node_stat_watcher, node_io_watcher ?
22:08 <@piscisaureus_> bnoordhuis: seems like you have some painting to do in timer_wrap.cc :-p
22:09 <@bnoordhuis> piscisaureus_: ?
22:09 <@piscisaureus_> bnoordhuis: all the comments you had were from stuff I copied verbatim from timer_wrap.cc
22:09 <@bnoordhuis> oh right
22:09 <@bnoordhuis> i don't think i wrote that
22:10 <@piscisaureus_> yeah, but you want to pain the bikeshed :-p
22:10 <@bnoordhuis> it was that one guy, what's his name
22:10 <@piscisaureus_> bnoordhuis: btw - that said, I agree with all of your comments this time
22:10 <@piscisaureus_> (although neither of them are really a big deal)
22:11 <@piscisaureus_> btw - on windows I compile with C++ exceptions off so I wonder what would happen if new() fails
22:13 <@bnoordhuis> piscisaureus_: it'll still throw an exception
22:13 <@bnoordhuis> or maybe it aborts
22:14 <@bnoordhuis> gcc raises std::bad_alloc even with -fno-exceptions -fno-rtti
22:15 <@piscisaureus_> bnoordhuis: https://github.com/piscisaureus/node/commit/cd27d52a08b8e161eb2cf1e422fe5f9ba75f11f5
22:15 <@piscisaureus_> bnoordhuis: yeah, I suppose it would - don't know what would happen probably the program would crash
22:16 <@piscisaureus_> assert(x != NULL) after malloc is pretty pointless anyway :_)
22:17 <@bnoordhuis> piscisaureus_: lgtm
22:20 <@piscisaureus_> nice
22:20 <@piscisaureus_> so why are node_io_watcher and node_stat_watcher still around <-- isaacs ?
22:20 <@piscisaureus_> I am inclined to remove them
22:21 <@isaacs> bnoordhuis: weren't those for fs.watchFile?
22:21 <@isaacs> bnoordhuis: or did you port that to fs.watch()?
22:21 <@isaacs> or some js-only thing?
22:21 <@piscisaureus_> isaacs: node_stat_watcher was for fs.watchFile but no more (in master)
22:22 <@bnoordhuis> isaacs, piscisaureus_ : node_stat_watcher uses uv_fs_poll_t now
22:22 <@bnoordhuis> i.e. it backs fs.watchFile but with a libuv api
22:22 <@piscisaureus_> so what about node_io_watcher
22:22 <@bnoordhuis> can be nuked
22:22 <@isaacs> yeah, it looks like fs.watchFile is still using node_stat_watcher
22:22 <@piscisaureus_> I think nobody will miss node_stat_watcher and node_signal_watcher
22:22 <@piscisaureus_> yeah
22:22 <@piscisaureus_> ehh
22:22 <@isaacs> people will miss StatWatcher
22:23 <@isaacs>   this._handle = new binding.StatWatcher();
22:23 <@isaacs> (in fs.watchFile)
22:23 <@piscisaureus_> that's master?
22:23 <@piscisaureus_> odd
22:23 <@piscisaureus_> since this actually works on windows now, and node_stat_watcher does not
22:23 <@isaacs> i'm on 600a6468dc9067a358893f26ff46f1cd865f3c97
22:24 <@bnoordhuis> piscisaureus_: i rewrote node_stat_watcher to use uv_fs_poll_t a while ago
22:24 <@piscisaureus_> bnoordhuis: ah so it is still called node_stat_watcher.cc - heh
22:24 <@bnoordhuis> yeah, i didn't rename it
22:24 <@piscisaureus_> I expected it to live in fs_poll_wrap.cc or something
22:24 <@bnoordhuis> but feel free to
22:25 <@piscisaureus_> right ok
22:25 <@piscisaureus_> so how many compiled addons still rely on node_io_watcher ?
22:25 <@bnoordhuis> no idea, don't care
22:25 <@piscisaureus_> isaacs: is there any way to grep compiled addons? That would be super nice? :-)
22:25 <@isaacs> no, there is not.
22:25 <@piscisaureus_> er, to grep npm packaes
22:25 <@isaacs> but yes, it would
22:25 <@isaacs> yeah
22:25 <@bnoordhuis> come to think of it, i don't think we ever exported the c++ api
22:25 <@isaacs> the thing is, they're gzipped tarballs, inside a couchdb
22:26 <@isaacs> but removing IOWatcher should be fine
22:26 <@bnoordhuis> only the js side as an undocumented IOWatcher class
22:26 <@isaacs> i don't htink we actually use it
22:26 <@piscisaureus_> I am pretty sure we don;t
22:26 <@isaacs> anyone doing that shoudl be using libuv for it anyway
22:26 <@piscisaureus_> ok, shedding it
22:26 <@piscisaureus_> yes
22:31 < travis-ci> [travis-ci] joyent/libuv#597 (master - 3c526cb : Ben Noordhuis): The build passed.
22:31 < travis-ci> [travis-ci] Change view : https://github.com/joyent/libuv/compare/5da380a5ca7f...3c526cb7e539
22:31 < travis-ci> [travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/2182552
22:33 <@piscisaureus_> so what's up with CIA exactly>
22:34 <@piscisaureus_> I really miss it :-(
22:35 <@bnoordhuis> it went on to a better place :(
22:36 <@isaacs> yeah, i dunno
22:36 <@isaacs> lemme look at it.  one se
22:36 <@isaacs> c
22:36 <@isaacs> hm, it's active, but there's no url or other info for it in github
22:37  * isaacs signing up for CIA...
22:38 <@isaacs> hm...
22:38 <@isaacs> "payload deployed"
22:40 <@isaacs> but no message
22:50 <@piscisaureus_> hm
22:50 <@piscisaureus_> cia.vc appears down from here
22:57 <@isaacs> yep, from here as well
22:58 <@TooTallNate> ya tjfontaine said it was something on their end
22:59 <@isaacs> k
22:59 <@isaacs> maybe someone in #node.js will build us a replacement
22:59 <@isaacs> (see /topic)
23:00 < GitHub40> [node] piscisaureus created test (+3 new commits): http://git.io/qEsZKg
23:00 < GitHub40> [node/test] process: use uv_signal instead of ev_signal - Bert Belder
23:00 < GitHub40> [node/test] Delete the old node_signal_watcher code - Bert Belder
23:00 < GitHub40> [node/test] Remove node_io_watcher - Bert Belder
23:00 <@piscisaureus_> isaacs: ^-- that works
23:01 <@piscisaureus_> isaacs: instead of using the cia hook, use the IRC hook
23:01 <@piscisaureus_> isaacs: it only does one channel tho
23:01 <@piscisaureus_> it's not as pretty as the CIA thing unfortunately
23:02 <@isaacs> yeah, it's not
23:02 <@isaacs> it's sad
23:02 <@piscisaureus_> isaacs: so that was my private repo (I have no admin rights for joyent/*)
23:02 <@piscisaureus_> will remove the hook now :-)
23:06 < travis-ci> [travis-ci] joyent/libuv#598 (master - d90102e : Ben Noordhuis): The build passed.
23:06 < travis-ci> [travis-ci] Change view : https://github.com/joyent/libuv/compare/3c526cb7e539...d90102e649e9
23:06 < travis-ci> [travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/2182817
23:22 < travis-ci> [travis-ci] joyent/libuv#601 (v0.6 - 2db0093 : Bert Belder): The build is still failing.
23:22 < travis-ci> [travis-ci] Change view : https://github.com/joyent/libuv/compare/0233b92eacc0...2db009368a3d
23:22 < travis-ci> [travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/2182940
23:23 <@piscisaureus_> bnoordhuis: does __read_mostly even matter one bit ?
23:23 <@bnoordhuis> piscisaureus_: maybe not but i'm still using it
23:24 <@bnoordhuis> i like that it puts everything in one data section, makes it easier to inspect in a debugger
23:25 <@piscisaureus_> bnoordhuis: http://thecodeartist.blogspot.nl/2011/12/why-readmostly-does-not-work-as-it.html
23:26 <@bnoordhuis> that's kind of old, __read_mostly is implemented on arm nowadays
23:27 <@bnoordhuis> but it could be a no-op for all i care, it's nice that it signals the intent of the variable
23:52 <@piscisaureus_> bnoordhuis: what options do you commonly use when running valgrind?
23:53 <@piscisaureus_> bnoordhuis: I want to generalize this libuv patch so we can do tests/run-tests --tool=valgrind
23:53 <@piscisaureus_> or something
23:53 <@piscisaureus_> bnoordhuis: I want to generalize this libuv patch so we can do tests/run-tests --tool=drmemory in my case :-)
23:56 <@bnoordhuis> piscisaureus_: usually something like --leak-check=full --trace-origins=yes --num-callers=32
23:56 <@bnoordhuis> oh, and --quiet
23:57 <@bnoordhuis> okay, off to bed - sleep tight
--- Log closed Tue Aug 21 00:00:57 2012