Re: [PHP-DEV] Is there a technical reason

rtant in the open source world). It's a growing issue that needs to be addressed. Michael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] re Access Modifiers

Now that there's namespaces are we getting access modifiers on class/functions ? eg. namespace Foo; private function bar() { } public class Baz { } --- Michael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] [DISCUSSION] pecl_http

Hi Stas! On 05/02/15 00:43, Stanislav Malyshev wrote: > Hi! > >> Points explicitely marked for discussion in the RFC itself: >> >> * pecl/propro >> Proxies for properties representing state in internal C structs >> https://wiki.php.net/rfc/pecl_http#peclpropro >> >> * pecl/raphf >> (Persist

Re: [PHP-DEV] Re: [RFC] Support internal function return types

On 05/02/15 09:05, reeze wrote: > Thanks a lot! > > On 5 February 2015 at 16:03, Dmitry Stogov wrote: > >> merged into master with the proposed changes. >> >> Thanks. Dmitry. Awesome, thank you! -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit:

Re: [PHP-DEV] Re: [RFC] [DISCUSSION] pecl_http

Hi Stas! On 05/02/15 09:30, Stanislav Malyshev wrote: > Hi! > >> think raphf is far more of practical use. Why should HTTP, or even more >> HTTPS or HTTP2, be any different than another service, especially when > > Which "another service"? Databases (see my pecl/pq example in the RFC), key/valu

Re: [PHP-DEV] Re: [RFC] [DISCUSSION] pecl_http

