I am developing an R-package in one R-session (within R-Studio) while testing the package in another R-session (within a second instance of R-Studio). The package ("P") contains an R-function "foo".
In the test session all calls to foo are made by explicit qualification P::f(...).
When a new version is ready, the old library is uninstalled (checked that it is really gone from all locations in .libPaths()), newly built and reinstalled (with a new version number).
After some iterations of this, a bizarre phenomenon started: an old version of P::foo
executes even though it should not exist anywhere. I even check in the test session via
R> P:foo
the source code and it displays the latest version. However this is not the code that is executing. I can tell by the way the log file is written and there is simply no doubt about it. It is an old version that is executing.
What could I do to analyse this situation?
Related
Due to recent experience with several bugs created by updating packages, I wonder what the best approach is for the following problem:
I currently provide a stand alone version so to say of my shiny App (just the script files to run it locally) and run a long list of require() functions to load / install the needed packages. However, in the end I would like to use fixed package versions to avoid bugs created by changes in packages.
Is there a way to ensure that the user, who may have older or newer versions of packages on their computer, is using the right version of all the packages my app needs?
You can consider using packrat: https://rstudio.github.io/packrat/.
Unfortunately, private libraries don’t travel well; like all R
libraries, their contents are compiled for your specific machine
architecture, operating system, and R version. Packrat lets you
snapshot the state of your private library, which saves to your
project directory whatever information packrat needs to be able to
recreate that same private library on another machine.
Short tutorial:
RStudio - File - New Project - New Directory - New Project - "Do: use Path" - Create Project
Enter in the R(Studio) console:
Code:
packrat::init()
.libPaths() # test if libpath has changed
install.packages("reshape2") # installs within one of the packrat libpaths
Installing package into ‘C:/R/packRatTest/packrat/lib/x86_64-w64-mingw32/3.4.3’
Assumption would be that you can use and share RStudio Projects, but i think it would be hard to work without them anyway ;).
Try writing your shiny app as a package. You can, somewhat, control that through the description file.
Since you said you're using script take a look at: https://github.com/chasemc/electricShine
Even of you don't use it, hopefully looking at the code will help for things like setting the download repo to be a specific MRAN date.
I'm writing an R package using devtools and roxygen2. Note that this is my first time making a package, so maybe I am missing something important.
I want to add a dependency, the package, DESeq2. I have tried to do this in a number of ways, but believe the right way is to add the following to my DESCRIPTIONS file.
Depends:
DESeq2
If I add this, when I build and reload I get a fatal error. When running in RStudio it just gives a "Fatal Error" dialog and restarts the application. It appears to build, but when it does, library(myPackage), it crashes immediately.
If I remove the Depends section from the DESCRIPTIONS file it builds and loads fine. What's more, if I include a different package, for example, ggplot2, then it builds and loads fine as well.
What about a package would cause it to fail to load as a dependency and completely crash? Is there another way to require it or is there any way to dig deeper into the cause?
Thanks very much in advance.
I am executing an R script as ms-sql stored procedure. I'm trying to use the "geosphere" package, however when I execute the stored procedure, I'm getting the error "Invalid BXL stream" and the execution halts. The package is already installed on the machine and simply loading the package causes this error i.e library("geosphere") causes the error.
I can however, use this package independently with R Studio, so there doesn't seem to be any issue with the package.
I know this question is dated but I've run into the same issue multiple times so I wanted to leave my results here.
What I've found in using sp_execute_external_script to run R and Python scripts in MS-SQL 2016/17 is that the BXL error comes for 2 different reasons
Bad data types - Often, SQL doesn't understand the data types being sent out of the script. Usually explicitly casting the data as a certain datatype helps here.
Bad package configuration - Certain packages in the R and Anaconda distributions don't sync well with the stored procedure since the database blocks certain dependencies in these packages. Try reinstalling the package in the SQL installed instance of R or Python.
It seems that your problem falls in the latter category. I hope that helped!
Had a similar issue today but with a different package. Getting "invalid BXL stream from MSSQL stored procedure. However, i found that If i opened up Rterm.exe and typed the command 'require(packagename)' then Rterm crashes with "Rterm frontend has stopped working". This looks like a memory issue - which has also been suggested causes the "invalid BXL stream" error.
However, my issue turned out to be the fact that the dependencies for the packages had not been installed correctly (perhaps you are working through a proxy?).
I basically removed all the library packages that had been created when I first installed the problem package and did a install.packages("packagename"). All started working!
Apologies - just noticed that you stated that the package worked independently with R studio - this is probably an issue with R Memory allocation with SQL - See http://henkvandervalk.com/introducing-microsoft-sql-server-2016-r-services
This is a very specific question.
I have a simple Shiny app, using the latest version of R (3.2.2), RStudio (0.99.473), all packages up-to-date, tested in both Windows 7 and Ubuntu 14.04. The same thing happens in both SOs.
I have a library of functions which I embedded in a "package", with a properly created DESCRIPTION file. I use devtools to load this package. So, the first lines of code in my very simple Shiny app are
library("devtools")
load_all("../../RTEMP");
Since I plan to use some of these functions within the Shiny app. The package name is not actually RTEMP, I created this temporarily in order to isolate the problem. This temporary package has one single file inside RTEMP/R/, something.r. This file contains one line of code:
AA <- setRefClass("AA");
So I am creating a reference class with nothing but a name (my original code relies on R objects of this type). I am not doing anything with the package, simply loading it.
When running the Shiny app for the first time after opening RStudio, it works fine. If I close the app and open it again, I get the following error message:
ERROR: shinyjs: you cannot mix named and unnamed arguments in the same function call
Curiously, if I change the beginning of my Shiny app to this:
#library("devtools")
#load_all("../../RTEMP");
AA <- setRefClass("AA");
So, commenting the package loading and setting the reference class inside the Shiny app, everything works fine.
The problem happens when I call setRefClass from within a package loaded with devtools, but not when I call it directly from Shiny. Also, I can load it the first time, but not the second (the Shiny Window simply shows the error message above).
Any ideas what may be causing this bug?
Thank you very much.
It is actually a problem in the devtools package that is causing incompatibility with shinyjs. I submited this bug report and hopefully this will not happen in the next versions.
If you experienced a similar error message with Shiny, there might be other functions in other packages (or in your own package) that needs the namespace.
I've included a library called blotter in my R script which has a bug in it. Is there an easy way for me to edit the source to try and debug the issue?
Look up the trace and browser functions, they are the basic tools in R for debugging. Say you want to edit the source of function foo, then saying
trace("foo",edit=TRUE)
will open up the source of foo in the editor for you to change. However, this is for interactive debugging; the source files in the packages are not changed. So once you have found the bug, you need to change the package source files for the change to be permanent.
Such a feature is implemented in the development version of R (Jul 16, 2010):
A new facility has been added to r-devel for experimenting by authors of
packages.
The idea is to insert modified code from the package source into the
running package without re-installing. So one can change, test, change,
etc in a quick loop.
The mechanism is to evaluate some files of source code, returning an
environment object which is a snapshot of the code. From this
environment, functions and methods can be inserted into the environment
of the package in the current session. The insertion uses the trace()
mechanism, so the original code can be restored.
The one-step version is:
insertSource("mySourceFile.R", package = "myPackage", functions = "foo")
See this post for further details: Inserting and testing revised functions in a package
Your question of Is there an easy way for me to edit the source to try and debug the issue? has the obvious answer: Use the source, Luke!
blotter is a package on R-Forge from where you can get blotter sources here. That is the standard way of looking at Open Source and possibly helping it along with a bug fix.