Too much output and error to be useful

[Lionel Dricot]

A typical Elisa session completely fill my terminal with garbage and errors, even if all seems to work perfectly.

It's too the point where you cannot even pay attention to the console because each action seems to output a bunch of lines and python crashes.

The fact that Elisa put the backtrace in a file and tell you the name of the file should be an indicator that there's something wrong with the current console output. (and it forces the programmer to do one extra step when debugging)

In order to solve this bug :

1) A typical Elisa session should have no output at all ! Any output should be an error that the user must care about. Any non-critical error should be displayed only with a debug parameter to True or something like that.

2) It should be possible to have debug output only for a plugin or a set of plugin. When you are developping a plugin, you want to correct all errors. But only those related to your stuff, specially if you are developping your plugin against the current trunk. (well, in theory. Practically, releases have as much output as anythhing else).

Thanks for taking care of that :-)

[Olivier Tilloy (osomon)]

Although not really well documented, it is already possible to customize the logging level per-component when running Elisa.
To do this, set the ELISA_DEBUG environment variable to the desired value. Some examples:

`ELISA_DEBUG=*:5 ./elisa-core/bin/elisa` -> maximum logging level (disclaimer: this is unreadable)
`ELISA_DEBUG=*manager*:4 ./elisa-core/bin/elisa` -> set the logging level to 4 for all components which name contain "manager".

You can build more complex filters (the system is based on gstreamer's, see the section reserved to the --gst-debug option in the man page for gst-launch).

Displaying the traceback on the console rather than logging it to a file is a timesaver for developers, it's quite annoying to have to copy-paste the name of a temp file and open it in a separate terminal just to see what the error is when debugging.

Agreed on the fact that most of the "error" output as we have it currently is useless and could easily be fixed.

[Philippe Normand (philn)]

Le mardi 18 novembre 2008 à 10:29 +0000, Olivier Tilloy a écrit :
> Although not really well documented,

see elisa-core/docs/logging.txt

> it is already possible to customize the logging level per-component when running Elisa.
> To do this, set the ELISA_DEBUG environment variable to the desired value. Some examples:
>
> `ELISA_DEBUG=*:5 ./elisa-core/bin/elisa` -> maximum logging level (disclaimer: this is unreadable)
> `ELISA_DEBUG=*manager*:4 ./elisa-core/bin/elisa` -> set the logging level to 4 for all components which name contain "manager".
>
> You can build more complex filters (the system is based on gstreamer's,
> see the section reserved to the --gst-debug option in the man page for
> gst-launch).
>
> Displaying the traceback on the console rather than logging it to a file
> is a timesaver for developers, it's quite annoying to have to copy-paste
> the name of a temp file and open it in a separate terminal just to see
> what the error is when debugging.
>
> Agreed on the fact that most of the "error" output as we have it
> currently is useless and could easily be fixed.
>

[Lionel Dricot (ploum-deactivatedaccount)]

I must add that I'm behind a proxy with authentification so no online services are working. It means that all online services are outputting crashes of twisted which is really odd.

If a service depend of a connection, it should be hidden when no connection or just allow some restricted functionnalities. In any case, this should not appear in the console.

[Olivier Tilloy (osomon)]

Related bugs: bug #290300, bug #297687.

[dino99 (9d9)]

The latest free moovida 1.09 does not get any maintenance since a while. Now moovidadb.com is supporting Linux and support can be found at : http://www.fluendo.com/faq/