September 01, 2013
On Sunday, 1 September 2013 at 02:05:51 UTC, Manu wrote:
> </endrant>

Completely agree with Manu! I work in the Java + telecom world of programming and recently graduated, so that's the majority of my experience. From what I've seen and experienced is that most today programmers can't live without an IDE and a rock solid tool chain.

I've seen many solutions posted in this thread to parts of the problems, eg auto complete, debugging etc.
The thing with an IDE is that it has "JUST WORK" it should work with all the different components seamlessly.
The question I would like to ask is how can WE as a COMMUNITY improve this situation?
Official IDE support?
Official "IDE components"?
Roadmap?

Other languages like Java have corporate backing. What difference makes this? Why doesn't we have a roadmap? How does other open source communities work and what can we learn from them?

Sorry for the un-structure of my post.

September 01, 2013
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.
September 01, 2013
On 9/1/2013 2:25 AM, Dmitry Olshansky wrote:
> To get it to work with say VS11 I had to kill VCINSTALLDIR & WindowsSDKDir and
> set LIB/LINKCMD paths by hand in Environement64.
> Whatever magic setup code there is for VS10/WinSDK7 it doesn't work with
> VC11/WinSDK8.

What environment variables did VS11 set?

September 01, 2013
On 9/1/2013 2:46 AM, Simen Kjaeraas wrote:
> Like Dmitry said, it might work for 2010, but it certainly does not 'just
> work' for 2012 and 2013. I've probably spent twelve hours setting up DMD
> Win64 on my two confusers.

I need specifics.

Again, what environment variables are setup by these other VS's? What did you put in your sc.ini?

I don't have multiple VS installs.

September 01, 2013
On 9/1/2013 6:19 AM, Manu wrote:
> Hmmm, I found details on the net that recommended adding an [Environment64]
> section, which we did.
>
> I don't seem to have VCINSTALLDIR or WindowsSdkDir variables on my system :/ ..
> that said, VC obviously works on my machine.

Sorry if I am being repetitive here, but what environment variables is VS setting on your machine?

> It also seems potentially problematic that a variable would define a single
> install directory, since it's pretty common that programmers have multiple
> versions of VS on their machines.
> I have VS2010 and VS2012 on my machine. Simon had VS2012 and VS2013.

Yes, so what environment variables should sc.ini use to determine which one the user wants to use for dmd?

> I was also thinking it might be a mistake to keep phobos64.lib in the same
> folder as the 32bit omf libs. If paths are wrong, the link errors will only be
> understood by a programmer who understands compilers and lib/object formats in
> depth.
> Perhaps you should put them in a parallel lib64 directory, and hook that up in
> [Environment64] (I did that on my machine while trying to isolate problems and
> wort out where paths were coming from)?

Please, I need specifics.

> I reckon you should look into hooking up DirectX SDK patahing by default too
> since it's so common for basically any multimedia app.

I have no idea what you mean by this?
September 01, 2013
As a followup,

When I installed VS2010, it created a shortcut on my desktop labelled "Visual Studio x64 Win64 ...". Clicking on that opened a command line window.

In that window, I could compile and run VC programs from the command prompt using CL, LINK, etc.

In that window, if I typed:

SET

at the prompt, it showed the environment variables set, which included:

VCINSTALLDIR - where VC was installed
WindowsSdkDir - where the SDK was installed

This is all dmd needs in order to use VS2010.

However, I didn't want to have to click on that shortcut just to use -m64, so I merely copied the values VCINSTALLDIR and WindowsSdkDir into my own personal sc.ini, and then dmd -m64 worked fine.
September 01, 2013
On 9/1/2013 7:02 AM, Manu wrote:
> I know Walter does care about the DMD-Win64 debuginfo quality, but I don't think
> the debuginfo output is capable of addressing all the problems alone.

I (and others like Rainer who help a lot with Win64 support) also cannot do a thing without targeted bugzilla reports.
September 01, 2013
On 9/1/2013 6:55 AM, Manu wrote:
> Sometimes...
> Have you worked with it on a daily basis? It just doesn't work all the time.
> Also, in my experience the auto-complete suggestions are often either
> incomplete, or list heaps of completely unrelated stuff.
> I'm not saying it's bad, it's better than nothing and I really appreciate the
> project (I've said before, if it weren't for Rainer's effort, I simply wouldn't
> use D), but it certainly needs more work, especially if I'm going to have any
> traction selling it to others with no vested interest in the language.

I really appreciate your efforts here.

What Rainer needs is, I assume, the same things I need. Very specific lists of what went wrong.
September 01, 2013
On 9/1/2013 2:50 AM, deadalnix wrote:
> Considering DMD never deallocate anything, expect to restart your IDE every hour
> or so.

DMD deallocates everything when its process ends. This should have zero effect on the IDE. If you need to restart the IDE every hour, it is not because of DMD.

>> Debugging:
> Ho god ! The demangler do not demangle most things.

Bugzilla entry, please.

There are many members in the D community who poke around looking for low hanging fruit in bugzilla that they can fix. They'll never know about the issues you're having that they can fix if they aren't in bugzilla.
September 01, 2013
01-Sep-2013 21:24, Walter Bright пишет:
> On 9/1/2013 2:25 AM, Dmitry Olshansky wrote:
>> To get it to work with say VS11 I had to kill VCINSTALLDIR &
>> WindowsSDKDir and
>> set LIB/LINKCMD paths by hand in Environement64.
>> Whatever magic setup code there is for VS10/WinSDK7 it doesn't work with
>> VC11/WinSDK8.
>
> What environment variables did VS11 set?
>
(You can try downlaoding express editions as they are free)

The only one I see is
VS110COMNTOOLS
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

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).

+ 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.


-- 
Dmitry Olshansky