Re: [PHP-DEV] ob_start callback not fired with ob_get_clean()
On 25 April 2012 17:50, Dmitri Snytkine dsnytk...@ultralogistics.com wrote:
I am wondering why the call to ob_get_clean and ob_get_contents does not
trigger the callback function registered with ob_start('mycallback')
You could at least have told what PHP version you're using...
The output control layer implementation has been replaced in 5.4.
Despite this list being neither a bug tracker nor a support forum:
- Reproduce script?
- Expected result?
- Actual result?
- In which version did it work correctly last?
Thank you.
--
Regards,
Mike
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] call user defined function with args
Hi: you can refer to zif_call_user_func, which could be find at http://lxr.php.net/opengrok/xref/PHP_5_4/ext/standard/basic_functions.c#4714 thanks On Fri, Apr 27, 2012 at 12:43 PM, Yader Hernandez yader.hernan...@gmail.com wrote: Hello, I found this zend_call_function(zend_fcall_info *fci, zend_fcall_info_cache *fci_cache TSRMLS_DC) and many examples using it. I can successfully call this and it will call the user function for me. I'm interested in learning how to not only call the function, but also pass arguments to that function. Can anyone please point me to where I can see how that's done? thx -- Laruence Xinchen Hui http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] call user defined function with args
You might be interested by zend_call_method_with_[XXX]_params() as well http://lxr.php.net/xref/PHP_5_3/Zend/zend_interfaces.h Julien.Pauli On Fri, Apr 27, 2012 at 8:51 AM, Laruence larue...@php.net wrote: Hi: you can refer to zif_call_user_func, which could be find at http://lxr.php.net/opengrok/xref/PHP_5_4/ext/standard/basic_functions.c#4714 thanks On Fri, Apr 27, 2012 at 12:43 PM, Yader Hernandez yader.hernan...@gmail.com wrote: Hello, I found this zend_call_function(zend_fcall_info *fci, zend_fcall_info_cache *fci_cache TSRMLS_DC) and many examples using it. I can successfully call this and it will call the user function for me. I'm interested in learning how to not only call the function, but also pass arguments to that function. Can anyone please point me to where I can see how that's done? thx -- Laruence Xinchen Hui http://www.laruence.com/ -- 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
[PHP-DEV] considering to remove ext/imap from master
hi! Before I go with a RFC and all that, I would like to check the current feeling about killing ext/imap. The c-client project is dead since quite some time already. I do not see any viable alternative (applicable to server side usages) and it would be very hard to maintain the same APIs, given the little mess in the imap's API. There are also plenty of very good PHP implementation out there. Roundcube being my favourite, zeta components of the Zend Frameworks being two other. What are your thoughts about this drop? Links: http://incubator.apache.org/zetacomponents http://framework.zend.com/ http://roundcube.net/ Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] considering to remove ext/imap from master
Hi! Before I go with a RFC and all that, I would like to check the current feeling about killing ext/imap. The c-client project is dead since quite some time already. I do not see any viable alternative (applicable to server side usages) and it would be very hard to maintain the same APIs, given the little mess in the imap's API. Whatever mess it is, tons of code is using it, and isn't going to move to Zend Framework any time soon (and roundcube is GPL which means it's unusable for many projects). So dropping it means these projects will never be able to upgrade. Now, what would such move give us? Is there any problem with imap now? -- 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] considering to remove ext/imap from master
hi, On Fri, Apr 27, 2012 at 7:47 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Whatever mess it is, tons of code is using it, and isn't going to move to Zend Framework any time soon (and roundcube is GPL which means it's unusable for many projects). So dropping it means these projects will never be able to upgrade. As I said there are many very good alternatives, BSD-like too. Now, what would such move give us? Is there any problem with imap now? Yes, many (see the bugs DB). And c-client is as dead as msql. What does it bring to us? Less work, less worry, less issues, give a clear signal to the projects to migrate. Also keep in mind that we are talking about 2015 here as 5.4 still has it. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] considering to remove ext/imap from master
Hi! As I said there are many very good alternatives, BSD-like too. Alternative means rewriting all the code. On top of framework previously not used in the project, with different APIs, different approach to IMAP, etc. This is a large piece of work, for many projects - totally unnecessary as ext/imap work for them right now. That provided the person in question actually owns the code, not just runs the app. In the latter case he has no options to upgrade at all. Yes, many (see the bugs DB). And c-client is as dead as msql. Bug DB is full of bugs for everything, not a reason to drop imap. As for less work, I don't see how much less work can be done on imap that is done now. If it still works for people, why remove it? I see no reason to do this. -- 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] considering to remove ext/imap from master
hi! On Fri, Apr 27, 2012 at 8:40 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Alternative means rewriting all the code. On top of framework previously not used in the project, with different APIs, different approach to IMAP, etc. This is a large piece of work, for many projects - totally unnecessary as ext/imap work for them right now. I think you over estimate the complexity to move something to a clean, maintained, user friendly API from a over complex, buggy and unmaintained extension and library (which can kill requests under certain circumstances too). That provided the person in question actually owns the code, not just runs the app. In the latter case he has no options to upgrade at all. Again, 2015! That's not now, not tomorrow but 2015! Yes, many (see the bugs DB). And c-client is as dead as msql. Bug DB is full of bugs for everything, not a reason to drop imap. As for less work, I don't see how much less work can be done on imap that is done now. If it still works for people, why remove it? I see no reason to do this. if totally dead and not secure c-client is not a good reason, then I have no idea what a good reason is :), and again, we are saying: Heh, I know you are busy like hell, but we are going to kill imap support in 2015, and some distros will maintain 5.4 for a couple of years longer too, so you should have enough time to migrate the little code taking care of imap. And why do I say little code? Because anyone making anything serious (except basic reading ops) with imap already migrated to alternatives or wrote its own implementation. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] considering to remove ext/imap from master
On Fri, April 27, 2012 1:51 pm, Pierre Joye wrote: hi! On Fri, Apr 27, 2012 at 8:40 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Alternative means rewriting all the code. On top of framework previously not used in the project, with different APIs, different approach to IMAP, etc. This is a large piece of work, for many projects - totally unnecessary as ext/imap work for them right now. I think you over estimate the complexity to move something to a clean, maintained, user friendly API from a over complex, buggy and unmaintained extension and library (which can kill requests under certain circumstances too). I think you are over-estimating my bandwidth to take on such a task. :-) That provided the person in question actually owns the code, not just runs the app. In the latter case he has no options to upgrade at all. Again, 2015! That's not now, not tomorrow but 2015! I have an imap script running server-side to filter my email and knock out a whole bunch of spam that SpamAssasin doesn't catch. It's been running in a cron job since at least July 15, 2004 That's just the earliest mod-time file I can find in the directory... It's been running longer than that, actually. I set it up when Eudora was taking too long to download my email. And Eudora was free. And ad-free. So that's probably pre-2003, if I'm reading Wikipedia correctly. I add a new folder and edit the script or set up an alias and edit the script or find a new annoying pattern and edit the script... It's currently at 1065 lines of code, most of which are mailbox filtering or patterns to kill spam. It's been working fine for 8 years. I don't really care if it dies in any given run. It's going to run again in 10 minutes anyway. I dunno what 8 years time 10 minutes is, but that's an awful lot of times it worked just fine. I don't have time to change it, it's running all on an internal network at my webhost, so security is not a real concern. I'd have to plead No -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Function boolval()
Hi, I suggest we add a function boolval(). It simply converts the given argument to a boolean, like strval(), intval() and floatval(). I already have an implementation ready[1]. Why? * It is missing in the current list of *val()-functions and people expect it to exist. I'd say it is an inconsistency. * It can be used as a callback, which is why a bool-cast does not suffice. -- Jille [1] https://github.com/php/php-src/pull/60 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] considering to remove ext/imap from master
Hi! I think you over estimate the complexity to move something to a clean, maintained, user friendly API from a over complex, buggy and unmaintained extension and library (which can kill requests under certain circumstances too). No I do not. It doesn't matter if it's maintained or not if the code *works*. However friendly and shiny new components are, it is new development in the application infrastructure, and believe me, I know how much that costs in dev time, qa time, support time, etc., etc. If you ever did such thing, you must know it too. Again, 2015! That's not now, not tomorrow but 2015! 5.5 is planned to be released next year, isn't it? Users of imap will not be able to use it. I see no reason to set up both them and 5.5 for this fail. if totally dead and not secure c-client is not a good reason, then I have no idea what a good reason is :), and again, we are saying: Heh, Good reason would be extension broken and nobody willing to fix it, or presence of the superior alternative with easy migration path. imap works for its users just fine, and alternatives require installing frameworks with substantially different APIs. So what? We have bugs in many extensions. It is sad that maintainers do not fix them, but so is the nature of the volonteer project. If the extension still works, I see no reason to remove 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] Function boolval()
On Fri, Apr 27, 2012 at 1:14 PM, Jille Timmermans ji...@quis.cx wrote: Hi, I suggest we add a function boolval(). It simply converts the given argument to a boolean, like strval(), intval() and floatval(). I already have an implementation ready[1]. Why? * It is missing in the current list of *val()-functions and people expect it to exist. I'd say it is an inconsistency. * It can be used as a callback, which is why a bool-cast does not suffice. -- Jille [1] https://github.com/php/php-**src/pull/60https://github.com/php/php-src/pull/60 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Do you have wiki access? If so, please post an RFC for this! You'd have my vote. =) --Kris
Re: [PHP-DEV] Function boolval()
On 27-04-12 22:19, Kris Craig wrote: On Fri, Apr 27, 2012 at 1:14 PM, Jille Timmermans ji...@quis.cx Hi, I suggest we add a function boolval(). It simply converts the given argument to a boolean, like strval(), intval() and floatval(). I already have an implementation ready[1]. Why? * It is missing in the current list of *val()-functions and people expect it to exist. I'd say it is an inconsistency. * It can be used as a callback, which is why a bool-cast does not suffice. -- Jille [1] https://github.com/php/php-__src/pull/60 Do you have wiki access? If so, please post an RFC for this! You'd have my vote. =) I don't. If anyone can give it to me I will post an RFC :) -- Jille -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] considering to remove ext/imap from master
On Fri, Apr 27, 2012 at 3:49 PM, Pierre Joye pierre@gmail.com wrote: hi! Before I go with a RFC and all that, I would like to check the current feeling about killing ext/imap. The c-client project is dead since quite some time already. I do not see any viable alternative (applicable to server side usages) and it would be very hard to maintain the same APIs, given the little mess in the imap's API. A question not directly related to the rest of the discussion: Killing ext/imap just means that it is not shipped by default anymore right? It will still be available via pecl, so people who want to use it, still can, right? Nikita -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] considering to remove ext/imap from master
Hi Richard, I've heard of a lot of people with little scripts running around, that need *really need* magic quotes enabled. (j/k) All joking aside I know that probably having something running fine for 8+ years is great. Congrats on that achievement! There are reasons to evolve things to the point where older code really can't remain compatible - obvious disclaimer: I don't use ext/imap I'm biased when it doesn't hurt me... - but I think that security or lack of maintenance might be the two crucial points that might culminate in that decision when thinking long term. That's not to say you shouldn't voice your opinions, specially when you're dependant on the ext, be it for a larger project, or for a personal geeky filter I congratulated you on earlier. But if the ext is no longer being maintained, even if working properly for the time being, there might be a point to marking it deprecated, with proper directions for alternatives/migrations. The problem is not today, or these past 8+ years it's been working wonderfully for you; but what happens when you're keeping the ext active [i.e. not deprecated], and problems come around some time from now. Since it's unmaintained, there might be a problem when there's no one wanting to fix it... You should probably find confort in also having a better code with a more robust API, even though you might be forced into touching something you havent for 8+ years (we all know how that feels like). If not, then at least consider this should be marked as deprecated (even without a due date for complete removal), just for the sake of no longer being maintained! ~ Daniel Macedo -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] considering to remove ext/imap from master
hi Nikita., On Fri, Apr 27, 2012 at 10:23 PM, Nikita Popov nikita@googlemail.com wrote: On Fri, Apr 27, 2012 at 3:49 PM, Pierre Joye pierre@gmail.com wrote: hi! Before I go with a RFC and all that, I would like to check the current feeling about killing ext/imap. The c-client project is dead since quite some time already. I do not see any viable alternative (applicable to server side usages) and it would be very hard to maintain the same APIs, given the little mess in the imap's API. A question not directly related to the rest of the discussion: Killing ext/imap just means that it is not shipped by default anymore right? It will still be available via pecl, so people who want to use it, still can, right? Right, and distros will release it forever too. We only say that we do not support it anymore, just like we did with sqlite (which has zero bugs and was widely used and did not have easy migration path for the databases). -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] considering to remove ext/imap from master
hi, On Fri, Apr 27, 2012 at 9:41 PM, Richard Lynch c...@l-i-e.com wrote: I have an imap script running server-side to filter my email and knock out a whole bunch of spam that SpamAssasin doesn't catch. Wrong tool for this task, but that's another discussion. Also as I said, if all you need is to read ,mails, it takes 5mins to do it with any of the previously libraries. They even have very nice to implement filters in a better way than what you could with ext/imap. I don't have time to change it, it's running all on an internal network at my webhost, so security is not a real concern. I'd have to plead No And what prevent you then to keep php 5.4 for the next 10 years as well? Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] considering to remove ext/imap from master
On Fri, 27 Apr 2012 15:49:03 +0200, Pierre Joye pierre@gmail.com wrote: Before I go with a RFC and all that, I would like to check the current feeling about killing ext/imap. The c-client project is dead since quite some time already. I do not see any viable alternative (applicable to server side usages) and it would be very hard to maintain the same APIs, given the little mess in the imap's API. There are also plenty of very good PHP implementation out there. Roundcube being my favourite, zeta components of the Zend Frameworks being two other. What are your thoughts about this drop? Since the library is not maintained anymore, this is an obvious candidate to move to PECL -- same case as sqlite. But then PHP will be further from Zawinski's law of software envelopment, which is a cause for concern :) [1] http://en.wikipedia.org/wiki/Jamie_Zawinski#Zawinski.27s_law_of_software_envelopment -- Gustavo Lopes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] considering to remove ext/imap from master
On Fri, 27 Apr 2012, Nikita Popov wrote: On Fri, Apr 27, 2012 at 3:49 PM, Pierre Joye pierre@gmail.com wrote: hi! Before I go with a RFC and all that, I would like to check the current feeling about killing ext/imap. The c-client project is dead since quite some time already. I do not see any viable alternative (applicable to server side usages) and it would be very hard to maintain the same APIs, given the little mess in the imap's API. A question not directly related to the rest of the discussion: Killing ext/imap just means that it is not shipped by default anymore right? It will still be available via pecl, so people who want to use it, still can, right? Sigh. That works for people that control their environment. It doesn't work for the pletoria of cases where you have to rely on the hosters. Most hosters would never install anything from PECL. As far as I know, ext/imap works, it's not beautiful, but it works. So no need to remove it. 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] considering to remove ext/imap from master
On Fri, Apr 27, 2012 at 11:00 PM, Derick Rethans der...@php.net wrote: Sigh. That works for people that control their environment. It doesn't work for the pletoria of cases where you have to rely on the hosters. Most hosters would never install anything from PECL. As far as I know, ext/imap works, it's not beautiful, but it works. So no need to remove it. May I ask why you agreed to move sqlite away? That is a very close situation (well, better as sqlite library status was way better than current c-client). Not trying to troll, but trying hard to figure out your reasoning here. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] considering to remove ext/imap from master
Hi! May I ask why you agreed to move sqlite away? That is a very close situation (well, better as sqlite library status was way better than current c-client). There's sqlite3, but nothing like this for imap. If there were another superior imap extension it would be different business. -- 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] Function boolval()
Hi
2012/4/27 Jille Timmermans ji...@quis.cx:
Hi,
I suggest we add a function boolval(). It simply converts the given argument
to a boolean, like strval(), intval() and floatval(). I already have an
implementation ready[1].
Why?
* It is missing in the current list of *val()-functions and people expect it
to exist. I'd say it is an inconsistency.
* It can be used as a callback, which is why a bool-cast does not suffice.
Does it really matter nowadays when we got closures anyway:
$bools = array_map(range('a', 'z'), function($a){ return((boolean) $a); });
--
regards,
Kalle Sommer Nielsen
ka...@php.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
