Re: [R-SIG-Mac] Homebrew [was: from Mac to LInux?]

2020-04-03 Thread Rainer Krug



> On 3 Apr 2020, at 13:25, Simon Urbanek  wrote:
> 
> Rainer,
> 
> 
>> On 3/04/2020, at 10:01 PM, Rainer M Krug  wrote:
>> 
>> Thanks a lot for your detailed response - it is very much appreciated.
>> 
>>> On 2 Apr 2020, at 22:30, Simon Urbanek  wrote:
>>> 
>>> 
>>> 
 On 2/04/2020, at 9:15 PM, Patrick Schratz  
 wrote:
 
 AFAIK most people on that list would vote hard against installing R via 
 homebrew for several reasons - maybe there should be a section about this 
 on the R dev / CRAN page to address this topic, @Simon? Otherwise this 
 will come up again and again.
 
>>> 
>> 
>> 
>>> That main objection is that people are mixing Homebrew with CRAN and 
>>> vice-versa which leads to many problems. You cannot use packages from CRAN 
>>> when using Homebrew, period, and you have to be really careful if you want 
>>> to mix Homebrew libraries (not anything R-related) with CRAN (it is doable 
>>> if you know what you're doing).
>> 
>> 
>> This is definitely true (and I assume, you are referring to CRAN binary 
>> packages).
>> 
>> But I am wondering: I am always installing from the normal CRAN mirrors, and 
>> my R installation (homebrew) always installs from source. I never use `type 
>> = “source”`in the installation for packages. 
>> 
>> My question: when would I install incompatible packages (I assume, you mean 
>> binary packages for Mac) from CRAN?
>> 
> 
> Maybe you wouldn't but I have seen people do it.

My question would be: how? Is the installation from binary forced when 
installing with that option?

> 
> 
>> 
>>> 
>>> The fundamental issue is that package managers like Homebrew replace system 
>>> libraries with their own (for new features/updates that the system 
>>> libraries don't provide) which break anything that relies on the system 
>>> library. Out of all the package managers Homebrew the only one that is 
>>> trying to address the issue by trying to separate them, but even that has 
>>> been diverging over time.
>>> 
>>> The second issue is that they are increasingly replacing toolchains 
>>> (compilers) with their own builds, which makes everything incompatible in 
>>> explosive ways (things just segfault). Making sure that a compiler 
>>> toolchain is stable is actually non-trivial and many packager manager 
>>> authors/maintainers have little experience with this. That used the be the 
>>> primary reason to avoid them, because it was just normal that the released 
>>> binaries were miscompiled and things would break all the time. Fortunately, 
>>> I think that has gotten better over time.
>>> 
>>> If you stick only with Homebrew, then you're likely ok, but you're on your 
>>> own and have to compile all packages form sources.
>> 
>> This is true, but I did not encounter big problems. And this is, why I 
>> thought loud in suggesting to setup a (non official!) homebrew tap to 
>> install the packages, similar to how it is in linux (Debian).
>> 
>>> Majority of our time as CRAN maintainers for the binary releases is about 
>>> providing dependent libraries for packages and making sure things "just 
>>> work”.
>> 
>> And I think everybody really appreciates this and is VErY happy about it. 
>> This is essential work!
>> 
>>> It is doable, just a lot of work, so by using Homebrew every user has to 
>>> spend that time.
>> 
>> Doable: definitely. lot of work: in my experience not that much more.
>> 
>> Overall, I definitely agree, that the official distribution should stay the 
>> proper apple way. But there are circumstances, where these are delayed, or 
>> problems occur after macOS upgrades, which will delay the compilation of new 
>> ones (GRASS did not have Mac binaries for a long time due to this problem). 
>> 
> 
> I'm not sure what you refer to, but if there are issues, please let me know. 
> If you don't report issues, they won't get fixed.


No problems here - this was just an example, where a second "approved” 
(whatever that means) installation approach would be useful.


> 
> 
>> So an alternative way of installing, community supported but approved, would 
>> be preferable. The r formula for homebrew has been installed in the last 
>> year more that 112.000 times (https://formulae.brew.sh/formula/r 
>> ) so I think there is likely a rather 
>> large user base of R from homebrew. 
>> 
>> A first step in this direction, would be to either include homebrew in this 
>> list, or create a new R-sig-hoebrew list, which could become the home of 
>> these discussions.
>> 
> 
> I'm not sure I'd like to go there. I would direct that to Homebrew as we have 
> nothing to do with the formulae used there. However, that's not really my 
> call.


At homebrew, you have to get hold of the maintainer of that formula - which is 
often not that easy. Power user problems of a software can only be solved by a 
power user of that software - and writing a formula for homebrew, only requires 
a basic understanding of the program 

Re: [R-SIG-Mac] Homebrew [was: from Mac to LInux?]

2020-04-03 Thread Simon Urbanek
Rainer,


> On 3/04/2020, at 10:01 PM, Rainer M Krug  wrote:
> 
> Thanks a lot for your detailed response - it is very much appreciated.
> 
>> On 2 Apr 2020, at 22:30, Simon Urbanek  wrote:
>> 
>> 
>> 
>>> On 2/04/2020, at 9:15 PM, Patrick Schratz  wrote:
>>> 
>>> AFAIK most people on that list would vote hard against installing R via 
>>> homebrew for several reasons - maybe there should be a section about this 
>>> on the R dev / CRAN page to address this topic, @Simon? Otherwise this will 
>>> come up again and again.
>>> 
>> 
> 
> 
>> That main objection is that people are mixing Homebrew with CRAN and 
>> vice-versa which leads to many problems. You cannot use packages from CRAN 
>> when using Homebrew, period, and you have to be really careful if you want 
>> to mix Homebrew libraries (not anything R-related) with CRAN (it is doable 
>> if you know what you're doing).
> 
> 
> This is definitely true (and I assume, you are referring to CRAN binary 
> packages).
> 
> But I am wondering: I am always installing from the normal CRAN mirrors, and 
> my R installation (homebrew) always installs from source. I never use `type = 
> “source”`in the installation for packages. 
> 
> My question: when would I install incompatible packages (I assume, you mean 
> binary packages for Mac) from CRAN?
> 

Maybe you wouldn't but I have seen people do it.


> 
>> 
>> The fundamental issue is that package managers like Homebrew replace system 
>> libraries with their own (for new features/updates that the system libraries 
>> don't provide) which break anything that relies on the system library. Out 
>> of all the package managers Homebrew the only one that is trying to address 
>> the issue by trying to separate them, but even that has been diverging over 
>> time.
>> 
>> The second issue is that they are increasingly replacing toolchains 
>> (compilers) with their own builds, which makes everything incompatible in 
>> explosive ways (things just segfault). Making sure that a compiler toolchain 
>> is stable is actually non-trivial and many packager manager 
>> authors/maintainers have little experience with this. That used the be the 
>> primary reason to avoid them, because it was just normal that the released 
>> binaries were miscompiled and things would break all the time. Fortunately, 
>> I think that has gotten better over time.
>> 
>> If you stick only with Homebrew, then you're likely ok, but you're on your 
>> own and have to compile all packages form sources.
> 
> This is true, but I did not encounter big problems. And this is, why I 
> thought loud in suggesting to setup a (non official!) homebrew tap to install 
> the packages, similar to how it is in linux (Debian).
> 
>> Majority of our time as CRAN maintainers for the binary releases is about 
>> providing dependent libraries for packages and making sure things "just 
>> work”.
> 
> And I think everybody really appreciates this and is VErY happy about it. 
> This is essential work!
> 
>> It is doable, just a lot of work, so by using Homebrew every user has to 
>> spend that time.
> 
> Doable: definitely. lot of work: in my experience not that much more.
> 
> Overall, I definitely agree, that the official distribution should stay the 
> proper apple way. But there are circumstances, where these are delayed, or 
> problems occur after macOS upgrades, which will delay the compilation of new 
> ones (GRASS did not have Mac binaries for a long time due to this problem). 
> 

I'm not sure what you refer to, but if there are issues, please let me know. If 
you don't report issues, they won't get fixed.


> So an alternative way of installing, community supported but approved, would 
> be preferable. The r formula for homebrew has been installed in the last year 
> more that 112.000 times (https://formulae.brew.sh/formula/r) so I think there 
> is likely a rather large user base of R from homebrew. 
> 
> A first step in this direction, would be to either include homebrew in this 
> list, or create a new R-sig-hoebrew list, which could become the home of 
> these discussions.
> 

I'm not sure I'd like to go there. I would direct that to Homebrew as we have 
nothing to do with the formulae used there. However, that's not really my call.

Today another reason came up why I have an issue with Homebrew: people install 
compilers and similar tools and then use them instead of Xcode for everything 
outside of Homebrew. That is absolutely unsupported, because they have 
different runtime environments, so things break. Sometimes in subtle ways and 
things segfault at random points. The thing is, if people knew what they were 
doing, and Homebrew was only used by developers, it would be all fine - they'd 
know not to mix and match run-times. But most user don't.


> 
>> 
>> (FWIW I use Hombrew myself for tools, but not in /usr/local (I'm using 
>> /opt/brew) and I only put it on the PATH for the tools that I need, never to 
>> compile anything "native" against it.)
> 
> 

Re: [R-SIG-Mac] Homebrew [was: from Mac to LInux?]

2020-04-03 Thread Rainer M Krug
Thanks a lot for your detailed response - it is very much appreciated.

> On 2 Apr 2020, at 22:30, Simon Urbanek  wrote:
> 
> 
> 
>> On 2/04/2020, at 9:15 PM, Patrick Schratz  wrote:
>> 
>> AFAIK most people on that list would vote hard against installing R via 
>> homebrew for several reasons - maybe there should be a section about this on 
>> the R dev / CRAN page to address this topic, @Simon? Otherwise this will 
>> come up again and again.
>> 
> 


> That main objection is that people are mixing Homebrew with CRAN and 
> vice-versa which leads to many problems. You cannot use packages from CRAN 
> when using Homebrew, period, and you have to be really careful if you want to 
> mix Homebrew libraries (not anything R-related) with CRAN (it is doable if 
> you know what you're doing).


This is definitely true (and I assume, you are referring to CRAN binary 
packages).

But I am wondering: I am always installing from the normal CRAN mirrors, and my 
R installation (homebrew) always installs from source. I never use `type = 
“source”`in the installation for packages. 

My question: when would I install incompatible packages (I assume, you mean 
binary packages for Mac) from CRAN?


> 
> The fundamental issue is that package managers like Homebrew replace system 
> libraries with their own (for new features/updates that the system libraries 
> don't provide) which break anything that relies on the system library. Out of 
> all the package managers Homebrew the only one that is trying to address the 
> issue by trying to separate them, but even that has been diverging over time.
> 
> The second issue is that they are increasingly replacing toolchains 
> (compilers) with their own builds, which makes everything incompatible in 
> explosive ways (things just segfault). Making sure that a compiler toolchain 
> is stable is actually non-trivial and many packager manager 
> authors/maintainers have little experience with this. That used the be the 
> primary reason to avoid them, because it was just normal that the released 
> binaries were miscompiled and things would break all the time. Fortunately, I 
> think that has gotten better over time.
> 
> If you stick only with Homebrew, then you're likely ok, but you're on your 
> own and have to compile all packages form sources.

This is true, but I did not encounter big problems. And this is, why I thought 
loud in suggesting to setup a (non official!) homebrew tap to install the 
packages, similar to how it is in linux (Debian).

> Majority of our time as CRAN maintainers for the binary releases is about 
> providing dependent libraries for packages and making sure things "just work”.

And I think everybody really appreciates this and is VErY happy about it. This 
is essential work!

> It is doable, just a lot of work, so by using Homebrew every user has to 
> spend that time.

Doable: definitely. lot of work: in my experience not that much more.

Overall, I definitely agree, that the official distribution should stay the 
proper apple way. But there are circumstances, where these are delayed, or 
problems occur after macOS upgrades, which will delay the compilation of new 
ones (GRASS did not have Mac binaries for a long time due to this problem). 

So an alternative way of installing, community supported but approved, would be 
preferable. The r formula for homebrew has been installed in the last year more 
that 112.000 times (https://formulae.brew.sh/formula/r) so I think there is 
likely a rather large user base of R from homebrew. 

A first step in this direction, would be to either include homebrew in this 
list, or create a new R-sig-hoebrew list, which could become the home of these 
discussions.


> 
> (FWIW I use Hombrew myself for tools, but not in /usr/local (I'm using 
> /opt/brew) and I only put it on the PATH for the tools that I need, never to 
> compile anything "native" against it.)

Than you are completely in the cold and without support from homebrew… As far 
as I heard, in this case, everything is locally compiled and not using the 
binaries - correct?

Cheers, and thanks again for your very useful clarifications,

Rainer

> 
> Cheers,
> Simon
> 
> 
> 
>> Anyhow, this is also not relating to the initial topic of that thread and 
>> should probably discussed separately.
>> On 2. Apr 2020, 10:04 +0200, Rainer M Krug , wrote:
>>> I am using Homebrew on a Mac (two Macs - one at home, one at work) instead 
>>> of the official R package, and I did not have any problems after upgrades - 
>>> maybe I am lucky, maybe not as picky in defining “problem”, but my 
>>> suggestion would be to try R from homebrew to install R.
>>> 
>>> OK - no support from here - I know.
>>> 
>>> And homebrew has also binary versions. What is missing, is a hombrew R 
>>> package repository. Maybe an idea to create one?
>>> 
>>> 
>>> Cheers,
>>> 
>>> Rainer
>>> 
>>> 
 On 2 Apr 2020, at 02:37, Duncan Murdoch  wrote:
 
 On 01/04/2020 2:48 p.m., Carl Witthoft 

[R-SIG-Mac] Homebrew [was: from Mac to LInux?]

2020-04-02 Thread Simon Urbanek



> On 2/04/2020, at 9:15 PM, Patrick Schratz  wrote:
> 
> AFAIK most people on that list would vote hard against installing R via 
> homebrew for several reasons - maybe there should be a section about this on 
> the R dev / CRAN page to address this topic, @Simon? Otherwise this will come 
> up again and again.
> 

That main objection is that people are mixing Homebrew with CRAN and vice-versa 
which leads to many problems. You cannot use packages from CRAN when using 
Homebrew, period, and you have to be really careful if you want to mix Homebrew 
libraries (not anything R-related) with CRAN (it is doable if you know what 
you're doing).

The fundamental issue is that package managers like Homebrew replace system 
libraries with their own (for new features/updates that the system libraries 
don't provide) which break anything that relies on the system library. Out of 
all the package managers Homebrew the only one that is trying to address the 
issue by trying to separate them, but even that has been diverging over time.

The second issue is that they are increasingly replacing toolchains (compilers) 
with their own builds, which makes everything incompatible in explosive ways 
(things just segfault). Making sure that a compiler toolchain is stable is 
actually non-trivial and many packager manager authors/maintainers have little 
experience with this. That used the be the primary reason to avoid them, 
because it was just normal that the released binaries were miscompiled and 
things would break all the time. Fortunately, I think that has gotten better 
over time.

If you stick only with Homebrew, then you're likely ok, but you're on your own 
and have to compile all packages form sources. Majority of our time as CRAN 
maintainers for the binary releases is about providing dependent libraries for 
packages and making sure things "just work". It is doable, just a lot of work, 
so by using Homebrew every user has to spend that time.

(FWIW I use Hombrew myself for tools, but not in /usr/local (I'm using 
/opt/brew) and I only put it on the PATH for the tools that I need, never to 
compile anything "native" against it.)

Cheers,
Simon



> Anyhow, this is also not relating to the initial topic of that thread and 
> should probably discussed separately.
> On 2. Apr 2020, 10:04 +0200, Rainer M Krug , wrote:
>> I am using Homebrew on a Mac (two Macs - one at home, one at work) instead 
>> of the official R package, and I did not have any problems after upgrades - 
>> maybe I am lucky, maybe not as picky in defining “problem”, but my 
>> suggestion would be to try R from homebrew to install R.
>> 
>> OK - no support from here - I know.
>> 
>> And homebrew has also binary versions. What is missing, is a hombrew R 
>> package repository. Maybe an idea to create one?
>> 
>> 
>> Cheers,
>> 
>> Rainer
>> 
>> 
>>> On 2 Apr 2020, at 02:37, Duncan Murdoch  wrote:
>>> 
>>> On 01/04/2020 2:48 p.m., Carl Witthoft wrote:
 If I should ask over at r-sig-debian instead of here, please tell me.
 I don't wish to clog r-sig-mac with off-topic stuff.
 I've been watching the massive headaches people are dealing with trying
 to keep R fully compatible with each MacOS X upgrade, I'm wondering
 whether replacing my iMac (2009) with a new Mac really makes sense from
 an R - user point of view, as opposed to getting some inexpensive
 desktop and installing Linux. I know I can run R and RStudio under
 Linux, for example, but don't know what limitations, if any there are
 when it comes to building packages from source, getting compatible
 compilers, and so on.
 What have some of you 'power R users' discovered when/if you tried to
 build , or incorporate Bioconductor or other repository's packages under
 Linux?
>>> 
>>> If your iMac is still working, try installing Ubuntu or some other Linux on 
>>> it. I think at that age Apple is no longer providing upgrades, but I just 
>>> put Ubuntu on a 2008 iMac, and it works well. (I needed to upgrade the 
>>> memory, but that just cost $40 for 4 GB.)
>>> 
>>> So I got a $40 desktop, with a nice screen.
>>> 
>>> Duncan Murdoch
>>> 
>>> ___
>>> R-SIG-Mac mailing list
>>> R-SIG-Mac@r-project.org
>>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>> 
>> --
>> Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, 
>> UCT), Dipl. Phys. (Germany)
>> 
>> Orcid ID: -0002-7490-0066
>> 
>> Department of Evolutionary Biology and Environmental Studies
>> University of Zürich
>> Office Y34-J-74
>> Winterthurerstrasse 190
>> 8075 Zürich
>> Switzerland
>> 
>> Office: +41 (0)44 635 47 64
>> Cell: +41 (0)78 630 66 57
>> email: rainer.k...@uzh.ch
>> rai...@krugs.de
>> Skype: RMkrug
>> 
>> PGP: 0x0F52F982
>> 
>> 
>> 
>> 
>> [[alternative HTML version deleted]]
>> 
>> ___
>> R-SIG-Mac mailing list
>> R-SIG-Mac@r-project.org
>> 

Re: [R-SIG-Mac] Homebrew

2020-04-02 Thread Dr Eberhard W Lisse
Rainer,

I am definitively interested.

But, as a disclaimer, I am an elderly Gynecologist only dabbling in R
and a little in Perl :-)-O. 

el

On 02/04/2020 12:43, Rainer M Krug wrote:
> 
> 
>> On 2 Apr 2020, at 12:17, Duncan Murdoch 
>> wrote:
>>
>> On 02/04/2020 5:58 a.m., Dr Eberhard W Lisse wrote:
>>> New thread :-)-O
>>> I am wondering if I should not try to figure out how automate this.
>>> Is there a way of (only) listing all user installed (additional)
>>> packages, ie not the ones that come with R?
> 
> I had something similar in mind - here is my repo which collects ides
> (no code yet) https://github.com/rkrug/install
> 
> If you are interested, we could get this going.
> 
> If I understand correctly, this would be very useful in many cases.
> 
>>
>> Look at the "Priority" column in installed.packages().  "base" is
>> part of R, "recommended" is normally distributed with R.
>> "recommended" packages can be updated after R is installed, "base"
>> packages can't.
> 
> That is a good idea.  We should take this forward.
> 
>>
>> If you just copy all the packages to the new library that aren't
>> already there, and run update.packages(checkBuilt = TRUE) R will
>> re-install everything that was originally installed under an earlier
>> version.
> 
> 
> Cheers,
> 
> Rainer
[...]

-- 
Dr. Eberhard W. Lisse   \ /   Obstetrician & Gynaecologist 
e...@lisse.na / *  |  Telephone: +264 81 124 6733 (cell)
PO Box 8421  \  / If this email is signed with GPG/PGP
Bachbrecht 10007, Namibia ;/ Section 20 of Act No. 4 of 2019 may apply

___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac


Re: [R-SIG-Mac] Homebrew

2020-04-02 Thread Dr Eberhard W Lisse
Argument for homebrew:

brew upgrade

which will figure out what needs to be upgraded so I don't have 
manually keep track of it.


BTW, it usually pulls the binary, and these have worked without any 
issues for many years, the last time something went wrong on the 
Download and it pulled the source. I don't care either way.

Packages must be installed from source, but not as source. R will look 
for the package on CRAN like any other and usually takes the binary, 
sometimes asking whether it should take a (newer) source )of the 
package)

The first run of (re-)installing additional packages does indeed take 
some time, but it doesn't happen often.

The point is that there is a channel for issues with homebrew packages 
but few people (especially when desperate) will take the time :-)-O

greetings, el

 02/04/2020 13:09, Rainer M Krug wrote:
> 
> 
>> On 2 Apr 2020, at 12:56, Hervé Pagès  wrote:
>>
>> Just for a minute let's ignore the fact that installing R via
>> Homebrew is not considered a good option by the competent authorities
>> (which sounds like a good enough reason to stay away from it).  I'm
>> still wondering: what's the benefit vs installing the official CRAN
>> binary?  Just curious.
> 
> Arguments against homebrew:
> 
> Not an official response, but in the past, homebrew was compiling
> everything on the local machine.  This is not the case anymore, and
> the default installation in homebrew, installs a binary.
> 
> All packages need to be installed from source.  This takes time, but I
> had no problems with any of the packages I use.
> 
> Just some tidbits from previous discussions.
> 
> But I would like to also hear the official reason (no resources would
> be a good enough justification as well).
> 
> Arguments for homebrew:
> 
> it is more Linux like, in the way that you have more control over the
> tools used.  e.g. when still using the official R installation, I
> regularly used different versions of GDAL in R, GRASS, …, which can
> cause inconsistencies.
> 
> The installation is done without requiring root privileges, which is a
> big advantage (as I see it).
> 
> 
> 
> Cheers,
> 
> Rainer
[...]

-- 
Dr. Eberhard W. Lisse   \ /   Obstetrician & Gynaecologist 
e...@lisse.na / *  |  Telephone: +264 81 124 6733 (cell)
PO Box 8421  \  / If this email is signed with GPG/PGP
Bachbrecht 10007, Namibia ;/ Section 20 of Act No. 4 of 2019 may apply

___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac


Re: [R-SIG-Mac] Homebrew

2020-04-02 Thread Rainer M Krug



> On 2 Apr 2020, at 12:56, Hervé Pagès  wrote:
> 
> Just for a minute let's ignore the fact that installing R via Homebrew is not 
> considered a good option by the competent authorities (which sounds like a 
> good enough reason to stay away from it). I'm still wondering: what's the 
> benefit vs installing the official CRAN binary? Just curious.

Arguments against homebrew:

Not an official response, but in the past, homebrew was compiling everything on 
the local machine. This is not the case anymore, and the default installation 
in homebrew, installs a binary. 

All packages need to be installed from source. This takes time, but I had no 
problems with any of the packages I use.

Just some tidbits from previous discussions.

But I would like to also hear the official reason (no resources would be a good 
enough justification as well).

Arguments for homebrew: 

it is more Linux like, in the way that you have more control over the tools 
used. e.g. when still using the official R installation, I regularly used 
different versions of GDAL in R, GRASS, …, which can cause inconsistencies.

The installation is done without requiring root privileges, which is a big 
advantage (as I see it).



Cheers,

Rainer


> 
> Thanks,
> H.
> 
> On 4/2/20 03:43, Rainer M Krug wrote:
>>> On 2 Apr 2020, at 12:17, Duncan Murdoch  wrote:
>>> 
>>> On 02/04/2020 5:58 a.m., Dr Eberhard W Lisse wrote:
 New thread :-)-O
 I am wondering if I should not try to figure out how automate this.
 Is there a way of (only) listing all user installed (additional)
 packages, ie not the ones that come with R?
>> I had something similar in mind - here is my repo which collects ides (no 
>> code yet) 
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_rkrug_install=DwIFaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=uDuycJflTWje5wqLzrbP7zBZojiWq6DmyxGuwakypr0=ZUWEqptXXn0kw7PX-ToEnYb7DtfXGUcOn5PzyQVfVG8=
>> If you are interested, we could get this going.
>> If I understand correctly, this would be very useful in many cases.
>>> 
>>> Look at the "Priority" column in installed.packages().  "base" is part of 
>>> R, "recommended" is normally distributed with R. "recommended" packages can 
>>> be updated after R is installed, "base" packages can't.
>> That is a good idea. We should take this forward.
>>> 
>>> If you just copy all the packages to the new library that aren't already 
>>> there, and run update.packages(checkBuilt = TRUE) R will re-install 
>>> everything that was originally installed under an earlier version.
>> Cheers,
>> Rainer
>>> 
>>> Duncan Murdoch
 I could then construct the below file automagically, and if I was
 really bothered and bored find out how to make Homebrew pre/post
 install scripts to automate this :-)-O
 And, for the record, other than that, I can only recall one serious
 issue, when the openblas library got lost recently which was however
 fixed quite quickly.
 greetings, el
 On 02/04/2020 10:17, Dr Eberhard W Lisse wrote:
> 
> I do same, including Rstudio (Cask).
> 
> Once in a while after major updates I need to reinstall all my extra
> packages, so I have written me a little script along the lines of
> 
>   #!/usr/local/bin/Rscript
>   local({
>   r <- getOption("repos")
>   r["CRAN"] <- 
> "https://urldefense.proofpoint.com/v2/url?u=https-3A__cloud.r-2Dproject.org_=DwIFaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=uDuycJflTWje5wqLzrbP7zBZojiWq6DmyxGuwakypr0=rnzs7MN3dX-WT08dEbSoFz0AVBgX-xNNlW9keQhr0jg=
>  "
>   options(repos = r)
>   })
>   install.packages(c(
>   "RMariaDB", "rstudioapi"
>   ))
> 
> made it 0755 and can run it from the command line. Put it in my
> handbook so I don't forget and never looked back.
> 
> 
> greetings, el
> 
> On 02/04/2020 10:03 am, Rainer M Krug wrote:
>> I am using Homebrew on a Mac (two Macs - one at home, one at work)
>> instead of the official R package, and I did not have any problems
>> after upgrades - maybe I am lucky, maybe not as picky in defining
>> “problem”, but my suggestion would be to try R from homebrew to
>> install R.
>> 
>> OK - no support from here - I know.
>> 
>> And homebrew has also binary versions.  What is missing, is a hombrew
>> R package repository.  Maybe an idea to create one?
>> 
>> 
>> Cheers,
>> 
>> Rainer
 
>>> 
>>> ___
>>> R-SIG-Mac mailing list
>>> R-SIG-Mac@r-project.org
>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_r-2Dsig-2Dmac=DwIFaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=uDuycJflTWje5wqLzrbP7zBZojiWq6DmyxGuwakypr0=-Kazp7RDPhXbnKvMu3vyOfRSE7ZQBHDCH9Vy6MeGssA=
>> --
>> Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc 

Re: [R-SIG-Mac] Homebrew

2020-04-02 Thread Hervé Pagès
Just for a minute let's ignore the fact that installing R via Homebrew 
is not considered a good option by the competent authorities (which 
sounds like a good enough reason to stay away from it). I'm still 
wondering: what's the benefit vs installing the official CRAN binary? 
Just curious.


Thanks,
H.

On 4/2/20 03:43, Rainer M Krug wrote:




On 2 Apr 2020, at 12:17, Duncan Murdoch  wrote:

On 02/04/2020 5:58 a.m., Dr Eberhard W Lisse wrote:

New thread :-)-O
I am wondering if I should not try to figure out how automate this.
Is there a way of (only) listing all user installed (additional)
packages, ie not the ones that come with R?


I had something similar in mind - here is my repo which collects ides (no code yet) 
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_rkrug_install=DwIFaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=uDuycJflTWje5wqLzrbP7zBZojiWq6DmyxGuwakypr0=ZUWEqptXXn0kw7PX-ToEnYb7DtfXGUcOn5PzyQVfVG8=

If you are interested, we could get this going.

If I understand correctly, this would be very useful in many cases.



Look at the "Priority" column in installed.packages().  "base" is part of R, "recommended" is 
normally distributed with R. "recommended" packages can be updated after R is installed, "base" packages 
can't.


That is a good idea. We should take this forward.



If you just copy all the packages to the new library that aren't already there, 
and run update.packages(checkBuilt = TRUE) R will re-install everything that 
was originally installed under an earlier version.



Cheers,

Rainer




Duncan Murdoch

I could then construct the below file automagically, and if I was
really bothered and bored find out how to make Homebrew pre/post
install scripts to automate this :-)-O
And, for the record, other than that, I can only recall one serious
issue, when the openblas library got lost recently which was however
fixed quite quickly.
greetings, el
On 02/04/2020 10:17, Dr Eberhard W Lisse wrote:


