On 2013-09-01 23:04, Michel Fortin wrote:

> But reverse-engineering Objective-C classes knowing only the name of
> classes and their methods is so much fun! How can people not be
> interested in running Xcode inside the debugger to follow what calls
> what? Then all you have to do is inject some code at the right place to
> subvert the IDE into compiling your D code, tracking D module
> dependencies, and suggesting completions as you type. Piece of cake!

Hehe :)

-- 
/Jacob Carlborg

On 2 September 2013 16:05, Walter Bright <newshound2@digitalmars.com> wrote:

> On 9/1/2013 10:01 PM, Manu wrote:
>
>> How about the DirectX SDK?
>> http://www.microsoft.com/en-**us/download/details.aspx?id=**6812<http://www.microsoft.com/en-us/download/details.aspx?id=6812>
>> It's super standard aswell for anyone working on multimedia software.
>> It has an environment variable on my machine: DXSDK_DIR = C:\Program Files
>> (x86)\Microsoft DirectX SDK (June 2010)\
>>
>
> How about:
>
> LIBPATH64=%VCINSTALLDIR%lib\**amd64;%WindowsSdkDir%lib\x64;%**DXSDK_DIR%
>
> in your sc.ini?
>

Yeah, that's what I did. I'm just suggesting it should be detected and added by the installer.

On Monday, 2 September 2013 at 03:51:54 UTC, Manu wrote:
> On 2 September 2013 05:20, Jacob Carlborg <doob@me.com> wrote:
>> Gave up? Why not just use DMD directly from the zip on the command line
>> and use TextMate or Sublime. TextMate 2 supports in app download of new
>> languages and Sublime comes with support for D out of the box. Even though
>> it's not perfect it has to be better than giving up.
>>
>
> I dunno. People just don't do that.
> It's perceived that typing commands in the command line is a completely
> unrealistic workflow for most people that doesn't love linux.

It is more of a cultural issue than real tool stack issue. Yes, I am perfectly aware that Microsoft has succeeded in creating incredibly closed and tool-oriented programming environment and also succeeded to create lot of programmers that accept it as the only possible way to do things. I am perfectly aware that game dev industry is completely Microsoft-centric and is forced to accept such rules of the game.

But do you seriously expect anyone with no personal business interest to work on brining more of such crap into something that is not broken? You would have had my sympathy but demand "Let's force everyone to use IDE" is just insane. All this thread would have made some sense if some enterprise D entity has existed but it simply does not work that way right now. And, to be honest, I am glad about it.

On Sun, 01 Sep 2013 16:32:06 +0200, Manu <turkeyman@gmail.com> wrote:

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

Here's something D lets you do today:

class Foo {
// Definition:
    // Forbles the grabblies.
    void bar();

// Implementation:
    void bar() {
        myGrabblies.forble();
    }
}

It does not get rid of the tabs, and has no checking that all functions
are present in the definition (the compiler gets confused if only the
definition is there), but it does give a nice list at the top.

