gcc3 issues?

Looks like we've got a slew of gcc3 issues (which don't show up on the tinderboxes, cause nobody's running a gcc3 box.) rspier@bear ~/projects/parrot$ make test perl t/harness t/op/basic..ok t/op/bitwiseok t/op/debuginfo..ok t/op/hacks..ok t/op/ifunless...ok t

Re: Is there a way to turn GC completely off?

At 5:35 PM -0400 4/13/02, Clinton A. Pierce wrote: >I'm fighting a now-you-see-it now-you-don't kind of bug and I was >wondering if there's a way to completely turn off garbage collection >and memory re-use for debugging? Yes. The sweepoff and collectoff ops will turn of DOD runs and GC sweeps

[PRE-RELEASE] 0.0.5 upcoming

Hopefully that'll get your attention. In the interests of accomplishing something this millennium, I'm planning to tag version 0.0.5 at some time around 12:01am EST Monday, April 15. I'll be watching mail up until the deadline, so if nobody complains, Monday evening I'll run the test suites and i

Re: Is there a way to turn GC completely off?

Clinton A. Pierce wrote: > I'm fighting a now-you-see-it now-you-don't kind of bug and I was wondering > if there's a way to completely turn off garbage collection and memory > re-use for debugging? The defined procedures for doing this are not currently implemented. The simplest way for now is p

Re: TODO additions

On Sat, 13 Apr 2002, Tom Hughes wrote: # Well that is what perl 5 does certainly. cool I didnt know that! (I've never pondered perl5 internals) # decided not to do that in perl 6 though due to issues about what # it meant to nul terminate in various different character sets. # We can't assume t

Is there a way to turn GC completely off?

I'm fighting a now-you-see-it now-you-don't kind of bug and I was wondering if there's a way to completely turn off garbage collection and memory re-use for debugging? My problems vanish when seemingly insignificant things happen, and re-appear again later. For example, I'll take a line of te

Re: TODO additions

In message <[EMAIL PROTECTED]> Roman Hunt <[EMAIL PROTECTED]> wrote: > why dont we default to null terminating strings of type native? > if "native" is what we get when LANG=C it only seems natural to do so. > else we are forced to use wrapper functions a that grow and manipulate > stri

Re: TODO additions

why dont we default to null terminating strings of type native? if "native" is what we get when LANG=C it only seems natural to do so. else we are forced to use wrapper functions a that grow and manipulate string data any time we need to pass it to standard C functions that wont accept a string_l

Re: Avoiding the deadlands

On Wed, Apr 10, 2002 at 12:28:33PM -0400, Dan Sugalski wrote: > At 4:54 AM -0400 4/9/02, Michel J Lambert wrote: > Right. A good spot for it is in either explicit DOD request ops, or > we require it as one of the ops run at block exit or something. We > may do a sweep when an exception's trigge

Re: Minor patch to make the GC count total bytes copied [APPLIED]

On 04/12/02 Dan Sugalski wrote: > FWIW, the numbers were: > > No JIT: Parrot 866 gen/sec Mono 11 gen/sec >JIT: Parrot 1068 gen/sec Mono 114 gen/sec Interesting data: was this taken a while ago? I get different ratios on my machine (PIII 1.1): Parrot JIT: 850 (though the output

Re: TODO additions

In message <[EMAIL PROTECTED]> Tom Hughes <[EMAIL PROTECTED]> wrote: > Syscall param open(pathname) contains uninitialised or unaddressable byte(s) > at 0x403F1892: __libc_open (__libc_open:31) > by 0x403829C3: _IO_fopen@@GLIBC_2.1 (iofopen.c:67) > by 0x809B287: cg_core

Re: TODO additions

In message <[EMAIL PROTECTED]> Steve Fink <[EMAIL PROTECTED]> wrote: > +Stability > +- > +Purify and other memory badness detectors One thing that may be useful here is valgrind, which can be found at http://developer.kde.org/~sewardj/ and does Purify types things on linux.