00:00:00  * ircretaryquit (Remote host closed the connection)
00:00:08  * ircretaryjoined
00:00:52  <MI6>libuv-master-gyp: #228 FAILURE windows-x64 (4/196) windows-ia32 (4/196) http://jenkins.nodejs.org/job/libuv-master-gyp/228/
00:06:48  * dominictarrquit (Quit: dominictarr)
00:19:26  <trevnorris>othiym23: ping, can run your tests when ready
00:22:20  * dap_quit (Quit: Leaving.)
00:24:54  * dominictarrjoined
00:25:36  * Ralithquit (Ping timeout: 245 seconds)
00:26:11  <othiym23>trevnorris: probably will have to wait until later tonight, furiously throwing together slides for pdxnode tonight
00:26:24  <trevnorris>othiym23: no worries, it's nothing urgent.
00:26:25  <othiym23>gonna show them all CLS and addAsyncListener
00:27:31  <trevnorris>hah, great.
00:27:50  <Domenic_>trevnorris: I believe my version had a leak, but indutny refactored it to not have a leak. It sounds like the WeakObject refactor reintroduced the leak?
00:29:55  <trevnorris>Domenic_: Hm. Not sure. that's what i'm trying to figure out. what I don't get is that when you call ObjectWrap::Wrap() it makes the Persistent weak and calls the destructor during gc
00:30:20  <trevnorris>Domenic_: which is how WeakObject also works, but for some reason the Persistent isn't weak when the destructor gets called.
00:32:07  * jxsquit (Quit: ZNC - http://znc.in)
00:36:55  * pachetquit (Read error: Connection reset by peer)
00:37:26  * inolenjoined
00:38:26  * inolenquit (Client Quit)
00:43:24  <Domenic_>trevnorris: given that i never actually produced a non-leaky implementation i think indutny is probably the one to talk to about this :)
00:44:29  * EhevuTovquit (Quit: This computer has gone to sleep)
00:48:13  <trevnorris>son of a bitch. this must have something to do with how values are passed by value, not by reference.
00:49:06  <trevnorris>there ,you little bastard...
00:49:20  <trevnorris>Domenic_: it has nothing to do w/ your code. it has to do w/ how v8 handles persistents.
00:53:33  <trevnorris>DAMN YOU V8!!!
00:53:33  <LOUDBOT>MAYBE ITS SUPPOSED TO BE LIKE A FAMILY DINNER
00:57:14  <trevnorris>Domenic_: so, the reason it failed in your code was because contextify was always the first thing to run. sorry about the confusion. :P
00:59:51  * jmar777joined
01:01:29  * amartensquit (Quit: Leaving.)
01:07:05  * inolenjoined
01:10:29  * Ralithjoined
01:11:57  * dominictarrquit (Quit: dominictarr)
01:13:08  * jxsjoined
01:13:50  * brsonquit (Ping timeout: 268 seconds)
01:15:13  * brsonjoined
01:35:44  * jxsquit (Quit: bye)
01:36:16  * dominictarrjoined
01:36:33  * jxsjoined
01:36:34  * wwicksjoined
01:37:04  * TooTallNatequit (Quit: Computer has gone to sleep.)
01:38:17  * abraxasjoined
01:40:09  * kazuponjoined
01:41:50  * kazuponquit (Remote host closed the connection)
01:55:26  * kazuponjoined
02:01:32  * wolfeida_joined
02:02:41  * wolfeidauquit (Ping timeout: 245 seconds)
02:56:53  * octetcloudquit (Quit: WeeChat 0.4.2)
03:03:36  * dominictarrquit (Quit: dominictarr)
03:06:58  * piscisaureus_joined
03:13:03  * TooTallNatejoined
03:13:24  * TooTallNatequit (Client Quit)
03:29:52  * mcavagequit (Remote host closed the connection)
03:30:18  * mcavagejoined
03:31:02  * mcavage_joined
03:31:02  * mcavagequit (Read error: Connection reset by peer)
03:33:05  * brsonquit (Quit: leaving)
03:40:35  * jmar777quit (Remote host closed the connection)
03:41:14  * jmar777joined
03:42:03  * Benviejoined
03:45:58  * jmar777quit (Ping timeout: 265 seconds)
03:48:39  * Benviequit (Ping timeout: 256 seconds)
03:55:48  * kazupon_joined
03:57:31  * kazuponquit (Ping timeout: 245 seconds)
03:58:09  * kazuponjoined
03:58:52  * bajtosjoined
04:01:04  * kazupon_quit (Ping timeout: 246 seconds)
04:04:49  * c4milojoined
04:08:53  * kazuponquit (Remote host closed the connection)
04:09:20  * kazuponjoined
04:10:46  <piscisaureus_>isaacs: you around?
04:11:22  <tjfontaine>how's bert this evening/morning?
04:11:31  <piscisaureus_>I'm fine
04:12:19  <tjfontaine>what are you up to?
04:12:20  * mcavage_quit (Remote host closed the connection)
04:12:33  * dap_joined
04:12:38  <piscisaureus_>So remember tasks and what I've been talking about
04:12:46  * mcavagejoined
04:12:49  <tjfontaine>indeed
04:12:51  <piscisaureus_>what if I could just add those features to Domains?
04:13:04  <tjfontaine>sounds interesting
04:13:31  <tjfontaine>do you have a vision for it so far?
04:13:39  <piscisaureus_>Close
04:14:02  <piscisaureus_>Domains need to be implicitly added to other domains
04:14:05  * kazuponquit (Ping timeout: 272 seconds)
04:14:41  <piscisaureus_>also domains need to be able to "end" in a succesful state
04:15:07  <piscisaureus_>and they need to not only capture async operations but also remove them when they are done
04:15:10  * bajtosquit (Quit: bajtos)
04:15:37  <piscisaureus_>I think we could then make domain.dispose() work with well-defined semantics
04:17:26  <piscisaureus_>tjfontaine: I don't like the idea of maintaining a fork of node for too long so I'm trying to see a path for getting it into core
04:17:34  <piscisaureus_>without pissing people off
04:17:37  * mcavagequit (Ping timeout: 272 seconds)
04:26:13  <tjfontaine>piscisaureus_: right, but I'm not sure that can happen for 1.0, is that what your expectations would be?
04:26:23  <tjfontaine>piscisaureus_: there's no reason it needs to be a fork, it could be a branch :)
04:26:29  <piscisaureus_>tjfontaine: *shrug* :)
04:26:51  <tjfontaine>piscisaureus_: but right having to maintain the idea separate from node upstream is a pain indeed
04:27:11  <piscisaureus_>tjfontaine: I'm thinking maybe it could be a flag
04:27:21  <piscisaureus_>tjfontaine: like we had in the past with --uv
04:27:31  <piscisaureus_>Before you were around :)
04:27:45  <tjfontaine>I was around during 0.5 you just didn't know it :)
04:27:55  <piscisaureus_>hehe
04:28:14  <piscisaureus_>yes you got the timeline right
04:28:59  <tjfontaine>can you verify something for me? I'm going to have to step out for a bit
04:29:07  <tjfontaine>but I'd like a second opinion
04:29:13  <piscisaureus_>sure
04:32:13  * kazuponjoined
04:42:18  * defunctzombiechanged nick to defunctzombie_zz
04:56:20  * AvianFlu_quit (Remote host closed the connection)
04:57:03  * AvianFlujoined
05:06:41  * piscisaureus_quit (Ping timeout: 245 seconds)
05:09:09  * dap_quit (Quit: Leaving.)
05:13:19  * mcavagejoined
05:20:51  * mcavagequit (Ping timeout: 272 seconds)
05:25:22  * kazuponquit (Remote host closed the connection)
05:25:50  * kazuponjoined
05:30:27  * kazuponquit (Ping timeout: 252 seconds)
05:35:19  * kazuponjoined
05:43:37  * paddybyersquit (Quit: paddybyers)
05:44:55  * paddybyersjoined
06:06:55  * AvianFlu_joined
06:10:55  * AvianFlu_quit (Ping timeout: 246 seconds)
06:28:02  * c4miloquit (Read error: Connection reset by peer)
06:32:38  * c4milojoined
06:36:34  * kazuponquit (Remote host closed the connection)
06:36:51  * kazuponjoined
06:41:19  * AvianFluquit (Remote host closed the connection)
06:41:48  * AvianFlujoined
06:46:37  <MI6>nodejs-v0.10-windows: #267 UNSTABLE windows-ia32 (9/602) windows-x64 (11/602) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/267/
06:48:07  * inolenquit (Quit: Leaving.)
06:51:36  * c4miloquit (Remote host closed the connection)
06:52:04  * c4milojoined
06:56:48  * c4miloquit (Ping timeout: 252 seconds)
07:09:56  * kazuponquit (Remote host closed the connection)
07:10:00  * Kakerajoined
07:10:24  * kazuponjoined
07:13:27  * kazupon_joined
07:14:08  * kazuponquit (Read error: Connection reset by peer)
07:16:09  * hzjoined
07:20:38  * hzquit (Disconnected by services)
07:20:41  * hzjoined
07:40:48  * dominictarrjoined
07:41:02  * AvianFluquit (Remote host closed the connection)
07:41:35  * AvianFlujoined
07:47:56  * mcavagejoined
07:52:51  * mcavagequit (Ping timeout: 272 seconds)
08:06:12  * dominictarrquit (Quit: dominictarr)
08:38:03  * bnoordhuisjoined
08:48:54  * mcavagejoined
08:55:19  * mcavagequit (Ping timeout: 265 seconds)
09:03:46  * Kakeraquit (Ping timeout: 245 seconds)
09:09:57  * wolfeida_changed nick to wolfeidau
09:11:44  * kazupon_quit (Remote host closed the connection)
09:21:25  * rendarjoined
09:24:35  * inolenjoined
09:25:50  * AvianFluquit (Remote host closed the connection)
09:26:18  * AvianFlujoined
09:27:14  * Chip_Zeroquit (Quit: Leaving IRC - dircproxy 1.2.0)
09:27:39  * Chip_Zerojoined
09:27:41  * Chip_Zeroquit (Client Quit)
09:28:30  * Chip_Zerojoined
09:30:37  <inolen>bnoordhuis: yes I did, but as usual, I managed to find my way ;)
09:32:03  <inolen>bnoordhuis: did anything come of the threadlet work for fs operations that I read about from late last year?
09:33:22  <rendar>inolen, was it a paper or an article?
09:33:50  <inolen>it was just mentioned in some github issues
09:34:57  <inolen>(https://github.com/joyent/libuv/issues/649)
09:40:28  <rendar>i see
09:41:14  <bnoordhuis>inolen: well... yes and no
09:41:26  <bnoordhuis>i did some work on it but it wasn't always a win
09:42:18  <bnoordhuis>i'm planning to revisit it someday when i've thought things through more
09:42:28  <inolen>I ask as I was doing some work on node-java, which I guess is in somewhat of a similar situation to the syscall bound operations. it's spinning up threads just to send calls through the JNI interface
09:44:05  <bnoordhuis>inolen: i guess it could work well for something like JNI
09:44:27  <bnoordhuis>the problem with i/o is that if you have, say, 128 threads all doing fstat(0), you get a lot of contention on the inode
09:44:46  <bnoordhuis>the problem becomes worse the more threads you have
09:45:25  <bnoordhuis>as long as those JNI calls aren't locking the world, you should be good though
09:45:47  <bnoordhuis>there's still the context switch overhead but that doesn't usually become an issue until you have thousands of threads
09:46:55  <bnoordhuis>oh, i did find out that the kernel's task scheduler in some kernel versions doesn't always work great when you have many threads
09:47:40  <bnoordhuis>it may be beneficial to pin threads to cores or the scheduler may be migrating them an insane number of times
09:48:47  <rendar>hmm why thousand of threads should do fastat, all in the same inode?
09:48:52  <rendar>fstat*
09:49:05  <bnoordhuis>oh, i'm not saying that's a common workload
09:49:12  <rendar>i see
09:49:21  <rendar>so you think if it may happen, in some situation
09:49:22  <bnoordhuis>but node is a general purpose platform so it's got to be prepared for things like that
09:49:57  <bnoordhuis>one situation where i could see that happening is where someone writes a web server that servers static files
09:50:17  <rendar>yeah right
09:50:21  <bnoordhuis>and checks with fstat(fd) if the file has changed
09:50:40  <rendar>in such a case, i think it'd be more convenient to use inotify
09:50:41  <bnoordhuis>did i just type 'servers static files'? serves!
09:50:55  <bnoordhuis>oh well, inotify is not infinitely scalable
09:51:03  <bnoordhuis>the max number of watchers is usually quite limited
09:51:10  <rendar>oh..really? why?
09:51:26  <inolen>bnoordhuis: I see. I'd just seen the reduced stack size comment and thought there may be _some_ advantage. Worthy of swapping out a call to uv_queue_work if it existed at least that is ;)
09:51:37  <bnoordhuis>sysctl -a | grep fs.inotify
09:51:37  <bnoordhuis>fs.inotify.max_queued_events = 16384
09:51:37  <bnoordhuis>fs.inotify.max_user_instances = 128
09:51:38  <bnoordhuis>fs.inotify.max_user_watches = 8192
09:51:45  <bnoordhuis>^ those are the defaults on my fedora system
09:52:04  <rendar>i see
09:52:32  * mcavagejoined
09:52:49  <bnoordhuis>and note that max_user means the total for all the user's processes :)
09:53:59  <rendar>so i could have only 128 inotify fds (or, 128 directories watching, since inotify is not recursive) in the OVERALL system?
09:54:15  <bnoordhuis>for one user, yes
09:55:00  <rendar>this kind of suck
09:55:15  <rendar>why so little? a server will need a lot of more than that
09:55:52  <bnoordhuis>because dirent watching requires a fair amount of resources
09:56:26  <bnoordhuis>if you could create an unlimited number of watchers, a single user could easily bring down the system
09:57:10  <rendar>hmm i see
09:57:46  <rendar>bnoordhuis, well, maybe you can set those sysctl value with a kind of echo "65535" >> /proc/somewhere/inotify/max_users
09:57:49  <rendar>?
09:57:58  <bnoordhuis>yeah, but only as root :)
09:58:28  <bnoordhuis>i think people would be fairly upset if node started mucking around with sysctls behind their back
09:59:51  * mcavagequit (Ping timeout: 260 seconds)
10:01:02  <rendar>bnoordhuis, yeah thats right
10:01:22  <rendar>bnoordhuis, well, the user has the powers also to modify that value for users, e.g. a "http" user on the system :)
10:01:30  <rendar>the root*
10:21:13  <indutny>bnoordhuis: hoya
10:21:16  <indutny>bnoordhuis: yt?
10:36:49  <bnoordhuis>indutny: ih
10:38:55  <indutny>bnoordhuis: how are you?
10:40:16  <bnoordhuis>indutny: no better or worse than usual. what about you?
10:40:21  <indutny>good too
10:40:25  <indutny>working on fsevents poller
10:40:35  <indutny>and I wanted to talk about it a bit
10:40:38  <indutny>do you have minute?
10:40:40  <bnoordhuis>okay
10:40:46  <bnoordhuis>60, 59, 58...
10:41:14  <indutny>haha
10:41:22  <indutny>so, thinking about performance
10:41:43  <indutny>it seems that the only way to keep it in O(n) (where n - is number of files in folders)
10:41:47  <indutny>is to store files in a hashmap
10:42:02  <indutny>otherwise it'll be O(n * n) on every timer event
10:42:09  <indutny>and what I'm thinking about is
10:42:10  <bnoordhuis>waa
10:42:12  <bnoordhuis>why?
10:42:13  <indutny>may be fuck it
10:42:22  <indutny>and just stay with what it is right now :)
10:42:24  <rendar>is fsevent like linux's inotify?
10:42:32  <indutny>yes, but worse
10:42:33  <indutny>:)
10:42:36  <rendar>eheh
10:42:40  <bnoordhuis>only works for directories - if it works
10:42:59  <rendar>i see, but is that one that came from bsds?
10:43:02  <indutny>bnoordhuis: so, its O(n*n) because I need to compare lists of files in a directory
10:43:05  <indutny>rendar: no
10:43:10  <indutny>rendar: its Apple child
10:43:13  <indutny>Apple's
10:43:15  <rendar>oh..i see
10:43:23  <indutny>bnoordhuis: what do you think?
10:43:25  <rendar>but can't you just use kqueue on apple?
10:43:30  <indutny>not for directories
10:43:36  <indutny>also
10:43:37  <bnoordhuis>kqueue sucks even worse for file watching...
10:43:42  <indutny>it doesn't support recursive changes
10:43:44  <rendar>oh boy
10:43:47  <bnoordhuis>and yes, we do use it for files
10:43:48  <indutny>i.e. in sub-directories
10:44:05  <indutny>bnoordhuis: so yay or nay to hashmaps?
10:44:12  <indutny>I can certainly do it
10:44:18  <bnoordhuis>indutny: well... what kind of lists are we talking here?
10:44:27  <indutny>I'm going to call uv_fs_readdir()
10:44:29  <bnoordhuis>i mean, what exactly do you need to compare?
10:44:30  <indutny>for each directory
10:44:34  <rendar>what about speaking bsd community to improve kqueue for files?
10:44:35  <indutny>and compare lists of files
10:44:38  <indutny>oh
10:44:43  <indutny>yeah
10:44:53  <indutny>oh
10:44:55  <indutny>wait
10:44:59  <indutny>I can just check timestamps
10:45:11  <indutny>but I still will need to have old timestamps
10:45:16  <indutny>and compare with them
10:45:22  <indutny>to figure out which files has changed
10:45:33  <indutny>anyway, I need to check against old list of files and timestamps
10:45:36  <indutny>is it clear?
10:45:53  <bnoordhuis>let me recap how i think it works
10:45:58  <bnoordhuis>you scan the directory for files first
10:46:22  <bnoordhuis>then you start polling the directory itself for mtime changes
10:46:35  <bnoordhuis>when you see a change, you scan the directory again
10:46:47  <bnoordhuis>and compare the new files list against the old one
10:46:51  <bnoordhuis>correct?
10:51:42  <indutny>oh
10:51:46  <indutny>yeah, that will work
10:52:24  <indutny>I didn't thought about directory's mtime
10:52:28  <indutny>s/thought/think
10:52:46  <bnoordhuis>okay. what was your approach?
10:52:48  <indutny>ok, what will you advise for comparing lists of files?
10:52:56  <indutny>bnoordhuis: almost the same, but with timer
10:53:07  <bnoordhuis>ah, right
10:53:28  <indutny>so, do we need hashmaps for that?
10:53:35  <bnoordhuis>well yeah, you'd still need a timer to poll the directory
10:53:37  <indutny>comparing N*N strings could be a bit painul
10:53:41  <indutny>painful
10:53:46  <indutny>bnoordhuis: yeah, I understand
10:53:47  <bnoordhuis>and no, hashmaps are not the right data structure for that
10:54:00  <indutny>ok, tell me more
10:54:21  <bnoordhuis>you probably want to view the file lists as sets and calculate the difference or the complement
10:54:29  <bnoordhuis>you can do that in linear time
10:54:34  <rendar>what about asking to bsd developers to improve kqueue for files?
10:55:01  <bnoordhuis>rendar: well, one of the issues with kqueue is that it's fd based rather than path based
10:55:15  <bnoordhuis>but that's kind of central to the whole kqueue api so i don't see that changing anytime soon
10:55:16  <rendar>oh
10:55:27  <indutny>bnoordhuis: well, it could be changed
10:55:28  <bnoordhuis>besides, there's not really such a thing as 'bsd developers' :)
10:55:31  <indutny>yeah
10:55:34  <indutny>that's the problem
10:55:35  <bnoordhuis>you have freebsd, openbsd, netbsd, dragonflybsd
10:55:43  <indutny>everyone has their own shit to work on
10:55:46  <MI6>nodejs-v0.10: #1541 UNSTABLE smartos-x64 (7/602) smartos-ia32 (9/602) linux-x64 (2/602) osx-x64 (1/602) osx-ia32 (1/602) http://jenkins.nodejs.org/job/nodejs-v0.10/1541/
10:55:48  <rendar>what i mean is that sometimes OS developers do not put efforts and let library/application developers to pain
10:55:56  <indutny>rendar: they always do
10:56:04  * mcavagejoined
10:56:06  <rendar>yeah..
10:56:21  <indutny>bnoordhuis: sorry, I'm probably a bit stupid here
10:56:33  <indutny>bnoordhuis: what's underlying structure for sets?
10:56:35  <indutny>if not hashmaps
10:56:39  <bnoordhuis>rendar: the bsd landscape is too fragmented to get any work done in a reasonable amount of time
10:56:40  <rendar>what about a trie?
10:56:55  <indutny>I'm not sure how comparing two trees could be O(n)
10:56:58  <bnoordhuis>indutny: could be a tree, could be a sorted list
10:56:58  <rendar>bnoordhuis, i agree
10:57:11  <indutny>O(n * log n)
10:57:13  <indutny>that's what it is
10:57:27  <indutny>right?
10:57:40  <bnoordhuis>if you have to sort the list first, yes
10:57:46  <indutny>no, not because of this
10:57:58  <indutny>because for every item I'll need to do lookup in old sorted list
10:58:04  <indutny>n items
10:58:09  <indutny>log n - for lookup
10:58:13  <bnoordhuis>no no no
10:58:25  <bnoordhuis>you have two sets, the old file list and the new one
10:58:35  <indutny>ok
10:58:45  <rendar>well, a trie let's you to search "XYZ*" very fast in a set of strings, O(log n) where n is not the number of elements but the max_size of string inserted
10:58:46  <bnoordhuis>when you calculate the difference, you end up with the items that are in neither set
10:59:10  <bnoordhuis>the complement is the set of items that's in the new set but not the old set (or vice versa)
10:59:12  <indutny>and calculating difference will take O(n * log n)
10:59:19  <indutny>isn't it?
10:59:29  <bnoordhuis>no, it's on the order of 2 * n
10:59:37  <indutny>why?
10:59:45  <bnoordhuis>because :)
10:59:46  <indutny>you mean n*n ?
10:59:50  <bnoordhuis>look it up on wikipedia
11:00:19  <bnoordhuis>it's paramount that the lists are already sorted though
11:00:25  * mcavagequit (Ping timeout: 245 seconds)
11:00:37  <bnoordhuis>rendar: yeah, but the data in this case wouldn't be purely strings
11:00:41  <indutny>bnoordhuis: can you send me a link?
11:00:53  <bnoordhuis>okay, okay... lmfgtfy
11:01:02  <indutny>I believe that its O(n) only if set is represented as a hashmap
11:01:36  <bnoordhuis>http://www.sgi.com/tech/stl/set_difference.html <- section 'complexity'
11:02:03  <rendar>bnoordhuis, really? why? aren't just pathnames?
11:02:15  <bnoordhuis>rendar: also struct stat data
11:02:22  <rendar>oh...got it
11:02:34  <indutny>erm
11:02:46  <indutny>probably I am missing something
11:03:08  <bnoordhuis>no doubt. i'll help you find it
11:03:52  <indutny>I clearly see how its O(n) for hashmaps
11:04:02  <indutny>and can't figure out how it could be not worse for lists and trees
11:04:05  <bnoordhuis>for the average case, yes
11:04:18  <bnoordhuis>worst case performance for hashmaps is terrible though
11:04:25  <indutny>well, yes
11:04:39  <indutny>I agree
11:04:57  <indutny>its not that O(n * log n) looks terrible to me
11:04:58  <indutny>its ok
11:05:14  <indutny>I just want to be sure that I won't implement something inefficient :)
11:05:27  <indutny>so if you could share implementation details with me - I'd be really glad
11:05:43  <indutny>http://stackoverflow.com/questions/4642172/computing-set-intersection-in-linear-time
11:06:02  <indutny>also
11:06:12  <indutny>we don't need set difference
11:06:16  <bnoordhuis>it's probably going to be dominated by the actual directory scan
11:06:51  <indutny>we need http://mathworld.wolfram.com/SymmetricDifference.html
11:07:04  <bnoordhuis>calculating the difference or the complement afterwards should be relatively insignificant as long as you don't do anything stupid
11:07:04  <indutny>because both lists might contain elements that are not present in other set
11:07:11  <indutny>I agree
11:07:17  <indutny>but do you agree that it is O(n * log n)
11:07:32  <bnoordhuis>depends on whether the lists are already sorted
11:07:41  <indutny>they're
11:07:54  <indutny>that's how uv_fs_readdir returns them
11:08:00  <bnoordhuis>then you can calculate the difference in linear time
11:08:07  <indutny>how?
11:08:13  <bnoordhuis>i'm not sure uv_fs_readdir() actually guarantees any ordering
11:08:36  <bnoordhuis>that's a function of the underlying scandir() libc, er, function
11:08:43  <indutny> n = scandir(req->path, &dents, uv__fs_readdir_filter, alphasort);
11:08:48  <indutny>seems like it does
11:08:58  <bnoordhuis>oh indeed. man, i'm so forward thinking
11:09:11  <indutny>haha
11:09:24  <indutny>so, may you please describe your O(n) algorithm for that?
11:09:28  <indutny>difference
11:11:16  <bnoordhuis>indutny: http://stackoverflow.com/a/3252750 <- that's the basic algorithm
11:11:16  * inolenquit (Read error: Connection reset by peer)
11:11:41  <indutny>oooh
11:11:48  <indutny>thanks
11:12:02  <bnoordhuis>the alphasort that went before is of course O(n * log n) but there's no helping that
11:12:15  <indutny>yeah
11:12:17  <indutny>it'll happen anyway
11:12:23  <bnoordhuis>well... maybe we could radix sort that shizzle
11:12:37  <indutny>how would it help?
11:12:50  <indutny>its using quicksort internally anyway
11:12:52  <indutny>scandir()
11:12:57  <bnoordhuis>radix sort is O(kn) where k is the size of the key
11:13:05  <bnoordhuis>yeah, but in that case we wouldn't be using scandir()
11:13:24  <indutny>oh, that
11:13:29  <indutny>and what would you use instead?
11:13:40  <indutny>ah
11:13:41  <indutny>NULL
11:13:42  <indutny>:)
11:13:48  <bnoordhuis>nah, radix sort ain't gonna work if we want the filenames sorted lexicographical
11:13:49  <indutny>instead of alpha sort
11:14:03  <bnoordhuis>i was thinking maybe we could sort on the inode or something
11:14:09  <indutny>heh
11:14:12  <bnoordhuis>but then it's no longer sorted alphabetically of course
11:14:18  <bnoordhuis>okay, never mind that then :)
11:14:43  * abraxasquit (Remote host closed the connection)
11:14:50  <indutny>:)
11:16:57  <indutny>ok, seems like I've a plan
11:16:59  <indutny>thank you, man
11:17:02  <bnoordhuis>np :)
11:18:37  <rendar>but they must be sorted alphabetically?
11:19:03  <bnoordhuis>well... that's what uv_fs_scandir() does right now
11:19:16  <indutny>we'll figure it out later
11:19:25  <rendar>oh, to simulate its behavior then
11:19:32  <rendar>i see
11:44:28  * Kakerajoined
11:51:55  * dominictarrjoined
11:56:24  * mcavagejoined
12:01:19  <indutny>bnoordhuis: does uv_fs_poll works with directories?
12:01:58  <indutny>yeah, seems like so
12:03:59  * bnoordhuisquit (Ping timeout: 260 seconds)
12:04:01  * mcavagequit (Ping timeout: 272 seconds)
12:27:35  * wwicks_joined
12:28:46  * wwicksquit (Ping timeout: 245 seconds)
12:28:46  * wwicks_changed nick to wwicks
13:00:10  * mcavagejoined
13:05:17  * c4milojoined
13:06:16  * c4miloquit (Read error: Connection reset by peer)
13:06:45  * c4milojoined
13:07:47  * c4miloquit (Read error: Connection reset by peer)
13:08:08  * mcavagequit (Ping timeout: 240 seconds)
13:08:20  * c4milojoined
13:09:22  * c4miloquit (Read error: Connection reset by peer)
13:09:50  * c4milojoined
13:10:04  * bnoordhuisjoined
13:10:50  * c4miloquit (Read error: Connection reset by peer)
13:11:21  * c4milojoined
13:12:21  * c4miloquit (Read error: Connection reset by peer)
13:12:50  * c4milojoined
13:14:06  * c4miloquit (Read error: Connection reset by peer)
13:14:25  * c4milojoined
13:14:35  * bnoordhuisquit (Ping timeout: 248 seconds)
13:15:22  * c4miloquit (Read error: Connection reset by peer)
13:15:25  * bnoordhuisjoined
13:15:56  * c4milojoined
13:16:53  * c4miloquit (Read error: Connection reset by peer)
13:17:27  * c4milojoined
13:18:24  * c4miloquit (Read error: Connection reset by peer)
13:18:57  * c4milojoined
13:19:55  * c4miloquit (Read error: Connection reset by peer)
13:20:24  * c4milojoined
13:21:27  * c4miloquit (Read error: Connection reset by peer)
13:21:57  * c4milojoined
13:22:58  * c4miloquit (Read error: Connection reset by peer)
13:23:30  * c4milojoined
13:24:28  * c4miloquit (Read error: Connection reset by peer)
13:25:00  * c4milojoined
13:26:03  * c4miloquit (Read error: Connection reset by peer)
13:26:29  * c4milojoined
13:27:44  * c4miloquit (Read error: Connection reset by peer)
13:28:00  * c4milojoined
13:29:01  * c4miloquit (Read error: Connection reset by peer)
13:29:31  * c4milojoined
13:30:00  * wwicks_joined
13:30:13  * wwicksquit (Ping timeout: 248 seconds)
13:30:14  * wwicks_changed nick to wwicks
13:30:33  * c4miloquit (Read error: Connection reset by peer)
13:31:05  * c4milojoined
13:32:03  * c4miloquit (Read error: Connection reset by peer)
13:32:15  * vptrjoined
13:32:36  * c4milojoined
13:33:44  * c4miloquit (Read error: Connection reset by peer)
13:34:04  * c4milojoined
13:35:06  * c4miloquit (Read error: Connection reset by peer)
13:35:38  * c4milojoined
13:36:40  * c4miloquit (Read error: Connection reset by peer)
13:37:08  * c4milojoined
13:38:08  * c4miloquit (Read error: Connection reset by peer)
13:38:38  * c4milojoined
13:39:40  * c4miloquit (Read error: Connection reset by peer)
13:40:08  * c4milojoined
13:41:15  * c4miloquit (Read error: Connection reset by peer)
13:41:43  * c4milojoined
13:42:44  * c4miloquit (Read error: Connection reset by peer)
13:43:09  * c4milojoined
13:44:11  * c4miloquit (Read error: Connection reset by peer)
13:44:43  * c4milojoined
13:45:43  * c4miloquit (Read error: Connection reset by peer)
13:46:16  * c4milojoined
13:47:15  * c4miloquit (Read error: Connection reset by peer)
13:47:46  * c4milojoined
13:48:48  * c4miloquit (Read error: Connection reset by peer)
13:49:14  * c4milojoined
13:50:27  * c4miloquit (Read error: Connection reset by peer)
13:50:47  * c4milojoined
13:51:55  * c4miloquit (Read error: Connection reset by peer)
13:52:19  * c4milojoined
13:53:20  * c4miloquit (Read error: Connection reset by peer)
13:53:51  * c4milojoined
13:54:50  * c4miloquit (Read error: Connection reset by peer)
13:55:22  * c4milojoined
13:55:29  * pachetjoined
13:55:38  * pachetquit (Changing host)
13:55:38  * pachetjoined
13:56:24  * c4miloquit (Read error: Connection reset by peer)
13:56:55  * c4milojoined
13:57:08  * c4miloquit (Remote host closed the connection)
14:01:14  * bajtosjoined
14:04:01  * inolenjoined
14:04:54  * mcavagejoined
14:07:31  * defunctzombie_zzchanged nick to defunctzombie
14:09:47  * mcavagequit (Ping timeout: 272 seconds)
14:13:43  * inolenquit (Quit: Leaving.)
14:19:57  * piscisaureus_joined
14:29:44  * jmar777joined
14:37:37  * dominictarrquit (Quit: dominictarr)
14:47:47  * piscisaureus_quit (Ping timeout: 272 seconds)
14:49:41  * piscisaureus_joined
14:51:04  * wwicks_joined
14:51:33  * bajtosquit (Quit: bajtos)
14:52:53  * wwicksquit (Ping timeout: 248 seconds)
14:52:54  * wwicks_changed nick to wwicks
14:57:55  * piscisaureus_quit (Ping timeout: 272 seconds)
15:05:16  * mcavagejoined
15:05:20  * dominictarrjoined
15:09:12  * mcavagequit (Ping timeout: 240 seconds)
15:13:41  * AvianFlu_joined
15:14:15  * AvianFluquit (Disconnected by services)
15:14:17  * AvianFlu_changed nick to AvianFlu
15:14:44  * AvianFlu_joined
15:16:07  <MI6>joyent/libuv: Ben Noordhuis v0.10 * 1800efc : unix: fix non-synchronized access in signal.c - http://git.io/YJhI5Q
15:16:22  <bnoordhuis>now i need to merge v0.10 into master... :-(
15:16:48  <bnoordhuis>you owe me a beer, bertje
15:18:39  <MI6>libuv-v0.10: #120 UNSTABLE smartos (2/187) windows (5/188) http://jenkins.nodejs.org/job/libuv-v0.10/120/
15:20:11  <bnoordhuis>`git merge -s ours` is not really giving the desired results :(
15:21:15  <tjfontaine>ya, I haven't necessarily had much luck with that style of merge
15:22:40  * mcavagejoined
15:23:04  <MI6>libuv-v0.10-gyp: #84 FAILURE windows-x64 (4/188) windows-ia32 (3/188) http://jenkins.nodejs.org/job/libuv-v0.10-gyp/84/
15:24:07  * dap_joined
15:26:15  <MI6>nodejs-master: #628 UNSTABLE smartos-ia32 (7/648) smartos-x64 (10/648) osx-ia32 (1/648) http://jenkins.nodejs.org/job/nodejs-master/628/
15:29:42  <MI6>joyent/libuv: Ben Noordhuis master * fe4f062 : Merge remote-tracking branch 'origin/v0.10' (+4 more commits) - http://git.io/kUlr0w
15:29:57  <bnoordhuis>i'm reasonably certain i didn't botch that too bad
15:30:12  <bnoordhuis>confidence instilling, right?
15:31:36  <tjfontaine>heh
15:31:56  <tjfontaine>do we need to merge anything for libuv 0.8?
15:32:05  * wwicks_joined
15:32:33  <bnoordhuis>no, that didn't support signals
15:32:39  <bnoordhuis>*multi-loop signals
15:33:30  <tjfontaine>no I just meant in general, as I'm about to do a release ...
15:33:34  <tjfontaine>><
15:33:43  * defunctzombiechanged nick to defunctzombie_zz
15:33:47  * wwicksquit (Ping timeout: 248 seconds)
15:33:48  * wwicks_changed nick to wwicks
15:34:03  <bnoordhuis>oh, like that. guess the answer is still 'no', v0.8 is pretty much dead by now
15:34:08  <tjfontaine>nod
15:34:24  * bajtosjoined
15:35:02  <MI6>libuv-master: #289 UNSTABLE windows (3/196) smartos (3/195) http://jenkins.nodejs.org/job/libuv-master/289/
15:35:30  <MI6>libuv-master-gyp: #229 FAILURE windows-x64 (3/196) windows-ia32 (3/196) http://jenkins.nodejs.org/job/libuv-master-gyp/229/
15:45:17  <tjfontaine>bnoordhuis: do you have osx around to test the current state of v0.8?
15:46:32  * piscisaureus_joined
15:47:39  * bajtosquit (Quit: bajtos)
15:48:15  <MI6>libuv-node-integration: #274 UNSTABLE smartos-x64 (6/602) smartos-ia32 (6/602) http://jenkins.nodejs.org/job/libuv-node-integration/274/
15:51:45  * piscisaureus_quit (Ping timeout: 272 seconds)
15:54:58  <bnoordhuis>tjfontaine: yes. one sec
15:55:49  <tjfontaine>bnoordhuis: thanks, I'm seeing some segfaults when v8 is cleaning up, but indutny wasn't able to reproduce -- not that osx v0.8 is a priority platform
15:56:53  <bnoordhuis>running tests now. everything seems to be passing so far
15:57:08  <tjfontaine>ok, I guess my laptop is just special
15:57:11  <tjfontaine>https://gist.github.com/tjfontaine/7043511
15:57:22  <tjfontaine>thoughts on that one?
15:58:06  <bnoordhuis>looks like awesome code
15:58:10  <tjfontaine>:)
15:58:29  <bnoordhuis>if you're asking for a lgtm: lgtm
15:58:39  <tjfontaine>ok, thanks
15:58:46  <tjfontaine>pushing this and the other backport
15:59:14  <bnoordhuis>[02:34|% 100|+ 464|- 0]: Done
15:59:23  <tjfontaine>alright, I'm just really unlucky
15:59:34  <tjfontaine>https://gist.github.com/tjfontaine/7029498
15:59:40  <tjfontaine>is what I'm getting sometimes
16:00:18  <bnoordhuis>oh... never seen that before
16:00:31  <tjfontaine>ya it's pretty reliable on my laptop at the moment
16:00:54  <MI6>joyent/node: Timothy J Fontaine v0.8 * c421a5e : crypto: clear errors from verify failure (+2 more commits) - http://git.io/yJ5eBw
16:01:17  <tjfontaine>brb
16:04:44  <MI6>libuv-node-integration: #275 FAILURE http://jenkins.nodejs.org/job/libuv-node-integration/275/
16:07:54  * bnoordhuisquit (Ping timeout: 252 seconds)
16:09:10  * dominictarrquit (Quit: dominictarr)
16:09:15  * TooTallNatejoined
16:09:49  <indutny>tjfontaine: your CPU is rooted
16:13:08  * wwicks_joined
16:14:11  * wwicksquit (Ping timeout: 272 seconds)
16:14:11  * wwicks_changed nick to wwicks
16:15:54  * defunctzombie_zzchanged nick to defunctzombie
16:17:22  * amartensjoined
16:26:46  <MI6>nodejs-v0.8: #53 UNSTABLE osx-x64 (1/475) osx-ia32 (1/475) smartos-x64 (1/475) linux-x64 (1/475) smartos-ia32 (2/475) linux-ia32 (2/475) http://jenkins.nodejs.org/job/nodejs-v0.8/53/
16:28:13  * Benviejoined
16:33:50  * wwicksquit (Read error: Connection reset by peer)
16:34:12  * wwicksjoined
16:34:45  <tjfontaine>indutny: quite probably :)
16:35:03  * bajtosjoined
16:35:39  * piscisaureus_joined
16:54:10  * Ralithquit (Read error: Operation timed out)
17:11:37  * inolenjoined
17:15:08  * wwicks_joined
17:16:10  <tjfontaine>piscisaureus_: mind if I also backport https://gist.github.com/tjfontaine/7043511#file-handle-error-patch to v0.8?
17:16:19  <tjfontaine>or rather lgty? :)
17:16:31  <piscisaureus_>tjfontaine: yeah lgtm
17:16:42  <tjfontaine>k
17:17:03  <MI6>joyent/node: Ben Noordhuis v0.8 * 78fe7d0 : crypto: clear openssl error stack when handled - http://git.io/hY3-Tw
17:19:09  * wwicksquit (Ping timeout: 272 seconds)
17:19:09  * wwicks_changed nick to wwicks
17:20:42  * ryahjoined
17:21:04  <ryah>ddd7e04fd6442ae0edba6fd64dbe416be5bca86b build: switch to autotools
17:21:11  <ryah>-_-
17:21:19  <tjfontaine>it's not a switch, it's an addition
17:21:36  <tjfontaine>the hand grown makefile was unwieldy
17:21:39  <ryah>-_-
17:22:04  <ryah>the makefile should have been deleted
17:22:37  <tjfontaine>well that's a different conversation, but suffice it to say libuv's interest has grown beyond just node, and autotools is the easiest way to facilitate integration downstream
17:22:44  * AvianFluquit (Remote host closed the connection)
17:23:32  <ryah>fucking up my small efforts to evolve unix
17:23:42  <ryah>:P
17:24:58  <ryah>if you just tell rust (or whoever) to use gyp..
17:25:16  <ryah>then we contribute to the solution rather than the problem
17:25:22  <ryah>but whatever.
17:25:26  <tjfontaine>you're over estimating gyp frankly
17:25:38  <tjfontaine>but that's fine, are you coming back to volunteer? :)
17:25:39  * Ralithjoined
17:26:10  <ryah>gyp is the only good done in build systems in the last 15 years
17:26:23  <tjfontaine>gyp is not a build system, it's a meta system
17:26:25  * AvianFlujoined
17:26:42  <tjfontaine>it solves a particular classification of problems, it is hardly a panacea
17:27:01  <tjfontaine>but I really don't have time to be trolled by this
17:29:03  <ryah>so had i removed the legacy makefile after the gyp switch, we could have avoided pulling in autoconf and all of the horrors it implies? it was never the intention to maintain two build definitions
17:29:51  <tjfontaine>and in node we do only maintain one
17:30:20  <tjfontaine>but libuv's interest is larger than node, as it should be, and to facilitate its growth it's pretty trivial to just have support for the common denominator
17:30:44  <ryah>(sorry for speaking in absolutes - i don't actually care :))
17:30:52  <tjfontaine>demerit.
17:30:53  <ryah>who is demanding autoconf support?
17:31:18  <ryah>rust?
17:31:40  <ryah>why not have gyp generate autoconf support?
17:31:46  <ryah>that would be much better
17:31:53  <tjfontaine>you should contribute that patch to them
17:32:47  <piscisaureus_>trevnorris: hey
17:33:17  <piscisaureus_>trevnorris: hey
17:33:40  <piscisaureus_>trevnorris: is there a way with async listeners to know what the method name was
17:34:25  * st_lukejoined
17:34:29  <piscisaureus_>trevnorris: I am relying on async listener events to have parity e.g. for every "callback" an "after" is made
17:34:47  <piscisaureus_>trevnorris: but what I'm seeing is that sometimes 1 callback triggers multiple "after"s
17:35:18  <piscisaureus_>trevnorris: I suspect that it has to do with handle callbacks like timeout_cb and listen_cb and read_cb
17:35:27  <MI6>joyent/node: tjfontaine created branch v0.8.26-release - http://git.io/8n5cxQ
17:36:52  <ryah>just because things have been done in the past, eg having makefile install libraries, doesn't mean it should be continued. there are a great many things in unix that need to die.
17:37:20  <ryah>i thought it was universally understood that autoconf was among them - especially in this group
17:37:40  <tjfontaine>autotools are like democracy, everythign sucks, it's the least of all the shit
17:37:51  * st_lukequit (Remote host closed the connection)
17:38:06  <ryah>disagree. gyp is least of all the shit
17:39:19  <tjfontaine>and your opinion has been noted
17:40:20  * ryahquit (Quit: okay.)
17:40:29  <MI6>nodejs-v0.8: #54 UNSTABLE osx-x64 (1/475) osx-ia32 (2/475) smartos-x64 (4/475) linux-x64 (3/475) smartos-ia32 (2/475) linux-ia32 (3/475) http://jenkins.nodejs.org/job/nodejs-v0.8/54/
17:45:53  * st_lukejoined
17:53:47  * indexzerojoined
17:55:42  <MI6>libuv-master: #290 UNSTABLE linux (1/195) windows (3/196) smartos (3/195) http://jenkins.nodejs.org/job/libuv-master/290/
17:56:17  * bnoordhuisjoined
17:57:24  * brsonjoined
18:01:07  * brsonquit (Client Quit)
18:01:27  * brsonjoined
18:07:20  <MI6>libuv-node-integration: #276 FAILURE http://jenkins.nodejs.org/job/libuv-node-integration/276/
18:08:54  <tjfontaine>blah src\res\node_etw_provider.man : error : Failed to open file for write: 'g:\jenkins\workspace\nodejs-msi\1d92f228\Release\obj\global_intermediate\node_etw_providerTEMP.BIN' [g:\jenkins\workspace\nodejs-msi\1d92f228\node_etw.vcxproj]
18:08:58  <tjfontaine>MC : error : Failed creating provider resources for manifest ^ [g:\jenkins\workspace\nodejs-msi\1d92f228\node_etw.vcxproj]
18:09:10  <tjfontaine>hm I think we fixed that post v0.8
18:16:23  * wwicksquit (Read error: Connection reset by peer)
18:16:43  * wwicksjoined
18:25:41  * indexzeroquit (Quit: indexzero)
18:26:08  <tjfontaine>this is so frustrating
18:32:27  * bajtosquit (Quit: bajtos)
18:49:56  * pooyajoined
18:50:31  * inolenquit (Quit: Leaving.)
18:52:29  * st_lukequit (Remote host closed the connection)
18:55:08  * vptrquit (Ping timeout: 265 seconds)
18:57:09  * piscisaureus_quit (Ping timeout: 248 seconds)
18:58:30  * vptrjoined
19:04:08  <MI6>nodejs-master-windows: #421 UNSTABLE windows-x64 (24/648) windows-ia32 (22/648) http://jenkins.nodejs.org/job/nodejs-master-windows/421/
19:16:40  * abraxasjoined
19:18:26  * EhevuTovjoined
19:21:39  * abraxasquit (Ping timeout: 272 seconds)
19:29:12  * rendarquit (Ping timeout: 252 seconds)
19:37:25  * dshaw_joined
19:37:40  * FROGGSjoined
19:41:29  * piscisaureus_joined
19:51:11  <bnoordhuis>piscisaureus_: olla bertje, how's SF?
19:57:53  * AvianFlu_quit (Disconnected by services)
19:58:23  * AvianFlu_joined
20:00:45  * dshaw_quit (Quit: Leaving.)
20:03:52  * EhevuTovquit (Quit: This computer has gone to sleep)
20:04:53  * EhevuTovjoined
20:05:54  * indexzerojoined
20:06:56  * jmar777quit (Remote host closed the connection)
20:07:31  * jmar777joined
20:11:41  * jmar777quit (Ping timeout: 240 seconds)
20:15:08  <tjfontaine>bnoordhuis, piscisaureus_: doing the v0.10 libuv release, do you need anything extra for that?
20:19:56  <bnoordhuis>tjfontaine: define 'extra'?
20:20:35  <bnoordhuis>there are no pending patches or anything if that is what you mean
20:29:50  <piscisaureus_>bnoordhuis: hey. I made it
20:29:56  <piscisaureus_>bnoordhuis: but I'm in sm not sf
20:31:25  * bajtosjoined
20:38:53  * bajtosquit (Quit: bajtos)
20:41:37  * bajtosjoined
20:46:38  <tjfontaine>bnoordhuis: that's what I meant, ya, sorry for the ambiguity
20:50:34  <MI6>joyent/libuv: Timothy J Fontaine v0.10 * 939560b : Now working on v0.10.19 (+1 more commits) - http://git.io/nxCtOA
20:50:42  <MI6>joyent/libuv: tjfontaine created tag v0.10.18 - http://git.io/3ZsfIg
20:52:31  <MI6>joyent/node: Timothy J Fontaine v0.10 * 8fc48bc : uv: Upgrade to v0.10.18 - http://git.io/BhllEw
20:54:17  * bajtosquit (Quit: bajtos)
20:55:18  * bajtosjoined
21:02:57  <MI6>libuv-master-gyp: #230 FAILURE linux-x64 (1/195) windows-x64 (5/196) windows-ia32 (3/196) http://jenkins.nodejs.org/job/libuv-master-gyp/230/
21:03:30  <MI6>libuv-review: #78 FAILURE windows-ia32 (5/188) windows-x64 (5/188) linux-x64 (3/187) http://jenkins.nodejs.org/job/libuv-review/78/
21:05:06  * brsonquit (Read error: Operation timed out)
21:05:11  <MI6>libuv-v0.10: #121 UNSTABLE smartos (3/187) windows (6/188) http://jenkins.nodejs.org/job/libuv-v0.10/121/
21:05:18  * brsonjoined
21:06:09  <tjfontaine>https://gist.github.com/tjfontaine/7048276
21:06:22  <tjfontaine>oh there's one more fix I wanted to land
21:07:12  <MI6>libuv-v0.10-gyp: #85 FAILURE windows-x64 (3/188) windows-ia32 (4/188) osx-x64 (1/188) linux-ia32 (1/187) http://jenkins.nodejs.org/job/libuv-v0.10-gyp/85/
21:09:35  * piscisaureus_quit (Ping timeout: 245 seconds)
21:09:51  * AvianFlewjoined
21:09:54  * AvianFlewquit (Remote host closed the connection)
21:10:19  * bajtosquit (Ping timeout: 272 seconds)
21:10:40  * indexzeroquit (Quit: indexzero)
21:12:03  * bajtosjoined
21:14:07  * AvianFluquit (Ping timeout: 272 seconds)
21:15:31  <MI6>joyent/node: Timothy J Fontaine v0.10 * 5e41c02 : crypto: clear errors from verify failure - http://git.io/E_cEJw
21:15:41  <MI6>nodejs-master: #629 UNSTABLE smartos-ia32 (9/648) linux-x64 (1/648) smartos-x64 (11/648) osx-ia32 (1/648) http://jenkins.nodejs.org/job/nodejs-master/629/
21:16:12  <MI6>nodejs-v0.10: #1542 UNSTABLE smartos-x64 (6/602) smartos-ia32 (8/602) linux-x64 (1/602) linux-ia32 (1/602) http://jenkins.nodejs.org/job/nodejs-v0.10/1542/
21:16:55  * pooyaquit (Quit: pooya)
21:23:26  * hzquit
21:23:33  <MI6>nodejs-v0.10-windows: #268 UNSTABLE windows-ia32 (12/602) windows-x64 (12/602) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/268/
21:32:13  <MI6>nodejs-master-windows: #422 UNSTABLE windows-x64 (21/648) windows-ia32 (20/648) http://jenkins.nodejs.org/job/nodejs-master-windows/422/
21:36:57  <MI6>nodejs-v0.10: #1543 UNSTABLE smartos-x64 (8/603) smartos-ia32 (7/603) linux-x64 (1/603) linux-ia32 (1/603) osx-x64 (1/603) http://jenkins.nodejs.org/job/nodejs-v0.10/1543/
21:38:56  <MI6>joyent/node: tjfontaine created branch v0.10.21-release - http://git.io/jjih7Q
21:42:52  <MI6>nodejs-v0.10-windows: #269 UNSTABLE windows-ia32 (10/603) windows-x64 (7/603) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/269/
21:43:19  <MI6>libuv-node-integration: #277 UNSTABLE linux-ia32 (1/602) linux-x64 (1/602) smartos-x64 (5/602) smartos-ia32 (7/602) http://jenkins.nodejs.org/job/libuv-node-integration/277/
21:43:25  * dominictarrjoined
21:44:10  <trevnorris>afternoon
21:44:45  <tjfontaine>gday
21:45:20  <trevnorris>anything crazy going on?
21:45:42  <tjfontaine>just trying to get v0.8 to build the msi on windows, but that (knock on wood) should work this time
21:46:01  <trevnorris>awesome.
21:46:12  <tjfontaine>and v0.10 should be building
21:46:48  <trevnorris>awesome. stellar work tjfontaine
21:46:56  <tjfontaine>we shall see :)
21:47:31  <trevnorris>bnoordhuis: can you give me a clue what's going on here? https://github.com/trevnorris/node/commit/bbea5fc
21:47:57  <trevnorris>why does disposing one Persistent not make the other one empty, but they're both equal?
21:50:20  <MI6>joyent/node: Timothy J Fontaine v0.8.26-release * 6d391bb : fix pkg building - http://git.io/GuE2Tw
21:50:22  <MI6>joyent/node: tjfontaine created tag v0.8.26 - http://git.io/KaUdTg
21:51:17  * dominictarrquit (Quit: dominictarr)
21:52:33  * pooyajoined
21:52:34  <bnoordhuis>trevnorris: hrm. does that mean you have multiple copies of the same persistent?
21:53:16  * dominictarrjoined
21:54:01  <trevnorris>bnoordhuis: not that I could see. persistent() is stored on the class, and the persistent* passed is from MakeWeak
21:54:12  <trevnorris>so all I can figure is that MakeWeak passes back a copy
21:54:17  <bnoordhuis>trevnorris: oh, like that. sorry, wasn't following
21:54:50  <bnoordhuis>you call persistent_the_arg->Dispose() and you expect persistent()->IsEmpty() to be true?
21:55:05  <trevnorris>yeah, but it isn't
21:55:20  <MI6>joyent/node: Timothy J Fontaine v0.8 * 23c608a : Now working on 0.8.27 (+2 more commits) - http://git.io/QtHFOg
21:55:56  <bnoordhuis>indeed. v8 doesn't really know persistent_ exists so it can't update it
21:56:15  <bnoordhuis>you basically have a stale pointer
21:57:28  <trevnorris>ok, so is there a better solution than what I did in that commit?
21:58:53  <bnoordhuis>just ignore persistent_the_arg?
21:59:11  <trevnorris>um. more so calling self->persistent().Dispose();
21:59:19  <bnoordhuis>yeah
21:59:33  <trevnorris>like, do I need to call Dispose on both?
21:59:49  <bnoordhuis>both?
22:00:03  <bnoordhuis>you mean the arg and the member variable?
22:00:06  <trevnorris>yeah
22:00:29  <bnoordhuis>no. just ignore the arg
22:00:37  <trevnorris>ok cool. thanks.
22:03:32  * dominictarrquit (Quit: dominictarr)
22:09:56  * dap_quit (Ping timeout: 265 seconds)
22:10:07  * dap_joined
22:11:40  * c4milojoined
22:13:31  * c4miloquit (Read error: Connection reset by peer)
22:13:38  * c4milo_joined
22:14:34  * c4milo_quit (Read error: Connection reset by peer)
22:15:17  * c4milojoined
22:16:06  * c4miloquit (Read error: Connection reset by peer)
22:16:36  * c4milojoined
22:17:35  * c4miloquit (Read error: Connection reset by peer)
22:18:08  * c4milojoined
22:19:18  * c4miloquit (Read error: Connection reset by peer)
22:19:48  * c4milojoined
22:20:32  * AvianFlujoined
22:20:39  * c4miloquit (Read error: Connection reset by peer)
22:21:13  * c4milojoined
22:21:13  * TooTallNatequit (Quit: Computer has gone to sleep.)
22:22:12  * c4miloquit (Read error: Connection reset by peer)
22:22:43  * c4milojoined
22:23:41  * c4miloquit (Read error: Connection reset by peer)
22:24:13  * c4milojoined
22:24:27  * c4miloquit (Remote host closed the connection)
22:29:09  <MI6>node-review: #94 FAILURE osx-x64 (1/475) linux-ia32 (1/475) smartos-x64 (2/475) centos-x64 (4/475) linux-x64 (1/475) osx-ia32 (3/475) windows-ia32 (4/475) centos-ia32 (5/475) smartos-ia32 (3/475) http://jenkins.nodejs.org/job/node-review/94/
22:30:42  * AvianFlu_quit (Remote host closed the connection)
22:31:37  <MI6>nodejs-v0.8: #55 UNSTABLE osx-x64 (1/475) osx-ia32 (1/475) smartos-x64 (3/475) linux-x64 (2/475) smartos-ia32 (4/475) linux-ia32 (4/475) http://jenkins.nodejs.org/job/nodejs-v0.8/55/
22:32:03  * TooTallNatejoined
22:34:18  * AvianFluquit (Remote host closed the connection)
22:35:25  * AvianFlujoined
22:37:21  <MI6>joyent/node: tjfontaine created tag v0.10.21 - http://git.io/G9DwYw
22:40:53  <MI6>joyent/node: Timothy J Fontaine v0.10 * 85b2aae : Now working on 0.10.22 (+2 more commits) - http://git.io/PnPLaA
22:42:04  * dominictarrjoined
22:44:02  * paddybyersquit (Quit: paddybyers)
22:46:43  <MI6>joyent/node: Timothy J Fontaine v0.10 * 028e524 : blog: Post for v0.10.21 (+1 more commits) - http://git.io/57p_jw
22:56:50  <MI6>nodejs-v0.10-windows: #270 UNSTABLE windows-ia32 (10/603) windows-x64 (10/603) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/270/
22:57:52  <MI6>nodejs-v0.10: #1544 UNSTABLE smartos-x64 (5/603) smartos-ia32 (5/603) http://jenkins.nodejs.org/job/nodejs-v0.10/1544/
22:58:32  <MI6>node-review: #95 FAILURE osx-x64 (3/475) linux-ia32 (1/475) smartos-x64 (4/475) centos-x64 (5/475) windows-x64 (4/475) linux-x64 (1/475) osx-ia32 (1/475) centos-ia32 (5/475) smartos-ia32 (2/475) http://jenkins.nodejs.org/job/node-review/95/
22:59:32  * bajtosquit (Quit: bajtos)
23:02:18  <Ralith>any particular reason timerfd and signalfd aren't used by libuv on linux?
23:07:55  * bajtosjoined
23:13:21  * amartensquit (Quit: Leaving.)
23:15:54  <MI6>nodejs-v0.10-windows: #271 UNSTABLE windows-ia32 (11/603) windows-x64 (13/603) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/271/
23:16:37  * bajtosquit (Quit: bajtos)
23:16:37  <MI6>nodejs-v0.10: #1545 UNSTABLE smartos-x64 (8/603) smartos-ia32 (6/603) linux-x64 (1/603) linux-ia32 (4/603) http://jenkins.nodejs.org/job/nodejs-v0.10/1545/
23:18:34  * defunctzombiechanged nick to defunctzombie_zz
23:21:15  * bajtosjoined
23:21:57  * Kakeraquit (Ping timeout: 272 seconds)
23:22:35  * bnoordhuisquit (Ping timeout: 272 seconds)
23:24:11  <MI6>node-review: #96 UNSTABLE osx-x64 (1/603) smartos-x64 (6/603) centos-x64 (3/603) windows-x64 (11/603) linux-x64 (1/603) windows-ia32 (14/603) centos-ia32 (2/603) smartos-ia32 (5/603) http://jenkins.nodejs.org/job/node-review/96/
23:26:42  * ibobrikquit (Quit: ibobrik)
23:30:08  * vptrquit (Ping timeout: 240 seconds)
23:30:10  * dshaw_joined
23:39:31  * pooyaquit (Quit: pooya)
23:41:28  * dominictarrquit (Quit: dominictarr)
23:43:13  * dshaw_quit (Quit: Leaving.)
23:44:00  * dominictarrjoined
23:51:28  * dominictarrquit (Quit: dominictarr)
23:54:42  * jmar777joined
23:55:46  * jmar777quit (Remote host closed the connection)
23:56:23  * jmar777joined
23:57:00  * vptrjoined
23:58:48  <MI6>libuv-master-gyp: #231 FAILURE windows-x64 (3/196) windows-ia32 (3/196) http://jenkins.nodejs.org/job/libuv-master-gyp/231/