On 1 September 2013 19:57, Jacob Carlborg <doob@me.com> wrote:

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


Well we never got OSX working (under mono-d), although this was mainly due
to supporting apple infrastructure in the end. I think we wrangled the
toolchain in the end, but never got everything linking; C++ dependencies
got complicated.
We eventually gave up, just wasting too much time, and he went off and did
the music/sounds for the game...

If you'd like to help me finish that OSX work we started together last year, that'd be really great for next time! :)

 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.


I've never met a C++ developer that likes Eclipse ;)
But I should probably check it out.

 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.


No, actually, as much as I keep banging on the IDE thing, in this case I
absolutely don't want help from the IDE, I just want to look at my page of
text, and be able to read a useful summary.
Can you give me any good reasons why fully defined functions polluting the
readability of a class definition could possibly be a good thing?
I just don't get it... why would you ever want to break up the nice summary
of what a class has&does, and why would you want to indent all of your
functions an extra few tab levels by default?

As a programmer, I spend a lot more time reading code than documentation, and much of that time is spent reading it in foreign places like github commit logs (limited horizontal space), diff/merge windows (hard to distinguish class API changes vs function body changes at a glance, since they're interleaved), even chat clients and communication tools. The IDE can't assist in any of these contexts. If you have to have an IDE to read your code, then something is really wrong.

...also, that implies you have good IDE integration, which is the a central
part of my entire rant! ;)
This argument is invalid until we have that, and at this point, it seems
much more likely we may be able to define methods outside the class scope
than have awesome IDE's.

On 1 September 2013 20:22, Gary Willoughby <dev@nomad.so> wrote:

> On Sunday, 1 September 2013 at 02:05:51 UTC, Manu wrote:
>
>> 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.
>>
>
> Uggh! I absolutely do not agree with this. You should rely on documentation or an IDE class overview for these things *not* alter the language. In lieu of IDE support just use ddoc comments for methods and properties and compile the documentation for each build.
>

I think that's unrealistic. People need to read the code in a variety of
places. Github commit logs (limited horizontal space), diff/merge clients,
office communication/chat tools.
If the code depends on an IDE to be readable, then that's gotta be
considered an epic fail!

Give me one advantage to defining methods inline? I only see disadvantages. Lots of them.

On 1 September 2013 20:40, Dicebot <public@dicebot.lv> wrote:

> On Sunday, 1 September 2013 at 02:05:51 UTC, Manu wrote:
>
>> ...
>>
>>> </endrant>
>>>
>>
> Thought number one after reading "This is why I absolutely hate programming for Windows!" :) Was pretty happy with vim, grep, gdb and makefiles on Linux. Anyway, key problem (as far as I can see) here is that few of D developers have both experience and personal interest in any IDE/Windows focus as well as related tool stack. D has some nice flavor of anarchy - both like it and consider it a problem.
>

Plenty of the key contributors are Windows users, including Walter I
believe.
My suggestion is to encourage dev's to use the same tools the end users are
using, and declare them first-class language features. I reckon it'll
improve quick-smart under that environment.

On Sunday, 1 September 2013 at 14:39:37 UTC, Manu wrote:
> Plenty of the key contributors are Windows users, including Walter I
> believe.

Yes but I'd be surprised to learn that their daily D application domain is as IDE-demanding as your game dev experience.

> My suggestion is to encourage dev's to use the same tools the end users are
> using, and declare them first-class language features. I reckon it'll
> improve quick-smart under that environment.

I simply don't see this working with current D development model. After all, open-source is not about simply working for free - it is about working for yourself and then sharing it. But there needs to be some _personal_ interest in implementing something, end users are just side effect. Well, of course I can't say anything about D dev motivation but I simply can't imagine people spending that much time on something they don't need, are not interested in and gain nothing from.

If anything, that indicates that there needs to be more game dev guys among the core devs.

On Sunday, 1 September 2013 at 14:14:05 UTC, Manu wrote:
> Microsoft's C# intellisense is absolutely spectacular, and there's no
> reason D couldn't be just as good.

There's one very good reason: templates. It makes it substantially more complicated. Further, the C# compiler was designed with Visual Studio integration in mind from the beginning, while DMD is an evolution of DMC++.

On 2013-09-01 13:29:21 +0000, Jacob Carlborg <doob@me.com> said:

> On 2013-09-01 15:18, Andrej Mitrovic wrote:
> 
>> How is deprecating makefiles easier than making whatever IDE that
>> you're using just call a 'make' command when you click a button? Even
>> VS comes with nmake and friends.
> 
> Like the Xcode project does. It calls "make" when building but contains a separate dummy target to allow autocompletion and similar features to work. For some reason those features don't work for make targets.

That's because the Xcode indexer indexes files it knows are included in a target, and Xcode doesn't parse makefiles and thus can't know which files it'll compile (not that it could do so reliably anyway). With another target were all the c/cpp files are marked as being part of it, the indexer does its job.

