On Thursday, 1 February 2018 at 11:21:37 UTC, Russel Winder wrote:
> D should be proud of having a reference compiler, a GCC-based one, and an LLVM-based one. This is a Good Thing™, let no-one undermine this.

Nothing wrong with choice as long as that choice does not introduces issues. Currently there are 3 compilers but also 3 different ways to install ( depending on the platform ). DMD has a installer, LDC needs a manual copy job + path creation, GDC did not even bother with ( sorry ).

Let alone 'conflicts':

Example: Install DMD ( what has its own DUB ) but also install LDC ( what has its own DUB), now lets say both version have different dub versions. Yes, this happened to me and it conflicted with some of the Editor plugins their build process because the wrong "version" of dub got selected during the build process. Its not really a bug but a issue that can trip people ( lost a hour on that one ).

Other issues can be that it makes conversations difficult. When new people read DMD, LDC, GDC in these forums, you can just as well be speaking Mandarin ( Chinese ).

Suggestion:

Is it maybe not better to have one "front-end" compiler visible that people download

Example:

D run main.d
D run main.d --compiler ldc ( not installed? Auto download and compile using dub )
D run main.d --compiler ldc --options -o3
D run main.d --compiler gdc ( not installed? Auto ...)

D package install web-d

Seen this layout with a some other compilers where everything is clean integrated.

- Compiler ( default )
-- Run
-- Test

- Package
-- Install
-- Remove
-- Update

- Tools
--- Format
--- Check
- Language server?

No dub, no ldc, gdc, no confusion, just one clean interface. What happens behind the interface is nobody there business. It just presents better.

Dub already does half this work with the compiler option but its a package manager not the "face of D". Hard to explain...

Anyway, too much off-topic?

On Thu, 2018-02-01 at 15:27 +0000, Benny via Digitalmars-d wrote:
> 
[…]
> Nothing wrong with choice as long as that choice does not introduces issues. Currently there are 3 compilers but also 3 different ways to install ( depending on the platform ). DMD has a installer, LDC needs a manual copy job + path creation, GDC did not even bother with ( sorry ).

For me:

aptitude install ldc
aptitude install gdc
aptitude install dmd-bin
aptitude install dub

Seems to work fine, and no conflicts.

[…]
-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

On Thu, Feb 01, 2018 at 03:47:50PM +0000, Russel Winder via Digitalmars-d wrote:
> On Thu, 2018-02-01 at 15:27 +0000, Benny via Digitalmars-d wrote:
> > 
> […]
> > Nothing wrong with choice as long as that choice does not introduces issues. Currently there are 3 compilers but also 3 different ways to install ( depending on the platform ). DMD has a installer, LDC needs a manual copy job + path creation, GDC did not even bother with ( sorry ).
> 
> For me:
> 
> aptitude install ldc
> aptitude install gdc
> aptitude install dmd-bin
> aptitude install dub
> 
> Seems to work fine, and no conflicts.
[...]

Only because the OS has a sane packaging system (and some people were kind enough to package the compilers in nice packages). For less-privileged OSes, the user experience could be drastically different. ;-)


T

-- 
Prosperity breeds contempt, and poverty breeds consent. -- Suck.com

On Thursday, 1 February 2018 at 16:17:45 UTC, H. S. Teoh wrote:
> On Thu, Feb 01, 2018 at 03:47:50PM +0000, Russel Winder via Digitalmars-d wrote:
>> On Thu, 2018-02-01 at 15:27 +0000, Benny via Digitalmars-d wrote:
>> > 
>> […]
>> > Nothing wrong with choice as long as that choice does not introduces issues. Currently there are 3 compilers but also 3 different ways to install ( depending on the platform ). DMD has a installer, LDC needs a manual copy job + path creation, GDC did not even bother with ( sorry ).
>> 
>> For me:
>> 
>> aptitude install ldc
>> aptitude install gdc
>> aptitude install dmd-bin
>> aptitude install dub
>> 
>> Seems to work fine, and no conflicts.
> [...]
>
> Only because the OS has a sane packaging system (and some people were kind enough to package the compilers in nice packages). For less-privileged OSes, the user experience could be drastically different. ;-)
>
>
> T

curl https://i.dlang.io/install.sh | bash -s dmd
~/dlang/install.sh ldc
~/dlang/install.sh gdc

Works on all Posix systems
Now to use LDC as default:

. ~/dlang/install.sh -a ldc


