Re: [Rd] Using long long types in C++
I've been trying desperately to unsubscribe from this. Not that I don't like R; but I only wanted help and then ended up on this email list. I've put in more than one request to unsubscribe. On Thu, Sep 19, 2013 at 7:31 PM, Patrick Welche wrote: > On Fri, Sep 20, 2013 at 12:51:52AM +0200, rom...@r-enthusiasts.com wrote: > > In Rcpp we'd like to do something useful for types such as long long > > and unsigned long long. > ... > > But apparently this is still not enough and on some versions of gcc > > (e.g. 4.7 something), -pedantic still generates the warnings unless > > we also use -Wno-long-long > > Can you also add -std=c++0x or is that considered as bad as adding > -Wno-long-long? > > (and why not use autoconf's AC_TYPE_LONG_LONG_INT and > AC_TYPE_UNSIGNED_LONG_LONG_INT for the tests?) > > Cheers, > > Patrick > > __ > R-devel@r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel > [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Vignette problem and CRAN policies
take me off here
On Mon, Sep 23, 2013 at 4:44 PM, Marc Schwartz wrote:
> Spencer,
>
> FYI. I just noted in your post below the error message from WriteXLS
> regarding TEXT::CSV_XS missing.
>
> Please note that in version >=3.0 of WriteXLS (current is 3.2.1), that is
> no longer required and has been replaced by Text::CSV_PP, which is a Pure
> Perl module and is included in the WriteXLS CRAN package to reduce the
> dependencies on nonstandard external Perl modules.
>
> Regards,
>
> Marc Schwartz
>
>
> On Sep 23, 2013, at 4:28 PM, Spencer Graves
> wrote:
>
> > Hello, All:
> >
> >
> > Professor Ripley is correct as usual: I misunderstood his original
> statement of the problem.
> >
> >
> > He gave two possible solutions. I could not make the first
> solution work, and I didn't try the second until someone else on this list
> explained it in slightly more detail.
> >
> >
> > The correction passed R CMD check on my local computer. It has
> been "building" on R-Forge since 2013-09-20 19:19:14+02. I hope this
> completes soon enough for me to meet Ripley's Sept. 25 deadline for this
> correction to "sos".
> >
> >
> > Thanks again to Prof. Ripley and everyone else who took the time to
> read my post.
> >
> >
> > Spencer
> >
> >
> > On 9/19/2013 12:00 AM, Prof Brian Ripley wrote:
> >> This is nothing to do with CRAN policies (nor R).
> >>
> >> The issue is that the current upquote.sty does not play with 'ae' fonts
> as used by default by Sweave. The change is in TeX.
> >>
> >> And that was what Spencer Graves was informed.
> >>
> >>
> >> On 19/09/2013 04:35, Spencer Graves wrote:
> >>> Hello, All:
> >>>
> >>>
> >>> The vignette with the sos package used "upquote.sty", required
> >>> for R Journal when it was published in 2009. Current CRAN policy
> >>> disallows "upquote.sty", and I've so far not found a way to pass "R CMD
> >>> check" with sos without upquote.sty.
> >>>
> >>>
> >>> I changed sos.Rnw per an email exchange with Prof. Ripley without
> >>> solving the problem; see below. The key error messages (see the
> results
> >>> of "R CMD build" below) appear to be "sos.tex:16: LaTeX Error:
> >>> Environment article undefined" and " sos.tex:558: LaTeX Error:
> >>> \begin{document} ended by \end{article}." When the article worked, it
> >>> had bot \begin{document} and \begin{article}, with matching \end
> >>> statements for both. I've tried commenting out either without success.
> >>>
> >>>
> >>> The current nonworking code is available on R-Forge via anonymous
> >>> SVN checkout using "svn checkout
> >>> svn://svn.r-forge.r-project.org/svnroot/rsitesearch/". Any suggestions
> >>> on how to fix this would be greatly appreciated.
> >>>
> >>>
> >>>Thanks,
> >>>Spencer
> >>>
> >>>
> >>> ## COMPLETE RESULTS FROM R CMD check
> >>>
> >>>
> >>> Microsoft Windows [Version 6.1.7600]
> >>> Copyright (c) 2009 Microsoft Corporation. All rights reserved.
> >>>
> >>> C:\Users\sgraves>cd 2013
> >>> C:\Users\sgraves\2013>cd R_pkgs
> >>> C:\Users\sgraves\2013\R_pkgs>cd sos
> >>> C:\Users\sgraves\2013\R_pkgs\sos>cd pkg
> >>> C:\Users\sgraves\2013\R_pkgs\sos\pkg>R CMD build sos
> >>> * checking for file 'sos/DESCRIPTION' ... OK
> >>> * preparing 'sos':
> >>> * checking DESCRIPTION meta-information ... OK
> >>> * installing the package to re-build vignettes
> >>> * creating vignettes ... ERROR
> >>> Loading required package: brew
> >>>
> >>> Attaching package: 'sos'
> >>>
> >>> The following object is masked from 'package:utils':
> >>>
> >>> ?
> >>>
> >>> Loading required package: WriteXLS
> >>> Perl found.
> >>>
> >>> The following Perl modules were not found on this system:
> >>>
> >>> Text::CSV_XS
> >>>
> >>> If you have more than one Perl installation, be sure the correct one
> was
> >>> used he
> >>> re.
> >>>
> >>> Otherwise, please install the missing modules. See the package INSTALL
> >>> file for
> >>> more information.
> >>>
> >>> Loading required package: RODBC
> >>> Warning in odbcUpdate(channel, query, mydata, coldata[m, ], test =
> test, :
> >>>character data 'Adrian Baddeley and
> >>> Rolf Turner
> >>> with substantial contributions of code by
> >>> Kasper Klitgaard Berthelsen;Abdollah Jalilian; Marie-Colette van
> Liesho
> >>> ut; Ege Rubak; Dominic Schuhmacher;and Rasmus
> >>> Waagepetersen.
> >>> Additional contributionsby Q.W. Ang;S. Azaele; C. Beale;
> >>> R. Bernhardt; T. Bendtsen;A. Bevan; B. Biggerstaff; R.
> Bivan
> >>> d; F. Bonneu; J. Burgos; S. Byers; Y.M. Chang;
> J.B.
> >>> Che
> >>> n; I. Chernayavsky;Y.C. Chin; B. Christensen; J.-F.
> Co
> >>> eurjolly; R. Corria Ainslie; M. de la Cruz; P. Dalgaard;
> >>> P.J. Dig
> >>> gle;P. Donnelly;I. Dryden; S. Eglen; O. Flores; N.
> >>> Funwi-Gabga;
> >>> A. Gault; M. Genton; J. Gilbey; J. Goldstick;
> >>> P. Graba
> >>> rnik; C.
Re: [Rd] inconsistency/bug in recordPlot/replayPlot
take me off here
On Mon, Sep 23, 2013 at 10:31 PM, Gabriel Becker wrote:
> Paul,
>
> Thanks for the response.
>
>
> On Mon, Sep 23, 2013 at 7:43 PM, Paul Murrell >wrote:
>
> >
> > par(bg="white")
> >
> > plot(1:10)
> > recplot = recordPlot()
> > png("bgreplay.png")
> > replayPlot(recplot)
> > dev.off()
> >
> > Would that satisfy your use case ?
> >
>
> Unfortunately it does not, as my use-case is in a caching/dynamic document
> setting. Thus I am capturing plotting from evaluation of an arbitrary piece
> of code within a series of such evaluations. I cannot be guaranteed the
> code doesn't call dev.off() or explicitly create a new device and I
> wouldn't want to clobber any non-white background set in previous code.
>
> I thought putting par(bg="white") after the call to png() (or bg="white" in
> the png call) might work, but it appears that replayPlot is actively
> setting the background to transparent so that didn't fly.
>
> Any other ideas or advice would be appreciated.
> ~G
>
>
> >
> > Paul
> >
> >
> > On 09/14/13 09:17, Gabriel Becker wrote:
> >
> >> Hey all,
> >>
> >> I've run accross what seems to be a bug in the recordPlot/replayPlot
> >> functionality (or at least the lack of a feature which seems pretty
> >> reasonable to expect to be there)
> >>
> >> When drawing to a file-based graphics device (I tested with png()), the
> >> file resulting from calling replayPlot on a recordedplot object does not
> >> contain an identical image to that captured by the same graphics device
> >> when used on the plot that was recorded.
> >>
> >> Reproducible (at least for me on linux) example:
> >>
> >> png("noreplay.png")
> >> plot(1:10)
> >> dev.off()
> >>
> >> plot(1:10)
> >> recplot = recordPlot()
> >> png("withreplay.png")
> >> replayPlot(recplot)
> >> dev.off()
> >>
> >> The resulting png files are attached. You'll notice that the
> noreplay.png
> >> has the expected white background, while withoutreplay.png has no/a
> >> transparent background.
> >>
> >> This seems likely to be related to the note in ?dev.print :
> >> "
> >> Note that these functions copy the _device region_ and not a plot:
> >> the background colour of the device surface is part of what is
> >> copied. Most screen devices default to a transparent background,
> >> which is probably not what is needed when copying to a device such
> >> as png.
> >> "
> >>
> >> Now this may be as intended because it is "not allowed" to draw
> >> recordedplot objects to devices other than the one they were recorded on
> >> (AFAIK the primary purpose of recordedplot objects is fast redraws
> >> internally), but alas that is what my use-case calls for. Furthermore,
> I
> >> don't think I'm alone in thinking wistfully about how useful it would be
> >> to
> >> have an actual, transportable object class which can fully represent an
> R
> >> plot in any R-based context.
> >>
> >> I'm pretty sure I can compile a patch which does this if it would be
> >> considered, though there would be a delay of a week or two before I
> could
> >> burrow out from under the mound of other stuff I currently need to be
> >> doing
> >>
> >> sessionInfo below, and I have also confirmed that the behavior remains
> >> unchanged in the current trunk.
> >>
> >> Thanks,
> >> ~G
> >>
> >> sessionInfo()
> >>>
> >> R version 3.0.1 (2013-05-16)
> >> Platform: x86_64-pc-linux-gnu (64-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
> >>
> >> loaded via a namespace (and not attached):
> >> [1] compiler_3.0.1 tools_3.0.1
> >>
> >>
> >>
> >> __**
> >> R-devel@r-project.org mailing list
> >> https://stat.ethz.ch/mailman/**listinfo/r-devel<
> https://stat.ethz.ch/mailman/listinfo/r-devel>
> >>
> >>
> > --
> > Dr Paul Murrell
> > Department of Statistics
> > The University of Auckland
> > Private Bag 92019
> > Auckland
> > New Zealand
> > 64 9 3737599 x85392
> > p...@stat.auckland.ac.nz
> > http://www.stat.auckland.ac.**nz/~paul/<
> http://www.stat.auckland.ac.nz/~paul/>
> >
>
>
>
> --
> Gabriel Becker
> Graduate Student
> Statistics Department
> University of California, Davis
>
> [[alternative HTML version deleted]]
>
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>
>
[[alternative HTML version deleted]]
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
