[R-SIG-Mac] Can't get help.start() to work.

Peter Cowan cowan.pd at gmail.com
Thu Oct 29 05:26:36 CET 2009


On Wed, Oct 28, 2009 at 8:39 PM, Rolf Turner <r.turner at auckland.ac.nz> wrote:
>
> On 29/10/2009, at 2:39 PM, Duncan Murdoch wrote:
>
>> On 28/10/2009 9:04 PM, Rolf Turner wrote:
>>>
>>> Under my newly installed version of R, 2.10.0, help.start() refuses
>>> to perform.  When I issue the command I get a ``Host is unreachable''
>>> message from the browser (which is Firefox, version 3.5.3).
>>>
>>> I have seen things about funnies with help under 2.10.0 but have
>>> not properly comprehended them.  I am not sure if they apply to my
>>> situation.  I did a bit of scrounging through recent postings to
>>> R-help and could not find anything relevant. Can someone tell me
>>> ***in monosyllables*** ( :-) ) how to get help.start() to work?
>>>
>>> Session info:
>>>
>>>> R version 2.10.0 Patched (2009-10-27 r50222)
>>>> i386-apple-darwin8.11.1
>>>>
>>>> locale:
>>>> [1] C
>>>>
>>>> attached base packages:
>>>> [1] datasets  utils     stats     graphics  grDevices methods   base
>>>>
>>>> other attached packages:
>>>> [1] misc_0.0-11    fortunes_1.3-6 MASS_7.3-3
>>>>
>>>> loaded via a namespace (and not attached):
>>>> [1] tools_2.10.0
>>>
>>> I have attached, in pdf form, a screen shot of the message I get
>>> in the Firefox window when help.start() fails.
>>
>> The problem appears to be with "WebMarshal Proxy".  I don't know if you
>> have any control over this, or it comes from your IT department, but you
>> need to tell it to let Firefox connect to R on your own machine (address
>> 127.0.0.1) if you want help.start() to work.  If that requires you to
>> set a particular port number (or range) for R to use, see the
>> ?tools::startDynamicHelp page for details.
>
>        This did not/does not happen with R version 2.9.2.  Why has
>        version 2.10.0 introduced a difficulty?
>>
- Hide quoted text -
>> You may find that the GUI works better.  It doesn't use Firefox, it has
>> its own built in browser, and it's conceivable that it will avoid going
>> through the proxy.
>
> Yes, the GUI works in respect of providing html help.  But
>
>        (a) I ***HATE*** using the GUI.
>
>        (b) Funny things happen when I try loading spatstat from the GUI.
>
>        If I click on Packages & Data --> Package Manager, I get an error:
>
>> Error in package.manager(is.loaded, pkgs, pkgs.desc, pkgs.url) :
>>  invalid arguments (length mismatch)
>> In addition: Warning messages:
>> 1: In .find.package(pkgs) : there is no package called 'BACCO'
>> 2: In .find.package(pkgs) : there is no package called 'forecasting'
>
>
>        There ***are*** packages BACCO and forecasting in my local
>        library (~/Rlib).  But ne'er mind.
>
>        So I try
>
>        library(spatstat)
>
>        from the command line (in the window opened by the GUI).  I get an
> error:
>
>> Loading required package: mgcv
>> Error in dyn.load(file, DLLpath = DLLpath, ...) :
>>  unable to load shared library
>> '/Users/rturner/Rlib/lattice/libs/i386/lattice.so':
>>  dlopen(/Users/rturner/Rlib/lattice/libs/i386/lattice.so, 6): Library not
>> loaded:
>> /Library/Frameworks/R.framework/Versions/2.7/Resources/lib/libR.dylib
>>  Referenced from: /Users/rturner/Rlib/lattice/libs/i386/lattice.so
>>  Reason: image not found
>> In addition: Warning message:
>> package 'spatstat' was built under R version 2.9.2 and help may not work
>> correctly
>> Error: package 'mgcv' could not be loaded
>
>        However if I abandon the (expletive deleted) GUI, start R from
> the command line and then load spatstat, all is well.  (Modulo some
> warnings about packages being built under earlier versions of R whence
> the help might not work correctly.  Which it doesn't anyway.)
>
>        So why should mgcv load when R is started from the command
> line, but not when it is started from the GUI?

I think this has been mentioned by others, but you seem to be making
life difficult for yourself.  When you install R on a recent mac you
essentially get two versions, one for 32bit and one for 64bit.  These
are not compatible w/ each other (and no amount of effort would ever
make them so).  The installer (2.10.0 IIRC) installs in addition a GUI
for each R.app (32bit) and R64.app (64bit).  The default when
launching R in the terminal with Snow Leopard appears to be 64bit.
You can check this by opening the Activity Monitor application and
looking for the R process.  If you install or build packages using the
default terminal version of R you *MUST* use R64.app for the packages
to work properly.  If built 64bit they must be run 64bit.  Your error
message say you are trying to load a package in 32bit R (probably
R.app) that have been install/build w/ 64bit R (the terminal).  I
recommend that you stick w/ one computer architecture (in this case
terminal and R64.app might work well for you).

>        This is getting ridiculous.  Everything I try engenders
> another error and another fiasco.  Things have become too complex and
> intricate.  IMHO too much effort has been expended on implementing
> gee-whiz facilities for the super-clever or GUI facilities for the
> retarded at the expense of simple usability for the ordinary middle of
> the road user.

I would gently suggest that this is not the best attitude to display
when trying to get help from volunteers.  I understand that you are
frustrated, but keep in mind that Simon and the other core developers
have expended far far more time that you've lost due to your
frustrations so that we could all have R.  Furthermore, the changes
that are riling you at the moment are as much (if not more so) a
result of the changes that Apple has made w/ Snow Leopard.

HTH

Peter



More information about the R-SIG-Mac mailing list