Re: [PHP-DEV] PDO ODBC #42765 uninitialized length bug patch

[Anish Mistry]

PDO ODBC #42765 uninitialized length bug patch
https://bugs.php.net/bug.php?id=42765

Any takers?  Would we be able to get this patch committed?  It's a
pretty straight forward fix.

Thanks,

--
Anish

On 11/02/2016 10:32, Anish Mistry wrote:
> Would a developer be able look at the patch in this bug:
> https://bugs.php.net/bug.php?id=42765
> 
> And let me know what else needs to happen to get this committed?  This is 
> pretty much required to make the module work correctly with most SQL server 
> databases via ODBC.
> 
> I'm hitting this on multiple OSes and they are telling to get it committed 
> upstream instead of patching the local package.
> 

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

[PHP-DEV] Error of codes on page https://wiki.php.net/phpng-upgrading

[ideal]

Hi,

The codes that show usage of smart_string:

- smart_str str = {0};
- smart_str_appendl(str, " ", sizeof(" ") - 1);
- smart_str_0(str);
- RETURN_STRINGL(implstr.c, implstr.len, 0);
+ smart_string str = {0};
+ smart_string_appendl(str, " ", sizeof(" ") - 1);
+ smart_string_0(str);
+ RETVAL_STRINGL(str.c, str.len);
+ smart_string_free();

Maybe actually should be:

- smart_str str = {0};
- smart_str_appendl(str, " ", sizeof(" ") - 1);
- smart_str_0(str);
- RETURN_STRINGL(implstr.c, implstr.len, 0);
+ smart_string str = {0};
+ smart_string_appendl(, " ", sizeof(" ") - 1);
+ smart_string_0();
+ RETVAL_STRINGL(str.c, str.len);
+ smart_string_free();


Thanks.

Re: [PHP-DEV] [RFC] [Vote] Doxygen

[Christopher Jones]

On 17/6/17 5:53 pm, Fleshgrinder wrote:

Hi!

I started voting on the Doxygen RFC:

https://wiki.php.net/rfc/doxygen


Did I miss seeing when the vote ends?

Chris

--
http://twitter.com/ghrd


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

[PHP-DEV] NEUTRAL Benchmark Results for PHP Master 2017-06-20

[lp_benchmark_robot]

Results for project PHP master, build date 2017-06-20 08:30:24-07:00
commit: c18ba68
previous commit:e0403eb
revision date:  2017-06-20 10:11:41-04:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, 
stepping 2, LLC 45 MB
mem:128 GB
os: CentOS 7.1
kernel: Linux 3.10.0-229.4.2.el7.x86_64

Baseline results were generated using release php-7.0.0, with hash 60fffd2 from
2015-12-01 04:16:47+00:00

---
benchmark   relative   change since   change since  
current rev run
std_dev*   last run   baseline  
   with PGO
---
:-|   Wordpress 4.2.2 cgi -T1  0.24%  0.00%  3.21%  
  7.98%
:-|   Drupal 7.36 cgi -T1  0.16% -0.59%  1.30%  
  5.53%
:-|   MediaWiki 1.23.9 cgi -T5000  0.14% -0.31%  2.52%  
  4.17%
:-|   bench.php cgi -T100  0.01%  0.37% 46.74%  
  3.59%
:-|  micro_bench.php cgi -T10  0.01%  0.04% 21.90%  
  2.59%
:-|  mandelbrot.php cgi -T100  0.01% -0.01% 44.50%  
  3.15%
---

* Relative Standard Deviation (Standard Deviation/Average)

If this is not displayed properly please visit our results page here: 
http://languagesperformance.intel.com/neutral-benchmark-results-for-php-master-2017-06-20/

Note: Benchmark results for Wordpress, Drupal, MediaWiki are measured in
fetches/second while all others are measured in seconds.
More details on measurements methodology at: 
https://01.org/lp/documentation/php-environment-setup.

Subject Label Legend:
Attributes are determined based on the performance evolution of the workloads
compared to the previous measurement iteration.
NEUTRAL: performance did not change by more than 1% for any workload
GOOD: performance improved by more than 1% for at least one workload and there
is no regression greater than 1%
BAD: performance dropped by more than 1% for at least one workload and there is
no improvement greater than 1%
UGLY: performance improved by more than 1% for at least one workload and also
dropped by more than 1% for at least one workload


Our lab does a nightly source pull and build of the PHP project and measures
performance changes against the previous stable version and the previous nightly
measurement. This is provided as a service to the community so that quality
issues with current hardware can be identified quickly.

Intel technologies' features and benefits depend on system configuration and may
require enabled hardware, software or service activation. Performance varies
depending on system configuration.


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

Re: [PHP-DEV] Missing commits in 7.0 branch

[Stanislav Malyshev]

Hi!

> From the history it looks like you didn't push the 7.0 branch. 
> 
> See also the commit mail which only references 7.1 and master.
> http://news.php.net/php.cvs/96748

