FW: R CMD check: Too long [R] code line generated (PR#1900)
ripley@stats.ox.ac.uk
ripley@stats.ox.ac.uk
Wed, 14 Aug 2002 07:01:34 +0100 (BST)
On Wed, 14 Aug 2002, Henrik Bengtsson wrote:
> Sorry, but it was indeed the redirection of the standard output in
> Cygwin/bash that cause the first problem, not R (I should stop doing
> troubleshooting at 1:00 AM). So please forget about the problems reported in
> R_CMD_check.out. However, it would still be nice if you still update R CMD
> check to do join with "\n".
Yes, on ME. That was my prime suspect.
The change has already been made.
> Also, the problem with TooLongLines.R still remains since it crashes [R]
> also when sourced from within Rgui.exe.
Will take a look.
> Sorry about that, I hope none of you spent time on the first problem.
Not me: I could not reproduce it on XP.
> Henrik
>
> -----Original Message-----
> From: Henrik Bengtsson [mailto:hb@maths.lth.se]
> Sent: Wednesday, August 14, 2002 12:50 AM
> To: ripley@stats.ox.ac.uk
> Cc: r-devel@stat.math.ethz.ch; R-bugs@biostat.ku.dk
> Subject: RE: R CMD check: Too long [R] code line generated (PR#1900)
>
>
> I did some error tracking myself. I verified that the Perl generated
> temporary [R] file was correct. I narrowed down the problem to be with the
> redirecting of the standard input, i.e. <, into [R] and I also found that I
> could not get the same problem if I source()'d the same file. Then I thought
> it might be my shell (Cygwin/bash), but not! Doing
>
> % cat < R_CMD_check.out
>
> is just fine, but when doing
>
> R --vanilla --quiet < R_CMD_check.out
>
> I run into problems. It looks like every line that is long enough will get
> some garbage bytes inserted at column 1023. I have attached the
> R_CMD_check.out file with comments for you. As you see, it is not what R CMD
> check have generated, but as the problem is not with R CMD check itself
> anymore I removed the non-interesting parts.
>
> Maybe related to this is another problem that makes source() crash if I have
> a too long string (>2128 characters) inside a function definition. The
> attached R script TooLongLines.R is supposed to illustrate this. It also
> contains Dr. Mingw's report.
>
> FYI: I'll be out of the office from Wednesday noon-Sunday.
>
> Henrik Bengtsson
>
> > -----Original Message-----
> > From: ripley@stats.ox.ac.uk [mailto:ripley@stats.ox.ac.uk]
> > Sent: Tuesday, August 13, 2002 11:43 AM
> > To: hb@maths.lth.se
> > Cc: r-devel@stat.math.ethz.ch; R-bugs@biostat.ku.dk
> > Subject: Re: R CMD check: Too long [R] code line generated (PR#1900)
> >
> >
> > 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‘_ÜIoarrayData.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
> >
> >
> >
> >
>
--
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._