any logger in core?

[Francois Berenger]

On Tuesday, November 13, 2012 6:34:05 PM UTC+9, David House wrote:
>
> Also, there is a function for logging fatal errors. It's called failwith 
> :) 
>

failwith messages do not come with a timestamp. 

>
> On Tue, Nov 13, 2012 at 9:27 AM, Malcolm Matalka <mmat... at gmail.com<javascript:>> 
> wrote: 
> > I agree with David.  The current logger I am using at work as 5 or 6 log 
> > levels and I have found little value in it.  I think 'fatal' is 
> > especially devilish since, in such a situation, your monitoring tools 
> > should be the ones determining that. 
> > 
> > /M 
> > 
> > David House <dho... at janestreet.com <javascript:>> writes: 
> > 
> >> Hmm, I am surprised you want so many! 
> >> 
> >> I claim there is a cost in allowing tons and tons of different log 
> >> levels. Firstly, it complicates the interface. Secondly, it leads to 
> >> different applications choosing different logging levels for 
> >> essentially the same errors. E.g. how do you choose whether some 
> >> particular failure is an error, or a fatal? Isn't it likely that 
> >> someone else will make a different choice? There are lines that you 
> >> can draw, but it's a big grey area. Having fewer choices means that 
> >> everyone's programs are more consistent with respect to each other. 
> >> 
> >> Putting it another way: three logging levels should be enough for 
> anyone! :) 
> >> 
> >> On Tue, Nov 13, 2012 at 8:02 AM, Francois Berenger 
> >> <francois.ber... at gmail.com <javascript:>> wrote: 
> >>> The choice in log levels is a little scarce. 
> >>> 
> >>> Currently: 
> >>> raw (I don't know it's level, I guess it's always printed but I may be 
> >>> wrong) 
> >>> then, ordered by my intuitive notion of log priority: 
> >>> debug < info < error 
> >>> 
> >>> I'm used to: 
> >>> debug < info < warn < error < fatal 
> >>> 
> >>> So, I miss the warning and fatal log levels. 
> >>> But, that's just based on my experience. 
> >>> 
> >>> Regards, 
> >>> F. 
> >>> 
> >>> 
> >>> On Thursday, November 8, 2012 7:13:25 PM UTC+9, David House wrote: 
> >>>> 
> >>>> On Thu, Nov 8, 2012 at 3:48 AM, Francois 
> >>>> <francois.b... at gmail.com> wrote: 
> >>>> > I don't know where to find never_returns. 
> >>>> 
> >>>> It's there if you open Core.Std. 
> >>>> 
> >>>> > But the following did work (and never stop): 
> >>>> 
> >>>> You need to explicitly shut down async using the shutdown function in 
> >>>> Async.Std. 
> >>>> 
> >>>> > I'm affraid of open directives, I try to keep my code _very_ 
> explicit 
> >>>> > about what it is doing and which function from which module is used 
> >>>> > (maybe because of past overexposure to some C++ code). 
> >>>> 
> >>>> I think that's exactly the right approach -- I often find myself 
> >>>> making similar comments when doing code review at work. Things are 
> >>>> much easier to follow if opens are reduced, or made more local, and 
> >>>> more explicit. 
> >>>> 
> >>>> That being said, I do allow myself the luxury of opening Core.Std and 
> >>>> Async.Std in most of my modules that use core / async. I find this to 
> >>>> strike a good balance between concision and explicitness. 
> >>>> 
> >>>> One of the reasons is that there are very few *values* brought into 
> >>>> scope by opening Core.Std and Async.Std. This conversation has 
> contain 
> >>>> disproportionally many: never_returns, shutdown, etc. -- an unlucky 
> >>>> coincidence! But nearly everything is squirreled away inside a 
> module, 
> >>>> which helps a lot. (In other words, our "Pervasives" is much smaller 
> >>>> than the ocaml standard library's.) 
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ocaml.org/pipermail/core/attachments/20121113/5e7a0fc0/attachment-0001.html>