Ok, I've re-added them to 7.0 and pushed it. Anatol, could you also add
these to the release branch so that 7.0 would be in sync with 7.1 sooner?

Thanks,
-- 
Stas Malyshev
smalys...@gmail.com

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

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[Rowan Collins]

On 19 June 2017 21:22:53 BST, Rasmus Schultz  wrote:
>So what's on the table is a syntax-improved but feature-crippled
>variant of
>closures, not an all-round replacement?

I haven't the time right now to dig out my summary from the mail archives, but 
this is one of the fundamental disagreements / misunderstandings that made 
discussion difficult the first time: different people want very different 
things from this feature, leading to conflicting views on whether certain 
things are advantages or disadvantages.

For me (and I am not alone), this feature is NOT a new syntax for closures. It 
is a new TYPE of closure, with new semantics - automatically capturing 
variables - for a specific use case. 

Personally, I am strongly opposed to any multi-line version of it, because I 
don't want the fundamental scoping rules of the language changed except for the 
specific case of simple lambda expressions.

If what you are looking for is a replacement syntax for existing closures, you 
will have a completely different set of priorities. That doesn't make either of 
us wrong, but it does mean we're going to find it very hard to agree on a 
syntax and feature set.

Regards,

-- 
Rowan Collins
[IMSoP]

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

Re: [PHP-DEV] [RFC][VOTE] Add support for stream-wrapped URLs inopcode cache

[François Laupretre]

Hi,

Le 20/06/2017 à 18:35, 江湖大虾仁 a écrit :

Hi François,
  Good work, but I'm not sure if I missed something because I didn't 
find any discuss relating to this RFC in my mail box, as well as the 
PR on GitHub. I have a question about the detail of `cache_key`:


Discussion : http://www.serverphorums.com/read.php?7,1505444

> If the method is not defined, every path associated to this wrapper 
are non-cacheable. In order to avoid key value conflicts, the returned 
key must start with the same '://' prefix as the input path. 
If it not the case, an error is raised and the key is ignored.


Why don't we simply ask `cache_key` to provide the path, and we 
combine it with scheme in the core? It's much easier for userland to 
implement this feature since there is less limits, and we didn't need 
to worry about the key conflicts between different stream-wrappers any 
more.


1. The userspace code needs to get the full URL as input, as a stream 
wrapper may be associated with more than one scheme.
2. In the most usual case where the input URL is to be used as key, I 
cannot ask developers to compute the returned path by removing the 
'://' prefix from the input URL. The API is much easier to 
understand if they just return the input URL. It is also faster in this 
case because the PHP function/method returning its input argument won't 
even duplicate the data (it will just increment the zend_string 
reference count).


Regards

François

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

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[Rasmus Schultz]

> I just think your example is an exaggeration to what happens in practice.

I think it's an example of what happens with any inconsistent feature in
any language.


On Tue, Jun 20, 2017 at 9:53 AM, Markus Fischer  wrote:

> Hello Rasmus,
>
> On 19.06.17 22:22, Rasmus Schultz wrote:
>
>> If I have to factor back and forth between new and old syntax every time a
>> closure changes from one to multiple or back to one statement, then,
>> frankly, what's the point?
>>
>> I think I would just keep using the old syntax, then - for consistency,
>> and
>> to save myself the frustration of factoring back and forth.
>>
>
> I'm writing closures every day and it's so rare to have this changes from
> single/multiple I don't even remember. I think in practice this is a
> non-issue except for very rare special cases and, don't forget: it's
> optional, you don't have to.
>
> In my opinion, if this is worth doing, it's worth doing it right.
>>
>
> No counter-argument here :)
>
> I just think your example is an exaggeration to what happens in practice.
>
> - Markus
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] [RFC][VOTE] Add support for stream-wrapped URLs inopcode cache

[江湖大虾仁]

Hi François,
  Good work, but I'm not sure if I missed something because I didn't find any 
discuss relating to this RFC in my mail box, as well as the PR on GitHub. I 
have a question about the detail of `cache_key`:


> If the method is not defined, every path associated to this wrapper are  
> non-cacheable. In order to avoid key value conflicts, the returned key  must 
> start with the same '://' prefix as the input path.  If it not the 
> case, an error is raised and the key is ignored.


Why don't we simply ask `cache_key` to provide the path, and we combine it with 
scheme in the core? It's much easier for userland to implement this feature 
since there is less limits, and we didn't need to worry about the key conflicts 
between different stream-wrappers any more.




best regards,
CHU Zhaowei


-- Original --
From:  "François Laupretre";
Date:  Tue, Jun 20, 2017 02:12 AM
To:  "François Laupretre"; 
"Internals"; 

Subject:  Re: [PHP-DEV] [RFC][VOTE] Add support for stream-wrapped URLs 
inopcode cache

 
Hi,

Opening vote for : https://wiki.php.net/rfc/url-opcode-cache

Voting period will end Monday, July 3, 2017, 00:00 UTC.

Regards

