Re: [R-SIG-Mac] R 4 dumping tons of console messages in Big Sur

[Simon Urbanek]

Tim,

that is likely intentional on Apple side - see R for Mac FAQ if you don't want 
to see that Apple debugging output.

Cheers,
Simon



> On 25/06/2020, at 2:49 AM, Timothy Bates  wrote:
> 
> R in pretty-much unusable in Big Sur (OSX beta) - it's generating many more
> than ever warning messages to the console, such that a simple calculation
> fills the page with warnings... e.g:
> 
> 
> (174-19)/15
> [1] 10.3
> 2020-06-24 15:45:31.472 R[4178:38668] 
> is drawing everything
> 2020-06-24 15:45:31.472 R[4178:38668] Drawing rect: {{9, 60}, {278, 323}}:
> 
> 2020-06-24 15:45:31.472 R[4178:38668] drawRow: 0, clip: {{0, 0}, {278,
> 323}} - 
> 2020-06-24 15:45:31.472 R[4178:38668]columnsToDraw:  0x63dd84b0>[number of indexes: 1 (in 1 ranges), indexes: (0)]
> 2020-06-24 15:45:31.472 R[4178:38668] Really drawing cell at row: 0 col: 0
> 2020-06-24 15:45:31.472 R[4178:38668] drawRow: 1, clip: {{0, 0}, {278,
> 323}} - 
> 2020-06-24 15:45:31.472 R[4178:38668]columnsToDraw:  0x63dd8540>[number of indexes: 1 (in 1 ranges), indexes: (0)]
> 2020-06-24 15:45:31.472 R[4178:38668] Really drawing cell at row: 1 col: 0
> 2020-06-24 15:45:31.472 R[4178:38668] drawRow: 2, clip: {{0, 0}, {278,
> 323}} - 
> 2020-06-24 15:45:31.472 R[4178:38668]columnsToDraw:  0x63dd84b0>[number of indexes: 1 (in 1 ranges), indexes: (0)]
> 2020-06-24 15:45:31.472 R[4178:38668] Really drawing cell at row: 2 col: 0
> 2020-06-24 15:45:31.472 R[4178:38668] drawRow: 3, clip: {{0, 0}, {278,
> 323}} - 
> 2020-06-24 15:45:31.472 R[4178:38668]columnsToDraw:  0x63dd8540>[number of indexes: 1 (in 1 ranges), indexes: (0)]
> 2020-06-24 15:45:31.472 R[4178:38668] Really drawing cell at row: 3 col: 0
> 2020-06-24 15:45:31.472 R[4178:38668] drawRow: 4, clip: {{0, 0}, {278,
> 323}} - 
> 2020-06-24 15:45:31.472 R[4178:38668]columnsToDraw:  0x63dd84b0>[number of indexes: 1 (in 1 ranges), indexes: (0)]
> 2020-06-24 15:45:31.472 R[4178:38668] Really drawing cell at row: 4 col: 0
> 2020-06-24 15:45:31.472 R[4178:38668] drawRow: 5, clip: {{0, 0}, {278,
> 323}} - 
> 2020-06-24 15:45:31.472 R[4178:38668]columnsToDraw:  0x63dd8540>[number of indexes: 1 (in 1 ranges), indexes: (0)]
> 2020-06-24 15:45:31.472 R[4178:38668] Really drawing cell at row: 5 col: 0
> 
>   [[alternative HTML version deleted]]
> 
> ___
> R-SIG-Mac mailing list
> R-SIG-Mac@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-mac

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

Re: [R-SIG-Mac] R 4 dumping tons of console messages in Big Sur

[Ken Beath]

That is what happens at times with beta software, and is more likely to be 
Apple’s problem. 

Assuming that you are properly registered put a bug report into Apple.

Ken

