July 25, 2014
On 2014-07-25 14:52, Dicebot wrote:

> That is interesting clash of attitude to standard library :) In my
> opinion it is quite the opposite - standard library is here to ensure
> primarily that all trivial things are done in a same way in all
> projects. Anything more complicated can be packaged as a separate
> library but trivialities are exactly the things that set up common
> ground and ensure good library interoperation.

Do you think std.datetime is easy? I heard it was quite hard to implement correctly. Taken into account daylight savings and what not. Phobos is full of things like that. But it also contains trivial functionality. And we should not even start talking about druntime.

-- 
/Jacob Carlborg
July 25, 2014
On 2014-07-25 15:01, francesco cattoglio wrote:

> "fmin" is trivial as well, is not used all the time, yet is in the
> standard library. Sometime trivial stuff is still good to have.

I'm not saying it bad to have trivial stuff in the standard library. I just don't see how NullLogger is useful. But I can see that a rolling logger is very useful. Or a systemd logger.

-- 
/Jacob Carlborg
July 26, 2014
On Thursday, 24 July 2014 at 18:51:03 UTC, Andrei Alexandrescu wrote:
>
> 0. There's no way to set the minimal logging level statically, except for an on/off switch. There must be a way to define e.g. -version=logLevel=trace that sets the minimum logging level actually performed. Any logging below that level is a no-op. Which segues into the next problem:

Internally in SRLabs we are using a logging library with static logging level and static tagging of the log lines, something like:

  logdbg!(GL, SUR, REND, DBG_AA)("initialising the surface and the texture data");

Where 'logdbg' is just an helper for having the right log level template params.
The tags are defined and reserved in a common module in a tuple, and commented/decommented by the single developer by needs (well, actually we are mixing an external not committed file):

  ...
  CAVS,  /// cavs machinery.
  //GL,      /// flavour OpenGL.
  //PAR,    /// descriptors parser.
  REND, /// global renderer threaded loop.
  //SUR,    /// generic mixed library HL surface handlers.

  // ... reserved to developers ...
  //DBG_AA, /// Aaron is interested in that for his debugging purpose.
  DBG_PI,  /// Paolo is interested in that for his debugging purpose.


So, we have a very nice granularity and a compile-time guillotine, and we can cherry-pick log emissions in a very pragmatic way in different context (bugs hunting, production, test environ, etc).

The tag approach is strange, and for what I know, it's something that I've never seen around, but everyone here is liking it a lot.

> 1. There's a bunch of code still generated even with logging statically disabled (per http://d.godbolt.org). I could not find a way to completely eliminate generated code. Unused lazy parameters MUST generate no code at the front end level. This is a performance bug in the D front end that blocks acceptance of this proposal.

That's the big problem: we were able to completely obliterated log lines that don't use lazy parameters, but the lazy is just unavoidable in a log library: I'm very interested in a solution for this issue.

---
Paolo

6 7 8 9 10 11 12 13 14 15 16
Next ›   Last »