[Bioc-devel] Request for undeprecation of motifbreakR

2023-06-27 Thread Coetzee, Simon via Bioc-devel
Dear bioc-devel,

I am sorry for not being responsive to the error messages related to the 
building of motifbreakR.

As you can likely see, I was responsive to errors earlier in the year, entering 
many changes to keep up to date with the changing conditions of the Bioc 
universe, and bugs that I discovered (with the help of users on my github 
issues).

Earlier in the year, perhaps as a result of altering my email notifications and 
organization as a result of going on paternity leave, I somehow lost track of a 
recurrent error introduced as a response to my most recent change to 
motifbreakR, despite your repeated emails to that effect. On Tuesday June 27, I 
got an email from my PI indicating that the package has been depreciated.

It appears as though the errors were from the most recent change altering the 
examples to a couple of my functions, and I have fixed them on upstream/devel. 
Additionally, I have made sure that any email filters and organizational 
changes have been reverted to their previously functional states.

As a result of these remedies, I hope that, once again, motifbreakR can be 
reinstated to good standing in Bioconductor. Is there anything else that I can 
do to prove my continued enthusiasm and commitment to the package and community?

Thank you,

Simon Coetzee


IMPORTANT WARNING: This message is intended for the use ...{{dropped:11}}

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel


Re: [Rd] Correct use of tools::R_user_dir() in packages?

2023-06-27 Thread Dirk Eddelbuettel


On 27 June 2023 at 15:36, Carl Boettiger wrote:
| tools::R_user_dir() provides configurable directories for R packages
| to write persistent information consistent with standard best
| practices relative to each supported operating systems for
| applications to store data, config, and cache information
| respectively.  These standard best practices include writing to
| directories in the users home filespace, which is also specifically
| against CRAN policy.
| 
| These defaults can be overridden by setting the environmental
| variables R_USER_DATA_DIR , R_USER_CONFIG_DIR, R_USER_CACHE_DIR,
| respectively.
| 
| If R developers should be using the locations provided by
| tools::R_user_dir() in packages, why does CRAN's check procedure not
| set these three environmental variables to CRAN compliant location by
| default (e.g. tempdir())?
| 
| In order to comply with CRAN policy, a package developer can obviously
| set these environmental variables themselves within the call for every
| example, every unit test, and every vignette.  Is this the recommended
| approach or is there a better technique?

My use evolved to something like this (from in this case r2u, but similar in
a few other packages)

.defaultConfigFile <- function() {
pkgdir <- tools::R_user_dir(packageName())  # ~/.local/share/R/ + 
package
if (dir.exists(pkgdir)) {
fname <- file.path(pkgdir, "config.dcf")
if (file.exists(fname)) {
return(fname)
}
}
return("")
}

You can then create config reader and writers functions that have a file
argument (set to the above) whicg you can override in tests with tempfile()
allowing you to write and then read.

Given the 'thou shalt not write to $HOME' rule, I often have parameter
getters with default values which, if a config file is found (with the name
per the helper above), also read it and use it to override the defaults.
Works for me, and is lightweight via a 'using batteries included'
zero-depends approach.

Dirk

-- 
dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org

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


[Rd] Correct use of tools::R_user_dir() in packages?

2023-06-27 Thread Carl Boettiger
tools::R_user_dir() provides configurable directories for R packages
to write persistent information consistent with standard best
practices relative to each supported operating systems for
applications to store data, config, and cache information
respectively.  These standard best practices include writing to
directories in the users home filespace, which is also specifically
against CRAN policy.

These defaults can be overridden by setting the environmental
variables R_USER_DATA_DIR , R_USER_CONFIG_DIR, R_USER_CACHE_DIR,
respectively.

If R developers should be using the locations provided by
tools::R_user_dir() in packages, why does CRAN's check procedure not
set these three environmental variables to CRAN compliant location by
default (e.g. tempdir())?

In order to comply with CRAN policy, a package developer can obviously
set these environmental variables themselves within the call for every
example, every unit test, and every vignette.  Is this the recommended
approach or is there a better technique?

Thanks for any clarification!

