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
On 4/15/02 10:24 PM, Larry Wall wrote:
> So the main reason that objects can function as hashes is so that the
> user can poke an object into an interface expecting a hash and have it
> "make sense", to the extent that the object is willing to be viewed like
> that.
Sure, by why should that be th
Rich Morin writes:
: At 5:26 PM -0700 4/13/02, Larry Wall wrote:
: >Well, Perl 5 doesn't really support compact arrays of known size, and
: >those are the only kind that are easy to think about when it comes to
: >vectorization.
:
: Actually, I can think of other possibilities. For instance, are
[EMAIL PROTECTED] writes:
: On 4/15/02 5:16 PM, Damian Conway wrote:
: > if we don't support this, people will be forever having to create Perl 6
: > adapter classes just so that they can make use of legacy Perl 5 code. :-(
:
: Okay, how about making it a pragma that's not enabled by default? So
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
On 4/15/02 5:16 PM, Damian Conway wrote:
> if we don't support this, people will be forever having to create Perl 6
> adapter classes just so that they can make use of legacy Perl 5 code. :-(
Okay, how about making it a pragma that's not enabled by default? So all
those Perl 5 porters can do the
Luke Palmer wrote:
> > More interestingly, it may also be that, by default, the C (i.e.
> > hash-look-up) method of a class invokes the accessor of the same name as the
> > key, so that:
>
> I'm a tad bit confused on the grounds of classes. Are we allowed to:
> %fred = new Flintstone;
No. Not
> 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
> > $foo.{bar_attr} = 1;
> >
> > This would help Perl 6 support legacy Perl 5 OO code
>
> How? Perl 5 code doesn't use ".", and if Perl 5 code has to be changed
> anyway, why not change it "all the way"?
Because changing:
$foo->{bar_attr}
to:
$foo.{bar_attr}
is a generic, pu
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
On Fri, Apr 12, 2002 at 02:14:36PM -0700, Erik Steven Harrison wrote:
>
> --
>
> On Fri, 12 Apr 2002 18:27:11
> abigail wrote:
> >On Fri, Apr 12, 2002 at 04:42:07PM +0100, Piers Cawley wrote:
> >> [EMAIL PROTECTED] writes:
> >> >
> >> > Why isn't
> >> >
> >> > if %foo {"key"} {print "Hel
On 4/15/02 1:16 AM, Damian Conway wrote:
> More interestingly, it may also be that, by default, the C (i.e.
> hash-look-up) method of a class invokes the accessor of the same name as the
> key, so that:
>
> $foo.bar_attr = 1;
>
> could also be written:
>
> $foo.{bar_attr} = 1;
>
> and still ha
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
Damian Conway <[EMAIL PROTECTED]> writes:
> Yes, subroutine variables *are* like underwear.
> But parameter names *aren't* like underwear.
> Because they're not (primarily) subroutine variables.
>
> So they're like the labels on the knobs, dials, and buttons of your
> favourite elctronic device.
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
On Mon, 15 Apr 2002, Damian Conway wrote:
> More interestingly, it may also be that, by default, the C (i.e.
> hash-look-up) method of a class invokes the accessor of the same name as the
> key, so that:
I'm a tad bit confused on the grounds of classes. Are we allowed to:
%fred = new Flintston
27 matches
Mail list logo
