R CMD check: Too long [R] code line generated (PR#1900)
ripley@stats.ox.ac.uk
ripley@stats.ox.ac.uk
Tue, 13 Aug 2002 10:43:03 +0100 (BST)
On Tue, 13 Aug 2002 hb@maths.lth.se wrote:
> Full_Name: Henrik Bengtsson
> Version: 1.5.1
> OS: WinMe
> Submission from: (NULL) (217.210.0.243)
>
>
> In the Perl script $R_HOME/bin/check there is a bug under the section "Check R
> code for syntax errors" where the 'Rfiles <- c(...)' is build up. If there are
> too many files in @Rfiles the source code line generated will be too long and
> weird things will happen, e.g. strange bytes/characters will be inserted.
> SUGGESTION/SOLUTION:
> Add a new line character after each "join";
>
> $Rcmd .= join("\",\n \"", @Rfiles) . "\")\n";
>
> instead of
>
> $Rcmd .= join("\", \"", @Rfiles) . "\")\n";
>
>
> SUGGESTION II:
> I ran into similar problems in other situations where I autogenerated too long
> source lines. The errors where hard to reproduce and took time to find. It would
> be nice if the [R] parser, or some previous engine that reads the source file,
> could given an explicit error saying that the "line was too long".
>
> EXAMPLE:
> In my case I got in perl '@Rfiles' was:
> "R/LogBook.R R/LogEntry.R R/GenePixData.R R/Layout.R R/ImaGeneData.R
> R/MicroarrayData.PLOT.R R/QualityData.R R/MicroarrayData.R R/MAData.R
> R/MAData.NORM.R R/zzz.R R/Replicates.R R/SMA.R R/FieldFilter.R R/Filter.R
> R/QuantArrayData.R R/RGData.R R/RawData.R R/000.R R/MicroarrayData.IO.R
> R/LayoutGroups.R R/BFilter.R R/com.braju.sma.R R/Copy of TFilter.R R/Copy of
> SSMatrix.R R/private.utils.R R/WangetalData.R R/KHessFilter.R R/DfFilter.R
> R/SpotData.R R/ScanAlyzeData.R R/BMAData.R R/AFilter.R R/MFilter.R
> R/Layout.obsolete.R R/AndFilter.R R/OrFilter.R R/SEFilter.R R/TFilter.R
> R/AcceptFilter.R R/SpotPosition.R R/SerialFilter.R R/GSRArray.R
> R/MultiwayArray.R R/KHessData.R R/GeneAcceptFilter.R R/GeneData.R
> R/GeneRejectFilter.R R/TMAData.R R/NotFilter.R R/ParallelFilter.R
> R/RejectFilter.R R/ReplicateOutlierFilter.R R/WorkData.R R/Matrix.R
> R/MicroarrayData.LOG.R R/MicroarrayData.NORM.R R/SSMatrix.R"
>
> but in [R] 'Rfiles' became:
> [1] "R/LogBook.R" "R/LogEntry.R"
> [3] "R/GenePixData.R" "R/Layout.R"
> [5] "R/ImaGeneData.R" "R/MicroarrayData.PLOT.R"
> [7] "R/QualityData.R" "R/MicroarrayData.R"
> [9] "R/MAData.R" "R/MAData.NORM.R"
> [11] "R/zzz.R" "R/Replicates.R"
> [13] "R/SMA.R" "R/FieldFilter.R"
> [15] "R/Filter.R" "R/QuantArrayData.R"
> [17] "R/RGData.R" "R/RawData.R"
> [19] "R/000.R" "R/MicroarrayData.IO.R"
> [21] "R/LayoutGroups.R" "R/BFilter.R"
> [23] "R/com.braju.sma.R" "R/Copy of TFilter.R"
> [25] "R/Copy of SSMatrix.R" "R/private.utils.R"
> [27] "R/WangetalData.R" "R/KHessFilter.R"
> [29] "R/DfFilter.R" "R/SpotData.R"
> [31] "R/ScanAlyzeData.R" "R/BMAData.R"
> [33] "R/AFilter.R" "R/MFilter.R"
> [35] "R/Layout.obsolete.R" "R/AndFilter.R"
> [37] "R/OrFilter.R" "R/SEFilter.R"
> [39] "R/TFilter.R" "R/AcceptFilter.R"
> [41] "R/SpotPosition.R" "R/SerialFilter.R"
> [43] "R/GSRArray.R" "R/MultiwayArray.R"
> [45] "R/KHessData.R" "R/GeneAcceptFilter.R"
> [47] "R/GeneData.R" "R/GeneRejectFilter.R"
> [49] "R/TMAData.R" "R/NotFilter.R"
> [51] "R/ParallelFilter.R" "R/RejectFilter.R"
> [53] "R/ReplicateOutlierFilter.R" "R/WorkData.R"
> [55] "R/Matrix.R" "R/Micr\b‘_ÜI oarrayData.LOG.R"
> [57] "R/MicroarrayData.NORM.R" "R/SSMatrix.R"
>
> Look at the 56 element. Trying to add or remove files, I found that this was
> always happening at the same column in the Rfiles row and inferred that this is
> due to the maximum line length in [R] source files. Correct?
There is no such line limit. If I take your file list, convert it via the
orginal join and read it into R, I don't get a problem, under Linux or
Windows XP. I think you are hitting the limitations of your `operating
system', not R. But without a reproducible example it is hard to tell.
Package survival has 92 files with file names at least as long as yours,
and that works perfectly happily on Windows XP.
Can you make available a sample package which exhibits the problem?
Nevertheless, joining with "\n" should be a palliative measure.
--
Brian D. Ripley, ripley@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 272860 (secr)
Oxford OX1 3TG, UK Fax: +44 1865 272595
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
r-devel mailing list -- Read http://www.ci.tuwien.ac.at/~hornik/R/R-FAQ.html
Send "info", "help", or "[un]subscribe"
(in the "body", not the subject !) To: r-devel-request@stat.math.ethz.ch
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._