On Saturday, 13 June 2020 at 09:24:52 UTC, Petar Kirov [ZombineDev] wrote:
> On Saturday, 13 June 2020 at 03:33:14 UTC, Andrei Alexandrescu wrote:
>>
>> That should be killed with fire. I have seldom disliked a program this much.
>
> I think the most accurate way to classify your message is as "shitposting", which according to the (5th) definition in the Urban Dictionary [1] is:
> 1: The failure to make a constructive post
> 2: The inability to add useful information to a forum
> 3: Worthless overly offensive generally racists posts written in a manner which aggravates others.
> 4: Nrom
>
> Andrei, please use a more professional demeanor.
>
> [1]: https://www.urbandictionary.com/define.php?term=shitposting

I can't agree more. I miss the "original Andrei" :/

On Saturday, 13 June 2020 at 08:58:56 UTC, Petar Kirov [ZombineDev] wrote:
> - AFAIK, installing a GNUmake on Windows involves installing a whole Posix emulation/compatibility environment like cygwin, msys or msys2, which brings it's own rats nest of problems
> - Even if Make is not a problem, it is still dependent on Posix compatible shell, so that's one more variable in the equation

Side note: LDC has been using GNUmake on Windows for years, incl. extending some upstream Makefiles to work with and test Windows targets too.
While GNUmake itself is surprisingly portable (source comes with a Visual Studio project working out of the box, resulting in a little 330 KB Win64 stand-alone executable), the tests require bash and the usual little GNU tools.
Fortunately, a normal git installation on Windows provides the expected GNU environment, incl. bash.

On 6/13/20 2:05 AM, Petar Kirov [ZombineDev] wrote:
> On Saturday, 13 June 2020 at 03:33:14 UTC, Andrei Alexandrescu wrote:
>>
>> That should be killed with fire. I have seldom disliked a program this much.
> 
> If anything should be killed with fire that should probably be the use of DDoc macros in dlang.org. It's a prime example of https://wiki.c2.com/?JobSecurity, but with the difference with that analogy that the only people needing that job security had already quit and now the whole thing is so messed up that no one can fix it without rewriting it from scratch.

At one time I had ambitions to search and replace the documentation to use markdown syntax instead of Ddoc macros to the extent possible. I just haven't made time for it yet, sadly.

One in particular I'd like to replace is the silly $(P) macro on every single paragraph, but that would require another PR to Ddoc to do automatically create paragraphs instead of <BR>s. In my original "markdown" PR that got shot down and I didn't try to bring it back at the time.

On Saturday, 13 June 2020 at 09:05:46 UTC, Petar Kirov [ZombineDev] wrote:
> If anything should be killed with fire that should probably be the use of DDoc macros in dlang.org.

Out of curiosity, are there any more details on that? Like a Bugzilla issue, forum post, PR discussion etc. This complaint is new to me.

On Saturday, 13 June 2020 at 15:25:07 UTC, David Gileadi wrote:
> One in particular I'd like to replace is the silly $(P) macro on every single paragraph

Fun fact: this is the key issue that caused me to actually create adrdox.

Lots of problems with ddoc but the horrible paragraph handling was the finishing blow.

On 6/13/20 5:05 AM, Petar Kirov [ZombineDev] wrote:
> On Saturday, 13 June 2020 at 03:33:14 UTC, Andrei Alexandrescu wrote:
>>
>> That should be killed with fire. I have seldom disliked a program this much.
> 
> If anything should be killed with fire that should probably be the use of DDoc macros in dlang.org. It's a prime example of https://wiki.c2.com/?JobSecurity, but with the difference with that analogy that the only people needing that job security had already quit and now the whole thing is so messed up that no one can fix it without rewriting it from scratch.

What's wrong with those? Also: don't forget that it's easy to define a battery of macros to translate to other formats. In addition to html there are translations to ebook, LaTeX, plain text, and one that I found interesting to define, which outputs the actual macros back. Or something like that. Oh, I found it: https://github.com/dlang/dlang.org/blob/master/verbatim.ddoc. Cool beans.

To translate to other formats automatically or semiautomatically you could start with such a battery of macros and define them appropriately.

On 6/13/20 5:24 AM, Petar Kirov [ZombineDev] wrote:
> On Saturday, 13 June 2020 at 03:33:14 UTC, Andrei Alexandrescu wrote:
>>
>> That should be killed with fire. I have seldom disliked a program this much.
> 
> I think the most accurate way to classify your message is as "shitposting", which according to the (5th) definition in the Urban Dictionary [1] is:
> 1: The failure to make a constructive post
> 2: The inability to add useful information to a forum
> 3: Worthless overly offensive generally racists posts written in a manner which aggravates others.
> 4: Nrom
> 
> Andrei, please use a more professional demeanor.
> 
> [1]: https://www.urbandictionary.com/define.php?term=shitposting

Nice going. Particularly lovely is the weaseling of loaded words that make it all look more righteous.

On 6/13/20 11:33 AM, Adam D. Ruppe wrote:
> On Saturday, 13 June 2020 at 15:25:07 UTC, David Gileadi wrote:
>> One in particular I'd like to replace is the silly $(P) macro on every single paragraph
> 
> Fun fact: this is the key issue that caused me to actually create adrdox.
> 
> Lots of problems with ddoc but the horrible paragraph handling was the finishing blow.

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.

