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?

On 1 September 2013 12:57, Andrej Mitrovic <andrej.mitrovich@gmail.com>wrote:

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

** If you want to link against any other libraries. Ie, if your eco-system
is not completely self-contained.
Libs in windows are compiled with VC. It's the de facto standard.

In our context, libs include: D3D, OpenGL, DirectSound, XAudio, DirectInput, XInput, zlib, libpng, libjpeg, libmad, libogg, libvorbis, AssImp, etc.

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

Most of who? The D devs? You all reject auto-complete and debuggers? How do
you get any work done?
Most of the D developers don't seem to be like most of the commercial
software dev's I've ever worked with.
I can't explain this, but I think it's a big problem that the development
community experience has very little on common with the end-user experience.

The reason for the political move would be in the inclusion of all of their
bugs into the main bug tracker, and consequently included in any reporting
and trend data.
It would also give end-users the right to come into the D forums and
complain about the IDE integration's directly. It's a central part of the
language experience, and should be taken as first-class criticism.

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

Reconsider.

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

I'd argue that it would; inflicting the pain of trying to be a productive D user on the developers will certainly highlight the importance of the issue. I'm sure the only reason it can remain in such a feeble state for so many years, is because the few people that write D code every day and could be focusing attention on it aren't exposed to it.

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

Well bugzilla then, wherever.. Just in the same place.

I'm really don't like bugzilla as an end-user, but I'm not performing
searching actions.
As a reporter, I find it's needless friction between me and reporting bugs,
and I consequently report perhaps half as many bugs as I would otherwise,
because I need to open a slow website, and login with yet another account...

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

Cool. And yeah, I know, I've seen it raised loads of times.
Raise it's priority? It's clearly a critical issue, not just a 'yeah that'd
be nice'.

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

And needs to be fixed.

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

Oh, in bin... Never thought to look there ;)
I think most users would expect a link in the start menu.

> 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! :)
>

These are all horrible 'solutions' to remove an item from an array. It should be one line.

It's a 48hr game jam, efficiency is not a priority. Brevity and
readability/hackability are of key importance.
Especially when cooperating with a bunch of programmers, with absolutely no
discussion about code/systems design.

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

Well, it's still a good idea if you ask me, and my squad of friends at least. ;)

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

Are you saying I should have told everyone to set up their machines before
coming?
The decision to use D was made on the spot, upon my insistence...
Seems I'm making myself unpopular all over the world for recommending D to
people, perhaps I should stop ;)

On Sunday, 1 September 2013 at 04:36:46 UTC, Manu wrote:
> I'm really don't like bugzilla as an end-user, but I'm not performing
> searching actions.
> As a reporter, I find it's needless friction between me and reporting bugs,
> and I consequently report perhaps half as many bugs as I would otherwise,
> because I need to open a slow website, and login with yet another account...

I've always found Bugzilla to be terrible. I *still* have no clue how to actually find the latest opened issues. For my own personal stuff I use Jira ($10 for up to 10 users or free for open source projects) and I find it to be an excellent issue tracking system. The ability to create an issue just by simply pressing 'c' on any page is wonderful and things load fairly fast from my experiences. That being said, I don't see D changing away from bugzilla any time soon, if ever. And honestly, there are much bigger priorities.

On 8/31/2013 10:02 PM, Kapps wrote:
> I've always found Bugzilla to be terrible. I *still* have no clue how to
> actually find the latest opened issues.

All open issues (the latest are at the end):

http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED


Regressions:

http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&bug_severity=regression&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED


What I did was create my own custom "home page" and fill it with these handy URL's.

On 8/31/2013 9:36 PM, Manu wrote:
> I'm really don't like bugzilla as an end-user, but I'm not performing searching
> actions.
> As a reporter, I find it's needless friction between me and reporting bugs, and
> I consequently report perhaps half as many bugs as I would otherwise, because I
> need to open a slow website, and login with yet another account...

Bugzilla sets a cookie on your machine so you don't have to repeatedly log in. I log in once every few months when something happens to my browser that deleted the cookies.

If you have cookies disabled, of course you'll have to log in every time. But that's the same with github, too.

On Sunday, 1 September 2013 at 07:55:15 UTC, Walter Bright wrote:
> On 8/31/2013 10:02 PM, Kapps wrote:
>> I've always found Bugzilla to be terrible. I *still* have no clue how to
>> actually find the latest opened issues.

I have to agree with Manu that I probably report half as many
ICE's and parse errors than I receive, simply because of how slow
Bugzilla is.

That and its interface is so tedious, I have no idea how to check
if it has already been reported...

On 9/1/2013 1:05 AM, Daniel Cousens wrote:
> On Sunday, 1 September 2013 at 07:55:15 UTC, Walter Bright wrote:
>> On 8/31/2013 10:02 PM, Kapps wrote:
>>> I've always found Bugzilla to be terrible. I *still* have no clue how to
>>> actually find the latest opened issues.
>
> I have to agree with Manu that I probably report half as many
> ICE's and parse errors than I receive, simply because of how slow
> Bugzilla is.
>
> That and its interface is so tedious, I have no idea how to check
> if it has already been reported...

Brad tells me that it is very slow at 2AM-3AM PST, which is when it goes into some sort of maintenance mode. Since you guyz are in different timezones, are you perhaps hitting that time?

On Sun, 01 Sep 2013 10:05:31 +0200
"Daniel Cousens" <daniel210x@gmail.com> wrote:

> On Sunday, 1 September 2013 at 07:55:15 UTC, Walter Bright wrote:
> > On 8/31/2013 10:02 PM, Kapps wrote:
> >> I've always found Bugzilla to be terrible. I *still* have no
> >> clue how to
> >> actually find the latest opened issues.
> 
> I have to agree with Manu that I probably report half as many ICE's and parse errors than I receive, simply because of how slow Bugzilla is.
> 
> That and its interface is so tedious, I have no idea how to check if it has already been reported...

I like bugzilla a lot. One of the few web-based tools I don't mind using. And it always seems much faster than 99% of the other websites out there, including github.

On 2013-09-01 09:55, Walter Bright wrote:

> All open issues (the latest are at the end):
>
> http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED

I doesn't look like the latest are at the end. It seems to be sorted by status, not date.

-- 
/Jacob Carlborg

On 2013-09-01 10:00, Walter Bright wrote:

> If you have cookies disabled, of course you'll have to log in every
> time. But that's the same with github, too.

Github also uses cookies, or something. I rarely have to log in at Github.

-- 
/Jacob Carlborg