www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Beta D 2.068.0-b2

reply Martin Nowak <code+news.digitalmars dawg.eu> writes:
Second beta for the 2.068.0 release.

http://downloads.dlang.org/pre-releases/2.x/2.068.0/
http://ftp.digitalmars.com/

Also available on Travis-CI as dmd-2.068.0-b2.


of all fixed issues that will be included in 2.068.0.
A description of library and language changes is still upcoming.

This beta comes with 27 dmd, 2 druntime, and 4 phobos fixes.

https://github.com/D-Programming-Language/dmd/compare/v2.068.0-b1...v2.068.0-b2
https://github.com/D-Programming-Language/druntime/compare/v2.068.0-b1...v2.068.0-b2
https://github.com/D-Programming-Language/phobos/compare/v2.068.0-b1...v2.068.0-b2

Please report any bugs at https://issues.dlang.org.

-Martin
Jul 25 2015
next sibling parent reply Martin Nowak <code+news.digitalmars dawg.eu> writes:
On 07/25/2015 02:20 PM, Martin Nowak wrote:
 Second beta for the 2.068.0 release.
 
 http://downloads.dlang.org/pre-releases/2.x/2.068.0/
 http://ftp.digitalmars.com/
BTW, I'd like to phase out the fat 50-60MB combined zip, and add tar.xz/gz for linux/freebsd/osx. Does anyone still rely on the combined zip?
Jul 26 2015
next sibling parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 07/26/2015 09:55 AM, Martin Nowak wrote:
 On 07/25/2015 02:20 PM, Martin Nowak wrote:
 Second beta for the 2.068.0 release.

 http://downloads.dlang.org/pre-releases/2.x/2.068.0/
 http://ftp.digitalmars.com/
BTW, I'd like to phase out the fat 50-60MB combined zip, and add tar.xz/gz for linux/freebsd/osx. Does anyone still rely on the combined zip?
I think DVM still relies on it (unless I just have an old DVM on this machine)
Jul 26 2015
prev sibling next sibling parent reply Jordi Sayol via Digitalmars-d-announce writes:
El 26/07/15 a les 15:55, Martin Nowak via Digitalmars-d-announce ha escrit:
 BTW, I'd like to phase out the fat 50-60MB combined zip, and add
 tar.xz/gz for linux/freebsd/osx.
Is it not better to use 7z format? It has more compression ratios than gz/bz2, and they can be easily handled on Windows.
Jul 26 2015
parent Martin Nowak <code+news.digitalmars dawg.eu> writes:
On 07/26/2015 08:13 PM, Jordi Sayol via Digitalmars-d-announce wrote:
 Is it not better to use 7z format? It has more compression ratios than gz/bz2,
and they can be easily handled on Windows.
xz is 7-zip same entropy encoding.
Jul 27 2015
prev sibling next sibling parent Ben Boeckel via Digitalmars-d-announce writes:
On Sun, Jul 26, 2015 at 20:13:09 +0200, Jordi Sayol via Digitalmars-d-announce
wrote:
 El 26/07/15 a les 15:55, Martin Nowak via Digitalmars-d-announce ha escrit:
 BTW, I'd like to phase out the fat 50-60MB combined zip, and add
 tar.xz/gz for linux/freebsd/osx.
Is it not better to use 7z format? It has more compression ratios than gz/bz2, and they can be easily handled on Windows.
7z and xz are the same compression algorithm (LZMA), but xz works with tar (it works in streaming mode). --Ben
Jul 26 2015
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2015-07-26 15:55, Martin Nowak wrote:

 BTW, I'd like to phase out the fat 50-60MB combined zip, and add
 tar.xz/gz for linux/freebsd/osx.
 Does anyone still rely on the combined zip?
Yes, DVM does rely on them. -- /Jacob Carlborg
Jul 28 2015
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2015-07-26 15:55, Martin Nowak wrote:

 BTW, I'd like to phase out the fat 50-60MB combined zip, and add
 tar.xz/gz for linux/freebsd/osx.
 Does anyone still rely on the combined zip?
I noticed building the installer for OS X relies on that as well. -- /Jacob Carlborg
Jul 29 2015
parent Jacob Carlborg <doob me.com> writes:
On 2015-07-29 13:12, Jacob Carlborg wrote:

 I noticed building the installer for OS X relies on that as well.
Never mind, I looked at an old version of the makefile. -- /Jacob Carlborg
Jul 29 2015
prev sibling next sibling parent Rikki Cattermole <alphaglosined gmail.com> writes:
On 26/07/2015 12:20 a.m., Martin Nowak wrote:
 Second beta for the 2.068.0 release.

 http://downloads.dlang.org/pre-releases/2.x/2.068.0/
 http://ftp.digitalmars.com/

 Also available on Travis-CI as dmd-2.068.0-b2.


 of all fixed issues that will be included in 2.068.0.
 A description of library and language changes is still upcoming.

 This beta comes with 27 dmd, 2 druntime, and 4 phobos fixes.

 https://github.com/D-Programming-Language/dmd/compare/v2.068.0-b1...v2.068.0-b2
 https://github.com/D-Programming-Language/druntime/compare/v2.068.0-b1...v2.068.0-b2
 https://github.com/D-Programming-Language/phobos/compare/v2.068.0-b1...v2.068.0-b2

 Please report any bugs at https://issues.dlang.org.

 -Martin
*Grumbles* I was hoping a bug I found was fixed in ~master. It's not. I'll submit bug report later but: Internal error: backend\cgcv.c 217 But only in -debug -m64 without -v on Windows. With -v or -release, it builds fine.
Jul 26 2015
prev sibling next sibling parent =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig rejectedsoftware.com> writes:
The first RC of vibe.d 0.7.24 has also just been released. It works with 
DMD 2.068.0-b2. The final release will happen in lock-step with the DMD 
release.

Changelog:
https://github.com/rejectedsoftware/vibe.d/blob/master/CHANGELOG.md
Jul 26 2015
prev sibling next sibling parent reply "anonymous" <12321 45654.121> writes:
On Saturday, 25 July 2015 at 12:21:19 UTC, Martin Nowak wrote:
 Second beta for the 2.068.0 release.
Is std.expermimental.allocator planned for 2.068 ? I see it's still not merged and we already almost in August.
Jul 26 2015
next sibling parent "extrawurst" <stephan extrawurst.org> writes:
On Sunday, 26 July 2015 at 21:13:07 UTC, anonymous wrote:
 On Saturday, 25 July 2015 at 12:21:19 UTC, Martin Nowak wrote:
 Second beta for the 2.068.0 release.
