<div dir="ltr">On 1 September 2013 12:57, Andrej Mitrovic <span dir="ltr"><<a href="mailto:andrej.mitrovich@gmail.com" target="_blank">andrej.mitrovich@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">On 9/1/13, Manu <<a href="mailto:turkeyman@gmail.com">turkeyman@gmail.com</a>> wrote:<br>

> The only compiler you can realistically use productively in windows is<br>
> DMD-Win64 **<br>
<br>
</div>Why? Win32 works fine for me and many others. If you run into<br>
Optlink-related bugs it's usually the compiler's fault. It might<br>
generate a bad object file and cause Optlink to crash (Unilink is<br>
better for diagnosing what went wrong).<br>
<br>
I'd imagine in a game-jam you won't be making a huge codebase, so you<br>
might as well stick with 32bit?<br></blockquote><div><br></div><div>** If you want to link against any other libraries. Ie, if your eco-system is not completely self-contained.</div><div>Libs in windows are compiled with VC. It's the de facto standard.</div>
<div><br></div><div>In our context, libs include: D3D, OpenGL, DirectSound, XAudio, DirectInput, XInput, zlib, libpng, libjpeg, libmad, libogg, libvorbis, AssImp, etc.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im">
> We needed to mess with sc.ini for quite some time to get the stars aligned<br>
> such that it would actually compile and find the linker+libs.<br>
><br>
> Walter: DMD needs to internally detect installations of various versions of<br>
> VisualStudio, and either 'just work', or amend sc.ini on its own.<br>
<br>
</div>I provided a setup script once to retrieve the VC paths, which could<br>
then be invoked by some other process (perhaps even DMD itself when it<br>
reads sc.ini), but nothing seems to have come out of it yet:<br>
<br>
<a href="http://forum.dlang.org/thread/50DAD8BA.8030205@digitalmars.com?page=2#post-CAJ85NXCKNnKMjVKpk9wSWOrGdAhJFCWa_n:2BkjCZpjJOBC5u-bQ:40mail.gmail.com" target="_blank">http://forum.dlang.org/thread/50DAD8BA.8030205@digitalmars.com?page=2#post-CAJ85NXCKNnKMjVKpk9wSWOrGdAhJFCWa_n:2BkjCZpjJOBC5u-bQ:40mail.gmail.com</a><br>

