Well, if you want my 2 cents as well, the 2 cents a PHP user is very willing
to share with you guys...
PHP6 is a major release. BC is a priority, but as far as I'm concerned not
the top priority. I wouldn't mind a unicode-only PHP at all. Like a few
others here, I think the speed penalty won't be
Hi,
some of you may be aware of the wiki I set up to manage/document the
todo lists and parts of the release management for PHP releases. In
response to this Wez created a set of patches to enable developers to
set milestones (aka PHP versions) for bug reports. While I do not think
this repla
Ditto please!
Jevon
- Original Message -
From: "Ron Korving" <[EMAIL PROTECTED]>
To:
Sent: Thursday, October 13, 2005 8:27 PM
Subject: [php] Re: [PHP-DEV] Unicode Implementation
> Well, if you want my 2 cents as well, the 2 cents a PHP user is very
willing
> to share with you guys...
Unnecessary, you can tell the user within the closing comment
in which branches you fixed the bug. Don't forget that it can
CHANGE later, someone reverts the fix or the fix wasn't needed
or.. you get the picture.
--Jani
On Thu, 13 Oct 2005, Lukas Smith wrote:
Hi,
some of
Jani Taskinen wrote:
Unnecessary, you can tell the user within the closing comment
in which branches you fixed the bug. Don't forget that it can
CHANGE later, someone reverts the fix or the fix wasn't needed
or.. you get the picture.
Does it hurt though?
It makes it alot easie
On Thu, 13 Oct 2005, Lukas Smith wrote:
Jani Taskinen wrote:
Unnecessary, you can tell the user within the closing comment
in which branches you fixed the bug. Don't forget that it can
CHANGE later, someone reverts the fix or the fix wasn't needed
or.. you get the picture.
D
And remember: PHP6 will not be released for at least a year. So by then
typical servers will run at several hundred MHz more, so perhaps the
speed penalty won't be noticed at all. This is even more true compared
to the current speed of PHP as there will (If I recall this correctly)
be significant p
Oliver Grätz wrote:
> And remember: PHP6 will not be released for at least a year. So by then
> typical servers will run at several hundred MHz more, so perhaps the
> speed penalty won't be noticed at all.
And people will do more with PHP ultimately making the MHz boost
irrelevant. Despite tremend
On Thu, 13 Oct 2005 17:43:03 +0200
[EMAIL PROTECTED] (Oliver Grätz) wrote:
> And remember: PHP6 will not be released for at least a year. So by
> then typical servers will run at several hundred MHz more, so perhaps
> the speed penalty won't be noticed at all.
This argument is irrelevant. You on
I posted this on general a while ago and the only conclusion anyone
could come to is that there's a PHP bug somewhere. I'm running a snap
of 5.1 from today on OS X 10.4.2, and I've seen the same symptoms on
RedHat EL4. Before I report something does anyone here have any idea
what could be a
On 13.10.2005 20:51, Marcus Bointon wrote:
in a.inc.php:
in b.class.php:
Works fine here.
Fatal error: Class 'Config' not found
Use absolute path everywhere ?
I can't reproduce it either.
--
Wbr,
Antony Dovgal
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscrib
Hello all.
This is what I got trying to install latest snapshot of 5.1.0-dev with Apache2
on Linux:
--
Notice: Error: zlib extension is not enabled - gzinflate() function needed for
compressed .phars in /root/php5-200510131630/pear/install-pear.phar on line 393
Warning: main(p
TRANSLATE PHP MANUAL
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 13 Oct 2005, at 17:51, Marcus Bointon wrote:
I have another problem with included classes that seems to defy
explanation:
As usual there is a simple explanation for this one: I had a file
called 'config.php' lurking in one of the folders in my include path
- Deploying on Linux, I'd jus
Ilia Alshanetsky schrieb:
>>And remember: PHP6 will not be released for at least a year. So by then
>>typical servers will run at several hundred MHz more, so perhaps the
>>speed penalty won't be noticed at all.
> And people will do more with PHP ultimately making the MHz boost
> irrelevant. Despi
Pierre schrieb:
> This argument is irrelevant. You only hide the possible lack of
> scalability behind hardware improvements.
A "lack of scalability" will only occur if the Unicode features create a
more than linear performance drop which I suppose won't happen. Even if
it becomes three times slo
Oliver Grätz wrote:
> http://www.ister.org/code/article/de/php45bench.xhtml
>
> indicate that PHP5 is slower than PHP4, but in the note at the end there
> is some evidence that PHP5.1 will be significantly faster than PHP4 when
> it comes to objects and classes (which is what people who "do more w
On Thu, 13 Oct 2005, Oliver Grätz wrote:
And people will do more with PHP ultimately making the MHz boost
irrelevant. Despite tremendous increases in hardware performance, the
software we run seems to run slower and slower.
Which doesn't stop them from moving from PHP to Ruby (which I suppose
On Thu, 13 Oct 2005, Antony Dovgal wrote:
--
Notice: Error: zlib extension is not enabled - gzinflate() function needed for
compressed .phars in /root/php5-200510131630/pear/install-pear.phar on line
393
Warning: main(phar://install-pear.phar/index.php): failed to open stream
On 13.10.2005 23:38, Jani Taskinen wrote:
Add --disable-pear to the configure line and the errors go away.
Cool.
We need to document it then =)
--
Wbr,
Antony Dovgal
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
After the recent discussion in #php.pecl:
Is there any chance to use system's gunzip to unpack the phar as a fallback
solution ?
Or even better - to download and install not compressed version of the phar ?
Or at least use --without-pear when there is no --with-zlib or it's
--with-zlib=shared ?
On Fri, 14 Oct 2005, Antony Dovgal wrote:
> After the recent discussion in #php.pecl:
>
> Is there any chance to use system's gunzip to unpack the phar as a fallback
> solution ?
> Or even better - to download and install not compressed version of the phar ?
> Or at least use --without-pear when
On Thu, 13 Oct 2005 23:22:36 +0200 (CEST)
[EMAIL PROTECTED] (Derick Rethans) wrote:
> On Fri, 14 Oct 2005, Antony Dovgal wrote:
>
> > After the recent discussion in #php.pecl:
> >
> > Is there any chance to use system's gunzip to unpack the phar as a
> > fallback solution ?
> > Or even better -
Jani Taskinen schrieb:
>
> [...] instead of waiting what we'll
> break next.
*ROTFL*
You seem to develop a healthy fatalism ;-)
Bier?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On 14.10.2005 01:30, Pierre wrote:
On Thu, 13 Oct 2005 23:22:36 +0200 (CEST)
[EMAIL PROTECTED] (Derick Rethans) wrote:
On Fri, 14 Oct 2005, Antony Dovgal wrote:
> After the recent discussion in #php.pecl:
>
> Is there any chance to use system's gunzip to unpack the phar as a
> fallback solut
On Fri, 14 Oct 2005 01:39:08 +0400
[EMAIL PROTECTED] (Antony Dovgal) wrote:
> Also, what if someone uses --without-zlib? The installer would fail
> again?
Yes, so the solution is to go with uncompressed phar in php releases.
It gets compressed anyway.
--Pierre
--
PHP Internals - PHP Runtime D
On Thu, 13 Oct 2005 21:02:09 +0200
[EMAIL PROTECTED] (Oliver Grätz) wrote:
> Pierre schrieb:
>
> > This argument is irrelevant. You only hide the possible lack of
> > scalability behind hardware improvements.
>
> A "lack of scalability" will only occur if the Unicode features
> create a more tha
On Thu, 13 Oct 2005, Oliver Grätz wrote:
Jani Taskinen schrieb:
[...] instead of waiting what we'll
break next.
*ROTFL*
You seem to develop a healthy fatalism ;-)
I'm just realistic. I _KNOW_ we're gonna break stuff.
Intentionally, "accidently" and accidently.
--Jan
Jani Taskinen wrote:
> On Thu, 13 Oct 2005, Antony Dovgal wrote:
>
>> --
>> Notice: Error: zlib extension is not enabled - gzinflate() function
>> needed for compressed .phars in
>> /root/php5-200510131630/pear/install-pear.phar on line 393
>>
>> Warning: main(phar://install-pear.p
Marcus Bointon schrieb:
> I posted this on general a while ago and the only conclusion anyone
> could come to is that there's a PHP bug somewhere.
Hm? I tested you code on a Debian 5.1 RC1 system and could not reproduce
the problem. I thought you failed to post the whole code you used since
you
If you include a file within a function, that file will be loaded in
that function's scope. Example:
The same happens if b.class.php is included within a function (or class
member, etc.) and includes a.inc.php, as in your example (I am presuming.)
If this is the problem, I suggest simply a
31 matches
Mail list logo
