On Saturday, 2 March 2019 at 18:19:37 UTC, Martin Nowak wrote:
> Glad to announce D 2.085.0, ♥ to the 49 contributors.
>
> This release comes with context-aware assertion messages, lower GC memory usage, a precise GC, support to link custom GCs, lots of Objective-C improvements¹, and toolchainRequirements for dub. This release also ended official support for OSX-32.
>
> http://dlang.org/download.html http://dlang.org/changelog/2.085.0.html
>
> ¹: There is a pending Objective-C fix
> (https://github.com/dlang/dmd/pull/9402) that slipped 2.085.0 but will
> be released with 2.085.1 soon (~1.5 weeks).
>
> -Martin

Thanks!

It would be even greater if the GC could automatically do

   -DRT-gcopt=cleanup:none

automatically for all the GC-allocations of aggregate types that don't have a destructor (hasElaborateDestructor being true for structs and classes).

Would that be possible to implement?

I presume that would require segregating the heap even further, right?

On Sunday, 3 March 2019 at 21:51:30 UTC, Per Nordlöw wrote:
> that don't have a destructor (hasElaborateDestructor being true

Correction:

> that don't have a destructor (hasElaborateDestructor being FALSE

On 03/03/2019 22:51, Per Nordlöw wrote:
> On Saturday, 2 March 2019 at 18:19:37 UTC, Martin Nowak wrote:
>> Glad to announce D 2.085.0, ♥ to the 49 contributors.
>>
>> This release comes with context-aware assertion messages, lower GC memory usage, a precise GC, support to link custom GCs, lots of Objective-C improvements¹, and toolchainRequirements for dub. This release also ended official support for OSX-32.
>>
>> http://dlang.org/download.html http://dlang.org/changelog/2.085.0.html
>>
>> ¹: There is a pending Objective-C fix
>> (https://github.com/dlang/dmd/pull/9402) that slipped 2.085.0 but will
>> be released with 2.085.1 soon (~1.5 weeks).
>>
>> -Martin
> 
> Thanks!
> 
> It would be even greater if the GC could automatically do
> 
>    -DRT-gcopt=cleanup:none
> 
> automatically for all the GC-allocations of aggregate types that don't have a destructor (hasElaborateDestructor being true for structs and classes).
> 
> Would that be possible to implement?
> 
> I presume that would require segregating the heap even further, right?

These objects would still have to be scanned, so there is not much that could be saved with respect to performance.

BTW: DRT options have a double-dash at the start, e.g.

--DRT-gcopt=cleanup:none

This should be corrected in the blog post, too.

On Sunday, 3 March 2019 at 17:44:21 UTC, Andre Pany wrote:
> On Sunday, 3 March 2019 at 14:01:03 UTC, aliak wrote:
>> On Saturday, 2 March 2019 at 18:19:37 UTC, Martin Nowak wrote:
>>> Glad to announce D 2.085.0, ♥ to the 49 contributors.
>>>
>>> This release comes with context-aware assertion messages, lower GC memory usage, a precise GC, support to link custom GCs, lots of Objective-C improvements¹, and toolchainRequirements for dub. This release also ended official support for OSX-32.
>>>
>>> http://dlang.org/download.html http://dlang.org/changelog/2.085.0.html
>>>
>>> ¹: There is a pending Objective-C fix
>>> (https://github.com/dlang/dmd/pull/9402) that slipped 2.085.0 but will
>>> be released with 2.085.1 soon (~1.5 weeks).
>>>
>>> -Martin
>>
>> I'm not sure what's happening here but with 2.085.0 I'm getting linking errors all of a sudden. Could it be dub?
>>
>> To reproduce, init a new dub project, add dependency on "ddash" and use this main:
>>
>> import std.stdio;
>>
>> void main() {
>> 	import ddash: stringifySeperatedBy;
>> 	writeln([1, 2, 3].stringifySeperatedBy("."));
>> }
>>
>> Linking results in:
>>
>> Linking...
>> Undefined symbols for architecture x86_64:
>>   "__D5ddash12__ModuleInfoZ", referenced from:
>>       __D3app12__ModuleInfoZ in blah.o
>> ld: symbol(s) not found for architecture x86_64
>> clang: error: linker command failed with exit code 1 (use -v to see invocation)
>>
>>
>> When I set compiler back to 2.084.1 then:
>>
>> Linking...
>> To force a rebuild of up-to-date targets, run again with --force.
>> Running ./blah
>> 1.2.3
>>
>> Any ideas?
>
> After upgrading DMD in most cases I have to either delete the cached dub packages in the user directory or execute dub with the --force argument to rebuild all dependent dub packages.
> In theory dub should be able to recognize a changed compiler version and automatically rebuild all dependencies but I do not know how hard it would be to implement this.
>
> Kind regards
> Andre

Thanks for the tip, but it was on deployment on clean machines so everything is downloaded from scratch. No caches as far as i could tell. Double checked on my machine as well and still the same.

I did however notice that it also works on 2.085.0 if i import it a different way:

i.e. this works:

void main() {
 	import ddash.functional: stringifySeperatedBy; // difference is in import statement
 	writeln([1, 2, 3].stringifySeperatedBy("."));
}

So I guess maybe dub is off somewhere, or something which shouldn't have been working was.

On Monday, 4 March 2019 at 07:58:09 UTC, Rainer Schuetze wrote:
> These objects would still have to be scanned, so there is not much that could be saved with respect to performance.

Ok, thanks.

On Sunday, 3 March 2019 at 18:31:41 UTC, Manu wrote:
> On Sat, Mar 2, 2019 at 10:25 AM Martin Nowak via Digitalmars-d-announce <digitalmars-d-announce@puremagic.com> wrote:
>>
>> Glad to announce D 2.085.0, ♥ to the 49 contributors.
>>
>> This release comes with context-aware assertion messages, lower GC memory usage, a precise GC, support to link custom GCs, lots of Objective-C improvements¹, and toolchainRequirements for dub. This release also ended official support for OSX-32.
>>
>> http://dlang.org/download.html http://dlang.org/changelog/2.085.0.html
>>
>> ¹: There is a pending Objective-C fix
>> (https://github.com/dlang/dmd/pull/9402) that slipped 2.085.0 but will
>> be released with 2.085.1 soon (~1.5 weeks).
>>
>> -Martin
>
> The windows installer is not signed?
> Did something happen? O_o

https://issues.dlang.org/show_bug.cgi?id=19670

Was supposed to be fixed in this release.