Is std.expermimental.allocator planned for 2.068 ? I see it's still not merged and we already almost in August.
yeah was hoping to see it in there too --Stephan
Jul 26 2015
prev sibling next sibling parent reply "Brian Schott" <briancschott gmail.com> writes:
On Sunday, 26 July 2015 at 21:13:07 UTC, anonymous wrote:
 On Saturday, 25 July 2015 at 12:21:19 UTC, Martin Nowak wrote:
 Second beta for the 2.068.0 release.
Is std.expermimental.allocator planned for 2.068 ? I see it's still not merged and we already almost in August.
That makes me disappointed. I spent many hours reviewing and debugging that package. I have several projects that depend on it and I'd rather not maintain my own copy any more.
Jul 26 2015
parent reply "Joseph Cassman" <jc7919 outlook.com> writes:
On Sunday, 26 July 2015 at 23:07:15 UTC, Brian Schott wrote:
 On Sunday, 26 July 2015 at 21:13:07 UTC, anonymous wrote:
 On Saturday, 25 July 2015 at 12:21:19 UTC, Martin Nowak wrote:
 Second beta for the 2.068.0 release.
Is std.expermimental.allocator planned for 2.068 ? I see it's still not merged and we already almost in August.
That makes me disappointed. I spent many hours reviewing and debugging that package. I have several projects that depend on it and I'd rather not maintain my own copy any more.
Please merge allocators. How did the review finish, BTW? Still waiting on its summary. Unless I missed it. Thanks for the work on getting this included in 2.068. Joseph
Jul 26 2015
parent reply "Joseph Cassman" <jc7919 outlook.com> writes:
On Monday, 27 July 2015 at 03:18:13 UTC, Joseph Cassman wrote:
 [...]
 How did the review finish, BTW? Still waiting on its summary. 
 Unless I missed it.
Looks like the review summary was just posted. Thanks for the update. Joseph
Jul 26 2015
parent reply "Gerald Jansen" <gjansen ownmail.net> writes:
I'm not sure if this is the right place to report issues. I 
downloaded dmd.2.068.0-b2.linux.zip, unzipped it and added the 
bin64 directory to my path. The standard hello.d compiles fine 
but segfaults immediately. Details follow. Also rdmd segfaults 
with the same message. (The same process with the 2.067.1 zip 
works fine on the same box.)

Details:
gjansen gamma:~$ uname -a

EDT 2012 x86_64 x86_64 x86_64 GNU/Linux
gjansen gamma:~$ dmd --version
DMD64 D Compiler v2.068.0-b2
Copyright (c) 1999-2015 by Digital Mars written by Walter Bright
gjansen gamma:~$ dmd hello.d
gjansen gamma:~$ ./hello
Segmentation fault (core dumped)
gjansen gamma:~$ gdb hello
<snip>
(gdb) run
Starting program: /ricerca/gjansen/hello
[Thread debugging using libthread_db enabled]

Program received signal SIGSEGV, Segmentation fault.
0x00000000004418e1 in _d_initMonoTime ()
Missing separate debuginfos, use: debuginfo-install 
glibc-2.12-1.80.el6_3.6.x86_64
Jul 31 2015
parent reply "Kelet" <kelethunter gmail.com> writes:
On Friday, 31 July 2015 at 15:58:24 UTC, Gerald Jansen wrote:
 I'm not sure if this is the right place to report issues. I 
 downloaded dmd.2.068.0-b2.linux.zip, unzipped it and added the 
 bin64 directory to my path. The standard hello.d compiles fine 
 but segfaults immediately. Details follow. Also rdmd segfaults 
 with the same message. (The same process with the 2.067.1 zip 
 works fine on the same box.)

 Details:
 gjansen gamma:~$ uname -a

 13:44:51 EDT 2012 x86_64 x86_64 x86_64 GNU/Linux
 gjansen gamma:~$ dmd --version
 DMD64 D Compiler v2.068.0-b2
 Copyright (c) 1999-2015 by Digital Mars written by Walter Bright
 gjansen gamma:~$ dmd hello.d
 gjansen gamma:~$ ./hello
 Segmentation fault (core dumped)
 gjansen gamma:~$ gdb hello
 <snip>
 (gdb) run
 Starting program: /ricerca/gjansen/hello
 [Thread debugging using libthread_db enabled]

 Program received signal SIGSEGV, Segmentation fault.
 0x00000000004418e1 in _d_initMonoTime ()
 Missing separate debuginfos, use: debuginfo-install 
 glibc-2.12-1.80.el6_3.6.x86_64
Hi Gerald, MonoTime is the replacement for TickDuration and it's initialized from the runtime initialization function (rt_init). This is because the GC and others may need time functionality. Unfortunately, it looks like MonoTime does not currently support your kernel version. It needs at least Linux 2.6.39. The reason being is that it has the CLOCK_BOOTTIME clock which was implemented in Linux 2.6.39. Without this clock, the minimum version would be Linux 2.6.32. If I had to hazard a guess, I'd say the offending segfault is coming from calling clock_getres(clockArg, &ts) (where clockArg is essentially CLOCK_BOOTTIME) in _d_initMonoTime(). It seems to call this for all supported Clocks for your platform. Hopefully some code can be added to only allow CLOCK_BOOTTIME on kernels that support it. 2.6.32 is still supported as a longterm kernel release. Regards, Kelet
Jul 31 2015
next sibling parent "Kelet" <kelethunter gmail.com> writes:
On Friday, 31 July 2015 at 17:56:23 UTC, Kelet wrote:
 On Friday, 31 July 2015 at 15:58:24 UTC, Gerald Jansen wrote:
 [...]
Hi Gerald, MonoTime is the replacement for TickDuration and it's initialized from the runtime initialization function (rt_init). This is because the GC and others may need time functionality. [...]
To expand on this, while MonoTime was in 2.067.1, it was not initialized in rt_init at the time. Regards, Kelet
Jul 31 2015
prev sibling parent "Martin Nowak" <code dawg.eu> writes:
On Friday, 31 July 2015 at 17:56:23 UTC, Kelet wrote:
 Hi Gerald,

 MonoTime is the replacement for TickDuration and it's 
 initialized from the runtime initialization function (rt_init). 
 This is because the GC and others may need time functionality.
Thanks, filed as https://issues.dlang.org/show_bug.cgi?id=14863.
Aug 02 2015
prev sibling parent reply Martin Nowak <code+news.digitalmars dawg.eu> writes:
On 07/26/2015 11:13 PM, anonymous wrote:
 
 Is std.expermimental.allocator planned for 2.068 ?
 I see it's still not merged and we already almost in August.
