www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Release D 2.078.0

reply Martin Nowak <code+news.digitalmars dawg.eu> writes:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Glad to announce D 2.078.0.

This release comes with runtime detection of Visual Studio
installation paths, an integral promotion transition for unary
operations on byte and short sized integers, more -betterC features,
and a couple of language and library tweaks.

Thanks to everyone involved in this 👏
https://dlang.org/contributors.html.

http://downloads.dlang.org/releases/2.x/2.078.0/
http://dlang.org/changelog/2.078.0.html

- -Martin
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEpzRNrTw0HqEtE8TmsnOBFhK7GTkFAlpNFkMACgkQsnOBFhK7
GTmMFA/+ItXVmhkrsIMgJxbfZrLh3UqDNxC0gH+s/x8HQ9h+dWlAzueimjPY5+5W
kXQ/LzPbN7KS3Cm5N8x22gTU4Ldwow2ObHW+GNLq/3Id45xn1KFvM5FVr8pNXIA+
po17ZykzXHPOwh4jpHv+5sa4d6ldcW41RKMlzqXOCoIEvo6qxbJsSiG/2IWR2zzk
cMMzFpzxBX7eixtbDj/WFhE1Ou+6MSXrZ8E94DfnBeJfXed5dPt6RTOTa1va+R+4
XdDSFd85qIAxRBM6aPXudNdh1RWVwolFONJMarUO+fSU1lebkSbLVTEpYoBTbZid
fZrxeGB35dpA7RqZqlkv90VBzoamujzAn1GO7on1Qar6GI2YGmWtLGg3WjOLp5s7
d6O/VbJx7R8RCmeIBfAhqGUhuTNx1a6H3G7n3mztYEj8h5Y7uI9nCx1hXqgUIVwt
7VpiuLibdnZ35R7sV9GA9CMjb9o4OdvbBlAKFgPDyLTgKSI5Pr9RpWCIVqwErlyO
jCnrRc7JTueVEjjCPxdaYn2CQH9KmsgpqDZ+FaHHR//Uyu72vrbsoavPVV8MA6+0
iCoLZnH5u7eI2sFjxqe73LliaqrPNXMt2YTAyRAEvNXjULuSfZoDtcqLba1QnePP
i1y1EAZa9Wvv/8nIErrB3mjJwtHowBNMR4AE53BSPJmH5HDbuSE=
=1oyf
-----END PGP SIGNATURE-----
Jan 03 2018
next sibling parent Basile B. <b2.temp gmx.com> writes:
On Wednesday, 3 January 2018 at 17:43:36 UTC, Martin Nowak wrote:
 Glad to announce D 2.078.0.

 This release comes with runtime detection of Visual Studio 
 installation paths, an integral promotion transition for unary 
 operations on byte and short sized integers, more -betterC 
 features, and a couple of language and library tweaks.

 Thanks to everyone involved in this 👏 
 https://dlang.org/contributors.html.

 http://downloads.dlang.org/releases/2.x/2.078.0/ 
 http://dlang.org/changelog/2.078.0.html

 - -Martin
thanks buddies.
Jan 03 2018
prev sibling next sibling parent Seb <seb wilzba.ch> writes:
On Wednesday, 3 January 2018 at 17:43:36 UTC, Martin Nowak wrote:
 Glad to announce D 2.078.0.

 This release comes with runtime detection of Visual Studio 
 installation paths, an integral promotion transition for unary 
 operations on byte and short sized integers, more -betterC 
 features, and a couple of language and library tweaks.

 Thanks to everyone involved in this 👏 
 https://dlang.org/contributors.html.

 http://downloads.dlang.org/releases/2.x/2.078.0/ 
 http://dlang.org/changelog/2.078.0.html

 - -Martin
Thanks a lot Martin!! BTW we have per-release contributor listings too: https://github.com/dlang/dlang.org/pull/2048
Jan 03 2018
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Jan 03, 2018 at 06:43:36PM +0100, Martin Nowak via
Digitalmars-d-announce wrote:
 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA512
 
 Glad to announce D 2.078.0.
Awesome! [...]
 https://dlang.org/contributors.html.
[...] Not sure where's the best place to report this, but this list contains some duplicates. One that I found is "Mihails Strasuns" == "Михаил Страшун". Does the contributor script have some mechanism for specifying equivalence classes for the various online identities of contributors? T -- In theory, software is implemented according to the design that has been carefully worked out beforehand. In practice, design documents are written after the fact to describe the sorry mess that has gone on before.
Jan 03 2018
parent Seb <seb wilzba.ch> writes:
On Wednesday, 3 January 2018 at 19:40:17 UTC, H. S. Teoh wrote:
 On Wed, Jan 03, 2018 at 06:43:36PM +0100, Martin Nowak via 
 Digitalmars-d-announce wrote:
 -----BEGIN PGP SIGNED MESSAGE-----
 Hash: SHA512
 
 Glad to announce D 2.078.0.
