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

> On 2013-09-01 16:32, Manu wrote:
>
>  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...
>>
>
> 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.
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.

Side note; I'm working on support in premake for parallel C and D project generation for popular IDE's and makefiles. But it's not there yet.

 If you'd like to help me finish that OSX work we started together last
>> year, that'd be really great for next time! :)
>>
>
> Well, I'm quite busy with my own projects. But I could perhaps give you a hand if you need. Although I don't want to do all the work as last time.
>

Fair enough. Well I don't have a Mac, and I don't know Cocoa, or ObjC... :/

 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?
>>
>
> To keep everything in one place. Why would you want to duplicate the method signatures? I hate the header/source synchronization in the C family of languages. Especially in C++ where the signatures cannot even be exactly the same between the header and source file. I'm thinking of default values, for example.
>

I'm not suggesting it be in a separate file, Just below the class
definition somewhere.
The IDE actually can help here. If it detects you've modified a function
signature, and it's defined lower in the file, it can fairly easily change
it for you there too.

 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.
>>
>
> That I agree with.
>

So the conclusion is to put the IDE's assistance burden on the authoring
side, not the reading side.
Ie, when you change a function signature, IDE can update the definition's
signature too.

Good IDE's have awesome refactor tools, where you change a signature, and it will change it at all places that it is referenced.

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

> On 2013-09-01 16:36, Manu wrote:
>
>  Give me one advantage to defining methods inline? I only see
>> disadvantages. Lots of them.
>>
>
> Give me one advantage to repeat the method signature.


I've listed them, but again:
 * You can read the class declaration; what it has, and does, at a glance.
 * Function's don't have a few extra tab's of white space by default. This
means you can more easily understand the flow of code within your class.
 * Your code uses less horizontal space.
 * I find it easier to review commit's in diff's, since I can clearly see
separation between API changes, and function implementation changes.

I find it much easier to detect the difference between 0, 1 and 2 tabs
deep, than 2, 3 and 4 tab's deep.
I believe there's an exponential falloff to your precision wrt estimating
tab depth the deeper it gets. This makes the code less easy to follow; "Am
in inside a loop, an if block, or a local function? What depth is the outer
scope of the function anyway?" while skimming through code.

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

> On 9/1/2013 11:58 AM, Dmitry Olshansky wrote:
>
>> 01-Sep-2013 22:44, Walter Bright пишет:
>>
>>> On 9/1/2013 11:01 AM, Dmitry Olshansky wrote:
>>>
>>>> The only one I see is
>>>> VS110COMNTOOLS
>>>>
>>>
>>> Very strange. When I click on the shortcut "Visual Studio x64 Win64..." to open a command prompt, it sets a veritable blizzard of environment variables.
>>>
>>
>> Ah, that command prompt...
>> VCINSTALLDIR=C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\
>> WindowsSdkDir=C:\Program Files (x86)\Windows Kits\8.0\
>>
>> However the said windows kit folder has tree like this:
>> C:\Program Files (x86)\Windows Kits\8.0\Lib\win8\um\{arm,x86,**amd64}
>>
>> That 'win8\um' sub-folder is what must be throwing it off. It's nothing
>> like
>> that in Win7 SDK.
>>
>>  There are 2 distinct things - libraries are ound in Platform SDK (or
>>>> rather
>>>> WindowsSDK these days) and version 8 differs from 7. You can download
>>>> and
>>>> install it (any version) - it's a free download.
>>>> Compiler/linkers are installed to VisualStudio and are dealt with
>>>> separately.
>>>>
>>>> I still have this error when trying to comompile with debug info:
>>>>
>>>> LINK : fatal error LNK1101: incorrect MSPDB110.DLL version; recheck
>>>> installation
>>>> of this product
>>>>
>>>> No idea whose fault is it (DMD vs MS linker vs something in my
>>>> paths/env).
>>>>
>>>
>>> DMD does not load any DLLs.
>>>
>>
>> Okay, then it could very well be just me messing with paths/env.
>>
>> OT: MS x64 compiler too could be had for free (it come with SDK I
>> installed not
>> VS express)
>>
>>  + I have to redefine everything in order to compile phobos/druntime as
>>>> these are
>>>> hardcoded to VS10 (again !) thus I don't usually test/build x64
>>>> Phobos. It's far
>>>> less hassle for me to keep around x64 Linux virtual box for testing.
>>>>
>>>
>>> When I compile phobos, for example, I use the following makefile (named "makefile"). It is very handy for resetting the environment variables used by win32.mak.
>>>
>>> --------------
>>> # Makefile to build D runtime library phobos.lib for Win32 # Designed to work with \dm\bin\make.exe
>>>
>>
>> Thanks! I could borrow that.
>> With that said I don't quite like Makefiles at all.
>>
>>
> I think the most practical thing at the moment is to:
>
> 1. put comments in sc.ini explaining it better
> 2. replace the hardcoded tails that link.c appends to the sc.ini values
> with new settings in sc.ini
> 3. provide commented-out example settings for each variant of VS as we
> discover what they should be
>

