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.
