similar to: Undocumented change of dirname("C:/") on R-devel on Windows

I confirmed the revert fixed my failing test. Thanks! 2023?2?23?(?) 20:12 Hiroaki Yutani <yutani.ini at gmail.com>: > Thanks for the prompt response, I'll confirm it after the new R-devel > binary is available. > Also, thanks for the detailed explanation. I agree with you in general. > > > "/" in "C:/" is a path separator or not, and whether it is

Thanks for the prompt response, I'll confirm it after the new R-devel binary is available. Also, thanks for the detailed explanation. I agree with you in general. > "/" in "C:/" is a path separator or not, and whether it is trailing or not It seems a Windows' path basically consists of two components; a drive specification (e.g., C:) and the directory structure

On 2/23/23 03:27, Hiroaki Yutani wrote: > Hi, > > I found dirname() behaves differently on R-devel on Windows. Since I'm not > sure which behavior is right, let me ask here before filing this to R's > Bigzilla. > > On R 4.2.2., we get > > > dirname("C:/") > [1] "C:/" > > However, on R-devel (r83888), we get > >

Hi Tomas, There has been an R CMD check error with xfun and r-devel on Windows for a while: https://www.r-project.org/nosvn/R.check/r-devel-windows-x86_64/xfun-00check.html Basically it means that the following would return TRUE before: normalizePath('a/b', mustWork = FALSE) == normalizePath('./a/b', mustWork = FALSE) but it became FALSE at some point in r-devel. I think

Hi Yutani, ALTREP is part of the official R api, as illustrated by the presence of src/include/R_ext/Altrep.h. Everything declared in the header files in that directory is official API AFAIK (and I believe that is more definitive than the manuals). The documentation of ALTREP has lagged behind its implementation unfortunately, which may partially my fault for not submitting doc patches for it

Thanks for your convincing comment, but it seems the R core team has a different opinion... A few hours ago, src/include/R_ext/Altrep.h got this comment: /* Not part of the API, subject to change at any time. */ commit: https://github.com/r-devel/r-svn/commit/2059bffde642f8426d1f39ab5dd995d19a575d4d While I'm glad to see their attempt to make it clear, I'm confused. That

Thanks, Hernando, Sorry, "API" is a bit confusing term in this context, but what I want to discuss is the "API" that Writing R Extension defines as quoted in my previous email. It's probably different from an ordinary sense when we casually say "R C API". You might wonder why I care about such a difference. This is because calling a "non-API" is

> On Apr 22, 2024, at 7:37 PM, Gabriel Becker <gabembecker at gmail.com> wrote: > > Hi Yutani, > > ALTREP is part of the official R api, as illustrated by the presence of > src/include/R_ext/Altrep.h. Everything declared in the header files in that > directory is official API AFAIK (and I believe that is more definitive than > the manuals). > That is not true

Hello, I don't believe it is illegal, as ALTREP "implements an abstraction underneath the C API". And is "compatible with all code which uses the API". Please see slide deck by Gabriel Becker, with L Tierney, M Lawrence and T Kalibera. https://bioconductor.org/help/course-materials/2020/BiocDevelForum/16-ALTREP .pdf ALTREP framework implements an abstraction underneath

Writing R Extension[1] defines "API" as: 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. But, the document (WRE) doesn't have even a single mention of ALTREP, the term "ALTREP" itself or any entry points related to ALTREP. Does this mean,

Thanks so much for your wonderful work, Luke! I didn't expect such a clarification to happen this soon. This is really great. For convenience, I created a quick web page to search the result of tools:::funAPI(). https://yutannihilation.github.io/R-fun-API/ Hope this helps those who are too lazy to install R-devel to check. Best, Yutani 2024?6?6?(?) 23:47 luke-tierney--- via R-devel

Sorry to ask about a bit drifted topic, but will there be an alternative API to DATAPTR? > DATAPTR is not in the API and can't be at least in this form I believe it's vital for ALTREP to return the pointer to the expanded version of a SEXP just like the implementation in base R does [1]. At least, VECSXP has no other measure to expose the pointer if I understand correctly. Best,

On Mon, Apr 22, 2024 at 5:14?PM Simon Urbanek <simon.urbanek at r-project.org> wrote: > > > > On Apr 22, 2024, at 7:37 PM, Gabriel Becker <gabembecker at gmail.com> > wrote: > > > > Hi Yutani, > > > > ALTREP is part of the official R api, as illustrated by the presence of > > src/include/R_ext/Altrep.h. Everything declared in the header

Thanks, But this didn't work. It installs msys2 along with lots of other stuff, and gdb would not start as before (missing DLL's). Then I tried to run the command you suggested again, and there was a warning from the package manager about a cycle detected, but now gdb starts with the following messages... Traceback (most recent call last): File "<string>", ine 3, in

On 1/18/23 19:41, Dominick Samperi wrote: > Thanks for the detailed feedback Tomas, > > I ran the command 'pacman -Syuu' again, just to be sure, and this time > it says "there is nothing to do." > > It appears that gdb is working. I was spooked by the diagnostics that > you say is a known (not serious) issue. > > My mistake was not setting a

On 1/18/23 17:39, Dominick Samperi wrote: > Thanks, > > But this didn't work. It installs msys2 along with lots of other > stuff, and gdb would not start as before (missing DLL's). > > Then I tried to run the command you suggested again, and there was a > warning from the package manager about a cycle detected, but now gdb > starts with the following messages...

Thanks for the detailed feedback Tomas, I ran the command 'pacman -Syuu' again, just to be sure, and this time it says "there is nothing to do." It appears that gdb is working. I was spooked by the diagnostics that you say is a known (not serious) issue. My mistake was not setting a breakpoint on main, so I confused problems with gdb with problems with the program I'm

I have just uploaded to CRAN a new version 3.2.0.1948 of Rtools for Windows. This will become visible there in a few hours, and be copied to mirrors thereafter. People who want to build packages that include compiled code can use this to supply the compilers, etc., that are necessary for the build. It also includes some extra materials for people who want to build R itself. This version

On second thought, there is a lot of metapramming code in Rcpp that runs before main, so I was wrong to say nothing can happen before main() is called. Strategically placed print statements may be the best strategy. On Wed, Jan 18, 2023 at 8:17 PM Dominick Samperi <djsamperi at gmail.com> wrote: > Since these ?stray threads? were appearing before I installed gdb into > Rtools42, this

If the subject of xapian-core apitests on MSYS/MINGW and MSYS2/MINGW is taken up it might be noted that the compiler version could be recorded, probably gcc 5.3.0 or newer, that closed pipes might be an issue, and also allocating for the location of xapian-tcpsrv. Not from my own tests but another man informed there was some problems with [MSYS2] python bindings. I am not knowledgeable of the