Awesome! [...]
 https://dlang.org/contributors.html.
[...] Not sure where's the best place to report this, but this list contains some duplicates. One that I found is "Mihails Strasuns" == "Михаил Страшун". Does the contributor script have some mechanism for specifying equivalence classes for the various online identities of contributors? T
Yes, it's a git mailmap: https://github.com/dlang/tools/blob/master/.mailmap See also: https://github.com/git/git/blob/master/Documentation/mailmap.txt Improvements are welcome :)
Jan 03 2018
prev sibling next sibling parent reply Mike Parker <aldacron gmail.com> writes:
On Wednesday, 3 January 2018 at 17:43:36 UTC, Martin Nowak wrote:
 Glad to announce D 2.078.0.

 This release comes with runtime detection of Visual Studio 
 installation paths, an integral promotion transition for unary 
 operations on byte and short sized integers, more -betterC 
 features, and a couple of language and library tweaks.

 Thanks to everyone involved in this 👏 
 https://dlang.org/contributors.html.

 http://downloads.dlang.org/releases/2.x/2.078.0/ 
 http://dlang.org/changelog/2.078.0.html

 - -Martin
Awesome! I'll post the blog announcement and hit social media in ~12 hours.
Jan 03 2018
parent reply Mike Parker <aldacron gmail.com> writes:
On Thursday, 4 January 2018 at 02:27:13 UTC, Mike Parker wrote:

 Awesome! I'll post the blog announcement and hit social media 
 in ~12 hours.
Blog: https://dlang.org/blog/2018/01/04/dmd-2-078-0-has-been-released/ Reddit: https://www.reddit.com/r/programming/comments/7o2tcw/dmd_20780_has_been_released/
Jan 04 2018
next sibling parent reply Joakim <dlang joakim.fea.st> writes:
On Thursday, 4 January 2018 at 13:03:21 UTC, Mike Parker wrote:
 On Thursday, 4 January 2018 at 02:27:13 UTC, Mike Parker wrote:

 Awesome! I'll post the blog announcement and hit social media 
 in ~12 hours.
Blog: https://dlang.org/blog/2018/01/04/dmd-2-078-0-has-been-released/ Reddit: https://www.reddit.com/r/programming/comments/7o2tcw/dmd_20780_has_been_released/
Nice post, good explanations and code samples. Here's some phrases I'd change: quality of life -> quality-of-life stubbed out -> stubbed-out line, or an alternative -> line or an alternate D runtime dependent -> that depends DMD 2.80.0 -> DMD 2.080.0
Jan 04 2018
parent Mike Parker <aldacron gmail.com> writes:
On Thursday, 4 January 2018 at 15:22:03 UTC, Joakim wrote:

 Nice post, good explanations and code samples.  Here's some 
 phrases I'd change:

 quality of life -> quality-of-life
 stubbed out -> stubbed-out
 line, or an alternative -> line or an alternate D runtime
 dependent -> that depends
 DMD 2.80.0 -> DMD 2.080.0
Thanks!
Jan 04 2018
prev sibling next sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Thursday, 4 January 2018 at 13:03:21 UTC, Mike Parker wrote:
 Blog:
 https://dlang.org/blog/2018/01/04/dmd-2-078-0-has-been-released/

 Reddit:
 https://www.reddit.com/r/programming/comments/7o2tcw/dmd_20780_has_been_released/
I've been really liking the blog write-ups on the new releases. On a related note, the vision document for 2018H1 has not yet been created.
Jan 04 2018
parent reply Mike Parker <aldacron gmail.com> writes:
On Thursday, 4 January 2018 at 15:51:55 UTC, jmh530 wrote:

 I've been really liking the blog write-ups on the new releases.
Thanks!
 On a related note, the vision document for 2018H1 has not yet 
 been created.
It's a WIP.
Jan 04 2018
parent Jack Stouffer <jack jackstouffer.com> writes:
On Thursday, 4 January 2018 at 15:53:33 UTC, Mike Parker wrote:
 On a related note, the vision document for 2018H1 has not yet 
 been created.
It's a WIP.
If I may make a suggestion, please make the vision documents smaller and more focused. The goals laid out are typically far too broad to actually accomplish in half a year. Instead, the document should give detailed milestones for two or three long term goals which the community should complete in the six months. E.g.
  safety: we aim to enable large-scale uses of D with safety 
 guarantees
