www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - DMD v2.066.0-rc1

reply Andrew Edwards <ridimz yahoo.com> writes:
DMD v2.066.0-rc1 binaries are available for testing:

     http://wiki.dlang.org/Beta_Testing
Jul 31 2014
next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 7/31/2014 5:51 AM, Andrew Edwards wrote:
 DMD v2.066.0-rc1 binaries are available for testing:

      http://wiki.dlang.org/Beta_Testing
Thank you again, Andrew!
Aug 01 2014
prev sibling next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Thursday, 31 July 2014 at 12:51:53 UTC, Andrew Edwards wrote:
 DMD v2.066.0-rc1 binaries are available for testing:

     http://wiki.dlang.org/Beta_Testing
Want to bring attention of wider audience that this release really needs all help it can get - regression count still stays high as new ones get fired after old ones are fixed and schedule is long overdue. Any help will be appreciated.
Aug 03 2014
parent reply Manu via Digitalmars-d-announce <digitalmars-d-announce puremagic.com> writes:
This windiows installer went wrong on me.
First, it tried to uninstall, it offered to uninstall from 'C:\D'. My DMD
install is 'C:\dev\D'... The path was presented in a greyed out textbox
that I couldn't type in to correct it, and no button to select the true
install location.
The uninstall step failed.

Then when reinstalling I was given the option where to install, I chose
'C:\dev\D' and it installed over the top of my existing install, and wiped
my sc.ini file. So I need to configure the DirectX SDK paths again.


Side note:
I still think the installer really should detect the DXSDK; it's a
Microsoft library, and virtually any multimedia software developed with
VS2010 or prior will depend on it (It's merged into the WinSDK since
DX2012).

The DXSDK install paths are:
Include: C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\Include
Lib: C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\Lib\x64

The "(June 2010)" part is a safe assumption, it's the last released one,
and it will remain so since it's now bundled with the WinSDK for more
recent visual studio releases. It's the only one available on the Microsoft
website.
As I see it, if we profess to support VS2010 and prior, then we should
detect the DXSDK paths in the installer, otherwise software that builds
fine in VS2012+ won't work with VS2010 without user intervention, and that
will almost certainly lead to posts on this forum.


On 4 August 2014 11:12, Dicebot via Digitalmars-d-announce <
digitalmars-d-announce puremagic.com> wrote:

 On Thursday, 31 July 2014 at 12:51:53 UTC, Andrew Edwards wrote:

 DMD v2.066.0-rc1 binaries are available for testing:

     http://wiki.dlang.org/Beta_Testing
Want to bring attention of wider audience that this release really needs all help it can get - regression count still stays high as new ones get fired after old ones are fixed and schedule is long overdue. Any help will be appreciated.
Aug 03 2014
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 8/3/2014 8:51 PM, Manu via Digitalmars-d-announce wrote:
 This windiows installer went wrong on me.
 First, it tried to uninstall, it offered to uninstall from 'C:\D'. My DMD
 install is 'C:\dev\D'... The path was presented in a greyed out textbox that I
 couldn't type in to correct it, and no button to select the true install
location.
 The uninstall step failed.

 Then when reinstalling I was given the option where to install, I chose
 'C:\dev\D' and it installed over the top of my existing install, and wiped my
 sc.ini file. So I need to configure the DirectX SDK paths again.
Please file these on bugzilla as 2 bug reports. https://issues.dlang.org/enter_bug.cgi
 Side note:
 I still think the installer really should detect the DXSDK; it's a Microsoft
 library, and virtually any multimedia software developed with VS2010 or prior
 will depend on it (It's merged into the WinSDK since DX2012).

 The DXSDK install paths are:
 Include: C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\Include
 Lib: C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\Lib\x64

 The "(June 2010)" part is a safe assumption, it's the last released one, and it
 will remain so since it's now bundled with the WinSDK for more recent visual
 studio releases. It's the only one available on the Microsoft website.
 As I see it, if we profess to support VS2010 and prior, then we should detect
 the DXSDK paths in the installer, otherwise software that builds fine in
VS2012+
 won't work with VS2010 without user intervention, and that will almost
certainly
 lead to posts on this forum.
One of the reasons I delayed so long in supporting VS is because Microsoft changes things around with every release, making trying to support whatever version the customer has is a constant configuration/testing nightmare, consuming a great deal of time and effort with little payback. With dmc, this is not a problem. As an aside, one thing I find difficult to understand is why experienced C++ developers find it so hard to set an environment variable (or one in the sc.ini) pointing to where the right .h files are and the right .lib files are. Heck, I just cribbed them from where Microsoft set them in its own command prompt shortcut "Visual Studio x64 Win64 Command Prompt (2010)". For example, clicking on the shortcut and typing "set" gives: -------------------------------------- Setting environment for using Microsoft Visual Studio 2010 x64 tools. C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC>set ALLUSERSPROFILE=C:\ProgramData CommandPromptType=Native CommonProgramFiles=C:\Program Files\Common Files CommonProgramFiles(x86)=C:\Program Files (x86)\Common Files CommonProgramW6432=C:\Program Files\Common Files ComSpec=C:\Windows\system32\cmd.exe FP_NO_HOST_CHECK=NO Framework35Version=v3.5 FrameworkDir=C:\Windows\Microsoft.NET\Framework64 FrameworkDIR64=C:\Windows\Microsoft.NET\Framework64 FrameworkVersion=v4.0.30319 FrameworkVersion64=v4.0.30319 FSHARPINSTALLDIR=C:\Program Files (x86)\Microsoft F#\v4.0\ HOMEDRIVE=C: HOMEPATH=\Users\walter INCLUDE=C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\INCLUDE;C:\Program Files (x86)\Micros oft Visual Studio 10.0\VC\ATLMFC\INCLUDE;C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include ; LIB=C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\LIB\amd64;C:\Program Files (x86)\Microsof t Visual Studio 10.0\VC\ATLMFC\LIB\amd64;C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\lib\x64 ; LIBPATH=C:\Windows\Microsoft.NET\Framework64\v4.0.30319;C:\Windows\Microsoft.NET\Framework64\v3.5;C: \Program Files (x86)\Microsoft Visual Studio 10.0\VC\LIB\amd64;C:\Program Files (x86)\Microsoft Visu al Studio 10.0\VC\ATLMFC\LIB\amd64; MEDIAMALL=C:\Program Files (x86)\MediaMall\ MOZ_PLUGIN_PATH=C:\Program Files (x86)\Foxit Software\Foxit Reader\plugins\ NUMBER_OF_PROCESSORS=6 OS=Windows_NT Path=C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\BIN\amd64;C:\Windows\Microsoft.NET\Frame work64\v4.0.30319;C:\Windows\Microsoft.NET\Framework64\v3.5;C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\VCPackages;C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE;C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\Tools;C:\Program Files (x86)\HTML Help Workshop;C: \Program Files (x86)\Microsoft SDKs\Windows\v7.0A\bin\NETFX 4.0 Tools\x64;C:\Program Files (x86)\Mic rosoft SDKs\Windows\v7.0A\bin\x64;C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\bin;C:\Program Files\Common Files\Microsoft Shared\Windows Live;C:\Program Files (x86)\Common Files\Microsoft Shar ed\Windows Live;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsP owerShell\v1.0\;C:\Program Files (x86)\Microsoft SQL Server\100\Tools\Binn\;C:\Program Files\Microso ft SQL Server\100\Tools\Binn\;C:\Program Files\Microsoft SQL Server\100\DTS\Binn\;C:\Program Files ( x86)\Windows Live\Shared PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC Platform=X64 PROCESSOR_ARCHITECTURE=AMD64 PROCESSOR_IDENTIFIER=AMD64 Family 21 Model 1 Stepping 2, AuthenticAMD PROCESSOR_LEVEL=21 PROCESSOR_REVISION=0102 ProgramData=C:\ProgramData ProgramFiles=C:\Program Files ProgramFiles(x86)=C:\Program Files (x86) ProgramW6432=C:\Program Files PROMPT=$P$G PSModulePath=C:\Windows\system32\WindowsPowerShell\v1.0\Modules\ PUBLIC=C:\Users\Public SESSIONNAME=Console SystemDrive=C: SystemRoot=C:\Windows VCINSTALLDIR=C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\ VS100COMNTOOLS=C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\Tools\ VSINSTALLDIR=C:\Program Files (x86)\Microsoft Visual Studio 10.0\ windir=C:\Windows WindowsSdkDir=C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\ windows_tracing_flags=3 windows_tracing_logfile=C:\BVTBin\Tests\installpackage\csilogfile.log C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC> ---------------------------------- There's VCINSTALLDIR and WindowsSdkDir and INCLUDE and LIBPATH
Aug 05 2014
next sibling parent Manu via Digitalmars-d-announce <digitalmars-d-announce puremagic.com> writes:
On 6 August 2014 15:20, Walter Bright via Digitalmars-d-announce <
digitalmars-d-announce puremagic.com> wrote:

 On 8/3/2014 8:51 PM, Manu via Digitalmars-d-announce wrote:

 This windiows installer went wrong on me.
 First, it tried to uninstall, it offered to uninstall from 'C:\D'. My DMD
 install is 'C:\dev\D'... The path was presented in a greyed out textbox
 that I
 couldn't type in to correct it, and no button to select the true install
 location.
 The uninstall step failed.

 Then when reinstalling I was given the option where to install, I chose
 'C:\dev\D' and it installed over the top of my existing install, and
 wiped my
 sc.ini file. So I need to configure the DirectX SDK paths again.
Please file these on bugzilla as 2 bug reports. https://issues.dlang.org/enter_bug.cgi
Yup, there's already been listings and related discussions. As an aside, one thing I find difficult to understand is why experienced
 C++ developers find it so hard to set an environment variable (or one in
 the sc.ini) pointing to where the right .h files are and the right .lib
 files are.
There is %DXSDK_DIR%, which is fine to use. I've been discussing it with Brad on the bug tracker.
Aug 06 2014
prev sibling parent reply "Brad Anderson" <eco gnuk.net> writes:
On Wednesday, 6 August 2014 at 05:20:27 UTC, Walter Bright wrote:
 On 8/3/2014 8:51 PM, Manu via Digitalmars-d-announce wrote:
 This windiows installer went wrong on me.
 First, it tried to uninstall, it offered to uninstall from 
 'C:\D'. My DMD
 install is 'C:\dev\D'... The path was presented in a greyed 
 out textbox that I
 couldn't type in to correct it, and no button to select the 
 true install location.
 The uninstall step failed.

 Then when reinstalling I was given the option where to 
 install, I chose
 'C:\dev\D' and it installed over the top of my existing 
 install, and wiped my
 sc.ini file. So I need to configure the DirectX SDK paths 
 again.
Please file these on bugzilla as 2 bug reports. https://issues.dlang.org/enter_bug.cgi
 Side note:
 I still think the installer really should detect the DXSDK; 
 it's a Microsoft
 library, and virtually any multimedia software developed with 
 VS2010 or prior
 will depend on it (It's merged into the WinSDK since DX2012).

 The DXSDK install paths are:
 Include: C:\Program Files (x86)\Microsoft DirectX SDK (June 
 2010)\Include
 Lib: C:\Program Files (x86)\Microsoft DirectX SDK (June 
 2010)\Lib\x64

 The "(June 2010)" part is a safe assumption, it's the last 
 released one, and it
 will remain so since it's now bundled with the WinSDK for more 
 recent visual
 studio releases. It's the only one available on the Microsoft 
 website.
 As I see it, if we profess to support VS2010 and prior, then 
 we should detect
 the DXSDK paths in the installer, otherwise software that 
 builds fine in VS2012+
 won't work with VS2010 without user intervention, and that 
 will almost certainly
 lead to posts on this forum.
One of the reasons I delayed so long in supporting VS is because Microsoft changes things around with every release, making trying to support whatever version the customer has is a constant configuration/testing nightmare, consuming a great deal of time and effort with little payback. With dmc, this is not a problem. As an aside, one thing I find difficult to understand is why experienced C++ developers find it so hard to set an environment variable (or one in the sc.ini) pointing to where the right .h files are and the right .lib files are.
I don't think it's difficult for them, I think they often just don't know they can. Environment variables just aren't as well known on Windows these days. If you are an 18 year old getting into programming you likely have never even heard of environment variables or batch files and may not even know how to use the command prompt (or open it for that matter). Windows Vista came out when they were 10 years old and the days of having to know and use the command prompt for typical users were long gone by this point. I'm thirty so I knew and used MS-DOS as a kid (I had to) but if you've never used these things how would you know you could? Even if you are an experienced programmer having used Visual Studio or some other IDE for years you'd likely not have had to adjust environment variables to get anything to work. Manu knows these things, of course, but his it-should-just-work complaints probably go a long way to helping people who don't know these things.
 Heck, I just cribbed them from where Microsoft set them in its 
 own command prompt shortcut "Visual Studio x64 Win64 Command 
 Prompt (2010)". For example, clicking on the shortcut and 
 typing "set" gives:

 [...]
I added the same style of command prompt for DMD to the installer a couple years ago. One for 64-bit and one for 32-bit.
Aug 06 2014
parent reply "Kagamin" <spam here.lot> writes:
On Wednesday, 6 August 2014 at 16:19:39 UTC, Brad Anderson wrote:
 I don't think it's difficult for them, I think they often just 
 don't know they can. Environment variables just aren't as well 
 known on Windows these days. If you are an 18 year old getting 
 into programming you likely have never even heard of 
 environment variables or batch files and may not even know how 
 to use the command prompt (or open it for that matter). Windows 
 Vista came out when they were 10 years old and the days of 
 having to know and use the command prompt for typical users 
 were long gone by this point. I'm thirty so I knew and used 
 MS-DOS as a kid (I had to) but if you've never used these 
 things how would you know you could?
There are OS courses at institutes, where you have linux, gcc and learn, how pipes, shared memory and synchronization mechanisms work.
Aug 07 2014
next sibling parent "Meta" <jared771 gmail.com> writes:
On Thursday, 7 August 2014 at 11:30:19 UTC, Kagamin wrote:
 On Wednesday, 6 August 2014 at 16:19:39 UTC, Brad Anderson 
 wrote:
 I don't think it's difficult for them, I think they often just 
 don't know they can. Environment variables just aren't as well 
 known on Windows these days. If you are an 18 year old getting 
 into programming you likely have never even heard of 
 environment variables or batch files and may not even know how 
 to use the command prompt (or open it for that matter). 
 Windows Vista came out when they were 10 years old and the 
 days of having to know and use the command prompt for typical 
 users were long gone by this point. I'm thirty so I knew and 
 used MS-DOS as a kid (I had to) but if you've never used these 
 things how would you know you could?
There are OS courses at institutes, where you have linux, gcc and learn, how pipes, shared memory and synchronization mechanisms work.
These are just broad overview courses that barely scratch the surface. A 4 month course can barely teach you anything about such a broad topic.
Aug 07 2014
prev sibling parent reply Manu via Digitalmars-d-announce <digitalmars-d-announce puremagic.com> writes:
On 7 August 2014 21:30, Kagamin via Digitalmars-d-announce <
digitalmars-d-announce puremagic.com> wrote:

 On Wednesday, 6 August 2014 at 16:19:39 UTC, Brad Anderson wrote:

 I don't think it's difficult for them, I think they often just don't know
 they can. Environment variables just aren't as well known on Windows these
 days. If you are an 18 year old getting into programming you likely have
 never even heard of environment variables or batch files and may not even
 know how to use the command prompt (or open it for that matter). Windows
 Vista came out when they were 10 years old and the days of having to know
 and use the command prompt for typical users were long gone by this point.
 I'm thirty so I knew and used MS-DOS as a kid (I had to) but if you've
 never used these things how would you know you could?
There are OS courses at institutes, where you have linux, gcc and learn, how pipes, shared memory and synchronization mechanisms work.
It's not because it's hard, it's because it's perceived as totally backwards, and it undermines the trust in the ecosystem. It's all about perception. The Windows/Visual Studio development culture is pretty immature, and expects nothing less than the level of polish and presentation that Microsoft put into Visual Studio. I have direct experience with hundreds of these sorts of developers. The prevailing opinion is that Linux is rubbish for nerds, and if the ecosystem presents itself in that style, it won't be taken seriously. You can't gain the confidence of this community of developers unless you appeal to them on their terms. First impressions and basic presentation are extremely important to perception. I think configuration friction in particular is extremely important to eliminate; you are dealing with someone whose investment in D can be measured in seconds, probably knows absolutely nothing about the ecosystem technically, and is not yet sure if they even want to. Any friction between them and a helpful little wizard that generates a hello world project for them so they can start hacking about and see how it feels may quite possibly dismiss it on contact.
Aug 07 2014
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Thursday, 7 August 2014 at 15:35:11 UTC, Manu via 
Digitalmars-d-announce wrote:
 The Windows/Visual Studio development culture is pretty 
 immature, and
 expects nothing less than the level of polish and presentation 
 that
 Microsoft put into Visual Studio.
I have no idea how one can call one shitty program that can't even install itself to "just work" as polished (reference to http://forum.dlang.org/post/xwfpcuavpdpwmvnbndmt forum.dlang.org)
Aug 07 2014
parent reply Manu via Digitalmars-d-announce <digitalmars-d-announce puremagic.com> writes:
On 8 August 2014 01:41, Dicebot via Digitalmars-d-announce <
digitalmars-d-announce puremagic.com> wrote:

 On Thursday, 7 August 2014 at 15:35:11 UTC, Manu via
 Digitalmars-d-announce wrote:

 The Windows/Visual Studio development culture is pretty immature, and
 expects nothing less than the level of polish and presentation that
 Microsoft put into Visual Studio.
I have no idea how one can call one shitty program that can't even install itself to "just work" as polished (reference to http://forum.dlang.org/post/xwfpcuavpdpwmvnbndmt forum. dlang.org)
Umm, I don't know what you're talking about exactly. But let me get this straight, it looks like you're saying you are annoyed that it didn't 'just work' out of the box? :P But regardless, you're talking about `make -f win64.mak`, which suggests that you're clearly not a windows/visual studio developer, and therefore wouldn't understand ;) You're meant to open the .sln file and press the build button...
Aug 07 2014
parent reply "Dicebot" <public dicebot.lv> writes:
On Thursday, 7 August 2014 at 16:53:57 UTC, Manu via 
Digitalmars-d-announce wrote:
 Umm, I don't know what you're talking about exactly. But let me 
 get this
 straight, it looks like you're saying you are annoyed that it 
 didn't 'just
 work' out of the box? :P
Yeah this is the inly compiler I have used so far where you can't just type `cl.exe helloworld.c` after installation and expect it to not crash - with an intention that you must use special environment wrapper before that is never mentioned to you during installation.
 You're meant to open the .sln file and press the build button...
I'll tell my scripts next time that all they need is to press a build button, yeah
Aug 07 2014
parent reply Manu via Digitalmars-d-announce <digitalmars-d-announce puremagic.com> writes:
On 8 August 2014 02:57, Dicebot via Digitalmars-d-announce <
digitalmars-d-announce puremagic.com> wrote:

 On Thursday, 7 August 2014 at 16:53:57 UTC, Manu via
 Digitalmars-d-announce wrote:

 Umm, I don't know what you're talking about exactly. But let me get this
 straight, it looks like you're saying you are annoyed that it didn't 'just
 work' out of the box? :P
Yeah this is the inly compiler I have used so far where you can't just type `cl.exe helloworld.c` after installation and expect it to not crash - with an intention that you must use special environment wrapper before that is never mentioned to you during installation.
Yeah, the first I ever became aware about that environment script was when Walter pointed it out to me a few years ago. I've never encountered anybody try and use MSC from the command line in about 15 years professionally. That's what I mean about this culture; it's the opposite of linux, and it outright rejects practises that are linux-like. You're meant to open the .sln file and press the build button...

 I'll tell my scripts next time that all they need is to press a build
 button, yeah
What's a script? Is that related to the command prompt? We left that behind in Windows95... ;)
Aug 07 2014
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
On Thursday, 7 August 2014 at 17:05:29 UTC, Manu via 
Digitalmars-d-announce wrote:
 On 8 August 2014 02:57, Dicebot via Digitalmars-d-announce <
 digitalmars-d-announce puremagic.com> wrote:

 On Thursday, 7 August 2014 at 16:53:57 UTC, Manu via
 Digitalmars-d-announce wrote:

 Umm, I don't know what you're talking about exactly. But let 
 me get this
 straight, it looks like you're saying you are annoyed that it 
 didn't 'just
 work' out of the box? :P
Yeah this is the inly compiler I have used so far where you can't just type `cl.exe helloworld.c` after installation and expect it to not crash - with an intention that you must use special environment wrapper before that is never mentioned to you during installation.
Yeah, the first I ever became aware about that environment script was when Walter pointed it out to me a few years ago. I've never encountered anybody try and use MSC from the command line in about 15 years professionally. That's what I mean about this culture; it's the opposite of linux, and it outright rejects practises that are linux-like.
well I don't mind that habits are totally different - but the fact that it is considered an excuse for distributing broken programs (and cl.exe is broken by most basic software usability principles) is frustrating at least. "Polishing" means exactly paying attention to details like that, making sure that features on one uses still work when stumbled upon. And making your GUI even more fancy is, well, making you GUI fancy. Nothing to do with polishing.
 I'll tell my scripts next time that all they need is to press 
 a build
 button, yeah
What's a script? Is that related to the command prompt? We left that behind in Windows95... ;)
Yeah you know those old school things that allow us to spend time on something actually useful instead of pressing buttons ;)
Aug 07 2014
parent reply "Dicebot" <public dicebot.lv> writes:
On Thursday, 7 August 2014 at 17:11:23 UTC, Dicebot wrote:
 well I don't mind that habits are totally different - but the 
 fact that it is considered an excuse for distributing broken 
 programs (and cl.exe is broken by most basic software usability 
 principles) is frustrating at least. "Polishing" means exactly 
 paying attention to details like that, making sure that 
 features on one uses still work when stumbled upon. And making 
 your GUI even more fancy is, well, making you GUI fancy. 
 Nothing to do with polishing.
And here I also mean that all other Windows builds of compilers / interpreters I have used / tried passed that simple sanity test. Some may require complicated setup to do complicated things but "hello world" is always just that simple. Microsoft seems to be the only company who can afford doing things like that with users and expect them to suck it >_<
Aug 07 2014
parent reply Jacob Carlborg <doob me.com> writes:
On 2014-08-07 19:15, Dicebot wrote:

 And here I also mean that all other Windows builds of compilers /
 interpreters I have used / tried passed that simple sanity test. Some
 may require complicated setup to do complicated things but "hello world"
 is always just that simple.

 Microsoft seems to be the only company who can afford doing things like
 that with users and expect them to suck it >_<
On OS X both work well. You can either just press "the button" or use the command line, assuming you have installed the command line tools. -- /Jacob Carlborg
Aug 07 2014
parent "Joakim" <dlang joakim.airpost.net> writes:
On Thursday, 7 August 2014 at 19:15:00 UTC, Jacob Carlborg wrote:
 On 2014-08-07 19:15, Dicebot wrote:

 And here I also mean that all other Windows builds of 
 compilers /
 interpreters I have used / tried passed that simple sanity 
 test. Some
 may require complicated setup to do complicated things but 
 "hello world"
 is always just that simple.

 Microsoft seems to be the only company who can afford doing 
 things like
 that with users and expect them to suck it >_<
On OS X both work well. You can either just press "the button" or use the command line, assuming you have installed the command line tools.
This is kind of why I picked up a Powerbook a decade ago, to be able to use the command-line and Unix and still have multimedia work well (linux/BSD audio/video have made major strides since then). Then, among other reasons, I found out that Apple is using that money for stuff like this, and that's the first and last Apple product I ever bought: http://www.cnet.com/news/us-patent-office-rejects-apple-autocomplete-patent-used-against-samsung/
Aug 08 2014
prev sibling next sibling parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, 7 August 2014 at 17:05:29 UTC, Manu via 
Digitalmars-d-announce wrote:
 I've never encountered anybody try and use MSC from the command 
 line in about 15 years professionally.
LOL. That's almost always how I use VS when I'm forced to use it at work. As soon as I figured out that I could build from the command line using VS, I stopped opening it unless I had to in order to run the debugger. But I'm not even vaguely a typical Windows developer. I'm pretty hardcore Linux, all things considered. - Jonathan M Davis
Aug 07 2014
next sibling parent Timothee Cour via Digitalmars-d-announce writes:
On Thu, Aug 7, 2014 at 11:11 AM, Jonathan M Davis via
Digitalmars-d-announce <digitalmars-d-announce puremagic.com> wrote:

 On Thursday, 7 August 2014 at 17:05:29 UTC, Manu via
 Digitalmars-d-announce wrote:

 I've never encountered anybody try and use MSC from the command line in
 about 15 years professionally.
LOL. That's almost always how I use VS when I'm forced to use it at work. As soon as I figured out that I could build from the command line using VS, I stopped opening it unless I had to in order to run the debugger. But I'm not even vaguely a typical Windows developer. I'm pretty hardcore Linux, all things considered. - Jonathan M Davis
Likewise, when I had to use windows and VS (for visualD+other stuff), running from command line was the only way I could find to execute my scripts, set appropriate environment variables etc, without having to spend time every time something changed clicking through options (which is terrible in most IDEs including VS). Command line saves time every time you have to do a task more than once, administer different machines etc.
Aug 12 2014
prev sibling parent Manu via Digitalmars-d-announce <digitalmars-d-announce puremagic.com> writes:
On 13 August 2014 12:15, Timothee Cour via Digitalmars-d-announce <
digitalmars-d-announce puremagic.com> wrote:

 On Thu, Aug 7, 2014 at 11:11 AM, Jonathan M Davis via
 Digitalmars-d-announce <digitalmars-d-announce puremagic.com> wrote:

 On Thursday, 7 August 2014 at 17:05:29 UTC, Manu via
 Digitalmars-d-announce wrote:

 I've never encountered anybody try and use MSC from the command line in
 about 15 years professionally.
LOL. That's almost always how I use VS when I'm forced to use it at work. As soon as I figured out that I could build from the command line using VS, I stopped opening it unless I had to in order to run the debugger. But I'm not even vaguely a typical Windows developer. I'm pretty hardcore Linux, all things considered. - Jonathan M Davis
Likewise, when I had to use windows and VS (for visualD+other stuff), running from command line was the only way I could find to execute my scripts, set appropriate environment variables etc, without having to spend time every time something changed clicking through options (which is terrible in most IDEs including VS). Command line saves time every time you have to do a task more than once, administer different machines etc.
It sounds like there's a high chance you don't know how to use Visual Studio very well...
Aug 13 2014
prev sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 8/7/2014 1:05 PM, Manu via Digitalmars-d-announce wrote:
 I've never encountered anybody try and use MSC from the command line in
 about 15 years professionally.
I've tried to. When using Marmalade. Marmalade's mandatory build system is very closed-off and VS-integrated, so when I needed to include other stuff into my workflow (forget exactly why/what), I had to invoke from a script. And it worked *very* poorly. The fact that so few people use VS from the cmd line could partly be *because* it works so poorly: Ex 1: There's a lot of apple fans who have rationalized all sorts of limitations as "good", or at least acceptable, long as the apple didn't support them. Then the moment apple would offer it, suddenly it'd be hailed as the greatest thing since sliced bread. Ex 2: Linux users rarely use GUI file managers. I love GUI file managers, but when I'm on Linux, I find even I do a lot more of my file management on the cmdline than I normally would. I do that *because* linux file managers tend to be pretty bad (esp the Nautilus-based ones IMO). So I'm not surprised other Linux users aren't really into GUI file managers either. We could be seeing a similar thing here. Something is shunned as "bad" *because* that particular world's version of it is very poorly done or otherwise unavailable.
 That's what I mean about this culture; it's
 the opposite of linux, and it outright rejects practises that are
 linux-like.
While I don't doubt that's true of a lot of people in the industry, I have to question how much stubbornly clinging to ignorance can really count as a "culture". I'm tempted to claim that isn't culture at all, it's just pandemic pigheaded ignorance.
Aug 14 2014
next sibling parent "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Thursday, 14 August 2014 at 19:14:32 UTC, Nick Sabalausky 
wrote:
 On 8/7/2014 1:05 PM, Manu via Digitalmars-d-announce wrote:
 That's what I mean about this culture; it's
 the opposite of linux, and it outright rejects practises that 
 are
 linux-like.
While I don't doubt that's true of a lot of people in the industry, I have to question how much stubbornly clinging to ignorance can really count as a "culture". I'm tempted to claim that isn't culture at all, it's just pandemic pigheaded ignorance.
Somehow, I doubt that anyone claims that you pull your punches or that you don't speek your mind... :) - Jonathan M Davis
Aug 14 2014
prev sibling parent Manu via Digitalmars-d-announce <digitalmars-d-announce puremagic.com> writes:
On 15 August 2014 05:14, Nick Sabalausky via Digitalmars-d-announce <
digitalmars-d-announce puremagic.com> wrote:

 On 8/7/2014 1:05 PM, Manu via Digitalmars-d-announce wrote:

 I've never encountered anybody try and use MSC from the command line in
 about 15 years professionally.
I've tried to. When using Marmalade. Marmalade's mandatory build system is very closed-off and VS-integrated, so when I needed to include other stuff into my workflow (forget exactly why/what), I had to invoke from a script. And it worked *very* poorly. The fact that so few people use VS from the cmd line could partly be *because* it works so poorly: Ex 1: There's a lot of apple fans who have rationalized all sorts of limitations as "good", or at least acceptable, long as the apple didn't support them. Then the moment apple would offer it, suddenly it'd be hailed as the greatest thing since sliced bread. Ex 2: Linux users rarely use GUI file managers. I love GUI file managers, but when I'm on Linux, I find even I do a lot more of my file management on the cmdline than I normally would. I do that *because* linux file managers tend to be pretty bad (esp the Nautilus-based ones IMO). So I'm not surprised other Linux users aren't really into GUI file managers either. We could be seeing a similar thing here. Something is shunned as "bad" *because* that particular world's version of it is very poorly done or otherwise unavailable. That's what I mean about this culture; it's
 the opposite of linux, and it outright rejects practises that are
 linux-like.
While I don't doubt that's true of a lot of people in the industry, I have to question how much stubbornly clinging to ignorance can really count as a "culture". I'm tempted to claim that isn't culture at all, it's just pandemic pigheaded ignorance.
It is what it is... I'm just making an argument for the importance of the seamlessness of the download -> "hello world" experience. There's a large number of developers who find this to be a sign of quality, and they will pre-judge accordingly. You won't win these people over by telling them the reality of their condition ;)
Aug 15 2014
prev sibling parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 8/7/2014 11:34 AM, Manu via Digitalmars-d-announce wrote:
 It's not because it's hard, it's because it's perceived as totally
 backwards, and it undermines the trust in the ecosystem. It's all about
 perception.

 The Windows/Visual Studio development culture is pretty immature, and
 expects nothing less than the level of polish and presentation that
 Microsoft put into Visual Studio.
 I have direct experience with hundreds of these sorts of developers. The
 prevailing opinion is that Linux is rubbish for nerds, and if the ecosystem
 presents itself in that style, it won't be taken seriously. You can't gain
 the confidence of this community of developers unless you appeal to them on
 their terms. First impressions and basic presentation are extremely
 important to perception.
 I think configuration friction in particular is extremely important to
 eliminate; you are dealing with someone whose investment in D can be
 measured in seconds, probably knows absolutely nothing about the ecosystem
 technically, and is not yet sure if they even want to. Any friction between
 them and a helpful little wizard that generates a hello world project for
 them so they can start hacking about and see how it feels may quite
 possibly dismiss it on contact.
While I (unfortunately) agree with everything you've said here, I can't help chiming in with one thing: Speaking as a programmer who's primarily used Windows ever since 3.1, anyone who earns a paycheck writing code *and* believes "Linux is rubbish for nerds"[1], needs to grow the fuck up, both professionally and intellectually. It's absolutely no different from a grown adult being a console fanboy. It's just pathetic and completely inexcusable for any so-called "professional". [1] And you're right, such people *do* (inexplicably) exist. I've known some.
Aug 09 2014
parent reply "Dicebot" <public dicebot.lv> writes:
On Saturday, 9 August 2014 at 14:24:41 UTC, Nick Sabalausky wrote:
 While I (unfortunately) agree with everything you've said here, 
 I can't help chiming in with one thing: Speaking as a 
 programmer who's primarily used Windows ever since 3.1, anyone 
 who earns a paycheck writing code *and* believes "Linux is 
 rubbish for nerds"[1], needs to grow the fuck up, both 
 professionally and intellectually. It's absolutely no different 
 from a grown adult being a console fanboy. It's just pathetic 
 and completely inexcusable for any so-called "professional".

 [1] And you're right, such people *do* (inexplicably) exist. 
 I've known some.
People take surprising pride in praising own ignorance and any philosophy that justifies such ignorance. When I started doing commercial programming after some years of open-source and hobby experiments biggest cultural shock was that many of my colleagues actually avoided learning anything out of the default comfort zone and called that _professional attitude_. To take it from common holywar path : my rant was not about GUI vs console either, but about the fact that they distribute some programs that die with meaningless error unless certain system paths are manually specified. This is a terrible approach - I can't imagine any program installed via standard OS tools to act that way and not consider it a bug. Even majority of Windows programs I remember using were more responsible in that regard.
Aug 09 2014
parent reply Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 8/9/2014 10:57 AM, Dicebot wrote:
 actually avoided learning anything out of the default comfort zone and
 called that _professional attitude_.
People have some truly bizarre ideas about what constitutes professionalism. At a previous job I had, at one particular developer's meeting with one of the brass (it was a weekly meeting that primarily served to make this particular manager/co-owner feel like she was being useful - not that she ever was - by sticking her fingers where they didn't belong), by pure chance all the developers happened to be wearing shirts with collars. The manager made a big point about how happy she was to see that because (paraphrasing here) "shirt collars are professional". Yea, forget competence, skill, ability, work ethic, demeanor...no, apparently "professionalism" involves..."shirt collars". Idiot. That's not the only example of clothing-based naivety I've seen among people who *should* know better: It's truly disturbing how many businesspeople can be trivially fooled into thinking any old random con artist is a trustworthy professional, simply by the con artist walking into any dept store and buying a suit to wear. "Oh, I see he's wearing a suit. That means he must be very professional!" People are morons.
Aug 11 2014
parent reply "Jonathan M Davis" <jmdavisProg gmx.com> writes:
On Monday, 11 August 2014 at 16:29:10 UTC, Nick Sabalausky wrote:
 On 8/9/2014 10:57 AM, Dicebot wrote:
 actually avoided learning anything out of the default comfort 
 zone and
 called that _professional attitude_.
