On Thu, Dec 27, 2012 at 6:52 AM, Joel Brandt <jobra...@adobe.com> wrote: > There are two changes to node that I'm considering contributing. Before I > get started, I wanted to get some guidance on whether these things might > ever be accepted into master.
As you've presented them here, not very likely. I'll explain why below. > I believe it would be nice to be able to reassign these to any > stream object. This would add complexity, and you can easily implement it yourself: function myConsoleLog() { var str = util.format.apply(util, arguments); myStream.write(str + "\n"); } > The use case for me is when node is launched as a child > process and stdout is used for IPC with the parent. Why not use node's built-in IPC and just don't use stdout/stderr as the IPC channel? var child = child_process.spawn(process.execPath, [script], { stdio: [ 'pipe', 'pipe', 'pipe', 'ipc ] }) That'll open up fd3 in the child as an IPC channel, and stdin/out/err will be streams that you can write to/read from. You'll be able to then do stuff like: // in the parent child.send({ some: "message" }) child.on("message", function(response) { ... }) // in the child: process.on("message", function(message) { ... }) process.send({ some: "response" }) > An alternative to allowing this reassignment could be to have a call that > sets all console logging functions to write to stderr. (Then stdout would be > left free for IPC.) This might be drastically simpler. Then use console.error instead of console.log. > - Where should the API call go? The 'util' package? And, any guidance on > what the API should be? The API should go in npm, if you decide to create it. > - Right now, writes to stdout/stderr are usually blocking. Would we be > opening up a can of worms by trying to have console.log write to streams in > non-blocking ways? Logging to a non-blocking stream will mean that chunks may be lost if you do `process.exit()` explicitly. But as long as there are pending writes, node won't automatically quit. > - If we consider this change, would we also change the logging functions > in the 'util' package? Would we allow the user to switch each separately, or > would console.log/util.log always write to the same place (and the same for > console.error/util.error)? The util.log/p/error/debug functions are deprecated in favor of console. > - Are there logging functions other than console.log/info/debug/error and > util.debug/error/puts/print/log? Well, someone can always write to process.stdout/err explicitly. > 2. allow enabling the V8 debugger programmatically (from a JS call) There are already command-line arguments for turning on the debugger and controlling its port. The API to call into is internal and undocumented for a reason; it's not really to be started from within JavaScript. But I might be missing something here, and I can see that it could be useful. Fedor Indutny is our resident debugger expert. Post an issue on the github asking about this, and mention @indutny in it. If he says it's a bad idea, I'd believe him. -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to nodejs@googlegroups.com To unsubscribe from this group, send email to nodejs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en