We're trying hard here to meet some deadlines, so things are really simple. If something is ready (reviewed, tested, documented, and merged into stable) it'll end up in a release, otherwise it'll end up in the next release (only 2 month later). We can't postpone indefinitely just b/c every other person is trying to push through their particular interests.
Jul 27 2015
next sibling parent reply "extrawurst" <stephan extrawurst.org> writes:
On Monday, 27 July 2015 at 09:04:08 UTC, Martin Nowak wrote:
 On 07/26/2015 11:13 PM, anonymous wrote:
 
 Is std.expermimental.allocator planned for 2.068 ?
 I see it's still not merged and we already almost in August.
We're trying hard here to meet some deadlines, so things are really simple. If something is ready (reviewed, tested, documented, and merged into stable) it'll end up in a release, otherwise it'll end up in the next release (only 2 month later). We can't postpone indefinitely just b/c every other person is trying to push through their particular interests.
fair enough. 2.069 release it is then ;) -- Stephan
Jul 27 2015
parent reply "jmh530" <john.michael.hall gmail.com> writes:
On Monday, 27 July 2015 at 11:30:09 UTC, extrawurst wrote:
 On Monday, 27 July 2015 at 09:04:08 UTC, Martin Nowak wrote:
 On 07/26/2015 11:13 PM, anonymous wrote:
 
 Is std.expermimental.allocator planned for 2.068 ?
 I see it's still not merged and we already almost in August.
We're trying hard here to meet some deadlines, so things are really simple. If something is ready (reviewed, tested, documented, and merged into stable) it'll end up in a release, otherwise it'll end up in the next release (only 2 month later). We can't postpone indefinitely just b/c every other person is trying to push through their particular interests.
fair enough. 2.069 release it is then ;) -- Stephan
I thought the next release was to switch to ddmd and wasn't supposed to add a bunch of new features?
Jul 27 2015
parent "Martin Nowak" <code dawg.eu> writes:
On Monday, 27 July 2015 at 16:57:24 UTC, jmh530 wrote:
 I thought the next release was to switch to ddmd and wasn't 
 supposed to add a bunch of new features?
That's for the dmd side, doesn't preclude work on druntime or Phobos.
Jul 28 2015
prev sibling next sibling parent reply "Joseph Cassman" <jc7919 outlook.com> writes:
On Monday, 27 July 2015 at 09:04:08 UTC, Martin Nowak wrote:
 On 07/26/2015 11:13 PM, anonymous wrote:
 
 Is std.expermimental.allocator planned for 2.068 ?
 I see it's still not merged and we already almost in August.
We're trying hard here to meet some deadlines, so things are really simple. If something is ready (reviewed, tested, documented, and merged into stable) it'll end up in a release, otherwise it'll end up in the next release (only 2 month later). We can't postpone indefinitely just b/c every other person is trying to push through their particular interests.
I can understand that. But releases tend to be several months away. And not just two. So this is a bit frustrating. Joseph
Jul 27 2015
parent reply "Martin Nowak" <code dawg.eu> writes:
On Monday, 27 July 2015 at 17:12:49 UTC, Joseph Cassman wrote:
 I can understand that. But releases tend to be several months 
 away. And not just two. So this is a bit frustrating.
We're trying to get to a 2 month interval, and delaying work that doesn't meet the deadlines is necessary to achieve this. I hope that with a more regular interval people will be more aware of the next release and plan their work accordingly.
Jul 28 2015
parent "Joseph Cassman" <jc7919 outlook.com> writes:
On Tuesday, 28 July 2015 at 09:10:43 UTC, Martin Nowak wrote:
 On Monday, 27 July 2015 at 17:12:49 UTC, Joseph Cassman wrote:
 I can understand that. But releases tend to be several months 
 away. And not just two. So this is a bit frustrating.
We're trying to get to a 2 month interval, and delaying work that doesn't meet the deadlines is necessary to achieve this. I hope that with a more regular interval people will be more aware of the next release and plan their work accordingly.
That would be awesome. Thanks for your work toward that goal. Joseph
Jul 28 2015
prev sibling parent reply "anonymous" <12321 456.654> writes:
On Monday, 27 July 2015 at 09:04:08 UTC, Martin Nowak wrote:
 On 07/26/2015 11:13 PM, anonymous wrote:
 
 Is std.expermimental.allocator planned for 2.068 ?
 I see it's still not merged and we already almost in August.
We're trying hard here to meet some deadlines, so things are really simple. If something is ready (reviewed, tested, documented, and merged into stable) it'll end up in a release, otherwise it'll end up in the next release (only 2 month later). We can't postpone indefinitely just b/c every other person is trying to push through their particular interests.
Yep I see where the energy goes http://forum.dlang.org/thread/ckjukjfkgrguhfhkdhhj forum.dlang.org
Jul 27 2015
next sibling parent reply "anonymous" <12321 456.654> writes:
On Monday, 27 July 2015 at 23:40:28 UTC, anonymous wrote:
 On Monday, 27 July 2015 at 09:04:08 UTC, Martin Nowak wrote:
 On 07/26/2015 11:13 PM, anonymous wrote:
 
 Is std.expermimental.allocator planned for 2.068 ?
 I see it's still not merged and we already almost in August.
We're trying hard here to meet some deadlines, so things are really simple. If something is ready (reviewed, tested, documented, and merged into stable) it'll end up in a release, otherwise it'll end up in the next release (only 2 month later). We can't postpone indefinitely just b/c every other person is trying to push through their particular interests.
Yep I see where the energy goes http://forum.dlang.org/thread/ckjukjfkgrguhfhkdhhj forum.dlang.org
where it' gone....
Jul 27 2015
parent "anonymous" <12321 456.654> writes:
On Monday, 27 July 2015 at 23:49:34 UTC, anonymous wrote:
 On Monday, 27 July 2015 at 23:40:28 UTC, anonymous wrote:
 On Monday, 27 July 2015 at 09:04:08 UTC, Martin Nowak wrote:
 On 07/26/2015 11:13 PM, anonymous wrote:
 [...]
We're trying hard here to meet some deadlines, so things are really simple. If something is ready (reviewed, tested, documented, and merged into stable) it'll end up in a release, otherwise it'll end up in the next release (only 2 month later). We can't postpone indefinitely just b/c every other person is trying to push through their particular interests.
Yep I see where the energy goes http://forum.dlang.org/thread/ckjukjfkgrguhfhkdhhj forum.dlang.org
where it' gone....
where it's gone. Instead to solve the conflicts...
Jul 27 2015
prev sibling parent "Martin Nowak" <code dawg.eu> writes:
On Monday, 27 July 2015 at 23:40:28 UTC, anonymous wrote:
 On Monday, 27 July 2015 at 09:04:08 UTC, Martin Nowak wrote:
 Yep I see where the energy goes

 http://forum.dlang.org/thread/ckjukjfkgrguhfhkdhhj forum.dlang.org
That has nothing to do with our release. https://trello.com/b/XoFjxiqG/active
Jul 28 2015
prev sibling parent reply "Joseph Cassman" <jc7919 outlook.com> writes:
On Saturday, 25 July 2015 at 12:21:19 UTC, Martin Nowak wrote:
 Second beta for the 2.068.0 release.

 http://downloads.dlang.org/pre-releases/2.x/2.068.0/ 
 http://ftp.digitalmars.com/

 Also available on Travis-CI as dmd-2.068.0-b2.


 contains a list
 of all fixed issues that will be included in 2.068.0.
 A description of library and language changes is still upcoming.

 This beta comes with 27 dmd, 2 druntime, and 4 phobos fixes.

 https://github.com/D-Programming-Language/dmd/compare/v2.06
.0-b1...v2.068.0-b2 https://github.com/D-Programming-Language/druntime/compare/v2.06
.0-b1...v2.068.0-b2 https://github.com/D-Programming-Language/phobos/compare/v2.068.0-b1...v2.068.0-b2

 Please report any bugs at https://issues.dlang.org.

 -Martin
Sorry for the following rant but I am frustrated by the poor quality of support for Windows 64 development. <rant> Will the change over to DDMD finally make Win64 a fully supported platform? And will I finally be able to build the most recent code snapshot without having to get a Win64 build toolchain setup (Win64 is not really supported for DMD development: [2])? I just wasted a lot of time again trying to get Win64 set up on a machine I had to wipe. I had it working for 2.067.1 somehow but was never able to duplicate that on other machines I have. The information at [1] is outdated. Neither the Windows 7 nor 8.1 SDK install a linker for me now for some reason. I had to install VS 2015 to get a 64-bit linker. This fixed the linker not found post installation issue. But then I got a LIBCMT.lib not found issue. I copied it and other library files to the D installation lib64 subdirectory (I couldn't figure out what to modify in the sc.ini file; tried various modifications). Now I am getting a cryptic LNK4229 error that makes no sense to me. At this point I quit. I shouldn't have to modify the sc.ini file at all to get any of this working. This is after using the Windows installer and when I use the -m64 compilation switch. By way of comparison, I can download other languages and run their installer. After that everything just works: linker included. Why do I have to install a MS toolchain just to get 64-bit linking for DMD? I like D a lot. I have been using it for a while. But I have always had trouble with Win64 development. I need that platform for my work. But I will have to dev on Linux again just for 64-bit support. And hope that this can finally get fixed. Although I am real close to just walking away on this one. </rant> Hope this can be fixed. Thanks Joseph [1] http://wiki.dlang.org/Installing_DMD_on_64-bit_Windows_7_(COFF-compatible) [2] http://wiki.dlang.org/Building_DMD -- Windows - step by step
Jul 27 2015
next sibling parent reply "jmh530" <john.michael.hall gmail.com> writes:
On Monday, 27 July 2015 at 18:58:33 UTC, Joseph Cassman wrote:
 Sorry for the following rant but I am frustrated by the poor 
 quality of support for Windows 64 development.

 <rant>
I understand that frustration. I had some modest problems getting it to work with -m64 on my home computer. However, I had bigger problems getting Visual D to work. Eclipse wouldn't work with the Java installed on my work computer. Coedit wouldn't install on my work computer either (I'm not sure how much this is Coedit's fault though, works fine at home). I think at home I'm just going to virtualize a Linux session. I can dual-boot the machine, but I always find it a hassle if I'm in the middle of doing something in Windows and want to play around with D.
Jul 27 2015
next sibling parent "Joseph Cassman" <jc7919 outlook.com> writes:
On Monday, 27 July 2015 at 20:43:38 UTC, jmh530 wrote:
 On Monday, 27 July 2015 at 18:58:33 UTC, Joseph Cassman wrote:
 Sorry for the following rant but I am frustrated by the poor 
 quality of support for Windows 64 development.

 <rant>
I understand that frustration. I had some modest problems getting it to work with -m64 on my home computer. However, I had bigger problems getting Visual D to work. Eclipse wouldn't work with the Java installed on my work computer. Coedit wouldn't install on my work computer either (I'm not sure how much this is Coedit's fault though, works fine at home). I think at home I'm just going to virtualize a Linux session. I can dual-boot the machine, but I always find it a hassle if I'm in the middle of doing something in Windows and want to play around with D.
Yeah, pretty much the unfortunate conclusion I came to as well. Joseph
Jul 27 2015
prev sibling parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig rejectedsoftware.com> writes:
Am 27.07.2015 um 22:43 schrieb jmh530:
 On Monday, 27 July 2015 at 18:58:33 UTC, Joseph Cassman wrote:
 Sorry for the following rant but I am frustrated by the poor quality
 of support for Windows 64 development.

 <rant>
I understand that frustration. I had some modest problems getting it to work with -m64 on my home computer. However, I had bigger problems getting Visual D to work. Eclipse wouldn't work with the Java installed on my work computer. Coedit wouldn't install on my work computer either (I'm not sure how much this is Coedit's fault though, works fine at home). I think at home I'm just going to virtualize a Linux session. I can dual-boot the machine, but I always find it a hassle if I'm in the middle of doing something in Windows and want to play around with D.
I never had issues with VisualD so far. Which version of VisualStudio do you have installed? 64-bit compilation for DMD also works for me for VisualD, as well as when using DUB from the "VS20xx x64 Native Tools Command Prompt" (xx=13 or 15) with the "-a x86_64" switch.
Jul 28 2015
parent "jmh530" <john.michael.hall gmail.com> writes:
On Tuesday, 28 July 2015 at 09:17:21 UTC, Sönke Ludwig wrote:
 I never had issues with VisualD so far. Which version of 
 VisualStudio do you have installed?

 64-bit compilation for DMD also works for me for VisualD, as 
 well as when using DUB from the "VS20xx x64 Native Tools 
 Command Prompt" (xx=13 or 15) with the "-a x86_64" switch.
I don't really even like Visual Studio. I'm not going to make any extra effort to get something working with it. If it worked easily (like with me spending less than 10 min trying to get it work), then I might have played around with VisualD.
Jul 28 2015
prev sibling next sibling parent reply "Martin Nowak" <code dawg.eu> writes:
On Monday, 27 July 2015 at 18:58:33 UTC, Joseph Cassman wrote:
 Sorry for the following rant but I am frustrated by the poor 
 quality of support for Windows 64 development.
Try http://rainers.github.io/visuald/visuald/StartPage.html.
 By way of comparison, I can download other languages and run 
 their installer. After that everything just works: linker 
 included. Why do I have to install a MS toolchain just to get 
 64-bit linking for DMD?
What languages and what linkers are they using?
 I like D a lot. I have been using it for a while. But I have 
 always had trouble with Win64 development. I need that platform 
 for my work. But I will have to dev on Linux again just for 
 64-bit support. And hope that this can finally get fixed. 
 Although I am real close to just walking away on this one.
Jul 28 2015
parent reply "Joseph Cassman" <jc7919 outlook.com> writes:
On Tuesday, 28 July 2015 at 09:30:38 UTC, Martin Nowak wrote:
 On Monday, 27 July 2015 at 18:58:33 UTC, Joseph Cassman wrote:
 Sorry for the following rant but I am frustrated by the poor 
 quality of support for Windows 64 development.
Try http://rainers.github.io/visuald/visuald/StartPage.html.
 By way of comparison, I can download other languages and run 
 their installer. After that everything just works: linker 
 included. Why do I have to install a MS toolchain just to get 
 64-bit linking for DMD?
What languages and what linkers are they using?
 I like D a lot. I have been using it for a while. But I have 
 always had trouble with Win64 development. I need that 
 platform for my work. But I will have to dev on Linux again 
 just for 64-bit support. And hope that this can finally get 
 fixed. Although I am real close to just walking away on this 
 one.
Thanks for the pointer. I took a look. I could be wrong but it seems it is geared toward using D in VS. This is a little different than my use-case. I use D with a text editor and the console. So I am just looking for a 64-bit linker. I was forced to install VS to get one since for some reason the 7A and 8.1 Windows SDK's did not install a complete 64-bit toolchain for me. Yeah, I used the Windows D installer after the toolchain was in-place. So I figured the sc.ini should have been automatically set. Your next post is more to the point of what I am trying to do. I'll try out a redux on the path I took to install to give more clarity. It'll take a while since I have to uninstall VS2015. Appreciate the feedback. Joseph
Jul 28 2015
parent "Martin Nowak" <code dawg.eu> writes:
On Wednesday, 29 July 2015 at 01:52:34 UTC, Joseph Cassman wrote:
 I was forced to install VS to get one since for some reason the 
 7A and 8.1 Windows SDK's did not install a complete 64-bit 
 toolchain for me.
Seems like Microsoft dropped the compiler from the SDK. https://msdn.microsoft.com/en-us/windows/desktop/hh852363.aspx
Jul 29 2015
prev sibling parent reply "Martin Nowak" <code dawg.eu> writes:
On Monday, 27 July 2015 at 18:58:33 UTC, Joseph Cassman wrote:
 I just wasted a lot of time again trying to get Win64 set up on 
 a machine I had to wipe. I had it working for 2.067.1 somehow 
 but was never able to duplicate that on other machines I have. 
 The information at [1] is outdated. Neither the Windows 7 nor 
 8.1 SDK install a linker for me now for some reason. I had to 
 install VS 2015 to get a 64-bit linker. This fixed the linker 
 not found post installation issue. But then I got a LIBCMT.lib 
 not found issue. I copied it and other library files to the D 
 installation lib64 subdirectory (I couldn't figure out what to 
 modify in the sc.ini file; tried various modifications). Now I 
 am getting a cryptic LNK4229 error that makes no sense to me. 
 At this point I quit.
Depending on Microsoft's libc and linker for 64-bit is an unfortunate dependency and can cause some hassle. An alternative would be appreciated, but I'm not aware of any. There is some code in the installer, that detects your SDK, but if you installed it after dmd it won't work. Isn't there some feedback about SDKs during installation?
Jul 28 2015
parent reply "Joseph Cassman" <jc7919 outlook.com> writes:
On Tuesday, 28 July 2015 at 09:43:00 UTC, Martin Nowak wrote:
 On Monday, 27 July 2015 at 18:58:33 UTC, Joseph Cassman wrote:
 I just wasted a lot of time again trying to get Win64 set up 
 on a machine I had to wipe. I had it working for 2.067.1 
 somehow but was never able to duplicate that on other machines 
 I have. The information at [1] is outdated. Neither the 
 Windows 7 nor 8.1 SDK install a linker for me now for some 
 reason. I had to install VS 2015 to get a 64-bit linker. This 
 fixed the linker not found post installation issue. But then I 
 got a LIBCMT.lib not found issue. I copied it and other 
 library files to the D installation lib64 subdirectory (I 
 couldn't figure out what to modify in the sc.ini file; tried 
 various modifications). Now I am getting a cryptic LNK4229 
 error that makes no sense to me. At this point I quit.
Depending on Microsoft's libc and linker for 64-bit is an unfortunate dependency and can cause some hassle. An alternative would be appreciated, but I'm not aware of any. There is some code in the installer, that detects your SDK, but if you installed it after dmd it won't work. Isn't there some feedback about SDKs during installation?
There is probably an obvious reason this is not possible but I could not see it when reading through the MS licensing information. It seems to me the linker bin could be redistributed. Why is it (and the other required lib/dll files) not bundled with the Windows installer to make it one-stop-shopping? Seems like this is what is done with Win32. Joseph
Jul 28 2015
next sibling parent reply "Martin Nowak" <code dawg.eu> writes:
On Wednesday, 29 July 2015 at 01:55:35 UTC, Joseph Cassman wrote:
 There is probably an obvious reason this is not possible but I 
 could not see it when reading through the MS licensing 
 information. It seems to me the linker bin could be 
 redistributed. Why is it (and the other required lib/dll files) 
 not bundled with the Windows installer to make it 
 one-stop-shopping?

 Seems like this is what is done with Win32.
You're not allowed to redistribute the VS binaries, only the libc dlls. On Win32 we use our own libc (dmc) and linker (optlink). We could improve our installer so it can optionally start the VS compiler installation.
Jul 29 2015
next sibling parent reply "Martin Nowak" <code dawg.eu> writes:
On Wednesday, 29 July 2015 at 07:10:13 UTC, Martin Nowak wrote:
 You're not allowed to redistribute the VS binaries, only the 
 libc dlls.
 On Win32 we use our own libc (dmc) and linker (optlink).
 We could improve our installer so it can optionally start the 
 VS compiler installation.
https://issues.dlang.org/show_bug.cgi?id=14847
Jul 29 2015
parent reply "Joseph Cassman" <jc7919 outlook.com> writes:
On Wednesday, 29 July 2015 at 07:16:39 UTC, Martin Nowak wrote:
 On Wednesday, 29 July 2015 at 07:10:13 UTC, Martin Nowak wrote:
 You're not allowed to redistribute the VS binaries, only the 
 libc dlls.
 On Win32 we use our own libc (dmc) and linker (optlink).
 We could improve our installer so it can optionally start the 
 VS compiler installation.
https://issues.dlang.org/show_bug.cgi?id=14847
Martin, appreciate the help with this issue. I have investigated further and it looks like there is a work-around (item [3] below). Here is a synopsis of what I have found through testing. 1) Windows 7 SDK will not install completely now that I have .NET 4.5.1 installed (it requires version 4). It incorrectly considers the newer runtime as not as up-to-date. 2) Windows 8.1 SDK does not include a console build system (c.f. [1]). Thanks for pointing that out in your previous post. That page coincides with what I found in my testing. 3) The VS Community 2013 with Update 5 installation [2] includes a complete build system that works with the DMD Windows installer (tested with version 2.068.0-b2). This is what should be used with DMD now since it is free and works with the current .NET runtime. 4) The VS 2015 Community 2015 installation [2] also includes a complete build system. However, the DMD Windows installer does not recognize it and fails to update the sc.ini file accordingly. I will file a bug report shortly with details. It is taking a while to do all of the un/installs to get a relevant test environment. So I thought I would make this post about what I have found. Thought it might help with your trying to get the 068 release out the door. After I have finished my testing I will update the DMD Win64 wiki page with what is currently working. Thanks again for the help. Joseph [1] https://msdn.microsoft.com/en-us/windows/desktop/hh852363.aspx [2] https://www.visualstudio.com/en-us/downloads#d-community
Jul 29 2015
next sibling parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig rejectedsoftware.com> writes:
Am 30.07.2015 um 02:59 schrieb Joseph Cassman:
 4) The VS 2015 Community 2015 installation [2] also includes a complete
 build system. However, the DMD Windows installer does not recognize it
 and fails to update the sc.ini file accordingly. I will file a bug
 report shortly with details.