People have some truly bizarre ideas about what constitutes professionalism. At a previous job I had, at one particular developer's meeting with one of the brass (it was a weekly meeting that primarily served to make this particular manager/co-owner feel like she was being useful - not that she ever was - by sticking her fingers where they didn't belong), by pure chance all the developers happened to be wearing shirts with collars. The manager made a big point about how happy she was to see that because (paraphrasing here) "shirt collars are professional". Yea, forget competence, skill, ability, work ethic, demeanor...no, apparently "professionalism" involves..."shirt collars". Idiot. That's not the only example of clothing-based naivety I've seen among people who *should* know better: It's truly disturbing how many businesspeople can be trivially fooled into thinking any old random con artist is a trustworthy professional, simply by the con artist walking into any dept store and buying a suit to wear. "Oh, I see he's wearing a suit. That means he must be very professional!" People are morons.
The sad reality is that your physical appearance - including your clothing - can have a big impact on how people perceive you, so in many situations, wearing nicer clothing can have a definite impact. This is particularly true when dealing with stuff like sales where you're constantly having to deal with new people. That's not to say that clothing makes the man, but impressions like that can matter, even if it seems like they shouldn't. So, it makes a lot of sense for some folks to wear nicer clothes - or "professional" clothes - as part of their job. However, for engineers, it's ridiculous. We shouldn't normally be interacting with anyone where it would matter. So, attire like t-shirt and jeans should be fine. Our clothing should have little impact on our job. And in most cases, if an engineering manager is pushing for that sort of thing, I think that it's a very bad sign. - Jonathan M Davis
Aug 11 2014
parent Nick Sabalausky <SeeWebsiteToContactMe semitwist.com> writes:
On 8/11/2014 3:55 PM, Jonathan M Davis wrote:
 The sad reality is that your physical appearance - including your
 clothing - can have a big impact on how people perceive you, so in many
 situations, wearing nicer clothing can have a definite impact. This is
 particularly true when dealing with stuff like sales where you're
 constantly having to deal with new people. That's not to say that
 clothing makes the man, but impressions like that can matter, even if it
 seems like they shouldn't. So, it makes a lot of sense for some folks to
 wear nicer clothes - or "professional" clothes - as part of their job.
 However, for engineers, it's ridiculous. We shouldn't normally be
 interacting with anyone where it would matter. So, attire like t-shirt
 and jeans should be fine. Our clothing should have little impact on our
 job. And in most cases, if an engineering manager is pushing for that
 sort of thing, I think that it's a very bad sign.
