Yes, earlier I was advocating a side-step SHM area for the side-step
OpCache because it'll probably use less memory. Sounded like I lost that
argument, so I switched to in-process heap (which is more complicated too).
New commit using side-step SHM(not heap):
https://github.com/php/php-src/commit/
I think this is the most awesomest fantastical idea since sliced bread.
+~0
On Thu, Oct 8, 2015 at 11:05 AM, Mattias Gonzalez wrote:
> I wanted to propose the "var_die($var)" functionallity.
> My mates and i use a lot var_dump($var);die;
>
> Since die() wont print an array just a string, i thin
I agree with Ben on this, I personally use var_dump();exit; in my code a
lot, but there's no reason this needs to be in the core and not in userland:
function dd(...$args) {
var_dump(...$args);
exit;
}
On Fri, Oct 9, 2015 at 5:24 PM Kris Childress wrote:
> Mattias,
>
> As an avid user o
Mattias,
As an avid user of var_dump($something); die(); I think this is a *fabulous*
idea!
Laravel has a good idea with dd(), I would like to see something that is
quick and easy to type, that we can throw anything at.. Maybe something
similar (basic example) to the following :
function dd($
If you and your friends use that a lot, how about you just define a
function for it in userland? There's absolutely no logical reason to
have this in core.
function var_die($value) { var_dump($value); exit; }
On 08.10.2015 17:05, Mattias Gonzalez wrote:
I wanted to propose the "var_die($var)"
I wanted to propose the "var_die($var)" functionallity.
My mates and i use a lot var_dump($var);die;
Since die() wont print an array just a string, i think it´ll be very useful.
It should do the var_dump($var);and die();
what do you think?
On Thu, Oct 8, 2015 at 4:41 PM, Ferenc Kovacs wrote:
> Hi,
>
> we RMs started using the release branches (PHP-X.Y.Z) a while ago and we
> push those so that the we can work together easier when preparing/syncing
> the releases.
> As those branches are meaningless for the general public I would pro
Hi,
> -Original Message-
> From: julienpa...@gmail.com [mailto:julienpa...@gmail.com] On Behalf Of
> Julien Pauli
> Sent: Thursday, October 8, 2015 5:28 PM
> To: Ferenc Kovacs
> Cc: Stanislav Malyshev ; Remi Collet ; Kalle
> Sommer Nielsen ; Anatoliy Belsky ; PHP Internals
>
> Subject: R
On Wed, Oct 7, 2015 at 2:39 PM, Anatol Belski wrote:
> Hi Matt,
>
> > -Original Message-
> > From: Matt Ficken [mailto:themattfic...@gmail.com]
> > Sent: Wednesday, October 7, 2015 12:18 PM
> > To: Anatol Belski
> > Cc: Dmitry Stogov ; Pierre Joye ;
> > Laruence ; PHP Internals ;
> > dmi
On Thu, Oct 8, 2015 at 9:47 AM, Matt Ficken wrote:
> Yes, earlier I was advocating a side-step SHM area for the side-step
> OpCache because it'll probably use less memory. Sounded like I lost that
> argument, so I switched to in-process heap (which is more complicated too).
>
> New commit using s
Hi,
we RMs started using the release branches (PHP-X.Y.Z) a while ago and we
push those so that the we can work together easier when preparing/syncing
the releases.
As those branches are meaningless for the general public I would propose
updating our current release process (
https://github.com/ph
2015-10-08 10:33 GMT+02:00 Dmitry Stogov :
> few notes:
> - are you sure SysV IPC API is available everywhere? I mean shmget()
> in file_cache_fallback_init().
> (I didn't know about Windows).
Yes the SysV IPC API is available under Windows, because we have our
own implementation in TSRM/, more sp
few notes:
- this is for Windows only. Right?
- are you sure SysV IPC API is available everywhere? I mean shmget()
in file_cache_fallback_init().
(I didn't know about Windows).
- I think all the changes should be wrapped by "#ifdef ...FALLBACK_SUPPORT"
(at least we will able to easily remove this)
Results for project php-src-nightly, build date 2015-10-08 11:10:59+03:00
commit: 478e8d6b6d97e53c9e278ec783a2a4fa963df344
revision_date: 2015-10-07 16:26:58+02:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, stepping
2, LLC 45 MB
On 10/01/2015 01:59 AM, Stephen Coakley wrote:
So then, in summary, threads & multiprocessing enables you to do more
*work* simultaneously, while async **maximizes the usefulness of each
thread you have**. So using both is actually an incredibly good thing,
but they aren't the same nor accompli
Results for project php-src-nightly, build date 2015-10-09 05:13:05+03:00
commit: 5a793a68b0ef1f8d9e3c16bb5bfa358d0c30907d
revision_date: 2015-10-09 02:40:11+03:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, stepping
2, LLC 45 MB
16 matches
Mail list logo
