date:20200825

[Rd] NAs and rle

2020-08-25 Thread Gabriel Becker

Hi All,

A twitter user, Mike fc (@coolbutuseless) mentioned today that he was
surprised that repeated NAs weren't treated as a run by the rle function.

Now I know why they are not. NAs represent values which could be the same
or different from eachother if they were known, so from a purely conceptual
standpoint there is no way to tell whether they are the same and thus
constitute a run or not.

This conceptual strictness isnt universally observed, though, because we
get the following:

> unique(c(1, 2, 3, NA, NA, NA))

[1]  1  2  3 NA


Which means that rle(sort(x))$value is not guaranteed to be the same as
unique(x), which is a little strange (though likely of little practical
impact).


Personally, to me it also seems that, from a purely data-compression
standpoint, it would be valid to collapse those missing values into a run
of missing, as it reduces size in-memory/on disk without losing any
information.

Now none of this is to say that I suggest the default behavior be changed
(that would surely disrupt some non-trivial amount of existing code) but
what do people think of a  group.nas argument which defaults to FALSE
controlling the behavior?

As a final point, there is some precedent here (though obviously not at all
binding), as Bioconductor's Rle functionality does group NAs.

Best,
~G

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] trace creates object in base namespace if called on function argument

2020-08-25 Thread Antoine Fabri

Apologies there is one line missing in my last email, the code should be :

foo <- function() "hello"
trace2 <- function(fun) trace(fun, quote(print("!!!")))
trace2(foo) # <- THIS LINE WAS MISSING
base::fun

Best,

Antoine

Le mar. 25 août 2020 à 22:02, Antoine Fabri  a
écrit :

