Re: [Rd] problem with R installation package
> Jeroen Ooms
> on Mon, 9 Jan 2012 13:56:44 -0800 writes:
> Hi Regis,
> As you can see on the cran page of your package, no binaries have been
build
> yet for windows or osx. This can take a couple of days, you have to be
> patient. For now you can install your package from source using:
> install.packages("G2Sd", type="source")
> ps: This is a question for the r-help mailing list, not r-devel.
Yes, indeed!
Martin Maechler
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] CRAN binary packages (was problem with R installation package)
On 10/01/2012 08:16, Martin Maechler wrote:
Jeroen Ooms
on Mon, 9 Jan 2012 13:56:44 -0800 writes:
> Hi Regis,
> As you can see on the cran page of your package, no binaries have been
build
> yet for windows or osx. This can take a couple of days, you have to be
> patient. For now you can install your package from source using:
> install.packages("G2Sd", type="source")
> ps: This is a question for the r-help mailing list, not r-devel.
Yes, indeed!
Martin Maechler
Except that for Windows binaries packages, people are asked in several
places (including the @ReadMe and the rw-FAQ) not to ask about them on
R-help, and for Mac binary packages only R-sig-mac is possibly appropriate.
There are only a handful of people who could do anything about binary
packages, and they are very busy people and probably only skim R-help at
most. If there really is a problem not explained by impatience or the
results on the CRAN log page at
http://cran.r-project.org/web/checks/check_summary.html it would be best
to contact them directly: but please check carefully that there is not
yet an explanation on e.g. R-sig-mac.
The whole CRAN process is running close to its human and machine
resource limits: there are plans afoot to ease some of the pressures,
but they too need resources to design and implement.
It would help a lot if people would follow the checklist in 'Writing R
Extensions' and the policies linked from
http://cran.r-project.org/web/packages/index.html, and in particular not
submit too-frequent updates and submit tarballs that check cleanly and
have been checked on win-builder. And definitely: send a submission
email mentioning the package in the subject line.
Slightly off-subject (but applied to Regis' submission): CRAN is
nowadays taking some NOTEs as more serious, so e.g.
- new submissions are required to have a NAMESPACE file and updates will
get nagged to add one.
- packages are expected not to call C/C++ assert, abort, exit or FORTRAN
stop, so please address that before submission. (The reason this is
still a NOTE is that there are false positives on some platforms: check
on Linux if at all possible.)
--
Brian D. Ripley, rip...@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, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] serializing recordedplot object
On Jan 10, 2012, at 1:06 AM, Jeroen Ooms wrote:
> The underlying problem turns out to be serialization of objects of
> class "NativeSymbolInfo". When these are serialized and unserialized,
> the memory address turns into a nullpointer, causing the fail. To fix
> it, one can simply create new nativeSymbolInfo objects. E.g:
>
> # The old example:
> library(lattice);
> histogram(rnorm(100));
> x <- recordPlot();
> saveRDS(x, "myplot.rds");
> y <- readRDS("myplot.rds");
>
> # y contains nullpointers making it fail.
> print(y);
>
> # To fix:
> for(i in 1:length(y[[1]])) {
> if( "NativeSymbolInfo" %in% class(y[[1]][[i]][[2]][[1]]) ){
>y[[1]][[i]][[2]][[1]] <- getNativeSymbolInfo(y[[1]][[i]][[2]][[1]]$name);
> }
> }
> print(y);
>
> Now this works, but it is a bit ugly. Is there a more general method
> of serializing objects in a way that native objects are restored where
> possible?
>
Unfortunately R doesn't provide a way for this. Without changes to
unserialization (on the wishlist for a few years now, but not easy to design)
the best you can do is to check the native symbols for NULL pointers on usage
and then re-fetch - that's something that could be done reasonably easily,
although it's still a hack ...
>
>
>
>
>
> On Mon, Jan 9, 2012 at 12:47 AM, Jeroen Ooms
> wrote:
>>
>> I use recordPlot() to save plots to disk that I render later to a
>> variety of formats. This works fine for base R plots and ggplot2
>> plots, and also used to work for lattice plots. However somewhere in
>> version 2.14 things stopped working for lattice plots. Here is an
>> example:
>>
>> library(lattice);
>> histogram(rnorm(100));
>> x <- recordPlot();
>> saveRDS(x, "myplot.rds");
>> y <- readRDS("myplot.rds");
>> print(y);
>> Error: NULL value passed as symbol address
>>
>> printing x works fine, but printing y either gives an error or prints
>> an empty page. The problem seems to be related to serializing the
>> recordedplot object, which contains a lot of memory pointers. Any tips
>> or workarounds?
>>
>>> sessionInfo()
>> R version 2.14.1 (2011-12-22)
>> Platform: i686-pc-linux-gnu (32-bit)
>>
>> locale:
>> [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
>> [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
>> [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
>> [7] LC_PAPER=C LC_NAME=C
>> [9] LC_ADDRESS=C LC_TELEPHONE=C
>> [11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
>>
>> attached base packages:
>> [1] stats graphics grDevices utils datasets methods base
>>
>> other attached packages:
>> [1] lattice_0.20-0
>>
>> loaded via a namespace (and not attached):
>> [1] grid_2.14.1
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] serializing recordedplot object
I don't think anyone has yet mentioned that the canonical way to save
lattice plots is to save the object produced by lattice, and print() it
again when required.
recordPlot was only ever intended to be a temporary expedient, as the
help page says.
On 10/01/2012 14:17, Simon Urbanek wrote:
On Jan 10, 2012, at 1:06 AM, Jeroen Ooms wrote:
The underlying problem turns out to be serialization of objects of
class "NativeSymbolInfo". When these are serialized and unserialized,
the memory address turns into a nullpointer, causing the fail. To fix
it, one can simply create new nativeSymbolInfo objects. E.g:
# The old example:
library(lattice);
histogram(rnorm(100));
x<- recordPlot();
saveRDS(x, "myplot.rds");
y<- readRDS("myplot.rds");
# y contains nullpointers making it fail.
print(y);
# To fix:
for(i in 1:length(y[[1]])) {
if( "NativeSymbolInfo" %in% class(y[[1]][[i]][[2]][[1]]) ){
y[[1]][[i]][[2]][[1]]<- getNativeSymbolInfo(y[[1]][[i]][[2]][[1]]$name);
}
}
print(y);
Now this works, but it is a bit ugly. Is there a more general method
of serializing objects in a way that native objects are restored where
possible?
Unfortunately R doesn't provide a way for this. Without changes to
unserialization (on the wishlist for a few years now, but not easy to design)
the best you can do is to check the native symbols for NULL pointers on usage
and then re-fetch - that's something that could be done reasonably easily,
although it's still a hack ...
On Mon, Jan 9, 2012 at 12:47 AM, Jeroen Ooms wrote:
I use recordPlot() to save plots to disk that I render later to a
variety of formats. This works fine for base R plots and ggplot2
plots, and also used to work for lattice plots. However somewhere in
version 2.14 things stopped working for lattice plots. Here is an
example:
library(lattice);
histogram(rnorm(100));
x<- recordPlot();
saveRDS(x, "myplot.rds");
y<- readRDS("myplot.rds");
print(y);
Error: NULL value passed as symbol address
printing x works fine, but printing y either gives an error or prints
an empty page. The problem seems to be related to serializing the
recordedplot object, which contains a lot of memory pointers. Any tips
or workarounds?
sessionInfo()
R version 2.14.1 (2011-12-22)
Platform: i686-pc-linux-gnu (32-bit)
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
[3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
[5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
[7] LC_PAPER=C LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] lattice_0.20-0
loaded via a namespace (and not attached):
[1] grid_2.14.1
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Brian D. Ripley, rip...@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, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] S4 summary method not being called (VGAM)
A relevant report, not just for VGAM but for maintainers of other
packages that define methods for functions that have both generic and
non-generic versions in other packages.
The problem is that VGAM "Depends" on stats4 but does not import from
it. So when VGAM is loaded, only the old version of summary() is
available. Importing the relevant functions from stats4 in VGAM should
fix the problem.
With the current R 2.14.1 this happens silently. With the latest
r-devel, the installation of VGAM produces a warning:
"Functions for exporting methods must have been made generic, explicitly
or implicitly; not true when loading 'VGAM' for 'AIC', 'coef', 'logLik',
'plot', 'summary', 'vcov' "
This implies (a bit obscurely) that the package has generic versions in
its dependencies, but has not imported them.
Maintainers of CRAN packages should check installation against the
development version. Warning messages like this suggest a problem with
the imports.
John
On 1/9/12 5:05 PM, mark.braving...@csiro.au wrote:
The symptom triggering this email is that an S4 summary method sometimes
refuses to be invoked, even when a package is explicitly loaded, if the first
load of the package is implicit. It may or may not be specific to 'summary'
methods and/or the 'VGAM' package. I've sent to R-devel because (i) it looks
like some kind of bug to me, but I'm not sure; (ii) it's not something I
personally need any help with; and (iii) it seems a bit specialized for R-help.
Here's the case notes. I have an object 'nf1' of S4 class 'vglm', created by calling 'vglm(...)'
from package 'VGAM' (you can create your own from the examples in VGAM). It's save()d into a file
"nf1.rda". If I start a new R session, call 'library( VGAM)', and then
'load("nf1.rda")', then 'summary(nf1)' works fine. But if instead I start a pretty basic
R session and load() the file *without* having explicitly called library( VGAM), the summary method
for 'vglm' doesn't get called whether or not I subsequently call library( VGAM). Transcript below.
I'm using R 2.13.2 on Windows XP, VGAM 0.8-4. The same thing happens with R
2.15 devel v57866.
bye
Mark
Mark Bravington
CSIRO CMIS
Marine Lab
Hobart
Australia
#
# Start a basic R session, and then:
search()
[1] ".GlobalEnv""package:stats4""package:splines" "package:stats"
"package:graphics"
[6] "package:grDevices" "package:utils" "package:datasets" "package:methods"
"Autoloads" "package:base"
print( load( "nf1.rda")) # which should implicitly load VGAM, but not attach it
[1] "nf1"
search()
# ...snipped. No explicit VGAM
loadedNamespaces()
# ...snipped. VGAM is there at the end.
nf1
Call:
vglm(formula = form, family = posbinomial, data = data, trace = TRUE)
Coefficients:
# ...snipped. The print() or show() or whatever method seems to get called OK
summary( nf1)
Length Class Mode
1 vglm S4
# Hmmm... default method is being called, that's wrong. Try explicitly
attaching 'VGAM':
library( VGAM)
Loading required package: splines
Loading required package: stats4
Attaching package: 'VGAM'
The following object(s) are masked from 'package:splines':
bs, ns
The following object(s) are masked from 'package:stats':
biplot, case.names, coefficients, df.residual, fitted, fitted.values,
formula, poly, residuals,
variable.names, weights
The following object(s) are masked from 'package:base':
identity, print, scale.default
summary( nf1)
Length Class Mode
1 vglm S4
# Hmmm... even though VGAM is on the search path etc, the wrong method is being
called
###
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] inconsistent overflow handling by strtoi() on 32-bit Windows
Using the precompiled R 2.14.1 on 32-bit Windows XP strtoi(x)
gives 2^31-1 for x>2^31-1 but NA when x goes out of range
in the negative direction:
> x <- c("2147483646", "2147483647", "2147483648", "2147483649")
> str(strtoi(x))
int [1:4] 2147483646 2147483647 2147483647 2147483647
> str(strtoi(sprintf("-%s", x)))
int [1:4] -2147483646 -2147483647 NA NA
> sessionInfo()
R version 2.14.1 (2011-12-22)
Platform: i386-pc-mingw32/i386 (32-bit)
locale:
[1] LC_COLLATE=English_United States.1252
[2] LC_CTYPE=English_United States.1252
[3] LC_MONETARY=English_United States.1252
[4] LC_NUMERIC=C
[5] LC_TIME=English_United States.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
On 64-bit Linux overflow in the either direction gives NA.
Bill Dunlap
Spotfire, TIBCO Software
wdunlap tibco.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] S4 summary method not being called (VGAM)
All maintainers of CRAN packages which produced such a report were asked
for an update a week or so ago. Several have already done so.
The remaining list is
DMwR FAiR VGAM arm arulesSequences dcmle depmixS4 flip mirt spacom tlemix
On 10/01/2012 16:43, John Chambers wrote:
A relevant report, not just for VGAM but for maintainers of other
packages that define methods for functions that have both generic and
non-generic versions in other packages.
The problem is that VGAM "Depends" on stats4 but does not import from
it. So when VGAM is loaded, only the old version of summary() is
available. Importing the relevant functions from stats4 in VGAM should
fix the problem.
With the current R 2.14.1 this happens silently. With the latest
r-devel, the installation of VGAM produces a warning:
"Functions for exporting methods must have been made generic, explicitly
or implicitly; not true when loading 'VGAM' for 'AIC', 'coef', 'logLik',
'plot', 'summary', 'vcov' "
This implies (a bit obscurely) that the package has generic versions in
its dependencies, but has not imported them.
Maintainers of CRAN packages should check installation against the
development version. Warning messages like this suggest a problem with
the imports.
John
On 1/9/12 5:05 PM, mark.braving...@csiro.au wrote:
The symptom triggering this email is that an S4 summary method
sometimes refuses to be invoked, even when a package is explicitly
loaded, if the first load of the package is implicit. It may or may
not be specific to 'summary' methods and/or the 'VGAM' package. I've
sent to R-devel because (i) it looks like some kind of bug to me, but
I'm not sure; (ii) it's not something I personally need any help with;
and (iii) it seems a bit specialized for R-help.
Here's the case notes. I have an object 'nf1' of S4 class 'vglm',
created by calling 'vglm(...)' from package 'VGAM' (you can create
your own from the examples in VGAM). It's save()d into a file
"nf1.rda". If I start a new R session, call 'library( VGAM)', and then
'load("nf1.rda")', then 'summary(nf1)' works fine. But if instead I
start a pretty basic R session and load() the file *without* having
explicitly called library( VGAM), the summary method for 'vglm'
doesn't get called whether or not I subsequently call library( VGAM).
Transcript below.
I'm using R 2.13.2 on Windows XP, VGAM 0.8-4. The same thing happens
with R 2.15 devel v57866.
bye
Mark
Mark Bravington
CSIRO CMIS
Marine Lab
Hobart
Australia
#
# Start a basic R session, and then:
search()
[1] ".GlobalEnv" "package:stats4" "package:splines" "package:stats"
"package:graphics"
[6] "package:grDevices" "package:utils" "package:datasets"
"package:methods" "Autoloads" "package:base"
print( load( "nf1.rda")) # which should implicitly load VGAM, but not
attach it
[1] "nf1"
search()
# ...snipped. No explicit VGAM
loadedNamespaces()
# ...snipped. VGAM is there at the end.
nf1
Call:
vglm(formula = form, family = posbinomial, data = data, trace = TRUE)
Coefficients:
# ...snipped. The print() or show() or whatever method seems to get
called OK
summary( nf1)
Length Class Mode
1 vglm S4
# Hmmm... default method is being called, that's wrong. Try explicitly
attaching 'VGAM':
library( VGAM)
Loading required package: splines
Loading required package: stats4
Attaching package: 'VGAM'
The following object(s) are masked from 'package:splines':
bs, ns
The following object(s) are masked from 'package:stats':
biplot, case.names, coefficients, df.residual, fitted, fitted.values,
formula, poly, residuals,
variable.names, weights
The following object(s) are masked from 'package:base':
identity, print, scale.default
summary( nf1)
Length Class Mode
1 vglm S4
# Hmmm... even though VGAM is on the search path etc, the wrong method
is being called
###
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Brian D. Ripley, rip...@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, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Updated Windows toolchain
On Mon, Nov 28, 2011 at 11:56 PM, Prof Brian Ripley wrote: > An updated toolchain is now being used for Windows' builds of R-devel: > details are in the R-admin manual and at > http://www.murdoch-sutherland.com/Rtools/ and > http://www.stats.ox.ac.uk/pub/Rtools/ > Thanks for the update. I saw that http://cran.r-project.org/bin/windows/Rtools/VERSION.txt had the following contents: Rtools version 2.15.0.1911 So I downloaded Rtools215.exe but when I installed it, the VERSION.txt that was extracted read: Rtools version 2.15.0.1908 ...which is the same version I previously had installed. Has the new version not propagated yet or is there some other issue? Thanks, Dan > Both 32- and 64-bit parts of the toolchain use v2.0.1 of the Mingw-w64 > project's runtime and a beta of gcc 4.5.4: the Mingw.org project's builds > are no longer used. This should mean that code which compiles for 64-bit > Windows also compiles for 32-bit Windows, and v.v. unless code makes > (incorrect but common) assumptions that pointers fit into longs. > > A very few packages will need modifications because they contain > declarations which clash with the headers in this toolchain: where we are > aware of problems the maintainers have been informed. > > At DLL level different Windows' toolchains should be compatible: at C level > they mostly are but at C++ level they are pretty much incompatible (so that > for example GDAL has to be re-compiled for every toolchain: and Rcpp users > need to be careful to use only one toolchain for Rcpp and their packages). > All the external software previously made available (and more) is made > available at http://www.stats.ox.ac.uk/pub/Rtools . > > The toolchain has support for OpenMP and pthreads: however OpenMP support is > not enabled by default in R (it is too slow to be much use). If you do make > use of it in your packages, be aware that you will need to ship the > appropriate pthreads DLL(s). > > It is expected that there will be several further minor updates prior to the > release of 2.15.0 in ca 4 months, but this step is the major one. > > -- > Brian D. Ripley, rip...@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 > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Updated Windows toolchain
On 10.01.2012 18:51, Dan Tenenbaum wrote: On Mon, Nov 28, 2011 at 11:56 PM, Prof Brian Ripley wrote: An updated toolchain is now being used for Windows' builds of R-devel: details are in the R-admin manual and at http://www.murdoch-sutherland.com/Rtools/ and http://www.stats.ox.ac.uk/pub/Rtools/ Thanks for the update. I saw that http://cran.r-project.org/bin/windows/Rtools/VERSION.txt had the following contents: Rtools version 2.15.0.1911 So I downloaded Rtools215.exe but when I installed it, the VERSION.txt that was extracted read: Rtools version 2.15.0.1908 ...which is the same version I previously had installed. Has the new version not propagated yet or is there some other issue? Looks like it failed. I just checked the original sources and CRAN and the versions differ. We will take care soon. Uwe Thanks, Dan Both 32- and 64-bit parts of the toolchain use v2.0.1 of the Mingw-w64 project's runtime and a beta of gcc 4.5.4: the Mingw.org project's builds are no longer used. This should mean that code which compiles for 64-bit Windows also compiles for 32-bit Windows, and v.v. unless code makes (incorrect but common) assumptions that pointers fit into longs. A very few packages will need modifications because they contain declarations which clash with the headers in this toolchain: where we are aware of problems the maintainers have been informed. At DLL level different Windows' toolchains should be compatible: at C level they mostly are but at C++ level they are pretty much incompatible (so that for example GDAL has to be re-compiled for every toolchain: and Rcpp users need to be careful to use only one toolchain for Rcpp and their packages). All the external software previously made available (and more) is made available at http://www.stats.ox.ac.uk/pub/Rtools . The toolchain has support for OpenMP and pthreads: however OpenMP support is not enabled by default in R (it is too slow to be much use). If you do make use of it in your packages, be aware that you will need to ship the appropriate pthreads DLL(s). It is expected that there will be several further minor updates prior to the release of 2.15.0 in ca 4 months, but this step is the major one. -- Brian D. Ripley, rip...@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, UKFax: +44 1865 272595 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Updated Windows toolchain
On 10/01/2012 12:51 PM, Dan Tenenbaum wrote: On Mon, Nov 28, 2011 at 11:56 PM, Prof Brian Ripley wrote: > An updated toolchain is now being used for Windows' builds of R-devel: > details are in the R-admin manual and at > http://www.murdoch-sutherland.com/Rtools/ and > http://www.stats.ox.ac.uk/pub/Rtools/ > Thanks for the update. I saw that http://cran.r-project.org/bin/windows/Rtools/VERSION.txt had the following contents: Rtools version 2.15.0.1911 So I downloaded Rtools215.exe but when I installed it, the VERSION.txt that was extracted read: Rtools version 2.15.0.1908 ...which is the same version I previously had installed. Has the new version not propagated yet or is there some other issue? I see 2.15.0.1911 in the original of that file, but the file on the Canadian mirror is the 1908 version (not current). Not sure how that happened; it might just be really bad luck in the update timing. I'll wait until tomorrow to see if things clear themselves up automatically. Duncan Murdoch Thanks, Dan > Both 32- and 64-bit parts of the toolchain use v2.0.1 of the Mingw-w64 > project's runtime and a beta of gcc 4.5.4: the Mingw.org project's builds > are no longer used. This should mean that code which compiles for 64-bit > Windows also compiles for 32-bit Windows, and v.v. unless code makes > (incorrect but common) assumptions that pointers fit into longs. > > A very few packages will need modifications because they contain > declarations which clash with the headers in this toolchain: where we are > aware of problems the maintainers have been informed. > > At DLL level different Windows' toolchains should be compatible: at C level > they mostly are but at C++ level they are pretty much incompatible (so that > for example GDAL has to be re-compiled for every toolchain: and Rcpp users > need to be careful to use only one toolchain for Rcpp and their packages). >All the external software previously made available (and more) is made > available at http://www.stats.ox.ac.uk/pub/Rtools . > > The toolchain has support for OpenMP and pthreads: however OpenMP support is > not enabled by default in R (it is too slow to be much use). If you do make > use of it in your packages, be aware that you will need to ship the > appropriate pthreads DLL(s). > > It is expected that there will be several further minor updates prior to the > release of 2.15.0 in ca 4 months, but this step is the major one. > > -- > Brian D. Ripley, rip...@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, UKFax: +44 1865 272595 > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] serializing recordedplot object
On Tue, Jan 10, 2012 at 6:17 AM, Simon Urbanek wrote: > Unfortunately R doesn't provide a way for this. Without changes to > unserialization (on the wishlist for a few years now, but not easy to design) > the best you can do is to check the native symbols for NULL pointers on usage > and then re-fetch - that's something that could be done reasonably easily, > although it's still a hack ... Hmm that concerns me a bit. I make heavy use of saveRDS and readRDS in my framework and have assumed that for all practical purposes most objects can be saved to disk and loaded later on without problems. Are there any other types of objects that are not being serialized-unserialized to a state where they are functional again? In the case of the NativeSymbolInfo object, it should not be too hard to add an optional feature to unserialize which reloads the package and NativeSymbolInfo when it runs into nullpointers during unserialization? I am currently doing this manually after the unserialization, but that introduces quite some overhead. Thanks, Jeroen __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] serializing recordedplot object
On Jan 10, 2012, at 4:12 PM, Jeroen Ooms wrote: > On Tue, Jan 10, 2012 at 6:17 AM, Simon Urbanek > wrote: >> Unfortunately R doesn't provide a way for this. Without changes to >> unserialization (on the wishlist for a few years now, but not easy to >> design) the best you can do is to check the native symbols for NULL pointers >> on usage and then re-fetch - that's something that could be done reasonably >> easily, although it's still a hack ... > > Hmm that concerns me a bit. I make heavy use of saveRDS and readRDS in > my framework and have assumed that for all practical purposes most > objects can be saved to disk and loaded later on without problems. Are > there any other types of objects that are not being > serialized-unserialized to a state where they are functional again? > No, AFAIR just external pointers (and weak references I presume). There is simply no way to serialize them, because by definition such objects are transient and only present in the running process. They lose meaning the moment the process is terminated. > In the case of the NativeSymbolInfo object, it should not be too hard > to add an optional feature to unserialize which reloads the package > and NativeSymbolInfo when it runs into nullpointers during > unserialization? I am currently doing this manually after the > unserialization, but that introduces quite some overhead. > You could hard-code a special case of NativeSymbolInfo into R itself, but there are many other uses of external pointers in packages. The practical problem is that by definition you have no way of knowing which code will be able to unserialize a given external pointer. The fact that it is wrapped in a class is quite irrelevant to the pointer itself which doesn't know that. And conversely the class itself doesn't know that it may contain an external pointer - it's just a vanilla structure and you can't feasibly run a method on every single object you unserialize just to find out. Also you would need a special way of creating some raw byte stream that represents the state of the external pointer - apart from the regular serialization. That's why the current "solution" is that code using external pointers checks for NULL pointers and attempts to deal with that by inferring whether it can restore it or not from the information available (which is not always possible). Cheers, Simon __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] serializing recordedplot object
On 01/10/2012 02:54 PM, Simon Urbanek wrote: On Jan 10, 2012, at 4:12 PM, Jeroen Ooms wrote: On Tue, Jan 10, 2012 at 6:17 AM, Simon Urbanek wrote: Unfortunately R doesn't provide a way for this. Without changes to unserialization (on the wishlist for a few years now, but not easy to design) the best you can do is to check the native symbols for NULL pointers on usage and then re-fetch - that's something that could be done reasonably easily, although it's still a hack ... Hmm that concerns me a bit. I make heavy use of saveRDS and readRDS in my framework and have assumed that for all practical purposes most objects can be saved to disk and loaded later on without problems. Are there any other types of objects that are not being serialized-unserialized to a state where they are functional again? No, AFAIR just external pointers (and weak references I presume). There is simply no way to serialize them, because by definition such objects are transient and only present in the running process. They lose meaning the moment the process is terminated. Maybe obvious so I won't waste public bandwidth, but opened connections of all sorts (e.g., to data bases) and [to be explicit] references to c / c++ (probably many packages using Rcpp produce these) objects. Martin In the case of the NativeSymbolInfo object, it should not be too hard to add an optional feature to unserialize which reloads the package and NativeSymbolInfo when it runs into nullpointers during unserialization? I am currently doing this manually after the unserialization, but that introduces quite some overhead. You could hard-code a special case of NativeSymbolInfo into R itself, but there are many other uses of external pointers in packages. The practical problem is that by definition you have no way of knowing which code will be able to unserialize a given external pointer. The fact that it is wrapped in a class is quite irrelevant to the pointer itself which doesn't know that. And conversely the class itself doesn't know that it may contain an external pointer - it's just a vanilla structure and you can't feasibly run a method on every single object you unserialize just to find out. Also you would need a special way of creating some raw byte stream that represents the state of the external pointer - apart from the regular serialization. That's why the current "solution" is that code using external pointers checks for NULL pointers and attempts to deal with that by inferring whether it can restore it or not from the information available (which is not always possible). Cheers, Simon __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel -- Computational Biology Fred Hutchinson Cancer Research Center 1100 Fairview Ave. N. PO Box 19024 Seattle, WA 98109 Location: M1-B861 Telephone: 206 667-2793 __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
