Re: [Rd] example(smooth.spline) fails when function is NOT byte-compiled

2012-09-20 Thread Prof Brian Ripley
As the posting guide asked of you, try R-patched or R-devel before 
posting, and check the bug repository.


• smooth.spline() used DUP = FALSE which allowed its compiled C
  code to change the function: this was masked by the default
  byte-compilation. (PR#14965.)


On 19/09/2012 21:41, Hervé Pagès wrote:

Hi,

example(smooth.spline) fails with the non byte-compiled version of the
smooth.spline function:

example(smooth.spline)

   smth.s require(graphics)

   smth.s attach(cars)

   smth.s plot(speed, dist, main = data(cars)smoothing splines)

   [... more output deleted...]

   smth.s lines(smooth.spline(speed, dist, df=10), lty=2, col = red)
   Error in smooth.spline(speed, dist, df = 10) :
 smoothing parameter value too small

More precisely, here is what happens on a fresh R session (R-2.15.1
configured with --disable-byte-compiled-packages):

  ** Checking that smooth.spline() is not compiled:

smooth.spline
   [... output deleted...]
   environment: namespace:stats

  ** 1st call works:

res - smooth.spline(c(4, 4, 7, 7, 8, 9), c(2, 10, 4, 22, 16, 10))


  ** 2nd call fails:

res - smooth.spline(c(4, 4, 7, 7, 8, 9), c(2, 10, 4, 22, 16, 10))
   Error in smooth.spline(c(4, 4, 7, 7, 8, 9), c(2, 10, 4, 22, 16, 10)) :
 smoothing parameter value too small

  ** 3rd call (but now with the compiled version of the function) still
 fails:

library(compiler)

smooth.spline2 - cmpfun(smooth.spline)

smooth.spline2
   [... output deleted...]
   bytecode: 0x16813a0
   environment: namespace:stats

res2 - smooth.spline2(c(4, 4, 7, 7, 8, 9), c(2, 10, 4, 22, 16, 10))
   Error in smooth.spline2(c(4, 4, 7, 7, 8, 9), c(2, 10, 4, 22, 16, 10)) :
 smoothing parameter value too small

Thanks,
H.

My session info:

  sessionInfo()
R version 2.15.1 (2012-06-22)
Platform: x86_64-unknown-linux-gnu (64-bit)

locale:
  [1] LC_CTYPE=en_US.UTF-8   LC_NUMERIC=C
  [3] LC_TIME=en_US.UTF-8LC_COLLATE=en_US.UTF-8
  [5] LC_MONETARY=en_US.UTF-8LC_MESSAGES=en_US.UTF-8
  [7] LC_PAPER=C LC_NAME=C
  [9] LC_ADDRESS=C   LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C

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

loaded via a namespace (and not attached):
[1] tools_2.15.1





--
Brian D. Ripley,  rip...@stats.ox.ac.uk
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel:  +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax:  +44 1865 272595

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


[Rd] Rbuildignore question

2012-09-20 Thread Terry Therneau

I'm touching up changes to rpart and have a question with .Rbuildignore.  Here 
is my file

tmt1014% more .Rbuildignore
test.local
\.hg
src/print_tree.c


 The source code included a module print_tree.c, used for dubugging.  
Commented
out calls to can be found here and there.  I want to leave it in the source tree
even though no submitted copy of rpart will use it.

 Even with the ignore line above, R CMD check still compiles it, and gives a 
bad
boy NOTE about use of printf.  Can I/ should I/ how do I get rid of this?

(R 2.15.1)

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


Re: [Rd] Rbuildignore question

2012-09-20 Thread Duncan Murdoch

On 20/09/2012 1:43 PM, Terry Therneau wrote:

I'm touching up changes to rpart and have a question with .Rbuildignore.  Here 
is my file

tmt1014% more .Rbuildignore
test.local
\.hg
src/print_tree.c


   The source code included a module print_tree.c, used for dubugging.  
Commented
out calls to can be found here and there.  I want to leave it in the source tree
even though no submitted copy of rpart will use it.

   Even with the ignore line above, R CMD check still compiles it, and gives a 
bad
boy NOTE about use of printf.  Can I/ should I/ how do I get rid of this?


What do you mean, leave it in the source tree?  Since you're telling 
build to ignore it, I assume that's just for your own use, not for users 
of your package.  And what did you run check on, the tarball or the 
directory?  If you ran it on the tarball, then there's something wrong 
with your tarball, because it shouldn't be there (you said to ignore 
it).  If you're running check on the directory, then ignore the NOTE, 
because it shouldn't appear when you run it on the tarball.


Duncan Murdoch

__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel


Re: [Rd] Rbuildignore question

2012-09-20 Thread Terry Therneau

Thanks, that answers my question.
  1. I was running on the source tree.  And by leave in the source tree I mean just 
that, with local source code control managment.  It's in a place I can find it when needed.

It would appear on Rforge. But per your comment, not on the CRAN source.  Ok

  2. I'll check the tarball soon, but I'm guessing you are right about the 
error going
away.

On 09/20/2012 12:57 PM, Duncan Murdoch wrote:

On 20/09/2012 1:43 PM, Terry Therneau wrote:

I'm touching up changes to rpart and have a question with .Rbuildignore. Here 
is my file

tmt1014% more .Rbuildignore
test.local
\.hg
src/print_tree.c


The source code included a module print_tree.c, used for dubugging. Commented
out calls to can be found here and there. I want to leave it in the source tree
even though no submitted copy of rpart will use it.

Even with the ignore line above, R CMD check still compiles it, and gives a bad
boy NOTE about use of printf. Can I/ should I/ how do I get rid of this?


What do you mean, leave it in the source tree? Since you're telling build to 
ignore it,
I assume that's just for your own use, not for users of your package. And what 
did you run
check on, the tarball or the directory? If you ran it on the tarball, then 
there's
something wrong with your tarball, because it shouldn't be there (you said to 
ignore it).
If you're running check on the directory, then ignore the NOTE, because it 
shouldn't
appear when you run it on the tarball.

Duncan Murdoch


__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel