Re: Release D 2.078.0
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
Re: Release D 2.078.0
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.
Re: Release D 2.078.0
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é
Re: Release D 2.078.0
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é
Re: Release D 2.078.0
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? :).
Re: Release D 2.078.0
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
Re: Release D 2.078.0
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.
Re: Release D 2.078.0
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?
Re: Release D 2.078.0
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é
Re: Release D 2.078.0
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
Re: Release D 2.078.0
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é
Re: Release D 2.078.0
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.
Re: Release D 2.078.0
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.
Re: Release D 2.078.0
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é
Re: Release D 2.078.0
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/src/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
Re: Release D 2.078.0
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!
Re: Release D 2.078.0
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.
Re: Release D 2.078.0
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,...
Re: Release D 2.078.0
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 ?
Re: Release D 2.078.0
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.
0x77460299 in fwrite () from /lib64/libc.so.6
Fatal error: glibc detected an invalid stdio handle
Аварийный останов
(gdb) bt
#0 0x77460299 in fwrite () from /lib64/libc.so.6
#1 0x004046ba in std.stdio (obj=..., f=0x655160 ) at
/usr/include/d/std/stdio.d:4064
#2 0x004045f1 in std.stdio.File.LockingTextWriter (this=...,
writeme=...)
at /usr/include/d/std/stdio.d:2775
#3 0x00403ddb in std.range.primitives (e=..., r=...) at
/usr/include/d/std/range/primitives.d:269
#4 0x00403dad in std.range.primitives (e=..., r=...) at
/usr/include/d/std/range/primitives.d:358
#5 0x00403d41 in std.format (this=..., writer=...) at
/usr/include/d/std/format.d:1188
#6 0x00403871 in std.format (fmt=..., w=...) at
/usr/include/d/std/format.d:474
#7 0x004037d1 in std.stdio.File (this=..., fmt=...) at
/usr/include/d/std/stdio.d:1496
#8 0x00403759 in std.stdio (fmt=...) at
/usr/include/d/std/stdio.d:3797
#9 0x0040370a in D main (args=...) at hello.d:7
Thank you, yours sincerely and etc...
Please file an issue (so it doesn't get lost) thanks!
http://issues.dlang.org
Re: Release D 2.078.0
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.
0x77460299 in fwrite () from /lib64/libc.so.6
Fatal error: glibc detected an invalid stdio handle
Аварийный останов
(gdb) bt
#0 0x77460299 in fwrite () from /lib64/libc.so.6
#1 0x004046ba in std.stdio (obj=..., f=0x655160 ) at
/usr/include/d/std/stdio.d:4064
#2 0x004045f1 in std.stdio.File.LockingTextWriter (this=...,
writeme=...)
at /usr/include/d/std/stdio.d:2775
#3 0x00403ddb in std.range.primitives (e=..., r=...) at
/usr/include/d/std/range/primitives.d:269
#4 0x00403dad in std.range.primitives (e=..., r=...) at
/usr/include/d/std/range/primitives.d:358
#5 0x00403d41 in std.format (this=..., writer=...) at
/usr/include/d/std/format.d:1188
#6 0x00403871 in std.format (fmt=..., w=...) at
/usr/include/d/std/format.d:474
#7 0x004037d1 in std.stdio.File (this=..., fmt=...) at
/usr/include/d/std/stdio.d:1496
#8 0x00403759 in std.stdio (fmt=...) at
/usr/include/d/std/stdio.d:3797
#9 0x0040370a in D main (args=...) at hello.d:7
Thank you, yours sincerely and etc...
Re: Release D 2.078.0
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
Re: Release D 2.078.0
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.
Re: Release D 2.078.0
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.
Re: Release D 2.078.0
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.
Re: Release D 2.078.0
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!
Re: Release D 2.078.0
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
Re: Release D 2.078.0
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/
Re: Release D 2.078.0
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.
Re: Release D 2.078.0
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!
Re: Release D 2.078.0
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
Re: Release D 2.078.0
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
Re: Release D 2.078.0
On 1/3/2018 9:43 AM, Martin Nowak wrote: Glad to announce D 2.078.0. Thank you, Martin!
Re: Release D 2.078.0
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.
Re: Release D 2.078.0
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.
Re: Release D 2.078.0
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
Release D 2.078.0
-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-
