On Sunday, 14 June 2020 at 17:40:04 UTC, Andrei Alexandrescu wrote:
> On 6/14/20 1:05 PM, Bruce Carneal wrote:
>> On Sunday, 14 June 2020 at 16:07:16 UTC, Seb wrote:
>>> On Saturday, 13 June 2020 at 18:56:55 UTC, Andrei
>>
>> [big snip of clarifying context and concise refutations of many earlier assertions]
>> 
>> Thanks Seb, for the context, the refutations, and for the references to alternative tools (rund, reggae).
>
> Most of said refutations are reducible to simple misunderstandings. A few are due to my oversights. A few are Seb's. My core point stays: build.d is not Good Work(tm), and can't be talked into it. It must be worked into it.
>
> I don't want the makefiles back. I want Good Work, which build.d has a good way to go toward. A good part of my critique can be addressed by refactoring build.d in the ways I suggested. Another part of the critique would be achieved by a pass through its design, with an eye for making dependency syntax tolerable.

I'm not a domain expert on this but from my earlier sight-reading of the code it sure looks like a rework/refactor/rewrite candidate to me as well.  More importantly Seb, a domain expert, appears to agree with you on this.

Such an agreement would make this a part of the well recognized bigger challenge: engaging qualified programmers from a mostly-volunteer pool to address known problems.

On Saturday, 13 June 2020 at 18:22:27 UTC, Andrei Alexandrescu wrote:
> What's wrong with those? Also: don't forget that it's easy to define a battery of macros to translate to other formats.

This doesn't actually work since there's some characters with different meanings in those targets and ddoc's only answer to it is to introduce more and more macros for single characters.

It is a big hassle to actually use and gives no real world benefit since using html as an intermediate format is easier anyway!

On Saturday, 13 June 2020 at 18:30:31 UTC, Andrei Alexandrescu wrote:
> Yah that's awful. At a point either myself or someone else was working on automatically inserting a $(P ...) whenever a double newline was present. I think that was an easy fix.

Indeed, and ddoc actually kinda does that for .d files, it just doesn't for .dd files. Weird rules.

But \n\n is not necessarily a paragraph break. Consider this:

/++

First paragraph

$(DIVC foo,
  bar
)
+/

That \n\n there is immediately followed by a div tag... and should not actually have a <p> before it. It isn't completely wrong but it isn't right semantically and can lead to spacing bugs in the resulting page (it is invalid html to have a div inside a p, so it will automatically close the <p> tag before opening the <div>).

So it is just a bit more complicated than it looks. My implementation to cover all the crazy edge cases I thought up is like 300 lines of code and it still isn't actually perfect (of course any time you have a 300 line buggy function there's the possibility that I just overcomplicated it and there's a much simpler, more general solution I missed).

On 6/15/20 12:58 PM, Adam D. Ruppe wrote:
> On Saturday, 13 June 2020 at 18:22:27 UTC, Andrei Alexandrescu wrote:
>> What's wrong with those? Also: don't forget that it's easy to define a battery of macros to translate to other formats.
> 
> This doesn't actually work since there's some characters with different meanings in those targets and ddoc's only answer to it is to introduce more and more macros for single characters.

There is a way to translate individual characters before applying macros. I'm not sure of its limitations.

On Tuesday, 16 June 2020 at 01:15:08 UTC, Andrei Alexandrescu wrote:
> There is a way to translate individual characters before applying macros. I'm not sure of its limitations.

That only works on code blocks and inline `code`, actually. ddoc has a misfeature of "embedded html" that specifies this bad behavior in other contexts so I wasn't able to convince the language maintainers to change it globally.

https://dlang.org/spec/ddoc.html#embedded_html

On Saturday, 13 June 2020 at 20:37:59 UTC, jmh530 wrote:
> One problem is that if you allow people to make bug fixes to old phobos versions, then there is no way for the subsequent releases to get the updates as if you could with a git branch. You would have to do them all manually.
>

Git will allow you to create a patch from one file and apply it to another. Still manual.


Working in std.experimental I found the private symbols had to work with. That is likely not as bad with this since the idea would be to recreate the phobos ecosystem around the changes. To that end it may be best to take a module and it's entirety into the new version and forwarding only happens across modules.

On Thursday, 18 June 2020 at 14:16:13 UTC, Jesse Phillips wrote:
> On Saturday, 13 June 2020 at 20:37:59 UTC, jmh530 wrote:
>> One problem is that if you allow people to make bug fixes to old phobos versions, then there is no way for the subsequent releases to get the updates as if you could with a git branch. You would have to do them all manually.
>>
>
> Git will allow you to create a patch from one file and apply it to another. Still manual.
>
> [snip]

I think Andrei had made a good point about propagating up changes. This would imply keeping the structure that I had previously for std.algorithm overall, but modify the N_NN module files. For instance, if one were starting from 2_89, then that would be unchanged, while 2_90 would be

module 2_90.std.algorithm;
public import 2_89.std.algorithm: funA, funC, funD...;
void funB() {}

and so on up. For an even more fine-grained basis, you could do

module 2_90_0.std.algorithm;
public import 2_89.std.algorithm: funA, funC, funD...;
void funB() {}

module 2_90_1.std.algorithm;
public import 2_90_0.std.algorithm: funA, funC, funD...;
void funB() {}

module 2_90.std.algorithm;
public import 2_90_1.std.algorithm;

So this would work pretty well in terms of minimizing the amount of code re-use going on.

(there is probably scope for a mixin that can do those imports, or a new language feature "import module: -f" that imports everything except f)

With respect to your suggestion, suppose you release some patch for funB in 2.90.1 late, i.e. when the current version is 2.95 or something. If funB has not been changed over this period, then it propagates up without issue (note that the import of 2_89 would not be over the patch, 2_89 would be structured like 2_90). However, if funB has changed, then future updates will not benefit from it. You would have to manually update those as well. Your suggestion would be useful in this case, I think.

On Thursday, 18 June 2020 at 15:55:06 UTC, jmh530 wrote:
> not benefit from it. You would have to manually update those as well. Your suggestion would be useful in this case, I think.

I think my concern is mostly moot. I think managing the updates will be a challenge in all approaches. But I also think this is a good idea overall.

On 6/18/20 10:08 PM, Jesse Phillips wrote:
> On Thursday, 18 June 2020 at 15:55:06 UTC, jmh530 wrote:
>> not benefit from it. You would have to manually update those as well. Your suggestion would be useful in this case, I think.
> 
> I think my concern is mostly moot. I think managing the updates will be a challenge in all approaches. But I also think this is a good idea overall.

One good goal for std.v2020 would be to forego autodecoding throughout. The endeavor will no doubt present challenges, which in turn will prompt clever solutions and a good accumulation of experience.

On Fri, Jun 19, 2020 at 09:14:30PM -0400, Andrei Alexandrescu via Digitalmars-d wrote: [...]
> One good goal for std.v2020 would be to forego autodecoding throughout.
[...]

Another could be to fix up the range API -- i.e, reconsider the ugliness that is .save, now that D has copy ctors.


T

-- 
I'm still trying to find a pun for "punishment"...