Regards,

Carl

---
Carl Boettiger
http://carlboettiger.info/

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


Re: [Bioc-devel] psygenet2r bioconductor question

2023-06-27 Thread Kern, Lori
To get rid of the BiocStyle you need to add BiocStyle to your DESCRIPTION in 
the suggests field.

To have the changes be on the release branch, you need to alter and push 
changes on RELEASE_3_17 branch of git.bioconductor.org instead of to devel on 
git.bioconductor.org.

See:

http://contributions.bioconductor.org/git-version-control.html#bug-fix-in-release-and-devel



Lori Shepherd - Kern

Bioconductor Core Team

Roswell Park Comprehensive Cancer Center

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


From: Bioc-devel  on behalf of alba gutierrez 

Sent: Tuesday, June 27, 2023 10:10 AM
To: bioc-devel@r-project.org 
Subject: [Bioc-devel] psygenet2r bioconductor question

Dear Bioconductor Team,

I have been trying to fix my package that was failing in Bioconductor due
to a warning (not an error) on the code. I updated my github and try to
push the changes to Bioconductor, and for some reason, I cannot update the
main one.

As you can see, my last push to the dev environment was on May 22nd, and
the package is building fine,
http://secure-web.cisco.com/1BLsNasLT7jE0dM8Qu4VbJF2l4zp2AwcK2Yje6tPlpzPO_8WjF0lau6pZgC7DRuSytIPUUUMGZGVHgH4aPiCkjgAYap4CYvXil1ddwO8l0O7WLwnQPAKStIb2Rv3O7C7d71L3CYf3ZJ0963jLyLVPjFv94nVnlrBuHXCe9edHon3hxEdiy7QncCb03Z43bcBt18Tk8vvolJLTCnxtghJzETb7yME_gkMd3GSi4NZAf5Dc_gPxpnZevqVTusB_FvToENt7dvS8P9TMAy0ggN4BoSAKzyLMFtmkVvoSUlD24OkovK0kdUjv0wNXmyAuezfG/http%3A%2F%2Fbioconductor.org%2FcheckResults%2Fdevel%2Fbioc-LATEST%2Fpsygenet2r%2F
  (even
if I see now an error on Linux due to BiocStyle package on the CHECK step)

BUT I could not push the same changes to the main one, my last successful
push was on May 15th.
http://secure-web.cisco.com/1GrH89YAgTat9RKKgsO-F-LKhAIoVNMaX4cdUxHDH_qB2q01LUl42LyG_qUGxuZF24t_Sdmu7s8zSTdJDxpLbHgg5w2k7lKa2IyGxqNh1tJlhdk9O8QWDZ6wfkws1dx_XE3GKemSsOltuUntVr61u7FqqGXxxeyz1B1aVkwKWTzUi5_EYg5dq9cvg7VcVbTJNoiEQCo2lP0Fjpq30ablC-ClH2OlES88mnvvvAJgns-ctvXbOWAmMRf8Guuwg-1P0TjyLDqGH7fJ3Pd2irJijP1io6wcUFpVNeKNDYWZESst88bZOa9D66QiSJQFFvRSI/http%3A%2F%2Fbioconductor.org%2FcheckResults%2Frelease%2Fbioc-LATEST%2Fpsygenet2r%2Fnebbiolo1-buildsrc.html
instead of May 22nd. 
https://secure-web.cisco.com/16IYMq-X5pv9dp6RlqGxG8CVMv5GOU9kIh0zpMhK2Y_9Ud0P3BOEG1_Wjvj0AsOhnKDPv2M8YpaV6pSz0gCyM1lIEyukmUAi4nTvzHd8_n8AtlVtINzyTO1OghS4oT_mmbrIgp2qS2M5fxwpGghHyzelPz6SuYgu9vfpWygV1Aaes4ON-Bcvx-VSOKe5yjBwy68rsCWkFVFIMhspt5WrY802WezSU3J76nO_QzbsT5j9e4IzSca-a__QkHN-6cCr49j9fSbwjXOgEkI5GgiTbIR1SkbvvfRDacxO6-hx63lUe-S1OA_awIcRdhsJrtpAe/https%3A%2F%2Fgithub.com%2FaGutierrezSacristan%2Fpsygenet2r