Hi Stas! On 05/02/15 09:30, Stanislav Malyshev wrote: >> The sole code change would be removing the check for POST, i.e. >> `!strcasecmp(SG(request_method),"POST")` so that actually any request >> method with a recognized content-type (i.e. application/form-data or >> application/x-www-form-urlen

Re: [PHP-DEV] Re: [RFC] [DISCUSSION] pecl_http

On 05/02/15 09:53, Stanislav Malyshev wrote: > Hi! > >> Databases (see my pecl/pq example in the RFC), key/value stores, message >> queues, whatever you can think of. > > HTTP and databases are principally different. HTTP protocol is stateless > message-oriented protocol, and database connection

Re: [PHP-DEV] Re: [RFC] [DISCUSSION] pecl_http

On 05/02/15 10:03, Stanislav Malyshev wrote: > Hi! > >> Yes, I mean $_POST (and $_FILES). It's been requested multiple times, >> but I know it's quite controversial. I think this approach is better >> than any other proposed yet (think $_PUT and stuff). > > You're building an OO next-generation A

Re: [PHP-DEV] [RFC][DISCUSSION] script() and script_once()

On 05/02/15 02:53, Yasuo Ohgaki wrote: > Hi all, > > I would like to discuss my "must have it in PHP 7" item. > > PHP RFC: script() and script_once() > https://wiki.php.net/rfc/script_and_script_once > Forget about the INI setting. I think the perfect fit for that feature would be import{,_once

Re: [PHP-DEV] Allow dropping typehints during inheritance

On 05/02/15 13:10, Julien Pauli wrote: > On Thu, Feb 5, 2015 at 2:08 AM, Andrea Faulds wrote: > >> Hi Hannes, >> >>> On 4 Feb 2015, at 23:58, Hannes Magnusson >> wrote: >>> >>> So what it supports "more inputs"? >>> It does constitute an LSP violation. "more inputs" is not what the >>> guarantee

Re: [PHP-DEV] Re: [RFC] [DISCUSSION] pecl_http

Hi Pierre! On 05/02/15 18:49, Pierre Joye wrote: > > On Feb 5, 2015 3:17 PM, "Michael Wallner" <mailto:m...@php.net>> wrote: >> >> Compare the timings accessing google 20 times sequentually: >> >> With default of raphf.persistent_handle.limit

Re: [PHP-DEV] Re: [RFC] [DISCUSSION] pecl_http

Hi Stas! On 05/02/15 21:28, Stanislav Malyshev wrote: > Hi! > >> Does the following kcachegrind screenshot give an idea (I used a minimum >> node cost of 10% to simplify the graph)? >> >> Left is raphf enabled (24M Ir) and on the right raphf disabled (35M Ir): >> http://dev.iworks.at/ext-http/rap

Re: [PHP-DEV] Re: [RFC] [DISCUSSION] pecl_http

Hi Stas! On 05/02/15 21:46, Stanislav Malyshev wrote: > Hi! > >> Uhm, I'm not sure I understand :-? Weren't I supposed to measure exacly >> that? Let me know, if you wanted something else to be compared. > > I wanted to know why we need persistent resources. You brought comparing > persistent re

Re: [PHP-DEV] Design by Contract

On 06/02/15 15:17, François Laupretre wrote: > You probably didn't live the PHP 4/5 migration Now, this seems to become a habit. -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: [RFC] [DISCUSSION] pecl_http

On 08/02/15 23:25, Stanislav Malyshev wrote: > Hi! > >> Are you saying performance is not the reason we use persistent handles? > > It is, for databases where connection setup is expensive. Even then > persistent handles are not always the best solution. But with DB, you > routinely connect to on

Re: [PHP-DEV] Re: [RFC] [DISCUSSION] pecl_http

On 08/02/15 23:25, Stanislav Malyshev wrote: >> Youself said that HTTP is a stateless protocol, so how would a >> connection in an "unclean state" look like in your opinion? > > Connection and protocol are different things. In connection, you could > be in the middle of the protocol - i.e. sendin

Re: [PHP-DEV] Re: [RFC] [DISCUSSION] pecl_http

On 04/02/15 18:57, Pavel Kouřil wrote: > On Wed, Feb 4, 2015 at 6:17 PM, Andrea Faulds wrote: >> Hey, >> >>> On 4 Feb 2015, at 17:10, Crypto Compress >>> wrote: >>> I would go with Http\ >>> >>> Why not the reserved Php\Http\? >> >> This sounds good to me. php\ is already reserved, and i

Re: [PHP-DEV] [RFC] [DISCUSSION] pecl_http

On 06/02/15 17:44, Daniel Lowrey wrote: >>> I’ve rewritten the RFC for pecl_http and hopefully addressed most of the >>> things mentioned previously. >>> >>> I you still find anything lacking, please let me know, so I can > expand the >>> RFC accordingly. >>> >>> And of course, everything else is u

Re: [PHP-DEV] Re: Proposal: Introduce a new macro:php_error_docref_ex()

Why not leave it as it is? I mean, really, those five strokes? Wherever it's going, I'm -1 on changing the meaning of the existing macro. On 11 Feb 2015 16:01, "reeze" wrote: > Hi, > > On 11 February 2015 at 19:15, Dmitry Stogov wrote: > > > Hi, > > > > I don't think it'll improve something, a

Re: [PHP-DEV] [RFC] [DISCUSSION] pecl_http

On 06/02/15 17:44, Daniel Lowrey wrote: > If you doubt that this is a solved problem in userland consider the > performance of my own 100% userland HTTP client demonstrated here > without the use of curl or any other extensions: > > https://gist.github.com/rdlowrey/54171625334670ccb9f5 I can repl

Re: [PHP-DEV] [DISCUSSION] Make empty() a Variadic

On 12/02/15 19:55, Thomas Punt wrote: > I'd like to propose to make empty() a variadic, where if any > arguments passed in are considered empty, then false is returned Should that read "if any arguments passed in are considered *NOT* empty, then false is returned"? -- Regards, Mike -- PHP In

Re: [PHP-DEV] [DISCUSSION] Make empty() a Variadic

On 13/02/15 12:31, Andrea Faulds wrote: > >> On 13 Feb 2015, at 11:16, Andrea Faulds wrote: >> >> Hey, >> >>> On 13 Feb 2015, at 07:28, Michael Wallner wrote: >>> >>> On 12/02/15 19:55, Thomas Punt wrote: >>> >>>> I

Re: [PHP-DEV] Scalar Type Hints v0.4

On 17/02/15 23:03, Sara Golemon wrote: > 1) Introduce scalar types for primitives: bool, int, float, string, > resource, object (we already have array) > 1a) Introduce meta-types as pre-defined unions (we can add custom > unions in a later rfc). A possible list may be as follows (again, we > can

Re: [PHP-DEV] Scalar Type Hints v0.4

On 18/02/15 12:31, Rowan Collins wrote: > Michael Wallner wrote on 18/02/2015 11:19: >> On 17/02/15 23:03, Sara Golemon wrote: >> >>> 1) Introduce scalar types for primitives: bool, int, float, string, >>> resource, object (we already have array) >>> 1a)