> On 25 Jun 2020, at 12:49 am, Timothy Bates  wrote:
> 
> R in pretty-much unusable in Big Sur (OSX beta) - it's generating many more
> than ever warning messages to the console, such that a simple calculation
> fills the page with warnings... e.g:
> 
> 
> (174-19)/15
> [1] 10.3
> 2020-06-24 15:45:31.472 R[4178:38668] 
> is drawing everything
> 2020-06-24 15:45:31.472 R[4178:38668] Drawing rect: {{9, 60}, {278, 323}}:
> 
> 2020-06-24 15:45:31.472 R[4178:38668] drawRow: 0, clip: {{0, 0}, {278,
> 323}} - 
> 2020-06-24 15:45:31.472 R[4178:38668]columnsToDraw:  0x63dd84b0>[number of indexes: 1 (in 1 ranges), indexes: (0)]
> 2020-06-24 15:45:31.472 R[4178:38668] Really drawing cell at row: 0 col: 0
> 2020-06-24 15:45:31.472 R[4178:38668] drawRow: 1, clip: {{0, 0}, {278,
> 323}} - 
> 2020-06-24 15:45:31.472 R[4178:38668]columnsToDraw:  0x63dd8540>[number of indexes: 1 (in 1 ranges), indexes: (0)]
> 2020-06-24 15:45:31.472 R[4178:38668] Really drawing cell at row: 1 col: 0
> 2020-06-24 15:45:31.472 R[4178:38668] drawRow: 2, clip: {{0, 0}, {278,
> 323}} - 
> 2020-06-24 15:45:31.472 R[4178:38668]columnsToDraw:  0x63dd84b0>[number of indexes: 1 (in 1 ranges), indexes: (0)]
> 2020-06-24 15:45:31.472 R[4178:38668] Really drawing cell at row: 2 col: 0
> 2020-06-24 15:45:31.472 R[4178:38668] drawRow: 3, clip: {{0, 0}, {278,
> 323}} - 
> 2020-06-24 15:45:31.472 R[4178:38668]columnsToDraw:  0x63dd8540>[number of indexes: 1 (in 1 ranges), indexes: (0)]
> 2020-06-24 15:45:31.472 R[4178:38668] Really drawing cell at row: 3 col: 0
> 2020-06-24 15:45:31.472 R[4178:38668] drawRow: 4, clip: {{0, 0}, {278,
> 323}} - 
> 2020-06-24 15:45:31.472 R[4178:38668]columnsToDraw:  0x63dd84b0>[number of indexes: 1 (in 1 ranges), indexes: (0)]
> 2020-06-24 15:45:31.472 R[4178:38668] Really drawing cell at row: 4 col: 0
> 2020-06-24 15:45:31.472 R[4178:38668] drawRow: 5, clip: {{0, 0}, {278,
> 323}} - 
> 2020-06-24 15:45:31.472 R[4178:38668]columnsToDraw:  0x63dd8540>[number of indexes: 1 (in 1 ranges), indexes: (0)]
> 2020-06-24 15:45:31.472 R[4178:38668] Really drawing cell at row: 5 col: 0
> 
>   [[alternative HTML version deleted]]
> 
> ___
> R-SIG-Mac mailing list
> R-SIG-Mac@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-mac

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

Re: [R-SIG-Mac] Can't open files in 4.0 or 4.01

[Brandon Hurr]

Simon,

1) Yes, I use homebrew for installing python/openCV and GIS stuff. I don't
recognize the others mentioned and I have a few system extensions installed
(discussed below).
2) I have been using Bob's Rswitch app recently and downloading the bundle
rather than using the installer. The behavior is unchanged for me on two
separate macs whether it's installed this way or not.

Related to #1, I have two separate macs where this is happening and both
more or less have the same software bundle from homebrew (and most other
apps).
brew list returns
gdbm openssl@1.1 python sqlite
jhead pandoc readline xz

I just wiped my homebrew install, rebooted, loaded an Rscript by double
clicking into R-gui and its editor, then tried to load another script and
it crashed R like before.
The behavior is the same with

   - R 4.0.2 & R.app GUI 1.72 (7846) x86_64-apple-darwin17.0 for R 4.0
   - Installed via PKG
  - R 4.1.0 (2020-06-21 r78727) & R.app GUI 1.72 (7846)
   x86_64-apple-darwin17.0 for R 4.1
   - Installed via untar

