Hi,

it's been a long time since the last release of Visual D, but I hope it wasn't too long. As Visual D moves closer to the dlang.org website, this is the final release that will be available on http://www.dsource.org/projects/visuald. Downloads and documentation are also available at http://rainers.github.io/visuald.

Major changes include

  * Installer now supports VS 2013, updated to cv2pdb 0.27, mago 0.8, fixes x64 debugger in VS 2012 Shell

  * improvements to "Compile and Run"

  * improvements to syntax/coverage highlighting

  * DParser engine now used by default, updated to recent version

  * single file options now available per project configuration

  * added global option to display the reason for building a target

  * added different options for executable and library search paths to be used for Win32/x64

  * link dependencies can now also be monitored for the 32-bit MS linker

  * added commands "Collapse unittests" and "Collapse disabled" to the outlining menu

The full list of changes can be found
here: http://www.dsource.org/projects/visuald/wiki/VersionHistory
or:   http://rainers.github.io/visuald/visuald/VersionHistory.html

Visual D is written in D, source code is available here:
https://github.com/D-programming-Language/visuald

Best,
Rainer

First of all i would like to thank you for making this wonderfull plugin. It was the existance of this pluggin that made me even consider learning D.

This release however broke my setup. Whenever i tried to step into code while debugging it would crash visual studio. I fixed this by changing the debugger to Visual Studio (x86 mixed mode) i'm not sure if i used this debugger in previous versions (i may have) but i had never changed the used debugger until today.

For more information i am using Visual Studio 2012 Ultimate. The application was in DMD 2064 beta 4 (x86 mode).

On 03.11.2013 01:34, TheFlyingFiddle wrote:
> First of all i would like to thank you for making this wonderfull
> plugin. It was the existance of this pluggin that made me even consider
> learning D.
>
> This release however broke my setup. Whenever i tried to step into code
> while debugging it would crash visual studio. I fixed this by changing
> the debugger to Visual Studio (x86 mixed mode) i'm not sure if i used
> this debugger in previous versions (i may have) but i had never changed
> the used debugger until today.
>
> For more information i am using Visual Studio 2012 Ultimate. The
> application was in DMD 2064 beta 4 (x86 mode).
>

I tried to reproduce (within VS2012 Shell) but could not produce any crashes.

Do you have updates for VS 2012 installed? Did you switch back to the "old" engine by enabling "native Edit and Continue" (watches don't work with the new engine?

Does it happen with a standard hello-world program, or does it have to be more involved? If you have a repro case please submit a bug report: http://d.puremagic.com/issues/enter_bug.cgi?product=D

On Sunday, 3 November 2013 at 08:07:41 UTC, Rainer Schuetze wrote:
> I tried to reproduce (within VS2012 Shell) but could not produce any crashes.
>
> Do you have updates for VS 2012 installed? Did you switch back to the "old" engine by enabling "native Edit and Continue" (watches don't work with the new engine?
>
> Does it happen with a standard hello-world program, or does it have to be more involved? If you have a repro case please submit a bug report: http://d.puremagic.com/issues/enter_bug.cgi?product=D

I'm now unable to recreate the bugg. It vanished after an automatic windows update. So i'm guessing that the problem was in my visual studio setup rather then in the Visual D pluggin.

Thanks so much. As I've said before, this is an absolutely critical, yet
often overlooked piece of the ecosystem.
Good to see plenty of life in the project! :)

Note: I saw Alexander Bothe released an update to the parser one day after your release... ;)


On 3 November 2013 00:40, Rainer Schuetze <r.sagitario@gmx.de> wrote:

> Hi,
>
> it's been a long time since the last release of Visual D, but I hope it wasn't too long. As Visual D moves closer to the dlang.org website, this is the final release that will be available on http://www.dsource.org/ projects/visuald. Downloads and documentation are also available at http://rainers.github.io/visuald.
>
> Major changes include
>
>   * Installer now supports VS 2013, updated to cv2pdb 0.27, mago 0.8,
> fixes x64 debugger in VS 2012 Shell
>
>   * improvements to "Compile and Run"
>
>   * improvements to syntax/coverage highlighting
>
>   * DParser engine now used by default, updated to recent version
>
>   * single file options now available per project configuration
>
>   * added global option to display the reason for building a target
>
>   * added different options for executable and library search paths to be
> used for Win32/x64
>
>   * link dependencies can now also be monitored for the 32-bit MS linker
>
>   * added commands "Collapse unittests" and "Collapse disabled" to the
> outlining menu
>
> The full list of changes can be found
> here: http://www.dsource.org/projects/visuald/wiki/VersionHistory
> or:   http://rainers.github.io/visuald/visuald/VersionHistory.html
>
> Visual D is written in D, source code is available here: https://github.com/D-programming-Language/visuald
>
> Best,
> Rainer
>

I just found something surprising.
I went into the 0.3.37 options, saw the 32bit/64bit separation, but noticed
by default, the lib paths were populated like so:

32bit:
$(DevEnvDir)..\..\VC\lib\amd64\
C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Lib\x64

64bit:
$(VCInstallDir)\lib\amd64
C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\lib\x64

Should I be surprised that the 32bit lib paths both point to 64bit libs? Shouldn't the 32bit libs point to the DMD OMF libs?


On 5 November 2013 15:09, Manu <turkeyman@gmail.com> wrote:

