Had another 48hr game jam this weekend...

[deadalnix]

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 !