Re: [PHP-DEV] Digit separators for numeric literals

On 19/02/15 03:44, Rasmus Lerdorf wrote: > but _999_ would need to work as well and _ is a valid char in a constant > so you can have a constant named _999_. > Why would we need to support the underscore in front (and maybe even at the end) of a number? -- Regards, Mike -- PHP Internals - P

[PHP-DEV] [RFC][DISCUSS] Continue output buffering despite aborted connection

Hi, I drafted an RFC to continue output buffering despite an aborted connection was detected. The title might well be a bit misleading, so please read the RFC before judgement. https://wiki.php.net/rfc/continue_ob -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To un

Re: [PHP-DEV] Digit separators for numeric literals

On 19/02/15 13:16, Nikita Nefedov wrote: > > Why not space? It's certainly possible (I just checked) and it would look > clear I guess: > > my_func(1 999 999); > Yes, but what if I just missed one or two commas there? ;) -- Regards, Mike -- PHP Internals - PHP Runtime Development Maili

[PHP-DEV] [RFC][PRE-VOTE] pecl_http

Hi! Please, consider this a warning that I'll put this to vote again shortly. https://wiki.php.net/rfc/pecl_http -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] [RFC][VOTE] pecl_http

Hi, as already threatened, I hereby open the vote on the pecl_http RFC. https://wiki.php.net/rfc/pecl_http#vote -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Unnecessary extensions ...

> On 22 02 2015, at 11:31, Lester Caine wrote: > > With the discussion on adding http extension by default and not now > having other key extensions in a normal build I'm looking at what I NEED > and what I can get away without. On the current PHP7 test build I do not > have mysqlnd installed as

[PHP-DEV] Re: [RFC][VOTE] pecl_http

Hi, I forgot to formally declare a voting period, so I’ll do so now. Voting will end on Feb, 27th at 21:00 UTC, so if you didn’t vote yet, please do so until then. https://wiki.php.net/rfc/pecl_http#vote > On 20 02 2015, at 21:56, Michael Wallner wrote: > > Hi, > > as alread

Re: [PHP-DEV] Re: [RFC][VOTE] pecl_http

The vote on the pecl_http RFC has been closed, thanks to everyone who participated. The results are 9 in favour and 23 against, so the RFC was declined, which is actually an understatement ;) > On 27 02 2015, at 18:19, Pascal MARTIN, AFUP wrote: > > > Le 26/02/2015 12:28, Micha

Re: [PHP-DEV] [RFC][DISCUSSION] Constructor behaviour of internal classes

On 1 Mar 2015 15:56, "Dan Ackroyd" wrote: > > Hi Internals, > > This email is to announce the formal opening of discussion for an RFC > to clean up the behaviour of the constructors shown by several > internal classes. > > https://wiki.php.net/rfc/internal_constructor_behaviour > > For reference t

Re: [PHP-DEV] [RFC][DISCUSSION] Constructor behaviour of internal classes

On 01/03/15 23:05, Stanislav Malyshev wrote: > Hi! > >> This email is to announce the formal opening of discussion for an RFC >> to clean up the behaviour of the constructors shown by several >> internal classes. >> >> https://wiki.php.net/rfc/internal_constructor_behaviour > > I'm not sure why t

Re: [PHP-DEV] Consistent function names

I can't think of any good use case for a bulk import outside of laziness. Any good IDE will handle this for you and if you are importing as \ then why don't you just not namespace them in the first place. On Mon, Mar 2, 2015 at 11:33 PM, Stanislav Malyshev wrote: > Hi! > > > I would love to have

Re: [PHP-DEV] [RFC][DISCUSSION] Constructor behaviour of internal classes

>> Consistency with userland is beneficial, because the majority of PHP >> developers probably do not expect `new` to yield anything than a >> concrete instance or an exception. > > Of course, consistency with userland is beneficial. However, in userland > we do not have many things that we have

Re: [PHP-DEV] Deprecate array()

Removing array() is purely a stylistic preference and offers no benefit. It does however offer lots of work for people bringing libraries up to date as well as polluting logs. I see no reason to discuss this further unless someone has something concrete. Thanks, On Tue, Mar 3, 2015 at 12:27 PM, A

Re: [PHP-DEV] Consistent function names

