00:48:24  * Haragethjoined
00:57:17  <daurnimator>creationix: you can
00:57:29  <daurnimator>creationix: it's an issue in musl-gcc.
00:58:26  <daurnimator>you can compile it fine if you go to a full musl distro (e.g. alpine linux in a container) or just turn off external unwinding (LJ_NO_UNWIND I think? it's in lj_err.c)
01:03:48  <creationix>daurnimator, wait, so if I use musl from alpine (default gcc?) then external unwinding will work?
01:03:58  <daurnimator>creationix: correct.
01:04:05  * creationixlogs into alpine box
01:04:19  <creationix>that would be awesome
01:04:30  <creationix>dlopen would still be busted, but I don't use it that often anyway
01:04:42  <creationix>I'm worried that ffi.open also uses it though
01:04:45  <creationix>I do use that a bit
01:04:57  <daurnimator>creationix: the issue is that if gcc is compiled with glibc, it links in libgcc_eh with everything you build.... usually it's not a problem, but for unwinding there are issues.
01:05:05  <daurnimator>creationix: huh? what's wrong with dlopen?
01:05:17  <creationix>static musl doesn't support it I thought
01:05:27  <daurnimator>well yeah... it's static
01:05:37  <daurnimator>this is sort of the definition of static: not dynamic :P
01:05:40  <creationix>dynamically linked musl works great compiled on alpine. I even blogged about that
01:05:59  * DarkGodquit (Ping timeout: 276 seconds)
01:06:19  <creationix>well, can't I have a "dynamic" binary that simply doesn't link to anything for core functionality, but can optionally dlopen shared libraries at runtime?
01:07:28  <creationix>I mean, I currently statically link in libuv, luajit and openssl
01:07:41  <creationix>why not add musl as well, but still have dlopen functionality at runtime
01:07:51  <creationix>or is libc special?
01:10:43  <creationix>hmm, I guess I would need all of libc just in case the shared library used some part of it I'm not using
01:11:12  <daurnimator>creationix: if you statically compile in libc, the shared libraries you load can't use libc.
01:11:23  <daurnimator>and.... everything uses libc :p
01:11:37  <creationix>I know this isn't possible, I'm just trying to understand why it was done this way
01:11:44  <daurnimator>i.e. supporting dlopen in a static libc is sort of pointless.
01:11:55  <creationix>not at all
01:12:05  <creationix>I want a portable binary that can load shared libraries and call functions in them
01:12:21  <creationix>but I guess that's not possible since the shared libraries are linked against another libc
01:12:28  <daurnimator>correct.
01:12:28  <creationix>that could cause some nasty problems
01:12:39  <daurnimator>the kernel sort of enforces "one libc per process"
01:12:52  <creationix>but still, I think a static version of luvi would be nice
01:13:00  <creationix>just can't seem to get it working, I'll try on alpine
01:13:55  <daurnimator>creationix: I played around with it yesterday. I pretty much got it working when I left cmake for dead :P
01:14:21  <creationix>I'm hoping midipix can let me drop libuv and cmake
01:14:33  <creationix>maybe later this year that might be feasable?
01:15:21  <creationix>first-class windows support is essential, most of the known luvit users and node users are on and targetting windows
01:15:25  <daurnimator>creationix: I hope so.... though my worry is the timeline might be longer.
01:15:34  <creationix>now by "most" I mean like 55-60%, but still
01:16:04  <creationix>daurnimator, well it will take time to rewrite luvit to not use libuv as well. I'm not even sure what that is
01:16:10  <creationix>would probably just migrate to your event loop
01:16:45  <daurnimator>creationix: well yeah. at that point... you've removed the "uv" out of "luvit". so we just have..... lit? :P
01:17:09  <creationix>right, the luvi model with zip assets and the lit package manager exist outside the concept of lua flavored node
01:17:22  <creationix>but not even lua is essential for thatw
01:17:42  <creationix>I could have a lua version, a js version using duktape, and another using some scripting language I make up
01:18:09  <daurnimator>creationix: at that point my question becomes: what is your goal?
01:18:17  <creationix>great question
01:18:22  <creationix>mostly have fun making useful things
01:18:31  <creationix>but I'm often guilty of creating solutions looking for problems
01:18:44  <creationix>or rehashing existing ideas to see how they can morph
01:19:01  <daurnimator>creationix: I'd be interested in seeing you re-take up brozula.
01:19:15  <creationix>think it's feasable?
01:19:38  <creationix>and I assume you've seen moonshine?
01:19:48  <daurnimator>yeah moonshine is *really* sloppy
01:19:48  <creationix>that's basically the same thing, but working and for lua bytecode
01:19:58  <daurnimator>I tried to help out and one point
01:20:04  <creationix>what's sloppy about it? How could I avoid the same problems?
01:20:09  <daurnimator>but my feedback was acknowledged... then ignored.
01:20:11  <creationix>I'm kinda sloppy too :(
01:20:32  <daurnimator>creationix: keeping true lua semantics.
01:20:49  <creationix>ahh, it wasn't quite lua
01:20:56  <daurnimator>not randomly introducing "oh but if we allow 0 to be false here it makes X easier"
01:21:19  <creationix>yeah, that's a bad idea
01:21:29  <daurnimator>or "we .bind everything js exposed to lua cause it's easy for manipulating svgs."
01:22:04  <creationix>can't it be done instead using : syntax?
01:22:09  <daurnimator>it can!
01:22:10  <creationix>I mean, don't .bind in js
01:22:11  <daurnimator>and it should.
01:22:15  <daurnimator>but... moonshine didn't
01:22:21  <daurnimator>and doesn't want to change.
01:22:21  <creationix>.bind is evil to begin with, I would know
01:22:42  <creationix>ok, so if they don't have that market covered as I thought, then maybe there is value in brozula
01:23:00  <daurnimator>creationix: he also started "starlight", which is moonshine targetting ES6
01:23:04  <daurnimator>same issues :(
01:23:10  <creationix>also I stopped before because browser JS just didn't have enough primitives in ES5
01:23:26  <creationix>now with generators, weak tables, maps, proxies, etc. It should be much easier
01:23:42  <daurnimator>creationix: FWIW I fixed up all the semantics in lua.vm.js. brozula should have the same semantics.
01:24:07  <creationix>remind me the approach that one took
01:24:08  <daurnimator>I suggest that you'd use lua.vm.js as the "reference" implementation.
01:24:13  <daurnimator>creationix: emscripten
01:24:19  <creationix>ahh
01:24:39  <creationix>so mine should work the same more or less, but be a lot less code
01:24:46  <daurnimator>creationix: I fixed up it's JS <=> lua bridge. now it has really good semantics for calling between lua and js, both ways.
01:24:53  <creationix>lua bytecode or luajit bytecode?
01:25:10  <daurnimator>creationix: less code; but also the important thing is using JS's garbage collector
01:25:21  <creationix>right
01:25:38  <creationix>though if webassembly ever exposes the GC to it's values, then something interesting could be done
01:25:39  <daurnimator>without that you have 2 gcs. which is an unsolved problem in computer science :P
01:26:07  <daurnimator>creationix: well I *do* have that https://github.com/tc39/proposal-weakrefs ...
01:26:13  <creationix>I thought weak refs solved that. That's how I solve rpc across two machines
01:26:22  <daurnimator>but you still end up with unbreakable cycles
01:26:30  <creationix>true
01:26:40  <creationix>cycle detection doesn't exactly work cross gc
01:26:46  <daurnimator>exactly
01:27:03  <daurnimator>which is a major reason to use JS objects to "back" lua objects.
01:27:05  <creationix>but still, the weakrefs are a way to manually break cycles, just not a general solution
01:27:10  <daurnimator>that way the JS GC can "see" everything
01:27:40  <daurnimator>creationix: cycles aren't a problem for a GC.
01:27:53  <daurnimator>but they are for *two* GCs.
01:28:18  <creationix>right, I've written simple mark/sweep GC and ref-counting gcs
01:28:30  <daurnimator>creationix: which bytecode you use doesn't matter. whatever makes you happier. you could even make your own.
01:28:48  <creationix>I think I read the luajit bytecode performs better
01:28:50  <daurnimator>==> bytecode isn't a defined piece in lua
01:28:58  <creationix>it is aligned better for sure, but not sure that matters in js
01:29:05  <creationix>it probably does, typed arrays are fairly low level
01:29:25  <daurnimator>creationix: you could even have structured instructions if you wanted to.
01:29:28  <creationix>I could just write a lua parser and interpret the ast
01:29:39  <daurnimator>creationix: sure. or reuse one that already exists ;)
01:29:54  <creationix>is there a canonical lua parser?
01:30:21  <creationix>I do worry such a naive interpreter would be super slow
01:30:34  <creationix>though now sure how bytecode interpreter would be any faster
01:30:44  <creationix>when I was working on brozula, I wanted to write a bytecode jit
01:30:54  <creationix>jit to js so that V8 can hit to assembly
01:30:57  <daurnimator>creationix: no canonical parser.
01:31:38  <daurnimator>it's not hard to write one though
01:31:38  <creationix>that's basically what pflua did to make a super fast packet filter "interpreter"
01:31:47  <creationix>he jitted the pf code to lua and let luajit jit it to assembly
01:32:13  <creationix>query and workload optimized assembly, it was faster than the linux kernel code by orders of magnitude
01:32:21  <daurnimator>creationix: sort of... he just relied on luajit's optimizer and made sure to hit the fast parts.
01:32:38  <creationix>but didn't he translate the code to lua on the fly
01:32:45  <creationix>luajit can't optimize a giant switch loop, nothing can really
01:32:50  <creationix>that's the problem with interpreters
01:33:39  <creationix>btw, Andy is the reasons browser ever gained ES6 generator support
01:33:47  <daurnimator>diamond shaped control flow is diamond shaped control flow. you can only massage so much.
01:33:59  <creationix>his sponsor just up and paid him to implement it in all the major browsers, and he did
01:37:00  <daurnimator>creationix: so the reason I think brozula-style is the way forward is coroutines: a source => source transpiler can never capture lua's awesome semantics around coroutines.
01:38:19  <creationix>I wonder if generators would be enough
01:38:37  <daurnimator>I don't think so.
01:38:45  <creationix>pretty much every function in the vm would need to be a generator. That kills most the performance benifits
01:38:49  <konobi>lo
01:38:57  <creationix>well, every impure function that is
01:39:03  <creationix>konobi: hi
01:39:53  <daurnimator>creationix: not impure functions; but any function that *may* (even indirectly) call coroutine.yield.
01:40:00  <creationix>daurnimator: right
01:40:07  <creationix>which is very hard to know statically
01:40:25  <daurnimator>pretty much. that'd be a major research project.
01:41:52  <creationix>daurnimator, but you're right, proper coroutines is why I abondoned the jit idea for brozula before
01:41:55  <daurnimator>(and consider that almost might involve a coroutine.yield => indexing a table, adding two values.... etc)
01:41:57  <konobi>huh... haven't read talk like this since I frequented the perl6 channel
01:42:11  <daurnimator>s/almost might/almost anything might/
01:42:18  <daurnimator>konobi: hmm?
01:42:29  <creationix>daurnimator, good point, not a low hanging fruit at all
01:42:37  <konobi>oh gc, jit, coroutines, etc.
01:43:12  <creationix>konobi, you should see all the partially implemented vm and partially designed programming languages I've worked on in the last year alone
01:43:16  <daurnimator>konobi: see https://github.com/creationix/brozula -- creationix was working on it back in 2012
01:43:17  <creationix>20+ for sure
01:43:23  <konobi>heh
01:43:38  <konobi>tried looking at moarvm?
01:43:50  <daurnimator>I think it's worth resuming work there. and might be a good outlet for creationix's creative efforts :p
01:44:43  <konobi>http://www.moarvm.org/
01:45:03  <creationix>no, havn't looked into moar yet. I never did perl stuff
01:45:11  <creationix>looks like a pretty good vm toolkit
01:45:12  <daurnimator>konobi: yeah i've seen it... good on them I guess
01:45:28  <creationix>pypy interested me as well
01:45:40  <creationix>learned neko (from haxe) years ago
01:45:53  <creationix>even considered jvm or clr
01:46:08  <daurnimator>one thing I've learnt from luajit is that you *shouln't* try to write a "generic" JIT: you should always try to match semantics of a target language. otherwise your heuristics are slow/bad.
01:46:30  <creationix>yes that
01:46:38  <creationix>also I hate fighting semantic mismatches
01:46:56  <creationix>the other reason I gave up on brozula. JS and Lua are just different enough to be painful
01:47:11  <konobi>daurnimator: it's under active development, the dev lead is a very smart cookie and it's designed to be available not just to perl6
01:47:49  <daurnimator>and because of that lesson: I have no interest in moarvm. either it's good and matches perl semantics, in which case I don't care cause I don't write perl. or it's bad and is a "generic vm" and I don't want anything to do with it.
01:48:18  <konobi>it's a different approach, based on metamodels
01:48:38  <daurnimator>creationix: yeah I thought that too. but thinking about CASTL (the JS=>lua transpiler) gave me hope.
01:49:03  <daurnimator>creationix: last time we wrote it targetting all browsers. I think we have enough new things now we can make it work
01:49:07  <creationix>daurnimator, don't worry as time goes JS adds more and more lua features ;)
01:49:13  <daurnimator>e.g. Map is in enough browsers now.
01:49:16  <creationix>too bad they can never drop anything
01:49:43  <konobi>there's always emscripten... mwuahahha
01:49:52  <daurnimator>creationix: I still think they can/should. have type="text/javascript2" which is where all new features land.
01:50:06  <daurnimator>if you use the new feature; you can't use the old feature
01:50:11  <creationix>daurnimator, not going to happen, but maybe webassembly will be that
01:50:21  <creationix>though they are doing that with the module format
01:50:31  <creationix>modules are not scripts, they are incompat. in subtle ways
01:50:33  <daurnimator>creationix: AFAICS there's nothing to be exicted about with webassembly... it's just asm.js but not js.
01:50:48  <creationix>daurnimator, initially, the long term goal is to break compat with js
01:50:54  <creationix>add threads and other features js can't add
01:51:43  <daurnimator>js already has threads. and they're supported by emscripten. they're called webworkers.
01:52:02  <creationix>I mean threads that share mutable state with locks and all that horror
01:52:04  <daurnimator>it's not a surprise that webworkers almost exactly map to pthreads semantics...
01:52:42  <creationix>what's odd is node.js never got workers
01:52:44  <daurnimator>creationix: yep... you can share a typedarray with a webworker. and can do locks via postMessage (which is the best way to implement anyway)
01:52:57  <creationix>ok, then they are like threads
01:54:35  * creationixwonders how closely c11 threads match
01:55:12  <daurnimator>considering c11 threads get implemented on top of pthreads; and webworkers match pthreads.......
01:57:23  <creationix>daurnimator, ok so one thing I never understood about luajit bytecode is how upvalues work
01:57:30  <creationix>do you understand this?
01:57:48  <creationix>http://wiki.luajit.org/Bytecode-2.0#upvalue-and-function-ops
01:57:54  <daurnimator>not deeply. can probably figure it out with some staring.
01:58:17  <creationix>UCLO and FNEW didn't make sense to me
01:58:38  <creationix>since then I've implemented a couple lisps with closures, but my model doesn't seem to match what luajit is describing
01:58:49  <daurnimator>creationix: what don't you understand about them?
01:59:10  <creationix>what does "close upvalues for slots..." mean
01:59:47  <daurnimator>creationix: same as in normal lua I assume.
01:59:48  <creationix>I understand `uv` is just a number, a index into something
01:59:55  <creationix>the "closure" I assume
02:00:03  <creationix>but what exactly does it mean to close over something
02:00:51  <daurnimator>creationix: http://luaforge.net/docman/83/98/ANoFrillsIntroToLua51VMInstructions.pdf see page 54
02:02:53  <creationix>I guess it means to make a copy of that section of value stack
02:03:06  <creationix>but where the copy is just reference to the variables somehow
02:03:22  <daurnimator>"CLOSE in line [5] makes the virtual machine find all affected locals (they have to be open upvalues,) take them out of the stack, and place them in a safe place so that they do not disappear when the block or function goes out of scope"
02:03:22  <creationix>because the stack itself will often unwind before the function is later executed
02:04:18  <creationix>ok, so I'm close, still a little muddy
02:04:38  <creationix>so in js, the stack would just be a js array
02:04:49  <creationix>maybe
02:09:02  <daurnimator>creationix: likely.
02:09:29  <creationix>the value stack doesn't need to be js backed, just the lua values
02:09:40  <creationix>so it could be a typed array of indexes into a js array of values
02:09:45  <creationix>make that my heap
02:09:45  <daurnimator>"value" stack? you mean the constant table?
02:10:13  <creationix>no, I mean the local variables
02:10:27  <creationix>`var` in the luajit docs
02:10:45  <daurnimator>"Lua employs two stacks. The Callinfo stack tracks activation frames. There is the secondary stack L->stack that is an array of TValue objects. The Callinfo objects index into this array. Registers are basically slots in the L->stack array."
02:13:45  <creationix>yep, the L->stack as lua calls it
02:13:58  <creationix>that's why the C api looks the way it does
02:15:15  <daurnimator>creationix: btw, I'd also try and make something like the C api available (except for JS of course).
02:15:24  <creationix>https://gist.github.com/creationix/1d52c2723279105f2b0ccfdd0298a3fb#gistcomment-1756933
02:17:30  <daurnimator>creationix: have you got a question there? :p
02:17:40  <creationix>just trying to understand it
02:17:44  <creationix>that's as simple as closures can be
02:17:52  <daurnimator>creationix: I added the example in comment that's simpler (from no frills)
02:18:49  <daurnimator>creationix: I'm still not sure which bit you don't understand
02:19:07  <creationix>it's the semantics of the references and what it means to "move to a safe place"
02:19:07  <daurnimator>`UCLO 0` means "close over everything from upvalue 0 onwards"
02:19:22  <creationix>right, so copies of the references?
02:19:46  <creationix>local code can use the slot after it's been closed over right?
02:20:19  <daurnimator>creationix: it moves it from the open upvalues into the upvalue slot.
02:21:34  <creationix>ok, then what is an "open upvalue"
02:21:38  <creationix>what's "open" about it
02:22:01  <daurnimator>creationix: not closed :P
02:22:28  <daurnimator>that's perhaps a bit tautological
02:22:50  <creationix>so what if two closures reference the same value?
02:23:03  <creationix>the generated code just reuses the same closure?
02:23:17  <creationix>can it still be used as a local variable?
02:23:23  <creationix>I guess I need to generate some more code to test
02:23:24  <daurnimator>functions have a "prototype" and then you have a "closure"
02:23:58  <daurnimator>a closure is what you probably think of as a function
02:24:33  <creationix>sure, I mean the set of closed over variables
02:24:41  <creationix>I guess multiple closures can share it
02:25:32  <daurnimator>uh, no?
02:25:46  <daurnimator>each closure has it's own list of upvalues
02:26:27  <creationix>then how can they close over the same value
02:26:37  <creationix>if it's closed over, it's not open anymore right?
02:26:54  <creationix>I know they can share mutable references to a single value
02:27:31  <daurnimator>creationix: it's an open upvalue, not an open TValue.
02:27:52  <daurnimator>the upvalue(s) are a property of the closure
02:28:05  <creationix>but you close over tvalues
02:28:27  <daurnimator>an upvalue contains a pointer to a tvalue
02:28:45  <creationix>so it's not a move then, a pointer
02:29:09  <daurnimator>you *move* the "upvalue" structure from one list to another.
02:29:31  <daurnimator>the tvalue pointer inside that upvalue structure doesn't change during the "closing" process.
02:30:17  <creationix>ok, so what is "KNIL 0 1" creating in your sample? That's a new local variable at slot 0 containing the value nil
02:30:25  <creationix>is that a TValue or an upvalue or something else?
02:32:00  <daurnimator>`KNIL 0 1` corresponds to `local p,q`: it creates two new (nil) values on the L->stack starting at indexes 0 and 1.
02:32:31  <daurnimator>(`nil` is a TValue)
02:33:14  <creationix>sure, but tvalues are immutable right?
02:33:20  <creationix>or can you change them in-place in the vm
02:33:41  <creationix>if so, that may be the part I'm missing
02:33:59  <daurnimator>a TValue (Tagged Value) is pretty much a lua object
02:34:10  <creationix>right, I get that
02:34:33  <creationix>but what happens when I later set a new value to slot 0?
02:34:45  <creationix>does the tvalue change in-place in memory?
02:34:55  <creationix>I didn't think things like nil were heap allocated
02:36:35  <daurnimator>no I don't believe tvalues ever change. they just get replaced.
02:36:47  <creationix>ok, so that's what I thought
02:36:57  <creationix>it's silly to box primitives like nil, boolean and small integers
02:37:36  <daurnimator>infact they aren't boxed in lua at all. in general: things that share a metatable aren't boxed.
02:37:49  <creationix>so it local slot contains the tvalue for nil and upvalue on closure 1 contains the same tvalue, and closure 2 contains the same tvalue, how are changes syncronized?
02:37:53  <daurnimator>(i.e. nil, booleans, numbers, strings, lightuserdata, functions)
02:38:56  <creationix>that's like lua code `a = 1; b = a; c = a;` and then `a = 2` and expecting b and c to also equal 2
02:39:09  <creationix>there must be a level of indirection somewhere
02:39:28  <daurnimator>creationix: the closure both share the same "UpVal" in their upvalue list.
02:40:01  <creationix>so upvalues are heap allocated and reference counted?
02:40:23  <daurnimator>upvalues are heap allocated. not reference counted.
02:40:42  <creationix>ok, not reference counted, but somehow it knows when to free them
02:41:00  <creationix>heap allocated boxes around tvalues
02:41:11  <creationix>and the closure list is just a list of pointers to upvalues?
02:41:38  <daurnimator>creationix: c closures and lua closures are slightly different there.
02:41:55  <creationix>right, pointers are not the same as lua references
02:42:16  <daurnimator>creationix: I mean C closure can share upvalues. lua closures don't.
02:42:36  <daurnimator>C closures upvalues are an array of TValues. lua closures upvalues are an array of UpVal.
02:43:11  <creationix>and UpVal is just a pointer to a TVal right?
02:43:25  <creationix>a floating lua reference
02:44:05  <daurnimator>yes.
02:44:53  <creationix>so I think what is messing me up then is I keep worrying about the case where a TValue is used locally in a function but is also closed over and moved to an UpVal
02:45:05  <creationix>perhaps the compiler will never generate such code
02:45:44  <daurnimator>creationix: UpVal only contains a pointer to the tvalue.
02:45:56  <daurnimator>it's not *moved* to an UpVal.
02:47:06  <creationix>are the local slots also pointers to TValues instead of TValues directly?
02:48:40  <daurnimator>L-stack is a list of TValue. (not pointers)
02:49:27  <creationix>hmm, still confused then
02:50:11  <daurnimator>uh wait sorry
02:50:13  <daurnimator>no.
02:50:14  <daurnimator>it's a pointer.
02:51:50  <creationix>so stack *is* a list of pointers?
02:53:43  <daurnimator>yep. sorry. The reference I quoted from didn't say that. and then I confused myself when I didn't see the `*` in the typedef for StkId.
02:54:35  <creationix>so I wonder where the TValues live
02:55:46  <creationix>boxed values are in the lua heap, pointers to integers have to point somewhere
02:56:04  <daurnimator>creationix: the constant table
02:56:38  <creationix>sure for large constants, but aren't some just inline values in the TValue union?
02:57:03  <daurnimator>creationix: the constant table is a list of TValue... I think. let me double check that one
02:57:18  <creationix>ok, that kinda makes sense
02:57:52  <creationix>but I wonder how they are garbage collected
02:58:15  <konobi>mkay... time to work on this app
02:59:37  <daurnimator>creationix: yep. constant table is just a list of TValue.
03:00:00  <creationix>constant sounds like static liketime
03:00:23  <creationix>I guess the pointers to tvalues are tagged to know if it's a constant table entry or a heap entry
03:00:25  <daurnimator>creationix: what do you mean? the constant table is a member of a Proto. when the Proto gets collected the constant table does too.
03:00:58  <creationix>oh, it's not global
03:01:10  <creationix>proto is scoped to function execution lifetime right?
03:01:34  <daurnimator>creationix: each function prototype (Proto) has it's own constant table
03:01:37  <creationix>well and any closures created within it
03:02:04  <daurnimator>a closure (function as you know it) is a Proto + a list of upvalues
03:02:21  <daurnimator>(list of pointers to upvalues that is)
03:02:32  <creationix>and upvalues point to the parent proto
03:02:39  <creationix>the parent can't be GCed till the child is
03:03:00  <creationix>*UpVal's point to parent proto
03:03:10  <daurnimator>yep.
03:03:13  <daurnimator>http://www.lua.org/source/5.3/lobject.h.html#LClosure
03:03:26  <creationix>ok, this is closer to lisp style closures than I thought
03:03:57  <konobi>is there any module for doing stuff like farm-workers?
03:04:08  <creationix>farm-workers?
03:04:31  <konobi>npm module
03:04:45  <konobi>worker-farm even
03:05:02  <creationix>not that I know of
03:05:28  <creationix>spawning children with pipes to communicate is pretty easy using uv.spawn
03:05:49  <creationix>you can search the lit database for various keywords. I don't know everything that is in there
03:05:56  <creationix>I only wrote half of it ;)
03:06:27  <konobi>i can't get a full list of packages
03:06:49  <creationix>yeah, must be a bug, says there are 174, but then only shows a couple pages worth
03:06:54  <konobi>seems like the results are being paged, but no paging shows
03:07:34  <creationix>konobi: right, but I don't remember implementing paging in the query engine
03:07:50  <creationix>daurnimator, thanks it's making a lot more sense now
03:08:42  <creationix>daurnimator, though, since it's called a "constant" table I expect the boxed values live elsewhere
03:08:53  <creationix>in the GC heap I would assume
03:10:08  <daurnimator>creationix: perhaps look at a function like this: function() local x = 0; local function inc() x = x + 5; return x end return inc end
03:10:38  <daurnimator>hold on, adding labels for clarity in my following explanation
03:11:25  <daurnimator>function gen() local x = 0; local function inc() x = x + 5; return x end return inc end; local incrementers = {}; for i=1,10 do incrementers[i] = gen(); end
03:12:18  <daurnimator>there are 3 function prototypes in that. 'gen' 'inc', and the whole thing (an anonymous function).
03:13:15  <daurnimator>the 'gen' prototype has 1 constant: 0 (used to initialise x)
03:13:29  <daurnimator>the 'inc' prototype has 1 constant: 5
03:14:11  <daurnimator>the encapsulating function prototype has 3 constants: the string "gen" (used to get/set the global), and the numbers 1 and 10 (used in the `for` loop).
03:14:47  <daurnimator>creationix: ^^ make sense?
03:15:55  <creationix>so every number ever stored to a local variable creates a new slot in the table? seems wasteful
03:17:16  <daurnimator>creationix: every constant used in a function is stored in the constant table... where else would they live? (they have to be *somewhere*)
03:18:21  <creationix>right, then a simple `for i = 1, 1000000000 do end` would eat a ton of ram
03:18:42  <creationix>that doesn't sound right
03:18:46  <daurnimator>creationix: huh? there's only 2 constants there, 1 and 1000000000.
03:19:07  <creationix>all, misread your comment
03:19:13  <creationix>"1 and 10" not "1 to 10"
03:19:32  <creationix>except in luajit there are also immediate values in the bytecode
03:19:51  <daurnimator>right. in luajit it skips the constant table for small enough numbers.
03:20:34  <creationix>for some operations
03:20:41  <daurnimator>yep.
03:20:46  <creationix>ADDVN adds some inline constant to a slot
03:21:01  <daurnimator>usually it's best to "think" in lua. and add luajit optimisations on top.
03:21:41  <creationix>ok, so constant table is not what I'm looking for, it's what I thought it was before. A place to store constants found in source code
03:21:56  <creationix>things that don't quite fit inline in the bytecode,
03:22:51  <creationix>I'm talking about runtime generated/computed values that have references to them from multiple places
03:24:44  <creationix>https://gist.github.com/creationix/1d52c2723279105f2b0ccfdd0298a3fb#gistcomment-1756972
03:25:22  <daurnimator>creationix: you're asking where 'a' lives?
03:25:31  <creationix>KSHORT stored the value 1 in slot 0
03:25:46  <creationix>right, it's closed over, modified in the closure, and the return somehow has the updated value
03:26:31  <daurnimator>creationix: I added comment with lua decompilation.
03:26:38  <creationix>the 1 exist as an inline part of the bytecode instruction. I'm sure it's copied somwehere when the new TValue is created, but where does that TValue live?
03:28:13  <daurnimator>creationix: huh? which bit are you talking about? lets refer to the lua decomp for now.
03:28:26  <creationix>sure looks like the same thing
03:28:40  <creationix>main loads the constant 1 into slot 0
03:29:11  <daurnimator>yes.
03:29:46  <creationix>looks like CLOSURE is closing over the slot and references the source in one shot and storing the prototype in slot 1
03:31:03  <creationix>interestingly, luajit creates the function, calls it and then does UCLO before returning
03:31:32  <daurnimator>creationix: the 2 functions are the opposite way around in the 2 dumps
03:32:08  <daurnimator>creationix: UCLO is *also* a JMP. i.e. it's just like the double return in lua.
03:32:51  <daurnimator>actually no sorry. UCLO *can* be. but in this case it isn't... it just jumps to the next instruction
03:33:13  <konobi>creationix: client side code error on lit
03:34:43  <creationix>konobi, interesting, the json from the server looks right https://lit.luvit.io/search/*
03:34:53  <creationix>parses as JSON for me and has a lot of entries, perhaps all of them
03:39:14  <creationix>daurnimator: I understand the flow, just confused on what closing over variables does
03:39:24  <creationix>especially since it's done *after* creating and calling the closure
03:41:33  <creationix>most importantly, where does UGET 0 0 read from? FNEW doesn't specify anything about closures, just function prototype from the constant table and storing instance in local slot
03:41:59  <creationix>anyway, I need some sleep, I'm pretty sick today and don't need to get sicker, thanks for being patient with me.
03:42:03  <creationix>daurnimator, g'night
03:53:30  <konobi>are there any coverage tools for lua?
03:58:01  <daurnimator>konobi: yep. luacov
03:58:20  <daurnimator>konobi: if you use busted `busted -c` turns on coverage analysis (requires luacov to be installed))
04:00:56  <konobi>daurnimator: awesome, thanks. now to see if it'll work with luvit
04:04:24  <daurnimator>konobi: btw, if you're interested in vm stuff: https://www.reddit.com/r/programming/comments/badl2/luajit_2_beta_3_is_out_support_both_x32_x64/c0lrus0
04:05:59  <konobi>i used to do a bit of VM work back in a previous experimental version of perl6
04:08:46  <konobi>huh... nice
04:58:13  * SkyRocknRolljoined
05:08:39  * Haragethquit (Remote host closed the connection)
05:13:17  * Haragethjoined
06:14:25  * Haragethquit (Remote host closed the connection)
07:00:26  * daurnimatorquit (Quit: WeeChat 1.4)
07:06:36  * daurnimatorjoined
07:10:48  * Something12_joined
07:13:39  * Something12quit (Ping timeout: 244 seconds)
07:14:23  * daurnimatorquit (Quit: WeeChat 1.4)
07:24:28  * ksheedloquit (Ping timeout: 264 seconds)
07:25:31  * ksheedlojoined
07:39:05  * rendarjoined
08:06:59  * daurnimatorjoined
10:51:07  <konobi>huh... something like Moose for lua would be pretty interesting
11:57:14  <konobi>huh http://fperrad.github.io/lua-TestMore/ and http://fperrad.github.io/lua-Coat/
12:05:44  * SkyRocknRollquit (Ping timeout: 276 seconds)
13:17:22  <rphillips>good morning
14:12:28  <creationix>mornin'
15:32:06  * Haragethjoined
16:18:53  * SkyRocknRolljoined
17:07:06  * SkyRocknRollquit (Remote host closed the connection)
17:22:24  <creationix>daurnimator, looks like node will soon have most of ES6 implemented http://node.green/
18:19:05  * DarkGodjoined
19:40:43  * rendarquit (Ping timeout: 252 seconds)
19:47:25  * rendarjoined
23:13:46  * rendarquit (Quit: std::lower_bound + std::less_equal *works* with a vector without duplicates!)
23:25:31  * Haragethquit (Remote host closed the connection)
23:54:49  * DarkGodquit (Quit: Leaving)