Hey:
There are some PRs for supports of PowerPC64
https://github.com/php/php-src/pull/734
https://github.com/php/php-src/pull/735
https://github.com/php/php-src/pull/736
https://github.com/php/php-src/pull/737
Anyone can review them?
or, I will commit the patches by
Thanks for catching this. I'm fixing it.
Dmitry.
On Mon, Aug 18, 2014 at 5:57 AM, Andrea Faulds wrote:
> Hi!
>
> In _z_param_long in Zend/zend_API.h:
>
> if (EXPECTED(Z_TYPE_P(arg) == IS_LONG)) {
> if (strict && UNEXPECTED(Z_DVAL_P(arg) > LONG_MAX)) {
>
Hi,
> Hi,
>
> I'm trying to call a function inside a module, a PHP_FUNCTION.
>
> Other than zend_eval_stringl, what's the direct way to do it?
Please refer to call_user_function and call_user_function_ex.
>
>
> --
> Best Regards,
> Aaron Lewis - PGP: 0x13714D33 - http://pgp.mit.edu/
> Finger
Hi,
I'm trying to call a function inside a module, a PHP_FUNCTION.
Other than zend_eval_stringl, what's the direct way to do it?
--
Best Regards,
Aaron Lewis - PGP: 0x13714D33 - http://pgp.mit.edu/
Finger Print: 9F67 391B B770 8FF6 99DC D92D 87F6 2602 1371 4D33
--
PHP Internals - PHP Runt
Hi!
In _z_param_long in Zend/zend_API.h:
if (EXPECTED(Z_TYPE_P(arg) == IS_LONG)) {
if (strict && UNEXPECTED(Z_DVAL_P(arg) > LONG_MAX)) {
*dest = LONG_MAX;
} else if (strict && UNEXPECTED(Z_DVAL_P(arg) < LONG_MIN)) {
On Sun, Aug 17, 2014 at 5:13 PM, Stas Malyshev wrote:
> Hi!
>
>> It does, but maybe you missed it. Under the Proposal section:
>>
>>> To solve this, we relax the current invariant of scoped closures
>>> having to be bound, and add a new parameter to bind(To) to produce
>>> an unbound, scoped closu
Hi!
> It does, but maybe you missed it. Under the Proposal section:
>
>> To solve this, we relax the current invariant of scoped closures
>> having to be bound, and add a new parameter to bind(To) to produce
>> an unbound, scoped closure, like so:
Indeed, I missed it - I was looking for bindTo.
On 17 Aug 2014, at 20:33, Andrea Faulds wrote:
> https://wiki.php.net/rfc/closure_apply#vote
>
> The vote ends 2014-08-17. The Function Referencing as Closures RFC is not yet
> being put to a vote.
I cancelled the vote as I’ve changed what the RFC does after some discussion.
Instead of havin
On 17 Aug 2014, at 22:36, Levi Morrison wrote:
> I have a small clarification question on the RFC: you are adding
> another parameter to bindTo which defaults to false, but I didn't
> quite understand the reasoning. Can you try explaining that to me in a
> different way?
I’ll give it a go.
Clo
Hi!
> I have a small clarification question on the RFC: you are adding
> another parameter to bindTo which defaults to false, but I didn't
> quite understand the reasoning. Can you try explaining that to me in a
> different way?
Interestingly enough, the RFC doesn't even mention this change.
--
2014-08-17 23:55 GMT+03:00 Chris Wright :
> Personally my ideal option would be to deprecate $_POST and $_GET in
> favour of $_BODY and $_QUERY, respectively, which would be populated
> the same way regardless of the request method (not just PUT and POST).
> Similarly $_FILES would be populated for
I have a small clarification question on the RFC: you are adding
another parameter to bindTo which defaults to false, but I didn't
quite understand the reasoning. Can you try explaining that to me in a
different way?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: h
On 17 August 2014 11:49, David Zuelke wrote:
> That does not make any sense; applications could accept XML, CSV or whatever
> else just as well.
>
> The original proposal is not very useful. $_GET contains parsed query string
> info, $_POST contains parsed HTTP request body information if the me
On 8/17/14, 1:18 PM, Sara Golemon wrote:
> On Sun, Aug 17, 2014 at 12:58 PM, Marc Bennewitz wrote:
>> I've created a draft RFC and patch to change the behavior of non-strict
>> string to string comparison to be binary safe (as the strict comparison
>> operator does):
>>
>> https://wiki.php.ne
Type juggling is a (major) feature of PHP which would effectively be
neutered by this change. As Sara mentioned we already have tools to achieve
binary and string comparison.
On Aug 17, 2014 4:19 PM, "Sara Golemon" wrote:
> On Sun, Aug 17, 2014 at 12:58 PM, Marc Bennewitz wrote:
> > I've created
On Sun, Aug 17, 2014 at 12:58 PM, Marc Bennewitz wrote:
> I've created a draft RFC and patch to change the behavior of non-strict
> string to string comparison to be binary safe (as the strict comparison
> operator does):
>
> https://wiki.php.net/rfc/binary_string_comparison
>
If I understand
As a variant, not to create a new super global variables, can be
modified $_REQUEST to OOP style
class _REQUEST implements ArrayAccess // for backward compatibility
{
}
// get as array, from body request
$_REQUEST->body
// get all http request headers
$_REQUEST->headers
// get method requ
Hi internals!
I've created a draft RFC and patch to change the behavior of non-strict
string to string comparison to be binary safe (as the strict comparison
operator does):
https://wiki.php.net/rfc/binary_string_comparison
On comparing two numeric strings both operands will be equal if
Good evening,
I’ve updated the patch to work with phpng, so the Closure::call() RFC has been
put to a vote:
https://wiki.php.net/rfc/closure_apply#vote
The vote ends 2014-08-17. The Function Referencing as Closures RFC is not yet
being put to a vote.
Thanks!
--
Andrea Faulds
http://ajf.me/
On 15/08/2014 01:46, Yasuo Ohgaki wrote:
On Wed, Jul 30, 2014 at 9:35 PM, Rowan Collins
mailto:rowan.coll...@gmail.com>> wrote:
Making small changes, such as extra function aliases, or identical
versions of existing functions with switched parameter order, just
adds to the overall c
On Fri, Aug 15, 2014 at 11:57 AM, Marc Bennewitz wrote:
> shouldn't it be merged into the branches PHP-5.4, PHP-5.5 as well as
> PHP-5.6 and shouldn't there an info in the NEWS file? It's currently
> only merged to master.
>
I opted for master-only on the grounds that while it's an improvement,
it
2014-08-17 12:22 GMT+03:00 Ferenc Kovacs :
>
>
>
> On Sun, Aug 17, 2014 at 12:41 AM, Park Framework > wrote:
>
>> This is necessary for convenient use RESTful API.
>>
>> file_get_contents('php://input') - Very inconvenient
>>
>> I would like to finally get native support for PHP, preferably vers
On Sun, Aug 17, 2014 at 12:49 PM, David Zuelke wrote:
> That does not make any sense; applications could accept XML, CSV or whatever
> else just as well.
>
> The original proposal is not very useful. $_GET contains parsed query string
> info, $_POST contains parsed HTTP request body information
That does not make any sense; applications could accept XML, CSV or whatever
else just as well.
The original proposal is not very useful. $_GET contains parsed query string
info, $_POST contains parsed HTTP request body information if the media type is
application/x-www-urlencoded or multipart/
On 15.08.2014 22:39, Andrea Faulds wrote:
On 15 Aug 2014, at 19:57, Marc Bennewitz wrote:
Sara,
shouldn't it be merged into the branches PHP-5.4, PHP-5.5 as well as
PHP-5.6 and shouldn't there an info in the NEWS file? It's currently
only merged to master.
Marc
There might be an argumen
Sorry , make worked after ./buildconf and configure
On Sun, Aug 17, 2014 at 12:35 PM, marius adrian popa wrote:
> This is on debian sid x64
>
> date/php_date.c:21:
> /home/mariuz/work/php-src/main/php_stdint.h:88:4: error: #error "No
> suitable 16bit integer type found"
> # error "No suitable 1
This is on debian sid x64
date/php_date.c:21:
/home/mariuz/work/php-src/main/php_stdint.h:88:4: error: #error "No
suitable 16bit integer type found"
# error "No suitable 16bit integer type found"
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/
Hi,
I'm planning to release 5.6.0 from RC4 if nothing serious comes up, so this
is just a heads-up: if you think that there is some fix, which should make
into the 5.6.0 final (which isn't in RC4) or if you think that there is
some blocker issue which should be solved before the 5.6.0 final releas
On Sun, Aug 17, 2014 at 12:41 AM, Park Framework
wrote:
> This is necessary for convenient use RESTful API.
>
> file_get_contents('php://input') - Very inconvenient
>
> I would like to finally get native support for PHP, preferably version 5.6
>
feel free to create an rfc/implementation, I don'
29 matches
Mail list logo