Could you help me with this? I am not sure why I cannot push changes
anymore to the main one.

Thanks in advance,

Alba

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://secure-web.cisco.com/1RPMe8Z551EucdL_xAulDmZfI62ExpuJ1v476tQANSBGezvZ6fMbWdI-3-3Hn1PQt2EUmkZpknt2W6Gvb5IxS-AuAjv9gWEn2oyXCzDxqKZuOrg9WaUdjCC0hJADBKpbLcc_A0Nap6rPZ-y8whcrHI8R4xKF7UMLmXa2tNnOUOKXV4vLFjBODuLCnz7L91ed73Q0jkXqvZdjR_BNli2Qxm47nUWZZtoFKyVRWYwUhG5SBSYtczIUDnVa0X6eAPwB8JGJAc58tiPnIDTscnSFqpmoGpWMcIZpdLG2uPz_7YbxMGVPAZbo3xYsw9M4UqZlC/https%3A%2F%2Fstat.ethz.ch%2Fmailman%2Flistinfo%2Fbioc-devel



This email message may contain legally privileged and/or confidential 
information.  If you are not the intended recipient(s), or the employee or 
agent responsible for the delivery of this message to the intended 
recipient(s), you are hereby notified that any disclosure, copying, 
distribution, or use of this email message is prohibited.  If you have received 
this message in error, please notify the sender immediately by e-mail and 
delete this email message from your computer. Thank you.
[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel


[Bioc-devel] psygenet2r bioconductor question

2023-06-27 Thread alba gutierrez
Dear Bioconductor Team,

I have been trying to fix my package that was failing in Bioconductor due
to a warning (not an error) on the code. I updated my github and try to
push the changes to Bioconductor, and for some reason, I cannot update the
main one.

As you can see, my last push to the dev environment was on May 22nd, and
the package is building fine,
http://bioconductor.org/checkResults/devel/bioc-LATEST/psygenet2r/  (even
if I see now an error on Linux due to BiocStyle package on the CHECK step)

BUT I could not push the same changes to the main one, my last successful
push was on May 15th.
http://bioconductor.org/checkResults/release/bioc-LATEST/psygenet2r/nebbiolo1-buildsrc.html
instead of May 22nd. https://github.com/aGutierrezSacristan/psygenet2r

Could you help me with this? I am not sure why I cannot push changes
anymore to the main one.

Thanks in advance,

Alba

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel


Re: [R-pkg-devel] Package broke with R 4.3.0

2023-06-27 Thread Iñaki Ucar
On Tue, 27 Jun 2023 at 18:45, Jeff Newmiller  wrote:
>
> if (any(c( "alaska", "hawaii") %in% zoom)){}

Note that this changes behavior. If e.g. zoom is c("something",
"alaska"), the code above returns TRUE. Previous behavior was FALSE
(with a warning).

Iñaki