The only system extensions I see in my Sys Preferences are Google Drive,
Dropbox, One Drive, and OneNote. I haven't ever used the OneNote one and
rarely One Drive. Google Drive and Dropbox are installed and regularly
syncing a few folders. R seems to crash when opening a second file
regardless of where it is located (e.g. synced folder, non-synced folder,
external drive, system drive, etc.). I exited all of these programs and
tried again and it still happened.

Anything else I should try or more information I could supply to narrow
this down?

Thanks,
Brandon

On Tue, Jun 23, 2020 at 5:02 PM Simon Urbanek 
wrote:

> Brandon,
>
> Thanks for your reports. I tested all Catalinas 10.15.3 through 10.15.5
> and, frustratingly, I cannot replicate the issue. I tried opening documents
> of different sizes, multiple documents, even changing the "close windows
> when quitting the app" global setting and still no crash.
>
> There are a few posts that suggest the a crash on Open is not entirely
> uncommon on Catalina. There is no definite answer, but there are pointers
> to unnotarized parts/libraries loaded into a process. So one theory would
> be that users experiencing such issues have some 3rd part libraries or
> tools on the machine which are not notarized and cause the issue. So two
> comments from that:
>
> 1) do you have any 3rd party software that is not notarized? (like
> Homebrew, Haxxies, UI-plugins or similar) If so try to remove them (or
> rename their directories).
>
> 2) try using the unnotarized version of R to see if the problem persists -
> see R for Mac FAQ 10.17:
>
> https://cran.r-project.org/bin/macosx/RMacOSX-FAQ.html#I-cannot-attach-debugger-to-R
>
> Thanks,
> Simon
>
>
>
> > On Jun 9, 2020, at 2:39 AM, Brandon Hurr  wrote:
> >
> > Simon,
> >
> > When I removed these two I did get a slightly different behavior on my
> MBA.
> > In the past I would get the pinwheel of death and R would peg at 100%,
> but
> > now when I try and load a second file it simply crashes R immediately.
> > Debug Console log here:
> > https://gist.github.com/bhive01/1421f464ce5d345644878cd41309f647
> > Separately I loaded up R from my applications folder and then clicked on
> a
> > file to load it and it did the same thing:
> > https://gist.github.com/bhive01/d7791d0070a43d73de2489f6cab9211f
> > The same crashing behavior if you load it from the Open Recents in the
> menu:
> > https://gist.github.com/bhive01/1bae74d6cbcbb8c014415d47ac9fe456
> >
> > In the first instance I double clicked the file from Finder and it would
> > open with R-GUI/R. But a second file would not, once R was loaded.
> >
> > I don't know if that gets us any closer, but apparently there is some
> > difference in that it crashes immediately rather than a pinwheel of
> death.
> > The only thing I can think of is that I did have my own custom color
> > palette and you reference changing the color scheme. Seems unlikely, but
> > perhaps there's a connection there?
> > As Carl says, I'm happy to try other things if you have suggestions or
> have
> > ideas on more information. I've been using BBEdit to open other scripts,
> > but often forget and end up with a crash because I double-click on a
> file.
> > I might try to get BBEdit to work with R more intimately as Carl pointed
> > out.
> >
> > B
> >
> > On Sun, Jun 7, 2020 at 3:46 PM Simon Urbanek <
> simon.urba...@r-project.org>
> > wrote:
> >
> >> Thanks for the reports. Unfortunately, I still cannot reproduce it on
> >> Catalina - neither with 4.0.1 nor 4.0.0.
> >> Can someone post exactly how to replicate? (How do exactly you open the
> >> file? - the Open dialog works fine for me...)
> >>
> >> Note that the GUI is independent of R and compatible up to the patch
> >> version, i.e. the 4.0.0 GUI works with R 4.0.1 and vice-versa. You can
> also
> >> just download the GUI from
> >> https://mac.R-project.org
> >> and run it from the image, you don’t even have to install it.
> >>
> >> The only 