> Thanks so much. As I've said before, this is an absolutely critical, yet
> often overlooked piece of the ecosystem.
> Good to see plenty of life in the project! :)
>
> Note: I saw Alexander Bothe released an update to the parser one day after your release... ;)
>
>
> On 3 November 2013 00:40, Rainer Schuetze <r.sagitario@gmx.de> wrote:
>
>> Hi,
>>
>> it's been a long time since the last release of Visual D, but I hope it wasn't too long. As Visual D moves closer to the dlang.org website, this is the final release that will be available on http://www.dsource.org/ projects/visuald. Downloads and documentation are also available at http://rainers.github.io/visuald.
>>
>> Major changes include
>>
>>   * Installer now supports VS 2013, updated to cv2pdb 0.27, mago 0.8,
>> fixes x64 debugger in VS 2012 Shell
>>
>>   * improvements to "Compile and Run"
>>
>>   * improvements to syntax/coverage highlighting
>>
>>   * DParser engine now used by default, updated to recent version
>>
>>   * single file options now available per project configuration
>>
>>   * added global option to display the reason for building a target
>>
>>   * added different options for executable and library search paths to be
>> used for Win32/x64
>>
>>   * link dependencies can now also be monitored for the 32-bit MS linker
>>
>>   * added commands "Collapse unittests" and "Collapse disabled" to the
>> outlining menu
>>
>> The full list of changes can be found
>> here: http://www.dsource.org/projects/visuald/wiki/VersionHistory
>> or:   http://rainers.github.io/visuald/visuald/VersionHistory.html
>>
>> Visual D is written in D, source code is available here: https://github.com/D-programming-Language/visuald
>>
>> Best,
>> Rainer
>>
>
>

On 06.11.2013 03:01, Manu wrote:
> I just found something surprising.
> I went into the 0.3.37 options, saw the 32bit/64bit separation, but
> noticed by default, the lib paths were populated like so:
>
> 32bit:
> $(DevEnvDir)..\..\VC\lib\amd64\
> C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Lib\x64
>
> 64bit:
> $(VCInstallDir)\lib\amd64
> C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\lib\x64
>
> Should I be surprised that the 32bit lib paths both point to 64bit libs?
> Shouldn't the 32bit libs point to the DMD OMF libs?

The 32-bit paths don't have a default (settings in sc.ini should usually be enough), but your settings from previous Visual D versions are kept.

On Tuesday, 5 November 2013 at 05:09:58 UTC, Manu wrote:
> Note: I saw Alexander Bothe released an update to the parser one day after
> your release... ;)

Sure, there have been a couple of critical regression bugs in the parser engine.
Furthermore, I re-enabled the ufcs completion.

Rainer, I somehow really recommend to provide a more frequent way to update the D_Parser.dll - just to provide a way to fix e.g. completion issues without having to recompile/package/upload the entire VisualD setup.

An automated build system which simply calls
git pull
and
xbuild DParser2/DParser2.csproj
already suffices. I could insert a push hook into the repo which is executed then in order to inform the build system to do a rebuild.

It also was possible to execute Unittests first, so in the case that there are some regression bugs (as it happened just recently), it simply won't be distributed.

Finally, a small webserver providing the built dll (or a zip of it) and a check whether there's an update available will passively distribute the dll to all clients. Not to forget some security things like hash check or encryption etc.

Also, the D_Parser.dll could be put into the AppData/Roaming folder, so no admin rights are needed for a parser update.

What do you think about this?

On 6 November 2013 18:25, Alexander Bothe <info@alexanderbothe.com> wrote:

> On Tuesday, 5 November 2013 at 05:09:58 UTC, Manu wrote:
>
>> Note: I saw Alexander Bothe released an update to the parser one day after your release... ;)
>>
>
> Sure, there have been a couple of critical regression bugs in the parser
> engine.
> Furthermore, I re-enabled the ufcs completion.
>
> Rainer, I somehow really recommend to provide a more frequent way to update the D_Parser.dll - just to provide a way to fix e.g. completion issues without having to recompile/package/upload the entire VisualD setup.
>
> An automated build system which simply calls
> git pull
> and
> xbuild DParser2/DParser2.csproj
> already suffices. I could insert a push hook into the repo which is
> executed then in order to inform the build system to do a rebuild.
>
> It also was possible to execute Unittests first, so in the case that there are some regression bugs (as it happened just recently), it simply won't be distributed.
>
> Finally, a small webserver providing the built dll (or a zip of it) and a check whether there's an update available will passively distribute the dll to all clients. Not to forget some security things like hash check or encryption etc.
>
> Also, the D_Parser.dll could be put into the AppData/Roaming folder, so no admin rights are needed for a parser update.
>
> What do you think about this?
>

I've often wondered if there's room for greater sharing of effort between
VisualD and Mono-D.
For instance, it seems a shame to have .visualdproj, and .dproj files
separate and incompatible. .csproj files are the same between VS and MD, I
wonder if the same is possible for D with collaboration?
Also things like the refactor engine? Are those things separated into
self-contained libs so any IDE can make use of them?
The semantic analysis really seems like a job for the DMD front end, built
as a lib, rather than re-inventing the wheel. Clang seems to provide that
sort of service for C tooling. Shame DMD doesn't seem to offer anything
similar.

I have no idea what the actual state of any of this actually is mind you, just thoughts I often ponder.

Regarding project files - I like Mono-D attempt to support dub package.json as project description file.

Regarding semantical analysis - both Mono-D and VisualD should just merged efforts with DCD, problem solved :)