00:00:30  * Golesquit (Quit: Computer has gone to sleep.)
00:03:26  * DarkGodquit (Remote host closed the connection)
00:05:21  * DarkGodjoined
01:06:23  * philips_quit (Excess Flood)
01:09:33  * philips_joined
01:49:50  * DarkGodquit (Quit: Leaving)
02:01:42  * indexzeroquit (Quit: indexzero)
02:15:40  * joshthecoderquit (Quit: Leaving...)
02:17:20  * indexzerojoined
02:38:04  * indexzeroquit (Quit: indexzero)
02:44:35  * indexzerojoined
02:57:01  * mmaleckichanged nick to mmalecki[zzz]
03:03:02  * xmingquit (Ping timeout: 250 seconds)
03:08:04  * joshthecoderjoined
04:06:37  * kazuponjoined
04:59:16  * xmingjoined
06:35:18  * joshthecoderquit (Quit: Leaving...)
08:44:21  * indexzeroquit (Quit: indexzero)
08:47:08  * DarkGodjoined
08:48:18  * indexzerojoined
08:51:55  * xmingquit (Changing host)
08:51:55  * xmingjoined
09:08:50  * kazuponquit (Remote host closed the connection)
09:16:32  * devurandomquit (Remote host closed the connection)
09:21:49  * devurandomjoined
09:59:07  * indexzeroquit (Quit: indexzero)
10:27:00  * devurandomquit (Remote host closed the connection)
10:32:09  * devurandomjoined
12:32:31  * Golesjoined
12:34:08  * devurandomquit (Remote host closed the connection)
12:38:04  * devurandomjoined
12:38:39  * devurandomquit (Remote host closed the connection)
12:42:10  * devurandomjoined
12:47:22  * mirkokjoined
12:49:25  * Golesquit (Quit: Computer has gone to sleep.)
12:50:47  * Golesjoined
12:53:13  * devurandomquit (Remote host closed the connection)
12:53:20  * mirkokquit (Quit: mirkok)
12:56:59  * devurandomjoined
13:03:45  * mirkokjoined
13:04:51  * Golesquit (Ping timeout: 252 seconds)
13:05:46  * Golesjoined
13:06:48  * mirkokquit (Quit: mirkok)
13:06:57  * mirkokjoined
14:10:34  * mmalecki[zzz]changed nick to mmalecki
14:58:00  * indexzerojoined
15:11:26  * kazuponjoined
15:23:43  * joshthecoderjoined
15:28:45  * bakinsjoined
15:32:45  * mirkokquit (Quit: mirkok)
15:33:38  * kazuponquit (Remote host closed the connection)
15:37:16  * bakinsquit (Quit: bakins)
15:38:05  * mirkokjoined
15:48:22  * kazuponjoined
15:48:31  * kazuponquit (Remote host closed the connection)
15:48:48  * mmaleckichanged nick to mmalecki[out]
16:29:03  * indexzerochanged nick to indexzero[brb
16:29:18  * indexzero[brbchanged nick to indexzero[brb-co
16:29:27  * indexzero[brb-cochanged nick to indexzero[brb]
16:46:09  * bakinsjoined
17:04:50  * indexzero[brb]changed nick to indexzero
17:15:06  * Golesquit (Ping timeout: 264 seconds)
17:16:08  * joshthecoderquit (Quit: Leaving...)
17:18:19  * bakinsquit (Quit: bakins)
17:26:12  * Golesjoined
17:29:00  * Golesquit (Client Quit)
18:16:30  * DarkGodquit (Ping timeout: 250 seconds)
18:22:06  * Golesjoined
18:44:44  * bakinsjoined
19:08:32  * DarkGodjoined
19:30:09  * travis-cijoined
19:30:09  <travis-ci>[travis-ci] luvit/luvit#546 (master - d200246 : Tim Caswell): The build passed.
19:30:09  <travis-ci>[travis-ci] Change view : https://github.com/luvit/luvit/compare/4db42e888e9b...d2002465b3d1
19:30:09  <travis-ci>[travis-ci] Build details : http://travis-ci.org/luvit/luvit/builds/3745391
19:30:09  * travis-cipart
19:40:15  * Golesquit (Quit: Computer has gone to sleep.)
19:44:06  * bakinsquit (Quit: bakins)
19:57:47  * hasufelljoined
19:58:24  <hasufell>bjorn: oh, hanging out in luvit too? :o
20:08:21  * Golesjoined
20:09:12  <creationix>hasufell, hi
20:09:22  <hasufell>yo
20:09:29  <creationix>so what this I hear about gentoo?
20:10:02  <hasufell>https://bugs.gentoo.org/show_bug.cgi?id=406403
20:10:27  <hasufell>I gave up on unbundling uv, too fragile.
20:11:18  <hasufell>is it correct that all libraries are unmodified?
20:11:58  <creationix>so libuv does have "stable" releases of sorts
20:12:05  <creationix>the version tags that match the stable nodejs releases
20:12:23  <creationix>and luvit builds against the 0.8.x series currently I believe
20:12:32  <creationix>does the nodejs package for gentoo bundle libuv?
20:13:01  <creationix>also the 0.5.0 release of luvit is anchient
20:13:11  <creationix>we *really* need a newer release
20:13:17  <creationix>especially if distros are going to bundle it
20:13:25  <hasufell>bundle?
20:13:29  <hasufell>it's called package :P
20:13:37  <creationix>well I guess with gentoo, it's not bundling
20:13:53  <hasufell>not sure about nodejs, gonna build it first
20:14:14  <hasufell>bundling is discouraged in gentoo, that's why
20:14:21  <creationix>also, luvit depends on a couple custom luajit build flags
20:14:25  <hasufell>for various reasons, especially security fixing
20:14:37  <creationix>in particular the 5.1 backports
20:14:42  * Golesquit (Quit: Computer has gone to sleep.)
20:14:53  <creationix>if you use stock luajit, the process.env table won't be enumerable
20:15:09  <creationix>(which isn't a terrible problem, I doubt that's used for anything other than interactive debugging)
20:15:42  <creationix>I understand why distros don't want to have static deps in packages
20:15:50  <creationix>but some libraries are too new and changing to be shared sanely
20:16:17  <creationix>I think libuv would be good enough if we stuck to the versions released with node stable releases
20:16:26  <creationix>and openssl can obviously be external
20:16:35  <creationix>http_parser can be external, but it's super tiny
20:16:58  <hasufell>what build flags are you talking about, do you see anything here? http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-lang/luajit/?hideattic=1&sortby=log also look at the files subdir where the patches are
20:17:51  <creationix>looks like it's just this flag now https://github.com/luvit/luvit/blob/master/Makefile#L67
20:18:36  <creationix>also luajit 2.0 final it out, we should definitely update to that if possible
20:19:15  <hasufell>well, lua-5.2 is hardmasked here, so I only support 5.1.5 max anyway
20:19:40  <hasufell>hardmasked means something like "testing testing"
20:20:03  <creationix>the 5.2 compat flag in luajit is all 5.2 features that can be implemented without breaking 5.1 compat
20:20:08  <creationix>so it's a safe flag to enable
20:20:14  <creationix>but most distros don't since it's not the default
20:20:25  <hasufell>well, easy for us, we can provide a useflag for that
20:20:50  <creationix>right, but if you build luajit as a shared library, it can only be built with or without the flag, not both
20:21:14  <creationix>but like I said, it should be a safe flag
20:21:21  <creationix>and luvit only weakly depends on it
20:21:24  <creationix>it's a very nice to have
20:21:43  <hasufell>for which luajit versions does that apply?
20:21:54  <hasufell>we have 2.0.0_beta7 up to beta_10
20:22:00  <hasufell>is it present in all of them?
20:22:49  * Golesjoined
20:22:51  <creationix>I believe so
20:23:12  <creationix>I've had it for over a year
20:23:17  <creationix>not sure when beta7 came out
20:24:56  <hasufell>/usr/include/node/uv.h <- seems nodejs does bundle uv
20:25:53  <creationix>I know upstream does
20:26:04  <creationix>I've never looked at the gentoo package for it though
20:26:32  <hasufell>well, the more packages use it, the better unbundling is
20:26:44  <creationix>right, libuv was written specifically for nodejs
20:26:48  <creationix>rust lang uses it
20:26:51  <creationix>as does luvit
20:26:56  <creationix>not sure what else that's popular
20:28:15  <hasufell>Apache-2.0 MIT <- is that correct or did I miss a license?
20:28:20  <creationix>my luv (stock lua library) uses it
20:28:35  <creationix>luvit itself it apache, yes and libuv is mit
20:28:54  * Golesquit (Quit: Computer has gone to sleep.)
20:29:25  <hasufell>well, if you are about to cut a new release I might just wait for it and add that useflag to luajit then
20:29:38  <creationix>yajl is ISC
20:29:58  <creationix>yeah, I think I will cut a release
20:30:01  * Golesjoined
20:30:05  <creationix>and try to get this in archlinux too
20:30:07  <hasufell>creationix: yeah, but we don't use the code
20:30:23  <creationix>yajl is dynamic link?
20:30:26  <hasufell>yes
20:30:56  <creationix>ok, so you want to bundle libuv and http_parser for now then?
20:31:09  <hasufell>yeah, too lazy to unbundle them
20:31:21  <hasufell>libuv was horrible the last time I worked on luvit-0.3
20:31:37  <hasufell>that's probably why I lost interest, but users seem to be interested in luvit
20:31:49  <creationix>cool
20:32:13  <creationix>rphillips, philips_, I'm going to cut a release. Should it be 0.6.0 since it's been so long since the 0.5 release?
20:32:37  <hasufell>also... bundling zlib is usually a bad idea. zlib was subject to many security vulnerabilities... fixing that is easy if it's a shared lib
20:32:50  <creationix>right
20:33:02  <creationix>the reason luvit bundled everything was so that it was easier for people to build
20:33:09  <creationix>with build recipied like ebuilds that's not a problem
20:33:13  <creationix>*recipies
20:33:16  <hasufell>yeah, I don't mind as long as there is an option to turn it off
20:33:35  <rphillips>creationix: 0.6.0 seems good
20:37:27  <hasufell>creationix: btw... it's possible to call 3rd party Makefiles from within cmake
20:37:41  <creationix>true
20:37:59  <hasufell>so the top build system being cmake and the other ones plain Makefile should work imo
20:38:16  <creationix>I just don't have time or interest to muck with build systems
20:38:21  <hasufell>but converting could take a few days
20:38:34  <creationix>yeah, we had someone converting everything to cmake already
20:38:42  <creationix>not sure what happened to that effort
20:39:28  <hasufell>well, imo plain Makefiles are ok if they are properly coded
20:39:37  <hasufell>most of the time they are not^^
20:39:56  <hasufell>because you cannot have everything in scope a distribution needs/wants
20:40:14  <hasufell>but if you want to ship for windows, autotools is probably not an option
20:41:45  <creationix>right, windows + linux distros is hard
20:52:21  <creationix>heh, I need to install libyajl-dev in order to use system yajl...
20:52:23  <creationix>duh
20:55:48  <hasufell>weird binary distros :P
20:59:43  <creationix>do you use luvit from git or the tarball I cut with releases
20:59:52  <hasufell>tarball
21:00:03  <creationix>that way people don't need git to build luvit
21:00:29  <creationix>the problem with the tarball is I have to include all bundled libraries
21:00:40  <creationix>and including openssl is wasteful if you're not going to use it
21:02:44  <creationix>maybe I could make two tarballs, one with just libuv bundled and one with everything
21:03:13  <hasufell>well, http-parser is still needed too
21:03:37  <creationix>right and that
21:12:28  <creationix>hmm, deps/luacrypto, I wonder what exactly that is
21:12:56  <hasufell>https://github.com/mkottman/luacrypto
21:13:20  <creationix>so it's just openssl bindings for lua I guess
21:13:30  <creationix>I guess that's fine to bundle
21:15:26  <creationix>I wonder what license that is. It looks very MIT/BSD/ISC style http://luacrypto.luaforge.net/license.html
21:15:31  <philips_>creationix: <3 sure :)
21:16:06  <creationix>philips_, rphillips I'm going to update libuv to the latest in the 0.8 branch and http_parser to the latest before the ABI broke last week
21:16:12  <philips_>creationix: hasufell : We depend on luvit having a gyp file so we will be maintaining it at least
21:16:21  <creationix>hopefully that doesn't break the gyp system
21:16:23  <philips_>hasufell: for github.com/racker/virgo
21:17:36  <philips_>creationix: luacrypto provides the lower level rsa operations. The openssl tls bindings are internal to luvit howerver
21:17:41  <philips_>creationix: _crypto is the module
21:17:54  <creationix>that's right. I remember now
21:20:55  * kostiljoined
21:27:31  <kostil>Hi all, I had a question on loading dynamic lua modules with luvit win32 binary. I have a dll module build with vs2010 linked with lua 5.1.4. I am trying to load it at startup of luvit script, but it hangs inside luaopen_ function in the dll itself. However, when using with lua.exe this module loads and works correctly, is luvit w32 linked with a newer version of LUA which might cause this issue?
21:34:24  <creationix>no idea about windows
21:34:35  <creationix>I do know that luvit only supports modules that return their exports
21:37:57  <kostil>creationix, could you please explain what it means by returning their exports? is that a normal way of writing modules for LUA?
21:39:23  <creationix>there are multiple ways
21:39:26  <creationix>you can return a table
21:39:28  <creationix>and that is your exports
21:39:41  <creationix>(and the only way in lua 5.2 I believe)
21:40:25  <kostil>is luvat compiled with 5.2
21:40:26  <kostil>?
21:41:25  <creationix>no, by default it's lua 5.1 with 52 compat flags
21:41:34  <creationix>but that's not why the module system is the way it is
21:41:56  <creationix>I decided the module system should work this way, and then by coincidence, 5.2 made the same change
21:44:21  <kostil>from process explorer I see that when I load the module, its stuck at somewhere in mutex but initiated from function luaF_newproto at lua5.1.dll. do you by any change know what luaF_newproto does?
21:50:32  <kostil>one more question actually, I read the following insturctions for building on windows (https://github.com/luvit/luvit/wiki/Build) but I do not see setup.py in gyp folder and i just got the code from github today? could you point in right direction for building on windows?
21:54:44  * Golesquit (Quit: Computer has gone to sleep.)
21:56:09  <creationix>kostil, I've never built on windows personally, I'm afraid I'm not much help there
21:58:59  <kostil>alright, thanks anyway. creationix, maybe you know the other thing then. again looking at process explorer basically a tool for windows processes, I see that lock and call twice to luaopen_ function of my module. how does luvit load modules, using which thread to be exact? it is possible that its trying to load the module from two separate threads simultaniously?
21:59:31  <creationix>look at the native example in the luvit source
21:59:37  <creationix>(in the examples folder)
21:59:51  <creationix>luvit expects a single return value to be the value of the module
22:00:03  <creationix>and the C function needs to match the filename
22:01:22  <kostil>I am afraid that isn't a problem, I did look in there already. luaopen function is indeed called. I would imagine if it did return something that luvit doesn't support, it would either exit and display an error, but would still proceed right?
22:01:29  <kostil>in my case it just hangs within that module load
22:01:51  <creationix>I do know that luajit has issues loading binary modules on windows if it's statically linked
22:01:54  <creationix>that may be the problem
22:02:00  <creationix>I say some notes on the luajit website
22:02:04  <creationix>(or are you using stock lua)
22:02:28  <kostil>the module is not statically linked
22:02:34  <creationix>no, but luajit is
22:02:38  <creationix>and that's the problem
22:02:50  <kostil>ah
22:03:13  <kostil>so I can try to link statically and try loading again, do you think?
22:04:35  <creationix>so either you link your module statically with luvit itself (a custom luvit build) or build luvit with a shared luajit library somehow
22:04:43  <creationix>at least, that's what I think
22:04:51  <creationix>I haven't actually tried
22:06:13  <kostil>i see, now I just need to find someone to help me built it on windows
22:07:59  <creationix>"Since Windows symbols are bound to a specific DLL name, you need to link to the lua51.dll created by the LuaJIT build (do not rename the DLL). You may link LuaJIT statically on Windows only if you don't intend to load Lua/C modules at runtime."
22:08:21  <creationix>I think we link luajit statically and hence you can't load C modules at runtime
22:08:51  <creationix>that quote is from http://luajit.org/install.html
22:09:28  <kostil>i see, so a dynamic link build of luvit might actually solve this issue
22:11:18  * hasufellquit (Quit: Verlassend)
22:13:25  <kostil>do you know who create the win32 binary that is located on project page?
22:28:02  <creationix>either rphillips or philips_
22:28:34  <philips_>rje can do it if he wants :) :) :)
22:29:07  <kostil>:)
22:29:23  <philips_>kostil: I can build it to, I have access to a winserver machine
22:29:44  <kostil>well, whoever done it, could that someone be kind enough to give me the solution file?
22:30:29  <kostil>philips: that would be great and all, but I have a specific issues and need to build luvit with dynamically linked luajit
22:30:45  <philips_>kostil: Oh :-/
22:31:28  <kostil>I would rather do it myself not to take anyone's time, plus it will help me understand all of it better. solution file would be of great help though
22:31:41  <kostil>at least I would know all the build events, etc
22:32:42  <rje>sure, i can do it
22:32:47  <rje>philips_: ^^
22:33:10  <rje>er,nm
22:33:27  <rje>kostil: if you need help,ive gotten it working
22:33:28  <philips_>rje: nm?
22:33:41  <kostil>I do need help
22:33:53  <kostil>you've got working what? windows build?
22:34:01  <kostil>or the problem I described earlier?
22:34:40  <rje>philips_: never mind me building it if that won't help him, but i can try to help him sort out his issue
22:35:11  <rje>kostil: i have a working build with vc 2010, 2010 express and 2012
22:35:23  <kostil>the thing is is that I really don't know if that would fix the issue or not
22:35:32  <kostil>workign with vc 2010 prof
22:35:46  <kostil>well, I mean i have that one
22:36:00  * rjereads back to find your issue
22:36:14  <creationix>the issue is loading a C module from luvit
22:36:56  <kostil>yes
22:37:03  <rje>using the ffi?
22:37:08  <creationix>no, using normal require
22:37:10  <kostil>no, using loadlib
22:37:30  <kostil>well yea, require
22:38:02  <creationix>on the luajit embedding guide...
22:38:04  <creationix>"Since Windows symbols are bound to a specific DLL name, you need to link to the lua51.dll created by the LuaJIT build (do not rename the DLL). You may link LuaJIT statically on Windows only if you don't intend to load Lua/C modules at runtime."
22:38:54  <creationix>my guess is we're statically linking luajit when building for windows and so we can't load C modules at runtime
22:42:44  * mirkokquit (Quit: mirkok)
22:46:27  <rje>creationix: that sounds like a problem then.:/
22:47:43  <creationix>on the bright side, windows allows bundling the dll in the same folder as the luvit.exe binary
22:47:50  <creationix>we just need to build it that way
22:54:12  <creationix>he goes hoping I didn't break anything...
22:54:25  <creationix>updated key deps to latest stable versions and tagged at 0.6.0
22:54:36  <creationix>I'm building binaries for linux versions now...
22:55:25  <creationix>should I build the binaries with bundled openssl, zlib, and luajit?
22:55:28  <creationix>or shared
22:57:32  * travis-cijoined
22:57:32  <travis-ci>[travis-ci] luvit/luvit#547 (master - 5d14efb : Tim Caswell): The build passed.
22:57:32  <travis-ci>[travis-ci] Change view : https://github.com/luvit/luvit/compare/d2002465b3d1...5d14efb22c76
22:57:32  <travis-ci>[travis-ci] Build details : http://travis-ci.org/luvit/luvit/builds/3748564
22:57:32  * travis-cipart
22:57:36  <creationix>shared means security fixes for openssl and friends can happen without updating luvit itself
22:57:43  <creationix>but it also means they need those installed
22:58:01  <creationix>I think I'll bundle yajl and luajit since most systems don't have those out of the box
22:58:05  <creationix>and share openssl and zlib
23:00:27  <philips_>rje: wow, that static linking problem is going to bite the agent too
23:01:12  <philips_>rje: something to figure out :-/
23:05:29  * indexzeroquit (Quit: indexzero)
23:10:27  * coolaj86quit (Ping timeout: 260 seconds)
23:11:30  * coolaj86joined
23:15:19  <rje>philips_: we're not using dynamic linking?
23:15:38  <philips_>rje: on linux we are statically linking everything
23:15:47  <philips_>rje: On Windows I thought we were but I might be wrong
23:16:35  <rje>philips_: on windoed the libluajit.dll gets built and it seems to get used as i was having trouble writing to it.
23:16:50  <philips_>rje; ok, cool :)
23:18:55  <kostil>indeed there is a library along with the latest build for windows, then maybe the problem I have doesn't have to do with luajit?
23:19:36  <rje>philips_: on windows libluajit.dll is required for luvit to run
23:19:54  <philips_>good to know
23:21:14  <rje>static libs are always friend and foe, the guarantee running on a variety of platforms but carry the issues they were built with
23:21:55  <rje>kostil: i'm not sure how the luvit loads external dlls
23:22:30  <kostil>rje, do you have a solution file for vs 2010 that I can adapt to build luvit?
23:23:26  <rje>kostil: does your lua not build the solution file when you run configure?
23:23:44  <rje>kostil: s/lua/luvit/
23:24:01  <kostil>I was using the following, but the files are missing from the master branch, hold up
23:24:14  <kostil>https://github.com/luvit/luvit/wiki/Build
23:24:39  <kostil>there is no setup.py file from step 4
23:25:15  <kostil>maybe those aren't the steps?
23:25:59  <rje>kostil: you shouldn't need it. i don't remember doing that
23:26:20  <kostil>so what do I need to run? python ./configure?
23:26:25  <rje>kostil: i got python, then msysgit, then ran configure
23:26:46  <kostil>i get this
23:26:46  <kostil>Traceback (most recent call last):
23:27:02  <kostil>ImportError: No module named gyp
23:27:05  * indexzerojoined
23:27:07  <kostil>line 16 of configure
23:27:24  <rje>when you did a checkout, did you do it recursive?
23:27:37  <rje>sorry, a clone recursive
23:27:49  <kostil>i did it from github web
23:27:50  <kostil>as zip
23:28:59  <rje>if you can, try it using the shell from msysgit from here http://code.google.com/p/msysgit/downloads/list?q=net+installer
23:29:14  <kostil>ok, let me try
23:30:04  <rje>then as long as python is in your path you can just run ./configure after starting a shell and running msys.bat
23:30:32  <kostil>ok, downloading msysgit now, will let you know in a few
23:31:14  <rje>i'll be here, just ping me so the bells ring :)
23:44:47  <kostil>rje: same thing
23:46:28  <rje>kostil: ok, so you cloned the repository? git clone http://github.com/luvit/luvit
23:46:35  <kostil>yes
23:46:39  <rje>kostil: ok, so you cloned the repository? git clone http://github.com/luvit/luvit --recursive
23:46:56  <kostil>oh, no...:) hold please
23:47:06  <rje>that's ok, we can get it
23:47:20  <rje>cd into your cloned repo
23:47:40  <rje>git submodule init
23:47:44  <rje>git submodule sync
23:47:58  <rje>those will do the same thing as a recursive
23:48:20  <kostil>doing it now
23:49:44  <kostil>done
23:49:47  <kostil>run configure?
23:49:52  <rje>yup
23:50:32  <kostil>error but different, hold up
23:52:03  <kostil>actually wait, it was an old shell and git was not in the path
23:52:44  <rje>from a shell, run c:\msysgit\msys.bat
23:52:46  <kostil>ok, so it finished with works "Done! now run python build.py to build"
23:53:04  <rje>there should be a sln file now
23:53:24  <kostil>yes, I see it
23:53:30  <rje>:)
23:53:32  <kostil>I will try build it
23:53:35  <kostil>thanks rje
23:53:52  <kostil>let me see what will happen
23:54:07  <rje>you can build itin the gui or on the command line with: tools/build.py build
23:54:28  <kostil>solution to build "all" or "luvit"?
23:54:37  <rje>i build luvit
23:54:49  <rje>set that as the default project
23:57:15  <kostil>errors in libluajit, banch of unresolved externals for lua
23:58:05  <kostil>any paths I need to set?
23:58:34  <rje>shouldn't be