Did you make sure that your current Juno session is actually running on 0.11.1? If you’re using the process cycler (which is the default), you might need to kill up to three Julia sessions because Atom.jl is already loaded in them.
Not sure what’s going on there – nothing changed in ink’s installation procedure. I also can’t repro that bug on my Windows machine. Does node -v work in a terminal?
I had the same error. Are you on Atom 1.40? If so you may try to downgrade to 1.39. I think its related to version of node used by apm.
Well, as per the release notes above:
Using Atom 1.40.0 should result in a different error, but maybe I’m wrong on that.
node -v does not work. I am running in git bash. I guess I need to make sure node is in the path, don’t I?
PS: I don’t have node -v in the cmd either.
The installation seems to have worked fine for you, so that should be irrelevant.
In your case only Atom.jl’s version is important.
No, the node command is not available (I’m using git-bash on Win10).
Iby multiple uninstall-install I’ve now managed to install ink. The weird thing is that I cannot uninstall julia-client for some reason. It’s just there in the list, with no version attached, and apm uninstall julia-client just fails:
$ apm uninstall julia-client
Uninstalling julia-client failed
Failed to delete julia-client: No package.json found at C:\Users\mc0022\.atom\packages\julia-client\package.json
This is the list of packages currently installed (community packages only):
$ apm list
Built-in Atom Packages (93)
[...]
Community Packages (11) C:\Users\mc0022\.atom\packages
├── indent-detective@0.4.0
├── ink@0.11.5
├── julia-client
├── language-julia@0.19.1
├── language-latex@1.2.0
├── latex@0.50.2
├── latex-completions@0.3.6
├── pdf-view@0.72.0
├── tool-bar@1.2.0
├── uber-juno@0.3.0
└── wordcount@3.1.0
I have Atom 1.40.1
Did you close Atom before trying apm uninstall julia-client? If not, please do so.
If that still doesn’t work, try deleting C:\\Users\You\.atom\packages\julia-client manually, and apm install julia-client again afterwards.
…good suggestion 
I’m pretty sure at some point I did exactly that. However, I tried multiple times, and at least a few times without having Atom open. Still no luck
I figured out the part of manual deleting the julia-client folder, and it worked in terms of uninstalling julia-client, but still no luck in installing both ink and julia-client back. (it turns out ink wasn’t actually installed, as I had no folder in the packages directory for that package.
However, apparently I’ve solved by uninstalling all packages related to uber-juno, uninstalling uber-juno itself and reinstalling it (directly from Atom, as I found out it doesn’t work from apm…)
Hope this could be useful to someone else - many thanks for your help.
@aviatesk thanks for replying.
Yes I’m in Juno’s debugger. Yes the local variables are already assigned. I also restarted Juno many times, and upgraded julia-client to 0.11.2, ink to 0.11.5, and uber-juno to 0.3.0. Also, Atom.jl is at #master.
The symptom persisted but I found out more details:
Outside of debug mode, the data tip works for global and local variables (variables are shown as expressions not values if not calculated yet) and standard library functions.
Once I am in Juno’s debug mode, data tip stops working BEFORE the current line of execution (which is highlighted), but works for lines AFTER the current line of execution. This is consistent for global variable, local variable, and function names. If the variable has been assigned value, a value will show up if the text under mouse is AFTER the current line of execution.
I copied your function and got the same symptom I had before: if I hover over will_append before the current line of execution, no data tip. If I hover over will_append right after the current line of execution (the first line in the for loop), data tip works.
See the two photos attached showing the two cases.
I also tried another PC with the same setup (Windows 10 64-bit, all the latest version of everything, Julia is 1.3.0-rc3, Atom.jl is at #master). Same symptom. Also the behavior has no dependency on “Compiled Mode” or not for debugging.
Did you move the code of strlimit after defining it ?
We checks your mouse is under the debugged method via CodeTracking.definition(String, method) (like here) but this fails if you started debug after moving the method.
(Or something changed between v1.2 & v1.3, actually we don’t have any test for this functionality)
If this still doesn’t make the issue clear, it might be better to move and discuss in https://github.com/JunoLab/Juno.jl/issues.
No I didn’t change any code once the code had run for one time. I understand the debugger will not dynamically load the latest code from the editor, so after the code is run and debugging starts I don’t change any code; if I want to change it, I’ll change, run again, and then debug.
I will open an issue at the link you gave.
