Skip to content

R 3.2, Mac 10.10.3 : help.search showing error

18 messages · Berend Hasselman, David Winsemius, Simon Urbanek +2 more

#
On Jun 13, 2015, at 11:04 PM, Berend Hasselman wrote:

            
There was no error either with using help() or using the Mac GUI package manager. Those were the reported difficulties previously reported.
The error I am getting was from the most recent R 3.2.0 downloaded yesterday. There is no 3.2.0-Patched for Mavericks.  The release candidate, R 3.2.1 RC, is marked on the ATT Research webpage as failing Make and it indeed fails to launch. I would NOT recommend that anyone accept that advice. 

But maybe it is a Mac-specific problem. When I remove the crippled R 3.2.1 RC and reinstall the R 3.2.0 and run from a Terminal window I do not get the help.search() error. So copying to R SIG Mac, and will not copy R-help on any further efforts.
#
Posting the session Info when running in the GUI
Error in help(db[i, "topic"], package = db[i, "Package"], lib.loc = lib,  : 
  'topic' should be a name, length-one character vector or reserved word
R version 3.2.0 (2015-04-16)
Platform: x86_64-apple-darwin13.4.0 (64-bit)
Running under: OS X 10.10.3 (Yosemite)

locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base     

loaded via a namespace (and not attached):
[1] tools_3.2.0

I had earlier tried following the code of help.search and its call to help by reading the code and running trace but was not able to find where the arguments of help.search had been renamed as ?topic?.

Then running in the Terminal window does not provoke the error.

I had earlier noted that the crash report for the launch of R 3.2.1 from the R.app (GUI) indicated that the directory that the GUI was attempting to load R from was incorrectly specified as: /Library/Frameworks/R.framework/Versions/3.3/Resources/

? 
David.
David Winsemius, MD
Alameda, CA, USA
#
Running R-3.2.1 RC on Yosemite 10.10.3 Mavericks version

Result of sessionInfo():

R version 3.2.1 RC (2015-06-10 r68503)
Platform: x86_64-apple-darwin13.4.0 (64-bit)
Running under: OS X 10.10.3 (Yosemite)

locale:
[1] en_GB.UTF-8/en_GB.UTF-8/en_GB.UTF-8/C/en_GB.UTF-8/en_GB.UTF-8

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base     

loaded via a namespace (and not attached):
[1] tools_3.2.1

and issuing the command

help.search(?linear models?) 

works perfectly ok.
On the page http://r.research.att.com: for R-3.2-branch  the R 3.2.1 RC did not fail make.
The development version of R failed.
And my R 3.2.1 of a few days ago has no problem with the help.search() function.

Berend
#
On Jun 14, 2015, at 9:33 AM, Berend Hasselman wrote:

            
We seem to be talking past each other. The failure I am seeing for 3.2.0 is in the R.app sessions. Not seeing error in a Terminal session.

This is what I see (today) at the att.research site:
============
R-devel
3.2.1 RC
(2015/06/10, r68509)	mavericks	Jun 14 00:39	x86_64: make FAILED  (log)
Package: OK

R-devel-mavericks-sa-x86_64.tar.gz (59Mb)

R-devel-mavericks-signed.pkg (69Mb, installer incl. GUI)
=============

The failure I described for version 3.2.1 RC  was the GUI that was failing to launch which I thought might be related to the att.research note "x86_64: make FAILED (log)", but this line from the log link following the notation FAILED:

http://r.research.att.com/log-R-devel.mavericks.x86_64.html

..... suggests an attempt to find resources for version 3.3.0:

clang -dynamiclib -Wl,-headerpad_max_install_names  -undefined dynamic_lookup -single_module -multiply_defined suppress -L/usr/local/lib -install_name libR.dylib -compatibility_version 3.3.0  -current_version 3.3.0  -headerpad_max_install_names -o libR.dylib CommandLineArgs.o Rdynload.o Renviron.o RNG.o agrep.o apply.o arithmetic.o array.o attrib.o bind.o builtin.o character.o coerce.o colors.o complex.o connections.o context.o cum.o dcf.o datetime.o debug.o deparse.o devices.o dotcode.o dounzip.o dstruct.o duplicate.o edit.o engine.o envir.o errors.o eval.o format.o gevents.o gram.o gram-ex.o graphics.o grep.o identical.o inlined.o inspect.o internet.o iosupport.o lapack.o list.o localecharset.o logic.o main.o mapply.o match.o memory.o names.o objects.o options.o paste.o platform.o plot.o plot3d.o plotmath.o print.o printarray.o printvector.o printutils.o qsort.o random.o raw.o registration.o relop.o rlocale.o saveload.o scan.o seq.o serialize.o sort.o source.o split.o sprintf.o startup.o subassign.o subscript.o subset.o summary.o sysutils.o times.o unique.o util.o version.o g_alab_her.o g_cntrlify.o g_fontdb.o g_her_glyph.o xxxpr.o   `ls ../unix/*.o ../appl/*.o ../nmath/*.o` ../extra/tre/libtre.a  ../extra/intl/libintl.a ../extra/tzone/libtz.a -L../../lib -lRblas -L/usr/local/lib/gcc/x86_64-apple-darwin13.0.0/4.8.2 -lgfortran -lquadmath -lm    -Wl,-framework -Wl,CoreFoundation -lreadline  -lpcre -llzma -lbz2 -lz -licucore -lm -liconv
David Winsemius
Alameda, CA, USA
#
It says R-devel version 3.2.1 RC. Development version.
Wouldn?t/Shouldn't that be 3.3.0  especially since it is trying to find resources for 3.3.0?

I?m using R-3.2-branch: version 3.2.1 RC.
which is the upcoming R 3.2.1 AFAICT and I have assumed.

Berend
#
Yes, that is the way it is supposed to work. 3-2-branch moves through the sequence 

3.2.0 alpha
3.2.0 beta
3.2.0 RC
3.2.0 
3.2.0 Patched
3.2.1 beta
3.2.1 RC
3.2.1
3.2.1 Patched
<etc>

whereas R-devel should stick at

3.3.0 Under development (unstable)

until it is time for 3-3-branch, at which point it changes to 3.4.0 Under development, etc.

How R-devel ended up listing as 3.2.1 RC is hard to tell, but presumably it is a local error at r.research.att.com (there seems to be no issue with the present sources in SVN).

Notice that 3.2.0 Patched disappears when 3.2.1 prereleases start. There seems to be no backlog of builds of 3.2.0 Patched, but there would be little point in looking for one. 3.2.1 is really just a formal release of patches-to-date.
#
Note that the build failed - this means that there is no actual way to determine the version (since R can't be run). I think what happens is that the currently installed version is then reported which is whatever did succeed last - in this case 3.2.1 RC. The bug here is that nothing (other that the error) should have been reported.

Cheers,
Simon
On Jun 14, 2015, at 3:26 PM, peter dalgaard <pdalgd at gmail.com> wrote:

            
#
OK, that explains it.

(However, `cat VERSION` should work whether or not the build succeeds).

-pd

  
    
#
On Jun 14, 2015, at 11:11 PM, peter dalgaard wrote:

            
In the confusion about which build is which I hope it's not forgotten that the problem started with ver 3.2.0's help.search function throwing an unexpected error when run in the R.app environment.
#
On 15 Jun 2015, at 08:40 , David Winsemius <dwinsemius at comcast.net> wrote:

            
Yes, but the suggestion was that the issue had gone away in current R-3-2-branch versions (never mind the current name), so had it? (I'd rather not check it for you because I'm superstitious about upsetting the build machine so close to release.)

-pd

  
    
#
On Jun 15, 2015, at 7:36 AM, peter dalgaard <pdalgd at gmail.com> wrote:

            
Yes, that has been long fixed:


Last-update: 2015-04-20
*       fix HTTP help startup to use new R 3.2.0 API

*       adapt to changed variable names in hsearch$match


Cheers,
Simon
#
This is on a machine where I obtained the R/GUI package installer on Saturday for the express purpose of attempting (and succeeding) in replicating the report I saw in Rhelp.


R version 3.2.0 (2015-04-16) -- "Full of Ingredients"
Copyright (C) 2015 The R Foundation for Statistical Computing
Platform: x86_64-apple-darwin13.4.0 (64-bit)

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.

  Natural language support but running in an English locale

R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.

Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.

[R.app GUI 1.65 (6931) x86_64-apple-darwin13.4.0]

[History restored from /Users/davidwinsemius/.Rapp.history]
Error in help(db[i, "topic"], package = db[i, "Package"], lib.loc = lib,  : 
  'topic' should be a name, length-one character vector or reserved word
R version 3.2.0 (2015-04-16)
Platform: x86_64-apple-darwin13.4.0 (64-bit)
Running under: OS X 10.10.3 (Yosemite)

locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base     

loaded via a namespace (and not attached):
[1] tools_3.2.0

Best;
David,
David Winsemius, MD
Alameda, CA, USA
#
On Jun 15, 2015, at 10:09 AM, David Winsemius <dwinsemius at comcast.net> wrote:

            
^^ but that's old! Please test with the current RC - it's pointless to report things on old releases that have been fixed since ... I really don't know how else we can make this more simple - we have nightly builds as easy to install as the releases and still people don't bother testing them until it's too late :(
#
On Jun 15, 2015, at 7:27 AM, Simon Urbanek wrote:

            
Well, it's what I got 2 days ago from http://r.research.att.com/
I went to your site on Saturday. Downloaded the available Mavericks releases. Both of them. One threw the error. One simply failed to load.

http://r.research.att.com/mavericks/R-3.2-branch/R-3.2-branch-mavericks-signed.pkg is different that what I got  2 days ago. Yes. the error is corrected.
#
On 15 Jun 2015, at 16:51 , David Winsemius <dwinsemius at comcast.net> wrote:

            
Well, we don't change released versions retroactively.

R 3.2.0 is R 3.2.0. If there's a bug in 3.2.0, there's a bug in 3.2.0 and there will continue to be a bug in 3.2.0. If we fix it, the fixed version will be something other than 3.2.0.

(Actually, we could conceiveably distribute and modify R.app and other shell applications out of sync with R itself, but that is not what we do.) 

-pd
#
On Jun 15, 2015, at 8:14 AM, peter dalgaard wrote:

            
The bug is (or was)  in the interaction with the GUI. Not in R 3.2.0.
#
On Jun 15, 2015, at 11:25 AM, David Winsemius <dwinsemius at comcast.net> wrote:

            
But the GUI *is* part of the R 3.2.0 release so, yes, it was a bug in R 3.2.0.

You can always fetch either the GUI or R from the nightly pages. Since you knew it's the GUI, you could simply take the updated GUI from there. But if that doesn't fix it, you still have to get the full R since it may be an interaction of both.

All am I asking is for people to test the betas/RCs since we typically get reports only after the release which is simply too late to do anything about it.

Cheers,
Simon
#
Perhaps the latest R-patched should also be published at
http://cran.r-project.org/bin/macosx/, just to make it more
discoverable + encourage its use by more users? (In other words --
should users be encouraged to run R 3.2.0-patched instead of R-3.2.0?
If so, the 'patched' link should be advertised more strongly than R
3.2.0, in my opinion).

The http://r.research.att.com/ page is 'scary' for new users -- since
it's a different page, with different styling, and the big
'experimental' caveat (ie -- don't blame us if it blows up your
computer) so I think this dissuades a lot of users from testing. In
particular, that text seems to give the connotation that even
R-patched is also 'dangerous'; I don't think that's true and so that
ends up scaring more potential users off.

Also, is there any reason for displaying a download link for the GUI
sources as well? I imagine the overlap between users downloading R
binaries and users downloading R GUI sources is pretty small; at best
I think it confuse new users (wait, so if I want to install R with a
GUI, do I need to download both? What are 'sources', anyway?)

On Mon, Jun 15, 2015 at 8:37 AM, Simon Urbanek
<simon.urbanek at r-project.org> wrote: