On Thu, May 21, 2020 at 10:37 AM wrote:
> Providing a way to more easily resolve situations that otherwise would
> be errors is a reasonable thing for an IDE to do.
In principle, yes.
However, I note that the word "easily" could mean different things to
different people.
Certain IDE* (not naming
Providing a way to more easily resolve situations that otherwise would
be errors is a reasonable thing for an IDE to do. I would prefer is
such things were optional and off by default, but other way not.
If an IDE does this and you don't approve then you don't have to use
it.
Best,
luke
On Wed
> An IDE could provide a more sophisticated interface, like a dialog
> allowing separate choices for each conflict. But this is best left up
> to the IDE or the user.
An IDE (or other user interface) should not alter the behavior of R,
especially the installing/loading/attaching of packages.
Ther
On Wed, May 20, 2020 at 11:10 AM brodie gaslam via R-devel
wrote:
>
> > On Wednesday, May 20, 2020, 7:00:09 AM EDT, peter dalgaard
> wrote:
> >
> > Expected, see FAQ 7.31.
> >
> > You just can't trust == on FP operations. Notice also
>
> Additionally, since you're implementing a "mean" function
You can get what you are asking for now in R 4.0.0 with
globalCallingHandlers and using the packageConflictError object that
is signaled. This should get you started:
```
options(conflicts.policy = "strict")
packageConflictError
handle_conflicts <- function(e) {
cat(conditionMessage(e))
> On Wednesday, May 20, 2020, 7:00:09 AM EDT, peter dalgaard
> wrote:
>
> Expected, see FAQ 7.31.
>
> You just can't trust == on FP operations. Notice also
Additionally, since you're implementing a "mean" function you are testing
against R's mean, you might want to consider that R uses a two-p
Dear R Developers,
###
# Context:
###
When managing Search Path Conflicts (See:
https://developer.r-project.org/Blog/public/2019/03/19/managing-search-path-conflicts/index.html),
with:
options(conflicts.policy = "strict")
We get the following behaviour when loading a package (Eg: dplyr):
libra
On 5/14/20 8:34 PM, Jan Gorecki wrote:
Hi R developers,
I observed that system(timeout=) may still return exit code 0, when
killing the process due to timeout.
In src/unix/sys-unix.c there is
#define KILL_SIGNAL1 SIGINT
#define KILL_SIGNAL2 SIGTERM
#define KILL_SIGNAL3 SIGKILL
#define EMERGENC
> Trang Le writes:
> Hi Kurt,
> Thank you for fixing quantile(). However, do you think c.factor() can
> potentially break more functions? For example, with this new change,
> classification from the partykit package using predict() comes back NA because
> of this:
> https://github.com/cran/pa
Hi Kurt,
Thank you for fixing quantile(). However, do you think c.factor() can
potentially break more functions? For example, with this new change,
classification from the partykit package using predict() comes back NA
because of this:
https://github.com/cran/partykit/blob/597245ef3dfc98411ce919b
Thanks for reporting this, it is a bug, now fixed in R-devel and
R-patched (PR#17800).
Best
Tomas
On 5/15/20 3:50 AM, William Dunlap via R-devel wrote:
Is it just my installation or does edit() (or fix(), etc.) in R-4.0.0
double all the backslashes when options(keep.source=TRUE)? E.g.,
opti
Expected, see FAQ 7.31.
You just can't trust == on FP operations. Notice also
> a2=(z[idx]+x[idx]+y[idx])/3
> a2==a
[1] FALSE
> a2==b
[1] TRUE
-pd
> On 20 May 2020, at 12:40 , Morgan Morgan wrote:
>
> Hello R-dev,
>
> Yesterday, while I was testing the newly implemented function pmean in
> p
Hello R-dev,
Yesterday, while I was testing the newly implemented function pmean in
package kit, I noticed a mismatch in the output of the below R expressions.
set.seed(123)
n=1e3L
idx=5
x=rnorm(n)
y=rnorm(n)
z=rnorm(n)
a=(x[idx]+y[idx]+z[idx])/3
b=mean(c(x[idx],y[idx],z[idx]))
a==b
# [1] FALSE
13 matches
Mail list logo
