Dynamically load user32.dll from R & call external function - r

I try to access user32.dll functions in R Session. I used the code:
dyn.load("c://windows//system32//user32.dll")
.External("MessageBeep", 0L)
But R session crashes. According to documentation .External is intended to use during R package creation. However there was no prohibition to use it as shown above.
I am using Windows 8 and RStudio (1.1.453) / R (3.5.0). Could you advise a proper way to call external Windows functions from R session?

Artem,
You are accessing the Win32 C API, thus you can load the user32.dll, and then use the Foreign {base} .C() call too access the Window32 MessageBeep function.
Example Code
dyn.load("c://windows//system32//user32.dll")
.C("MessageBeep")
Runtime Output
> dyn.load("c://windows//system32//user32.dll")
> .C("MessageBeep")
list()
>
You should hear the Windows Message "Beep" - Alas, I have yet to figure out how to include sounds in solutions (Chuckle). I hope the above helps address your problem.
Note: I'd also recommend you take a look at the Rcpp package, I am a big fan.

Related

Data acquisition using QuantTools with R

I am using the QuantTools package in R language
When get_finam_data () is used, how can I obtain a list of symbols that can be acquired?
You should go to package internals to get the list.
Just download data for arbitrary symbol so the list is fetched from Finam server and saved for later use.
Keep in mind this is not documented so it can be changed in future versions.
get_finam_data( 'GAZP', Sys.Date() )
QuantTools:::finam_downloader_env$instruments_info
I suppose there no way to get it from QuantTools package. You can get it from https://www.finam.ru/profile/moex-akcii/mosenrg/export/?market=1 by hand or use external web sources.

Determining if there are unused packages in an R script [duplicate]

As my code evolves from version to version, I'm aware that there are some packages for which I've found better/more appropriate packages for the task at hand or whose purpose was limited to a section of code which I've now phased out.
Is there any easy way to tell which of the loaded packages are actually used in a given script? My header is beginning to get cluttered.
Update 2020-04-13
I've now updated the referenced function to use the abstract syntax tree (AST) instead of using regular expressions as before. This is a much more robust way of approaching the problem (it's still not completely ironclad). This is available from version 0.2.0 of funchir, now on CRAN.
I've just got around to writing a quick-and-dirty function to handle this which I call stale_package_check, and I've added it to my package (funchir).
e.g., if we save the following script as test.R:
library(data.table)
library(iotools)
DT = data.table(a = 1:3)
Then (from the directory with that script) run funchir::stale_package_check('test.R'), we'll get:
Functions matched from package data.table: data.table
**No exported functions matched from iotools**
Have you considered using packrat?
packrat::clean() would remove unused packages, for example.
I've written a command-line script to accomplish this task. You can find it in this Github gist. I'm sure there are edge cases that it misses, but it works pretty well, on both R scripts and Rmd files.
My approach always is to close my R script or IDE (i.e. RStudio) and then start it again.
After this I run my function without loading any dependecies/packages beforehand.
This should result in various warning and error messages telling you which functions couldn't be found and executed. This again will give you hints on what packages are necessary to load beforehand and which one you can leave out.

How can I tell which packages I am not using in my R script?

As my code evolves from version to version, I'm aware that there are some packages for which I've found better/more appropriate packages for the task at hand or whose purpose was limited to a section of code which I've now phased out.
Is there any easy way to tell which of the loaded packages are actually used in a given script? My header is beginning to get cluttered.
Update 2020-04-13
I've now updated the referenced function to use the abstract syntax tree (AST) instead of using regular expressions as before. This is a much more robust way of approaching the problem (it's still not completely ironclad). This is available from version 0.2.0 of funchir, now on CRAN.
I've just got around to writing a quick-and-dirty function to handle this which I call stale_package_check, and I've added it to my package (funchir).
e.g., if we save the following script as test.R:
library(data.table)
library(iotools)
DT = data.table(a = 1:3)
Then (from the directory with that script) run funchir::stale_package_check('test.R'), we'll get:
Functions matched from package data.table: data.table
**No exported functions matched from iotools**
Have you considered using packrat?
packrat::clean() would remove unused packages, for example.
I've written a command-line script to accomplish this task. You can find it in this Github gist. I'm sure there are edge cases that it misses, but it works pretty well, on both R scripts and Rmd files.
My approach always is to close my R script or IDE (i.e. RStudio) and then start it again.
After this I run my function without loading any dependecies/packages beforehand.
This should result in various warning and error messages telling you which functions couldn't be found and executed. This again will give you hints on what packages are necessary to load beforehand and which one you can leave out.

emacs: expand autocomplete for R function to include namespace

Am using EMACS/ESS as editor for R.
I find it helpful to refer to a function defined outside of base with it's relevant namespace; as well as being good practice in general, it seems to be necessary when running R CMD check on a package.
I really like autocomplete in EMACS and am wondering if there's a way to extend the functionality to include namespace when autocomplete-ing the name of a function.
For example (in R):
library(stats)
Then in ESS when I start typing dn the autocomplete dnorm appears (greyed out) and I can complete it by pressing TAB.
What would be better is to complete as stats::dnorm or even stats:::dnorm so that I don't need to manually check whether the function I'm using is in base. (For a relatively new user, memorizing the names of all functions in base may be a lot to ask).
Details:
EMACS: 2012-06-10 on MARVINGNU Emacs 24.1.1 (i386-mingw-nt6.1.7601)
ESS version 12.04-4
Icicles (default install c. Oct 2012). Not sure how to find version info. for this.
If this doesn't already exist, any pointers would be welcome. Note this is closely related but if the answer is already there then I'm not quite getting it...

How can I remove a lock from a linked environment in R?

I tried to run a Bioconductor package (truncateCDF) that modify an environment(hgu133plus2cdf), to remove unwanted probesets, from an affymetrix chip.
Everything went fine, until I got the following message (translated from french):
> assign(cdfname, cdf.env, env=CDF.env)
Error in assign(cdfname, cdf.env, env = CDF.env) :
impossible to change the value of a locked link for 'hgu133plus2cdf'
The assign function is the ultimate function of the code, that save the changes made to the environment dataset CDF.env to the original environment (hgu133plus2cdf), before using it in analyses of affymetrix chip results; so, it is essential.
My question: what is this locked link to the hgu133plus2cdf environment, and how could I bypass it.
The author of this package successfully run its package around 2005; so I suppose it is a feature introduced since then in R (probably not related to Bioconductor, since assign is a basic R function, reason why I ask this question on this forum instead of Biostar).
I tried to read the docs, but I am overwhelmed, when it comes to environments.
Thanks in advance for any help.
I don't think truncateCDF is from a Bioconductor package; it is a at least not current. This sounds like this post and the next two from the same thread from the Bioconductor mailing list. It is a result of a change in R -- packages now have not-easily-modified name spaces, and these are implemented by locking the environment in which name space symbols are defined. Removing probes is not an essential part of a typical microarray work flow. Please ask on the Bioconductor mailing list (no subscription required) if you'd like more help.

Resources