www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Visual D 0.3.37 released

reply Rainer Schuetze <r.sagitario gmx.de> writes:
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
Nov 02 2013
next sibling parent reply "TheFlyingFiddle" <theflyingfiddle gmail.com> writes:
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).
Nov 02 2013
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
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
Nov 03 2013
parent "TheFlyingFiddle" <theflyingfiddle gmail.com> writes:
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.
Nov 03 2013
prev sibling next sibling parent reply Manu <turkeyman gmail.com> writes:
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
Nov 04 2013
parent reply "Alexander Bothe" <info alexanderbothe.com> writes:
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?
Nov 06 2013
next sibling parent reply Manu <turkeyman gmail.com> writes:
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.
Nov 06 2013
next sibling parent reply "Dicebot" <public dicebot.lv> writes:
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 :)
Nov 06 2013
parent "Alexander Bothe" <info alexanderbothe.com> writes:
On Wednesday, 6 November 2013 at 14:43:35 UTC, Dicebot wrote:

 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 :)


I dunno, there's probably just a small read method required in 
order to read .visualdproj files..gonna have a look at it.
Nov 06 2013
prev sibling parent reply Bruno Medeiros <brunodomedeiros+dng gmail.com> writes:
On 06/11/2013 14:39, Manu wrote:

 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?


The best approach here is to support an IDE-independent project 
configuration standard. And Dub is a good choice to go with this approach.

-- 
Bruno Medeiros - Software Engineer
Nov 06 2013
parent reply Manu <turkeyman gmail.com> writes:
On 7 November 2013 02:05, Bruno Medeiros <brunodomedeiros+dng gmail.com>wrote:


 On 06/11/2013 14:39, Manu wrote:


 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?


 The best approach here is to support an IDE-independent project
 configuration standard. And Dub is a good choice to go with this approach.



I use premake, but that's not the point.
The point here is that MonoDevelop is a blatant VisualStudio clone, and it
supports VS .sln and .csproj files, it would seem nice to continue that
compatibility between VS and MD for D too. The compilers are the same with
the same features and options, so there's no good reason for the project's
to differ, which are both just xml files, but structured slightly
differently while containing the same settings.
Nov 06 2013
parent reply "Dicebot" <public dicebot.lv> writes:
Picking common standard for all possible IDE's scales better than 
cloning approach of a single one (especially if this one is 
closed and known of forcing closed ecosystems)
Nov 06 2013
parent "Alexander Bothe" <info alexanderbothe.com> writes:
On Wednesday, 6 November 2013 at 17:49:57 UTC, Dicebot wrote:

 Picking common standard for all possible IDE's scales better 
 than cloning approach of a single one (especially if this one 
 is closed and known of forcing closed ecosystems)


Essentially, dub.

I'm okay with that decision :-P
Nov 06 2013
prev sibling parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 06.11.2013 09:25, Alexander Bothe 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.


Yeah, being able to get releases out more often, and having bug fixes 
being tested in the field would be nice. But I think we should not 
over-engineer things here.
Do you have a web-server that could do the compilation?



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


The component being used by Visual D is a local COM server, I'm not sure 
if it is good to have that in a user folder.



 What do you think about this?
Nov 06 2013
parent reply "Alexander Bothe" <info alexanderbothe.com> writes:
On Thursday, 7 November 2013 at 05:45:34 UTC, Rainer Schuetze 
wrote:

 On 06.11.2013 09:25, Alexander Bothe 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.


 Yeah, being able to get releases out more often, and having bug 
 fixes being tested in the field would be nice. But I think we 
 should not over-engineer things here.
 Do you have a web-server that could do the compilation?


No - I just have got a normal dedicated web-server thingy for 
php&mysql ^_^

But well, just a very small infrastructure that allows us to 
update software more often - a couple of hours ago I implemented 
this new eponymous template syntax..and now you had to release 
another VisualD to have it in there, right?


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


 The component being used by Visual D is a local COM server, I'm 
 not sure if it is good to have that in a user folder.


Okay, it's probably safer to let the user decide when to update 
only.
Nov 06 2013
parent Rainer Schuetze <r.sagitario gmx.de> writes:
Sorry for the delay, I've been away for a couple of days.

On 07.11.2013 07:13, Alexander Bothe wrote:

 On Thursday, 7 November 2013 at 05:45:34 UTC, Rainer Schuetze wrote:

 Yeah, being able to get releases out more often, and having bug fixes
 being tested in the field would be nice. But I think we should not
 over-engineer things here.
 Do you have a web-server that could do the compilation?


 No - I just have got a normal dedicated web-server thingy for php&mysql ^_^

 But well, just a very small infrastructure that allows us to update
 software more often - a couple of hours ago I implemented this new
 eponymous template syntax..and now you had to release another VisualD to
 have it in there, right?


