00:40:52  * ralphtheninjajoined
01:25:20  * dg__quit (Ping timeout: 272 seconds)
05:02:28  * SkyRocknRolljoined
06:06:57  * hdmsjoined
06:07:34  * hdmsquit (Client Quit)
09:02:04  * torporjoined
10:10:29  * torporquit (Quit: Leaving.)
10:21:33  * torporjoined
10:39:15  * torporquit (Quit: Leaving.)
10:51:10  * SkyRocknRollquit (Ping timeout: 256 seconds)
11:15:49  * SkyRocknRolljoined
11:46:12  * SkyRocknRollquit (Remote host closed the connection)
11:46:28  * torporjoined
11:46:53  * torporquit (Client Quit)
12:52:14  <rphillips>good morning
14:27:16  * dan336joined
14:36:47  <rphillips>going to do a luvit release
14:36:54  <rphillips>anybody want to get anything in?
14:49:56  <creationix>rphillips: I can do a lit release first if you want
14:50:16  <rphillips>+1
14:50:42  <creationix>we're 14 commits past the last tag
14:53:58  <creationix>rphillips: ok, lit 2.1.0 released
14:54:28  <rphillips>sweet
14:55:01  <rphillips>bumped lit in luvit
14:55:08  <rphillips>i'll get the changelog together
14:57:22  * travis-cijoined
14:57:23  <travis-ci>luvit/luvit#2256 (master - 5cdc784 : Ryan Phillips): The build passed.
14:57:23  <travis-ci>Change view : https://github.com/luvit/luvit/compare/86f37445e03e...5cdc78467509
14:57:23  <travis-ci>Build details : https://travis-ci.org/luvit/luvit/builds/68333806
14:57:23  * travis-cipart
15:00:52  * travis-cijoined
15:00:53  <travis-ci>luvit/luvit#2257 (master - 3a0d49f : Ryan Phillips): The build passed.
15:00:53  <travis-ci>Change view : https://github.com/luvit/luvit/compare/5cdc78467509...3a0d49fa6047
15:00:53  <travis-ci>Build details : https://travis-ci.org/luvit/luvit/builds/68334186
15:00:53  * travis-cipart
15:02:12  <rphillips>ok 2.2.1 done
15:02:15  <rphillips>of luvit
15:02:32  * piernov_joined
15:02:38  * travis-cijoined
15:02:39  <travis-ci>luvit/luvit#2258 (master - 55aa90d : Ryan Phillips): The build passed.
15:02:39  <travis-ci>Change view : https://github.com/luvit/luvit/compare/3a0d49fa6047...55aa90da3531
15:02:39  <travis-ci>Build details : https://travis-ci.org/luvit/luvit/builds/68334506
15:02:39  * travis-cipart
15:03:09  * piernov_quit (Remote host closed the connection)
15:03:37  * travis-cijoined
15:03:38  <travis-ci>luvit/luvit#2259 (2.2.1 - 55aa90d : Ryan Phillips): The build failed.
15:03:38  <travis-ci>Change view : https://github.com/luvit/luvit/compare/2.2.1
15:03:38  <travis-ci>Build details : https://travis-ci.org/luvit/luvit/builds/68334710
15:03:38  * travis-cipart
15:10:13  * travis-cijoined
15:10:14  <travis-ci>luvit/luvit#2259 (2.2.1 - 55aa90d : Ryan Phillips): The build failed.
15:10:14  <travis-ci>Change view : https://github.com/luvit/luvit/compare/2.2.1
15:10:14  <travis-ci>Build details : https://travis-ci.org/luvit/luvit/builds/68334710
15:10:14  * travis-cipart
15:13:23  <rphillips>creationix: https://travis-ci.org/luvit/luvit/builds/68334710#L276
15:13:25  <rphillips>hmm
15:13:49  <rphillips>luvit keys are empty
15:14:10  <creationix>you hit the github rate limit
15:15:01  <rphillips>ah k
15:15:40  <creationix>Adding a GITHUB_TOKEN to the environment would greatly increase the limit, but then how would you securely upload that token
15:17:01  <creationix>looks like your limit will reset at 10:30
15:17:06  <creationix>so yo ucould just wait 13 minutes
15:17:14  <rphillips>ok
15:17:24  <rphillips>i should have done [skip ci]
15:30:42  * dan336quit (Quit: Leaving.)
15:32:56  * erlbot--_joined
15:33:23  <creationix>hmm, my plugin idea won't work on linux
15:33:34  <creationix>on osx, you can cat unix socket, but not on linux
15:33:52  <creationix>I'll bet socat works though :)
15:34:49  <creationix>yep `socat - UNIX:/var/run/gardener`
15:36:31  <rphillips>yeah
15:36:33  <rphillips>socat++
15:40:23  * travis-cijoined
15:40:24  <travis-ci>luvit/luvit#2262 (master - ebc3ddb : Ryan Phillips): The build passed.
15:40:24  <travis-ci>Change view : https://github.com/luvit/luvit/compare/55aa90da3531...ebc3ddb9e64d
15:40:24  <travis-ci>Build details : https://travis-ci.org/luvit/luvit/builds/68341129
15:40:24  * travis-cipart
15:44:43  * travis-cijoined
15:44:44  <travis-ci>luvit/luvit#2263 (master - 4482565 : Ryan Phillips): The build passed.
15:44:44  <travis-ci>Change view : https://github.com/luvit/luvit/compare/ebc3ddb9e64d...448256597334
15:44:44  <travis-ci>Build details : https://travis-ci.org/luvit/luvit/builds/68341846
15:44:44  * travis-cipart
15:52:26  <creationix>ok, luvit bridge is working! https://github.com/creationix/gardener
15:52:47  <creationix>the .ino file flashes to the sensor controller (spark core)
15:52:54  <creationix>the bridge is the luvit server
15:52:59  <creationix>the agent plugin is simple the socat line
15:53:05  <creationix>*simply
15:53:36  <creationix>the bridge accepts metrics and stores them along with the timestamps https://github.com/creationix/gardener/blob/master/spark/main.ino#L31
15:54:03  <creationix>and when socat reads the socket, it dumps the plugin report https://github.com/creationix/gardener/blob/master/bridge/server.lua#L45-L52
15:58:18  * erlbot--_quit (Remote host closed the connection)
15:59:14  <creationix>now to setup a dedicated server. I'm thinking one of the RPIs
16:01:41  * SkyRocknRolljoined
16:04:37  * dan336joined
16:47:16  <creationix>hmm, it runs fine when I run it manually, but pretty-print crashes with stack overflow when running via upstart
16:47:28  <creationix>rphillips: didn't you see a stack overflow issue the other day with pretty-print dump?
16:47:42  <rphillips>it's been there awhile
16:47:52  <rphillips>only when I use the terminal in emacs
16:49:07  <creationix>I'll bet it's the same issue
16:49:15  <creationix>something to do with assumptions about the terminal
16:49:22  <creationix>I'll bet upstart doesn't allocate a tty
17:12:46  * travis-cijoined
17:12:47  <travis-ci>luvit/luvit#2264 (master - feca06a : Tim Caswell): The build passed.
17:12:47  <travis-ci>Change view : https://github.com/luvit/luvit/compare/448256597334...feca06a94b38
17:12:47  <travis-ci>Build details : https://travis-ci.org/luvit/luvit/builds/68354319
17:12:47  * travis-cipart
17:14:15  <creationix>rphillips: I fixed the bug in pretty print
17:14:20  <creationix>did you release luvit already?
17:16:03  <creationix>https://github.com/luvit/luvit/commit/feca06a94b387c3ae276fdef79b6efa15fdacd90
17:18:16  <rphillips>i did. but we have a few more patches
17:18:19  <rphillips>merged this morning
17:18:42  <rje>bbiab drs appt, in the meantime can you guys give this a few moments of thought? https://github.com/virgo-agent-toolkit/rackspace-monitoring-agent/issues/765
17:24:40  <rphillips>nice patch...
17:24:47  <rphillips>i looked at that code and didn't figure it out
17:27:15  <rphillips>creationix: i think we should roll another release
17:28:49  <creationix>rphillips: yeah, it was tricky to debug
17:47:24  <dan336>so when lit says: 'using dependency: fe4e98eb16bc1f359e7c4535265ebedc45e024a6 as coro-http' does that mean that it isn't going to use the one in my deps folder?
17:50:55  <dan336>because I'm trying to change that one to do some debugging and testing, and none of the changes I'm making are making into the app I'm making
18:01:25  * SkyRocknRollquit (Remote host closed the connection)
18:04:59  <creationix>dan336: it should use the local dep. Does the hash change when you modify the code?
18:06:04  <dan336>what hash do you mean?
18:06:56  <dan336>if you mean the hash of the file contents, then yes it would change when I modify the contents of the file.
18:07:08  <dan336>its alright though, I worked around it.
18:07:23  <dan336>still strange that it stopped letting me do that.
18:10:12  <dan336>also fixed the issue I ran into yesterday: https://github.com/luvit/lit/pull/96
18:25:29  <creationix>dan336: I mean the hash for the dependency. Local dependencies are imported into the database and their hash is shown
18:29:15  <creationix>dan336: also why did you change the loop, this is enough right? https://github.com/luvit/lit/pull/97
18:29:51  <dan336>the forr loop breaks out when item is nil
18:29:53  <dan336>*for
18:29:59  <dan336>so it never runs the check
18:30:07  <dan336>thats how the for loop works
18:30:45  <dan336>at least that was my understanding, otherwise the #item == 0 check would throw an error wouldn't it?
18:31:16  <creationix>ahh, right
18:31:52  <creationix>so what change are you trying to do then?
18:32:56  <dan336>so if item is nil, that means the connection closed, so setting `res.keepAlive = false` causes the connection to not be added back into the connection pool. which is what it was doing before.
18:33:22  <creationix>dan336: ok, I think I got it. how about this? https://github.com/luvit/lit/pull/97/files
18:33:51  <dan336>yeah that looks good too.
18:34:08  <dan336>well no
18:34:21  <dan336>what if item is nil AFTER a loop iteration?
18:34:54  <creationix>you can't read past the loop or it will break keepalive
18:35:23  <dan336>no i mean the first loop iteration item has a value
18:35:34  <dan336>the second loop iteration item is nil so it breaks out
18:35:54  * piernovjoined
18:35:55  <dan336>wait I"m just reading ti wrong.
18:36:03  <dan336>yeah that will work fine.
18:42:04  <creationix>dan336: I'm not sure my patch will make a difference though.
18:42:14  <dan336>really why not?
18:42:26  <creationix>well, not in the normal case. It will only help for early disconnects
18:42:44  <creationix>the http-codec should always emit the empty string for valid streams
18:43:02  <creationix>we need a way to know if a socket is still active before reusing it
18:43:19  <creationix>and we need a way to clean out sockets when they disconnect and not have them waiting around
18:43:36  <dan336>well even if you could check if it was still alive, it wouldn't always work.
18:44:20  <dan336>you could have just done the check milliseconds before the fin packet arrived.
18:45:14  <dan336>its one of the fun things about http keepalive, the server can close without informing the client.
18:45:34  <creationix>right, so we could be in the middle of sending a second request and get shurdown
18:45:39  <creationix>*shutdown
18:46:08  <dan336>thats correct, which is one of the reasons that the expect: continue header exists.
18:46:39  <creationix>but if the server sent a keepalive header, we should be safe to reuse it if we're quick right?
18:46:58  <creationix>though we should probably put a short timeout on that socket and kill it after a while
18:47:03  <dan336>nop not even then,
18:47:07  <dan336>*nope
18:47:41  <rphillips>creationix: you want to enable keepalive on the socket
18:47:58  <rphillips>it'll tell you when there is a dead peer
18:48:17  <creationix>how will it tell us though? What libuv API?
18:48:55  <rphillips>you should get the close event
18:49:08  <rphillips>an empty read/error
18:50:14  <rphillips>http://www.tldp.org/HOWTO/html_single/TCP-Keepalive-HOWTO/#checkdeadpeers
18:50:36  <dan336>yeah, but I think the defaults are horribly high on those.
18:50:37  <rphillips>it's what node's agent module does
18:51:36  <dan336>ah but you can set them on a per socket basis?
18:51:48  <rphillips>right
18:51:54  <rphillips>and it's tunable via the OS
18:52:47  <creationix>right, we need to somehow gracefully handle when write or read on the reused socket fails
18:52:56  <creationix>maybe retry with a new socket?
18:53:25  <creationix>write would fail just as fast as read right?
18:54:03  <dan336>read is much more dependable
18:54:05  <creationix>we could add a "reused" flag on the socket and if the initial write fails, just grab another socket and try again instead of crashing
18:54:31  <dan336>I tested something out similar to that and it worked just fine.
18:54:53  <creationix>I guess it's safe to start reading before writing, we just need to write the logic so we're not blocked on the read
18:55:21  <dan336>well it should be safe to write the header and body and then try to read the response header
18:55:37  <creationix>the write won't get an error?
18:55:57  <dan336>not unless the socket is closed, but the code doesn't currently check for errors
18:56:41  <creationix>right, so I need to check for errors on write and read to be safe and just start over with a new socket if it's a reused socket
18:56:53  <creationix>if it's a fresh socket, give up
18:57:14  <creationix>I don't like the idea of re-sending the request automatically
18:57:22  <creationix>what if it was received and had side-effects
18:58:09  <dan336>thats true.
18:58:35  <dan336>what would you do if you were writing an http client and got a connection close? just give up or would you try again?
18:59:12  <dan336>I suppose it depends on what you were writting...
19:00:25  <creationix>so it's safe to restart as long as the socket is reused *and* the full request hasn't been sent
19:05:30  <creationix>dan336: what's the error you get? Does it hit this path? https://github.com/luvit/lit/blob/master/deps/coro-http.lua#L130
19:05:46  <creationix>(when you reuse a closed socket)
19:06:47  <dan336>before the patch we were looking at, it would yield in the read() call right before that line and never be resumed. with the patch it hits that error.
19:12:47  <creationix>dan336: what do you think of this? https://github.com/luvit/lit/commit/368075e682caf5c694878c058b7dd3994827f9b7
19:13:45  <dan336>do you think a `write()` is needed in that case too? isn't that how the handles are closed and freed?
19:14:13  <creationix>perhaps
19:14:55  <creationix>dan336: https://github.com/luvit/lit/commit/fc9af1527c09ac3f89b902f836b055f5bda0b94e
19:15:27  * sousouxjoined
19:16:04  <dan336>that looks good.
19:16:06  <creationix>though I'm kinda suprized that all those writes won't cause an error if the socket is closed
19:16:11  <creationix>is that really how tcp works?
19:17:07  <dan336>kind of, its really more of a timing issue.
19:17:21  <sousoux>creationix: has anyone used the https luvit server much?
19:18:00  <rphillips>we use the client a lot
19:18:05  <rphillips>server... not so much
19:18:12  <sousoux>I've added in keep-alive management to http and I now get my process spinning away into 100% cpu zone
19:18:20  <sousoux>Can't seem to track it down
19:18:56  <rphillips>have a test case?
19:18:56  <sousoux>Seems to be happening in tls common.lua but when it really spins away I can't even get a trace out of it
19:19:03  <sousoux>Not yet
19:19:26  <sousoux>If I had a test case I think I would know what it was!
19:19:44  <rphillips>linux? osx? strace might help
19:19:48  <sousoux>linux
19:19:48  <rphillips>or activity monitor
19:19:50  <creationix>sousoux: this is using luvit's node-style code and not coro-http in lit right?
19:20:03  <sousoux>tried strace, valgrind, gdb,
19:20:12  <sousoux>still not getting a clue
19:20:32  <sousoux>valgrind profiling locked my entire VM up
19:20:40  <creationix>impressive
19:20:59  <sousoux>breaking in gdb seems to show that it is in lua
19:21:28  <sousoux>Or at least I break into the pcall to the read callback
19:21:36  <sousoux>from uv
19:21:52  <sousoux>I'm not convinced that is every returning
19:21:55  <sousoux>ever
19:22:39  <sousoux>Hmm just wanted to know if someone had seen anything like that. I'll track it down in the end PITA
19:23:46  <sousoux>Need https server working. Should have taken your advice and gone the coro direction. Too late now.
19:24:00  <creationix>I run all my luvit servers behind nginx, so I only use https for clients
19:28:54  * piernovquit (Remote host closed the connection)
19:42:25  <creationix>heh, if you reuse an http connection for exactly 100 requests through nginx with tls, it will close the connection
19:42:31  <creationix>(gracefully with Connection: close)
19:42:52  * piernovjoined
19:43:30  <creationix>sure enough, it's a tunable param http://nginx.org/en/docs/http/ngx_http_core_module.html#keepalive_requests
19:44:57  * piernovquit (Read error: Connection reset by peer)
19:46:39  * piernovjoined
19:48:46  * piernovquit (Read error: Connection reset by peer)
19:49:07  <dan336>so the http-codec doesn't handle decoding responses for HEAD requests correctly. HEAD requests might have a content-length header, but no body, and the decode hangs trying to read the body if the content-length header is present.
19:49:22  <creationix>hmm, I thought I had logic for that
19:49:28  <creationix>but I may have lost if in early refactoring
19:50:39  * piernovjoined
19:51:27  <dan336>yeah the only reason that HEADs and 304 work with weblit at all is because weblit-auto-headers closes the connection in those cases.
19:51:44  <creationix>dan336: HEAD requests should always jump to decodeEmpty right?
19:52:11  <creationix>hmm, unless keepAlive is false maybe
19:52:13  <dan336>thats right, 304 as well.
19:52:26  <creationix>well, 304 could have a body I think
19:53:00  <creationix>nevermind, that's forbidden by the spec
19:53:02  <dan336>not it cant. the rfc says 'MUST NOT have a body'
19:59:03  <creationix>hmm, the HEAD response is tricky
19:59:44  <creationix>HEAD request (and any request) is allowed to have a body at the parsing level, it just doesn't mean anything at the semantic level for requests like GET and HEAD
20:00:02  <creationix>but the response to a HEAD requests may have content headers but no content
20:00:20  <creationix>so somehow http-codec needs to know which responses belong to HEAD requests
20:00:25  <rphillips>i think there is a bug in the luvit https implementation
20:01:37  <rphillips>https://gist.github.com/rphillips/14f4e8e4e096be101542
20:01:48  <rphillips>rje: ^
20:03:28  <dan336>creationix: could it be solved by "upgrading" the connection to a fresh http codec when a HEAD request is sent?
20:04:00  <dan336>then it wouldn't have to be fixed at the codec level
20:04:36  <creationix>dan336: you mean when the HEAD response head is parsed?
20:04:45  <creationix>that's where we get stuck, the head is parsed and we're waiting on data
20:05:56  <rje>rphillips, is siege not getting the body?
20:06:09  <sousoux>Found it. My problem not yours
20:06:21  <rphillips>sousoux: phew...
20:06:31  <rphillips>but I do think siege is not working right
20:06:38  <rphillips>rje: it's getting the body of 12 bytes
20:07:32  <dan336>creationix: yes i mean when it is parsed.
20:08:02  <creationix>dan336: btw, here is a fun test client https://gist.github.com/creationix/b2d25456345f88f74dec
20:08:26  <creationix>though the luvit.io server is too predictable. It doesn't test much of the error cases
20:09:19  <dan336>oh thats cool, it does 2 connections in parrallel 200 times.
20:09:49  <creationix>yep
20:09:53  <rje>rphillips, vidyo?
20:10:01  <creationix>I'm really liking split, should have made it sooner
20:10:24  <dan336>yeah that seems really handy. I'm going to use it as soon as this http stuff is figured out :)
20:11:12  <dan336>i have a process where I'm reading files from the disk and uploading them to a remote server, and using split would mean I could limit it to a certain number of files at a time.
20:11:39  <rphillips>rje: sure
20:12:19  <dan336>creationix: whats really fun is that you can do a parallel for i in pairs() loop :)
20:12:36  <sousoux>I'll do a pull request of the http.lua keep-alive stuff if you are interested.
20:12:54  <creationix>sousoux: sure
20:13:20  * piernovquit (Remote host closed the connection)
20:14:33  <creationix>dan336: yeah, I think restarting the codec after parsing the head of an HEAD response is the only sane way to handle this
20:14:40  <creationix>it just makes me sad I can't handle this at the parser level
20:15:08  <creationix>but it would require some side-channel and coupling between the two parsers
20:15:19  <dan336>well you can but it would require creating both the decoder and encoder at the same time so that they can share scpe
20:15:22  <dan336>*scop
20:15:23  <dan336>yeah
20:15:52  <creationix>http is just a bad design
20:15:56  <creationix>but we're stuck with it :P
20:16:08  <creationix>maybe some day http2 will replace it
20:16:20  <dan336>creationix: this is what makes me excited about the coro-split -> https://gist.github.com/DBarney/8bca7fbeff9b62be08c8
20:16:30  <dan336>yeah maybe someday.
20:17:00  * piernovjoined
20:17:12  <creationix>dan336: oh, that's neat. It's not actually parallel though, just concurrent. It's still single threaded
20:17:26  <creationix>but yeah, if you do any I/O in the work section, they will interleave
20:17:48  <dan336>exactly. and yeah not parallel, just concurrent :)
20:18:00  <dan336>i tend to get my terminology mixed up.
20:18:25  <creationix>and you can share the same function definition for both halves
20:18:32  <creationix>it will still create an independent task thread for each
20:18:44  <dan336>yeah, that even better :)
20:19:11  <creationix>maybe I'll make a variant of split that runs x clones of a task
20:19:44  <dan336>either way, its still very cool.
20:20:04  <creationix>the only danger is the iterator needs to be able having itself called after it ended
20:20:18  <creationix>I don't know about pairs, but my custom iterators can't always handle this
20:20:36  <dan336>thats true.
20:21:24  <creationix>yeah, actually pairs won't work at all since it requires some arguments, but the idea is good in general
20:22:10  * piernovquit (Ping timeout: 272 seconds)
20:22:50  <rphillips>fixed it: https://github.com/luvit/luvit/pull/757/files
20:23:00  <dan336>thats too bad, but the actual one I'm going to use is the fs.scandir, which looks like it should work.
20:23:06  <rphillips>sousoux: so that fix will affect you
20:23:14  <rphillips>should work better
20:24:53  * piernovjoined
20:24:53  * travis-cijoined
20:24:54  <creationix>dan336: yep, I make my iterators not require any arguments
20:24:54  <travis-ci>luvit/luvit#2266 (fixes/tls_socket - d1e0434 : Ryan Phillips): The build failed.
20:24:54  <travis-ci>Change view : https://github.com/luvit/luvit/commit/d1e043458a2c
20:24:54  <travis-ci>Build details : https://travis-ci.org/luvit/luvit/builds/68380467
20:24:54  * travis-cipart
20:24:58  <rphillips>ack
20:25:16  <rphillips>rate limit
20:25:57  <creationix>rphillips: we could create a dummy github account, create a read-only token and store it in the build script
20:26:18  <creationix>sure people could impersonate the account, but it wouldn't gain them much
20:26:33  <rphillips>i think travis supports encrypted environment variables
20:26:55  <creationix>or that, but still make it read-only so that travis can't write to anything
20:27:44  <creationix>or if you're not paranoid, just include a read-only token in plain view. Worst thing someone can do is read data as you using your rate limit
20:28:56  <creationix>rphillips: not sure if it's related to your recent tls fix, but I made a change to coro-http where it unrefs sockets while they are idle in the connection pool and re-refs them when it hands them back out
20:29:09  <creationix>that way the process's uv loop isn't hanging on idle connections
20:29:47  <creationix>I don't remember if luvit's http client reuses sockets or not
20:29:59  <rphillips>creationix: https://github.com/blog/2024-read-only-deploy-keys
20:30:05  <rphillips>could we use one of these?
20:30:58  <creationix>https://github.com/luvit/lit/commit/ac34a54f3c8d70f613bdf8c92e39be9c917d01b0
20:31:26  <creationix>rphillips: no, but that's neat
20:31:32  <creationix>you need a read-only token
20:31:52  <rphillips>oh, i see
20:31:55  <rphillips>this is an ssh key
20:31:59  <creationix>https://github.com/settings/tokens/new
20:32:17  <creationix>just uncheck everything and I think it's read-only
20:33:28  <creationix>Grants read-only access to public information (includes public user profile info, public repository info, and gists)
20:38:39  <rphillips>creationix: where does this token get passed to ?
20:38:44  <rphillips>which part of the script
20:38:56  <creationix>lit looks for it in an environment variable called GITHUB_TOKEN
20:39:32  <creationix>rphillips: https://github.com/luvit/lit/blob/master/libs/github-request.lua#L32-L36
20:40:46  <creationix>rphillips: you're hitting this now because I enabled signature checking in the client
20:41:04  <creationix>I'm not sure this even adds much security since you already have to trust the server when dealing with shared accounts like "luvit"
20:41:23  <creationix>and the server already verifies all signatures before allowing people to upload anything
20:41:35  <creationix>I could turn on verification in the client by default
20:45:59  <rphillips>https://github.com/luvit/luvit/commit/6873effe8670d8bff536cbf5f6c8e610d852e1b9
20:46:02  <rphillips>ok. we will see
20:47:24  <rphillips>https://travis-ci.org/luvit/luvit/builds/68383540#L87
20:47:25  * travis-cijoined
20:47:26  <travis-ci>luvit/luvit#2268 (fixes/tls_socket - 6873eff : Ryan Phillips): The build was fixed.
20:47:26  <travis-ci>Change view : https://github.com/luvit/luvit/compare/d1e043458a2c...6873effe8670
20:47:26  <travis-ci>Build details : https://travis-ci.org/luvit/luvit/builds/68383540
20:47:26  * travis-cipart
20:47:31  <rphillips>sweet!
20:52:39  <creationix>dan336: this should fix the head response issue you were seeing https://github.com/luvit/lit/commit/4f4ec6c87811e8a997a122b2397a73c04812f816
20:53:32  <creationix>rphillips: also we need something like this in luvit's use of http-codec if we don't already
20:53:34  <creationix>^
20:53:43  <creationix>I just can't handle it sanely at that level
20:54:11  <rphillips>creationix: wdym?
20:54:38  <creationix>the response for a HEAD request may contain headers like Content-Length or chunked encoding
20:54:42  <creationix>but there will never be a body
20:55:01  <creationix>the codec has no idea since the HEAD request that belongs to this response is so far away
20:55:16  <rphillips>gotcha
20:55:47  <creationix>most likely it's in some client encoder in some other part of the code, and even if you linked the encoder to the decoder with some shared side-channel, pipelining will cause trouble and you'd have to count requests/responses
20:56:01  <creationix>it's much easier for the code that has req and res in the same closure to simply reset the res after reading the head
20:56:36  <dan336>creationix: thank you, it will be very nice to use HEAD requests!
20:56:59  <creationix>rphillips: you're not using coro-wrapper, but the idea there is I allow hot-replacing the decode function https://github.com/luvit/lit/commit/4f4ec6c87811e8a997a122b2397a73c04812f816#diff-32cb0065744f95a5c7eaca646111360eR80
20:57:04  <creationix>this way buffered data isn't lost
20:57:24  <creationix>https://github.com/luvit/lit/blob/master/deps/coro-wrapper.lua#L23-L25
20:57:34  <rje>rphillips, trying to work in this solution http://stackoverflow.com/questions/12693327/running-a-powershell-script-as-admin-without-typing-in-passwords
20:57:43  <creationix>dan336: can you test this PR that has several fixes for you?
20:57:58  <dan336>creationix: sure
20:58:08  <creationix>https://github.com/luvit/lit/pull/97
21:07:43  <dan336>creationix: so it resets it correctly, but it still is trying to read a body.
21:08:04  <creationix>how can I test this?
21:08:22  <creationix>I guess, just make a HEAD requests to something with content normally?
21:08:25  <dan336>but if the for loop and the continue check were wrapped in an if statment that checked to see if it was reset, it works fine.
21:08:29  <dan336>yeah
21:08:58  <dan336>I updated weblit-auto-headers to return '' instead of nil on HEAD and 304, and that is how I am testing it locally.
21:10:27  * travis-cijoined
21:10:28  <travis-ci>luvit/luvit#2270 (fixes/tls_socket - ce3611c : Ryan Phillips): The build passed.
21:10:28  <travis-ci>Change view : https://github.com/luvit/luvit/compare/6873effe8670...ce3611cc5c1f
21:10:28  <travis-ci>Build details : https://travis-ci.org/luvit/luvit/builds/68386415
21:10:28  * travis-cipart
21:11:06  <creationix>it hangs just fine making HEAD against luvit.io
21:11:19  <creationix>nginx should be doing the right thing on it's end
21:11:33  <dan336>well nginx should be handling it fine.
21:12:29  <creationix>dan336: that's so strange. Why is read blocking
21:12:43  <dan336>because its trying to read a head again. its a new codec
21:13:01  <dan336>thats it initial state
21:13:52  <creationix>oh, I see what you mean, I shouldn't try to read the body in the HEAD case!
21:13:57  * creationixoops
21:14:07  <dan336>:) exactly
21:16:04  <creationix>got it. I force-pushed that commit with the fix https://github.com/luvit/lit/commit/4d60b6ebaa939f5304e100c300ed5ec1572ae7d0?w=1
21:17:06  <dan336>ok, I just tested it out. It works like a charm!
21:17:18  <dan336>HEAD requests now work
21:17:23  <creationix>awesome, I'll publish a new coro-http then
21:17:39  <dan336>sweet, thank you!
21:19:52  <creationix>dan336: published as coro-http v1.2.0
21:19:57  <creationix>thanks for finding the bugs
21:20:18  <creationix>and for the idea of how to handle the HEAD response
21:20:51  <dan336>yeah no problem
21:47:11  * travis-cijoined
21:47:12  <travis-ci>luvit/luvit#2272 (master - 49e9ac4 : Ryan Phillips): The build passed.
21:47:12  <travis-ci>Change view : https://github.com/luvit/luvit/compare/6af94274bdf4...49e9ac4e885d
21:47:12  <travis-ci>Build details : https://travis-ci.org/luvit/luvit/builds/68391025
21:47:12  * travis-cipart
21:56:34  * dg__joined
22:08:39  * travis-cijoined
22:08:40  <travis-ci>luvit/luvit#2273 (feat/tls_client_reuse - 1a5db4d : zhaozg): The build failed.
22:08:40  <travis-ci>Change view : https://github.com/luvit/luvit/commit/1a5db4d7b35d
22:08:40  <travis-ci>Build details : https://travis-ci.org/luvit/luvit/builds/68394080
22:08:40  * travis-cipart
22:08:52  <rphillips>hmm https://travis-ci.org/luvit/luvit/builds/68394080#L1810
22:10:11  <rphillips>https://github.com/luvit/luvi/pull/101
22:12:15  <creationix>yep
22:51:20  * travis-cijoined
22:51:21  <travis-ci>luvit/luvi#560 (fixes/bump_lua_openssl_for_session_reuse - 83929d9 : Ryan Phillips): The build passed.
22:51:21  <travis-ci>Change view : https://github.com/luvit/luvi/commit/83929d992565
22:51:21  <travis-ci>Build details : https://travis-ci.org/luvit/luvi/builds/68394738
22:51:21  * travis-cipart
22:59:28  * dan336quit (Quit: Leaving.)
23:09:54  <rje>rphillips, yt?
23:16:43  <rphillips>rje: hey, back
23:17:46  <rphillips>cpu usage with ssl and luvi usage is quite high
23:17:51  <rphillips>luvit*
23:21:50  <rje>rphillips, https://gist.github.com/rjemanuele/8ef88137d04f3234e7dd
23:22:09  <rphillips>works?
23:22:27  <rje>so that will run the tests in the right directory as admin, but it spawns another window
23:24:40  <rphillips>-NoNewWindow
23:24:42  <rphillips>?
23:25:13  <rje>incompatable with -verb runas
23:26:17  <rphillips>bummer
23:26:28  <rphillips>so, we can't see the output?
23:32:01  <rje>right, i'm going to try a few more things and then email appveyor support, there has got to be a way
23:32:30  <rphillips>nice... yeah, an email would be good
23:36:34  <rje>i wonder if you can get rdp on an appveyor account so i can test something
23:53:29  <rje>rphillips, they say it should just work. plan b, write a powershell script that does exactly what i want in a test repo