Re: [PHP-DEV] Re: Bug 47435[Was]: Re: [PHP-DEV] What gruntwork needs to be done

[Ferenc Kovacs]

I want both!!!
:)

Tyrael

On Wed, Apr 7, 2010 at 11:18 PM, Michael Graziano  wrote:

> > Ramus,
> >
> > On Tue, Apr 6, 2010 at 1:34 PM, Rasmus Lerdorf 
> wrote:
> >
> >>
> >> Here is a straightforward (but not easy) one:
> >>
> >> http://bugs.php.net/bug.php?id=47435
> >>
> >> I actually found it easy, slightly tedious, and not straightforward. I
> > guess its perspective.
> >
> > I am CCing my former colleague Mike G who added is $.02 to the ticket at
> > my
> > request.
>
> > Valli's notes implied that FILTER_VALIDATE_IP should match CIDR netmask
> > notations. eg 0.0.0.0/0 and ::1/128 should match. They do not. I propose
> a
> > new flag called FILTER_FLAG_INCLUDE_CIDR_NETMASK that does match.
>
> I have mixed feelings on the CIDR matching aspect -- using CIDR notation
> It's possible to define an "insane" network (like 8000::/1 or 128.0.0.0/1
> or 192.0.0.0/8) that encompasses a bunch of "special" nets, but is not
> itself "special" per the RFCs. It's a stupid and pathological edge case
> which should never happen, but it creates all sorts of funky interaction
> with the other filter flags that you would need to account for.
> Rejecting the CIDR mask and requiring an unqualified (and therefore
> implied v4/32 or v6/128) address is a neat (and common) way of
> sidestepping that problem.
>
> Having said that, in the sane, non-pathological case subnet matching is
> really nice to have. :)
>
> -MG
>
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

[PHP-DEV] Re: Bug 47435[Was]: Re: [PHP-DEV] What gruntwork needs to be done

[Michael Graziano]

> Ramus,
>
> On Tue, Apr 6, 2010 at 1:34 PM, Rasmus Lerdorf  wrote:
>
>>
>> Here is a straightforward (but not easy) one:
>>
>> http://bugs.php.net/bug.php?id=47435
>>
>> I actually found it easy, slightly tedious, and not straightforward. I
> guess its perspective.
>
> I am CCing my former colleague Mike G who added is $.02 to the ticket at
> my
> request.

> Valli's notes implied that FILTER_VALIDATE_IP should match CIDR netmask
> notations. eg 0.0.0.0/0 and ::1/128 should match. They do not. I propose a
> new flag called FILTER_FLAG_INCLUDE_CIDR_NETMASK that does match.

I have mixed feelings on the CIDR matching aspect -- using CIDR notation
It's possible to define an "insane" network (like 8000::/1 or 128.0.0.0/1
or 192.0.0.0/8) that encompasses a bunch of "special" nets, but is not
itself "special" per the RFCs. It's a stupid and pathological edge case
which should never happen, but it creates all sorts of funky interaction
with the other filter flags that you would need to account for.
Rejecting the CIDR mask and requiring an unqualified (and therefore
implied v4/32 or v6/128) address is a neat (and common) way of
sidestepping that problem.

Having said that, in the sane, non-pathological case subnet matching is
really nice to have. :)

-MG




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

[PHP-DEV] Re: Bug 47435[Was]: Re: [PHP-DEV] What gruntwork needs to be done

[Justin Dearing]

On Wed, Apr 7, 2010 at 3:39 PM, Rasmus Lerdorf  wrote:

>
> I'm ok with these.  Like you say, this stuff is a bit tedious to sort
> through, and anything we can do to make it easier on users is a good
> thing.  I'm trying to get the filter extension beefed up in the next
> version of PHP so people will gravitate towards it as an easy to use
> built-in mechanism as opposed to rolling their own over and over.
>

I'm all about reusing code.

Before I open the ticket, can someone propose a better constant name than
FILTER_FLAG_INCLUDE_CIDR_NETMASK.

Justin

Re: [PHP-DEV] Output buffering patch

[Michael Wallner]

Am 07.04.2010 16:37, schrieb Zeev Suraski:

At 09:58 07/04/2010, Michael Wallner wrote:

Here you go:

http://wiki.php.net/rfc/new-output-api


Thanks Mike - that's very helpful!

Quick question - other than fixing the issues mentioned in the intro
section of the RFC, are there any changes to the behavior of
userland-accessible functions (ob_start(), etc.)?


It actually fixes quite some more oddities, but I really can't remember
what...

I'm also having quite a hard time remembering userland changes, but some 
off the top of my head:


