On Sat, Dec 02, 2006 at 09:13:47AM -0500, David Golden <[EMAIL PROTECTED]>
wrote:
> >As I cannot reproduce this with 5.8.8, could you try it with a current
> >version of perl to see wether this bug has been fixed in the meantime?
>
> It is.
Thanks, thats good, although at least one very similar failure was
reported with a 5.8.8 perl.
> >The purpose of tests is actually to test stuff: Forcing the module to use
> >an event model that works over the one that will get used will only hide
> >bugs.
>
> You're missing my broader point
I do not think so, but you might know better than me, of course.
> you're not running a controlled test.
I am. What makes you think differently?
> For each Event module you support, you should force the usage
> of a particular module if its available on the system running tests
> (and skip otherwise). Then you could more easily isolate problems to
> Event, Coro, Tk, etc.
Yes, but thats a lot of effort for little actual gain, as all those
modules contain testsuites themselves.
> >That would be quite a bit more useful, but I won't have the time for that
> >:)
>
> You don't have time to write it,
I do not have the time.
> tests? Some other "Any" interfaces allow specification of which
> underlying module to use through the "use" line.
Similar to AnyEvent, yes.
> All you have to do is code that up and then cut/paste your test program
> for each underlying event module and run/skip depending on if its
> available.
All I have to do is use time I can likely spend on other, more important,
stuff, yes, thats completely correct.
Now, as it seems to be very easy for you, all you have to do is to write
those tests and submit them. Would certainyl save me a lot of time and
would reach your goal, while at the same time improving the module...
> >Well, I doubt the event model makes a big difference.
>
> The event models rely on XS, right?
Nope. Some of them do, though.
> So they can corrupt anything the perl binary can corrupt.
When you debug a problem you start with the most likely bug candidate you
can identify. Which, in this case, is perl itself. When you rule out the
most likely candidate, you go on with the next.
Besides, your logic is not very useful: XS modules corrupt memory through
bugs. The same thing is true with Perl programs. So if you have memory
corruption, it can be caused by XS, or Perl, or other factors. XS is not a
likely candidate just because it is XS.
In this case, it is very unlikely that the Event models make an essential
difference, especially as they have been well-tested by me (leading to
actual bugfixes in Glib, event and Tk), thus the doubt, which I think is
quite reasonable.
--
The choice of a
-----==- _GNU_
----==-- _ generation Marc Lehmann
---==---(_)__ __ ____ __ [EMAIL PROTECTED]
--==---/ / _ \/ // /\ \/ / http://schmorp.de/
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE
