[Rd] Error generated by .Internal(nchar) disappears when debugging

[Joris Meys]

Thank you for looking at the issue. I've tried it with a tiny package
myself and I get the same results. So the problem should solve itself in
time.
Also thank you Michael for explaining the difference in behaviour when
debugging.

Cheers
Joris

On Tue, Oct 6, 2015 at 2:41 AM, Duncan Murdoch <murdoch.duncan at gmail.com>
wrote:

> On 05/10/2015 8:25 PM, Matt Dowle wrote:
> >
> > On Mon, Oct 5, 2015 at 4:57 PM, Duncan Murdoch <murdoch.duncan at gmail.com
> > <mailto:murdoch.duncan at gmail.com>> wrote:
> >
> >     On 05/10/2015 7:24 PM, Matt Dowle wrote:
> >     > Joris Meys <jorismeys <at> gmail.com <http://gmail.com>> writes:
> >     >
> >     >>
> >     >> Hi all,
> >     >>
> >     >> I have a puzzling problem related to nchar. In R 3.2.1, the
> internal
> >     > nchar
> >     >> gained an extra argument (see
> >     >> https://stat.ethz.ch/pipermail/r-announce/2015/000586.html)
> >     >>
> >     >> I've been testing code using the package copula, and at home I'm
> >     still
> >     >> running R 3.2.0 (I know, I know...). When trying the following
> >     code, I
> >     > got
> >     >> an error:
> >     >>
> >     >>> library(copula)
> >     >>> fgmCopula(0.8)
> >     >> Error in substr(sc[i], 2, nchar(sc[i]) - 1) :
> >     >>   4 arguments passed to .Internal(nchar) which requires 3
> >     >>
> >     >> Cheers
> >     >> Joris
> >     >
> >     >
> >     > I'm seeing a similar problem. IIUC, the Windows binary .zip from
> >     CRAN of
> >     > any package using base::nchar is affected. Could someone check my
> >     answer
> >     > here is correct please :
> http://stackoverflow.com/a/32959306/403310
> >
> >     Nobody has posted a simple reproducible example here, so it's kind of
> >     hard to say.
> >
> >     I would have guessed that a change to the internal signature of the C
> >     code underlying nchar() wouldn't have any effect on a package that
> >     called the R nchar() function.
> >
> >     When I put together my own example (a tiny package containing a
> function
> >     calling nchar(), built to .zip using R 3.2.2, installed into R
> 3.2.0),
> >     it confirmed my guess.
> >
> >     On the other hand, if some package is calling the .Internal function
> >     directly, I'd expect that to break.  Packages shouldn't do that.
> >
> >     So I'd say there's been no evidence posted of a problem in R here,
> >     though there may be problems in some of the packages involved.  I'd
> >     welcome an example that provided some usable evidence.
> >
> >     Duncan Murdoch
> >
> >
> > I don't have Windows so am not able to test unfortunately.
> > data.table makes no calls to .Internal(). Such calls are caught and
> > prevented by R CMD check.
> > Both data.table and copula contain "ByteCompile: yes" in their
> > DESCRIPTION files.  Does the toy package break with that setting?
> > Matt
> >
>
> That's it.  With "ByteCompile: yes" I get the same error.
>
> I don't know if there's anything we can do about this now, but we should
> be able to avoid it in the future.
>
> Duncan Murdoch
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>



-- 
Joris Meys
Statistical consultant

Ghent University
Faculty of Bioscience Engineering
Department of Mathematical Modelling, Statistics and Bio-Informatics

tel :  +32 (0)9 264 61 79
Joris.Meys at Ugent.be
-------------------------------
Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php

	[[alternative HTML version deleted]]