On Sunday 04 January 2009 06:38:08 Klaas-Jan Stol via RT wrote: > On Sun Jan 04 06:03:03 2009, rurban wrote:
> > The imcc problem is still there. Found by testing TT #127. > > The trace shows some off-by-one string failures: > > > > 98 get_class P0, "Data::Dumper" P0=PMCNULL > > 101 if_null P0, 5 P0=PMCNULL > > 106 load_bytecode "Data/Dumper.pbc" > > 0 get_class P1, "Data::Dumper" P1=PMCNULL > > 3 if_null P1, 5 P1=PMCNULL > > 8 load_bytecode "Data/Dumper/Default." > > 0 get_class P1, "Data::Dumper::Defaul" P1=PMCNULL > > 3 if_null P1, 5 P1=PMCNULL > > 8 load_bytecode "Data/Dumper/Base" > > I doubt whether it's IMCC. Compiling this to bytecode: > > .sub main > load_bytecode "test.pir" > .end > > and disassembling gives: > > Seq_Op_Num- Relative-PC SrcLn#: > Current Source Filename loadbc.pir > 000000000000-000000000000 000002: load_bytecode_sc "test.pir" > 000000000001-000000000002 000002: set_returns_pc PMC_CONST(2) > 000000000002-000000000004 000002: returncc > > So, the string test.pir is still there, implying imcc parses it > correctly, I think. That's correct. Parrot's tracing output only displays the first n characters of STRINGs. -- c
