00:14:33  * ryan_fordjoined
00:38:26  * creationixjoined
02:15:12  * SkyRocknRollquit (Ping timeout: 260 seconds)
02:45:37  * DarkGodquit (Ping timeout: 240 seconds)
05:15:16  * ryan_fordquit (Quit: WeeChat 1.5)
08:21:29  * DarkGodjoined
08:33:05  * ryan_fordjoined
09:40:46  * rendarjoined
09:41:00  * rendarquit (Changing host)
09:41:00  * rendarjoined
09:53:50  * CapsAdminquit (Ping timeout: 240 seconds)
10:12:07  * creationixquit (Remote host closed the connection)
14:00:05  * ryan_fordquit (Ping timeout: 240 seconds)
15:09:31  * creationixjoined
16:09:20  * SkyRocknRolljoined
16:49:16  * Soniquit (Ping timeout: 260 seconds)
16:50:22  <creationix>rphillips, how's it going
16:50:35  <creationix>I see a lot of github activity on luvit. Need help with anything?
16:50:39  <creationix>SinisterRectus, ^
16:51:31  <SinisterRectus>i just took an interest in the ssl fix because it was affecting some of my users, and then it took off from there. nothing more to do at the moment. just a lit bump and release i guess.
16:51:45  <rphillips>creationix: just released the tweaks
16:51:59  <rphillips>yeah, lit needs a bump i think
16:52:34  <creationix>I think there might be some divergence in the modules that luvit and lit share, I'll see if I can check
16:52:42  <creationix>http-codec, secure-socket, etc...
16:52:50  <rphillips>thanks
16:53:16  <SinisterRectus>pretty-print
16:53:25  <creationix>btw, several of the new luvit versions havn't been published to lit
16:53:31  <creationix>*luvit/deps versions
16:53:41  <SinisterRectus>is there a reason why lit has its own copies instead of directly depending on the luvit versions
16:53:49  <creationix>path, pretty-print, tls, and url
16:53:49  <rphillips>creationix: lit publish deps/* . right?
16:54:02  <creationix>SinisterRectus, just bootstrap problems in the build
16:54:06  <creationix>rphillips, yep
16:54:07  <SinisterRectus>oh
16:54:24  <creationix>SinisterRectus, lit is the package builder, so it can't build itself if it's missing dependencies
16:54:32  <SinisterRectus>good point
16:54:48  <creationix>though as this point, we have enough older version of lit that we could probably build with an older version (that's what gcc does)
16:55:45  <creationix>rphillips, and when you're done, luvit itself probably needs a version bump and published to lit
16:55:58  <rphillips>i published to lit yesterday for luvit
16:56:10  <rphillips>exactly that command line... didn't seem to 100% work
16:56:23  <creationix>I see, it's the new commits since then that are makingit complain
16:56:42  <creationix>you can test with `lit add`
16:56:51  <creationix>it will do the same thing as `lit publis` but not actually publish
16:57:02  <creationix>and then you can nuke your local ~/.litdb.git to undo it
17:00:59  <creationix>they weren't diverged, mainly lit didn't yet have the new pretty-printer changes
17:01:27  <creationix>one way I like to test is `rm -rf deps && lit instakk && git diff`
17:01:39  <creationix>it checks to see if what's published to lit matches what's locally in deps
17:01:46  <creationix>*install
17:04:20  * Sonijoined
17:05:41  <creationix>ok, everything in luvit and lit appears to be synced up and up to date
17:06:03  <creationix>I updated the version used on luvit.io for the websites and restarted the services
17:06:18  <creationix>hopefully some of these bug fixes will improve the crap stability we've had lately
17:07:23  <SinisterRectus>nice
17:07:56  <creationix>thanks everyone for helping when I'm busy
17:20:54  * travis-cijoined
17:20:55  <travis-ci>luvit/luvit#2988 (master - 3bda341 : Tim Caswell): The build passed.
17:20:55  <travis-ci>Change view : https://github.com/luvit/luvit/compare/bf781aaf2f07...3bda341d5897
17:20:55  <travis-ci>Build details : https://travis-ci.org/luvit/luvit/builds/243745980
17:20:55  * travis-cipart
18:36:56  * rendarquit (Ping timeout: 258 seconds)
19:06:48  * rendarjoined
19:27:03  <Soni>creationix: I've always wondered, why does every runtime ever created (including LuaJIT) insist on keeping everything loaded in RAM at all times?
19:27:32  <Soni>even "dead code" caused by read-only properties initialized at runtime
19:28:26  <Soni>e.g. local flag = os.getenv("something") function thisGetsCalledInATightLoop() if flag then <some code that never gets called> else <some code that always gets called> end end
19:28:38  <Soni>LuaJIT keeps the bytecode always loaded and never gets rid of it
19:29:08  <Soni>even tho there's a whole section of code that's never gonna be used
19:32:09  <Soni>I guess this is what loadstring is for...
19:33:18  <Soni>thisGetsCalledInATightLoop = require "thisGetsCalledInATightLoop" .. (flag and "_flagged" or "")
19:33:20  <Soni>hmm
19:33:31  <Soni>maybe the solution is to add more lazy evaluation everywhere
19:36:33  <Soni>...
19:36:39  <Soni>GCC *could* be lazy evaluated
19:36:46  <Soni>but every call would have to be an indirect call
19:36:50  <Soni>but that's fine IMO
19:37:05  <Soni>but then again most native code runs straight from disk
19:37:10  <Soni>so it doesn't matter for GCC
20:26:14  * rendarquit (Quit: std::lower_bound + std::less_equal *works* with a vector without duplicates!)
20:32:43  <SinisterRectus>the halting problem?
20:32:55  <SinisterRectus>there's no way to know that the code is never needed again
20:47:31  <Soni>SinisterRectus: it's not a halting problem issue
20:48:13  <SinisterRectus>what code do you want it to release
20:48:25  <Soni>there are many ways to know 1. the code is never referenced 2. it's a constant 3. etc 4. even the JIT eliminates it
20:48:45  <Soni>if the JIT eliminates it from the JITted code why not eliminate it from the "source" bytecode?
20:50:30  <SinisterRectus>that i don't know, but i wouldn't expect it to either