I do same, including Rstudio (Cask).

Once in a while after major updates I need to reinstall all my extra
packages, so I have written me a little script along the lines of

#!/usr/local/bin/Rscript
local({
r <- getOption("repos")
r["CRAN"] <- 
"https://urldefense.proofpoint.com/v2/url?u=https-3A__cloud.r-2Dproject.org_=DwIFaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=uDuycJflTWje5wqLzrbP7zBZojiWq6DmyxGuwakypr0=rnzs7MN3dX-WT08dEbSoFz0AVBgX-xNNlW9keQhr0jg=
 "
options(repos = r)
})
install.packages(c(
"RMariaDB", "rstudioapi"
))

made it 0755 and can run it from the command line. Put it in my
handbook so I don't forget and never looked back.


greetings, el

On 02/04/2020 10:03 am, Rainer M Krug wrote:

I am using Homebrew on a Mac (two Macs - one at home, one at work)
instead of the official R package, and I did not have any problems
after upgrades - maybe I am lucky, maybe not as picky in defining
“problem”, but my suggestion would be to try R from homebrew to
install R.

OK - no support from here - I know.

And homebrew has also binary versions.  What is missing, is a hombrew
R package repository.  Maybe an idea to create one?


Cheers,

Rainer




___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_r-2Dsig-2Dmac=DwIFaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=uDuycJflTWje5wqLzrbP7zBZojiWq6DmyxGuwakypr0=-Kazp7RDPhXbnKvMu3vyOfRSE7ZQBHDCH9Vy6MeGssA=


