[Doug Hemken]

There are some really admirable design features in rcall, but I'm have serious trouble getting it to even run in a Windows terminal server environment - although R is installed in the default place! "setpath" fails utterly as well. The documentation is outdated, which further gets in the way. And the imposition of an Rprofile.site steps all over our server setup. Why not .Rprofile, which is the normal thing to use for project-specific configuration (it could look for further .Rropfiles, too)?

[Doug Hemken]

I second the call to not leave an outdated rcall on SSC

[Mike Lacy]

Per Rich Williams' #28 in this thread. I updated R and verified that I had the right version of -rcall-, and yes, I still have the oddity of -rcall- working fine with an incorrect but default path (/usr/bin/R on a Windows machine), but throwing an r(601) when I do -rcall setpath "C:/program Files/R/R-3.4.2bin/x64/"-
Again, I'm not whining <grin>, just putting out data to help with the diagnosis.

[Richard Williams]

This works for me. Note that I had to modify the setpath command from what I was using with the SSC version of Rcall, i.e. I had to add R.exe to the path.

. rcall setpath "C:\Program Files\R\R-3.4.2\bin\x64\"
file C:\Program Files\R\R-3.4.2\bin\x64\ not found
r(601);

. rcall setpath "C:\Program Files\R\R-3.4.2\bin\x64\R.exe"

. R: a <- 100

.
. display r(a)
100

Also, it may just be a typo, but it looks like Mike is missing a slash before bin in his example.


EDIT: Based on the help file, the preferred code may be

. rcall setpath "C:\Program Files\R\R-3.4.2\bin\x64\R.exe"

. rcall: a <- 100

. display r(a)
100

[Mike Lacy]

Rich has it here (thanks!) -- set path requires a whole file name, not just the containing directory--, but there's still a quirk:

rcall setpath "C:\Program Files\R\R-3.4.2\bin\x64\R.exe

runs without error, rcall continues to call R, but -rcall describe- still reports /usr/bin/R as the R pathj Just a cosmetic problem, I think.

[Richard Williams]

Maybe rcall describe isn't functional yet. Here is what I get:

. rcall setpath "C:\Program Files\R\R-3.4.2\bin\x64\R.exe"

. rcall describe
-------------------------------------------------------------------------------
         R path:   /usr/bin/R
      R version:   R version 3.4.2 (2017-09-28)
      R profile:   \ado\plus/r/RProfile.site
      R history:   \ado\plus/r/Rhistory.do
-------------------------------------------------------------------------------

[haghish]

Mike Lacy This was a bug. rcall was detecting the correct path to R, but printing the expected path of R on Unix instead. I released a new version on GitHub which fixes this problem. There was also a problem with the R profile and R history paths for Windows as Richard Williams showed above, which is also fixed now.

. rcall describe
-------------------------------------------------------------------------------
         R path:   C:\Program Files\R\R-3.4.1\bin\R.exe
      R version:   R version 3.4.1 (2017-06-30)
      R profile:   c:\ado\plus/r/RProfile.site
      R history:   c:\ado\plus/r/Rhistory.do
-------------------------------------------------------------------------------

[haghish]

There are some really admirable design features in rcall, but I'm have serious trouble getting it to even run in a Windows terminal server environment - although R is installed in the default place! "setpath" fails utterly as well. The documentation is outdated, which further gets in the way. And the imposition of an Rprofile.site steps all over our server setup. Why not .Rprofile, which is the normal thing to use for project-specific configuration (it could look for further .Rropfiles, too)?

Rprofile.site and Rprofile.Rprofile are very different things and work differently. The site is more global and influences the setup of R for rcall only. In otherwords, you can define different setup for R when it is called from rcall without effecting R when it's run from the cmd, for example. What difficulty did you experience when setting up rcall?

[Bruce Weaver]

Maybe rcall describe isn't functional yet. Here is what I get:

. rcall setpath "C:\Program Files\R\R-3.4.2\bin\x64\R.exe"

. rcall describe
-------------------------------------------------------------------------------
R path: /usr/bin/R
R version: R version 3.4.2 (2017-09-28)
R profile: \ado\plus/r/RProfile.site
R history: \ado\plus/r/Rhistory.do
-------------------------------------------------------------------------------

