I have a function that I'm trying to add to a package. I am generating the documentation via devtools::document(). The .Rd files for this and ~70 other functions are generated successfully, but this one function is not added to the namespace.
The file can be found at the following link, and perhaps importantly, is called truncate.distribution.r. I have many other functions with periods in the names, so I am almost certain that is not the problem.
However, as I was going through the NAMESPACE, I noticed this line S3method(truncate,distribution), and wondered if the similar name was a coincidence (i.e. comma, as opposed to period). I tried removing the period from the name, and re-generating the documentation and NAMESPACE, and it all worked just fine - that is, the function is exported with the package.
While the altered name works, I would like to learn why it failed and how I can prevent similar failures in the future. Also, I like the original name. :)
Anyone have any thoughts? Much appreciated.
So you guys are right, and it had to do with the periods in the names. The particular file that cause the problem for us was one where the first part of the name ("truncate."...) was already a base function, thus being interpreted as S3methods.
Thanks to all who answered. I'm not sure why I'm getting voted down - knowing not to use periods in function names is not inherent knowledge, nor is it expressly forbidden anywhere I looked (i.e. Hadley's, or Google's Style Guides).
I found one other potential cause of similar grief. My last line of Roxygen code had a typo in the #' #export command resulting in the same poor behavior
Related
I use the R package furrr for most of my parallelization needs, and basically never have issues with exporting things from my global environment to the cluster. Today I did and I have no idea why. The package documentation seems to describe the process by which global variables are sent to the clusters as "black magic." What is the black magic?
The furrr::future_options documentation says:
Global variables and packages
By default, the future package will perform black magic to look up the global variables and packages that your furrr call requires, and it will export these to each worker. However, it is not always perfect, and can be refined with the globals and packages arguments.
As a secondary question: is there an elegant way to tell it to do its black magic, but also to export something it missed? Or, are the choices a) all black magic, or b) hard code everything in the .options argument?
This doesn't totally answer the question, but I think it points you in the right direction. From the "Globals" section of this intro vignette:
It does this with help of the globals package, which uses static-code inspection to identify global variables. If a global variable is identified, it is captured and made available to the evaluating process.
There's also this "Common Issues with Solutions" vignette (which #michael helpfully linked above) that discusses some common "gotcha" things that result from the static code eval in the globals package.
I found my way here because my future_map() code was failing to find the variables I referenced inside a glue() call. That vignette explained exactly why this happens.
As to why your code was sometimes working and sometimes not, hard to say. But as you can see, there is sufficient complexity going on under the hood that I'm not surprised if some seemingly unrelated change broke something. (For me this change was cleaning up my code and using glue instead of paste :shrug:)
I am trying to make some changes or replace some functions with other ones within the R package rodd. I have downloaded and extracted the source codes. They are in different files and some of them need editing. How can I do it in a proper way?
I searched on the internet. I only found cases who need one single change in a function within a package. But in my case, the package rodd needs some more changes and also replacing some functions with the original ones. I also need to mention that I need to make a 2 dimensional (for the control variable X) version of the package. So I am still not sure which changes fit my needs and each time I need to make some changes and see which changes solve the problem. I also need to have both the actual version and the edited version of the package.
Any ideas/suggestions are appreciated.
tpopt(x, ...)
I would also mention I need to make some changes in the procedure (other functions) which result in the function tpopt, not the function tpopt itself.
I'm pretty new to R.
I just imported a CSV file into my R environment. I see the name of the dataframe and the name of the columns, but there is information below and I don't know what to make of it.
It looks like it might be records of the data types that R guessed when it imported the data, but I'm not sure. Can you confirm what it's communicating? Thanks!
The functions in the readr package add an extra spec attribute to the data they read in. It won't affect anything in later code. I assume it is intended for debugging purposes in case your data is imported poorly, you can see what was used so you can try something different in a manual override.
It's mentioned a bit in the readr vignette, especially the last two sections. You can access the spec attribute directly with either attr(your_data, "spec") or spec(your_data).
I have a question about R. I think I forgot to save one of the scripts I was working on and I'm trying to get it back somehow. The script involved commands to create plots.
If I use the command:
print(nameoftheplot)
I am able to print the plot. Does this mean that R still has the script somewhere in the working memory? And how can I get it back?
Thanks for your help!
With luck, your commands are saved in R’s history; you should immediately perform
savehistory('history.r')
This usually contains all the last commands you executed.
I am able to print the plot. Does this mean that R still has the script somewhere in the working memory?
Unfortunately, no. However, it still has the print object in memory, and you can dump that to retrieve some information:
dput(nameoftheplot)
Whether this is useful depends on how exactly the plot was created.
Apart from that, the following two things can give you information about the last state of your script:
ls()
will show you all the objects you defined in the global environment. You can look at their values for clues. In particular, if you defined functions, their code will be available in its entirety.
search()
will show you which packages your script loaded and attached.
From this you may be able to reconstruct large parts of your code.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
View the source of an R package
I want to see the source code of stats::reorder.
This answer seems not apply to built in packages which are compiled to bytecode:
> stats::reorder
function (x, ...)
UseMethod("reorder")
>bytecode: 0x103321718<
>environment: namespace:stats<
This has nothing to do with reorder being compiled to bytecode and everything to do with it being a generic function.
My answer here elaborates on this.
But specifically for this situation if you want to see the code you can use
# Find what methods are available for reorder
methods(reorder)
# Attempt to check out the code for reorder.default
reorder.default
# Use getAnywhere to view code regardless of if it is exported
getAnywhere(reorder.default)
As others have said, you want methods(reorder). But for your mode general question, the best way is to download the source code of R, and search the code with grep. You can also browse the code online but it's not always obvious in which file a particular function might live.
This isn't a matter of compilation, what you're seeing is the result of the fact that reorder is written to do different things depending on the class of what you want to reorder. There are separate reorder functions for different possible options, and you can list them by calling methods(reorder). You can then examine the source of whichever one is appropriate.