00:21:15  * Haragethquit (Remote host closed the connection)
00:43:36  * dobsonquit (Quit: Leaving)
00:49:23  * Something12joined
00:54:21  * dobsonjoined
00:56:23  * sclark39joined
00:56:49  <sclark39>Can luvit do clustering like node.js?
00:57:18  * therebelrobotquit (Ping timeout: 265 seconds)
00:58:05  <sclark39>https://github.com/luvit/luv/blob/master/examples/tcp-cluster.lua
00:58:07  <sclark39>i imagine is it
01:16:06  <daurnimator>sclark39: doesn't sound like clustering; but I don't know how node.js likes to redefine terms...
01:17:33  <sclark39>daurnimator one of the things node.js advertises (or people like it for) is because you can easily convert a node.js program to be able to be run on a cluster
01:18:15  <daurnimator>sclark39: it sounds like they have a very different definition of "cluster" to the rest of the world. do you have an example?
01:19:00  <sclark39>https://nodejs.org/api/cluster.html
01:19:00  <sclark39>http://www.sitepoint.com/how-to-create-a-node-js-cluster-for-speeding-up-your-apps/
01:19:46  <sclark39>sounds like it's just making it able to be multi-threaded... but I believed the instances could be run across multiple servers (but I am not very experienced with nodejs)
01:19:53  <daurnimator>okay yeah. they use the word "cluster" entirely incorrectly.
01:20:01  <daurnimator>they infact just mean workers
01:20:15  <sclark39>yeah
01:20:20  <rch>Yeah it's a weird name, it's always bugged me
01:20:25  <daurnimator>so yeah, luvit can do workers no problem. it's usually pretty simple to do.
01:20:31  <daurnimator>(in any language)
01:20:42  <sclark39>does node.js support actual clusters? or did they just rename workers to cluster and then say they supported it?
01:21:03  <daurnimator>sclark39: just renamed by the look of it
01:22:27  <sclark39>Yeah, this is another spot where it seems luvit and nodejs are tied :P
01:22:37  <sclark39>(which means luvi/luvit is still winning for me)
01:23:20  <sclark39>The one problem I've had with luv is that I don't know how to get good tracebacks from the coroutines
01:23:40  <daurnimator>sclark39: lua has debug.traceback(mycoroutine)
01:23:51  <sclark39>Right, but I need to catch it when it errors
01:24:11  <sclark39>the traceback it prints with the coroutine by default is not helpful
01:24:28  <daurnimator>sclark39: I can have a quick look. do you know where that gets thrown from?
01:24:43  <sclark39>Nah, let me see if I can make a demo app
01:25:01  <daurnimator>sclark39: no I meant which line in the luv source
01:25:14  <sclark39>ah, no, haven't dug down that far yet.
01:29:23  <daurnimator>wait, where *is* the coroutine resuming happening?
01:45:30  * Haragethjoined
01:47:58  <sclark39>uv.run handles the resuming daurnimator
01:48:56  <daurnimator>sclark39: there's not a single lua_resume call in luv...
02:10:55  * a__quit (Ping timeout: 240 seconds)
02:12:57  <daurnimator>creationix: ^^
02:14:38  <creationix>where are the coroutines being used?
02:14:45  <creationix>luvit's core APIs are callback based
02:14:53  <creationix>and correct, luv doesn't touch them, it's all callback
02:15:16  <creationix>I have a common pattern in my coro-* libraries where lua code wraps callback code and yields and resumes the calling thread
02:15:36  <daurnimator>ah okay, so sclark39 is using that?
02:16:05  <sclark39>Yeah, that's what I'd be using
02:16:18  <sclark39>Sorry :P
02:16:40  <sclark39>How can I get good tracebacks on error from that, creationix ?
02:17:05  <creationix>for example, here is how I would wrap a callback based setTimeout to be a coroutine based sleep https://gist.github.com/creationix/19b9d8cefe55d946807c
02:17:15  <creationix>error handling is tricky
02:17:43  <creationix>I don't like how lua coroutines do errors
02:17:58  <daurnimator>o.o that's half the reason I use coroutines
02:18:03  <daurnimator>errors are actually readable!
02:18:08  <creationix>if there is an error raised, whoever called coroutine resume gets it
02:18:20  <daurnimator>creationix: well yeah....
02:18:21  <creationix>daurnimator: yes, the stack traces are much better, that's true
02:18:48  <creationix>but in my case 99% of the time, it's a luv callback into lua that eventually calls coroutine.resume
02:18:57  <sclark39>yup, that's what I keep seeing too
02:19:03  <creationix>which is deep in some library code and has no idea how to handle your error
02:19:04  <sclark39>which makes it very hard to actually figure out what went wrong
02:19:17  <daurnimator>creationix: I guess I don't really have that problem, as with cqueues it's all resumed from the scheduler.
02:19:43  <creationix>sclark39: so the way to handle it is to put an xpcall inside your coroutine, then it never escapes into whoever resumes the thread
02:20:30  <daurnimator>creationix: well where *do* you want it to be reported/escape to?
02:20:36  <sclark39>hmm
02:20:49  <sclark39>I'll give that a try
02:21:12  <creationix>https://gist.github.com/creationix/19b9d8cefe55d946807c#file-error-handling-lua
02:21:14  <creationix>sclark39: ^
02:21:27  <daurnimator>creationix: you could write a little helper than does the resume, and if it fails, store it for some 'run' function to yell about
02:22:34  <creationix>daurnimator: yes, but then all my libraries that wrap callbacks would need to depend on this library
02:22:40  <sclark39>creationix how would you combien those two? if the sleep is within the commented section along with some other code will it error?
02:22:49  <daurnimator>creationix: yeah. that's reasonable IMO.
02:23:01  <creationix>instead a library that does the coroutine.create and xpcall wrapping for you would be more flexible
02:23:11  <creationix>and not require anything to be done in all the coro-* libraries
02:25:26  * DarkGodquit (Quit: Leaving)
02:27:02  * Haragethquit (Remote host closed the connection)
02:30:45  <creationix>sclark39: something like this might help https://gist.github.com/creationix/19b9d8cefe55d946807c#file-helper-lua
02:31:20  <sclark39>neat
02:32:41  <creationix>so yeah, daurnimator's system is nice if you don't have callback based stuff to wrap, but I interop with callback based code all the time
02:32:42  <daurnimator>creationix: I meant something quite different
02:33:22  <creationix>daurnimator: so my initial idea was to put something like your idea into luv itself
02:33:37  <creationix>have a place where people could register global error handlers for callbacks
02:34:15  <daurnimator>creationix: hold up. writing exxample.
02:34:19  <creationix>the full idea was a way to wrap all callbacks into lua so that you could do things before, after, or wrap the call in xpcall
02:36:27  <creationix>the problem with a global wrapper is the lack of context and locality
02:36:41  <creationix>different pieces of code want to handle errors differently and only their errirs
02:36:43  <creationix>*errors
02:37:06  <creationix>though I guess what I didn't consider is lua maps can use the thread as a key
02:37:15  <creationix>that might work well
02:38:24  <creationix>I just need a way to know what thread started an action since callbacks in luv all happen on the main thread
02:38:49  <daurnimator>creationix: https://gist.github.com/daurnimator/a0288074b747a4c26d16
02:38:58  <creationix>this isn't clear with things like connection pooling or emitters in libuv
02:40:05  <creationix>daurnimator: remind me what "kv" mode does
02:40:14  <creationix>double weak table?
02:40:15  <daurnimator>creationix: weak keys and weak values.
02:40:26  <creationix>got it. Sometimes I forget how powerful lua is
02:40:38  <creationix>features I've wished for for years in JS and will never get it seems
02:40:40  <daurnimator>creationix: coming to JS real soon now :)
02:40:58  <creationix>weak maps right, but never coroutines
02:41:06  <creationix>just generators
02:41:26  <daurnimator>creationix: https://twitter.com/DeanTribble/status/698326538589044736
02:41:31  <daurnimator>^^ weakrefs
02:41:44  <daurnimator>once we have that lua.vm.js will actually be usable!
02:42:01  <creationix>yeah, that will help a lot
02:42:08  <creationix>Map helped a bit implement tables
02:42:23  <creationix>and Proxy helps with the other metamethods I think
02:42:28  <daurnimator>yep
02:43:16  <creationix>I guess if you just yield* everything in JS then you can simulate coroutines, I just worry about the performance of that
02:43:46  <creationix>what's it do now, just transform the code and generate a state machine?
02:43:58  <daurnimator>creationix: I'd still run a lua vm actually.
02:44:15  <daurnimator>I'm trying to make sure it's ready with wasm
02:44:35  <daurnimator>and enter it as a full alternative for js on the web
02:44:49  <creationix>I have high hopes for wasm
02:44:53  <daurnimator>the js weakref is just needed to bridge to the DOM
02:45:05  <creationix>I want a future where eventually any language is on equal standing technically with js
02:45:11  <creationix>just a matter of implementation work then
02:45:22  <daurnimator>creationix: honestly the weakref is the last thing left...
02:45:42  <creationix>I can see how that helps integrate with the dom
02:45:44  <daurnimator>everything else we can already do *today*
02:46:10  <creationix>webasm should be incrementally faster and smaller than asm.js
02:46:19  <creationix>service workers are pretty amazing too
02:46:21  <daurnimator>webasm I don't actually need.
02:46:26  <daurnimator>performance isnt really on my mind
02:46:56  <creationix>I don't want megabytes of vm just to run my script in an alternative language, that's a non-starter for most people
02:47:20  <daurnimator>creationix: caching it isn't enough?
02:47:28  <creationix>I wish browsers had some sort of cross-domain content-addressable cache
02:47:40  <daurnimator>they... do?
02:48:09  <daurnimator>cross domain <script> src should be cached
02:48:28  <creationix>I mean, I could reference a resource by it's sha256 hash and if there is a matching resource in the cache (no matter what it's original url was) use it
02:49:53  <creationix>cross-domain script tags still need to make conditional requests or have long-lifetime cache expiration
02:50:09  <creationix>and even then, there is no single global path for the latest jquery, people have their own urls and copies
02:50:21  <creationix>with content-addressable hashes, anything with the same content is the same key
02:50:44  <creationix>and it's guranteed to not change (apart from hash collisions, which with sha256 would be crazy rare)
02:51:03  <daurnimator>The thing about releasing something like a new language on the Web is you can mandate a few things
02:51:28  <creationix>you can, but it will slow adoption
02:51:41  <creationix>people won't trust your server and will want mirrors
02:51:45  <daurnimator>I didn't expect anything else :p
02:52:10  <creationix>with content-addressable, there can be all the mirrors in the world, but once the content is cached, it doesn't matter
02:52:38  <creationix>but they will never add it because of fear of hash collisions and evil actors
02:53:11  <daurnimator>In any case, the compiled lua vm is still smaller than e.g. react
02:53:22  <creationix>this is true, gotta keep things in perspective
02:53:28  <creationix>modern frameworks are ridiculous
02:53:48  <creationix>I'm using elm for an app and that's about as big as I'll go
02:54:26  <creationix>it's require an offline compiler written i haskell, but I love the type system
02:55:05  <creationix>daurnimator: have you considered compiling lua to js offline, or do you really want the live compiler in the web page?
02:57:08  <daurnimator>I was lua to fit in just like js
02:57:23  <daurnimator>So, runtime is required IMO
02:58:30  <daurnimator>Nevermind that I've used coroutines extensively in my experiments. Which is difficult to transpire to js, as you noted above
03:00:19  <creationix>yeah, implementing a vm is the route for my languages too
03:01:23  <daurnimator>Getting off topic ;)
03:01:34  <daurnimator>So, my paste before make sense?
03:02:25  <creationix>yeah, but I'm not sure what it gains over my helper
03:02:44  <creationix>you still need to wrap the coroutine, but you *also* need to make all resumers aware of it
03:03:11  <creationix>I guess more control
03:03:23  <creationix>since the callback gets the raw err and a reference to the co
03:04:48  <creationix>daurnimator: another problem is your resumer just passes the results of the callback directly to the yielder
03:05:09  <creationix>in my case I'm wrapping various APIs with different callback signatures and I want to normalize them to a common format
03:05:19  <creationix>but I guess that could be done after the fact
03:05:40  <daurnimator>Creationix: then transform the result of coroutine.yield
03:05:51  <creationix>right, that's what I mean by "after the fact"
03:06:05  <creationix>but the idea of using a weakmap is key here
03:06:11  <daurnimator>creationix: that way tracebacks in transformation code will make sense
03:06:12  <creationix>and I like you don't need xpcall
03:06:22  <creationix>true
03:06:27  <daurnimator>And the transformations themselves can call other async functions
03:06:54  <creationix>how about this: Add an API to luv where you can associate an error handler with any thread
03:08:10  <creationix>hmm, nevermind, I still need to know what thread started the async action
03:08:42  <creationix>currently luv just fatal exits if lua_pcall finds an error in a callback
03:09:02  <creationix>it used to let the error bubble up to uv.run(), but that has some undefined semantics
03:12:34  * sclark39quit
03:13:10  <creationix>daurnimator: how about this? change luv to accept threads as well as functions in the callback slot
03:14:02  <creationix>if you give it a thread, luv will do the resume in C, the `coros` table can be part of luv so people can register resumers
03:14:17  <daurnimator>creationix: does that solve the problem of "where does the error propagate to?"
03:14:41  <daurnimator>creationix: yeah I was sort of suggesting that 'coros' table would be a uservalue on the uv_loop_t
03:14:47  <creationix>so many luvit APIs already accept a thread instead of a function
03:14:55  <daurnimator>they do?
03:14:58  <creationix>but it's not very elegant
03:17:23  <daurnimator>creationix: btw, in a real version I'd make a 'yielder' a special function too. that way you can use things like https://github.com/saucisson/lua-coronest
03:18:17  <daurnimator>creationix: re: luvit apis taking a thread instead of a function. by default have them assume the current thread. that way they "just work" as blocking apis :)
03:18:32  <creationix>https://asciinema.org/a/3s3xe4waw32dqwcwib7j8eiem
03:18:41  <creationix>daurnimator: I would do that, but it's a breaking change
03:18:54  <creationix>currently if you omit the callback, it still runs non-blocking, it just doesn't notify you when done
03:19:06  <creationix>if I instead make it block and return the value, some programs will break/deadlock
03:19:18  <creationix>all my new APIs do just that
03:19:28  <daurnimator>what do the old ones do instead?
03:19:30  <daurnimator>return EAGAIN?
03:19:46  <creationix>they don't usually return anything
03:19:58  <creationix>just register the event with libuv and return
03:21:01  <daurnimator>ah
03:21:27  <daurnimator>so they don't care if it succeeds or fails?
03:22:12  <creationix>well, all that information is in the callback
03:22:21  <creationix>and if you omit the callback, it just runs and then drops the results
03:22:26  <creationix>node.js behavior
03:23:58  <daurnimator>ah
03:25:50  <creationix>daurnimator: did you like how lift wraps luv with coroutines? http://lua-users.org/lists/lua-l/2016-02/msg00131.html
03:26:55  <creationix>I would love for the node.js clone APIs to eventually be just a set of optional userspace libraries and have luvit be something more neutral
03:27:21  <creationix>maybe just a set of libraries you can use with luarocks or lit and run with luvi based apps or normal lua
03:27:39  <creationix>I'm getting close technically, it's mostly a question of how to rebrand stuff
03:27:44  <daurnimator>creationix: honestly I think it should be the other way round
03:27:59  <creationix>other way?
03:28:06  <daurnimator>i.e. you should have all these nice 'blocking' coroutine yielding apis
03:28:13  <daurnimator>then wrap them to provide node.js style callback ones
03:28:24  <daurnimator>going the other direction is.... silly
03:28:32  <creationix>yes, but that's libuv
03:28:46  <daurnimator>not to mention making for hard to read code (IMO)
03:28:47  <creationix>I need windows support, libuv is the best cross-platform library for this stuff
03:29:09  <daurnimator>creationix: yeah I know..... hopefully I have an answer to that in the next month or so
03:29:14  <creationix>it's inefficient to wrap callbacks in coroutines just to wrap back in callbacks.
03:29:31  <creationix>now if I had a coroutine-based core, I'd happily do as you suggest
03:29:35  <creationix>would simplify a lot of code
03:29:42  <daurnimator>^^
03:29:49  * daurnimatoris working on it
03:29:55  <daurnimator>not with libuv though
03:30:01  <creationix>of course
03:30:10  <creationix>I went down that route wrapping libuv at the C level
03:30:32  <creationix>then using nothing more than luajit's FFI to bind it (and not using ffi callbacks)
03:30:57  <creationix>(meaning the wrapping was not using lua APIs, but just translating the callback API to poll style)
03:31:17  <daurnimator>creationix: off topic: did you try out lua-http yet? :)
03:31:27  <creationix>no, been pretty busy
03:31:41  <creationix>4 kids + full-time job + making my own language
03:32:02  <creationix>if luvit wasn't related to my day job, I wouldn't be maintaining it much
03:32:46  <daurnimator>how does rackspace use luvit btw?
03:32:56  <creationix>currently for the monitoring agent
03:33:06  <creationix>it's a single binary using luvi that sits inside customer machines
03:33:14  <creationix>it connects out to our servers and reports on health
03:33:31  <creationix>the team was node.js based, but they needed something not so heavy. They needed node in lua
03:33:40  <creationix>hence why luvit was originally a node.js clone in lua
03:34:27  <creationix>the original team is long gone and rphillips and I pretty much own the technical direction now. I'm working on a new agent that's coroutine based at the core
03:34:39  <creationix>still luv based because that's what I have
03:35:27  <creationix>(when I made luvit I wasn't at rackspace, I made it for webos for dbus services, but same store. Like node.js but less heavy)
03:35:34  <creationix>*same story
03:36:02  <creationix>webos used node.js for backend services which was crazy expensive. Each process was 20+mb of ram and over 1000ms of startup time
03:36:17  <creationix>luvit was a tiny fraction of both
03:36:28  <creationix>but then HP shut down webos
03:41:54  <daurnimator>creationix: and e.g. duk luv didn't do that for you? or did that come after?
03:42:06  <creationix>dukluv is much newer
03:42:21  <creationix>it's really neat, but not fast like luajit
03:42:40  <daurnimator>creationix: would be cool to work on https://github.com/PaulBernier/castl
03:42:50  <daurnimator>js => lua compiler
03:42:56  <daurnimator>I know exactly how to work on it too
03:42:57  <creationix>ohh, another
03:43:04  <daurnimator>just don't have the time
03:43:10  <creationix>the tessel people made one of those and gave up
03:43:25  <creationix>https://github.com/tessel/colony-compiler
03:43:29  <daurnimator>yeah I know
03:43:46  <daurnimator>CASTL works quite well. just needs someone that knows lua a bit better
03:44:00  <creationix>My new language is targetting esp8266 chips, but could be able to run in browsers and servers too
03:44:24  <daurnimator>interesting
03:44:32  <daurnimator>I sort of gave up on esp8266
03:44:39  <creationix>they are really cheap
03:44:43  <daurnimator>it just doesn't have the guts to have more than 2 TLS sessions
03:44:43  <creationix>nodemcu is a mess
03:44:49  <daurnimator>which makes it all very insecure
03:44:51  <creationix>yeah, not the most stable thing
03:45:04  <daurnimator>creationix: https://github.com/superhouse/esp-open-rtos seen this?
03:45:15  <creationix>but my language should work great on arm32 microcontrollers too
03:45:21  <creationix>it's just C99 at the moment
03:45:46  <creationix>I think the JS port for esp8266 uses that
03:46:12  <creationix>http://www.espruino.com/ESP8266
03:46:19  <creationix>I mean http://www.espruino.com/EspruinoESP8266
03:46:49  <creationix>daurnimator: what chips do you prefer, the stm32 family?
03:47:59  <daurnimator>creationix: at the moment I have my hopes up for the CHIP
03:48:14  <daurnimator>i.e. fuck embedded. for $9 I can have a real OS.
03:48:33  <creationix>yeah, next time I go to dallas, I'm grabbing a few Pi zeros for $5 each
03:48:54  <daurnimator>na, need wifi for most things
03:49:00  <daurnimator>pi zero doesn't have the right things IMO
03:49:22  <creationix>chip is nice though
03:51:14  <creationix>oh wow, chip is crazy powerful compared to esp8266
03:51:19  <creationix>I wonder how batter life compares
03:51:22  <daurnimator>pi zero + usb wifi has already blown out both $ budget and power budget.
03:51:30  <creationix>wifi is the main drain right?
03:51:36  <creationix>(so much not different)
03:51:38  <daurnimator>creationix: power draw of chip is around 2* more than esp8266 AFAIK
03:51:47  <creationix>not bad for 100x power
03:51:57  <daurnimator>yep
03:52:17  <creationix>ohh and storage built-in
03:52:26  <creationix>much cheaper than pi zero if you need wifi
03:52:34  <daurnimator>^^
03:52:41  <creationix>and bluetooth!
03:52:41  <daurnimator>or storage, or lots of other things
03:52:57  <creationix>does it have BTLE that mobile devices can use?
03:53:13  <creationix>looks like it's the version before that
03:53:44  <creationix>hmm, so hdmi isn't built-in, that was a turn-off when I last looked at them
03:53:54  <creationix>but for a microcontroller replacement, I don't care about hdmi
03:54:04  <daurnimator>creationix: "CHIP supports the Bluetooth 4.0 LE standard using the built-in Bluetooth."
03:54:27  <creationix>I may have to preorder some if I didn't already
03:54:34  <creationix>I'll bet these run luvit no problem too
03:54:46  <daurnimator>creationix: it does have HDMI, but only on headers, you need an adapter from headers to female hdmi (which they sell)
03:55:00  <creationix>oh, that's not bad
03:55:14  <creationix>so pocket chip just uses the headers directly I'll bet
03:55:23  <daurnimator>yep
03:56:13  <daurnimator>it also has composite video out
04:00:20  <daurnimator>creationix: anyway, it's my remaining hope for embedded projects to be sane.
04:05:42  <creationix>I think I'll take a closer look at chip, this will make a lot of things much easier for me.
04:10:38  * creationixjust preordered 4 chips
04:11:22  <daurnimator>hehe
04:11:57  <daurnimator>I tried to preorder several, but shopify refuse my credit card.
04:12:19  <daurnimator>and shopify tell me the merchant has to file the bug with them, they can't talk to me directly
04:12:30  <daurnimator>even though there's obviously a shopify bug
04:53:10  <creationix>alright, my vm is up to 42kb of static linux binary with rich garbage collected data types
04:54:00  <daurnimator>creationix: almost about to get bigger than lua ;)
04:54:58  <creationix>boolean, integer (up to int64_t), rational (up to int64_t/int64_t), unicode character, unicode string, byte array, uint32_t array (for pixels), cons pair, list, set, map, and immutable symbol (interned string)
04:55:18  <creationix>daurnimator: which lua?
04:55:51  <daurnimator>creationix: if you strip the stdlib + the lexer out of lua you can get the whole thing under 64K
04:56:00  <creationix>nice
04:56:55  <creationix>daurnimator: how do I build lua 5.3 as a static lib using musl-gcc and without standard lib?
04:57:24  <daurnimator>creationix: it's not a built in build option. takes some surgery
04:57:40  <daurnimator>I last did it.... 7 years ago?
04:57:59  <daurnimator>don't have the time to take you through it right now.
05:11:30  <creationix>yeah, full lua is 307k for lua and 193K for luac
05:11:49  * creationixhas to remember how to compile a static lua using musl
05:13:24  <daurnimator>creationix: okay... I got absorbed
05:13:36  <daurnimator>creationix: doing things really lazily, I got it down to 86K
05:13:51  <creationix>just tweaked main to not include the libs?
05:14:30  <creationix>so one of the things I love about microcontrollers is the lack of an OS getting in the way
05:14:46  <creationix>but I guess booting the kernel and then my app as init is close
05:15:09  <creationix>my app would be all the userspace there is
05:15:24  <creationix>might make wifi hard though, hmm
05:16:31  <creationix>I'll have to read up on what exactly the chip kernel will provide
05:32:09  <daurnimator>creationix: standard linux kernel
05:32:16  <daurnimator>they're trying to keep it mainline
05:32:44  <creationix>that's good. So I'll be reading up on what the kernel provides directly. It's probably more than what the esp chips provide
05:32:47  <creationix>and better documented
05:32:51  <daurnimator>yup
05:33:11  <creationix>I don't think people realize how much of a full system is in the linux kernal alone
05:36:12  <daurnimator>got it
05:36:19  <daurnimator>lua 5.3 down to 60K
05:36:53  <daurnimator>http://sprunge.us/BcEd
05:37:06  <daurnimator>cd src && make all MYCFLAGS="-flto -Os" SYSLDFLAGS="-flto -Os"
05:37:39  <daurnimator>File: ‘lua’ Size: 71040 Blocks: 144 IO Block: 4096 regular file
05:37:46  <daurnimator>$ strip lua
05:37:54  <daurnimator>File: ‘lua’ Size: 60288 Blocks: 120 IO Block: 4096 regular file
05:39:02  <daurnimator>so I made luaY_parser and luaL_openlibs unreachable. then did link time optimisation (which will strip all the dead code). then stripped debug symbols :)
05:39:30  * SkyRocknRolljoined
05:43:28  <daurnimator>with musl-gcc it's down to 57280 bytes
06:00:15  <daurnimator>creationix: make all CC=musl-gcc CFLAGS="-flto -Os" LDFLAGS="-static -flto -Os -s"
06:01:02  <creationix>nice
06:03:48  <daurnimator>after that improvements are quite minor
06:03:51  <daurnimator>currently at 87688
06:05:56  <daurnimator>i'm sure you can get much smaller once you don't actually need it to behave like a repl on a linux terminal :p
06:53:30  <creationix>using the same flags, my vm is 27Kb
06:54:33  <daurnimator>creationix: btw, some approximate library sizes: https://gist.github.com/daurnimator/527d7c4b9d13c2effd8e
08:32:14  * DarkGodjoined
09:52:37  * piernovquit (*.net *.split)
09:52:37  * devurandomquit (*.net *.split)
09:52:39  * Igelquit (*.net *.split)
09:52:39  * leitequit (*.net *.split)
09:52:43  * piernovjoined
09:52:48  * devurandomjoined
09:52:59  * Igeljoined
10:03:33  * devurandomquit (*.net *.split)
10:03:33  * piernovquit (*.net *.split)
10:03:57  * devurandomjoined
10:03:58  * piernovjoined
10:08:10  * Igelquit (*.net *.split)
10:08:10  * b_lindeijerquit (*.net *.split)
10:08:20  * bjornjoined
10:08:20  * bjornquit (Changing host)
10:08:20  * bjornjoined
10:08:55  * Igeljoined
10:17:38  * leitejoined
10:49:25  * dobsonquit (*.net *.split)
10:49:48  * dobsonjoined
11:04:15  * dobsonquit (*.net *.split)
11:04:15  * bjornquit (*.net *.split)
11:04:15  * piernovquit (*.net *.split)
11:04:16  * SkyRocknRollquit (*.net *.split)
11:04:16  * tfnico_quit (*.net *.split)
11:04:17  * kostcoquit (*.net *.split)
11:04:24  * piernovjoined
11:04:36  * bjornjoined
11:04:36  * bjornquit (Changing host)
11:04:37  * bjornjoined
11:05:07  * SkyRocknRolljoined
11:05:27  * dobsonjoined
11:10:10  * daurnimatorquit (Ping timeout: 260 seconds)
11:11:28  * kostcojoined
11:14:56  * tfnico_joined
11:28:04  * SkyRocknRollquit (Ping timeout: 264 seconds)
11:38:01  * daurnimatorjoined
11:39:56  * endouquit (*.net *.split)
11:39:56  * rchquit (*.net *.split)
11:39:56  * squeekquit (*.net *.split)
11:39:57  * rjequit (*.net *.split)
11:40:09  * rjejoined
11:40:11  * squeekjoined
11:40:31  * endoujoined
11:40:41  * rchjoined
11:41:59  * SkyRocknRolljoined
11:50:21  * Something12quit (*.net *.split)
11:52:27  * Something12joined
11:59:13  * Something12quit (*.net *.split)
11:59:16  * erlbot--quit (*.net *.split)
11:59:17  * rweichlerquit (*.net *.split)
11:59:17  * grep_awayquit (*.net *.split)
11:59:18  * Xequit (*.net *.split)
11:59:18  * songgaoquit (*.net *.split)
11:59:41  * Something12joined
12:00:02  * erlbot--joined
12:00:02  * rweichlerjoined
12:00:03  * grep_awayjoined
12:01:09  * Xejoined
12:03:52  * indexzeroquit (Ping timeout: 260 seconds)
12:04:04  * songgaojoined
12:07:30  * songgaoquit (*.net *.split)
12:09:22  * indexzerojoined
12:24:52  * endouquit (*.net *.split)
12:24:56  * rphillipsquit (*.net *.split)
12:24:56  * ksheedloquit (*.net *.split)
12:24:56  * creationixquit (*.net *.split)
12:25:01  * creationixjoined
12:25:08  * rphillipsjoined
12:25:23  * endoujoined
12:25:42  * ksheedlo-raxjoined