Richard (and others), I had to include the -force- option when installing the latest version of -rcall- from github.

net install github, from("https://haghish.github.io/github/")
github install haghish/rcall, force
rcall describe

Output:

. rcall describe
-------------------------------------------------------------------------------
         R path:   C:\Program Files\R\R-3.4.1\bin\R.exe
      R version:   R version 3.4.1 (2017-06-30)
      R profile:   c:\ado\plus/r/RProfile.site
      R history:   c:\ado\plus/r/Rhistory.do
-------------------------------------------------------------------------------

Prior to including -force- to install the latest version, I was seeing R path: /usr/bin/R, as in Richard's output.

[Richard Williams]

adoupdate is not updating the files either. I suspect haghish needs to update the distribution dates in the .pkg files. For example,

net describe https://raw.githubusercontent.com/haghish/rcall/master/rcall

currently shows a distribution date of 20170506.

When I try to install,

. net install https://raw.githubusercontent.com/haghish/rcall/master/rcall
checking rcall consistency and verifying not already installed...

the following files already exist and are different:
    c:\ado\plus\r\r.ado
    c:\ado\plus\r\rcall.ado
    c:\ado\plus\r\rcall.sthlp

no files installed or copied
(no action taken)
r(602);

But this forces the install:

. net install https://raw.githubusercontent.com/haghish/rcall/master/rcall, force
checking rcall consistency and verifying not already installed...

the following files will be replaced:
    c:\ado\plus\c\call_return.ado
    c:\ado\plus\m\matconvert.ado
[rest of output deleted]

If haghish updates the .pkg files then I think adoupdate will catch any future updates of his programs.

[Richard Williams]

The path looks weird in mine, but it seems to work:

. rcall setpath "C:\Program Files\R\R-3.4.2\bin\x64\R.exe"

. rcall describe
-------------------------------------------------------------------------------
         R path:   C:\Program Files\R\R-3.4.2\bin\x64\R.exeC:\Program Files\R\R-3.4.2\bin\x64\R.exe
      R version:   R version 3.4.2 (2017-09-28)
      R profile:   c:\ado\plus/r/RProfile.site
      R history:   c:\ado\plus/r/Rhistory.do
-------------------------------------------------------------------------------

[haghish]

Thanks Richard, yeah it printed both the automatically detected path and your defined path. That's fixed on the new update, 2.1.2 on GitHub.

For installing packages from GitHub, I really think the github install is ideal, because it also installs package dependencies (other Stata packages, if specified).

github install haghish/rcall

Bruce Weaver the force option shouldn't normally be required to reinstall an existing package. last year when the github package was released, there were many suggestions that the command should uninstall the current version and reinstall it without any hassle. I assume that your path wasn't updated, perhaps due to a global macro? I hope it works now.

[Richard Williams]

The path shows up correctly now, thanks.

The github install may be superior but it is sort of in an alternate universe. Most people not following this thread will not know about it, and will instead install the old version on SSC. Maybe you could work with Stata so that github support gets added to the net install and related commands. Sometimes the better method loses out to the already popular current method.

Also I'm not totally sure that you are right about dependencies. Seems to me I have seen SSC programs that installed other programs that they were dependent on, but I can't find an example right off the top of my head. In any event help files will usually tell you what else needs to be installed.

[Doug Hemken]

@Haghish,
It will take me a while to sort out all the config issues - at least one was due to the Stata config imposed by our sys admin.
But I did figure out why "rc" is showing up in my global environment - seemed really mysterious when I went to teach an R workshop yesterday evening, especially when I mainly use that name in Stata programming. It made me wonder just how quickly I am forgetting what I just did this morning!

I could swear yesterday **our** Rprofile.site was **not** running, this morning it appears **your** Rprofile.site does not run. Only one of the two will be invoked, correct?

You are leaving behind stata.output?

[Doug Hemken]

In my experience (we have about 1000 active users at any given time), only some of our experienced R users are aware of github, and only a handful (5-10) use it. The vast majority of our experienced Stata users find and use packages on SSC (hundreds of people, Stata is the dominant language here).
Keeping your source on github makes sense to me as a programmer, but I would push production versions to SSC regularly - it should just be part of the routine if you want people to find this!