similar to: The R Journal, Volume 9, Issue 1

On Sat, 10 Nov 2018, Andreas Storvik Strauman wrote: > Hello! I'm confused as to what the actual problem with includeRnw is? Is > the problem that it relies on R-knitr? Before it would be withdrawn, may > I be given an opportunity to fix said problem? Yes, the problem is that it expesses an external dependence on anything outside texlive. On packaging systems (for me Fedora),

Hello! I'm confused as to what the actual problem with includeRnw is? Is the problem that it relies on R-knitr? Before it would be withdrawn, may I be given an opportunity to fix said problem? includeRnw only invokes the already existing R installation, and should not affect any other global settings or affect the installation in any way. If this is the case, it's a bug and I'd

On Sat, 10 Nov 2018, I?aki Ucar wrote: > On Sat, 10 Nov 2018 at 15:17, Roger Bivand <Roger.Bivand at nhh.no> wrote: >> >> On upgrading my F28 to F29, I've found that R-core and a number of R >> packages: >> >> R-evaluate R-glue R-highr R-knitr R-magrittr R-markdown R-mime R-stringi >> R-stringr R-yaml >> >> are installed, although I

Dear all, The latest issue of The R Journal is now available at: https://journal.r-project.org/archive/2017-2/. New this time - quick access to news and notes 2013-to date in the navigation bar to the left including new Forwards and R-teaching columns; articles in 2017-2 may link to code and other supplementary matter from landing pages. Many thanks to all contributors - especially

Dear all, The latest issue of The R Journal is now available at: https://journal.r-project.org/archive/2017-2/. New this time - quick access to news and notes 2013-to date in the navigation bar to the left including new Forwards and R-teaching columns; articles in 2017-2 may link to code and other supplementary matter from landing pages. Many thanks to all contributors - especially

On Sat, 10 Nov 2018 at 15:17, Roger Bivand <Roger.Bivand at nhh.no> wrote: > > On upgrading my F28 to F29, I've found that R-core and a number of R > packages: > > R-evaluate R-glue R-highr R-knitr R-magrittr R-markdown R-mime R-stringi > R-stringr R-yaml > > are installed, although I only ever install R from source and always keep > my Rs locally. So I

On upgrading my F28 to F29, I've found that R-core and a number of R packages: R-evaluate R-glue R-highr R-knitr R-magrittr R-markdown R-mime R-stringi R-stringr R-yaml are installed, although I only ever install R from source and always keep my Rs locally. So I don't use Fedora R rpms, but these were installed without my command. Something in texlive is doing this. A remedy is to

In the rgdal package, configure.ac has had : ${LDFLAGS=`"${RBIN}" CMD config LDFLAGS`} at least since 2012, so picking up LDFLAGS known to the R version installed. Very recently, users installing rgdal from source with R installed from RPM are seeing problems, such as those reported in this thread: https://stat.ethz.ch/pipermail/r-sig-geo/2020-June/028251.html The diagnosis by

The third report on the R-spatial evolution project has been published. https://r-spatial.org/r/2023/04/10/evolution3.html It links back to earlier blogs and presentations, and focuses on work that maintainers of R packages and workflows using rgdal, rgeos and maptools need to put in train now before the packages are archived on CRAN. The first changes will occur in June 2023, and the

The third report on the R-spatial evolution project has been published. https://r-spatial.org/r/2023/04/10/evolution3.html It links back to earlier blogs and presentations, and focuses on work that maintainers of R packages and workflows using rgdal, rgeos and maptools need to put in train now before the packages are archived on CRAN. The first changes will occur in June 2023, and the

A new release of rgdal, a package providing bindings for the Geospatial Data Abstraction Library for reading and writing spatial data, has reached CRAN. This release changes the error handling mechanisms, and is more fully described in a posting on R-sig-geo: https://stat.ethz.ch/pipermail/r-sig-geo/2011-July/012126.html If any users observe unexpected behaviour following update, please

A new release of rgdal, a package providing bindings for the Geospatial Data Abstraction Library for reading and writing spatial data, has reached CRAN. This release changes the error handling mechanisms, and is more fully described in a posting on R-sig-geo: https://stat.ethz.ch/pipermail/r-sig-geo/2011-July/012126.html If any users observe unexpected behaviour following update, please

I was looking at the example on the manual page of plot.window, and noticed that it needs fixing - names(eurodist) should now be labels(eurodist): --- /home/rsb/topics/R-2.2.0/src/library/graphics/man/plot.window.Rd 2005-04-18 12:18:59.000000000 +0200 +++ plot.window.Rd 2005-10-11 21:08:57.000000000 +0200 @@ -48,6 +48,6 @@ ry <- range(y <- -loc[,2]) plot(x, y, type="n",

Very helpful. One (possible) correction inline below... On Thu, 30 Mar 2006, Ray Brownrigg wrote: > > From: nhy303 at abdn.ac.uk > > > > I have plotted a map of the Barents Sea and surrounding coastline using: > > > > map('worldHires',ylim=c(50,85),xlim=c(5,65),fill=T,resolution=0) > > map.axes() > > map.scale(x=30,metric=T) > > > >

Excuse my asking here than on R-help, but it may be a Fedora question. On Fedora 7, I'm running a fresh R 2.7.1 built from source, usually in en_GB, but also tried in en_GB.UTF8. Running example(plotmath) generates lots of: Pango-WARNING **: shape engine failure, expect ugly output. the offending font is 'Symbol Not-Rotated ...' Setting: x11(type="Xlib") relieves the

Hi, I installed F14 on release, but was diquieted to note that my symlinked GotoBLAS (http://cran.r-project.org/doc/manuals/R-admin.html#Shared-BLAS, foot of paragraph) prevented R (compiled from source, no special configure options) from loading - everything had been fine on F < 14. It seems that: cat /selinux/booleans/allow_execstack is 1 1 on my RHEL systems, but became (?) 0 0 in F14.

Please do not cross-post. Please do provide sufficient information to help diagnose your problem (here the output of the ./configure run during installation). Almost certainly you are trying to install from source when one or more external dependency is not satisfied. Did you read: http://cran.r-project.org/bin/linux/redhat/README and note that R-rgdal is *not* provided as a binary? Did you

Revised versions of maptools, a package for reading geographical data from shapefiles, and sp, a package with classes and methods for spatial data handling, have been released on CRAN. They are maptools release 0.5-1 and sp release 0.8-1. The maptools package now depends on sp (>= 0.8), so that users of maptools will need both to update the package itself, and to install the sp package. All

>From version 2.01-17, splancs, a package for spatial point pattern analysis, depends on package sp. Because both packages have defined a bounding box function bbox(), the bbox() method in sp has been given priority, and the default object for dispatch is an array with two or more columns (as in splancs until now). However, the deprecated splancs function returned a non-closed rectangle of

>From version 2.01-17, splancs, a package for spatial point pattern analysis, depends on package sp. Because both packages have defined a bounding box function bbox(), the bbox() method in sp has been given priority, and the default object for dispatch is an array with two or more columns (as in splancs until now). However, the deprecated splancs function returned a non-closed rectangle of