[PHP-DEV] Re: [PHP-DOC] Re: [PHP-DEV] Moving PHP documentation to Git repository
On Tue, Jun 25, 2013 at 1:05 PM, David Soria Parra d...@php.net wrote: On 2013-06-25, Ferenc Kovacs tyr...@gmail.com wrote: there were some initial discussion and work done on moving the docs to git, see https://wiki.php.net/doc/git http://git.php.net/?p=3Dweb/doc-editor.git;a=3Dshortlog;h=3Drefs/heads/GIT_= READY http://marc.info/?l=3Dphpdocm=3D132321958514090w=3D2 but it seems that we lost momentum, but I think that this isn't a technical problem, just lack of interest (svn and the online editor just works for the regulars), maybe others have different opinions on this. and I'm fairly certain that the slow integration of the patches also not a technical problem as well. I think that it would worth more to figure out and fix the underlying problem which causes the current delay for integrating the incoming patches= . moving to git/github without fixining the underlying issue would only mean that we switched to pull requests not getting accepted in a timely manner(which is unfortunately common with our other git/github repos). generally speaking i am in favor in moving more and more to git. we lost momentum and I am stuck with a new job and RMing. I can help with technical questions but don't hav emuch time implementing it. I'm also in favor of moving to Git. The amount of contributions to the brazilian portuguese translation would be much more significant if we had a streamlined contribution system, which pull requests on Github allow quite easily. What are the current problems of Git migration?
[PHP-DEV] Small performance improvement on main/rfc1867.c
Just submitted a small patch here: https://github.com/php/php-src/pull/34 I had sent this before to gr...@php.net, before the GIT migration. Small fix really. The current code is correct, but if it is used inside a long loop or long strings, it's inefficient.
Re: [PHP-DEV] RFC: Removing PHP tags
Removing PHP's native feature of being able to be easily embedded inside HTML and other markup languages is absolutely retrograde. Of of the biggest points in favor of PHP is that i'm able to easily do this: ul ?php foreach ($stuff as $item): ? li?php echo $item ?/li ?php endforeach; ? /ul Or this: ?xml version=1.0 ? store ?php foreach ($stuff as $item): ? product?php echo $item ?/product ?php endforeach; ? /store Without having to implement any slow-as-hell template language. It works right out of the box. Using MVC as an argument for tag removal is a clear disrespect to the language itself.
Re: [PHP-DEV] RFC: Removing PHP tags
What many people fail to see is that PHP is it's own templating language. It might be ugly for people used to other template languages, but it works perfectly and right out of the box. On Sat, Mar 31, 2012 at 11:24 PM, Klaus Silveira klaussilve...@php.netwrote: Removing PHP's native feature of being able to be easily embedded inside HTML and other markup languages is absolutely retrograde. Of of the biggest points in favor of PHP is that i'm able to easily do this: ul ?php foreach ($stuff as $item): ? li?php echo $item ?/li ?php endforeach; ? /ul Or this: ?xml version=1.0 ? store ?php foreach ($stuff as $item): ? product?php echo $item ?/product ?php endforeach; ? /store Without having to implement any slow-as-hell template language. It works right out of the box. Using MVC as an argument for tag removal is a clear disrespect to the language itself.
[PHP-DEV] Small question about performance
Hello internals,
I've been involved in a discussion at the PHP Standards Group and we
recently had the following statement:
*Say you had a loop, and inside that loop you wanted to modify a param
**update the key:**
**foreach($a as $key = $val) {
** $a[$key] = someLong(functionCalls(hereThat($spanOver85Chars)));
**}**
**If this exceeded the line width, you would have to split things like
**this over a few lines, storing the val temporarily in a zval's until
**you reached your end computation. Therefore allocating more memory
**iteratively. *
I'm curious about this. Can anyone confirm it or a benchmark should be
made?
Re: [PHP-DEV] Apache 2.4 support in PHP 5.4.0?
I agree with Stas on this one. Certainly not critical and needs some review while on the trunk. On Fri, Feb 24, 2012 at 5:57 PM, Stas Malyshev smalys...@sugarcrm.comwrote: Hi! If you're planning to have a PHP 5.4 RC9, should Apache 2.4 support be included? This would reduce any negative user sentiment that PHP 5.4 doesn't even support the latest Apache. Latest Apache is about 3 days old now :) If somebody expects PHP to have release version supporting new major version of Apache within days of the new release I feel his expectations need to be adjusted. I certainly wouldn't expect it. There is a patch attached to https://bugs.php.net/bug.php?**id=61172https://bugs.php.net/bug.php?id=61172 It needs review and wider testing. I don't think it is a critical fix, so it's not for 5.4.0. For 5.4.1 we will consider it, and for trunk it can go in right now if somebody validates it. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Git Migration Status Update
Hey David, I just wanted to thank you for the huge amount of work you have been dedicating towards the PHP community. Amazing! :D
[PHP-DEV] Problems with master.php.net
I have noticed that master.php.net has been offline for a few days now, resulting in a failure to login at the PHP Wiki. Are you guys having this same issue?
Re: [PHP-DEV] SVN Account Request: ionixjunior
You don't need an SVN account to hear about future versions of PHP, just follow the internals mailing list. On Tue, Dec 27, 2011 at 12:08 PM, Ione Souza Junior jun...@ionixjunior.com.br wrote: Being inside all the news yet to come in future versions of PHP, and also participate in polls. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP CLI webserver test failures
I'll try to help Laruence improve the test coverage. If you guys have any suggestion for test starting point, let me know. On Wed, Nov 16, 2011 at 5:41 PM, Christopher Jones christopher.jo...@oracle.com wrote: Hi Laruence, Is there anyway to make the PHP CLI webserver tests more resilient? They are failing on gcov.php.net and are high on the list of user test reports: http://gcov.php.net/viewer.**php?version=PHP_HEADfunc=**testshttp://gcov.php.net/viewer.php?version=PHP_HEADfunc=tests http://qa.php.net/reports/?**version=5.4.0RC2-devhttp://qa.php.net/reports/?version=5.4.0RC2-dev Chris -- Email: christopher.jo...@oracle.com Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SplClassLoader RFC Voting phase
I agree with Guilherme on this one. The voting objective seems very vague currently. On Mon, Nov 7, 2011 at 12:29 PM, guilhermebla...@gmail.com guilhermebla...@gmail.com wrote: I'd rather suggest to split this poll into 3 questions: 1- The same as you wrote. Having it in SPL and in PHP 5.4 2- Have it in PHP 5.4 as an external extension (FIG, PSR or PSG), enabled by default. 3- As an external extension, disabled by default. This would require PHP core to reserve the namespace for us. Cheers, On Mon, Nov 7, 2011 at 11:41 AM, David Coallier dav...@php.net wrote: Hey everyone, After lengthy discussions and various opinion, we believe this issue has been discussed at length and the PSR-0 has had this standard effective for the past 1.5 year. The SplClassLoader RFC has moved to voting stage. Please cast your votes at https://wiki.php.net/rfc/splclassloader/vote Thank you very much for all the interest showed so far, -- David Coallier -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Guilherme Blanco Mobile: +55 (11) 8118-4422 MSN: guilhermebla...@hotmail.com São Paulo - SP/Brazil -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Klaus Silveira (011) 8564-2492 www.klaussilveira.com
Re: [PHP-DEV] CI for 5.4
What are the current obstacles in a possible Jenkins implementation for the PHP codebase? -- Klaus Silveira (011) 8564-2492 www.klaussilveira.com
[PHP-DEV] Moving to Git and possible move to Github
I hate to bring this discussion again, but with the future move to Git, moving to Github would be a nice idea. I wanted to propose a discussion of the pros and cons and possibly create an RFC. Apache is mirroring their GIT to github, not actually using Github. This is also a good thing. -- Klaus Silveira (011) 8564-2492 www.klaussilveira.com
Re: [PHP-DEV] CI for 5.4
Yes, it is. But not only email notifications are possible, other interesting integrations are possible. For example, Jabber. https://wiki.jenkins-ci.org/display/JENKINS/Instant+Messaging+Plugin https://wiki.jenkins-ci.org/display/JENKINS/Jabber+Plugin On Thu, Nov 3, 2011 at 4:43 PM, Stefan Marr p...@stefan-marr.de wrote: Hi Ferenc: On 03 Nov 2011, at 19:01, Ferenc Kovacs wrote: Of course there are ways to improve the current setup, I listed those ideas at https://wiki.php.net/rfc/jenkins#future_plans Very nice. I don't know Jenkins, but would it be possible to mail the author of a change in case it breaks something? I just had such a case, where my local setup was insufficient to catch it. Thanks a lot Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Klaus Silveira (011) 8564-2492 www.klaussilveira.com
Re: [PHP-DEV] CI for 5.4
That's kind of a general setup, Stefan. Sending an email to the commiter that broke the build with details of the build process, as well sending an email to a mailing list. I'll be looking into this Jenkins issue (JENKINS-5931). Maybe having an access control based on IRC operators and voices? On Thu, Nov 3, 2011 at 5:33 PM, Stefan Marr p...@stefan-marr.de wrote: Hi: On 03 Nov 2011, at 20:15, Ferenc Kovacs wrote: The usual setup is that you have a mailing list/alias which always gets a mail about the build results (which can also be customized in detail, when to mail, etc.) and optionally you can notify the person whose commit break the build. If I get a personal notification via mail, if I break something, that kind of guarantees my attention. Using IRC is to distracting, so that is not an option for me. Sorry. If I am the only one who would use it, then don't bother. But if I can simply opt-in for it somewhere, that would be great. Thanks to people like Antony, obviously stupid bugs get caught pretty fast. Thanks Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525 -- Klaus Silveira (011) 8564-2492 www.klaussilveira.com
Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] CI for 5.4
Yes, it's a wonderful setup. Great work, Ferenc! :D This does give a nice motivation to write more tests and increase the code coverage, doesn't it? On Thu, Nov 3, 2011 at 7:22 PM, Felipe Pena felipe...@gmail.com wrote: 2011/11/3 Ferenc Kovacs tyr...@gmail.com: On Thu, Nov 3, 2011 at 8:41 PM, Klaus Silveira cont...@klaussilveira.comwrote: That's kind of a general setup, Stefan. Sending an email to the commiter that broke the build with details of the build process, as well sending an email to a mailing list. I'll be looking into this Jenkins issue (JENKINS-5931). Maybe having an access control based on IRC operators and voices? yeah, using voices would work, but then that would mean that it is only a read only channel for most people, which imo would be a bad move. I mean it would be really nice, if people could drop by to our qa related irc room and start talking about that pesky build failure. another solution would be to set up a custom irc bot, independently from jenkins, which could fetch the build results through the mailing list or rss and send it to the channel. of course extending the jenkins irc bot is also a possibility, the easiest way would be having a configuration option for disabling the whole control stuff, as we don't really need the interactivity there, you can use the web interface for that. -- Ferenc Kovács @Tyr43l - http://tyrael.hu Nice work with this Jenkins stuff! The system seems pretty useful. I like the idea to have a mailing list for build result notification, as well as send mail to the build breaker. -- Regards, Felipe Pena -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Klaus Silveira (011) 8564-2492 www.klaussilveira.com
Re: [PHP-DEV] enable mbstring by default
I agree... in fact, most international developers don't know about this. They expect that PHP supports unicode by default, creating faulty software. Sad but true. On Mon, Oct 17, 2011 at 11:35 AM, Tom Boutell t...@punkave.com wrote: Will PHP really never, ever, ever be unicode by default? It'll always be a weird special case to not be from the shores of the Atlantic? On Thu, Oct 13, 2011 at 5:41 PM, Klaus Silveira cont...@klaussilveira.com wrote: What drawbacks could possibly be brought with mbstring being enabled by default? On Thu, Oct 13, 2011 at 6:11 PM, Mike Robinson m...@rile.ca wrote: On October-11-11 11:46 AM Ferenc Kovacs wrote: As the full unicode support went down with php6, wouldn't it be a logical step to enable the mbstring extension by default(maybe even turning it into a builtin ext like phar)? I think that mbstring is a pretty mature and stable extension, and there isn't much dependencies so I can't think of reason why we couldn't do it. Of course the mbstring.func_overload would still disabled by default (maybe exporting the mb functions to the 'utf8' namespace? :P), so it would be a backward compatible change. What do you think? ps: maybe it is too late for 5.4, but having it in trunk is still better than nothing. The mbstring extension was enabled by default once upon a time, if memory serves, and as I recall the results were extremely painful. While both PHP and mbstring have matured significantly since then, I'm old school that way. Fool me once... Best, Mike Robinson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Klaus Silveira (011) 8564-2492 www.klaussilveira.com -- Tom Boutell P'unk Avenue 215 755 1330 punkave.com window.punkave.com -- Klaus Silveira (011) 8564-2492 www.klaussilveira.com
Re: [PHP-DEV] enable mbstring by default
What drawbacks could possibly be brought with mbstring being enabled by default? On Thu, Oct 13, 2011 at 6:11 PM, Mike Robinson m...@rile.ca wrote: On October-11-11 11:46 AM Ferenc Kovacs wrote: As the full unicode support went down with php6, wouldn't it be a logical step to enable the mbstring extension by default(maybe even turning it into a builtin ext like phar)? I think that mbstring is a pretty mature and stable extension, and there isn't much dependencies so I can't think of reason why we couldn't do it. Of course the mbstring.func_overload would still disabled by default (maybe exporting the mb functions to the 'utf8' namespace? :P), so it would be a backward compatible change. What do you think? ps: maybe it is too late for 5.4, but having it in trunk is still better than nothing. The mbstring extension was enabled by default once upon a time, if memory serves, and as I recall the results were extremely painful. While both PHP and mbstring have matured significantly since then, I'm old school that way. Fool me once... Best, Mike Robinson -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Klaus Silveira (011) 8564-2492 www.klaussilveira.com
