00:00:01  <piscisaureus_>oh
00:00:10  <piscisaureus_>bnoordhuis: my point, that is *not* possible
00:00:16  <piscisaureus_>bnoordhuis
00:00:24  <bnoordhuis>okay, why not?
00:00:30  <piscisaureus_>.// So now we want to write 42
00:00:41  <piscisaureus_>if (...) process.stdout.write(42);
00:00:45  <piscisaureus_>fill in the blanks
00:01:11  <bnoordhuis>this is probably best handled in libuv
00:01:33  <piscisaureus_>orly?
00:01:36  <bnoordhuis>we'd need to signal to the application that it's now safe to write (or not safe as the case may be)
00:01:42  <piscisaureus_>bnoordhuis: nah
00:01:59  <piscisaureus_>bnoordhuis: we should just make that bitch nonblocking, and be a little smarter
00:02:26  <bnoordhuis>to recap, make pipes non-blocking, keep tty and files blocking?
00:02:39  <piscisaureus_>bnoordhuis: afaict that was always the plan
00:02:47  <piscisaureus_>bnoordhuis: but I don't like that rule at all
00:03:08  <bnoordhuis>yes, it violates the 'no exceptions' rule
00:03:18  <bnoordhuis>we'd have to amend it to 'no exceptions, except for pipes'
00:03:28  <piscisaureus_>the fact that stdio is blocking is already a violation of the no exceptions rule
00:03:30  <bnoordhuis>which just doesn't have a good ring to it
00:03:36  * mjr_quit (Ping timeout: 248 seconds)
00:03:44  * mjr_joined
00:04:09  <bnoordhuis>but okay, i don't object - make it non-blocking and make it nice
00:08:45  <piscisaureus_>bnoordhuis: uv_pipe_open just doesn't set the nonblocking flag
00:08:51  <piscisaureus_>bnoordhuis: that seems like an oversight to me
00:08:58  <piscisaureus_>bnoordhuis: er, looks
00:09:18  <bnoordhuis>possibly, i didn't write that :)
00:09:47  <piscisaureus_>maybe we can have process.stdout.setBlocking() ?
00:09:59  <piscisaureus_>or would that be awful
00:10:20  <piscisaureus_>bnoordhuis: but srsly - libuv writeSync support would be very nice
00:10:36  <piscisaureus_>we could also get rid of the fact that writing to tty in a tight loop blows up
00:10:55  <piscisaureus_>that's not bad, except for the fact that people know tty is blocking
00:11:27  <piscisaureus_>anyway, first things first
00:53:44  <isaacs>piscisaureus_: yes, stdout.setBlocking() would be a little bit of awful.
00:54:01  <isaacs>piscisaureus_: the main thing is that tty and file stdio must be blocking
00:54:16  <piscisaureus_>isaacs: well, tty sure
00:54:23  <piscisaureus_>file stdio i don't care about
00:54:30  <isaacs>i do :)
00:55:05  <isaacs>losing the last write to a log file is a pita
00:55:20  <piscisaureus_>true
00:55:25  <seebees>i like pita
00:55:49  <piscisaureus_>seebees: oh. I have a nice device here to give you some.
00:56:50  <seebees>piscisaureus_: does it come with humus?
00:57:09  <seebees>or only file io?
00:57:18  <piscisaureus_>seebees: lubricating it will make the pita experience less intense
00:59:01  <seebees>piscisaureus_: ya, I tried, but I really don't have a come back for that
01:04:43  <isaacs>piscisaureus_: isn't it like 3am where you are?
01:04:51  <piscisaureus_>isaacs: ye
01:04:51  <piscisaureus_>s
01:05:02  <isaacs>damn. crazy night owls.
01:05:15  <piscisaureus_>isaacs: yeah, time to leave
01:05:21  <bnoordhuis>ditto
01:05:21  <isaacs>get some rest, man :)
01:05:31  <piscisaureus_>isaacs: rest is for pussies.
01:05:35  <piscisaureus_>coding is for men
01:05:55  <bnoordhuis>3 am is nothing, last night i logged off at 6
01:06:02  * piscisaureus_tries to get elected governor of California
01:06:20  <bnoordhuis>anyway, sleep tight all
01:06:29  <piscisaureus_>isaacs: anyway, worry about nonblocking stdio pipes
01:06:32  <piscisaureus_>then I will get rest
01:06:46  <piscisaureus_>bnoordhuis: hey
01:06:50  <piscisaureus_>bnoordhuis: what time, tomorrow?
01:11:29  * bnoordhuisquit (Ping timeout: 260 seconds)
01:20:25  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
01:37:10  * ericktquit (Read error: Operation timed out)
01:38:20  * brsonquit (Quit: leaving)
01:45:32  * dapquit (Quit: Leaving.)
01:58:12  * perezdquit (Quit: perezd)
01:59:26  * TooTallNatequit (Quit: Linkinus - http://linkinus.com)
02:07:42  <CIA-155>libuv: Luis Lavena master * rb6e3dcc / (src/win/winapi.h src/win/winsock.h): (log message trimmed)
02:07:42  <CIA-155>libuv: Windows: actually detect mingw-w64 and not 64 bits mode
02:07:42  <CIA-155>libuv: __MINGW64__ is only defined when using mingw-w64 in 64bits mode, not when
02:07:42  <CIA-155>libuv: using the 32bits version of the compiler.
02:07:42  <CIA-155>libuv: Instead, to detect usage of mingw-w64 instead of mingw version of GCC we
02:07:42  <CIA-155>libuv: should look at __MINGW64_VERSION_MAJOR and __MINGW64_VERSION_MINOR. If one
02:07:43  <CIA-155>libuv: of these is defined means we are running on mingw-w64 compiler and headers
02:09:33  * travis-cijoined
02:09:33  <travis-ci>[travis-ci] joyent/libuv#223 (master - b6e3dcc : Luis Lavena): The build is still failing.
02:09:33  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/42a8669...b6e3dcc
02:09:33  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1168915
02:09:33  * travis-cipart
02:11:54  * perezdjoined
02:52:22  * isaacsquit (Remote host closed the connection)
03:02:48  * ericktjoined
03:03:53  * ericktquit (Client Quit)
03:05:59  * ericktjoined
03:32:01  * c4miloquit (Ping timeout: 256 seconds)
03:41:15  * c4milojoined
03:56:12  * c4miloquit (Ping timeout: 265 seconds)
04:05:29  * isaacsjoined
04:46:56  * ericktquit (Quit: erickt)
04:48:36  * CoverSlidequit (Read error: Connection reset by peer)
04:51:58  * CoverSlidejoined
04:59:54  * isaacsquit (Remote host closed the connection)
05:47:08  * paddybyersjoined
06:25:28  * orlandovftwjoined
06:38:35  * isaacsjoined
06:52:08  * paddybyersquit (Quit: paddybyers)
07:05:18  * paddybyersjoined
07:19:33  * paddybyersquit (Quit: paddybyers)
07:33:30  <perezd>is it possible for node/libuv to use more than 6 threads
07:41:12  * rendarjoined
08:00:23  * perezdquit (Quit: perezd)
09:17:46  * orlandovftwquit (Ping timeout: 244 seconds)
09:21:39  * isaacsquit (Remote host closed the connection)
09:22:30  * isaacsjoined
09:28:49  * paddybyersjoined
09:35:37  * CoverSlidequit (Ping timeout: 272 seconds)
09:42:59  * CoverSlidejoined
10:03:19  * CoverSlidequit (Read error: Connection reset by peer)
10:08:16  * CoverSlidejoined
10:30:46  * mjr_quit (Quit: mjr_)
10:30:53  * paddybyersquit (Ping timeout: 252 seconds)
10:44:47  * bnoordhuisjoined
11:00:02  <CIA-155>libuv: Aaron Bieber master * r109dcb2 / config-unix.mk : build: make "make test" work on OpenBSD - http://git.io/9iFfDA
11:02:07  * travis-cijoined
11:02:07  <travis-ci>[travis-ci] joyent/libuv#224 (master - 109dcb2 : Aaron Bieber): The build is still failing.
11:02:07  <travis-ci>[travis-ci] Change view : https://github.com/joyent/libuv/compare/b6e3dcc...109dcb2
11:02:07  <travis-ci>[travis-ci] Build details : http://travis-ci.org/joyent/libuv/builds/1171525
11:02:07  * travis-cipart
11:05:10  * c4milojoined
11:12:23  <CIA-155>node: Ben Noordhuis master * r5648d95 / src/node.cc : Remove unused local variable. - http://git.io/9RIeyQ
12:05:16  * abraxasquit
12:33:57  * piscisaureus_joined
13:12:30  <creationix>piscisaureus_, on the gist you posted with pipes
13:12:58  <creationix>it always returns true, except after it has written 65536 bytes, then it just hangs.
13:13:43  <creationix>s/hangs/blocks/
13:15:56  <creationix>and it never actually writes to stdout, which baffles me
13:17:04  <creationix>ahh, stdout is paused in the child
13:17:10  <creationix>that probably explains why it never writes
13:19:23  <creationix>if I comment out the pause, it always returns true and never exits the loop
13:19:44  <creationix>so yeah, writing appears to be blocking
13:29:10  <piscisaureus_>bnoordhuis: http://en.wikipedia.org/wiki/MIPS_architecture#Pseudo_instructions
14:35:54  * pfox___joined
14:36:25  * ericktjoined
14:52:27  * ericktquit (Quit: erickt)
15:07:26  <piscisaureus_>bnoordhuis: try this:
15:07:27  <piscisaureus_>var s = (new Array(1024*1024)).join('.');
15:07:28  <piscisaureus_>require('vm').createContext(s);
15:13:10  <piscisaureus_>http://twitter.com/#!/mattn_jp/status/194643021336297472
15:13:24  <piscisaureus_>Let me quote that
15:13:25  <piscisaureus_>@yukihiro_matz libuv使ってblockをmrb_yieldして回していると数10回まわった所でproc->body->iseqが0x04なんて値になってハマっているのですが、起きうる可能性無いでしょうか?
15:13:41  <tjfontaine>I think I agree with him
15:14:40  <tjfontaine>do we know what he said?
15:14:43  <piscisaureus_>I would almost say
15:14:45  <piscisaureus_>@syoyo: epoll/kqueue 自体は libuv で使われているけど、それを libuv がインターフェイスとしては見せていない. fd を渡したらよろしく dispatch してくれるのを libuv に手をいれて追加するか, async + thread で頑張るか.
15:15:05  <piscisaureus_>(http://twitter.com/#!/syoyo/status/192663254730940417)
15:16:27  <tjfontaine>google translate helps I guess
15:16:35  <piscisaureus_>Not really
15:32:13  * benviequit
16:00:09  * isaacsquit (Read error: Connection reset by peer)
16:00:43  * isaacsjoined
16:09:13  <isaacs>good mornign
16:09:33  <bnoordhuis>good afternono
16:18:16  <piscisaureus_>dap: hey
16:19:56  * orlandovftwjoined
16:22:26  * dapjoined
16:30:32  * paddybyersjoined
16:57:57  * ericktjoined
17:01:38  * ericktquit (Read error: Operation timed out)
17:05:07  * ericktjoined
17:06:23  <piscisaureus_>dap: hey, are you going to publish that blog article/
17:06:48  <piscisaureus_>dap: I showed it to someone yesterday and people want to read it now
17:07:23  <dap>piscisaureus_: someone I know ran into a weird issue that I wanted to root-cause.
17:07:30  <dap>though it worked fine for me.
17:07:43  <piscisaureus_>dap ah hmmm
17:07:44  <dap>I can post it if people are eager to read it.
17:07:48  <piscisaureus_>dap: they are here
17:08:06  <piscisaureus_>dap: you can also give me another preview link, the current one no longer works
17:08:16  <piscisaureus_>dap: maybe just publish
17:11:41  <dap>yeah, I'll clean it up and publish it shortly.
17:12:22  <isaacs>dap: i take it this is re dtrace and node stuff? wanna publish it on nodejs.org as well?
17:12:25  * ericktquit (Quit: erickt)
17:12:36  <dap>isaacs: sure
17:13:16  <dap>…though I kind of would like to figure out Trent's problem
17:13:40  <dap>that said, I've used this a ton, and never seen the thing he's seeing, which makes me suspect an odd build or environment issue.
17:17:58  * ericktjoined
17:18:56  <creationix>is there a reason libuv doesn't expose realpath?
17:19:02  <isaacs>creationix: it's hazardous
17:19:08  <creationix>really?
17:19:08  <isaacs>creationix: like, very badly dangerous.
17:19:11  <isaacs>creationix: yeah.
17:19:21  <isaacs>creationix: the man pages on bsd and linux both say "do not use"
17:19:23  <creationix>could libuv provide a safe version then
17:19:35  <isaacs>creationix: well... node does this by writing it in js
17:19:42  <isaacs>creationix: it's not that hard to port, i'm guessing.
17:19:42  <creationix>indeed, and it's a lot of code
17:19:53  <creationix>hard to get right I mean
17:19:55  <isaacs>creationix: it's a lot less than it would be in C :))
17:20:03  <creationix>I guess so
17:20:15  <creationix>but if done once right in C, it works everywhere
17:20:25  <creationix>and less js -> C++ boundary crosses
17:21:04  * orlandovftwquit (Quit: leaving)
17:21:48  * piscisaureus__joined
17:22:00  * bnoordhuis_joined
17:22:32  * piscisaureus_quit (Ping timeout: 248 seconds)
17:23:18  * bnoordhuisquit (Ping timeout: 260 seconds)
17:23:33  <dap>piscisaureus_: http://dtrace.org/blogs/dap/2012/04/25/profiling-node-js/. I'm not going to publicize yet, but at least it's there for now.
17:23:48  <piscisaureus__>dap: cool! thanks !
17:32:12  <creationix>wow, realpath is 220 lines of js with seperate windows and posix paths
17:32:22  <creationix>and that's on top of libuv's abstractions
17:33:02  <piscisaureus__>creationix: yeah. There is some reason for that but I do not recall
17:33:20  <piscisaureus__>creationix: it's questionable whether it is needed. I don't recall any issues with libuv's realpath.,
17:33:21  <creationix>the windows branch is just a shortcut because there is no lstat on windows
17:33:33  <creationix>libuv doesn't have realpath
17:33:35  <piscisaureus__>creationix: yeah, that's an open issue. lstat will be fixed.
17:33:38  <piscisaureus__>oh
17:34:02  <piscisaureus__>windows could just use GetFinalPathName to implement uv_realpath
17:34:16  <creationix>right, I think uv could provide a good realpath
17:34:20  <piscisaureus__>yes
17:34:22  <creationix>seems like it's within scope
17:34:38  <piscisaureus__>creationix: yeah. we take patches
17:34:44  <creationix>lol
17:34:49  <creationix>you don't want me writing windows C++ code
17:34:57  <piscisaureus__>creationix: I will do the windows part.
17:35:17  <creationix>it's a shame realpath() from stdlib.h isn't usable
17:36:22  <piscisaureus__>creationix: on windows it is easy. Just copy the example from http://msdn.microsoft.com/en-us/library/windows/desktop/aa364962%28v=vs.85%29.aspx
17:36:24  <piscisaureus__>:-p
17:36:44  <creationix>actually, modern realpath is fine, it allocs the char* for you if you pass in NULL
17:36:53  <creationix>I wonder how many systems support that
17:37:32  <creationix>hmm, nevermind, it's still using PATH_MAX
17:41:51  <creationix>ahh, found a sane realpath for C++ http://insanecoding.blogspot.com/2007/11/implementing-realpath-in-c.html
17:43:12  * c4milochanged nick to c4milo|lunch
17:43:18  <piscisaureus__>creationix: that's c++
17:43:32  <piscisaureus__>creationix: and it uses stl
17:43:38  <creationix>right, it will need to be ported
17:44:11  * ericktquit (Quit: erickt)
17:48:12  * ericktjoined
17:48:48  * brsonjoined
17:53:30  * piscisaureus__quit (Quit: ~ Trillian Astra - www.trillian.im ~)
18:23:18  * c4milo|lunchchanged nick to c4milo
18:24:11  * paddybyersquit (Quit: paddybyers)
18:24:40  * ericktquit (Quit: erickt)
18:25:56  * ericktjoined
18:26:59  <creationix>so childProcess.exec uses /bin/sh, could it use /bin/su if the user passed a username?
18:27:32  <creationix>or is there a better way to run a child process as a specific uid/gid
18:33:09  <tjfontaine>well, I would suggest sudo over su, but I think seteuid/setegid is generally how daemon thigns handle it
18:34:00  * mralephjoined
18:38:58  <creationix>yeah, and I have uid/gid, not username/groupname
18:39:19  <creationix>I guess I should open a node process, pass in the command to spawn and setuid/gid before spawning
18:39:40  <creationix>just seems overkill to have an extra node process just to change the uid and gid of a child
18:41:43  <tjfontaine>well, sudo can use a uid/gid
18:42:49  <creationix>true, but for my case I can't assume sudo it installed
18:42:54  <creationix>many servers don't have it
18:43:05  <creationix>maybe a patch to node's spawn?
18:43:17  <creationix>to allow setting uid and gid of the child?
18:43:21  <tjfontaine>a module should be able to do it
18:43:29  <creationix>module?
18:43:42  <bnoordhuis_>there's process.setuid() and process.setgid()
18:43:42  <tjfontaine>a node module, so that others coudl have it
18:43:51  <tjfontaine>oh see, already done :)
18:44:02  * orlandovftwjoined
18:44:06  <creationix>bnoordhuis_, right, but that's from inside a process
18:44:18  * piscisaureus_joined
18:44:22  <creationix>I want to create a child process with a specified uid/gid
18:46:05  <bnoordhuis_>we could perhaps add that
18:46:24  <tjfontaine>is there an analog in windows land for this?
18:48:10  * orlandovftwquit (Ping timeout: 244 seconds)
18:48:25  * TooTallNatejoined
18:52:36  * piscisaureus_quit (Quit: ~ Trillian Astra - www.trillian.im ~)
18:52:42  * orlandovftwjoined
18:56:51  <creationix>hmm, my libuv wishlist is growing, maybe I should find time to start submitting patches
18:57:15  * bnoordhuis_quit (Ping timeout: 252 seconds)
19:24:30  * ericktquit (Remote host closed the connection)
19:24:45  * ericktjoined
19:52:34  * paddybyersjoined
20:05:53  <isaacs>creationix: childProcess.exec taks a uid and gid
20:06:14  <isaacs>bnoordhuis: That's already supported
20:06:16  <isaacs>npm uses that like crazy
20:09:16  <creationix>really? sweet
20:09:20  <creationix>but not spawn?
20:15:16  <creationix>isaacs, cool, looks like spawn does accept uid and git
20:15:20  * creationixread some npm code
20:15:22  <creationix>:)
20:17:07  <creationix>that needs documenting!
20:17:36  <isaacs>creationix: oh, yeah, it should be in the docs if it isn't
20:17:59  <creationix>though it doesn't seem to be working for me
20:18:19  <creationix>I have a node repl as root and I run
20:18:19  <creationix>require('child_process').spawn("sleep", ["100"], {uid:1000,gid:1000})
20:18:23  <creationix>but sleep is running as root
20:19:16  <creationix>but I see you're setting uid and gid in npm https://github.com/isaacs/npm/blob/master/lib/utils/exec.js#L97-103
20:20:47  <isaacs>hmm
20:22:10  <isaacs>weird. yes, that appears to be broken. wth.
20:22:52  <isaacs>yeah... that's super broken. and a problem.
20:23:39  <isaacs>$ sudo ./node test/disabled/test-setuidgid.js
20:23:39  <isaacs>node.js:256
20:23:39  <isaacs> throw e; // process.nextTick error, or 'error' event on first tick
20:23:40  <isaacs> ^
20:23:42  <isaacs>AssertionError: unexpected error message
20:24:01  <isaacs>oh, no, that's a different test
20:24:37  <isaacs>yeah, looks like that behavior never got ported to libuv
20:24:47  <creationix>ouch
20:25:25  <isaacs>cwd is there.
20:25:27  <isaacs>env is there
20:25:30  <isaacs>but no uid/gid
20:25:49  <creationix>can we fix this in 0.6.x since it's supposed to be there?
20:26:07  <isaacs>yes.
20:28:11  <creationix>ok, so I need this for a c9 project and npm depends on it. What needs to be done to get it fixed
20:28:26  <isaacs>i'm writing a patch now.
20:28:29  <isaacs>it shouldn't be too hard.
20:28:33  <creationix>sweet, thanks
20:28:43  <isaacs>but a) libuv 0.6 needs to support it, and b) node needs to be built with that support
20:28:55  <creationix>my backup plan was to spawn su -c and escape all the args manually in js
20:32:47  <isaacs>creationix: hm... actually, so, we might not be able to do this in v0.6
20:32:56  <creationix>:(
20:33:08  <creationix>too invasive
20:33:15  <isaacs>it does change the abi, because it changes the uv_process_options_t
20:33:19  <isaacs>no, not too invasive.
20:33:22  <isaacs>but a public-facing change
20:33:45  <creationix>abi right
20:34:04  <creationix>though, how would a change to uv_process_options_t break anything? Can addons use that structure?
20:34:30  <isaacs>well, other libuv users would use that structure if they use spawn :)
20:34:34  <isaacs>we can't break them, either
20:35:54  <isaacs>so, for node v0.6, you can spawn a node, then process.setuid/setgid, then spawn(process.execPath, process.argv)
20:36:07  <isaacs>which is annoying, but whatever
20:36:07  <creationix>or use su
20:36:15  <creationix>(my use case is posix only)
20:36:16  <isaacs>yeah, or use su
20:36:20  <creationix>node is very heavy
20:36:21  <tjfontaine>I'm still in favor of sudo over su
20:36:42  <tjfontaine>I know you say "sudo" might not be there, but it's also possible for "su" to not be either
20:36:43  <isaacs>or sudo -i, sure
20:36:53  <isaacs>or is it -u?
20:36:54  <creationix>is there a 0.8.x milestone for libuv somewhere so we can make sure this gets in?
20:36:57  <isaacs>i always forget
20:37:02  <tjfontaine>-i is equivalent to su
20:37:10  <isaacs>creationix: there is not, but the issues are being tracked in the node repo
20:37:14  <creationix>su -c "mycommand with args" username
20:37:36  <creationix>tjfontaine, I can't assume sudo
20:37:41  <creationix>it's not as standard as su
20:37:45  <tjfontaine>sudo -i -u uid -g gid --
20:37:56  <creationix>a fresh archlinux won't have sudo
20:37:59  <creationix>same with webos phones
20:38:08  <creationix>I'm sure there are others
20:38:18  <tjfontaine>I'm not particularly convinced that "su" is what should be considered standard either
20:38:33  <creationix>well, spawning a node process is too expensive
20:38:47  <creationix>and we don't want to change ABI in 0.6.x
20:38:59  <tjfontaine>you could write a node addon to do this as well, less than ideal but certainly doable
20:39:01  <creationix>I've never run across a linux that didn't have /bin/su
20:39:16  <creationix>yeah, no binary addons either
20:39:26  * mjr_joined
20:39:46  <creationix>I need my library to run on most linux boxes with minimal dependencies. So far I only depend on node 0.6.x
21:05:40  <isaacs>creationix: https://github.com/joyent/libuv/pull/389
21:09:43  <creationix>isaacs, reading...
21:10:44  <creationix>very simple
21:10:50  <creationix>it's a shame we can't put this in 0.6.x
21:11:45  <creationix>isaacs, could you do `options.gid > 0` instead of `options.gid && options.gid != -1` ?
21:11:52  <creationix>or is that less clear
21:12:31  <creationix>it does change the behavior for negatives less than -1
21:13:22  <tjfontaine>0 is valid, so > -1, or >= 0
21:13:37  <creationix>oh, right, I read the logic backwards
21:14:14  <creationix>so if gid is 0 then it does nothing?
21:14:20  <creationix>shouldn't it error out in that case
21:14:56  <tjfontaine>in his current implementation I would say 0 means noop, and no it should be allowed (at least on linux) because CAP_SETUID means regular user could set to 0
21:15:34  <creationix>good point
21:15:55  <creationix>so then it should be `options.gid != -1 && setgid(options.gid)` just remote the `options.gid &&`
21:15:57  * pfox___quit (Ping timeout: 246 seconds)
21:16:42  <creationix>or options.gid >= 0 (do we care what happens when gid is -3)
21:16:59  <tjfontaine>I guess that depends on what uid_t is
21:17:40  <creationix>.uid is int
21:21:49  <tjfontaine>creationix: I meant uid_t in linux, which I think is generally uint32
21:22:08  <creationix>right, but once this is bound to node, js numbers can be negative
21:22:34  <creationix>I say leave -3 undefined behavior
21:23:20  <tjfontaine>creationix: what if I have a user with an id > int32?
21:23:59  <creationix>tjfontaine, that would be insane
21:24:29  <tjfontaine>creationix: theoretically possible, and probably more likely than you expect because of the way samba and winbind work for negotiated users
21:24:41  <creationix>isaacs, I commented inline on not filtering out the 0 case, otherwise looks good to me. Thanks for getting to this so fast!
21:26:51  * mikealjoined
21:27:29  <creationix>tjfontaine, in x86 linux it is unsigned int or unsigned short depending on 64/32
21:27:59  <creationix>I looked through the various archs on linux kernel and none were larger than unsigned int
21:28:30  <creationix>so our signed int is one bit shy of being large enough for all cases
21:29:37  <tjfontaine>creationix: there's a lot of variance through the ages and platforms, I just wanted to put my opinion on the record is all
22:01:32  * piscisaureus_joined
22:01:52  <piscisaureus_>isaacs: creationix: we could go the same route as we did with 64 bit file offsets
22:02:06  <piscisaureus_>e.g. add uv_spawn2 which does support uid and gid
22:02:14  <piscisaureus_>and then properly fix it in libuv.master
22:03:07  <piscisaureus_>isaacs: this is an abi breaker...
22:04:26  <creationix>piscisaureus_, so node would use the new API, but the original ABI would remain unchanged
22:04:33  <piscisaureus_>yes
22:04:45  <piscisaureus_>but that would be in 0.6 only
22:04:51  <creationix>that works as long as we remember to fix it later
22:05:05  <piscisaureus_>in 0.8/master there would be just one api that sets uid and gid
22:05:11  <creationix>right
22:05:33  <creationix>that would make me happy. I really don't want to shell out to su or an extra node process
22:08:16  <isaacs>piscisaureus_: that sounds fine to me
22:08:39  <isaacs>creationix: well... setuid(0) makes no sense, really
22:08:53  <isaacs>creationix: non-root users can't setuid anyway, which means you'er already 0
22:09:13  <isaacs>oh, i guess on solaris derivatives you can set an explicit setuid perm bit
22:09:14  <creationix>sometimes they can
22:09:17  <isaacs>yeah
22:09:24  <creationix>but yeah, not normally
22:09:28  <piscisaureus_>isaacs: also, I think there are gid_t and uid_t
22:09:32  <isaacs>yes, that's true
22:09:34  <isaacs>should not be ints
22:09:35  <creationix>yes, but those are unsigned
22:09:41  <piscisaureus_>hmm
22:09:47  <creationix>how will you store the -1 case
22:09:49  <isaacs>creationix: on os x uid_t is not unsigned, i don't think
22:09:56  <creationix>well on linux it is
22:09:57  <piscisaureus_>creationix: dunno
22:10:06  <isaacs>creationix: or maybe it is, and that's why nobody (-2) has such a big number :)
22:10:11  <piscisaureus_>creationix: maybe options.flags |= UV_SPAWN_SETSID ?
22:10:16  * mikealquit (Quit: Leaving.)
22:10:34  <isaacs>$ id -- -2
22:10:34  <isaacs>uid=4294967294(nobody) gid=4294967294(nobody) groups=4294967294(nobody),12(everyone),61(localaccounts),402(com.apple.sharepoint.group.1)
22:11:13  <creationix>tim@touchsmart:~/luvit$ id nobody
22:11:13  <creationix>uid=65534(nobody) gid=65534(nogroup) groups=65534(nogroup)
22:11:16  <piscisaureus_>isaacs: creationix: windows_verbatim_arguments is only just a flag as well
22:11:22  <piscisaureus_>so we could just merge all those into a flags fields
22:11:24  <piscisaureus_>*field
22:11:30  <creationix>that works
22:12:01  <piscisaureus_>there's more options I can think off
22:12:07  <piscisaureus_>like, UV_SPAWN_SHELL
22:12:12  <piscisaureus_>no priority though
22:12:16  <isaacs>piscisaureus_: or setsid
22:12:19  <piscisaureus_>yep
22:12:34  <isaacs>piscisaureus_: did that detached stuff ever get back in?
22:12:41  <piscisaureus_>isaacs: oh that too :-)
22:12:50  <piscisaureus_>isaacs: no, AvianFlu never updated his PR
22:12:58  <isaacs>AvianFlu: Ping.
22:13:11  <AvianFlu>what's up?
22:13:13  <piscisaureus_>let me double check that, before we start mud throwing
22:13:38  <AvianFlu>I mean, the PR never got any comments, to be fair! but I'm happy to update it
22:14:09  <piscisaureus_>oh hmm
22:14:12  <piscisaureus_>maybe you did
22:14:14  <AvianFlu>I made a second one
22:14:17  <AvianFlu>that actually worked
22:14:28  <piscisaureus_>I remember the last issues we had was that detach_cb should be dropped
22:14:42  <piscisaureus_>and detaching should not imply that all stdio handles are nulled
22:14:56  <isaacs>yes, that's a separate concept, for sure
22:15:07  <AvianFlu>I agree
22:15:11  <AvianFlu>https://github.com/joyent/libuv/pull/329 is the most recent one
22:15:36  <AvianFlu>I think the part about not nulling the stdio handles needs some of that stdio refactoring to work
22:17:46  <piscisaureus_>unfortunately I am still blocked on the pipe word
22:17:48  <piscisaureus_>*work
22:18:04  <piscisaureus_>igorzi: did you get the chance to review my commits?
22:23:34  * rendarquit
22:33:19  * mralephquit (Quit: Leaving.)
22:35:05  * mikealjoined
23:05:09  * brsonquit (Ping timeout: 246 seconds)
23:07:14  * brsonjoined
23:16:07  <TooTallNate>hggf\
23:21:12  <dap>isaacs: you know what would be great? if we could have V8 call abort() when it encountered an uncaught exception, *before* unwinding the stack. I don't know if that's even possible.
23:23:33  * brsonquit (Ping timeout: 244 seconds)
23:24:35  * brsonjoined
23:28:13  <piscisaureus_>dap: what about you add a dtrace hook in the exception path?
23:28:32  <dap>piscisaureus_: that would be nice too.
23:28:49  <dap>but I want this on all the time (see node-panic)
23:28:50  <piscisaureus_>dap: so you can always record the last one and you know what the last one was when node crashes due to an uncaughtexception
23:29:15  <piscisaureus_>dap: I don't think v8 knows at "throw" time whether an exception will be caught
23:29:27  <dap>Yeah, I'm afraid of that.
23:29:41  <piscisaureus_>dap: an exception basically is just a special return value afaik
23:30:12  <dap>Well, it still has the stack at that point, and has to unwind it back to the last try/catch. What I'm hoping is that it looks for that before unwinding.
23:30:32  <piscisaureus_>dap: well,, the stack is recorded as a property of the exception object
23:30:40  <piscisaureus_>dap: that that's always there, right?
23:30:57  <dap>well, only some basic information about it.
23:31:16  <dap>MDB can examine the function arguments, as long as they're still *on* the stack, so I want to keep that.
23:31:22  <piscisaureus_>dap: well, you'd have to add a dtrace hook in the exception constructor
23:31:29  <piscisaureus_>and you could grab out of there what you want
23:31:47  <dap>that's not really the use case I'm looking for. I want to grab *everything* all the time, for postmortem analysis.
23:31:54  <dap>like, if your C program segfaults, you get a core dump, and you figure out what went wrong.
23:32:17  <dap>I want that for Node. We already did the work for our debugger to understand node core dumps. Now I just want it to dump core when an uncaught exception happens :)
23:32:32  <piscisaureus_>aah
23:32:46  <dap>I'll have to dig into V8 and see if this is even remotely possible.
23:32:59  <piscisaureus_>dap: well, I think exceptions are caught by a TryCatch object
23:33:07  <piscisaureus_>dap: at least, the uncaughtexception should be
23:33:16  <piscisaureus_>so maybe you can create a special flavor of TryCatch
23:33:50  <dap>yeah, the question is, does it unwind the stack before that object gets it
23:33:57  <piscisaureus_>hmm
23:33:59  <dap>or does that object do the unwinding.
23:34:04  <dap>you know what I mean?
23:34:16  <piscisaureus_>dap: yeah, but I don't know
23:34:22  * piscisaureus_looks it up
23:34:33  <dap>I could create my own top-level try/catch that just calls abort(), but if it's already popped all the frames, that won't help. But that's a good idea, if it works the way we hope
23:35:12  <piscisaureus_>dap: well, calling abort() may be nice for you, but not in general :-)
23:35:35  <dap>it's probably the best thing for any production app on SmartOS, but yeah, not on other systems.
23:36:01  * pfox___joined
23:37:35  <piscisaureus_>dap:
23:37:35  <piscisaureus_>void Isolate::ScheduleThrow(Object* exception) {
23:37:35  <piscisaureus_> // When scheduling a throw we first throw the exception to get the
23:37:35  <piscisaureus_> // error reporting if it is uncaught before rescheduling it.
23:37:35  <piscisaureus_> Throw(exception);
23:37:36  <piscisaureus_> thread_local_top()->scheduled_exception_ = pending_exception();
23:37:36  <piscisaureus_> thread_local_top()->external_caught_exception_ = false;
23:37:37  <piscisaureus_> clear_pending_exception();
23:37:37  <piscisaureus_>}
23:37:53  <piscisaureus_>dap: looks hopeful
23:37:56  <dap>cool
23:38:20  <piscisaureus_>dap: I am not sure whether compiled code takes teh same path
23:38:39  <dap>I'll have to do some digging. When I get some time :)
23:39:59  * avsejjoined
23:49:28  * bnoordhuisjoined
23:50:16  <bnoordhuis>i finally rebooted my laptop
23:50:25  <bnoordhuis>bye bye 4500+ hour uptime :(