--
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, 
UCT), Dipl. Phys. (Germany)

Orcid ID: -0002-7490-0066

Department of Evolutionary Biology and Environmental Studies
University of Zürich
Office Y34-J-74
Winterthurerstrasse 190
8075 Zürich
Switzerland

Office: +41 (0)44 635 47 64
Cell:   +41 (0)78 630 66 57
email:  rainer.k...@uzh.ch
rai...@krugs.de
Skype: RMkrug

PGP: 0x0F52F982




[[alternative HTML version deleted]]

___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__stat.ethz.ch_mailman_listinfo_r-2Dsig-2Dmac=DwIFaQ=eRAMFD45gAfqt84VtBcfhQ=BK7q3XeAvimeWdGbWY_wJYbW0WYiZvSXAJJKaaPhzWA=uDuycJflTWje5wqLzrbP7zBZojiWq6DmyxGuwakypr0=-Kazp7RDPhXbnKvMu3vyOfRSE7ZQBHDCH9Vy6MeGssA=



--
Hervé Pagès

Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024

E-mail: hpa...@fredhutch.org
Phone:  (206) 667-5791
Fax:(206) 667-1319

___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac


Re: [R-SIG-Mac] Homebrew

2020-04-02 Thread Rainer M Krug



> On 2 Apr 2020, at 12:17, Duncan Murdoch  wrote:
> 
> On 02/04/2020 5:58 a.m., Dr Eberhard W Lisse wrote:
>> New thread :-)-O
>> I am wondering if I should not try to figure out how automate this.
>> Is there a way of (only) listing all user installed (additional)
>> packages, ie not the ones that come with R?

