Re: [PHP-DEV] Change bug tracker "bogus" to "not-bug"?

Ok, by popular demand I have changed "Bogus" to "Not a bug" in the bugs tracker. The sub-status stuff we have been discussing can just be added in the comment when you mark something as "Not a bug". eg. Status: Not a bug Reason: 583 CNR So, having done this, for the folks too skittish to mark stu

Re: [PHP-DEV] Change bug tracker "bogus" to "not-bug"?

On Jan 24, 2012, at 3:47 PM, Ferenc Kovacs wrote: > On Wed, Jan 25, 2012 at 12:11 AM, Justin Martin wrote: > >> Hello, >> >> With some frequency, I find bugs which are not "bogus", so much as they >> are reported based on a misunderstanding. Usually this happens for >> documentation problems,

Re: [PHP-DEV] salsa.lo

On 01/19/2012 08:20 PM, Clint M Priest wrote: > Just updated and tried to compile, getting this: > > make: *** No rule to make target > `/opt/php-core/trunk-accessor/ext/hash/hash_salsa.c', needed by > `ext/hash/hash_salsa.lo'. Stop. > > I see that commit 322421 removed the hash_salsa.c but pe

Re: [PHP-DEV] FD_SETSIZE warning?

On 01/13/2012 02:42 PM, Reindl Harald wrote: > > Am 13.01.2012 17:36, schrieb Rasmus Lerdorf: >> FD_SETSIZE is a system limit on the number of open files a >> single process can have. From a bash shell type: ulimit -n and >> you will probably see this magical 1024 numb

Re: [PHP-DEV] FD_SETSIZE warning?

On 01/13/2012 05:13 AM, Hannes Landeholm wrote: > I'm flooded with this warning when my system is under a high load and uses > a lot of sockets/file descriptors. I get it in stream_select: > > "E_WARNING: E_WARNING caught: stream_select(): You MUST recompile PHP with > a larger value of FD_SETSIZE

Re: [PHP-DEV] disabling ereg

On 01/10/2012 11:33 AM, Philip Olson wrote: > Any objections? Regardless of deprecation status, this option > should be available. Or if not, why? The main reason is that we are not done removing all the dependencies. This is a large deprecation that is going to require the process to span multipl

Re: [PHP-DEV] Re: 5.3.9, Hash DoS, release

On 01/09/2012 05:28 PM, Xinchen Hui wrote: >> I understand the difference. But large arrays are obviously the ones >> that are prone to hitting the collision limits. > Yes, but don't you think this is at least better than restricting > number of elements? :) The difference is the source. If, for e

Re: [PHP-DEV] Re: 5.3.9, Hash DoS, release

On 01/09/2012 09:18 AM, Xinchen Hui wrote: > Sent from my iPhone > > 在 2012-1-10，1:14，Rasmus Lerdorf 写道： > >> On 01/09/2012 08:50 AM, Xinchen Hui wrote: >>> Hi: >>>I am not sure whether you have understood my point. >>> >>>If

Re: [PHP-DEV] Re: 5.3.9, Hash DoS, release

On 01/09/2012 08:50 AM, Xinchen Hui wrote: > Hi: > I am not sure whether you have understood my point. > > If an array have more than 1024 buckets in an same bucket > list(same index), there must already be an performance issue. The problem is you really need to consider the source. There

Re: [PHP-DEV] Re: another fix for max_input_vars.

On 01/04/2012 11:49 PM, Laruence wrote: > Hi: > there is one way maybe is a good try. > > when resize hashtable, we don't just dobule the size, instead, we > increase the hashtable size with a random delta > > what do you think? Sorry, you lost me. How does that help? The problem is when

Re: [PHP-DEV] Re: another fix for max_input_vars.

On 01/04/2012 11:33 PM, Stas Malyshev wrote: > Hi! > >> Yes, but we still need an actual case to look at. Opcode caches >> shouldn't be a problem unless they store some representation on disk >> that live across server restarts. In the APC world, nobody does that. Is > > It's not that simple. Tak

Re: [PHP-DEV] Re: another fix for max_input_vars.

On 01/04/2012 11:09 PM, Stas Malyshev wrote: > Hi! > >> I really don't think this manual per-feature limiting is going to cut it >> here. The real problem is the predictability of the hashing which we can >> address by seeding it with a random value. That part is easy enough, the >> hard part is f

Re: [PHP-DEV] Re: another fix for max_input_vars.

