Re: [PHP-DEV] [DICUSS]Cleanup resource handling APIs
Hi! as you can see, we use r to receive a IS_RESOURCE type, that means, check the type in ZEND_FETCH_RESOURCE is overhead.. Except that some functions could receive z and decide if it's the resource or not afterwards... But I guess you could rely on the code that decides it to check. Some code would crash (or produce some very bad memory corruption) if somebody would forget to add this check when porting such extension. Is saving one branch worth it? ZEND_API void *zend_fetch_resource(zval *passed_id, int default_id, const char *resource_type_name, int *found_resource_type, int num_resource_types, ...) we use va_args to passing resource type, that means, the rescue type arguments can not be passed by register but by stack.. which is a little low effiicient . Is it that bad? Functions are passing arguments via the stack all around. The interface with fetch(), fetch2(), fetch3(), fetch4(), etc. looks a little clunky. As for storing the value directly instead of having the list - it would work for all cases except for two important ones: 1. Persistent resources - they need to be stored somewhere, and not in zvals that are supposed to be dead at the end of the request. 2. Cleanup at the end for non-persistent ones - zvals may be lost and not destructed in many exceptional situations. Not destructing the resource may mean having a stale lock forever or consuming connections or handles, etc. So there should be some mechanism allowing for destroying all resources that are transient. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Question regarding stream wrappers and op code cache
Hi Cesar, On 4 February 2015 at 07:26, Cesar Rodas ce...@rodas.me wrote: Hi Guys, I have a doubt, is it efficient include/require files from a source different than the real file system a stream wrapper class? My question is, would the op-code cache work as it would when reading a file form the filesystem? Yes it works if you are using 'phar' stream wrapper, the rest wrappers are not cached, @see https://github.com/php/php-src/blob/master/ext/opcache/ZendAccelerator.c#L138-L142 This RFC: https://wiki.php.net/rfc/streams-is-cacheable is aim to remove the restriction and allow stream wrapper itself to decide should it been cached by opcache. Cheers, -- César D. Rodas Open Source developer +595-983-161124 PGP: F9ED A265 A3AB C8A1 D145 7368 158A 0336 C707 0AA6
Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2
Hi Andrea, In you proposal you disable declaration of classes with names, that may be used for scalar type hints - Int, Float, ... What do you think about using only lowercase type names for scalar type hints? In this case we won't have to introduce any limitations. function foo(int $a) // expects integer function foo(Int $a) // expects instance of class Int Thanks. Dmitry. On Tue, Feb 3, 2015 at 12:40 AM, Andrea Faulds a...@ajf.me wrote: Hey everyone, On 2 Feb 2015, at 16:50, Andrea Faulds a...@ajf.me wrote: The implementation does work for testing. I still need to write tests for return types but they seem to work. Parameter types are fully-working, though, and they have extensive tests, so I know they’re working fine and you could add them to an existing project. Strictifying an existing library is a good idea. I’ll try “strictifying” one of my bigger personal projects (PictoSwap, a 3DS browser application with a PHP backend) and see how it goes. I expect it’ll be fairly smooth, we’ll see. I just went and did this on PictoSwap, it was fairly painless. It’s quite a small application, to be fair, but it is “real-world code”. First, I compiled my branch with the following configure command: YACC=/usr/local/opt/bison27/bin/bison ./configure --enable-debug --enable-phpdbg --disable-all --with-gd --enable-pdo --with-sqlite3 --with-pdo-sqlite --enable-session --enable-json Ignore the YACC=, I only need to do that because OS X is weird. As you can see, PictoSwap requires Gd, PDO-SQLite, Session and JSON. Then, I ran my site with the freshly-compiled version of PHP. Actually, that’s not quite true - I compiled several times, each time finding an error because of a missing extension. Eventually I got to this configure line which included all the ones my app needed. Second, I added declare(strict_types=1); to each file along with type hints. I did this file by file, and tested with each file. For most of the files, nothing was broken by the addition of strict type hints. However, some files did cause issues. When I added hints to my graphics functions in include/graphics.php and turned on strict types, I got an error because of a type mismatch, which lead to me discovering a bug. It turns out I’d been assuming that gd takes float pixel positions, but it actually takes integer pixels! This means that those crucial .5s had been truncated off all this time, and I was none-the-wiser. I added explicit integer casts. Now it’s obvious that the results are being truncated. Adding strict hints to include/user.php, which includes the “business logic” as such turned up the most issues. It showed me a few different things. One thing I learned was that return types are crippled by the lack of nullable returns. For most of my functions, I need to return TRUE (success) or a string (error message). I’d be fine with switching to NULL (success) or string (error) so it’s hintable, but I can’t actually do that, because we lack nullable returns. That means I’m omitting return types on most of my functions, unfortunately. I hope that the Nullable Types RFC can pass and fix this. Another thing I learned was how I really needed to convert the values going into and coming out of my database (SQLite 3, in this case). Turns out most of the data in there was strings, as SQLite is dynamically-typed, and so my JSON output was ending up filled with strings, where it should have had numbers or booleans. Type mismatch errors allowed me to spot where this was happening. It’s only because JavaScript is similarly merciful to PHP that my web app worked at all! I also learned that my session data didn’t have correct types: the user ID had ended up a string, not an integer. This was trivially fixed, but something I wouldn’t have noticed without strict typing. Now, the addition of type hints to include/user.php broke my web-facing code (htdocs/api.php), because I wasn’t converting types properly. However, this only broke it when it used strict typing mode. If I turned off strict typing mode, as I expected, PHP happily converted the types and everything worked swimmingly. The fixes weren’t that difficult, but not having to make everything strict at once made adding type hints easier, because I could disable strict types in code that wasn’t yet ready and my app would keep running fine, then turn on strict types one it was updated. The end result of this was better code, and I spotted some errors. The migration was eased, as I had hoped, by the ability to make some files strict and others weak. It also shows that my web app works fine without modifications on PHP 7, which is great. Admittedly, my web app is quite small. But I think this makes a good case for the usefulness of this RFC, and in particular of the declare() system, and strict hints vs. weak hints. :) You can see the diff here:
RE: [PHP-DEV] [VOTE] Feature request #38685: str_[i]replace(): Add support for (string needle, array replace)
De : yohg...@gmail.com [mailto:yohg...@gmail.com] De la part de Yasuo Ohgaki On Tue, Feb 3, 2015 at 2:00 AM, François Laupretre franc...@tekwire.net wrote: Opening the vote for : https://wiki.php.net/rfc/cyclic-replace I guess you mean discussion? Actually, I wanted to open the vote, as discussion took place one month ago. But, as people seem to discover the RFC, yes, we're starting another discussion. Cheers François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [DICUSS]Cleanup resource handling APIs
Hey:
On Mon, Feb 2, 2015 at 1:34 PM, Xinchen Hui larue...@php.net wrote:
Hey:
we used to use lval of zval as a handle to access resource type..
but now, we introduced a new type IS_RESOURCE, which make the
handle(id) sort of redundant .
further more, the common usage when handling resource is like:
if (zend_parse_parameters(ZEND_NUM_ARGS(), rl, result,
offset) == FAILURE) {
return;
}
ZEND_FETCH_RESOURCE(mysql_result, MYSQL_RES *, result, -1, MySQL
result, le_result);
as you can see, we use r to receive a IS_RESOURCE type, that
means, check the type in ZEND_FETCH_RESOURCE is overhead..
and:
ZEND_API void *zend_fetch_resource(zval *passed_id, int default_id,
const char *resource_type_name, int *found_resource_type, int
num_resource_types, ...)
we use va_args to passing resource type, that means, the rescue
type arguments can not be passed by register but by stack.. which is a
little low effiicient .
so, I'd like propose a zend_resource handling API cleanup..
1. DROP ZEND_REGISTER_RESOURCE/FETCH_RESOURCE.
2. add :
ZEND_API void *zend_fetch_resource(zend_resource *res, const
char *resource_type_name, int resource_type);
ZEND_API void *zend_fetch_resource2(zend_resource *res, const char
*resource_type_name, int *found_type, int resource_type, int
resource_type2);
ZEND_API void *zend_fetch_resource_ex(zval *res, const char
*resource_type_name, int resource_type);
ZEND_API void *zend_fetch_resource2_ex(zval *res, const char
*resource_type_name, int *found_type, int resource_type, int
resource_type2);
a underworking patch could be found at:
https://github.com/php/php-src/pull/1042
any ideas objections?
thanks
merged, all tests passes.
thanks
--
Xinchen Hui
@Laruence
http://www.laruence.com/
--
Xinchen Hui
@Laruence
http://www.laruence.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Scalar Type Hints v0.2
Am 04.02.2015 um 06:44 schrieb Dmitry Stogov: What do you think about using only lowercase type names for scalar type hints? In this case we won't have to introduce any limitations. This would be inconsistent with the rest of PHP being case-insensitive and only lead to confusion. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE] Removal of dead or not yet PHP7 ported SAPIs and extensions
Hi! I am kind of surprised that RFC about removing whole extensions has Backward Incompatible Changes listed as None. Really? No BC impact whatsoever by removing imap and mcrypt? Literally nobody ever anywhere is using it? - ext/imap and ext/mcrypt: while I realise that the underlying libraries are dead, these extensions are too widely used to straight up remove them, I fear — we don't have obvious alternatives with simple enough APIs that we can push users towards. I'd strongly support and encourage a reimplementation of these extensions (in C or PHP) around something supported if someone was able to step up and do the work, otherwise yes, I'll pitch in to do the minimal work to port these to 7.0 if required. IIRC imap is working with PHP 7 and passes the tests on CI currently. mcrypt seems to be enabled on CI too. So what is needed for them for 7.0? -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [RFC][VOTE] Removal of dead or not yet PHP7 ported SAPIs and extensions
Anatol Belski in php.internals (Mon, 2 Feb 2015 20:11:20 +0100): properly after the voting phase the https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts moves to the voting. Each item is voted separately. ext/ereg needs a fix before it can be moved to PECL. The TS build --with-ereg=shared currently fails: Creating library C:\php-sdk\php70dev\Release_TS\php_ereg.lib and object C:\php-sdk\php70dev\Release_TS\php_ereg.exp ereg.obj : error LNK2001: unresolved external symbol __tsrm_ls_cache C:\php-sdk\php70dev\Release_TS\php_ereg.dll : fatal error LNK1120: 1 unresolved externals Jan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [DICUSS]Cleanup resource handling APIs
Hey:
On Tue, Feb 3, 2015 at 12:37 AM, François Laupretre
franc...@tekwire.net wrote:
De : Xinchen Hui [mailto:larue...@php.net]
furthermore, I'd like to discuss remove the handle in zend_resource struct..
it may breaks some usage (use resource as long/double/string)
case IS_RESOURCE: {
char buf[sizeof(Resource id #) + MAX_LENGTH_OF_LONG];
int len;
len = snprintf(buf, sizeof(buf), Resource id #
ZEND_LONG_FMT, (zend_long)Z_RES_HANDLE_P(op));
return zend_string_init(buf, len, 0);
}
I don't understand how you can delete the resource if you remove the handle
from the zend_resource struct. Or would you store the index elsewhere ?
if you use HashTable , yes, it's hard to get rid of it, but we can
hidden it from user land..
and actually, we only use integer index of regular_list for zend_resource..
if we decide to remove handle, then it maybe easy to re-implement it
as a plain c array like zend_resource[];
and when doing realloce, we allocate new segment, and link them togther. etc
thanks
Regards
François
--
Xinchen Hui
@Laruence
http://www.laruence.com/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PS(invalid_session_id) ?
Hi Pierre, On Wed, Feb 4, 2015 at 9:08 AM, Pierre Joye pierre@gmail.com wrote: Please add them (and maybe example migration code) to UPGRADING.INTERNALS Got it! I'll add it to UPGRADING soon. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] What do we need strict scalar type hints for?
On Tue, Feb 3, 2015 at 7:14 PM, Andrea Faulds a...@ajf.me wrote: Hi Dmitry, On 3 Feb 2015, at 04:07, Dmitry Stogov dmi...@zend.com wrote: I have similar opinion. Strict typing looks foreign for PHP. It is in a way, yes. PHP has traditionally been “weakly-typed” everywhere. That being said, we’re not always weakly-typed (there are strict type checks in some places), and userland code has sometimes done strict type checks anyway. I see, strict type hints may be useful. Aspecially for testing and error detection, but anyaway, I'm not sure if and how it should be enabled. Declare() is a working solution, but it's not excelent. It’s not a perfect solution, but I haven’t seen anything that seems to be much better. The best bit about declare() is that it would make strict types completely optional, so people who don’t like them wouldn’t have to use them, even if they call code which does. I agree. It's probably the best solution that we saw. But it's still not good enough, It would be great to make the obvious part of the proposal accepted first. I would suggest to make two separate voting questions. 1) Enable scalar type hinting with standard rules. 2) In addition enable strict type hinting triggered by declare(). Thanks. Dmitry. -- Andrea Faulds http://ajf.me/
Re: [PHP-DEV] What do we need strict scalar type hints for?
Hi Yasuo, You probably talk about https://wiki.php.net/rfc/expectations I wasn't the author of idea, I just helped with thoughts and implantation. I think it may be useful for PHP7. Thanks. Dmitry. On Tue, Feb 3, 2015 at 11:12 PM, Yasuo Ohgaki yohg...@ohgaki.net wrote: Hi Dmitry, On Mon, Feb 2, 2015 at 6:12 PM, Dmitry Stogov dmi...@zend.com wrote: could you please write down few use cases, when strict scalar type hints are really useful. I'm not opposing to have scalar type hints, but assertion can do better job for it. I think you have proposed assert() w/o runtime overhead. Is this included in PHP7? Enable by opcache, perhaps? Sorry for OT. I'm curious. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] What do we need strict scalar type hints for?
Hi Dmitry, On Wed, Feb 4, 2015 at 2:36 PM, Dmitry Stogov dmi...@zend.com wrote: You probably talk about https://wiki.php.net/rfc/expectations I wasn't the author of idea, I just helped with thoughts and implantation. I think it may be useful for PHP7. Thank you for the info. It would be great to have it for PHP7 indeed. I'm looking forward to vote. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
RE: [PHP-DEV] Re: [DICUSS]Cleanup resource handling APIs
De : Xinchen Hui [mailto:larue...@php.net] I don't understand how you can delete the resource if you remove the handle from the zend_resource struct. Or would you store the index elsewhere ? if you use HashTable , yes, it's hard to get rid of it, but we can hidden it from user land.. and actually, we only use integer index of regular_list for zend_resource.. if we decide to remove handle, then it maybe easy to re-implement it as a plain c array like zend_resource[]; and when doing realloce, we allocate new segment, and link them togther. Anyway, IMO, moving resources from HashTable to a plain C array is a good thing. Allocating segments of 20 structs, for instance, would be fine as a single segment would fit 99.9 % of the cases. This way, you could even compute a pseudo resource handle from the zend_resource address (for var_dump()). The only additional thing you would need is a field to mark the resource as deleted/invalid. But setting ptr to NULL and type to -1 would be probably enough. I am interested in the subject of resources because I just implemented a resource abstraction layer in php-ext-gen (https://github.com/flaupretre/php-ext-gen). The objective being to use the same user code for PHP 5 and 7. Maybe you can have a look at the project and give me your opinion. Regards François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What do we need strict scalar type hints for?
Am 04.02.2015 um 08:25 schrieb Dmitry Stogov: The idea of that RFC was an ability to have zero-cost assert(). But an assert() is still in the body of a function or method and not part of its signature. That is what I want scalar type declarations for. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE] Removal of dead or not yet PHP7 ported SAPIs and extensions
Hi! We keep discussing how to improve security, make php safer by default, etc. But for IMAP, you basically open the door with a big shield saying come in, we have free cooking and you can do almost all you want inside via this door. This is insane. If it was only up to me I would kick it out of core right now due to the critical issue it has. Which critical issue? I see no security issues listed in the bug DB for imap. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] $http_response_header
Hi! About $php_errormsg , we have error_get_last(). About $http_response_headers, we have no replacement. Why not get rid of both ? I agree. Magically appearing variables are bad design and if we can get rid of them, PHP 7 is the time. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE] Removal of dead or not yet PHP7 ported SAPIs and extensions
Hi! Libmcrypt is a dead cow but not much of a threat for now. On the other hand cclient is dangerous, it should have been removed long time ago already. I'm not sure - what is the dangerous part? Are you referring to some published CVEs or other reports? Then it would be useful to list them here and on the RFC. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Question regarding stream wrappers and op code cache
De : Cesar Rodas [mailto:ce...@rodas.me] I have a doubt, is it efficient include/require files from a source different than the real file system a stream wrapper class? My question is, would the op-code cache work as it would when reading a file form the filesystem? I understand your question but, yes, the feature is essential to packages systems like phar and phk (and it is useless for most other stream wrappers). Package systems distribute a virtual file tree, handle stat(), and returning valid mtimes. So, the opcode cache must be able to work with these stream wrappers. Regards François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] removing http line folding support?
Hi! Our header() function supports multiline HTTP headers, which are allowed by RFC 2616. However, newer RFC - https://tools.ietf.org/html/rfc7230#section-3.2.4 - deprecates them and says: Historically, HTTP header field values could be extended over multiple lines by preceding each extra line with at least one space or horizontal tab (obs-fold). This specification deprecates such line folding except within the message/http media type (Section 8.3.1). A sender MUST NOT generate a message that includes line folding (i.e., that has any field-value that contains a match to the obs-fold rule) unless the message is intended for packaging within the message/http media type. So, my question is - any objections for dropping this functionality? I'd be inclined to drop it in all versions from 5.4 up since it may still be confusing some not too smart clients that don't implement full spec, and frankly to me it doesn't seem of any use anyhow, but if you disagree, please explain. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE] Removal of dead or not yet PHP7 ported SAPIs and extensions
On Wed, Feb 4, 2015 at 2:09 PM, Stanislav Malyshev smalys...@gmail.com wrote: Hi! Libmcrypt is a dead cow but not much of a threat for now. On the other hand cclient is dangerous, it should have been removed long time ago already. I'm not sure - what is the dangerous part? Are you referring to some published CVEs or other reports? Then it would be useful to list them here and on the RFC. I have to dig back (or may be in the last threads where we discussed that). I will try to to post them here (RFC is in voting phase so no edition) asap. However, I totally fail to understand your reasoning. We know both libraries are dead. ext/Imap is almost not used anymore by any major tool relying on imap, Which appealing reasons do you have to force us to have to maintain them for the next decade? 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] [RFC][VOTE] Removal of dead or not yet PHP7 ported SAPIs and extensions
On Feb 4, 2015 1:51 PM, Stanislav Malyshev smalys...@gmail.com wrote: Hi! And at list this one living native PHP implementation https://github.com/horde/horde/tree/master/framework/Imap_Client/ (and more library links in the older thread link above). This is part of Horde with 9 listed dependencies and 9 suggested ones, and probably also sub-dependencies. It is much less convenient than having imap right here when you run PHP. And looks like on top of that it lists PHP 7 as not supported. I'm sure there are other imap implementations, but I wouldn't be that quick in throwing out one that a lot of people may use. Roundcube imap cleint has many users, other mail libraries are getting a lot of traction. It is not like our users do not move away already. For two reasons, compatibly first (many bugs in imap using c-client) and also because c-client is less and less available by default on many systems.
Re: [PHP-DEV] What do we need strict scalar type hints for?
The idea of that RFC was an ability to have zero-cost assert().
DbC is a much more bigger feature, it is interesting, but requires
significant work.
Thanks. Dmitry.
On Wed, Feb 4, 2015 at 10:11 AM, François Laupretre franc...@tekwire.net
wrote:
De : Dmitry Stogov [mailto:dmi...@zend.com]
Hi Yasuo,
You probably talk about https://wiki.php.net/rfc/expectations
I wasn't the author of idea, I just helped with thoughts and
implantation.
I think it may be useful for PHP7.
In accordance with Yasuo's suggestions, couldn't we consider assertions as
part of a future implementation of the wider 'design by contract' concept ?
DbC could handle :
- function inputs : 'smart' built-in arguments types (keeping loose
typing), constraints on possible values
- function output : accepted return types/values
- assertions anywhere in the code
Function input/output validation would be done using built-in 'smart'
types ('string', 'numeric', 'integer', etc), and, optionally, 'validator'
functions. These could validate any aspect about argument/return type and
value. The key point with DbC (as well as assertions) is that, as there's
no constraint on performance, validation can be very precise and can run in
userland code.
For function input/output validation, I would extend the phpdoc syntax
(keeping compatibility with existing comments).
Another suggestion for assertions : if we hide it in comments (something
unusual like '//@@assert(...)'), we probably don't need to define an opcode
and it can be implemented as a standard function.
The question of whether DbC should replace or just supplement arg/return
typing remains open :).
What I suggest, if you agree, is that, even if we don't implement the
whole DbC concept now, we could already consider assertions as being part
of it, and rename zend.assertions to zend.dbc, assert.exceptions to
dbc.exceptions, and AssertException to DbcException.
Regards
François
Re: [PHP-DEV] [RFC][VOTE] Removal of dead or not yet PHP7 ported SAPIs and extensions
On Feb 4, 2015 1:30 PM, Stanislav Malyshev smalys...@gmail.com wrote: Hi! I am kind of surprised that RFC about removing whole extensions has Backward Incompatible Changes listed as None. Really? No BC impact whatsoever by removing imap and mcrypt? Literally nobody ever anywhere is using it? - ext/imap and ext/mcrypt: while I realise that the underlying libraries are dead, these extensions are too widely used to straight up remove them, I fear — we don't have obvious alternatives with simple enough APIs that we can push users towards. I'd strongly support and encourage a reimplementation of these extensions (in C or PHP) around something supported if someone was able to step up and do the work, otherwise yes, I'll pitch in to do the minimal work to port these to 7.0 if required. IIRC imap is working with PHP 7 and passes the tests on CI currently. mcrypt seems to be enabled on CI too. So what is needed for them for 7.0? Both extensions are relatively thin wrappers around the respective libraries. C-client for IMAP and libmcrypt for mcrypt. Libmcrypt is a dead cow but not much of a threat for now. On the other hand cclient is dangerous, it should have been removed long time ago already. Cheers, Pierre
RE: [PHP-DEV] What do we need strict scalar type hints for?
De : Dmitry Stogov [mailto:dmi...@zend.com]
Hi Yasuo,
You probably talk about https://wiki.php.net/rfc/expectations
I wasn't the author of idea, I just helped with thoughts and implantation.
I think it may be useful for PHP7.
In accordance with Yasuo's suggestions, couldn't we consider assertions as part
of a future implementation of the wider 'design by contract' concept ?
DbC could handle :
- function inputs : 'smart' built-in arguments types (keeping loose typing),
constraints on possible values
- function output : accepted return types/values
- assertions anywhere in the code
Function input/output validation would be done using built-in 'smart' types
('string', 'numeric', 'integer', etc), and, optionally, 'validator' functions.
These could validate any aspect about argument/return type and value. The key
point with DbC (as well as assertions) is that, as there's no constraint on
performance, validation can be very precise and can run in userland code.
For function input/output validation, I would extend the phpdoc syntax (keeping
compatibility with existing comments).
Another suggestion for assertions : if we hide it in comments (something
unusual like '//@@assert(...)'), we probably don't need to define an opcode and
it can be implemented as a standard function.
The question of whether DbC should replace or just supplement arg/return typing
remains open :).
What I suggest, if you agree, is that, even if we don't implement the whole DbC
concept now, we could already consider assertions as being part of it, and
rename zend.assertions to zend.dbc, assert.exceptions to dbc.exceptions, and
AssertException to DbcException.
Regards
François
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE] Removal of dead or not yet PHP7 ported SAPIs and extensions
Hi! And at list this one living native PHP implementation https://github.com/horde/horde/tree/master/framework/Imap_Client/ (and more library links in the older thread link above). This is part of Horde with 9 listed dependencies and 9 suggested ones, and probably also sub-dependencies. It is much less convenient than having imap right here when you run PHP. And looks like on top of that it lists PHP 7 as not supported. I'm sure there are other imap implementations, but I wouldn't be that quick in throwing out one that a lot of people may use. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zero-fill right shift.
On 3 February 2015 at 14:36, Andrea Faulds a...@ajf.me wrote: I don’t know where you got that idea. The binary ops are consistent - they aren’t constrained by register size like in previous PHP versions, but they’re still completely consistent. php -r 'var_dump(1 65);' int(2) Rotate left gets broken. It’s slower, yes, but that hardly matters. If people care so much about performance, why use PHP? If people didn't care about performance, we wouldn't have phpng, or any of the other work people have done to make the engine faster. Sometimes you have to make the most of what you have available. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zero-fill right shift.
Hi, On 3 Feb 2015, at 14:43, Leigh lei...@gmail.com wrote: On 3 February 2015 at 14:36, Andrea Faulds a...@ajf.me wrote: I don’t know where you got that idea. The binary ops are consistent - they aren’t constrained by register size like in previous PHP versions, but they’re still completely consistent. php -r 'var_dump(1 65);' int(2) Rotate left gets broken. It’s not “broken”, the behaviour is just different to account for it now being an arbitrary-precision type. If you want to “rotate left”, bitmasking does exist. It’s slower, yes, but that hardly matters. If people care so much about performance, why use PHP? If people didn't care about performance, we wouldn't have phpng, or any of the other work people have done to make the engine faster. Sometimes you have to make the most of what you have available. OK, performance is not unimportant. But in most cases, arbitrary-precision integers are not going to be a bottleneck for your web app. Also, the bigint changes only affect you if you’re dealing with large integers anyway. If you want to preserve the horrid float promotion behaviour, you can do so explicitly. But I think in most cases, it’s better to trade off performance for lack of data loss. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zero-fill right shift.
On 3 February 2015 at 15:02, Andrea Faulds a...@ajf.me wrote: Why would it be promoted?! The high bit is the 63rd bit. It fits within a long. I'm assuming your bigint implementation would want to respect signage. When does it promote? 63rd to preserve signage? 4611686018427387904 // 1 62 - int 9223372036854775808 // 1 63 - bigint 18446744073709551616 // 1 64 - bigint Or 64th to for complete madness? 4611686018427387904 // 1 62 - int -9223372036854775808 // 1 63 - int 18446744073709551616 // 1 64 - bigint -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zero-fill right shift.
On 3 February 2015 at 14:49, Andrea Faulds a...@ajf.me wrote: It’s not “broken”, the behaviour is just different to account for it now being an arbitrary-precision type. That's pretty much the definition of a BC issue. Also, the bigint changes only affect you if you’re dealing with large integers anyway. If you want to preserve the horrid float promotion behaviour, you can do so explicitly. But I think in most cases, it’s better to trade off performance for lack of data loss. It's not anything to do with float promotion or data loss. If I'm working with a 64-bit bitmask that gets promoted to bigint when I set the high bit, it's a performance regression from then on. Not everything written in PHP is a web app. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zero-fill right shift.
On 3 Feb 2015, at 14:59, Leigh lei...@gmail.com wrote: On 3 February 2015 at 14:49, Andrea Faulds a...@ajf.me wrote: It’s not “broken”, the behaviour is just different to account for it now being an arbitrary-precision type. That's pretty much the definition of a BC issue. Sure, it’s a BC break if you’re relying on the undefined behaviour of your platform. Which a lot of people unfortunately were doing. Actually, this specific case was already broken in PHP 7 after the Integer Semantics RFC passed, which made our bitwise shifts more consistent across platforms. Also, the bigint changes only affect you if you’re dealing with large integers anyway. If you want to preserve the horrid float promotion behaviour, you can do so explicitly. But I think in most cases, it’s better to trade off performance for lack of data loss. It's not anything to do with float promotion or data loss. If I'm working with a 64-bit bitmask that gets promoted to bigint when I set the high bit Why would it be promoted?! The high bit is the 63rd bit. It fits within a long. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] $http_response_header
On 2/3/15 3:33 AM, Julien Pauli wrote:
On Mon, Feb 2, 2015 at 6:19 PM, Ferenc Kovacs tyr...@gmail.com wrote:
About $php_errormsg , we have error_get_last().
About $http_response_headers, we have no replacement.
Well, we sort of do. You can get header information from the http
context stream metadata:
$fh = fopen($urlPath, 'r', false, $context);
$metadata = stream_get_meta_data($fh);
$content = stream_get_contents($fh);
fclose($fh);
$metadata['wrapper_data'] will include the headers. From an ease-of-use
standpoint, $http_reponse_header gives you immediate access to headers
when the previous operation was a stream based HTTP request (via fopen,
or even file_get_contents()).
Why not get rid of both ?
I mean, those variables magically appearing into your code are born from C,
where libc usually give access to errno and errstr variables (which are
often implemented as macros).
We could, but it would be nice to add some kind of easy to use
replacement for the last stream operation, which essentially is the
best/most common use case for $http_response_header after the fact that
it is magically conjured into local scope.
For example, right now, to get headers from a http stream request, its
as ease as:
$content = file_get_contents('http://php.net/');
var_dump($http_response_header);
I think a nice replacement for that would be supporting (at least):
$content = file_get_contents('http://php.net/');
$header = stream_get_meta_data()['wrapper_data'];
By passing null to stream_get_meta_data(), it would use metadata from
the last request made with streams (in the same way
$http_response_header is allocated).
Thats just a thought for that. I no other suggestion for the error
stuff as I'd forgotten that even existed.
-ralph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zero-fill right shift.
On 3 Feb 2015, at 14:15, Leigh lei...@gmail.com wrote: On 3 February 2015 at 13:54, Andrea Faulds a...@ajf.me wrote: Hi Leigh, On 3 Feb 2015, at 13:51, Leigh lei...@gmail.com wrote: No idea. Personally I'm opposed to the bigints implementation because of the implicit type auto-promotion. Huh? There’s no type promotion from a userland perspective, it’s entirely an implementation detail. Yes, some integers may be IS_LONG and others may be IS_BIGINT internally, but that’s only for Zend Engine 3 (might change in future), the boundary point varies by platform, and crucially, you can’t distinguish them from userland. Aside from the breaks to some binary ops I don’t know where you got that idea. The binary ops are consistent - they aren’t constrained by register size like in previous PHP versions, but they’re still completely consistent. and once you hit the promotion breakpoint working with that integer is a lot slower. It’s slower, yes, but that hardly matters. If people care so much about performance, why use PHP? -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] $http_response_header
On 03 02 2015, at 10:33, Julien Pauli jpa...@php.net wrote: $HTTP_RAW_POST_DATA could as well disappear (made deprecated as of 5.6). This is already gone in master, which reminds me of the missing UPGRADING note. Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Big Integer Support
On 03/02/15 14:03, Andrea Faulds wrote: But I don’t consider 0.25MB extra to be such a problem in practice. The PHP binary is already huge, and every system running PHP will have ample memory. Yes one approach is 'computers are getting faster with lots of memory' ... and for servers this is not a problem ...they will more than likely be 64bit anyway! But for smaller embedded devices php *IS* becoming an option so I don't have to program in C or something else, and then we look to strip everything that does not need to be present. Only support one database interface. Ideally have simple unicode direct in the core and magically the 'already huge' binary becomes an option so code developed on the servers can be run locally, and only the data needs to be sourced over the network connection. The trade off is battery life over optimised code ... it even helps where a network connection may be down more than up and it does not need all of the current overheads to work. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE] Removal of dead or not yet PHP7 ported SAPIs and extensions
On 03/02/2015 09:39, Anatol Belski wrote: Marius Adrian Popa has stated to maintain both, and looks like there several active users who will use that. So going by that, it's not being voted on these exts. I must have missed that, sorry for the noise. Cheers -- Matteo Beccati Development Consulting - http://www.beccati.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Big Integer Support
On 02/02/15 23:50, Andrea Faulds wrote: Since a clean 64bit build of PHP does not need anything other than 'integer' to support 64bit BIGINT SQL numbers, loading 32bit builds with an overly heavy solution is just not right! I don’t see how it’s “overly heavy”. Bear in mind that several extensions (not just ext/gmp) already require GMP anyway. libgmp.so is 538.6kb gmp.so add a further 242.1kb You will have to elaborate on what else is reliant on it for a normal PHP build. I've only JUST installed any of it on the development machine to get those sizes and gmp extension is not yet enabled. THAT just seems rather heavy to just support a pair of 32bit integers that the database extension has already loaded and is handling as a single object ... on a 32bit platform. 'longint' only needs an extension to provide it, which can then be replaced by properly crafted code for devices that already have 256bit and better maths capability anyway. GMP provides high-performance, optimised SIMD assembly implementations for most platforms. Yes GMP does have some ARM support, but it may not be the most economic solution. ARM does have it's own more compact libraries for the same functionality and replacing the 780kb gmp option by something smaller should be an option, rather than making the rest of the core dependent on it. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE] Removal of dead or not yet PHP7 ported SAPIs and extensions
Hi Adam, thanks for the explanations. On Tue, February 3, 2015 08:10, Adam Harvey wrote: On 3 February 2015 at 03:11, Anatol Belski anatol@belski.net wrote: properly after the voting phase the https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts moves to the voting. Each item is voted separately. The voting ends on 2015-02-09 at 21:00 CET. To explain my -1s: - ext/imap and ext/mcrypt: while I realise that the underlying libraries are dead, these extensions are too widely used to straight up remove them, I fear — we don't have obvious alternatives with simple enough APIs that we can push users towards. I'd strongly support and encourage a reimplementation of these extensions (in C or PHP) around something supported if someone was able to step up and do the work, otherwise yes, I'll pitch in to do the minimal work to port these to 7.0 if required. For ext/imap I can point to this old thread: http://grokbase.com/t/php/php-internals/141zh29xs2/ext-imap-bye-bye-in-php-5-6 And at list this one living native PHP implementation https://github.com/horde/horde/tree/master/framework/Imap_Client/ (and more library links in the older thread link above). With ext/mcrypt there are also libs, I can point at least to this one https://github.com/phpseclib/phpseclib which was available even before PHP5.3 i think. Interestingly it can rely on ext/mcrypt if available, otherwise it uses native PHP implementations. Though note that those both are already ported, they landed in the RFC exactly because of the dead dependency libraries. I can just enclose myself to the reimlementation/surrogate layer idea. Actually that would make sense also for the ext/regex which was voted to be removed in another RFC. Otherwise, i'd rather advise users to use the native PHP implementations. - ext/pdo_dblib: ODBC is almost always the better way of interfacing with SQL Server, but I don't think keeping this one around is doing anyone much harm (as opposed to ext/mssql, which we should kill with fire for the same reasons as ext/mysql). There's also the sqlsrv extension http://www.microsoft.com/en-us/download/details.aspx?id=20098 . I had no chance to check ext/pdo_dblib but it's stated as not ported yet on the PHPNG wiki page. Abstentions: - sapi/apache2filter: I wonder if someone would step up for that one if we advertised more widely, given I believe that it is in actual use. Unlike most of the other SAPIs, which are obviously dead, I'd like to give this one a bit more time before the 7.0 feature freeze. No movement on this so far in the PHP7 direction. Nobody is porting it, nobody is asking for that. - sapi/milter: I'm at least passingly familiar with almost all of the Web servers in the list, but I know nothing about the environments this SAPI is used in. Can someone who is familiar with it describe the pros and cons to dropping it? It's a very exotic thing. As mentioned in the RFC, with this you can hook into the MTA process. But the PHP script is invoked fromwithin the MTA. - ext/sybase_ct: does PDO (via dblib and/or ODBC) cover this functionality adequately? I feel that I know enough to vote on SQL Server related topics, but haven't looked at actual Sybase for years. Basically the same as apache2filter - no movement on this towards PHP7. Nobody is porting it, nobody is asking for that. If there are no constant maintainers for this, IMHO porting it once which is doable, won't bring anything good but tons of subtle bugs. Porting it once without real maintanance and usage, just because we want to have sybase in, i mean. I'm really curious about the stats after this RFC, which extensions/sapis turned out to have found a new home and maintanance somewhere like PECL :) Regards Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE] Removal of dead or not yet PHP7 ported SAPIs and extensions
On 02/02/2015 20:21, Lester Caine wrote: On 02/02/15 19:11, Anatol Belski wrote: properly after the voting phase the https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts moves to the voting. Each item is voted separately. The voting ends on 2015-02-09 at 21:00 CET. I feel this is totally out of line since only people who use modules will have the need to retain them, but like me many of those people have no right to vote! I have not yet found any problem running interbase with 'master' and I am sure the warnings being raised simply require the assistance of someone who understands why a change has been made, rather than it being essential that we have to learn that knowledge JUST to keep an existing extension working. What about moving pdo_firebird to pecl too? Last time I checked it was fairly broken (compared to ext/interbase). Cheers -- Matteo Beccati Development Consulting - http://www.beccati.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE] Removal of dead or not yet PHP7 ported SAPIs and extensions
Hi Matteo, On Tue, February 3, 2015 09:09, Matteo Beccati wrote: On 02/02/2015 20:21, Lester Caine wrote: On 02/02/15 19:11, Anatol Belski wrote: properly after the voting phase the https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts moves to the voting. Each item is voted separately. The voting ends on 2015-02-09 at 21:00 CET. I feel this is totally out of line since only people who use modules will have the need to retain them, but like me many of those people have no right to vote! I have not yet found any problem running interbase with 'master' and I am sure the warnings being raised simply require the assistance of someone who understands why a change has been made, rather than it being essential that we have to learn that knowledge JUST to keep an existing extension working. What about moving pdo_firebird to pecl too? Last time I checked it was fairly broken (compared to ext/interbase). Marius Adrian Popa has stated to maintain both, and looks like there several active users who will use that. So going by that, it's not being voted on these exts. Regards Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE] Removal of dead or not yet PHP7 ported SAPIs and extensions
On Feb 3, 2015 2:10 PM, Adam Harvey ahar...@php.net wrote: On 3 February 2015 at 03:11, Anatol Belski anatol@belski.net wrote: properly after the voting phase the https://wiki.php.net/rfc/removal_of_dead_sapis_and_exts moves to the voting. Each item is voted separately. The voting ends on 2015-02-09 at 21:00 CET. To explain my -1s: - ext/imap and ext/mcrypt: while I realise that the underlying libraries are dead, these extensions are too widely used to straight up remove them, I fear — we don't have obvious alternatives with simple enough APIs that we can push users towards. I'd strongly support and encourage a reimplementation of these extensions (in C or PHP) around something supported if someone was able to step up and do the work, otherwise yes, I'll pitch in to do the minimal work to port these to 7.0 if required. We have plenty of alternative implemented in php, supporting way more things that ext/IMAP ever did. However I have a hard time to understand your argument. We keep discussing how to improve security, make php safer by default, etc. But for IMAP, you basically open the door with a big shield saying come in, we have free cooking and you can do almost all you want inside via this door. This is insane. If it was only up to me I would kick it out of core right now due to the critical issue it has. Mcrypt is only a time bomb. It will be the same pretty soon.
Re: [PHP-DEV] [RFC][VOTE] Removal of dead or not yet PHP7 ported SAPIs and extensions
Hi Michael, On Tue, February 3, 2015 08:31, Michael Wallner wrote: On 3 Feb 2015 08:10, Adam Harvey ahar...@php.net wrote: I understand your thoughts. How about if we do for mcrypt what we did for mhash, I.e. implement a compatible layer on top of openssl? I have not checked if it's even possible yet, just an idea that popped into mind. I would be willing to do this to learn more about the openssl innards, so I'd probably need someone else to verify my work. if you venture to do this, please ping. I can support you at least with testing and maybe more. Regards Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What do we need strict scalar type hints for?
Hi Sven, On 3 Feb 2015, at 19:07, Sven Drieling s...@sven-drieling.de wrote: What about scalar type declaration in userland? It’s one of many suggestions. I really, really don’t think it’s a good idea. Rather than having two models (as the RFC suggests), we’d have n models, where n is the number of existent PHP frameworks and libraries. Every single application would have its own approach. It’d be chaotic, and not terribly user-friendly. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Big Integer Support
On 3 Feb 2015, at 14:49, Lester Caine les...@lsces.co.uk wrote: On 03/02/15 14:03, Andrea Faulds wrote: But I don’t consider 0.25MB extra to be such a problem in practice. The PHP binary is already huge, and every system running PHP will have ample memory. Yes one approach is 'computers are getting faster with lots of memory' ... and for servers this is not a problem ...they will more than likely be 64bit anyway! But for smaller embedded devices php *IS* becoming an option so I don't have to program in C or something else, and then we look to strip everything that does not need to be present. Sure, but I don’t think we shouldn’t cripple the language merely for the sake of really low-end embedded devices. Also, I’m not convinced that the overhead, at least in terms of file size, is really that big of an issue. Just for you, I’ve gone and compiled the bigint branch (with LibTomMath) and master on my machine: $ ls -l php7-* -rwxr-xr-x 1 ajf staff 6400408 3 Feb 16:39 php7-bigint -rwxr-xr-x 1 ajf staff 6248920 3 Feb 16:42 php7-master The difference is a mere 151488 B, or 151 KB. Is that really so bad? -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zero-fill right shift.
On 3 Feb 2015, at 15:12, Leigh lei...@gmail.com wrote: On 3 February 2015 at 15:02, Andrea Faulds a...@ajf.me wrote: Why would it be promoted?! The high bit is the 63rd bit. It fits within a long. I'm assuming your bigint implementation would want to respect signage. When does it promote? 63rd to preserve signage? 4611686018427387904 // 1 62 - int 9223372036854775808 // 1 63 - bigint 18446744073709551616 // 1 64 - bigint Or 64th to for complete madness? 4611686018427387904 // 1 62 - int -9223372036854775808 // 1 63 - int 18446744073709551616 // 1 64 - bigint The specific code can be found here: https://github.com/TazeTSchnitzel/php-src/blob/b91a80879ca3ba269bd239d9c820003c83d0dbc1/Zend/zend_operators.c#L2265 The algorithm is fairly simple: if the number of bits in the long plus the number of bits to shift is greater than the number of bits in a zend_long, then it promotes. Thus: $ sapi/cli/php -r '$x = 1 62; debug_zval_dump($x);' long(4611686018427387904) $ sapi/cli/php -r '$x = 1 63; debug_zval_dump($x);' bigint(9223372036854775808) refcount(2) $ sapi/cli/php -r '$x = 1 64; debug_zval_dump($x);' bigint(18446744073709551616) refcount(2) I tried some negative numbers, but I’ve noticed that any left shift on a negative integer promotes - that’s probably because clz is including the high bit... that should probably be fixed, mostly likely by doing clz on its absolute value in that case and factoring in the high bit. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PS(invalid_session_id) ?
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
Re: [PHP-DEV] Zero-fill right shift.
On 3 February 2015 at 15:02, Andrea Faulds a...@ajf.me wrote: Why would it be promoted?! The high bit is the 63rd bit. It fits within a long. because On 3 February 2015 at 16:08, Andrea Faulds a...@ajf.me wrote: $ sapi/cli/php -r '$x = 1 63; debug_zval_dump($x);' bigint(9223372036854775808) refcount(2) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zero-fill right shift.
On 3 Feb 2015, at 16:22, Leigh lei...@gmail.com wrote: On 3 February 2015 at 15:02, Andrea Faulds a...@ajf.me wrote: Why would it be promoted?! The high bit is the 63rd bit. It fits within a long. because On 3 February 2015 at 16:08, Andrea Faulds a...@ajf.me wrote: $ sapi/cli/php -r '$x = 1 63; debug_zval_dump($x);' bigint(9223372036854775808) refcount(2) Yeah, I see your point now, although I’d question *why* you need to mess with the high bit. You can still do ^ -1 or something as usual, though. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What do we need strict scalar type hints for?
Hi Dmitry, On 3 Feb 2015, at 04:07, Dmitry Stogov dmi...@zend.com wrote: I have similar opinion. Strict typing looks foreign for PHP. It is in a way, yes. PHP has traditionally been “weakly-typed” everywhere. That being said, we’re not always weakly-typed (there are strict type checks in some places), and userland code has sometimes done strict type checks anyway. I see, strict type hints may be useful. Aspecially for testing and error detection, but anyaway, I'm not sure if and how it should be enabled. Declare() is a working solution, but it's not excelent. It’s not a perfect solution, but I haven’t seen anything that seems to be much better. The best bit about declare() is that it would make strict types completely optional, so people who don’t like them wouldn’t have to use them, even if they call code which does. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Add is_cacheable() stream-wrapper operation
On 02/02/2015 07:35 PM, David Muir wrote: On 3 Feb 2015, at 3:49 am, Rasmus Lerdorf ras...@lerdorf.com wrote: 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? There are some issues with that which we will have to address at some point. For example, when running fpm chrooted you need more than the path. We'll likely need a more APC-like option here to use the device+inode for the key. It seems like a generic mechanism like you are proposing needs to take this into account and provide some mechanism that tells the opcode cache how to determine uniqueness. Perhaps that is simply encoded into the path parameter, but then maybe it should have a more appropriate name. -Rasmus Don't we already have this problem with chrooted FPM? I haven't tested it more recently, but last time I tried, opcache would fail to invalidate the cache after updating the file. Worked fine with a non-chroot environment. Not sure if this is related to the issues you mean here... Yes, like I said, this is an issue we have to address still. It is on the TODO list and definitely looking for volunteers. I just wanted to make sure that Francois' RFC didn't introduce something which would make it harder to eventually fix this by not allowing for a non-path cache key. -Rasmus signature.asc Description: OpenPGP digital signature
[PHP-DEV] Zero-fill right shift.
Hi list, How do we feel about a zero-fill right shift operator? PHPs current right shift operator preserves signage, but this is not always desirable. I propose the same syntax as JavaScript for this: php -r 'var_dump(-256 8);' int(-1) php -r 'var_dump(-256 8);' int(16777215) This will introduce a T_SHRZF token and corresponding opcode. Targeting PHP 7. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Zero-fill right shift.
is called a logical right shift (in contrast to the arithmetic right shift ). This would be a good addition. $op1 $op2 is equivalent to ($op1 $op2) (PHP_INT_MAX $op2 - 1) == Original == From: Leigh lei...@gmail.com To: internals@lists.php.net Date: Tue, 03 Feb 2015 14:24:07 +0100 Subject: [PHP-DEV] Re: Zero-fill right shift. This will introduce a T_SHRZF token and corresponding opcode. Targeting PHP 7. That should have been T_SRZF, and I suppose I would also have to add = (T_SRZF_EQUAL) which looks nasty, but should be included for completeness. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE] Removal of dead or not yet PHP7 ported SAPIs and extensions
Pierre Joye wrote on 03/02/2015 09:14: On Feb 3, 2015 4:06 PM, Lester Caine les...@lsces.co.uk wrote: On 03/02/15 08:44, Matteo Beccati wrote: Marius Adrian Popa has stated to maintain both, and looks like there several active users who will use that. So going by that, it's not being voted on these exts. I must have missed that, sorry for the noise. This is a bit of the problem here. There is a substantial Firebird user base who like wordpress and joomla users have no knowledge of what is going on in the background to keep their platform working. Often we don't find out about things - 'they get missed' - but similarly just treading water takes too much time today so following development on everything we do use often takes second place? I wonder if ANY mssql users have noticed that they may be left out of PHP7 ... I suspect that may actually have a bigger user base than the paid for 'Interbase' yet it's got no support here. For mssql, most of them (while we see more and more requests from linux lately) are on windows. And mssql support has been removed with the release of 5.3.0. Since 2 years they use sqlsrv from pecl. For what it's worth, we've been running a Linux + MS SQL setup for around 10 years, due to a previous migration from Classic ASP to PHP. We originally used ext/mssql, and moved to ext/pdo_dblib with PHP 5.4 (previous versions didn't support nextRowset(), which made it unusable). Both run smoothly on current Ubuntu builds with FreeTDS installed. While we've almost succeeded in deprecating the legacy DBs in favour of Postgres, it could easily happen that someone is just starting down the same route now, and would want to know what driver will work best with PHP 7. As others have hinted, maybe there could be a table somewhere of the recommended drivers (and db-specific exts, where applicable) to use for different OS/DB combinations? This could answer both if I'm a PHP user, which configuration should I be choosing for reasonable future-proofing? and if I'm an extension developer, where should I be contributing features?. Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zero-fill right shift.
On 3 February 2015 at 13:25, Andrea Faulds a...@ajf.me wrote: Hmm, how would this interact with bigints? Does it rely on fixed-width integers, as it appears to? :/ No idea. Personally I'm opposed to the bigints implementation because of the implicit type auto-promotion. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zero-fill right shift.
Hi Leigh, On 3 Feb 2015, at 13:51, Leigh lei...@gmail.com wrote: On 3 February 2015 at 13:25, Andrea Faulds a...@ajf.me wrote: Hmm, how would this interact with bigints? Does it rely on fixed-width integers, as it appears to? :/ No idea. Personally I'm opposed to the bigints implementation because of the implicit type auto-promotion. Huh? There’s no type promotion from a userland perspective, it’s entirely an implementation detail. Yes, some integers may be IS_LONG and others may be IS_BIGINT internally, but that’s only for Zend Engine 3 (might change in future), the boundary point varies by platform, and crucially, you can’t distinguish them from userland. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Big Integer Support
Hi Lester, On 3 Feb 2015, at 08:56, Lester Caine les...@lsces.co.uk wrote: On 02/02/15 23:50, Andrea Faulds wrote: Since a clean 64bit build of PHP does not need anything other than 'integer' to support 64bit BIGINT SQL numbers, loading 32bit builds with an overly heavy solution is just not right! I don’t see how it’s “overly heavy”. Bear in mind that several extensions (not just ext/gmp) already require GMP anyway. libgmp.so is 538.6kb gmp.so add a further 242.1kb You will have to elaborate on what else is reliant on it for a normal PHP build. cURL and other things that use GnuTLS: https://bugs.php.net/bug.php?id=63595 Also, the bigint branch doesn’t require ext/gmp to be enabled. I've only JUST installed any of it on the development machine to get those sizes and gmp extension is not yet enabled. Well, you don’t actually need GMP anyway. The patch also bundles a lightweight, pure C89 bigint library called LibTomMath which will be built if you don’t ask to use GMP explicitly. It’s nowhere near as fast as GMP, but it’s liberally-licensed, lightweight, etc. THAT just seems rather heavy to just support a pair of 32bit integers that the database extension has already loaded and is handling as a single object ... on a 32bit platform. Even just a “pair of 32-bit integers” requires a significant effort. You need to bundle some sort of library to deal with it. 'longint' only needs an extension to provide it, which can then be replaced by properly crafted code for devices that already have 256bit and better maths capability anyway. GMP provides high-performance, optimised SIMD assembly implementations for most platforms. Yes GMP does have some ARM support, but it may not be the most economic solution. ARM does have it's own more compact libraries for the same functionality and replacing the 780kb gmp option by something smaller should be an option, rather than making the rest of the core dependent on it. If you wish to go to the hassle of adding a bigint backend specifically optimised for ARM, you’re free to. But I don’t consider 0.25MB extra to be such a problem in practice. The PHP binary is already huge, and every system running PHP will have ample memory. Thanks. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC][VOTE] Removal of dead or not yet PHP7 ported SAPIs and extensions
On 03/02/15 12:37, Rowan Collins wrote: For what it's worth, we've been running a Linux + MS SQL setup for around 10 years, due to a previous migration from Classic ASP to PHP. We originally used ext/mssql, and moved to ext/pdo_dblib with PHP 5.4 (previous versions didn't support nextRowset(), which made it unusable). Both run smoothly on current Ubuntu builds with FreeTDS installed. While we've almost succeeded in deprecating the legacy DBs in favour of Postgres, it could easily happen that someone is just starting down the same route now, and would want to know what driver will work best with PHP 7. I've still got some ASP sites, and have been using mssql in much the same way but those sites will remain with PHP5.2 and the replacements will be on the modern framework. As others have hinted, maybe there could be a table somewhere of the recommended drivers (and db-specific exts, where applicable) to use for different OS/DB combinations? This could answer both if I'm a PHP user, which configuration should I be choosing for reasonable future-proofing? and if I'm an extension developer, where should I be contributing features?. I think third part libraries like ADOdb probably need a similar treatment. My use of mssql is via that and other legacy drivers are similarly wrapped, but tagging alternative paths there can only help, and is something I can document. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zero-fill right shift.
Hi Leigh, On 3 Feb 2015, at 13:20, Leigh lei...@gmail.com wrote: Hi list, How do we feel about a zero-fill right shift operator? PHPs current right shift operator preserves signage, but this is not always desirable. I propose the same syntax as JavaScript for this: php -r 'var_dump(-256 8);' int(-1) php -r 'var_dump(-256 8);' int(16777215) This will introduce a T_SHRZF token and corresponding opcode. Targeting PHP 7. Hmm, how would this interact with bigints? Does it rely on fixed-width integers, as it appears to? :/ I think it’s a very obscure use case, too. Might be better to add a function in this case, like we did for intdiv(). Thoughts? -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Zero-fill right shift.
This will introduce a T_SHRZF token and corresponding opcode. Targeting PHP 7. That should have been T_SRZF, and I suppose I would also have to add = (T_SRZF_EQUAL) which looks nasty, but should be included for completeness. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Zero-fill right shift.
On 3 February 2015 at 13:54, Andrea Faulds a...@ajf.me wrote: Hi Leigh, On 3 Feb 2015, at 13:51, Leigh lei...@gmail.com wrote: No idea. Personally I'm opposed to the bigints implementation because of the implicit type auto-promotion. Huh? There’s no type promotion from a userland perspective, it’s entirely an implementation detail. Yes, some integers may be IS_LONG and others may be IS_BIGINT internally, but that’s only for Zend Engine 3 (might change in future), the boundary point varies by platform, and crucially, you can’t distinguish them from userland. Aside from the breaks to some binary ops and once you hit the promotion breakpoint working with that integer is a lot slower. Lets not derail this thread into a discussion about why I dislike bigints. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Big Integer Support
Hi Lester, On Tue, February 3, 2015 15:49, Lester Caine wrote: On 03/02/15 14:03, Andrea Faulds wrote: But I don’t consider 0.25MB extra to be such a problem in practice. The PHP binary is already huge, and every system running PHP will have ample memory. Yes one approach is 'computers are getting faster with lots of memory' ... and for servers this is not a problem ...they will more than likely be 64bit anyway! But for smaller embedded devices php *IS* becoming I would like to ask, what those embedded devices are. Also I would like to state that it's hard to part the concerns you express. Arbitrary integer math is the daily bread of any modern programming language. Furthermore, from the test done so far there's no much visible impact to the present operation. Regards Anatol -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: PS(invalid_session_id) ?
Hi Rasmus,
On Wed, Feb 4, 2015 at 1:20 AM, Rasmus Lerdorf ras...@lerdorf.com wrote:
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?
At first, PS(invalid_session_id) was never worked as it supposed. It wasn't
used to
generate new session ID when session ID is invalid...
To notify invalid session ID to session module, please use
PS_FUNC_VALIDATE_SID().
If it returns FAILURE, session module creates new session ID by using
PS_FUNC_CREATE_SID().
If PS_FUNC_CREATE_SID() is not implemented, session module uses the default
php_session_create_id().
For save handlers, there are old save handler definitions PS_FUNCS,
PS_FUNCS_SID. New
save handlers are supposed to use PS_FUNCS_UPDATE_TIMESTAMP. It requires to
implement
PS_CREATE_SID, if save handler does not need custom session ID, the default
php_session_create_id()
may simply be called. However, session ID collision is better to be checked
like files handler. With
collision check in PS_CREATE_SID_FUNC(), collision never happens.
/*
* Create session ID.
* PARAMETERS: PS_CREATE_SID_ARGS in php_session.h
* RETURN VALUE: Valid session ID(zend_string *) or NULL for FAILURE.
*
* PS_CREATE_SID_FUNC() must check collision. i.e. Check session data if
* new sid exists already.
* *mod_data is guaranteed to have non-NULL value.
* NOTE: Default php_session_create_id() does not check collision. If
* NULL is returned, session module create new ID by using
php_session_create_id().
* If php_session_create_id() fails due to invalid configuration, it raises
E_ERROR.
* NULL return value checks from php_session_create_id() is not required
generally.
*/
PS_CREATE_SID_FUNC(files)
{
zend_string *sid;
int maxfail = 3;
PS_FILES_DATA;
do {
sid = php_session_create_id((void**)data);
if (!sid) {
if (--maxfail 0) {
return NULL;
} else {
continue;
}
}
/* Check collision */
/* FIXME: mod_data(data) should not be NULL (User handler could be
NULL) */
if (data ps_files_key_exists(data, sid-val) == SUCCESS) {
if (sid) {
zend_string_release(sid);
sid = NULL;
}
if (--maxfail 0) {
return NULL;
}
}
} while(!sid);
return sid;
}
Summary for new save handler
- Use PS_FUNCS_UPDATE_TIMESTAMP/PS_MOD_UPDATE_TIMESTAMP
- PS_VALIDATE_SID() returns FAILURE for uninitialized session ID, anything
save handler decides as invalid session ID. Otherwise, return SUCCESS.
- PS_CREATE_SID() should check session ID collision. Return NULL for
failure.
- PS_UPDATE_TIMSTAMP_FUNC() must update session data timestamp. e.g.
touch file for files, memcache updates timestamp by read access so
return
SUCCESS simply.
I added comments to ext/session/mod_files.c for save handler developers.
Please refer to it also.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
RE: [PHP-DEV] [VOTE] Add is_cacheable() stream-wrapper operation
De : Rasmus Lerdorf [mailto:ras...@lerdorf.com] Don't we already have this problem with chrooted FPM? I haven't tested it more recently, but last time I tried, opcache would fail to invalidate the cache after updating the file. Worked fine with a non-chroot environment. Not sure if this is related to the issues you mean here... Yes, like I said, this is an issue we have to address still. It is on the TODO list and definitely looking for volunteers. I just wanted to make sure that Francois' RFC didn't introduce something which would make it harder to eventually fix this by not allowing for a non-path cache key. Well, from what I see in accel_make_persistent_key_ex(), the key is the path or a concatenation of the path, the cwd, the include path... Of course, the idea is to avoid the stat() call. But I don't see how we can determine a reliable cache key without a stat(). Maybe opcache shouldn't compute the key by itself. For each file it receives, it would ask the corresponding wrapper for a cache key (and the plain files wrapper would do a stat() and return dev/inode/mtime). François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] What do we need strict scalar type hints for?
Am Mon, 02 Feb 2015 23:38:21 +0100
schrieb Christoph Becker cmbecke...@gmx.de:
Hallo,
addVat(-1);
Well, my point was that even a strict type system doesn't necessarilly
catch all erroneous/undesired arguments. Even if addVat() properly
handles negative numbers, and maybe even zeroes, there are functions
that can't.
What about scalar type declaration in userland?
namespace mytypes;
declare scalartype amount($amount) {
if (!is_int($amount) !is_float($amount)) {
throw new InvalidArgumentException('Argument amount
must be of the type int|float, '.gettype($amount).' given');
}
}
function addVat(mytypes\amount $amount) {
return round($amount*1.19, 2);
}
addVat(42) // OK
addVat(42) // OK
addVat(-42) // OK
addVat(42.0) // OK
addVat(true) // Exception
var mytypes\amount $amount = 0;
$amount = 42; // OK
$amount = 42; // OK
$amount = true; // Exception
tschuess
[|8:)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Big Integer Support
Am 03.02.2015 17:44 schrieb Andrea Faulds a...@ajf.me: On 3 Feb 2015, at 14:49, Lester Caine les...@lsces.co.uk wrote: On 03/02/15 14:03, Andrea Faulds wrote: But I don’t consider 0.25MB extra to be such a problem in practice. The PHP binary is already huge, and every system running PHP will have ample memory. Yes one approach is 'computers are getting faster with lots of memory' ... and for servers this is not a problem ...they will more than likely be 64bit anyway! But for smaller embedded devices php *IS* becoming an option so I don't have to program in C or something else, and then we look to strip everything that does not need to be present. Sure, but I don’t think we shouldn’t cripple the language merely for the sake of really low-end embedded devices. Also, I’m not convinced that the overhead, at least in terms of file size, is really that big of an issue. Just for you, I’ve gone and compiled the bigint branch (with LibTomMath) and master on my machine: $ ls -l php7-* -rwxr-xr-x 1 ajf staff 6400408 3 Feb 16:39 php7-bigint -rwxr-xr-x 1 ajf staff 6248920 3 Feb 16:42 php7-master The difference is a mere 151488 B, or 151 KB. Is that really so bad? -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Please get this mayor feature finally into the core In the current century a real 64bit support is not discussable anymore...
Re: [PHP-DEV] [RFC] Big Integer Support
On 3 February 2015 21:49:28 GMT, Lester Caine les...@lsces.co.uk wrote: On 03/02/15 16:44, Andrea Faulds wrote: Sure, but I don’t think we shouldn’t cripple the language merely for the sake of really low-end embedded devices. Also, I’m not convinced that the overhead, at least in terms of file size, is really that big of an issue. 'I don’t think we should cripple' ? There are two views on the handling of integers. Obviously it would be nice if there was no limit to the size of a number and there are situations where that is indeed useful. However there are equally situations where both the natural 32bit and 64bit limits of the target hardware and software needs to be observed and these require a different method of handling things like 'overflow'. Simply automatically upgrading an integer value to a more complex object depending on what hardware one is running on adds the overhead of having to create code to disable things depending on some hardware flag. With the bulk of SQL persistent data having to manage both 32 and 64bit integer limits and the matching float/numeric limits, a system of working which mirrors that would naturally seem to be the sensible default. If those limitations have been avoided by the use of additional libraries, then a matching additional library in PHP also comes into play. Currently we have a problem with the size of integers, but simply ignoring that there are limits is not the may to fix that problem. I don't think a high-level language should expose the details of integer representation of the server you install it on any more than it exposes memory management. A user might need to know limitations of the implementation, but they shouldn't be relying on details of it. Nor should you be relying on your DB server having the same limits as your PHP server, so you'd need to check for 32-bit overflow anyway to install on a 64-bit system. Making the PHP side predictably support arbitrary precision would seem to remove special cases from userland, not add them. It shunts them into C code, which does all sorts of icky low-level stuff we'd like to ignore already. -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Question regarding stream wrappers and op code cache
Hi Guys, I have a doubt, is it efficient include/require files from a source different than the real file system a stream wrapper class? My question is, would the op-code cache work as it would when reading a file form the filesystem? Cheers, -- César D. Rodas Open Source developer +595-983-161124 PGP: F9ED A265 A3AB C8A1 D145 7368 158A 0336 C707 0AA6 signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] [RFC] Big Integer Support
On 3 Feb 2015, at 21:49, Lester Caine les...@lsces.co.uk wrote: On 03/02/15 16:44, Andrea Faulds wrote: Sure, but I don’t think we shouldn’t cripple the language merely for the sake of really low-end embedded devices. Also, I’m not convinced that the overhead, at least in terms of file size, is really that big of an issue. 'I don’t think we should cripple' ? There are two views on the handling of integers. Obviously it would be nice if there was no limit to the size of a number and there are situations where that is indeed useful. However there are equally situations where both the natural 32bit and 64bit limits of the target hardware and software needs to be observed and these require a different method of handling things like 'overflow’. Maybe. But PHP has never cared about those things. We promote to float when integers would “overflow” in another language. Simply automatically upgrading an integer value to a more complex object depending on what hardware one is running on adds the overhead of having to create code to disable things depending on some hardware flag. Not really. We already do promotion for integers to float, and it’s a very simple operation to check for overflow, natively supported by many compilers, and we also have a pure C fallback. All that bigints do is that instead of promoting to float, we promote to bigints. There’s no new overhead, these checks already existed, and have done for well over a decade. The only complexity bigints add are the addition of the new IS_BIGINT type (which goes in your operator type matrices etc.), and requiring some bigint library. With the bulk of SQL persistent data having to manage both 32 and 64bit integer limits and the matching float/numeric limits, a system of working which mirrors that would naturally seem to be the sensible default. Why should it match SQL? Why should we have the complexity of two different sizes of integer? Why not just have a single, unified arbitrary-precision integer type, like the RFC proposes. If those limitations have been avoided by the use of additional libraries, then a matching additional library in PHP also comes into play. Currently we have a problem with the size of integers, but simply ignoring that there are limits is not the may to fix that problem. This RFC doesn’t ignore that there are limits. Arbitrary-precision integers are, naturally, bounded by available RAM (including the request memory limit). -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] src karma request
Hello, On Mon, Feb 2, 2015 at 9:45 AM, Pierre Joye pierre@gmail.com wrote: found and added, php-src :) Thanks for your work! Thanks for adding that. Unfortunately I just tried to push it and it rejected me :) : [jakub@localhost master]$ git push upstream master Counting objects: 261, done. Delta compression using up to 4 threads. Compressing objects: 100% (202/202), done. Writing objects: 100% (203/203), 45.97 KiB | 0 bytes/s, done. Total 203 (delta 150), reused 0 (delta 0) remote: Welcome bukka. remote: You have insufficient Karma! remote: I'm sorry, I cannot allow you to write to remote: php-src.git/NEWS remote: php-src.git/UPGRADING remote: php-src.git/ext/json/CREDITS remote: php-src.git/ext/json/JSON_parser.c remote: php-src.git/ext/json/JSON_parser.h remote: php-src.git/ext/json/Makefile.frag remote: php-src.git/ext/json/config.m4 remote: php-src.git/ext/json/config.w32 remote: php-src.git/ext/json/json.c remote: php-src.git/ext/json/json_encoder.c remote: php-src.git/ext/json/json_parser.y remote: php-src.git/ext/json/json_scanner.c remote: php-src.git/ext/json/json_scanner.re remote: php-src.git/ext/json/php_json.h remote: php-src.git/ext/json/php_json_encoder.h remote: php-src.git/ext/json/php_json_parser.h remote: php-src.git/ext/json/php_json_scanner.h remote: php-src.git/ext/json/php_json_scanner_defs.h remote: php-src.git/ext/json/tests/bug54484.phpt remote: php-src.git/ext/json/tests/pass003.phpt remote: php-src.git/ext/json/utf8_decode.c remote: php-src.git/ext/json/utf8_decode.h remote: Have a nice day. To g...@git.php.net:php-src.git ! [remote rejected] master - master (pre-receive hook declined) error: failed to push some refs to 'g...@git.php.net:php-src.git Please can someone look at it? My username is bukka . Thanks a lot Jakub
Re: [PHP-DEV] [RFC] Big Integer Support
On Tue, Feb 3, 2015 at 10:44 AM, Andrea Faulds a...@ajf.me wrote: On 3 Feb 2015, at 14:49, Lester Caine les...@lsces.co.uk wrote: On 03/02/15 14:03, Andrea Faulds wrote: But I don’t consider 0.25MB extra to be such a problem in practice. The PHP binary is already huge, and every system running PHP will have ample memory. Yes one approach is 'computers are getting faster with lots of memory' ... and for servers this is not a problem ...they will more than likely be 64bit anyway! But for smaller embedded devices php *IS* becoming an option so I don't have to program in C or something else, and then we look to strip everything that does not need to be present. Sure, but I don’t think we shouldn’t cripple the language merely for the sake of really low-end embedded devices. Also, I’m not convinced that the overhead, at least in terms of file size, is really that big of an issue. Just for you, I’ve gone and compiled the bigint branch (with LibTomMath) and master on my machine: $ ls -l php7-* -rwxr-xr-x 1 ajf staff 6400408 3 Feb 16:39 php7-bigint -rwxr-xr-x 1 ajf staff 6248920 3 Feb 16:42 php7-master The difference is a mere 151488 B, or 151 KB. Is that really so bad? I would take 1MB if I had to so that I could have this in core. I work with them everyday and the pain of having to deal with them as strings is a royal pain. It would only become worse if this does not get into core and type hints do as the mess would be drastic for any systems that must handle 64bit integers across the board. It's not useful to have to always go to gmp to handle numbers of this type. It is simply not realistic. On top of that, we use embedded systems everyday. I have 6 devices sitting in front of me right now. Think of a GUID whereas they have large integer internal representations and a hex representation for human readable. On top of this, we also have beaglebones and raspberry pi's that have internal memory capacities where this easily fits and flash storage. There is no reason that this feature should be held back for embedded systems or even system on a chip. Regards, Mike
Re: [PHP-DEV] What do we need strict scalar type hints for?
Hi Dmitry, On Mon, Feb 2, 2015 at 6:12 PM, Dmitry Stogov dmi...@zend.com wrote: could you please write down few use cases, when strict scalar type hints are really useful. I'm not opposing to have scalar type hints, but assertion can do better job for it. I think you have proposed assert() w/o runtime overhead. Is this included in PHP7? Enable by opcache, perhaps? Sorry for OT. I'm curious. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] What do we need strict scalar type hints for?
Hi all,
On Wed, Feb 4, 2015 at 5:23 AM, Thomas Bley ma...@thomasbley.de wrote:
function addVat($amount) {
validateAmount($amount);
return round($amount*1.19, 2);
}
function validateAmount($amount) {
if (!is_int($amount) !is_float($amount)) {
throw new InvalidArgumentException('Argument amount must be of the
type int|float, '.gettype($amount).' given');
}
}
I use such code where runtime check is required.
I prefer following for better performance/readability. i.e. Pre/Post
conditions are inside of function definition.
If PHP supports native DbC, runtime checks are omitted and script runs
faster. NOTE: Dev time checks are
done in in/out block with proper DbC design. Runtime check should be in
function body.
function addVat($amount)
in {
// precondition check
assert(!is_int($amount) !is_float($amount));
// OR
if (!is_int($amount) !is_float($amount)) {
throw new InvalidArgumentException('Argument amount must be of the type
int|float, '.gettype($amount).' given');
}
}
out {
// postcondition check
assert(is_numeric($__return_vlaue) $__return_value 0
$__return_value MAX_AMOUNT);
}
{
// function body
return round($amount*1.19, 2);
}
Type hints are useful for simple runtime check.
Much less lines to write ;) It also encourage users to validate their app
inputs. This is important benefits for secure apps.
Things like these encourage proper DbC design naturally. Therefore, I'm +1
for all of these.
Regards,
--
Yasuo Ohgaki
yohg...@ohgaki.net
Re: [PHP-DEV] What do we need strict scalar type hints for?
I would prefer:
function addVat($amount) {
validateAmount($amount);
return round($amount*1.19, 2);
}
function validateAmount($amount) {
if (!is_int($amount) !is_float($amount)) {
throw new InvalidArgumentException('Argument amount must be of the type
int|float, '.gettype($amount).' given');
}
}
Regards
Thomas
Sven Drieling wrote on 03.02.2015 20:07:
Am Mon, 02 Feb 2015 23:38:21 +0100
schrieb Christoph Becker cmbecke...@gmx.de:
Hallo,
addVat(-1);
Well, my point was that even a strict type system doesn't necessarilly
catch all erroneous/undesired arguments. Even if addVat() properly
handles negative numbers, and maybe even zeroes, there are functions
that can't.
What about scalar type declaration in userland?
namespace mytypes;
declare scalartype amount($amount) {
if (!is_int($amount) !is_float($amount)) {
throw new InvalidArgumentException('Argument amount
must be of the type int|float, '.gettype($amount).' given');
}
}
function addVat(mytypes\amount $amount) {
return round($amount*1.19, 2);
}
addVat(42) // OK
addVat(42) // OK
addVat(-42) // OK
addVat(42.0) // OK
addVat(true) // Exception
var mytypes\amount $amount = 0;
$amount = 42; // OK
$amount = 42; // OK
$amount = true; // Exception
tschuess
[|8:)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Big Integer Support
On 03/02/15 19:59, Martin Keckeis wrote: Please get this mayor feature finally into the core In the current century a real 64bit support is not discussable anymore... Martin this has NOTHING to do with getting 64 bit support into core. That has already been achieved by the introduction of 64 bit builds. What this is about is modifying integer support so that when an integer gets bigger than 64bits on a 64bit platform, it automatically folds to a gmp object bidden in the background. My problem is with that process happening when a 32bit integer becomes a gmp object on a 32bit platform. Under some conditions that SHOULD overflow as it does currently, but in other conditions you want a 64 bit number that overflows at 64 bits even on the 32bit platform. As Leigh has also identified, handling of wrap around in these cases is equally important. 'Arbitrary integer math' has a place - fine, but most exist in parallel with fixed integer maths. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] $http_response_header
On Tue, Feb 3, 2015 at 10:33 AM, Julien Pauli jpa...@php.net wrote: On Mon, Feb 2, 2015 at 6:19 PM, Ferenc Kovacs tyr...@gmail.com wrote: On Tue, Dec 2, 2014 at 11:28 AM, Ferenc Kovacs tyr...@gmail.com wrote: On Tue, Dec 2, 2014 at 1:08 AM, Rowan Collins rowan.coll...@gmail.com wrote: On 1 December 2014 22:28:04 GMT, Ralph Schindler ra...@ralphschindler.com wrote: Hi all, Many of you know from reading the subject line whats coming next! ;) In php, after we interact with HTTP streams (as a client), PHP conjures into local scope a variable with header information from the previous request $http_response_header. Is this behavior something we want to keep around into PHP 7? Or should we find a different/short-cut way to get the information. Currently, the same information can be ascertained, but only if there is an open file handle and only through stream_get_meta_data($fh). It would be nice if there were an as-easy approach to getting data without perhaps conjuring magic variables into the beloved local scope? Thoughts? Ralph Schindler PS Also, do we have any other local-scope variables like this? Wow, I had no idea that existed; what an incredibly ugly implementation. Even the name is weird (why header singular when it contains an array of headers?) The only other local-scope variable listed next to it in the manual [1] is $php_errormsg, which has to be enabled with an ini setting. If the information is useful at all, then I guess a get_last_http_response_headers() function would be less magic - although that would presumably mean the data had to be stashed indefinitely in an internal global just in case it was asked for, rather than it naturally falling out of scope. We could just say that if you're using a shortcut like file_get_contents, you can't have it both ways and access metadata afterwards. It's just a pity ext/curl is so faithful to the underlying lib, and therefore so awkward to use for simple cases. [1]: http://php.net/manual/en/reserved.variables.php +1 on introducing the get_last function, and I would also suggest adding a new ini settings similarly to track_errors so we can discourage/deprecate the usage of this feature before removing it. -- Ferenc Kovács @Tyr43l - http://tyrael.hu bump. Hey. About $php_errormsg , we have error_get_last(). About $http_response_headers, we have no replacement. Why not get rid of both ? I mean, those variables magically appearing into your code are born from C, where libc usually give access to errno and errstr variables (which are often implemented as macros). As we are cleaning PHP and reorganizing it for PHP7, I simply would suggest to drop support for anything like automatic magic variable appearence. $HTTP_RAW_POST_DATA could as well disappear (made deprecated as of 5.6). Julien.P yeah, as I mentioned I support introducing a new function for fetching the info, but I'm a bit hesitant to remove these variables before we start deprecating them both in the manual and at least the ini usage. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] [VOTE] Feature request #38685: str_[i]replace(): Add support for (string needle, array replace)
Hi Francois, On Tue, Feb 3, 2015 at 2:00 AM, François Laupretre franc...@tekwire.net wrote: Opening the vote for : https://wiki.php.net/rfc/cyclic-replace This RFC adds support in str_replace() and str_ireplace() for the combination of (string needle, array replace). In this case, each occurrence of the needle is replaced with an element of the 'replace' array. I guess you mean discussion? Example code would be nice for this RFC. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] [VOTE] Feature request #38685: str_[i]replace(): Add support for (string needle, array replace)
Hi, On Mon, Feb 2, 2015 at 7:58 PM, François Laupretre franc...@tekwire.net wrote: De : Andrey Andreev [mailto:n...@devilix.net] I seem to have missed the new parameter (and constants) addition during the discussion ... sorry to say this, but that one would probably fail the RFC. Mmh... I don't like the idea of adding a parameter but several people argued that we needed a way to control looping behavior, as the original idea was to loop through the replace array. But I am still hesitating. Instead of voting on the RFC, please tell me which behavior you prefer : - an options argument to decide on the looping behavior, - always stopping replacements when the replace array is exhausted - always looping The other options are too exotic to become the default behavior. Always looping, the other option is already covered by strtr(). I'd like control over the behavior too, but that just makes the API really ugly. Cheers, Andrey. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] Feature request #38685: str_[i]replace(): Add support for (string needle, array replace)
On Feb 3, 2015 1:08 PM, Andrey Andreev n...@devilix.net wrote: Hi, On Mon, Feb 2, 2015 at 7:58 PM, François Laupretre franc...@tekwire.net wrote: De : Andrey Andreev [mailto:n...@devilix.net] I seem to have missed the new parameter (and constants) addition during the discussion ... sorry to say this, but that one would probably fail the RFC. Mmh... I don't like the idea of adding a parameter but several people argued that we needed a way to control looping behavior, as the original idea was to loop through the replace array. But I am still hesitating. Instead of voting on the RFC, please tell me which behavior you prefer : - an options argument to decide on the looping behavior, - always stopping replacements when the replace array is exhausted - always looping The other options are too exotic to become the default behavior. Always looping, the other option is already covered by strtr(). I'd like control over the behavior too, but that just makes the API really ugly. Cheers, Andrey. Or rather, should be covered by strtr(). Cheers, Andrey.
Re: [PHP-DEV] Question regarding stream wrappers and op code cache
On 03/02/15 20:55, Leigh wrote: On 3 February 2015 at 23:26, Cesar Rodas ce...@rodas.me wrote: Hi Guys, I have a doubt, is it efficient include/require files from a source different than the real file system a stream wrapper class? My question is, would the op-code cache work as it would when reading a file form the filesystem? Do you mean if you `include 'mystream://something.php'; ? Yes, that's exactly what I *tried* to ask! Interesting question. I'd like to think that when opcache tries to stat the file that streamWrapper::url_stat is called, and keeping the mtime the same will cause the cached version to be used. Really no idea though, I'd like to know the answer too. Let's wait then! Cheers, -- César D. Rodas Open Source developer +595-983-161124 PGP: F9ED A265 A3AB C8A1 D145 7368 158A 0336 C707 0AA6 signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] Question regarding stream wrappers and op code cache
On 3 February 2015 at 23:26, Cesar Rodas ce...@rodas.me wrote: Hi Guys, I have a doubt, is it efficient include/require files from a source different than the real file system a stream wrapper class? My question is, would the op-code cache work as it would when reading a file form the filesystem? Do you mean if you `include 'mystream://something.php'; ? Interesting question. I'd like to think that when opcache tries to stat the file that streamWrapper::url_stat is called, and keeping the mtime the same will cause the cached version to be used. Really no idea though, I'd like to know the answer too. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PS(invalid_session_id) ?
On Feb 4, 2015 2:51 AM, Yasuo Ohgaki yohg...@ohgaki.net wrote: I added comments to ext/session/mod_files.c for save handler developers. Please refer to it also. Please add them (and maybe example migration code) to UPGRADING.INTERNALS Thanks!
Re: [PHP-DEV] [RFC][VOTE] Removal of dead or not yet PHP7 ported SAPIs and extensions
Anatol Belski in php.internals (Tue, 3 Feb 2015 09:11:18 +0100): Hi Michael, On Tue, February 3, 2015 08:31, Michael Wallner wrote: On 3 Feb 2015 08:10, Adam Harvey ahar...@php.net wrote: I understand your thoughts. How about if we do for mcrypt what we did for mhash, I.e. implement a compatible layer on top of openssl? I have not checked if it's even possible yet, just an idea that popped into mind. I would be willing to do this to learn more about the openssl innards, so I'd probably need someone else to verify my work. if you venture to do this, please ping. I can support you at least with testing and maybe more. Daniel Stenberg (curl dev) happened to point to libtomcrypt today: https://github.com/libtom/libtomcrypt Jan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Big Integer Support
On 03/02/15 22:35, Andrea Faulds wrote: Currently we have a problem with the size of integers, but simply ignoring that there are limits is not the may to fix that problem. This RFC doesn’t ignore that there are limits. Arbitrary-precision integers are, naturally, bounded by available RAM (including the request memory limit). BUT the whole problem currently IS the crap way 32bit integers roll over to float. And trying to handle 64bit integers currently on PHP IS a problem because of it. The current easy fix is simply to ignore the top 32 bits of BIGINT, but that solution is no longer practical with the growing volume of data we are handling. If I could ignore the 32bit builds then I would and then all that is required is something to switch off rolling out of the 64 bit integer and only support 64bit servers, but the remote machines are all going to be 32bit. It is ignoring the limitations of hardware that cause problems and while it may seem simple to 'do everything in abstract software' at some point just how the hardware is affecting the results comes into play. If you are going to add this abstract integer type, then it is equally important that the model also includes ranging, and length management so that things like bit wrapping work as expected. strict types should know that only an integer of a certain range is acceptable otherwise we have to add THAT at the library level. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] src karma request
my fault, did not commit the change :D It should be fine now. On Wed, Feb 4, 2015 at 3:21 AM, Jakub Zelenka bu...@php.net wrote: Hello, On Mon, Feb 2, 2015 at 9:45 AM, Pierre Joye pierre@gmail.com wrote: found and added, php-src :) Thanks for your work! Thanks for adding that. Unfortunately I just tried to push it and it rejected me :) : [jakub@localhost master]$ git push upstream master Counting objects: 261, done. Delta compression using up to 4 threads. Compressing objects: 100% (202/202), done. Writing objects: 100% (203/203), 45.97 KiB | 0 bytes/s, done. Total 203 (delta 150), reused 0 (delta 0) remote: Welcome bukka. remote: You have insufficient Karma! remote: I'm sorry, I cannot allow you to write to remote: php-src.git/NEWS remote: php-src.git/UPGRADING remote: php-src.git/ext/json/CREDITS remote: php-src.git/ext/json/JSON_parser.c remote: php-src.git/ext/json/JSON_parser.h remote: php-src.git/ext/json/Makefile.frag remote: php-src.git/ext/json/config.m4 remote: php-src.git/ext/json/config.w32 remote: php-src.git/ext/json/json.c remote: php-src.git/ext/json/json_encoder.c remote: php-src.git/ext/json/json_parser.y remote: php-src.git/ext/json/json_scanner.c remote: php-src.git/ext/json/json_scanner.re remote: php-src.git/ext/json/php_json.h remote: php-src.git/ext/json/php_json_encoder.h remote: php-src.git/ext/json/php_json_parser.h remote: php-src.git/ext/json/php_json_scanner.h remote: php-src.git/ext/json/php_json_scanner_defs.h remote: php-src.git/ext/json/tests/bug54484.phpt remote: php-src.git/ext/json/tests/pass003.phpt remote: php-src.git/ext/json/utf8_decode.c remote: php-src.git/ext/json/utf8_decode.h remote: Have a nice day. To g...@git.php.net:php-src.git ! [remote rejected] master - master (pre-receive hook declined) error: failed to push some refs to 'g...@git.php.net:php-src.git Please can someone look at it? My username is bukka . Thanks a lot Jakub -- 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] libmcrypt: abandonware?
On Thu, Dec 11, 2014 at 5:10 PM, Derick Rethans der...@php.net wrote: On Wed, 10 Dec 2014, Andrea Faulds wrote: On 10 Dec 2014, at 06:33, Remi Collet r...@fedoraproject.org wrote: Having a dead upstream for crypto API is a critical issue :( FYI some downstream (ex RHEL) don't even provide this library. Already too much crypto libraries, and it will be a mess to provide a dead project in an Enterprise distribution. So php/mcrypt also not available. But most applications. which use it, usually have alternative, and make it optional (ex phpMyAdmin 4.3 now even use openssl as first choice). We probably have enough crypto API in PHP, and we probably should mark this one as deprecated / unmaintained in 5.x, and move it to PECL (7.x). It’s my understanding that ext/mcrypt is quite widely used. Would it not be possible to update the lib to use OpenSSL or something on the backend, so existing applications would not need changing? I think you're going to find this difficult, as the mcrypt implementations can have some odd quircks in them. As the maintainer of this extension I'd say to just drop it in PHP 7. I wouldn't even bother trying to make it compile for it. You won't bother but we should? Wondering why you voted against removing it. -- Pierre @pierrejoye | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Failing test for bug #61470
Hi Stas, On Tue, Feb 3, 2015 at 5:04 AM, Stanislav Malyshev smalys...@gmail.com wrote: I see you've added test for #61470 to 5.5 and up. But this test is failing on CI. Could you please look into it and fix it or revert it until it works? Sorry, it was my mistake. It seems I should have run tests on my personal checkouts. It's removed already. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] [RFC][VOTE] Removal of dead or not yet PHP7 ported SAPIs and extensions
On 03/02/15 09:14, Pierre Joye wrote: I wonder if ANY mssql users have noticed that they may be left out of PHP7 ... I suspect that may actually have a bigger user base than the paid for 'Interbase' yet it's got no support here. For mssql, most of them (while we see more and more requests from linux lately) are on windows. And mssql support has been removed with the release of 5.3.0. Since 2 years they use sqlsrv from pecl. I spotted the reference to using ODBC as an alternative as well which does get used for Firebird in some areas. The point perhaps is that like mysql, the information as to what IS the preferred method of working these days is not being linked to the discussion? There is useful material on a number of these 'removals' but it's all mixed up in the one thread :( Separate 'crib sheets' to support each eventual change? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] $http_response_header
On Mon, Feb 2, 2015 at 6:19 PM, Ferenc Kovacs tyr...@gmail.com wrote: On Tue, Dec 2, 2014 at 11:28 AM, Ferenc Kovacs tyr...@gmail.com wrote: On Tue, Dec 2, 2014 at 1:08 AM, Rowan Collins rowan.coll...@gmail.com wrote: On 1 December 2014 22:28:04 GMT, Ralph Schindler ra...@ralphschindler.com wrote: Hi all, Many of you know from reading the subject line whats coming next! ;) In php, after we interact with HTTP streams (as a client), PHP conjures into local scope a variable with header information from the previous request $http_response_header. Is this behavior something we want to keep around into PHP 7? Or should we find a different/short-cut way to get the information. Currently, the same information can be ascertained, but only if there is an open file handle and only through stream_get_meta_data($fh). It would be nice if there were an as-easy approach to getting data without perhaps conjuring magic variables into the beloved local scope? Thoughts? Ralph Schindler PS Also, do we have any other local-scope variables like this? Wow, I had no idea that existed; what an incredibly ugly implementation. Even the name is weird (why header singular when it contains an array of headers?) The only other local-scope variable listed next to it in the manual [1] is $php_errormsg, which has to be enabled with an ini setting. If the information is useful at all, then I guess a get_last_http_response_headers() function would be less magic - although that would presumably mean the data had to be stashed indefinitely in an internal global just in case it was asked for, rather than it naturally falling out of scope. We could just say that if you're using a shortcut like file_get_contents, you can't have it both ways and access metadata afterwards. It's just a pity ext/curl is so faithful to the underlying lib, and therefore so awkward to use for simple cases. [1]: http://php.net/manual/en/reserved.variables.php +1 on introducing the get_last function, and I would also suggest adding a new ini settings similarly to track_errors so we can discourage/deprecate the usage of this feature before removing it. -- Ferenc Kovács @Tyr43l - http://tyrael.hu bump. Hey. About $php_errormsg , we have error_get_last(). About $http_response_headers, we have no replacement. Why not get rid of both ? I mean, those variables magically appearing into your code are born from C, where libc usually give access to errno and errstr variables (which are often implemented as macros). As we are cleaning PHP and reorganizing it for PHP7, I simply would suggest to drop support for anything like automatic magic variable appearence. $HTTP_RAW_POST_DATA could as well disappear (made deprecated as of 5.6). Julien.P
Re: [PHP-DEV] [RFC][VOTE] Removal of dead or not yet PHP7 ported SAPIs and extensions
On 03/02/15 08:44, Matteo Beccati wrote: Marius Adrian Popa has stated to maintain both, and looks like there several active users who will use that. So going by that, it's not being voted on these exts. I must have missed that, sorry for the noise. This is a bit of the problem here. There is a substantial Firebird user base who like wordpress and joomla users have no knowledge of what is going on in the background to keep their platform working. Often we don't find out about things - 'they get missed' - but similarly just treading water takes too much time today so following development on everything we do use often takes second place? I wonder if ANY mssql users have noticed that they may be left out of PHP7 ... I suspect that may actually have a bigger user base than the paid for 'Interbase' yet it's got no support here. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Enable opcache by default in PHP7?
OPcache will bring nothing to dev env, except possible failures and WTFs. So I suggest not enabling it in development php.ini. Julien.P On Tue, Feb 3, 2015 at 6:59 AM, Pierre Joye pierre@gmail.com wrote: On Feb 3, 2015 11:26 AM, Xinchen Hui larue...@php.net wrote: Hey: opcache is disabled by default configure, I am plan to enable it by default and also add zend_extension=opcache.so in php.ini-product/developmement is there any objections or concerns? thanks No problem here for production. I am however not sure about Dev, it can still be disable using ini setting but I am not sure it works well with any debugging extension out there. Does it?
Re: [PHP-DEV] [RFC][VOTE] Removal of dead or not yet PHP7 ported SAPIs and extensions
On Feb 3, 2015 4:06 PM, Lester Caine les...@lsces.co.uk wrote: On 03/02/15 08:44, Matteo Beccati wrote: Marius Adrian Popa has stated to maintain both, and looks like there several active users who will use that. So going by that, it's not being voted on these exts. I must have missed that, sorry for the noise. This is a bit of the problem here. There is a substantial Firebird user base who like wordpress and joomla users have no knowledge of what is going on in the background to keep their platform working. Often we don't find out about things - 'they get missed' - but similarly just treading water takes too much time today so following development on everything we do use often takes second place? I wonder if ANY mssql users have noticed that they may be left out of PHP7 ... I suspect that may actually have a bigger user base than the paid for 'Interbase' yet it's got no support here. For mssql, most of them (while we see more and more requests from linux lately) are on windows. And mssql support has been removed with the release of 5.3.0. Since 2 years they use sqlsrv from pecl.
Re: [PHP-DEV] [RFC] Big Integer Support
On 03/02/15 16:44, Andrea Faulds wrote: Sure, but I don’t think we shouldn’t cripple the language merely for the sake of really low-end embedded devices. Also, I’m not convinced that the overhead, at least in terms of file size, is really that big of an issue. 'I don’t think we should cripple' ? There are two views on the handling of integers. Obviously it would be nice if there was no limit to the size of a number and there are situations where that is indeed useful. However there are equally situations where both the natural 32bit and 64bit limits of the target hardware and software needs to be observed and these require a different method of handling things like 'overflow'. Simply automatically upgrading an integer value to a more complex object depending on what hardware one is running on adds the overhead of having to create code to disable things depending on some hardware flag. With the bulk of SQL persistent data having to manage both 32 and 64bit integer limits and the matching float/numeric limits, a system of working which mirrors that would naturally seem to be the sensible default. If those limitations have been avoided by the use of additional libraries, then a matching additional library in PHP also comes into play. Currently we have a problem with the size of integers, but simply ignoring that there are limits is not the may to fix that problem. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
