[R-SIG-Mac] Re: Two other questions

[stefano iacus]

Hi Dan,
I'm forwardinf this mail to r-sig-mac as well as it is of common 
interest I guess.

On Dec 14, 2004, at 8:08 PM, Dan Putler wrote:

> Hi Stefano,
>
> Thanks for the quick reply. The solution works for all help requests
> from Rcmdr except for getting help on a dataframe contained in a
> package, where an error occurs. However, it is an Rcmdr issue since the
> same error occurs under Linux and Windows when htmlhelp is TRUE.
>
> I do have two other questions, one trivial (but I haven't seen
> documented anywhere) and one difficult. The trivial question is how do 
> I
> create a binary package for OS X. Under Windows this amounts to 
> building
> the package, and then zipping the directory of the built package and 
> its
> contents using the command "zip -r9x". My guess is that the process is
> similar under OS X, with the exception that tar is used instead of zip.
> As a result, other than "c", "z", and "f", what flags do I use with 
> tar?

yes, exactly. "tar zcf xx.tgz path_to_xx_package".
By default, .tgz is the extension for binary packages for R under OS X.


>
> The difficult issue is that if you run Rcmdr in a workspace, and then
> save that workspace before quiting R, some elements of the Rcmdr
> namespace seems to persist. The impact of this is that when you attempt
> to launch R again from the directory containing the workspace, R aborts
> on launch.
It could be of interest to be able to reproduce it.  Can you give us 
some reproducible small workspace and R.app error log?

>  I found that I could get R to load if I had X11 _prior_ to
> launching R. I think this is a result of Rcmdr requiring tcltk, and 
> this
> element of the Rcmdr namespace is one of the things that persists.
yes

> R
> doesn't abort under Linux or Windows since everything happens under the
> same windowing system.
not for Wìndows, but under windows tcltk is always available. But you 
are right, it works.

>  I sent email to John Fox about this issue, but
> since he does not own a Mac, there isn't much he can do.
I'm not sure how he can solve this problem since (but probably someone 
here has hints).


>  My question is
> whether or not there is a work around to this whereby R starts X11
> rather than aborting, or an option can be set whereby X11 is started at
> R startup?

we can add an option for that R.app prefs in fact but I'm not sure it 
could work either as launching X11 is not syncronous anyway. Even if 
R.app starts X11 for you, there's no guarantee that X11 is really 
running at the moment R requires it.