-- 
Michel Fortin
michel.fortin@michelf.ca
http://michelf.ca

On 1 September 2013 23:24, Jacob Carlborg <doob@me.com> wrote:

> On 2013-09-01 13:44, Mike Parker wrote:
>
>  I have a batch file tied to a command prompt shortcut that always sets
>> the D environment when I launch it. Updating DMD is a matter of deleting the old directory and unzipping the zip file.
>>
>
> Or just use DVM:
>
> https://github.com/jacob-**carlborg/dvm<https://github.com/jacob-carlborg/dvm>


I think infrastructure solutions like this are probably fine, but they're
worthless unless they're installed by default as part of the standard DMD
installer.
If it's robust, convince Walter to include it in the standard installer
package?

01-Sep-2013 06:05, Manu пишет:
> 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.

Just find a way so that it isn't hardcoded (which Walter inevitably seems to end up with).

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

+1

Strangely I went from VisualD to Sublime Text and never look back
- it's far simpler (the overhead of having project/configuration etc.
per short snippet of code I need to try), and STABILITY issues are well, need to be addressed.

> I have come to the conclusion that treating IDE integration as ancillary
> projects maintained by usually just one single member of the community
> has absolutely failed.
> I suggest:
>   * These should be made central D community projects.
>   * I think they should be hosted in the same github organisation as DMD.

Maybe. Though this move alone hardly buys anything unlike e.g. being prominently featured on dlang.org download page that would rise the number of users and bugs reported though (that you propose though).

>   *** As many contributors as possible should be encouraged to work with
> them every day.

So true. But in case of say VisualD there simply not enough of folks with right kind of expertise - that are familiar with VisualStudio SDK + the number of arcane steps to build/integrate it AND have time/inclination to work on it.
Ditto with other IDEs, it's a lot of upfront work to learn the infrastructure + as anything interactive there is no easy test suite to check your tweaks/hacks.

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

While I understand the sentiment it is not a good idea. Makefiles are crap but some modern build tool would do just fine (certainly not specific per IDE project). _Having_ to use some IDE just hurts automation and adds dependency AND rises the barrier of entry (we'd lose all the editor + cmd line guys, and hell they are too amazing to lose).

Not only that but toolchains and core libraries are all about batch processing and easily reproducible test runs - nothing like an interactive app. Hence the large difference in mindset w.r.t. say debugging, as batch tools are far more amendable to printf/assert style of debugging (more specifically postmortem style, including analyzing core dumps/stack traces).

Unless there is some organized effort behind "interactive D" things will keep moving slowly.


-- 
Dmitry Olshansky

On 08/31/2013 07:05 PM, Manu wrote:

> IDE integration absolutely needs to be considered a first class feature of
> D.

This is probably a repeat but Brian Schott has just announced DCD:

  http://forum.dlang.org/post/hrbzrholeoyyriumddjd@forum.dlang.org

Ali

Am 01.09.2013 15:55, schrieb Manu:
>
> Mago is only Win32, and DMD is only Win64... I've tried encouraging the
> Mago guy to support Win64, but it doesn't seem to be a highly active
> project recently. I think this is another case of a 1-man project that
> represents a fairly critical part of the ecosystem.
>

You may be pleased to hear the mago is currently getting 64-bit and pdb support. Its activly beeing worked on, check the svn repository on dsource.org.

>
>
> Sometimes...
> Have you worked with it on a daily basis? It just doesn't work all the
> time. Also, in my experience the auto-complete suggestions are often
> either incomplete, or list heaps of completely unrelated stuff.
> I'm not saying it's bad, it's better than nothing and I really
> appreciate the project (I've said before, if it weren't for Rainer's
> effort, I simply wouldn't use D), but it certainly needs more work,
> especially if I'm going to have any traction selling it to others with
> no vested interest in the language.

I'm not talking about the auto-complete. I talk about the class view. It only works on the .json output of the compiler. If you regularly recompile (which is not an issue with D because it's basically free) you have a nice and clean overview of all your modules, classes and structs. And you can even search that class view to find stuff. It also helps somewhat with auto-completion and "goto definition".
Yes I use it on a daily basis, and yes I know that it's not perfect. You should also go into Options -> Text Editors -> D -> Intelli Sense and play around with the options there to see what works best for you.

>
> But this project approached it from a different angle, ie, a total
> replacement for C++ which does have a rich toolset available. I want to
> use D in this context in the future, and if that were the commitment we
> were considering at Remedy, there's no way we would have gone for it.
>

Yeah I gave a talk about D at Havok recently too and basically got the same response. D simply doesn't have enough tools / momentum to be a option. I use D as a C++ replacement though, and going back to C++ annoys me more and more every day. Better tools are nice, but I'm really missing some features D has when coding C++.