Hello everyone.
I am wondering about `update` and `require` properties of AAs which are mentioned to be present here: https://dlang.org/spec/hash-map.html#properties
However, this code doesn't compile:
```
import std.stdio;
void main()
{
    class C{}
	int[C] aa;

	auto a = aa.require("a", new C());
}
```
Notice that this is the very code from the specification.
Compiler says: "Error: no property require for type int[C]".
The same situation with `update` property.
So, I'm wondering is this a bug of some kind or just the spec isn't updated.

Thank you.

On Tuesday, 26 June 2018 at 07:05:44 UTC, Vasniktel wrote:
> Hello everyone.
> I am wondering about `update` and `require` properties of AAs which are mentioned to be present here: https://dlang.org/spec/hash-map.html#properties
> However, this code doesn't compile:
> ```
> import std.stdio;
> void main()
> {
>     class C{}
> 	int[C] aa;
>
> 	auto a = aa.require("a", new C());
> }
> ```
> Notice that this is the very code from the specification.
> Compiler says: "Error: no property require for type int[C]".
> The same situation with `update` property.
> So, I'm wondering is this a bug of some kind or just the spec isn't updated.
>
> Thank you.

I think the documentation gets published prematurely.  The new methods for the associative arrays should come in the next release, scheduled for July 1st.  https://dlang.org/changelog/pending.html#require_update

Mike

On Tuesday, 26 June 2018 at 07:25:09 UTC, Mike Franklin wrote:
>
> I think the documentation gets published prematurely.  The new methods for the associative arrays should come in the next release, scheduled for July 1st.  https://dlang.org/changelog/pending.html#require_update
>
> Mike

Wow, thanks a lot.
I have forgotten to check future releases :)

On Tue, Jun 26, 2018 at 07:25:09AM +0000, Mike Franklin via Digitalmars-d wrote: [...]
> I think the documentation gets published prematurely.  The new methods for the associative arrays should come in the next release, scheduled for July 1st.  https://dlang.org/changelog/pending.html#require_update
[...]

Seriously, we need to start implementing versioned docs on dlang.org.


T

-- 
If lightning were to ever strike an orchestra, it'd always hit the conductor first.

On Tuesday, 26 June 2018 at 15:51:00 UTC, H. S. Teoh wrote:
> On Tue, Jun 26, 2018 at 07:25:09AM +0000, Mike Franklin via Digitalmars-d wrote: [...]
>> I think the documentation gets published prematurely.  The new methods for the associative arrays should come in the next release, scheduled for July 1st.  https://dlang.org/changelog/pending.html#require_update
> [...]
>
> Seriously, we need to start implementing versioned docs on dlang.org.
>
>
> T

Doesn't it already offer it?

Here https://dlang.org/spec/hash-map.html
in the very top right corner you can diverge from master.
However it seems a bit bugged that when selecting something else than master, it suddenly prints master again, and there is no way to get back to master. Looks a bit broken.

Wouldn't it be better to reflect the latest published version of the docs there as a default??

On 6/26/18 11:51 AM, H. S. Teoh wrote:
> On Tue, Jun 26, 2018 at 07:25:09AM +0000, Mike Franklin via Digitalmars-d wrote:
> [...]
>> I think the documentation gets published prematurely.  The new methods
>> for the associative arrays should come in the next release, scheduled
>> for July 1st.  https://dlang.org/changelog/pending.html#require_update
> [...]
> 
> Seriously, we need to start implementing versioned docs on dlang.org.

We do. But stable right now is in beta, so the docs are going to reflect what will soon be released.

What we probably should do is have a "released" branch for the docs. Or just answer the odd question every once in a while on the forums :)

-Steve

On Tue, Jun 26, 2018 at 04:17:03PM +0000, Timoses via Digitalmars-d wrote:
> On Tuesday, 26 June 2018 at 15:51:00 UTC, H. S. Teoh wrote:
[...]
> > Seriously, we need to start implementing versioned docs on dlang.org.
[...]
> Doesn't it already offer it?
> 
> Here https://dlang.org/spec/hash-map.html
> in the very top right corner you can diverge from master.

Ah, I must have missed that button!


> However it seems a bit bugged that when selecting something else than master, it suddenly prints master again, and there is no way to get back to master. Looks a bit broken.
> 
> Wouldn't it be better to reflect the latest published version of the docs there as a default??

Yeah, the default docs should be the latest published version, not git master.  Most visitors to the website wouldn't be running git master, so it's a bit strange (and very confusing!) to use that by default. Phobos docs already have phobos-prerelease/ for git master and phobos/ for the current release; the language spec pages need to do something similar.


T

-- 
What are you when you run out of Monet? Baroque.

