On Thu, 4 Jul 2024 at 11:44, Ivan Krylov via R-devel
wrote:
> Hello R-devel,
>
> I would like to suggest a couple of updates for the R FAQ.
>
> https://CRAN.R-project.org/bin/linux/suse is currently empty and the
> directory has mtime from 2012, so it probably doesn't help to reference
> it in FA
so available as
>
> https://github.com/r-devel/r-svn/commit/f7c46500f455eb4edfc3656c3fa20af61b16abb7
>
> Dirk
>
> | (or 86238 for the port to the release branch) should be easily
> backported.
> |
> | (CC Luke in case there is more to it)
> |
> | - pd
> |
> | > On
Dear R-core,
I just received notification of CVE-2024-27322 [1] in RedHat's Bugzilla. We
updated R to v4.4.0 in Fedora rawhide, F40, EPEL9 and EPEL8, so no problem
there. However, F38 and F39 will stay at v4.3.3, and I was wondering if
there's a specific patch available, or if you could point me t
On Wed, 1 Nov 2023 at 12:57, Tomas Kalibera wrote:
>
>
> On 10/31/23 10:45, Iñaki Ucar wrote:
> > On Tue, 24 Oct 2023 at 12:53, Tomas Kalibera
> > wrote:
> >> The output of session info is based on that flexiblas is used and on
> >> what flexiblas tel
On Tue, 24 Oct 2023 at 12:53, Tomas Kalibera wrote:
>
> The output of session info is based on that flexiblas is used and on
> what flexiblas tells R is the backend it uses. R does not attempt to
> check that optimized LAPACK functions from the backend really end up
> called via flexiblas, and I d
El lun., 30 oct. 2023 12:26, Roger Bivand escribió:
> I also noticed this:
>
> https://www.theregister.com/2023/10/13/gnome_proposes_dropping_x11/
>
> which is concerning. Until now, I've retained X11 on Fedora because of
> difficulties in screen sharing via zoom in Wayland sessions.
>
KDE Plasm
Hi,
Not sure if this is the right place for this. The "R Installation and
Administration" guide states:
> Apparently undocumented: FlexiBLAS on Fedora provides a complete LAPACK, but
> not the enhanced routines from ATLAS or OpenBLAS.
I'm not sure what this means. FlexiBLAS does provide 100% of
I think r-package-devel is a better place for this. CC'ing there.
On Sun, 27 Aug 2023 at 23:50, Mike Marchywka wrote:
>
> I was curious what R packages, or indeed any other applications, exist
> to plot streamed data from arbitrary data generators. It need not
> be publication quality plotting bu
On Thu, 29 Jun 2023 at 01:34, Carl Boettiger wrote:
>
> Thanks Simon, I was very much hoping that would be the case! It may
> be that I just need to put the version requirement on 4.0 then. I
> will be sure to add this version restriction to my packages (which
> technically I should be doing any
On Sun, 16 Apr 2023 at 12:58, nos...@altfeld-im.de wrote:
>
> I am the author of the *tryCatchLog* package and want to
>
> - suppress selected conditions (warnings and messages)
> - rethrow selected conditions (e.g a specific warning as a message or to
> "rename" the condition text).
>
> I could
Hi,
Just a heads-up that curl 8 landed in Fedora Rawhide a couple of days
ago. Note that R does **not** compile without a small fix [1] that
allows the configuration to continue if the major version is > 7.
[1] https://src.fedoraproject.org/rpms/R/blob/rawhide/f/R-4.2.3-curl-v8.patch
Best,
--
I
On Wed, 8 Feb 2023 at 19:59, Henrik Bengtsson
wrote:
>
> I just want to add a few reasons that I know of for why users are
> still on Red Hat/CentOS 7 and learned from being deeply involved with
> big academic and research high-performance compute (HPC) environments.
> These systems are not like y
On Wed, 8 Feb 2023 at 07:05, Prof Brian Ripley wrote:
>
> On 08/02/2023 00:13, Gábor Csárdi wrote:
> > As preparation for the next release, I am trying to compile R devel on
> > RHEL / CentOS 7, which is still supported by RedHat until 2024 June.
True, but with a big asterisk. Full updates ended
El mar., 27 sept. 2022 18:42, Blätte, Andreas
escribió:
> Dear all,
>
> my apologies for a dull question. I think I do understand that unnoticed
> Internet access requires scrutiny and a more explicit approach.
>
> But I am not sure how this would impact on the practice on many Windows
> machines
El mar., 27 sept. 2022 4:22, Dirk Eddelbuettel escribió:
>
> Regarding 'system' libraries: Packages like stringi and nloptr download the
> source of, respectively, libicu or libnlopt and build a library _if_ the
> library is not found locally. If we outlaw this, more users may hit a
> brick
> wa
s in the
> > DESCRIPTION (probably with hashes), that's a big improvement over the
> > current state of things, in which basically we don't know what the
> > package tries download, then it may fail, and finally there's no
> > guarantee that it's what the autho
On Mon, 26 Sept 2022 at 21:50, Simon Urbanek
wrote:
>
> [snip]
> Sure, I fully agree that it would be a good first step, but I'm still waiting
> for examples ;).
Oh, you want me to actually name specific packages? I thought that
this was a well-established fact from your initial statement "I ful
This is e.g. how RPM
packaging works: the spec declares all the sources, they are
downloaded once, hashed and stored in a lookaside cache. Then package
building doesn't need general Internet connectivity, just access to
the cache.
Iñaki
>
> Cheers,
> Simon
>
>
> > On Sep 24, 2
On Fri, 23 Sept 2022 at 17:22, Iñaki Ucar wrote:
>
> [snip]
> Now, what if connection is suppressed during package load? There are
> basically three use cases out there:
>
> (1) The package requires additional files for the installation (e.g.
> the source code of an external
Hi all,
I'd like to open this debate here, because IMO this is a big issue.
Many packages do this for various reasons, some more legitimate than
others, but I think that this shouldn't be allowed, because it
basically means that installation fails in a machine without Internet
access (which happen
On Sun, 10 Jul 2022 at 16:28, GILLIBERT, Andre
wrote:
>
> > No, that is how computers work (with floating point numbers).
>
>
> The fact that not all values are representable by floating point does not
> mean that outputing a number with maximum accuracy, then reading it back,
> should yield a d
On Thu, 12 Aug 2021 at 22:20, Gabriel Becker wrote:
>
> Hi Toby,
>
> This definitely appears intentional, the first expression of
> stats:::na.omit.default is
>
>if (!is.atomic(object))
>
> return(object)
I don't follow your point. This only means that the *default* method
is not int
On Thu, 24 Jun 2021 at 14:21, Kurt Hornik wrote:
>
> >>>>> Deepayan Sarkar writes:
>
> > On Thu, Jun 24, 2021 at 5:31 PM Iñaki Ucar wrote:
> >>
> >> Hi,
> >>
> >> I noticed that R 4.1 places html files into the packages' h
Hi,
I noticed that R 4.1 places html files into the packages' help
directory, compared to previous versions, which used an RDS. I found a
possible bug in the code that processes the aliases from the Rd files
and generates the names for these html files (I haven't identified
where this happens thou
On Sat, 1 May 2021 at 03:41, Henrik Bengtsson
wrote:
>
> Ben, it's most like what Peter says. I can confirm it works; I just
> installed https://cran.r-project.org/src/base-prerelease/R-latest.tar.gz
> on an up-to-date CentOS 7.9.2009 system using the vanilla gcc (GCC)
> 4.8.5 that comes with tha
On Thu, 29 Apr 2021 at 15:59, Ben Bolker wrote:
>
>I probably don't want to go down this rabbit hole very far, but if
> anyone has any *quick* ideas ...
>
>Attempting to build R from scratch with a fresh SVN checkout on a
> somewhat out-of-date CentOS system (for which I don't have root ac
On Thu, 29 Apr 2021 at 14:36, Gábor Csárdi wrote:
>
> Dear all,
>
> Fedora 34 was released two days ago, and with a fresh build of R I get
>
> [root@2dba8b3587c1 R-devel]# bin/R
> ERROR: R_HOME ('/tmp/R-devel') not found
This is known. It's a docker issue after a glibc change. See [1] and
referen
On Thu, 18 Mar 2021 at 05:10, Dirk Eddelbuettel wrote:
>
>
> On 17 March 2021 at 22:53, Ben Bolker wrote:
> |Thanks. I know it's supposed to Just Work (and I definitely
> | appreciate all the work that's gone into making it Just Work 99% of the
> | time!).
>
> And for what it is worth, the af
On Thu, 21 Jan 2021 at 14:19, Sebastian Meyer wrote:
>
> Am 21.01.21 um 13:51 schrieb Iñaki Ucar:
> > Minor question: wouldn't the new pipe syntax be worth a minor version
> > bump?
>
> Yes. The NEWS mention the pipe syntax for R-devel not for R-patched.
>
>
Minor question: wouldn't the new pipe syntax be worth a minor version
bump? A package planning to drop magrittr would end up depending on R
4.0.4, which sounds suboptimal. And (I don't find any reference to
this in the manual or in CRAN policies, but) if I remember correctly,
depending on a patch v
On Tue, 12 Jan 2021 at 20:23, wrote:
>
> After some discussions we've settled on a syntax of the form
>
> mtcars |> subset(cyl == 4) |> d => lm(mpg ~ disp, data = d)
>
> to handle cases where the pipe lhs needs to be passed to an argument
> other than the first of the function called on the r
On Sun, 13 Dec 2020 at 04:27, wrote:
>
> If R is receiving a kill signal there is nothing it can do about it.
>
> I am guessing you are running into a memory over-commit issue in your OS.
> https://en.wikipedia.org/wiki/Memory_overcommitment
> https://engineering.pivotal.io/post/virtual_memory_set
On Wed, 18 Nov 2020 at 10:26, Tomas Kalibera wrote:
>
> On 11/17/20 9:34 PM, Bill Dunlap wrote:
> > I just got a new Windows laptop (i7, 10th generation CPU), installed
> > 'Windows Subsystem for Linux 2' and then installed Ubuntu 20.04 and
> > used 'apt-get install' to install packages that the R
o the R user so that they
> > might determine what is best for their potentially latency- or
> > throughput-sensitive application?
> >
> > Best,
> > Jeff
> >
> > On Mon, Nov 2, 2020 at 14:05, Iñaki Ucar wrote:
> >> On Mon, 2 Nov 2020 at 02:22, Si
On Mon, 2 Nov 2020 at 14:29, Jeff wrote:
>
> Could TCP_NODELAY and TCP_QUICKACK be exposed to the R user so that
> they might determine what is best for their potentially latency- or
> throughput-sensitive application?
I think it makes sense (with a sensible default). E.g., Julia does this [1-2].
On Mon, 2 Nov 2020 at 02:22, Simon Urbanek wrote:
>
> It looks like R sockets on Linux could do with TCP_NODELAY -- without (status
> quo):
How many network packets are generated with and without it? If there
are many small writes and thus setting TCP_NODELAY causes many small
packets to be sent
Hi,
In line 5, you are allocating a vector of length nc. Then, in line 12, you
are using nr as a limit, so if nr goes beyond nc, which is happening in
line 39, you are in trouble.
Iñaki
On Sat, 12 Sep 2020 at 03:30, Rory Nolan wrote:
> I want to write an R function using R's C interface that t
Hi Henrik,
A bit late, but you can take a look at smbache's {import} package [1]
in case you didn't know it. I believe it does what you are describing.
[1] https://github.com/smbache/import
Iñaki
On Tue, 23 Jun 2020 at 22:21, Henrik Bengtsson
wrote:
>
> Hi,
>
> I'm developing a package whose A
On Thu, 30 Apr 2020 at 02:49, Dirk Eddelbuettel wrote:
>
>
> On 29 April 2020 at 11:22, peter dalgaard wrote:
> | Hum, at least it is not Apple, so maybe you can attach a debugger to the
> running process? (gdb -p process_id or something like that --- haven't
> actually done it for a decade). Th
On Mon, 6 Apr 2020 at 04:59, Paul Murrell wrote:
>
> Hi
>
> The R branch ...
>
> https://svn.r-project.org/R/branches/R-symfam/
>
> ... is now set up so that it works "out of the box" on Fedora by setting
> the default to be 'symbolfamily=cairoSymbolFont(family, usePUA=FALSE)'
> when grSoftVersion
On Sat, 4 Apr 2020 at 11:51, Martin Maechler wrote:
>
> This is mostly a RFC [but *not* about the many extra packages, please..]:
>
> Noticing to my chagrin how my students work in a project,
> googling for R code and cut'n'pasting stuff together, accumulating
> this and that package on the way
On Tue, 31 Mar 2020 at 03:32, Paul Murrell wrote:
>
> I think R will retain the idea of a separate symbol font in at least the
> short term because of backward compatibility and cross-platform support
> and support for a range of graphics devices. So this fix is just for
> cairo-based devices on
On Mon, 30 Mar 2020 at 22:41, Paul Murrell wrote:
>
> Hi
>
> On 30/03/20 10:43 pm, Iñaki Ucar wrote:
> > On Mon, 30 Mar 2020 at 04:24, Paul Murrell wrote:
> >>
> >> Hi
> >>
> >> I have created an R branch that contains a potential fix ...
&
gt; I am starting testing an R fix for this problem today.
> >
> > As suggested, the plan is to allow the R user to specify a font family
> > other than "symbol" for plotmath output (or, more generally, in R
> > parlance, for 'font=5' or 'fontface=5'
> parlance, for 'font=5' or 'fontface=5') on a Cairo-based graphics device.
>
> Paul
>
>
> On 27/03/20 11:30 pm, Iñaki Ucar wrote:
> > On Wed, 25 Mar 2020 at 12:25, Nicolas Mailhot
> > wrote:
> >>
> >>
> >>
> >> R b
On Wed, 25 Mar 2020 at 12:25, Nicolas Mailhot
wrote:
>
>
>
> R brought this all on itself by hardcoding a Windows-only “Symbol” font
> family name in its default conf. Linux systems are UTF-8 by default for
> ~20 years now, they don’t need the forcing of magic font families to
> handle symbols no
On Wed, 25 Mar 2020 at 01:14, Gavin Simpson wrote:
>
> Dear list
>
> On Fedora 31 the pango library has recently updated to version >= 1.44
> and in doing so has switched to using the HarfBuzz library (from
> FreeType) and dropped Adobe Type 1 font support. This causes problems
> with plotmath as
On Wed, 15 Jan 2020 at 15:14, IAGO GINÉ VÁZQUEZ wrote:
>
> Hi all,
>
> Is the next behaviour suitable?
>
> identical(F,FALSE)
>
> ## [1] TRUE
>
> utils::getParseData(parse(text = "c(F,FALSE)", keep.so=rce = TRUE))
>
> ##line1 col1 line2 col2 id parenttoken terminal text
> ## 1
A bit off-topic, but...
On Wed, 15 Jan 2020 at 05:45, Abby Spurdle wrote:
>
> > Which version of Fedora are you on?
>
> I've got Fedora 31.
> I just checked, and R 3.6.2 is available now.
R 3.6.2 was submitted a month ago for testing and reached stable 19
days ago [1]. At any time, you can see w
On Tue, 14 Jan 2020 at 15:06, Siegfried Köstlmeier
wrote:
>
> Hi all,
>
> I maintain the package „qrandom“ which is based on a web API. In last time
> the testthat tests failed because the website was down.
> I implemented the following code in v1.2.2 to ensure that tests are only run
> if the web
On Sun, 12 Jan 2020 at 00:49, Henrik Bengtsson
wrote:
>
> [snip]
>
> A final plead: Adding an option to disable forking, at least in the
> 'parallel' package only, will spare people (end users, developers,
> sysadms, ...) many many hours of troubleshooting and eventually trying
> to find workaroun
On Wed, 8 Jan 2020 at 19:21, Toby Hocking wrote:
>
> Hi R-core, I was wondering if somebody could please add jsslogo.jpg to the
> R sources? (as I reported yesterday in this bug)
>
> https://bugs.r-project.org/bugzilla/show_bug.cgi?id=17687
>
> R already includes jss.cls which is the document clas
On Wed, 8 Jan 2020 at 02:05, Pages, Herve wrote:
>
> On 1/7/20 06:13, brodie gaslam via R-devel wrote:
> ...
> > Happy new decade.
>
> *** caught segfault ***
> conflicting decade boundaries
https://xkcd.com/2249/ ;-)
>
> Traceback:
> 1: new_decade <- 2020:2029
> 2: previous_decade <- 2011
You can try for testing with a column of class errors, from the package
'errors'. The attributes depend on the content in the way Hadley pointed
out.
Iñaki
El lun., 4 nov. 2019 23:19, Rolf Turner escribió:
> On 5/11/19 10:54 AM, Duncan Murdoch wrote:
> > On 04/11/2019 4:40 p.m., Pages, Herve wr
On Sun, 3 Nov 2019 at 22:12, Rolf Turner wrote:
>
>
> I recently tried to write a new method for "[", to be applied to data
> frames, so that the object returned would retain (all) attributes of the
> columns, including attributes that my code had created.
>
> I thrashed around for quite a while,
On Sun, 6 Oct 2019 at 10:30, Joris Meys wrote:
>
> I'm largely with Gabriel Becker on this one: if pipes enter base R, they
> should be a well thought out and integrated part of the language.
>
> I do see merit though in providing a pipe in base R. Reason is mainly that
> right now there's not a s
On Sat, 5 Oct 2019 at 19:54, Hugh Marera wrote:
>
> [...] it is not very difficult to find functions in dplyr or data.table or
> indeed other packages that one may wish to be in base R. Examples, for me,
> could include data.table::fread
You have utils::read.table and the like.
> dplyr::group_
On Sat, 5 Oct 2019 at 18:10, Rui Barradas wrote:
>
> R is a functional language, pipes are not.
How would you classify them? Pipes are analogous to function
composition. In that sense, they are more functional than classes, and
R does have classes.
Anyway, I don't see "purity" as a valid argumen
On Sat, 5 Oct 2019 at 17:15, Hugh Marera wrote:
>
> How is your argument different to, say, "Should dplyr or data.table be
> part of base R as they are the most popular data science packages and they
> are used by a large number of users?"
Two packages with many features, dozens of functions and
On Fri, 6 Sep 2019 at 14:08, Therneau, Terry M., Ph.D. via R-devel
wrote:
>
> Yes, that is exactly the problem. The code found in the "config" script is
> never run.
> But why doesn't it get run?
It should be called "configure", not "config".
Iñaki
On Tue, 3 Sep 2019 at 14:53, Therneau, Terry M., Ph.D. via R-devel
wrote:
>
> I remember there was advice about a server that one could use for reverse
> dependency
> checks, but I forgot to write it down. (Or I did save the info and forgot
> where I saved
> it...) I have been doing the check
Dear CRAN maintainers, R core team,
Here are some suggestions to prevent some issues I found in several
packages on CRAN. Some of these issues have been reported to their
maintainers, but still I believe it would be desirable to enforce
these on CRAN or in the corresponding R CMD.
- Checks for un
Don't mind. It seems to be a caching issue in the underlying
filesystem. Not sure how to solve it though.
Iñaki
On Wed, 21 Aug 2019 at 13:21, Iñaki Ucar wrote:
>
> Hi,
>
> I'm building r-devel using [1], and I see:
>
> mv: './grid/vignettes/grid.Rnw-lattice&
Hi,
I'm building r-devel using [1], and I see:
mv: './grid/vignettes/grid.Rnw-lattice' and
'./grid/vignettes/grid.Rnw' are the same file
make[1]: *** [Makefile:121: vignettes-no-lattice] Error 1
Regards,
Iñaki
[1] https://hub.docker.com/r/rocker/r-devel/dockerfile
_
On Sat, 3 Aug 2019 at 00:36, Abby Spurdle wrote:
>
> I can't find one reference to Python in the documentation:
Maybe because it's *not* needed? There's a note here though:
https://github.com/rwinlib/gcc-4.9.3
Iñaki
__
R-devel@r-project.org mailing li
On Mon, 15 Jul 2019 at 18:55, William Dunlap via R-devel
wrote:
>
> This may be related to the size of the deparsed call in the error message
> that Brodie and Luke were discussing recently on R-devel (" Mitigating
> Stalls Caused by Call Deparse on Error"). I don't get a crash, but the
> error
It doesn't matter you didn't use the value. An invalid read may fail
or not. It depends on whether that memory portion was reallocated or
not by the OS. When it was, you are trying to read in a memory region
where you don't have permission, so it crashes.
Iñaki
On Sun, 30 Jun 2019 at 04:27, Thern
On Wed, 19 Jun 2019 at 07:42, King Jiefei wrote:
>
> Hello Kevin and Iñaki,
>
> Thanks for your quick responses. I sincerely appreciate them! I can see how
> complicated it is to interact with R in C. Iñaki's suggestion is very
> helpful, I saw there is a lot of performance gain by turning the f
On Tue, 18 Jun 2019 at 19:41, King Jiefei wrote:
>
> [...]
>
> It is clear to see that calling an R function in R is the fast one, it is
> about 5X faster than ` R_forceAndCall ` and ` Rf_eval`. the latter two
> functions have a similar performance and using Rcpp is the worst one. Is it
> expected
m elapsed
2.307 0.000 2.313
> system.time(test(C_test3, testFunc, evn$x))
user system elapsed
2.131 0.000 2.138
Iñaki
On Tue, 18 Jun 2019 at 20:35, Iñaki Ucar wrote:
>
> On Tue, 18 Jun 2019 at 19:41, King Jiefei wrote:
> >
> > [...]
> >
> > It is cl
On Tue, 18 Jun 2019 at 19:03, Therneau, Terry M., Ph.D. via R-devel
wrote:
>
> I had added a vignette to the coxme package and all worked well locally, but
> it failed at
> CRAN. The issue is that the vignette involves using coxme for pedigree
> data, it
> doesn't work without the kinship2 p
On Sat, 15 Jun 2019 at 01:24, Abby Spurdle wrote:
>
> None of the tools that I've looked at satisfy these constraints.
> But if you know of some, I'd like to know... And I would consider
> contributing...
What about Atom, VS Code and the like? Or what about taking a project
that meets most of th
Honestly, I don't see the motivation for this. There are many similar
projects that are mature, so my feedback would be: don't reinvent the wheel
and contribute to those.
Iñaki
El vie., 14 jun. 2019 3:18, Abby Spurdle escribió:
> I thought that I'd get more feedback.
> But it's ok, I understan
FWIW, innoextract extracts the contents of the installer just fine.
Iñaki
On Tue, 4 Jun 2019 at 17:40, Steven Penny wrote:
>
> On Mon, Jun 3, 2019 at 6:54 PM Marc Schwartz wrote:
> > I am on macOS primarily, albeit, I have run both Windows and Linux routinely
> > in years past.
>
> With all due
I believe r-package-devel is the proper list for this. Now in CC.
On Thu, 30 May 2019 at 00:16, Dr Gregory Jefferis
wrote:
>
> Dear Colleagues,
>
> I would like to provide a CITATION file for my package nat.nblast [1].
>
> I have the correct citation in BibTeX format [2]. How can I convert this
>
On Sun, 19 May 2019 at 23:23, Pavel Krivitsky wrote:
>
> Hi, Inaki,
>
> On Sun, 2019-05-19 at 16:59 +0200, Iñaki Ucar wrote:
> > IMO the simplest way to do this is to check who the caller was:
> >
> > foo <- function(x) UseMethod("foo")
> >
On Sat, 18 May 2019 at 23:34, Pavel Krivitsky wrote:
>
> > The issue here is that you are registering a non-standard name
> > (.gen.formula) for that generic and then defining what would be the
> > standard name (gen.formula) for... what purpose? IMHO, this is a bad
> > practice and should be avoi
On Tue, 14 May 2019 at 12:31, Pavel Krivitsky wrote:
>
> > Note that disabling name-based dispatch implies two things: 1) the
> > inability to override your method by defining gen.formula in the
> > global environment, and 2) another package can break yours (i.e.,
> > internal calls to gen()) by r
CCing r-devel.
On Tue, 14 May 2019 at 02:11, Pavel Krivitsky wrote:
>
> Dear All,
>
> I've run into this while updating a package with unfortunately named
> legacy functions. It seems like something that might be worth changing
> in R, and I want to get a sense of whether this is a problem before
On Wed, 8 May 2019 at 18:00, Ralf Stubner wrote:
>
> On 08.05.19 09:34, Iñaki Ucar wrote:
> > On Wed, 8 May 2019 at 04:52, Peter Langfelder
> > wrote:
> >>
> >> (CCing the R-devel list, maybe someone will have a better answer.)
> >>
> >&g
On Wed, 8 May 2019 at 04:52, Peter Langfelder
wrote:
>
> (CCing the R-devel list, maybe someone will have a better answer.)
>
> To be honest, I don't know how to. I wasn't able to configure R to use
> OpenBLAS using the configure script and options on my Linux Fedora system.
> I configure it witho
On Mon, 15 Apr 2019 at 08:44, Tomas Kalibera wrote:
>
> On 4/13/19 12:05 PM, Iñaki Ucar wrote:
> > On Sat, 13 Apr 2019 at 03:51, Kevin Ushey wrote:
> >> I think it's worth saying that mclapply() works as documented
> > Mostly, yes. But it says nothing about
On Sat, 13 Apr 2019 at 18:41, Simon Urbanek wrote:
>
> Sure, but that a completely bogus argument because in that case it would fail
> even more spectacularly with any other method like PSOCK because you would
> *have to* allocate n times as much memory so unlike mclapply it is guaranteed
> to
On Sat, 13 Apr 2019 at 03:51, Kevin Ushey wrote:
>
> I think it's worth saying that mclapply() works as documented
Mostly, yes. But it says nothing about fork's copy-on-write and memory
overcommitment, and that this means that it may work nicely or fail
spectacularly depending on whether, e.g., y
On Fri, 12 Apr 2019 at 21:32, Travers Ching wrote:
>
> Just throwing my two cents in:
>
> I think removing/deprecating fork would be a bad idea for two reasons:
>
> 1) There are no performant alternatives
"Performant"... in terms of what. If the cost of copying the data
predominates over the comp
On Thu, 11 Apr 2019 at 22:07, Henrik Bengtsson
wrote:
>
> ISSUE:
> Using *forks* for parallel processing in R is not always safe.
> [...]
> Comments?
Using fork() is never safe. The reference provided by Kevin [1] is
pretty compelling (I kindly encourage anyone who ever forked a process
to read i
On Wed, 27 Feb 2019 at 09:51, Serguei Sokol wrote:
>
> On 26/02/2019 05:18, Brian Montgomery via R-devel wrote:
> > The following code crashes after about 300 iterations on my
> > x86_64-w64-mingw32 machine on R 3.5.2 --vanilla.
> > Others have duplicated this (see
> > https://github.com/tidyver
On Wed, 27 Feb 2019 at 09:02, Sebastian Martin Krantz
wrote:
>
> Dear Developers,
>
> Having spent time developing and thinking about how data aggregation and
> summary statistics can be enhanced in R, I would like to present my
> ideas/efforts in the form of two commands:
>
> The first, which for
On Mon, 18 Feb 2019 at 17:27, Gábor Csárdi wrote:
>
> From "Writing R Extensions":
>
> "Only ASCII characters (and the control characters tab, formfeed, LF
> and CR) should be used in code files."
>
> So I am afraid you cannot use μm.
Thanks, Gábor, I missed that bit. Then, is an .Rd file conside
Hi,
We found a (to our eyes) strange behaviour that might be a bug. First
a little bit of context. The 'units' package allows us to set the unit
using both SE or NSE. E.g., these both work in the same way:
units::set_units(1:10, "μm")
#> Units: [μm]
#> [1] 1 2 3 4 5 6 7 8 9 10
units::se
On Mon, 14 Jan 2019 at 10:58, Glen MacLachlan wrote:
>
> Hello,
>
> Not sure if this is the right list of if this is a gdal/sf issue so I
> apologize but recently I've been seeing errors that crash R/3.5.1 and throw
> a double-linked list error (see below). Has anyone else come across this
> issue
On Mon, 7 Jan 2019 at 22:09, Gergely Daróczi wrote:
>
> Dear David, sharing some related (subjective) thoughts below.
>
> You can provide your app as a Docker image, so that the end-user
> simply calls a "docker pull" and then "docker run" -- that can be done
> from a user-friendly script as well.
"R-devel on behalf of Duncan Murdoch"
> >>
> >> wrote:
> >>
> >>>On 03/01/2019 3:37 p.m., Duncan Murdoch wrote:
> >>> I see this too; by bisection, it seems to have first appeared in r72943.
> >>
> >>Sor
Hi,
I found the following issue in r-devel (2019-01-02 r75945):
`foo<-` <- function(x, value) {
bar(x) <- value * x
x
}
`bar<-` <- function(x, value) {
stopifnot(all(value / x == 1))
x + value
}
`foo<-` <- compiler::cmpfun(`foo<-`)
`bar<-` <- compiler::cmpfun(`bar<-`)
x <- c(2, 2)
foo(
On Tue, 4 Dec 2018 at 11:12, wrote:
>
> function ppois is a function calculate the CDF of Poisson distribution, it
> should generate a non-decreasing result, but what I got is:
>
> > any(diff(ppois(0:19,lambda=0.9))<0)
> [1] TRUE
>
> Actually,
>
> > ppois(19,lambda=0.9) [1] TRUE
>
> Which could n
On Sat, 3 Nov 2018 at 11:54, Joris Meys wrote:
>
> FWIW, you can get the URL and extract the link with extension from there.
> Archived packages are always tarballs, so that makes the following possible:
>
> url <- "https://cran.r-project.org/package=httr&version=1.3.0";
>
> library(RCurl)
>
> pk
es. So we
have to do the following similarly odd trick (note the "#"):
Source0:
https://cran.r-project.org/package=%{packname}&version=%{version}#/%{packname}_%{version}.tar.gz
Did you consider this problem? Is there any alternate immutable URL
*with* extension? If n
El mié., 19 sept. 2018 a las 14:43, Duncan Murdoch
() escribió:
>
> On 18/09/2018 5:46 PM, Carl Boettiger wrote:
> > Dear list,
> >
> > It looks to me that R samples random integers using an intuitive but biased
> > algorithm by going from a random number on [0,1) from the PRNG to a random
> > inte
El lun., 10 sept. 2018 a las 14:18, Tomas Kalibera
() escribió:
>
> On 09/05/2018 11:18 AM, Iñaki Ucar wrote:
> > The bottomline here is that one can always call a base method,
> > inexpensively and without modifying the object, in, let's say,
> > *formal* OOP language
tants in the byte-code compiler.
>
> Best
> Tomas
>
> >
> > Thxs,
> >
> > Henrik
> >
> > __
> > 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
--
Iñaki Ucar
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
1 - 100 of 106 matches
Mail list logo
