Ideas for new features and how to implement them

[zero-plusplus]

This discussion summarizes ideas for new features of the debug adapter and how to implement them.

Any questions or improvements to my ideas, please feel free to comment.

[zero-plusplus]

Delayed retrieval of large arrays

Description

vscode can group large arrays by 100 separators, such as [0..99], [100..199].

Currently, all elements are retrieved first, but retrieving partial elements as this group expands will reduce loading costs while allowing large arrays to be handled without restriction.

How to implement

There are two ways of doing this, but as a common part of both, it is necessary to be able to get the number of elements in an array.

It is also necessary to determine whether it is an array or not, as this functionality should only work for arrays.

The number of elements can be obtained with numchildren in the response to property_get.
However, I don't know if this is a bug on my end, but in v2 numchildren is set to 2 regardless of the number of elements. So as a workaround, use property_get to get arr.length instead.

The following methods are possible for determining the array

• v1.
  • Whether or not a value can be taken in arr[1]
• v2
  • Whether it inherits from Array
  • Whether the number of elements can be obtained with arr.length

1. Using the p argument of property_get

In the debugger, the p argument of the property_get command can be used to get partial child elements.

One problem with the implementation using the p argument is that it is not possible to retrieve only elements of the array in the specified range.

For example, if the first child element is retrieved, it will be retrieved as <base>, [1], [2], ... , [99] and on the next page it will be retrieved as [100], [101], ... , [199] on the next page, and the next page is retrieved with a shift of only the non-index elements.

Correcting this requires a solid understanding of the debugger specifications.

2. Retrieve property_get 100 times

The method is simple: arr[1], arr[2], ... , arr[100] and just use property_get 100 times.
It is not clear how much this high number of communications affects the processing cost, but the advantage is that the same process can be implemented in v1, which has a slightly different specification.

---

Implemented in the way described in 2. in the following.

• 856b06e

If there are no problems, this seems to be the way to go.

[Lexikos]

<base>, Length and [1] are all just "properties" as far as DBGp is concerned. They are all paged together, and should all be counted by numchildren but are not. I've written a detailed explanation on the forum.

If you want to retrieve only the items, in v2 you can use the <enum> pseudo-property. If the object's __Enum is a built-in function, the debugger engine automatically calls it and directly writes the items into the parent property instead of <enum>, but <enum> can still be queried directly with property_get -n arr.<enum>.

Retrieve property_get 100 times

It would probably be much more efficient to set a page size of 100 and retrieve two pages. You will know on which page the items start after querying each page of properties. Or you can use <enum> and retrieve one page.

[zero-plusplus]

Currently v2 is being re-implemented to use the <enum> method. So far it is working well.

I am considering which method to implement in v1.
Since v1 is no longer supported, I am thinking that method 2., which is less efficient but more maintainable, seems to be the way to go.