01:02:46  * Akagi201joined
01:04:49  * kazuponjoined
01:15:39  * DarkGodquit (Ping timeout: 245 seconds)
02:00:04  * Akagi201quit
02:08:34  * kazuponquit (Remote host closed the connection)
02:09:00  * kazuponjoined
03:36:03  * hdmsquit (Quit: hdms)
03:59:26  * kazuponquit (Ping timeout: 244 seconds)
04:55:26  * kazuponjoined
05:40:05  * SkyRocknRolljoined
05:58:20  * kazuponquit (Remote host closed the connection)
05:58:48  * kazuponjoined
06:04:58  * kazuponquit (Remote host closed the connection)
06:05:04  * kazuponjoined
07:31:26  * kazuponquit (Remote host closed the connection)
07:31:56  * kazuponjoined
07:42:32  * DarkGodjoined
08:00:28  * kazuponquit (Remote host closed the connection)
08:00:35  * kazuponjoined
08:16:16  * bjornjoined
09:00:28  * kazuponquit (Remote host closed the connection)
10:10:42  * kazuponjoined
11:46:52  * kazupon_joined
11:47:43  * kazuponquit (Read error: Connection reset by peer)
11:49:21  * SkyRocknRollquit (Ping timeout: 240 seconds)
11:50:54  * SkyRocknRolljoined
12:29:08  * kazupon_quit (Remote host closed the connection)
13:27:24  <rphillips>morning
14:32:11  * dan336joined
14:44:22  * travis-cijoined
14:44:23  <travis-ci>brimworks/luvi#25 (master - 2ff3dde : Brian Maher): The build passed.
14:44:23  <travis-ci>Change view : https://github.com/brimworks/luvi/compare/f1e1bb8d57e7...2ff3dde70294
14:44:23  <travis-ci>Build details : http://travis-ci.org/brimworks/luvi/builds/64262264
14:44:23  * travis-cipart
15:08:07  <creationix>rphillips: mornin’
15:08:16  <rphillips>hiya tim!
15:08:28  <creationix>I’m trying to fix my ISP hijacking redirects to their overloaded link tracker
15:08:43  <creationix>end result is half the links I click end up with a big page saying “Server overloaded!”
15:09:11  <creationix>I’m already using google dns in my router, they appear to be hijacking http traffic
15:12:22  <rphillips>:(
15:14:57  * SkyRocknRollquit (Ping timeout: 240 seconds)
15:17:03  <creationix>oh well, now it’s not reproducing
15:17:07  <creationix>they must know I’m looking
15:17:31  <creationix>rphillips: did you ever figure out why we’re getting hash verification failures using lit on travis?
15:17:43  <rphillips>not yet
15:17:47  <creationix>I can’t reproduce it locally and all the objects on the server are correct
15:17:57  <rphillips>same here... i tried it locally as well
15:22:01  <rphillips>i wonder if it's a partial read
15:33:59  * kazuponjoined
15:37:02  <rphillips>does lit source main.lua within the project
15:37:04  <rphillips>?
15:37:35  <rphillips>hmm. doesn't look likt it
15:37:39  <rphillips>like*
15:48:12  <rphillips>works on all my linux boxes :(
15:51:51  <creationix>what do you mean “source” main.lua?
15:52:01  <creationix>new lit stores all lua files as bytecode
15:52:11  <creationix>but with full debug info so that you still get proper stack traces
16:12:53  * hdmsjoined
16:20:32  <rphillips>perhaps we should do a release with some more log messages
16:26:23  <creationix>rphillips: good idea, I can make that error more verbose
16:29:59  <creationix>ok, if the objects come in out of order, it will have that error
16:43:37  <rje>interesting
16:44:57  <creationix>I wonder if two requests are getting multiplexed over the same socket
16:45:49  <creationix>we send a list of hashes that we lack and then read the hashes values off the socket one at a time https://github.com/luvit/lit/blob/master/libs/rdb.lua#L141-L145
16:46:01  <creationix>it fails if an object doesn’t match the expected hashes in order
16:46:25  <creationix>s/hashes values/values/
16:58:06  <creationix>rphillips: can you use lit in master or do you need a release cut? https://github.com/luvit/lit/commit/f11bff37eb5f068d61f91dd3ea4c89e5ae509323
16:58:55  <creationix>you could add `lit make github://luvit/lit` and then use `./lit`
17:01:02  <rphillips>creationix: i think we will need a release.
17:05:45  <creationix>rphillips: ok, try lit 1.2.10
17:06:18  <rphillips>thanks
17:07:28  * kazuponquit (Ping timeout: 255 seconds)
17:14:25  <rphillips>ok, it's building
17:18:07  <rphillips>creationix: https://travis-ci.org/virgo-agent-toolkit/rackspace-monitoring-agent/builds/64289681#L464
17:19:36  <creationix>rphillips: hmm, that actual hash isn’t in the list at all
17:21:53  <rphillips>hmm. line 154 has a shadowed 'i' var
17:22:14  * DarkGodquit (Ping timeout: 256 seconds)
17:38:12  <creationix>rphillips: that shouldn’t matter
17:39:05  <creationix>rphillips: i could log the actual data that gave the incorrect hash, also I could log every time a wants command was sent (but this would add noise to the non error case)
17:45:05  <creationix>oh, we do log when wants is sent, hmm
17:45:38  <creationix>maybe I could add when the fetch completes to make sure they don’t overlap
18:19:26  * DarkGodjoined
18:21:16  <creationix>https://github.com/luvit/lit/commit/30a58ff8e02e8be89389c8b93d46d91b8c4840a6
18:27:19  <rphillips>nice
18:27:20  <rphillips>that should help
18:34:05  <creationix>rphillips: try 1.2.11
18:39:28  <rphillips>creationix: https://travis-ci.org/virgo-agent-toolkit/rackspace-monitoring-agent/builds/64300865#L467
18:41:16  <creationix>rphillips: interesting, empty
18:44:35  <creationix>vidyo crash :(
18:44:45  <rphillips>any errors from the lit server? hangups?
18:47:43  <creationix>this is the data it should have gotten https://gist.github.com/creationix/8532a8342e102b16fb34
18:50:36  <rphillips>hmm.. looks like util.lua
18:51:01  <rphillips>util/misc.lua
18:51:06  <rphillips>in the virgo-base repo
18:56:41  <creationix>I think this is the relevent logs from that travis run https://gist.github.com/creationix/8532a8342e102b16fb34#file-srever-log
18:58:42  <creationix>yep, that first GET request is the version check at https://travis-ci.org/virgo-agent-toolkit/rackspace-monitoring-agent/builds/64300865#L155
19:03:42  <creationix>what’s strange is git objects should *never* be empty strings
19:04:18  * kazuponjoined
19:04:22  <creationix>the blob for an empty file contains “BLOB 0\0”
19:09:17  * kazuponquit (Ping timeout: 244 seconds)
19:15:24  <rphillips>perhaps it was a bad push?
19:15:30  <rphillips>s/push/publish?
19:15:50  <creationix>nope, the object checks out on the server
19:16:02  <creationix>I wonder if travis is killing the websocket connection
19:17:50  <creationix>so “send” is sent on the wire as simply a deflated message in a binary websocket frame
19:18:04  <creationix>so it would need proper websocket framing and contain 'x\001\003\000\000\000\000\001’ to decode as “”
19:18:44  <creationix>and we’re using wss:// so travis can’t interfere with the stream
19:26:39  <creationix>hmm, if there is an invalid frame, it will be decoded as send with empty body
19:27:23  <creationix>> require('miniz').inflate('not right') —> “”
19:28:54  <creationix>I still don’t understand how that could happen on only travis and at the exact same file every time
19:29:09  <creationix>the same luvit server works fine when building locally
19:29:19  <creationix>and the stream is tls so proxies can’t mess with it
19:33:39  <creationix>rphillips: ok, try again with 1.2.12
19:34:06  <creationix>https://github.com/luvit/lit/commit/e35c7587dc7e72bf79dd21eecd011fbbb9b94faf
19:51:23  <creationix>yep, it’s an inflate error, but why on travis? https://travis-ci.org/virgo-agent-toolkit/rackspace-monitoring-agent/builds/64311077#L461
19:54:44  <creationix>maybe the packet sizes are smaller and exposing a bug in my websocket deframing code?
19:56:34  <rphillips>quite possible
20:01:09  <creationix>the version on the server is 2989 bytes of compressed data
20:01:23  <creationix>the received data is 2965 compressed
20:02:04  <creationix>(it’s not the same compressed data, but both are compressed from the same source using the same compression library, so I would expect them to match)
20:04:37  <rphillips>maybe there is still an issue with the ssl flush?
20:05:12  <creationix>perhaps, but this is mid stream and my deframing logic should notice when there are missing bytes
20:05:20  <creationix>websocket frames have length in their header
20:05:31  <rphillips>ah, and the lengths match up?
20:05:41  <rphillips>the websocket frame lenghts*
20:05:52  <creationix>good question
20:08:49  <creationix>does this sound right on line 76? https://github.com/luvit/lit/blob/master/deps/websocket-codec.lua#L76-L79
20:09:53  <creationix>I’m not sure why it has -1 there
20:10:26  <creationix>offset is zero indexed I think and len can be zero
20:13:45  <rphillips>the -1 does look strange
20:16:55  <creationix>I’m pretty sure that’s wrong. I’m trying with the -1 removed to see if that fixes it
20:17:12  <creationix>https://travis-ci.org/virgo-agent-toolkit/rackspace-monitoring-agent/builds/64315479
20:19:12  <creationix>not sure how an off-by-one error would explain 24 bytes missing though
20:22:30  <rphillips>started
20:23:05  <rphillips>bingo
20:23:47  <creationix>well, there you have it. The mtu size on travis is different enough to trigger a 1-byte wide bug in my parser
20:23:57  <creationix>it’s crazy how consistent it was
20:25:18  <creationix>I remember offset being called something else that was 1-indexed originally
20:25:34  <creationix>I must have missed that -1 when I was going through changing it to a zero-indexed offset
20:25:50  <rphillips>i'll rebase that PR... I want to bump the package.lua version as well
20:26:27  <creationix>rje: found the bug https://github.com/luvit/lit/commit/0d6369aac65494b582fd59dacd4ee5c735e1d605#diff-13fe9978848d9c5f7577dbfa3c25bd81L76
20:27:41  <creationix>ok, pushed fixes to server. It could prevent some people from publishing
20:28:12  <rphillips>i rebased the PR with your version bump and my version bump for the agent
20:28:50  <rphillips>all three of us got a credit on that PR :)
20:29:11  <creationix>:)
20:29:44  <rphillips>rje: we will need a make.bat and the buildbots hooked up
20:30:08  <rje>creationix, awesome, nice tracking that down
20:31:07  <rje>rphillips, make.bat?
20:33:12  <rphillips>for the builder https://github.com/virgo-agent-toolkit/rackspace-monitoring-agent-buildbot-builder
20:33:31  <rphillips>we may not need to recompile sigar.dll
20:33:58  <rphillips>or recompile luvi
20:34:12  <creationix>windows is always 64 bit right?
20:34:21  <creationix>their ABI is pretty stable I think
20:34:22  <rphillips>we do have a 32bit version for windows
20:34:41  <creationix>I don’t make 32-bit luvi for windows
20:35:15  <creationix>though it could be added if cross-compiling was just changing the cmake flags
20:35:26  <rphillips>hmm. 32bit version of luvi would have parity
20:35:42  <rphillips>yeah, it's just a tweak to the cmake flag... leave off the 64bit name on the cmake options
20:36:03  <rphillips>-G"Visual Studio 12"
20:36:10  <rje>ic
20:37:41  <rje>yay, ci passed
20:38:01  <rphillips>yeah, my rebase borked it, but I got it fixed
20:38:20  <rphillips>merged
20:38:44  <rje>where does the buildbot call build.sh?
20:39:00  <rje>should we just call that on windows too?
20:39:40  <rphillips>https://github.com/racker/buildbot/blob/master/master_agentbuild_cm/agent2.py#L26
20:40:00  <rphillips>notice, on line 61 the windows builders are commented out
20:41:12  <rphillips>the force version should just work since it is done with cmake
20:41:24  <rphillips>build.bat on windows will need to export the environment variable
20:41:43  <rphillips>export FORCE_VERSION=some_version
20:52:24  <creationix>rphillips: ok, I’ll add a 32-bit version to the publish script for windows
20:53:07  <rphillips>thanks
20:53:09  <creationix>what shall the postfix be? -i686?
20:53:19  <creationix>it’s -amd64 currently
20:53:42  <creationix>which is kinda odd since the posix variants all use underscores
20:53:42  <rphillips>we currently use ia32
20:53:47  <creationix>ia32, perfect
20:59:44  <creationix>rphillips: ok, tiny is done, now building regular https://github.com/luvit/luvi/releases/tag/v2.0.9
21:17:07  <creationix>rphillips: ok, see if the new binaries help https://github.com/luvit/luvi/releases/tag/v2.0.9
21:46:22  <creationix>hmm, fresh provision failed https://gist.github.com/creationix/1c259fc2f3014437eb43#file-up-log-L1432
21:46:28  <creationix>I saw this before but thought it was harmless
21:47:09  * travis-cijoined
21:47:10  <travis-ci>luvit/luvi#540 (master - c97922c : Tim Caswell): The build passed.
21:47:10  <travis-ci>Change view : https://github.com/luvit/luvi/compare/affe225fdb68...c97922c64163
21:47:10  <travis-ci>Build details : http://travis-ci.org/luvit/luvi/builds/64324180
21:47:10  * travis-cipart
22:12:56  <creationix>dinner time. Thanks for helping me find a bug in websocket-codec
22:21:42  <rphillips>glad we got past that
22:21:47  <rphillips>travis ftw
22:35:24  * rjekeeps writing build scripts, we'll get this thing done
23:00:37  <rphillips>thanks!
23:00:44  <rphillips>it's so close
23:15:45  * dan336quit (Quit: Leaving.)