I'm an R newbie using RScaLAPACK and every time I spawn a new process grid I get a message.
> sla.gridInit(2)
[1] "RScaLAPACK:Process Grid Initialized "
I'm going to put this line in a function and I don't want my function to be spitting out this message. However- I don't want to just sink("/dev/null") the call because for all I know, something somewhere could go wrong and then I'd be suppressing useful output. Basically, I want it to be silent when it succeeds and loud if it fails. What is the best way to accomplish this?
Any thoughts, including design considerations, are welcome.
edit:
sla.gridInit() isn't returning anything. The code for sla.gridInit just calls print().
edit:
I suppose capturing output is best like in suppress messages displayed by "print" instead of "message" or "warning" in R . At least I will have the output if I want to do something with it.
You can wrap this function in one of the suppress* functions, suppressMessages, suppressWarnings or suppressPackageStartupMessages. See the help pages of those functions for more details.
Related
During a process, I need to copy a directory using fs::dir_copy(currentPath, newPath). Some of the time, I get the following error message:
Error in link_copy(links, path(new_path[[i]], path_rel(links, path[[i]])), :
all(is_link(path)) is not TRUE
This only happens some of the time, not always. What's more, if I replace my directory with a manual copy of itself (i.e. manually copy directory, delete original, rename the copy), then my code will work.
Could someone please explain why this could be happening? Is there a way I can sidestep that error once and for all?
This does not answer your question but may help you to further analyse what is going on. One of the great things of R is that you can easily inspect source code. Especially in a situation where unusual things appear to happen, looking at the code may be useful.
In your case, we can inspect the source code of fs::dir_copy and trace back to which code generates the error message. If you type fs::dir_copy (no parenthesis) into the console, R will print the R code of the function (if the function is not primitive). Doing that here will show you that the fs:dir_copy function calls the fs::link_copyfunction. Makes sense, as the error message comes from this function.
We can now print this function with fs::link_copy
This function generates the error message in this line:
stopifnot(all(is_link(path)))
From the error message we know that all(is_link(path)) returns FALSE. Next step is to have a look at the fs::is_link function. Here we see that the error may come from the call to the setNames function, which depends on the fs::file_info function: res <- file_info(path)
Here we see that setNames is called with a condition depending on what the file_infofunction returned:
setNames(!is.na(res$type) & res$type == "symlink", res$path)
This looks unusual as setNames takes an object and a character vector as formals. But then, I am not the developer of these functions ;-)
Perhaps there are issues with the file type on your machine and fs::file_info(path) returns something unexpected under some conditions.
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.
After poking around on the internet I wasn't able to find anyone who had written a quine in R (Edit: since writing this, have found several on SO, but am still interested in this one). So I figured I'd try my hand at coming up with one myself. My result was the (surprisingly short) code:
function(){}
which will output function(){} when run. This takes advantage of the fact that a function name without parens or arguments after it will return the function's source code.
However, a program that "looks at itself" is not generally considered a true quine. There are two things I realized I don't understand in the course of trying to decide whether I'd written a "real" quine: (1) What constitutes a program "looking at itself" (from a quine standpoint) beyond use of file i/o and (2) the extent to which function(){} (or similar commands like logical(0)) are self referential when they print themselves. The former seems to be too subjective for SO, but I was hoping for some clarification on the latter. So...
When I run function(){}, what exactly is happening that causes it to print its own "source code"? For example, is R loading an empty function into a local environment, evaluating that function, and then looking back at the code that defined it to print? Or, is it just looking at function(){} and echoing its definition right away? Is there a fundamental difference between this and
f<-function(){cat("f<-");print(f);cat("f()")}
f()
in terms of how they both print themselves when run?
You don't completely get what's going on here. Actually, the code
function(){}
doesn't do anything apart from constructing a function without arguments and body, returning it and deleting it immediately after it's returned. Its output would be NULL, so doesn't "recreate itself".
The output you see in the console, is not the output given by function(){} but by print.function. This is the S3 method that takes care of showing a function object in the console. What you actually do, is:
a <- function(){}
print(a)
rm(a)
A true R quine would be something like this:
m<-"m<-0;cat(sub(0,deparse(m),m))";cat(sub(0,deparse(m),m))
See also Wikipedia for this and other examples
This is not a true quine as it does not print anything to stdout. Whole point of Quine is that it can reproduce itself by printing. Program must create a new file or output in stdout containing its exact code.
Example of a javascript quine would be:
(function a(){console.log(`(${a}())`)}())
(function(x) print(substitute(x(x))))(function(x) print(substitute(x(x))))
using R and debugging, I often might have a function with several arguments set by default.
e.g.
foo <- function(x=c(3,4,5), y= 'house', dateidx = '1990-01-01'){}
Often I just want to manually run through some lines in the function, while using the pre-set parameters. If the parameter list is long, I have to type or paste each argument to the console manually before stepping through the function.
x=c(3,4,5)
y= 'house'
dateidx = '1990-01-01'
It's ok if the list of arguments is small but if there is a long list of arguments, it gets tedious. Is there some way to just copy the whole set of arguments, paste to console, and do something like unlist, so that all the arguments are passed to the console as if I manually passed each one?
p.s. I'm weakly familiar with the debug tool, but sometimes I find it easier and faster to just troubleshoot lines quickly and manually as above.
There is no easy pre-existing way to do this--mainly because this a problem solved by the debugger.
One could imagine hacking something together that might parse these parameters with a regex and set them automatically--or something like that. However, the effort would be much better spent learning how to use the debugger.
It should be quite quick to test the part of the code you are interested in with the debugger if you learn how to use it. RStudio has a visual debugger. Using this, you can simply mark the command you are interested in testing with a breakpoint and run the script. The script will run until it reaches the breakpoint, then stop there so you can inspect what is happening.
I'm a total noob at R and I may have bitten off a little more than I can chew but if you can help me I will appreciate it.
So what i'm trying to do is retrieve the top trending from twitter (working) and then use them as part of a URL to try pull back their definitions. My issue is the readline function seems to wait for me to hit return before it attempts the URL and i'm looking for a way to make it do the rest automagically, please find my code below
definitions <- ""
lapply(X=hashtags,FUN=function(X){
tagdef <- c(tagdefurl,X[[dfPointer]])
tagdef<- paste(tagdef,collapse=" ")
tagdef <- stringr::str_replace(string=tagdef,pattern=" ", replacement="")
definitions <- tryCatch(readline(tagdef),silent=F)
})
tagdef is defined as is supposed to be the list to store the returned definitions in
I've checked all my OAuth nonsense and everything on that side is fine, i'm getting the trends back without issue. Can anyone give me some pointers?
Unfortunately, you might have just stumbled on a case of "user error due to similarly named functions". In R, there is both readline (which reads a line from the terminal (in interactive use)) and readLines (which is used to *read some or all text lines from a connection).
The former expects user input, and the first argument is "prompt", hence the waiting for input.
Remember also that cApItaLiZation matters in R.