On Sunday, 23 June 2019 at 17:58:27 UTC, Rainer Schuetze wrote:
> today a new version of Visual D has been released.

before I used VS2017 with VD 0.49. was ok. then I uninstalled it both.
then installed VS2019 (.NET only), installed VD 0.50, installed Build Tools for 2019 (C++), installed DMD & LDC as unpack distros to some folder and added PATH to their bin dirs - CLI is working now.

and now I have some issues with new VD 0.50:
- (weird but can live with it) mode "betterC" looks in settings like "remove some runtime info and helper functions" - not clear too much coz I thoughts that this option decrease compiled EXE size. please give to it more clear text like "betterC"
- (in concert) Visual D Settings\Updates\Base directory
for what needed that directory? for D projects? (oh, we are in tab "Updates") then what I should point here DMD directory (that can be in ProgramFiles if i used DMD installer)? LDC directory (that can be in any other user dir)? or I should point just "C:\"? weird name and option.
- Path to VS Linker exists only in DMD Directories tab for x64. What for GDC and LDC in case I dont install DMD at all?

and now main troubles: I cant build any D project any more from VS.
- compiling as "DMD x64": OPTLINK can not build EXE coz VD gives to it probably weird option. OPTLINK points to "/OUT:.." option and I dont used any nonASCII chars. dunno whats wrong. DMD still can build EXE from CLI.
- compiling as "LDC x64": again used OPTLINK. why? LDC has own lld-link.
- ok. remove DMD from VS options and from PATH var. LDC tried to use link.exe. why? it has own lld-link again. see next point.
- coz I installed Build Tools(C++) separate form VS my folder to libs and tools located at "C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools" not in the "..\Community". Probably its MS problem but I have what I have. so using VCINSTALLDIR is not good option for all cases. Try to check folder BuildTools too and VCINSTALLDIR for lastest build tools and libs. I can point VD settings manually but VD can do it automatically - just to check two folders instead one.

On Tuesday, 25 June 2019 at 12:24:03 UTC, a11e99z wrote:
and should exists total uninstallation with removing ALL setting and folders.
probably its good for updating to new version but should exist possibility to make clean new installation with removing all old settings.
for now uninstall & new install restore all old settings. dunno where it stores. I remove folder in program files, <home user>appdata\roaming and some keys from registry but it doesnt helps. probably I missed something.

On Tuesday, 25 June 2019 at 12:24:03 UTC, a11e99z wrote:
> On Sunday, 23 June 2019 at 17:58:27 UTC, Rainer Schuetze wrote:
>> today a new version of Visual D has been released.
>
> and now I have some issues with new VD 0.50:
> and now main troubles: I cant build any D project any more from VS.
> - compiling as "LDC x64": again used OPTLINK. why? LDC has own lld-link.

I deinstalled Build Tools, installed VC++ from VS-Installer to Community folder as 99% does.
same problems.
deinstalled VD0.50, install it again, all settings restored from olds (I want to do clean installation)
deinstalled VD0.50, installed 0.49.2, same problems and same old settings.
pic of LDC x64 w OPTLINK https://pasteboard.co/Il3uc0E.png
well, now i can not compile D projects at all with any version of VD.

On 25/06/2019 08:49, Bart wrote:
> On Tuesday, 25 June 2019 at 05:32:37 UTC, Rainer Schuetze wrote:
>>
>>
>> On 24/06/2019 21:58, Bart wrote:
>>> On Sunday, 23 June 2019 at 17:58:27 UTC, Rainer Schuetze wrote:
>>>> Hi,
>>>>
>>>> today a new version of Visual D has been released. Its main new features are
>>>>
>>>> [...]
>>>
>>>
>>> Did you break showing interfaces in the debug window? None of my interfaces are able to be expanded as the objects they are after updating. Was working fine right before.
>>
>> I think the bug has been in there since beta1, but doesn't always show up (never in a debug build). The class name is cached for a vtbl-pointer, but that cached value can be overwritten if there are uninitialized references evaluated afterwards. Fixed for the next release.
> 
> Never in a debug build? I'm using debug build ;/ Before sometimes it woudln't show up but after the update no interface was expandable(well, at least when I noticed it I could not expand any)

I was talking about the debug build of the debugger extension.

On 25/06/2019 14:24, a11e99z wrote:
> On Sunday, 23 June 2019 at 17:58:27 UTC, Rainer Schuetze wrote:
>> today a new version of Visual D has been released.
> 
> before I used VS2017 with VD 0.49. was ok. then I uninstalled it both. then installed VS2019 (.NET only), installed VD 0.50, installed Build Tools for 2019 (C++), installed DMD & LDC as unpack distros to some folder and added PATH to their bin dirs

That's where your troubles start.

> - CLI is working now.
> 
> and now I have some issues with new VD 0.50:
> - (weird but can live with it) mode "betterC" looks in settings like
> "remove some runtime info and helper functions"

That's the description given by dmd in the CLI help.

 - not clear too much coz
> I thoughts that this option decrease compiled EXE size. please give to it more clear text like "betterC"

I can add betterC/worseD to the description if that helps. The VC++ integration already calls the option "Better C".

> - (in concert) Visual D Settings\Updates\Base directory
> for what needed that directory? for D projects? (oh, we are in tab
> "Updates") then what I should point here DMD directory (that can be in
> ProgramFiles if i used DMD installer)? LDC directory (that can be in any
> other user dir)? or I should point just "C:\"? weird name and option.

There is not a lot of space for verbose descriptions in this dialog, the installer explains it a bit less terse. But I'll try to cover it in a line above or below the option.

> - Path to VS Linker exists only in DMD Directories tab for x64. What for GDC and LDC in case I dont install DMD at all?

GDC uses ld and LDC the Microsoft linker, nothing from the dmd installation.

> 
> and now main troubles: I cant build any D project any more from VS.
> - compiling as "DMD x64": OPTLINK can not build EXE coz VD gives to it
> probably weird option. OPTLINK points to "/OUT:.." option and I dont
> used any nonASCII chars. dunno whats wrong. DMD still can build EXE from
> CLI.

That's probably because link.exe cannot be found in the standard locations (Build tools not supported, as probably C++ integration doesn't do aswell). Then PATH is searched, but the dmd folder contains some badly named executables, link.exe being the worst.

> - compiling as "LDC x64": again used OPTLINK. why? LDC has own lld-link. - ok. remove DMD from VS options and from PATH var. LDC tried to use link.exe. why? it has own lld-link again. see next point.

lld-link is pretty new, and is unlikely to work well enough in combination with C++. For example, Microsoft keeps adding new debug information records.

> - coz I installed Build Tools(C++) separate form VS my folder to libs and tools located at "C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools" not in the "..\Community". Probably its MS problem but I have what I have. so using VCINSTALLDIR is not good option for all cases. Try to check folder BuildTools too and VCINSTALLDIR for lastest build tools and libs. I can point VD settings manually but VD can do it automatically - just to check two folders instead one.

Sorry, can't support all possible combinations of installations. I think it's not too bad if you can still configure the odd cases.

On 25/06/2019 15:38, a11e99z wrote:
> On Tuesday, 25 June 2019 at 12:24:03 UTC, a11e99z wrote:
> and should exists total uninstallation with removing ALL setting and
> folders.
> probably its good for updating to new version but should exist
> possibility to make clean new installation with removing all old settings.
> for now uninstall & new install restore all old settings. dunno where it
> stores. I remove folder in program files, <home user>appdata\roaming and
> some keys from registry but it doesnt helps. probably I missed something.

The problem is that Visual Studio keeps the settings in a private registry that is only mounted when you run VS. This private registry is not accessible by the installer.

Adding a "Reset all settings to default" sounds like a good idea, though. I'll see if it can be added in the next release.

You could try running "devenv /ResetSettings" for a global reset.

On 25/06/2019 15:53, a11e99z wrote:
> On Tuesday, 25 June 2019 at 12:24:03 UTC, a11e99z wrote:
>> On Sunday, 23 June 2019 at 17:58:27 UTC, Rainer Schuetze wrote:
>>> today a new version of Visual D has been released.
>>
>> and now I have some issues with new VD 0.50:
>> and now main troubles: I cant build any D project any more from VS.
>> - compiling as "LDC x64": again used OPTLINK. why? LDC has own lld-link.
> 
> I deinstalled Build Tools, installed VC++ from VS-Installer to Community
> folder as 99% does.
> same problems.
> deinstalled VD0.50, install it again, all settings restored from olds (I
> want to do clean installation)
> deinstalled VD0.50, installed 0.49.2, same problems and same old settings.
> pic of LDC x64 w OPTLINK https://pasteboard.co/Il3uc0E.png
> well, now i can not compile D projects at all with any version of VD.

