On Sunday, 1 September 2013 at 13:20:50 UTC, Manu wrote:
> Why complicate the issue? What's wrong with readable code?

Well, the fact is, AFAIK, it's never been an issue for C# and Java programmers. In fact, it' the first time I hear about people complaining on this one. Maybe because of the generalized usage of IDEs, I guess.

I do agree that IDEs DO matter. It really does make a monumental difference. Without them, Java and C# programming would be a chore. But with them, you are often more productive than in Python (opinion based on my own professionnal experience). The problem is, maintaining one or several IDE plugins is going to be nearly a full-time job, even if the compiler is a library. Or you need a very motivated person like Iain Buclain to keep updating the tools.

I think at this point, what D needs is a bit of commercial support from a company like JetBrains or some equivalent. Maybe there is now an opportunity for founding such a company, one that would specialize in building professional tools around the D language. I believe the language and the compilers are stable enough to grow a serious business around them. If we compare to what the state of C++ compilers was before 2000, I believe we are much better off. And that was just over a decade ago. Who knows what the state of D will be in 5 years ? So yes, there is a case to be made for growing a company around pro D tools, and the first company that does it will grab the whole market.

On 9/1/2013 11:01 AM, Dmitry Olshansky wrote:
> The only one I see is
> VS110COMNTOOLS

Very strange. When I click on the shortcut "Visual Studio x64 Win64..." to open a command prompt, it sets a veritable blizzard of environment variables.

> that was defined to
> C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\Tools\
>
> What currently works for me is:
> [Environment64]
> PATH=C:\"Program Files (x86)"\"Microsoft Visual Studio 11.0"\Common7\IDE;%PATH%
> LIB=C:\"Program Files (x86)"\"Windows Kits"\8.0\Lib\win8\um\x64;C:\"Program
> Files (x86)"\"Microsoft Visual Studio 11.0"\VC\lib\amd64;"%@P%\..\lib"
> WindowsSdkDir=
> LINKCMD64=C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\bin\amd64\link.exe

I'm quite sure that VS20?? sets an environment variable for "Windows Kits" somewhere.

> There are 2 distinct things - libraries are ound in Platform SDK (or rather
> WindowsSDK these days) and version 8 differs from 7. You can download and
> install it (any version) - it's a free download.
> Compiler/linkers are installed to VisualStudio and are dealt with separately.
>
> I still have this error when trying to comompile with debug info:
>
> LINK : fatal error LNK1101: incorrect MSPDB110.DLL version; recheck installation
> of this product
>
> No idea whose fault is it (DMD vs MS linker vs something in my paths/env).

DMD does not load any DLLs.

> + I have to redefine everything in order to compile phobos/druntime as these are
> hardcoded to VS10 (again !) thus I don't usually test/build x64 Phobos. It's far
> less hassle for me to keep around x64 Linux virtual box for testing.

When I compile phobos, for example, I use the following makefile (named "makefile"). It is very handy for resetting the environment variables used by win32.mak.

--------------
# Makefile to build D runtime library phobos.lib for Win32
# Designed to work with \dm\bin\make.exe

DIR=\dmd2

#DMD=$(DIR)\windows\bin\dmd
DMD=..\dmd

#DOC=..\..\html\d\phobos
DOC=..\doc\phobos

STDDOC=std.ddoc

DRUNTIME=..\druntime

MODEL=32

MACS=DMD=$(DMD) DOC=$(DOC) STDDOC=$(STDDOC) DIR=$(DIR) DRUNTIME=$(DRUNTIME)

targets :
        make -fwin$(MODEL).mak $(MACS)

test :
        make -fwin$(MODEL).mak $(MACS) test

unittest :
        make -fwin$(MODEL).mak $(MACS) unittest

cov :
        make -fwin$(MODEL).mak $(MACS) cov

clean :
        make -fwin$(MODEL).mak $(MACS) clean

html :
        make -fwin$(MODEL).mak $(MACS) html

