In the panel of variable management, the value column should perhaps be renamed to "content", and the variable size should be displayed instead of the uninformative "<too big variable>" when appropriate.
I sure, that ability to calculate object size is pretty strict for backends. For example, I am not sure, that Lua could do it without overhead.
(In reply to Nikita Sirgienko from comment #1) > I sure, that ability to calculate object size is pretty strict for backends. > For example, I am not sure, that Lua could do it without overhead. I see. I was not aware of these technicalities. Would you consider adding this functionality to the backend languages for which this computation seems rather simple? Thinking about R/Octave/Scilab/Julia/Python, maybe others.
(In reply to avlas from comment #2) > (In reply to Nikita Sirgienko from comment #1) > Would you consider adding this functionality to the backend languages for > which this computation seems rather simple? Thinking about > R/Octave/Scilab/Julia/Python, maybe others. I am thinking about it, and I'll see what i can do
(In reply to Nikita Sirgienko from comment #3) > (In reply to avlas from comment #2) > > (In reply to Nikita Sirgienko from comment #1) > > Would you consider adding this functionality to the backend languages for > > which this computation seems rather simple? Thinking about > > R/Octave/Scilab/Julia/Python, maybe others. > > I am thinking about it, and I'll see what i can do Thank you
(In reply to Nikita Sirgienko from comment #3) > (In reply to avlas from comment #2) > > (In reply to Nikita Sirgienko from comment #1) > > Would you consider adding this functionality to the backend languages for > > which this computation seems rather simple? Thinking about > > R/Octave/Scilab/Julia/Python, maybe others. > > I am thinking about it, and I'll see what i can do For those backends for which this may be possible, do you think it would be better/easier to show three columns (Name, Size and Values)? [Now that I think about it, should we add Type as well?] Ideally the columns for Size and Values (and Type if considered) could be enabled optionally. I would very much like to have sizes (and maybe types) at sight to better understand the data and code in mutual context, to ease debugging, etc. I don't feel that (an incomplet) list of values are that important, at least for my workflow. Also, having a bunch of Values is a bit distracting, for instance column arrays hide a lot of other variables in the workspace. [Side note: this behavior (how values are displayed) could also be changed. An example of this could be how latest stable versions of Octave display values in the workspace, and perhaps cantor could consider adding a specific variable display panel similar to Octave's variable editor (although this would be a more sophisticated/complicated add)]
(In reply to avlas from comment #5) > (In reply to Nikita Sirgienko from comment #3) > > (In reply to avlas from comment #2) > > > (In reply to Nikita Sirgienko from comment #1) > > > Would you consider adding this functionality to the backend languages for > > > which this computation seems rather simple? Thinking about > > > R/Octave/Scilab/Julia/Python, maybe others. > > > > I am thinking about it, and I'll see what i can do > > For those backends for which this may be possible, do you think it would be > better/easier to show three columns (Name, Size and Values)? [Now that I > think about it, should we add Type as well?] [...] Those are nice ideas. We should add them to our backlog.
Added this requested feature in https://invent.kde.org/education/cantor/commit/691f84076a435fbcae49beac0d193b9791c93ddc On this moment for Python/Julia/Octave. Instead of <too long variable> they will show bytes size.