Yea, various things about appearance definitely have a subconscious effect on perception. That's a fairly deeply ingrained part of human nature, unfortunate as it may be. But what really gets me is when people have it as a fully *conscious* belief, not just subconscious. Then my "WTF" meter just redlines.
Aug 12 2014
prev sibling parent reply "Maxim Fomin" <maxim-fomin outlook.com> writes:
On Thursday, 31 July 2014 at 12:51:53 UTC, Andrew Edwards wrote:
 DMD v2.066.0-rc1 binaries are available for testing:

     http://wiki.dlang.org/Beta_Testing
What about changelog? http://dlang.org/changelog.html In past it was pretty nicely made, but now it lists only 2 changes (unlike 2.065 and 2.064 comprehensive changelogs and judging by how much time passed since 2.065 it should be lengthy too).
Aug 09 2014
parent "Brad Anderson" <eco gnuk.net> writes:
On Saturday, 9 August 2014 at 15:35:08 UTC, Maxim Fomin wrote:
 On Thursday, 31 July 2014 at 12:51:53 UTC, Andrew Edwards wrote:
 DMD v2.066.0-rc1 binaries are available for testing:

    http://wiki.dlang.org/Beta_Testing
What about changelog? http://dlang.org/changelog.html In past it was pretty nicely made, but now it lists only 2 changes (unlike 2.065 and 2.064 comprehensive changelogs and judging by how much time passed since 2.065 it should be lengthy too).
Kenji has an open pull request to flesh it out a bit more. https://github.com/D-Programming-Language/dlang.org/pull/616 Still not nearly as good as when Andrej had time to do it.
Aug 09 2014