00:03:53  * dan336quit (Quit: Leaving.)
00:04:52  * UniOnquit (Quit: Leaving)
00:16:05  * a_lejoined
00:16:30  * a_lequit (Read error: Connection reset by peer)
00:17:12  * a_lejoined
00:22:50  * a_lequit (Read error: Connection reset by peer)
00:23:18  * a_lejoined
00:24:30  * a_lequit (Read error: Connection reset by peer)
00:24:43  * a_lejoined
01:18:03  * DarkGodquit (Ping timeout: 264 seconds)
02:54:05  <rphillips>i'm going to want to pull in virgo-base into rackspace-monitoring
02:54:14  <rphillips>via lit
02:55:11  <rphillips>i wonder if we could have a list of github IDs in package.lua that are allowed to push to lit
03:11:03  * a_lequit (Remote host closed the connection)
03:11:40  * a_lejoined
03:16:23  * a_lequit (Ping timeout: 256 seconds)
08:17:21  * DarkGodjoined
08:45:33  * travis-cijoined
08:45:33  <travis-ci>luvit/luvi#258 (winsvc - 545a566 : Rob Emanuele): The build passed.
08:45:33  <travis-ci>Change view : https://github.com/luvit/luvi/compare/2bd9ca2900a1...545a566f370e
08:45:33  <travis-ci>Build details : http://travis-ci.org/luvit/luvi/builds/47890210
08:45:33  * travis-cipart
08:52:03  * endou______quit (Ping timeout: 276 seconds)
08:53:36  * travis-cijoined
08:53:36  <travis-ci>luvit/luvi#260 (winsvc - 4b6d309 : Rob Emanuele): The build has errored.
08:53:36  <travis-ci>Change view : https://github.com/luvit/luvi/compare/545a566f370e...4b6d309d0889
08:53:36  <travis-ci>Build details : http://travis-ci.org/luvit/luvi/builds/47890836
08:53:36  * travis-cipart
09:05:13  * endou______joined
11:28:13  * travis-cijoined
11:28:14  <travis-ci>luvit/luvi#263 (winsvc - 7af1028 : Rob Emanuele): The build passed.
11:28:14  <travis-ci>Change view : https://github.com/luvit/luvi/compare/3e6472dc8dbf...7af102899c53
11:28:14  <travis-ci>Build details : http://travis-ci.org/luvit/luvi/builds/47903525
11:28:14  * travis-cipart
11:54:43  * travis-cijoined
11:54:43  <travis-ci>luvit/luvi#265 (winsvc - 5dd2fa4 : Rob Emanuele): The build passed.
11:54:43  <travis-ci>Change view : https://github.com/luvit/luvi/compare/7af102899c53...5dd2fa4e5c54
11:54:43  <travis-ci>Build details : http://travis-ci.org/luvit/luvi/builds/47905899
11:54:43  * travis-cipart
12:03:32  * travis-cijoined
12:03:32  <travis-ci>luvit/luvi#267 (winsvc - 3861ccc : Rob Emanuele): The build passed.
12:03:32  <travis-ci>Change view : https://github.com/luvit/luvi/compare/5dd2fa4e5c54...3861ccc589a7
12:03:32  <travis-ci>Build details : http://travis-ci.org/luvit/luvi/builds/47906635
12:03:32  * travis-cipart
15:29:31  * a_lejoined
15:31:55  * dan336joined
15:34:19  * avidaljoined
15:34:39  <avidal>glad to see luvit is still going strong, and congrats on the job creationix :)
15:36:12  <avidal>what's the difference between the standard, static, and tiny prebuilt luvi binaries for linux x86_64?
15:36:50  <avidal>ah, tiny is the default
15:37:49  <avidal>so tiny doesn't have openssl or zlib, large has openssl and zlib, but as shared libraries, and static has openssl and zlib statically compiled?
15:47:57  * a_lequit (Remote host closed the connection)
15:48:31  * a_lejoined
15:52:49  * a_lequit (Ping timeout: 244 seconds)
15:57:00  * a_lejoined
16:03:31  * tjcraveyjoined
16:09:43  <rphillips>avidal: righto :)
16:09:57  <rphillips>we have arm binaries as well for raspberry pi
16:27:43  <avidal>roger
16:32:13  * UniOnjoined
16:40:58  <songgao>rch rphillips creationix Hi
16:41:20  <songgao>so luvit-stream was almost a transpiling from node's stream
16:41:33  <rphillips>songgao: hey :)
16:42:01  <songgao>yeah end was replaced by either _end or finish
16:50:40  <avidal>Hmm. Can library code clear (or remove something from) the require cache?
16:51:16  <avidal>I'm working on a small tcp proxy with plugin support and I'd like to be able to reload plugins without restarting the entire proxy
16:51:59  <avidal>Figure I can run my proxy with luvit and load plugins via `require`, but i need to be able to remove a module from the require cache after i've told it to teardown
16:53:30  <avidal>but it (seems) that require gives you just the generator function and everything else is hidden from scope
16:58:02  <rphillips>avidal: a PR would be great... sounds like a useful feature
16:59:34  <avidal>also, i must be missing something because in the luvit repl require(module) doesn't actually return anything i can locally bind; best I can do is, for instance: `require('http').createServer`
17:00:08  <avidal>because: `local http = require('http'); http == nil`
17:01:15  <avidal>hmm, but the example works
17:01:58  <avidal>oh
17:02:02  <avidal>can't use locals at the top level of the repl?
17:02:24  <rphillips>right
17:03:21  <avidal>ok
17:03:38  <avidal>so maybe i can rewrite the require module in luvit to expose a bit more of the innards
17:10:15  <avidal>not quite sure how yet, but i'll think about it
17:12:49  <rphillips>i'm not sure if it needs a rewrite... there is a global table with the cache in it
17:13:20  <rphillips>it needs some accessor functions to wipe the cache, or wipe a particular entry
17:14:32  <rphillips>https://github.com/luvit/luvit/blob/luvi-up/app/modules/require.lua#L44
17:16:47  <avidal>yeah i'm looking at it
17:17:02  <avidal>i guess i was thinking about exposing the cache table directly, but i suppose there's no good reason
17:18:58  <avidal>so the setmetatable makes it so calling the module itself as a function calls requireSystem which returns the generator function, which returns the inner function
17:19:07  <avidal>loving it
17:19:58  <avidal>i'll poke around, need to more closely understand it
17:21:56  * a_lequit (Remote host closed the connection)
17:22:34  * a_lejoined
17:22:40  * a_lequit (Read error: Connection reset by peer)
17:26:35  <rphillips>sweet :)
17:27:41  * a_lejoined
17:29:17  <avidal>Having a hard time registering just how luvit main.lua upgrades the require function. I mean, I can see that it happens locally since it aliases `require` locally using the result of luvit-require, but I don't see how that causes the rest of luvit to use the same module loader.
17:29:42  <avidal>ohhhhhh
17:30:02  <avidal>the lua formatter in require.lua
17:30:19  * a_lequit (Read error: Connection reset by peer)
17:30:28  <avidal>injects the require function into the module before returning it
17:30:42  * a_lejoined
17:31:28  <avidal>er, injects the require function before calling the module function
17:32:53  * a_lequit (Remote host closed the connection)
17:33:28  <avidal>well, injects a new instance of the require system (by calling the generator again)
17:33:58  <avidal>well, a new generator function scoped to the path of the module itself
17:33:58  * a_lejoined
17:41:42  <rje>rphillips: service code works
17:41:56  <rphillips>sweet!
17:42:04  <rphillips>PR ready? or still WIP?
17:42:20  <rje>ready
17:42:37  <rje>i'm going to ask hounsou to read it too
17:43:12  <rphillips>nice
17:45:07  <rphillips>rje: the license header should be at the top of the files
17:47:43  <rje>rphillips: will do
17:53:20  <creationix>avidal: one idea is to use _G.require directly (lua’s native require)
17:53:27  <creationix>it exposes it’s require cache
17:53:41  <creationix>but then you have to use lua path semantics for require which I find very frustrating
17:54:25  <creationix>luvit’s custom require adds the very useful idea of relative requires (relative to the calling file) which is why it needs a custom version for each module
17:55:01  <creationix>so in it’s cache, the paths will be absolute, which might be tricky for you
17:56:58  <creationix>rphillips: I’m at the doctor with my toddler at the moment (ear infection), but when I get back to my desk, I plan on working on http(s) client. Do we have tcp and tls clients already? (“net” and “tls” modules)
17:57:10  * a_lequit (Read error: Connection reset by peer)
17:57:16  <creationix>I think I saw net.createConnection when I was working on http server
17:57:30  * a_lejoined
17:57:31  <rphillips>creationix: we do
17:58:06  <rphillips>tls.connect exists
17:58:20  * a_lequit (Read error: Connection reset by peer)
17:58:31  <rphillips>btw, I made the default suite TLS_V1
17:58:49  <creationix>cool
17:59:02  * a_lejoined
17:59:34  <avidal>creationix: I'm thinking about maybe having a require.unload that takes a module path, resolves it, then drops it from the cache. Do you know off-hand if the cache is shared? It seems to be so. The only thing unique per module seems to be the closure around the module.path to locate the module being required
18:00:15  <avidal>or maybe require.resolve(path) and then callers can explicitly get access to require.cache, similar to node in that regard
18:00:32  <avidal>not sure if having an `unload` function as part of the stdlib is the right thing to do
18:01:05  <avidal>but i also don't really want to fork luvit just because the require system doesn't expose what i would need to manipulate the cache
18:07:19  <rphillips>rje: went through a first pass
18:09:21  <rje>rphillips: almost done with the fixes
18:09:35  <rphillips>looks awesome
18:14:07  <rje>https://github.com/luvit/luv/pull/107
18:14:15  <rje>rfr ^
18:24:52  * travis-cijoined
18:24:52  <travis-ci>luvit/luvi#269 (winsvc - 9db03c7 : Rob Emanuele): The build passed.
18:24:52  <travis-ci>Change view : https://github.com/luvit/luvi/compare/3861ccc589a7...9db03c743d52
18:24:52  <travis-ci>Build details : http://travis-ci.org/luvit/luvi/builds/47947751
18:24:52  * travis-cipart
18:48:32  * travis-cijoined
18:48:33  <travis-ci>luvit/luvit#1472 (luvi-up - b9dad57 : Ryan Phillips): The build passed.
18:48:33  <travis-ci>Change view : https://github.com/luvit/luvit/compare/a5c9c5e6093f...b9dad57aca1f
18:48:33  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/47949239
18:48:33  * travis-cipart
18:49:06  <rje>if anyone else with a bend toward windows wants to give thoughts on the windows service api exposed in luvi please do, https://github.com/luvit/luvi/pull/43
18:51:22  * travis-cijoined
18:51:22  <travis-ci>luvit/luv#222 (expose_loop_state - 8f0e07d : Rob Emanuele): The build passed.
18:51:22  <travis-ci>Change view : https://github.com/luvit/luv/commit/8f0e07d10788
18:51:22  <travis-ci>Build details : http://travis-ci.org/luvit/luv/builds/47949260
18:51:22  * travis-cipart
19:09:40  * avidalquit (Quit: My Mac has gone to sleep. ZZZzzz…)
19:10:02  * avidaljoined
19:11:11  * travis-cijoined
19:11:11  <travis-ci>luvit/luv#224 (master - 1ad9f43 : Rob Emanuele): The build passed.
19:11:11  <travis-ci>Change view : https://github.com/luvit/luv/compare/03521fc08e10...1ad9f43bd7a4
19:11:11  <travis-ci>Build details : http://travis-ci.org/luvit/luv/builds/47953458
19:11:11  * travis-cipart
19:16:12  <avidal>Ok, I think I'm getting the hang of this. Looks like I need to make a new step in the process that resolves a callerPath, modulePath into a 'module key', which is used in the cache. I'll have to refactor some of the functions to make room for the resolver, since there's no discrete resolution step currently, it's just a side-effect of attempting to find a module
19:17:56  * travis-cijoined
19:17:57  <travis-ci>luvit/luvi#273 (winsvc - db29b12 : Rob Emanuele): The build passed.
19:17:57  <travis-ci>Change view : https://github.com/luvit/luvi/compare/d538a5d73ff4...db29b1246d32
19:17:57  <travis-ci>Build details : http://travis-ci.org/luvit/luvi/builds/47953717
19:17:57  * travis-cipart
19:19:37  <rphillips>avidal: that sounds reasonable
19:19:45  <avidal>Yeah, I think so too.
19:25:32  <avidal>Part of the problem is that while `finder` resolves the prefix and formatter, it's not actually the entire story since `loader` might change the path (to account for init.lua, or adding .lua)
19:28:15  <avidal>(don't mind me, i'm just brain dumping)
19:43:23  <creationix>avidal: yes, a standalone resolver would be useful indeed. I've loved that node has that
19:45:35  <avidal>yeah
19:50:37  * a_lequit (Remote host closed the connection)
19:52:31  * a_lejoined
20:06:42  <avidal>creationix rphillips: is lib/luvit no longer used in the luvi-up branch?
20:06:57  <avidal>just want to make sure there's nothing in there that i need to reference
20:07:00  <creationix>Correct, it's just there for easy access
20:07:04  <avidal>thought so
20:07:05  <creationix>currently it's all dead code
20:07:27  <avidal>so that means the luvi-up branch no longer supports npm installs then, correct?
20:07:42  <avidal>since the node_modules stuff was in lib/luvit/module.lua
20:07:49  <creationix>it can, but not the same way
20:07:53  * a_lequit (Read error: Connection reset by peer)
20:08:02  <creationix>when configuring the require generator, you can change "modules" to "node_modules"
20:08:13  <avidal>yeah, options.modulesPath
20:08:22  * a_lejoined
20:08:27  <avidal>er, modulesName
20:08:31  <creationix>https://github.com/luvit/luvit/blob/b9dad57aca1f3eca2662a33e8af8002c4900b5c5/tests/test-require.lua#L133-L143
20:09:00  <creationix>I'm open to the idea of allowing a list of modules names if it's needed. I just didn't want to add it till there was a concrete use case
20:10:45  <avidal>So if someone wanted to build an app with luvit that uses, for instance, node_modules for the bundled modules, they would need to use a custom luvit "build" that merely updates main.lua to change the modulesName when bootstrapping the module loader
20:13:40  <creationix>avidal: yeah, that should work
20:13:46  <creationix>also did you see how I packaged my "lit" app
20:13:52  <creationix>it doesn't inherit from luvit at all
20:13:53  <avidal>did not
20:14:02  <creationix>I just cherry picked the modules I wanted
20:14:03  <avidal>checking now
20:14:35  <creationix>I didn't want any of the node.js style APIs and wanted to use coroutines instead of callbacks.
20:17:46  <avidal>alias.sh and update.sh use luvit (or at least call it); or are those outdated?
20:19:41  <rphillips>creationix: lit is working well
20:19:58  <rphillips>the collaboration piece with other people making tweaks is the tricky part
20:20:17  <creationix>did you have any ideas on how to do this?
20:20:42  <rphillips>not really... but it's a sticking point
20:20:58  <creationix>would manually adding collaborators like npm does be enough?
20:21:29  <creationix>I think I could store this in the tag itself so it moves with the data and is digitally signed
20:22:13  <creationix>The first release would need to be the owner, but they could add other authorized people via comments in the tag message
20:22:28  <creationix>and the client would automatically keep these and repeat them in each release
20:23:44  <creationix>still, it would be nice to have group owned top-levels like "luvit/require"
20:24:11  <creationix>I could do this manually since I have access to the server, but I don't like using special priviledges
20:25:39  <avidal>Hmm, lit auth doesn't work for me, I'm guessing the openssl bindings are missing
20:26:02  <creationix>avidal: it requires the large or static version of luvi
20:26:09  <creationix>because of heavy openssl usage
20:26:33  <avidal>yeah i'm using the large darwin build
20:26:49  <creationix>that should work. It does make some assumptions though
20:26:49  <avidal>well, the regular `luvi` binary on luvi-binaries/Darwin_x86_64
20:26:53  <avidal>assuming that's the large build
20:27:01  <creationix>static, but yeah
20:27:02  <avidal>since it's not the -tiny, and there is no -static
20:27:20  <creationix>openssl on darwin is crap, too old to dynamic link
20:27:32  * a_lequit (Remote host closed the connection)
20:28:29  <creationix>avidal: lit assumes that $HOME/.ssh/id_rsa had github access under your github username
20:28:51  <avidal>Yeah, it does
20:29:01  <avidal>(that is, id_rsa.pub is what I've pushed to github)
20:29:06  <creationix>it verifies this by downloading your public keys from github and generating fingerprints for each comparing to the fingerprint of the local private key
20:29:12  <creationix>what's the error?
20:29:32  <creationix>I'm pretty sure rphillips published from darwin. I work on linux most the time
20:30:16  <avidal>ssh-rsa.lua:99: attempt to index local 'key' (a nil value)
20:30:35  <avidal>i pretty printed openssl.pkey and i get a clean report from there, i'll debug further
20:30:52  * a_lejoined
20:31:08  <avidal>(and key comes from a call to pkey.read)
20:31:36  <creationix>interesting, openssl can't read your private key
20:32:12  <creationix>if you run `head ~/.ssh/id_rsa -n1`, it outputs "-----BEGIN RSA PRIVATE KEY-----" right?
20:32:34  * a_lequit (Remote host closed the connection)
20:32:46  <avidal>yeah, and doing `p("Loading private key with data", data)` at the top of exports.loadPrivate dumps my private key to stdout
20:33:11  * a_lejoined
20:33:11  <creationix>try wrapping pkey.read with an assert maybe?
20:33:28  <creationix>nil as first arg will often have reason as second arg, assert will throw that
20:34:16  <avidal>just: assert(pkey.read(data, true)) ?
20:35:27  <avidal>nothing useful, just a traceback showing the loadPrivate call, walking up through auth:42 and then into the module loader
20:35:33  <avidal>but no descriptive message
20:37:38  * a_lequit (Ping timeout: 265 seconds)
20:37:42  <creationix>yep, I see it just returns nil, hmm https://github.com/zhaozg/lua-openssl/blob/master/src/pkey.c#L89-L131
20:38:14  <creationix>I guess he expects you to call some generic function to fetch the error
20:38:28  <creationix>personally I like to to that for the caller in my bindings and return it after nil
20:39:13  <avidal>I guess it's lua-openssl pkey.read that's actually prompting me for my passphrase since i don't see that in the lit sources
20:40:44  <creationix>yep
20:40:58  <creationix>ok, it seems this is the function to call to get the error message https://github.com/zhaozg/lua-openssl/blob/10489be021db287c9127841ab06f066d71d0df5b/src/openssl.c#L112-L133
20:41:21  <creationix>looks like it's exposed to lua at require('openssl').error()
20:41:28  <avidal>will check
20:41:36  <creationix>https://github.com/zhaozg/lua-openssl/blob/10489be021db287c9127841ab06f066d71d0df5b/src/openssl.c#L253
20:42:30  <avidal>218529960 'error:0D0680A8:asn1 encoding routines:ASN1_CHECK_TLEN:wrong tag'
20:42:31  <avidal>barf
20:43:28  <creationix>ouch
20:43:33  <avidal>yeah..
20:43:38  <avidal>but the key works fine, i use it all the time
20:43:43  <creationix>how much do you know about rsa, asn.1 and friends?
20:43:51  <creationix>you can decode your private key manually using https://www.openssl.org/docs/apps/asn1parse.html
20:43:55  <avidal>so i'm wondering if something in fs.readFile
20:44:08  <creationix>doubt it, it's just ASCII
20:44:17  <creationix>you printed the text, it was all there right?
20:44:55  <avidal>Yeah, it all looks fine
20:45:14  <creationix>PEM format is base64 encoded DER encoded asn.1 of your key struct
20:45:33  <creationix>it's strange that openssl can't read your private key
20:45:50  <creationix>though it was created with openssh, not openssl I assume
20:45:56  <creationix>`ssh-keygen`?
20:45:59  <avidal>yeah
20:46:56  <creationix>you can parse it with openssl asn1parse -in ~/.ssh/id_rsa, but don't paste me the result.
20:47:20  <avidal>don't plan on it :)
20:49:56  <creationix>here is mine with the sensitive numbers redacted https://gist.github.com/creationix/aa85a1755e801639b524
20:50:39  <avidal>Yeah I get another error. I'll get to the bottom of this
20:51:12  <creationix>good luck. I have no idea why openssl can't read your key
20:51:15  <avidal>yeah..
20:51:21  <avidal>especially because ssh works just fine
20:51:28  <avidal>although openssh !== openssl
20:52:05  <creationix>right, Their private key formats are suppossedly the same
20:52:21  <creationix>the public key formats were very different which is why I had to implement reading and writing in lua
20:52:38  <avidal>31237:error:0D07207B:asn1 encoding routines:ASN1_get_object:header too long
20:52:39  <avidal>gah
20:53:03  <creationix>as a workaround, you can create a new key, authorize it on github, and manually set ~/.litconfig to point to it
20:54:43  <creationix>all I can think of is you created the key a long time ago when openssh generated incompatible keys
20:54:52  <avidal>probably
20:54:55  <avidal>well
20:55:02  <avidal>i've only had this laptop for a hair over a year now
20:56:22  <avidal>yeah, old openssh it seems
20:56:27  <avidal>generates incompatible keys
21:00:38  <avidal>installing openssh and openssl via homebrew
21:01:31  <creationix>fwiw, I'm doing something really strange using ssh keys to do rsa signatures with openssl
21:01:42  <creationix>as far as I know, this is not very well tested waters
21:02:21  <creationix>I just figured people were more likely to have ssh keys on their machine than pgp keys
21:02:27  <creationix>also I can verify any keys using public github APIs
21:02:29  <avidal>i happen to have both
21:02:52  <creationix>I plan to support gpg as well, just haven't had time to code it yet. Finishing luvit 2.0 is higher priority
21:03:17  <avidal>guess i still need to regenerate my keypair though
21:06:13  <avidal>hmm, and i generated my gpg key for keybase.io based on my ssh key
21:06:13  <creationix>avidal: how old is your darwin version btw? I haven't had any issues using the stock openssh on my laptops. But I've only tested on pretty new machines running the latest version
21:06:21  <avidal>so i wonder if i can just upgrade my existing key
21:06:48  <creationix>you should be able to reformat it. Just back up the original
21:06:58  <creationix>ssh-keygen accepts various inputs
21:09:19  <avidal>i suppose i can just push a new public key to keybase
21:12:41  <creationix>I believe `ssh-keygen -p` will allow you to change the passphrase (thus reformatting the key)
21:14:23  <avidal>oh. my. god.
21:14:28  <avidal>(it was the wrong password)
21:15:19  <avidal>the error when running openssl asn1parse led me to believe openssl couldn't read my key
21:15:26  <avidal>instead of telling me that my passphrase is wrong
21:15:42  <avidal>put in the correct passphrase and lit auth works just fine
21:17:58  <avidal>So lit doesn't use luvit at all, just a handful of modules cherry-picked from luvit
21:18:40  <avidal>But it looks like your intention is to move a lot of those modules to possibly be external from luvit itself anyway (considering the "deps" config for lit and the fact that the modules are in modules/creationix)
21:19:04  <avidal>But then what's going to be left of luvit? :)
21:19:20  <creationix>luvit is like a distribution of luvi
21:19:20  * nachiketjoined
21:19:23  <creationix>with a node.js flavor
21:19:44  <creationix>the long-term goal is to get all the luvit modules into the lit repository where they can be consumed independently
21:19:50  <avidal>Right on
21:19:53  <creationix>I have them in the lit tree for bootstrap reasons
21:20:09  <creationix>but I often run `lit install` in the lit/app folder and then git diff to see if anything is out of date
21:20:21  <avidal>And luvit itself will pull in all of those modules (and then possibly have some bundled that aren't really consumable by themselves) and provide a reasonable main.lua that can execute your script?
21:20:21  <creationix>it will appear as reverse diffs when lit reverts my unpublished changes
21:20:47  <creationix>yep, luvit will continue to be what it was
21:20:59  <avidal>But all of its pieces will be (mostly) decomposed
21:21:07  <creationix>just packaged a little differently internally. The main goal with luvit 2.0 is to make it trivial to customize it
21:21:15  <avidal>I see
21:21:41  <creationix>some people prefer the batteries included style distribution, others want a pile of parts they can play with
21:22:03  <creationix>before I made lit, luvi already had the ability to layer apps
21:22:11  <avidal>right on
21:22:18  <creationix>you could make your app inherit from luvit and selectivly replace files (like main.lua)
21:22:47  <creationix>but the lit style is even more granular in that you only use what you explicitly include
21:24:27  <avidal>yeah i think i'm tracking this now
21:25:04  <avidal>(mostly)
21:25:07  <creationix>I think the best workflow moving forward will be to distribute lit binaries (which include the luvi framework internally)
21:25:39  <creationix>and then people can build their own custom executables with just a package.lua + whatever modules aren't in a lit repo
21:25:43  <avidal>Making lit kind of like lein
21:26:51  <creationix>this lein? https://github.com/technomancy/leiningen/
21:26:56  <creationix>never used it, but looks neat
21:27:54  <avidal>Yeah, it's kind of a bootstrapper for clojure projects. You get a project.clj that defines your dependencies, lein deals with bootstrapping clojure, updating your deps, interfacing with a local maven repository, pulling from clojars, and so on
21:28:06  <creationix>I've also considered rebranding a little. Make lit be the new luvit. and rename luvit to node.lua or something
21:28:35  <creationix>the nice thing about luvi is you don't need a compiler once you have the luvi binary
21:28:45  <creationix>(assuming your app doesn't use any native addons)
21:28:59  <creationix>but even if it does have native addons, luvi supports embedding .dll/.so files in the zip
21:29:34  <creationix>so if I ever found a sane way to publish binaries for C addons, lit could pull those in too
21:31:09  <creationix>also lit repos are trivial to host
21:31:32  <avidal>So there's still value in having a resolver for luvit-require, except you can eventually import luvit-require in your non-luvit project
21:31:33  <creationix>so if you have private modules for internal company use, you can publish them to a local lit server that also acts as a caching proxy to the public lit server
21:31:54  <creationix>and by trivial I mean `lit up && lit serve` on some lan machine
21:31:57  <avidal>yeah
21:32:23  <creationix>right, I use luvit's require in lit
21:32:34  <rch>heh "lit up"
21:32:37  <creationix>and lit is certainly not a luvit project, it's an entirely different async model
21:32:41  <avidal>although i guess luvit-require changes the semantics of require significantly enough that it's either luvit compatible or it isn't
21:33:04  <creationix>right, luvit require is very different from lua require
21:33:17  <avidal>are you concerned that people might create 'lit packages' without having a standard require implementation?
21:33:29  <creationix>but that's why the new version doesn't replace lua's require. It just shadows it with a local variable
21:33:32  <avidal>well i guess luvit-require will fall back to luaRequire
21:34:01  <avidal>And only if something is located and loaded with luvit-require will it receive luvit-require as it's require implementation
21:34:11  <creationix>good point, lit does assume luvit require
21:34:44  <creationix>if you do `lit install creationix/git` it will create `modules/creationix/git.lua` to be required with "creationix/git"
21:35:17  <creationix>and yes, only modules loaded via luvit require can see luvit require
21:35:30  <creationix>so luvit *should* be able to load luarocks modules now
21:36:49  <avidal>Ah, right right. Because even if you luvit-require(module), and module expects the regular lua-require semantics when *it* requires something, then luvit-require will fallback to lua-require, and then the rest of the modules loaded in the tree will continue to use lua-require
21:37:28  <creationix>exactly. And you can always go direct to _G.require to skip luvit-require alltogether
21:38:10  <creationix>perhaps naming it "require" was a bad idea
21:38:26  <creationix>we just wanted to port node's APIs as closely as possible when creating luvit
21:38:57  <avidal>Yeah..
21:39:00  <avidal>I get that
21:39:03  <creationix>the other option was "require" is lua-require and "load" is luvit-require
21:39:12  <creationix>or maybe not "load", but something
21:39:24  <creationix>(since load is also a lua builtin)
21:39:28  <avidal>yeah
21:40:27  * a_lejoined
21:44:36  <rje>is there an simple file write example? i'm trying to do a simple logger file appender https://gist.github.com/rjemanuele/cbf365c8d8f1a742dbb1
21:45:18  * a_lequit (Ping timeout: 265 seconds)
21:45:19  <avidal>And the issues with lua require is just that its very implicit, you can't explicitly say load module relative to here; it's always loaded relative to the current directory first (unless you change package.path)
21:46:23  <creationix>rje: why "w+"? Don't you mean "a"? https://github.com/luvit/luv/blob/1ad9f43bd7a48f6c252ce87938bacd47d37d39f1/src/fs.c#L124
21:46:42  <avidal>and it also doesn't support loading from within the luvi bundle
21:46:44  <creationix>avidal: right, it depends too much on global system state
21:46:59  <creationix>I prefer my intra-package requires to be system independent
21:47:08  <avidal>yep
21:48:43  <creationix>well, luvit's require is extensible. I think I could add on a loader to read from the luvi bundle
21:48:51  <creationix>the main reason to rewrite was to get relative requires
21:49:17  <creationix>it's impossible with lua's system since path resolve isn't as configurable and doesn't have caller path as one of the inputs
21:50:30  <avidal>So the issue arises when you require a regular lua module which requires another module that lives next to it, but the other module's name clashes with a 'builtin'.
21:51:12  <avidal>easy example would be a lua module that contains `require('stream')` to mean stream.lua which sits next to the main module file
21:52:04  <avidal>yeah that sucks :)
21:53:15  <avidal>and yeah it's clearly impossible to support both 'systems', universally
21:54:20  <avidal>although maybe luvi/lit modules should require regular lua modules using a specific prefix? and those would immediately fallback to native require?
21:55:12  <avidal>i mean the problem (seems) to exist solely at the boundary where modules intended to be consumed by luvit-require also include things from luarocks or regular lua scripts
21:55:23  <avidal>Oh, yeah, I guess those modules can just be told to use _G.require
21:57:03  * a_lejoined
21:59:50  <avidal>and i guess native require also uses dot syntax for paths
22:02:18  <avidal>Oh, my mistake. It's never relative and always absolute.
22:05:10  <avidal>So how the hell are regular modules distributed (sans luarocks)? How can they possibly know what the absolute path to their own location is?
22:06:28  <rphillips>creationix: yes, manually adding collaborators would be a win i think
22:06:41  <rphillips>sorry, I had to get to this appointment for my son
22:07:45  <creationix>avidal: exactly
22:08:02  <avidal>Damn. I knew lua modules were fucked, but I guess I didn't realize how bad
22:08:40  <avidal>Solution to loading a module that exists next to the current module file:
22:08:41  <avidal>package.path = debug.getinfo(1,"S").source:match[[^@?(.*[\/])[^\/]-$]] .."?.lua;".. package.path
22:08:42  <avidal>require("foo.bar")
22:09:08  <avidal>don't get me wrong, I think lua is fantastic, but this is horseshit :)
22:09:45  <creationix>now you see why I reimplemented a node-style require resolve
22:09:51  <avidal>yeah...
22:10:04  <rje>creationix: oops, i did want 'a' but i'm getting an assert at Assertion failed: 0, file c:\users\rje\documents\rackspace\luvi\deps\luv\libuv\src\win\handle-inl.h, line 159
22:10:12  <creationix>and finally found a way to fallback to normal require for existing lua code
22:10:25  <avidal>yeah
22:10:58  <avidal>So it just needs to be very very clear to users that if they are going to include normal lua/luarocks packages they should probably just use _G.require in the first place
22:14:18  <creationix>probably a good idea
22:14:27  <creationix>name conflicts could easily happen
22:14:38  <avidal>yeah
22:15:06  <creationix>rje: strange
22:15:27  <avidal>Maybe luvit-require can support rock: as a prefix and use the luarocks loader, if available
22:15:53  <rje>creationix: its got something to do with the write
22:19:19  <rphillips>avidal: i like that idea
22:20:02  <creationix>rje: hmm, where is your offset for write
22:20:08  <avidal>And then maybe it's every man for himself if you want to load lua modules that aren't available via lit or luarocks
22:20:15  <avidal>(ie, use _G.require)
22:20:56  <creationix>rje: pass -1 for implicit offset. I just forward the integer through to libuv https://github.com/luvit/luv/blob/master/src/fs.c#L348
22:21:02  <creationix>I think that's the proper way to append
22:21:18  <avidal>i mean in those cases you'd likely just drop them into your source tree anyway and then you can freely change the require usage
22:23:22  <creationix>hmm, I need to add vector support to uv.fs_write like I did for uv.write (vector being a table of strings)
22:24:16  <rje>creationix: oh, i see
22:24:27  <rje>creationix: thanks
22:31:16  <rphillips>rje: https://github.com/rphillips/virgo-logging
22:31:36  <rphillips>would be sweet to get your file logger into this
22:31:49  * not^vjoined
22:34:54  <rje>rphillips: i'm also looking at writing a windows logger
22:35:12  <rphillips>sweet
22:37:01  <avidal>maybe this endeavor is pointless and lit should adopt luvit-require as the only hard dep, with lit users republishing rocks (and other vanilla lua modules) after making them luvit-require compatible
22:37:08  <avidal>because it's a Hard Problem
22:38:08  <avidal>so i'll instead just focus on adding require.resolve and require.cache to luvit-require
22:38:13  <avidal>because those are attainable :)
22:38:18  <creationix>I'm happy with the current situation. _G.require is available and is the fallback. That's good enough for me
22:38:26  <creationix>yep
22:38:28  <avidal>Sounds good
22:38:54  <avidal>Modest me, thinking I could solve the single biggest "problem" with luvit since it launched :)
22:39:56  <avidal>anyway, time for me to head home. I'll try hacking on require.resolve a bit more and get a PR in
22:44:29  * avidalquit (Ping timeout: 252 seconds)
22:47:18  * avidaljoined
22:47:49  <avidal>our transit system shouldn't be legally allowed to say this train has wifi
22:47:57  <avidal>because it's shit
22:55:52  <rphillips>rje: i was thinking of for the log feature of the svc manager stuff, to set a noop function called log() and just let it be setable by the user
22:56:11  <rphillips>exports.setLogFunction(p)
22:57:13  <rphillips>log('some message')
23:25:29  * avidal__joined
23:25:53  * avidalquit (Ping timeout: 240 seconds)
23:35:53  * avidal__quit (Read error: Connection reset by peer)
23:39:29  * avidaljoined
23:39:44  * avidalquit (Client Quit)
23:48:04  * not^vquit (Ping timeout: 265 seconds)
23:56:56  * DarkGodquit (Ping timeout: 264 seconds)
23:57:45  * dan336quit (Quit: Leaving.)