Jonathan Scott Duff wrote:
>>Because what you do with a hypothetical has to be reversible.
>
> I thought it was just the hypothetical's existence that has to be
> reversible.
That's not my understanding. You need to be able to cope with this too:
rule alias :w { \$ $name:= [is named \(
Peter Behroozi wrote:
>> sub hidden (str $name, int $force is aka($override)) {...}
>
>
> Hang on a moment! In your original answer to this question, you used
> the "is named('alias')" syntax, but now you are suggesting using the
> sigil in the syntax.
Yes, but for a *different* property.
On Jeudi 5 Septembre 2002 17:08, Dan Sugalski wrote :
> At 3:04 PM + 9/5/02, Leon Brocard (via RT) wrote:
> >I realise that proper Unicode support is coming, but it may be a while
> >to get here. We currently have ord() and it makes sense to have a
> >chr() as well, so that's what my patch pro
On Dimanche 8 Septembre 2002 11:28, Jerome Quelin wrote :
> In fact, I tried to change S0, and whatever S0 value is (I tried with
> several values: "<", ">", "A", "0", " "), I always get a 60 as its ordinal
> value...
I forgot to tell you: it doesn't work when I try to change S0 from the test
se
Jerome Quelinm wrote:
> > In fact, I tried to change S0, and whatever S0 value is (I tried with
> > several values: "<", ">", "A", "0", " "), I always get a 60 as its
ordinal
> > value...
>
> I forgot to tell you: it doesn't work when I try to change S0 from the
test
> set. But when I try to put a
On Dimanche 8 Septembre 2002 11:50, Peter Gibbs wrote :
> This looks like a COW bug. Try the attached patch (untested).
In fact, here's the minimal test case:
$ cat p.pasm <"
print I10
print "<\n"
end
EOF
$ perl ../../assemble.pl p.pasm >P.pbc
$ ../../parrot P.pbc
>v<
>97<
# New Ticket Created by Peter Gibbs
# Please include the string: [perl #17071]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=17071 >
Attached patch fixes a problem with ord reported by Jerome Quelin.
It also includes a te
Damian Conway wrote:
> Though leaving optimization in the hands of the programmer
> is generally a Bad Idea.
That doesn't sound like a Perl slogan.
> It's also a matter of syntactic consistency. It has to be := for
> "inlined" bindings (i.e. rx/ $name:= /) because otherwise
> we make = meta (whi
At 6:59 AM + 9/7/02, Damian Conway wrote:
>Jonathan Scott Duff wrote:
>>Sounds like an optimization that should be in the hands of the
>>programmer to me.
>
>Possibly. Though leaving optimization in the hands of the programmer
>is generally a Bad Idea.
Oh, I dunno... If that programmer is me
Some regexpes will be longer, but a lot will benefit from the changes, by being
shorter or clearer, or often, both. The problem with your suggestion is you're
making assumeptions about what's common and what's not (character classes more
common than closures, for instance) that probably aren't ac
Aaron Sherman wrote:
> sub chomp($string is rw){
> my $irs = ${"/"}; # XXX What is $/ now?
> if defined $irs {
> if $irs.isa(Object) {
> return undef;
> } elsif $irs.length == 0 {
> $string =~ s/ \n+ $ //;
Should
Would it be accurate to say that "is" sets properties of variables, whereas
"but" sets properties of values? If so, what would this output:
my $var is true;
$var=0;
if ($var) {print "true"}
else {print "false"}
I would expect it to output "false".
__
In a message dated Sun, 8 Sep 2002, Steve Canfield writes:
> Would it be accurate to say that "is" sets properties of variables, whereas
> "but" sets properties of values? If so, what would this output:
>
> my $var is true;
> $var=0;
> if ($var) {print "true"}
> else {print "false"}
>
> I
>From: Trey Harris <[EMAIL PROTECTED]>
>To: Steve Canfield <[EMAIL PROTECTED]>
> > I would expect it to output "false".
>
>Why? I believe that, whatever you set $var to, you have marked the
>variable as constantly true in booleans.
Because in my experience variables are not true or false. They
I realise that it's almost 2 years since the RFC deadline, plus we're
several apocolypses past the appropriate Camel chapters.
IIRC there are 5 different variants of m//
normal /g
scalar context: match from startcontinue progressive match
> "SC" == Steve Canfield <[EMAIL PROTECTED]> writes:
SC> Would it be accurate to say that "is" sets properties of variables,
SC> whereas "but" sets properties of values? If so, what would this output:
SC> my $var is true;
that is not a variable property so it should be a compile tim
> [run time control of assignment behavior when array contains pairs]
How much have I misunderstood things from a mechanisms
available point of view (as against a practical / nice way to
do things) when I suggest something along the lines of:
my sub op:= (*@list : %adverbs) {
...
On Thu, Sep 05, 2002 at 07:46:38PM -0400, John Porter wrote:
> Steve Fink wrote:
> > Here is the new PMC I keep babbling about. Before I commit it, any
> > comments? Like, does anybody think this should be named differently?
> > It's really a dequeue (double-ended queue), ...
>
> I for one think
On Sun, Sep 08, 2002 at 11:50:10AM +0200, Peter Gibbs wrote:
> Jerome Quelinm wrote:
> > > In fact, I tried to change S0, and whatever S0 value is (I tried with
> > > several values: "<", ">", "A", "0", " "), I always get a 60 as its
> ordinal
> > > value...
> >
> > I forgot to tell you: it doesn'
On Sun, Sep 08, 2002 at 10:35:16AM +, Peter Gibbs wrote:
>
> Attached patch fixes a problem with ord reported by Jerome Quelin.
> It also includes a test case in string.t.
Oops, I thought this patch was for something else. Oh well, I've
applied the fix already, with an equivalent test case, s
On Sat, Sep 07, 2002 at 09:17:38AM +, Peter Gibbs wrote:
>
> Mike's changes to integrate the external and selfpoolptr flags
> have resulted in the on_free_list flag remaining set when a
> buffer header is reallocated.
>
> This breaks life, so I have had to fix it to be able to compare
> tim
# New Ticket Created by Jerome Quelin
# Please include the string: [perl #17072]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=17072 >
I just rsync-ed my parrot.
$ perl Configure.pl
[...]
$ make
[...]
string.c: In functi
if I knew, what exactly to ask, it where easier.
I'm implementing a parrot interpreter in immc. I seem to have memory
corruptions or unreproducible errors. E.g. moving the stacktop variable
only slightly gives different test results, as well as results on a
second machine differ. Blocking
from perl5-porters:
On Sun, Sep 08, 2002 at 09:47:24PM +0200, Rafael Garcia-Suarez wrote:
> Nicholas Clark wrote:
> > Are we going to assimilate what parrot is doing in all its C files -
> >
> > /*
> > * Local variables:
> > * c-indentation-style: bsd
> > * c-basic-offset: 4
> > * indent-ta
24 matches
Mail list logo