I think you have an old version of VisualD, perhaps the 0.3.38 from [1]? That just happened to me yesterday, because that page is the number one Google result and the out-of-date note is quite small. I think the dsource project should just be removed, or replaced by nothing than a single link to the new homepage [2]. [1]: http://www.dsource.org/projects/visuald [2]: http://rainers.github.io/visuald/visuald/StartPage.html
Jul 30 2015
next sibling parent reply =?UTF-8?B?U8O2bmtlIEx1ZHdpZw==?= <sludwig rejectedsoftware.com> writes:
Am 30.07.2015 um 09:49 schrieb Sönke Ludwig:
 Am 30.07.2015 um 02:59 schrieb Joseph Cassman:
 4) The VS 2015 Community 2015 installation [2] also includes a complete
 build system. However, the DMD Windows installer does not recognize it
 and fails to update the sc.ini file accordingly. I will file a bug
 report shortly with details.
I think you have an old version of VisualD, perhaps the 0.3.38 from [1]? That just happened to me yesterday, because that page is the number one Google result and the out-of-date note is quite small. I think the dsource project should just be removed, or replaced by nothing than a single link to the new homepage [2]. [1]: http://www.dsource.org/projects/visuald [2]: http://rainers.github.io/visuald/visuald/StartPage.html
Hm, I just installed VisualD on a freshly installed machine and there I get an error "libucrt.lib not found", so I probably just had some files left over from previous VS versions or SDKs.
Jul 30 2015
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 30.07.2015 11:23, Sönke Ludwig wrote:
 Am 30.07.2015 um 09:49 schrieb Sönke Ludwig:
 Am 30.07.2015 um 02:59 schrieb Joseph Cassman:
 4) The VS 2015 Community 2015 installation [2] also includes a complete
 build system. However, the DMD Windows installer does not recognize it
 and fails to update the sc.ini file accordingly. I will file a bug
 report shortly with details.
