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

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

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


On 1 September 2013 17:42, Walter Bright <newshound2@digitalmars.com> 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?
>
>

On 1 September 2013 17:46, Nick Sabalausky < SeeWebsiteToContactMe@semitwist.com> wrote:

> On Sun, 01 Sep 2013 06:45:48 +0200
> "Kapps" <opantm2+spam@gmail.com> wrote:
>
> > On Sunday, 1 September 2013 at 02:05:51 UTC, Manu wrote:
> > > One more thing:
> > > I'll just pick one language complaint from the weekend.
> > > It is how quickly classes became disorganised and difficult to
> > > navigate
> > > (like Java and C#).
> > > We all wanted to ability to define class member functions
> > > outside the class
> > > definition:
> > >   class MyClass
> > >   {
> > >     void method();
> > >   }
> > >
> > >   void MyClass.method()
> > >   {
> > >     //...
> > >   }
> > >
> > > It definitely cost us time simply trying to understand the
> > > class layout
> > > visually (ie, when IDE support is barely available).
> > > You don't need to see the function bodies in the class
> > > definition, you want
> > > to quickly see what a class has and does.
> >
> > This isn't something I've found to be an issue personally, but I suppose it's a matter of what you're used to. Since I'm used to C#, I haven't had problems with this. I've always felt that this was the IDE's job, personally. That being said, perhaps .di files could help with this?
>
> I see it as the job of doc generators.
>

Why complicate the issue? What's wrong with readable code?

On 2013-09-01 12:21, Jakob Ovrum wrote:

> What do you mean? Please show some code how a declared but not defined
> struct can be initialized in any way, shape or form.

int[] a; // default initialized
int[] b = [3, 4, 5]; // explicitly initialized

-- 
/Jacob Carlborg

On 2013-09-01 13:44, Mike Parker wrote:

> I have a batch file tied to a command prompt shortcut that always sets
> the D environment when I launch it. Updating DMD is a matter of deleting
> the old directory and unzipping the zip file.

Or just use DVM:

https://github.com/jacob-carlborg/dvm

-- 
/Jacob Carlborg

On Sunday, 1 September 2013 at 13:21:20 UTC, Jacob Carlborg wrote:
> int[] a; // default initialized
> int[] b = [3, 4, 5]; // explicitly initialized

This has nothing to do with the problem.

On 1 September 2013 18:06, Benjamin Thaut <code@benjamin-thaut.de> wrote:

> Am 01.09.2013 04:05, schrieb Manu:
>
>
>> !!!!!!!!!
>> This has to be given first-class attention!
>> I am completely and utterly sick of this problem. Don made a massive
>> point of it in his DConf talk, and I want to re-re-re-re-re-re-re-stress
>> how absolutely important this is.
>> !!!!!!!!!
>>
>
> I have to fully agree here.
>
>
>
>> Debugging:
>>
>> Poor debugging experience wastes your time every 5 minutes.
>> I can only speak for the Windows experience (since we failed to get OSX
>> working); there are lots of problems with the debugging experience under
>> visual studio...
>> I haven't logged bugs yet, but I intend to.
>> There were many instances of people wasting their time chasing bugs in
>> random places when it was simply a case of the debugger lying about the
>> value of variables to them, and many more cases where the debugger
>> simply refused to produce values for some variables at all.
>> This is an unacceptable waste of programmers time, and again, really
>> burned us in a 48hour context.
>>
>>
> Actually there is only one little patch needed to make debugging work nicely with the visual studio c++ debugger. It replaces all '.' chars with '@' in type names inside the debug information. There was a pull request from Rainer Schuetze once, but it got rejected by Walter.
>
> https://github.com/Ingrater/**dmd/commit/**522f6dbeb93944ebfebde6f938a2ee* *3a2d6be124<https://github.com/Ingrater/dmd/commit/522f6dbeb93944ebfebde6f938a2ee3a2d6be124>
>
> Also if you are using Visual Studio 2012, you need to change the debugging engine because the new one can't deal with D code that has C++ debugging info. For that go to Options -> Debugging -> Edit and Continue -> Enable Edit and Continue (this will make Visual Studio 2012 use the old debugging engine).
>

I use 2010, but Simon was using 2012, maybe that was the source of his problems. He certainly seemed to have a lot more problems than me.

Then everything will work nicely. The only real issue is, that the debugger
> can't identify which class is behind a given interface.
>
> Also you should try using mago, it can be enabled inside the visualD debugging options of your project. It even features D expression evaluation, but it only works for 32-bit (but requires not cv2pdb conversion).


Mago is only Win32, and DMD is only Win64... I've tried encouraging the Mago guy to support Win64, but it doesn't seem to be a highly active project recently. I think this is another case of a 1-man project that represents a fairly critical part of the ecosystem.


Containers:
>>
>> The question came up multiple times; "I don't think this should be an
>> array... what containers can I use, and where are they?"...
>> Also, nobody could work out how to remove an arbitrary item from an
>> array, or an item from an AA by reference/value (only by key).
>>
>> This code:
>>    foreach(i, item; array)
>>      if(item == itemToRemove)
>>        array = array[0..i] ~ array[i+1..$];
>> Got a rather 'negative' reaction from the audience to put it lightly...
>>
>>
> Oh containers, I would love to have some. Like every one else using D I've written my own by now.


It turns out that it's not actually so easy to just 'knock up' a set of
robust containers that work well across all of D's features.
Templates, and various typing complexities always seem to complicate the
issue.
In my experience, I knock something together, and it appears to work in the
simple case... but then down the line, something a little more niche hits
it, and I realise it's not a trivial tweak to fix it. Often a more
substantial rethink may be required.

 One more thing:
>> I'll just pick one language complaint from the weekend.
>> It is how quickly classes became disorganised and difficult to navigate
>> (like Java and C#).
>> We all wanted to ability to define class member functions outside the
>> class definition:
>>    class MyClass
>>    {
>>      void method();
>>    }
>>
>>    void MyClass.method()
>>    {
>>      //...
>>    }
>>
>> It definitely cost us time simply trying to understand the class layout
>> visually (ie, when IDE support is barely available).
>> You don't need to see the function bodies in the class definition, you
>> want to quickly see what a class has and does.
>>
>>
> You should really use VisualD's ability to parse the AST .json files dmd generates while compiling. Using this feature you get a really awesome class view and even "Go to defintion" works.
>

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.

The situation at Remedy was different, it was an easier sell. Since we
implemented D as an extension language, the productivity comparison was to
scripting languages like lua which also have no tight integration or
debugging support in Visual Studio. Visual-D was certainly an improvement
over other scripting solutions, and I think I made that case at DConf.
But this project approached it from a different angle, ie, a total
replacement for C++ which does have a rich toolset available. I want to use
D in this context in the future, and if that were the commitment we were
considering at Remedy, there's no way we would have gone for it.

My hope from the Remedy experience was to prove that it works in a
commercial environment.
I went out on a REALLY massive limb there, and as far as I can tell, it's
well received (although it took the better part of a year longer to get
there than I promised).
I'd love to see it take the next step one day, ie, into the main
code-base... but the tools need to be rock solid before that can ever
happen.


Conclusion:
>> I think this 48 hour jam approach is a good test for the language and
>> it's infrastructure. I encourage everybody to try it (ideally with a
>> clean slate computer).
>> The lesson is that we need to make this process smooth, since it mirrors
>> the first-experience of everybody new to D.
>> It also highlights and magnifies time-wasters that are equally
>> unacceptable in a commercial environment.
>>
>> I don't think I made any converts this weekend wrt the above issues encountered. I might have even just proved to them that they should indeed stick with C# (the IDE's work!)... :(
>>
>> Please, we need a road-map, we need to prioritise these most basic
>> aspects of the experience, and we need to do it soon.
>> I might re-iterate my feeling that external IDE integration projects
>> should be claimed by the community officially, and user experience +
>> debugging issues should be first-class issues in the main d language
>> bug-tracker so everybody can see them, and everybody is aware of the
>> stats.
>> Also, the DMD front-end should be a lib offering auto-completion and
>> syntax hilighting data to clients.
>>
>> I'm doing some more work on premake (a nice light buildsystem that generated makefiles and project files for popular IDE's) to tightly incorporate D into the various IDE's it supports.
>>
>> </endrant>
>>
>
> Other then that I have to fully agree with all the points you listed.
>
> Kind Regards
> Benjamin Thaut
>
>

