Loading ...
Sorry, an error occurred while loading the content.

97ParseXS Changes and Strawberry Perl

Expand Messages
  • James E Keenan
    Aug 23, 2010
    • 0 Attachment
      At YAPC::NA::2010 in Columbus, Ohio, in June, Curtis Jewell of the
      Strawberry Perl project attended my presentation. Curtis
      subsequently gave our proposed revisions a spin on Strawberry Perl.
      Here I summarize some of our off-list correspondence.

      1.

      > On Aug 19, 2010, at 9:24 PM, Curtis Jewell wrote:
      >>
      >> I have downloaded your branch, and the first thing that needs done is
      >> that the Build.PL's override of do_create_makefile_pl needs fixed,
      >> specifically this line:
      >>
      >> $self->do_system(qw(perl -pi -e), q{s/'INSTALLDIRS' =>
      >> '\w+'/'INSTALLDIRS' => (\$] < 5.008009 ? 'site' : 'perl')/},
      >> 'Makefile.PL');
      >>
      >> The fix would be replacing that line by these two lines:
      >>
      >> $self->do_system(qw(perl -pi.bak -e), q{s/'INSTALLDIRS' =>
      >> '\w+'/'INSTALLDIRS' => (\$] < 5.008009 ? 'site' : 'perl')/},
      >> 'Makefile.PL');
      >> unlink 'Makefile.PL.bak';
      >>
      >> You can't do a plain -pi on Win32 is why - this is the output you
      >> get.
      >>
      >> C:\Documents and
      >> Settings\Administrator\Desktop\jkeenan-extutils-parsexs-db2e0c7>Build
      >> dist
      >> Creating Makefile.PL
      >> Can't do inplace edit without backup.
      >> Creating README using Pod::Readme
      >> Creating META.yml
      >> Creating ExtUtils-ParseXS-3
      >> Creating ExtUtils-ParseXS-3.tar.gz
      >>
      >> Note the second line - that's what happens.
      >

      2.

      > On Aug 20, 2010, at 12:49 AM, Curtis Jewell wrote:
      >
      >>
      >>
      >> On Wed, 18 Aug 2010 21:46 -0400, "James E Keenan" <jkeen@...>
      >> wrote:

      >> Houston, we have a problem.
      >>
      >> Specifically, t\106_process_typemaps.t fails. Backslash issues.
      >>
      >> Here's the STDOUT:
      >>
      >> t\001-basic.t ....................... ok
      >> t\002-more.t ........................ ok
      >> t\003-usage.t ....................... ok
      >> t\004-nolinenumbers.t ............... ok
      >> t\101-standard_typemap_locations.t .. ok
      >> t\102-trim_whitespace.t ............. ok
      >> t\103-tidy_type.t ................... ok
      >> t\104-map_type.t .................... ok
      >> t\105-valid_proto_string.t .......... ok
      >> t\106-process_typemaps.t ............
      >> Dubious, test returned 2 (wstat 512, 0x200)
      >> Failed 2/7 subtests
      >>
      >> Test Summary Report
      >> -------------------
      >> t\106-process_typemaps.t (Wstat: 512 Tests: 7 Failed: 2)
      >> Failed tests: 1-2
      >> Non-zero exit status: 2
      >> Files=10, Tests=101, 9 wallclock secs ( 0.11 usr + 0.07 sys = 0.18
      >> CPU)
      >> Result: FAIL
      >>
      >> Here's the STDERR:
      >>
      >> XSMore.c:306:9: warning: unknown escape sequence '\p'
      >> XSMore.c:306:9: warning: unknown escape sequence '\p'
      >>
      >> # Failed test 'Got expected result for no typemap in current
      >> directory'
      >> # at t\106-process_typemaps.t line 26.
      >> # 'Can't find typemap in C:\tmp\tempenv\0ntG6E1OPV
      >> # '
      >> # doesn't match '(?-xism:Can't find typemap in
      >> C:\tmp\tempenv\0ntG6E1OPV)'
      >> Unrecognized escape \J passed through in regex; marked by <-- HERE in
      >> m/Can't find pseudo in C:\tmp\tempenv\J <-- HERE b5uTgjjGU/ at
      >> t\106-process_typemaps.t line 43.
      >>
      >> # Failed test 'Got expected result for no typemap in current
      >> directory'
      >> # at t\106-process_typemaps.t line 43.
      >> # 'Can't find pseudo in C:\tmp\tempenv\Jb5uTgjjGU
      >> # '
      >> # doesn't match '(?-xism:Can't find pseudo in
      >> C:\tmp\tempenv\Jb5uTgjjGU)'
      >> # Looks like you failed 2 tests of 7.
      >> Failed 1/10 test programs. 2/101 subtests failed.
      >

      3.

      > On Aug 21, 2010, at 10:44 PM, James E Keenan wrote:
      >
      >>
      >> Just stared at this a little bit more.
      >>
      >>> Specifically, t\106_process_typemaps.t fails. Backslash issues.
      >>>
      >>> t\106-process_typemaps.t ............
      >>> Dubious, test returned 2 (wstat 512, 0x200)
      >>> Failed 2/7 subtests
      >>>
      >>> Test Summary Report
      >>> -------------------
      >>> t\106-process_typemaps.t (Wstat: 512 Tests: 7 Failed: 2)
      >>> Failed tests: 1-2
      >>> Non-zero exit status: 2
      >>> Files=10, Tests=101, 9 wallclock secs ( 0.11 usr + 0.07 sys =
      >>> 0.18
      >>> CPU)
      >>> Result: FAIL
      >>>
      >>> Here's the STDERR:
      >>>
      >>> XSMore.c:306:9: warning: unknown escape sequence '\p'
      >>> XSMore.c:306:9: warning: unknown escape sequence '\p'
      >>>
      >>> # Failed test 'Got expected result for no typemap in current
      >>> directory'
      >>> # at t\106-process_typemaps.t line 26.
      >>> # 'Can't find typemap in C:\tmp\tempenv\0ntG6E1OPV
      >>> # '
      >>
      >> Note that what you 'got' put you on to another line. So I suspect
      >> the content of your $@ included CRLF
      >>
      >>
      >>> # doesn't match '(?-xism:Can't find typemap in
      >>> C:\tmp\tempenv\0ntG6E1OPV)'
      >>
      >> But that's all on a single line. So I wonder: Could this be Unix
      >> vs DOS line ending problem, rather than Unix vs DOS path separator
      >> problem?
      >>
      >> I note that the error message in
      >> ExtUtils::ParseXS::Utilities::process_typemaps() includes a "\n"
      >> character:
      >>
      >> 370 foreach my $typemap (@tm) {
      >> 371 die "Can't find $typemap in $pwd\n" unless -r $typemap;
      >> 372 }
      >

      4.

      > On Aug 22, 2010, at 6:04 AM, Curtis Jewell wrote:
      >
      >> Good catch. I'll check that Monday morning and see what's going on
      >> there. We may have both backslash issues (because we would prefer
      >> not to
      >> to generate C code from XS files that goes "ick" on backslashes when
      >> compiled, I assume) and the newline issues yet.
      >