On 9/1/13, Brad Anderson <eco@gnuk.net> wrote:
>> What I need from you guys and your different VS installs is, for each one, a bug report with what is necessary to get it installed. Then we can add it to the modern version of my floppy disk "linker collection".
>
> This can be automated easily enough.  The installer can detect what versions of VS are installed and either set an environment variable or modify sc.ini (your choice).  It could probably be made forward compatible since Microsoft has been using basically the same paths and registry keys for every new release since at least VS 2005.

Yes, and VS comes out what, maybe once a year? This is possible to implement and maintain. If it weren't, then installing VS plugins would be impossible, but as far as I know it mostly works out of the box (hell, VisualD does it, so why can't we do something as simple as detect VS paths?)

On 2013-09-01 19:25:10 +0000, Jacob Carlborg <doob@me.com> said:

> On 2013-09-01 18:24, Dmitry Olshansky wrote:
> 
>> 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.
> 
> And Xcode which doesn't even officially supports plugins.

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!

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

On 9/1/2013 1:56 PM, Andrej Mitrovic wrote:
> On 9/1/13, Brad Anderson <eco@gnuk.net> wrote:
>>> What I need from you guys and your different VS installs is,
>>> for each one, a bug report with what is necessary to get it
>>> installed. Then we can add it to the modern version of my
>>> floppy disk "linker collection".
>>
>> This can be automated easily enough.  The installer can detect
>> what versions of VS are installed and either set an environment
>> variable or modify sc.ini (your choice).  It could probably be
>> made forward compatible since Microsoft has been using basically
>> the same paths and registry keys for every new release since at
>> least VS 2005.
>
> Yes, and VS comes out what, maybe once a year? This is possible to
> implement and maintain. If it weren't, then installing VS plugins
> would be impossible, but as far as I know it mostly works out of the
> box (hell, VisualD does it, so why can't we do something as simple as
> detect VS paths?)
>

Pull requests are, of course, welcome.

On 9/1/2013 12:28 PM, Brad Anderson wrote:
> I can make the installer detect which versions of Visual Studio are installed
> and the path they are installed.  Would I rather I have the installer modify the
> installed sc.ini or set an environment variable?

dmd is specifically made to not rely on us setting any environment or system registry variables. So modifying sc.ini is the only solution.

On Sunday, 1 September 2013 at 21:10:23 UTC, Walter Bright wrote:
> On 9/1/2013 12:28 PM, Brad Anderson wrote:
>> I can make the installer detect which versions of Visual Studio are installed
>> and the path they are installed.  Would I rather I have the installer modify the
>> installed sc.ini or set an environment variable?
>
> dmd is specifically made to not rely on us setting any environment or system registry variables. So modifying sc.ini is the only solution.

Sounds good.  I'll get started.

On 9/1/2013 12:21 PM, Walter Bright wrote:
> 2. replace the hardcoded tails that link.c appends to the sc.ini values with new
> settings in sc.ini


https://github.com/D-Programming-Language/dmd/pull/2509

Manu

(answering the OP)

Stupid me, I just adressed similar issues in http://forum.dlang.org/thread/jlssvljpdgxlubdajwyy@forum.dlang.org ("End user experience with D") because first I thought this here was about game development (which I don't care about).

Short version: I agree with Manu. Completely. Strongly.

One warning tough: We should differentiate between "essential" and "nice but not urgent". For a simple reason: Feasibility.

Sure, .chm help would be nice for Windows users but frankly, good doc at all are more important; if it's, say, HTML that's good enough for a start.

As for an IDE we should definitely favour something cross platform (and non-java!!!) rather than caring about peculiarities of Windows, OSX, lx/kde, etc. Those can be done later. Really important is to have a base asap.

The killer: Debugging.

GDB is bare minimum and seeing adresses of structures rather than the members and their values is basically worthless.

When trying a new language I usually do a small project: "osnsort", i.e. a utility that takes (usually via a pipe from 'du -h') lines with OS style numbers (like "4,3M" for 4,4MB filesize) and then sorts those lie properly (unlike sort which lousily fails).
While D nicely showed some of its strengths and the coding was really enjoyable and the docs good enough for someone with a C background) I soon found myself inserting lots of "debug" statements as a "more elegant" version of the old "#ifdef DEBUG printf(...) #endif". *** YUCK!!! ***

Putting it bluntly: D is so great, so powerful, so nice language that it's worth a lot of efforts. With any other language I would have turned away and taken it to be a hobby thingy.

So, we must not please everyone and take care of their OS issues right now, but we definitely need some kind of, if somewhat crude, working base in terms of debugger support, IDE and docs.

A+ -R

On Sunday, 1 September 2013 at 11:43:53 UTC, 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. Editing is a matter of launching Sublime Text 2. Compiling is alt-tabbing to the command prompt and typing "dub build". It's a painless process and I never have any trouble. Of course, I don't try to use the MS tools, or build DMD myself. That way lies pain.

For a few releases now the D installer for Windows has created a start menu shortcut that launches cmd.exe with dmd et al. added to the PATH.  It also adds to the PATH during installation if you let it.

=============== INTERRUPT ================

Can we, please, just for a moment leave details aside?



Dear Walter Bright

There are currently 3 threads addressing more or less the same issue: user experience.

You have, no doubt, created a wonderful, great and promising language. That's why we're here.

Yet we have heard from users who left. Not because D isn't good enough - actually it's so good that some at stay loosely connected and read and write here - but because in order to be useful and to grow and spread all over the universe, the power, the beauty and the elegance of a language must be found in practically interaction, too. In other words: user experience.

It seems in that context there are mainly 3 points coming up:

- IDE
- Docs
- Debugging

And I'd like to add a 4th: C library bindings.

Obviously neither you nor any 3 or 5 of us can possibly make *every*one happy. Equally obviously, making too many not happy leads to potential D users leaving the language.

Shouldn't we find some reasonable common grounds? Shouldn't we at least discuss and create a rough ToDo route with some priorities?

There are, for instance, tools out there that allow to create various common formats for documentation, incl. HTML and .chm.
Shouldn't we make an effort to identify and agree (or, if necessary, a dictum by you and/or Andrei) on some cross platform tool for documentation so as to be able to create all needed formats from one set of docs?

Thanks for D and - please - let us do the next step now. Let us not debate over Eclipse vs. Vim but agree that at least 1 cross platform IDE must be supported along with at least 1 cross platform Editor. Let us not only address language issues and problems with a narrow view but let us at the same time keep our mind open for the larger picture.

And let us agree that a not yet perfect language along with well useable and realiably working tools is worth at least as much as an ever more refined language with lousy, alpha, broken old, or simply not reasonably useable tools.
The same goes for the tools. Let us have 1 set of cross platform tools, even primitive ones but realiable and reliably working ones rather than striving to have a variety tools for each and every OS and whim addressing every minute detail coming up.

Let's build a base - and then conquer the world.

On 9/1/2013 2:04 PM, Michel Fortin wrote:
> Piece of cake!

I agree!