search for: patperry

...la3/show_bug.cgi?id=16278 , but my report may have fallen through the cracks due to the timing around the 3.2.0 release. The bug was introduced in the patch displayed here: https://github.com/wch/r-source/commit/32f633885a903bc422537dc426644f743cc645e0 The fix is very simple: https://github.com/patperry/r-source/commit/c1701c05ad91d5631eef196c2007ad9897b01f85 I?ve posted a script that demonstrates the bug at https://gist.github.com/patperry/90a388b056e09cf6a51b Please let me know if there?s anything I can do to help get this fix incorporated. -- Patrick Perry Assistant Professor Stern School...

...l-defined for realloc (it should free the memory). Based on my failing CRAN tests, it looks like this is a Linux-specific issue. Is there a way to modify my Makevars to force the linker to choose my version of xrealloc for my package-specific code? My current Makevars are at https://github.com/patperry/r-corpus/blob/master/src/Makevars Thanks in advance for any help. Patrick [[alternative HTML version deleted]]

...here something wrong with the way I'm compiling my package on that platform? Is this just some quirk about the way R is loading dynamic libraries on Linux? I'd appreciate any insight into the issue. Patrick p.s. Here are some references: My package Makevars are at https://github.com/patperry/r-corpus/blob/master/src/Makevars ; my version of "xrealloc" is in corpus/src/xalloc.c You can see the source for the libreadline xrealloc at https://github.com/JuliaLang/readline/blob/master/xmalloc.c#L67 Patrick Perry wrote: > > I have a package on CRAN now (corpus-0.3.1) tha...

...t may have fallen through the cracks due to the timing around the 3.2.0 release. > > The bug was introduced in the patch displayed here: > > https://github.com/wch/r-source/commit/32f633885a903bc422537dc426644f743cc645e0 > > The fix is very simple: > > https://github.com/patperry/r-source/commit/c1701c05ad91d5631eef196c2007ad9897b01f85 > > I?ve posted a script that demonstrates the bug at > > https://gist.github.com/patperry/90a388b056e09cf6a51b > > Please let me know if there?s anything I can do to help get this fix incorporated. > > > -- &g...

On 11 May 2017 at 12:16, Patrick Perry wrote: | I've done a bit more investigation into this issue. Here is my current | understanding of the situation: | | 1. I have a package on CRAN (corpus-0.3.1) that passes tests on all | platforms except for Linux. | 2. My package defines a C function, "xrealloc", for internal use. | 3. The libreadline library that R links to defines a

...d42aaf44a879cac0fc31fa4 . This causes the CRAN checks for the "corpus" package to emit a warning: https://www.r-project.org/nosvn/R.check/r-devel-linux-x86_64-fedora-clang/corpus-00check.html . The offending code is in an upstream library bundled with the package: https://github.com/patperry/corpus/blob/master/src/table.c#L118 #pragma GCC diagnostic push #pragma GCC diagnostic ignored "-Wtype-limits" // gcc emits a warning if sizeof(size_t) > sizeof(unsigned) if ((size_t)size > SIZE_MAX / sizeof(*items)) { #pragma GCC diagnostic pop This is code app...

...ing around the > 3.2.0 release. > > > > The bug was introduced in the patch displayed here: > > > > > https://github.com/wch/r-source/commit/32f633885a903bc422537dc426644f743cc645e0 > > > > The fix is very simple: > > > > > https://github.com/patperry/r-source/commit/c1701c05ad91d5631eef196c2007ad9897b01f85 > > > > I?ve posted a script that demonstrates the bug at > > > > https://gist.github.com/patperry/90a388b056e09cf6a51b > > > > Please let me know if there?s anything I can do to help get this fix > inco...

...s causes the CRAN checks for the "corpus" package to emit a > warning: > > https://www.r-project.org/nosvn/R.check/r-devel-linux-x86_64-fedora-clang/corpus-00check.html > . > > The offending code is in an upstream library bundled with the package: > https://github.com/patperry/corpus/blob/master/src/table.c#L118 > > #pragma GCC diagnostic push > #pragma GCC diagnostic ignored "-Wtype-limits" > // gcc emits a warning if sizeof(size_t) > sizeof(unsigned) > > if ((size_t)size > SIZE_MAX / sizeof(*items)) { > #pragma GCC...

Thank you!. My apologies again for not including the console output in my message before. I sent another e-mail with the output in the meantime, so it should be a bit clearer now, what I am seeing. In case I missed something, please let me know. Yes, I am using latin1 and cp1252 interchangebly here, mostly because Encoding() is reporting the encoding as "latin1". You presumed correctly

This is a follow-up on my initial posts regarding character encodings on Windows (https://stat.ethz.ch/pipermail/r-devel/2017-August/074728.html) and Patrick Perry's reply (https://stat.ethz.ch/pipermail/r-devel/2017-August/074830.html) in particular (thank you for the links and the bug report!). My initial posts were quite chaotic (and partly wrong), so I am trying to clear things up a

On 21 May 2015, at 12:49 , Martin Maechler <maechler at lynne.stat.math.ethz.ch> wrote: >>>>>> peter dalgaard <pdalgd at gmail.com> >>>>>> on Thu, 21 May 2015 11:03:05 +0200 writes: > >> On 21 May 2015, at 10:35 , Martin Maechler <maechler at lynne.stat.math.ethz.ch> wrote: > >>>> >>>> I noticed that