OT: std.logger was Re: std.experimental Timeline

[Jonathan M Davis via Digitalmars-d]

On Monday, 4 January 2016 at 09:24:44 UTC, Robert burner Schadek 
wrote:
> On Sunday, 3 January 2016 at 21:37:28 UTC, Dicebot wrote:
>> Haven't found any issues with std.allocator so far but 
>> std.logger definitely is not Phobos ready per my requirements. 
>> I have been recently re-evaluating it as possible replacement 
>> for old Tango logger we use and found that in several places 
>> it forces unnecessary GC allocations and/or immutability (i.e. 
>> https://github.com/D-Programming-Language/phobos/blob/master/std/experimental/logger/core.d#L742 requires that log message must be formatted into immutable string before it can be passed to another logger). This is a deal breaker that can possibly require major API change to fix.
>>
>
> I do not follow.
>
> 1. Tango passes a const(char)[] around [1]. What is the 
> difference?
> 2. Have you looked at the doc and the impl. of FileLogger? They 
> both show an easy how to implement a Logger without the GC. 
> With that it is also trivial to make a MultiLogger that does 
> not allocate. BTW, the default implementation is a direct 
> result of the "by default multi-threading safe" requirement 
> brought up multiple times during reviews.
>
>
> [1] 
> https://github.com/SiegeLord/Tango-D2/blob/d2port/tango/util/log/Log.d#L1297

If I understand correctly (based on previous statements by 
Dicebot), the problem is that at Sociomantic, they reuse buffers 
heavily. So, they basically don't use string much of anywhere and 
instead use some combination of char[] and const(char)[] (so that 
the array elements can be given new values without reallocating), 
and std.experimental.logger - like a lot of typical D code - uses 
string, which means that when they log a message with 
std.experimental.logger, their buffer has to be copied into a 
string, which means that an allocation occurs, which in their 
environment is unacceptable.

So, to work for them, they would need std.experimental.logger to 
accept something like const(char)[] or an arbitrary ranges of 
characters and to not allocate inside of any of its logging 
functions. Any requirement to convert to string (be it by the 
user of the logger or inside of the logger itself) doesn't work 
with their requirements.

I'm not particularly familiar with std.experimental.logger as it 
stands, by I would guess that to fit Sociomantic's requirements, 
it would need to either manage to log without actually 
constructing any array of characters (e.g. by printing each of 
its elements in turn without actually putting them together 
first), or it would need to reuse a buffer every time it created 
the line to log (which would incur the cost of copying the 
characters but wouldn't normally have to allocate). But I don't 
know how well that fits in with the logger being hierarchical via 
classes (which solves other design requirements) or how close the 
current implementation is to that. Certainly, being forced to use 
classes does prevent the logger from using some of the typical 
techniques that we use (particularly with regards to ranges). So, 
the logger definitely presents some challenges that most other 
Phobos code doesn't have to deal with. :| Though obviously, you'd 
be more aware of that than anyone. :)

- Jonathan M Davis