00:00:37  * travis-cijoined
00:00:37  <travis-ci>luvit/luvit#1408 (luvi-up - 09f4666 : Tim Caswell): The build passed.
00:00:37  <travis-ci>Change view : https://github.com/luvit/luvit/compare/829820f616cb...09f4666382f3
00:00:37  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/44274781
00:00:37  * travis-cipart
00:52:42  * UniOnquit (Remote host closed the connection)
02:22:03  * cledevjoined
02:27:17  * cledevquit (Ping timeout: 240 seconds)
02:28:56  * cledevjoined
03:13:41  * cledevquit (Ping timeout: 264 seconds)
03:36:03  * dan336joined
04:04:11  * cledevjoined
04:08:09  * cledevquit (Client Quit)
04:19:21  * cledevjoined
04:30:06  * a_lequit (Remote host closed the connection)
04:58:01  * cledevquit (Ping timeout: 264 seconds)
04:59:13  * DarkGodquit (Ping timeout: 258 seconds)
04:59:36  * DarkGodjoined
06:24:29  * cledevjoined
06:35:14  * dan336quit (Quit: Leaving.)
07:48:40  * cledevquit (Ping timeout: 250 seconds)
07:52:24  * cledevjoined
09:06:14  * cledevquit (Ping timeout: 250 seconds)
09:11:20  * cledevjoined
09:23:15  * cledevquit (Remote host closed the connection)
09:24:23  * cledevjoined
09:40:57  * a_lejoined
10:25:30  * cledevquit (Read error: Connection reset by peer)
10:26:42  * cledevjoined
10:51:38  * torpor1joined
10:53:49  * torporquit (Ping timeout: 252 seconds)
13:32:08  * DarkGodquit (Remote host closed the connection)
13:33:24  * DarkGodjoined
14:53:14  * KennethWilkejoined
14:55:55  * torpor1quit (Read error: Connection reset by peer)
14:56:17  * torporjoined
15:15:57  * torporquit (Quit: Leaving.)
15:16:13  * torporjoined
15:19:38  * dan336joined
15:24:57  * torporpart
15:29:17  * KennethWilkequit (Remote host closed the connection)
15:33:00  * KennethWilkejoined
15:36:20  * xtjoined
15:36:56  <KennethWilke>g'morning
15:37:29  <dan336>morning
15:38:08  <xt>I'm new to luvit and I'm confused by the state of the different repos.
15:38:28  <xt>I'm porting my IRC bot from ev to uv, and I need things like http client too
15:38:38  <xt>can anyone help me out with which repos I should use?
15:41:00  <dan336>xt: yeah there are a few repos aren't there. There are mainly three that you could use
15:41:12  <dan336>(any who know better feel free to correct me)
15:41:16  <xt>I have used luv now
15:41:20  <xt>and I got a working client
15:41:31  <xt>but then I discovered that all the helpers like http/dns are in luvit repo
15:41:37  <dan336>thats right
15:41:49  <xt>can I use those with luv?
15:42:18  <KennethWilke>i believe you can, i know a few of the http bits are in flux atm
15:42:23  <dan336>probably
15:42:28  <KennethWilke>creationix would know for sure
15:42:33  <KennethWilke>ping!
15:42:44  <xt>local native = require('uv_native')
15:42:55  <xt>is there some branch that's ready to use?
15:43:06  <xt>or do I have to change stuff to use luvit-libs with luv?
15:43:21  <KennethWilke>i've been using the luvi-up branch of the luvit repo for my tinkering
15:43:59  <KennethWilke>it's been fairly reliable for me, easy to setup
15:44:00  <dan336>and I've been using the master branch, so I will have to update to the luvi-up branch soon.
15:44:57  <KennethWilke>i've not been using the http features, but the http decoder/encoder is still there in working order i believe
15:45:05  <KennethWilke>https://github.com/luvit/luvit/tree/luvi-up/app/modules
15:50:51  <xt>ok, thanks for answers guys. I will explore some more
16:01:01  <KennethWilke>no problem, good luck!
16:01:05  <xt>require'logging.console'
16:01:08  <xt>[string "bundle:modules/require.lua"]:147: Unknown format: console
16:01:12  <xt>Sadness.
16:32:44  * dan3361joined
16:35:21  * dan336quit (Ping timeout: 258 seconds)
16:59:51  * UniOnjoined
17:00:25  * UniOnquit (Remote host closed the connection)
17:00:46  * UniOnjoined
17:45:37  * KennethWilkequit (Quit: Leaving)
17:50:08  * KennethWilkejoined
17:55:15  <creationix>KennethWilke: I reviewed your PR, comments are in the commit
17:55:48  <xt>you can only make apps using luvit using the luvit binary now?
17:56:00  <xt>the custom require functions breaks things for me :(
17:56:02  <KennethWilke>i saw 'em, making changes
17:57:23  <creationix>xt: what do you mean? Which version of luvit are you using and what’s breaking?
17:57:39  <xt>do you see my messages from two hours ago?
17:57:45  <xt>or shall I repaste?
17:57:47  <creationix>nope, sorry
17:57:53  <xt>require'logging.console'
17:57:56  <xt>[string "bundle:modules/require.lua"]:147: Unknown format: console
17:58:09  <xt>I'm using the luvi-up branch of luvit
17:58:13  <creationix>is this luvit from luvit.io or from the luvi-up branch on github?
17:58:36  <creationix>sounds like luvi-up version with the bundle: url
17:59:19  <xt>what i want is to use luv, I already have that part figured out. But I also want to use the http-client and stuff from luvit
17:59:22  <creationix>yeah, looks like it thinks .console is the file extension and doesn’t know how to open such a file, try adding .lua
17:59:23  <KennethWilke>creationix, the data member is the only way to associate data with the callbacks in libuv
17:59:36  <KennethWilke>is it assumed closures will be used for any arbitrary data as well?
17:59:53  <creationix>KennethWilke: the data member is a void* in C, it has nothing to do with lua variables
18:00:00  <creationix>there are no closures in C
18:00:08  <KennethWilke>right, but what if i want data to be passed into my callback
18:00:15  <KennethWilke>that's what that void pointer is for, user defined purposes
18:00:33  <creationix>right, the void* data is to work around the lack of closure in C
18:00:37  <creationix>which is what I use it for
18:00:45  <creationix>but in lua, I don’t even give you the handle in the callback
18:01:00  <KennethWilke>yeah, that's another thing that still seems odd to me
18:01:02  <creationix>so attaching arbitrary data on the handle won’t do you much good since you need the closure to get the handle in the first place in lua
18:01:30  <creationix>I could modify the metatable of userdata to allow setting arbitrary properties on it
18:01:46  <creationix>I used to do this, I don’t think it has much overhead for people who don’t use it
18:02:04  <creationix>in the old libuv bindings in older luv, that was how you attached callbacks
18:02:14  <creationix>handle.onfoo = function (…) end
18:02:31  <KennethWilke>but that's trying to be more on the node style of things isn't it?
18:02:53  <creationix>the luv bindings are just trying to be libuv in lua
18:03:00  <KennethWilke>not having the handles passed to the callbacks makes me miss the libuv style of things
18:03:30  <creationix>right, like I said. I initially did it that way, but after a few weeks of using it, everyone agreed it was a bad idea
18:03:35  <KennethWilke>a lot of encouragement to use closures, which are great i just don't like being forced to use them
18:04:13  <creationix>my choices are either force you to use closures for the times you need the handle in a callback or force all callbacks to have an extra parameter that you usually don’t need
18:04:16  <xt>creationix: it actually works with require 'logging/console'
18:04:29  <xt>but then I discovered luvit doesn't use the standard lua package.path
18:04:46  <creationix>xt, correct, luvit’s require has little to do with lua’s require
18:05:06  <creationix>but it should fall back to lua’s require if it can’t find something. The fact that is errored on an unknown extension is a bug
18:05:25  <xt>is there a tutorial I can follow for this?
18:05:37  <xt>http://luvit.io/ is down
18:05:40  <creationix>not yet, sorry.
18:05:47  <creationix>luvit.io would be wrong for latest luvit anyway
18:06:44  <creationix>rebooted the server
18:06:57  <creationix>it has a memory leak and I haven’t had time to track it down. It goes down every couple of weeks
18:07:04  <xt>string.gfind, attempt to call field 'gfind' (a nil value)
18:07:08  <xt>what is going on..
18:07:15  <creationix>gfind isn’t a lua thing
18:07:37  <creationix>I think you mean gmatch
18:07:43  <creationix>http://www.lua.org/manual/5.1/manual.html#pdf-string.gmatch
18:08:28  <creationix>xt, if you want, you can just use luv with the normal lua or luajit runtime
18:08:37  <creationix>the http decoder from luvit is just a single file you can pull out
18:08:42  <creationix>though the tls stuff is trickier
18:08:57  <xt>segmentation fault
18:08:59  <xt>lol
18:09:13  <xt>creationix: okay, I mgiht try that, this is leading to all sorts of strangeness
18:09:31  <xt>I was using luajit before, I thought luvit used that too, but maybe with lua5.2-flags?
18:09:43  <xt>DLUAJIT_ENABLE_LUA52COMPAT removes string.gfind
18:10:44  <creationix>what is string.gfind then?
18:10:48  <creationix>I don’t see that in the 5.1 manual?
18:10:59  <creationix>but yes, I build luvit with LUA52COMPAT turned on
18:11:17  <xt>Function string.gfind was renamed string.gmatch. (See compile-time option LUA_COMPAT_GFIND in luaconf.h.)
18:11:21  <xt>from 5.1 manual
18:12:10  <creationix>ahh, so it’s an old lua thing
18:12:19  <creationix>I guess luajit left it in for backwards compat
18:12:29  <xt>yeah, I never noticed until now
18:12:30  <creationix>and I see the free version of PIL uses it
18:14:01  <creationix>http://lua-users.org/lists/lua-l/2013-04/msg00117.html
18:14:26  <xt>yeah, thanks
18:14:56  <xt>I think I must try to use luvit libs without using luvit launcher, since it's not so compatible with existing code
18:15:04  <creationix>so if you want to use luvit’s require, don’t use ‘.’ when you mean ‘/‘, it really confuses it
18:15:05  <KennethWilke>creationix, i think i got all your feedback added that PR
18:17:06  <creationix>yep, much better
18:17:26  <creationix>did my notes pointing to the various sources help?
18:18:07  <creationix>oh, should probably add [ci skip] when making doc only commits do the CI bots don’t do extra work
18:19:19  <KennethWilke>yeah they helped
18:19:36  <KennethWilke>i understand a bit more about how the things come together in C
18:19:51  <KennethWilke>but with that i found a lot of things that didn't work as i expected them to
18:22:41  <KennethWilke>i understand the reasoning behind why things aren't as i'd expect, but it feels stylistically restrictive to me
18:25:22  <creationix>you mean like how the callbacks work?
18:26:08  <KennethWilke>yeah, not being able to get to the object i expect to be able to access without using closures
18:28:17  <KennethWilke>it seems like it'd make generalizing a lot of things more confusing when collaborating with other developers
18:28:53  <creationix>I think it depends on your background. Using closures certainly isn’t very C like
18:29:07  <creationix>coming from C, you expect all state to be passed in as parameters to callbacks
18:29:32  <creationix>in JavaScript you have closures and can pass the state via “this” without putting extra stuff in the args
18:29:37  <creationix>lua has closures, but no this
18:30:11  <KennethWilke>it has self, but it seems like that'd complicate things making callbacks methdos
18:30:14  <KennethWilke>methods*
18:30:16  <creationix>luv used to look like uv.read_start(stream, function (stream, err, chunk) … end)
18:30:30  <creationix>right, the self sugar doesn’t work for inline callbacks
18:30:42  <creationix>it worked back when callbacks were properties on the userdata
18:30:52  <KennethWilke>the thing i'm missing is being able to define a function and pass it as that callback argument
18:30:53  <creationix>function stream:onread(err, chunk) end
18:32:04  <KennethWilke>my experience isn't so much coming from a C background, it's more of a perl, javascript, php, python background
18:32:15  <KennethWilke>i've rarely been able to use C for work projects
18:32:17  <creationix>stream:read_start(function (err, chunk) return userfn(stream, err, chunk) end)
18:32:33  <creationix>just wrap the function the user passes you to inject the stream
18:33:16  <KennethWilke>yeah that seems okay
18:33:29  <creationix>you can’t pass arbitrary methods as event handlers in JavaScript without binding them either
18:34:10  <KennethWilke>i usually use js more like a structured or functional language than as an object oriented language
18:34:32  <KennethWilke>so i've not often ran into that being a problem
18:34:33  <creationix>me too, but I digress
18:34:49  <creationix>I run into that problem because I spent years teaching node.js to newbies who love OOP
18:35:09  <creationix>closures are fantastic for event code
18:35:54  <creationix>btw, I fixed `lit install` last night
18:36:02  <creationix>the tools/test.sh script should actually run now
18:36:12  <KennethWilke>ahh, nice
18:37:02  <creationix>now I need to implement the network protocols and the server and we’ll have a POC minux security
18:37:10  <creationix>then add in some actual signature verification and it will be a usable beta
18:37:18  <creationix>*minus
18:37:29  <KennethWilke>nice! that'll be a great thing to have ready to rock
18:37:43  <creationix>hmm, and recursive dependencies
18:37:49  <creationix>I should file github tickets to track this
18:38:05  <creationix>probably a good practice anyway since I work remote remote
18:38:15  <KennethWilke>lol
18:38:33  <KennethWilke>yeah the github issue tracker is pretty nice
18:38:44  <creationix>(My team is remote to San Antonio (San Francisco) and I’m remote to my team (Red Lick, TX))
18:39:06  <KennethWilke>oh? i thought some of your team worked outa' austin too
18:39:15  <creationix>just rphillips on our team I think
18:39:31  <creationix>though he’s done a large part of luvit work over the years.
18:39:37  <KennethWilke>is it the cloud monitoring team?
18:39:41  <creationix>yep
18:39:52  <creationix>rje is in Washington state
18:39:59  <creationix>we’re all sorts of distributed
18:40:32  <KennethWilke>well, at least that's common in open source development, people are pretty used to things being remote
18:40:48  <creationix>yep, all the more reason to file issues
18:41:06  <KennethWilke>i was trying to look through them the other day to see if any were closable
18:41:15  <xt>the lib/luvit/*.lua can't be used with luv?
18:41:23  <xt>I don't know what uv_native is
18:41:38  <xt>sorry for having bad questions :(
18:41:46  <xt>this is all a bit confusing for a newcomer
18:42:42  <KennethWilke>they aren't bad questions! there's a lot of stuff in there
18:43:22  <KennethWilke>at least you seem to have a better grasp of Lua than i do
18:43:25  <KennethWilke>:p
18:43:32  <creationix>xt: that folder is legacy stuff from luvit 1.0
18:43:39  <creationix>use the libraries in app/modules
18:43:45  <xt>but those seem very incomplete
18:43:46  <creationix>they use “uv” which is the same as “luv"
18:43:51  <creationix>yep, we’re not done
18:43:54  <xt>no URL parser
18:44:07  <xt>oh, ok
18:44:14  <creationix>luv was re-written just a couple months ago
18:44:23  <creationix>and now we’re in the process of rewriting luvit to use it
18:44:45  <creationix>luv itself is quite stable and usable now, we even have most the docs covered now
18:44:58  <xt>yes, the luv part was easy to figure out
18:45:06  <xt>it's the supporting libs that confuse me
18:45:15  <xt>so maybe I should look at porting some of the old libs to new libs?
18:45:25  <creationix>that would be great
18:45:27  <xt>if I want a simple http client
18:45:42  <creationix>http_parser isn’t in the new code base, I instead wrote a pure lua encoder/decoder
18:46:11  <creationix>here is one example of making an HTTP request in the new code https://github.com/luvit/luvit/blob/luvi-up/tests/test-http.lua
18:46:28  <creationix>it’s not pretty, but works mostly
18:46:29  <xt>yeah, tested that. But it's missing a lot of stuff
18:46:43  <xt>no IDN, no url parser, no location moved follow
18:47:06  <creationix>libcurl bindings are another option I’ve considered
18:47:15  <xt>:S
18:47:16  <creationix>I think the multi interface can be made to play nice with the libuv event loop
18:47:25  <creationix>though the libcurl API is strange
18:47:49  <creationix>I recently write sync bindings for duktape, https://github.com/creationix/dukcurl
18:48:18  <creationix>with a little sugar, it wasn’t too bad https://github.com/creationix/dukcurl/blob/master/request.js#L9-L62
18:48:46  <xt>kinda backwards to use curl when we have all the pieces
18:49:18  <creationix>agreed, but it’s still a lot of work to glue all those pieces together
18:49:22  <creationix>tls is especially nasty
18:49:32  <creationix>rphillips: has been working on tls for quite a while now
18:50:08  <rphillips>i created a curl binding with the old luvit awhile ago. https://gist.github.com/rphillips/b501c8320381f1bdca64
18:50:27  <xt>these are the handlers I'm coming from https://github.com/Neopallium/lua-handlers
18:50:39  <xt>all the same problems solved, but with different even tloop
18:51:10  <xt>working fully with https
18:51:19  <creationix>nice
18:51:30  <creationix>xt: so why are you looking into luv/luvit then?
18:52:08  <xt>I like the basic blocks better
18:52:10  <creationix>hmm, doesn’t appear to be native to windows
18:52:31  <creationix>I really like luv and luvi, still unsure about the layers above that in luvit
18:52:33  <xt>and as you can see, no recent patches
18:52:51  <creationix>xt: so you’re writing high level HTTP API clients right?
18:53:12  <creationix>rphillips: nice ffi, I keep forgetting that’s an option
18:53:20  <xt>well.. I sort of expected there to be one already
18:53:33  <xt>but as far as I can tell there is one for old API, but not new
18:54:03  <creationix>right, I mean you want to work at the application layer doing things like reading and writing custom headers, sharing JSON messages, checking status codes and setting http methods right?
18:54:13  <xt>aye
18:54:20  <rphillips>thanks... the thought was to perhaps use libcurl for our poller since most everyone uses libcurl anyway to test webservers
18:54:27  * drorhjoined
18:54:45  <creationix>rphillips: not a bad idea, it’s certainly battle tested. I’m just unsure of how nice it plays with the event loop
18:54:59  <xt>libcurl will certainly be blocking, I think?
18:55:11  <rphillips>no. it's async
18:55:16  <creationix>curl_easy_perform is blocking
18:55:26  <creationix>but the multi interface has it’s own event loop of sorts
18:56:08  <xt>have you considered working togheter with openresty community on some of these things?
18:56:42  <creationix>well we’re now writing nginx plugins, but yeah, once the core is stable, we can look into sharing high-level libraries
18:56:47  <creationix>s/now/not/
18:57:09  <xt>they too are reimplementing all the things to run on top of event loop
18:57:44  <xt>https://github.com/pintsized/lua-resty-http
18:57:57  <creationix>rphillips: I wonder if libuv can select on http://curl.haxx.se/libcurl/c/curl_multi_fdset.html
18:59:05  <creationix>I’m experimenting with coroutine based APIs. Luvit itself needs to remain backwards compat for now with the node style APIs
18:59:16  <creationix>this is why I split luvit into three layers (luvit, luvi, luv)
18:59:20  <xt>creationix: this is what I'm most interested in myself
18:59:33  <xt>I find it very easy to use as a "end user" of the APIs
18:59:42  <creationix>xt: look at my lit code I’ve been writing. It’s all coroutine based, but using luv
18:59:50  <creationix>https://github.com/luvit/lit
19:00:11  <creationix>nice blocking I/O that only blocks the current coroutine https://github.com/luvit/lit/blob/master/commands/install.lua#L13
19:01:22  <creationix>it’s also using luvit’s require system since I like it a lot better than the lua one
19:01:31  <xt>so, don't you require a http client for that? :-)
19:01:35  <creationix>nope
19:01:54  <creationix>but I did implement git core for the storage
19:02:09  <creationix>and will be soon implementing the network protocol for syncing between nodes
19:06:38  <creationix>xt: though I may end up adding an HTTP based version of the protocol for people behind crappy proxies
19:06:55  <creationix>seems https is the only reliable protocol for communicating in some places
19:07:37  <xt>I must go back to the drawing board, and see what I want to do..
19:07:55  <creationix>xt: you could just use stable luvit for now
19:07:57  <creationix>luvit.io is back up
19:08:04  <creationix>and the master branch on github still has the code
19:08:12  <creationix>it’s used in production at lots of places
19:08:28  <xt>I guess
19:08:36  <creationix>personally I would rather use luv and luvi
19:09:23  <xt>I have ported to luv already, so I could even cheat and use curl for the http-things I need. But then again, I would also need a http server
19:09:32  <creationix>I think http sugar is next on rphillips’s list when he finishes the tls stuff
19:10:03  <creationix>xt: did you see https://github.com/luvit/luvit/tree/luvi-up/bench/http-cluster ?
19:10:16  <creationix>it’s a really fast http server using the encoder/decoder directly
19:12:19  <creationix>hmm, that section “How HTTP works” is wrong, it’s explaining the old coroutine based codec
19:12:33  <xt>looks almost like nginx design
19:12:49  <creationix>the fd passing?
19:12:58  <xt>and worker per core
19:13:12  <creationix>it’s a pretty common trick on unix systems. The workers aren’t balanced, but I don’t consider that a problem
19:13:37  <creationix>if you don’t have enough work to keep all workers busy, what’s wrong with one worker getting most the work. It’s not like it slows anything down
19:14:26  <creationix>if anything, all work going to the first worker is a good thing under low load. Keeps cpu affinity and caches in a better state
19:17:13  <creationix>lit milestone! https://github.com/luvit/lit/milestones
19:20:19  <creationix>rphillips: does curl work on windows? It seems to be all fd based. Windows has SOCKET handles instead
19:20:45  <creationix>I guess for the agent pollers that wouldn’t matter since they always run on linux
19:21:14  * songgaoquit (Excess Flood)
19:21:30  <creationix>I think using uv_poll_init_socket and uv_poll_start with the fs set from curl should make for a decently fast integration
19:21:46  * songgaojoined
20:14:27  <creationix>I found what’s been causing short call stacks. It’s when I use coroutine.wrap(), it by default onlt shows the top stack call
20:14:42  <creationix>putting an xpcall with debug.traceback in there helps
20:15:08  <creationix>https://github.com/luvit/lit/blob/master/main.lua#L5-L18
20:15:33  <creationix>also starting a coroutine before requiring the apps main logic means I can block on I/O whenever I want
20:26:33  * songgaoquit (Excess Flood)
20:26:51  * songgaojoined
22:58:31  * dan3361quit (Quit: Leaving.)
23:40:11  * KennethWilkequit (Quit: Leaving)