Thomas Keller <m...@thomaskeller.biz> writes: > Am 07.05.10 12:33, schrieb Stephen Leake: >> Thomas Keller <m...@thomaskeller.biz> 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()
Ok. If we make the assumption that anything written to io.write() is a progress message, then I agree that capturing it somehow is more important than the details of newlines and stdout vs stderr. I think that assumption is reasonable; it's certainly true for my Lua code. Hmm. I'm not sure that's true in the current tests; does this overwriting happen when the mtn tests are running? If someone is depending on the current behavior, they can change to io.stdout:write(). Sounds good. -- -- Stephe _______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
