On Mon, Sep 02, 2013 at 12:32:06AM +1000, Manu wrote:
> On 1 September 2013 19:57, Jacob Carlborg <doob@me.com> wrote:
[...]
> > 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?

If I wanted to to that, I'd setup folding in vim to fold function bodies. There's nothing inherently wrong with fully-defined functions inside their class -- Java does it, and I don't hear Java programmers complain about that.


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

I dunno, this sounds to me like maybe your class design needs to get looked at. :) I usually try to structure my code such that class methods are relatively short and self-contained, and I don't end up with classes with 50 methods each 10 pages long.


T

-- 
Customer support: the art of getting your clients to pay for your own incompetence.

On Sun, Sep 01, 2013 at 12:40:00PM +0200, Dicebot 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!" :)

+1. :)


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

The thing is, we keep hearing complaints about how D IDE integration is bad, etc., but it seems like not many people are willing to do something about it. What we need is somebody who is (1) dedicated to D, (2) dedicated to making IDE integration for D work nicely, (3) produce lots of code to make it work.

Forcing people to change the way to work on D just so you can have IDE integration probably won't have much of an effect. For instance, I wouldn't touch an IDE with a 10-foot pole. Will I still contribute to D? Sure. Will I do something about IDE integration because everyone complains about it? Unlikely. Will I be glad if somebody steps up and say, here's what I've been doing to make D IDE integration better? I'd fully support it. The question is whether there is such a somebody. :)


T

-- 
First Rule of History: History doesn't repeat itself -- historians merely repeat each other.

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

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.

On Monday, 2 September 2013 at 01:41:51 UTC, Brad Anderson 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
>
> 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.

Err, ignore the last sentence.  I forgot that it was probably the path tail issue I was hitting.

There are only 2 visual studio related environment variables on my machine:

VS100COMNTOOLS = C:\Program Files (x86)\Microsoft Visual Studio
10.0\Common7\Tools\
VS110COMNTOOLS = C:\Program Files (x86)\Microsoft Visual Studio
11.0\Common7\Tools\

But in general, I reckon it's probably bad practise to rely on environment variables in Windows. They're usually a complete mess, and hard to manage.


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

> On 9/1/2013 2:25 AM, Dmitry Olshansky wrote:
>
>> To get it to work with say VS11 I had to kill VCINSTALLDIR &
>> WindowsSDKDir and
>> set LIB/LINKCMD paths by hand in Environement64.
>> Whatever magic setup code there is for VS10/WinSDK7 it doesn't work with
>> VC11/WinSDK8.
>>
>
> What environment variables did VS11 set?
>
>

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

> On 9/1/2013 2:46 AM, Simen Kjaeraas wrote:
>
>> Like Dmitry said, it might work for 2010, but it certainly does not 'just work' for 2012 and 2013. I've probably spent twelve hours setting up DMD Win64 on my two confusers.
>>
>
> I need specifics.
>
> Again, what environment variables are setup by these other VS's? What did you put in your sc.ini?
>
> I don't have multiple VS installs.
>

My sc.ini looks like this, I also broke dmd2/windows/lib into lib and lib64:

[Version]
version=7.51 Build 020

[Environment64]
LIB="c:\Program Files (x86)\Microsoft Visual Studio
10.0\VC\lib\amd64";"c:\Program Files (x86)\Microsoft
SDKs\Windows\v7.0A\Lib\x64";"C:\Program Files (x86)\Microsoft DirectX SDK
(June 2010)\Lib\x64";"%@P%\..\lib64"
DFLAGS=-m64 "-I%@P%\..\..\src\phobos" "-I%@P%\..\..\src\druntime\import"
LINKCMD64=%VCINSTALLDIR%bin\amd64\link.exe

[Environment]
LIB="%@P%\..\lib";\dm\lib
VCINSTALLDIR=C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\
DFLAGS=-m64 "-I%@P%\..\..\src\phobos" "-I%@P%\..\..\src\druntime\import"
LINKCMD=%@P%\link.exe
LINKCMD64=%VCINSTALLDIR%bin\amd64\link.exe
WindowsSdkDir=C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A

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

