[R-SIG-Mac] Help in creating a MacOSX binary of the mapdata package 2.1-3?
Ray Brownrigg
Ray.Brownrigg at ecs.vuw.ac.nz
Tue Aug 31 05:37:31 CEST 2010
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:
> On Aug 30, 2010, at 8:46 PM, Jooil Kim wrote:
> > Hi Simon,
> >
> > First off, I can see that some of my previous comments were very ignorant
> > in many regards. Having been given further information on the efforts of
> > the r-project community in maintaining the MacOSX binaries, I sincerely
> > regret most of my remarks.
> >
> > That said, I find it strange that not only does the compile work, but so
> > do all the examples in the mapdata package - the "map('china')" example,
> > the source of trouble according to the logs, seems to work OK. As far as
> > I can tell so far, other users cannot reproduce the bug that's keeping a
> > MacOSX binary from being generated for CRAN.
>
> 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
>
> > My main purpose was to help point out that there may be a problem, not
> > point fingers at anyone or be disrespectful for any of the people who put
> > in time and effort to help maintain R. Once again apologize if some of my
> > sentences came out that way.
> >
> > I still hope that a solution could be found, as I believe binary forms of
> > packages are desirable for most people using R, however I don't think I
> > should be further wasting the community's valuable time with this issue.
> >
> > Cheers,
> >
> > Jooil
> >
> > On Tue, Aug 31, 2010 at 7:51 AM, Simon Urbanek
> > <simon.urbanek at r-project.org> wrote:
> >
> > On Aug 30, 2010, at 3:46 AM, Jooil Kim wrote:
> > > Hello,
> > >
> > > My problem was that I didn't have XCode installed until a few minutes
> > > ago, and I can confirm that compiling from the source works (x86_64 on
> > > OSX10.6.4, R2.11.1 - sorry about that).
> >
> > 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.
> >
> > > The error codes I pasted on my earlier e-mail were copied from the
> > > CRAN, the log notes on why a Mac binary of the mapdata package wasn't
> > > available (
> > > http://www.r-project.org/nosvn/R.check/r-release-macosx-ix86/mapdata-00
> > >check.html ).
> > >
> > > As there's no obvious problem with the source code itself, the problem
> > > is most probably with those that maintain the MacOSX binaries on CRAN.
> >
> > 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...
> >
> > > I assume there may be some novice users who might not want to go
> > > through the trouble of trying to compiling source code and much rather
> > > install just the binary versions of packages, and I do hope that the
> > > overseers of the MacOSX binaries would give the compile another try...
> >
> > 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 Mon, Aug 30, 2010 at 3:54 PM, Prof Brian Ripley <ripley at stats.ox.ac.uk>wrote:
> > >> On Mon, 30 Aug 2010, Jooil Kim wrote:
> > >>
> > >> Hello all,
> > >>
> > >>> I recently noticed that the MacOSX binary of the mapdata package ver
> > >>> 2.1-3 wasn't available.
> > >>>
> > >>> The mapdata package is a useful extension for the maps package,
> > >>> providing higher-resolution map data.
> > >>>
> > >>> In contacting package maintainer Ray Brownrigg, (Ray.Brownrigg at
> > >>> ecs.vuw.ac.nz), I'm told that he is willing to make the fixes
> > >>> necessary, however does not have the Mac resources to track the bug
> > >>> causing the problems.
> > >>>
> > >>> In looking at the log, I get the impression that the actual problem
> > >>> is minor, in that a problem occurs in checking the examples.
> > >>
> > >> 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)
> > >>
> > >> .
> > >>
> > >>> Here's a copy-and-paste from the logs below.
> > >>>
> > >>> ==================================================================
> > >>> checking examples ... ERROR
> > >>> Running examples in 'mapdata-Ex.R' failed.
> > >>> The error most likely occurred in:
> > >>>
> > >>> ### * china
> > >>>
> > >>>> flush(stderr()); flush(stdout())
> > >>>>
> > >>>> ### Name: china
> > >>>> ### Title: China Map
> > >>>> ### Aliases: china chinaMapEnv
> > >>>> ### Keywords: datasets
> > >>>>
> > >>>> ### ** Examples
> > >>>>
> > >>>> map('china')
> > >>>
> > >>> *** caught segfault ***
> > >>> address 0x30010073, cause 'memory not mapped'
> > >>>
> > >>> Traceback:
> > >>> 1: .C("maptype", PACKAGE = "maps", as.character(mapbase), integer(1))
> > >>> 2: maptype(database)
> > >>> 3: map("china")
> > >>> aborting ...
> > >>> ==================================================================
> > >>>
> > >>> Does anyone in the Mac group have the skills and time to figure this
> > >>> out and
> > >>> contact Ray about a solution?
> > >>>
> > >>> Sorry, I should really try to do this myself, but I'm still very new
> > >>> at this...
> > >>>
> > >>> Thanks,
> > >>>
> > >>> Jooil
> > >>>
> > >>> --
> > >>> #############################################
> > >>> Jooil Kim
> > >>> Graduate Student
> > >>> School of Earth and Environmental Sciences,
> > >>> Seoul National University
> > >>> Gwanak Gu Shillim 9 Dong San 56-1
> > >>> Seoul National Univ. Bld#501, Rm 503
> > >>> Seoul, Rep. of Korea 151-742
> > >>> kji2080 at gmail.com
> > >>> tel) 82-2-877-6741
> > >>> fax) 82-2-885-7164
> > >>> #############################################
> > >>>
> > >>> [[alternative HTML version deleted]]
> > >>>
> > >>> _______________________________________________
> > >>> R-SIG-Mac mailing list
> > >>> R-SIG-Mac at stat.math.ethz.ch
> > >>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
> > >>
> > >> --
> > >> Brian D. Ripley, ripley at stats.ox.ac.uk
> > >> Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
> > >> University of Oxford, Tel: +44 1865 272861 (self)
> > >> 1 South Parks Road, +44 1865 272866 (PA)
> > >> Oxford OX1 3TG, UK Fax: +44 1865 272595
> > >
> > > --
> > > #############################################
> > > Jooil Kim
> > > Graduate Student
> > > School of Earth and Environmental Sciences,
> > > Seoul National University
> > > Gwanak Gu Shillim 9 Dong San 56-1
> > > Seoul National Univ. Bld#501, Rm 503
> > > Seoul, Rep. of Korea 151-742
> > > kji2080 at gmail.com
> > > tel) 82-2-877-6741
> > > fax) 82-2-885-7164
> > > #############################################
> > >
> > > [[alternative HTML version deleted]]
> > >
> > > _______________________________________________
> > > R-SIG-Mac mailing list
> > > R-SIG-Mac at stat.math.ethz.ch
> > > https://stat.ethz.ch/mailman/listinfo/r-sig-mac
> >
> > --
> > #############################################
> > Jooil Kim
> > Graduate Student
> > School of Earth and Environmental Sciences,
> > Seoul National University
> > Gwanak Gu Shillim 9 Dong San 56-1
> > Seoul National Univ. Bld#501, Rm 503
> > Seoul, Rep. of Korea 151-742
> > kji2080 at gmail.com
> > tel) 82-2-877-6741
> > fax) 82-2-885-7164
> > #############################################
More information about the R-SIG-Mac
mailing list