00:10:48  * indexzeroquit (Quit: indexzero)
00:41:29  * pancakequit (Quit: zz)
01:01:54  * xmingquit (Read error: Connection reset by peer)
03:00:55  * xmingjoined
04:06:22  * dvvquit (Read error: Operation timed out)
04:35:26  * dvvjoined
04:50:00  * dvvquit (Ping timeout: 246 seconds)
05:04:36  * indexzerojoined
05:05:00  * indexzeroquit (Client Quit)
05:17:13  * dvvjoined
06:23:27  * xmingquit (Changing host)
06:23:27  * xmingjoined
07:00:41  * tim_smartquit (Quit: leaving)
07:02:16  * tim_smartjoined
07:22:46  * tim_smartchanged nick to tim_smart|away
09:39:55  * mmaleckijoined
11:38:31  * mmaleckiquit (Ping timeout: 260 seconds)
11:43:23  * mmaleckijoined
12:33:19  * mmaleckiquit (Ping timeout: 246 seconds)
12:53:21  * dvvquit (Ping timeout: 246 seconds)
12:59:58  * mmaleckijoined
13:50:01  * dvvjoined
14:08:31  * mmaleckiquit (Ping timeout: 246 seconds)
14:14:07  * mmaleckijoined
14:23:44  <creationix>morning everyone
14:32:56  * TheJHjoined
14:41:41  <xming>heya
14:43:04  <xming>made some progress here, yajl and http_parser build against system libs or linked statically to the downloaded src
14:43:35  <creationix>cool
14:43:54  <creationix>I talked to the libuv guys, we'll have to maintain a cmake version of libuv
14:43:59  <creationix>though it shouldn't be hard
14:45:53  <xming>maybe we dont' have to :D
14:46:15  <creationix>xming, are you still using cmake for everything?
14:46:25  <creationix>or do you mean non-bundled libuv
14:47:03  <xming>someone already forked libuv and maintains cmake build :D https://github.com/okuoku/libuv
14:47:20  <xming>so I saied "maybe"
14:47:34  <xming>everything is going to be cmake
14:47:56  <xming>creationix: also auto detect modules in src/modules is working
14:48:07  <creationix>:)
14:48:18  <xming>we are going to have a big problem iwth cross compiling
14:48:18  <creationix>how hard is cmake to get on a machine?
14:48:34  <creationix>xming, luajit bytecode compiling?
14:48:38  <xming>how hard? Most distros have that
14:48:58  <xming>idd, lujia only generate "native" ELF\
14:49:16  <xming>/slujia/luajit
14:49:23  <xming>blah can't type today sorry
14:49:31  <creationix>I was thinking we could teach the "luvit" binary to do bytecode compiling
14:49:44  <creationix>so cross-compile a non-bundled luvit
14:49:56  <creationix>then have luvit bundle itself using arm
14:50:01  <creationix>(or whatever target)
14:50:51  <creationix>or just add a --bundle=/path/to/newbinary fkag
14:51:12  <creationix>I guess it depends on how hard that is
14:51:31  <creationix>it would need to not depend on the system linker or compiler
14:52:38  <xming>currently for the download dpendencies I use tarballs
14:52:40  <creationix>xming, do your method is to configure everything at build-time and do it in one step
14:52:44  <xming>IMHO tarballs are better
14:52:57  <creationix>tarballs instead of git submodules?
14:53:05  <xming>creationix: you can if you know all the defines
14:53:08  <xming>like this
14:53:27  <xming>cmake ../ -DUSE_HTTP -DUSE_SYSTEM_HTTP ....
14:54:01  <xming>creationix: I can add git submodules, but I will do that later, known tarballs (versions) is better to avoid brakage for users
14:54:09  <xming>git is needed for devs
14:55:07  <creationix>currently I use submodules for development
14:55:23  <creationix>and the `make tarball` target creates a single tarball with all deps included
14:55:41  <xming>creationix: if you want to get a feel of cmake for luvit you can download the tarball and try https://github.com/downloads/xming/luvit/luvit.cmake-test.tgz
14:56:39  <creationix>xming, so install cmake from system?
14:56:51  <xming>yeah, what do you use?
14:57:20  <creationix>ubuntu
14:57:27  <xming>that tarbalss is made a few days ago, you need all system libs
14:57:37  <xming>apt-get cmake?
14:57:52  <creationix>right
14:57:56  <creationix>wow, us.archive.ubuntu.com is really slow right now
14:58:02  <creationix>500 bytes/second
14:58:05  <xming>ubuntu is slow :D
14:58:12  <creationix>faster than windows
14:58:20  <creationix>and most the drivers work out of the box
14:58:31  <xming>I haven't had any windows systems in like 10 years
14:58:32  <creationix> I run archlinux on my raspberry pi
14:58:46  <creationix>my last windows box was windows 98
14:58:53  <xming>last windows version I know pretty well is win2k
14:59:19  <xming>I have been using Linux since 1991 dual booting
14:59:33  <creationix>I do run OSX on my macs though. I never could get used to gnome with a mac keyboard
14:59:58  <xming>I got my wife a MBP, my kid has a hackintosh
15:01:15  <xming>me all the way Linux, but I am really considering migrating to *BSD
15:01:57  <creationix>so cmake was only 5,257Kb to download (including deps I didn't have)
15:02:00  <creationix>that's not too bad
15:02:22  <xming>it's really nifty, except for the syntax :D
15:02:35  <creationix>ok, so error
15:02:38  <creationix>complained about LUAJIT_INCLUDE_DIR
15:02:46  <creationix>do I need to install luajit-dev or something?
15:02:46  <xming>it can d/l, untar, do git, file operations, ....
15:03:01  <xming>no need for external tools
15:03:39  <xming>yeah for that version you need too system libs and includes
15:03:51  <xming>s/too/all
15:04:47  <xming>doing this cmake thing is really not difficult, but keeping all permutations in-check is the hardest part
15:06:12  <creationix>there is libluajit-5.1-dev, not sure what version that is
15:06:21  <creationix>I use some fairly recent stuff in luvit
15:06:42  <xming>creationix: http://pastebin.com/eFRZRCUM
15:07:04  <xming>that is a cmake file for making your own modules will look like
15:07:21  <xming>that is more complex than simple module
15:07:23  <creationix>wow, that's verbose
15:08:03  <xming>it can fetch tarball, unpack, configure, compile, ..... or use system lib
15:08:14  <xming>then it bundles (still one line to add for that)
15:09:12  <xming>I still want to make simpler
15:09:35  <xming>trying to see what I can group together and put into macro() function()
15:17:39  <xming>creationix: it still can't find LUAJIT_INCLUDE_DIR?
15:19:06  <creationix>-- Could NOT find LUAJIT (missing: LUAJIT_LIBRARIES)
15:19:20  <creationix>I tried both using ubuntu's package and running `make install` from luajit source
15:21:57  <xming>it looks for luajit.h in /usr/include/luajit-2.0 or /usr/include/luajit
15:22:15  <xming>where is your luajit.h
15:22:49  <xming>oops libs
15:23:21  <xming>what is your libluajit called?
15:27:09  * spionWjoined
16:10:36  <creationix>sorry, was in meeting
16:10:46  <creationix>I installed luajit into the /usr/local PREFIX
16:11:34  <creationix>/usr/local/bin/luajit-2.0.0-beta10 and /usr/local/include/luajit-2.0/lua.h
16:11:45  <creationix>standard `make install` target
16:12:28  <xming>there is also /usr/local/include/luajit-2.0/luajit.h isn't there?
16:26:09  * spionWquit (Ping timeout: 246 seconds)
16:37:12  <CIA-113>Ryan Phillips features/https * r05f2b24 / (5 files in 3 dirs): https: Initial HTTPS Client Support - http://git.io/aWEYfA
16:38:04  <CIA-113>Ryan Phillips features/https * r5971f97 / lib/luvit/https.lua : https: add license header - http://git.io/0WLKqw
16:38:47  <creationix>xming, yep
17:29:31  * AvianFlujoined
17:56:12  * neomantrajoined
17:56:55  * `3rdEdenjoined
18:15:41  * mkandrashoffjoined
19:05:03  * tim_smartjoined
19:05:03  * tim_smartquit (Client Quit)
19:06:09  * tim_smart|awaychanged nick to tim_smart
19:08:35  <levi>creationix: I've actually built luvit and played with it a bit now. It's shaping up nicely!
19:09:31  <levi>It is a bit closer to node.js than would be my preference, but I understand that's your explicit design goal.
19:31:47  <creationix>levi, are you lua person by background?
19:36:15  * kevwiljoined
19:38:17  * kevwilpart
19:38:33  <levi>Nope.
19:42:57  <dvv>Hi! creationix: what could be arguments against luarocks as building supersystem (which can relay to make/cmake) nowdays? i believe we can have pure luajit + luvit package
19:43:34  <creationix>dvv, same objections as always
19:43:50  <creationix>if you're going to be compatable with something, you have to do it properly
19:43:55  <creationix>I'd rather just be incompatable
19:44:47  <creationix>it could be done, sure, but that's not my goal
19:45:05  <creationix>luvit is a platform that uses lua, not a lua library
19:45:09  <dvv>i'm not about require()ing existing sync-style modules
19:45:28  <dvv>but about building system
19:45:44  <dvv>which is proven
19:45:46  <creationix>oh, I see
19:45:50  <xming>https://github.com/LuaDist/Repository
19:46:00  <creationix>sure would be strange to use luarocks to build luvit, but then not use it in luvit
19:48:25  <dvv>i'm investigating the way one can install luarocks so the the latter mimicks luvit's way of looking up modules
19:50:26  <dvv>they allow to install it "locally" and even have module versioning, afaics
20:01:14  <levi>creationix: My background is fairly polyglot; mostly I work in C and play in various languages like Scheme, Python, Haskell, etc.
20:03:00  <creationix>levi, what would you change?
20:03:05  <creationix>what parts of node do you not like?
20:05:08  <levi>I really am not crazy about the ubiquity of asynchronous callbacks. I mean, they work fine and have their advantages, but they really do a number on the 'flow' of code.
20:07:00  <creationix>levi, true, but what's the alternative?
20:07:09  <creationix>non-blocking I/O requires some sort of continuation
20:07:15  <creationix>callbacks are very simple
20:07:26  <creationix>(in languages with closures at least)
20:08:45  <levi>Well, there's also cooperative threading. I've used several languages with synchronous I/O APIs that do not block the runtime for I/O.
20:10:08  <dvv>creationix: so luvit can itself be a rock, and luvit modules can be as well. that way we don't have to provide ugly --cflags et. al options, care of headers, arch, os etc.
20:11:17  <dvv>gone can be numerous weak attempts to normalize moduling and spawn a robust package manager etc.
20:13:33  <levi>I'm not suggesting you ought to rearchitect luvit, and indeed I think the way you've set it up would allow experimenting with alternatives "off to the side" so to speak.
20:16:02  <creationix>levi, yeah, using libuv is a hard requirement
20:16:07  <creationix>it wouldn't be luvit without it
20:16:13  <creationix>libuv is non-blocking and callback based
20:16:42  <levi>Sure, you've got to have it that way in the core.
20:17:10  <creationix>dvv, if you have time, you could make a fork of luvit that's packaged as a standard luarock
20:17:17  <creationix>to see what people think
20:17:42  <creationix>my use case is building single-binary apps
20:18:01  <creationix>I want a folder people can download, customize, and then bundle into a single app
20:18:38  <creationix>levi, I did talk to Mike Pall about this, his idea was to rewrite libuv to be iterator based (select style)
20:18:49  <creationix>and then call the callbacks or coroutines or whatever at the lua level
20:18:57  <creationix>then ffi could be used instead of C bindings
20:19:00  <creationix>and it would be super fast
20:19:07  <levi>Interesting.
20:19:20  <creationix>I like the idea, but that would be a rewrite of libuv
20:19:43  <levi>I think a lua-only layer could still be written.
20:19:45  <creationix>If I had time, I would write a select-style layer on top of libuv in C and ffi into that
20:19:54  <creationix>libuv as it is today isn't ffi able
20:19:56  <creationix>not purely at least
20:20:07  <creationix>not to mention that ffi callbacks are really slow
20:20:23  <levi>The lua-only layer wouldn't provide ffi, but it would provide an alternative user API without replacing the old one.
20:20:48  <creationix>levi, that can be done too, but not blocking
20:21:03  <creationix>a blocking select function can be turned into non-blocking callbacks
20:21:06  <creationix>but not the other way
20:21:40  <levi>That's not quite what I was thinking of.
20:21:51  <creationix>so if libuv instead was a single API to get events uv_get_event(uv_event* event)
20:22:03  <creationix>levi, you can layer coroutines on top of luvit's callbacks
20:22:09  <creationix>and that looks blocking
20:22:11  <levi>That is what I meant.
20:22:17  <creationix>I made an example in the examples folder
20:22:21  <creationix>that works quite well
20:22:38  <pquerna>m? you could use lua coroutines as they exist today with the exisitng callback api
20:22:47  <pquerna>using lua_resume
20:23:21  <creationix>https://github.com/luvit/luvit/blob/master/examples/fs-coroutines.lua#L14-15
20:23:30  * dvv-androidjoined
20:23:47  <creationix>https://github.com/luvit/luvit/blob/master/lib/luvit/fiber.lua#L22-25
20:23:55  * dvv-androidquit (Remote host closed the connection)
20:24:08  <creationix>pquerna, use coroutines at the C layer?
20:24:26  <creationix>that could work
20:24:44  <creationix>then each "thread" would appear blocking and the system would act as if it was multithreaded
20:24:48  <creationix>mostly
20:24:50  * dvv-androidjoined
20:25:26  <creationix>I still like Mike's idea
20:25:35  <creationix>but the libuv guys weren't interested
20:25:48  <creationix>isaac called it a "boil the oceans" idea
20:26:06  <levi>creationix: Yeah, I saw those and I was thinking along those lines, but more developed. Clearly luvit-the-runtime supports it, but luvit-the-system doesn't really provide much and assumes you're going to do everything via callbacks.
20:26:30  <creationix>levi, right, callbacks are the lungua franca
20:26:47  <creationix>and to be fair, it's really hard to do arbitrart parallel work using coroutines
20:26:55  <creationix>callbacks are actually simpler for that kind of work
20:27:00  <creationix>same for event handlers
20:27:07  <levi>Well, using raw coroutines, I agree.
20:27:23  <creationix> even using full blocking syntax
20:27:31  <creationix>in a blocking system, you can only do one thing at a time
20:27:37  <creationix>there is no way to describe parallel work
20:28:10  <levi>Sure there is, you just spawn additional tasks/threads/fibers/whatever you want to call them.
20:28:48  <creationix>ok, so "fiber" or whatever would be an async function and run in parallel
20:28:50  <creationix>that could work
20:29:20  <creationix>though I worry about the performance overhead of using coroutines everywhere
20:29:41  <creationix>but preserving the stack sure makes debugging and error handling easier.
20:30:07  <creationix>levi, but other than the fs module, there aren't many async functions
20:30:10  <levi>It wouldn't remove the asynchronous callback layer beneath, so you could always optimize stuff that's going too slow.
20:30:11  <creationix>just event handlers
20:30:33  <creationix>yeah, so select-style C layer with pure coroutine-style lua layer
20:30:35  <creationix>that could be nice
20:31:27  <creationix>pquerna, would luvit still be attractive to you guys if it had a coroutine based API instead of a node-style callback API?
20:31:29  <creationix>just curious
20:31:41  <creationix>I know part of the reason you joined luvit was because it was like node, but uses less ram
20:31:44  <levi>There's no reason the two can't coexist, either.
20:31:55  <creationix>sure
20:32:06  <creationix>I'm just trying to gauge how important similair APIs is
20:32:14  <levi>Although callback APIs tend to be infectious.
20:32:33  <creationix>coroutines wrap them fairly well
20:32:47  <creationix>and if the C layer was blocking, it would be easier to build both types on top
20:34:10  <creationix>hmm, how well could async functions be wrapped?
20:34:18  <creationix>my "fiber" module isn't enough sugar
20:34:25  <creationix>it's still obviously a callback
20:34:33  <creationix>(which was on purpose)
20:35:02  * mmaleckiquit (Ping timeout: 265 seconds)
20:35:41  <levi>I don't think it would be a problem, it would just be a matter of keeping track of which coroutines belong to which callbacks.
20:37:59  <creationix>so in streamline.js, you can do things like `if (foo(a, _) || bar(b, _)) { ... }` where foo and bar are actually async functions
20:38:25  <creationix>I think we could do that with coroutines without writing a code transformer
20:38:48  <creationix>if wait(foo, a) or wait(bar, b) then ... end
20:39:43  <creationix>fiber(function (wait) ... end)
20:39:47  <levi>Where wait would spawn a coroutine-thread and block the current thread on its result?
20:39:54  <creationix>fiber would spawn the coroutine
20:40:08  <creationix>so you can't suspend the main thread
20:40:14  <creationix>but you can suspend within any fiber
20:40:22  <creationix>this would be trivially easy today
20:41:15  <creationix>we could even give fiber a callback since it's non-blocking
20:41:21  <creationix>so we know when the coroutine is done
20:41:40  <creationix>and then a higher-level api could "block" on our fiber based function
20:41:42  <levi>In the model I'm thinking of, every 'server' you would want to run would have its own coroutine, and it would spawn a new coroutine for every socket, etc.
20:42:21  <creationix>http.createServer(function (req, res, wait) ... end)
20:42:33  <creationix>so you could use wait within the http request handler
20:43:25  <creationix>actually, I kinda like the wait syntax
20:43:39  <levi>I was also envisioning a global task switcher and a single set of blocking/task switching functions to manage them instead of passing 'wait' functions around.
20:43:41  <creationix>thanks to lua's multiple return values we can get the error from async functions
20:43:51  <creationix>we'll just need to swap the order to make it assert friendly
20:44:02  <creationix>levi, so even more implicit
20:44:12  <creationix>hmm..
20:45:08  <levi>I think it might be worth mocking up some fake code to see what these different ideas would look like implementing various common things.
20:45:28  <creationix>I worry about making it too implicit
20:45:36  <creationix>with wait, it's obvious what's going on
20:46:13  <creationix>since state can change out from under you while you're suspended
20:46:18  <creationix>explicit suspension is a good thing
20:46:26  <levi>I was thinking that you could use naming conventions to indicate things that might suspend.
20:46:34  <creationix>just if only we could make it explicit but not painful
20:47:18  <pquerna>rphillips: anything i can help with on --setup / https client?
20:47:29  <levi>I think that the other side to this coin would be some better state management things as well.
20:48:25  <levi>It would be nice if programs written in idiomatic style would work both in cooperative and preemptive threading models.
20:48:46  <rphillips>pquerna: definetly. the luvit http code monkeypatches the stream, and it's messing up the cleartext TLS stream
20:48:51  <levi>I don't have any concrete suggestions in that direction, though.
20:48:58  <rphillips>pquerna: I can't post to the auth server
20:49:23  <rphillips>pquerna: https://github.com/racker/virgo/pull/115
20:49:49  <rphillips>and https://github.com/luvit/luvit/pull/254
20:50:03  * dvv-androidquit (Ping timeout: 246 seconds)
20:50:11  <creationix>levi, yeah, not sure I understand that concretely
20:50:12  <rphillips>the Ele API client works... I ran raxmon and got a token and plopped it in
20:51:11  <pquerna>rphillips: ah
20:51:51  <rphillips>pquerna: some help on the post + http layer would be helpful
20:52:23  <levi>creationix: Well, mostly a coroutine thread should be the only one touching its own data, and data that needs to be shared should be managed by some abstraction that ensures consistency.
20:56:38  <creationix>it's no different than callback based code
20:56:42  <creationix>just need to be aware
20:56:46  * pancakejoined
20:57:17  <pancake>hi
20:57:19  <pquerna>rphillips: kk, taking a look
20:58:03  <creationix>pancake, hello
20:58:23  <creationix>levi, actually, I think I'll try my fiber wait idea
20:58:32  <pancake>https://twitter.com/compay/status/215532846637527041
20:58:35  <creationix>it's better than the current fiber module
20:58:40  <pancake>https://twitter.com/compay/status/215544073732370432
20:58:59  <pancake>https://twitter.com/compay/status/215532307547815936
21:00:54  <creationix>pancake, interesting
21:01:33  <creationix>so we need LON
21:01:44  <creationix>JSON:JS::LON:Lua
21:01:52  <pancake>:D
21:01:56  <levi>creationix: I think it's a great idea, especially for node-trained folks.
21:02:07  <pancake>in fact luvit's json parser is quite slow compared to nodejs one
21:02:10  <creationix>I mean, JSON is a subset of JS
21:02:15  <creationix>why not do the same thing for lua
21:02:18  <creationix>it would be close
21:02:44  <creationix>pancake, yeah, that's unfortunate
21:02:49  <creationix>I thought yajl would be faster
21:03:05  <creationix>does anyone use the current fiber module?
21:03:12  <creationix>I'd like to just replace it with a wait based one
21:03:21  <levi>creationix: I view the state management thing as orthogonal to the flow-management thing. Either way, it could use some help. :)
21:03:27  <creationix>fiber(block, callback)
21:03:29  <creationix>levi, agreed
21:03:38  <creationix>block(wait)
21:03:40  <pancake>creationix: didnt tried to benchmark yaml vs json
21:03:55  <creationix>pancake, which json?
21:04:00  <creationix>luvit's json is based on yaml
21:04:09  <pancake>the node's one, as far as it's the reference
21:04:33  <levi>Doesn't lua already have 'lon' in everything but name?
21:04:43  <creationix>the same that js had json
21:04:48  <levi>Yeah.
21:04:56  <creationix>but a parser that only accepts proper "lon" fixes the security concerns
21:05:02  <creationix>solved the same problem json solved
21:05:08  <creationix>*solves the same problem json solved
21:05:52  <creationix>JSON should be easier to parse than full js
21:06:24  <pancake>creationix: the code for parsing "lon" is in one of the tweets above
21:06:35  <creationix>pancake, right, using eval
21:06:37  <pancake>we could expose that function in the core api of luvit
21:06:48  <creationix>or was there another
21:06:58  <creationix>I guess it's not lon, but LTN
21:06:59  <pancake>https://gist.github.com/2962063
21:07:03  <creationix>Lua Table Notation
21:07:11  <creationix>Java Script Object Notation
21:07:23  <pancake>ltn takes sense
21:07:44  <creationix>actually since lua strings don't care about unicode, a LTN parser would be very easy
21:08:52  <levi>Actually, if you look at the code there, you'll notice that he's setting the environment, effectively sandboxing it.
21:09:07  <creationix>levi, good point
21:09:12  <creationix>lua is easier to sandbox
21:09:19  <levi>I really like that about lua.
21:09:25  <creationix>though they can still do while true do; end
21:09:46  <creationix>or eat all the ram
21:10:13  <levi>Hmm, yeah.
21:10:25  <creationix>besides, a proper subset would mean parsers could be written for other languages
21:10:40  <creationix>though I'm not sure what it would have over JSON
21:10:47  <creationix>except for allowing arbitrary binary data in strings
21:10:58  <levi>Yes, I agree, defining an interop subset would be good.
21:11:04  <pancake>the good thing about standards is that there are many
21:11:08  <creationix>and order or keys wouldn't be allowed to matter
21:11:32  <creationix>and nil can't be a key
21:11:50  <creationix>I mean value
21:12:18  <creationix>or key, I guess it's not allowed there
21:12:42  <creationix>LTN would know the difference between {["5"]=true} and {[5]=true}
21:12:56  <creationix>and could have tables as keys
21:13:04  <creationix>so I guess it's different enough from json
21:13:48  <creationix>what number formats should it accept
21:13:58  <creationix>I see lua ignore zeros at the start
21:14:02  <creationix>so no octal format
21:14:33  <creationix>hex format would be nice
21:14:37  <creationix>it's a shame JSON doesn't allow that
21:14:43  <creationix>but it does allow scientific notation
21:14:57  <levi>You could call it LTIN for "Lua Table Interop Notation", which would make it easier to pronounce.
21:15:24  * levipaints the bikeshed. ;)
21:15:42  <pancake>and will also support [[ ]]
21:17:54  <creationix>pancake, what's [[ ]]?
21:18:06  <creationix>LTIN :)
21:18:26  <creationix>pronounced el-tin?
21:18:48  <levi>Yup, that's what it sounded like in my head anyway.
21:19:16  <creationix>I should write up a LTIN spec in the luvit wiki
21:19:21  <pancake>multiline
21:19:22  <creationix>and add it to the luvit standard library
21:19:23  <pancake>text
21:19:30  <creationix>pancake, oh, right
21:19:36  * creationixhasn't used lua lately
21:19:44  <creationix>comments?
21:19:48  <creationix>should that be part of the spec?
21:19:57  <creationix>people miss it from json
21:20:06  <creationix>but it's not data, it's comments on the data
21:20:19  <creationix>my take is if we allow arbitrary whitespace, we should allow comments too
21:20:26  <creationix>both are for ease of writing and reading by humans
21:20:43  <levi>Sure, I would agree with including comments.
21:20:56  <creationix>both -- and --[[ ]] style
21:21:14  <creationix>so you can comment out blocks of a config file
21:22:28  <creationix>ok, I'm going to rewrite fiber.lua and document the LTIN format :)
21:22:38  <creationix>no time to write a LTIN parser today though
21:22:39  <levi>One of the nifty things about Lua as a data definition language is that a function of one parameter doesn't need parens, so you can do: Foo { bar = "baz", frob = "blot" }
21:23:19  <creationix>yeah, that's neat
21:23:26  <creationix>when I get into writing more lua than js I do that more
21:23:33  <creationix>been doing a lot of js for work lately
21:23:43  <creationix>thousands of lines of node code
21:23:56  <levi>You can also nest those, but that wouldn't work with LTIN.
21:23:58  <creationix>my next project involves lua and opengl
21:23:59  <creationix>:)
21:24:03  <levi>Nice!
21:24:11  <creationix>I'm trying to see if I can use luvit
21:24:18  <pancake>creationix: i think supporting objc should be more prioritary than ltn :P
21:24:43  <creationix>pancake, I need iOS for work
21:24:53  <creationix>my two iPads arrived this week
21:24:56  <pancake>:)
21:25:05  <creationix>but LTIN is simple and quick
21:25:08  <creationix>I like it
21:25:11  <pancake>heheh :)
21:25:30  <creationix>the keys won't port to other languages
21:25:35  <creationix>but the rest is fairly portable
21:25:47  <creationix>what other languages support arbitrary values as keys?
21:25:50  <pancake>are you going to add objc support for work?
21:26:05  <pancake>perl?
21:26:09  <creationix>pancake, my work project is to write an iOS appstore app using lua and opengl
21:26:22  <creationix>I guess js does now through maps
21:26:31  <creationix>so a LTIN parser can generate maps instead of objects
21:26:34  <levi>creationix: You can make appstore apps with Codea now, apparently.
21:26:45  <creationix>levi, btw, that block game rocks!
21:26:51  <levi>Yeah, it's fun!
21:26:55  <creationix>I've almost got all 3-stars on medium
21:26:59  <creationix>the others are super hard
21:27:35  <creationix>codea is way too high-level for my work project
21:27:49  <creationix>I basically need webgl + node, but in lua
21:27:56  <creationix>luvit + ffi sounds like a good fit for that
21:27:57  <pquerna>rphillips: do you know whats happening to the request body?
21:28:04  <levi>Nice.
21:28:06  <pquerna>rphillips: i don't see why its not being sent
21:28:36  <pancake>http://twolivesleft.com/Codea/
21:28:51  * creationixgoes off to write up the ltin spec before 5pm hits and his family demands his attention
21:29:34  <creationix>http://ltin.io/ is open, but I'm not paying $100 for it
21:29:38  <creationix>ltin.org is taken
21:29:47  <creationix>we could do ltin.luvit.io
21:29:49  <creationix>;)
21:31:03  <pancake>+1 subdomain :P
21:33:20  <levi>There you go. :)
21:35:10  <pquerna>rphillips: like i don't think the POST bodies are getting sent at all
21:35:42  <levi>It might be interesting to extend LTIN with a mechanism for referring to previous data in the stream to be able to capture references between tables and cyclic structurs.
21:36:54  <rphillips>pquerna: i put some prints in the tls write functions and saw the payload
21:37:02  * mmaleckijoined
21:37:07  <pquerna>rphillips: hrm, yeah
21:40:18  * `3rdEdenquit (Quit: Leaving...)
21:42:05  <pquerna>rphillips: looks like its always getting chunked
21:42:13  <pquerna>rphillips: even if its a content-length body
21:42:20  <pquerna>i think this will happen with non-https too
21:42:21  <pquerna>hrm
21:46:42  <pquerna>rphillips: bleh
21:52:03  <creationix>well, it's not a fully formed spec, but it has the general idea https://github.com/luvit/luvit/wiki/LTIN---Lua-Table-Interop-Notation
21:52:07  <creationix>feel free to tidy up
21:52:15  <creationix>I'd love parser diagrams like on json.org
21:54:28  <creationix>moved to https://github.com/luvit/luvit/wiki/Lua-Table-Interop-Notation
21:56:14  <levi>Isn't the order of integer keys in a table defined to be numeric order?
21:56:41  <pquerna>timer.setTimeout(0
21:56:44  <pquerna>rhrmnaadf
22:00:04  <creationix>nope
22:00:10  <creationix>that's why you should use ipairs
22:00:27  <creationix>though I think most implementations give the integer keys in order
22:00:35  <creationix>due to how the hash algorithm works
22:00:40  <creationix>(I could be wrong though)
22:09:51  <CIA-113>Paul Querna master * r43e6d4d / tests/runner.lua : Only run files that start with test, not just contain test. - http://git.io/VNixMA
22:17:30  * TheJHquit (Ping timeout: 272 seconds)
22:23:50  * mmaleckiquit (Ping timeout: 272 seconds)
22:24:40  <levi>creationix: You're right, not even integer keys are ordered.
22:29:06  <creationix>levi, coro idea https://gist.github.com/2962615
22:29:11  <creationix>anyway, got to go
22:31:03  <levi>Seeya!
23:31:05  * pancakequit (Read error: Operation timed out)
23:54:25  <pquerna>hrm
23:54:26  <pquerna>rphillips: print("buffer is broken on win32, need to not ffi into malloc")
23:55:51  <rphillips>pquerna: it may work now.
23:56:01  <rphillips>Not sure
23:56:04  <pquerna>nmmm, looks likes its still FFI'ing into malloc
23:56:20  <rphillips>The ssl code doesn't use the buffer
23:58:18  <pquerna>i know
23:58:27  <pquerna>sorry just was looking at making horrible test cases
23:58:31  <rphillips>I'll look into it more in the morning
23:58:57  <rphillips>Maybe tonight
23:59:17  <rphillips>Will be awesome to have a luvit client
23:59:31  <rphillips>Luvit Maas client *
23:59:43  <pquerna>:)