Ralph Schindler wrote:
In the spirit of fopen's optional [, bool use_include_path].. is this
something that can be added to is_readable?
ie:
bool is_readable ( string filename [, bool use_include_path] )
we can always dream ..
so far the answer has been that this parameter should never have
On 6-Oct-06, at 7:25 PM, Edin Kadribasic wrote:
I believe that making a RC now will increase the probability of
people testing out stuff, rather than expecting them to checkout
the latest CVS. I see absolutely no point in waiting to some
arbitrary weekday.
Aside from a few issues RC5 is
Edin Kadribasic wrote:
Now that we know that there is going to be RC6 I think there is no point
in waiting for another week for it just because we have to release
things on Thursday.
I think that the best thing would be to make immediate RC6 and allow
people some time to test it, and if nothi
I believe that making a RC now will increase the probability of people
testing out stuff, rather than expecting them to checkout the latest
CVS. I see absolutely no point in waiting to some arbitrary weekday.
Edin
Ilia Alshanetsky wrote:
RC6 will be out on Thursday to give people a chance to i
RC6 will be out on Thursday to give people a chance to identify any
remaining issues with the current state of 5.2.0 as well as allow
existing bug reporters to confirm the critical issues outlined have
been resolved.
On 6-Oct-06, at 7:13 PM, Edin Kadribasic wrote:
Now that we know that th
Now that we know that there is going to be RC6 I think there is no point
in waiting for another week for it just because we have to release
things on Thursday.
I think that the best thing would be to make immediate RC6 and allow
people some time to test it, and if nothing critical comes up, re
In the spirit of fopen's optional [, bool use_include_path].. is this
something that can be added to is_readable?
ie:
bool is_readable ( string filename [, bool use_include_path] )
-ralph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub
This feature was just added in the CVS.
Ilia Alshanetsky
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi Andrei,
most parts off it work in unicode mode, there are a few places which
need little work, see Dmitry's "FIXME: Unicode support" comments to get
an idea. Basically I'm in writing tests and writing a patch but
currently have less time than expected...
johannes
Andrei Zmievski wrote:
A
hi ilia,
PHP works just fine with newer version of autoconf and automake. For
example I am using autoconf 2.60 and automake 1.9.6 and not
experiencing any build issues. One of the reasons we recommend
autoconf 2.13 is because it has a non-broken implementation of config
test caching and unlike
On the same note you can use C and ignore all rules, coding using only
void pointers and relying purely on gotos for flow control. :-)
Sure, and PHP is much closer to "C" (I intentionally use quotes because
it's not matter of language but rather concept, but since you named it,
I will keep t
PHP works just fine with newer version of autoconf and automake. For
example I am using autoconf 2.60 and automake 1.9.6 and not
experiencing any build issues. One of the reasons we recommend
autoconf 2.13 is because it has a non-broken implementation of config
test caching and unlike auto
php52-cvs' "INSTALL" states:
"autoconf 2.13 and automake 1.4+ are required (newer versions of
autoconf may work, but are not supported)"
@ distrowatch, distros haven't shipped for ages with automake 1.4.
automake 1.4 was released: 14-Jan-1999
current/stable automake
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I would appear that we've missed another vcwd issue that affected a
number of problems outlined in bug #39059 therefor we are going to
have an RC6. So, this means if you have bug fixes they can once again
go into the 5.2 tree.
Ilia
-BEGIN
On 6-Oct-06, at 12:17 PM, Stanislav Malyshev wrote:
I be wary of allowing this because in some instances method
signature can drastically impact behavior for example
foo(&$bar) {} vs foo($bar); I'd prefer to don't reduce this to
E_NOTICE.
Yes, it can have runtime impact. So what? There are
On Fri, 6 Oct 2006, Edin Kadribasic wrote:
> Edin Kadribasic wrote:
> > Stanislav Malyshev wrote:
> > > > The vote is should OO strictness (fatal error on changing function
> > > > arguments in derived classes in this case) be removed or kept.
> > >
> > > I think fatal error should be definitely r
On Thu, 5 Oct 2006, Michael Wallner wrote:
> Michael Wallner wrote:
>
> > I'd therefore like to conduct a serious vote on this issue.
> >
> > [X] (+1) please remove that redundant strictness again
> > [ ] (-1) leave as it is, we need strict OO implementation
> > [ ] ( 0) what the hell are you ta
I be wary of allowing this because in some instances method signature
can drastically impact behavior for example
foo(&$bar) {} vs foo($bar); I'd prefer to don't reduce this to E_NOTICE.
Yes, it can have runtime impact. So what? There are so many cases where,
for example, not declaring a var
On 6-Oct-06, at 11:59 AM, Edin Kadribasic wrote:
I believe that most OO "strictness" fatal errors should be demoted
to notices.
* Changing function signatures in derived classes
I be wary of allowing this because in some instances method signature
can drastically impact behavior for exam
Edin Kadribasic wrote:
Stanislav Malyshev wrote:
The vote is should OO strictness (fatal error on changing function
arguments in derived classes in this case) be removed or kept.
I think fatal error should be definitely removed or the rules be at
least relaxed sufficiently to accomodate for P
Stanislav Malyshev wrote:
The vote is should OO strictness (fatal error on changing function
arguments in derived classes in this case) be removed or kept.
I think fatal error should be definitely removed or the rules be at
least relaxed sufficiently to accomodate for PHP flexibility - e.g., (
The vote is should OO strictness (fatal error on changing function
arguments in derived classes in this case) be removed or kept.
I think fatal error should be definitely removed or the rules be at
least relaxed sufficiently to accomodate for PHP flexibility - e.g., ()
should be allowed to be
Should be non-fatal.
IMO, we shouldn't even be using up CPU cycles to check this; use a
compiled language for that kind of safety.
--Wez.
On 10/6/06, Edin Kadribasic <[EMAIL PROTECTED]> wrote:
The vote is should OO strictness (fatal error on changing function
arguments in derived classes in thi
The vote is should OO strictness (fatal error on changing function
arguments in derived classes in this case) be removed or kept.
Edin
Wez Furlong wrote:
Just a lame ass late-to-the-show comment... I've been out of touch and
this mini thread gives no indication what the vote is about.
Can we
Just a lame ass late-to-the-show comment... I've been out of touch and
this mini thread gives no indication what the vote is about.
Can we try to use more descriptive subjects going forward, thanks!
--Wez.
On 10/5/06, Lukas Kahwe Smith <[EMAIL PROTECTED]> wrote:
Michael Wallner wrote:
> 3, 2
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello,
Windows build of 5.2.0RC5 is available:
http://downloads.php.net/edink/php-5.2.0RC5-Win32.zip
http://downloads.php.net/edink/php-5.2.0RC5-win32-installer.msi
http://downloads.php.net/edink/pecl-5.2.0RC5-Win32.zip
http://downloads.php.net/edink
downloading the pecl
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
27 matches
Mail list logo
