Re: [PHP-DEV] Wiki RFC karma request: pmmaga

2016-12-06 Thread Joe Watkins
Morning,

Granted.

Cheers
Joe

On Mon, Dec 5, 2016 at 6:19 PM, Pedro Magalhães  wrote:

> Hi all,
>
> In order to create the RFC for the deprecation of the binary strings and
> future RFCs,
> I kindly request that my account on the wiki (pmmaga) is given the
> necessary karma.
>
> Thanks in advance.
>
> Regards,
> Pedro Magalhães
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


[PHP-DEV] Use pthread in php extension

2016-12-06 Thread simon .barotte
Hi all,

I developpe an extension php, and I would like use Linux pthread in my
extension (PHP 5.6.27).
But I have a feeling that my thread don't work, I looked for the
documentation but I find no concrete example.
Can I use pthread without zts activated ? Sample of my code :

void *called_from_thread(void *num){
php_printf(" print by thread");
}

PHP_FUNCTION(test){
pthread_t inc_x_thread;
int x = 0;

if(pthread_create(&inc_x_thread, NULL, called_from_thread, &x)) {
php_printf("Error creating thread");
return;
}

php_printf("This is main print");

if(pthread_join(inc_x_thread, NULL)) {
php_printf("Error joining thread");
return;
}
}

When I execute my extension in php, I always obtain the same display, This
is main print print by thread
For me the normal behavior of thread would be to have different displays
sometimes... no ?

Every help/advice is welcome :)

Regards.
Simon


Re: [PHP-DEV] [RFC][VOTE] User defined session serializer

2016-12-06 Thread Bob Weinand
Hey,

> Am 06.12.2016 um 08:06 schrieb Yasuo Ohgaki :
> 
> Hi all,
> 
> *snip*
> 
> * Why it does not use exception for error?
> 
> Session module uses "errors", not "exceptions" basically. Session save
> handler uses "errors" also. We should avoid inconsistency in a module.
> Exception adoption will be addressed and exceptions will be used
> consistent manner by other RFC.

This is not session module specific, your interface is specifying a return 
type. Thus this should be enforced on the interface implementation level. (I.e. 
it will be impossible for an user to define a function not having a return type 
of string/array)

Also, if a wrong argument is passed to a function, it should throw a type 
error. Perhaps old modules from pre-PHP 5 do emit warnings or recoverables, but 
we then shall transition from that to TypeError, and definitely use TypeError 
in new functionality.

Bob

[PHP-DEV] SoapClient __getLocation

2016-12-06 Thread Silvio Marijić
Hi,

I've submited pull request to add a __getLocation to SoapClient. Motivation
for that was to add a practical way of getting current location from
SoapClient.

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

Any feedback?

Cheers.

-- 
Silvio Marijić
Software Engineer
2e Systems


[PHP-DEV][RFC][DISCUSSION] SoapClient __getLocation method

2016-12-06 Thread Silvio Marijić
2016-12-06 15:47 GMT+01:00 Silvio Marijić :

> Here is RFC open for discussion.
>
> https://wiki.php.net/rfc/soap_get_location
>
> 2016-12-06 14:48 GMT+01:00 Silvio Marijić :
>
>> Hi,
>>
>> I've submited pull request to add a __getLocation to SoapClient.
>> Motivation for that was to add a practical way of getting current location
>> from SoapClient.
>>
>> https://github.com/php/php-src/pull/2232
>>
>> Any feedback?
>>
>> Cheers.
>>
>> --
>> Silvio Marijić
>> Software Engineer
>> 2e Systems
>>
>
>
>
> --
> Silvio Marijić
> Software Engineer
> 2e Systems
>



-- 
Silvio Marijić
Software Engineer
2e Systems


[PHP-DEV] Re: SoapClient __getLocation

2016-12-06 Thread Silvio Marijić
Here is RFC open for discussion.

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

2016-12-06 14:48 GMT+01:00 Silvio Marijić :

> Hi,
>
> I've submited pull request to add a __getLocation to SoapClient.
> Motivation for that was to add a practical way of getting current location
> from SoapClient.
>
> https://github.com/php/php-src/pull/2232
>
> Any feedback?
>
> Cheers.
>
> --
> Silvio Marijić
> Software Engineer
> 2e Systems
>



-- 
Silvio Marijić
Software Engineer
2e Systems


[PHP-DEV] UGLY Benchmark Results for PHP Master 2016-12-06

2016-12-06 Thread lp_benchmark_robot
Results for project PHP master, build date 2016-12-06 06:26:58+02:00
commit: 795cd6d
previous commit:35cfec1
revision date:  2016-12-05 20:41:21+01: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.07% -0.04%  0.12%  
  7.25%
:-|   Drupal 7.36 cgi -T1  0.17%  0.72% -0.15%  
  3.23%
:-|   MediaWiki 1.23.9 cgi -T5000  0.16% -0.28%  2.10%  
  3.40%
:-|   bench.php cgi -T100  0.00% -0.06% 32.56%  
 -1.98%
:-(  micro_bench.php cgi -T10  0.01% -3.07% 12.35%  
  4.92%
:-)  mandelbrot.php cgi -T100  0.03%  3.58% 32.87%  
-14.45%
---

* Relative Standard Deviation (Standard Deviation/Average)

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

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] Re: [RFC] Debugging PDO Prepared Statement Emulation v2

