www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Release D 2.085.0

reply Martin Nowak <code+news.digitalmars dawg.eu> writes:
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
Mar 02 2019
next sibling parent reply Cym13 <cpicard openmailbox.org> writes:
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
In the -preview/-revert it is said: As of now, DMD offers these reverts: -preview=dip25: Reverts DIP25 changes -revert=import: Revert to single phase name lookup Shouldn't that be "-revert=dip25" instead of -preview there?
Mar 02 2019
parent Seb <seb wilzba.ch> writes:
On Saturday, 2 March 2019 at 19:37:08 UTC, Cym13 wrote:
 On Saturday, 2 March 2019 at 18:19:37 UTC, Martin Nowak wrote:
 [...]
In the -preview/-revert it is said: As of now, DMD offers these reverts: -preview=dip25: Reverts DIP25 changes -revert=import: Revert to single phase name lookup Shouldn't that be "-revert=dip25" instead of -preview there?
Thanks! -> https://github.com/dlang/dlang.org/pull/2596
Mar 02 2019
prev sibling next sibling parent reply Basile B. <b2.temp gmx.com> writes:
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
GoodBye Darwin 32. I wonder if the issues specific to this platform should be all closed as WONTFIX or left as is (example : https://issues.dlang.org/show_bug.cgi?id=13457)
Mar 02 2019
parent Jacob Carlborg <doob me.com> writes:
On 2019-03-02 20:44, Basile B. wrote:

 GoodBye Darwin 32.
 
 I wonder if the issues specific to this platform should be all closed as 
 WONTFIX or left as is (example : 
 https://issues.dlang.org/show_bug.cgi?id=13457)
I think Walter has mentioned in the past that bugs like this might be an actual problem and could surface on other platforms as well. -- /Jacob Carlborg
Mar 03 2019
prev sibling next sibling parent evilrat <evilrat666 gmail.com> writes:
On Saturday, 2 March 2019 at 18:19:37 UTC, Martin Nowak wrote:
 Glad to announce D 2.085.0, ♥ to the 49 contributors.
Oh no! Windows installer is not signed, again.
Mar 02 2019
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2019-03-02 19:19, 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).
I highly recommend that anyone that wants to start using the new Objective-C features to wait until the point release. -- /Jacob Carlborg
Mar 03 2019
prev sibling next sibling parent reply aliak <something something.com> writes:
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?
Mar 03 2019
parent reply Andre Pany <andre s-e-a-p.de> writes:
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
Mar 03 2019
parent aliak <something something.com> writes:
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.
Mar 04 2019
prev sibling next sibling parent reply Manu <turkeyman gmail.com> writes:
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
Mar 03 2019
parent Radu <void null.pt> writes:
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.
Mar 04 2019
prev sibling parent reply Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
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?
Mar 03 2019
next sibling parent Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
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
Mar 03 2019
prev sibling parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
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.
Mar 03 2019
parent Per =?UTF-8?B?Tm9yZGzDtnc=?= <per.nordlow gmail.com> writes:
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.
Mar 04 2019