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

[stefano iacus]

I see,
just defining DISPLAY=:0 won't work in this case.
I think the right thing to do now is just to start X11 before loading 
this workspace file.

stefano

On Dec 15, 2004, at 6:37 AM, Dan Putler wrote:

> Hi Stefano,
>
> Here is a slightly re-named version of my .RData file (created from
> scratch, and then broken by loading Rcmdr, quiting Rcmdr, and saving 
> the
> workspace), along with a screen shot of what the error message when I
> bring up an R session using terminal. R aborts cleanly, so there is no
> R.crash.log file created.
>
> Hope this is the evidence you were looking for.
>
> Dan
>
> On Tue, 2004-12-14 at 14:16, stefano iacus wrote:
>> 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.
> <load_error.tiff><RData>