In perl.git, the branch smoke-me/khw-smoke has been created

<http://perl5.git.perl.org/perl.git/commitdiff/9de20b3442ed479d04b299633a3b9e6fbd303fa9?hp=0000000000000000000000000000000000000000>

        at  9de20b3442ed479d04b299633a3b9e6fbd303fa9 (commit)

- Log -----------------------------------------------------------------
commit 9de20b3442ed479d04b299633a3b9e6fbd303fa9
Author: Karl Williamson <[email protected]>
Date:   Tue Dec 27 21:25:39 2016 -0700

    toke.c: Clarify comment

M       toke.c

commit 5f9501e82813ff6bdfa26f96b1c5b05707470826
Author: Karl Williamson <[email protected]>
Date:   Tue Dec 27 21:15:43 2016 -0700

    toke.c: Keep better track for avoiding work in tr///
    
    As explained in the comments, tr/// creates byte map tables for bytes
    0-255 if everything is below 256.  If something is higher than that,
    special handling is required (currently a swash), and so there is no
    point in creating the tables here by expanding each range.  Prior to
    this commit, it realized this on a per-range basis, not expanding ranges
    which extend above 255.  This commit changes that so if any time it
    finds something above 255, it remembers that and skips the expansion of
    all future ranges encountered.
    
    This was done without adding any extra tests outside the specific tr///
    code.

M       toke.c

commit 0f65d062a55f567e39c7922d8395d73a8ccac14d
Author: Karl Williamson <[email protected]>
Date:   Tue Dec 27 21:20:13 2016 -0700

    toke.c: Fix comment that said the opposite of what was meant

M       toke.c

commit 32e6344ef57eef9ce1ac2a69f341638150b9bc5e
Author: Karl Williamson <[email protected]>
Date:   Tue Dec 27 20:55:13 2016 -0700

    toke.c: Simplify expression
    
    Unless there's a reason its needed, I prefer not to set a variable
    within an 'if', as it increases the reader's cognitive load.

M       toke.c

commit 1c78a5ea7bf12478b6d24c5f0cbf88e30ae5d40a
Author: Karl Williamson <[email protected]>
Date:   Tue Dec 27 20:52:20 2016 -0700

    SV_UTF8_NO_ENCODING is no longer used
    
    It once had meaning under 'use encoding';

M       sv.h
M       toke.c

commit 3c6c5690f32d945f81190377460f5a39cb416048
Author: Karl Williamson <[email protected]>
Date:   Thu Aug 18 21:41:08 2016 -0600

    toke.c: White-space only
    
    Indent after previous commit added new blocks, and a couple other white
    space adjustments

M       toke.c

commit 3d370ac9cd769f8c6ce636826b91a12a3c8efe32
Author: Karl Williamson <[email protected]>
Date:   Thu Aug 18 18:54:13 2016 -0600

    toke.c: Potentially avoid work when converting to UTF-8
    
    Some code points < 256 are the same whether represented in UTF-8, or
    not.  Others change to require 2 bytes to represent in UTF-8.  When
    parsing a string, using UTF-8 is avoided unless necessary, because of
    the extra overhead required for processing UTF-8.  This means that when,
    during the parse, we discover we need to convert to UTF-8, we have to,
    in effect, reparse whatever we have so far to make sure those code
    points that differ under UTF-8 get their proper representation.  This
    reparsing would not be necessary if we know that the string doesn't have
    such code points.
    
    It turns out that keeping track of having seen UTF-8 variant code points
    is cheap, requiring no extra branch instructions.  And the payoff is
    potentially large, avoiding having to reparse the string.  This commit
    changes to keep track.

M       toke.c

commit c724c38151b2cef7ded42e2266734b1f33148017
Author: Karl Williamson <[email protected]>
Date:   Sun Dec 25 21:53:04 2016 -0700

    toke.c: Reorder if/else branches
    
    It is easier to read code if the trivial branch is follows immediately
    after the 'if'.

M       toke.c

commit 00fc48edba05a5d0af525b50c49a72cea8d0b48b
Author: Karl Williamson <[email protected]>
Date:   Tue Dec 27 19:37:33 2016 -0700

    toke.c: Fix too-small SvGROW()
    
    This might be a bug on EBCDIC, but not ASCII platforms.  The code forgot
    that SvGROW takes a total size, and not an incremental size.  So, this
    is most likely a no-op, but I believe there are no cases on ASCII
    platforms where this actually needs to grow, and on EBCDIC, it would
    only be very large, way above Unicode, code points.  Grows in later
    iterations of the loop would recover to grow to the correct size, unless
    this EBCDIC escape sequence was the final thing there.

M       toke.c

commit 6ab088a0bca8c1e493f5e45fb5bff06df47595d9
Author: Karl Williamson <[email protected]>
Date:   Tue Dec 27 19:20:08 2016 -0700

    toke.c: Simplify a couple of expressions
    
    By storing an intermediate result in a temporary, the final expression
    is clearer.

M       toke.c

commit d7fd2726a15214d5d865a61437d476ff12e53704
Author: Karl Williamson <[email protected]>
Date:   Tue Dec 27 19:45:07 2016 -0700

    toke.c: Convert sv_grow to SvGROW
    
    The latter is preferred

M       toke.c
-----------------------------------------------------------------------

--
Perl5 Master Repository

Reply via email to