I am using pycodestyle_magic as a linter in Jupyter. I am following the instructions at
https://github.com/mattijn/pycodestyle_magic
But I get error with 1-cell checking be it '%%pycodestyle' or '%%flake8'.
1st ERROR
# 1st CELL
%load_ext pycodestyle_magic
# 2nd CELL
%%pycodestyle
a=1
print(a)
2nd ERROR
# 1st CELL
%load_ext pycodestyle_magic
# 2nd CELL
%%flake8
a=1
print(a)
1st ERROR
I'm basing this on your image you posted for '1st error' and not the inaccurate code you posted:
Note that the error in your first error was saying line magic and not cell magic because it was not looking for cell magic anymore. You can see it will look for cell magic on the first line of a cell by putting in %%fake_magic as a first line and then 2 + 2 as a second line of cell. Running that you'll see UsageError: Cell magic %%fake_magic not found.
Hence, your first 'error' is that you are missing that the first line of the cell where you want to use cell magic becomes special. You cannot have something else on the first line where you want to use cell magic, even if it is commented out. In the image, you have #%%flake8 above %%pycodestyle. If you remove that line, it should work.
2nd ERROR
I'm basing this on your image you posted for '2nd ERROR' and not the inaccurate code you posted:
You've stumbled upon a bug currently involving flake8. (Maybe same or more bugs seem to prevent the %%flake8 magic from working at all for now, see comments.)
The solution/workaround is very similar to the '1st ERROR'. Remove the line you were trying to comment out because it being there is causing an issue.
The reasoning appears to be complex about the way the %%flake8 cell magic appears to work behind the scenes so that you cannot have comments in the code content at this time or it won't work. (And the second time it sees that comment symbol, it throws the error you see.) This bug has been reported here.
But the solution/work-around for now is straightforward. Remove the complexity you added, and see if it works.
In case of the %%flake8 magic, running the demo notebook as shown there doesn't work as shown, and so there is indeed a bug in the current version that was introduced by actually a bug in flake8 that the extension uses, see the specific comment here and the link to the underlying issue over at the flake8 repo. (In fact the extent that it doesn't work may be greater than the notebook reflects because as discussed in the comments, even cells without commented lines fail to report any formatting issues. The demo actually doesn't have any without and so I got distracted noting it only didn't show the buffer error for the first one in the demo notebook but since it had a commented line I thought it was still related.)The other way to workaround it at present is to install an older version of flake8 as pointed out here. The solution was merged though and should be available soon, and so just avoiding the triggering code in simple cases like yours is probably easier.
Note about the inaccurate code:
Post code for what gave you the issue, not what you think gave you the issue. Part of why you are asked to provide code as text the way you ran it, it is so those looking into it can run it the same way. Plus they don't have to type and can easily run it as you did. Beyond that, there's more reason behind it: you can try to see if what you observed originally matches what you are seeing now.
If you had run what you posted under the heading '1st ERROR' as the code block text, you would have seen it without the error you showed in your image. Usually you'd then discern the error/difference yourself. In other words, starball's comment was trying to point you to why you should be doing that, and sorted that 1st error out yourself. That would ultimately make your point about the fragile nature of %%flake8 magic have more impact because it isn't diluted by report of an error that isn't really an error. Plus, you may have realized what was necessary to avoid '2nd ERROR' because that code block works without error no matter how many times you run it.
Technical notes:
Anyone wishing to try out pycodestyle_magic with some of this code and the demo notebooks can click here to launch such a session served via the mybinder.org. service with most things necessary already set up. Once the session starts up in the classic Jupyter notebook interface, you need to do some further preparation to use pycodestyle_magic. As detailed here, you can install it with pip install flake8 pycodestyle_magic. So open a new notebook with the Python kernel backing it using New drop down on the upper right side and then choose the Python3 kernel. When it opens, make a cell that has %pip install flake8 pycodestyle_magic and run it. Then put %load_ext pycodestyle_magic as a cell and run that. You can now try the magic with code or pull the demo notebooks over and run those.
Related
it's been a few days that im trying to run my Rmd on Kaggle, but it simply doesn't work.
The main reason (I guess) is that, somehow the console is reading the code as an R code, but im sure that I'm using Rmarkdown.
Therefore, the console reads a Text line as a code line, giving me the code error below:
Also, i tried to copy and edit other's people markdown, but i keep getting the same error line.
You can check my code here: https://www.kaggle.com/badluckmath/kernel4c85aae59c/edit/run/39891200
He's working perfectly on my Rstudio.
I'm looking for a huge help here, please!
I've been stuck with this for a week!
If i press the buttom to run code, it will simply give me this error message.
For that, i still don't know the solution. But since this is a premade Rmarkdown and i knew that it works, i simple used the Save (Commit) options and at the end, it worked.
I am using JupyterLab to build a bioinformatics pipeline that uses both bash and python scripts.
The first bash script results gives a lot of feedback on every step of the process. However, this feedback is not helpful (unless there was an error) and makes the document less readable.
I would like to be able to hide this cell's output by default, but also to be able to open it when necessary to troubleshoot. I know it's possible to click 3 times on the output to collapse it; I was just wondering whether there is a way to do so by default.
I tried to add the tag specified on here (https://jupyterbook.org/features/hiding.html#Hiding-outputs) to the cell, but it does not seem to work for me.
Thanks for your help.
You may just want to suppress the output using %%capture cell magic as illustrated here. Then you simply remove that magic command from the first line of the cell for times you want to see the output, such as when troubleshooting.
If you want to make it so every time you run the cell, you can later decide to review what was captured you can use the %%capture magic command more as it was meant to be used. By assigning what is captured you can also do something like what the %%bash cell magic allows with handling output streams (see here), too. As described and illustrated here using the utils object you can easily get the stdout and/or stderr as a string, see http://ipython.readthedocs.io/en/stable/api/generated/IPython.utils.capture.html.
So say you put the following at the top of you cell to assign what was captured to out:
%%capture out
You can review the stdout stream later with the following:
print(out.stdout)
Or if you just want part of it, something like print(out.stdout[1:500]). I have some fancier handling illustrated in some blocks of code here.
I'm seeing a very strange issue with R (v 3.3.2, running on the command line of a CentOS 7 linux box). If I execute a command that goes over one line in the terminal, the output appears at the beginning of the second line of the command. This didn't happen with previous versions of R, though it does happen with later versions I've installed. I am using Putty as the terminal, but it also happens if I use xterm.
To describe it better, it looks like this:
> tmpvaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaal=1 [before hitting enter]
> tmpvaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
> aaaaaaaaaaaaaaaal=1 [after enter, typing overwrites the a's now]
If the multiline command outputs something, that output occurs on the second line and overwrites the a's. If there is an error, then the error message terminates properly and the next prompt follows the error message. So does anyone have any ideas? Thanks in advance!
Update: After some more experimenting, I've found another odd behavior. If I use CTRL-R to search for a previous multiline command, and then execute it, the output or subsequent prompt appears at the same location in the command as where the cursor was. Here's another example:
(reverse-i-search)`1':tmpvaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaal=1[cursor on one before hitting enter]
[hit enter and then:]
>tmpvaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
aaaaaaaaal=1
aaaaaaaaal=>
Pretty strange. Hard to describe so its hard to find any evidence of other problems like this on stack-exchange or elsewhere. My feeling is it has to do with the readline library but it is strange because this doesn't happen in the shell command line, only in R as far as I can tell.
Update 2: I've found a potentially more revealing way to replicate this issue. If you manually add a bunch of newlines (by jamming CTRL-V CTRL-J repeatedly), then hit enter, the next prompt jumps right back up to underneath the last one. This is not what happens in the underlying shell (bash for me), or in previous versions of R that I can check.
Just to have the answer out there in case anyone else has this issue, the problem was that my system was using an old version of the readline library, 6.2, and the issue disappeared when updating it to the current version, 7.0. So it would seem that even though later versions of R will install with the outdated readline, they don't exactly work correctly.
I must predicate this by saying that I am still quite new to RStudio/R so I hope this is not user error. However when debugging I am getting some strange results whilst in debug mode.
1) The code jumps to another part of the code without apparently being called.
2) When this happens the highlighter only partially highlights the code it jumps to but the arrow in the margin points to this partially highlighted line
3) The code then returns to place it jumped away from originally
I get the warning "Debug location is approximate because source source code is not available". Is this related to the problem?
You can replicate the results by installing the package dlm:
https://cran.r-project.org/web/packages/dlm/dlm.pdf
p<-3
G=diag(c(0.9963,0.9478,0.7740))
W=diag(c(0.0026^2,0.0027^2,0.0035^2))
C0_est=solve(diag(p)-G%*%t(G))*W
mod2<-dlm(m0=c(0.0501,-0.0251,-0.0116),C0=C0_est,FF=X,V=0.000000001*diag(m),GG=diag(c(0.9963,0.9478,0.7740)),W=diag(c(0.0026^2,0.0027^2,0.0035^2)))
debugonce(dlmForecast)
dlmForecast(mod2, nAhead=5, sampleNew=2)
When you step through using F10 you will find that the code jumps to L7 from Lines 28,32, 54 and 57 and to L4 from line 47.
Q1.) Why does this partial highlighting of the line being debugged mean?
Q2.) What causeses the code to jump backward and forwards like this with no apparent function call?
Kind Regards
Baz
Most R packages don't include copies of the package's source code (the keep.source option controls this behavior; you can read more about it here). When you debug code from this kind of package, RStudio has to guess at both what the code looked like originally and where the current execution point is in that code. This process includes some heuristics and does occasionally misinterpret the execution point. So what you're seeing is not the actual execution point jumping around, but RStudio making the wrong guess about where it is in the deparsed code.
Code from your own R scripts (and from packages with keep.source) have source references (see R journal article) which allow RStudio to line up the code and execution point precisely.
I wasn't able to reproduce this with your example (it appears to reference a variable m that it doesn't declare); if you can resolve that and send it to me (jonathan at rstudio dot com) I'll see if we can improve the heuristics so this case works better.
The problem is that when I run the code, there's no return in the console; I mean it does run the code, but does not return any output.
For example, if I write
v <- c(1, 2, 3, 4, 5)
v
I would expect in return
[1] 1 2 3 4 5
But it's not working.
I have version RStudio Version 0.98.1079 and R Version 3.1.1
Possibility 1 (until the + sign was mentioned): I was wondering if you had been doing a tutorial where they were demonstrating the sink function and you hadn't gotten to the point where it was reversed.
> sink('out.txt') # diverts all output to a disk file
> v <- c(1,2)
> v # output went to file
> sink() # sets the output back to the console
> v
[1] 1 2
Another way would be to call closeAllConnections:
> sink('out.txt')
> v
> v
> closeAllConnections()
> v
[1] 1 2
Possibility 2: To address the lack of response with a "+" showing at the Rstudio console ... that is a sign that the R parser "thinks" the entered text has not completed a full R command. It may indicate that you haven't typed a closing bracket or parenthesis. If typing one or two of those is unsuccessful and you keep getting mor +'s then you may be successful with typing the [esc]-key. If it is showing up immediately after a restart then you should check your code for correctness and make sure that the .Rdata file is deleted from your working directory. If you don't know what that means then you may need to search for the methods appropriate to your operating system. You could also have an error in the code of one of your .rprofile files.
In any case these two possibilities have nothing to do with Rstudio per se and everything to to with the typical behavior of an R console session in pretty much any IDE.
Do the lines still start with a "+"? It is also possible you forgot to close the brackets of a function. Try "}".
I had the same issue and none of the tips mentioned here were working.
Session > Restart R did the trick for me, possibly suggesting that I had a similar problem as andrewH but was not patient enough to wait for R to behave again.
This is a very old question, but I just had the same problem with a different cause, so I thought I would describe it here case it should be useful to someone else. I was getting the regular command prompt, with nothing more, no matter what I typed at the command line. I tried multiple returns, escape, sink, traceback, closeAllConnections (which did give me a response, "error: unexpected ) in (), but then went back to the command prompt and ignored a second traceback).
Anyway after half an hour or so of pulling my hair out, up pops "View(Mid2)". Mid2 is a tibble with 8.5 million observations of 88 numeric variables. I must have tapped it in the environment pane accidentally. I suppose it just took that long for the viewer to render it. I assume that all the other things I did hit at once, because RStudio crashed immediately thereafter.
The interesting thing about this particular version of the problem is what didn't happen. The red stop sign in the upper right of the console window, that lights when R is busy, didn't light. That is unfortunate -- but understandable, if the RStudio viewer is a different process. But also, when my computer is working hard on a really big computation or IO task, the fan usually starts, but it didn't. Don't know why. . I took its absence, incorrectly, to mean no such computation was underway.
If the lines in console are starting with "+".
Save your work and close the 'RStudio' or other tool which you are using and Start it again, it worked for me.
If you are using R Studio Cloud, refresh or re-opening won't work.
Only clue from the above posts or answers is your console will always start with '+'
In my case I tried all possibilities of closing braces.
And ")" worked for me when I typed that into the console and press enter.
sink() function did nothing in R Studio Cloud
A simple mistake might have also caused this problem:
A rather lengthy command left abandoned in the console is blocking the appearance of the result line.
Thus, the console only shows that line, but the result from any code run from the source, will not appear.
To solve this, just switch to the console, remove any remaining command and try again.
Experiencing something like that explained here as an unresponsive console to the R-Code running was just devastating for me when I experienced it. But luckly although I tried every trick explained in this page, it did not work for me. At last I clicked on the "To console" option available just below the Environment, History, Connections, Tutorial Tab on the R Studio. It solved the puzzle for me just now.
The best solution I've found is closeAllConnections and/or sink which almost always work
But as a stop gap measure, View()'ing always works. It's sort of a pain but whatever you wanted to print out, surround by View and you can see it