Re: [Bioc-devel] Biostrings: substitution matrices disappeared?

[Martin Grigorov]

Hi,

Yesterday there was another email about Biostrings -
https://stat.ethz.ch/pipermail/bioc-devel/2024-April/020395.html
I thought it might be related to your problem.

Regards,
Martin

On Thu, Apr 25, 2024 at 8:23 AM Ulrich Bodenhofer <
ulrich.bodenho...@gmail.com> wrote:

> Dear colleagues, dear BioC core team,
>
> One of my packages in the devel branch, the ‘msa’ package seems broken
> since
> yesterday. The vignette does not run anymore (therefore, the package does
> not build), and the reason is that the BLOSUM62 substitution matrix cannot
> be loaded form the ‘Biostrings’ package anymore. I checked the ‘Biostrings’
> package. In Version 2.70.3 in the release branch, the substitution matrices
> were still in the ‘data/’ directory. In the current devel version 2.71.6,
> they have disappeared. I found no hint to that in the NEWS file. So, I want
> to kindly ask the maintainers of the ‘Biostrings’ package to give me some
> advice how to fix that on my side or, in case that this is an error in the
> current devel version of the ‘Biostrings’ package, to have a look into
> this.
>
> Thanks a lot in advance, best regards,
> Ulrich
>
> ___
> 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] Biostrings: substitution matrices disappeared?

[Ulrich Bodenhofer]

Dear colleagues, dear BioC core team,

One of my packages in the devel branch, the ‘msa’ package seems broken since
yesterday. The vignette does not run anymore (therefore, the package does
not build), and the reason is that the BLOSUM62 substitution matrix cannot
be loaded form the ‘Biostrings’ package anymore. I checked the ‘Biostrings’
package. In Version 2.70.3 in the release branch, the substitution matrices
were still in the ‘data/’ directory. In the current devel version 2.71.6,
they have disappeared. I found no hint to that in the NEWS file. So, I want
to kindly ask the maintainers of the ‘Biostrings’ package to give me some
advice how to fix that on my side or, in case that this is an error in the
current devel version of the ‘Biostrings’ package, to have a look into this.

Thanks a lot in advance, best regards,
Ulrich

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

Re: [Rd] [External] Re: Is ALTREP "non-API"?

[luke-tierney--- via R-devel]

On Wed, 24 Apr 2024, Hadley Wickham wrote:


A few more thoughts based on a simple question: how do you determine the
length of a vector?

