Re: Visual D 0.3.37 released
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
Re: Visual D 0.3.37 released
On 5 February 2014 16:55, Rainer Schuetze r.sagita...@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.
Re: Visual D 0.3.37 released
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
Re: Visual D 0.3.37 released
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.
Re: Visual D 0.3.37 released
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
Re: Visual D 0.3.37 released
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 ?
Re: Visual D 0.3.37 released
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
Re: Visual D 0.3.37 released
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 phpmysql ^_^ 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?
Re: Visual D 0.3.37 released
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.
Re: Visual D 0.3.37 released
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.
Re: Visual D 0.3.37 released
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.
Re: Visual D 0.3.37 released
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/
Re: Visual D 0.3.37 released
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.
Re: Visual D 0.3.37 released
ok i forgot about output pane. so what i see here... ConsoleApp1\Debug\ConsoleApp1.pdb: cannot load PDB helper DLL
Re: Visual D 0.3.37 released
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.
Re: Visual D 0.3.37 released
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
Re: Visual D 0.3.37 released
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?
Re: Visual D 0.3.37 released
On 6 November 2013 18:25, Alexander Bothe i...@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.
Re: Visual D 0.3.37 released
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 :)
Re: Visual D 0.3.37 released
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.
Re: Visual D 0.3.37 released
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
Re: Visual D 0.3.37 released
On 7 November 2013 02:05, Bruno Medeiros brunodomedeiros+...@gmail.comwrote: 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.
Re: Visual D 0.3.37 released
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)
Re: Visual D 0.3.37 released
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
Re: Visual D 0.3.37 released
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?
Re: Visual D 0.3.37 released
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 phpmysql ^_^ 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.
Re: Visual D 0.3.37 released
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 turkey...@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.sagita...@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
Re: Visual D 0.3.37 released
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.
Re: Visual D 0.3.37 released
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.sagita...@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
Re: Visual D 0.3.37 released
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
Re: Visual D 0.3.37 released
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.
Visual D 0.3.37 released
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
Re: Visual D 0.3.37 released
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).
