Community
Participate
Working Groups
Thanks to bug 365541, DSF now creates partitions of 100 elements for large arrays. When using pretty printers, we can have structures that are displayed like arrays, such as Maps, Vectors, Lists. Lets call them 'virtual arrays'. When such a virtual array has more than 100 elements, the user may expect it to be partitioned like a normal array. There is more complexity for virtual arrays because: 1- we don't know in advance how many children the virtual array has 2- we only fetch children by chunks of 100 3- virtual arrays can grow or shrink dynamically
Agree, would be a nice feature. Just as a reminder: Any implementation of this feature must not rely on getting the number of children in such a virtual array. Otherwise we risk to hang on uninitialized collections (e.g. local variables in a method), not to talk about sluggishness. This is because the python pretty printers don't offer a method to just retrieve the number of children. Instead, we have to iterate over all available children.
Another point to remember is that the chunks of children we fetch at once, is a preference that can change dynamically (default 100). My first thoughts on the user interface for this feature is that the partitions would by dynamic instead of fixed. They would only be created once we actually have retrieved 100 children or more. For example, the user might see a virtual array of 90 elements in the view, but at the next suspend, if that virtual array has grown to 105 elements, the user would then see two partitions [0...99] and [100...104]. Another example is if the user sets the number of children fetched preference to 75 and expands a virtual array (that has 200 elements, except we can't know that in advance). We will fetch 75 children and show no partitions. If the user clicks on "More children...", we will fetch another 75 children, and then, because we have reached more than 100 children, we would create the partitions. I think this approach will require us to tell the view to refresh the contents of an expression using an IDMEvent, but I guess we can mimic the solution used for the "More children..." logic. I'm not planning on working on this, but I wanted to at least put the info in the bug.
