00:13:41  <creationix>no, seems to build fine on appveyor, just not my desktop
00:25:07  * dan3361quit (Quit: Leaving.)
01:02:49  * drorhquit (Remote host closed the connection)
01:07:14  * UniOnquit (Remote host closed the connection)
01:13:55  * forkforkquit (Ping timeout: 246 seconds)
01:17:15  * DarkGodquit (Quit: Leaving)
07:12:54  * ncopajoined
07:13:02  <ncopa>hi
07:13:26  <ncopa>can luvit run with standard Lua? ie without the jit part
08:22:13  * a_lequit
08:23:22  * a_lejoined
10:30:14  * torporjoined
12:59:14  <rphillips>ncopa: luvit master might be able to
12:59:34  <rphillips>luvi-up branch can probably run on straight lua without the openssl binding
12:59:40  <rphillips>out of the box, no
13:00:55  <ncopa>ok, thanks
13:01:11  <ncopa>jit does not play very well with PaX kernel
13:01:59  <rphillips>x86 arch?
13:04:29  <ncopa>on any arch i think
13:07:40  <ncopa>kernel will write protect memory pages with execute permission, and remove execute permissions on memory pages with write access
13:07:49  <ncopa>makes jit unhappy
13:08:53  <ncopa>or jit is actually happy, but kernel gets angry when just in time compiled code is about to execute
13:08:58  <ncopa>and kills the process
14:27:47  * torpor1joined
14:30:09  * torporquit (Ping timeout: 252 seconds)
15:31:56  * dan336joined
15:43:27  * DarkGodWquit (Ping timeout: 265 seconds)
16:03:34  * ncopaquit (Ping timeout: 245 seconds)
16:33:06  <rphillips>creationix: did windows build?
16:37:27  * torpor1quit (Quit: Leaving.)
16:58:31  <creationix>rphillips: still broken on my desktop
16:58:37  <creationix>I think it’s something wrong with my setup
16:58:45  <creationix>luajit complains about missing the jit.* stuff
16:59:23  <creationix>(I did switch windows boxes recently)
17:06:32  * UniOnjoined
17:12:53  * ncopajoined
17:30:20  * dan336quit (Quit: Leaving.)
17:40:35  <creationix>I’m removing all the visual studio versions and installing the new community edition (free pro version for open source)
17:52:50  <rje>creationix, when you run cmake you *should* be able to specify which VS version you want to run
17:53:18  <creationix>true
17:57:48  <creationix>Also I want to try the new community edition in hopes of creating a 64-bit binary
17:57:57  <creationix>are most windows boxes these days 64-bit?
17:58:15  <rphillips>probably a good bet
17:58:52  <rje>creationix, most are. some of the community editions will not build 64 bit though
18:00:10  <rje>creationix, i believe everything run in rackspace for 2014 and forward was 64 bit (there are some legacy cases but hey are rare).
18:00:44  <creationix>good to know
18:01:31  <creationix>btw, did phillips ever try to convince the team to switch to go for the agent? I looked at it over the weekend, it reminds me of a mix of C and lua
18:01:59  <creationix>(not that I’m suggesting such a change, just curious)
18:02:34  <creationix>if we ever do change platforms, it would probably be to something like duktape since it’s the popular JS language, but even lower memory overhead than lua
18:04:02  <rch>go wasn't ready back then
18:04:07  <rch>not even close
18:04:19  <creationix>and I’m not even convinced it’s faster than luajit for a lot of tasks
18:04:29  <creationix>go seems pretty stable these days though
18:26:50  <creationix>hmm, still can’t build with fresh visual studio. Maybe my luvi tree is broken somehow, trying a fresh clone
18:30:28  <rphillips>songgao wrote a golang agent endpoint
18:31:18  <rch>https://github.com/virgo-agent-toolkit/go-agent-endpoint
18:31:21  <rphillips>I like go... it's fast to get stuff working
18:31:41  <rch>he had a demo with a virgo agent connected to his aep and sending metrics which were graphed, end to end local monitoring demo, pretty cool
18:33:56  <rphillips>https://bitbucket.org/kardianos/service/src/fa716ddd1b6e940f25801d8ac9e64e0918d6590e/service_windows.go?at=default
18:34:56  <rphillips>https://github.com/cloudfoundry/gosigar
18:35:22  <creationix>finally figured out my build issue
18:35:38  <rphillips>looks like gosigar is not done
18:35:42  <creationix>when I set LUA_PATH to get luacheck working with luarocks, it broke the luvi build because now luajit can’t find it’s *.jit fiels
18:36:07  <creationix>on the bright side, community edition of VS seems to make 64-bit luajit
18:36:39  <rphillips>nice
18:41:25  <rphillips>creationix: if you could help me get the virgo-base luvi-up branch updated to use lit that would help me out
18:41:38  <creationix>ok, almost done finishing the windows build
18:42:00  <rphillips>sweet...
18:42:16  <rphillips>rje: dlpath in the upgrade.lua file is undefined according to luachheck
18:42:30  <rphillips>it might be that way in master as well
18:47:18  <rje>creationix, great that it does make 64-bit, older verisons didn't :(
18:47:31  <creationix>community is new, it’s different than express
18:47:32  <rje>rphillips, have a link to that line?
18:47:59  <rje>creationix, ah, there in lies the rub
18:48:08  <rphillips>https://github.com/virgo-agent-toolkit/virgo-base-agent/blob/master/client/upgrade.lua#L431
18:48:59  <creationix>alright, windows luvi v0.5.7 building.. Now to grab some lunch before standup and then on to helping rphillips with luvi-up migrations
18:49:22  <rphillips>thanks!
18:51:50  <rje>rphillips, hmmm, looks like item.path might have been a left over artifact. looks unused in the download_iter
18:54:30  * DarkGodjoined
18:59:49  * ncopaquit (Ping timeout: 245 seconds)
19:01:07  * travis-cijoined
19:01:07  <travis-ci>luvit/luvi#236 (master - c46fb02 : Tim Caswell): The build passed.
19:01:07  <travis-ci>Change view : https://github.com/luvit/luvi/compare/6a3272799854...c46fb024a64f
19:01:07  <travis-ci>Build details : http://travis-ci.org/luvit/luvi/builds/46351547
19:01:07  * travis-cipart
19:11:34  <creationix>hmm, appveyor doesn't seem to have VS 2013 https://ci.appveyor.com/project/racker-buildbot/luvi/build/1.0.11/job/pe94gohu4fwrjm3a
19:11:47  <creationix>I wonder if we can make cmake choose 64 bit version if it's there, but not crash if it's not
19:14:13  * ncopajoined
19:16:33  * travis-cijoined
19:16:33  <travis-ci>luvit/luvit#1442 (luvi-up - 5747f6a : Tim Caswell): The build passed.
19:16:33  <travis-ci>Change view : https://github.com/luvit/luvit/compare/e947f35ed603...5747f6ae31fa
19:16:33  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/46353578
19:16:33  * travis-cipart
19:24:49  * ncopaquit (Ping timeout: 245 seconds)
19:26:24  * ncopajoined
19:33:59  * ncopaquit (Ping timeout: 245 seconds)
19:34:29  <rphillips>creationix: we could create a flavor for windows to build 32/64bits
19:34:41  <rphillips>and tell cmake to do that
19:34:55  <rphillips>i almost think just forcing 64bit
19:35:25  <creationix>I just forced 64 bits and it broke appveyor
19:35:32  <creationix>works great on my box though!
19:36:05  <creationix>but I had to hard code vs 2013, which kinda sucks
19:37:26  <creationix>rphillips: so how can I help with luvi-up and lit stuff?
19:37:43  <creationix>the lit bootstrap is somewhat painful because not all the required modules to install are in the core repo
19:37:55  <rphillips>well. if you could help get all the modules setup correctly that would help
19:38:16  <rphillips>we can move modules around if need be
19:38:18  <creationix>I could just commit all the deps into the tree, we just need to remember that that’s not the cannonical source for those projects
19:38:20  <rphillips>or fork them into our repo
19:39:29  <creationix>rphillips: ok, do a `git pull` in lit
19:39:34  <creationix>it should have all it’s deps now
19:40:12  <creationix>ok, now it’s pushed, sorry
19:41:13  <creationix>bte, the “update.sh” script will install a built version of lit to /usr/local/bin/lit
19:41:29  <creationix>it also tries to restart he lit systemd command, but that will simply fail if you have no such service
19:49:29  * ncopajoined
19:53:35  * travis-cijoined
19:53:35  <travis-ci>luvit/luvi#237 (master - e6312b3 : Tim Caswell): The build passed.
19:53:35  <travis-ci>Change view : https://github.com/luvit/luvi/compare/c46fb024a64f...e6312b30e1da
19:53:35  <travis-ci>Build details : http://travis-ci.org/luvit/luvi/builds/46357840
19:53:35  * travis-cipart
19:53:59  * ncopaquit (Ping timeout: 245 seconds)
19:54:43  <creationix>ok, I only force 64 bits in my publish script for luvi-binaries. appveyor will use whatever default cmake picks.
20:04:10  * ncopajoined
20:05:06  <creationix>rphillips: is lit working better for you now?
20:06:15  * rightonb_joined
20:06:31  <rphillips>it is
20:07:16  <rphillips>so virgo-base uses, async, hsm, request, and split-stream
20:07:23  <rphillips>luvit modules
20:07:45  <creationix>ok, and you want to publish those to lit.luvit.io?
20:08:10  <rphillips>right
20:08:54  <creationix>are you still at the office and can't talk on port 4821?
20:16:52  * rightonb_part
21:07:21  <bjorn>creationix: Do you already have luacheck working on Windows? I installed it with LuaRocks today. It felt a little involved but it worked.
21:07:31  <creationix>yep, I got it working
21:07:49  <rch>heh http://lit.luvit.io/
21:07:50  <creationix>also got the sublime plugin patched to support windows
21:08:06  <bjorn>Ok it just worked for me. Maybe it already included your patch?
21:08:07  <creationix>rch: todo: write web frontend to lit
21:08:11  <rch>heh
21:08:33  <creationix>bjorn: the sublime patch is upstream. I think my luarocks issue was I installed it incorrectly
21:09:10  <creationix>rch: the cli tool uses port 4821
21:09:12  <bjorn>I just used the batch file and had it use the shipped Lua, cause it didn't want to find the Lua exeecutable it located for whatever reason.
21:09:17  <creationix>so the domain doesn’t actually matter at the moment
21:09:33  <rch>right i figured
21:09:35  <creationix>yep, using the shipped lua was the key to making it work
21:09:59  <bjorn>I found luacheck especially useful for seeing unused required modules, but it also showed me some dead code already.
21:10:06  <creationix>yep
21:12:08  * a_lequit (Remote host closed the connection)
21:12:46  * a_lejoined
21:20:28  * dan336joined
21:47:59  * phorejoined
21:52:34  * phorequit (Read error: Connection reset by peer)
22:21:30  <rphillips>luacheck++
22:23:55  <creationix>alright, found one of my issues that silently ate errors
22:24:12  <creationix>coroutine.wrap(xpcall)(fn, debug.traceback) doesn’t work like I thought it did
22:24:30  <creationix>it only catches errors in the first tick, after that it silently does nothing
22:25:12  <creationix>this works much better https://github.com/luvit/lit/commit/fa8368ef21c1896dd4d533eaad2442ec2d46e70e
22:27:50  <rphillips>interesting
22:29:52  <creationix>which makes sense, I just hadn’t thought it through properly
22:30:03  <creationix>coroutine.wrap returns a function that only returns the first yield
22:30:25  <creationix>so if you yield before throwing, it never gets the exception that happens later on
22:30:34  <creationix>but xpcall on the inside, waits till the coroutine is done
22:46:38  <rphillips>creationix: looks like the luvit project needs the appveyor plugin
22:46:55  <rphillips>the PR is only building on travis
22:47:46  <creationix>I’m not sure what the issue is
22:47:49  <creationix>the hook is setup
22:48:15  <rphillips>perhaps it's a github-ism then
22:49:51  <creationix>you can force a new build from the appveyor ui
22:49:57  <creationix>I did that to test a luv build
22:50:39  * travis-cijoined
22:50:39  <travis-ci>luvit/luvit#1444 (luvi-up - d09fda4 : Ryan Phillips): The build passed.
22:50:39  <travis-ci>Change view : https://github.com/luvit/luvit/compare/5747f6ae31fa...d09fda49fd29
22:50:39  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/46380871
22:50:39  * travis-cipart