> On June 27, 2023 9:11:09 AM PDT, "Göran Broström"  wrote:
> >
> >
> >Den 2023-06-27 kl. 17:17, skrev Göran Broström:
> >> If(zoom %in% c(“alaska”,  “hawaii”)…
> >
> >Wrong, maybe
> >
> >if (("alaska" %in% zoom) || ("hawaii" %in% zoom)){}
> >
> >
> >>
> >> Göran
> >>
> >>> 27 juni 2023 kl. 16:32 skrev arilamst...@gmail.com:
> >>>
> >>> It appears that my R package choroplethr broke due to this change in R
> >>> 4.3.0:
> >>>
> >>> CHANGES IN R 4.3.0:
> >>>
> >>> SIGNIFICANT USER-VISIBLE CHANGES:
> >>>
> >>> Calling && or || with LHS or (if evaluated) RHS of length greater than one
> >>> is now always an error, with a report of the form
> >>>
> >>> 'length = 4' in coercion to 'logical(1)'
> >>> Environment variable R_CHECK_LENGTH_1_LOGIC2 no longer has any effect.
> >>>
> >>> The specific line which broke is this:
> >>> https://github.com/arilamstein/choroplethr/blob/master/R/usa.R#L24
> >>>
> >>> The bug can be reproduced like this:
> >>>
> >>> zoom = c("arizona", "arkansas", "louisiana", "minnesota", "mississippi",
> >>>   "montana", "new mexico", "north dakota", "oklahoma", "pennsylvania",
> >>>   "tennessee", "virginia", "california", "delaware", "west virginia",
> >>>   "wisconsin", "wyoming", "alabama", "alaska", "florida", "idaho",
> >>>   "kansas", "maryland", "colorado", "new jersey", "north carolina",
> >>>   "south carolina", "washington", "vermont", "utah", "iowa",
> >>> "kentucky",
> >>>   "maine", "massachusetts", "connecticut", "michigan", "missouri",
> >>>   "nebraska", "nevada", "new hampshire", "new york", "ohio", "oregon",
> >>>   "rhode island", "south dakota", "district of columbia", "texas",
> >>>   "georgia", "hawaii", "illinois", "indiana")
> >>>
> >>> if (zoom == "alaska" || zoom == "hawaii") {}
> >>> Error in zoom == "alaska" || zoom == "hawaii" :
> >>>   'length = 51' in coercion to 'logical(1)'
> >>>
> >>> I have two questions:
> >>>
> >>> 1. Can someone explain why this change was introduced to the language?
> >>> 2. Can someone tell me if there is a preferred, idiomatic way to rewrite 
> >>> my
> >>> code?
> >>>
> >>> I came up with two solutions that work. The first checks whether zoom is 
> >>> of
> >>> length 1:
> >>>
> >>> if ((length(zoom) == 1) && (zoom %in% c("alaska", "hawaii"))) { }
> >>>
> >>> The second keeps the vector recycling, but then uses all to coerce the
> >>> vector to be a single value. In retrospect, I think I likely assumed that
> >>> this is what R < 4.3.0 was doing when the code worked. (But I wrote this
> >>> code many years ago, so I can't be sure!):
> >>>
> >>> if (all(zoom == "alaska") || all(zoom == "hawaii")) {}
> >>>
> >>> Thanks in advance.
> >>>
> >>> Ari
> >>>
> >>> [[alternative HTML version deleted]]
> >>>
> >>> __
> >>> R-package-devel@r-project.org mailing list
> >>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
> >>
> >> __
> >> R-package-devel@r-project.org mailing list
> >> https://stat.ethz.ch/mailman/listinfo/r-package-devel
> >
> >__
> >R-package-devel@r-project.org mailing list
> >https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
> --
> Sent from my phone. Please excuse my brevity.
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel



-- 
Iñaki Úcar

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


Re: [R-pkg-devel] Package broke with R 4.3.0

2023-06-27 Thread Jeff Newmiller
if (any(c( "alaska", "hawaii") %in% zoom)){}

On June 27, 2023 9:11:09 AM PDT, "Göran Broström"  wrote:
>
>
>Den 2023-06-27 kl. 17:17, skrev Göran Broström:
>> If(zoom %in% c(“alaska”,  “hawaii”)…
>
>Wrong, maybe
>
>if (("alaska" %in% zoom) || ("hawaii" %in% zoom)){}
>
>
>> 
>> Göran
>> 
>>> 27 juni 2023 kl. 16:32 skrev arilamst...@gmail.com:
>>> 
>>> It appears that my R package choroplethr broke due to this change in R
>>> 4.3.0:
>>> 
>>> CHANGES IN R 4.3.0:
>>> 
>>> SIGNIFICANT USER-VISIBLE CHANGES:
>>> 
>>> Calling && or || with LHS or (if evaluated) RHS of length greater than one
>>> is now always an error, with a report of the form
>>> 
>>> 'length = 4' in coercion to 'logical(1)'
>>> Environment variable R_CHECK_LENGTH_1_LOGIC2 no longer has any effect.
>>> 
>>> The specific line which broke is this:
>>> https://github.com/arilamstein/choroplethr/blob/master/R/usa.R#L24
>>> 
>>> The bug can be reproduced like this:
>>> 
>>> zoom = c("arizona", "arkansas", "louisiana", "minnesota", "mississippi",
>>>   "montana", "new mexico", "north dakota", "oklahoma", "pennsylvania",
>>>   "tennessee", "virginia", "california", "delaware", "west virginia",
>>>   "wisconsin", "wyoming", "alabama", "alaska", "florida", "idaho",
>>>   "kansas", "maryland", "colorado", "new jersey", "north carolina",
>>>   "south carolina", "washington", "vermont", "utah", "iowa",
>>> "kentucky",
>>>   "maine", "massachusetts", "connecticut", "michigan", "missouri",
>>>   "nebraska", "nevada", "new hampshire", "new york", "ohio", "oregon",
>>>   "rhode island", "south dakota", "district of columbia", "texas",
>>>   "georgia", "hawaii", "illinois", "indiana")
>>> 
>>> if (zoom == "alaska" || zoom == "hawaii") {}
>>> Error in zoom == "alaska" || zoom == "hawaii" :
>>>   'length = 51' in coercion to 'logical(1)'
>>> 
>>> I have two questions:
>>> 
>>> 1. Can someone explain why this change was introduced to the language?
>>> 2. Can someone tell me if there is a preferred, idiomatic way to rewrite my
>>> code?
>>> 
>>> I came up with two solutions that work. The first checks whether zoom is of
>>> length 1:
>>> 
>>> if ((length(zoom) == 1) && (zoom %in% c("alaska", "hawaii"))) { }
>>> 
>>> The second keeps the vector recycling, but then uses all to coerce the
>>> vector to be a single value. In retrospect, I think I likely assumed that
>>> this is what R < 4.3.0 was doing when the code worked. (But I wrote this
>>> code many years ago, so I can't be sure!):
>>> 
>>> if (all(zoom == "alaska") || all(zoom == "hawaii")) {}
>>> 
>>> Thanks in advance.
>>> 
>>> Ari
>>> 
>>> [[alternative HTML version deleted]]
>>> 
>>> __
>>> R-package-devel@r-project.org mailing list
>>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>> 
>> __
>> R-package-devel@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel
>
>__
>R-package-devel@r-project.org mailing list
>https://stat.ethz.ch/mailman/listinfo/r-package-devel

-- 
Sent from my phone. Please excuse my brevity.

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


Re: [R-pkg-devel] Package broke with R 4.3.0

2023-06-27 Thread Göran Broström




Den 2023-06-27 kl. 17:17, skrev Göran Broström:

If(zoom %in% c(“alaska”,  “hawaii”)…


Wrong, maybe

if (("alaska" %in% zoom) || ("hawaii" %in% zoom)){}




Göran


27 juni 2023 kl. 16:32 skrev arilamst...@gmail.com:

It appears that my R package choroplethr broke due to this change in R
4.3.0:

CHANGES IN R 4.3.0:

SIGNIFICANT USER-VISIBLE CHANGES:

Calling && or || with LHS or (if evaluated) RHS of length greater than one
is now always an error, with a report of the form

'length = 4' in coercion to 'logical(1)'
Environment variable R_CHECK_LENGTH_1_LOGIC2 no longer has any effect.

The specific line which broke is this:
https://github.com/arilamstein/choroplethr/blob/master/R/usa.R#L24

The bug can be reproduced like this:

zoom = c("arizona", "arkansas", "louisiana", "minnesota", "mississippi",
  "montana", "new mexico", "north dakota", "oklahoma", "pennsylvania",
  "tennessee", "virginia", "california", "delaware", "west virginia",
  "wisconsin", "wyoming", "alabama", "alaska", "florida", "idaho",
  "kansas", "maryland", "colorado", "new jersey", "north carolina",
  "south carolina", "washington", "vermont", "utah", "iowa",
"kentucky",
  "maine", "massachusetts", "connecticut", "michigan", "missouri",
  "nebraska", "nevada", "new hampshire", "new york", "ohio", "oregon",
  "rhode island", "south dakota", "district of columbia", "texas",
  "georgia", "hawaii", "illinois", "indiana")

if (zoom == "alaska" || zoom == "hawaii") {}
Error in zoom == "alaska" || zoom == "hawaii" :
  'length = 51' in coercion to 'logical(1)'

I have two questions:

1. Can someone explain why this change was introduced to the language?
2. Can someone tell me if there is a preferred, idiomatic way to rewrite my
code?

I came up with two solutions that work. The first checks whether zoom is of
length 1:

if ((length(zoom) == 1) && (zoom %in% c("alaska", "hawaii"))) { }

The second keeps the vector recycling, but then uses all to coerce the
vector to be a single value. In retrospect, I think I likely assumed that
this is what R < 4.3.0 was doing when the code worked. (But I wrote this
code many years ago, so I can't be sure!):

if (all(zoom == "alaska") || all(zoom == "hawaii")) {}

Thanks in advance.

Ari

[[alternative HTML version deleted]]

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


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


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


Re: [R-pkg-devel] Package broke with R 4.3.0

2023-06-27 Thread Göran Broström
If(zoom %in% c(“alaska”,  “hawaii”)…

Göran

> 27 juni 2023 kl. 16:32 skrev arilamst...@gmail.com:
> 
> It appears that my R package choroplethr broke due to this change in R
> 4.3.0:
> 
> CHANGES IN R 4.3.0:
> 
> SIGNIFICANT USER-VISIBLE CHANGES:
> 
> Calling && or || with LHS or (if evaluated) RHS of length greater than one
> is now always an error, with a report of the form
> 
> 'length = 4' in coercion to 'logical(1)'
> Environment variable R_CHECK_LENGTH_1_LOGIC2 no longer has any effect.
> 
> The specific line which broke is this:
> https://github.com/arilamstein/choroplethr/blob/master/R/usa.R#L24
> 
> The bug can be reproduced like this:
> 
> zoom = c("arizona", "arkansas", "louisiana", "minnesota", "mississippi",
>  "montana", "new mexico", "north dakota", "oklahoma", "pennsylvania",
>  "tennessee", "virginia", "california", "delaware", "west virginia",
>  "wisconsin", "wyoming", "alabama", "alaska", "florida", "idaho",
>  "kansas", "maryland", "colorado", "new jersey", "north carolina",
>  "south carolina", "washington", "vermont", "utah", "iowa",
> "kentucky",
>  "maine", "massachusetts", "connecticut", "michigan", "missouri",
>  "nebraska", "nevada", "new hampshire", "new york", "ohio", "oregon",
>  "rhode island", "south dakota", "district of columbia", "texas",
>  "georgia", "hawaii", "illinois", "indiana")
> 
> if (zoom == "alaska" || zoom == "hawaii") {}
> Error in zoom == "alaska" || zoom == "hawaii" :
>  'length = 51' in coercion to 'logical(1)'
> 
> I have two questions:
> 
> 1. Can someone explain why this change was introduced to the language?
> 2. Can someone tell me if there is a preferred, idiomatic way to rewrite my
> code?
> 
> I came up with two solutions that work. The first checks whether zoom is of
> length 1:
> 
> if ((length(zoom) == 1) && (zoom %in% c("alaska", "hawaii"))) { }
> 
> The second keeps the vector recycling, but then uses all to coerce the
> vector to be a single value. In retrospect, I think I likely assumed that
> this is what R < 4.3.0 was doing when the code worked. (But I wrote this
> code many years ago, so I can't be sure!):
> 
> if (all(zoom == "alaska") || all(zoom == "hawaii")) {}
> 
> Thanks in advance.
> 
> Ari
> 
>[[alternative HTML version deleted]]
> 
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel

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


Re: [R-pkg-devel] Package broke with R 4.3.0

2023-06-27 Thread Iñaki Ucar
On Tue, 27 Jun 2023 at 16:31,  wrote:
>
> It appears that my R package choroplethr broke due to this change in R
> 4.3.0:
>
> CHANGES IN R 4.3.0:
>
> SIGNIFICANT USER-VISIBLE CHANGES:
>
> Calling && or || with LHS or (if evaluated) RHS of length greater than one
> is now always an error, with a report of the form
>
> 'length = 4' in coercion to 'logical(1)'
> Environment variable R_CHECK_LENGTH_1_LOGIC2 no longer has any effect.
>
> The specific line which broke is this:
> https://github.com/arilamstein/choroplethr/blob/master/R/usa.R#L24
>
> The bug can be reproduced like this:
>
> zoom = c("arizona", "arkansas", "louisiana", "minnesota", "mississippi",
>   "montana", "new mexico", "north dakota", "oklahoma", "pennsylvania",
>   "tennessee", "virginia", "california", "delaware", "west virginia",
>   "wisconsin", "wyoming", "alabama", "alaska", "florida", "idaho",
>   "kansas", "maryland", "colorado", "new jersey", "north carolina",
>   "south carolina", "washington", "vermont", "utah", "iowa",
> "kentucky",
>   "maine", "massachusetts", "connecticut", "michigan", "missouri",
>   "nebraska", "nevada", "new hampshire", "new york", "ohio", "oregon",
>   "rhode island", "south dakota", "district of columbia", "texas",
>   "georgia", "hawaii", "illinois", "indiana")
>
> if (zoom == "alaska" || zoom == "hawaii") {}
> Error in zoom == "alaska" || zoom == "hawaii" :
>   'length = 51' in coercion to 'logical(1)'
>
> I have two questions:
>
> 1. Can someone explain why this change was introduced to the language?

This was incorrect code before, and should be fixed; this didn't
change. The change is that now it always triggers an error.

> 2. Can someone tell me if there is a preferred, idiomatic way to rewrite my
> code?

Option 1:
if (identical(zoom, "alaska") || identical(zoom, "hawaii")) {}

Option 2:
if (isTRUE(zoom == "alaska") || isTRUE(zoom == "hawaii")) {}

> I came up with two solutions that work. The first checks whether zoom is of
> length 1:
>
> if ((length(zoom) == 1) && (zoom %in% c("alaska", "hawaii"))) { }

This works too.

> The second keeps the vector recycling, but then uses all to coerce the
> vector to be a single value. In retrospect, I think I likely assumed that
> this is what R < 4.3.0 was doing when the code worked. (But I wrote this
> code many years ago, so I can't be sure!):

Before R 4.3.0, there was a warning, and the string was compared with
the first value only.

Iñaki


> if (all(zoom == "alaska") || all(zoom == "hawaii")) {}
>
> Thanks in advance.
>
> Ari
>
> [[alternative HTML version deleted]]
>
> __
> R-package-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-package-devel



-- 
Iñaki Úcar

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


[R-pkg-devel] Package broke with R 4.3.0

2023-06-27 Thread arilamstein
It appears that my R package choroplethr broke due to this change in R
4.3.0:

CHANGES IN R 4.3.0:

SIGNIFICANT USER-VISIBLE CHANGES:

Calling && or || with LHS or (if evaluated) RHS of length greater than one
is now always an error, with a report of the form

'length = 4' in coercion to 'logical(1)'
Environment variable R_CHECK_LENGTH_1_LOGIC2 no longer has any effect.

The specific line which broke is this:
https://github.com/arilamstein/choroplethr/blob/master/R/usa.R#L24

The bug can be reproduced like this:

zoom = c("arizona", "arkansas", "louisiana", "minnesota", "mississippi",
  "montana", "new mexico", "north dakota", "oklahoma", "pennsylvania",
  "tennessee", "virginia", "california", "delaware", "west virginia",
  "wisconsin", "wyoming", "alabama", "alaska", "florida", "idaho",
  "kansas", "maryland", "colorado", "new jersey", "north carolina",
  "south carolina", "washington", "vermont", "utah", "iowa",
"kentucky",
  "maine", "massachusetts", "connecticut", "michigan", "missouri",
  "nebraska", "nevada", "new hampshire", "new york", "ohio", "oregon",
  "rhode island", "south dakota", "district of columbia", "texas",
  "georgia", "hawaii", "illinois", "indiana")

if (zoom == "alaska" || zoom == "hawaii") {}
Error in zoom == "alaska" || zoom == "hawaii" :
  'length = 51' in coercion to 'logical(1)'

I have two questions:

1. Can someone explain why this change was introduced to the language?
2. Can someone tell me if there is a preferred, idiomatic way to rewrite my
code?

I came up with two solutions that work. The first checks whether zoom is of
length 1:

if ((length(zoom) == 1) && (zoom %in% c("alaska", "hawaii"))) { }

The second keeps the vector recycling, but then uses all to coerce the
vector to be a single value. In retrospect, I think I likely assumed that
this is what R < 4.3.0 was doing when the code worked. (But I wrote this
code many years ago, so I can't be sure!):

if (all(zoom == "alaska") || all(zoom == "hawaii")) {}

Thanks in advance.

Ari

[[alternative HTML version deleted]]

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


[Bioc-devel] List of Deprecated Packages for Bioc3.18

2023-06-27 Thread Kern, Lori
The Bioconductor Team is continuing to identify packages that will be 
deprecated in the next release to allow for the Bioconductor community to 
respond accordingly. This is the current list of deprecated packages for Bioc 
3.17:



Software:

Unresponsive:

  *   baySeq
  *   BGmix
  *   BioMM
  *   biomvRCNS
  *   deco
  *   genbankr
  *   HPAStainR
  *   hypeR
  *   imageHTS
  *   motifbreakR
  *   netbiov
  *   plethy
  *   qrqc
  *   RNAdecay
  *   SOMNiBUS
  *   TCseq
  *   Travel
  *   tweeDEseq

It should be noted, we did try to reach out to these package maintainers 
multiple times and they were either unresponsive or had emails bounce. We 
encourage anyone that is familiar with a package maintainer on this list to 
reach out to them and notify them directly. Packages can be un-deprecated if a 
maintainer fixes the package to build/check cleanly before the next release and 
requests un-deprecation on the bioc-devel@r-project.org mailing list

Please do not undeprecate a package yourself. You must request undeprecation 
from the Bioconductor core team at bioc-devel@r-project.org.



Lori Shepherd - Kern

Bioconductor Core Team

Roswell Park Comprehensive Cancer Center

Department of Biostatistics & Bioinformatics

Elm & Carlton Streets

Buffalo, New York 14263


This email message may contain legally privileged and/or confidential 
information.  If you are not the intended recipient(s), or the employee or 
agent responsible for the delivery of this message to the intended 
recipient(s), you are hereby notified that any disclosure, copying, 
distribution, or use of this email message is prohibited.  If you have received 
this message in error, please notify the sender immediately by e-mail and 
delete this email message from your computer. Thank you.
[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel


Re: [Bioc-devel] SVMDO Bioc 3.18 Kunpeng2 error

2023-06-27 Thread Martin Grigorov
Hi,

Last week we updated R from 4.3.0 to 4.3.1 with empty site-library/ folder.
All packages are being re-installed and some of them timed out.

I just checked and both klaR and org.Hs.eg.db are installed. Please
re-check the results later today!

Regards,
Martin

On Tue, Jun 27, 2023 at 11:25 AM erhanozer19 via Bioc-devel <
bioc-devel@r-project.org> wrote:

> Dear Bioconductor Community,
>
> In BioC 3.18 build/check, kunpeng2 linux ARM64 reports this error:
>
> ERROR: dependencies ‘klaR’, ‘org.Hs.eg.db’ are not available for package
> ‘SVMDO’
>
> Is this a kunpeng2 related problem?
>
> ___
> Bioc-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel


[Bioc-devel] SVMDO Bioc 3.18 Kunpeng2 error

2023-06-27 Thread erhanozer19 via Bioc-devel

Dear Bioconductor Community,

In BioC 3.18 build/check, kunpeng2 linux ARM64 reports this error:

ERROR: dependencies ‘klaR’, ‘org.Hs.eg.db’ are not available for package 
‘SVMDO’


Is this a kunpeng2 related problem?

___
Bioc-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/bioc-devel