00:07:07  * graydonquit (Quit: Leaving.)
02:04:31  <dmkbot>joyent/node: Hamms: querystring.stringify can't deal with nested objects - https://github.com/joyent/node/issues/1665
02:07:54  <piscisaureus>DrPizza: do you know how to specify a library search path in gyp?
02:08:22  <DrPizza>to do what, add system lib dirs?
02:08:34  <piscisaureus>DrPizza: no to point to php5ts.lib
02:08:44  <DrPizza>I'm not sure, no
02:08:46  <piscisaureus>which is located outside of my project
02:10:25  * brsonquit (Ping timeout: 252 seconds)
02:25:58  <DrPizza>I think the best solution is to delet ephp and everything related to it
02:27:21  <piscisaureus>muhahah
02:27:31  <piscisaureus>I know, but I'm an idiot
02:27:37  <piscisaureus>in fact, I'm going to quit node
02:27:44  <piscisaureus>work on php for a while
02:27:48  <piscisaureus>them I'm moving to perl
02:27:51  <piscisaureus>of cobol
02:27:58  <piscisaureus>*or
02:29:13  <piscisaureus>Ryan is going to love cobol.
02:29:20  <piscisaureus>max line length == 72 character
02:29:21  <piscisaureus>s
02:34:52  <DrPizza>I'm just trying to think of there's anything possibly even shitter that you could switch to
02:34:58  <DrPizza>nothing springs immediately to mind
02:37:46  <piscisaureus>hmm no me neither
02:38:05  <piscisaureus>brainfuck obviously. but that doesn't count because *nobody* considers that okay
02:39:19  <piscisaureus>oh yes
02:39:21  <piscisaureus>euphoria
02:39:26  <piscisaureus>i used to do that when i was a kid
02:39:47  <piscisaureus>http://www.rapideuphoria.com/ <-- hasn't even changed since then :-)
02:42:21  <DrPizza>yeah I was just thinking of real languages
02:42:25  <DrPizza>brainfuck doesn't really count
03:00:08  <DrPizza>piscisaureus: that euphoria thing looks retarded
03:00:48  <piscisaureus>I moved there just after quickbasic
03:00:53  <piscisaureus>before I got started on c++
03:01:13  <piscisaureus>DrPizza: it was not so bad back then - but not really powerful
03:01:28  <piscisaureus>but today they're still targeting 16-bit dos or that's what it looks like
03:03:00  <piscisaureus>I'm building my php extension with gyp
03:03:04  <piscisaureus>\o/
03:03:08  <piscisaureus><3 gyp
03:03:58  <piscisaureus>I wish php used gyp
04:28:17  * piscisaureusquit (Ping timeout: 258 seconds)
04:34:31  <dmkbot>joyent/libuv: erickt: Fix uv_getaddrinfo to accept custom data. - https://github.com/joyent/libuv/issues/156
05:23:11  * indutnyquit (K-Lined)
05:26:12  * indutnyjoined
05:26:21  * indutnyquit (Remote host closed the connection)
05:28:39  * indutnyjoined
05:54:31  <dmkbot>joyent/node: ArtS: Weird 'require' behaviour - https://github.com/joyent/node/issues/410
05:59:31  <dmkbot>joyent/node: Kos: Misleading console output for arrays with undefined - https://github.com/joyent/node/issues/1651
06:09:31  <dmkbot>joyent/node: ArtS: Weird 'require' behaviour - https://github.com/joyent/node/issues/410
06:14:14  * mralephjoined
06:40:36  * indutnyquit (Ping timeout: 276 seconds)
06:44:31  <dmkbot>joyent/node: ArtS: Weird 'require' behaviour - https://github.com/joyent/node/issues/410
06:49:31  <dmkbot>joyent/node: ArtS: Weird 'require' behaviour - https://github.com/joyent/node/issues/410
06:51:21  * mralephquit (Read error: Connection reset by peer)
07:07:11  * mralephjoined
07:19:36  * indutnyjoined
08:27:39  * mralephquit (Quit: Leaving.)
08:30:25  * dmkbotquit (Ping timeout: 246 seconds)
10:34:50  <indutny>ryah: yt?
12:14:46  * dmkbotjoined
12:44:43  <dmkbot>joyent/node: cryptix: test-fs-utimes - debug assertion fails on win32 - https://github.com/joyent/node/issues/1666
12:48:49  * bnoordhuisjoined
12:58:16  * dmkbotquit (Remote host closed the connection)
12:58:34  * dmkbotjoined
13:17:47  * pieternjoined
13:22:38  <bnoordhuis>zlib?
13:23:32  <dmkbot>joyent/node: ArtS: Weird 'require' behaviour - https://github.com/joyent/node/issues/410
13:27:27  <pietern>hi guys
13:27:46  <pietern>small idea I got working with libuv:
13:28:16  <pietern>why not export things like UV_TCP_FIELDS, UV_PIPE_FIELDS etc
13:28:40  <pietern>so extending these primitives outside libuv is also possible
13:29:10  <pietern>I find myself using a whole lot of type punning and keeping multi layered ->data references
13:29:52  <bnoordhuis>pietern: you mean UV_TCP_PRIVATE_FIELDS and such?
13:29:53  <pietern>with the *_FIELDS thing any "subclass" can be simply type-casted
13:30:21  <pietern>bnoordhuis: no, a full UV_TCP_FIELDS, which includes everything from HANDLE_FIELDS, STREAM_FIELDS and PRIVATE_FIELDS
13:31:14  <pietern>so you can avoid the indirection or typecast when using such a type as first member of a custom struct
13:32:08  <bnoordhuis>pietern: one issue is that the alignment requirements for your struct and the libuv struct may differ
13:32:17  <bnoordhuis>(we already ran into that once in a test)
13:32:29  <bnoordhuis>why don't you use a container_of macro?
13:33:03  <pietern>bnoordhuis: hmm, right the alignment problem would only happen when its not used as first member..
13:33:11  <pietern>not familiar with that macro,
13:33:12  <pietern>looking it up
13:33:35  <pietern>oh right, the offset of trick
13:33:39  <bnoordhuis>yes
13:33:48  <bnoordhuis>btw, it also happens when the struct is the first member
13:34:12  <bnoordhuis>in that test i mentioned, gcc decided that uv_tcp_t had to be aligned at a greater boundary than uv_pipe_t
13:34:20  <bnoordhuis>great fun we had in tracking that one down :/
13:35:09  <pietern>so the offsets of their "superclass" fields didn't line up?
13:35:12  <pietern>sounds like fun… ;)
13:36:18  <bnoordhuis>pietern: do you have relatives in or near meppel or enschede?
13:36:42  <pietern>bnoordhuis: one far-away uncle in meppel, not in enschede
13:36:55  <bnoordhuis>right, i originally hail from meppel :)
13:37:02  <pietern>s/far away/distant/
13:37:23  <bnoordhuis>what's your uncle's name?
13:37:27  <pietern>bnoordhuis: our name isn't that common, we're probably distant relatives :)
13:37:30  <pietern>anco
13:37:45  <pietern>he's a nephew of my father
13:37:51  <bnoordhuis>oh, i don't know any anco's
13:37:59  <bnoordhuis>but yeah, probably distant relatives :)
13:39:06  <pietern>bnoordhuis: do you know of any roots in northern groningen?
13:39:54  <bnoordhuis>bnoordhuis: yes, but only vaguely - great-grand uncles, nieces of the third degree, that kind of thing
13:39:57  <pietern>bnoordhuis: btw, the offsetof trick, that would require having two conversion macro's right, or am I overseeing something?
13:40:50  <pietern>bnoordhuis: right, there's probably something there :) fun to see another noordhuis in programming
13:41:14  <bnoordhuis>pietern: http://lxr.free-electrons.com/source/tools/perf/util/include/linux/kernel.h#L26
13:41:30  <bnoordhuis>so your struct foo embeds a uv_tcp_t* tcp_req
13:41:40  <bnoordhuis>your callback gets passed a tcp_req
13:42:04  <bnoordhuis>and you look up your struct foo with -> struct foo *foo = container_of(tcp_req, struct foo *, tcp_req)
13:42:26  <bnoordhuis>correction: struct foo *foo = container_of(tcp_req, struct foo, tcp_req)
13:42:47  <pietern>bnoordhuis: right, that's similar to what I constructed myself, it only leaves way for the other way around
13:42:54  <bnoordhuis>other way around?
13:43:13  <pietern>e.g. passing foo->tcp_req instead of just foo
13:43:27  <bnoordhuis>oh right
13:43:36  <bnoordhuis>small trade-off though, isn't it?
13:44:24  <pietern>bnoordhuis: yes, indeed,
13:44:45  <pietern>and the potential alignment bugs are worse than some cosmetics
13:44:56  <pietern>thanks for reminding me how time consuming those can be
13:46:02  <bnoordhuis>pietern: you're playing around with libuv in redis?
13:46:38  <pietern>bnoordhuis: I did some superficial experiments earlier
13:47:06  <pietern>no plans to move forward with that, as it has a very thin and proven reactor right now
13:47:19  <pietern>using it on another project now
13:47:25  <bnoordhuis>do tell!
13:47:49  <pietern>it has got to do with high frequency time series collection
13:48:10  <pietern>or: balance between high frequency and high quantity
13:48:32  <dmkbot>joyent/node: cryptix: test-fs-utimes - debug assertion fails on win32 - https://github.com/joyent/node/issues/1666
13:48:32  <pietern>and I'm writing a messagepack wrapper around libuv
13:48:55  <pietern>so the unit of currency becomes a msgpack object instead of a char*
13:49:32  <pietern>and other stuff like limiting the max nr outstanding messages per stream
13:49:45  <bnoordhuis>a message queue kind of thing?
13:49:56  <pietern>that also lead me to the uv_write_t cleanup thing I posted earlier as issue
13:50:25  <pietern>no, it's more that agents will be streaming sampled data into this thing
13:50:36  <pietern>and this thing will be responsible for indexing and storing it
13:50:57  <pietern>so basically the simplest possible uv_tcp_t server + eio for uv_work_t
13:51:06  <pietern>I'm in love with this stack :)
13:51:13  <bnoordhuis>hah, good :)
13:51:16  <bnoordhuis>about that issue you posted
13:51:33  <bnoordhuis>In addition: the current behavior shows that the write is immediately executed when the write queue is empty. When this fails, uv_write returns a -1 status and the uv_write_t can be cleaned up. Shouldn't the write callback for this request be called in the next reactor tick?
13:51:40  <bnoordhuis>is that with tcp on unix?
13:51:47  <pietern>bnoordhuis: yep
13:52:10  <bnoordhuis>immediately executed, that should not / cannot be, i think
13:52:22  <bnoordhuis>the request is put on a deferred queue
13:53:02  <pietern>bnoordhuis: https://github.com/joyent/libuv/blob/master/src/unix/stream.c#L658-667
13:54:56  <bnoordhuis>ah right
13:55:38  <pietern>that struck me as quite odd since uv_close also makes sure to call the callback and delays that to the next tick
13:56:14  <pietern>it's not a big problem, but as for consistency I'd expect it to make a deferred call to the callback
13:56:14  * dmkbotquit (Read error: Operation timed out)
13:58:14  <bnoordhuis>well, we should fix it
13:58:16  <pietern>bnoordhuis: btw, the container_of thing only works when the struct is embedded as a whole, not just a pointer
13:58:21  <bnoordhuis>at the very least it's inconsistent with what udp does
13:58:30  <bnoordhuis>pietern: yes sorry, that was a typo on my part
13:58:40  <pietern>bnoordhuis: np thanks
13:59:49  <pietern>bnoordhuis: what do you think about the write queue cleanup thing?
13:59:50  <bnoordhuis>pietern: you can tweak container_of to work with embedded pointers but it's almost always used to embed structures
14:01:09  <bnoordhuis>pietern: let me get it straight: say you have 5 pending writes and the first one fails with, say, ECONNRESET
14:01:21  <bnoordhuis>what do you think should happen?
14:01:34  <pietern>bnoordhuis: well, the write watchers will probably not fire again
14:01:42  <pietern>although I'm uncertain..
14:02:07  <bnoordhuis>no, but the callbacks will get invoked when you uv_close the handle
14:02:09  <pietern>anyway: when I get a status=-1 on a write callback, I probably want to uv_close the stream asap
14:02:22  <bnoordhuis>(at least, they should be - this was a bug that may or may not have been fixed)
14:02:40  <pietern>bnoordhuis: ok, I couldn't find a trace of that logic being in place
14:02:49  <pietern>bnoordhuis: so maybe that's pending
14:03:11  <bnoordhuis>i can't see it either
14:03:13  <pietern>bnoordhuis: generally the cleanup code for uv_write_t's will be in their callbacks
14:03:16  <bnoordhuis>i'll fix it today
14:03:21  <pietern>at least, that makes sense to me
14:03:35  <pietern>so I'd expect the callbacks to be fired /before/ the uv_close callback is fired
14:03:46  <bnoordhuis>yes, that's what should happen
14:03:55  <pietern>since that would be the place where you cleanup other artifats
14:04:35  <bnoordhuis>for the record, it should work like this: you uv_close the handle, all pending writes get their callbacks invoked with status=-1, then the close callback is invoked
14:04:37  <pietern>at least in a way where subsequent write callbacks are called when flags & UV_CLOSING
14:04:50  <pietern>bnoordhuis: ok
14:04:52  <pietern>great
14:05:25  <pietern>it was what I'd expected
14:05:32  <bnoordhuis>i suspect we haven't actually implemented it yet so i'll fix that :)
14:05:55  <pietern>bnoordhuis: btw, are you FT on node/libuv?
14:06:13  <bnoordhuis>pietern: ft as in full time?
14:06:17  <pietern>yeah
14:06:25  <bnoordhuis>yes, i'm employed by joyent
14:06:32  <pietern>ok, cool
14:06:48  <pietern>just curious, I remember seeing NRC media somewhere
14:06:52  <pietern>:)
14:07:00  <bnoordhuis>oh right, i left there in july
14:07:08  <pietern>I see
14:07:15  <pietern>still based in NL though?
14:07:21  <bnoordhuis>yep, the fair city of gouda
14:07:36  <bnoordhuis>you're in groningen, right?
14:10:27  <pietern>bnoordhuis: yes
14:16:10  <bnoordhuis>bert is often in groningen, have him buy you a beer sometime
14:16:53  <pietern>bnoordhuis: cool, I haven't met him yet
14:17:00  <pietern>although I know he's doing tons of windows work
14:17:15  <pietern>he's also FT joyent?
14:17:30  <bnoordhuis>no, he's a part-timer at rackspace
14:18:45  <pietern>bnoordhuis: btw, I remember a problem with embedding structs
14:19:01  <pietern>uv_stream_t is smaller than uv_tcp_t and uv_pipe_t
14:19:05  <pietern>but they should both work
14:19:30  <bnoordhuis>pietern: put them in a union?
14:19:31  <pietern>so that would require uv_stream_t to include padding 
14:20:01  <bnoordhuis>you should consider uv_stream_t as an abstract base class btw
14:21:10  <pietern>bnoordhuis: right, I need to get used to anonymous unions and the like: we compile redis for c99 compliance
14:24:26  <bnoordhuis>pietern: the union doesn't even have to be anonymous
14:24:45  <bnoordhuis>it just guarantees that it'll be large enough for either uv_tcp_t or uv_pipe_t and that it's properly aligned
14:25:00  <pietern>bnoordhuis: yes, but that results in more deference
14:25:11  <pietern>like foo->union.tcp->loop
14:25:24  <bnoordhuis>don't worry about that, the compiler optimizes away
14:25:37  <bnoordhuis>compiled down to asm, it's just a load
14:25:58  <bnoordhuis>(load as in movl or leal)
14:28:54  <pietern>I know, but I'm trying to get both idiomatic and aesthetically pleasing code ;)
14:29:11  <pietern>nevermind, I'm going with the big dereference and component_of :)
14:29:25  <pietern>isn't worth to dabble too much about this kind of thing
14:29:27  <bnoordhuis>cool, i promise you you'll like it :)
14:30:23  <bnoordhuis>the day i discovered container_of in the kernel headers was a little like a light shineth down from heaven
14:30:29  <bnoordhuis>and a 'why didn't i think of that' moment
14:30:41  <indutny>hi everyone!
14:30:47  <bnoordhuis>hey indutny
14:31:03  <indutny>could anyone help me in testing and giving feedback one one essential node.js feature?
14:31:17  <indutny>bnoordhuis: feedback mostly
14:31:22  <bnoordhuis>depends on your definition of essential :)
14:31:26  <indutny>heh
14:32:03  <indutny>bnoordhuis: it's about debugger
14:32:15  <indutny>I stubbed out most of the things for new debugger
14:32:24  <indutny>but I want to be sure that API is ok
14:32:39  * bnoordhuislistens
14:32:39  <indutny>https://github.com/indutny/node/tree/feature-debugger-test
14:32:45  <indutny>can you please check this out
14:32:54  <indutny>try to build, run node debug script.js
14:33:04  <indutny>and give me a feedback on API
14:33:07  <bnoordhuis>i'm not a fan of GH's new layout, i think :/
14:33:11  <indutny>heh
14:33:19  <indutny>`feature-debugger-test` branch so
14:33:27  <indutny>on git://github.com/indutny/node
14:33:32  <bnoordhuis>indutny: can you submit it as a pull request?
14:33:58  <bnoordhuis>i'll look at it but i'm busy with other stuff atm
14:34:10  <indutny>I'm going to do that, but later (I'll rebase commits)
14:34:26  <indutny>bnoordhuis: can you checkout my repo w/o pull requests when you'll have enough time
14:34:28  <indutny>?
14:34:40  <bnoordhuis>i suppose so
14:34:46  <bnoordhuis>but what's so bad about pull requests?
14:34:46  <indutny>bnoordhuis: thank you!
14:35:08  <indutny>hm...
14:35:25  <indutny>I wanted to rebase it to one commit when I'll finish it
14:35:38  <bnoordhuis>oh that, don't worry
14:35:42  <indutny>ok
14:35:46  <indutny>one second
14:35:58  <bnoordhuis>or create a new feature branch and squash it
14:36:09  <bnoordhuis>but either way it's not a big deal
14:36:14  <indutny>ok
14:39:12  <indutny>https://github.com/joyent/node/pull/1667
14:40:02  <bnoordhuis>thanks, indutny
14:40:06  <indutny>np
14:40:20  <indutny>I'll push more commits to it
14:42:04  <bnoordhuis>okay, cool
14:43:18  <indutny>cc ryah: https://github.com/joyent/node/pull/1667
14:44:33  <indutny>brb
15:07:55  * piscisaureusjoined
15:13:37  <piscisaureus>pietern: re uv_write errror handling. If what you say is true, it is a bug. The write callback should be made for every call to uv_write. I am sure the windows implementation does this, not sure about unix tho - but it should.
15:13:58  <pietern>piscisaureus: thanks for confirming, I discussed this with bnoordhuis earlier
15:14:02  <pietern>and I believe he's fixing
15:14:11  <piscisaureus>pietern: ah, nice.
15:14:18  <piscisaureus>noordhuis family dinner?
15:14:24  <pietern>piscisaureus: all callbacks should also be called from the reactor, right?
15:14:27  <pietern>piscisaureus: ;)
15:14:35  <pietern>that's a libuv invariant
15:15:53  <piscisaureus>pietern: probably most of the errors should. But some errors might not atm, e.g. if your socket is not connected then uv-win reports the error synchronously.
15:16:50  <pietern>ok, but the idea is to defer every callback eventually, right?
15:17:12  <piscisaureus>pietern: hmm...
15:17:26  <piscisaureus>pietern: That may be best, yes
15:17:30  <pietern>piscisaureus: similar to the deferred callback for uv_close,
15:17:44  <pietern>that's not necessary on unix, but it is still done
15:17:51  <piscisaureus>pietern: sure it will always *defer* the callback
15:18:07  <piscisaureus>pietern: but uv_write() could also just return -1
15:18:15  <piscisaureus>then there will never be a callback
15:18:25  <bnoordhuis>piscisaureus: i think we should that fix that
15:18:30  <pietern>piscisaureus: right, in error conditions
15:18:47  <bnoordhuis>piscisaureus: never return an error, always defer the callback
15:18:51  <pietern>but then we would have : -1 == error, no action, no callback
15:18:53  <bnoordhuis>piscisaureus: except for OOM conditions maybe
15:18:58  <pietern>and 0 == action + deferred callback
15:19:11  <piscisaureus>pietern: yes, exactly
15:19:35  <pietern>right, makes 100% sense
15:19:48  <piscisaureus>pietern: uv-win always defers the callback, so that's good.
15:20:10  <piscisaureus>pietern: we have a test for this (test-callback-stack) but maybe write() slipped through
15:20:14  <pietern>yep, there only is uv_write
15:20:23  <pietern>that has: return -1, action, no callback
15:21:00  <pietern>piscisaureus: this will only show in case of a write error
15:21:14  <piscisaureus>yes
15:21:21  <piscisaureus>bnoordhuis: https://github.com/joyent/libuv/blob/master/src/win/tcp.c#L638-641
15:21:27  <piscisaureus>bnoordhuis: we can't really defer that
15:21:51  <piscisaureus>bnoordhuis: but reporting failure with -1 and make no callback seems fine to me
15:22:22  <bnoordhuis>piscisaureus: i suppose you're right
15:23:10  <piscisaureus>bnoordhuis: about our retarded side project: I got $TCP->connect working() :-)
15:23:18  <piscisaureus>incl. making the callback into the vm
15:23:23  <piscisaureus>on windows
15:23:26  <bnoordhuis>piscisaureus: heh, cool
15:23:29  <bnoordhuis>did you push it?
15:23:36  <piscisaureus>bnoordhuis: not yet
15:23:47  <piscisaureus>bnoordhuis: I want to rename the project.
15:24:01  <piscisaureus>we should call it phode or pode or something
15:24:09  <bnoordhuis>phode
15:24:10  <piscisaureus>or puv or puh
15:24:12  <bnoordhuis>i can live with that
15:24:34  <bnoordhuis>we could at sometime in the future split off the uv bindings into a separate project
15:24:48  <bnoordhuis>since it'd actually be useful
15:24:59  <piscisaureus>bnoordhuis: split it off from what?
15:25:05  <bnoordhuis>from... er, phode
15:25:21  <piscisaureus>bnoordhuis: but it *is* uv bindings?
15:25:25  <piscisaureus>I mean, what else is there?
15:25:37  <piscisaureus>or you mean the node-like interface that we're attempting?
15:25:46  <bnoordhuis>node-like sugar yes
15:25:54  <bnoordhuis>and stuff like drizzle
15:25:58  <piscisaureus>bnoordhuis: yeah, maybe
15:26:08  <piscisaureus>bnoordhuis: I didn't get drizzle compiling
15:26:28  <bnoordhuis>piscisaureus: where did it stop?
15:26:29  <piscisaureus>bnoordhuis: I am using gyp to build it on windows, but I didn't feel like creating a gyp file for drizzle
15:26:41  <piscisaureus>bnoordhuis: <3 gyp
15:26:44  <bnoordhuis>:)
15:26:48  <bnoordhuis>commit the gyp files to
15:26:49  <bnoordhuis>*too
15:26:54  <piscisaureus>bnoordhuis: will do
15:27:11  <piscisaureus>bnoordhuis: but the php build variant and the paths of the php includes are hard-coded in the gyp file right now
15:27:12  <bnoordhuis>i'll be a happy camper if i don't have to write a configure.in
15:27:24  <bnoordhuis>oh well, i can live with that for now
15:27:52  <piscisaureus>bnoordhuis: minus the fact that it's hard-coded for my system :-)
15:28:10  <bnoordhuis>move the hard-coded bits into a separate non-versioned file
15:28:12  <piscisaureus>bnoordhuis: let me just commit everything in a messy commit, okay
15:28:15  <pietern>bnoordhuis: re the uv_write thing:
15:28:17  <piscisaureus>so you have the cargo
15:28:26  <bnoordhuis>pietern: yes?
15:29:40  <pietern>I'm not so sure all of a sudden
15:29:48  <pietern>there is another check in there for stream->fd <= 0
15:29:54  <pietern>sorry, < 0
15:30:05  <pietern>that also returns -1 with no action
15:30:11  <pietern>and the user should clean up his uv_write_t
15:30:16  <bnoordhuis>the delayed init stuff
15:30:22  <bnoordhuis>or?
15:30:41  <bnoordhuis>oh right, i see what you mean
15:30:44  <bnoordhuis>raises EBADF
15:30:44  <pietern>no, whether or not uv_write should trigger the callback with status=-1 on failure
15:31:04  <pietern>in a sense, stream < 0 is no different from a failing write
15:31:14  <pietern>since there is no effect in both cases
15:32:22  <pietern>so I'm not sure it should run the callback now..
15:32:37  <pietern>if error == -1 + no action + no callback
15:32:55  <pietern>then uv_write + write < 0 == no action --> no callback
15:34:05  <bnoordhuis>okay, let me ponder this for a bit
15:35:02  <bnoordhuis>does everyone agree that deferring as much as possible is easiest for the caller?
15:35:05  <bnoordhuis>piscisaureus: ^
15:36:32  <bnoordhuis>piscisaureus: also -> https://github.com/Skomski/node/commit/2cb71a42e529003743eec2da173870bf2eb53f57#commitcomment-574520
15:38:23  <pietern>bnoordhuis: I agree
15:38:43  <pietern>although in the case of uv_write, you need some error handling in the return -1 case as well
15:39:04  <piscisaureus>bnoordhuis: can you link me to the code this is about?
15:39:23  <bnoordhuis>piscisaureus: that pull request or libuv?
15:39:27  <piscisaureus>bnoordhuis: libuv
15:40:56  <bnoordhuis>piscisaureus: https://github.com/joyent/libuv/blob/master/src/unix/stream.c#L662 <- stuff like that
15:41:53  <piscisaureus>bnoordhuis: depends on what uv__write does obviously :-)
15:44:04  <piscisaureus>bnoordhuis: okay so to understand this right:
15:44:04  <piscisaureus>We all agree that uv_something either returns 0 and guaranteeds the callback to be made,
15:44:04  <piscisaureus>*or* -1 is returned the the callback is guaranteed not to be made
15:44:04  <piscisaureus>But the discussion is whether uv_write should ever return -1 at all?
15:44:19  <bnoordhuis>yes
15:44:20  <piscisaureus>s/the the/and the/
15:44:27  <bnoordhuis>or should return -1 as much as it does
15:44:50  <bnoordhuis>the EBADF case is an example of where you could still defer the callback
15:45:18  <bnoordhuis>otoh, you can argue that EBADF is a programmer error
15:45:26  <bnoordhuis>so it should fail fast
15:45:52  <pietern>bnoordhuis: if correct use of the api guarantees that it should NOT happen, I'd throw in an assert
15:45:52  <piscisaureus>bnoordhuis: I think I don't want to guarantee that we never return -1
15:46:07  <piscisaureus>pietern is right about that
15:46:26  <pietern>make uv_write return void, have it defer everything
15:46:32  <pietern>and bail when you make a programming error
15:46:56  <bnoordhuis>i can live with that
15:46:57  <pietern>that leaves a single place to deal with the uv_write_t's you create
15:46:59  <pietern>love it
15:46:59  <bnoordhuis>piscisaureus?
15:47:07  <DrPizza>errors shouldbe returned to the caller
15:47:11  <piscisaureus>bnoordhuis: not sure
15:47:13  <DrPizza>immediately
15:47:52  <bnoordhuis>it's a library of course... it should handle invalid input graciously
15:48:21  <piscisaureus>bnoordhuis: this may be doable for tcp uv_write but I don't think we can actually defer in any case
15:49:40  <bnoordhuis>i'm going to ponder this some more
15:49:53  <pietern>sorry to confuse you guys with this
15:49:55  <pietern>;)
15:50:55  <pietern>I think that if graciously handling erroneous usage of the library has impact on its design, an assert is ok
15:51:05  <piscisaureus>we'll have to discuss with ryah
15:51:15  <piscisaureus>if we want this change anyway
15:51:41  <piscisaureus>it sounds nice, unfallible calls :-)
15:52:49  <bnoordhuis>you'll still have to deal with corner cases like malloc returning NULL
15:52:55  <piscisaureus>yes
15:53:04  <pietern>bnoordhuis: does libev handle that?
15:54:06  <piscisaureus>bnoordhuis: in the case of uv_listen it's more problematic
15:54:28  <bnoordhuis>pietern: no - but libev is not the measure of things
15:54:31  <piscisaureus>bnoordhuis: since we do not pass errors to the user, so we can't defer the error in that case
15:55:01  <bnoordhuis>okay, i'll get back to this in a bit
15:55:03  <bnoordhuis>dinner's ready :)
15:55:12  <piscisaureus>say hi to the wife :-p
15:55:16  <pietern>bnoordhuis: I'm leaving for dinner as well,
15:55:18  <pietern>have a good evening
15:55:18  <bnoordhuis>hah, i will :)
15:55:22  <bnoordhuis>you too, pietern
15:55:25  <pietern>thank for the chat!
15:55:33  <pietern>love the work you guys are doing!
15:55:46  <pietern>I/O is a pain, and a solid design for taking that away is very welcome :)
15:55:59  <pietern>later!
15:56:08  * pieternchanged nick to pietern_away
16:03:45  * pietern_awayquit (Quit: pietern_away)
16:14:30  * dmkbotjoined
16:59:40  * graydonjoined
17:24:28  <dmkbot>joyent/node: ArtS: Weird 'require' behaviour - https://github.com/joyent/node/issues/410
17:25:54  * brsonjoined
17:29:28  <dmkbot>joyent/node: ArtS: Weird 'require' behaviour - https://github.com/joyent/node/issues/410
17:34:05  <pquerna>https://github.com/dustin/labrea
17:34:41  <pquerna>https://github.com/dustin/labrea/blob/master/examples/randomerrors.lua
17:36:19  <piscisaureus>pquerna: what's that for?
17:39:38  <pquerna>mjr has that weird issue with a socket sometimes returning ETIMEOUT
17:39:49  <pquerna>with labrea, you can write a lua script to intercept write()
17:39:54  <pquerna>and choose when to return ETIMEOUT
17:40:08  <pquerna>and then hopefully debug the uncatchable exception problem he has had
17:40:34  <piscisaureus>we could also just create a test that monkey patches net.Socket to do the samee
17:40:40  <piscisaureus>prolly less work to set up
17:51:25  <piscisaureus>pquerna: dunno if Lisa bugged you about my time sheets as well, but I'm doing it now.
17:51:35  <piscisaureus>transferring timekeeper data to excel
17:51:37  <piscisaureus>so boring
17:59:32  <bnoordhuis>no scrum call today either, i suppose?
18:01:43  <piscisaureus>I think so
18:02:53  <piscisaureus>bnoordhuis: https://github.com/piscisaureus/phode
18:06:43  <bnoordhuis>piscisaureus: KeyError: 'Undefined variable library in deps/libuv/uv.gyp while loading dependencies of phode.gyp while trying to load phode.gyp'
18:07:09  <piscisaureus>bnoordhuis: I tested it only in windows
18:07:23  <piscisaureus>bnoordhuis: I haven't sorted that out
18:07:28  <bnoordhuis>okay
18:07:31  <piscisaureus>bnoordhuis: look at gen.bat for how to call it
18:07:58  <piscisaureus>(add --Dlibrary=static_library even though we're building a shared one)
18:08:44  <piscisaureus>bnoordhuis: it could also be that --depth wants an absolute path on linux
18:09:06  <piscisaureus>try with --depth=$("pwd") or however you guys do that
18:09:15  <bnoordhuis>--depth=$PWD :)
18:10:15  <piscisaureus>bnoordhuis: but I can verify that $tcp->write and $tcp->connect works now. Although it's not doing proper error handling, doesn't free memory correctly, and doesn't validate arguments
18:20:23  <piscisaureus>bnoordhuis: also I think we should use namespaces anyway
18:20:34  <bnoordhuis>piscisaureus: why?
18:20:44  <piscisaureus>you can't have nested classes
18:21:00  <piscisaureus>e.g. uv::tcp::createConnect() <-- not possible
18:21:14  <piscisaureus>also there is no good support for aliasing
18:22:07  <piscisaureus>with namespaces you could just have:
18:22:07  <piscisaureus>use uv\tcp;
18:22:07  <piscisaureus>createConnection("google.com", 80, onConnection);
18:23:50  <bnoordhuis>okay
18:24:00  <bnoordhuis>ugly but hey, that's php
18:33:34  <bnoordhuis>../../opt/php5/include/php/main/php.h:298: warning: type defaults to �int� in declaration of �inline�
18:33:34  <bnoordhuis>../../opt/php5/include/php/main/php.h:298: error: expected �,� or �;� before �void�
18:33:37  <bnoordhuis>fsck
18:50:25  * mralephjoined
18:56:00  <bnoordhuis>piscisaureus: do you have an example file?
19:06:53  <piscisaureus>bnoordhuis: i will be back later, but quicky:
19:06:53  <piscisaureus>$t = new TCP();
19:06:53  <piscisaureus>$t->connect("127.0.0.1", 5432, function () use ($t) {
19:06:53  <piscisaureus> echo "connected!\n";
19:06:53  <piscisaureus> $t->write("gheh!", function() use ($t) {
19:06:54  <piscisaureus> echo "written!\n";
19:06:54  <piscisaureus> });
19:06:55  <piscisaureus>});
19:26:32  <piscisaureus>bnoordhuis: so did it work?
19:26:44  <bnoordhuis>piscisaureus: yep
19:26:52  <bnoordhuis>needed to add a uv_run() though :)
19:27:16  <piscisaureus>yes, sure
19:28:02  <piscisaureus>bnoordhuis: so where to go from her?
19:28:10  <piscisaureus>We need proper cleanup of reqs and handles
19:28:36  <bnoordhuis>yes
19:28:54  <bnoordhuis>let's see if i can get close() to work
19:29:24  <piscisaureus>bnoordhuis: I think we can use the same trick as node: grab a handle to oneself and drop it in the close callback
19:29:36  <piscisaureus>in this case it would be just Z_ADDREF_P
19:29:49  <bnoordhuis>er?
19:30:14  <piscisaureus>bnoordhuis: you have to be careful that you don't free a handle's memory before the close callback is made
19:30:30  <bnoordhuis>yes
19:30:56  <piscisaureus>bnoordhuis: so just Z_ADDREF after uv_init, and Z_DELREF in close_cb
19:31:15  <bnoordhuis>right
19:31:19  <piscisaureus>bnoordhuis: then actually free the memory when php's gc wants to
19:32:25  <bnoordhuis>are strings still byte arrays in php 5.5?
19:32:36  <piscisaureus>not sure
19:32:45  <piscisaureus>I think they are moving towards multibyte
19:33:23  <piscisaureus>but in php dealing with string encoding is up to user, so I think it's safe to just write it as a byte array
19:33:47  <piscisaureus>bnoordhuis: it's definitely not going to be utf16 or something weird like that
19:34:57  <piscisaureus>bnoordhuis: I'm gonna try to make listen() work
19:35:12  <bnoordhuis>piscisaureus: quick binging suggests in-core multibyte support is a php6 thing
19:35:19  <bnoordhuis>cool, i'll hack on close()
19:35:28  <bnoordhuis>oh, and let's use container_of
19:35:32  <bnoordhuis>less hassle with pointers
19:35:34  <piscisaureus>bnoordhuis: php6 is off the map
19:35:47  <piscisaureus>there are no actual attempts to do it
19:36:05  <bnoordhuis>php6 you mean?
19:36:09  <piscisaureus>yes
19:36:14  <bnoordhuis>just like perl6!
19:37:31  <piscisaureus>bnoordhuis: btw, I want to strive for the node api directly
19:37:39  <piscisaureus>no " internal" binding layer
19:37:56  <bnoordhuis>you mean no php code?
19:38:05  <piscisaureus>yes, no php code
19:38:05  <piscisaureus>or?
19:38:17  <bnoordhuis>fine by me
19:38:28  <piscisaureus>I don't know how that is going to work out
19:38:52  <bnoordhuis>i don't think you can really, from a native php add-on
19:38:56  <bnoordhuis>unless you eval it :)
19:39:12  <piscisaureus>that is a fine solution by itself
19:39:26  <piscisaureus>we could have a php2c build step :-)
19:40:09  <piscisaureus>we'll need some kind of eventemitter :-/
19:40:53  <bnoordhuis>that's conceptually easy enough isn't it?
19:41:06  <piscisaureus>yes, sure
19:41:21  <piscisaureus>but it would be nice to inherit an eventemitter class in c-land
19:41:26  <piscisaureus>I don't know how to do that
19:44:41  <bnoordhuis>grep for 'overloaded', there are api functions for that
19:45:20  <bnoordhuis>INIT_OVERLOADED_CLASS_ENTRY
19:46:59  <bnoordhuis>we should pass the handle - $t - as the first argument
19:47:16  <piscisaureus>bnoordhuis: also, do you know if it is possible to throw from c?
19:47:57  <bnoordhuis>piscisaureus: yes, zend_throw_exception
19:48:16  <piscisaureus>ok, thnx
19:48:21  <piscisaureus>you know so much about php
19:48:23  <piscisaureus>scary
19:48:24  <piscisaureus>:-)
19:52:50  <bnoordhuis>i wrote some internal pecl modules when i was at ziggo
19:57:15  <bnoordhuis>yay, close() works
19:57:32  <bnoordhuis>still leaking memory left and right though
19:57:33  <bnoordhuis>=== Total 10 memory leaks detected ===
19:57:43  * dmkbotquit (Remote host closed the connection)
19:58:01  * dmkbotjoined
19:58:02  <piscisaureus>bnoordhuis: sure, I've made no attempt whatsoever to free memory so far
19:58:37  <bnoordhuis>one thing with close() is, the handle's dead but the php object is still alive
19:59:05  <piscisaureus>bnoordhuis: you need to efree() in tcp_wrap_free
19:59:11  <piscisaureus>php doesn't do this
19:59:20  <bnoordhuis>yes, that's the case
19:59:25  <bnoordhuis>but it works like this now:
19:59:35  <bnoordhuis>php code calls $handle->close()
19:59:58  <piscisaureus>yes, ok
20:00:16  <piscisaureus>bnoordhuis: but php's gc calls tcp_wrap_free when the object goes out of scope
20:00:36  <bnoordhuis>yes, but that's not the case yet after $handle->close()
20:00:57  <piscisaureus>bnoordhuis: that's fine right
20:00:58  <bnoordhuis>so presumably the php code could call $handle->close() again and bad things would happen
20:01:03  <piscisaureus>I mean, in js it's the same
20:01:14  <piscisaureus>bnoordhuis: yeah, we need to prevent that
20:01:18  <bnoordhuis>we should add a 'is dead' check
20:01:23  <bnoordhuis>simple enough to do
20:01:33  <piscisaureus>Make it a macro
20:01:41  <piscisaureus>so we can use it everywhere
20:02:11  <bnoordhuis>yep
20:06:18  * brsonquit (Ping timeout: 260 seconds)
20:07:08  * brsonjoined
20:10:15  * brsonquit (Read error: Connection reset by peer)
20:10:48  * brsonjoined
20:11:16  <bnoordhuis>piscisaureus: variable naming: tcp_wrap or self?
20:11:25  <piscisaureus>bnoordhuis: is there a good reference for the php api?
20:11:28  <piscisaureus>*shrug*
20:11:31  <piscisaureus>both are okay
20:11:42  <piscisaureus>bnoordhuis: I am looking for docs on zend_hash_init
20:12:11  <bnoordhuis>piscisaureus: read the source, more reliable than any documentation you'll find online
20:12:31  <bnoordhuis>you can run doxygen over the source but the php source code is pretty low on useful comments
20:12:38  <piscisaureus>yes
20:12:45  <piscisaureus>and macro clusterfucks all over the place :-(
20:17:35  <bnoordhuis>quite
20:17:43  <bnoordhuis>object healthcheck is in place
20:19:19  <bnoordhuis>i'll start on the event emitter
20:19:35  <piscisaureus>kewl. I was also doing that but getting nowhere/
20:19:38  <piscisaureus>so you do it
20:21:28  <bnoordhuis>that's why you were asking about zend_hash, i take it? :)
20:22:03  <piscisaureus>bnoordhuis: yes
20:22:14  <piscisaureus>bnoordhuis: can you commit local.gypi skeletton?
20:22:23  <bnoordhuis>piscisaureus: sure
20:23:16  <bnoordhuis>piscisaureus: but the idea is that it's, well, local
20:23:22  <bnoordhuis>as in non-versioned
20:23:34  <piscisaureus>bnoordhuis: yes, sure
20:23:44  <piscisaureus>bnoordhuis: we could rename it to local.gypi.example
20:23:50  <piscisaureus>so ppl know what to fill out
20:23:59  <bnoordhuis>okay
20:26:43  * GitHub27joined
20:26:43  <GitHub27>[phode] none pushed 3 new commits to master: https://github.com/piscisaureus/phode/compare/ec34419...649eb3d
20:26:43  <GitHub27>[phode/master] rename module to phode - Ben Noordhuis
20:26:43  <GitHub27>[phode/master] implement TCP::close() - Ben Noordhuis
20:26:43  <GitHub27>[phode/master] throw exception when method is called on a dead handle - Ben Noordhuis
20:26:43  * GitHub27part
20:30:38  <bnoordhuis>spiffy :)
20:32:02  <bnoordhuis>piscisaureus: define PHP_INCLUDE_PATH in your local.gypi
20:32:25  <piscisaureus>^-- I'd like to use CIA for that but ryah claimed #libuv
20:34:26  <piscisaureus>bnoordhuis: you left -l../php/Debug_TS/php5ts_debug.lib in phode.gyp
20:34:29  <piscisaureus>does that work?
20:34:53  <bnoordhuis>it does nothing for me, i don't have to link against anything
20:34:54  <piscisaureus>oh hmm nvm
21:18:52  * mraleph1joined
21:18:55  * mralephquit (Read error: Connection reset by peer)
21:23:03  * phodejoined
21:23:03  <phode>[phode] piscisaureus pushed 2 new commits to master: https://github.com/piscisaureus/phode/compare/935f05e...9285c85
21:23:03  <phode>[phode/master] Clean up build system files - Bert Belder
21:23:03  <phode>[phode/master] Update .gitignore - Bert Belder
21:23:03  * phodepart
21:24:42  * phodejoined
21:24:42  <phode>[phode] piscisaureus pushed 1 new commit to master: https://github.com/piscisaureus/phode/commit/de821adbe12a74dd993a8cef5c1d49e884292928
21:24:42  <phode>[phode/master] Fix NTS build - Bert Belder
21:24:42  * phodepart
21:25:07  <bnoordhuis>piscisaureus: NTS or ZTS?
21:25:17  <piscisaureus>no NTS == Not thread-safe
21:25:39  <piscisaureus>I forgot to define TSRMLS_D_GET when ZTS off
21:25:50  <bnoordhuis>oh, so we have to test that too
21:25:53  <bnoordhuis>pain!
21:26:02  <piscisaureus>bnoordhuis: no, let's not test that
21:27:41  <bnoordhuis>piscisaureus: you broke my build >:(
21:27:42  <bnoordhuis>NameError: name 'visibility' is not defined while evaluating condition 'visibility=="hidden"' in phode.gyp while trying to load phode.gyp
21:27:48  <piscisaureus>gheh
21:27:49  <piscisaureus>sorry
21:27:54  <piscisaureus>I thought that was needed only for v8
21:28:19  <piscisaureus>bnoordhuis: restore it in common.gypi
21:28:41  <piscisaureus>bnoordhuis: x-platform build system setup still painful
21:29:31  * phodejoined
21:29:31  <phode>[phode] bnoordhuis pushed 1 new commit to master: https://github.com/piscisaureus/phode/commit/9f82424944e5b1a9017182dee8c42ba444d86a7a
21:29:31  <phode>[phode/master] build: unbreak build on unix - Ben Noordhuis
21:29:31  * phodepart
21:29:44  <bnoordhuis>make that bot post to #node.js :)
21:29:54  <piscisaureus>troll bot
21:30:03  <piscisaureus>can't do, it'll do only 1 channel
21:30:06  <bnoordhuis>aww
21:30:22  <piscisaureus>maybe I'm wrong, but I'm not doing it anyway
21:33:31  <CIA-52>node: Sean Cunningham master * reb99083 / (4 files in 3 dirs): tls: add client-side session resumption support - https://github.com/joyent/node/commit/eb99083d0bbca437e62d0959ca8dd0cb73bb04fa
21:33:31  <CIA-52>node: Ben Noordhuis master * r6387736 / src/node_crypto.cc : tls: new[] instead of malloc() in Connection::GetSession() - https://github.com/joyent/node/commit/638773628cf8568025d51fd9582ed11a5866be28
21:42:12  <piscisaureus>bnoordhuis: should we have a separate class for server and socket?
21:43:56  <bnoordhuis>piscisaureus: hmm, don't think so
21:44:05  <bnoordhuis>i don't see any compelling reason
21:45:27  <piscisaureus>ok. time will tell :-)
21:52:58  <dmkbot>joyent/node: Kos: Misleading console output for arrays with undefined - https://github.com/joyent/node/issues/1651
22:03:10  <piscisaureus>bnoordhuis: do you know if Z_STRVAL string are 0-terminated?
22:03:30  * mraleph1quit (Quit: Leaving.)
22:04:08  <bnoordhuis>piscisaureus: they should be
22:04:30  <bnoordhuis>but i don't think it's actually illegal
22:04:40  <bnoordhuis>(to not be nul terminated, that is)
22:04:44  <piscisaureus>hmm
22:04:47  <piscisaureus>:-(
22:04:57  <piscisaureus>I'm gonna assume that they are for the moment
22:07:21  <pquerna>bnoordhuis++ // phode
22:07:32  <piscisaureus>pquerna: are you serious?
22:07:48  <pquerna>yes
22:08:06  <pquerna>i was talkig to someone at summercamp about it
22:08:18  <pquerna>php is a nice language, baring the massive stdlib, and the zend engine
22:08:24  <pquerna>and that OO was BOLTED on the side
22:08:27  <pquerna>but otherwise, i like it
22:08:34  <piscisaureus>pquerna: hmm.
22:08:37  <pquerna>just dislike the massive stdlib :)
22:08:39  <piscisaureus>I am not so serious
22:08:40  <pquerna>so replace it !
22:08:57  <piscisaureus>we just conceived this when we were drunk last thursday
22:09:05  <bnoordhuis>^ 'tis true
22:09:07  <pquerna>lol
22:09:20  <pquerna>well, i might of been drunk when I said it was a good idea too
22:09:29  <piscisaureus>hahaha
22:09:32  <piscisaureus>pquerna++ :-)
22:09:59  <bnoordhuis>piscisaureus: Z_STRVALs are nul-terminated, i looked it up
22:10:05  <piscisaureus>nice :-)
22:10:28  <piscisaureus>bnoordhuis: I really like libuv actually
22:10:31  <piscisaureus>makes this all very easy
22:10:51  <piscisaureus>even the alloc_cb is nice - we can just emalloc() our buffers now
22:10:57  <piscisaureus>make them a string in the same pass
22:18:59  <piscisaureus>bnoordhuis: it would be nice if we had a uv_is_listening function
22:19:04  <piscisaureus>and a uv_is_connected as well
22:19:16  <piscisaureus>uv_is_connection would be better
22:19:35  <bnoordhuis>piscisaureus: why? client code can track that itself
22:19:50  <piscisaureus>bnoordhuis: yes, but now the client code needs to do it
22:19:59  <piscisaureus>and since libuv is tracking it anyway
22:20:04  <piscisaureus>we might as well expose that
22:20:27  <piscisaureus>I mean we also have uv_is_active for timers and the like - the client could track that too
22:20:41  <bnoordhuis>piscisaureus: good point
22:20:45  * bnoordhuisremoves uv_is_active
22:21:24  <bnoordhuis>i suppose you have a point, piscisaureus
22:21:32  <bnoordhuis>but we don't need it right now
22:21:44  <piscisaureus>s/we/you/ :-)
22:22:59  <piscisaureus>bnoordhuis: the only reason that I'm not adding it right now is that I don't feel like upgrading libuv
22:24:52  <bnoordhuis>the thing is that i like to wait with adding convenience functions until the api has matured
22:25:02  <bnoordhuis>and the internals, for that matter
22:25:04  <piscisaureus>yeah, makes sense
22:25:43  <piscisaureus>bnoordhuis: how do I construct a new TCP object from c?
22:25:52  <piscisaureus>I mean, tcp_new doesn't return a zval
22:26:05  <bnoordhuis>piscisaureus: my first guestion is: why would you want to do that? :)
22:26:13  <piscisaureus>bnoordhuis: accepting connections
22:26:23  <piscisaureus>I need to construct a new TCP object from the connection_cb
22:27:14  <bnoordhuis>piscisaureus: 1 sec, let me look it up - it's something like zend_new_object
22:32:58  <dmkbot>joyent/node: nzakas: stdout not flushed upon exit with output redirect - https://github.com/joyent/node/issues/1669
22:33:35  <bnoordhuis>piscisaureus: sorry, don't know
22:34:17  <piscisaureus>bnoordhuis: okay, no problem
22:35:01  * indutnyquit (Read error: Connection reset by peer)
22:35:45  <bnoordhuis>piscisaureus: oh wait
22:36:14  <bnoordhuis>tcp_wrap->obj is a zvalue_value
22:36:41  <bnoordhuis>oh, but a zvalue_value is not a complete zval :/
22:39:04  <bnoordhuis>piscisaureus: i haven't tried it but you should be able to turn tcp_wrap->obj in a zval
22:40:38  <bnoordhuis>piscisaureus: and for completeness sake, Z_OBJVAL(tcp_wrap->obj) returns the object you can pass to zend_object_std_init()
22:48:36  <bnoordhuis>piscisaureus: question: why does uv_tcp_write() want a uv_loop_t? it knows what loop the handle belongs to right?
22:48:50  <piscisaureus>bnoordhuis: uv_tcp_write is internal
22:49:07  <bnoordhuis>err, nm :)
22:49:08  <piscisaureus>bnoordhuis: in uv_win we shuffle the loop arg around on the stack
23:05:29  * indutnyjoined
23:24:18  <piscisaureus>bnoordhuis: can you help me out with c?
23:24:31  <bnoordhuis>piscisaureus: sure, what's the problem?
23:25:14  <piscisaureus>zval* args[1]; args[0] = foo; do_something_with_zval***(&args) <- doesn't work
23:25:14  <piscisaureus>zval** args; args = &foo; do_something_with_zval***(&args) <- works
23:25:24  <piscisaureus>what am I doing wrong?
23:25:59  <piscisaureus>bnoordhuis: ^
23:26:14  <bnoordhuis>do_something_with_zval takes a pointer to ***zval?
23:26:19  <piscisaureus>yes
23:27:38  <bnoordhuis>it depends on what do_something_with_zval does
23:27:56  <piscisaureus>bnoordhuis: just pass the pointer to zval** along
23:28:03  <piscisaureus>bnoordhuis: I can get it to compile
23:28:10  <bnoordhuis>without warnings?
23:28:11  <piscisaureus>but it seems to be semantically different
23:28:51  <bnoordhuis>yes
23:29:02  <piscisaureus>bnoordhuis: 2>src\ext.c(316): warning C4047: 'function' : 'zval ***' differs in levels of indirection from 'zval *(*)[1]'
23:29:40  <bnoordhuis>overzealous compiler
23:29:50  <bnoordhuis>the array decays into a pointer
23:30:18  <bnoordhuis>a pointer to ***zval, that is
23:30:25  <bnoordhuis>what kind of function is it anyway?
23:30:34  <piscisaureus>call_callback
23:30:50  <piscisaureus>it sets function_call_info.params
23:30:57  <piscisaureus>which has type zval***
23:31:14  <piscisaureus>iow, a pointer to an array of zval pointers
23:33:13  <bnoordhuis>right, i see what you mean
23:33:36  <bnoordhuis>though i don't quite understand why it has to be zval***
23:34:08  <piscisaureus>me neither
23:34:50  <bnoordhuis>but zval*[1] == zval**
23:34:58  <piscisaureus>yeah, sure
23:35:26  <piscisaureus>that's why I am surprised
23:35:41  <piscisaureus>it's also in debug mode, it shouldn't do any optimization
23:36:47  <piscisaureus>bnoordhuis: maybe it creates only a pointer to zval[1] on the stack
23:37:35  <bnoordhuis>oh, that's another thing
23:38:02  <bnoordhuis>if that function_call_info.params thing lives longer than the call_callback function
23:38:09  <piscisaureus>doesn't
23:38:14  <piscisaureus>pretty sure
23:38:16  <bnoordhuis>okay, no problem there then
23:38:47  <piscisaureus>bnoordhuis: zval (*args)[1]; <- maybe that
23:39:09  <piscisaureus>problem: args[0] = zval_ptr then gives me "lvalue not modifiable"
23:40:47  <bnoordhuis>piscisaureus: https://gist.github.com/2e18f5b0b7b7b7b01f1e <- what does your compiler say about that?
23:41:35  <piscisaureus>bnoordhuis: nothing, it is happy with that
23:42:59  <bnoordhuis>piscisaureus: hmm, weird
23:43:11  <bnoordhuis>can you send over your code?
23:43:17  <bnoordhuis>make a branch or something
23:44:01  <piscisaureus>bnoordhuis: just a sec
23:47:25  <bnoordhuis>oh, i know what your compiler is complaining about
23:48:15  * phodejoined
23:48:15  <phode>[phode] piscisaureus pushed 1 new commit to master: https://github.com/piscisaureus/phode/commit/843799d12f4eab33bccc456868003eda52cbe26f
23:48:15  <phode>[phode/master] work on tcp->listen() - Bert Belder
23:48:15  * phodepart
23:48:16  <bnoordhuis>that function wants zval***, a mutable pointer to zval**, but &(zval*[1]) is not that
23:48:35  <piscisaureus>ah :-)
23:49:26  <piscisaureus>bnoordhuis: the offending piece: https://github.com/piscisaureus/phode/blob/843799d12f4eab33bccc456868003eda52cbe26f/src/ext.c#L314-316
23:49:38  <ryah>hey
23:49:52  <piscisaureus>hey ryah
23:49:56  <piscisaureus>how are you?
23:50:05  <ryah>good - tired
23:50:45  <bnoordhuis>piscisaureus: zval* args[1]; args[0] = &foo; zval** argp = &args; do_something_with_zval(&argp);
23:50:53  <bnoordhuis>that's what you want
23:51:07  <piscisaureus>ok let me try
23:51:12  <ryah>phode?
23:51:20  <bnoordhuis>it's all the rage!
23:53:28  <piscisaureus>bnoordhuis: yes, I can curl it now
23:53:34  * phodejoined
23:53:34  <phode>[phode] piscisaureus pushed 1 new commit to master: https://github.com/piscisaureus/phode/commit/4e4accd21d93981ad068b4cdbf8d7f06db082d58
23:53:34  <phode>[phode/master] bnoordhuis' arg fix - Bert Belder
23:53:34  * phodepart
23:53:35  <piscisaureus>bnoordhuis: no eventemitter yet tho
23:54:15  <bnoordhuis>piscisaureus: sorry, got side-tracked by my day job :)
23:54:27  <piscisaureus>bnoordhuis: yes, I bet
23:54:34  <piscisaureus>I am quitting this too
23:54:43  <piscisaureus>now ryah is back we gtg back to $work
23:54:58  <bnoordhuis>play time is over :(
23:56:23  <ryah>git hub looks all different
23:56:37  <piscisaureus>ryah: huh? what are you talking about?
23:56:40  <ryah>so much changed since ive been gone
23:56:43  <ryah>https://github.com/joyent/node/commits/master
23:56:44  <piscisaureus>ryah: nothing changed
23:56:51  <piscisaureus>it must be you!
23:56:54  <piscisaureus>omg ryah is ill
23:57:23  <bnoordhuis>so...
23:57:28  <bnoordhuis>how was nodeconf, ryah?
23:57:37  <ryah>it was fun - i met igor
23:57:46  <bnoordhuis>how's igor in real life?
23:58:01  <ryah>i got wildly drunk, made a fool of myself, etc. the usual.
23:58:13  <bnoordhuis>all in a day's work
23:58:36  <ryah>igor is very nice and looks exactly like he sounds
23:58:59  <piscisaureus>hmm
23:59:14  <piscisaureus>No particular picture comes to mind