Am 10.06.2014 12:25, schrieb w0rp:
> On Tuesday, 10 June 2014 at 08:12:53 UTC, Sönke Ludwig wrote:
>> It's not heap allocations. The problem is that during CTFE, currently
>> basically every variable change allocates memory that is never freed
>> again. I've used a few tricks to get the memory usage down (which is
>> why the Diet compiler source code doesn't look very pretty), but
>> basically the only way to get reasonable memory use is to fix the D
>> front end.
>
> Indeed, this is a front end issue. I'm considering switching to markdown
> files loaded at runtime for many pages. So I can create only a few diet
> templates for basic layout, two column, generic changelog template, etc,
> and then load Markdown content at runtime and parse Markdown for
> generating the table of contents automatically.

If you go down the Markdown route*, let's extend the vibe.textfilter.markdown module to output structural information. Writing a Markdown parser in a way that doesn't use a cascade of regex patterns is definitely nothing I'd recommend anyone to try to do, unless absolutely necessary - it's awful.

* Are there any other opinions on this? I remember that there have been some strong proponents of using DDOC for things, so it would be bad if in the end Markdown were to be dropped, after all of the work has already been done. Personally I'd strongly favor Markdown, though.

On Tuesday, 10 June 2014 at 10:42:14 UTC, Sönke Ludwig wrote:
> * Are there any other opinions on this? I remember that there have been some strong proponents of using DDOC for things, so it would be bad if in the end Markdown were to be dropped, after all of the work has already been done. Personally I'd strongly favor Markdown, though.

DDOC was promoted because of dog-fooding rationale but I believe it has unacceptable learning curve and negatively impacts documentation contribution.

On 10/06/14 10:12, Sönke Ludwig wrote:

> But yes, it's definitely not what you want to have for D. I'm not sure
> how much can be done about that, though - except from rewriting the CTFE
> engine with performance in mind (maybe even using a JIT compiler). Or
> maybe it's possible to be more liberal with algorithmic optimizations
> when the CTFE memory usage brought to a reasonable level.

Can the templates be compiled in a separate phase, not using CTFE but as a regular compiler?

-- 
/Jacob Carlborg

On Tuesday, 10 June 2014 at 11:09:41 UTC, Jacob Carlborg wrote:
> On 10/06/14 10:12, Sönke Ludwig wrote:
>
>> But yes, it's definitely not what you want to have for D. I'm not sure
>> how much can be done about that, though - except from rewriting the CTFE
>> engine with performance in mind (maybe even using a JIT compiler). Or
>> maybe it's possible to be more liberal with algorithmic optimizations
>> when the CTFE memory usage brought to a reasonable level.
>
> Can the templates be compiled in a separate phase, not using CTFE but as a regular compiler?

Or, just like ctRegx vs regx, can we have a runtime version of diet template that runs slower but doesn't need to compile? It would be great for development phase.

On Tuesday, 10 June 2014 at 11:35:32 UTC, Puming wrote:
> On Tuesday, 10 June 2014 at 11:09:41 UTC, Jacob Carlborg wrote:
>> On 10/06/14 10:12, Sönke Ludwig wrote:
>>
>>> But yes, it's definitely not what you want to have for D. I'm not sure
>>> how much can be done about that, though - except from rewriting the CTFE
>>> engine with performance in mind (maybe even using a JIT compiler). Or
>>> maybe it's possible to be more liberal with algorithmic optimizations
>>> when the CTFE memory usage brought to a reasonable level.
>>
>> Can the templates be compiled in a separate phase, not using CTFE but as a regular compiler?
>
> Or, just like ctRegx vs regx, can we have a runtime version of diet template that runs slower but doesn't need to compile? It would be great for development phase.

We can't because Diet templates may contain arbitrary D code inline.

