19:25:26  * sergimquit (Quit: Computer has gone to sleep.)
19:25:58  <piscisaureus_>luckily it is easy to restart:
19:25:58  <piscisaureus_>ssh root@logs.libuv.org
19:25:58  <piscisaureus_>$ svcadm restart slurp
19:26:02  <piscisaureus_>but I already did it
19:26:35  * TheJHjoined
19:28:04  * EhevuTov_joined
19:29:21  * kazuponjoined
19:30:11  * loladiroquit (Quit: loladiro)
19:31:16  * EhevuTovquit (Ping timeout: 252 seconds)
19:38:22  <creationix>I think uv_fs_read and uv_fs_write are the hardest for me to write bindings for
19:38:28  * kazuponquit (Ping timeout: 245 seconds)
19:38:54  <piscisaureus_>why?
19:39:40  * EhevuTov_quit (Quit: Leaving)
19:40:51  <creationix>just complicated
19:40:56  <creationix>especially managing the data
19:41:30  <creationix>I wish the on_read callback has a pointer to the buffer in req->pty
19:42:10  <creationix>also, on uv_fs_write, how long to I need to make sure the data buffer is valid?
19:42:16  <creationix>till the callback is called I assume?
19:42:53  <piscisaureus_>yup
19:43:13  <piscisaureus_>euh
19:43:22  <piscisaureus_>creationix: you get the buffer as an argument right?
19:43:27  <piscisaureus_>atleast for reads
19:43:57  <creationix>where?
19:44:04  <creationix>I can't find docs anywhere on that
19:44:14  <creationix>everyone just passes the buffer along manually using some other data structure
19:44:42  <creationix>this is for fs on read, not stream on read
19:44:47  <piscisaureus_>ah,true
19:44:55  <piscisaureus_>obviously it is somewhere in the req :-)
19:45:08  <creationix>hmm
19:45:15  * creationixgoes a printf-ing
19:46:21  <piscisaureus_>not cross platform
19:46:22  <piscisaureus_>hehe
19:46:36  <piscisaureus_>I suppose we could stick in there
19:47:22  <bnoordhuis>nah. it's a matter of organizing your code
19:48:27  <creationix>I mean, fs_readlink puts it's data in req->ptr
19:48:51  <creationix>why can't req->pty point to the buffer that was passed in when fs_read or fs_write was called?
19:49:37  <piscisaureus_>creationix: bnoordhuis is the most expensive engineer here. I suppose he must be right.
19:50:09  <piscisaureus_>infact I don't like uv_fs at all :-)
19:50:12  <creationix>bnoordhuis, of course I can create a new struct and store the buffer there and chain that to req->data, but that seems like such a waste
19:50:20  <piscisaureus_>or
19:50:33  <bnoordhuis>creationix: because it's an implementation detail and one that may change someday
19:50:40  <piscisaureus_>struct tim_fs_t {
19:50:40  <piscisaureus_> uv_fs_t u;
19:50:40  <piscisaureus_> uv_buf_t buf;
19:50:40  <piscisaureus_>}
19:50:50  <creationix>so what is API and what is private
19:50:52  <bnoordhuis>^ that. embed it
19:51:05  <bnoordhuis>creationix: anything not explicitly marked public is private
19:51:12  <piscisaureus_>eu
19:51:17  <piscisaureus_>bnoordhuis: not quite I think
19:51:27  <bnoordhuis>well, it's a good rule of thumb
19:51:30  <creationix>right, so uv.h is public
19:51:34  <piscisaureus_>in uv.h it's more like
19:51:43  <bnoordhuis>though it doesn't quite hold for uv_fs_t
19:51:48  <piscisaureus_>everything in uv.h is public unless it's marked private
19:51:49  <creationix>but it doesn't have any comments on how to use most of uv_fs_*
19:51:55  <creationix>I learned how to use it reading node source
19:52:02  <creationix>and reading libuv private source
19:52:08  <piscisaureus_>hmm
19:52:09  <creationix>but then I have no idea what's supported
19:52:47  <bnoordhuis>i'll update uv.h
19:53:12  <bnoordhuis>only errorno, fs_type and result are public
19:53:29  <bnoordhuis>and statbuf
19:53:42  <creationix>and readdir, readlink?
19:53:46  <creationix>how do I get their data
19:54:16  <bnoordhuis>sorry, ptr is too
19:54:21  <bnoordhuis>only in some cases though :)
19:54:36  <bnoordhuis>the documentation could be improved, yes
19:54:42  <creationix>yeah, docs would help save me a lot of guesswork there
19:54:46  <piscisaureus_>the api sanity too haha
19:55:31  <creationix>but regarding the buffer for uv_fs_write and uv_fs_read, is there a technical reason you can't point to it with ptr?
19:55:36  <creationix>that would be terribly useful to me
19:55:47  <creationix>I've already got a struct I store at ->data
19:55:57  <creationix>and I don't want to special case just for those two types
19:56:38  <piscisaureus_>no there's no technical reason
19:56:49  <piscisaureus_>although i'd prefer uv_buf_t here :-)
19:58:22  <bnoordhuis>piscisaureus_: things would be a lot cleaner if we had per-operation structs instead of just uv_fs_t
19:58:29  <piscisaureus_>yes
19:58:52  <bnoordhuis>who thought up the current api anyway? it wasn't me, of this i'm sure :)
19:58:59  <piscisaureus_>me neither
19:59:09  <bnoordhuis>oh, that one guy? the one we had to let go?
19:59:19  <piscisaureus_>yeah or maybe even that other guy that we had to let go
19:59:29  <piscisaureus_>but I remember that it was under a certain time pressure
19:59:41  <bnoordhuis>yeah, and something of an afterthought
19:59:48  <bnoordhuis>"we rock, libuv is almost done. oh right, fs"
19:59:54  <piscisaureus_>yes :-)
20:00:20  * TheJHquit (Read error: Operation timed out)
20:01:25  <piscisaureus_>I think igor yanked out the windows bits within the week or so
20:03:29  * sergimjoined
20:04:02  * felixgejoined
20:05:30  <bnoordhuis>piscisaureus_: so, uv_cancel()
20:05:40  * felixgequit (Client Quit)
20:05:46  <piscisaureus_>bnoordhuis: yes
20:05:46  <bnoordhuis>my main beef is that cancelling arbitrary requests isn't easy
20:05:47  <piscisaureus_>bnoordhuis:
20:05:50  * felixgejoined
20:05:51  <bnoordhuis>some need cleanup, some don't
20:05:52  <piscisaureus_>true
20:06:03  <piscisaureus_>but this is about pubic api
20:06:15  <bnoordhuis>ghehe, you said pubic
20:06:22  <piscisaureus_>there's no need to make it bigger than public
20:06:34  <bnoordhuis>the innuendos keep coming
20:06:56  <piscisaureus_>aw, /me makes appointment with freudian therapist
20:07:02  <bnoordhuis>hah
20:07:27  <bnoordhuis>actually, i thought up a solution (kind of) for uv_fs_t reqs
20:07:50  <piscisaureus_>bnoordhuis: obviously we could just make uv_cancel a big switch statement
20:07:51  <bnoordhuis>there's a big after_cb now but that could be split up in per-fs_type cbs
20:08:01  <piscisaureus_>yeah, that'd work
20:08:12  <bnoordhuis>and invoke them with a cancelled=1 argument
20:08:18  <bnoordhuis>lot of work though
20:08:22  <piscisaureus_>huh
20:08:36  <piscisaureus_>why not report r=-1 and errno=ECANCELLED?
20:08:59  <bnoordhuis>or that. but we're talking internal functions here so the exact details don't matter
20:09:40  <piscisaureus_>bnoordhuis: what we'd need is
20:09:43  * lohkeyquit (Ping timeout: 260 seconds)
20:09:52  <bnoordhuis>or or or... remove the uv_fs_t from the pending queue and put it on the completed queue with a flag saying 'cancelled'
20:10:06  <piscisaureus_>yeah
20:10:08  <bnoordhuis>then invoke the user's cb with r=-1 and loop->err.code=UV_CANCELLED
20:10:14  <piscisaureus_>that'd make sense right?
20:10:18  <bnoordhuis>i think so
20:10:21  <piscisaureus_>it would also work for getaddrinfo
20:10:42  <bnoordhuis>then it becomes the responsibility of the user to clean up
20:10:47  <piscisaureus_>uv_write/uv_connect/uv_shutdown is a little more difficult
20:10:48  <bnoordhuis>sounds like a plan :)
20:10:52  <piscisaureus_>haha
20:11:22  <piscisaureus_>bnoordhuis: but if we support only work at first, and maybe fs/getaddrinfo i'd be fine
20:11:28  <bnoordhuis>what are the issues with connect/write/shutdown?
20:11:39  <bnoordhuis>on unix, it's easy - much easier than fs and getaddrinfo
20:11:45  <piscisaureus_>well, you'd have to remove them from a stream-bound queue
20:12:02  <bnoordhuis>so?
20:12:12  <piscisaureus_>on windows we'd have to actually cancel the underlying syscall for which there is no guarantee it'd work :-)
20:12:27  <bnoordhuis>right, i figured it was something like that
20:12:31  <piscisaureus_>so we have to specify that we can never make the guarantee that an operation can be cancelled
20:12:41  <piscisaureus_>the problem here, as always, is windows xp and LSPs
20:13:07  <bnoordhuis>can't you switch to select() when you detect either xp or an lsp?
20:13:17  <bnoordhuis>and maybe print a big fat warning in the console
20:13:29  <piscisaureus_>haha
20:13:35  <piscisaureus_>like uv_poll_t does
20:13:46  <piscisaureus_>bnoordhuis: possibly
20:14:14  * sergimquit (Quit: Computer has gone to sleep.)
20:15:55  * sergimjoined
20:16:13  <bnoordhuis>piscisaureus_: btw, is xp really an issue? if we dropped xp support, how many people would complain?
20:16:14  <piscisaureus_>bnoordhuis: but realistically, cancelling write/end/connect is rather lame
20:16:44  <piscisaureus_>bnoordhuis: you could really just close the handle
20:16:50  <piscisaureus_>bnoordhuis: ehm, well, I don't know
20:16:52  <bnoordhuis>piscisaureus_: agreed. if you need to do that, that to me suggests that you need to rethink your approach
20:17:21  <piscisaureus_>bnoordhuis: at the oscon training I did with Rik there were quite a lot of XP users
20:17:31  <piscisaureus_>bnoordhuis: in fact the majority was, even
20:17:37  <bnoordhuis>really? the mind boggles
20:17:46  <piscisaureus_>you sound like mraleph1 now
20:18:06  <piscisaureus_>bnoordhuis: but really it shows how much we are affected by the hipster distortion field
20:18:22  <bnoordhuis>says he to the guy living in gouda :)
20:19:22  <piscisaureus_>bnoordhuis: the only thing I am afraid of
20:19:28  * c4miloquit (Remote host closed the connection)
20:19:48  <piscisaureus_>bnoordhuis: within half a year creationix will come <bla bla bla> with some actually reasonable use case for cancelling uv_write
20:20:00  <bnoordhuis>yeah, he is like that
20:20:18  <piscisaureus_>and then I'll feel obliged to fix that
20:20:48  <bnoordhuis>can't we add a clause to our license: "Free for commercial or non-commercial use - unless your name is Tim Caswell and you live in Texas."?
20:21:08  <bnoordhuis>creationix: you live in texas, don't you?
20:21:17  <piscisaureus_>sounds too easy to circumvent
20:21:19  <piscisaureus_>what if he moves
20:21:38  <bnoordhuis>i bet it's easier for us to change the license than for him to keep moving around
20:22:00  <piscisaureus_>what about
20:22:15  <piscisaureus_>- unless your mirror shows an image like this http://jsconf.eu/2010/speakers/tim_caswell.jpeg
20:22:43  <piscisaureus_>bnoordhuis: or maybe
20:26:04  <creationix>bnoordhuis, correct
20:26:26  * c4milojoined
20:27:08  <bnoordhuis>creationix: "steers and queers", if i remember the slogan right?
20:27:27  <creationix>sounds like Austin
20:27:59  <creationix>so about changing uv_fs_t to store the buffer in ->ptr, how hard is that change
20:28:36  <bnoordhuis>https://github.com/torvalds/linux/pull/26#issuecomment-10774717 <- hah, here we go again
20:28:40  <creationix>I hacked mine externally (I just set req->ptr to my buffer after calling uv_fs_read) and it seems to work fine
20:29:31  <bnoordhuis>creationix: it works but only accidentally
20:29:51  <bnoordhuis>on unix, the actual buffer is stored in void* buf, ptr is unused
20:30:03  <piscisaureus_>Crap I really have to finish and practice my talk now
20:30:16  <bnoordhuis>the paris one?
20:30:20  <piscisaureus_>yeah
20:30:57  <bnoordhuis>creationix: you should use req->data, that's what it's for
20:31:30  <creationix>bnoordhuis, I know it's unused, I'm proposing we change the public API
20:31:46  <creationix>and I'm already using req->data for something else
20:32:25  <bnoordhuis>creationix: "i'm already using it for something else" <- that's not a great argument :)
20:32:36  * indexzeroquit (Quit: indexzero)
20:33:58  <creationix>sure it is
20:34:07  <piscisaureus_>3...2...1...
20:34:08  <creationix>making my code twice as complicated is a bad thing
20:34:11  * TheJHjoined
20:34:26  <creationix>unless there is a good reason to not point to the buffer with ptr
20:35:04  * kazuponjoined
20:40:03  * kazuponquit (Ping timeout: 260 seconds)
20:40:40  <bnoordhuis>creationix: the good reason is that libuv doesn't need ptr to point to anything valid in this case
20:41:05  <bnoordhuis>and i don't want to cast in (api) stone unnecessary things
20:42:42  <creationix>bnoordhuis, for reference, here is my hack https://github.com/creationix/luv/commit/4d0db57b132cd0e16725d9c622a091a7f1812d1c
20:43:04  * jmar777quit (Remote host closed the connection)
20:43:09  <creationix>the commented out code in luv_fs_read and luv_fs_write is from luvit which uses ->data for this
20:43:40  * jmar777joined
20:44:20  <creationix>though I did discover that if I set anything to req->ptr it will get freed by libuv when I call uv_fs_req_cleanup(req)
20:44:35  <creationix>I was freeing it manually since I'm mallocing it manually and I got double free errors
20:44:53  <creationix>that might be a good reason to not do it, but it sure is terribly convenient
20:47:25  <bnoordhuis>creationix: luv_callback_t* callback = (luv_callback_t*)malloc(sizeof(luv_callback_t)) <- luv_callback_t* callback = malloc(sizeof(*callback))
20:47:41  <bnoordhuis>shorter and won't fail horribly if the type of callback changes
20:48:12  * jmar777quit (Ping timeout: 264 seconds)
20:48:34  <bnoordhuis>../../src/node_stat_watcher.cc:46:76: error: no matching function for call to ‘SetPrototypeMethod(v8::Persistent<v8::FunctionTemplate>&, const char [5], <unresolved overloaded function type>) <- i feared this day would come... g++ 4.8
20:48:39  <creationix>bnoordhuis, thanks
20:52:34  * bradleymeckquit (Quit: bradleymeck)
20:57:56  * `3rdEdenquit (Remote host closed the connection)
21:00:21  * jmar777joined
21:06:40  * lohkeyjoined
21:17:52  * sgallaghquit (Remote host closed the connection)
21:18:00  * loladirojoined
21:19:28  * stagas_joined
21:20:53  * stagasquit (Ping timeout: 248 seconds)
21:20:54  * stagas_changed nick to stagas
21:23:25  * `3rdEdenjoined
21:29:32  * sergimquit (Quit: Computer has gone to sleep.)
21:35:37  * jmar777quit (Remote host closed the connection)
21:36:04  * kazuponjoined
21:36:13  * jmar777joined
21:40:39  * jmar777quit (Ping timeout: 256 seconds)
21:40:50  * kazuponquit (Ping timeout: 256 seconds)
21:45:12  * TheJHquit (Remote host closed the connection)
21:48:06  * brsonquit (Remote host closed the connection)
21:50:30  * rendarquit
21:50:31  * brsonjoined
21:55:23  * sergimjoined
21:56:27  * loladiroquit (Quit: loladiro)
21:57:22  * TooTallNatequit (Quit: Computer has gone to sleep.)
21:57:48  * TooTallNatejoined
22:07:43  * hzquit (Read error: Connection reset by peer)
22:09:13  * hzjoined
22:14:02  * hzquit (Read error: Connection reset by peer)
22:14:16  * loladirojoined
22:14:31  * hzjoined
22:15:35  * mikealjoined
22:17:02  * `3rdEdenquit (Remote host closed the connection)
22:17:44  * Ralt_quit (Ping timeout: 255 seconds)
22:18:22  * hzquit (Read error: Connection reset by peer)
22:18:44  * loladiroquit (Ping timeout: 260 seconds)
22:18:46  * hzjoined
22:19:56  * hzquit (Client Quit)
22:22:53  * sergimquit (Quit: Computer has gone to sleep.)
22:24:29  * sergimjoined
22:24:51  * sergimquit (Client Quit)
22:27:49  * felixgequit (Read error: Connection reset by peer)
22:36:41  * kazuponjoined
22:39:58  * perezdquit (Quit: perezd)
22:41:24  * kazuponquit (Ping timeout: 265 seconds)
22:46:02  <TooTallNate>isaacs: ping
22:46:30  * perezdjoined
22:47:18  * indexzerojoined
22:52:03  <isaacs>pong
22:53:55  <TooTallNate>isaacs: do you have thoughts on https://github.com/isaacs/readable-stream/issues/30#issuecomment-10523918
22:54:26  <isaacs>TooTallNate: peek sounds ok
22:54:41  <isaacs>TooTallNate: it won't be particularly performant if you peek more than the first buffer, thohg
22:55:01  <TooTallNate>yay, i had a good idea!!
22:55:14  <TooTallNate>isaacs: my only use-cases so far are for the beginning of the stream so that's ok with me
22:55:20  * perezdquit (Quit: perezd)
22:55:27  <isaacs>:D
22:55:48  * mjr_joined
22:57:13  * perezdjoined
22:57:29  * perezdquit (Remote host closed the connection)
23:00:34  * stagasquit (Read error: Connection reset by peer)
23:02:09  <bnoordhuis>william shatner performing pulp's 'common people'
23:02:15  <bnoordhuis>it's art, i tell you, art!
23:02:19  <piscisaureus_>http://en.wikipedia.org/wiki/Node_Module
23:04:18  * stagasjoined
23:06:22  * mmaleckichanged nick to mmalecki[zz]
23:08:26  * loladirojoined
23:09:57  * loladiroquit (Client Quit)
23:10:45  * stagasquit (Ping timeout: 256 seconds)
23:11:19  * stagasjoined
23:13:47  * mikealquit (Quit: Leaving.)
23:15:01  * warzquit
23:25:01  * c4miloquit (Remote host closed the connection)
23:27:10  * bradleymeckjoined
23:31:05  * loladirojoined
23:31:42  <bnoordhuis>piscisaureus_: around?
23:32:00  <piscisaureus_>bnoordhuis: quickly, i have to go
23:32:10  <bnoordhuis>piscisaureus_: are there people at the office this week?
23:32:24  <piscisaureus_>bnoordhuis: pm
23:36:03  * c4milojoined
23:37:42  * kazuponjoined
23:42:21  * kazuponquit (Ping timeout: 260 seconds)
23:43:58  * mikealjoined
23:44:44  * ArmyOfBrucequit (Excess Flood)
23:45:17  * ArmyOfBrucejoined
23:45:26  * benoitcquit (Excess Flood)
23:51:38  * benoitcjoined
23:53:35  * c4miloquit (Remote host closed the connection)
23:54:23  * mikealquit (Ping timeout: 256 seconds)