On Thu, Dec 27, 2012 at 6:52 AM, Joel Brandt <[email protected]> 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
