On Sun, Mar 28, 2021 at 17:15 Sara Golemon wrote:
> On Sun, Mar 28, 2021 at 6:57 PM Paul Crovella
> wrote:
>
>> You might consider requiring commits be signed while you're at it.
>>
>>
> I suggested this as well, and even if we don't require it, we should
> STRONGLY encourage it.
>
> I've been s
On Sun, Jan 19, 2020 at 4:53 PM Mike Schinkel wrote:
> Also, Rowan Collins mentioned that checks in Go can be disabled for
> runtime checking; maybe we could support an option that disables said
> checking so that production sites could run w/o checks but we could run
> checks in development, tes
Crap, brain freeze. Pushed this patch from the wrong window. Reverting.
-Rasmus
On Wed, Oct 23, 2019 at 2:31 PM Rasmus Lerdorf wrote:
> Commit:5870efbcf5235bb7328fe7cea3b8e2b92fb9fc0d
> Author:Rasmus Lerdorf Wed, 23 Oct 2019
> 14:31:27 -0700
On Tue, Oct 1, 2019 at 8:25 AM Benjamin Morel
wrote:
> > Perhaps a more generic $_SERVER['PHP_REQUEST_STATUS'] or something along
> those lines where you'd put the error message from
> https://www.php.net/manual/en/features.file-upload.errors.php as well.
> And add new states for these exceeded l
On Tue, Oct 1, 2019 at 6:32 AM Benjamin Morel
wrote:
> > We have https://www.php.net/manual/en/features.file-upload.errors.php but
> in general this is not so easy to make more convenient because this runs
> before your PHP code starts to run, so it is not like you can stick it in a
> try/catch.
On Tue, Oct 1, 2019 at 1:00 AM Benjamin Morel
wrote:
> Hi internals,
>
> One thing that always bugged me is how PHP silently ignores data that
> exceeds the limits defined in php.ini.
>
> For example, posting a form exceeding post_max_size results in empty $_POST
> and $_FILES, with no error mess
Lots of drama on internals lately. Not that different from 15-20 years ago.
A couple of things to keep in mind for everyone.
It is not that hard to write a tool that perfectly fits your own needs and
people who are very similar to you in terms of skillset, background and
overall experience. What P
On Sat, Aug 10, 2019 at 5:37 AM Andrea Faulds wrote:
> As the person who initially proposed and implemented strict_types, I
> think this is heading in the wrong direction. Perhaps that directive was
> a mistake, if it will lead to so many attempts inspired by it to
> fragment the language, includ
Christoph, I think we should merge
http://git.php.net/?p=php-src.git;a=commitdiff;h=5c4d125d4c2976236e2ecddd1d8c6e7b113ec482
into 7.3.6.
-Rasmus
On Tue, Apr 2, 2019 at 2:22 AM Anatol Belski wrote:
> On Mon, 2019-04-01 at 13:42 -0700, Rasmus Lerdorf wrote:
> > On Mon, Apr 1, 2019 at 9:25 AM Rasmus Lerdorf
> > wrote:
> >
> > > I've been walking through the PHP 7.2->7.3 ext/dom diffs but I
> > &
On Mon, Apr 1, 2019 at 9:25 AM Rasmus Lerdorf wrote:
> I've been walking through the PHP 7.2->7.3 ext/dom diffs but I don't see
> what has caused this change: https://3v4l.org/hEmmR
> What did I miss?
>
Tracked it down to this bug fix: https://bugs.php.net/76285
-Rasmus
I've been walking through the PHP 7.2->7.3 ext/dom diffs but I don't see
what has caused this change: https://3v4l.org/hEmmR
What did I miss?
-Rasmus
On Sat, Feb 9, 2019 at 4:17 PM Ben Ramsey wrote:
> > On Feb 9, 2019, at 18:15, Stanislav Malyshev
> wrote:
> >
> > Hi!
> >
> > I am trying to access bugs.php.net and I am getting timeouts all the
> > time today (TLS handshake passes, but no content is delivered). Seems to
> > be something wrong
On Fri, Oct 19, 2018 at 1:17 AM, Dmitry Stogov wrote:
>
> I would like to start discussion on a Preloadng RFC
> https://wiki.php.net/rfc/preload
I have been playing with this a bit this weekend.
It is tricky to tell if it is working. I think it would be helpful if the
opcache section on the ph
On Fri, Oct 19, 2018 at 1:17 AM, Dmitry Stogov wrote:
> Hi Internals,
>
> I would like to start discussion on a Preloadng RFC
> https://wiki.php.net/rfc/preload
>
> This technology would allow loading some PHP files on server startup and
> make all the defined classes and functions to be permanen
On Tue, Aug 28, 2018 at 2:52 AM, Jan Ehrhardt wrote:
> https://bugs.php.net/bug.php?id=76743
>
> Are we back?
>
Hopefully. Watching it closely today.
Has been for a while. It is on the same box as lists.php.net which died. We
are working on it.
On Sun, Aug 26, 2018 at 11:40 PM, Stanislav Malyshev
wrote:
> Hi!
>
> Looks like news.php.net is not responding. Anybody could check what's up
> with this?
>
> Thanks,
> --
> Stas Malyshev
> smalys...@
Ok, should be fixed now. https://bugs.php.net/bug.php?id=76553 looks good.
But I think between my backup and the conversion I lost a couple of bug
comments from this morning. Sorry about that.
-Rasmus
On Sat, Jul 21, 2018 at 8:31 AM, Rasmus Lerdorf wrote:
> Uh, ok, something obviously w
Uh, ok, something obviously went wrong there. Checking.
On Sat, Jul 21, 2018 at 8:30 AM, Rasmus Lerdorf wrote:
> For future reference, here is what I did to fix the encoding problem:
>
> MariaDB [phpbugsdb]> select sdesc from bugdb wh
For future reference, here is what I did to fix the encoding problem:
MariaDB [phpbugsdb]> select sdesc from bugdb where id=76553;
++
By the way, the following users have ssh accounts on bugs.php.net:
bjori derick felipe nikic rasmus sas scottmac tyrael
the error log is in /srv/bugs.php.net/logs/error.log
and the code is here: g...@git.php.net:/web/bugs.git
Feel free to log in and fix stuff as you find more issues. Right
it an
ipv6 addr.
On Sat, Jul 21, 2018 at 6:18 AM, Christoph M. Becker
wrote:
> On 21.07.2018 at 12:10, Rasmus Lerdorf wrote:
>
> > Works fine for me on https://bugs.php.net/bug.php?id=76635&thanks=1
>
> I just commented “Testing”, but the comment isn't there. Don
Works fine for me on https://bugs.php.net/bug.php?id=76635&thanks=1
On Sat, Jul 21, 2018 at 6:06 AM, Christoph M. Becker
wrote:
> On 21.07.2018 at 11:51, Rasmus Lerdorf wrote:
>
> > That one should be fixed. It was actually posting the comments, but
> getting
> > an e
That one should be fixed. It was actually posting the comments, but getting
an error after. If you reload the bug you see it.
On Sat, Jul 21, 2018 at 5:41 AM, Christoph M. Becker
wrote:
> On 21.07.2018 at 10:46, Nikita Popov wrote:
>
> > On Tue, Jul 17, 2018 at 10:38 PM, Rasmus Lerd
On Thu, Jul 19, 2018 at 4:45 PM, Hoffman, Zachary Robert
wrote:
> On Thu, 2018-07-19 at 22:35 +0200, Niklas Keller wrote:
> > Hey Rasmus
> >
> > I just found this bug: https://bugs.php.net/bug.php?id=76553
> >
> > Has this bug been like that before the migration, too? Or did
> > something go wron
his in the next day or two unless someone
beats me to it.
-Rasmus
On Thu, Jul 19, 2018 at 4:35 AM, marius adrian popa
wrote:
> Hello Rasmus,
>
> I can't access previous patches
>
> https://bugs.php.net/patch-display.php?bug_id=62300&;
> patch=0&revision=latest
>
> On
I need to move bugs.php.net to another server sometime today. I won't be
able to do it without a little bit of downtime as I have to stop new
activity on the existing box, copy the DB over and then point DNS to the
new box. The DNS TTL is only 5 minutes, so it shouldn't be unavailable for
much long
On Tue, May 1, 2018 at 11:19 AM, Sara Golemon wrote:
> On Tue, Apr 24, 2018 at 1:54 PM, Sara Golemon wrote:
> > On Thu, Apr 12, 2018 at 5:56 PM, Sara Golemon wrote:
> >> Please put your name forward here if you wish to be considered a
> candidate.
> >> An initial todo page has been added to the
On Wed, Jan 10, 2018 at 10:48 AM, Michael Morris wrote:
> On Wed, Jan 10, 2018 at 12:27 PM, Rasmus Lerdorf
> wrote:
>
> > If you stay away from trying to change a 25-year old loosely typed
> > language into a strictly typed one, then the RFC becomes much simpler.
> >
On Wed, Jan 10, 2018 at 10:11 AM, Ryan Jentzsch
wrote:
> I agree with Michael (to a large degree) and I think I see clearly
> Michael's point:
> Under the current system I will NEVER create an RFC (or find someone with
> the Zend engine coding chops to help me) because the RISK vs. REWARD with
>
On Wed, Jan 10, 2018 at 5:27 AM, Michael Morris wrote:
>
> Also, drawing the architectural drawings for a skyscraper is also like only
> 10% of the work, but it's a damn important 10%.
>
Wow, that's rather insulting to the amazing work Dmitry, Nikita, Xinchen
and others are doing working on the c
On Tue, Jan 9, 2018 at 3:06 PM, Michael Morris wrote:
> Before I begin, and without picking on anyone specific, I want to say that
> it is generally unhelpful to say that because I, or others, do not know how
> the engine is set up that it is impossible to make any meaningful
> contributions to t
Definitely. Small, uncontroversial changes have never required an RFC.
Let's not add process just for the sake of process.
-Rasmus
On Fri, Jan 5, 2018 at 3:47 AM, Rowan Collins
wrote:
> On 5 January 2018 at 10:38, Dan Ackroyd wrote:
>
> > On 2 January 2018 at 13:55, Peter Cowburn
> wrote:
> >
> On Jan 4, 2018, at 13:09, Andreas Hennings wrote:
>
> A system where all variables are type-locked could in fact be faster
> than a system with dynamically typed variables.
> Depends on the implementation, of course. I imagine it would be a lot
> of work to get there.
I think you, and many ot
Ok, both have been added to the ezmlm deny list for internals
On Tue, Jan 2, 2018 at 2:49 AM, Nikita Popov wrote:
> Hi,
>
> This mail is going to both the systems group and internals mailing list.
>
> I would like to request a mailing list suspension for the users
> tonymars...@hotmail.com and l
Yeah, we know. Martin contacted Servergrove about 12 hours ago and we
haven't heard back. The machine itself is unreachable.
-Rasmus
It isn't super-helpful to publicly shame our active volunteers.
On Wed, Nov 8, 2017 at 3:33 PM, Sara Golemon wrote:
> On Wed, Nov 8, 2017 at 9:11 AM, Rasmus Lerdorf wrote:
> > So please report that directly to systems@ (that's what it is there
> for) and
> > cc s
2017 at 3:01 PM, Sara Golemon wrote:
> On Wed, Nov 8, 2017 at 8:03 AM, Rasmus Lerdorf wrote:
> > Our smtp servers are actually quite well maintained by Sascha and
> company.
> >
> This is a response from the mail server, with no mailing list software
> involved.
> This
> Without any generally available information about the existing email
> infrastructure, it's hard to make targeted comments about how to fix
> what is obviously broken with this system which literally nobody with
> the ability to fix cares about. That means a either a conversation
> (which should
On Tue, Nov 7, 2017 at 5:44 PM, Pedro Magalhães wrote:
> I'm not sure if the people who have access to the machines follow this
> mailing list as well, so I would suggest reaching out directly to the
> people listed as having access to the mailing lists machine (you can find
> that list here: htt
On Fri, Oct 6, 2017 at 12:04 PM, Sara Golemon wrote:
> On Fri, Oct 6, 2017 at 10:18 AM, Rasmus Lerdorf
> wrote:
> > Sara/Remi do you mind if I merge this into 7.2? This affects opcache
> debug
> > output only and I want to start playing with some DCE reporting from
&
Sara/Remi do you mind if I merge this into 7.2? This affects opcache debug
output only and I want to start playing with some DCE reporting from Phan.
Having the original line numbers available will make that more effective.
On Fri, Oct 6, 2017 at 11:03 AM, Rasmus Lerdorf wrote:
> Com
On Sat, Jul 22, 2017 at 8:21 AM, Jan Ehrhardt wrote:
> I am sure I am running PHP 7, not sure it is E_STRICT in 7.0 & 7.1. Just
> misread
> your statement "Even in 5.6 and 5.5 it was an E_STRICT", I suppose.
>
> With the 80-character line-breaks:
>
> C:\phpdev\php72nts.x64>php ..\class.php
>
> C:
On Sat, Jul 22, 2017 at 12:32 AM, Jan Ehrhardt wrote:
> Your example issues an E_STRICT warning, in both PHP 7.2 nts x64 and PHP
> 7.1 nts x64, so it must be caused by something else.
Are you sure you are even running PHP 7? This type of code hasn't issued an
E_STRICT since PHP 5.
See:
https:
On Fri, Jul 21, 2017 at 9:50 PM, Jan Ehrhardt wrote:
>
> I tried running Drupal7 with 7.2.0 Beta 1 and ran into a fatal error,
> that does not happen under PHP 7.1.x (Windows, NTS, x64). I do not know
> if it is a bug, an omission in UPGRADING or me looking with my nose.
> Therefore I did not file
On Thu, Jul 20, 2017 at 3:25 PM, Larry Garfield
wrote:
>
> I figure this is a long-shot, but Platform.sh hosts a number of
> community sites for free. (We recently became the home of
> https://externals.io/, for example.) We have multiple data centers and
> SSL-all-the-things using Lets Encrypt.
On Thu, Jul 20, 2017 at 1:42 AM, Niklas Keller wrote:
>
> They can also just request them themselves, but only for their mirror
> domain. If you allow them to issue for www.php.net, you can as well just
> put the current private key there.
>
I think there is a big difference between putting the p
On Wed, Jul 19, 2017 at 11:59 PM, Stephen Reay
wrote:
>
> Does it need to be geo-dns, or could it instead be "geo-http" - a small
> number of servers responding to (www.)?php.net, which then respond with
> http redirects based on client ip. This is similar to how Debians "new"
> mirror service wor
On Wed, Jul 19, 2017 at 1:50 PM, Sara Golemon wrote:
>
> * Use docker hub as the distribution channel. (https out of the box)
>
Getting https support in the web server is not what prevents us from
getting https for www.php.net. It is key management across our geodns
www.php.net that is the limiti
On Wed, Jul 19, 2017 at 1:42 PM, Niklas Keller wrote:
>
> We should really change that and fully move to HTTPS.
>
I have looked at various ways of doing this, but it isn't trivial and it
has absolutely nothing to do with the actual html and slapping in some
https links instead of http. The probl
No from me as well. This is wagging the dog by the tail. Picking a
documentation format is the very least of the concerns here. It would be
wonderful to have better internal API documentation, but putting up any
sort of structural restriction like limiting it to a specific header-based
format, isn'
This looks interesting. So you build against Valgrind and run php-cgi -T
5,1000 or something like that? What is your normal command line to do one
of these callgrind runs?
On Thu, May 25, 2017 at 3:52 PM, Nikita Popov wrote:
>
>
> During normal development I usually only run either Zend/ tests, or the
> tests in the extension I'm modifying (the rest is what CI is for).
> Parallelizing by directory will speed up our CI builds (which is important,
> we're often suffer
On Thu, May 25, 2017 at 3:09 AM, Andrea Faulds wrote:
>
> It occurred to me a little while ago that if we ran the test suite in
> parallel, but only run one test from a given directory (or extension) at a
> time, it should probably avoid any such problems, and it would not be
> particularly diffic
Also note that we don't do binary release outside of Windows. We leave it
up to the various distributions. If this Snap thing, which I have also
never heard of, has the equivalent of an rpm .spec file that you wish to
contribute and keep up to date we can add that, but anything beyond that is
out o
Ah, I see what I did now. I only messed up the old dstogov-foreach
experimental branch. We can probably kill that branch entirely.
On Fri, Apr 14, 2017 at 3:56 PM, Rasmus Lerdorf wrote:
> Oops, a misconfigured git setup ended up pushing to all branches on me. If
> someone could lend
Oops, a misconfigured git setup ended up pushing to all branches on me. If
someone could lend a hand cleaning this up I would appreciate it.
-Rasmus
On Wed, Feb 1, 2017 at 3:06 PM, Rowan Collins
wrote:
> On 01/02/2017 20:17, Rasmus Lerdorf wrote:
>
>> You probably think of $var as being a local scope variable here,
>> but really it isn't. It is an imported variable that happened to not exist
>> in the outer scop
On Wed, Feb 1, 2017 at 8:05 AM, Bruce Weirdan wrote:
> On Wed, Feb 01, 2017 at 07:45:50AM -0800, Rasmus Lerdorf wrote:
> > The reason it is feasible to do this for single-expression closures in
> this
> > short form syntax is that you don't typically need a local scope
On Tue, Jan 31, 2017 at 12:41 PM, Andrea Faulds wrote:
>
> That's the idea. I'd prefer it if auto-capture was not restricted to
> single-expression functions (“arrow functions”). Though arrow functions
> make most sense with auto-capture, it doesn't need to be stricted to them.
This goes against
On Mon, Jan 23, 2017 at 12:52 PM, Alice Wonder wrote:
> Actually I found that wasn't the case. To build php against an alternat
> openssl API - I did have to rebuild net-snmp but curl, for example, at
> least on CentOS uses NSS for it's TLS and so didn't need to be rebuild to
> build PHP against
On Mon, Jan 23, 2017 at 12:31 AM, Alice Wonder wrote:
> If someone on such a distro really can't use PHP 7.1.x, LibreSSL can be
> installed in parallel to OpenSSL (I do on CentOS) and I suspect php 7.0
> will build against it (5.6.x does and 7.1.x does)
>
> Also, I suspect older OpenSSL shared li
out this year, will ship with openssl-1.1 so they will not be able to run
any version of PHP prior to 7.1.
-Rasmus
On Sun, Jan 22, 2017 at 11:33 AM, Jakub Zelenka wrote:
> Hi Rasmus,
>
> On Sun, Jan 22, 2017 at 1:28 AM, Rasmus Lerdorf
> wrote:
>
>> Jakub, what do you think a
On Sat, Jan 21, 2017 at 5:22 PM, Rasmus Lerdorf wrote:
> On Sat, Jan 21, 2017 at 4:47 PM, Christoph M. Becker
> wrote:
>>
>> Anyhow, the SQLite3 documentation states[1]:
>>
>> | The sqlite3_prepare_v2() and sqlite3_prepare16_v2() interfaces are
>> | recom
Jakub, what do you think about back-porting the openssl-1.1 supporting
changes to the PHP-7.0 branch? I think it is too early to have PHP-7.0 not
compile on new Linux versions and right now it doesn't compile on any Linux
that has openssl-1.1.
-Rasmus
On Sat, Jan 21, 2017 at 4:47 PM, Christoph M. Becker
wrote:
>
> Anyhow, the SQLite3 documentation states[1]:
>
> | The sqlite3_prepare_v2() and sqlite3_prepare16_v2() interfaces are
> | recommended for all new programs. The two older interfaces are
> | retained for backwards compatibility, but the
On Fri, Jan 20, 2017 at 1:08 PM, Rasmus Lerdorf wrote:
>
> On Fri, Jan 20, 2017 at 12:58 Nikita Popov wrote:
>
>>
>> That sounds like it could be the source of the issue.
>>
> Ah, that makes more sense than it never hitting that close call because I
> co
On Fri, Jan 20, 2017 at 12:58 Nikita Popov wrote:
>
> From the docs for sqlite3_close():
>
> > If the database connection is associated with unfinalized prepared
>
> statements or unfinished sqlite3_backup objects then sqlite3_close()
>
> will leave the database connection open and return SQLITE_
I have been chasing a really odd fd leak which I haven't been able to
reproduce manually. The code involved is about as simple as you can get:
class C {
public static function fn($arg) {
$pdo = new PDO('sqlite:/var/dbs/file.db');
$query = $pdo->prepare("SELECT * FROM tb WHERE i
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.
On Thu, Dec 1, 2016 at 8:00 AM, Derick Rethans wrote:
>
> I think it's time to retire Ecelerity. Nobody knows how it works. if
> It'd be postfix, I would likely have checked one of these ghost mail
> reports out...
>
I don't think anyone disagrees with that, but at the same time it is a lot
of wo
The problem here is that it is not a standard mail setup so finding online
resources is tricky. It is Ecelerity from MessageSystems. I have been
poking the config trying to find where this subject keyword thing is
defined, but so far no luck. In the short term I think we need someone who
knows Ecel
On Thu, Nov 24, 2016 at 11:54 PM, Craig Duncan wrote:
> I've submit a PR (https://github.com/php/php-src/pull/2220) to fix a bug (
> https://bugs.php.net/bug.php?id=73581).
>
> Kalle suggested I run the change by here to see if there are any concerns
> or feedback about merging this?
>
This does
>
> > c. Get some specific people to volunteer to review patches in security
> > repo regularly - how? Any takers?
> >
> OFC it'd be ideal to have some karma holders to participate. And another
> option, which is IMHO eligible - we could invite several reporters. There
> is already a couple of peop
>
> The output of the perf diff is quite poor I think, here's the mainline :
> 35.90% +44.94% php-fpm [.] 0x00042412
> 10.72% -6.05% libc-2.19.so[.] 0x00079030
> 9.71% -9.34% newrelic.so [.] 0x00030980
> 3.81% -3.47% [
On Fri, Oct 14, 2016 at 9:15 PM, Jérémie BORDIER
wrote:
>
> I don't really know how to investigate further. If you have any
> pointers on how to help figuring out what's wrong, I'd love to try.
>
I would breakout the Linux perf command for something like this.
Run it like this:
perf record -p
On Sep 5, 2016, at 13:13, Nicolas Grekas wrote:
>
> It's not specifically me but Symfony's ClassCollectionLoader::load()
> method, which generates a single file with common classes inlined for
> faster bootstrapping (the perf gain is objectively measurable).
I have a hard time believing concaten
On Mon, Jun 20, 2016 at 1:25 PM, Dmitry Stogov wrote:
So, I propose to switch zend-signals on, and revert back if it makes
problems to 7.1 release process.
Any objections?
No objections here. I have been hitting annoying segfaults in 7.0 that
will likely be helped by this.
-Rasmus
On 03/20/2016 01:58 PM, Anatol Belski wrote:
> Dmitry has already merged this patch into the 7.0 branch. I also know from
> Remi that Fedora doesn't play well with the huge pages. Huge pages require
> special system settings which are usually not enabled in OSes by default.
> Having it off by de
Trivial things like adding a completely non-controversial optional
argument to a function really does not require an RFC. Let's not get
hung up on process just for the sake of process here.
-Rasmus
On 02/17/2016 05:06 AM, Christian Schneider wrote:
> Hi there,
> we just ran into a version of the bug "JIT bug with lookbehind assertion":
> https://bugs.exim.org/show_bug.cgi?id=1189
>
> To reproduce it you can use
> php -n -r 'ini_set("pcre.jit", 0); echo
> preg_replace("/\b(11|21|
On 02/06/2016 10:10 AM, Simon Svensson wrote:
> On 05/02/16 22:29, Rasmus Lerdorf wrote:
>> On 02/05/2016 11:39 AM, Simon Svensson wrote:
>>> I am unable to reproduce the error with this recompiled source, both
>>> with the /usr/local/php70/bin/php and /usr/local/php70
On 02/05/2016 11:39 AM, Simon Svensson wrote:
> I am unable to reproduce the error with this recompiled source, both
> with the /usr/local/php70/bin/php and /usr/local/php70-debug/bin/php.
> This is the same experience I had with earlier releases, where I have
> been unable to reproduce the segment
On 01/04/2016 07:22 PM, Sara Golemon wrote:
> On Thu, Dec 31, 2015 at 1:10 PM, Stanislav Malyshev
> wrote:
>> I don't think it is a good idea, currently, for the following reasons:
>>
> [::snip::]
>
> It terrifies me to say this, but I completely agree with Stas. ;)
>
> I can't personally remem
On Dec 7, 2015, at 18:17, Rasmus Lerdorf wrote:
>
>> On Dec 7, 2015, at 16:28, Lester Caine wrote:
>>
>> PHP7 is around 10% slower ... and given that half the time is taken
>> in database lookup, the code performance is potentially worse. So what
>> am I mis
On Dec 7, 2015, at 16:28, Lester Caine wrote:
>
> PHP7 is around 10% slower ... and given that half the time is taken
> in database lookup, the code performance is potentially worse. So what
> am I missing?
Then you have a config problem. The first and obvious thing to check is your
opcache set
On 12/03/2015 12:58 PM, Niklas Keller wrote:
> Yes, releases have been repackaged,
> see
> https://mta.openssl.org/pipermail/openssl-announce/2015-December/51.html
Ah, I misread. I thought you meant our php-7.0.0 tarball was a failed
release.
signature.asc
Description: OpenPGP digital sig
On 12/03/2015 09:39 AM, Niklas Keller wrote:
> Jan Ehrhardt schrieb am Do., 3. Dez. 2015 17:04:
>
> Ferenc Kovacs in php.internals (Thu, 3 Dec 2015 16:27:36 +0100):
>> On Thu, Dec 3, 2015 at 4:18 PM, Sebastian Bergmann
>> wrote:
>>
>>> Am 03.12.2015 um 16:10 schrieb Julien Pauli:
We, PHP, a
On 12/03/2015 12:28 PM, Andi Gutmans wrote:
> What just happened? It was on php.net and now it's gone?
It's there. Did you get geo-dns'ed to a different www.php.net perhaps?
The mirrors are still updating.
-Rasmus
signature.asc
Description: OpenPGP digital signature
On Nov 23, 2015, at 15:21, Anthony Ferrara wrote:
>
> Rasmus,
>
>> I think this was mostly a PR failure on my part actually. If I/we are a bit
>> more careful about how we handle similar issues and the people lurking with
>> itchy Twitter trigger fingers would spend a bit more time looking int
On Nov 23, 2015, at 15:05, Zeev Suraski wrote:
>
>> On 23 בנוב׳ 2015, at 14:04, Joe Watkins wrote:
>>
>>
>> No one is expecting 0.0 or any version to be bug free, but the simplicity of
>> the fix says nothing about the seriousness of the bug. I think it quite
>> serious _because_ we are a fe
On Nov 23, 2015, at 10:35, Derick Rethans wrote:
>
>> On November 23, 2015 10:08:18 AM GMT+01:00, Rasmus Lerdorf
>> wrote:
>>> On 11/23/2015 09:49 AM, Phil Sturgeon wrote:
>>> The "There will always be bugs" argument is a strawman, nobody is
>>
On 11/23/2015 09:49 AM, Phil Sturgeon wrote:
> The "There will always be bugs" argument is a strawman, nobody is
> saying wait until it's perfect.
>
> People in this thread are consistently conflating "there will always
> be bugs" with "lets just ignore this bug which is 'around critical'
> and cr
On Nov 23, 2015, at 00:48, Adam Harvey wrote:
>
> Here's an alternative suggestion: we've previously switched to one
> week RC cycles late in the piece when trying to get major releases
> stabilised and we're at the point of only fixing one or two things per
> RC. That's exactly where we are now.
On 11/22/2015 06:18 AM, Anthony Ferrara wrote:
> Zeev,
>
> On Sat, Nov 21, 2015 at 11:52 PM, Zeev Suraski wrote:
>>
>>> On 22 בנוב׳ 2015, at 0:47, Anthony Ferrara wrote:
>>>
>>> I think this is significant enough to be a blocker to gold and that we
>>> should fix it prior to release.
>>>
>>> Tho
On Nov 20, 2015, at 15:51, Andone, Bogdan wrote:
>
> Please ignore the Mandelbrot result. It seems it was a measurement error, as
> we were unable to reproduce it on the same commit with additional runs.
Perhaps it would be possible to automatically trigger additional runs in case a
result show
On 11/16/2015 04:11 PM, Jefferson Gonzalez wrote:
> On 11/16/2015 04:22 PM, Rasmus Lerdorf wrote:
>> But that is exactly what the file-based opcache does by itself. The only
>> speedup you achieve by trying to distribute the .bin files would be a
>> minor boost the first
On 11/16/2015 03:13 PM, Jefferson Gonzalez wrote:
> On 11/14/2015 08:03 PM, Rasmus Lerdorf wrote:
>> Beyond that I can't picture what possible use this could be.
>
> I also think that the ability to have a .phpc and .php side by side
> would be nice, but not for hiding th
On Nov 14, 2015, at 10:13, Pascal Chevrel wrote:
>
> Hi guys,
>
> I am very exceited about the imminent release of PHP 7 and that also
> corresponds to when my non-profit will get a new server sponsored by a
> local ISP, so we want to switch to 7 at this occasion, right in December ;)
>
> Do yo
On Nov 13, 2015, at 21:32, Stephen Coakley wrote:
>
>> On 11/13/2015 05:46 PM, Rasmus Lerdorf wrote:
>>> On Nov 13, 2015, at 17:00, Stephen Coakley wrote:
>>>
>>>>> On 11/13/2015 03:45 PM, Sebastian Bergmann wrote:
>>>>> On 11/13/
1 - 100 of 1854 matches
Mail list logo
