That's what Ralf and I suggested all along. By the way, the problem is
that most of the web developers don't know anything about IT. I guess
most of them use Windows (and you can't expect a Windows user to
compile stuff), and the majority of the other half uses Ubuntu and
never even saw the shell,
That's what Ralf and I suggested all along. By the way, the problem is
that most of the web developers don't know anything about IT. I guess
most of them use Windows (and you can't expect a Windows user to
compile stuff), and the majority of the other half uses Ubuntu and
never even saw the
Dan, I'm a PHP developer myself too and I always compile PHP and Apache for
my own (PostgreSQL is good for me as it's packaged for Archlinux). But the
majority is just dumb. And you're right about the bug reports, lots of them
would be just like it doesn't work because of reasons. But they'd at
Gustavo Lopes wrote:
I've opened the vote for the remove calls from incompatible context RFC:
https://wiki.php.net/rfc/incompat_ctx#vote
FINALLY realised why this was an itch I had to scratch.
Why just pick on one aspect of E_STRICT ? Surely the end point should be
removing all of the
On Wed, Jan 30, 2013 at 10:50 AM, Lester Caine les...@lsces.co.uk wrote:
Gustavo Lopes wrote:
I've opened the vote for the remove calls from incompatible context RFC:
https://wiki.php.net/rfc/**incompat_ctx#votehttps://wiki.php.net/rfc/incompat_ctx#vote
FINALLY realised why this was an
XDebug together with an opcode cache is always a shaky thing and not
something we should be too concerned about. You would never want to
run both in production. It would be good if they didn't clobber each
other for dev environment purposes, but I am sure we can figure that
out.
This
Stas Malyshev wrote:
The TS model in php should be redesigned in the next major version,
instead of simply giving it up.
Again, I'd not mind seeing this redesign, but do we have somebody who's
actually going to do that?
Ignoring the problem of 'someone to do it', in this age of multi-core
On Wed, Jan 30, 2013 at 11:33 AM, Lester Caine les...@lsces.co.uk wrote:
Stas Malyshev wrote:
The TS model in php should be redesigned in the next major version,
instead of simply giving it up.
Again, I'd not mind seeing this redesign, but do we have somebody who's
actually going to do
Hi,
I wonder if PHP supports PTY? I see old codes (from 2004 to 2010) using
proc_open with $descriptors = [[0 = 'pty']] for example. When I try, I
have an error because PTY seems to not be supported. ./configure does
not propose me to --enable-pty as I have seen in some related posts.
On Wed, Jan 30, 2013 at 11:51 AM, Ivan Enderlin @ Hoa
ivan.ender...@hoa-project.net wrote:
Hi,
I wonder if PHP supports PTY? I see old codes (from 2004 to 2010) using
proc_open with $descriptors = [[0 = 'pty']] for example. When I try, I
have an error because PTY seems to not be supported.
On 1/17/2013 12:20 PM, Clint Priest wrote:
I'm happy to say that Property Accessors is ready for a vote for
inclusion in 5.5 release.
Nikita and I (as well as Stas a bit) have all been working hard to
make this happen for 5.5, voting and the specifications are here:
-Original Message-
From: Pierre Joye [mailto:pierre@gmail.com]
Sent: Wednesday, January 30, 2013 8:10 AM
To: Stas Malyshev
Cc: Zeev Suraski; PHP internals
Subject: Re: [PHP-DEV] ZTS - why are you using it?
On Wed, Jan 30, 2013 at 2:15 AM, Stas Malyshev smalys...@sugarcrm.com
On 1/29/2013 6:54 PM, Stas Malyshev wrote:
Hi!
I think having stuff on the wiki is nice, but for things related to the
code - e.g., APIs, builds descriptions, etc. - they should stay in the
code. They are easier to find there and easier to keep up-to-date, and
also ensure they have the content
PHP is currently susceptible to the DoS attack described here:
http://www.ietf.org/mail-archive/web/tls/current/msg07553.html
Obviously this is a fairly narrow scenario, it only comes into play when PHP is
acting as a socket server providing secure connectivity, it is not the
responsibility of
On 30/01/13 11:58, Ferenc Kovacs wrote:
On Wed, Jan 30, 2013 at 11:51 AM, Ivan Enderlin @ Hoa
ivan.ender...@hoa-project.net wrote:
Hi,
I wonder if PHP supports PTY? I see old codes (from 2004 to 2010) using
proc_open with $descriptors = [[0 = 'pty']] for example. When I try, I
have an error
On Wed, Jan 30, 2013 at 12:45 PM, Ivan Enderlin @ Hoa
ivan.ender...@hoa-project.net wrote:
On 30/01/13 11:58, Ferenc Kovacs wrote:
On Wed, Jan 30, 2013 at 11:51 AM, Ivan Enderlin @ Hoa
ivan.ender...@hoa-project.net wrote:
Hi,
I wonder if PHP supports PTY? I see old codes (from 2004 to
On Wed, Jan 30, 2013 at 12:53 PM, Ferenc Kovacs tyr...@gmail.com wrote:
On Wed, Jan 30, 2013 at 12:45 PM, Ivan Enderlin @ Hoa
ivan.ender...@hoa-project.net wrote:
On 30/01/13 11:58, Ferenc Kovacs wrote:
On Wed, Jan 30, 2013 at 11:51 AM, Ivan Enderlin @ Hoa
On 29/01/2013 09:03, Zeev Suraski wrote:
I’m creating a new one,
based on the apparent level of interest in ZTS. This isn’t an RFC to
remove ZTS by any stretch, but I **am** a bit confused about why people are
still using ZTS.
Personally because runkit sandbox requires it, amongst other
On Tue, 22 Jan 2013 18:23:59 +0100, Gustavo Lopes glo...@nebm.ist.utl.pt
wrote:
https://wiki.php.net/rfc/sendrecvmsg
The module ext/sockets, a wrapper around the sockets API, does not
include support to recvmsg() and sendmsg(). This RFC addresses this
shortcoming by support introducing
Hi Guys,
As a heavy user of ZTS in multi threaded C/C++ applications, here are my $0.02.
Removing ZTS would be a bad idea for all those custom multi-threaded
applications out there that allow some form of internal/embedded PHP scripting.
These applications are not web-servers but do make use
-Original Message-
From: Bas van Beek [mailto:b...@tobin.nl]
Sent: Wednesday, January 30, 2013 2:29 PM
To: Zeev Suraski
Cc: Pierre Joye; Stas Malyshev; PHP internals
Subject: Re: [PHP-DEV] ZTS - why are you using it?
Hi Guys,
As a heavy user of ZTS in multi threaded C/C++
Seeing as it doesn't break BC, and could be quite useful I don't see why
you shouldn't merge it.
On Wed, Jan 30, 2013 at 8:25 AM, Gustavo Lopes glo...@nebm.ist.utl.ptwrote:
On Tue, 22 Jan 2013 18:23:59 +0100, Gustavo Lopes glo...@nebm.ist.utl.pt
wrote:
Op 30 jan. 2013, om 13:42 heeft Zeev Suraski het volgende geschreven:
-Original Message-
From: Bas van Beek [mailto:b...@tobin.nl]
Sent: Wednesday, January 30, 2013 2:29 PM
To: Zeev Suraski
Cc: Pierre Joye; Stas Malyshev; PHP internals
Subject: Re: [PHP-DEV] ZTS - why are you using
On Wed, Jan 30, 2013 at 1:42 PM, Zeev Suraski z...@zend.com wrote:
In case I wasn't sufficiently clear, I'm talking about putting PHP inside
a *multithreaded web server*, not being a good idea.
It makes no sense where FPM is supported, or little sense.
The use case you
specify is exactly
Hi
2013/1/30 Stas Malyshev smalys...@sugarcrm.com:
How it's more outside product than any of the other extensions we
brought to the core?
Because it was not developed at php.net for example? How many
extensions thats in the core today was not developed somewhere at
php.net, or was either in
This is the kind of info the RFC (and then user doc) should have.
I updated the RFC with two extra sections - 'what's an opcode cache', and
'interaction with other plugins'.
https://wiki.php.net/rfc/optimizerplus
Zeev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe,
Hi Zeev,
Specifically would it continue to work with the Zend Guard decoder (as it does
now)?
Thanks,
John.
-Original Message-
From: Zeev Suraski [mailto:z...@zend.com]
Sent: 30 January 2013 14:48
To: Christopher Jones
Cc: internals@lists.php.net
Subject: RE: [PHP-DEV] [RFC]
- Ursprüngliche Message -
Von: Stas Malyshev smalys...@sugarcrm.com
Gesendet: 0:00 Mittwoch, 30.Januar 2013
Betreff: Re: [PHP-DEV] echo new SplFileObject(__FILE__);
__toString is mapped to current() for SplFileObject:
http://www.php.net/manual/en/splfileobject.current.php
On 30 בינו 2013, at 16:57, John Carter jcar...@identitynetworks.com wrote:
Hi Zeev,
Specifically would it continue to work with the Zend Guard decoder (as it
does now)?
Our (Zend's) goal would be yes.
Zeev
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
To be honest, it looks like __toString() was just added in there for the
sake of it without any real thought as to what casting an entier
SplFileObject to a string. This to me implies the entire object( i.e: the
entire file ) should be returned as a string rather than aliasing it to a
method
On Wed, Jan 30, 2013 at 4:44 PM, hakre hanskren...@yahoo.de wrote:
- Ursprüngliche Message -
Von: Stas Malyshev smalys...@sugarcrm.com
Gesendet: 0:00 Mittwoch, 30.Januar 2013
Betreff: Re: [PHP-DEV] echo new SplFileObject(__FILE__);
__toString is mapped to current() for
- Weitergeleitete Message -
Von: hakre hanskren...@yahoo.de
An: Zeev Suraski z...@zend.com
CC:
Gesendet: 17:09 Mittwoch, 30.Januar 2013
Betreff: Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP
distribution
- Ursprüngliche Message -
Von: Zeev Suraski
Von: Paul Dragoonis dragoo...@gmail.com
Gesendet: 16:54 Mittwoch, 30.Januar 2013
To be honest, it looks like __toString() was just added in there for the sake
of it without any real thought as to what casting an entier SplFileObject to a
string. This to me implies the entire object( i.e:
* In that RFC you write:
the integration won’t happen before late 2014. [if it's not bundled
with PHP 5.5]
Can you please outline why?
Based on an 18 month release cycle, and assuming we release 5.5.0 in mid
2013, 5.6.0 will come out late 2014.
Especially does it mean you stop
On Wed, Jan 30, 2013 at 5:47 PM, Zeev Suraski z...@zend.com wrote:
* In that RFC you write:
the integration won’t happen before late 2014. [if it's not bundled
with PHP 5.5]
Can you please outline why?
Based on an 18 month release cycle, and assuming we release 5.5.0 in mid
2013,
Hi!
But this isn't that strong of an argument, and I think that following
what SplFileInfo does would be more sensible (echoing the filename), but
I'm not sure change would worth breaking BC for.
I don't see why it would be more sensible. It's different objects that
do different things - Info
-Original Message-
From: Pierre Joye [mailto:pierre@gmail.com]
Sent: Wednesday, January 30, 2013 7:22 PM
To: Zeev Suraski
Cc: hakre; PHP internals
Subject: Re: [PHP-DEV] [RFC] Integrating Zend Optimizer+ into the PHP
distribution
On Wed, Jan 30, 2013 at 5:47 PM, Zeev Suraski
Hi!
Because it was not developed at php.net for example? How many
I'm not sure what is the meaning here. Nothing is developed at
php.net, strictly speaking. php.net doesn't have its own development
team that works exclusively for php.net, it just gets code contributions
from volunteers. And
2013.01.30. 19:16, Stas Malyshev smalys...@sugarcrm.com ezt írta:
Hi!
But this isn't that strong of an argument, and I think that following
what SplFileInfo does would be more sensible (echoing the filename), but
I'm not sure change would worth breaking BC for.
I don't see why it would
I also agree that we don't need to fix this, nor break BC. It is confusing
as hell but it's there now and changing it would be more disruptive.
Is there a desire from anyone to gracefully throw E_DEPRECATED in a future
version of PHP 5.x when someone tries to __toString() the SplFileObject but
On 30 January 2013 18:48, Paul Dragoonis dragoo...@gmail.com wrote:
Is there a desire from anyone to gracefully throw E_DEPRECATED in a future
version of PHP 5.x when someone tries to __toString() the SplFileObject but
only get back a single line ?
Absolutely not.
--
PHP Internals - PHP
Hi,
we have an open PR for a new SSL stream context option to prevent the CRIME
attack vendor. Anybody with more familiar knowledge of SSL should have a look:
https://github.com/php/php-src/pull/269
cu,
Lars
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
Rebuttal inline... - and better solution at end...
On Tuesday, January 29, 2013 01:46 PM, Stas Malyshev wrote:
Hi!
I've used this in other places, it's basically lightweight traits, and
has always been perfectly valid code. There does not seem to be a clear
justification for deprecating it
Hi!
I did a testable version in javascript the other day. - it's similar to
this..
Javascript is not really an OO language. It has objects, but it doesn't
really follow or enforce any of OO paradigms. It's prototype-based, so
things work differently there.
An almost secret vote, that as I
Top posting as the discussion was going a bit off topic. (Yes there was
a vote, but the rfc could do with some refinements.)
This is an illustration of the proposed change to the RFC, and the
absurdity of how trait's allow incompatible scopes, and give no similar
warning
Example1 -
If addPreserveText() uses anything from Footer, it should not be called
from TextRun, but if it does not, it should be in Section.
No, if it was in Section, all the child classes would have to override
it and throw errors. That results in quite a bit of pointless
boilerplate code to solve a
Some of us have rather large bodies of code written over 10-12 years
that make significant use of calling $this from incompatible
contexts (i.e. we know it's compatible, but php doesn't).
Most consider such use a sin.
Could there be a compromise that would allow us evildoers to continue in
our
47 matches
Mail list logo