On 01/04/2012 08:13 PM, Laruence wrote: > On Thu, Jan 5, 2012 at 5:56 AM, Rasmus Lerdorf wrote: >> On 01/04/2012 01:48 PM, Rasmus Lerdorf wrote: >>> On 01/04/2012 01:27 PM, Stas Malyshev wrote: >>>> Hi! >>>> >>>>> Right,

Re: [PHP-DEV] Re: another fix for max_input_vars.

On 01/04/2012 01:48 PM, Rasmus Lerdorf wrote: > On 01/04/2012 01:27 PM, Stas Malyshev wrote: >> Hi! >> >>> Right, like I said in my previous message, if this is caught by >>> display_start_errors, I am ok with it. We need the default/no php.ini >>> f

Re: [PHP-DEV] Re: another fix for max_input_vars.

On 01/04/2012 01:27 PM, Stas Malyshev wrote: > Hi! > >> Right, like I said in my previous message, if this is caught by >> display_start_errors, I am ok with it. We need the default/no php.ini >> file case to not leak information like this. > > Just checked - it does not display error if display_

Re: [PHP-DEV] Re: another fix for max_input_vars.

On 01/04/2012 01:01 PM, Ferenc Kovacs wrote: > I just got the tip that this error is only shown > if display_startup_errors is set to true, and because it is in the > startup routine the file path in the error message (which is the real > infoleak) would only point to "unknown 0". > If somebody has

Re: [PHP-DEV] Re: another fix for max_input_vars.

On 01/04/2012 12:46 PM, Johannes Schlüter wrote: > On Wed, 2012-01-04 at 12:29 -0800, Stas Malyshev wrote: >> Hi! >> >>> But there is a very valid security concern here. People can usually run >>> safely with display_errors enabled if their code is well-written. They >> >> Oh no. Nobody should or c

Re: [PHP-DEV] Re: another fix for max_input_vars.

On 01/04/2012 12:19 PM, Reindl Harald wrote: > > > Am 04.01.2012 21:07, schrieb Paul Dragoonis: > >> I agree with Rasmus here. A lot of people keep display_errors >> on, even when they shouldn't. > > it is not the job of a programming language stop admins from > beeing stupid - the defaults hav

Re: [PHP-DEV] Re: another fix for max_input_vars.

On 01/04/2012 11:54 AM, Nikita Popov wrote: > On Wed, Jan 4, 2012 at 8:50 PM, Rasmus Lerdorf wrote: >> Since it is one of these remotely-triggered errors that you can't >> program around, it should probably be suppressed when display_errors is >> on. There is another pre

Re: [PHP-DEV] Re: another fix for max_input_vars.