cleanhtml:
        make -fwin$(MODEL).mak $(MACS) cleanhtml

zip :
        make -fwin$(MODEL).mak $(MACS) zip

install :
        make -fwin$(MODEL).mak $(MACS) install

cov :
        make -fwin$(MODEL).mak $(MACS) cov

time :
        make -fwin$(MODEL).mak $(MACS) clean
        timer make -fwin$(MODEL).mak $(MACS)

On Sun, 01 Sep 2013 19:14:11 +0200, eles <eles@eles.com> wrote:

> On Sunday, 1 September 2013 at 14:32:18 UTC, Manu wrote:
>> On 1 September 2013 19:57, Jacob Carlborg <doob@me.com> wrote:
>>
>>> On 2013-09-01 04:05, Manu wrote:
>>
>> I've never met a C++ developer that likes Eclipse ;)
>> But I should probably check it out.
>
> Well, I'm mostly a C guy, but I prefer working in Eclipse over others (C::B, Anjuta etc.)
>
> For this reason, I look forward to DDT.
>
> However, for the time being, what keeps me far from DDT is the very reason that I embraced Eclipse/CDT for: the debugger. DDT lacks it.

I too use Eclipse+CDT (and other plugins like linuxtools, pyDEV)for C/C++ on Linux/BSD. Eclipse is also the "de facto" standard for C/C++ in the embedded world. See for example www.yoctoproject.org. Also android development toolkit (ADT) is eclipse based. See http://developer.android.com/sdk/index.html.
Eclipse+CDT has improved a _lot_ over the last 5/6 years. It has become my 'IDE' of choice for C/C++ development over C::B, codelite, anjuta, KDevelop, VIM etc on Linux/BSD. On windows I still prefer MSVS for C++ which is still way ahead of eclipse+CDT, but the gap is closing...

In my experience good tools (especially debugger!) and integration with MSVS/Eclipse/Xcode are mandatory to gain broader adaption. Most of my co-workers can't even get anything done without a IDE!

01-Sep-2013 22:44, Walter Bright пишет:
> On 9/1/2013 11:01 AM, Dmitry Olshansky wrote:
>> The only one I see is
>> VS110COMNTOOLS
>
> Very strange. When I click on the shortcut "Visual Studio x64 Win64..."
> to open a command prompt, it sets a veritable blizzard of environment
> variables.

Ah, that command prompt...
VCINSTALLDIR=C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\
WindowsSdkDir=C:\Program Files (x86)\Windows Kits\8.0\

However the said windows kit folder has tree like this:
C:\Program Files (x86)\Windows Kits\8.0\Lib\win8\um\{arm,x86,amd64}

That 'win8\um' sub-folder is what must be throwing it off. It's nothing like that in Win7 SDK.

>> There are 2 distinct things - libraries are ound in Platform SDK (or
>> rather
>> WindowsSDK these days) and version 8 differs from 7. You can download and
>> install it (any version) - it's a free download.
>> Compiler/linkers are installed to VisualStudio and are dealt with
>> separately.
>>
>> I still have this error when trying to comompile with debug info:
>>
>> LINK : fatal error LNK1101: incorrect MSPDB110.DLL version; recheck
>> installation
>> of this product
>>
>> No idea whose fault is it (DMD vs MS linker vs something in my
>> paths/env).
>
> DMD does not load any DLLs.

Okay, then it could very well be just me messing with paths/env.

OT: MS x64 compiler too could be had for free (it come with SDK I installed not VS express)

>> + I have to redefine everything in order to compile phobos/druntime as
>> these are
>> hardcoded to VS10 (again !) thus I don't usually test/build x64
>> Phobos. It's far
>> less hassle for me to keep around x64 Linux virtual box for testing.
>
> When I compile phobos, for example, I use the following makefile (named
> "makefile"). It is very handy for resetting the environment variables
> used by win32.mak.
>
> --------------
> # Makefile to build D runtime library phobos.lib for Win32
> # Designed to work with \dm\bin\make.exe