Re: [R-SIG-Mac] HDF4 Support for GDAL

[Matt Strimas-Mackey]

Thanks for the suggestion! Looked into it and gdalUtils uses system() calls to 
access gdalwarp at the command line, which is what previous versions of the 
MODIS package did and what the maintainers of that package are trying to avoid 
with the current version. I believe the thinking is that since sf includes self 
contained GDAL binaries it makes more sense to use that rather than have users 
install GDAL from source and get the MODIS package to connect to it, which is 
challenging for many users.

M

From: David Winsemius 
Date: Wednesday, June 24, 2020 at 12:11 PM
To: Matt Strimas-Mackey , "r-sig-mac@r-project.org" 

Subject: Re: [R-SIG-Mac] HDF4 Support for GDAL


Have you attempted installing and using 
https://cran.r-project.org/web/packages/gdalUtils/gdalUtils.pdf

I don't have any experience with it but it says it can extract sub_datasets 
from HDF4



--

David.
On 6/24/20 7:00 AM, Matt Strimas-Mackey wrote:

Hi all,



The MODIS package uses gdalwarp to process MODIS data. Previously it called 
gdalwarp via system(), however, it recently switched to using the function 
sf::gdal_utils() to access gdalwarp, which is more portable and avoids users 
having to install GDAL on their system. The catch is that HDF4 support is 
required for processing MODIS data. The Windows sf binaries already come with 
HDF4 support for GDAL, however, the Mac OS binaries do not, which makes the 
MODIS package unusable on Mac unless sf is compiled from source, which is 
challenging. More context on this issue is available here: 
https://github.com/MatMatt/MODIS/issues/78



In the above GH issue, Tim Salabim suggested this listserv would be a good 
place to connect with someone that could get HDF4 support into the Mac OS 
binaries. Any suggestions for how to proceed would be appreciated!



Thanks!



Matt



  [[alternative HTML version deleted]]



___

R-SIG-Mac mailing list

R-SIG-Mac@r-project.org

https://stat.ethz.ch/mailman/listinfo/r-sig-mac

