01:09:58  * kazuponjoined
03:40:12  * kazuponquit (Remote host closed the connection)
04:38:29  * SkyRocknRolljoined
04:40:47  * kazuponjoined
04:53:58  * dan336joined
04:54:30  * SkyRocknRollquit (Quit: Leaving)
04:55:02  * SkyRocknRolljoined
04:55:02  * SkyRocknRollquit (Changing host)
04:55:02  * SkyRocknRolljoined
04:56:10  * SkyRocknRollquit (Remote host closed the connection)
04:56:27  * SkyRocknRolljoined
05:04:02  * dan336quit (Quit: Leaving.)
05:29:16  * SkyRocknRollquit (Remote host closed the connection)
05:58:24  * SkyRocknRolljoined
05:58:24  * SkyRocknRollquit (Changing host)
05:58:24  * SkyRocknRolljoined
07:16:05  * kazuponquit (Remote host closed the connection)
07:30:06  * ldubjoined
08:00:04  * SkyRocknRollquit (Ping timeout: 276 seconds)
08:09:05  * kazuponjoined
08:26:54  * SkyRocknRolljoined
08:26:54  * SkyRocknRollquit (Changing host)
08:26:54  * SkyRocknRolljoined
08:45:07  * ldubquit (Ping timeout: 256 seconds)
08:46:25  * SkyRocknRollquit (Ping timeout: 244 seconds)
09:03:39  * SkyRocknRolljoined
09:03:43  * SkyRocknRollquit (Changing host)
09:03:43  * SkyRocknRolljoined
10:36:16  * kazuponquit (Remote host closed the connection)
11:24:55  * sousouxquit (Ping timeout: 246 seconds)
11:35:57  * SkyRocknRollquit (Remote host closed the connection)
11:55:09  * DarkGodjoined
12:00:39  * KennethWilkejoined
12:58:43  <rphillips>good morning
13:02:54  * travis-cijoined
13:02:55  <travis-ci>luvit/luvit#2206 (master - 1cc211d : Ryan Phillips): The build passed.
13:02:55  <travis-ci>Change view : https://github.com/luvit/luvit/compare/6d71e1318c89...1cc211d7c48c
13:02:55  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/66537784
13:02:55  * travis-cipart
13:20:42  <creationix>rphillips: morning. I'm having a hard time understanding https://github.com/luvit/luvit/pull/743/files
13:25:32  <rphillips>I think the plaintext was within the repeat block when it was returned int he outer block
13:25:37  <rphillips>Perhaps I misread that
13:27:10  <creationix>I'm pretty sure the change to tls/common.lua is all wrong, but the change to http-codec.lua does appear to change behavior, but I'm not sure exactly how
13:31:12  <creationix>It's true that I wasn't always resetting bytesLeft to 0 before the state ended, but that's fine since it's always reset before entering that state.
13:36:26  <creationix>hmm, he's online, perhaps he can shed some light on this patch
13:46:13  <rphillips>rje: hmm. that monitoring process is sticking around
13:46:18  <rphillips>after the service is stopped
14:03:58  * necrophcodrjoined
14:07:02  * travis-cijoined
14:07:03  <travis-ci>luvit/luvit#2207 (coro-all-the-things - 6d71e13 : Ryan Phillips): The build passed.
14:07:03  <travis-ci>Change view : https://github.com/luvit/luvit/compare/a76ee81d6a82...6d71e1318c89
14:07:03  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/66547224
14:07:03  * travis-cipart
14:08:31  * travis-cijoined
14:08:32  <travis-ci>luvit/luvit#2208 (master - 6d71e13 : Ryan Phillips): The build passed.
14:08:32  <travis-ci>Change view : https://github.com/luvit/luvit/compare/1cc211d7c48c...6d71e1318c89
14:08:32  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/66547341
14:08:32  * travis-cipart
14:10:29  * travis-cijoined
14:10:30  <travis-ci>luvit/luvit#2211 (coro-all-the-things - 20ea82c : Tim Caswell): The build passed.
14:10:30  <travis-ci>Change view : https://github.com/luvit/luvit/compare/a76ee81d6a82...20ea82cbe1b2
14:10:30  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/66547624
14:10:30  * travis-cipart
14:15:11  * boxofroxquit (Ping timeout: 252 seconds)
14:25:32  * DarkGodquit (Ping timeout: 256 seconds)
14:26:04  <rphillips>creationix: figure it out?
14:28:48  <rphillips>getting the msi version failed on the upgrade
14:31:34  * dan336joined
14:38:18  * DarkGodjoined
14:41:53  * boxofroxjoined
14:45:42  * SkyRocknRolljoined
14:46:33  <creationix>rphillips: yep, I reverted the pr
14:46:49  <creationix>I wonder what bug he was trying to fix
14:49:48  * necrophcodrquit (Quit: WeeChat 1.2)
14:58:23  <rphillips>looks like windows isn't downloading the msi
14:58:26  <rphillips>for an upgrade :(
15:31:02  <rphillips>creationix: rje: https://gist.github.com/rphillips/bb41dcf75e131b9266df
15:31:13  <rphillips>this test case doesn't download the entire file for some reason
15:32:53  <creationix>on windows only?
15:36:05  <rphillips>looks like on osx as well
15:39:58  <creationix>rphillips: yep, just tried on linux and it only gets about 5% of the file (114688 / 2592768)
15:42:51  <creationix>the server is express fwiw
15:45:45  <creationix>hmm, rphillips. I don't get any data events or the end event on most runs
15:46:12  <rphillips>yeah, it gets partiall downloaded
15:46:16  <rphillips>partially*
15:48:04  <rphillips>wget works
15:50:47  <creationix>it stops at a different point every time
15:51:04  <creationix>I suspect something at the tls level, but not sure
15:53:10  <creationix>how come the data event never fires in your example? Shouldn't it happen for each http chunk?
15:58:04  <rphillips>hmm .the data event fires for me
15:58:12  <rphillips>probably not printing it out
15:59:45  <creationix>the end event never happens on the tls stream
15:59:48  <creationix>hmm
16:00:26  <creationix>rphillips: oh, you're right, there is no print in the outer data handler
16:00:49  <creationix>so the stream just stops at some random point and the process exits with code 0
16:00:56  <rphillips>interesting thing is that it just exits
16:00:58  <rphillips>right
16:01:27  <rphillips>i'm going to try and find a non-tls file to download
16:02:40  <rphillips>http://releases.ubuntu.com/14.04.2/ubuntu-14.04.2-server-amd64.iso
16:03:19  <creationix>I'm logging some data here https://gist.github.com/creationix/d9f7e17b5a525ac6abf3
16:03:37  <creationix>cipherText is the length of the raw data on the tcp socket
16:04:15  <creationix>chunk is the cleartext chunk size (and buffer is the buffer size in the decoder) Since this has a content-length, there is never leftover bytes
16:04:27  <creationix>also the header come in on it's own chunk every time
16:04:31  <creationix>*comes
16:04:49  <creationix>I'll bet the tls stream protects the data frames from getting split apart
16:05:14  <creationix>extra is the buffer bytes left over after parsing and event is the parser output
16:05:52  <rphillips>non-tls file seems to work
16:08:07  <creationix>yep
16:08:20  <creationix>I'm now 95% sure the issue is somewhere in tls
16:08:22  <creationix>;)
16:10:01  * KennethWilkequit (Remote host closed the connection)
16:13:37  <rphillips>hmm. self.ssl:read()
16:13:40  <rphillips>sometimes returns a bool
16:15:39  <rphillips>and an err of 'want_read'
16:16:44  <creationix>sounds likely
16:22:56  <creationix>so most the want reads are followed by cipherText data events
16:23:07  <creationix>but it does end on a want_read without any data
16:23:42  <rphillips>https://github.com/luvit/luvit/blob/master/deps/tls/common.lua#L235
16:23:47  <rphillips>i think this is part of the problem
16:24:04  <rphillips>we tweak coro-tls to be a while loop
16:24:17  <rphillips>not to mention, it's calling the outer callback too many times
16:24:27  <rphillips>tweaked*
16:26:37  <creationix>you mean in TLSSocket:_write ?
16:26:41  <creationix>changing to a while loop doesn't seem to help
16:29:24  * kazuponjoined
16:31:52  * necrophcodrjoined
16:35:48  <creationix>plus it would cause double callbacks if it did actually loop
16:36:07  <creationix>coro-tls doesn't have that issue since the while loop blocks on writes and there is no callback
16:39:50  <rphillips>creationix: got it
16:40:10  <rphillips>the stream gets paused, and the handshake read handler gets put back
16:40:12  <rphillips>got a patch
16:41:08  <rphillips>https://github.com/luvit/luvit/pull/745
16:45:45  <rphillips>hmm. test is hanging... probably a bit overzeleous
16:52:04  * travis-cijoined
16:52:05  <travis-ci>luvit/luvit#2213 (fixes/fix_resume_tls - 5d349af : Ryan Phillips): The build has errored.
16:52:05  <travis-ci>Change view : https://github.com/luvit/luvit/commit/5d349aff16e4
16:52:05  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/66569643
16:52:05  * travis-cipart
16:53:51  <creationix>I think the if is fine vs the while
16:54:09  <creationix>I'm not sure why I made a while in coro-tls
16:54:30  <creationix>if you want to make sure, you can check pending in the callback
16:54:40  <creationix>(in the write callback)
16:55:34  <rphillips>creationix: we do the while here in lit, right? https://github.com/luvit/lit/blob/master/deps/coro-tls.lua#L63
16:56:13  <creationix>right, the same behavior in callback code is to check pending in the write callback and make a recursive call
16:56:23  <creationix>but I'm not convinced the loop ever happens more than once
16:56:54  * travis-cijoined
16:56:55  <travis-ci>luvit/luvit#2215 (fixes/fix_resume_tls - 8ad06d1 : Ryan Phillips): The build was canceled.
16:56:55  <travis-ci>Change view : https://github.com/luvit/luvit/compare/5d349aff16e4...8ad06d1c2c66
16:56:55  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/66570578
16:56:55  * travis-cipart
16:57:01  * creationixneeds to move to the office to have working vidyo, brb
16:58:01  <rje>rphillips, nice find on the tls bug, that's screwing up the upgrade download?
16:58:22  <rphillips>yep
17:08:08  * travis-cijoined
17:08:09  <travis-ci>luvit/luvit#2215 (fixes/fix_resume_tls - 8ad06d1 : Ryan Phillips): The build has errored.
17:08:09  <travis-ci>Change view : https://github.com/luvit/luvit/compare/5d349aff16e4...8ad06d1c2c66
17:08:09  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/66570578
17:08:09  * travis-cipart
17:40:48  * travis-cijoined
17:40:49  <travis-ci>luvit/luvit#2217 (fixes/fix_resume_tls - 05d3b64 : Ryan Phillips): The build has errored.
17:40:49  <travis-ci>Change view : https://github.com/luvit/luvit/compare/8ad06d1c2c66...05d3b6491121
17:40:49  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/66576434
17:40:49  * travis-cipart
17:54:51  * sousouxjoined
17:56:51  <sousoux>creationix: I noticed that the lit core api has changed a bit. Am I correct in thinking that installList takes a path to a folder and installs a dependency into it along with its dependencies into deps under that folder?
17:57:42  <creationix>right (path, list) will install list (and list’s deps) into path/deps
17:57:44  <sousoux>I was doing the install manually and then using processDeps before
17:58:37  <sousoux>how do I install into path?
17:59:09  <sousoux>do you mean that list is installeed in path or in path/deps
17:59:12  <sousoux>?
17:59:14  <creationix>just a single package, not worrying about it’s deps
17:59:39  <sousoux>I don't mind doing it in two steps
18:00:00  <sousoux>Install single package into path and then its deps into deps
18:00:13  <sousoux>That's more or less what I do now
18:00:41  <sousoux>basically I need to get the node and its deps
18:01:09  <creationix>did you see the new zip endpoing in the api?
18:01:12  <creationix>*endpoint
18:01:28  <creationix>exporting a single package to fs is simple https://github.com/luvit/lit/blob/master/libs/install-deps.lua#L74
18:02:26  <sousoux>ok. that was what I was doing before. and then I use the normal install to install its deps
18:02:29  <creationix>basically with the new system, you build the entire tree in the db, and then export it somewhere
18:02:33  <creationix>sounds like you want to export it to the fs
18:02:34  <creationix>https://github.com/luvit/lit/blob/master/libs/api.lua#L191-L199
18:02:57  <creationix>this example will give you a package with it’s deps embedded
18:03:27  <creationix>get hash, calculate deps, install deps, export to fs
18:03:45  <sousoux>ok got you
18:04:03  <creationix>querydb will accept either a tag hash or tree hash and give you the tree hash
18:04:27  <creationix>the db.read(…) gives you the tag hash
18:06:55  <sousoux>is installDeps still available via core? -- local installDeps = require('install-deps').toDb
18:07:32  <creationix>right, they aren’t all exposed in core
18:07:48  <creationix>but you can get at them via require(‘lit/libs/install-deps’)
18:08:13  <creationix>I can expose these in core if you want
18:08:22  <sousoux>ok. I tried an absolute require before and had trouble. I will try again
18:10:48  <creationix>I don’t call it absolute, (that’s something different like /home/user/code/myapp/deps/lit/…)
18:11:10  <creationix>but yeah, reaching into a package should work.
18:13:46  * SkyRocknRollquit (Remote host closed the connection)
18:14:21  <rphillips>hmm. this is weird
18:14:36  <rphillips>that small change made some of the tls tests not work
18:23:33  * travis-cijoined
18:23:34  <travis-ci>luvit/luvit#2219 (fixes/fix_resume_tls - af1af43 : Ryan Phillips): The build failed.
18:23:34  <travis-ci>Change view : https://github.com/luvit/luvit/compare/05d3b6491121...af1af4365bfe
18:23:34  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/66583883
18:23:34  * travis-cipart
18:25:10  <creationix>actually, this is weird, the tsp socket under the tls code stops getting data
18:25:29  <creationix>so while it only happens with this tls connection, I'm not sure how tls could be at fault
18:26:46  * fdagostinojoined
18:27:19  <fdagostino>Hi there
18:27:50  <creationix>fdagostino: welcome
18:28:00  <fdagostino>Thanks Tim
18:28:04  <creationix>sousoux: did the deep require work for you?
18:28:43  <fdagostino>I'm trying to compile Luvit in order to run it on an embbeded device
18:29:04  <fdagostino>but I need some guidance
18:29:10  <creationix>fdagostino: what kind of device?
18:29:29  <fdagostino>It's an EFT-POS, runs on top of an ARMv61
18:29:45  <fdagostino>it has a Linux, but I don't have console access
18:30:03  <creationix>oh, I remember, you posted to the mailing list
18:30:09  <fdagostino>right!
18:30:13  <creationix>how can you have a linux without console access?
18:30:27  <fdagostino>because the vendor don't allow you to access
18:30:56  <fdagostino>they have like an app manager that runs on top of the embedded linux
18:30:59  <creationix>I see, the only way to run code is to compile using their cross-compiler and write to sdcard or something?
18:31:29  <fdagostino>they provide an SDK with a toolchain for windows, using cygwin
18:31:37  <creationix>tricky
18:31:43  <fdagostino>the compiler is arm-brcm-linux-gnueabi-
18:32:11  <fdagostino>It is possible to have Luvit as a runtime through a shared library (.so)
18:32:14  <fdagostino>?
18:32:26  <creationix>that depends on what you mean by "luvit"
18:32:44  <creationix>the normal way the luvit binary is packaged is luvi + a zip file containing lua
18:32:54  <fdagostino>ok
18:32:55  <creationix>I don't think that trick would work with a .so
18:33:08  <fdagostino>but as I understood
18:33:12  <fdagostino>luvi is like a console tool
18:33:19  <fdagostino>right?
18:33:35  <creationix>luvi is the base runtime with zip asset bundling logic and some botostrap code
18:34:08  <fdagostino>ok, but luvi uses LuaJIT as runtime, right?
18:34:13  <creationix>we recently added a diagram to the docs to show the relationships https://luvit.io/docs.html
18:34:45  <fdagostino>LuaJIT can be compiled as a .so
18:34:54  <creationix>Simply having luajit + luv as a .so would give you a nice low-level version of luvit
18:35:23  <fdagostino>ok, sounds good
18:35:49  <creationix>I actually enjoy this level of abstraction and based most my code upon it mostly with some coroutine and require sugar I added
18:36:01  <creationix>the luvit metapackage is for people wanting a clone of the node.js APIs
18:36:25  <creationix>luv is pretty straightforward to build
18:36:52  <creationix>will cmake work with your cross-compiler?
18:37:50  <creationix>the luv bindings are just a single C file that #include's the other C files https://github.com/luvit/luv/blob/master/CMakeLists.txt#L43
18:38:06  <creationix>it just needs libuv and luajit headers to compile
18:38:31  * travis-cijoined
18:38:32  <travis-ci>luvit/luvit#2221 (fixes/tls_reads - 24625bd : Ryan Phillips): The build passed.
18:38:32  <travis-ci>Change view : https://github.com/luvit/luvit/commit/24625bd8ef2f
18:38:32  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/66585941
18:38:32  * travis-cipart
18:38:33  <fdagostino>I think I won't have problems compiling luajit and luv
18:39:22  <creationix>so if you go that route, things are a *lot* simpler
18:39:27  <creationix>and luv itself is mostly documented
18:39:31  <fdagostino>once I have that cross-compiled as a .so
18:39:32  <rphillips>creationix: rje: simplified the patch to just https://github.com/luvit/luvit/pull/746
18:39:48  <creationix>plus it almost mirrors the libuv docs at http://docs.libuv.org/en/v1.x/
18:40:45  <creationix>fdagostino: sounds like you good to go then. Once you have luajit + luv, I can help you cherry-pick parts of the luvit metapackage you want to use.
18:41:03  <creationix>rphillips: did that really fix it?
18:41:04  <fdagostino>that is similar to implementing duktape and dukluv, right?
18:41:11  <rphillips>creationix: yep
18:41:31  <creationix>fdagostino: yeah, luajit + luv is a *lot* like duktape + dukluv
18:41:51  <fdagostino>creationnix, thanks! I'll comeback when I've that running on my device
18:42:01  <creationix>btw, why use as a .so?
18:42:03  <fdagostino>one last doubt
18:42:19  <fdagostino>I need them as a .so or .a
18:42:30  <creationix>so main app is C, but you want to script some parts in lua?
18:42:34  <fdagostino>because is the way I can download to the device
18:43:02  <fdagostino>yes, the entrypoint for apps is in C or C++
18:43:16  <creationix>makes sense
18:44:12  * grep_awayquit (Ping timeout: 244 seconds)
18:44:28  <fdagostino>but let me check something in vendors doc
18:45:22  <creationix>rphillips: sure enough, that fixes it nicely. Good work.
18:46:56  * grep_awayjoined
18:47:06  <rphillips>thanks
18:47:16  <creationix>I guess it was calling handshake at the wrong time breaking stuff
18:47:36  <rphillips>yeah, the stream:pipe would pause the stream, then resume it with the handshake read handler
18:49:25  <creationix>well, I had figured it had something to do with resume
18:49:47  <creationix>rphillips: btw, do we need a luvi release with the openssl patch?
18:50:12  <rphillips>we do
18:50:17  <creationix>I don't know of anyone using luvit for tls server in production, but it can't hurt
18:50:25  <creationix>I use nginx as terminator in my luvit apps
18:51:40  <creationix>ok, I'll do a luvi release, then a lit release, then a luvit release?
18:53:20  <fdagostino>@creationix, let me know when I can ask you a question
18:53:27  <creationix>fdagostino: sure, what's up
18:54:23  <creationix>rphillips: I think lua-openssl is pointing to a commit that doesn't exist anymore, I'll update to master
18:55:11  <fdagostino>creationix: I've checked the vendors SDK. In the end when you compile a project you obtain an Linux app executable
18:55:41  <rphillips>rje: still can't get the version from the msi on download
18:55:58  <fdagostino>with Luvit, is it possible to obtain an app bundled as standalone linux app?
18:56:31  <fdagostino>because if I can get that, I don't need to embedded the runtime as a .so
18:56:31  <creationix>fdagostino: not sure what you mean
18:56:43  <creationix>you could make the normal luajit app with luv embedded
18:56:54  <creationix>but then your main entry-point is the luajit cli interface
18:57:05  <fdagostino>mmmm
18:57:10  <creationix>if they allow script files, that would work
18:57:14  <rphillips>creationix: could you +1 #746?
18:57:32  <creationix>start with #!/path/to/luvjit some lua code
18:57:55  <creationix>rphillips: done
18:58:06  <rphillips>thanks!
18:58:30  <creationix>rphillips: you can review coro-all-the-things when you want. I'm finished for now with it
18:59:08  * travis-cijoined
18:59:09  <travis-ci>luvit/luvit#2223 (master - 32a661f : Ryan Phillips): The build passed.
18:59:09  <travis-ci>Change view : https://github.com/luvit/luvit/compare/6d71e1318c89...32a661f5f53c
18:59:09  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/66588601
18:59:09  * travis-cipart
19:00:23  <creationix>rphillips: thanks. Basically the goal is to allow a coroutine thread instead of a callback in all luvit APIs where the callback is a one-off event
19:00:32  <creationix>and it will just suspend the current coroutine and return the result
19:00:41  <creationix>I'm just adding it as I need it
19:01:59  * travis-cijoined
19:02:00  <travis-ci>luvit/luvit#2224 (master - 9693566 : Tim Caswell): The build passed.
19:02:00  <travis-ci>Change view : https://github.com/luvit/luvit/compare/32a661f5f53c...969356674d79
19:02:00  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/66589021
19:02:00  * travis-cipart
19:02:07  * travis-cijoined
19:02:08  <travis-ci>luvit/luvi#555 (master - 3fa6b67 : Tim Caswell): The build passed.
19:02:08  <travis-ci>Change view : https://github.com/luvit/luvi/compare/9d026ae98cd0...3fa6b672c6f0
19:02:08  <travis-ci>Build details : http://travis-ci.org/luvit/luvi/builds/66588150
19:02:08  * travis-cipart
19:04:52  <fdagostino>I can download an linux app and companion files (lua scripts)
19:07:20  <fdagostino>but I can't execute a command with parameters
19:09:06  <fdagostino>for example, how do you execute the http-server.lua example?
19:09:30  <fdagostino>something like luvi http-server.lua? or luvit http-server.lua?
19:10:49  <necrophcodr>those are luvit examples i believe, not luvi examples
19:11:43  <necrophcodr>usually though a luvi app consists of a directory with a main.lua file. you then execute `luvi directory` to run the directory as an application.
19:11:43  <fdagostino>yes they are luvit examples
19:12:14  <fdagostino>ok thanks necrophcodr
19:12:38  <necrophcodr>fdagostino: you can read the help too by running `luvi --help`
19:13:00  <fdagostino>as i see in readme.md, you can do something like this:
19:13:24  <fdagostino># Build the binary when done luvi myapp -o mybinary # Run the new self-contained binary ./mybinary
19:13:35  <necrophcodr>that is true
19:13:42  <fdagostino>so in that case
19:13:52  <fdagostino>mybinary is a self-contained linux app?
19:13:52  <necrophcodr>you then want to do `luvi directory -o bin`
19:14:06  <necrophcodr>then you can simply execute `./bin` to run the single binary application
19:14:13  <necrophcodr>it is indeed
19:16:27  * boxofroxquit (Ping timeout: 250 seconds)
19:17:07  * kazuponquit (Remote host closed the connection)
19:17:15  <fdagostino>ok, thanks! I need "mybinary" to be ARMv61 compatible
19:17:29  <necrophcodr>fdagostino: then do the same thing on a ARMv6l platform
19:17:50  <necrophcodr>alternatively, you might want to look into proot (proot.me)
19:17:51  <fdagostino>ok, is not possible to cross-compile in Windows targeting ARMv61?
19:18:02  <necrophcodr>luvi doesn't cross compile no
19:18:59  * DarkGodquit (Ping timeout: 245 seconds)
19:19:05  * travis-cijoined
19:19:06  <travis-ci>luvit/luvi#557 (v2.1.1 - 677ed00 : Tim Caswell): The build passed.
19:19:06  <travis-ci>Change view : https://github.com/luvit/luvi/compare/v2.1.1
19:19:06  <travis-ci>Build details : http://travis-ci.org/luvit/luvi/builds/66590592
19:19:06  * travis-cipart
19:19:13  <fdagostino>ok,thanks, now I'm getting it
19:29:03  <rje>rphillips, what's going on with that?
19:29:18  <rje>rphillips, is the msi valid?
19:29:51  <creationix>fdagostino: did you decide to try to use luvi instead of just luajit + luv?
19:30:10  <fdagostino>I'm thinking the best way to implement this
19:30:51  <creationix>either compile in luajit + libuv + luv into your C app and use it as a library or compile luajit + libuv + luv using luvjit's main and run lua scripts with it
19:31:06  <creationix>luvi is if you want to mess with zip assets and more of the luvit ecosystem
19:32:16  <fdagostino>one question about luajit
19:32:26  <rphillips>rje: *sigh* i don't think it's still downloading the entire package
19:32:49  <creationix>rphillips: I got a done event when I tried
19:32:57  <rphillips>same here
19:33:15  <creationix>when you tried wget, did it have the whole thing?
19:33:27  <fdagostino>can luajit compile lua scripts into bytecode?
19:33:36  <creationix>fdagostino: yep, and embed in C code
19:33:44  <necrophcodr>fdagostino: yes
19:33:48  <creationix>that's how luvi embeds a little lua glue in it's bootstrap logic
19:34:07  <rphillips>creationix: yep
19:34:12  <rphillips>worked on the unicies
19:34:16  <creationix>you can output the lua bytecode as C or H files (basically a big char array)
19:34:33  <fdagostino>or a raw format i've seen
19:34:54  <creationix>fdagostino: right, there are several output formats
19:35:10  <creationix>lit will actually compile all lua source to raw bytecode when forming the embedded zip for bundles zip apps
19:35:27  <creationix>helps with memory usage since comments get stripped out this way
19:35:51  <necrophcodr>i dont recall, but is the raw bytecode actually portable, or is it based on things like endianness and shit?
19:36:06  <necrophcodr>i dont even know something something bits and bytes whatever
19:36:08  <creationix>I believe it's mostly portable
19:36:19  <fdagostino>so if i get a .so with luajit+libuv+luv binary compatible with my device and compile a program using luvit using luajit under windows
19:36:37  <fdagostino>then i can load the file in C?
19:36:46  <rphillips>so the test file I pasted is missing one chunk on the write
19:36:51  <rphillips>on windows
19:37:04  <creationix>necrophcodr: ok, luajit is portable unlike lua
19:37:17  <creationix>as long as you don't try to compile in one version of luajit and load in another
19:37:40  <necrophcodr>ah, so there can be version mismatch. makes perfect sense though. cool, thanks!
19:38:22  <creationix>rphillips: with a done event printed right?
19:39:49  <rphillips>https://www.evernote.com/l/AAldlQHrb5hEXKenqsUKu1rh1oozfcNKuIY
19:40:06  <rphillips>the content-length and the write length are about one chunk off
19:40:15  <rphillips>doesn't happen everytime :(
19:40:21  <fdagostino>but this raw bytecode is platform-independent? similar to .NET IL?
19:40:33  <creationix>rphillips: interesting
19:40:47  <creationix>fdagostino: correct, in luajit it's platform-independent
19:40:56  <creationix>vanilla lua is not, endiness can bite you
19:40:59  <necrophcodr>fdagostino: sure, but the issue is that certain libraries used may not be.
19:41:30  <necrophcodr>like ffi-libraries, such as some .so library or whatever
19:41:32  <fdagostino>necrophcodr, libraries used where?
19:41:43  * creationixis reminded he needs to finish his luajit bytecode interpreter in browser JS
19:42:04  <necrophcodr>creationix: as in luajit.min.js run lua shit on luajit?
19:42:47  <necrophcodr>fdagostino: libraries used by third parties for instance. if you're just writing lua scripts, you probably won't have to worry too much
19:42:59  <fdagostino>ok, perfect!
19:43:16  * boxofroxjoined
19:43:54  <creationix>necrophcodr: no, to run luajit bytecode in a browser
19:44:08  <necrophcodr>oh right bytecode
19:44:19  <creationix>I write VMs for fun, and it's not a bad bytecode
19:44:35  <necrophcodr>oooh i see, so you write luajit code, compile it with luajit, and run it in the browser
19:44:46  <creationix>yep
19:45:04  <necrophcodr>that is some hella cool shit. i should probably look into writing a vm some day.
19:45:48  <fdagostino>so, to confirm, with this approach I can write and compile lua scripts in Windows to raw bytecode and execute it on an ARM device (if cross-compile works)
19:46:19  <necrophcodr>fdagostino: if you do `luvi directory -o app` then you need to do it from an ARM device though
19:46:33  <fdagostino>no luvi involved
19:46:41  <creationix>fdagostino: right, or just send the lua to the arm device and have luajit compile it on the fly
19:46:41  <necrophcodr>then no problem as far as i see
19:46:48  <fdagostino>just luajit compile
19:47:40  <creationix>you can even compile to bytecode from a lua script via the string.dump() extension in luajit
19:47:49  <creationix>that's how lit's build tool does it
19:48:08  <creationix>http://luajit.org/extensions.html
19:48:29  <fdagostino>and as I see luvit source code is all lua scripts
19:48:58  <fdagostino>perfect, thanks creationix!
19:49:23  <creationix>luvit does depend on some code implemented in luvi that you won't have using luajit + luv
19:49:29  <creationix>but they can easily be ported
19:50:21  <fdagostino>no problem with that if I count with your help :P
19:50:31  <creationix>:)
19:52:17  <creationix>rphillips: my last Raspberry PI A+ just died
19:52:33  <creationix>the armv6 build of luvi is becoming harder and harder to support
19:52:38  * fdagostinoquit (Quit: Page closed)
19:52:54  <creationix>I can order a new B+ on amazon, but they pad the price a bit
19:52:59  * fdagostinojoined
19:53:06  <creationix>I should have picked one up while I was in Dallas, Microcenter had them for $25
19:53:44  <fdagostino>well guys, thank you for your help!
19:54:02  <fdagostino>I'll try to get the .so and let you know progress
20:07:31  * jetlquit (*.net *.split)
20:07:55  * jetljoined
20:13:34  <creationix>rphillips: I can see it too. It sometimes is missing 4096 bytes
20:15:07  <rphillips>croeationix: OS X?
20:15:24  <rphillips>creationix: ^
20:15:32  <creationix>no, linux
20:16:00  <rphillips>k
20:18:24  <rphillips>strange. I see a read event after the done event sometimes
20:21:07  <creationix>interesting
20:23:22  <creationix>rphillips: in the case where data is missing, we get an end event at the top level before the underlying tcp stream has emitted end
20:23:39  <creationix>something is triggerring end early
20:24:14  <creationix>actually nevermind, the tcp level end is always after the end event
20:36:11  * DarkGodjoined
20:39:43  <fdagostino>guys, I'm trying to cross-compile luajit, but at step BUILDVM lj_vm.o it throws "Error: no PE object support for this target"
20:39:50  <fdagostino>any idea?
20:47:47  <creationix>fdagostino: you did read the cross-compile docs right?
20:48:04  <creationix>other than that, you can ask on the luajit mailing list. (but make sure to read the docs first or Mike will get on to you)
20:48:25  <creationix>http://luajit.org/install.html
20:52:36  <creationix>fdagostino: hmm, your platform might be unsupported. Luajit is implemented in assembly
20:52:49  <creationix>even the interpreter is assembly. I'm not sure it has a fallback in C
20:53:08  <creationix>at a minimum you'd need to disable jit
21:00:27  <fdagostino>creationix, yes we are following that instructions
21:00:37  <fdagostino>thanks, I'll ask in their list
21:00:51  <creationix>if it is unsupported, you can always use stock lua with luv
21:01:12  <fdagostino>sorry, what is stock lua?
21:02:29  <creationix>the normal lua project from brazil
21:02:40  <creationix>http://www.lua.org/
21:02:50  * kazuponjoined
21:03:17  <creationix>it's even easier to build, but you don't get the nice parts of luajit
21:04:40  <creationix>I'm pretty sure lua bytecode isn't portable http://lua-users.org/lists/lua-l/2014-10/msg00185.html
21:07:49  * kazuponquit (Ping timeout: 250 seconds)
21:11:06  <fdagostino>thanks creationix
21:18:04  <rphillips>hmm
21:23:29  <creationix>rphillips: I did see the TCP end once before the high-level end
21:23:32  <creationix>(it was an error case that time)
21:27:06  <creationix>this server has tls compression doesn't it? The ciphertext sizes are much smaller than the plaintext chunks
21:27:41  <rphillips>it's out AEPs... not sure if it has compression
21:27:44  <rphillips>our*
21:27:58  <rphillips>simon just recently changed them to not use stud anymore
21:29:01  <creationix>https://gist.github.com/creationix/53f57a75b0bdc60e0e71
21:29:29  <creationix>it looks like we're missing a plainText event at the end sometimes
21:30:02  <rphillips>i am thinking the cleartext buffer may need a flush
21:31:41  <creationix>what do we need other than reading from it in a loop?
21:33:53  <creationix>comparing the end for success and fail cases: https://gist.github.com/creationix/53f57a75b0bdc60e0e71
21:34:11  <creationix>I just learned the second arg is 0 when the tls stream is done
21:36:04  <rphillips>hmm
21:39:11  <creationix>flushing self.inp doesn't seem to do anything
21:39:51  <rphillips>we get a cipher text payload, then right after that the nil for a close
21:40:29  <rphillips>https://www.evernote.com/l/AAlNpBxKX7VBjoc7cNWecjMo0vSmLB-d7ow
21:42:45  <creationix>I wonder if my http-codec is at fault this time
21:43:06  <creationix>the tls patterns look identical in both cases, except the size if off sometimes
21:44:07  <rphillips>maybe an off by one in the http-codec?
21:44:17  <rphillips>decodeChunked might be culprit
21:44:25  <rphillips>or decodeCounted
21:47:09  <creationix>one thing I've noticed is the high-level end happens right after the last plainText chunk and sometimes after the last plaintext end. I wonder if there is a nextTick in there somewhere
21:47:35  <creationix>also I can't reproduce the error anymore
21:48:05  <rphillips>:/
21:48:11  <rphillips>i always get 20480 bytes
21:48:12  <creationix>oh nevermind, I can, my reporting was just broken
21:51:08  <creationix>ok, so I improved my logging. The data is always all there, but often the end event happens when there is still a chunk or two left
21:51:52  <creationix>so end is just happening early
21:53:11  <creationix>and I can confirm the counter is hitting exactly zero too soon
21:53:19  <creationix>which explains the end event
21:56:23  <creationix>it can't be off-by-one because when there are exactly 4096 or 5256 bytes left, there is a chunk of exactly that size
21:56:32  <rphillips>yeah
21:56:38  <creationix>but then there are another one or two after that to make it match the size in the header
22:03:49  * kazuponjoined
22:05:04  <rphillips>hmm. this is a doozy
22:05:29  <rphillips>i think i'm going to debug with a large text file next
22:08:57  * kazuponquit (Ping timeout: 240 seconds)
22:09:54  <creationix>rphillips: ok, I'm pretty sure it's a race condition around data events being deferred with nextTick or something
22:10:12  <creationix>everything checks out at the tcp, tls, codec and codec consumer
22:10:19  <creationix>but the actual events dont't fire till later
22:11:05  <rphillips>maybe in the stream code
22:11:11  <rphillips>stream_readable uses nextTick
22:11:16  <creationix>compare the call to https://github.com/luvit/luvit/blob/master/deps/http.lua#L370 with when the data event happens
22:12:26  <creationix>yep, that's it for sure. The http layer enqueues the last two data events, then the end event happens and then the two data events
22:13:49  <creationix>res:_end() is sync, but res:push(data) is deferred
22:14:16  <creationix>maybe _end is the wrong call?
22:15:04  <rphillips>:push() might be it
22:15:19  <rphillips>where is the _end?
22:18:19  <creationix>rphillips: https://github.com/luvit/luvit/blob/master/deps/http.lua#L305
22:18:32  <creationix>I don't think an empty push is it, but it's worth trying
22:19:05  <creationix>actually, that does fix it
22:20:34  <rphillips>fully?
22:20:39  <rphillips>i think i'm still missing data
22:21:49  <creationix>this? https://gist.github.com/creationix/3fdc0dfba211debe6609
22:22:29  <creationix>I can run it 20 times on linux and it's good every time
22:23:49  <creationix>I got to go, good luck
22:24:38  <necrophcodr>i think i've fallen for luvit/luvit/deps/core.lua
22:24:43  <necrophcodr>that shit is simple and so amazing
22:25:56  <necrophcodr>i also like object functions that return self if they dont return anything else. that is some neat shit.
22:59:05  <rphillips>I'll try that out
22:59:07  <rphillips>Thanks
23:00:23  * dan336quit (Quit: Leaving.)
23:05:19  * kazuponjoined
23:10:37  * kazuponquit (Ping timeout: 255 seconds)
23:32:48  <fdagostino>someone has this issue building luajit:
23:33:00  <fdagostino> CC lj_ir.o
23:33:00  <fdagostino> lj_ir.c:53: error: 'exp2' undeclared here (not in a function)
23:33:00  <fdagostino> lj_ir.c:53: error: 'log2' undeclared here (not in a function)