On 01/04/2012 11:46 AM, Ferenc Kovacs wrote: > On Wed, Jan 4, 2012 at 8:37 PM, Stas Malyshev wrote: > >> Hi! >> >> >> Could you please elaborate on that part - where is the disclosure >>>and what exactly is being disclosed? >>> >>> >>> I would guess that the value of that said limit. (it i

Re: [PHP-DEV] Return Type Hinting for Methods RFC

On 12/22/2011 11:49 AM, John Crenshaw wrote: > From: Rasmus Lerdorf [mailto:ras...@lerdorf.com] > >> How is that hard? >> >> function age_lookup($age) { >> return $coll->find(array('age' => (int)$age); >> } >> >> but aga

Re: [PHP-DEV] Return Type Hinting for Methods RFC

On 12/22/2011 11:20 AM, Dmitri Snytkine wrote: > Not sure what you mean by json wrapped. > In mongo you do $coll->find(array('age' => $age); > > if $age is a string '21' your will not get any erros but neither will you > get any results. It is json underneath, but in your find() example, obviousl

Re: [PHP-DEV] Return Type Hinting for Methods RFC

On 12/22/2011 11:18 AM, Will Fitch wrote: > On Dec 22, 2011, at 1:41 PM, Rasmus Lerdorf wrote: > >> On 12/22/2011 07:08 AM, Keloran wrote: >>> i would love to see this expanded aswell (the way type hinting on function >>> variables was supposed to be), so that i

Re: [PHP-DEV] Return Type Hinting for Methods RFC

On 12/22/2011 10:51 AM, Sebastian Bergmann wrote: > Am 22.12.2011 19:41, schrieb Rasmus Lerdorf: >> This is not a step forward. If the author of age_check() really doesn't >> want to accept type-juggled arguments, then it is easy enough to do a >> strict type check in

Re: [PHP-DEV] Return Type Hinting for Methods RFC

On 12/22/2011 07:08 AM, Keloran wrote: > i would love to see this expanded aswell (the way type hinting on function > variables was supposed to be), so that it could be > > string, int > > e.g. > function int test(bool $tester) { > if ($tester) { return 5; } > return 99; > } Return type hintin

Re: [PHP-DEV] Is Bug #34972 (no non-blocking on STDIN on Windows) going to be fixed?

It is non-trivial to implement on Windows. It is more of a feature request than a bug. UNIX supports non-blocking stdin natively, Windows doesn't. A Windows guy would need to write a compatibility layer to get this to work and we don't have very many Windows guys around. -Rasmus On Dec 8, 2011

Re: [PHP-DEV] Phalanger

On 12/08/2011 03:53 PM, Rasmus Lerdorf wrote: > This is a complete non-starter. The bulk of PHP users are on > non-Windows, especially Linux, and Mono performance on Linux is really > not good. Last time I checked it was an order of magnitude slower on > Linux compared to the same hard

Re: [PHP-DEV] Phalanger

On 12/08/2011 03:28 PM, Rasmus Schultz wrote: > Don't take this the wrong way, I'm merely trying to provoke your thoughts a > bit with this e-mail! :-) > > Has it occurred to anyone, to abandon the official PHP codebase and adopt > Phalanger instead? > > Some convincing (to me) points: > > - Pha

Re: [PHP-DEV] Will apc.optimization ever be put back to APC?

On 12/03/2011 10:28 AM, Dmitri Snytkine wrote: > APC is great, APC definetely speeds up the php a lot but I just remember that > there used to be also optimization options. > I remember the days where eAccelerator and php accelerator and mmcache were > popular. They all had code optimization opt

Re: [PHP-DEV] 5.4's New De-referencing plus assignment

On 12/02/2011 08:50 AM, Matthew Weier O'Phinney wrote: > if (!(($validator = new SomeValidator())->isValid($value))) { > // Validation failed, get messages... > $view->assign('errors' => $validator->getMessages()); > return $view->render('error'); > } > // valida

Re: [PHP-DEV] Strict session?

On 12/01/2011 02:38 AM, Yasuo Ohgaki wrote: > Hi Daniel, > > 2011/12/1 Daniel K. : >> Yasuo Ohgaki wrote: >>> >>> I've made the patch for trunk. I checked by using session module >>> tests using valgrind. >>> >>> https://gist.github.com/1379668 >> >> >> As a general comment there seems to be lots

Re: [PHP-DEV] New dereferencing syntaxes in 5.4

On 11/29/2011 05:22 PM, de...@lucato.it wrote: > Hi Rasmus, > > I already tested a similar example (see > http://codepad.viper-7.com/tNkTTX) but I'm getting Sorry, pasting something into codepad doesn't qualify as testing. You have no idea how and when they built the 5.4 they are running. Until

Re: [PHP-DEV] New dereferencing syntaxes in 5.4

On 11/29/2011 04:49 PM, de...@lucato.it wrote: > Hi, > > is the new dereferencing syntax definitely part of 5.4 ? > > Will it be possible to replace this: > > $model = new DomainModel('foo', 'bar'); > $result = $model->findByName('John'); > > with: > > $result = (new DomainModel('foo', 'bar'))

Re: [PHP-DEV] 5.4 regression: non-existent sub-sub keys now have values

On 11/24/2011 02:03 PM, Larry Garfield wrote: > Generally $foo, bar, and baz will all be arrays, and if they're not it > means someone else had a bug somewhere. Of course, Drupal module > developers never have bugs in their code that accidentally puts a string > where they should have put an array

Re: [PHP-DEV] 5.4 regression: non-existent sub-sub keys now have values

On 11/24/2011 01:44 PM, Yasuo Ohgaki wrote: > Hi all, > > I should think twice before seding mail. "abc" as array index is > converted to 0 since it's not a integer. So with current code is > behave consistently with regards to string to long conversion. > > However, > > PHP 5.3 > php -r '$s = "

Re: [PHP-DEV] 5.4 regression: non-existent sub-sub keys now have values

On 11/24/2011 01:08 PM, Pierre Joye wrote: > hi Rasmus, > > On Thu, Nov 24, 2011 at 9:35 PM, Rasmus Lerdorf wrote: > >> I had a quick look through the Drupal code. I don't see a single place >> that this is done where a deeply nested array index is applied to

Re: [PHP-DEV] 5.4 regression: non-existent sub-sub keys now have values

On 11/24/2011 12:12 PM, Larry Garfield wrote: > On 11/23/2011 12:13 PM, Lester Caine wrote: >> Richard Quadling wrote: >>> I agree with Daniel on this. >>> >>> Just looking for any test relating to isset() to see what tests will >>> now fail. >> >> So it's not just me :) >> I am seeing this break r

Re: [PHP-DEV] Results of testing ZF against PHP 5.4.0RC1

On 11/17/2011 03:10 PM, Stas Malyshev wrote: > Hi! > >> I recall from earlier discussions that Stas was in favor of reverting >> this change -- what's the status at this time? This single change > > I was not and still am not - I think if something warrants notice this > is exactly the ca

Re: [PHP-DEV] [PATCH] Making in_array a language operator

On 11/13/2011 10:08 AM, Pierre Joye wrote: > 2011/11/13 Antoine Delignat-Lavaud : >> So this means being able to use $string->strlen() (or even $string->len()) >> instead of strlen($string) or $array->in_array($x) ($array->in($x)) instead >> of in_array($x,$array), right? > > Yes, that's the idea,

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

All the ob_* tests are still in 5.4 and they all pass, so no, these functions have not been removed. On 11/13/2011 07:26 AM, Reindl Harald wrote: > > > Am 13.11.2011 16:11, schrieb Laruence: >> Hi: >> >> this revisioin remove the ob_* functions: >> http://svn.php.net/viewvc?view=revision&revis

[PHP-DEV] ext/standard/tests/http tests

Hey Gustavo, you added a simple http server and some tests a year ago. I think we have some bitrot on them as they are all failing for me and also on gcov: http://gcov.php.net/viewer.php?version=PHP_5_4&func=tests&file=ext%2Fstandard%2Ftests%2Fhttp%2Fbug38802.phpt http://gcov.php.net/viewer.php?ve

Re: [PHP-DEV] Load extensions for .user.ini files

Well, it is simple enough that we don't really need a patch. However, generally if you want to submit a patch it needs to be against a current svn branch and not an old release. You want to minimize the work people will need to do to look at your suggested change. The other issue with your patch i

Re: [PHP-DEV] Load extensions for .user.ini files

Which branch in this patch against? It doesn't apply to 5_3/5_4/trunk It is short and simple so I could do it manually, of course, but I'd like to know what you have been testing it against. On 11/10/2011 07:14 PM, Edward Z. Yang wrote: > Here is the proposed patch (sans tests; we did our own man

[PHP-DEV] Hash problems in session-oo code

Hey Arpad, looking through the code you added to ext/standard/basic_functions.c it looks like you are doing some weird key handling in the shutdown function hash. In register_user_shutdown_function() you have: zend_hash_update(BG(user_shutdown_function_names), function_name, sizeof(function_name)

Re: [PHP-DEV] who can vote

On 11/10/2011 01:17 PM, Pierre Joye wrote: > If that's not the case, and after a 2nd thought, it is actually not > the case, then we can just discard this whole thread and go back to > code and proposals. I only find very disturbing to have to explain and > argue so many times about that only beca

Re: [PHP-DEV] who can vote

On 11/10/2011 10:38 AM, Pierre Joye wrote: > On Thu, Nov 10, 2011 at 7:18 PM, Rasmus Lerdorf wrote: > >> We are not talking about a specific RFC here. This discussion is about >> changing the current way of voting. > > Yes, and that's what I'm talking ab

Re: [PHP-DEV] Patch for Bug #60164 / Phar __HALT_COMPILER() scanning issue

On 11/10/2011 11:44 AM, Ralph Schindler wrote: > Hey all, > > I've spent a bunch of time tracking down this issue (which was > intermittent at best) and have identified the problem and have a patch > for the solution. > > Details here: https://bugs.php.net/bug.php?id=60164 > > The attached patch

Re: [PHP-DEV] who can vote

On 11/10/2011 09:44 AM, Pierre Joye wrote: > That's another myth spread by the opponents of making our process > open. All RFCs proposed has been proposed with patches, implemented by > the proposers, with or without the help of other core developers. > Nobody ever succeed (except the alternative a

Re: [PHP-DEV] who can vote

On 11/10/2011 05:53 AM, guilhermebla...@gmail.com wrote: > I don't think so. You have classified that php-src have more weight in > voting because they do the biggest effort. > That's great, but you're forgetting that php-doc, php-web and php-test > do have a lot of effort too. > The fact when it c

Re: [PHP-DEV] who can vote

On 11/10/2011 12:36 AM, Pierre Joye wrote: > The last example of such a case is the SplClassLoader, the gap between > our communities and us is getting even larger. I think it is time to > consider their views and voices, especially as we get new contributors > (you know, the people actually doing

Re: [PHP-DEV] who can vote

On 11/09/2011 07:01 PM, guilhermebla...@gmail.com wrote: > My short version of this entire email is very simple question. Is PHP > meritocracy based? It is. > I want to highlight another RFC where I saw the before mentioned > meritocracy fallen into the cracks. > http://wiki.php.net/rfc/shortsynt

Re: [PHP-DEV] PHP CLI + Valgrind = FAIL

I think it is a new thing in Valgrind 3.7 On 11/08/2011 02:23 PM, Yasuo Ohgaki wrote: > Hi Stats, > > New gmail's, wordwrap and message display/sync, is killing me... > > Anyway, I've been using valgrind on my osx 10.6 with PHP 5.3 for a > while and I don't have startup problem with PHP 5.4 like

Re: [PHP-DEV] PHP CLI + Valgrind = FAIL

On 11/08/2011 09:42 AM, Stas Malyshev wrote: > Hi! > >> On 11/08/2011 01:39 AM, Florian Anderiasch wrote: >>> So it looks like only FPM uses it for more than the default behaviour of >>> "terminate", from a quick glance. >> Not deferring SIGUSR2 just because valgrind on OSX doesn't like it isn't >

Re: [PHP-DEV] PHP CLI + Valgrind = FAIL

On 11/08/2011 01:39 AM, Florian Anderiasch wrote: > So it looks like only FPM uses it for more than the default behaviour of > "terminate", from a quick glance. Well, it is part of the new 5.4 signal handling code that defers these signals, including SIGUSR2, when inside a critical section. In ord

Re: [PHP-DEV] Load extensions for .user.ini files

On 11/08/2011 12:46 AM, Edward Z. Yang wrote: > Excerpts from Rasmus Lerdorf's message of Tue Nov 08 03:40:17 -0500 2011: >> You are aware that these extensions can't be unloaded, right? So one >> user loading an extension will potentially be stepping on another user >> and breaking their code. >

Re: [PHP-DEV] Load extensions for .user.ini files

On 11/08/2011 12:23 AM, Edward Z. Yang wrote: > Hello all, > > My team is interested in permitting .user.ini files to load > extensions. We believe this to be a simple fix: add > an invocation of php_ini_register_extensions to the end > of sapi/cgi/cgi-main.c. > > I don't believe this steps on a

Re: [PHP-DEV] PHP CLI + Valgrind = FAIL

On 11/07/2011 09:23 PM, Stas Malyshev wrote: > Hi! > > I've noticed that if I run PHP 5.4 under Valgrind on my Mac, I get this: > > Fatal error: Error installing signal handler for 31 in Unknown on line 0 > Could not startup. > > Indeed, valgrind says: > ==47112== Warning: ignored attempt to set

Re: [PHP-DEV] SplClassLoader RFC Voting phase

On 11/07/2011 07:04 PM, Larry Garfield wrote: > If anything, the low degree of communication between "people who write > PHP" and "people who write in PHP" is, and has long been, one of PHP's > great weaknesses. I think this entire thread has shown that very well. > That is something that needs

Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] CI for 5.4

On 11/03/2011 03:47 PM, Ferenc Kovacs wrote: > A, it will report every test failure, but we fix all of our tests so we > are cool. (my preference) But even if we do that, when a test does fail, it may take a couple of days to fix it. It would be nice if we didn't get an internals email for every c

Re: [PHP-DEV] Re: [PHP-QA] Re: [PHP-DEV] CI for 5.4

On 11/03/2011 02:26 PM, Ferenc Kovacs wrote: > We could set up the email notification any time, we would just have to > agree where to send (internals, php-qa, creating a dedicated mailing list?) > and when to send (as I added to the RFC, having failing tests can be a > problem from the notificatio

Re: [PHP-DEV] is_a fix for 5.4 and HEAD

On 10/13/2011 04:54 PM, Alan Knowles wrote: > On Thursday, October 13, 2011 11:23 PM, Stas Malyshev wrote: >> On 10/13/11 12:39 AM, Alan Knowles wrote: >>> Can someone apply this to HEAD and PHP_5_4, or let me have karma. >>> >>> https://bugs.php.net/patch-display.php?bug_id=55475&patch=final_patch

Re: [PHP-DEV] open_basedir bypass -> errata tempnam()

Reindl, please read http://www.unicom.com/pw/reply-to-harmful.html The list is configured correctly. On 09/28/2011 07:42 AM, Reindl Harald wrote: > > Am 28.09.2011 16:19, schrieb Hannes Magnusson: >> On Wed, Sep 28, 2011 at 00:39, Reindl Harald >> wrote: >>> PLEASE REPLY ONLY TO THE LIST >> >>

Re: [PHP-DEV] Question about ABI compatibility for an ext/xsl patch and an API question for the implementation

This sounds like the best approach actually. On Sep 27, 2011, at 7:03 AM, Christian Stocker wrote: > Hi again > > I just had the idea for a 4th option. Won't be less controversy, but > it's backwards and forwards compatible. > > 4) use a php ini setting in PHP 5.3 > > I know, we try to avoid

Re: [PHP-DEV] Re: is_a() - again - a better fix

On 09/23/2011 08:20 PM, Christopher Jones wrote: > > > On 09/23/2011 11:17 AM, Rasmus Lerdorf wrote: >> On 09/23/2011 07:13 PM, Christopher Jones wrote: >>> >>> >>> On 09/23/2011 09:15 AM, Matthew Weier O'Phinney wrote: >>> >>&g

Re: [PHP-DEV] Re: is_a() - again - a better fix

On 09/23/2011 08:20 PM, Christopher Jones wrote: > > > On 09/23/2011 11:17 AM, Rasmus Lerdorf wrote: >> On 09/23/2011 07:13 PM, Christopher Jones wrote: >>> >>> >>> On 09/23/2011 09:15 AM, Matthew Weier O'Phinney wrote: >>> >>&g

Re: [PHP-DEV] Re: is_a() - again - a better fix

On 09/23/2011 07:13 PM, Christopher Jones wrote: > > > On 09/23/2011 09:15 AM, Matthew Weier O'Phinney wrote: > >> I could also see this being an interesting peer-pressure move -- "First >> to test!", "We tested last week; how come _you_ haven't?", etc. > > Speaking of testing, the commit > htt

Re: [PHP-DEV] Re: is_a() - again - a better fix

On 09/23/2011 12:17 PM, Pierre Joye wrote: > We do 2) already (while we are working on increasing the amount of > apps and frameworks being tested), as I was asking to revert this > patch between 5.3.7 and 5.3.8 back then pointing to our tests results > and numerous reports. The problem was not in

Re: [PHP-DEV] Re: is_a() - again - a better fix

On 09/23/2011 12:13 PM, Patrick ALLAERT wrote: > 2011/9/23 Rasmus Lerdorf >> 2. Maybe we should think bigger and put more focus on having large PHP >> frameworks and apps test every RC. Currently we notify them of RCs >> and just hope someone will test and report bac

Re: [PHP-DEV] Re: is_a() - again - a better fix

On 09/23/2011 01:37 AM, Alan Knowles wrote: > This patch adds an extra parameter 'allow_string' to is_a (default off) > and is_subclass_of (default on) , > > https://bugs.php.net/patch-display.php?bug_id=55475&patch=Is_a_with_allow_string_argument_v3&revision=latest >

Re: [PHP-DEV] Re: is_a() - again - a better fix

I don't see the harm in reverting back to the previous behaviour in the 5.3 tree. It's not like it will break code that has been fixed to work with the new behaviour. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RESULT] Choosing a distributed version control system for PHP

On 09/07/2011 11:15 PM, dukeofgaming wrote: > Awesome news, this particular decision tends not to be an easy one in open > source software communities (well, perhaps now it is easier with all the > traction git & github have) so I think this is evidence of how good the RFC > process is. > > Is the

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

On 09/07/2011 02:12 PM, Stas Malyshev wrote: > But it doesn't send SIGPROF by itself. Looks like Darwin got screwed up > itimer implementation at least up to kernel 10.8.0, Mac OS X 10.6.8. > Didn't try it on Lion, maybe the have updated/fixed it. Right, so we need to decide what to do about that.

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

On 09/07/2011 01:32 PM, Stas Malyshev wrote: > Hi > > On 9/7/11 1:17 PM, Rasmus Lerdorf wrote: >> >> Interesting that this is different on Darwin. That doesn't seem like >> something that should be OS-specific unless Darwin's itimer >> implementation is

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

On 09/07/2011 01:04 PM, Stas Malyshev wrote: > Hi! > > On 9/7/11 12:43 PM, Rasmus Lerdorf wrote: >> Actually, it seems to be more than that. That set_time_limit() just >> speeds up the test. Since we have a default max_execution_time you >> should still have hit tha

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

On 09/07/2011 12:28 PM, Stas Malyshev wrote: > Hi! > > On 9/7/11 12:24 PM, Rasmus Lerdorf wrote: >>> tests/lang/045.phpt now works for me, but tests/func/005a.phpt still >>> fails. It's on Darwin. >> >> That one doesn't fail for me. What's

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

On 09/07/2011 12:28 PM, Stas Malyshev wrote: > Hi! > > On 9/7/11 12:24 PM, Rasmus Lerdorf wrote: >>> tests/lang/045.phpt now works for me, but tests/func/005a.phpt still >>> fails. It's on Darwin. >> >> That one doesn't fail for me. What's

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

On 09/07/2011 12:16 PM, Stas Malyshev wrote: > Hi! > > On 9/7/11 11:54 AM, Rasmus Lerdorf wrote: >> Please help me figure out if this fix causes any weird side-effects >> anywhere. Essentially the problem is that the new deferred signals >> patch ignores signals when r

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

e. By pretending not to be running a signal handler when we call the shutdown functions we can re-enable timeouts here. On 09/07/2011 11:48 AM, Rasmus Lerdorf wrote: > rasmus Wed, 07 Sep 2011 18:48:17 + > > Revision: http://svn.php.net/viewvc?view=revision&a

Re: [PHP-DEV] mysqli tests breaking

On 09/05/2011 08:07 AM, Andrey Hristov wrote: > and here we see a bug. The value in libmysql is not reset, as the > Documentation states. Clear bug. For cases where a test exposes a libmysql bug, especially if it is something that acts differently across different versions of libmysql, the test s

Re: [PHP-DEV] Make mysqlnd default over libmysql in 5.4

On 09/03/2011 12:15 AM, Lester Caine wrote: > My SUSE installs all have mysqlnd included in the core, As do other > Linux distributions. I think for much the same reason that the windows > builds do as well? The PHP development team have decided that > -without-mysqlnd is required to remove it rath

Re: [PHP-DEV] Make mysqlnd default over libmysql in 5.4

On 09/02/2011 11:48 PM, Lester Caine wrote: > Stas Malyshev wrote: >> libmysql *is* the common case build and the one most people would be >> running in >> production, at least as far as I see around. > In the words of wikipedia - provide proof. > If this is the case then why is mysqlnd loaded by d

Re: [PHP-DEV] Make mysqlnd default over libmysql in 5.4

On 09/02/2011 11:43 PM, Lester Caine wrote: > All builds seem to have mysqlnd included by default? So that has to be > tested on every installation even if it's not going to be used? And I've > hit problems with distributions needing MySQL because of a dependency on > mysqlnd. > > I know we have h

Re: [PHP-DEV] Make mysqlnd default over libmysql in 5.4

On 09/02/2011 06:08 PM, Stas Malyshev wrote: > Hi! > > On 9/2/11 6:02 PM, Rasmus Lerdorf wrote: >> Well, we are not trying to get to 0 failed tests in all permutations of >> all extensions on all platforms. We are trying to get to 0 failed tests >> on a common-case buil

Re: [PHP-DEV] Make mysqlnd default over libmysql in 5.4

On 09/02/2011 05:56 PM, Stas Malyshev wrote: > Hi! > > On 9/2/11 4:45 PM, Rasmus Lerdorf wrote: >> One of the goals before the beta is to get to 0 failed tests for a >> common build. Unless you simply skip all the failing libmysql tests, >> that's going to be hard

Re: [PHP-DEV] Make mysqlnd default over libmysql in 5.4

On 09/02/2011 05:56 PM, Stas Malyshev wrote: > Hi! > > On 9/2/11 4:45 PM, Rasmus Lerdorf wrote: >> One of the goals before the beta is to get to 0 failed tests for a >> common build. Unless you simply skip all the failing libmysql tests, >> that's going to be hard

Re: [PHP-DEV] Make mysqlnd default over libmysql in 5.4

On 09/02/2011 01:17 PM, Lester Caine wrote: > Rasmus Lerdorf wrote: >> I was actually going to suggest doing this in 5.4 and trunk but didn't >> get around to writing the email yet. > > It would still be nice to be able to simply switch off MySQL for those > of us

Re: [PHP-DEV] Make mysqlnd default over libmysql in 5.4

On 09/02/2011 12:24 PM, Stas Malyshev wrote: > Hi! > > On 9/2/11 12:17 PM, Christopher Jones wrote: >> I'm +1 for this. I think the decision& implementation needs to be done >> before Beta or deferred to trunk. > > Frankly, I'd be more comfortable with trunk. We have enough trouble with > unit

Re: [PHP-DEV] Make mysqlnd default over libmysql in 5.4

On 09/02/2011 05:27 AM, Johannes Schlüter wrote: > Hi, > > when building PHP using > (I) ./configure --with-mysql --with-mysqli --with-pdo-mysql > you currently get a build using the system default libmysql, usually > in /us or > such. Alternatively PHP can be built using > (II) ./configure --w

[PHP-DEV] 2 new test failures

Pierre, your changes today caused 2 new test failures: Bug #51709 (Can't use keywords as method names) [tests/basic/bug51709_1.phpt] Bug #51709 (Can't use keywords as method names) [tests/basic/bug51709_2.phpt] The diffs: 001+ Parse error: syntax error, unexpected 'for' (T_FOR), expecting identi

Re: [PHP-DEV] 5.4 beta & tests

I am down to 34 test failures compiling against mysqlnd instead of libmysql http://codepad.org/ZV8imUuc I did have to set MYSQL_TEST_SOCKET=/var/run/mysqld/mysqld.sock in my environment though. It was defaulting to /tmp/mysql.sock -Rasmus -- PHP Internals - PHP Runtime Development Mailing List

Re: [PHP-DEV] 5.4 beta & tests

On 08/30/2011 10:08 PM, Stas Malyshev wrote: > Hi! > > On 8/30/11 9:53 PM, Stas Malyshev wrote: >> strftime() on Mac seems to ignore timezone arguments in struct tm for >> some reason and uses environment TZ instead. Not sure how to address >> that. > > Looking into Mac strftime sources, it says

Re: [PHP-DEV] 5.4 beta & tests

On 08/30/2011 08:39 PM, Stas Malyshev wrote: > Hi! > > I've checked the unit tests on my Mac and I see 48 failures so far. I've > put them here: > https://wiki.php.net/todo/tests54?&#tested_2011-08-30_on_mac_os_x > > Most of them are mysql, but others too. > So, is there anybody working or willin

Re: [PHP-DEV] 5.4 beta

associated with bug reports anyway so it's not > like they'd get lost forever. > > Nat > > On Mon, Aug 29, 2011 at 4:39 PM, Rasmus Lerdorf <mailto:ras...@lerdorf.com>> wrote: > > On 08/29/2011 12:23 AM, Stas Malyshev wrote: > > Hi! >

Re: [PHP-DEV] 5.4 beta

On 08/29/2011 12:23 AM, Stas Malyshev wrote: > Hi! > > On 8/28/11 11:06 PM, Rasmus Lerdorf wrote: >> I would really like to see the number of failed tests hit 0 before we >> even consider a 5.4 beta release. It shouldn't take that long to fix the >> remaining tests

Re: [PHP-DEV] 5.4 beta

On 08/28/2011 10:34 PM, Stas Malyshev wrote: > According to our release plan, we are planning to release the 5.4 beta > this week on September 1st, which means it'll be packaged on Wednesday > Aug 31st. If you have any TODO items you want in, please do it before that. I would really like to see th

Re: [PHP-DEV] ext_skel on Fedora

On 08/26/2011 05:09 PM, Aaron Gray wrote: > I cannot seem to find 'ext_skel' or 'PECL_Gen' on my F11 instillation of > php-devel ? No idea what F11 does, but it is in the source tarball. Just download it from php.net. -Rasmus -- PHP Internals - PHP Runtime Development Mailing List To unsubscrib

Re: [PHP-DEV] Why the autoconf <= 2.59 check?

On 08/24/2011 04:08 PM, Edwin van Vliet wrote: > In commit 09e803c it is unfortunately unclear exactly why support for > "newer" autoconf is somehow dropped. Since autoconf 2.60 was released > Mon, 26 Jun 2006, this means PHP 5.3.8 needs to be built with software > more than 5 years old. By itself

[PHP-DEV] SVN Downtime

You may have noticed we had some downtime on svn.php.net today. It started around 16:30 Pacific time and we finally got the box back up at around 23:35. It turned out that the onboard RAID controller had gone bad which wasn't completely obvious initially. Sitting there staring at an fsck and wonde

Re: [PHP-DEV] Failing Autotests / Bugs

On 08/23/2011 09:45 AM, Daniel Convissor wrote: > Hi: > > On Sun, Aug 21, 2011 at 03:08:09PM +0200, Reindl Harald wrote: >> FAIL DateTime::diff() days -- spring type2 type2 >> [ext/date/tests/DateTime_days-spring-type2-type2.phpt] >> FAIL DateTime::diff() days -- spring type2 type3 >> [ext/date/

Re: [PHP-DEV] 5.3.7pl1

On 08/19/2011 04:16 PM, Stas Malyshev wrote: > Hi! > > Looks like 5.3.7 shipped with broken crypt() (see bug# 55439 and > http://svn.php.net/viewvc/?view=revision&revision=315218) - and I > think it's a serious problem since this means everybody's md5 passwords > will stop working - so should we m

<    1   2   3   4   5   6   7   8   9   10   >