R Blotter demo not working under linux

StackOverflow https://stackoverflow.com/questions/12126192

  •  28-06-2021
  •  | 
  •  

Question

I am looking to run the r blotter demo program under linux, and get the following error when I run demo(amzn_test)

> # update the portfolio stats
> updatePortf("amzn_port",Dates="2010-01-14")
Error in if (nzchar(intervals[1])) s <- as.POSIXlt(do.call(firstof, parse.side(intervals[1]))) : 
  argument is of length zero

Interestingly, with the same version of R, everything runs fine in Windows. I am pretty new to R and hit a wall trying to trouble shoot. I did check the sessioInfo in Linux and Windows and they were a match except for the locale which I believe is OS specific.

On Linux:

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

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

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

other attached packages:
[1] lattice_0.20-6          blotter_0.8.10          FinancialInstrument_1.0 quantmod_0.3-17         TTR_0.21-1              Defaults_1.1-1         
[7] xts_0.8-6               zoo_1.7-7              

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

On Windows:

> sessionInfo()
R version 2.15.1 (2012-06-22)
Platform: x86_64-pc-mingw32/x64 (64-bit)

locale:
[1] LC_COLLATE=English_United States.1252  LC_CTYPE=English_United States.1252   
[3] LC_MONETARY=English_United States.1252 LC_NUMERIC=C                          
[5] LC_TIME=English_United States.1252
Was it helpful?

Solution

This issue has been patched in Rev. 1133. The code was using the time function on a list instead of on an xts object that the list contained. It looks like this has been a problem for a while, but until a change yesterday to explicitly use xts:::time.xts, a different time method was being dispatched which happily returned different values than intended without error. Thanks for the report.

If you need help checking out, building and installing the latest version, see this post

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top