I think you have an old version of VisualD, perhaps the 0.3.38 from [1]? That just happened to me yesterday, because that page is the number one Google result and the out-of-date note is quite small. I think the dsource project should just be removed, or replaced by nothing than a single link to the new homepage [2]. [1]: http://www.dsource.org/projects/visuald [2]: http://rainers.github.io/visuald/visuald/StartPage.html
Hm, I just installed VisualD on a freshly installed machine and there I get an error "libucrt.lib not found", so I probably just had some files left over from previous VS versions or SDKs.
Are you sure it is libucrt.lib? I've never seen a library with this name (I only have a prerelease of VS2015 installed, though).
Jul 30 2015
parent reply "Joseph Cassman" <jc7919 outlook.com> writes:
On Thursday, 30 July 2015 at 18:34:28 UTC, Rainer Schuetze wrote:
 On 30.07.2015 11:23, Sönke Ludwig wrote:
 Am 30.07.2015 um 09:49 schrieb Sönke Ludwig:
 Am 30.07.2015 um 02:59 schrieb Joseph Cassman:
 4) The VS 2015 Community 2015 installation [2] also includes 
 a complete
 build system. However, the DMD Windows installer does not 
 recognize it
 and fails to update the sc.ini file accordingly. I will file 
 a bug
 report shortly with details.
I think you have an old version of VisualD, perhaps the 0.3.38 from [1]? That just happened to me yesterday, because that page is the number one Google result and the out-of-date note is quite small. I think the dsource project should just be removed, or replaced by nothing than a single link to the new homepage [2]. [1]: http://www.dsource.org/projects/visuald [2]: http://rainers.github.io/visuald/visuald/StartPage.html
Hm, I just installed VisualD on a freshly installed machine and there I get an error "libucrt.lib not found", so I probably just had some files left over from previous VS versions or SDKs.
Are you sure it is libucrt.lib? I've never seen a library with this name (I only have a prerelease of VS2015 installed, though).
Not sure if it ties in with DMD or not but a libucrt.lib missing error was one of the several errors I got when trying to use VS2015 with DMD + Win64. I do not get the error with VS2013u5 (the file exists with both installations but is only recognized for the later for some reason). Posting in case it helps isolate the issue for VisualD as well. Joseph
Jul 30 2015
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 31.07.2015 02:41, Joseph Cassman wrote:
 Not sure if it ties in with DMD or not but a libucrt.lib missing error
 was one of the several errors I got when trying to use VS2015 with DMD +
 Win64. I do not get the error with VS2013u5 (the file exists with both
 installations but is only recognized for the later for some reason).
 Posting in case it helps isolate the issue for VisualD as well.

 Joseph
I just updated my VS2015 installation and can confirm the error message regarding libucrt.lib. I found the library in the folder "c:\Program Files (x86)\Windows Kits\10\Lib\10.0.10150.0\ucrt\x64". You can add it to the library search paths in "Tools->Options->Projects and Solutions->Visual D->DMD Directories->x64". Unfortunately, that does not help a lot because Microsoft changed their C runtime quite a bit to make it more compliant to C99. This causes unresolved symbols when linking phobos.
Aug 02 2015
next sibling parent "Joseph Cassman" <jc7919 outlook.com> writes:
On Sunday, 2 August 2015 at 09:20:44 UTC, Rainer Schuetze wrote:
 On 31.07.2015 02:41, Joseph Cassman wrote:
 [...]
