Skip to content

Help in creating a MacOSX binary of the mapdata package 2.1-3?

8 messages · David Winsemius, Brian Ripley, Simon Urbanek +2 more

#
On Aug 29, 2010, at 8:15 PM, Jooil Kim wrote:

            
There is an earlier version 2.1-1.
When I compile from source on a Mac 10.5.8  running R 2.11.1 the  
version 2.1-3 of mapdata does not report an error.

 > require(mapdata)
 > map("china") # draws a map
-------------- next part --------------
A non-text attachment was scrubbed...
Name: map_china.pdf
Type: application/pdf
Size: 34153 bytes
Desc: not available
URL: <https://stat.ethz.ch/pipermail/r-sig-mac/attachments/20100829/4d546f10/attachment-0001.pdf>
-------------- next part --------------

 > sessionInfo()
R version 2.10.1 Patched (2010-02-17 r51152)
x86_64-apple-darwin9.8.0

locale:
[1] en_US.UTF-8/en_US.UTF-8/C/C/en_US.UTF-8/en_US.UTF-8

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base

other attached packages:
[1] mapdata_2.1-3  maps_2.1-4     reshape_0.8.3  plyr_0.1.9      
lattice_0.18-3

loaded via a namespace (and not attached):
[1] grid_2.10.1  tools_2.10.1
#
On Mon, 30 Aug 2010, Jooil Kim wrote:

            
Not being able to run your examples is not 'minor': it is the first 
test that the package is installed properly, and 'china' is the first 
example.

You haven't told us the 'at a minimum information' asked for in the 
posting guide.  What version of R (including what architecture) are 
you running?  Have you actually tried compiling from the package 
sources yourself?  It works for me on i386 and x86_64.

So there is a fair chance simply installing from the sources will work 
for you.  If you have Xcode installed, all you need to do is

install.packages('mapdata', type = 'source')
library(mapdata)
example(china)

.

  
    
#
On Aug 30, 2010, at 3:46 AM, Jooil Kim wrote:

            
Of course it does - you can see that form the logs (sort of since you have different OS and different architecture and thus not really relevant to the error). But that is beside the point. The fact that something compiles doesn't meant it works.
If programs crash and there is "no obvious problem with the source" then why do we bother with debugging? If there was an obvious problem then the author would have fixed it, don't you think? It's the non-obvious problems that we call "bugs".

The point of checks is to verify (to some degree) that a program works the way it was designed. That's why a binary of a package failing checks will not get to CRAN as it doesn't work the way it was designed - to protect users from non-obvious failures. Now why that should be a problem "with those that maintain the MacOSX binaries" is entirely beyond me...

Note that the crash is in a call to maps so the issue could be anywhere from mapdata, maps to R...
Sure - with the same result. That's what the nightly builds do: run checks every night if a package fails - one try a night ... 

Cheers,
Simon
#
On Aug 30, 2010, at 8:46 PM, Jooil Kim wrote:

            
I can reproduce it reliably in R CMD check and semi-reliably in a session. The problem is that it is reproducible with the binary, i.e. there is a non-zero probability that it will happen. The backtrace points into .C itself -- but since mapdata itself has no native code it is either an issue in maps or R... (or mapdata generates something on which maps chokes).

I spent quite some time on it today and still can't pin it down (valgrind shows nothing), so I can release the binary for mapdata but what this means is that updates won't be pushed automatically.

Cheers,
Simon
#
Simon (et. al.):

Are you able to reproduce the problem with any of the other datasets, either in the maps 
or mapdata packages?  At one level there are two different dataset 'structures' in 
mapdata, one type shared by "china" and "rivers", the other by "worldHires" 
and "nzHires".  [Specifically, most datasets are polygon based, but "china" and "rivers" 
consist of line segments only.]

Further, the "france" and "italy" datasets in the maps package are not explicitly tested 
in the examples and, if I recall correctly, they are of a similar construction to 
the "china" dataset.

If you can find any pattern here, I might be able to construct a smaller dataset that may 
help in the diagnosis.

Regards,
Ray Brownrigg

----
Data sets in package 'mapdata':

chinaMapEnv             China Map
nzHiresMapEnv           New Zealand Map
riversMapEnv            World Rivers Map Database
world2HiresMapEnv       Pacific Centric World Map
worldHiresMapEnv        World Map

Data sets in package 'maps':

canada.cities           Database of Canadian cities
countyMapEnv            United States County Map
franceMapEnv            France Map
italyMapEnv             Italy Map
nzMapEnv                New Zealand Basic Map
ozone                   Sample datasets
stateMapEnv             United States State Boundaries Map
us.cities               Database of US cities
usaMapEnv               United States Coast Map
votes.repub             Sample datasets
world.cities            Database of world cities
world2MapEnv            Pacific Centric Low resolution World Map
worldMapEnv             Low resolution World Map
----
On Tue, 31 Aug 2010, Simon Urbanek wrote: