00:02:21  <rphillips>creationix: whichever is easiest
00:02:52  <rphillips>a standalone luvi might be preferable
00:03:07  <rphillips>if we get luvi into the distributions, then it should be portable
00:03:39  <creationix>maybe lit should pre-inject the require system and also run scripts?
00:03:54  <rphillips>that would be slick
00:06:00  <creationix>but then lit apps won’t be raw luvi apps anymore
00:06:15  <creationix>since lit will be injecting the require bootstrap at the top of main.lua
00:06:29  <creationix>sure would make it easier to use though
00:09:07  * UniOnquit (Remote host closed the connection)
00:17:19  * dan336quit (Quit: Leaving.)
00:18:19  * travis-cijoined
00:18:20  <travis-ci>luvit/luvit#1566 (lit-up - dd400bb : Tim Caswell): The build passed.
00:18:20  <travis-ci>Change view : https://github.com/luvit/luvit/compare/be044b5353b5...dd400bb48a6f
00:18:20  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/50282714
00:18:20  * travis-cipart
00:19:33  * travis-cijoined
00:19:34  <travis-ci>luvit/luvit#1567 (lit-up - 0695e5f : Tim Caswell): The build was broken.
00:19:34  <travis-ci>Change view : https://github.com/luvit/luvit/compare/dd400bb48a6f...0695e5f3ab2c
00:19:34  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/50282829
00:19:34  * travis-cipart
00:22:43  <rphillips>perhaps the package.lua could define that somehow
00:23:04  <creationix>True
00:23:23  <creationix>I’m writing up tasks to clean up lit and documenting stuff. I’ll clean it all up tomorrow
00:23:30  <rphillips>cool. thanks
00:23:35  <creationix>lit isn’t yet ready for the library
00:30:52  <creationix>rphillips: commands documented a little better https://github.com/luvit/lit/tree/master/app/commands#lit-cli-commands
00:30:58  <creationix>dinner time
01:23:13  * a_lequit (Remote host closed the connection)
01:37:25  * a_lejoined
02:26:57  <rphillips>nice docs
02:59:30  * a_lequit (Ping timeout: 246 seconds)
03:15:22  * dan336joined
03:44:57  * imzyxwvujoined
03:53:44  * dan336quit (Quit: Leaving.)
03:58:28  * a_lejoined
04:41:37  * bjornquit (Read error: Connection reset by peer)
04:43:14  * bjornjoined
04:43:14  * bjornquit (Changing host)
04:43:14  * bjornjoined
05:22:36  * not^vjoined
05:42:28  * not^vquit (Ping timeout: 245 seconds)
07:08:28  * not^vjoined
07:15:45  * travis-cijoined
07:15:46  <travis-ci>luvit/luvit#1569 (http-client - 9f06244 : Rob Emanuele): The build has errored.
07:15:47  <travis-ci>Change view : https://github.com/luvit/luvit/compare/734ebf4a26b6...9f0624436871
07:15:47  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/50310083
07:15:47  * travis-cipart
07:25:39  * not^vquit (Read error: Connection reset by peer)
07:46:46  * imzyxwvuquit (Ping timeout: 255 seconds)
07:50:35  * imzyxwvujoined
08:21:33  * DarkGodjoined
09:55:47  * imzyxwvuquit (Ping timeout: 252 seconds)
09:59:35  * imzyxwvujoined
11:53:10  * dan336joined
12:15:51  * imzyxwvuquit (Ping timeout: 244 seconds)
12:23:16  * dan336quit (Quit: Leaving.)
13:26:03  * imzyxwvujoined
13:45:59  * blessYahujoined
14:02:21  * dan336joined
14:22:27  * dan336quit (Quit: Leaving.)
14:28:57  <rphillips>george added ssl_cache_mode support to lua-openssl
14:28:59  <rphillips>https://github.com/zhaozg/lua-openssl/commit/e91f9f7cf546e1978f6a523a06cf3d512b95b8b8
14:33:02  <rphillips>https://github.com/luvit/luvi/pull/58
14:36:26  <creationix>rphillips: mornin’
14:36:45  <rphillips>good morning
14:36:54  <creationix>ssl_cache_mode, that’s handy
14:37:21  <rphillips>yeah, it's based off my bug report I opened
14:37:40  <creationix>imzyxwvu: I just saw your message from yesterday. RPi2 sounds great
14:37:57  * creationixhas irc open in several machines at once
14:38:09  <imzyxwvu>yes i got it last day.
14:38:52  <creationix>I got a beaglebone black. I wonder if the binaries are compatible
14:39:37  <imzyxwvu>i run raspbian on it. it provides so fluent gnome3 experience. i choose raspbian because of it's larger community.
14:40:04  <imzyxwvu>beaglebone is so cool. it hass so many gpios.
14:40:45  <imzyxwvu>and it has analog inputs. rpi doesn't.
14:41:10  <imzyxwvu>i have some analog sensors but i couldn't use them with rpi.
14:43:47  <imzyxwvu>creationix: if you want to know if there binaries are compatible. you could send me a compiled program that prints "Hello World!". a test could show it.
14:44:33  * blessYahuquit (Remote host closed the connection)
14:47:19  * blessYahujoined
14:50:23  <creationix>imzyxwvu: it will be a bit, I need to re-flash the device. It was a clearance item from radio shack and has a really old version of angstrom on it
14:51:17  * blessYahuquit (Remote host closed the connection)
14:55:22  * blessYahujoined
15:02:41  * a__quit (Remote host closed the connection)
15:06:54  * a__joined
15:37:29  * dan336joined
16:10:32  <creationix>rphillips: so I’ve been thinking about the library unit test case and lit
16:10:42  <rphillips>yah
16:10:50  <creationix>it would make life easier if require were baked into lit and used the lit database instead of a modules folder
16:11:11  <creationix>we can still make static binaries using rch’s idea of copying a subset of the lit db into the zip bundle
16:12:09  <creationix>how attached are you to the idea of physical dependencies you can see and edit?
16:12:10  <rphillips>gotcha
16:12:32  <creationix>edit in particular, we can add a web frontend to lit to make them visible
16:12:40  <rphillips>for the bundle, I don't think it's an issue
16:13:02  <rphillips>will the LUVI_APP + lit install paradigm still work?
16:13:18  <creationix>yeah it will still be a luvi app
16:13:22  <creationix>luvi knows nothing of lit
16:13:32  <rphillips>it's sorta nice to edit a dependency on the local filesystem then push it upstream
16:13:34  <creationix>it will just be a different require module
16:13:49  <rphillips>that sounds fine with me
16:13:56  <creationix>also sometimes I’m developing a library and want to test it in the context of the program that consumes it
16:14:02  <creationix>I use `npm link` a lot
16:14:36  <creationix>I could look in “modules” first and if it’s not there look in the db
16:15:23  * torporjoined
16:15:37  <rphillips>+1
16:15:53  <rphillips>could be an interesting way to support binary modules as well
16:16:00  <creationix>the db is just a better graph than the filesystem for the dependencies graph
16:18:00  <creationix>could even export the entire db as a read-only filesystem via fuse for exploring
16:18:11  <creationix>my git-fuse POC would easy to adapt to this
16:19:31  <creationix>paths would be like: db/luvit/pretty-print/v0.1.0/16.lua
16:20:03  <creationix>or: db/creationix/git/v1.2.0.lua
16:20:09  <creationix>(for single file packages)
16:20:39  <creationix>with tag metadata at: db/creationix/git/v1.2.0.json
16:21:26  <creationix>actually, that may be a good simple http interface to browse the db
16:21:40  <creationix>http urls map about the same as filesystems
16:22:34  <creationix>rphillips: how do you envision binary modules working?
16:22:41  <creationix>special mapping per platform?
16:23:44  <rphillips>yeah
16:23:47  <creationix>foo/bar.lit -> foo/bar.win64.dll on windows 64 and -> foo/bar.darwin64.so on osx
16:24:18  <creationix>could even make the downloader skip binaries that aren’t for the running platform
16:24:25  <creationix>depending on how much we want to optimize
16:24:50  <creationix>the bundler certainly wants to skip other platform binaries
16:34:09  * UniOnjoined
16:39:44  <rphillips>hmm. lttng support in luvi would be interesting
16:41:17  <creationix>lttng?
16:43:37  <rphillips>http://lttng.org/
16:43:40  <rphillips>it's a tracing framework
16:43:42  <rphillips>for linux
16:45:49  <creationix>dtrace type thing?
16:45:56  <creationix>io.js just added support right?
16:46:10  <creationix>that would be awesome to have
16:46:18  <dan336>not to butt in, by why do that instead of something like dtrace or systemtap?
16:46:35  <rphillips>creationix: they did.
16:46:50  <rphillips>dan336: i think dtrace support would be slick as well
16:47:03  <rphillips>afaik, io.js/nodejs already has dtrace support
16:47:18  <creationix>yep, dtrace is great for darwin and solaris
16:47:39  <creationix>I think I heard lttng is better than systemtap or dtrace for linux though
16:47:51  <rphillips>correct
16:48:04  <rphillips>dtrace on linux is pretty much only with RHEL or Suse
16:48:12  <rphillips>i forgot which one
16:48:13  <dan336>ok, that makes sense, sytemtap is not a good implementation at all. and dtrace doesn't really exist
16:48:43  <creationix>so would that go in luv or luvi (or both)?
16:48:50  <creationix>I’m not sure what’s involved in adding hooks
17:11:28  <rphillips>maybe just luv
17:11:36  <rphillips>i wonder if libuv has the hooks already
17:11:50  * torporquit (Quit: Leaving.)
17:15:35  * torporjoined
17:17:41  <rphillips>doesn't look like it
18:17:04  * DarkGodquit (Ping timeout: 250 seconds)
18:19:01  <torpor>hey guys - i'm kind of new to luvit but have been hacking with it for a few months
18:19:21  <torpor>i just did an update and saw the luvi-up branch - is this considered the main branch we should work with these days?
18:19:51  <rphillips>it's still in a flux, but largely working well
18:20:27  <torpor>ok, so i'll switch to that then and catch up. any gotcha's for someone who has been ignoring it but still loves luvit? :)
18:20:36  <rphillips>:)
18:20:50  <rphillips>so there is one binary now called luvi
18:20:55  <torpor>ok
18:21:17  <rphillips>it supports embedded zip files to run scripts out of
18:21:23  <torpor>cool
18:21:48  <rphillips>we should have luvit in 'lit' the package manager soon
18:21:57  <rphillips>it's there now, but we are tweaking a few things
18:22:24  <rphillips>any comments/feature requests/etc would be great
18:24:48  <torpor>man i have a lot to catch up with
18:24:50  <torpor>what is lit? :)
18:25:13  <rphillips>it's the luvit package manager :) https://github.com/luvit/lit
18:25:18  <torpor>oh man
18:25:23  <torpor>any reason luvit didn't use luarocks?
18:25:44  <rphillips>the require system is just really different
18:25:56  <rphillips>though I believe creationix may be looking into that right now
18:26:21  <rphillips>lit make [somedir] will take the luvi binary and pack it all into one executable as well
18:26:22  * torporlooks at the 20 million package managers on his system and weeps
18:26:53  <rphillips>it == your luvi/luvit lua scripts
18:26:59  <torpor>ok
18:27:07  <rphillips>so it's a build tool as well
18:27:12  <torpor>so it should then be pretty easy to deploy then .. just a single file to copy up to the server and fire up ..
18:27:13  <imzyxwvu>another reason might be that many packages on luarocks are synchronous.
18:27:20  <rphillips>right
18:27:27  <rphillips>torpor: exactly
18:27:49  <rphillips>with libuv, luajit, (optional openssl and zlib)
18:27:59  <torpor>wow, gonna consume all this tomorrow .. nice work.
18:27:59  <rphillips>on windows we have windows services working as well
18:28:22  <torpor>i got into luvit a few months ago as i wanted to replace node .. and now it seems luvit has grown into something massive.
18:28:47  <rphillips>the next release is going to be exciting
18:28:58  <torpor>why?
18:29:08  <torpor>i mean besides all the above
18:29:39  <rphillips>well all of the above, and I believe we can attract more users
18:29:45  <torpor>ok
18:29:55  <rphillips>raspberry pi support, async embedded work
18:30:02  <torpor>sweet
18:30:13  <torpor>why rpi specifically - isn't this sort of a given with linux support?
18:30:32  <creationix>torpor: yes, but I make binaries
18:30:37  <rphillips>right
18:30:38  <creationix>saving people an hour of compiling on their pi
18:30:39  <torpor>hmm.
18:30:54  <torpor>so rpi binaries good to go .. sweet.
18:30:59  <torpor>is it going to be .deb ?
18:31:06  <torpor>i.e. packaged?
18:31:07  <creationix>that’s the goal
18:31:10  <torpor>righto
18:31:23  <creationix>once stable get the core bits into as many repos as possible
18:31:42  <imzyxwvu>would new luvit be in the apt repo of raspbian?
18:32:02  <creationix>that would be better than me creating binaries manually
18:32:19  <creationix>we’ll just have to see how much work it is to maintain the various repos
18:33:34  <creationix>rphillips: got basic http server done for lit https://github.com/luvit/lit/pull/26
18:33:52  <rphillips>oh man... nice
18:34:16  <creationix>ok, just deployed it
18:34:26  <creationix>and broke it
18:34:27  <creationix>http://lit.luvit.io/
18:34:41  <imzyxwvu>it shows 502?
18:36:56  <creationix>works locally, something with the nginx proxy broke the new code
18:37:24  <imzyxwvu>creationix: i saw in the web server code you heavily used string.format to generate the page.
18:37:25  <torpor>ok - over and out guys, thanks for the headsup and i'll be back for some more luvit action once i've caught up with all the new stuff.
18:37:30  * torporpart
18:37:54  <imzyxwvu>have you seen my web framework to simplify url dispatching??
18:38:05  <imzyxwvu>it included an eruby-like templating engine.
18:40:34  <creationix>ahh, found the problem. My nginx proxy is adding “Connection: upgrade” to all requests, not just websocket requests
18:47:00  <creationix>rphillips: imzyxwvu: ok, working now http://lit.luvit.io/luvit/stream/v0.1.0
18:47:39  <rphillips>nice
18:48:35  <imzyxwvu>it's nice!
18:49:55  <creationix>nothing fancy, but allows browsing all packages and versions
18:50:02  <creationix>and individual files by hash
18:50:49  <imzyxwvu>hmm, the ui could be improved later.
18:51:09  <creationix>for sure, it could have a github style ui for browsing easily
18:51:28  <creationix>or could just emit JSON metadata and let another static website consume it and show a pretty face
18:52:00  <creationix>I prefer the json route to keep this server webservice and lit protocol only
18:53:20  <imzyxwvu>just emitting json and being loaded by xhrs seems a better solution.
18:54:37  <creationix>I really like the self documenting style github uses for their API https://api.github.com/
18:54:44  <creationix>looks really nice if using JSONView plugin
18:54:49  <creationix>and it hyperlinkable in that case
18:56:35  <creationix>also since the lit protocol is over websocket, you could easily implement a lit client entirely in the browser
18:57:17  <creationix>you could even generate public ssh keys in the browser, upload them to github using their api and oauth, then create new modules using the same technique as tedit.creationix.com and publish to lit using websockets
18:57:25  <creationix>the only thing you can’t do in the browser is run the lua code
18:57:49  <rphillips>though... we could write a service to execute the lua code :)
18:57:54  <creationix>exactly my thoughts
18:58:10  <imzyxwvu>lua could be compiled by clang into js.
18:58:16  <creationix>true, but not libuv
18:58:32  <imzyxwvu>hmm. js could provide io.
18:58:42  <imzyxwvu>not
18:58:43  <creationix>right, you could re-implement the APIs
18:59:03  <creationix>which would be interesting. I’ve always wanted to virtualize an entire OS in the browser
18:59:31  <imzyxwvu>there is a linux vm running in browser.
18:59:44  <creationix>right, but I’m thinking higher level, paravirtual
18:59:46  <imzyxwvu>created by the author of qemu: bellard.org/jslinux
18:59:55  <creationix>no need to emulate the x86 cpu
19:00:21  <creationix>though is luvi builds in his vm, that could be one option
19:01:46  <rphillips>http://blog.phusion.nl/2015/02/09/traveling-ruby-20150210-smaller-supports-ruby-2-2-windows/
19:01:51  <rphillips>self contained ruby
19:04:01  <imzyxwvu>creationix: could i use lit as a luvit library?
19:23:46  <creationix>imzyxwvu: not yet, but it shouldn’t be hard to publish lit itself to the repo
19:24:21  * DarkGodjoined
19:24:23  <creationix>imzyxwvu: that’s a good idea. I’m doing some internal refactors at the moment and I’ll take that into account
19:25:05  <imzyxwvu>i thought about making a web ui based on my web framework, if i could directly use lit in a luvit app...
19:26:05  <creationix>neat
19:35:48  * imzyxwvuquit (Ping timeout: 245 seconds)
19:58:07  <rphillips>we are so close...
20:00:15  <rphillips>rje: i don't want to really publicize the 3 weeks... it was a guestimate I think may be achievable
20:01:06  <creationix>I plan on finishing the lit cleanup this week, then we should be good to continue porting everything to lit
20:01:26  <creationix>the virgo-base-agent (a library with unit tests) exposed a flaw in my previous plan
20:01:30  <rphillips>yeah, there is still a lot to do... buildbots... packaging
20:01:46  <creationix>we kinda want to support libraries with tests
20:01:49  <rphillips>porting the rackspace-monitoring-agent as well... but I don't think that will take a long time
20:02:29  <creationix>I wonder if we could get someone to make a pretty website for lit if I expose and document the REST calls
20:02:45  <rphillips>that might be possible
20:03:10  <rphillips>at the mimimum we could bootstrap it
20:03:36  <creationix>imzyxwvu wanted to try one using lit on the server, but I had more imagined a static site using pure xhr calls
20:04:09  <creationix>it could even cache stuff in local storage in the browser using the lit protocol over websocket
20:04:47  <creationix>though wtih a js lit client the database might get a flood of js modules in it too
20:05:26  <creationix>so should we focus on getting luvi into the distributions or lit?
20:05:35  <creationix>luvi can always be extracted from lit
20:05:53  <creationix>(which is basically what lit make does, it extracts and then adds a new zip file)
20:06:19  <rphillips>i think two packages makes sense...
20:06:35  <creationix>but luvi is a build-time dependency to lit, not runtime
20:07:07  <creationix>if I were to install lit on my ubuntu box, I might depend on libuv, openssl, libluajit, and zlib, but not luvi
20:07:36  <rphillips>i was thinking we might want to deploy lit as source, and use the LUVI_APP wrapper
20:08:29  <rphillips>i'm not sold either way though. lit standalone would work too
20:09:20  <creationix>actually, thinking about luvi, I’m not sure why it needs LUVI_APP to be an env variable
20:09:54  <creationix>since it’s required, luvi could just shift the first arg as the LUVI_APP path
20:10:06  <creationix>and mutate the args table internally to hide the fact
20:10:20  <creationix>`luvi luvit/app` would load the luvit repl
20:10:31  <creationix>`alias luvit=“luvi luvit/app”`
20:10:33  <creationix>etc
20:10:43  <creationix>would be much friendlier to windows where setting env is harder
20:10:56  <creationix>and LUVI_TARGET doesn’t need to be in luvi since lit duplicates it
20:11:00  <rphillips>that is a good idea
20:11:56  <rphillips>https://www.elance.com/j/convert-existing-nodejs-process-cpu-plugin-lua-luvit/68655173/
20:13:01  <rphillips>man, that is super interesting
20:14:23  <rphillips>rje: did you see this?
20:14:26  <rphillips>https://www.elance.com/r/jobs/q-luvit/
20:22:41  <creationix>sigar and luvit
20:22:44  <creationix>interesting
21:29:54  <creationix>ok, building luvi tiny takes 10.5 minutes on my beagle bone
21:30:57  <rphillips>http://imzyx.com/technology/cross-compiling-lua-library-for-ios.html
21:32:15  <creationix>nice
22:14:23  <rphillips>wow... 10 minutes
22:14:32  <rphillips>not bad at all
22:18:22  <creationix>well, that was for tiny, but somewhat faster than rpi 1
22:18:50  <creationix>I think the killer feature of the BBB is you can wire it to any laptop via usb and it gets power and internet from the laptop
22:18:57  <creationix>and you can ssh into the bbb over the usb
22:19:21  <creationix>portable linux box, I’ll just have to see if it works with mac laptops or chromebooks too
22:19:40  <creationix>(plus it has ~100 GPIO pins)
22:20:16  <creationix>I can run `lit install luvit/luvit` in 0.7 seconds with a primed cache
22:23:31  <creationix>with no cache and downloading all data over the internet, it takes 4.9 seconds
22:24:01  <creationix>(to keep code simple, I run all network operations in serial)
22:25:25  <rphillips>that seems reasonable
22:25:56  <creationix>yeah, 5 seconds to download and install a node-clone API on a slow embedded device is good enough
22:26:09  <creationix>most of that is internet latency
22:26:24  <creationix>lit protocol downloads every git object one at a time
22:26:45  <creationix>there is some parallel logic there (all files in a tree are requested at once when syncing)
22:27:04  <creationix>but in this case, most the modules are single-file modules so it doesn’t do much parallel
22:32:51  <creationix>heh, making it parallel breaks the protocol
22:33:01  <creationix>the protocol assumes a single client making a single request at a time
22:50:57  * travis-cijoined
22:50:58  <travis-ci>luvit/luvit#1570 (lit-up - dd400bb : Tim Caswell): The build was fixed.
22:50:58  <travis-ci>Change view : https://github.com/luvit/luvit/compare/0695e5f3ab2c...dd400bb48a6f
22:50:58  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/50417774
22:50:58  * travis-cipart
22:52:26  * joconnorjoined