and
Static introspection: We believe this is an important strategic 
advantage of D and we should continue to improve both compiler 
support and library support.
These are not actionable and can't be achieved in just six months of work. Instead, something like
 To move toward a  safe Phobos, std.json, std.file, and 
 std.stdio should all be 100%  safe by June.
Static introspection: we believe this is an important strategic 
advantage of D, so X, Y, and Z feature should be added by June
gives contributors goals they can start making PRs for.
Jan 04 2018
prev sibling parent reply David Nadlinger <code klickverbot.at> writes:
On Thursday, 4 January 2018 at 13:03:21 UTC, Mike Parker wrote:
 https://dlang.org/blog/2018/01/04/dmd-2-078-0-has-been-released/
 In normal D code, struct destructors are executed when an 
 instance goes out of scope. This is handled by DRuntime, […]
This is slightly inaccurate. Regular stack cleanup doesn't involve the runtime at all; druntime only comes into play for exception handling. Since destructors also need to be run when the scope is left by an exception, they are implemented via `try {} finally {}` internally. The EH part of these depends on druntime, but not the regular path.
 One of the seemingly obscure features dependent upon DRuntime 
 is the ModuleInfo type. It’s a type that works quietly behind 
 the scenes as one of the enabling mechanisms of reflection and 
 most D programmers will likely never hear of it.
This is somewhat confusingly worded as well. It's actually mostly the other way around – druntime depends on ModuleInfo to be emitted, crucially for static constructor, destructors and unit tests to be run. At least without shared libraries in the picture, it would be fairly easy to manually look up the set of ModuleInfos in a druntime-less D program. — David
Jan 04 2018
next sibling parent Mike Parker <aldacron gmail.com> writes:
On Thursday, 4 January 2018 at 17:40:55 UTC, David Nadlinger 
wrote:

 This is slightly inaccurate. Regular stack cleanup doesn't 
 involve the runtime at all; druntime only comes into play for 
 exception handling. Since destructors also need to be run when 
 the scope is left by an exception, they are implemented via 
 `try {} finally {}` internally. The EH part of these depends on 
 druntime, but not the regular path.



 This is somewhat confusingly worded as well. It's actually 
 mostly the other way around – druntime depends on ModuleInfo to 
 be emitted, crucially for static constructor, destructors and 
 unit tests to be run. At least without shared libraries in the 
 picture, it would be fairly easy to manually look up the set of 
 ModuleInfos in a druntime-less D program.

  — David
Thanks, David!
Jan 05 2018
prev sibling parent Mike Franklin <slavo5150 yahoo.com> writes:
On Thursday, 4 January 2018 at 17:40:55 UTC, David Nadlinger 
wrote:

 it would be fairly easy to manually look up the set of 
 ModuleInfos in a druntime-less D program.
