> I was beating my head on the wall yesterday trying to figure out why
> an intlist test was failing on a freshly updated source tree. (I
> rarely use 'make clean', because that's almost always just covering up
> dependency problems.) I'll leave out the gory details, but the problem
> boiled down
Recently I presented a Perl 6 overview talk at a Java conference. The
audience was mostly mute, which is unfortunate as I wanted to hear some
feedback or at least some groans of pain, but there was one Lisp programmer
in the front row that asked some interesting questions.
One was "Perl 6 suppor
I was beating my head on the wall yesterday trying to figure out why
an intlist test was failing on a freshly updated source tree. (I
rarely use 'make clean', because that's almost always just covering up
dependency problems.) I'll leave out the gory details, but the problem
boiled down to parrot/
Paul Johnson wrote:
> On Sat, Sep 21, 2002 at 10:05:50AM -, Smylers wrote:
>
> > Many Perl programs use C<$_> to mean
> > 'the current line'. 'A2' gives the Perl 6 syntax for this as:
> >
> >while $STDIN {
> >
> > Maybe somewhere in the middle of
> > it, it's necessary to have a C loo
Luke Palmer wrote:
> On 21 Sep 2002, Smylers wrote:
>
> > But because C<$num> _might_ be used as an array ref, the data has to
> > be kept around, which is wasteful.
>
> The programmer should know whether it would or wouldn't,
Oh, I wasn't doubting that. I was just concerned that if the 'typi
Aaron Sherman wrote:
> On Sat, 2002-09-21 at 06:38, Smylers wrote:
>
> > ... lists now use square brackets.
>
> I don't disagree that this is a good thing, but let's look at some
> cases that might not look the way you had intended:
Oh, I hadn't really intending anything. Starting from what
Mike Lambert wrote:
> http:[EMAIL PROTECTED]/msg11553.html
Thanks for this. I must have missed some parts of this discussion on the
list. Aligning the header pools could be an interesting approach, since
now a considerable amount of time is spent to determine if a pointer on
the sysem stack
> >>First and foremost, is there any compelling reason, to have totally
> >>different structures for PMCs and Buffers?
> >>- Both have a ->data aka ->bufstart
> >>- Both have ->flags, that have vastly the same meaning.
> >>
> >
> > As jason said in another message, Dan has changed his mind from
>
Mike Lambert wrote:
[ Unifying Buffer and PMC ]
> As jason said in another message, Dan has changed his mind from
> yesteryear, and decided that buffers and pmcs should be the same
> structure.
Roadmap
---
1) Hide Buffer and PMC internals, namely
- buflen
- bufstart
- flags
