Hello Jeff,
try te attached script as a base for your needs and don't send such long
mails without any usefull information - instead please try to strip down
the mails to the parts containing usefull information...:-)
marcus
Saturday, July 17, 2004, 12:38:28 AM, you wrote:
> hi, i am trying to
Hello Erik,
interfaces do not allow code (function bodies) nor doe they allow
properties. But they allow multiple inheritance. That is a class can
inherit multiple interfaces but only one class. The reason for this
is a compromise to overcome the problems with multiple inheritance
namely the pronl
hi, i am trying to compile rpms for php5.0.0 based on taking the 5.0.0
source just released on the 13th, and using the php.spec file from the
4.3.6 source rpm and tweaking it a little. basically, i'm trying to
stay close to what redhat has in its configure (even though it's a ton
of stuff), because
What is the reason for why PHP5 does not allow creating an interface by
extending a non "interfaced" class?
The follow code produces an error saying "CMAES_Section cannot implement
CMAES_DB_Section - it is not an interface in
not only that but those people who want this performance boost can use
apc. i'll give george a patch that solves this if no one else steps
up.
-sterling
On Fri, 16 Jul 2004 10:20:08 -0700, Andi Gutmans <[EMAIL PROTECTED]> wrote:
> Nah, I dread the INI word. It makes applications less portable.
>
Nah, I dread the INI word. It makes applications less portable.
I prefer rolling back than doing this.
Andi
At 10:09 AM 7/16/2004 -0700, Sara Golemon wrote:
"Andi Gutmans" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> I don't think it's critical to include this patch, but I do think
At 07:08 PM 7/16/2004 +0200, Thies C. Arntzen wrote:
On Fri, 16 Jul 2004 09:32:10 -0700, Andi Gutmans <[EMAIL PROTECTED]> wrote:
> Do you have the source?
> I think it'd be more interesting to see the performance difference on a
> real world application such as phpBB, phpnuke or similar. If you can
"Andi Gutmans" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> I don't think it's critical to include this patch, but I do think it'd be
a
> good thing.
> Do you really think it'll break BC for many applications? How many people
> have functions that use null(), false(), true()?
>
I k
On Fri, 16 Jul 2004 09:32:10 -0700, Andi Gutmans <[EMAIL PROTECTED]> wrote:
> Do you have the source?
> I think it'd be more interesting to see the performance difference on a
> real world application such as phpBB, phpnuke or similar. If you can give
> us numbers on that, it would definitely impro
On Fri, 16 Jul 2004 12:46:47 -0400, Ilia Alshanetsky <[EMAIL PROTECTED]> wrote:
> On July 16, 2004 12:41 pm, Thies C. Arntzen wrote:
> > php has no real concept for out-of-memory situations (stack or real)
> > - nor do we catch infinite (nor too deep) recursions. allowing for
> > "deeper" recursio
That is nowhere near a real-life application. There's no logic only
function calls.
Look, I asked Ilia not to change the alloca() but eventually agreed. So
personally I have no problem with undoing that patch, but I still think
that not testing real-life applications is not the way to make a cas
On Fri, 16 Jul 2004, Christian Stocker wrote:
> I didn't blame you and there are good reasons to not to port it. But for
> BC, maybe someone will do it anyway... OTOH the switch to ext/xsl isn't
> that hard and you gain a lot of speed improvements ;)
I think the only difficulties you'd run into i
On July 16, 2004 12:41 pm, Thies C. Arntzen wrote:
> php has no real concept for out-of-memory situations (stack or real)
> - nor do we catch infinite (nor too deep) recursions. allowing for
> "deeper" recursion doesn't really fix anything. so, i think we should
> either come up with a real soluti
Here you go.
Ilia
On July 16, 2004 12:32 pm, Andi Gutmans wrote:
> Do you have the source?
> I think it'd be more interesting to see the performance difference on a
> real world application such as phpBB, phpnuke or similar. If you can give
> us numbers on that, it would definitely improve your
On Fri, 16 Jul 2004 12:15:46 -0400, Ilia Alshanetsky <[EMAIL PROTECTED]> wrote:
> On July 16, 2004 11:58 am, Thies C. Arntzen wrote:
> > hey ilia,
> >
> > here's another one of my meaningess, synthetic benchmarks (this is how
> > the CreatorsOfPHP(tm) would call them)
> >
> > ackermann(8) (source o
can we put that in the release notes - "php is like 50% more stable,
it takes 20 seconds not 10 to crash it?"
-sterling
On Fri, 16 Jul 2004 12:15:46 -0400, Ilia Alshanetsky <[EMAIL PROTECTED]> wrote:
> On July 16, 2004 11:58 am, Thies C. Arntzen wrote:
> > hey ilia,
> >
> > here's another one of
Do you have the source?
I think it'd be more interesting to see the performance difference on a
real world application such as phpBB, phpnuke or similar. If you can give
us numbers on that, it would definitely improve your point if the
performance penalty show in that case.
At 05:58 PM 7/16/200
Building the bundled libgd library into PHP causes symbol namespace
pollution; if any other Apache modules link a different version of libgd
into the Apache process they may instead pick up symbols from the PHP
libgd, and segfault randomly. (One of our users saw this when using
mod_perl with Perl:
On July 16, 2004 11:58 am, Thies C. Arntzen wrote:
> hey ilia,
>
> here's another one of my meaningess, synthetic benchmarks (this is how
> the CreatorsOfPHP(tm) would call them)
>
> ackermann(8) (source on request - highly recursive)
Recursive functions in PHP are inherently dangerous as without
Hi Sterling
On 16.7.2004 18:04 Uhr, Sterling Hughes wrote:
it wasn't ported because i don't want people using it anymore, they
should be using ext/xsl, period.
I didn't blame you and there are good reasons to not to port it. But for
BC, maybe someone will do it anyway... OTOH the switch to ext/xsl
it wasn't ported because i don't want people using it anymore, they
should be using ext/xsl, period.
-sterling
On Fri, 16 Jul 2004 11:18:46 +0200, Christian Stocker <[EMAIL PROTECTED]> wrote:
>
>
> On 16.7.2004 11:15 Uhr, Kamesh Jayachandran wrote:
>
> > Hi,
> > I have seen that in php5.0/ext/
I would have been +0 for 5, I'm -1 for 5.1. FETCH_CONSTANT is not a
terribly expensive operation (as opposed to registering constants with
define()), and something like this is *easy* to optimize in a compiler
cache/optimizer. End of the day, we shouldn't break BC in any way
during a point release
On Fri, 16 Jul 2004 08:39:21 -0400, Ilia Alshanetsky <[EMAIL PROTECTED]> wrote:
> Oops mail client assign the message to the wrong patch.
> In response to Andi's question, we can probably get away with using a regular
> malloc since the number of variables needed to cause a crash will probably
> ca
I don't think it's critical to include this patch, but I do think it'd be a
good thing.
Do you really think it'll break BC for many applications? How many people
have functions that use null(), false(), true()?
Andi
At 08:17 AM 7/16/2004 -0700, Sterling Hughes wrote:
oh, i didn't notice it at al
oh, i didn't notice it at all, which i'll buy is probably my fault. :)
This seems like its a bad optimization. I believing in breaking BC
in some cases when its absolutely necessary, but an optimization like
this one could easily happen at the level of an optimizer, like APC or
Zend's product.
On Jul 16, 2004, at 3:22 AM, Thies C. Arntzen wrote:
this will have a performance impact on every function call in php. and
it won't stop fix out-of-memory crashes completely.
i really don't think this is what we should do...
Well, allocating it all in stack memory seems intractable - you can
easi
There's no reason why gettimeofday() shouldn''t return the same time in
successive calls; this test fails spuriously on Linux/x86_64 (which has
a particularly fast gettimeofday() implementation).
--- ext/standard/tests/time/001.phpt23 May 2003 20:56:33 - 1.4.2.2
+++ ext/standard/tests
Thanks
On Fri, 16 Jul 2004 11:18:46 +0200, "Christian Stocker"
<[EMAIL PROTECTED]> said:
>
>
> On 16.7.2004 11:15 Uhr, Kamesh Jayachandran wrote:
>
> > Hi,
> > I have seen that in php5.0/ext/xslt directory does not have any source
> > except the test scripts whereas in php-4.3.8 I could find the
On 16.7.2004 11:15 Uhr, Kamesh Jayachandran wrote:
Hi,
I have seen that in php5.0/ext/xslt directory does not have any source
except the test scripts whereas in php-4.3.8 I could find the files.
In php5.0 there is one extra directory under ext by name xsl which does
not exist in PHP4.3.8
ext/xslt
Hi,
I have seen that in php5.0/ext/xslt directory does not have any source
except the test scripts whereas in php-4.3.8 I could find the files.
In php5.0 there is one extra directory under ext by name xsl which does
not exist in PHP4.3.8
Why is this change?
Can someone clarify me on this?
With reg
Hello Sterling,
it was on internals and in TODO-5.1. Maybe not many people noticed
it between discussing typehints and ifsetor.
marcus
Friday, July 16, 2004, 9:12:28 AM, you wrote:
> woops, discussion should be on [EMAIL PROTECTED]
> -- Forwarded message --
> From: Sterling Hu
Well,
the new word "clone" made the same :
class a{
function clone() {}
}
is not working anymore :)
andrey
Sterling Hughes wrote:
if (connected::true()) {
echo "bar";
}
?>
On Fri, 16 Jul 2004 09:26:33 +0200, dharana <[EMAIL PROTECTED]> wrote:
Excuse my ignorance, but why does this breaks compat
On Fri, 16 Jul 2004 09:26:33 +0200, dharana <[EMAIL PROTECTED]> wrote:
> Excuse my ignorance, but why does this breaks compatibility?
>
>
>
> Sterling Hughes wrote:
> > woops, discussion should be on [EMAIL PROTECTED]
> >
> >
> > -- Forwarded message --
> > From: Sterli
Excuse my ignorance, but why does this breaks compatibility?
Sterling Hughes wrote:
> woops, discussion should be on [EMAIL PROTECTED]
>
>
> -- Forwarded message --
> From: Sterling Hughes <[EMAIL PROTECTED]>
> Date: Fri, 16 Jul 2004 00:11:53 -0700
> Subject: Re: [ZEND-ENGINE-CVS] c
woops, discussion should be on [EMAIL PROTECTED]
-- Forwarded message --
From: Sterling Hughes <[EMAIL PROTECTED]>
Date: Fri, 16 Jul 2004 00:11:53 -0700
Subject: Re: [ZEND-ENGINE-CVS] cvs: ZendEngine2 /
zend_language_parser.y zend_language_scanner.l
To: Marcus Boerger <[EMAIL PROT
35 matches
Mail list logo