I just updated my VS2015 installation and can confirm the error message regarding libucrt.lib. I found the library in the folder "c:\Program Files (x86)\Windows Kits\10\Lib\10.0.10150.0\ucrt\x64". You can add it to the library search paths in "Tools->Options->Projects and Solutions->Visual D->DMD Directories->x64". Unfortunately, that does not help a lot because Microsoft changed their C runtime quite a bit to make it more compliant to C99. This causes unresolved symbols when linking phobos.
Very cool. That change to the C runtime also explains some of the errors I was getting. Thanks for the explanation. Joseph
Aug 02 2015
prev sibling parent Martin Nowak <code+news.digitalmars dawg.eu> writes:
On 08/02/2015 11:20 AM, Rainer Schuetze wrote:
 Unfortunately, that does not help a lot because Microsoft changed their
 C runtime quite a bit to make it more compliant to C99. This causes
 unresolved symbols when linking phobos.
You think we can work that out soon enough? https://issues.dlang.org/show_bug.cgi?id=14849#c7 It seems that we need to link to a certain flavor of the runtime.
Aug 03 2015
prev sibling parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 30.07.2015 09:49, Sönke Ludwig wrote:
 Am 30.07.2015 um 02:59 schrieb Joseph Cassman:
 4) The VS 2015 Community 2015 installation [2] also includes a complete
 build system. However, the DMD Windows installer does not recognize it
 and fails to update the sc.ini file accordingly. I will file a bug
 report shortly with details.
I think you have an old version of VisualD, perhaps the 0.3.38 from [1]? That just happened to me yesterday, because that page is the number one Google result and the out-of-date note is quite small. I think the dsource project should just be removed, or replaced by nothing than a single link to the new homepage [2]. [1]: http://www.dsource.org/projects/visuald [2]: http://rainers.github.io/visuald/visuald/StartPage.html
Last time I tried, I could no longer edit the dsource pages without producing completely garbled text. This happened when the dsource site was moved [1]. A single line might work, though... [1] http://forum.dlang.org/thread/jclqnnkkcbqnmehpnokv forum.dlang.org?page=3
Jul 30 2015
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 30.07.2015 20:27, Rainer Schuetze wrote:
 On 30.07.2015 09:49, Sönke Ludwig wrote:
 Am 30.07.2015 um 02:59 schrieb Joseph Cassman:
 4) The VS 2015 Community 2015 installation [2] also includes a complete
 build system. However, the DMD Windows installer does not recognize it
 and fails to update the sc.ini file accordingly. I will file a bug
 report shortly with details.
I think you have an old version of VisualD, perhaps the 0.3.38 from [1]? That just happened to me yesterday, because that page is the number one Google result and the out-of-date note is quite small. I think the dsource project should just be removed, or replaced by nothing than a single link to the new homepage [2]. [1]: http://www.dsource.org/projects/visuald [2]: http://rainers.github.io/visuald/visuald/StartPage.html
Last time I tried, I could no longer edit the dsource pages without producing completely garbled text. This happened when the dsource site was moved [1]. A single line might work, though... [1] http://forum.dlang.org/thread/jclqnnkkcbqnmehpnokv forum.dlang.org?page=3
Actually, I cannot even login now. It displays "phpBB : Critical Error Error creating new session" Vladimir, can you just clean the page and add the link to the startpage and the github repo? It seems that has been done with the cv2pdb project.
Jul 30 2015
parent reply "Vladimir Panteleev" <thecybershadow.lists gmail.com> writes:
On Thursday, 30 July 2015 at 18:42:08 UTC, Rainer Schuetze wrote:
 Vladimir, can you just clean the page and add the link to the 
 startpage and the github repo? It seems that has been done with 
 the cv2pdb project.
Done.
Jul 30 2015
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 30.07.2015 20:46, Vladimir Panteleev wrote:
 On Thursday, 30 July 2015 at 18:42:08 UTC, Rainer Schuetze wrote:
 Vladimir, can you just clean the page and add the link to the
 startpage and the github repo? It seems that has been done with the
 cv2pdb project.
Done.
That was fast. Thanks!
Jul 30 2015
parent reply "Kagamin" <spam here.lot> writes:
On Thursday, 30 July 2015 at 18:54:03 UTC, Rainer Schuetze wrote:
 That was fast. Thanks!
README in github repo still has some outdated links to dsource. Also bugzilla address is https://issues.dlang.org/
Jul 31 2015
parent Rainer Schuetze <r.sagitario gmx.de> writes:
On 31.07.2015 09:54, Kagamin wrote:
 On Thursday, 30 July 2015 at 18:54:03 UTC, Rainer Schuetze wrote:
 That was fast. Thanks!
README in github repo still has some outdated links to dsource. Also bugzilla address is https://issues.dlang.org/
I removed most dsource links (also from the documentation), but some are still valid and not available elsewhere (e.g. download links of files only found there). I didn't immediately get what you meant with the bugzilla address because it worked due to redirection. I'll update that later...
Aug 02 2015
prev sibling next sibling parent reply "Martin Nowak" <code dawg.eu> writes:
On Thursday, 30 July 2015 at 00:59:16 UTC, Joseph Cassman wrote:
 4) The VS 2015 Community 2015 installation [2] also includes a 
 complete build system. However, the DMD Windows installer does 
 not recognize it and fails to update the sc.ini file 
 accordingly. I will file a bug report shortly with details.
https://issues.dlang.org/show_bug.cgi?id=14849
Jul 30 2015
parent "Joseph Cassman" <jc7919 outlook.com> writes:
On Thursday, 30 July 2015 at 08:13:35 UTC, Martin Nowak wrote:
 On Thursday, 30 July 2015 at 00:59:16 UTC, Joseph Cassman wrote:
 4) The VS 2015 Community 2015 installation [2] also includes a 
 complete build system. However, the DMD Windows installer does 
 not recognize it and fails to update the sc.ini file 
 accordingly. I will file a bug report shortly with details.
https://issues.dlang.org/show_bug.cgi?id=14849
Nice, thanks for posting the issue. Added the sc.ini files resulting from installation test runs. Joseph
Jul 30 2015
prev sibling parent "Joseph Cassman" <jc7919 outlook.com> writes:
On Thursday, 30 July 2015 at 00:59:16 UTC, Joseph Cassman wrote:
 On Wednesday, 29 July 2015 at 07:16:39 UTC, Martin Nowak wrote:
 [...]
