This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.
Send mail to mime@docserver.cac.washington.edu for more info.
------=_NextPart_000_0006_01C2432C.7ACD6BA0
Content-Type: TEXT/PLAIN; CHARSET=iso-8859-1
Content-Transfer-Encoding: 8BIT
Content-ID: <Pine.GSO.4.44.0208140920312.15226@auk.stats>
This is a separate bug, reproducible on Solaris, so I am re-filing it as a
new report.
There may well need to be a linewidth limit, but this should be caught.
R --vanilla < TooLongLines.R does work.
R-bugs mangles attachments, but my mailer does not like very long lines.
--
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
---------- Forwarded message ----------
Date: Wed, 14 Aug 2002 00:49:43 +0200
From: Henrik Bengtsson <hb@maths.lth.se>
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慱躀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
>
>
>
>
------=_NextPart_000_0006_01C2432C.7ACD6BA0
Content-Type: APPLICATION/OCTET-STREAM; NAME="TooLongLines.R"
Content-Transfer-Encoding: QUOTED-PRINTABLE
Content-ID: <Pine.GSO.4.44.0208140920320.15226@auk.stats>
Content-Description:
Content-Disposition: ATTACHMENT; FILENAME="TooLongLines.R"
# Doing source("TooLongLines.R") on this file and on [R] v1.5.1 on
WinMe will
# make [R] crash. The "reason" is that there is a too long source line
*inside*
# a function defintion. However, declaring a character variable with a very
# very long string works. See more comments below.
myFcn <- function() {
# I have inserted roman letter (L =3D 50, C =3D 100, D =3D 500, M =3D 1000) in
the string below to easier get the position of each character.
# Comments or something else, e.g.
x <- 2
# does not matter, the problem is the next very long line (>=3D2128
characters) inside a function() defintion:
"234567890123456789012345678901234567890123456789L1234567890123456789012345678901234567890123456789C1234567890123456789012345678901234567890123456789L1234567890123456789012345678901234567890123456789C1234567890123456789012345678901234567890123456789L1234567890123456789012345678901234567890123456789C1234567890123456789012345678901234567890123456789L1234567890123456789012345678901234567890123456789C1234567890123456789012345678901234567890123456789L1234567890123456789012345678901234567890123456789D1234567890123456789012345678901234567890123456789L1234567890123456789012345678901234567890123456789C1234567890123456789012345678901234567890123456789L1234567890123456789012345678901234567890123456789C1234567890123456789012345678901234567890123456789L1234567890123456789012345678901234567890123456789C1234567890123456789012345678901234567890123456789L1234567890123456789012345678901234567890123456789C1234567890123456789012345678901234567890123456789L1234567890123456789012345678901234567890123456789M1234567890123456789012345678901234567890123456789L1234567890123456789012345678901234567890123456789C1234567890123456789012345678901234567890123456789L1234567890123456789012345678901234567890123456789C1234567890123456789012345678901234567890123456789L1234567890123456789012345678901234567890123456789C1234567890123456789012345678901234567890123456789L1234567890123456789012345678901234567890123456789C1234567890123456789012345678901234567890123456789L1234567890123456789012345678901234567890123456789D1234567890123456789012345678901234567890123456789L1234567890123456789012345678901234567890123456789C1234567890123456789012345678901234567890123456789L1234567890123456789012345678901234567890123456789C1234567890123456789012345678901234567890123456789L1234567890123456789012345678901234567890123456789C1234567890123456789012345678901234567890123456789L1234567890123456789012345678901234567890123456789C1234567890123456789012345678901234567890123456789L1234567890123456789012345678901234567890123456789M1234567890123456789012345678901234567890123456789L1234567890123456789012345678901234567890123456789C123456789012345678901234567"
# Comments or something else, e.g.
x <- 2
# does not matter. Any line shorter than 2128 works fine, i.e. removing
# the last '7' from the string above and
source("TooLongLines.R") will
# be just fine.
} # myFcn()
# 'Rterm --vanilla' and 'RGUI.exe' ([R] v1.5.1 (2002-06-17) on
WinMe) both
# give 'Signal 127' and Dr. Mingw reports:
#
# RTERM.EXE caused an Access Violation at location 00486a03 in module R.DLL
Writing to location 00486a95.
# =20
# Registers:
# eax=3D00486a95 ebx=3D0091e990 ecx=3D0091ecb0 edx=3D00484028 esi=3D00000000
edi=3D0000007b
# eip=3D00486a03 esp=3D0091e8f4 ebp=3D0091e900 iopl=3D0 nv up ei pl nz
na po cy
# cs=3D018f ss=3D0197 ds=3D0197 es=3D0197 fs=3D271f gs=3D0000
efl=3D00010207
# =20
# Call stack:
# 00486A03 R.DLL:00486A03 R_Parse
# 004873D1 R.DLL:004873D1 Rf_yyerror
# 00487933 R.DLL:00487933 Rf_isValidName
# 00487ECC R.DLL:00487ECC Rf_yylex
# 00484D71 R.DLL:00484D71 Rf_yyparse
# 004866DF R.DLL:004866DF Rf_yyparse
# 004869E1 R.DLL:004869E1 R_Parse
# 00486B66 R.DLL:00486B66 R_ParseConn
# 004F6AC3 R.DLL:004F6AC3 do_parse
# 004AA5A7 R.DLL:004AA5A7 do_internal
# 0047F494 R.DLL:0047F494 Rf_eval
# 00480808 R.DLL:00480808 do_begin
# 0047F494 R.DLL:0047F494 Rf_eval
# 0047FAA6 R.DLL:0047FAA6 Rf_applyClosure
# 0047F6DD R.DLL:0047F6DD Rf_eval
# 00481065 R.DLL:00481065 do_set
# 0047F494 R.DLL:0047F494 Rf_eval
# 004812D9 R.DLL:004812D9 Rf_evalList
# 0047F5E2 R.DLL:0047F5E2 Rf_eval
# 00481065 R.DLL:00481065 do_set
# 0047F494 R.DLL:0047F494 Rf_eval
# 00480808 R.DLL:00480808 do_begin
# 0047F494 R.DLL:0047F494 Rf_eval
# 0047FAA6 R.DLL:0047FAA6 Rf_applyClosure
# 0047F6DD R.DLL:0047F6DD Rf_eval
# 0049D325 R.DLL:0049D325 R_PromptString
# 0049DC74 R.DLL:0049DC74 run_Rmainloop
# 0049DC8C R.DLL:0049DC8C Rf_mainloop
# 0040153D RTERM.EXE:0040153D
# 0040139C RTERM.EXE:0040139C
# 0040166D RTERM.EXE:0040166D
# 004010F4 RTERM.EXE:004010F4
# 004011EF RTERM.EXE:004011EF
# BFF7B9E4 KERNEL32.DLL:BFF7B9E4 IsDBCSLeadByte
# BFF7B896 KERNEL32.DLL:BFF7B896 IsDBCSLeadByte
# BFF7A24F KERNEL32.DLL:BFF7A24F MakeCriticalSectionGlobal
------=_NextPart_000_0006_01C2432C.7ACD6BA0--
-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
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
_._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._