Skip to content

error with source(): invalid 'times' value

14 messages · Gabor Grothendieck, jim holtman, William Dunlap +2 more

#
hi

I am seeing a strange behavior I can't understand... doing:

 > source("/tmp/RFile.r",echo=TRUE)
Error in rep.int(c(prompt.echo, continue.echo), c(leading, length(dep) -  :
   invalid 'times' value
 > traceback()
3: rep.int(c(prompt.echo, continue.echo), c(leading, length(dep) -
        leading))
2: paste(rep.int(c(prompt.echo, continue.echo), c(leading, length(dep) -
        leading)), dep, sep = "", collapse = "\n")
1: source("/tmp/RFile.r", echo = TRUE)
 >

But the file I am trying to source is very simple... see:
$ more /tmp/RFile.r
###################################################
### chunk number 1:
###################################################
#line 516 "VolStocksDec2010.Rnw"
path<-"~/Dropbox/FAO/Papers/Volatility only"
pathMarkov<-"~/Dropbox/FAO/Markov Model/"
library(zoo)

Any idea where it can come from? It works fine when echo=FALSE... I am 
using R 2.12, on Ubuntu Linux 10.4 (R from CRAN), full session info 
below. Should I rather send this to r-devel?

Thanks a  lot

Matthieu


sessionInfo()
R version 2.12.1 (2010-12-16)
Platform: i486-pc-linux-gnu (32-bit)

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

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

loaded via a namespace (and not attached):
[1] grid_2.12.1         lattice_0.19-17     Matrix_0.999375-45
[4] nnet_7.3-1          tsDyn_0.7-40        tseries_0.10-23
[7] tseriesChaos_0.1-11
#
On Mon, Jan 24, 2011 at 12:07 PM, Matthieu Stigler
<matthieu.stigler at gmail.com> wrote:
Does this work?

source("/tmp/RFile.r", echo = TRUE, prompt.echo = NULL, continue.echo = "+ ")
#
Le 24. 01. 11 18:22, Gabor Grothendieck a ?crit :
Thanks for your quick answer!
Unfortunately, it does not change:
source("/tmp/RFile.r", echo = TRUE, prompt.echo = NULL, continue.echo = 
"+ ")
Error in rep.int(c(prompt.echo, continue.echo), c(leading, length(dep) -  :
   invalid 'times' value
 > traceback()
3: rep.int(c(prompt.echo, continue.echo), c(leading, length(dep) -
        leading))
2: paste(rep.int(c(prompt.echo, continue.echo), c(leading, length(dep) -
        leading)), dep, sep = "", collapse = "\n")
1: source("/tmp/RFile.r", echo = TRUE, prompt.echo = NULL, continue.echo 
= "+ ")

note this is not a systematic problem, but can't say exactly when/why it 
works or not...

thanks
#
It sounds like you have some invalid expressions.  Dump out the values
of 'leading' and 'length(dep) - leading'.  Learn some simple debugging
techniques.  One is to set

options(error=utils::recover)

so that on the error you can use the browser to examine what the values are.

On Mon, Jan 24, 2011 at 12:07 PM, Matthieu Stigler
<matthieu.stigler at gmail.com> wrote:

  
    
#
ok, thanks Jim

The problem comes from length(dep)<leading, so we get negative number...
 > length(dep)
[1] 183

c(leading, length(dep) - leading)
[1]  516 -333

But 183 seems to be the right number:
$ wc -l /tmp/RFile.r
183 /tmp/RFile.r

So now need to understand what is this "dep", and why it has a bigger 
length... tried to check source code (:-)) but could not get it... any 
idea?

Thanks a lot

Matthieu


Le 24. 01. 11 18:29, jim holtman a ?crit :
#
On Mon, Jan 24, 2011 at 12:29 PM, Matthieu Stigler
<matthieu.stigler at gmail.com> wrote:
Check getOption("prompt.echo") and getOption("continue") and try
different values for the prompt.echo= and continue.echo= arguments of
source. I am able to get your times error by using source("myfile.R",
echo = TRUE, continue.echo = NULL)
#
Do 'str(dep)' to see what dep is and where it comes from.  If you have
the 'options' set as I suggested, you can do this examination when the
error occurs.

On Mon, Jan 24, 2011 at 12:41 PM, Matthieu Stigler
<matthieu.stigler at gmail.com> wrote:

  
    
#
Put a space after the # in the line
#line 516
to avoid the problem.  A similar problem also
appears in parse().

  > parse(text="#line 102\nlog(pi)\n")
  Error in `Encoding<-`(`*tmp*`, value = character(0)) :
    'value' must be of positive length
  > parse(text="# line 102\nlog(pi)\n")
  expression(log(pi))
  attr(,"srcfile")
  <text>
  attr(,"wholeSrcref")
  # line 102
  log(pi)

(I'm still using 2.12.0.)

Bill Dunlap
Spotfire, TIBCO Software
wdunlap tibco.com
#
On 11-01-24 12:07 PM, Matthieu Stigler wrote:
There is no such version, but this looks like a bug that was fixed in 
2.12.1.  Are you using 2.12.0?  (I might be wrong about the timing of 
the fix; if you're using 2.12.1, try 2.12.1-patched.)

Duncan Murdoch
#
Hi

Well this is the output of str(dep) on a small example:
str(dep)
  chr [1:8] "###################################################" ...
Browse[1]> dep
[1] "###################################################"
[2] "### chunk number 1:"
[3] "###################################################"
[4] "#line 516 \"VolStocksDec2010.Rnw\""
[5] "path<-\"~/Dropbox/FAO/Papers/Volatility only\""
[6] "pathMarkov<-\"~/Dropbox/FAO/Markov Model/\""
[7] "library(zoo)"
[8] ""

it seems quite accurate... I guess the problem comes form leading... 
even if this smaller example, it is still the same number (516) as in 
the test with bigger source doc...

Can you reproduce this on your machine? I can reproduce it on two Linux 
buntu 10.4, R 2.12.1 ...

Thanks!!

Le 24. 01. 11 19:18, jim holtman a ?crit :
#
indeed this makes the trick! quite strange... is this a known bug/issue?

thanks!

Matthieu

Le 24. 01. 11 19:48, William Dunlap a ?crit :
#
Le 24. 01. 11 20:43, Duncan Murdoch a ?crit :
Indeed 2.12.1, sorry for imprecision! I will give a try to 
2.12.1-patched, although I am not so sure how I can install it (should I 
compile) on linux...

thanks!!
#
It is known now.  The problem arises while
printing the output of parse because the srcref
attribute contains the numbers from those
  #line <number>
entries and the printing routine gets confused
if the numbers are out of the range 1 through
the number of lines of text.

Bill Dunlap
Spotfire, TIBCO Software
wdunlap tibco.com
#
On 11-01-24 5:09 PM, mat wrote:
Bill Dunlap has already confirmed that this is not what was fixed (or 
what was fixed never made it into the sources).  I'll get to it, but not 
for a couple of weeks.

Duncan Murdoch