On 6/26/18 12:48 PM, Steven Schveighoffer wrote:
> On 6/26/18 11:51 AM, H. S. Teoh wrote:
>> On Tue, Jun 26, 2018 at 07:25:09AM +0000, Mike Franklin via Digitalmars-d wrote:
>> [...]
>>> I think the documentation gets published prematurely.  The new methods
>>> for the associative arrays should come in the next release, scheduled
>>> for July 1st.  https://dlang.org/changelog/pending.html#require_update
>> [...]
>>
>> Seriously, we need to start implementing versioned docs on dlang.org.
> 
> We do. But stable right now is in beta, so the docs are going to reflect what will soon be released.
> 
> What we probably should do is have a "released" branch for the docs. Or just answer the odd question every once in a while on the forums :)
> 

Oh wait, this is the dlang.org repository.

Yeah, so in answer to a few questions here:

1. The dlang.org repository is backwards -- master generates the docs for the default dlang.org. I've brought this up before, still don't understand why we don't use stable for the latest dlang.org.

2. No, the new hash-map methods will not be in 2.081 releasing on July 1st, because that merge was more recent than the date 2.081 was branched for release (6/17).

-Steve

On Tue, Jun 26, 2018 at 12:54:11PM -0400, Steven Schveighoffer via Digitalmars-d wrote: [...]
> 1. The dlang.org repository is backwards -- master generates the docs for the default dlang.org. I've brought this up before, still don't understand why we don't use stable for the latest dlang.org.

Probably because we want to keep phobos-prerelease up-to-date with git master?

The only sane way to do this IMO is to make the dlang.org makefiles generate multiple versions of the docs, thereby acting as the authoritative source for all dlang.org pages.  This means released specs need to be archived separately (e.g., by copying to spec/${version}/* and linking stuff there).

I just checked the versioned docs with the button on the upper right of the page... it links to dlang.io, which IMO is a bad idea, not because of dlang.io itself but because we're basically relying on an external URL to contain what we assume it might contain.  IMO it's better to keep all versions of the docs in a single repo (dlang.org) so that things can be updated/refreshed from a single source, in keeping with SSOT.  Doing it that way then lets us do things like fix typos in older docs without unnecessary complications.


> 2. No, the new hash-map methods will not be in 2.081 releasing on July 1st, because that merge was more recent than the date 2.081 was branched for release (6/17).
[...]

That makes it even the more confusing. :-/


T

-- 
Valentine's Day: an occasion for florists to reach into the wallets of nominal lovers in dire need of being reminded to profess their hypothetical love for their long-forgotten.

On Tuesday, 26 June 2018 at 17:12:37 UTC, H. S. Teoh wrote:
> On Tue, Jun 26, 2018 at 12:54:11PM -0400, Steven Schveighoffer via Digitalmars-d wrote: [...]
>> 1. The dlang.org repository is backwards -- master generates the docs for the default dlang.org. I've brought this up before, still don't understand why we don't use stable for the latest dlang.org.
>
> Probably because we want to keep phobos-prerelease up-to-date with git master?

FWIW the docs in the release archives are built from stable.
The reason is that both stable _and_ master are built on dlang.org, so historically no one was interested in doing release management for the docs.

> The only sane way to do this IMO is to make the dlang.org makefiles generate multiple versions of the docs, thereby acting as the authoritative source for all dlang.org pages.

It already takes 20 minutes to do a full build of all dlang.org HTML pages.
Doing it for old versions is a REALLY bad idea as you are susceptible to
- more random failures (e.g. DUB registry being down)
- it will take hours for each build
- it won't be possible to do it in a CI for each PR due to the large time required, which means the deployment could be broken without us knowing
- resources might be offline or change (e.g. currently it fetches the RSS from the DBlog for the frontpage indexes, this already broke the build a few times)
- building all versions will fail due to newer dependencies or OS-level changes (e.g. -fPIC, glibc changes, ...)

> This means released specs need to be archived separately (e.g., by copying to spec/${version}/* and linking stuff there).
>
> I just checked the versioned docs with the button on the upper right of the page... it links to dlang.io, which IMO is a bad idea, not because of dlang.io itself but because we're basically relying on an external URL to contain what we assume it might contain.  IMO it's better to keep all versions of the docs in a single repo (dlang.org) so that things can be updated/refreshed from a single source, in keeping with SSOT.  Doing it that way then lets us do things like fix typos in older docs without unnecessary complications.

Ehm the docarchives are simple a snapshot of each version (that's why the "Improve this page" doesn't work or the "Version" button says it's stable even though it's 2.076 (or there isn't even a version button at all).
Anyhow, I'm pretty sure that we don't want to put all the HTML files into the main dlang.org git repo. It's about 5 GB extracted.
The repo is here and part of the official D GitHub organization

https://github.com/dlang/docarchives.dlang.io

I don't see any problem of hosting it there, after all, the content never changes.
There hasn't been much interest in it so far, so I doubt that moving things will make this any better.