A function displays an informative message the first time it runs per R session. However, experienced users may want this message to not appear, ever.
I considered simply setting an options() when the package is loaded, then if the user really doesn't want to see any message, they can set the option value from TRUE to FALSE at the start of their script.
Are there any established conventions around how package level options should be set?
From my own thinking:
Try to ensure no overriding of existing options
Try to ensure the name of the option is not the same as any other option set in any other common package (that could be very confusing to the user)
Are there any other things to consider?
Note: I did find this, which looks promising, but unfortunately it seems to return a 404 not found.
Related
Using R Version 4.0.2 and RStudio Version 1.3.1056
This is honestly one of the strangest features I've seen in RStudio, and I suppose there's probably a good reason for it to be there, but I'm currently not seeing it and I feel that it can lead to a lot of issues of misleading data.
Basically, to my understanding, when you create and open an R project in RStudio, RStudio creates a Session with a Global Environment.
Every time you run something, this is added to the Global Environment, I assume it's done as a cached value.
However, I've encountered situations where this feature leads to either:
Outdated/wrong values being shown in my tests.
Cases where a function stops working altogether after changing 1 piece of code, executing the new code, then undoing the change.
functions "bleeding into" other files without importing/sourcing them.
Case 1 and 2 obviously leads to a lot of issues while testing. If you try to run a test like
test <- someFunction()
test #to display the value of the test
If the code is correct, the test will execute and the results of test will be stored in the Global Environment.
However, if you then proceed to break the code and run the test again, since test already has a value stored in Global Environment, that old value will print, even though the function failed and thus didn't return anything. Of course if you go above on the console feed, you might run into a line after test <- someFunction() saying "someFunction failed for X reason", but I still think it's both pretty misleading and not very intuitive. Sometimes the result of a function is really large and it's complicated to scroll all the way up the console to see if the code exited with an error, whereas other IDEs would simply immediately tell you at the end of the console that the code failed, and not print the old and outdated value.
Example: Running the proper code.
Running the code after having changed is.na to the non-existent is.not.na.
Notice how it's still printing the old value belonging to the previous version of the function.
The third case can also lead to misleading scenarios.
If you execute a function in any file within your session, the function is stored in the Global Environment. This allows you to call the function from any other file, even if you haven't added a source statement at the top to load the file containing that function.
Once again this can lead to cases where you inadvertently change/add a new function on file B without running it, then try to invoke the function from file A and you get unexpected results because you were actually invoking the old/outdated function, and the Global Environment has no idea about the changes to the old one or the new function.
All of these issues are rather easy to fix, but I think that's a bit beyond the point. Why is this a feature in general? Why isn't the Global Environment emptied upon errors in execution? I know that you can manually empty the GE whenever you want, but it seems odd to me that the IDE doesn't do it on its own, or, to my knowledge, that it doesn't provide you with an option for it to do it.
I can imagine that it provides some benefit at runtime, but is it really that significant that it can justify these behaviors?
I would like to use the named entity recognition functions in the monkeylearn package in R.
As part of the setting up process, we need to do the following:
"To get an API key for MonkeyLearn, register at http://monkeylearn.com/. Note that MonkeyLearn supports registration through GitHub, which makes the registration process really easy. For ease of use, save your API key as an environment variable as described at http://stat545.com/bit003_api-key-env-var.html. You might also want to use the usethis::edit_r_environ() function to modify .Renviron.
All functions of the package will conveniently look for your API key using Sys.getenv("MONKEYLEARN_KEY") so if your API key is an environment variable called “MONKEYLEARN_KEY” you don’t need to input it manually.
Please also create a “MONKEYLEARN_PLAN” environment variable indicating whether your Monkeylearn plan is “free”, “team”, “business” or “custom”. If you do not indicate it by default it will be “free” with a message. If your plan is “custom” you’ll need a third environment variable “MONKEYLEARN_RATE” indicating the maximum amount of requests per minute that you can make to the API. If you do not indicate it, by default it will be 120 with a message."
I've gotten the API key, but as a layman, I couldn't understand the guide on saving the api key as environment variable. Could anyone provide a step by step guide for Windows please?
Thank you.
monkeylearn maintainer here, sorry for the unclear docs.
It means you need to add two lines in an R startup file called .Renviron.
MONKEYLEARN_KEY="blablablayourkey"
MONKEYLEARN_PLAN="free"
The last line of .Renviron has to be an empty line.
To open .Renviron to edit it, you can use usethis::edit_r_environ(). After adding the two lines with your key and plan, don't forget to restart R.
Read more about startup files in general in this resource.
I hope this helps. Note that I don't look up Stack Overflow very often as opposed to rOpenSci's forum
I am using a 3rd party package for a script, I want to tweak one of the functions so that one of the variables created by the function is assigned to the global environment.
I did this previously by doing
fixInNamespace("the_function","the_namespace","namespace:::the_function")
And it opened a pop-up window where I could add my one line of code
assign("global_variable", "variable", envir = .GlobalEnv)
It worked like a charm, I could then write the rest of my script to use this newly formed variable.
I have tried to run the code again one day later and it can't find the global variable, and if I run
namespace:::the_function
It shows me the function code without my edit, why has it reverted back to its previous form? Is fixInNamespace not permanent?
Thanks,
Ryan
No, it's not permanent. It will last until the namespace is loaded again. Normally namespaces stay loaded for an entire R session, so your change will last for the session. (It is possible to unload a namespace without quitting R; in that case your change would be lost as soon as the namespace was unloaded.) In any case, the next time the package is loaded, it will be the original version of the namespace.
There are a couple of ways to make your change permanent, but doing this is not a good idea. One way is to call assignInNamespace from your startup code (see ?Startup for possibilities). Another is to edit the R source code, and build your own custom copy of R.
Neither of these is a good idea in the long term. Some future version of R might change the function you've modified, and then you'll end up with a modified obsolete version.
I'm composing a package in R 3.1.2, with RStudio, using the devtools package. When I check() the package, there is one persistent note to the effect that there is "no visible binding for global variable"...
I have read several threads that suggest assigning my offending variables to NULL, to using globalVariables(), and that pronounce anathema on globalVariables(). Nothing is working for me, unhappily. I'm happy to do anything that works, including submitting my package with the NOTE I'm getting, and keeping my fingers crossed.
But before I submit as is, can anyone enlighten me as to why one should try to avoid a the situation that generates the NOTE? Should I care?
Details: I am initializing an object in .onAttach() and assign()ing it into the global environment. I understand this may be bad practice.
I am trying to pass variables from one page to another using Sessions , but they don't seem to have effect. In the source page inside the razor syntax
Session["variable"] = "value";
And in the target page:
<p>#Session["variable"].ToString()</p>
but I get a server error
Exception Details: System.NullReferenceException: Object reference not set to an instance of an object.
Any suggestions would be most welcome........Thanks
I was only ever able to get this to work with casting:
<p>#(string)Session["variable"]</p>
Although it has been a long time since I have tried it with ToString() instead, I do explicitly remember my attempt to call a Session variable only successful with the casting option, although I have heard that ToString() should work. Either way, I always get it to work with casting.
That having been said, I feel it only right of me to warn you that if you are simply trying to pass data between pages, you shouldn't be using Session variables at all. Use hidden form fields, query strings, Url Data, or even cookies and/or databases before you do that.
I like to look at Session variables as something to quickly solve very special cases and only to be used very CAREFULLY. ALWAYS expect the value to be null and test its value before using it.
For help with the options for transferring data between web pages using WebMatrix, check out Mike Brind's very helpful site: http://www.mikesdotnetting.com/Article/192/Transferring-Data-Between-ASP.NET-Web-Pages <-- You'll want to bookmark this for now. It is right up the alley of what you are getting yourself into with WebMatrix.
If you still want to use the Session variable and casting doesn't work, the only other thing I can think that would cause the error is that the value you expect in Session["variable"] isn't what you think it is.
For the Record:
I was only trying to make a point when saying, "or even cookies and/or databases before you do that" Please do not use those options, as they are likely terrible in your case (also, cookies would just give you the same problems as Session variables, actually). In any case, it really all depends on how you are using the data and if you are always checking to make sure the value hasn't been cleared in the case of Session variables and/or cookies.