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] [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] 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 11, Michael just pointed out th

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.

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

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'

[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

[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'

[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

[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

Re: [PHP-DEV] SVN Account Request: justatest

On Fri, 02 Mar 2012 17:45:20 -0800, Kris Craig wrote: > I think it's a solid approach but I've always been a fan of having > written policies and clear procedures as opposed to the more ad hoc > approach that this appears to be. I wouldn't mind seeing this drafted > into an RFC; I believe the pol

Re: [PHP-DEV] hash / tiger regression in PHP 5.4.0

On Mon, 05 Mar 2012 17:52:52 +0100, Remi Collet wrote: > > Using a simple C program (linked against libmash) > > Hash: fdb9019a79c33a95677e2097abae91eb0de00b3054bb5c39 > > So the result from php <= 5.3.10 seems the right one. Sorry for the delay, but I already explained the issue in the bug re

Re: [PHP-DEV] hash / tiger regression in PHP 5.4.0

> It'd be worse to keep the wrong behavior, providing as tiger what it is not. > What can be done is to add a "tiger192,3-broken php5.4" hash for BC of > those which may have used the new one. > It's serious enough so I'd consider it a factor for a new minor in short > time, but not for setting in

[PHP-DEV] Re: [PHP-CVS] [git] commit php-src.git: UPGRADING

Shouldn't the commit mails reference the push mail? Looks a bit messy without relations of commit/push mails. On 19 March 2012 20:33, Michael Wallner wrote: > Commit: 867d980574ec8086cc40634fbd62af257504b8ea > Author: Michael Wallner(m...@php.net)         Mon, 19 Mar 2012 20:

[PHP-DEV] Re: [PHP-CVS] [git] commit php-src.git: ext/hash/tests/mhash_001.phpt ext/hash/tests/mhash_003.phpt

Should the commit to bugs.php.net hook already work? A link was obviously added to the commit message, but the bug was not commented. Just in case... On 19 March 2012 22:04, Michael Wallner wrote: > Commit: 260e77709ddfe9e72e2b7f11393673b6ee18a7f9 > Author: Michael Wallner(m...@p

Re: [PHP-DEV] Accessors v2.4 Proposed Changes

Hi Clint, On 22 March 2012 20:00, Clint M Priest wrote: > Does anyone else have any comments about this RFC (as-implemented)? I need time, probably longer than the weekend, to review your RFC, to be able to say anything seriously. Generally, I was against the idea of accessors, when you brought

Re: [PHP-DEV] [RFC] skipping optional parameters

On 18 April 2012 01:23, Jordi Boggiano wrote: > On 18.04.2012 00:54, Stas Malyshev wrote: >> https://wiki.php.net/rfc/skipparams >> >> Basically, it allows you to do this: >> >> create_query("deleted=0", "name",,, /*report_errors*/ true); +1 > - Would it be possible to allow trailing commas in

Re: [PHP-DEV] ob_start callback not fired with ob_get_clean()

On 25 April 2012 17:50, Dmitri Snytkine wrote: > I am wondering why the call to ob_get_clean and ob_get_contents does not > trigger the callback function registered with ob_start('mycallback') You could at least have told what PHP version you're using... The output control layer implementation ha

[PHP-DEV] Re: [PHP-CVS] cvs: php-src /ext/spl php_spl.c

Hi Marcus Boerger, you wrote: > Hello Andi, > > Monday, April 11, 2005, 12:35:34 AM, you wrote: > > >>Hi, > > >>Andrey might have a point. Unlike the other names you've defined, this one >>feels as if it'll break lots of apps. >>How about FileIterator? > > > very missleading. Maybe FileObject or

Re: [PHP-DEV] PHP 5.1

Hi Andreas Korthaus, you wrote: > Will pecl_http be included? (AFAIR something like that has been > discussed earlier this year on this list) Hm, I must have missed that... Anyway it's still far away from stable - just compare the count of tests against the amount of functionality provided. Reg

Re: [PHP-DEV] PHP 5.1

Hi Andreas Korthaus, you wrote: > Michael Wallner wrote: >> Anyway it's still far away from stable - just compare the >> count of tests against the amount of functionality provided. > > OK, I wrote some small scripts and it worked quite nice. Very good work, > it'

[PHP-DEV] while we're at it (PHP-5.1 & instanceof)

I already complained about that issue several times on IRC and now that it's time for PHP-5.1 to come, I'll just throw this question/rant in... Using is_a() throws a notice (E_STRICT IIRC) in PHP5, which should be fine, because it was deprecated in favour of the instanceof operator. But there's

Re: [PHP-DEV] while we're at it (PHP-5.1 & instanceof)

Hi Andi Gutmans, you wrote: > Seems to work... Sorry, what seems to work what way? Thanks, -- Michael - < mike(@)php.net > signature.asc Description: OpenPGP digital signature

Re: [PHP-DEV] while we're at it (PHP-5.1 & instanceof)

Hi Andi Gutmans, you wrote: > instanceof calls __autoload() Well, what for I wonder? If the class is not defined, no object can be an instance of it... Regards, -- Michael - < mike(@)php.net > signature.asc Description: OpenPGP digital signature

[PHP-DEV] Re: Problem with leak detection

Marcus Boerger wrote: i just stumbled over a strange issue while testing. Some of my tests have exit(0) at the end for easier test verification. Now i found a new one that has a few memleaks but only reports them if i drop that exit(0) line. Is this something we need to fix (e.g. exit() omits

[PHP-DEV] Re: php4 and imap

D. Walsh wrote: How do I resolve this issue to obtain imap support in PHP4? Please direct such questions to php.general or similar. This list is supposed for discussing PHP *internals*. Regards, Mike hint: cclient-dev -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, v

[PHP-DEV] static members of internal classes

Hi, I have some issues with static members of internal classes. AFAICS no extension uses them so far (did I miss something?). There seems to be missing a proper cleanup routine for the static_member hashtable in PHP-5.0 because there are mem-leaks for each property to which another value (i.e. st

[PHP-DEV] Re: static members of internal classes

I wrote: > I have some issues with static members of internal classes. > AFAICS no extension uses them so far (did I miss something?). I cannot declare static properties as strings because that causes memory errors in zval_dtor() (SET_STATIC_PROP_EX code is actually the same as in ReflectionClass

[PHP-DEV] Re: static members of internal classes

Hi I wrote: > I wrote: > > >>I have some issues with static members of internal classes. >>AFAICS no extension uses them so far (did I miss something?). > > I cannot declare static properties as strings because that causes > memory errors in zval_dtor() (SET_STATIC_PROP_EX code is actually > the s

Re: [PHP-DEV] Re: static members of internal classes

Hi Dmitry Stogov, you wrote: > Hi Michael, > > It is not a bug. You understood proper. Internal classes are stored in > regular heap and they don't use e[memory] function family. > This is done, because memory allocated by emalloc is freed after each > request, but internal classes should still ali

Re: [PHP-DEV] Re: static members of internal classes

Hi, I wrote: > Isn't the behaviour of ReflectionClass then bogus, because > it doesn't care about ZEND_INTERNAL_CLASSes? And... shouldn't there be a cleanup for static members of ZEND_INTERNAL_CLASSes to reset the contents to the declared values? Also zval_internal_dtor() implies that one canno

Re: [PHP-DEV] Re: static members of internal classes

Hi Marcus Boerger, you wrote: > Hello Michael, > > sure but there's a difference Reflection whatever is only run during > request time, what you want is running outside and require malloc rather > than emalloc. Thanks, I already adjusted my code according to that. But guess, I've still not solv

Re: [PHP-DEV] Re: static members of internal classes

Hi Andi Gutmans, you wrote: >> Also zval_internal_dtor() implies that one cannot set >> a static member of a ZEND_INTERNAL_CLASS to be a stream, >> array etc... > > > Yes, that's correct. It's a limitation you have to live with because > those datastructures are destroyed at the end of the request

[PHP-DEV] Re: PHP 5.1 Release Candidate 1

Hi Andi Gutmans, you wrote: > As planned (a tiny bit delayed), I'd like to RC1 PHP 5.1 within the next > few days. I suggest to aim for Tuesday in a week. > If there are any critical issues which need addressing please email me. Is instanceof going to be fixed? If not (without any reason), I'll s

[PHP-DEV] build fix for ZEND_DEBUG>=2

Index: zend_vm_def.h === RCS file: /repository/ZendEngine2/zend_vm_def.h,v retrieving revision 1.56 diff -u -r1.56 zend_vm_def.h --- zend_vm_def.h 21 Jul 2005 13:48:10 - 1.56 +++ zend_vm_def.h 27 Jul 2005 08:07:08

Re: [PHP-DEV] [PATCH] Namespace Patch, Beta 1

Hi Jessie Hernandez, you wrote: > Forgot to mention, since I expect the majority of users to follow the PEAR > convention for their classes (basically one class per file, file is named > like class, with "namespace" directories) With the minor but essential logical difference: $file = str

Re: [PHP-DEV] [PATCH] Namespace Patch, Beta 1

Hi Marcus Boerger, you wrote: > Hello Michael, > > i suffest that pear finally takes a better approach with the arrival of > namespaces then the ugly workaround of '_'. Of course -- PEAR would benefit a lot of namespaces! -- Michael - < mike(@)php.net > signature.asc Description: OpenPGP dig

[PHP-DEV] Re: RC1, instanceof?

Hi Pierre-Alain Joye, you wrote: > I can write a patch to "fix" it if we agree that the current > behavior is not correct. While you're at it, could you continue on fixing the following: (another evidence that the current "generic" behaviour is bad) try { // anything } catch (NonExistant

Re: [PHP-DEV] Re: RC1, instanceof?

Hi Andi Gutmans, you wrote: > You are wrong because __autoload() *is* called and you can load the > class on the-fly. The only problem is if the class does not exist in > your code base, in which case, your application should blow up! No insult intended, but this is just stubborn. You want to hear

Re: [PHP-DEV] Re: [PATCH] Namespace Patch, Beta 2

Hi Marcus Boerger, you wrote: > Hello Jessie, > > Tuesday, August 9, 2005, 4:36:41 AM, you wrote: >>1) I asked this before, but it wasn't answered: is there any reason why .php >>is not a default extension for spl_autoload? > > > PEAR uses .inc.php and i as well as all i have spoken too like .inc

Re: [PHP-DEV] Re: RC1, instanceof?

Hi Stanislav Malyshev, you wrote: > Now the only problem I see here is if you > type Bar when you intended to type Baz - but I'm not sure this warrants > the fatal error. Yes, unit tests could catch such issues. > MW>>There could be a flag to let instanceof *not* die - > MW>>a little less generi

  1   2   3   4   5   6   7   >