00:03:18  * dan336joined
00:15:00  * DarkGodquit (Ping timeout: 258 seconds)
00:16:37  * dan336quit (Quit: Leaving.)
01:06:05  <rphillips>creationix: sweet. I'll review that patch in the morning
01:18:25  * kazuponjoined
02:17:57  * kazuponquit (Remote host closed the connection)
02:25:40  * dan336joined
02:28:25  * a_lequit (Read error: Connection reset by peer)
02:28:49  * a_lejoined
02:29:07  * a_lequit (Remote host closed the connection)
03:03:24  * kazuponjoined
03:07:35  * kazuponquit (Ping timeout: 244 seconds)
04:05:41  * dan336quit (Quit: Leaving.)
04:13:12  * hdmsquit (Quit: hdms)
04:38:25  * merpnderpjoined
04:38:37  * merpnderppart
06:19:02  * a_lejoined
06:29:41  * SkyRocknRolljoined
07:39:29  * DarkGodjoined
08:14:09  * a_lequit (Remote host closed the connection)
11:10:40  * hdmsjoined
12:01:15  * ldubjoined
13:16:08  * SkyRocknRollquit (Remote host closed the connection)
14:01:53  <rphillips>good morning
14:08:52  * DarkGodquit (Remote host closed the connection)
14:23:55  * DarkGodjoined
14:44:48  * dan336joined
15:05:31  * kazuponjoined
15:05:39  * KennethWilkejoined
15:20:57  <creationix>rphillips: mornin
15:21:05  <rphillips>hiya!
15:24:59  <KennethWilke>g'morning
15:25:25  <KennethWilke>i haven't popped in here in a long while, hope things are goin' well for y'all
15:26:56  * SkyRocknRolljoined
15:29:26  * a_lejoined
15:31:23  * hdms_joined
15:32:00  * hdmsquit (Ping timeout: 252 seconds)
15:32:01  * hdms_changed nick to hdms
15:33:27  <creationix>KennethWilke: yep, staying busy
15:34:07  <KennethWilke>that's good stuff, last time i bothered y'all you were working on package manager stuff, has that gone well?
15:35:27  <creationix>yep, just finished a pretty big internal refactor to the package manager
15:35:31  <creationix>rphillips: did you see https://github.com/luvit/luvit/issues/741?
15:35:50  <creationix>KennethWilke: you can see what's published at https://luvit.io/lit.html
15:36:02  <creationix>we just hit 100 packages
15:36:33  <rphillips>i thought we did support keep-alive
15:39:00  <KennethWilke>that's pretty great work
15:40:20  <dan336>rphillips: i played with keep alive about a month or two ago and found that the headers were returned correctly, but that the second request over the same socket was never responded to.
15:40:33  <dan336>I don't know if that is still the case though
15:41:28  <dan336>I assumed that it was something that I was doing wrong. otherwise I would have reported it.
15:43:07  * sousouxjoined
15:43:25  <sousoux>anyone at home?
15:44:05  <sousoux>just spotted that luvit http ignores any headers added with addHeader
15:44:41  <sousoux>setHeader
15:52:32  <creationix>sousoux: can you write a simple test case to reproduce it?
15:52:37  <creationix>sounds like it should b easy
15:55:20  <sousoux>no - I think I'm talking rubbish
15:55:48  <sousoux>still a pita porting from 0.83 to 2.0
15:56:09  <sousoux>I'm close to the end but continuously tripped up
15:57:10  <sousoux>hold on. I was looking at the luvit 0.83 version when I thought I was wrong
15:57:38  <sousoux>I will be able to reproduce but better I can fix
15:58:22  <sousoux>It is pretty clear - ServerResponse:writeHead only looks at headers passed to it
16:01:11  <sousoux>It is not however clear even from the nodejs docs what the effect of calling setHeader several times on the same header is. I guess that would reset the header. And then if you pass headers in writeHead should that overwrite those or be added.
16:06:09  * KennethWilkequit (Remote host closed the connection)
16:06:35  <sousoux>no keep alive logic either
16:10:33  <sousoux>ok. I get it. I was not aware of the implicit headers behaviour in nodejs and luvit behaved differently before
16:18:57  * ldubquit (Ping timeout: 252 seconds)
16:20:37  <sousoux>one other thing. at present doing a package search with lit when a lit proxy is connected (has an up) systematically causes the meta data on the up server to be searched. Logical since you can't know if a package has not been synced. However if I do know would it be interesting for you to have an option that allows you to indicate that you do not want uplink package data to be searched?
16:20:58  <sousoux>If not I'll just put it in my own version
16:21:28  <sousoux>Makes searches via a proxy rather slow
16:23:05  <creationix>sousoux: cool, you're running a local lit server. I thought I was the only one who did that
16:23:14  <creationix>and yes, I've noticed that having an active upstream makes search really slow
16:23:35  <creationix>as a workaround, you can `lit down` before search, but I can see how that's not always an option
16:23:45  <creationix>what's your use case? I'll fix it for you
16:25:18  <creationix>The problem is that db.match will always include the upstream if there is one when searching for a match.
16:25:37  <creationix>This is the desired behavior for the lit client since you almost never want to search only your local cache
16:25:50  <creationix>It's less clear for a lit proxy
16:26:40  <creationix>Also searching in a proxy doesn't even include all search results from the upstream last I checked. It's slower, but doesn't actually benefit from it.
16:27:04  <creationix>Ideally we'd have local search and search including upstream right?
16:33:59  * a_lequit (Remote host closed the connection)
16:40:56  * a_lejoined
16:42:18  <sousoux>yes we now have a lit server running
16:43:26  <sousoux>my use cse is that I have certain packages that I want to stay on our server since they are very specific to the application but they may have dependencies that need to be downloaded from yours
16:44:07  <sousoux>at present I'm using a tag to 'categorize' the packages
16:45:27  <creationix>rphillips: currently lit is MIT licensed to me. Does it need to match luvit's license?
16:45:27  <sousoux>that is not really ideal. I had the idea of having a piece of meta data that indicates that the package should stay at that server but that still doesn't solve the search problem.
16:46:10  <rphillips>creationix: hmm. i sorta think so... it's all in the same org
16:46:19  <sousoux>only thing I could think of is custom url for local queries or a header (yuck)
16:46:41  <creationix>sousoux: there is the "private" field in packages. Maybe instead of being a boolean that prevents publishing, it could be an url to the upstream you're allowed to publish to?
16:47:02  <sousoux>yes. that would work
16:47:30  <creationix>If someone publishes to a proxy, should it forward non-private packages to it's upstream?
16:47:48  <creationix>right now, you have to manually change your upstream to wss://lit.luvit.io if you want to publish there
16:48:01  <sousoux>well I would obviously prefer not in my case
16:48:27  <creationix>right, for your private code, you want it local, but what if you also maintain some open source modules?
16:48:37  <sousoux>I think it is fine if sync is only down and publish is explicit
16:49:00  <sousoux>then at least you can predict the outcome.
16:49:09  <creationix>I wonder if you could configure an upstream as being private safe?
16:49:29  <creationix>or have two upstreams? One for cache and private publishing and one for public stuff
16:52:36  * ldubjoined
16:55:25  * SkyRocknRollquit (Remote host closed the connection)
16:55:35  <creationix>rphillips: ok, switched lit itself to apache2 licensed to "The Luvit Authors"
16:55:44  <rphillips>cool
16:56:00  <creationix>the creationix/* dependencies are still MIT under me though. I think it's fine for lit to use third-party dependencies
16:57:12  <creationix>https://github.com/luvit/lit/commit/1e3aa463aa93b2a6b46de086ad262cef952d3fb3
16:57:30  <rphillips>that seems fine
17:01:36  <sousoux>creationix: I can see why in pure proxy mode you would want to have some packages sync upwards
17:02:05  <sousoux>just needs to be very clear what you ask for
17:03:11  <sousoux>one other nice feature for the proxy would be that it can accept meta data that upstream does not necessarily. i.e. you can set custom metadata items in config file
17:03:27  <sousoux>metadata keys I mean
17:18:35  <creationix>custom metadata, interesting
17:18:44  <creationix>currently, the list is hard-coded in the lit client itself
17:24:14  * DarkGodquit (Ping timeout: 265 seconds)
17:25:47  <rje>rphillips, what can i do to help with the stdio patch integration? (ps. didn't you take yesterday off)
17:26:00  <rphillips>rje: i did
17:26:11  <rphillips>rje: if you could help me integrate that into the agent it would help
17:26:36  <rphillips>rje: we may need to do a luvit release to get that patch in
17:26:50  <rje>are you seeing the same issue on linux with php (was it php)?
17:29:06  <sousoux>creationix: I know
17:30:22  <creationix>sousoux: technically you could just patch your local lit client to allow custom metadata and the lit servers would accept it
17:30:30  <creationix>the only thing they verify is the signature matches the owner
17:30:40  <sousoux>the server doesn't validate?
17:30:48  <sousoux>I kind of assumed that it did
17:31:53  <creationix>nope, and the search code is care to not assume much
17:31:57  <creationix>*careful
17:32:02  <rphillips>rje: it was a certain version of ruby
17:32:10  <rphillips>i haven't tested that yet
17:32:19  <rje>gotcha
17:33:53  <creationix>sousoux: so I think multiple upstreams with per-upstream config options will enable the stuff you want
17:34:38  <creationix>you could add custom fields per upstreams, you could allow private packages to some.
17:35:06  <creationix>you could have different default upstreams for publishing public, publishing private, and downloading
17:35:29  <creationix>downloading should probably always be the local proxy if there is one so save bandwidth
17:36:04  <creationix>and maybe restrict search to certain upstreams?
17:37:44  <creationix>or to keep it simple, just have an optional secondary upstream
17:37:54  <creationix>and always use the public upstream for public
17:38:57  <sousoux>just a search that is only local would solve my issue. and the current behaviour of not syncing upstream
17:39:13  <rphillips>rje: i'll bump luvit
17:39:27  <creationix>I think for now search should always be local
17:39:49  <creationix>the fact that is checks remote when matching versions is just a side effect of sharing code with the lit client
17:40:00  <sousoux>or some way of marking a package not to sync upstream if you want to enable that
17:40:47  <creationix>sousoux: currently, it will simply refuse to publish anything with `private = true`
17:41:03  <creationix>but when I add a secondary private/local upstream, it will publish there instead of failing.
17:41:04  <sousoux>the getMeta forces a sync to the upstream I seem to remember (if rdb has 'hooked')
17:41:32  <creationix>db.match is the slow one if I recall
17:42:27  * travis-cijoined
17:42:28  <travis-ci>luvit/luvit#2184 (master - 6d71e13 : Ryan Phillips): The build passed.
17:42:28  <travis-ci>Change view : https://github.com/luvit/luvit/compare/1d92f20d2a49...6d71e1318c89
17:42:28  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/66256081
17:42:28  * travis-cipart
17:43:23  <creationix>sousoux: https://github.com/luvit/lit/issues/86
17:44:22  <creationix>sousoux: so to confirm, you would rather have local-only search in your proxy than have slow results?
17:44:48  <creationix>it will show anything you have cached, but won't show remote updates unless you run `lit sync` on the proxy
17:45:17  * travis-cijoined
17:45:18  <travis-ci>luvit/luvit#2189 (fixes/child_process_errors - c2ba994 : Ryan Phillips): The build has errored.
17:45:18  <travis-ci>Change view : https://github.com/luvit/luvit/compare/fixes/child_process_errors
17:45:18  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/66256325
17:45:18  * travis-cipart
17:45:39  * travis-cijoined
17:45:40  <travis-ci>luvit/luvit#2187 (fixes/stdin_highwater_mark - 9ba7956 : Ryan Phillips): The build has errored.
17:45:40  <travis-ci>Change view : https://github.com/luvit/luvit/compare/fixes/stdin_highwater_mark
17:45:40  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/66256321
17:45:40  * travis-cipart
17:45:50  <rphillips>i pushed all my local branches... :/
17:46:02  <rphillips>i thought --all pushed the tags as well
17:46:11  <rphillips>it doesn't
17:47:01  <creationix>rphillips: nope, git is weird about that one
17:47:06  <creationix>sousoux: https://github.com/luvit/lit/issues/87
17:47:07  * travis-cijoined
17:47:08  <travis-ci>luvit/luvit#2191 (feat/add_lbuffer - 88705af : Ryan Phillips): The build has errored.
17:47:08  <travis-ci>Change view : https://github.com/luvit/luvit/compare/feat/add_lbuffer
17:47:08  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/66256329
17:47:08  * travis-cipart
17:47:30  * travis-cijoined
17:47:31  <travis-ci>luvit/luvit#2194 (http_post_error - 0c84c7e : Rob Emanuele): The build has errored.
17:47:31  <travis-ci>Change view : https://github.com/luvit/luvit/commit/0c84c7e32114
17:47:31  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/66256335
17:47:31  * travis-cipart
17:47:55  * travis-cijoined
17:47:56  <travis-ci>luvit/luvit#2190 (fixes/pause_stdin - cfc674d : Ryan Phillips): The build has errored.
17:47:56  <travis-ci>Change view : https://github.com/luvit/luvit/compare/fixes/pause_stdin
17:47:56  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/66256327
17:47:56  * travis-cipart
17:49:03  * travis-cijoined
17:49:04  <travis-ci>luvit/luvit#2196 (fixes/net_destroy_and_process_once - b4c3f7c : Ryan Phillips): The build has errored.
17:49:04  <travis-ci>Change view : https://github.com/luvit/luvit/compare/fixes/net_destroy_and_process_once
17:49:04  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/66256339
17:49:04  * travis-cipart
17:49:28  * travis-cijoined
17:49:29  <travis-ci>luvit/luvit#2195 (fixes/flush_http - e3e535f : Ryan Phillips): The build has errored.
17:49:29  <travis-ci>Change view : https://github.com/luvit/luvit/compare/fixes/flush_http
17:49:29  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/66256337
17:49:29  * travis-cipart
17:49:48  * travis-cijoined
17:49:49  <travis-ci>luvit/luvit#2186 (fixes/double_callback2 - d8b8711 : Ryan Phillips): The build has errored.
17:49:49  <travis-ci>Change view : https://github.com/luvit/luvit/compare/fixes/double_callback2
17:49:49  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/66256319
17:49:49  * travis-cipart
17:50:33  * travis-cijoined
17:50:34  <travis-ci>luvit/luvit#2197 (fixes/release_buffers_set_mode - ba5eb55 : Ryan Phillips): The build has errored.
17:50:34  <travis-ci>Change view : https://github.com/luvit/luvit/compare/fixes/release_buffers_set_mode
17:50:34  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/66256341
17:50:34  * travis-cipart
17:50:46  * travis-cijoined
17:50:47  <travis-ci>luvit/luvit#2199 (tls-read-fix - 325cf71 : Tim Caswell): The build has errored.
17:50:47  <travis-ci>Change view : https://github.com/luvit/luvit/commit/325cf718f87c
17:50:47  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/66256345
17:50:47  * travis-cipart
17:50:56  * travis-cijoined
17:50:57  <travis-ci>luvit/luvit#2201 (2.1.15 - 6d71e13 : Ryan Phillips): The build passed.
17:50:57  <travis-ci>Change view : https://github.com/luvit/luvit/compare/2.1.15
17:50:57  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/66256358
17:50:57  * travis-cipart
17:51:06  * travis-cijoined
17:51:07  <travis-ci>luvit/luvit#2198 (feat/add_poll_libcurl_example - d9db111 : Ryan Phillips): The build has errored.
17:51:07  <travis-ci>Change view : https://github.com/luvit/luvit/compare/feat/add_poll_libcurl_example
17:51:07  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/66256343
17:51:07  * travis-cipart
17:53:12  * travis-cijoined
17:53:13  <travis-ci>luvit/luvit#2188 (fixes/add_thawte_premium_server_ca - 8499709 : Ryan Phillips): The build has errored.
17:53:13  <travis-ci>Change view : https://github.com/luvit/luvit/compare/fixes/add_thawte_premium_server_ca
17:53:13  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/66256323
17:53:13  * travis-cipart
17:55:16  * travis-cijoined
17:55:17  <travis-ci>luvit/luvit#2203 (fixes/windows - de5a898 : Ryan Phillips): The build has errored.
17:55:17  <travis-ci>Change view : https://github.com/luvit/luvit/compare/bcdc3456d539^...de5a898bbaec
17:55:17  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/66256363
17:55:17  * travis-cipart
17:56:26  * travis-cijoined
17:56:27  <travis-ci>luvit/luvit#2202 (fixes/fix_kill_close - 7367235 : Ryan Phillips): The build has errored.
17:56:27  <travis-ci>Change view : https://github.com/luvit/luvit/compare/fixes/fix_kill_close
17:56:27  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/66256361
17:56:27  * travis-cipart
18:06:33  <rphillips>rje: i think we should a function in virgo-base that does the spawn
18:06:37  <rphillips>write a function*
18:06:50  <rphillips>with stdin set to nil
18:12:16  <rje>are all the children that spawn'd ok with having their stdin closed?
18:12:58  <creationix>what if stdin is a pipe?
18:13:04  <creationix>or is that the case causing trouble
18:13:53  <rje>in the powershell 2.0 case (Windows 2008 server), stdin has to be explicitly closed before powershell can exiot
18:14:21  <rje>(long discussion with bert on that maybe a year + .5 ago
18:15:37  <creationix>we might need some option to close stdin in some sub-processes, but not others if some can’t handle stdin being closed
18:16:33  <creationix>I guess the question is what happens if stdin in closed and the child tries to read from stdin. Will their half also be closed and cause an error
18:17:57  <rphillips>the child should get an eof read reading from stdin
18:18:01  <rphillips>from*
18:20:25  <creationix>that sounds pretty safe
18:20:44  <creationix>maybe try just closing stdin as soon as we’re done writing to it and testing to see if anything breaks
18:20:45  * DarkGodjoined
18:28:56  <sousoux>creationix: I would rather choose /search = upstream /searchlocal = local
18:29:20  * kazuponquit (Remote host closed the connection)
18:30:00  <creationix>sousoux: a large part of the issue is it assumes the data is local. Once I make the search algorithm remote aware, it should be a lot faster
18:30:18  <sousoux>I'm making calls from a web front end and making the end user wait for 8 secs (at present with a very local lit server) is too long
18:30:55  <creationix>yep, it shouldn’t be any slower than making the request against the public server
18:31:09  <creationix>plus a tiny delay for local results
18:31:16  <sousoux>that is absolutely the goal
18:32:06  <sousoux>our server is currently in belgium but we have a lot of customers in the US so I may need to locate another one there
18:32:26  <sousoux>to cut down the time
18:38:33  <creationix>right, I just need to call out to upstream’s search command, search local-only, and then merge the results
18:38:37  <creationix>that should be much faster
18:38:44  <creationix>just one round-trip across the ocean
18:43:37  <creationix>sousoux: and my upstream is in USA (Texas) hmm
18:44:27  <creationix>maybe the search results could just include the server’s upstream as a url and let the client connect direct to the upstream, search there and then merge results?
18:44:57  <creationix>that way people in the US can query directly against my US server instead of waiting on your server to proxy the results
18:45:13  <sousoux>creationix: yup. that is why I was thinking of a search to local only. I only need that because I know those packages can only be on our server.
18:46:02  <sousoux>the search REST api
18:46:52  <sousoux>After when our back end decides it wants to install something it goes off and does it and notifies the web front end async when it has finished. It is less of a problem.
18:47:02  <creationix>right, also with this two-step process, the local UI can return results in two stages or skip the second stage alltogether
18:47:58  <creationix>sousoux: you wrote your own search UI right?
18:47:58  <sousoux>We don't need the second stage. If a package requires something from upstream that only happens once the user has said that they want to install.
18:48:21  <sousoux>The front end search UI is in our web page yes
18:48:31  <creationix>thanks, just trying to understand the use case
18:48:45  <creationix>so yes, making search local-only is the main thing you need
18:49:02  <sousoux>I think I mentioned it before but it is basically nodered rewritten as a very focussed M2M agent
18:49:22  <sousoux>what we are pulling from lit is dynamically installed nodes
18:49:58  <sousoux>they may have dependencies on other packages but the node itself is a very specific package that is loaded in a special way
18:50:05  <creationix>very cool
18:51:12  <sousoux>it works very nicely
18:51:32  <sousoux>The other thing I'm storing on lit is a library of different flows.
18:52:20  <sousoux>the UI throws up a list of packages with descriptions, versions, etc. That is what the query is retrieving.
18:53:00  <sousoux>at present there is no paging etc because we are just launching this functionality but I hope I'm going to have to think about that in the future :)
18:53:35  <creationix>yep, I plan on adding paging to the search API once we get more data. For now it’s very simple
18:54:06  <sousoux>It's fine for now. There won't be more than 20 items when we launch.
18:55:00  <creationix>so your search page is something like this? http://flows.nodered.org/
18:56:00  <sousoux>once the user selects a package I notify our back end over a permanent ws message bus that we maintain that the package is selected then the back end installs and notifies the front end over the message bus and hey presto the node appears in the users node list
18:56:44  <sousoux>the flows bit is like that but integrated into the editor
18:57:20  <sousoux>so when you select a flow you can instantly drop it on your editor page
18:57:52  <sousoux>that is obviously more time critical than the node story
18:59:01  <sousoux>II will be testing more on our live server tomorrow. at present I have a problem with our reverse proxy rewriting the URLs in the json and not including the port number
18:59:12  <sousoux>:(
18:59:39  <sousoux>I could recreate the urls but would prefer not to
18:59:55  <sousoux>lit is working fine
19:01:32  <sousoux>It all ends up on a dedicated M2M gateway called CloudGate - www.option.com
19:05:51  <creationix>sousoux: you’re in Europe right? How much later will you be working tonight?
19:11:55  <sousoux>intermittently I've been cooking supper for 4 kids putting them to bed etc. Soon I'm going to expire!
19:14:12  * KennethWilkejoined
19:15:39  <creationix>sousoux: https://github.com/luvit/lit/commit/906e1041fca562fc3566cb0dda07a1d0453b4462
19:16:04  <creationix>this is in the refactor branch. It’s pretty stable now, but I’m still testing before merging into master
19:16:16  <creationix>I hope for a lit release today
19:16:43  <creationix>or just make this one-line change in your server to make search faster https://github.com/luvit/lit/commit/906e1041fca562fc3566cb0dda07a1d0453b4462#diff-885fcaf845148fd7e8f89b722209437cR136
19:17:14  <creationix>that will use db.offlineMatch if there is an upstream
19:17:15  <sousoux>creatonix: ok. got you. that forces match to be offline all the time. fine for now.
19:17:56  <creationix>I think it’s a good permament fix. For remote results, we just need to make a remote search call and then merge the results
19:18:10  <sousoux>I'll pull that onto the live server tomorrow
19:18:21  <creationix>but I’m thinking this is better done in the client which is why I included the upstream url so the client can decide to search there directly
19:18:43  <sousoux>I think that is fine
19:20:04  <sousoux>I only use the rest api's for the front end. all the install stuff is over the lit web socket apart from flows which are just one file pulled directly into the front end and will never need to come from upstream.
19:22:26  <sousoux>creationix: thank you very much for the help and for luvi/t
19:28:45  <creationix>sousoux: glad it’s working for you
19:42:23  * kazuponjoined
20:42:04  * kazuponquit (Remote host closed the connection)
20:56:32  <creationix>rphillips: rje: check out this neat diagram a luvi user made https://github.com/luvit/lit/issues/85#issuecomment-110902862
20:57:09  * a_lequit
20:57:42  <rphillips>now that... is slick
20:58:28  * KennethWilkequit (Remote host closed the connection)
21:02:17  <rje>rphillips, creationix: i asked alex to make some inquiries into what flavors still exhibit the TOE bug. he's doing that ASAP
21:02:32  <rphillips>cool
21:02:36  <rphillips>that will help
21:29:58  * kazuponjoined
21:30:21  * kazuponquit (Read error: Connection reset by peer)
21:30:44  * kazuponjoined
21:31:57  * kazuponquit (Read error: Connection reset by peer)
21:32:23  * kazuponjoined
21:37:30  * kazuponquit (Ping timeout: 265 seconds)
21:38:32  * ldub_joined
21:39:01  * ldub_quit (Client Quit)
21:40:22  * ldubquit (Ping timeout: 256 seconds)
22:04:58  * bjornquit (Read error: Connection reset by peer)
22:21:40  * kazuponjoined
22:23:53  * SouL_|_joined
22:31:58  * kazuponquit (Remote host closed the connection)
22:59:17  * dan336quit (Quit: Leaving.)
23:16:03  <creationix>rphillips: this should solve the submodule problem with bootstrapping lit https://github.com/luvit/lit/commit/6a192d94edebc4fdeb5e2777a4122b02efc5a2c1
23:16:10  <creationix>we can just download zips from luvit.io
23:16:21  <creationix>(since github doesn't support submodules in it's zip service)
23:32:40  * kazuponjoined
23:37:37  * kazuponquit (Ping timeout: 255 seconds)
23:38:43  * dan336joined
23:49:29  <creationix>hmm, something is wrong with the zip writer or the zip reader
23:59:29  * dan336quit (Quit: Leaving.)