Re: [PHP-DEV] Bundling modern extensions
Am 07.06.2011 04:42, schrieb Martin Scotta: On Mon, Jun 6, 2011 at 8:15 PM, Reindl Harald h.rei...@thelounge.netwrote: Am 06.06.2011 23:40, schrieb Martin Scotta: It'd be very nice if some extension could be enabled just by dropping the extension file on the path. So developers can check what they have using phpinfo, and then upload the needed extension using ftp. Is it possible? if a developer only would try such idiotic action he would lost his accounts forever and get fired from one day to the next! WTF how can anybody have the idea that it would be a good idea to let non-sysadmins uplod and execute binaries on a server? Thanks you for all yours responses. Now it's clear what the issue is... the usage of compiled libraries. We need some middleware between the core and PHP. That way extensions could be written in PHP, compiled and distributed in some library format. Library users just add them into their path, include them, and use the classes/functions as usual. - No OS dependence - minimum dependence with core version - size of core will reduce drastically - faster runtime, include only what libs you use, as you need them what are you speaking about and since how long you are working with PHP that you never heard about PEAR, ZendFramework? signature.asc Description: OpenPGP digital signature
[PHP-DEV] Windows builds
I've cross posted to the windows list as this is a useful link! http://www.anindya.com/ I don't feel quite so bad now about not being able to update my own builds, but a matching Additional Extensions section for the x86 builds would just finish the picture. I'm just waiting for an OK to use the links in my own tutorials. -- 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// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bundling modern extensions
On 07/06/11 15:49, Reindl Harald wrote: Am 07.06.2011 04:42, schrieb Martin Scotta: On Mon, Jun 6, 2011 at 8:15 PM, Reindl Harald h.rei...@thelounge.netwrote: Am 06.06.2011 23:40, schrieb Martin Scotta: It'd be very nice if some extension could be enabled just by dropping the extension file on the path. So developers can check what they have using phpinfo, and then upload the needed extension using ftp. Is it possible? if a developer only would try such idiotic action he would lost his accounts forever and get fired from one day to the next! WTF how can anybody have the idea that it would be a good idea to let non-sysadmins uplod and execute binaries on a server? Thanks you for all yours responses. Now it's clear what the issue is... the usage of compiled libraries. We need some middleware between the core and PHP. That way extensions could be written in PHP, compiled and distributed in some library format. Library users just add them into their path, include them, and use the classes/functions as usual. - No OS dependence - minimum dependence with core version - size of core will reduce drastically - faster runtime, include only what libs you use, as you need them what are you speaking about and since how long you are working with PHP that you never heard about PEAR, ZendFramework? And you should know that PEAR and ZF are user-land libraries, not compiled libraries. I think Martin is wishing for is the PHP Native Interface: https://wiki.php.net/rfc/php_native_interface Either that, or a PHP equivalent of Cython or Pyrex. Cheers, David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Windows builds
Lester, We are now all aware of your constant bashing about our work for php on windows, but could you please give us some rest and post this wherever you like. And no you won't get a official ok for this build or any other but what we have already numerous times discuss. The same applies even more for x64 versions. Thanks for your understanding, On Tue, Jun 7, 2011 at 9:11 AM, Lester Caine les...@lsces.co.uk wrote: I've cross posted to the windows list as this is a useful link! http://www.anindya.com/ I don't feel quite so bad now about not being able to update my own builds, but a matching Additional Extensions section for the x86 builds would just finish the picture. I'm just waiting for an OK to use the links in my own tutorials. -- 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// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- 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] Bundling modern extensions
Am 07.06.2011 11:32, schrieb David Muir: On 07/06/11 15:49, Reindl Harald wrote: Am 07.06.2011 04:42, schrieb Martin Scotta: On Mon, Jun 6, 2011 at 8:15 PM, Reindl Harald h.rei...@thelounge.netwrote: Am 06.06.2011 23:40, schrieb Martin Scotta: It'd be very nice if some extension could be enabled just by dropping the extension file on the path. So developers can check what they have using phpinfo, and then upload the needed extension using ftp. Is it possible? if a developer only would try such idiotic action he would lost his accounts forever and get fired from one day to the next! WTF how can anybody have the idea that it would be a good idea to let non-sysadmins uplod and execute binaries on a server? Thanks you for all yours responses. Now it's clear what the issue is... the usage of compiled libraries. We need some middleware between the core and PHP. That way extensions could be written in PHP, compiled and distributed in some library format. Library users just add them into their path, include them, and use the classes/functions as usual. - No OS dependence - minimum dependence with core version - size of core will reduce drastically - faster runtime, include only what libs you use, as you need them what are you speaking about and since how long you are working with PHP that you never heard about PEAR, ZendFramework? And you should know that PEAR and ZF are user-land libraries, not compiled libraries. i know that I think Martin is wishing for is the PHP Native Interface: https://wiki.php.net/rfc/php_native_interface where is the real difference to a userland-library as PEAR and the thousand other which exists and will we ever see a solution for extensions wich is SECURE? there is a reason for example to disallow many functions on a webserver - so every API has to make sure they can not be bypassed because we can is no valid reason for everything because we can install binary extension as they exist now and if you can not you are missing the permissions for some good reasons signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] 5.4 moving forward
On Tue, Jun 7, 2011 at 4:26 AM, Rasmus ras...@lerdorf.com wrote: On 06/06/2011 08:38 PM, Lester Caine wrote: And much like Apache, I don't consider it our job to do binary builds for people. It is very nice that a few people have volunteered to build Windows binaries and they are available on windows.php.net as a convenience, but our primary focus is the source distribution and that's where the bulk of the attention goes. If people are building critical systems that rely on binary-only releases, they really should reconsider how they do things and at the very least install a compiler on their platform of choice and learn how to build stuff themselves. As far as I know nothing that was available in 5.2 is not available in 5.3 in source form. Same for binary, the release is complete. And our builds are per se official builds. 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] 5.4 moving forward
On Tue, Jun 7, 2011 at 7:41 AM, Lester Caine les...@lsces.co.uk wrote: People who are building critical systems are in a position to make a choice, and THEY will not be using windows. But PHP was origianlly 'Personal Home Page' and I am sure that as many people are using PHP because of the 'personal' element. Those are the sort of people who 5 years ago could not afford to buy the M$ software to create their own builds, and even today some areas of windows can't be built with the free version. We tried to fill the gap by writing our own compilations to fill the gap, but today the problem is that there is simply no beginners tutorial that directs people to how they can get around the problems created by the current windows builds of PHP. I said that moving people forward to PHP5.3 was another thread, and is work that does need to be done, but simply kicking those people out into the cold is much as M$ does every version is not the way to treat users. Keep your bashing out of this list. Thanks. No matter the target. A SIMPLE clean set of instructions on the windows download page would be a start, updating the manual to reflect the current situation, and reporting errors to third party projects We have no control over 3rd party projects, If you find misleading or wrong informations on our sites, please report a bug. But hi jacking every thread about new php release or new features is not the way, I repeat: It is not the way. 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] Callable typehint
On Tue, Jun 7, 2011 at 1:02 AM, Stas Malyshev smalys...@sugarcrm.com wrote:
Sure. How about reducing boilterplate code like this:
if(is_readable($foo)) {
$var = file_get_contents($foo);
} else {
throw InvalidArgumentException();
}
Why won't we make language construct to do that too? I don't think these
things belong in the language syntax.
The whole point is that callables are generally not constructed from
user input, they're hardcoded in the code somewhere, and so if a fatal
error occurs, the developer notices it, hopefully during development.
With is_readable, a file can be anywhere, anytime, readable or not, it
depends on the environment the code runs on, and not on the code
itself, so it's not deterministic and you should therefore be able to
easily handle this gracefully.
Cheers
--
Jordi Boggiano
@seldaek :: http://seld.be/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Implementation help needed: Currying RFC
On Mon, 2011-06-06 at 01:28 +0200, Lars Strojny wrote: I¹ve finally found some time to put together a first draft of an RFC for currying (https://wiki.php.net/rfc/currying). This is basically meant as a starting point to find a clean and concise syntax for PHP. So, if you kinda like what you¹ve read or you think it¹s crazy or anything in between, drop me a message. I wonder how your proposal would work with a variable number of arguments. Taking a piece out of your RFC: $apos = curry strpos(..., 'a')); Would the parameter always be appended? So what would happen here: $apos(); // runtime error wrong param count? $apos(bar); // fine $apos(bar, foo); // 'a' casted to long, used as offset? $apos(bar, foo, 0); // run-time error wrong param count? I feel that this won't fit easily in the language, while the feature itself can be nice with all these callback things. I also don't know if it can be implemented in an efficient way. A simple way to implement is to create a closure. (which has performance impacts and misleading error messages in the cases shown above) I also think that Keyword curry should have an alias schoenfinkel should not be the case. It is nice to remember some people and such but I think this alias is just one more thing to know when reading code but serves no real purpose. I know the concept mostly as currying, Scala for instance seems to always reference it as currying. johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Give the Language a Rest motion (fwd)
Hi, Short-array syntax, Native JSON, Currying. I can almost only say one thing: WHY?! And because of that, I'd like to forward a mail by Zeev from a few years ago. I think it applies now even more than then: -- Forwarded message -- Date: Thu, 09 Mar 2006 12:57:32 +0200 From: Zeev Suraski z...@zend.com To: internals@lists.php.net Subject: [PHP-DEV] Give the Language a Rest motion I'd like to raise a motion to 'Give the Language a Rest'. Almost a decade since we started with the 2nd iteration on the syntax (PHP 3), and 2 more major versions since then, and we're still heatedly debating on adding new syntactical, core level features. Is it really necessary? I'd say in almost all cases the answer's no, and a bunch of cases where a new feature could be useful does not constitute a good enough reason to add a syntax level feature. We might have to account for new technologies, or maybe new ways of thinking that might arise, but needless to say, most of the stuff we've been dealing with in recent times doesn't exactly fall in the category of cutting edge technology. My motion is to make it much, much more difficult to add new syntax-level features into PHP. Consider only features which have significant traction to a large chunk of our userbase, and not something that could be useful in some extremely specialized edge cases, usually of PHP being used for non web stuff. How do we do it? Unfortunately, I can't come up with a real mechanism to 'enforce' a due process and reasoning for new features. Instead, please take at least an hour to bounce this idea in the back of your mind, preferably more. Make sure you think about the full context, the huge audience out there, the consequences of making the learning curve steeper with every new feature, and the scope of the goodness that those new features bring. Consider how far we all come and how successful the PHP language is today, in implementing all sorts of applications most of us would have never even thought of when we created the language. Once you're done thinking, decide for yourself. Does it make sense to be discussing new language level features every other week? Or should we, perhaps, invest more in other fronts, which would be beneficial for a far bigger audience. The levels above - extensions to keep with the latest technologies, foundation classes, etc. Pretty much, the same direction other mature languages went to. To be clear, and to give this motion higher chances of success, I'm not talking about jump. PHP can live with jump, almost as well as it could live without it :) I'm talking about the general sentiment. Zeev -- 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] Give the Language a Rest motion (fwd)
On Tue, Jun 7, 2011 at 1:04 PM, Derick Rethans der...@php.net wrote: Hi, Short-array syntax, Native JSON, Currying. I can almost only say one thing: WHY?! And because of that, I'd like to forward a mail by Zeev from a few years ago. I think it applies now even more than then: I'd to disagree. I love activities on the list, even for features I would never want to see implemented in php. It is how it works, it is how it should work, Getting constant new requests, discussing new possible features, moving forward. Even if it does not mean it has to be uncontrollable and that we should implement every 2nd request. 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] Give the Language a Rest motion (fwd)
On Tue, Jun 7, 2011 at 1:04 PM, Derick Rethans der...@php.net wrote: Hi, Short-array syntax, Native JSON, Currying. I can almost only say one thing: WHY?! And because of that, I'd like to forward a mail by Zeev from a few years ago. I think it applies now even more than then: snip I think that it is better to have healthy discussion about the language, than to stop accepting feature request at all. of course we have to carefully select which RFCs are good enough and worthy for inclusion, and properly introduce them into the language and for the users. I really like the current buzz, but maybe there are some people like you, who are more in favor for the previous flow of conversations(fewer participants, fewer discussions). Tyrael
Re: [PHP-DEV] Implementation help needed: Currying RFC
Hi Johannes, Thank you very much for your detailed feedback. Am 07.06.11 12:40 schrieb Johannes Schlüter unter johan...@schlueters.de: [...] I wonder how your proposal would work with a variable number of arguments. Taking a piece out of your RFC: $apos = curry strpos(..., 'a')); Would the parameter always be appended? So what would happen here: $apos(); // runtime error wrong param count? $apos(bar); // fine $apos(bar, foo); // 'a' casted to long, used as offset? $apos(bar, foo, 0); // run-time error wrong param count? Clarified this specifically in the new error handling paragraph. It should throw a warning/notice in cases 3 and 4, stating that the parameter is not used. I feel that this won't fit easily in the language, while the feature itself can be nice with all these callback things. I also don't know if it can be implemented in an efficient way. A simple way to implement is to create a closure. (which has performance impacts and misleading error messages in the cases shown above) Explained more detailed in the RFC, how I would try implementing it (indeed with closures or a specialization of them, look at the new paragraph „Implementation details). I also think that Keyword curry should have an alias schoenfinkel should not be the case. It is nice to remember some people and such but I think this alias is just one more thing to know when reading code but serves no real purpose. I know the concept mostly as currying, Scala for instance seems to always reference it as currying. As I set on #pecl.php, I will not fight for this alias :). So removed in the RFC. With regards, Lars -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: [PHP-WIN] Re: [PHP-DEV] Windows builds
Pierre Joye wrote: Lester, We are now all aware of your constant bashing about our work for php on windows, but could you please give us some rest and post this wherever you like. And no you won't get a official ok for this build or any other but what we have already numerous times discuss. The same applies even more for x64 versions. No problem ... I'm not asking ... but future Firebird builds will only work fully with 64 bit installations. If anybody is interested http://enquirysolve.co.uk/wiki/index.php?page=Windows+Manual+-+FWAP+Installation replaces the one from 2006 which can't be used now to carry out a current working install. Still very much work in progress - I've been working on this since last night - I need to sort out how to unzip the php files on Windows 7 - I said no to the RAR trial and did not ralise that it also kills zip handling! :( -- 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// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bundling modern extensions
On 07/06/11 18:40, Reindl Harald wrote: Am 07.06.2011 11:32, schrieb David Muir: On 07/06/11 15:49, Reindl Harald wrote: Am 07.06.2011 04:42, schrieb Martin Scotta: On Mon, Jun 6, 2011 at 8:15 PM, Reindl Harald h.rei...@thelounge.netwrote: Am 06.06.2011 23:40, schrieb Martin Scotta: It'd be very nice if some extension could be enabled just by dropping the extension file on the path. So developers can check what they have using phpinfo, and then upload the needed extension using ftp. Is it possible? if a developer only would try such idiotic action he would lost his accounts forever and get fired from one day to the next! WTF how can anybody have the idea that it would be a good idea to let non-sysadmins uplod and execute binaries on a server? Thanks you for all yours responses. Now it's clear what the issue is... the usage of compiled libraries. We need some middleware between the core and PHP. That way extensions could be written in PHP, compiled and distributed in some library format. Library users just add them into their path, include them, and use the classes/functions as usual. - No OS dependence - minimum dependence with core version - size of core will reduce drastically - faster runtime, include only what libs you use, as you need them what are you speaking about and since how long you are working with PHP that you never heard about PEAR, ZendFramework? And you should know that PEAR and ZF are user-land libraries, not compiled libraries. i know that I think Martin is wishing for is the PHP Native Interface: https://wiki.php.net/rfc/php_native_interface where is the real difference to a userland-library as PEAR and the thousand other which exists and will we ever see a solution for extensions wich is SECURE? there is a reason for example to disallow many functions on a webserver - so every API has to make sure they can not be bypassed because we can is no valid reason for everything because we can install binary extension as they exist now and if you can not you are missing the permissions for some good reasons So you're saying that PECL, PNI or FFI should should be actively discouraged because of security concerns? Python has ctypes. How did it solve the security problems? What exactly are the security issues? I'm really trying to figure out where you're coming from. Cheers, David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-WIN] Re: [PHP-DEV] Windows builds
On 06/07/2011 09:36 AM, Lester Caine wrote: Pierre Joye wrote: Lester, We are now all aware of your constant bashing about our work for php on windows, but could you please give us some rest and post this wherever you like. And no you won't get a official ok for this build or any other but what we have already numerous times discuss. The same applies even more for x64 versions. No problem ... I'm not asking ... but future Firebird builds will only work fully with 64 bit installations. I can see it making sense to have a 64-bit build of a Database, but clients that just talk to it over a socket using some socket protocol shouldn't in any way be required to also be 64-bit. Same goes for your Web server and PHP if you use the recommended FastCGI mechanism. Again there is a nice separation between the two, so you don't need to match build environments there either. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bundling modern extensions
On Tue, Jun 7, 2011 at 3:04 PM, Reindl Harald h.rei...@thelounge.netwrote: Am 07.06.2011 14:44, schrieb David Muir: On 07/06/11 18:40, Reindl Harald wrote: there is a reason for example to disallow many functions on a webserver - so every API has to make sure they can not be bypassed because we can is no valid reason for everything because we can install binary extension as they exist now and if you can not you are missing the permissions for some good reasons So you're saying that PECL, PNI or FFI should should be actively discouraged because of security concerns? WHERE i said this? PECL-Extensions can NOT be enabled by the user except if dl is enabled of course. Tyrael
[PHP-DEV] Inline constructing/cloning and inline foreach listing
Hi,
I like to do stuff inline instead of cluttering my code with variables.
There are currently three syntaxes/expressions which are currently not
supported but I hope could be implemented until 5.4.
First inline constructing (which I think has already previously been
discussed), but also cloning, e.g:
// Inline constructing:
$car = (new CarFactory())-makeCar();
// Inline cloning:
$tomorrow = (clone $today)-add($one_day);
I'd also like to iterate sets of arrays more inline: (I'm not sure if this
has been discussed before)
foreach ($arrays as list($e1, $e2, $e3)) { ...
// Instead of:
foreach ($arrays as $array) {
list($e1, $e2, $e3) = $array;
Regards,
Hannes
Re: [PHP-DEV] Bundling modern extensions
On Tue, Jun 7, 2011 at 3:10 PM, Reindl Harald h.rei...@thelounge.netwrote: Am 07.06.2011 15:08, schrieb Ferenc Kovacs: On Tue, Jun 7, 2011 at 3:04 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 07.06.2011 14:44, schrieb David Muir: On 07/06/11 18:40, Reindl Harald wrote: there is a reason for example to disallow many functions on a webserver - so every API has to make sure they can not be bypassed because we can is no valid reason for everything because we can install binary extension as they exist now and if you can not you are missing the permissions for some good reasons So you're saying that PECL, PNI or FFI should should be actively discouraged because of security concerns? WHERE i said this? PECL-Extensions can NOT be enabled by the user except if dl is enabled of course. i think nobody out there will enable this and hope such crazy things are not enabled by default! sadly there are many crazy people out there: http://www.google.hu/#sclient=psyhl=husource=hpq=intitle:phpinfo()+enable_dlaq=faqi=aql=oq=pbx=1bav=on.2,or.r_gc.r_pw.fp=580ca0074daf5780biw=1280bih=939 Tyrael
RE: [PHP-DEV] Implementation help needed: Currying RFC
$apos = curry strpos(..., 'a')); $apos(); // runtime error wrong param count? $apos(bar); // fine $apos(bar, foo); // 'a' casted to long, used as offset? $apos(bar, foo, 0); // run-time error wrong param count? I understand where this can be useful sometimes, but I disagree that this should be added as a language feature. It is still possible to implement this (parameter positioning in your curried function) using a function that returns a closure similar to the curry_left example in the RFC. One possible method (inspired by the C++ system for doing the same thing) would be: $apos = curry( 'strpos', _1(), 'a' ); // _1() returns a placeholder positioning object This isn't quite as nice as the proposed T_FILL, but on the other hand, it is more powerful (parameters could change order) and isn't nearly as confusing as the RFC syntax (which looks like perhaps strpos is being called in some strange way). Of course, there is also always the regular old closure, which is far more explicit and leaves no confusion about exactly what is being returned. No offense to anyone who loves currying, but I don't see why this should be implemented. There are plenty of good options available for achieving identical or better results without modifying the language. John Crenshaw Priacta, Inc.
RE: [PHP-DEV] Inline constructing/cloning and inline foreach listing
// Inline constructing:
$car = (new CarFactory())-makeCar();
// Inline cloning:
$tomorrow = (clone $today)-add($one_day);
Agreed. The fact that these expressions can't be wrapped in parentheses never
made any sense to me.
foreach ($arrays as list($e1, $e2, $e3)) { ...
Disagree. This feels very obtuse. I wouldn't expect this construct to work at
all, and even if it did, it is highly ambiguous (I.E. at first I thought you
were intending to grab 3 entries at a time, rather than extracting entries from
a second array).
John Crenshaw
Priacta, Inc.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Callable typehint
On Mon, Jun 6, 2011 at 22:49, Christopher Jones christopher.jo...@oracle.com wrote: On 06/06/2011 12:41 PM, Hannes Magnusson wrote: See attached patch+phpt; Any objections to include it in 5.4? Hannes, How about putting up an RFC for it? Even a brief RFC would be better than none. https://wiki.php.net/rfc/callable To avoid another flamewar.. Am I now supposed to create a new thread with [RFC] in the subject, wait for minimum 2 weeks, and then create a poll somewhere on the wiki and create new thread with [VOTE] in subject, and wait for another 2weeks and then if accepted by 50%+1 php.net developer, and 60% of the community votes, then I can commit? Thats the current rules of the game? -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Callable typehint
On 7 June 2011 15:00, Hannes Magnusson bj...@php.net wrote: On Mon, Jun 6, 2011 at 22:49, Christopher Jones christopher.jo...@oracle.com wrote: On 06/06/2011 12:41 PM, Hannes Magnusson wrote: See attached patch+phpt; Any objections to include it in 5.4? Hannes, How about putting up an RFC for it? Even a brief RFC would be better than none. https://wiki.php.net/rfc/callable To avoid another flamewar.. Am I now supposed to create a new thread with [RFC] in the subject, wait for minimum 2 weeks, and then create a poll somewhere on the wiki and create new thread with [VOTE] in subject, and wait for another 2weeks and then if accepted by 50%+1 php.net developer, and 60% of the community votes, then I can commit? Thats the current rules of the game? I always thought it was publish and be damned. -- Richard Quadling Twitter : EE : Zend : PHPDoc @RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY : bit.ly/lFnVea -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Callable typehint
On Tue, Jun 7, 2011 at 16:04, Richard Quadling rquadl...@gmail.com wrote: On 7 June 2011 15:00, Hannes Magnusson bj...@php.net wrote: On Mon, Jun 6, 2011 at 22:49, Christopher Jones christopher.jo...@oracle.com wrote: On 06/06/2011 12:41 PM, Hannes Magnusson wrote: See attached patch+phpt; Any objections to include it in 5.4? Hannes, How about putting up an RFC for it? Even a brief RFC would be better than none. https://wiki.php.net/rfc/callable To avoid another flamewar.. Am I now supposed to create a new thread with [RFC] in the subject, wait for minimum 2 weeks, and then create a poll somewhere on the wiki and create new thread with [VOTE] in subject, and wait for another 2weeks and then if accepted by 50%+1 php.net developer, and 60% of the community votes, then I can commit? Thats the current rules of the game? I always thought it was publish and be damned. ;) That RFC process thread just became to much to pay attention to, so I'm unsure what the status of it is. -Hannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Trying to find out where the memory went
Please test the exact thing I suggested :) var_dump(memory_get_usage()); token_get_all(file_get_contents(FILE)); gc_collect_cycles(); var_dump(memory_get_usage()); memory_get_peak_usage() is irrelevant, and USE_ZEND_ALLOC won't give accurate results anymore when looking at memory usage. If the above gives the same numbers you got initially, then there's a memleak in token_get_all(). David On 06.06.2011, at 22:30, Mike van Riel wrote: David and Pauli, When I change the test script to: var_dump(memory_get_peak_usage()); gc_collect_cycles(); token_get_all(file_get_contents(FILE)); gc_collect_cycles(); var_dump(memory_get_peak_usage()); And execute the following bash line preceding: export USE_ZEND_ALLOC=0 I get the following output: int(8240) int(8240) When I remove the gc_collect_cycles I get the same result. Even assigning the results to a variable do not increase the peak memory. FYI: When I change the argument of memory_get_peak_usage to 'true', I get the following results: int(262144) int(262144) This amount is astoundingly less than the previous conclusions and less than my own calculations would show. Of course this leads me to the following questions: 1. Does it hurt to disable the Zend MM? 2. Can it be done from inside a PHP Script? 3. Why is the memory consumption so much lower, even lower than my calculations? I assume it is a good thing to at least try to create an easy way to reproduce the issue (cannot include my test file) and create a bug report about this :) Thank you for your assistance thus far. Mike On Sun, 5 Jun 2011 15:36:43 +0200, Julien Pauli wrote: Seems like leak. Try disabling ZendMM to see if something noticeable happens (memory peak should be lower). USE_ZEND_ALLOC=0 Cheers, Julien On Sun, Jun 5, 2011 at 2:01 PM, David Zülke david.zue...@bitextender.com wrote: Smells like a memory leak if gc_collect_cycles() doesn't fix it. David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php smime.p7s Description: S/MIME cryptographic signature
Re: [PHP-DEV] Trying to find out where the memory went
On Tue, Jun 7, 2011 at 4:28 PM, David Zülke david.zue...@bitextender.comwrote: Please test the exact thing I suggested :) AFAIK he did. int(640720) int(244001144) except if you suggested something else off-list. Tyrael
Re: [PHP-DEV] Trying to find out where the memory went
Damn I'm an idiot. I meant memory_get_usage() all along. Sorry Mike. Then it'll
make sense... memory_get_usage(), but a gc_collect_cycles() before the second
call.
So, my first email should have had this code in it:
var_dump(memory_get_usage());
token_get_all(file_get_contents('PATH'));
var_dump(memory_get_usage());
And then, a comparison to this would be useful:
var_dump(memory_get_usage());
token_get_all(file_get_contents('PATH'));
gc_collect_cycles();
var_dump(memory_get_usage());
David
On 07.06.2011, at 16:34, Ferenc Kovacs wrote:
On Tue, Jun 7, 2011 at 4:28 PM, David Zülke
david.zue...@bitextender.comwrote:
Please test the exact thing I suggested :)
AFAIK he did.
int(640720)
int(244001144)
except if you suggested something else off-list.
Tyrael
smime.p7s
Description: S/MIME cryptographic signature
Re: [PHP-DEV] Trying to find out where the memory went
One thing to keep in mind of course is that each zval incurs an overhead. $x =
1; requires 144 bytes of memory in total IIRC.
David
On 04.06.2011, at 23:38, Mike van Riel wrote:
Dear Internals,
During development of DocBlox I encountered a (for me) unusual situation
with regards to memory usage.
I hope you can shed some light on this for me as I do not understand.
The situations is as follows:
I have a php file containing about 53 KLOC (including whitespace and
comments), which is about 2.1MB in size. When I execute the
memory_get_peak_usage after running the token_get_all method on its
content it reports that 232MB of RAM have been used in the process.
I am having trouble understanding how 244003984B (232MB) RAM could be
used.
The following is what I have calculated:
* 640.952B to start with (measured);
* 2.1MB to load the file contents into memory using file_get_contents
* 68 bytes for the resulting array
* 68 bytes for each child array representing a token
* 68 bytes for each element in a token array (which can be either 1 or
3, depending whether it is actually a token or literal)
* 2.1MB in total for the string contents of the token literals /
contents (equivalent to the byte size of the file)
I have used the count method to retrieve the number of tokens (276697)
and come to the following sum (everything is retrieved and calculated in
bytes):
640952+2165950+68+(276697*68)+(276697*3*68)+2165950=80234436 = 76M
This is a worst case formula where I assume that every token in the
array consists of 3 elements.
Based on this calculation I would be missing 156MB of memory; anybody
know where that went?
I used the following snippet of code for my tests:
var_dump(memory_get_peak_usage());
$tokens = token_get_all(file_get_contents('PATH'));
var_dump(count($tokens));
var_dump(memory_get_peak_usage());
I hope this mail did not scare anyone ;)
Kind regards,
Mike van Riel
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
smime.p7s
Description: S/MIME cryptographic signature
Re: [PHP-DEV] Bundling modern extensions
Martin Scotta On Tue, Jun 7, 2011 at 10:36 AM, Ferenc Kovacs i...@tyrael.hu wrote: On Tue, Jun 7, 2011 at 3:10 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 07.06.2011 15:08, schrieb Ferenc Kovacs: On Tue, Jun 7, 2011 at 3:04 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 07.06.2011 14:44, schrieb David Muir: On 07/06/11 18:40, Reindl Harald wrote: there is a reason for example to disallow many functions on a webserver - so every API has to make sure they can not be bypassed because we can is no valid reason for everything because we can install binary extension as they exist now and if you can not you are missing the permissions for some good reasons So you're saying that PECL, PNI or FFI should should be actively discouraged because of security concerns? WHERE i said this? PECL-Extensions can NOT be enabled by the user except if dl is enabled of course. i think nobody out there will enable this and hope such crazy things are not enabled by default! sadly there are many crazy people out there: http://www.google.hu/#sclient=psyhl=husource=hpq=intitle:phpinfo()+enable_dlaq=faqi=aql=oq=pbx=1bav=on.2,or.r_gc.r_pw.fp=580ca0074daf5780biw=1280bih=939 Most admins are not even aware of this, others really don't care -- how many host are up to date? So why relying on them? Tyrael
Re: [PHP-DEV] Bundling modern extensions
On Tue, Jun 7, 2011 at 4:59 PM, Martin Scotta martinsco...@gmail.comwrote: Martin Scotta On Tue, Jun 7, 2011 at 10:36 AM, Ferenc Kovacs i...@tyrael.hu wrote: On Tue, Jun 7, 2011 at 3:10 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 07.06.2011 15:08, schrieb Ferenc Kovacs: On Tue, Jun 7, 2011 at 3:04 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 07.06.2011 14:44, schrieb David Muir: On 07/06/11 18:40, Reindl Harald wrote: there is a reason for example to disallow many functions on a webserver - so every API has to make sure they can not be bypassed because we can is no valid reason for everything because we can install binary extension as they exist now and if you can not you are missing the permissions for some good reasons So you're saying that PECL, PNI or FFI should should be actively discouraged because of security concerns? WHERE i said this? PECL-Extensions can NOT be enabled by the user except if dl is enabled of course. i think nobody out there will enable this and hope such crazy things are not enabled by default! sadly there are many crazy people out there: http://www.google.hu/#sclient=psyhl=husource=hpq=intitle:phpinfo()+enable_dlaq=faqi=aql=oq=pbx=1bav=on.2,or.r_gc.r_pw.fp=580ca0074daf5780biw=1280bih=939 Most admins are not even aware of this, others really don't care -- how many host are up to date? So why relying on them? I didn't intended to use that to block your feature request. I've just show that there are people ran php installs with enable_dl = On personally I wouldn't mind if we would drop the support for the dl, but thats offtopic here. Tyrael
Re: [PHP-DEV] Bundling modern extensions
Martin Scotta On Tue, Jun 7, 2011 at 6:32 AM, David Muir davidkm...@gmail.com wrote: On 07/06/11 15:49, Reindl Harald wrote: Am 07.06.2011 04:42, schrieb Martin Scotta: On Mon, Jun 6, 2011 at 8:15 PM, Reindl Harald h.rei...@thelounge.net wrote: Am 06.06.2011 23:40, schrieb Martin Scotta: It'd be very nice if some extension could be enabled just by dropping the extension file on the path. So developers can check what they have using phpinfo, and then upload the needed extension using ftp. Is it possible? if a developer only would try such idiotic action he would lost his accounts forever and get fired from one day to the next! WTF how can anybody have the idea that it would be a good idea to let non-sysadmins uplod and execute binaries on a server? Thanks you for all yours responses. Now it's clear what the issue is... the usage of compiled libraries. We need some middleware between the core and PHP. That way extensions could be written in PHP, compiled and distributed in some library format. Library users just add them into their path, include them, and use the classes/functions as usual. - No OS dependence - minimum dependence with core version - size of core will reduce drastically - faster runtime, include only what libs you use, as you need them what are you speaking about and since how long you are working with PHP that you never heard about PEAR, ZendFramework? And you should know that PEAR and ZF are user-land libraries, not compiled libraries. I think Martin is wishing for is the PHP Native Interface: https://wiki.php.net/rfc/php_native_interface Either that, or a PHP equivalent of Cython or Pyrex. Cython or Pyrex are good examples of what I meant. I'm not sure about the PNI Cheers, David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Implementation help needed: Currying RFC
Hi John,
thanks for your feedback.
Am 07.06.11 15:43 schrieb John Crenshaw unter johncrens...@priacta.com:
[...]
I understand where this can be useful sometimes, but I disagree that this
should be added as a language feature. It is still possible to implement
this (parameter positioning in your curried function) using a function
that returns a closure similar to the curry_left example in the RFC. One
possible method (inspired by the C++ system for doing the same thing)
would be:
$apos = curry( 'strpos', _1(), 'a' ); // _1() returns a placeholder
positioning object
Interesting idea to use placeholder argument as it is implementable in
user space (or as a PECL extension or a bundled one) without touching the
parser. Maybe an arg()-Function which returns a placeholder object would
be the way to go. Something like this maybe:
$apos = curry('strpos, arg(1), 'a);
This isn't quite as nice as the proposed T_FILL, but on the other hand,
it is more powerful (parameters could change order) and isn't nearly as
confusing as the RFC syntax (which looks like perhaps strpos is being
called in some strange way).
Could you elaborate on how parameters could change order?
Of course, there is also always the regular old closure, which is far
more explicit and leaves no confusion about exactly what is being
returned.
That¹s true. The main motivation for this proposal is brevity and less
boilerplate code for callbacks.
No offense to anyone who loves currying, but I don't see why this should
be implemented. There are plenty of good options available for achieving
identical or better results without modifying the language.
Thanks again for your opinion and the idea of having an argument
placeholder.
With regards,
Lars
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Implementation help needed: Currying RFC
Martin Scotta On Tue, Jun 7, 2011 at 10:43 AM, John Crenshaw johncrens...@priacta.comwrote: $apos = curry strpos(..., 'a')); $apos(); // runtime error wrong param count? $apos(bar); // fine $apos(bar, foo); // 'a' casted to long, used as offset? $apos(bar, foo, 0); // run-time error wrong param count? I understand where this can be useful sometimes, but I disagree that this should be added as a language feature. It is still possible to implement this (parameter positioning in your curried function) using a function that returns a closure similar to the curry_left example in the RFC. One possible method (inspired by the C++ system for doing the same thing) would be: $apos = curry( 'strpos', _1(), 'a' ); // _1() returns a placeholder positioning object This isn't quite as nice as the proposed T_FILL, but on the other hand, it is more powerful (parameters could change order) and isn't nearly as confusing as the RFC syntax (which looks like perhaps strpos is being called in some strange way). Of course, there is also always the regular old closure, which is far more explicit and leaves no confusion about exactly what is being returned. No offense to anyone who loves currying, but I don't see why this should be implemented. There are plenty of good options available for achieving identical or better results without modifying the language. Hey Jhon, What about writing your curry idea in plain PHP, as a proof of concept. Then you can show examples live and others can toy with it. I'm pretty sure most php developers are not used to curry -- or at least those who don't have functional programming skills John Crenshaw Priacta, Inc.
Re: [PHP-DEV] Bundling modern extensions
Am 07.06.2011 16:59, schrieb Martin Scotta: Most admins are not even aware of this, others really don't care -- how many host are up to date? So why relying on them? 2.6.35.13-92.fc14.x86_64 #1 SMP Sat May 21 17:26:25 UTC 2011 httpd-2.2.19-2.fc14.rh.20110526.x86_64 apr-1.4.5-1.fc14.rh.20110522.x86_64.rpm mod_security-2.6.0-3.fc14.rh.20110526.x86_64 php-suhosin-0.9.32.1-13.fc14.rh.20110526.x86_64 mysql-server-5.5.13-2.fc14.rh.20110601.x86_64 phpMyAdmin-3.4.2-2.fc14.rh.20110607.noarch.rpm disable_functions: popen, pclose, exec, passthru, shell_exec, system, proc_open proc_close, proc_nice, proc_terminate, proc_get_status, pcntl_exec, apache_child_terminate posix_kill, posix_mkfifo, posix_setpgid, posix_setsid, posix_setuid, mail, symlink so please keep in mind that there are users/admins which are really knowing what they do and try not introduce cool features / defaults while bypassing security with them only for braindead users thinking enable all you can get is funny a well configured machine has ALL disabled / uninstalled which is not really needed signature.asc Description: OpenPGP digital signature
[PHP-DEV] Re: Callable typehint
Dne 6.6.2011 21:41, Hannes Magnusson napsal(a):
Hi
As quickly mentioned in the '$arr = array('Hello', 'world'); $arr();'
thread[1], we are hitting the need for a callable typehint.
See attached patch+phpt; Any objections to include it in 5.4?
-Hannes
[1] http://php.markmail.org/message/gdas65h3im52sleg
I like the idea. However I think the type hint should be named
callback instead of callable because this name is used already in a
lot of documentations and also in PHP documentation
http://php.net/manual/en/language.pseudo-types.php#language.types.callback
Jaroslav Hanslik
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inline constructing/cloning and inline foreach listing
On 7 June 2011 15:53, John Crenshaw johncrens...@priacta.com wrote:
foreach ($arrays as list($e1, $e2, $e3)) { ...
Disagree. This feels very obtuse. I wouldn't expect this construct to work
at all, and even if it did, it is highly ambiguous (I.E. at first I thought
you were intending to grab 3 entries at a time, rather than extracting
entries from a second array).
John Crenshaw
Priacta, Inc.
I don't understand what's ambiguous? For each iteration the foreach assigns
the current value to the variable $value specified as either as $key =
$value or as $value. The as keyword is simply a type of assignment
operator that assigns the current element to the right expression. Since PHP
has a special list() language construct for assignment it doesn't make
sense that list(...) = $something assignment would work but not
array($something) as list(...).
Grabbing 3 elements at a time is not logical at all. Why would the list
construct change how the foreach iterates?
Hannes
RE: [PHP-DEV] Implementation help needed: Currying RFC
-Original Message-
From: Lars Strojny [mailto:l...@strojny.net]
I understand where this can be useful sometimes, but I disagree that this
should be added as a language feature. It is still possible to implement
this (parameter positioning in your curried function) using a function
that returns a closure similar to the curry_left example in the RFC. One
possible method (inspired by the C++ system for doing the same thing)
would be:
$apos = curry( 'strpos', _1(), 'a' ); // _1() returns a placeholder
positioning object
Interesting idea to use placeholder argument as it is implementable in
user space (or as a PECL extension or a bundled one) without touching the
parser. Maybe an arg()-Function which returns a placeholder object would
be the way to go. Something like this maybe:
$apos = curry('strposŒ, arg(1), 'aŒ);
That would work too. The general idea for this type of implementation isn't
mine. This is how C++ systems implement this, which is where the idea comes
from. (See boost::bind)
I like your arg(n) syntax better, but worry about namespace collisions (but
again, that's less of an issue when implemented in user code, rather than at
the language level).
This isn't quite as nice as the proposed T_FILL, but on the other hand,
it is more powerful (parameters could change order) and isn't nearly as
confusing as the RFC syntax (which looks like perhaps strpos is being
called in some strange way).
Could you elaborate on how parameters could change order?
Yeah. Consider this:
$today_cookie = curry('setcookie', arg(1), arg(2), arg(4), 60*60*24, arg(3));
Originally, the order of parameters in setcookie is ($name, $value, $expire,
$path, $domain, ...). this changes the order to ($name, $value, $domain, $path)
(which is common for setcookie wrappers, because it is often a more useful
order).
In any case, you can see how this type of implementation can be very flexible
and tailored to specific application needs in a way that a language level
implementation can't (for fear of bloat).
John Crenshaw
Priacta, Inc.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Inline constructing/cloning and inline foreach listing
From: Hannes Landeholm [mailto:landeh...@gmail.com]
Sent: Tuesday, June 07, 2011 11:50 AM
To: John Crenshaw; internals@lists.php.net
Subject: Re: [PHP-DEV] Inline constructing/cloning and inline foreach listing
On 7 June 2011 15:53, John Crenshaw
johncrens...@priacta.commailto:johncrens...@priacta.com wrote:
foreach ($arrays as list($e1, $e2, $e3)) { ...
Disagree. This feels very obtuse. I wouldn't expect this construct to work at
all, and even if it did, it is highly ambiguous (I.E. at first I thought you
were intending to grab 3 entries at a time, rather than extracting entries from
a second array).
John Crenshaw
Priacta, Inc.
I don't understand what's ambiguous? For each iteration the foreach assigns the
current value to the variable $value specified as either as $key = $value or
as $value. The as keyword is simply a type of assignment operator that
assigns the current element to the right expression. Since PHP has a special
list() language construct for assignment it doesn't make sense that
list(...) = $something assignment would work but not array($something) as
list(...).
Grabbing 3 elements at a time is not logical at all. Why would the list
construct change how the foreach iterates?
Hannes
The proposed meaning IS the more logical of the two, but that didn't stop me
from being confused when I first looked at the construction. Like I said, at
first glance I thought you were trying to iterate 3 at a time and I thought
why would we want the language to support THAT?
In any case, I'm just one person, and I don't entirely care for list() in the
first place so I'm probably biased, but this construct seems wrong to me.
John Crenshaw
Priacta, Inc.
Re: [PHP-DEV] Callable typehint
On 2011-06-07, Hannes Magnusson bj...@php.net wrote: On Mon, Jun 6, 2011 at 22:49, Christopher Jones christopher.jo...@oracle.com wrote: On 06/06/2011 12:41 PM, Hannes Magnusson wrote: See attached patch+phpt; Any objections to include it in 5.4? Hannes, How about putting up an RFC for it? Even a brief RFC would be better than none. https://wiki.php.net/rfc/callable I've edited the Problems section to also point out that Closure is considered an implementation detail which may change in the future -- which could potentially require changing any code type-hinting on it. -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Implementation help needed: Currying RFC
Hi Martin, Am 07.06.11 17:09 schrieb Martin Scotta unter martinsco...@gmail.com: [...] Hey Jhon, What about writing your curry idea in plain PHP, as a proof of concept. Then you can show examples live and others can toy with it. Yep, working on it. With regards, Lars -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Windows builds
I don't feel quite so bad now about not being able to update my own builds, but a matching Additional Extensions section for the x86 builds would just finish the picture. If the PHP+Windows community developed a reliable system that built [most] all PECL extensions, then we would link to that within the PHP Manual. And if such a system was moved to a php.net server, then DLL download links could also be added to each individual pecl.php.net page. Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Implementation help needed: Currying RFC
Hey John, What about writing your curry idea in plain PHP, as a proof of concept. Then you can show examples live and others can toy with it. I'm pretty sure most php developers are not used to curry -- or at least those who don't have functional programming skills I'll consider this. The basic theory is pretty simple. You need an object that identifies a parameter position, and a short syntax for referencing that object. I think anyone familiar with currying should be able to get the basic idea from that, so I don't think this stops the discussion from moving forward, but if a userland implementation is needed to demonstrate why a parser level implementation isn't, I can throw together something basic, or at least some pseudo-code. John Crenshaw Priacta, Inc. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Implementation help needed: Currying RFC
So, here we go, simple prototype of what John suggested: - Test Case: https://github.com/lstrojny/functional-php/blob/playground/tests/Functional /CurryTest.php - Implementation: https://github.com/lstrojny/functional-php/blob/playground/src/Functional/C urry.php With regards, Lars Am 07.06.11 18:14 schrieb Lars Strojny unter l...@strojny.net: Hi Martin, Am 07.06.11 17:09 schrieb Martin Scotta unter martinsco...@gmail.com: [...] Hey Jhon, What about writing your curry idea in plain PHP, as a proof of concept. Then you can show examples live and others can toy with it. Yep, working on it. With regards, Lars -- 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] Windows builds
On Tue, Jun 7, 2011 at 6:15 PM, Philip Olson phi...@roshambo.org wrote: I don't feel quite so bad now about not being able to update my own builds, but a matching Additional Extensions section for the x86 builds would just finish the picture. If the PHP+Windows community developed a reliable system that built [most] all PECL extensions, then we would link to that within the PHP Manual. And if such a system was moved to a php.net server, then DLL download links could also be added to each individual pecl.php.net page. There is an easy way to build pecl extension and yes, pecl.php.net will be the place to provide them as well. In the meantime I uploaded them in the link I pasted earlier. But it happens that things can happen when people actually do the work, and not only complain endlessly in all possible channels. 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] Bundling modern extensions
My reasoning is simple. The key for bundling extensions is to have them available for most hosting solutions. If a shared host provides support for mongodb, then he will most likely enable the mongodb extension in php, if he knows what he is doing. The same applies for all other non core critical features but more from an architecture point of view. Please don't forget that it's possible to host your database apart from your main code. Mongolab[1], for example, offers MongoDB hosting, so shared hosts that have the MongoDB extension enabled could easily use their free tier on cheap hosting (at the cost of latency, of course). Couch.io[2] used to offer free trial/sandbox hosting of CouchDB, similarly (but there was no stable CouchDB extension last time I checked), but I'm not sure if Couchbase (to which couch.io now points) does. The point is that you don't need to have the target service available on the PHP-hosting-machine in order to make use of the technology. [1] https://mongolab.com/ [2] http://www.couchbase.com/ S -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Trying to find out where the memory went
I have ran the script that you provided and got the following results: int(635192) int(635944) Which is far less than the peak memory result. I use memory_get_peak_usage to measure what the worst case memory output is in my application. I expect this to be the actual memory used (and thus when the server starts swapping if this number exceeds the physical memory). Is my assertion about the meaning of memory_get_peak_usage incorrect? Mike On Tue, 2011-06-07 at 16:28 +0200, David Zülke wrote: Please test the exact thing I suggested :) var_dump(memory_get_usage()); token_get_all(file_get_contents(FILE)); gc_collect_cycles(); var_dump(memory_get_usage()); memory_get_peak_usage() is irrelevant, and USE_ZEND_ALLOC won't give accurate results anymore when looking at memory usage. If the above gives the same numbers you got initially, then there's a memleak in token_get_all(). David On 06.06.2011, at 22:30, Mike van Riel wrote: David and Pauli, When I change the test script to: var_dump(memory_get_peak_usage()); gc_collect_cycles(); token_get_all(file_get_contents(FILE)); gc_collect_cycles(); var_dump(memory_get_peak_usage()); And execute the following bash line preceding: export USE_ZEND_ALLOC=0 I get the following output: int(8240) int(8240) When I remove the gc_collect_cycles I get the same result. Even assigning the results to a variable do not increase the peak memory. FYI: When I change the argument of memory_get_peak_usage to 'true', I get the following results: int(262144) int(262144) This amount is astoundingly less than the previous conclusions and less than my own calculations would show. Of course this leads me to the following questions: 1. Does it hurt to disable the Zend MM? 2. Can it be done from inside a PHP Script? 3. Why is the memory consumption so much lower, even lower than my calculations? I assume it is a good thing to at least try to create an easy way to reproduce the issue (cannot include my test file) and create a bug report about this :) Thank you for your assistance thus far. Mike On Sun, 5 Jun 2011 15:36:43 +0200, Julien Pauli wrote: Seems like leak. Try disabling ZendMM to see if something noticeable happens (memory peak should be lower). USE_ZEND_ALLOC=0 Cheers, Julien On Sun, Jun 5, 2011 at 2:01 PM, David Zülke david.zue...@bitextender.com wrote: Smells like a memory leak if gc_collect_cycles() doesn't fix it. David -- 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] Trying to find out where the memory went
Before I forget; without gc_collect_cycles I get the following output using memory_get_usage instead of memory_get_peak_usage: int(634640) int(635392) Mike On Tue, 2011-06-07 at 19:44 +0200, Mike van Riel wrote: I have ran the script that you provided and got the following results: int(635192) int(635944) Which is far less than the peak memory result. I use memory_get_peak_usage to measure what the worst case memory output is in my application. I expect this to be the actual memory used (and thus when the server starts swapping if this number exceeds the physical memory). Is my assertion about the meaning of memory_get_peak_usage incorrect? Mike On Tue, 2011-06-07 at 16:28 +0200, David Zülke wrote: Please test the exact thing I suggested :) var_dump(memory_get_usage()); token_get_all(file_get_contents(FILE)); gc_collect_cycles(); var_dump(memory_get_usage()); memory_get_peak_usage() is irrelevant, and USE_ZEND_ALLOC won't give accurate results anymore when looking at memory usage. If the above gives the same numbers you got initially, then there's a memleak in token_get_all(). David On 06.06.2011, at 22:30, Mike van Riel wrote: David and Pauli, When I change the test script to: var_dump(memory_get_peak_usage()); gc_collect_cycles(); token_get_all(file_get_contents(FILE)); gc_collect_cycles(); var_dump(memory_get_peak_usage()); And execute the following bash line preceding: export USE_ZEND_ALLOC=0 I get the following output: int(8240) int(8240) When I remove the gc_collect_cycles I get the same result. Even assigning the results to a variable do not increase the peak memory. FYI: When I change the argument of memory_get_peak_usage to 'true', I get the following results: int(262144) int(262144) This amount is astoundingly less than the previous conclusions and less than my own calculations would show. Of course this leads me to the following questions: 1. Does it hurt to disable the Zend MM? 2. Can it be done from inside a PHP Script? 3. Why is the memory consumption so much lower, even lower than my calculations? I assume it is a good thing to at least try to create an easy way to reproduce the issue (cannot include my test file) and create a bug report about this :) Thank you for your assistance thus far. Mike On Sun, 5 Jun 2011 15:36:43 +0200, Julien Pauli wrote: Seems like leak. Try disabling ZendMM to see if something noticeable happens (memory peak should be lower). USE_ZEND_ALLOC=0 Cheers, Julien On Sun, Jun 5, 2011 at 2:01 PM, David Zülke david.zue...@bitextender.com wrote: Smells like a memory leak if gc_collect_cycles() doesn't fix it. David -- 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] Trying to find out where the memory went
memory_get_peak_usage() is the maximum amount of memory used by the VM of PHP (but not by some extensions for instance) up until the point where that function is called. So the actual memory usage may be even higher IIRC. But yeah, you're basically right. I've explained in another message why it might be so much more than you expected (zval overhead, basically) David On 07.06.2011, at 19:44, Mike van Riel wrote: I have ran the script that you provided and got the following results: int(635192) int(635944) Which is far less than the peak memory result. I use memory_get_peak_usage to measure what the worst case memory output is in my application. I expect this to be the actual memory used (and thus when the server starts swapping if this number exceeds the physical memory). Is my assertion about the meaning of memory_get_peak_usage incorrect? Mike On Tue, 2011-06-07 at 16:28 +0200, David Zülke wrote: Please test the exact thing I suggested :) var_dump(memory_get_usage()); token_get_all(file_get_contents(FILE)); gc_collect_cycles(); var_dump(memory_get_usage()); memory_get_peak_usage() is irrelevant, and USE_ZEND_ALLOC won't give accurate results anymore when looking at memory usage. If the above gives the same numbers you got initially, then there's a memleak in token_get_all(). David On 06.06.2011, at 22:30, Mike van Riel wrote: David and Pauli, When I change the test script to: var_dump(memory_get_peak_usage()); gc_collect_cycles(); token_get_all(file_get_contents(FILE)); gc_collect_cycles(); var_dump(memory_get_peak_usage()); And execute the following bash line preceding: export USE_ZEND_ALLOC=0 I get the following output: int(8240) int(8240) When I remove the gc_collect_cycles I get the same result. Even assigning the results to a variable do not increase the peak memory. FYI: When I change the argument of memory_get_peak_usage to 'true', I get the following results: int(262144) int(262144) This amount is astoundingly less than the previous conclusions and less than my own calculations would show. Of course this leads me to the following questions: 1. Does it hurt to disable the Zend MM? 2. Can it be done from inside a PHP Script? 3. Why is the memory consumption so much lower, even lower than my calculations? I assume it is a good thing to at least try to create an easy way to reproduce the issue (cannot include my test file) and create a bug report about this :) Thank you for your assistance thus far. Mike On Sun, 5 Jun 2011 15:36:43 +0200, Julien Pauli wrote: Seems like leak. Try disabling ZendMM to see if something noticeable happens (memory peak should be lower). USE_ZEND_ALLOC=0 Cheers, Julien On Sun, Jun 5, 2011 at 2:01 PM, David Zülke david.zue...@bitextender.com wrote: Smells like a memory leak if gc_collect_cycles() doesn't fix it. David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php smime.p7s Description: S/MIME cryptographic signature
Re: [PHP-DEV] Windows builds
On Jun 7, 2011, at 10:11 AM, Pierre Joye wrote: On Tue, Jun 7, 2011 at 6:15 PM, Philip Olson phi...@roshambo.org wrote: I don't feel quite so bad now about not being able to update my own builds, but a matching Additional Extensions section for the x86 builds would just finish the picture. If the PHP+Windows community developed a reliable system that built [most] all PECL extensions, then we would link to that within the PHP Manual. And if such a system was moved to a php.net server, then DLL download links could also be added to each individual pecl.php.net page. There is an easy way to build pecl extension and yes, pecl.php.net will be the place to provide them as well. In the meantime I uploaded them in the link I pasted earlier. But it happens that things can happen when people actually do the work, and not only complain endlessly in all possible channels. And this is a call for someone or some people to do the work by raising a hand, posting an RFC, writing code, whatever it takes. But I think people assume either it's going to eventually happen, or that php.net is happy with the current situation. In other words, we need an official progress report and position on the manner. Thoughts? Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Windows builds
On Tue, Jun 7, 2011 at 7:53 PM, Philip Olson phi...@roshambo.org wrote: And this is a call for someone or some people to do the work by raising a hand, posting an RFC, writing code, whatever it takes. But I think people assume either it's going to eventually happen, or that php.net is happy with the current situation. In other words, we need an official progress report and position on the manner. Thoughts? There is an official report and that's phpize support being almost complete, that finally two persons seem to be willing to help with the web frontend parts of the job. Wiki sections with the progress will follow as well. So please do not interfere with that as it could be finally take off and the last we need is even more confusions and politics. Once it is place, I will make the change in the docs accordingly. But about linking some random, uncontrolled and especially ones provided by the initial poster in this thread in our documentation is an absolute no go. The reasons are numerous and quite obvious if you have followed the archives. 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] Windows builds
On Jun 7, 2011, at 11:10 AM, Pierre Joye wrote: On Tue, Jun 7, 2011 at 7:53 PM, Philip Olson phi...@roshambo.org wrote: And this is a call for someone or some people to do the work by raising a hand, posting an RFC, writing code, whatever it takes. But I think people assume either it's going to eventually happen, or that php.net is happy with the current situation. In other words, we need an official progress report and position on the manner. Thoughts? There is an official report and that's phpize support being almost complete, that finally two persons seem to be willing to help with the web frontend parts of the job. Wiki sections with the progress will follow as well. So please do not interfere with that as it could be finally take off and the last we need is even more confusions and politics. Once it is place, I will make the change in the docs accordingly. My intent is to push progress and gain clarity. But about linking some random, uncontrolled and especially ones provided by the initial poster in this thread in our documentation is an absolute no go. The reasons are numerous and quite obvious if you have followed the archives. I'm happy to hear progress is being made. Regards, Philip -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Trying to find out where the memory went
Am i then also correct to assume that the output of memory_get_peak_usage is used for determining the memory_limit? Also: after correcting with your new information (zval = 114 bytes instead of 68) I still have a rather large offset: 640952+2165950+114+(276697*114)+(276697*3*114)+2165950 = 131146798 = 125M (not trying to be picky here; I just don't understand) _If_ my calculations are correct then a zval should be approx 216 bytes (excluding string contents): ((24400-640952-2165950-2165950) / 4) / 276697 = 215.9647B Mike On Tue, 2011-06-07 at 19:50 +0200, David Zülke wrote: memory_get_peak_usage() is the maximum amount of memory used by the VM of PHP (but not by some extensions for instance) up until the point where that function is called. So the actual memory usage may be even higher IIRC. But yeah, you're basically right. I've explained in another message why it might be so much more than you expected (zval overhead, basically) David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Callable typehint
Hi! Am I now supposed to create a new thread with [RFC] in the subject, wait for minimum 2 weeks, and then create a poll somewhere on the wiki and create new thread with [VOTE] in subject, and wait for another 2weeks and then if accepted by 50%+1 php.net developer, and 60% of the community votes, then I can commit? Thats the current rules of the game? Not really, we never had 50%+1 rule and I really hope we never will. But the rest is close to what is being currently proposed. -- 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] Trying to find out where the memory went
144 (not 114!) bytes is for an integer; I'm not quite sure what the overheads are for arrays, which token_get_all() produces in abundance :) An empty array seems to occupy 312 bytes of memory. Also, strings have memory allocated in 8 byte increments as far as I know, so 1 eats up 8 bytes, and 12345678901234567 will consume 24 bytes for the raw text, not 17. David On 07.06.2011, at 20:26, Mike van Riel wrote: Am i then also correct to assume that the output of memory_get_peak_usage is used for determining the memory_limit? Also: after correcting with your new information (zval = 114 bytes instead of 68) I still have a rather large offset: 640952+2165950+114+(276697*114)+(276697*3*114)+2165950 = 131146798 = 125M (not trying to be picky here; I just don't understand) _If_ my calculations are correct then a zval should be approx 216 bytes (excluding string contents): ((24400-640952-2165950-2165950) / 4) / 276697 = 215.9647B Mike On Tue, 2011-06-07 at 19:50 +0200, David Zülke wrote: memory_get_peak_usage() is the maximum amount of memory used by the VM of PHP (but not by some extensions for instance) up until the point where that function is called. So the actual memory usage may be even higher IIRC. But yeah, you're basically right. I've explained in another message why it might be so much more than you expected (zval overhead, basically) David smime.p7s Description: S/MIME cryptographic signature
Re: [PHP-DEV] Callable typehint
On 07.06.2011, at 12:09, Jordi Boggiano wrote:
On Tue, Jun 7, 2011 at 1:02 AM, Stas Malyshev smalys...@sugarcrm.com wrote:
Sure. How about reducing boilterplate code like this:
if(is_readable($foo)) {
$var = file_get_contents($foo);
} else {
throw InvalidArgumentException();
}
Why won't we make language construct to do that too? I don't think these
things belong in the language syntax.
The whole point is that callables are generally not constructed from
user input, they're hardcoded in the code somewhere, and so if a fatal
error occurs, the developer notices it, hopefully during development.
With is_readable, a file can be anywhere, anytime, readable or not, it
depends on the environment the code runs on, and not on the code
itself, so it's not deterministic and you should therefore be able to
easily handle this gracefully.
Precisely.
I'd love to see a callable type hint too. And a scalar one while we're at
it ;)
David
smime.p7s
Description: S/MIME cryptographic signature
Re: [PHP-DEV] Callable type
Hi! https://wiki.php.net/rfc/callable It is good there's an RFC. However it seems to lack code examples. I understand it may be obvious to the proposers how it looks like, but it'd be nice to have the actual example there as it is done nearly everywhere else. The patch introduces new zval type IS_CALLABLE but zval functions weren't updated for it - IIRC at least dtor may end up being called on IS_CALLABLE value produced in the parser. Note also that this pseudo-type is called callback in all of our documentation, which means we have now documentation that says: bool array_walk ( array $array , callback $funcname [, mixed $userdata ] ) and type check that says callable. Also, it is not clear what would happen if this type check is made against method which is not accessible (e.g. private out of scope). Would it say that the argument is invalid (which would be really confusing since it'd say something like callable expected, array given which it technically correct but doesn't explain why this array is not callable) or would allow it? If not, then zend_is_callable error information should be used and displayed. And the tests need to cover these cases, along with __call and __callStatic. For me personally it makes zero sense that having just removed strict typing we are introducing it back through back door, but if everybody likes it so be 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] Callable type
On 07.06.2011, at 21:12, Stas Malyshev wrote: Hi! https://wiki.php.net/rfc/callable Note also that this pseudo-type is called callback in all of our documentation, which means we have now documentation that says: bool array_walk ( array $array , callback $funcname [, mixed $userdata ] ) and type check that says callable. Oh, good point. It should be callback then, too, maybe? Or the documentation should be adjusted (which might be a good idea, as $funcname doesn't reflect the realities anymore). David smime.p7s Description: S/MIME cryptographic signature
Re: [PHP-DEV] Callable type
For me personally it makes zero sense that having just removed strict typing we are introducing it back through back door, but if everybody likes it so be it. It's strict typing to have a type-hint that can be matched by 4 different constructs (string function names, arrays, closures, invokable classes)? Basically anything that would succeed in call_user_func would be allowed to pass...? There's no dynamic typing that I'm aware of that this would prevent. Either it's callable, or it's not. No casting or silent type conversion is going to change that. So it's not making typing stricter at all. All it does is allow you to say I want this parameter to be able to be directly called. *What* form of call you give it doesn't matter one bit. So in a sense, it's like having a String type-hint that casts if it can, but throws an error if it can't (Ex: an object without __toString). This will allow if there's a way to call it, and throw an error if not. I'm all for this addition. +1 On Tue, Jun 7, 2011 at 3:12 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! https://wiki.php.net/rfc/callable It is good there's an RFC. However it seems to lack code examples. I understand it may be obvious to the proposers how it looks like, but it'd be nice to have the actual example there as it is done nearly everywhere else. The patch introduces new zval type IS_CALLABLE but zval functions weren't updated for it - IIRC at least dtor may end up being called on IS_CALLABLE value produced in the parser. Note also that this pseudo-type is called callback in all of our documentation, which means we have now documentation that says: bool array_walk ( array $array , callback $funcname [, mixed $userdata ] ) and type check that says callable. Also, it is not clear what would happen if this type check is made against method which is not accessible (e.g. private out of scope). Would it say that the argument is invalid (which would be really confusing since it'd say something like callable expected, array given which it technically correct but doesn't explain why this array is not callable) or would allow it? If not, then zend_is_callable error information should be used and displayed. And the tests need to cover these cases, along with __call and __callStatic. For me personally it makes zero sense that having just removed strict typing we are introducing it back through back door, but if everybody likes it so be 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Callable type
callback is callable, the opposite could not be true. a string --or a closure-- is callable, but the string is not a callback IMHO callable fits better. Martin Scotta On Tue, Jun 7, 2011 at 4:28 PM, David Zülke david.zue...@bitextender.comwrote: On 07.06.2011, at 21:12, Stas Malyshev wrote: Hi! https://wiki.php.net/rfc/callable Note also that this pseudo-type is called callback in all of our documentation, which means we have now documentation that says: bool array_walk ( array $array , callback $funcname [, mixed $userdata ] ) and type check that says callable. Oh, good point. It should be callback then, too, maybe? Or the documentation should be adjusted (which might be a good idea, as $funcname doesn't reflect the realities anymore). David
Re: [PHP-DEV] Callable type
Hi! callback is callable, the opposite could not be true. a string --or a closure-- is callable, but the string is not a callback According to our docs, which were out there for years, it is. One of the main and widespread complaints about PHP is the lack of any system in naming, design and documentation, it is sad to see how many people want to make it worse instead of making it better. -- 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] Callable type
On 07.06.2011, at 22:31, Stas Malyshev wrote: Hi! callback is callable, the opposite could not be true. a string --or a closure-- is callable, but the string is not a callback According to our docs, which were out there for years, it is. One of the main and widespread complaints about PHP is the lack of any system in naming, design and documentation, it is sad to see how many people want to make it worse instead of making it better +1. I'm thinking it should be callback, or the docs should be adjusted. callable arguably does make more sense, but either way, it needs to be consistent, that's what matters most. David smime.p7s Description: S/MIME cryptographic signature
Re: [PHP-DEV] Callable type
hi Stas, I have to say that we should apply our upcoming voting rule here as well. If we don't, pls count -1 from here anyway. Cheers, On Tue, Jun 7, 2011 at 9:12 PM, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! https://wiki.php.net/rfc/callable It is good there's an RFC. However it seems to lack code examples. I understand it may be obvious to the proposers how it looks like, but it'd be nice to have the actual example there as it is done nearly everywhere else. The patch introduces new zval type IS_CALLABLE but zval functions weren't updated for it - IIRC at least dtor may end up being called on IS_CALLABLE value produced in the parser. Note also that this pseudo-type is called callback in all of our documentation, which means we have now documentation that says: bool array_walk ( array $array , callback $funcname [, mixed $userdata ] ) and type check that says callable. Also, it is not clear what would happen if this type check is made against method which is not accessible (e.g. private out of scope). Would it say that the argument is invalid (which would be really confusing since it'd say something like callable expected, array given which it technically correct but doesn't explain why this array is not callable) or would allow it? If not, then zend_is_callable error information should be used and displayed. And the tests need to cover these cases, along with __call and __callStatic. For me personally it makes zero sense that having just removed strict typing we are introducing it back through back door, but if everybody likes it so be 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 -- 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] Callable type
To be honest: everybody knows what you mean when you say callback. Callable sounds more like the name of an interface. On Tue, 2011-06-07 at 22:32 +0200, David Zülke wrote: On 07.06.2011, at 22:31, Stas Malyshev wrote: Hi! callback is callable, the opposite could not be true. a string --or a closure-- is callable, but the string is not a callback According to our docs, which were out there for years, it is. One of the main and widespread complaints about PHP is the lack of any system in naming, design and documentation, it is sad to see how many people want to make it worse instead of making it better +1. I'm thinking it should be callback, or the docs should be adjusted. callable arguably does make more sense, but either way, it needs to be consistent, that's what matters most. David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Callable type
On 2011-06-07, David Zülke david.zue...@bitextender.com wrote: On 07.06.2011, at 22:31, Stas Malyshev wrote: Hi! callback is callable, the opposite could not be true. a string --or a closure-- is callable, but the string is not a callback According to our docs, which were out there for years, it is. One of the main and widespread complaints about PHP is the lack of any system in naming, design and documentation, it is sad to see how many people want to make it worse instead of making it better +1. I'm thinking it should be callback, or the docs should be adjusted. callable arguably does make more sense, but either way, it needs to be consistent, that's what matters most. Agreed, here. callback is the usage throughout the documentation to refer to anything that passes is_callable(). -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Callable type
+1 for callable, it is really more consistent. On Tue, Jun 7, 2011 at 3:44 PM, Matthew Weier O'Phinney weierophin...@php.net wrote: On 2011-06-07, David Zülke david.zue...@bitextender.com wrote: On 07.06.2011, at 22:31, Stas Malyshev wrote: Hi! callback is callable, the opposite could not be true. a string --or a closure-- is callable, but the string is not a callback According to our docs, which were out there for years, it is. One of the main and widespread complaints about PHP is the lack of any system in naming, design and documentation, it is sad to see how many people want to make it worse instead of making it better +1. I'm thinking it should be callback, or the docs should be adjusted. callable arguably does make more sense, but either way, it needs to be consistent, that's what matters most. Agreed, here. callback is the usage throughout the documentation to refer to anything that passes is_callable(). -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Callable type
On 2011-06-07, dukeofgaming dukeofgam...@gmail.com wrote: --0016e68ee3e4bc4b0e04a525bac6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1 for callable, it is really more consistent. I was actually agreeing With David and Stas that callback was more consistent, and casting my vote for that. On Tue, Jun 7, 2011 at 3:44 PM, Matthew Weier O'Phinney weierophin...@php.net wrote: On 2011-06-07, David Z=FClke david.zue...@bitextender.com wrote: On 07.06.2011, at 22:31, Stas Malyshev wrote: callback is callable, the opposite could not be true. a string --or a closure-- is callable, but the string is not a callback According to our docs, which were out there for years, it is. One of the main and widespread complaints about PHP is the lack of any system in naming, design and documentation, it is sad to see how many people want to make it worse instead of making it better +1. I'm thinking it should be callback, or the docs should be adjusted. callable arguably does make more sense, but either way, it needs to be consistent, that's what matters most. Agreed, here. callback is the usage throughout the documentation to refer to anything that passes is_callable(). -- Matthew Weier O'Phinney Project Lead| matt...@zend.com Zend Framework | http://framework.zend.com/ PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bundling modern extensions
On 06/06/2011 10:56 AM, Johannes Schlüter wrote: On Mon, 2011-06-06 at 10:18 -0500, Larry Garfield wrote: The only way, currently, that projects can predict what a given host will have installed is bundled in core PHP. If it's in the core PHP bundle, we can *usually* expect it to be there. If not, we can *usually* presume it won't be. That's not a hard and fast rule, but it's the best we've got right now. While that rule is not true by far. I never said it was a *good* rule. Just that it's the least bad we have right now. In the Drupal project (my home turf) we regularly struggle with debating if we can rely on a certain extension or not given that it's so hard to predict host behavior. Even among dedicated servers, many of my clients wrinkle their brows in confusion when I talk about installing a PECL module more complex than APC. We really do need some predictability in this market. Unless we start a certification program (PHP Certified Hoster .. demanding some specific features etc.) there's little we can do. And I doubt we want to do that ;-) If I had the time I'd consider it, frankly. We did manage to force the issue with PHP 5.2 with the GoPHP5 project. I once considered expanding its scope but never really had the time/energy to drive it. One day[tm] I plan to make all this data public with a simple query interface. I'd also be interested in adding such a data collection to other software. If you're interested feel free to contact me of list. johannes I am interested, actually. Stand by. :-) --Larry Garfield -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Callable type
On Tue, Jun 7, 2011 at 4:41 PM, Matthew Weier O'Phinney weierophin...@php.net wrote: On 2011-06-07, dukeofgaming dukeofgam...@gmail.com wrote: --0016e68ee3e4bc4b0e04a525bac6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1 for callable, it is really more consistent. I was actually agreeing With David and Stas that callback was more consistent, and casting my vote for that. Oh. But then, shouldn't is_callable be deprecated for a more consistently named is_callback? Regards, David
Re: [PHP-DEV] Callable type
On Tue, 2011-06-07 at 12:12 -0700, Stas Malyshev wrote:
Hi!
https://wiki.php.net/rfc/callable
It is good there's an RFC. However it seems to lack code examples. I
understand it may be obvious to the proposers how it looks like, but
it'd be nice to have the actual example there as it is done nearly
everywhere else.
The RFC is missing information about what happens in codebases which
already have a callable type declared. Will that be prevented or will
they hit a runtime error? (callable expected, callable type found)
What about default values? Will
function foo(callback $cb = 'strpos') { }
be valid?
The information on reflection is limited. what shall
Reflection::Parameter::getTypehint() return? Will that method allow to
differ between a class type and this magic?
What about ARGINFO? Will internal functions be able to define this type
via ARGINFO? How will this be reported in `php --rf function`?
johannes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bundling modern extensions
2011/6/7 Johannes Schlüter johan...@schlueters.de: That's why there are package managers or the windows Installer bundling some PECL stuff (or MSFT's Web Installer thingy) The msft thingy as you call it does not support update and is a simple wrapper around our own installer (which uses MSI). We (php-win) would like however to provide such tool on windows, to install the binaries for php's extension as well as updating php itself, totally or what is necessary (updated library or extension for example, besides the main php releases). That's on the list for the next months. 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] Trying to find out where the memory went
On Tue, 2011-06-07 at 21:03 +0200, David Zülke wrote: 144 (not 114!) bytes is for an integer; I'm not quite sure what the overheads are for arrays, which token_get_all() produces in abundance :) An empty array seems to occupy 312 bytes of memory. Also, strings have memory allocated in 8 byte increments as far as I know, so 1 eats up 8 bytes, and 12345678901234567 will consume 24 bytes for the raw text, not 17. I'm too lazy to do the actual math (well best would be to do sizeof(zval), sizeof(HashTable), sizeof(Bucket) on your system) and there are few things to consider: * The sizes are different from 32 bit and 64bit; with 64bit there's a difference between Windows and Unix/Linux (on Win a long will still be 32 bit, but pointers 64 bit, on Linux/Unix both are 64bit) * On some architectures memory segments have to be aligned in some way which might waste memory * As David mentioned HashTables (Arrays) are more complex. * token_get_all() returns an array of (string | array of (long, string, long) ) * A long takes sizeof(zval) * A string takes sizeof(zval)+strlen()+1 * and array is a HashTable + space for buckets, this includes place for some not used elements * Each element inside the HT needs additional space for a Bucket with some meta data * While running your script you also keep the complete script file in memory. You also keep some temporary parser data in memory while the resulting array is being filled. In the end it's not fully trivial to gather the size needed. And I'm sure my list is missing lts of things. http://schlueters.de/blog/archives/142-HashTables.html has an short introduction to HashTables. Skipping many of the details. johannes David On 07.06.2011, at 20:26, Mike van Riel wrote: Am i then also correct to assume that the output of memory_get_peak_usage is used for determining the memory_limit? Also: after correcting with your new information (zval = 114 bytes instead of 68) I still have a rather large offset: 640952+2165950+114+(276697*114)+(276697*3*114)+2165950 = 131146798 = 125M (not trying to be picky here; I just don't understand) _If_ my calculations are correct then a zval should be approx 216 bytes (excluding string contents): ((24400-640952-2165950-2165950) / 4) / 276697 = 215.9647B Mike On Tue, 2011-06-07 at 19:50 +0200, David Zülke wrote: memory_get_peak_usage() is the maximum amount of memory used by the VM of PHP (but not by some extensions for instance) up until the point where that function is called. So the actual memory usage may be even higher IIRC. But yeah, you're basically right. I've explained in another message why it might be so much more than you expected (zval overhead, basically) David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Callable type
On 08.06.2011, at 00:38, dukeofgaming wrote: On Tue, Jun 7, 2011 at 4:41 PM, Matthew Weier O'Phinney weierophin...@php.net wrote: On 2011-06-07, dukeofgaming dukeofgam...@gmail.com wrote: +1 for callable, it is really more consistent. I was actually agreeing With David and Stas that callback was more consistent, and casting my vote for that. Oh. But then, shouldn't is_callable be deprecated for a more consistently named is_callback? No, because is_callable() also performs visibility checks. Which of course begs the question... should the type hint do the same? David smime.p7s Description: S/MIME cryptographic signature
Re: [PHP-DEV] Callable type
2011/6/8 David Zülke david.zue...@bitextender.com:
On 08.06.2011, at 00:38, dukeofgaming wrote:
On Tue, Jun 7, 2011 at 4:41 PM, Matthew Weier O'Phinney
weierophin...@php.net wrote:
On 2011-06-07, dukeofgaming dukeofgam...@gmail.com wrote:
+1 for callable, it is really more consistent.
I was actually agreeing With David and Stas that callback was more
consistent, and casting my vote for that.
Oh. But then, shouldn't is_callable be deprecated for a more consistently
named is_callback?
No, because is_callable() also performs visibility checks.
Which of course begs the question... should the type hint do the same?
David
+1 to callback (and have mercy on docs/translation people, it's too
much work to search/replace for such a minor difference :))
And yes, two similar terms (callback/callable) will make situation worse.
Plus to Johanness question: will it add runtime performance overhead
on code like this:
function(callback $callback = 'non_existent_function') {}
--
Regards,
Shein Alexey
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
