00:12:44  * daurnimatorjoined
01:36:12  * rgrinbergjoined
06:06:52  * SkyRocknRolljoined
06:18:48  * rgrinbergquit (Ping timeout: 265 seconds)
06:37:29  * rendarjoined
07:16:30  * SinisterRectusquit (Ping timeout: 244 seconds)
07:16:43  * SinisterRectusjoined
12:17:57  * rgrinbergjoined
12:20:33  * rgrinbergquit (Quit: WeeChat 1.5)
12:20:53  * rgrinbergjoined
12:31:29  * rgrinbergquit (Ping timeout: 260 seconds)
12:48:02  * rgrinbergjoined
13:48:44  * zatherzjoined
13:49:04  <zatherz>I think I found a bug in luvit, https://zatherz.eu/trashcan/lua/luvit/
13:49:10  <zatherz>download both x.lua and test.lua, then run x.lua
13:49:17  <zatherz>on any sane Lua version, it prints 3
13:49:22  <zatherz>on Luvit, it prints nil
13:49:27  <zatherz>related to requires and global variables
14:03:15  <rphillips>zatherz: luvit has its own require system
14:05:41  <daurnimator>loadfile isn't related to require
14:05:50  <daurnimator>at least. it shouldn't be.
14:06:11  * daurnimatorglares at creationix_
14:07:05  <SinisterRectus>i think we figured out that you need to explicitly use the _G table
14:07:14  * SkyRocknRollquit (Remote host closed the connection)
14:41:58  * SkyRocknRolljoined
15:05:01  * SkyRocknRollquit (Remote host closed the connection)
15:06:06  * SkyRocknRolljoined
15:38:48  <creationix>daurnimator I don't touch loadfile, but luvit's custom require does wrap modules in a custom scope
15:39:07  <creationix>still I recommend using the luvit-loader lib instead of luvit's require, but migration is slow
15:39:41  <daurnimator>creationix: ah; so x.lua's global scope was not the global scope?
15:40:06  <creationix>right, but I do expose a reference to the real global scope via _G
15:40:18  <creationix>the idea was to make global leakage explicit and not accidental
15:40:27  <creationix>luvit 1.0 was very opinionated
15:44:24  <daurnimator>i'm still a little confused...
15:44:36  <daurnimator>doesn't loadfile give the loaded code the same env as the caller?
15:44:41  <daurnimator>I might be misremembering that one
15:46:19  <creationix>from the manual "The environment of the returned function is the global environment."
15:46:34  <creationix>and since the parent module is in a luvit sandbox, `x` doesn't exist in global
15:47:59  <creationix>SinisterRectus zatherz, I recommend switching to luvit-loader instead of using the legacy luvit binary. Any ideas of how to communicate that better are welcome
15:48:59  <creationix>luvit's built-in require is very opionated and causes more trouble than good if you have any prior experience with lua. My target audience when designing it was JS developers coming over from node.js
15:50:02  <daurnimator>creationix: ah true. http://www.lua.org/source/5.3/lapi.c.html#lua_load it does grab the global env :)
15:50:29  <daurnimator>creationix: yeah I do know that. I'm not sure if any JS devs understand node's require either though :P
15:50:52  <creationix>I can't change luvit, it will break code for most the people using luvit in large systems
15:51:22  <creationix>breaking the system for my most loyal users to make things easier for newcomers isn't a good tradeoff I think
15:51:52  <daurnimator>creationix: btw, watch out for impending openssl 1.1.0 release
15:52:04  <daurnimator>it causes breakage with a *huge* number of packages.
15:52:19  <creationix>fun
15:52:43  <creationix>maybe I should just start over once midipix gets stable and drop libuv
15:52:47  * daurnimatorported cqueues tonight minus one remaining issue.
15:52:55  <daurnimator>luaossl will take more effort :(
15:53:04  <creationix>:/
15:53:17  <daurnimator>creationix: I wish. midipix is now running 4 months late on release though :P
15:53:34  <creationix>yeah, I thought they were going slowly lately
15:53:54  <creationix>I wonder if the linux subsystem for windows took some of their steam away
15:55:33  <daurnimator>well the main author did go overseas for a couple of months there. back a couple of weeks ago IIRC
15:55:41  <creationix>that will do it
15:56:32  <daurnimator>/bed for me
15:56:36  <creationix>good night
15:57:39  * rgrinbergquit (Ping timeout: 244 seconds)
16:22:59  <SinisterRectus>eh. i like explictly defining _G.foo anyway. zatherz was the one who ran into the issue. i didn't know luvit-loader was a thing, i'll check it out.
16:28:47  <APNG>creationix, "lovet"
16:29:19  <APNG>if you want a name for a better luvit
16:29:42  <creationix>interesting
16:29:52  <APNG>see also javescrept
16:30:07  <creationix>ideally we'll keep the luvit name, but somehow move the legacy package out of the main-light
16:30:25  <APNG>do it like python
16:30:58  <creationix>I'm not sure python is a good example of how to do breaking changes and keep the community from fragmenting
16:31:06  * rgrinbergjoined
16:31:16  <APNG>uh
16:31:21  <APNG>use a flag
16:31:27  <APNG>-r2 or something
16:31:56  <APNG>modules can trivially work with both the new and the old require
16:32:00  <APNG>so it won't be an issue
16:32:11  <creationix>the thing is, there's a fairly small number of people using luvit, if I could give them a pain-free way to keep their stuff working that would be ideal
16:32:33  <creationix>but I don't want new people to learn with the current luvit/luvit package as the official entry point
16:32:44  <APNG>-r2 flag *is* pain free
16:32:55  <APNG>as well as per-package "require mode" config
16:33:15  <APNG>wrap require so that if the require mode is "old" or missing, then use old require mode
16:33:18  <creationix>then you just have a huge complex system with both tangled together
16:33:19  <APNG>otherwise just use native require
16:33:24  <APNG>yes >.>
16:33:26  <APNG>but it works
16:33:29  <APNG>and it works well
16:33:37  <creationix>I don't think we have to do this, luvit isn't that popular
16:33:54  <creationix>but at the same time, the community is so small, if I cause any friction, we'll lose the few we have
16:34:05  <APNG>just do the maintenance pain
16:34:07  <APNG>you can clean it up later
16:35:05  <APNG>(it's actually trivial tbh, just do local oldrequire = require; require = function(...) if package.whatever.requiremode == "old" or not package.whatever.requiremode then return require(...) else return nativerequire(...) end end
16:35:24  <APNG>example code, adapt as needed
16:39:55  <creationix>I guess I could just make luvit 3.0 and strip out most the node stuff
16:40:07  <creationix>people on legacy systems won't automatically update to it
16:40:18  <creationix>and I can even copy the old one to a new name like luvit-node or something
16:40:30  <creationix>so it can be continued to be maintained if there is still interest
16:41:13  <APNG>yes
16:41:15  <APNG>so like python
16:43:57  <creationix>APNG btw, something like this would make a good luvit replacement as the official CLI tool https://github.com/squeek502/luver
16:44:50  <APNG>"No circular requires allowed" does that mean you can't assign to package.loaded and manually do a circular require?
16:45:03  <creationix>I'm not sure what he means by that
16:45:20  <APNG>(btw, yes, I do manually assign to package.loaded like that)
16:45:28  <creationix>luvit-loader is just a custom loader for lua's native require
16:45:39  <APNG>(not sure if I ever put the code on github tho)
16:46:20  <creationix>The other direction is focus on luv and publishing luvit-loader to luarocks
16:46:34  <creationix>but then you lose luvi and lit, those are still quite useful
16:46:54  <APNG>creationix, 5.3 support?
16:46:59  <creationix>yep
16:47:06  <creationix>where possible at least
16:47:07  <APNG>I like 5.3 support
16:47:15  <creationix>nor all libraries can work on all lua versions
16:48:12  <creationix> I was at one point porting select libraries to have full test coverage on all versions of lua.
16:48:14  <creationix>For example https://github.com/super-agent/msgpack
16:48:28  <creationix>https://github.com/super-agent/msgpack/blob/master/.travis.yml#L9-L15
16:49:00  <creationix>this library did much better https://github.com/super-agent/schema/blob/master/.travis.yml#L9-L15
16:49:23  <APNG>what's msgpack?
16:50:03  <creationix>http://msgpack.org/index.html
16:50:06  <creationix>awesome
16:50:16  <APNG>also
16:50:24  <APNG>can't you use uh
16:50:27  <APNG>string.pack in lua 5.3?
16:50:37  <creationix>possibly
16:50:54  <creationix>but it would be a completely different implementation
16:51:04  <creationix>I seem to remember string.pack had some issues
16:51:05  <APNG>you mean a much better implementation?
16:51:36  <APNG>"read16 read32 write32" I think all that can be done trivially with string.pack
16:52:13  <creationix>what endianess?
16:52:17  <creationix>native won't work
16:52:19  <APNG>use < and >
16:53:18  <APNG>floats are a bit tricky, in addition to converting them to string you might also have to tweak the resulting string a bit, depending on the platform/float representation
16:53:41  <creationix>I ended up just using luajit's ffi
16:53:52  <creationix>and manually detecting endieness and reordering the bytes if need-be
16:54:10  <creationix>is string.pack new?
16:54:14  <APNG>yeah lua 5.3 does the reordering for you
16:54:18  <APNG>yeah string.pack is 5.3
16:54:41  <APNG>but note that string.pack makes no guarantees about floats I think
16:55:41  <creationix>so much (native size), that's really annoying when doing network protocols
16:56:30  <APNG>use i[n] and I[n]
16:57:00  <creationix>I run lua on everything from Tensilica xtensa CPUS, to ARM SOCs to x84_64 servers
16:57:05  <APNG>use i[n] and I[n]
16:57:27  <APNG>floats and doubles are tricky and there's no portable way to do it
16:57:28  <creationix>I'm not sure what they mean by native size on floats and doubles
16:57:35  <creationix>I thought the definition was float is 32-bit and double it 64
16:57:41  <creationix>what machines differ from that?
16:57:46  <APNG>pretty sure some machines have 64-bit floats and 128-bit doubles?
16:58:34  <creationix>I know long double can be 80 or 128 bit depending on machine
16:58:43  <creationix>but a normal double has always been 64 in my experience
16:59:48  <creationix>I wonder if anyone has written a backport for string.pack/unpack that uses luajit ffi
17:00:01  <creationix>doesn't look like it's too hard, especially for the subset of the format I'd be using
17:00:27  <APNG>I think so, yes
17:01:00  <creationix>Because using the native bitops in lua 5.3 is a no go for portable code
17:01:03  <creationix>they are syntax errors in others
17:01:10  <creationix>also the semantics aren't what I want usually
17:01:24  <APNG>well uh
17:01:31  <APNG>you can use load()
17:01:36  <creationix>mike paul's bitop extension for lua doesn't compile or work well on the PUV luas either
17:01:59  <creationix>*PUC lua
17:02:08  <konobi>nanomsg++
17:02:14  <APNG>load"local a,b=... return a<<b"
17:02:32  <APNG>load"local a,b=... return a<<b" or lshift
17:02:51  <APNG>(it's shitty but it works)
17:03:06  <creationix>APNG I think implementing string.pack/unpack is much saner
17:03:15  <APNG>yeah
17:03:30  <creationix>konobi nanomsg.org? looks fun
17:04:08  <konobi>yup
17:04:38  <konobi>creationix: got an object lib for lua that you really recommend?
17:04:53  <creationix>konobi luvit's core lib is pretty simple and nice
17:05:03  <creationix>I don't really use such libs myself. I like C style coding
17:05:06  <creationix>functions and args
17:05:33  <creationix>konobi https://github.com/luvit/luvit/blob/master/deps/core.lua
17:05:41  <creationix>I assume this is what you mean by "object lib"
17:07:43  <konobi>close... but good to see alternate implementations
17:08:22  <creationix>I'm sure there are many, but like I said, I was never interested. We just made that one to make porting node APIs easier
17:10:00  <konobi>yup... just seeing if there's a more lua-ey way of expressing the basics of oo, but proto-typical-esque seems par for the course
17:11:28  <APNG>I use closures
17:11:30  <APNG>personally
17:12:24  <konobi>the implementation doesn't matter too much, just look and feel
17:13:14  <creationix>I think the real value in OOP is encapsulation. Having clearly defined interface points and not leaking implementation details
17:13:30  <creationix>and things like inheritance are a nightmare and should have never have been associated with OOP
17:13:54  <APNG>eh `instanceof` is nice
17:14:03  <APNG>kinda
17:14:09  <creationix>it's a poor mans type system
17:14:18  <creationix>really what you want is abstract types
17:14:22  <creationix>but lua doesn't have that
17:14:40  <creationix>though I suppose it could be done easy enough with a new metamethod
17:15:40  <konobi>looking at doing a pure MOP currently... but my buddy has me distracted with some academic talks to watch ^_^
17:15:49  <creationix>that would actually be a really nice object system. I might prototype that out some time when I'm not already working till 2am trying to finish prepping my next talk
17:16:45  <konobi>creationix: heh... Coat/Joose/Moose are pretty awesome
17:17:48  <APNG>hmm
18:29:34  * rendarquit (Ping timeout: 255 seconds)
18:33:19  * rgrinbergquit (Ping timeout: 244 seconds)
18:59:00  * rendarjoined
19:20:48  * rgrinbergjoined
19:35:00  * rgrinbergquit (Read error: Connection reset by peer)
19:36:14  * rgrinbergjoined
19:38:11  * rgrinbergquit (Read error: Connection reset by peer)
19:53:38  * SkyRocknRollquit (Remote host closed the connection)
19:57:17  * rgrinbergjoined
21:17:26  * rgrinbergquit (Read error: Connection reset by peer)
21:19:44  <SinisterRectus>if uv.run is called twice, does that actually run the a loop twice, or is it just going to re-start the loop
21:21:40  * rgrinbergjoined
21:30:41  * rgrinbergquit (Quit: WeeChat 1.5)
21:31:06  * rgrinbergjoined
21:35:57  * zatherzquit (Ping timeout: 276 seconds)
21:56:25  * rgrinbergquit (Ping timeout: 252 seconds)
22:04:04  * rendarquit (Quit: std::lower_bound + std::less_equal *works* with a vector without duplicates!)
22:44:53  * rgrinbergjoined