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
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 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 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
> [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) {
...
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
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
> "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
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
>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
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
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".
__
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
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
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
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
# 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
# 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
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<
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: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
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
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.
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 \(
24 matches
Mail list logo