ob_start(array("oh1","oh2","oh3")) does not work, as the handler 
argument is always supposed to be callable.  This was undeocumented anyway.


ob_get_status() arrays have more/other entries.

ob_start("obh", 1) was supposed to really buffer just one byte, but 
AFAIR this was changed back by someone to default to 4096...


ob_gzhandler() and thelike are no PHP_FUNCTIONs anymore.

Regards,
Mike

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

[PHP-DEV] Re: Bug 47435[Was]: Re: [PHP-DEV] What gruntwork needs to be done

[Rasmus Lerdorf]

On 04/07/2010 12:30 PM, Justin Dearing wrote:
> Ramus,
> 
> On Tue, Apr 6, 2010 at 1:34 PM, Rasmus Lerdorf  > wrote:
> 
> Here is a straightforward (but not easy) one:
> 
> http://bugs.php.net/bug.php?id=47435
> 
> I actually found it easy, slightly tedious, and not straightforward. I
> guess its perspective.
> 
> I am CCing my former colleague Mike G who added is $.02 to the ticket at
> my request.
> 
> I have submitted a patch that includes tests after Valli's suggestion. I
> have to add the IPv4 mapping code, and will do that tonight. If you
> could provide feedback on the rest I would appreciate it.
> 
> Below are two proposals that I think belong in separate tickets. I will
> open these two tickets unless they are summarily rejected by Ramus.
> 
> Valli's notes implied that FILTER_VALIDATE_IP should match CIDR netmask
> notations. eg 0.0.0.0/0  and ::1/128 should match.
> They do not. I propose a new flag called
> FILTER_FLAG_INCLUDE_CIDR_NETMASK that does match. 
> 
> I second Mike G's proposed additional "FILTER_FLAG_NO_SPECIAL_RANGE"
> that captures the union of the other sets as a convenient shortcut.

I'm ok with these.  Like you say, this stuff is a bit tedious to sort
through, and anything we can do to make it easier on users is a good
thing.  I'm trying to get the filter extension beefed up in the next
version of PHP so people will gravitate towards it as an easy to use
built-in mechanism as opposed to rolling their own over and over.

-Rasmus

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

[PHP-DEV] Bug 47435[Was]: Re: [PHP-DEV] What gruntwork needs to be done

[Justin Dearing]

Ramus,

On Tue, Apr 6, 2010 at 1:34 PM, Rasmus Lerdorf  wrote:

>
> Here is a straightforward (but not easy) one:
>
> http://bugs.php.net/bug.php?id=47435
>
> I actually found it easy, slightly tedious, and not straightforward. I
guess its perspective.

I am CCing my former colleague Mike G who added is $.02 to the ticket at my
request.

I have submitted a patch that includes tests after Valli's suggestion. I
have to add the IPv4 mapping code, and will do that tonight. If you could
provide feedback on the rest I would appreciate it.

Below are two proposals that I think belong in separate tickets. I will open
these two tickets unless they are summarily rejected by Ramus.

Valli's notes implied that FILTER_VALIDATE_IP should match CIDR netmask
notations. eg 0.0.0.0/0 and ::1/128 should match. They do not. I propose a
new flag called FILTER_FLAG_INCLUDE_CIDR_NETMASK that does match.

I second Mike G's proposed additional "FILTER_FLAG_NO_SPECIAL_RANGE" that
captures the union of the other sets as a convenient shortcut.

Justin

[PHP-DEV] Mysql completing Query fast but mysql->query() takes long time to return even single selects/updates

[David Murphy]

As you can see  PHP claims  it took 20 seconds for mysql->query() to return
but   mysql think is took around 1.0s

 
This is from our application 
I enabled profile in mysql to determine why an update took 20seconds.  As
you can see  MySQL reported no where near that amount of duration took
place. 
Is there any way I can dig into php and determine why  mysql client libs are
so slow (this is not using mysqlnd but  mysql-client-libs on CentOS using
5.3.2)
 
 
04/06/2010 14:54:54 20.6899s  UPDATE `calls` SET `Result`='Busy' WHERE
`CallID`='144786'
 | Status   | Duration | CPU_user | CPU_system |
Context_voluntary | Context_involuntary | Block_ops_in | Block_ops_out |
Messages_sent | Messages_received | Page_faults_major | Page_faults_minor |
Swaps | 
 


--
 | starting | 0.39 | 0.00 | 0.00   | 0
| 0   | 0| 0 | 0 | 0
| 0 | 0 | 0 | 
 | checking permissions | 0.08 | 0.00 | 0.00   | 0
| 0   | 0| 0 | 0 | 0
| 0 | 0 | 0 | 
 | Opening tables   | 0.10 | 0.00 | 0.00   | 0
