00:00:00  * ircretaryquit (Remote host closed the connection)
00:00:10  * ircretaryjoined
00:02:55  * rendarquit (Quit: Leaving)
00:16:02  * tarruda_joined
00:17:26  * tarrudaquit (Ping timeout: 265 seconds)
01:28:06  * chris_99quit (Quit: Ex-Chat)
01:29:27  * stagasquit (Ping timeout: 245 seconds)
01:40:01  * andrehjrquit (Quit: Computer has gone to sleep.)
01:59:45  * bradleymeckjoined
02:07:57  * andrehjrjoined
02:14:04  * andrehjrquit (Quit: Computer has gone to sleep.)
03:19:50  * tjkrusinskiquit (Ping timeout: 258 seconds)
03:26:59  * brsonquit (Quit: leaving)
03:35:13  * Left_Turnquit (Quit: Leaving)
03:37:53  * AvianFluquit (Remote host closed the connection)
03:39:51  * bradleymeckquit (Quit: bradleymeck)
04:21:07  * Ralithquit (Ping timeout: 255 seconds)
04:31:53  * Orbordejoined
04:33:45  * Ralithjoined
04:34:38  <Orborde>Hey, does someone have a libuv dev environment set up on Windows? I don't, and I'm trying to diagnose a possible Windows-only crash: http://paste.orangehattech.com/view/003191f5
04:36:20  <Orborde>(to be clear, I'm looking for someone to try running the above snippet on Windows and tell me if it crashes)
04:59:09  <txdv>probably not many people trying to use tha trdlock
04:59:11  <txdv>so it might be buggy
05:00:13  <a_le>is it ok to uv_read_stop() within the alloc_cb, if I can't provide memory for the next read operation?
05:01:25  <txdv>as in you want to that alloc_cb to be called again after running the loop after the stop?
05:01:57  <a_le>txdv: I want it to be called again only after I issue another uv_read_start()
05:03:26  <a_le>alloc_cb() fires, it goes like: "oh shit I can't take any data" and then it issues uv_read_stop(). Some more processing happens, and we are ready to take more data again, we issue uv_read_start(). Hopefully now that old alloc_cb() will get invoked again, but maybe I am daydreaming :)
05:03:38  <a_le>what I am afraid will happen instead is:
05:04:02  <txdv>it wont
05:04:21  <a_le>that the uv_read_stop() doesn't have an immediate effect and that libuv will barf when the uv_buf will have len = 0
05:04:41  <a_le>txdv: how do you suggest i handle this?
05:04:49  <txdv>just return len = 0 and read_start again lat er
05:05:01  <txdv>i think it wont barf on len = 0
05:05:04  <txdv>im not sure though
05:05:08  <a_le>txdv: i am lost
05:05:15  <a_le>so what was wrong?
05:05:21  <txdv>no, im talking shit
05:05:26  <txdv>it wont barf on unix
05:05:30  <txdv>on windows it will
05:05:47  <a_le>ChangeLog:* windows: make uv_read_stop immediately stop reading (Jameson Nash)
05:06:10  <a_le>is it equivalent to a uv_read_stop() on unix?
05:06:50  <txdv>immediately but not in the alloc_cb
05:09:14  <a_le>txdv: so the only thing I need to pay attention to is that if i ever return a 0-len buf, I need to later issue another uv_read_start() by myself, even if I never explicitly invoked a uv_read_stop() ?
05:10:11  <txdv>no, that was a lie, i thought about the unix aspect of libuv
05:10:25  <txdv>windows calls alloc_cb before it issues the IO request
05:10:49  <a_le>i am reading src/unix/stream.c
05:11:21  <a_le>read_cb(stream, UV_ENOBUFS, &buf) gets invoked right away upon a 0-len buf being returned by alloc_cb
05:12:48  <txdv>yeah, so it works on unix for sure
05:12:54  <txdv>i dont think that it works on windows though
05:13:06  <txdv>wait i have to think about it
05:13:28  <a_le>i'll wait :)
05:14:09  <txdv>it will work
05:14:23  <a_le>on both win and unix?
05:14:32  <txdv>the only difference is that alloc_cb on unix is called a bit later
05:14:50  <a_le>i'm listening then i have more questions
05:15:02  <txdv>return len = 0, stop reading
05:15:06  <txdv>start reading when you are ready agian
05:15:34  <a_le>stop reading = issue a uv_read_stop()?
05:16:53  <txdv>you dont need to stop
05:17:03  <txdv>but it will trigger again on the next loop iteration
05:17:30  <a_le>even if no new data was received?
05:17:38  <a_le>is it ok for me to stop?
05:18:07  <a_le>within the alloc_cb?
05:20:29  <txdv>if you stop all operations of the current iteration will still be executed
05:20:48  <txdv>wait
05:21:05  <txdv>you mean read_stop or the other stop which stops the loop?
05:21:18  <a_le>uv_read_stop()
05:21:49  <a_le>(thank you for your patience :-)
05:25:31  <txdv>i dont know for sure
05:26:02  <txdv>i'd have to investigate the code
05:33:55  <a_le>i see
05:35:40  <txdv>a_le: Just try it out
05:35:44  <txdv>are you on windows?
05:41:31  <a_le>txdv: linux/macOS
05:41:58  <a_le>txdv: yeah I guess I could do it on purpose, artificially
05:42:28  <txdv>either one dives deep into the code or one just tries it out
05:42:47  <txdv>the code part is the better way, because you understand, but it is the harder way and takes much more time
05:45:51  <a_le>yep
05:46:02  * seishunjoined
05:46:32  <a_le>i won't be able to try right away though
05:46:42  <a_le>will let you know once i've done it
06:02:54  * tarruda_quit (Read error: Connection reset by peer)
06:04:46  * petka_quit (Quit: Connection closed for inactivity)
07:04:13  * seishunquit (Ping timeout: 272 seconds)
07:58:14  * kaeso-joined
08:00:16  * ircretaryquit (Ping timeout: 252 seconds)
08:00:16  * kaesoquit (Ping timeout: 252 seconds)
08:00:17  * kaeso-changed nick to kaeso
08:00:17  * ircretaryjoined
08:00:18  * Damn3dquit (Ping timeout: 252 seconds)
08:01:05  * MI6quit (Ping timeout: 252 seconds)
08:01:05  * julianduquequit (Ping timeout: 252 seconds)
08:02:06  * julianduquejoined
08:02:54  * Damn3djoined
08:19:21  * Guest15275quit (Ping timeout: 252 seconds)
08:19:28  * tjfontainejoined
08:19:30  * skebcio_joined
08:19:43  * ircretaryquit (Ping timeout: 252 seconds)
08:19:43  * hij1nxquit (Ping timeout: 252 seconds)
08:19:49  * hij1nxjoined
08:19:58  * tjfontainechanged nick to Guest83914
08:20:05  * skebcioquit (Ping timeout: 252 seconds)
08:36:19  * dsantiagojoined
09:21:40  * SergeiRNDjoined
09:26:25  * rendarjoined
09:40:21  * stagasjoined
10:00:21  * davijoined
10:23:23  * a_lequit (Remote host closed the connection)
10:35:51  * Left_Turnjoined
10:44:09  * SergeiRNDquit (Quit: Leaving.)
10:50:37  * daviquit (Remote host closed the connection)
10:53:56  * a_lejoined
10:55:25  * chris_99joined
10:59:04  * a_lequit (Ping timeout: 258 seconds)
11:22:40  * chris_99quit (Quit: Ex-Chat)
11:28:10  * tarruda_joined
11:30:55  * SergeiRNDjoined
11:52:44  * tarruda_quit (Ping timeout: 245 seconds)
12:41:55  <hij1nx>rendar: ping
12:45:43  * chris_99joined
13:14:27  * stagasquit (Ping timeout: 245 seconds)
13:26:42  * tjkrusinskijoined
13:31:28  * [spoiler]joined
13:34:08  * stagasjoined
13:37:39  <hij1nx>hmm, anyone around for a question?
13:40:52  * tjkrusinskiquit (Ping timeout: 240 seconds)
13:51:08  * andrehjrjoined
13:55:21  * tjkrusinskijoined
14:08:04  * AvianFlujoined
14:46:55  * SergeiRNDquit (Quit: Leaving.)
14:56:28  * wolfeidauquit (Ping timeout: 264 seconds)
14:59:43  * chris_99quit (Quit: Ex-Chat)
15:00:36  * wolfeidaujoined
15:01:24  * thlorenzjoined
15:01:58  * chris_99joined
15:08:17  * KennethWilkejoined
15:09:13  * andrehjrquit (Quit: Computer has gone to sleep.)
15:11:34  * bradleymeckjoined
15:15:12  * rmgjoined
15:17:20  * stagasquit (Ping timeout: 244 seconds)
15:46:13  <am11>hij1nx: don't ask to ask, just ask. :)
15:52:31  * stagasjoined
16:13:19  * wolfeidau_joined
16:15:09  <hij1nx>am11: or ask here and 3 other places and then return to all three places to let them know i figured it out ;)
16:15:32  <am11>cool!
16:15:42  * wolfeidauquit (Ping timeout: 245 seconds)
16:16:20  <am11>and i am still stuggling with libuv and v8 .. and i don't know where to beging with decribing the problem :)
16:17:04  <am11>but txdv know what i am talking about.. so i guess i better shut up and wait :)
16:17:57  <hij1nx>so, im having this issue where the buffer (of type uv_buf_t) is not always the same data that i expect it to be
16:18:00  <hij1nx>https://gist.github.com/hij1nx/23f16b5f508cb50f4ecc
16:18:13  <hij1nx>i have a test that can reproduce the issue
16:18:54  <hij1nx>i had both rvagg and indutny look at it but they weren't sure what it might be
16:19:00  <indutny>ohai
16:19:04  <indutny>well
16:19:09  <indutny>I didn't get a chance to do it
16:19:12  <indutny>honestly saying :)
16:19:18  <hij1nx>yay indutny :D
16:19:19  <indutny>doing it now
16:19:32  <hij1nx><3
16:19:35  <am11>yay!
16:25:36  <indutny>hij1nx: the test case appears to be working fine
16:25:47  <indutny>hij1nx: I'm using libuv 1.0.2
16:26:06  * seishunjoined
16:27:32  <am11>here is my valgrind log: https://gist.github.com/am11/6cfcebdef05e3751f16d i don't know what to make of it. the process was terminating with SIGSEGV due to some unknown reason, so i used valgrind. Now the logs are pretty colorful (including all kinds of v8 calls)
16:28:14  * Fishrock123joined
16:30:37  <indutny>hij1nx: appears to be working even on 200000 iterations
16:30:48  <hij1nx>indutny: wow omg :(
16:31:02  <indutny>let me try 1.1.0
16:31:12  <indutny>yeah, the same
16:31:23  <indutny>hij1nx: are you running it in vagrant?
16:31:26  <indutny>or vbox?
16:31:26  <hij1nx>hmm, no
16:31:32  <hij1nx>just on my mac
16:31:32  <indutny>so it is just osx?
16:31:36  <hij1nx>yeah
16:31:39  <hij1nx>Yosemite
16:31:45  <indutny>same on my side
16:31:50  <indutny>SSD?
16:31:53  <hij1nx>yeah
16:31:58  <indutny>still the same
16:31:59  <hij1nx>new macbook air
16:32:01  <hij1nx>hmf
16:32:07  <indutny>anyway
16:32:10  <indutny>let me re-read it
16:32:10  <hij1nx>ok, well, im willing to accept only one answer
16:32:27  <hij1nx>its because maybe im still on some beta version of Yosemite
16:32:29  <indutny>have you created the file?
16:32:31  <indutny>:)
16:32:40  <hij1nx>created the file?
16:32:45  <indutny>out.txt
16:32:48  <hij1nx>yeah
16:32:49  <hij1nx>haha
16:32:53  <indutny>ook :)
16:33:16  <hij1nx>oh, what version compiler are you?
16:33:40  <hij1nx>Apple LLVM version 6.0 (clang-600.0.41.2) (based on LLVM 3.5svn)
16:33:46  <indutny>Apple LLVM version 6.0 (clang-600.0.56) (based on LLVM 3.5svn)
16:34:00  <indutny>are you sure that read_req.result is the same as stat->st_size
16:34:10  <indutny>when it fails
16:34:17  <hij1nx>yes
16:34:25  <hij1nx>let me double check
16:34:35  <indutny>I don't see any other problems with it
16:34:38  <indutny>honestly saying
16:36:18  <hij1nx>yep it's the same
16:36:25  <hij1nx>ok
16:36:32  <hij1nx>i think it honestly might be this computer
16:36:42  <hij1nx>oh i got an idea, how about a reboot? haha
16:38:25  * SergeiRNDjoined
16:38:57  <indutny>hij1nx: haha
16:39:06  <indutny>hij1nx: before you'll do it
16:39:13  <indutny>hij1nx: please dtruss the script again
16:41:45  <indutny>hij1nx: should have much less noise
16:41:55  <indutny>hij1nx: so please paste the complete log
16:41:59  <indutny>s/log/trace/
16:42:00  <hij1nx>k
16:43:33  <hij1nx>indutny: https://gist.github.com/hij1nx/d34cfcf6e589b21fd631
16:43:37  <indutny>thanks
16:44:24  <indutny>gosh
16:44:26  <indutny>I have no idea
16:44:29  <indutny>looks good
16:44:39  <indutny>may be a compiler bug
16:45:15  <hij1nx>im guessing either that or becuase im not on that latest Yosemite
16:47:39  * wolfeidau_quit (Remote host closed the connection)
16:48:07  * wolfeidaujoined
16:49:08  * a_lejoined
16:49:49  <hij1nx>hehe, usually its the opposite, "works on my machine"
16:50:35  <indutny>:)
16:51:58  * petka_joined
16:57:42  * seishunquit (Remote host closed the connection)
16:59:55  * seishunjoined
17:09:51  * cjbquit (Remote host closed the connection)
17:11:28  * cjb81joined
17:13:11  * wolfeidauquit (Read error: Permission denied)
17:13:56  * wolfeidaujoined
17:16:00  * wolfeidauquit (Remote host closed the connection)
17:16:29  * wolfeidaujoined
17:26:24  * brsonjoined
17:28:31  * Fishrock123quit (Remote host closed the connection)
17:32:45  * Fishrock123joined
17:39:41  * bradleymeckquit (Quit: bradleymeck)
18:22:35  * Fishrock123quit (Quit: Leaving...)
18:29:08  * chris_99quit (Ping timeout: 264 seconds)
18:29:08  * thlorenzquit (Remote host closed the connection)
18:29:10  * thlorenzjoined
18:29:22  * chrisdickinsonquit (Ping timeout: 255 seconds)
18:29:52  * chrisdickinsonjoined
18:41:53  * zjujoined
18:44:54  * chris_99joined
18:55:22  * brockfredinjoined
18:55:49  * thlorenzquit (Remote host closed the connection)
19:03:05  * thlorenzjoined
19:05:10  * thlorenz_joined
19:05:11  * thlorenzquit (Read error: Connection reset by peer)
19:10:30  * zju4joined
19:10:52  * zjuquit (Ping timeout: 244 seconds)
19:20:01  * SergeiRNDquit (Quit: Leaving.)
19:28:06  * sandr8quit
19:33:11  * bradleymeckjoined
20:02:36  * KennethWilkequit (Quit: Leaving)
20:09:41  * thlorenz_quit (Remote host closed the connection)
20:10:29  * thlorenzjoined
20:30:15  * bradleymeckquit (Read error: Connection reset by peer)
20:30:16  * bradleymeck_joined
20:30:25  * tjkrusinskiquit (Ping timeout: 255 seconds)
20:38:33  * bradleymeck_quit (Read error: Connection reset by peer)
20:38:56  * bradleymeckjoined
21:29:28  * cjb81quit (Remote host closed the connection)
21:29:57  * bradleymeckquit (Quit: bradleymeck)
21:30:14  * cjb81joined
21:30:46  * tjkrusinskijoined
21:38:03  * iarnajoined
21:42:45  * seishunquit (Read error: Connection reset by peer)
21:43:09  * andrehjrjoined
21:46:48  * seishunjoined
21:58:34  * tjkrusinskiquit (Ping timeout: 265 seconds)
22:09:27  * zjujoined
22:10:28  * zju4quit (Ping timeout: 244 seconds)
22:18:45  * andrehjrquit (Quit: Computer has gone to sleep.)
22:30:21  * [spoiler]quit (Quit: Leaving)
22:33:22  * iarnaquit (Remote host closed the connection)
22:33:33  * iarnajoined
22:34:07  * iarnaquit (Remote host closed the connection)
22:39:56  * andrehjrjoined
22:40:11  * andrehjrquit (Client Quit)
22:42:28  * andrehjrjoined
22:57:49  * seishunquit (Ping timeout: 258 seconds)
23:04:51  * tjkrusinskijoined
23:09:37  * tjkrusinskiquit (Ping timeout: 265 seconds)
23:26:41  * chris_99quit (Quit: Ex-Chat)
23:28:14  * [spoiler]joined
23:30:03  * LeftWing__joined
23:30:05  * LeftWingquit (Read error: Connection reset by peer)
23:34:46  * iarnajoined
23:39:43  * rmgquit (Remote host closed the connection)
23:40:13  * LeftWing__changed nick to LeftWing
23:44:15  * rmgjoined
23:47:49  * thlorenzquit (Remote host closed the connection)
23:59:19  * inolenjoined
23:59:57  * iarnaquit (Ping timeout: 240 seconds)