On Wednesday, 31 January 2018 at 11:42:14 UTC, Seb wrote:
> Here's a spoiler:
>
> 1) Andrei does an excellent job at managing his students [1] and there work over the last couple of months has been tremendous. As the experiment with UPB was very successful, there will be more projects like this one and global scholarship
>
> 2) The vision document will finally get updated (there have been a few delays due to holiday, illnesses etc.)
>
> https://wiki.dlang.org/Vision/2017H2
>
> 3) More community input (I'm preparing a State of D survey atm)
>
> 4) More active voting by the community on important issues
>
> 5) Better documentation and overview on what the foundation is doing
>
> Currently under discussion/work:
>
> 6) Using OpenCollective for tracking expenses openly
> 7) Offering membership packages for companies
> 8) Doing bi-annual Kickstarter compaigns for important issues to the community (e.g. "fix shared")

Thank you Seb and the other.

Sorry for going off the rails but i do like D a lot. Its the only reason i keep coming back for the same punishment time and time again. It simply gets so frustrating at times what feels like running into a stone wall.

Maybe the real issue is not the issues that need to be solved but the lack of "news". The blogs are very interesting and i applaud them. But is it maybe not time to have a real news section on the site where project status updates are provided. We are not talking blogs but smaller news snipes that do not take a lot of time, so people who do not spend there life on the forum or other locations feel like there is indeed movement. It can also help in the actual marketing.

On Wednesday, 31 January 2018 at 19:00:57 UTC, Jack Stouffer wrote:
> That's just something that Walter was able to bang out in an hour, should have been done years ago, and was excited about.

So it isn't a big deal, but IMO that should be left to an IDE or shell.

Back to the argument about cPython vs PyPy/dmd vs ldc. You want the reference compiler to be relatively simple and leave the unnecessary complications to the production compiler. So if DMD's backend was simple and only was a bare minimum implementation of the semantics then having multiple compilers would be comparable to the Python situation. PyPy is probably way too complicated to act as a reference and it would be difficult for Python to move if it had been the reference.

Some might say that DMD is too complicated to act as a reference as well, and that D has a problem moving because of it. If that is true, and I think it is, then the logical conclusion would be to make the DMD codebase simpler and leave performance to LDC. Like Python does with PyPy.

On 1/31/2018 5:54 AM, Jack Stouffer wrote:
> On Wednesday, 31 January 2018 at 07:56:37 UTC, Andrew Benton wrote:
>> E.g. three compilers
> 
> Every other compiled language (and a lot of scripting ones) uses the fact of multiple compilers for the language as a sign of adoption and ecosystem growth.
> 
> I've only ever seen people complain about D in this area. Never once have I seen someone argue that the existence of PyPy hurts Python or gogcc hurts Go.

Back when D had only one compiler, dmd, people complained it had only one compiler. Now that it has three, they complain that it has three.

Sometimes, ya just gotta ignore people.

On Wed, Jan 31, 2018 at 09:07:39PM +0000, John Gabriele via Digitalmars-d wrote:
> On Wednesday, 31 January 2018 at 20:03:11 UTC, Adam D. Ruppe wrote:
> > 
> > {snip} (well, I tried to get it upstream but I think upstream is a brick wall and not worth trying anymore)
> 
> That is very concerning to hear.

FWIW, here's my POV regarding "upstream", speaking as one who has no prior (or current!) personal connection with anyone involved with D development at the time, and who got granted commit access to Phobos only because one day I and another person whom I do not wish to name (who was at the time also not connected to "upstream") were complaining on the forum about lack of response to Phobos PRs, and *somebody*, presumably Andrei (but this is speculation on my part, as I was never actually told what happened exactly), decided to hand us the keys to the kingdom, so to speak, to see what we'd do with it.  I didn't merge anything for about a month or more afterwards, not out of intimidation or anything like that, but just feeling unqualified to make decisions of that sort just yet. I continued submitting PRs like an "outsider" for a while, and only later began to build up enough confidence to start merging PRs.

Even today, I contribute to D development purely out of my own interest, both in terms of technical interest, interest in seeing D improve because I use it for numerous personal projects, and also some amount of personal fulfilment in being able to contribute to something bigger than just my own projects.

The way I see it, is that the majority of PRs that get merged are in the category of small, incremental changes, things like bugfixes, small improvements to existing features, the odd useful tool here and there, that sort of thing.  Larger-scale changes do tend to take a lot more work (and persistence!) to push through, not because of any active policy or motive that hinder such changes, but primarily because as a volunteer-driven project, it's not very often that someone from among the volunteers would:

(1) Have the time to spend reviewing a large and complicated change;

(2) Have enough expertise in the affected area(s) of the project to feel
    confident enough to make decisions about it;

(3) Have all of the above plus the interest to actually *want* to wade
    into the depths of a large changeset, which implies the commitment
    to continue interacting with the submitter until it's merged or
    rejected, rather than do something else that's (a) more
    self-contained and easier to review, (b) can be done in a short
    amount of time that fits into their current stretch of free time,
    and (c) still contributes something positive to the project.

Large-scale changes do happen every now and then, such as Daniel Murphy's monumental effort in translating dmd's original C++ source into D, leading to the bootstrapping compiler we have today.  But these require a lot more effort and coordination with key decision makers, usually Walter & Andrei, and it really helps if you can convince one or both of them to take your side.  A "small fry" like myself wouldn't dare to push the merge button on changes of this kind of magnitude, since it could have drastic consequences that I can't foresee due to not having a full grasp of the full scale of what is being changed. Plus, sometimes somebody else *did* raise valid points of concern against the PR, so I would hold off merging until the concern is addressed and that person approves of the updated change. And in a large changeset, there can be a large number of such concerns, which requires a lot of back-and-forth before a decision can be reached.

