Hi Yasuo!
On 17 September 2013 21:17, Yasuo Ohgaki yohg...@ohgaki.net wrote:
Hi all,
SG(request_info).post_data/raw_post_data is removed and modules supposed to
read it from stream on master.
Did the suggestion from UPGRADING.INTERNALS to use the php://input
wrapper work out for you? Maybe
missing any real-world examples of why it might be useful
One thing the I have run across in making my libraries, is the not being
able to call a function `default`.
I use the chainable getter/setter in one syntax a lot (a la jQuery). Hence
when I have a class with a property named default, and
*Should have been !== null
On Wed, Sep 18, 2013 at 7:27 PM, David Neilsen da...@pan.co.nz wrote:
missing any real-world examples of why it might be useful
One thing the I have run across in making my libraries, is the not being
able to call a function `default`.
I use the chainable
Hi Internals.
How do you feel about expanding the is_* functions to accept multiple
parameters similar to the way isset() already does?
From the manual: If multiple parameters are supplied then isset() will
return TRUE only if all of the parameters are set. Evaluation goes from
left to right and
On Wednesday, September 18, 2013 at 12:53 PM, Leigh wrote:
Hi Internals.
How do you feel about expanding the is_* functions to accept multiple
parameters similar to the way isset() already does?
From the manual: If multiple parameters are supplied then isset() will
return TRUE only if all
On Thu, Aug 29, 2013 at 11:33 AM, Nikita Popov nikita@gmail.com wrote:
Hi internals!
This is a spinoff from the variadics thread. Quoting Stas:
I also think this:
public function query($query, ...$params)
public function query(...$params)
should be legal too.
This is a
On Sep 18, 2013, at 11:53 AM, Leigh lei...@gmail.com wrote:
Hi Internals.
How do you feel about expanding the is_* functions to accept multiple
parameters similar to the way isset() already does?
...
Thoughts?
For isset() there is a good reason to do this, because the var might not
Am 18.09.2013 um 09:28 schrieb David Neilsen da...@pan.co.nz:
missing any real-world examples of why it might be useful
One thing the I have run across in making my libraries, is the not being
able to call a function `default`.
I use the chainable getter/setter in one syntax a lot (a la
2013/9/18 Igor Wiedler i...@wiedler.ch
On Sep 18, 2013, at 11:53 AM, Leigh lei...@gmail.com wrote:
Hi Internals.
How do you feel about expanding the is_* functions to accept multiple
parameters similar to the way isset() already does?
...
Thoughts?
For isset() there is a good
function doStuffWithNumbers(...$numbers) {
if (!is_int(...$numbers)) {
throw new InvalidArgumentException('blah');
...
Thoughts?
Returning bool in this case will make it impossible to respond with a
meaningful error message. Which of the provided arguments !is_int()?
Instead,
Hi Bob, thanks for the RFC!
For those of us that use token_get_all(), will the newly allowed token
appear as T_STRING or as T_%KEYWORD%?
May I suggest you add a word about it in the RFC?
As Ryan pointed out in the other thread, a T_%KEYWORD% has a high chance to
break existing documentation
On Thu, Aug 29, 2013 at 11:33 AM, Nikita Popov nikita@gmail.com wrote:
Hi internals!
This is a spinoff from the variadics thread. Quoting Stas:
I also think this:
public function query($query, ...$params)
public function query(...$params)
should be legal too.
This is a
On 18 September 2013 12:15, Igor Wiedler i...@wiedler.ch wrote:
for is_* functions, this could easily be done with a higher-order every
function. You pass a predicate and an array of values. It returns a boolean.
Example:
if (!every('is_int', $numbers)) {
throw new
Am 18.09.2013 um 14:30 schrieb Nicolas Grekas nicolas.grekas+...@gmail.com:
Hi Bob, thanks for the RFC!
For those of us that use token_get_all(), will the newly allowed token
appear as T_STRING or as T_%KEYWORD%?
May I suggest you add a word about it in the RFC?
As Ryan pointed out in
i.e. is_null($a, $b, $c) would be the same as is_null($a) is_null($b)
is_null($c)
Note that this would not be semantically equivalent in this form, even if
`is_null()` did accept multiple parameters, because of the short-circuiting
with ``:
?php
function are_null() {
foreach
I like the naming convention of are_*. For me personally it isn't directly
intuitive that the multiple parameters of is_* would be compared with an
and not an ||.
On Wed, Sep 18, 2013 at 7:50 AM, Sean Coates s...@seancoates.com wrote:
i.e. is_null($a, $b, $c) would be the same as
On Tue, Sep 17, 2013 at 08:28:58AM +0200, Remi Collet wrote:
Please... don't rely, for distro packaged PHP on configure option listed
in phpinfo report [1].
Additional Modules
Module Name
readline
readline extension doesn't use readline library (under incompatible
Le 18/09/2013 16:04, Alain Williams a écrit :
What is needed is for this to NOT be called if the standard output is not
connected to a tty.
From your previous message:
ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo
...}) = 0
ioctl(0, SNDCTL_TMR_STOP or
On Wed, Sep 18, 2013 at 04:13:39PM +0200, Remi Collet wrote:
Le 18/09/2013 16:04, Alain Williams a écrit :
What is needed is for this to NOT be called if the standard output is not
connected to a tty.
From your previous message:
ioctl(0, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400
http://news.php.net/php.internals/23254
-ralph
On 9/16/13 7:53 AM, Bob Weinand wrote:
Hi!
This is the (official) RFC thread for the patch proposed in
http://php.markmail.org/message/7rn4mbwkbytqa3ig
https://wiki.php.net/rfc/keywords_as_identifiers
Any feedback about the RFC or the
On Wed, Sep 18, 2013 at 4:20 PM, Alain Williams a...@phcomp.co.uk wrote:
On Wed, Sep 18, 2013 at 04:13:39PM +0200, Remi Collet wrote:
Le 18/09/2013 16:04, Alain Williams a écrit :
What is needed is for this to NOT be called if the standard output is
not
connected to a tty.
From
2013/9/18 Sean Coates s...@seancoates.com:
i.e. is_null($a, $b, $c) would be the same as is_null($a) is_null($b)
is_null($c)
Note that this would not be semantically equivalent in this form, even if
`is_null()` did accept multiple parameters, because of the short-circuiting
with ``:
Not a good idea IMHO: it would complexify the execution a lot, think about:
To be clear, I wasn't proposing an alternative. I was just pointing out that
function call semantics are not the same as conditional (short-circuit)
semantics, as they appeared in the OP.
S
--
PHP Internals - PHP
2013/9/18 Chris London m...@chrislondon.co:
I like the naming convention of are_*. For me personally it isn't directly
intuitive that the multiple parameters of is_* would be compared with an
and not an ||.
isset() already operates that way, keeping is_ and implementing it
as originally
2013/9/18 Sean Coates s...@seancoates.com:
Not a good idea IMHO: it would complexify the execution a lot, think about:
To be clear, I wasn't proposing an alternative. I was just pointing out that
function call semantics are not the same as conditional (short-circuit)
semantics, as they
Am Mittwoch, 18. September 2013 um 16:29 schrieb Ralph Schindler:
http://news.php.net/php.internals/23254
-ralph
On 9/16/13 7:53 AM, Bob Weinand wrote:
Hi!
This is the (official) RFC thread for the patch proposed in
http://php.markmail.org/message/7rn4mbwkbytqa3ig
On Wed, Sep 18, 2013 at 04:33:50PM +0200, Julien Pauli wrote:
One could use ltrace -l to trace library calls.
On my laptop (Debian) :
ltrace -l /usr/lib/x86_64-linux-gnu/libedit.so.2 php -a
using_history(1, 38, 0x25000f, 712, 0x1087900) = 0
Interactive shell
On 18 September 2013 14:50, Sean Coates s...@seancoates.com wrote:
i.e. is_null($a, $b, $c) would be the same as is_null($a) is_null($b)
is_null($c)
Note that this would not be semantically equivalent in this form, even if
`is_null()` did accept multiple parameters, because of the
Am 18.9.2013 um 18:09 schrieb Leigh lei...@gmail.com:
On 18 September 2013 14:50, Sean Coates s...@seancoates.com wrote:
i.e. is_null($a, $b, $c) would be the same as is_null($a) is_null($b)
is_null($c)
Note that this would not be semantically equivalent in this form, even if
`is_null()`
Hi Bob:
It's now only for class/interface/trait, label and method names.
Sure, that's not as bad.
A bigger concern of mine is the added compatibility problem with new
code possibly not being able to run on older PHP versions. That cost
seems greater than the benefit of some developers being
Hi Bob:
Well, that makes no sense. Then you just could say no to all new
language changes. Because it cannot be run on older versions.
Allow me one last post to clarify. What I said is the cost in _this_
case doesn't outweigh the advantages.
As someone who writes a lot of open source (and
On 18/09/2013 19:25, Daniel Convissor wrote:
Allow me one last post to clarify. What I said is the cost in _this_
case doesn't outweigh the advantages. As someone who writes a lot of
open source (and proprietary) code that gets run on machines that I
have no control over, implementing this
Am 18.9.2013 um 19:53 schrieb Daniel Convissor
dani...@analysisandsolutions.com:
Hi Bob:
It's now only for class/interface/trait, label and method names.
Sure, that's not as bad.
A bigger concern of mine is the added compatibility problem with new
code possibly not being able to run on
Hi Bob:
Well, that makes no sense. Then you just could say no to all new
language changes. Because it cannot be run on older versions.
Allow me one last post to clarify. What I said is the cost in _this_
case doesn't outweigh the advantages.
As someone who writes a lot of open source
On Wed, Sep 18, 2013 at 2:25 PM, Daniel Convissor
dani...@analysisandsolutions.com wrote:
As someone who writes a lot of open source (and proprietary) code that
gets run on machines that I have no control over, implementing this
proposal will complicate my life. Every time I make a function
On Sep 18, 2013 10:53 AM, Daniel Convissor
dani...@analysisandsolutions.com wrote:
Hi Bob:
It's now only for class/interface/trait, label and method names.
Sure, that's not as bad.
A bigger concern of mine is the added compatibility problem with new
code possibly not being able to run
On 13/09/13 22:10, Lazy wrote:
Hello internals,
I'm trying to fix deadlock in an ancient php 5.2.17, php hangs on
internal libc lock.
From my understanding free is not safe to use in a signal handler, and
this seems to be the issue here.
No, it's not.
On 18 September 2013 18:50, Bob Weinand bobw...@hotmail.com wrote:
At least, from a technical point, evaluating LTR would require to change the
engine
(would be some more complex change as it would require to switch between
contexts
and being able to execute the ZEND_SEND_VAL opcodes one by
Am 18.09.2013 um 21:57 schrieb Leigh lei...@gmail.com:
On 18 September 2013 18:50, Bob Weinand bobw...@hotmail.com wrote:
At least, from a technical point, evaluating LTR would require to change the
engine
(would be some more complex change as it would require to switch between
contexts
On Wed, Sep 18, 2013 at 4:19 PM, Michael Wallner m...@php.net wrote:
Did the suggestion from UPGRADING.INTERNALS to use the php://input
wrapper work out for you? Maybe I should add a comment inline...
Thank you for the tip.
It worked very well.
I read your patch didn't read
On 16/09/13 15:58, Daniel Lowrey wrote:
More generally, PHP's stream encryption aspects are quite poorly
documented. For example, https:// streams disable peer verification by
default. While I understand that this is necessary to provide the easiest
possible user experience for things like
Ángel González wrote:
On 16/09/13 15:58, Daniel Lowrey wrote:
More generally, PHP's stream encryption aspects are quite poorly
documented. For example, https:// streams disable peer verification by
default. While I understand that this is necessary to provide the easiest
possible user
On Thu, Sep 19, 2013 at 8:33 AM, Ángel González keis...@gmail.com wrote:
On 16/09/13 15:58, Daniel Lowrey wrote:
More generally, PHP's stream encryption aspects are quite poorly
documented. For example, https:// streams disable peer verification by
default. While I understand that this is
I would argue that LTR support is also inconsistent / not desired.
If I wrote:
$i = 0;
is_three($i = $i + 1, $i = $i + 1, $i = $i + 1);
I would certainly expect is_three to return false, but I would also expect
$i to contain three. php doesn't normally evaluate arguments lazily, it
would be
I have run all the PHPT tests from the latest master test-pack against builds
with this patch on Windows (all versions 2008+):
I get the same failures I get from recent master builds. The patch doesn't
break anything on Windows.
You can get the PHP builds for Windows with this patch that I used
While we're on the topic, it's actually worse than that. Even if you
turn peer validation and name checking on, PHP can't handle
subjectAltNames in certificates, which causes quite a few failures.
This is incorrect. PHP has supported both the SNI_enabled and
SNI_server_name
SSL context options
46 matches
Mail list logo
