www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - 521 days, 22 hours, 7 minutes and 52 seconds...

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
...is what took to get std.experimental.logger in Phobos.

https://github.com/D-Programming-Language/phobos/pull/1500

A time to celebrate! Many thanks to Robert who carried it through a long 
gestation, Dicebot for managing the review process, and everybody who 
provided feedback, especially Martin Nowak for his ideas.


Andrei
Jan 26 2015
next sibling parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Mon, Jan 26, 2015 at 10:09:45AM -0800, Andrei Alexandrescu via Digitalmars-d
wrote:

 ...is what took to get std.experimental.logger in Phobos.
 
 https://github.com/D-Programming-Language/phobos/pull/1500
 
 A time to celebrate! Many thanks to Robert who carried it through a
 long gestation, Dicebot for managing the review process, and everybody
 who provided feedback, especially Martin Nowak for his ideas.


[...]

Certainly, this deserves celebration!

But OTOH, if *this* is what it takes to contribute a new module to
Phobos, then it's no wonder we have trouble finding contributors...
Most would give up before they even try. I think there's an imbalance
here between the quality of existing Phobos modules vs. the quality
expected of future Phobos modules. Whatever happened to incremental
refinement??  Do we really expect flawless perfection before merging to,
of all places, std.*experimental*?


T

-- 
Fact is stranger than fiction.
Jan 26 2015
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/26/15 10:17 AM, H. S. Teoh via Digitalmars-d wrote:

 On Mon, Jan 26, 2015 at 10:09:45AM -0800, Andrei Alexandrescu via
Digitalmars-d wrote:

 ...is what took to get std.experimental.logger in Phobos.

 https://github.com/D-Programming-Language/phobos/pull/1500

 A time to celebrate! Many thanks to Robert who carried it through a
 long gestation, Dicebot for managing the review process, and everybody
 who provided feedback, especially Martin Nowak for his ideas.


 [...]

 Certainly, this deserves celebration!

 But OTOH, if *this* is what it takes to contribute a new module to
 Phobos, then it's no wonder we have trouble finding contributors...
 Most would give up before they even try. I think there's an imbalance
 here between the quality of existing Phobos modules vs. the quality
 expected of future Phobos modules. Whatever happened to incremental
 refinement??  Do we really expect flawless perfection before merging to,
 of all places, std.*experimental*?


For a good while there was no std.experimental. Its introduction was 
partially motivated by the stalemate of this contribution. -- Andrei
Jan 26 2015
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Mon, Jan 26, 2015 at 10:33:32AM -0800, Andrei Alexandrescu via Digitalmars-d
wrote:

 On 1/26/15 10:17 AM, H. S. Teoh via Digitalmars-d wrote:


[...]

But OTOH, if *this* is what it takes to contribute a new module to
Phobos, then it's no wonder we have trouble finding contributors...
Most would give up before they even try. I think there's an imbalance
here between the quality of existing Phobos modules vs. the quality
expected of future Phobos modules. Whatever happened to incremental
refinement??  Do we really expect flawless perfection before merging
to, of all places, std.*experimental*?


 
 For a good while there was no std.experimental. Its introduction was
 partially motivated by the stalemate of this contribution. -- Andrei


And yet it still took so long to get it in?

IMO a better approach would have been, merge it into std.experimental
sooner, then submit followup PRs to std.experimental when the
implementation is found to be inferior. We already officially don't
guarantee non-breakage in std.experimental anyway, so we're not
constrained by release schedule or anything like that.

Plus, this way it's easier for other contributors to chime in to the
implementation (I know you can submit PRs against other PRs, but not
many people know that or have the patience to do that).

Once we've bashed it into shape in std.experimental to everyone's
satisfaction, we can move it into std proper.

If it takes just as much effort to get it into std.experimental as it
would take to get into std directly, I don't see the point of the
additional hassle introduced by std.experimental.


T

-- 
Acid falls with the rain; with love comes the pain.
Jan 26 2015
next sibling parent "Laeeth Isharc" <Laeeth.nospam nospam-laeeth.com> writes:
On Monday, 26 January 2015 at 19:50:39 UTC, H. S. Teoh wrote:

 On Mon, Jan 26, 2015 at 10:33:32AM -0800, Andrei Alexandrescu 
 via Digitalmars-d wrote:

 On 1/26/15 10:17 AM, H. S. Teoh via Digitalmars-d wrote:


 [...]