"Image not found" for the link.

I suspect that there is something wrong with the order of folders in the PATH environment variable. You can check the generated batch (*.cmd) in the output folder.

On Tuesday, 25 June 2019 at 19:47:40 UTC, Rainer Schuetze wrote:
>
>
> On 25/06/2019 15:53, a11e99z wrote:
>> On Tuesday, 25 June 2019 at 12:24:03 UTC, a11e99z wrote:
>>> On Sunday, 23 June 2019 at 17:58:27 UTC, Rainer Schuetze wrote:
>>>> today a new version of Visual D has been released.
>>>
>>> and now I have some issues with new VD 0.50:
>>> and now main troubles: I cant build any D project any more from VS.
>>> - compiling as "LDC x64": again used OPTLINK. why? LDC has own lld-link.
>> 
>> I deinstalled Build Tools, installed VC++ from VS-Installer to Community
>> folder as 99% does.
>> same problems.
>> deinstalled VD0.50, install it again, all settings restored from olds (I
>> want to do clean installation)
>> deinstalled VD0.50, installed 0.49.2, same problems and same old settings.
>> pic of LDC x64 w OPTLINK https://pasteboard.co/Il3uc0E.png
>> well, now i can not compile D projects at all with any version of VD.
>
> "Image not found" for the link.
>
> I suspect that there is something wrong with the order of folders in the PATH environment variable. You can check the generated batch (*.cmd) in the output folder.


Maybe what might help is for VD to output all relevant information such as the locations of the compiler, linker, library imports, etc... all in an easily one per line file.

I tend to have trouble parsing the logs and such because the information is not easily readable unless one knows exactly what they are looking for. Specially with large projects.

This may not help with the compiler and linker itself unless you were to monitor the file system for changes(like process monitor) and then report what it is using but that would be a bit of work.

On my comp LDC does not work and I just get a crash but I don't know why. I simply don't use LDC for now.

For example, if you could override all the file commends in VD (e.g., if you use std.file you could hijack it) and then output all open files to a log along with VD's __FILE__ and __LINE__ info to get the source where they are being used at.  Would also require doing it with the shell but you basically already do it... just maybe pretty print the info so it is more readable. E.g.,

VD Options
   ---

Paths:
   Libraries: C:\Lib
   Imports: C:\Imports
   Compiler: C:\dmd\bin

Import libraries:
   C:\libraries\
   D:\foxtrot\tango.m
   ...
<compiler> Command line options:
   -m64
   -g
   -IC:\libraries\
   ...
...

Opened Files:
    C:\project\happy.m <VD: collect.m#34>
    D:\projects\dance.m <VD: import.m#334>
    ....

The point is to be as verbose as possible to provide as much contextual information for figuring out problems.



or whatever...


If you setup the framework you could slowly convert everything over time by simply logging stuff and as you come across old usage you can update it. Maybe get the most relevant first and then the rest of the stuff could follow.

There are dll injection libraries that can be used to inject in to a process to monitor file system access... could be used on the compiler and linker and all the files it uses could be stored(the log file would be very large but it would be helpful).

On Wednesday, 26 June 2019 at 02:35:53 UTC, Bart wrote:
> On Tuesday, 25 June 2019 at 19:47:40 UTC, Rainer Schuetze wrote:

Before I told about problems with VD on my laptop.
Most of time I use desktop with VS2019 and VD0.49.2 - its working.
I dont have a few days for "debugging" my installation for now so I put my laptop in case and I am afraid install new VD to desktop. I will deeply plunge to this jungle at July.
I filled some issues/enhancement to bugtracker yesterday.
In any case thanks for VD, I like it and I need it.

On Wednesday, 26 June 2019 at 08:28:13 UTC, a11e99z wrote:
> On Wednesday, 26 June 2019 at 02:35:53 UTC, Bart wrote:
>> On Tuesday, 25 June 2019 at 19:47:40 UTC, Rainer Schuetze wrote:
>
> Before I told about problems with VD on my laptop.
> Most of time I use desktop with VS2019 and VD0.49.2 - its working.
> I dont have a few days for "debugging" my installation for now so I put my laptop in case and I am afraid install new VD to desktop. I will deeply plunge to this jungle at July.
> I filled some issues/enhancement to bugtracker yesterday.
> In any case thanks for VD, I like it and I need it.

oops! to Rainer Schuetze :)