On 24/09/06, Ron Korving <[EMAIL PROTECTED]> wrote:
In this case, wouldn't E_NOTICE make more sense? E_STRICT kind of indicates
that certain behaviour is deprecated, right?
I think that's a whole other issue. E_STRICT seems to be used for both
errors in coding style (calling static methods from
Ron Korving wrote:
> In this case, wouldn't E_NOTICE make more sense? E_STRICT kind of
> indicates that certain behaviour is deprecated, right?
We are moving in circles. Using E_STRICT for both the use of deprecated
language features and the "unstrict" use of language features is
confusing.
-
PHP 4 Bug Database summary - http://bugs.php.net
Num Status Summary (634 total including feature requests)
===[*Configuration Issues]
38670 Open Whole 4.4.x branch has problem with open_basedir option nested
from Apache2
PHP 5 Bug Database summary - http://bugs.php.net
Num Status Summary (600 total including feature requests)
===[*Configuration Issues]
37919 Feedback PHP doesn't read the configurations propertly
===
Hi,
Don't know if someone wants to check this out and apply it before 5.2's
release, or whether you want it at all. ;-) I just noticed how many of the
php_error_docref()'s still have a period (".") at the end of the text,
resulting in "... error message. in on line " Looks
better/consistent wit
On 25/09/06, Matt W <[EMAIL PROTECTED]> wrote:
Hi,
Don't know if someone wants to check this out and apply it before 5.2's
release, or whether you want it at all. ;-) I just noticed how many of the
php_error_docref()'s still have a period (".") at the end of the text,
resulting in "... error me
Hi Richard,
- Original Message -
From: "Richard Quadling"
Sent: Monday, September 25, 2006
> On 25/09/06, Matt W <[EMAIL PROTECTED]> wrote:
> > [...]
> >
> > I don't know if my regex search found all occurrences, but I fixed up
the
> > files I found. The only changes were removing a tra
Hi,
Noticed this a couple months ago and never sent this simple thing. :-)
ERANGE is being triggered too soon because of the wrong variable, which
causes the following (in Unicode mode, of course) on 32-bit:
(int) '2147483640' // int(2147483647)
'2147483640' + 0) // float(2147483640)
Instead of
On Thu, 21 Sep 2006, Pierre wrote:
> Before any further comment, we agreed on the "filter" prefix. We have
> to stick to it. I also think we should respect other developers
> choices.
>
> As you said, filter is more than a simple extension, its design choice
> should not be up to only one or two
On Sat, 23 Sep 2006, Rui Hirokawa wrote:
> What do you think about the specification ?
> Which way do you prefer to support alias/MIME encoding?
> 1. adding new functions
>(mb_list_encodings_alias_names(), mb_list_mime_names())
> 2. adding an option to mb_list_encoding().
I think it should
On Sun, 24 Sep 2006, Zeev Suraski wrote:
> At 11:10 22/09/2006, Derick Rethans wrote:
> >On Thu, 21 Sep 2006, Michael Wallner wrote:
> >
> > > [ ] (+1) please remove that redundant strictness again
> > > [X] (-1) leave as it is, we need strict OO implementation
> > > [ ] ( 0) what the hell are you
On Sun, 24 Sep 2006, Ron Korving wrote:
> In this case, wouldn't E_NOTICE make more sense? E_STRICT kind of indicates
> that certain behaviour is deprecated, right?
Not really, E_STRICT is for when you're doing something that you
shouldn't. In my opinion that includes using a deprecated function
Hello,
Before any further comment, I have to say that I'm more than
disappointed to have put so much effort to get a concensus from the
PHP developers here and lost it right away because you, alone, thinks
that *we* made wrong choices. I cannot accept that any longuer, I do
not want to block 5.2
I posted this to php-general several days ago, and the only response
suggested that perhaps I should forward the question to PHP internals.
If what's below isn't expected behavior, I'd be glad to dedicate a few
days to helping track down the problem.
I've tried what's below on the server clust
Ok, so I've built an extension that uses a C++ library. It compiles fine
but the build system is insisting on linking with gcc no matter what I
tell it. Is there some simple trick I'm missing as far as convincing it
to use g++ goes?
Here is the config.m4 in case I've missed something in there.
On 26.09.2006 01:09, Stut wrote:
Ok, so I've built an extension that uses a C++ library. It compiles fine
but the build system is insisting on linking with gcc no matter what I
tell it. Is there some simple trick I'm missing as far as convincing it
to use g++ goes?
Here is the config.m4 in ca
On 9/25/06, Stut <[EMAIL PROTECTED]> wrote:
I had expected the PHP_REQUIRE_CXX() macro to trigger a change to the
link command, but it does not seem to have done anything beyond
influencing what is used to compile the extension itself.
Hi,
I think you have to add stdc++ with PHP_ADD_LIBRARY()
> PHP_NEW_EXTENSION(mmsr, mmsr.c "$PHP_MMSR/MMSR/mmsr_bridge.cpp",
> $ext_shared)
PHP_NEW_EXTENSION(mmsr, mmsr.c "$PHP_MMSR/MMSR/mmsr_bridge.cpp",
$ext_shared,,,1)
Ref: aclocal.m4 / EEPHP:Chapter 17
-Sara
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http:
18 matches
Mail list logo
