Re: [PHP-DEV] Re: [PHP-CVS] com php-src: fixes to date: ext/date/lib/timelib.c ext/date/lib/timelib.h ext/date/php_date.c ext/date/php_date.h
On Fri, 22 Aug 2014, Anatol Belski wrote: On Fri, August 22, 2014 17:17, Derick Rethans wrote: On Fri, 22 Aug 2014, Anatol Belski wrote: On Fri, August 22, 2014 14:54, Derick Rethans wrote: Yeah, those datatypes should already be there. What needs fixing to make it work? I think now that it's unavoidable to create an arch dependent portable type as timelib_sll is always 64 bit. Please take a look https://gist.github.com/weltling/e2c295a1c2efed62890e . The only difference here would be that it would always return timelib_sll even on 32 bit build (however within 32 bit range). If not that, it'd be probably ok. But IMHO not clean. Probably it would be better to pull the #ifdef's into the timelib.h header to define things like TIMELIB_SLL_MAX and so on, and also to define a portable type, then several places in timelib could be moved to portable types. I you don't mind, i'd rather go this way. Right, but timelib_ssl is supposed to be that portable 64bit int type. Exactly, it's 64 bit, that's why the patch in the gist would cause compiler warning when timelib_date_to_int() used in 32 bit PHP. But we need a type which would go with PHP types bitness, probably timelib_int or alike. Or how would you see the solution, always 64 bit? Yes, it should always go 64bit into PHP. cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug Posted with an email client that doesn't mangle email: alpine -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: Fwd: date extension broken tests
Hey, not sure if my mail made it over the weekend... connectivity was not great. On Mon, 25 Aug 2014, Dmitry Stogov wrote: Could you please take a look into these tests failures. I actually, think that the new behavior is right. Calls to parent::__constructor() shouldn't change value of already constructed $this. I agree, but I think the Horde people had issues with this.. but I can't find that communication with Jan Schneider now. I've cc-ed him as perhaps he remembers. cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug Posted with an email client that doesn't mangle email: alpine -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [VOTE] Abstract Syntax Tree
On Tue, Aug 26, 2014 at 1:58 AM, Andrea Faulds a...@ajf.me wrote:
On 26 Aug 2014, at 00:53, Benjamin Eberlei kont...@beberlei.de wrote:
Depends, registering for shutdown handlers and catching fatals is a
pretty
common thing. If EngineException does not get caught, it should produce
an
E_FATAL again with the correct error code.
Exceptions already do this, do they not? I don’t see why those exceptions
would be any different.
people have code out there like this:
try {
//something stupid
} catch (Exception $e) {
//do nothing or maybe log it
}
if we turn fatal errors into Exceptions extending the base Exception class,
these Pokémon constructs (Gotta Catch 'Em All) will will swallow those
errors and contrinue the execution, maybe causing more dangerous
results(data corruption, etc.) than a simple fatal error could.
But these issues was discussed before, so I'm fairly sure that Nikita is
aware of those concerns, and let's just wait for him to update his proposal
and we can discuss it after it's ready.
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Re: [PHP-DEV] 5.4 security only
Hi Stas On 19 August 2014 00:59, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! Moving this out of other topics into its own: according to the release RFC, we should have 5.4 have 2 years of bugfixes one year of security fixes. Since 5.4 was released in March 2012, we're already past 2 year mark. However, we're still have some bugfixes in 5.4, so I'd like to do this: - 5.4.32 is released as planned this week, nothing changes there. - 5.4 branch that is to be 5.4.33 will be the last release that has any non-security bugfixes. We hope that by the time 5.4.33 is out 5.6.0 is out too, so that would play nice with the two stable branches, one security branch theme. Starting from that release forward, 5.4 would be purely security fixes only branch. - EFFECTIVE IMMEDIATELY, we do not accept new non-security bugfixes into 5.4 branch unless they are very important ones (and that is only because people may, in theory, have pending patches and we didn't give advance notice). Importance would have to be determined somewhat arbitrarily, but basically if it works without it, then it's not in, if there's serious doubt if it should be in, it's not in, etc. Security issues, of course, still allowed in. This means if somebody has some pending non-security fixes that have to be in 5.4, the following two weeks are the last call, provided that the fixes really must be in 5.4. Any objections/suggested modifications to this plan? A bug has been discovered in SSL-enabled streams, ideally the fix would go into 5.4. While the bug touches OpenSSL, it's not a security fix in the strictest sense, however it is known to cause problems with non-blocking SSL/TLS-enabled streams in the real world (it's also theoretically possible, though unlikely, for this to cause issues with blocking streams). I have created a trivial patch to fix the bug [1], an explanation of the nature of the bug and how the fix resolves the problem can be seen in the commit message and comments in the code. The patch contains no tests, as it's not possible to reproduce the bug in a reliable manner due to a dependency on external factors for the bug to appear - things such as the OS packet scheduler, network latency, MTU may all affect whether the buggy behaviour occurs. Does anyone have any objections to this being included in 5.4? Thanks, Chris [1] https://github.com/DaveRandom/php-src/commit/d4da5d8c1dae152f7aa5f0dd09b1f29b51f48c89 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] 1948 Piscinas espectaculares
--- Este mensaje no contiene virus ni malware porque la protección de avast! Antivirus está activa. http://www.avast.com
Re: [PHP-DEV] 5.4 security only
Hi! Does anyone have any objections to this being included in 5.4? Thanks, Chris [1] https://github.com/DaveRandom/php-src/commit/d4da5d8c1dae152f7aa5f0dd09b1f29b51f48c89 I think it's ok for 5.4. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Remove generated lexers from git?
Hi internals! Currently our git repo contains files like zend_language_scanner.c, zend_ini_scanner.c, etc which are files generated by re2c. Historically these files have been included because re2c was not readily available on many platforms. In the thread on bison 3 compatibility [1] there was some discussion as to whether this limitation still applies. Quoting Adam Harvey: +1. I don't think re2c is that onerous a requirement anyway, for the most part: it's available through apt-get, brew, yum, and probably most other packaging systems. Given the amount of other things a developer has to install to build php-src from git, re2c is hardly going to break the camel's back. So, I'd like to bring this up again. Are there any objections to removing generated lexer files from the repo? If not, does it suffice to just git rm them and add them to .gitignore, or are other changes required? Nikita [1]: http://markmail.org/message/x3p7ltekzws6ywhw
Re: [PHP-DEV] Remove generated lexers from git?
On 26 Aug 2014, at 20:55, Nikita Popov nikita@gmail.com wrote: Currently our git repo contains files like zend_language_scanner.c, zend_ini_scanner.c, etc which are files generated by re2c. Historically these files have been included because re2c was not readily available on many platforms. In the thread on bison 3 compatibility [1] there was some discussion as to whether this limitation still applies. On a similar theme, could we also get rid of the generated Zend VM, and wire up zend_vm_gen.php to make like we wire up bison and re2c? That would make PHP a dependency to build PHP, but it would hardly be the first language which is reliant on itself to be built. Are there any distributions out there in which PHP is not available? Bear in mind that for non-developers, we would still include a generated VM in the source packages so most people wishing to compile PHP don’t need it, this would only affect people using git. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Remove generated lexers from git?
Hi! On a similar theme, could we also get rid of the generated Zend VM, and wire up zend_vm_gen.php to make like we wire up bison and re2c? That would make building PHP for non-internals person harder and the list of dependencies they need to get right longer. While providing zero added value. And yes, there are a lot of non-internals persons building PHP. Sometimes they may even use git. That would make PHP a dependency to build PHP, but it would hardly be the first language which is reliant on itself to be built. Are there It would not be the first, but why do it? It works just fine right now, why break it? any distributions out there in which PHP is not available? There are systems that aren't Linux and don't have PHP as standard package, yes. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] 5.4 security only
On 26 August 2014 18:31, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! Does anyone have any objections to this being included in 5.4? Thanks, Chris [1] https://github.com/DaveRandom/php-src/commit/d4da5d8c1dae152f7aa5f0dd09b1f29b51f48c89 I think it's ok for 5.4. Great, thanks :-) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Remove generated lexers from git?
On Tue, Aug 26, 2014 at 10:01 PM, Andrea Faulds a...@ajf.me wrote: On 26 Aug 2014, at 20:55, Nikita Popov nikita@gmail.com wrote: Currently our git repo contains files like zend_language_scanner.c, zend_ini_scanner.c, etc which are files generated by re2c. Historically these files have been included because re2c was not readily available on many platforms. In the thread on bison 3 compatibility [1] there was some discussion as to whether this limitation still applies. On a similar theme, could we also get rid of the generated Zend VM, and wire up zend_vm_gen.php to make like we wire up bison and re2c? That would make PHP a dependency to build PHP, but it would hardly be the first language which is reliant on itself to be built. Are there any distributions out there in which PHP is not available? Bear in mind that for non-developers, we would still include a generated VM in the source packages so most people wishing to compile PHP don’t need it, this would only affect people using git. -1 on removing zend_vm_execute.h. Having to install php before I can build php would be very inconvenient. Nikita
[PHP-DEV] VCS access
Hi all I would like to request VCS access to php-src. I would like to be able to merge my own patches when (and only when) it is agreed they should be merged :-) Existing contributions: https://github.com/php/php-src/commits?author=DaveRandom https://github.com/php/php-src/pulls/DaveRandom https://github.com/salathe/phpdoc-en/commits?author=DaveRandom Thanks, Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Remove generated VM from git?
Hi! Spinning this discussion (removing generated VM from git) off into its own thread. On 26 Aug 2014, at 21:12, Nikita Popov nikita@gmail.com wrote: -1 on removing zend_vm_execute.h. Having to install php before I can build php would be very inconvenient. I’d point out PHP already requires extra dependencies (and your proposal adds one further) before building PHP from git. I also doubt it would cause inconvenience to developers, as if you’re developing PHP you need a stable PHP install anyway. You wouldn’t need PHP to build PHP for most cases, only if you’re building it from git. On 26 Aug 2014, at 21:08, Stas Malyshev smalys...@sugarcrm.com wrote: That would make building PHP for non-internals person harder and the list of dependencies they need to get right longer. While providing zero added value. And yes, there are a lot of non-internals persons building PHP. Sometimes they may even use git. Why would a non-internals person want to build PHP from git? That’s just making things harder on themselves. Besides PHP itself (should my proposal succeed), you need other extra dependencies, including a lexer generator if Nikita’s proposal succeeds. That would make PHP a dependency to build PHP, but it would hardly be the first language which is reliant on itself to be built. Are there It would not be the first, but why do it? It works just fine right now, why break it? The advantages are twofold: 1. We avoid git tracking generated files that don’t provide meaningful diffs and that can have massive changes just from changing the source code or the generation script. 2. It’s no longer necessary to manually generate the VM every time an opcode is modified. (Less debugging pain if you forget.) any distributions out there in which PHP is not available? There are systems that aren't Linux and don't have PHP as standard package, yes. OK, that’s true. But on such systems the release package would still build. -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Remove generated VM from git?
Hi! Why would a non-internals person want to build PHP from git? That’s Why not? It's an open-source project, isn't it? People may prefer using git, many integration systems (including PHP's own composer) rely on git. just making things harder on themselves. Besides PHP itself (should my proposal succeed), you need other extra dependencies, including a lexer generator if Nikita’s proposal succeeds. It's like since we depend on gcc, adding more dependencies is no problem. Doesn't make any sense to me, adding dependencies makes it harder, so it is more problems. Especially with recursive dependencies. 1. We avoid git tracking generated files that don’t provide meaningful diffs and that can have massive changes just from changing the source code or the generation script. 2. It’s no longer necessary to manually generate the VM every time an opcode is modified. (Less debugging pain if you forget.) That's not an advantage. Having extra file in git is no problem at all, we don't pay per byte, and somebody who can't handle regenerating the VM file should not be messing with the VM (for one, they would notice the problem immediately on running the test for the change locally, and if they don't test the changes locally we probably don't want these changes). And it's not like we change the VM every day. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] VCS access
On Tue, Aug 26, 2014 at 10:25 PM, Chris Wright daveran...@php.net wrote: Hi all I would like to request VCS access to php-src. I would like to be able to merge my own patches when (and only when) it is agreed they should be merged :-) Existing contributions: https://github.com/php/php-src/commits?author=DaveRandom https://github.com/php/php-src/pulls/DaveRandom https://github.com/salathe/phpdoc-en/commits?author=DaveRandom Thanks, Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Hi Chris, I've granted you with php-src karma, it can take a coupe of minutes until it is propagated, but you should be able to push php-src.git soon. Please check out our git docs in the wiki: https://wiki.php.net/vcs/gitfaq https://wiki.php.net/vcs/gitworkflow The only special thing is our touch NEWS merge driver, don't forget to set that properly. -- Ferenc Kovács @Tyr43l - http://tyrael.hu
Re: [PHP-DEV] VCS access
On 27 August 2014 00:05, Ferenc Kovacs tyr...@gmail.com wrote: On Tue, Aug 26, 2014 at 10:25 PM, Chris Wright daveran...@php.net wrote: Hi all I would like to request VCS access to php-src. I would like to be able to merge my own patches when (and only when) it is agreed they should be merged :-) Existing contributions: https://github.com/php/php-src/commits?author=DaveRandom https://github.com/php/php-src/pulls/DaveRandom https://github.com/salathe/phpdoc-en/commits?author=DaveRandom Thanks, Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Hi Chris, I've granted you with php-src karma, it can take a coupe of minutes until it is propagated, but you should be able to push php-src.git soon. Please check out our git docs in the wiki: https://wiki.php.net/vcs/gitfaq https://wiki.php.net/vcs/gitworkflow Great, thanks very much :-) The only special thing is our touch NEWS merge driver, don't forget to set that properly. I won't be pushing anything until I've done a couple of practice merges locally -- Ferenc Kovács @Tyr43l - http://tyrael.hu -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Remove generated VM from git?
On 26 Aug 2014, at 22:17, Stas Malyshev smalys...@sugarcrm.com wrote: That's not an advantage. Having extra file in git is no problem at all, we don't pay per byte, and somebody who can't handle regenerating the VM file should not be messing with the VM (for one, they would notice the problem immediately on running the test for the change locally, and if they don't test the changes locally we probably don't want these changes). And it's not like we change the VM every day. Actually, I wouldn’t be so bothered by this if I didn’t have to manually regenerate the VM. Would it be possible to make `make` track Zend/zend_vm_def.h? -- 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] Closure::apply() (re-opening)
On 20 Aug 2014, at 13:50, Andrea Faulds a...@ajf.me wrote: I’m putting this RFC to a vote again as I haven’t heard any objections in the past three days, and in the event something’s been missed, one week would be long enough to spot it. Vote is here: https://wiki.php.net/rfc/closure_apply#vote It ends 2014-08-27. Thanks! Voting has ended. With 13 votes in favour and none against, the RFC is accepted. Unfortunately, as it affects /Zend, I don’t have the karma to merge this myself. I updated the pull request to work with int64. The pull request can be found here: https://github.com/php/php-src/pull/775 Thanks! -- Andrea Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: zpp and zend_string
Hi internals, With the recent merge of int64 the `zend_string` type now uses `size_t` to store its length, but ZPP (and friends) still use `int *` to store the parsed string lengths. http://lxr.php.net/xref/PHP_TRUNK/Zend/zend_API.c#519 This look like an oversight. Will this be fixed as well? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
