Re: [PHP-DEV] PDO & size_t
Hey: On Mon, Jan 26, 2015 at 8:43 AM, Stanislav Malyshev wrote: > Hi! > > With recent moving of string lengths to size_t, it looks like PDO APIs > weren't updated. I.e.: > > typedef int (*pdo_stmt_get_col_data_func)(pdo_stmt_t *stmt, int colno, > char **ptr, zend_ulong *len, int *caller_frees); > > This looks like len should be size_t, and in fact fetch_value() in > pdo_stmt.c sends size_t parameter there, but since I'm not very familiar > with PDO internals, I'd like to double check - is it an omission and > will anything break if I change it to size_t? I think it is okey, of course you should change all related apis in pdo_* drivers thanks > > There are also other things, like: > > const char *driver_name; > zend_ulong driver_name_len; > > typedef int (*pdo_dbh_prepare_func)(pdo_dbh_t *dbh, const char *sql, > zend_long sql_len, pdo_stmt_t *stmt, zval *driver_options); > > typedef zend_long (*pdo_dbh_do_func)(pdo_dbh_t *dbh, const char *sql, > zend_long sql_len); > > typedef int (*pdo_dbh_quote_func)(pdo_dbh_t *dbh, const char *unquoted, > int unquotedlen, char **quoted, int *quotedlen, enum pdo_param_type > paramtype); > > As you can see, sometimes length is an int, sometimes zend_long, > sometimes zend_ulong. This looks like it needs some cleanup. > -- > Stas Malyshev > smalys...@gmail.com > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- Xinchen Hui @Laruence http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] PDO & size_t
Hi! With recent moving of string lengths to size_t, it looks like PDO APIs weren't updated. I.e.: typedef int (*pdo_stmt_get_col_data_func)(pdo_stmt_t *stmt, int colno, char **ptr, zend_ulong *len, int *caller_frees); This looks like len should be size_t, and in fact fetch_value() in pdo_stmt.c sends size_t parameter there, but since I'm not very familiar with PDO internals, I'd like to double check - is it an omission and will anything break if I change it to size_t? There are also other things, like: const char *driver_name; zend_ulong driver_name_len; typedef int (*pdo_dbh_prepare_func)(pdo_dbh_t *dbh, const char *sql, zend_long sql_len, pdo_stmt_t *stmt, zval *driver_options); typedef zend_long (*pdo_dbh_do_func)(pdo_dbh_t *dbh, const char *sql, zend_long sql_len); typedef int (*pdo_dbh_quote_func)(pdo_dbh_t *dbh, const char *unquoted, int unquotedlen, char **quoted, int *quotedlen, enum pdo_param_type paramtype); As you can see, sometimes length is an int, sometimes zend_long, sometimes zend_ulong. This looks like it needs some cleanup. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP7 Homework for everyone reading this list
On Jan 25, 2015 3:31 AM, "Jan Ehrhardt" wrote: > > Pavel Kou?il in php.internals (Sat, 24 Jan 2015 19:07:28 +0100): > >> https://phpdev.toolsforresearch.com/php-7.0.0-dev-nts-Win32-VC11-x86.htm > >> https://phpdev.toolsforresearch.com/php-7.0.0-dev-nts-Win32-VC11-x86.zip > > https://phpdev.toolsforresearch.com/php-7.0.0-dev-Win32-VC11-x86.htm > https://phpdev.toolsforresearch.com/php-7.0.0-dev-Win32-VC11-x86.zip > > >may I use your build for testing my applications compability with PHP7? > > Yes, of course. That is what they are for. Yes, but if you find some bugs, repro with the snaps on windows.php.net There are bugs which are compiler or config specific, that's why we will ask to use our builds if necessary.
[PHP-DEV] Stepping stones to a working php7 ...
Crib sheet for today's work ... Slowly getting on top of all the bits I need to get my development site running on PHP7. http://php7.lsces.org.uk/phpinfo.php is running in parallel with http://lsces.org.uk/phpinfo.php. Little niggles on the way to a matching shared library layout to match the PHP5 one on SUSE13.1 /zlib ... rename config0.m4 to config.m4 to build /pdo_firebird had to manually link firebird include files and builds a clean extenstion /interbase also manual lnk, but build has warnings - is working though. /openssl ... rename config0.m4 to config.m4 to build /ldap ... can't find library files /imagick ... need to get a copy to work with Need a mysql setup for some conversion work, but not managed to get that included as yet. Think I need to include mysqlnd in the core build as a start? -- 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] [VOTE] jsond
> On 25 Jan 2015, at 23:02, Juan Basso wrote: > > Andrea, > > > I did a PR to Jakub's branch with changes of preserve fractional part rfc > after it was approved. His branch has the same implementation that was merged > into 5.6, but adapted to master. > > Also, as he mentioned, the same behavior, options disabled by default. Alright, 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] Re: PHP7 Homework for everyone reading this list
Michael Wallner in php.internals (Sun, 25 Jan 2015 18:32:18 +0100): >On 23/01/15 22:18, Jan Ehrhardt wrote: >> Dmitry Stogov in php.internals (Fri, 23 Jan 2015 17:54:45 +0400): >>> "master" branch. >> >> propro, raphf and pecl_http do not compile with the master branch. >> You'll have to checkout the phpng branch. These extensions did compile >> and load: >> https://phpdev.toolsforresearch.com/php-7.0.0-dev-nts-Win32-VC11-x86.htm > >Dmitry is sort of right, actually. The plan is to merge phpng back into >master of course, and do legacy releases out of the R_2_* branches. But then we have the problem the other way around: you will have to checkout special branches to compile for 5.x. Will that be 'phpog'? Or is your plan to make a special version for PHP 5.x? I noticed Joe Watkins has a 'five' branch besides master in pthreads. Just guessing: is the 'five' for PHP 5.x and the master for PHP7? We surely need a list of the extensions that have been ported to PHP7 and where to find them. Jan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] jsond
Andrea, I did a PR to Jakub's branch with changes of preserve fractional part rfc after it was approved. His branch has the same implementation that was merged into 5.6, but adapted to master. Also, as he mentioned, the same behavior, options disabled by default. Juan Baso On Jan 25, 2015 1:08 PM, "Andrea Faulds" wrote: > Hi Jakub, > > What’s the status of the Preserve Fractional Part RFC with relation to the > jsond extension? > > I’d like to know that before voting. > > Thanks. > > > On 25 Jan 2015, at 17:29, Jakub Zelenka wrote: > > > > Hi All! > > > > Voting on jsond is now open: > > > > https://wiki.php.net/rfc/jsond > > > > It's a simple Yes/No vote whether jsond should replace the current json > > extension in PHP 7. > > > > Cheers > > > > Jakub > > -- > 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] RFC: Introduce session_start() options - read_only, unsafe_lock, lazy_write and lazy_destroy
Hi all, On Thu, Jan 22, 2015 at 2:05 PM, Yasuo Ohgaki wrote: > I've made patch for master since PHP 5.6 is released already. > > https://wiki.php.net/rfc/session-lock-ini > https://github.com/php/php-src/pull/1016 > > Except comments, changes are almost minimal, but includes a few bug fixes > that tests equality of PS(session_status) against "php_session_none". The > comparison must be "PS(session_status) != php_session_active" as it has > php_session_disabled. I also removed 2 needless session globals. > > Comments are appreciated. > This patch boosts PHP application performance a lot when session data > have not changed. It's faster than benchmark in the wiki because hashing > has removed. > > If I don't have any comment in a few days, I'll merge it to master. > I've updated UPGRADING and UPGRADING.INTERNALS and ready to merge. I'll wait a day more. Please comment on github if you have. Thank you. Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] [RFC] Scalar Type Hints
On Sun, Jan 25, 2015 at 5:05 PM, Andrea Faulds wrote: > Hi Pavel, > Hi, thanks for explaining some things. > > It can *sometimes* be a lossless conversion. Only sometimes. > > For float to int conversion: > > * Floats have the special values INF, NAN and -NAN, which cannot be preserved > * Floats have negative zero, which also cannot be preserved > * Fractional components cannot be preserved > * Floats sacrifice precision to allow a wider range of values. They work with > significant figures (scientific notation), unlike integers which always offer > full precision. So a particular float value isn’t necessarily equivalent to a > particular integer value, you have to invent precision to do the conversion. > 2e10 is dealt with as if it’s 2 with 10 zeroes after it, but it’s just a > number beginning with 2 that has a magnitude of roughly 10^10. If you convert > it to the integer value 20 000 000 000, you’ve just invented values for those > trailing digits - those digits weren’t necessarily zero, we just don’t know > what those digits are. Someone who’s an expert on floating-point might need > to correct me here, but I think this is correct to some extent. What I’m > saying is that float->integer conversion is inherently imprecise. > > For int to float conversion: > > * Values beyond 2^53 or below -2^53 cannot be represented as floats without a > loss of precision > > Some strongly-typed languages allow these conversions implicitly, but I’m not > sure that’s a good thing or something we should want to copy. Loss of > precision isn’t good. If you ask for strict typing, you probably want to > avoid it, and should get strict typing. > >> And being able to pass a float(1.5) to int and lose the 0.5 value >> doesn't make sense as well, because data will get lost. Neither of >> those feels somehow "predictable" and "natural”. > > Sure, but it is our existing behaviour. > Yeah, as I said, implicit float to int is IMHO bad and I personally don't like it much, because data loss sucks. But being consistent with existing behavior is probably the right way to do stuff. About the problem with int to float and loss of precision beyond 2^53: I didn't realize that, was thinking just about 32bit integers when I wrote that. But now I wonder how other languages do it, when they are implicitly converting 64bit integers to double precision floating point numbers. > > Unfortunately we don’t have safe casting functions because they were > rejected. Alas. > >> So, I think it would be best to choose just one of these two >> approaches and either loosen it a little or make it more strict (so >> data loss doesn't happen). But I guess this approach would be >> inconsistent with how the built-in PHP functions work? > > While it never went to a vote, the Scalar Type Hinting with Casts RFC, which > proposed stricter weak casts, was not well-received. The Safe Casting > Functions RFC was rejected when it went to a vote. > Oh, I didn't know that stricter weak casts were not well-recieved, because I didn't read internals mailing list back then. But if that's the case, I would gladly see the weak variant of this RFC accepted. Have you thought about splitting this RFC into two? One for adding the weak version and another one for adding the declare strict statement? > > The Scalar Type Hinting with Casts RFC didn’t do that, it was also based on > values. > > In a dynamically-typed language like PHP, I don’t see why it needs to be > type-based rather than value-based. > Maybe I wrote it wrong; I knew the old RFC had conversions based on values. I just thought the rules based on types (you definitely know what you need to convert and what not before calling a function) would make much more sense, but the problem with 2^53 means that the typed-based conversions are not a great solution either. Pavel Kouril -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] jsond
On Sun, Jan 25, 2015 at 6:27 PM, Stanislav Malyshev wrote: > > > Please do not forget to add all BC-breaking changes in UPGRADING > (currently not part of the patch). > Just added in https://github.com/bukka/php-src/commit/22394b79423b6c4eab3d43e246e03fc3feedfff5 . ;) Thanks
Re: [PHP-DEV] [VOTE] jsond
Hi On Sun, Jan 25, 2015 at 6:07 PM, Andrea Faulds wrote: > > What’s the status of the Preserve Fractional Part RFC with relation to the > jsond extension? > The preserve fractional part RFC has been accepted as a non-default option. It's also non-default option in jsond and the proposed patch. You probably ask me because I wanted to make it default. :) However I don't want to change it if the flag is already in. It would make mess in the default flag (option) value which would be changed from 0 and complicate the current way of enabling and disabling flags - people would have look to the doc to see what the default is and then OR this option with their settings if they wanted to keep the default and add a new flag - that would be just wrong IMHO... It means that I don't have any plans to propose such thing. And even if I had, it wouldn't be part of this RFC. ;) Cheers Jakub
Re: [PHP-DEV] [VOTE] jsond
Hi! > https://wiki.php.net/rfc/jsond > > It's a simple Yes/No vote whether jsond should replace the current json > extension in PHP 7. Please do not forget to add all BC-breaking changes in UPGRADING (currently not part of the patch). -- 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 results for default ctors RFC
> De : Dan Ackroyd [mailto:dan...@basereality.com] > > However I think there is a strong risk of people having to give a > reason why they voted no being abused, particularly if it is shown > while the voting was taking place, as people could be harassed for > choosing an 'invalid' reason to reject the RFC. Some suggestions for a future hypothetical RFC software : - Individual votes are kept secret. Just make public the number of voters and overall result. Each voter sees its own vote. - Vote starts with RFC discussion. - A voter can modify its vote until vote closes. - Votes span a range from '-2' (completely disagree) to '+2' (fully agree). - A minimal number of voters (quorum) is required for an RFC to be approved. - and, most important, comments are stored with the RFC, and mirrored to the mailing list. Please comment. Even if we don't have it today, maybe we can agree on an objective for tomorrow. I was looking for such a software, as I thought such needs are very common among open source projects, but I didn't find anything convincing. The best solution I imagine would be github adding an optional voting feature to issues (would we need to restrict access to vote or would we accept anybody with a github account ?). Github issues already have almost everything we need, except voting. Cheers François -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Vote results for default ctors RFC
Hi! > It was a fairly simple proposed change with a well-defined set of > impacted change; what diversity of disagreement do you expect? I've already have a number of reasons I haven't heard before, or didn't know their relative importance to people. I think hearing people out - not necessarily agreeing, but at least being aware of the differences - is a part of the healthy process, while silently turning your back is not. People may think it's "noise" - and it can be if done excessively - but I think it's an important function of the community. -- 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 results for default ctors RFC
Hi! > 2) I don't see a flood of people coming to the mailing list complaining > about this feature, so I'm not compelled to want it in the language. That's true for most features, and that's normal - in fact, I can't remember a feature or a fix where we had a flood of people coming to the list. And a pretty strange reason to refuse a new thing - nobody develops new things by sitting and waiting for people to complain enough about not having this exact thing. Apple didn't make iPhone because a lot of people came to them and asked them to make an iPhone. Of course, I'm not comparing my little RFC to a technological breakthrough, but the whole premise that new things can be made only when enough people complained about not having it sounds wrong to me. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [VOTE] jsond
Hi Jakub, What’s the status of the Preserve Fractional Part RFC with relation to the jsond extension? I’d like to know that before voting. Thanks. > On 25 Jan 2015, at 17:29, Jakub Zelenka wrote: > > Hi All! > > Voting on jsond is now open: > > https://wiki.php.net/rfc/jsond > > It's a simple Yes/No vote whether jsond should replace the current json > extension in PHP 7. > > Cheers > > Jakub -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [VOTE] jsond
Hi All! Voting on jsond is now open: https://wiki.php.net/rfc/jsond It's a simple Yes/No vote whether jsond should replace the current json extension in PHP 7. Cheers Jakub
Re: [PHP-DEV] Re: PHP7 Homework for everyone reading this list
On 23/01/15 22:18, Jan Ehrhardt wrote: > Dmitry Stogov in php.internals (Fri, 23 Jan 2015 17:54:45 +0400): >> "master" branch. > > propro, raphf and pecl_http do not compile with the master branch. > You'll have to checkout the phpng branch. These extensions did compile > and load: > https://phpdev.toolsforresearch.com/php-7.0.0-dev-nts-Win32-VC11-x86.htm Dmitry is sort of right, actually. The plan is to merge phpng back into master of course, and do legacy releases out of the R_2_* branches. -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Vote results for default ctors RFC
On 25 January 2015 at 15:44, Dan Ackroyd wrote: > On 25 January 2015 at 11:26, Peter Cowburn wrote: > > That's what the mailing list threads are for, right? > > > If someone has already said a reason on the list for why an RFC should > be voted no, when someone else agrees with that reason it's not common > for them to email, as it could be viewed as generating noise. > Any internals discussion thread can be viewed as generating noise. How are readers to know whether the one post mentioning a particular for/against reason has wider support/disapproval without people saying so in the central discussion thread(s)? If it were a "noise or nothing" decision, I'd rather have multiple people saying "+1" on a particular thought or idea *during the discussion phase* than everyone keeping quiet for fear of being "noisy". Of course, I'd really rather posts be slightly longer and well thought-out than "+1" too. > > Also having all the reasons why an RFC was declined in one place would > make it easier to revisit RFCs in the future. It would allow people to > see if RFCs were declined because people thought they were just a bad > idea, or if there was a problem with a small detail of the RFC, > without having to wade through email archives. > There's nothing, procedurally, preventing RFC authors from summarising the discussion around an RFC on the RFC's wiki page; say after a vote has been finished, or even before the voting period. > > However I think there is a strong risk of people having to give a > reason why they voted no being abused, particularly if it is shown > while the voting was taking place, as people could be harassed for > choosing an 'invalid' reason to reject the RFC. > I too fear the "that's a terrible reason to vote the way you did" knee-jerk reactions. Then again, I could merrily vote "yes" to every single RFC without raising a whiff of suspicion or ridicule. :) > > cheers > Dan >
Re: [PHP-DEV] Re: [PHP-CVS] Re: Broken apps
On Sun, Jan 25, 2015 at 3:18 PM, Lester Caine wrote: > On 25/01/15 13:52, Matteo Beccati wrote: > > Not yet. For now, use --without-pear. > > Just for the record ... There have been various comments about PEAR's > future. There is a substantial base of code using it. However the > versions downloaded direct may not actually be usable currently so some > plan to make that code base usable again probably needs to be on the > PHP7 todo list? > > I will cross check the PEAR modules I am currently using when I get that > far since they have already been made e_strict clean. > > -- > 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 > > I've added a PR for pear-core(https://github.com/pear/pear-core/pull/33), with those fixes I was able to build a install-pear-nozlib.phar which when copied to php-src/pear/ made make install without error (and I was able to install pear/pecl packages so it seems to be working fine) As I mentioned in the PR, I think it is likely that we will be other upcoming BC breaks requiring changes in PEAR, so instead of requiring a PEAR release and rebuilding http://pear.php.net/install-pear-nozlib.phar I would suggest having a php7 compatible install-pear-nozlib.phar committed to php-src for now (until we have release freeze with php7). What do you think? -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] Warnings in zend_alloc.h
Am 25.01.2015 um 17:17 schrieb Andi Gutmans: > Can you provide more info re: operating system and version? > Compiler version? $ cat /etc/issue Fedora release 21 (Twenty One) $ clang --version clang version 3.5.0 (tags/RELEASE_350/final) Target: x86_64-redhat-linux-gnu Thread model: posix -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Warnings in zend_alloc.h
Can you provide more info re: operating system and version? Compiler version?
Thanks.
Sent from my iPhone
> On Jan 24, 2015, at 11:57 PM, Sebastian Bergmann wrote:
>
> Nut sure whether this is an issue or not but I see it a lot while
> compiling master:
>
> Zend/zend_alloc.h:57:236: warning: unknown attribute 'alloc_size'
> ignored [-Wunknown-attributes]
> __attribute__ ((visibility("default"))) void* _emalloc(size_t size,
> const char *__zend_filename, const uint __zend_lineno,
> const char *__zend_orig_filename, const uint __zend_orig_lineno)
> __attribute__ ((__malloc__)) __attribute__ ((alloc_size(1)));
>
> Zend/zend_alloc.h:61:250: warning: unknown attribute 'alloc_size'
> ignored [-Wunknown-attributes]
> __attribute__ ((visibility("default"))) void* _ecalloc(size_t nmemb,
> size_t size , const char *__zend_filename, const uint __zend_lineno,
> const char *__zend_orig_filename, const uint __zend_orig_lineno)
> __attribute__ ((__malloc__)) __attribute__ ((alloc_size(1,2)));
>
> Zend/zend_alloc.h:62:238: warning: unknown attribute 'alloc_size'
> ignored [-Wunknown-attributes]
> __attribute__ ((visibility("default"))) void* _erealloc(void *ptr,
> size_t size, int allow_failure , const char *__zend_filename,
> const uint __zend_lineno , const char *__zend_orig_filename,
> const uint __zend_orig_lineno) __attribute__ ((alloc_size(2)));
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Scalar Type Hints
Hi Pavel, > On 25 Jan 2015, at 08:38, Pavel Kouřil wrote: > > personally I still don't like this RFC in it's current form and > "shorter" declare won't change it. I didn’t expect that making it shorter would really change anyone’s opinions, except perhaps those who don’t like the term “type hint”. > I was thinking a lot about the > typehints in PHP for last few days and I think having only one way > would be the best - and it's somewhere between the curent weak and > strict typing. My main "issue" is that the current weak typing is too > loose and the strict typing is too strict. > > The problem with the current strict typing is that you cannot pass > "int" to a "float" parameter, even though there can be a totally > lossless conversion and it works in other strongly typed languages. It can *sometimes* be a lossless conversion. Only sometimes. For float to int conversion: * Floats have the special values INF, NAN and -NAN, which cannot be preserved * Floats have negative zero, which also cannot be preserved * Fractional components cannot be preserved * Floats sacrifice precision to allow a wider range of values. They work with significant figures (scientific notation), unlike integers which always offer full precision. So a particular float value isn’t necessarily equivalent to a particular integer value, you have to invent precision to do the conversion. 2e10 is dealt with as if it’s 2 with 10 zeroes after it, but it’s just a number beginning with 2 that has a magnitude of roughly 10^10. If you convert it to the integer value 20 000 000 000, you’ve just invented values for those trailing digits - those digits weren’t necessarily zero, we just don’t know what those digits are. Someone who’s an expert on floating-point might need to correct me here, but I think this is correct to some extent. What I’m saying is that float->integer conversion is inherently imprecise. For int to float conversion: * Values beyond 2^53 or below -2^53 cannot be represented as floats without a loss of precision Some strongly-typed languages allow these conversions implicitly, but I’m not sure that’s a good thing or something we should want to copy. Loss of precision isn’t good. If you ask for strict typing, you probably want to avoid it, and should get strict typing. > And being able to pass a float(1.5) to int and lose the 0.5 value > doesn't make sense as well, because data will get lost. Neither of > those feels somehow "predictable" and "natural”. Sure, but it is our existing behaviour. > Also, after a little bit of thinking, if someone needs to do a type > conversion while calling a method, writing foo((int) $bar) isn't that > hard. This isn’t a good idea. Explicit casts do not care for what value you give them, they will convert whether or not the conversion makes sense. Unfortunately we don’t have safe casting functions because they were rejected. Alas. > So, I think it would be best to choose just one of these two > approaches and either loosen it a little or make it more strict (so > data loss doesn't happen). But I guess this approach would be > inconsistent with how the built-in PHP functions work? While it never went to a vote, the Scalar Type Hinting with Casts RFC, which proposed stricter weak casts, was not well-received. The Safe Casting Functions RFC was rejected when it went to a vote. > PS: Ideally, the data loss rules should be made for types and not > values (like the old scalar type hints RFC had), so you don't get > unpredictable results. The Scalar Type Hinting with Casts RFC didn’t do that, it was also based on values. In a dynamically-typed language like PHP, I don’t see why it needs to be type-based rather than value-based. 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 results for default ctors RFC
On 25 January 2015 at 11:26, Peter Cowburn wrote: > That's what the mailing list threads are for, right? If someone has already said a reason on the list for why an RFC should be voted no, when someone else agrees with that reason it's not common for them to email, as it could be viewed as generating noise. Also having all the reasons why an RFC was declined in one place would make it easier to revisit RFCs in the future. It would allow people to see if RFCs were declined because people thought they were just a bad idea, or if there was a problem with a small detail of the RFC, without having to wade through email archives. However I think there is a strong risk of people having to give a reason why they voted no being abused, particularly if it is shown while the voting was taking place, as people could be harassed for choosing an 'invalid' reason to reject the RFC. cheers Dan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] Re: Broken apps
On 25/01/15 13:52, Matteo Beccati wrote: > Not yet. For now, use --without-pear. Just for the record ... There have been various comments about PEAR's future. There is a substantial base of code using it. However the versions downloaded direct may not actually be usable currently so some plan to make that code base usable again probably needs to be on the PHP7 todo list? I will cross check the PEAR modules I am currently using when I get that far since they have already been made e_strict clean. -- 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] Re: [PHP-CVS] Re: Broken apps
On Sun, Jan 25, 2015 at 1:51 PM, Lester Caine wrote: > On 19/01/15 15:17, Xinchen Hui wrote: > > actually, it still fails with: > > > > Fatal error: Call to undefined function set_magic_quotes_runtime() in > > > phar:///home/huixinchen/opensource/trunk/pear/install-pear-nozlib.phar/PEAR/Config.php > > on line 1026 > > make[1]: *** [install-pear-installer] Error 255 > > make: *** [install-pear] Error 2 > > Anything been done about this? > > I'm getting it as Fatal error: Call to undefined function > set_magic_quotes_runtime() in > > phar:///srv/repo/php-src_master/pear/install-pear-nozlib.phar/PEAR/DependencyDB.php > on line 581 > > Starting from a clean checkout from github - git.php.net would not let > me clone - now have a local copy running on mecurial > > Have got as far as > ./configure --enable-fpm --prefix=/opt/php7 --enable-shared=yes > --enable-static=no > > Trying to build php7 php-fpm to go with nginx ... to mirror the php5 setup. > I've just updated configure.in to disable PEAR by default. You'll have to run ./buildconf for this to take effect. Alternatively you can ./config.nice --without-pear. Nikita
Re: [PHP-DEV] Re: [PHP-CVS] Re: Broken apps
On 25/01/2015 13:51, Lester Caine wrote: On 19/01/15 15:17, Xinchen Hui wrote: actually, it still fails with: Fatal error: Call to undefined function set_magic_quotes_runtime() in phar:///home/huixinchen/opensource/trunk/pear/install-pear-nozlib.phar/PEAR/Config.php on line 1026 make[1]: *** [install-pear-installer] Error 255 make: *** [install-pear] Error 2 Anything been done about this? I'm getting it as Fatal error: Call to undefined function set_magic_quotes_runtime() in phar:///srv/repo/php-src_master/pear/install-pear-nozlib.phar/PEAR/DependencyDB.php on line 581 Not yet. For now, use --without-pear. 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] Re: [PHP-CVS] Re: Broken apps
On 19/01/15 15:17, Xinchen Hui wrote: > actually, it still fails with: > > Fatal error: Call to undefined function set_magic_quotes_runtime() in > phar:///home/huixinchen/opensource/trunk/pear/install-pear-nozlib.phar/PEAR/Config.php > on line 1026 > make[1]: *** [install-pear-installer] Error 255 > make: *** [install-pear] Error 2 Anything been done about this? I'm getting it as Fatal error: Call to undefined function set_magic_quotes_runtime() in phar:///srv/repo/php-src_master/pear/install-pear-nozlib.phar/PEAR/DependencyDB.php on line 581 Starting from a clean checkout from github - git.php.net would not let me clone - now have a local copy running on mecurial Have got as far as ./configure --enable-fpm --prefix=/opt/php7 --enable-shared=yes --enable-static=no Trying to build php7 php-fpm to go with nginx ... to mirror the php5 setup. -- 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 results for default ctors RFC
On 25 January 2015 at 08:07, Stanislav Malyshev wrote: > I am a bit disappointed by the result, as I think it would be a good > change, but I am much more disappointed by the fact that that 20 people > voted against it and not even half of them - I would say maybe 1/5 of > them - chose to participate in discussion even minimally and explain > what is wrong with it in their opinion. I understand when everybody > agrees there's no need of the flood of +1s, vote is enough, but > disagreement by its nature is more diverse. I think not bothering to > discuss and then just voting "no" with no explanation is not how the > healthy RFC process should be working. > My points were already covered I believe. In hindsight I should have added a "me too". I think that "might refactor one day" is a pretty flimsy excuse for a feature, and if you're going to refactor, that constructor will probably need some parameters passing anyway, so you still have to do the work. I'm in the camp that thinks if you call a method that doesn't exist, you've done something wrong (I particularly hate __call too). Leigh. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Vote results for default ctors RFC
On 25 January 2015 at 10:52, Paul Dragoonis wrote: > Hi Stas, > > Maybe a cool wiki feature addition is: once people vote they could > optionally leave a comment right there on the wiki, which we could collect > and read. Thoughts? > That's what the mailing list threads are for, right? In the more distant past, we did used to have individuals' comments on ideas in the wiki. If we did want to go down that road again, (almost) everyone who can vote can edit the wiki page to add their own thoughts right now. > > Here's my feedback for you on why i voted No. > > 1) It felt a bit too "magic" for me, with no real gain from an internal or > userland perspective. > > 2) I don't see a flood of people coming to the mailing list complaining > about this feature, so I'm not compelled to want it in the language. > > As always, thanks for your efforts. > > > > On Sun, Jan 25, 2015 at 8:07 AM, Stanislav Malyshev > wrote: > > > Hi! > > > > The vote for RFC https://wiki.php.net/rfc/default_ctor has been > > concluded, with the result of 27 vs. 20. Since 2/3 majority is required > > for acceptance, the RFC has been declined. > > > > I am a bit disappointed by the result, as I think it would be a good > > change, but I am much more disappointed by the fact that that 20 people > > voted against it and not even half of them - I would say maybe 1/5 of > > them - chose to participate in discussion even minimally and explain > > what is wrong with it in their opinion. I understand when everybody > > agrees there's no need of the flood of +1s, vote is enough, but > > disagreement by its nature is more diverse. I think not bothering to > > discuss and then just voting "no" with no explanation is not how the > > healthy RFC process should be working. > > > > -- > > 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 results for default ctors RFC
> I am a bit disappointed by the result, as I think it would be a good > change, but I am much more disappointed by the fact that that 20 people > voted against it and not even half of them - I would say maybe 1/5 of > them - chose to participate in discussion even minimally and explain > what is wrong with it in their opinion. I understand when everybody > agrees there's no need of the flood of +1s, vote is enough, but > disagreement by its nature is more diverse. It was a fairly simple proposed change with a well-defined set of impacted change; what diversity of disagreement do you expect? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Vote results for default ctors RFC
Hi Stas, Maybe a cool wiki feature addition is: once people vote they could optionally leave a comment right there on the wiki, which we could collect and read. Thoughts? Here's my feedback for you on why i voted No. 1) It felt a bit too "magic" for me, with no real gain from an internal or userland perspective. 2) I don't see a flood of people coming to the mailing list complaining about this feature, so I'm not compelled to want it in the language. As always, thanks for your efforts. On Sun, Jan 25, 2015 at 8:07 AM, Stanislav Malyshev wrote: > Hi! > > The vote for RFC https://wiki.php.net/rfc/default_ctor has been > concluded, with the result of 27 vs. 20. Since 2/3 majority is required > for acceptance, the RFC has been declined. > > I am a bit disappointed by the result, as I think it would be a good > change, but I am much more disappointed by the fact that that 20 people > voted against it and not even half of them - I would say maybe 1/5 of > them - chose to participate in discussion even minimally and explain > what is wrong with it in their opinion. I understand when everybody > agrees there's no need of the flood of +1s, vote is enough, but > disagreement by its nature is more diverse. I think not bothering to > discuss and then just voting "no" with no explanation is not how the > healthy RFC process should be working. > > -- > 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 results for default ctors RFC
On 25/01/15 08:07, Stanislav Malyshev wrote: > I think not bothering to > discuss and then just voting "no" with no explanation is not how the > healthy RFC process should be working. One thought I had was 'Why would I be adding a constructor is the parent did not require one?' Personally I would prefer - like with other strict element - that if I am overriding something which does not currently exist I get a warning. If the base library 'improves' things by adding one then I also need to know, so silently hiding it just seems wrong! The bug in my 'update from 5.2 crib sheet is NOT adding the constructor to the parent, and that is my starting point even if it's just an empty shell. As other e_strict additions often turn out. -- 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 results for default ctors RFC
Hi all, On Sun, Jan 25, 2015 at 5:21 PM, Matteo Beccati wrote: > On 25/01/2015 09:07, Stanislav Malyshev wrote: > >> I am a bit disappointed by the result, as I think it would be a good >> change, but I am much more disappointed by the fact that that 20 people >> voted against it and not even half of them - I would say maybe 1/5 of >> them - chose to participate in discussion even minimally and explain >> what is wrong with it in their opinion. I understand when everybody >> agrees there's no need of the flood of +1s, vote is enough, but >> disagreement by its nature is more diverse. I think not bothering to >> discuss and then just voting "no" with no explanation is not how the >> healthy RFC process should be working. >> > > I was supposed to send an explanation after voting, but I forgot. Sorry > about that. > > I initially was going to vote "yes" as I kind of liked the concept. What > made me change my mind was the implementation decision. I fully understand > the reasons behind a conservative approach, but I just didn't like the > "magic" (doesn't exist, but it's ok to call it). I would have voted yes for > the approach #1 as it looked more consistent, and #2 seemed to be slightly > worse than what we have now. I liked the idea. PHP is dynamic language and user should be able to enjoy the "magic", IMHO. I also would like to know the reason why vote against a RFC. Without feedback, there is no improvement. Comment plugin to the wiki, perhaps? Regards, -- Yasuo Ohgaki yohg...@ohgaki.net
Re: [PHP-DEV] [RFC] Skipping parameters take 2
Hi!
> class Baz extends Bar {
> function foo($a=default, $b=default) {
> // do something
> parent::foo($a, $b);
> }
> }
I tried to implement this, however there's a major issue that I do not
know how to overcome. The issue is that when we compile method foo() we
do not know the default values. These values are stored in RECV_INIT
opcodes directly, so when we find out what the actual values are - i.e.
when we resolve inheritance for class Baz - it may be in runtime, so
we'd have to update opcodes for RECV_INIT in foo() in runtime. Which is
not going to sit well with opcode cache, which assumes opcodes do not
change.
I'm not sure yet how to solve this - since the values are only stored in
the opcodes it is not easy to locate them in runtime, so even if we make
'default' zvals some special type we'd still have a problem finding the
right value since the binding happens in runtime and we don't have now
any place to store the result of that binding.
I'll think a bit more about it, in the meantime any ideas about how to
resolve this problem are welcome.
--
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] Scalar Type Hints
On Sun, Jan 25, 2015 at 5:02 AM, Andrea Faulds wrote: > Hi everyone, > > Just a few small updates. > > I’ve made a small change to this RFC. Instead of the strict mode syntax being > declare(strict_typehints=TRUE), it’s now declare(strict_types=1) instead. > This makes it a bit quicker to type - important given you’d need to type it a > lot - without sacrificing much readability. It also avoids using the words > “type hint”, which I understand are contentious to some people. > > The patch now includes a more extensive set of tests: > https://github.com/TazeTSchnitzel/php-src/tree/scalar_type_hints_2_strict_mode/Zend/tests/typehints/ > > The pull request is also now green on Travis (aside from two failures on the > debug build - but they also fail in master). > > Levi’s Return Types RFC has now passed, so now the RFC needs to cover that. > The RFC currently doesn’t discuss return types, save for a paragraph in the > Future Scope section. When the return types patch is merged, I’ll update the > scalars patch, and then update the RFC. A point of contention here is whether > or not return types should always be strict, or whether they should also obey > the strict/weak modes. I’m not entirely sure on that one, that specific item > may end up going to a vote. That said, I do lean towards always strict, given > you can usually ensure your return type’s correct. > > Thanks. > > -- > Andrea Faulds > http://ajf.me/ > Hello, personally I still don't like this RFC in it's current form and "shorter" declare won't change it. I was thinking a lot about the typehints in PHP for last few days and I think having only one way would be the best - and it's somewhere between the curent weak and strict typing. My main "issue" is that the current weak typing is too loose and the strict typing is too strict. The problem with the current strict typing is that you cannot pass "int" to a "float" parameter, even though there can be a totally lossless conversion and it works in other strongly typed languages. And being able to pass a float(1.5) to int and lose the 0.5 value doesn't make sense as well, because data will get lost. Neither of those feels somehow "predictable" and "natural". Also, after a little bit of thinking, if someone needs to do a type conversion while calling a method, writing foo((int) $bar) isn't that hard. So, I think it would be best to choose just one of these two approaches and either loosen it a little or make it more strict (so data loss doesn't happen). But I guess this approach would be inconsistent with how the built-in PHP functions work? PS: Ideally, the data loss rules should be made for types and not values (like the old scalar type hints RFC had), so you don't get unpredictable results. The only ones I can think of right now are basically int -> bool, int -> float, object (w/ __toString) -> string, int -> string, float -> string? Regards Pavel Kouril -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Vote results for default ctors RFC
Hi Stas, On 25/01/2015 09:07, Stanislav Malyshev wrote: I am a bit disappointed by the result, as I think it would be a good change, but I am much more disappointed by the fact that that 20 people voted against it and not even half of them - I would say maybe 1/5 of them - chose to participate in discussion even minimally and explain what is wrong with it in their opinion. I understand when everybody agrees there's no need of the flood of +1s, vote is enough, but disagreement by its nature is more diverse. I think not bothering to discuss and then just voting "no" with no explanation is not how the healthy RFC process should be working. I was supposed to send an explanation after voting, but I forgot. Sorry about that. I initially was going to vote "yes" as I kind of liked the concept. What made me change my mind was the implementation decision. I fully understand the reasons behind a conservative approach, but I just didn't like the "magic" (doesn't exist, but it's ok to call it). I would have voted yes for the approach #1 as it looked more consistent, and #2 seemed to be slightly worse than what we have now. My 2c. 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
[PHP-DEV] [RFC] Vote results for default ctors RFC
Hi! The vote for RFC https://wiki.php.net/rfc/default_ctor has been concluded, with the result of 27 vs. 20. Since 2/3 majority is required for acceptance, the RFC has been declined. I am a bit disappointed by the result, as I think it would be a good change, but I am much more disappointed by the fact that that 20 people voted against it and not even half of them - I would say maybe 1/5 of them - chose to participate in discussion even minimally and explain what is wrong with it in their opinion. I understand when everybody agrees there's no need of the flood of +1s, vote is enough, but disagreement by its nature is more diverse. I think not bothering to discuss and then just voting "no" with no explanation is not how the healthy RFC process should be working. -- Stas Malyshev smalys...@gmail.com -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