And if we still rely on sc.ini to get it right:
4. As the final step of the DMD installer, open sc.ini in notepad for the
user's approval.

On 2 September 2013 05:28, Brad Anderson <eco@gnuk.net> wrote:

> On Sunday, 1 September 2013 at 07:42:47 UTC, Walter Bright wrote:
>
>> On 8/31/2013 7:05 PM, Manu wrote:
>>
>>> 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.
>>>
>>
>> The default sc.ini contains:
>> -----------------------------
>> [Version]
>> version=7.51 Build 020
>>
>> [Environment]
>> LIB="%@P%\..\lib";\dm\lib
>> DFLAGS="-I%@P%\..\..\src\**phobos" "-I%@P%\..\..\src\druntime\**import"
>> LINKCMD=%@P%\link.exe
>> LINKCMD64=%VCINSTALLDIR%bin\**amd64\link.exe
>> VCINSTALLDIR=%VCINSTALLDIR%
>> WindowsSdkDir=%WindowsSdkDir%
>> ------------------------------**----
>>
>> When I installed VC 2010, it set the environment variables VCINSTALLDIR and WindowsSdkDir. Then, the default sc.ini should "just work".
>>
>> What went wrong, specifically?
>>
>
> 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?
>

Avoid environment variables in windows, if you ask me. They are a mess, and
they are hard to manage through the stupid UI hidden in system
settings->advanced->advanced->environment variables.
I think most windows users would consider sc.ini much simpler, but the most
important thing is that they need to know it's there, and that it's
critical that it's correct.

Another idea is to enhance DMD's error messages to warns about correct paths in sc.ini when it either fails to find link.exe, or encounters an OMF library (the two tell-tale errors that sc.ini is wrong).

On 2 September 2013 05:35, Vladimir Panteleev <vladimir@thecybershadow.net>wrote:

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

It can have a link inserted in the start menu. I don't usually go looking for doc's in bin/...

If I were gonna be picky, the index seems incomplete. Open it up, click the
'index' tab, and type tostringz... it's not there.
I think it's also very unnatural for a chm to have the module's functions
all on the one page. Can they be broken up into separate articles?

But it's fine. The the main problem I had with it, is that I had no idea it existed. I didn't look in bin/.

On 2 September 2013 05:44, Brian Schott <briancschott@gmail.com> wrote:

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

Well you can look at Remedy's experience. I've also sparked interest in
staff from a few other companies when talking to developers.
It'll never fly though if when they go to try it out, they're met with the
kind of experience I had on the weekend.
Don't underestimate how much people hate C++ these days.

On 2 September 2013 06:00, Walter Bright <newshound2@digitalmars.com> 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.
>

MS always release preview versions to toolchain/workflow vendors though. You just need to register interest to get access afaik.

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

I don't think my 2010 install is non-standard in any way...

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

I posted my sc.ini in a prior post. I'll try and get Simon's from him, since he was on 2012.

On 2 September 2013 11:41, Brad Anderson <eco@gnuk.net> wrote:

> On Sunday, 1 September 2013 at 21:08:24 UTC, Walter Bright wrote:
>
>> 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.
>>
>
> https://github.com/D-**Programming-Language/**installer/pull/22<https://github.com/D-Programming-Language/installer/pull/22>
>
> It can detect (through registry keys) the paths of Visual C++ 10, 11, and 12 (2010, 2012, and 2013) and Windows SDK 7.0A, 7.1A, 8.0, and 8.1.  It modifies the sc.ini installed from the zip file by substituting the defaults with the detected paths (which makes it important I have accurately reflected what the sc.ini defaults will be).
>
> I only have VC 10 to test with myself (and lack the disk space to have concurrent installations of all 3).  I installed the Windows SDK 7.0A (comes with VC 10), 8.0, and 8.1 though I couldn't actually use 8.0 and 8.1 successfully because of the path tail issue Dmitry pointed out (and you opened a pull request to fix).
>
> The combination of VC 10 and SDK 8.1 did not work (link errors) but VC 10 with 7.0A worked perfectly.  I imagine you need to pair the SDK with the version of VC that was released around the same time.
>

Huzzah! Give the man a beer! :)

How about the DirectX SDK?
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)\

On 9/1/2013 9:15 PM, Manu wrote:
> Well you can look at Remedy's experience. I've also sparked interest in staff
> from a few other companies when talking to developers.
> It'll never fly though if when they go to try it out, they're met with the kind
> of experience I had on the weekend.
> Don't underestimate how much people hate C++ these days.

Your work is really valuable to D. Please make sure all the problems you encountered wind up as bugzilla entries!

On 9/1/2013 6:41 PM, Brad Anderson wrote:
> On Sunday, 1 September 2013 at 21:08:24 UTC, Walter Bright wrote:
>> Pull requests are, of course, welcome.
>
> https://github.com/D-Programming-Language/installer/pull/22

It's just like ordering pizza!!!

Brad, you Da Man!