Stanislav Malyshev wrote:
>
>> Please, lets keep 5.x code in 5.x and 6.x code in 6.x, different
>> branches exist for a good reason.
>
> Well, then I guess we shouldn't have (binary) in 5.x?
A lot of functions in PHP 6 are able to take both binary and Unicode
strings and act differently when the
I am not sure why this thread was revived. We decided long ago that we
would have namespaces in PHP 6 barring any nasty technical problems and
assuming a good way to implement it could be found.
And I'll second Tony here and mention that we really could use more
eyeballs on the bug database. I a
Richard Lynch wrote:
> On Sat, November 11, 2006 7:37 am, Rasmus Lerdorf wrote:
>> helping to get rid of bogus reports or translating the really bad
>> reports into a simple reproducable test case is often the part that
>
> This is a plea for not being quite so bogus-trigger-
Richard Lynch wrote:
> On Mon, November 13, 2006 9:29 am, Jochem Maas wrote:
>> that sounds about right. my experience with SimpleXML is that every is
>> either
>> a string, an object, an array depending on how you are looking at it
>> and regardless of
>> the situation auto-casting can be relied o
They are C-level hooks. The various storage mechanisms need to add
support for them in order to expose them to userspace PHP. I added
support in pecl/apc, for example.
See:
http://progphp.com/progress.php
(pick some random file in the 200k size range)
Source at: http://progphp.com/progress.
The main issue, as I already discussed with Andrei (sorry, our
discussions are stealth since I see him almost every day even though I
try hard to avoid him) is how we handle encoding errors if we jit at
runtime and process the entire array at that time. I agree that this is
architecturally the rig
On 08/14/2014 01:43 PM, Keyur Govande wrote:
> Hello,
>
> I've opened https://github.com/php/php-src/pull/770 for patches for bugs
> #65463, #66036. More details in the PR.
>
> The bug is reproducible on PHP 5.4, 5.5 and 5.6 with and without
> --enable-zend-signals.
>
> Please review, I'm hesita
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
On 8/22/14, 11:38 AM, Pierre Joye wrote:
> On Aug 22, 2014 5:33 PM, "Andrea Faulds" wrote:
>>
>>
>> On 22 Aug 2014, at 12:16, Nikita Popov wrote:
>>
>>> As we were not given a chance to resolve this issue before the merge, a
>>> short proposal has been created, which aims to revert all unnecessar
On 8/22/14, 10:46 PM, Pierre Joye wrote:
> In other words, it would be nice to see more developers actually
> porting extensions to realize the amount of changes are introduced by
> NG and by the int64. The sooner is in order of magnitude must larger.
> It is not a bad comment, only a fact. Given t
On 8/22/14, 11:09 PM, Pierre Joye wrote:
> On Sat, Aug 23, 2014 at 8:05 AM, Rasmus Lerdorf wrote:
>> On 8/22/14, 10:46 PM, Pierre Joye wrote:
>>> In other words, it would be nice to see more developers actually
>>> porting extensions to realize the amount of changes a
On 8/22/14, 11:25 PM, Pierre Joye wrote:
> There is. Long is not used anymore. So we can argue about that but
> there is a change and it should be reflected imo.
>
> You still totally ignore any of my other points, which are even more
> important in regard to maintaining one code tree for 5.x and
On Sep 29, 2014, at 04:05, Jan Ehrhardt wrote:
>
> Julien Pauli in php.internals (Mon, 29 Sep 2014 12:50:55 +0200):
>>> On Sun, Sep 28, 2014 at 3:45 PM, Jan Ehrhardt wrote:
>>>
>>> The sources are available at http://windows.php.net/download/
>>> Strange that they did not show up at the non WIN
On 10/10/2014 09:50 AM, Stas Malyshev wrote:
> Hi!
>
>> Can you please elaborate a little ?
>> Doesn't such leak have to be fixed in ext/gmp ?
>
> We clean up the memory at the end of the request. But if the request
> ended abnormally and we had some active gmp objects, with gmp data
> allocated
> On Oct 11, 2014, at 16:47, Kris Craig wrote:
>
>> On Oct 11, 2014 1:52 PM, "Nikita Popov" wrote:
>>
>> Hi internals!
>>
>> We currently have a number of deprecated features, which we likely want to
>> remove in PHP 7. I've created a tracking RFC listing deprecated
>> functionality (if I miss
On 10/14/2014 06:29 AM, Andrea Faulds wrote:
>
> On 14 Oct 2014, at 14:27, Kristopher wrote:
>
>> $_HTTP_REQUEST_BODY and $_HTTP_QUERY_STRING for nostalgia's sake.
>
> Ew, non-superglobals.
>
> But $_REQUEST_BODY and $_QUERY_STRING are a bit lengthy. Perhaps $_QUERY (for
> $_GET) and $_BODY (
On 10/14/2014 09:15 AM, Mike Dugan wrote:
> On October 14, 2014 at 11:57:26 AM, Rasmus Lerdorf (ras...@lerdorf.com
> <mailto:ras...@lerdorf.com>) wrote:
>> On 10/14/2014 06:29 AM, Andrea Faulds wrote:
>> >
>> > On 14 Oct 2014, at 14:27, Kristopher wrote:
On 10/14/2014 10:14 AM, Stas Malyshev wrote:
> Hi!
>
>> IMO, AST, INT64, NG, Uniforme variables style is enough for a new
>> marjor version.. why we still need to wait?
>
> We don't need to just "wait", as sit and do nothing. We need to allocate
> time for other features.
There are also quite a
On 10/14/2014 11:16 AM, Rowan Collins wrote:
> On 14/10/2014 17:18, Rasmus Lerdorf wrote:
>> I think 20+ years of history has proven this to be a non-issue. Of all
>> the things that people get confused by in PHP, $_GET/$_POST are right
>> near the bottom of the list.
>
On 10/14/2014 05:20 PM, Tjerk Meesters wrote:
>
> On 15 Oct 2014, at 01:24, Rasmus Lerdorf wrote:
>
>> On 10/14/2014 10:14 AM, Stas Malyshev wrote:
>>> Hi!
>>>
>>>> IMO, AST, INT64, NG, Uniforme variables style is enough for a new
>>>&g
On 10/16/2014 04:27 AM, Ferenc Kovacs wrote:
> On Fri, Jun 15, 2012 at 3:01 AM, Anthony Ferrara
> wrote:
>
>> Hello all,
>>
>> I raised this topic on list over a year ago (
>> http://marc.info/?l=php-internals&m=130417646507744&w=2 ). It was
>> determined that it wasn't time yet to disable prepar
On 10/16/2014 02:38 PM, Morgan Tocker wrote:
> The more clear cases would be:
> - The prepared statement is reused enough times that the initial extra round
> trip can be amortized.
> - If large place-holder values can be sent direct to the server without
> having to be escaped or parsed. For e
On 10/16/2014 09:10 AM, Ferenc Kovacs wrote:
> I don't think we should remove the option, just change the defaults, and
> most people would be fine switching back to the emulation, but it should
> be their conscious decision imo.
> Currently many people aren't aware that they are using client side
On Oct 17, 2014, at 05:21, Uve Vesterbrandt wrote:
> *_We would be grateful_*
> Can anybody follow our idea? We, as a group mighty like a response to this.
> If anyone has some general ideas for possible solution, it would be funand
> helpfull, but our current project, however, only reveal whethe
https://github.com/php/php-src/blob/master/ext/opcache/zend_accelerator_module.c#L259
That looks suspicious to me and in simple testing doesn't appear to be
the case. I mean, you can set it per-dir, but it doesn't make any
difference at that point. Dmitry, could you go through the list of
opcache
On 11/04/2014 10:08 AM, Andrea Faulds wrote:
>
>> On 4 Nov 2014, at 17:46, Stas Malyshev wrote:
>>
>> Hi!
>>
"public Foo function bar()" would be so much worse than "public function
bar() : Foo"
>>>
>>> Because when you grep for "function bar", in future you'd have to know
>>> the retur
On 11/04/2014 04:42 PM, Levi Morrison wrote:
>>> If we used this syntax instead, which wouldn’t disrupt grep:
>>>
>>> public Foo function bar();
>>>
>>> It’d be inconsistent with normal function declarations which would have to
>>> have Foo after function.
>>
>> I don't understand that inconsi
On 11/04/2014 06:33 PM, Dmitry Stogov wrote:
> Hi Rasmus,
>
> Sorry for delay, I'm just back to work after ZendCon and holidays.
>
> opcache.revalidate_freq is PHP_INI_ALL on purpose.
> Scripts that generate and include the same file again and again should
> set it to 0 to check for modification
> On Nov 7, 2014, at 00:38, Remi Collet wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Le 07/11/2014 07:46, Dmitry Stogov a écrit :
>> Commit:9dfa843a386b65b18353c510f032e322004d0bb7 Author:
>> Dmitry Stogov Fri, 7 Nov 2014 09:46:49
>> +0300 Parents: 0ddcf2a919a24c
On 11/07/2014 06:52 AM, Ferenc Kovacs wrote:
> 5.4 is in security fix mode, let see what Stas thinks about this.
I am not that concerned about 5.4. People should be upgrading. But we
should get this into the next 5.5 and 5.6 releases.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/25/2014 07:37 AM, Scott Arciszewski wrote:
> I would like to, at the minimum, suggest making the following
> functions run in constant time:
>
> * bin2hex() * hex2bin() * base64_encode() * base64_decode() *
> mcrypt_encrypt() -- requires delving
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/26/2014 07:29 AM, Scott Arciszewski wrote:
> http://events.ccc.de/congress/2012/Fahrplan/attachments/2235_29c3-schinzel.pdf
>
> No, a random delay is not sufficient.
Sure, I mentioned that if the scenario allows for lots of observations
then it
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/26/2014 11:45 AM, Anthony Ferrara wrote:
>> That seems like a lot of functions to artificially slow down.
>
> Well, in most cases it shouldn't slow it down by a non-trivial
> margin.
If that can be shown definitively, then I would have fewer ob
On 12/03/2014 01:40 PM, Robert Stoll wrote:
> Heya,
>
>
>
> I would like to know If it is somehow possible to overload existing functions
> by extensions. And if it is possible, are
> there already some extension doing it?
>
> I am not talking about the magic __call function. I am talking ab
On 01/11/2015 06:05 PM, Stanislav Malyshev wrote:
> Hi!
>
>> Also, FWIW, anyone who used the Suhosin patch couldn’t use srand()
>> because it disabled it.
>
> And? You can disable any function in PHP, that doesn't mean anything.
>
>> Because if we don’t break it, people will continue to rely on
On 01/12/2015 01:31 AM, Andrea Faulds wrote:
> Hi Rasmus,
>
>> On 12 Jan 2015, at 09:06, Rasmus Lerdorf wrote:
>>
>> Yes, there is plenty of code out there that relies on srand()+rand()
>> returning a repeatable sequence of pseudo-random numbers. I have written
&
On 01/14/2015 07:24 PM, Xinchen Hui wrote:
> On Thu, Jan 15, 2015 at 1:53 AM, Julien Pauli wrote:
>> I obviously will help porting some of them.
> as I remembered, memcached and redis already be proted by demon at php.net
For memcached, do you mean this pull request?
https://github.com/php-memc
On 01/14/2015 06:05 PM, Dan Ackroyd wrote:
> On 14 January 2015 at 21:21, Michael Wallner wrote:
>> * imagick
>
> Most of the work was done while it was still called NG:
> https://github.com/danack/imagick/tree/phpng . Which means that branch
> probably won't work against master as there have bee
I think this broke usort() of more than 16 elements.
eg.
'aaa', 'date' => 'Oct 8, 2006' ],
[ 'id' => 'bbb', 'date' => 'Nov 14, 2008'],
[ 'id' => 'ccc', 'date' => 'Dec 19, 2014'],
[ 'id' => 'ddd', 'date' => 'Feb 4, 2010'],
[ 'id' => 'eee', 'date' => 'Jul 7, 2013'],
On 01/16/2015 03:54 PM, Simon J Welsh wrote:
> That’s an invalid comparison function. It causes the current usort to reverse
> sort the array and I see no problem with that changing (you’re saying that a
> value for $a less than $b is in fact greater than it, and a value of $b less
> than or equ
On Jan 16, 2015, at 19:18, Xinchen Hui wrote:
>
> Hey:
>
>
>> On Sat, Jan 17, 2015 at 8:20 AM, Rasmus Lerdorf wrote:
>>> On 01/16/2015 03:54 PM, Simon J Welsh wrote:
>>> That’s an invalid comparison function. It causes the current usort to
>>> rev
On Jan 17, 2015, at 17:52, Marcio Almada wrote:
>> Cryptic notation is not a PHP way. IMHO.I like original "default" proposal
>> and it is good enough.
>> Regards,
>
> When I suggested `_` it was more as a feature wandering. I like
> `default` too. The RFC looks good enough as it is now :)
_ i
On 01/18/2015 11:45 AM, Stanislav Malyshev wrote:
> Hi!
>
>> Yes, like I said, I am aware that the comparison function is flaky
>> but it is still code that has worked for 15 years so we have to be
>> clear about the BC break. The fact that it works up until the array
>
> Looking at that function
On 01/18/2015 02:08 PM, Rasmus Lerdorf wrote:
> We have to be really really careful with this "oh, that code is wrong,
> so we can break it argument". This will break hundreds if not thousands
> of sites in a hard-to-debug way. It took me less than a minute of
> looking on
On 01/18/2015 09:00 PM, Andrea Faulds wrote:
> That would also mean a future sorting API could unify user sorts and non-user
> sorts: just make the default callback be cmp().
>
> Usage would be like this:
>
> cmp(1, 2); // 1
> cmp(1, 1); // 0
> cmp(2, 1); // 1
>
> Essentially, exactly like the
In testing PHP7 beyond just the default extensions, I am noticing that
ext/imap is segfaulting on almost every test. I tracked it down to this
code in ext/imap/php_imap.c:
/* {{{ imap_do_open
*/
static void php_imap_do_open(INTERNAL_FUNCTION_PARAMETERS, int persistent)
{
char *mailbox, *u
On 01/20/2015 01:54 PM, Rasmus Lerdorf wrote:
> Things I have tried. changed it from "p" to "s" and also from "p" to "S"
> and using a zend_string * instead. In both cases I got the same bogus
> address back from zpp. Right now I am trying to make s
On 01/20/2015 02:46 PM, Stanislav Malyshev wrote:
> Hi!
>
>> So, I guess the lesson is that we need to be careful when we migrate
>> extensions to PHP 7. Passing ints instead of size_t string length params
>> to zpp can cause extreme weirdness and we should go through all our
>> bundled extensions
By installing a couple of apps (Wordpress-4.1, Drupal8 and Moodle -
there are still some issues in Moodle I haven't figured out yet) on a
box we've tracked down some bugs over the last couple of days. It would
be really useful if we got more eyes on this. Install php7, then install
any random app a
On 01/22/2015 02:30 PM, Dan Ackroyd wrote:
> On 22 January 2015 at 21:07, Lester Caine wrote:
>> imagick is now available?
>
> Not yet. I'll try to finish it off before the end of the weekend. Most
> of the work was done earlier, but I need to add the changes for the
> Native TLS.
>
> btw this r
On 01/26/2015 11:14 AM, Pascal Chevrel wrote:
> Hi all,
>
> I just compiled master to test my main application and the good news is
> that I have no functional regression and some of the views get a
> considerable speed up (like, page generation divided by two!).
>
> I had one unit test failing a
On 01/27/2015 08:55 AM, Dmitry Stogov wrote:
> The patch makes ~1% improvement on Wordpress-3.6 (saving duplication and
> destruction of 200 arrays on each request)
Awesome!
signature.asc
Description: OpenPGP digital signature
As a follow-up to my PHP7 Homework post last week, here is a bit of
spoon-feeding for all you lurkers on this list.
https://atlas.hashicorp.com/rasmus/boxes/php7dev
The description there should be fairly self-explanatory. If you have a
computer running Linux, OSX or Windows and about 4G of disk s
On 01/29/2015 01:32 PM, Yasuo Ohgaki wrote:
> Hi all,
>
> I came across with bug #68947 https://bugs.php.net/bug.php?id=68947
> and realized small inconsistency.
>
> http://3v4l.org/ldZKl
>
> $obj->${array[$key]}; // Syntax error
> $obj->{$array[$key]}; // Works
>
> $obj->${key}; // E_NOTICE. D
On 01/30/2015 02:17 AM, Ralf Becker wrote:
> Tried installing EGroupware (www.egroupware.org) on your vagrant box.
>
> Unfortunately our installation check, checking for various requirements,
> immediately triggers a segmentation fault :-(
>
> ==> /var/log/nginx/php-fpm_error.log <==
> [30-Jan-20
On 01/30/2015 05:06 AM, Rasmus Lerdorf wrote:
> On 01/30/2015 02:17 AM, Ralf Becker wrote:
>> Tried installing EGroupware (www.egroupware.org) on your vagrant box.
>>
>> Unfortunately our installation check, checking for various requirements,
>> immediately tr
There is something weird going on with PHP7 and the moodle_page class
and all its magic methods. It dies with a:
/var/www/moodle/blocks/navigation/block_navigation.php(223) : Notice -
Undefined property: moodle_page::$navigation
/var/www/moodle/blocks/navigation/block_navigation.php(223) : Fatal
e
On 01/30/2015 11:13 PM, Michael Wallner wrote:
>
> On 31 Jan 2015 06:04, "Rasmus Lerdorf" <mailto:ras...@lerdorf.com>> wrote:
>>
>> There is something weird going on with PHP7 and the moodle_page class
>> and all its magic methods. It dies with
On 01/30/2015 09:10 PM, Dmitry Stogov wrote:
> Hi,
>
> Nikita got an idea about stopping changing of array/object internal
> pointers even in forech by reference.
> I've added an additional RFC section:
>
> https://wiki.php.net/rfc/php7_foreach#additional_behavoir_change
>
> Trivial implementati
On 02/02/2015 08:38 AM, François Laupretre wrote:
> Hi,
>
> Opening the vote for :
>
> https://wiki.php.net/rfc/streams-is-cacheable
>
> This RFC proposes a generic way for opcode caches to decide if a given URI
> is cacheable or not.
Doesn't this imply that "path" is the one true cache key? Th
Hey Yasuo, I noticed that you removed the invalid_session_id boolean
from php_session.h. For extensions that do:
PS(invalid_session_id) = 1;
what is the new way for them?
-Rasmus
signature.asc
Description: OpenPGP digital signature
On 02/02/2015 07:35 PM, David Muir wrote:
>
>
>> On 3 Feb 2015, at 3:49 am, Rasmus Lerdorf wrote:
>>
>>> On 02/02/2015 08:38 AM, François Laupretre wrote:
>>> Hi,
>>>
>>> Opening the vote for :
>>>
>>> https://wiki.php.
On 09/17/2012 08:47 AM, Will Fitch wrote:
> I haven't seen a maintenance notification, and it appears git.php.net may
> be down. Anyone else able to reproduce this?
It is down at the moment yes. Slight mixup trying to add some firewall
rules.
-Rasmus
--
PHP Internals - PHP Runtime Development
On 09/18/2012 12:39 PM, Michael Shadle wrote:
> Also as there is also htmlspecialchars() which most people use for escaping
> this seems like a better, more centralized functionality and better
> nomenclature for escaping on output in general with options for various types
> (and should just be
On 09/18/2012 02:21 PM, Stas Malyshev wrote:
> Hi!
>
>> Filter has already gone down this road--I doubt the value added by having a
>> second, much
>> more verbose way to call htmlspecialchars()--but I don't see why we must
>> continue down
>> that path.
>
> So, you don't think there should b
On 09/18/2012 03:28 PM, Pádraic Brady wrote:
> Hi Rasmus,
>
> On Tue, Sep 18, 2012 at 7:34 PM, Rasmus Lerdorf wrote:
>> If we want to add more filters for more specific purposes, I am not
>> completely against it, although the more specific they get the more
>> chur
On 09/18/2012 03:46 PM, Pádraic Brady wrote:
> Bear in mind the RFC, in userland (and likely any PECL ext) implements
> the ESAPI rules. They've been hacked on a lot over the years which is
> why I made sure they were followed exactly. It's very unlikely that a
> browser bug could scupper these unl
On 10/16/2012 02:51 AM, Amaury Bouchard wrote:
> 2012/10/16 Stas Malyshev
>
public DateTime $date;
>>>
>>> This is *real* progress, even if under the hood all it does is wrap
>>
>> I think it's a movement in wrong direction. Again, it is an attempt to
>> make PHP a strongly typed language, w
On 10/18/2012 03:47 AM, Anatoliy Belsky wrote:
> Hi,
>
> as requested in the issue #63284, I've produced a patch for PCRE 8.31
> upgrade. Tests has passed for me on 5.3/5.4/master ts and nts, though
> anybody willing to perform additional tests is welcomed. More tests will
> be performed next days
On 10/18/2012 04:16 PM, David Strauss wrote:
> On Thu, Oct 18, 2012 at 4:06 PM, David Muir wrote:
>> Upstart support would be good to have too.
>
> I'm aware of Upstart having some basic socket activation support, and
> I'm happy to provide advice on the PHP-FPM/Linux side for integrating
> it in
On 10/20/2012 01:59 PM, Nikita wrote:
> Hello, list. I want to propose generics. For those, who don't know what it
> is, here's example: say we have a Comment class, that has a method getBody.
> Also we have Collection class, that implements Traversable. Now, if I want to
> validate all insertio
On 10/25/2012 08:53 AM, Anthony Ferrara wrote:
>> If there are no objections, I'll go ahead and draft an RFC for the
>> notice/docs idea later today. If anyone would like to co-author it with
>> me, please drop me an email and I'll send you the wiki link once I've
>> created the page.
>>
>
> Do
On 10/29/2012 12:20 AM, Laruence wrote:
> Hey:
>is there any change to git box recently?
>
>I got a fail message like:
>
>Total 5 (delta 3), reused 0 (delta 0)
>remote: Shared object "libvpx.so.0" not found, required by "php"To
> g...@git.php.net:php-src.git
This is fixed now.
On 11/05/2012 01:57 AM, Jean-Sébastien Hedde wrote:
> Hi,
>
> I'm facing an issue with preg_match and an UTF8 string.
>
> The pattern is : /^[[:alnum:]\s\-\'%]+$/u
> The string : Régis
>
> If I read the manual preg_match should return 0 ("In UTF-8 mode,
> characters with values greater than 128
On 11/05/2012 08:41 AM, Jean-Sébastien Hedde wrote:
> On Mon, 05 Nov 2012 08:04:06 -0800, Rasmus Lerdorf
> wrote:
>>
>> I think the documentation is wrong on that. In Unicode mode [[:alnum:]]
>> actually becomes \p{Xan} which should match Unicode chars as well, but
>
On 11/12/2012 07:24 AM, Leigh wrote:
> Hi,
>
>> We put ext/mysql in a (security) bug fix maintenance mode only
>> years ago. Too many ignore those attempts to get rid of ext/mysql.
>
> Maybe it's time to put it into full non-maintenance mode then?
>
> I believe MySQL is one of the on-by-default
On 11/15/2012 11:53 AM, Will Fitch wrote:
> On Thu, Nov 15, 2012 at 2:48 PM, Stas Malyshev wrote:
>
>> Hi!
>>
>>> Again, though, this is a long way down the road: today's discussion is
>>> purely about deprecation.
>>
>> So these people using mysql-based code will have for years to live with
>> ap
On 11/15/2012 12:08 PM, Will Fitch wrote:
> On Thu, Nov 15, 2012 at 3:00 PM, Rasmus Lerdorf wrote:
> Actually, no it wouldn't. You still get the overhead of the error, plus
> any custom error handlers will be triggered regardless of the
> error_reporting setting which
On 11/15/2012 01:50 PM, Austen Hoogen wrote:
> The reason to depreciate and/or cease support for a feature (not the same
Pet peeve of mine. The word is deprecate. Depreciate is a financial term.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/un
On 11/15/2012 04:18 PM, Sherif Ramadan wrote:
> On Thu, Nov 15, 2012 at 6:59 PM, Anthony Ferrara wrote:
>
>>
>>
>> If it wasn't that active open source projects still have ext/mysql as their
>> primary connection today, I would agree with you. But we still have open
>> source projects, major ones
On 11/15/2012 05:52 PM, Sherif Ramadan wrote:
> This was the soft-deprecation notice that I believe was discussed
> before the actual steps were to be taken to officially deprecate
> ext/mysql. Yes, it's a suggestion, but a clearly worded suggestion,
> none-the-less. It has been around for a little
On 11/15/2012 11:27 PM, Pierre Joye wrote:
> hi Anthony,
>
> On Thu, Nov 15, 2012 at 9:11 PM, Anthony Ferrara wrote:
>
>>> Actually, no it wouldn't. You still get the overhead of the error, plus
any custom error handlers will be triggered regardless of the
error_reporting setting which
On 11/16/2012 12:51 AM, Patrick ALLAERT wrote:
> Rasmus,
>
> As per the RFC: adding E_DEPRECATED only in mysql_connect(),
> mysql_pconnect(). Which means only one error (normally) by request.
I still don't see the point of using E_DEPRECATED like this for an
entire extension. And I think it will
On 11/16/2012 01:34 AM, Ryan McCue wrote:
> Pierre Joye wrote:
>> Wordpress lead developer statement is rather clear: Go ahead, we will follow.
>
> Indeed, we have patches written already [1], but they were low priority.
> The plan is to aim for landing these in the next major version, assuming
>
On 11/16/2012 02:18 AM, Patrick ALLAERT wrote:
> In eZ Publish CMS, we have recently removed [1] support for the mysql
> handler in favour of the mysqli one and as such, we have no more
> mysql_*() functions calls except for the above use case where we rely
> on mysql_escape().
I suppose you mean
On 11/16/2012 09:32 AM, Patrick ALLAERT wrote:
> 2012/11/16 Rasmus Lerdorf :
>> On 11/16/2012 02:18 AM, Patrick ALLAERT wrote:
>>> In eZ Publish CMS, we have recently removed [1] support for the mysql
>>> handler in favour of the mysqli one and as such, we have no m
On 11/17/2012 07:19 AM, Ángel González wrote:
> On 16/11/12 17:03, Rasmus Lerdorf wrote:
>> So, I am curious, why are you waiting on us for this? Is it because
>> ext/mysql does everything you need and you simply have no need for any
>> of the new and obviously better featur
On 11/17/2012 09:14 AM, Ángel González wrote:
> On 17/11/12 17:24, Rasmus Lerdorf wrote:
>> Being able to fire off your SQL query at the top of a page and then
>> instead of waiting around for the result continue building the page
>> until you get to the point where you nee
On 11/20/2012 09:51 PM, Adam Harvey wrote:
> On 21 November 2012 13:45, Stas Malyshev wrote:
>>> Proposal: I propose we revert this change. Future consideration might
>>
>> I see no reason to revert the change and keep dragging around the GUIDs.
>> Data URLs are much better and cleaner solution, a
On 11/26/2012 05:24 PM, Raymond Irving wrote:
> Hello,
>
> I've being reading about HHVM and the numbers are looking great but I was
> just wondering if we will we ever see something like HHVM being added to
> the PHP core?
No, not likely. Maybe an LLVM-based JIT one day, but the HHVM approach
is
On 11/26/2012 09:03 PM, Sara Golemon wrote:
> P.S. - I do disagree with Rasmus' statement about none of us looking
> at fitting a JIT into PHP. ;)
I think you misread my reply. I specifically said that a JIT is a
possibility, just not the HH approach.
-Rasmus
--
PHP Internals - PHP Runtime Dev
On 11/30/2012 09:15 AM, Dmitry Stogov wrote:
> Hi,
>
> The NEWS and UPGRADING explains the details.
>
> http://pastebin.com/VC71Y8LV
>
> The patch is big, but actually quite simple.
> I'm going to commit it on Monday or Tuesday (if no objections).
>
> I'm going to look into the similar optimiza
On 12/05/2012 05:02 PM, Sara Golemon wrote:
> It's been awhile since I last commited (pre git, in fact) and now I'm
> getting a failure during 'git push'. It asks for my password, I enter
> it, it asks again, I enter again, and I get a permission denied error.
> Do I need to do something to updat
On 12/10/2012 12:59 PM, Tom Boutell wrote:
> Sure. I wasn't asking for myself but rather in the context of how
> close 5.3 is to being reasonable to deprecate.
APC is at the point now for 5.4 where I don't think there are any more
edge cases than we have in 5.3. Neither is perfect, but it is close
On 12/16/2012 12:27 PM, Lester Caine wrote:
> Anthony Ferrara wrote:
>> can we please keep superfluous discussions like coding standards
>> off-list? I
>> have no issue with representation of fig discussion, but whitespace
>> discussions
>> have no place on this list...
>
> The standards being dic
On 12/16/2012 03:20 PM, Lester Caine wrote:
> One gets the impression that it's all too late, so from the other side,
> should all of the core files be changed to follow the new de-facto
> standard? And YES I classify using different white space standards for
> different file formats as more of a
On 12/19/2012 01:39 AM, Dmitry Stogov wrote:
> Hi,
>
> opcode caches support is one of the problem we have with current
> implementation.
> 5.4.10 seems just can't work with any cache at all.
> Of course, I'll care about it, and may give suggestions for necessary
> APC changes.
Do you have an exa
On 12/19/2012 03:27 PM, Stas Malyshev wrote:
> Hi!
>
>> I did come up with a problem in my server crashing with SIGBUS.
>> After long testing/tracing found:
>>
>> https://bugs.php.net/bug.php?id=52752
>
> Just tried to reproduce it on Centos 6.2 install (without APC), works
> just fine for me. I
On 12/20/2012 06:36 AM, Dmitry Stogov wrote:
> Hi Pierre,
>
> The following test may crash on the second request with opcode cache.
>
>
> trait THello {
>
> public function hello() { echo 'Hello'; }
> }
>
> class TraitsTest { use THello; }
>
> $test = new TraitsTest();
> $test->hello();
>
On 12/21/2012 09:28 AM, Dmitry Stogov wrote:
> Hi,
>
> This is more or less final proposed patch for 5.4
>
> http://pastebin.com/ceiWWD4N
>
> It fixes implementation mistakes and makes the whole implementation much
> simpler.
> I hope I didn't introduce new bugs :)
> Of course I checked it with
701 - 800 of 1854 matches
Mail list logo