ModuleInfo is declared and defined in druntime (https://github.com/dlang/druntime/blob/7bfaa8c0755771b807a8344b8c0bfcf73aec7c82/ rc/object.d#L1443). If one is doing a druntime-less build, how would it be possible have a set of `ModuleInfo`s to manually look up? Mike
Jan 05 2018
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 1/3/2018 9:43 AM, Martin Nowak wrote:
 Glad to announce D 2.078.0.
Thank you, Martin!
Jan 03 2018
prev sibling next sibling parent reply thedeemon <dlang thedeemon.com> writes:
On Wednesday, 3 January 2018 at 17:43:36 UTC, Martin Nowak wrote:
 Glad to announce D 2.078.0.

 This release comes with runtime detection of Visual Studio 
 installation paths
I've got a problem with linking phobos64.lib now. I run "Visual C++ 2015 x64 Native Build Tools Command Prompt", i.e. cmd.exe with environment set up. With dmd 2.077.0 I run "dmd app.d -m64 -ofapp.exe" and it all goes well, compiles and links successfully. With dmd 2.078.0 I run "dmd app.d -m64 -ofapp.exe" and get: phobos64.lib(stacktrace_196a_3e5.obj) : error LNK2019: unresolved external symbol snprintf referenced in function _D4core3sys7windows10stacktrace10StackTrace13resolveNoSyncFAxmZAAa phobos64.lib(parseoptions_bee_21b.obj) : error LNK2001: unresolved external symbol snprintf phobos64.lib(demangle_ab0_79b.obj) : error LNK2001: unresolved external symbol snprintf phobos64.lib(parseoptions_bee_21b.obj) : error LNK2019: unresolved external symbol sscanf referenced in function _D4core8internal12parseoptions5parseFNbNiAxaKANgaKfQkZb app.exe : fatal error LNK1120: 2 unresolved externals Error: linker exited with status 1120
Jan 03 2018
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 04.01.2018 07:25, thedeemon wrote:
 On Wednesday, 3 January 2018 at 17:43:36 UTC, Martin Nowak wrote:
 Glad to announce D 2.078.0.

 This release comes with runtime detection of Visual Studio 
 installation paths
I've got a problem with linking phobos64.lib now. I run "Visual C++ 2015 x64 Native Build Tools Command Prompt", i.e. cmd.exe with environment set up. With dmd 2.077.0 I run "dmd app.d -m64 -ofapp.exe" and it all goes well, compiles and links successfully. With dmd 2.078.0 I run "dmd app.d -m64 -ofapp.exe" and get: phobos64.lib(stacktrace_196a_3e5.obj) : error LNK2019: unresolved external symbol snprintf referenced in function _D4core3sys7windows10stacktrace10StackTrace13resolveNoSyncFAxmZAAa phobos64.lib(parseoptions_bee_21b.obj) : error LNK2001: unresolved external symbol snprintf phobos64.lib(demangle_ab0_79b.obj) : error LNK2001: unresolved external symbol snprintf phobos64.lib(parseoptions_bee_21b.obj) : error LNK2019: unresolved external symbol sscanf referenced in function _D4core8internal12parseoptions5parseFNbNiAxaKANgaKfQkZb app.exe : fatal error LNK1120: 2 unresolved externals Error: linker exited with status 1120
What's missing is probably legacy_stdio_definition.lib that has to be added to the linker command line for VS2015 or later. You can verify this by checking how dmd invokes the linker by adding -v to the dmd command line. I suspect this happens due to the new VS detection in dmd that hasn't been followed up by an appropriate installer update (unfortunately it didn't make it into this release). Please try replacing the Environment64 section in sc.ini with just this: [Environment64] LIB=% P%\..\lib64 DFLAGS=%DFLAGS% -L/OPT:NOICF
Jan 04 2018
parent thedeemon <dlang thedeemon.com> writes:
On Thursday, 4 January 2018 at 08:15:50 UTC, Rainer Schuetze 
wrote:

 What's missing is probably legacy_stdio_definition.lib that has 
 to be added to the linker command line for VS2015 or later.
Yes, that is the case! Using -v flag I can see that dmd 2.077 invokes C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\\bin\link.exe /NOLOGO app /OUT:"app.exe" /OPT:NOICF /LIBPATH:"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\\lib\amd64" /LIBPATH:"C:\Program Files (x86)\Windows Kits\10\\lib\x64" /LIBPATH:"C:\Program Files (x86)\Windows Kits\10\\lib\10.0.10240.0\ucrt\x64" legacy_stdio_definitions.lib While the new 2.078 just C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\link.exe /NOLOGO app /OUT:"app.exe" /OPT:NOICF /LIBPATH:"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\lib\amd64" /LIBPATH:"C:\Program Files (x86)\Windows Kits\10\lib\10.0.10240.0\um\x64"
 Please try replacing the Environment64 section in sc.ini with 
 just this:

 [Environment64]
 LIB=% P%\..\lib64
 DFLAGS=%DFLAGS% -L/OPT:NOICF
I'm using the variant from 7z archive (not installer). Its sc.ini section already looks very much like this.
Jan 04 2018
prev sibling next sibling parent IM <3di gm.com> writes:
On Wednesday, 3 January 2018 at 17:43:36 UTC, Martin Nowak wrote:
 Glad to announce D 2.078.0.

 This release comes with runtime detection of Visual Studio 
 installation paths, an integral promotion transition for unary 
 operations on byte and short sized integers, more -betterC 
 features, and a couple of language and library tweaks.

 Thanks to everyone involved in this 👏 
 https://dlang.org/contributors.html.

 http://downloads.dlang.org/releases/2.x/2.078.0/ 
 http://dlang.org/changelog/2.078.0.html

 - -Martin
Thank you very much!
Jan 04 2018
prev sibling next sibling parent reply =?UTF-8?B?0JPQu9C10LEg0JrRg9C70LjQutC+0LIvR2xlYg==?= Kulikov <gleb asd.iao.ru> writes:
Martin Nowak wrote:


 
 Glad to announce D 2.078.0.
Hello and Happy New Year ! :) Unfortunally, linux x86_64 version(*) has problems: (*) from red hat rpm simplest test program: module main; import std.stdio; int main(string[] args) { writefln("Hello World\n"); return 0; } traps with follows reason: Program received signal SIGSEGV, Segmentation fault. 0x00007ffff7460299 in fwrite () from /lib64/libc.so.6 Fatal error: glibc detected an invalid stdio handle Аварийный останов (gdb) bt /usr/include/d/std/stdio.d:4064 writeme=...) at /usr/include/d/std/stdio.d:2775 /usr/include/d/std/range/primitives.d:269 /usr/include/d/std/range/primitives.d:358 /usr/include/d/std/format.d:1188 /usr/include/d/std/format.d:474 /usr/include/d/std/stdio.d:1496 /usr/include/d/std/stdio.d:3797 Thank you, yours sincerely and etc...
Jan 05 2018
next sibling parent rikki cattermole <rikki cattermole.co.nz> writes:
On 05/01/2018 2:30 PM, Глеб Куликов/Gleb Kulikov wrote:
 Martin Nowak wrote:
 
 
 Glad to announce D 2.078.0.
Hello and Happy New Year ! :) Unfortunally, linux x86_64 version(*) has problems: (*) from red hat rpm simplest test program: module main; import std.stdio; int main(string[] args) { writefln("Hello World\n"); return 0; } traps with follows reason: Program received signal SIGSEGV, Segmentation fault. 0x00007ffff7460299 in fwrite () from /lib64/libc.so.6 Fatal error: glibc detected an invalid stdio handle Аварийный останов (gdb) bt /usr/include/d/std/stdio.d:4064 writeme=...) at /usr/include/d/std/stdio.d:2775 /usr/include/d/std/range/primitives.d:269 /usr/include/d/std/range/primitives.d:358 /usr/include/d/std/format.d:1188 /usr/include/d/std/format.d:474 /usr/include/d/std/stdio.d:1496 /usr/include/d/std/stdio.d:3797 Thank you, yours sincerely and etc...
Please file an issue (so it doesn't get lost) thanks! http://issues.dlang.org
Jan 05 2018
prev sibling next sibling parent reply user789 <user789 789.fi> writes:
On Friday, 5 January 2018 at 14:30:13 UTC, Глеб Куликов/Gleb 
Kulikov wrote:
 Martin Nowak wrote:


 
 Glad to announce D 2.078.0.
Hello and Happy New Year ! :) Unfortunally, linux x86_64 version(*) has problems: (*) from red hat rpm
I also setup from the RH rpm and it works fine here, also in GDB. Can you reproduce it at each run ?
Jan 05 2018
parent reply gleb <gleb asd.iao.ru> writes:
user789 wrote:

 Unfortunally, linux x86_64 version(*) has problems:
I also setup from the RH rpm and it works fine here, also in GDB. Can you reproduce it at each run ?
Yes, it's fully reproducable in number of x86_64 systems: system "1",glibc-core-2.25-alt2.x86_64, AMD Athlon, kernel 4.9.56 system "2",glibc-core-2.25-alt3.x86_64, Core i5, kernel 4.9.56 system "3",glibc-core-2.25-alt3.x86_64, Core i7, kernel 4.9.42 system "4",glibc-core-2.25-alt3.x86_64 ,Xeon E5-2620, kernel 4.9.65 with the same behavior, so it is not installation -- dependent. all previous versions of dmd works good. ldc2 1.7.0-beta1 and older works ok as well. all another functionality, except of fwrite, seems to be ok. -- yours sincerely,...
Jan 05 2018
parent user789 <user789 789.fi> writes:
On Friday, 5 January 2018 at 15:30:39 UTC, gleb wrote:
 user789 wrote:

 Unfortunally, linux x86_64 version(*) has problems:
I also setup from the RH rpm and it works fine here, also in GDB. Can you reproduce it at each run ?
Yes, it's fully reproducable in number of x86_64 systems: system "1",glibc-core-2.25-alt2.x86_64, AMD Athlon, kernel 4.9.56 system "2",glibc-core-2.25-alt3.x86_64, Core i5, kernel 4.9.56 system "3",glibc-core-2.25-alt3.x86_64, Core i7, kernel 4.9.42 system "4",glibc-core-2.25-alt3.x86_64 ,Xeon E5-2620, kernel 4.9.65 with the same behavior, so it is not installation -- dependent. all previous versions of dmd works good. ldc2 1.7.0-beta1 and older works ok as well. all another functionality, except of fwrite, seems to be ok. -- yours sincerely,...
I've seen your report. kernel is at 4.14 and glibc is 2.26 here, although it's hard to say if this is the problem but your systems seem not to be updated since about a full year.
Jan 05 2018
prev sibling parent Martin Nowak <code+news.digitalmars dawg.eu> writes:
On 01/05/2018 03:30 PM, Глеб Куликов/Gleb Kulikov wrote:
 Martin Nowak wrote:
 
 
 Glad to announce D 2.078.0.