Thanks! I could borrow that.
With that said I don't quite like Makefiles at all.

-- 
Dmitry Olshansky

On 2013-09-01 16:32, Manu wrote:

> Well we never got OSX working (under mono-d), although this was mainly
> due to supporting apple infrastructure in the end. I think we wrangled
> the toolchain in the end, but never got everything linking; C++
> dependencies got complicated.
> We eventually gave up, just wasting too much time, and he went off and
> did the music/sounds for the game...

Gave up? Why not just use DMD directly from the zip on the command line and use TextMate or Sublime. TextMate 2 supports in app download of new languages and Sublime comes with support for D out of the box. Even though it's not perfect it has to be better than giving up.

> If you'd like to help me finish that OSX work we started together last
> year, that'd be really great for next time! :)

Well, I'm quite busy with my own projects. But I could perhaps give you a hand if you need. Although I don't want to do all the work as last time.

> No, actually, as much as I keep banging on the IDE thing, in this case I
> absolutely don't want help from the IDE, I just want to look at my page
> of text, and be able to read a useful summary.
> Can you give me any good reasons why fully defined functions polluting
> the readability of a class definition could possibly be a good thing?
> I just don't get it... why would you ever want to break up the nice
> summary of what a class has&does, and why would you want to indent all
> of your functions an extra few tab levels by default?

To keep everything in one place. Why would you want to duplicate the method signatures? I hate the header/source synchronization in the C family of languages. Especially in C++ where the signatures cannot even be exactly the same between the header and source file. I'm thinking of default values, for example.

> As a programmer, I spend a lot more time reading code than
> documentation, and much of that time is spent reading it in foreign
> places like github commit logs (limited horizontal space), diff/merge
> windows (hard to distinguish class API changes vs function body changes
> at a glance, since they're interleaved), even chat clients and
> communication tools. The IDE can't assist in any of these contexts. If
> you have to have an IDE to read your code, then something is really wrong.

That I agree with.

> ...also, that implies you have good IDE integration, which is the a
> central part of my entire rant! ;)
> This argument is invalid until we have that, and at this point, it seems
> much more likely we may be able to define methods outside the class
> scope than have awesome IDE's.

-- 
/Jacob Carlborg

On 2013-09-01 16:36, Manu wrote:

> Give me one advantage to defining methods inline? I only see
> disadvantages. Lots of them.

Give me one advantage to repeat the method signature.

-- 
/Jacob Carlborg

On 9/1/2013 11:58 AM, Dmitry Olshansky wrote:
> 01-Sep-2013 22:44, Walter Bright пишет:
>> On 9/1/2013 11:01 AM, Dmitry Olshansky wrote:
>>> The only one I see is
>>> VS110COMNTOOLS
>>
>> Very strange. When I click on the shortcut "Visual Studio x64 Win64..."
>> to open a command prompt, it sets a veritable blizzard of environment
>> variables.
>
> Ah, that command prompt...
> VCINSTALLDIR=C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\
> WindowsSdkDir=C:\Program Files (x86)\Windows Kits\8.0\
>
> However the said windows kit folder has tree like this:
> C:\Program Files (x86)\Windows Kits\8.0\Lib\win8\um\{arm,x86,amd64}
>
> That 'win8\um' sub-folder is what must be throwing it off. It's nothing like
> that in Win7 SDK.
>
>>> There are 2 distinct things - libraries are ound in Platform SDK (or
>>> rather
>>> WindowsSDK these days) and version 8 differs from 7. You can download and
>>> install it (any version) - it's a free download.
>>> Compiler/linkers are installed to VisualStudio and are dealt with
>>> separately.
>>>
>>> I still have this error when trying to comompile with debug info:
>>>
>>> LINK : fatal error LNK1101: incorrect MSPDB110.DLL version; recheck
>>> installation
>>> of this product
>>>
>>> No idea whose fault is it (DMD vs MS linker vs something in my
>>> paths/env).
>>
>> DMD does not load any DLLs.
>
> Okay, then it could very well be just me messing with paths/env.
>
> OT: MS x64 compiler too could be had for free (it come with SDK I installed not
> VS express)
>
>>> + I have to redefine everything in order to compile phobos/druntime as
>>> these are
>>> hardcoded to VS10 (again !) thus I don't usually test/build x64
>>> Phobos. It's far
>>> less hassle for me to keep around x64 Linux virtual box for testing.
>>
>> When I compile phobos, for example, I use the following makefile (named
>> "makefile"). It is very handy for resetting the environment variables
>> used by win32.mak.
>>
>> --------------
>> # Makefile to build D runtime library phobos.lib for Win32
>> # Designed to work with \dm\bin\make.exe
>
> Thanks! I could borrow that.
> With that said I don't quite like Makefiles at all.
>

I think the most practical thing at the moment is to:

1. put comments in sc.ini explaining it better
2. replace the hardcoded tails that link.c appends to the sc.ini values with new settings in sc.ini
3. provide commented-out example settings for each variant of VS as we discover what they should be

On 2013-09-01 17:17, Manu wrote:

> I think infrastructure solutions like this are probably fine, but
> they're worthless unless they're installed by default as part of the
> standard DMD installer.
> If it's robust, convince Walter to include it in the standard installer
> package?

I might look in to that when it's time to update to D2. But the point of DVM is to use it instead of an installer.

-- 
/Jacob Carlborg

On 2013-09-01 18:24, Dmitry Olshansky wrote:

> So true. But in case of say VisualD there simply not enough of folks
> with right kind of expertise - that are familiar with VisualStudio SDK +
> the number of arcane steps to build/integrate it AND have
> time/inclination to work on it.
> Ditto with other IDEs, it's a lot of upfront work to learn the
> infrastructure + as anything interactive there is no easy test suite to
> check your tweaks/hacks.

And Xcode which doesn't even officially supports plugins.

-- 
/Jacob Carlborg

On Sunday, 1 September 2013 at 07:42:47 UTC, Walter Bright wrote:
> On 8/31/2013 7:05 PM, Manu wrote:
>> The only compiler you can realistically use productively in windows is
>> DMD-Win64, and that doesn't work out of the box.
>> We needed to mess with sc.ini for quite some time to get the stars aligned such
>> that it would actually compile and find the linker+libs.
>>
>> Walter: DMD needs to internally detect installations of various versions of
>> VisualStudio, and either 'just work', or amend sc.ini on its own. Or the
>> installer needs to amend sc.ini. Either way, leaving it to a user to fiddle with
>> an ini file just isn't acceptable. We had to google solutions to this problem,
>> and even then, we had trouble with the paths we added to sc.ini; are spaces
>> acceptable? Do they have quites around them?...
>> I might also suggest that Microsoft supplied (ie, 'standard'), libraries should
>> be automatically detected and path entries added in there too:
>>   C:\Program Files (x86)\Microsoft SDKs\...
>>   C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\...
>> These are on basically every windows developers machine, and each of us had to
>> configure them ourselves.
>
> The default sc.ini contains:
> -----------------------------
> [Version]
> version=7.51 Build 020
>
> [Environment]
> LIB="%@P%\..\lib";\dm\lib
> DFLAGS="-I%@P%\..\..\src\phobos" "-I%@P%\..\..\src\druntime\import"
> LINKCMD=%@P%\link.exe
> LINKCMD64=%VCINSTALLDIR%bin\amd64\link.exe
> VCINSTALLDIR=%VCINSTALLDIR%
> WindowsSdkDir=%WindowsSdkDir%
> ----------------------------------
>
> When I installed VC 2010, it set the environment variables VCINSTALLDIR and WindowsSdkDir. Then, the default sc.ini should "just work".
>
> What went wrong, specifically?

I can make the installer detect which versions of Visual Studio are installed and the path they are installed.  Would I rather I have the installer modify the installed sc.ini or set an environment variable?