R devel - Oct 2015 - Error generated by .Internal(nchar) disappears when debugging

On 05/10/2015 7:24 PM, Matt Dowle wrote:
> Joris Meys <jorismeys <at> 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

Doesn't the byte-compiler inline calls like nchar() to call the .Internal
directly for certain optimization levels?  If the 'internal' signature
changed in a point release, I'd expect an issue like the below.  (I'm
pretty sure CRAN packages are byte-compiled at build-time, but don't use
Windows so can't confirm)

To Joris' initial question. I think the debug machinery calls the
unoptimized (no-inline) function.

Michael
> On Oct 5, 2015, at 6:57 PM, Duncan Murdoch <murdoch.duncan at
gmail.com> wrote:
> 
>> On 05/10/2015 7:24 PM, Matt Dowle wrote:
>> Joris Meys <jorismeys <at> 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
> 
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

On Mon, Oct 5, 2015 at 4:57 PM, Duncan Murdoch <murdoch.duncan at
gmail.com>
wrote:
> On 05/10/2015 7:24 PM, Matt Dowle wrote:
> > Joris Meys <jorismeys <at> 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

	[[alternative HTML version deleted]]

I can reproduce the problem by running R-3.2.0 (on Windows),
installing copula from CRAN,
and then using it:
> install.packages("copula")
Installing package into 'C:/Program Files/R/R-3.2.0/site-library'
(as 'lib' is unspecified)
also installing the dependencies 'gsl', 'ADGofTest',
'pspline'

Warning: unable to access index for repository
http://bioconductor.org/packages/2.12/data/annotation/bin/windows/contrib/3.2
Warning: unable to access index for repository
http://bioconductor.org/packages/2.12/data/experiment/bin/windows/contrib/3.2
trying URL
'http://cran.rstudio.com/bin/windows/contrib/3.2/gsl_1.9-10.zip'
Content type 'application/zip' length 1121688 bytes (1.1 MB)
downloaded 1.1 MB

trying URL
'http://cran.rstudio.com/bin/windows/contrib/3.2/ADGofTest_0.3.zip'
Content type 'application/zip' length 13378 bytes (13 KB)
downloaded 13 KB

trying URL
'http://cran.rstudio.com/bin/windows/contrib/3.2/pspline_1.0-17.zip'
Content type 'application/zip' length 58343 bytes (56 KB)
downloaded 56 KB

trying URL
'http://cran.rstudio.com/bin/windows/contrib/3.2/copula_0.999-13.zip'
Content type 'application/zip' length 3792158 bytes (3.6 MB)
downloaded 3.6 MB

package 'gsl' successfully unpacked and MD5 sums checked
package 'ADGofTest' successfully unpacked and MD5 sums checked
package 'pspline' successfully unpacked and MD5 sums checked
package 'copula' successfully unpacked and MD5 sums checked

The downloaded binary packages are in
       
C:\Users\wdunlap\AppData\Local\Temp\RtmpeurJX7\downloaded_packages
> library(copula)
Warning message:
package 'copula' was built under R version 3.2.2
> fgmCopula(0.8)
Error in substr(sc[i], 2, nchar(sc[i]) - 1) :
  4 arguments passed to .Internal(nchar) which requires 3
Bill Dunlap
TIBCO Software
wdunlap tibco.com


On Mon, Oct 5, 2015 at 4:57 PM, Duncan Murdoch <murdoch.duncan at
gmail.com> wrote:
> On 05/10/2015 7:24 PM, Matt Dowle wrote:
>> Joris Meys <jorismeys <at> 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
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

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

On Tue, Oct 6, 2015 at 1:57 AM, Duncan Murdoch <murdoch.duncan at
gmail.com>
wrote:
> On 05/10/2015 7:24 PM, Matt Dowle wrote:
> > Joris Meys <jorismeys <at> 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.
>
You're free to try the simple reproducible example I've provided in my
original question. Tried that out on 3 different computers, and I got the
same behaviour 3 times.

>
> 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.
>
I never said the package called the internal function, because it doesn't.
The error message reports there's an error in substr(sc[i], 2, nchar(sc[i])
- 1). Then it continues to indicate the problem occurs at the moment
nchar() calles the internal function. That's how the core team wrote the
nchar() function.

> 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.
>
With all due respect for your involvement in and knowledge about R, I have
the impression you read too quickly through the mail. There is a problem
and it is reproducible. I'm just not smart enough to figure out how the
problem came about.

Kind regards
Joris

>
> 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]]

On 06/10/2015 8:48 AM, Joris Meys wrote:
> 
> 
> On Tue, Oct 6, 2015 at 1:57 AM, 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.
> 
> 
> You're free to try the simple reproducible example I've provided in
my
> original question. Tried that out on 3 different computers, and I got
> the same behaviour 3 times.
As I posted yesterday, with Matt's help I was able to find a simple
reproduction of the bug.

The reason I wouldn't count your original post as a simple reproducible
example (and the same applies to what I saw on Stack Overflow), was that
it required a fairly large package (copula) in the demonstration.  I'm
not familiar with the internals of that package (or Matt's package
discussed on Stack Overflow), so it would be a lot of work for me to
identify what it was in them that triggered the bug.  If the bug had
required those packages and couldn't be demonstrated without them, then
it would likely be a bug in those packages, not in R.

