00:18:31  * Something12joined
02:00:45  * DarkGodquit (Quit: Leaving)
04:30:12  * SkyRocknRoll_quit (Ping timeout: 264 seconds)
05:07:31  * SkyRocknRolljoined
06:58:23  * squeekquit (Ping timeout: 264 seconds)
07:02:01  * squeekjoined
07:50:34  * SkyRocknRollquit (Ping timeout: 245 seconds)
08:07:35  * SkyRocknRolljoined
09:06:18  * DarkGodjoined
11:04:46  * sousouxquit (Ping timeout: 240 seconds)
12:56:22  <creationix>daurnimator, trying to port luvit's require to a lua loader
12:56:29  <creationix>I found a somewhat hacky workaround
12:57:04  <creationix>if I insert my loader at the very front, it gets called before lua looks in the package.loaded cache. This allows me to use my cache (with fully resolved path names).
12:57:49  <creationix>Lua will still store a copy of the module in package.loaded at the short name (possibly overwriting a conflicting name). But as long as my loader always comes first, I don't think that's a problem.
12:59:38  <daurnimator>creationix: yeah... lua isn't very friendly to relative loading
13:00:08  <daurnimator>for e.g. it means you can now no longer create useful helpers around your require
13:00:24  <daurnimator>because it would be relative to the helper
13:00:47  <creationix>I think my hacked up loader will work. It's working for lit at least.
13:01:02  <creationix>still need to run it through the more involved luvit unit tests
13:01:06  <daurnimator>yep
13:01:11  <daurnimator>no less hacky than what you had before
13:01:22  <creationix>a different kind of hacky
13:01:22  <daurnimator>one day you'll realise you don't need relative require ;)
13:01:46  <creationix>or switch to a language with a require system that supports it :P
13:02:32  <daurnimator>in other news, I finally fixed the broken lua-http test
13:02:49  <daurnimator>(it was failing on travis; but not locally; which made it a pain in the ass)
13:02:54  <creationix>yep, been there
13:03:26  <creationix>btw, I'm still considering moving luvit over to luaossl. I just need to convince myself that coupling luv with an openssl context is a good idea
13:03:31  <daurnimator>I ended up making a different branch and just kept amending the commit on it until it passed
13:03:37  <creationix>it should help performance at least
13:03:55  <creationix>good idea, that keeps your history clean
13:04:20  <daurnimator>creationix: FWIW, you could write a small C module that took an openssl SSL_CTX* and gave output as a lua string directly
13:05:01  <creationix>My plan was to add a couple methods to the uv_stream_t "class" so that any libuv stream can add tls
13:05:26  <daurnimator>creationix: I think that's a good idea. but I assume you have other libuv developers there to fight with? :P
13:05:34  <creationix>but yes, another idea is just write a standanlone C module that adds the missing functionality to luaossl so we can keep our current behavior
13:05:49  <creationix>it doesn't need to go into libuv, just my lua bindings
13:05:59  <daurnimator>luaossl might even take such a patch
13:12:38  <creationix>The one thing I like about our current decoupled approach is any stream can have tls added, even if it's not a real libuv stream. It's just a question of if anyone actually does that or has reason to do that.
13:13:28  <creationix>daurnimator, how do you handle tls in your libuv version of cqueues?
13:13:37  <creationix>are you using luvit with it's openssl bindings?
13:14:05  <creationix>I imagine it would integrate a lot cleaner if luv would accept a context from luaossl directly.
13:15:43  <daurnimator>creationix: libuv version of cqueues??
13:15:58  <creationix>I mean when you integrate with libuv
13:16:16  <creationix>like the examples you put in the luvit repo
13:16:47  <daurnimator>creationix: it hooks up a cqueue with uv_loop_t or vice-versa. nothing at the socket/stream level.
13:17:22  <creationix>so can I use your http library to make a https call using libuv for the system calls?
13:18:03  <daurnimator>no. you'd use my http library; which uses the cqueues socket library; which uses the cqueues scheduler => which you hook up to a uv_loop_t (which is a singleton in luv)
13:18:23  <creationix>ok, that makes more sense
13:18:40  <creationix>but if I wanted to use libuv instead of the cqueues socket library for lua-http, how hard would that be?
13:19:35  <daurnimator>I use a "target state" mechanism which cqueues caters well for. I doubt that's easy in libuv
13:20:40  <daurnimator>e.g. in the cqueues socket module, you can construct a socket object which returns instantly; then call :write (before it's connected at the syscall level), and it makes sure it does everything in order
13:22:07  <creationix>I've been very careful with luvit to keep protocol logic decoupled from the socket code. The idea is you can reuse my http-codec with any stream
13:22:23  <creationix>same with tls-codec (but with the aforementioned performance issues)
13:22:59  <creationix>I don't see why targetting your interface would be hard. Just need to keep some state in a layer above libuv.
13:23:04  <creationix>I already do this for my coro-* interfaces
13:23:20  <daurnimator>creationix: IMO that style is a bit futile; it really limits what you can do => I realised having a flexible scheduler that can be embedded anywhere was the solution to being able write easy to read code
13:23:53  <daurnimator>creationix: yeah. but at that point you're basically emulating cqueues's socket module on top of libuv.....
13:24:14  <creationix>right, which makes it slower and more complicated :)
13:24:26  <creationix>but cqueues doesn't support IOCP in windows right?
13:24:42  <daurnimator>creationix: no. I'm working on windows solutions... and I'm aiming lower level than IOCP now :)
13:25:05  <daurnimator>i.e. undocumented NT interfaces
13:25:11  <daurnimator>which are suprisingly stable
13:25:29  <daurnimator>or not so suprising; when you realise all the people that understand this level left microsoft 20 years ago
13:27:44  <creationix>good luck
13:42:03  <daurnimator>creationix: libuv actually uses similar stuff in one area
13:46:01  <daurnimator>creationix: anyway, in my http2 code I actually use cqueues schedulers
13:46:15  <daurnimator>each http2 connection has it's own scheduler
13:46:32  <daurnimator>(that would be like each http2 connection having it's own uv_loop_t)
14:11:49  <daurnimator>hrm
14:11:50  * SkyRocknRollquit (Ping timeout: 250 seconds)
14:12:00  <daurnimator>which I actually am stuck thinking about at the moment
14:12:15  <daurnimator>e.g. you call myhttp2stream:write_chunk(big_string)
14:12:30  <daurnimator>now, the first part of big_string gets sent
14:12:33  <daurnimator>but you run out of peer credits
14:12:59  <daurnimator>so it reads ahead until it gets more
14:13:14  <daurnimator>but what if during the read-ahead, there's an error?
14:13:50  <daurnimator>considering my convention is to return `nil, err, errno`
14:14:22  <daurnimator>it seems weird to return the errors for such an unrelated thing (from the read-ahead) from :write_chunk
14:46:32  <creationix>yep, this kind of stuff gets tricky
14:47:26  <creationix>also, http2 has peer credits?
14:48:32  <daurnimator>creationix: yep
14:48:49  <daurnimator>creationix: you can only send as much data as credits you have
14:49:14  <daurnimator>then you have to wait for more credits before you send the rest of the data
14:50:02  <creationix>but http2 isn't a p2p protocol, how does that work?
14:50:06  <creationix>or do I not understand it?
14:50:38  <rphillips>good morning
14:50:51  <creationix>rphillips, morning
14:53:11  <creationix>I've seen the "peer-to-peer" extension to http2 that acts sort of like websocket, but I don't see anything about credits in it
14:53:27  <daurnimator>creationix: the peer is the server (or client)
14:53:59  <daurnimator>creationix: https://http2.github.io/http2-spec/#fc-principles
14:54:53  <creationix>I see, interesting
15:10:11  * SkyRocknRolljoined
15:11:23  * SkyRocknRoll_joined
19:17:55  <creationix>rje, you mentioned luvit garbage collection. Did you need help with something?
19:18:16  <rje>creationix, yes, uick vidyo?
19:18:44  <creationix>sure, your room?
19:47:39  * SkyRocknRoll_quit (Ping timeout: 245 seconds)
19:47:56  * SkyRocknRollquit (Remote host closed the connection)
19:49:10  <rphillips>creationix: https://github.com/rphillips/virgo-logging/blob/master/init.lua#L101
20:14:04  <creationix>rphillips, the luajit code for os.date looks pretty straightforward https://github.com/LuaJIT/LuaJIT/blob/1393b2f681df3a71cb381b958e8e3221d2dd427d/src/lib_os.c#L213-L216
20:14:18  <creationix>the only GC related action is to push the final string into lua
20:15:41  <rphillips>it might be the FileLogger/fs.WriteStream
20:15:43  <rphillips>https://github.com/rphillips/virgo-logging/blob/master/init.lua#L121
20:16:29  <creationix>maybe it's not date related. it's just that date is the first thing in a log entry?
20:16:36  <rphillips>yeah
20:16:46  <creationix>maybe something gets corrupted at the end of the previous line
20:17:12  <creationix>which we were seeing with the config file issue we thought was locale related
20:17:43  <creationix>maybe fs.WriteStream is buggy on some systems?
20:18:08  <creationix>that would be used by both config file writer and this logger right?
20:18:26  <rphillips>correct
20:18:50  <rphillips>the config file used fs.writeFile
20:19:18  <creationix>hmm, maybe not then, that's different code, unless writeFile uses writeStream internally
20:21:35  <creationix>I need to run a quick errand, will be back in a bit
20:43:49  <creationix>...maybe not (bike has flat tires and pump is missing)
22:04:38  * kostcoquit (Ping timeout: 240 seconds)
22:04:49  * kostcojoined
22:43:04  <creationix>hmm, dropping luvit/require means we can't use module:load anymore
22:43:46  <creationix>(that was a way to load relative resources from either luvi bundles or filesystem)
22:46:00  <creationix>I'll add a utils.load that does the same thing
22:59:05  * travis-cijoined
22:59:06  <travis-ci>luvit/luvit#2669 (luvly - 2d134b0 : Tim Caswell): The build has errored.
22:59:06  <travis-ci>Change view : https://github.com/luvit/luvit/compare/1714c7217ac1...2d134b05c1db
22:59:06  <travis-ci>Build details : https://travis-ci.org/luvit/luvit/builds/100705238
22:59:06  * travis-cipart
23:02:02  * travis-cijoined
23:02:03  <travis-ci>luvit/luvit#2671 (luvly - 77f3d6d : Tim Caswell): The build has errored.
23:02:03  <travis-ci>Change view : https://github.com/luvit/luvit/compare/2d134b05c1db...77f3d6db0000
23:02:03  <travis-ci>Build details : https://travis-ci.org/luvit/luvit/builds/100705896
23:02:03  * travis-cipart
23:22:03  <creationix>made good progress on moving luvit to luvit-loader
23:22:21  <rphillips>nice!
23:22:24  <creationix>most the unit tests are passing now, but for some reason, the test runner doesn't output anything till it fails
23:22:37  <creationix>I'm going to miss the module: api
23:22:54  <creationix>but it conflicts greatly with lua (where `module` is a global deprecated function)
23:23:14  <creationix>I suppose we could write a library in deps that has the old `module` interface
23:23:22  * travis-cijoined
23:23:23  <travis-ci>luvit/luvit#2673 (luvly - 29a1ca5 : Tim Caswell): The build has errored.
23:23:23  <travis-ci>Change view : https://github.com/luvit/luvit/compare/77f3d6db0000...29a1ca5467d3
23:23:23  <travis-ci>Build details : https://travis-ci.org/luvit/luvit/builds/100710054
23:23:23  * travis-cipart
23:23:24  <creationix>probably better than what I'm doing with tacking stuff on utils
23:23:47  <creationix>hmm, except we don't want to conflict with the lua global, so maybe utils is the right place?
23:24:26  <creationix>anyway, dinner time https://github.com/luvit/luvit/pull/861/files?w=1
23:26:19  <creationix>I think a new "resource" module can replace the old `module` global
23:26:36  <creationix>resource.load, resource.dir, resource.filename, resource.resolve, etc..
23:26:42  <creationix>all relative utilities
23:26:57  <creationix>that work in bundle or fs mode automatically
23:57:37  <daurnimator>creationix: if its a module of relative things. call it 'relative'? or 'relativity'
23:57:56  <daurnimator>there's gotta be some moon-related pun in there too around the theory of relativity