Michel Pelletier <[EMAIL PROTECTED]> wrote: > The first is multi-inheritance stopped working, but that's not as big a > deal as the new problem.
I've changed a few bits in object code during Pie-thon hacking, which is likely the cause for the problem. A small code snippet that exposes the error would be fine. IIRC these two are the main issues: - some behavior WRT default.pmc's method redirection changed e.g. get_pmc_keyed_int => get_pmc_keyed - you have to be more careful about calling conventions of return values. E.g. you can now override get_string like so: .namespace ["Foo"] .sub __get_string $P0 = new .String $P0 = "xyz" I3 = 1 # one PMC return value P5 = $P0 invoke P1 I've written here the return sequence explicitely to show what's hidden if you use .pcc_begin_return ... Anyway, as the signature of __get_string awaits a STRING* value and as the return value is indicated as one PMC by setting I3, the STRING* get's automatically extracted by calling get_string() on the returned PMC. This BTW leads to nice endless loops, if the returned PMC is a Foo object :) > ... Consider: > .sub _main @MAIN > BeginInteraction: > getstdin $P0 > print ">>>" > readline $S0, $P0 > print $S0 > goto BeginInteraction > .end > Print a prompt, There was a bug in the buffered IO layer (io_buf.c) WRT stdout line buffering. The initialization code did try to turn on line buffering, but failed twice: the init layer calls were the wrong order (from up to down, but an upper layer needs e.g an initialized STDOUT handle) and line buffering for output was unimplemented anyway ;) So we now have line buffering turned on by default for STDOUT, which of course breaks above example. There are several ways to adapt the code to the new behavior: 1) pop off the buffered I/O layer: getstdout Px Sx = pop Px # Sx = 'buf' 2) explicitely flush output getstdout P2 # PASM syntax callmethod "flush" 3) turn off line buffering $P0 = getstdout # PIR syntax $P0."setbuf"(0) See classes/parrotio.pmc:class_init() for available methods. > -Michel leo