00:38:17  <rphillips>man this is sweet
00:38:22  <rphillips>creationix: tried it out... works great
00:39:05  <rphillips>going to clone into the agent and try this out
00:44:13  * DarkGodquit (Ping timeout: 255 seconds)
00:47:19  * joconnor_quit (Ping timeout: 245 seconds)
01:14:03  <rphillips>cool. I have a noop main working with the monitoring agent + new lit + luvit2 within lit
01:14:18  <rphillips>working good so far
01:18:24  * a_lequit (Remote host closed the connection)
01:29:35  <rphillips>unit tests are passing in virgo-base
01:30:02  <rphillips>creationix: is the luvit/init module checked into lit?
01:31:29  * UniOnquit (Remote host closed the connection)
01:35:35  * a_lejoined
01:41:28  <a_le>how do i empty the write queue for a stream?
01:45:29  <a_le>in other words, if there are pending write requests for a stream, and i uv_close the stream, do i need to worry that handle->write_queue_size might be still non-zero if i now want to proceed and delete the data structure where the stream handle is embedded?
02:14:30  * a_lequit (Remote host closed the connection)
02:17:16  <rphillips>hmm. a close() or destroy() should work
02:21:19  * a_lejoined
02:44:04  * a_lequit (Remote host closed the connection)
02:49:32  * imzyxwvujoined
02:56:05  <imzyxwvu>when i do this: local http = require "http" in a file required by another file, 'http' was not found. but if i add [[local require = require('luvit-require')()("bundle:modules/main.lua")]] before it, everything works.
02:58:00  <imzyxwvu>i'm using this build: "https://ci.appveyor.com/project/racker-buildbot/luvit/build/1.0.175/artifacts" the following code can cause it: a.lua: "require 'b'" b.lua "http = require 'http'"
03:03:40  <imzyxwvu>it seems require.lua:formatters.lua didn't replace the require function of the module's env.
03:07:00  * ^vjoined
03:16:13  * imzyxwvuquit (Ping timeout: 252 seconds)
03:20:48  * ^vquit (Ping timeout: 245 seconds)
03:22:37  * ^vjoined
03:28:18  * ^vquit (Ping timeout: 245 seconds)
03:40:53  * ^vjoined
03:43:26  * a_lejoined
03:49:13  * imzyxwvujoined
03:52:53  * ^vquit (Ping timeout: 245 seconds)
04:00:59  * ^vjoined
04:01:00  * ^vquit (Client Quit)
04:01:53  * imzyxwvuquit (Ping timeout: 246 seconds)
04:07:10  * ^vjoined
04:25:23  * ^vquit (Ping timeout: 245 seconds)
04:27:40  * ^vjoined
04:49:33  * ^vquit (Ping timeout: 245 seconds)
04:50:26  * ^vjoined
05:01:38  * ^vquit (Ping timeout: 245 seconds)
05:02:40  * ^vjoined
05:10:48  * ^vquit (Ping timeout: 245 seconds)
05:14:59  * ^vjoined
05:22:28  * ^vquit (Ping timeout: 245 seconds)
05:34:19  * a_le_joined
05:37:51  * a_lequit (Ping timeout: 256 seconds)
05:41:22  * a_le_quit (Ping timeout: 240 seconds)
05:48:42  * a_lejoined
05:57:41  * a_le_joined
05:59:01  * a_lequit (Ping timeout: 252 seconds)
05:59:34  * a_lejoined
06:03:24  * a_le_quit (Ping timeout: 246 seconds)
06:55:00  * imzyxwvujoined
06:56:45  <imzyxwvu>rpi2 compiles luajit (-j4) in 90 seconds.
06:59:36  * Akagi201quit (Remote host closed the connection)
07:00:13  * Akagi201joined
07:04:26  * imzyxwvu1joined
07:05:32  * imzyxwvuquit (Ping timeout: 252 seconds)
07:20:34  * Akagi201_joined
07:22:36  * Akagi201quit (Ping timeout: 265 seconds)
07:49:02  * torporjoined
08:34:28  * DarkGodjoined
10:43:26  * torporquit (Quit: Leaving.)
11:00:46  * torporjoined
11:20:34  * torporquit (Quit: Leaving.)
11:23:26  * torporjoined
12:34:21  * xtquit (Ping timeout: 265 seconds)
12:36:04  * xtjoined
13:08:52  * UniOnjoined
13:39:02  * torporquit (Quit: Leaving.)
14:03:47  <rphillips>nice
14:04:05  <rphillips>imzyxwvu1: we replace the require system with that line
14:05:21  <imzyxwvu1>rphillips: i thought the require in the env of a required module should also be replaced.
14:07:39  * torporjoined
14:11:16  <rphillips>hmm. it should
14:12:05  <rphillips>but it needs to come after the require line you pasted
14:16:19  <imzyxwvu1>https://github.com/luvit/luvit/blob/luvi-up/app/modules/require.lua#L187 this made _G of require.lua exposed to the module, including _G.require (lua's original require). but i can't find how to let it expose the own require system of luvit.
14:18:07  <avidal>L184 does that
14:19:11  <avidal>requireName defaults to "require" and generate(module.path) creates a "new" luvit-require implementation rooted at the path that the new module was located
14:19:16  <imzyxwvu1>avidal: but it seems the file required by another file can't require luvit's own library.
14:19:53  <imzyxwvu1>a.lua: require "b" b.lua: local http = require "http"
14:20:00  <avidal>are you sure the second module was actually located by luvit-require and not the fallback, which is lua require?
14:20:33  <imzyxwvu1>luvit a.lua => .\b.lua:1: module 'http' not found:
14:21:08  <imzyxwvu1>seems i misused the new require
14:21:15  <avidal>if luvit-require loads using the fallback, then the loaded module is still using the native require impl, not the luvit-require
14:21:27  <imzyxwvu1>require "./b" works.
14:21:35  <imzyxwvu1>sorry to bother you. i misused it.
14:22:19  <avidal>in your example of a.lua requiring b and b requiring http, you can fix it in a.lua with:
14:22:19  <avidal>require './b'
14:22:19  <avidal>luvit-require doesn't look in the cwd for modules unless you prefix with ./
14:23:12  * torporquit (Quit: Leaving.)
14:23:23  <avidal>does that make sense?
14:23:47  <avidal>you can verify if you change the value of requireName to something totally different; you'll see that the name is not available in the loaded module in your original example, and that's because it's actually being loaded by lua and not luvit
14:23:47  <imzyxwvu1>i made more sense.
14:24:39  <avidal>cheers :)
14:24:54  <avidal>i dug into it quite a bit a couple of weeks ago
14:25:22  <avidal>train just pulled in, gotta get going
14:25:24  <avidal>glad i could help
14:25:33  <imzyxwvu1>avidal: many thanks.
14:25:54  <imzyxwvu1>your answer helped me a lot about this.
14:26:46  <rphillips>thanks avidal
14:27:01  <imzyxwvu1>i need to read the code of new luvit's require.lua more carefully.
14:35:26  <avidal>np
14:37:31  <imzyxwvu1>it seems new luvit doesn't have an url module.
14:38:14  <imzyxwvu1>the one in old luvit is completely in lua. why not bump it?
14:41:52  <rphillips>it hasn't been ported yet
14:42:03  <rphillips>it's probably still in the old location in lib/luvit/...
14:42:13  <rphillips>and there is probably a test in tests/to-convert/
14:47:03  <avidal>your nicks are the same length and textual colors them the same way
14:47:10  <avidal>so it looks like one person having a conversation with himself
14:47:44  <avidal>imzyxwvu1: yeah, require.lua in luvit is a bit hard to grok; it could use more documentation i think
14:49:46  * a_lequit (Ping timeout: 255 seconds)
14:54:00  <rphillips>yeah, there is also some different behaviors when the require is within a 'bundle' as wel
14:54:02  <rphillips>well
14:54:11  <avidal>yep
15:06:56  * a_lejoined
15:10:32  <rphillips>creationix: i'm add the tests directory to the lit 'app' and it says main.lua isn't found
15:11:02  <rphillips>do you have an thought on how to add them in now
15:11:04  <rphillips>?
15:11:38  <creationix>lit app doesn’t work with luvit’s tests yet
15:11:46  <creationix>but you can still use `LUVI_APP=app lit tests/run.lua`
15:12:09  <rphillips>perfect... thanks
15:27:38  * torporjoined
15:31:10  <imzyxwvu1>i suggest to import lua-cjson to luvi, for the following reason: 1. it's a fast implement, faster than any lua implement and it's also licensed under MIT. 2. JS provides a JSON object but Lua doesn't. 3. JSON is so widely used.
15:47:19  * torporquit (Quit: Leaving.)
15:48:01  <imzyxwvu1>https://github.com/imzyxwvu/luvit-fly this is a web framework for luvit still under construction. thanks if anyone could give me any suggestions. i'll complete the document later.
15:57:43  <rphillips>creationix: thinking LUVI_MAIN might be appropriate
15:58:06  <rphillips>right now it's using the app/main.lua... would be nice to make it the tests/run.lua
15:58:44  <creationix>well, tests/run.lua isn’t a luvi main function, it’s a luvit script
15:58:48  <creationix>slightly different interface
15:59:00  <rphillips>right... it gets sourced from the app/main.lua
15:59:19  <creationix>but we could maybe allow overriding main and convert run.lua to a main.lua format
15:59:27  <rphillips>yeah
15:59:40  <rphillips>not all apps will have 'require' a file support
15:59:55  * dan336joined
16:07:59  * xtquit (Ping timeout: 265 seconds)
16:15:18  * xtjoined
16:17:11  * a_lequit (Ping timeout: 244 seconds)
16:21:10  <rphillips>rje: creationix: https://github.com/virgo-agent-toolkit/virgo-base-agent/pull/148
16:21:20  <rphillips>got virgo-base lit up
16:21:34  <rphillips>punny :)
16:22:03  <creationix>what do you think about my Makefile hack to built lit on the fly
16:22:09  <creationix>ideally, we can just assume lit is in the user’s path
16:22:14  <creationix>but it’s a little early for that I think
16:22:18  <rphillips>for now. I think it's a good solution
16:23:15  <rphillips>is there a way to enumerate which versions of packages are inlit?
16:23:18  <rphillips>in lit*?
16:27:38  * joconnorjoined
16:46:37  * a_lejoined
16:47:05  <creationix>rphillips: not yet, but it would be easy enough to add
16:47:20  <creationix>should probably add it to `lit install` to not overwrite packages already installed
16:51:17  <rphillips>now I want to build a luvi{t} OS
16:51:54  <creationix>that could be fun
16:53:14  <rphillips>no systemd, FTW
17:04:55  * torporjoined
17:05:30  * xtquit (Ping timeout: 265 seconds)
17:06:47  * xtjoined
17:16:31  <imzyxwvu1>good idea. i built a lua os whose INIT is a lua script that repl lua lines.
17:33:31  * a_lequit (Remote host closed the connection)
17:34:07  * a_lejoined
17:46:26  <rje>rphillips, nice lit'ified virgo
17:50:15  <rch>diff looks too small, i was expecting it to be a real big change
18:04:06  * torporquit (Quit: Leaving.)
18:04:07  <rphillips>rje: just need to port the agent now
18:04:37  * a_lequit (Remote host closed the connection)
18:05:13  * a_lejoined
18:06:15  * torporjoined
18:09:18  * DarkGodquit (Ping timeout: 265 seconds)
18:15:45  <rphillips>https://github.com/virgo-agent-toolkit/virgo-base-agent/tree/luvi-up
18:16:02  * torporquit (Quit: Leaving.)
18:16:14  <rphillips>the base-agent tree looks simple... the actual code needs some cleanup
18:29:39  * torporjoined
18:39:33  <creationix>rch: lit-up and luvi-up aren’t that different
18:43:54  <rch>oh i see
18:51:34  <rphillips>https://www.evernote.com/shard/s9/sh/357ac89f-79e1-4c15-8f7b-be66557fa207/a41ed69ae7d51d5bcaadad7b2006f568
18:51:40  <rphillips>unit tests work on windows :)
18:53:38  <rphillips>creationix: lit make app should pull the luvit deps right?
18:53:50  <rphillips>if they are in the package.lua
18:54:30  <creationix>make app imports the deps straight from the lit db to the zip, it then pulls all files from disk. In the case of the luvit tree, the local file will overwrite the lit ones
18:54:50  <creationix>but if you rm -rf app/modules, then `lit make app` will still make a valid luvit
18:55:02  <creationix>I do need to add the .exe extension when on windows
18:55:22  <rphillips>https://gist.github.com/rphillips/4946e74f68d1a97addca
18:55:27  <rphillips>this is my windows batch file
18:55:48  <rphillips>if I run lit install within the app folder, the binary works
18:55:58  <rphillips>if I do a lit make app, the require.lua file is missing
18:56:55  <creationix>I should publish a luvit metapackage so you can depend on luvit
18:57:06  <rphillips>+1
18:57:09  <creationix>I think just a `lit publish` on luvit’s app folder will do it
18:57:10  <creationix>you can try
18:57:24  <creationix>hmm, actually, make sure to `rm -rf modules` first
18:57:30  <rphillips>lit-up branch?
18:57:35  <creationix>right
18:57:37  <rphillips>k
18:57:48  <creationix>you should still be authorized to publish to the luvit org
18:59:08  <rphillips>woo
18:59:16  <rphillips>seems to have worked
19:00:11  <rphillips>creationix: is it called luvit/luvit?
19:00:15  <rphillips>the package name
19:00:22  <creationix>yep
19:00:31  * a_lequit (Remote host closed the connection)
19:01:17  * a_lejoined
19:01:37  <creationix>a_le: I believe libuv flushes the queue before calling the close callback
19:01:38  <rphillips>hmm
19:01:52  * a_lequit (Read error: Connection reset by peer)
19:02:08  * a_lejoined
19:02:17  <creationix>a_le: no, sorry, it’s uv_shutdown that flushes
19:02:22  <rphillips>No matching package: luvit/luvit@2.0.0
19:02:36  <creationix>rphillips: what did it say when you published it?
19:02:40  <rphillips>publishing: luvit@2.0.0
19:02:45  <rphillips>done: success
19:03:43  <rphillips>i did luvit publish
19:03:49  <rphillips>is that right for the org?
19:04:31  <creationix>oh interesting, it published to luvit@v2.0.0 instead of luvit/luvit@v2.0.0
19:05:52  <creationix>rphillips: yep, my bad https://github.com/luvit/luvit/blob/lit-up/app/package.lua#L2
19:05:55  <creationix>should be luvit/luvit
19:06:34  <creationix>rphillips: pull lit-up and publish again
19:07:21  * DarkGodjoined
19:09:23  <creationix>rphillips: when it published, it didn’t include modules right? Just init.lua and main.lua and package.lua I think
19:10:07  <rphillips>correct
19:10:09  <rphillips>pushed it again
19:10:18  * travis-cijoined
19:10:19  <travis-ci>luvit/luvit#1563 (lit-up - 9356fcc : Tim Caswell): The build was broken.
19:10:20  <travis-ci>Change view : https://github.com/luvit/luvit/compare/3f11ea698b1b...9356fcc6bf0e
19:10:20  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/50245135
19:10:20  * travis-cipart
19:11:27  <creationix>rphillips: looks like it’s working great
19:11:54  <creationix>so luvit/luvit is both a luvi app and a library
19:12:02  <rphillips>yeah
19:12:03  <creationix>library mode just requires init.lua, but app mode uses main.lua
19:12:16  <rphillips>the lit install... actually crashed on a pass
19:12:28  <rphillips>something to try and reproduce
19:12:34  <rphillips>within luvi
19:12:42  <rphillips>maybe the ssl thing
19:12:42  <creationix>interesting
19:12:56  <creationix>your upstream is still wss right?
19:13:01  <rphillips>i ran it again and it completed successfully
19:13:19  <creationix>yeah, I haven’t seen a crash there yet
19:13:23  <rphillips>yeah, wss
19:21:12  <rphillips>creationix: https://github.com/virgo-agent-toolkit/virgo-base-agent.git
19:21:19  <rphillips>could you try the luvi-up branch on your windows box?
19:21:32  <creationix>doing that now
19:21:33  <rphillips>make.bat lit
19:21:36  <rphillips>make.bat virgo-base
19:21:38  <rphillips>make.bat test
19:21:56  <rphillips>luvit packages do not appear to be sucked down
19:25:48  <rphillips>works on osx for me
19:29:06  <creationix>almost done fixing lit make for windows
19:30:02  <rphillips>sweet
19:30:03  <rphillips>thanks
19:30:30  <rch> creationix │ so luvit/luvit is both a luvi app and a library
19:30:33  <rch>mindblown.gif
19:30:46  <creationix>rch: yep
19:33:23  <rphillips>virgo-base is the same way
19:33:28  <rphillips>though the app is just the test suite
19:33:38  <creationix>rphillips: almost working. Try with latest lit and luvi-up
19:33:47  <creationix>(assuming you’re on a windows box)
19:33:56  <rphillips>yeah... trying...
19:34:12  <creationix>it appears the issue now is path handling somewhere
19:36:06  <rphillips>creationix: https://www.evernote.com/shard/s9/sh/cd161898-7765-4199-b55b-9251d9034626/72cc9fe87b6849e967a1e1f2cb186474
19:36:09  <rphillips>is this what you see?
19:36:27  * travis-cijoined
19:36:28  <travis-ci>luvit/luvit#1564 (lit-up - 0901c49 : Tim Caswell): The build was fixed.
19:36:28  <travis-ci>Change view : https://github.com/luvit/luvit/compare/9356fcc6bf0e...0901c4997d12
19:36:29  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/50248667
19:36:29  * travis-cipart
19:36:30  <creationix>something like that
19:37:09  * torporquit (Quit: Leaving.)
19:37:16  <creationix>windows says luvit.exe is not a valid zip
19:37:35  <rphillips>hmm
19:38:17  <creationix>mingw unzip can read it
19:38:23  <creationix>it’s missing main.lua and init.lua
19:38:32  <creationix>it installed the deps, but not the files
19:38:49  * joconnorquit
19:38:53  <creationix>lit must still be broken on windows, will fix
19:39:27  <rphillips>i don't see the luvit modules being pulled down
19:41:46  <creationix>I’m still trying to get luvit itself to `lit make`. You have luvit/luvit@2.0.0 as a dep right?
19:43:53  <creationix>maybe I’m not pulling in deps recursivly
19:47:25  <rphillips>yeah, it's in the package.lua
19:48:48  * travis-cijoined
19:48:49  <travis-ci>luvit/luvit#1565 (lit-up - be044b5 : Tim Caswell): The build passed.
19:48:49  <travis-ci>Change view : https://github.com/luvit/luvit/compare/0901c4997d12...be044b5353b5
19:48:49  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/50250642
19:48:49  * travis-cipart
19:50:33  <creationix>hmm, when I make a sample app with just one dep to luvit/luvit@2.0.0 it pulls in all the luvit libs
19:51:49  <creationix>I think part of the problem is LUVI_APP doesn’t like windows paths
19:52:15  <creationix>in the Make.bat file, I used relative unix paths like “lit/app” and it works
19:52:29  <creationix>but passing in uv.cwd() which looks like ‘C:\Code\luvit/app’, it breaks
19:52:36  <creationix>\Code\luvit\app
19:56:45  * imzyxwvu1quit (Ping timeout: 246 seconds)
20:01:49  <creationix>ok, so LUVI_APP is a *colon* separated list, what could go wrong with windows paths containing colons :/
20:03:01  <rphillips>hmm. it looks like the lit app is being used with a make virgo-base
20:03:07  <rphillips>the lit main.lua*
20:08:00  <creationix>rphillips: what do you mean?
20:08:40  <rphillips>creationix: https://www.evernote.com/shard/s9/sh/cd161898-7765-4199-b55b-9251d9034626/72cc9fe87b6849e967a1e1f2cb186474
20:08:48  <rphillips>see how it is using commands/tests...
20:09:18  <creationix>oh, it’s interpreting your arg as a lit command
20:09:29  <creationix>how are you calling lit?
20:10:25  <rphillips>virgo-base.exe tests\run.lua
20:10:32  <rphillips>its the in the make.bat file
20:11:02  <creationix>interesting, virgo-base has lit’s main
20:12:51  <creationix>yeah, `lit make` is busted for sure.
20:13:00  <creationix>it’s not including luvit’s main and it’s giving you lit’s main
20:13:14  <creationix>I pushed a patch to luvi that helps it work better on windows
20:17:17  <creationix>rphillips: found the bug
20:18:50  <creationix>fs.scandir isn’t reporting the type on windows
20:19:01  <creationix>so lit make is skipping all files when importing
20:19:18  <creationix>I’m guessing your command has a trailing : somewhere in LUVI_APP and that’s why it’s inheriting from lit
20:20:22  <rphillips>hmm
20:23:19  <rphillips>i don't see LUVI_APP being set anywhere but the Make.bat file
20:28:49  * travis-cijoined
20:28:50  <travis-ci>luvit/luv#236 (master - e17c72a : Tim Caswell): The build has errored.
20:28:50  <travis-ci>Change view : https://github.com/luvit/luv/compare/dd2b78ae5e26...e17c72a78bc0
20:28:50  <travis-ci>Build details : http://travis-ci.org/luvit/luv/builds/50255778
20:28:50  * travis-cipart
20:29:41  <rphillips>picking up the kids from school. brb in 20
20:34:23  <creationix>ok
20:50:31  * Akagi201joined
20:51:32  <a_le>creationix: i think i missed your message...
20:51:58  <creationix>what were you asking? (I’m at a different computer now)
20:52:21  * Akagi201_quit (Ping timeout: 246 seconds)
20:53:11  <creationix>oh, something about uv_close right
20:53:22  <creationix>so uv_shutdown will flush all buffers and callback when it’s safe to uv_close
20:53:37  <rphillips>.
20:53:49  <creationix>rphillips: I fixed `lit make` for windows I think
20:53:53  <rphillips>sweet
20:53:57  <rphillips>trying it out
20:54:07  <a_le>creationix: not sure i understand... wouldn't uv_close_cb be the only thing i need to wait for?
20:54:28  <a_le>(before I free my handle)
20:54:28  <creationix>I would think that would drop buffered data
20:54:52  <creationix>http://docs.libuv.org/en/v1.x/stream.html#c.uv_shutdown
20:55:06  <creationix>right, always wait till close_cb before freeing the handle
20:56:22  <creationix>a_le: there is still old issue https://github.com/joyent/libuv/issues/157
20:56:28  <rphillips>looks like the same issue...
20:56:31  <a_le>but so, uv_shutdown is only necessary if i want to be sure to deliver all of the queued data?
20:56:34  <rphillips>updated lit on master
20:56:41  <creationix>a_le: right, that’s my understanding
20:57:03  <a_le>then in the shutdown callback i actually do uv_close
20:57:12  <a_le>and then in the uv_close callback i actually free?
20:57:15  * torporjoined
20:57:32  <creationix>rphillips: also I just pushed a patch to the windows binaries for luvi
20:57:39  <rphillips>ah k
20:58:13  <creationix>rphillips: in luvit/luvit I can now do `make clean` and `make test` on windows and it works
20:58:23  <creationix>look at the changes I made to the Make.bat file
20:58:29  <creationix>(lit-up branch)
20:58:46  <rphillips>k
21:01:08  * DarkGodquit (Remote host closed the connection)
21:01:47  <rphillips>hmm. still looks like it's using the lit main.lua
21:02:32  <rphillips>pushed the virgo-base#luvi-up branch with the updated makefile
21:05:16  <rphillips>ok... still trying it out...
21:05:20  <rphillips>got closer
21:09:07  <rphillips>ok. I need to move the modules/* files
21:10:00  <creationix>also you don’t need all the luvit/* deps, just luvit/luvit
21:10:07  <rphillips>got that one
21:10:22  <rphillips>so if I move app/modules/virgo to app/virgo
21:10:33  <rphillips>require('virgo...') works?
21:10:54  <creationix>don’t think so
21:10:55  <rphillips>i'm getting a module 'virgo/connection' not found
21:11:12  <creationix>require looks in the modules folder only
21:11:30  <rphillips>wasn't there a lit patch to ignore that folder?
21:11:31  <creationix>but you can do “./virgo” from main.lua assuming your require bootstrap has the right path
21:12:01  <creationix>lit make now ignores modules, I should probably add that to lit publish too
21:12:24  <rphillips>https://github.com/virgo-agent-toolkit/virgo-base-agent/blob/luvi-up/tests/test-connection.lua#L16
21:12:34  <rphillips>what is the best to load the module now?
21:12:52  * a__quit (Remote host closed the connection)
21:12:56  <rphillips>the virgo module was in app/modules
21:13:17  <creationix>hmm, virgo is a library not an app
21:13:21  <creationix>that looks ideal
21:13:50  <creationix>but from within virgo’s tests, you probably need “../app/init” or something
21:14:19  <creationix>I gotta run, I’ll brb in about an hour
21:14:52  <rphillips>np
21:15:36  * a__joined
21:25:21  * torpor1joined
21:27:03  * torporquit (Ping timeout: 252 seconds)
21:53:07  <rphillips>looks like luvit:lit-up is installing the luvit modules from lit to run the tests against
21:53:33  <rphillips>i'm getting virgo/connection not found
21:53:41  * torpor1quit (Quit: Leaving.)
21:53:44  <rphillips>which makes sense because the files are local
22:19:12  <rphillips>yeah, i think we will need to fix the packaging...
22:21:31  <creationix>rphillips: ok, I’m back
22:22:45  <rphillips>wb
22:23:12  <rphillips>creationix: see my messages on the state of things?
22:24:20  <creationix>can I check out your code?
22:24:28  <creationix>luvit/luvit is working as expected for me on windows now
22:24:40  <creationix>the only remaining bug in lit-up is something is broken in the repl
22:25:16  <rphillips>yeah, I checked it all in
22:25:38  <creationix>rphillips: your luvit at lit-up isn’t working?
22:25:50  <rphillips>that works
22:25:56  <rphillips>virgo-base#luvi-up
22:26:32  <rphillips>luvit's lit-up is installing the luvit modules from lit, then running tests against those
22:26:33  <creationix>you mean lit-up?
22:26:58  <creationix>rphillips: oh, you mean from the central repository
22:27:02  <creationix>yes, I do know about that
22:27:08  <creationix>I should probably fix that
22:27:30  <rphillips>i merged the lit-up branch to luvi-up in virgo-base
22:27:39  <rphillips>probably was a bit premature
22:27:41  <creationix>just created lit #22 for that
22:29:32  <creationix>ok, so virgo-base is a library only right?
22:35:33  <creationix>rphillips: how is virgo-base used? If it’s just a library and not a standalone app it should probably have a “lib” folder instead of “app” and doesn’t need main.lua
22:36:29  <creationix>so for running the tests, I think a custom main would help a lot
22:38:17  <rphillips>it's a library
22:38:52  <rphillips>creationix: could you help me tweak virgo-base
22:38:54  <rphillips>?
22:39:06  <creationix>yeah, just making sure I understand the use case
22:39:13  <creationix>I haven’t made a lit library this big yet
22:39:17  <rphillips>yeah, it's used by the monitoring agent
22:39:29  <rphillips>it's basically a library for agents
22:39:39  <rphillips>has connection logic, etc
22:39:46  <creationix>so is it the library’s responsibility to setup the luvit style env? (globals, event loop, etc)
22:40:07  <rphillips>i would say it's the agent's responsibility to setup the event loop, etc
22:40:18  <rphillips>virgo-base is just a library of luvit code
22:40:25  <creationix>ok, I’ll try some stuff and send a pr
22:40:29  <rphillips>thanks!
22:44:29  <creationix>rphillips: what org should this be under in lit?
22:44:45  <creationix>you can claim any github org that you’re a public member of
22:44:47  <rphillips>virgo-agent-toolkit
22:45:09  <creationix>run `lit claim virgo-agent-toolkit`
22:45:21  <creationix>and then to add me, run `lit share virgo-agent-toolkit creationix`
22:48:18  <rphillips>done
22:48:46  <creationix>I see it
22:48:56  * creationixis amazed lit is actually working
22:49:07  <rphillips>totally impressed as well
22:52:01  * UniOnquit (Read error: Connection reset by peer)
22:52:27  * UniOnjoined
22:52:38  <creationix>would you prefer a custom main in luvi or just assume the user has a luvit standalone binary for running tests?
22:54:58  <creationix>if you go to https://github.com/luvit/lit-backup and look at the list of tags, you can see all the packages in lit.luvit.io
22:55:20  <creationix>or `git ls-remote git://github.com/luvit/lit-backup.git | grep tags`
22:57:08  <creationix>I’m still manually pushing the backup though, so it’s not always up to date
22:57:29  <creationix>I just log in as lit@luvit.io and do `git push --tags`
23:14:26  <a_le>after on_close(my_handle), if i walk all the handles i can find my_handle still pending, closing, but devoided of its type...
23:15:19  <a_le>creationix: how does this make sense?
23:15:56  <creationix>uv_walk iterates over your closed handle?
23:16:04  <creationix>I don’t think that should happen
23:16:04  <a_le>well it appears not to be closed
23:16:12  <a_le>but i got my callback invoked with that handle
23:16:20  <creationix>if the close callback gets called it better be closed
23:16:23  <a_le>also, UV_HANDLE_TYPE_MAP returns unknown
23:16:57  <a_le>and the loop hangs
23:17:04  <a_le>i.e. that handle never gets closed
23:17:14  <a_le>and given i have no other events, it's stuck there forever
23:17:50  <creationix>is it `is_closing`?
23:18:15  <a_le>yes
23:18:16  <a_le>walkAndCountHandlesCb[9] {0x75172a0}[0] still waiting on pending handle of type <unknown> @0x8d3fed8 which is closing
23:18:53  <creationix>I can’t imagine what’s causing that. Did you try asking in #libuv?
23:19:05  <a_le>oh damn i am in #luvit
23:19:09  <a_le>on_close[7] {0x8d3fec0}A[1];handle@0x8d3fed8;|0->|->0|0-> down() for an on_close(0x8d3fed8) TCP handle
23:19:18  <a_le>this is where it got closed a while before
23:19:26  <a_le>the callback for that had been invoked
23:20:21  <a_le>i should print the type there too, TCP handle is just inferred by me from the offset within the struct