FAQ
Hi!

Here are two patches that will fix this user request.
I hope they look fine. Btw, they are for php5 HEAD.

I don't have any karma so I can't commit them even if they look
good. So I will leave that to someone else..



/Magnus


--
War is much too serious a matter to be entrusted to the military.
-- Clemenceau

Search Discussions

  • Moriyoshi Koizumi at Mar 30, 2003 at 4:22 pm
    Where's the patch? It seems your sylpheed doesn't correctly send the
    attachment as text/plain. Try suffixing it with ".txt"..

    Moriyoshi

    Magnus Maatta wrote:
    Hi!

    Here are two patches that will fix this user request.
    I hope they look fine. Btw, they are for php5 HEAD.

    I don't have any karma so I can't commit them even if they look
    good. So I will leave that to someone else..



    /Magnus


    --
    War is much too serious a matter to be entrusted to the military.
    -- Clemenceau
  • Magnus Maatta at Mar 30, 2003 at 4:32 pm

    On Mon, 31 Mar 2003 01:25:43 +0900 Moriyoshi Koizumi wrote:

    Where's the patch? It seems your sylpheed doesn't correctly send the
    attachment as text/plain. Try suffixing it with ".txt"..
    hmm.. heh.. ok.. They should come now then.. And remember that it's my
    first patches (ZE2 patch is 90% Marcus btw), so don't be to hard on me =D


    /Magnus




    --
    Stock's Observation:
    You no sooner get your head above water but what someone pulls
    your flippers off.
  • Magnus Maatta at Mar 30, 2003 at 4:36 pm

    On Sun, 30 Mar 2003 18:32:21 +0200 Magnus Maatta wrote:

    On Mon, 31 Mar 2003 01:25:43 +0900
    Moriyoshi Koizumi wrote:
    Where's the patch? It seems your sylpheed doesn't correctly send the
    attachment as text/plain. Try suffixing it with ".txt"..
    hmm.. heh.. ok.. They should come now then.. And remember that it's my
    first patches (ZE2 patch is 90% Marcus btw), so don't be to hard on me =D
    Argh.. Let me put them on URL instead..

    http://novell.stoldgods.nu/~magnus/12192.diff
    http://novell.stoldgods.nu/~magnus/ieicf.diff

    /Magnus




    --
    Stock's Observation:
    You no sooner get your head above water but what someone pulls
    your flippers off.

    --
    "The Amiga is the only personal computer where you can run a multitasking
    operating system and get realtime performance, out of the box."
    -- Peter da Silva
  • Andrei Zmievski at Mar 30, 2003 at 4:47 pm

    On Sun, 30 Mar 2003, Magnus Maatta wrote:
    hmm.. heh.. ok.. They should come now then.. And remember that it's my
    first patches (ZE2 patch is 90% Marcus btw), so don't be to hard on me =D
    Argh.. Let me put them on URL instead..

    http://novell.stoldgods.nu/~magnus/12192.diff
    http://novell.stoldgods.nu/~magnus/ieicf.diff
    I'd rather not keep extending in_array() with more and more parameters.
    I must have missed it, but why do we need a case-insensitive version of
    it in the first place?

    -Andrei http://www.gravitonic.com/

    "The day Microsoft makes something that doesn't suck,
    is probably the day Microsoft starts making vacuum cleaners."
    - Ernst Jan Plugge
  • Magnus Maatta at Mar 30, 2003 at 4:52 pm

    On Sun, 30 Mar 2003 11:46:41 -0500 Andrei Zmievski wrote:
    On Sun, 30 Mar 2003, Magnus Maatta wrote:
    hmm.. heh.. ok.. They should come now then.. And remember that it's my
    first patches (ZE2 patch is 90% Marcus btw), so don't be to hard on me =D
    Argh.. Let me put them on URL instead..

    http://novell.stoldgods.nu/~magnus/12192.diff
    http://novell.stoldgods.nu/~magnus/ieicf.diff
    I'd rather not keep extending in_array() with more and more parameters.
    I must have missed it, but why do we need a case-insensitive version of
    it in the first place?
    Well, I don't really need it atm. But someone requested it and I wrote a patch
    for it. Mostly just to learn this =)

    But if people don't want case insensive in_array I will mark the bug as "Won't fix".

    / Magnus


    --
    Don't despair; your ideal lover is waiting for you around the corner.
  • Mike Robinson at Mar 30, 2003 at 6:20 pm

    Andrei Zmievski wrote:

    I'd rather not keep extending in_array() with more and more
    parameters. I must have missed it, but why do we need a
    case-insensitive version of it in the first place?
    ATM, in_array() takes 2 args and 1 parameter. Adding 1 more
    wouldn't hurt, doesn't break BC, and provides some added
    usefulness. IMHO, this would be a handy feature, and if it
    were added I can't imagine having to extend in_array any
    further. Does 'please' help? :)

    --Mike
  • Andrei Zmievski at Mar 30, 2003 at 6:24 pm

    On Sun, 30 Mar 2003, Mike Robinson wrote:
    ATM, in_array() takes 2 args and 1 parameter. Adding 1 more
    wouldn't hurt, doesn't break BC, and provides some added
    usefulness.
    And slows down the inner loop of searching.
    IMHO, this would be a handy feature, and if it
    were added I can't imagine having to extend in_array any
    further. Does 'please' help? :)
    Can't imagine? Look in the archives. One of the proposals included
    having an option to tell in_array() to move the internal array pointer
    to the found element.

    -Andrei http://www.gravitonic.com/

    Give a man a fish; you have fed him for today. Teach a man to fish;
    and you can sell him fishing equipment.
    -Author unknown
  • Marcus Börger at Mar 30, 2003 at 6:37 pm

    At 20:24 30.03.2003, Andrei Zmievski wrote:
    On Sun, 30 Mar 2003, Mike Robinson wrote:
    ATM, in_array() takes 2 args and 1 parameter. Adding 1 more
    wouldn't hurt, doesn't break BC, and provides some added
    usefulness.
    And slows down the inner loop of searching.
    If thats the only problem the patch can be rewritten to have only
    one additional assembler operation (or was it three to get an address?)
    for the inner loop (indeed i would suggest so).
    IMHO, this would be a handy feature, and if it
    were added I can't imagine having to extend in_array any
    further. Does 'please' help? :)
    Can't imagine? Look in the archives. One of the proposals included
    having an option to tell in_array() to move the internal array pointer
    to the found element.
    this is the real problem...and to add another one: why not supply
    a user defined compare function (not that it makes sense really).

    marcus
  • Mike Robinson at Mar 30, 2003 at 7:06 pm

    Andrei Zmievski wrote:
    On Sun, 30 Mar 2003, Mike Robinson wrote:
    ATM, in_array() takes 2 args and 1 parameter. Adding 1 more
    wouldn't hurt, doesn't break BC, and provides some added
    usefulness.
    And slows down the inner loop of searching.
    Indeed, but it's always a point of contention; the tradeoffs
    between performance and feature set. Seems to me that in_array()
    no matter was is going to be a bit of a performance hound, so
    adding some usefulness isn't going to be that much of a headache.
    But if in your opinion the tradeoff is too profound leave it
    out, by all means. My point was that of usefulness. I'll leave
    the weighting against performance of such to the experts.
    Can't imagine? Look in the archives. One of the proposals included
    having an option to tell in_array() to move the internal array pointer
    to the found element.
    Yeah, things like that are bound to happen, but you can dismiss
    them as you see fit as I trust your judgment on stuff like that.
    Just didn't want you to dismiss this particular proposal without
    someone saying the case-sensitivity addition would be useful,
    because it would be.

    Best Regards
    Mike Robinson
  • Magnus Maatta at Mar 30, 2003 at 8:12 pm

    On Sun, 30 Mar 2003 14:06:29 -0500 "Mike Robinson" wrote:

    Andrei Zmievski wrote:
    On Sun, 30 Mar 2003, Mike Robinson wrote:
    ATM, in_array() takes 2 args and 1 parameter. Adding 1 more
    wouldn't hurt, doesn't break BC, and provides some added
    usefulness.
    And slows down the inner loop of searching.
    Indeed, but it's always a point of contention; the tradeoffs
    between performance and feature set. Seems to me that in_array()
    no matter was is going to be a bit of a performance hound, so
    adding some usefulness isn't going to be that much of a headache.
    But if in your opinion the tradeoff is too profound leave it
    out, by all means. My point was that of usefulness. I'll leave
    the weighting against performance of such to the experts.
    I had to make a test with and without any of my patches..

    novell TESTS # ./performance_test.php
    Test took: 20.615808010101 seconds
    novell TESTS # ./performance_test.php
    Test took: 20.806298971176 seconds
    novell TESTS # uptime
    22:07:58 up 7:24, 1 user, load average: 1.19, 1.05, 1.08


    First run is with patches, and second one without patches.

    The script is:

    #!/tmp/php5test/bin/php
    <?php
    function getmicrotime()
    {
    list($usec, $sec) = explode(" ",microtime());
    return ((float)$usec + (float)$sec);
    }

    $time_start = getmicrotime();

    $array = array(1 => "test", 2 => "temp", 3 => "typo", 4 => "magnus", 5 => "loss", 6 => "luser", 7 => "is", 8 => "sending", 9 => "me", 10 => "wedding", 11 => "pics", 12 => "throu", 13 => "IRC", 14 => "performance", 15 => "loss", 16 => "must", 17 => "check", 18 => "if", 19 => "its", 20 => "bad");

    for ($x = 0; $x < 500000; $x++) {
    in_array("doesnt_exist", $array);
    }

    $time_end = getmicrotime();
    $time = $time_end - $time_start;

    echo "Test took: $time seconds\n";
    ?>

    PHP was compiled with: ./configure --disable-all --enable-cli --disable-cgi --with-pcre-regex --prefix=/tmp/php5test


    As I understand, the concern of performance loss would be that it would need to check more stuff in the loops before it could proceed.


    /Magnus


    --
    To do two things at once is to do neither.
    -- Publilius Syrus
  • Magnus Maatta at Mar 30, 2003 at 8:35 pm

    On Sun, 30 Mar 2003 22:12:22 +0200 Magnus Maatta wrote:

    On Sun, 30 Mar 2003 14:06:29 -0500
    "Mike Robinson" wrote:
    Andrei Zmievski wrote:
    On Sun, 30 Mar 2003, Mike Robinson wrote:
    ATM, in_array() takes 2 args and 1 parameter. Adding 1 more
    wouldn't hurt, doesn't break BC, and provides some added
    usefulness.
    And slows down the inner loop of searching.
    Indeed, but it's always a point of contention; the tradeoffs
    between performance and feature set. Seems to me that in_array()
    no matter was is going to be a bit of a performance hound, so
    adding some usefulness isn't going to be that much of a headache.
    But if in your opinion the tradeoff is too profound leave it
    out, by all means. My point was that of usefulness. I'll leave
    the weighting against performance of such to the experts.

    Andrei: -1
    Ilia: -1
    Derick: -1
    Georg: -1
    Marcus: +0
    Moriyoshi: -1
    ====================
    Total: -5

    So I marked it: Won't Fix

    Good experience thou =)


    /Magnus

    --
    The trouble with computers is that they do what you tell them, not what
    you want.
    -- D. Cohen
  • Steph at Mar 31, 2003 at 2:25 am

    Andrei: -1
    Ilia: -1
    Derick: -1
    Georg: -1
    Marcus: +0
    Moriyoshi: -1
    ====================
    Total: -5

    So I marked it: Won't Fix

    Good experience thou =)


    /Magnus
    Hrm, and next time I'll leave it til I've read to the end of the thread
    before I comment :-I
  • Steph at Mar 31, 2003 at 2:18 am

    ATM, in_array() takes 2 args and 1 parameter. Adding 1 more
    wouldn't hurt, doesn't break BC, and provides some added
    usefulness.
    And slows down the inner loop of searching.
    IMHO, this would be a handy feature, and if it
    were added I can't imagine having to extend in_array any
    further. Does 'please' help? :)
    Can't imagine? Look in the archives. One of the proposals included
    having an option to tell in_array() to move the internal array pointer
    to the found element.
    Is that even slower than that long moment when you need to manually
    create an array with the correct casing, strip filepaths, and then do a
    case-insensitive string comparison?
  • George Schlossnagle at Mar 30, 2003 at 4:46 pm
    Still no patch.
    On Sunday, March 30, 2003, at 11:32 AM, Magnus Maatta wrote:

    On Mon, 31 Mar 2003 01:25:43 +0900
    Moriyoshi Koizumi wrote:
    Where's the patch? It seems your sylpheed doesn't correctly send the
    attachment as text/plain. Try suffixing it with ".txt"..
    hmm.. heh.. ok.. They should come now then.. And remember that it's my
    first patches (ZE2 patch is 90% Marcus btw), so don't be to hard on me
    =D


    /Magnus




    --
    Stock's Observation:
    You no sooner get your head above water but what someone pulls
    your flippers off.

    --
    PHP Internals - PHP Runtime Development Mailing List
    To unsubscribe, visit: http://www.php.net/unsub.php

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupphp-internals @
categoriesphp
postedMar 30, '03 at 4:20p
activeMar 31, '03 at 2:25a
posts15
users7
websitephp.net

People

Translate

site design / logo © 2022 Grokbase