Re: [PHP-DEV] Rogue Wave Software acquires enterprise PHP leader Zend

[Pierre Joye]

On Oct 7, 2015 12:42 AM, "David Zuelke"  wrote:
>
> On 06.10.2015, at 19:28, Pierre Joye  wrote:
>
> > The license cannot be changed without approvals of every contributor
> > to date. I very much doubt they will. And to make that point clear for
> > me, if they do and come with anything but the PHP license, I can
> > already say that I won't accept it.
>
> First, a license change may be necessary from their side in case "Zend
Technologies Ltd" ceases to exist.
>
> Second, never say never. The PHP and Zend licenses are just BSD licenses
with a few more or less irrelevant (to the code, the project, and its
future) additional sections about the use of the word "PHP" in product
names and that you must under no circumstance feed an Elephpant spinach on
the last Friday of the month or something like that.
>
> So a switch to "pure" BSD, for example, probably wouldn't be a big deal,
even to you, would it?

Last word on the matter for now  (because it does not matter much ;), yes
it will be a big deal. I am strongly in favor of one come license for the
core.

Re: [PHP-DEV] Remove name mangling? (when creating variables from external sources)

[Anthony Ferrara]

Hey,

On Tue, Oct 6, 2015 at 4:38 PM, Bishop Bettini  wrote:
> Hi!
>
> Currently dots and spaces are converted to underscores when pulling them in
> from HTML:
>
> 
> 
> 
> 
> 
> 
> 
>
> Ostensibly[1], names were mangled to support import_request_variables and
> register_globals.  But curiously other characters that would create an
> invalid variable aren't mangled:
>
>  
>
> There are already two bug requests out there asking to remove this behavior
> or expose the original name: #34882 and #42055
>
> Since 5.4.0 removed both import_request_variables and register_globals,
> does this mangling serve any purpose?  If not, can we remove it?
>
>
> [1] http://php.net/manual/en/language.variables.external.php
> [2] https://bugs.php.net/bug.php?id=34882
> [3] https://bugs.php.net/bug.php?id=42055

I'm all for this. Mangling has always seemed ...weird... Pulling it
out is awesome.

However, it also would be a pretty non-trivial BC break for people who
rely on the mangling. This would be likely something for 8?

Anthony

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Remove name mangling? (when creating variables from external sources)

[Bishop Bettini]

Hi!

Currently dots and spaces are converted to underscores when pulling them in
from HTML:









Ostensibly[1], names were mangled to support import_request_variables and
register_globals.  But curiously other characters that would create an
invalid variable aren't mangled:

 

There are already two bug requests out there asking to remove this behavior
or expose the original name: #34882 and #42055

Since 5.4.0 removed both import_request_variables and register_globals,
does this mangling serve any purpose?  If not, can we remove it?


[1] http://php.net/manual/en/language.variables.external.php
[2] https://bugs.php.net/bug.php?id=34882
[3] https://bugs.php.net/bug.php?id=42055

Re: [PHP-DEV] Rogue Wave Software acquires enterprise PHP leader Zend

[Chris Tankersley]

I updated the blog post to better explain why changing the license would be
hard and would probably never happen.

-Chris

On Tue, Oct 6, 2015 at 1:56 PM, Marcel Araujo  wrote:

> PHP won't die!
>
> http://ctankersley.com/2015/10/06/zends-acquisition-doesnt-matter/
>
> PHP, and the Zend Engine, currently follow the PHP License. There's a line
> > at the top though that has people worried:
> > Copyright (c) 1999-2006 Zend Technologies Ltd. All rights reserved.
> > Zend holds the copyright to the Zend Engine, and thus the ability to set
> > the license on the Zend Engine. What's the Zend Engine? It's the thing
> that
> > makes PHP... well, PHP. It turns our written code into something servers
> > understand, and makes things work. The only major player that compares to
> > it is HHVM (yes, there are others, but HHVM is the only one I've seen
> with
> > real traction).
> > So, as copyright holder, Zend/RogueWave is well within their rights to
> > change the license to something more permissive, or lock it down. It is
> > their choice.
> > If they do decide to do that, they can't change it retroactively. The PHP
> > Community as a whole can continue to use previous versions of the Zend
> > Engine, as long as they continue to follow the PHP License, and ignore
> the
> > "new" Zend Engine. Life would find a way.
> > There's precedent for that in fact, as when Zend suddenly showed up with
> > phpng, there was some talk about not using it. We're a fickle group, and
> > PHP internals could, and would, move away from the Zend Engine if needed.
> > We'd also gladly continue to use older versions of Zend Engine before the
> > license change.
> > Worse case, we're all switching to HHVM and we have a few minor bugs to
> > figure out.
>
>
>
>
> On Tue, Oct 6, 2015 at 2:42 PM, David Zuelke  wrote:
>
> > On 06.10.2015, at 19:28, Pierre Joye  wrote:
> >
> > > The license cannot be changed without approvals of every contributor
> > > to date. I very much doubt they will. And to make that point clear for
> > > me, if they do and come with anything but the PHP license, I can
> > > already say that I won't accept it.
> >
> > First, a license change may be necessary from their side in case "Zend
> > Technologies Ltd" ceases to exist.
> >
> > Second, never say never. The PHP and Zend licenses are just BSD licenses
> > with a few more or less irrelevant (to the code, the project, and its
> > future) additional sections about the use of the word "PHP" in product
> > names and that you must under no circumstance feed an Elephpant spinach
> on
> > the last Friday of the month or something like that.
> >
> > So a switch to "pure" BSD, for example, probably wouldn't be a big deal,
> > even to you, would it?
> >
> > David
> >
> >
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
>
>
> --
>
>
>
>
>
>
> *Marcel AraujoAnalista de SistemasDesenvolvedor
> PHP/Zend/JavaScript/jQuery/NodeJSLinux User
> #490101http://www.twitter.com/marcelarauj0
> http://blog.marcelaraujo.me
> http://br.linkedin.com/in/marcelaraujo
> *
>

Re: [PHP-DEV] Rogue Wave Software acquires enterprise PHP leader Zend

[Marcel Araujo]

PHP won't die!

http://ctankersley.com/2015/10/06/zends-acquisition-doesnt-matter/

PHP, and the Zend Engine, currently follow the PHP License. There's a line
> at the top though that has people worried:
> Copyright (c) 1999-2006 Zend Technologies Ltd. All rights reserved.
> Zend holds the copyright to the Zend Engine, and thus the ability to set
> the license on the Zend Engine. What's the Zend Engine? It's the thing that
> makes PHP... well, PHP. It turns our written code into something servers
> understand, and makes things work. The only major player that compares to
> it is HHVM (yes, there are others, but HHVM is the only one I've seen with
> real traction).
> So, as copyright holder, Zend/RogueWave is well within their rights to
> change the license to something more permissive, or lock it down. It is
> their choice.
> If they do decide to do that, they can't change it retroactively. The PHP
> Community as a whole can continue to use previous versions of the Zend
> Engine, as long as they continue to follow the PHP License, and ignore the
> "new" Zend Engine. Life would find a way.
> There's precedent for that in fact, as when Zend suddenly showed up with
> phpng, there was some talk about not using it. We're a fickle group, and
> PHP internals could, and would, move away from the Zend Engine if needed.
> We'd also gladly continue to use older versions of Zend Engine before the
> license change.
> Worse case, we're all switching to HHVM and we have a few minor bugs to
> figure out.




On Tue, Oct 6, 2015 at 2:42 PM, David Zuelke  wrote:

> On 06.10.2015, at 19:28, Pierre Joye  wrote:
>
> > The license cannot be changed without approvals of every contributor
> > to date. I very much doubt they will. And to make that point clear for
> > me, if they do and come with anything but the PHP license, I can
> > already say that I won't accept it.
>
> First, a license change may be necessary from their side in case "Zend
> Technologies Ltd" ceases to exist.
>
> Second, never say never. The PHP and Zend licenses are just BSD licenses
> with a few more or less irrelevant (to the code, the project, and its
> future) additional sections about the use of the word "PHP" in product
> names and that you must under no circumstance feed an Elephpant spinach on
> the last Friday of the month or something like that.
>
> So a switch to "pure" BSD, for example, probably wouldn't be a big deal,
> even to you, would it?
>
> David
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>


-- 






*Marcel AraujoAnalista de SistemasDesenvolvedor
PHP/Zend/JavaScript/jQuery/NodeJSLinux User
#490101http://www.twitter.com/marcelarauj0
http://blog.marcelaraujo.me
http://br.linkedin.com/in/marcelaraujo
*

Re: [PHP-DEV] Rogue Wave Software acquires enterprise PHP leader Zend

[David Zuelke]

On 06.10.2015, at 19:28, Pierre Joye  wrote:

> The license cannot be changed without approvals of every contributor
> to date. I very much doubt they will. And to make that point clear for
> me, if they do and come with anything but the PHP license, I can
> already say that I won't accept it.

First, a license change may be necessary from their side in case "Zend 
Technologies Ltd" ceases to exist.

Second, never say never. The PHP and Zend licenses are just BSD licenses with a 
few more or less irrelevant (to the code, the project, and its future) 
additional sections about the use of the word "PHP" in product names and that 
you must under no circumstance feed an Elephpant spinach on the last Friday of 
the month or something like that.

So a switch to "pure" BSD, for example, probably wouldn't be a big deal, even 
to you, would it?

David



--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Rogue Wave Software acquires enterprise PHP leader Zend

[Pierre Joye]

