Visual D Debugger "complaints" (Mago?)
Joerg Joergonson via Digitalmars-d-ide
digitalmars-d-ide at puremagic.com
Tue Jun 21 15:34:31 PDT 2016
On Sunday, 19 June 2016 at 08:06:55 UTC, Rainer Schuetze wrote:
>
> On 18.06.2016 17:57, Joerg Joergonson wrote:
>> On Friday, 17 June 2016 at 08:18:59 UTC, Rainer Schuetze wrote:
>>>
>>> Visualizer code in the binary sounds like an interesting
>>> idea. Given
>>> some convention on naming so that symbols are discoverable
>>> and rather
>>> safe to call, that could be doable.
>>>
>>> Mago does not yet support calling code in the debugged
>>> process, so
>>> that would be a first step to implement such kind of
>>> visualizers.
>>
>> It would be interesting, easy on the end user, and "portable"
>> if it
>> could be done. Having it stored in modules could allow
>> mago/VD to
>> compile the code(since we know we have the compiler) outside
>> the
>> project. Generic debugging helpers could be written and
>> shared. It just
>> depends on the difficulty of implementing properly ;)
>
> 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.
I have no problem with that, anything that makes life easier is a
+ for me ;)
A side note, intellisense shows all the possible invocations on a
type. It would be nice to make a distinction of direct members,
and such
e.g., a list
Type
method1
field1
...
Base
method1
field1
...
External
....
When looking for a method that I'm not aware of I have to scroll
through all the module imports(e.g., min, max, Date, abs,
etc...). If all this stuff was at the button of the list and the
more relevant stuff was at the top, it would be better. A line
separator is all that is needed to distinguish.
Basically break the list in to derivation type and sub-sort
alphabetically rather than using a flat list sorted
alphabetically.
Probably something quite easy to do? Could be an option.
More information about the Digitalmars-d-ide
mailing list