On Thu, Oct 2, 2008 at 11:00 PM, chromatic <[EMAIL PROTECTED]> wrote:
> Can anything in the PIO_open() path throw an exception? If so, these strings
> will leak.
In a first look, it does not throw, but given that it calls layer
functions, one never can be sure. But I don't see a better solution
Forgot to forward to list:
On Thu Oct 02 18:37:05 2008, [EMAIL PROTECTED] wrote:
> On Wed Oct 01 16:09:41 2008, julianalbo wrote:
>
> >
> > I see a more generic problem. Several modules add lib links to the
> > parrot executable. Makes sense to link static libraries if that is the
> > intention
# New Ticket Created by I Sop
# Please include the string: [perl #59576]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=59576 >
I just copied the 'attribute' method, renamed everything, and changed the
parameter order for
On Thursday 02 October 2008 13:37:28 [EMAIL PROTECTED] wrote:
> Author: julianalbo
> Date: Thu Oct 2 13:37:27 2008
> New Revision: 31570
>
> Modified:
>trunk/src/ops/io.ops
>
> Log:
> some fixes in the open opcode
> --- trunk/src/ops/io.ops (original)
> +++ trunk/src/ops/io.ops Thu
> maybe a duplicate of #43485
>
> PIR code to reproduce:
>
> ..sub 'foo' :main
> $S0 = null
> $P0 = new 'Hash'
> # no crash without next line
> $P0['yum'] = 5
> $P1 = $P0[$S0]
> ..end
Fixed in r31566, together with a test adapted from this code.
Don't know if is related to #43
On Wednesday 01 October 2008 21:24:39 Stephen Weeks via RT wrote:
> Attached is a possible fix of this problem. I'm fairly certain that
> it's correct, but I'd like review from at least one other person before
> I commit it.
It makes sense to me. I wonder if we could re-enable the optimization
>> > I think will be better the other way, using the return value to flag
>> > existence, and passing a pointer to store the result. This will allow
>> > shorter and cleaner code.
>
> Another possibility might be to avoid the extra parameter altogether,
> returning NULL (not PMCNULL) if the element
On Thu, Oct 02, 2008 at 04:51:32PM +0100, Nick Glencross wrote:
> NotFound,
>
> That would look cleaner, wouldn't it? I'll give it a go.
>
> Nick
>
> On Thu, Oct 2, 2008 at 3:35 PM, NotFound <[EMAIL PROTECTED]> wrote:
> > I think will be better the other way, using the return value to flag
> > e
NotFound,
That would look cleaner, wouldn't it? I'll give it a go.
Nick
On Thu, Oct 2, 2008 at 3:35 PM, NotFound <[EMAIL PROTECTED]> wrote:
> I think will be better the other way, using the return value to flag
> existence, and passing a pointer to store the result. This will allow
> shorter and
> (I'd expect an exception to be raised instead.)
>
>
> PIR code:
>
> ..sub 'foo' :main
> $S0 = null
> $P0 = open $S0, '<'
> ..end
>
> output:
> src/string.c:2106: failed assertion 's'
Fixed in r31565 , but several questions opened:
Where to put a test for this? There is no t/ops/io.t and
I think will be better the other way, using the return value to flag
existence, and passing a pointer to store the result. This will allow
shorter and cleaner code.
--
Salu2
All,
Sorry, I see that I said opcode a new times, when of course I meant
PMC vtable entry.
Nick
# New Ticket Created by Nick Glencross
# Please include the string: [perl #59546]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=59546 >
Hi All,
This patch adds two new opcodes which allow a hash "exists" and "get"
to be p
Looks correct.
Tested on Linux i386, parrot test pass, perl6 test pass, test program
in the RT does not hang and the generated pbc contains the expected
opcodes.
Good work!
--
Salu2
# New Ticket Created by I Sop
# Please include the string: [perl #59542]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=59542 >
maybe a duplicate of #43485
PIR code to reproduce:
..sub 'foo' :main
$S0 = null
$P0 =
# New Ticket Created by I Sop
# Please include the string: [perl #59532]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=59532 >
The following PIR code causes a segfault:
Attached is a possible fix of this problem. I'm fairly certain that
it's correct, but I'd like review from at least one other person befor
eI commit it.
0001--imcc.patch
Description: Binary data
# New Ticket Created by I Sop
# Please include the string: [perl #59544]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=59544 >
(I'd expect an exception to be raised instead.)
PIR code:
..sub 'foo' :main
$S0 = null
The problem is that the vtable function get_class return NULL. This is
easily fixable, but the root of the problem is that the _class attribute
is set in init as PMCNULL, but later it contains NULL.
19 matches
Mail list logo