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

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