[PHP-DEV] bug #49510

[Stas Malyshev]

Hi!

We've got a bit of a discussion on bug #49510 in the comments. The
problem is this: filter_var('', FILTER_VALIDATE_BOOLEAN, array("flags"
=> FILTER_NULL_ON_FAILURE)) returns "null" (i.e. failure) while docs say
boolean filter will return false on ''. I think we need to sync with the
docs.
The question is - should we apply it to 5.3/5.4? It is a behavior
change, even though current code behavior does not match documented
behavior.

-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227


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

[PHP-DEV] qa.php.net pulls screen does not display all the pulls

[Stas Malyshev]

Hi!

When I go to qa.php.net to see pulls for php-src, I only see pulls down
to number 56, but earlier ones are not displayed for some reason. Does
anybody know what's wrong with it and could fix it?

Thanks,
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227


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

Re: Re: [PHP-DEV] 6.0 And Moving Forward

[Morgan L. Owens]

On 2012-07-14 04:12, jpauli wrote:

On Fri, Jul 13, 2012 at 5:33 PM, Anthony Ferrara  wrote:


4. Rewrite the entire parser completely. I keep hearing about how bad PHP's
parser is, and how it's growing out of control. Perhaps this is a good time
to rewrite it (perhaps changing semantics slightly) to be better adapted
towards future changes...


We have an RFC and a patch playing with lemon parser. Actually, just a
conversion, reentrant.
Refer to Pierrick or Felipe about it :-)

Will the conversion include writing a formal definition of the language 
from the perspective of someone planning to write a PHP parser? Right 
now the only way to get such a definition is to reverse-engineer the 
Bison source.



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

[PHP-DEV] installing from source on mac osx 10.7.3

[Yader Hernandez]

I can't seem to get a vanilla php binary from a simple

$ ./configure
make
make install

The last few lines indicate that everything went well:

Installing PHP SAPI module:   cgi
Installing PHP CGI binary: /usr/local/bin/
*Installing PHP CLI binary:/usr/local/bin/*
Installing PHP CLI man page:  /usr/local/man/man1/
Installing build environment: /usr/local/lib/php/build/
Installing header files:  /usr/local/include/php/
Installing helper programs:   /usr/local/bin/
  program: phpize
  program: php-config
Installing man pages: /usr/local/man/man1/
  page: phpize.1
  page: php-config.1
Installing PEAR environment:  /usr/local/lib/php/
[PEAR] Archive_Tar- installed: 1.3.7
[PEAR] Console_Getopt - installed: 1.3.0
[PEAR] Structures_Graph- installed: 1.0.4
[PEAR] XML_Util   - installed: 1.2.1
[PEAR] PEAR   - installed: 1.9.4
Wrote PEAR system config file at: /usr/local/etc/pear.conf
You may want to add: /usr/local/lib/php to your php.ini include_path

when I look into /usr/local/bin the php cli binary is not there. Doing a
locate does not find any php binary (even after an updatedb).

There is one output that can be interpreted as an error but I don't think
it has anything to do with not compiling php:

Generating phar.php
Generating phar.phar
PEAR package PHP_Archive not installed: generated phar will require PHP's
phar extension be enabled.

I'm running on mac osx 10.7.3. I have no problems on Ubuntu 11.04.

Has anyone ran into this issue? Is there some output I should be paying
attention to?

[PHP-DEV] imap_headerinfo defaulthost parameter

[Stas Malyshev]

Hi!

Could anybody tell me what defaulthost parameter is supposed to do in
imap_headerinfo()? The docs say nothing about it and it doesn't seem to
be used anywhere in the code. Any ideas? Should we just remove it or it
serves some purpose?
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227


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

Re: [PHP-DEV] [proposal + pull request] Replace logo GUIDs with data URIs

[Stas Malyshev]

Hi!

> And I actually know of websites using the functions to display the logo..
> Is there some way we could provide a BC function for it somehow?
> Maybe rather then removing the functions, make then return the data uris?

Having the functions to get the images sounds like a good idea, some
sites may want to use them to display the logos. However, I don't think
we should use the same function, as then deciding what the function
actually does is complicated. I'd rather prefer doing something like:

if(function_exists('php_logo_guid')) {
  $url = "/index.php?=".php_logo_guid();
} else if(function_exists('php_logo_url')) {
  $url = php_logo_url();
}
if(!empty($url))
echo "";

it's clear what each function gives me then.

-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227



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

Re: [PHP-DEV] [proposal + pull request] Replace logo GUIDs with data URIs

[Brandon Wamboldt]

FYI, data URIs are only supported in IE8 or higher, IE7 and below do not
support them.

On Sat, Jul 14, 2012 at 6:16 PM, Rasmus Lerdorf  wrote:

> On 07/14/2012 01:49 PM, Andrew Faulds wrote:
> > Hi there,
> >
> > This is a patch that replaces PHP's infamous logo GUIDs with data URIs
> > instead, and also embed PHP credits in the phpinfo() page, hidden
> > using JavaScript (but gracefully degrading), to eliminate these GUIDs
> > altogether.
> >
> > :)
> >
> > https://github.com/php/php-src/pull/132
>
> Looks ok to me. master-only, of course. It is simpler and cleaner than
> the GUID approach and I think enough browsers can handle data URIs these
> days.
>
> -Rasmus
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
*Brandon Wamboldt*
Programmer / Web Developer

StackOverflow Careers
Profile- GitHub
Profile  -
LinkedIn -
My Blog 

Re: [PHP-DEV] [proposal + pull request] Replace logo GUIDs with data URIs

[Hannes Magnusson]

On Sat, Jul 14, 2012 at 9:49 PM, Andrew Faulds  wrote:
> Hi there,
>
> This is a patch that replaces PHP's infamous logo GUIDs with data URIs
> instead, and also embed PHP credits in the phpinfo() page, hidden
> using JavaScript (but gracefully degrading), to eliminate these GUIDs
> altogether.
>
> :)
>
> https://github.com/php/php-src/pull/132


The sapi/cli/tests/php_cli_server_011.phpt testcase looks like a real testcase..
It should probably be rewritten then removed completely.

And I actually know of websites using the functions to display the logo..
Is there some way we could provide a BC function for it somehow?
Maybe rather then removing the functions, make then return the data uris?

-Hannes

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

Re: [PHP-DEV] [proposal + pull request] Replace logo GUIDs with data URIs

[Rasmus Lerdorf]

On 07/14/2012 01:49 PM, Andrew Faulds wrote:
> Hi there,
> 
> This is a patch that replaces PHP's infamous logo GUIDs with data URIs
> instead, and also embed PHP credits in the phpinfo() page, hidden
> using JavaScript (but gracefully degrading), to eliminate these GUIDs
> altogether.
> 
> :)
> 
> https://github.com/php/php-src/pull/132

Looks ok to me. master-only, of course. It is simpler and cleaner than
the GUID approach and I think enough browsers can handle data URIs these
days.

-Rasmus

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

[PHP-DEV] Recommended way to create a zval that serves as a callback in an extension

[Adam Jon Richardson]

Hi,

I'm calling the function php_pcre_replace() in my extension:
http://lxr.php.net/xref/PHP_5_4/ext/pcre/php_pcre.c#952

I would like to use a callback for the replace_val, but this will be
supplied by my extension. I'm wondering what the recommended way of
creating the replace_val zval callback would be in the extension.

Thank you for your patience and help.

Adam

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

[PHP-DEV] [proposal + pull request] Replace logo GUIDs with data URIs

[Andrew Faulds]

Hi there,

This is a patch that replaces PHP's infamous logo GUIDs with data URIs
instead, and also embed PHP credits in the phpinfo() page, hidden
using JavaScript (but gracefully degrading), to eliminate these GUIDs
altogether.

:)

https://github.com/php/php-src/pull/132

-- 
Andrew Faulds (AJF)
http://ajf.me/

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

Re: [PHP-DEV] Re: array_last_key() function

[Rasmus Lerdorf]

On 07/14/2012 10:29 AM, Rasmus Lerdorf wrote:
> On 07/14/2012 10:13 AM, Anthony Ferrara wrote:
>> Gustavo,
>>
>> Why is the last key special? Why not a function to get the first or the
>>> penultimate key?
>>>
>>
>> How would such a function look?
> 
> I think the function would look just like the function we have for doing
> this.
> 
> key(array_slice($arr,-2));
> 
> And no, this has no side-effect of changing the array pointer in $arr,
> of course.
> 
> And array_last_key() is identical to array_slice($arr,-1) is it not?
> 
> The only thing array_last_key() saves is a single function call to
> key(). That doesn't seem worth it to me.

Ok, with the slight modification that for numeric keys we would want to
preserve the keys.

function array_last_key($arr) {
  return key(array_slice($arr,-1,null,true));
}

And despite what the docs say, the array pointer is not changed.
Test:

$a = [ 'first'=>1, 'second'=>2, 'third'=>3, 'last'=>4 ];
next($a);
next($a);
echo key($a);
echo array_last_key($a);
echo key($a);

This outputs:
third
last
third

-Rasmus

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

Re: [PHP-DEV] Re: array_last_key() function

[Gustavo Lopes]

Em Sat, 14 Jul 2012 19:13:32 +0200, Anthony Ferrara   
escreveu:



Why is the last key special? Why not a function to get the first or the

penultimate key?



How would such a function look?


I think you've misread my statement. I was not suggesting a function that  
would get an arbitrary key. I was asking what was special about the last  
key that would merit a dedicated function. The underlying position was  
that there was nothing special about them (but see below), and a dedicated  
function function was not warranted.



Of course, there is one aspect where the first and last keys are special
-- if you have some algorithm where you pop or shift the array
successively. But in that case the argument about end() + key() having  
side effects is irrelevant because you are changing the array anyway.


How are you changing the array by getting the last (or first) key in this
method? Could you elaborate on that?


I'm afraid I also wasn't clear here. One certainly does not have to change  
the array to get the first or the last key. I was only stating that the  
circumstances where it would be important to get specifically the first or  
the last key are also those where you would want to have side effects. My  
argument was that getting specifically the first or last keys is only  
important if you are somehow traversing the array by removing the first or  
last elements specifically and that requires side effects*.


*This statement requires some qualification. Of course, you don't need  
side effects to remove the last element; you could use array_slice() to  
implement a sort of array_rest() or array_most() that would remove the  
first or the last element. But 1) it is not efficient to use these  
patterns in PHP and 2) since you are anyway copying parts you the array,  
it is not a problem to change those copies.



--
Gustavo Lopes

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

Re: [PHP-DEV] Re: array_last_key() function

[Rasmus Lerdorf]

On 07/14/2012 10:13 AM, Anthony Ferrara wrote:
> Gustavo,
> 
> Why is the last key special? Why not a function to get the first or the
>> penultimate key?
>>
> 
> How would such a function look?

I think the function would look just like the function we have for doing
this.

key(array_slice($arr,-2));

And no, this has no side-effect of changing the array pointer in $arr,
of course.

And array_last_key() is identical to array_slice($arr,-1) is it not?

The only thing array_last_key() saves is a single function call to
key(). That doesn't seem worth it to me.

-Rasmus

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

Re: [PHP-DEV] Re: array_last_key() function

[Anthony Ferrara]

Gustavo,

Why is the last key special? Why not a function to get the first or the
> penultimate key?
>

How would such a function look?


> Of course, there is one aspect where the first and last keys are special
> -- if you have some algorithm where you pop or shift the array
> successively. But in that case the argument about end() + key() having side
> effects is irrelevant because you are changing the array anyway.


How are you changing the array by getting the last (or first) key in this
method? Could you elaborate on that?

Anthony

Re: [PHP-DEV] Re: array_last_key() function

[Gustavo Lopes]

Em Sat, 14 Jul 2012 04:04:27 +0200, Anthony Ferrara   
escreveu:



I like this idea. array_first_key would be nice too

I am probably missing something, but what those would allow to do that
rewind/end+key() doesn't do?



The big thing that it does that end()+key() doesn't do is really what it
doesn't do (update the internal pointer).

end() modifies the array pointer. So if you try this in user-land:

function array_last_key(array $array) {
end($array);
return key($array);
}

It will always force a full copy of the array (at least the hash table).
Implementing this as a core function however would eliminate that one
side-effect...


Why is the last key special? Why not a function to get the first or the  
penultimate key?


Of course, there is one aspect where the first and last keys are special  
-- if you have some algorithm where you pop or shift the array  
successively. But in that case the argument about end() + key() having  
side effects is irrelevant because you are changing the array anyway.


--
Gustavo Lopes

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

Re: [PHP-DEV] Re: array_last_key() function

[Paul Dragoonis]

(forgot to CC internals on the previous email)

On Sat, Jul 14, 2012 at 4:42 PM, John LeSueur  wrote:
> Readability is solved by creating a userland function:
>
> function array_last_key(&$array)
> {
> return key(array_slice($array, -1,1,true));
> }

Another userland function, with a by-ref parameter. Again more
unnecessary complexity, solved by our new friend array_last_key.

I hope this gets put into a branch soon, I'll happily +1 vote it.

- Paul.

>
> $lastkey = array_last_key($array);
>
> Now, it may still be quicker, or use less memory(temporarily) if it were a
> core function, but I'd like to see numbers before making a decision. I would
> still want to see a significant advantage before it is added to core.
>
>
> On Sat, Jul 14, 2012 at 9:33 AM, Paul Dragoonis  wrote:
>>
>> $lastKey = key(array_slice($array,-1,1,true));
>> vs
>> $lastKey = array_last_key($array);
>>
>> The latter will be quicker, use less memory and easier to read/maintain.
>>
>> - Paul.
>>
>> On Sat, Jul 14, 2012 at 4:28 PM, John LeSueur 
>> wrote:
>> >
>> >
>> > On Sat, Jul 14, 2012 at 4:34 AM, Paul Dragoonis 
>> > wrote:
>> >>
>> >> On Sat, Jul 14, 2012 at 3:04 AM, Anthony Ferrara 
>> >> wrote:
>> >> > Stas,
>> >> >
>> >> >> I like this idea. array_first_key would be nice too
>> >> >>
>> >> >> I am probably missing something, but what those would allow to do
>> >> >> that
>> >> >> rewind/end+key() doesn't do?
>> >> >>
>> >> >
>> >> > The big thing that it does that end()+key() doesn't do is really what
>> >> > it
>> >> > doesn't do (update the internal pointer).
>> >> >
>> >> > end() modifies the array pointer. So if you try this in user-land:
>> >> >
>> >> > function array_last_key(array $array) {
>> >> > end($array);
>> >> > return key($array);
>> >> > }
>> >> >
>> >> > It will always force a full copy of the array (at least the hash
>> >> > table).
>> >> > Implementing this as a core function however would eliminate that one
>> >> > side-effect...
>> >>
>> >> and it beats doing $var = null; if(isset($array[0])) { $var =
>> >> $array[0]; }
>> >>
>> > Not sure that does the trick(you're pulling values, not keys, and
>> > assuming
>> > 0-based array), but...
>> >
>> > What about reset(array_keys($array)); or end(array_keys($array)); which
>> > only
>> > makes copies of the keys?
>> > or even better key(array_slice($array, 0, 1, true)); or
>> > key(array_slice($array,-1,1,true)); which makes a copy of one element of
>> > the
>> > array?
>> >
>> > I'm of the opinion that we mostly have enough array_* functions, and new
>> > ones have to provide a significant advantage to be accepted. If these
>> > functions are significantly faster than the alternatives, then perhaps
>> > they
>> > have merit, but they seem like convenience functions, rather than
>> > fundamentals.
>> >
>> > John
>
>

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

Re: [PHP-DEV] Re: array_last_key() function

[John LeSueur]

On Sat, Jul 14, 2012 at 4:34 AM, Paul Dragoonis  wrote:

> On Sat, Jul 14, 2012 at 3:04 AM, Anthony Ferrara 
> wrote:
> > Stas,
> >
> >> I like this idea. array_first_key would be nice too
> >>
> >> I am probably missing something, but what those would allow to do that
> >> rewind/end+key() doesn't do?
> >>
> >
> > The big thing that it does that end()+key() doesn't do is really what it
> > doesn't do (update the internal pointer).
> >
> > end() modifies the array pointer. So if you try this in user-land:
> >
> > function array_last_key(array $array) {
> > end($array);
> > return key($array);
> > }
> >
> > It will always force a full copy of the array (at least the hash table).
> > Implementing this as a core function however would eliminate that one
> > side-effect...
>
> and it beats doing $var = null; if(isset($array[0])) { $var = $array[0]; }
>
> Not sure that does the trick(you're pulling values, not keys, and assuming
0-based array), but...

What about reset(array_keys($array)); or end(array_keys($array)); which
only makes copies of the keys?
or even better key(array_slice($array, 0, 1, true)); or
key(array_slice($array,-1,1,true)); which makes a copy of one element of
the array?

I'm of the opinion that we mostly have enough array_* functions, and new
ones have to provide a significant advantage to be accepted. If these
functions are significantly faster than the alternatives, then perhaps they
have merit, but they seem like convenience functions, rather than
fundamentals.

John

RE: [PHP-DEV] 6.0 And Moving Forward

[Clint Priest]

+1 :)

> -Original Message-
> From: Kris Craig [mailto:kris.cr...@gmail.com]
> Sent: Friday, July 13, 2012 11:47 AM
> To: Anthony Ferrara
> Cc: internals@lists.php.net
> Subject: Re: [PHP-DEV] 6.0 And Moving Forward
> 
> >
> >
> > 4. Rewrite the entire parser completely. I keep hearing about how bad
> > PHP's parser is, and how it's growing out of control. Perhaps this is
> > a good time to rewrite it (perhaps changing semantics slightly) to be
> > better adapted towards future changes...
> >
> >
> I'm bored so I'm gonna poke the hornet's nest:  Anyone up for converting the 
> whole damn thing to C++?
> 
> I welcome your hatred.  Muaa ha ha ha!  ;)
> 
> --Kris

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

Re: [PHP-DEV] Re: array_last_key() function

[Paul Dragoonis]

On Sat, Jul 14, 2012 at 3:04 AM, Anthony Ferrara  wrote:
> Stas,
>
>> I like this idea. array_first_key would be nice too
>>
>> I am probably missing something, but what those would allow to do that
>> rewind/end+key() doesn't do?
>>
>
> The big thing that it does that end()+key() doesn't do is really what it
> doesn't do (update the internal pointer).
>
> end() modifies the array pointer. So if you try this in user-land:
>
> function array_last_key(array $array) {
> end($array);
> return key($array);
> }
>
> It will always force a full copy of the array (at least the hash table).
> Implementing this as a core function however would eliminate that one
> side-effect...

and it beats doing $var = null; if(isset($array[0])) { $var = $array[0]; }

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

Re: [PHP-DEV] 6.0 And Moving Forward

[Lester Caine]

Sherif Ramadan wrote:

I propose choosing a different version naming for the next branch.
Perhaps we can skip 6 since it got nowhere and move right to 7. I'm
sure that's superficial right now, but will be important for the sake
of not confusing anyone that may have read or heard about what PHP 6
was once planned to be.


Which is perhaps why we had 5.3 with some major structural changes when that 
would have been better with a major number advance ... The confusion at that 
time with PHP6 'roadmap' prevented leaving PHP5.2 with some better longer term 
support.


But I agree with Pierre that skipping 6 is a little pointless just because 
people jumped on a bandwagon that had not even been put into Alpha and produced 
vapourware books.


The problem currently is producing a roadmap that we can all agree on and are 
happy to work towards. I see some of the re-factoring as a lot more practical 
than some of the facilities that are being forced on us by the likes of E_STRICT 
compliance. Many of my existing sites will never be E_STRICT compliant, it's not 
worth the time, so I need to maintain a version of PHP that supports those sites 
securely! And PHP5.2 is still the safest base for those sites but is no longer 
'secure' ... how many hundreds of thousands of sites currently live need all of 
the PHP5.3+ facilities switched off?


--
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk



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

Re: [PHP-DEV] 6.0 And Moving Forward

[Pierre Joye]

hi,

On Sat, Jul 14, 2012 at 8:14 AM, Sherif Ramadan  wrote:
> I'd like to address the most obvious issues I see with moving on to PHP 6.
>
> First, there has already been a lot of discussion on PHP 6 since as
> early as 2007, if I recall correctly. Albeit, a lot of this has died
> down over the years, but there are probably still a lot of books and
> people out there with misconceptions about PHP 6 and this could lead
> to further confusion. I believe it's important to try and make any
> future transitions into PHP easier.

PHP 6 never existed, we never did any release, I see no appealing but
pointless marketing reason to skip this version. I see however many
very good reasons not to skip it.

Cheers,
-- 
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org

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