If you want the definition in a different file, and no class Foo { in the
implementation file, you can do this:

// foo.d
class Foo {
    // Forbles the grabblies.
    void bar();

    import("foo_imp.d");
}
----------------------------
//foo_imp.d:

bar() {
    myGrabblies.forble();
}

That gives no inline indication of which class the functions belong to,
though. Also, no global functions in foo_imp.d.

Now, neither of these solutions are perfect, but they might be good enough.
I'd also like to see implementation separate from definition, but I feel
dmd -H could do that job nicely by including comments, or possibly by
dmd -D with the correct ddoc template.

-- 
Simen

On 2 September 2013 18:14, Mike Parker <aldacron@gmail.com> wrote:

> On 9/2/2013 11:54 AM, Manu wrote:
>
>>
>> DirectX, Microsoft's multimedia API?
>> http://www.microsoft.com/en-**us/download/details.aspx?id=**6812<http://www.microsoft.com/en-us/download/details.aspx?id=6812>
>> It installs bunches of libs in their own directory, I think you should
>> include them in sc.ini by default.
>>
>> DirectX does appear to have an environment variable on my machine:
>>
>>    DXSDK_DIR = C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\
>>
>> So if you map: %DXSDK_DIR%Lib\x64 that will make the libs available.
>>
>
> MS has stopped making new versions of the DirectX SDK. Everything now ships as part of the Windows SDK.
>
> See http://msdn.microsoft.com/en-**us/library/windows/desktop/**
> ee663275(v=vs.85).aspx<http://msdn.microsoft.com/en-us/library/windows/desktop/ee663275(v=vs.85).aspx>
>

Yeah, but DMD is tested against VS2010, and many users of VS2010 still exist (like me, and all but one of my friends on the weekend). Which means the DXSDK package is still totally relevant.

On Monday, 2 September 2013 at 12:54:41 UTC, Simen Kjaeraas wrote:
> If you want the definition in a different file, and no class Foo { in the
> implementation file, you can do this:
>
> // foo.d
> class Foo {
>     // Forbles the grabblies.
>     void bar();
>
>     import("foo_imp.d");
> }
> ----------------------------
> //foo_imp.d:
>
> bar() {
>     myGrabblies.forble();
> }
>
> That gives no inline indication of which class the functions belong to,
> though. Also, no global functions in foo_imp.d.

That is pretty fun trick but it is so preprocessor-flavored! :( Also it is likely to confuse lot of semantic analysis tool. Still may be a viable hack.

On 2 September 2013 18:25, Jacob Carlborg <doob@me.com> wrote:

> On 2013-09-02 05:51, Manu wrote:
>
>  I dunno. People just don't do that.
>> It's perceived that typing commands in the command line is a completely
>> unrealistic workflow for most people that doesn't love linux.
>> He would have also had to have written himself a makefile, and none of
>> us know how to write a makefile. I generate makefiles with other tools,
>> but there are no good makegen tools that support D and C projects
>> together, and even if there were, you'd just be writing a makegen script
>> instead, which we still didn't know how to write...
>> We also really didn't have time to stuff around with it. He just went
>> and recorded audio instead.
>>
>
> I would have used a shell script but I get your point.
>
>
>  Fair enough. Well I don't have a Mac, and I don't know Cocoa, or ObjC...
>> :/
>>
>
> Hehe. You do already support iOS, how was that added?


Some time back when I did have a Mac, and I lifted the boot code from a sample app, and then the rest of the code just fell into place because it's super system-agnostic.

 Good IDE's have awesome refactor tools, where you change a signature,
>> and it will change it at all places that it is referenced.
>>
>
> Then your back to need of an IDE to use the language.


Yeah, except this seems like a more sensible application of an IDE helper
to me, and it's not required by any means for the language to be useful.
Since the code can be read in any number of locations, and expecting the
IDE to assist you with making the code readable makes no sense.
Rather, move the 'burden' to the authoring stage, and the IDE can equally
help there, but the advantage is readability anywhere without IDE support.

On 02/09/13 14:51, Dicebot wrote:
> But do you seriously expect anyone with no personal business interest to work on
> brining more of such crap into something that is not broken? You would have had
> my sympathy but demand "Let's force everyone to use IDE" is just insane. All
> this thread would have made some sense if some enterprise D entity has existed
> but it simply does not work that way right now. And, to be honest, I am glad
> about it.

Personally I find, observing a number of different open source projects, that a very typical problem is a kind of "selection bias" among contributors that leads them to significantly under-appreciate the usability problems of their software.

It goes something like this: anyone who has spent any length of time using that software (which of course includes most contributors) either had a workflow and toolchain that the software matched with, or they have been able to adapt their workflow and toolchain to enable them to use the software.  Usually they have managed to find ways of coping and working around any other usability issues that arise.  And that situation then compounds itself over time because new users come and either adapt in the same way that existing contributors have, or they leave.

So, you wind up with a body of contributors who often have much in common in terms of their setup, their perception of the priorities, and in their ability to handle the software.  And that in turn can be very dangerous, because you get people who simply don't understand (or have any way to experience) problems that are brought to them by new users or by others.

And of course there are always greater problems than usability, so those problems are the ones that get focused on, with the developers all the while bemoaning the lack of manpower and wondering why it is so difficult to attract and hold on to contributors.

The only way that I can see to avoid that trap is to have a strong focus on usability as part of your development process, to make sure that developers have good connections with a diverse range of potential users and their experiences, and (where possible) for developers to dedicate part of their time to actually trying to undergo that experience themselves.

The TL;DR of what I'm saying here is: while it's certainly crazy to force D contributors to use IDEs, there's a great deal of value in making sure that a good number of contributors regularly get IDE experience, and regularly try out "fresh start" installs of D in IDE and non-IDE environments, because that way you have a sense of how easy or painful it is for new users to get things installed and just get hacking.

On Monday, 2 September 2013 at 13:36:12 UTC, Joseph Rushton Wakeling wrote:
> Personally I find, observing a number of different open source projects, that a very typical problem is a kind of "selection bias" among contributors that leads them to significantly under-appreciate the usability problems of their software.
>
> <snip>

There is a notable difference between making contribution easier and improving user experience. One thing that is often misunderstood about open-source driving power is that it is in fact very egoistic. You do stuff that is useful to you and share it with others because it costs you nothing and benefits in the long run. But key target user tends to be developer itself, not some kind of "end" user. Of course there is some place for idealistic motivation but in my opinion this is most important part in open-source success.

On 2 September 2013 22:51, Dicebot <public@dicebot.lv> wrote:

> On Monday, 2 September 2013 at 03:51:54 UTC, Manu wrote:
>
>> On 2 September 2013 05:20, Jacob Carlborg <doob@me.com> wrote:
>>
>>> Gave up? Why not just use DMD directly from the zip on the command line
>>> and use TextMate or Sublime. TextMate 2 supports in app download of new
>>> languages and Sublime comes with support for D out of the box. Even
>>> though
>>> it's not perfect it has to be better than giving up.
>>>
>>>
>> I dunno. People just don't do that.
>> It's perceived that typing commands in the command line is a completely
>> unrealistic workflow for most people that doesn't love linux.
>>
>
> It is more of a cultural issue than real tool stack issue. Yes, I am perfectly aware that Microsoft has succeeded in creating incredibly closed and tool-oriented programming environment and also succeeded to create lot of programmers that accept it as the only possible way to do things. I am perfectly aware that game dev industry is completely Microsoft-centric and is forced to accept such rules of the game.
>
> But do you seriously expect anyone with no personal business interest to work on brining more of such crap into something that is not broken? You would have had my sympathy but demand "Let's force everyone to use IDE" is just insane. All this thread would have made some sense if some enterprise D entity has existed but it simply does not work that way right now. And, to be honest, I am glad about it.
>

Okay, I clearly made my claim too strongly, but I still think it would be
valuable for basically everyone to try it out every now and then, and
understand the experience on offer.
Sure, each to their own thing... I just wanted to stress that a higher
consideration to the end-user experience wouldn't go astray.