00:10:30  * qard-appnetaquit (Quit: (╯°□°)╯︵ pɹɐb)
00:16:33  * rcyrjoined
00:22:23  * rcyrchanged nick to systemfault
00:57:11  * piscisaureusjoined
01:01:48  * PerilousApricotjoined
01:03:42  * Haragethquit (Read error: Connection reset by peer)
01:13:26  * dap_quit (Quit: Leaving.)
01:13:32  * PerilousApricotquit (Remote host closed the connection)
01:17:19  * rmg_joined
01:21:01  * happy-dudequit (Quit: Connection closed for inactivity)
01:22:03  * rmg_quit (Ping timeout: 264 seconds)
01:38:12  * Haragethjoined
01:49:51  * brsonquit (Quit: leaving)
02:01:15  * piscisaureusquit (Quit: Leaving.)
02:33:57  * tunniclm_quit (Ping timeout: 244 seconds)
02:33:58  * Haragethquit (Read error: Connection reset by peer)
03:18:51  * rmg_joined
03:23:02  * rmg_quit (Ping timeout: 244 seconds)
03:53:03  * PerilousApricotjoined
03:58:39  * PerilousApricotquit (Ping timeout: 276 seconds)
04:30:29  * rgrinbergquit (Ping timeout: 258 seconds)
04:40:01  * rgrinbergjoined
05:04:10  * piscisaureus_topic: Liberal utopian void ~ http://logs.libuv.org/libuv ~ http://groups.google.com/group/libuv
05:04:49  * piscisaureus_topic: Liberal utopian void ~ http://logs.libuv.org/libuv ~ http://groups.google.com/group/libuv
05:05:48  * piscisaureus_topic: Liberal utopian void ~ http://logs.libuv.org/libuv ~ http://groups.google.com/group/libuv
05:06:25  * piscisaureus_topic: Liberal utopian void ~ http://logs.libuv.org/libuv ~ http://groups.google.com/group/libuv
05:06:58  * piscisaureus_topic: Liberal utopian void ~ http://logs.libuv.org/libuv ~ http://groups.google.com/group/libuv
05:12:48  * zju3quit (Ping timeout: 250 seconds)
05:14:33  * rgrinbergquit (Ping timeout: 240 seconds)
05:20:23  * rmg_joined
05:24:31  * rmg_quit (Ping timeout: 240 seconds)
05:29:07  * PerilousApricotjoined
05:34:04  * PerilousApricotquit (Ping timeout: 264 seconds)
06:30:21  * PerilousApricotjoined
06:34:41  * PerilousApricotquit (Ping timeout: 258 seconds)
06:55:59  * systemfaultquit (Quit: Bye!)
07:09:09  * rendarjoined
07:11:32  * Fishrock123joined
07:21:52  * rmg_joined
07:26:04  * rmg_quit (Ping timeout: 240 seconds)
08:22:37  * rmg_joined
08:22:55  * seishunjoined
08:27:42  * rmg_quit (Ping timeout: 272 seconds)
08:31:50  * PerilousApricotjoined
08:36:27  * PerilousApricotquit (Ping timeout: 250 seconds)
08:41:52  * Fishrockjoined
08:43:52  * Fishrock123quit (Ping timeout: 258 seconds)
09:00:06  * Fishrockquit (Remote host closed the connection)
09:16:28  * Fishrock123joined
09:32:38  * PerilousApricotjoined
09:37:06  * PerilousApricotquit (Ping timeout: 244 seconds)
10:00:34  * Fishrock123quit (Quit: Leaving...)
10:04:05  <avih>creationix: hey. nice work with dukluv :) i found a minor bug which i'll probably PR soon, but regardless, duktape goes 2.0 soon, and some of the stuff you use will get deprecated. specifically, 'print' which you use at your tests/sample and all the module loading/resolution stuff, and iirc you also use file loading which is also removed. i think all of those, maybe except print, are available at 'extra/', but maybe a better approach would be to rely on no
10:04:05  <avih>extras. it should not be too hard to make the adaptation
10:24:04  * rmg_joined
10:28:47  * rmg_quit (Ping timeout: 260 seconds)
10:29:29  * thealphanerdquit (Quit: farewell for now)
10:29:59  * thealphanerdjoined
10:33:11  * PerilousApricotjoined
10:37:31  * PerilousApricotquit (Ping timeout: 240 seconds)
11:09:12  * seishunquit (Ping timeout: 272 seconds)
11:30:56  * thefourtheyequit (Quit: Connection closed for inactivity)
12:08:18  * grantilajoined
12:09:08  * seishunjoined
12:25:32  * rmg_joined
12:30:07  * rmg_quit (Ping timeout: 260 seconds)
12:34:42  * seishunquit (Ping timeout: 272 seconds)
12:34:51  * PerilousApricotjoined
12:39:07  * PerilousApricotquit (Ping timeout: 250 seconds)
12:41:09  * seishunjoined
12:48:49  * grantilaquit (Ping timeout: 258 seconds)
12:51:43  * rgrinbergjoined
13:06:58  * rgrinbergquit (Quit: WeeChat 1.5)
13:07:18  * rgrinbergjoined
13:26:20  * rmg_joined
13:30:47  * rmg_quit (Ping timeout: 260 seconds)
13:36:32  * PerilousApricotjoined
13:53:13  * seishunquit (Read error: Connection reset by peer)
14:04:32  * seishunjoined
14:08:23  * rendarquit (Ping timeout: 250 seconds)
14:10:45  * tunniclm_joined
14:22:56  * PerilousApricotquit (Remote host closed the connection)
14:47:46  * rgrinbergquit (Ping timeout: 252 seconds)
15:05:46  * rgrinbergjoined
15:19:47  <creationix>avih thanks
15:19:57  <creationix>also have you seen seaduk (part of nucleus.js)
15:20:00  <creationix>aka dukluv 2.0
15:20:16  <creationix>https://github.com/nucleus-js/seaduk
15:21:11  <avih>creationix: i have not, and i'm unfamiliar with nucleus.js ...
15:21:17  <creationix>it's super new
15:21:34  <creationix>but basic idea is a micro-core that's just libuv + duktape + zip asset bundling
15:21:44  <creationix>and by concatenating a zip file of js code you can make standalone binaries
15:22:19  <creationix>also the core will have some optional addons like glfw, openssl, sdl, etc
15:22:43  <avih>cool
15:23:04  <avih>creationix: but dukluv on its own is very raw. great, but not a real framework, IMO
15:23:26  <avih>IMO it needs some node-lookalike effort
15:23:38  <avih>(i know there have been few attempts)
15:24:23  <creationix>it's a lot of work
15:24:29  <creationix>I would know, I did the same thing for luvit
15:24:39  <avih>(i created a basic stream abstraction which works identically on file/pipe/tty and then console.log/err etc which based on it and doesn't care what std* actually are)
15:24:42  <creationix>but I think that nucleus.js could eventually actually become node's core
15:25:23  <avih>creationix: btw, re the bug, at duv_is_pipe:
15:25:24  <avih>- uv_tcp_t* handle;
15:25:25  <avih>+ uv_pipe_t* handle;
15:26:00  <avih>(i bumped into it when i added pipe support to the stream abstraction)
15:26:48  <creationix>nice find
15:26:54  <creationix>yes, PR please so you can get credit in git
15:27:00  <avih>(the stream abstraction is for both in and out, though obviously slightly different APIs between them)
15:27:31  <avih>creationix: i don't care about credit, especially not over such a minor thing :) go ahead and land it
15:27:50  * rmg_joined
15:28:00  <creationix>k
15:29:59  <creationix>avih did that actually cause problems? I don't see anywhere in that functions that uses pipe specefic members
15:30:08  <creationix>->type is the same on all libuv structs I thought
15:30:21  <avih>it's not apparently
15:30:28  <avih>the struct size is different it seems
15:30:29  <avih>iirc
15:30:47  <avih>iirc when you check the type you also compare the size, that's what failed iirc
15:30:51  <creationix>oh, I see
15:30:54  <creationix>yeah, that will do it
15:31:13  <creationix>btw, I have a more robust system in seaduk
15:31:24  <avih>more robust for what?
15:31:30  <creationix>for type checking
15:31:36  <avih>btw, your editor system is amazing :)
15:31:42  <creationix>editor?
15:31:48  <avih>tedit maybe?
15:32:04  * rmg_quit (Ping timeout: 240 seconds)
15:32:05  <creationix>oh thanks. That was a lot of work
15:32:10  <avih>figures :)
15:32:13  <creationix>it's a shame I ran out of money and had to abondon it
15:32:29  <creationix>especially now that browsers have service workers and ES6
15:32:35  <creationix>I could do so much with it
15:33:10  <avih>the integration and live runs are really nice
15:33:34  <creationix>with service workers I would be able to write server-side JS in the app and the browser actually render the HTML in an iframe
15:33:34  <avih>i only played withit very little, but watched your vid. very impressive
15:34:03  <avih>how would it be better?
15:34:04  <creationix>I could write a new platform that uses duktape on the server (for low cost fremium hosting) but test locally in the browser even when offline
15:34:07  <avih>more responsive?
15:34:32  <creationix>my main goal with tedit was a real development environment that ran 100% offline in a browser without special extensions
15:34:35  <avih>you can run duktape in the browser too :)
15:34:44  <creationix>true, then I'd have a real sandbox
15:34:53  <creationix>once webassembly lands, tedit will have real potential
15:34:54  <avih>iirc duktape.org has such demp, and the code is at the main duktape repo iirc
15:35:04  <avih>demo*
15:35:08  <creationix>I think that one is using asm.js
15:35:17  <creationix>it works, just is a little bloated size-wise
15:35:21  <avih>i think so too
15:35:25  <creationix>good thing duktape itself is tiny
15:35:26  <avih>:)
15:35:42  <avih>well.. not as tiny as mujs, but quite friendlier license :)
15:35:51  <creationix>mujs?
15:36:07  <avih>http://mujs.com/
15:36:19  <creationix>gpl bleh
15:36:32  <avih>way more spartan code and less "features", but it gets it right, and IMO also way more maintainable
15:37:08  <creationix>I wonder how gpl applies when it's compiled to asm.js and is being used by browser code
15:37:25  <avih>duktape is not really maintainable IMO, despite its maintainer being very on top of it, IMO no one else can
15:37:42  <creationix>is it that bad. I found the internals very well documented
15:37:49  <creationix>not that I've actually tried to hack on it yet
15:38:17  <avih>yes, he's very meticulous, but have you looked at duktape.h ? :)
15:38:35  <avih>the #ifdef-ery is mind boggling
15:38:55  <creationix>well yeah, it supports a lot of targets
15:39:09  <creationix>I like how mujs is also stack based C API
15:39:23  <creationix>I never was a fan of V8's smart pointers, handles, etc
15:39:24  <avih>yes, and seemingly successfully, but other than him, not many can contribute imo
15:40:46  <avih>creationix: i added duktape and mujs support for mpv (even both at the same binary) including a thin abstraction layer to write code which works with both duktape and mujs. works very well, but was not integrated due to license (mujs) or insanity (duktape) https://github.com/avih/mpv/tree/js-duk
15:40:55  <avih>i'm using it as my main scripting interface to mpv
15:40:59  <creationix>nice
15:41:31  <creationix>avih have you tried the samsung engine?
15:41:45  <creationix>https://github.com/Samsung/jerryscript
15:41:59  <avih>the jerry thingy? no, iirc they don't support windows
15:42:59  <avih>i've looked at it few times, seems preliminary TBH
15:43:42  <creationix>I like to think I could contribute to duktape. I mean, I design languages and write VMs for fun. Time is my real problem
15:43:53  <creationix>I have 4 kids with a 5th on the way
15:43:54  <avih>:)
15:44:01  <avih>oh.. congrats :)
15:44:19  <avih>yeah, i did notice much of your stuff is made with kids in mind ;)
15:44:30  <avih>not it also makes sense ;)
15:44:33  <avih>now*
15:44:54  <creationix>also I learned to program very young. I'm 3rd generation programmer
15:45:13  <creationix>My mom was much better at punch-cards than her dad :)
15:45:21  <avih>oh :) i'm first, but i started (relatively - to that time) young. about 9 iirc
15:45:25  <avih>lol
15:45:34  <creationix>yeah, 9 is still pretty early
15:46:05  <avih>that's where i learned english from initially. goto END;
15:47:01  <avih>(zx81)
15:47:11  <creationix>:)
15:47:31  <creationix>I cut my teeth on C64 in the 80's and then Dos5 on an i386 in the 90's
15:48:19  <avih>sounds about the same period :)
15:48:38  <avih>though you were probably 4yo ;)
15:49:02  <creationix>I certainly played on c64 when I was 4, but programmed when I was closer to 8
15:52:33  <avih>i recall two programs which i really liked, one was a piano which would record the tunes you play, and the other was for the sinclair spectrum which would vsync-scroll third of the screen hight with huge fonts which i also created :) sold it to some local cable company at the time
15:53:25  <avih>(i'm still fascinated and deals with vsync related stuff to this day)
15:54:12  * seishunquit (Ping timeout: 272 seconds)
15:55:19  * seishunjoined
16:00:33  * PerilousApricotjoined
16:01:34  * cremesquit (Quit: cremes)
16:03:07  * brsonjoined
16:12:10  * Haragethjoined
16:15:08  * PerilousApricotquit (Remote host closed the connection)
16:17:07  * dap_joined
16:18:08  * cremesjoined
16:21:43  <avih>creationix: "nucleus.getenv(name) -> value" <-- iirc libuv doesn't have a portable getenv, does it? (unicode aware)
16:21:57  <creationix>avih, no I added that
16:22:04  <avih>right
16:22:05  <creationix>and yes, mine is unicode aware and should work on windows
16:22:18  <avih>cool
16:22:24  <creationix>at least the lua version is. I'm havn't yet fixed windows bugs in nucleus yet
16:22:36  * zju3joined
16:22:51  <creationix>nucleus will support windows fully, but at the moment, I'm still proving out APIs in unix where I can move faster
16:23:00  <avih>hmm.. i found it weird that libuv doesn't have it. it does seem to use it internally with unicode iirc, like with $HOME etc
16:23:14  <creationix>yeah, not sure
16:23:18  <creationix>seems like something libuv could add
16:23:26  <avih>yeah, i think it should too
16:23:35  <creationix>I've long wanted an ecosystem of libuv addons. Things that make sense, but maybe not everyone wants included
16:24:17  <creationix>openssl integration, proper event loop sharing with GUI toolkits, leveldb, env variables, etc
16:24:52  <avih>hmm... i see the value, but also the issue. IMO depending on how big it could end up. if not a big number of addons, then IMO it should be integrated into libuv
16:25:09  <avih>also, iirs there was a similar project forked from libuv with that boal in mind - simpler
16:25:36  <avih>goal*
16:46:57  * rgrinbergquit (Ping timeout: 276 seconds)
16:50:51  * brsonquit (Ping timeout: 276 seconds)
16:57:45  <txdv>creationix: whlat is holding that addon system back?
16:59:37  * qard-appnetajoined
17:00:04  * seishunquit (Ping timeout: 272 seconds)
17:01:55  * PerilousApricotjoined
17:04:09  * brsonjoined
17:05:17  <creationix>txdv inertia? An official place to post libraries? Conventions?
17:05:33  <creationix>I know indutny wrote several uv-* libraries
17:06:45  <creationix>though I agree with avih. The environment variable stuff seems like it should be in core
17:06:54  <creationix>since libuv uses it already for other APIs
17:07:37  <avih>+1 :)
17:09:06  * seishunjoined
17:12:05  * PerilousApricotquit (Remote host closed the connection)
17:22:00  <avih>creationix: btw, re your module loading code, while i didn't read it thoroughly, it seemed to me more code than it could/should be. IMO it's enough to expose a file_load/run api, and then implement require in js on top of just that. I implemented a similar approach for the mpv scripting support, and then tried it instead of your module load, and it worked on the use cases which i tried see https://github.com/avih/mpv/blob/js-duk/player/javascript/defaults.
17:22:00  <avih>js#L32
17:27:08  <creationix>avih, right. I just didn't have a good way to embed JS in the binary
17:27:19  <creationix>it might be easier now
17:27:49  <creationix>with seaduk, module loaders are all user-space
17:28:00  <avih>creationix: embedding js files would be useful for dukluv regardless IMO, since it would allow to create encapsulated applications
17:28:02  <creationix>only the raw primitves needed (readfile, scandir, etc) are provided
17:28:14  <creationix>well, seaduk solves that nicely
17:28:25  <avih>right, i noticed, but didn't look deeply
17:28:30  <creationix>asset bundling/loading is it's main feature on top of duktape
17:28:46  <avih>on top of dukluv you mean?
17:29:02  <creationix>seaduk doesn't use dukluv
17:29:20  * rmg_joined
17:30:17  <avih>is there a projects which connects them?
17:30:33  <avih>i.e. duktape, libuv, and assets?
17:33:28  * rmg_quit (Ping timeout: 244 seconds)
17:35:47  * fourqquit (Ping timeout: 260 seconds)
17:36:09  * rgrinbergjoined
17:42:44  <txdv>creationix: what libraries did he write?
17:52:21  * qard-appnetaquit (Max SendQ exceeded)
17:56:21  <creationix>txdv: https://github.com/indutny/uv_ssl_t https://github.com/indutny/uv_link_t https://github.com/indutny/uv_http_t
17:57:21  <creationix>avih yeah, that's what nucleus.js is. Seaduk is the nucleus implementation using libuv + duktape in C
17:57:48  <creationix>but the code in dukluv isn't used. Seaduk has it's own libuv bindings for duktape
17:58:03  <creationix>it's a much easier interface in JS I think
17:58:08  <creationix>and easier to swap out backends
17:59:17  <avih>hmm.. didn't look at nucleus, but i thought libuv is great exactly because it's so straight forward mapping from the bindings to libuv
17:59:28  <avih>dukluv* is great...
17:59:28  * roxlujoined
17:59:48  <txdv>soon we gonna be like libevent
18:09:52  * brsonquit (Quit: leaving)
18:29:09  <creationix>avih right, seaduk is similar scope to dukluv, it just had a more clearly defined JS API and a minimal asset bundling feature
18:29:34  <creationix>and the core duktape-libuv bundings can probably be extracted into it's own repo
18:29:38  <avih>creationix: i should look at it then before i continue discussing it :)
18:29:50  <avih>right.
18:29:54  <creationix>(in the lua world, I have luv and luvi and luvit)
18:30:05  <creationix>luvi uses luv, but you can also use luv from things like plain lua
18:30:26  <avih>yeah, which i tried to figure where the boundaries go between those lua thingies, but never quite got it :)
18:31:15  <creationix>so seaduk is the JS version of luvi
18:31:31  <avih>what does the name mean?
18:31:35  <avih>sea?
18:31:44  <creationix>it's implemented in C
18:31:51  * creationixis too punny for his own good
18:32:18  <creationix>I also have one implemented in Rust that might use duktape
18:32:35  <avih>you're all over the place :)
18:32:39  <avih>though in a good way ;)
18:33:42  <avih>i liked the idea of nucleus, if i got it right, which sounds like it should build on top of dukluv or equivalent - i.e. plain language+libuv binding
18:34:02  <avih>then a minimal framework/os on top of that
18:34:13  <avih>then the proper framework (node) on top of that
18:40:39  <avih>also, not sure about nucleus, but with dukluv, in your colors etc samples, you use print which goes directly to stdout, and not via libuv tty handle - which translates ansi escapes on windows. so on windows your demos are without colors and literal ansi sequences instead
18:41:29  <avih>and also break if stdin/out/err are pipes or redirects etc
18:41:50  <avih>which is why i wrote the stream abstraction over pipe/file/tty
18:50:20  <avih>file append redirect (>>) is extra nasty since you get the file handle and have to append yourself.
18:52:21  <creationix>avih right. Like I said. I havn't made it work on windows well yet
18:52:37  <creationix>It will of course use libuv tty for stdout on windows eventaully
18:53:00  <creationix>though nucleus itself will probably not have any of this, it will be done in userspace js libraries
18:53:10  <avih>it's not bad, just needs some refinements :) and it works. statically linked ~600k, and ~250k upx'ed, which is kinda cool :)
18:53:20  <creationix>yeah, trying to keep it small
18:53:29  <creationix>250k upx, I should use that more often
18:53:49  <creationix>does that play nice with the zip appending trick?
18:54:06  <avih>not sure which trick is that
18:54:22  * saghuljoined
18:54:29  <creationix>so a nucleus app will be a nucleus implementation (like seaduk) concatenated with a zip file containing all the JS assets
18:54:41  <creationix>it works because exe files ignore the end and zip files ignore the beginning
18:54:53  <creationix>as long as upx binaries still ignore the end, it should work
18:55:12  <avih>not sure, but upx has quite a few options, one might work
18:55:21  <avih>but they definitely have collision potential
18:55:35  <avih>also, will you take a PR for this? https://github.com/creationix/dukluv/issues/25
18:57:20  <avih>creationix: that's my patch for it http://pastebin.com/WcGF2F4v
18:57:59  <creationix>miniz is a mess. I've had to patch so much
18:58:02  <creationix>but it's small and works
18:58:20  <creationix>PR should be fine
18:58:28  <avih>i dislike the forceinline thingy
18:59:12  <creationix>really I should just write my own zip handling code, but it's just hard enough I'd rather use an existing library
18:59:24  <creationix>and I have no intentions of re-implementing inflate/deflate
19:00:38  <avih>iirc there's libz which should be simpler and cleaner, but not sure if it supports zip.
19:01:01  <creationix>right, if it's small and clean I'd be willing to implement zip myself
19:01:03  <creationix>zip if pretty simple
19:01:12  <avih>you should ask midipix/sortix on #midipix
19:01:54  <avih>sortie*
19:05:09  <creationix>I wonder how it compares to miniz on size
19:05:20  <creationix>certainly looks like a cleaner zlib
19:09:27  * saghulquit (Quit: My MacBook Pro has gone to sleep. ZZZzzz…)
19:09:50  <creationix>avih, so you say mujs is pretty complete ES5 and smaller than duktape?
19:10:02  <avih>yes for both
19:10:18  <avih>it also has few es6 bits, but iirc less than duktape
19:11:03  <avih>and it doesn't have .substr because it's only common but non standard :)
19:12:32  <avih>i'd imagine it has more bugs though, since it's not used at many places. i reported many bugs which were fixed quickly, and it does get occasional bugfixes, and seems to work well, but.. it's less tested
19:15:24  <avih>(it does have .substring of course)
19:22:40  * PerilousApricotjoined
19:27:11  * PerilousApricotquit (Ping timeout: 240 seconds)
19:28:16  * Haragethquit (Remote host closed the connection)
19:30:51  * rmg_joined
19:35:57  * rmg_quit (Ping timeout: 276 seconds)
19:57:26  <avih>creationix: in "nucleus.compile(string, path)" ( https://github.com/nucleus-js/design/blob/master/api/nucleus.md ) you say "The source is wrapped in function () { ... }". it's not literally, right? since duktape has compile in a global context, and if you literally wrap it, then the source mapping will be wrong, at the very least the column if you don't use newlines at the wrapper
19:58:16  <avih>you probably want to say "semantically wrapped as a function"
19:58:37  <creationix>I think it's literally wrapped in the implementation
19:58:42  <creationix>but I'm open to tweaking things
19:58:59  <avih>literally is not good enough, for a perfectionist as yourself ;)
19:59:17  <creationix>well I wanted to use duktape's function scope which requires this
19:59:33  <avih>let me see what i did with mpv. iirc there's duk_compile or so which does the same thing without your own wrapping
19:59:49  <creationix>ideally nucleus will expose all the different targets and not do any automatic wrapping
20:00:48  <creationix>right, so I'm using DUK_COMPILE_FUNCTION
20:01:37  <avih>wait, maybe i'm interpreting it wrongly. what does it actually do?
20:02:11  <avih>i had the impression it compiles string as if it was loaded as the file path. is that correct?
20:02:17  <creationix>"The bytecode generated for global and eval code is currently slower than that generated for functions"
20:02:29  <creationix>(reason I went with FUNCTION mode)
20:02:35  <avih>doesn't matter. it's far from a hot code path
20:03:06  <avih>it's typically used for require and that's it. it 's not a performance bottleneck
20:04:12  <creationix>yeah, should probably use global by default and not wrap
20:04:25  <creationix>for some reason I thought it made all code slow, even embedded functions
20:05:15  <avih>i think not, but if unsure, consult sami
20:05:38  <avih>i find it hard to believe though that perf is affected after compilation
20:06:50  <avih>it's not impossible though, but still, literal wrapper is not clean. better have good code, and consider perf issues once you actually have them IMO
20:07:17  <avih>(disclaimer, i work with mozilla, at the firefox performance team)
20:07:47  <creationix>avih, yeah not disagreeing
20:07:54  <creationix>I should change that
20:08:07  <creationix>the design for nucleus is still fluid so feel free to suggest anything
20:08:14  <avih>i am :)
20:08:35  <creationix>:)
20:09:25  * creationixre-creates #node.js room on freenode
20:09:31  <creationix>* #nucleus.js
20:09:37  <avih>lol
20:10:11  <creationix>node core said they *might* eventually use nucleus, but it's distant and unknown probility
20:10:48  <creationix>personally I don't think there is a chance unless nucleus is a raging success and gets to compariable popularity as node
20:11:06  <avih>for now, i think they're being polite ;)
20:11:12  <avih>but who knows
20:11:31  <creationix>I'm not worried. I'm building it for a need I have, not to change node
20:11:41  <avih>yup
20:11:49  <creationix>though eventual compat with the npm ecosystem is a stated goal
20:11:58  <creationix>(via some userspace library on top of nucleus)
20:13:31  <avih> tried to run highlightjs and prism.js on dukluv with my minimal require+console+std* streams, and it bumped into a duktape issue of unsupported regex - on both
20:14:06  <avih>seemingly duktape has an open issue on that - how much non standard but common regex syntax to support
20:14:21  <creationix>that's a shame, I thought most of that was implemented already
20:14:28  <creationix>I guess they use some esoteric stuff
20:14:38  <avih>didn't look deeper for now
20:14:57  <creationix>maybe just comment on the duktape issue that those libraries don't run?
20:15:34  <avih>i wrote a console syntax highlighter (like gnu source-highlight) for less, and it uses highlight.js and/or prism.js as backend (including parsing their styles css) and it works perfectly in node, so i tried that with dukluv
20:16:36  <avih>i might add a comment, once i find out exactly which part of the syntax is rejected
20:18:09  <creationix>avih, just for you https://github.com/nucleus-js/design/issues/27
20:18:41  <avih>:)
20:19:47  <avih>creationix: btw, since you were interested in mujs, this is how similar their APIs are https://github.com/avih/mpv/blob/js-duk/player/mud_js.h
20:20:18  <creationix>yeah, both seem to follow lua's API
20:20:33  <creationix>porting luvit to dukluv was mostly copy-paste + search-replace
20:21:09  <creationix>rust with rjs is another story. I bought tickets to rustconf since I clearly don't have the required skills there
20:22:24  <avih>never got near rust TBH
20:22:36  <avih>though it does sound promising
20:23:35  <creationix>I love the design of the language, but it's learning curve is steep
20:24:08  <creationix>I've *never* been willing to pay to learn a language till rust. (it's that exciting and that difficult)
20:25:55  <avih>:)
20:27:30  <creationix>hmm, now I remember the other reason I went with function mode and not global mdoe
20:27:39  <creationix>you can "return" in global mode to export something
20:27:49  <creationix>it's compiled as a function, but there is no return
20:29:25  <avih>not sure i follow
20:29:44  <avih>you expect the file at 'path' to just return outside of a function?
20:29:53  <creationix>https://github.com/nucleus-js/seaduk/blob/master/test-app/deps/theme-256.js#L34
20:30:23  <creationix>would be "module.exports = theme" in common js
20:30:28  <avih>creationix: module.exports = there;
20:30:33  <avih>theme*
20:30:47  <creationix>right, but that depends on a CJS module system which isn't part of nucleus
20:30:54  <creationix>it's fine, I can work with global mode
20:31:00  <creationix>the last expression is returned like in eval
20:31:01  <avih>maybe it should be? it's really not that complex
20:31:08  <creationix>and I can manually wrap when I want to hide things
20:31:31  <creationix>a simple CJS isn't complex, but people have opinions
20:31:44  <avih>you can also set the global theme to be your theme
20:31:47  <creationix>the point of this is to push such bikeshedding to userspace
20:32:21  <avih>but dunno, returning when there's no function is not without use cases, but looks weird, and non conformant to known standards
20:32:37  <creationix>yeah, I'm changing my code to work in global mode
20:32:45  * PerilousApricotjoined
20:32:45  <creationix>it's a little more work, but quite workable
20:32:50  <creationix>and most people will use some module system
20:33:02  <avih>most probably
20:33:33  <avih>also, i don't have enough background on this, but i found main.js to be a bit harsh requirement
20:33:45  <creationix>I just need to wrap my modules in an IIFE
20:33:58  <creationix>what's harsh?
20:34:01  <avih>i was thinking more of node_modules/seaduk.bootstrap.js as a starting point
20:34:13  <creationix>worried about name conflicts?
20:34:23  <avih>no
20:34:50  <avih>but, i'm not sure what's the standard here, if there is one, which is the reason i said i'm not sure about it
20:36:26  <avih>the hardcoded filename requirement (re what's harsh)
20:36:59  <creationix>nucleus is the standard. We just need something to bootstrap the process
20:37:22  <creationix>I guess I could teach it to look for a "main" field in a package.json or something
20:37:25  <avih>no disagreement there
20:37:41  <creationix>also lots of this is porting from luvit where I've done this in production
20:37:45  <creationix>it's main.lua in luvit
20:37:53  <avih>yeah, probably more node-like in that, but, i'm not sure what the node standard is
20:37:57  <creationix>nobody has ever complained (not that we have that many users)
20:38:21  * PerilousApricotquit (Ping timeout: 276 seconds)
20:38:31  <creationix>but so far I've avoided assuming "node_modules" or "package.json" have any meaning
20:38:55  <creationix>minimal assumptions and conventions is the goal at this layer
20:38:58  <avih>that doesn't sound like a good reason to keep ignoring the subject ;) (nor a good reason to blindly accept it ;) )
20:39:16  <avih>yeah, i agree there
20:39:29  <creationix>I mean, who do C programs start at main()?
20:39:32  <creationix>*why
20:39:46  <avih>ask Ritchie? :)
20:39:57  <creationix>something is needed. I can do init.js or bootstrap.js if that makes more sense, but I think it needs to be hard-coded
20:40:08  <avih>i think so too
20:40:40  <creationix>I didn't go with init.lua for luvit since that already has special meaning (akin to index.html in web servers)
20:40:45  <avih>my issue was with "main.js" being that hardcoded thing. i thought it should be more hidden to allow more "free" "public" structure
20:41:51  <creationix>now I do allow setting a custom main when running via nucleus
20:41:57  <avih>if your bootstrap point is more hidden, then the top level structure could be made to fit the specific application
20:42:18  <creationix>mostly this is used for a group of unit tests sharing common files, but having different entry points
20:43:29  <avih>well. i shouldn't keep this specific discussion going since i don't have enough grounds to stand on. it's just a hunch
20:43:43  <creationix>it's interesting
20:44:28  <avih>yes, and important in the overal design too, though most probably almost fully orthogonal to most other things
20:45:09  <avih>it might as well be a config value or a command line option which is added when creating the compound app
20:45:21  <creationix>so something well-known and probably static is given. I guess the question is about visibility
20:45:32  <creationix>maybe a .bootstrap.js
20:45:40  <avih>that sounds good to me
20:45:40  <creationix>or .nucleus.init.js
20:45:46  <avih>better :)
20:46:11  <creationix>the fact that the app uses nucleus should not be highly visible
20:46:17  <avih>i like the 'nucleus' in it, since it has good semantics
20:46:54  <creationix>I just worry about people not seeing the file and getting confused
20:46:58  <avih>not highly, but it's still a nucleus only/mostly, right?
20:47:07  <creationix>cp oldapp/* newapp/; nucleus newapp
20:47:14  <avih>:)
20:48:04  * Haragethjoined
20:48:38  <avih>i don't yet have a full grasp of the relations between nucleus/duktape/libuv, so i don't have a good mental model of what might be more common and what not
20:50:32  <avih>but the point is, i think, that this is a nucleus config which defines the bootstrap of the app. and it's a nucleus-only config if i understand correctly
20:51:14  <avih>i.e. if the app is also fit to run as non-nucleus, then it might need a different bootstrap code
20:52:00  * zju3quit (Ping timeout: 276 seconds)
20:54:19  <creationix>avih: I see
20:54:53  * zju3joined
20:56:10  <avih>creationix: in https://github.com/nucleus-js/seaduk/commit/99da0b7 do you really need the function wrapper? iirc duk_compile (or at least dik_pcompile) already isolates it and compiles it as a function, so unless you tested that your var statements end up on the global object, i think they won't
20:58:03  <creationix>the docs clearly state the default is just like script tags
20:58:07  <creationix>it would make globals
20:58:19  <creationix>"compiles into a function with zero arguments, which executes like a top level Ecmascript program"
20:58:50  <avih>right, so it's already a function, and a function's vars are not global
20:59:20  <avih>basically, just like your wrapper does i think. wrapped in a function with zero args and executed at the global context...
20:59:52  * tunniclm_quit (Read error: No route to host)
21:00:07  <creationix>oh, on the utils
21:00:13  <avih>yes
21:00:31  <creationix>the function statements in the main library would be globals, but not the vars
21:00:49  * creationixhas been doing too much lua where functions and vars have identical scoping rules
21:00:57  <avih>right, but it's an anonymous function, so no pollution
21:00:59  * tunniclm_joined
21:03:31  * brsonjoined
21:05:58  <creationix>avih, even simple, a single object literal :) https://github.com/nucleus-js/seaduk/commit/21d69f9e1bababb3f990663800c4ea71bccd4f40
21:06:20  <creationix>should perform a lot better for what it's worth (not a bottleneck at all)
21:07:09  <avih>nice, though not sure why it would affect/improve perf
21:07:25  <creationix>a single literal versus a dozen property sets
21:07:31  <avih>probably some, since it's just evaluation of an object literal
21:07:31  <creationix>depends on the actual bytecode
21:07:47  <creationix>property writes are pretty slow I would think
21:07:50  <avih>yes. well.. it would be faster indeed :)
21:08:21  <avih>but the higher value is the clean-ness :)
21:08:37  <creationix>right, I doubt the performance would ever matter
21:09:52  <avih>yep btw, i have a console colors module which is both very direct and with very nice syntax https://0x0.st/mjZ.js
21:10:58  <avih>you do sgr("bold blue") + myText + sgr(); supports xterm256 and true colors as web colors syntax (#ff0000 or #f00) and color names etc
21:11:20  <avih>as well as true color to 256 colors conversion
21:11:42  <avih>it's part of the console syntax highlighter, but i haven't published it yet
21:12:42  <creationix>yeah, this is just what I had written for dukluv. nucleus itself won't ship with any of this
21:12:52  <creationix>except for maybe the unit tests
21:15:34  <avih>i like things which are both straight forward (i.e. no limiting abstractions) but also with more humane interface, which is why i like dukluv ;) it does what it says on the tin, and that's it
21:16:21  <avih>abstractions do have a place of course, but in a separate domain than the straight forward stuff
21:32:00  <txdv>dukluv?
21:32:19  * rmg_joined
21:32:19  <txdv>creationix at it with the funny names
21:33:00  <txdv>javascript on devices with 64kb
21:33:03  <txdv>what could go wrong?
21:33:53  * PerilousApricotjoined
21:33:57  <avih>duktape happens to work just as well on desktop systems, and is a bit simpler than v8
21:34:45  <txdv>what isnt simpler than v8?
21:34:51  <txdv>v8 has the potential to become skynet
21:34:51  <avih>so if you need an embedded scripting for your app, possibly duktape (or mujs) would be a better choice than using v8
21:35:01  <avih>it was an understatement :)
21:35:46  <avih>regardless if your app runs on a 64K SOC or a plain desktop app
21:36:36  <creationix>txdv if you don't like the bad puns stay away from luvit's docs
21:36:48  <creationix>the getting started guide has gems like "get lit and make luv"
21:37:26  <avih>wait, how's rubi related?!?
21:37:30  * rmg_quit (Ping timeout: 276 seconds)
21:38:10  * PerilousApricotquit (Ping timeout: 250 seconds)
21:41:12  <avih>creationix: "nucleus.base - A string containing the base path of the resource bundle. If running from a directory it will be the directory path, if it's a zip, it will be path to the zip." <-- i'm guessing path to the zip in a way which could be concatenated with a path inside the zip? such as nucleus.join_paths(nucleus.base, 'main.js') ?
21:42:35  <avih>i.e. the app shouldn't care about its bundling, and nucleus.base + "main.js" (assuming that's our bootstrap) will always work?
21:43:05  <creationix>the bundle fs APIs are apart from system FS APIs
21:43:14  <creationix>there is no unified vfs API for both
21:43:24  <creationix>in other words, when running in zip mode, you can't read outside the zip
21:43:39  <creationix>not using the provided APIs at least. Userspace could obviously do it with this path
21:43:47  <avih>hmm..
21:44:04  <creationix>so main.js is always "/main.js" or just "main.js"
21:44:11  <avih>i don't fully follow the logic of where your abstraction ends then
21:44:47  <creationix>right the provided path utilities are really only meant for inside the bundle
21:45:03  <avih>worth noting at the docs IMO
21:45:03  <creationix>(though I did bother to pass all of node's unit tests when I rewrote the path_join function)
21:45:30  <avih>nice
21:46:51  <avih>so you can't use nucleus.base in nucleus.readfile(path)
21:47:01  <creationix>the only reason I provide path utils at all is it makes bootstrapping a module system much easier
21:47:07  <creationix>correct
21:47:11  <avih>the end of the abstraction is non trivial
21:47:25  <creationix>nucleus.readfile is relative to base
21:47:28  <avih>i.e. its edge
21:48:02  <creationix>it's defined as the minimal primitives required to make something like node in pure JS
21:48:12  <creationix>so technically the path utilities are cheating
21:48:24  <creationix>but I need them for the mini build system inside nucleus
21:48:43  <creationix>bootstrapping concerns are tricky with such a minimal core
21:48:44  <avih>yeah, they're needed all right, but the abstraction is misleading
21:48:49  <creationix>luvi has similar issues
21:48:55  <avih>maybe it needs different namespace or so
21:50:01  <creationix>technically you can read outside the bundle using readfile with paths like "../foo", but I don't think you should be able to
21:50:02  <creationix>https://github.com/nucleus-js/design/issues/22
21:50:12  <creationix>because it breaks when in zip mode
21:50:19  <avih>when i thought about bootstrap system for dukluv, i imagined an "internal" set of files which are the only files exposed to the dukluv api. these internal files create a minimal system with perfect abstraction, on which the "app" files build
21:51:35  <creationix>so you know how node.js bundles several JS libraries right?
21:51:36  <avih>so these internal files keep a reference to uv, but then delete it from the global objects such that it becomes invisible to the app
21:51:50  <avih>no
21:52:08  <avih>well.. i think.. somewhat. definitely not fully.
21:52:09  <creationix>but yes, that's the idea. This is why everything is namespaced under nucleus
21:52:13  <avih>(how node bundles)
21:52:22  <creationix>so the bootstrap system can delete it after getting the references it needs
21:52:44  <avih>right
21:53:02  <creationix>so technically, it's tricky involving compiling JS somehow and snapshots, but at a high level, the JS (raw or compiled) is embedded in the node binary
21:53:04  <avih>the same way i delete Duktape before giving control to the user scripts in mpv
21:53:11  <creationix>with a nucleus based node, there would be a zip appended with the js code
21:53:24  <creationix>and user apps would still be outside the zip and outside the node binary
21:53:37  <creationix>the nucleus.readfile API would only be used to read from this bundled zip
21:53:50  <creationix>uv.fs_open and friends would be used to read real files
21:54:22  <avih>right, i had the same idea in mind (bundling) - as these internal files would be embedded into the exe, but overridable by files e.g. at mode_modules/dukluv_internal/*
21:54:49  <creationix>overridable by files outside the bundle?
21:54:57  <avih>only i thought of embedding them at compile time rather than bundling time
21:55:36  <creationix>since nucleus can run either out of a folder or zip or appended zip the compile step is optional when developing core modules (this is the main reason for this design actually)
21:55:53  <creationix>they are still core modules like node's http module, but the dev workflow is much nicer
21:56:07  <avih>well.. i didn't think too far. but my main idea was not a platform like nucleus wants to be, but more a node-like system, where its internal files are embedded so you don't need them, but you can still work on them without recompiling the exe via a hardcoded path
21:56:10  <creationix>also if you wanted to, you could make a custom single-file app with your own custom files
21:56:55  <avih>well, sounds like it. i still don't have a solid mental model of it
21:57:26  <creationix>like I've said. We've used this model for a year in production on the luvit project so I have some real world experience with it.
21:57:42  <avih>yup. definitely valuable
21:57:42  <creationix>the luvit package manager allows publishing luvi based apps which users can built using lit
21:58:00  <creationix>so `lit make lit://creationix/wscat` and you get a single binary `wscat`
21:58:21  <creationix>embedded in it is a luvi binary and a zip file containing wscat and it's dependencies which were all fetched on the fly
21:58:37  <creationix>https://luvit.io/lit.html#wscat
21:58:41  <avih>yeah.. i still don't get the relations between those three, and seems you really like this triplet semantics, so i'm not really fit to discuss the subject till i actually understand these relations
21:58:56  <creationix>it's a branding problem
21:59:11  <creationix>luvit 1.0 was a clone on node in lua. All one big project with lua embedded at compile time
21:59:11  <avih>it's a naming problem :)
21:59:34  <creationix>luv was an attempt to make the libuv bindings available to the general lua community
21:59:48  <creationix>but then I made something in between and called it luvi to be funny
21:59:56  <avih>so sounds like luvit should have been based on luv, right?
22:00:02  <creationix>luvit 2.0 is
22:00:08  <creationix>it's a complete rewrite from the groud up
22:00:20  <avih>ok, so what's luvi?
22:00:21  <creationix>luvit 1.0 had it's own libuv bindings internally, but libuv changed significantly since then
22:00:43  <creationix>luvi is luv + luajit + openssl + miniz + zip asset bundling
22:00:47  <creationix>basically the same as nucleus
22:01:01  <creationix>and luvit 2.0 is pure lua published as a userspace metapackage
22:01:20  <avih>sec. let me digest this
22:01:40  <creationix>luvi contains all the C code required to implement luvit
22:02:13  <avih>it's like, exactly the same mental block i get when i try to understand the relation between dukluv and nucleus and seaduk
22:02:35  <avih>it seems there's some redundancy there
22:02:54  <creationix>luvi embeds luv
22:03:06  <avih>and so does luvit, yes?
22:03:08  <creationix>as well as luajit and everything else written in C
22:03:14  <creationix>luvit is a zip file
22:03:17  <creationix>with luvit prepended
22:03:20  <creationix>*luvi prepended
22:03:34  <avih>so luvit is the packaging system?
22:03:53  <avih>which defines luvi as its executor?
22:03:54  <creationix>luvit is a metapackage that implements the same CLI and set of libraries as luvit 1.0
22:03:55  <creationix>but as a luvi app
22:04:00  <creationix>https://lit.luvit.io/packages/luvit/luvit/latest
22:04:48  <creationix>lit is the closest thing to npm we have. It downloads dependencies, but also builds luvi based apps
22:05:21  <avih>don't you mean luvit based apps?
22:05:34  <creationix>correct
22:05:35  <avih>(at least i get luv ;) )
22:05:42  <creationix>lit, for example is not luvit based
22:05:50  <creationix>it uses it's own set of libraries that are coroutine based
22:06:00  <creationix>whereas luvit is a node.js clone (event emitters, streams, etc)
22:06:15  <creationix>there are a few libs that are shared, but lit does not embed all of luvit
22:06:27  <creationix>lit and luvit are peers technically. Both depend on luvi
22:06:36  <creationix>unlike node where npm depends on node directly
22:06:40  <avih>ok, so luv is libuv bindings for lua. luvi is a bundling of luvi and a specific set of packages. luvit is a platform which defines packaging of luvi and some user app, and lit is the luvit app which updates luvit packages?
22:07:04  <creationix>right, luvit is node for lua
22:07:13  <creationix>lit is npm for luvit, but not using luvit
22:07:25  <avih>oh
22:07:36  <avih>ok, yeah, i only assumed it's a luvit app
22:07:37  <creationix>anyway, dinner time. I'll try to come on later if you have more questions
22:07:46  <creationix>or post issues somewhere
22:07:52  <avih>i need to let it sink some :) bon apetite
22:07:59  <creationix>later
22:08:01  <avih>and nice talking to you :)
22:08:07  <creationix>:)
22:18:38  * seishunquit (Ping timeout: 272 seconds)
22:27:53  * PerilousApricotjoined
22:32:42  * PerilousApricotquit (Ping timeout: 260 seconds)
23:01:08  * PerilousApricotjoined
23:05:54  * PerilousApricotquit (Ping timeout: 276 seconds)
23:06:42  * PerilousApricotjoined
23:10:51  * PerilousApricotquit (Ping timeout: 246 seconds)
23:31:54  * rgrinbergquit (Ping timeout: 276 seconds)
23:33:45  * rmg_joined
23:38:12  * rmg_quit (Ping timeout: 250 seconds)
23:38:30  * rgrinbergjoined
23:53:47  * tunniclm_quit (Ping timeout: 260 seconds)