Bug 377771 - Wrong reppresentation of arrays in the variable manager
Summary: Wrong reppresentation of arrays in the variable manager
Status: RESOLVED FIXED
Alias: None
Product: cantor
Classification: Applications
Component: julia-backend (show other bugs)
Version: unspecified
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: Ivan Lakhtanov
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-03-18 14:15 UTC by Alexander Semke
Modified: 2018-06-03 08:29 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In: 18.04.2


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander Semke 2017-03-18 14:15:38 UTC
* create an array with string values s=["a1","a2"] -> in the variable manager the array is shown as ASIIString["a1","a2"] and not as ["a1","a2"]

* create an empty array b = Int64[], in the variable manager the array is shown as Int64[] and not as [] (similar for String[] and any other types).

* create an array with string and integer values anyrray=[1,2,"abc"] -> in the variable the array is shown as Any[1,2,"abc"] and not as [1,2,"abc]

Looks like the parser for Julia's output need to be extended and improved.
Comment 1 Ivan Lakhtanov 2017-04-02 20:09:35 UTC
By the moment we are using 'show(var)' to get string to show in variable manager. So there is no special logic on the side of the Cantor backend for this. Can you specify exactly what info you wait from variable manager and why presence of array type looks redundant for you?
Comment 2 Alexander Semke 2017-04-03 06:16:44 UTC
To be more consistent with the other backends, I'd only expect here to see the values only without any data types (["a1","a2"] and not ASIIString["a1","a2"], etc.). For integer arrays in Julia this is already the case. Create an array either via a=[1,2,3] or via a=Array{Int64}(3) and check the results in the variable manager - you won't see there any "Int64".

So, there are mainly two reasons 

1. we want to provide consistent behavior in the variable manager across different backends and also to stay consistent within Julia

2. for the integration in LabPlot (https://labplot.kde.org/2016/07/23/labplot-2-3-0-released/) we don't expect any data types, neither. We look only for the position of the brackets, strip them away, convert the remaining string to the vector of doubles and plot the values. In LabPlot we'd need now to also strip away all those data types like Int64, etc. I propose to do this directly in Cantor in order to provide more consistency as described in the first point.
Comment 3 Nikita Sirgienko 2018-06-02 21:05:17 UTC
Git commit 4facde26645b5ac777883de38a5dfc96487cc753 by Nikita Sirgienko.
Committed on 02/06/2018 at 21:04.
Pushed by sirgienko into branch 'master'.

Make Julia variables format in variables model more consistent with the other backends
FIXED-IN: 18.04.2
Differential Revision: https://phabricator.kde.org/D13290

M  +6    -1    src/backends/julia/juliasession.cpp
M  +2    -0    src/backends/julia/juliasession.h

https://commits.kde.org/cantor/4facde26645b5ac777883de38a5dfc96487cc753
Comment 4 Alexander Semke 2018-06-03 08:29:51 UTC
Git commit 8c7a0c37f0c7e7deb9f035339d0aecb2f5a819e4 by Alexander Semke, on behalf of Nikita Sirgienko.
Committed on 03/06/2018 at 08:29.
Pushed by asemke into branch 'Applications/18.04'.

Make Julia variables format in variables model more consistent with the other backends
FIXED-IN: 18.04.2
Differential Revision: https://phabricator.kde.org/D13290

M  +6    -1    src/backends/julia/juliasession.cpp
M  +2    -0    src/backends/julia/juliasession.h

https://commits.kde.org/cantor/8c7a0c37f0c7e7deb9f035339d0aecb2f5a819e4