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