Re: [Monotone-devel] RFC: lua output redirection

[Stephen Leake]

Thomas Keller <address@hidden> writes:

> 1) users cannot distinguish lua output from the application's normal output
>
> 2) like 1), but even worse for (remote) stdio: for remote_stdio the
> problem is that the user does not even see it (while he maybe wants to),
> while for normal stdio the output possibly leads to parsing errors
>
> 3) monotone's logging facility (--log) won't catch the output either,
> which makes it f.e. hard to debug netsync hooks which are executed in
> daemon mode (f.e. Debian's start-stop-daemon has no way to redirect the
> daemon's output somewhere else, the application has to take care of that
> itself or you need to write some simple wrapper script for that)

These are good reasons for a new Lua output function.

> So the patch basically introduces a new function "message" (naming
> proposals welcome...) which calls our print macro with the given text
> input while prefixing every line with "lua: ", 

Ok.

> and secondly overwrites print() and io.write() at startup to use the
> new implementation.

I don't think this is a good idea; these are standard Lua functions that
are documented in the Lua manual. Better to introduce a new funciton
io.message or io.mtn_message. 

On the other hand, I suppose it is reasonable in the mtn automate
stdio context to expect io.write() to show up in one of the stdio 
streams. I gather it does not now, but your change makes it do that.

But does it show up in the stdout or progress stream? Progress is
appropriate for debug messages, but someone will want to generate
basic_io from Lua, in the stdout stream; how do they do that?

More generally, the Lua code could pick any one of the stdio streams to
write to.

> Some notes:
>
> 1) io.stdout:write() and io.stderr:write() are still available -
> partially because I could not find a way to overwrite / disable them
> (they're of userdata type...) and partially because I still wanted to
> give the not-so-usual lua hacker a chance to really write to stdout or
> stderr if he really wants to do so
>
> 2) I haven't yet find a way to print something without a newline with
> our sanity setup, so io.write() always up with a newline which is
> different from the original behaviour, so it should be documented at least.
>
> 3) While both, io.write() and print() previously outputted on stdout,
> the new output goes exclusively to stderr (otherwise the points 1) and
> 2) above wouldn't be easily solvable) - so this is surely another thing
> which needs to be documented, in case somebody expects his (lua) output
> exclusively on stdout.
>
> So what do you think? Is this something we should do or do you think
> this is a bad idea?

If it really was pure redirection (ie making io.write show up in stdio
stdout or progress stream), then overwritting io.write would be ok. But
given these other changes in behavior, I think it needs a new name.

-- 
-- Stephe