Hello and Happy New Year ! :) Unfortunally, linux x86_64 version(*) has problems:
Please file a bug report under https://issues.dlang.org/enter_bug.cgi and link to it from here. This is an announce forum, and soon this information is lost. Please make sure to list necessary information to reproduce this issue (e.g. cc --version; ld -v; uname -a; cat /etc/redhat-release). If it works in 2.077.1, it should be filed as regression and the bug title should start with [2.078]. -Martin
Jan 09 2018
prev sibling next sibling parent reply Andre Pany <andre s-e-a-p.de> writes:
On Wednesday, 3 January 2018 at 17:43:36 UTC, Martin Nowak wrote:
 Glad to announce D 2.078.0.

 This release comes with runtime detection of Visual Studio 
 installation paths, an integral promotion transition for unary 
 operations on byte and short sized integers, more -betterC 
 features, and a couple of language and library tweaks.

 Thanks to everyone involved in this 👏 
 https://dlang.org/contributors.html.

 http://downloads.dlang.org/releases/2.x/2.078.0/ 
 http://dlang.org/changelog/2.078.0.html

 - -Martin
It seems vs-auto-detection does not work with the Visual Studio 2017 Community version: I executed "vcvars64.bat". After that environment variable PATH contains following entries: C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.11.25503\bin\HostX64\x64; C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\VC\VCPackages; C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\CommonExtensions\Microsoft\TestWindow; C:\Program Files (x86)\Microsoft Visual ... dmd app.d -m64 Error: can't run 'C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\\bin\link.exe', check PATH I checked the location and link.exe is available in the very first element of PATH environment variable: C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.11.25503\bin\Hostx64\x64 Could you check? Kind regards André
Jan 07 2018
next sibling parent Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Monday, 8 January 2018 at 07:56:18 UTC, Andre Pany wrote:
 On Wednesday, 3 January 2018 at 17:43:36 UTC, Martin Nowak 
 wrote:
 Glad to announce D 2.078.0.

 This release comes with runtime detection of Visual Studio 
 installation paths, an integral promotion transition for unary 
 operations on byte and short sized integers, more -betterC 
 features, and a couple of language and library tweaks.

 Thanks to everyone involved in this 👏 
 https://dlang.org/contributors.html.

 http://downloads.dlang.org/releases/2.x/2.078.0/ 
 http://dlang.org/changelog/2.078.0.html

 - -Martin
It seems vs-auto-detection does not work with the Visual Studio 2017 Community version: I executed "vcvars64.bat". After that environment variable PATH contains following entries: C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.11.25503\bin\HostX64\x64; C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\VC\VCPackages; C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\CommonExtensions\Microsoft\TestWindow; C:\Program Files (x86)\Microsoft Visual ... dmd app.d -m64 Error: can't run 'C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\\bin\link.exe', check PATH
Note the double backslash, its getting confused.
Jan 08 2018
prev sibling parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 08.01.2018 08:56, Andre Pany wrote:
 On Wednesday, 3 January 2018 at 17:43:36 UTC, Martin Nowak wrote:
 Glad to announce D 2.078.0.

 This release comes with runtime detection of Visual Studio 
 installation paths, an integral promotion transition for unary 
 operations on byte and short sized integers, more -betterC features, 
 and a couple of language and library tweaks.

 Thanks to everyone involved in this 👏 
 https://dlang.org/contributors.html.

 http://downloads.dlang.org/releases/2.x/2.078.0/ 
 http://dlang.org/changelog/2.078.0.html

 - -Martin
It seems vs-auto-detection does not work with the Visual Studio 2017 Community version: I executed "vcvars64.bat". After that environment variable PATH contains following entries: C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.11.25503\bin\HostX64\x64; C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\VC\VCPackages; C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\CommonExtensions\Microsoft\TestWindow; C:\Program Files (x86)\Microsoft Visual ... dmd app.d -m64 Error: can't run 'C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\\bin\link.exe', check PATH I checked the location and link.exe is available in the very first element of PATH environment variable: C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.11.25503\bin\Hostx64\x64 Could you check? Kind regards André
Unfortunately the corresponding installer PRs didn't make it into the release, so you still have to remove most options of section Environment64 from sc.ini yourself. This should be enough [Environment64] LIB=% P%\..\lib64 DFLAGS=%DFLAGS% -L/OPT:NOICF When using the 7z dmd file, the most harmful setting is LINKCMD, that doesn't work for VS2017.
Jan 08 2018
next sibling parent Andre Pany <andre s-e-a-p.de> writes:
On Monday, 8 January 2018 at 22:41:31 UTC, Rainer Schuetze wrote:
 Unfortunately the corresponding installer PRs didn't make it 
 into the release, so you still have to remove most options of 
 section Environment64 from sc.ini yourself. This should be 
 enough

 [Environment64]
 LIB=% P%\..\lib64
 DFLAGS=%DFLAGS% -L/OPT:NOICF

 When using the 7z dmd file, the most harmful setting is 
 LINKCMD, that doesn't work for VS2017.
