Re: [perl #37336] [RESOLVED] [BUG] Parrot 0.3.0 t/pmc/io.t assert core dump
Jarkko Hietaniemi
> According to our records, your request regarding
> "[BUG] Parrot 0.3.0 t/pmc/io.t assert core dump"
> has been resolved.
According to my records, it's a TODO test and therefore not quite
yet resolved :-)
> If you have any further questions or concerns, please respond to this message.
>
> For other topics, please create a new ticket.
>
> Please don't feel obligated to say "Thanks" or "Kudos" or "I owe you a beer" -- if you respond to this message it will reopen the ticket. If you must, please send email directly to the person who handled your ticket, and not to the tracking system.
>
> <URL: https://rt.perl.org/rt3/Ticket/Display.html?id=37336 >
>
Joshua Hoblitt
> Joshua Hoblitt via RT wrote:
> > According to our records, your request regarding
> > "[BUG] Parrot 0.3.0 t/pmc/io.t assert core dump"
> > has been resolved.
>
> According to my records, it's a TODO test and therefore not quite
> yet resolved :-)
It's a test failure for unimplemented feature(s). There is already a
TODO ticket (bug #31178) that ruffly covers this. Can you make a case
for why it needs to be to tracked as a software defect?
Cheers,
-J
--
Jarkko Hietaniemi
> On Sat, Oct 15, 2005 at 11:09:38AM +0300, Jarkko Hietaniemi wrote:
>
>>Joshua Hoblitt via RT wrote:
>>
>>>According to our records, your request regarding
>>> "[BUG] Parrot 0.3.0 t/pmc/io.t assert core dump"
>>>has been resolved.
>>
>>According to my records, it's a TODO test and therefore not quite
>>yet resolved :-)
>
>
> It's a test failure for unimplemented feature(s). There is already a
> TODO ticket (bug #31178) that ruffly covers this. Can you make a case
> for why it needs to be to tracked as a software defect?
A core dump is a software defect, an unacceptable failure, doesn't
matter whether it is from an assert or not. If Parrot's
development thinks differently or uses different terms, fine,
close the ticket.
> Cheers,
>
> -J
>
> --
>
Leopold Toetsch
> Joshua Hoblitt via RT wrote:
>>It's a test failure for unimplemented feature(s). There is already a
>>TODO ticket (bug #31178) that ruffly covers this. Can you make a case
>>for why it needs to be to tracked as a software defect?
>
> A core dump is a software defect, an unacceptable failure, doesn't
> matter whether it is from an assert or not. If Parrot's
> development thinks differently or uses different terms, fine,
> close the ticket.
The core dump is caused by a TODO test, which tests 'features' that will
be removed anyway. The test does something like:
new P0, Undef
read S0, P0, 1
Citing chip from the other ticket #31178:
[TODO] IO - off with its head! er, opcodes!
IO doesn't belong as opcodes.
Design a standard IO library ... base it on something sane that already
exists ... and get all those IO functions the heck out of our opcode
space.
---
That means, that the C<read> opcode (and some other IO opcodes) will be
removed and replaced by a ParrotIO method. Calling "read" on a PMC that
can't "read" will just throw a "method not found" exception and this
case is resolved.
Anybody might decide, how many open tickets we need for this, and how
severe this one segfault is.
leo