On 1 September 2013 18:49, Walter Bright <newshound2@digitalmars.com> wrote:

> On 9/1/2013 1:06 AM, Benjamin Thaut wrote:
>
>> Also if you are using Visual Studio 2012, you need to change the debugging engine because the new one can't deal with D code that has C++ debugging info.
>>
>
> This endless merry-go-round of MSC breaking the tools constantly is why I went with my own toolset years ago.
>

And I don't blame you, but sadly, to achieve success in the Windows environment, I'm absolutely convinced it must work seamlessly with the de facto standard MS infrastructure.

On 1 September 2013 18:51, Benjamin Thaut <code@benjamin-thaut.de> wrote:

> Am 01.09.2013 10:49, schrieb Walter Bright:
>
>  On 9/1/2013 1:06 AM, Benjamin Thaut wrote:
>>
>>> Also if you are using Visual Studio 2012, you need to change the
>>> debugging
>>> engine because the new one can't deal with D code that has C++
>>> debugging info.
>>>
>>
>> This endless merry-go-round of MSC breaking the tools constantly is why I went with my own toolset years ago.
>>
>
> Still the visual studio debugger has the best debugging experience you can currently get for D.
>

True, which is perhaps a little bit tragic. It's a good start, but lots of
things just don't work right yet.
May I re-iterate my point about the community claiming and supporting the
IDE and debugger integration as a first class language feature with bugs in
the main tracker...

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.