<br>
Recently Nick has been working on making release scripts which will<br>
package dmd.zip automatically, I hope we can work on better VC<br>
integration after that work is done.<br>
<div class="im"><br>
> I suggest:<br>
>  * These should be made central D community projects.<br>
<br>
</div>Most of us are happy enough with syntax-highlighted text editors, so<br>
we likely wouldn't touch any IDE code. I'm not sure what the above<br>
political move would do. There was a period when DWT was elected as<br>
the "official" D GUI, but nothing came out of it. So these political<br>
moves don't really mean a thing.<br></blockquote><div><br></div><div>Most of who? The D devs? You all reject auto-complete and debuggers? How do you get any work done?</div><div>Most of the D developers don't seem to be like most of the commercial software dev's I've ever worked with.</div>
<div>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.</div><div><br></div><div>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.</div>
<div>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">
>    - Deprecate DMD makefiles. Seriously! Insist that contributors use the<br>
> IDE bindings to work on DMD.<br>
<br>
</div>Not gonna happen.<br></blockquote><div><br></div><div>Reconsider.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im">
>    - The fact that you all laughed at the prior point suggests clearly why<br>
> it needs to be done. It will cease to be a problem when all the<br>
> druntime/phobos contributors are suffering the end-user experience.<br>
<br>
</div>Slowing us down won't help anyone.<br></blockquote><div><br></div><div>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.</div>
<div>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.</div><div><br>
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">
>  * They should receive bugs in the main github bug-tracker, so EVERY D<br>
> contributor can see them, and how many there are.<br>
<br>
</div>Bugzilla is better than whatever github has to offer. It's fast and<br>
its very searchable. Github just seems to introduce more and more<br>
useless features every other day (but I can't even search the damn<br>
pull request section, even though there's a "global" search..).<br></blockquote><div><br></div><div>Well bugzilla then, wherever.. Just in the same place.</div><div><br></div><div>I'm really don't like bugzilla as an end-user, but I'm not performing searching actions.</div>
<div>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...</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">
> This goes back to the threads where the IDE guys are writing their own<br>
> parsers, when really, DMD should be able to be built as a lib, with an API<br>
> designed for using DMD as a lib/plugin.<br>
> I think continuous code compilation for auto-completion and syntax<br>
> highlighting purposes should be a service offered and maintained by DMD.<br>
> That way it will evolve with the language, and anyone can use it without<br>
> reinventing the wheel.<br>
<br>
</div>This has been said a million times, but it's a very slow evolution<br>
turning an application into a library, especially one like DMD. The<br>
C++ => D migration process of DMD could maybe help us move into this<br>
direction.<br></blockquote><div><br></div><div>Cool. And yeah, I know, I've seen it raised loads of times.</div><div>Raise it's priority? It's clearly a critical issue, not just a 'yeah that'd be nice'.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">
> There were many instances of people wasting their time chasing bugs in<br>
> random places when it was simply a case of the debugger lying about the<br>
> value of variables to them, and many more cases where the debugger simply<br>
> refused to produce values for some variables at all.<br>
<br>
</div>That sucks.<br></blockquote><div><br></div><div>And needs to be fixed.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im">
> Documentation:<br>
><br>
> Okay for the most part, but some windows dev's want a CHM that looks like<br>
> the typical Microsoft doc's people are used to.<br>
<br>
</div>It's in the windows/bin folder. It's a poor place to put it, it should<br>
better be put in a 'doc' folder or something, and it should be noted<br>
somewhere on the website.<br></blockquote><div><br></div><div>Oh, in bin... Never thought to look there ;)</div><div>I think most users would expect a link in the start menu.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im">
> This code:<br>
>   foreach(i, item; array)<br>
>     if(item == itemToRemove)<br>
>       array = array[0..i] ~ array[i+1..$];<br>
> Got a rather 'negative' reaction from the audience to put it lightly...<br>
<br>
</div>That will allocate a new array. It could have been:<br>
<br>
foreach(i, item; array)<br>
    if (item == itemToRemove)<br>
        array = array.remove(i);<br>
<br>
or even:<br>
<br>
auto idx = array.countUntil(item);<br>
if (idx != -1)<br>
    array = array.remove(idx);<br>
<br>
Although it's still not very pretty. I'm surprised you're using<br>
allocation like that for game development! :)<br></blockquote><div><br></div><div>These are all horrible 'solutions' to remove an item from an array.</div><div>It should be one line.</div><div><br></div><div>It's a 48hr game jam, efficiency is not a priority. Brevity and readability/hackability are of key importance.</div>
<div>Especially when cooperating with a bunch of programmers, with absolutely no discussion about code/systems design.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im">
> It is how quickly classes became disorganised and difficult to navigate<br>
> (like Java and C#).<br>
> We all wanted to ability to define class member functions outside the class<br>
> definition:<br>
>   class MyClass<br>
>   {<br>
>     void method();<br>
>   }<br>
><br>
>   void MyClass.method()<br>
>   {<br>
>     //...<br>
>   }<br>
><br>
> It definitely cost us time simply trying to understand the class layout<br>
> visually (ie, when IDE support is barely available).<br>
> You don't need to see the function bodies in the class definition, you want<br>
> to quickly see what a class has and does.<br>
<br>
</div>I think Andrei mentioned once that this might be a good idea, but it<br>
needs a DIP and formal reviewing, not to mention a solid<br>
implementation. Only this time, no more back-channel introduction of<br>
features like UDAs, please. We ended up having a deprecation for<br>
syntax that never formally existed.<br></blockquote><div><br></div><div>Well, it's still a good idea if you ask me, and my squad of friends at least. ;)</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im">
> Conclusion:<br>
> I think this 48 hour jam approach is a good test for the language and it's<br>
> infrastructure. I encourage everybody to try it (ideally with a clean slate<br>
> computer).<br>
<br>
</div>Clean slate means you run exactly into issues like setting up the<br>
compiler, which does bring these problems to light, but really in a<br>
game-jam full of people wanting to try D, why not come prepared?<br>
</blockquote><div><br></div><div>Are you saying I should have told everyone to set up their machines before coming?</div><div>The decision to use D was made on the spot, upon my insistence...</div><div>Seems I'm making myself unpopular all over the world for recommending D to people, perhaps I should stop ;)</div>
</div></div></div>