But OTOH, if *this* is what it takes to contribute a new 
module to
Phobos, then it's no wonder we have trouble finding 
contributors...
Most would give up before they even try. I think there's an 
imbalance
here between the quality of existing Phobos modules vs. the 
quality
expected of future Phobos modules. Whatever happened to 
incremental
refinement??  Do we really expect flawless perfection before 
merging
to, of all places, std.*experimental*?


 
 For a good while there was no std.experimental. Its 
 introduction was
 partially motivated by the stalemate of this contribution. -- 
 Andrei


 And yet it still took so long to get it in?

 IMO a better approach would have been, merge it into 
 std.experimental
 sooner, then submit followup PRs to std.experimental when the
 implementation is found to be inferior. We already officially 
 don't
 guarantee non-breakage in std.experimental anyway, so we're not
 constrained by release schedule or anything like that.

 Plus, this way it's easier for other contributors to chime in 
 to the
 implementation (I know you can submit PRs against other PRs, 
 but not
 many people know that or have the patience to do that).

 Once we've bashed it into shape in std.experimental to 
 everyone's
 satisfaction, we can move it into std proper.

 If it takes just as much effort to get it into std.experimental 
 as it
 would take to get into std directly, I don't see the point of 
 the
 additional hassle introduced by std.experimental.


 T


I don't claim expertise on library development, but isn't it the 
norm that the bar is raised for quality as a platform matures.  
Because complexity increases much more than linearly with time, 
and also as one learns from earlier mistakes and missteps.

If it is not easy to get a contribution in, that raises the 
satisfaction of having it eventually accepted.  People like 
having a high bar to meet, even if that's not the way of the 
modern world.  And D's orientation towards excellence is one of 
the things I personally find most appealing.

Maybe it is worth writing up some lessons learned from the 
discussion on github and pointers for future contributors.
Jan 26 2015
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/26/15 11:48 AM, H. S. Teoh via Digitalmars-d wrote:

 On Mon, Jan 26, 2015 at 10:33:32AM -0800, Andrei Alexandrescu via
Digitalmars-d wrote:

 On 1/26/15 10:17 AM, H. S. Teoh via Digitalmars-d wrote:


 [...]

 But OTOH, if *this* is what it takes to contribute a new module to
 Phobos, then it's no wonder we have trouble finding contributors...
 Most would give up before they even try. I think there's an imbalance
 here between the quality of existing Phobos modules vs. the quality
 expected of future Phobos modules. Whatever happened to incremental
 refinement??  Do we really expect flawless perfection before merging
 to, of all places, std.*experimental*?


 For a good while there was no std.experimental. Its introduction was
 partially motivated by the stalemate of this contribution. -- Andrei


 And yet it still took so long to get it in?

 IMO a better approach would have been, merge it into std.experimental
 sooner, then submit followup PRs to std.experimental when the
 implementation is found to be inferior.


Of course. I repeat: for a long time std.experimental was not an option. 
Clearly it's better with it than without, and merging into 
std.experimental first, std later, will be the way we roll. -- Andrei
Jan 26 2015
parent reply "Dicebot" <public dicebot.lv> writes:
We couldn't merge it into std.experimental before because you 
have stated that even std.experimental modules shouldn't have a 
breaking changes normally. It was 2 reviews ago.