Martin, appreciate the help with this issue. I have investigated further and it looks like there is a work-around (item [3] below). Here is a synopsis of what I have found through testing. [...]
Updated the wiki page on DMD with what I was able to get working. http://wiki.dlang.org/Installing_DMD Joseph
Jul 30 2015
prev sibling next sibling parent "jmh530" <john.michael.hall gmail.com> writes:
On Wednesday, 29 July 2015 at 07:10:13 UTC, Martin Nowak wrote:
 You're not allowed to redistribute the VS binaries, only the 
 libc dlls.
 On Win32 we use our own libc (dmc) and linker (optlink).
 We could improve our installer so it can optionally start the 
 VS compiler installation.
If it only installed the required things, then that might be good. The whole thing though...last time I tried to install VS it took like an hour.
Jul 29 2015
prev sibling parent Rainer Schuetze <r.sagitario gmx.de> writes:
On 29.07.2015 09:10, Martin Nowak wrote:
 On Wednesday, 29 July 2015 at 01:55:35 UTC, Joseph Cassman wrote:
 There is probably an obvious reason this is not possible but I could
 not see it when reading through the MS licensing information. It seems
 to me the linker bin could be redistributed. Why is it (and the other
 required lib/dll files) not bundled with the Windows installer to make
 it one-stop-shopping?

 Seems like this is what is done with Win32.
You're not allowed to redistribute the VS binaries, only the libc dlls. On Win32 we use our own libc (dmc) and linker (optlink). We could improve our installer so it can optionally start the VS compiler installation.
Digger [1] is able to download the installers, but just extract the packages needed to link DMD built executables for win64. I'm not sure whether this is in compliance with the SDK license (you never see it or have to agree to it). [1] https://github.com/CyberShadow/Digger
Jul 30 2015
prev sibling parent reply "Kagamin" <spam here.lot> writes:
On Wednesday, 29 July 2015 at 01:55:35 UTC, Joseph Cassman wrote:
 There is probably an obvious reason this is not possible but I 
 could not see it when reading through the MS licensing 
 information. It seems to me the linker bin could be 
 redistributed.
 9. SCOPE OF LICENSE. The software is licensed, not sold. This 
 agreement only gives you some rights to use the software. 
 Microsoft reserves all other rights.
So you should find an expressly granted right to redistribute.
Jul 29 2015
parent reply "Taylor Hillegeist" <taylorh140 gmail.com> writes:
On Wednesday, 29 July 2015 at 11:56:34 UTC, Kagamin wrote:
 On Wednesday, 29 July 2015 at 01:55:35 UTC, Joseph Cassman 
 wrote:
 There is probably an obvious reason this is not possible but I 
 could not see it when reading through the MS licensing 
 information. It seems to me the linker bin could be 
 redistributed.
 9. SCOPE OF LICENSE. The software is licensed, not sold. This 
 agreement only gives you some rights to use the software. 
 Microsoft reserves all other rights.
So you should find an expressly granted right to redistribute.
Apparently Intel was able to redistribute it with their fortran compiler. Intel® Visual Fortran development environment based on Microsoft Visual Studio 2010 Shell is included with Academic and Commercial licenses for Intel® Visual Fortran. It is not included with Evaluation or Student licenses. This development environment provides everything necessary to edit, build and debug Fortran applications. Some features of the full Visual Studio product are not included, such as: Resource Editor (see ResEdit*, a third-party tool, for a substitute) Automated conversion of Compaq* Visual Fortran projects I guess what I mean to say is that they did it, maybe it can be done. Of course VS Shell is still way more than is necessary for our purposes.
Jul 29 2015
parent reply "Kagamin" <spam here.lot> writes:
On Wednesday, 29 July 2015 at 15:45:19 UTC, Taylor Hillegeist 
wrote:
 I guess what I mean to say is that they did it, maybe it can be 
 done.
Of course it can be done with an additional license agreement with microsoft.
 Of course VS Shell is still way more than is necessary for our 
 purposes.
I believe VS shell is redistributable, because it was made exactly for that.
Jul 29 2015
next sibling parent "Joseph Cassman" <jc7919 outlook.com> writes:
On Wednesday, 29 July 2015 at 18:13:22 UTC, Kagamin wrote:
 On Wednesday, 29 July 2015 at 15:45:19 UTC, Taylor Hillegeist 
 wrote:
 I guess what I mean to say is that they did it, maybe it can 
 be done.
Of course it can be done with an additional license agreement with microsoft.
 Of course VS Shell is still way more than is necessary for our 
 purposes.
I believe VS shell is redistributable, because it was made exactly for that.
Yeah, if the linker (and other relevant files) for Win64 could be licensed from MS so they could be packaged with the DMD installer that would be a sweet deal. I know D is in bootstrap mode right now but this could be one of the things that helps get it to the necessary polished phase that helps get the acceptance past the 10,000 mark. It takes a standard half-day or so to install Visual Studio. So any way to make setting up a Win64 environment faster is much appreciated. And I would feel necessary to get wide acceptance. Joseph
Jul 29 2015
prev sibling parent reply "John Colvin" <john.loughran.colvin gmail.com> writes:
On Wednesday, 29 July 2015 at 18:13:22 UTC, Kagamin wrote:
 On Wednesday, 29 July 2015 at 15:45:19 UTC, Taylor Hillegeist 
 wrote:
 I guess what I mean to say is that they did it, maybe it can 
 be done.
Of course it can be done with an additional license agreement with microsoft.
 Of course VS Shell is still way more than is necessary for our 
 purposes.
I believe VS shell is redistributable, because it was made exactly for that.
It's in the name: https://www.microsoft.com/en-us/download/details.aspx?id=46886
Jul 30 2015
parent reply "Martin Nowak" <code dawg.eu> writes:
On Thursday, 30 July 2015 at 09:24:09 UTC, John Colvin wrote:
 https://www.microsoft.com/en-us/download/details.aspx?id=46886
Does it include the C++ compiler and linker?
Aug 02 2015
next sibling parent Rainer Schuetze <r.sagitario gmx.de> writes:
On 02.08.2015 11:38, Martin Nowak wrote:
 On Thursday, 30 July 2015 at 09:24:09 UTC, John Colvin wrote:
 https://www.microsoft.com/en-us/download/details.aspx?id=46886
Does it include the C++ compiler and linker?
No, the VS shell does not include any specific language support and libraries.
Aug 02 2015
prev sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Sunday, 2 August 2015 at 09:38:23 UTC, Martin Nowak wrote:
 On Thursday, 30 July 2015 at 09:24:09 UTC, John Colvin wrote:
 https://www.microsoft.com/en-us/download/details.aspx?id=46886
Does it include the C++ compiler and linker?
I think it contains a linker, but I'm not 100% sure. See https://msdn.microsoft.com/en-us/library/bb129445.aspx for some info
Aug 02 2015