On Tue, Oct 6, 2015 at 11:21 PM, Ferenc Kovacs  wrote:
> Hi,
>
> I've just read the news about the Zend acquisition:
> http://www.zend.com/en/resources/news-and-events/newsroom/press/3683_rogue-wave-software-acquires-enterprise-php-leader-zend-acquisition-broadens-enterprise-strength-across-top-five-development-languages
> I'm curious how will this change the License of the Zend Engine.
> If anybody not familiar with the situation, the Zend Engine has it's own
> license, the Zend License:
> https://en.wikipedia.org/wiki/PHP_License#Zend_Engine_License and that
> refers to the Zend Technologies and zend.com everywhere.
> I would like to ask Zeev/Andi about what does the acquisition mean for the
> php project and if they already have a plan about what to do with the Zend
> Engine license in the future.
>
> ps: just noticed that http://www.zend.com/license/2_00.txt is a 404 even
> thought that is linked from php-src/Zend/* and from the wikipedia page on
> the Zend Engine License.

The license cannot be changed without approvals of every contributor
to date. I very much doubt they will. And to make that point clear for
me, if they do and come with anything but the PHP license, I can
already say that I won't accept it.

Cheers,
-- 
Pierre

@pierrejoye | http://www.libgd.org

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Rogue Wave Software acquires enterprise PHP leader Zend

[Bishop Bettini]

On Tue, Oct 6, 2015 at 12:21 PM, Ferenc Kovacs  wrote:

> ps: just noticed that http://www.zend.com/license/2_00.txt is a 404 even
> thought that is linked from php-src/Zend/* and from the wikipedia page on
> the Zend Engine License.
>

Indeed, the 2.0 license went dark between 6-June-2014 [1] and 17-Nov-2014
[2].  SPDX has a copy [3].

[1]:
https://web.archive.org/web/20140606091832/http://www.zend.com/license/2_00.txt
[2]:
https://web.archive.org/web/20141117083350/http://www.zend.com/license/2_00.txt
[3]: https://spdx.org/licenses/Zend-2.0.html

[PHP-DEV] Rogue Wave Software acquires enterprise PHP leader Zend

[Ferenc Kovacs]

Hi,

I've just read the news about the Zend acquisition:
http://www.zend.com/en/resources/news-and-events/newsroom/press/3683_rogue-wave-software-acquires-enterprise-php-leader-zend-acquisition-broadens-enterprise-strength-across-top-five-development-languages
I'm curious how will this change the License of the Zend Engine.
If anybody not familiar with the situation, the Zend Engine has it's own
license, the Zend License:
https://en.wikipedia.org/wiki/PHP_License#Zend_Engine_License and that
refers to the Zend Technologies and zend.com everywhere.
I would like to ask Zeev/Andi about what does the acquisition mean for the
php project and if they already have a plan about what to do with the Zend
Engine license in the future.

ps: just noticed that http://www.zend.com/license/2_00.txt is a 404 even
thought that is linked from php-src/Zend/* and from the wikipedia page on
the Zend Engine License.

-- 
Ferenc Kovács
@Tyr43l - http://tyrael.hu

Re: [PHP-DEV] Re: Re: RFC proposal.

[Sergey Vanyushin]

2015-10-06 17:01 GMT+03:00 Johannes Schlüter :

> On Tue, 2015-10-06 at 15:42 +0400, somebody anon wrote:
>
> Please fix your mail program to provide a name and In-Reply-To and
> References headers so that we can address somebody and your mails are
> sorted correctly.
>
> > I've implemented this function and two other size-related in php [1],
> but I
> > think they should be in php core to avoid implementation of them by
> > thousands of people. This draft is only for demonstation purposes. There
> > are presented three functions:
> >
> > a. size_format([$format,] $bytes [, $unit]): string
>
> If we do it this must be generic and work for "everybody". This is not
> trivial. i.e. for 1001 bytes depending on context any of these might be
> "correct":
>* 1001 byte
>* 0.98 KiB
>* 0.98 kB
>* 0,98 kB
>* 1 KiB
>* 1 KB
>* 1 Ko
>* ...
>

Not all of them are correct. 0.98 kB for 1001 b is not correct, for example.
But with current behavior I got these results without any modification of
source code:
"1001 b"
"0.98 KiB"
"0.98 kb"
"1.00 kb"
"1 KiB"
"100 MiB"
"1.44 MiB"


> Also one often wants different precision depending on the value
>* 100 MB (not 100.23 MB)
>* 1.44 MB (not 1 MB)
>
> Feel free to come back with a more complete proposal and provide a name,
> a proper subject etc.  (... and even then I doubt this has to be part of
> the core distribution, we should only add things which can't be done in
> userland (due to libraries or performance requirements or similar)  as
> userland code is more flexible to change/improve and simpler to debug
> for users and especially with PHP 7 fast enough for mot things)
>

I don't think that some people prefer kB. Also, what "ko" is?


>
> johannes
>
>

[PHP-DEV] [RFC] [DISCUSSION]: Class Constant Visibility

[Sean DuBois]

Morning internals!

I am starting the discussion around adding visibility modifiers
to class constants. Following in the same pattern as properties.
https://wiki.php.net/rfc/class_const_visibility

There was some great discussion about this before as well
http://news.php.net/php.internals/87946

If you are interested in the code itself. The tests for the reflection ext have
not been updated yet. Beyond that I am unaware of any work outside of opcache 
changes (and bugs) !
https://github.com/php/php-src/pull/1494

thanks

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Re: Windows OpCache bug fix

[Anatol Belski]

Hi Dmitry,

> -Original Message-
> From: Dmitry Stogov [mailto:dmi...@zend.com]
> Sent: Tuesday, October 6, 2015 10:01 AM
> To: Anatol Belski 
> Cc: Matt Ficken ; Pierre Joye
> ; Laruence ; PHP Internals
> ; dmi...@php.net
> Subject: Re: [PHP-DEV] Re: Windows OpCache bug fix
> 
> On Mon, Oct 5, 2015 at 6:38 PM, Anatol Belski  wrote:
> 
> >
> >
> > > -Original Message-
> > > From: Dmitry Stogov [mailto:dmi...@zend.com]
> > > Sent: Monday, October 5, 2015 3:31 PM
> > > To: Anatol Belski 
> > > Cc: Matt Ficken ; Pierre Joye
> > > ; Laruence ; PHP Internals
> > > ; dmi...@php.net
> > > Subject: Re: [PHP-DEV] Re: Windows OpCache bug fix
> > >
> > > > > > > Subject: Re: [PHP-DEV] Re: Windows OpCache bug fix
> > > > > > >
> > > > > > > > Dmitry, I'd have a question to this
> > > > > > > > > Also. if we can't map SHM into desired address space, we
> > > > > > > > > may map it in
> > > > > > > > any
> > > > > > > > > other address and copy data into the process memory
> > > > > > > > > similar to
> > > > > > > > file-cache.
> > > > > > > > In randomized memory layout, even the base were available
> > > > > > > > and OpenFileMapping were worky, some parts of that memory
> > > > > > > > were already
> > > > > > > taken.
> > > > > > > > How exactly it could be done, could you please give a
> > > > > > > > couple of pointers to this?
> > > > > > >
> > > > > > >
> > > > > > > If MapViewOfFileEx(..., wanted_mapping_base) fails, we do
> > > > > > > MapViewOfFileEx(..., NULL).
> > > > > > >
> > > > > > >
> > > > > > > > Would the file cache be always required then?
> > > > > > > >
> > > > > > >
> > > > > > > This is not necessary, but depends on implementation of course.
> > > > > > >
> > > > > > Thanks for the advice. I was playing with this over these days.
> > > > > > There are two usual cases where it possibly fails when
> > > > > > reattaching ATM
> > > > > >
> > > > > > -
> > > > > > https://github.com/php/php-src/blob/PHP-7.0/ext/opcache/shared
> > > > > > _all
> > > > > > oc_w
> > > > > > in32.c#L151
> > > > > > - the saved address is available but is not suitable
> > > > > > -
> > > > > > https://github.com/php/php-src/blob/PHP-7.0/ext/opcache/shared
> > > > > > _all
> > > > > > oc_w
> > > > > > in32.c#L159
> > > > > > - the actual MapViewOfFileEx case
> > > > > >
> > > > > > An unrelated plain C test shows, that MapViewOfFileEx can
> > > > > > possibly fail when called second time, too. Even with NULL or
> > > > > > with another address as base. But even if it could map at a
> > > > > > different base - the internal structures will probably have invalid
> addresses.
> > > > >
> > > > >
> > > > > right. we might need different code for zend_accle_hash access
> > > > > or convert corresponding structures to PIC.
> > > > > For opcdeos "invalid address" don't matter because we will copy
> > > > > them into process memory and fix (like in file-cache).
> > > > >
> > > > Ah, I have to study the file cache code then. But generally it
> > > > sounds not like something that can be done offhand. I've also
> > > > thought about other things like interned strings (maybe something
> > > > else), not sure they're stored with the cache.
> > > >
> > > > >
> > > > > > So it looks like there's indeed no profit to do any retry once
> > > > > > the actualy base address needed was failed to reattach to.
> > > > > >
> > > > > > IMHO the scenario that were usable - in case it fails to
> > > > > > reattach to the exact address, it has to switch to heap. Just
> > > > > > for one request, it should get a heap allocated segment and
> > > > > > then
> > invalidate all the
> > > cache.
> > > > > > That way we fulfill the following
> > > > > >
> > > > > > - the request is served for sure
> > > > > > - the scripts are not cached indeed, so no divergence with the
> > > > > > actual real cache
> > > > > >
> > > > > > A heap fallback memory handler would be probably quite easy to
> > > > implement.
> > > > > > What do you think?
> > > > > >
> > > > > > Apropos with the heap - it also looks like when PHP is used as
> > > > > > module under mpm_winnt, all the cache could use heap instead
> > > > > > of SHM. In that case, there is only one Apache process serving
> > > > > > with
> > many
> > > threads.
> > > > > > Except one would want to share that cache outside Apache,
> > > > > > using heap there could be a much simpler solution.
> > > > > >
> > > > >
> > > > > Heap based cache makes the same problems. It increase the memory
> > > > > usage
> > > > and
> > > > > doesn't provide cache consistency.
> > > > > Just fall-back to file-cache may be better.
> > > > Do you think something like this would suffice as file cache
> > > > fallback
> > > > https://gist.github.com/weltling/224001a468f04de13693  ? Though
> > > > it'd still diverge from the "main" cache.
> > > >
> > >
> > > I think we should enable file-cache automatically, but we can set
> > > ZCG(accel_directives).file_cache_only
> > > if the file_cache already enabled.
> > >
> > 

[PHP-DEV] Benchmark Results for PHP Master 2015-10-06

[lp_benchmark_robot]

Results for project php-src-nightly, build date 2015-10-06 05:13:02+03:00
commit: bc95a6109f0de4cec87f324512a672b472abd66f
revision_date:  2015-10-06 01:03:35+02:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, stepping 
2, LLC 45 MB
mem:128 GB
os: CentOS 7.1
kernel: Linux 3.10.0-229.4.2.el7.x86_64

Baseline results were generated using release php-7.0.0beta3, with hash 
1674bd9b151ff389fb8c9fc223bc6aafdd49ff2c from 2015-08-05 04:56:40+00:00

--
benchmark   relative   change since   change since
std_dev*   last run   baseline
--
:-)   Wordpress 4.2.2 cgi -T1  0.23% -0.28%  2.56%
:-)   Drupal 7.36 cgi -T1  0.58%  0.42%  2.01%
:-)   MediaWiki 1.23.9 cgi -T5000  0.09%  0.36%  3.63%
:-( bench.php cgi -T1  0.09% -1.42%  0.91%
:-)   micro_bench.php cgi -T1  1.17%  2.54% -0.76%
:-)mandelbrot.php cgi -T1  0.23% -2.43%  5.75%
--
Note: Benchmark results for Wordpress, Drupal, MediaWiki are measured in 
fetches/second while all others are measured in seconds.
* Relative Standard Deviation (Standard Deviation/Average)

Our lab does a nightly source pull and build of the PHP project and measures 
performance changes against the previous stable version and the previous 
nightly measurement. This is provided as a service to the community so that 
quality issues with current hardware can be identified quickly.

Intel technologies' features and benefits depend on system configuration and 
may require enabled hardware, software or service activation. Performance 
varies depending on system configuration.

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] [DRAFT]: Consistent callables

[Daniel Persson]

Hi Dan.

Had this email in the "need-to-read" pile for over a week and finally got
the time to go though the RFC.

Seems like this is something that we need to address. Inconsistencies are
never good.

The only thing I want to point out is that is_callable as well as
method_exists don't state in the manual that the functions or methods
referred is visible.
To make this function implied I think the manual should be updated to state
it.

For instance

public class A {
private function foo() {}
}

method_exists(new A(), "foo") is technically true.
The method exist but is not visible from your context. For instance when
you use reflection you might want to find any method that exists? Or should
that be handled by the pure reflection API? Either way I think the manual
needs to state this clearly.

Best regards
Daniel

On Tue, Sep 29, 2015 at 4:25 PM, Dan Ackroyd  wrote:

> Hello internals,
>
> Here is a draft RFC to make the callable type in PHP be consistent and
> have much fewer surprises.
>
> https://wiki.php.net/rfc/consistent_callables
>
> This RFC is probably not ready for the formal discussion that is held
> before a vote on it can be held as there may be some more details of
> what changes are necessary lurking, waiting to be found, in the PHP
> source code. However I would like to gather feedback about the
> likelihood of the RFC passing, as implementing a patch for this RFC is
> likely to be a significant amount of work.
>
> And yes most of this RFC targets PHP 8 with only small parts for 7.1.
> I realise that it is easy to think that it's a bit early to start
> thinking about that before 7 is out the door, but as there was a
> stampede of RFCs for PHP 7, I think the earlier RFCs can be discussed
> the better. Depending on the feedback, I imagine I would put this RFC
> up for a formal discussion and vote early in the new year.
>
> cheers
> Dan
> Ack
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>

Re: [PHP-DEV] Re: Re: RFC proposal.

[Johannes Schlüter]

On Tue, 2015-10-06 at 15:42 +0400, somebody anon wrote:

Please fix your mail program to provide a name and In-Reply-To and
References headers so that we can address somebody and your mails are
sorted correctly.

> I've implemented this function and two other size-related in php [1], but I
> think they should be in php core to avoid implementation of them by
> thousands of people. This draft is only for demonstation purposes. There
> are presented three functions:
> 
> a. size_format([$format,] $bytes [, $unit]): string

If we do it this must be generic and work for "everybody". This is not
trivial. i.e. for 1001 bytes depending on context any of these might be
"correct":
   * 1001 byte
   * 0.98 KiB
   * 0.98 kB
   * 0,98 kB
   * 1 KiB
   * 1 KB
   * 1 Ko
   * ...
Also one often wants different precision depending on the value
   * 100 MB (not 100.23 MB)
   * 1.44 MB (not 1 MB)

Feel free to come back with a more complete proposal and provide a name,
a proper subject etc.  (... and even then I doubt this has to be part of
the core distribution, we should only add things which can't be done in
userland (due to libraries or performance requirements or similar)  as
userland code is more flexible to change/improve and simpler to debug
for users and especially with PHP 7 fast enough for mot things)

johannes



signature.asc
Description: This is a digitally signed message part

Re: [PHP-DEV] RFC proposal.

[Remi Collet]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Le 05/10/2015 00:10, somebody anon a écrit :

"someone.wanted.to.be.unkn...@gmail.com"

Can't be serious...

> Hi PHP community. I am a developer with few years experience in PHP
> and now want to propose some addition to default "filesystem"
> extension. There's money_format and number_format functions to
> format money and number values in human-readable format, but there
> is not any "size_format" function that does the same - reformat an
> integer that holds size in bytes in well-formed string representing
> size in one of "big" units like MB or GB. So I can implement
> function to do this with following interface:
>> size_format($format, $bytes, $unit = null)
> that will format size like printf with taking in accoun using unit
> and multiplier (1k or 1024). So, I wait for responses. Thanks for
> attention.
> 

Don't see any benefit.
Different locales will need different output (US=KiB, Fr=Kio)



Remi.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlYTvLAACgkQYUppBSnxahghugCfZzYhBzAaoHjSS4TiwYtO2Zom
oP0AoKC/vAjcQ6f4/p+LDxa3EWoQ+I8J
=V6lZ
-END PGP SIGNATURE-

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: Re: RFC proposal.

[somebody anon]

On 5 October 2015 17:42:08, Rowan Collins  wrote:

> An interesting idea. Do you have any idea of the values $format and $unit 
> would accept? Would it handle both decimal-based GB etc and binary-based GiB 
> etc [1]?
> What about other units that can be scaled in the same way, like metres? Would 
> it make more sense to make it a unit-formatting function or library - and if 
> so, does it need to be in core, or could it just be a lightweigh  Composer 
> dependency people could grab when they needed it?
> [1] https://en.m.wikipedia.org/wiki/Binary_prefix


I've implemented this function and two other size-related in php [1], but I
think they should be in php core to avoid implementation of them by
thousands of people. This draft is only for demonstation purposes. There
are presented three functions:

a. size_format([$format,] $bytes [, $unit]): string

Formats size in appropriate or specified in $unit unit like sprintf() does.
For example, default format is "%.3F Ui" which means:

   - %.3F is a sprintf-macro that will be replaced by size value

   - U means upper-cased unit (MB, GB and so on)

   - i means binary prefix

   So, formatted string will be like "1.457 KiB"

b. size_parse($string): integer

Parses string that contains size value and unit in integer containing size
in bytes.

c. size_transform(float $size, $from, $to): float

Translates size in one unit to another.


You can see examples of usage in test file [2]. They all support size units
up to YB and both decimal (GB) and binary (GiB) prefixes and can translate
size values between prefixes.


[1] https://github.com/wapmorgan/ext-size

[2] https://github.com/wapmorgan/ext-size/blob/master/test.php

Re: [PHP-DEV] Re: Windows OpCache bug fix

[Dmitry Stogov]

On Mon, Oct 5, 2015 at 6:38 PM, Anatol Belski  wrote:

>
>
> > -Original Message-
> > From: Dmitry Stogov [mailto:dmi...@zend.com]
> > Sent: Monday, October 5, 2015 3:31 PM
> > To: Anatol Belski 
> > Cc: Matt Ficken ; Pierre Joye
> > ; Laruence ; PHP Internals
> > ; dmi...@php.net
> > Subject: Re: [PHP-DEV] Re: Windows OpCache bug fix
> >
> > > > > > Subject: Re: [PHP-DEV] Re: Windows OpCache bug fix
> > > > > >
> > > > > > > Dmitry, I'd have a question to this
> > > > > > > > Also. if we can't map SHM into desired address space, we may
> > > > > > > > map it in
> > > > > > > any
> > > > > > > > other address and copy data into the process memory similar
> > > > > > > > to
> > > > > > > file-cache.
> > > > > > > In randomized memory layout, even the base were available and
> > > > > > > OpenFileMapping were worky, some parts of that memory were
> > > > > > > already
> > > > > > taken.
> > > > > > > How exactly it could be done, could you please give a couple
> > > > > > > of pointers to this?
> > > > > >
> > > > > >
> > > > > > If MapViewOfFileEx(..., wanted_mapping_base) fails, we do
> > > > > > MapViewOfFileEx(..., NULL).
> > > > > >
> > > > > >
> > > > > > > Would the file cache be always required then?
> > > > > > >
> > > > > >
> > > > > > This is not necessary, but depends on implementation of course.
> > > > > >
> > > > > Thanks for the advice. I was playing with this over these days.
> > > > > There are two usual cases where it possibly fails when reattaching
> > > > > ATM
> > > > >
> > > > > -
> > > > > https://github.com/php/php-src/blob/PHP-7.0/ext/opcache/shared_all
> > > > > oc_w
> > > > > in32.c#L151
> > > > > - the saved address is available but is not suitable
> > > > > -
> > > > > https://github.com/php/php-src/blob/PHP-7.0/ext/opcache/shared_all
> > > > > oc_w
> > > > > in32.c#L159
> > > > > - the actual MapViewOfFileEx case
> > > > >
> > > > > An unrelated plain C test shows, that MapViewOfFileEx can possibly
> > > > > fail when called second time, too. Even with NULL or with another
> > > > > address as base. But even if it could map at a different base -
> > > > > the internal structures will probably have invalid addresses.
> > > >
> > > >
> > > > right. we might need different code for zend_accle_hash access or
> > > > convert corresponding structures to PIC.
> > > > For opcdeos "invalid address" don't matter because we will copy them
> > > > into process memory and fix (like in file-cache).
> > > >
> > > Ah, I have to study the file cache code then. But generally it sounds
> > > not like something that can be done offhand. I've also thought about
> > > other things like interned strings (maybe something else), not sure
> > > they're stored with the cache.
> > >
> > > >
> > > > > So it looks like there's indeed no profit to do any retry once the
> > > > > actualy base address needed was failed to reattach to.
> > > > >
> > > > > IMHO the scenario that were usable - in case it fails to reattach
> > > > > to the exact address, it has to switch to heap. Just for one
> > > > > request, it should get a heap allocated segment and then
> invalidate all the
> > cache.
> > > > > That way we fulfill the following
> > > > >
> > > > > - the request is served for sure
> > > > > - the scripts are not cached indeed, so no divergence with the
> > > > > actual real cache
> > > > >
> > > > > A heap fallback memory handler would be probably quite easy to
> > > implement.
> > > > > What do you think?
> > > > >
> > > > > Apropos with the heap - it also looks like when PHP is used as
> > > > > module under mpm_winnt, all the cache could use heap instead of
> > > > > SHM. In that case, there is only one Apache process serving with
> many
> > threads.
> > > > > Except one would want to share that cache outside Apache, using
> > > > > heap there could be a much simpler solution.
> > > > >
> > > >
> > > > Heap based cache makes the same problems. It increase the memory
> > > > usage
> > > and
> > > > doesn't provide cache consistency.
> > > > Just fall-back to file-cache may be better.
> > > Do you think something like this would suffice as file cache fallback
> > > https://gist.github.com/weltling/224001a468f04de13693  ? Though it'd
> > > still diverge from the "main" cache.
> > >
> >
> > I think we should enable file-cache automatically, but we can set
> > ZCG(accel_directives).file_cache_only
> > if the file_cache already enabled.
> >
> I've revoked the approach
> https://gist.github.com/weltling/69bd1e47dc15273edde5 , also added
> enforcement per request (was missing in the previous version). Or did you
> mean "we should NOT enable file cache automatically"? Can be easy changed
> ofc. IMHO one can enforce automatically, careful programmers do check error
> logs :)
>


I wouldn't enable file cache automatically, but this really not an
implementation problem.

+   if (NULL != ZCG(accel_directives).file_cache) {
+   ZCG(accel_directives).file_cache_only = 1;
+   }



>
> >
> > >
> 

Re: [PHP-DEV] Re: Windows OpCache bug fix

[Dmitry Stogov]

Hi Eric,


On Mon, Oct 5, 2015 at 9:49 PM, Eric Stenson  wrote:

> >From: Dmitry Stogov [mailto:dmi...@zend.com]
> >
> >> On Thu, Oct 1, 2015 at 11:54 AM, Matt Ficken 
> >> wrote:
> >>
> >>> Pierre Joy wrote:
> >>> And what wincache does. It is slower but the request is served.
> >>
> >> WinCache (file cache) if it can't reattach, creates a new shared mem
> >> file
> >
> > I'm not sure how WinCache works, but opcache already implements most
> > necessary functionality.
>
> Sorry for getting to the party late, but let me clarify what WinCache does:
>
> 1. For the opcode cache, if WinCache can't map to the same address, it
> falls back to using process-local (heap) memory for the opcode arrays.
> This is because the elements in the opcode arrays contain absolute
> pointers, and we don't want to spend cycles (a) converting all pointers to
> offsets when copying opcode arrays into shared memory, and then (b)
> converting all offsets back to absolute addresses when copying the opcode
> array back out of shared memory.  WinCache simply gets the pointer to the
> opcode array in shared memory and returns it, unmodified, to the PHP Core
> for execution.
>

Opcache uses the same strategy,.


> When WinCache falls back to process-local memory, it does NOT create a
> second memory mapped segment, and does not chew additional cross-process
> resources.
>

Opcahce but don't have a fall-back mechanism in case of inability to remap
SHM into the same address space


> 2. WinCache's file cache does not map to an identical address in all
> processes.  We simply map it to *any* address (using NULL for the suggested
> address to MapViewOfFileEx), and then use relative offsets in the cache
> structures for all entries in shared memory.
>

File-cache in opcache is a second level opcode cache. Instead of SHM (or in
addition to SHM) we may store precompiled php scripts on disk.

Thanks. Dmitry.


>
> 3. WinCache's user cache and session cache are similar to the file cache,
> and do not have to map to the same address in all processes. Cache entries
> use relative offsets to locate cache entries, and the values do not contain
> absolute addresses.
>
> Finally, For PHP7, WinCache has removed its opcode cache.  We assume that
> Windows consumers of PHP7 will use Zend Opcache for opcode caching.
>

>
>
> Thx!
> --E.
>

Re: [PHP-DEV] Re: Windows OpCache bug fix

[Dmitry Stogov]

On Tue, Oct 6, 2015 at 9:27 AM, Matt Ficken  wrote:

> Ultimately if the 2nd OpCache is shared in a new SHM, in-process in a new
> SHM or in-process Heap, memory will increase, scripts have to be recompiled
> and there are consistency issues. File-cache will avoid recompiling
> scripts, but unless OpCache is disabled, there needs to be a 2nd OpCache
> stored somewhere.
>
> For the stat, reset and revalidate consistency issues, to build off
> Anatol's idea:  If can't reattach to base address, then reattach to any
> address and create a 2nd OpCache in Heap, BUT keep the SHM open so that the
> stat fields(fe ZCSG(hits)) are still accessible. Those fields aren't
> pointers so they should work from whatever base address MapViewOfFileEx()
> provides, if not, could fork ZCSG into 2 structs (somehow reuse existing
> stat fields on existing SHM).
>
> opcache_get_status() in any/all processes would read those fields from SHM.
>
>
> Since there would be 2+ processes with an OpCache (the original in SHM,
> and sidestep OpCaches on the heaps of those processes), can't use a simple
> flag (would be cleared by 2nd process, before 3rd got it).  Could add
> ZCSG(opcache_count) field and increment every time an OpCache gets created
> (and decrement on process exit). Simple, but not using
> zend_shared_alloc_lock() avoids creating new locking issues.
>
> Add a new ZCSG(opcache_revalidate_count) in that struct that is set to
> ZCSG(opcache_count) anytime opcache_reset() or opcache_invalidate() called
> or if persistent_compile_file() finds a changed script.
>

This way work. Actually, it's even possible clean opcoache SHM completely
or invalidate individual files with SHM mapped into different address. Of
course it shpuld be implemented, and I don;t know all the problems yet.


>
> In process with side-step OpCache,  in persistent_compile_file()
> (assuming opcache.validate_timestamps && revalidate_freq>0) will check if
> ZCSG(opcache_revalidate_count) > 0 and will then decrement the count and
> reload scripts from file-cache (where it checks opcache.revalidate_freq).
> And then wrap this all in some `#ifdef ZEND_WIN32`s
>
>
> Would still have extra memory usage. When I have a process that can't
> reattach I usually get several, so having an in-process OpCache(SHM or
> Heap) may lead to more memory usage than a shared SHM, but having 2 SHMs in
> a process would mess up the nice existing code.
>

What extra memory? Do you mean in-process memory for op_arrays during
request processing?


>
> Don't have to recompile scripts(quickly loads from file-cache) and fixes
> the 3 consistency issues, and would keep serving up requests without
> performance loss.
>
> Yes, temporary incomplete solutions often get forgotten and not replaced
> later with a better complete solution, but in this case we're motivated try
> to fully fix this whole issue and if that doesn't work, at least build a
> more complete solution, but that takes time (known issue for already a few
> years), we should do something that works for now. This is more complex
> than a bugfix that creates a 2nd SHM OpCache. Can we do this now? What is
> still possible for 7.0? 7.0.1?
>

If we understand each other properly, It looks like a more or less
consistent solution now.
This is going to be a self-contained change, so I don't see big problems
releasing some fix for PHP-7.0 branch even after GA 7.0.0 release.
Of course, we may make final decision only after complete implementation.

Thanks. Dmitry.



>
>
>
> On Mon, Oct 5, 2015 at 11:49 AM, Eric Stenson 
> wrote:
>
>> >From: Dmitry Stogov [mailto:dmi...@zend.com]
>> >
>> >> On Thu, Oct 1, 2015 at 11:54 AM, Matt Ficken 
>> >> wrote:
>> >>
>> >>> Pierre Joy wrote:
>> >>> And what wincache does. It is slower but the request is served.
>> >>
>> >> WinCache (file cache) if it can't reattach, creates a new shared mem
>> >> file
>> >
>> > I'm not sure how WinCache works, but opcache already implements most
>> > necessary functionality.
>>
>> Sorry for getting to the party late, but let me clarify what WinCache
>> does:
>>
>> 1. For the opcode cache, if WinCache can't map to the same address, it
>> falls back to using process-local (heap) memory for the opcode arrays.
>> This is because the elements in the opcode arrays contain absolute
>> pointers, and we don't want to spend cycles (a) converting all pointers to
>> offsets when copying opcode arrays into shared memory, and then (b)
>> converting all offsets back to absolute addresses when copying the opcode
>> array back out of shared memory.  WinCache simply gets the pointer to the
>> opcode array in shared memory and returns it, unmodified, to the PHP Core
>> for execution.
>>
>> When WinCache falls back to process-local memory, it does NOT create a
>> second memory mapped segment, and does not chew additional cross-process
>> resources.
>>
>> 2. WinCache's file cache does not map to an identical address in all
>> processes.  We simply map it to *any* address (using NULL for th