On Thursday, July 4, 2019 6:48:15 AM MDT Robert M. Münch via Digitalmars-d- announce wrote:
> On 2019-07-04 10:11:18 +0000, Mike Franklin said:
> > I don't know what digger is doing, but from the error messages, it appears that the new files in `rt/array` can't be found.  I believe the build is trying to use a new compiler with an older or existing runtime.  You'll need both the latest compiler and the latest runtime together for them to work.
> >
> > If you can identify a bug in the makefiles, or some other such problem preventing the build, let me know and I'll try to fix it right away.
>
> So, the problem is, that digger somehow misses to copy over the new source to the install directory. It does for some parts (phobos, but I'm not sure if for every file necessary) but not for druntime files.
>
> I just manually copied the files now.

Yeah. I ran into the same problem with my own build tool. There wasn't previously an rt folder in the imports. It was all hidden in the implementation, and my build tool didn't copy it over, resulting in confusing errors at first when druntime was recently changed to have an rt folder in the imports. I think that for druntime, it currently works to just copy over everything in the import folder, whereas with Phobos, you have to copy over specific directories (std and etc IIRC). So, for Phobos, you can't just grab everything from a single folder, and it may have been the case with druntime at one point that you couldn't either (I'm not sure). So, it doesn't really surprise me that digger broke. Any time that a tool is having to duplicate any logic from the build system (even if it's just which files to grab to install rather than for the build itself), it risks breaking any time that the build system is altered.

- Jonathan M Davis

On Thursday, 4 July 2019 at 09:13:39 UTC, Martin Tschierschke wrote:
> On Thursday, 4 July 2019 at 08:47:03 UTC, Martin Tschierschke wrote:
>
> I just looked at this again: http://erdani.com/d/downloads.daily.png
> and it should be a great reward to see how adoption of D increases in the long run.
>
> mt.

Just repeating something already noted by Andrei about that graph ... It is only direct downloads, it doesn't count Linux distribution installs - atleast Gentoo has structured & fairly up-to-date packages, allowing to switch seamlessly between DMD, GDC & LDC; Debian/Ubuntu/Devuan probably have it too, Arch Linux too?

The influx is likely bigger than that graph suggests :-)

Another stat that might make sense to people who have the history of that stat, is views of videos in the foundation's channel and in the Dconf channels on YouTube.

On Thursday, 4 July 2019 at 08:11:26 UTC, Martin Nowak wrote:
> Glad to announce D 2.087.0, ♥ to the 63 contributors.
>
> This release comes with types matching single template alias parameters, nested template methods/local template functions, multi-threaded GC marking, and a phobos compiled with -preview=DIP1000.
>
> http://dlang.org/download.html http://dlang.org/changelog/2.087.0.html
>
> -Martin

The blog announcement:

https://dlang.org/blog/2019/07/05/dmd-2-087-0-released/

And on reddit:

https://www.reddit.com/r/programming/comments/c9g5pg/d_20870_released/

After updating compiler to 2.087 I got a lot of deprecation warnings linked to std.json module. I have found all of the usages of deprecated symbols in my project and changed them to the new ones. All these warnings are about changing
JSON_TYPE to JSONType
JSON_TYPE.STRING to JSONType.string
and etc...
But after eleminating deprecated symbols from my project I still have deprecation warnings. Seems that these symbols being accessed from Phobos, because I am pretty sure that I don't have other external dependencies that use std.json. The problem it that because of this `spamming` messages I can miss `real` deprecation warnings. Is there some way to `fix` it? The is some part of compiler output (all of it is too long):
/usr/include/dmd/phobos/std/conv.d(987,34): Deprecation: enum member `std.json.JSONType.INTEGER` is deprecated - Use .integer
/usr/include/dmd/phobos/std/conv.d(987,34): Deprecation: enum member `std.json.JSONType.INTEGER` is deprecated - Use .integer
/usr/include/dmd/phobos/std/conv.d(987,34): Deprecation: enum member `std.json.JSONType.UINTEGER` is deprecated - Use .uinteger
/usr/include/dmd/phobos/std/conv.d(987,34): Deprecation: enum member `std.json.JSONType.UINTEGER` is deprecated - Use .uinteger
/usr/include/dmd/phobos/std/conv.d(987,34): Deprecation: enum member `std.json.JSONType.FLOAT` is deprecated - Use .float_
/usr/include/dmd/phobos/std/conv.d(987,34): Deprecation: enum member `std.json.JSONType.FLOAT` is deprecated - Use .float_
/usr/include/dmd/phobos/std/conv.d(987,34): Deprecation: enum member `std.json.JSONType.ARRAY` is deprecated - Use .array
/usr/include/dmd/phobos/std/conv.d(987,34): Deprecation: enum member `std.json.JSONType.ARRAY` is deprecated - Use .array
/usr/include/dmd/phobos/std/conv.d(987,34): Deprecation: enum member `std.json.JSONType.OBJECT` is deprecated - Use .object
/usr/include/dmd/phobos/std/conv.d(987,34): Deprecation: enum member `std.json.JSONType.OBJECT` is deprecated - Use .object
/usr/include/dmd/phobos/std/format.d(4373,24): Deprecation: enum member `std.json.JSONType.NULL` is deprecated - Use .null_
/usr/include/dmd/phobos/std/format.d(4373,24): Deprecation: enum member `std.json.JSONType.NULL` is deprecated - Use .null_
/usr/include/dmd/phobos/std/format.d(4373,24): Deprecation: enum member `std.json.JSONType.STRING` is deprecated - Use .string
/usr/include/dmd/phobos/std/format.d(4373,24): Deprecation: enum member `std.json.JSONType.STRING` is deprecated - Use .string
/usr/include/dmd/phobos/std/format.d(4373,24): Deprecation: enum member `std.json.JSONType.INTEGER` is deprecated - Use .integer
/usr/include/dmd/phobos/std/format.d(4373,24): Deprecation: enum member `std.json.JSONType.INTEGER` is deprecated - Use .integer
/usr/include/dmd/phobos/std/format.d(4373,24): Deprecation: enum member `std.json.JSONType.UINTEGER` is deprecated - Use .uinteger
/usr/include/dmd/phobos/std/format.d(4373,24): Deprecation: enum member `std.json.JSONType.UINTEGER` is deprecated - Use .uinteger
/usr/include/dmd/phobos/std/format.d(4373,24): Deprecation: enum member `std.json.JSONType.FLOAT` is deprecated - Use .float_
/usr/include/dmd/phobos/std/format.d(4373,24): Deprecation: enum member `std.json.JSONType.FLOAT` is deprecated - Use .float_
/usr/include/dmd/phobos/std/format.d(4373,24): Deprecation: enum member `std.json.JSONType.ARRAY` is deprecated - Use .array
/usr/include/dmd/phobos/std/format.d(4373,24): Deprecation: enum member `std.json.JSONType.ARRAY` is deprecated - Use .array
/usr/include/dmd/phobos/std/format.d(4373,24): Deprecation: enum member `std.json.JSONType.OBJECT` is deprecated - Use .object
/usr/include/dmd/phobos/std/format.d(4373,24): Deprecation: enum member `std.json.JSONType.OBJECT` is deprecated - Use .object

Am Sun, 07 Jul 2019 08:06:57 +0000 schrieb uranuz:

> After updating compiler to 2.087 I got a lot of deprecation warnings
> linked to std.json module. I have found all of the usages of deprecated
> symbols in my project and changed them to the new ones. All these
> warnings are about changing JSON_TYPE to JSONType JSON_TYPE.STRING to
> JSONType.string and etc...
> But after eleminating deprecated symbols from my project I still have
> deprecation warnings. Seems that these symbols being accessed from
> Phobos, because I am pretty sure that I don't have other external
> dependencies that use std.json. The problem it that because of this
> `spamming` messages I can miss `real` deprecation warnings. Is there
> some way to `fix` it? The is some part of compiler output (all of it is
> too long): /usr/include/dmd/phobos/std/conv.d(987,34): Deprecation: enum
> member `std.json.JSONType.INTEGER` is deprecated - Use .integer
> /usr/include/dmd/phobos/std/conv.d(987,34): Deprecation: enum member


I think phobos does not explicitly use these deprecated symbols, but the reflection code in format triggers the deprecation messages:

import std.json, std.stdio;
void main()
{
    JSONType c;
    writefln("%s", c);
}

I'm not sure if this can be solved, maybe deprecated members can be explicitly ignored in format, but maybe the reflection code itself is triggering the deprecation (which would then probably be a DMD bug).

-- 
Johannes

On Sunday, 7 July 2019 at 10:09:50 UTC, Johannes Pfau wrote:
> Am Sun, 07 Jul 2019 08:06:57 +0000 schrieb uranuz:
>
>> After updating compiler to 2.087 I got a lot of deprecation warnings
>> linked to std.json module. I have found all of the usages of deprecated
>> symbols in my project and changed them to the new ones. All these
>> warnings are about changing JSON_TYPE to JSONType JSON_TYPE.STRING to
>> JSONType.string and etc...
>> But after eleminating deprecated symbols from my project I still have
>> deprecation warnings. Seems that these symbols being accessed from
>> Phobos, because I am pretty sure that I don't have other external
>> dependencies that use std.json. The problem it that because of this
>> `spamming` messages I can miss `real` deprecation warnings. Is there
>> some way to `fix` it? The is some part of compiler output (all of it is
>> too long): /usr/include/dmd/phobos/std/conv.d(987,34): Deprecation: enum
>> member `std.json.JSONType.INTEGER` is deprecated - Use .integer
>> /usr/include/dmd/phobos/std/conv.d(987,34): Deprecation: enum member
>
>
> I think phobos does not explicitly use these deprecated symbols, but the reflection code in format triggers the deprecation messages:
>
> import std.json, std.stdio;
> void main()
> {
>     JSONType c;
>     writefln("%s", c);
> }
>
> I'm not sure if this can be solved, maybe deprecated members can be explicitly ignored in format, but maybe the reflection code itself is triggering the deprecation (which would then probably be a DMD bug).

Yes. It looks like it, because seems that `format` and `conv` use the same approach to convert data to string and in process of iterating reflection code `touches` deprecated symbols and it `starts to smell`... Maybe some special `compilation context` should exists where these deprecation warnings are ignored or ignore them when we access or iterate symbols using __trait(...)

Should I file a bugreport?

On Thursday, 4 July 2019 at 12:57:43 UTC, Mike Franklin wrote:
> The copy should take place when building druntime from the makefiles.  The files to be copied are listed at https://github.com/dlang/druntime/blob/12bcb73da97a0c26aaf4b943eabd3c25051a89da/mak/COPY#L405-L408 and, for Windows, should be copied https://github.com/dlang/druntime/blob/12bcb73da97a0c26aaf4b943eabd3c25051a89da/mak/WINDOWS#L1187-L1197 is executed.  But, I don't know if that happens or not with digger.

Why have these declarations been placed in the "rt" package, and not in "core.internal"?

The "rt" package has historically always been for the Druntime implementation part which is not importable from D programs. I think "core.internal" would have been more suitable.

On Friday, 5 July 2019 at 03:47:20 UTC, Jonathan M Davis wrote:
> Yeah. I ran into the same problem with my own build tool. There wasn't previously an rt folder in the imports. It was all hidden in the implementation, and my build tool didn't copy it over, resulting in confusing errors at first when druntime was recently changed to have an rt folder in the imports. I think that for druntime, it currently works to just copy over everything in the import folder, whereas with Phobos, you have to copy over specific directories (std and etc IIRC). So, for Phobos, you can't just grab everything from a single folder, and it may have been the case with druntime at one point that you couldn't either (I'm not sure). So, it doesn't really surprise me that digger broke. Any time that a tool is having to duplicate any logic from the build system (even if it's just which files to grab to install rather than for the build itself), it risks breaking any time that the build system is altered.

Digger has a good reason and a not-so-good reason to avoid using the included build system logic.

The good reason is that Digger attempts to support building a range of D versions as large as possible on modern systems. Sometimes, that means patching or entirely avoiding parts of the build system included with the D source code. However, this was not the case in this situation.

The not-so-good reason, and the root issue here, is the "digger install" functionality, which attempts to merge an existing "standard" D installation with one built by Digger. At the time I implemented it, we didn't have a good well-defined process of building release archives (rather, it was the duty of the release manager at the time to get it right), so, there was no way for Digger to know how to correctly build a complete D distribution including all the extra files which are not versioned, but nevertheless included in the archives; "digger install" was thus created as a work-around for that situation. This Digger feature has a hard-coded list of objects it needs to patch / update, which as you can guess did not include the "rt" package from Druntime.

On Monday, 15 July 2019 at 10:52:08 UTC, Vladimir Panteleev wrote:
> On Thursday, 4 July 2019 at 12:57:43 UTC, Mike Franklin wrote:
>> The copy should take place when building druntime from the makefiles.  The files to be copied are listed at https://github.com/dlang/druntime/blob/12bcb73da97a0c26aaf4b943eabd3c25051a89da/mak/COPY#L405-L408 and, for Windows, should be copied https://github.com/dlang/druntime/blob/12bcb73da97a0c26aaf4b943eabd3c25051a89da/mak/WINDOWS#L1187-L1197 is executed.  But, I don't know if that happens or not with digger.
>
> Why have these declarations been placed in the "rt" package, and not in "core.internal"?
>
> The "rt" package has historically always been for the Druntime implementation part which is not importable from D programs. I think "core.internal" would have been more suitable.

I discussed that briefly on Slack with a couple other developers.  My understanding is the `rt` is the language implementation and `core` is the low level library for users.

The code in `rt/array` are language implementations.  They are not to be imported by the user.  They are, however, required by the language to implement D's built-in arrays, so that is why they are publicly imported in object.d.

Mike