Re: [MirageOS-devel] Logs

[Thomas Leonard <talex5@xxxxxxxxx>]

On 16 October 2015 at 14:21, Daniel BÃnzli <daniel.buenzli@xxxxxxxxxxxx> wrote:
> Le vendredi, 16 octobre 2015 Ã 13:31, Thomas Leonard a Ãcrit :
>> I think the key here (as you mentioned) is splitting the collection
>> library from the reporting. The collection part needs to have minimal
>> dependencies so anyone writing an OCaml library will be happy to use
>> it.
>
> Only the result compatibility package will be depended upon.

Sounds fine.

>> This is the hard part, because you have to get everyone to agree
>> ;-)
>
> Well usually I do something and people use it if they wantâ I like to get 
> feedback, but feedback must always be taken with a kilogram of salt. In the 
> end its always fine for me if not everybody agrees.

The only thing I worry about is that using an application with
multiple logging systems can be annoying. e.g. you tell it to copy all
logs to a file, but later discover that only half the messages went
there because some libraries were using a different logging system. If
there's an easy way to get the authors of other logging systems on
board, that could be useful (but OCaml libraries don't generally do
any logging at all, so it's not a huge issue).

>> Log.error -> a human should be alerted (by default) that this has happened
>> Log.warning -> if it's not working, check these messages first
>> Log.info -> a human should see this by default if they look at the logs
>> Log.debug -> this should not be shown by default
>
> I would just like to comment on why I have that Log.show level in there 
> (maybe a better name should be found, suggestions welcome). There are (cli) 
> programs whose natural duty is to have their output show progress or a kind 
> of console intermingled with the log messages â e.g. opam, a build system or 
> a test suite. At the time it seemed such "consoles" do actually naturally 
> blend into the logging mechanism as the lowest logging level which allows to 
> easily reuse the reporting/redirection/quietness control of the logging 
> framework for that aswell. Still a little bit unsure whether this should be 
> kept or not though.

Makes sense (I'd expect it to go between warning and info - I can
imagine wanting to suppress progress without suppressing errors). On
the other hand, an application could just log at info level and make
that visible by default for its own loggers, while keeping info level
suppressed by default for other components.

If you're going for nouns, perhaps
error/warning/notice/info(rmation)/debug. If verbs,
alert/warn/show/info(rm)/debug.


-- 
Dr Thomas Leonard        http://roscidus.com/blog/
GPG: DA98 25AE CAD0 8975 7CDA  BD8E 0713 3F96 CA74 D8BA

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel