Re: Problem with BP's
On 18.08.2017 02:05, Johnson Jones wrote:
On Friday, 18 August 2017 at 00:02:23 UTC, Johnson Jones wrote:
On Thursday, 17 August 2017 at 22:41:51 UTC, 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.
but making MyFile.d a module(adding module MyFile; at the top) and doing
import Myfile;
CallSomeFunctionInMyFile();
Allowed the breakpoints to be hit.
I guess this is a related problem with mixin debugging, which still
doesn't work for me. In a sense, it might be a good why to debug them
because the file exists already and one doesn't have to have it
generated by the compiler to debug. This should help get the symbols
and line numbers correct and the line mappings. Might help make a
seemless way to debug them. e.g., any BP's in Myfile.d have to be
translated to the original file they are mixed in at and vice versa
when debugging them(open Myfile D).
Hmm, maybe that wasn't the fix, still getting the error in some cases:
The error is "Unexpected symbol reader error while processing test.exe"
It might have been coincidence that the above change worked or it
might be that it only partially fixed it.
What's strange about it is that delegates inside the function I'm
calling are hit but code in the root of the function are not.
void CallSomeFunctionInMyFile()
{
addDelegate(()
{
foo();
});
foo();
}
The first foo will break on a BP assinged to it but the second one won't.
You can try switching to the disassembly view to see where the compiler
generated debug line numbers.
It assumes line numbers and code offsets are always ascending. Maybe
assumption doesn't hold here.
Re: Problem with BP's
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.
but making MyFile.d a module(adding module MyFile; at the top) and doing
import Myfile;
CallSomeFunctionInMyFile();
Allowed the breakpoints to be hit.
That would the normal usage, too.
I guess this is a related problem with mixin debugging, which still
doesn't work for me. In a sense, it might be a good why to debug them
because the file exists already and one doesn't have to have it
generated by the compiler to debug. This should help get the symbols and
line numbers correct and the line mappings. Might help make a seemless
way to debug them. e.g., any BP's in Myfile.d have to be translated to
the original file they are mixed in at and vice versa when debugging
them(open Myfile D).
Re: Debugging Visual D using Visual D
On 18.08.2017 00:14, Johnson Jones wrote:
On Thursday, 17 August 2017 at 21:18:35 UTC, Johnson Jones wrote:
On Thursday, 17 August 2017 at 17:45:35 UTC, Rainer Schuetze wrote:
On 17.08.2017 19:05, Johnson wrote:
On Wednesday, 16 August 2017 at 19:35:19 UTC, Rainer Schuetze wrote:
On 16.08.2017 21:18, Johnson Jones wrote:
What's strange is that with your changes, privateregistry seems to
use them... but it still loads the old(I think) visualD because
when I try the debug the BP's are not hit and the module shows the
original visualD directory.
The Visual D installer adds the extension to the VS installation
("c:\Program Files (x86)\Microsoft Visual
Studio\2017\Community\Common7\IDE\Extensions\Rainer
Schuetze\VisualD") so it is immediately available for all users and
suffixes.
You can move it to
"%HOME%\AppData\Local\Microsoft\VisualStudio\15.0_\Extensions\Rainer
Schuetze\VisualD" to load it only with the version without suffix.
With both the system wide extension and the one in the "Exp"
folder, the extension from the user folder took precedence for me,
though.
If you run "devenv /RootSuffix Exp /Log" VS writes a log into
"%APPDATA%\Roaming\Microsoft\VisualStudio\15.0_Exp\ActivityLog.xml"
that also lists detected extensions.
I completely removed the `Extensions\Rainer Schuetze` directories in
all visual studio folders that I know of:
C:\Program Files (x86)\Microsoft Visual
Studio\2017\Enterprise\IDE\Extensions
C:\Users\Main\AppData\Local\Microsoft\VisualStudio\15.0_4d0b469e
C:\Users\Main\AppData\Local\Microsoft\VisualStudio\15.0_4d0b469eExp
Running visual studio still loads Visual D. It seems that it doesn't
even use the visuald.pkgdef.
Obviously I have those entries in the registry. Which it seems it
pulls from and either doesn't use the extensions folder at all on my
system or is overridden by the registry entries? If that's the case,
how can it be worked around? If not, what else might it be?
If visuald.pkgdef is suppose to be what visual studio uses to load
visual D as an extension, does it import that in to the registry and
then use the registry or does it always use the pkgdef file?(which
doesn't seem to be the case, as, again, visual D is loading with
visual studio without any of those pkgdef's)
What I'm afraid of is that deleting the registry keys will not do
any good, they will just be re-imported by loading the pkgdef(or
not, in which case Visual D won't be found at all) and then the main
registry keys will be used for the Exp, like it is now.
Basically visual studio is not loading the pkgdef files either at
all or only once, or every time but not allow them to overwrite the
registry keys, or something else is going on that I can't seem to
figure out.
I think you are right that VS imports the settings from the pkgdef
only once, then uses the registry only.
Maybe try deleting the cache files in
"%APPDATA%\Local\Microsoft\VisualStudio\15.0_\Extensions".
Ok, It seems to be caching. I deleted everything in the main registry
related to visualD and ran visual studio and it was still there!
Searched on line and came up with devenv updateconfiguration, reran
VS, and VisualD was no longer there! Ran experimental and it's still
there!
Used the same process to remove it from Exp.
So, this surely has to be caching, although I removed all the cache
files I could fine from both versions.
As of this point there is nothing related to visualD in the registry
nor the VS folders as far as I can tell and both versions are not
finding visualD.
I will copy the modified pkgdef file to the exp dir and run it: Did
nothing, Vi sual D didn't load! Copied the original pkgdef, no go.
Seems Visual studio is not using the pkgdef in
C:\Users\Main\AppData\Local\Microsoft\VisualStudio\15.0_4d0b469eExp\Extensions\Rainer
Schuetze\VisualD
I put the extensions folder in all the visual studio versions in that
base dir and it didn't help(so it's not using any directory in
C:\Users\Main\AppData\Local\Microsoft\VisualStudio).
Of course, at this point it means something is fubar'ed.
I went ahead and installed latest VD so I could get some work done.
Seems like no problem.
So either visual studio is not doing what it's suppose to or it has
more cache files laying around that I failed to delete, unless you see
something different?
[Just me going step by step for reference:
I should mention that after installing the latest, Visual D also gets
installed in the Exp version ;/ so it "magically" propagated to it.
The evidence seems to point to visual studio simply loading visual D
from the system registry and completely bypassing everything else. It
doesn't even look at the pkgdef's(or looked at them once and installed
them, then uses the registry thereafter).
Does the visualD installer install registry keys? or just the pkgdef
file and then somehow informs VS and then VS does it?
My guess is that Visual D installs the registr
Re: Problem with BP's
On Friday, 18 August 2017 at 00:02:23 UTC, Johnson Jones wrote:
On Thursday, 17 August 2017 at 22:41:51 UTC, 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.
but making MyFile.d a module(adding module MyFile; at the top)
and doing
import Myfile;
CallSomeFunctionInMyFile();
Allowed the breakpoints to be hit.
I guess this is a related problem with mixin debugging, which
still doesn't work for me. In a sense, it might be a good why
to debug them because the file exists already and one doesn't
have to have it generated by the compiler to debug. This
should help get the symbols and line numbers correct and the
line mappings. Might help make a seemless way to debug them.
e.g., any BP's in Myfile.d have to be translated to the
original file they are mixed in at and vice versa when
debugging them(open Myfile D).
Hmm, maybe that wasn't the fix, still getting the error in some
cases:
The error is "Unexpected symbol reader error while processing
test.exe"
It might have been coincidence that the above change worked or
it might be that it only partially fixed it.
What's strange about it is that delegates inside the function I'm
calling are hit but code in the root of the function are not.
void CallSomeFunctionInMyFile()
{
addDelegate(()
{
foo();
});
foo();
}
The first foo will break on a BP assinged to it but the second
one won't.
Re: Problem with BP's
On Thursday, 17 August 2017 at 22:41:51 UTC, 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.
but making MyFile.d a module(adding module MyFile; at the top)
and doing
import Myfile;
CallSomeFunctionInMyFile();
Allowed the breakpoints to be hit.
I guess this is a related problem with mixin debugging, which
still doesn't work for me. In a sense, it might be a good why
to debug them because the file exists already and one doesn't
have to have it generated by the compiler to debug. This should
help get the symbols and line numbers correct and the line
mappings. Might help make a seemless way to debug them. e.g.,
any BP's in Myfile.d have to be translated to the original file
they are mixed in at and vice versa when debugging them(open
Myfile D).
Hmm, maybe that wasn't the fix, still getting the error in some
cases:
The error is "Unexpected symbol reader error while processing
test.exe"
It might have been coincidence that the above change worked or it
might be that it only partially fixed it.
Problem with BP's
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.
but making MyFile.d a module(adding module MyFile; at the top)
and doing
import Myfile;
CallSomeFunctionInMyFile();
Allowed the breakpoints to be hit.
I guess this is a related problem with mixin debugging, which
still doesn't work for me. In a sense, it might be a good why to
debug them because the file exists already and one doesn't have
to have it generated by the compiler to debug. This should help
get the symbols and line numbers correct and the line mappings.
Might help make a seemless way to debug them. e.g., any BP's in
Myfile.d have to be translated to the original file they are
mixed in at and vice versa when debugging them(open Myfile D).
Re: Debugging Visual D using Visual D
On Thursday, 17 August 2017 at 21:18:35 UTC, Johnson Jones wrote:
On Thursday, 17 August 2017 at 17:45:35 UTC, Rainer Schuetze
wrote:
On 17.08.2017 19:05, Johnson wrote:
On Wednesday, 16 August 2017 at 19:35:19 UTC, Rainer Schuetze
wrote:
On 16.08.2017 21:18, Johnson Jones wrote:
What's strange is that with your changes, privateregistry
seems to use them... but it still loads the old(I think)
visualD because when I try the debug the BP's are not hit
and the module shows the original visualD directory.
The Visual D installer adds the extension to the VS
installation ("c:\Program Files (x86)\Microsoft Visual
Studio\2017\Community\Common7\IDE\Extensions\Rainer
Schuetze\VisualD") so it is immediately available for all
users and suffixes.
You can move it to
"%HOME%\AppData\Local\Microsoft\VisualStudio\15.0_\Extensions\Rainer Schuetze\VisualD" to load it only with the version without suffix. With both the system wide extension and the one in the "Exp" folder, the extension from the user folder took precedence for me, though.
If you run "devenv /RootSuffix Exp /Log" VS writes a log
into
"%APPDATA%\Roaming\Microsoft\VisualStudio\15.0_Exp\ActivityLog.xml" that also lists detected extensions.
I completely removed the `Extensions\Rainer Schuetze`
directories in all visual studio folders that I know of:
C:\Program Files (x86)\Microsoft Visual
Studio\2017\Enterprise\IDE\Extensions
C:\Users\Main\AppData\Local\Microsoft\VisualStudio\15.0_4d0b469e
C:\Users\Main\AppData\Local\Microsoft\VisualStudio\15.0_4d0b469eExp
Running visual studio still loads Visual D. It seems that it
doesn't even use the visuald.pkgdef.
Obviously I have those entries in the registry. Which it
seems it pulls from and either doesn't use the extensions
folder at all on my system or is overridden by the registry
entries? If that's the case, how can it be worked around? If
not, what else might it be?
If visuald.pkgdef is suppose to be what visual studio uses to
load visual D as an extension, does it import that in to the
registry and then use the registry or does it always use the
pkgdef file?(which doesn't seem to be the case, as, again,
visual D is loading with visual studio without any of those
pkgdef's)
What I'm afraid of is that deleting the registry keys will
not do any good, they will just be re-imported by loading the
pkgdef(or not, in which case Visual D won't be found at all)
and then the main registry keys will be used for the Exp,
like it is now.
Basically visual studio is not loading the pkgdef files
either at all or only once, or every time but not allow them
to overwrite the registry keys, or something else is going on
that I can't seem to figure out.
I think you are right that VS imports the settings from the
pkgdef only once, then uses the registry only.
Maybe try deleting the cache files in
"%APPDATA%\Local\Microsoft\VisualStudio\15.0_\Extensions".
Ok, It seems to be caching. I deleted everything in the main
registry related to visualD and ran visual studio and it was
still there!
Searched on line and came up with devenv updateconfiguration,
reran VS, and VisualD was no longer there! Ran experimental and
it's still there!
Used the same process to remove it from Exp.
So, this surely has to be caching, although I removed all the
cache files I could fine from both versions.
As of this point there is nothing related to visualD in the
registry nor the VS folders as far as I can tell and both
versions are not finding visualD.
I will copy the modified pkgdef file to the exp dir and run it:
Did nothing, Vi sual D didn't load! Copied the original pkgdef,
no go.
Seems Visual studio is not using the pkgdef in
C:\Users\Main\AppData\Local\Microsoft\VisualStudio\15.0_4d0b469eExp\Extensions\Rainer
Schuetze\VisualD
I put the extensions folder in all the visual studio versions
in that base dir and it didn't help(so it's not using any
directory in
C:\Users\Main\AppData\Local\Microsoft\VisualStudio).
Of course, at this point it means something is fubar'ed.
I went ahead and installed latest VD so I could get some work
done. Seems like no problem.
So either visual studio is not doing what it's suppose to or it
has more cache files laying around that I failed to delete,
unless you see something different?
[Just me going step by step for reference:
I should mention that after installing the latest, Visual D also
gets installed in the Exp version ;/ so it "magically" propagated
to it.
The evidence seems to point to visual studio simply loading
visual D from the system registry and completely bypassing
everything else. It doesn't even look at the pkgdef's(or looked
at them once and installed them, then uses the registry
thereafter).
Does the visualD installer install registry keys? or just the
pkgdef file and then somehow informs VS and then VS does it?
My guess is that Visual D installs the registry keys, possibly
wrong/old way, VS uses t
Re: Debugging Visual D using Visual D
On Thursday, 17 August 2017 at 17:45:35 UTC, Rainer Schuetze
wrote:
On 17.08.2017 19:05, Johnson wrote:
On Wednesday, 16 August 2017 at 19:35:19 UTC, Rainer Schuetze
wrote:
On 16.08.2017 21:18, Johnson Jones wrote:
What's strange is that with your changes, privateregistry
seems to use them... but it still loads the old(I think)
visualD because when I try the debug the BP's are not hit
and the module shows the original visualD directory.
The Visual D installer adds the extension to the VS
installation ("c:\Program Files (x86)\Microsoft Visual
Studio\2017\Community\Common7\IDE\Extensions\Rainer
Schuetze\VisualD") so it is immediately available for all
users and suffixes.
You can move it to
"%HOME%\AppData\Local\Microsoft\VisualStudio\15.0_\Extensions\Rainer Schuetze\VisualD" to load it only with the version without suffix. With both the system wide extension and the one in the "Exp" folder, the extension from the user folder took precedence for me, though.
If you run "devenv /RootSuffix Exp /Log" VS writes a log into
"%APPDATA%\Roaming\Microsoft\VisualStudio\15.0_Exp\ActivityLog.xml" that also lists detected extensions.
I completely removed the `Extensions\Rainer Schuetze`
directories in all visual studio folders that I know of:
C:\Program Files (x86)\Microsoft Visual
Studio\2017\Enterprise\IDE\Extensions
C:\Users\Main\AppData\Local\Microsoft\VisualStudio\15.0_4d0b469e
C:\Users\Main\AppData\Local\Microsoft\VisualStudio\15.0_4d0b469eExp
Running visual studio still loads Visual D. It seems that it
doesn't even use the visuald.pkgdef.
Obviously I have those entries in the registry. Which it seems
it pulls from and either doesn't use the extensions folder at
all on my system or is overridden by the registry entries? If
that's the case, how can it be worked around? If not, what
else might it be?
If visuald.pkgdef is suppose to be what visual studio uses to
load visual D as an extension, does it import that in to the
registry and then use the registry or does it always use the
pkgdef file?(which doesn't seem to be the case, as, again,
visual D is loading with visual studio without any of those
pkgdef's)
What I'm afraid of is that deleting the registry keys will not
do any good, they will just be re-imported by loading the
pkgdef(or not, in which case Visual D won't be found at all)
and then the main registry keys will be used for the Exp, like
it is now.
Basically visual studio is not loading the pkgdef files either
at all or only once, or every time but not allow them to
overwrite the registry keys, or something else is going on
that I can't seem to figure out.
I think you are right that VS imports the settings from the
pkgdef only once, then uses the registry only.
Maybe try deleting the cache files in
"%APPDATA%\Local\Microsoft\VisualStudio\15.0_\Extensions".
Ok, It seems to be caching. I deleted everything in the main
registry related to visualD and ran visual studio and it was
still there!
Searched on line and came up with devenv updateconfiguration,
reran VS, and VisualD was no longer there! Ran experimental and
it's still there!
Used the same process to remove it from Exp.
So, this surely has to be caching, although I removed all the
cache files I could fine from both versions.
As of this point there is nothing related to visualD in the
registry nor the VS folders as far as I can tell and both
versions are not finding visualD.
I will copy the modified pkgdef file to the exp dir and run it:
Did nothing, Vi sual D didn't load! Copied the original pkgdef,
no go.
Seems Visual studio is not using the pkgdef in
C:\Users\Main\AppData\Local\Microsoft\VisualStudio\15.0_4d0b469eExp\Extensions\Rainer
Schuetze\VisualD
I put the extensions folder in all the visual studio versions in
that base dir and it didn't help(so it's not using any directory
in C:\Users\Main\AppData\Local\Microsoft\VisualStudio).
Of course, at this point it means something is fubar'ed.
I went ahead and installed latest VD so I could get some work
done. Seems like no problem.
So either visual studio is not doing what it's suppose to or it
has more cache files laying around that I failed to delete,
unless you see something different?
Re: Debugging Visual D using Visual D
On 17.08.2017 19:05, Johnson wrote:
On Wednesday, 16 August 2017 at 19:35:19 UTC, Rainer Schuetze wrote:
On 16.08.2017 21:18, Johnson Jones wrote:
What's strange is that with your changes, privateregistry seems to
use them... but it still loads the old(I think) visualD because when
I try the debug the BP's are not hit and the module shows the
original visualD directory.
The Visual D installer adds the extension to the VS installation
("c:\Program Files (x86)\Microsoft Visual
Studio\2017\Community\Common7\IDE\Extensions\Rainer Schuetze\VisualD")
so it is immediately available for all users and suffixes.
You can move it to
"%HOME%\AppData\Local\Microsoft\VisualStudio\15.0_\Extensions\Rainer
Schuetze\VisualD" to load it only with the version without suffix.
With both the system wide extension and the one in the "Exp" folder,
the extension from the user folder took precedence for me, though.
If you run "devenv /RootSuffix Exp /Log" VS writes a log into
"%APPDATA%\Roaming\Microsoft\VisualStudio\15.0_Exp\ActivityLog.xml" that
also lists detected extensions.
I completely removed the `Extensions\Rainer Schuetze` directories in all
visual studio folders that I know of:
C:\Program Files (x86)\Microsoft Visual
Studio\2017\Enterprise\IDE\Extensions
C:\Users\Main\AppData\Local\Microsoft\VisualStudio\15.0_4d0b469e
C:\Users\Main\AppData\Local\Microsoft\VisualStudio\15.0_4d0b469eExp
Running visual studio still loads Visual D. It seems that it doesn't
even use the visuald.pkgdef.
Obviously I have those entries in the registry. Which it seems it pulls
from and either doesn't use the extensions folder at all on my system or
is overridden by the registry entries? If that's the case, how can it be
worked around? If not, what else might it be?
If visuald.pkgdef is suppose to be what visual studio uses to load
visual D as an extension, does it import that in to the registry and
then use the registry or does it always use the pkgdef file?(which
doesn't seem to be the case, as, again, visual D is loading with visual
studio without any of those pkgdef's)
What I'm afraid of is that deleting the registry keys will not do any
good, they will just be re-imported by loading the pkgdef(or not, in
which case Visual D won't be found at all) and then the main registry
keys will be used for the Exp, like it is now.
Basically visual studio is not loading the pkgdef files either at all or
only once, or every time but not allow them to overwrite the registry
keys, or something else is going on that I can't seem to figure out.
I think you are right that VS imports the settings from the pkgdef only
once, then uses the registry only.
Maybe try deleting the cache files in
"%APPDATA%\Local\Microsoft\VisualStudio\15.0_\Extensions".
Re: Debugging Visual D using Visual D
On Wednesday, 16 August 2017 at 19:35:19 UTC, Rainer Schuetze
wrote:
On 16.08.2017 21:18, Johnson Jones wrote:
What's strange is that with your changes, privateregistry
seems to use them... but it still loads the old(I think)
visualD because when I try the debug the BP's are not hit and
the module shows the original visualD directory.
The Visual D installer adds the extension to the VS
installation ("c:\Program Files (x86)\Microsoft Visual
Studio\2017\Community\Common7\IDE\Extensions\Rainer
Schuetze\VisualD") so it is immediately available for all users
and suffixes.
You can move it to
"%HOME%\AppData\Local\Microsoft\VisualStudio\15.0_\Extensions\Rainer Schuetze\VisualD" to load it only with the version without suffix. With both the system wide extension and the one in the "Exp" folder, the extension from the user folder took precedence for me, though.
If you run "devenv /RootSuffix Exp /Log" VS writes a log into
"%APPDATA%\Roaming\Microsoft\VisualStudio\15.0_Exp\ActivityLog.xml" that also lists detected extensions.
I completely removed the `Extensions\Rainer Schuetze` directories
in all visual studio folders that I know of:
C:\Program Files (x86)\Microsoft Visual
Studio\2017\Enterprise\IDE\Extensions
C:\Users\Main\AppData\Local\Microsoft\VisualStudio\15.0_4d0b469e
C:\Users\Main\AppData\Local\Microsoft\VisualStudio\15.0_4d0b469eExp
Running visual studio still loads Visual D. It seems that it
doesn't even use the visuald.pkgdef.
Obviously I have those entries in the registry. Which it seems it
pulls from and either doesn't use the extensions folder at all on
my system or is overridden by the registry entries? If that's the
case, how can it be worked around? If not, what else might it be?
If visuald.pkgdef is suppose to be what visual studio uses to
load visual D as an extension, does it import that in to the
registry and then use the registry or does it always use the
pkgdef file?(which doesn't seem to be the case, as, again, visual
D is loading with visual studio without any of those pkgdef's)
What I'm afraid of is that deleting the registry keys will not do
any good, they will just be re-imported by loading the pkgdef(or
not, in which case Visual D won't be found at all) and then the
main registry keys will be used for the Exp, like it is now.
Basically visual studio is not loading the pkgdef files either at
all or only once, or every time but not allow them to overwrite
the registry keys, or something else is going on that I can't
seem to figure out.
