On Sunday, 1 September 2013 at 19:29:00 UTC, 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?

I meant "Would you rather I..."

On Sunday, 1 September 2013 at 02:05:51 UTC, Manu wrote:
> 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. Those that aren't familiar
> with the CHM viewer; it's just HTML but with a nice index + layout tree.

What can be improved in the CHM that's currently bundled with DMD?

On 2013-09-01 16:59, Michel Fortin wrote:

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

It's make sense but it's not very convenient.

-- 
/Jacob Carlborg

On 9/1/13, Walter Bright <newshound2@digitalmars.com> wrote:
> 3. provide commented-out example settings for each variant of VS as we
> discover
> what they should be

Imagine if after installing Windows 7 you were provided with a boot.ini file which didn't work, but hey, it had commented out examples on how to make the system properly boot. You weren't even give info on which partition the system installed, the manual says "Check your hard drive vendor instructions".

This isn't a 1-click install, and it's still a usability issue.

I know you seem to hate automation (because it sometimes fails), but having each individual person waste hours on initial setup is much worse than having a script which can potentially fail. At least the script can be fixed once the bug is reported, and it can be tested.

On Sunday, 1 September 2013 at 18:36:39 UTC, SomeDude wrote:
> I think at this point, what D needs is a bit of commercial support from a company like JetBrains or some equivalent. Maybe there is now an opportunity for founding such a company, one that would specialize in building professional tools around the D language. I believe the language and the compilers are stable enough to grow a serious business around them. If we compare to what the state of C++ compilers was before 2000, I believe we are much better off. And that was just over a decade ago. Who knows what the state of D will be in 5 years ? So yes, there is a case to be made for growing a company around pro D tools, and the first company that does it will grab the whole market.

It's a bit of a chicken-and-egg problem. I'd like to do this, but there would have to be several companies already using D professionally for it to be a viable business model. And for a company to invest in D, they'd probably want the tooling to already exist.

On 9/1/2013 12:38 PM, Andrej Mitrovic wrote:
> I know you seem to hate automation (because it sometimes fails), but
> having each individual person waste hours on initial setup is much
> worse than having a script which can potentially fail. At least the
> script can be fixed once the bug is reported, and it can be tested.

Back in the bad old Datalight C days, I relied on the Microsoft linker which came on the DOS system disks. Unfortunately, Microsoft constantly changed it, even with the same version of DOS. Worse, numerous other Microsoft products came with yet other versions of LINK.EXE.

All those linkers behaved differently.

It was a frackin' nightmare to support customers with them. I used to have floppy disks packed full of just different versions of LINK.EXE.

This drove me to get our own linker (BLINK.EXE). While it wasn't perfect, either, at least I could actually fix problems with it rather than throwing up my hands in rage being unable to control the situation.

There's no way we can automate VC 2014 so its unpredictable configuration will work. All we can do is react after the fact.

I don't hate automation. sc.ini works out of the box with the default install of VS 2010.

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

On Sunday, 1 September 2013 at 14:14:05 UTC, Manu wrote:
> On 1 September 2013 13:53, Jakob Ovrum <jakobovrum@gmail.com> wrote:
>>
>> dmd2\windows\bin\d.chm
>
>
> Noted. I suggest the installer put a link in the start menu :)
>

https://github.com/D-Programming-Language/installer/pull/21

On Sunday, 1 September 2013 at 14:37:13 UTC, Manu wrote:
> 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.

That's because you're suggesting that if we can't get an immediate overview of class code then it's unreadable which is complete nonsense. Classes do sometimes grow and become large and getting an overview is hard but that doesn't mean the code is unreadable or of low quality. In fact if the developers have bothered to write the associated ddoc comments while developing the code, creating overviews is as trivial as adding -D to the compile command.

An overview of the class's interface should be the job of the documentation or a nice tool such as DDOC, an IDE class overview (there are many), class diagrams, ctags, etc...

IMHO it's total folly to further complicate the language to provide you with something that already exists and i think this particular point is just because of your personal preference on how code should be structured which is obviously drawn from C++.

On Sun, 1 Sep 2013 23:20:37 +1000
Manu <turkeyman@gmail.com> wrote:

> On 1 September 2013 17:46, Nick Sabalausky < SeeWebsiteToContactMe@semitwist.com> wrote:
> 
> > On Sun, 01 Sep 2013 06:45:48 +0200
> > "Kapps" <opantm2+spam@gmail.com> wrote:
> >
> > > On Sunday, 1 September 2013 at 02:05:51 UTC, Manu wrote:
> > > > 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.
> > >
> > > This isn't something I've found to be an issue personally, but I suppose it's a matter of what you're used to. Since I'm used to C#, I haven't had problems with this. I've always felt that this was the IDE's job, personally. That being said, perhaps .di files could help with this?
> >
> > I see it as the job of doc generators.
> >
> 
> Why complicate the issue? What's wrong with readable code?
> 

I spent several years using C/C++ exclusively (and was happy with it
at the time) and I still don't understand what's "readable" about having
a class's members separate from the class itself. It's also a non-DRY
maintenance PITA and one of the biggest reasons I left C/C++.

I don't like complicating things, and I like readable code. That's why I find C++-style class definitions intolerable.

And what's so complicated about tossing in those two little characters: -D

On Sunday, 1 September 2013 at 20:00:19 UTC, Walter Bright wrote:
> On 9/1/2013 12:38 PM, Andrej Mitrovic wrote:
>> I know you seem to hate automation (because it sometimes fails), but
>> having each individual person waste hours on initial setup is much
>> worse than having a script which can potentially fail. At least the
>> script can be fixed once the bug is reported, and it can be tested.
>
> Back in the bad old Datalight C days, I relied on the Microsoft linker which came on the DOS system disks. Unfortunately, Microsoft constantly changed it, even with the same version of DOS. Worse, numerous other Microsoft products came with yet other versions of LINK.EXE.
>
> All those linkers behaved differently.
>
> It was a frackin' nightmare to support customers with them. I used to have floppy disks packed full of just different versions of LINK.EXE.
>
> This drove me to get our own linker (BLINK.EXE). While it wasn't perfect, either, at least I could actually fix problems with it rather than throwing up my hands in rage being unable to control the situation.
>
> There's no way we can automate VC 2014 so its unpredictable configuration will work. All we can do is react after the fact.
>
> I don't hate automation. sc.ini works out of the box with the default install of VS 2010.
>
> 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.  Even if they make a release that the D installer doesn't properly detect fixing that is a 5 minute job by one person (probably me) versus requiring every user to spend a half hour or more (6 hours in Manu's experience) trying to figure out how to get 64 bit working.