Now you have reconsidered, which is understandable considering 
how long has it been taking, but pretending that was intended to 
work that way does not make you look good :(

PS I was in favor for very lax initial requirements for 
experimental packages for this very reason.
Jan 26 2015
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/26/15 12:30 PM, Dicebot wrote:

 We couldn't merge it into std.experimental before because you have
 stated that even std.experimental modules shouldn't have a breaking
 changes normally. It was 2 reviews ago.

 Now you have reconsidered, which is understandable considering how long
 has it been taking, but pretending that was intended to work that way
 does not make you look good :(

 PS I was in favor for very lax initial requirements for experimental
 packages for this very reason.


Now I remember. I admit I was wrong. -- Andrei
Jan 26 2015
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Monday, 26 January 2015 at 20:35:31 UTC, Andrei Alexandrescu 
wrote:

 On 1/26/15 12:30 PM, Dicebot wrote:

 We couldn't merge it into std.experimental before because you 
 have
 stated that even std.experimental modules shouldn't have a 
 breaking
 changes normally. It was 2 reviews ago.

 Now you have reconsidered, which is understandable considering 
 how long
 has it been taking, but pretending that was intended to work 
 that way
 does not make you look good :(

 PS I was in favor for very lax initial requirements for 
 experimental
 packages for this very reason.


 Now I remember. I admit I was wrong. -- Andrei


That was.. unexpected :) Does that mean requirements for any 
future experimental proposals should also be tuned down a bit?
Jan 26 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/26/15 12:46 PM, Dicebot wrote:

 On Monday, 26 January 2015 at 20:35:31 UTC, Andrei Alexandrescu wrote:

 On 1/26/15 12:30 PM, Dicebot wrote:

 We couldn't merge it into std.experimental before because you have
 stated that even std.experimental modules shouldn't have a breaking
 changes normally. It was 2 reviews ago.

 Now you have reconsidered, which is understandable considering how long
 has it been taking, but pretending that was intended to work that way
 does not make you look good :(

 PS I was in favor for very lax initial requirements for experimental
 packages for this very reason.


 Now I remember. I admit I was wrong. -- Andrei


 That was.. unexpected :) Does that mean requirements for any future
 experimental proposals should also be tuned down a bit?


Of course. I'm not planning to repeat the mistake :o). -- Andrei
Jan 26 2015
parent "Dicebot" <public dicebot.lv> writes:
On Monday, 26 January 2015 at 20:51:40 UTC, Andrei Alexandrescu 
wrote:

 That was.. unexpected :) Does that mean requirements for any 
 future
 experimental proposals should also be tuned down a bit?


 Of course. I'm not planning to repeat the mistake :o). -- Andrei


Great news, thanks!
Jan 26 2015
prev sibling parent reply "tn" <no email.com> writes:
On Monday, 26 January 2015 at 20:35:31 UTC, Andrei Alexandrescu
wrote:

 On 1/26/15 12:30 PM, Dicebot wrote:

 We couldn't merge it into std.experimental before because you 
 have
 stated that even std.experimental modules shouldn't have a 
 breaking
 changes normally. It was 2 reviews ago.

 Now you have reconsidered, which is understandable considering 
 how long
 has it been taking, but pretending that was intended to work 
 that way
 does not make you look good :(

 PS I was in favor for very lax initial requirements for 
 experimental
 packages for this very reason.


 Now I remember. I admit I was wrong. -- Andrei


I thought the idea was that there should be no _known_ pending
breaking changes when mergin into std.experimental. Thus
std.experimental would be for fixing problems that are found when
the package is actually used. Breaking changes for fixing those
would be perfectly fine.

1. review => if problems found => fix all known problems and
repeat the review
2. once everyting seems ok in review => merge to std.experimental
3. if a new problem requiring a breaking change is found => fix it
4. once no new problems have been found for a while => seems ok
=> merge to std
5. if a new problem requiring a breaking change is found => can't
fix it, maybe try to cirmumvent it somehow etc. (no breaking
changes unless it's critical)
Jan 27 2015
parent "aldanor" <i.s.smirnov gmail.com> writes:
On Tuesday, 27 January 2015 at 09:07:30 UTC, tn wrote:

 On Monday, 26 January 2015 at 20:35:31 UTC, Andrei Alexandrescu
 wrote:

 On 1/26/15 12:30 PM, Dicebot wrote:

 We couldn't merge it into std.experimental before because you 
 have
 stated that even std.experimental modules shouldn't have a 
 breaking
 changes normally. It was 2 reviews ago.

 Now you have reconsidered, which is understandable 
 considering how long
 has it been taking, but pretending that was intended to work 
 that way
 does not make you look good :(

 PS I was in favor for very lax initial requirements for 
 experimental
 packages for this very reason.


 Now I remember. I admit I was wrong. -- Andrei


 I thought the idea was that there should be no _known_ pending
 breaking changes when mergin into std.experimental. Thus
 std.experimental would be for fixing problems that are found 
 when
 the package is actually used. Breaking changes for fixing those
 would be perfectly fine.

 1. review => if problems found => fix all known problems and
 repeat the review
 2. once everyting seems ok in review => merge to 
 std.experimental
 3. if a new problem requiring a breaking change is found => fix 
 it
 4. once no new problems have been found for a while => seems ok
 => merge to std
 5. if a new problem requiring a breaking change is found => 
 can't
 fix it, maybe try to cirmumvent it somehow etc. (no breaking
 changes unless it's critical)


I found out I quite like the Rust's way of doing this because 
it's changing so much and so fast -- plain and simple, unstable 
features are put behind "feature gates" and the only way for the 
end user to use unstable API is to explicitly mark it as allowing 
the unstable code. This also goes well with RFC review process. 
Once the feature is stabilized, no changes to user code are 
required, no imports to be changed etc. This allows them to merge 
in ridiculous amount of PRs/day and test everything out live 
without affecting the core stable API.
Jan 27 2015
prev sibling parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Mon, Jan 26, 2015 at 08:30:58PM +0000, Dicebot via Digitalmars-d wrote:

 We couldn't merge it into std.experimental before because you have
 stated that even std.experimental modules shouldn't have a breaking
 changes normally. It was 2 reviews ago.


Yeah, this part didn't make much sense to me. While I agree that we
shouldn't be accepting random junk into std.experimental, the bar
shouldn't be set so high that legitimate initial revisions of a new
module are also excluded. Otherwise, what's the point of even having
std.experimental as opposed to merging straight into std?



 Now you have reconsidered, which is understandable considering how
 long has it been taking, but pretending that was intended to work that
 way does not make you look good :(
 
 PS I was in favor for very lax initial requirements for experimental
 packages for this very reason.


+1.

And we should not forget that if something in std.experimental continues
to disappoint, there's always the option of dropping it altogether,
since we don't guarantee non-breakage on std.experimental. So there's no
reason the bar should be as high as it is right now.


T

-- 
They pretend to pay us, and we pretend to work. -- Russian saying
Jan 26 2015
prev sibling parent reply "Zach the Mystic" <reachzach gggmail.com> writes:
On Monday, 26 January 2015 at 19:50:39 UTC, H. S. Teoh wrote:

 If it takes just as much effort to get it into std.experimental 
 as it
 would take to get into std directly, I don't see the point of 
 the
 additional hassle introduced by std.experimental.


 T


I agree - be shameless with what you put in std.experimental. 
Otherwise it has no purpose. Really, the whole point of such a 
package is so you can safely *ignore* all the trolls and 
naysayers on reddit, newsgroups, slashdot, etc... so that you can 
work on the libraries. There should be no shame whatsoever in 
breaking code that uses std.experimental, nor any pretense that 
it's anything but a playground for working out kinks. 
std.experimental is a warehouse where things are tried and 
scrapped regularly. The only reason it exists is to say that 
these particular *kinds* of tasks are "preapproved" for phobos. 
It says *nothing* about whether the current implementation will 
be here next month or not. Everything in std.experimental is 
"still in the shop", subject to complete and instantaneous recall 
at any time.

Otherwise, ask yourself, what's the point of std.experimental at 
all? You just like giving people 13 extra characters to type when 
you make guarantees?
Jan 26 2015
parent "weaselcat" <weaselcat gmail.com> writes:
On Monday, 26 January 2015 at 21:51:03 UTC, Zach the Mystic wrote:

 On Monday, 26 January 2015 at 19:50:39 UTC, H. S. Teoh wrote:

 If it takes just as much effort to get it into 
 std.experimental as it
 would take to get into std directly, I don't see the point of 
 the
 additional hassle introduced by std.experimental.


 T


 I agree - be shameless with what you put in std.experimental. 
 Otherwise it has no purpose. Really, the whole point of such a 
 package is so you can safely *ignore* all the trolls and 
 naysayers on reddit, newsgroups, slashdot, etc... so that you 
 can work on the libraries. There should be no shame whatsoever 
 in breaking code that uses std.experimental, nor any pretense 
 that it's anything but a playground for working out kinks. 
 std.experimental is a warehouse where things are tried and 
 scrapped regularly. The only reason it exists is to say that 
 these particular *kinds* of tasks are "preapproved" for phobos. 
 It says *nothing* about whether the current implementation will 
 be here next month or not. Everything in std.experimental is 
 "still in the shop", subject to complete and instantaneous 
 recall at any time.

 Otherwise, ask yourself, what's the point of std.experimental 
 at all? You just like giving people 13 extra characters to type 
 when you make guarantees?


+1, I'd love to see more experimental possibly-later approved 
modules in std.experimental.
Jan 26 2015
prev sibling next sibling parent "Tofu Ninja" <emmons0 purdue.edu> writes:
On Monday, 26 January 2015 at 18:19:18 UTC, H. S. Teoh wrote:

 Certainly, this deserves celebration!

 But OTOH, if *this* is what it takes to contribute a new module 
 to
 Phobos, then it's no wonder we have trouble finding 
 contributors...
 Most would give up before they even try. I think there's an 
 imbalance
 here between the quality of existing Phobos modules vs. the 
 quality
 expected of future Phobos modules. Whatever happened to 
 incremental
 refinement??  Do we really expect flawless perfection before 
 merging to,
 of all places, std.*experimental*?


 T


This is what I was thinking this morning.... I saw something 
about logger review and and thought to myself "this is still 
going on?"
Jan 26 2015
prev sibling parent "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Monday, 26 January 2015 at 18:19:18 UTC, H. S. Teoh wrote:

 On Mon, Jan 26, 2015 at 10:09:45AM -0800, Andrei Alexandrescu 
 via Digitalmars-d wrote:

 ...is what took to get std.experimental.logger in Phobos.
 
 https://github.com/D-Programming-Language/phobos/pull/1500
 
 A time to celebrate! Many thanks to Robert who carried it 
 through a
 long gestation, Dicebot for managing the review process, and 
 everybody
 who provided feedback, especially Martin Nowak for his ideas.


 [...]

 Certainly, this deserves celebration!

 But OTOH, if *this* is what it takes to contribute a new module 
 to
 Phobos, then it's no wonder we have trouble finding 
 contributors...
 Most would give up before they even try. I think there's an 
 imbalance
 here between the quality of existing Phobos modules vs. the 
 quality
 expected of future Phobos modules.


To be quite frank, the code was initially quite bad. Design 
decisions aside, there were many errors like not using attributes 
correctly and having messy algorithms with exponential time 
complexity. This hasn't been the case with all Phobos proposals.

(Also, valid criticisms were sometimes forgotten for a long time, 
and there were sometimes several months between patches, but 
things like these are unavoidable in a volunteer environment.)


 Whatever happened to incremental
 refinement??  Do we really expect flawless perfection before 
 merging to,
 of all places, std.*experimental*?


 T


The deal to include it into std.experimental was only introduced 
at the very end of the review process.
Jan 26 2015
prev sibling next sibling parent reply "Robert burner Schadek" <rburners gmail.com> writes:
thank you  !"In order of appearance on github"() { Dicebot, 
JakobOvrum, monarchdodra, klamonte, grogancolin, fugalh, Geod24, 
andralex, braddr, AndrejMitrovic, MetaLang, p0nce, yglukhov, 
elendel-, sigod, sybrandy, DmitryOlshansky, SerialVelocity, 
drasha, klickverbot, MartinNowak, jacob-carlborg, 9il, quickfur, 
deadalnix, MrSmith33, 9rnsr }

and anyone I forgot

thank you very very much
Jan 26 2015
next sibling parent "Mathias LANG" <geod24 gmail.com> writes:
On Monday, 26 January 2015 at 18:25:13 UTC, Robert burner Schadek 
wrote:

 thank you  !"In order of appearance on github"() { Dicebot, 
 JakobOvrum, monarchdodra, klamonte, grogancolin, fugalh, 
 Geod24, andralex, braddr, AndrejMitrovic, MetaLang, p0nce, 
 yglukhov, elendel-, sigod, sybrandy, DmitryOlshansky, 
 SerialVelocity, drasha, klickverbot, MartinNowak, 
 jacob-carlborg, 9il, quickfur, deadalnix, MrSmith33, 9rnsr }

 and anyone I forgot

 thank you very very much


Thanks to you for your contributions !
It takes a lot of patience and motivation to go through this 
process for so long. I'm pretty sure you paved the way for better 
/ faster (stronger?) review :)
Jan 26 2015
prev sibling next sibling parent "Meta" <jared771 gmail.com> writes:
On Monday, 26 January 2015 at 18:25:13 UTC, Robert burner Schadek 
wrote:

 thank you  !"In order of appearance on github"() { Dicebot, 
 JakobOvrum, monarchdodra, klamonte, grogancolin, fugalh, 
 Geod24, andralex, braddr, AndrejMitrovic, MetaLang, p0nce, 
 yglukhov, elendel-, sigod, sybrandy, DmitryOlshansky, 
 SerialVelocity, drasha, klickverbot, MartinNowak, 
 jacob-carlborg, 9il, quickfur, deadalnix, MrSmith33, 9rnsr }

 and anyone I forgot

 thank you very very much


Thank you for having the fortitude to carry this through.
Jan 26 2015
prev sibling next sibling parent ketmar <ketmar ketmar.no-ip.org> writes:
On Mon, 26 Jan 2015 18:25:11 +0000, Robert burner Schadek wrote:

congrats!=
Jan 26 2015
prev sibling next sibling parent "Robert burner Schadek" <rburners gmail.com> writes:
On Monday, 26 January 2015 at 18:25:13 UTC, Robert burner Schadek 
wrote:

 thank you  !"In order of appearance on github"() { Dicebot, 
 JakobOvrum, monarchdodra, klamonte, grogancolin, fugalh, 
 Geod24, andralex, braddr, AndrejMitrovic, MetaLang, p0nce, 
 yglukhov, elendel-, sigod, sybrandy, DmitryOlshansky, 
 SerialVelocity, drasha, klickverbot, MartinNowak, 
 jacob-carlborg, 9il, quickfur, deadalnix, MrSmith33, 9rnsr }

 and anyone I forgot

 thank you very very much


and of course mleise, sry I forgot you
Jan 26 2015
prev sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Monday, 26 January 2015 at 18:25:13 UTC, Robert burner Schadek 
wrote:

 thank you  !"In order of appearance on github"() { Dicebot, 
 JakobOvrum, monarchdodra, klamonte, grogancolin, fugalh, 
 Geod24, andralex, braddr, AndrejMitrovic, MetaLang, p0nce, 
 yglukhov, elendel-, sigod, sybrandy, DmitryOlshansky, 
 SerialVelocity, drasha, klickverbot, MartinNowak, 
 jacob-carlborg, 9il, quickfur, deadalnix, MrSmith33, 9rnsr }

 and anyone I forgot

 thank you very very much


Well complaining is easy. Doing is harder. Thanks to you.
Jan 26 2015
parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Tuesday, 27 January 2015 at 00:05:20 UTC, deadalnix wrote:

 On Monday, 26 January 2015 at 18:25:13 UTC, Robert burner 
 Schadek wrote:

 thank you  !"In order of appearance on github"() { Dicebot, 
 JakobOvrum, monarchdodra, klamonte, grogancolin, fugalh, 
 Geod24, andralex, braddr, AndrejMitrovic, MetaLang, p0nce, 
 yglukhov, elendel-, sigod, sybrandy, DmitryOlshansky, 
 SerialVelocity, drasha, klickverbot, MartinNowak, 
 jacob-carlborg, 9il, quickfur, deadalnix, MrSmith33, 9rnsr }

 and anyone I forgot

 thank you very very much


 Well complaining is easy. Doing is harder. Thanks to you.


Just an FYI:
I'm sure you meant to sincerely thank Robert, but the above reads 
like you are blaming him for it being harder to do than to 
complain. "Thanks to you" is dangerous to put near anything 
negative as it's just a commonly used sarcastically as it is 
sincerely. English is weird :)
Jan 27 2015
parent "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 27 January 2015 at 11:43:48 UTC, John Colvin wrote:

 Just an FYI:
 I'm sure you meant to sincerely thank Robert, but the above 
 reads like you are blaming him for it being harder to do than 
 to complain. "Thanks to you" is dangerous to put near anything 
 negative as it's just a commonly used sarcastically as it is 
 sincerely. English is weird :)


Thanks for the heads up, that is indeed what I meant.
Jan 27 2015
prev sibling next sibling parent reply "weaselcat" <weaselcat gmail.com> writes:
On Monday, 26 January 2015 at 18:09:46 UTC, Andrei Alexandrescu 
wrote:

 ...is what took to get std.experimental.logger in Phobos.

 https://github.com/D-Programming-Language/phobos/pull/1500

 A time to celebrate! Many thanks to Robert who carried it 
 through a long gestation, Dicebot for managing the review 
 process, and everybody who provided feedback, especially Martin 
 Nowak for his ideas.


 Andrei


Following this timeline, we should get std.allocator sometime 
next year? : )
Jan 26 2015
parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"weaselcat"  wrote in message news:ovwpcitsqbmpusckkghl forum.dlang.org... 


 Following this timeline, we should get std.allocator sometime 
 next year? : )


2019
Jan 26 2015
prev sibling parent "ZombineDev" <valid_email he.re> writes:
Congratulations to all involved for the effort to bring this 
completion. I am very glad that we now have a standard way of 
logging in Phobos :)



On Monday, 26 January 2015 at 18:09:46 UTC, Andrei Alexandrescu 
wrote:

 ...is what took to get std.experimental.logger in Phobos.

 https://github.com/D-Programming-Language/phobos/pull/1500

 A time to celebrate! Many thanks to Robert who carried it 
 through a long gestation, Dicebot for managing the review 
 process, and everybody who provided feedback, especially Martin 
 Nowak for his ideas.


 Andrei
Jan 27 2015