ATM, yes. Maybe we can create a small update installer for the DParser 
component that you could also build.

Another option might be to get a time slot on the auto tester build 
servers. I could try to prepare a script to do a Visual D build from the 
necessary branches. Brad, would that be possible?
Nov 11 2013
prev sibling next sibling parent reply Manu <turkeyman gmail.com> writes:
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
Nov 05 2013
parent Rainer Schuetze <r.sagitario gmx.de> writes:
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.
Nov 05 2013
prev sibling parent reply "evilrat" <evilrat666 gmail.com> writes:
On Saturday, 2 November 2013 at 14:40:56 UTC, Rainer Schuetze 
wrote:

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


unfortuantely it doesn't works with VS 2013, it installs and 
registers with visual studio, but whenever i hit the build or 
debug it instantly reports "build error" with no info.
Nov 09 2013
parent reply "Nicholas Londey" <londey gmail.com> writes:
Have a look at this and see if that helps. I think I got it 
working in vs2013 because it was the announcement that it should 
be working that prompted me to find out why it wasn't.

http://d.puremagic.com/issues/show_bug.cgi?id=11457
Nov 09 2013
next sibling parent reply "evilrat" <evilrat666 gmail.com> writes:
On Sunday, 10 November 2013 at 07:13:26 UTC, Nicholas Londey 
wrote:

 Have a look at this and see if that helps. I think I got it 
 working in vs2013 because it was the announcement that it 
 should be working that prompted me to find out why it wasn't.

 http://d.puremagic.com/issues/show_bug.cgi?id=11457


i see sc.ini points to x64 vc\bin path, replaced with path to x86 
bin and still not works.

p.s. also please fix custom type coloring depending on visual 
studio style, with dark color scheme custom types(string, object, 
etc.) is unreadable even on good ips display. i think it would be 
better to set it to something like light blue as VC does with 
basic types.
Nov 10 2013
parent reply "evilrat" <evilrat666 gmail.com> writes:
ok i forgot about output pane. so what i see here...

ConsoleApp1\Debug\ConsoleApp1.pdb: cannot load PDB helper DLL
Nov 10 2013
parent reply "evilrat" <evilrat666 gmail.com> writes:
On Sunday, 10 November 2013 at 08:53:08 UTC, evilrat wrote:

 ok i forgot about output pane. so what i see here...

 ConsoleApp1\Debug\ConsoleApp1.pdb: cannot load PDB helper DLL


so the problem with debug server formats?
i wish it would work with visual studio 2013 soon, but at least 
x64 debug works so i can continue using it for now \0/
Nov 11 2013
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 12.11.2013 08:25, evilrat wrote:

 On Sunday, 10 November 2013 at 08:53:08 UTC, evilrat wrote:

 ok i forgot about output pane. so what i see here...

 ConsoleApp1\Debug\ConsoleApp1.pdb: cannot load PDB helper DLL


 so the problem with debug server formats?
 i wish it would work with visual studio 2013 soon, but at least x64
 debug works so i can continue using it for now \0/


This message is emitted by cv2pdb that is used to convert the debug 
information to a pdb file. Unfortunately cv2pdb is not yet updated for 
VS2013. I haven't tried it, but a workaround might be to copy the file 
vc\bin\mspdb120.dll to mspdb110.dll.

If you switch the debugger to "Mago", the conversion is no longer 
needed, so you can still build and debug Win32 executables.
Nov 12 2013
parent reply "evilrat" <evilrat666 gmail.com> writes:
On Tuesday, 12 November 2013 at 08:06:24 UTC, Rainer Schuetze 
wrote:

 If you switch the debugger to "Mago", the conversion is no 
 longer needed, so you can still build and debug Win32 
 executables.


mago gives "cannot launch debugger on %appname%. hr = 897...", so 
only x64 debugger left for usage
Nov 12 2013
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 12.11.2013 10:19, evilrat wrote:

 On Tuesday, 12 November 2013 at 08:06:24 UTC, Rainer Schuetze wrote:

 If you switch the debugger to "Mago", the conversion is no longer
 needed, so you can still build and debug Win32 executables.


 mago gives "cannot launch debugger on %appname%. hr = 897...", so only
 x64 debugger left for usage


Are you sure that you are not trying to debug a 64-bit executable with 
mago? Maybe the working directory is invalid, this can also cause problems.

If it still fails, please show the full error code, maybe I can guess 
what's going wrong.
Nov 12 2013
next sibling parent "dbjdbj" <dbj dbj.org> writes:
I have the same issue with the same VS2013 Shell.
I am using W7 PROF 32bit
I have tried with mago and that works.
I am new to D. What is wrong with using mago, if anything ?

Thanks
DBJ
Jan 23 2014
prev sibling parent reply "ParticlePeter" <ParticlePeter gmx.de> writes:
On Wednesday, 13 November 2013 at 06:48:44 UTC, Rainer Schuetze 
wrote:

 On 12.11.2013 10:19, evilrat wrote:

 On Tuesday, 12 November 2013 at 08:06:24 UTC, Rainer Schuetze 
 wrote:

 If you switch the debugger to "Mago", the conversion is no 
 longer
 needed, so you can still build and debug Win32 executables.


 mago gives "cannot launch debugger on %appname%. hr = 897...", 
 so only
 x64 debugger left for usage


 Are you sure that you are not trying to debug a 64-bit 
 executable with mago? Maybe the working directory is invalid, 
 this can also cause problems.

 If it still fails, please show the full error code, maybe I can 
 guess what's going wrong.


Are there any news on that issue ?
I get the same error Messages as mentioned with these debuggers:
VS and VS (x86 Mixed Mode) OUTPUT: AppName.pdb: cannot load PDB 
helper DLL
Mago WIN ERROR MESSAGE: cannot launch debugger on AppNamel.exe hr 
= 89710016

AppName is a 32-Bit executable.

Its on a fresh installed Win 8 with VS2013, unfortunately no old 
VS2012 dlls available. Would it help to upgrade to Win 8.1 ?
Feb 04 2014
parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 04.02.2014 18:47, ParticlePeter wrote:

 On Wednesday, 13 November 2013 at 06:48:44 UTC, Rainer Schuetze wrote:

 On 12.11.2013 10:19, evilrat wrote:

 On Tuesday, 12 November 2013 at 08:06:24 UTC, Rainer Schuetze wrote:

 If you switch the debugger to "Mago", the conversion is no longer
 needed, so you can still build and debug Win32 executables.


 mago gives "cannot launch debugger on %appname%. hr = 897...", so only
 x64 debugger left for usage


 Are you sure that you are not trying to debug a 64-bit executable with
 mago? Maybe the working directory is invalid, this can also cause
 problems.

 If it still fails, please show the full error code, maybe I can guess
 what's going wrong.


 Are there any news on that issue ?
 I get the same error Messages as mentioned with these debuggers:
 VS and VS (x86 Mixed Mode) OUTPUT: AppName.pdb: cannot load PDB helper DLL
 Mago WIN ERROR MESSAGE: cannot launch debugger on AppNamel.exe hr =
 89710016

 AppName is a 32-Bit executable.

 Its on a fresh installed Win 8 with VS2013, unfortunately no old VS2012
 dlls available. Would it help to upgrade to Win 8.1 ?



Have you tried the latest beta version [1]? This had some improvements 
in cv2pdb to find the ms*pdb.dll and some fixes in mago aswell.

Launching a program with a non-existing working directory causes this 
problem, too. Maybe you have made a typo there?

[1] https://github.com/D-Programming-Language/visuald/releases
Feb 04 2014
parent reply Manu <turkeyman gmail.com> writes:
On 5 February 2014 16:55, Rainer Schuetze <r.sagitario gmx.de> wrote:


 On 04.02.2014 18:47, ParticlePeter wrote:


 On Wednesday, 13 November 2013 at 06:48:44 UTC, Rainer Schuetze wrote:


 On 12.11.2013 10:19, evilrat wrote:


 On Tuesday, 12 November 2013 at 08:06:24 UTC, Rainer Schuetze wrote:


 If you switch the debugger to "Mago", the conversion is no longer
 needed, so you can still build and debug Win32 executables.


 mago gives "cannot launch debugger on %appname%. hr = 897...", so only
 x64 debugger left for usage


 Are you sure that you are not trying to debug a 64-bit executable with
 mago? Maybe the working directory is invalid, this can also cause
 problems.

 If it still fails, please show the full error code, maybe I can guess
 what's going wrong.


 Are there any news on that issue ?
 I get the same error Messages as mentioned with these debuggers:
 VS and VS (x86 Mixed Mode) OUTPUT: AppName.pdb: cannot load PDB helper DLL
 Mago WIN ERROR MESSAGE: cannot launch debugger on AppNamel.exe hr =
 89710016

 AppName is a 32-Bit executable.

 Its on a fresh installed Win 8 with VS2013, unfortunately no old VS2012
 dlls available. Would it help to upgrade to Win 8.1 ?


 Have you tried the latest beta version [1]? This had some improvements in
 cv2pdb to find the ms*pdb.dll and some fixes in mago aswell.

 Launching a program with a non-existing working directory causes this
 problem, too. Maybe you have made a typo there?

 [1] https://github.com/D-Programming-Language/visuald/releases


