00:49:35  * aliem_quit (Remote host closed the connection)
01:04:43  * xmingquit (Ping timeout: 248 seconds)
01:05:17  * xmingjoined
01:06:29  * xmingquit (Client Quit)
03:32:12  * dvv-androidjoined
05:26:25  * tokyodanjoined
05:33:49  <levi>Huh, no wonder it didn't work without chunking.
05:34:23  <levi>It's not setting the encoding to chunked and it's not setting a Content-Length header either when it sends the c-frame.
05:41:10  <levi>o-frame, I mean.
06:20:48  * aliemjoined
06:23:40  * xmingjoined
06:31:09  * tokyodanquit (Quit: tokyodan)
07:40:04  * mmaleckijoined
09:36:37  * tim_smartquit (Quit: leaving)
09:36:47  * tim_smartjoined
09:36:49  * dvvjoined
09:37:32  * tim_smartchanged nick to tim_smart|away
09:44:25  * spionLjoined
11:07:01  * dvv-androidquit (Ping timeout: 276 seconds)
12:24:34  * dvv-androidjoined
12:32:10  * dvv-androidquit (Ping timeout: 276 seconds)
12:46:53  * mmaleckiquit (Quit: leaving)
13:12:08  * neomantra1joined
14:37:21  * mmaleckijoined
15:33:35  * mmaleckiquit (Read error: Connection reset by peer)
15:46:03  * mmaleckijoined
16:26:35  <CIA-113>Ryan Phillips features/improve_http_module * ra006444 / (lib/luvit/http.lua lib/luvit/net.lua): http: changes part 3 - http://git.io/rDREeA
16:42:32  * TheJHjoined
16:42:55  * neomantra1quit (Quit: Leaving.)
17:16:37  * 16SABGXFTjoined
17:17:10  * arek_deepinitjoined
17:26:22  * mmaleckiquit (Ping timeout: 245 seconds)
17:30:20  * mmaleckijoined
17:37:05  * arek_deepinitquit (Read error: Connection reset by peer)
17:38:37  <pquerna>https://github.com/luvit/luvit/compare/master...features/improve_http_module
17:46:08  * spionLquit (Ping timeout: 246 seconds)
17:46:41  <levi>Do most users of luvit and node http modules just run in chunked encoding mode most of the time?
17:47:09  <pquerna>yes
17:49:40  <levi>dvv had one of his sockjs transports running without chunked mode, and in my attempts to make it run correctly it looked like the standard API was very helpful if you were running in auto-chunked-mode but happily let you shoot your foot if you turned auto-chunked-mode off.
17:50:30  * `3rdEdenjoined
17:50:49  <levi>i.e., if you happen to do something that flushes your headers before you get content-length out and you're not running in auto-chunked-mode, you're screwed.
17:52:26  <pquerna>the old ccode was very... fragile and dind't auto-chunk when it needed to always
17:52:38  <pquerna>the newer stuff rphillips is goign through should make it more solid
17:52:57  <levi>Auto-chunking worked fine, dvv just explicitly turned it off.
18:04:17  * mmaleckiquit (Ping timeout: 245 seconds)
18:30:59  * `3rdEdenquit (Quit: Leaving...)
18:40:30  * dvv-androidjoined
18:59:25  * arek_deepinitjoined
19:19:43  <CIA-113>Ryan Phillips features/improve_http_module * rfe61ead / lib/luvit/http.lua : http: first working client. - fixes some syntax errors - http://git.io/7-43Mw
19:20:36  <rphillips>sweet
19:22:09  * mmaleckijoined
19:23:08  <CIA-113>Ryan Phillips features/improve_http_module * rdc82393 / lib/luvit/http.lua : http: remove a few debug statements - http://git.io/_LatXQ
19:32:10  <xming>any idea what might causing this? -> uv.lua:269: Unknown stream file type 0
19:35:45  <rphillips>hmm
19:36:37  * dvv-androidquit (Ping timeout: 276 seconds)
19:36:51  <xming>it happens only when I am including uv.a as obj instead of linking to, it seems
19:39:05  <xming>or not
19:39:46  <rphillips>the error gets displayed when we create the stdio/stderr streams
19:40:03  <xming>with my current build system
19:40:11  <xming>linking to system libuv works
19:40:26  <rphillips>probably missing some commandline defines
19:40:54  <xming>including my own uv.a fails (vanilla uv build), including the uv.a from vanilla luvit also fails
19:41:16  <xming>it's must be a combination of things
19:41:26  <xming>I have been fighting to this for hours
19:42:02  <xming>rphillips: okay I will look for -D
19:42:25  <xming>besides this, I have working libuv cmake
19:42:42  <rphillips>coo
19:42:44  <xming>still todos are, lucrypt and luajit
19:42:52  <xming>luajit is complex
19:42:54  <rphillips>luajit was a PITA
19:46:53  <CIA-113>Ryan Phillips features/improve_http_module * r364d996 / lib/luvit/http.lua : http: add missing ClientRequest:_implicitHeader - http://git.io/jZ1Z2A
19:47:21  <xming>rphillips: you think it's defines with luvit? Or with other deps?
19:48:12  <rphillips>i'll check
19:48:49  <xming>if I include system libuv (instead of linking to it) it works too
19:49:16  <xming>so libuv canilla and build by luvit work with vanilla luvit but not mine
19:49:33  <xming>only the system lib works with mine :/
19:49:57  * xmingchecks how the system libua is built
19:50:16  <rphillips>uv_guess_handle() is the call
19:50:25  <rphillips>are you including unix/tty.c?
19:50:27  <rphillips>in libuv?
19:51:15  <xming>yeap
19:52:42  <pquerna>rphillips: so, building a centos VM now to do RPMs
19:52:48  <rphillips>nice
19:52:57  <pquerna>rphillips: anything i can help with until thats ready?
19:53:30  <rphillips>i'm going to start working on unit tests for the http client... I could use your help on the server side http code
19:53:59  <rphillips>there is also a concept of an Agent class within the http module... might be worth implementing
19:54:25  <pquerna>agent is for connection pooling
19:54:30  <pquerna>i actually don't like the node impl there
19:54:31  <pquerna>:-/
19:54:45  <xming>system libuv has -fno-strict-aliasing
19:54:46  <rphillips>then let's skip that for now... server side http would be helpful
19:54:57  <pquerna>okay, is it just porting the node stuff?
19:55:06  <rphillips>right
19:55:12  <rphillips>should be pretty straight forward
19:55:12  <pquerna>okay, will look
19:56:10  <rphillips>from a quick test, the client appears to be fast :)
20:01:13  <rphillips>17 milliseconds for a GET w/ DNS lookup to google
20:01:58  * arek_deepinitquit (Ping timeout: 276 seconds)
20:03:55  * mmaleckiquit (Ping timeout: 264 seconds)
20:04:51  <CIA-113>Ryan Phillips features/improve_http_module * r1cd1587 / lib/luvit/http.lua : http: add url parsing if options are a string - http://git.io/1HBAMA
20:17:00  * arek_deepinitjoined
20:21:43  <xming>rphillips: any idea? http://pastebin.com/MQMqngHR
20:25:19  <rphillips>you printing out what you get for the handle_type
20:25:29  <rphillips>in utils.c luv_handle_type_to_string
20:25:36  <rphillips>or the caller of that function
20:26:01  <rphillips>xming: are you on linux?
20:26:22  <xming>yes
20:26:44  <xming>I am just going insane because to 2 libs are basically the same
20:26:58  <xming>compiled with the same flags
20:30:33  <xming>what is type? An int?
20:31:00  <rphillips>yeah
20:31:26  <rphillips>uv.lua line 256 and 238
20:31:31  <rphillips>have the conversion to a string
20:31:42  <rphillips>you could do a print there too and see what you are getting back
20:32:11  <xming>I get 12
20:33:07  <rphillips>hmm
20:33:14  <rphillips>UV_ARES_EVENT
20:33:45  <xming>or that switch statement is ordered :D
20:33:57  <xming>I was searching in the uv's *h
20:34:28  <xming>there shouldn't be are events, should there? No DNS involved
20:34:36  <xming>s/are/ares
20:34:44  <rphillips>no. that is setting up the TTYs
20:34:51  <rphillips>shouldn't be there
20:35:28  <xming>hmm
20:35:32  * arek_deepinitquit (Quit: Konversation terminated!)
20:35:43  <xming>my livit and uv are not compatible
20:36:14  <xming>if this is true then vanilla luvit isn't compatible with my system libuv
20:36:17  <xming>I need to test that
20:38:55  <xming>haha
20:38:56  <xming>indeed
20:39:12  <xming>luvit can't link to my system libuv
20:39:19  <xming>well it can
20:39:23  <xming>but same error
20:40:28  <xming>so the conclusion
20:40:44  <xming>my cmake build is only compatible with my system libuv
20:41:11  <xming>luvit is compatible with all libuv except my system one
20:42:36  <creationix>xming: libuv has changed a bit recently
20:42:50  <creationix>I don't think luvit even builds against latest libuv
20:43:09  <xming>it does
20:43:25  <xming>creationix: I wil ltry earlierversion
20:43:32  <xming>creationix: but the strange thing is
20:45:28  * tim_smart|awaychanged nick to tim_smart
20:45:31  <xming>luvit vanilla builds with the git submodule (is libuv the latest there) and runs fine
20:45:51  <xming>but luvit vanilla doesn't run fine when I link it to my system libuv
20:46:06  <xming>and vice versa with my cmake luvit
20:46:46  <xming>same source, same libs, just compiled differently
20:55:18  <pquerna>creationix> I don't think luvit even builds against latest libuv <- it crashes afaik due to the ref count cahgnes (?)
20:55:27  <pquerna>i know philips was working on it
20:55:49  <creationix>pquerna: oh, cool, I didn't know someone was working on that
20:56:19  * MaMosjoined
20:56:28  * MaMospart
20:58:12  <rphillips>i don't think he is actively working it
20:59:17  <xming>which is the latest libuv that works?
21:14:08  * 16SABGXFTquit (Quit: Leaving.)
21:34:15  * `3rdEdenjoined
21:36:52  <creationix>xming: the one in the luvit submodule should work
21:37:00  <creationix>submodules point to a specific revision
21:53:15  * kevwiljoined
22:21:31  * kevwilquit (Ping timeout: 244 seconds)
22:22:53  * kevwiljoined
22:29:49  * kevwilquit (Quit: WeeChat 0.3.8)
22:35:38  <xming>the tarball from my system lib works
22:35:43  <xming>now I get it
22:36:12  <levi>What was the issue?
22:36:36  <xming>I am guessing that uv vhanged a lot, especially in the .h
22:37:01  <xming>somehow it's picking the system .h
22:37:15  <xming>I will investigate in the weekend
22:38:42  <xming>so this is almost sorted
22:38:53  <xming>my next big headache is luajit
22:40:48  <levi>Cool, the string library does indeed set the metatable on strings so that method lookup looks in the string library when you call methods on strings.
22:41:25  <levi>It only works on variables holding strings, not string literals.
22:44:19  <levi>Unfortunatly, the same doesn't happen with tables. This makes sense, since a table only gets one metatable, and you're probably going to use it for class inheritance.
23:12:10  * `3rdEdenquit (Quit: Linkinus - http://linkinus.com)
23:43:56  * AvianFluquit (Ping timeout: 240 seconds)
23:51:16  * tim_smartchanged nick to tim_smart|away