I had something similar in mind - here is my repo which collects ides (no code 
yet) https://github.com/rkrug/install

If you are interested, we could get this going.

If I understand correctly, this would be very useful in many cases.

> 
> Look at the "Priority" column in installed.packages().  "base" is part of R, 
> "recommended" is normally distributed with R. "recommended" packages can be 
> updated after R is installed, "base" packages can't.

That is a good idea. We should take this forward.

> 
> If you just copy all the packages to the new library that aren't already 
> there, and run update.packages(checkBuilt = TRUE) R will re-install 
> everything that was originally installed under an earlier version.


Cheers,

Rainer


> 
> Duncan Murdoch
>> I could then construct the below file automagically, and if I was
>> really bothered and bored find out how to make Homebrew pre/post
>> install scripts to automate this :-)-O
>> And, for the record, other than that, I can only recall one serious
>> issue, when the openblas library got lost recently which was however
>> fixed quite quickly.
>> greetings, el
>> On 02/04/2020 10:17, Dr Eberhard W Lisse wrote:
>>> 
>>> I do same, including Rstudio (Cask).
>>> 
>>> Once in a while after major updates I need to reinstall all my extra
>>> packages, so I have written me a little script along the lines of
>>> 
>>> #!/usr/local/bin/Rscript
>>> local({
>>> r <- getOption("repos")
>>> r["CRAN"] <- "https://cloud.r-project.org/;
>>> options(repos = r)
>>> })
>>> install.packages(c(
>>> "RMariaDB", "rstudioapi"
>>> ))
>>> 
>>> made it 0755 and can run it from the command line. Put it in my
>>> handbook so I don't forget and never looked back.
>>> 
>>> 
>>> greetings, el
>>> 
>>> On 02/04/2020 10:03 am, Rainer M Krug wrote:
 I am using Homebrew on a Mac (two Macs - one at home, one at work)
 instead of the official R package, and I did not have any problems
 after upgrades - maybe I am lucky, maybe not as picky in defining
 “problem”, but my suggestion would be to try R from homebrew to
 install R.
 
 OK - no support from here - I know.
 
 And homebrew has also binary versions.  What is missing, is a hombrew
 R package repository.  Maybe an idea to create one?
 
 
 Cheers,
 
 Rainer