On 1 September 2013 13:53, Jakob Ovrum <jakobovrum@gmail.com> wrote:

> Sorry about the nonsensical reply, the web interface was acting up... this is the intended reply.
>
>
> On Sunday, 1 September 2013 at 02:05:51 UTC, Manu wrote:
>
>> The only compiler you can realistically use productively in windows is DMD-Win64, and that doesn't work out of the box.
>>
>
> Why didn't you go with DMD-Win32? Because of OMF? implib and/or objconv is a hassle but probably less of a hassle than using the nascent DMD-Win64.


Ummm... just no. I'm just not even gonna touch that. It just feels 'fake',
and I have no confidence in it at all.
Maybe I'm being difficult, but I just want to work in the same world as all
the other existing code on my ecosystem.
I'm not making major concessions like that for the niche language when
everything else is already working well.

If that suggestion works flawlessly, then DMD-Win32 should be enhanced to embed those tools, and convert COFF libs to OMF automatically at link time.

 Overwhelmingly, the biggest complaint was a lack of symbolic information to
>> assist with auto-completion. Visual-D tries valiantly, but it falls quite
>> short of the mark.
>> This goes back to the threads where the IDE guys are writing their own
>> parsers, when really, DMD should be able to be built as a lib, with an API
>> designed for using DMD as a lib/plugin.
>>
>
> Although I'm not convinced auto-completion is a vital feature (Microsoft's C++ IntelliSense is shit too), I agree that any time spent on custom parsers and best-effort semantic analysis is a complete waste of time. The only semantic analysis engine that is going to be sufficiently good for D is one from a compiler front-end. Apart from DMD, it's worth taking a look at SDC for this.


Microsoft's C# intellisense is absolutely spectacular, and there's no reason D couldn't be just as good. I think the deficiencies in the C++ experience come from the language it's self. C++ offers the opportunity for too many ambiguities. The preprocessor has gotta hinder the intellisense engine for one.

 some windows dev's want a CHM that looks like
>> the typical Microsoft doc's people are used to. Those that aren't familiar with the CHM viewer; it's just HTML but with a nice index + layout tree.
>>
>
> dmd2\windows\bin\d.chm


Noted. I suggest the installer put a link in the start menu :)

 Yes, we hit DMD bugs, like the one with opaque structs which required
>> extensive work-arounds.
>>   struct MyStruct;
>>   MyStruct*[] = new MyStruct*[n];
>>
>
> I'm not sure this is a bug. How do you default initialize an array of structs you don't know the .init values of?
>

It's an array of pointers. Pointers always .init to null...?

On Sunday, 1 September 2013 at 03:40:44 UTC, Michel Fortin wrote:
> On 2013-09-01 02:05:39 +0000, Manu <turkeyman@gmail.com> said:
>
> I'm not using D anymore. I realized that with the time required to maintain the toolset (including installer and Xcode plugin) plus the time it'd take to make the language suitable to my needs (Objective-C integration, perhaps ARM support for iOS), all that by itself would probably be more than one full-time job. As all this meta-work would seriously get in the way of my actual work, I let it go. I'm not regretting that move.
>
> So I'm no longer using D, but I'm still hanging around here from time to time because there's always something interesting to read.

That's a pity, but I can understand: actually I'm relaying in calling Objective-C runtime functionality directly, having wrapped the *very-minimum* Cocoa things that I need for our projects...

But the reality is that it's simply not feasible to use D for OSX applications apart from sticking with the posix/bsd face of the system, so one of the big three OS is out.

I would also add that actually I'm not able to debug on OSX, and that's simply something that it's a show stopper for my colleague: the best results are coming from lldb, with decent stack trace and, alas I can also set breakpoints, but I'm not able to print any local at all.

In all the tree platform, at least the debugger, as set of patch, as documentation in the main site (not in the wiki!), as support in the backend, should be the priority number one, in my opinion.

- Paolo Invernizzi