00:02:28  * dan336quit (Quit: Leaving.)
01:11:05  * cledevjoined
01:51:25  * kazuponjoined
02:03:52  * cledevquit (Ping timeout: 240 seconds)
03:05:35  * travis-cijoined
03:05:35  <travis-ci>luvit/luvit#1157 (luvi-up - 2c30ee3 : Ryan Phillips): The build has errored.
03:05:35  <travis-ci>Change view : https://github.com/luvit/luvit/compare/fffd678d23b9...2c30ee31b755
03:05:35  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/40959305
03:05:35  * travis-cipart
03:08:28  <rphillips>creationix: https://gist.github.com/rphillips/e0a3258e8e37f6357acf
03:09:04  <rphillips>this would be slick to have in luvi, but it will need zip creation support
03:09:23  <creationix>rphillips: zip creation isn’t too bad, I can write it tomorrow if you wish
03:09:36  * travis-cijoined
03:09:37  <travis-ci>luvit/luvit#1157 (luvi-up - 2c30ee3 : Ryan Phillips): The build passed.
03:09:37  <travis-ci>Change view : https://github.com/luvit/luvit/compare/fffd678d23b9...2c30ee31b755
03:09:37  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/40959305
03:09:37  * travis-cipart
03:10:03  <rphillips>creationix: that would rock
03:10:14  <creationix>it’s something I’ve been wanting to add
03:11:41  <rphillips>i would like a brain dump about the coroutine stuff
03:15:37  <creationix>brain dump?
03:15:47  <creationix>do you have questions?
03:16:05  <rphillips>yeah, I don't get the chain logic yet
03:16:14  <creationix>ahh, the protocol parsers
03:16:22  <creationix>yeah, that took me a couple days to wrap my head around
03:17:06  <creationix>I’d love some feedback on the chain syntax too. I’m not settled on how it works
03:17:20  <creationix>but the basic idea is that each segment in a chain runs as an independent coroutine
03:17:29  <creationix>it can read from it’s source and write to it’s destination
03:17:34  <creationix>both read and write are blocking
03:18:14  <creationix>since lua is single threaded, only one of the coroutines will run at a time, most will be blocked on reading or writing most of the time
03:18:38  <creationix>chain basically takes a list of workers and moves data between them
03:19:08  <creationix>suppose I have workers 1, 2, and 3. 1’s read is the real external read, say from a tcp socket, 3’s write is also to the tcp socket
03:19:49  <creationix>when 1 writes, it will check if 2 is waiting for the data, if it is, it will resume 2 passing the data along. Then 1 will be blocked till 2 yields
03:20:04  <creationix>if 1 writes and 2 isn’t waiting to read yet, then 1 will yield and wait for a reader
03:20:24  <creationix>when 2 reads, if there is no data waiting in 1, it will yield
03:21:36  <rphillips>it could potentially deadlock, right?
03:21:41  <creationix>if there is data, 2 will take the data from the box, resume 1 (and wait for 1 to yield again) and then return
03:22:15  <creationix>deadlock isn’t too likely here
03:22:21  <creationix>that last case was https://github.com/luvit/luvit/blob/luvi-up/app/modules/codec.lua#L100-L105
03:22:26  <creationix>I had to look it up
03:22:48  <creationix>resume is always a non-blocking operation
03:23:05  <creationix>so when 2 resumes 1 after taking the data from 1’s box, it will return soon
03:23:21  <creationix>most of the time, 1 will loop around and read from it’s source causing it to yield
03:24:55  <creationix>since each segment is it’s own coroutine and only one can run at a time, blocking in one coroutine is what enables the others to continue
03:26:19  <creationix>typically all the segments are waiting on read (except in the base of backpressure)
03:27:14  <creationix>so 1 gets data, writes to 2 who is waiting, who writes to 3 who is waiting, who writes to the socket, the kernel buffer has room, 3 then blocks on read, returns to 2 who loops back and blocks on read, returns and 1 loops back to blocking on read from the tcp socket
03:27:42  <creationix>if there is backpressure, they tend to all get blocked on writing
03:28:12  <creationix>I use nil to signal end of stream
03:28:13  <rphillips>so a chain from 1,2,3, will potentially run in the same tick
03:28:30  <creationix>right, if the codecs are purely CPU transforms (like http and tls)
03:28:30  <rphillips>but if one is waiting then it pauses
03:29:14  <creationix>so most codec loops look like `for item in read() do write(item) end ; write()`
03:29:21  <creationix>with some extra logic in the middle
03:29:39  <creationix>for..in will exit when read returns nil, and the final write will forward the nil
03:31:48  <rphillips>that helps a lot
03:32:35  <creationix>I was worried about performance, that’s why a benchmark was the first thing I did
03:32:51  <creationix>but I get around 100k/sec with 3 workers + the wrapped tcp socket
03:33:05  <rphillips>http?
03:33:09  <creationix>the 3 workers are httpServerDecode, app, and httpServerEncode
03:33:14  <creationix>with tls it’s 5
03:33:28  <creationix>tls-decode, http-decode, app, http-encode, tls-encode
03:33:54  <creationix>the tls encode and decode pair need to be made together sinde handshake bypasses the inner layers
03:34:08  <creationix>that why it returned a function instead of just exporting encode/decode
03:34:57  <creationix>the tls code came out really elegant with handshake being one loop https://github.com/luvit/luvit/blob/tls-codec/app/modules/codecs/tls.lua#L40-L53
03:35:00  * kazuponquit (Remote host closed the connection)
03:35:17  <creationix>and then two simple workers to feed the data through the ssl context
03:36:23  <creationix>I don’t assume which of tls.encoder or tls.decoder get called first, so I just yield the first, and then handshake in the second
03:36:44  <creationix>in this case it’s encoder that gets started first since that’s the order in chain
03:36:48  <creationix>*decoder
03:37:09  <creationix>https://github.com/luvit/luvit/blob/tls-codec/tests/test-tls-codec.lua#L52
03:48:32  <rphillips>that is slick
03:51:48  <rphillips>chain(resolver.decode, app, resolver.encode)
03:52:03  <rphillips>is that correct?
03:52:53  <creationix>chain returns a function that takes read and write
03:53:06  <creationix>wrapStream creates a blocking read,write pair from a uv_stream_t
03:53:25  <creationix>this is the part I’m considering changing, chain is kinda strange
03:54:41  <creationix>we could make a chaining API
03:55:08  <creationix>wrap(socket):add(tls):add(http):run(app)
03:55:25  <creationix>and add would assume the thing to the left was upstream and .decode from it and .encode on the way out
03:56:14  <creationix>conceptually though, chain is much simpler
03:56:29  <creationix>it takes several (read,write) workers and creates a new composite worker
03:56:43  <creationix>worker concatenation
03:57:48  <creationix>and with chain, I suppose you could work wither direction
03:58:31  <creationix>we would just need a version of wrapStream that accepted read,write instead of producing it
03:58:51  <creationix>and the app would need to produce those instead of accepting them
03:59:00  <creationix>hmm, that seems backwards, probably not a good idea
04:01:02  <creationix>chain(http.encode, wrapSocket(socket), http.decode)(app())
04:03:56  * travis-cijoined
04:03:56  <travis-ci>luvit/luvit#1158 (luvi-up - 5bb5137 : Tim Caswell): The build passed.
04:03:56  <travis-ci>Change view : https://github.com/luvit/luvit/compare/2c30ee31b755...5bb5137f029a
04:03:56  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/40962281
04:03:56  * travis-cipart
04:25:45  * kazuponjoined
04:48:16  * ra_joined
04:50:17  * ra^^quit (Ping timeout: 240 seconds)
06:46:37  * kazuponquit (Remote host closed the connection)
07:01:27  * kazuponjoined
08:12:09  * torporjoined
08:19:12  * torporquit (Read error: Connection reset by peer)
08:28:55  * torporjoined
08:29:55  * torporquit (Read error: Connection reset by peer)
08:31:55  * torporjoined
08:44:31  * kazuponquit (Remote host closed the connection)
08:45:52  * kazuponjoined
09:19:10  * ra__joined
09:22:17  * ra_quit (Ping timeout: 240 seconds)
09:38:47  * kazuponquit (Remote host closed the connection)
09:43:47  * kazuponjoined
10:03:00  * torpor1joined
10:03:01  * torporquit (Read error: Connection reset by peer)
10:11:43  * kazuponquit (Remote host closed the connection)
10:12:24  * kazuponjoined
10:44:59  * kazuponquit (Remote host closed the connection)
10:45:44  * kazuponjoined
10:45:55  * kazuponquit (Remote host closed the connection)
10:46:03  * kazuponjoined
11:00:29  * torpor1changed nick to torpor
11:05:10  * kazuponquit (Remote host closed the connection)
12:16:02  * kazuponjoined
12:20:45  * kazuponquit (Ping timeout: 272 seconds)
13:27:15  * kazuponjoined
13:40:22  * torporquit (Quit: Leaving.)
14:02:52  * kazuponquit
14:04:11  * kazuponjoined
14:16:58  * torporjoined
14:23:24  * torporquit (Quit: Leaving.)
14:33:35  <rphillips>we need to get the ca certs into the new luvit
14:41:01  * kazuponquit (Remote host closed the connection)
14:42:23  * kazuponjoined
14:43:48  * torporjoined
14:46:39  * torporquit (Client Quit)
14:51:36  * torporjoined
14:56:25  * kazuponquit (Remote host closed the connection)
15:11:43  <creationix>rphillips: mornin'
15:11:49  <rphillips>morning
15:12:12  <creationix>shall I dig into zip writing in luvi or did you still need help understanding the codec stuff?
15:16:11  <rphillips>zip writing in luvi would be sweet
15:16:24  <rphillips>i've got a good handle on the codec stuff now
15:23:37  * tjcraveyjoined
15:24:09  * torpor1joined
15:24:26  * torporquit (Read error: No route to host)
15:26:15  * dan336joined
15:40:13  <rphillips>3 seconds for unit tests... luvit
15:42:02  <tjcravey>the link on luvit.io for prebuilt binaries links to a page that only has the source tarball
15:53:10  <creationix>tjcravey: yep, looks like we never made binaries for that version. It’s a manual process
15:53:22  <creationix>but the good news is the new luvi version of luvit in progress is much easier to build
15:54:31  <tjcravey>Okay, cool. Thanks!
15:55:33  <creationix>tjcravey: btw, are you just starting with luvit?
15:55:43  <creationix>the new luvi version is super cool if you want to test it out for me
15:55:57  <tjcravey>Yeah, brand new, only heard of it yesterday
15:56:04  <creationix>you don’t need a C compiler to build the new version
15:56:08  <creationix>what platform are you on?
15:56:14  <tjcravey>OS X Yosemite
15:57:15  <creationix>git clone [email protected]:luvit/luvit.git --recursive --branch luvi-up
15:57:33  <creationix>that command will grab the new luvit branch which has the binaries in a submodule
15:57:45  <creationix>make will zip the luvit source with the luvi binary to create a new binary
15:57:54  <creationix>assuming you have zip on your machine
15:58:08  <creationix>if not, I’m adding zip nativly to luvit today
15:59:22  <tjcravey>Yeah, looks like I do have zip, so that should be good
16:00:31  <creationix>the legacy luvit required a c compiler and python 2, which is a pain on many systems
16:00:42  <creationix>many linuxes have python 3 and windows C compilers are hard to setup
16:03:13  <creationix>tjcravey: though the new version of luvit isn’t quite done yet, so the examples on luvit.io probably won’t work
16:03:20  <creationix>but I can help you if you want
16:03:48  <tjcravey>awesome, sounds good
16:18:44  <tjcravey>that seems to have worked perfectly
16:19:19  <creationix>:)
16:19:21  <tjcravey>git clone, cd in to the luvit directory, ran make, and then ./luvit, and now I'm looking at Welcome to the Luvit repl!
16:20:01  <creationix>and if you `make test` outside the repl, it should run the unit tests
16:20:11  <creationix>takes a couple seconds. I expect them work, I test on yoesmite daily
16:20:25  <tjcravey># All tests passed
16:20:27  <tjcravey>:)
16:20:49  <creationix>All the primitives are complete, but in the “uv” module
16:20:52  <creationix>with the libuv API
16:21:02  <creationix>the node.js style APIs are still in progress
16:21:32  <creationix>the “bench” folder and the “tests” folder are up-to-date
16:21:47  <creationix>the “examples” folder is for legacy luvit and most of them probably don’t work
16:21:55  <creationix>yet
16:23:22  <tjcravey>that's cool, this gives me something to play with
16:23:54  <tjcravey>Just trying to get a feel for the language at this point
16:24:01  <creationix>also most the examples in https://github.com/luvit/luv/tree/master/examples should work
16:24:10  <creationix>just use “uv” instead of “luv” to require the libuv api
16:24:27  <creationix>luvit has a more node.js style require system while luv examples are raw lua requires
16:27:37  <tjcravey>cool, thanks for your help!
16:28:24  <creationix>enjoy
16:47:34  <creationix>Adding deflate to luvi seems to add about 100k to the binary since I’m switching to full miniz instead of just tinfl
16:48:06  * aliemjoined
16:48:17  * aliempart
16:49:20  <rphillips>https://github.com/luvit/luvit/pull/532
16:50:48  <creationix>I think if I prefix all of miniz’s public functions with static it will shrink the binary a bit
16:50:57  <creationix>I include it in luvit’s bindings by including the C file
16:53:49  * travis-cijoined
16:53:49  <travis-ci>luvit/luvit#1159 (fixes/fix-fs-example - c07fe18 : Ryan Phillips): The build passed.
16:53:49  <travis-ci>Change view : https://github.com/luvit/luvit/commit/c07fe189a8a6
16:53:49  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/41017559
16:53:49  * travis-cipart
16:57:33  <rphillips>fixed that pr up
16:59:26  * travis-cijoined
16:59:27  <travis-ci>luvit/luvit#1161 (fixes/fix-fs-example - db67fe4 : Ryan Phillips): The build passed.
16:59:27  <travis-ci>Change view : https://github.com/luvit/luvit/compare/c07fe189a8a6...db67fe449145
16:59:27  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/41018325
16:59:27  * travis-cipart
17:08:33  * travis-cijoined
17:08:33  <travis-ci>luvit/luvit#1165 (exit-code - 3e2b93e : Ryan Phillips): The build passed.
17:08:33  <travis-ci>Change view : https://github.com/luvit/luvit/commit/3e2b93e19162
17:08:33  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/41019235
17:08:33  * travis-cipart
17:08:55  <rphillips>I have a good feeling luvit2 is going to cause the agent to go down in memory usage
17:09:16  <rphillips>we might be < 4 MB
17:09:59  <creationix>if there a way to tell gcc to treat all functions as static?
17:10:19  <creationix>I don’t want to try and find all functions in the 5000 lines of minix and prefix them with static
17:10:39  <creationix>but the unused functions are causing ~150kb bloat
17:10:51  <rphillips>-finline-functions perhaps
17:11:11  <rphillips>https://gcc.gnu.org/onlinedocs/gcc-3.4.6/gcc/Optimize-Options.html
17:11:19  <rphillips>-fkeep-inline-functions
17:14:26  <creationix>doesn’t seem to make much difference
17:14:37  <creationix>-fvisibility=hidden didn’t help either
17:15:48  <creationix>I guess it’s OK for now, but some time, we should try to optimize the build
17:16:34  <creationix>rphillips: so you think fs.write should keep the old API that matches node?
17:16:53  <creationix>I hate it that node and libuv have different orders here, but there isn’t much we can do about it
17:16:55  <rphillips>well... i dont have hard feelings about
17:16:56  <rphillips>it
17:17:07  <rphillips>i was thinking about legacy code
17:17:34  <creationix>right, we want migration to be easier
17:17:52  <creationix>some people told me they like it when luvit matches node
17:18:00  <creationix>since they are porting node code over
17:18:15  <creationix>so it’s not just virgo that likes the node style
17:30:36  <creationix>I hope luvit can run on boxed this small http://www.amazon.com/TP-LINK-TL-WR702N-Wireless-Repeater-150Mpbs/dp/B007PTCFFW/ref=sr_1_1
17:30:56  <creationix>they are about $10 each in china
17:31:10  <creationix>commonly used for robot brains by hacker groups
17:31:59  <rphillips>slick
17:32:55  <creationix>they have between 2 and 16mb of ram depending on the version
17:33:10  <creationix>they can run busybox linux and normal lua I know
17:42:37  * ra__quit (Ping timeout: 240 seconds)
18:07:56  <creationix>I’m so tempted to port js-git to luvit
18:08:06  <creationix>especially now that inflate and deflate are in luvi
18:13:50  * ra^^joined
18:14:36  <rch>i find myself wishing tedit/js-git were completely feature complete so i could use it / hack on it for stuff
18:14:40  <rch>pretty often these days
18:16:19  <creationix>I need to finish brozula so lua code can run in tedit
18:16:30  <creationix>that or implement some sort of proxy to allow it to shell out
19:04:37  * travis-cijoined
19:04:37  <travis-ci>luvit/luvit#1167 (luvi-up - 2ec94af : Ryan Phillips): The build passed.
19:04:37  <travis-ci>Change view : https://github.com/luvit/luvit/compare/5bb5137f029a...2ec94af34073
19:04:37  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/41030039
19:04:37  * travis-cipart
19:09:45  <rphillips>nginx in luvi... yes please
19:13:33  <creationix>nginx in luvi?
19:15:43  <rphillips>it would be neat to have an entire replacement in luvi
19:38:17  <creationix>you know, if we’re writing the zip and unzip code for luvi, there is no reason to use actual zip format
19:39:13  <creationix>rphillips: what do you think about using a simpler format that’s not compat with zip?
19:39:18  <rphillips>creationix: wdyt of this? https://github.com/luvit/luvit/compare/add-luvit-module
19:39:34  <rphillips>creationix: zip format is nice
19:39:57  <rphillips>we could get the zip file from the binary as well.
19:40:05  * travis-cijoined
19:40:05  <travis-ci>luvit/luvit#1170 (add-luvit-module - c7ec843 : Ryan Phillips): The build failed.
19:40:05  <travis-ci>Change view : https://github.com/luvit/luvit/commit/c7ec8434cbef
19:40:05  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/41033500
19:40:05  * travis-cipart
19:40:55  <creationix>so the “luvit” module creates the luvit style globals?
19:41:01  <rphillips>right
19:41:17  <rphillips>so we don't have to copy and paste into virgo or other projects
19:42:15  <creationix>shouldn’t the _G.require part go there to?
19:42:43  <creationix>though I guess that then creates a bit of a bootstrap problem
19:42:51  <creationix>you can’t just require ”luvit”
19:43:03  <creationix>it would be bundle:/modules/luvit.lua or something
19:43:18  <creationix>no that wouldn’t work either
19:43:35  <creationix>you’d need to register it using bundle.register
19:44:42  <creationix>I like it, +1
19:45:37  <creationix>and we could maybe add some of the command-line parsing and/or repl code there too and just call it from main
19:46:06  <creationix>though we can just move things over on an as-needed basis
19:47:24  <creationix>this bit could go into luvit as a argument parser library https://github.com/luvit/luvit/blob/c7ec8434cbefb6df9ec015880859669c8a2562c5/app/main.lua#L71-L91
19:47:34  * cledevjoined
19:47:41  <creationix>I mean this part https://github.com/luvit/luvit/blob/c7ec8434cbefb6df9ec015880859669c8a2562c5/app/main.lua#L93-L113
20:05:09  <rphillips>creationix: +1 ? https://github.com/luvit/luvit/pull/533
20:05:32  <creationix>yep
20:05:47  <rphillips>i pull this, and the init PR should work
20:06:11  <creationix>cool
20:07:26  * travis-cijoined
20:07:27  <travis-ci>luvit/luvit#1172 (luvi-up - 52a5159 : Ryan Phillips): The build passed.
20:07:27  <travis-ci>Change view : https://github.com/luvit/luvit/compare/2ec94af34073...52a51590a6ff
20:07:27  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/41036081
20:07:27  * travis-cipart
20:09:45  * travis-cijoined
20:09:46  <travis-ci>luvit/luvit#1173 (add-luvit-module - 697cea2 : Ryan Phillips): The build was fixed.
20:09:46  <travis-ci>Change view : https://github.com/luvit/luvit/compare/c7ec8434cbef...697cea2caad9
20:09:46  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/41036161
20:09:46  * travis-cipart
20:13:11  * travis-cijoined
20:13:11  <travis-ci>luvit/luvi#98 (zip - 728c7c3 : Tim Caswell): The build has errored.
20:13:11  <travis-ci>Change view : https://github.com/luvit/luvi/compare/16a78b173101^...728c7c3af800
20:13:11  <travis-ci>Build details : http://travis-ci.org/luvit/luvi/builds/41036364
20:13:11  * travis-cipart
20:16:21  * travis-cijoined
20:16:21  <travis-ci>luvit/luvi#99 (zip - 395326c : Tim Caswell): The build passed.
20:16:21  <travis-ci>Change view : https://github.com/luvit/luvi/compare/728c7c3af800...395326c6c1f3
20:16:21  <travis-ci>Build details : http://travis-ci.org/luvit/luvi/builds/41036520
20:16:21  * travis-cipart
20:18:08  * torpor1part
20:18:40  <creationix>rphillips: so for luvi zipping, it’s enough to just pass in a list of files and contents and return the zip as a string?
20:19:26  <rphillips>hmm. we should support directories, and individual files
20:19:28  <creationix>I could also do it as an emitting stream where as you feed it files, it emits data
20:20:53  <rphillips>contrib/zip.py ${LUVI_ZIP} deps/luvit-up/app app
20:20:53  * typedlambdajoined
20:20:59  <rphillips>this is what I started to do in virgo-base
20:21:34  <rphillips>in virgo currently we have a bundle.list
20:21:51  <rphillips>https://github.com/virgo-agent-toolkit/rackspace-monitoring-agent/blob/master/bundle.list
20:22:15  <creationix>that’s handy
20:22:55  <creationix>my quesion is, do we need a streaming interface at the low level or just a buffering interface that accepts a completed list of files/folders and returns a string?
20:22:59  <rphillips>with luvit... we will need the luvit modules as well in the right spot
20:23:36  <rphillips>we might want to support a --prefix and perhaps --trim option to the internal zip location
20:26:15  <rphillips>+1? https://github.com/luvit/luvit/pull/534
20:28:18  <creationix>where does it call luvit.run()
20:29:11  <creationix>the unit tests have their own uv.run and wouldn’t notice if it was missing
20:46:48  <rch>instead of bundle list i would love to have something that traverses the dependency tree and bundles like browserify
20:47:01  <rch>so we don't need to maintain manually, so we don't include unneeded files, and we don't miss needed ones
20:47:14  <rch>i tried to make it but needed a lua parser in lua x.x
20:59:41  <rphillips>rch: https://gist.github.com/rphillips/e0a3258e8e37f6357acf
20:59:46  <rphillips>this is the idea i had yesterday
20:59:53  <rphillips>just use lua to parse
21:00:17  <rch>hrm don't think i understand
21:01:25  <rphillips>i didn't quite understand the lua parser comment...
21:01:46  <rphillips>that was my idea yesterday on packaging the scripts
21:02:26  * travis-cijoined
21:02:26  <travis-ci>luvit/luvit#1175 (add-luvit-module - 1d2e571 : Ryan Phillips): The build passed.
21:02:26  <travis-ci>Change view : https://github.com/luvit/luvit/compare/697cea2caad9...1d2e57106482
21:02:26  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/41041332
21:02:26  * travis-cipart
21:03:03  <creationix>you don’t need a full lua parser
21:03:04  <rch>heh
21:03:12  <creationix>in js, I just wrote a simple state machine to scan for requires
21:03:41  <creationix>https://github.com/creationix/mine
21:03:49  <rch>https://github.com/robert-chiniquy/node-luvit-deps/blob/master/index.js#L49
21:03:51  <rch>oh nice
21:04:06  <rch>creationix: ^ right so we'd want that but in lua
21:04:09  <rch>your state machine is very short
21:04:24  <creationix>just implement enough state machine to ignore strings and comments and it’s pretty easy to find require calls
21:05:00  <rch>rphillips: ^ yeah so that's basically what i was thinking
21:05:24  <rch>generate a transitory bundle list every build based on the modules required from the entry point
21:06:08  <creationix>Instead of generating a static list, I’d write a module who’s sole job is to find the list dynamically
21:06:13  <creationix>then just eval that file to get the list
21:06:20  <rch>cool
21:06:34  <creationix>I guess that’s what you meant by transitory
21:07:36  <rch>yup
21:08:58  <rch>i was going to use https://github.com/virgo-agent-toolkit/luvit-resolve
21:55:05  * travis-cijoined
21:55:06  <travis-ci>luvit/luv#161 (fixes/project - e697e81 : Ryan Phillips): The build failed.
21:55:06  <travis-ci>Change view : https://github.com/luvit/luv/commit/e697e8197936
21:55:06  <travis-ci>Build details : http://travis-ci.org/luvit/luv/builds/41046301
21:55:06  * travis-cipart
21:56:42  * travis-cijoined
21:56:42  <travis-ci>luvit/luv#163 (master - a80bd12 : Ryan Phillips): The build was broken.
21:56:42  <travis-ci>Change view : https://github.com/luvit/luv/compare/46390a04c030...a80bd127fd7f
21:56:42  <travis-ci>Build details : http://travis-ci.org/luvit/luv/builds/41046414
21:56:42  * travis-cipart
21:57:14  * travis-cijoined
21:57:15  <travis-ci>luvit/luvi#100 (master - 09aca94 : Ryan Phillips): The build passed.
21:57:15  <travis-ci>Change view : https://github.com/luvit/luvi/compare/16d7a246a44a...09aca94dff84
21:57:15  <travis-ci>Build details : http://travis-ci.org/luvit/luvi/builds/41046400
21:57:15  * travis-cipart
21:57:51  <rphillips>reverted...
21:57:55  <rphillips>something there is the issue
21:58:01  <rphillips>with the project() declarations
21:58:18  <rphillips>worked perfect on windows.
21:59:35  <rphillips>https://github.com/luvit/luvi/pull/25
21:59:36  <rphillips>testing
22:00:51  * travis-cijoined
22:00:51  <travis-ci>luvit/luvi#101 (master - 3f5b83a : Ryan Phillips): The build passed.
22:00:51  <travis-ci>Change view : https://github.com/luvit/luvi/compare/09aca94dff84...3f5b83a945fb
22:00:51  <travis-ci>Build details : http://travis-ci.org/luvit/luvi/builds/41046995
22:00:51  * travis-cipart
22:03:48  <rphillips>yep. the top level project needs project() and is used first
22:03:53  <rphillips>http://www.cmake.org/cmake/help/v3.0/command/project.html
22:05:14  * travis-cijoined
22:05:15  <travis-ci>luvit/luvi#102 (fixes/project - 63ac770 : Ryan Phillips): The build passed.
22:05:15  <travis-ci>Change view : https://github.com/luvit/luvi/commit/63ac7708878a
22:05:15  <travis-ci>Build details : http://travis-ci.org/luvit/luvi/builds/41047218
22:05:15  * travis-cipart
22:11:11  * travis-cijoined
22:11:12  <travis-ci>luvit/luvi#104 (master - 94370d6 : Ryan Phillips): The build passed.
22:11:12  <travis-ci>Change view : https://github.com/luvit/luvi/compare/3f5b83a945fb...94370d6fd079
22:11:12  <travis-ci>Build details : http://travis-ci.org/luvit/luvi/builds/41047854
22:11:12  * travis-cipart
22:20:48  * travis-cijoined
22:20:48  <travis-ci>luvit/luvi#105 (master - 5e7df22 : Ryan Phillips): The build passed.
22:20:48  <travis-ci>Change view : https://github.com/luvit/luvi/compare/94370d6fd079...5e7df223faf3
22:20:48  <travis-ci>Build details : http://travis-ci.org/luvit/luvi/builds/41048584
22:20:48  * travis-cipart
22:42:10  * mattlgyjoined
22:46:37  <mattlgy>Noob question: For `http.request`, what will be in `data` in `res:on("data", function (data)`? Will that be a Node-y style stream or can I rely on that being the full http response's body?
22:53:28  <creationix>probably node style packets
22:53:41  <creationix>rphillips: dinner time. I pushed what I’ve got for zip encoding
22:53:44  <creationix>it almost works
22:54:00  <creationix>though miniz does have zip code inside it, we could perhaps just bind to that instead of implementing it in lua
22:54:08  <creationix>my main issue is it uses it’s own file I/O
22:54:24  <creationix>I’d rather virtualize that
22:54:54  <rphillips>gotcha
22:55:50  <rphillips>https://github.com/luvit/luvi/pull/26
22:56:36  <rphillips>hmm. didn't quite work
22:58:06  * 7F1ABV4OMjoined
22:58:07  <7F1ABV4OM>luvit/luvi#106 (zip - d528fff : Tim Caswell): The build passed.
22:58:07  <7F1ABV4OM>Change view : https://github.com/luvit/luvi/compare/395326c6c1f3...d528fffe5edd
22:58:07  <7F1ABV4OM>Build details : http://travis-ci.org/luvit/luvi/builds/41051741
22:58:07  * 7F1ABV4OMpart
22:58:30  * tjcraveyquit (Quit: Textual IRC Client: www.textualapp.com)
22:58:43  * travis-cijoined
22:58:43  <travis-ci>luvit/luvi#107 (fixes/parallel_build - 6dea3aa : Ryan Phillips): The build failed.
22:58:43  <travis-ci>Change view : https://github.com/luvit/luvi/commit/6dea3aaf94d0
22:58:43  <travis-ci>Build details : http://travis-ci.org/luvit/luvi/builds/41051882
22:58:43  * travis-cipart
23:01:40  * travis-cijoined
23:01:40  <travis-ci>luvit/luvi#109 (fixes/parallel_build - 392c988 : Ryan Phillips): The build passed.
23:01:40  <travis-ci>Change view : https://github.com/luvit/luvi/compare/6dea3aaf94d0...392c9887b70e
23:01:40  <travis-ci>Build details : http://travis-ci.org/luvit/luvi/builds/41052194
23:01:40  * travis-cipart
23:02:28  <rphillips>travis build machines have 32 virtual processes... man
23:02:33  <rphillips>precessors*
23:03:58  <rphillips>the 'large' build (with openssl) went from 2 minute 40 seconds to 1 minute 14 seconds
23:04:38  <rphillips>looks like it depends though
23:08:30  * travis-cijoined
23:08:30  <travis-ci>luvit/luvi#109 (fixes/parallel_build - 392c988 : Ryan Phillips): The build passed.
23:08:30  <travis-ci>Change view : https://github.com/luvit/luvi/compare/6dea3aaf94d0...392c9887b70e
23:08:30  <travis-ci>Build details : http://travis-ci.org/luvit/luvi/builds/41052194
23:08:30  * travis-cipart
23:10:40  <rphillips>ninja is supported by cmake
23:10:47  <rphillips>-Gninja to the cmake options
23:10:53  <rphillips>then ninja from the commandline
23:10:59  <rphillips>luvi builds w/ openssl in 24 seconds
23:16:17  * mattlgyquit (Remote host closed the connection)
23:17:53  * travis-cijoined
23:17:54  <travis-ci>luvit/luvi#111 (master - f505bae : Ryan Phillips): The build passed.
23:17:54  <travis-ci>Change view : https://github.com/luvit/luvi/compare/5e7df223faf3...f505bae597ef
23:17:54  <travis-ci>Build details : http://travis-ci.org/luvit/luvi/builds/41053447
23:17:54  * travis-cipart
23:29:05  * travis-cijoined
23:29:05  <travis-ci>luvit/luvi#112 (fixes/add_generator_support - fa0f070 : Ryan Phillips): The build passed.
23:29:05  <travis-ci>Change view : https://github.com/luvit/luvi/commit/fa0f070b7c86
23:29:05  <travis-ci>Build details : http://travis-ci.org/luvit/luvi/builds/41054326
23:29:05  * travis-cipart
23:30:41  <rphillips>https://github.com/luvit/luvi/pull/27
23:30:44  <rphillips>dinner