> On 17 Dec 2015, at 19:58 , Michael Felt <aixto...@gmail.com> wrote:
>
> On 2015-12-17 19:30, peter dalgaard wrote:
>> Presumably the file in question is one of
>>
>> Peter-Dalgaards-MacBook-Air:BUILD pd$ grep -r "^Package: tools" *
>> library/tools/DESCRIPTION:Package: tools
>> src/library/tools/DESCRIPTION:Package: tools
>>
>> so the first thing I'd do is to have a good look at those files and see if
>> they got somehow corrupted.
>>
>> If they look sane, presumably the bit of code that checks it isn't... So
>> that would be my next thing to check.
>>
>> -pd
> I had just gotten here, and tried comparing them with the 32-bit build (as I
> do not know what sane is yet).
>
> Sources are in:
> /data/prj/cran/R-3.2.3
>
> Builds are in:
> /data/prj/cran/32/R-3.2.3 and
> /data/prj/cran/64/R-3.2.3
>
> The files, in the build directories look "sane", at least comparable
OK. Perhaps a check for special characters with a hex editor, just to be sure?
But probably not the cause.
>
> root@x065:[/data/prj/cran/R-3.2.3]sdiff -w 132
> /data/prj/cran/??/R-3.2.3/library/tools/DESCRIPTION
> Package: tools Package:
> tools
> Version: 3.2.3 Version:
> 3.2.3
> Priority: base Priority:
> base
> Title: Tools for Package Development Title:
> Tools for Package Development
> Author: R Core Team Author: R
> Core Team
> Maintainer: R Core Team <r-c...@r-project.org>
> Maintainer: R Core Team <r-c...@r-project.org>
> Description: Tools for package development, administration and
> Description: Tools for package development, administration and
> License: Part of R 3.2.3 License:
> Part of R 3.2.3
> Suggests: XML, codetools, methods Suggests:
> XML, codetools, methods
> Built: R 3.2.3; powerpc-ibm-aix5.3.7.0; 2015-12-17 12:02:34 UTC | Built: R
> 3.2.3; ; Thu Dec 17 17:39:55 UTC 2015; unix
>
> As the 32-bit build completes, while the 64-bit stops at "tools" there is a
> difference in what they have available:
>
> root@x065:[/data/prj/cran/R-3.2.3]ls -l
> /data/prj/cran/??/R-3.2.3/library/tools
> /data/prj/cran/32/R-3.2.3/library/tools:
> total 72
> -rw-r--r-- 1 root 33 356 Dec 17 12:02 DESCRIPTION
> -rw-r--r-- 1 root 33 3665 Dec 16 11:37 INDEX
> drwxr-sr-x 2 root 33 4096 Dec 17 08:45 Meta
> -rw-r--r-- 1 root 33 7112 Dec 17 12:02 NAMESPACE
> drwxr-sr-x 2 root 33 4096 Dec 17 12:02 R
> drwxr-sr-x 2 root 33 4096 Dec 16 11:37 help
> drwxr-sr-x 2 root 33 4096 Dec 16 11:37 html
> drwxr-sr-x 2 root 33 4096 Dec 16 11:34 libs
>
> /data/prj/cran/64/R-3.2.3/library/tools:
> total 40
> -rw-r--r-- 1 root 33 339 Dec 17 17:40 DESCRIPTION
> -rw-r--r-- 1 root 33 7112 Dec 17 17:40 NAMESPACE
> drwxr-sr-x 2 root 33 4096 Dec 17 17:19 R
> drwxr-sr-x 2 root 33 4096 Dec 17 05:58 libs
>
> So, is dcf.c, or main.c the better place to check. dcf.c does not look like
> "fun" - all those lexical arguments at the start:
Cue story of looking for keys under lamppost...
>
> SEXP attribute_hidden do_readDCF(SEXP call, SEXP op, SEXP args, SEXP env)
> {
> .... man many lines ....
> } else {
> /* Must be a regular line with no tag
> ... */
> line[20] = '\0';
> error(_("Line starting '%s ...' is
> malformed!"), line);
> }
> }
> }
> }
> ... more lines to go...
>
As you're dying in an else clause, a previous if () must contain the clue.
Unfortunately not necessarily the matching one.
My guess is that your TRE library is broken. The line should have matched the
RE "regline" defined as
tre_regcomp(®line, "^[^:]+:[[:blank:]]*", REG_EXTENDED);
...and used here:
if(tre_regexecb(®line, line, 1, regmatch, 0) == 0) {
but apparently does not.
> Thanks for the assistance!
>
> Michael
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Office: A 4.23
Email: pd....@cbs.dk Priv: pda...@gmail.com
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
