March 22, 2017
On Sunday, 19 June 2016 at 08:06:55 UTC, Rainer Schuetze wrote:
>
> On 18.06.2016 17:57, Joerg Joergonson wrote:
>> [...]
>
> Visualizers in a separate module or even binary have the problem of not being able to access private symbols. Having it in a DLL built and loaded by mago/vd needs an extensive API for reflection and memory access. This seems like a larger project...
>
> I'd rather start with some functions in the debuggee itself to be searched for the type data to be displayed, e.g.
>
> string mago_visualizer(ref T data);
> string mago_visualizer(T)(ref T data);
>
> or some sink-delegate-version to avoid allocations.
>
> mago will try to resolve these for T and its base classes. If it finds one, it is called and the string result is displayed.

Has anything like this been added yet?  I would like to be able to see the GUID value in the debugger, but it is not showing up...
March 26, 2017

On 22.03.2017 22:13, StarGrazer wrote:
> On Sunday, 19 June 2016 at 08:06:55 UTC, Rainer Schuetze wrote:
>>
>> On 18.06.2016 17:57, Joerg Joergonson wrote:
>>> [...]
>>
>> Visualizers in a separate module or even binary have the problem of
>> not being able to access private symbols. Having it in a DLL built and
>> loaded by mago/vd needs an extensive API for reflection and memory
>> access. This seems like a larger project...
>>
>> I'd rather start with some functions in the debuggee itself to be
>> searched for the type data to be displayed, e.g.
>>
>> string mago_visualizer(ref T data);
>> string mago_visualizer(T)(ref T data);
>>
>> or some sink-delegate-version to avoid allocations.
>>
>> mago will try to resolve these for T and its base classes. If it finds
>> one, it is called and the string result is displayed.
>
> Has anything like this been added yet?  I would like to be able to see
> the GUID value in the debugger, but it is not showing up...

No, nothing added to that respect. You should be able to view a GUID, though. It could be a case of debug info missing from a library (see https://issues.dlang.org/show_bug.cgi?id=4014).
March 26, 2017
On Sunday, 26 March 2017 at 15:45:47 UTC, Rainer Schuetze wrote:
>
>
> On 22.03.2017 22:13, StarGrazer wrote:
>> On Sunday, 19 June 2016 at 08:06:55 UTC, Rainer Schuetze wrote:
>>> [...]
>>
>> Has anything like this been added yet?  I would like to be able to see
>> the GUID value in the debugger, but it is not showing up...
>
> No, nothing added to that respect. You should be able to view a GUID, though. It could be a case of debug info missing from a library (see https://issues.dlang.org/show_bug.cgi?id=4014).

How would I find out? All I know is that GUID and some other things show up with as {}, which is very uninformative.
March 27, 2017

On 26.03.2017 19:49, StarGrazer wrote:
> On Sunday, 26 March 2017 at 15:45:47 UTC, Rainer Schuetze wrote:
>>
>>
>> On 22.03.2017 22:13, StarGrazer wrote:
>>> On Sunday, 19 June 2016 at 08:06:55 UTC, Rainer Schuetze wrote:
>>>> [...]
>>>
>>> Has anything like this been added yet?  I would like to be able to see
>>> the GUID value in the debugger, but it is not showing up...
>>
>> No, nothing added to that respect. You should be able to view a GUID,
>> though. It could be a case of debug info missing from a library (see
>> https://issues.dlang.org/show_bug.cgi?id=4014).
>
> How would I find out? All I know is that GUID and some other things show
> up with as {}, which is very uninformative.

Actually, phobos and druntime are built without debug information, and dmd does not generate corresponding debug info for code that uses structs declared by the libraries.

Even if you rebuild druntime and phobos with debug information, you might hit the issue mentioned above. A workaround should be to actually reference GUID.init somewhere, as the debug info is only linked in when the init property is referred to.

To help with this issue, Visual D has the project option "build and use local version of phobos with same compiler options" on the linker page. It also allows debugging calls into druntime/phobos.

Unfortunately, this build is broken with recent dmd versions. Currently investigating...
March 27, 2017

On 27.03.2017 18:50, Rainer Schuetze wrote:
> To help with this issue, Visual D has the project option "build and use
> local version of phobos with same compiler options" on the linker page.
> It also allows debugging calls into druntime/phobos.
>
> Unfortunately, this build is broken with recent dmd versions. Currently
> investigating...

Should be fixed for dmd 2.073 in this build:

https://ci.appveyor.com/project/rainers/visuald/build/1.0.115/job/7r384dme5sw1pnq2/artifacts

Unfortunately, GUID having an initializer with all zeroes causes all references to the init property to be optimized away. The only way I found to drag the debug info in is to place this code somewhere at global scope.

extern extern(C) __gshared int D4core3sys7windows8basetyps4GUID6__initZ;
__gshared ref_GUID_init = &D4core3sys7windows8basetyps4GUID6__initZ;
March 27, 2017
On Monday, 27 March 2017 at 18:05:23 UTC, Rainer Schuetze wrote:
>
>
> On 27.03.2017 18:50, Rainer Schuetze wrote:
>> [...]
>
> Should be fixed for dmd 2.073 in this build:
>
> https://ci.appveyor.com/project/rainers/visuald/build/1.0.115/job/7r384dme5sw1pnq2/artifacts
>
> Unfortunately, GUID having an initializer with all zeroes causes all references to the init property to be optimized away. The only way I found to drag the debug info in is to place this code somewhere at global scope.
>
> extern extern(C) __gshared int D4core3sys7windows8basetyps4GUID6__initZ;
> __gshared ref_GUID_init = &D4core3sys7windows8basetyps4GUID6__initZ;

None of this worked for me ;/
April 01, 2017

On 28.03.2017 01:57, StarGrazer wrote:
> On Monday, 27 March 2017 at 18:05:23 UTC, Rainer Schuetze wrote:
>>
>>
>> On 27.03.2017 18:50, Rainer Schuetze wrote:
>>> [...]
>>
>> Should be fixed for dmd 2.073 in this build:
>>
>> https://ci.appveyor.com/project/rainers/visuald/build/1.0.115/job/7r384dme5sw1pnq2/artifacts
>>
>>
>> Unfortunately, GUID having an initializer with all zeroes causes all
>> references to the init property to be optimized away. The only way I
>> found to drag the debug info in is to place this code somewhere at
>> global scope.
>>
>> extern extern(C) __gshared int D4core3sys7windows8basetyps4GUID6__initZ;
>> __gshared ref_GUID_init = &D4core3sys7windows8basetyps4GUID6__initZ;
>
> None of this worked for me ;/

"not working" means it built the "private" phobos library with debug information and your code compiled and linked with the above snippet, but debug info was still missing?
Next ›   Last »
1 2