00:14:15  * quakephil_joined
00:14:29  * quakephilquit (Ping timeout: 264 seconds)
01:10:07  * dg__quit (Ping timeout: 250 seconds)
01:19:33  * hdmsquit (Quit: hdms)
01:38:05  * hdmsjoined
01:46:44  * hdmsquit (Quit: hdms)
01:48:53  * hdmsjoined
02:06:21  * hdmsquit (Quit: hdms)
02:45:14  * hdmsjoined
02:46:48  * hdmsquit (Read error: Connection reset by peer)
02:50:57  * hdmsjoined
02:59:35  * hdmsquit (Quit: hdms)
03:15:46  * hdmsjoined
03:23:43  * dan336joined
03:39:48  * dan336quit (Quit: Leaving.)
03:44:39  * hdmsquit (Quit: hdms)
03:45:18  * hdmsjoined
03:57:41  * dan336joined
04:21:08  * hdmsquit (Quit: hdms)
04:36:39  * dan336quit (Quit: Leaving.)
05:46:54  * SkyRocknRolljoined
06:31:25  * torporjoined
07:07:22  * SkyRocknRoll_joined
07:07:23  * SkyRocknRoll_quit (Client Quit)
07:24:04  * dg__joined
09:00:34  * SkyRocknRollquit (Ping timeout: 255 seconds)
09:17:11  * SkyRocknRolljoined
10:23:05  * dg__quit (Ping timeout: 256 seconds)
10:52:15  * torporquit (Quit: Leaving.)
11:46:42  * hdmsjoined
12:09:00  <rphillips>good morning
13:01:56  * cptGjoined
13:03:23  * dg__joined
13:03:37  <cptG>hey there! I'm having problems with weblit-websocket and could not find anything in the sources... If I send frames that are large enough, my connection errors out with "invalid frame header" in chrome. The websocket frame view in chrome's devtools shows an opcode of -1 - does anyone have an idea?
13:06:23  <rphillips>cptG: Tim did a fix yesterday or the day before, have you picked up that change?
13:07:09  <rphillips>this commit: https://github.com/luvit/lit/commit/4cffee03d2388161f6202ee20c7f265b2701d668
13:19:25  <cptG>rphillips: hm. My frames succeed until a size of 15, everyting above fails so this commit seems unrelated to my problem. Just to be sure: I'm sending {opcode = 1; payload = mystring; len = mystring:len()} - correct?
13:19:53  * torporjoined
13:20:20  <rphillips>hmm. he should be here shortly
13:20:32  <cptG>I'll stick around :)
13:27:41  <cptG>rphillips: huh. It seems like it was a bug in my version of weblit - an update fixed it :)
13:27:51  <rphillips>sweet!
13:28:29  <cptG>this is my first project with luvit so I still need some getting used to lit & luvit ;)
13:28:44  <rphillips>give us feedback... we want to make it better
13:33:07  <cptG>so far it's great. I absolutely love the simple install. I've been developing a C++11-binding lib for luajit and I love that I can use that in my server code, as well. I guess I'll hit some problems later on in my project but I just saw that there's a google group for discussions so I'll head there for feedback :)
13:41:35  <rphillips>awesome!
13:57:16  * SkyRocknRollquit (Ping timeout: 265 seconds)
14:10:03  * SkyRocknRolljoined
14:18:01  * SkyRocknRollquit (Remote host closed the connection)
14:23:55  <cptG>hum. Quick question for ideas: I can't write to a websocket from within a callback (e.g. setTimeout) is there a way around that? I tried polling in process.nextTick but that yields the same error :(
14:33:41  * dan336joined
15:38:45  * gavellanedajoined
15:39:08  <gavellaneda>good morning
15:40:43  <gavellaneda>how are you rphillips, creationix?
15:41:14  <rphillips>doing good, and you?
15:41:36  <gavellaneda>good too, I've moved to Argentina
15:41:44  <rphillips>wow. nice
15:42:12  <gavellaneda>I've traveled by car from Brazil, a long trip :)
15:43:24  <gavellaneda>ryan, I need some help from you :)
15:44:15  <gavellaneda>I've published a code were luvit does not flush the output buffers on process exit
15:44:24  <gavellaneda>don't know if you have a solution for this
15:44:25  <gavellaneda>https://gist.githubusercontent.com/GabrielNicolasAvellaneda/4a1ed23379070a8671e2/raw/20508c487f47e17670157b1c181366b934417341/gistfile1.luawww.mirc.co.uk/register.html
15:44:53  <gavellaneda>ups
15:44:55  <gavellaneda>https://gist.githubusercontent.com/GabrielNicolasAvellaneda/4a1ed23379070a8671e2/raw/20508c487f47e17670157b1c181366b934417341
15:46:41  <rphillips>yeah, i hit this the other day, it's a bug
15:46:50  <gavellaneda>good to know
15:47:08  <rphillips>you can try putting the process:exit on the nexttick
15:47:09  <gavellaneda>I saw someone reporting a similar problem with nodejs
15:48:00  <rphillips>it's due to us calling os.exit() here... we don't close all the libuv handles
15:48:01  <creationix>cptG: still around?
15:48:02  <rphillips>https://github.com/luvit/luvit/blob/master/deps/process.lua#L113
15:48:07  <cptG>creationix: yep
15:48:31  <creationix>sorry for the websocket bugs. I made a lot of fixes recently
15:48:40  <rphillips>we could wait for the .end event on process.stdout/stderr
15:48:41  <gavellaneda>rphillips, perfect
15:49:18  <cptG>creationix: no worries :)
15:49:22  <gavellaneda>rphillips, so to be in the next tick, put the on('exit') inside the on('data')?
15:49:39  <creationix>cptG: are you still having trouble writing in a callback?
15:49:56  <rphillips>timer.nextTick(function() process:exit() end)
15:50:02  <rphillips>it's lame
15:50:05  <rphillips>but might work
15:50:18  <creationix>cptG: also are you using coroutine style or callback style? Mixing them is hard to get right
15:50:18  <cptG>creationix: yes, I've not had any success so far - atm I'm looking into using raw tcp sockets as a replacement :/
15:50:40  <creationix>I've only used websockets with coroutine based code so far
15:50:45  <cptG>creationix: didn't know there's a callback style for websockets - I'm using "for foo in read"
15:50:47  <gavellaneda>rphillips, thanks, I will try this
15:51:05  <creationix>cptG: right, if you want to use the read,write interface, you need to make sure you're always in a coroutine
15:51:24  <rphillips>gavellaneda: i'll looking fixing it this week or next, unless you get to it
15:51:27  <creationix>raw luv callbacks aren't in coroutines, they are fresh stacks
15:51:29  <rphillips>into fixing*
15:51:53  <creationix>when you must run code from a callback, wrap it in coroutine.wrap(function () ... end)()
15:52:05  <creationix>but more often the correct thing is to convert the callback into a coroutine interface
15:52:11  <creationix>what are you doing that needs a callback?
15:52:22  <cptG>creationix: I'm launching a childprocess
15:52:46  <cptG>creationix: the callbacks are child.stdout('data') and the like
15:54:46  <cptG>so... how I could use req.on('message', ...) in my call to weblit.websocket OR wrap the code of my callback in couroutine.wrap OR rewrite my callbacks with coroutines, right?
15:56:11  <creationix>cptG: so stdout is a luv stream under the hood
15:56:34  <creationix>personally I'd use luv's spawn directly instead of the luvit one and wrap the luv stream as a coroutine stream
15:56:55  <creationix>like I said, mixing the two approaches gets messy real quick
15:57:23  <creationix>cptG: this is what I use to get read,write out of a uv_stream_t https://github.com/luvit/lit/blob/master/deps/coro-channel.lua#L10-L69
15:58:14  <rphillips>i think this does exactly what you want: https://github.com/luvit/lit/blob/a8b3418ee78d64dd0c5abad3bc971a5a7d2db2aa/libs/exec.lua
15:58:23  <cptG>creationix: sweet, thanks!
15:58:58  <creationix>of that if you just want to read all the output
15:59:38  <cptG>ah yes, that's enough for now but the wrap-approach I'll keep in the back of my head for later
15:59:40  <cptG>thanks a lot!
16:00:06  <creationix>I could write a quick coro-spawn library that returns stdout, stderr, and stdin as read/write functions
16:00:27  <cptG>creationix: I've opened an issue in weblit about it - should I close it or do you want to reply for documentation's sake?
16:00:29  <creationix>but the exec helper is much simpler if you just want to buffer output
16:00:46  <cptG>creationix: such a library sounds useful
16:01:14  <creationix>yep, I'm just making coro-* libraries as I need them. Basically mirroring most the libraries in the luvit metapackage
16:01:52  <creationix>cptG: what's your use case? Do you want to stream the stdio of the child or just buffer and get the whole result?
16:02:14  <cptG>I think it'd be nice to document this "limitation" for users like me that naively assume callbacks are fine in any place. Or maybe somehow catch the error in luvit/luv and report it more verbosely?
16:02:24  <cptG>creationix: straming would be nice, it's a long-running build process
16:02:45  <cptG>creationix: which, now that I'm writing it, sounds like the wrap-approach would be best for me I guess
16:03:06  <creationix>so the only tricky part is what to do with the exit event
16:04:01  <creationix>it's a one-time thing, so normally I'd do a blocking coroutine API, but if you're also streaming stdio, you don't want to block on exit
16:04:17  <creationix>I guess we just need an easy way to split coroutines into two parallel tasks
16:04:50  <cptG>creationix: hum. I could wrap the invokation of "make" and print a magic string to stderr on exit if it's not solvable in the server code, it's a hack but it would probably work in 99.99% of my cases ;)
16:04:52  <gavellaneda>thanks rphillips, the nextTick seems to work (I'm testing with luvit 0.10.0... we are in the process of migrating to latest luvit.. but... the process seems slow)
16:04:54  <creationix>callbacks are concurrent by default, but coro style is all serial
16:05:41  <rphillips>serial-looking*
16:06:01  <creationix>well yeah, it's all non-blocking at the process level, but it's blocking at the program logic level
16:06:36  <creationix>callback code has helper libraries (like async) that help do things in serial, maybe we should make a library for coroutines to help doing things in parallel
16:06:58  <creationix>much like spawning a few goroutines
16:07:00  <rphillips>+1. I was thinking the same thing
16:07:07  <cptG>which is nice, I much prefer it to callbacks. Looks cleaner.
16:07:30  <creationix>same here. The language I'm designing has this I/O model baked in
16:07:45  <creationix>with keywords for splitting into two parallel tasks (each with blocking calls)
16:07:58  <creationix>but we can get pretty close with a little library in lua
16:09:59  <creationix>cptG: ok, I'll make coro-spawn with read/write style stdio and a blocking function to wait for exit
16:10:06  <cptG>sounds interesting
16:10:28  <cptG>creationix: nice, looking forward to it :)
16:10:40  <creationix>hmm, actually, in all cases you'd use the blocking exit in a parallel green-thread
16:11:02  <creationix>either way, the read/write style stdio will be nice
16:12:08  <gavellaneda>+1 guys you are always talking about very interesting stuff, would like to work on that ideas
16:14:01  <creationix>I should write a blog post about the coro style some day on luvit.io
16:15:09  <gavellaneda>creationix, would be great
16:29:49  * torporquit (Quit: Leaving.)
16:30:43  <gavellaneda>rphillips, the nextTick reduced the number of buffers that were not flushed but if you have various process running in parallel, the problem still occurs.
16:37:23  <rphillips>yeah... i'll try and get a fix in
16:43:23  <gavellaneda>ok, thanks
16:51:01  <creationix>hmm, so child processes have 5 different event sources (stdout data/end, stderr data/end, process-exit)
16:51:14  <creationix>I wonder if a uniform event stream would make sense
17:00:46  <creationix>nah, I'll just add the parallel helper and it will be pretty easy to use
17:01:27  <cptG>hrm... luvit segfaults in test-process.lua
17:02:03  <cptG>It also segfaults if I try to uv.spawn a command with my own std{io,out} pipes... can someone confirm?
17:02:42  <cptG>:q!
17:07:33  <rje>rphillips, is all this fetid and rotting? https://github.com/virgo-agent-toolkit/rackspace-monitoring-agent/blob/luvi-up/tests/helper.lua
17:09:56  <rphillips>Yep. Helper is old. Could be removed
17:16:25  <creationix>cptG: ok, done with coro-spawn and coro-split
17:16:27  <creationix>https://github.com/luvit/lit/commit/b93fcfb483c4d50ca03812a19246c94961aab127
17:16:54  <creationix>you can see usage in the newly modified exec.lua helper https://github.com/luvit/lit/blob/master/libs/exec.lua
17:19:04  <creationix>actually I'm going to change it a bit. The logic for specifying which pipes to create is wrong
17:21:13  <creationix>ok, now it's good https://github.com/luvit/lit/blob/master/libs/exec.lua
17:26:14  <creationix>rphillips: how do you like the new exec.lua helper (showing off the new coro-spawn and coro-split libraries)
17:26:38  <creationix>hmm, I left debug prints in there
17:28:27  <creationix>waiting on all three is much easier this way than using events
17:28:41  <creationix>the exit event often comes before the end event for both the output streams. Just a strange part of unix
17:29:01  <creationix>in node and luvit, you had to make sure to wait till both the exit had fired and both end events fired
17:29:13  <creationix>which split it's implicit that you want to wait for everything and order doesn't matter
17:30:45  <creationix>*with split
17:44:27  * hdmsquit (Quit: hdms)
17:46:35  <rphillips>creationix: wow. that is nice!
18:24:17  * gavellanedaquit
18:28:58  <rphillips>gavellaneda left :/
18:28:59  <rphillips>https://github.com/luvit/luvit/pull/753
18:30:26  * travis-cijoined
18:30:27  <travis-ci>luvit/luvit#2246 (fixes/flush_stdout_on_exit - 6ffd025 : Ryan Phillips): The build passed.
18:30:27  <travis-ci>Change view : https://github.com/luvit/luvit/commit/6ffd025a7eee
18:30:27  <travis-ci>Build details : https://travis-ci.org/luvit/luvit/builds/68202861
18:30:27  * travis-cipart
19:08:02  <dan336>just an FYI i opened 3 pull requests for the lit project to fix some of the deps.
19:21:14  <rphillips>nice. thanks!
19:37:12  <cptG>creationix: I just tried it and it works like a charm, thanks a lot!
19:43:26  <creationix>awesome
19:48:26  <cptG>creationix: fyi: I'm still seeing the illegal frame header problem on my armv7 machine :(
19:48:47  <cptG>but just to be sure: the update procedure is "lit sync" and "lit update" right?
19:49:29  <cptG>nah. pebcak
19:49:35  <cptG>did not update correctly :)
20:16:23  * cptGquit (Quit: Konversation terminated!)
20:18:26  * hdmsjoined
20:33:47  * hdmsquit (Quit: hdms)
20:54:36  * travis-cijoined
20:54:37  <travis-ci>luvit/luvi#558 (release - 6aad454 : Ryan Phillips): The build has errored.
20:54:37  <travis-ci>Change view : https://github.com/luvit/luvi/compare/affe225fdb68...6aad4548657f
20:54:37  <travis-ci>Build details : https://travis-ci.org/luvit/luvi/builds/68222036
20:54:37  * travis-cipart
21:04:25  <rphillips>updated the release branch on luvi
21:04:45  <rphillips>it builds now.. i don't think travis picked it up
21:05:28  <creationix>oops, sorry for forgetting to move release
21:05:51  <creationix>cptG is now gone, but I think there is confusion about what `lit sync` and `lit update` do
21:06:04  <creationix>there is no command to update deps in the local folder
21:06:15  <creationix>rm -rf deps && lit install works great though
21:06:30  <creationix>should be make a command to update local deps?
21:07:20  <creationix>now that we differentiate between deps and libs, deps can be used exclusively for external packages
21:07:22  <rphillips>creationix: https://xkcd.com/1537/
21:07:44  <creationix>yeah, saw that. Even better than JS :)
21:11:15  <rphillips>:)
21:13:15  <rphillips>lit install doesn't update local deps?
21:19:22  <creationix>nope
21:19:36  <creationix>lit install only installs missing deps. It leaves whatever you have locally alone
21:19:56  <creationix>but if you do `lit install foo/bar` it will install over whatever might be there
21:28:42  <rje>creationix, is there a way to get a better error here as to why the compile failed? https://ci.appveyor.com/project/racker-buildbot/rackspace-monitoring-agent/build/1.0.393#L849
21:30:20  <creationix>rje: did lit crash?
21:30:54  <creationix>I don't think I exit -1 anywhere without first showing the reason, it must be a segfault or something
21:32:43  <rje>creationix, pm
21:38:14  <creationix>rje: that's strange. I can't find that line in core.lua. I wonder what version of lit that is
21:38:22  <creationix>the line I thought it was is at https://github.com/luvit/lit/blob/master/libs/export-zip.lua#L45
21:38:51  <rje>lit 2.0.4
21:40:43  <creationix>2.0.4 should have export-zip, it's new enough
21:40:55  <creationix>there is no dump anywhere in core.lua in 2.0.4
21:41:52  <creationix>core.lua line 421 is unrelated https://github.com/luvit/lit/blob/467ff55615d61f7dbde82a5ef28b0630f8dc1b57/libs/core.lua#L431
21:45:36  <creationix>It looks like you have a much older version of core.lua somehow https://github.com/luvit/lit/blob/a3312562e0557e18faff122db490880a2eb93ebf/libs/core.lua#L433
21:45:54  <creationix>this line would show the behavior you're seeing. It's already fixed in the latest version
21:46:39  <creationix>rje: if you can, try updating to a later version of lit
21:46:55  <creationix>current is 2.0.10-1
21:47:46  <rphillips>the tag for the Make.bat would be 2.0.10 though
21:49:12  <rje>bumping it gives the error
21:52:30  <rje>thank you
21:52:35  <rje>missing comma
21:54:26  <creationix>oh, by "gives the error" you mean it gave a proper error message
21:56:09  <rje>yes, have error message, can fix
21:56:54  <rphillips>happens on my box as well
21:57:23  <rphillips>ah, error in the test file, nm
21:57:50  <rphillips>i think cmake is eating that error message
22:00:40  <creationix>btw, should lit allow .lua files containing syntax errors? Currently it hard-errors, but I could change it to include the file uncompiled with a warning message.
22:00:52  <creationix>But I fear that message won't be seen and the error will be found much later
22:02:29  <rphillips>yeah, I think the current behavior is good
22:02:34  <rphillips>fail early
22:03:11  <creationix>if you do want to include a file with invalid lua, you'll just have to change the extension. That shouldn't be a problem I hope
22:04:28  <rphillips>creationix: so, you think the emit('exit'... should be right before the os.exit?
22:04:45  <creationix>right. I don't want things to work sometimes
22:04:53  <rphillips>got it... I'll buy that
22:05:22  <creationix>and if the exit handler wanted to do async work, all it has to do is call uv.run()
22:05:51  <creationix>probably should close all existing handles at that point though
22:05:58  <creationix>or maybe we could do that in the exit handler
22:06:38  <creationix>uv.walk(function (handle) if not handle:is_closing() then handle:close() end) uv.run()
22:06:53  <creationix>then call the exit handler and they'll have an empty loop
22:06:58  <creationix>may be too much though
22:09:30  * travis-cijoined
22:09:31  <travis-ci>luvit/luvit#2248 (fixes/flush_stdout_on_exit - 80cc0aa : Ryan Phillips): The build passed.
22:09:31  <travis-ci>Change view : https://github.com/luvit/luvit/compare/6ffd025a7eee...80cc0aaaea18
22:09:31  <travis-ci>Build details : https://travis-ci.org/luvit/luvit/builds/68234988
22:09:31  * travis-cipart
22:12:16  <dan336>so here is something I just tracked down. I'm using coro-http.request to make a lot of requests to a web server and it will suddenly stop without throwing an error or anything. I traced it down to a missing assert around the connect in coro-tcp, it was erroring out with EMFILE.
22:12:51  <dan336>however that still doesn't solve the issue of why coro-http isn't correctly reusing connections. and not closing down ones that can't be reused.
22:16:27  <creationix>dan336: are the connections to the same host?
22:16:41  <creationix>I thought I implemented in connection pooling
22:16:43  <dan336>they are. and only 1 is in use at a time.
22:16:52  <creationix>so it should be pooling them
22:17:04  <dan336>you did, but its not working because of what socket:is_active() is returning.
22:17:19  <dan336>and I'm not sure why it is returning false.
22:18:32  <rphillips>linux?
22:18:38  <rphillips>lsof on the process would be helpful
22:18:38  <dan336>osx
22:18:43  <creationix>uv_is_active is always a strange one
22:18:51  <dan336>yeah I was reading the docs on it http://docs.libuv.org/en/latest/handle.html#c.uv_is_active
22:19:23  <creationix>" is active when it is doing something that involves i/o, like reading, writing, connecting, accepting new connections, etc."
22:19:36  <dan336>I was curious if the socket was being paused by the coro-wrapper, so I put some prints in there, but i only say it being unpaused once.
22:19:37  <rphillips>rje: hey, it passed!
22:19:52  <dan336>*saw
22:19:55  <rje>rphillips, that's just with the fixtures
22:20:10  * travis-cijoined
22:20:11  <travis-ci>luvit/luvit#2250 (master - e9f7522 : Ryan Phillips): The build passed.
22:20:11  <travis-ci>Change view : https://github.com/luvit/luvit/compare/a8c8139f30b7...e9f7522d1f3c
22:20:11  <travis-ci>Build details : https://travis-ci.org/luvit/luvit/builds/68236265
22:20:11  * travis-cipart
22:20:31  <dan336>sorry I was looking at the coro-channel module, not coro-wrapper
22:20:35  <creationix>dan336: does it work if you remove the is_active constraint?
22:21:09  <dan336>thats the thing, it segfaults when I remove it. so it should be there.
22:21:29  <creationix>segfaults is not a good sign, that shouldn't be possible from lua
22:22:47  <creationix>if an idle socket doesn't count as active, then we should remove that constraint. I don't remember why I added it
22:23:09  <creationix>dan336: do you have a minimal test case using some public HTTP API?
22:23:41  <dan336>not yet, I was testing out something I was developing. I can create one.
22:24:29  <creationix>hmm, it looks like a paused socket will show as inactive
22:24:44  <creationix>(according to the "Rule of thumb")
22:27:35  <creationix>dan336: btw, you missed a hex-bin in the git submodule
22:28:16  <creationix>and I don't have it as a dependency either, my bad.
22:30:20  <creationix>ok, fixed it
22:32:40  <dan336>oh sorry, I just searched in lit and updated what I could find.
22:36:57  <creationix>no worries
22:37:09  <creationix>I can't reproduce the segfault, if I remove is_active, it reuses the connection just fine
22:38:33  <rphillips>dan336: double check that your ulimit for files is set to a reasonable amount
22:39:20  <creationix>I might be leaking connections
22:39:36  <creationix>looking through the code, I don't have any sort of timeout to close sockets
22:39:41  <dan336>its set to 256, however there should only be 1 connection at a time because of how the app is structured.
22:39:50  <creationix>they only close when the coro-channel abstraction tells them to
22:39:58  <dan336>actually 2 at a time.
22:40:29  <creationix>dan336: I've got to go soon, but I'm interested in this segfault. I'm pretty sure the is_active needs to go away
22:40:50  <creationix>I vaguely remember thinking is_active was true for as long as the tcp connection was value, but now I see that's not true
22:41:06  <dan336>creationix: I think so too, I'll try to get a small test up. right now its just not working :)
22:41:18  <creationix>it will be false for any paused socket and possible even for unpaused, but idle connections
22:42:51  <creationix>dan336: ok, I published updated coro-http and websocket-codec packages to lit. Try with the latest versions.
22:43:03  <creationix>see you all later
22:52:49  <rphillips>take care
22:52:51  <rphillips>https://github.com/luvit/luvit/pull/754
22:55:19  * dan336quit (Quit: Leaving.)
22:55:35  * travis-cijoined
22:55:36  <travis-ci>luvit/luvit#2251 (fixes/stdout_stderr_exit - eeee695 : Ryan Phillips): The build passed.
22:55:36  <travis-ci>Change view : https://github.com/luvit/luvit/commit/eeee695e5c27
22:55:36  <travis-ci>Build details : https://travis-ci.org/luvit/luvit/builds/68240841
22:55:36  * travis-cipart
22:57:15  * dan336joined
23:00:11  * dan336quit (Client Quit)
23:06:39  * travis-cijoined
23:06:40  <travis-ci>luvit/luvit#2253 (fixes/stdout_stderr_exit - 3223caf : Ryan Phillips): The build passed.
23:06:40  <travis-ci>Change view : https://github.com/luvit/luvit/compare/eeee695e5c27...3223cafe443b
23:06:40  <travis-ci>Build details : https://travis-ci.org/luvit/luvit/builds/68242416
23:06:40  * travis-cipart
23:21:48  * travis-cijoined
23:21:49  <travis-ci>luvit/luvit#2255 (master - 86f3744 : Ryan Phillips): The build passed.
23:21:49  <travis-ci>Change view : https://github.com/luvit/luvit/compare/e9f7522d1f3c...86f37445e03e
23:21:49  <travis-ci>Build details : https://travis-ci.org/luvit/luvit/builds/68243746
23:21:49  * travis-cipart
23:30:25  * dan336joined
23:31:06  * dan336quit (Client Quit)