>> 
> 
> ___
> R-SIG-Mac mailing list
> R-SIG-Mac@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-mac

--
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, 
UCT), Dipl. Phys. (Germany)

Orcid ID: -0002-7490-0066

Department of Evolutionary Biology and Environmental Studies
University of Zürich
Office Y34-J-74
Winterthurerstrasse 190
8075 Zürich
Switzerland

Office: +41 (0)44 635 47 64
Cell:   +41 (0)78 630 66 57
email:  rainer.k...@uzh.ch
rai...@krugs.de
Skype: RMkrug

PGP: 0x0F52F982




[[alternative HTML version deleted]]

___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac


Re: [R-SIG-Mac] Homebrew

2020-04-02 Thread Duncan Murdoch

On 02/04/2020 5:58 a.m., Dr Eberhard W Lisse wrote:

New thread :-)-O

I am wondering if I should not try to figure out how automate this.

Is there a way of (only) listing all user installed (additional)
packages, ie not the ones that come with R?


Look at the "Priority" column in installed.packages().  "base" is part 
of R, "recommended" is normally distributed with R. "recommended" 
packages can be updated after R is installed, "base" packages can't.


If you just copy all the packages to the new library that aren't already 
there, and run update.packages(checkBuilt = TRUE) R will re-install 
everything that was originally installed under an earlier version.


