Re: [PHP-DEV] opcache.file_cache_only = 1 disables Opcode Caching
Hey: On Tue, Dec 29, 2015 at 3:31 PM, Tom Sommer wrote: > Awesome feature with opcache.file_cache_only, really exciting :) > > A couple of things: > > 1) It's not documented in the manual > yes, it's an experimental feature now > > 2) When you set opcache.file_cache_only = 1, the "Opcode Caching" > information in phpinfo() disappears. > "Opcode Caching" and "Optimization" is shown as "Disabled". Is this > intended? > fixed in : https://github.com/php/php-src/commit/3f07a256f75a55eaf7e7bfed681f8dfb4b901e55 now it will print: Zend OPcache Opcode Caching => Up and Running Optimization => Enabled SHM Cache => Disabled File Cache => Enabled Startup => OK thanks > Thanks :) > > // Tom > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- Xinchen Hui @Laruence http://www.laruence.com/
[PHP-DEV] opcache.file_cache_only = 1 disables Opcode Caching
Awesome feature with opcache.file_cache_only, really exciting :) A couple of things: 1) It's not documented in the manual 2) When you set opcache.file_cache_only = 1, the "Opcode Caching" information in phpinfo() disappears. "Opcode Caching" and "Optimization" is shown as "Disabled". Is this intended? Thanks :) // Tom -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Make strict mode more strict?
Hi (all), On Mon, Dec 28, 2015 at 3:40 PM, Yasuo Ohgaki wrote: > Hi all, > > On Tue, Dec 29, 2015 at 5:28 AM, Yasuo Ohgaki wrote: > > Object(class) is type, so it makes sense checking class consistency. If > we > > check object's class, not only the class but also ancestor classes > should be > > checked. This may affect performance. > > I'm not sure if this worth the effort. > > It sounds negative, so I correct this. > > Since we have class type hint, it better to support class check. IMO. > Almost all cases are simple class equality check. So it wouldn't hurt > performance much, I suppose. > > Regards, > > -- > Yasuo Ohgaki > yohg...@ohgaki.net > I think that it would be worthwhile to get either a RFC or some test code on this, the latter depending on how you would assess the difficulty. The feature itself has a huge demand and goes along the lines of current development. If something could be developed, then we could assess performance. I would estimate it to be small, however in any case the feature is optional. We're not anymore considering to increase the size of the z-val. The feature has 2 stages, one of which would be drastically easier to implement and would show us about performance. Stage 1 - typing only objects already set by comparing classes upon assignment, if set a particular mode Stage 2 - Adding some form of language hint, which will require a parser and some method of storing the class hint for null objects. The latter has a proposed solution not sounding hard to implement, but modifying the parser sound like a more difficult step.
Re: [PHP-DEV] RFC proposal for alternative list syntax
Hi Thanks all for the feedback - I'm posting back to get some "RFC karma" for my newly created wiki account please - so I can post my RFC - username is "julian" Thanks Regards Julian From: Kris Craig Sent: 28 December 2015 18:40 To: Pierre Joye Cc: PHP internals list; Julian Rhind; Stanislav Malyshev Subject: Re: [PHP-DEV] RFC proposal for alternative list syntax On Dec 27, 2015 7:56 PM, "Pierre Joye" mailto:pierre@gmail.com>> wrote: > > On Mon, Dec 28, 2015 at 6:20 AM, Stanislav Malyshev > mailto:smalys...@gmail.com>> wrote: > > Hi! > > > >> // With the new array syntax this has been improved to > >> > >> list ($a, $b) = [1, 2]; > >> > >> // I think this new syntax should logically extend to > >> > >> [$a, $b] = [1, 2]; > > > > list() and array() are two different language constructs, using the same > > syntax for them is a bad idea. > > I tend to agree here but it exists elsewhere and is quite handy. Also > the behavior of this expression, in this case, is obvious. > > > Cheers, > -- > Pierre > > @pierrejoye | http://www.libgd.org > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > This could be very nice shortcut to have. Seems intuitive enough; I doubt there'd be any serious confusion over this. You should draft an RFC for this, OP. --Kris
Re: [PHP-DEV] Make strict mode more strict?
Hi all, On Tue, Dec 29, 2015 at 5:28 AM, Yasuo Ohgaki wrote: > Object(class) is type, so it makes sense checking class consistency. If we > check object's class, not only the class but also ancestor classes should be > checked. This may affect performance. > I'm not sure if this worth the effort. It sounds negative, so I correct this. Since we have class type hint, it better to support class check. IMO. Almost all cases are simple class equality check. So it wouldn't hurt performance much, I suppose. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Make strict mode more strict?
Hi Elijah,
On Tue, Dec 29, 2015 at 12:47 AM, Elijah Johnson wrote:
> The mode "stack-mode-static-object-types" would ideally also prevent
> assignment of an object with a current string value, or string placeholder
> value. What I mean by placeholder value - an additional z-val type "t"
> returning true for IS_NULL, where the class name id is stored in value
> union. This would be declared by type hint ex. MyObject $object; If the
> variable is assigned, MyObject $object = ...; then potentially the same.
>
> On assignment would look something like this (pseudo-code):
>
> bool checkType(zVal, newZVal)
> {
> bool throw_error = false;
> if (MODE_STACK_TYPE_OBJECT)
> {
>if (isObjectType(zVal))
>{
> int class_id= GET_PLACEHOLDER_CLASS(zVal);// ie.
> zVal.value or value of current object
> if (class_id !== GET_CLASS(newZVal))
> {
>throw_error = true;
> }
>} else if (IS_OBJECT(newZVal) && !IS_NULL(zVal){
> throw_error = true; // assigning an object to a non-null,
> non-object
>}
> }
> if (throw_error)
> {
> // assign to null, generate TypeError
> // ie. Warning: assign of type to type, assigned null value
> return false; // prevent assignment by caller
> }
> return true
> }
>
> Some additional checks would likely be necessary to prevent placeholders
> from being assigned and returned, and if strict mode was implemented, there
> would need to be a second placeholder type (or some other means of
> identification such as a constant).
>
> Implementing placeholders isn't a necessary step, but it would make for
> very readable code.
Now I understand why you think zval modification is needed and concern
about performance. My proposal checks basic types simply. i.e. Only
checks if a variable is object type or not. Simple and quick.
Object(class) is type, so it makes sense checking class consistency. If we
check object's class, not only the class but also ancestor classes should be
checked. This may affect performance.
I'm not sure if this worth the effort.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Throwable::addSuppressed()
On 28 July 2015 at 21:33, Markus Malkusch wrote: > Hi PHP > > So I read that there's this Throwable interface coming. Great! How about > extending it with: > > void Throwable::addSuppressed(Throwable exception) > > Throwable[] Throwable::getSuppressed() > > So PHP, what do you think, might a RFC find acceptance? Yes. Are you going to write an RFC for it? If not, do you mind if I start writing the RFC with you either listed as co-author or 'the ideas guy' ? cheers Dan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Multicatch RFC proposal
On 24 December 2015 at 22:40, Bronisław Białek wrote:
> Hello everyone!
>
> I've just created an RFC draft for catching multiple exception types
> in one catch statement:
> https://github.com/bronek89/php-multicatch-rfc
>
> I wrote RFC on github to check if there is any positive response from
> community.
>
> Basically it introduces possibility to write code such as:
>
> try {
> // ...
> } catch (DbException | ResourceNotFoundException $e) {
> throw new HttpException("not found", 404, $e);
> } catch (\Throwable $e) {
> throw new HttpException("fail", 500, $e);
> }
>
> Provided patch is my first experience with PHP source code, so it
> could be not perfectly written (or simply poor ;-) ) .
>
> What do you think about introducing that kind of feature into PHP?
>
Yes, please. The alternative work-arounds are not as good.
Though I also am concerned about it getting in the way of other
proposals, I don't think it would be an issue. The meaning of the
syntax in your example is pretty obvious. So the only way it could be
a problem is if another RFC proposed a different and 'not as obvious'
meaning.
cheers
Dan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Make strict mode more strict?
Some additional observations -
On Mon, Dec 28, 2015 at 10:03 AM, Elijah Johnson wrote:
> Thanks,
>
> On Mon, Dec 28, 2015 at 6:34 AM, François Laupretre
> wrote:
>
>> Hi,
>>
>> Le 26/12/2015 21:35, Elijah Johnson a écrit :
>>
>>> Can you explain your statement that this would be a huge and complex
>>> work? You must mean that there would be multiple places in the php source
>>> code where variables are assigned? I'm not yet discussing performance, but
>>> only the aspect of adding the feature.
>>>
>>
>> There may other options I don't know but, AFAIK, this implies adding an
>> optional type hint at the zval level. This type hint should be verified at
>> least before each conversion. Copy-on-write is an other issue, as it is
>> currently not compatible with zval type hints. Seeing only variables with
>> well-defined names, and focusing on arrays, only scratches the surface.
>> Everything happens at the zval level. So, IMO, attaching type hints to
>> variables and properties is a huge and complex work.
>>
>> Regards
>>
>> François
>>
>
> I think I see what you are saying. Copy on write takes a reference to the
> entire z-val in two local variables, so a type-hint at the z-val level
> would be shared.
>
> This returns us to the insight of the original mailer who suggested that
> an object or array variable should be typed by its first-assigned object.
> This would simply need to be a global mode - stack-mode-legacy,
> stack-mode-static-object-types, and stack-mode-super-strict for those who
> want basic types also.
>
> I'm not saying that this is ideal, just that we need to compromise a bit
> to accommodate our existing code base and performance issues.
>
> The proposal for an additional z-val which stores the class name in the
> zval.value member and is counted as null could accommodate the case where
> the user wants to assign the type before he has an object.
>
> I think this is the best option. Another theory I had was to store the
> types at the context level in some kind of array, but its really too much.
>
> The idea just now proposed of 3 global modes will eliminate the issue of
> storing at the z-val level. The mode "stack-mode-static-object-types" is
> even already compatible with every line of code that I have properly
> written in PHP.
>
The mode "stack-mode-static-object-types" would ideally also prevent
assignment of an object with a current string value, or string placeholder
value. What I mean by placeholder value - an additional z-val type "t"
returning true for IS_NULL, where the class name id is stored in value
union. This would be declared by type hint ex. MyObject $object; If the
variable is assigned, MyObject $object = ...; then potentially the same.
On assignment would look something like this (pseudo-code):
bool checkType(zVal, newZVal)
{
bool throw_error = false;
if (MODE_STACK_TYPE_OBJECT)
{
if (isObjectType(zVal))
{
int class_id= GET_PLACEHOLDER_CLASS(zVal);// ie.
zVal.value or value of current object
if (class_id !== GET_CLASS(newZVal))
{
throw_error = true;
}
} else if (IS_OBJECT(newZVal) && !IS_NULL(zVal){
throw_error = true; // assigning an object to a non-null,
non-object
}
}
if (throw_error)
{
// assign to null, generate TypeError
// ie. Warning: assign of type to type, assigned null value
return false; // prevent assignment by caller
}
return true
}
Some additional checks would likely be necessary to prevent placeholders
from being assigned and returned, and if strict mode was implemented, there
would need to be a second placeholder type (or some other means of
identification such as a constant).
Implementing placeholders isn't a necessary step, but it would make for
very readable code.
Re: [PHP-DEV] Make strict mode more strict?
Thanks, On Mon, Dec 28, 2015 at 6:34 AM, François Laupretre wrote: > Hi, > > Le 26/12/2015 21:35, Elijah Johnson a écrit : > >> Can you explain your statement that this would be a huge and complex >> work? You must mean that there would be multiple places in the php source >> code where variables are assigned? I'm not yet discussing performance, but >> only the aspect of adding the feature. >> > > There may other options I don't know but, AFAIK, this implies adding an > optional type hint at the zval level. This type hint should be verified at > least before each conversion. Copy-on-write is an other issue, as it is > currently not compatible with zval type hints. Seeing only variables with > well-defined names, and focusing on arrays, only scratches the surface. > Everything happens at the zval level. So, IMO, attaching type hints to > variables and properties is a huge and complex work. > > Regards > > François > I think I see what you are saying. Copy on write takes a reference to the entire z-val in two local variables, so a type-hint at the z-val level would be shared. This returns us to the insight of the original mailer who suggested that an object or array variable should be typed by its first-assigned object. This would simply need to be a global mode - stack-mode-legacy, stack-mode-static-object-types, and stack-mode-super-strict for those who want basic types also. I'm not saying that this is ideal, just that we need to compromise a bit to accommodate our existing code base and performance issues. The proposal for an additional z-val which stores the class name in the zval.value member and is counted as null could accommodate the case where the user wants to assign the type before he has an object. I think this is the best option. Another theory I had was to store the types at the context level in some kind of array, but its really too much. The idea just now proposed of 3 global modes will eliminate the issue of storing at the z-val level. The mode "stack-mode-static-object-types" is even already compatible with every line of code that I have properly written in PHP.
Re: [PHP-DEV] Make strict mode more strict?
Hi, Le 26/12/2015 21:35, Elijah Johnson a écrit : Can you explain your statement that this would be a huge and complex work? You must mean that there would be multiple places in the php source code where variables are assigned? I'm not yet discussing performance, but only the aspect of adding the feature. There may other options I don't know but, AFAIK, this implies adding an optional type hint at the zval level. This type hint should be verified at least before each conversion. Copy-on-write is an other issue, as it is currently not compatible with zval type hints. Seeing only variables with well-defined names, and focusing on arrays, only scratches the surface. Everything happens at the zval level. So, IMO, attaching type hints to variables and properties is a huge and complex work. Regards François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Wiki access
On Sun, Dec 27, 2015 at 2:03 PM, Guy Sheffer wrote: > Hey all, > I wanted to get wiki access to update the IRC channel here: > https://wiki.php.net/internals/windows > > From: > #php-dev-win > > to: > #winphp-dev > > which is the right one to go to. > > I've been the windows integration engineer Zend for little more than a year > and this is where we did our coordination. > > Thanks, > Guy Sheffer > guysoft > hi, I've assigned you into the appropriate wiki group, but I've just realized that it doesn't have karma to edit the https://wiki.php.net/internals/windows page, only the subpages. I've updated the group acl so now that page is also allowed for the group, but this change needs some time to be propagated, usually under an hour or so. Let me know if you still can't edit that page even after waiting an hour. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
