00:02:30  * dan336quit (Quit: Leaving.)
00:29:49  * travis-cijoined
00:29:51  <travis-ci>luvit/luvit#1580 (http-client - a01f286 : Rob Emanuele): The build has errored.
00:29:51  <travis-ci>Change view : https://github.com/luvit/luvit/compare/9f0624436871...a01f2865ce14
00:29:51  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/50572225
00:29:51  * travis-cipart
00:41:31  * not^vquit (Ping timeout: 255 seconds)
01:10:17  * DarkGodquit (Ping timeout: 245 seconds)
01:52:36  * dan336joined
01:53:15  * dan336quit (Client Quit)
02:11:50  * a_lequit (Read error: Connection reset by peer)
02:12:13  * a_lejoined
02:35:18  * imzyxwvujoined
02:38:08  * imzyxwvu1joined
02:39:24  * imzyxwvuquit (Ping timeout: 245 seconds)
02:49:02  * imzyxwvujoined
02:50:39  * imzyxwvu1quit (Ping timeout: 245 seconds)
02:58:38  * a__quit (Ping timeout: 246 seconds)
03:12:08  * travis-cijoined
03:12:09  <travis-ci>luvit/luvit#1581 (fixes/process_kill_and_getpid - 157124a : Ryan Phillips): The build is still failing.
03:12:10  <travis-ci>Change view : https://github.com/luvit/luvit/compare/6be0dd7c4d3c...157124a3b50e
03:12:10  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/50583955
03:12:10  * travis-cipart
03:43:12  * joconnorquit (Ping timeout: 252 seconds)
05:02:47  * hdmsquit (Quit: hdms)
05:07:57  * imzyxwvu1joined
05:09:16  * imzyxwvuquit (Ping timeout: 255 seconds)
06:41:07  * travis-cijoined
06:41:07  <travis-ci>luvit/luvit#1582 (http-client - ce98f11 : Rob Emanuele): The build failed.
06:41:08  <travis-ci>Change view : https://github.com/luvit/luvit/compare/a01f2865ce14...ce98f1169753
06:41:08  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/50595618
06:41:08  * travis-cipart
06:45:04  * travis-cijoined
06:45:05  <travis-ci>luvit/luvit#1584 (http-client - 041ca2a : Rob Emanuele): The build is still failing.
06:45:05  <travis-ci>Change view : https://github.com/luvit/luvit/compare/ce98f1169753...041ca2a9faae
06:45:05  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/50595818
06:45:05  * travis-cipart
06:53:29  * torporjoined
06:53:40  <torpor>hi
06:55:18  <torpor>trying to build on raspian (latest) and get this error on 'make test':
06:55:19  <torpor>http://pastebin.com/w68R1MbW
06:55:23  <torpor>anyone know what thats about?
06:56:33  <torpor>ok ran it again and didn't get it .. strange.
06:56:39  <torpor>maybe my rpi was 'settling'
07:21:29  * a_lequit (Ping timeout: 246 seconds)
07:22:58  * a_lejoined
07:28:32  * torporquit (Quit: Leaving.)
07:51:20  * torporjoined
07:52:23  * torporquit (Client Quit)
07:54:32  * torporjoined
08:26:00  * DarkGodjoined
09:24:13  * DarkGodquit (Ping timeout: 256 seconds)
09:24:40  * DarkGodjoined
09:51:25  * imzyxwvu1quit (Ping timeout: 255 seconds)
09:59:23  * imzyxwvujoined
09:59:30  <torpor>just wanted to report in that i'm currently attempting a build of luvit on the openpandora handheld device ..
10:24:02  <torpor> actually, doesn't work - no bins
10:24:13  <torpor>is there some way to build luvi bins independently?
11:10:00  * DarkGodquit (Ping timeout: 246 seconds)
11:30:20  * torporquit (Quit: Leaving.)
13:54:29  * torporjoined
14:23:21  <torpor>luvit runs great on my rpi! nice and easy to build too
14:26:05  <rphillips>torpor: were you able to build the luvi binaries?
14:26:29  <torpor>no
14:26:47  <torpor>there is something wrong with the ARM platform cmake detection on Angstrom linux (as is used in the openpandora)
14:27:05  <torpor>built fine on rpi (raspbian) but pandora, luvi didn't detect the arch and failed
14:27:06  <rphillips>not sure
14:27:09  <torpor>yeah
14:27:17  <rphillips>we build natively on the rpi
14:27:20  <torpor>i'll get back to it later if you're interested .. it'd be so nice to have luvit on the pandora
14:27:27  <torpor>yeah i'm just using my rpi instead
14:27:28  <rphillips>any help would be appreciated
14:27:34  <torpor>for now. but i want portable luvit. :)
14:28:23  <torpor>its great to develop for the rpi with lua/luvit this way, just exciting to be honest. and when i get it up on the pandora i'll be even happier.
14:28:41  <torpor>i'm using luvit as a backend for games, and using the pandora makes a multiplayer instance so much nicer to set up - i.e. no cloud, battery powered.
14:31:50  <rphillips>wow coo
14:31:52  <rphillips>cool
14:32:06  <rphillips>torpor: are you new to luvit, or have you used it before?
14:34:27  <torpor>i've been using it for a few months, but new to the latest massive changes
14:35:12  <torpor>was very happy to replace node and go 100% lua. ;)
14:35:17  <rphillips>:) awesome
14:35:22  <torpor>yup
14:35:41  <torpor>i will demo this rig next week to a "game company"
14:35:49  <rphillips>wow... that is cool
14:36:23  <torpor>i confess to not being too keen on the massive changes, but i'll catch up with luvi and everything .
14:37:13  <rphillips>we wanted to lower the barrier to entry into luvit... let us know your feedback once you try it out
14:43:02  <torpor>i'm not sure i see the utility of having an app bundler/package manager front-end.
14:43:09  <torpor>but i see this happening all over the place with lua
14:43:27  <torpor>so i figure it won't be bad, as long as .. eventually .. all these package managers somehow manage to conform with each other.
14:48:50  <rphillips>we work on the rackspace cloud monitoring agent, so shipping one binary has a benefit to us
14:49:37  <rphillips>a luvi/luvit app can be ran from the commandline with luvi as well... it does not have to be embedded
14:49:43  <rphillips>LUVI_APP=somepath/app luvi
14:50:49  <rphillips>you could potentially ship a package that installs into say, /usr/share/some-app/1.0.1 and point the binary to it's app folder
14:51:15  <torpor>well its a matter of just what your integration strategy is going to be
14:51:20  <rphillips>exactly
14:51:32  <torpor>in my case, i wanna just git-fetch and run the locally-built bin on the source folder as an application.
14:51:38  <torpor>don't need to .deb'ify it and so on
15:10:05  * a_lequit (Read error: Connection reset by peer)
15:10:45  * a_lejoined
15:29:45  * travis-cijoined
15:29:46  <travis-ci>luvit/luvit#1586 (fixes/process_kill_and_getpid - 80de765 : Ryan Phillips): The build is still failing.
15:29:47  <travis-ci>Change view : https://github.com/luvit/luvit/compare/157124a3b50e...80de765b154f
15:29:47  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/50646152
15:29:47  * travis-cipart
15:34:04  <rphillips>creationix: i think we want this line within the Makefile for luvit tests: LUVI_APP=app luvi-binaries/Darwin_x86_64/luvi tests/run.lua
15:34:42  * hdmsjoined
15:38:07  * torporquit (Quit: Leaving.)
15:41:45  * torporjoined
15:43:51  * torporquit (Client Quit)
15:47:46  * torporjoined
15:49:00  * torporquit (Client Quit)
15:49:34  * torporjoined
15:52:29  * a_le_joined
15:52:33  * a_lequit (Ping timeout: 265 seconds)
15:54:42  <creationix>torpor: what hardware would I need to dev on open pandora? I’m not opposed to collecting hardware to test on.
15:56:36  <torpor>you can use a pandora to dev on pandora. its a linux workstation.
15:57:12  <torpor>i'm compiling luvit/luvi with the pandora itself
15:57:18  <torpor>it has normal linux tools, etc.
15:57:33  <torpor>only thing thats broken is that for some reason luvi's ARM detection isn't working on Pandora, dunno why yet.
15:58:15  <torpor>if you're interested i'm quite happy to open up my pandora to you to have a look.
16:00:42  <creationix>I can maybe remote debug next week. I was just wondering if I could order my own
16:00:46  <creationix>looks like they are hard to buy
16:00:51  <torpor>they are a bit at the moment
16:00:58  <torpor>the team is working on the pyra - the successor
16:01:09  <torpor>but there is a very flourishing community around the pandora
16:01:14  <torpor>check out http://repo.openpandora.org/
16:01:20  <torpor>you will see why it has a cult following.
16:02:27  <rphillips>nice 1.7 Ghz
16:02:27  <torpor>i'm using mine as a portable demo platform for my multi-platform projects - based on the MOAI framework (http://getmoai.com/) .. which plays very nicely with luvit, btw. nothing says sexy like passing a lua table from one framework to the other. ;)
16:03:00  <creationix>I’ll bet
16:03:10  <torpor>lua has eaten my brain
16:03:15  <creationix>torpor: you know you can use luv directly if you don’t need all the structure and opinion in luvit
16:03:23  <creationix>luv is quite stable already
16:03:34  <creationix>https://github.com/luvit/luv
16:03:41  <torpor>creationix: i want a clean, stable build so i can track you guys' progress with little fuss .. best is if everything just builds clean and works.
16:03:42  <rch>the nodejs layer is nice though, if you have node fresher to mind than libuv
16:03:54  <torpor>yeah i do a bit, thats right
16:04:31  <creationix>wow, that pyra looks really nice. Any guess when it will be done this week?
16:04:33  <creationix>*year
16:04:52  <torpor>i used node to implement "shared memory" whereby a commonly accessed lua table was 'reflected' among participants by the node server, which means that on a frame-for-frame basis, we could have a shared table across instances.
16:04:58  <torpor>creatio
16:06:01  <creationix>rphillips: shall I start a new luvi build?
16:06:06  <torpor>creationix: the pyra is going to happen this year. the pandora crowd are a really vibrant group building these platforms .. i would suggest tracking the project and getting in early if you like it. its totally grass-roots and very much an open source style hardware project. lots of drama, lots of history, but lots of people who have been working on this stuff for a decade, now. we're definitely going to enjoy the pyra era of the saga .
16:06:13  <rphillips>creationix: please
16:06:23  <creationix>I don’t think there is anything else other than your pid/uid/gid stuff
16:06:36  <rphillips>correct. I don't think so either
16:06:53  <torpor>(anyway, i replaced all my node code with luvit last year, and am now catching up to get a new implementation this weekend..)
16:07:05  <creationix>torpor: awesome. I’ll try to set aside some budget. A portable device like that looks perfect for my demos, hacking, and teaching
16:07:22  <torpor>its really a dream machine
16:07:35  <creationix>estimated price? I’m guessing around $500
16:07:36  <torpor>i love my pandora (i have 2) and will have a few pyra ..
16:07:47  <rphillips>torpor: what prompted the shift from node to luvit/lua?
16:07:52  <torpor>i think EvilDragon is trying to keep it close to the 300 - 400 eurange
16:08:01  <torpor>rphillips: i hate javascript and love lua.
16:08:05  <rch>heh
16:08:06  <rphillips>gotcha
16:08:19  <torpor>my mind has been consumed by lua since picking it up 5 years ago
16:08:32  <torpor>my wife made a t-shirt for me for christmas that says "lua all the things"
16:08:39  <creationix>lua is nice, but I can’t deny the reach of JS thanks to browsers
16:08:48  <torpor>bollocks to the browser (cf. MOAI)
16:09:10  <creationix>but running lua in browsers is mostly feasable these days with compilers/emulators/transpilers
16:09:25  <torpor>MOAI is a Lua browser.
16:09:30  <bjorn>I was reading JavaScript 6 features and it does make it much more attractive than before at least. Some Lua features in there like (shallow) coroutines and multi-value returns.
16:10:01  <creationix>yeah, but ES6 is also a massive mess, reminds me of the complexity of C++
16:10:04  <creationix>lua is nice and simple
16:10:05  <torpor>i have no doubt that js has its value, but i sincerely don't give a shit because lua bytecode defeats all the things.
16:10:07  <torpor>;)
16:10:12  <bjorn>True.
16:10:21  <rch>should call it js++
16:10:22  <bjorn>Though, I wish Lua had arrow functions sometimes. :P
16:10:23  <creationix>torpor: did you see my luajit bytecode interpreter that runs in browsers?
16:10:29  <torpor>nope.
16:10:33  <torpor>might have heard of it though
16:10:39  <torpor>i just don't believe in the browser any more.
16:10:41  <creationix>never got it quite finished, but I think it’s feasable if I gave it more effort
16:10:54  <torpor>i think there is room in the world for an open-source client (MOAI) backed by a Lua bytecode universe.
16:11:01  <creationix>torpor: I’ve done web development for almost 20 years, so it’s hard for me to ignore
16:11:16  <torpor>btw moai targets can run in browsers too (html5+js host)
16:11:31  <creationix>we’ve been thinking about an OS with a linux kernel and running luvit as pid 1 to replace init/systemd/etc
16:11:58  <torpor>yeah me too
16:12:09  <creationix>luajit is crazy fast
16:12:11  <torpor>one thing i've done in my career is work on embedded systems for music studio equipment
16:12:29  <creationix>elua much?
16:12:39  <torpor>i.e. i did a filesystem for Yamaha, was involved in the Access Virus synthesizer. And I think a Lua-based embedded OS has a *huge* potential in the market.
16:13:06  <torpor>creationix: if you start or are involved in a pure-lua based pid1-type embedded system, i'm totally 110% there with you.
16:13:11  <torpor>i would do it today if i could.
16:13:29  <torpor>linux kernel, MOAI front-end, Lua-all-the-things approach.
16:13:40  <torpor>i imagine luvit-nextgen would be an init replacement
16:14:25  <creationix>rphillips: https://github.com/luvit/luvi/commit/edb06f7e3c8eb7f2e7897a518fe85d8b040fe34b
16:14:39  <rphillips>+1
16:14:59  <creationix>torpor: neat, something to explore after luvit 2.0 is released
16:15:09  <creationix>need to get that done asap since so many things are waiting on stable luvit
16:15:15  <torpor>i would very much like to be involved because i've been thinking about the subject for 15 years.
16:15:16  <torpor>;)
16:15:43  <creationix>luvit 2.0 should be within a month
16:15:46  <torpor>a lua-only linux embedded os would be an amazing project. i can think of so many places to put it.
16:16:17  <torpor>i'm on the luvit list, i'm going to start paying more attention once i get my old-luvit project working on new-luvit.
16:16:49  <torpor>btw you guys are awesome. i mean it.
16:19:21  * travis-cijoined
16:19:22  <travis-ci>luvit/luvi#358 (master - edb06f7 : Tim Caswell): The build has errored.
16:19:23  <travis-ci>Change view : https://github.com/luvit/luvi/compare/301c02961eb1...edb06f7e3c8e
16:19:23  <travis-ci>Build details : http://travis-ci.org/luvit/luvi/builds/50652549
16:19:23  * travis-cipart
16:19:36  * torporquit (Quit: Leaving.)
16:23:01  <bjorn>I was just updating luvit, but I guess it isn't building right now? ^^
16:23:25  <bjorn>Ah wait that was for luvi.
16:23:33  <bjorn>I got:
16:23:35  <bjorn>fatal: reference is not a tree: cb1b73fc7ab14ff238fdbf4424956cc0c2544e4a
16:23:35  <bjorn>Unable to checkout 'cb1b73fc7ab14ff238fdbf4424956cc0c2544e4a' in submodule path 'luvi-binaries'
16:23:35  <bjorn>Makefile:8: recipe for target 'luvi-binaries/Linux_x86_64/luvi' failed
16:23:44  * travis-cijoined
16:23:45  <travis-ci>luvit/luvi#359 (v0.6.5 - edb06f7 : Tim Caswell): The build passed.
16:23:45  <travis-ci>Change view : https://github.com/luvit/luvi/compare/v0.6.5
16:23:45  <travis-ci>Build details : http://travis-ci.org/luvit/luvi/builds/50653050
16:23:45  * travis-cipart
16:24:31  <creationix>did I add a submodule to something I never pushed?
16:24:50  <creationix>well, I’m working on a new luvi release anyway
16:24:51  <bjorn>I guess that may explain it.
16:24:59  * travis-cijoined
16:25:00  <travis-ci>luvit/luvi#358 (master - edb06f7 : Tim Caswell): The build has errored.
16:25:00  <travis-ci>Change view : https://github.com/luvit/luvi/compare/301c02961eb1...edb06f7e3c8e
16:25:00  <travis-ci>Build details : http://travis-ci.org/luvit/luvi/builds/50652549
16:25:00  * travis-cipart
16:25:41  * torporjoined
16:26:22  <creationix>bjorn: hmm, cb1b73fc7 is the Ubuntu 10.10 build of luvi v0.6.4, that should work
16:26:44  <bjorn>Hmm, I get the same error when trying to make lit.
16:26:48  <creationix>I see it on github https://github.com/luvit/luvi-binaries/commits/master
16:26:57  <creationix>github caching issues maybe?
16:27:15  <bjorn>Hmm, my index says "deleted" for all binaries.
16:27:19  <creationix>you can update to the latest version I just pushed (binary for osx)
16:27:33  <bjorn>[email protected]:~/projects/lit$ git submodule update
16:27:33  <bjorn>fatal: reference is not a tree: cb1b73fc7ab14ff238fdbf4424956cc0c2544e4a
16:27:33  <bjorn>Unable to checkout 'cb1b73fc7ab14ff238fdbf4424956cc0c2544e4a' in submodule path 'luvi-binaries'
16:28:00  <creationix>try a `fetch` and hard reset to origin/master in the submodule
16:28:08  <bjorn>I only see commit 2c855ac1150fd24a700ec0186f4e1671eba3b788 on origin/master of luvi-binaries.
16:28:13  <torpor>can i just say that i think binary release like this are counter-productive? if its hard to build for a platform, that is going to be covered up by the binary release, and can lead to the work on fixing the build not being done ..
16:28:36  <creationix>torpor: it’s not hard to build, but I’m trying to ease the barrier to entry
16:28:49  <creationix>windows people, and slow machines like raspberry pi take significant time to build
16:29:02  <bjorn>Ah, it was cloned with depth 1?
16:29:09  <torpor>really? then work on the docs/tutorials. i don't think bin releases are as productive as they could be. the kind of people who will use luvit will build it - if its easy to build.
16:29:23  <creationix>bjorn: oh interesting, submodules don’t like shallow clones
16:29:32  <creationix>so it broke because I just pushed a new version
16:30:22  <creationix>maybe I should do —depth 10 so the old versions are still there while I’m pushing the new ones
16:35:47  <creationix>I’m thinking that binaries for linux are a bad idea
16:35:53  <creationix>but they are certainly useful for windows
16:36:08  <creationix>and I like them for raspberry pi since it takes an hour to build on that poor machine
16:38:02  <rphillips>just tried luvi on freebsd 10... builds+links... can't find init.lua within the executable
16:38:16  * torporquit (Quit: Leaving.)
16:38:53  <rphillips>has to be a linker or compile flag
16:39:06  <creationix>darwin has trouble with that and bsd is related
16:39:15  <creationix>maybe we need to add bsd to some cmake config to export stuff
16:39:25  <creationix>how are you testing bsd btw
16:39:45  <rphillips>vagrant image
16:40:07  * torporjoined
16:41:10  <torpor>creationix: so i'm running luvit on my rpi, and it was nice to have luvi onboard. but i didn't try to build luvi on it yet. does it really take an hour?
16:42:04  <creationix>yes, but part of that is it builds luajit 4 times in amalg mode
16:42:10  <creationix>you’re welcome to help with that
16:42:28  <creationix>(I’m talking about the publish-raspberry target in the makefile)
16:42:33  <torpor>well i have some catching up to do and i'm also a bit more interested in the app side of things, but yeah .. i hear you.
16:43:07  <torpor>gtg, cu later.
16:43:16  * torporquit (Client Quit)
16:44:30  <creationix>rphillips: ok, binary is in everything but rPi
16:44:48  <rphillips>sweet. thanks... i'll update my pr
16:47:55  <creationix>I just updated luvi-up
16:48:50  <creationix>I also made the shallow clones a little deeper so they don’t break as soon as I push anything
16:49:49  * travis-cijoined
16:49:50  <travis-ci>luvit/luvit#1587 (luvi-up - 0d901cf : Tim Caswell): The build passed.
16:49:51  <travis-ci>Change view : https://github.com/luvit/luvit/compare/3a2a784070a0...0d901cfc7edb
16:49:51  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/50657140
16:49:51  * travis-cipart
16:50:31  <creationix>rphillips: just rebase with luvi-up to get the updated lit with the updated luvi
16:50:44  <rphillips>k
16:53:29  <bjorn>So I somehow worked my way around the luvi-binaries problem (not exactly sure how, unfortunately), but now I'm getting this when making luvit:
16:53:30  <bjorn>fatal: reference is not a tree: cb1b73fc7ab14ff238fdbf4424956cc0c2544e4a
16:53:30  <bjorn>Unable to checkout 'cb1b73fc7ab14ff238fdbf4424956cc0c2544e4a' in submodule path 'luvi-binaries'
16:53:30  <bjorn>Makefile:8: recipe for target 'luvi-binaries/Linux_x86_64/luvi' failed
16:53:36  <bjorn>Erm, old clipboard.
16:53:40  <bjorn>fail: [string "bundle:lib/parse-deps.lua"]:17: No matching package: luvit/[email protected]
16:57:11  <creationix>bjorn: fresh git clone of luvit?
16:57:13  <creationix>let me try
16:57:34  <bjorn>Well I tried 'git clean -dxf' to fix it, but it's not a fresh clone.
16:58:08  <creationix>submodules are a mess in git
16:58:16  <creationix>if I do a fresh clone on my mac it works
16:58:40  <creationix>`git clone https://github.com/luvit/luvit.git && cd luvit && make && make test`
16:59:15  <bjorn>I get this dependency error here.
16:59:26  <bjorn>Using your command.
16:59:42  <bjorn>(Linux 64-bit)
17:00:25  * a_le_quit (Ping timeout: 264 seconds)
17:01:17  * a_lejoined
17:02:38  <creationix>bjorn: which linux?
17:02:54  <creationix>bjorn: also, do you see buffer.lua if you do `unzip -l luvit`
17:02:57  <creationix>the binary is also a zip file
17:03:09  <bjorn>creationix: Xubuntu 64-bit
17:03:25  <creationix>the latest binry I just published was build on ubuntu 10.10
17:03:25  <bjorn>creationix: Well it didn't manage to build luvit.
17:03:36  <creationix>oh, so the lit binary is busted
17:03:44  <creationix>`unzip -l lit/lit`
17:04:01  <rphillips>creationix: https://github.com/luvit/luvi/pull/59
17:04:13  <rphillips>works... openssl bump is for an include path
17:04:22  <bjorn>creationix: Well there is nothing called "buffer" in there.
17:04:26  <creationix>rphillips: thanks
17:04:36  <creationix>bjorn: yeah, lit doesn’t use buffer, what was the error from?
17:04:49  <bjorn>Running 'make' in luvit.
17:04:54  <bjorn>Makefile:5: recipe for target 'luvit' failed
17:05:02  <rphillips>luvit unit tests pass on freebsd as well :)
17:05:32  <bjorn>So "lit/lit make app" says "fail: [string "bundle:lib/parse-deps.lua"]:17: No matching package: luvit/[email protected]"
17:06:13  <creationix>ahh, lit can’t find the package
17:06:22  <creationix>what does `lit/lit config` print for upstream?
17:06:25  <rphillips>https://atlas.hashicorp.com/chef/boxes/freebsd-10.0
17:06:39  <bjorn>defaultUpstream: lit.luvit.io
17:07:11  <creationix>bjorn: there is currently a bug in lit where it always tries to install dependencies even when they are already there locally
17:07:24  <creationix>bjorn: you must have tried lit when it was very early
17:07:39  <bjorn>I think I did, yes.
17:07:49  <creationix>change that line in your $HOME/.litconfig to make defaultUpstream and upstream be wss://lit.luvit.io/
17:07:58  <bjorn>I need to go have dinner now.
17:08:05  <creationix>bjorn: thanks for testing
17:08:55  <bjorn>creationix: No problem, thanks for your help. lit installed the deps now and make for luvit worked. :)
17:09:05  <creationix>awesome
17:09:23  <bjorn>creationix: I never created ~/.litconfig myself. Maybe it should avoid writing stuff there when those things are changed later?
17:09:42  * travis-cijoined
17:09:43  <travis-ci>luvit/luvi#360 (fixes/add_freebsd_support - 5c9c8b7 : Ryan Phillips): The build passed.
17:09:44  <travis-ci>Change view : https://github.com/luvit/luvi/commit/5c9c8b75e2ee
17:09:44  <travis-ci>Build details : http://travis-ci.org/luvit/luvi/builds/50659177
17:09:44  * travis-cipart
17:09:47  <creationix>I had to switch the protocol to be websockets to get around crappy proxies in some networks
17:10:48  <rphillips>heh
17:13:25  * travis-cijoined
17:13:26  <travis-ci>luvit/luvit#1588 (fixes/process_kill_and_getpid - 1efe18d : Ryan Phillips): The build is still failing.
17:13:26  <travis-ci>Change view : https://github.com/luvit/luvit/compare/80de765b154f...1efe18d0a225
17:13:26  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/50659953
17:13:26  * travis-cipart
17:14:16  <rphillips>creationix: the test case is using the luvit packages within the lit repo instead of the local dir
17:15:13  <creationix>rphillips: yes, that is still outstanding
17:15:29  <rphillips>ah k
17:15:59  <creationix>https://github.com/luvit/lit/issues/22
17:20:00  <creationix>rphillips: you can comment out the dependencies in package.json while you wait on the lit fix
17:20:19  <rphillips>yeah, let me see
17:20:21  <creationix>just remember to re-enable them whenever you publish a new version of luvit to lit
17:25:38  * travis-cijoined
17:25:39  <travis-ci>luvit/luvit#1589 (fixes/process_kill_and_getpid - 1ba924c : Ryan Phillips): The build was fixed.
17:25:40  <travis-ci>Change view : https://github.com/luvit/luvit/compare/1efe18d0a225...1ba924c2c91b
17:25:40  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/50661503
17:25:40  * travis-cipart
17:26:59  * joconnorjoined
17:27:08  * travis-cijoined
17:27:09  <travis-ci>luvit/luvit#1590 (fixes/process_kill_and_getpid - 80bef19 : Ryan Phillips): The build was fixed.
17:27:09  <travis-ci>Change view : https://github.com/luvit/luvit/compare/1ba924c2c91b...80bef19207bd
17:27:09  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/50661561
17:27:09  * travis-cipart
17:27:09  <rphillips>creationix: wdyt of https://github.com/luvit/luvit/pull/611/files
17:27:11  <rphillips>?
17:28:05  <creationix>it shouldn’t make a difference
17:28:15  * joconnorquit (Read error: Connection reset by peer)
17:28:38  <creationix>actually, what I did do for luvi is run twice, once from embedded zip and once from filesystem
17:28:44  * joconnorjoined
17:29:38  * joconnorquit (Remote host closed the connection)
17:29:50  <creationix>rphillips: since it unconditionally re-builds the luvit binary every time, it shouldn’t matter right?
17:30:16  <rphillips>well... it doesn't pull in anything from the app directory right now
17:30:24  <rphillips>if I comment out the deps
17:30:46  * joconnorjoined
17:30:58  <creationix>good thing I’m cleaning up lit, it’s all sorts of buggy
17:31:17  <creationix>go for it, add the LUVI_APP stuff
17:32:57  * joconnor_joined
17:32:58  * joconnorquit (Read error: Connection reset by peer)
17:32:59  * joconnor_quit (Read error: Connection reset by peer)
17:33:21  <rphillips>k https://github.com/luvit/luvit/pull/611
17:33:26  * joconnorjoined
17:34:48  * joconnorquit (Read error: Connection reset by peer)
17:34:58  * travis-cijoined
17:34:59  <travis-ci>luvit/luvit#1592 (fixes/process_kill_and_getpid - 530b8e8 : Ryan Phillips): The build was broken.
17:34:59  <travis-ci>Change view : https://github.com/luvit/luvit/compare/80bef19207bd...530b8e884c13
17:34:59  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/50663113
17:34:59  * travis-cipart
17:35:30  <creationix>I see you’re also skipping `lit make` entirely
17:35:34  <creationix>that’s probably more stable for now
17:35:52  * joconnorjoined
17:36:44  * joconnor_joined
17:36:52  <rphillips>it'll be easy to put back
17:36:57  * joconnorquit (Read error: Connection reset by peer)
17:36:58  * joconnor_quit (Read error: Connection reset by peer)
17:37:14  * joconnorjoined
17:38:49  * travis-cijoined
17:38:50  <travis-ci>luvit/luvit#1594 (fixes/process_kill_and_getpid - 2d4c2ef : Ryan Phillips): The build was fixed.
17:38:50  <travis-ci>Change view : https://github.com/luvit/luvit/compare/530b8e884c13...2d4c2efce044
17:38:50  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/50663584
17:38:50  * travis-cipart
17:40:26  <creationix>rphillips: keep reloading the test till it passes right ;)
17:40:39  <rphillips>yeah, I want to fix that problem
17:41:24  <rphillips>creationix: do you get that error on any of your boxen?
17:41:36  <creationix>I’ve never seen the socket timout issue
17:46:35  * travis-cijoined
17:46:36  <travis-ci>luvit/luvit#1596 (luvi-up - 9548e0c : Ryan Phillips): The build passed.
17:46:36  <travis-ci>Change view : https://github.com/luvit/luvit/compare/0d901cfc7edb...9548e0cff831
17:46:36  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/50664650
17:46:36  * travis-cipart
17:51:18  <rphillips>might be a bug with timer resolution
17:53:15  <rphillips>https://github.com/luvit/luvit/issues/613
17:53:39  <creationix>cool
17:58:03  <rphillips>appveyor builds are faster to spawn than travis now
17:58:10  * travis-cijoined
17:58:11  <travis-ci>luvit/luvit#1597 (http-client - 60374b9 : Rob Emanuele): The build is still failing.
17:58:11  <travis-ci>Change view : https://github.com/luvit/luvit/compare/041ca2a9faae...60374b922f1a
17:58:11  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/50666284
17:58:11  * travis-cipart
17:58:21  <creationix>yep
18:00:02  <rphillips>+1? https://github.com/luvit/luvit/pull/608
18:01:31  <creationix>I don’t care
18:01:40  <creationix>merge if you want
18:08:30  * travis-cijoined
18:08:31  <travis-ci>luvit/luvit#1601 (luvi-up - 03b8766 : Ryan Phillips): The build passed.
18:08:31  <travis-ci>Change view : https://github.com/luvit/luvit/compare/9548e0cff831...03b876655d21
18:08:31  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/50667363
18:08:31  * travis-cipart
18:22:24  <rphillips>looking into a bug from support for the agent
18:23:40  <rphillips>https://github.com/virgo-agent-toolkit/rackspace-monitoring-agent/issues/666
18:23:57  <rphillips>same issue
18:27:12  <bjorn>I don't really understand the usefulness of "%d %d" % { 1, 2 }. It's mainly just slower, right?
18:27:28  <bjorn>Though I guess as usual I'm too worried about performance and it may look nicer like that in some code.
18:28:33  <creationix>rphillips: timers aren’t being nice today are they?
18:28:38  <bjorn>rphillips: Could you also set __call and have "%d %d" (1, 2)?
18:28:59  <rphillips>creationix: not at all...
18:29:08  <creationix>bjorn: no, that’s a syntax error
18:29:20  <bjorn>Ah, stupid. :P
18:29:24  <creationix>bjorn: you’d have to wrap the string literal in parens
18:29:37  <bjorn>Well alright.
18:29:46  <creationix>personally I just use string.format
18:30:02  <bjorn>Oh... if you pass one argument and it's a literal, you can do "%s foo" "bar" :P
18:30:08  <creationix>and when I really care about performance I’ll cache `format` in an upvalue or local variable
18:30:34  <creationix>bjorn: also syntax error for me
18:30:51  <bjorn>Hmm.
18:32:54  <bjorn>Right, also requires parenthesis.
18:33:06  <bjorn>Somehow doesn't in this case:
18:33:07  <bjorn>> function foo(string) return function(s) print(s) end end
18:33:07  <bjorn>> foo "bar" "baz"
18:33:07  <bjorn>baz
18:33:31  <bjorn>But well, that's function return value and not working on a literal.
18:46:47  * imzyxwvuquit (Ping timeout: 246 seconds)
20:22:12  <rphillips>luvit is trending on github in lua https://github.com/trending?l=lua&since=monthly
20:29:40  <creationix>nice
21:17:04  <bjorn>Trending repositories results are currently being dissected.
21:17:04  <bjorn>This may be a few minutes. Now would be a great time to write that novel you've always been talking about.
21:17:07  <bjorn>heh...
22:19:54  * piernovquit (Remote host closed the connection)
22:20:22  <rphillips>going to take off a bit early and get a beer