Didn't we have this discussion yesterday already?
See also: https://dlang.org/install.html

On Thursday, 1 February 2018 at 15:47:50 UTC, Russel Winder wrote:
> For me:
>
> aptitude install ldc
> aptitude install gdc
> aptitude install dmd-bin
> aptitude install dub
>
> Seems to work fine, and no conflicts.
>
> […]

Please try Windows and then come back ;)

On Thursday, 1 February 2018 at 03:00:07 UTC, Walter Bright wrote:
> On 1/31/2018 5:58 PM, H. S. Teoh wrote:
>> cosmetic features.
>
> I tough lesson I've learned is that cosmetics matter, a lot. Sometimes much more than substance. There's no getting away from it.

This is one reason I recommend markdown for docs. Cosmetics is what markdown does best. People *like* looking at it and editing it. It's like typing an email or a forum comment.

Other reasons I recommend it are:

  * everyone already knows it (it's at github, stackoverflow, and reddit),

  * it's fairly easy to write (as easy as possible while still looking good),

  * there's an open spec (CommonMark), and

  * writing new language-specific markup formats appears to be something that's not done anymore. There's javadoc, texinfo, doxygen, docbook, groff --- all very ... *mature* technologies. In modern projects: Rust uses markdown, Python uses reST, Git uses asciidoc --- all general-purpose non- language-specific lightweight markup formats.

The only reason I can think of for *not* using markdown for project docs is if your project is another competing lightweight markup format.

On Thursday, 1 February 2018 at 11:06:09 UTC, Russel Winder wrote:
> On Wed, 2018-01-31 at 16:13 +0000, John Gabriele via Digitalmars-d wrote:
>> […]
>> this older language from times past, before C++11, and using ddoc
>> for docs instead of markdown contributes to this perception. Let
>> me know if you'd like help in translating D website and doc pages
>> from ddoc to markdown.
>
> I am sure Markdown is find for single page HTML pages, but for bigger documents that need to render to HTML or PDF (or other e-publishing formats) surely AsciiDoctor and XeLaTeX are the only choices.

It's trivial to put multiple markdown files together into a large doc, if that's desired. Just put a bunch of .md files together into the same directory and run your markdown processor on them. They can link to each other in the [normal way](./other-file.html#normal-way).

Markdown provides a simple, practical, modern, and commonly-known way to get docs written fast and by anyone who wants to pop in and improve them. There's no easier way to write plain text docs that look as good.

Sorry, can't recall if I already mentioned this, but D suffers from a perception that it's "old", or "the language that tried and failed to replace C++". Something simple like markdown for its docs sends a clear message that D is modern and knows when to pivot to new and better ways after the old ways are not serving it anymore.

Incidentally, choosing an established standard like markdown is a good way to short-circuit bikeshedding about "it what ways should ddoc be updated to include some markdown features?". Just pick standard CommonMark markdown and you're done.

One last note and I'll (try to!) stop: it's difficult enough to get good writers to help with docs. Much more so when they've got to first learn your own language-specific markup (which is only useful with your project).

On 2/1/2018 3:11 AM, Martin Tschierschke wrote:
> Idea: There should be some kind of news ticker for all enhancements and important decisions, maybe at first just via twitter  with a special #tag  beside #dlang where all updates are announced. And a place on the homepage, where this feed is displayed separately.

It's already there on the right side of https://dlang.org/

On 01/31/2018 06:38 PM, H. S. Teoh wrote:
> 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.

Thanks for the critique. I'm trying to get better organized at being less of a bottleneck every day.

Regarding the documentation system, at a high level it's clear that working to improve the established solutions is often a sensible and productive way to go about things. This is not core language so we have no important backward compatibility issues.

A distinct documentation system seeking to replace the existent ones would need to present a strong motivation. I would be hard pressed to recall that we were presented with a good case that we rejected without due consideration.


Andrei

On Wednesday, 31 January 2018 at 11:42:14 UTC, Seb wrote:

> Yes, obviously the current situation isn't ideal, but it's not too bad either and we have found one good, but probably not so well-known yet way to tackle this: the dlang-community organization on GH (https://github.com/dlang-community).
> A lot of important, but more or less abandoned repositories have been adopted, s.t. there's a common place to submit bug fixes and feature PRs and its ensured by CIs that they are always in a good state, e.g. always compile with the latest DMD.

Wait, have libdparse et al. been abandoned? What happened to Brian?