Le samedi, 24 octobre 2015 à 17:25, Thomas Leonard a écrit :
> stdout/stderr is something OCaml programs can generally assume exists.
> If someone makes a new OCaml platform, it's up to them to make sure
> they do something sensible (mirage-xen sends output to the default
> console, for example). O
On 24 October 2015 at 15:55, Daniel Bünzli wrote:
>
> Spiros sent this. I respond on the list I hope he doesn't mind. My response
> is below his message.
>
>
> Le samedi, 24 octobre 2015 à 14:45, Spiros Eliopoulos a écrit :
>
>> > 1) nop reporter (do absolutely nothing)
>> > 2) stderr reporter (v
> Le 24 oct. 2015 à 15:55, Daniel Bünzli a écrit :
>
> Which invalidates for me your argument that it should not be 3).
However I think that your arguments holds for some of the programs, e.g. Those
that use a library that logs but don't care about it.
In the end maybe the best is 1) it's th
Very sorry, I meant to send that to the list as well.
-Spiros E.
On Sat, Oct 24, 2015 at 10:55 AM, Daniel Bünzli wrote:
>
> Spiros sent this. I respond on the list I hope he doesn't mind. My
> response is below his message.
>
>
> Le samedi, 24 octobre 2015 à 14:45, Spiros Eliopoulos a écrit :
>
Spiros sent this. I respond on the list I hope he doesn't mind. My response is
below his message.
Le samedi, 24 octobre 2015 à 14:45, Spiros Eliopoulos a écrit :
> > 1) nop reporter (do absolutely nothing)
> > 2) stderr reporter (vomits on stderr)
> > 3) invalid reporter (throws in your face
Le vendredi, 23 octobre 2015 à 13:49, Drup a écrit :
> However I have trouble understand what is the intended use case for
> tags, and in particular why they are parametrized.
Maybe it's over engineering at work; I never used that personally for now.
There are two intended use cases:
1) If lib
I globally like the API (it's similar to Lwt_log, which I already quite
liked).
However I have trouble understand what is the intended use case for
tags, and in particular why they are parametrized. It doesn't seem to be
possible to filter by tag in a programmatic way.
Le 23/10/2015 03:18, D
Thanks for taking time to feedback, always appreciated !
Le vendredi, 23 octobre 2015 à 09:49, Thomas Leonard a écrit :
> Having a default level for new sources seems a bit ugly. If I
> understand correctly, this is a global that can only be used correctly
> if you know when your libraries are g
On 23 October 2015 at 02:18, Daniel Bünzli wrote:
> Ok so here's something:
>
> http://erratique.ch/software/logs
> http://erratique.ch/software/logs/doc/
>
> Given that it's clearly superior from a disabled logging performance point of
> view, Logs uses Dr. Yallop's formatting continuation t
Ok so here's something:
http://erratique.ch/software/logs
http://erratique.ch/software/logs/doc/
Given that it's clearly superior from a disabled logging performance point of
view, Logs uses Dr. Yallop's formatting continuation technique. Thanks also to
Gabriel R. for making further convin
On 16 October 2015 at 11:55, Daniel Bünzli wrote:
> Le vendredi, 16 octobre 2015 à 11:11, Anil Madhavapeddy a écrit :
>> And debugk in that pull request answers my query nicely:
>>
>> Log.debugk "received %s (%s)" @@ fun k -> k (pretty k) (pretty v)
> I prefer my version mentioned on the same page
Le lundi, 19 octobre 2015 à 10:07, Thomas Leonard a écrit :
> I think anything that writes to stdout should need explicit
> configuration from the application.
Yes that's the reason why this level is called App and is reserved for use by
the application — this is explicitly stated in the usage gu
On 17 October 2015 at 15:04, Daniel Bünzli wrote:
> Le samedi, 17 octobre 2015 à 12:49, Thomas Leonard a écrit :
>> (but OCaml libraries don't generally do any logging at all, so it's not a
>> huge issue).
>
> And this tradition should continue as much as possible.
>
>> Makes sense (I'd expect it
Le samedi, 17 octobre 2015 à 12:49, Thomas Leonard a écrit :
> (but OCaml libraries don't generally do any logging at all, so it's not a
> huge issue).
And this tradition should continue as much as possible.
> Makes sense (I'd expect it to go between warning and info - I can
> imagine wantin
On 16 October 2015 at 14:21, Daniel Bünzli 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 OC
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 resul
On 16 October 2015 at 11:11, Anil Madhavapeddy wrote:
>
>> On 16 Oct 2015, at 10:55, Daniel Bünzli wrote:
>>
>> Hello,
>>
>> The topic was mentioned again on the mirage call. I also need such a library
>> in many different contexts and I keep on rewriting the bits of a basic
>> logger in too ma
Le vendredi, 16 octobre 2015 à 12:07, Jeremy Yallop a écrit :
> > Maybe. As said above I'll try to see if I can find a convenient way to
> > generalize the notion of level into a notion of "tag".
>
> The Async logging framework takes a similar approach, although it
> supports levels as well: eac
On 16 October 2015 at 11:55, Daniel Bünzli wrote:
> I prefer my version mentioned on the same page
>
> Log.debug "received %a (%a)" pp_key k pp_value v
>
> which is the natural way of using Format. Jeremy may want to comment on the
> performance results though.
Yes: I'll add a note on that top
On 10/16/2015 11:55, Daniel Bünzli wrote:
> Le vendredi, 16 octobre 2015 à 11:23, Hannes Mehnert a écrit :
>> Certainly this could be a layer on top of the simple logging library,
>> but it might be handy to have it embedded at the lowest level. What do
>> others think?
>
> Maybe. As said above I'
Le vendredi, 16 octobre 2015 à 11:11, Anil Madhavapeddy a écrit :
> I really like this library except for the notion of log levels. […] with the
> level stuff added by a higher level logger/monitor?
I don't see how a higher-level structure could decide if that string message is
informational, a
Hi Daniel,
On 10/16/2015 10:55, Daniel Bünzli wrote:
> The topic was mentioned again on the mirage call. I also need such a library
> in many different contexts and I keep on rewriting the bits of a basic logger
> in too many of my projects.
>
> I do have a Log module in bos [1] which represe
> On 16 Oct 2015, at 11:18, Thomas Gazagnaire wrote:
>
>> that could be passed around libraries as an argument, with the level stuff
>> added by a higher level logger/monitor?
>
> How do you decide what to filter or not? Maybe a notion of section (that
> users can turn off and on) could be mo
On 16 Oct 2015, at 11:13, Thomas Gazagnaire wrote:
>
>> This will happen soon or later on my side, so if you think you could be
>> served by that and have ideas about it, speak.
>
> yes!
>
> The format based logging might be useful to avoid performance issues such as
> [1] or [2].
And debugk
> that could be passed around libraries as an argument, with the level stuff
> added by a higher level logger/monitor?
How do you decide what to filter or not? Maybe a notion of section (that users
can turn off and on) could be more useful?
I think xapi used to allow users to specify which sect
> This will happen soon or later on my side, so if you think you could be
> served by that and have ideas about it, speak.
yes!
The format based logging might be useful to avoid performance issues such as
[1] or [2].
--
Thomas
[1]: https://github.com/mirage/ocaml-git/pull/130
[2]:
https://gi
> On 16 Oct 2015, at 10:55, Daniel Bünzli wrote:
>
> Hello,
>
> The topic was mentioned again on the mirage call. I also need such a library
> in many different contexts and I keep on rewriting the bits of a basic logger
> in too many of my projects.
>
> I do have a Log module in bos [1]
Hello,
The topic was mentioned again on the mirage call. I also need such a library in
many different contexts and I keep on rewriting the bits of a basic logger in
too many of my projects.
I do have a Log module in bos [1] which represents the very basics I'd like,
but I would like to for
28 matches
Mail list logo