On 6/13/20 8:41 AM, Seb wrote:
> On Saturday, 13 June 2020 at 09:24:52 UTC, Petar Kirov [ZombineDev] wrote:
>> On Saturday, 13 June 2020 at 03:33:14 UTC, Andrei Alexandrescu wrote:
>>>
>>> That should be killed with fire. I have seldom disliked a program this much.
>>
>> I think the most accurate way to classify your message is as "shitposting", which according to the (5th) definition in the Urban Dictionary [1] is:
>> 1: The failure to make a constructive post
>> 2: The inability to add useful information to a forum
>> 3: Worthless overly offensive generally racists posts written in a manner which aggravates others.
>> 4: Nrom
>>
>> Andrei, please use a more professional demeanor.
>>
>> [1]: https://www.urbandictionary.com/define.php?term=shitposting
> 
> I can't agree more. I miss the "original Andrei" :/

The original Andrei, just like today's Andrei, has an appreciation for good engineering. I didn't feel the need to add to provide detail because (a) most regulars in this forum already knew what I was going to say, and (b) nobody save for a few would share my opinion.

But, I'll bite again, again to regret it.

The absolute minimum - and I repeat, absolute minimum, first thing, knee-jerk thing - that one would expect from a custom build program would be that it separates the data (cmdline options, file names, environment vars, everything that's supposed to change often and easily) from the code that manipulates them and deals with things like tracking dependencies, parsing things, etc. If all is implemented in a single file I'd expect the data first, rules next, details at the end. build.d almost seems to want to make a point to be nothing like that.

* Available rules (rootRules) nicely appear on line 40.

* Then, we have main() dealing with a lot of stuff. (Why?)

* The rules using makeRule are a confusing mix of code and data starting at line 249, after the reader has browsed through a bunch of implementation details. (An interesting side question would be what language features would make such things easier to write; e.g. a mixin string in conjunction with a DSL that implements a small subset of make may be nicer. But also becomes ironic - we started by going away from make.)

* Configuration file stuff is at lines 297-315.

* Hundreds of lines of rules follow. It is natural to ask oneself to what extent they improve on makefile (or other build tools') syntax. I mean is this something easy on the eyes? Did build.d attain its objective?

 582  /// BuildRule to generate man pages
   583  alias man = makeRule!((builder, rule) {
   584      alias genMan = methodInit!(BuildRule, (genManBuilder, genManRule) => genManBuilder
   585          .target(env["G"].buildPath("gen_man"))
   586          .sources([
   587              dmdRepo.buildPath("docs", "gen_man.d"),
   588              env["D"].buildPath("cli.d")])
   589          .command([
   590              env["HOST_DMD_RUN"],
   591              "-I" ~ srcDir,
   592              "-of" ~ genManRule.target]
   593              ~ flags["DFLAGS"]
   594              ~ genManRule.sources)
   595          .msg(genManRule.command.join(" "))
   596      );
   597
   598      const genManDir = env["GENERATED"].buildPath("docs", "man");
   599      alias dmdMan = methodInit!(BuildRule, (dmdManBuilder, dmdManRule) => dmdManBuilder
   600          .target(genManDir.buildPath("man1", "dmd.1"))
   601          .deps([genMan, directoryRule(dmdManRule.target.dirName)])
   602          .msg("(GEN_MAN) " ~ dmdManRule.target)
   603          .commandFunction(() {
   604              writeText(dmdManRule.target, genMan.target.execute.output);
   605          })
   606      );
   607      builder
   608      .name("man")
   609      .description("Generate and prepare man files")
   610      .deps([dmdMan].chain(
   611          "man1/dumpobj.1 man1/obj2asm.1 man5/dmd.conf.5".split
   612          .map!(e => methodInit!(BuildRule, (manFileBuilder, manFileRule) => manFileBuilder
   613              .target(genManDir.buildPath(e))
   614              .sources([dmdRepo.buildPath("docs", "man", e)])
   615              .deps([directoryRule(manFileRule.target.dirName)])
   616              .commandFunction(() => copyAndTouch(manFileRule.sources[0], manFileRule.target))
   617              .msg("copy '%s' to '%s'".format(manFileRule.sources[0], manFileRule.target))
   618          ))
   619      ).array);
   620  });

* The source files are hardcoded somewhere starting at line 1160. I wish I was kidding.

* A lot more support code follows, which is fine for a single-file build tool. I wish this were a two-files affair a la build.d and buildinfo.d, or if single file have an obvious separation:

/****************************************************************
    IMPLEMENTATION FOLLOWS
****************************************************************/

On 6/13/20 4:30 AM, Seb wrote:
> I myself consider Phobos as low priority to maintain as it's basically frozen/dead code.

I was wondering what would be the drawbacks of defining an ultra-simple convention for versions of the standard library - with yearly granularity. Not being an expert in versioning I've always been coy to mention it, but how about trying it instead of the current stalemate. After all C++ does it (both with 3-year language versions and with things like std::tr1, std::tr2 etc) and it has a more dangerous modularity mechanism.

D's modularity is, or should be, rock solid. So then we could simply define "vYEAR" as versions of standard library modules. So:

// import the backward-compatible lib
import std.algorithm;
// import this year's algorithm with breaking changes
import std.v2020.algorithm;
// live dangerously, import work-in-progress
import std.v2020.algorithm;

Of course no need to define yearly versions for every year and every package/module. Just those that are worth adding backwards-breaking improvements.

A module should not import both std.xyz and std.v2020.xyz. Or the behavior is dependent on xyz and defined clearly.

I wonder how well this would work.