---
osname= linux
osvers= 2.4.21-27.0.2.elsmp
arch= i386-linux-thread-multi
cc= gcc 4.0.0 20050516 (Red Hat 4.0.0-6)
---
Flags:
category=core
severity=medium
ack=no
---
Under Parrot 0.2.3 the following PIR program prints "4" as
expected:
.sub "main" @MAIN
.local pmc a, b
a = new Integer
a = 2
b = a.__add(a)
print b
print "\n"
end
.end
Under Parrot 0.3.0 the same code fails like this:
parrot: src/nci.c:72: get_nci_P: Assertion `n < st->src.n' failed.
Aborted
Regards,
Roger Browne
---
Summary of my parrot 0.3.0 (r9313) configuration:
configdate='Mon Oct 3 20:04:05 2005'
Platform:
osname=linux, archname=i386-linux-thread-multi
jitcapable=1, jitarchname=i386-linux,
jitosname=LINUX, jitcpuarch=i386
execcapable=1
perl=/usr/bin/perl
Compiler:
cc='gcc', ccflags='-D_REENTRANT -D_GNU_SOURCE -DDEBUGGING -pipe -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm',
Linker and Libraries:
ld='gcc', ldflags=' -L/usr/local/lib',
cc_ldflags='',
libs='-lresolv -lnsl -ldl -lm -lcrypt -lutil -lpthread -lrt -lgmp'
Dynamic Linking:
share_ext='.so', ld_share_flags='-shared -L/usr/local/lib -fPIC',
load_ext='.so', ld_load_flags='-shared -L/usr/local/lib -fPIC'
Types:
iv=long, intvalsize=4, intsize=4, opcode_t=long, opcode_t_size=4,
ptrsize=4, ptr_alignment=1 byteorder=1234,
nv=double, numvalsize=8, doublesize=8
---
Environment:
HOME LANG LANGUAGE LD_LIBRARY_PATH LOGDIR PATH SHELL
> Under Parrot 0.2.3 the following PIR program prints "4" as
> expected:
>
> .sub "main" @MAIN
> .local pmc a, b
> a = new Integer
> a = 2
> b = a.__add(a)
> print b
> print "\n"
> end
> .end
>
> Under Parrot 0.3.0 the same code fails like this:
>
> parrot: src/nci.c:72: get_nci_P: Assertion `n < st->src.n' failed.
Yep. The equivalent tests in t/pmc/mmd.t are still skipped. The problem
is that the infix multi subs take an optional 3rd argument (the
destination) and that there is no good means yet to denote :optional
NCI arguments.
But please note that there is hardly a real need to invoke the method
directly. Just use:
b = a + a
This will call the "__add" multi, whatever it is.
leo
OK. It's my fault for developing against the 0.2.3 release rather than
against the svn branch.
> ... Just use:
>
> b = a + a
>
> This will call the "__add" multi, whatever it is.
The code I posted was just a minimal example to illustrate the
regression.
My real problem occurs in Amber's HLL code where I call functions like
"__add" directly (as part of the implementation of Amber's basic types),
and therefore Amber's basic types stopped working in 0.3.0.
I will implement the ability to have inline PIR fragments within Amber
code, so that I can use the workaround you suggest. No problem.
Regards,
Roger
>> b = a + a
>>
>>This will call the "__add" multi, whatever it is.
> My real problem occurs in Amber's HLL code where I call functions like
> "__add" directly (as part of the implementation of Amber's basic types),
Well, as said, that shouldn't be necessary. If your native types define
"__add" in PIR or PMCs provide the "add" multi sub, it will be called.
Tcl defines e.g. TclInt.divide inside languages/classes/tclint.pmc and
it is called, if MMD type signatures match.
> Regards,
> Roger
leo