Error generated by .Internal(nchar) disappears when debugging

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Error generated by .Internal(nchar) disappears when debugging

Joris FA Meys
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

So I do the obvious and try to debug using debug():

> debugonce(fgmCopula)
> fgmCopula(0.8)

And when I try that, I can step through the complete function without any
error. I know that the obvious solution is to update to R 3.2.2, but :

- I have absolutely no clue how a function can give an error when used
normally, but not return any error when stepping through it using debug.
- The copula package built for R 3.2.2 isn't compatible any longer with R
versions older than R 3.2.1, like the one used in our PC classes. Other
packages might share the same problem.

Can somebody shed some light on what exactly is going on here? I don't want
to bug the authors of the copula package if I'm not sure of the origin of
this problem.

Cheers
Joris
--
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
[hidden email]
-------------------------------
Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Error generated by .Internal(nchar) disappears when debugging

Matt Dowle
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

Matt

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Error generated by .Internal(nchar) disappears when debugging

Duncan Murdoch-2
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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Error generated by .Internal(nchar) disappears when debugging

Michael Weylandt
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 <[hidden email]> 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
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Error generated by .Internal(nchar) disappears when debugging

Matt Dowle
In reply to this post by Duncan Murdoch-2
On Mon, Oct 5, 2015 at 4:57 PM, Duncan Murdoch <[hidden email]>
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]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Error generated by .Internal(nchar) disappears when debugging

William Dunlap
In reply to this post by Duncan Murdoch-2
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 <[hidden email]> 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
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Error generated by .Internal(nchar) disappears when debugging

Duncan Murdoch-2
In reply to this post by Matt Dowle
On 05/10/2015 8:25 PM, Matt Dowle wrote:

>
> On Mon, Oct 5, 2015 at 4:57 PM, Duncan Murdoch <[hidden email]
> <mailto:[hidden email]>> 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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Error generated by .Internal(nchar) disappears when debugging

Joris FA Meys
In reply to this post by Duncan Murdoch-2
On Tue, Oct 6, 2015 at 1:57 AM, Duncan Murdoch <[hidden email]>
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
>
> ______________________________________________
> [hidden email] 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
[hidden email]
-------------------------------
Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Error generated by .Internal(nchar) disappears when debugging

Joris FA Meys
In reply to this post by Duncan Murdoch-2
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 <[hidden email]>
wrote:

> On 05/10/2015 8:25 PM, Matt Dowle wrote:
> >
> > On Mon, Oct 5, 2015 at 4:57 PM, Duncan Murdoch <[hidden email]
> > <mailto:[hidden email]>> 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
>
> ______________________________________________
> [hidden email] 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
[hidden email]
-------------------------------
Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Error generated by .Internal(nchar) disappears when debugging

Duncan Murdoch-2
In reply to this post by Joris FA Meys
On 06/10/2015 8:48 AM, Joris Meys wrote:

>
>
> On Tue, Oct 6, 2015 at 1:57 AM, Duncan Murdoch <[hidden email]
> <mailto:[hidden email]>> 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

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Error generated by .Internal(nchar) disappears when debugging

Joris FA Meys
On Tue, Oct 6, 2015 at 3:02 PM, Duncan Murdoch <[hidden email]>
wrote:

> On 06/10/2015 8:48 AM, Joris Meys wrote:
>
>
> 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.
>

Dear Duncan,

thank you for the help and the extra clarification. I'll keep it in mind
for the future.
Cheers
Joris

--
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
[hidden email]
-------------------------------
Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Error generated by .Internal(nchar) disappears when debugging

Cook, Malcolm
In reply to this post by Duncan Murdoch-2
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:[hidden email]] On Behalf Of Duncan
 > Murdoch
 > Sent: Monday, October 05, 2015 6:57 PM
 > To: Matt Dowle <[hidden email]>; [hidden email]
 > 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
 >
 > ______________________________________________
 > [hidden email] mailing list
 > https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Error generated by .Internal(nchar) disappears when debugging

Joris FA Meys
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 <[hidden email]> 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:[hidden email]] On Behalf Of
> Duncan
>  > Murdoch
>  > Sent: Monday, October 05, 2015 6:57 PM
>  > To: Matt Dowle <[hidden email]>; [hidden email]
>  > 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
>  >
>  > ______________________________________________
>  > [hidden email] mailing list
>  > https://stat.ethz.ch/mailman/listinfo/r-devel
>
> ______________________________________________
> [hidden email] 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
[hidden email]
-------------------------------
Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Error generated by .Internal(nchar) disappears when debugging

Cook, Malcolm
OK – definitely a red herring – thanks for following up…

From: Joris Meys [mailto:[hidden email]]
Sent: Wednesday, October 07, 2015 4:09 PM
To: Cook, Malcolm <[hidden email]>
Cc: Duncan Murdoch <[hidden email]>; Matt Dowle <[hidden email]>; [hidden email]
Subject: Re: [Rd] Error generated by .Internal(nchar) disappears when debugging

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 <[hidden email]<mailto:[hidden email]>> 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:[hidden email]<mailto:[hidden email]>] On Behalf Of Duncan
 > Murdoch
 > Sent: Monday, October 05, 2015 6:57 PM
 > To: Matt Dowle <[hidden email]<mailto:[hidden email]>>; [hidden email]<mailto:[hidden email]>
 > 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<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
 >
 > ______________________________________________
 > [hidden email]<mailto:[hidden email]> mailing list
 > https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
[hidden email]<mailto:[hidden email]> 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
[hidden email]<mailto:[hidden email]>
-------------------------------
Disclaimer : http://helpdesk.ugent.be/e-maildisclaimer.php

        [[alternative HTML version deleted]]

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Error generated by .Internal(nchar) disappears when debugging

Martin Morgan-3
In reply to this post by Cook, Malcolm


> -----Original Message-----
> From: R-devel [mailto:[hidden email]] On Behalf Of Cook,
> Malcolm
> Sent: Wednesday, October 07, 2015 3:52 PM
> To: 'Duncan Murdoch'; Matt Dowle; [hidden email]
> 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:[hidden email]] On Behalf Of
> Duncan  > Murdoch  > Sent: Monday, October 05, 2015 6:57 PM  > To: Matt
> Dowle <[hidden email]>; [hidden email]  > 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
>  >
>  > ______________________________________________
>  > [hidden email] mailing list
>  > https://stat.ethz.ch/mailman/listinfo/r-devel
>
> ______________________________________________
> [hidden email] 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.
______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel