Whenever I compile my R code, I get a lot of extra white spaces that just clog up my worksheet.
Is there any way to suppress this, without changing the code to be on the same line using semicolons? I'm currently working in Sage Worksheets, on the cloud.
I've made some changes to slightly reduce whitespace in R mode for SageMathCloud (https://cloud.sagemath.com); restart your project to get this update. However, due to how Sage works they might not be sufficient. If you evaluate the following in a cell (in sage mode, or put %sage at the top), it will eliminate a lot of additional whitespace in %r mode.
def r_eval0(*args, **kwds):
return sage.interfaces.r.R.eval(sage.interfaces.r.r, *args, **kwds).strip().replace('\n\n','')
sage_salvus.r_eval0 = r_eval0
Related
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.
If I begin a line (i.e. a paragraph) in the details section of my .Rd file with \mjeqn a new line immediately follows the expression (anti-bonus points: the added new line seems to have wider line spacing than 'ordinary' new lines). How can I suppress this behavior when I want to start a line with inline mathy stuff using \mjeqn?
Sketched out example:
\mjeqn{foo^{bar}}{foo^bar} estimates bas.
Gives me something like the below when parsed (into html preview):
foo^bar
estimates bas.
I am just using mathjaxr, not roxygen2.
I don't know why that happens, but it looks like a bug, maybe in the R help rendering engine, maybe in the mathjaxr macro, or maybe in MathJax. A simple workaround is to put something invisible on the line ahead of the math, e.g.
\emph{}\mjeqn{foo^{bar}}{foo^bar} estimates bas.
Edited to add:
Digging into the rendering code, it seems the problem is that the \mjeqn macro expands into something that R ignores when trying to determine paragraphs, so it thinks the paragraph starts after that. Putting \emph{} ahead of it tells R that the paragraph has started and everything is fine. This has been incorporated into the package, so if you download the Github version, or wait for the next CRAN release, you won't need the workaround.
Edit: I am using RStudio
Up till now, while commenting something, I was using % symbol. Alternatively, I am just using Ctrl+Shift+C shortcut, which results in commenting with % or %' (or # for chunks).
The problem is, even if I comment something, it still often causes compilation errors. Look at the part of screenshot below:
Lines 1 to 23 are fully commented and document starts at line 24. However, even if parts of the code are commented out and shouldn't affect it, they for some reason still results in errors.
If I move code from lines 24to32 at the very beginning of the file, it compiles without problems. I thought that maybe there can't be comments at the beginning of the file, but looks like it's not an issue, as trying things like moving \documentclass{article} at the very beginning still results in errors, even though there are less of them.
How can I comment lines, so they won't be calling compilation errors?
First, Make sure that all the lines you don't need are "correctely"commented.
Then, i think that you can't put commented code on the top of your document, also avoid to put commented code on your document it's a lousy code.
It is very strange that R appears to ignore the last line of my .Rprofile.
For example, in .Rprofile
...
test<-function()1 # without line ending
And thus test is never loaded although the rest is loaded successfully. If I load it manually, source(".Rprofile"), test loads fine.
Is it the desired behaviour?
Under R studio with R 3.0 + in Linux
Can any one reproduce this?
This is a super annoying "feature" - the last line is silently ignored if it does not have a trailing newline.
I am using R 2.15.2 on windows XP.
I was used to use Rgui.exe but it was lacking the UNIX standards I like to use like CTRL+R <=>backward research and CTRL+U <=>erase line ...
If I missed something please tell me !
Then I tried Rterm.exe (which looks identical to R.exe to me) which has all those nice features. I found how to tune it right clicking on the top of the window to set height-width (it is like tuning the window you get from cmd.exe).
The problem is that now I cannot see on the window more than 75 characters, with a $ at the end: like this:
R) ppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppppp$
Not sure if it is a R option of a windows one, but if I set options("width"=180) I can see data.frame on the full width of the window...
Not sure what is happening, can I modify this?
We still do not know the answer to that one, so I guess 50 pts goes to Oscar de León... good for him to bad for me...
Sadly, it appears to be built in.
There used to be a problem with R when trying to print long strings. Apparently it was fixed first in Rterm and other versions of R before being fixed in Rgui.
When Rgui was fixed, possibly it was by a different means, since this issue can be fixed in Rgui but not other windows versions of R. You can change the width of the console for output both in Rgui and (later) Rterm.
The prompt is another story. It is actually not the same as the output space, and thus is controlled with a different option; but, this only works for Rgui. To do it, set pgcolumns=180 in the Rconsole file under [R HOME]\etc\. This modifies the width of the internal pager of the Rgui console, and effectively enables you to type up to 180 characters per input prompt.
Possibly there is a way to integrate that behavior into Rterm, and maybe Duncan Murdoch can point you in the correct direction (or prove me completely wrong).
I'm not really sure what is being requested. If what is needed in RTerm.exe is to display the end of a long line (and position the cursor there), then use CTRL-E. You can go back to the beginning of a line with CTRL-A. One can go back and forth repeatedly as needed until the line is use ENTER.
The control character of readline seem to be active, for instance CTRL-P scrolls back one command and CTRL-N brings up the "next" command from history if you hit CTRL-P too many times. (These are the same behavior as the up/down arrow keys.) See link for other expected readline behaviors.
On my machine alt-f and alt-b (which should have been meta-f and meta-b) did not natively move forward or backward by words, but ESC-b and ESC-f did so on a line that exceeded the console width and had the $'s marking either the right or left extents as having further material to look consider.
If you want to wrap display lines, then you need to consider alternatives or additions to readline: link, but that is an untested suggestion and merely the results of a search for: "readline wrap display".
The command should be options(width = 180) (without the quotes around width), but when you run Rterm in the Windows shell, it doesn't respect changes to this value; it just prints output as wide as the console.
The best way of working with R is (almost always) to use an IDE. Try emacs + ESS or one of the many vim plugins (R.vim, vim-R, VIM:r-plugin) if you want something UNIXy.