Duncan Murdoch


I could then construct the below file automagically, and if I was
really bothered and bored find out how to make Homebrew pre/post
install scripts to automate this :-)-O

And, for the record, other than that, I can only recall one serious
issue, when the openblas library got lost recently which was however
fixed quite quickly.


greetings, el

On 02/04/2020 10:17, Dr Eberhard W Lisse wrote:


I do same, including Rstudio (Cask).

Once in a while after major updates I need to reinstall all my extra
packages, so I have written me a little script along the lines of

#!/usr/local/bin/Rscript
local({
r <- getOption("repos")
r["CRAN"] <- "https://cloud.r-project.org/;
options(repos = r)
})
install.packages(c(
"RMariaDB", "rstudioapi"
))

made it 0755 and can run it from the command line. Put it in my
handbook so I don't forget and never looked back.


greetings, el

On 02/04/2020 10:03 am, Rainer M Krug wrote:

I am using Homebrew on a Mac (two Macs - one at home, one at work)
instead of the official R package, and I did not have any problems
after upgrades - maybe I am lucky, maybe not as picky in defining
“problem”, but my suggestion would be to try R from homebrew to
install R.

OK - no support from here - I know.

And homebrew has also binary versions.  What is missing, is a hombrew
R package repository.  Maybe an idea to create one?


Cheers,

Rainer




___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac


[R-SIG-Mac] Homebrew

2020-04-02 Thread Dr Eberhard W Lisse
New thread :-)-O

I am wondering if I should not try to figure out how automate this.

Is there a way of (only) listing all user installed (additional) 
packages, ie not the ones that come with R?

I could then construct the below file automagically, and if I was 
really bothered and bored find out how to make Homebrew pre/post 
install scripts to automate this :-)-O

And, for the record, other than that, I can only recall one serious 
issue, when the openblas library got lost recently which was however 
fixed quite quickly. 


greetings, el

On 02/04/2020 10:17, Dr Eberhard W Lisse wrote:
> 
> I do same, including Rstudio (Cask).
> 
> Once in a while after major updates I need to reinstall all my extra
> packages, so I have written me a little script along the lines of
> 
>   #!/usr/local/bin/Rscript
>   local({
>   r <- getOption("repos")
>   r["CRAN"] <- "https://cloud.r-project.org/;
>   options(repos = r)
>   })
>   install.packages(c(
>   "RMariaDB", "rstudioapi"
>   ))
> 
> made it 0755 and can run it from the command line. Put it in my
> handbook so I don't forget and never looked back.
> 
> 
> greetings, el
> 
> On 02/04/2020 10:03 am, Rainer M Krug wrote:
>> I am using Homebrew on a Mac (two Macs - one at home, one at work)
>> instead of the official R package, and I did not have any problems
>> after upgrades - maybe I am lucky, maybe not as picky in defining
>> “problem”, but my suggestion would be to try R from homebrew to
>> install R.
>>
>> OK - no support from here - I know.
>>
>> And homebrew has also binary versions.  What is missing, is a hombrew
>> R package repository.  Maybe an idea to create one?
>>
>>
>> Cheers,
>>
>> Rainer

-- 
Dr. Eberhard W. Lisse   \ /   Obstetrician & Gynaecologist 
e...@lisse.na / *  |  Telephone: +264 81 124 6733 (cell)
PO Box 8421  \  / If this email is signed with GPG/PGP
Bachbrecht 10007, Namibia ;/ Section 20 of Act No. 4 of 2019 may apply

___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac


Re: [R-SIG-Mac] homebrew install High Sierra - tcl-tk support

2017-10-18 Thread David Winsemius

> On Oct 18, 2017, at 12:09 AM, Rainer Krug  wrote:
> 
> 
> 
>> On 17 Oct 2017, at 17:18, David Winsemius  wrote:
>> 
>>> 
>>> On Oct 17, 2017, at 7:56 AM, David Winsemius  wrote:
>>> 
 
 On Oct 17, 2017, at 1:43 AM, Rainer Krug  wrote:
 
 Hi
 
 One question about home-brew installation:
 
 After upgrading to High Sierra (and update to R 3.4.2), I don’t get tcl-tk 
 support in R.
 
 I get the following error:
 
> library(tcltk)
Error: package or namespace load failed for ‘tcltk’:
 .onLoad failed in loadNamespace() for 'tcltk', details:
  call: fun(libname, pkgname)
  error: Tcl/Tk support is not available on this system
