Re: Time to move logger from experimental to std ?

2017-12-01 Thread Basile B. via Digitalmars-d

On Friday, 1 December 2017 at 15:51:42 UTC, Claude wrote:

On Thursday, 30 November 2017 at 09:39:20 UTC, Basile B. wrote:

On Wednesday, 29 November 2017 at 21:14:57 UTC, Claude wrote:
On Wednesday, 29 November 2017 at 14:32:54 UTC, Basile B. 
wrote:

Did I miss anything?


Sorry but yes, i think so, the handle is indirectly accessible 
with "FileLogger.file.fileno".


Oops! Sorry for the noise...


Now on ~master, the filename and the File are even protected.


Re: Time to move logger from experimental to std ?

2017-12-01 Thread Claude via Digitalmars-d

On Thursday, 30 November 2017 at 09:39:20 UTC, Basile B. wrote:

On Wednesday, 29 November 2017 at 21:14:57 UTC, Claude wrote:
On Wednesday, 29 November 2017 at 14:32:54 UTC, Basile B. 
wrote:

Did I miss anything?


Sorry but yes, i think so, the handle is indirectly accessible 
with "FileLogger.file.fileno".


Oops! Sorry for the noise...


Re: Time to move logger from experimental to std ?

2017-11-30 Thread Nathan S. via Digitalmars-d
On Thursday, 30 November 2017 at 09:37:27 UTC, Robert burner 
Schadek wrote:

On Wednesday, 29 November 2017 at 19:48:44 UTC, Nathan S. wrote:
Considering that one of those issues is that the logger 
outputs garbage when given a wstring or a dstring, I would not 
take this as an indication that it's time to "graduate" the 
logger from experimental.


That was fixed at dconf17 and merged a couple of days later.


Glad to hear that. It seems like the reason it might have fallen 
through the cracks is that the commit message referenced issue 
15945 instead of 15954.


https://github.com/dlang/phobos/commit/9e6759995a1502dbd92a05b4d0a8b662f1c6032b#diff-41bb8731b16e43f1b48e0d529c498fa9



Re: Time to move logger from experimental to std ?

2017-11-30 Thread Robert burner Schadek via Digitalmars-d
On Wednesday, 29 November 2017 at 21:40:13 UTC, Jonathan M Davis 
wrote:
It was my understanding that there were still problems with its 
design that Robert wanted to fix, but I don't know where any of 
that stands. But certainly, I don't think that it makes sense 
to push forward with trying to get the logger out of 
experimental without his feedback.


That is correct, I had the code nearly ready, but then didn't 
found time create
the PR. Its a api change, but it would make the api safer to log 
into manually
handled memory, and would reduce the gc pressure. I'll try to 
squeeze my schedule for time to get this going again.


Re: Time to move logger from experimental to std ?

2017-11-30 Thread Robert burner Schadek via Digitalmars-d

On Wednesday, 29 November 2017 at 21:14:57 UTC, Claude wrote:

...
Did I miss anything?


to write a bugzilla issue about it


Re: Time to move logger from experimental to std ?

2017-11-30 Thread Basile B. via Digitalmars-d

On Wednesday, 29 November 2017 at 21:14:57 UTC, Claude wrote:

On Wednesday, 29 November 2017 at 14:32:54 UTC, Basile B. wrote:
Hello, most of the changes made during the current year to the 
std.experimental.logger package are related to the cosmetic 
style. Isn't this a sign showing that the experimentation is 
achieved ?


I tried deriving FileLogger class to implement my own log 
fomatting. I overrided beginLogMsg, logMsgPart or finishLogMsg, 
but I could not do anything with it because the handle "file_" 
is private (so I cannot access it within the derived class).


So I ended up rewriting my own FileLogger deriving directly 
from Logger and copying most of the Phobos version code, but 
that's not convenient.


Did I miss anything?


Sorry but yes, i think so, the handle is indirectly accessible 
with "FileLogger.file.fileno".


Re: Time to move logger from experimental to std ?

2017-11-30 Thread Robert burner Schadek via Digitalmars-d

On Wednesday, 29 November 2017 at 19:48:44 UTC, Nathan S. wrote:
Considering that one of those issues is that the logger outputs 
garbage when given a wstring or a dstring, I would not take 
this as an indication that it's time to "graduate" the logger 
from experimental.


That was fixed at dconf17 and merged a couple of days later.



Re: Time to move logger from experimental to std ?

2017-11-29 Thread Jonathan M Davis via Digitalmars-d
On Wednesday, November 29, 2017 14:32:54 Basile B. via Digitalmars-d wrote:
> Hello, most of the changes made during the current year to the
> std.experimental.logger package are related to the cosmetic
> style. Isn't this a sign showing that the experimentation is
> achieved ?
>
>
> Facts:
> - There only 4 issues for logger -
> https://issues.dlang.org/buglist.cgi?bug_status=UNCONFIRMED_status=NEW
> _status=ASSIGNED_status=REOPENED=phobos=OP=OP=p
> roduct=component=alias=short_desc=content=CP=CP=OR
> st_id=218035=substring=substring=substring=substring=substr
> ing=matches_format=advanced_desc=logger_desc_type=all
> wordssubstr=logger=logger=logger=logger=logger=%22logger
> %22 - The history, mostly style things:
> https://github.com/dlang/phobos/commits/master/std/experimental/logger

It was my understanding that there were still problems with its design that
Robert wanted to fix, but I don't know where any of that stands. But
certainly, I don't think that it makes sense to push forward with trying to
get the logger out of experimental without his feedback.

Personally, I would _really_ like to see
https://issues.dlang.org/show_bug.cgi?id=8687 dealt with so that file and
line number can be runtime arguments rather than compile time arguments so
that you don't end up with a new template instantiation every time you log
something.

- Jonathan M Davis



Re: Time to move logger from experimental to std ?

2017-11-29 Thread Claude via Digitalmars-d

On Wednesday, 29 November 2017 at 14:32:54 UTC, Basile B. wrote:
Hello, most of the changes made during the current year to the 
std.experimental.logger package are related to the cosmetic 
style. Isn't this a sign showing that the experimentation is 
achieved ?


I tried deriving FileLogger class to implement my own log 
fomatting. I overrided beginLogMsg, logMsgPart or finishLogMsg, 
but I could not do anything with it because the handle "file_" is 
private (so I cannot access it within the derived class).


So I ended up rewriting my own FileLogger deriving directly from 
Logger and copying most of the Phobos version code, but that's 
not convenient.


Did I miss anything?


Re: Time to move logger from experimental to std ?

2017-11-29 Thread Nathan S. via Digitalmars-d

On Wednesday, 29 November 2017 at 14:32:54 UTC, Basile B. wrote:

- There only 4 issues for logger


Considering that one of those issues is that the logger outputs 
garbage when given a wstring or a dstring, I would not take this 
as an indication that it's time to "graduate" the logger from 
experimental.


Re: Time to move logger from experimental to std ?

2017-11-29 Thread notna via Digitalmars-d

On Wednesday, 29 November 2017 at 14:32:54 UTC, Basile B. wrote:
Hello, most of the changes made during the current year to the 
std.experimental.logger package are related to the cosmetic 
style. Isn't this a sign showing that the experimentation is 
achieved ?


[...]


+1


Re: Time to move logger from experimental to std ?

2017-11-29 Thread Jack Stouffer via Digitalmars-d

On Wednesday, 29 November 2017 at 14:32:54 UTC, Basile B. wrote:
Hello, most of the changes made during the current year to the 
std.experimental.logger package are related to the cosmetic 
style. Isn't this a sign showing that the experimentation is 
achieved ?



Facts:
- There only 4 issues for logger - 
https://issues.dlang.org/buglist.cgi?bug_status=UNCONFIRMED_status=NEW_status=ASSIGNED_status=REOPENED=phobos=OP=OP=product=component=alias=short_desc=content=CP=CP=OR_id=218035=substring=substring=substring=substring=substring=matches_format=advanced_desc=logger_desc_type=allwordssubstr=logger=logger=logger=logger=logger=%22logger%22
- The history, mostly style things: 
https://github.com/dlang/phobos/commits/master/std/experimental/logger


In the past Andrei remarked that he didn't want to move it from 
stdx until RCStr was in Phobos. That was a couple of years ago, 
so his opinion might have change by seeing the slow progress on 
the DIP1000 front.