| 0   | 0| 0 | 0 | 0
| 0 | 0 | 0 | 
 | System lock  | 0.05 | 0.00 | 0.00   | 0
| 0   | 0| 0 | 0 | 0
| 0 | 0 | 0 | 
 | Table lock   | 0.06 | 0.00 | 0.00   | 0
| 0   | 0| 0 | 0 | 0
| 0 | 0 | 0 | 
 | init | 0.36 | 0.00 | 0.00   | 0
| 0   | 0| 0 | 0 | 0
| 0 | 0 | 0 | 
 | Updating | 0.99 | 0.001000 | 0.00   | 0
| 0   | 0| 0 | 0 | 0
| 0 | 0 | 0 | 
 | end  | 0.23 | 0.00 | 0.00   | 0
| 0   | 0| 0 | 0 | 0
| 0 | 0 | 0 | 
 | query end| 0.04 | 0.00 | 0.00   | 0
| 0   | 0| 0 | 0 | 0
| 0 | 0 | 0 | 
 | freeing items| 0.007410 | 0.00 | 0.00   | 4
| 1   | 0| 0 | 0 | 0
| 0 | 0 | 0 | 
 | logging slow query   | 0.04 | 0.00 | 0.00   | 0
| 0   | 0| 0 | 0 | 0
| 0 | 0 | 0 | 
 | cleaning up  | 0.04 | 0.00 | 0.00   | 0
| 0   | 0| 0 | 0 | 0
| 0 | 0 | 0 |

 

 

Thanks

David Murphy

Re: [PHP-DEV] Repetitive calling of Z_STRLEN_P(value) in ext/filter/logical_filter.c

[Michael Maclean]

Justin Dearing wrote:
> Hey,
> 
> Sorry for pestering with excessive questions, but I've not done a lot of C
> programming.
> 
> In filter.c, specificalyl in php_filter_validate_ip(), Z_STRLEN_P(value)
> gets called a lot. I know compilers tend to inline short functions, but are
> they smart enough to assign a variable to a repetive macro expansion?

Z_STRLEN_P is just a macro that expands to a variant of Z_STRLEN, which
in turn is just (zval).value.str.len. These macros will be expanded by
the preprocessor before the code is actually compiled.

http://php-og.mgdm.net/opengrok/xref/PHP_5_3/Zend/zend_operators.h#Z_STRLEN_P


Michael

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

[PHP-DEV] Repetitive calling of Z_STRLEN_P(value) in ext/filter/logical_filter.c

[Justin Dearing]

Hey,

Sorry for pestering with excessive questions, but I've not done a lot of C
programming.

In filter.c, specificalyl in php_filter_validate_ip(), Z_STRLEN_P(value)
gets called a lot. I know compilers tend to inline short functions, but are
they smart enough to assign a variable to a repetive macro expansion?

Justin

Re: [PHP-DEV] Output buffering patch

[Zeev Suraski]

At 09:58 07/04/2010, Michael Wallner wrote:

Here you go:

http://wiki.php.net/rfc/new-output-api


Thanks Mike - that's very helpful!

Quick question - other than fixing the issues mentioned in the intro 
section of the RFC, are there any changes to the behavior of 
userland-accessible functions (ob_start(), etc.)?


Zeev 



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

[PHP-DEV] GitHub mirror is not worked

[Kousuke Ebihara]

Hi,

http://github.com/php/php-src is not updated for a long time.

Probably, it has not worked correctly since removing trunk.

I hope that it will work again.

(Is this report suitable for this list?)

Thanks.

--
Kousuke Ebihara

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

Re: [PHP-DEV] Named Parameters

[Christian Schneider]

Tjerk Anne Meesters wrote:
> In the case whereby names parameters are "plucked" from the argument
> list and passed as a hash to the function it really shouldn't matter
> whether that's invalid in python; both (2, 'name' => 'test') and
> ('name' => 'test', 2) would yield the same results, albeit it's a
> highly dubious way of passing arguments ;-)

Actually we use "positional" (scalar) both after and before "named"
(associative) parameters a lot for HTML generation and DB queries:

$html = table('class' => "beautiful",
tr(
td("foo"), td("bar"),
),
tr(
td("qux"), td("quux"),
),
);

foreach (new T_User('firstname' => $firstname, "ORDER BY age") as $user)
...

$bar = it::replace('Foo' => "Bar", $foo, 'casesensitive' => true);

So any solution restricting named parameters to any of
- declared named parameters only
- not allowing alternating named/positional parameter sets while
maintaining these sets and order
would not fit our needs.

