On 9/1/13, Manu <turkeyman@gmail.com> wrote:
> The only compiler you can realistically use productively in windows is
> DMD-Win64 **

Why? Win32 works fine for me and many others. If you run into
Optlink-related bugs it's usually the compiler's fault. It might
generate a bad object file and cause Optlink to crash (Unilink is
better for diagnosing what went wrong).

I'd imagine in a game-jam you won't be making a huge codebase, so you
might as well stick with 32bit?

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

I provided a setup script once to retrieve the VC paths, which could
then be invoked by some other process (perhaps even DMD itself when it
reads sc.ini), but nothing seems to have come out of it yet:

http://forum.dlang.org/thread/50DAD8BA.8030205@digitalmars.com?page=2#post-CAJ85NXCKNnKMjVKpk9wSWOrGdAhJFCWa_n:2BkjCZpjJOBC5u-bQ:40mail.gmail.com

Recently Nick has been working on making release scripts which will
package dmd.zip automatically, I hope we can work on better VC
integration after that work is done.

> I suggest:
>  * These should be made central D community projects.

Most of us are happy enough with syntax-highlighted text editors, so
we likely wouldn't touch any IDE code. I'm not sure what the above
political move would do. There was a period when DWT was elected as
the "official" D GUI, but nothing came out of it. So these political
moves don't really mean a thing.

>    - Deprecate DMD makefiles. Seriously! Insist that contributors use the
> IDE bindings to work on DMD.

Not gonna happen.

>    - The fact that you all laughed at the prior point suggests clearly why
> it needs to be done. It will cease to be a problem when all the
> druntime/phobos contributors are suffering the end-user experience.

Slowing us down won't help anyone.

>  * They should receive bugs in the main github bug-tracker, so EVERY D
> contributor can see them, and how many there are.

Bugzilla is better than whatever github has to offer. It's fast and
its very searchable. Github just seems to introduce more and more
useless features every other day (but I can't even search the damn
pull request section, even though there's a "global" search..).

> 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.
> I think continuous code compilation for auto-completion and syntax
> highlighting purposes should be a service offered and maintained by DMD.
> That way it will evolve with the language, and anyone can use it without
> reinventing the wheel.

This has been said a million times, but it's a very slow evolution
turning an application into a library, especially one like DMD. The
C++ => D migration process of DMD could maybe help us move into this
direction.

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

That sucks.

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

It's in the windows/bin folder. It's a poor place to put it, it should
better be put in a 'doc' folder or something, and it should be noted
somewhere on the website.

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

That will allocate a new array. It could have been:

foreach(i, item; array)
    if (item == itemToRemove)
        array = array.remove(i);

or even:

auto idx = array.countUntil(item);
if (idx != -1)
    array = array.remove(idx);

Although it's still not very pretty. I'm surprised you're using
allocation like that for game development! :)

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

I think Andrei mentioned once that this might be a good idea, but it
needs a DIP and formal reviewing, not to mention a solid
implementation. Only this time, no more back-channel introduction of
features like UDAs, please. We ended up having a deprecation for
syntax that never formally existed.

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

Clean slate means you run exactly into issues like setting up the
compiler, which does bring these problems to light, but really in a
game-jam full of people wanting to try D, why not come prepared?