00:23:44  * kevwilquit (Ping timeout: 255 seconds)
00:30:35  * q66quit (Remote host closed the connection)
01:05:20  * DarkGodquit (Ping timeout: 252 seconds)
01:27:26  * tim_smartchanged nick to tim_smart|away
01:31:20  * tim_smart|awaychanged nick to tim_smart
02:18:15  * jsermenoquit (Read error: Connection timed out)
02:19:29  * jsermenojoined
03:48:00  * kazuponjoined
03:55:31  * jsermenoquit (Quit: jsermeno)
04:33:52  * jsermenojoined
04:50:15  * tim_smartchanged nick to tim_smart|away
04:51:49  * indexzero_joined
04:54:52  * indexzeroquit (Ping timeout: 252 seconds)
04:54:53  * indexzero_changed nick to indexzero
05:09:22  * kevwiljoined
05:14:08  * kevwilquit (Client Quit)
05:40:33  * indexzeroquit (Quit: indexzero)
06:05:50  * indexzerojoined
06:14:12  * philips_quit (Excess Flood)
06:28:30  * philips_joined
07:27:06  * jsermenoquit (Quit: jsermeno)
07:36:40  * jsermenojoined
07:47:57  * jsermenoquit (Quit: jsermeno)
08:03:35  * kazuponquit (Read error: Connection reset by peer)
08:04:06  * kazuponjoined
08:06:02  * jsermenojoined
08:07:19  * kazuponquit (Read error: Connection reset by peer)
08:07:39  * kazuponjoined
08:20:35  * indexzeroquit (Quit: indexzero)
08:23:08  * jsermenoquit (Quit: jsermeno)
09:38:41  * kazuponquit (Remote host closed the connection)
09:41:13  * kazuponjoined
09:42:07  * kazuponquit (Remote host closed the connection)
13:14:58  * q66joined
13:22:20  * supplantrchanged nick to help
13:22:28  * helpchanged nick to supplantr
14:21:32  <creationix>I hope it's ok I accepted a couple pull requests
14:21:38  <creationix>they were both tiny and looked good
14:23:13  * travis-cijoined
14:23:13  <travis-ci>[travis-ci] luvit/luvit#585 (master - 7a361cc : Tim Caswell): The build passed.
14:23:13  <travis-ci>[travis-ci] Change view : https://github.com/luvit/luvit/compare/52af9e9c176a...7a361cc48fbd
14:23:13  <travis-ci>[travis-ci] Build details : http://travis-ci.org/luvit/luvit/builds/4930152
14:23:13  * travis-cipart
14:23:58  * travis-cijoined
14:23:58  <travis-ci>[travis-ci] luvit/luvit#586 (master - 239fd26 : Tim Caswell): The build passed.
14:23:58  <travis-ci>[travis-ci] Change view : https://github.com/luvit/luvit/compare/7a361cc48fbd...239fd2612595
14:23:58  <travis-ci>[travis-ci] Build details : http://travis-ci.org/luvit/luvit/builds/4930212
14:23:58  * travis-cipart
14:45:23  * DarkGod2_quit (Ping timeout: 256 seconds)
14:45:45  * DarkGod2joined
15:20:53  <rphillips>creationix: lgtm
16:23:06  * supplantrquit (Quit: WeeChat 0.4.0)
17:03:14  * indexzerojoined
17:20:06  * indexzeroquit (Quit: indexzero)
17:25:43  * kevwiljoined
17:39:25  * indexzerojoined
17:44:34  * indexzeroquit (Quit: indexzero)
18:48:20  * jsermenojoined
19:10:22  * indexzerojoined
19:55:49  * kevwilquit (Ping timeout: 244 seconds)
19:56:55  * kevwiljoined
20:05:23  * indexzeroquit (Quit: indexzero)
20:17:21  * jsermenoquit (Quit: jsermeno)
20:22:46  * Felix___joined
20:23:20  <Felix___>Hey Tim
20:24:33  <Felix___>So I'm attempting to reduce the ideological purity by changing 'require' to 'luv_require' in my fork, but module.lua is doing some inscrutable-to-me things that apparently maintain the 'require' shadow.
20:27:01  * indexzerojoined
20:28:41  * tim_smart|awaychanged nick to tim_smart
20:29:21  <Felix___>I'm interested in knowing if (a) you or anyone else knows what that magic is, and/or (b) anyone else has a better way of interfacing with plain-old-lua modules.
20:34:43  * jsermenojoined
20:39:37  <creationix>Felix___, so two things
20:39:50  <creationix>first, I'm ok with renaming luvit's require to something else
20:40:16  <creationix>"load" is probably a better name than luv_require
20:40:40  <creationix>also the luvit require is actually a local variable in every module's environment that has the relative paths baked in
20:40:55  <creationix>that way it know what "./foo" is relative to
20:41:24  <creationix>would be good to know how much a hassle it would be for rphillips and philips_ to search-replace "require" to "load" in their luvit code
20:41:29  * Felix____joined
20:41:33  <Felix____>(damn web gateway)
20:42:08  * Felix___quit (Ping timeout: 245 seconds)
20:42:25  <creationix>Felix___, also in it's current implementation, I think luvit's require neuters the normal lua require
20:42:32  <creationix>we'll need to make the implementation standalone
20:42:40  <Felix____>I agree
20:43:00  <creationix>but then require would be lua's real require and "load" would be luvit's enhanced require
20:43:09  <Felix____>yep
20:43:29  <Felix____>that would require some module rework but I think it would be worth it to improve compatibility.
20:43:31  <creationix>the other option is find a way to convert the luvit style require to a lua loader
20:43:41  <creationix>if they can live side-by-side
20:44:00  <creationix>lua's require is extensible after all
20:45:00  <Felix____>yeah -- maybe if .luvit modules were loaded the luvit way, that would be cleaner.
20:47:39  <creationix>there are 4 special loaders I think
20:47:46  <creationix>the built-in bytecode in the binary
20:47:51  <creationix>(for bundled luvit builds)
20:48:07  <creationix>the build-in lua libraries in $PREFIX/lib/luvit
20:48:38  <creationix>relative loaders using "./foo" for .lua and .luvit files
20:48:59  <creationix>relative loaders mapping "foo" to "..*/modules/foo"
20:51:09  <Felix____>where do you think lua native require is getting shadowed? module.lua:130 has 'function module.require' but changing that name doesn't seem to undo the shadow.
20:51:27  <creationix>look for where I set __dirname
20:51:31  <creationix>it should be in the same place
20:51:44  <creationix>__dirname, __filename, and require
20:51:56  <Felix____>hmm, but that's inside a function definition.
20:52:05  <Felix____>in local function myloadfile(...).
20:52:26  <creationix>yep
20:52:30  <creationix>setfenv
20:52:40  <creationix>every module has a new local function called "require"
20:53:05  <creationix>which is just a closure to the real require, but with the filepath partially applied
20:53:13  <Felix____>ahh.
20:53:30  <Felix____>and somehow myloadfile() is called at least once somewhere, to cause that setfenv to happen?
20:53:49  <creationix>it's called for every file required via the luvit system
20:55:13  <Felix____>but it's part of the luvit system require, so I'm not seeing how it gets called the first time to do that fenv initialization
20:56:54  * jsermenoquit (Quit: jsermeno)
20:57:16  <Felix____>seems like that setfenv initialization ought to be outside of that function
20:57:23  <Felix____>unless I'm confused, which is entirely likely
20:58:32  <creationix>https://github.com/luvit/luvit/blob/master/lib/luvit/luvit.lua#L321
20:58:38  <creationix>the bootstrap file
20:59:00  <Felix____>ahh
20:59:54  <creationix>also I think I'm fine with not neutering the globals too https://github.com/luvit/luvit/blob/master/lib/luvit/luvit.lua#L75-L85
21:00:02  <Felix____>I suspect 'load' is already used in a lot of tables, do you have any other ideas for a better name for luvit's require?
21:00:06  <Felix____>(good because that was my next plan :))
21:00:17  <Felix____>I was thinking luv_require, but am agnostic
21:00:32  <creationix>thing is, it needs to be pretty
21:00:37  <creationix>this is the primary require for luvit code
21:00:40  <Felix____>haha
21:00:57  <creationix>why should the primary native require for the platform be prefixed?
21:01:24  <creationix>supporting lua require is much lower priority, it's a nice to have
21:01:28  <Felix____>to avoid shadowing the underlying language's primary keywords
21:02:04  <Felix____>maybe 'cuddle'
21:02:22  <creationix>is "load" a common variable name?
21:02:34  <creationix>I see loadfile, but not load
21:02:35  <Felix____>it's undoubtedly a very common module function name
21:02:42  <creationix>that doesn't matter
21:02:46  <creationix>this isn't a table key
21:02:49  <creationix>this is a local variable
21:03:02  <creationix>foo.load doesn't conflict with load
21:03:22  <Felix____>you sure about that?
21:03:47  <creationix>now if "load" is a common global function name or at least top-level local variable name, then we have a problem
21:04:04  <creationix>but a property name on some other table doesn't matter
21:04:59  <Felix____>functions are just values in lua, I would be shocked if x.load = function (x) end; x.load = 5; x() didn't explode
21:05:31  <Felix____>lua: a.lua:4: attempt to call field 'load' (a number value)
21:05:36  <Felix____>yeah I don't think that works in lua
21:05:51  <creationix>of course you can't call a number
21:06:07  <creationix>but I don't understand what that has to do with naming the top-level local variable
21:06:40  <Felix____>I'm probably misunderstanding setfenv then
21:06:46  <Felix____>reading up on it now
21:06:55  <creationix>setfenv sets local variables in the function body
21:06:59  <creationix>basically replaces it's globals
21:07:03  <creationix>_G
21:07:16  <creationix>actually it may very well set _G
21:07:53  <creationix>which as you know, is accessible as local variables
21:08:04  <creationix>_G.g = 5; print(g)
21:10:38  <Felix____>yeah ok, setfenv works differently than I thought it did.
21:10:59  <philips_>creationix: I think it would be easy for the rackspace agent in the init code to just alias it back
21:11:06  <Felix____>If you enjoy 'load' then that's entirely possible.
21:11:07  <philips_>creationix: but, I don't work at rackspace anymore :)
21:17:18  <creationix>philips_, it's not a global to alias back
21:17:26  <creationix>it's created fresh for every module loaded
21:17:44  <creationix>they would have to search and replace require -> load in all luvit libraries
21:32:48  * jsermenojoined
21:34:03  <Felix____>success.
21:49:15  <Felix____>creationix: put up a PR that builds for me.
21:49:27  <Felix____>tested external require and it worked like a charm.
21:57:25  <rphillips>like matt mentioned though it breaks the entire ecosystem
22:01:33  <Felix____>I think it enables more ecosystem than it breaks, personally, but I understand the view
22:02:44  <rphillips>i'm pondering it
22:03:04  <rphillips>it's a trivial change for the agent, but...
22:08:35  * kevwilquit (Quit: WeeChat 0.4.0)
22:32:47  <creationix>rphillips, right
22:32:57  <creationix>rphillips, I mean I did break compat with lua on purpose
22:33:44  <creationix>as soon as you use any existing library that blocks on I/O, your luvit server's throughput is dead
22:34:25  <rphillips>true
22:34:35  <creationix>I'm just not sure anymore that was a net win
22:34:53  <creationix>99% of the lua people who look at luvit walk away because it's not compat
22:34:59  <creationix>and most node people prefer javascript
22:35:03  <creationix>who is our audience?
22:42:57  <rphillips>yeah... i can see merging it
22:48:17  <pquerna>i do not like it. I've lived this life.
22:48:21  <pquerna>its called twisted-python
22:48:25  <pquerna>it works with normal python code
22:48:27  <pquerna>sometimes
22:48:30  <pquerna>then lots of times not
23:07:24  <Felix____>I think breaking compat with lua was a good idea in theory, because it protects people from making dumb mistakes. Nevertheless, lua people tend not to be like (some) javascript people, and are used to understanding tradeoffs. I think the node people did that because they were terrified of what would happen when joe jquery tried to use their library.
23:14:31  <creationix>Felix____, the other option is to document clearly how to port lua libraries to luvit
23:14:35  <creationix>and keep the ecosystems seperate
23:15:03  <creationix>that was my plan all along, but I never documented it and people didn't figure it out on their own
23:15:38  <creationix>I too was burned by twisted-python and event-machine-ruby
23:15:48  <creationix>so I'm on the fence :/
23:15:55  <rphillips>yep. same
23:16:04  <Felix____>I don't see the value of the barrier to entry (and as a ruby guy I feel your pain)
23:16:15  <creationix>Felix____, but I do agree with you about lua devs
23:16:22  <creationix>from what I've seen they are a different kind
23:16:37  <Felix____>if there were some wicked amazing feature that luvit provided which meant that repackaging libraries was fun and easy and clearly a better option, then yeah
23:16:58  <creationix>I think it's way better :P
23:17:03  <Felix____>but there's a lot of lua libraries and not a lot of people stepping up to do that work to make a parallel version of them just for luvit
23:17:35  <creationix>my thought was that people would do the work if luvit was worth it's weight
23:17:37  <Felix____>luvit is good, it's just not 'fork the entire lua ecosystem' good
23:17:43  <creationix>I ported all kinds of code to node
23:17:49  <creationix>code that wasn't originally in javascript at all
23:18:01  <creationix>more re-implemented from spec than porting actually
23:18:06  <creationix>from lua to luvit is much easier
23:18:15  <creationix>but perhaps because it's so close, people don't see it as porting
23:18:22  <creationix>and instead think luvit is lacking somehow or is broken
23:18:29  <Felix____>if it had better documentation ( :-) ) and were functionally complete (e.g. accept the c-buffer pull request already) then it could attract that mass
23:19:00  <Felix____>I confess that the reason I wanted to do this was because yesterday I wandered into this channel like a yokel because 'require' was breaking and there's no docs about that or people who knew the answer immediately available
23:19:03  <creationix>and that's my fault, I don't put enough time into luvit
23:19:23  <Felix____>I understand from twitter that you have children to cuddle so that's understandable
23:19:23  <creationix>other than a few guys at Rackspace, I
23:19:30  <creationix>I'm not aware of anyone maintaining it
23:20:10  <creationix>right now I'm creating a new language in my free time
23:20:16  <creationix>there is no time left for luvit :(
23:20:31  <creationix>but if someone shares my vision for luvit, I'll happily give then commit access
23:20:36  <Felix____>I'd be happy to help with luvit. I think you'd probably be better served making luvit a shining gem than another new language but that is my personal opinion :)
23:20:57  <Felix____>your code history looks like someone with amazing ideas and ADD :D
23:21:05  <creationix>lol
23:21:26  <Felix____>I know, garbage collected tinybasic...OH LOOK A SQUIRREL
23:21:36  <creationix>so true
23:21:55  <creationix>so luvit has two options
23:21:58  <Felix____>anyway luvit has promise, and all of the forks appear to have wasted away
23:22:12  <creationix>either get some more energy and finish itself
23:22:27  <creationix>or accept fate and code in lua compat
23:22:46  <creationix>I don't think lua compat is good for luvit in the long term
23:22:55  <creationix>my luv project is a better way to that route
23:22:57  <Felix____>I don't think those are incompatible destinies. Lua compat is an unalloyed, positive good.
23:22:59  <creationix>it's libuv for normal lua
23:23:10  <creationix>have you seen my luv?
23:23:22  <Felix____>I checked it out, but it looked like you abandoned it.
23:23:29  <creationix>paused more like
23:23:37  <creationix>there wasn't much interest
23:23:56  <Felix____>it looked fine, but a real good luvit would be much more interesting.
23:24:12  <creationix>well, the difference between luvit and luv is the own ecosystem
23:24:27  <Felix____>So lay out for me, just so I understand, what is particularly bad about lua compat, besides that someone could theoretically fuck themselves up?
23:24:27  <creationix>the custom require system, the bundled libraries, the opinions about built-in globals
23:24:51  <creationix>it's not theoretical, many people will
23:24:55  <Felix____>so?
23:25:05  <Felix____>people fuck themselves up with rails, ruby, node, php...
23:25:11  <Felix____>you can't solve stupid
23:25:29  <Felix____>I can write an infinite loop in one line in luvit today
23:25:43  <creationix>right, but smart developers will mess up
23:25:54  <creationix>hmm, I need zmq, let me pull in this zmq library
23:26:04  <Felix____>not with excellent documentation and a thriving ecosystem they won't
23:26:05  <creationix>wait, why won't my http server accept any requests anymore?!
23:26:22  <creationix>also the require styles are very hard to mix
23:26:34  <creationix>it may be technically possible, but it would be terrible confusing
23:27:13  <Felix____>I think it's more confusing to shadow 'require' and pretend that 90% of the modules out there don't exist.
23:27:26  <Felix____>I agree that some people can fail
23:27:27  <creationix>it's only confusing if you think luvit is lua
23:27:31  <Felix____>but you can't stop that, no matter how hard you try
23:27:41  <creationix>hence why I'm creating a new language
23:27:44  <Felix____>"Lua + libUV + JIT = pure awesome-sauce"
23:27:58  <Felix____>Luvit is lua
23:28:06  <creationix>it's built using lua
23:28:06  <Felix____>that's not bad!
23:28:11  <Felix____>it's good in fact!
23:28:15  <creationix>can you require luarocks from a wow extension?
23:28:27  <creationix>or a redis query?
23:28:35  <creationix>or any of the places where lua is embedded
23:29:04  <Felix____>those are a little different (although I disagree strongly with salvatore on his lua embed policy too, actually)
23:29:25  <Felix____>those are not development environments
23:29:38  * DarkGodjoined
23:30:28  <creationix>well, I need to go do dishes, I'll be back on tomorrow
23:30:45  <Felix____>have a good night, great chatting!
23:30:46  <creationix>I'm just not sure what would happen if we fixed the compat issues
23:30:53  <Felix____>sleep on it
23:30:57  <Felix____>the pull request will still be there :)
23:31:04  <Felix____>if I have better ideas I'll come armed tomorrow
23:33:48  * devurandomquit (Remote host closed the connection)
23:35:28  * Felix____quit (Ping timeout: 245 seconds)
23:39:16  * devurandomjoined
23:43:47  * jsermenoquit (Read error: Connection timed out)
23:44:51  * jsermenojoined