Your evaluation is pretty anecdotal. I agree with some points but you need some solid evidence if you are going to rate these languages. Also do you have a list of all the functions you would like to rename or is this a sweeping lets just change everything so it matches and deprecate all the old st

Re: [PHP-DEV] Consistent function names

, Yasuo Ohgaki wrote: > Hi Michael, > > On Wed, Mar 4, 2015 at 12:15 PM, Michael Schuett > wrote: > >> Your evaluation is pretty anecdotal. I agree with some points but you >> need some solid evidence if you are going to rate these languages. Also do >> you have a li

Re: [PHP-DEV] Consistent function names

> On 04 03 2015, at 09:58, Lester Caine wrote: > > On 04/03/15 03:34, Yasuo Ohgaki wrote: >> I made list of rename candidates >> https://wiki.php.net/rfc/consistent_function_names#list_of_functions_to_be_renamed >> If you have suggestions, I appreciate! > > Taking the starting point ... the cod

Re: [PHP-DEV] Use behavior thoughts

> > So, I created a PR to remove this error: > https://github.com/php/php-src/pull/1149 > +1 > > Note that there is no BC break here, as it's removing an error condition > today. > > This results in a weird edge case (which is 100% valid, but feels

[PHP-DEV] [VOTE] [RFC] continue output buffering

Hi, I’d like to start vote on RFC:continue_ob — any objections? https://wiki.php.net/rfc/continue_ob Regards, Mike

Re: [PHP-DEV] [VOTE] [RFC] continue output buffering

Hi all! > On 11 03 2015, at 08:26, Matteo Beccati wrote: > > On 10/03/2015 03:10, Yasuo Ohgaki wrote: >> Hi Mike, >> >> On Mon, Mar 9, 2015 at 9:45 PM, Michael Wallner wrote: >> >>> Hi, I’d like to start vote on RFC:continue_ob — any objections? >

Re: [PHP-DEV] php_stream_read(...) may return less than expected

On 12/03/15 14:28, Umberto Salsi wrote: > Hi all, > I'm not a PHP internals developer, but this might be a bug spread here and > there in the source. This coding pattern: > > if(php_stream_read(..., n) != n){ > php_error_docref(NULL TSRMLS_CC, E_SOMETHING, "Read error!"); > > seems wrong to m

Re: [PHP-DEV] [VOTE] [RFC] continue output buffering

Voting just started on https://wiki.php.net/rfc/continue_ob I’ll close the poll in a week. Thanks, Mike

Re: [PHP-DEV] Voting irregularities

> On 15 03 2015, at 15:19, Anthony Ferrara wrote: > > All, > > I ran some numbers on the current votes of the dual-mode vote right > now. There were a number of voters that I didn't recognize. So I > decided to pull some stats. > > The following voters never voted before the dual-mode RFC went

Re: [PHP-DEV] Voting irregularities

> On 15 03 2015, at 16:23, Levi Morrison wrote: > > On Sun, Mar 15, 2015 at 8:29 AM, Michael Wallner wrote: >> >>> On 15 03 2015, at 15:19, Anthony Ferrara wrote: >>> >>> All, >>> >>> I ran some numbers on the current votes of the

Re: [PHP-DEV] Minimum version of GCC required to build PHP

