| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
| |
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
|
|
|
|
|
|
| |
From: "Paul Marquess" <paul_marquess@yahoo.co.uk>
Message-ID: <AIEAJICLCBDNAAOLLOKLMEEGDPAA.paul_marquess@yahoo.co.uk>
p4raw-id: //depot/perl@15155
|
|
|
|
|
| |
Message-Id: <200203090013.AAA01000@gizmo.fdgroup.co.uk>
p4raw-id: //depot/perl@15127
|
|
|
|
|
|
| |
Message-Id: <20020302054958.A5511@math.ohio-state.edu>
p4raw-link: @14577 on //depot/perl: 0ad5258ff3f3328f321188cbb4fcd6a74b365431
p4raw-id: //depot/perl@14956
|
|
|
| |
p4raw-id: //depot/perl@14391
|
|
|
| |
p4raw-id: //depot/perl@14114
|
|
|
|
|
|
| |
findings -- some of the warnings I can't explain except
by NVgf being detected wrong, though.
p4raw-id: //depot/perl@13764
|
|
|
|
|
| |
Message-Id: <200112090509.AAA02053@Orb.Nashua.NH.US>
p4raw-id: //depot/perl@13543
|
|
|
|
|
| |
are used under normal operation (S_not_a_number()).
p4raw-id: //depot/perl@13099
|
|
|
|
|
| |
Message-ID: <20011116004809.A934@math.ohio-state.edu>
p4raw-id: //depot/perl@13044
|
|
|
|
|
| |
reimplement sv_uni_display() using that.
p4raw-id: //depot/perl@12619
|
|
|
|
|
| |
do it if wanted, and be prepared for more display options.
p4raw-id: //depot/perl@12612
|
|
|
|
|
| |
Message-Id: <011019174427.d749b@DUPHY4.Physics.Drexel.Edu>
p4raw-id: //depot/perl@12513
|
|
|
| |
p4raw-id: //depot/perl@12341
|
|
|
|
|
| |
not just as a byte string.
p4raw-id: //depot/perl@12246
|
|
|
|
|
| |
TODO: dump the SvUTF8() hash keys similarly.
p4raw-id: //depot/perl@12243
|
|
|
| |
p4raw-id: //depot/perl@12127
|
|
|
|
|
|
| |
Thanks to H. Merijn Brand for the patch.
Some of the comments and or guards might be removable in perl.h now.
p4raw-id: //depot/perl@11758
|
|
|
|
|
|
| |
Message-ID: <20010825174509.A5752@netthink.co.uk>
I also added a fix to Opcode.pm to quite test cases.
p4raw-id: //depot/perl@11756
|
|
|
| |
p4raw-id: //depot/perl@11716
|
|
|
| |
p4raw-id: //depot/perl@11713
|
|
|
|
|
|
|
| |
Message-ID: <20010712041411.A3467@pjcj.net>
(With prototyping and multiplicity tweaks.)
p4raw-id: //depot/perl@11305
|
|
|
| |
p4raw-id: //depot/perl@11285
|