| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
| |
(specifically references with overloaded stringification)
p4raw-id: //depot/perl@23997
|
|
|
| |
p4raw-id: //depot/perl@23180
|
|
|
| |
p4raw-id: //depot/perl@23176
|
|
|
| |
p4raw-id: //depot/perl@23161
|
|
|
| |
p4raw-id: //depot/perl@22607
|
|
|
|
|
| |
actually work.
p4raw-id: //depot/perl@22605
|
|
|
|
|
| |
Message-ID: <533D273D4014D411AB1D00062938C4D90404682E@hotel.npl.co.uk>
p4raw-id: //depot/perl@22521
|
|
|
| |
p4raw-id: //depot/perl@22509
|
|
|
| |
p4raw-id: //depot/perl@22406
|
|
|
|
|
|
|
|
|
|
| |
Message-ID: <20040221013147.GB6953@pjcj.net>
Rework the OP structure to use less space.
Remove op_seq (and simulate it in dump.c),
replace it by op_opt and op_static,
shrink op_type, remove PL_op_seqmax.
p4raw-id: //depot/perl@22353
|
|
|
|
|
| |
stored in the pad
p4raw-id: //depot/perl@22343
|
|
|
|
|
|
|
| |
Message-Id: <20040217163216.GA6805@ethan>
Make PVLV a superset of PVGV, so that $lvalue = *FOO works
p4raw-id: //depot/perl@22315
|
|
|
| |
p4raw-id: //depot/perl@22294
|
|
|
| |
p4raw-id: //depot/perl@21536
|
|
|
|
|
|
| |
From: "Marcus Holland-Moritz" <mhx-perl@gmx.net>
Message-ID: <006801c34efe$8aac1920$0c2f1fac@R2D2>
p4raw-id: //depot/perl@20224
|
|
|
|
|
| |
Message-ID: <533D273D4014D411AB1D00062938C4D9040465BD@hotel.npl.co.uk>
p4raw-id: //depot/perl@20004
|
|
|
|
|
|
| |
Message-Id: <1051872303.26203.104.camel@supox>
(plus perldiag nit)
p4raw-id: //depot/perl@19505
|
|
|
| |
p4raw-id: //depot/perl@19392
|
|
|
|
|
| |
Message-ID: <20030407100041.A1617@fdgroup.com>
p4raw-id: //depot/perl@19268
|
|
|
|
|
|
|
| |
(Lots of Perl 5 source code archaeology was involved.)
Larry didn't make strangled noises when I showed him
the patch, either :-)
p4raw-id: //depot/perl@19242
|
|
|
|
|
| |
Message-ID: <20030331085549.GB1300@windhund.schwern.org>
p4raw-id: //depot/perl@19098
|
|
|
|
|
| |
Message-ID: <20030329185807.GL274@Bagpuss.unfortu.net>
p4raw-id: //depot/perl@19081
|
|
|
| |
p4raw-id: //depot/perl@18801
|
|
|
|
|
|
| |
Subject: Re: Did the assertion patch/feature submission get overlooked?
Message-ID: <3DE8F439.50402@yahoo.com>
p4raw-id: //depot/perl@18727
|
|
|
|
|
|
| |
threading issue. Should perhaps be a PVOP to save memory, but then
we have nowhere to store the hash of the function!
p4raw-id: //depot/perl@18640
|
|
|
|
|
|
| |
dumping (but now use SvPV_nolen). (This change made an empty
prototype to show up as "_" under -Uuseperlio.)
p4raw-id: //depot/perl@18600
|
|
|
|
|
| |
Message-ID: <20030119172204.D24444@fdgroup.com>
p4raw-id: //depot/perl@18558
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Introduce a cache for UTF-8 data: length and byte<->char offset
mapping are stored in a new type of magic. Speeds up length(),
substr(), index(), rindex(), pos(), and some parts of s///.
The speedup varies a lot (on the usual suspects: what is the
access pattern of the data, compiler, CPU), but should be at
least one order of magnitude, and getting to the same magnitude
as byte string speeds, and in some cases (length on unchanged data)
even reaching the byte string speed. On the other hand, in some
cases (index) the byte speed is still faster by a factor of five
or so, but the bottleneck there does not seem to be any more
the byte<->char offset mapping (instead, the fbm_instr() speed).
There is one cache slot for the length, and only two for the
byte<->char offset mapping (the first one for the start->offset,
and the second for the offset->offset+length, when talking
in substr() terms).
Code this hairy is bound to have hairy trolls hiding under it.
[...]
A small tweak on top of #18353: don't display mg_len bytes of
mg_ptr for PERL_MAGIC_utf8 because that's not what's there.
p4raw-id: //depot/perl@18530
|
|
|
|
|
| |
Message-ID: <20021226211626.GD284@Bagpuss.unfortu.net>
p4raw-id: //depot/perl@18456
|
|
|
|
|
| |
Message-ID: <20021219190021.D9530@fdgroup.com>
p4raw-id: //depot/perl@18410
|
|
|
|
|
| |
Message-ID: <20021219185543.C9530@fdgroup.com>
p4raw-id: //depot/perl@18409
|
|
|
|
|
| |
Message-ID: <20021210012644.A7843@fdgroup.com>
p4raw-id: //depot/perl@18302
|
|
|
|
|
| |
Message-ID: <20021124221906.A25386@fdgroup.com>
p4raw-id: //depot/perl@18220
|
|
|
|
|
|
| |
Subject: [PATCH]
Message-Id: <200211181009.gAIA9pFG034877@vran.herceg.de>
p4raw-id: //depot/perl@18177
|
|
|
|
|
|
| |
character is UTF-8. (Copied from pp_lcfirst.)
2. sv_dump() should display FLAGS=...,UTF8 for both POK and pPOK.
p4raw-id: //depot/perl@18107
|
|
|
|
|
| |
Still imcomplete. Configure will follow
p4raw-id: //depot/perl@18030
|
|
|
|
|
| |
Message-ID: <20020925234023.A20044@fdgroup.com>
p4raw-id: //depot/perl@17953
|
|
|
|
|
| |
Message-ID: <lSCg9gzkgymX092yn@efn.org>
p4raw-id: //depot/perl@17947
|
|
|
|
|
|
| |
Message-id: <3D556FE6.6000404@rowman.com>
plus a bit of cleanup
p4raw-id: //depot/perl@17742
|
|
|
|
|
|
| |
Message-id: <20020815001035.A69079@plum.flirble.org>
specify "-Accflags='-DPERL_COPY_ON_WRITE'" to use
p4raw-id: //depot/perl@17728
|
|
|
|
|
| |
Message-id: <20020806200510.GC31473@ool-18b93024.dyn.optonline.net>
p4raw-id: //depot/perl@17725
|
|
|
|
|
| |
Message-id: <20020805005533.B26111@fdgroup.com>
p4raw-id: //depot/perl@17718
|
|
|
|
|
| |
Message-ID: <Pine.LNX.4.44.0205230959040.3222-100000@lapaki>
p4raw-id: //depot/perl@16754
|
|
|
|
|
| |
Message-ID: <20020513234822.G21318@fdgroup.com>
p4raw-id: //depot/perl@16586
|
|
|
| |
p4raw-id: //depot/perl@16156
|
|
|
|
|
|
| |
SvREFCNT_dec(x ? y : z) did not typecast the right thing due to
missing parens in macro definition
p4raw-id: //depot/perl@16055
|
|
|
|
|
|
| |
change is from change#12026)
p4raw-link: @12026 on //depot/maint-5.6/perl: ff42b73b40f5a895aef4bed81c794f468e0609bc
p4raw-id: //depot/perl@16048
|
|
|
|
|
| |
Message-ID: <20020413015806.GA371@Bagpuss.unfortu.net>
p4raw-id: //depot/perl@15893
|
|
|
|
|
|
|
| |
Message-ID: <20020405232117.GE323@Bagpuss.unfortu.net>
(with the last one reversed)
p4raw-id: //depot/perl@15757
|
|
|
|
|
|
|
|
|
|
| |
If the bit is on, when the keys are fetched from the hash
(%h, each %h, keys %h), the Unicodified versions of the keys
are returned if needed. This solution errs on the size of
over-Unicodifying, the old solution erred on the side of
under-Unicodifying. As long as the hash keys can be a mix
of byte and Unicode strings, a perfect fit is hard to come by.
p4raw-id: //depot/perl@15407
|