> On 15 03 2015, at 16:36, Sebastian Bergmann wrote: > > Am 15.03.2015 um 15:34 schrieb Sebastian Bergmann: >> I am asking because using GCC 2.95.3 and GCC 3.4.0 I get errors related >> to the usage of intptr_t (see http://pastebin.com/9Gn0AAXA). > > Over in Room 1

Re: [PHP-DEV] Voting irregularities

>> >> Is there a way to check when someone got a php.net account/karma? >> >> >> http://people.php.net >> > > I am aware of this, but unless I just missed it that site doesn't show > *when* they got an account. Oh, sorry! I thought it reads something like “Account opened: Y-m-d” but that’s

Re: [PHP-DEV] [RFC][VOTE] Constructor behaviour of internal classes

> On 15 03 2015, at 17:09, Dan Ackroyd wrote: > > Hi List, > > The 'Constructor behaviour of internal classes' RFC is now in voting. > Please note, it's the coding standard that is being voted on. If > anyone thinks I've implemented the changes in a way that is less > awesome then there is no r

Re: [PHP-DEV] phar_rename_archive() bug fix for PHP7

On 17/03/15 15:55, Ralph Schindler wrote: > hi all, > > Phar::convertTo*() methods have a design flaw such that phar files can't > be successfully converted and retain the proper file suffix at the same > time when the base name contains dots. An expression of this is > attempting to convert some

[PHP-DEV] [RFC][ACCEPTED] Continue Output Buffering

Hi, I was late closing the vote on rfc:continue_ob, but there was only one yay in the last two days, anyway. The change was accepted with 100% yes votes, and has just been committed. -- Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.

[PHP-DEV] [RFC] Fix the Tenary Operator -- Please!? Please?

Per PHPsadness... http://phpsadness.com/sad/30 Since 7 is allowed to have BC breaks this would be the time to fix this. I'll let someone with more seniority actually write this up - but please, please fix this - it's a very long standing annoyance.

Re: [PHP-DEV] [RFC] Fix the Tenary Operator -- Please!? Please?

It's not a feature though - it's a bug. It's just one of those bugs that the fixing of which may break something. On Thu, Mar 26, 2015 at 6:31 PM, Rowan Collins wrote: > On 26 March 2015 20:54:12 GMT, Michael Morris wrote: > >Per PHPsadness... > > > >http:

Re: [PHP-DEV] [RFC] Fix the Tenary Operator -- Please!? Please?

Rowan, I seriously, seriously doubt anyone would write PHP 7 compliant code that only takes advantage of ternary associativity, a feature that is only occasionally useful. If they can't take the hint from the parse errors arising out of the spaceship op and all the other stuff being added, they're

Re: [PHP-DEV] What's our official stance on small self-contained additions in a micro version

On 30/03/15 12:04, Ferenc Kovacs wrote: > Hi, > > I know that our official release process allows that, but there are some > reasonable arguments against doing that and this topic was brought up > multiple times related to specific fixes. > I have two open PRs like that: > https://github.com/php/p

Re: [PHP-DEV] Deprecate setlocale?

> On 01 04 2015, at 18:15, Dan Ackroyd wrote: > > Hi, > > I'd like to get people's feedback for the idea of making setlocale be > either deprecated and to be removed eventually or just increasing the > warning level against people using it. > > The short version of why we should do this is tha

Re: [PHP-DEV] What's our official stance on small self-contained additions in a micro version

> On 01 04 2015, at 18:28, François Laupretre wrote: > >> De : Ferenc Kovacs [mailto:tyr...@gmail.com] >> >> I could accept any decision between holding off new features until next >> minor/major and allowing features explicitly without going through an RFC, >> but I >> want to have an expli

Re: [PHP-DEV] PR 1217: Add support for upload files from buffer string in curl extenion

On 22 Apr 2015 10:27, "Alexander Moskalev" wrote: > > Thanks to all for feedback! > > Let's try to integrate new feature to old class. > We have constructor in CURLFile with one required parameter: $filename . > To avoid BC break we cannot replace this parameter. So I suggest to do it > optional

Re: Fwd: [PHP-DEV] [RFC] [PHP 7.1] libsodium

On 21/05/15 09:49, Peter Petermann wrote: > Hi Scott, > > I personally think the RFC is a bit short, > also I just had a very brief look at the documentation of the extension in > question, and find its API a bit strange, > whats up with having everything in static method calls? > > regards, > PP >

Re: [PHP-DEV] Method call overhead

> On 03 06 2015, at 05:30, Bishop Bettini wrote: > My question though is on relative times. Method call overhead is > consistently 50% to 150% over a direct call. Is my experiment invalid, or > is this overhead expected? Is the overhead in the allocation, > deallocation, GC? I’suggest you us

Re: [PHP-DEV] Maintaining LDAP module

> On 10 06 2015, at 12:21, Côme BERNIGAUD wrote: > > Hello, > > I intend to work on LDAP module, starting by trying to get rid of obsolete > method calls. (starting by https://bugs.php.net/bug.php?id=69471 ) > > I already have appropriate CVS rights but I’m not sure which branch I should > c

Re: [PHP-DEV] LDAP module test suite

On 15/06/15 15:43, Chris Wright wrote: > On 15 June 2015 at 14:02, Côme BERNIGAUD > wrote: > >> Hello, >> >> What is the needed configuration to be able to run the whole LDAP test >> suite? >> It connects with "cn=Manager,dc=my-domain,dc=com" but then tries to create >> "dc=my-domain,dc=com". >>

Re: [PHP-DEV] Consolidation of Traversable and array operations

On 15/07/15 13:28, Tjerk Meesters wrote: > Hi! > > A few weeks ago I resurrected a two year old proposal for adding two array > functions, namely array_every() and array_some(), modelled after their > JavaScript equivalent. > > https://github.com/php/php-src/pull/1385 > > ... > > Let me know wh

Re: [PHP-DEV] Consolidation of Traversable and array operations

On 16/07/15 11:26, Rowan Collins wrote: > Benjamin Eberlei wrote on 15/07/2015 21:19: >> >> But instanceof and anything related to Reflection or get_class or >> relevant code will fail on array. > > > Ah, yes, I hadn't thought of reflection type things. I don't think > instanceof would be a probl

[PHP-DEV] List of possible E_RECOVERABLE_ERRORs

Hi. I hate to ask an outright question on the list rather but I've been searching the last 5 hours for an answer to this and haven't found anything and it's a rather tight corner case. I'm working on a small package for PHP 5.x that uses set_error_handler() to convert E_RECOVERABLE_ERRORs to the a

Re: [PHP-DEV] List of possible E_RECOVERABLE_ERRORs

ance on this - smoothing the transition from 5 to 7 helps all of us. On Tue, Jul 21, 2015 at 1:44 PM, Rowan Collins wrote: > Michael Morris wrote on 21/07/2015 18:11: > >> Hi. I hate to ask an outright question on the list rather but I've been >> searching the last 5 hours for an

Re: [PHP-DEV] What to do with ext/snmp?

We have switched to a userland library (https://github.com/FreeDSx/SNMP) due to crashes when using the internal SNMP extension in ZTS scenarios. It doesn't really answer your question, but maybe it fits category two, that usage is not very high or that people chose the pure PHP version. Mi

Re: [PHP-DEV] function ob_gzhandler is missed in 5.4

On Tue, 06 Dec 2011 11:07:00 -0800, Stas Malyshev wrote: >> https://bugs.php.net/bug.php?id=60326 > > Ah, I didn't realize this is patch from Mike. Let me take another look > into it but I think it can be applied unless anyone sees anything wrong > with it. Note that despite I wrote the patch, I'

Re: [PHP-DEV] Re: [PHP-DOC] missing docs for 5.4

Slightly off topic - but this is definitely a part of the PHP project I'm qualified to help (documentation writing) with in some capacity. Who would I get in contact with to get an assignment? Just the PHP docs list or someone specific? (I'm subbed to the internals list, I dunno if I'm subbed to

[PHP-DEV] Re: svn: /SVNROOT/ global_avail pre-commit

On Thu, 29 Dec 2011 18:29:36 +, David Soria Parra wrote: > dsp Thu, 29 Dec 2011 18:29:36 + > > Revision: http://svn.php.net/viewvc?view=revision&revision=321521 > > Log: > Temporarily deactivate commits to systems during migration > > Changed paths:

Re: [PHP-DEV] function ob_gzhandler is missed in 5.4

On Fri, 30 Dec 2011 10:29:09 +0100, Nicolas Grekas wrote: > What is the status of this ? Looks like it's already been committed. Regards, Mike -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: Code freeze for 5.4

On Sat, 07 Jan 2012 14:40:25 -0800, Stas Malyshev wrote: > The following may be considered for inclusion: > - Unit tests & test fixes - Fixes for critical bugs - Security fixes - > BC break fixes Please still ask RMs for approval prior to committing > even if your patch falls into these categorie

Re: [PHP-DEV] 5.4.0 rc6 and release

quot;normal" for big projects like this? Again, please take these questions as normal questions, I don't want to attack anybody, I'm just interested in the process and relatively new to internal PHP development. Thanks for your work on PHP! Michael Am 19.01.2012 23:55, sc

[PHP-DEV] Re: svn: /php/php-src/ branches/PHP_5_4/ext/zlib/tests/bug60761.phpt trunk/ext/zlib/tests/bug60761.phpt

On Mon, 23 Jan 2012 06:39:01 +, Rasmus Lerdorf wrote: > rasmus Mon, 23 Jan 2012 06:39:01 + > > Revision: http://svn.php.net/viewvc?view=revision&revision=322596 > > Log: > Please test your tests > > Changed paths: > U php/php-src/branches/PHP_5_4/

[PHP-DEV] Re: One more critical problem in 5.4

On Wed, 25 Jan 2012 19:07:15 +0400, Dmitry Stogov wrote: > Hi Stas, > > We've just found one more critical problem in 5.4. > > Apache/PHP crashes in case of error on startup, when > display_startup_errors=1. It's probably related to new output API. > > I afraid it may affect many php users. ...

Re: [PHP-DEV] One more critical problem in 5.4

On Wed, 25 Jan 2012 09:13:43 -0800, Stas Malyshev wrote: > Hi! > >> We've just found one more critical problem in 5.4. >> >> Apache/PHP crashes in case of error on startup, when >> display_startup_errors=1. It's probably related to new output API. >> >> I afraid it may affect many php users. > >

[PHP-DEV] Re: [PHP-WEBMASTER] [git] web/master.git branch master updated. 8181453

On Tue, 24 Jan 2012 20:33:10 +0100, David Soria Parra wrote: > > I understand that it's useful, so you suggested having a mail for each > commit instead of each push. I prefer mails per push as they are the > only documentation of who pushed what. In case someone pulls from a > person that doesn'

Re: [PHP-DEV] mail.add_x_header set to on in php.ini-production

Personally I would want to have an audit log of emails on production. That actually is probably more important to me than non-production environments :) On Jan 27, 2012, at 1:37 AM, Martin Jansen wrote: > Is there any intention behind enabling the mail.add_x_header > configuration directive in

[PHP-DEV] Re: One more critical problem in 5.4

On Tue, 31 Jan 2012 10:04:34 +0200, yoram bar haim wrote: > Sorry, problem is not solved yet. I committed a possible fix to trunk. It's pretty much along the patch from you, I just hat to fix crashes in the cli server and need to do some more testing before merging into PHP_5_4. Thank you for y

[PHP-DEV] Re: One more critical problem in 5.4

Thank you. Now I just need to figure why the cli servers styles are printed to stdio... On Tue, 31 Jan 2012 11:16:40 +0200, yoram bar haim wrote: > The patch to trunk does solve the FastCGI headers problem. tested with > PHP fastcgi on top of lighttpd. -- PHP Internals - PHP Runtime Develop

Re: [PHP-DEV] Re: One more critical problem in 5.4

On Wed, 01 Feb 2012 11:57:08 +0200, Lior Kaplan wrote: > On Tue, 2012-01-31 at 03:58 -0500, Michael Wallner wrote: >> On Tue, 31 Jan 2012 10:04:34 +0200, yoram bar haim wrote: >> >> > Sorry, problem is not solved yet. >> >> I committed a possible fix to trun

Re: [PHP-DEV] [RFC] Deprecate and remove /e modifier from preg_replace

Perhaps rather than killing it we should just emphasize it more in the documentation (ie on preg_replace and not only in pattern modifiers). But I have found the /e modifier to be very useful in the past. Unfortunately, just having woken up I can't remember exactly where and how I used it, lol.

Re: [PHP-DEV] When is PHP6 Beta going to be available ;)

As far as I know, PHP 6 has been indefinitely postponed. Getting full unicode support turned out to be no mere bear, but an Arctotherium ( http://en.wikipedia.org/wiki/Arctotherium ). On Sat, Feb 4, 2012 at 3:26 PM, Lester Caine wrote: > I'm just looking into my annual dedicated server update s

Re: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds

Having watched this discussion unfold, I for one intend to discontinue using Sushonin. I advise others to do the same. The character displayed by Stefan throughout this thread speaks for itself as to why. On Sat, Feb 4, 2012 at 9:44 AM, Stefan Esser wrote: > Pierre, > > I think we all know that

Re: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds

I don't think so. My experience with the attitude he has shown is, when mistakes get made by such a person, they are hidden away rather than honestly reported. To paraphrase a line from Harry Potter - brilliant people don't make many mistakes, but the ones they make tend to be large and very damag

Re: [PHP-DEV] Suhosin patch disabled by default in Debian php5 builds

On Mon, Feb 6, 2012 at 11:51 AM, Nikita Popov wrote: > On Mon, Feb 6, 2012 at 5:22 PM, Reindl Harald > wrote: > > if you anwer to a list mail answer to the list and not private damend! > Please, such kind of language is really not necessary. Hitting Reply > instead of Reply All happens to everyb

[PHP-DEV] Re: main/output.c problem

On Mon, 13 Feb 2012 10:54:38 +0200, James Edmunds wrote: ... > if the output handler function set the return buffer pointer to NULL, it > was a signal to the output code to pass through the buffer contents > unmodified. The compatibility function wasn't doing that. A fix has been committed. Tha

[PHP-DEV] Re: [PHP-CVS] svn: /php/php-src/ branches/PHP_5_4/main/output.c trunk/main/output.c

hp.net, so there's no bug number. So, after all it doesn't seem to warrant a NEWS entry, does it? > > On 02/14/2012 11:31 AM, Michael Wallner wrote: >> mike Tue, 14 Feb 2012 19:31:54 >> + >> >> Revision: http://svn.p

[PHP-DEV] $_PARAMETERS Super Global Object

Before writing up a full RFC I want to put out a feeler on something. Currently we have several input parameter objects, chief among them $_GET, $_POST, $_REQUEST, $_SERVER (for the client HTTP headers). All of them are arrays and legacy code sometimes writes to them. Locking them as read only ob

Re: [PHP-DEV] $_PARAMETERS Super Global Object

tanding the full extent that you're suggesting. > > -- > Will Fitch > > On Wednesday, February 22, 2012 at 9:57 AM, Michael Morris wrote: > > Before writing up a full RFC I want to put out a feeler on something. > Currently we have several input parameter objects, chief a

Re: [PHP-DEV] Scalar type hinting

What I've wanted for awhile, but don't know what the implementation problems would be, is to allow for two new variable types to solve this problem - Strict and tolerant variables. Both of these must be declared formally (otherwise PHP assumes scalar) and the datatype must be included. The syntax

Re: [PHP-DEV] Scalar type hinting

a copy. This will hurt the > performance in hardly predictable ways. > > johannes > > On Mon, 2012-02-27 at 09:29 -0500, Michael Morris wrote: >> What I've wanted for awhile, but don't know what the implementation >> problems would be, is to allow for two new va

Re: [PHP-DEV] Scalar type hinting

I don't want it to be a strongly typed language. Whatever you call it (weakly typed, loosely typed), I want a change to where the *option* to declare a datatype exists. I do not want it to be required, both for backwards compatibility and also for barrier to entry reasons. In my mind given: (this

Re: [PHP-DEV] Scalar type hinting

Thank you. Now I'm going to go work up a detailed RFC for what I posted earlier with some additional clarification as to when errors should and shouldn't be thrown. On Tue, Feb 28, 2012 at 2:53 PM, John Crenshaw wrote: > OK everyone, it seems that some people have forgotten or missed the origina

Re: [PHP-DEV] Scalar type hinting

I don't think the strong/weak stuff is necessary at all. Either a programmer cares about datatype or they don't and the vast, vast majority won't. Declaring a variable's datatype should have the effect of locking that variable's datatype down and not allowing it to switch types with the sole exce

Re: [PHP-DEV] Scalar type hinting

t; I purpose to deal with this and when it works and is released to the > wild then see if more strictness even is needed. I think this simple > weak type hinted functionality will suffice. > > -- Forwarded message -- > From: Simon Schick > Date: 2012/2/28 > Subj

Re: [PHP-DEV] Scalar type hinting

Agreed. If conversion can occur without data loss (that is, if the value being assigned is == the value that actually IS assigned) then no error should occur. So int $a = "1"; // no error. 1 == "1" so who cares? int $a = 'House'; // error 0 != 'House', so this is a problem. Again, errors shoul

Re: [PHP-DEV] Scalar type hinting

rong type, since that would > now be done for you at the lower level.  There are other cases where this > sort of conflict would be undesirable but the coder might still want the > script to proceed anyway, hence the need for the weak type.  There are > valid, real-world use cases for both. &

Re: [PHP-DEV] [RFC] discussions, about a 5.3 EOL

Michael On Mar 2, 2012, at 1:34 PM, Pierre Joye wrote: > hi, > > It should have been done before 5.4.0 was out, but better late than never. > > I put together four options here: > > https://wiki.php.net/rfc/php53eol > > I'm in favor of option #1, as it g

  1   2   3   4   5   6   7   8   9   10   >