- Original Message -
From: "Dan Sugalski" <[EMAIL PROTECTED]>
> Actually, we don't. (Sez the man catching up on altogether too much
> mail) Since we're putting the COW stuff at the tail end, substrings
> of COW strings are fine. You set the bufstart to where the substring
> starts, buflen
> Ok, now I understand the plan. In brief, in the following example $result
> is scoped to the block that encloses the whole loop:
>
>while (my $res = $search->getnext) { ...}
Yes. Because it's a lexical variable declared outside the closure controlled
by the C.
> However, in the next exa
Aaron Sherman wrote:
> > What if I want my methods to be called C<.get_bar()> and C<.set_bar()>,
> > since a certain Perl OO specialist suggests this approach is best for
> > avoiding ambiguity in one's API?
>
> Then you can declare them as such:
>
> sub get_bar() { .bar }
> sub get_baz
> while getNextValue() -> $i {
> ...
> }
>
> while getOtherNextValue() -> $i {
> ...
> }
>
> which generates no warning because each C<$i> is a parameter of the
> corresponding loop block, and hence scoped to that block.
Ok, now I understand the plan. In brief, in the following example $result
i
$ 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/op/integerok
t/op/interp.ok
t/op/macro..ok, 1/9 subtest skipped
t/op/number.# Failed test (t/op/number.t at li
At 10:58 AM +0200 5/6/02, Peter Gibbs wrote:
>The COWing of substrings requires a major interface change:
>*** All references to the data in a STRING must use the new strstart pointer
>instead of bufstart ***
Actually, we don't. (Sez the man catching up on altogether too much
mail) Since we're p
At 8:44 PM -0700 5/6/02, Mark Kvale wrote:
>
>Hi all,
>
>One of the upcoming decisions that needs to be made is on the design
>of the Parrot regex engine. More specifically, (1) how will compiled
>regexes be represented and (2) how will strings be matched against
>compiled regexes?
As I come in l
Anyone care to take this task on? It doesn't have to be at all fancy.
In fact, all it needs to do is handle:
*) Label offset calcs
*) Explicit, fully-qualified, opcode names
*) Opcode args as either labels or numbers
So we'd only pass it:
foo: sub_i_i_ic 1, 2, 5
ge_i_ic
Okay, I'm working on redoing the vtable docs, since they're both
deficient and decaying. A question came up a while back about what to
do with P1 in an opcode such as:
add P1, P2, P3
And the answer is that opcode function looks like:
p1->vtable->assign_pmc(p1, p2->vtable->add_pm
On Thu, 2002-05-09 at 12:37, David Wheeler wrote:
> On 5/8/02 1:24 PM, "Damian Conway" <[EMAIL PROTECTED]> claimed:
>
> > Yes.
> >
> > If you write:
> >
> > class Foo {
> > my $.bar;
> > my $.baz is public;
> > ...
> > }
> >
> > you get a private C<.bar()> accessor and a public C<.baz> access
On Thu, 2002-05-09 at 13:22, David Whipp wrote:
> Aaron Sherman [mailto:[EMAIL PROTECTED]] wrote:
> > what about
> > >
> > > while (do_something_with_side_effects_and_check_still_ok()) {
> > >
> > > I presume we don't want to do look-ahead here.
> >
> > Yes, I think he was saying exactly
Miko O'Sullivan wrote:
> Just checking here: is PRE_LAST a separate and non-mutually exclusive
> concept from LAST? I.e., would this make sense:
>
>foreach @arr -> $i {
> PRE_LAST {print "before last loop\n"}
> LAST {print "after last loop\n"}
> print "$i\n";
>}
>
> If
> The implication is that we can only provide advanced "PRE_LAST"
> style blocks (or their equiv.) on the C loop. The fact
> that they are impossible on the C loop should not
> constrain our thinking for the C loop.
Just checking here: is PRE_LAST a separate and non-mutually exclusive
concept fro
Aaron Sherman [mailto:[EMAIL PROTECTED]] wrote:
> what about
> >
> > while (do_something_with_side_effects_and_check_still_ok()) {
> >
> > I presume we don't want to do look-ahead here.
>
> Yes, I think he was saying exactly that we will do look-ahead
> here. "we don't guarantee order of
14 matches
Mail list logo
