1.0 release - language checkin

[François Perrad]

2009/3/16 Allison Randal <allison at parrot.org>:
>
>
> François Perrad wrote:
>>
>> 2009/3/15 Allison Randal <allison at parrot.org>:
>>>
>>> Lua:
>>>  [ ] Passes all tests on trunk
>>
>> No, failed 151/1202
>
> Are these expected failures (i.e. because Lua is targeting a version other
> than trunk)?
>

These tests were ok with Parrot 0.7.1
There fail since Parrot 0.8.0 (Exception refactor ?)

Lua works fine when exception comes from PIR (die $S0),
but segfaults when exception comes from C (PMC in fact).

 $ cat add.lua
     print (42 + nil)

When the exception catching in docall (luaaux.pir) is disabled, the
result is normal :

 $ parrot lua.pbc add.lua
attempt to perform arithmetic on a nil value
current instr.: '&main_10' pc -339049740 ((unknown file):-1)
called from Sub '&main_10' pc 93 (EVAL_1:36)
called from Sub 'docall' pc 53207 (src/lib/luaaux.pir:997)
called from Sub 'handle_script' pc 50993 (lua.pir:303)
called from Sub 'main' pc 50480 (lua.pir:123)

otherwise, parrot segfaults with the following back trace :

#0  0xb7b384b5 in clone_key_arg (interp=0x804f040, st=0xbfaf6168) at
src/call/pcc.c:1191
#1  0xb7b38b2f in Parrot_convert_arg (interp=0x804f040, st=0xbfaf6168)
at src/call/pcc.c:1817
#2  0xb7b3973d in Parrot_process_args (interp=0x804f040,
st=0xbfaf6168, param_or_result=PARROT_PASS_PARAMS)
    at src/call/pcc.c:1694
#3  0xb7b39c68 in parrot_pass_args (interp=0x804f040,
src_ctx=0x83a1ad0, dest_ctx=0x8247938, src_indexes=0xb77030b8,
    dest_indexes=0xbfaf623c, param_or_result=PARROT_PASS_PARAMS) at
src/call/pcc.c:1884
#4  0xb7ca5ec4 in Parrot_Exception_nci_backtrace (interp=0x804f040,
pmc=0x80aa810)
    at /home/fperrad/checkout/parrot/tools/build/../../lib/Parrot/Pmc2c/PCCMETHOD.pm:442
#5  0xb7cca04b in Parrot_NCI_invoke (interp=0x804f040, pmc=0x80aa810,
next=0xb77030dc) at ./src/pmc/nci.pmc:330
#6  0xb7ac7e1d in Parrot_callmethodcc_p_sc (cur_opcode=0xb77030d0,
interp=0x804f040) at src/ops/object.ops:80
#7  0xb7b7a029 in runops_slow_core (interp=0x804f040, pc=0xb77030d0)
at src/runops_cores.c:461
#8  0xb7b3e8d0 in runops_int (interp=0x804f040, offset=53220) at
src/interpreter.c:980
#9  0xb7b3f501 in runops (interp=0x804f040, offs=53220) at src/call/ops.c:107
#10 0xb7b3f7e8 in runops_args (interp=0x804f040, sub=0x80eeaf8,
obj=0x80b0358, meth_unused=0x0, sig=0xb7e17aac "vP",
    ap=0xbfaf6498 "`�\016\b") at src/call/ops.c:254
#11 0xb7b4064d in Parrot_runops_fromc_args (interp=0x804f040,
sub=0x80eeaf8, sig=0xb7e17aac "vP") at src/call/ops.c:321
#12 0xb7b20bc0 in Parrot_ex_throw_from_c (interp=0x804f040,
exception=0x80edd60) at src/exceptions.c:341
#13 0xb7b20d05 in Parrot_ex_throw_from_c_args (interp=0x804f040,
ret_addr_unused=0x0, exitcode=37,
    format=0xb76c1990 "attempt to perform arithmetic on a %Ss value")
at src/exceptions.c:410
#14 0xb76a81cd in Parrot_LuaNumber_multi_add_DEFAULT_PMC
(interp=0x804f040, pmc=0x80ee618, value=0x80ede80, dest=0x0)
    at ./luanumber.pmc:338
#15 0x080c4131 in ?? ()
#16 0x0804f040 in ?? ()
#17 0x080ee618 in ?? ()
#18 0x080ede80 in ?? ()
#19 0x00000000 in ?? ()
(gdb)

>>>  [ ] Installs
>>
>> ok, but an installed Lua cannot load external libraries
>> (languages/lua/library/*.pbc)
>
> Ah, you're right. I intended to merge in the load_language branch right
> after 0.9.1, but it appears I didn't. It's a small feature addition (2 new
> opcodes and supporting C functions), but I'd rather not make it so close to
> release. I'll make the change right after the release, and have added a
> deprecation item for the C API that makes the change easier.
>
> In the meantime, I recommend installing into a language-name subdirectory
> within the main library/ directory, for example:
>
>  /usr/lib/parrot/1.0.0/library/lua/*.pbc
>
> Then loading with:
>
>  load_bytecode 'lua/foo.pbc'
>
> Not ideal, but it is at least solid, stable, and guaranteed to be easily
> found with existing stored configuration data in parrot_config and the
> Parrot::Config::Generated library. (It will also continue to work even after
> the new HLL loading opcodes are added, so won't require a deprecation
> notice.)
>
> Allison
>
>