00:52:20  * dan336joined
01:23:39  * UniOnquit (Remote host closed the connection)
01:40:09  * a_lequit (Remote host closed the connection)
01:48:08  * blessYahujoined
01:54:23  * DarkGodquit (Ping timeout: 256 seconds)
02:14:39  * dan336quit (Quit: Leaving.)
02:41:47  * a___quit (Remote host closed the connection)
02:43:09  * a__joined
03:40:44  * a_lejoined
05:21:15  * blessYahuquit (Ping timeout: 244 seconds)
08:11:44  * DarkGodjoined
11:21:12  * torporjoined
11:47:21  * UniOnjoined
12:37:50  * torporquit (Quit: Leaving.)
14:38:26  <avidal>For example, each ternary expression (?:) generates 4 function calls and a closure - too lazy to implement anything more clever :)
14:38:29  <avidal>nice :)
14:59:59  <creationix>good morning all
15:00:28  <creationix>I hope everyone had a great weekend. I got to spend lots of time taking care of a sick toddler while my wife took care of the new baby
15:05:15  <avidal>Don't get me wrong, I love my son, but one is enough for me :)
15:08:30  <creationix>I love my kids, not complaining at all. Just keeps me busy
15:13:08  <rphillips_>good morning
15:19:18  * rphillips_changed nick to rphillips
15:27:09  * dan336joined
15:27:16  * rphillipsquit (Changing host)
15:27:16  * rphillipsjoined
15:42:03  * endou______quit
15:42:22  * endou______joined
16:04:08  <rphillips>creationix: i have virgo-base layed out like this https://github.com/virgo-agent-toolkit/virgo-base-agent/tree/luvi-up
16:04:19  <rphillips>i want to add this project to lit
16:04:51  <rphillips>looks like lit add in the main project wants the project.lua in the root of the tree
16:04:51  <creationix>which files need to be in the package?
16:05:23  <rphillips>perhaps I should refactor the packaging scripts into a different lit project
16:05:37  <rphillips>virgo-packaging
16:06:37  <creationix>currently lit is optimized towards tiny packages with the minimal files published
16:07:12  <creationix>if I were to publish lit or luvit, I would `lit publish app`
16:07:25  <rphillips>k
16:07:45  <creationix>maybe we should define a webpage property to point to the github repo for the full set of files and README
16:08:06  <creationix>when we get around to making a lit http frontend that will make showing docs easier
16:08:20  <rphillips>yeah, that would be nice
16:08:40  <creationix>npm has some defacto properties right? like “repo” and “homepage” I think
16:11:41  <rphillips>looks like it's repository
16:11:41  <rphillips>homepage exists
16:14:30  <creationix>I see, npm assumes github for “repository” like “strongloop/express”.
16:14:33  <creationix>https://github.com/strongloop/express/blob/master/package.json
16:14:53  * travis-cijoined
16:14:53  <travis-ci>luvit/luvit#1485 (luvi-up - 1de79f0 : Ryan Phillips): The build passed.
16:14:53  <travis-ci>Change view : https://github.com/luvit/luvit/compare/50ea52c2d674...1de79f0297e6
16:14:53  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/48360155
16:14:53  * travis-cipart
16:15:46  * DarkGodquit (Quit: Leaving)
16:18:48  <rphillips>creationix: are all these deps on github? https://github.com/luvit/lit/blob/master/app/package.lua
16:19:04  <creationix>yes, but not in their own repos
16:19:12  <creationix>the lit repo *is* their source tree
16:19:25  <rphillips>ah hah
16:22:01  * imzyxwvujoined
16:22:53  <imzyxwvu>i see luv directly pass the string buffer inside Lua VM to the uv_buf_t for uv_write. https://github.com/luvit/luv/blob/master/src/stream.c#L165
16:23:02  <imzyxwvu>i talked with libuv contributors and they said the buffer for uv_write can only be freed after the callback is called.
16:23:30  <imzyxwvu>so does it matter if Lua GC recycles the string before the the callback is called?
16:23:36  <rphillips>afaik, we ref the data buffer
16:23:40  <rphillips>creationix: ?
16:26:05  <rphillips>imzyxwvu: https://github.com/luvit/luv/blob/master/src/stream.c#L176
16:26:39  <creationix>yeah, it should be good. The luv unit tests gc like crazy to work out that kind of bugs
16:26:59  <creationix>the only open question I still have is if doing longjmp inside uv_run is safe
16:27:21  <creationix>I never got an answer from #libuv and looking at the code, it *seems* safe. Plus I’ve never had any issues with it
16:27:52  <avidal>if i wanted to help with luvit 2.0 (which i guess comprises luv, luvi, luvit, and lit?) where should I start? (note, i'm not very good with C)
16:27:52  <imzyxwvu>longjmp seems not often used
16:29:58  <imzyxwvu>but lua used it everywhere as a solution for the expection system. libuv documents didn't say anything about longjmp. (this is what i could expect because it is hardly used)
16:31:02  <creationix>imzyxwvu: I wouldn’t think it’s much different than nesting uv_run calls which I also do a lot without issue
16:31:23  <creationix>the inner call blocks the outer loop and mutates the same global state
16:31:43  <creationix>(assuming there is any state in uv_run other than program counter)
16:32:36  <imzyxwvu>but libuv documents didn't say uv_run is longjmp-safe, so I think using pcall to call callbacks is safer.
16:33:41  <imzyxwvu>I readed libuv uv_run code too and didn't find anything that seems to be unsafe for longjmps, but if libuv changed later, it might become unsafe
16:34:19  <creationix>right, it *seems* safe for now. More important to me is the error handling semantics of luv
16:34:34  <creationix>I sometimes see cases where lua exceptions silently go away
16:34:51  <imzyxwvu>for example, if it allocated some memory before a callback and free them after a callback, and the callback long jumped, there would be a memory leak bug.
16:35:33  <creationix>imzyxwvu: yes, but libuv will later call your callback in another uv_run
16:37:49  <imzyxwvu>what did you mean? what does that another uv_run refer to?
16:38:15  <imzyxwvu>i said lua_pcall would add some difficulties when debugging because it didn't collect stack traceback. later i found i was wrong. it just didn't do that but it can do that.
16:39:40  <creationix>if lua does a longjmp inside uv_run, then either the process will exit or some code will catch the lua “exception”
16:40:02  <creationix>in all cases in luvit, when I catch the lua exception, I call uv_run again to resume the event loop
16:40:17  <creationix>(or I had uv_run nested inside another which has the same effect)
16:40:52  <creationix>one idea I had is to add an error handling callback to uv.run()
16:41:12  <creationix>but then, what if there is an error in that callback?
16:41:16  * travis-cijoined
16:41:17  <travis-ci>luvit/luvit#1487 (luvi-up - 02aaff5 : Tim Caswell): The build passed.
16:41:17  <travis-ci>Change view : https://github.com/luvit/luvit/compare/1de79f0297e6...02aaff56ca03
16:41:17  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/48363527
16:41:17  * travis-cipart
16:41:20  <creationix>any lua code *can* crash
16:41:28  <imzyxwvu>just like process.on('error') ?
16:41:38  <creationix>more or less
16:41:49  <creationix>except uv.run is explicit in luv and implicit in node
16:42:52  <imzyxwvu>i have a solution: if there is an lua error in the error handler, also catch it and stop the libuv uv_run with an api. then rethrow it after uv_run returns.
16:43:20  <imzyxwvu>but it is ugly... i think.
16:43:29  <creationix>not to mention tricky to implement
16:44:47  <imzyxwvu>so could we ask the libuv people to keep uv_run longjmp-safe?
16:45:24  <creationix>that should be fine. It’s not my main concern
16:46:09  <imzyxwvu>so what's the main concern?
16:47:01  <creationix>I want sane error handling at the lua level. I’m not concerned about libuv getting into some invalid internal state
16:48:35  <creationix>I’m 95% sure uv_run is longjmp safe and will stay that way. if you want to get them to support that, that’s fine
16:49:50  <imzyxwvu>i would talk with them later about this.
16:51:01  <imzyxwvu>actually not just longjmps... C++ expections might also jump out of uv_run.
16:51:29  <creationix>true, all the more reason for them to support it
16:51:55  <imzyxwvu>i will go to #libuv to ask them about this.
17:26:52  * imzyxwvupart
17:33:48  <rphillips>creationix: specifying the luvi/luvit version would be interesting...
17:34:06  <rphillips>in the monitoring agent i'll need to package the luvit files as a layer
17:34:12  <creationix>good idea
17:34:30  <creationix>luvi is semver more-or-less
17:34:49  <rphillips>so I have virgo-base checked into lit
17:34:58  <creationix>nice
17:35:12  <creationix>what did you think of my idea to distribute lit binaries instead of luvit binaries
17:35:21  <avidal>please make a luvit.io/get-lit.sh :)
17:35:29  <rphillips>the project has a deps/ folder with the pin for luvit
17:35:45  <creationix>and add a lit command to read a package.lua and build a binary?
17:35:49  <rphillips>+1000
17:36:25  <rphillips>package_type: "luvit" or "luvi"
17:36:47  <creationix>like lib vs app?
17:37:05  <rphillips>right... but it'll need to be smart enough to grab the luvit layer as well
17:37:23  <creationix>well my plan was to put all of luvit in lit and not use the layering system
17:37:34  <rphillips>that works
17:37:54  <creationix>it’s a different style for sure, but I prefer it personally
17:38:04  <rphillips>should work well
17:38:13  <creationix>then luvit could be a meta-package of node.js apis for lit
17:38:30  <creationix>possibly renamed to node.lua (or io.lua)
17:38:41  <rphillips>yeah
17:39:17  <avidal>So luv has no deps (other than libuv and lua); luvi has only a dep on luv; lit is used to manage packages and build binaries (does it use luvi to make the binaries, or is that part of luvi moved to lit?) and comes with the require system
17:39:39  <creationix>luvi has some C deps, depending on the flavor
17:39:48  <creationix>miniz is bundled always, zlib, openssl, etc are optinoal
17:40:05  <creationix>though lit requires openssl
17:40:10  <avidal>miniz is used to make the archive that's sideloaded into the generated binary right?
17:40:16  <creationix>so anything lit based will have the fat version of luvi
17:40:37  <creationix>right, miniz was there before zlib
17:41:06  <creationix>if miniz wasn’t so tiny, I’d be motivated to deduplicate functionality when zlib is enabled
17:41:06  <rphillips>looks like the lua-openssl guy things the multi ssl:read() may be a bug on his side
17:41:12  <avidal>And I'm guessing the expectation is that lit could be used to manage and resolve modules for standard lua/luajit projects?
17:41:43  <creationix>avidal: only if they use lit’s require system (aka luvit’s require system)
17:42:23  <creationix>but that’s something that could be done. I could make the require library use lua’s internal I/O instead of libuv
17:42:31  <creationix>it’s blocking I/O already anyway
17:42:33  <avidal>When you use lit to install deps they just get dropped into ./modules after reading from the local litdb?
17:42:46  <creationix>avidal: right, but it’s two-layer
17:43:04  <creationix>so `lit install creationix/git` drops modules/creationix/git.lua (since git is a single-file module)
17:43:52  <creationix>technically, you could put any language module in there as long as your require system knows to look in modules/*/*
17:43:59  <avidal>Right, but as long as I have the lit loader installed before requiring creationix/git..yeah
17:44:03  <creationix>just like people use npm for non node modules
17:44:20  <avidal>So you could `lit install creationix/git` and then just use lua5.1 if you first register the lit-loader
17:44:23  <creationix>“modules” is more portable than “node_modules"
17:44:24  <creationix>;)
17:44:46  <creationix>well, since creationix/git doesn’t have any recursive dependencies, you don’t even need a custom require
17:45:00  <creationix>just need to add modules/creationix to your lua path and require(“git”)
17:45:00  <avidal>local git = require('modules.creationix.git'), yeah
17:45:04  <creationix>or that
17:45:05  <avidal>or what
17:45:07  <avidal>shit
17:45:08  <avidal>or that i meant
17:45:27  <creationix>probably just add modules
17:45:33  <creationix>then the require will match what lit expects mostly
17:45:51  <creationix>and since lit will be a self-contained binary, it will be easy to distributed
17:45:53  <creationix>*distribute
17:45:56  <avidal>so ultimately what i'm getting at, is that should package.lua have an engine(s) property that dictates if it requires running inside luvi? I suppose modules should be completely oblivious to the runtime, in general
17:46:24  <creationix>right, I’m fine if a module specifies a semver range for luvi.
17:46:47  <avidal>So lit itself might be packaged via luvi into a binary, but using lit to manage packages for non-luvi projects is as simple as registering the lit-loader
17:46:48  <creationix>but lit has no idea how you will use the files written to disk, so it can’t check that
17:47:11  <creationix>avidal: yep, that would work too
17:47:35  <creationix>what I don’t want to do is only allow installing packages who’s engine matches the luvi embedded in lit
17:47:38  <avidal>It helps me to identify the boundaries between the four projects
17:47:42  <avidal>right
17:47:51  <creationix>the luvi version in lit doesn’t matter, it could be written in go for all I care
17:47:55  <avidal>right
17:48:14  <creationix>it only matters for making new luvi apps since the binary part of the payload is in lit
17:48:25  <avidal>but the lit loader could scan engines when you require a package
17:48:36  <creationix>loader, yes
17:49:15  <creationix>so lit has two coupled, but separate halves
17:49:21  <avidal>yeah
17:49:23  <creationix>one if the CLI binary, the other is the require library
17:49:38  <avidal>Could use a write up :)
17:49:49  <avidal>Although I *might* know enough about it now to make a first pass
17:50:05  <creationix>avidal: feel free to create a wiki page on luvit/lit. I think it’s open access
17:50:19  <creationix>and/or file issues for features you want me to implement
17:50:37  <avidal>probably gist it at first to make sure I understand the intention but yeah, i'd love to
17:50:55  <avidal>Because all of this collectively leads to luvit 2.0, no?
17:55:27  <creationix>right
17:55:39  <avidal>k
17:55:45  <avidal>I might draft something up and ask itc for a review
17:56:24  <creationix>my two goals with luvit 2.0 are:
17:56:25  <creationix>1. update deps (luajit, libuv, etc..) and node APIs
17:56:26  <creationix>2. make custom versions and cherry-picking trivial and encouraged
17:56:38  <creationix>luv and luvi solve the first part of #1
17:56:51  <creationix>the new lua code we’re writing now solve the second half of #1
17:57:15  <creationix>#2 is why lit exists and why the luvi system is so unique
17:57:48  <creationix>so it sounds like “luvit” will eventually be a pure metapackage of lua abstraction on top of luvi
17:59:07  <avidal>Right, use luvi to generate a binary that includes the node.js API style lua modules that rely on luv. The end result is a binary that can then execute your own scripts that can require the bundled lua modules contained in luvit, bundled by luvi
18:00:34  <creationix>yep, the luvit binary will work much like before
18:00:42  <creationix>but it will be much easier to build and customize
18:00:52  <avidal>So luvit becomes an engine, like lua5.x and luajit. Some modules in lit are luvit compatible, some aren't (although lua compatible implies luajit compatible which implies luvit compatible)
18:01:36  <creationix>I think more platform than engine
18:01:43  <avidal>right on
18:01:45  <creationix>v8 is an engine, the web is a platform
18:03:03  <avidal>i was thinking of it describing a base layer of stdlib modules you can reasonably expect
18:03:39  <creationix>right. When writing browser libraries in JS, you assume very different deps than node libraries
18:04:05  <creationix>luvit libraries will assume streams and event emitters and other concepts
18:05:47  <avidal>will installing things via lit that have their own deps install them in a dep-local modules folder as well?
18:06:02  <creationix>no, lit keeps it flat
18:06:11  <avidal>k
18:06:14  <creationix>though the lit loader supports nested
18:06:36  <creationix>lit will warn if you have conflicting deep dependencies and install the newer verison
18:07:09  <creationix>if you *really* want and need incomptable versions, you can manually install them using nesting since the loader supports it
18:08:08  <avidal>Is the loader you've pulled into lit the same as the one currently in luvit@luvi-up?
18:08:16  <avidal>I know it was to start with
18:08:18  <creationix>should be
18:08:19  <avidal>but i'm curious if it's mutated
18:08:30  <creationix>I try to keep the modules in both projects in sync
18:08:41  <creationix>http-codec, for example changed a lot recently and I had to update both
18:09:00  <avidal>yeah i see that
18:09:07  <creationix>once luvit has been lit-ized I can stop duplicating it
18:09:33  <avidal>alright
18:44:51  * Michalik_quit
18:45:07  * Michalik_joined
18:45:38  * hdmsjoined
19:19:58  <avidal>This is what I understand of the overarching goals of luvit 2.0 (incl luv, luvi, and lit)
19:19:59  <avidal>https://gist.github.com/avidal/1dd5ed35d51f5f976a91
19:20:39  <rch>neat
19:41:51  <creationix>avidal: require is not bundled by luvi, but will be inside lit and available in the lit public repository
19:42:26  <avidal>What I mean is that using luvi to generate a bundle, will (should) luvi stick the loader within the bundle as well?
19:43:33  <creationix>not automatically
19:43:34  <avidal>Although I guess a luvi user could lit install lit-loader and then manually require lit-loader in main.lua to bootstrap
19:43:40  <creationix>it’s a dependency just like any other
19:44:22  <creationix>since luvi apps have to manually bootstrap in their main.lua there isn’t much luvi can do when bundling
19:45:23  <avidal>Right
19:45:39  <avidal>I suppose luvit@luvi-up does that in main.lua anyway, requiring the loader as a dep
19:46:20  <creationix>commented https://gist.github.com/avidal/1dd5ed35d51f5f976a91#comment-1380584
19:46:38  <avidal>yeah, roger
19:47:05  <creationix>it’s all fairly minimal and explicit, but I think that’s better at this layer
19:47:16  <creationix>you can add as much opinion and convention as you please in your custom luvi/lit app
19:47:22  <avidal>right, right
19:53:31  <avidal>updated
19:53:47  * dan336quit (Quit: Leaving.)
20:03:31  * dan336joined
20:03:34  * dan336quit (Client Quit)
20:39:45  * dan336joined
21:10:09  <avidal>hmm, i guess i should expand and say that lit loader requires luv
21:11:48  <creationix>avidal: well, I’m pretty sure that can be changed
21:11:53  <creationix>but yes, it currently requires luv
21:12:19  <creationix>actually, currently lit-loader requires luvi’s bundle and luv
21:12:28  <creationix>the bundle dep is required to support loading from bundles
21:12:39  <avidal>yeah, but the luvi bundle can be extracted out and passed in as an additional `reader` in options
21:12:41  <creationix>a non-bundle version could be written for vanilla lua if desired
21:12:53  * indexzeroquit (Remote host closed the connection)
21:13:11  <creationix>yep, the loader could be made configurable
21:13:21  <creationix>with different plugins as separate lit plugins to be configured in bootstrap
21:13:29  <avidal>right
21:13:43  <avidal>and it seems that (mostly) the luv usage can be replaced with the standard lua io module
21:19:25  <hdms>Hello Rob
21:21:19  <rje>uh hi hdms?
21:24:22  * indexzerojoined
21:40:49  * dan3361joined
21:42:53  * dan336quit (Ping timeout: 245 seconds)
22:23:16  * bjornquit (Read error: Connection reset by peer)
22:23:44  * bjornjoined
22:23:51  * bjornquit (Changing host)
22:23:51  * bjornjoined
22:59:35  * travis-cijoined
22:59:35  <travis-ci>luvit/luvi#285 (master - 420f3cd : Rob Emanuele): The build passed.
22:59:35  <travis-ci>Change view : https://github.com/luvit/luvi/compare/726887c0a75f...420f3cde5691
22:59:35  <travis-ci>Build details : http://travis-ci.org/luvit/luvi/builds/48412672
22:59:35  * travis-cipart
23:01:42  * travis-cijoined
23:01:42  <travis-ci>luvit/luvi#286 (master - 2d2ca70 : Rob Emanuele): The build passed.
23:01:42  <travis-ci>Change view : https://github.com/luvit/luvi/compare/420f3cde5691...2d2ca703682f
23:01:42  <travis-ci>Build details : http://travis-ci.org/luvit/luvi/builds/48412760
23:01:42  * travis-cipart
23:19:30  * ^vjoined