As a result our patch (and syntax converter in both directions for
unpatched webservers) uses a simple but somewhat limited approach:
Any sequence of key => value pairs in a function call are surrounded by
array() (done at compile time). This means functions accepting
interleaved named/non-named parameters need to do some varargs parsing
and sometimes you need to still manually add array() if you want to
separate two sets of named parameters (but that's a questionable API in
most cases).

More info: http://cschneid.com/php/INFO_README
Patch and manual converter: http://cschneid.com/php/
Autoloader with automatic syntax conversion: http://itools.search.ch/

I know I've mentioned this here before but I still think its pros and
cons should be taken into consideration when talking about this subject,
- Chris

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

Re: [PHP-DEV] Named Parameters

[Tjerk Anne Meesters]

In the case whereby names parameters are "plucked" from the argument
list and passed as a hash to the function it really shouldn't matter
whether that's invalid in python; both (2, 'name' => 'test') and
('name' => 'test', 2) would yield the same results, albeit it's a
highly dubious way of passing arguments ;-)

On 4/7/10, Martin Jansen  wrote:
> On 5.4.2010 00:45, Pierre Joye wrote:
>> On Mon, Apr 5, 2010 at 12:07 AM, Stanislav Malyshev  wrote:
>>
>>> 3. Combining named and un-named params can get weird - i.e. foo(1,2,3) is
>>> simple, foo(1, 2, bar => 3) is doable, but foo(1, 2, bar => 3, 4) would
>>> be
>>> trouble, since it is not clear at all where 4 should go to. Moreover,
>>
>> If we introduce named argument, mixing them should not be weird. An
>> argument can have both a name and a position, allowing combination of
>> normal or named arguments. Python's way to do it is very nice and
>> handy:
>>
>> http://diveintopython.org/power_of_introspection/optional_arguments.html
>
> Just to be clear about this:  Python does not allow using an unnamed
> parameter after a named parameter occurred, i.e. foo(bar = 3, 2) is not
> valid there.
>
> I would go as far as disallowing mixing of named and unnamed parameters
> completely.  But that's probably just me.
>
> - Martin
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 
--
Tjerk

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

Re: [PHP-DEV] Named Parameters

[Pierre Joye]

On Wed, Apr 7, 2010 at 8:27 AM, Martin Jansen  wrote:
> On 5.4.2010 00:45, Pierre Joye wrote:
>> On Mon, Apr 5, 2010 at 12:07 AM, Stanislav Malyshev  wrote:
>>
>>> 3. Combining named and un-named params can get weird - i.e. foo(1,2,3) is
>>> simple, foo(1, 2, bar => 3) is doable, but foo(1, 2, bar => 3, 4) would be
>>> trouble, since it is not clear at all where 4 should go to. Moreover,
>>
>> If we introduce named argument, mixing them should not be weird. An
>> argument can have both a name and a position, allowing combination of
>> normal or named arguments. Python's way to do it is very nice and
>> handy:
>>
>> http://diveintopython.org/power_of_introspection/optional_arguments.html
>
> Just to be clear about this:  Python does not allow using an unnamed
> parameter after a named parameter occurred, i.e. foo(bar = 3, 2) is not
> valid there.

Right, the doc is clear about that and makes the whole thing less confusing.

> I would go as far as disallowing mixing of named and unnamed parameters
> completely.  But that's probably just me.

That would defeat the main purposes of named arguments.

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

Re: [PHP-DEV] Output buffering patch

[Michael Wallner]

On 03/24/2010 09:41 PM, Lukas Kahwe Smith wrote:

All I am asking is a single document in the central location we have
dedicated for this (aka the rfc namespace on the wiki), that pulls
together all relevant documentation. If all that is needed is a copy
paste of a bunch of URL's all the better. But it makes no sense to
ask each and every developer to "do his homework". Thats a waste of
time and a sure way to have misunderstandings.

Seems like you know all there is to know about this, so how about
just throwing together an RFC, shouldnt take more than 10 minutes if
all of this is already perfectly documented.


Here you go:

http://wiki.php.net/rfc/new-output-api

Cheers,
Mike

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

Re: [PHP-DEV] Output buffering patch

[Michael Wallner]

On 03/24/2010 09:41 PM, Lukas Kahwe Smith wrote:

All I am asking is a single document in the central location we have
dedicated for this (aka the rfc namespace on the wiki), that pulls
together all relevant documentation. If all that is needed is a copy
paste of a bunch of URL's all the better. But it makes no sense to
ask each and every developer to "do his homework". Thats a waste of
time and a sure way to have misunderstandings.

Seems like you know all there is to know about this, so how about
just throwing together an RFC, shouldnt take more than 10 minutes if
all of this is already perfectly documented.


Here you go:

http://wiki.php.net/rfc/new-output-api

Cheers,
Mike

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