Any chance you can release a beta with that settings bug fixed?
I've supervised 2 new VD installs the last couple of days, and they all
suffer the problem with the mspdb dll path not being remembered in the exe
path settings.
Feb 05 2014
next sibling parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
Am 05.02.2014 13:21, schrieb Manu:

 Any chance you can release a beta with that settings bug fixed?
 I've supervised 2 new VD installs the last couple of days, and they all
 suffer the problem with the mspdb dll path not being remembered in the
 exe path settings.


Temporary workaround:

http://stuff.benjamin-thaut.de/D/visualdfix.reg

Download and run. This is for visual studio 2010. If you need it for a 
different version you have to open it with a text editor and change 
"10.0" to "11.0" for 2012 and "12.0" for 2013.

Kind Regards
Benjamin Thaut
Feb 05 2014
parent Rainer Schuetze <r.sagitario gmx.de> writes:
On 05.02.2014 14:20, Benjamin Thaut wrote:

 Am 05.02.2014 13:21, schrieb Manu:

 Any chance you can release a beta with that settings bug fixed?
 I've supervised 2 new VD installs the last couple of days, and they all
 suffer the problem with the mspdb dll path not being remembered in the
 exe path settings.


 Temporary workaround:

 http://stuff.benjamin-thaut.de/D/visualdfix.reg


The x64 settings that go wrong are ExeSearchPath64 and LibSearchPath64. 
They are written to DMD.ExeSearchPath64 and DMD.LibSearchPath64 instead, 
so if you copy/rename those entries in the registry hive pointed to by 
Benjamin, that should be picked up with the next start.



 Download and run. This is for visual studio 2010. If you need it for a
 different version you have to open it with a text editor and change
 "10.0" to "11.0" for 2012 and "12.0" for 2013.

 Kind Regards
 Benjamin Thaut
Feb 05 2014
prev sibling parent reply Rainer Schuetze <r.sagitario gmx.de> writes:
On 05.02.2014 13:21, Manu wrote:

 Any chance you can release a beta with that settings bug fixed?
 I've supervised 2 new VD installs the last couple of days, and they all
 suffer the problem with the mspdb dll path not being remembered in the
 exe path settings.


I didn't have a lot of time lately, but I am close to recovering from 
the recent SSD crash and almost have a working system back up now (with 
a precise GC dmd). I really should have pushed branches more often to 
github...

I have that settings bug fixed (saving to an registry entry but reading 
back a different one), so I hope I can create the new beta within the 
next couple of days.
Feb 05 2014
parent Rainer Schuetze <r.sagitario gmx.de> writes:
On 05.02.2014 22:47, Rainer Schuetze wrote:

 On 05.02.2014 13:21, Manu wrote:

 Any chance you can release a beta with that settings bug fixed?
 I've supervised 2 new VD installs the last couple of days, and they all
 suffer the problem with the mspdb dll path not being remembered in the
 exe path settings.


 I didn't have a lot of time lately, but I am close to recovering from
 the recent SSD crash and almost have a working system back up now (with
 a precise GC dmd). I really should have pushed branches more often to
 github...

 I have that settings bug fixed (saving to an registry entry but reading
 back a different one), so I hope I can create the new beta within the
 next couple of days.


The new beta 0.3.38beta3 of Visual D is available here: 
https://github.com/D-Programming-Language/visuald/releases
Feb 09 2014
prev sibling parent Rainer Schuetze <r.sagitario gmx.de> writes:
On 10.11.2013 08:13, Nicholas Londey wrote:

 Have a look at this and see if that helps. I think I got it working in
 vs2013 because it was the announcement that it should be working that
 prompted me to find out why it wasn't.

 http://d.puremagic.com/issues/show_bug.cgi?id=11457


Unfortunately the beta test has been done with the 8.0 Widows SDK only, 
and Microsoft changed their library paths again with the 8.1 SDK.
Nov 12 2013