>  
> 
> 
>     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.
> 
> 
> I never said the package called the internal function, because it
> doesn't. The error message reports there's an error insubstr(sc[i],
2,
> nchar(sc[i]) - 1). Then it continues to indicate the problem occurs at
> the moment nchar() calles the internal function. That's how the core
> team wrote the nchar() function.
> 
> 
>     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.
> 
> 
> With all due respect for your involvement in and knowledge about R, I
> have the impression you read too quickly through the mail. There is a
> problem and it is reproducible. I'm just not smart enough to figure out
> how the problem came about.
> 
I sometimes do read too quickly and miss important details, but I don't
think I did in this case.

Duncan Murdoch

What other packages do you have loaded?  Perhaps a BioConductor one that loads
S4Vectors that announces upon load:

	Creating a generic function for 'nchar' from package 'base' in
package 'S4Vectors'

Maybe a red herring...

~Malcolm

 > -----Original Message-----
 > From: R-devel [mailto:r-devel-bounces at r-project.org] On Behalf Of
Duncan
 > Murdoch
 > Sent: Monday, October 05, 2015 6:57 PM
 > To: Matt Dowle <mattjdowle at gmail.com>; r-devel at
stat.math.ethz.ch
 > Subject: Re: [Rd] Error generated by .Internal(nchar) disappears when
 > debugging
 > 
 > On 05/10/2015 7:24 PM, Matt Dowle wrote:
 > > Joris Meys <jorismeys <at> 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
 > 
 > ______________________________________________
 > R-devel at r-project.org mailing list
 > https://stat.ethz.ch/mailman/listinfo/r-devel

Malcolm,

I tested the code on a clean R 3.2.0 session. Not even in RStudio, just to
rule that out.
> sessionInfo()
R version 3.2.0 (2015-04-16)
Platform: x86_64-w64-mingw32/x64 (64-bit)
Running under: Windows 8 x64 (build 9200)

locale:
[1] LC_COLLATE=English_United Kingdom.1252
[2] LC_CTYPE=English_United Kingdom.1252
[3] LC_MONETARY=English_United Kingdom.1252
[4] LC_NUMERIC=C
[5] LC_TIME=English_United Kingdom.1252

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

other attached packages:
[1] copula_0.999-13

loaded via a namespace (and not attached):
 [1] Matrix_1.2-0     ADGofTest_0.3    tools_3.2.0      pspline_1.0-17
 [5] gsl_1.9-10       mvtnorm_1.0-3    grid_3.2.0       stats4_3.2.0
 [9] lattice_0.20-31  stabledist_0.7-0 fortunes_1.5-2


On Wed, Oct 7, 2015 at 9:52 PM, Cook, Malcolm <MEC at stowers.org> wrote:
> What other packages do you have loaded?  Perhaps a BioConductor one that
> loads S4Vectors that announces upon load:
>
>         Creating a generic function for 'nchar' from package
'base' in
> package 'S4Vectors'
>
> Maybe a red herring...
>
> ~Malcolm
>
>  > -----Original Message-----
>  > From: R-devel [mailto:r-devel-bounces at r-project.org] On Behalf Of
> Duncan
>  > Murdoch
>  > Sent: Monday, October 05, 2015 6:57 PM
>  > To: Matt Dowle <mattjdowle at gmail.com>; r-devel at
stat.math.ethz.ch
>  > Subject: Re: [Rd] Error generated by .Internal(nchar) disappears when
>  > debugging
>  >
>  > On 05/10/2015 7:24 PM, Matt Dowle wrote:
>  > > Joris Meys <jorismeys <at> 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
>  >
>  > ______________________________________________
>  > R-devel at r-project.org mailing list
>  > https://stat.ethz.ch/mailman/listinfo/r-devel
>
> ______________________________________________
> 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]]

> -----Original Message-----
> From: R-devel [mailto:r-devel-bounces at r-project.org] On Behalf Of Cook,
> Malcolm
> Sent: Wednesday, October 07, 2015 3:52 PM
> To: 'Duncan Murdoch'; Matt Dowle; r-devel at stat.math.ethz.ch
> Subject: Re: [Rd] Error generated by .Internal(nchar) disappears when
> debugging
> 
> What other packages do you have loaded?  Perhaps a BioConductor one that
> loads S4Vectors that announces upon load:
> 
> 	Creating a generic function for 'nchar' from package
'base' in package
> 'S4Vectors'
This was introduced as a way around the problem, where the declaration of a
method was moved to the .onLoad hook

.onLoad <- function(libname, pkgname)
     setMethod("nchar", "Rle", .nchar_Rle)

instead of in the body of the package. The rationale was that the method is then
created at run-time, when the generic is defined on the user's R, rather
than at compile time, when the generic is defined on the build system's R.
There was a subsequent independent report that this did not solve the problem,
but we were not able to follow up on that.

This is only defined in the current release version of S4Vectors, which is the
only version expected to straddle R versions with different signatures.

Martin Morgan
> 
> Maybe a red herring...
> 
> ~Malcolm
> 
>  > -----Original Message-----
>  > From: R-devel [mailto:r-devel-bounces at r-project.org] On Behalf Of
> Duncan  > Murdoch  > Sent: Monday, October 05, 2015 6:57 PM  > To:
Matt
> Dowle <mattjdowle at gmail.com>; r-devel at stat.math.ethz.ch  >
Subject: Re:
> [Rd] Error generated by .Internal(nchar) disappears when  > debugging 
>  >
> On 05/10/2015 7:24 PM, Matt Dowle wrote:
>  > > Joris Meys <jorismeys <at> 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
>  >
>  > ______________________________________________
>  > R-devel at r-project.org mailing list
>  > https://stat.ethz.ch/mailman/listinfo/r-devel
> 
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-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.