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/
