Andi Vajda wrote:
The purpose of --stderr is to output repository logger calls to
stderr. I don't think it's used for anything else.
I know I'm late to the party, but I'm pretty sure --stderr also prevents
tracebacks from appearing in their own window in the UI, based on this
comment in Chandler.py:
# Redirect stdio and stderr to a dialog if we're running the debug
# version. This is done to catch asserts, which otherwise will never
# get seen by people who run Chandler using the launchers, e.g.
# Aparna. If you're running release you can also set things up so
# that you can see stderr and stdout if you run in a shell or from
# wing with a console.
#
# useBestVisual - uses best screen resolutions on some old
computers.
# See wxApp.SetUseBestVisual
redirect = not Globals.options.stderr
app = wxApplication(redirect=redirect, useBestVisual=True)
Since we want tracebacks in the log, I think we still want --stderr when
running automated tests (both on tbox and from do_tests).
Generally, I don't think too much info in the logs when running
automated tests is a problem: I want to see as much info in the logs as
I can get, because it may save me from wasting time trying to reproduce
a problem. Tinderbox already uses a filter mechanism (which I've tweaked
a couple of times) that pulls important information to the top of the
log page, which makes it a lot easier to find specific failures -- if
there's info about the failure in the log, that is.
Getting rid of command line options just for the sake of getting rid
of them is helping nobody. End-users don't use command line options.
Some developers do, others can safely ignore them.
+1
...Bryan
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
