Front page | perl.perl5.porters |
Postings from March 2000
RE: Source filters
Thread Next
From:
Marquess,P,Paul,NEL38 R
Date:
March 24, 2000 11:37
Subject:
RE: Source filters
Message ID:
5104D4DBC598D211B5FE0000F8FE7EB2067FE5EB@mbtlipnt02.btlabs.bt.co.uk
From: Gurusamy Sarathy [mailto:gsar@ActiveState.com]
> On Fri, 24 Mar 2000 11:51:15 GMT, "Moore, Paul" wrote:
> >If so, there are some problems with Filter-1.17 when used with a Perl
built
> >with MULTI/ITHREADS/IMP_SYS on Win32. Specifically, the filter callback
> >functions seem to be missing the appropriate scattering of pTHXo_ in the
> >declarations. I've attached a patch for this.
>
> It needs a more complete patch than that. See below.
Thanks Sarathy, I'll try to upload a new version to CPAN this weekend with
the patch included. The only change I'll add is to make it work on pre-pTHX*
Perls and pre-ANSI C compilers.
> >However there are still test failures.
> >
> >t/call fails with errors which look related to binmode scripts (test 24
is
> >failing and it uses filter_read_exact, which may be going wrong because
each
> >line has an extra character (CR) beyond what is expected.
> >t/decrypt, t/order and t/tee fail as well, which may be similar.
> >Worse are t/cpp, t/exec and t/sh, which crash Perl. I can't see why.
Don't you run win95 Paul? If so it is probably the use of shell
metacharacters in the test harness.
> >
> >I think the binmode scripts thing is going to be a nasty portability
> >problem. IMHO, the user of the Filter module should not have to worry
about
> >line ending conventions in scripts. Of course, if the filter is slurping
in
> >binary data and translating it, binmode is necessary (that's why it was
> >introduced, for byteloader). Maybe the filter module needs something in
the
> >API to request binmode or textmode input of the script (with textmode the
> >default, as I expect the majority of filters will be text-based).
>
> I disagree. See ByteLoader. It would be the job of the particular filter
> implementation to know whether it wants to filter "text" or "binary"
input,
> and behave accordingly.
>
> I think Filter::Util::Call could use some convenience switches
> to do s/\r$// in filter_read() or ignore CRs when counting characters
> in filter_read_exact(). But I don't think it's really that big a
> portability issue if it can be clearly documented.
>
> >This is starting to look hard...
>
> The attached patch makes Filter 1.16 pass all tests on Windows, assuming
> you have GNU cpp.exe and tr.exe installed. It fails test 24 on Linux,
> for reasons that aren't clear. I haven't investigated much, but it
> seems that it could be a bug in either Filter (buffering issue?) or
> stdio. The problem that causes the failure is that the initial read
> from filter_read_exact() in test 24 doesn't return nine characters
> like it is supposed to. Instead it returns only two.
Hmmm, I haven't had a chance to build 5.6.0 yet, but 5.6.0-RC[123] passed
test 24 on my Linux box. I'll check it out once I get 5.6.0 built.
> I haven't checked Filter 1.17, but IIRC it only had documentation
> updates, so this patch should apply there too. (Note to PMQS: Filter
> should probably require/strongly recommend Perl 5.6.0 on Windows.
OK.
> Earlier versions of Perl are suboptimal, owing to the fact that
> PL_rsfp wasn't opened in binmode().)
Paul
Thread Next