[Rcpp-devel] Rcpp_precious_remove again (Windows)

[Dominick Samperi]

On the changes for R 4.2.0, it is not clear how to distinguish
R API functions from R internal functions (and this probably
doesn't matter for Rcpp), but you are correct,
on closer inspection these changes should not have effected
the way R_DefParams() was used before R_DefParamsEx()
was introduced.

It would be helpful if others could test to see if they can reproduce
the problems I reported. I will submit a pull request when
ready, and if there is no objection, ifdefs will be included that
permit compiling Rcpp and RInside using MSVC (there are only
a few small changes with most of them applying to RInside.cpp).

I do not recommend MSVC for R package development and deployment,
just for debugging difficult problems like this. More than a decade ago
this helped to track down bugs in a popular R package (rgl). Bugs that
can slip by g++ can trigger problems with MSVC. Users who use
MSVC for this purpose should understand that they are completely
on their own, as you say. There may be some advantages to testing
with MSVC given its good support for the newer runtime UCRT.

Dominick








On Mon, Jan 23, 2023 at 4:38 AM Tomas Kalibera <tomas.kalibera at gmail.com>
wrote:

>
> On 1/21/23 16:53, Dominick Samperi wrote:
>
> There are problems with the R-devel version, but they appear less
> frequently.
> What happens is two instances of the program are started instead of one,
> but there is normally
> a "dominant" one that hides the fact that there is another instance
> lurking, so
> the program seems to behave normally. Occasionally both instances
> come up (two terminals and two x11 panes). The R function
> R_SetWin32(Rstart) is called twice on startup.
>
> The problem is likely caused by the fact that R internals changed for
> R 4.2.0, in particular, the structRstart in R_ext/RStartup.h changed,
> and RSTART_VERSION was introduced. The requires use of
> R_DefParamsEx(&Rst, RSTART_VERSION) in place of
> R_DefParams(), and the return value must be zero for version
> compatibility.
>
> A short comment from me, please see the source code comments for more and
> R-exts. The changes in R 4.2.0 in the API carefully were designed to be
> backwards compatible. It is of course a good idea to switch to the new API
> and the embedding application should ideally always use the current
> headers, but it is unlikely the cause of any problems now.
>
>
> This is not Windows-specific, and I suspect there are
> problems under Linux, but symptoms rarely surface due to
> some quirks of that architecture (better immune system?).
>
> I modified the source with hints from the example
> src/gnuwin32/front-ends/rtest.c, and the program seems
> to behave more consistently, but the multiple instance
> problem persists.
>
> I've attached a version of RInside.cpp with my changes. The
> _MSC_VER ifdefs are for Video Studio, which I am using for
> debugging. I had some problems with gdb.
>
> R code has not been used with Visual Studio compilers for many years, and
> never officially supported by those. With MSVC, you are completely on your
> own and I would expect a large number of problems (solving many of which
> won't be relevant for R nor R packages).
>
> Tomas
>
>
> Dominick
>
>
>
>
>
> On Fri, Jan 20, 2023 at 7:56 PM Dirk Eddelbuettel <edd at debian.org> wrote:
>
>>
>> On 20 January 2023 at 19:11, Dominick Samperi wrote:
>> | You are right Dirk, RInside overrides what is specified because the
>> function
>> | myAskYesNo doesn't actually ask, so this explains why there is to
>> | termination
>> | prompt under Windows. This does not change what happens under Linux
>> | because this function is assigned to a Windows-specific callback. Under
>> | Linux the confirmation message appears.
>> |
>> | The current status is that the example seems to work using R-devel,
>> | but not using R-4.2.2.
>>
>> :-/
>>
>> If you can narrow it down we'd appreciate it. If not, well, r-devel will
>> be
>> r-release in the three months time.
>>
>> And I don't think we have done any changes on the Windows side since
>> before
>> UCRT with R 4.2.0.
>>
>> Dirk
>>
>> --
>> dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/rcpp-devel/attachments/20230123/5ff69a3a/attachment.html>