In addition: Warning message:
S3 methods ‘as.character.tclObj’, ‘as.character.tclVar’, 
 ‘as.double.tclObj’, ‘as.integer.tclObj’, ‘as.logical.tclObj’, 
 ‘as.raw.tclObj’, ‘print.tclObj’, ‘[[.tclArray’, ‘[[<-.tclArray’, 
 ‘$.tclArray’, ‘$<-.tclArray’, ‘names.tclArray’, ‘names<-.tclArray’, 
 ‘length.tclArray’, ‘length<-.tclArray’, ‘tclObj.tclVar’, 
 ‘tclObj<-.tclVar’, ‘tclvalue.default’, ‘tclvalue.tclObj’, 
 ‘tclvalue.tclVar’, ‘tclvalue<-.default’, ‘tclvalue<-.tclVar’, 
 ‘close.tkProgressBar’ were declared in NAMESPACE but not found
 
 
 Is this a problem on my side, or is there a problem with R & homebrew & 
 High Sierra & tcl-tk?
>>> 
>>> Caveat. I know almost nothing about homebrew other than its function and 
>>> the fact that users of it often have problems with installing R properly. 
>>> The CRAN page for the Mac R 3.4.2 fork says:
>>> 
>>> ---begin---
>>> Contains R 3.4.2 framework, R.app GUI 1.70 in 64-bit for Intel Macs, Tcl/Tk 
>>> 8.6.6 X11 libraries and Texinfo 5.2. The latter two components are optional 
>>> and can be ommitted when choosing "custom install", they are only needed if 
>>> you want to use the tcltk R package or build package documentation from 
>>> sources.
>> 
>> I intended that the next sentence be here (and wan't intending two copies of 
>> those sentences):
>> 
>> Note: the use of X11 (including tcltk) requires XQuartz to be installed 
>> since it is no longer part of OS X. Always re-install XQuartz when upgrading 
>> your OS X to a new major version.
>> 
>>> -end
>>> 
>>> So it makes me wonder if you need to add the correct versions of the 
>>> underlying system packages in a manner that your homebrew installation can 
>>> find them. (the 3.3 fork uses a differnt version of Tcl/Tk.) 
> 
> Thanks David - but no luck. Still the same problems - even after installing 
> quartz again.


I was not sure whether the  list of items included: "Intel Macs, Tcl/Tk 8.6.6 
X11 libraries and Texinfo 5.2" was missing a comma between 8.6.6 and X11 
libraries or conversely  that TCL/Tk 8.6.6 was supposed to indicate a 
particular version of Quartz. Looking at the various webpages for those two 
packages, I don't see any change in XQuartz' version numbers whereas there has 
been quite a bit of updating of TCL/Tk.

-- 
David.
___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac

Re: [R-SIG-Mac] homebrew install High Sierra - tcl-tk support

2017-10-18 Thread Rainer Krug


> On 17 Oct 2017, at 17:18, David Winsemius  wrote:
> 
>> 
>> On Oct 17, 2017, at 7:56 AM, David Winsemius  wrote:
>> 
>>> 
>>> On Oct 17, 2017, at 1:43 AM, Rainer Krug  wrote:
>>> 
>>> Hi
>>> 
>>> One question about home-brew installation:
>>> 
>>> After upgrading to High Sierra (and update to R 3.4.2), I don’t get tcl-tk 
>>> support in R.
>>> 
>>> I get the following error:
>>> 
>>> > library(tcltk)
>>> Error: package or namespace load failed for ‘tcltk’:
>>>  .onLoad failed in loadNamespace() for 'tcltk', details:
>>>   call: fun(libname, pkgname)
>>>   error: Tcl/Tk support is not available on this system
>>> In addition: Warning message:
>>> S3 methods ‘as.character.tclObj’, ‘as.character.tclVar’, 
>>> ‘as.double.tclObj’, ‘as.integer.tclObj’, ‘as.logical.tclObj’, 
>>> ‘as.raw.tclObj’, ‘print.tclObj’, ‘[[.tclArray’, ‘[[<-.tclArray’, 
>>> ‘$.tclArray’, ‘$<-.tclArray’, ‘names.tclArray’, ‘names<-.tclArray’, 
>>> ‘length.tclArray’, ‘length<-.tclArray’, ‘tclObj.tclVar’, ‘tclObj<-.tclVar’, 
>>> ‘tclvalue.default’, ‘tclvalue.tclObj’, ‘tclvalue.tclVar’, 
>>> ‘tclvalue<-.default’, ‘tclvalue<-.tclVar’, ‘close.tkProgressBar’ were 
>>> declared in NAMESPACE but not found
>>> 
>>> 
>>> Is this a problem on my side, or is there a problem with R & homebrew & 
>>> High Sierra & tcl-tk?
>> 
>> Caveat. I know almost nothing about homebrew other than its function and the 
>> fact that users of it often have problems with installing R properly. The 
>> CRAN page for the Mac R 3.4.2 fork says:
>> 
>> ---begin---
>> Contains R 3.4.2 framework, R.app GUI 1.70 in 64-bit for Intel Macs, Tcl/Tk 
>> 8.6.6 X11 libraries and Texinfo 5.2. The latter two components are optional 
>> and can be ommitted when choosing "custom install", they are only needed if 
>> you want to use the tcltk R package or build package documentation from 
>> sources.
> 
> I intended that the next sentence be here (and wan't intending two copies of 
> those sentences):
> 
> Note: the use of X11 (including tcltk) requires XQuartz to be installed since 
> it is no longer part of OS X. Always re-install XQuartz when upgrading your 
> OS X to a new major version.
> 
>> -end
>> 
>> So it makes me wonder if you need to add the correct versions of the 
>> underlying system packages in a manner that your homebrew installation can 
>> find them. (the 3.3 fork uses a differnt version of Tcl/Tk.)

Thanks David - but no luck. Still the same problems - even after installing 
quartz again.

Cheers,

Rainer

>> 
>> --
>> David.
>> 
>>> 
>>> Thanks,
>>> 
>>> Rainer
>>> 
>>> 
>>> --
>>> Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, 
>>> UCT), Dipl. Phys. (Germany)
>>> 
>>> University of Zürich
>>> 
>>> Cell:   +41 (0)78 630 66 57
>>> email:  rai...@krugs.de
>>> Skype:  RMkrug
>>> 
>>> PGP: 0x0F52F982
>>> 
>>> 
>>> 
>>> ___
>>> R-SIG-Mac mailing list
>>> R-SIG-Mac@r-project.org
>>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>> 
>> David Winsemius
>> Alameda, CA, USA
>> 
>> 'Any technology distinguishable from magic is insufficiently advanced.'   
>> -Gehm's Corollary to Clarke's Third Law
>> 
>> ___
>> R-SIG-Mac mailing list
>> R-SIG-Mac@r-project.org 
>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac 
>> 
> 
> David Winsemius
> Alameda, CA, USA
> 
> 'Any technology distinguishable from magic is insufficiently advanced.'   
> -Gehm's Corollary to Clarke's Third Law
> 
> ___
> R-SIG-Mac mailing list
> R-SIG-Mac@r-project.org 
> https://stat.ethz.ch/mailman/listinfo/r-sig-mac 
> 
--
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, 
UCT), Dipl. Phys. (Germany)

University of Zürich

Cell:   +41 (0)78 630 66 57
email:  rai...@krugs.de
Skype:  RMkrug

PGP: 0x0F52F982





signature.asc
Description: Message signed with OpenPGP
___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac

Re: [R-SIG-Mac] homebrew install High Sierra - tcl-tk support

2017-10-17 Thread David Winsemius

> On Oct 17, 2017, at 1:43 AM, Rainer Krug  wrote:
> 
> Hi
> 
> One question about home-brew installation:
> 
> After upgrading to High Sierra (and update to R 3.4.2), I don’t get tcl-tk 
> support in R.
> 
> I get the following error:
> 
>   > library(tcltk)
>   Error: package or namespace load failed for ‘tcltk’:
>.onLoad failed in loadNamespace() for 'tcltk', details:
> call: fun(libname, pkgname)
> error: Tcl/Tk support is not available on this system
>   In addition: Warning message:
>   S3 methods ‘as.character.tclObj’, ‘as.character.tclVar’, 
> ‘as.double.tclObj’, ‘as.integer.tclObj’, ‘as.logical.tclObj’, 
> ‘as.raw.tclObj’, ‘print.tclObj’, ‘[[.tclArray’, ‘[[<-.tclArray’, 
> ‘$.tclArray’, ‘$<-.tclArray’, ‘names.tclArray’, ‘names<-.tclArray’, 
> ‘length.tclArray’, ‘length<-.tclArray’, ‘tclObj.tclVar’, ‘tclObj<-.tclVar’, 
> ‘tclvalue.default’, ‘tclvalue.tclObj’, ‘tclvalue.tclVar’, 
> ‘tclvalue<-.default’, ‘tclvalue<-.tclVar’, ‘close.tkProgressBar’ were 
> declared in NAMESPACE but not found
> 
> 
> Is this a problem on my side, or is there a problem with R & homebrew & High 
> Sierra & tcl-tk?

Caveat. I know almost nothing about homebrew other than its function and the 
fact that users of it often have problems with installing R properly. The CRAN 
page for the Mac R 3.4.2 fork says:

---begin---
Contains R 3.4.2 framework, R.app GUI 1.70 in 64-bit for Intel Macs, Tcl/Tk 
8.6.6 X11 libraries and Texinfo 5.2. The latter two components are optional and 
can be ommitted when choosing "custom install", they are only needed if you 
want to use the tcltk R package or build package documentation from sources.

Contains R 3.4.2 framework, R.app GUI 1.70 in 64-bit for Intel Macs, Tcl/Tk 
8.6.6 X11 libraries and Texinfo 5.2. The latter two components are optional and 
can be ommitted when choosing "custom install", they are only needed if you 
want to use the tcltk R package or build package documentation from sources.
-end

So it makes me wonder if you need to add the correct versions of the underlying 
system packages in a manner that your homebrew installation can find them. (the 
3.3 fork uses a differnt version of Tcl/Tk.) 

-- 
David.

> 
> Thanks,
> 
> Rainer
> 
> 
> --
> Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, 
> UCT), Dipl. Phys. (Germany)
> 
> University of Zürich
> 
> Cell:   +41 (0)78 630 66 57
> email:  rai...@krugs.de
> Skype:  RMkrug
> 
> PGP: 0x0F52F982
> 
> 
> 
> ___
> R-SIG-Mac mailing list
> R-SIG-Mac@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-mac

David Winsemius
Alameda, CA, USA

'Any technology distinguishable from magic is insufficiently advanced.'   
-Gehm's Corollary to Clarke's Third Law

___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac

[R-SIG-Mac] homebrew install High Sierra - tcl-tk support

2017-10-17 Thread Rainer Krug
Hi

One question about home-brew installation:

After upgrading to High Sierra (and update to R 3.4.2), I don’t get tcl-tk 
support in R.

I get the following error:

> library(tcltk)
Error: package or namespace load failed for ‘tcltk’:
 .onLoad failed in loadNamespace() for 'tcltk', details:
  call: fun(libname, pkgname)
  error: Tcl/Tk support is not available on this system
In addition: Warning message:
S3 methods ‘as.character.tclObj’, ‘as.character.tclVar’, 
‘as.double.tclObj’, ‘as.integer.tclObj’, ‘as.logical.tclObj’, ‘as.raw.tclObj’, 
‘print.tclObj’, ‘[[.tclArray’, ‘[[<-.tclArray’, ‘$.tclArray’, ‘$<-.tclArray’, 
‘names.tclArray’, ‘names<-.tclArray’, ‘length.tclArray’, ‘length<-.tclArray’, 
‘tclObj.tclVar’, ‘tclObj<-.tclVar’, ‘tclvalue.default’, ‘tclvalue.tclObj’, 
‘tclvalue.tclVar’, ‘tclvalue<-.default’, ‘tclvalue<-.tclVar’, 
‘close.tkProgressBar’ were declared in NAMESPACE but not found
>


Is this a problem on my side, or is there a problem with R & homebrew & High 
Sierra & tcl-tk?

Thanks,

Rainer


--
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, 
UCT), Dipl. Phys. (Germany)

University of Zürich

Cell:   +41 (0)78 630 66 57
email:  rai...@krugs.de
Skype:  RMkrug

PGP: 0x0F52F982





signature.asc
Description: Message signed with OpenPGP
___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac

[R-SIG-Mac] Homebrew R, brewed gettext and --with-libintl-prefix

2014-02-24 Thread Evan McClain
Hi list,

This is probably the wrong place to post this, but I've hit an issue with the
homebrewed version of R. See:
https://github.com/Homebrew/homebrew-science/pull/676

It looks like the --with-libintl-prefix configure option is not adding the
proper include directory when installing packages. Is explicitly exporting
CPPFLAGS the proper way to get packages to use a non-standard gettext
installation or should --with-libintl-prefix do this automatically?

The alternative of using the included gettext also works, but homebrew already
packages gettext:
https://github.com/Homebrew/homebrew-science/pull/674

Any comments/suggestsions either on the list or on github would be appreciated.

Thanks
-- 
Evan McClain
/* No Comment */


pgpCsVt1d_7ON.pgp
Description: PGP signature
___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac


Re: [R-SIG-Mac] homebrew r mac osx lion?

2012-11-02 Thread Stefan Drees

Am 01.11.12 17:57, schrieb Frazier, Tyler James:

... is there a homebrew for r?  maybe its just brew install r
...


what about brew info r before asking the list?

and then, yes brew install r

All the best,
Stefan.





smime.p7s
Description: S/MIME Kryptografische Unterschrift
___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac


[R-SIG-Mac] homebrew r mac osx lion?

2012-11-01 Thread Frazier, Tyler James
Hi, is there a homebrew for r?  maybe its just brew install r -- thanks, Ty

-
Tyler Frazier
Department of Transportation Planning and Telematics
Technical University Berlin
http://www.vsp.tu-berlin.de/





[[alternative HTML version deleted]]

___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac