00:00:01  * ircretaryquit (Remote host closed the connection)
00:00:11  * ircretaryjoined
00:19:01  * chris_99joined
00:21:34  * c4milojoined
00:26:42  * c4miloquit (Ping timeout: 256 seconds)
00:27:03  * creationixjoined
00:29:45  * pgicxplzsjoined
00:31:58  * warehouse13quit (Ping timeout: 264 seconds)
00:34:01  <trevnorris>saghul: ping
00:36:00  * thlorenzquit (Remote host closed the connection)
00:48:19  * iamstefquit (Ping timeout: 272 seconds)
00:48:58  * eugeneware_quit (Ping timeout: 272 seconds)
00:49:42  * qard_quit (Ping timeout: 250 seconds)
00:49:47  * eugeneware_joined
00:50:14  * indexzero_quit (Ping timeout: 272 seconds)
00:50:28  * qardjoined
00:50:34  * indexzero__joined
00:51:18  * iamstef_joined
00:59:10  * thlorenzjoined
01:02:44  * kazuponjoined
01:04:06  * thlorenzquit (Ping timeout: 256 seconds)
01:08:59  * Fishrock123quit (Remote host closed the connection)
01:11:30  * abraxas_joined
01:16:05  * abraxas_quit (Ping timeout: 264 seconds)
01:29:23  * avalanche123quit (Remote host closed the connection)
01:38:12  * abraxas_joined
01:39:06  * avalanche123joined
01:44:06  * thlorenzjoined
01:46:46  * dap_1quit (Quit: Leaving.)
01:48:39  * kazupon_joined
01:51:31  * dshaw_quit (Quit: Leaving.)
01:52:22  * kazuponquit (Ping timeout: 264 seconds)
02:02:08  * avalanche123quit (Remote host closed the connection)
02:06:47  * avalanche123joined
02:07:23  * jgiquit (Quit: jgi)
02:10:40  * c4milojoined
02:11:07  * avalanche123quit (Ping timeout: 245 seconds)
02:15:25  * c4miloquit (Ping timeout: 244 seconds)
02:25:18  * avalanche123joined
02:33:40  * Fishrock123joined
02:36:27  * avalanche123quit (Remote host closed the connection)
02:42:22  * qardquit (Quit: leaving)
02:51:02  * Fishrockjoined
02:51:10  * Fishrock123quit (Ping timeout: 264 seconds)
02:53:50  * hueniversequit (Read error: Connection reset by peer)
02:54:40  * Fishrockquit (Client Quit)
02:56:43  * chris_99quit (Quit: Ex-Chat)
03:21:00  * hueniversejoined
03:32:31  * kazupon_quit (Remote host closed the connection)
03:36:29  * hueniversequit (Read error: Connection reset by peer)
03:36:57  * avalanche123joined
03:37:35  * sandr8joined
03:41:07  * avalanche123quit (Ping timeout: 245 seconds)
03:41:19  * kazuponjoined
03:59:33  * c4milojoined
04:03:57  * c4miloquit (Ping timeout: 240 seconds)
04:08:37  * pgicxplzsquit (Remote host closed the connection)
04:15:08  * nickleeflyjoined
04:16:51  * abraxas_quit (Remote host closed the connection)
04:25:16  * thlorenzquit (Remote host closed the connection)
04:27:50  * kazuponquit (Remote host closed the connection)
04:30:55  * thlorenzjoined
04:31:51  * thlorenzquit (Remote host closed the connection)
04:34:10  * inolen1quit (Ping timeout: 250 seconds)
04:38:37  * bradleymeckjoined
04:48:29  * AlexisMochaquit (Ping timeout: 264 seconds)
04:56:06  * bradleymeckquit (Ping timeout: 258 seconds)
04:56:16  <felipealmeida>hello
04:56:26  <felipealmeida>uv_run supports being called recursively?
04:56:37  <felipealmeida>uv_run(a) -> uv_run(a) ?
04:57:07  * bradleymeckjoined
05:01:45  * dshaw_joined
05:04:28  * thlorenzjoined
05:06:28  <Ralith>why would you do that
05:09:47  * thlorenzquit (Ping timeout: 264 seconds)
05:09:50  <felipealmeida>Ralith: I'm integrating libuv with EFL's mainloop
05:09:53  <felipealmeida>which supports this
05:10:09  <felipealmeida>and assumes it to be available
05:11:32  * dshaw_quit (Quit: Leaving.)
05:14:37  * AvianFluquit (Ping timeout: 240 seconds)
05:15:04  <felipealmeida>Ralith: does it support?
05:16:30  * dshaw_joined
05:16:42  * stagasquit (Ping timeout: 264 seconds)
05:23:39  * kazuponjoined
05:48:33  * c4milojoined
05:48:59  * seishunjoined
05:49:09  * abraxas_joined
05:50:19  * Alex7Komjoined
05:53:40  * c4miloquit (Ping timeout: 256 seconds)
06:17:46  * dshaw_quit (Quit: Leaving.)
06:19:59  * octetcloudquit (Ping timeout: 264 seconds)
06:24:09  * dshaw_joined
06:46:04  * brsonjoined
06:48:03  * Damn3d_quit (Ping timeout: 272 seconds)
06:49:14  * hueniversejoined
06:51:49  * Damn3djoined
06:51:49  * Damn3dquit (Changing host)
06:51:49  * Damn3djoined
06:53:29  * thlorenzjoined
06:58:10  * thlorenzquit (Ping timeout: 255 seconds)
06:59:33  * seishunquit (Ping timeout: 252 seconds)
07:00:16  * bajtosjoined
07:13:54  * kazuponquit (Remote host closed the connection)
07:15:23  * kazuponjoined
07:24:57  * avalanche123joined
07:29:53  * avalanche123quit (Ping timeout: 264 seconds)
07:32:18  * janjongboomjoined
07:35:43  * bradleymeckquit (Quit: bradleymeck)
07:37:19  * c4milojoined
07:37:23  * rmgquit (Remote host closed the connection)
07:38:45  * rmgjoined
07:42:16  * c4miloquit (Ping timeout: 255 seconds)
07:43:42  * rmgquit (Ping timeout: 264 seconds)
07:56:28  * brsonquit (Quit: leaving)
08:01:24  * kazuponquit (Remote host closed the connection)
08:06:07  * LOUDBOTquit (Ping timeout: 245 seconds)
08:10:14  * CAPSLOCKBOTquit (Ping timeout: 256 seconds)
08:10:48  <saghul>trevnorris: pong?
08:10:51  * CAPSLOCKBOTjoined
08:11:08  <saghul>felipealmeida: nope, it's not supported
08:12:01  * LOUDBOTjoined
08:15:30  * kellabytequit (Quit: Connection closed for inactivity)
08:17:27  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
08:26:41  * kazuponjoined
08:29:15  * SergeiRNDjoined
08:33:55  * dshaw_quit (Quit: Leaving.)
08:42:28  * thlorenzjoined
08:46:57  * thlorenzquit (Ping timeout: 245 seconds)
09:02:06  <txdv>yeah, why would you do that
09:04:29  <txdv>felipealmeida: can you point me out the source code where EFL assumes that?
09:04:36  <txdv>I want to know why this would beneficial
09:14:57  <saghul>txdv: FWIW, IIRC Qt's event loop also supports it (not sure why it is or isn't nice)
09:26:23  * c4milojoined
09:29:04  * janjongboomjoined
09:30:43  * c4miloquit (Ping timeout: 255 seconds)
09:31:52  <txdv>does that run block too?
09:55:44  <txdv>We need some input on why that might be good or bad
09:58:56  * stagasjoined
10:15:52  * abraxas_quit (Remote host closed the connection)
10:16:30  * abraxas_joined
10:20:37  * abraxas_quit (Ping timeout: 240 seconds)
10:27:22  * janjongboomquit (Ping timeout: 245 seconds)
10:28:39  * rmgjoined
10:28:43  * janjongboomjoined
10:31:17  * thlorenzjoined
10:32:51  * rendarjoined
10:33:29  * rmgquit (Ping timeout: 264 seconds)
10:35:31  * thlorenzquit (Ping timeout: 252 seconds)
10:52:39  * bajtosquit (Quit: bajtos)
10:54:34  * Left_Turnjoined
10:58:58  * chris_99joined
11:05:17  * SergeiRNDquit (Ping timeout: 264 seconds)
11:11:00  * kazuponquit (Remote host closed the connection)
11:15:15  * c4milojoined
11:20:04  * c4miloquit (Ping timeout: 256 seconds)
11:40:17  * SergeiRNDjoined
11:51:40  * Akagi201_quit
12:05:14  * abraxas_joined
12:07:54  * AlexisMochajoined
12:09:52  * abraxas_quit (Ping timeout: 245 seconds)
12:10:34  * bajtosjoined
12:20:05  * thlorenzjoined
12:24:34  * thlorenzquit (Ping timeout: 244 seconds)
12:34:39  * rendarquit (Quit: Leaving)
12:51:08  * avalanche123joined
12:56:01  * avalanche123quit (Ping timeout: 272 seconds)
13:04:04  * c4milojoined
13:05:43  * AvianFlujoined
13:09:19  * c4miloquit (Ping timeout: 272 seconds)
13:13:30  * c4milojoined
13:16:01  * txdv_quit (Read error: Connection reset by peer)
13:27:58  * bajtosquit (Quit: bajtos)
13:32:51  * rendarjoined
13:39:32  * kellabytejoined
13:40:26  * nickleeflyquit (Quit: Connection closed for inactivity)
13:53:09  * bradleymeckjoined
13:54:03  * abraxas_joined
13:58:48  * abraxas_quit (Ping timeout: 250 seconds)
14:08:42  * thlorenzjoined
14:11:53  * c4miloquit (Remote host closed the connection)
14:13:41  * thlorenzquit (Ping timeout: 264 seconds)
14:15:42  * c4milojoined
14:23:23  * thlorenzjoined
14:24:39  * lance|afkchanged nick to lanceball
14:30:12  * bradleymeckquit (Quit: bradleymeck)
14:36:49  * Fishrock123joined
14:41:46  * kazuponjoined
14:43:32  * c4miloquit (Remote host closed the connection)
14:43:45  * janjongboomquit (Ping timeout: 252 seconds)
14:43:52  * Left_Turnquit (Ping timeout: 250 seconds)
14:44:56  * janjongboomjoined
14:50:44  * SergeiRNDquit (Quit: Leaving.)
14:59:53  * chris_99quit (Ping timeout: 252 seconds)
15:02:30  * chris_99joined
15:07:05  * brsonjoined
15:10:51  * thlorenzquit (Remote host closed the connection)
15:12:21  * janjongboomquit (Quit: My MacBook has gone to sleep. ZZZzzz…)
15:21:24  * brsonquit (Quit: leaving)
15:23:02  * thlorenzjoined
15:26:47  * thlorenzquit (Remote host closed the connection)
15:31:52  * avalanche123joined
15:32:44  * avalanche123quit (Remote host closed the connection)
15:36:57  * thlorenzjoined
15:38:03  * bradleymeckjoined
15:42:21  * iamstef_changed nick to iamstef
15:48:28  * a_lequit (Remote host closed the connection)
15:49:05  * a_lejoined
15:53:31  * a_lequit (Ping timeout: 258 seconds)
16:03:50  * a_lejoined
16:08:17  * bajtosjoined
16:13:40  * SergeiRNDjoined
16:15:43  * chris_99quit (Ping timeout: 255 seconds)
16:25:04  * kazuponquit (Remote host closed the connection)
16:27:04  * kazuponjoined
16:28:26  * hueniversequit (Ping timeout: 244 seconds)
16:30:27  * Left_Turnjoined
16:32:12  * bajtosquit (Quit: bajtos)
16:32:15  * c4milojoined
16:33:26  * avalanche123joined
16:37:05  * c4miloquit (Ping timeout: 264 seconds)
16:37:59  * avalanche123quit (Ping timeout: 258 seconds)
16:46:59  * SergeiRNDquit (Quit: Leaving.)
17:00:30  * bajtosjoined
17:02:38  * seishunjoined
17:02:53  * octetcloudjoined
17:06:03  * chris_99joined
17:09:42  * bradleymeckquit (Quit: bradleymeck)
17:12:52  * c4milojoined
17:12:59  * kazuponquit (Remote host closed the connection)
17:13:22  * dshaw_joined
17:16:06  * thlorenz_joined
17:17:28  * c4miloquit (Ping timeout: 258 seconds)
17:22:30  * thlorenz_quit (Remote host closed the connection)
17:23:03  * thlorenz_joined
17:25:12  <a_le>pquerna: you around?
17:27:26  * thlorenz_quit (Ping timeout: 258 seconds)
17:32:23  * Ralithquit (Ping timeout: 240 seconds)
17:34:28  * pbunnyquit (Ping timeout: 255 seconds)
17:34:35  * dap_joined
17:46:52  * SergeiRNDjoined
17:50:28  * c4milojoined
18:04:29  * jgijoined
18:07:07  * rmgjoined
18:11:36  * a_lequit (Remote host closed the connection)
18:11:58  * a_lejoined
18:13:38  * a_lequit (Read error: Connection reset by peer)
18:14:20  * Ralithjoined
18:21:16  * AlexisMochaquit (Ping timeout: 255 seconds)
18:25:51  * a_lejoined
18:34:49  * Alex7Komquit
18:36:47  * qardjoined
18:38:07  * octetcloudquit (Ping timeout: 244 seconds)
18:40:29  * octetcloudjoined
18:44:33  * dshaw_quit (Quit: Leaving.)
18:46:28  * bradleymeckjoined
18:46:55  * inolenjoined
18:48:43  * piscisaureusjoined
18:55:56  * AlexisMochajoined
18:57:40  * SergeiRNDquit (Quit: Leaving.)
18:59:45  * a_lequit (Read error: Connection reset by peer)
19:00:08  <jgi>chrisdickinson: ping
19:00:14  <chrisdickinson>pong!
19:00:21  <jgi>chrisdickinson: ah sorry, I just saw you responded to https://github.com/joyent/node/pull/8755
19:00:24  <jgi>chrisdickinson: thanks :)
19:00:52  * a_lejoined
19:01:07  <chrisdickinson>hah, I forgot to set up my reminder properly in things.app :P
19:02:36  * avalanche123joined
19:02:53  <jgi>chrisdickinson: never used things, that could be a good time to try it :)
19:03:14  <jgi>chrisdickinson: I’ve been using Trello so far to track my personal tasks, any feedback on things.app?
19:03:54  <chrisdickinson>it's okay, i keep putting it down and picking it back up
19:03:57  * avalanche123quit (Remote host closed the connection)
19:04:51  * avalanche123joined
19:06:30  <jgi>chrisdickinson: ok thanks
19:06:47  <chrisdickinson>thanks for reminding me about trello!
19:07:32  * c4miloquit (Remote host closed the connection)
19:10:52  * thlorenzquit (Remote host closed the connection)
19:13:40  * c4milojoined
19:18:23  * c4miloquit (Ping timeout: 252 seconds)
19:20:07  * abraxas_joined
19:24:04  <MI6>joyent/node: Yazhong Liu v0.12 * d312b6d : url: support `path` for url.format - http://git.io/6SM--g
19:25:10  * abraxas_quit (Ping timeout: 255 seconds)
19:26:53  * bajtosquit (Quit: bajtos)
19:28:28  <chrisdickinson>errors in the repl seems borked on v0.12.
19:29:13  <piscisaureus>saghul: what is guv? You've got competition now?
19:31:41  * kriskowalquit (Quit: kriskowal)
19:32:02  * bajtosjoined
19:32:44  * bajtosquit (Client Quit)
19:33:18  <cjihrig>jgi: ping
19:34:01  * octetcloudquit (Quit: WeeChat 1.0.1)
19:39:16  * 7YUAAINQUjoined
19:41:40  * kriskowaljoined
19:42:18  * warehouse13joined
19:42:24  <jgi>cjihrig: pong!
19:43:40  <cjihrig>thanks for reviewing that pr. my only comment is that i think we should still allow negative timeouts to be passed
19:44:24  * Left_Turnquit (Ping timeout: 256 seconds)
19:47:22  <jgi>cjihrig: what’s the use case for negative timeouts?
19:47:36  * octetcloudjoined
19:48:44  <cjihrig>jgi: there isn't one. but, it's allowed everywhere else and there are checks in place to handle negative numbers
19:51:58  <jgi>cjihrig: my concern is that, if we call Socket.prototype.setTimeout with a negative msecs value, then nothing happens. The timeout doesn’t change, although the user probably expected the timeout to change. I thought that throwing in this case would be better then silently failing.
19:53:10  <jgi>cjihrig: I understand that this could potentlally break a lot of existing code though
19:55:06  <cjihrig>jgi: yea it's a bad situation. ideally, i'd like the code to be as restrictive as possible too. just worried about breaking existing code
19:56:47  <jgi>cjihrig: I’d like to get tjfontaine, trevnorris and others’ opinion on this, as they have more experience on API changes and their impact
19:58:29  <cjihrig>jgi: sounds good to me
19:58:51  * dshaw_joined
20:00:11  <creationix>Personally, I think it’s fine to break when people depend on undefined behavior.
20:00:35  * 7YUAAINQUchanged nick to thlorenz
20:01:19  <jgi>cjihrig: could you please add a comment to the PR that asks for input from core maintainers and people more experienced with dealing with API changes?
20:01:54  <cjihrig>jgi: sure
20:01:59  <jgi>cjihrig: thanks!
20:04:37  * stagas_joined
20:05:19  * stagasquit (Ping timeout: 252 seconds)
20:05:36  * stagas_changed nick to stagas
20:05:41  <cjihrig>jgi: https://github.com/joyent/node/pull/8739#issuecomment-65295149
20:06:18  <jgi>cjihrig: also, your branch is currently based on master, which if I understand correctly means that this change would land in a 0.13.x release. I think a more restrictive change would be fine for these releases. If we want to land it in 0.11.x or 0.12.x, then we could land a less restrictive change that for instance allows negative numbers.
20:06:33  <jgi>cjihrig: thanks!
20:08:01  <cjihrig>jgi: yea. i'm fine for rebasing it wherever needed, depending on how restrictive the change is
20:08:07  <jgi>cool
20:09:24  <jgi>creationix: yes, that’s my gut feeling too, but I don’t like to trust my gut feelings on these matters :)
20:09:41  <creationix>I understand
20:10:22  * kriskowalquit (Quit: kriskowal)
20:10:27  * avalanche123quit (Remote host closed the connection)
20:11:31  <cjihrig>creationix: i also agree with you. my only worry is that it's related to timeouts and it will turn into a "but this is supported in the browser" argument that drags on :-/
20:24:35  * c4milojoined
20:28:44  * octetcloudquit (Remote host closed the connection)
20:28:49  * jgiquit (Quit: jgi)
20:29:19  * octetcloudjoined
20:32:45  * brsonjoined
20:34:20  * c4miloquit (Remote host closed the connection)
20:34:44  * thlorenzquit (Remote host closed the connection)
20:35:32  * brsonquit (Remote host closed the connection)
20:36:17  * brsonjoined
20:46:41  * AlexisMochaquit (Ping timeout: 264 seconds)
20:50:23  * kriskowaljoined
20:57:24  * avalanche123joined
20:59:55  * pgicxplzsjoined
21:01:37  * warehouse13quit (Ping timeout: 240 seconds)
21:01:59  * avalanche123quit (Ping timeout: 264 seconds)
21:02:35  * avalanche123joined
21:07:58  * avalanch_joined
21:09:37  * abraxas_joined
21:09:58  * avalanche123quit (Ping timeout: 256 seconds)
21:11:15  * avalanche123joined
21:11:25  * avalanch_quit (Read error: Connection reset by peer)
21:13:06  * avalanch_joined
21:13:57  * abraxas_quit (Ping timeout: 240 seconds)
21:15:14  * thlorenzjoined
21:16:44  * avalanche123quit (Ping timeout: 244 seconds)
21:20:03  * avalanche123joined
21:20:31  * thlorenzquit (Remote host closed the connection)
21:21:16  * avalanch_quit (Ping timeout: 255 seconds)
21:35:07  * jgijoined
21:41:18  <saghul>piscisaureus: heh, actually I got help, because I'll end up merging the cffi bindings he started :-)
21:46:00  * chris_99quit (Quit: Ex-Chat)
21:46:31  * avalanche123quit (Remote host closed the connection)
21:50:29  * avalanche123joined
21:58:12  <trevnorris>tjfontaine: ping
21:59:50  * hueniversejoined
22:00:19  <saghul>trevnorris: I'll be around for a bit in case you needed something
22:00:45  * Damn3dquit (Ping timeout: 258 seconds)
22:05:42  <trevnorris>saghul: i'm just getting bitten in the performance butt by the fact uv_async_send() uses write(2) to interrupt the poll and wanted your feedback on the possibility of moving the poll to another thread, and instead using a sem_timedwait on the eloop thread.
22:07:39  * Damn3djoined
22:11:19  * Fishrock123quit (Remote host closed the connection)
22:15:47  * seishunquit (Ping timeout: 264 seconds)
22:20:42  <saghul>trevnorris: this is libnub, right?
22:21:03  <saghul>so, you want to run something in the loop thread and wait for it, but from another thread?
22:22:24  <trevnorris>saghul: the reason this came up is for libnub. the pain point is that uv_async_send() is so slow.
22:22:40  * kriskowalquit (Quit: kriskowal)
22:23:08  <trevnorris>the thought is to have a dedicated poll'ing thread that queue's up incoming whatnot and in the "poll" phase of the event loop it would check the queue. if nothing's there then it would sem_timedwait().
22:23:18  * c4milojoined
22:23:22  <trevnorris>this way other threads could interrupt by doing sem_post() instead of write()
22:23:51  <trevnorris>the polling thread would interrupt it the same way when something came in.
22:24:16  * kriskowaljoined
22:24:18  <saghul>trevnorris: hum
22:24:52  <trevnorris>or, I guess a possibly cheaper alternative would be a cond_timedwait
22:24:58  <saghul>and you think switching between 2 threads would be faster than the write() here?
22:25:22  <saghul>(maybe I lack the whole context here)
22:26:18  <trevnorris>let me start with the goal. make uv_async_send() faster.
22:26:43  <trevnorris>current impl is to do a write() on a fd that interrupts the poll.
22:26:57  <trevnorris>i'm maxing out at being able to do that around 100k/sec
22:27:09  <saghul>trevnorris: platform?
22:27:33  <trevnorris>linux 3.16 x86 i7
22:27:46  <trevnorris>x86_64
22:27:58  * c4miloquit (Ping timeout: 258 seconds)
22:28:21  <saghul>ok
22:29:36  <saghul>trevnorris: you may want to check this out: https://github.com/libuv/leps/pull/2
22:29:45  <saghul>specially the uv_callback request
22:30:36  * Fishrock123joined
22:31:24  * kriskowalquit (Quit: kriskowal)
22:34:13  * lanceballchanged nick to lance|afk
22:35:31  <trevnorris>saghul: i had something like uv_callback in libnub. problem is when the user wants to know the results of a specific operation immediately
22:35:52  <saghul>trevnorris: what kind of operation?
22:36:05  <trevnorris>e.g. uv_write(), and want to know the returned error code.
22:36:36  <saghul>ah, but from another thread, I guess?
22:36:39  <trevnorris>yeah
22:37:41  * kriskowaljoined
22:38:00  <saghul>TBH, I'm not sure if the semaphore trick would work better, specially in the common single threaded case
22:38:04  <trevnorris>currently i'm doing a uv_async_send() then uv_sem_wait() from the spawned thread. when the async cb is called the eloop does a sem_post to the child thread and sem_wait.
22:38:05  <trevnorris>then when the child is done it does a sem_post to tell the eloop it can continue.
22:39:04  <trevnorris>yeah. that's what i'm afraid of. cross thread communication has seriously been a bitch to figure out, performance-wise.
22:40:12  <saghul>trevnorris: why do you need to use multipple threads? I mean, is it because uv_write2 sucks, experimentation, other?
22:41:01  <trevnorris>saghul: for JS. people are using Node to generate templates and the like, which take a long time to finish, and I don't like it needs to block the eloop to run.
22:42:20  <trevnorris>also for JS safety. when JS throws an exception the env should usually be brought down. by running JS in another thread that can be done w/o bringing down the entire process.
22:42:47  <saghul>but do those tasks involve i/o?
22:42:56  <saghul>template rendering sounds some CPU bound, isn't it?
22:43:19  <trevnorris>yeah it is. but when the template is done they want to write it back out to the client.
22:44:00  <saghul>and uv_queue_work is too slow I assume?
22:44:17  <trevnorris>you don't get the error back immediately, right?
22:44:32  <trevnorris>e.g. don't want to queue up several writes and have one of them fail in the middle.
22:45:10  <saghul>no, I mean, you would call renderTemplate on the thread pool with uv_queue_work and when done do the write on the eloop thread
22:45:59  <trevnorris>well the template render would be done in JS. then from JS it would do, like, connection.write(template).
22:46:22  <trevnorris>and if the write is just queued back to the eloop then I don't know the error code.
22:46:51  <trevnorris>basically I need, like, a thread-safe uv_write()
22:47:17  <saghul>I'm afraid I don't have a good story to tell you here :-/
22:47:25  <creationix>saghul: you started pyuv right?
22:47:32  <saghul>creationix: yep
22:47:45  * piscisaureusquit (Ping timeout: 252 seconds)
22:48:04  <trevnorris>hehe. okay. but thanks for talking w/ me about it. at least helps me rule things out.
22:48:14  <creationix>awesome. luv also has full libuv 1.0 support. It’s luvit that’s taking time (all the node.js style sugar on top)
22:48:27  <saghul>trevnorris: uv_write reports most of its errors in the callback, so unless the handle is closed or something you could just run it safely disregarding the retcode
22:48:37  <saghul>it the planes are aligned, that is :-)
22:48:51  <saghul>creationix: awesome!
22:49:41  <trevnorris>saghul: my worry is a case like if someone does several uv_write()'s and one in the middle fails. then the data stream basically becomes corrupt.
22:49:46  <saghul>trevnorris: it would be great if you could have a look at libuv/leps and see if you have some ideas we could mergesort in there
22:50:01  <trevnorris>saghul: i definitely will. thanks for pointing me to it.
22:50:35  <saghul>trevnorris: i'm not sure how that could happen, since we queue writes and do them in order
22:55:06  <trevnorris>saghul: okay. i'll ponder on this some more. not sure if that type of scenario is possible w/ any of the APIs but I'm being paranoid in the case that a call to say write() to the same socket returns an error once, but doesn't return an error on the subsequent call.
22:55:34  * avalanche123quit (Remote host closed the connection)
22:56:55  <trevnorris>saghul: wtf. 001-remove-unix-support???
22:57:17  * dsantiagoquit (Ping timeout: 252 seconds)
22:57:24  <saghul>trevnorris: xDD
22:57:30  <trevnorris>heh. you come up w/ that? :P
22:57:45  <saghul>trevnorris: I woke up creative :-P
22:57:54  <trevnorris>haha. awesome.
22:58:17  <saghul>trevnorris: re sockets, I have never seen it happen, but it doesn't mean it's not possible. However, if write(2) fails you'll know in the callback
22:58:28  <saghul>it won't be returned by uv_write
22:58:31  * abraxas_joined
22:59:05  * dsantiagojoined
22:59:22  <trevnorris>couldn't uv_write() return EFBIG for one write, but then the subsequent uv_write() succeed? (total ridiculous edge case)
23:01:46  * avalanche123joined
23:02:10  * kriskowalquit (Quit: kriskowal)
23:02:46  * AvianFluquit (Quit: Leaving)
23:02:47  * pgicxplzsquit (Ping timeout: 252 seconds)
23:02:58  * abraxas_quit (Ping timeout: 255 seconds)
23:03:01  * kriskowaljoined
23:04:33  <saghul>trevnorris: it could return some errors, but not those returned by the write syscall
23:04:56  <saghul>it would return EBADF if you closed the handle, for example
23:06:49  * ircretaryquit (Ping timeout: 252 seconds)
23:07:24  <trevnorris>yeah. fortunately in that case it would then fail for every subsequent write.
23:08:50  <trevnorris>what happens if write returns an error code that doesn't have a libuv counter part? (e.g. EFBIG)
23:08:50  <trevnorris>i'm probably misunderstanding something here.
23:09:20  <saghul>trevnorris: all POSIX errnos should have a uv counterpart
23:09:53  <saghul>if there is one missing it's a bug, but I see you just volunteered to fix it, so all is good :-)
23:10:00  <trevnorris>hahaha
23:10:01  <trevnorris>okay.
23:10:24  <trevnorris>well, EFBIG is listed in errno and I can't find it in libuv. :P
23:10:43  <rendar>what is leps?
23:11:36  <saghul>Libuv Enhancement Proposal
23:11:40  <rendar>oh
23:11:43  <rendar>for 2.x?
23:11:55  <saghul>rendar: yep, look here: https://github.com/libuv/leps
23:11:59  <rendar>thanks saapas
23:12:04  <rendar>ops, saghul :)
23:13:02  * pgicxplzsjoined
23:14:29  * MI6quit (Ping timeout: 252 seconds)
23:18:45  * lance|afkchanged nick to lanceball
23:49:08  * lanceballchanged nick to lance|afk
23:55:21  * rendarquit (Quit: Leaving)