Should be fixed now.
If any more of these occur, the problem is that needs to be
included before (which itself includes ).
I noticed that some source files include the winsock headers twice, so
there is probably some spring cleaning that can be done.
I have included as one of the first things
+1
Moriyoshi
[EMAIL PROTECTED] (Marcus Boerger) wrote:
> Maybe we should add those two settings also to the default overwrites
> since you can easily fail all tests by this simple settings and mbstring
> module as well as output buffering are checked elsewhere.
>
> marcus
>
> Index: run-tests.
Hmm since it seems i am the only one wanting to take only the log version
of the messages i think we can leave it like it is now (with log_errors=0).
The reason i wanted log_errors=1 was that i simply wanted one single
additional line in the .diff files whatever is configured elsewhere.
marcus
A
At 18:24 28-10-2002, Marcus Börger wrote:
Second i did another commit to direct logs to stderr so the errors are shown
in the output. So i do not see any problem here.
I don't get it - display_errors=on works independantly from log_errors.
Why do we need logs?
[EMAIL PROTECTED] ~
$ /phpcvs/bi
On Mon, 28 Oct 2002, Marcus Börger wrote:
>Second i did another commit to direct logs to stderr so the errors are shown
>in the output. So i do not see any problem here.
Not necessarily..for me stderr goes to /var/log/messages, iirc. :)
>b) Leave it as it is now (of cause my favorite). S
First of all only some tests in ext/xslt were designed to present a warning.
I suggest this can be fixed by adding a --INI-- section disabling the error
messages.
Second i did another commit to direct logs to stderr so the errors are shown
in the output. So i do not see any problem here.
Third i
I guess we should add a --enable-mime-magic warning as well:
PHP Warning: mime_magic: can't read magic file in Unknown on line 0
FAIL ctype on integers [ext/ctype/tests/001.phpt]
PHP Warning: mime_magic: can't read magic file in Unknown on line 0
FAIL ctype on strings [ext/ctype/tests/002.phpt
On Mon, 28 Oct 2002, Jani Taskinen wrote:
>
>+1 for removing both bogus settings. (html_errors & log_errors)
Another one here then: +1 for reverting the changes.
Derick
> On Sun, 27 Oct 2002, Ilia A. wrote:
>
> >I am curios as to your reasoning behind turning on html_errors by default, wh
On Mon, 28 Oct 2002, Melvyn Sopacua wrote:
> At 01:27 28-10-2002, Ilia A. wrote:
>
> >I am curios as to your reasoning behind turning on html_errors by default,
> >why
> >would the tests need HTML data?
> >Logging of errors occurred during the tests seems pointless to me. As I've
> >mentioned be
+1 for removing both bogus settings. (html_errors & log_errors)
--Jani
On Sun, 27 Oct 2002, Ilia A. wrote:
>I am curios as to your reasoning behind turning on html_errors by default, why
>would the tests need HTML data?
>Logging of errors occurred during the tests seems pointless
At 01:27 28-10-2002, Ilia A. wrote:
I am curios as to your reasoning behind turning on html_errors by default,
why
would the tests need HTML data?
Logging of errors occurred during the tests seems pointless to me. As I've
mentioned before if a test needs to check if a certain type of error is
ge
But we are speaking about one single test. I mean multiple calls to
$php_errormsg
are allowed of cause. I was just looking for a solution to check whether a
test
produces any not wanted messages.
marcus
At 22:06 25.10.2002, Ilia A. wrote:
On October 25, 2002 04:01 pm, Marcus Börger wrote:
> I h
On October 25, 2002 04:01 pm, Marcus Börger wrote:
> I haven't installed xslt yet so i do not know...but i am testing with 25%
> of the modules and get the feeling that we must check for all warnings and
> errors.
>
> A special situation is ext/session/tests/008-php4.2.3.phpt
> where a warning mech
13 matches
Mail list logo