On Tuesday, 10 June 2014 at 10:42:14 UTC, Sönke Ludwig wrote:
> Am 10.06.2014 12:25, schrieb w0rp:
>> On Tuesday, 10 June 2014 at 08:12:53 UTC, Sönke Ludwig wrote:
>>> It's not heap allocations. The problem is that during CTFE, currently
>>> basically every variable change allocates memory that is never freed
>>> again. I've used a few tricks to get the memory usage down (which is
>>> why the Diet compiler source code doesn't look very pretty), but
>>> basically the only way to get reasonable memory use is to fix the D
>>> front end.
>>
>> Indeed, this is a front end issue. I'm considering switching to markdown
>> files loaded at runtime for many pages. So I can create only a few diet
>> templates for basic layout, two column, generic changelog template, etc,
>> and then load Markdown content at runtime and parse Markdown for
>> generating the table of contents automatically.
>
> If you go down the Markdown route*, let's extend the vibe.textfilter.markdown module to output structural information. Writing a Markdown parser in a way that doesn't use a cascade of regex patterns is definitely nothing I'd recommend anyone to try to do, unless absolutely necessary - it's awful.
>
> * Are there any other opinions on this? I remember that there have been some strong proponents of using DDOC for things, so it would be bad if in the end Markdown were to be dropped, after all of the work has already been done. Personally I'd strongly favor Markdown, though.

Definitely support Markdown.

DDoc is extremely discouraging/making bad first impression on newbies, especially for people who want to write web content.

(But I'd recommend extended GitHub-like markdown if possible, plain markdown is pretty bare bones. Personally I use ReStructuredText but I think the GitHub markdown is pretty good and most potential contributors can already write it without learning a new format.

On Tue, 2014-06-10 at 12:31 +0000, Kiith-Sa via Digitalmars-d wrote:
> On Tuesday, 10 June 2014 at 10:42:14 UTC, Sönke Ludwig wrote:
[…]
> > * Are there any other opinions on this? I remember that there have been some strong proponents of using DDOC for things, so it would be bad if in the end Markdown were to be dropped, after all of the work has already been done. Personally I'd strongly favor Markdown, though.

Isn't DDoc for generating API documentation is the vein of Doxygen, JavaDoc, etc., and isn't this discussion about generating general (albeit technical) webpages?

> Definitely support Markdown.
> 
> DDoc is extremely discouraging/making bad first impression on newbies, especially for people who want to write web content.
> 
> (But I'd recommend extended GitHub-like markdown if possible, plain markdown is pretty bare bones. Personally I use ReStructuredText but I think the GitHub markdown is pretty good and most potential contributors can already write it without learning a new format.

The Groovy community initially tried using GrailsDoc – not an API documentation system, but a way of writing general documentation that could easily access API documentation. However, the move now appears to be to ASCIIDoc using the ASCIIDoctor toolchain.

As for ReStructured Text, I find Markdown beats it for short pages, but it beats Markdown easily for bigger documents. The Sphinx system may not be appropriate for D, but it works very well.

-- 
Russel. ============================================================================= Dr Russel Winder      t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net 41 Buckmaster Road    m: +44 7770 465 077   xmpp: russel@winder.org.uk London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder

On 6/10/14, 3:42 AM, Sönke Ludwig wrote:
> * Are there any other opinions on this? I remember that there have been
> some strong proponents of using DDOC for things, so it would be bad if
> in the end Markdown were to be dropped, after all of the work has
> already been done. Personally I'd strongly favor Markdown, though.

I think ddoc is a lot more flexible than markdown, and I'm baffled by the claim that ddoc is difficult to learn. That said I do agree it's a turnoff for first-time website contributors. IMHO if we switch away from ddoc we should switch to something better, not something just different. -- Andrei

On Tuesday, 10 June 2014 at 11:09:23 UTC, Dicebot wrote:
> On Tuesday, 10 June 2014 at 10:42:14 UTC, Sönke Ludwig wrote:
>> * Are there any other opinions on this? I remember that there have been some strong proponents of using DDOC for things, so it would be bad if in the end Markdown were to be dropped, after all of the work has already been done. Personally I'd strongly favor Markdown, though.
>
> DDOC was promoted because of dog-fooding rationale but I believe it has unacceptable learning curve and negatively impacts documentation contribution.

I think the key advantage for Markdown is that it's well understood by a larger community, (GitHub, Stack Overflow, Reddit, etc.) so it would likely encourage contribution to editing pages on the website. It's also just has very nice syntax for writing articles with, although I know how frustrating it is to write a parser for it. (You have to accept stuff which is sometimes HTML, sometimes not.)

The library documentation will still be DDoc generated, as that's the best tool for that, just styled differently.

On 10/06/14 13:09, Dicebot wrote:

> DDOC was promoted because of dog-fooding rationale but I believe it has
> unacceptable learning curve and negatively impacts documentation
> contribution.

I think Ddoc is fine for API documentation, but not for designing a web site.

-- 
/Jacob Carlborg