> [coke - Sun Aug 15 13:26:21 2004]:
>
> Purify, Valgrind, and other memory badness detectors
It's still very much welcome to run the whole test suite through valgrind (or
similar tools).
Steps towards this are (afaik):
- %ENV{TEST_PROG} = 'perl vg_tester.pl'
- err recreate this env var - s
Due to new calling scheme this is obsolete.
Re more powerful constant creation:
There's already a VTABLE method for constructing PMCs from STRINGs, e.g:
=item C
Class method to construct an array from the string representation C,
which is a string I<"(el0, el1, ...)">.
used for creating param/args signature arrays inside
src/pmc/fixedint
Applied as r13307.
Still needs some tweaking, e.g. fix the failing past.t, but good enough
for now.
leo
as mentioned on IRC, it looks like a GC bug, but
actually it was a COW string bug (a possibly already set live flag wasn't
cleared, which lead to half-moved string memory, s. resources.c:370)
Fixed w. r13400
Thanks, applied - r14594.
* moved to tools/dev directory
* be sure to 'make testr' before looking at script results *but*
* disassemble did hang here during that - I killed it after it
accumulate 1.7 GB of memory.
* there might be some disassemble bug lurking somewhere, which doesn't
make me wonde
Well, I forgot one preliminary:
We need a config test first, if SDL is present and working, which shall
define:
C defines perl5
PARROT_HAS_SDL HAS_SDL
PARROT_HAS_SDL_imageHAS_SDL_image
(It's not given that libSDL_image is present, *if* libSDL is i
The plan behind of as2c.pl is and was to create compiler independant
machine code for an architecture. masm, gas, nasm, whatever syntax
doesn't fit all compilers. Therefore as2c.pl translates gas syntax to a
bytestring, which is then used as the asm code.
as2c's usage is indeed scarce: when the cod
Thanks, I've applied a modified version of the patch, showing that it's
a namespace issue caused by the .HLL line. Using .loadlib works fine and
as expected.
leo
thanks, fixed in r15810.
leo
fixed in r16383
> [EMAIL PROTECTED] - Tue May 10 06:00:52 2005]:
[cc'ed to our list, ticket #35392 ]
> Dear Perl eating Parrots,
>
> I hope you are the appropriate person to send this email to.
Almost :) Please use perl6-internals@perl.org for replies or questions
about parrot.
> Will Perl 6 have a tracing AP
Woolley Kj <[EMAIL PROTECTED]> wrote:
> Not a biggie, but here is a quick patch for ops.num that should stop
> the warnings about ops 1426 to 1432 not being mentioned there.
It's not really decided, if these opcodes are 'official'. So I'd rather
wait a bit before nailing down ops.num.
> Che
WOOLLEY kj (via RT) wrote:
>
> Just a simple set of code cleanups, and moving (mostly headers) to
> PDD07 conformance (mostly guard statements).
Thanks, applied.
leo
Nicholas Clark <[EMAIL PROTECTED]> wrote:
> I have evidence that DOD runs can miss noticing local variable pointers to
> live objects on x86 Linux. This is happening while running ponie, but
> the problem is during a single call to string_make. The gdb traces are from
> a copy of the parrot source
Nicholas Clark wrote:
> The for loop inside trace_mem_block steps right over it. This if fails:
>
> /* Do a quick approximate range check by bit-masking */
> if ((ptr & mask) == prefix || !prefix) {
Argh, yes. I have pointed out quite a time ago that this mask check
isn't ok. Sm
16 matches
Mail list logo