Skip to content

2.10.0 beta help functions

13 messages · Peter Cowan, Duncan Murdoch, Rob Goedman +2 more

#
I just installed the nightly from r.research.att.com called "R 2.10.0
beta (2009-10-13)" for leopard using the pkg installer.

When I use ?plot or help(plot) the help window opens, but is blank.
And, I get this warning:
Warning message:
In help("plot", package = NULL) :
  htmhelp = TRUE is deprecated: use help_type ="html"

I know the help system has changed significantly in 2.10.0 and I
apologize if it is poor form to report errors such as this while the
still in the beta phase, but my reliance on these help functions has
prevented me from continuing to use the beta and test other changes.

BTW thank you for the option, in the new installer, to only install
the 64bit GUI version.

Thank you,

Peter
#
Peter Cowan wrote:
I can confirm the problem in a current download, which labels itself as 
2.10.0 alpha (2009-10-08 r49995), R for Mac OS X GUI 1.30-devel Leopard 
build 32-bit.

You can get to the help system by running help.start(), but internal 
requests like ?plot will still go to the internal browser, which isn't 
working.  You can work around the bug by deleting the "AQUA" section of 
utils:::print.help_files_with_topic, e.g. by doing as follows:

print.help_files_with_topic <- utils:::print.help_files_with_topic

and then deleting the lines

    if (.Platform$GUI == "AQUA") {
        .Internal(aqua.custom.print("help-files", x))
        return(invisible(x))
    }

from your copy of print.help_files_with_topic.

One other problem with the installer:  by default it installed both 32 
and 64 bit versions, but R wouldn't start until I re-installed without 
the 64 bit version.  I'm using Leopard 10.5.8 on an old Intel Core Duo 
Macbook.  Can the installer detect that 64 bit executables are not 
supported, and not install it?

Duncan Murdoch
#
On Oct 14, 2009, at 9:12 PM, Duncan Murdoch wrote:

            
Thanks - I'll look into this.
It *is* checking the CPU and adjusting the installation accordingly,  
but there is some conflict in the automatically generated installer --  
it's not present when I create the package manually so it will need  
some more investigation...

Thanks,
Simon
#
On Oct 14, 2009, at 7:19 PM, Peter Cowan wrote:

            
To the contrary! The whole point of the beta phase is that it gets  
tested and all errors reported -- I'll look into this, thanks for the  
report.

Cheers,
Simon
#
Hmm, I think you probably have pre-built html pages.  I simply don't 
see any code that will generate them, either directly or by starting 
the httpd server to do so.

I just did some quick experiments, and I get blank pages on packages 
without pre-built html, and correct ones on a package I just installed 
with 'R CMD INSTALL --html'.
On Thu, 15 Oct 2009, Rob Goedman wrote:

            

  
    
#
On Oct 15, 2009, at 16:01 , Prof Brian Ripley wrote:

            
Yes, that's likely. They used to be part of the installation but now  
are not. The fact that they are missing was useful to point out that I  
forgot to switch R.app from html to dynamic help (fixed now), but I  
was actually planning on keeping them installed for other software  
that relies on it (e.g. JGR). That will give those packages the chance  
to update until R 2.11.0.

Thanks,
Simon
#
Both the installer issues as well as the help should be fixed. Please  
try tonight's builds [tomorrow].

Thanks,
Simon
On Oct 14, 2009, at 19:19 , Peter Cowan wrote:

            
#
On Thu, 15 Oct 2009, Simon Urbanek wrote:

            
I am sure Simon knows this, but they are still optional (configure 
option --enable-prebuilt-html).  More seriously, they are pretty much 
untested and I've fixed a couple of non-trivial bugs today (so the 
HTML files need to be regenerated).

Also, I've just updated my checkout of the Mac-GUI project and rebuilt 
it, and whereas help() now works with dynamic help, help.search() 
still fails to find pages for packages not under the main library tree 
(print.hsearch in the Mac-GUI project needs updating).

It's your prerogative to ship prebuilt HTML pages, but they are not 
going to be shipped on Windows, and not AFAIK on Linux binary builds, 
so a fair proportion of JGR users will want an update anyway.  They 
just add to the size of the download and the vast majority of users 
will never access them.

Brian

  
    
#
On Oct 15, 2009, at 17:00 , Prof Brian Ripley wrote:

            
Ok, updated (it wasn't the most beautiful piece of code before and  
it's not now but it might work).
Oh, ok -- I thought we agreed to keep them in binary distributions  
until 2.11, but if Windows doesn't ship them then there is no point,  
indeed...

Thanks,
Simon
#
Simon Urbanek wrote:
Both problems (help system and 32 bit cpu detection) appear to be fixed 
as of

R version 2.10.0 beta (2009-10-15 r50107)
R.app GUI 1.30-devel (5506 Leopard build 32-bit)

Duncan Murdoch
#
On Fri, Oct 16, 2009 at 10:18 AM, Duncan Murdoch <murdoch at stats.uwo.ca> wrote:
With

R version 2.10.0 beta (2009-10-15 r50107)
R.app GUI 1.30 (5506) x86_64-apple-darwin9.8.0

I can confirm that the help problem I reported (using ? and help())
are now fixed.

However, the GUI help interfaces -- text fields at the top of the
console and the top of the help window, do not seem to work.  The help
window gains (or keeps) focus but the help page is not updated.

Thank you for the quick update, I'll continue to poke around the help system.

Peter
#
help.search() now works in today's snapshot (and has caught up with 
2.10.0 beta), but did not in yesterday's.

Also, today's manages to install R.app and R64.app in Applications 
(the last two day's did not, even after I uninstalled those apps).

capabilities('tiff') reports no native TIFF support (someone who 
patently failed to RFTM called it 'misleading' recently despite the 
prominent NOTE on the help page): I thought you intended to add it?

Another thought for consideration: the Windows binary builds now have 
memory profiling turned on because although there is a small 
performance penalty, it seemed better to allow end users for do 
R-level memory debugging without needing to recompile R from the 
sources.  Might be worth it for Mac users too?

I did some Snow Leopard builds of 2.10.0 beta yesterday (on a machine 
that had been upgraded from Leopard, which may be relevant as we found 
some oddities, and will re-install it from scratch).

1) configure failed to find the X libraries (even though they were 
present), because it seems that /usr/X11/lib is no longer in the 
default ld search path.  We've seen something similar reported before, 
and e.g. LIBS=-L/usr/X11/lib fixed it.

2) I tried building (x86_64) with llvm-gcc and clang.  The build with 
llvm-gcc failed with an internal compiler error in datetime.c.  The 
build with clang almost worked, but had a configure error in package 
foreign.  The claims that clang was a faster compiler were obviously 
true, but the claims for better error messages seemed untrue: some 
were clearer but some were a lot more confused (not that production 
code is a good test of error messages).
On Thu, 15 Oct 2009, Simon Urbanek wrote: