Re: Driving Continuous Improvement in D
05.06.2018 17:00, Steven Schveighoffer пишет: To clarify a bit, complicated or controversial changes that are likely to be delayed or stalled, should be split from simple doc changes if it turns out it's not going to be pulled anytime soon. But normally, adding fixes for docs I would think is fine. -Steve Adding fixes for docs is fine for me too. I just don't like mixing unrelated changes in a commit. But nevertheless I did it. The world isn't ideal)
Re: Driving Continuous Improvement in D
On 6/5/18 9:58 AM, Steven Schveighoffer wrote: On 6/5/18 3:20 AM, drug wrote: 04.06.2018 21:08, Steven Schveighoffer пишет: On 6/4/18 1:51 PM, Joakim wrote: On Monday, 4 June 2018 at 15:52:24 UTC, Steven Schveighoffer wrote: On 6/2/18 3:23 AM, Mike Parker wrote: [...] I like the article, but was taken aback a bit by this quote: "for example, a PR to fix a bug in a specific piece of code mustn’t also edit the documentation of that function." [...] I think he was talking about _unrelated_ doc changes. Well, how unrelated? If, for instance, you are changing the docs to accommodate the new code, and notice a typo, I would be fine with fixing that, and have even ASKED for that. I guess I need a bigger clarification, as the way it reads is that we require people split their doc changes from their code changes, and that simply hasn't been the case. But what if your commit with this typo would be reverted? Then you lost your typo fix too. Then you fix the typo again? Reverts don't happen enough to justify this concern. To clarify a bit, complicated or controversial changes that are likely to be delayed or stalled, should be split from simple doc changes if it turns out it's not going to be pulled anytime soon. But normally, adding fixes for docs I would think is fine. -Steve
Re: Driving Continuous Improvement in D
On 6/5/18 3:20 AM, drug wrote: 04.06.2018 21:08, Steven Schveighoffer пишет: On 6/4/18 1:51 PM, Joakim wrote: On Monday, 4 June 2018 at 15:52:24 UTC, Steven Schveighoffer wrote: On 6/2/18 3:23 AM, Mike Parker wrote: [...] I like the article, but was taken aback a bit by this quote: "for example, a PR to fix a bug in a specific piece of code mustn’t also edit the documentation of that function." [...] I think he was talking about _unrelated_ doc changes. Well, how unrelated? If, for instance, you are changing the docs to accommodate the new code, and notice a typo, I would be fine with fixing that, and have even ASKED for that. I guess I need a bigger clarification, as the way it reads is that we require people split their doc changes from their code changes, and that simply hasn't been the case. But what if your commit with this typo would be reverted? Then you lost your typo fix too. Then you fix the typo again? Reverts don't happen enough to justify this concern. -Steve
Re: Driving Continuous Improvement in D
04.06.2018 21:08, Steven Schveighoffer пишет: On 6/4/18 1:51 PM, Joakim wrote: On Monday, 4 June 2018 at 15:52:24 UTC, Steven Schveighoffer wrote: On 6/2/18 3:23 AM, Mike Parker wrote: [...] I like the article, but was taken aback a bit by this quote: "for example, a PR to fix a bug in a specific piece of code mustn’t also edit the documentation of that function." [...] I think he was talking about _unrelated_ doc changes. Well, how unrelated? If, for instance, you are changing the docs to accommodate the new code, and notice a typo, I would be fine with fixing that, and have even ASKED for that. I guess I need a bigger clarification, as the way it reads is that we require people split their doc changes from their code changes, and that simply hasn't been the case. -Steve But what if your commit with this typo would be reverted? Then you lost your typo fix too.
Re: Driving Continuous Improvement in D
On 6/4/18 1:51 PM, Joakim wrote: On Monday, 4 June 2018 at 15:52:24 UTC, Steven Schveighoffer wrote: On 6/2/18 3:23 AM, Mike Parker wrote: [...] I like the article, but was taken aback a bit by this quote: "for example, a PR to fix a bug in a specific piece of code mustn’t also edit the documentation of that function." [...] I think he was talking about _unrelated_ doc changes. Well, how unrelated? If, for instance, you are changing the docs to accommodate the new code, and notice a typo, I would be fine with fixing that, and have even ASKED for that. I guess I need a bigger clarification, as the way it reads is that we require people split their doc changes from their code changes, and that simply hasn't been the case. -Steve
Re: Driving Continuous Improvement in D
On Monday, 4 June 2018 at 15:52:24 UTC, Steven Schveighoffer wrote: On 6/2/18 3:23 AM, Mike Parker wrote: [...] I like the article, but was taken aback a bit by this quote: "for example, a PR to fix a bug in a specific piece of code mustn’t also edit the documentation of that function." [...] I think he was talking about _unrelated_ doc changes.
Re: Driving Continuous Improvement in D
On 6/2/18 3:23 AM, Mike Parker wrote:
In this post for the D Blog, Jack Stouffer details how dscanner is used
in the Phobos development process to help improve code quality and fight
entropy.
The blog:
https://dlang.org/blog/2018/06/02/driving-continuous-improvement-in-d/
reddit:
https://www.reddit.com/r/programming/comments/8nyzmk/driving_continuous_improvement_in_d/
I like the article, but was taken aback a bit by this quote: "for
example, a PR to fix a bug in a specific piece of code mustn’t also edit
the documentation of that function."
Really? I both was not aware of this policy, and don't understand why
you wouldn't fix the docs at the same time. Can you elaborate?
I'll give you an example of what I was thinking of. Let's say you have a
function foo:
/**
* foo takes a parameter and returns true if ...
*/
bool foo(T)(T t) { ... }
And you realize foo really should only take integer parameters:
/**
* foo takes integer parameters and returns true if ...
*/
bool foo(T)(T t) if (isIntegral!T) { ... }
Why not both edit the function and fix the docs in the same PR? In fact,
why would we *accept* the change without updating the docs?
-Steve
Re: Driving Continuous Improvement in D
On Saturday, 2 June 2018 at 07:23:42 UTC, Mike Parker wrote: In this post for the D Blog, Jack Stouffer details how dscanner is used in the Phobos development process to help improve code quality and fight entropy. The blog: https://dlang.org/blog/2018/06/02/driving-continuous-improvement-in-d/ reddit: https://www.reddit.com/r/programming/comments/8nyzmk/driving_continuous_improvement_in_d/ Nice post. I haven't tried dscanner on my code, but I plan to now. It looks like the documentation on the dscanner repo is pretty good. If you think it's ready for wider adoption, consider adding a couple lines to the blog post indicating that folks who want to try it will find instructions in the repo.
Re: Driving Continuous Improvement in D
On Saturday, 2 June 2018 at 13:32:00 UTC, Basile B. wrote: Microbe, if you were a keyword for a protection attribute in a programming language, i would choose "smuck". To borrow a quote from someone else on this forum.. knock of the sex talk!. Anyway, increased membrane permeability leads to rupture, followed by death. Why should I exposed my objects to the toxic effects of the D module? And if encapsulation is not a 'quality' issue, then I don't know what is. In biology, encapsulation is the basis for life - it's why you and I exist. So my question is valid (even if you don't like it). Since the compiler won't protect my objects from the toxic effects of the D module, I am curious how dscanner can help.
Re: Driving Continuous Improvement in D
On Saturday, 2 June 2018 at 12:49:45 UTC, Microbe wrote: As you know, surrounding code within a module can infilitrate the membrane structure of those types that use 'private' to protect their boundary (for example, the 'private' member in that struct, in that blog). Since the compiler is completely useless in such situations (as it conspires with the surrounding code 'to ensure that it can infiltrate your types'), what does dscanner bring to the table, if anything, to help the programmer to ensure such types don't die a quick death due to the cytotoxic effect the module has on such types? Or is this not considered a 'quality' issue in D? Microbe, if you were a keyword for a protection attribute in a programming language, i would choose "smuck".
Re: Driving Continuous Improvement in D
On Saturday, 2 June 2018 at 07:23:42 UTC, Mike Parker wrote: In this post for the D Blog, Jack Stouffer details how dscanner is used in the Phobos development process to help improve code quality and fight entropy. The blog: https://dlang.org/blog/2018/06/02/driving-continuous-improvement-in-d/ reddit: https://www.reddit.com/r/programming/comments/8nyzmk/driving_continuous_improvement_in_d/ As you know, surrounding code within a module can infilitrate the membrane structure of those types that use 'private' to protect their boundary (for example, the 'private' member in that struct, in that blog). Since the compiler is completely useless in such situations (as it conspires with the surrounding code 'to ensure that it can infiltrate your types'), what does dscanner bring to the table, if anything, to help the programmer to ensure such types don't die a quick death due to the cytotoxic effect the module has on such types? Or is this not considered a 'quality' issue in D?
Driving Continuous Improvement in D
In this post for the D Blog, Jack Stouffer details how dscanner is used in the Phobos development process to help improve code quality and fight entropy. The blog: https://dlang.org/blog/2018/06/02/driving-continuous-improvement-in-d/ reddit: https://www.reddit.com/r/programming/comments/8nyzmk/driving_continuous_improvement_in_d/
