monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Thomas Keller
Subject: Re: [Monotone-devel] RFC: lua output redirection
Date: Fri, 07 May 2010 18:17:03 +0200
User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; de; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b2pre Thunderbird/3.0.4

Am 07.05.10 12:33, schrieb Stephen Leake:
> Thomas Keller <address@hidden> writes:
>> 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. 

We already have a couple of functions which behave differently, f.e. we
have disabled os.execute and io.popen for security reasons. And not
overwriting these two fails to resolve the original problem, i.e. having
a dumb-save way to catch 90% of the implementors output.

> 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?

It would pop up in the progress (p) stream. I'm not sure how lua code is
supposed to write basic_io to stdio's main output (m) stream. For
non-stdio Lua implementors could still just call io.stdout:write()

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

There are usually only three valid out-of-band streams which also do not
immediately mean the end of execution, p for progress, w for warning and
t for ticker. Since we had no way to print anything from Lua to mtn's
internal representation right now, I thought it would be the best to
just support p for now and if the need arises (and only if) add support
for other channels (tickers anyone?) as well.

>> 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.

If you have a good idea - shoot :)

Thomas.

-- 
GPG-Key 0x160D1092 | address@hidden | http://thomaskeller.biz
Please note that according to the EU law on data retention, information
on every electronic information exchange might be retained for a period
of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]