Re: cv2pdb: cannot add symbols to module, probably msobj140.dll missing
On 21.08.2017 05:24, Johnson wrote:
On Monday, 21 August 2017 at 03:18:38 UTC, Johnson wrote:
All of a sudden I'm getting this error. All I did was comment out a
huge block of code so I could check something. The code compiles but
the pdb conversion gives me that error ;/
Uncommenting out the code allows it to work again. I can't see why the
code I'm commenting out would give that error ;/
Deleting the code also produces the same result.
It seems to be in use with GTK and event handlers. The handlers are
completely isolated yet are somehow causing the problem.
You won't believe this, I'm sure, but
//Dialog.addOnDestroy((Widget w) { });
causes the error! Must be some serious bug! Uncommenting allows the
code to build fine.
I tried restarting visual D with no luck ;/
This just started happening too and a few hours ago I upgraded VS, so
maybe the msobj140.dll changed and broke cv2pdb? I copied it to the
cv2pdb dir so it should have no trouble finding it. I've also cleaned
the dir. It seems it's doing it on about everything I change. Going to
reboot to see if that helps.
Unfortunately, the VS2017 15.3.1 update seems to cause quite some
trouble. Bad linker (breaks TLS), bad vcvars*.bat (change current
directory), and this issue, too.
I guess they changed something about the (undocumented) interface to the
respective DLLs.
Re: Debugging Visual D using Visual D
On 20.08.2017 20:32, Johnson Jones wrote:
On Friday, 18 August 2017 at 06:37:44 UTC, Rainer Schuetze wrote:
Glad you figured it out. I had to enable Visual D in the extension
manager when using the local pkgdef.
Visual D installs for all users, so I think just installing into the
users AppData is not an option. VS 2017 doesn't seem to inspect the
"All Users" folders.
The installer is not supposed to write to the system registry for
VS2017 related components. I see some bad entries for mago and two
entries for marshalling some data, though, but they don't seem to have
an impact on extension detection (IIRC they are needed during build).
It writes a few clsID's I think. about 2 or 3, let me check...
Computer\HKEY_CLASSES_ROOT\TypeLib\{002a2de9-8bb6-484d-9903-7e4ad4084715}
C:\Program Files (x86)\VisualD\vdserver.tlb
Computer\HKEY_CLASSES_ROOT\WOW6432Node\CLSID\{002A2DE9-8BB6-484D-980E-7E4AD4084715}
C:\Program Files (x86)\VisualD\visuald.dll
These are the ones referred to above that might be used during building.
Computer\HKEY_CLASSES_ROOT\WOW6432Node\CLSID\{002a2de9-8bb6-484d-aa05-7e4ad4084715}
C:\Program Files (x86)\VisualD\DParser\DParserCOMServer.exe
This one is needed to start the semantic engine as a local COM server.
Computer\HKEY_CLASSES_ROOT\WOW6432Node\CLSID\{97348AC0-2B6B-4B99-A245-4C7E2C09D403}
C:\Program Files (x86)\VisualD\Mago\MagoNatDE.dll
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\MagoDebugger
In theory Mago is not a VS debug engine, but a system wide COM component
that can be used by other debugger frontends, too. I haven't seen
another application using it, though.
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VisualD
I also had to reinstall VisualD because for x64 the debugger would not
run. That probably came from me deleting one of those directories(the
ones referring to mago I guess).
So, I'm not sure if some of those keys are interfering with getting
isolation between the VS versions or what, but it seems that Visual
Studio load the registry version first before the extension package and
also then caches it. This makes it impossible to actually use the
isolated visual D even when everything is setup right as far as the
pkgdef's.
IMO all of these registry keys should have no influence on extension
loading.
Re: Problem with BP's
On 20.08.2017 20:26, Johnson Jones wrote:
On Friday, 18 August 2017 at 06:43:37 UTC, Rainer Schuetze wrote:
On 18.08.2017 00:41, Johnson Jones wrote:
I was doing something strange ;/
I had code like
mixin(import("Myfile.d"));
CallSomeFunctionInMyFile();
And no BP's could be hit in side the function call. D would say that
there was an error in the symbols for the project.
debugging mixins is not really supported by the compiler. It generates
source filenames that don't exist.
Yes, but in this case, it does exist! Which is why I'm saying it might
be a useful feature!
mixin(import(filename))
is essentially a direct insertion of filename in to the D source.
Even though it internally goes through the mixin analysis of the code,
it passes right through.
So, If VisualD knew that, it could just link up filename in to the
source and allow debugging of it.
If dmd outputted all string mixins to files, then the same logic would
apply.
e.g.,
it would rewrite
mixin("Hello World");
to
mixin(import(temp342.d));
and temp342.d would contain "Hello World".
Or it could just create a special module for it then import that
directly like below, which would probably allow it to nearly work with
Visual D. Visual D would just then have to know what is going on so it
could dive in to the "sub-file".
What I'm getting at is that it seems like very little work would have to
be done to get string mixins to be debuggable... instead of trying to
write some specialized mixin debugger. Dmd and Visual D already do all
the heavy lifting, they just need to communicate with each other enough
to make it happen.
There have been a couple of implementations of this, e.g.
https://github.com/dlang/dmd/pull/426 and the patch in
https://issues.dlang.org/show_bug.cgi?id=5051, but didn't get merged.
Re: cv2pdb: cannot add symbols to module, probably msobj140.dll missing
On Monday, 21 August 2017 at 03:18:38 UTC, Johnson wrote:
All of a sudden I'm getting this error. All I did was comment
out a huge block of code so I could check something. The code
compiles but the pdb conversion gives me that error ;/
Uncommenting out the code allows it to work again. I can't see
why the code I'm commenting out would give that error ;/
Deleting the code also produces the same result.
It seems to be in use with GTK and event handlers. The handlers
are completely isolated yet are somehow causing the problem.
You won't believe this, I'm sure, but
//Dialog.addOnDestroy((Widget w) { });
causes the error! Must be some serious bug! Uncommenting allows
the code to build fine.
I tried restarting visual D with no luck ;/
This just started happening too and a few hours ago I upgraded
VS, so maybe the msobj140.dll changed and broke cv2pdb? I copied
it to the cv2pdb dir so it should have no trouble finding it.
I've also cleaned the dir. It seems it's doing it on about
everything I change. Going to reboot to see if that helps.
cv2pdb: cannot add symbols to module, probably msobj140.dll missing
All of a sudden I'm getting this error. All I did was comment out
a huge block of code so I could check something. The code
compiles but the pdb conversion gives me that error ;/
Uncommenting out the code allows it to work again. I can't see
why the code I'm commenting out would give that error ;/
Deleting the code also produces the same result.
It seems to be in use with GTK and event handlers. The handlers
are completely isolated yet are somehow causing the problem.
You won't believe this, I'm sure, but
//Dialog.addOnDestroy((Widget w) { });
causes the error! Must be some serious bug! Uncommenting allows
the code to build fine.
I tried restarting visual D with no luck ;/
Re: Debugging Visual D using Visual D
I should state though, that I could be wrong(and haven't tested it out yet). It's possible that some of the caching "features" screwed up what I think is going on. But the typical thing that got stuff to work was deleting the visual D entries in the registry(of course, it broke mago also). So, I'm not 100%. It may be no keys that are needed to be removed, just a few of them, or all of them.
Re: Debugging Visual D using Visual D
On Friday, 18 August 2017 at 06:37:44 UTC, Rainer Schuetze wrote:
Glad you figured it out. I had to enable Visual D in the
extension manager when using the local pkgdef.
Visual D installs for all users, so I think just installing
into the users AppData is not an option. VS 2017 doesn't seem
to inspect the "All Users" folders.
The installer is not supposed to write to the system registry
for VS2017 related components. I see some bad entries for mago
and two entries for marshalling some data, though, but they
don't seem to have an impact on extension detection (IIRC they
are needed during build).
It writes a few clsID's I think. about 2 or 3, let me check...
Computer\HKEY_CLASSES_ROOT\TypeLib\{002a2de9-8bb6-484d-9903-7e4ad4084715}
C:\Program Files (x86)\VisualD\vdserver.tlb
Computer\HKEY_CLASSES_ROOT\WOW6432Node\CLSID\{002A2DE9-8BB6-484D-980E-7E4AD4084715}
C:\Program Files (x86)\VisualD\visuald.dll
Computer\HKEY_CLASSES_ROOT\WOW6432Node\CLSID\{002a2de9-8bb6-484d-aa05-7e4ad4084715}
C:\Program Files (x86)\VisualD\DParser\DParserCOMServer.exe
Computer\HKEY_CLASSES_ROOT\WOW6432Node\CLSID\{97348AC0-2B6B-4B99-A245-4C7E2C09D403}
C:\Program Files (x86)\VisualD\Mago\MagoNatDE.dll
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\MagoDebugger
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\VisualD
I also had to reinstall VisualD because for x64 the debugger
would not run. That probably came from me deleting one of those
directories(the ones referring to mago I guess).
So, I'm not sure if some of those keys are interfering with
getting isolation between the VS versions or what, but it seems
that Visual Studio load the registry version first before the
extension package and also then caches it. This makes it
impossible to actually use the isolated visual D even when
everything is setup right as far as the pkgdef's.
Re: Problem with BP's
On Friday, 18 August 2017 at 06:43:37 UTC, Rainer Schuetze wrote:
On 18.08.2017 00:41, Johnson Jones wrote:
I was doing something strange ;/
I had code like
mixin(import("Myfile.d"));
CallSomeFunctionInMyFile();
And no BP's could be hit in side the function call. D would
say that there was an error in the symbols for the project.
debugging mixins is not really supported by the compiler. It
generates source filenames that don't exist.
Yes, but in this case, it does exist! Which is why I'm saying it
might be a useful feature!
mixin(import(filename))
is essentially a direct insertion of filename in to the D source.
Even though it internally goes through the mixin analysis of the
code, it passes right through.
So, If VisualD knew that, it could just link up filename in to
the source and allow debugging of it.
If dmd outputted all string mixins to files, then the same logic
would apply.
e.g.,
it would rewrite
mixin("Hello World");
to
mixin(import(temp342.d));
and temp342.d would contain "Hello World".
Or it could just create a special module for it then import that
directly like below, which would probably allow it to nearly work
with Visual D. Visual D would just then have to know what is
going on so it could dive in to the "sub-file".
What I'm getting at is that it seems like very little work would
have to be done to get string mixins to be debuggable... instead
of trying to write some specialized mixin debugger. Dmd and
Visual D already do all the heavy lifting, they just need to
communicate with each other enough to make it happen.