Thanks a lot for the information. My use case is a XMake build plugin (Python) for D which currently only supports X86 COFF. Adapting the sc.ini from Python is only working with ugly workarounds as duplicate keys in sc.ini is not really allowed. I will wait until the corresponding pull request is merged. Does it make sense to open an issue or will it be anyway available in next relase? Kind regards André
Jan 09 2018
prev sibling parent reply Andre Pany <andre s-e-a-p.de> writes:
On Monday, 8 January 2018 at 22:41:31 UTC, Rainer Schuetze wrote:
 Unfortunately the corresponding installer PRs didn't make it 
 into the release, so you still have to remove most options of 
 section Environment64 from sc.ini yourself. This should be 
 enough

 [Environment64]
 LIB=% P%\..\lib64
 DFLAGS=%DFLAGS% -L/OPT:NOICF

 When using the 7z dmd file, the most harmful setting is 
 LINKCMD, that doesn't work for VS2017.
Any chance to get the corresponding PR with 2.078.1 point release? I also tried it with the Build Tools for Visual Studio 2017 and it neither works. I think the link path could be easily retrieved. You could check whether the first element of %PATH% contains a file link.exe and use this one if the file path also starts with %VCINSTALLDIR%. Example: Path=C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\VC\Tools\MSVC\14.12.25827\bin\HostX64\x64;... VCINSTALLDIR=C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\VC\ Kind regards André
Jan 12 2018
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 12.01.2018 12:42, Andre Pany wrote:
 On Monday, 8 January 2018 at 22:41:31 UTC, Rainer Schuetze wrote:
 Unfortunately the corresponding installer PRs didn't make it into the 
 release, so you still have to remove most options of section 
 Environment64 from sc.ini yourself. This should be enough

 [Environment64]
 LIB=% P%\..\lib64
 DFLAGS=%DFLAGS% -L/OPT:NOICF

 When using the 7z dmd file, the most harmful setting is LINKCMD, that 
 doesn't work for VS2017.
Any chance to get the corresponding PR with 2.078.1 point release? I also tried it with the Build Tools for Visual Studio 2017 and it neither works. I think the link path could be easily retrieved. You could check whether the first element of %PATH% contains a file link.exe and use this one if the file path also starts with %VCINSTALLDIR%. Example: Path=C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\VC\Tools\MSVC\14.12.25827\bin\HostX64\x64;... VCINSTALLDIR=C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\VC\ Kind regards André
IMO removing the detected entries from sc.ini should be good enough: https://github.com/dlang/dmd/pull/7686. The linker path is built from the other VC variables. I've based it on stable in the hope it will make it into 2.078.1. The more involved changes I mentioned are https://github.com/dlang/installer/pull/281 and https://github.com/dlang/dmd/pull/7500.
Jan 12 2018
parent Andre Pany <andre s-e-a-p.de> writes:
On Friday, 12 January 2018 at 18:25:37 UTC, Rainer Schuetze wrote:
 IMO removing the detected entries from sc.ini should be good 
 enough: https://github.com/dlang/dmd/pull/7686. The linker path 
 is built from the other VC variables. I've based it on stable 
 in the hope it will make it into 2.078.1.

 The more involved changes I mentioned are 
 https://github.com/dlang/installer/pull/281 and 
 https://github.com/dlang/dmd/pull/7500.
Thanks for your great work! Kind regards Andre
Jan 12 2018
prev sibling next sibling parent reply Andre Pany <andre s-e-a-p.de> writes:
On Wednesday, 3 January 2018 at 17:43:36 UTC, Martin Nowak wrote:
 Glad to announce D 2.078.0.

 This release comes with runtime detection of Visual Studio 
 installation paths, an integral promotion transition for unary 
 operations on byte and short sized integers, more -betterC 
 features, and a couple of language and library tweaks.

 Thanks to everyone involved in this 👏 
 https://dlang.org/contributors.html.

 http://downloads.dlang.org/releases/2.x/2.078.0/ 
 http://dlang.org/changelog/2.078.0.html

 - -Martin
