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
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 C op somewhere near the beginning of the code
should preve
All that metadata up front in the PDDs is a bit off-putting. I'm
thinking of going through all of them and putting it at the end. Any
objections?
Also, throughout the distribution we use variously TITLE (aka TITEL)
and NAME with and without the file path.
I've been using
=head1 NAME
path/f
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.
Jonathan Worthington <[EMAIL PROTECTED]> wrote:
> I've attached a patch which causes stuff in begin.c to be put before the
> #include "parrot/parrot.h" line, which fixes up this problem. I don't know
> if it's the right thing to do, but it's the best one I could think of.
Applied.
> Please crea
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
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
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
.
.
.
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 o
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,
wha
My fault. I didn't specify -kb when I added the images. I suppose
that's it.
I'll hold off trying to fix it for the moment, in the hope that someone
with more CVS knowledge will beat me to it.
Mike
On 21 Feb 2004, at 23:05, Steve Fink wrote:
.
.
.
P docs/pmc/subs.pod
cvs server: internal
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 conn
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 si
13 matches
Mail list logo
