00:05:05  <rphillips>rje I bet the make.bat needs to be tweaked to pass that msvs options
00:05:25  <rphillips>It's in the luvi project
00:06:12  <rje>rphillips, what is on the luvi project?
00:07:14  <rphillips>https://github.com/luvit/luvi/blob/master/make.bat#L10
00:08:32  <rje>that looks right
00:10:56  * hdmsjoined
00:11:18  <rphillips>The -G option should be in the agents make.bat file as well
00:11:22  <rphillips>Then program files should be used
00:12:23  <rje>i'll take that bet
00:13:07  <rje>seems odd though, as we shouldn't need the toolchain to build the msi
00:26:44  * hdmsquit (Quit: hdms)
00:35:16  * a_le_joined
00:38:44  * a_lequit (Ping timeout: 272 seconds)
00:45:08  <rphillips>I bet the root gets set from that. We can probably override it
00:59:07  * a_le_quit (Ping timeout: 264 seconds)
01:10:31  * Akagi201joined
01:11:13  * kazuponjoined
02:03:30  * Akagi201quit
02:06:28  * a_lejoined
02:07:35  * a_lequit (Read error: Connection reset by peer)
02:07:38  * a_le_joined
02:17:54  * travis-cijoined
02:17:55  <travis-ci>luvit/luvi#524 (master - fe77ec5 : Tim Caswell): The build passed.
02:17:56  <travis-ci>Change view : https://github.com/luvit/luvi/compare/0e1c98459bac...fe77ec500ba0
02:17:56  <travis-ci>Build details : http://travis-ci.org/luvit/luvi/builds/62332995
02:17:56  * travis-cipart
02:24:14  * kazuponquit (Remote host closed the connection)
02:29:22  * kazuponjoined
02:48:19  * a_le_quit (Ping timeout: 264 seconds)
02:52:12  * a_lejoined
03:21:43  <rphillips>http://cmake.3232098.n2.nabble.com/CPack-installation-directory-td7586870.html
03:21:47  <rphillips>rje: ^
03:36:14  * kazuponquit (Remote host closed the connection)
03:41:37  <rphillips>http://www.cmake.org/pipermail/cmake/2013-October/056200.html
03:41:51  <rphillips>set(CPACK_WIX_SIZEOF_VOID_P 8)
03:41:53  <rphillips>this does work
03:42:17  <rphillips>it's lame, but works
04:40:21  * kazuponjoined
05:16:51  * tetjoined
05:19:02  * endou_joined
05:26:56  * jetlquit (*.net *.split)
05:26:57  * endouquit (*.net *.split)
05:31:44  * SkyRocknRolljoined
05:42:52  * SouL_|_quit (Ping timeout: 272 seconds)
06:16:47  * SouL_|_joined
06:50:49  * kazuponquit (Remote host closed the connection)
06:51:22  * kazuponjoined
07:33:36  * kazuponquit (Remote host closed the connection)
07:33:43  * kazuponjoined
08:34:22  * kazuponquit (Remote host closed the connection)
08:34:57  * kazuponjoined
08:47:08  * kazuponquit (Remote host closed the connection)
08:47:15  * kazuponjoined
09:41:00  * SouL_|__joined
09:41:14  * SouL_|_quit (Ping timeout: 256 seconds)
09:47:18  * StepetSjoined
09:54:46  <StepetS>Hello, I have question about (unmaintained?) luvit-redis project. I found this project depends on some headers which I found only here https://github.com/parisfuja/RR-source/tree/master/libraries/luvit . I suppose this is luvit1 copy. So if i use headers from this repo would result be compatible with current version of luvit?
10:17:02  * ldub_joined
10:21:40  <ldub_>hello you all
10:21:56  <ldub_>found lit search nice ;-)
10:22:53  <ldub_>wondering if we can remove a lit package, i've heard about making it obsolete, but didn't find how to remove it.
10:29:24  * StepetSquit (Ping timeout: 256 seconds)
10:30:48  * StepetSjoined
10:49:03  * kazuponquit (Remote host closed the connection)
10:49:33  * kazuponjoined
11:12:20  * ldub_quit (Ping timeout: 264 seconds)
11:14:04  * kazuponquit (Read error: Connection reset by peer)
11:14:29  * kazuponjoined
11:15:39  * ldub_joined
11:27:34  * SouL_|__quit (Ping timeout: 244 seconds)
11:52:18  * kazuponquit (Remote host closed the connection)
11:52:44  * kazuponjoined
11:56:54  * kazuponquit (Ping timeout: 245 seconds)
12:50:41  * ldub_1joined
12:51:47  * ldub_quit (Ping timeout: 256 seconds)
12:56:33  * ldub_joined
12:58:36  * ldub_1quit (Ping timeout: 252 seconds)
13:04:09  * ldub_quit (Ping timeout: 240 seconds)
13:04:19  * ldub_joined
13:06:46  * ldub_1joined
13:08:47  * ldub_quit (Ping timeout: 256 seconds)
13:23:25  * ldub_joined
13:23:56  * ldub_1quit (Ping timeout: 256 seconds)
13:28:59  * boxofroxquit (Ping timeout: 245 seconds)
13:33:25  * SkyRocknRollquit (Remote host closed the connection)
13:38:00  * a_lequit (Remote host closed the connection)
13:54:01  * a_lejoined
13:56:12  * boxofroxjoined
14:37:01  * kazuponjoined
15:00:22  * a_lequit (Remote host closed the connection)
15:05:25  * arek_deepinitjoined
15:06:54  * a_lejoined
15:20:30  * a_le_joined
15:24:42  * a_lequit (Ping timeout: 265 seconds)
15:41:29  * hdmsjoined
15:44:26  * hdmsquit (Client Quit)
15:46:03  <rphillips>New musl out
15:53:55  * kazuponquit (Remote host closed the connection)
15:54:23  * kazuponjoined
15:59:01  * kazuponquit (Ping timeout: 265 seconds)
15:59:51  <arek_deepinit>rphillips: is that some kind of drink?
16:00:27  <rphillips>Musl is a static c library. We have been toying with it for luvit
16:00:49  <arek_deepinit>rphillips: i was joking ;), sorry if it was stupid
16:00:58  <arek_deepinit>im aware of musl existence ;)
16:01:10  <arek_deepinit>its pretty good one and much lighter than libc
16:01:36  <arek_deepinit>and implementations seems better
16:01:42  <rphillips>We have had issues with it and luajit
16:02:03  <rphillips>Lots of bug fixes in this release so it's worth a shot to try again
16:03:06  <arek_deepinit>seems like luajit development is bit stagnant recently :(
16:27:30  * kazuponjoined
16:31:03  * arek_deepinitquit (Ping timeout: 250 seconds)
16:39:16  * a_le_quit
16:58:58  <creationix>ldub_: if you really want to delete a package in lit, message me and I can delete it
16:59:14  <creationix>there is no API for unpublishing because once something is public, others may depend on it
16:59:32  <creationix>rphillips: shall we do a luvi release to get the sni support?
16:59:42  <creationix>George did a lot of work fixing the old tests
17:00:16  <creationix>https://github.com/luvit/luvi/commit/d27131a34eb0ccbfea107eb5377e3902cbf33427
17:00:47  <creationix>and then when luvit gets updated to use new luvi, we can enable this test https://github.com/luvit/luvit/blob/master/tests/test-tls-sni-server-client.lua#L23-L26
17:06:33  <creationix>idea: remote poller IoT agent
17:14:26  * hdmsjoined
17:26:44  <rje>rphillips, bleh, got it to use Program Files instead of Program Files (x86) http://www.cmake.org/pipermail/cmake/2013-October/056200.html
17:40:58  * kazuponquit (Remote host closed the connection)
17:41:26  * kazuponjoined
17:45:50  * kazuponquit (Ping timeout: 265 seconds)
18:08:23  * arek_deepinitjoined
18:09:26  * ldub_quit (Quit: Leaving.)
18:22:02  * SouL_|_joined
18:33:03  <rje>creationix, time for the agent sync
19:27:43  * kazuponjoined
19:35:14  * kazuponquit (Ping timeout: 245 seconds)
19:42:07  * erlbot--quit (Remote host closed the connection)
19:42:26  * erlbot--joined
19:49:15  * ldub_joined
20:03:16  <ldub_>hi again, i try to benchmark my tiny luvi app . my program exit without any trace. Any way to debug or something ?
20:06:47  <ldub_>sometimes i have some ENOTCONN error when checkShutdown`on coro-channel, but don't happen all times
20:21:12  * ksheedloquit (Read error: Connection reset by peer)
20:30:19  * ksheedlo-raxjoined
20:32:24  <ldub_>(i have nothing in /var/ logs)
20:36:31  * kazuponjoined
20:39:57  * kazuponquit (Read error: Connection reset by peer)
20:40:19  * kazuponjoined
21:00:18  <creationix>ldub_: I’ve seen this as well from time to time with the luvit.io server
21:00:22  <creationix>I’d love to know the root cause
21:00:42  <creationix>my plan was to put print everywhere and see how far it gets
21:01:05  <creationix>ldub_: are you using weblit or your own framework?
21:05:04  * creationixtopic: Lua + libUV + jiT = pure awesome-sauce | http://luvit.io | https://github.com/luvit/luvit | https://github.com/luvit/luv
21:06:37  <ldub_>creationix: yes
21:06:49  <ldub_>weblit-app
21:07:11  <creationix>great, me too. THe bug is either in weblit or the coro-* libraries
21:07:20  <creationix>I’m currently writing docs for weblit btw
21:07:34  <creationix>https://github.com/creationix/weblit#weblit-app
21:08:36  <creationix>ldub_: are you able to reproduce the issue reliably?
21:09:33  <ldub_>creationix: everytime i launch a bench, the process is killed
21:09:42  * {slurp}1quit (Ping timeout: 250 seconds)
21:09:47  <ldub_>(at the end of the bench)
21:09:51  <creationix>ab or wrk?
21:09:56  <creationix>or something else
21:09:57  <ldub_>wrk
21:12:06  <creationix>ok, let me try to benchmark luvit.io’s weblit app
21:12:26  <creationix>but as I’ve said, I never found the cause before, I just have luvit.io auto-restart un upstart
21:13:12  <ldub_>creationix: i confirm that it happens at the end of the wrk process
21:13:52  <creationix>yeah, I remember seeing that. I’m not sure its related to the other issue where it will sometimes just exit after certain requests
21:13:57  <creationix>time to find out
21:14:47  * StepetSquit (Quit: Leaving.)
21:16:33  <creationix>ldub_: you’ve got the latest deps right?
21:16:38  <creationix>(rm -rf deps && lit install)
21:16:54  <ldub_>humm not sure
21:18:03  <creationix>hmm, using default wrk params against luvit.io's server, it doesn't crash
21:18:14  <ldub_>https://github.com/lduboeuf/luvi-marc-ws/blob/master/package.lua#L5-L18
21:18:33  <creationix>but man is it slow (249 reqs/sec). I need to profile this app some time
21:18:44  <ldub_>^^
21:19:52  <creationix>ldub_: that should grab the latest. There havn't been any breaking changes to any of those
21:20:13  <creationix>btw, why luvit/json and lduboeuf/cjson
21:20:30  <ldub_>yes just for testing
21:20:34  <creationix>fair
21:20:46  <ldub_>found cjson faster
21:20:51  <creationix>I'll bet
21:21:08  <ldub_>i've publish it to lit
21:22:22  <creationix>I tried building it with lit make github://lduboeuf/luvi-marc-ws
21:22:30  <creationix>[string "bundle:deps/require.lua"]:253: No such module 'mconnector' in 'bundle:/libs/mclient.lua'
21:23:05  <ldub_>you've tried cjson or luvi-marc-ws ?
21:23:36  <creationix>I was trying the luvi-marc-ws app
21:23:49  <ldub_>i've didn't published mconnector yet cause it is in heavy developpement ;-)
21:24:00  <creationix>luvi apps can be published directly from github
21:24:07  <creationix>s/published/built/
21:24:27  <ldub_> ?
21:24:43  <creationix>Try `lit make github://creationix/termbox-sample`
21:24:59  <ldub_>ah ok, it does not fetch deps
21:25:14  <ldub_>mconnector is in deps folder currently
21:25:25  <ldub_>i know that i will have to remove it
21:25:36  <creationix>you know about the 'libs' folder right?
21:25:45  <ldub_>yes
21:25:53  <creationix>cool, just making sure
21:26:16  <ldub_>maybe a better place for now, but in the future mconnector will have a place for a lit package
21:26:18  <creationix>but lit make on github urls should fetch all prescribed deps
21:27:03  <creationix>anyway, when I tested my weblit app with wrk, it didn't die
21:27:10  <creationix>though I did get ENOTCONN for each connection
21:27:45  <ldub_>yeah like me
21:29:35  <ldub_>my project is only testable if you have a "marc" server running ( which has a tcp server) and some data in it
21:30:05  <creationix>ok, I'll see if I can fix this ENOTCONN message and see if that helps
21:32:49  <ldub_>nice
21:33:37  <creationix>heh, If I remove the error message, the process just silently exits!
21:34:02  <ldub_>creationix: ^^
21:34:30  <creationix>I know, right
21:35:10  <ldub_>so it is related to the tcp/http connection between wrk and the luvi process
21:37:14  * kazuponquit (Remote host closed the connection)
21:37:51  <creationix>hmm, usually, the socket is not active (according to socket:is_active())
21:38:06  <creationix>but sometimes it’s still active, even after shutdown’s callback
21:39:43  <ldub_>creationix: did you test with ab?, it does not reproduce the error here
21:40:10  <creationix>using keepalive makes a big difference
21:40:15  <creationix>it’s default in wrk right?
21:40:24  <ldub_>don't remember
21:41:21  <creationix>heh, wek doesn’t pass in a User-Agent, but ab does
21:41:33  <creationix>my logger doesn’t log requests without a user-agent
21:42:43  <ldub_>yes must add header for that
21:42:51  <creationix>ok, so using ab causes the server to exit, but not wrk (with my modifications)
21:47:34  * SouL_|_quit (Ping timeout: 244 seconds)
21:53:27  <creationix>so the silent exit is before the read end or write end events ever happen
21:53:30  <creationix>interesting
22:07:37  * ldub_quit (Ping timeout: 255 seconds)
22:08:24  * ldub_joined
22:12:51  <creationix>ldub_: this silent exit bug is pretty deep. I think it's some sort of crash and not normal exit
22:13:41  <ldub_>creationix: sorry for this ;-)
22:13:48  <creationix>yep, exit code 141
22:14:00  <creationix>no, thanks for motivating me to fix it
22:14:11  <creationix>I've seen it, but considered it low priority
22:14:22  <creationix>but when it stops others from using luvit, then it becomes more important
22:14:49  * ksheedlo-raxchanged nick to ksheedlo
22:15:26  <ldub_>creationix: i agree
22:15:27  <creationix>heh, gdb says "Program received signal SIGPIPE, Broken pipe."
22:15:41  <creationix>now we're getting somewhere
22:16:41  <ldub_>yeah saw that on http://stackoverflow.com/questions/18880606/socket-connection-getting-closed-abruptly-with-code-141
22:17:20  <ldub_>creationix: just for my self learning: how did you get exit code ?
22:17:29  <creationix>echo $?
22:17:32  <creationix>after it exits
22:17:36  <creationix>(if you're in bash)
22:17:50  <creationix>luvit server.lua; echo $?
22:17:58  <ldub_>awesome
22:19:13  <creationix>also if you want to use gdb and luvi with debug symbols:
22:19:34  <creationix>Edit luvi's makefile to change Release to Debug and `make clean regular test`
22:19:42  <creationix>(in the luvi source tree)
22:19:58  <creationix>and then gdb --args ~/luvi/build/luvi ~/luvit -- ~/luvit.io/server.lua
22:20:03  <ldub_>i see, that will be next course, thanks
22:20:10  <creationix>notice the path to luvi, luvit, and my app
22:22:12  <creationix>rphillips: do you remember why we don't signal(SIGPIPE, SIG_IGN) in luvi?
22:22:36  <creationix>thanks to ldub_ I finally found a way to reproduce a test case that need sit
22:22:39  <creationix>*needs it
22:22:49  <creationix>rje: ^
22:23:09  <creationix>(ryan is on vacation today)
22:23:27  <ldub_>oh okay, me too ^^
22:24:38  <rje>creationix, not sure. within the agent we used some pipes. if you want to ignore them do it from the lua in luvit.
22:28:26  <creationix>oh right, we can ignore that from lua
22:28:33  <creationix>ldub_: add this to your server: require('uv').new_signal():start("sigpipe")
22:28:48  <ldub_>creationix: let's try
22:28:55  <creationix>web servers hit SIGPIPE all the time when under high load
22:30:05  <ldub_>humm before `require('uv').run()`
22:30:18  <creationix>ldub_: correct, that's a blocking call
22:30:33  <creationix>right before would be fine
22:31:04  <creationix>I might just add this to weblit-app
22:32:01  <ldub_>creationix: bingo!, still have some ENOTCONN but don't exit.
22:32:11  <creationix>yep and I have a different fix for that
22:35:11  <ldub_>creationix: other question, any default tcp timeout when dealing with tcp connections, don't find where to write it ?
22:36:52  <creationix>ldub_: you mean the tcp keepalive value?
22:37:00  <ldub_>oh yes sorry
22:37:06  <creationix>socket:keepalive(enable, delay)
22:37:09  <creationix>part of the luv api
22:37:33  <creationix>http://docs.libuv.org/en/v1.x/tcp.html?highlight=keepalive#c.uv_tcp_keepalive
22:37:53  <creationix>oh, I did document that one https://github.com/luvit/luv/blob/master/docs.md#uvtcp_keepalivetcp-enable-delay
22:38:11  <ldub_>oh ok, but too low layer for me
22:38:24  <creationix>req.socket is the tcp handle
22:38:35  <creationix>I expose it for just this use case
22:38:41  <ldub_>not a coro-tcp connect(..., keepalive) feature ?
22:38:59  <creationix>hmm
22:39:38  <creationix>so you're connect is taking a long time and you want a timeout?
22:39:52  <creationix>or it's failing and you want it to wait longer?
22:42:03  <creationix>ldub_: ok, update weblit-app and coro-channel to get fixes
22:42:44  <ldub_>i did some work by using openresty's before, and found usefull to be able to set time out: conn:set_timeout(1000) -- 1 sec
22:43:17  <creationix>ok, so you want to change the internal timeout for connect
22:43:24  <creationix>I'm not sure libuv exposes that
22:43:41  <creationix>if it doesn't, you can always just use a timer and cancel the connect in theory
22:43:47  <creationix>sounds like a feature to add to coro-tcp
22:44:10  <creationix>uv request objects have a cancel method. Not that I've ever gotten it to work
22:45:42  * arek_deepinitquit (Quit: Konversation terminated!)
22:46:04  <ldub_>http://wiki.nginx.org/HttpLuaModule#tcpsock:connect
22:47:07  <ldub_>openresty's provide 2 nice features, the ability to handle timeout, and connection pool with limit
22:47:23  <ldub_>i think it's a quite common case
22:47:43  <ldub_>*use case
22:48:03  <creationix>I wonder if setting the keepalive here will do that https://github.com/luvit/lit/blob/master/deps/coro-tcp.lua#L32-L33
22:48:18  <creationix>you can try patching your coro-tcp and see if it helps
22:49:15  <ldub_> ok, i will try all that. But quite late here, time for relax. thanks for all
22:49:39  <creationix>did you get the updated weblit-app and coro-channel?
22:49:43  <creationix>it fixed my server all up
22:49:53  <ldub_>oh yes i'm going to try
22:50:04  <creationix>you can just `lit install creationix/weblit-app creationix/coro-channel` and it will install the latest over what you have
22:50:08  <creationix>ignoring your package.lua
22:52:16  <ldub_>perfect
22:52:33  <creationix>good night, thanks for helping me fix that bug
22:52:51  <ldub_>yes, last point, keepalive is also easily configurable ?
22:53:05  <creationix>http keepalive or tcp keepalive?
22:53:12  <ldub_>tcp
22:53:33  <creationix>if you can get access to the socket, it's socket:keepalive(true, seconds)
22:53:55  <creationix>the coro-tcp connect function returns read, write, socket
22:53:58  <ldub_>ok, default is infinite ?
22:54:03  <creationix>no idea
22:54:16  <ldub_>i'll check
22:54:21  <creationix>probably whatever is os default
22:54:31  <ldub_>or server side
22:55:24  <ldub_>okay see you then
22:56:21  * ldub_quit (Quit: Leaving.)
22:59:48  <creationix>alright luvit.io has new fixes deployed :)