Anyway, as far as Adam's dpldocs are concerned, the way I see it is this (and I'm saying this not as someone making the decision, but as a mostly-disinterested observer): Around the time it was first proposed, there are already two other competing documentation systems:

- The ddoc system, the original, and still in heavy use at the time, up
  till today;

- Sonke's newer one-page-per-function ddox system (which today has been
  partly integrated, but still not fully the default yet because of
  various issues that I didn't look too much into).

Having 3 different competing documentation systems is really crowded for this space, so for any of them to stand a chance, it has to be either already entrenched (ddoc), or else must offer significant advantages over its competitors.  More importantly, its proponent(s) would have to convince Andrei or Walter of said significant advantages, since that's what will tip the scale (obviously, its proponents must believe it has significant advantages otherwise they wouldn't have proposed it in the first place -- but the deciding factor is whether Andrei and/or Walter think likewise).

And IIRC, Andrei had already bought into the ddox system by then (the process of merging it might have already begun, I'm not 100% certain), so dpldocs was already starting from a disadvantaged position, whatever merits it may have on its own.  And I'll be frank that sometimes Andrei can take some effort to convince, and it takes a certain amount of dogged persistence (and thick-skin) to get through to him sometimes. And it doesn't help that he has so much on his plate, and generally doesn't have enough time to dedicate to all the decisions waiting upon him to make, so sometimes it can be frustrating trying to get through to him.

So to get through, dpldocs would need show a major advantage over ddoc and ddox, and Adam (and whoever else) would need to be persistent enough to convince Andrei to approve of it, and then it would require the effort to integrate it into everything else that's currently being used for generating docs on dlang.org -- since obviously, it wouldn't do for a new doc system to get merged, only for everyone to find that parts of dlang.org are now broken, or not working as well as before, or Phobos doc builds now have new issues, etc..

AFAICT, none of this is any deliberate roadblock or "brickwalling" to stop alternative proposals from being accepted, but it's mostly just due to circumstantial situations that arose, for better or for worse, as part of how D came to be what it is today.  In that sense, I don't blame Adam from deciding to fork instead -- given the circumstances, that's certainly the path of least resistance, unfortunate as it is.  With ddoc still entrenched as the de facto documentation system, and with ddox already merged and continuing to be improved with the view of becoming the new default docs (not my personal preference, but that's the direction it's headed), any alternative proposals would have a pretty tough uphill fight to get through.  It's unfortunate, but I don't think it's unreasonable either -- as I said, if it would not bring new, compelling advantages to the table, then it's pretty hard to justify all the work it would take to merge it and then maintain it afterwards. At least, it would be pretty tough to convince Andrei about this.


T

-- 
MACINTOSH: Most Applications Crash, If Not, The Operating System Hangs

On 1/31/2018 11:59 AM, Seb wrote:
> ... and Mike did put _a lot_ of effort in pushing colorful error messages:

Yes, and he did a nice job of it.

The results are attractive, worthwhile, and resolves a specific complaint people had about dmd's error messages.

On 1/31/2018 1:19 PM, H. S. Teoh wrote:
> I'd rather stick with just B&W.

  dmd -color=off file.d

On Wed, Jan 31, 2018 at 05:16:21PM -0800, Walter Bright via Digitalmars-d wrote:
> On 1/31/2018 1:19 PM, H. S. Teoh wrote:
> > I'd rather stick with just B&W.
> 
>   dmd -color=off file.d

Thanks!

Though, as I said, it doesn't bother me quite enough to want to go through the effort of explicitly specifying that.  It's just that, if it were up to me, I wouldn't bother putting in the time and energy to implement such kinds of cosmetic features.


T

-- 
He who sacrifices functionality for ease of use, loses both and deserves neither. -- Slashdotter

On Wednesday, January 31, 2018 17:16:21 Walter Bright via Digitalmars-d wrote:
> On 1/31/2018 1:19 PM, H. S. Teoh wrote:
> > I'd rather stick with just B&W.
>
>    dmd -color=off file.d

I have to wonder if my settings are right. I've never noticed any color in error messages. Messing around with some errors right now, the only color I see is that "Error:" is in red, and some of the text is bolded, so it's white instead of the grey that text is normally on my console. Maybe my console's settings aren't interacting with the color stuff very well.

- Jonathan M Davis

On Wed, Jan 31, 2018 at 07:14:57PM -0700, Jonathan M Davis via Digitalmars-d wrote:
> On Wednesday, January 31, 2018 17:16:21 Walter Bright via Digitalmars-d wrote:
> > On 1/31/2018 1:19 PM, H. S. Teoh wrote:
> > > I'd rather stick with just B&W.
> >
> >    dmd -color=off file.d
> 
> I have to wonder if my settings are right. I've never noticed any color in error messages. Messing around with some errors right now, the only color I see is that "Error:" is in red, and some of the text is bolded, so it's white instead of the grey that text is normally on my console. Maybe my console's settings aren't interacting with the color stuff very well.
[...]

I thought that *is* the color support that was added?  If you're expecting IDE-style syntax highlighting, I think you're setting your expectations a little high for something that ostensibly was banged out in a couple of hours. :-D


T

-- 
Be in denial for long enough, and one day you'll deny yourself of things you wish you hadn't.

On Thursday, 1 February 2018 at 02:24:44 UTC, H. S. Teoh wrote:
> I thought that *is* the color support that was added?  If you're expecting IDE-style syntax highlighting, I think you're setting your expectations a little high for something that ostensibly was banged out in a couple of hours.

Nope, the dmd compiler will highlight code between `` in its outputted error messages. dmd already knows how to lex D code (obviously) and even has a highlighter for ddoc, so it just pipes it through that existing function.

Not all error messages had the `` around its code though. That's what Mike did in most his PRs.