Mail Archives: cygwin/2006/06/08/22:07:57
On Thu, Jun 08, 2006 at 10:03:58PM -0400, Christopher Faylor wrote:
>On Thu, Jun 08, 2006 at 05:11:29PM -0700, Yitzchak Scott-Thoennes wrote:
>>Linda Walsh wrote:
>>> Yitzchak Scott-Thoennes wrote:
>>>> Can he or you reduce the problem to a non-File::BOM dependent test
>>>> script
>>> What part of the perl module File::BOM should I throw out before
>>> it's no longer File::BOM? It's just perl code.
>>>
>>> It's freely downloadable through CPAN, so I can't make it too
>>> much more publicly available than that.
>>
>>The point would be to reduce the amount of code that might need
>>to be inspected to find the underlying problem. Nothing to do
>>with publicly available.
>>
>>> But FWIW, the File::BOM code isn't the actual problem. It's
>>> the authors test routine that he decided to be "fancy" with,
>>> and use a child process to send strings via a "FIFO" to the
>>> test harness process.
>>>
>>> It isn't desirable to modify "cygwin-only-failing" Perl modules
>>> to work around problems than only happen under cygwin. Certainly
>>> you can see how that is "burying one's head under the sand". Suppose
>>> various parts of CPAN are rewritten to steer around bugs in Cygwin.
>>> Does that make the underlying problems problems in Cygwin go away?
>>> Does that make cygwin more stable or more compatible with other
>>> Posix platforms?
>>>
>>> In my mind it eliminates test cases that are perfectly uncovering
>>> Cygwin incompatibilities and deficiencies.
>>
>>I agree with all of the above and wasn't trying to suggest modifying
>>the tests.
>
>Indeed, this is standard operating procedure for debugging problems.
In case this wasn't clear, I meant that winnowing down a failure to a
minimal amount of code required to reproduce the problem is "SOP".
cgf
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -