[PHP-DEV] Deprecating GD functions imagettftext/bbox
Morning, I propose deprecating two GD functions: imagettftext and imagettfbbox. The reasons I would like to deprecate them are: 1. Their functionality is a subset of imagefttext and imageftbbox 2. The imagettf* functions have the same requirements as the imageft* functions 3. The imagettf* functions parameters are compatible with the imageft* functions parameters As far as I can tell the original reason for having both functions was because PHP LIBGD is a custom implementation of LIBGD that had additional functionality from the actual LIBGD. While this is still the case it seems that now the required functions (gdImageStringFT and gdImageStringFTEx) exist in both libraries. The only difference between imagettf* and imageft* functions is the imagettf* functions do not provide the optional ‘extrainfo’ parameter The only step to migrate from the imagettf* functions to imageft* functions is to change the function names from ‘imagettf*’ to ‘imageft*' I would like to create a timeline to deprecate and remove the imagettf* functions. Providing a timeline will allow for: 1. Clarity for which PHP functions to use going forward 2. Ability to plan a migration to the new PHP functions 3. Clarity for which PHP functions to improve in php-src 4. Ability to clean up some of the GD code in php-src I will hold off on proposing an actual timeline for now. I can implement any coding changes needed. Please let me know the general thoughts to deprecating these functions. If the reception is positive I would like to create an RFC to discuss this in full and come up with a timeline. ––– Hakuna Matata! Lonny Kapelushnik https://www.lonnylot.com 732.685.9175
[PHP-DEV] [RFC] imagettf* deprecation/removal
Morning all, Previously I posted on the list requesting any immediate feedback on this proposal. Given the quick feedback I received I’ve made an RFC for deprecating and removing the imagettftext and imagettfbbox functions: https://wiki.php.net/rfc/imagettf_deprecation All comments welcome! ––– Hakuna Matata! Lonny Kapelushnik https://www.lonnylot.com 1.732.685.9175
[PHP-DEV] Re: Deprecating GD functions imagettftext/bbox
Hi all, I appreciate the immediate feedback in this thread. Given the quick feedback and suggestions I received I wanted to create an RFC to be able to collect everything and move forward. I’ve written it out and properly announced it here. Lets continue the discussion over there.
Re: [PHP-DEV] [RFC] imagettf* deprecation/removal
>> Wouldn’t it be simpler to just make them aliases? > > Indeed, and as I have no problem if Lonny likes to go ahead with this > RFC, I do not think we need one for such trivial change. Andrea, Whom are you suggesting the alias would be simpler for? Personally, I do not think it would be simpler for the userland API to have them aliased. I think an alias will cause unneeded confusion, discussions, and waste time in an office. Pierre, The idea behind making this an RFC is to come to an agreement on both the change and the timeline now so there are little/no questions later. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] imagettf* deprecation/removal
On Jul 27, 2014, at 1:19 PM, Pierre Joye wrote: > > However the idea to add yet other warnings/notices to ext/gd is not > something I like to see in GD. I will rather remove many for php-next > instead of adding more. Also some new font APIs may as well make the > whole ttf ones less relevant, see the upstream version. Pierre, I would only want to add E_DEPRECATED to the function calls if we are actually going to remove them. Otherwise, I agree that we should not add it. Also, I noted it in the RFC, but want to make mention here in case you did not see: I’m suggesting E_DEPRECATED in 5.6.z+1 and removal in php.next. On Jul 27, 2014, at 1:22 PM, Andrea Faulds wrote: > The API signatures are compatible, yes? In which case, just make the legacy > functions be aliases of the new ones. This avoids breaking everyone’s code. Andrea, I don’t think that assessment accurately reflects the situation. I’m suggesting to change the userland API in php.next. According to the release process the whole point of a php.next is to break the API for improvements. Anyone upgrading to php.next is going to have to check for BC breaks. I’m suggesting having this minor change be one of the BC breaks in php.next. I’m not making the argument that it is important from a purely technical POV; I don’t believe it is. I’m making the argument that it is important from an operational POV. Removing them prevents newcomers and gurus from ever having any question about which function to use.
[PHP-DEV] DateTimeZone Serialize/Unserialize
Morning! I was creating a patch to allow serialize/unserialize of the DateTimeZone object. When running `make test` I found that we already have a test for the serialize/unserialize of DateTimeZone. The test checks that we are _not_ able to serialize/unserialize the DateTimeZone object: https://github.com/php/php-src/blob/PHP-5.4/ext/date/tests/DateTimeZone_serialize.phpt Is the test correct or do we want to be able to serialize/unserialize DateTimeZone? If the test is correct, why do we not want to be able to serialize/unserialize DateTimeZone objects? Thank you! -- Lonny Kapelushnik http://lonnylot.com (732) 807-5509
Re: [PHP-DEV] BUG 55240 - wrong date creation
In the date() function the formats are split up. In date() G is w/o leading zeros and H is w/ leading zeros. Why were these (as well as many others) combined and turned into an either/or for DateTime::createFromFormat? On Wed, Aug 3, 2011 at 4:10 PM, Derick Rethans wrote: > On Wed, 3 Aug 2011, Nicolai Scheer wrote: > > > On 03.08.2011 21:29, Joey Smith wrote: > > >> 2011/8/4 Nicolai Scheer : > > >>> Hi! > > >>> > > >>> Did anyone had the time to review bug 55240 > > >>> (https://bugs.php.net/bug.php?id=55240), yet? > > >>> > > > > > > It definitely appears to be unexpected behaviour - the 'G' format for > > > hours is "24-hour format without leading zeroes" - so the expectation > > > would be that 'Gi' parses '800' as '8 hours and 0 minutes'. (Also, I > > > thought I would point out here that the comments on 'G' and 'H', in > > > timelib_parse_from_format are backwards here - same with 'g' and 'h'.) > > > > Unfortunately, there's nothing I could do about the strings to be parsed > > (in terms of customer agreement...). > > > > "24-hour format without leading zeroes" is exactly what I had expected > > from the 'G' format as well. "24-hour" somehow implies "not greater than > > 24". On the other hand "overflow" handling might be expected (and even a > > good thing to do?). > > > > Let's see what others are about to comment on the issue... > > Personally I'd vote for "fixing" this by limiting the parsed value. > > Another possibility would be to introduce a new format without the > > "overflow handling"... > > Yes, this needs fixing. I am not sure how easy this is though... > I've assigned the bug to myself. > > cheers, > Derick > > -- > http://derickrethans.nl | http://xdebug.org > Like Xdebug? Consider a donation: http://xdebug.org/donate.php > twitter: @derickr and @xdebug > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
Re: [PHP-DEV] 5.4 beta & tests
> > Test strtolower() function [ext/standard/tests/strings/strtolower.phpt] > Test strtoupper() function [ext/standard/tests/strings/strtoupper1.phpt] > > I believe these fail on OSX because we test for undefined ASCII behavior. We call strtolower/strtoupper for all 256 ASCII characters, but ASCII is only defined for 128. The failure in these tests on OSX is above 128, which I do not think we should be testing for. I created a bug for the tests and added a patch to remove testing above 128 chars: https://bugs.php.net/bug.php?id=55546
[PHP-DEV] [PATCH] Feature 55218 - SimpleXML namespaces
Currently, if you recursively call getDocNamespaces on any SimpleXML node it retrieves ALL the namespaces for the entire document, regardless of what node you call it on. This patch adds a second bool argument called `from_root` that allows you to specify if you want all the namespaces from the root (default for BC) or only the namespaces from and below the node you call it on. I submitted this patch a while ago and haven't heard anything. I was recently contacted by someone asking if this feature was released b/c they needed this functionality. I've updated the patch against PHP-5.4 on github (https://github.com/php/php-src/pull/112). Is there some procedure I am missing for getting this committed? Is there some place I should be going for this discussion? I couldn't find an IRC channel that was helpful w/ core php development. Thank you, -- Lonny Kapelushnik http://lonnylot.com (732) 807-5509
[PHP-DEV] Re: [PATCH] Feature 55218 - SimpleXML namespaces
Can someone please let me know if I'm doing something wrong in trying to get this committed? Am I doing something procedurally wrong or is it normal for nobody to respond? Thank you On Thu, Jun 28, 2012 at 11:39 AM, Lonny Kapelushnik wrote: > Currently, if you recursively call getDocNamespaces on any SimpleXML node > it retrieves ALL the namespaces for the entire document, regardless of what > node you call it on. This patch adds a second bool argument called > `from_root` that allows you to specify if you want all the namespaces from > the root (default for BC) or only the namespaces from and below the node > you call it on. > > I submitted this patch a while ago and haven't heard anything. I was > recently contacted by someone asking if this feature was released b/c they > needed this functionality. I've updated the patch against PHP-5.4 on github > (https://github.com/php/php-src/pull/112). > > Is there some procedure I am missing for getting this committed? Is there > some place I should be going for this discussion? I couldn't find an IRC > channel that was helpful w/ core php development. > > Thank you, > > -- > Lonny Kapelushnik > http://lonnylot.com > (732) 807-5509 > -- Lonny Kapelushnik http://lonnylot.com (732) 807-5509
Re: [PHP-DEV] Re: [PATCH] Feature 55218 - SimpleXML namespaces
Hi Stas, Thanks for the response! Usually it helps to talk to extension maintainer (list of them in in > EXTENSIONS file). > In the original message of this thread I CCed the extension maintainer listed in EXTENSIONS (per the instructions in the README.SUBMITTING_PATCH) and I did not hear anything back. Previously, when I originally wrote this feature, I sent a private e-mail to the 3 maintainers listed on top of the simplexml.c file and did not hear anything back either (this was on 2011-08-31). > Speaking of the patch, could you explain what is it returning when > recursive is set but from_root is false? > It will only return the namespaces below and including the node you call it on. Say you have an XML doc like https://gist.github.com/3066372 Currently, if you call $x->getDocNamespaces(true) and $x->person[0]->getDocNamespaces(true) you get the same results. This is because the recursive call *always* starts from the root of the document. With the patch, when from_root is false the recursion will start from the node you call getDocNamespaces on. So when calling $x->getDocNamespaces(true, false) and $x->person[0]->getDocNamespaces(true, false) they return results based on the node they were called on. > Besides that, it looks OK but also needs NEWS and UPGRADING > descriptions. Please add those and I think it can be merged. These are now added. Thank you for your help! Please let me know if anything else needs to be changed. Have a great day! -- Lonny Kapelushnik http://lonnylot.com (732) 807-5509
[PHP-DEV] PHP Wiki problem
Hi, I found a problem in the PHP WIki. On IRC it was suggested that I open a bug report (#62611) and email internals. https://wiki.php.net/vcs/gitworkflow has wrong directions for 'Workflow for external contributors'. After `git remote...` you need to call `git fetch upstream` and the rebase needs to be `git pull --rebase upstream PHP-5.4 (or use upstream master)`. Have a great day! -- Lonny Kapelushnik http://lonnylot.com (732) 807-5509