2016-12-06 Thread Adam Baratz
>
> This issue is not difficult to solve in userland, at least well enough for
> debugging in my experience. Here's an older example I wrote up on my blog
> that worked (but I'm told is broken right now): https://daveyshafik.com/
> archives/605-debugging-pdo-prepared-statements.html
>

I want to be able to write .phpt tests that validate how values are getting
interpolated into emulated prepares. Since this creates a separate code
path, it wouldn't let me validate what gets sent to the server.
PDO::quote() doesn't necessarily produce the same output as
pdo_parse_params().


Re: [PHP-DEV] Re: [RFC] Debugging PDO Prepared Statement Emulation v2

2016-12-06 Thread Lester Caine
On 06/12/16 16:30, Adam Baratz wrote:
>> This issue is not difficult to solve in userland, at least well enough for
>> debugging in my experience. Here's an older example I wrote up on my blog
>> that worked (but I'm told is broken right now): https://daveyshafik.com/
>> archives/605-debugging-pdo-prepared-statements.html
>>
> I want to be able to write .phpt tests that validate how values are getting
> interpolated into emulated prepares. Since this creates a separate code
> path, it wouldn't let me validate what gets sent to the server.
> PDO::quote() doesn't necessarily produce the same output as
> pdo_parse_params().

The whole point of testing is that it tests real results not testing
'test code' that tries to emulate the real world. The whole point of
'emulated prepare statements' is that it creates a SQL query that the
target database engine can actually work with rather than one that a
more capable database engine will process. Testing the innards of some
driver is simply wrong, one tests the whole process is working! And
IDEALLY the test suit for PDO should work which ever target is selected,
but that is not lightly to happen any time soon.

-- 
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][RFC][DISCUSSION] SoapClient __getLocation method

2016-12-06 Thread Dan Ackroyd
On 6 December 2016 at 14:59, Silvio Marijić  wrote:

> https://wiki.php.net/rfc/soap_get_location
> https://github.com/php/php-src/pull/2232
>
> Any feedback?

Looks good to me. I'm not entirely sure this needs an RFC, but maybe
some people have some reason to object to it.

The only other thing to note is that ext/soap is an example of an
extension that could/should eventually be replaced with a userland
replacement and removed from core.but that is a task for another
day.

cheers
Dan
Ack

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



Re: [PHP-DEV][RFC][DISCUSSION] SoapClient __getLocation method

2016-12-06 Thread Silvio Marijić
Hi Dan,

Thanks for feedback. I'm not sure about RFC either, but it is a new feature
sort of.

Cheers,
Silvio.
On Dec 6, 2016 6:48 PM, "Dan Ackroyd"  wrote:

> On 6 December 2016 at 14:59, Silvio Marijić 
> wrote:
>
> > https://wiki.php.net/rfc/soap_get_location
> > https://github.com/php/php-src/pull/2232
> >
> > Any feedback?
>
> Looks good to me. I'm not entirely sure this needs an RFC, but maybe
> some people have some reason to object to it.
>
> The only other thing to note is that ext/soap is an example of an
> extension that could/should eventually be replaced with a userland
> replacement and removed from core.but that is a task for another
> day.
>
> cheers
> Dan
> Ack
>


Re: [PHP-DEV] [RFC][VOTE] User defined session serializer

2016-12-06 Thread Yasuo Ohgaki
Hi Bob,

On Tue, Dec 6, 2016 at 10:36 PM, Bob Weinand  wrote:
> Am 06.12.2016 um 08:06 schrieb Yasuo Ohgaki :
>
> Hi all,
>
> *snip*
>
> * Why it does not use exception for error?
>
> Session module uses "errors", not "exceptions" basically. Session save
> handler uses "errors" also. We should avoid inconsistency in a module.
> Exception adoption will be addressed and exceptions will be used
> consistent manner by other RFC.
>
>
> This is not session module specific, your interface is specifying a return
> type. Thus this should be enforced on the interface implementation level.
> (I.e. it will be impossible for an user to define a function not having a
> return type of string/array)
>
> Also, if a wrong argument is passed to a function, it should throw a type
> error. Perhaps old modules from pre-PHP 5 do emit warnings or recoverables,
> but we then shall transition from that to TypeError, and definitely use
> TypeError in new functionality.

If we use TypeError for this, session will be the first module that
uses TypeError in module. It may be better to use TypeError with
caution.

Let's have a RFC for exception usage guideline. There isn't clear
consensus how we should use exceptions now. When we have consensus, we
follow the guideline. For the time being, let exception usage is out
of this RFC scope

Since this RFC is targeting master (7.2), we have enough time for
exception adoption.

P.S. I don't like mixing errors and exceptions for submodules,
serialize and save handler. Please note that save handlers raise
"error" for invalid return types currently. If a module should adopt
exception, all applicable errors should be changed to exception at
once, and patch work should be avoided. IMO.

--
Yasuo Ohgaki
yohg...@ohgaki.net

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



Re: [PHP-DEV] php.net mailing setup owner?

2016-12-06 Thread Rasmus Lerdorf
Ecelerity is on osu1php and it is still taking traffic even though the mx
for php.net doesn't point to it. So something somewhere is hardcoded to use
it. But this discussion is better suited for the systems@ list.