RE: [PHP-DEV] PHP Package for PHP
> I have worked with PHP for 14 years now and I know nothing about PEAR. It > either says something about me or about PEAR. Then the next logical question would be do you know what PECL is? :) But to be short my point is - before attempting to get new function(ality) in core it (seems to me) that more realistic if you really want to achieve that is at least by presenting some kind of working base blocks especially when there are all the means to extend the language both on low level (being an extension) or a pure-php package in any of the existing channels (composer / push for repopulation of PEAR? etc). There is usually the argument - "if this is not in core no one (people on shared environments/hosting) won't be able to use it" and so on.. The counter to that are things like Imagick / redis / memcache(d) / APCu which are vastly popular but still live outside core (obviously those are not language rather than engine features). rr -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
RE: [PHP-DEV] PHP Package for PHP
> Which begs the question of a PHP Package for PHP. Some benefits: > > - Written in PHP, it will allow a much wider pool of contributors than the scarce pool of C developers contributing to PHP source code. Aren't this what frameworks are for (Laravel / Yii / Symfony / Zend etc)? Or PEAR? Like that particular path_join() request is exactly https://pear.php.net/package/File_Util/docs/latest/File/File_Util/File_Util.html#methodbuildPath rr -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
RE: [PHP-DEV] Moving PHP internals to GitHub
> Oftentimes community discussions are happening in parallel to the internal > discussions on the PHP reddit. > As is the same for this discussion, reading it is often useful to get > community input. > https://old.reddit.com/r/PHP/comments/12jrc8j/the_discussion_on_the_mailing_list_about_moving/ Sadly, there isn't anything useful being discussed just some people being upset about why someone doesn't (immediately) want to move to their [favorite] platform what gives even more validation for those who are against it. p.s. also excuses like "gmail is making me top-post and that why I can't write to internals" make me sad .. what have we come to / what's in the future .. rr -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
RE: [PHP-DEV] Long-Term Planning for PHP 9.0 Error Promotion
> Any type error should if you ask me. Unexpected types cause unexpected > behavior, and the longer PHP will try to continue with assumptions of types > and implicit casting, the bigger the damage can be. All this type juggling is > headache material and the less I see of it, the better. Sorry for derailing, but out of interest - why choose a loosely typed language in the first place then? rr -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
RE: [PHP-DEV] About the use of the terms master/slave and blacklist, proposal to replace.
> Last, regarding neutrality. This proposal is literally aimed at adopting > more- > neutral language. It's not a partisan move to say that harmful language > should be avoided. The problem (imo) is projecting/tying relations and social interactions (past and present) between people onto machine code (and nowadays also everything else) instead of explaining that there is no connection (the idea itself to declare that black is bad and white good for everything is absurd (was mentioned as an argument) - different cultures/nations have wildly wide range symbolisms regarding colors and now for some reason there is suddenly only one?). But if current (php) code is considered harmful/offending the next proposal/rfc should be to remove every "kill child/parent" fpm (possibly other sapis) /pcntl,posix (kill_children() from the tests) also die() and *_execute etc. as no sane person would agree that it's even remotely normal not to say more. rr -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] About the use of the terms master/slave and blacklist, proposal to replace.
> The word "master" has 18 meanings in English, according to > https://en.m.wiktionary.org/wiki/master - do you propose to outlaw those > 17 of them that have nothing to do with slavery, too? What about master's > degree, for example? > I wonder what will astronomers do with 'black hole' .. p.s. or physicists with 'white noise'. Also what happens when someone decides 'whitespace' to be racist .. Crazy times. rr -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Are PECL modules preferable?
> -Original Message- > From: Mike Schinkel > > That is a utopian sentiment, but not valid in the corporate world that uses > managed hosting because they are focused on operating their business and > not on having to spend time, resources and management expertise in > securing and running servers on the Internet. Not sure if using "corporate world" in this argument is good either. "Corporate world" typically doesn't want to change anything hence ~50% of the world still runs on PHP5. You will probably get more usage/adoption of the particular new feature in a php5/7 compatible php pecl extension rather than waiting for a managed hosting to upgrade to PHP 8/NEXT (see something like imagick, memcache or redis - not in a core at all, but probably rarely any host without those). As for the "ensures many PHP developers will _never_ have access to them" - nowadays when everything can run in containerized environments where you can setup/configure php in whatever manner you like or the software needs, it usually isn't a problem anymore. rr -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Constraints and userland@
> -Original Message- > From: Benjamin Morel [mailto:benjamin.mo...@gmail.com] > > > And we could change the RFC process to either: > > - require a 2/3 majority of votes *in each category* > - *or *require a 2/3 majority in the *average of all three categories* > - *or *give a weight to each category (like 50% to core members, 30% to OSS > developers and 20% to the rest of the world) and calculate the result > accordingly > - *or even* something like require a 2/3 majority in at least 2 of these > categories > > ... or any other rule we could think of. > > I quite like this idea of splitting voters into 3 categories, where each > category > has a weight that does not depend on the number of people who voted inside > it. > > Something like this would seem fair to me. Thoughts? The problem in this is that - what good is a vote/RFC if no one is there to implement it? Like you could get and overwhelming majority/weight in all the non-developer groups but what then? Are you then forcing someone to write the code? Pick someone from the group(s) who voted for or pay someone to do it (quite valid though)? IMO even now all the discussion in the internals@ (hence the name) for the developer (RFC author) is just to see if any other code contributor has something to say about his idea. The rest can voice their concerns but as long you don't really contribute yourself I doubt you get to choose in the end.. rr -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Deprecate Backtick Operator (V2)
> -Original Message- > From: Benjamin Morel [mailto:benjamin.mo...@gmail.com] > > One gain that's very often overlooked on this list, is teaching a better PHP > to > new generations. It IS confusing if PHP has more than one way to do one thing, Not directly related to this RFC but out of curiosity - where does this "doing the same thing in multiple ways is confusing" comes from? (I mean this as serious question) I had the impression that programming in essence is all about that - achieving/accomplishing something/the same different ways? Because then you have to question a lot of things (not saying it's a bad thing) - like for example why does heredoc <<< (or nowdoc) exist when we have =, .= (also probably won't be found in most if any popular/public projects, libraries) and so on.. (While extreme) then dropping PHP just because there are 10 other programming languages that do the same thing (or even better) also becomes an argument because it is kind of "confusing for new generations" to pick and choose which one is better (Which one is more easy? Which uses less system resources/is faster? Where do you get more salary as employee? Etc)? p.s. sorry for offtopic rr -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Deprecate Backtick Operator (V2)
> -Original Message- > From: Mark Randall [mailto:marand...@php.net] > > On 06/10/2019 14:18, Reinis Rozitis wrote: > > Since `` are used for literal strings (for poorly chosen reserved words as > > field, > table names (which happens from time to time)) in MySQL (multiline) queries I > doubt there is a simple way to distinguish and replace everything to exec(). > > Hi, > > As the RFC states, there are already widely used tools available which can do > this reliably: > > https://github.com/FriendsOfPHP/PHP-CS-Fixer > backtick_to_shell_exec > > -- > Mark Randall Sure, it was only a comment about "without huge Regex searches" from previous poster while the tool has those "tricky" parts https://github.com/FriendsOfPHP/PHP-CS-Fixer/blob/2.15/src/Fixer/Alias/BacktickToShellExecFixer.php (hence the help message and comments inside code) rr -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Deprecate Backtick Operator (V2)
> -Original Message- > From: Olumide Samson [mailto:oludons...@gmail.com] > > it should be deprecated for exec usage since they both do same thing With that logic This isn't high cost breaking changes coz it has a verifiable, ready > alternative to upgrade to without huge Regex searches. Since `` are used for literal strings (for poorly chosen reserved words as field, table names (which happens from time to time)) in MySQL (multiline) queries I doubt there is a simple way to distinguish and replace everything to exec(). rr -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Reclassifying engine warnings
> "It's like our company car still works, but it no longer tighter meets > emissions > standards so they won't let us take it into the city any more" That's a very interesting way to describe error level changes of a language. I wonder what happens when the manager asks - "What's with those guys who bought python/java trucks, go-carts? Do they also have these co2 problems?" Sorry for offtopic .. On a semi related note if the idea/discussion/RFC is for a betterment of language and future regarding warning/errors, it has always puzzled me: - why the engine is so minimalistic/unspecified regarding max_input_vars where the error is just "php-fpm: PHP Warning: Unknown: Input variables exceeded 1000. To increase the limit change max_input_vars in php.ini. in Unknown on line 0" which isn't very helpful. Also is E_WARNING enough in this case since the variables are forcefully truncated? - and the second is memory_limit which again without any external tooling and/or debug mode while shows the file and line doesn't actually produce meaningful error/backtrace to indicate the problematic part (especially in production environments) We have patched the zend_alloc (in a rough way by searching through symbol_table for fastcgi params) to print more details at least in the fpm-sapi to be able to replicate the issue more easily, but then again I doubt it's the right way to do so.. While the second is hardly related (except the fact it's some sort of programming error condition) doesn't the first one need the same reclassification of error level as undefined variables? rr -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Deprecate PHP's short open tags, again
> Please, let's keep this discussion at some level of sanity... You basically > need > stick to static HTML if you're considering possibility of such exec() usage > as a > security issue. This discussion has gone out of sanity levels the moment people started to state that short tags is one (of the many) things PHP has why new programmers and companies don't pick the language or why colleagues laugh at you and is a blocker of new bright future etc. and now in this moment this is a do or die situation otherways next year everyone will be writing in javascript. > 1. exec-like functions have their purpose without any straight-forward > alternative, while ` `` is intended usage of short open tags. On this I could also say that recommendations are to store all credentials outside webroot, but again it also qualify as something different than by accident generated code in IDE, just to show that the "security issue" can be stretched however you like. > You basically need stick to static HTML Maybe. But let's end at this .. rr -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Deprecate PHP's short open tags, again
> Honestly, I don't see how allowing exec/passthru/proc_open is a security risk. > These are just tools. We're talking about programming language - if you're > running PHP script as user X you should expect that it could do anything that > user > X can do. If you don't trust this script, just don't run it Depends on how you look at if exec($_GET['param']) is a language responsibility or programmers? On the same level you can then expect that programmer X always uses ' https://www.php.net/manual/en/language.basic-syntax.phptags.php > > "PHP also allows for short open tag available if enabled using the short_open_tag php.ini configuration file > directive, > or if PHP was configured with the --enable-short-tags option)." Which is actually the other way around - enabled by default / disabled if configured via ini. It feels most people who argue about the feature (are not in the burn it with fire and everyone who uses them should just go away) would be fine (enough) if it aligned to what's written in the documentation and then make deliberate decision to enable those. rr -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Deprecate PHP's short open tags, again
> This is about accidental usage of *language* feature, which *by design* can > lead to code leaks (so application bug, not misconfigured environment). > Clearly not a language problem that it has dedicated feature to shoot > yourself in the foot... > > These methods have their purpose (pretty important BTW), short open tags is > just "don't use it!!!" feature. Sure those are important - I was just pointing out that the "security card" is questionable since the language has more dangerous features which ask for the user to be careful and responsible about them rather than making everything foolproof and accident-free. Also it's not by design - the only way code can leak is when it has been using 'http://www.php.net/unsub.php
RE: [PHP-DEV] Deprecate PHP's short open tags, again
> It is surprising how thing that is considered by one to be a security risk, > is treated > as nothing relevant by others. This dichotomy is quite disturbing - in what > case > removing security risk is "no real gain"? It's questionable that a misconfigured environment is a "security" risk caused by language rather than ignorance of the administrator. On that matter you could ask why are all the exec/passthru/proc_open etc functions/features are allowed by default while every other guide on hardening web suggests those to be disabled (added to disable_functions)? I would bet there have been a lot more (actual) security breaches because of unsanitized/unescaped parameters to those. Just to repeat some other people - there are a lot other things to work on than this. rr -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again
> This does not explain how someone could use that feature *by accident*. I gave > an example where you can use short open tags by accident, and it is really > easy > (the most popular IDE sometimes generates code with short open tags) and hard > to notice (it is not easy to spot a difference between ` can > you compare this to situation when you create a separate file with an explicit > directive to disable PHP engine, and then be surprised that code is not > executed? Disabling short tags now is done with "an explicit directive" (there has to be a specific ini file with a specific setting 'short_open_tag = 0'). Isn't this the same "situation when you create a separate file with an explicit directive"? If a coder (or IDE) has written 'http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again
> -Original Message- > From: Robert Korulczyk [mailto:rob...@korulczyk.pl] > > > Can you give an example where using `.user.ini` may create unexpected and hard > to notice code leaks? I did mention such example with the 'engine' setting ( https://www.php.net/manual/en/apache.configuration.php#ini.engine as it's PHP_INI_ALL ). Of course you could ask why would anyone do that (and afaik it's sapi specific) but technically it can happen just in one "hard to notice" subdirectory/tree. Note that atm short_tags are by default enabled and the disable happens only in php(-cli).ini so unless one throws the ini configuration files around willy nilly it is a deliberate decision from administrator. p.s. to clarify I'm not against changing the default value to disabled (to be consistent with the distributed ini-examples and (coding) recommendations) but I still don't understand what is the reason to deny for end-users the ability to change/re-enable this feature if they need it and choose so. But according to some emails for some reasons the existence of short tags now has turned out to be a major language future/feature blocker .. so go figure. rr -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again
> -Original Message- > From: Bishop Bettini [mailto:bis...@php.net] > > That's why I highlighted Robert Korulczyk's case study: only a particular > code path in a particular environment had the problem. > > The status quo enables deployments to fail insecurely. "secret"; is a trap waiting to spring. I would rather require ten thousand > people secure their environment by running a script, than risk a single person > exposing their credentials for all to steal. > > I challenge everyone who's voted no to consider this balance. If the initial RFC would have been accepted as is (without the later proposed changes after the lengthy discussion) you would have sprung the same "trap" as in that particular case study - code would be exposed. Argument for "only a particular code path in a particular environment" is somewhat weak because in that case why does even ' .user.ini' feature exists (especially in apache sapi where you can even do engine = 0) as it also can lead to wildly different language behaviour? rr -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again
> -Original Message- > From: Brent [mailto:bre...@stitcher.io] > > > It feels like much of the counter arguments are based on guesses without any > real data to point to. It goes both ways - the argument for removal states "This means that their use is not possible in portable code, because the code author does not necessarily have the necessary control over the configuration". What is the number/statistics of developers which have written a portable (in their mind) code (which means NOT using short tags) just to find out that the code/application doesn't work because those are disabled? Is there real data for that? rr -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again
> -Original Message- > From: Côme Chilliet [mailto:c...@opensides.be] > > This is what bugs me, the counter argument page from Zeev states «I never > use short tags in any PHP code that I write, and as far as I recall - I never > have. », and at the same time «put hundreds of thousands of people > through additional pain when upgrading.» Why does/should it bug you? The statements aren't contradictory. There are (must be) a lot of features which a particular language developer might not use (or even find ridiculous) himself personally but those still have been implemented historically or for future use for other users/clients etc. > Did anyone in this discussion stated that he was using them? Yes. rr -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] [DISCUSSION] Deprecate PHP's short open tags V2
> First, short_open_tag is an ini setting that control core language syntax. > This means that their use is not possible in portable code, because the code > author does not necessarily have the necessary control over the configuration > of the deployment environment. While this RFC is a much better way of deprecating the feature (looking at the previous votes it most likely will happen), the reasoning/text (main point) is still odd: - if the code author wants a portable code he HAS the necessary control over it and can always follow the coding guidelines and write it using 'http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags
> -Original Message- > From: Marco Pivetta [mailto:ocram...@gmail.com] > > Also a good chance to finally take a look at code that has been rotting in a > hard > drive for too much time. It's an odd way of justifying a BC break by saying "you can write this one-liner sed or use this third-party tool to alter you code" exactly the same way every backwards incompatible change can be fixed then .. and then it makes no sense to even discuss. At the beginning of the proposal it was asked (on mailinglist) if the change has any impact on performance (php runs faster/language parses becomes substantially simple etc), if there are any security issues (like with magic quotes) or maybe similarly as with different extensions there is no one to support the code anymore. But in the end there is only the 'http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags
> A 68% majority which barely clears the 2/3 requirements for something as > fundamental as that - with so many core devs against it - we'll deserve all > the > criticism that will be coming our way in 7.4/8.0 from end users wondering why > we needlessly broke their apps and made migration a bit more of a headache. It's quite interesting to check the karma levels for the voters (might be on a slippery slope here but it feels a bit unfair that someone with just a documentation karma (or no karma at all (at least according to wiki.php.net)) has the same weight on a core option getting removed). p.s. at least for the deprecation stage for 7.4 the revert patch is simple rr -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags
> From: Robert Korulczyk [mailto:rob...@korulczyk.pl] > > Personally, I'm surprised by the controversy around this change. So far it > was an > obvious anti-pattern for me, and never seen anybody who was aware of the > consequences of using http://www.php.net/unsub.php
RE: [PHP-DEV] [RFC] Deprecate PHP's short open tags
> I would like to start the discussion about the deprecation of PHP's short open > tags: > https://wiki.php.net/rfc/deprecate_php_short_tags Hi, I did read the initial thread about this and now the RFC and it doesn't really state what is the reason of removing the short tags besides this one line: "PHP has provided over the years different ways to indicate the beginning of PHP code other than the standard " Is there a (noticeable) speed improvement or does it make the parser/engine more simple? Is it wrong to provide different ways to indicate the start of php code? Since the short 'https://w3techs.com/technologies/details/pl-php/all/all rr -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Mysql result data types
> who forces you to ext/mysql? It's out of topic but obviously the code/software and products on the servers. For me as a system administrator I have choice either to never upgrade (for example https://w3techs.com/technologies/details/pl-php/all/all one can see the rough rate of php version adoption) or work around the issues/lack of features in the deprecated stuff (or answer why I broke everything). While I prefer bleeding edge it's not always an option (to force everyone) and in general 7.1+ext/mysql+mysqlnd works just fine. rr -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Mysql result data types
> no idea what the state of PDO is > > > http://blog.ulf-wendel.de/2008/php-new-network-traffic-cpu-and-memory- > savings-with-mysqlnd/ > >if(mysqli_options($this->conn, MYSQLI_OPT_INT_AND_FLOAT_NATIVE, Thanks, as we still partly (forced to) live in the "deprecated or moved to pecl" ext/mysql world this gave the idea to actually implement the int_and_float_native into the extension rather than alter the driver (which apparently already has such functionality). rr -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Mysql result data types
Hello,
is there a reason (technical or historical) why the data coming from MySQL is
always strings?
I've found only one case where the data type is "honored" -
PDO+mysqlnd+emulation off [1]
We made a fairly simple patch to 'mysqlnd' which enables (configurable via ini)
data to be returned (trying to match) as defined in database/table.
In general something like:
switch( field->type ){
case MYSQL_TYPE_TINY:
case MYSQL_TYPE_SHORT:
case MYSQL_TYPE_LONG:
case MYSQL_TYPE_LONGLONG:
case MYSQL_TYPE_INT24:
convert_to_long(data);
break;
case MYSQL_TYPE_DECIMAL:
case MYSQL_TYPE_DOUBLE:
case MYSQL_TYPE_FLOAT:
case MYSQL_TYPE_NEWDECIMAL:
convert_to_double(data);
break;
}
Does it make sense to create a PR and/or RFC for something like this?
[1] https://phpdelusions.net/pdo#returntypes
wbr
Reinis Rozitis
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] New operator for context-dependent escaping
From: Michael Vostrikov The problem is that these functions should be called everywhere manually, and there is no error when these functions are not called. And this RFC proposes a solution - call a function automatically. Though you can use pecl/taint for that. If anything imo it would make more sense to propose/vote for such functionality to be included in core. rr -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?
Again, why can't we just bypass this whole argument by adding a configure option? Something like --date.default_timezone=America/Los_Angeles? It could then build that in so it'll assume that if there's no php.ini or if it's just not set in there. Problem solved, everybody's use-case covered. If you build php yourself from source there is always the option to throw (comment out) that one particular E_WARNING line ext/date/php_date.c.(that is something I do for example for mysqlnd which complains about non-existing character set on older sphinxsearch instances). But if the OP is annoyed by typing php -d date.timezone=... myfile.php each time he could just make an alias (or doskey in win environment). rr -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [VOTE] ext/mysql deprecation in 5.5
From: Patrick ALLAERT Sorry, but removing the E_DEPRECATED notice when moved to PECL is not part of the proposed RFC and should certainly not happen. I don't get what is the reason behind it? Yes, the extension is old but it still works perfectly fine and even outperforms the newer mysqli/pdo in some cases and noone will rewrite the legacy apps - so why is there such a hate (I must say) for ISPs and platform providers? If you insist on throwing errors in external pecl extension for me as a server farm administrator it won't leave any choice but to edit the extension code / build custom distro package before putting it on production. rr -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: ext/mysql deprecation
Rewriting perfectly functional mysql code to use mysqli is not a trivial move, just as are the problems of re-writing PHP5.2 code to work cleanly on 5.4. ISP's are stuck between keeping customers - who are most likely not even very computer literate - working while fighting the problems that changes such as removing mysql will cause them. I wonder if there have been any plans or suggestions (while dropping the old ext/mysql code) to provide some sort of seamless migration/alternatives (similar way it has been done in case of libmysql and mysqlnd)? In short - just aliasing the old mysql_* to mysqli_* functions (as most used like _query, _fetch_row/assoc have just mixed variable order)? rr -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Socket activation support for PHP-FPM
In short, this allows spawning a PHP-FPM pool on-demand with systemd initializing the main socket. What would be the advantage on using systemd instead of using FPMs native 'ondemand' process manager? rr -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] One suggestion to PHP-FPM
Let's start from the beginning. How are you going to detect how much memory a thread consumes? no ideas There is an old patch in the Zends PAT directory http://devzone.zend.com/content/patch/pat38.txt (it reads the /proc/pid though or fallbacks to getrusage). Have used this for quite a time in past but got to conclusion that just finetuning the max_requests setting works better even with leaking code/extensions as the small leaks get _fixed_ when the child restarts but for the big ones (like imagemagick used to be) killing the child each time is rarely any solution either. Of course the option to make the childs permanent and from time to time check the memusage could be usefull. rr -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FPM is available in a separate SVN branch
- See if the normal libevent or libev could handle all the needs and not a patched copy anymore (or get with the libevent team) Isn't this is allready done since 0.6.x fpm? Afaik php-fpm needs external libevent on system now. - Adaptive process support (the major thing lacking) Somewhat done with the 'apache-like' spawning mechanism? rr -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FPM is available in a separate SVN branch
Correct. Biggest lacking feature. While this maybe a bit out of topic, but just out of curiosity why do you think that adaptive spawning is any good (trying to run more processes in given time period than started) - stepping back to how apache operates with its prefork mechanism (iirc there are even people from php-dev community which suggested running apache with start/maxservers identical so there is always constant number of childs (for php processing) to avoid unwanted/unexpected resource consumption? There should be reasons why it was also dropped from the other external process manager lighty/spawn-fcgi and never planned in webservers like nginx .. I would rather want to see one day php (master process) return FCGI_OVERLOADED for the webserver/application to decide what to do next. rr -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FastCGI limit memory
For example lighttpd according to NetCraft: 01.2007 lighttpd 172819 02.2007 lighttpd 702712 You should wait march, such a jump is suspect :) --Pierre Hello Pierre, 03.2007 lighttpd 1.399.786 http://survey.netcraft.com/Reports/0703/ This gives place 4, right behind Sun (if you skip 'unknown'). Still quite a small percentage from the overal pool but the growth remains ;) What brings back my question about the possibility to enforce php fastcgi childs max allowed memory (on the process itself). rr -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FastCGI limit memory
Andi Gutmans wrote: Yeah but process limits are inherited after fork(). Well probably. But does there exists a configurable limit in php for that (which was implemented by previos mentioned patch in 4.x branch)? As if the child exceeds the limit it handles the last request and shuts down to be respawned by master. Killing the process from outside doesnt sound like a nice solution. rr -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mod_fast_apache, FastCGI, and mysqli
Christopher Jones wrote: I guess MySQL folks are also looking into Java like connection pooling: http://krow.livejournal.com/487174.html Besides there are some third-party solutions like SQLRelay http://sqlrelay.sourceforge.net/ rr -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FastCGI limit memory
Andi Gutmans wrote: Don't the FastCGI processes inherit memory limits from their parent? (assuming you're not running standalone FastCGI which almost noone does). Nope, the parent (master) process only keeps the track of active childs (usually I spawn like 250 of them) and distributes the incoming requests. As far as I understand each child operates on its own. rr -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] FastCGI limit memory
Hello, is there a chance that this will ever make in PHP5 (or othet future releases) as base feature http://www.zend.com/zend/week/pat/pat48.txt That is besides PHP_FCGI_MAX_REQUESTS to have also the posibility limit the childs max memory usage/leak (PHP_FCGI_MAX_RAM_MB) I'm asking about this just because yesterday while testing MagickWand ( http://www.magickwand.org which according to Thomas Boutell http://marc.theaimsgroup.com/?l=php-devm=115698025320619 in some point should replace GD) just by accident discovered a huge leak in phpinfo() output of the extension. Just by running some 100-1000 requests each of the php childs (10 total) memory usage grew up to ~1Gb but thats not the point (I'll try to valgrind and isolate the problem and send the bug to the MW developers). My point is - although 5.2.x core has become much much better in memory management (4.4.x actually didnt really work without the patch) you can't say that there are no leaks in longer time span in all the bundled and not bundled extensions. And although apache with its prefork is still a leader a lot of webservers which run php in fastcgi mode are getting more and more popular. For example lighttpd according to NetCraft: 01.2007 lighttpd 172819 02.2007 lighttpd 702712 Besides looking at http://survey.netcraft.com/Reports/0702/ those which I know ( Zeus, lighttpd, nginx, LiteSpeed, Sun One) pretty all run PHP using fastcgi. So how about it? rr -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FastCGI limit memory
It will never replace the GD extension. Please read the whole thread before making conclusions (btw, check out http://www.libgd.org). I didnt mean that way nor as a conclusion, GD is still much faster and so on (but thanks for the link/hint). It was just an excuse why did I play with magickwand (what Thomas proposed) in case somebody would ask why there is a need for such feature and just respond with we dont support third-party extension.. if it breaks core then its your own fault ;) Aye the lighty stats look fishy (lets wait march) but whatever its something Netcraft provides.. Besides getting comments on all other parts but not the initial question? :) rr -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] FastCGI limit memory
I'm not sure that you are looking at the right place to solve the problem. If the leaks are in phpinfo (or in memory allocated by php), then maybe (really not sure). But if the leaks are in IM as their extension does not use php memory manage, it is not something fixable by php or anything else but IM. Pierre you are getting me totally wrong. I dont really care for this particular ImageMagick(Wand) or even phpinfo leak at all :) What I am talking about is a feature which similar as 'memory_limit' (inside one script runtime) limits maximum memory usage for a long running php child (if spawned with the -b option (external FASTCGI Server mode)). At the moment the only option to avoid memory leaks is to set PHP_FCGI_MAX_REQUESTS after which the child dies and a new is spawned. Still the memory usage can grow (as example in this case) way too quick to actually hit the request limit, which may bring the system in OOM state. The patch was provided for 4.x branch http://www.zend.com/zend/week/pat/pat48.txt So I wanted to get some feebacks (without filling the feature request at bugs.php.net which I apologise for) if its something worth to implement. Probably to hear something from Dmitry. Keep an eye on the current 2.1.0 development, it will be really fast :) Is the source allready available for testing? Those 3 remaining tasks in roadmap didnt look problematic at this state (though I suppose there are more issues).. rr -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] include_once
Hello, just a quick question - will the include_once() (Optimized require_once() and include_once() by eliminating fopen(3) on second usage. (Dmitry)) optimisation fix in 5.2.0 backported also in PHP 4 tree (in 4.4.5 maybe?) Theoretically speaking (havent checked the default funcs internal changes between 4.x and 5.2) could it be possible to patch 4.x without breaking the rest of the core? rr -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] include_once
No, no features will be back ported to PHP 4.4. Although I dont see this as feature more like a fix (uneeded opens() stats() on each call) still thank you for the fast reply. p.s. lately the topics and discussions on internal list are pretty scarry.. starting with political issues and ending with memory manager flaws (besides also some phparchitect articles which propose/show 5.2 being faster in all generic tests still slower in realworld aplications).. which probably makes a lot (at least me) users uneasy about switching to the 5.2.x tree :) rr -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
