00:15:47  * travis-cijoined
00:15:48  <travis-ci>luvit/luvi#522 (release - 0e1c984 : Tim Caswell): The build passed.
00:15:48  <travis-ci>Change view : https://github.com/luvit/luvi/compare/fa60e81ac815...0e1c98459bac
00:15:48  <travis-ci>Build details : http://travis-ci.org/luvit/luvi/builds/62144423
00:15:48  * travis-cipart
00:42:56  * travis-cijoined
00:42:57  <travis-ci>luvit/luvi#521 (v2.0.6 - 0e1c984 : Tim Caswell): The build passed.
00:42:57  <travis-ci>Change view : https://github.com/luvit/luvi/compare/v2.0.6
00:42:57  <travis-ci>Build details : http://travis-ci.org/luvit/luvi/builds/62141348
00:42:57  * travis-cipart
00:57:15  * kazuponjoined
02:04:21  <rphillips>i think minimizing the lua files would lower the memory usage as well
02:04:47  <rphillips>a gcore on a running agent does have some remnants of the source
02:05:01  <rphillips>not sure if that is active memory or just stale
02:05:54  <rphillips>looks like it's active... hmm
02:06:36  <rphillips>perhaps the require module is caching the raw file, and not the bytecode
02:07:44  <rphillips>hmm yeah, readFile has a fileCache
02:12:18  * kazuponquit (Remote host closed the connection)
02:12:34  * hdms_joined
02:12:45  * kazuponjoined
02:13:31  * hdmsquit (Ping timeout: 250 seconds)
02:13:31  * hdms_changed nick to hdms
02:13:41  * hdmsquit (Client Quit)
02:19:50  * kazuponquit (Remote host closed the connection)
02:19:58  * kazuponjoined
02:22:38  <rphillips>hmm. that cache is just true/false
02:41:21  * DarkGodquit (Ping timeout: 276 seconds)
03:18:25  * grep_awayquit (Ping timeout: 264 seconds)
03:19:14  * grep_awayjoined
03:27:14  * kazuponquit (Remote host closed the connection)
04:20:53  * kazuponjoined
05:20:38  * kazuponquit (Remote host closed the connection)
05:21:06  * kazuponjoined
05:31:01  * SouL_|_quit (Ping timeout: 256 seconds)
05:46:41  * SkyRocknRolljoined
05:46:41  * SkyRocknRollquit (Changing host)
05:46:41  * SkyRocknRolljoined
05:49:51  * torporjoined
06:06:28  * torporquit (Quit: Leaving.)
06:13:13  * SouL_|_joined
07:31:29  * DarkGodjoined
08:43:25  * kazuponquit (Remote host closed the connection)
08:43:32  * kazuponjoined
09:42:09  * Akagi201joined
09:45:48  * kazuponquit (Remote host closed the connection)
09:46:16  * kazuponjoined
10:49:54  * kazuponquit (Ping timeout: 244 seconds)
11:19:09  * Akagi201quit
11:35:48  * SouL_|_quit (Ping timeout: 256 seconds)
11:42:18  * torporjoined
11:51:00  * torporquit (Quit: Leaving.)
11:56:49  * torporjoined
12:10:44  <rphillips>good morning
12:15:33  * torporquit (Quit: Leaving.)
12:16:47  * torporjoined
12:20:09  * SkyRocknRollquit (Remote host closed the connection)
13:11:53  * torporquit (Quit: Leaving.)
13:14:20  * torporjoined
13:47:21  * Akagi201joined
13:56:17  * Akagi201quit (Remote host closed the connection)
13:58:05  * Akagi201joined
14:18:47  <creationix>mornin'
14:28:58  * StepetSjoined
14:30:40  <StepetS>Hello, is there anybody who knows how build luvit-redis(https://github.com/tadeuszwojcik/luvit-redis)?
14:30:57  <creationix>rphillips: I was reading on the elua lists and learned that compiled programs save memory
14:31:11  <creationix>I guess in that case, it can skip loading the program to ram
14:31:32  <creationix>the bytecode is almost always larger than the lua code (unless it's heavily commented)
14:31:36  <rphillips>when i took the core yesterday, there are caches of the data somewhere
14:31:49  <rphillips>the contents of the files
14:32:20  <creationix>the lua code? And it was in plaintext, not gzipped right?
14:32:28  <rphillips>right, plaintext
14:32:31  <creationix>(because it should be deflated in the zip file)
14:32:59  <creationix>rphillips: were you running from a zip bundle or off disk?
14:33:18  <rphillips>from the zip bundle
14:34:03  <creationix>hmm, not much in the luvi side then https://github.com/luvit/luvi/blob/master/src/lua/init.lua#L255-L257
14:34:15  <creationix>and require calls bundle.readfile directly I'm pretty sure
14:34:22  <creationix>(luvit/require that is)
14:35:06  <creationix>you can look at the zip to make sure the lua files are compressed, but they should be
14:35:44  <creationix>unzip -l might even tell you
14:37:17  <creationix>hmm, that shows the uncompressed sizes
14:37:34  <creationix>but luvit's binary is ~500mb lua, but the zip file is only 250kb
14:37:41  <creationix>so it must be compressing
14:40:15  <creationix>rphillips: oh interesting, I cache a boolean in the fileCache. That could be a problem for Module:load if you try to load a file you've already loaded before.
14:40:43  <rphillips>hmm
14:41:15  <creationix>maybe luajit is caching the source lua?
14:41:36  <rphillips>certainly possible
14:41:45  <rphillips>i saw all the root CA certificates
14:41:54  <rphillips>i added a _root_ca.roots = nil after the load
14:42:05  <rphillips>it does help a tad, but doesn't seem too significant
14:42:28  <creationix>https://github.com/luvit/luvit/bhttps://github.com/luvit/luvit/blob/master/deps/require.lua#L66lob/master/deps/require.lua#L266
14:43:10  <rphillips>trying logging into root@
14:43:16  <rphillips>i put one of your ssh keys on there
14:43:30  <rphillips>home has a core file
14:45:01  * creationixhas too many machines
14:49:34  <creationix>rphillips: what's a good way to look through core dumps?
14:50:13  * StepetSquit (Quit: Leaving.)
14:50:24  <rphillips>vim+xxd
14:50:32  <rphillips>or just scrolling through the text
14:50:39  <rphillips>or strings
14:51:07  <creationix>yeah, tried strings, it's not installed
14:51:28  <creationix>though hexdump -C | grep exports found some good offsets
14:51:57  <rphillips>installed strings, it's in the binutils packages
14:54:09  <rphillips>it doesn't look like all the lua files are in memory
14:54:21  <rphillips>perhaps that is a luajit thing
14:54:33  * hdmsjoined
14:54:54  <creationix>yeah, I see the certs
14:57:11  <creationix>rphillips: there are other ways to load the module with less debug info
14:58:13  <creationix>maybe use loadstring(string.dump(loadstring(code), true),filename)?
14:58:29  <creationix>string.dump(fn, true) is a luajit extension to strip out debug information and make portable bytecode
14:58:54  <creationix>then loadstring has less to cache perhaps?
14:59:18  <creationix>another idea is to just not pass in filename to loadstring, that may disable debug data entirely, but stack traces will be hard
15:00:38  <creationix>yeah, I'll bet it's the debug info, the main difference between debug bytecode and raw bytecode is a copy of the source code
15:00:51  <creationix>try string.dump(loadstring("return a - b")) in a luvit repl
15:01:00  <creationix>compare with string.dump(loadstring("return a - b"), true)
15:01:08  <rphillips>k
15:01:50  <rphillips>ah hah
15:02:18  <creationix>so with double loadstring with a stripping compile in the middle should preserve filename, but dump the source code
15:02:28  <creationix>our files are small enough, that should make debugging sane
15:03:37  <rphillips>i don't want to lose debuggability, but I think it's worth trying to see if it's significant
15:05:54  <creationix>I'm testing with some larger files, not sure this is the case
15:06:08  <creationix>if you give it a filename in the inner loadstring, it doesn't store the source
15:06:16  <creationix>I think it was just using the first line as the filename
15:07:04  <creationix>so main.lua in luvit is 2843 bytes of bytecode with debug info
15:07:11  <creationix>and 2208 without
15:09:05  * torporpart
15:09:45  <rphillips>i wonder if it makes sense to add a 'compiled' attribute to the package.lua
15:10:01  <rphillips>and the compressor can string.dump the file right before adding to the zip
15:10:33  <creationix>in nodemcu they have a .rc extension for compiled files
15:10:42  <creationix>we could add that to the require path loader
15:10:49  <creationix>loadstring accepts either bytecode or lua code
15:10:51  <rphillips>oh slick
15:11:19  <creationix>it will bloat the binary size a bit, bytecode is larger and doesn't compress as well as lua ascii
15:11:46  <creationix>though the difference is less once both are deflated
15:13:06  <creationix>rphillips: https://github.com/luvit/luvit/compare/small
15:13:19  <creationix>you can try this in your deps/require.lua and see if it makes a difference
15:13:36  * travis-cijoined
15:13:37  <travis-ci>luvit/luvit#2143 (small - 48a8bab : Tim Caswell): The build passed.
15:13:37  <travis-ci>Change view : https://github.com/luvit/luvit/compare/small
15:13:37  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/62252677
15:13:37  * travis-cipart
15:14:23  * travis-cijoined
15:14:24  <travis-ci>luvit/luvit#2144 (small - fe3b3da : Tim Caswell): The build passed.
15:14:24  <travis-ci>Change view : https://github.com/luvit/luvit/compare/48a8bab504b9...fe3b3dad2286
15:14:24  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/62252836
15:14:24  * travis-cipart
15:18:44  <rphillips>thanks
15:19:11  <rphillips>current binary is at about 10.7 MB on this box
15:19:15  <rphillips>RSS
15:26:01  <rphillips>creationix: not a huge change
15:26:12  <rphillips>10.3 MB
15:26:14  <creationix>does the dump still have the full certs?
15:27:43  <rphillips>still has this source file
15:27:46  <rphillips>https://www.evernote.com/shard/s9/sh/a4e8c134-aca8-4fb1-9b5e-def38b8ac13e/7b73ff4a513cdb3f46ddc80507c7f346
15:28:26  <creationix>maybe we do need to pre-compile them so it never loads the source?
15:28:42  <rphillips>maybe
15:34:33  <creationix>so the bytecode is actually smaller than the lua in this case
15:34:41  <creationix>I guess that massive license header makes a difference
15:42:23  <creationix>rphillips: try this patch to lit
15:42:25  <creationix>https://github.com/luvit/lit/compare/small
15:42:41  <creationix>it will compile all lua files and strip debug info during lit make
15:42:47  <creationix>(including deep dependencies)
15:43:52  <creationix>for luvit, the total zip bundle goes from 570k down to 367k (before compression)
15:44:13  <creationix>the final size is barely smaller though
15:45:07  <creationix>256k vs 211k for the zip bundles
15:45:13  <creationix>but it is still smaller
15:45:24  <rphillips>doesn't seem worth it
15:45:34  <rphillips>the memory size is about the same
15:45:35  <creationix>well, the goal isn't to save file size
15:45:56  <creationix>you're not still seeing certs in the core dump are you?
15:48:20  <creationix>of course the certs are stored as strings, unless we change them to store as pre-parsed x509 certs it won't help
15:48:31  <creationix>and pre-parsed might be bigger because of cert padding
15:48:34  <creationix>*struct padding
15:48:52  <creationix>it's only 300k of lua anyway
15:49:11  <rphillips>right... i have a tweak to nil out the cert buffer after load
15:50:27  <creationix>bytecode for certs is 235k vs 310k for lua
15:50:32  <rphillips>those two tweaks drop the RSS by 1 MB
15:51:27  <creationix>better, but is it worth loosing line numbers in strack traces?
15:51:37  <creationix>you should at least get the correct filename
15:51:45  <rphillips>i would rather have stack traces I think
15:52:04  <creationix>it might be a fun flag to add to lit though
15:52:25  <creationix>then I can write heavily commented lua code without worrying about it bloating my luvi apps
15:52:33  <rphillips>yeah
15:53:22  <creationix>I wonder if debug mode keeps the comments or just records the offsets of the actual code
15:53:33  <creationix>then you'd keep full debug but still shrink size a bit
15:53:46  <creationix>just remove the true in string.dump in lit to test
15:54:19  <rphillips>preserves the comment
15:54:34  <creationix>the cert file is about the same with or without debug ingo
15:54:38  <creationix>*info
15:55:21  <creationix>are you sure it keeps the comments? luajit -bg -t raw strips them
15:56:40  <rphillips>i tried the string.dump in the repl
15:57:19  <creationix>that one does funny things for short strings
15:59:51  <creationix>yep, it's using the first line as the filename if you don't pass one in
16:01:05  * lvhpart ("mov eax, 1; push 0; int 80h")
16:02:27  <creationix>rphillips: this seems to give the correct stack traces https://github.com/luvit/lit/compare/small#diff-28a24a93b2251fb77bf0733f71cb233fR411
16:03:07  <creationix>with this version of lit, my luvit binary is actually a little bigger
16:03:26  <creationix>but it does have full stacktrace support and hopefully uses less ram (it does still strip out comments)
16:05:13  <rphillips>trying it
16:06:58  <rphillips>sweet
16:07:11  <creationix>having all the lua precompiled should help with startup time (not that it was an issue)
16:07:39  <rphillips>bundle:load() will that bypass the cache?
16:08:09  <creationix>bundle:load just does a relative pathJoin and then calls loadfile
16:08:20  <creationix>but as I just noticed, that will return true the second time you call it
16:08:51  <creationix>it probably needs to bypass the cache since that can break require if you load something and then later try to require it
16:09:23  <rphillips>https://github.com/luvit/luvit/compare/fixes/nil_the_root_cas_after_load
16:09:35  <rphillips>this nil's the root_ca's after they are loaded
16:10:16  * travis-cijoined
16:10:17  <travis-ci>luvit/luvit#2145 (fixes/nil_the_root_cas_after_load - 3ca653b : Ryan Phillips): The build passed.
16:10:17  <travis-ci>Change view : https://github.com/luvit/luvit/commit/3ca653b1a0f5
16:10:17  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/62261390
16:10:17  * travis-cipart
16:10:26  <creationix>rphillips: where does DEFAULT_CA_STORE get set?
16:10:28  <rphillips>not sure if we really want to do this
16:10:34  <rphillips>couple lines down
16:11:08  <creationix>oh, if it's unconditional then why have a loadRootCAStore function at all?
16:11:38  <rphillips>there was that memory issue with the x509 store
16:11:41  <rphillips>before
16:11:58  <rphillips>i'll refactor this
16:12:24  <creationix>so how much did the lit change affect binary size and rss usage?
16:12:33  <creationix>I expect the binary got a little bigger
16:12:52  <rphillips>looks like after the binary gets warmed up... it's saving about 500k
16:14:35  <creationix>unrelated, the luvit unit tests are segfaulting about every other run on my linux box (ubuntu 14.04)
16:15:11  <creationix>we were seeing that on travis too right?
16:16:31  <rphillips>right
16:16:36  <rphillips>we never got a good backtrace
16:16:37  <rphillips>https://github.com/luvit/luvit/compare/fixes/nil_the_root_cas_after_load
16:17:09  * travis-cijoined
16:17:10  <travis-ci>luvit/luvit#2146 (fixes/nil_the_root_cas_after_load - 56f4477 : Ryan Phillips): The build has errored.
16:17:10  <travis-ci>Change view : https://github.com/luvit/luvit/compare/3ca653b1a0f5...56f447779b10
16:17:10  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/62262362
16:17:10  * travis-cipart
16:17:46  * travis-cijoined
16:17:47  <travis-ci>luvit/luvit#2147 (fixes/nil_the_root_cas_after_load - 559bdaa : Ryan Phillips): The build passed.
16:17:48  <travis-ci>Change view : https://github.com/luvit/luvit/compare/56f447779b10...559bdaa0d22a
16:17:48  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/62262524
16:17:48  * travis-cipart
16:21:25  <creationix>https://github.com/luvit/lit/pull/78
16:21:59  <rphillips>https://github.com/luvit/luvit/pull/733
16:23:13  <creationix>so both out PRs combined saved about 500kb RSS. I'll take it
16:27:21  <creationix> now I can use verbose comments and not feel bad about it!
16:27:36  <creationix>I was wanting to put docs for single-file lit packages in a giant block comment
16:31:52  <creationix>so for the prototype, I've settled on a simple bus style where part of the task is simply luajit bytecode that gets run in a sandbox on the agent
16:32:01  <creationix>no dependencies or lit trees yet
16:32:06  * SouL_|_joined
16:32:25  <creationix>it's a compromise between everything being on the agent statically and everything streaming
16:32:53  <creationix>so now I just need some real tasks to implement
16:33:56  <creationix>it also gives the task a name so that you can hot-reload tasks on the agent
16:36:00  <rphillips>nice
16:37:27  * travis-cijoined
16:37:28  <travis-ci>luvit/luvit#2149 (master - 039615f : Ryan Phillips): The build passed.
16:37:28  <travis-ci>Change view : https://github.com/luvit/luvit/compare/48a8bab504b9...039615fa4075
16:37:28  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/62265421
16:37:28  * travis-cipart
16:38:23  <creationix>also with everything moving towards websockets and luajit bytecode, we can have web agents
16:38:31  <creationix>I implemented a luajit bytecode interpreter a while back
16:38:37  <creationix>so agents could live in browsers
16:39:06  <rphillips>is it on github?
16:39:11  <creationix>yep
16:39:22  <creationix>https://github.com/creationix/brozula
16:39:33  <creationix>and there are newer ones than mine that are a lot faster
16:39:57  <creationix>I never quite finished this one, but I know a lot more about luajit now so it should be easier now
16:40:31  <creationix>moonshine is pretty impressive, but it’s lua bytecode, not luajit bytecode http://moonshinejs.org/
16:48:17  <creationix>ok, new lit version published with compile step
16:48:29  <creationix>also it doesn't complain about version mismatches when it's a build revision only
16:51:28  * Akagi201quit (Remote host closed the connection)
16:53:54  <creationix>ok, and luvit update published with tweaks
16:55:13  * travis-cijoined
16:55:14  <travis-ci>luvit/luvit#2151 (master - 29082b5 : Tim Caswell): The build passed.
16:55:14  <travis-ci>Change view : https://github.com/luvit/luvit/compare/039615fa4075...29082b5b6300
16:55:14  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/62267832
16:55:14  * travis-cipart
16:57:44  <creationix>luvit can now run a short script in under 0.1s on my old raspberry pi. I think the pre-compiled lua files helped there
16:58:08  <rphillips>nice
16:58:11  <creationix>for comparison, node.js takes over 10x as long
16:58:22  <rphillips>and how much more ram :)
16:58:34  <creationix>heh, about 20x more ram
16:59:11  <creationix>I know of at least one startup moving to luvit from node for their raspberry pi based work
16:59:28  <creationix>the big killer was when v8 dropped support for older arm devices
16:59:58  <rphillips>oh neat
17:02:20  * rphillipsquit (*.net *.split)
17:02:20  * tetquit (*.net *.split)
17:02:20  * boxofroxquit (*.net *.split)
17:02:35  * tetjoined
17:02:51  * boxofroxjoined
17:02:56  * rphillipsjoined
17:14:07  <rphillips>hmm. creationix my lit build is downloading the package again
17:14:16  <rphillips>it's pointing to the luvi release branch
17:16:11  <creationix>rphillips: lit build?
17:16:53  <rphillips>https://agentbuild.cm.k1k.me/builders/agent2-centos63-x86_64/builds/27/steps/run%20build/logs/stdio
17:17:04  <rphillips>my end-2-end build for the agent
17:17:26  <rphillips>v2.0.6 of luvi
17:19:11  <rphillips>ah hah
17:19:12  <creationix>2.0.6 is latest luvi right?
17:19:15  <rphillips>i think my lit version is wrong
17:19:31  <creationix>ahh, it's probably trying to downgrade your luvi
17:22:09  <rphillips>so the luvi binary we have doesn't work on: rhel5,rhel6,ubuntu{10.04,11.04,11.10},debian{6,7},centos{5,6}
17:22:24  <creationix>ouch
17:22:33  <creationix>build on ubuntu 14.04 x64
17:22:43  <rphillips>we might want to try building on a rhel5 box
17:22:47  <rphillips>or centos5
17:27:49  <rphillips>yep, bumping the lit version fixed it
17:32:11  <creationix>so I thought you were building custom luvi for the agent on the older boxes. Would you rather just build the official luvi binaries on an old system?
17:39:05  <rch>win 16
17:39:10  <rch>oops, sorry
17:40:09  <rphillips>creationix: i am building a custom luvi... the issue was it tried to download the older luvi because the lit version was old
17:40:20  <rphillips>i think building the custom luvi is the way to go
17:40:30  <creationix>ahh, the version just needs to match
17:40:32  <rphillips>too many distro quirks to get right
17:40:48  <creationix>I can make it more lax and use the internal luvi if it matches semver with the require luvi
17:40:58  <creationix>then it won't downgrade unless there is a major number change
17:41:15  <rphillips>i sorta like it how it is... it fails gracefully
18:17:09  <rphillips>creationix: quick meeting after this one?
18:17:16  <rphillips>i have a 1x1 at 1:30
18:17:17  <creationix>sure
18:17:32  <creationix>after that is fine. I’m expecting a visitor at 1:30 anyway
18:18:48  <rphillips>http://labs.omniti.com/labs/reconnoiter/docs/noitd.wire.protocol.html
18:18:55  <rphillips>this is the REST protocol the API talks to
18:22:56  * Akagi201joined
18:23:29  <creationix>xml :P
18:24:22  <creationix> should we get an xml parser for luvit or will this eventually be json?
18:25:33  <rphillips>it'll migrate to whatever we want to make it... probably json
18:26:08  <creationix>I wonder what "{" means in msgpack
18:26:17  <creationix>hopefully it's not a valid first byte :)
18:27:22  <creationix>hmm, it's a valid integer
18:27:30  <creationix>123
18:27:44  * Akagi201quit (Ping timeout: 272 seconds)
18:28:06  <creationix>in fact, pretty much all the visible ASCII characters are valid integers in msgpack
18:29:10  <rphillips>we could look for MSGPACK
18:29:13  <rphillips>then switch protocols
18:31:52  <creationix>will we have a framing protocol around the messages like websocket?
18:31:55  <creationix>https://gist.github.com/creationix/4a47b7b9877c9cc94d4c
18:32:03  <creationix>the current framing is newline delimited right?
18:32:12  <creationix>(which isn't safe for msgpack)
18:32:28  <rphillips>i think that would be smart
18:32:51  <creationix>if we had frames and we knew the frame was exactly one message then it would be simple
18:33:11  <creationix>msgpack decode would only consume 1 byte when there were 13 and we would know to try json
18:33:58  <creationix>well with websocket framing, for example, we could use unicode frames for json and binary frames for msgpack
18:34:11  <creationix>but that's already different than plain newline delimited json
18:34:41  <creationix>now websocket is different that raw JSOn
18:34:51  <creationix>JSON will start with "{" and websocket will start with "GET"
18:35:15  <creationix>the client won't switch protocols mid stream, so it's first bytes on the tls stream that matter
18:35:58  <creationix>I think that will work great. Accept newline-delimited-json or msgpack over websocket
18:36:05  <creationix>those are simple to tell apart
18:42:58  <rje>creationix, rphillips: finally got to talk with shane, dude's been sick as a dog, product is cool with the private net agent, self-updating/downloading code as long as that code is publicly accessible.
18:43:28  <creationix>awesome
19:05:44  <rphillips>yeah, that would be slick
19:05:57  <rphillips>rje: sweet
19:06:14  <rphillips>alex is going to help get us some more requirements for private monitoring
19:09:13  <creationix>thanks
19:10:14  <rje>creationix, rphillips: so i was picking pquerna's brain this morning. how much memory is taken up by the zip file in ram when it is loaded as part of the exe?
19:10:42  <rje>there are some things we can do to not have that ram wasted
19:15:50  <rphillips>afaik, the entire zip isn't in ram
19:15:54  <rphillips>the zip has an index
19:22:06  <rphillips>rje: does that make sense?
19:23:07  <rje>rphillips, not really
19:23:46  <rphillips>so the executable is opened and it's scanned for files
19:24:22  <rphillips>scanned for zip index
19:24:25  <rphillips>*
19:24:33  <rphillips>it's pretty efficient from what I can tell
19:24:46  <rje>rphillips, vidyo?
19:25:15  <creationix>ok, I’m free now
19:25:46  <rphillips>sure
19:30:31  <rje>go comcast
19:31:05  <rphillips>http://labs.omniti.com/labs/reconnoiter/docs/ch05s31.html
19:55:49  <rphillips>http://docs.rackspace.com/cm/api/v1.0/cm-devguide/content/appendix-check-types-remote.html#section-ct-remote.tcp
20:11:43  * Akagi201joined
20:16:40  * Akagi201quit (Ping timeout: 272 seconds)
20:18:42  <creationix>wow http://blogs.windows.com/buildingapps/2015/05/12/bringing-node-js-to-windows-10-iot-core/
20:19:27  <creationix>I wonder how hard it would be to port that to luvit
20:50:10  <rphillips>interesting
21:47:25  <rje>rphillips, i pulled latest from the agent to merge in my changes and the package no longer builds, anyt thoughts? https://gist.github.com/rjemanuele/3c790c98efb1dee3058b
21:48:32  <rphillips>C:/Code/luvi/src/lua/init.lua:392: ERROR: C:\Users\rje\Documents\rackspace\virgo\C:\Users\rje\Documents\rackspace\virgo\
21:48:35  <rphillips>contrib\printversion is not a zip file or a folder
21:48:39  <rphillips>looks like this failed
21:49:05  <rphillips>luvi-up is working
21:49:24  <rje>this is that branch
21:49:30  <rje>no changes
21:49:56  <rphillips>which branch is it?
21:50:05  <rje>luvi-up
21:50:17  <rje>i stashed all my changes
21:51:36  <rphillips>ah. make.bat package
21:56:38  <rphillips>rje: line 9 in make.bat
21:56:45  <rphillips>should be cmake -H. -Bbuild
21:56:58  <rphillips>but, it looks like that fails
21:57:09  <rphillips>https://www.evernote.com/shard/s9/sh/af9a3d63-579e-4fd2-8d48-cc97e3f63ba3/5db462dfe5414fe45fc7269c31862d76
21:58:00  * hdmsquit (Quit: hdms)
21:59:55  <rje>rphillips, hmmmm
22:06:42  * hdmsjoined
22:12:47  * a_lejoined
22:12:49  <rphillips>rje: i'm thinking that lit can't parse the commandline
22:13:50  <rphillips>added those options to luvi-up
22:16:02  <rje>rphillips, where else is lit called now aside from the :test block?
22:16:25  * a_lequit (Read error: Connection reset by peer)
22:16:29  <rje>i'm assuming fro cmake
22:16:53  * a_lejoined
22:17:22  <rphillips>rje: pull
22:17:36  <rphillips>line 45
22:17:40  <rphillips>of the CMakeLists.txt
22:18:35  <rje>ah there it is
22:25:23  <rphillips>rje: pull once more
22:25:46  <rphillips>looks like make and make package worked
22:28:21  <rje>thanks, that's the ticket
22:28:37  <rphillips>it was wanting the relative path on windows
22:28:40  <rphillips>go figures
22:29:16  <rphillips>generated an installer for me though
22:52:58  * piernovquit (Read error: Connection reset by peer)
22:53:59  * piernovjoined
23:01:13  * Akagi201joined
23:06:16  * Akagi201quit (Ping timeout: 272 seconds)
23:07:36  * a_lequit (Remote host closed the connection)
23:11:22  * hdmsquit (Quit: hdms)
23:33:45  * a_lejoined
23:37:06  * jetljoined
23:38:42  * tetquit (Ping timeout: 244 seconds)
23:50:54  <rje>rphillips, did you notice that the installer *always* uses "Program Files (x86)" as the install directory?