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