Debug: At least give a way to disable it for when im doing live debugging and want to regain the port and debug a different process.
On Thursday, December 27, 2012 10:51:44 PM UTC-6, Isaac Schlueter wrote: > > On Thu, Dec 27, 2012 at 6:52 AM, Joel Brandt <[email protected]<javascript:>> > 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
