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

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

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


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

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

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.

01-Sep-2013 11:42, Walter Bright пишет:
> On 8/31/2013 7:05 PM, Manu wrote:

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

This is hopeless. It should try to detect many versions.
As different versions have different folder structures.

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.

-- 
Dmitry Olshansky

On 2013-09-01 05:53, Jakob Ovrum wrote:

> Although I'm not convinced auto-completion is a vital feature
> (Microsoft's C++ IntelliSense is shit too)

That doesn't mean there aren't any IDE's out there with good support for autocompletion. The one in Eclipse for Java is fantastic. The one in Xcode 4+ for C/C++ and Objective-C/C++ is really good.

I'm also quite amazed by JetBrains, they're spitting out IDE's like mad, with full language support for many types of languages. Even those that are usually very difficult, like dynamically typed languages. They fully support Ruby on Rails.

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

You're forced to explicitly initialize it.

-- 
/Jacob Carlborg

On Sun, 01 Sep 2013 09:42:37 +0200, 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?
>

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.

-- 
Simen

On Sunday, 1 September 2013 at 02:05:51 UTC, Manu wrote:
> Configuring compilers:
>
> Naturally, this is primarily a problem with the windows experience, but
> it's so frustrating that it is STILL a problem... how many years later?

My first setup took me days :D Somehow it improved. It still sucks.

>
> Getting a workable environment:
>
> Unsurprisingly, the Linux user was the only person happy work with a
> makefile. Everybody else wanted a comfortable IDE solution (and the linux
> user would prefer it too).
>

I came to the same conclusion, and that is why SDC is relying on libd. Our tooling sucks hard.

> Obviously, we settled on Visual-D (Windows) and Mono-D (OSX/Linux); the
> only realistic choices available. The OSX user would have preferred an
> XCode integration.
>

I don't know any dev that is happy of XCode, even OSX lovers. I mean, how good is a editor that propose you to export functions to iTune (I should try it one day, I really wonder what it does), but not finding declaration in its contextual menu ?

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

Considering DMD never deallocate anything, expect to restart your IDE every hour or so.

> Debugging:
>

Ho god ! The demangler do not demangle most things. Hello stack trace of incomprehensible symbol. If gdb is able to give me file/line, druntime is completely unable to do so, so you have to use external tooling to get back this info.

The best of the best being too long mangling being truncated in the output. Backtrace is the bare minimum to dubug and it isn't working.

>
> Documentation:
>
> Okay for the most part, but 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.
>

I don't understand that. I never understand anything at MS documentation because of its look and feel (the content is usually pretty good).

I guess it is matter of taste/habit.

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

Me miss 1 piece in the language to make that work properly (and another one to make that more effiscient). Namely covariance on template instances and allocators.

I've been raising the first one as it is also a problem for SDC. People raised it to implement AA as lib, and it is a recurring discussion around dcollection.

>
> Bugs:
> Yes, we hit DMD bugs, like the one with opaque structs which required
> extensive work-arounds.
>   struct MyStruct;
>   MyStruct*[] = new MyStruct*[n];
>
> We also ran into some completely nonsense error messages, but I forgot to
> log them, since we were working against the clock.
>
>
> 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).

Arguably, this is because of lack of IDE support and because C++ screwed you up :D I recognize the feature as good to have, but definitively not as big as an issue as the one mentioned above. If the problem mentioned before are solved, then this one won't be a big issue.

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

That look a good project !

On 2013-09-01 04:05, Manu wrote:

> Naturally, this is primarily a problem with the windows experience, but
> it's so frustrating that it is STILL a problem... how many years later?
> People don't want to 'do work' to install a piece of software. Rather,
> they expect it to 'just work'. We lost about 6 hours trying to get
> everyone's machines working properly.
> In the context of a 48 hour game jam, that's a terrible sign! I just
> kept promising people that it would save time overall... which I wish
> were true.

Was this only on Windows or were there problems on Linux/Mac OS X as well?

> Getting a workable environment:
>
> Unsurprisingly, the Linux user was the only person happy work with a
> makefile. Everybody else wanted a comfortable IDE solution (and the
> linux user would prefer it too).

I can understand that.

> IDE integration absolutely needs to be considered a first class feature
> of D.
> I also suggest that the IDE integration downloads should be hosted on
> the dlang download page so they are obvious and available to everyone
> without having to go looking, and also as a statement that they are
> actually endorsed by the dlanguage authorities. As an end-user, you're
> not left guessing which ones are good/bad/out of date/actually work/etc.

I completely agree.

> Obviously, we settled on Visual-D (Windows) and Mono-D (OSX/Linux); the
> only realistic choices available.

There's also DDT with Eclipse. It supports auto completion, go to definition, has an outline view and so on.

> The OSX user would have preferred an  XCode integration.

This one is a bit problematic since Xcode doesn't officially supports plugins. But it's still possible, as been shown by Michel Fortin with his D for Xcode plugin.

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

Sounds like you want an outline view in the IDE. This is supported by DDT in Eclipse. Even TextMate on Mac OS X has a form of outline view.

-- 
/Jacob Carlborg

While I consider going to a contest with tools you don't know yet a very risky move, I can only empathize with some of the points expressed by Manu.

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

Same problem here, I used DMD-Win64 only once since I don't remember the steps to get it to work (I think it involved changing some .lib and path in sc.ini).

> 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 happened to me several times, so that I end up relying on writefln-debugging again. The fact that an IDE plugin exist at all is a huge acceptance factor in the workplace.

On Sunday, 1 September 2013 at 09:46:08 UTC, Jacob Carlborg wrote:
> That doesn't mean there aren't any IDE's out there with good support for autocompletion. The one in Eclipse for Java is fantastic. The one in Xcode 4+ for C/C++ and Objective-C/C++ is really good.

Java is not a good comparison because it does not have any compile-time metaprogramming features to speak of.

I've never used Xcode but how does it fare when faced with C++ template metaprogramming?

> You're forced to explicitly initialize it.

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