00:00:01  * ircretaryquit (Remote host closed the connection)
00:00:10  * ircretaryjoined
00:00:24  * dap_1quit (Quit: Leaving.)
00:04:30  * daviddiasquit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
00:07:43  * c4milojoined
00:10:03  * quijotejoined
00:12:20  * avalanche123quit (Remote host closed the connection)
00:12:48  * avalanche123joined
00:14:19  * avalanche123quit (Remote host closed the connection)
00:14:25  * avalanche123joined
00:14:33  * quijotequit (Ping timeout: 240 seconds)
00:19:45  * wavdedjoined
00:24:20  * seishunquit (Ping timeout: 240 seconds)
00:29:21  * zz_karupachanged nick to karupa
00:36:15  * inolenquit (Quit: Leaving.)
00:40:48  * inolenjoined
00:46:35  * dsantiagoquit (Ping timeout: 272 seconds)
00:52:35  * dsantiagojoined
00:53:50  * avalanche123quit (Remote host closed the connection)
00:54:17  * avalanche123joined
00:55:23  * cjihrigjoined
00:58:42  * avalanche123quit (Ping timeout: 260 seconds)
01:02:49  * wavdedquit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
01:08:27  * WalrusPony1joined
01:10:39  * WalrusPonyquit (Ping timeout: 255 seconds)
01:10:48  * quijotejoined
01:13:32  <mmalecki>hmm, does anyone know what http_parser_execute return value means exactly?
01:15:18  * quijotequit (Ping timeout: 246 seconds)
01:18:19  * kazuponjoined
01:18:48  <nathan7>mmalecki: let's dive into node?
01:20:12  <mmalecki>it's number of parsed characters
01:20:15  <mmalecki>I'll document it.
01:36:29  * kazuponquit (Read error: No route to host)
01:36:35  * kazuponjoined
01:39:34  * yunongquit (Ping timeout: 255 seconds)
01:41:44  * SquirrelCZECHquit (Quit: No Ping reply in 180 seconds.)
01:42:17  * brsonquit (Quit: leaving)
01:43:10  * SquirrelCZECHjoined
01:44:29  * kazupon_joined
01:48:10  * kazuponquit (Ping timeout: 260 seconds)
01:49:48  * wavdedjoined
01:51:29  <othiym23>does anybody know for sure if there are OSes on which file renames are not atomic?
01:51:49  <othiym23>and does anybody know if there are any (other) guaranteed atomic fs operations in libuv?
01:52:01  <othiym23>need it for a thing
01:58:13  * kazupon_quit (Remote host closed the connection)
01:58:40  * kazuponjoined
02:00:53  * abraxasjoined
02:06:50  <nathan7>othiym23: I figure POSIX guarantees it
02:07:32  <nathan7>othiym23: other than flock and friends and rename and O_EXCL|O_CREAT, I can't think of any
02:07:45  <nathan7>othiym23: but I'm probably not the person you wanted to hear from [=
02:09:17  * SquirrelCZECHquit (Quit: No Ping reply in 180 seconds.)
02:11:44  * quijotejoined
02:12:29  * SquirrelCZECHjoined
02:12:31  <othiym23>just wondering if there's some wiggliness in Windows to be worried about
02:13:11  <othiym23>and also nathan7 <3 I'm just trying to get the problem solved here, and spent most of the day working with your code
02:15:50  <nathan7>othiym23: hope you like it [=
02:15:51  * quijotequit (Ping timeout: 246 seconds)
02:16:15  * nathan7is just going mad staring at heap snapshot diffs
02:18:57  * jreyno40joined
02:19:09  <jreyno40>I’m having a problem with libuv
02:19:10  <jreyno40>:(
02:19:23  <jreyno40>I think I may be getting race conditions or something
02:20:10  <jreyno40>Assertion failed: (uv__has_active_reqs(handle->loop)), function uv__udp_run_completed, file src/unix/udp.c, line 97.
02:23:55  <jreyno40>:(
02:28:29  * jreyno40quit (Ping timeout: 255 seconds)
02:28:32  * jreyno40_joined
02:28:41  * Left_Turnquit (Remote host closed the connection)
02:28:44  * jreyno40joined
02:29:28  <nathan7>jreyno40: are you threading or something?
02:30:00  <jreyno40_>nathan7: Not trying to; working on an open-source library that is using a libuv udp event loop running on NOWAIT
02:30:12  <jreyno40_>it appears that when calling uv_udp_send in quick succession
02:30:35  <jreyno40_>maybe uv_run is being called too many times or not enough..
02:30:45  <jreyno40_>I don’t know enough about libuv to diagnose the issue
02:32:53  <jreyno40>so I think this code is threaded
02:33:21  <jreyno40_>what does uv_run do?
02:37:47  * c4miloquit (Remote host closed the connection)
02:45:17  <nathan7>jreyno40_: uv_run() runs an event loop tick
02:45:31  <jreyno40_>nathan7: which does?
02:45:39  <nathan7>jreyno40_: handle events
02:45:59  <jreyno40_>nathan7: okay, so when I call uv_udp_send it adds an event to the event look
02:46:01  <jreyno40_>loop*
02:46:02  <jreyno40_>correct?
02:46:13  <nathan7>jreyno40_: well, no, when the send *completes* it fires an event
02:46:28  <nathan7>jreyno40_: but you can use an event loop in one thread only
02:46:35  * indexzerojoined
02:46:36  <nathan7>jreyno40_: like, you can't just use it across multiple threads
02:46:44  <jreyno40_>nathan7: gotcha
02:46:51  <nathan7>jreyno40_: if you call uv_udp_send with that event loop in another thread, things go horribly wrong
02:47:03  <jreyno40_>nathan7: So what’s happening
02:47:12  <nathan7>jreyno40_: I'm not sure
02:47:26  <jreyno40_>nathan7: is that uv_udp_send is being called twice in a row with the same callback function
02:47:40  <jreyno40_>the callback function frees the “req"
02:47:41  <nathan7>jreyno40_: no, they'd create separate uv_reqs
02:48:04  <jreyno40_>nathan7: I’m saying this is how my code is structured
02:48:18  <nathan7>jreyno40_: okay
02:48:34  <nathan7>jreyno40_: they'd still create separate uv_reqs
02:48:42  <nathan7>afaict
02:49:04  <nathan7>are you /certain/ you're not doing thread-unsafe stuff
02:49:27  <jreyno40_>nathan7: I didn’t write this code, but I’m fairly certain
02:49:47  <jreyno40_>nathan7: just using a “uv_default_loop"
02:50:05  <nathan7>jreyno40_: yeah, but if you're calling uv_run in a diff thread than the uv_udp_send…
02:50:22  <nathan7>jreyno40_: I can't see your code, but it's the one thing that feels very likely
02:51:04  <jreyno40_>nathan7: actually no
02:51:11  <jreyno40_>nathan7: I’m positive it’s all in one thread
02:51:20  <nathan7>jreyno40_: okay
02:52:04  <nathan7>jreyno40_: the callback is called correctly, two invocations with two different reqs?
02:52:21  <jreyno40_>callback? sorry, do you mean uv_udp_send?
02:52:54  <nathan7>I'm guessing you're passing a callback to that
02:53:00  <jreyno40_>nathan7: yes, I am
02:53:09  <nathan7>that callback
02:53:14  <nathan7>is it called correctly?
02:53:27  <jreyno40_>nathan7: it’s inside of that callback a lot of issues seem to be happening
02:53:37  <jreyno40_>nathan7: it appears to be attempting to free the same memory twice
02:53:44  <nathan7>jreyno40_: that's bad
02:53:50  <nathan7>err
02:53:54  <jreyno40_>nathan7: and I’m getting that Assertion: thing
02:53:57  <nathan7>now here I'd run it with libumem in debug mode
02:54:04  <nathan7>but I'm guessing you're on Linux or OS X or something
02:54:05  <jreyno40_>“Assertion failed: (uv__has_active_reqs(handle->loop)), function uv__udp_run_completed, file src/unix/udp.c, line 97.”
02:54:10  <jreyno40_>nathan7: I’m on OSX
02:54:13  <nathan7>yeah
02:54:19  <nathan7>I tend to debug on Solaris
02:54:32  <nathan7>maybe valgrind?
02:54:44  <jreyno40_>okay; I’m not too experienced with valgrind
02:54:49  <jreyno40_>nathan7: But I’ll give it a shot
02:54:52  <nathan7>I basically scream incessantly whenever I can't reproduce crashses on Solaris
02:55:01  <nathan7>because I want to avoid being experienced with valgrind
02:55:14  <nathan7>gdb has damaged me enough
02:55:30  <nathan7>as cryptic as mdb sometimes is
02:55:53  <nathan7>I don't think I've actually ever used valgrind
02:55:54  * nathan7installs
02:56:02  <nathan7>clearly an excellent idea at 5AM
02:56:45  <jreyno40_>nathan7: haha
02:56:55  <jreyno40_>nathan7: yeah I’m brew installing it right now
02:57:30  * bradleymeckquit (Quit: bradleymeck)
02:57:56  <nathan7>"this thing has a manpage, right"
02:59:28  <jreyno40_>nathan7: So what do you think could be happening? Any thoughts?
02:59:39  <jreyno40_>It seems the same callback for the same event is being called twice
03:01:09  * bradleymeckjoined
03:02:18  <nathan7>jreyno40_: dunno, I'm not too much of a libuv person :|
03:02:31  <jreyno40_>nathan7: Ahh; Well thanks for the help anyhow
03:02:32  <nathan7>jreyno40_: but something very odd is happening for sure
03:02:50  <nathan7>multiple requests for the same thing are still multiple distinct requests
03:07:03  * nsmquit (Ping timeout: 240 seconds)
03:07:22  * nsmjoined
03:09:00  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
03:10:34  * pguilloryjoined
03:12:27  * quijotejoined
03:16:44  * quijotequit (Ping timeout: 240 seconds)
03:17:14  <jreyno40_>nathan7: When will the uv_udp_send callback be called?
03:17:36  * avalanche123joined
03:19:58  <nathan7>jreyno40_: when the send completes according to the OS
03:22:12  * avalanche123quit (Ping timeout: 272 seconds)
03:25:05  * mikealjoined
03:27:06  * kazuponquit (Remote host closed the connection)
03:36:15  * mikealquit (Quit: Leaving.)
03:39:49  * rmgquit (Remote host closed the connection)
03:40:04  * TooTallNatequit (Quit: Computer has gone to sleep.)
03:40:16  * TooTallNatejoined
03:45:42  * rmgjoined
03:46:11  * mikealjoined
03:48:59  * rmgquit (Remote host closed the connection)
03:49:34  * rmgjoined
03:49:39  * eugeneware__joined
03:49:51  * groundwater_joined
03:52:26  * brycebar1ljoined
03:52:44  * groundwaterquit (Ping timeout: 250 seconds)
03:52:44  * eugeneware_quit (Ping timeout: 250 seconds)
03:52:46  * brycebarilquit (Ping timeout: 250 seconds)
03:53:00  * eugeneware__changed nick to eugeneware_
03:53:07  * groundwater_changed nick to groundwater
03:53:32  * c4milojoined
03:53:42  * yunongjoined
03:53:53  * jgiquit (Quit: jgi)
03:54:00  * rmgquit (Ping timeout: 255 seconds)
03:54:01  * yunongquit (Client Quit)
03:55:12  * groundwaterquit
03:55:52  * groundwaterjoined
03:58:19  * jreyno40_quit (Quit: jreyno40_)
03:58:19  * jreyno40quit (Quit: jreyno40)
03:58:29  * c4miloquit (Ping timeout: 272 seconds)
04:00:34  * bradleymeckquit (Quit: bradleymeck)
04:02:43  * euoia_joined
04:07:08  * avalanche123joined
04:07:15  * bradleymeckjoined
04:13:07  * quijotejoined
04:17:51  * wavdedquit (Quit: Textual IRC Client: www.textualapp.com)
04:17:58  * quijotequit (Ping timeout: 260 seconds)
04:18:17  * kazuponjoined
04:18:56  * kazuponquit (Remote host closed the connection)
04:18:58  * kazupon_joined
04:20:08  * rmgjoined
04:21:21  * SquirrelCZECHquit (Quit: No Ping reply in 180 seconds.)
04:21:28  * avalanche123quit (Remote host closed the connection)
04:21:54  * avalanche123joined
04:22:47  * SquirrelCZECHjoined
04:25:37  * rmgquit (Ping timeout: 255 seconds)
04:26:28  * avalanche123quit (Ping timeout: 250 seconds)
04:30:34  * euoia_quit (Ping timeout: 260 seconds)
04:33:49  * cjihrigquit (Quit: Leaving.)
04:35:07  * indexzeroquit (Quit: indexzero)
04:43:35  * indexzerojoined
04:48:59  * avalanche123joined
04:50:21  * indexzeroquit (Quit: indexzero)
04:52:09  * inolenquit (Quit: Leaving.)
04:56:05  * inolenjoined
04:59:20  * AvianFluquit (Read error: Connection reset by peer)
05:10:57  * SquirrelCZECH_joined
05:11:00  * SquirrelCZECHquit (Write error: Broken pipe)
05:13:13  * inolenquit (Quit: Leaving.)
05:14:01  * quijotejoined
05:14:34  * sblomquit (Remote host closed the connection)
05:14:40  * sblomjoined
05:17:57  * indexzerojoined
05:18:03  * quijotequit (Ping timeout: 240 seconds)
05:26:30  * TooTallNatequit (Quit: Computer has gone to sleep.)
05:28:21  * avalanche123quit (Remote host closed the connection)
05:28:48  * avalanche123joined
05:33:14  * inolenjoined
05:33:25  * avalanche123quit (Ping timeout: 260 seconds)
05:39:04  * daviddiasjoined
05:41:50  * c4milojoined
05:46:18  * c4miloquit (Ping timeout: 250 seconds)
06:14:39  * quijotejoined
06:15:35  * inolenquit (Quit: Leaving.)
06:19:28  * quijotequit (Ping timeout: 255 seconds)
06:24:52  * rmgjoined
06:29:41  * rmgquit (Ping timeout: 255 seconds)
06:37:22  * Ralithjoined
06:45:46  * daviddiasquit (Quit: Textual IRC Client: www.textualapp.com)
06:47:08  * daviddiasjoined
06:48:06  * daviddiasquit (Client Quit)
06:48:25  * daviddiasjoined
06:50:06  * quijotejoined
06:51:52  * SquirrelCZECH_quit (Quit: No Ping reply in 180 seconds.)
06:53:04  * SquirrelCZECHjoined
06:57:29  * inolenjoined
07:12:33  * daviddiasquit (Ping timeout: 240 seconds)
07:14:18  * avalanche123joined
07:15:10  * Left_Turnjoined
07:15:32  * pguilloryquit (Ping timeout: 240 seconds)
07:18:32  * rendarjoined
07:19:02  * avalanche123quit (Ping timeout: 260 seconds)
07:19:22  <saghul|afk>indutny: pang, will test
07:19:26  <indutny>heya
07:19:26  * indexzeroquit (Quit: indexzero)
07:19:28  <indutny>np
07:19:30  <indutny>I figured it out
07:19:34  <indutny>running tests right now
07:21:15  * Soarez|afkchanged nick to Soarez
07:22:43  <indutny>yay
07:22:44  <indutny>it is working
07:22:45  <indutny>finally :)
07:23:10  <indutny>saghul|afk: wanna review?
07:27:48  * inolenquit (Quit: Leaving.)
07:29:29  <indutny>saghul|afk: anyway, https://github.com/joyent/libuv/pull/1420
07:30:06  * c4milojoined
07:32:58  * inolenjoined
07:33:46  * Ralithquit (Ping timeout: 250 seconds)
07:34:38  * c4miloquit (Ping timeout: 250 seconds)
07:36:09  * janjongboomjoined
07:40:43  * dignifiedquirejoined
07:57:07  * inolenquit (Quit: Leaving.)
07:57:17  * saghul|afkchanged nick to saghul
07:57:29  <saghul>indutny: thanks! left some comments
08:23:30  * quijotequit (Ping timeout: 250 seconds)
08:25:09  <indutny>saghul: thanks
08:25:10  <indutny>replied
08:30:45  * quijotejoined
08:53:42  * a3fjoined
09:04:36  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
09:05:27  * petka_joined
09:10:21  * Soarezchanged nick to Soarez|afk
09:18:22  * c4milojoined
09:18:52  * janjongboomjoined
09:23:22  * c4miloquit (Ping timeout: 264 seconds)
09:28:03  * Ralithjoined
09:43:03  * sinclair|workquit (Quit: ChatZilla 0.9.90.1 [Firefox 31.0/20140716183446])
10:01:40  * kazupon_quit (Remote host closed the connection)
10:03:15  * kazuponjoined
10:08:51  * Soarez|afkchanged nick to Soarez
10:13:20  * Ralithquit (Ping timeout: 255 seconds)
10:13:43  * sh1mmerquit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
10:15:54  * quijotequit (Ping timeout: 260 seconds)
10:16:58  * bajtosjoined
10:23:10  * kazuponquit (Read error: Connection reset by peer)
10:23:14  * kazupon_joined
10:26:47  * abraxasquit (Remote host closed the connection)
10:32:43  * Soarezchanged nick to Soarez|afk
10:38:37  * Soarez|afkchanged nick to Soarez
10:43:18  * quijotejoined
10:47:22  * quijotequit (Ping timeout: 240 seconds)
10:47:37  * seishunjoined
11:06:44  * c4milojoined
11:11:21  * c4miloquit (Ping timeout: 246 seconds)
11:22:06  * karupachanged nick to zz_karupa
11:23:34  * Soarezchanged nick to Soarez|afk
11:37:34  * _3rdEdenchanged nick to `3rdEden
11:38:04  * `3rdEdenchanged nick to _3rdEden
11:41:22  * c4milojoined
11:43:55  * quijotejoined
11:46:20  * c4miloquit (Ping timeout: 272 seconds)
11:46:45  * kellabytejoined
11:47:37  * bradleymeckquit (Quit: bradleymeck)
11:48:17  * quijotequit (Ping timeout: 255 seconds)
11:49:21  * AlexisMocha_quit (Read error: Connection reset by peer)
11:52:43  * AlexisMochajoined
11:57:22  * janjongboomquit (Ping timeout: 245 seconds)
11:58:26  * janjongboomjoined
12:21:17  * rmgjoined
12:25:52  * rmgquit (Ping timeout: 260 seconds)
12:30:33  * a3fquit (Ping timeout: 240 seconds)
12:32:27  * ircretaryquit (Remote host closed the connection)
12:32:37  * ircretaryjoined
12:39:27  * sinclair|workjoined
12:44:27  * quijotejoined
12:47:36  * Soarez|afkchanged nick to Soarez
12:48:57  * quijotequit (Ping timeout: 245 seconds)
12:58:38  * a3fjoined
13:06:58  * andrehjrjoined
13:09:18  * guybrushquit (Excess Flood)
13:09:36  * bradleymeckjoined
13:10:01  * guybrushjoined
13:10:24  * quijotejoined
13:22:01  <MI6>joyent/libuv: Fedor Indutny master * ab2c442 : fs: introduce uv_readdir_next() and report types - http://git.io/3mk3Jg
13:23:31  <indutny>yay!
13:24:21  <saghul>\o/
13:27:53  <mmalecki>ohhh!
13:27:55  <mmalecki>sweet!
13:28:01  <mmalecki>do we have a node binding yet?
13:28:08  * euoia_joined
13:28:49  <mmalecki>btw, I started working on: https://github.com/mmalecki/http-parser.rs, maybe Rust will finally get actual HTTP
13:29:36  * kazupon_quit (Remote host closed the connection)
13:29:41  * c4milojoined
13:29:50  <bradleymeck>nice
13:33:56  * c4miloquit (Ping timeout: 240 seconds)
13:48:28  * cjihrigjoined
13:48:28  * cjihrigquit (Client Quit)
13:55:49  * inolenjoined
13:56:22  * kellabytequit (Quit: Connection closed for inactivity)
13:57:11  * inolenquit (Client Quit)
13:58:50  * inolenjoined
13:58:50  * inolenquit (Client Quit)
14:01:46  * euoia_quit (Ping timeout: 260 seconds)
14:04:11  * SquirrelCZECHquit (Remote host closed the connection)
14:05:31  * mikealquit (Quit: Leaving.)
14:06:53  * inolenjoined
14:07:15  * dignifiedquirequit (Quit: dignifiedquire)
14:09:14  * inolenquit (Client Quit)
14:11:54  * inolenjoined
14:16:03  * inolenquit (Ping timeout: 240 seconds)
14:17:19  * quijotequit (Read error: Connection reset by peer)
14:17:25  * quijote_joined
14:17:44  * inolenjoined
14:17:56  * indexzerojoined
14:19:09  * cjihrigjoined
14:22:19  * inolenquit (Ping timeout: 272 seconds)
14:22:28  * euoia_joined
14:26:44  * cjihrigquit (Ping timeout: 260 seconds)
14:28:37  * janjongboomquit (Ping timeout: 245 seconds)
14:28:45  * abraxasjoined
14:29:22  * c4milojoined
14:29:29  * inolenjoined
14:29:57  * janjongboomjoined
14:30:45  * dignifiedquirejoined
14:33:43  * abraxasquit (Ping timeout: 272 seconds)
14:35:37  * quijote_quit (Ping timeout: 272 seconds)
14:36:20  * wavdedjoined
14:36:52  <dainis>hmm, what guarantees does node timeoutHave, because right now I have an issue that 500ms timeout is fired after ~100ms
14:37:08  <dainis>node 0.10.30
14:38:46  * kenperkinsquit (Remote host closed the connection)
14:42:07  * inolenquit (Quit: Leaving.)
14:42:46  * quijotejoined
14:44:58  * a3fquit (Quit: ChatZilla 0.9.90.1 [Firefox 31.0/20140716183446])
14:45:48  <indutny>dainis: this is very strange
14:45:54  <indutny>dainis: on which OS do you see it?
14:46:01  <indutny>do you have a test case?
14:49:23  * indexzeroquit (Quit: indexzero)
14:52:02  <dainis>linux x64, can't really isolate because this happens when one the tests is run, we check whether one of the things is retried after 500ms, that is done by comparing Date.now() values, when I run just setTimeout for 500ms then callback usually gets executed after 450ms-480ms all subsequent setTimeouts execute roughly when they should, on node 0.10.28 same simple test outputs 500-503ms
14:53:15  <dainis>I did put some console logs around that setTimeout to verify that that is the culprit
14:53:59  * cjihrigjoined
14:54:07  <tjfontaine>dainis: are you able to do an out of band build of node and test to see if it still happens in our current 0.10 branch?
14:54:39  <tjfontaine>in general though 0.10.30 uses the monotonic timer and not the system time, because the system time is more susceptible to drift
14:55:19  * avalanche123joined
14:58:23  * cjihrigquit (Ping timeout: 244 seconds)
15:01:12  <tjfontaine>did anyone change the configuration of the windows slaves in jenkins?
15:03:10  * indexzerojoined
15:05:43  * seishunquit (Read error: Connection reset by peer)
15:06:12  * kenperkinsjoined
15:15:31  * kazuponjoined
15:19:05  <tjfontaine>indutny: https://github.com/joyent/node/compare/v0.10...merge-review lgty presumably?
15:19:23  * cjihrigjoined
15:25:42  <indutny>hey hey
15:26:17  * quijotequit (Ping timeout: 272 seconds)
15:26:19  <indutny>makes sense!
15:26:22  <indutny>tjfontaine: LGTM
15:26:44  <MI6>joyent/node: Fedor Indutny v0.10 * 6b97c2e : openssl: fix keypress requirement in apps on win32 (+1 more commits) - http://git.io/LYs2PA
15:26:48  <tjfontaine>gone
15:28:52  * jreyno40_joined
15:29:29  * quijotejoined
15:30:30  * mikealjoined
15:32:11  <MI6>joyent/node: Fedor Indutny v0.10 * fd80a31 : deps: backport 5f836c from v8 upstream - http://git.io/-Qgx9w
15:32:49  * avalanche123quit (Remote host closed the connection)
15:33:15  * avalanche123joined
15:33:32  * kenperkins_joined
15:34:02  * wavdedquit (Read error: Connection reset by peer)
15:37:42  * avalanche123quit (Ping timeout: 246 seconds)
15:38:00  * jgijoined
15:38:40  * kenperkinsquit (Read error: Connection reset by peer)
15:40:21  * inolenjoined
15:40:22  * inolenquit (Client Quit)
15:40:27  * janjongboomquit (Ping timeout: 245 seconds)
15:40:43  * janjongboomjoined
15:42:22  * jreyno40_quit (Quit: jreyno40_)
15:43:52  * seishunjoined
15:47:10  * dshaw_joined
15:51:16  * jreyno40_joined
15:54:11  * Soarezchanged nick to Soarez|afk
16:00:59  * avalanche123joined
16:01:25  * avalanche123quit (Remote host closed the connection)
16:01:49  * avalanche123joined
16:02:14  * wavdedjoined
16:02:38  <tjfontaine>indutny, saghul: nothign slated to go in libuv 0.10 such taht we would need a new release?
16:03:13  <tjfontaine>indutny, AlexisMocha, trevnorris, wanna have a call?
16:03:21  * avalanche123quit (Remote host closed the connection)
16:04:23  * indexzeroquit (Quit: indexzero)
16:06:20  <AlexisMocha>tjfontaine: can do a quick one. have to leave at :30
16:06:23  <txdv>indutny: did you set the enomem error now?
16:06:29  <txdv>didnt you want me to do it?
16:07:51  <tjfontaine>AlexisMocha: ok if we can't get fedor and trevor and nate today, maybe we can have one tomorrow morning, after landing trevors stuff and the libuv fix for smartos I'm relatively confident we can release the final 0.11 as an RC
16:08:02  * rmgjoined
16:09:33  <AlexisMocha>ok
16:11:34  * dap_joined
16:11:50  <tjfontaine>we need to have the unfortunate conversation about what it means to have a consistent hash key for module cache :/
16:12:07  * quijotequit (Ping timeout: 255 seconds)
16:12:51  <rendar>tjfontaine: cache for .js modules that are loaded with require() ?
16:13:21  <tjfontaine>rendar: we do that already, but we don't normalize the key, so on osx and windows you can require the same file multiple times with multiple cases and get new instances back
16:13:43  <rendar>oh, i see
16:13:53  <rendar>well, that seems pretty trivial to implement..
16:13:55  <tjfontaine>[it's really not about platform but about filesystem, but in practice most windows and osx filesystems fall prey to this]
16:14:05  <rendar>mmmm
16:14:11  <tjfontaine>rendar: trivial to implement but results in a behavior change
16:14:24  * c4miloquit (Remote host closed the connection)
16:14:27  <rendar>what kind of behavior change?
16:14:32  <tjfontaine>on a case sensitive filesystem you lose the ability to have both ./util.js and ./Util.js
16:14:36  <saghul>tjfontaine: not that I know of
16:14:42  <tjfontaine>saghul: ok thanks
16:14:52  <rendar>tjfontaine: oh...
16:15:30  <tjfontaine>rendar: we actually expand that out to the full path, but any component along that path may be case [in]sensitive
16:15:39  <rendar>well, but "util" and "Util" will have a different hash code
16:15:47  * c4milojoined
16:15:53  <tjfontaine>rendar: not on osx and windows [in practice[
16:16:10  * mcavagejoined
16:16:48  * mcavagequit (Client Quit)
16:16:58  * mcavagejoined
16:17:11  <tjfontaine>hmm I still need to do the intl review as well, that's probably going to be me today, intl and trevor review
16:17:39  <rendar>tjfontaine: possible solution: require() will be case insentivie
16:17:41  <rendar>insensitive*
16:18:13  <tjfontaine>rendar: how do you do that efficiently on case sensitive platforms?
16:18:27  <tjfontaine>[iow have you seen what wine and mono have to do to get around that?]
16:18:28  * TooTallNatejoined
16:19:32  <rendar>tjfontaine: nope, what are they doing?
16:19:57  <tjfontaine>it's just really painful, you want your open() to do just whatever the OS and FS want to do and stay out if their way
16:20:41  <tjfontaine>rendar: in short changing require to be insensitive means we now have to pick which of Util.js and util.js we open
16:20:57  <tjfontaine>I mean it's just a shift of where the responsibility is
16:21:02  <tjfontaine>but it's easier for us to manage the cache key
16:21:23  * inolenjoined
16:21:37  <rendar>tjfontaine: i see, how the cache key will be managed, basically?
16:21:44  <tjfontaine>good question ;)
16:21:47  <rendar>:)
16:23:43  <rendar>tjfontaine: btw the cache key concept is to load all .js files into memory and giving them an hash key based on their content/name?
16:25:03  * cjihrigquit (Quit: Leaving.)
16:25:30  * euoia_quit (Ping timeout: 260 seconds)
16:25:39  * cjihrigjoined
16:25:50  * avalanche123joined
16:29:35  * abraxasjoined
16:30:34  * avalanche123quit (Ping timeout: 264 seconds)
16:32:32  <tjfontaine>rendar: I hadn't particularly considered using content as part of that
16:32:46  <bradleymeck>if require does become case insensitive list of what gets checked first needs to be very careful
16:32:58  <tjfontaine>rendar: that's interesting though, but frustrating if someone changes on disk then we've introduced hot loading
16:33:52  * abraxasquit (Ping timeout: 240 seconds)
16:33:55  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
16:34:01  * avalanche123joined
16:35:06  <bradleymeck>Abc ABc aBc aBC abC AbC abc ABC, could all exist in a case sensitive directory so you would need to define for example what happens if neither pure UPPER or pure lower are present etc.
16:35:45  <bradleymeck>I would assume module authors can fix this, but \o/
16:35:46  <tjfontaine>it's particularly difficult to interpret what the user meant in these instances
16:37:00  <nathan7>tjfontaine: it might just make sense to throw
16:37:07  <nathan7>tjfontaine: refuse to load different cases
16:37:29  <tjfontaine>that's a particularly abrupt change
16:37:31  <nathan7>though that doesn't resolve the case where stuff works because the case differs
16:37:55  <tjfontaine>I think what I'm most worried about are the onslaught of new node developers on windows
16:37:59  <nathan7>yeah
16:38:04  <tjfontaine>who will almost certainly be deploying on unicies
16:38:15  <tjfontaine>and not understanding necessarily why their modules aren't found
16:38:16  <nathan7>can you get the filename given the fd?
16:38:26  <nathan7>check that the case is correct, else throw
16:38:47  <tjfontaine>there's not [afaik] a way to reliably get the on disk storage of the name
16:38:52  * quijotejoined
16:39:06  <nathan7>you'd have symlinks fucking with that anyway
16:39:07  <nathan7>:|
16:39:18  <nathan7>you'd have to do a readdir, but we already do enough stat calls on require…
16:39:20  <tjfontaine>right there are a lot of other caveats here
16:39:34  <tjfontaine>the change to key normalization is easy
16:39:43  <tjfontaine>understanding the ramifications are not
16:39:47  <nathan7>yeah
16:40:09  <nathan7>actually, could probably drop a few stat calls throwing that readdir in
16:40:28  <tjfontaine>depends on your tolerance for races :)
16:41:32  * a_lequit (Ping timeout: 240 seconds)
16:44:07  <jgi>tjfontaine: are you refering to this PR: https://github.com/joyent/node/pull/8145?
16:44:51  <rendar>tjfontaine: yeah, i see the problem
16:45:02  <rendar>tjfontaine: for hot loading you mean reloading the file at every disk change?
16:45:45  <tjfontaine>rendar: yes
16:45:51  <tjfontaine>jgi: ya, also AlexisMocha has a similar pr
16:48:10  <jgi>tjfontaine: ok, my understanding was that path.normalize changes the case only on Windows for drive letters. So requiring two different files with different cases should still work on file systems that are case sensitive.
16:48:59  * a_lejoined
16:49:02  * cjihrigquit (Quit: Leaving.)
16:49:52  * quijotequit (Ping timeout: 245 seconds)
16:50:01  * cjihrigjoined
16:51:18  <jgi>tjfontaine: but my PR doesn’t solve the more general problem, so it’s a fix for only a very tiny portion of these types of issues.
16:51:52  <tjfontaine>jgi: right
16:53:12  * kellabytejoined
16:53:45  * brycebar1lchanged nick to brycebaril
16:55:27  * kazuponquit (Remote host closed the connection)
16:58:21  * indexzerojoined
16:58:34  * brsonjoined
17:03:03  * janjongboomjoined
17:04:35  * dshaw_quit (Quit: Leaving.)
17:04:49  * cjihrigquit (Quit: Leaving.)
17:07:22  * janjongboomquit (Ping timeout: 245 seconds)
17:08:29  * sblomquit (Read error: Connection reset by peer)
17:08:32  * indexzeroquit (Quit: indexzero)
17:09:44  * quijotejoined
17:10:12  * indexzerojoined
17:11:12  * avalanch_joined
17:13:46  * avalanche123quit (Ping timeout: 255 seconds)
17:15:02  * dshaw_joined
17:16:24  * wavdedquit (Ping timeout: 246 seconds)
17:16:25  * daviddiasjoined
17:16:39  <nathan7>tjfontaine: a stat() isn't race-tolerant either
17:16:45  * quijotequit (Ping timeout: 246 seconds)
17:16:45  <nathan7>tjfontaine: well, race-safe
17:16:49  * indexzeroquit (Quit: indexzero)
17:16:59  <nathan7>tjfontaine: you'd have to open(), bailing on ENOENT
17:17:20  <nathan7>tjfontaine: maybe I am mistaken, but I thought node's require did stat() a bunch
17:19:38  * janjongboomjoined
17:23:12  <tjfontaine>nathan7: right, the open path is ideally what we would do, there are lots of cases where we can be better :)
17:23:20  * indexzerojoined
17:24:48  <nathan7>tjfontaine: I spent aages figuring out how to handle concurrency with fs stuff while writing the stuff that's becoming npm's cache now
17:24:55  * cjihrigjoined
17:24:56  * indexzeroquit (Client Quit)
17:29:04  * jreyno40_quit (Quit: jreyno40_)
17:30:19  * jreyno40joined
17:30:19  * jreyno40quit (Client Quit)
17:36:36  * mcavagequit (Remote host closed the connection)
17:42:07  * mikealquit (Quit: Leaving.)
17:43:32  * quijotejoined
17:46:12  <txdv>saghul: did indutny add the nomem return in his patch?
17:47:56  * quijotequit (Ping timeout: 240 seconds)
17:49:35  * jreyno40_joined
17:54:16  <tjfontaine>src/uv-common.c:485:11: error: 'uv__dirent_t' has no member named 'd_type'
17:54:16  <tjfontaine>src/uv-common.c:485:23: error: 'DT_DIR' undeclared (first use in this function)
17:54:17  <tjfontaine>src/uv-common.c:485:23: note: each undeclared identifier is reported only once for each function it appears in
17:54:22  <tjfontaine>saghul, indutny ^^
17:56:15  * rosskjoined
17:57:00  * quijotejoined
18:00:54  * brsonquit (Quit: leaving)
18:01:01  * brsonjoined
18:03:10  <indutny>huh?
18:03:13  <indutny>on which platform?
18:04:03  <tjfontaine>smartos
18:05:26  * kazuponjoined
18:08:22  * kenperkins_changed nick to kenperkins
18:11:03  <jreyno40_>I’m getting some weird errors with libuv
18:12:06  * wavdedjoined
18:14:08  * a_lequit (Remote host closed the connection)
18:14:43  * a_lejoined
18:14:57  * kazuponquit (Remote host closed the connection)
18:19:01  * bradleymeckquit (Quit: bradleymeck)
18:21:00  <jreyno40_>here is a backtrace I’ve drummed up: http://hastebin.com/xukipopave.xml
18:21:22  * quijotequit (Ping timeout: 240 seconds)
18:22:43  <tjfontaine>can you recompile in debug mode? exec bad address is probably a null deref of sorts
18:23:43  <jreyno40_>tjfontaine: Sorry, I’m not well versed with libuv. I’m working on an open-source project that uses it
18:23:50  <jreyno40_>how would I recompile in debug mode
18:24:00  <tjfontaine>depends on how the project is consuming it
18:24:08  <jreyno40_>do I need to recompile from source in debug & take the .a file back into the open-source project?
18:24:19  <tjfontaine>that is one way to do it
18:24:20  <jreyno40_>tjfontaine: using it for a uv_default_loop and uv_udp_send
18:24:50  <jreyno40_>tjfontaine: C, not NodeJS
18:25:40  <jreyno40_>tjfontaine: Okay, so how would I compile in debug from source?
18:25:59  <tjfontaine>where's the project using this, is it compiling libuv as part of its build?
18:26:21  <jreyno40_>tjfontaine: no, it’s statically linking assembly (libuv.a)
18:26:44  <tjfontaine>ok, which mechanism are you using to build the libuv.a?
18:26:48  <tjfontaine>autoconf or gyp?
18:27:05  <jreyno40_>tjfontaine: autoconf
18:28:40  * quijotejoined
18:29:31  <tjfontaine>ok frustratingly there doesn't seem tobe a debug target currently
18:29:40  <jreyno40_>:(
18:29:49  <tjfontaine>jreyno40_: CFLAGS="-O0 -g" ./configure
18:30:01  <jreyno40_>do that?
18:30:02  <jreyno40_>:D
18:30:12  <tjfontaine>ya, it's not 100% what I would want, but it may be sufficient
18:31:18  <jreyno40_>tjfontaine: okay
18:31:44  <tjfontaine>then ou could also do: make V=1 CFLAGS="-O0 -g"
18:31:49  <jreyno40_>oh, last time I compiled from source a make check test failed
18:32:00  <tjfontaine>you want to watch the compilation output to see that each code unit is getting that passed to it
18:32:36  <tjfontaine>brb lunch
18:33:13  <jreyno40_>tjfontaine: okay
18:34:56  * avalanch_quit (Remote host closed the connection)
18:35:27  * avalanche123joined
18:37:59  * euoia_joined
18:40:02  * avalanche123quit (Ping timeout: 244 seconds)
18:40:36  <jreyno40_>tjfontaine: I am also getting this error: Assertion failed: (uv__has_active_reqs(handle->loop)), function uv__udp_run_completed, file src/unix/udp.c, line 97.
18:40:50  * avalanche123joined
18:44:21  * AvianFlujoined
18:47:36  * mcavagejoined
18:48:14  * sh1mmerjoined
18:50:52  * quijotequit (Ping timeout: 240 seconds)
18:51:55  * mcavagequit (Ping timeout: 244 seconds)
18:54:16  * dshaw_quit (Quit: Leaving.)
19:01:11  * quijotejoined
19:03:30  * bajtosquit (Quit: bajtos)
19:03:49  * dignifiedquirequit (Quit: dignifiedquire)
19:04:52  * sh1mmerquit (Ping timeout: 245 seconds)
19:04:53  <saghul>tjfontaine: pong
19:05:20  <saghul>jreyno40_: do you have a test case?
19:06:25  <jreyno40_>saghul: this is a rather large project
19:06:33  <jreyno40_>saghul: so no
19:06:42  <saghul>jreyno40_: multiple threads?
19:06:48  <jreyno40_>saghul: no
19:06:58  <jreyno40_>saghul: I can however give you a brief description
19:07:06  <jreyno40_>that could definitely help
19:07:18  <saghul>jreyno40_: go ahead :-)
19:08:11  <jreyno40_>first thing done with libuv: uv_default_loop();
19:08:28  <jreyno40_>uv_udp_init(thatLoop, socketPtr);
19:08:42  <jreyno40_>uv_ip4_addr(ip, port, sock_addr);
19:09:12  * sh1mmerjoined
19:09:14  <jreyno40_>Then, we go into a loop repeatedly calling uv_run(thatLoop, UV_RUN_NOWAIT);
19:09:42  <jreyno40_>saghul: The library is a video streaming library. Thus, when capture data is received (a video frame) a bunch of stuff is done to create a packet
19:10:08  <jreyno40_>saghul: THEN uv_udp_send(); is called to send the packet.
19:10:19  <jreyno40_>saghul: all meanwhile uv_run() is still being called
19:10:25  <jreyno40_>This is all in a single thread
19:11:44  <saghul>hum, there is no obvious reason why that would happen :-/
19:12:07  <saghul>out of curiosity, why can't you use UV_RUN_DEFAULT?
19:14:41  <jreyno40_>saghul: That blocks and we’re drawing a video being streamed at high speed
19:15:01  <jreyno40_>saghul: so we can’t use that
19:15:16  <saghul>aha
19:15:36  <saghul>give me a sec, I found something weird there
19:15:49  <jreyno40_>saghul: Oh? ^.^
19:15:50  * rendarquit (Ping timeout: 260 seconds)
19:16:12  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
19:16:22  <jreyno40_>saghul: Oh, KEY piece of information; The error ONLY happens when we try to call uv_udp_send in quick succession
19:16:22  * quijotequit (Ping timeout: 240 seconds)
19:17:15  <saghul>jreyno40_: do you check the return code? do you get any before it goes nuts?
19:20:00  <jreyno40_>saghul: just “if(r!=0){printf(“got an error…\n”);}"
19:20:16  <jreyno40_>saghul: where r = uv_udp_send();
19:21:52  * rendarjoined
19:23:25  * dsantiagoquit (Quit: Computer has gone to sleep.)
19:24:06  <saghul>jreyno40_: and, no error?
19:24:11  * wavdedquit (Read error: Connection reset by peer)
19:24:39  * sinclair|workquit (Remote host closed the connection)
19:27:13  <jreyno40_>saghul: I’m also getting messages that say “Abort trap: 6” but I’m not sure that’s related
19:27:19  <jreyno40_>saghul: Yep, no error
19:27:44  <saghul>jreyno40_: those aborts don't sound good at all :-( do you have a backtrace?
19:28:08  <jreyno40_>http://hastebin.com/xukipopave.xml
19:28:46  <jreyno40_>It segfaults sometimes
19:29:00  <jreyno40_>other times it throws the “Assertion failed:” partnered with “Abort trap: 6"
19:29:36  <jreyno40_>other times I get a free issue
19:29:53  <jreyno40_>saghul: which is especially weird; It manages to call a callback twice at the exact same time
19:30:08  <jreyno40_>saghul: so one of them frees the memory, the other tries to free the already freed memory
19:30:19  <jreyno40_>saghul: and I’m referring to the callback you can pass into uv_udp_send
19:31:02  <jreyno40_>saghul: and in that callback we free “uv_udp_send_t* req; free(req->data); free(req)"
19:31:13  <jreyno40_>saghul: Could that be the issue? Freeing the request?
19:31:16  <saghul>jreyno40_: yo use different uv_udp_send_t request objects each time you call uv_udp_send, right?
19:31:43  <saghul>*you use
19:31:45  <jreyno40_>saghul: Yes, a new request object is malloced each time.
19:32:06  <saghul>do you modify any of its fields besides data?
19:32:22  <jreyno40_>saghul: no
19:32:41  <jreyno40_>saghul: However we also us a uv_buf_t (which we initialize with uv_buf_init());
19:32:56  <saghul>jreyno40_: and where do you store it?
19:32:57  <jreyno40_>saghul: we pass it as the third argument to uv_udp_send()
19:33:04  <saghul>sure
19:33:15  <saghul>how do you free the buffer?
19:33:17  <jreyno40_>saghul: and it appears the person that wrote this never frees that
19:33:42  <saghul>the buffer structure is copied, not the buffer base
19:34:15  <jreyno40_>saghul: meaning?
19:34:18  <saghul>jreyno40_: you can pass a stack allocated uv_buf_t, as long as buf->base points to valid memory thoughout the lifetime of the request
19:34:32  <saghul>*throughout
19:35:16  <jreyno40_>well
19:35:42  <jreyno40_>saghul: it appears buf->base is never specifically set
19:36:03  <saghul>its set by uv_buf_init
19:36:06  <jreyno40_>saghul: we cann uv_buf_init((char *)tmp, nbytes); where tmp is a char* with bytes
19:36:15  <jreyno40_>saghul: Okay
19:36:21  <jreyno40_>saghul: So there should be no issue there either, correct?
19:36:39  <saghul>jreyno40_: is tmp valid from the moment you call uv_udp_send until the callback is called?
19:37:10  <jreyno40_>saghul: tmp is out of scope inside of the callback
19:37:25  <jreyno40_>saghul: tmp is declared inside of the function calling uv_udp_send
19:37:55  <saghul>jreyno40_: well, the memory needs to be valid until then, otherwise you may write garbage
19:37:55  <tjfontaine>saghul: just that the readdir stream work is broken on smartos
19:38:22  <saghul>tjfontaine: doh
19:38:51  <jreyno40_>saghul: hmm… okay
19:39:17  <saghul>tjfontaine: looks like dirent doesn't have d_type on SunOS
19:39:23  <jreyno40_>saghul: So I need to make sure the tmp variable is still in scope inside of the callback?
19:39:49  <saghul>jreyno40_: tmp is a pointer to a memory area, you need to make sure that memory is valid until then
19:40:00  <trevnorris>afternoon
19:41:12  <jreyno40_>saghul: so is uv_buf_init taking the pointer from tmp?
19:41:22  <jreyno40_>saghul: is it a pointer to tmp?
19:41:32  <jreyno40_>saghul: So does it point to the same memory
19:41:38  <trevnorris>saghul: *nix compiles w/ 4 threads by default. on windows, while it still has a "thread pool" libuv just doesn't need to manage how many threads it has?
19:41:42  <jreyno40_>saghul: or is it copying what is in that memory location
19:41:46  <trevnorris>i.e. it's managed by windows.
19:43:42  <jreyno40_>saghul: I’m not entirely sure how I can check the memory. Since the pointer is declared inside of the function calling uv_udp_send & I create the uv_buf that gets passed into uv_udp_send, tmp goes out of scope at the end of the function & the uv_buf isn’t passed as a parameter to the callback
19:44:09  <tjfontaine>saghul: according to posix d_type and others are only available by platform, also that d_type may not be supported by the filesystem
19:48:53  <saghul>jreyno40_: it sets a pointer, it doesn't copy the memory
19:49:37  <saghul>tjfontaine: yeah, let me try to make a quick patch
19:49:41  <jreyno40_>saghul: Okay, so if I’m mallocing in the sender function but never freeing it should still be valid
19:49:57  <jreyno40_>saghul: I just need to free it somewhere O.o
19:50:24  <jreyno40_>saghul: the data coming across is valid too, meaning we’re actually able to reconstruct video frames
19:50:29  <saghul>trevnorris: "compiling w/ 4 threads" you mean the default size of the thread pool?
19:50:53  <saghul>jreyno40_: damn. Then you have a leak, but it shouldn't crash.
19:50:56  * AvianFluquit (Read error: Connection reset by peer)
19:51:39  <saghul>jreyno40_: any chance you can simulate that UV_RUN_NOWAIT spin + lots of uv_usp_send in a test case? That would definitely help.
19:52:06  * bradleymeckjoined
19:52:25  <jreyno40_>saghul: I’m considering it
19:52:44  <jreyno40_>saghul: I just figured I could fix it quicker than I could provide a test case
19:52:49  <jreyno40_>saghul: guess not though
19:54:01  <jreyno40_>saghul: I’m just baffled; I really don’t know how “Assertion failed: (uv__has_active_reqs(handle->loop)), function uv__udp_run_completed, file src/unix/udp.c, line 97.” is happening
19:56:13  * avalanche123quit (Remote host closed the connection)
19:56:26  * bradleymeckquit (Client Quit)
19:56:40  * avalanche123joined
19:56:50  <saghul>tjfontaine: can you try this? https://gist.github.com/saghul/20236dbba12250e6f265
19:57:28  <saghul>jreyno40_: yeah, me neither :-/
19:58:06  <trevnorris>saghul: yeah. default side of the thread pool on the *nix side is w/ 4 threads. but swear I remember Bert telling me that Windows manages how many threads are created.
19:58:07  * bradleymeckjoined
19:58:42  <saghul>trevnorris: yes, Windows used to use the system work queuing facilities
19:58:46  <tjfontaine>saghul: seems like DT_UNKNOWN would be more appropriate
19:59:03  <saghul>but I unified the threadpool, so now uv_cancel also works on Windows
19:59:15  * wavdedjoined
19:59:20  <trevnorris>ah, so that's the reason. thanks for the clarification.
19:59:22  <saghul>tjfontaine: SunOS doesn't even have a type, so it's all files to his eyes...
19:59:27  <trevnorris>the rust team will be interested to hear that.
19:59:30  <saghul>trevnorris: any time!
19:59:50  <tjfontaine>saghul: if uv is exposing the concept of this interface, we should be faithful to it, even if the platform doesn't support it
20:00:24  <tjfontaine> Currently, only some filesystems (among them: Btrfs, ext2, ext3, and
20:00:24  <tjfontaine> ext4) have full support for returning the file type in d_type. All
20:00:24  <tjfontaine> applications must properly handle a return of DT_UNKNOWN.
20:00:32  <saghul>tjfontaine: true that
20:00:42  <saghul>let me make a better patch
20:00:58  <tjfontaine>so the whole interface of this needs to know how to handle interpreting the results
20:01:06  * avalanche123quit (Ping timeout: 260 seconds)
20:03:26  * euoia_quit (Ping timeout: 260 seconds)
20:03:52  * dignifiedquirejoined
20:05:08  <trevnorris>tjfontaine: fyi, github is displaying the commits on https://github.com/joyent/node/pull/8110 out of order
20:09:07  * avalanche123joined
20:13:27  * sh1mmerquit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
20:13:53  * quijotejoined
20:15:56  <jreyno40_>saghul: So the buffer (b) being stack allocated then b = uv_buf_init((char *)tmp, bytes); where tmp is heap allocated shouldn’t be an issue? Meaning that (b) will be managed & the heap allocated data will still be there in the callback?
20:16:53  <saghul>yes, sort of
20:17:12  <saghul>you'll need to save a pointer to tmp somewhere if you want to free it
20:17:42  <saghul>you can embed the uv_udp_send_t request in another struct, or use the data field, for example
20:18:53  * quijotequit (Ping timeout: 272 seconds)
20:20:36  <jreyno40_>saghul: ahh, silly me. We were using the data field
20:20:40  <jreyno40_>saghul: to free it
20:22:24  <trevnorris>tjfontaine: I think https://github.com/joyent/node/pull/8110 is where I want it. when can I land it?
20:22:30  * a3fjoined
20:22:35  <jreyno40_>saghul: And it’s okay to free the uv_udp_send_t inside of the callback?
20:22:43  <saghul>tjfontaine: updated with extra bacon: https://gist.github.com/saghul/20236dbba12250e6f265
20:23:08  <saghul>tjfontaine: please give it a shot and I'll send a PR so that indutny and txdv also check it out
20:23:28  <saghul>jreyno40_: yes
20:23:45  <saghul>after the callback you can dispose the request
20:25:34  <jreyno40_>saghul: wait, after?
20:25:40  <jreyno40_>saghul: we’re disposing it inside the callback
20:26:38  <saghul>jreyno40_: yeah, it's ok to do it inside, that's what I tried to say :-)
20:26:45  <saghul>as in, libuv will no longer use it
20:27:02  <jreyno40_>saghul: oh, okay
20:27:08  <jreyno40_>saghul: I was hoping you would say it wasn't
20:27:12  <jreyno40_>saghul: lol
20:29:04  * mikealjoined
20:29:05  <saghul>jreyno40_: I suspect memory corruption, make sure you never reuse a request object by accident
20:29:19  <jreyno40_>saghul: I do too; That was my first guess
20:29:24  <jreyno40_>saghul: I’ve just been unable to find any up to now
20:29:32  <jreyno40_>saghul: But I’ll keep looking; thank you
20:30:52  <saghul>jreyno40_: you're welcome, I hope you can find it so we can solve it in case it's a problem in libuv
20:31:13  <jreyno40_>saghul: Thanks, I’ll report back ^.^
20:31:27  * abraxasjoined
20:31:47  * jreyno40_quit (Quit: jreyno40_)
20:35:24  * avalanche123quit (Remote host closed the connection)
20:35:57  * abraxasquit (Ping timeout: 260 seconds)
20:36:31  * avalanche123joined
20:36:41  <indutny>saghul: LGTM
20:36:54  <indutny>saghul: didn't know that solaris has now directory information
20:37:02  * brsonquit (Ping timeout: 260 seconds)
20:37:47  * daviddiasquit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
20:38:02  * dsantiagojoined
20:40:30  * brsonjoined
20:40:42  * avalanche123quit (Ping timeout: 250 seconds)
20:41:51  * sh1mmerjoined
20:42:26  <tjfontaine>saghul: I will test it, it looks like it will work, though my question is why we aren't passing the rest of the types that the interface describes? certainly we will get requests to know about blk, chr, fifo, lnk, and sock as well?
20:43:37  * quijotejoined
20:44:29  * avalanche123joined
20:44:48  <saghul>tjfontaine: they can send pull requests :-)
20:45:15  <saghul>indutny: oh, I thought you were afk, thanks!
20:45:17  <tjfontaine>haha, I will send the PR
20:45:58  <saghul>tjfontaine: :-) ok, I'll make a PR and see if any jenkins bot complains, just in case
20:46:04  * jreyno40joined
20:48:28  * quijotequit (Ping timeout: 260 seconds)
20:48:50  * sblomjoined
20:49:24  * Soarez|afkchanged nick to Soarez
20:53:36  <tjfontaine>saghul: we'll probably need to do similar work on the windows path as well, so people can write code that works on all the platforms :)
20:55:56  <saghul>tjfontaine: I checked the flags and there doesn't seen to be any which is not a "file"
20:57:43  <saghul>tjfontaine: tests pass on SmartOS. I'll land it in the morning, when I can have another look with a fresher brain, just in case I miss something
20:57:52  <saghul>not it's time to watch Suits :-)
20:57:55  <saghul>*now
20:58:21  * jreyno40quit (Quit: jreyno40)
20:59:14  <tjfontaine>hehe fun show
20:59:29  <tjfontaine>saghul: fwiw though, fs__stat_handle shows at least we know if it's a link
20:59:48  <saghul>tjfontaine: ok, I'll look into that
21:00:40  * c4miloquit
21:03:00  * dshaw_joined
21:04:38  * jgiquit (Quit: jgi)
21:06:28  * dignifiedquirequit (Quit: dignifiedquire)
21:10:01  * jreyno40_joined
21:19:17  * wavdedquit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
21:20:43  * jreyno40_quit (Quit: jreyno40_)
21:25:31  * a_lequit (Read error: Connection reset by peer)
21:25:49  * wavdedjoined
21:26:02  * a_lejoined
21:26:29  * andrehjrquit (Quit: Computer has gone to sleep.)
21:28:00  * jgijoined
21:29:28  * AvianFlujoined
21:29:34  * jreyno40_joined
21:34:00  * jreyno40_quit (Ping timeout: 250 seconds)
21:40:30  * wavdedquit (Quit: Textual IRC Client: www.textualapp.com)
21:44:29  * quijotejoined
21:48:37  * quijotequit (Ping timeout: 244 seconds)
21:52:48  * jreyno40_joined
21:56:22  * kellabytequit (Quit: Connection closed for inactivity)
21:56:56  * bradleymeck_joined
21:58:18  * andrehjrjoined
22:00:40  * bradleymeckquit (Ping timeout: 272 seconds)
22:00:40  * bradleymeck_changed nick to bradleymeck
22:03:24  * mikealquit (Quit: Leaving.)
22:05:42  * mikealjoined
22:14:02  * euoia_joined
22:15:08  * dshaw_1joined
22:16:44  * dshaw_quit (Ping timeout: 240 seconds)
22:19:56  <jreyno40_>saghul: Hey, does uv_udp_send automatically free the memory inside of the uv_buf passed to it?
22:23:53  * mikealquit (Quit: Leaving.)
22:25:12  * Soarezchanged nick to Soarez|afk
22:31:55  <bradleymeck>jreyno40_: no
22:32:08  <jreyno40_>bradleymeck: thanks
22:32:18  * abraxasjoined
22:32:24  * janjongboomjoined
22:35:00  <jreyno40_>Okay, I may have an issue
22:35:34  <jreyno40_>the request objects I’m malloc’ing (when calling uv_udp_send twice in a row) are each using the same memory
22:36:39  * abraxasquit (Ping timeout: 246 seconds)
22:37:12  * jreyno40_part
22:42:05  * c4milojoined
22:45:19  * quijotejoined
22:45:57  * Soarez|afkchanged nick to Soarez
22:46:29  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
22:48:12  * rendarquit
22:49:53  * quijotequit (Ping timeout: 260 seconds)
23:14:31  * dap_1joined
23:14:33  * dap_quit (Read error: Connection reset by peer)
23:28:37  * dshaw_1quit (Read error: Connection reset by peer)
23:28:44  * dshaw_joined
23:36:23  * petka_quit (Quit: Connection closed for inactivity)
23:38:14  * dsantiagoquit (Quit: Computer has gone to sleep.)
23:45:18  * seishunquit (Ping timeout: 250 seconds)
23:46:05  * quijotejoined
23:50:20  * quijotequit (Ping timeout: 240 seconds)
23:50:33  * kaesoquit (Ping timeout: 240 seconds)
23:51:46  * kaesojoined
23:52:08  * avalanche123quit (Remote host closed the connection)
23:52:34  * avalanche123joined
23:54:02  * sh1mmerquit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
23:57:14  * avalanche123quit (Ping timeout: 260 seconds)
23:58:36  * sh1mmerjoined