01:54:12  * rgrinbergquit (Ping timeout: 240 seconds)
03:11:00  * rgrinbergjoined
04:15:54  * rgrinbergquit (Ping timeout: 276 seconds)
04:43:35  * SkyRocknRolljoined
06:18:40  * rendarjoined
09:36:19  * SkyRocknRollquit (Remote host closed the connection)
12:15:48  * rgrinbergjoined
14:03:16  <urzds>creationix: Yes, it is a package that I want to publish to lit. I assumed lit packages need an init.lua file, which lit would use as the deps/my-package.lua file when installed into other projects. But it appears to be able to publish the contents of all of libs/, too.
15:31:31  <creationix>urzds, so lit has either single-file packages or folder packages
15:31:50  <creationix>with single-file, you just embed the metadata in a comment at the top. Most the luvit and lit internal packages are like this
15:32:08  <creationix>with multi-file, you need package.lua (though it might try to also pull metadata from init.lua)
15:32:20  <urzds>But in the single-file case I cannot run tests, because I have no way of loading the module from my own tree, is that correct?
15:32:42  <creationix>I have no way of running your tests (me being the lit server)
15:32:44  <creationix>but you can
15:32:56  <urzds>How?
15:33:08  <creationix>just put the file in `libs/foo.lua` or `deps/foo.lua` and then in `tests/mytest.lua` just `require 'foo'`
15:33:24  <creationix>and when you publish, just `lit publish libs/foo.lua` directly
15:33:43  <creationix>or as I do, `lit publish deps/*` since I put all my public packages in deps and all my private ones in libs
15:34:16  <urzds>I thought deps/ is reserved for lit - that'd be where it installs all the dependencies into?
15:34:29  <creationix>it's used by lit, yes
15:34:40  <creationix>but it does try hard to not overwrite anything you put there manually
15:34:51  <creationix>but libs works just as well
15:34:53  <urzds>But you suggested to rm -fr deps/ to update...
15:35:11  <creationix>yes and that's what I do in my workflow
15:35:20  <creationix>everything in deps is published to lit
15:35:29  <creationix>so when I delete it and re install, they come back
15:35:50  <creationix>if the new file is older than what I had before (since I do commit deps to git in this workflow), I can see it
15:35:59  <creationix>that means I forgot to publish an update for that package
15:36:00  <urzds>But the package itself cannot be put into deps/ then, because if you wanted to update its dependencies, you'd also delete your own source code...
15:36:37  <creationix>maybe we're not talking about the same thing
15:36:38  <urzds>And if you did not commit to git, you'd be screwed...
15:36:58  <urzds>Since all the changes that you made are gone.
15:37:20  <creationix>true, I commit before nuking
15:37:28  <creationix>but let's step back, what are you trying to do?
15:37:52  <urzds>I have a very tiny lit package that is just one file big, which I want to test.
15:38:15  <creationix>the suggested workflow is as you assume, put deps in gitignore and only use it for third-party lit published dependencies
15:38:28  <creationix>right, so in that case, I just put it on the root of my repo
15:38:41  <creationix>and require it as `../foo` or `./foo` depending on where the tests are
15:38:51  <creationix>but don't name it init, name it the name of the package
15:39:00  <urzds>As I understood, I'd put the one file into libs/ and instead of running "lit publish" I'd run "lit publish libs/*"?
15:39:21  <creationix>putting it libs just puts it in the global search path, it's not required
15:39:26  <urzds>Ok, that's another way.
15:40:01  <creationix>so `/foo.lua` is your package, that folder will also have `/README.md` and `/test-foo.lua` if you have just one test file
15:40:08  <creationix>or `test/*.lua` for multiple tests
15:40:12  <creationix>or something
15:40:25  <urzds>k
15:40:25  <creationix>(the README would be just for github as it won't publish to lit
15:40:48  <urzds>But lit will publish according to the metadata in the file itself, not based on the filename?
15:41:00  <urzds>In that case I can also get rid of package.lua...
15:41:03  <creationix>right
15:41:14  <creationix>the filename should match the last part of the metadata name
15:41:31  <creationix>because your tests will need to use the path to the filename and people using your library will use the metadata name
15:45:11  <urzds>Irks: tests/run.lua:25: bad argument #1 to 'fs_scandir_next' (uv_req expected, got nil)
15:45:34  <urzds>I am using the example run.lua file.
15:46:10  <urzds>It does not expect that req might be nil if the tests/ directory does not exist.
15:47:33  <creationix>that's using the bundle API right?
15:47:55  <creationix>if so sounds like a bug
15:48:02  <urzds>creationix: I don't even have to modify test-date.lua - I can still require("date") after moving the latter out of libs into the root of the repository. Is that just by chance, or can I rely on this behaviour?
15:48:31  <creationix>the root is not in the search path
15:48:36  <creationix>something is up
15:48:45  <urzds>creationix: No, it's this file: https://github.com/luvit/luvit/blob/master/tests/run.lua
15:48:50  <creationix>(though come to think of it, why didn't I add the roots into the path?)
15:49:12  <urzds>creationix: Could this be an interaction with LUA_PATH that was set by luarocks?
15:49:36  <creationix>perhaps, it is supposed to fallback to native require
15:49:38  <urzds>No, can't be.
15:50:03  * rgrinbergquit (Ping timeout: 240 seconds)
15:50:06  <urzds>./ or ../ or similar are not in LUA_PATH.
15:50:50  <creationix>the default package.path has `./?.lua` as the first path
15:50:59  <creationix>but not ..
15:51:34  <urzds>It seems to work for any number of "./" or "../" that I put before "data" in the call to require...
15:51:55  <urzds>require("../../date") == require("../date") == require("./date")
15:52:36  <urzds>... put before "date"
15:56:04  <urzds>It even works if I require "..../date".
15:56:15  <urzds>Literally. Four dots.
16:00:13  <urzds>creationix: Is that somehow expected, or did I mess something up?
16:02:07  <creationix>that's strange
16:02:11  <creationix>which require are you using?
16:02:21  <urzds>The default require that I get in luvit...
16:02:26  <creationix>weird
16:02:44  <urzds>This is the code: https://github.com/urzds/luvit-date
16:03:25  <urzds># mv libs/date.lua .
16:03:30  <creationix>looks like a bug in require
16:03:47  <urzds>And put the contents of package.lua into date.lua, and then you have the exact same state as I have.
16:04:17  <creationix>or lua's require is doing something funly
16:04:42  <urzds>LUA_PATH="${HOME}/.luarocks/share/lua/5.1/?.lua;${HOME}/.luarocks/share/lua/5.1/?/init.lua;${HOME}/.local/share/lua/5.1/?.lua;${HOME}/.local/share/lua/5.1/?/init.lua;./?.lua;/usr/local/share/lua/5.1/?.lua;/usr/local/share/lua/5.1/?/init.lua;/usr/local/lib/lua/5.1/?.lua;/usr/local/lib/lua/5.1/?/init.lua;/usr/share/lua/5.1/?.lua;/usr/share/lua/5.1/?/init.lua"
16:04:45  <creationix>change date to something wrong and look at the stack trace
16:04:57  <creationix>require('..../date2'), for example
16:05:28  <urzds>Then it starts to look into this location, e.g. $HOME/.luarocks/share/lua/5.1////////////datex.lua
16:05:48  <creationix>yep, it's stripping the leading dots
16:05:52  <creationix>that's why 4 works
16:06:06  <creationix>those "no file" lines in the stack trace are from native require
16:06:08  <urzds>It replaces dots by /
16:06:19  <creationix>and luvit currently doesn't use it, but only as a fallback if it can't find the module
16:06:35  <urzds>Ah, I get it.
16:06:47  <creationix>I've switched everything else over to the lit-loader require system that just adds a new loader to native require, but it would be a breaking change to do it for luvit
16:06:53  <creationix>the semantics are slightly different
16:06:53  <urzds>So I can require"foo.bar" and get foo/bar.lua
16:07:14  <urzds>What is "everything else"?
16:07:19  <creationix>right, just be aware of the limitations of luvit's native require. Those paths are relative to cwd, not the file calling require
16:07:28  <creationix>lit itself and all the projects I make with luvit
16:07:41  <creationix>^ (those are everything else)
16:08:04  <creationix>here is the require system for lit https://github.com/luvit/lit/blob/master/luvit-loader.lua
16:08:08  <urzds>So can I make my lib use that lit-loader and it will be more sane?
16:08:09  <creationix>it's just a plugin into native lua require
16:08:38  <creationix>yes, but if you're still using `luvit` the CLI tool to run your program, then luvit's require will still get injected
16:08:53  <creationix>though someone has made a version of the luvit cli tool that removes all the opinoins
16:08:57  <creationix>it's really nice and clean
16:09:49  <creationix>https://github.com/squeek502/luver
16:09:59  <creationix>the `luvit` cli tool is legacy, it's the node.js clone
16:10:12  <creationix>I'm just not sure how to rename things since the project itself is called "luvit"
16:10:43  <creationix>notice that he uses luvit-loader instead of the node-clone require in luvit https://github.com/squeek502/luver/blob/master/deps/luvit-loader.lua
16:12:54  <creationix>he's not done with it yet and so it's not published to lit, but you can build it directly from github
16:12:55  <creationix>lit make github://squeek502/luver
16:13:12  <creationix>then `./luver yourapp/entry.lua`
16:13:41  <urzds>luvit is legacy? I thought the whole point of luvit was to have a node.js clone?
16:15:40  <creationix>it was
16:16:02  <creationix>but after 5 years there was virtually no interest in a node clone in lua
16:16:17  <creationix>but there is a lot more interest in something node-like, but adapter for lua's strengths
16:16:23  <creationix>*adapted
16:16:30  <urzds>Ah, ok.
16:16:38  <urzds>As long as it is well documented...
16:17:00  <urzds>That was nice about luvit initially - it would (almost) work, if you followed the node.js docs.
16:17:16  <creationix>right, that's why the legacy luvit interface is still maintained
16:17:27  <creationix>it's even installed by default when you do `lit update`
16:17:36  <creationix>and rackspace still uses it heavily internally
16:17:48  <creationix>but almost all new development is in the lit and luvi based stuff
16:19:07  <urzds>In lit publish, with --[[lit-meta, how do you get all the values? Do you simply grab them from _G?
16:19:38  * rgrinbergjoined
16:19:46  <urzds>I tried to copy my stuff from package.lua, stripping the surrounding table, but got bitten by the trailing ,
16:22:02  <creationix>https://github.com/luvit/lit/blob/d80d38407a9234988f2d70d49275b6eead120f9b/libs/pkg.lua#L36-L83
16:22:47  <creationix>yeah, it evals the string and then returns the resulting global table
16:22:56  <creationix>(evals in a new environment with empty global)
16:25:25  <urzds>Is the exports field in any way special?
16:26:53  <urzds>What's nice about naming it init.lua is that I can do lit publish, without knowing the filename.
16:35:42  <jpleau>creationix: what versions of Lua did you use when running tests on arm64? luajit?
16:38:27  <creationix>jpleau yep
16:38:41  <creationix>didn't try anything other than the official luvi binary
16:39:13  <creationix>this was all I needed to add to our luajit cmake file https://github.com/luvit/luv/commit/e4f2a80b7f7a3ffcddbbaed8fa002a3989c9a9f6
16:39:27  <jpleau>okay. I'm still waiting access to arm64 machines on debian architectures, we have tests failing /hanging on arm64 with lua5.2 (probably happens with other versions, it's just the first one that gets built)
16:39:42  <jpleau>I'll be able to debug it in a few days
16:42:39  <creationix>I was using an odroid C2 running ubuntu 16.04 for my tests, you can get one fairly cheap
16:43:32  <creationix>http://ameridroid.com/products/odroid-c2
16:43:49  <creationix>it's the same CPI as the PI3, but clocked faster I think
16:43:52  <creationix>*CPU
16:44:40  <jpleau>I'm not certain I'm willing to buy, I already have a rpi2 that I bought the day it came out, it's still unboxed :P
17:28:00  <urzds>creationix: Do you have a nice way to automatically publish from CI? Is it possible to pass Lit a GH personal access token via an env var?
17:28:36  <creationix>lit publishes by signing using your ssh private key as an rsa key
17:28:49  <creationix>so you just need to give the CI server an SSH key that you've authorized with your github account
17:29:21  <creationix>there are environment variables for custom paths to a lit config file which can then have a custom path to the key
17:29:23  <urzds>Hm... Has anyone done that with Travis before?
17:29:46  <creationix>but I could add a feature to pull the key directly from env (assuming it's not too large)
17:29:51  <creationix>not that I know of
17:30:10  <urzds>But in any case: The purpose of a signature is probably that not anyone can sign my packages - so I'd have to trust the CI system...
17:30:20  <creationix>obviously
17:32:00  <urzds>Thus I shouldn't actually push my Docker container images with Travis, either...
17:32:26  <urzds>I'll think about that... Thanks for the advice.
17:32:39  <creationix>trust-less systems are very hard. I've designed a few and in the end, you always have to have someone or something you trust
17:33:20  <creationix>I wonder if I could add another way to authenticate people on publish. SSH keys have full access
17:33:28  <creationix>while github tokens could be more limited
17:33:40  <APNG>hi creationix
17:33:45  <creationix>APNG hi
17:34:20  <APNG>uh can you help me with a thing? it's js tho...
17:36:15  <APNG>creationix, any idea about this? http://stackoverflow.com/questions/25456794/does-javascript-have-a-standard-equivalence-method-you-can-define-on-your-own-ob
17:36:43  <creationix>APNG if JS does have that, it will be part of the Proxy interface
17:37:22  <creationix>doesn't look like there is a trap for equivalence https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Proxy
18:13:45  * rendarquit (Ping timeout: 276 seconds)
18:42:50  * rendarjoined
18:59:23  * rgrinbergquit (Ping timeout: 244 seconds)
19:09:58  * rgrinbergjoined
22:46:15  * rendarquit (Quit: std::lower_bound + std::less_equal *works* with a vector without duplicates!)