What is the purpose of the coverage option "srcpath"? In my scenario I have a folder "dependencies" and a folder "source". I want to generate code coverage only for the files in folder "source". dmd -unittest -cov source/app.d dependencies/dep.d app.exe --DRT-covopt="srcpath:./source dstpath:./cov" By specifying "srcpath" there are 2 empty files created in folder cov: source-app.lst dependencies-dep.lst I thought by specifying "srcpath" I limit the code coverage generation to the files located in folder source... Kind regards André
Jan 09 2018
parent reply Leandro Lucarella <leandro.lucarella sociomantic.com> writes:
On Wednesday, 10 January 2018 at 05:35:05 UTC, Andre Pany wrote:
 On Wednesday, 3 January 2018 at 17:43:36 UTC, Martin Nowak 
 wrote:
 Glad to announce D 2.078.0.

 This release comes with runtime detection of Visual Studio 
 installation paths, an integral promotion transition for unary 
 operations on byte and short sized integers, more -betterC 
 features, and a couple of language and library tweaks.

 Thanks to everyone involved in this 👏 
 https://dlang.org/contributors.html.

 http://downloads.dlang.org/releases/2.x/2.078.0/ 
 http://dlang.org/changelog/2.078.0.html

 - -Martin
What is the purpose of the coverage option "srcpath"? In my scenario I have a folder "dependencies" and a folder "source". I want to generate code coverage only for the files in folder "source". dmd -unittest -cov source/app.d dependencies/dep.d app.exe --DRT-covopt="srcpath:./source dstpath:./cov" By specifying "srcpath" there are 2 empty files created in folder cov: source-app.lst dependencies-dep.lst I thought by specifying "srcpath" I limit the code coverage generation to the files located in folder source...
From what I saw in the code, I think what it does is just override where the code was actually placed when you compiled, so tools to visualize the coverage can show you the source code. * https://dlang.org/code_coverage.html#switchsrcpath * https://github.com/dlang/druntime/blob/382b759738b5fa1e59bfda2ad542b9d60ef3d59a/src/rt/cover.d#L83-L84 * https://github.com/dlang/druntime/blob/382b759738b5fa1e59bfda2ad542b9d60ef3d59a/src/rt/cover.d#L211 BTW, to just report coverage of certain files you can just compile with `-cov` those files. I guess that should work (maybe? :).
Jan 12 2018
parent Andre Pany <andre s-e-a-p.de> writes:
On Friday, 12 January 2018 at 10:13:13 UTC, Leandro Lucarella 
wrote:
 From what I saw in the code, I think what it does is just 
 override where the code was actually placed when you compiled, 
 so tools to visualize the coverage can show you the source code.

 * https://dlang.org/code_coverage.html#switchsrcpath
 * 
 https://github.com/dlang/druntime/blob/382b759738b5fa1e59bfda2ad542b9d60ef3d59a/src/rt/cover.d#L83-L84
 * 
 https://github.com/dlang/druntime/blob/382b759738b5fa1e59bfda2ad542b9d60ef3d59a/src/rt/cover.d#L211

 BTW, to just report coverage of certain files you can just 
 compile with `-cov` those files. I guess that should work 
 (maybe? :).
Thanks for the clarification. Kind regards André
Jan 12 2018
prev sibling parent reply Nathan S. <no.public.email example.com> writes:
DMD64 2.078.0 on Linux and macOS is taking wildly longer to build 
and run unittests for mir-algorithm. The extra time appears to be 
related to release mode optimizations.

Build logs:
https://travis-ci.org/libmir/mir-algorithm/builds/324052159

DMD 2.077.1 for linux32: 3 min 20 sec
DMD 2.077.1 for linux64: 3 min 16 sec
DMD 2.077.1 for mac64: 5 min 4 sec

DMD 2.078.0-rc.1 for linux32: 13 min 30 sec
DMD 2.078.0-rc.1 for linux64: 9 min 39 sec
DMD 2.078.0-rc.1 for mac64: 10 min 56 sec, then the job was 
aborted

The above tests all include a non-release build and a release 
build. On my mac laptop running DMD 2.078.0, building and running 
the mir-algorithm unittests takes 8 seconds normally but takes ~3 
minutes 49 seconds with dub options "releaseMode", "optimize", 
"inline", "noBoundsCheck".

I don't see any new compiler optimizations in the changelog. Any 
idea of what could be causing this?
Jan 10 2018
parent reply Nathan S. <no.public.email example.com> writes:
On Wednesday, 10 January 2018 at 21:32:55 UTC, Nathan S. wrote:
 On my mac laptop running DMD 2.078.0, building and running the 
 mir-algorithm unittests takes 8 seconds normally but takes ~3 
 minutes 49 seconds with dub options "releaseMode", "optimize", 
 "inline", "noBoundsCheck".
When I remove the "inline" option the build + test time becomes <10 seconds. So the weirdly slow part is related to inlining.
Jan 10 2018
parent timotheecour <timothee.cour2 gmail.com> writes:
On Wednesday, 10 January 2018 at 21:42:38 UTC, Nathan S. wrote:
 When I remove the "inline" option the build + test time becomes 
 <10 seconds. So the weirdly slow part is related to inlining.
filed so we don't forget: https://issues.dlang.org/show_bug.cgi?id=18221
Jan 10 2018