Rf_length() is used in example code in R-exts, but I don't think it's
formally documented anywhere (although it's possible I missed it). Is using
in an example sufficient to consider a function to be part of the public
API? If so, SET_TYPEOF() is used in a number of examples, and hence used by
CRAN packages, but is no longer considered part of the public API.

Rf_xlength() doesn't appear to be mentioned anywhere in R-exts. Does this
imply that long vectors are not part of the exported API? Or is there some
other way we should be determining the length of such vectors?

Are the macro variants LENGTH and XLENGTH part of the exported API? Are we
supposed to use them or avoid them?

Relatedly, I presume that LOGICAL() is the way we're supposed to extract
logical values from a vector, but it isn't documented in R-exts, suggesting
that it's not part of the public API?


My pragmatic approach to deciding if an entry point is usable in a
package is to

grep for it in the installed headers

grep for it in WRE

if those are good, check the text in both places to make sure it
doesn't tell me not to use is

The first two can be automated; the text reading can't for now.

One place this runs into trouble is when the prose in WRE doesn't
explicitly mention the entry point, but says something like 'this one
and similar ones are OK'. A couple of years ago I worked on improving
some of those by explicitly adding some of those implicit ones, which
did sometimes make the text more cumbersome. I'm pretty sure I added
LOGICAL() and RAW() at that point (but may be mis-remebering); they
are there now. In some other cases I left the text alone but added
index entries. That makes them findable with a text search. I think I
got most that can be handled that way, but there may be some others
left. Far from ideal, but at least a step forward.



---

It's also worth pointing out where R-exts does well, with the documentation
of utility functions (
https://cran.r-project.org/doc/manuals/R-exts.html#Utility-functions). I
think this is what most people would consider documentation to imply, i.e.
a list of input arguments/types, the output type, and basic notes on their
operation.
---

Finally, it's worth noting that there's some lingering ill feelings over
how the connections API was treated. It was documented in R-exts only to be
later removed, including expunging mentions of it in the news. That's
obviously water under the bridge, but I do believe that there is
the potential for the R core team to build goodwill with the community if
they are willing to engage a bit more with the users of their APIs.


As you well know R-core is not a monolith. There are several R-core
members who also are not happy about how that played out and where
that stands now. But there was and is no viable option other than to
agree to disagree. There is really no upside to re-litigating this
now.

Best,

luke



Hadley

[[alternative HTML version deleted]]

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



--
Luke Tierney
Ralph E. Wareham Professor of Mathematical Sciences
University of Iowa  Phone: 319-335-3386
Department of Statistics andFax:   319-335-3017
   Actuarial Science
241 Schaeffer Hall  email:   luke-tier...@uiowa.edu
Iowa City, IA 52242 WWW:  http://www.stat.uiowa.edu/

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

Re: [Rd] View() segfaulting ...

[Ben Bolker]

As suggested by Josh Ulrich, here's what I get when running under 
valgrind.



$ R -d valgrind
==218120== Memcheck, a memory error detector
==218120== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==218120== Using Valgrind-3.18.1 and LibVEX; rerun with -h for copyright 
info

==218120== Command: /usr/local/lib/R/bin/exec/R
==218120==

R Under development (unstable) (2024-04-24 r86483) -- "Unsuffered 
Consequences"

Copyright (C) 2024 The R Foundation for Statistical Computing
Platform: x86_64-pc-linux-gnu

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.

  Natural language support but running in an English locale

R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.

Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.

gcoto> gctorture(TRUE)
> View(1:3)
*** stack smashing detected ***: terminated
==218120==
==218120== Process terminating with default action of signal 6 (SIGABRT)
==218120==at 0x4D619FC: __pthread_kill_implementation 
(pthread_kill.c:44)

==218120==by 0x4D619FC: __pthread_kill_internal (pthread_kill.c:78)
==218120==by 0x4D619FC: pthread_kill@@GLIBC_2.34 (pthread_kill.c:89)
==218120==by 0x4D0D475: raise (raise.c:26)
==218120==by 0x4CF37F2: abort (abort.c:79)
==218120==by 0x4D54675: __libc_message (libc_fatal.c:155)
==218120==by 0x4E01599: __fortify_fail (fortify_fail.c:26)
==218120==by 0x4E01565: __stack_chk_fail (stack_chk_fail.c:24)
==218120==by 0x27B686AD: in_R_X11_dataviewer (dataentry.c:540)
==218120==by 0x495C7C7: do_External (dotcode.c:573)
==218120==by 0x499A07F: bcEval_loop (eval.c:8141)
==218120==by 0x49B501C: bcEval (eval.c:7524)
==218120==by 0x49B501C: bcEval (eval.c:7509)
==218120==by 0x49B538A: Rf_eval (eval.c:1167)
==218120==by 0x49B755E: R_execClosure (eval.c:2398)
==218120==
==218120== HEAP SUMMARY:
==218120== in use at exit: 42,061,827 bytes in 9,305 blocks
==218120==   total heap usage: 23,905 allocs, 14,600 frees, 66,039,858 
bytes allocated

==218120==
==218120== LEAK SUMMARY:
==218120==definitely lost: 0 bytes in 0 blocks
==218120==indirectly lost: 0 bytes in 0 blocks
==218120==  possibly lost: 5,868 bytes in 14 blocks
==218120==still reachable: 42,055,959 bytes in 9,291 blocks
==218120==   of which reachable via heuristic:
==218120== newarray   : 4,264 bytes in 1 
blocks

==218120== suppressed: 0 bytes in 0 blocks
==218120== Rerun with --leak-check=full to see details of leaked memory
==218120==
==218120== For lists of detected and suppressed errors, rerun with: -s
==218120== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Aborted (core dumped)
bolker:~/R$

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

[Rd] View() segfaulting ...

[Ben Bolker]

  I'm using bleeding-edge R-devel, so maybe my build is weird. Can 
anyone else reproduce this?


  View() seems to crash on just about anything.

View(1:3)
*** stack smashing detected ***: terminated
Aborted (core dumped)

  If I debug(View) I get to the last line of code with nothing 
obviously looking pathological:


Browse[1]>
debug: invisible(.External2(C_dataviewer, x, title))
Browse[1]> x
$x
[1] "1" "2" "3"

Browse[1]> title
[1] "Data: 1:3"
Browse[1]>
*** stack smashing detected ***: terminated
Aborted (core dumped)




R Under development (unstable) (2024-04-24 r86483)
Platform: x86_64-pc-linux-gnu
Running under: Pop!_OS 22.04 LTS

Matrix products: default
BLAS/LAPACK: 
/usr/lib/x86_64-linux-gnu/openblas-pthread/libopenblasp-r0.3.20.so; 
LAPACK version 3.10.0


locale:
 [1] LC_CTYPE=en_CA.UTF-8   LC_NUMERIC=C
 [3] LC_TIME=en_CA.UTF-8LC_COLLATE=en_CA.UTF-8
 [5] LC_MONETARY=en_CA.UTF-8LC_MESSAGES=en_CA.UTF-8
 [7] LC_PAPER=en_CA.UTF-8   LC_NAME=C
 [9] LC_ADDRESS=C   LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_CA.UTF-8 LC_IDENTIFICATION=C

time zone: America/Toronto
tzcode source: system (glibc)

attached base packages:
[1] stats graphics  grDevices utils datasets  methods   base

loaded via a namespace (and not attached):
[1] compiler_4.5.0

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

Re: [Rd] [External] Re: Is ALTREP "non-API"?

[Henrik Bengtsson]

On Wed, Apr 24, 2024 at 1:32 PM luke-tierney--- via R-devel
 wrote:
>
> On Wed, 24 Apr 2024, Hadley Wickham wrote:
>
> >>
> >>
> >>
> > That is not true at all - the presence of header does not constitute
>  declaration of something as the R API. There are cases where internal
>  functions are in the headers for historical or other reasons since the
>  headers are used both for the internal implementation and packages.
> >> That's
>  why this is in R-exts under "The R API: entry points for C code":
> >
> > If I understand your point correctly, does this mean that
>  Rf_allocVector() is not part of the "official" R API? It does not
> >> appear to
>  be documented in the "The R API: entry points for C code" section.
> >
> 
>  It does, obviously:
>  https://cran.r-project.org/doc/manuals/R-exts.html#Allocating-storage-1
> >>>
> >>>
> >>> I'm just trying to understand the precise definition of the official API
> >>> here. So it's any function mentioned in R-exts, regardless of which
> >> section
> >>> it appears in?
> >>>
> >>> Does this sentence imply that all functions starting with alloc* are part
> >>> of the official API?
> >>>
> >>
> >> Again, I can only quote the R-exts (few lines below the previous "The R
> >> API" quote):
> >>
> >>
> >> We can classify the entry points as
> >> API
> >> Entry points which are documented in this manual and declared in an
> >> installed header file. These can be used in distributed packages and will
> >> only be changed after deprecation.
> >>
> >>
> >> It says "in this manual" - I don't see anywhere restriction on a
> >> particular section of the manual, so I really don't see why you would think
> >> that allocation is not part on the API.
> >>
> >
> > Because you mentioned that section explicitly earlier in the thread. This
> > obviously seems clear to you, but it's not at all clear to me and I suspect
> > many of the wider community. It's frustrating because we are trying
> > our best to do what y'all want us to do, but it feels like we keep getting
> > the rug pulled out from under us with very little notice, and then have to
> > spend a large amount of time figuring out workarounds.
>
> Please try to keep this discussion non-adversarial.
>
> > That is at least
> > feasible for my team since we have multiple talented folks who are paid
> > full-time to work on R, but it's a huge struggle for most people who are
> > generally maintaining packages in their spare time.
>
> As you well know, almost all R-core members are also trying to
> maintain and improve R in their spare time. Good for folks to keep in
> mind before demanding R-core do X, Y, or Z for you.
>
> > For the purposes of this discussion could you please "documented in the
> > manual" means? For example, this line mentions allocXxx functions: "There
> > are quite a few allocXxx functions defined in Rinternals.h—you may want to
> > explore them.". Does that imply that they are documented and free to use?
>
> Where we are now in terms of what package authors can use to write R
> extensions has evolved organically over many years. The current state
> is certainly not ideal:
>
>  There are entry points in installed headers that might be
>  available;
>
>  but to find out if they are in fact available requires reading
>  prose text in the header files and in WRE.
>
> Trying to fine-tune wording in WRE, or add a lot of additional entries
> is not really a good or realistic way forward: WRE is both
> documentation and tutorial and more legalistic language/more complete
> coverage would make it less readable and still not guarantee
> completeness or clarity.
>
> We would be better off (in my view, not necessarily shared by others
> in R-core) if we could get to a point where:
>
>  all entry points listed in installed header files can be used in
>  packages, at least with some caveats;
>
>  the caveats are expressed in a standard way that is searchable,
>  e.g. with a standardized comment syntax at the header file or
>  individual declaration level.
>
> In principle this is achievable, but getting there from where we are
> now is a lot of work. There are some 500 entry points in the R shared
> library that are in the installed headers but not mentioned in WRE.
> These would need to be reviewed and adjusted. My guess is about a
> third are fine and intended to be API-stable, another third are not
> used in packages and don't need to be in public headers. The remainder
> are things that may be used in current packages but really should not
> be, for example because they expose internal data in ways that can
> cause segfaults or they make it difficult to implement performance
> improvements in the base engine. Sorting through these and working
> with package authors to find alternate, safer options takes a lot of
> time (see 'spare time' above) and energy (some package authors are
> easier to work with than others). Several of us 

Re: [Rd] Question regarding .make_numeric_version with non-character input

[Hervé Pagès]

Hi Kurt,

Is it intended that numeric_version() returns an error by default on 
non-character input in R 4.4.0? It seems that I can turn this into a 
warning by setting 
_R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_=false but I don't seem 
to be able to find any of this mentioned in the NEWS file.

Thanks,

H.

On 4/1/24 05:28, Kurt Hornik wrote:
>> Andrea Gilardi via R-devel writes:
> Thanks: should be fixed now in the trunk.
>
> Best
> -k
>
>> Thank you very much Dirk for your kind words and for confirming the bug.
>> Next week I will open a new issue on Bugzilla adding the related patch.
>> Kind regards
>> Andrea
>> On 29/03/2024 20:14, Dirk Eddelbuettel wrote:
>>> On 29 March 2024 at 17:56, Andrea Gilardi via R-devel wrote:
>>> | Dear all,
>>> |
>>> | I have a question regarding the R-devel version of 
>>> .make_numeric_version() function. As far as I can understand, the current 
>>> code 
>>> (https://github.com/wch/r-source/blob/66b91578dfc85140968f07dd4e72d8cb8a54f4c6/src/library/base/R/version.R#L50-L56)
>>>  runs the following steps in case of non-character input:
>>> |
>>> | 1. It creates a message named msg using gettextf.
>>> | 2. Such object is then passed to stop(msg) or warning(msg) according to 
>>> the following condition
>>> |
>>> | tolower(Sys.getenv("_R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_") != 
>>> "false")
>>> |
>>> | However, I don't understand the previous code since the output of 
>>> Sys.getenv("_R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_") != "false" 
>>> is just a boolean value and tolower() will just return "true" or "false". 
>>> Maybe the intended code is 
>>> tolower(Sys.getenv("_R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_")) != 
>>> "false" ? Or am I missing something?
>>>
>>> Yes, agreed -- good catch.  In full, the code is (removing leading
>>> whitespace, and putting it back onto single lines)
>>>
>>> msg <- gettextf("invalid non-character version specification 'x' (type: 
>>> %s)", typeof(x))
>>> if(tolower(Sys.getenv("_R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_") 
>>> != "false"))
>>> stop(msg, domain = NA)
>>> else
>>> warning(msg, domain = NA, immediate. = TRUE)
>>>
>>> where msg is constant (but reflecting language settings via standard i18n)
>>> and as you not the parentheses appear wrong.  What was intended is likely
>>>
>>> msg <- gettextf("invalid non-character version specification 'x' (type: 
>>> %s)", typeof(x))
>>> if(tolower(Sys.getenv("_R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_")) 
>>> != "false")
>>> stop(msg, domain = NA)
>>> else
>>> warning(msg, domain = NA, immediate. = TRUE)
>>>
>>> If you use bugzilla before and have a handle, maybe file a bug report with
>>> this as patch athttps://bugs.r-project.org/
>>>
>>> Dirk
>>>
>> __
>> 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

-- 
Hervé Pagès

Bioconductor Core Team
hpages.on.git...@gmail.com

[[alternative HTML version deleted]]

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

Re: [Rd] [External] Re: Is ALTREP "non-API"?

[luke-tierney--- via R-devel]

On Wed, 24 Apr 2024, Hadley Wickham wrote:






That is not true at all - the presence of header does not constitute

declaration of something as the R API. There are cases where internal
functions are in the headers for historical or other reasons since the
headers are used both for the internal implementation and packages.

That's

why this is in R-exts under "The R API: entry points for C code":


If I understand your point correctly, does this mean that

Rf_allocVector() is not part of the "official" R API? It does not

appear to

be documented in the "The R API: entry points for C code" section.




It does, obviously:
https://cran.r-project.org/doc/manuals/R-exts.html#Allocating-storage-1



I'm just trying to understand the precise definition of the official API
here. So it's any function mentioned in R-exts, regardless of which

section

it appears in?

Does this sentence imply that all functions starting with alloc* are part
of the official API?



Again, I can only quote the R-exts (few lines below the previous "The R
API" quote):


We can classify the entry points as
API
Entry points which are documented in this manual and declared in an
installed header file. These can be used in distributed packages and will
only be changed after deprecation.


It says "in this manual" - I don't see anywhere restriction on a
particular section of the manual, so I really don't see why you would think
that allocation is not part on the API.



Because you mentioned that section explicitly earlier in the thread. This
obviously seems clear to you, but it's not at all clear to me and I suspect
many of the wider community. It's frustrating because we are trying
our best to do what y'all want us to do, but it feels like we keep getting
the rug pulled out from under us with very little notice, and then have to
spend a large amount of time figuring out workarounds.


Please try to keep this discussion non-adversarial.


That is at least
feasible for my team since we have multiple talented folks who are paid
full-time to work on R, but it's a huge struggle for most people who are
generally maintaining packages in their spare time.


As you well know, almost all R-core members are also trying to
maintain and improve R in their spare time. Good for folks to keep in
mind before demanding R-core do X, Y, or Z for you.


For the purposes of this discussion could you please "documented in the
manual" means? For example, this line mentions allocXxx functions: "There
are quite a few allocXxx functions defined in Rinternals.h—you may want to
explore them.". Does that imply that they are documented and free to use?


Where we are now in terms of what package authors can use to write R
extensions has evolved organically over many years. The current state
is certainly not ideal:

There are entry points in installed headers that might be
available;

but to find out if they are in fact available requires reading
prose text in the header files and in WRE.

Trying to fine-tune wording in WRE, or add a lot of additional entries
is not really a good or realistic way forward: WRE is both
documentation and tutorial and more legalistic language/more complete
coverage would make it less readable and still not guarantee
completeness or clarity.

We would be better off (in my view, not necessarily shared by others
in R-core) if we could get to a point where:

all entry points listed in installed header files can be used in
packages, at least with some caveats;

the caveats are expressed in a standard way that is searchable,
e.g. with a standardized comment syntax at the header file or
individual declaration level.

In principle this is achievable, but getting there from where we are
now is a lot of work. There are some 500 entry points in the R shared
library that are in the installed headers but not mentioned in WRE.
These would need to be reviewed and adjusted. My guess is about a
third are fine and intended to be API-stable, another third are not
used in packages and don't need to be in public headers. The remainder
are things that may be used in current packages but really should not
be, for example because they expose internal data in ways that can
cause segfaults or they make it difficult to implement performance
improvements in the base engine. Sorting through these and working
with package authors to find alternate, safer options takes a lot of
time (see 'spare time' above) and energy (some package authors are
easier to work with than others). Several of us have taken cracks at
moving this forward from time to time, but it rarely gets to the top
of anyone's priority list.


And in general, I'd urge R Core to make an explicit list of functions that
you consider to be part of the exported API, and then grandfather in
packages that used those functions prior to learning that we weren't
supposed to.


Making a list and hoping that it will remain up to date is not
realistic.  The only way that would 

Re: [Rd] Is ALTREP "non-API"?

[Simon Urbanek]

> On Apr 25, 2024, at 12:55 AM, Hadley Wickham  wrote:
> 
> 
> 
> >>> That is not true at all - the presence of header does not constitute
> >> declaration of something as the R API. There are cases where internal
> >> functions are in the headers for historical or other reasons since the
> >> headers are used both for the internal implementation and packages. That's
> >> why this is in R-exts under "The R API: entry points for C code":
> >>> 
> >>> If I understand your point correctly, does this mean that
> >> Rf_allocVector() is not part of the "official" R API? It does not appear to
> >> be documented in the "The R API: entry points for C code" section.
> >>> 
> >> 
> >> It does, obviously:
> >> https://cran.r-project.org/doc/manuals/R-exts.html#Allocating-storage-1
> > 
> > 
> > I'm just trying to understand the precise definition of the official API
> > here. So it's any function mentioned in R-exts, regardless of which section
> > it appears in?
> > 
> > Does this sentence imply that all functions starting with alloc* are part
> > of the official API?
> > 
> 
> Again, I can only quote the R-exts (few lines below the previous "The R API" 
> quote):
> 
> 
> We can classify the entry points as
> API
> Entry points which are documented in this manual and declared in an installed 
> header file. These can be used in distributed packages and will only be 
> changed after deprecation.
> 
> 
> It says "in this manual" - I don't see anywhere restriction on a particular 
> section of the manual, so I really don't see why you would think that 
> allocation is not part on the API.
> 
> Because you mentioned that section explicitly earlier in the thread. This 
> obviously seems clear to you, but it's not at all clear to me and I suspect 
> many of the wider community. It's frustrating because we are trying our best 
> to do what y'all want us to do, but it feels like we keep getting the rug 
> pulled out from under us with very little notice, and then have to spend a 
> large amount of time figuring out workarounds. That is at least feasible for 
> my team since we have multiple talented folks who are paid full-time to work 
> on R, but it's a huge struggle for most people who are generally maintaining 
> packages in their spare time.
> 


I must be missing something here since I have no idea what you are talking 
about. The whole point if a stable API is that no rugs are pulled, so in fact 
it's exactly the opposite of what you claim - the notice is at least a year due 
to the release cycle, typically more. Unlike many other languages and 
ecosystems, R public API does not change very often - and R-core is thinking 
hard about making breaking changes if at all. In fact, I hear more complaints 
that the API does NOT change and we are too conservative, precisely because we 
want to avoid unnecessary breakage.

I will not further comment here - all I did was to point out the relevant text 
from R-exts which is the canonical source of information. If you have issues, 
find some parts unclear and want to improve the documentation, I would like to 
invite you to contribute constructively, propose changes, submit patches. The 
R-exts document has been around for decades, so it seem implausible that all of 
sudden it is being misunderstood the way you portrayed it, but it is certainly 
a good idea to improve documentation so contributions are welcome.

Cheers,
Simon

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

Re: [Rd] Is ALTREP "non-API"?

[Hadley Wickham]

A few more thoughts based on a simple question: how do you determine the
length of a vector?

Rf_length() is used in example code in R-exts, but I don't think it's
formally documented anywhere (although it's possible I missed it). Is using
in an example sufficient to consider a function to be part of the public
API? If so, SET_TYPEOF() is used in a number of examples, and hence used by
CRAN packages, but is no longer considered part of the public API.

Rf_xlength() doesn't appear to be mentioned anywhere in R-exts. Does this
imply that long vectors are not part of the exported API? Or is there some
other way we should be determining the length of such vectors?

Are the macro variants LENGTH and XLENGTH part of the exported API? Are we
supposed to use them or avoid them?

Relatedly, I presume that LOGICAL() is the way we're supposed to extract
logical values from a vector, but it isn't documented in R-exts, suggesting
that it's not part of the public API?

---

It's also worth pointing out where R-exts does well, with the documentation
of utility functions (
https://cran.r-project.org/doc/manuals/R-exts.html#Utility-functions). I
think this is what most people would consider documentation to imply, i.e.
a list of input arguments/types, the output type, and basic notes on their
operation.
---

Finally, it's worth noting that there's some lingering ill feelings over
how the connections API was treated. It was documented in R-exts only to be
later removed, including expunging mentions of it in the news. That's
obviously water under the bridge, but I do believe that there is
the potential for the R core team to build goodwill with the community if
they are willing to engage a bit more with the users of their APIs.

Hadley

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] nebbiolo1 - build report

[Jennifer Wokaty]

The new report is 
available:https://bioconductor.org/checkResults/3.19/bioc-LATEST/MSA2dist/.

Jennifer Wokaty (they/them)

Waldron Lab at CUNY SPH
Bioconductor Core Team

From: Bioc-devel  on behalf of Herv� Pag�s 

Sent: Wednesday, April 24, 2024 12:27 PM
To: Kristian Ullrich ; bioc-devel@r-project.org 

Subject: Re: [Bioc-devel] nebbiolo1 - build report

* This email originates from a sender outside of CUNY. Verify the sender before 
replying or clicking on links and attachments. *

As for the error you will see when today's report gets published it's
caused by the recent move of the pairwiseAlignment stuff from Biostrings
to the new pwalign package. I fixed it in MSA2dist 1.7.6 so it will go
away in tomorrow's report. Please resync your GitHub repo with
git.bioconductor.org when you get a chance.

H.

On 4/24/24 09:18, Herv� Pag�s wrote:
>
> Hi Kristian,
>
> I believe that this is because the new report didn't get published yet
> so the links in the email you received still points to yesterday's
> report. We're investigating.
>
> Best,
>
> H.
>
> On 4/24/24 09:10, Kristian Ullrich wrote:
>> Hi,
>>
>> I just got an email from bbs:
>>
>> Hi MSA2dist maintainer,
>>
>> According to the Multiple platform build/check report for BioC 3.19,
>> the MSA2dist package has the following problem(s):
>>
>>   o ERROR for 'R CMD INSTALL' on nebbiolo1. See the details here:
>>   
>> https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fbioconductor.org%2FcheckResults%2F3.19%2Fbioc-LATEST%2FMSA2dist%2Fnebbiolo1-install.html__%3B!!PxiZbSOawA!JXtUuFyazbia9xcI2poFmD8RwdzAoeA2p7qo-3E8uEECTMUF2RvOae17q7c7nyyINmLgkWqYpfynvaOjuqOgs8-a3E7pTy5hhQPfEg%24=05%7C02%7Cjennifer.wokaty%40sph.cuny.edu%7C50043778ddea452e058a08dc647c75f6%7C6f60f0b35f064e099715989dba8cc7d8%7C0%7C0%7C638495732936269396%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=xrT6KZN0S9x5lltJLUTmmitRNT881m0wgfoBhW0OhMU%3D=0
>>
>> >  >
>>
>>   o ERROR for 'R CMD build' on nebbiolo1. See the details here:
>>   
>> https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.com%2Fv3%2F__https%3A%2F%2Fbioconductor.org%2FcheckResults%2F3.19%2Fbioc-LATEST%2FMSA2dist%2Fnebbiolo1-buildsrc.html__%3B!!PxiZbSOawA!JXtUuFyazbia9xcI2poFmD8RwdzAoeA2p7qo-3E8uEECTMUF2RvOae17q7c7nyyINmLgkWqYpfynvaOjuqOgs8-a3E7pTy6dYC38CA%24=05%7C02%7Cjennifer.wokaty%40sph.cuny.edu%7C50043778ddea452e058a08dc647c75f6%7C6f60f0b35f064e099715989dba8cc7d8%7C0%7C0%7C638495732936292827%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=EWzdda0QeS0ADA55wWN7agnv7qfVmg96gQw%2FVQgQMLY%3D=0
>>
>> >  >
>>
>> However, if I check the the page, there are no ERROR listed:
>>
>> Report page was generated:
>>
>> This page was generated on 2024-04-23 11:37:19 -0400 (Tue, 23 Apr 2024).
>>
>> Should I just wait or where I can find the mentioned ERROR?
>>
>> Best regards
>>
>> Kristian
>>
> --
> Herv� Pag�s
>
> Bioconductor Core Team
> hpages.on.git...@gmail.com

--
Herv� Pag�s

Bioconductor Core Team
hpages.on.git...@gmail.com

[[alternative HTML version deleted]]

___

Re: [Bioc-devel] MIRit fails to build on palomino3

[Kern, Lori via Bioc-devel]

We will look into it.  If there is anything that needs to be done on your end 
we will reach out.

Cheers,


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 Jacopo Ronchi 

Sent: Wednesday, April 24, 2024 6:33 AM
To: bioc-devel@r-project.org 
Subject: [Bioc-devel] MIRit fails to build on palomino3

Dear developers,

My package (MIRit) can be successfully installed and built on nebbiolo1,
iconway and kunpeng2. Moreover, it successfully passes R CMD check on all
these platforms.

However, it started failing the build process only on palomino3, due to a
call to "bfcadd()" during vignette re-building.

Thanks in advance for the help,
Jacopo

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://secure-web.cisco.com/1TwHJ2hcuHfkECRr8eAiB0Arq-i6Q03A_8nP9rv-fAoF2q0a5_jFABQEK2h2xh6ceM7T2zG9TPtxtmrktkpjS5i3uF_edrqr6E3jeMtaI-X6qOE1uINhpb_9khk3lfUU1uZ644NK-UR3I8mlB3ntvxYnoY6KkXsz7cydUOnbsYEBTux4vTgHg7pDpCLkj3jOEs8EodxeVLy9Tr-EQ8Wd7yDPgxXUE9TfK4T8gV3MuTzmNmsKNqDRko1oh3MaQDieNiTrTwWtwDwR-62eaCG3IJG-lB7NhU2DxSd2nppD0fUlMoHAVIxswXTohs3rWRtdk/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] Build errors related to the new pwalign package

[Hervé Pagès]

Hi developers,

pairwiseAlignement() and stringDist() have recently moved from 
Biostrings to the new pwalign package. This is causing a number of 
failures today on the 3.19 report. Since yesterday I've been actively 
repairing packages affected by this by pushing fixes to 
git.bioconductor.org. Most packages are now fixed but this won't reflect 
before tomorrow's report.

Later in the day I'll send emails to the maintainers of packages that I 
have touched and ask them to resync their GitHub repos with 
git.bioconductor.org.

Sorry for the inconvenience.

Let me know if you have any questions.

Best,

H.

-- 
Hervé Pagès

Bioconductor Core Team
hpages.on.git...@gmail.com

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] nebbiolo1 - build report

[Hervé Pagès]

As for the error you will see when today's report gets published it's 
caused by the recent move of the pairwiseAlignment stuff from Biostrings 
to the new pwalign package. I fixed it in MSA2dist 1.7.6 so it will go 
away in tomorrow's report. Please resync your GitHub repo with 
git.bioconductor.org when you get a chance.

H.

On 4/24/24 09:18, Hervé Pagès wrote:
>
> Hi Kristian,
>
> I believe that this is because the new report didn't get published yet 
> so the links in the email you received still points to yesterday's 
> report. We're investigating.
>
> Best,
>
> H.
>
> On 4/24/24 09:10, Kristian Ullrich wrote:
>> Hi,
>>
>> I just got an email from bbs:
>>
>> Hi MSA2dist maintainer,
>>
>> According to the Multiple platform build/check report for BioC 3.19,
>> the MSA2dist package has the following problem(s):
>>
>>   o ERROR for 'R CMD INSTALL' on nebbiolo1. See the details here:
>>   
>> https://bioconductor.org/checkResults/3.19/bioc-LATEST/MSA2dist/nebbiolo1-install.html
>>   
>> 
>>
>>   o ERROR for 'R CMD build' on nebbiolo1. See the details here:
>>   
>> https://bioconductor.org/checkResults/3.19/bioc-LATEST/MSA2dist/nebbiolo1-buildsrc.html
>>   
>> 
>>
>> However, if I check the the page, there are no ERROR listed:
>>
>> Report page was generated:
>>
>> This page was generated on 2024-04-23 11:37:19 -0400 (Tue, 23 Apr 2024).
>>
>> Should I just wait or where I can find the mentioned ERROR?
>>
>> Best regards
>>
>> Kristian
>>
> -- 
> Hervé Pagès
>
> Bioconductor Core Team
> hpages.on.git...@gmail.com

-- 
Hervé Pagès

Bioconductor Core Team
hpages.on.git...@gmail.com

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] nebbiolo1 - build report

[Hervé Pagès]

Hi Kristian,

I believe that this is because the new report didn't get published yet 
so the links in the email you received still points to yesterday's 
report. We're investigating.

Best,

H.

On 4/24/24 09:10, Kristian Ullrich wrote:
> Hi,
>
> I just got an email from bbs:
>
> Hi MSA2dist maintainer,
>
> According to the Multiple platform build/check report for BioC 3.19,
> the MSA2dist package has the following problem(s):
>
>   o ERROR for 'R CMD INSTALL' on nebbiolo1. See the details here:
>   
> https://bioconductor.org/checkResults/3.19/bioc-LATEST/MSA2dist/nebbiolo1-install.html
>   
> 
>
>   o ERROR for 'R CMD build' on nebbiolo1. See the details here:
>   
> https://bioconductor.org/checkResults/3.19/bioc-LATEST/MSA2dist/nebbiolo1-buildsrc.html
>   
> 
>
> However, if I check the the page, there are no ERROR listed:
>
> Report page was generated:
>
> This page was generated on 2024-04-23 11:37:19 -0400 (Tue, 23 Apr 2024).
>
> Should I just wait or where I can find the mentioned ERROR?
>
> Best regards
>
> Kristian
>
-- 
Hervé Pagès

Bioconductor Core Team
hpages.on.git...@gmail.com

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] New annotation hub package?

[Kern, Lori via Bioc-devel]

I can assist you with this request.   In the future there is the email 
h...@bioconductor.org for these types of requests instead of the developer 
mailing list as mentioned in the documentation.

I'll contact you off mailing list for further details and instruction.

Cheers,


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 Sara López 
Ruiz de Vargas 
Sent: Wednesday, April 24, 2024 9:17 AM
To: bioc-devel@r-project.org 
Subject: [Bioc-devel] New annotation hub package?

Dear developers community,

We are currently developing a package for which we are quite sure we
will need a supporting AnnotationHub or ExperimentHub package to go with
it.
We are using a set of gene annotations (GENCODE version 40 hg38) and
enhancer annotations (ENCODE registry of cCREs v3), which are not
available in the AnnotationHub.
Correct me if I’m wrong.

On top of that, our package depends on in house precomputed datasets
that occupy a lot of space.
We have solved this issue temporarily by making the annotations and the
precomputed data into RSQLite databases which the user can download
(into inst/extada)
once the package is installed. This however makes the inst/extdata
folder really large (above 5GB). Most likely a Hub package would be a
better solution.

When looking at the documentation (
https://secure-web.cisco.com/1SsSYiZvjhKsQTFDCiJs0zb6X29DjrpzlJ2hbWrRlx8i-tJpOM_X_CeJJbTIno7lpn5KpG38T0R-RtgcpXEhht9UGyKnVc-Xhzfc7uJKGpjgkNWPgaAqEkv7dtSBqHZjisJHne-FoHtc3puPdivFQ5JoxHenR3tMndo8F4AxdcaDrmc86qyiC7wulOGvXG8urAj43FaLkpCC-GQSWFFCeqaN6Bj55ech4IoyaCMU0cfKv70FAKXhk1dTjtQjDe9e8SxKEhdSipEWpUWIsk-QnozRWMFNRit5mLBhjgQzTW60FMWumv_ztFHv9Zhl1YhgZ/https%3A%2F%2Fbioconductor.org%2Fpackages%2Fdevel%2Fbioc%2Fvignettes%2FHubPub%2Finst%2Fdoc%2FCreateAHubPackage.html
) one of the first things
mentioned is to contact a Bioconductor team member. I was wondering if I
could find someone in this forum who could help with this.

Best regards,

Sara Lopez

--
Sara López Ruiz de Vargas
Max Planck Institute for Molecular Genetics
Vingron Lab / Dept. of Computational Molecular Biology
Ihnestraße 63-⁠73
14195 Berlin
GERMANY

___
Bioc-devel@r-project.org mailing list
https://secure-web.cisco.com/19y5jjNThFPctQlUbT6K3Hg9mlaxJVmKPEEjbx1GABHcgiaZQLDwUslfiGwqVxEnsyORtZigkAfhFetbn6fqOLCK8y1y2W7c7TL_aqCedQIJ5FNhIQndxPaGaMUo0FACODWPqqZdSC6mh3lYOeOKBsF_Nj2dYROxddjkqPgYIeDqPjsQrusThRWvpl0X_WYU5w-fAsPWm-96kj-SbyCdQn06KfZukOoWr4X2bp1PKqn352I2YAKsTfyaeDAj56glb4YClnSN8ON42U_W1gVe--tk1h65kVazU_2Flfv-1AmhBNg60B7Rppzv99K_b44eS/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] nebbiolo1 - build report

[Kristian Ullrich]

Hi,

I just got an email from bbs:

Hi MSA2dist maintainer,

According to the Multiple platform build/check report for BioC 3.19,
the MSA2dist package has the following problem(s):

 o ERROR for 'R CMD INSTALL' on nebbiolo1. See the details here:
 
https://bioconductor.org/checkResults/3.19/bioc-LATEST/MSA2dist/nebbiolo1-install.html
 


 o ERROR for 'R CMD build' on nebbiolo1. See the details here:
 
https://bioconductor.org/checkResults/3.19/bioc-LATEST/MSA2dist/nebbiolo1-buildsrc.html
 


However, if I check the the page, there are no ERROR listed:

Report page was generated:

This page was generated on 2024-04-23 11:37:19 -0400 (Tue, 23 Apr 2024).

Should I just wait or where I can find the mentioned ERROR?

Best regards

Kristian

-- 
Kristian Ullrich, Ph.D.
Max Planck Institute
For Evolutionary Biology

Scientific IT group
Department of Evolutionary Genetics
August Thienemann Str. 2
24306 Plön
Germany
+49 4522 763 313
ullr...@evolbio.mpg.de

“Ich weiß, allen tut's leid. Jeder muss gucken, wo er bleibt. Dein Lohn, so gut 
wie nichts. Nichts, was du tust, fällt ins Gewicht.” (Die traurigen Hummer; 
Moritz Krämer)

-- 
CONFIDENTIALITY NOTICE:\ The contents of this email mess...{{dropped:11}}

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

Re: [Rd] Is ALTREP "non-API"?

[Hiroaki Yutani]

> And in general, I'd urge R Core to make an explicit list of functions that
you consider to be part of the exported API

While I believe R Core is in the process of such clarification, I'd also
vote for this. Now that WRE has "experimental" category, and if we take the
current definition of "documented in the manual" literally, an
"experimental" entry point cannot be documented because the entry point
would promote to an "API" for the obvious reason. It would sound funny that
you cannot write precautionary statements on experimental entry points just
because of the very definition of "experimental". So, I agree R should have
the explicit list.

I'd add that R should also define a process on how to stabilize an
"experimental" or "public" entry point into an "API". For example, Rust
language has such a process [1]. After a feature is introduced as unstable,
a "tracking issue" is filed and the related problems are reported or linked
to it. Users can know what are the remaining problems before getting
stabilized, and, if they have strong will, they can contribute to resolving
such blockers. Similarly, if we can track the unresolved problems of each
non-API, we might be able to help the R core team more smoothly.

Best,
Yutani

[1]: https://rustc-dev-guide.rust-lang.org/stabilization_guide.html


2024年4月24日(水) 21:55 Hadley Wickham :

> >
> >
> >
> > >>> That is not true at all - the presence of header does not constitute
> > >> declaration of something as the R API. There are cases where internal
> > >> functions are in the headers for historical or other reasons since the
> > >> headers are used both for the internal implementation and packages.
> > That's
> > >> why this is in R-exts under "The R API: entry points for C code":
> > >>>
> > >>> If I understand your point correctly, does this mean that
> > >> Rf_allocVector() is not part of the "official" R API? It does not
> > appear to
> > >> be documented in the "The R API: entry points for C code" section.
> > >>>
> > >>
> > >> It does, obviously:
> > >>
> https://cran.r-project.org/doc/manuals/R-exts.html#Allocating-storage-1
> > >
> > >
> > > I'm just trying to understand the precise definition of the official
> API
> > > here. So it's any function mentioned in R-exts, regardless of which
> > section
> > > it appears in?
> > >
> > > Does this sentence imply that all functions starting with alloc* are
> part
> > > of the official API?
> > >
> >
> > Again, I can only quote the R-exts (few lines below the previous "The R
> > API" quote):
> >
> >
> > We can classify the entry points as
> > API
> > Entry points which are documented in this manual and declared in an
> > installed header file. These can be used in distributed packages and will
> > only be changed after deprecation.
> >
> >
> > It says "in this manual" - I don't see anywhere restriction on a
> > particular section of the manual, so I really don't see why you would
> think
> > that allocation is not part on the API.
> >
>
> Because you mentioned that section explicitly earlier in the thread. This
> obviously seems clear to you, but it's not at all clear to me and I suspect
> many of the wider community. It's frustrating because we are trying
> our best to do what y'all want us to do, but it feels like we keep getting
> the rug pulled out from under us with very little notice, and then have to
> spend a large amount of time figuring out workarounds. That is at least
> feasible for my team since we have multiple talented folks who are paid
> full-time to work on R, but it's a huge struggle for most people who are
> generally maintaining packages in their spare time.
>
> For the purposes of this discussion could you please "documented in the
> manual" means? For example, this line mentions allocXxx functions: "There
> are quite a few allocXxx functions defined in Rinternals.h—you may want to
> explore them.". Does that imply that they are documented and free to use?
>
> And in general, I'd urge R Core to make an explicit list of functions that
> you consider to be part of the exported API, and then grandfather in
> packages that used those functions prior to learning that we weren't
> supposed to.
>
> Hadley
>
>
> --
> http://hadley.nz
>
> [[alternative HTML version deleted]]
>
> __
> R-devel@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Package passing checks on Linux and macOS but failing on Windows

[Richard Heery]

Okay thanks. However, I won't be able to fix my package until the
dependencies are fixed. Is that okay?

Cheers,

Richard

On Wed, 24 Apr 2024 at 15:45, Kern, Lori 
wrote:

> Yes your package will still be included in the release.   Even if a
> package is failing, you would receive notifications and a deprecation cycle
> before the package would be officially removed.  We like to see package
> fixed before a release so they can be made available to end users as soon
> as possible and so that you as a maintainer would only need to fix one
> branch instead of two.
>
> Cheers,
>
> 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
> Richard Heery 
> *Sent:* Wednesday, April 24, 2024 7:35 AM
> *To:* bioc-devel@r-project.org 
> *Subject:* [Bioc-devel] Package passing checks on Linux and macOS but
> failing on Windows
>
> Hi all,
>
> My new package on the devel version of Bioconductor is passing the
> build/check report on Linux and macOS, but failing on Windows (Palomino3).
> It seems some other packages that my one depends on are also failing on
> Windows (e.g. rtracklayer) so I am wondering will my package still be added
> to the new release of Bioconductor if it is passing on Linux and macOS?
>
> Cheers,
>
> Richard
>
> [[alternative HTML version deleted]]
>
> ___
> Bioc-devel@r-project.org mailing list
>
> https://secure-web.cisco.com/1t49XRTeE8loSvv35U4FnGrVHu50rpZSBti-9DZbr1dCqE7o0bVhKEtgut7wP5Bln-RhNML_v7MxZVe87WGSWbYYrSEj2oK_dA-EyXuxlAN9LcYbjH6NN5eXZC2MErWcdlAdPt6flPBvyWhPDnt-1lseoKgbfp9urTDU27vA05mMZaUY2DKn9M47U6uvKWOcmH26HIkl1aiKvWLWazCimKQYHyAHXYfEfNI0tReCKZNomnUK7KNy4AhGvSNLG6W9oPZvyKebITi7Qhr1vOlWrkFXbeTY51qGgsbvtojf0b3oVoE3TeKJzZ5_7DNfmwpZc/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

Re: [Bioc-devel] Package passing checks on Linux and macOS but failing on Windows

[Kern, Lori via Bioc-devel]

Yes your package will still be included in the release.   Even if a package is 
failing, you would receive notifications and a deprecation cycle before the 
package would be officially removed.  We like to see package fixed before a 
release so they can be made available to end users as soon as possible and so 
that you as a maintainer would only need to fix one branch instead of two.

Cheers,


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 Richard Heery 

Sent: Wednesday, April 24, 2024 7:35 AM
To: bioc-devel@r-project.org 
Subject: [Bioc-devel] Package passing checks on Linux and macOS but failing on 
Windows

Hi all,

My new package on the devel version of Bioconductor is passing the
build/check report on Linux and macOS, but failing on Windows (Palomino3).
It seems some other packages that my one depends on are also failing on
Windows (e.g. rtracklayer) so I am wondering will my package still be added
to the new release of Bioconductor if it is passing on Linux and macOS?

Cheers,

Richard

[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://secure-web.cisco.com/1t49XRTeE8loSvv35U4FnGrVHu50rpZSBti-9DZbr1dCqE7o0bVhKEtgut7wP5Bln-RhNML_v7MxZVe87WGSWbYYrSEj2oK_dA-EyXuxlAN9LcYbjH6NN5eXZC2MErWcdlAdPt6flPBvyWhPDnt-1lseoKgbfp9urTDU27vA05mMZaUY2DKn9M47U6uvKWOcmH26HIkl1aiKvWLWazCimKQYHyAHXYfEfNI0tReCKZNomnUK7KNy4AhGvSNLG6W9oPZvyKebITi7Qhr1vOlWrkFXbeTY51qGgsbvtojf0b3oVoE3TeKJzZ5_7DNfmwpZc/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] Package passing checks on Linux and macOS but failing on Windows

[Richard Heery]

Hi all,

My new package on the devel version of Bioconductor is passing the
build/check report on Linux and macOS, but failing on Windows (Palomino3).
It seems some other packages that my one depends on are also failing on
Windows (e.g. rtracklayer) so I am wondering will my package still be added
to the new release of Bioconductor if it is passing on Linux and macOS?

Cheers,

Richard

[[alternative HTML version deleted]]

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

[Bioc-devel] Final Reminder: EuroBioC2024 Abstract Deadline April 26th

[Maria . Doyle]

Hi everyone,

This is the last call to submit your abstracts for the EuroBioC2024 conference. 
The submission window closes this Friday, April 26th, at 5 PM BST.

Ensure your research is showcased at EuroBioC2024 by submitting your abstract 
here.

We�re excited to see your contributions and thank everyone who has submitted so 
far!

Best regards,
Maria


Maria Doyle, PhD
Bioconductor Community Manager

School of Medicine,
University of Limerick, Limerick, V94 T9PX
Ireland
Email: maria.do...@ul.ie
Phone (office): +353 61 234 768
[I work flexible hours across several time zones. I don't expect you to read or 
respond to my emails outside of your normal working hours]



[[alternative HTML version deleted]]

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

[Bioc-devel] New annotation hub package?

[Sara López Ruiz de Vargas]

Dear developers community,

We are currently developing a package for which we are quite sure we 
will need a supporting AnnotationHub or ExperimentHub package to go with 
it.
We are using a set of gene annotations (GENCODE version 40 hg38) and 
enhancer annotations (ENCODE registry of cCREs v3), which are not 
available in the AnnotationHub.

Correct me if I’m wrong.

On top of that, our package depends on in house precomputed datasets 
that occupy a lot of space.
We have solved this issue temporarily by making the annotations and the 
precomputed data into RSQLite databases which the user can download 
(into inst/extada)
once the package is installed. This however makes the inst/extdata 
folder really large (above 5GB). Most likely a Hub package would be a 
better solution.


When looking at the documentation ( 
https://bioconductor.org/packages/devel/bioc/vignettes/HubPub/inst/doc/CreateAHubPackage.html 
) one of the first things
mentioned is to contact a Bioconductor team member. I was wondering if I 
could find someone in this forum who could help with this.


Best regards,

Sara Lopez

--
Sara López Ruiz de Vargas
Max Planck Institute for Molecular Genetics
Vingron Lab / Dept. of Computational Molecular Biology
Ihnestraße 63-⁠73
14195 Berlin
GERMANY

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

Re: [Rd] Is ALTREP "non-API"?

[Hadley Wickham]

>
>
>
> >>> That is not true at all - the presence of header does not constitute
> >> declaration of something as the R API. There are cases where internal
> >> functions are in the headers for historical or other reasons since the
> >> headers are used both for the internal implementation and packages.
> That's
> >> why this is in R-exts under "The R API: entry points for C code":
> >>>
> >>> If I understand your point correctly, does this mean that
> >> Rf_allocVector() is not part of the "official" R API? It does not
> appear to
> >> be documented in the "The R API: entry points for C code" section.
> >>>
> >>
> >> It does, obviously:
> >> https://cran.r-project.org/doc/manuals/R-exts.html#Allocating-storage-1
> >
> >
> > I'm just trying to understand the precise definition of the official API
> > here. So it's any function mentioned in R-exts, regardless of which
> section
> > it appears in?
> >
> > Does this sentence imply that all functions starting with alloc* are part
> > of the official API?
> >
>
> Again, I can only quote the R-exts (few lines below the previous "The R
> API" quote):
>
>
> We can classify the entry points as
> API
> Entry points which are documented in this manual and declared in an
> installed header file. These can be used in distributed packages and will
> only be changed after deprecation.
>
>
> It says "in this manual" - I don't see anywhere restriction on a
> particular section of the manual, so I really don't see why you would think
> that allocation is not part on the API.
>

Because you mentioned that section explicitly earlier in the thread. This
obviously seems clear to you, but it's not at all clear to me and I suspect
many of the wider community. It's frustrating because we are trying
our best to do what y'all want us to do, but it feels like we keep getting
the rug pulled out from under us with very little notice, and then have to
spend a large amount of time figuring out workarounds. That is at least
feasible for my team since we have multiple talented folks who are paid
full-time to work on R, but it's a huge struggle for most people who are
generally maintaining packages in their spare time.

For the purposes of this discussion could you please "documented in the
manual" means? For example, this line mentions allocXxx functions: "There
are quite a few allocXxx functions defined in Rinternals.h—you may want to
explore them.". Does that imply that they are documented and free to use?

And in general, I'd urge R Core to make an explicit list of functions that
you consider to be part of the exported API, and then grandfather in
packages that used those functions prior to learning that we weren't
supposed to.

Hadley


-- 
http://hadley.nz

[[alternative HTML version deleted]]

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

Re: [Bioc-devel] Additional commit access for the BindingSiteFinder package

[Kern, Lori via Bioc-devel]

Could you please have the current maintainer Mirko Br�ggemann confirm this 
request?





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 Klostermann, 
Melina 
Sent: Wednesday, April 24, 2024 4:56 AM
To: bioc-devel@r-project.org 
Cc: mirko.brueggem...@mail.de 
Subject: [Bioc-devel] Additional commit access for the BindingSiteFinder package

Hello,

I recently joined the development of the Bioconductor BindingSiteFinder package 
and would like to get commit access to 
git.bioconductor.org
 for this package.
The package was developed Mirko Br�ggemann (in cc) and we are working on it 
together now.

Could you provide me with an access key?

Thanks a lot.
Bests

Melina Klostermann


Melina Klostermann

PhD student
Zarnack group
Buchmann Institute for Molecular Life Sciences
Max-von-Laue-Str. 15
60438 Frankfurt a.M.




[[alternative HTML version deleted]]

___
Bioc-devel@r-project.org mailing list
https://secure-web.cisco.com/1Ko2L6mEHlir1tGM7xP9epTH02TWKz2fztEXs3M13UM9anSMH44I6Yv7yl7HJySY9O6IBxJuoXZvvtsZoHOFhu7nI5Eb1_GnPkzflE8ff_6cCpYZ4_ccPwH7PawcfDCmKbRRtKjqzV0xb_b5-JC0s_gzj44jwdBaMmxV0xcYqp0wAOtcvAQyLLGK0y5Wf2ZolSXsC99qvnRVeRtNu8xEHQWbUG8HEcff1fEixPxACUWyxM9xR8mO5Q1VlKf7qWxhTBEDmyMzXkxZd4py6KLtk0A4C_YGUHcHvN0e_BCQM9G5Hn3gjaFFJ5rPNEfD3kOYG/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] Additional commit access for the BindingSiteFinder package

[Klostermann, Melina]

Hello,

I recently joined the development of the Bioconductor BindingSiteFinder package 
and would like to get commit access to 
git.bioconductor.org for this package.
The package was developed Mirko Brüggemann (in cc) and we are working on it 
together now.

Could you provide me with an access key?

Thanks a lot.
Bests

Melina Klostermann


Melina Klostermann

PhD student
Zarnack group
Buchmann Institute for Molecular Life Sciences
Max-von-Laue-Str. 15
60438 Frankfurt a.M.




[[alternative HTML version deleted]]

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

[Bioc-devel] MIRit fails to build on palomino3

[Jacopo Ronchi]

Dear developers,

My package (MIRit) can be successfully installed and built on nebbiolo1,
iconway and kunpeng2. Moreover, it successfully passes R CMD check on all
these platforms.

However, it started failing the build process only on palomino3, due to a
call to "bfcadd()" during vignette re-building.

Thanks in advance for the help,
Jacopo

[[alternative HTML version deleted]]

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

Re: [R-pkg-devel] [External] Re: Package submission to CRAN not passing incoming checks

[Ivan Krylov via R-package-devel]

В Wed, 24 Apr 2024 00:17:28 +
"Petersen, Isaac T"  пишет:

> I included the packages (including the raw package folders and their
> .tar.gz files) in the /inst/extdata folder.

Would you prefer your test to install them from the source directories
(as you currently do, in which case the *.tar.gz files can be omitted)
or the *.tar.gz files (in which case you can set the `repos` argument
to a file:/// URI and omit the package directories and the setwd()
calls)?

I think (but haven't tested) that the two problems that are currently
breaking your test are with .libPaths() and setwd().

.libPaths(temp_lib) overwrites the library paths with `temp_lib` and
the system libraries, the ones in %PROGRAMFILES%\R\R-*\library. In
particular, this removes %LOCALAPPDATA%\R\win-library\* from the list
of library paths, so the packages installed by the user (including
'waldo', which is needed by 'testthat') stop being available.

In order to add temp_lib to the list of the paths, use
.libPaths(c(temp_lib, .libPaths())).

Since setwd() returns the previous directory, one that was current
before setwd() was called, the code newpath <- setwd(filepath);
setwd(newpath) will keep the current directory, not set it to
`filepath`. Use oldpath <- setwd(filepath) instead.

Since you're already using 'testthat' and it already depends on
'withr', you may find it easier to use withr::local_dir(...) and
withr::local_temp_libpaths(...).

In order to test for a package being attached by load_or_install() (and
not just installed and loadable), check for 'package:testpackage1'
being present in the return value of search(). (This check is good
enough and much easier to write than comparing environments on the
search path with the package exports or comparing searchpaths() with
the paths under the temporary library.)

Finally, I think that there is no need for the test_load_or_install()
call because I don't see the function being defined anywhere. Doesn't
test_that(...) run the tests by itself?

-- 
Best regards,
Ivan

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