[[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] HDF4 Support for GDAL

[David Winsemius]

Have you attempted installing and using 
https://cran.r-project.org/web/packages/gdalUtils/gdalUtils.pdf

I don't have any experience with it but it says it can extract 
sub_datasets from HDF4


-- 

David.

On 6/24/20 7:00 AM, Matt Strimas-Mackey wrote:
> Hi all,
>
> The MODIS package uses gdalwarp to process MODIS data. Previously it called 
> gdalwarp via system(), however, it recently switched to using the function 
> sf::gdal_utils() to access gdalwarp, which is more portable and avoids users 
> having to install GDAL on their system. The catch is that HDF4 support is 
> required for processing MODIS data. The Windows sf binaries already come with 
> HDF4 support for GDAL, however, the Mac OS binaries do not, which makes the 
> MODIS package unusable on Mac unless sf is compiled from source, which is 
> challenging. More context on this issue is available here: 
> https://github.com/MatMatt/MODIS/issues/78
>
> In the above GH issue, Tim Salabim suggested this listserv would be a good 
> place to connect with someone that could get HDF4 support into the Mac OS 
> binaries. Any suggestions for how to proceed would be appreciated!
>
> Thanks!
>
> Matt
>
>   [[alternative HTML version deleted]]
>
> ___
> R-SIG-Mac mailing list
> R-SIG-Mac@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-mac

[[alternative HTML version deleted]]

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

[R-SIG-Mac] R 4 dumping tons of console messages in Big Sur

[Timothy Bates]

R in pretty-much unusable in Big Sur (OSX beta) - it's generating many more
than ever warning messages to the console, such that a simple calculation
fills the page with warnings... e.g:


(174-19)/15
[1] 10.3
2020-06-24 15:45:31.472 R[4178:38668] 
is drawing everything
2020-06-24 15:45:31.472 R[4178:38668] Drawing rect: {{9, 60}, {278, 323}}:

2020-06-24 15:45:31.472 R[4178:38668] drawRow: 0, clip: {{0, 0}, {278,
323}} - 
2020-06-24 15:45:31.472 R[4178:38668]columnsToDraw: [number of indexes: 1 (in 1 ranges), indexes: (0)]
2020-06-24 15:45:31.472 R[4178:38668] Really drawing cell at row: 0 col: 0
2020-06-24 15:45:31.472 R[4178:38668] drawRow: 1, clip: {{0, 0}, {278,
323}} - 
2020-06-24 15:45:31.472 R[4178:38668]columnsToDraw: [number of indexes: 1 (in 1 ranges), indexes: (0)]
2020-06-24 15:45:31.472 R[4178:38668] Really drawing cell at row: 1 col: 0
2020-06-24 15:45:31.472 R[4178:38668] drawRow: 2, clip: {{0, 0}, {278,
323}} - 
2020-06-24 15:45:31.472 R[4178:38668]columnsToDraw: [number of indexes: 1 (in 1 ranges), indexes: (0)]
2020-06-24 15:45:31.472 R[4178:38668] Really drawing cell at row: 2 col: 0
2020-06-24 15:45:31.472 R[4178:38668] drawRow: 3, clip: {{0, 0}, {278,
323}} - 
2020-06-24 15:45:31.472 R[4178:38668]columnsToDraw: [number of indexes: 1 (in 1 ranges), indexes: (0)]
2020-06-24 15:45:31.472 R[4178:38668] Really drawing cell at row: 3 col: 0
2020-06-24 15:45:31.472 R[4178:38668] drawRow: 4, clip: {{0, 0}, {278,
323}} - 
2020-06-24 15:45:31.472 R[4178:38668]columnsToDraw: [number of indexes: 1 (in 1 ranges), indexes: (0)]
2020-06-24 15:45:31.472 R[4178:38668] Really drawing cell at row: 4 col: 0
2020-06-24 15:45:31.472 R[4178:38668] drawRow: 5, clip: {{0, 0}, {278,
323}} - 
2020-06-24 15:45:31.472 R[4178:38668]columnsToDraw: [number of indexes: 1 (in 1 ranges), indexes: (0)]
2020-06-24 15:45:31.472 R[4178:38668] Really drawing cell at row: 5 col: 0

[[alternative HTML version deleted]]

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

[R-SIG-Mac] HDF4 Support for GDAL

[Matt Strimas-Mackey]

Hi all,

The MODIS package uses gdalwarp to process MODIS data. Previously it called 
gdalwarp via system(), however, it recently switched to using the function 
sf::gdal_utils() to access gdalwarp, which is more portable and avoids users 
having to install GDAL on their system. The catch is that HDF4 support is 
required for processing MODIS data. The Windows sf binaries already come with 
HDF4 support for GDAL, however, the Mac OS binaries do not, which makes the 
MODIS package unusable on Mac unless sf is compiled from source, which is 
challenging. More context on this issue is available here: 
https://github.com/MatMatt/MODIS/issues/78

In the above GH issue, Tim Salabim suggested this listserv would be a good 
place to connect with someone that could get HDF4 support into the Mac OS 
binaries. Any suggestions for how to proceed would be appreciated!

Thanks!

Matt

[[alternative HTML version deleted]]

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

[R-SIG-Mac] How to create path for OpenBUGS into R using R2OpenBUGS with new Wineskin-Winery 1.8.4.1/Wineskin2.9.06-1 on MacOS Catalina 10.15.5

[Jordan Rogan]

Hi!


I recently downloaded the new Wineskin-Winery 1.8.4.1/Wineskin2.9.06-1 onto
my mac adapted for the limitations for MacOS Catalina 10.15.5 that caused
old versions of Wine to no longer work. I downloaded it so that I could
download the Windows program OpenBUGS and use R2openBUGS in R to use the
program. I am trying to figure out how to call OpenBUGS into R with
R2OpenBUGS with the new wineskin/wineskin-winery version.


 I found older code using the Wine argument in R2OpenBuGS, but I think the
path has significantly changed with the new version of Wineskin which is
not downloaded using homebrew as old versions of Wine were. I think I just
need to figure out how to create the correct path for the new version of
wine--I do not know if this is possible using the old wine argument
designed for older versions of wine.


I downloaded the new Wineskin from here:
https://github.com/Gcenx/WineskinServer/releases


The old path for OpenBUGS and R2OpenBUGS for older versions of wine I found
were: WINE="/usr/local/Cellar/wine/2.0.4/bin/wine"

WINEPATH="/usr/local/Cellar/wine/2.0.4/bin/winepath"

OpenBUGS.pgm="/Applications/OpenBUGS323/OpenBUGS.exe"


But trying to do the same, I received the error message: "Error in
bugs(spp.data, inits, params, "model1.txt", debug = T, n.chains = nc, : *unused
argument (OpenBUGS.pgm = bugs)"*


Part of my confusion is what the difference is between the arguments "wine"
and "winepath". There is also an argument "newWINE" that says: *"Use new
versions of Wine that have ‘winepath’ utility*", but I don't know if my
version of wine has this, and how this argument is then written.


If I go to the "get info" on where my wineskin app is on my computer, the
path is (while redacting my name)
"/Users/firstname_lastname/Applications/Wineskin/Wineskin-2.9.0.7.app".
Maybe this would work? But I don't know if this would be in the argument
for wine, or winepath.


I think perhaps if I can adapt the path, it will work. But I'm not sure
exactly what is needed, particularly for the new version of wine for MacOS
Catalina, and if the old wine arguments even work with the new version of
wine. If anyone could help I would sincerely appreciate it. Thanks!!

-- 
Jordan Rogan

Ph.D. Candidate, Applied Biodiversity Sciences
Department of Ecology and Conservation Biology (ECCB)
Texas A University
Website: jordanrogan.wordpress.com | Twitter: @jordrogan | Skype: jord0123

[[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] Packages with updated spatial libraries.

[Edzer Pebesma]

Dear Roy, thanks for the message. Is it possible that the sf version you
use links to an older version of GDAL/PROJ than the new rgdal does? In
other words: if you update sf from CRAN, does the error persist?

Many regards,

On 6/22/20 9:28 PM, Roy Mendelssohn - NOAA Federal wrote:
> I installed the whole suite available through Prof. Ripley's efforts, and 
> finally have gotten time to do extensive testing.  I just ran into a problem 
> with code that worked previously. It doesn't break all the mapping code,  
> only some. The error I get is given below.  And yes I realize that this by 
> itself it isn't much help.  It is a function calling a function in another 
> package that causes the problem.  I am going to have to get in with the 
> debugger and see what is actually being passed, and I will post what is going 
> on in more detail when I figure it out.  This is more just a heads-up that 
> the new versions can indeed break things in existing code.  This is what I 
> was hoping to find out,  because it is going to take some time to pinpoint 
> where.
> 
> -Roy
> 
>> Error in st_crs.character(comment(x)) : invalid crs: GEOGCRS["unknown",
>> DATUM["World Geodetic System 1984",
>> ELLIPSOID["WGS 84",6378137,298.257223563,
>> LENGTHUNIT["metre",1]],
>> ID["EPSG",6326]],
>> PRIMEM["Greenwich",0,
>> ANGLEUNIT["degree",0.0174532925199433],
>> ID["EPSG",8901]],
>> CS[ellipsoidal,2],
>> AXIS["longitude",east,
>> ORDER[1],
>> ANGLEUNIT["degree",0.0174532925199433,
>> ID["EPSG",9122]]],
>> AXIS["latitude",north,
>> ORDER[2],
>> ANGLEUNIT["degree",0.0174532925199433,
>> ID["EPSG",9122
>> In addition: Warning messages:
>> 1: In rgdal::rawTransform(projfrom, projto, nrow(xy), xy[, 1], xy[,  :
>>   Using PROJ not WKT2 strings
>> 2: In rgdal::rawTransform(projection(obj), crs, nrow(xy), xy[, 1],  :
>>   Using PROJ not WKT2 strings
>> 3: In rgdal::rawTransform(projto_int, projfrom, nrow(xy), xy[, 1],  :
>>  
>>  Error in st_crs.character(comment(x)) : invalid crs: GEOGCRS["unknown",
>> DATUM["World Geodetic System 1984",
>> ELLIPSOID["WGS 84",6378137,298.257223563,
>> LENGTHUNIT["metre",1]],
>> ID["EPSG",6326]],
>> PRIMEM["Greenwich",0,
>> ANGLEUNIT["degree",0.0174532925199433],
>> ID["EPSG",8901]],
>> CS[ellipsoidal,2],
>> AXIS["longitude",east,
>> ORDER[1],
>> ANGLEUNIT["degree",0.0174532925199433,
>> ID["EPSG",9122]]],
>> AXIS["latitude",north,
>> ORDER[2],
>> ANGLEUNIT["degree",0.0174532925199433,
>> ID["EPSG",9122  
> 
> -Roy
> 
> 
>>
>> On Jun 12, 2020, at 7:20 AM, Roy Mendelssohn - NOAA Federal 
>>  wrote:
>>
>> I will do the install sometime over the weekend,  and test what I have  
>> (mainly the packages I have that use these).  Today is kind of tis up  (I 
>> mean I can do the install easily enough,  just no time to do any testing).
>>
>> Thanks,
>>
>> -Roy
>>
>>
>>> On Jun 12, 2020, at 7:17 AM, Roger Bivand  wrote:
>>>
>>> On Fri, 12 Jun 2020, rmendelss gmail wrote:
>>>
 Thank you for these efforts.  I imagine it will also make it easier to 
 eventually have these on CRAN.

>>>
>>> Do you have the possibility to try out the affected packages in your 
>>> workflows to provide feedback? At the moment, user feedback can help guide 
>>> the deployment of CRAN macOS R-spatial binaries.
>>>
>>> Roger
>>>
 -Roy


> On Jun 12, 2020, at 7:11 AM, Prof Brian Ripley  
> wrote:
>
> I have put binary packages on CRANextras for lwgeom rgdal rgeos sf built 
> with GEOS 3.8.1, GDAL 3.1.0, PROJ 6.3.2.
>
> Install with (e.g.)
>
> options(repos="https://www.stats.ox.ac.uk/pub/RWin;)
> install.packages('rgdal', type = 'binary')
>
> (This needed a development version of the rgdal sources.)
>
> This is just to allow early access: it is planned to use these versions 
> of the libs on the CRAN builders soon (but they do need package updates, 
> e.g. for rgdal and proj4).
>
> These are all using static libraries to make these self-contained.
>
> (In case anyone is wondering why not PROJ 7 -- that would need unreleased 
> changes to the PROJ and GDAL sources and changes to many CRAN packages.)
>
> --
> Brian D. Ripley,  rip...@stats.ox.ac.uk
> Emeritus Professor of Applied Statistics, University of Oxford
>
> ___
> R-SIG-Mac mailing list
> R-SIG-Mac@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-mac


>>>
>>> -- 
>>> Roger Bivand
>>> Department of Economics, Norwegian School of Economics,
>>> Helleveien 30, N-5045 Bergen, Norway.
>>> voice: +47 55 95 93 55; e-mail: roger.biv...@nhh.no
>>> 

Re: [R-SIG-Mac] Download for MacOS

[Simon Urbanek]

Paige,

thanks, now fixed. The symlink was missing, the actual location worked
https://cran.r-project.org/bin/macosx/base/R-4.0.2.pkg
but the shortcut didn't. The master now works 
(https://mac.R-project.org/bin/macosx ), all others mirrors should sync up in 
time.

Thanks,
Simon


> On Jun 24, 2020, at 5:19 PM, Paige Coburn  wrote:
> 
> Hello,
> I’m trying to download R for MacOS 4.0.2.pkg and I am getting an “Error 404” 
> message. 

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