RE: [PHP-DEV] PHP Package for PHP

2023-05-18 Thread Reinis Rozitis
> 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)

RE: [PHP-DEV] PHP Package for PHP

2023-05-18 Thread Reinis Rozitis
> 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

RE: [PHP-DEV] Moving PHP internals to GitHub

2023-04-12 Thread Reinis Rozitis
> 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. >

RE: [PHP-DEV] Long-Term Planning for PHP 9.0 Error Promotion

2022-01-28 Thread Reinis Rozitis
> 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

RE: [PHP-DEV] About the use of the terms master/slave and blacklist, proposal to replace.

2020-06-15 Thread Reinis Rozitis
> 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

RE: [PHP-DEV] About the use of the terms master/slave and blacklist, proposal to replace.

2020-06-15 Thread Reinis Rozitis
> 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' ..

RE: [PHP-DEV] Are PECL modules preferable?

2020-03-23 Thread Reinis Rozitis
> -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

RE: [PHP-DEV] Constraints and userland@

2019-10-10 Thread Reinis Rozitis
> -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

RE: [PHP-DEV] [RFC] Deprecate Backtick Operator (V2)

2019-10-08 Thread Reinis Rozitis
> -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

RE: [PHP-DEV] [RFC] Deprecate Backtick Operator (V2)

2019-10-07 Thread Reinis Rozitis
> -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

RE: [PHP-DEV] [RFC] Deprecate Backtick Operator (V2)

2019-10-06 Thread Reinis Rozitis
> -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

RE: [PHP-DEV] [RFC] Reclassifying engine warnings

2019-08-28 Thread Reinis Rozitis
> "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

RE: [PHP-DEV] Deprecate PHP's short open tags, again

2019-08-14 Thread Reinis Rozitis
> 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

RE: [PHP-DEV] Deprecate PHP's short open tags, again

2019-08-14 Thread Reinis Rozitis
> 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

RE: [PHP-DEV] Deprecate PHP's short open tags, again

2019-08-14 Thread Reinis Rozitis
> 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

RE: [PHP-DEV] Deprecate PHP's short open tags, again

2019-08-14 Thread Reinis Rozitis
> 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

RE: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

2019-08-09 Thread Reinis Rozitis
> 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

RE: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

2019-08-09 Thread Reinis Rozitis
> -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 (

RE: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

2019-08-08 Thread Reinis Rozitis
> -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

RE: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

2019-08-08 Thread Reinis Rozitis
> -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,

RE: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags, again

2019-08-08 Thread Reinis Rozitis
> -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

RE: [PHP-DEV] [RFC] [DISCUSSION] Deprecate PHP's short open tags V2

2019-07-23 Thread Reinis Rozitis
> 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

RE: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags

2019-04-24 Thread Reinis Rozitis
> -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

RE: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags

2019-04-24 Thread Reinis Rozitis
> 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

RE: [PHP-DEV] [RFC] [VOTE] Deprecate PHP's short open tags

2019-04-11 Thread Reinis Rozitis
> 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

2019-03-25 Thread Reinis Rozitis
> 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

RE: [PHP-DEV] Mysql result data types

2017-10-12 Thread Reinis Rozitis
> 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

RE: [PHP-DEV] Mysql result data types

2017-10-12 Thread Reinis Rozitis
> 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"

[PHP-DEV] Mysql result data types

2017-10-12 Thread Reinis Rozitis
? [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

2016-07-30 Thread Reinis Rozitis
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

Re: [PHP-DEV] date.timezone E_WARNING -- Really necessary? What's the rationale?

2013-05-27 Thread Reinis Rozitis
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.

Re: [PHP-DEV] Re: [VOTE] ext/mysql deprecation in 5.5

2012-11-28 Thread Reinis Rozitis
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

Re: [PHP-DEV] RFC: ext/mysql deprecation

2012-11-13 Thread Reinis Rozitis
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

Re: [PHP-DEV] [RFC] Socket activation support for PHP-FPM

2012-10-18 Thread Reinis Rozitis
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:

Re: [PHP-DEV] One suggestion to PHP-FPM

2010-04-26 Thread Reinis Rozitis
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

Re: [PHP-DEV] FPM is available in a separate SVN branch

2009-12-07 Thread Reinis Rozitis
- 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

Re: [PHP-DEV] FPM is available in a separate SVN branch

2009-12-07 Thread Reinis Rozitis
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

Re: [PHP-DEV] FastCGI limit memory

2007-03-02 Thread Reinis Rozitis
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

Re: [PHP-DEV] FastCGI limit memory

2007-02-07 Thread Reinis Rozitis
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

Re: [PHP-DEV] mod_fast_apache, FastCGI, and mysqli

2007-02-07 Thread Reinis Rozitis
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

Re: [PHP-DEV] FastCGI limit memory

2007-02-06 Thread Reinis Rozitis
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

[PHP-DEV] FastCGI limit memory

2007-02-05 Thread Reinis Rozitis
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

Re: [PHP-DEV] FastCGI limit memory

2007-02-05 Thread Reinis Rozitis
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

Re: [PHP-DEV] FastCGI limit memory

2007-02-05 Thread Reinis Rozitis
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

[PHP-DEV] include_once

2007-01-15 Thread Reinis Rozitis
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

Re: [PHP-DEV] include_once

2007-01-15 Thread Reinis Rozitis
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