At 8:55 PM +0200 4/14/02, Peter Gibbs wrote:
>The specific problem Clinton mentioned is yet another infant mortality
>problem, this time in string_concat. I don't know what the current decision
>is on handling these situations, but this one can be avoided by optimising
>the code anyway. If the tra
At 01:05 AM 4/15/2002 -0400, you wrote:
>Clint, in terms of getting things in Parrot fixed, I think it's better if
>you can provide a way to generate the bug, no matter how complex the case
>is. Non-simple test cases are better than no test cases at all, imo.
Okay. Good. I won't spend a *terrib
On Mon, Apr 15, 2002 at 01:05:41AM -0400, Mike Lambert wrote:
> > As a follow-up, I found one bug. Rather odd it is. The symptom is loading
> > a program, doing a LIST
> > and seeing only part of the code. Dumping the
> > string-which-contains-the-code you can see the entire program in it (unli
> As a follow-up, I found one bug. Rather odd it is. The symptom is loading
> a program, doing a LIST
> and seeing only part of the code. Dumping the
> string-which-contains-the-code you can see the entire program in it (unlike
> the earlier described bug). The problem was in here:
Clint, in
At 08:55 PM 4/14/2002 +0200, Peter Gibbs wrote:
>The specific problem Clinton mentioned is yet another infant mortality
>problem, this time in string_concat. I don't know what the current decision
>is on handling these situations, but this one can be avoided by optimising
>the code anyway. If the
At 08:55 PM 4/14/2002 +0200, Peter Gibbs wrote:
>The specific problem Clinton mentioned is yet another infant mortality
>problem, this time in string_concat. I don't know what the current decision
>is on handling these situations, but this one can be avoided by optimising
>the code anyway. If the
[Follow up to my previous post]
lib/Parrot/Assembler.pm creates all string constants with chartype = 0,
which, by virtue of the sequence of the enums in include/parrot/chartype.h
means unicode. So all string constants are type: unicode, encoding:
singlebyte.
I am not going to try and fix this on
The specific problem Clinton mentioned is yet another infant mortality
problem, this time in string_concat. I don't know what the current decision
is on handling these situations, but this one can be avoided by optimising
the code anyway. If the transcoding is done before making the result string,
At 1:24 PM -0400 4/14/02, Clinton A. Pierce wrote:
>At 10:06 PM 4/13/2002 -0400, Dan Sugalski wrote:
>>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
>>>collectio
At 10:06 PM 4/13/2002 -0400, Dan Sugalski wrote:
>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
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
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
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
13 matches
Mail list logo