> On 9/1/2013 6:19 AM, Manu wrote:
>
>> Hmmm, I found details on the net that recommended adding an
>> [Environment64]
>> section, which we did.
>>
>> I don't seem to have VCINSTALLDIR or WindowsSdkDir variables on my system
>> :/ ..
>> that said, VC obviously works on my machine.
>>
>
> Sorry if I am being repetitive here, but what environment variables is VS setting on your machine?


I don't have any that look meaningful, other than the TOOLS ones in my prior reply.

 It also seems potentially problematic that a variable would define a single
>> install directory, since it's pretty common that programmers have multiple
>> versions of VS on their machines.
>> I have VS2010 and VS2012 on my machine. Simon had VS2012 and VS2013.
>>
>
> Yes, so what environment variables should sc.ini use to determine which one the user wants to use for dmd?


I think it should search through program files on installation. User might
have non-standard installation path name.
But I also think the paths should be supplied by Visual-D when running
inside VisualStudio, since it's running within the version of VS that you
actually want to use, so it can set the appropriate paths for that version
(I've raised this with Rainer).

 I was also thinking it might be a mistake to keep phobos64.lib in the same
>> folder as the 32bit omf libs. If paths are wrong, the link errors will
>> only be
>> understood by a programmer who understands compilers and lib/object
>> formats in
>> depth.
>> Perhaps you should put them in a parallel lib64 directory, and hook that
>> up in
>> [Environment64] (I did that on my machine while trying to isolate
>> problems and
>> wort out where paths were coming from)?
>>
>
> Please, I need specifics.


Put phobos64.lib and friends in lib64/, beside lib/

 I reckon you should look into hooking up DirectX SDK patahing by default
>> too
>> since it's so common for basically any multimedia app.
>>
>
> I have no idea what you mean by this?
>

DirectX, Microsoft's multimedia API?
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.

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

> As a followup,
>
> When I installed VS2010, it created a shortcut on my desktop labelled "Visual Studio x64 Win64 ...". Clicking on that opened a command line window.
>
> In that window, I could compile and run VC programs from the command prompt using CL, LINK, etc.
>
> In that window, if I typed:
>
> SET
>
> at the prompt, it showed the environment variables set, which included:
>
> VCINSTALLDIR - where VC was installed
> WindowsSdkDir - where the SDK was installed
>
> This is all dmd needs in order to use VS2010.
>
> However, I didn't want to have to click on that shortcut just to use -m64, so I merely copied the values VCINSTALLDIR and WindowsSdkDir into my own personal sc.ini, and then dmd -m64 worked fine.
>

Ah yes, that batch file... that explains it.
Maybe what you can do is scan the users Program Files for the batch file,
and then pull those lines from it? (A bit hackey...)

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

> On 9/1/2013 7:02 AM, Manu wrote:
>
>> I know Walter does care about the DMD-Win64 debuginfo quality, but I
>> don't think
>> the debuginfo output is capable of addressing all the problems alone.
>>
>
> I (and others like Rainer who help a lot with Win64 support) also cannot do a thing without targeted bugzilla reports.
>

How do you feel about using the DMD-Win64 + Visual-D suite as a dev
environment when working on druntime+phobos for a while? Try debugging some
issues using the VS debugger...
I've suggested that devs need to understand the end-user experience. I
think you'd reveal a lot of the really trivial issues (that are non-trivial
in aggregate) very quickly.

I'll continue to log bugs as I find them, I didn't this weekend because when finding a bug, I then need to spend the time to boil down a minimal repro case, and we were working against the clock >_<

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

> On 9/1/2013 6:55 AM, Manu wrote:
>
>> 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 really appreciate your efforts here.
>
> What Rainer needs is, I assume, the same things I need. Very specific lists of what went wrong.
>

Yup, but there's so many bugs in his bug tracker. It seems clear to me he
needs help.
I talked with him a lot at DConf. As I understand it, most of the problems
are because both his and Alexander Bothe's semantic analyser's just aren't
as good as the D front end.

This comes back to my point about it being a separate satelite project. I wonder if it might help with visibility of these problems if it were included in the central github organisation, and bugs present in the main bug tracker that everyone can see and looks at regularly.