00:00:00  * ircretaryquit (Remote host closed the connection)
00:00:07  * ircretaryjoined
00:01:02  * kazuponquit (Ping timeout: 240 seconds)
00:01:54  * AvianFlujoined
00:03:27  <trevnorris>hueniverse1: cool.
00:04:04  * bnoordhuisquit (Ping timeout: 246 seconds)
00:04:06  * rendarquit
00:05:57  * AvianFluquit (Ping timeout: 248 seconds)
00:06:33  * sblomjoined
00:20:13  * loladiroquit (Quit: loladiro)
00:21:51  * FROGGSquit (Ping timeout: 245 seconds)
00:22:17  * loladirojoined
00:24:31  * c4milojoined
00:25:17  <trevnorris>awesome. only 62 more line changes before 6011 reaches 4,000 lines. I can do it! (maybe i'll just add some whitespace)
00:28:19  <othiym23>probably wouldn't be the first time
00:29:14  * c4miloquit (Remote host closed the connection)
00:29:31  * c4milojoined
00:29:59  <trevnorris>heh
00:30:36  <trevnorris>now if bert would just get on and tell me how he wants those hooks worked into the PR i'll do it.
00:30:52  <trevnorris>but that can be another PR later if he doesn't I guess.
00:30:54  <trevnorris>anyways
00:30:56  * trevnorris&
00:31:08  <trevnorris>.... oh LOUDBOT, that hurts :(
00:31:15  <othiym23>wow
00:31:16  <othiym23>such mean
00:35:17  * luxigo_joined
00:39:10  * julianduquequit (Read error: Operation timed out)
00:43:28  * mikealquit (Quit: Leaving.)
00:45:38  * superjoe30quit (Quit: Leaving)
00:51:29  * loladiroquit (Quit: loladiro)
00:51:48  * loladirojoined
00:53:26  * mikealjoined
00:54:00  * defunctzombie_zzchanged nick to defunctzombie
00:55:04  * dshaw_quit (Quit: Leaving.)
00:57:59  * kazuponjoined
01:05:12  * inolenjoined
01:08:36  * inolenquit (Client Quit)
01:10:02  * sblomquit (Ping timeout: 256 seconds)
01:10:03  * dshaw_joined
01:10:35  * mikealquit (Quit: Leaving.)
01:12:06  * mikealjoined
01:16:50  * mikealquit (Ping timeout: 256 seconds)
01:22:33  * amartensquit (Quit: Leaving.)
01:22:57  * amartensjoined
01:26:57  * c4miloquit (Remote host closed the connection)
01:27:34  * c4milojoined
01:27:50  * amartensquit (Ping timeout: 264 seconds)
01:29:04  * c4milo_joined
01:29:41  * c4miloquit (Read error: Connection reset by peer)
01:29:51  * AvianFlujoined
01:30:34  * st_lukejoined
01:31:59  * kazuponquit (Ping timeout: 272 seconds)
01:37:42  * abraxasjoined
01:39:03  * abraxasquit (Read error: Connection reset by peer)
01:39:30  * abraxasjoined
01:42:12  * abraxasquit (Remote host closed the connection)
01:42:12  * abraxas_joined
01:43:55  * inolenjoined
01:56:02  * st_lukequit (Read error: Connection reset by peer)
01:57:14  * philipsquit (Excess Flood)
01:58:09  * AvianFluquit (Remote host closed the connection)
01:59:35  * amartensjoined
02:00:26  * philipsjoined
02:27:59  * kazuponjoined
02:30:53  * defunctzombiechanged nick to defunctzombie_zz
02:44:07  * dshaw_quit (Quit: Leaving.)
02:51:08  * TooTallNatequit (Quit: ["Textual IRC Client: www.textualapp.com"])
02:51:09  * inolenquit (Quit: Leaving.)
02:52:39  * AvianFlujoined
02:53:44  * kazuponquit (Ping timeout: 256 seconds)
02:55:02  * julianduquejoined
03:12:02  * AvianFluquit (Remote host closed the connection)
03:25:58  * mcavagequit (Remote host closed the connection)
03:26:26  * mcavagejoined
03:27:08  * mcavage_joined
03:27:08  * mcavagequit (Read error: Connection reset by peer)
03:32:40  * brsonquit (Quit: leaving)
03:45:58  * loladiroquit (Quit: loladiro)
03:46:11  * defunctzombie_zzchanged nick to defunctzombie
03:48:30  * AvianFlujoined
03:48:56  * dshaw_joined
04:00:01  * mikealjoined
04:00:05  * kazuponjoined
04:00:07  * AvianFluquit (Remote host closed the connection)
04:02:05  * abraxas_quit (Remote host closed the connection)
04:03:54  * abraxasjoined
04:04:57  * mcavage_quit (Remote host closed the connection)
04:05:23  * mcavagejoined
04:06:27  * mikealquit (Quit: Leaving.)
04:09:05  * amartensquit (Quit: Leaving.)
04:09:40  * mcavagequit (Ping timeout: 256 seconds)
04:18:30  * mikealjoined
04:22:31  * abraxasquit (Remote host closed the connection)
04:23:58  * abraxasjoined
04:24:36  * defunctzombiechanged nick to defunctzombie_zz
04:25:30  * amartensjoined
04:27:17  * loladirojoined
04:32:05  * luxigo_quit (Ping timeout: 248 seconds)
04:45:22  * inolenjoined
04:45:25  * amartensquit (Quit: Leaving.)
04:54:06  * abraxasquit (Remote host closed the connection)
04:54:30  * octetcloudquit (Ping timeout: 240 seconds)
04:56:23  * amartensjoined
05:00:48  * kazuponquit (Read error: Connection reset by peer)
05:01:02  * kazuponjoined
05:07:02  * dshaw_quit (Quit: Leaving.)
05:15:59  * mcavagejoined
05:20:53  * mcavagequit (Ping timeout: 272 seconds)
05:29:43  * abraxasjoined
05:32:35  * dshaw_joined
05:33:26  * karupa64changed nick to karupanerura
05:44:55  * julianduquequit (Read error: Connection reset by peer)
05:52:31  * amartensquit (Quit: Leaving.)
05:55:50  * loladiroquit (Quit: loladiro)
06:18:52  * kazuponquit (Read error: Connection reset by peer)
06:19:15  * kazuponjoined
06:25:16  <trevnorris>how is everyone?
06:28:23  * sindresorhusquit (*.net *.split)
06:28:23  * chrisdickinsonquit (*.net *.split)
06:29:35  <groundwater_>you'er up late!
06:29:48  * chrisdickinsonjoined
06:30:54  <trevnorris>groundwater_: yeah. wanted to get some productive work done, then I ended up taking the time to kick some promise lovers in the nads.
06:31:16  <groundwater_>you're sounding like LOUDBOT now
06:31:16  <trevnorris>curse them for taunting me!
06:31:42  * trevnorrisprogrammer by day, LOUDBOT by night
06:31:46  <trevnorris>kinda like it
06:32:24  <trevnorris>groundwater_: i'm curious, what type of performance regression do people expect from long stack traces?
06:32:49  <groundwater_>well i just kinda did that as an exercise, but they are quite useful
06:33:02  <groundwater_>my first attempt seemed to be pretty poorly performing though
06:33:27  <groundwater_>i assume from creating all the objects holding the stack traces
06:33:27  * sindresorhusjoined
06:34:00  <trevnorris>groundwater_: here's a script I threw together: https://gist.github.com/trevnorris/7209654
06:34:20  <trevnorris>in the benchmarks worst it does is around -2x
06:34:21  <groundwater_>i think that's what i started from
06:34:28  <groundwater_>yah that's about what I got
06:34:58  <groundwater_>i have the exercise somewhere, i'll look for it later
06:35:10  <trevnorris>eh, no worries. not important
06:35:16  <trevnorris>have you looked at the test changes?
06:35:32  <groundwater_>anyways, i tried keeping track of whenever a leaf-node was created, i.e. an async callback that invoked no further async callbacks
06:35:51  <groundwater_>i wanted to reuse the objects it had created to hold the stack, to see if that would perform better
06:36:05  <groundwater_>the problem is that async callbacks can basically be called N times, where you don't know N
06:36:22  <groundwater_>then I kind of concluded the only true way to be sure was to use the GC
06:37:11  <trevnorris>ah, that thing. there's one other way. but it requires c++ stuffs, and another patch to my patch.
06:37:25  <trevnorris>that's something bert is wanting me to do
06:39:00  <trevnorris>groundwater_: and you can technically know N. since the asyncQueue is attached to the context you can get at the number of AsyncListeners that are about to run by doing the following in a before/after callback: context._asyncQueue.length
06:39:46  <groundwater_>what about for example, reading a socket
06:40:03  <trevnorris>how do you mean?
06:40:41  <groundwater_>unless you're paying attention to the "end" event, the 'on data' callback can be called any number of times
06:41:46  <trevnorris>groundwater_: ah yeah. that's something I've been wanting to explore. if you could be triggered on the AsyncWrap destructor then you'd know it's dead.
06:42:01  <groundwater_>yah, i figured that's what you guys were discussing
06:42:05  <trevnorris>unfortunately the object has been disposed by the time it reaches the AsyncWrap destructor
06:42:31  <groundwater_>on another note, i want to take a look at adding "async-listners" to event emitters, but with a different name
06:42:34  <groundwater_>same API, new name
06:42:54  <groundwater_>i think domains could use the API
06:43:01  <groundwater_>also CLS
06:43:55  * trevnorriswishes for the EventEmitter to burn in the fiery pits of hell
06:44:15  <groundwater_>heh, now you're definitely turning into LOUDBOT
06:44:27  <trevnorris>:)
06:44:40  <groundwater_>anyways, i realize nothing would be accepted unless it was as performant as now
06:45:01  <trevnorris>i had originally added hooks into the event emitter until I realized it's useless sugar that really has nothing to do with asynchronous events.
06:45:07  <trevnorris>eh, that's easy enough to do.
06:45:18  <trevnorris>the trick is to make sure that it costs nothing when it's not being used.
06:45:36  * inolenquit (Quit: Leaving.)
06:45:48  <groundwater_>i want to use the exact same API with slightly different semantics since it's not necessarily async
06:45:51  <trevnorris>the problem is that there's no way in hell you're going to get an extension to the EE API
06:46:00  <groundwater_>the "onAsync" becomes "onAddListner"
06:46:49  <groundwater_>really i just need to be able to run a before/after callback around each handler
06:46:55  <groundwater_>the rest can be monkeypatched
06:47:28  <groundwater_>i.e. emit -> before() handler_1() after() before() handler_2() after()
06:47:53  <groundwater_>the only way to do that now is to either wrap the handlers, or completely replace emit
06:48:04  <trevnorris>oh well it's fairly trivial to add an EventEmitter.addListener({ before: fn, after: fn }) and not have it affect performance.
06:48:50  <trevnorris>also EventEmitter.removeListener(key);
06:49:27  <trevnorris>just keep numeric keys that check the values in emit. that'll have next to no performance difference.
06:49:39  <trevnorris>so the only cost is when the callbacks are actually called.
06:50:22  <groundwater_>okay i'll try to put something together
06:50:35  <groundwater_>it's always easier to talk when there's code on the table
06:51:44  <trevnorris>almost have a patch ready
06:52:47  <groundwater_>oh what about catching when an emitter throws?
06:53:00  <groundwater_>i guess that should go through _fatalException
06:55:28  <trevnorris>heh, there you'll have to rely on asyncListener. once you try to let _fatalException know about the event that triggered it you're right back in the domain shitstorm.
06:57:08  <groundwater_>heh
06:58:15  <groundwater_>i can't wait
06:59:03  * paddybyersjoined
07:00:18  * inolenjoined
07:01:25  <trevnorris>groundwater_: super simple impl: https://gist.github.com/trevnorris/7210177
07:01:43  <trevnorris>that won't have noticeable performance impact.
07:02:09  <trevnorris>oh wait. one bug.
07:02:25  <groundwater_>that was fast
07:02:30  <trevnorris>ok, fixed
07:03:06  <trevnorris>heh, i spent weeks working on optimizing the event emitter. have it memorized.
07:04:47  <trevnorris>another minor fix.
07:04:52  <trevnorris>w/ handling error events.
07:05:09  <groundwater_>it's fucking weird looking at diffs of a diff file
07:05:16  <trevnorris>hah
07:05:22  <groundwater_>https://gist.github.com/trevnorris/7210177/revisions
07:05:39  <trevnorris>hahaha
07:05:47  <trevnorris>never even looked at that.
07:06:22  <groundwater_>i was curious what you changed
07:06:28  * FROGGSjoined
07:06:48  <groundwater_>i'm sure there's some algebraic theory behind this
07:07:10  <trevnorris>what you can do from your end is run the async listener in the before, then remove it in the after. this will catch any errors.
07:07:11  <trevnorris>heh
07:07:42  <trevnorris>async listeners catch errors that happen synchronously as well, so it'll catch anything that's immediately triggered by the emitted callback
07:08:36  <groundwater_>ahh!
07:08:51  <groundwater_>well in CLS they really just need to switch out the context object
07:09:16  <groundwater_>but yah, i think that may do it
07:09:51  <trevnorris>hah, i'm a moron. forgot to update the counter. one sec.
07:11:11  <trevnorris>groundwater_: want a neat trick? pass an array as the value when you create the listener, then just make the context you want as the zero index. then it's available in the error state w/o needing to create a new async listener everytime
07:11:23  <trevnorris>and since it happens synchronously there's no worries about a collision.
07:13:43  <trevnorris>groundwater_: ok, just tested it. the basics are working.
07:15:00  <groundwater_>i'm literally just sitting here watching netflix and playing iphone games
07:15:10  <trevnorris>hehe
07:15:17  <trevnorris>well, it's late.
07:15:18  <groundwater_>i'm gonna have to check this out tomorrow
07:15:25  <trevnorris>no worries.
07:15:34  <groundwater_>looks awesome tho
07:15:53  <trevnorris>thanks. but just be warned, I doubt it'll land in core.
07:16:35  <trevnorris>can try, and since it has no performance diff wont hurt there, but I had one heck of a time just getting EventEmitter.listenerCount() in
07:16:57  <groundwater_>maybe if domains can be removed from the EE code
07:17:15  <groundwater_>or if I bribe tjfontaine with enough gin
07:17:19  <trevnorris>haha
07:17:27  <trevnorris>well, then we'd have to add a hook to the EE constructor.
07:17:40  <trevnorris>because it has to know if theres an active domain alive.
07:17:52  <trevnorris>though, that'll actually be less expensive than what it's doing now.
07:17:59  <trevnorris>so that might actually be a viable option.
07:18:05  <groundwater_>well, we're using a patched "on" method
07:18:10  <groundwater_>that kinda functions like onAsync
07:18:18  <groundwater_>so you can capture the domain when the listener is assigned
07:18:25  <groundwater_>oh wait, you capture the domain at creation
07:18:27  <groundwater_>d'oh
07:18:36  <trevnorris>yeah. that's the issue.
07:18:46  <groundwater_>fucking EEs
07:18:50  <trevnorris>yup.
07:19:16  <trevnorris>with their powers combined, event emitters and domains make a serious cluster fuck.
07:20:04  <groundwater_>heh
07:20:16  <trevnorris>well, it'd be trivial to do an creation callback counter.
07:20:22  <trevnorris>and have domains use that to attach the domain object.
07:20:24  <groundwater_>with your powers combined, I am captain async
07:20:30  <trevnorris>haha
07:21:14  <trevnorris>after 6011 lands i'll throw up a PR, unless you want to use that patch and throw up your own.
07:21:18  <trevnorris>doesn't matter to me.
07:21:55  <groundwater_>doesn't matter to me either
07:22:47  <trevnorris>coolio. well, I think i'm past being productive.
07:22:52  <groundwater_>heh
07:22:59  <groundwater_>time for some GTA 5
07:24:19  <trevnorris>ircretary: tell piscisaureus_ write up a gist about what you're looking for in the AsyncWrap hook. I'm down implementing it in 6011, but i'll need to get it in soon.
07:24:19  <ircretary>trevnorris: I'll be sure to tell piscisaureus_
07:24:33  <trevnorris>groundwater_: have fun. night
07:29:31  * rendarjoined
07:30:45  * inolenquit (Quit: Leaving.)
07:34:09  * inolenjoined
07:35:15  * inolenquit (Client Quit)
07:51:41  * dshaw_quit (Quit: Leaving.)
08:13:33  * inolenjoined
08:22:51  * paddybyersquit (Quit: paddybyers)
08:29:12  * zotjoined
08:31:18  * paddybyersjoined
08:52:18  * dshaw_joined
08:57:13  * dshaw_quit (Ping timeout: 272 seconds)
09:01:29  * inolenquit (Quit: Leaving.)
09:03:56  * inolenjoined
09:05:24  * bnoordhuisjoined
09:32:50  <MI6>joyent/node: Ben Noordhuis v0.10 * 0c5981b : doc: dgram: reword dgram.Socket#send() docs - http://git.io/m98wHQ
09:40:37  <indutny>рheya
09:40:41  <indutny>bnoordhuis: I was just looking at this bug
09:42:59  * inolenquit (Quit: Leaving.)
09:43:35  <MI6>nodejs-v0.10: #1568 UNSTABLE smartos-x64 (5/603) smartos-ia32 (4/603) linux-ia32 (1/603) http://jenkins.nodejs.org/job/nodejs-v0.10/1568/
09:44:54  * inolenjoined
09:47:35  * inolenquit (Client Quit)
09:52:13  * kazuponquit (Remote host closed the connection)
09:52:39  * kazuponjoined
09:53:00  * inolenjoined
09:53:04  * dshaw_joined
09:53:22  * inolenquit (Client Quit)
09:57:00  * Rabenklauejoined
09:57:02  * kazuponquit (Ping timeout: 240 seconds)
09:57:39  * dshaw_quit (Ping timeout: 260 seconds)
10:08:53  * Rabenklauequit (Ping timeout: 265 seconds)
10:14:13  * Rabenklauejoined
10:15:03  * kazuponjoined
10:19:31  * kazuponquit (Ping timeout: 265 seconds)
10:23:33  <bnoordhuis>indutny: hey. what's up?
10:25:54  <indutny>all good
10:27:37  * luxigo_joined
10:29:43  <indutny>bnoordhuis: is simple/test-https-foafssl failing for you in master?
10:32:23  <bnoordhuis>indutny: passes for me
10:32:55  * zotpart
10:33:40  <indutny>hrm
10:33:44  <indutny>bnoordhuis: odd
10:33:44  * inolenjoined
10:33:48  <indutny>aaah
10:33:50  <indutny>currrl
10:33:59  * inolenquit (Client Quit)
10:34:03  <indutny>don't tell me that those fucking bastards updated curl
10:34:03  <indutny>:P
10:34:37  <indutny>yes
10:34:38  <indutny>they did
10:34:45  <MI6>joyent/node: Thom Seddon master * f755ecf : src: accept passphrase when crypto signing with private key - http://git.io/q0bf3g
10:35:10  <indutny>whoa
10:36:07  <indutny>bnoordhuis: want me to help you with anything?
10:37:01  <rendar>indutny, what did they change on curl? :)
10:37:42  <`3rdEden>bnoordhuis: would you be interested in an EventEmitter patch that improves the execution performance (doubles) of .once but slightly decreases the performance of .emit?
10:38:36  <`3rdEden>I know that EventEmitter patches are usually frowned upon here ;)
10:39:06  <indutny>rendar: I don't know
10:39:11  <indutny>rendar: but it doesn't seem to be sending cert
10:40:05  * luxigo_quit (Ping timeout: 272 seconds)
10:40:49  <bnoordhuis>`3rdEden: emit() is called more often than once() so probably not
10:43:40  <`3rdEden>bnoordhuis: Is there a way I can test the impact of such changes in node?
10:44:00  <`3rdEden>The only “useful” way I can imagine a load test against a simple http server with and without the changes
10:44:55  <bnoordhuis>`3rdEden: `make bench` (though it takes a long time) or `make bench-http` or `make bench-net`
10:45:10  <bnoordhuis>`3rdEden: i welcome patches that add good EE benchmarks btw
10:45:22  <bnoordhuis>`3rdEden: you can drop them in benchmark/misc/
10:45:58  <`3rdEden>bnoordhuis: I’ve got a bunch of micro benchmarks that I used while optimizing my EventEmitter3 library
10:46:02  <`3rdEden>so i’ll see what I can do
10:46:25  * Rabenklauequit (Ping timeout: 272 seconds)
10:46:44  * zotjoined
10:49:32  <bnoordhuis>indutny: "want me to help you with anything?" <- not really. just go fix bugs :)
10:49:44  <bnoordhuis>we should be working towards getting node into releasable state for v0.12 anyway
10:52:37  <bnoordhuis>indutny: fwiw, i'm writing some 'sans i/o' micro benchmarks for tracking down regressions in net and http
10:52:40  <bnoordhuis>e.g. https://gist.github.com/bnoordhuis/925452eaa6a0f281d1aa
10:53:05  <bnoordhuis>you're free to shoot holes in my approach :)
10:53:47  * dshaw_joined
10:53:59  <mmalecki>bnoordhuis: our binge drinking tonight still on?
10:54:50  <bnoordhuis>mmalecki: hrm, can we move that to later this week?
10:55:00  <bnoordhuis>you're around for a couple of days, right?
10:55:04  <mmalecki>bnoordhuis: sure thing! scared by the rain ;) ?
10:55:12  <mmalecki>bnoordhuis: yes, I leave on 2nd
10:55:16  <bnoordhuis>hah, no. but today is a pretty busy day
10:55:23  <mmalecki>bnoordhuis: but then I'm actually moving here in 7 days!
10:55:31  <bnoordhuis>really? you got the job?
10:55:32  * inolenjoined
10:55:40  <mmalecki>bnoordhuis: yeah :)
10:55:45  * inolenquit (Client Quit)
10:55:50  <bnoordhuis>nice, congratulations :)
10:55:57  <mmalecki>bnoordhuis: thank you!
10:56:08  <MI6>nodejs-v0.10: #1569 UNSTABLE smartos-x64 (7/603) smartos-ia32 (7/603) linux-x64 (1/603) osx-x64 (1/603) osx-ia32 (1/603) http://jenkins.nodejs.org/job/nodejs-v0.10/1569/
10:56:08  * abraxasquit (Remote host closed the connection)
10:56:10  <mmalecki>bnoordhuis: I also fell in love with Amsterdam
10:56:27  <bnoordhuis>yeah? just wait till you see gouda
10:56:30  <MI6>nodejs-master: #649 UNSTABLE smartos-ia32 (8/654) linux-x64 (2/654) smartos-x64 (11/654) osx-ia32 (2/654) linux-ia32 (2/654) http://jenkins.nodejs.org/job/nodejs-master/649/
10:56:38  <bnoordhuis>mmalecki: btw, did we agree on amsterdam or utrecht?
10:56:45  <mmalecki>bnoordhuis: we agreed on Utrecht
10:56:56  <bnoordhuis>mmalecki: oh, i guess then it could still work
10:57:00  <mmalecki>but if you want to move it, that's fine with me
10:57:06  <mmalecki>oh, okay
10:57:50  <bnoordhuis>is bert coming along?
10:57:51  <bnoordhuis>did you talk to bert? maybe i should start with that :)
10:58:05  <mmalecki>bnoordhuis: hah, I didn't, I thought he was still in SF?
10:58:14  * dshaw_quit (Ping timeout: 256 seconds)
10:58:34  <bnoordhuis>oh, that's right
10:59:12  <bnoordhuis>okay, so tonight in utrecht?
10:59:40  <mmalecki>bnoordhuis: yes, that works. 9 PM at the Utrecht Central?
11:00:02  <bnoordhuis>mmalecki: does 8 PM work for you?
11:00:19  <bnoordhuis>else i have this one hour gap to fill
11:00:29  <bnoordhuis>btw, do you want to get dinner?
11:00:34  <mmalecki>bnoordhuis: yes, I do
11:00:53  <bnoordhuis>okay, cool. 8 or 9 PM?
11:00:55  <mmalecki>bnoordhuis: yeah, 8 PM is fine. will I be able to come back btw?
11:01:08  <mmalecki>I guess around 3 or 4 AM?
11:01:15  <bnoordhuis>last train leaves around midnight
11:01:35  <bnoordhuis>to amsterdam probably a little later even
11:02:19  <mmalecki>bnoordhuis: just checked with ns.nl, after 1:43, trains to Amsterdam leave every hour
11:02:43  <bnoordhuis>oh. guess that's one of the upsides of living in the capital
11:03:18  <bnoordhuis>okay, see you tonight then, maciej. first round's on you :)
11:03:24  <bnoordhuis>(and the ones after that as well)
11:03:30  <mmalecki>haha, sure. see you tonight!
11:03:33  <bnoordhuis>(i kid, i kid)
11:03:36  <bnoordhuis>see you tonight :)
11:05:03  * Kakera_joined
11:10:41  <indutny>bnoordhuis: back
11:46:24  <rendar>why do exist articles like this? http://live.julik.nl/2013/05/javascript-is-shit O_O
11:48:16  <mmalecki>rendar: because people have nothing to do?
11:48:45  <mmalecki>or dunno, they need hackernews imaginary points
11:52:15  * karupanerurachanged nick to zz_karupanerura
11:54:29  <bnoordhuis>at least it means people are using js, when they have strong opinions on it
11:54:34  * dshaw_joined
11:55:32  <bnoordhuis>reading the HN comments is amusing though; the extent to which people will argue their case when the first reply already points out how wrong they are
11:56:07  <bnoordhuis>to name particulars: https://news.ycombinator.com/item?id=6633105
11:57:53  <rendar>bnoordhuis, eheh right
11:58:59  * dshaw_quit (Ping timeout: 260 seconds)
12:05:57  <`3rdEden>mmalecki: your first mistake here in the Netherlands, trusting our rail system ;-)
12:06:36  <mmalecki>`3rdEden: THAT bad?
12:07:15  <`3rdEden>mmalecki: they are quite anal about how the weather affects the trains
12:07:44  <bnoordhuis>oh, i guess that's true. there were massive delays yesterday and this morning
12:07:46  <`3rdEden>Last week we had to get off our train that went to amsterdam near amserfoort (big-ish city) because the rails we’re “slippery"
12:07:54  <mmalecki>hmmm, right, I remember that from the last visit... and it rained today
12:07:57  <`3rdEden>It was 9 degrees and the sun was shining..
12:08:10  <bnoordhuis>mmalecki: maybe it's better to move it to thursday or friday
12:08:28  <mmalecki>bnoordhuis: yeah, I was going to suggest pushing it until weather is more... normal?
12:08:43  <`3rdEden>I doubt the trains have recovered from yesterday’s chaos
12:09:05  <bnoordhuis>probably not. they were still cleaning up in places this morning
12:09:24  <mmalecki>yeah, okay, let's make it Thursday
12:09:33  <mmalecki>bnoordhuis: unless you're coming to Amstedam.js?
12:09:40  <bnoordhuis>when's that
12:09:43  <bnoordhuis>+question mark
12:09:47  <mmalecki>bnoordhuis: tomorrow
12:09:54  <mmalecki>`3rdEden: you coming ^ ?
12:10:06  <bnoordhuis>oh. hrm, maybe. don't have much time but... maybe
12:10:08  <bnoordhuis>okay, gotta run
12:10:10  * bnoordhuisruns
12:10:17  <mmalecki>Run Ben, run!
12:11:17  <`3rdEden>mmalecki: Normally I would but arms still frigging hurts from my last tattoo session. I’ll probably be at the next amsterdam.js if the topics are good :)
12:11:51  <mmalecki>`3rdEden: word. let me know when you're in Amsterdam next and we'll hang out
12:14:52  * bnoordhuisquit (Ping timeout: 246 seconds)
12:15:08  <`3rdEden>mmalecki: normally I’m in Amsterdam every 2 weeks until I got both my sleeve tattoo’s done. But I’m usually running really late then as they are mostly 4hour+ sessions. But I’ll give you a heads up when I got some time to hang out.
12:15:54  <mmalecki>`3rdEden: awesome!
12:21:56  * Rabenklauejoined
12:55:16  * dshaw_joined
12:56:48  * abraxasjoined
12:57:05  * dshaw_1joined
12:57:07  * dshaw_quit (Read error: Connection reset by peer)
13:01:24  * abraxasquit (Ping timeout: 240 seconds)
13:01:26  * dshaw_1quit (Ping timeout: 240 seconds)
13:12:05  * Kakera_quit (Ping timeout: 248 seconds)
13:19:43  * loladirojoined
13:29:29  * kazuponjoined
13:48:35  * Kakera_joined
13:50:14  * bnoordhuisjoined
13:54:47  * loladiroquit (Quit: loladiro)
13:57:52  * dshaw_joined
14:02:39  * dshaw_quit (Ping timeout: 260 seconds)
14:08:48  * defunctzombie_zzchanged nick to defunctzombie
14:11:50  * kazuponquit (Remote host closed the connection)
14:12:16  * kazuponjoined
14:17:19  * kazuponquit (Ping timeout: 272 seconds)
14:20:22  * zotquit (Quit: Leaving.)
14:27:06  * pachetjoined
14:27:06  * pachetquit (Changing host)
14:27:06  * pachetjoined
14:33:39  * zotjoined
14:43:56  <bnoordhuis>recompiling llvm is serious business...
14:47:04  * AvianFlujoined
14:58:37  * dshaw_joined
15:02:52  * dshaw_quit (Ping timeout: 246 seconds)
15:09:47  <bnoordhuis> 2 3638 31.0% [vdso]
15:09:50  <bnoordhuis> 3 3552 97.6% LazyCompile: *exports._unrefActive timers.js:428:32
15:10:14  <bnoordhuis>^ _unrefActive() is making system calls like mad
15:14:30  * mcavagejoined
15:15:07  <bnoordhuis>i guess on linux we can do better by reading the timestamp directly from the vdso
15:15:27  <bnoordhuis>because that's what _unrefActive() does, update the event loop's idea of 'now'
15:20:43  <MI6>nodejs-master: #650 UNSTABLE smartos-ia32 (7/654) smartos-x64 (7/654) osx-ia32 (1/654) http://jenkins.nodejs.org/job/nodejs-master/650/
15:20:54  * mikealquit (Quit: Leaving.)
15:28:55  * mikealjoined
15:29:56  * octetcloudjoined
15:31:24  * mikealquit (Client Quit)
15:31:24  * saghulchanged nick to RubberDuck
15:31:37  <RubberDuck>You are right, Ben :-P
15:31:44  * RubberDuckchanged nick to saghul
15:34:28  <bnoordhuis>:)
15:35:04  <bnoordhuis>just throwing it out there so people don't get the idea i'm not doing anything
15:40:18  <saghul>bnoordhuis quick q: does #846 need fixing in your opinion?
15:41:22  <bnoordhuis>saghul: that's a windows-only issue, right? looks legit to me but i usually let bert sign off on / fix them
15:41:33  <bnoordhuis>though in practice that never happens, of course
15:41:59  <bnoordhuis>you're a committer now. if you think the fix is okay, go ahead and land it
15:42:18  * dshaw_joined
15:43:40  <saghul>bnoordhuis looks possible on unix too: https://github.com/joyent/libuv/blob/master/src/unix/core.c#L262
15:43:45  <saghul>I'll make a fix
15:46:44  * loladirojoined
15:47:06  * superjoe30joined
15:48:29  * mikealjoined
15:50:33  * mikealquit (Client Quit)
16:01:10  * sblomjoined
16:02:32  <tjfontaine>isaacs: btw I'm at home doing the call, then heading in so don't wait for me :)
16:03:06  * piscisaureus_joined
16:05:04  <tjfontaine>bnoordhuis, trevnorris, indutny: ping
16:05:05  <piscisaureus_>bnoordhuis: call
16:05:13  <bnoordhuis>oh, DST
16:05:20  <bnoordhuis>on my way, switching machines
16:06:33  <isaacs>bnoordhuis, indutny, piscisaureus_, tjfontaine, trevnorris, sblom: call?
16:07:44  * bnoordhu1sjoined
16:07:55  <bnoordhu1s>link?
16:08:17  <trevnorris>here
16:09:13  <tjfontaine>https://plus.google.com/hangouts/_/calendar/aXNhYWNzY2hsdWV0ZXJAZ21haWwuY29t._8gr32d1p611k8b9o6cr48b9k6op3eba18cr32b9k88s3cgpi8d2k8dq560
16:10:05  <bnoordhu1s>cheers
16:10:09  <rendar>i always wondered why google hangouts ids are so long :D
16:10:25  * bnoordhuisquit (Ping timeout: 272 seconds)
16:10:59  * loladiroquit (Quit: loladiro)
16:16:37  <bnoordhu1s>piscisaureus_: back in NL?
16:16:42  * bnoordhu1schanged nick to bnoordhuis
16:16:48  <piscisaureus_>bnoordhu1s: yup
16:18:51  * loladirojoined
16:27:36  <bnoordhuis>piscisaureus_: up for beer thursday?
16:27:50  <piscisaureus_>bnoordhuis: maybe... I might have to stay home
16:28:17  <bnoordhuis>piscisaureus_: why's that? restraining order?
16:28:23  * amartensjoined
16:28:32  <piscisaureus_>bnoordhuis: how did you guess
16:28:47  <bnoordhuis>piscisaureus_: i follow #politie020
16:29:05  <piscisaureus_>bnoordhuis: I'll know more tomorrow. Beer is good anyway.
16:29:10  <bnoordhuis>cool
16:33:45  * TooTallNatejoined
16:36:48  * loladiroquit (Quit: loladiro)
16:44:48  * indexzerojoined
16:46:49  * tylerflintjoined
16:47:09  <hueniverse1>trevnorris: I increased the response payload in the leak test to 4K and ran it with 0.11.7 all night. after about an hour there were a few big jumps in rss. then in the next 9 hours it was pretty stable with very minor growth but still leaking.
16:47:45  <tjfontaine>I haven't done the full analysis yet, but a lot fo what you're seeing feels like heap fragmentation
16:47:53  <trevnorris>hueniverse1: was that your script or mine?
16:48:03  * bnoordhuisquit (Remote host closed the connection)
16:49:45  <tjfontaine>almost all the memory is in the real heap, not the actual v8 heap
16:50:37  <tylerflint>(writing a tcp client). Can I set a "disconnect" callback on the connection (uv_connect_t)?
16:50:41  * loladirojoined
16:51:26  * st_lukejoined
16:51:31  <trevnorris>tjfontaine: did you ever hit up azure about getting more vm's?
16:51:47  <tjfontaine>not yet I will today with isaacs once I get intot he office
16:51:55  <trevnorris>coolio
16:52:07  <trevnorris>i'd be more than happy to iterate on the node_object_wrap, but don't want to spend the time setting up a windows vm to compile code
16:52:30  <tylerflint>or do I just need to just uv_read_start and watch for an EOF?
16:52:42  <MI6>joyent/node: Scott Blomquist master * c137e3d : src: Remove unused refs to node_object_wrap.h - http://git.io/Po4EZA
16:53:17  * sblom_joined
16:53:46  * sblomquit (Disconnected by services)
16:53:50  * sblom_changed nick to sblom
16:54:25  * sblomchanged nick to sblom_
16:54:29  <tylerflint>or, I guess I'm actually dealing with a uv_stream_t
16:54:54  * sblom_changed nick to sblom
16:55:51  <trevnorris>piscisaureus_: so did you say you're going to open a PR against my fork?
16:55:53  * zotpart
16:56:33  <hueniverse1>trevnorris: mine. looking at your changes now
16:57:26  <trevnorris>hueniverse1: only real change is that it hits the server harder, and removes function scoping to ease up on GC. hopefully to make the leak more pronounced.
16:58:21  * skabbesjoined
17:00:31  * skabbesquit (Client Quit)
17:02:14  * bnoordhuisjoined
17:02:35  <piscisaureus_>trevnorris: yes. It's not for landing, just for showing you the idea
17:03:13  <trevnorris>piscisaureus_: yeah, sounds good.
17:06:28  * skabbesjoined
17:07:36  * mikealjoined
17:07:47  <indutny>heya
17:07:51  <bnoordhuis>hoya
17:07:53  <indutny>sorry, missed a call
17:07:57  <indutny>forgot what time it was
17:08:12  <indutny>anything important?
17:08:37  <MI6>nodejs-master: #651 UNSTABLE osx-x64 (2/654) smartos-ia32 (9/654) smartos-x64 (11/654) http://jenkins.nodejs.org/job/nodejs-master/651/
17:08:42  <bnoordhuis>we didn't solve the world peace problem
17:08:59  <bnoordhuis>we did make some decisions on asyncwrap and so on
17:09:04  <indutny>ok
17:09:06  <indutny>yay or nay?
17:09:15  <bnoordhuis>mostly yay :)
17:09:30  <indutny>ok
17:10:36  <MI6>joyent/node: piscisaureus created branch 6011-isfinal - http://git.io/JXjs5g
17:10:52  <indutny>anyway
17:10:54  <indutny>anything else?
17:12:48  * amartensquit (Quit: Leaving.)
17:13:01  <piscisaureus_>trevnorris: https://github.com/joyent/node/commit/30902485c4c198ff784afab9e299aba2813df9d7
17:13:12  <piscisaureus_>stupid trillian
17:13:15  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
17:13:43  * piscisaureus_joined
17:14:43  * indexzeroquit (Quit: indexzero)
17:14:55  <trevnorris>bnoordhuis: so calling a callback from a destructor is dangerous. have any other ideas for alerting the user a class is about to be destructed?
17:16:05  * brsonjoined
17:16:55  * skabbesquit (Ping timeout: 246 seconds)
17:18:11  * bnoordhuisquit (Ping timeout: 260 seconds)
17:18:29  * AvianFluquit (Remote host closed the connection)
17:18:58  * skabbesjoined
17:23:19  <mmalecki>`3rdEden: yo, how can I primus.write({ hello: 'world' }) and have it be stringified?
17:23:50  <mmalecki>damn it, why do I keep asking here?!
17:23:57  <`3rdEden>It does that automaticallu
17:24:02  <`3rdEden>Y*
17:24:07  <mmalecki>I need to make #libuv my 3rd channel again
17:25:48  * amartensjoined
17:30:49  <indutny>trevnorris: what is it for?
17:30:59  <trevnorris>indutny: node_object_wrap is being removed from node.h for now to fix the windows build. that'll break user-land modules that depend on it, but we'll have that fixed before the v0.12 release.
17:31:11  <trevnorris>indutny: you mean asyncwrap?
17:31:19  <indutny>trevnorris: I mean near-death callback
17:33:20  <trevnorris>indutny: to alert the user that the class is about to be destructed.
17:33:26  <indutny>well
17:33:30  <indutny>have you seen node-weak?
17:33:55  <indutny>do you want it in core?
17:34:00  <trevnorris>yeah. node-weak inherits from asyncwrap. i'm talking about calling a js function.
17:34:20  * tylerflintpart
17:34:22  <trevnorris>inside the destructor of the class
17:34:29  <indutny>huuuh?
17:34:52  <indutny>trevnorris: https://github.com/TooTallNate/node-weak
17:34:52  <trevnorris>some classes have deterministic endings, so there's no weakcallback that we can use
17:34:57  <piscisaureus_>trevnorris: indutny: I think that AsyncWrap and WeakObject should be separate
17:35:15  <indutny>ok, I'm totally into this thing
17:35:17  <trevnorris>indutny: sorry, for some reason I saw weak-object
17:35:21  <indutny>np
17:36:02  <trevnorris>piscisaureus_: how are you going to do that w/o duplicating a ton of code? you'd have to make env(), persistent() and object() virtual members in asyncwrap and depend on the inheriting class to implement them.
17:36:20  <piscisaureus_>trevnorris: that's exactly what I did here: https://github.com/joyent/node/commit/30902485c4c198ff784afab9e299aba2813df9d7
17:36:31  <piscisaureus_>trevnorris: we could also use a common base class
17:36:40  <piscisaureus_>trevnorris: it's not *that* much
17:36:48  * mikealquit (Quit: Leaving.)
17:37:30  <piscisaureus_>trevnorris: well - AsyncWrap can still implement env(), persistent() etc
17:37:30  <indutny>trevnorris: AsyncWrap is basically a thing that does "new-domain" binding to callbacks?
17:37:40  <indutny>trevnorris: i.e. uses and sets asyncQueue things on objects
17:37:45  <indutny>trevnorris: right?
17:37:48  <piscisaureus_>trevnorris: but AsyncWrap should not do weak callbacks
17:38:00  <piscisaureus_>or use them
17:38:23  <trevnorris>indutny: partially. but it uses some state sharing techniques to have zero performance impact. unlike domains had
17:38:29  <trevnorris>piscisaureus_: why?
17:38:39  <indutny>trevnorris: ok
17:38:42  <indutny>trevnorris: external arras
17:38:47  <indutny>arrays*
17:38:48  <trevnorris>pretty much
17:39:28  <piscisaureus_>trevnorris: because you can never tell if a weak object will go away first or if it will make callbacks first
17:39:58  <trevnorris>indutny: also, AsyncWrap has its own MakeCallback implementation, since mos the necessary callback info is already on the class. makes syntax easier.
17:40:19  <indutny>trevnorris: cool, it is starting to fit properly in my head
17:40:21  <indutny>:)
17:40:40  <piscisaureus_>trevnorris: also AsyncWrap triggers your hooks but if you inherit from it without ever making any callbacks that's wrong
17:40:47  <trevnorris>piscisaureus_: eh? it's impossible that the persistent() is disposed before the MakeCallback since it's always the context of the callback.
17:41:07  <piscisaureus_>trevnorris: depends. If you make it weak, yes
17:41:18  <piscisaureus_>trevnorris: the other way around is worse even.
17:41:27  <piscisaureus_>ehh
17:41:35  <trevnorris>piscisaureus_: it has zero cost, and there's almost no place that happens. unlike when ObjectWrap was in use which had several class members that were never used by core.
17:41:47  <piscisaureus_>trevnorris: many crypto objects now trigger the async listener "listener" function without ever making any callbacks
17:41:54  <piscisaureus_>trevnorris: e.g. Hmac
17:42:03  <piscisaureus_>trevnorris: also ContextifyScript
17:42:19  <trevnorris>sec. taking a look.
17:42:47  <trevnorris>man. nvidia drivers for linux really suck.
17:44:09  <trevnorris>on the side, I think WeakObject::Unwrap<T>() should be renamed and go in util.h. it isn't specific to the WeakObject implementation.
17:44:40  <piscisaureus_>trevnorris: what if we had ObjectWrap as a base class
17:44:58  <piscisaureus_>trevnorris: and WeakObject adds MakeWeak and ClearWeak
17:45:09  <trevnorris>that's the class I've spent so much time trying to get rid of.
17:45:14  <piscisaureus_>haha
17:45:19  <piscisaureus_>ObjectWrap2
17:45:27  <trevnorris>heh ;)
17:46:02  <trevnorris>that's what WeakObject was supposed to be.
17:46:08  <piscisaureus_>trevnorris: I'm not saying that ObjectWrap1 is any good
17:46:32  <piscisaureus_>trevnorris: then why does WeakObject inherit from AsyncWrap and not the other way round?
17:46:38  <piscisaureus_>trevnorris: the other way round would be ok with me
17:47:11  * AvianFlujoined
17:48:17  <trevnorris>tried that, but still had the issue of always needing env(), persistent() and object(). which not all other classes had.
17:48:28  <trevnorris>i'm ok w/ the idea of creating a base class that just contains those three fields.
17:48:46  <trevnorris>those are the major pain point here.
17:50:44  <piscisaureus_>trevnorris: also Unwrap
17:50:54  <piscisaureus_>trevnorris: much nicer than NODE_UNWRAP imo
17:51:31  <trevnorris>I still think that should just go into util.h. so instead of SomeClass::Unwrap<T>() it'd just be Unwrap<T>()
17:51:48  <piscisaureus_>trevnorris: you can already use it that way :)
17:51:56  <piscisaureus_>trevnorris: you just didn't try :)
17:52:06  <piscisaureus_>trevnorris: that is - if you inherit from AsyncWrap
17:52:39  <piscisaureus_>\o/ for class inheritance
17:52:41  <trevnorris>I think unwrap shouldn't be a member of any class because it's usage is agnostic to the class itself.
17:52:41  * piscisaureus_brb
17:52:49  <piscisaureus_>trevnorris: Agree, actually
17:52:54  <piscisaureus_>but *shrug*
17:52:56  <trevnorris>:)
17:53:08  <trevnorris>i'm going to bring it up w/ ben when he gets back
17:56:12  * indexzerojoined
18:00:59  <sblom>s/for linux//
18:01:31  <sblom>(yikes. mostly ignore that. It's a _way_ lagged reply.)
18:01:38  <trevnorris>heh
18:09:06  * julianduquejoined
18:09:13  <sblom>Anyone know off the top of their head how to persuade node-gyp to build for x86 instead of x64?
18:09:30  <TooTallNate>sblom: --arch=ia32 perhaps
18:11:35  <tjfontaine>you really want to let gyp decide for itself though? or are you building in interesting ways?
18:11:53  <sblom>Well, I'm really just trying to get my module build to match the bitness of my node bulid.
18:12:00  <TooTallNate>tjfontaine: i think it checks process.arch
18:12:02  <sblom>(all of this on Windows)
18:12:07  <tjfontaine>TooTallNate: right.
18:12:20  <tjfontaine>sblom: execute with the proper node, it shoudl DoTheRightThing(tm)
18:12:29  <TooTallNate>indeed
18:12:31  <sblom>Ahhh, got it.
18:12:56  <sblom>I'm using installed node to run node-gyp and built node as --nodedir for node-gyp.
18:12:58  <sblom>Thanks.
18:13:04  <MI6>libuv-v0.10-gyp: #87 ABORTED http://jenkins.nodejs.org/job/libuv-v0.10-gyp/87/
18:13:09  <TooTallNate>tjfontaine: and to answer your question properly, i believe the .gyp files contain arch specific flags (which is lame indeed)
18:13:17  * dshaw_quit (Quit: Leaving.)
18:13:30  * TooTallNatequit (Quit: Computer has gone to sleep.)
18:13:55  <MI6>libuv-master-gyp: #250 ABORTED smartos-ia32 (2/195) http://jenkins.nodejs.org/job/libuv-master-gyp/250/
18:14:15  <MI6>libuv-master: #309 ABORTED http://jenkins.nodejs.org/job/libuv-master/309/
18:14:16  <trevnorris>sblom: here's my build command: /path/to/my-node/node $(which node-gyp) rebuild --nodedir=/path/to/my-node/
18:14:42  <tjfontaine>trevnorris: heh, if only he had a sane shell :P
18:14:52  <trevnorris>haha, I forget about that
18:15:00  <MI6>nodejs-master-windows: #439 ABORTED http://jenkins.nodejs.org/job/nodejs-master-windows/439/
18:15:26  <sblom>cygwin! Wait. cygwin fairly sucks.
18:15:45  <tjfontaine>not fairly, it's very unfair
18:15:51  <sblom>Indeed.
18:15:58  <MI6>libuv-v0.10: #122 ABORTED smartos (2/187) http://jenkins.nodejs.org/job/libuv-v0.10/122/
18:16:11  <sblom>Have I already ranted about how much of an unholy hack the cygwin implementation of fork() is?
18:16:18  <sblom>I'm sure I couldn't do better.
18:16:22  <tjfontaine>do I even want to know?
18:16:25  <sblom>But it only works by coincidence as far as I can tell.
18:16:27  <sblom>Oh, it's amazing.
18:16:34  <sblom>It's so amazing it's in their FAQ.
18:16:39  * sblomlooks for a link.
18:16:40  <tjfontaine>...
18:17:11  <rendar>sblom, you're right
18:17:19  <sblom>http://cygwin.com/cygwin-ug-net/highlights.html#ov-hi-process
18:17:55  <tjfontaine>sblom: oh man.
18:18:41  <sblom>It's seriously incredible. I only learned this when I was having a cygwin build of perl.exe randomly crash while building Chrome but only in a certain command shell (not cmd.exe).
18:19:12  <sblom>You would never believe how long it took me to even consider the possibility that it was the command shell causing perl.exe to crash.
18:22:39  <sblom>trevnorris, bnoordhuis, tjfontaine: Looks like ObjectWrap builds fine on Windows if not exported.
18:22:57  <trevnorris>sblom: awesome. that's good to hear.
18:23:01  <sblom>So we're in good shape to fix this for real.
18:23:50  <MI6>nodejs-v0.10-windows: #292 ABORTED http://jenkins.nodejs.org/job/nodejs-v0.10-windows/292/
18:24:01  <trevnorris>great. does that mean it'll get in before the release today?
18:24:03  <trevnorris>tjfontaine: ^
18:24:39  * bnoordhuisjoined
18:26:32  <trevnorris>bnoordhuis: is there a reason why WeakObject::Unwrap<T>() needs to exist? why not just use NODE_UNWRAP from node_internals.h?
18:27:05  <bnoordhuis>trevnorris: turn it around: why use a macro when you can use a method?
18:27:34  <trevnorris>bnoordhuis: well. at the least, I think it should be moved to util.h. the method seems class agnostic.
18:28:09  <bnoordhuis>i can live with that. replace calls to NODE_UNWRAP while you're at it :)
18:28:17  <trevnorris>will do :)
18:30:58  <tjfontaine>trevnorris: i thought it already landed
18:31:01  <trevnorris>bnoordhuis: I was thinking add, uint32_t index = 0); as the second parameter. just to not always rely on the class being in the zero index. not necessary?
18:31:24  * loladiroquit (Quit: loladiro)
18:31:45  * TooTallNatejoined
18:31:45  <trevnorris>tjfontaine: no. I landed another thing for NODE_WRAP, but guess now I'm getting rid of it
18:34:54  * loladirojoined
18:39:13  <sblom>trevnorris: I don't know why it can't go in for the release. I'm posting the PR now.
18:39:35  <trevnorris>awesome. glad this worked out :)
18:39:43  <sblom>yeah
18:39:45  <trevnorris>always like solutions that involve deleting code
18:43:50  * loladiroquit (Quit: loladiro)
18:45:11  <bnoordhuis>trevnorris: index=0? not sure what you mean
18:45:34  <trevnorris>bnoordhuis: when you unwrap you get the indexed property, should we always assume it's at 0
18:47:55  * mikealjoined
18:50:36  <bnoordhuis>trevnorris: oh, like that. seems like a safe assumption for now.
18:50:44  <sblom>https://github.com/joyent/node/pull/6436
18:50:46  <trevnorris>coolio
18:51:24  <tjfontaine>fucking.
18:51:25  <tjfontaine>gyp.
18:51:27  <tjfontaine>http://jenkins.nodejs.org/job/libuv-master-gyp/DESTCPU=x64,label=windows/251/console
18:51:47  <MI6>libuv-master-gyp: #251 ABORTED smartos-ia32 (2/195) smartos-x64 (2/195) http://jenkins.nodejs.org/job/libuv-master-gyp/251/
18:52:29  * jwhisnantjoined
18:52:37  * jwhisnantpart
18:52:43  <sblom>Nice topical reply, loudbot.
18:53:08  <tjfontaine>indeed.
18:59:50  * abraxasjoined
19:02:48  <MI6>node-review: #97 FAILURE windows-x64 (47/663) windows-ia32 (49/663) http://jenkins.nodejs.org/job/node-review/97/
19:03:48  <tjfontaine>how to know that bert did a feature branch, instead of everything working everywhere except windows, bert's are the opposite :)
19:04:25  <piscisaureus_>tjfontaine: oh that code isn't supposed to pass tests
19:04:26  * abraxasquit (Ping timeout: 264 seconds)
19:04:41  <tjfontaine>piscisaureus_: the builds are broken
19:04:52  <piscisaureus_>tjfontaine: weird. wfm
19:05:09  <piscisaureus_>tjfontaine: doesn't matter in this case anyway
19:05:11  <tjfontaine>http://jenkins.nodejs.org/job/node-review/DESTCPU=ia32,label=linux/97/console
19:05:14  <tjfontaine>nod
19:08:43  * loladirojoined
19:12:48  * loladiroquit (Ping timeout: 240 seconds)
19:14:15  * dshaw_joined
19:18:35  * dshaw_quit (Ping timeout: 240 seconds)
19:18:50  <trevnorris>bnoordhuis: almost done w/ that change. though I get the occasional "unused function" warning from the compiler. any way around that?
19:23:40  <trevnorris>ugh. have a way. it's stupid. but got it.
19:24:01  <trevnorris>just turned it into a template class instead.
19:35:53  * zotjoined
19:38:55  <sblom>tjfontaine: there are some mergedroppings in https://github.com/joyent/node/commit/61ccaf9
19:39:14  <sblom>I'm touching the file. Do you know whether the left or right changes are the ones I should keep?
19:39:23  * Rabenklauequit (Ping timeout: 246 seconds)
19:39:56  <trevnorris>son of a bitch. just ran git reset --hard on a couple hundred lines of change...
19:40:55  <sblom>Were they ever in a changeset? I.e. any chance they're in reflog?
19:41:54  <trevnorris>nope
19:41:59  <sblom>>_<
19:42:24  <sblom>Sorry to hear it--I've done that before.
19:44:47  <MI6>nodejs-v0.10-windows: #293 UNSTABLE windows-ia32 (17/603) windows-x64 (16/603) http://jenkins.nodejs.org/job/nodejs-v0.10-windows/293/
19:49:25  <piscisaureus_>isaacs: https://github.com/joyent/node/issues?direction=desc&labels=&milestone=17&page=1&sort=updated&state=open
19:51:46  <trevnorris>bnoordhuis: mind looking at: https://github.com/trevnorris/node/commit/b054790 and https://github.com/trevnorris/node/commit/7a9beef
19:51:54  <trevnorris>bnoordhuis: want to know if the implementation is ok.
19:52:09  <bnoordhuis>love the second commit hash
19:52:15  <MI6>nodejs-master-windows: #440 UNSTABLE windows-x64 (30/654) windows-ia32 (30/654) http://jenkins.nodejs.org/job/nodejs-master-windows/440/
19:52:16  <trevnorris>yeah, right?
19:53:07  <trevnorris>bnoordhuis: only part i'm concerned about is the change in the WeakObject constructor, how I pass WeakObject as the class type. I know it'd be "better" to pass the parent class, but since it's resolved as a void* didn't think it would matter.
19:55:20  <trevnorris>man, I should really land a few of these not so related commits. the PR is pushing 5000 lines changed.
19:58:27  <bnoordhuis>trevnorris: approach looks okay to me. the only place where it may go wrong is when you're wrapping/unwrapping classes with more than one base class
19:58:47  <bnoordhuis>and UnwrapObject() is maybe kind of wordy
19:59:07  <bnoordhuis>though i guess it says it what it does
19:59:36  <trevnorris>bnoordhuis: i believe you, but i'm not sure how that could be a problem and I was just going to use Wrap/Unwrap but there are methods like TCPWrap::Unwrap. i'm working those out right now.
20:00:07  <trevnorris>then was going to switch to Wrap/Unwrap. agree that it's too wordy.
20:00:52  <trevnorris>bnoordhuis: so, i'm not sure how to fix the multi-base class problem. mostly because I don't understand how it's a problem.
20:01:16  <bnoordhuis>trevnorris: okay. say you have class C with base classes A and B
20:01:37  <bnoordhuis>trevnorris: you cast C* to void* to store it. when you retrieve it, you don't cast it to C* but to A* or B*
20:01:45  <hueniverse1>tjfontaine: Can you ping the folks at joyent working on https://help.joyent.com/requests/134381? don't want to duplicate effort
20:01:55  <bnoordhuis>trevnorris: depending on the compiler and the phase of the moon, that may or may not do the expected thing
20:02:52  <bnoordhuis>trevnorris: long story short, just make sure to always cast to and from the same class
20:03:12  <trevnorris>bnoordhuis: ah, understand. basically has to do w/ how the compiler lays out memory in the class inheritance? like how you use macros in libuv for "inheritance" from struct to struct.
20:04:15  <bnoordhuis>trevnorris: correct
20:05:13  <trevnorris>bnoordhuis: so, your fix in WeakObject was to cast first to WeakObject then to the type. how would that solve the issue? just telling the compiler how to read the memory?
20:05:24  <bnoordhuis>trevnorris: basically, yes
20:05:40  <trevnorris>interesting. you have much knowledge.
20:05:51  <bnoordhuis>i read a lot
20:06:24  <trevnorris>heh.
20:07:50  <trevnorris>so.... trying to think of a way to fix that. if you have one let me know. guess I wasn't paying attention that in some places we might be casting, say, a TCPWrap as a HandleWrap.
20:10:11  <bnoordhuis>trevnorris: no places come to mind where we're doing that. i guess the guiding message is: be careful when making those changes :)
20:10:50  <trevnorris>ah, ok. thanks for the ProTip :)
20:11:22  <trevnorris>bnoordhuis: worked out the class methods named Wrap/Unwrap. think I should go ahead and remove the Object out of the method name?
20:12:03  <bnoordhuis>i guess so. shorter is better. in programming, at least
20:12:10  <trevnorris>cool.
20:13:21  * Rabenklauejoined
20:14:10  * Rabenklauequit (Client Quit)
20:16:38  * Kakera_quit (Ping timeout: 240 seconds)
20:17:06  * loladirojoined
20:21:28  * Kakera_joined
20:23:55  * st_lukequit (Remote host closed the connection)
20:25:24  * loladiroquit (Quit: loladiro)
20:30:34  <MI6>nodejs-master-windows: #441 UNSTABLE windows-x64 (27/654) windows-ia32 (30/654) http://jenkins.nodejs.org/job/nodejs-master-windows/441/
20:31:48  * loladirojoined
20:41:12  <trevnorris>bnoordhuis: you have any problems w/ me merging https://github.com/joyent/node/pull/6437
20:41:30  <trevnorris>bnoordhuis: just trying to remove not completely related commits from 6011 so it's not so large.
20:41:44  * sblomquit
20:43:53  <trevnorris>whoops. extraneous headers in node_crypto.h. removing now.
20:56:34  * loladiroquit (Quit: loladiro)
20:57:06  * loladirojoined
20:58:11  * loladiroquit (Client Quit)
20:58:30  * loladirojoined
20:59:23  * loladiroquit (Client Quit)
21:00:19  * indutny_joined
21:00:49  * abraxasjoined
21:02:41  * defunctzombiechanged nick to defunctzombie_zz
21:03:36  * mmalecki_joined
21:05:07  * abraxasquit (Ping timeout: 246 seconds)
21:07:36  * LeftWingquit (*.net *.split)
21:07:37  * mmaleckiquit (*.net *.split)
21:07:37  * indutnyquit (*.net *.split)
21:07:37  * tjfontainequit (*.net *.split)
21:07:37  * nsmquit (*.net *.split)
21:07:37  * othiym23quit (*.net *.split)
21:07:40  * indutny_changed nick to indutny
21:09:47  * loladirojoined
21:10:39  * loladiroquit (Client Quit)
21:11:36  * loladirojoined
21:12:23  <indutny>whoa
21:12:59  <trevnorris>indutny: sup?
21:13:12  <indutny>just returned back
21:13:20  <indutny>reading all email
21:14:10  * kellabytequit (Remote host closed the connection)
21:14:25  * LeftWingjoined
21:14:25  * tjfontainejoined
21:14:25  * nsmjoined
21:14:25  * othiym23joined
21:15:33  <MI6>libuv-master: #310 FAILURE http://jenkins.nodejs.org/job/libuv-master/310/
21:16:23  <indutny>bnoordhuis: any progress with my PRs?
21:16:47  <indutny>I've at least 8 emails in inbox that would be resolved once you'll approve them :P
21:16:59  <indutny>that'll make me happy for the rest of the week
21:17:20  <trevnorris>indutny: mind taking quick look at https://github.com/joyent/node/pull/6437 ?
21:19:14  * zotpart
21:19:18  <indutny>trevnorris: sure, looking
21:20:08  <trevnorris>bnoordhuis: re: inline static. got that from the usage in weak-object constructor declaration. are they two difference uses because one is a class member?
21:20:36  <indutny>trevnorris: I thought I seen similar commit in your domain-like PR
21:20:39  <indutny>trevnorris: similar to this https://github.com/trevnorris/node/commit/907f1409e702bf59d84297067c4d0b2c11f21c0a
21:21:20  <trevnorris>indutny: yeah. I reordered the commits so the ones not directly relating to asynclistners go first. just trying to break up the near 5000 line change into smaller stuff :)
21:21:33  <indutny>ahha
21:21:34  <indutny>finally
21:25:34  <trevnorris>tjfontaine: naughty naughty, think sblom already brought this up: 61ccaf9a (doc/api/addon.markdown) :)
21:26:36  <tjfontaine>ya, I'll fix it or you can
21:26:41  <tjfontaine>no biggie, it happens
21:26:52  <trevnorris>tjfontaine: sblom fixed it in https://github.com/joyent/node/pull/6436
21:27:15  <tjfontaine>ok then land it :)
21:27:45  <trevnorris>tjfontaine: and yeah. just giving you a hard time. a missed diff in the docs on a dev branch after merging stable is the least of anyones worries right now ;)
21:28:12  <tjfontaine>:)
21:29:03  <indutny>tjfontaine: all LGTM, except few nits
21:29:05  <indutny>err
21:29:06  <indutny>trevnorris: ^
21:29:07  <indutny>commented
21:29:14  <trevnorris>indutny: thanks :)
21:29:17  <indutny>brb
21:29:22  <indutny>you're welcome
21:29:32  <trevnorris>indutny: all your pr's on node, or some on libuv?
21:33:27  * AvianFluquit (Remote host closed the connection)
21:36:28  * AvianFlujoined
21:42:49  * defunctzombie_zzchanged nick to defunctzombie
21:51:34  <trevnorris>tjfontaine: is the release still happening today?
21:52:03  <tjfontaine>yes, can you go ahead and land sbloms thing?
21:52:16  <trevnorris>tjfontaine: not a problem, that was my next question :)
21:53:01  <tjfontaine>I have to do the libuv release, integrate that, and then we'll kick off the release
21:54:00  <trevnorris>ok. almost have his patch ready. learned from past mistakes what to check for so I don't have the urge to force push ;)
21:54:29  <MI6>joyent/node: Scott Blomquist master * a9a53ca : doc: Update documentation to reflect ObjectWrap changes (+1 more commits) - http://git.io/GTfMSQ
21:54:32  <tjfontaine>trevnorris++
21:54:33  <trevnorris>tjfontaine: ^
21:54:41  <trevnorris>heh. just for you tjfontaine
21:54:42  <tjfontaine>slowing down the pushes is a GoodThing(tm)
21:54:48  <tjfontaine>even when it's to fix things I break
21:55:25  <trevnorris>haha. yeah. it's a pretty crappy thing to break something else in a hurry to fix something you broke.
21:56:38  <bnoordhuis>indutny: still around?
21:56:45  <indutny>yes
21:56:46  <indutny>lurking around
21:56:53  <bnoordhuis>so that was you
21:57:01  <bnoordhuis>what PRs did you want me to look at?
21:57:09  <indutny>one sec
21:58:05  <indutny>https://github.com/joyent/node/pull/6428 , https://github.com/joyent/libuv/pull/970, https://github.com/joyent/libuv/pull/965
21:58:07  <indutny>bnoordhuis: ^
21:58:24  <indutny>don't concentrate that much on the first one
21:58:33  <bnoordhuis>okay
21:58:36  <indutny>I just put it here for completeness
21:59:35  <trevnorris>alright, if no one has any other concerns i'm going to go ahead and land https://github.com/joyent/node/pull/6437 . it's just the first 5 commits of 6011.
21:59:56  <MI6>joyent/libuv: Timothy J Fontaine master * b45e3cc : Now working on v0.11.15 (+1 more commits) - http://git.io/Hvr22g
21:59:58  <MI6>joyent/libuv: tjfontaine created tag v0.11.14 - http://git.io/PopB1A
22:00:25  <trevnorris>crap! I was hoping to get those in before the release. oh well, guess they're just internal changes anyways.
22:00:33  <tjfontaine>get what in?
22:00:44  <othiym23>is 6011 in?
22:00:46  <tjfontaine>no
22:00:51  <trevnorris>haha, no. https://github.com/joyent/node/pull/6428
22:00:53  <tjfontaine>6011 is happening immediately after release
22:01:14  <trevnorris>ah, if that's the case I have about a dozen commits I need to squash.
22:01:22  <tjfontaine>oh 6428 can wait, it's been so long for a release, changelog is going to be a sonofabitch
22:01:31  <indutny>trevnorris: first of 6011?
22:01:40  <indutny>so we'll still have to review 6006
22:02:31  <indutny>trevnorris: lets land this shit in
22:02:33  <indutny>trevnorris: :P
22:02:48  <trevnorris>indutny: first 5 commits of 6011 are changes that don't directly relate to the async listener patch, but made life easier. hence why I opened 6428. the one you already reviewed.
22:02:58  <indutny>trevnorris: that was a joke, sorry
22:03:09  <trevnorris>oh
22:03:11  <indutny>like you has 6011 commits to review
22:03:18  <indutny>and 6006 were left
22:03:22  <indutny>after reviewing
22:03:23  <indutny>5
22:03:26  <trevnorris>ah, hehe. got it.
22:03:36  <indutny>well, its not fun at all
22:03:38  <indutny>after all
22:03:39  <indutny>:P
22:04:51  <trevnorris>ok. just going to add one more example to the documentation. that should give me a 4,500 line change PR. :P
22:05:39  * loladiroquit (Quit: loladiro)
22:07:57  <bnoordhuis>https://github.com/joyent/libuv/pull/975 <- so nice!
22:08:26  <bnoordhuis>eliminates the clock_gettime() syscalls entirely
22:08:37  <indutny>Ж)
22:08:39  <indutny>really?
22:08:46  <indutny>oooh
22:08:47  <indutny>2.6.32
22:09:21  <bnoordhuis>yeah. it falls back to good ol' CLOCK_MONOTONIC with older kernel
22:09:25  <bnoordhuis>*kernels
22:09:38  <indutny>sad that its ubuntu-only
22:09:46  <MI6>nodejs-master: #652 UNSTABLE smartos-ia32 (8/654) smartos-x64 (10/654) osx-ia32 (1/654) http://jenkins.nodejs.org/job/nodejs-master/652/
22:09:52  <bnoordhuis>come again?
22:10:20  * dshaw_joined
22:11:08  <trevnorris>ok, landing https://github.com/joyent/node/pull/6437 to make the next v0.11 release.
22:11:09  <indutny>bnoordhuis: well, I don't know what mach_absolute_time does internally
22:11:18  <indutny>bnoordhuis: but I'm quite sure it goes to kernel anyway
22:11:37  <bnoordhuis>oh... you mean 'linux only'
22:11:53  <bnoordhuis>yeah, os x doesn't have a vdso or anything like it
22:12:00  <bnoordhuis>but who cares about os x anyway?
22:12:09  <indutny>I do
22:12:10  <indutny>a bit
22:12:14  <othiym23>I do!
22:12:19  * pachetquit (Ping timeout: 272 seconds)
22:12:41  <MI6>joyent/node: Trevor Norris master * 613d76e : src: shorten Object{Wrap,Unwrap} (+4 more commits) - http://git.io/oSePKA
22:12:59  <indutny>bnoordhuis: not that i enjoy it
22:13:06  <indutny>bnoordhuis: but I like some aspect of it
22:13:11  <indutny>bnoordhuis: mostly the UI
22:13:24  <indutny>sadly fonts are still awful in windows and ubuntu
22:13:38  * pachetjoined
22:13:38  * pachetquit (Changing host)
22:13:38  * pachetjoined
22:13:38  * pachetquit (Client Quit)
22:14:05  <bnoordhuis>meh. real men only need 8px monospace
22:14:19  <bnoordhuis>a line printer is acceptable too
22:15:37  <trevnorris>do you code with magnifying glasses? or just have a 30 inch monitor. 8 px is tiny.
22:16:03  * loladirojoined
22:16:09  <indutny>bnoordhuis: it hurt my eyes
22:16:11  <indutny>sorry
22:16:25  <indutny>I'd rather read binary data on the screen
22:16:33  * sblomjoined
22:16:45  <trevnorris>sblom: hey thanks. we landed your patch :)
22:16:59  <sblom>trevnorris: cool--thanks
22:17:07  * octetcloudquit (Ping timeout: 272 seconds)
22:17:10  <othiym23>I run at 11px and people regularly are astonished that I can still see
22:17:59  <trevnorris>man, no idea how i'm going to cleanup the commit history on 6011. that thing is a mess.
22:18:36  <indutny>sblom: any chance to improve fonts in windows?
22:18:47  <indutny>sblom: I've started spending more time in it recently
22:19:06  <indutny>(sorry, that was messed up russian humour)
22:19:27  <bnoordhuis>that's not something you see every day
22:19:30  <sblom>indutny: Sure--I'll get right on that.
22:19:37  <bnoordhuis>the words 'russian' and 'humour' in the same sentence, i mean
22:19:38  <indutny>thanks
22:19:50  <sblom>Damn. Missed an opportunity. Should've said. "Thanks for your interest. Will accept pull requests."
22:20:44  <bnoordhuis>to which fedor would've replied: "cool, where can i fork windows?"
22:21:08  <indutny>bnoordhuis: I'll continue reviewing tomorrow
22:21:10  <indutny>going to sleep now
22:21:18  <indutny>sblom: forking windows
22:21:23  <indutny>that's what I always wanted to do
22:21:29  <MI6>nodejs-master-windows: #442 UNSTABLE windows-x64 (27/654) windows-ia32 (28/654) http://jenkins.nodejs.org/job/nodejs-master-windows/442/
22:21:47  <indutny>in a good sense
22:22:55  <bnoordhuis>fedor could fork windows all night long and never tire of it
22:23:12  <bnoordhuis>anyway, sleep tight, fedor
22:23:25  <bnoordhuis>i'll take a peek at #965
22:24:11  * sblomquit (Ping timeout: 245 seconds)
22:31:30  <trevnorris>bnoordhuis: so I was thinking, using async listener. if you were attached in debug mode and it errored it'd be possible to get the stack of handles that are attached the the c++ classes.
22:31:30  <trevnorris>so technically you think it would be possible to write a native module where you could hand off a handle and inspect the c++ class state from js?
22:33:06  <tjfontaine>no more landing on master until I get uv integrated
22:34:33  <bnoordhuis>trevnorris: um, i guess anything is possible. why would you want to though?
22:35:59  <trevnorris>bnoordhuis: i dunno. thought of it while creating the long stack trace script. that I could pause on an event and inspect the js objects in the asynchronous call stack.
22:36:13  <trevnorris>and though, hey wonder if this could be done for the native side as well.
22:37:36  <trevnorris>i'm new to this whole advanced debugging thing. just never needed to use it before I guess. so was exploring ways this new api could be used.
22:38:01  <bnoordhuis>it's interesting how you approach things :)
22:38:05  <MI6>nodejs-master: #653 UNSTABLE smartos-ia32 (9/654) linux-x64 (2/654) smartos-x64 (12/654) http://jenkins.nodejs.org/job/nodejs-master/653/
22:38:30  <trevnorris>heh, how do you mean?
22:40:27  <bnoordhuis>hm, i approach programming with a utilitarian mindset: i want to be able to do this thing (whatever 'this thing' is), then i work my way from there until i can
22:40:37  <bnoordhuis>you seem to take a more exploratory approach
22:40:49  <bnoordhuis>i.e. "i wrote this thing, now what can i use it for?"
22:41:04  <bnoordhuis>i may be wholly off the mark here, of course
22:41:48  <trevnorris>haha. yeah. guess I do. usually it's a byproduct of trying to achieve something else. like the smalloc api, and figuring out I can attach data to almost anything (e.g. a function).
22:42:15  <trevnorris>just wanted to make buffers faster, then I realized it had other uses (useless or not, could still do it!)
22:44:02  <trevnorris>bnoordhuis: but it's nice to have you around because you can so quickly tell me when I'm about to do something that will A) kill me or B) just won't work. so it makes exploring crazy stuff so much funner. :)
22:44:33  <bnoordhuis>hah, nice to hear :)
22:46:05  * AvianFluquit (Remote host closed the connection)
22:46:07  * rendarquit (Quit: Leaving)
22:46:13  <piscisaureus_>ok i laughed
22:46:33  * AvianFlujoined
22:51:45  * AvianFluquit (Remote host closed the connection)
22:52:14  * FROGGSquit (Ping timeout: 240 seconds)
22:52:53  * sblomjoined
22:53:48  * kazuponjoined
22:55:00  * loladiroquit (Quit: loladiro)
22:55:14  * loladirojoined
22:55:47  * mikealquit (Quit: Leaving.)
22:56:41  * luxigo_joined
22:58:44  <sblom>CAPSLOCKBOT_: How are you related to LOUDBOT?
23:01:48  <isaacs>sblom: CAPSLOCKBOT_ is indeed related to LOUDBOT
23:02:20  <isaacs>sblom: CAPSLOCKBOT_'s raison d'etre is to boot people from rooms if they do not chat in all caps on capslock day
23:02:23  * isaacsbooted CAPSLOCKBOT_ (CAPSLOCKBOT_)
23:02:26  <isaacs>KAPOW
23:03:49  * sblomquit (Read error: Connection reset by peer)
23:04:45  * sblomjoined
23:04:58  * kazuponquit (Remote host closed the connection)
23:05:25  * kazuponjoined
23:05:30  <sblom>isaacs: oh, neat.
23:05:41  * FROGGSjoined
23:07:18  <SquirrelCZECH>guy
23:07:19  <SquirrelCZECH>s
23:07:54  <SquirrelCZECH>does anybody ever tried "tty_handle" on for example arduino or something?
23:07:55  <SquirrelCZECH>simply, any device that you would normally control with "pySerial" ?
23:08:08  <SquirrelCZECH>or, serial...
23:08:15  * SquirrelCZECHstill forgots that this is libuv and not pyuv :D
23:09:05  <sblom>SquirrelCZECH: If no one here speaks up, a lot of the folks who might know hang out in #Node.js
23:10:01  <SquirrelCZECH>sblom: true to that! :-)
23:10:07  * kazuponquit (Ping timeout: 268 seconds)
23:10:51  * Kakera_quit (Ping timeout: 252 seconds)
23:13:32  <sblom>SquirrelCZECH: What are you trying to do?
23:13:47  <SquirrelCZECH>sblom: just connect to arduino-like device
23:13:57  <SquirrelCZECH>sblom: '/dev/ttyUSB0'
23:14:15  <sblom>SquirrelCZECH: Cool.
23:15:18  <SquirrelCZECH>sblom: yep, thought that ttyHandle from pyuv would be just enough
23:15:31  <SquirrelCZECH>but it seems that it doesn't work :-/
23:21:05  <SquirrelCZECH>nah
23:21:09  <SquirrelCZECH>found library for Node.js
23:21:17  <SquirrelCZECH>don't understand even single line of code
23:21:22  * SquirrelCZECHshould learn c/c++ one day
23:22:13  * loladiroquit (Quit: loladiro)
23:23:56  * c4milo_quit (Remote host closed the connection)
23:26:36  * indexzeroquit (Quit: indexzero)
23:31:40  * FROGGSquit (Ping timeout: 264 seconds)
23:47:58  <MI6>joyent/node: Timothy J Fontaine master * 74a664b : fs_event_wrap: update to new libuv api (+1 more commits) - http://git.io/EEubNQ
23:50:30  <trevnorris>tjfontaine: sure you saw this, but you have 0.10.x change log entries mixed w/ v0.11.x entries.
23:50:37  <trevnorris>so there're duplicates
23:51:14  <trevnorris>tjfontaine: oh wait. nm
23:51:19  <trevnorris>didn't see that's for libuv
23:51:35  * SquirrelCZECH_joined
23:53:12  * mmaleckijoined
23:54:01  * bnoordhuisquit (Ping timeout: 272 seconds)
23:54:04  * LOUDBOT_joined
23:55:28  <trevnorris>wow, that libuv ChangeLog is sort of a pain to read. wonder why they didn't order the commits by the actual commit
23:58:10  * mmalecki_quit (*.net *.split)
23:58:10  * SquirrelCZECHquit (*.net *.split)
23:58:11  * LOUDBOTquit (*.net *.split)