00:26:26  * UniOnquit (Remote host closed the connection)
00:47:24  * nateratorjoined
01:49:24  <rphillips>would be interesting to see if luamin could be ran on a `lit make`
01:49:48  <rphillips>seems like it shrinks the code around 30%
02:14:27  * SouLquit (Ping timeout: 245 seconds)
02:55:08  * Igelquit (Quit: ZNC - http://znc.in)
03:00:07  * nateratorquit (Quit: naterator)
03:00:38  * nateratorjoined
03:00:52  * nateratorquit (Client Quit)
06:42:23  * nateratorjoined
06:51:52  * nateratorquit (Ping timeout: 255 seconds)
09:04:02  * dobsonquit (*.net *.split)
09:06:07  * dobsonjoined
11:12:41  * UniOnjoined
13:09:40  * Igeljoined
14:02:18  <rphillips>good morning
14:09:45  <avidal>morning
14:13:09  <avidal>hmm
14:13:19  <avidal>am i a contributor to luvit/lit or is the wiki publicly editable?
14:13:27  <avidal>i just made a small change
14:13:30  <avidal>fixed a typo
14:13:45  <avidal>https://github.com/luvit/lit/wiki/Creating-Your-First-Package/_compare/d808b110899731c4f0ad400b2abb2373d68d3730...204ac5354deeee8a04161b81234b7ef349cf224f
14:14:04  <avidal>i just realized that wiki edits (obviously) don't go over pull requests anyway
14:14:46  <avidal>yeah i guess the wiki is publicly editable
14:35:11  * nateratorjoined
14:39:52  * nateratorquit (Ping timeout: 255 seconds)
14:59:27  <rphillips>https://github.com/luvit/luvit/pull/650
15:18:19  * dan336joined
15:23:23  <rphillips>ran agent2 over the weekend... 13.7 MB
15:24:04  <rphillips>dedr
15:24:06  <rphillips>woops
16:02:02  * nateratorjoined
16:08:40  * joconnorjoined
16:21:32  <rphillips>we could do a release soon, I think
16:21:48  <rphillips>get the process.* streams in
16:28:31  <creationix>avidal: thanks for fixing the typos
16:28:36  <avidal>np
16:29:30  <creationix>rphillips: good mornin’
16:29:54  <rphillips>howdy tim
16:42:50  <creationix>rphillips: have you had a chance to try the new binary support in lit?
16:43:21  <rphillips>not yet... how do I need to tweak the lua-sigar module?
16:43:22  <creationix>It seems to work really well for the use case of glfw, It should work equally well lua bindings
16:43:44  * travis-cijoined
16:43:45  <travis-ci>luvit/luvit#1798 (luvi-up - 825dffc : Ryan Phillips): The build passed.
16:43:45  <travis-ci>Change view : https://github.com/luvit/luvit/compare/01e01fa0d149...825dffc63531
16:43:45  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/53674022
16:43:45  * travis-cipart
16:44:07  <creationix>so the magic path variables $OS and $ARCH will match all possibly values when publishing, but only the current native when installing or packing into a single binary
16:45:03  <creationix>I think most C bindings will have some level of wrapper on top written in lua
16:45:40  <creationix>in that top lua file (sigar/init.lua), you will calculate the path based on ffi.os and ffi.arch. I would put the binaries inside the sigar module under $OS-$ARCH/*
16:46:10  <creationix>so that the require is (‘./Windows-x64/sigar.dll’) for windows
16:46:23  <rphillips>i'll PR that up
16:46:29  <rphillips>which version of LIT do I need?
16:46:50  <creationix>I shared my lua code from glfw that auto-detects the file names since they vary so much by platform
16:46:54  <creationix>(shared in the wiki page)
16:47:16  <creationix>at least 0.11.4 I think
16:48:23  <creationix>https://github.com/luvit/lit/wiki/Publishing-Compiled-Code#directory-structure
16:48:45  <creationix>https://github.com/luvit/lit/wiki/Publishing-Compiled-Code#bundling-lua-c-api-libraries
16:49:33  <creationix>hmm, yeah that second tree is misleading, I’ll update it
16:50:46  <creationix>no, actually, it works great, that is better than what I just suggested. I forgot about the trick I wrote in the wiki
16:52:03  <rphillips>creationix: hmm. my import isn't found... i'll commit this
16:52:11  <rphillips>my non-binary import*
16:54:47  <rphillips>creationix: https://github.com/virgo-agent-toolkit/rackspace-monitoring-agent.git
16:54:53  <rphillips>branch, fixes/binup
16:55:05  <rphillips>just `make` within the check
16:55:07  <rphillips>checkout
16:55:34  <rphillips>'./client/virgo_client' had been found before
16:55:46  <rphillips>with lit 0.11.0
16:55:47  <creationix>k
16:57:45  <creationix>so one change was lit now applies filters when installing dependencies
16:57:58  <creationix>(was needed so as to not include all binary versions when building an app)
16:58:04  <rje>rphillips, were you able to find anything that was memory intensive?
16:58:15  <rphillips>rje: with
16:58:17  <rphillips>?
16:59:10  <creationix>rphillips: what is “virgo-client”? A folder or something?
16:59:35  <rphillips>file
16:59:36  <rphillips>https://github.com/virgo-agent-toolkit/rackspace-monitoring-agent/blob/luvi-up/client/virgo_client.lua
16:59:52  <creationix>ahh, in rma
17:00:59  <rje>rphillips: you had mentioned that virgo was taking up more memory than anticipated
17:01:20  <rje>and that you'd look into it if you had time
17:01:34  <creationix>rphillips: here is the problem, you changed **.lua to *.lua https://github.com/virgo-agent-toolkit/rackspace-monitoring-agent/compare/fixes/binup#diff-d1fa909ca8a7ee494144a51c73228384L9
17:01:41  <rphillips>ah... I think it's just the lua files... we could minimize them, or luajit them to .raw objects to compress them
17:01:50  <rphillips>doh!
17:01:50  <creationix>*.lua only looks in the top folder
17:02:50  <creationix>the luajit bytecode files don’t compress as well as lua source code
17:02:56  <creationix>it’s less expressive being vm assembly
17:03:13  <creationix>espcially once you factor in deflate
17:03:21  <creationix>(which the zip bundle uses on the highest setting)
17:04:03  <creationix>though we should support bytecode loading with the module loader. I’m pretty sure that works with loadstring
17:04:51  <rje>when the executable is loaded, is the zip and or uncompressed lua kept in memory?
17:05:25  <rphillips>creationix: i think we need to bump luvit within lit
17:05:50  <creationix>rje: it’s only uncompressed the first time the file is required
17:06:09  <creationix>and then the lua string should get GC’ed after that and only the exports value is cached
17:06:43  <creationix>the zip itself is part of the executable, so I’m not sure what OS caching does there. I read it using normal fs.open calls on uv.exepath()
17:07:10  <creationix>rphillips: most likely, let me see what’s out of date
17:07:54  <creationix>looks like fs.readStream process.std{out|in|err} and a tweak to the pretty printer
17:08:13  <creationix>and the newer lit
17:08:20  <rje>creationix: that's part of my thoughts, as it is part of the exe i believe it is kept in ram as part of the executable image. if we read the exe from disk to read the zip, maybe we can deallocate that portion
17:08:46  <rje>creationix: if we can't maybe we should read it from memory
17:08:52  <creationix>rje: maybe, I don’t know much about that
17:09:25  <creationix>oh, I remember now, I load the entire zip into memory for miniz to use
17:10:06  <creationix>hmm, nevermind, I used to
17:10:14  <creationix>now I just pass the path to miniz https://github.com/luvit/luvi/blob/master/src/lua/init.lua#L332
17:11:01  <rje>ok, so to be clear, right now it works as reading the zip from disk
17:11:22  <creationix>right, here is the miniz bindings https://github.com/luvit/luvi/blob/master/src/lminiz.c#L28-L56
17:11:37  <creationix>using uv_fs_read to read from the fd
17:12:12  <creationix>all miniz requires is that when it asks for a range of bytes, I return them
17:12:28  <rje>k, thank you
17:22:08  <creationix>rphillips: https://github.com/luvit/luvit/pull/652
17:22:21  <creationix>it’s already published to lit btw
17:24:59  * travis-cijoined
17:25:00  <travis-ci>luvit/luvit#1800 (v1.9.5-pre - 0433307 : Tim Caswell): The build passed.
17:25:00  <travis-ci>Change view : https://github.com/luvit/luvit/commit/0433307d0510
17:25:00  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/53680380
17:25:00  * travis-cipart
17:30:40  <rphillips>creationix: hmm. can't find module sigar
17:30:45  <rphillips>updated the branch on github
17:30:55  <rphillips>i'm on OSX
17:32:21  <creationix>rphillips: close, but require isn’t aware of $OS and $ARCH
17:32:39  <creationix>you need to prefix your require like $OS .. “-“ .. $ARCH .. “/sigar”
17:33:49  <creationix>rphillips: if you want, you can put a `sigar.lua` in libs that does this for you
17:33:56  <rphillips>sweet
17:34:20  <creationix>return require(‘./‘ .. $OS .. “-“ .. $ARCH .. “/sigar”)
17:36:37  <rphillips>nice... works on osx
17:36:48  <rphillips>i'll get the linux and windows modules added
17:36:48  <creationix>yep and gives a pretty nice error message on linux
17:36:58  <rphillips>creationix: which distro do you use for the linux build of luvi?
17:37:14  <creationix>I’ve been using Ubuntu 14.04 since it’s the current LTS
17:37:19  <rphillips>k
17:40:56  <creationix>I didn’t know jit had .os and .arch
17:41:02  <creationix>I guess those match what’s in ffi
17:41:08  <creationix>lit uses ffi.os and ffi.arch
17:44:56  <rphillips>ah ok
17:53:34  * travis-cijoined
17:53:35  <travis-ci>luvit/luvit#1801 (luvi-up - 57ce6e4 : Tim Caswell): The build passed.
17:53:35  <travis-ci>Change view : https://github.com/luvit/luvit/compare/a1bf6af26970...57ce6e475ef2
17:53:35  <travis-ci>Build details : http://travis-ci.org/luvit/luvit/builds/53683753
17:53:35  * travis-cipart
17:54:29  <rphillips>creationix: rje: https://github.com/virgo-agent-toolkit/rackspace-monitoring-agent/pull/690
17:54:33  <rphillips>got the binary modules added in
17:55:42  <creationix>seems to work (I don’t have /etc/r-m-a.cfg on my machine)
17:55:54  <rje>nice
17:56:13  <creationix>is it a drop-in replacement for the old agent, I could try it on my luvit.io box
17:57:11  <rphillips>almost
17:58:00  <creationix>when I run it on that box, it just exits with a large floating point number
17:58:05  <creationix>4.77548...
17:58:27  <creationix>I am still running the old agent fwiw
17:58:43  <rphillips>hmm
17:58:53  <rphillips>same 14.04 distro?
18:01:09  <creationix>no, it’s an arch box
18:05:28  <creationix>I can require the .so directly in luvit without any error
18:05:41  <creationix>not sure how to use it though, it’s a pretty opaque API just returning a userdata
18:05:50  <creationix>(from sigar.new)
18:11:51  <rje>Questing with Luvit, a libUV async framework for Lua is still under review for OSCON
18:13:26  <creationix>wow, they are really behind this year
18:14:05  <rphillips>ok. centos 5 and 6 have too old of a libc
18:14:22  <rphillips>does not run luvi
18:15:31  <creationix>that’s a shame.
18:15:49  <creationix>are there enough of them that a custom luvit is too much trouble?
18:15:58  <creationix>*custom luvi
18:16:47  <creationix>my normal uname filter won’t help since they are still Linux-x86_64 I’ll bet
18:17:02  <rphillips>i think we will have the agent buildbot compile luvi and sigar
18:17:10  <rphillips>on each platform
18:17:15  <rphillips>they package to deb and rpm already
18:17:21  <creationix>that would work well
18:17:38  <rphillips>libc--
18:18:01  <rphillips>golang realy got static binaries down right on linux
18:18:55  <creationix>yep
18:19:07  <creationix>but no dynamic modules
18:19:29  <creationix>ok, so my archlinux box has glibc 2.20
18:23:34  <creationix>ubuntu has 2.19
18:23:40  <creationix>(had to compile a C program to figure it out)
18:26:25  <creationix>to be precise, ubuntu 14.04 has “Ubuntu EGLIBC 2.19-0ubuntu6”
18:26:44  <creationix>while archlinux has vanilla “GNU libc 2.20”
19:04:24  * creationixshould eat lunch some time
20:06:07  * nateratorquit (Quit: naterator)
20:10:04  * nateratorjoined
21:04:10  <rphillips>rje: around?
21:07:24  <rje>rphillips, yes
21:07:58  <rphillips>rje: can you send me the windows .exe and .pdb for the agent on windows. from the master branch?
21:08:16  <rphillips>I don't have a readily available 2010 VS box
21:08:25  <rphillips>it's for the veracode scan
21:08:54  <rje>rphillips, would you want it built or from the buildbot?
21:09:07  <rphillips>from the buildbot would be fine
21:09:17  <rphillips>whichever is easiest
21:09:38  <rje>64 or 32 bit? both?
21:09:42  <rphillips>64bit
21:15:39  * rjegoes and reactivates the windows buildbots, then cries
21:18:32  <rje>rphillips, do you need the Debug version or Release?
21:18:42  <rphillips>i think debug
21:22:28  <rje>k, that i have to build
21:47:20  * nateratorquit (Quit: naterator)
21:49:59  * nateratorjoined
21:59:06  <rje>rphillips: where does the exe/pdb need to go?
21:59:28  <rphillips>rje: if you email them to me, or dropbox it... i'll upload it to the veracode website
22:01:04  <rje>emailed
22:01:50  <rphillips>got it... thanks
22:02:32  <rje>no problem
23:14:00  <creationix>rch: rphillips: New demo for OSX and Linux, `lit make github://creationix/termbox-sample`
23:14:23  <creationix>makes a binary “rainbows”
23:15:03  <creationix>dinner time
23:30:06  <rch> /Users/tim/luvi/src/lua/init.lua:404: [string "bundle:/deps/termbox/init.lua"]:12: Missing shared library in : /deps/termbox/OSX-x64
23:52:44  * UniOnquit (Remote host closed the connection)