Re: [PATCH] Don't mix PIO with stdio in Parrot_warn
Goplat [EMAIL PROTECTED] wrote: Using both PIO and stdio in Parrot_warn causes output to get mixed up when io is being buffered. Thanks, applied. leo
Re: [CVS ci] P6C added levels in test hierarchy
Allison Randal [EMAIL PROTECTED] wrote: The parrot memory corruption causing t/rx/call.t to fail is back, It isn't fixed yet. The potential corruption moves around, if byte code is added or removed. It might hit you or not. Placing a Ccollectoff op somewhere near the beginning of the code should prevent the corruption, *but* it can of course accumulate huge amounts of buffer memory in non trivial programs. Allison leo
Re: [perl #26966] [PATCH] JIT on POWER/AIX redux
Adam Thomason [EMAIL PROTECTED] wrote: As threatened, I've remade this patch for the improved platform system. aix/asm.s now sports sensible comments and less noise, and is a memory access or two faster to boot. AIX/POWER now passes all tests out of the box. Thanks to all who helped. Thanks, applied. leo
Re: JIT branches under the Sun
On Mon, Feb 16, 2004 at 09:08:55AM +0100, Leopold Toetsch wrote: I see. Your libc's sprintf seems to be missing the 0x prefix for the %p format. Ok you were right, that fixed it immediatly, and I'm now able to see within jit :). Attached are the dumps for this loop, with and without the print in between. Looking at it makes it pretty clear why it loops forever (mainly it jumps back to a load, loading always the same value). Somehow it relates to the way these jit sections are built afaik, but still do have to dig more and understand better its works. (if there are any hints/pointers, they are greatly appreciated ;) Thanks again for the help, Stephane PS.: apoligize for the delay in answering back. Also concerning fixing the debug part, I kind of prefer your second option (using Parrot_sprintf) since as I understand it its meant to avoid platform specific quirks? 0x00266570 jit_func+0:save %sp, -104, %sp 0x00266574 jit_func+4:add %i0, 0, %i2 0x00266578 jit_func+8:sethi %hi(0x266400), %i3 0x0026657c jit_func+12: or %i3, 0x130, %i3 ! 0x266530 0x00266580 jit_func+16: sethi %hi(0xfee7), %l0 0x00266584 jit_func+20: or %l0, 0xa0, %l0 ! 0xfee700a0 0x00266588 jit_func+24: sub %i1, %l0, %l0 0x0026658c jit_func+28: ld [ %i3 + %l0 ], %l0 0x00266590 jit_func+32: jmpl %l0, %l0 0x00266594 jit_func+36: nop 0x00266598 jit_func+40: mov 2, %l1 ! 0x2 0x0026659c jit_func+44: st %l1, [ %i2 + 4 ] 0x002665a0 jit_func+48: ld [ %i2 + 4 ], %l1 0x002665a4 jit_func+52: dec %l1 0x002665a8 jit_func+56: nop 0x002665ac jit_func+60: cmp %l1, 0 0x002665b0 jit_func+64: nop 0x002665b4 jit_func+68: bne,a 0x2665a0 jit_func+48 0x002665b8 jit_func+72: nop 0x002665bc jit_func+76: st %l1, [ %i2 + 4 ] 0x002665c0 jit_func+80: sethi %hi(0xfee7), %o0 0x002665c4 jit_func+84: or %o0, 0xc4, %o0 ! 0xfee700c4 0x002665c8 jit_func+88: call 0x8a43c Parrot_print_sc 0x002665cc jit_func+92: mov %i0, %o1 0x002665d0 jit_func+96: ret 0x002665d4 jit_func+100: restore # -- pasm used: set I1, 2 LOOP: sub I1, 1 ifI1, LOOP print end\n end 0x00266f10 jit_func+0:save %sp, -104, %sp 0x00266f14 jit_func+4:add %i0, 0, %i2 0x00266f18 jit_func+8:sethi %hi(0x266c00), %i3 0x00266f1c jit_func+12: or %i3, 0x2c8, %i3 ! 0x266ec8 0x00266f20 jit_func+16: sethi %hi(0xfee7), %l0 0x00266f24 jit_func+20: or %l0, 0xa0, %l0 ! 0xfee700a0 0x00266f28 jit_func+24: sub %i1, %l0, %l0 0x00266f2c jit_func+28: ld [ %i3 + %l0 ], %l0 0x00266f30 jit_func+32: jmpl %l0, %l0 0x00266f34 jit_func+36: nop 0x00266f38 jit_func+40: mov 2, %l1 ! 0x2 0x00266f3c jit_func+44: st %l1, [ %i2 + 4 ] 0x00266f40 jit_func+48: ld [ %i2 + 4 ], %l1 0x00266f44 jit_func+52: dec %l1 0x00266f48 jit_func+56: st %l1, [ %i2 + 4 ] 0x00266f4c jit_func+60: sethi %hi(0xfee7), %o0 0x00266f50 jit_func+64: or %o0, 0xb8, %o0 ! 0xfee700b8 0x00266f54 jit_func+68: call 0x8a254 Parrot_print_i 0x00266f58 jit_func+72: mov %i0, %o1 0x00266f5c jit_func+76: ld [ %i2 + 4 ], %l1 0x00266f60 jit_func+80: nop 0x00266f64 jit_func+84: cmp %l1, 0 0x00266f68 jit_func+88: nop 0x00266f6c jit_func+92: bne,a 0x266f40 jit_func+48 0x00266f70 jit_func+96: nop 0x00266f74 jit_func+100: sethi %hi(0xfee7), %o0 0x00266f78 jit_func+104: or %o0, 0xcc, %o0 ! 0xfee700cc 0x00266f7c jit_func+108: call 0x8a43c Parrot_print_sc 0x00266f80 jit_func+112: mov %i0, %o1 0x00266f84 jit_func+116: ret 0x00266f88 jit_func+120: restore # -- pasm used: set I1, 2 LOOP: sub I1, 1 print I1 ifI1, LOOP print end\n end 0x00263660 jit_func+0:save %sp, -104, %sp 0x00263664 jit_func+4:add %i0, 0, %i2 0x00263668 jit_func+8:sethi %hi(0x243c00), %i3 0x0026366c jit_func+12: or %i3, 0x2c8, %i3 ! 0x243ec8 0x00263670 jit_func+16: sethi %hi(0xfee7), %l0 0x00263674 jit_func+20: or %l0, 0xa0, %l0 ! 0xfee700a0 0x00263678 jit_func+24: sub %i1, %l0, %l0 0x0026367c jit_func+28: ld [ %i3 + %l0 ], %l0 0x00263680 jit_func+32: jmpl %l0, %l0 0x00263684 jit_func+36: nop 0x00263688 jit_func+40: mov 0x14d, %l1 ! 0x14d 0x0026368c jit_func+44: st %l1, [ %i2 + 4 ] 0x00263690 jit_func+48: ret 0x00263694 jit_func+52: restore 0x00263698 jit_func+56: st %l1, [ %i2 + 4 ] # -- pasm used: set I1, 333 end
[CVS ci] stacks
I've checked in a bunch of changes WRT stack code: * register frames and pad, user, control - stacks have now common code to handle new, push, pop, and copy * COW copying is now implemented (hopefully) correctly for all stacks This should also make the GC-related memory corruption vanish. leo
offtopic - first signs of a drug abuse problem?
On Feb-19, Dan Sugalski wrote: At 7:30 PM -0500 2/18/04, Simon Glover wrote: One really pedantic comment: wouldn't it make sense to rename the fetchmethod op to fetchmeth, for consistency with callmeth, tailcallmeth etc? Good point. I'll change that, then. D yo reall wan t repea C's infamou creat (mis)spellin? Admittedl, i i no ver ambiguou i thi cas, becaus ther ar alread s man letter, bu stil, tw extr letter i a smal pric t pa... steve, your words look like you'd been fetching too much 'meth' lately... :) and i agree 2 letters are indeed a small price for getting rid of this kind of bent and abominable humour once and for all LF
CVS update warning
. . . P docs/pmc/subs.pod cvs server: internal error: unsupported substitution string -kCOPY U docs/resources/parrot.small.png U docs/resources/perl-styles.css cvs server: internal error: unsupported substitution string -kCOPY U docs/resources/up.gif . . . Should those perhaps be -kb or -ko? My version of CVS certainly doesn't know COPY, nor have I ever heard of it.
Re: The Sort Problem: a definitive ruling
On Friday, February 20, 2004, at 05:48 , Damian Conway wrote:
Joe Gottman asked:
How do you decide whether a key-extractor block returns number? Do
you look at the signature, or do you simply evaluate the result of
the key-extractor for each element in the unsorted list? For example,
what is the result of the following code?
sort {$_.key} (1= 'a', 10 = 'b', 2 ='c');
There is nothing in the signature of the key-extractor to suggest
that all the keys are numbers, but as it turns out they all are. Will
the sort end up being numerical or alphabetic?
Whilst I'd very much like it to analyse the keys, detect that they're
all numbers, and use C =
Eek! Please don't even TRY to do that. It'd be creepy if the same call
to sort could swap at runtime between numeric and string comparisons
based upon its input. I would hope that the determination be made at
compile time.
Consider the poor schmuck sorting new objects in preparation for a merge
sort, only to find that his new array isn't sorted the same as his old
array was, even though they came back from the exact same call to
sort... Blech.
But if sort's arguments were specifically typed, i.e.:
my @array of Int;
@array = sort @array;
Does this meet the key extractor returns number qualification?
Gordon Henriksen
[EMAIL PROTECTED]
Re: Distributed testing idea
On Wed, Feb 18, 2004 at 06:49:19PM -0600, Ken Williams wrote: 1) In order to be convenient for the code author, he/she should be able to poll for available clients before submitting a job. My inclination would be to make this a simple inetd on the client, rather than any persistent connection between client server. I think if there were daemons on the client, or if the client had to connect to a daemon on the server, lots of clients would forget to do it when they rebooted. Its just as easy to make the client start on reboot as it is to add it to your inetd config. -- Michael G Schwern[EMAIL PROTECTED] http://www.pobox.com/~schwern/ Cuius rei demonstrationem mirabilem sane detexi hanc subscriptis exiguitas non caperet.
Re: Distributed testing idea
On Thu, Feb 19, 2004 at 08:35:28AM +, Nick Ing-Simmons wrote: Michael G Schwern [EMAIL PROTECTED] writes: One thing to keep in mind is portability. In order for this to be useful it has to run on pretty much all platforms. Unix, Windows, VMS, etc... So I'm trying to keep it as simple as possible. *snip* HTTPS might be overkill, we don't need to encrypt the communications, just identify the server. A simple thing to do would be for my server to have a public/private key pair. How about layering it on ssh then? See above. Yes, ssh is not portable enough. -- Michael G Schwern[EMAIL PROTECTED] http://www.pobox.com/~schwern/ I've just gone through a lung-crushing breakup with my blender and I don't think I should screw my forehead alone tonight.