François

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

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[Ilija Tovilo]

Well, the Ruby/Rust syntax would serve us well here too:

$things->forEach(|$v| {
    foo($v);
    bar($v);
});

On 19 Jun, 2017, at 09:43 PM, Rasmus Schultz  wrote:

I actually like this syntax, but what would it look like for multi-statement 
closures?

A nested set of curly braces around the body would look pretty messy.

    $things->forEach({$v => { foo($v); bar($v); }});


On Mon, Jun 19, 2017 at 4:43 PM, Levi Morrison  wrote:
On Sun, Jun 18, 2017 at 1:44 PM, Ilija Tovilo  wrote:

Sorry, I wasn’t aware of that.

What do you think of the Ruby/Rust style syntax that Levi proposed a while back?

$someDict
     ->map(|$v| $v * 2)
     ->filter(|$v| $v % 3);

This one has a few advantages:

1. It has syntax (a lot of) developers are already familiar with
2. It has no ambiguities and is fully backward compatible
3. It’s the shortest of all options available (two `|` characters and one space)


We determined that the arrow between the parameters and the expression
would still be required. Given this limitation I think this syntax is
seviceable:

    $someDict
        ->map({$v => $v * 2})
        ->filter({$v => $v % 3});

Sometime this week I intend to start another thread that narrows us
down to two choices.

Re: [PHP-DEV] Missing commits in 7.0 branch

[Johannes Schlüter]

On Mo, 2017-06-19 at 17:58 -0700, Stanislav Malyshev wrote:
> Hi!
> 
> I've discovered something weird in 7.0 branch. There are two commits
> of
> a bugfix -
> https://github.com/php/php-src/commit/d1d002fc4dd25a80e20163b18880f40
> a445276e7
> and
> https://github.com/php/php-src/commit/8c44d07fd485a8e8d62bc6e4fe14bec
> 5493ebc58
> - which I made, which are present in 7.1 and master. However, they
> were
> made for 7.0 branch (as merge commit in 7.1 shows) - but there is no
> trace of it in 7.0. I am trying to figure out why is that and what
> happened to it in 7.0 - is it my mess-up or somehow it was removed?
> 
> If nobody knows what happened, I'd assume I just messed it up and
> forgot
> to push into 7.0, and will re-add them, but I want to be sure just in
> case I forgot or misunderstood something.

>From the history it looks like you didn't push the 7.0 branch. 

See also the commit mail which only references 7.1 and master.
http://news.php.net/php.cvs/96748

johannes

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

Re: [PHP-DEV] [RFC][VOTE] Allow loading extensions by name

[Sara Golemon]

I'll double check later today, it might be that this comes in from the
startup phase and we can't do zend_error() for some reason.  Either
way I'll get it merged soonish.
Thanks.
-Sara

On Tue, Jun 20, 2017 at 6:53 AM, François Laupretre
 wrote:
> Hi Sara,
>
> Le 19/06/2017 à 23:33, Sara Golemon a écrit :
>>
>> I was about to merge this, but ran into some issues (mostly minor).
>> Could you at least address the fwrite(stderr, ...) item (and
>> preferably clean up the style nits while you're at it)?
>>
>> Oh, and I forgot to include it in the CR, but there are some
>> tabs/spaces issues as well.
>
> I fixed typos and style issues.
>
> About the 'fwrite(stderr,', I just used the same mechanism used by
> zend_load_extension() to raise an error. If you consider it is safe to
> replace it with a call to zend_error(), I'll do it.
>
> Regards
>
> François

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

Re: [PHP-DEV] [RFC][VOTE] Allow loading extensions by name

[François Laupretre]

Hi Sara,

Le 19/06/2017 à 23:33, Sara Golemon a écrit :

I was about to merge this, but ran into some issues (mostly minor).
Could you at least address the fwrite(stderr, ...) item (and
preferably clean up the style nits while you're at it)?

Oh, and I forgot to include it in the CR, but there are some
tabs/spaces issues as well.

I fixed typos and style issues.

About the 'fwrite(stderr,', I just used the same mechanism used by 
zend_load_extension() to raise an error. If you consider it is safe to 
replace it with a call to zend_error(), I'll do it.


Regards

François

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

Re: [PHP-DEV] [RFC]Discuss] Syntax for Arrow Functions

[Markus Fischer]

Hello Rasmus,

On 19.06.17 22:22, Rasmus Schultz wrote:

If I have to factor back and forth between new and old syntax every time a
closure changes from one to multiple or back to one statement, then,
frankly, what's the point?

I think I would just keep using the old syntax, then - for consistency, and
to save myself the frustration of factoring back and forth.


I'm writing closures every day and it's so rare to have this changes 
from single/multiple I don't even remember. I think in practice this is 
a non-issue except for very rare special cases and, don't forget: it's 
optional, you don't have to.



In my opinion, if this is worth doing, it's worth doing it right.


No counter-argument here :)

I just think your example is an exaggeration to what happens in practice.

- Markus

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