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