00:00:01  * ircretaryquit (Remote host closed the connection)
00:00:09  * ircretaryjoined
00:02:20  * dshaw_quit (Quit: Leaving.)
00:02:28  * stagasquit (Ping timeout: 245 seconds)
00:05:15  * kevinswi_joined
00:05:27  * kevinswiberquit (Ping timeout: 264 seconds)
00:14:24  * Fishrock123joined
00:16:05  * a_lejoined
00:16:30  * a_lequit (Read error: Connection reset by peer)
00:17:12  * a_lejoined
00:18:49  * Fishrock123quit (Ping timeout: 252 seconds)
00:22:50  * a_lequit (Read error: Connection reset by peer)
00:23:18  * a_lejoined
00:24:30  * a_lequit (Read error: Connection reset by peer)
00:24:43  * a_lejoined
00:27:06  <jgi>tjfontaine: also, the reason why path was created and overlaps pathname and search is https://github.com/joyent/node/issues/8722, which aimed at making “http.request(url.parse(someUrl))” easier.
00:27:25  <jgi>tjfontaine: so instead of fixing this change, maybe we could just reconsider it
00:27:30  <jgi>s/just//
00:28:22  <jgi>and by reconsidering it I mean revisiting it, I agree that being able to write http.request(url.parse(someUrl)) is a good thing
00:29:49  * bradleymeckquit (Read error: Connection reset by peer)
00:30:07  * bradleymeckjoined
00:30:30  * thlorenzquit (Remote host closed the connection)
00:36:29  <Wraithan>Currently url.parse() is extremely slow and doesn't conform to the whatwg spec for url parsers
00:36:34  <Wraithan>jgi, tjfontaine ^
00:38:17  <Wraithan>and by doesn't conform I mean it passes like 0% of tests
00:38:39  <Wraithan>I need to get my tests I wrote for that cleaned up and submitted
00:44:44  <tjfontaine>well it doesn't seem like we can fix that for v0.12
00:44:55  <tjfontaine>making url.parse conform to whatwg
00:45:06  <tjfontaine>the question is of course (as always) if that is indeed a design goal for Node.js
00:45:27  <tjfontaine>where do we draw the line between browser conformity and doing what may make more sense for a server side language
00:45:44  * toastynerdquit (Ping timeout: 265 seconds)
00:49:37  * toastynerdjoined
00:52:45  <jgi>tjfontaine, Wraithan: it seems that at least we don’t want the API to fail silently when it’s not used properly
00:53:26  <jgi>tjfontaine, Wraithan: unless that’s also part of the whatwg compatibility, and that it is considered a more important goal
00:56:45  <piscisaureus>so
00:56:48  <piscisaureus>just kick it out
00:56:53  <piscisaureus>like iojs did :)
00:57:47  <piscisaureus>there is no difficulty in doing url parsing in a module whatsoever
00:59:30  <tjfontaine>jgi: if we want to keep the feature -- it seems wrong to silently ignore that the input is bogus -- granted we can't fix other cases of this, but for new ones we can at least provide a modicum of sanity
00:59:43  <tjfontaine>piscisaureus: reverting the change is also one way to approach it
00:59:46  <piscisaureus>It was a nice idea, but turned out to have unexpected consequences
01:00:00  * DarkUraniumquit (Quit: Leaving)
01:00:55  * yunongquit
01:00:55  * Damn3dquit (Ping timeout: 245 seconds)
01:00:56  * yunongjoined
01:01:38  * ferossquit (Ping timeout: 245 seconds)
01:03:17  * Damn3djoined
01:03:50  * ferossjoined
01:06:03  * Fishrock123joined
01:06:58  * abraxas_joined
01:08:42  <piscisaureus>tjfontaine: if you land it you'll end up fighting a hydra because throwing from url.format also has consequences
01:09:20  <piscisaureus>now all code that calls url.parse need to be aware that errors may be thrown and deal with potential fd leaks
01:09:26  <piscisaureus>or eventemitter leaks
01:11:47  * kevinswi_quit (Remote host closed the connection)
01:12:27  * abraxas_quit (Ping timeout: 272 seconds)
01:18:58  <tjfontaine>piscisaureus: at the base of the conversation -- given bogus/invalid input the system cannot make forward progress, it's programmer error, and thus we can't move forward -- people shouldn't be trying to do error handling for programmer error, they should be aiming to do operational error handling
01:24:16  <piscisaureus>I know we have different opinions on that topic.
01:24:52  <piscisaureus>But in any case "doesn't throw by design" seems better than "doesn't throw if the user supplies the right input"
01:25:57  <tjfontaine>needless to say, it's a perfectly fine reason to have separate sandboxes with which to play in
01:30:50  * bradleymeckquit (Read error: Connection reset by peer)
01:31:26  * thlorenzjoined
01:31:28  * octetcloudquit (Ping timeout: 255 seconds)
01:33:04  * bradleymeckjoined
01:36:31  * thlorenzquit (Ping timeout: 264 seconds)
01:38:54  <piscisaureus>however you please
01:39:28  * piscisaureusquit (Quit: ~ Trillian Astra - www.trillian.im ~)
01:42:45  * kevinswiberjoined
01:45:23  * dap_quit (Quit: Leaving.)
01:49:25  * bradleymeckquit (Quit: bradleymeck)
01:58:20  * saghul_joined
02:00:40  * hij1nx_joined
02:05:05  * zjuquit (Read error: Connection reset by peer)
02:06:02  * saghulquit (Ping timeout: 264 seconds)
02:06:03  * hij1nxquit (Ping timeout: 264 seconds)
02:08:50  * abraxas_joined
02:09:29  * jgiquit (Quit: jgi)
02:10:48  * Ralithquit (Ping timeout: 244 seconds)
02:12:35  * jgijoined
02:19:56  * jgiquit (Quit: jgi)
02:21:52  * qard_joined
02:25:31  * thlorenzjoined
02:30:07  * thlorenzquit (Remote host closed the connection)
02:32:48  * kevinswiberquit (Remote host closed the connection)
02:32:48  * kevinswiberjoined
02:33:29  * reqsharkjoined
02:35:25  * wolfeidau_quit (Remote host closed the connection)
02:37:57  * Ralithjoined
02:46:22  * kevinswiberquit (Remote host closed the connection)
02:46:55  * kevinswiberjoined
02:47:23  * thlorenzjoined
02:49:36  * AvianFluquit (Quit: Leaving)
02:50:52  * kevinswiberquit (Ping timeout: 240 seconds)
02:51:38  * thlorenzquit (Ping timeout: 245 seconds)
03:00:19  * reqsharkquit (Quit: Be back later ...)
03:11:03  * a_lequit (Remote host closed the connection)
03:11:40  * a_lejoined
03:13:43  * kevinswiberjoined
03:16:23  * a_lequit (Ping timeout: 256 seconds)
03:24:34  * jasnelljoined
03:31:19  * kevinswiberquit (Remote host closed the connection)
03:31:44  * kevinswiberjoined
03:33:09  * thlorenzjoined
03:33:27  * Left_Turnquit (Ping timeout: 265 seconds)
03:36:05  * kevinswiberquit (Ping timeout: 252 seconds)
03:37:43  * thlorenzquit (Ping timeout: 264 seconds)
03:42:28  * wolfeidaujoined
03:44:06  * brsonquit (Quit: leaving)
03:55:06  * jasnellquit (Remote host closed the connection)
03:57:07  * Fishrock123quit (Quit: Leaving...)
04:01:59  * wolfeidauquit (Remote host closed the connection)
04:15:29  * octetcloudjoined
04:23:30  * thlorenzjoined
04:24:42  * jasnelljoined
04:25:08  * jasnellquit (Read error: Connection reset by peer)
04:25:44  * jasnelljoined
04:27:47  * thlorenzquit (Ping timeout: 245 seconds)
04:34:32  * jasnellquit (Remote host closed the connection)
04:34:52  * jasnelljoined
04:45:28  * kevinswiberjoined
04:54:18  * jasnellquit (Quit: Leaving...)
05:06:45  * AvianFlujoined
05:17:38  * kevinswiberquit (Remote host closed the connection)
05:18:14  * kevinswiberjoined
05:22:28  * kevinswiberquit (Ping timeout: 245 seconds)
05:24:21  * thlorenzjoined
05:29:04  * thlorenzquit (Ping timeout: 255 seconds)
05:30:04  * brsonjoined
05:40:10  * rmgquit (Remote host closed the connection)
06:01:07  * reqsharkjoined
06:05:31  * reqsharkquit (Ping timeout: 255 seconds)
06:14:17  * bajtosjoined
06:15:53  * zju3quit (Read error: Connection reset by peer)
06:19:03  * dshaw_joined
06:20:09  * zju3joined
06:27:37  * brsonquit (Quit: leaving)
06:34:18  * qard_quit (Quit: leaving)
06:42:24  * toastynerdquit (Ping timeout: 272 seconds)
06:43:04  * kevinswiberjoined
07:00:06  * kevinswiberquit (Remote host closed the connection)
07:00:32  * kevinswiberjoined
07:01:38  * kevinswiberquit (Remote host closed the connection)
07:02:09  * kevinswiberjoined
07:05:22  * toastynerdjoined
07:13:26  * thlorenzjoined
07:14:17  * abraxas_quit (Remote host closed the connection)
07:16:13  * abraxas_joined
07:17:44  * thlorenzquit (Ping timeout: 246 seconds)
07:26:14  * AvianFluquit (Quit: Leaving)
07:26:55  * octetcloudquit (Ping timeout: 264 seconds)
07:27:03  * Tux64quit (Quit: Connection closed for inactivity)
07:34:04  * wolfeidaujoined
07:51:15  * dshaw_quit (Quit: Leaving.)
07:53:59  * bajtosquit (Quit: bajtos)
08:00:51  * iarnaquit (Ping timeout: 256 seconds)
08:03:28  * toastynerdquit (Ping timeout: 272 seconds)
08:13:26  * SergeiRNDjoined
08:50:45  * kellabytequit (Ping timeout: 276 seconds)
08:50:59  * eugeneware_quit (Ping timeout: 272 seconds)
08:51:00  * rvaggquit (Ping timeout: 265 seconds)
08:51:37  * parshapquit (Ping timeout: 272 seconds)
08:51:38  * petka__quit (Ping timeout: 245 seconds)
08:54:29  * kellabytejoined
08:54:46  * savardcquit (Ping timeout: 272 seconds)
08:57:49  * parshapjoined
08:59:12  * kellabytequit (Ping timeout: 272 seconds)
09:00:20  * eugeneware_joined
09:01:56  * rvaggjoined
09:02:15  * thlorenzjoined
09:02:50  * savardcjoined
09:05:47  * petka__joined
09:05:55  * kellabytejoined
09:06:27  * bajtosjoined
09:06:35  * thlorenzquit (Ping timeout: 246 seconds)
09:20:34  * zju4joined
09:31:57  * stagasjoined
09:44:52  * rendarjoined
09:47:41  <txdv>saghul_: do I need to close all handles before calling uv_loop_close ?
09:54:27  <saghul_>txdv: yes, otherwise it returns UV_EBUSY
09:54:33  <saghul_>well, actually no
09:54:42  <saghul_>you can call it, but it will fail
09:55:58  <txdv>uv_loop_delete asserts
09:56:02  <txdv>and that blows up
09:56:05  <txdv>I am not happy with iot
09:56:21  <saghul_>uv_loop_delete is deprecated
09:56:39  <saghul_>you should use uv_loop_close + manual free (or not, depends on your use case)
09:56:56  <saghul_>the steps for completely closing a loop are: 1. have uv_run return
09:57:04  <saghul_>2. uv_walk and close all handles
09:57:20  <saghul_>3. uv_run again so the close callbacks run
09:57:35  <saghul_>4. uv_loop_close, and check it returns 0
09:57:43  <saghul_>5. free the loop
09:58:59  <txdv>6. profit
09:59:01  <txdv>thanks
09:59:21  <txdv>Yeah, I'm porting to the v1.x
09:59:27  <txdv>did you port pyuv already to v1.x?
10:00:20  <saghul_>no worries
10:00:25  <saghul_>yes, I did
10:01:08  <saghul_>the trickiest part for me was coupling the libuv handles lifetime with Python object's
10:02:10  <saghul_>I don't need to do that loop closing, because each handle keeps the Python loop object alive, so if the loop itself is GCd it means nobody is using it
10:02:31  * seishunjoined
10:02:35  <txdv>in C# you can just allocate a GCHandle
10:02:48  <txdv>until you close it, nothing will be collected
10:03:14  <txdv>I don't collect them automatically though, you have to dispose them yourselfs
10:07:35  <txdv>async support in python looks rather nice
10:07:36  <saghul_>In pyuv I do close them if they are GCd, but if a handle is 'active' then I increase the refcount so it's not collected
10:08:06  <saghul_>what async support? the asyncio module?
10:08:11  * chris_99joined
10:08:38  * bajtosquit (Quit: bajtos)
10:11:40  * SplinterOfChaosquit (Ping timeout: 255 seconds)
10:11:48  <txdv>I just saw some examples from your twitter feed
10:11:57  <txdv>iirc there is some special async annotation
10:13:25  <txdv>/home/bentkus/Projects/mono/LibuvSharp/bin/Debug/libuv.so(uv_walk+0x14) [0x7f1d836ea0d4]
10:13:39  <txdv>o god I wish this would have some proper debugging information
10:15:47  <saghul_>there is no async anotation really, it's more of a gentlemen's agreenment
10:16:14  <saghul_>some days I wake up like "yeah, yield from is the shit" and some others like "fuck no!" xD
10:19:09  * rmgjoined
10:19:50  <erikj>Is that twisted by any chance? The yield stuff always drives me up the wall in that, but I always end up missing it in other languages :/
10:20:44  <txdv>C# has async/await
10:20:58  <txdv>though its rather fat
10:23:47  <txdv>erikj: why does it annoy you/
10:23:52  * rmgquit (Ping timeout: 240 seconds)
10:24:43  <saghul_>In Python, the problem is that all libraries need to cooperate for yield from foo() to work
10:24:55  <saghul_>and none of the stuff in the standard library does that
10:25:13  <txdv>AAA yes
10:25:21  <txdv>Because all the libs are written with blocking calls
10:26:01  <erikj>Tbf, most of the time I get annoyed because I put a yield where I shouldn't or forget one where I should
10:26:45  <erikj>and it can be a nightmare to track down those sorts of bugs, since they don't produce any exceptions, the program just keeps going
10:27:39  <erikj>aaaaaand half the time exceptions raised lose their stack trace as they propagate back up
10:34:40  <txdv>hm interesting
10:34:51  <txdv>i check the active_handles property in loop_t and it says 0
10:35:00  <txdv>then I do a uv_walk and I get 2 handles
10:38:58  <saghul_>txdv: isn't that private?
10:41:34  <txdv>it doesn't say it
10:43:28  <saghul_>ah, I checked
10:43:35  <saghul_>are your handles unref'd?
10:44:02  <saghul_>txdv: if a handle is unref'd it doesn't count as active
10:44:27  <txdv>O yeah
10:44:30  <txdv>I am doing exactly that
10:47:24  <saghul_>I'm not even sure why we have that, you are better off just uv_walking
10:50:46  <txdv>I wish i would know how to 'show previous commit' with tig
10:51:06  * thlorenzjoined
10:51:07  <txdv>cant even come up with a adequate google search query
10:55:31  * kellabytequit (Quit: Connection closed for inactivity)
10:55:44  * thlorenzquit (Ping timeout: 244 seconds)
10:56:51  * abraxas_quit (Remote host closed the connection)
10:57:44  <txdv>I can't get the close callbacks triggered
10:57:47  <txdv>sigh
10:59:23  * SergeiRNDquit (Quit: Leaving.)
11:02:15  <txdv>Aaaaaa
11:02:17  <txdv>bug detected
11:09:54  * tarrudajoined
11:13:43  <txdv>weired bug
11:13:45  <txdv>:/
11:17:11  * Left_Turnjoined
11:25:01  <rendar>txdv, which bug?
11:26:40  <txdv>my bug
11:30:49  <txdv>in my wrapper
11:30:56  <txdv>it makes kaboom
11:31:12  <txdv>and i just realized that I have to put my user id in some strace config to get a proper debug trace
11:37:09  * SergeiRNDjoined
11:43:33  * Damn3dquit (Ping timeout: 265 seconds)
11:46:00  * Damn3djoined
11:51:55  * thlorenzjoined
11:56:13  * thlorenzquit (Ping timeout: 245 seconds)
12:24:45  * tarrudaquit (Quit: WeeChat 1.0.1)
12:24:51  * bajtosjoined
12:25:53  * Tux64joined
12:31:10  * bajtosquit (Ping timeout: 255 seconds)
12:35:00  * bajtosjoined
12:38:20  * stagasquit (Ping timeout: 246 seconds)
12:48:54  <txdv>saghul_: widows pipes don't support setting buffer_size?
12:50:08  <saghul_>txdv: nope, because they are not sockets really
12:53:14  * bajtosquit (Quit: bajtos)
12:55:02  <txdv>only on creation
12:55:49  <txdv>I wonder whether I should add this to the UVStream interface or make a seperate interface
12:56:24  <saghul_>I have it on the stream base class, if it fails, well the user will get an exception
12:57:44  <txdv>o god, you had to actually write the binding in C
12:59:55  <txdv>o god, udp is not a stream
12:59:59  <txdv>but i can set the buffer size as well
13:04:49  <txdv>saghul_: did you really had it to stream base class?
13:05:38  <saghul_>IIRC, yes
13:05:59  <txdv>https://pyuv.readthedocs.org/en/v1.x/search.html?q=buffer_size
13:06:04  <txdv>is udp a stream?
13:06:51  <saghul_>nope
13:06:59  <txdv>but it has buffer_size
13:07:15  <saghul_>wait, let me check
13:07:56  <saghul_>I misremembered, I have that function on the TCP, Pipe and UDP classes only
13:09:00  <txdv>yeah I'm looking at the C code now too
13:09:04  <txdv>so it is basically a seperate interface
13:10:23  <txdv>that is a lot of boiler plate you had to write to get libuv onto python
13:10:34  <txdv>a shitload of dedication you have
13:22:50  <saghul_>it was an excercise of learning :-)
13:23:02  <saghul_>I wanted to 'get' CPython's internals
13:27:34  * kellabytejoined
13:31:31  <txdv>i bet you got more than you asked for
13:34:49  * [spoiler]joined
13:40:44  * thlorenzjoined
13:45:23  * thlorenzquit (Ping timeout: 256 seconds)
14:28:45  * lance|afkchanged nick to lanceball
14:31:04  * thlorenzjoined
14:35:03  * abraxas_joined
14:35:18  * thlorenzquit (Remote host closed the connection)
14:39:22  * abraxas_quit (Ping timeout: 240 seconds)
14:44:49  * thlorenzjoined
14:48:58  * Fishrock123joined
14:49:54  * stagasjoined
14:50:46  * SergeiRNDquit (Quit: Leaving.)
14:51:14  <txdv>lol
14:51:16  <txdv>pipe_getsockname
14:51:22  * kevinswiberquit (Ping timeout: 240 seconds)
14:51:33  <txdv>that thing exists as an interface in my bindings before v1.x
14:52:06  <txdv>well spotted saghul_ that we need a getsockname for pipe
14:53:25  * kevinswiberjoined
15:05:09  * nathan7quit (Ping timeout: 276 seconds)
15:08:21  * roxluquit (Quit: My Mac has gone to sleep. ZZZzzz…)
15:09:57  * roxlujoined
15:11:23  * felipealmeidaquit (Ping timeout: 265 seconds)
15:16:48  * felipealmeidajoined
15:19:10  * reqsharkjoined
15:20:09  * nathan7joined
15:24:12  * andrehjrjoined
15:29:31  * a_lejoined
15:35:30  * kevinswiberquit
15:42:51  * rmgjoined
15:47:13  * rmgquit (Ping timeout: 252 seconds)
15:47:57  * a_lequit (Remote host closed the connection)
15:48:31  * a_lejoined
15:51:55  * rmgjoined
15:52:49  * a_lequit (Ping timeout: 244 seconds)
15:57:00  * a_lejoined
16:12:31  * iarnajoined
16:12:34  * iarnaquit (Remote host closed the connection)
16:12:48  * iarnajoined
16:13:21  * SplinterOfChaosjoined
16:14:39  * toastynerdjoined
16:15:12  * iarnaquit (Read error: Connection reset by peer)
16:15:12  * octetcloudjoined
16:15:41  * iarnajoined
16:21:42  <erikj>In uv_write, does libuv ever write to the given buffers?
16:24:11  * abraxas_joined
16:28:25  <srl295>tjfontaine: morning
16:28:28  <tjfontaine>morn
16:28:39  * abraxas_quit (Ping timeout: 252 seconds)
16:39:12  * lanceballchanged nick to lance|afk
16:40:35  <saghul_>erikj: sure
16:45:06  <erikj>What does it write there ooi?
16:47:55  * AlexisMochajoined
16:50:07  <saghul_>oh, wait, sorry, I misread!
16:50:15  <saghul_>no, we don't write in those buffers
16:50:19  <saghul_>erikj: ^
16:54:43  <erikj>Ah, I was curious what on earth you were doing :p
16:56:22  <erikj>Is that something that something that can/should be put in the doc?
16:57:27  <saghul_>I don't think so, write just writes the data :-)
16:57:44  * jgijoined
16:57:52  <saghul_>why did you think we might write to those buffers?
16:58:19  <tjfontaine>jgi, chrisdickinson, cjihrig, srl295, trevnorris https://plus.google.com/hangouts/_/calendar/dGpmb250YWluZUBub2RlanMub3Jn.7o3iugm5mbjqj81eb56fsoj118
16:58:24  <jgi>good morning!
16:58:29  <erikj>saghul_: I didn't really think you were, but the number of times I've been bitten because I've assumed library writers are sane...
16:58:34  <srl295>jgi: good mornign - need to find a headset
16:58:40  <erikj>I prefer being really explicit about such things
16:59:03  <cjihrig>tjfontaine: "You're not allowed to join this video call."
16:59:04  <erikj>especially given that most write APIs self document by taking char const*
16:59:09  * andrehjrquit (Quit: Computer has gone to sleep.)
16:59:12  <tjfontaine>cjihrig: blargh
16:59:23  <tjfontaine>cjihrig: can you try with your @nodejs.org account?
16:59:40  <nathan7>hey tjfontaine
16:59:51  <tjfontaine>hey
16:59:59  <saghul_>erikj: we do take a const uv_buf_t bufs[]
17:00:05  <nathan7>tjfontaine: how's TJing?
17:00:55  <tjfontaine>ok having a call at,
17:01:23  <srl295>joining
17:01:48  * thlorenzquit (Remote host closed the connection)
17:02:19  <tjfontaine>chrisdickinson: around?
17:02:19  <erikj>saghul_: but uv_buf_t.base is a char*, not a char const* right?
17:02:59  <srl295>cjihrig: tjfontaine i got that error also
17:03:06  <chrisdickinson>tjfontaine: yep, joining
17:03:09  <tjfontaine>srl295: what email address are you using so I can explicitly add you
17:03:14  <srl295>srl295 @ gmail
17:03:15  <saghul_>erikj: right, because we use the same structure when we read
17:03:37  <saghul_>erikj: if you think this would help, by all means, send a PR :-)
17:04:01  <srl295>tjfontaine: thought it was because i hadn't circled you :]
17:04:23  <tjfontaine>srl295: did you get my invite?
17:04:54  <srl295>tjfontaine: not yet sorry
17:05:05  <tjfontaine>you should be clear to join though
17:05:13  <erikj>saghul_: Cool, will do if I remember it later. Thanks :)
17:05:23  <saghul_>erikj: thank you!
17:05:46  <srl295>srl295@gmail.com
17:06:10  <tjfontaine>I added you to the calendar invite
17:08:15  * dap_joined
17:08:24  <tjfontaine>srl295: no *really* I clicked save and then it sent it
17:08:28  <srl295>tjfontaine: nothing in my inbox
17:08:29  <tjfontaine>srl295: you should be able to join now
17:12:07  * toastynerdquit (Remote host closed the connection)
17:21:56  * a_lequit (Remote host closed the connection)
17:22:34  * a_lejoined
17:22:40  * a_lequit (Read error: Connection reset by peer)
17:23:07  * davijoined
17:23:27  * stagasquit (Ping timeout: 264 seconds)
17:24:45  * Ralithquit (Ping timeout: 252 seconds)
17:27:41  * a_lejoined
17:30:19  * a_lequit (Read error: Connection reset by peer)
17:30:42  * a_lejoined
17:32:53  * a_lequit (Remote host closed the connection)
17:33:58  * a_lejoined
17:35:24  * SergeiRNDjoined
17:44:19  * thlorenzjoined
17:51:58  * SergeiRND1joined
17:53:41  * SergeiRNDquit (Ping timeout: 246 seconds)
17:57:08  <srl295>tjfontaine: jgi: robertkowalski et al thanks
17:57:10  * a_lequit (Read error: Connection reset by peer)
17:57:30  * a_lejoined
17:57:59  <jgi>srl295: thank you!
17:58:19  * thlorenzquit (Remote host closed the connection)
17:58:20  * a_lequit (Read error: Connection reset by peer)
17:59:02  * a_lejoined
17:59:06  <srl295>jgi: robertkowalski: all i meant is that for now (for some def'n of now), we can mark the data download as "LE" even if the "BE" one isn't also there to start with. Build scripts can easily generate both when a build happens, though.
17:59:14  <srl295>i'll note it on the issues
17:59:48  <tjfontaine>srl295: thank you!
18:00:31  <srl295>my thought is to add a make target that will generate the tarballs suitable for 'dist'
18:00:50  <tjfontaine>srl295: it may make it easier to group them by intel/power/arm etc
18:01:07  <srl295>tjfontaine: the data files are only big endian vs little endian
18:01:21  <srl295>(well actually vs. EBCDIC .. )
18:01:25  <jgi>srl295: that sounds good to me
18:01:46  <srl295>this is why ICU has only a few binary downloads..
18:02:04  * Ralithjoined
18:02:06  <tjfontaine>nod
18:03:00  <tjfontaine>I just mean we are probably going to want to group our downloads by arch/bitness as well, and we could in each section link to ICU data
18:03:19  <tjfontaine>so in /dist/v0.<>/node-icu-le.tar.gz and -be.tar.gz
18:03:42  <tjfontaine>but on the download page we just have it grouped in a more "human" way than LE/BE
18:03:53  <srl295>maybe node-locales-le.tar and node-locales-be.tar
18:04:14  <tjfontaine>sure
18:04:19  <tjfontaine>I'm not picky on the names
18:04:57  <srl295>tjfontaine: sounds good. so multiple links to the data, making it easy for users to hit the right ones
18:05:21  <jgi>heading to office now, see you in around 25 minutes
18:06:13  * jgiquit (Quit: jgi)
18:07:33  * AvianFlujoined
18:07:35  <cjihrig>tjfontaine: what about https://github.com/joyent/node/pull/8884? the throwing on timeout thing from a while back
18:09:24  <tjfontaine>cjihrig: that lgtm, presuming it doesn't break global.setTimeout behavior
18:10:19  <tjfontaine>which it looks like the test covers
18:10:19  <cjihrig>tjfontaine: it should only change socket timeouts
18:12:40  * abraxas_joined
18:12:50  * roxluquit (Quit: My Mac has gone to sleep. ZZZzzz…)
18:18:12  * abraxas_quit (Ping timeout: 276 seconds)
18:26:41  <MI6>joyent/node: cjihrig v0.12 * f347573 : net: throw on invalid socket timeouts - http://git.io/1jsmRg
18:26:47  * AvianFluquit (Ping timeout: 244 seconds)
18:37:59  * reqsharkquit (Quit: Be back later ...)
18:40:01  * jgijoined
18:40:13  * AvianFlujoined
18:45:50  * AvianFluquit (Ping timeout: 246 seconds)
18:48:35  <jgi>chrisdickinson, tjfontaine: sorry to continue on a discussion when we agreed on a decision: regarding throwing on url.format, I have one concern that I didn’t express during the meeting: throwing could happen much later after settings conflicting properties, making tracking the cause of issues difficult, and thus in my opinion defeating the purpose of throwing.
18:59:12  * thlorenzjoined
19:03:43  * thlorenzquit (Ping timeout: 245 seconds)
19:05:01  * roxlujoined
19:18:13  <jgi>tjfontaine: Is there anything we can do besides documenting how to install a newer libstdc++ to run v0.12 on CentOS?
19:18:27  <jgi>tjfontaine: https://github.com/joyent/node/issues/9079
19:24:23  * SergeiRND1quit (Quit: Leaving.)
19:27:05  * dshaw_joined
19:27:33  <jgi>super early lunch, bbiab
19:32:41  <trevnorris>srl295: want a doozie of a project? Buffer#localeCompare() :P
19:34:03  <srl295>trevnorris: ha..
19:34:22  <srl295>buffer of random bits?
19:35:37  <trevnorris>probably a string of some kind.
19:35:54  <trevnorris>basically being able to do a string compare on a buffer, so you don't have to convert the thing.
19:37:40  * jgiquit (Quit: jgi)
19:38:33  <srl295>trevnorris: not sure what the encoding model is at that point.. ICU itself can do compares in either utf-16 or utf-8
19:38:53  * thlorenzjoined
19:40:58  <srl295>trevnorris: within v8 ( runtime.cc ) Runtime_InternalCompare calls v8::Utils::ToLocal(String) and that apparently gets a utf-16 value
19:41:40  <trevnorris>srl295: ah, yeah. because that's how the string is represented internally in ECMAScript
19:42:43  <srl295>trevnorris: so, one could add a call that looks like char[] or whatever primitive types are in a Buffer as an argument to compare
19:42:56  <trevnorris>ooh. good idea.
19:45:00  * lance|afkchanged nick to lanceball
19:46:32  <srl295>new Intl.Collator().compare(new Buffer('foo'), new Buffer('foo')) => 0
19:46:43  <srl295>via toString()?
19:47:38  <trevnorris>yeah
19:47:44  <trevnorris>probably
19:48:05  <srl295>trevnorris: so CONVERT_ARG_HANDLE_CHECKED(String, .. does that?
19:48:37  <trevnorris>possibly. i'll have to double check.
19:48:39  * brsonjoined
19:49:06  <srl295>trevnorris: anyways, in Runtime_InternalCompare if we knew we had a utf8 buffer, v8 could call collator->compareUTF8() instead of collator->compare() at that point
19:49:32  <trevnorris>srl295: we assume all strings are utf8.
19:49:47  <trevnorris>unless stated otherwise.
19:50:37  * a_lequit (Remote host closed the connection)
19:51:05  <srl295>trevnorris: might not even need a semantic change to get a performance improvement then
19:52:31  * a_lejoined
19:52:49  <srl295>trevnorris: porbably the first step is to see if the collator.compare() (from Intl) has a speed difference between String and Buffer Is Buffer something that exists in v8 land?
19:53:46  <trevnorris>srl295: no. it's home grown, but it still uses v8 mechanisms internally.
19:53:56  <trevnorris>just depends on what API v8 has exposed.
19:54:23  <trevnorris>also, this is nothing remotely serious. I was just looking at implementing Buffer#indexOf()
19:54:30  * trevnorrislunch
19:55:09  <srl295>trevnorris: Oh ok. At least it was not compare arbitrary bits!
19:55:23  * andrehjrjoined
19:59:10  * piscisaureusjoined
20:01:50  * abraxas_joined
20:06:13  * abraxas_quit (Ping timeout: 245 seconds)
20:07:53  * a_lequit (Read error: Connection reset by peer)
20:08:22  * a_lejoined
20:12:28  <creationix>rphillips: I see you've published 8 different packages to lit. Is everything still working as expected for you?
20:13:06  <creationix>hmm, wrong channel
20:16:21  * yunongquit (Remote host closed the connection)
20:17:02  * yunongjoined
20:27:32  * a_lequit (Remote host closed the connection)
20:30:52  * a_lejoined
20:32:34  * a_lequit (Remote host closed the connection)
20:32:36  * dshaw_quit (Quit: Leaving.)
20:33:11  * a_lejoined
20:33:52  * AlexisMochaquit (Ping timeout: 240 seconds)
20:34:15  * AlexisMochajoined
20:37:38  * a_lequit (Ping timeout: 265 seconds)
20:40:52  * jgijoined
20:57:25  * sblomjoined
20:59:10  * [spoiler]quit (Quit: I'm running to save my life!)
21:05:00  * stagasjoined
21:17:33  * dshaw_joined
21:20:06  * seishunquit (Remote host closed the connection)
21:22:07  * seishunjoined
21:22:51  * sblomquit (Read error: Connection reset by peer)
21:24:36  * AvianFlujoined
21:40:27  * a_lejoined
21:45:18  * a_lequit (Ping timeout: 265 seconds)
21:49:46  * [spoiler]joined
21:50:20  * abraxas_joined
21:55:43  * abraxas_quit (Ping timeout: 264 seconds)
21:57:03  * a_lejoined
21:58:15  * daviquit (Ping timeout: 264 seconds)
22:09:16  * dshaw_quit (Quit: Leaving.)
22:13:19  <jgi>tjfontaine, trevnorris: does node “officially” support Centos with older libstdc++ or does it leave that to packagers (in this case nodesource if I understand correctly)? That’s in relation to https://github.com/joyent/node/issues/9079
22:21:55  * qardquit (Quit: leaving)
22:23:21  * qardjoined
22:40:00  <chrisdickinson>tjfontaine: jgi: I keep waffling on the "throw errors on conflicting keys" solution. I have it implemented, but it doesn't feel like its a solution that would extend cleanly to the other high-level keys
22:40:42  <jgi>chrisdickinson, tjfontaine: ok, have you seen my latest comment about it: https://github.com/joyent/node/issues/9070#issuecomment-71102085?
22:40:56  <jgi>chrisdickinson, tjfontaine: and once again, sorry for not mentioning that during the meeting :(
22:41:46  <chrisdickinson>no worries! yeah, I saw that – I had it set up to throw the offending mismatch as part of the error message
22:41:55  <chrisdickinson>(which might help track things down)
22:42:14  * iarnaquit (Remote host closed the connection)
22:44:28  <chrisdickinson>one bit I wasn't really aware of is that `url.parse` returns a URL object, not a plain JS object, so that might be a good venue to look into
22:44:45  * zju4quit (Read error: Connection reset by peer)
22:44:55  * zju4joined
22:45:03  <chrisdickinson>(IOW, I thought the suggestion to add `.format` was going to involve more work than it would in reality)
23:00:24  <tjfontaine>hi -- sorry a couple of impromtu meetings grabbed my time after our call
23:00:31  <tjfontaine>chrisdickinson, jgi -- catch me up
23:01:39  <tjfontaine>jgi: ancient libc is supported by libuv, ancient libstdc++ afaik won't compile with current v8
23:02:02  <chrisdickinson>tjfontaine: re: url + path, implemented the PR (https://github.com/joyent/node/pull/9081), jgi expressed concerns about the locality of the error with regards to where the actual problem originated; I have a vague unsettling feeling about spreading the change to other parts of the API
23:04:11  <tjfontaine>vague feelings are the best kind
23:06:08  <jgi>tjfontaine: we could make v0.12 build and run on CentOS, but do we want to take care of it, or do we leave that to packagers?
23:06:28  <tjfontaine>jgi: can we actually do that?
23:06:59  <tjfontaine>I'm not familiar with the relationship of g++ and libstdc++ version, but we need a newer g++ to be able to compile v8
23:09:02  * seishunquit (Ping timeout: 245 seconds)
23:09:23  <jgi>tjfontaine: I haven’t tried it for CentOS and node, but theoretically we could ship a libstc++ (built with a custom-built recent GCC on centos) with the binary and link with rpath
23:09:49  <jgi>tjfontaine: and by CentOS I mean “the oldest Linux platform we’d like to support"
23:10:01  <tjfontaine>blargh .....
23:10:04  <jgi>tjfontaine: :)
23:10:18  <tjfontaine>that is a worst case scenario I think
23:10:20  * roxluquit (Quit: My Mac has gone to sleep. ZZZzzz…)
23:10:38  <tjfontaine>I would agree to finding the oldest working g++ and libstdc++ thus making it easier
23:11:08  <tjfontaine>I think shipping libstdc++ would be particularly frowned upon, also doesn't make node portable for those environments
23:11:29  <tjfontaine>granted node is already not portable if their libstdc++ isn't compatible
23:12:52  <jgi>tjfontaine: there is also the problem of custom native modules which require newer libstdc++
23:13:28  <jgi>tjfontaine: but that’s fine if we don’t ship libstdc++ with the binary
23:16:31  <jgi>tjfontaine: I’m not sure I understand what you mean by “also doesn't make node portable for those environments”
23:19:14  <tjfontaine>jgi: if we ship libstdc++ with rpath set that means you have to carry the libstdc++ in the same place when you move the node binary
23:19:25  <tjfontaine>jgi: there are people who definitely don't want to do that
23:19:41  <jgi>tjfontaine: ok, right
23:19:44  <tjfontaine>[otoh I don't want to be statically linking against dependencies, so no one wins]
23:25:42  * zju1joined
23:29:02  * zju3quit (Ping timeout: 245 seconds)
23:35:04  <jgi>tjfontaine: ok for finding the oldest working g++ and libstdc++, should that be a blocker for v0.12? I have a feeling that with the current dependencies, it would break a lot of users, so I would say yes.
23:35:50  * thlorenzquit (Remote host closed the connection)
23:38:09  <tjfontaine>jgi: that's how we're building v0.10 today, and users aren't complaining?
23:38:55  <jgi>tjfontaine: because v8 in v0.10 doesn’t have a dependency on the recent bits of libstdc++
23:39:28  * abraxas__joined
23:40:02  <jgi>tjfontaine: see after the first half of this comment: https://github.com/joyent/node/pull/8886#issuecomment-67728551
23:40:03  <tjfontaine>I hate c++
23:40:08  <jgi>tjfontaine: :)
23:41:30  <tjfontaine>fuck
23:44:08  * abraxas__quit (Ping timeout: 245 seconds)
23:55:55  <tjfontaine>jgi: I think the answer is find a suitable old enough libstdc++ :/
23:56:16  <jgi>tjfontaine: yes, that’s what I think too, at least for now until we stumble on other issues.
23:56:58  <tjfontaine>jgi: indeed
23:58:36  <jgi>tjfontaine: do you think it’s a blocker for v0.12? I would say yes because it would break a lot of existing users. At the same time I don’t know as of now if we’ll be able to fix this problem for all current users of v0.10 with the “oldest possible libstdc++ solution”. So it’s kind of difficult to know when and how much this problem will be solved.
23:59:40  <rendar>why libstdc++ is needed? i didn't follow the whole conversation, sorry