Le jeudi 26 février 2009 à 20:27 +, Robin Burchell a écrit :
> I've been playing around with autoload lately, and specifically using
> autoload to load classes which may be in subdirectories. I came up
> with the following test script:
The best solution for you is to wait for PHP 5.3.0, then u
So, my understanding of the shut-up operator was that it temporarily set
error_reporting to zero, so you could define a custom error handler that
would do the equivalent simply by not honoring error_reporting = 0.
Something that would be more useful, and that I don't think is
implementable in PHP,
On Feb 26, 2009, at 7:21 PM, Greg Beaver wrote:
Pierre Joye wrote:
Hi,
What's about adding what screan (http://pecl.php.net/scream) to the
standard PHP? Everyone needs it and it should be possible to do that
without having to install an extension.
Comments/objections?
If it can be done easily an
Pierre Joye wrote:
> Hi,
>
> What's about adding what screan (http://pecl.php.net/scream) to the
> standard PHP? Everyone needs it and it should be possible to do that
> without having to install an extension.
>
> Comments/objections?
If it can be done easily and unobtrusively to existing code,
I'm just wondering why you appreciate the new behavior. Are there
still any positive reasons to incorporate the change? Could anyone
provide some example that the new behavior works better than the
original?
By the way, I noticed that SORT_REGULAR behaves differently than
SORT_STRING if the items
On Feb 26, 2009, at 5:58 AM, Rodrigo Saboya wrote:
Ronald, I think you are overreacting a little bit. It may be that
proper written could would get no benefit from this patch since it
would not load unneeded code and this patch ends up speeding up
environments where such "correct" loading is
The PHP development team would like to announce the immediate
availability of PHP 5.2.9. This release focuses on improving the
stability of the PHP 5.2.x branch with over 50 bug fixes, several of
which are security related. All users of PHP are encouraged to upgrade
to this release.
Secur
Hi!
I don't see any problem here - as it wouldn't have an collusion to any
in-the-past-written-code.
Am 27.02.2009 um 00:42 schrieb Richard Quadling >:
Hi.
Can anyone take a look at http://bugs.php.net/bug.php?id=47493 and
tell me if I'm on the right track with this?
Regards,
Richard.
2009/2/27 Ilia Alshanetsky :
> Compile a shopping list? How frequently are you deploying PHP? ;-) Even if
> you need to compile 4-5 PECL extensions its probably something you do only
> every few months anyway.
> We used to have PECL win32 binaries, I don't see them on windows.php.net,
> but perhaps
On Fri, Feb 27, 2009 at 1:16 AM, Ilia Alshanetsky wrote:
> Compile a shopping list? How frequently are you deploying PHP? ;-) Even if
> you need to compile 4-5 PECL extensions its probably something you do only
> every few months anyway.
> We used to have PECL win32 binaries, I don't see them on w
Compile a shopping list? How frequently are you deploying PHP? ;-)
Even if you need to compile 4-5 PECL extensions its probably something
you do only every few months anyway.
We used to have PECL win32 binaries, I don't see them on
windows.php.net, but perhaps they are else where.
Based on
Hi.
Can anyone take a look at http://bugs.php.net/bug.php?id=47493 and
tell me if I'm on the right track with this?
Regards,
Richard.
--
-
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498&r=213474731
"Standing on the shoulders of some very clever giants!"
--
2009/2/26 Ilia Alshanetsky :
> While a very useful feature, I think people who need it definitely will have
> the ability to run 2-3 commands that it takes to install a PECL extension.
>
> Ilia Alshanetsky
>
>
> On 26-Feb-09, at 6:28 PM, Pierre Joye wrote:
>
>> Hi,
>>
>> What's about adding what sc
While a very useful feature, I think people who need it definitely
will have the ability to run 2-3 commands that it takes to install a
PECL extension.
Ilia Alshanetsky
On 26-Feb-09, at 6:28 PM, Pierre Joye wrote:
Hi,
What's about adding what screan (http://pecl.php.net/scream) to the
st
Moriyoshi,
First of thank you for taking the time to provide examples regarding
the issues you are demonstrating. I've looked at a number of different
applications and have not found a functionality breakage due to this
change. While your example does show a change, I am not convinced
(so
Hi,
What's about adding what screan (http://pecl.php.net/scream) to the
standard PHP? Everyone needs it and it should be possible to do that
without having to install an extension.
Comments/objections?
Cheers
--
Pierre
http://blog.thepimp.net | http://www.libgd.org
--
PHP Internals - PHP Run
I think what you're doing is effectively the same as doing:
$fb = new Part .''. SubPart();
So basically concatenating a new instance of Part, with the results
from the function SubPart. Try defining Part as a class and see what
error you get. If I'm right, you'll get an undefined function error.
On Thu, Feb 26, 2009 at 8:48 PM, Guilherme Blanco
wrote:
> I doubt you'll find a patch to it.
>
> Mainly, the patch will be against this principle:
>
Hmm, that wouldn't actually have an impact, as (at least, what I'm
aiming for/wanting to do) is not to introduce periods as valid in
actual class
2009/2/26 Robin Burchell
> Hi all,
>
> I've been playing around with autoload lately, and specifically using
> autoload to load classes which may be in subdirectories. I came up
> with the following test script:
>
>
> function __autoload($sName)
> {
>echo "autoloading " . $sName . "\n";
I doubt you'll find a patch to it.
Mainly, the patch will be against this principle:
wrote:
> Hi all,
>
> I've been playing around with autoload lately, and specifically using
> autoload to load classes which may be in subdirectories. I came up
> with the following test script:
>
>
> function _
Hi all,
I've been playing around with autoload lately, and specifically using
autoload to load classes which may be in subdirectories. I came up
with the following test script:
The first line demonstrates what I'm after ("autoloading Foo.Bar"),
and the second seems to give a bit of an odd/incor
shire wrote:
> I agree for the general case, in our development environment though this
> might cause some pains. But we could always start there and see how it
> goes. I agree that Xdebug isn't really a use case we always need to
> optimize for.
Is it ever a case we need to optimize for? If y
On Fri, Feb 27, 2009 at 3:58 AM, Moriyoshi Koizumi wrote:
> 1. array_unique() has never been supposed to handle values other than
> strings. That's how bug #10658 is handled.
That's not what I really wanted to mean. I should have said "not
supposed to handle values other than scalars".
Moriyoshi
Rasmus Lerdorf wrote:
shire wrote:
I agree for the general case, in our development environment though this
might cause some pains. But we could always start there and see how it
goes. I agree that Xdebug isn't really a use case we always need to
optimize for.
Is it ever a case we need to o
Rasmus Lerdorf wrote:
Gopal V wrote:
shire wrote:
http://tekrat.com/downloads/bits/apc_lazy_php53.patch
You should be able to apply the above patch to the latest PHP_5_3
branch, and recompile the latest APC CVS against it. Two ini settings
enable/display lazy loading:
apc.lazy_functions=On/
Robin Burchell wrote:
> On Thu, Feb 26, 2009 at 5:21 PM, Moriyoshi Koizumi wrote:
>> So, in what point do you guys think of this change as valid?
>>
>> Moriyoshi
>
> Is there any known examples of code broken by this, or is it a more
> academic than practical problem?
>
>
That's indeed a pract
On Thu, Feb 26, 2009 at 5:21 PM, Moriyoshi Koizumi wrote:
> So, in what point do you guys think of this change as valid?
>
> Moriyoshi
Is there any known examples of code broken by this, or is it a more
academic than practical problem?
--
PHP Internals - PHP Runtime Development Mailing List
T
So, in what point do you guys think of this change as valid?
Moriyoshi
On Thu, Feb 26, 2009 at 11:36 PM, Antony Dovgal wrote:
> On 26.02.2009 17:19, Ilia Alshanetsky wrote:
>> Let's reach a conclusion by end of day (EST time) so release can either be
>> made or
>> delayed.
>
> +0
>
> Just go ah
Igor Feghali wrote:
> While trying to perform phar testing on the system previously
> mentioned by me, I couldn't manage to get php5.3-200902261130 to
> compile with IBM CC. First 3 lines of error:
>
> "/tmp/php5.3-200902261130/ext/pcre/pcrelib/pcre_internal.h", line
> 976.3: 1506-046 (S) Syntax e
While trying to perform phar testing on the system previously
mentioned by me, I couldn't manage to get php5.3-200902261130 to
compile with IBM CC. First 3 lines of error:
"/tmp/php5.3-200902261130/ext/pcre/pcrelib/pcre_internal.h", line
976.3: 1506-046 (S) Syntax error.
"/tmp/php5.3-200902261130/
Gopal V wrote:
> shire wrote:
>
>> http://tekrat.com/downloads/bits/apc_lazy_php53.patch
>>
>> You should be able to apply the above patch to the latest PHP_5_3
>> branch, and recompile the latest APC CVS against it. Two ini settings
>> enable/display lazy loading:
>>
>> apc.lazy_functions=On/Off
2009/2/26 Ilia Alshanetsky :
> Let's reach a conclusion by end of day (EST time) so
> release can either be made or delayed.
>
+0 aswell, lets just release it
--
Kalle Sommer Nielsen
ka...@php.net
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.ne
On 26.02.2009 17:19, Ilia Alshanetsky wrote:
> Let's reach a conclusion by end of day (EST time) so release can either be
> made or
> delayed.
+0
Just go ahead and release it.
--
Wbr,
Antony Dovgal
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.ph
shire wrote:
http://tekrat.com/downloads/bits/apc_lazy_php53.patch
You should be able to apply the above patch to the latest PHP_5_3
branch, and recompile the latest APC CVS against it. Two ini settings
enable/display lazy loading:
apc.lazy_functions=On/Off
apc.lazy_classes=On/OFf
Awesom
Moriyoshi,
Well, the only thing we could do at this point is to re-tag the
release with the change delaying the release by a week. You know where
I stand on the matter of the code default value, but if there is a
consensus on internal that this change needs to happen, then this can
defini
On Thu, Feb 26, 2009 at 1:58 PM, Rodrigo Saboya
wrote:
> For the average PHP programmer, the language will simply "get faster". That
> can't be bad in any way. It doesn't encourage you to write bad code, it just
> doesn't kick you in the nuts when you do.
It's probably also worth noting that in
Ronald Chmara wrote:
On Feb 21, 2009, at 10:55 PM, shire wrote:
Hi Ronald,
Ronald Chmara wrote:
Wait... so if I understand this right, let's envision a code base where,
per some random page load, 70 functions are actually called, but, oh,
7,000, or even 700,000, are being included for whatever
Hello Greg,
I have an AIX PPC 64 bits, IBM XL C/C++ compiler, which I can run the
tests. Is it of any interest ?
I read you tested on a PPC 64 already but as far as i understand you
used a GNU compiler.
Regards,
Igor Feghali.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscri
2009/2/25 Richard Quadling :
> 2009/2/22 Eric Stewart :
>> I made the following changes to the new INIs based on feedback mostly from
>> this list. Here are the changes.
>> 1. Changed production value of error_reporting to E_ALL & ~E_DEPRECATED.
>>
>> 2. extension_dir is now commented in both INIs.
39 matches
Mail list logo