> Dear R-devel,
>
> I don't think this is expected :
>
> foo <- function() "hello"
> trace2 <- function(fun) trace(fun, quote(print("!!!")))
> base::fun
> # Object with tracing code, class "functionWithTrace"
> # Original definition:
> # function() "hello"
> #
> # ## (to see the tracing code, look at body(object))
>
> `untrace()` has the same behavior.
>
> This is inconsistent with how debug works :
>
> foo <- function() "hello"
> debug2 <- function(fun) debug(fun)
> debug2(foo)
> isdebugged(foo)
> # [1] TRUE
>
> This can be worked around by defining :
>
> trace2 <- function(fun) eval.parent(substitute(trace(fun,
> quote(print("!!!")))
>
> but I believe the current behavior is undesired and it'd be better to make
> it behave as `debug()`, or to throw an error.
>
> Best,
>
> Antoine
>

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[Rd] trace creates object in base namespace if called on function argument

2020-08-25 Thread Antoine Fabri

Dear R-devel,

I don't think this is expected :

foo <- function() "hello"
trace2 <- function(fun) trace(fun, quote(print("!!!")))
base::fun
# Object with tracing code, class "functionWithTrace"
# Original definition:
# function() "hello"
#
# ## (to see the tracing code, look at body(object))

`untrace()` has the same behavior.

This is inconsistent with how debug works :

foo <- function() "hello"
debug2 <- function(fun) debug(fun)
debug2(foo)
isdebugged(foo)
# [1] TRUE

This can be worked around by defining :

trace2 <- function(fun) eval.parent(substitute(trace(fun,
quote(print("!!!")))

but I believe the current behavior is undesired and it'd be better to make
it behave as `debug()`, or to throw an error.

Best,

Antoine

[[alternative HTML version deleted]]

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

[R-pkg-devel] Package inputenc Error: Unicode char ‐ (U+2010) during Windows build

2020-08-25 Thread Joshua Harrison

Hi all,

I cannot get my package to correctly build on Windows because of an
encoding error that I just can't figure out. The package builds on my Mac
(10.14.6) and on a recent Debian release.

The source code for the package can be viewed here:
https://github.com/JHarrisonEcoEvo/CNVRG

The error code thrown by the "check_win_release" function of devtools is:

* checking PDF version of manual ... WARNING
LaTeX errors when creating PDF version.
This typically indicates Rd problems.
LaTeX errors found:
! Package inputenc Error: Unicode char ‐ (U+2010)
(inputenc)not set up for use with LaTeX.

See the inputenc package documentation for explanation.
Type  H   for immediate help.
! Package inputenc Error: Unicode char ‐ (U+2010)
(inputenc)not set up for use with LaTeX.

See the inputenc package documentation for explanation.
Type  H   for immediate help.
* checking PDF version of manual without hyperrefs or index ... ERROR
* checking for detritus in the temp directory ... OK
* DONE
Status: 1 ERROR, 1 WARNING, 1 NOTE

FYI the note referenced is because the package is a new submission.

I figured the problem was with hyphens (the unicode 2010) and so I went
through the manual and vignette and deleted all the hyphens in the regular
text. There are still hyphen symbols in the assignment operator of the
examples ("<-"). Are these the problem?

I have spent way too much time trying to figure this out so any help would
be greatly appreciated. I see that many folks have similar issues with
vignettes and manuals but I haven't found a solution that works for me.

I am completely fine not having the package build on Windows. Users of that
system can download the manual or view it in a browser. However, I don't
see how I can get the package on CRAN without fixing this.

Thanks for your time and assistance!

--
J. G. Harrison
Postdoctoral researcher
University of Wyoming
jgharrison.weebly.com

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [Rd] R 4.0.2 64-bit Windows hangs

2020-08-25 Thread Tomas Kalibera


On 8/22/20 9:33 PM, Jeroen Ooms wrote:

On Sat, Aug 22, 2020 at 9:10 PM Tomas Kalibera  wrote:

On 8/22/20 8:26 PM, Tomas Kalibera wrote:

On 8/22/20 7:58 PM, Jeroen Ooms wrote:

On Sat, Aug 22, 2020 at 8:39 AM Tomas Kalibera
 wrote:

On 8/21/20 11:45 PM, m19tdn+9alxwj7d2bmk--- via R-devel wrote:

Ah yes, this is related. I reported v2010 below, but it looks like
I was updated to this Insider Build overnight without my knowledge,
and conflated it with the new installation R v4 this morning.

I will continue to look into the issue with the methods Tomas
mentioned.

It is interesting that a rare 5 years old problem would re-appear on
current Insider builds. Which build of Windows are you running exactly?
I've seen another report about a crash on 20190.1000. It'd be nice to
know if it is present also in newer builds, i.e. in 20197.

I installed the latest 20197 build in a vm, and I can indeed reproduce
this problem.

What seems to be happening is that R triggers an infinite recursion in
Windows unwinding mechanism, and eventually dies with a stack
overflow. Attached a backtrace of the initial 100 frames of the main
thread (the pattern in the top ~30 frames continues forever).

The microsoft blog doesn't mention anything related to exception
handling has changed in recent versions:
https://docs.microsoft.com/en-us/windows-insider/at-home/active-dev-branch


Thanks, unfortunately that does not ring any bells (except below), I
can't guess from this what is the underlying cause of the problem.
There may be something wrong in how we use setjmp/longjmp or how
setjmp/longjmp works on Windows.

It reminds me of a problem I've been debugging few days ago, when
longjump implementation segfaults on Windows 10 (recent but not
Insider build) probably soon after unwinding the stack, but only with
GCC 10 / MinGW 7 and only in one of the no-segfault tests, and only
with -03 (not -O2, not with with -O3 -fno-split-loops). The problem
was sensitive to these optimization options interestingly on the call
site of long jump (do_abs), even when it was not an immediate caller
of the longjump. I've not tracked this down yet, it will require
looking at the assembly level, and I was suspecting a compiler error
causing the compiler to generate code that messes with the stack or
registers in a way that impacts the upcoming jump. But now as we have
this other problem with setjmp/logjmp, the compiler may not be the top
suspect anymore.

I may not be able to work on this in the next few days or a week, so
if anyone gets there first, please let me know what you find out.

Btw could you please try out if the UCRT build of R crashes as well in
the Insider Windows build ?

Yes, it hangs in exactly the same way, except that the backtrace shows

  ucrtbase!.intrinsic_setjmpex () from C:\WINDOWS\System32\ucrtbase.dll

Instead of msvcrt!_setjmpex (as expected of course).


Thanks. I found what is causing the problem I observed with GCC10/stock 
Windows 10, I expect this is the same one as in the Insider build.

I will investigate further,

Tomas

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Bioc-devel] About rcellminerData and rcellminerData new versions

2020-08-25 Thread Turaga, Nitesh

Hi Fathi,

So as I’ve mentioned previously, it’s impossible to go back in history cleanly 
on the Bioconductor git server. Like Herve explained we do this to maintain a 
“clean” commit history and to keep the repositories within Bioconductor as 
coherent as possible when we look at the logs.

I do not think you’ll be able to push these changes since both your branches 
have diverged so much.

You also cannot push with the “force” (-f) option. That is just not something 
we allow on the Bioconductor git server.

Just to make clear, when Martin said,

   The more straight-forward approach is to simply add a commit to the 
RELEASE_3_11 branch that undoes the changes you do not wish to publish, except 
with a version bump (to version 2.10.3?)

He did not mean, `git reset --hard` to a specific commit. Because of the branch 
divergence you’ll not be able to push. He meant, quite literally, “undo” the 
changes manually.

- If you added 10 lines of code in a commit, just delete those 10 lines of code 
from the next commit and update the version number.

I asked to see to see what happens with `git reset --hard` to see how much your 
RELEASE_3_11 branch has changed.

These are the steps I’d take to move forward from here,

1. git pull (to merge the remote branch)

2. 

3. Edit description file to update version number.

4. git add 

5. git commit -m 

6. git push upstream master


Notice that there is no `-f` here. Also notice that I’m not attempting to go 
back in time with git. I’m simply moving forward just undoing what I’ve done.

Best,

Nitesh


On Aug 25, 2020, at 10:30 AM, Elloumi, Fathi (NIH/NCI) [C] 
mailto:fathi.ello...@nih.gov>> wrote:

Hi Nitesh,

I made the changes locally:
nci-02048674-ML:rcellminerData elloumif$ git status
On branch RELEASE_3_11
Your branch and 'upstream/RELEASE_3_11' have diverged,
and have 1 and 21 different commits each, respectively.
  (use "git pull" to merge the remote branch into yours)

Should I do now:

git push -f upstream RELEASE_3_11 (with option -f) ?

Fathi

From: "Turaga, Nitesh" 
mailto:nitesh.tur...@roswellpark.org>>
Date: Tuesday, August 25, 2020 at 9:36 AM
To: "Elloumi, Fathi (NIH/NCI) [C]" 
mailto:fathi.ello...@nih.gov>>
Cc: Martin Morgan mailto:mtmorgan.b...@gmail.com>>, 
Hervé Pagès mailto:hpa...@fredhutch.org>>, bioc-devel 
mailto:bioc-devel@r-project.org>>, Nitesh Turaga 
mailto:nitesh.tur...@gmail.com>>
Subject: Re: [Bioc-devel] About rcellminerData and rcellminerData new versions

Hi Fathi,

You can try those steps. Let me know if it works.

Nitesh


On Aug 25, 2020, at 9:28 AM, Elloumi, Fathi (NIH/NCI) [C] 
mailto:fathi.ello...@nih.gov>> wrote:

Dear Martin,

I have attached my commit log for my local branch RELEASE_3_11 for package 
rcellminerData. To undo the changes and return the last April content, here 
what I plan to do locally:

- git reset -- hard  414dbc7bc3ab5c507dfca01e91005d7ebc62f282  (last commit 
from Hervé)
- change version in DESCRIPTION to 2.10.3 and commit this change locally
- git push upstream RELEASE_3_11

Please let me know if these steps are correct.

Thanks for your help.

Fathi

On 8/25/20, 7:06 AM, "Martin Morgan" 
mailto:mtmorgan.b...@gmail.com>> wrote:

   The more straight-forward approach is to simply add a commit to the 
RELEASE_3_11 branch that undoes the changes you do not wish to publish, except 
with a version bump (to version 2.10.3?)

   Martin

   On 8/24/20, 8:02 PM, "Bioc-devel on behalf of Elloumi, Fathi (NIH/NCI) [C] 
via Bioc-devel" 
mailto:bioc-devel-boun...@r-project.org> on 
behalf of bioc-devel@r-project.org> wrote:

   Dear Hervé,

   Thank you very much for your clarification. I already pushed updates 
(more data)  that will have impact on the output. I saw that you committed the 
April 27th version (2.10.0) for RELEASE_3_11. Looking at this link 
:https://secure-web.cisco.com/1GbaxXXZLBLRIoJalQWlchTBBJ_rLRkSsnlF6Ekz583a10uUnZLP-YgG4SnC6tgST76n4JiQeUssWmH3bjPbQbmTGY3usbOToAgyca06FFa_GSMlAKyLhBNsAE8c68p17FA_qtJoXwj-Pg7HrKh4M_WMMVqxgmj8pQnPQH9q1OEg34sOVuqkhtKeSKg_kBXoC4l0QcMnE0D1UtBGagtSMDWyn2Jjfaahpd14A9DhQMy7sOKqRxnSdVG0FhUBR8X7OolJ45XePxmXEKVXPTR2CU8D17j6GQq9JnkHgJ9v_0TFmnw_6vfazZq_sM__fTu1UOax3GMQOpOkLS6l-cSSyYS4oZDrvZj02X8cW5bejVVo/https%3A%2F%2Fbioconductor.org%2Fdevelopers%2Fhow-to%2Fgit%2Fabandon-changes%2F
 , it seems that the Bioconductor team can reset a previous commit. Please let 
me know if this the right way to do it as described in the previous link. 
Please advise.

   Best,

   Fathi

   On 8/21/20, 5:45 PM, "Hervé Pagès" 
mailto:hpa...@fredhutch.org>> wrote:

   Hi Fathi,

   The purpose of the "only bug fixes and documentation improvements in
   release" policy is **stability** of the current release (BioC 3.11).
   That is, we want to avoid disruption and to make analyses that use 
BioC
   3.11 as reproducible as possible. This means that if the changes to 
the
   RELEASE_3_11 branch of

Re: [Bioc-devel] About rcellminerData and rcellminerData new versions

2020-08-25 Thread Elloumi, Fathi (NIH/NCI) [C] via Bioc-devel

Hi Nitesh,

I made the changes locally:

nci-02048674-ML:rcellminerData elloumif$ git status

On branch RELEASE_3_11

Your branch and 'upstream/RELEASE_3_11' have diverged,

and have 1 and 21 different commits each, respectively.

  (use "git pull" to merge the remote branch into yours)

Should I do now:

git push -f upstream RELEASE_3_11 (with option -f) ?

Fathi

From: "Turaga, Nitesh" 
Date: Tuesday, August 25, 2020 at 9:36 AM
To: "Elloumi, Fathi (NIH/NCI) [C]" 
Cc: Martin Morgan , Hervé Pagès 
, bioc-devel , Nitesh Turaga 

Subject: Re: [Bioc-devel] About rcellminerData and rcellminerData new versions

Hi Fathi,

You can try those steps. Let me know if it works.

Nitesh


On Aug 25, 2020, at 9:28 AM, Elloumi, Fathi (NIH/NCI) [C] 
mailto:fathi.ello...@nih.gov>> wrote:

Dear Martin,

I have attached my commit log for my local branch RELEASE_3_11 for package 
rcellminerData. To undo the changes and return the last April content, here 
what I plan to do locally:

- git reset -- hard  414dbc7bc3ab5c507dfca01e91005d7ebc62f282  (last commit 
from Hervé)
- change version in DESCRIPTION to 2.10.3 and commit this change locally
- git push upstream RELEASE_3_11

Please let me know if these steps are correct.

Thanks for your help.

Fathi

On 8/25/20, 7:06 AM, "Martin Morgan" 
mailto:mtmorgan.b...@gmail.com>> wrote:

   The more straight-forward approach is to simply add a commit to the 
RELEASE_3_11 branch that undoes the changes you do not wish to publish, except 
with a version bump (to version 2.10.3?)

   Martin

   On 8/24/20, 8:02 PM, "Bioc-devel on behalf of Elloumi, Fathi (NIH/NCI) [C] 
via Bioc-devel" 
mailto:bioc-devel-boun...@r-project.org> on 
behalf of bioc-devel@r-project.org> wrote:

   Dear Hervé,

   Thank you very much for your clarification. I already pushed updates 
(more data)  that will have impact on the output. I saw that you committed the 
April 27th version (2.10.0) for RELEASE_3_11. Looking at this link : 
https://secure-web.cisco.com/1GbaxXXZLBLRIoJalQWlchTBBJ_rLRkSsnlF6Ekz583a10uUnZLP-YgG4SnC6tgST76n4JiQeUssWmH3bjPbQbmTGY3usbOToAgyca06FFa_GSMlAKyLhBNsAE8c68p17FA_qtJoXwj-Pg7HrKh4M_WMMVqxgmj8pQnPQH9q1OEg34sOVuqkhtKeSKg_kBXoC4l0QcMnE0D1UtBGagtSMDWyn2Jjfaahpd14A9DhQMy7sOKqRxnSdVG0FhUBR8X7OolJ45XePxmXEKVXPTR2CU8D17j6GQq9JnkHgJ9v_0TFmnw_6vfazZq_sM__fTu1UOax3GMQOpOkLS6l-cSSyYS4oZDrvZj02X8cW5bejVVo/https%3A%2F%2Fbioconductor.org%2Fdevelopers%2Fhow-to%2Fgit%2Fabandon-changes%2F
 , it seems that the Bioconductor team can reset a previous commit. Please let 
me know if this the right way to do it as described in the previous link. 
Please advise.

   Best,

   Fathi

   On 8/21/20, 5:45 PM, "Hervé Pagès" 
mailto:hpa...@fredhutch.org>> wrote:

   Hi Fathi,

   The purpose of the "only bug fixes and documentation improvements in
   release" policy is **stability** of the current release (BioC 3.11).
   That is, we want to avoid disruption and to make analyses that use 
BioC
   3.11 as reproducible as possible. This means that if the changes to 
the
   RELEASE_3_11 branch of the rcellminer and rcellminerData packages 
have
   the potential to break some of the scripts that your users are using 
for
   their analyses, or to change their output, then these changes should 
not
   be pushed to the RELEASE_3_11 branch.

   Note that we can only realistically aim at preserving things as 
stable
   as possible within the current release. Of course your software 
should
   be able to evolve over time. This is why important changes are 
allowed
   in devel (BioC 3.12).

   So the important question is: are the changes you pushed to BioC 3.11
   going to preserve stability? You are in the best position to answer 
that
   question. We (Nitesh and myself) lack context to answer it. Maybe 
Daniel
   knows a little bit more about what kind of changes you made but
   unfortunately he's no longer part of the BioC core team.

   Bottom line is: If the changes don't preserve stability, please don't
   push them to the release branch.

   Please don't hesitate to ask on the bioc-devel mailing list if you 
have
   concerns or questions about this.

   Best,
   H.


   On 8/21/20 09:34, Elloumi, Fathi (NIH/NCI) [C] wrote:

Dear Bioconductor team,

As mentioned in my previous email (please see below), do you consider
adding and cleaning data an enhancement should be only included in the
develop branch and NOT in the current release (3_11) branch version but
in the new release 3_12?

I followed the instructions at

[R-pkg-devel] Error in winbuilder

2020-08-25 Thread Nicholas Tierney

Hi Everyone,

I have an error when submitting to Winbuilder for my R package, naniar
.

When using `devtools::check_win_devel()` or `devtools::check_win_release()`
on naniar, I get the following logfile from winbuilder:

```
* using log directory 'd:/RCompile/CRANguest/R-release/naniar.Rcheck'
* using R version 4.0.2 (2020-06-22)
* using platform: x86_64-w64-mingw32 (64-bit)
* using session charset: ISO8859-1
* checking for file 'naniar/DESCRIPTION' ... OK
* checking extension type ... Package
* this is package 'naniar' version '0.5.3'
* package encoding: UTF-8
* checking CRAN incoming feasibility ... ERROR
Check process probably crashed or hung up for 20 minutes ... killed
Most likely this happened in the example checks (?),
if not, ignore the following last lines of example output:

 End of example output (where/before crash/hang up occured ?)

```

(submission URL here: https://win-builder.r-project.org/77PYyM2kMri1/)

I had previously thought this was a problem to do with CRAN being closed
last week, but apparently this is not the case, and it should have been
working. I cannot find any details on CRAN for this, but it passes build on
R HUB for windows, and it passes build with no warnings, errors, or notes
for me on Mac OSX, as well as on github actions (windows, macOS, and
ubuntu).

Just wondering if anyone has thoughts on this? I have also cross
posted on Rstudio
community
<
https://community.rstudio.com/t/winbuilder-error-check-process-probably-crashed-or-hung-up-for-20-minutes-killed/77492
>,
in case that is of interest.

Thanks for your time, and apologies if I have missed something obvious.

All the best,

Nick

[[alternative HTML version deleted]]

__
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel

Re: [Bioc-devel] About rcellminerData and rcellminerData new versions

2020-08-25 Thread Turaga, Nitesh

Hi Fathi,

You can try those steps. Let me know if it works.

Nitesh

On Aug 25, 2020, at 9:28 AM, Elloumi, Fathi (NIH/NCI) [C]
mailto:fathi.ello...@nih.gov>> wrote:

Dear Martin,

I have attached my commit log for my local branch RELEASE_3_11 for package
rcellminerData. To undo the changes and return the last April content, here
what I plan to do locally:

- git reset -- hard 414dbc7bc3ab5c507dfca01e91005d7ebc62f282 (last commit
from Hervé)
- change version in DESCRIPTION to 2.10.3 and commit this change locally
- git push upstream RELEASE_3_11

Please let me know if these steps are correct.

Thanks for your help.

Fathi

On 8/25/20, 7:06 AM, "Martin Morgan"
mailto:mtmorgan.b...@gmail.com>> wrote:

The more straight-forward approach is to simply add a commit to the
RELEASE_3_11 branch that undoes the changes you do not wish to publish, except
with a version bump (to version 2.10.3?)

Martin

On 8/24/20, 8:02 PM, "Bioc-devel on behalf of Elloumi, Fathi (NIH/NCI) [C]
via Bioc-devel"
mailto:bioc-devel-boun...@r-project.org> on
behalf of bioc-devel@r-project.org> wrote:

Dear Hervé,

Thank you very much for your clarification. I already pushed updates
(more data) that will have impact on the output. I saw that you committed the
April 27th version (2.10.0) for RELEASE_3_11. Looking at this link :
https://secure-web.cisco.com/1GbaxXXZLBLRIoJalQWlchTBBJ_rLRkSsnlF6Ekz583a10uUnZLP-YgG4SnC6tgST76n4JiQeUssWmH3bjPbQbmTGY3usbOToAgyca06FFa_GSMlAKyLhBNsAE8c68p17FA_qtJoXwj-Pg7HrKh4M_WMMVqxgmj8pQnPQH9q1OEg34sOVuqkhtKeSKg_kBXoC4l0QcMnE0D1UtBGagtSMDWyn2Jjfaahpd14A9DhQMy7sOKqRxnSdVG0FhUBR8X7OolJ45XePxmXEKVXPTR2CU8D17j6GQq9JnkHgJ9v_0TFmnw_6vfazZq_sM__fTu1UOax3GMQOpOkLS6l-cSSyYS4oZDrvZj02X8cW5bejVVo/https%3A%2F%2Fbioconductor.org%2Fdevelopers%2Fhow-to%2Fgit%2Fabandon-changes%2F
, it seems that the Bioconductor team can reset a previous commit. Please let
me know if this the right way to do it as described in the previous link.
Please advise.

Best,

Fathi

On 8/21/20, 5:45 PM, "Hervé Pagès"
mailto:hpa...@fredhutch.org>> wrote:

Hi Fathi,

The purpose of the "only bug fixes and documentation improvements in
release" policy is **stability** of the current release (BioC 3.11).
That is, we want to avoid disruption and to make analyses that use
BioC
3.11 as reproducible as possible. This means that if the changes to
the
RELEASE_3_11 branch of the rcellminer and rcellminerData packages
have
the potential to break some of the scripts that your users are using
for
their analyses, or to change their output, then these changes should
not
be pushed to the RELEASE_3_11 branch.

Note that we can only realistically aim at preserving things as
stable
as possible within the current release. Of course your software
should
be able to evolve over time. This is why important changes are
allowed
in devel (BioC 3.12).

So the important question is: are the changes you pushed to BioC 3.11
going to preserve stability? You are in the best position to answer
that
question. We (Nitesh and myself) lack context to answer it. Maybe
Daniel
knows a little bit more about what kind of changes you made but
unfortunately he's no longer part of the BioC core team.

Bottom line is: If the changes don't preserve stability, please don't
push them to the release branch.

Please don't hesitate to ask on the bioc-devel mailing list if you
have
concerns or questions about this.

Best,
H.

On 8/21/20 09:34, Elloumi, Fathi (NIH/NCI) [C] wrote:
Dear Bioconductor team,

As mentioned in my previous email (please see below), do you consider
adding and cleaning data an enhancement should be only included in the
develop branch and NOT in the current release (3_11) branch version but
in the new release 3_12?

I followed the instructions at
https://secure-web.cisco.com/1RUDS3iVBzcPhtbIZ04DnB8BcLmnwA9aO8_CkzKa8vxFPZkiGBrOiKmqdDA9N0alyItJdG3VJV_KvF9W_mUDiKzlO-taTgNHE0BIcItKedy2Rj_husqSBFOPbe0NGfgUgYXO9ZornEOJeqBWsQJVv0gW_OyFJRCMfzma1X3e3UO-frccNwYybj44Si-NNW4PPei1amKD89FP06sG7gVX1f7RcBKSrFM3_wLZJtwEebJDN_NBm6ZSzkeaugO3Zmx8sfNv-EM0Rm_q5Zms9-S8eO6u70UUgWh3J8FtkbCctnAre4KN2R9lbWkuzAzGuICxIXzdl_RVJ3s0Z6QFRYp8gdyWoYuFpC8HSE_cQYwSoc9g/https%3A%2F%2Fbioconductor.org%2Fdevelopers%2Fhow-to%2Fgit%2Fsync-existing-repositories%2F

Re: [Rd] sum() vs cumsum() implicit type coercion

2020-08-25 Thread Hugh Parsonage

(If I may be so bold, although I think it's unlikely that a majority
would be in favour of this change, and I doubt anyone is actually
proposing it, I think quite a bit more than "a majority" should be
required before a change like this should be allowed.

Considering the feature that cumsum coerces to numeric is documented,
the consistency of type coercion between sum and cumsum has never been
advertised, and that a custom version of cumsum that addresses the
inconsistency would be very easy for users to create themselves, I'd
struggle to think the change could ever have merit. Even public
unanimity would probably not be enough.)

On Tue, 25 Aug 2020 at 20:25, Martin Maechler
 wrote:
>
> > Tomas Kalibera
> > on Tue, 25 Aug 2020 09:29:05 +0200 writes:
>
> > On 8/23/20 5:02 PM, Rory Winston wrote:
> >> Hi
> >>
> >> I noticed a small inconsistency when using sum() vs cumsum()
> >>
> >> I have a char-based series
> >>
> >> > tryjpy$long
> >>
> >> [1] "0.0022"  "-0.0002" "-0.0149" "-0.0023" "-0.0342" "-0.0245" 
> "-0.0022"
> >>
> >> [8] "0.0003"  "-0.0001" "-0.0004" "-0.0036" "-0.001"  "-0.0011" 
> "-0.0012"
> >>
> >> [15] "-0.0006" "0.0016"  "0.0006"
> >>
> >> When I run sum() vs cumsum() , sum fails but cumsum converts the
> >> series to numeric before summing:
> >>
> >>> sum(tryjpy$long)
> >> Error in sum(tryjpy$long) : invalid 'type' (character) of argument
> >>
> >>> cumsum(tryjpy$long)
> >> [1]  0.0022  0.0020 -0.0129 -0.0152 -0.0494 -0.0739 -0.0761 -0.0758 
> -0.0759
> >> [10] -0.0763 -0.0799 -0.0809 -0.0820 -0.0832 -0.0838 -0.0822 -0.0816
> >>
> >> Which I guess is due to the following line in do_cum():
> >>
> >> PROTECT(t = coerceVector(CAR(args), REALSXP));
> >> This might be fine and there may be very good reasons why there is no
> >> coercion in sum - just seems a little inconsistent in usage
>
> > Yes. I don't know the reason for this design, but please note it is
> > documented in ?sum and in ?cumsum, which would also make it harder to
> > change. One can always use a consistent subset (not rely on the coercion
> > e.g. from characters).
>
> > Best
> > Tomas
>
> Indeed.
> Further note that most arithmetic/math  *fails* on
> character vectors, so if a change would have to be made, it
> should rather be such that cumsum() also rejects character
> input.
>
> We would have consistency then, but potentially break user code,
> even package code which has hitherto assumed cumsum() to coerce
> to numeric first.
>
> If a majority of commentators and R core thinks we should make
> such a change, I'd agree to consider it.
>
> Otherwise, we save (ourselves and others) a bit of time.
> Martin
>
> __
> 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: [Bioc-devel] About rcellminerData and rcellminerData new versions

2020-08-25 Thread Martin Morgan

The more straight-forward approach is to simply add a commit to the 
RELEASE_3_11 branch that undoes the changes you do not wish to publish, except 
with a version bump (to version 2.10.3?)

Martin

On 8/24/20, 8:02 PM, "Bioc-devel on behalf of Elloumi, Fathi (NIH/NCI) [C] via 
Bioc-devel"  wrote:

Dear Hervé,

Thank you very much for your clarification. I already pushed updates (more 
data)  that will have impact on the output. I saw that you committed the April 
27th version (2.10.0) for RELEASE_3_11. Looking at this link : 
https://bioconductor.org/developers/how-to/git/abandon-changes/ , it seems that 
the Bioconductor team can reset a previous commit. Please let me know if this 
the right way to do it as described in the previous link. Please advise.

Best,

Fathi

On 8/21/20, 5:45 PM, "Hervé Pagès"  wrote:

Hi Fathi,

The purpose of the "only bug fixes and documentation improvements in 
release" policy is **stability** of the current release (BioC 3.11). 
That is, we want to avoid disruption and to make analyses that use BioC 
3.11 as reproducible as possible. This means that if the changes to the 
RELEASE_3_11 branch of the rcellminer and rcellminerData packages have 
the potential to break some of the scripts that your users are using 
for 
their analyses, or to change their output, then these changes should 
not 
be pushed to the RELEASE_3_11 branch.

Note that we can only realistically aim at preserving things as stable 
as possible within the current release. Of course your software should 
be able to evolve over time. This is why important changes are allowed 
in devel (BioC 3.12).

So the important question is: are the changes you pushed to BioC 3.11 
going to preserve stability? You are in the best position to answer 
that 
question. We (Nitesh and myself) lack context to answer it. Maybe 
Daniel 
knows a little bit more about what kind of changes you made but 
unfortunately he's no longer part of the BioC core team.

Bottom line is: If the changes don't preserve stability, please don't 
push them to the release branch.

Please don't hesitate to ask on the bioc-devel mailing list if you have 
concerns or questions about this.

Best,
H.

On 8/21/20 09:34, Elloumi, Fathi (NIH/NCI) [C] wrote:
> Dear Bioconductor team,
> 
> As mentioned in my previous email (please see below), do you consider 
> adding and cleaning data an enhancement should be only included in 
the 
> develop branch and NOT in the current release (3_11) branch version 
but 
> in the new release 3_12?
> 
> I followed the instructions at 
> 
https://bioconductor.org/developers/how-to/git/sync-existing-repositories/ 
> 

> with instruction to update on both devel and release branches.
> 
> Please advise.
> 
> Best,
> 
> Fathi
> 
> *From: *"Elloumi, Fathi (NIH/NCI) [C]" 
> *Date: *Friday, August 21, 2020 at 10:51 AM
> *To: *"Van Twisk, Daniel" 
> *Subject: *About rcellminerData and rcellminerData new versions
> 
> Dear Daniel,
> 
> This week I pushed new version (2.10.2) for both packages rcellminer 
and 
> rcellminerData in the release_3_11 adding new drug data and cleaning 
> some “bad” experiments. Do you consider this against your policy here 
below.
> 
> /From the Bioconductor paper in 2004/
> 
> 
/(//https://genomebiology.biomedcentral.com/articles/10.1186/gb-2004-5-10-r80/ 
> 
/):/
> 
> /The only changes allowed to be made on the release version are bug/
> 
> /fixes and documentation improvements. This ensures that users will 
not/
> 
> /encounter radical new behaviors in code obtained in the release/
> 
> /version. All other changes such as enhancements or design changes 
are/
> 
> /carried out on the development branch [34]./
> 
> Please let me know asap and if needed we will back to previous commit.
> 
> Thanks,
> 
> -- Fathi
> 
>

Re: [Rd] sum() vs cumsum() implicit type coercion

2020-08-25 Thread Martin Maechler

> Tomas Kalibera 
> on Tue, 25 Aug 2020 09:29:05 +0200 writes:

> On 8/23/20 5:02 PM, Rory Winston wrote:
>> Hi
>> 
>> I noticed a small inconsistency when using sum() vs cumsum()
>> 
>> I have a char-based series
>> 
>> > tryjpy$long
>> 
>> [1] "0.0022"  "-0.0002" "-0.0149" "-0.0023" "-0.0342" "-0.0245" "-0.0022"
>> 
>> [8] "0.0003"  "-0.0001" "-0.0004" "-0.0036" "-0.001"  "-0.0011" "-0.0012"
>> 
>> [15] "-0.0006" "0.0016"  "0.0006"
>> 
>> When I run sum() vs cumsum() , sum fails but cumsum converts the
>> series to numeric before summing:
>> 
>>> sum(tryjpy$long)
>> Error in sum(tryjpy$long) : invalid 'type' (character) of argument
>> 
>>> cumsum(tryjpy$long)
>> [1]  0.0022  0.0020 -0.0129 -0.0152 -0.0494 -0.0739 -0.0761 -0.0758 
-0.0759
>> [10] -0.0763 -0.0799 -0.0809 -0.0820 -0.0832 -0.0838 -0.0822 -0.0816
>> 
>> Which I guess is due to the following line in do_cum():
>> 
>> PROTECT(t = coerceVector(CAR(args), REALSXP));
>> This might be fine and there may be very good reasons why there is no
>> coercion in sum - just seems a little inconsistent in usage

> Yes. I don't know the reason for this design, but please note it is 
> documented in ?sum and in ?cumsum, which would also make it harder to 
> change. One can always use a consistent subset (not rely on the coercion 
> e.g. from characters).

> Best
> Tomas

Indeed.
Further note that most arithmetic/math  *fails* on
character vectors, so if a change would have to be made, it
should rather be such that cumsum() also rejects character
input.

We would have consistency then, but potentially break user code,
even package code which has hitherto assumed cumsum() to coerce
to numeric first.

If a majority of commentators and R core thinks we should make
such a change, I'd agree to consider it.

Otherwise, we save (ourselves and others) a bit of time.
Martin

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Re: [Rd] sum() vs cumsum() implicit type coercion

2020-08-25 Thread Tomas Kalibera


On 8/23/20 5:02 PM, Rory Winston wrote:

Hi

I noticed a small inconsistency when using sum() vs cumsum()

  I have a char-based series

  > tryjpy$long

  [1] "0.0022"  "-0.0002" "-0.0149" "-0.0023" "-0.0342" "-0.0245" "-0.0022"

  [8] "0.0003"  "-0.0001" "-0.0004" "-0.0036" "-0.001"  "-0.0011" "-0.0012"

[15] "-0.0006" "0.0016"  "0.0006"

When I run sum() vs cumsum() , sum fails but cumsum converts the
series to numeric before summing:


sum(tryjpy$long)

Error in sum(tryjpy$long) : invalid 'type' (character) of argument


cumsum(tryjpy$long)

  [1]  0.0022  0.0020 -0.0129 -0.0152 -0.0494 -0.0739 -0.0761 -0.0758 -0.0759
[10] -0.0763 -0.0799 -0.0809 -0.0820 -0.0832 -0.0838 -0.0822 -0.0816

Which I guess is due to the following line in do_cum():

PROTECT(t = coerceVector(CAR(args), REALSXP));
This might be fine and there may be very good reasons why there is no
coercion in sum - just seems a little inconsistent in usage


Yes. I don't know the reason for this design, but please note it is 
documented in ?sum and in ?cumsum, which would also make it harder to 
change. One can always use a consistent subset (not rely on the coercion 
e.g. from characters).


Best
Tomas



Cheers
-- Rory

__
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] NAs and rle

Re: [Rd] trace creates object in base namespace if called on function argument

[Rd] trace creates object in base namespace if called on function argument

[R-pkg-devel] Package inputenc Error: Unicode char ‐ (U+2010) during Windows build

Re: [Rd] R 4.0.2 64-bit Windows hangs

Re: [Bioc-devel] About rcellminerData and rcellminerData new versions

Re: [Bioc-devel] About rcellminerData and rcellminerData new versions

[R-pkg-devel] Error in winbuilder

Re: [Bioc-devel] About rcellminerData and rcellminerData new versions

Re: [Rd] sum() vs cumsum() implicit type coercion

Re: [Bioc-devel] About rcellminerData and rcellminerData new versions

Re: [Rd] sum() vs cumsum() implicit type coercion

Re: [Rd] sum() vs cumsum() implicit type coercion

13 matches

Site Navigation

Mail list logo

Footer information