digitalmars.D.announce - Release D 2.078.0

Martin Nowak (27/27) Jan 03 2018 -----BEGIN PGP SIGNED MESSAGE-----

Basile B. (2/12) Jan 03 2018 thanks buddies.
Seb (4/14) Jan 03 2018 Thanks a lot Martin!!
H. S. Teoh (11/16) Jan 03 2018 Awesome!

Seb (6/25) Jan 03 2018 Yes, it's a git mailmap:

Mike Parker (3/13) Jan 03 2018 Awesome! I'll post the blog announcement and hit social media in

Mike Parker (5/7) Jan 04 2018 Blog:

Joakim (8/16) Jan 04 2018 Nice post, good explanations and code samples. Here's some

Mike Parker (2/9) Jan 04 2018 Thanks!

jmh530 (4/8) Jan 04 2018 I've been really liking the blog write-ups on the new releases.

Mike Parker (3/6) Jan 04 2018 It's a WIP.

Jack Stouffer (11/23) Jan 04 2018 If I may make a suggestion, please make the vision documents

David Nadlinger (14/21) Jan 04 2018 This is slightly inaccurate. Regular stack cleanup doesn't

Mike Parker (3/16) Jan 05 2018 Thanks, David!
Mike Franklin (5/7) Jan 05 2018 ModuleInfo is declared and defined in druntime

Walter Bright (2/3) Jan 03 2018 Thank you, Martin!
thedeemon (19/22) Jan 03 2018 I've got a problem with linking phobos64.lib now.

Rainer Schuetze (12/38) Jan 04 2018 What's missing is probably legacy_stdio_definition.lib that has to be

thedeemon (18/25) Jan 04 2018 Yes, that is the case!

IM (2/12) Jan 04 2018 Thank you very much!
=?UTF-8?B?0JPQu9C10LEg0JrRg9C70LjQutC+0LIvR2xlYg==?= Kulikov (38/40) Jan 05 2018 Hello and Happy New Year ! :)

rikki cattermole (3/60) Jan 05 2018 Please file an issue (so it doesn't get lost) thanks!
user789 (4/10) Jan 05 2018 I also setup from the RH rpm and it works fine here, also in GDB.

gleb (13/18) Jan 05 2018 Yes,

user789 (4/23) Jan 05 2018 I've seen your report. kernel is at 4.14 and glibc is 2.26 here,

Martin Nowak (9/18) Jan 09 2018 Please file a bug report under https://issues.dlang.org/enter_bug.cgi

Andre Pany (24/34) Jan 07 2018 It seems vs-auto-detection does not work with the Visual Studio

Nicholas Wilson (2/34) Jan 08 2018 Note the double backslash, its getting confused.
Rainer Schuetze (9/55) Jan 08 2018 Unfortunately the corresponding installer PRs didn't make it into the

Andre Pany (10/19) Jan 09 2018 Thanks a lot for the information. My use case is a XMake build
Andre Pany (15/24) Jan 12 2018 Any chance to get the corresponding PR with 2.078.1 point release?

Rainer Schuetze (8/40) Jan 12 2018 IMO removing the detected entries from sc.ini should be good enough:

Andre Pany (4/11) Jan 12 2018 Thanks for your great work!

Andre Pany (15/25) Jan 09 2018 What is the purpose of the coverage option "srcpath"?

Leandro Lucarella (12/40) Jan 12 2018 From what I saw in the code, I think what it does is just

Andre Pany (5/16) Jan 12 2018 Thanks for the clarification.

Nathan S. (19/19) Jan 10 2018 DMD64 2.078.0 on Linux and macOS is taking wildly longer to build

Nathan S. (3/7) Jan 10 2018 When I remove the "inline" option the build + test time becomes

timotheecour (3/5) Jan 10 2018 filed so we don't forget:

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

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

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

"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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

=?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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

D Programming

C/C++ Programming

Other

digitalmars.D.announce - Release D 2.078.0