We seem to have broken the Tru64 (Ermine) and the Mac OS X 10.1 (glastig)
tinderboxen with yesterday's patchfest. Ermine is failing on the
super-huge string test for some reason. Did we have a regression in this
area somewhere? The redhat box I just added (see below) seems to
demonstrate the probl
Dan Sugalski wrote:
> This feels excessively hackish. It's OK if we were welding in COW to
> an existing code base, but we're not--if we put it in, we put it in
> right.
>
> Right, in this case, is using the COW flag bit in the Buffer
> structure and making the changes to the appropriate string_*
At 11:21 PM +0200 4/15/02, Peter Gibbs wrote:
> > Is this still needed with the update to Parrot_allocate to use
>> buffers? I think I took care of that.
>
>No, Parrot_allocate still sets buflen to the original requested 'size'; not
>the inflated 'req_size' - I'm not sure what you intended.
I i
> Is this still needed with the update to Parrot_allocate to use
> buffers? I think I took care of that.
No, Parrot_allocate still sets buflen to the original requested 'size'; not
the inflated 'req_size' - I'm not sure what you intended.
The behaviour of Parrot_allocate needs to clearly defined
At 11:07 PM +0200 4/15/02, Peter Gibbs wrote:
>Dan Sugalski wrote:
>
>> This has been applied too. There's something bugging me about it--I
>> think there may be issues, and I'd really like it if we made sure we
>> had a bunch of zero-length string tests in the test suite.
>
>The only issue I a
At 4:59 PM -0400 4/15/02, Mike Lambert wrote:
>Looks like this latest broke galatic and momentum boxes on tinderbox.
>Can't assigned to a casted pointer. I think the following patch should
>help.
Applied, thanks.
--
Dan
--
Dan Sugalski wrote:
> This has been applied too. There's something bugging me about it--I
> think there may be issues, and I'd really like it if we made sure we
> had a bunch of zero-length string tests in the test suite.
The only issue I am currently aware of with zero-length strings is the fac
Looks like this latest broke galatic and momentum boxes on tinderbox.
Can't assigned to a casted pointer. I think the following patch should
help.
Mike Lambert
Index: classes/array.pmc
===
RCS file: /cvs/public/parrot/classes/array.
At 10:26 PM +0200 4/15/02, Peter Gibbs wrote:
>
>Note that string_grow still has the problem with not bothering to allocate a
>new buffer if copysize is zero, e.g. if we are expanding a previously empty
>buffer.
>
>I have submitted a patch for this previously, but since string_grow has now
>change
Note that string_grow still has the problem with not bothering to allocate a
new buffer if copysize is zero, e.g. if we are expanding a previously empty
buffer.
I have submitted a patch for this previously, but since string_grow has now
changed, herewith a resynced patch.
--
Peter Gibbs
EmKel Sy
At 3:03 PM -0400 4/15/02, Simon Glover wrote:
> Looks pretty good here. One minor thing I noticed: the change to
> string_grow means that we've got an unused local variable, which
> the patch below gets rid of.
Applied. I'd hope the compilers would optimize that away, but it's
best to not be
Looks pretty good here. One minor thing I noticed: the change to
string_grow means that we've got an unused local variable, which
the patch below gets rid of.
Simon
--- string.c.oldMon Apr 15 14:55:09 2002
+++ string.cMon Apr 15 14:59:56 2002
@@ -72,7 +72,6 @@
*/
STRING *
st
I just checked in some fixes to the GC and memory systems that should
(theoretically) make Parrot a darn sight more stable. Some
particularly stupid things (like we never ran through the Buffer pool
to collect their memory, nor did we mark aggregate's Buffer structs
as live) were fixed, as wer
Which is the core of at least some of the parrot crashes. D'oh! (And
IIRC, Mike Lambert even pointed that out)
I'm adding code to do that. In the mean time, I wouldn't stare too
hard at bizarre crashes until then.
--
Dan
---
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
17 matches
Mail list logo
