On Monday, 2 June 2014 at 12:42:02 UTC, Jacob Carlborg wrote:
> On 01/06/14 07:50, Russel Winder via Digitalmars-d wrote:
>
>> Contrast level is still a bit high though. The current dlang.org also
>> has this problem because of the use of white. I am not pushing dark grey
>> on light grey with spot colour (which is how Apple started out and still
>> use a lot) but something with less contrast might lead to a nice brand
>> imagery. Red, brown and black are clearly the base for a D brand, so
>> maybe washed out red-brown background rather than white. I haven't tried
>> this, it's just an idea – which may turn out to be rubbish.
>
> I tried and changed the background color of the #page-wrapper element to #CCCCCC. I think that looks good, although I usually prefer lighter themes.

By the way, feel free to contribute to development of the new site if you want to, and this goes for everyone who's interested in helping out. https://github.com/w0rp/new-dlang.org

I'm currently in the process of breaking down the change log into smaller pages, as the change log was getting near to 1MB of HTML. At this point, working on anything but the change log page could be helpful.

On 01/06/14 21:56, w0rp wrote:

> You just reminded me to put in a query string version hack at some
> point. I typically use something like ?v=<epoch_of_server_start> or
> similar.

That's not reliable. It's usually assets that are the problem, CSS, JS, images and so on. They should have a unique hash based on the content appended to the filename. Then you can have really long cache timeout (or what it's called) on those files.

-- 
/Jacob Carlborg

On Saturday, 31 May 2014 at 19:49:22 UTC, w0rp wrote:
> After watching Andrei's keynote where he was asking for help, and noticing that there wasn't any proof of someone working on this, I took charge.
>
> http://w0rp.com:8010/

Looks good! Can twitter widget be forced to rescale on wider screens? It looks very annoying right now with scroll-bar and lot of line breaks when half of the space is still available.

> * For pages, DDoc is replaced with diet templates.

If this will happen, I will actually start to contribute to documentation :)

On 2014-06-02 16:45, Dicebot wrote:

> If this will happen, I will actually start to contribute to
> documentation :)

Agree. This would also make a reason for me to learn vibe.d.

-- 
/Jacob Carlborg

Hmm... doesn't scale well, the main text remains crammed into fixed 1/3 of the page width, the rest is empty space.

On Monday, 2 June 2014 at 19:16:04 UTC, Kagamin wrote:
> Hmm... doesn't scale well, the main text remains crammed into fixed 1/3 of the page width, the rest is empty space.

There should be a maximum width on the text you read on a page. Once column size becomes so large, your reading speed will decrease.

Shouldn't it be measured in characters instead of percentage of page width?

I have updated the site and the repository with all of the D changelogs split into their own pages. I had to reformat a few things, primarily example code, so it would fit nicely in smaller column sizes. I marked sections with headings so it fits into a table of contents. One major thing that's missing is syntax highlighting, as I'm not sure what to use for that.

http://w0rp.com:8010/changelog

Here is what I've noticed so far that's good about the diet templates.

1. The template syntax, taken from Jade, is easy to understand and clean.
2. I can do tricks like the table of contents easily.

However, with the good comes the bad.

1. If you are recompiling one template, you are recompiling *all* of them. I'm getting closer to 100 templates, and it takes seconds to compile.
2. Compiling many templates allocates like crazy during compile time and eats memory like a hog. It takes *5GB* of RAM to compile all of these templates.

It seems like the vibe.d diet templates take heap allocation during compilation time way, way too far, to the point of them being impractical to use for large websites. Somewhere around 100 templates is something I would expect for a reasonably sized website.

So I have a plea or two for vibe.d

In addition to recompiling diet templates automatically during development, which has been mentioned before, I believe there should be an option to defer compilation of a template the first time, during development, until you view a page using it for the first time. This woud solve the slower compilation issue, because then you'd only pay for what you used.

Second, something must be done about memory allocation during compilation of diet templates. There's too much going on there.

That's it for now.

Am 10.06.2014 02:18, schrieb w0rp:
> I have updated the site and the repository with all of the D changelogs
> split into their own pages. I had to reformat a few things, primarily
> example code, so it would fit nicely in smaller column sizes. I marked
> sections with headings so it fits into a table of contents. One major
> thing that's missing is syntax highlighting, as I'm not sure what to use
> for that.
>
> http://w0rp.com:8010/changelog
>
> Here is what I've noticed so far that's good about the diet templates.
>
> 1. The template syntax, taken from Jade, is easy to understand and clean.
> 2. I can do tricks like the table of contents easily.
>
> However, with the good comes the bad.
>
> 1. If you are recompiling one template, you are recompiling *all* of
> them. I'm getting closer to 100 templates, and it takes seconds to compile.

Sounds kind of like an ironic joke when viewed from a C++ background ;)

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.

> 2. Compiling many templates allocates like crazy during compile time and
> eats memory like a hog. It takes *5GB* of RAM to compile all of these
> templates.

Yes, which is why (at least with the current compiler front end) I'd strongly recommend to put long text content in a different format that is inserted at runtime (e.g. DDOC or Markdown).

>
> It seems like the vibe.d diet templates take heap allocation during
> compilation time way, way too far, to the point of them being
> impractical to use for large websites. Somewhere around 100 templates is
> something I would expect for a reasonably sized website.

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.

>
> So I have a plea or two for vibe.d
>
> In addition to recompiling diet templates automatically during
> development, which has been mentioned before, I believe there should be
> an option to defer compilation of a template the first time, during
> development, until you view a page using it for the first time. This
> woud solve the slower compilation issue, because then you'd only pay for
> what you used.

That would probably even be a side-effect of the implementation of separately compiled templates (eagerly compiling them will require some additional code).

>
> Second, something must be done about memory allocation during
> compilation of diet templates. There's too much going on there.
>
> That's it for now.

See also https://issues.dlang.org/show_bug.cgi?id=6498

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.