RE: [PHP-DEV] Possible problem in the parser

[Ford, Mike [LSS]]

> -Original Message-
> From: Andi Gutmans [mailto:[EMAIL PROTECTED]
> Sent: 14 March 2003 14:50
> 
> You are right that it doesn't behave the same as C. However, 
> personally 
> although it might have been better for it to work like C I 
> don't think it's 
> a good idea to change it now. First of all it would break backwards 
> compatibility in a way which would be hard for people to find 
> where the bug 
> is and how to fix it. Secondly, not meaning to insult anyone 
> here, but I 
> think people who write such code without using parentheses 
> should improve 
> their coding style :)

Oh, I totally agree.  My original response was to a query as to whether the
PHP behaviour was a bug -- so I simply pointed out (in some detail!) that,
although different from c, it *did* conform to the precedence and
associativity documented in the PHP manual.

Cheers!

Mike

-----
Mike Ford,  Electronic Information Services Adviser,
Learning Support Services, Learning & Information Services,
JG125, James Graham Building, Leeds Metropolitan University,
Beckett Park, LEEDS,  LS6 3QS,  United Kingdom
Email: [EMAIL PROTECTED]
Tel: +44 113 283 2600 extn 4730  Fax:  +44 113 283 3211 

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Possible problem in the parser

[Ford, Mike [LSS]]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Sent: 13 March 2003 19:33
> To: Ford, Mike [LSS]
> Cc: 'Andrey Hristov'; [EMAIL PROTECTED]
> Subject: RE: [PHP-DEV] Possible problem in the parser
> 
> 
> At 14:58 13.03.2003, Ford, Mike   [LSS] wrote:
> 
> >Just to make this completely clear, in left-associative PHP
> >
> >b = a==1? 4:a==2? 5:6;
> >
> >is equivalent to
> >
> >b = (a==1? 4:a==2)? 5:6;
> 
> 
> NO it is not equal. Either '==' has higher precedence OR '?:' has.
> See one of my previous mails where i showed where the error is.

Yes, it is -- believe me, I've researched this extensively.  It is NOT about 
precedence, but associativity.  If you want me to be totally completist about this:

Starting from:

   b = a==1? 4:a==2? 5:6;

precedence rules make this equivalent to:

   b = (a==1)? 4:(a==2)? 5:6;

but this is still ambiguous -- which ?: phrase do you evaluate first?  Associativity 
provides the answer: in PHP, where ?: is left associative (i.e. the left most ?: is 
evaluated first), the result is equivalent to:

   b = ((a==1)? 4:(a==2))? 5:6;

On the other hand, in c, where ?: is right associative, the equivalent is:

   b = (a==1)? 4:((a==2)? 5:6);

which, apart from the additional (unnecessary) parentheses around the == comparisons, 
is exactly what I said before.

QED

Cheers!

Mike

-
Mike Ford,  Electronic Information Services Adviser,
Learning Support Services, Learning & Information Services,
JG125, James Graham Building, Leeds Metropolitan University,
Beckett Park, LEEDS,  LS6 3QS,  United Kingdom
Email: [EMAIL PROTECTED]
Tel: +44 113 283 2600 extn 4730  Fax:  +44 113 283 3211 

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Possible problem in the parser

[Ford, Mike [LSS]]

> -Original Message-
> From: Andrey Hristov [mailto:[EMAIL PROTECTED]
> Sent: 12 March 2003 17:26
> 
> > On Wed, 12 Mar 2003, Andrey Hristov wrote:
> >
> > >  Few minutes ago I found the following behaviour somehow 
> wierd for me :
> >
> > Known bug, the associativity of the ternary operator has been
> > broken since ages in the engine.  It's on the "won't be
> > fixed" sheet, because of BC concerns.

That's a bit hard -- it's different from c, certainly (left associative
instead of right), but that's a valid choice (even if it was originally
accidental!) and calling it broken is a bit harsh.

> 
> Is it documented somewhere?

Yes -- at
http://www.php.net/manual/en/language.operators.php#language.operators.prece
dence).

Just to make this completely clear, in left-associative PHP

   b = a==1? 4:a==2? 5:6;

is equivalent to

   b = (a==1? 4:a==2)? 5:6;

yielding 5 if a==1 or a==2, else 6.

But in right-associative c, it's equivalent to:

   b = a==1? 4:(a==2? 5:6);

yielding 4 if a==1, 5 if a==2, else 6.

Since this *is* documented behaviour, I don't see how it can be called
particularly unexpected.  ("Weird", maybe, if you're used to the c
behaviour, but not unexpected!)

Cheers!

Mike

-
Mike Ford,  Electronic Information Services Adviser,
Learning Support Services, Learning & Information Services,
JG125, James Graham Building, Leeds Metropolitan University,
Beckett Park, LEEDS,  LS6 3QS,  United Kingdom
Email: [EMAIL PROTECTED]
Tel: +44 113 283 2600 extn 4730  Fax:  +44 113 283 3211 

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] mssql.convertdatetime, mssql.longdatetime

[Mike Robinson]

Jochen Daum wrote:
> Hi !
> 
> I need to fetch a datetime column from sql server with 
> milliseconds. Someone posted a patch a while ago:
> 

Doesn't look like that patch made it, but a ton of work has
been done on that file since.

> How do I find out, if this patch has been incorporated
> into Version 4.3?

http://cvs.php.net/co.php/php4/ext/mssql/php_mssql.c?login=2&r=1.107

Regards
Mike Robinson


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Jumadi

[Mike Robinson]

You could charge $100 per php licence too. :P

Regards
Mike Robinson


Jani Taskinen wrote:


> Just make this one moderated. (but allow anyone with CVS
> access to post freely :)
> 
> --Jani
> 
> 
> 


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Re: str_ireplace vs. stri_replace

[Mike Robinson]

Jon Parise writes:
>  
> Get rid of stri_replace() and/or str_ireplace() and just add 
> a fourth optional parameter to str_replace() to control 
> case-sensitivity.

Yup.

Regards
Mike Robinson


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] CVS Account Request: mgf

[Mike Ford]

Occasional contributions to documentation; responding to / closing bug reports when I 
can.

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] roadmap of PHP - where? PHP 5 - when?

[Mike Robinson]

Rasmus Lerdorf wrote:

> Perception and warm fuzzies is an extremely important part of
> a large open source project that relies heavily on a large
> number of volunteers.  Messing with that is playing with fire.

You've hit it bang on.

[noise]
The clinical name for the 'fire' in this case is "cycle of
alienation", and in any environment that relies on volunteers,
this 'cycle' is almost impossible to avoid. I've been amazed
over the 4+ years since I jumped onto the list how well this
group has been able to circumvent the problems that normally
plague projects of this size and scope. FWIW, the number one
cause of the cycle is information sharing amongst a smaller
subgroup formed from the main group, usually without their
knowledge. In most cases, the result is fatal. The few groups
I've seen actually emerge from an active cycle are irreparably
damaged.
[/noise]

Regards
Mike Robinson




-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Bugsystem status codes (Was: Re: #21659 [Com]: sprintf)

[Ford, Mike [LSS]]

> -Original Message-
> From: Derick Rethans [mailto:[EMAIL PROTECTED]]
> Sent: 15 January 2003 15:17
> To: [EMAIL PROTECTED]
> Cc: PHP Quality Assurance Team Mailing List; PHP Developers 
> Mailing List
> Subject: [PHP-DEV] Bugsystem status codes (Was: Re: #21659 [Com]:
> sprintf)
> 
> 
> On 15 Jan 2003 [EMAIL PROTECTED] wrote:
> 
> > Why has this bug been marked as Bogus when it's a 
> Duplicate?  It seems
> > to be increasingly common for this to happen -- when did it become
> > standard policy to set duplicate report to Bogus?
> 
> Two exactly the same bugs were posted one minute after eachother from 
> persons on the same domain.

(Grits teeth) But it's still a duplicate report!
 
> It was in this case.
> 
> > And even if it is policy to set duplicate report to Bogus, 
> that policy
> > should be prominently documented, so that people don't get in a huff
> > about bugs being dismissed as not a bug when their 
> duplicate report is
> > set to Bogus (which has happened more than once already!).
> 
> People who dont understand the implicit meaning of the statii 
> shouldn't 
> touch the reports in the bug system. I'll write them down again:

I'm not talking about touching them in the bug system, I'm talking about
understanding them as a bog standard user.

> 
> bogus: submitted twice after each other, or by the same person on the 
>same topic; it's not a bug, but a support question. The reason 
>should always be noted in the comments

That's very confusing - there's really two different stauses in that
definition, which I think is the crux of the problem.  The first definition
really needs a new status such as "Repeat", which is otherwise treated like
Bogus.  But this definition is interesting, because I think some responders
are not respecting the "by the same person" part.

> dupli: almost the same bug, both bugs are found 'duplicate' 
> later on and 
>have both useful information

Yes, fair enough.  I just get the feeling that, lately, the balance has
tipped too far towards labelling repeat reports Bogus -- personally, I think
responders should be a little less Bogus-happy, and err on the side of
Duplicatifying if there's any doubt in the matter.  Also, when marking a
"repeat" as Bogus, not calling it a duplicate in the explanation would be
useful -- saying something more like "repeat of #xxx" or "Identical to #xxx"
would be better.

> verif: a member of the QA has verified the bug to be a real one
> analy: the cause of the bug is known, or a solution is known 
> for it but
>not yet implemented
> assig: don't touch this one, somebody is working on this. 
> open:  just submitted, or nobody knows what to do with it (after 
>feedback)
> feedb: Waiting for more feedback from the user
> suspe: at some point in the future we'll look at it again, 
> currently we 
>are waiting on an external thing to be fixed first
> close: the bug has been solved (fixed in cvs)
> wontf: we are not going to fix this issue because 
> criti: critical bug, should be fixed ASAP
> no fe: No feedback from the user was added since we asked it 
> two weeks 
>ago

H'mmm, interesting -- I don't think I've ever seen that list before --
certainly not linked from anywhere obvious such as http://bugs.php.net/, or
http://bugs.php.net/search.php.  Perhaps a "what happens to bug reports"
sort of link would be useful on the bugs front page, to complement "How to
report a bug"?

Cheers!

Mike

-
Mike Ford,  Electronic Information Services Adviser,
Learning Support Services, Learning & Information Services,
JG125, James Graham Building, Leeds Metropolitan University,
Beckett Park, LEEDS,  LS6 3QS,  United Kingdom
Email: [EMAIL PROTECTED]
Tel: +44 113 283 2600 extn 4730  Fax:  +44 113 283 3211

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] PHP4 + PHP5

[Mike Robinson]

> From: James Cox wrote:

>> "Mike Robinson" <[EMAIL PROTECTED]> wrote:
>>
>> I'm wondering if it will be possible to build and use 
>> both PHP4 and PHP5 as apache modules on the same webserver, 
>> similar to the way we could use both PHP3 and PHP4.

[snip]

> the patch for naming everything php5 and not php4 is done, i 
> am just finishing the patch to enable versioning properly.

Excellent. Way to go James.
This'll be so handy.
I was a little concerned about the application-type directives
in httpd.conf and how that would work.

I'm assuming PHP5 will use _only_ ZE2 once it's forked?

Regards
Mike Robinson



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] PHP4 + PHP5

[Mike Robinson]

Hiya,

I'm wondering if it will be possible to build and use both PHP4
and PHP5 as apache modules on the same webserver, similar to the
way we could use both PHP3 and PHP4.

Regards
Mike Robinson


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] size of session vars

[Ford, Mike [LSS]]

> -Original Message-
> From: Andi Gutmans [mailto:[EMAIL PROTECTED]]
> Sent: 10 January 2003 11:11
> 
> Lately, when people start asking php-general questions on 
> php-dev people 
> give them the answer and add "but you should have asked on 
> the php-general 
> list". Having received a good answer from php-dev gives them 
> incentive to 
> mail us again :)
> I suggest we keep to the standard polite reply that they 
> should please mail 
> php-general without giving them the answers.

If you really, really want to be helpful and give an answer,
couldn't you CC php-general into the standard polite reply,
and then go answer that when it shows up?

Or maybe the standard protocol for the standard polite reply
should be to CC it to php-general?

Cheers!

Mike

-
Mike Ford,  Electronic Information Services Adviser,
Learning Support Services, Learning & Information Services,
JG125, James Graham Building, Leeds Metropolitan University,
Beckett Park, LEEDS,  LS6 3QS,  United Kingdom
Email: [EMAIL PROTECTED]
Tel: +44 113 283 2600 extn 4730  Fax:  +44 113 283 3211 

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] ZE2 + php 4.4.0

[Mike Robinson]

Tularis wrote:
> 
> btw, has anyone tested this combo with mysql 4 yet?

Yup, mysql-4.0.7-gamma.
Works fine for me, except phpMyAdmin has some minir problems
that I haven't bothered tracking down yet.

Regards
Mike Robinson


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Happy New Year!

[Mike Robinson]

 To All,

 Congratulations to all of you on a fine year for PHP, and
 continued success in the future.

 Peace to you and yours, and a Happy New Year. :)


 Best Regards
 Mike Robinson


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] PHP Look Back 2002

[Mike Robinson]

Derick Rethans wrote:
> 
> We are almost at the end of 2002, and it seemed appropriate 
> to look back on the development issues of the past year. So 
> starts the first PHP Look Back! You can find it @ 
> http://www.derickrethans.nl/20021230.php, and if 
> you have any comments,feel free to post them with the link at
> the bottom of the page.

Awesome and classy.
Much like your contribution to PHP.
Thanks, and all the best to you in '03.

Regards
Mike Robinson




-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] PHP 4.3.0 released

[Mike Robinson]

Ari Pollak wrote:
> On Fri, Dec 27, 2002 at 07:41:50PM -0500, Mike Robinson wrote:
> > Shouldn't that be 'sapi/cgi/php and sapi/cli/php respectively'?
> 
> The second path is wrong, and respectfully should be respectively.
> 

Duh.
I guess I should lay off the egg nog eh?
:P

Mike


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] PHP 4.3.0 released

[Mike Robinson]

Sander Steffann writes:
> Hi All,
> 
> There is a weird line in here too:
> 
> >  * PHP Manual: Using PHP from the command line
> >http://www.php.net/manual/en/features.commandline.php
> 
> It's this one:
> By default when executing make, both the CGI and CLI are 
> built and placed as sapi/cgi/php and sapi/cgi/php respectfully
> 
> The second path is wrong, and respectfully should be respectively.

Shouldn't that be 'sapi/cgi/php and sapi/cli/php respectively'?
 ^^^

Regards
Mike Robinson


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] option to start in PHP mode

[Mike Robinson]

Andrei Zmievski wrote:

> We've talked about this in the past, but let's bring it up 
> again. It is a bit awkward to use CLI when it requires those 
>  tags. We should probably have a command-line 
> option that tells the parser to start in PHP mode instead of 
> HTML/text. Any thoughts on this?

FWIW, almost without fail every time I write a new CLI script
I forget to put the start/stop tags in and I get an error the
first time I run it. So from an 'intuitive' point of view,
[ and notwithstanding the value of my opinion :P ], the switch
sounds like a good idea to me.

Best Regards
Mike Robinson


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Safe Mode Off

[Mike Hall]

You don't... for that would be a profoundly stupid feature, defeating
the point of safe mode.

And I suspect [EMAIL PROTECTED] would be a better place for this
question

--- Original Message ---
From:"Shashwat Nagpal" <[EMAIL PROTECTED]>
To:  [EMAIL PROTECTED]
Date:Sat, 21 Dec 2002 14:37:58 +0530
Subject: [PHP-DEV] Safe Mode Off

how can i turn safe_mode on or off  from within the script...



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php




-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] T_PAAMAYIM_NEKUDOTAYIM

[Mike Robinson]

Just so you know, not so long ago a google search for
"T_PAAMAYIM_NEKUDOTAYIM" used to turn up just 1 matching result.

:P

Regards
Mike Robinson


Pierre-Alain Joye wrote:
> On Tue, 17 Dec 2002 00:17:47 +0100
> Pierre-Alain Joye <[EMAIL PROTECTED]> wrote:
> 
> > On Mon, 16 Dec 2002 23:56:03 +0100
> > Bertrand Mansion <[EMAIL PROTECTED]> wrote:
> > 
> > > will return 'Undefined variable: this'...
> > 
> > The syntax foo::bar() should be used for every method callable
> > directly(ex: a factory), without an instance of the parent object.
>^^
>without an instance of the object itself.


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Re: #20972 [Opn->Csd]: make fails during gd.c

[Mike Robinson]

Ilia A. wrote:
> This is a different bug (xpm) caused by a bug in the external 
> GD library, this 
> particular bug has been solved in the CVS. Unless you've 
> patched your GD with 
> gif write support you have nothing to gain from not using the bundled 
> library, which offers more functionality and is more stable. 
> The problem with 
> free/gd_free is likely due to you having 2 sets of the GD 
> library on your 
> computer. This confuses the check, because the headers do not 
> correspond with 
> the library itself.

Is the xpm fix going to make it into 4.3 then?

Regards
Mike Robinson
 


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] [PHP-QA] Test results (fwd)

[Mike Robinson]

There are other problems with gd, specifically with the xpm
stuff. RC3 barfs compiling against external gd libs.

Incorporating the changes found in:

http://cvs.php.net/co.php/php4/ext/gd/php_gd.h?login=2&r=1.49

and

http://cvs.php.net/co.php/php4/ext/gd/gd.c?login=2&r=1.239

fixes the problem, which didn't occur in RC2.

Regards
Mike Robinson

Marcus Börger writes:

> When you use gd and jpeg configure.m4 from gd will check 
> first for existance of the library file and second for one of 
> its functions. So i guess there is somethink wrong with the 
> #ifdefs in gd.c or in generating them in config.m4. This is 
> all i can say now but perhaps i can take a look into it 
> tomorrow.after sleeping :-)
> 
> This is you rline: "checking for jpeg_read_header in -ljpeg... yes"
> 


--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] php.exe - php-cgi.exe

[Ford, Mike [LSS]]

> -Original Message-
> From: Zeev Suraski [mailto:[EMAIL PROTECTED]]
> Sent: 11 December 2002 12:15
> 
> Guys, fact is that it doesn't matter that much what this binary is 
> called.  We can call it bhb for all practical purposes (not that I'm 
> suggesting that).  People will get used to whatever it's named.

If it were me (which, of course, it isn't, but...), I'd leave the cgi as php
and call the command-line version phpc.

(Well, actually, if it were *just* me, I'd leave them both as php -- even on
Windows -- and just make sure I had them in appropriate directories, but I'm
extremely aware that real-world users are often not up to that kind of
subtlety.)

What I absolutely would *not* do is rename the cgi version to php-cgi whilst
*simultaneously* introducing a new php with a different purpose.  If I were
going to do this, I'd want to do it in steps: 1 - cgi to php-cgi + introduce
php-cli (so any installations still looking for php get a straight file not
found); 2 - php-cli to php.  As I'm pretty sure this isn't going to fly,
let's go back to my first para...!!

Cheers!

Mike

-
Mike Ford,  Electronic Information Services Adviser,
Learning Support Services, Learning & Information Services,
JG125, James Graham Building, Leeds Metropolitan University,
Beckett Park, LEEDS,  LS6 3QS,  United Kingdom
Email: [EMAIL PROTECTED]
Tel: +44 113 283 2600 extn 4730  Fax:  +44 113 283 3211 

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] php.exe - php-cgi.exe

[Mike Robinson]

Wez Furlong writes:

On Sun, 8 Dec 2002, Mike Robinson wrote:
> > Sorry. There's just no way this should happen.

> But it has happened, and it's going stay this way.
> 
> Now, if you don't have anything positive to contribute, 
> please stop stirring up threads like this (again) without 
> first understanding the issues behind them.  It just wastes 
> time, which is better spent developing, bug fixing, 
> documenting - doing just about anything else is more productive.

You are correct in your assumption that I have difficulty
understanding the issues behind this change. After asking several
times for an explanation, and after having gone over the archives
to find some related discussion (and asking for pointers to that
as well), I came to conclusion that this change is totally wrong.
This change has nothing to do with fixing anything. It's breaking
BC in a huge way, at the historical level, for the sake of a minor
convenience for a very small group of users.

Throwing lame excuses at it, like "it's evolution", doesn't cut
it with me. I'm still at the same place. This is just wrong. It
has nothing to do with stirring anything up. 

Regards
Mike Robinson



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] php.exe - php-cgi.exe

[Mike Robinson]

Marcus Börger wrote:
> At 22:08 08.12.2002, Mike Robinson wrote:
> >Christoph Grottolo wrote:
> >
> > > It's worse.
> > >
> > > At least PHP 4.2.2 and 4.2.3. have php-cli.exe (CLI) and php.exe
> > > (CGI).
> >
> >This is the way it should stay.
> >I'm trying to find the archive of the discussion that lead to this
> >being changed. I'm having a huge problem getting my head 
> around why the
> >name of the CGI executable has to be changed at all. Any pointers or
> >enlightenment would be welcomed. :)
> >
> >Regards
> >Mike Robinson
> 
> 
> Just because you only need to type the name of the CGI sapi
> once: In other word one single time until we decide the name 
> changes. But you will use a command line interface hopefully 
> very often. I for one do and i am not going to type 
> php-cli.exe because it is way much to long.

Every system on the planet that uses php.exe as their CGI executable,
and I suggest there are quite a few, will have a broken setup with a
stock install of php-4.3.0, because typing php-cli.exe at the command
line is too long. And you expect putting huge notes and warnings in the
news file and installer will prevent this from happening.

> The reason against renaming CGI and using its old name for
> the CLI now would have lead us to register_globals=ON for eternity.

Totally different. Apples and oranges.
That was a security-related change, and IMHO, the amount of trouble
_that_ change caused far outweighed the meagre benefits achieved.

This change is going to break a lot of setups for the sake of cli users
saving a few keystrokes.

Sorry. There's just no way this should happen.

Regards
Mike Robinson


--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] php.exe - php-cgi.exe

[Mike Robinson]

Christoph Grottolo wrote:

> It's worse.
> 
> At least PHP 4.2.2 and 4.2.3. have php-cli.exe (CLI) and 
> php.exe (CGI).

This is the way it should stay.
I'm trying to find the archive of the discussion that lead to this
being changed. I'm having a huge problem getting my head around why
the name of the CGI executable has to be changed at all. Any pointers
or enlightenment would be welcomed. :)

Regards
Mike Robinson


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] php.exe - php-cgi.exe

[Mike Robinson]

Marcus Börger wrote:

> There was no cli and only cgi binary called php.exe.
> Then we decided to have a command line executable 
> (abbrevation CLI). And the we decided to use 'php.exe' for 
> the new CLI and to avoid confusion we chose to rename the CGI 
> binary from 'php.exe'. So now there will be some books and 
> other papers and online docs out there which state that 
> php.exe has to be installedIn other words there will be 
> users who install CLI as CGI what will lead into errors.

Well no offence, but renaming the CGI executable is just plain
wrong. The CLI executable should be named php-cli.exe. This seems
like such a nobrainer. Am I missing something? Clue me in.

Regards
Mike Robinson



--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] RE: [PHP-DOC] #20822 [Com]: getimagesize() returning null instead of false

[Mike Robinson]

Marcus Börger wrote:

>  From my point of view accessing a file should result in an 
> error if the file cannot be opened or in case of 
> GetImageSize() a file operation cannot be executed. For 
> example i would expect GetImageSize() to show an error if the 
> information cannot be retrieved due to file corruptions.

I agree. Absolutely. Masking bona fide file operation errors would
be a huge mistake, IMHO. 

Regards
Mike Robinson


--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] [PATCH] Redirect on Error

[Mike Robinson]

 Sterling Hughes writes:

> you're missing alot.
> 
> Its not inbox size, when you get multi-lingual error messages 
> you have more than one problem.
> 
> 1) Support.
[snip]

> 2) Implementation. 
[snip]

> 3) Everything else is in english.
[snip]

There are other problems too, but these are the biggies. Can't imagine
what this'll do to the workload for the QA folks.

I can appreciate the motive for multi-language error messages, but
its asking for trouble on a huge scale. If english is good enough
for programmers and air traffic controllers all over the world, its
good enough for PHP error messages. :) 


> These things should really come about via necessity.  I very rarely
see 
> the question "how can i catch parse errors on my production site", if 
> you really need, you can turn off display_errors, and that should do
it.


Yup.
When used with the logging stuff [syslog,logfile], it works quite well.
 

> The fact is, you shouldn't be needing code to catch a parse 
> error, if you do, there is something wrong with the way you 
> program, not with php.


Bingo.


Regards
Mike Robinson







-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] error handling

[Mike Robinson]

In Real Life [Patent Pending], if you cripple your production site
in the middle of the night then go to bed, you won't have to worry
about any of this because you'd be unemployed in the morning.

I agree with Derick's assessment.

I always have the option of turning display errors off (which is the
recommendation for production sites) and cranking stuff out to syslog
or some file I can monitor.

Throwing a 500 document is ugly, and so 90's. :)
Being competitive does not mean 'being like the other guys', a path
PHP has carefully and rightfully avoided.

Regards
Mike Robinson

Ivan Ristic writes:
> Edin Kadribasic wrote:
> 
> > On Thursday 21 November 2002 08:04, Derick Rethans wrote:
> >
> > >I still think that an included file just should fail hard 
> and I just 
> > >dont like this kind of obfucsication.
> >
> >
> > I agree with this 100%. It is IMHO a complete waste of time 
> trying to
> > handle parse errors gracefully. Most "solutions" proposed in this 
> > thread are either  server specific or would have an impact 
> on normal 
> > php operation (would require output buffering, etc.).
> 
>And in the real life you sometimes must change things live
>on the server, in the middle of the night. If you make a
>mistake then, and we all do, you will go to sleep without
>realising that the app/web site no longer works properly.
> 
>I use logwatch for this at the moment, but that is, IMHO, a
>very, very, clumsy solution.







-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Memory persistence with apache question

[Mike Leddy]

Unfortunately I can't ask my clients to upgrade to a CVS version -
v1.3.2 isn't available yet :-(

But more generally wouldn't it be nice if PHP could GUARANTEE that
memory resources are recovered on script termination ?

Lot's of scripts are written without proper consideration for memory -
and ISPs suffer because of it.

I use apache that forks children so I can sidestep the issue with
MaxRequestsPerChild  (at a performance hit for other clients)... 

What it I was using a threading model in apache 2.0 ? 

Mike

On Mon, 2002-11-18 at 22:52, Marcus Börger wrote:
> Problems that could arise:
> The sytem tries to open images and does not unset the variables...and
> such.
> I guess when everything is working you cannot do anything against. If
> you want 
> to investigate more you would need a debug version from php to verify
> if all
> memory is freed.
> 
> But this is the post from the developer who is assigned to the bug on
> Sourceforge:
> 
> >Date: 2002-10-23 17:59
> >Sender: bharat
> >Logged In: YES 
> >user_id=42211
> >
> >This is fixed in v1.3.2
> 
> marcus
> 
> At 04:33 19.11.2002, Mike Leddy wrote:
> > Hello,
> > 
> > I administer a linux 2.4.19/apache 1.3.26/php 4.1.2 server in an
> > ISP.  
> > 
> > Recently some clients started using a gallery php script:
> > http://gallery.sf.net
> > 
> > that causes excessive memory utilization on the server:
> > 
>http://sourceforge.net/tracker/index.php?func=detail&aid=498028&group_id=7130&atid=107130
> > So here goes the question:
> > 
> > In what situations will memory allocated to a script remain with the
> > apache process after the script has terminated ?
> > 
> > I always thought that memory allocated would be released on script
> > termination - Am I wrong in this assumption ? 
> > 
> > Could it be that the heap in the apache process stays at the
> > maximally
> > used level ?
> > 
> > Thanks for any pointers or how I should approach resolving this
> > problem.
> > (I am already using 'MaxRequestsPerChild 5' in apache as a stopgap
> > measure)
> > 
> > Mike
> > 
> > 
> > 
> > -- 
> > PHP Development Mailing List <http://www.php.net/>
> > To unsubscribe, visit: http://www.php.net/unsub.php
-- 
Atenciosamente

Mike Leddy,
Systems Administrator,
Braslink Network Inc., Miami, FL.
Tel +1 305 279 3232


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] 4.2.3 mbstring patch?

[Ford, Mike [LSS]]

> -Original Message-
> From: Yasuo Ohgaki [mailto:[EMAIL PROTECTED]]
> Sent: 19 November 2002 10:19
> 
> Andrei Zmievski wrote:
> > On Thu, 14 Nov 2002, lowbwtom wrote:
> > 
> >>Will there be a patch to fix the mbstring bug in 4.2.3? Any 
> idea when?
> >>(specifically to fix the missing 4 characters in array posts)
> >>
> (BTW, I don't use array, since "[]" are illegal chars)

Uh -- is this referring to form element name= attributes?

Cheers!

Mike

-
Mike Ford,  Electronic Information Services Adviser,
Learning Support Services, Learning & Information Services,
JG125, James Graham Building, Leeds Metropolitan University,
Beckett Park, LEEDS,  LS6 3QS,  United Kingdom
Email: [EMAIL PROTECTED]
Tel: +44 113 283 2600 extn 4730  Fax:  +44 113 283 3211 

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Just a little question

[Ford, Mike [LSS]]

> -Original Message-
> From: Hacook [mailto:[EMAIL PROTECTED]]
> Sent: 19 November 2002 09:48
> 
> I have a chain charachter that look like this :
> *text*text*text*text*textetc
> I would like to cut off the FIRST star but not the others
> My chain is REALLY long.
> I made that script :
> 
> $maxi=strlen($resultats)-2;
> $nb = 0;
> while ($nb<=$maxi) {
> $results2 = $results2.$results[1+$nb];
> $nb = $nb+1;
> }
> 
> where $results is the chain
> It works perfectly but it takes over 5 minutes !
> Do you have any idea on how to make it faster ?

(a) wrong list -- you want [EMAIL PROTECTED]

(b) $results2 = substr($results, 1);

Cheers!

Mike

-----
Mike Ford,  Electronic Information Services Adviser,
Learning Support Services, Learning & Information Services,
JG125, James Graham Building, Leeds Metropolitan University,
Beckett Park, LEEDS,  LS6 3QS,  United Kingdom
Email: [EMAIL PROTECTED]
Tel: +44 113 283 2600 extn 4730  Fax:  +44 113 283 3211 

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Mailparse extension

[Mike Hall]

Is this going to be production stable in 4.3.0?

Cheers,

Mike

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Memory persistence with apache question

[Mike Leddy]

Hello,

I administer a linux 2.4.19/apache 1.3.26/php 4.1.2 server in an ISP.  

Recently some clients started using a gallery php script:
http://gallery.sf.net

that causes excessive memory utilization on the server:
http://sourceforge.net/tracker/index.php?func=detail&aid=498028&group_id=7130&atid=107130
 
So here goes the question:

In what situations will memory allocated to a script remain with the
apache process after the script has terminated ?

I always thought that memory allocated would be released on script
termination - Am I wrong in this assumption ? 

Could it be that the heap in the apache process stays at the maximally
used level ?

Thanks for any pointers or how I should approach resolving this problem.
(I am already using 'MaxRequestsPerChild 5' in apache as a stopgap
measure)

Mike



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] GD 2.0.6 make errors

[Mike Robinson]

Derick Rethans wrote:
 
> It clearly crashes in the gid stuff... most likely the zlib version 
> against which gd was build does not match the zlib against PHP was 
> linked. But I really dont think you should be asking for support, as 
> this is a hacked up GD.

Nope, not asking for support. Just mentioning the segfault.
Thanks for taking it easy on me though. :)

Best Regards
Mike Robinson





-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] GD 2.0.6 make errors

[Mike Robinson]

> Jani Taskinen writes:

> This was actually fixed long time ago in CVS..
> 

I use 2.0.4 with the gif stuff hacked in, and current CVS from
about 5 minutes ago segfaults when using the gif stuff. Might be
a problem with the gd lib I'm using... backtrace as follows
(couldn't get a core file).

Regards
Mike Robinson


Starting program: /usr/local/apache/bin/httpd -X

Program received signal SIGSEGV, Segmentation fault.
0x40599842 in compress (init_bits=3, outfile=0x81614fc, im=0x8166c00) at
gd_lzw_out.c:534
534 if ( HashTabOf (i) == fcode ) {
(gdb) bt
#0  0x40599842 in compress (init_bits=3, outfile=0x81614fc,
im=0x8166c00) at gd_lzw_out.c:534
#1  0x405996c5 in GIFEncode (fp=0x81614fc, GWidth=365, GHeight=599,
GInterlace=0, Background=0, 
Transparent=-1, BitsPerPixel=1, Red=0x8166c10, Green=0x8167010,
Blue=0x8167410, im=0x8166c00)
at gd_lzw_out.c:349
#2  0x40599139 in gdImageLzwCtx (im=0x8166c00, out=0x81614fc) at
gd_lzw_out.c:67
#3  0x4059807b in gdImageGifCtx (im=0x8166c00, out=0x81614fc) at
gd_gif_out.c:23
#4  0x4014d413 in _php_image_output_ctx (ht=1, return_value=0x81612dc,
this_ptr=0x0, return_value_used=0, 
image_type=1, tn=0x402c77de "GIF", func_p=0x4059805a
)
at /usr/local/src/phpcvs/php4/ext/gd/gd_ctx.c:98
#5  0x40150987 in zif_imagegif (ht=1, return_value=0x81612dc,
this_ptr=0x0, return_value_used=0)
at /usr/local/src/phpcvs/php4/ext/gd/gd.c:1642
#6  0x4023e336 in execute (op_array=0x81512e4) at
/usr/local/src/phpcvs/php4/Zend/zend_execute.c:1595
#7  0x40231c15 in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at /usr/local/src/phpcvs/php4/Zend/zend.c:840
#8  0x4020d20c in php_execute_script (primary_file=0xb6c0) at
/usr/local/src/phpcvs/php4/main/main.c:1560
#9  0x40241efe in apache_php_module_main (r=0x8144f1c,
display_source_mode=0)
at /usr/local/src/phpcvs/php4/sapi/apache/sapi_apache.c:55
#10 0x402428c5 in send_php (r=0x8144f1c, display_source_mode=0,
filename=0x0)
at /usr/local/src/phpcvs/php4/sapi/apache/mod_php4.c:556
#11 0x40242a5a in send_parsed_php (r=0x8144f1c) at
/usr/local/src/phpcvs/php4/sapi/apache/mod_php4.c:571
#12 0x080542c0 in ap_invoke_handler ()
#13 0x0806876a in process_request_internal ()
#14 0x080687ca in ap_process_request ()
#15 0x0805fb8e in child_main ()
#16 0x0805fd54 in make_child ()
#17 0x0805febb in startup_children ()
#18 0x080604e8 in standalone_main ()
#19 0x08060d20 in main ()
#20 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6 


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] GD 2.0.6 make errors

[Mike Robinson]

Its up to 2.0.6 now. :)
Boutell has gone GD crazy all of a sudden.

Regards
Mike Robinson


> -Original Message-
> From: Pierre-Alain Joye [mailto:paj@;pearfr.org] 
> Sent: Thursday, November 14, 2002 11:55 AM
> To: Clay
> Cc: [EMAIL PROTECTED]
> Subject: Re: [PHP-DEV] GD 2.0.6 make errors
> 
> 
> On Thu, 14 Nov 2002 11:51:30 -0500
> "Clay" <[EMAIL PROTECTED]> wrote:
> 
> > Gcc 3.2
> > Solaris 9
> > 
> > 2.0.1 works fine.  Any ideas?  Anyone compile 2.0.6 yet on any 
> > platform?
> 
> do you mean 2.04 official gd ?
> 
> pa
> 
> -- 
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, visit: http://www.php.net/unsub.php
> 


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] strpos() suggestion

[Mike Hall]

Why couldn't you just strrev() the string and then strpos() for it?

Mike

--- Original Message ---
From:Monte Ohrt <[EMAIL PROTECTED]>
To:  [EMAIL PROTECTED]
Date:13 Nov 2002 16:02:54 -0600
Subject: [PHP-DEV] strpos() suggestion

Hi,

I had a little problem to solve today, and couldn't find any easy way to
do it without some extra steps slicing things up.

What I wanted to do is take an arbitrary point in a string, and find the
position of the first '[' on the left of it, and the first ']' on the
right of it.

Finding the ']' was easy, I use strpos() to find the first occurance of
']' after my given point.

Finding '[' however is not so easy. strrpos() was my first guess, but it
does not work like strpos() at all. There is no optional third
parameter, and on an unrelated note it only works with a single
character, not a string. inconsistant ;-) My best solution was to slice
the string at my point, then get the position of '[' with strrpos().

I'm not sure of the most intuitive way to solve this. One way would be
to add a feature to strpos(); if you supply a negative third parameter,
it gives you the position of the first occurance to the _left_ of that
point. I'm not sure if the number should represent the position from the
end or beginning of the string. Another way, add a third parameter to
strrpos() to start at a given point from the end of the string.

I'd try submitting a patch, but I'm not sure of which way would be best,
and my C is a bit rusty, I'd probably do more damage than help ;-)

Thoughts?
Monte


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php




-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] mbstring and 4.3.0

[Mike Robinson]

Jani Taskinen writes:

> I must (still) agree. +1 for making it disabled for now..
> (people who need it, already know to use 
> --enable-mbstring with 4.2.3)

Exactly.
It should remain off by default until it's solid.

Regards
Mike Robinson


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] [RFC] php-cli: option to ignore php.ini

[Mike Robinson]

Good idea. This is useful. Thanks. :)

Regards
Mike Robinson


> -Original Message-
> From: Marcus Börger [mailto:marcus.boerger@;t-online.de] 
> Sent: Tuesday, November 12, 2002 4:05 PM
> To: Wez Furlong
> Cc: [EMAIL PROTECTED]
> Subject: Re: [PHP-DEV] [RFC] php-cli: option to ignore php.ini
> 
> 
> Implemented:
> 
> [marcus@zaphod php4-HEAD]$ php -r 
> 'var_dump(get_cfg_var("cfg_file_path"));var_dump(php_ini_scann
ed_files());'
> string(20) "/home/marcus/php.ini"
> bool(false)
> 
> [marcus@zaphod php4-HEAD]$ php -n -r 
> 'var_dump(get_cfg_var("cfg_file_path"));var_dump(php_ini_scann
ed_files());'
> bool(false)
> bool(false)
> 
> [marcus@zaphod php4-HEAD]$ php -c x -n -r 
> 'var_dump(get_cfg_var("cfg_file_path"));var_dump(php_ini_scann
ed_files());'
> You cannot use both -n and -c switch. Use -h for help.
> 
> marcus
> 
> At 13:31 11.11.2002, Wez Furlong wrote:
> >What are your opinions for having some option to prevent the 
> >loading/parsing of php.ini for the CLI version of PHP?
> >
> >   -n "No Ini File"  - skips parsing php.ini on startup
> >
> >At the moment, I'm using "-c DOESNOTEXIST" to achieve the 
> same result, 
> >but this is a bit hacky.
> >

> 


--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Bug in PHP

[Mike Robinson]

Markus Fischer writes:

> 
> You can use PHP as CGI on Win32/IIS platform which proves to
> be far more stable or use Apache instead of IIS.
> 
> The combination you're using is known to have serious
> problems and is not recommended.
> 

Is this documented anywhere?

Regards
Mike Robinson



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] ODBTP, a possible solution for MS-SQL and other databases

[Mike Robinson]

Robert Twitty writes:

> So far 3 people have shown interest in ODBTP, however, it is 
> the weekend.  I am currently working on packaging it in a 
> tar.gz file.  If the response is low I will only release it 
> to those who have shown an interest, and if it becomes higher 
> than I will release it to the list.  It is very important to 
> me that the people who acquire it actually will use it and 
> provide feedback within a reasonable time period.  I do not 
> want to feel like I put it in  a "black hole."

Keep in mind some of the folks are in the throws of a fairly intense
release cycle.

I'd be interested in seeing more about this extension. It sounds
like it could be useful. What kind of license would this stuff
be released under?

Best Regards
Mike Robinson



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Re: Unsigned Problems Revisited

[Ford, Mike [LSS]]

> -Original Message-
> From: Andi Gutmans [mailto:andi@;zend.com]
> Sent: 30 October 2002 19:26
> 
> I think you guys have convinced me that having >>> only isn't too bad 
> (Jason will kill me now).
> Does anyone here on php-dev have any additional thoughts?

Well, although I think it's a good idea to add the missing shift
operator, I'd be a bit worried about the potential for confusion 
caused by having <<< and >>> operators that are not opposites of each 
other -- particularly with people trying to use <<< as a shift on the 
grounds that it "ought" to exist and wondering why the rest of their 
script had apparently disappeared down a black hole!

Whilst I don't want to start another lengthy discussion that ends up
going round the mulberry bush umpteen times, should we be considering
whether this is a case where PHP should strike out on its own and use
a slightly different operator for this?

Cheers!

Mike

-
Mike Ford,  Electronic Information Services Adviser,
Learning Support Services, Learning & Information Services,
JG125, James Graham Building, Leeds Metropolitan University,
Beckett Park, LEEDS,  LS6 3QS,  United Kingdom
Email: [EMAIL PROTECTED]
Tel: +44 113 283 2600 extn 4730  Fax:  +44 113 283 3211 


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Re: Unsigned Problems Revisited

[Mike Robinson]

Jason T. Greene writes:

> Ok,
> 
> I hereby volunteer to update the documentation to clearly 
> explain shifting (with examples).

Excellent!
That way, I can't stop losing sleep wondering what the heck
someone would need this stuff for. :)

Best Regards
Mike Robinson



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Re: [PHP-DOC] Re: [PHP-DEV] Re: [PHP-DOC] Apache 2 installation instructions

[Mike Robinson]

Derick Rethans writes:

> On Tue, 29 Oct 2002, Gabor Hojtsy wrote:
> 
> > As far as I can see, we should not not put into the PHP 
> documentation 
> > that Apache 2 is not production ready, but PHP is not 
> production ready 
> > for Apache 2.
> 
> But it's incorrect :). By saying "Do not use Apache 2 and PHP in a 
> production environment" you don't blame any of the two projects. 

I agree with Derick's approach.
There's no need to cast dispersions on either Apache2 or PHP.
Simply stating _clearly_ that the combination of PHP4 and Apache2
should not be used in a production environment is sufficient.

No need to play the blame-game. :)

Regards
Mike Robinson




-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] hebrew patch for jewish calendar

[Mike Hall]

I received the attachment... you sure it's his mailer playing up? ;-)

Mike

--- Original Message ---
From:Derick Rethans <[EMAIL PROTECTED]>
To:  moshe doron <[EMAIL PROTECTED]>
Date:Mon, 28 Oct 2002 14:37:05 +0100 (CET)
Subject: Re: [PHP-DEV] hebrew patch for jewish calendar

> On Mon, 28 Oct 2002, moshe doron wrote:
> 
> > i did it  (1.txt)
> 
> Still no attachment but everything inline. 
> Your mailer is apparently so braindead to include it inline. I want to 
> bet it's Outlook...
> 
> Derick

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] I hope this is the last email about this :)

[Ford, Mike [LSS]]

> -Original Message-
> From: Zeev Suraski [mailto:zeev@;zend.com]
> Sent: 28 October 2002 02:06
> 
> Thank you for the detailed explanation, I'm sure everybody 
> understands it now.
> 
> Let's go for the voting phase.  I vote we keep PHP-CLI with 
> implicit_flush 
> on by default.

+1

Cheers!

Mike

-----
Mike Ford,  Electronic Information Services Adviser,
Learning Support Services, Learning & Information Services,
JG125, James Graham Building, Leeds Metropolitan University,
Beckett Park, LEEDS,  LS6 3QS,  United Kingdom
Email: [EMAIL PROTECTED]
Tel: +44 113 283 2600 extn 4730  Fax:  +44 113 283 3211 

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] I hope this is the last email about this :)

[Mike Robinson]

Zeev Suraski writes:

> I vote we keep PHP-CLI with implicit_flush 
> on by default.

Ditto.

Regards
Mike Robinson



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] I hope this is the last email about this :) (was RFC:

[Ford, Mike [LSS]]

> -Original Message-
> From: Yasuo Ohgaki [mailto:yohgaki@;ohgaki.net]
> Sent: 24 October 2002 07:42
> To: [EMAIL PROTECTED]; Alan Knowles
> 
> Alan Knowles wrote:
> > Im +1 for reverting the patch - (for what it's worth)
> > 
> 
> This makes 2+ for having auto flushing :)

Add one more -- or even more, as I 'd say I'm +>1 for this!

> BTW, real language (i.e. not shell) don't flush. Please let me
> know if there is real language that do automatic flushing by
> default.

But PHP-CLI *is* a shell-scripting language, and therefore should behave
like one.  Other flavours of PHP aren't, and shouldn't.  QED.

> In addition, is it too difficult to write this kind of code?
> 
> function prompt($prefix) {
>   echo $prefix;
>   flush();
> }
> 
> I think this kind of code will be taught at the first
> class of programming course. (I could be wrong,
> since I don't know where people learned programming ;)

At university: learned half-a-dozen languages; *all* of them flushed streams
open on TTY either after every character, or (at line-end or when input
requested from same device).  I've been programming now for over 25 years,
and this is *still* the behaviour I expect by default when programming
command-line-executable scripts or programs.

> Let's guess something interesting.
> 
> How much % of scripts actually needs automatic flushing?
> My guess is less than 1%. What is yours?

For PHP-CLI: more than 90%.
For PHP CGI or SAPI: much less than 1%.

-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] I hope this is the last email about this :) (was

[Ford, Mike [LSS]]

> -Original Message-
> From: Yasuo Ohgaki [mailto:yohgaki@;ohgaki.net]
> Sent: 24 October 2002 09:01
> To: [EMAIL PROTECTED]; Melvyn Sopacua
> 
> Are you going to insist most scripts need inefficient auto flushing?

For CLI, yes.

> Have you ever used other programming languages?

Yes -- over 40 at last count!  (Even written the odd compiler in my time!)

> 
> I don't get it, but this is the 3rd vote.
> Too few still and reasoning is too weak.
> 
> BTW, if anyone would like to vote for inefficient/mostly useless
> auto flushing. Please add your vote to this article.
> 
> http://news.php.net/article.php?group=php.dev&article=89995

I would, but I can't see any way of replying/voting on the page that URL takes me 
to...!

Cheers!

Mike

-----
Mike Ford,  Electronic Information Services Adviser,
Learning Support Services, Learning & Information Services,
JG125, James Graham Building, Leeds Metropolitan University,
Beckett Park, LEEDS,  LS6 3QS,  United Kingdom
Email: [EMAIL PROTECTED]
Tel: +44 113 283 2600 extn 4730  Fax:  +44 113 283 3211 

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] php_value vs. php_admin_value

[Ford, Mike [LSS]]

> -Original Message-
> From: Rasmus Lerdorf [mailto:rasmus@;php.net]
> Sent: 21 October 2002 05:49
> 
> admin directives can only be used in the httpd.conf file.  
> Non-admins can
> be used in both httpd.conf and .htaccess.  ie. directives 
> that end-users
> should not be able to change themselves should be admin ones.

But the documentation is still not sufficiently clear on how to decide when
to use php_ directives and when to use php_admin_.  When I first came to do
a setup using these, I had a number of questions, and whilst I think I can
make an intelligent guess at some of the answers, I'm still not absolutely
sure.  The documentation should, clearly and unambiguously, answer all of
these:

* How do I decide when to use php_admin_* and when php_*?
  Is it based on the PHP_INI_* settings?
  - If so which one(s)?
  - If not, what is it based on?

* Can I use php_admin_* to set options have the PHP_INI_USER
  attribute (or PHP_INI_ALL)?
  - If so does that stop them from subsequently being
altered in other contexts (specifically in user scripts?).

Even after running a number of tests, I'm just not sufficiently sure of the
answers to suggest specific improvements -- but if someone "in the know"
could write a paragraph or two to answer the above questions, it would be a
major improvement.

(Shall I file a "Documentation problem" bug report?)

Cheers!

Mike

-
Mike Ford,  Electronic Information Services Adviser,
Learning Support Services, Learning & Information Services,
JG125, James Graham Building, Leeds Metropolitan University,
Beckett Park, LEEDS,  LS6 3QS,  United Kingdom
Email: [EMAIL PROTECTED]
Tel: +44 113 283 2600 extn 4730  Fax:  +44 113 283 3211 

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Bug count..

[Mike Robinson]

Jani Taskinen wrote:
> 
> Heh..just take a look in the database for bugs and them tell me
> how to get that data out of it. :)

SQL should do the trick.
:)

Regards
Mike Robinson

(Sorry, couldn't resist...)



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Re: Forked ext/gd by default

[Mike Robinson]

Rasmus Lerdorf writes:

> Whoa, pigs are flying over the skating rink in hell.

Those aren't pigs. That's the Unisys Legal Department.
It's a common mistake. :)

Regards
Mike Robinson






-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] [PHP-QA] Logs of failed tests PHP 4.3.0pre1 (fwd)

[Mike Robinson]

Michael Mauch wrote: 

> I doubt that the C library does anything useful with 
> non-ASCII characters while you are in a "C" or "POSIX" 
> locale, so expat or PHP can't do much to correct that.
> 
> So is your locale something other than "C" or "POSIX"? 
> "en_US.ISO-8859-1" for example?

Yup, thats what its set to.

> Perhaps ext/xml/tests/007.phpt could check whether it is able 
> to successfully use strtoupper() on $xmldata - and if not, 
> just skip that test?

I have no problem with this test failing. It actually provides
useful information. I'm not one to second-guess the intentions
of the author of this test ('sniper' I think). 

Thanks for the crash course on LOCALE. :)

Regards
Mike Robinson





-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] [PHP-QA] Logs of failed tests PHP 4.3.0pre1 (fwd)

[Mike Robinson]

Michael Mauch wrote:

[snip]
> >> > "en_US.ISO-8859-1" for example?
> >>
> >>Yup, thats what its set to.
> 
> Hmm. Strange. What does 
> 
>   php -r 'echo strtoupper("äöü"),"\n";'
> 
> yield on your system? And what system is it, btw?


It outputs äöü. Stock RedHat-8.0 box, kernel-2.4.18 glibc-2.2.93.


> We could use a test like strtopper("äöü")=="ÄÖÜ" to check if 
> the system is able to handle these characters correctly. If 
> not, the test could be skipped.
> 

Adding to ext/xml/tests/007.phpt:

if (strtoupper("äöü")!="ÄÖÜ") {  
print "skip\n";  
}

fixes this for me.

Regards
Mike Robinson


--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] [PHP-QA] Logs of failed tests PHP 4.3.0pre1 (fwd)

[Mike Robinson]

Michael Mauch writes:

> Are your locale settings ok?

Yeah, they're fine, for my locale.
But I'm not in Germany, though I'm told the beer there
is awesome. :)

Mike




> % locale 
> LANG=de_DE.ISO-8859-15
> LC_CTYPE=de_DE
> LC_NUMERIC="de_DE.ISO-8859-15"
> LC_TIME="de_DE.ISO-8859-15"
> LC_COLLATE=C
> LC_MONETARY="de_DE.ISO-8859-15"
> LC_MESSAGES="de_DE.ISO-8859-15"
> LC_ALL=
> % php ./run-tests.php ext/xml/tests/007.phpt 
> 
> =
> CWD : /usr/local/src/php-cvs/php4
> PHP : sapi/cli/php
> PHP_SAPI: cli
> PHP_VERSION : 4.3.0-dev
> PHP_OS  : Linux
> INI actual  : /usr/local/lib/php.ini
> More .INIs  : 
> Extra dirs  : 
> =
> Running selected tests.
> PASS xml_parse_into_struct/umlauts in tags 
> [ext/xml/tests/007.phpt] % LC_ALL=C php ./run-tests.php 
> ext/xml/tests/007.phpt
> 
> =
> CWD : /usr/local/src/php-cvs/php4
> PHP : sapi/cli/php
> PHP_SAPI: cli
> PHP_VERSION : 4.3.0-dev
> PHP_OS  : Linux
> INI actual  : /usr/local/lib/php.ini
> More .INIs  : 
> Extra dirs  : 
> =
> Running selected tests.
> FAIL xml_parse_into_struct/umlauts in tags [ext/xml/tests/007.phpt]
> 
> 
> Regards...
>   Michael
> 
> -- 
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, visit: http://www.php.net/unsub.php
> 


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] [PHP-QA] Logs of failed tests PHP 4.3.0pre1 (fwd)

[Mike Robinson]

Sorry, that test _is_ in 4.2.3, and it failed there as well
with the same problem, it just didn't output anything during
make test.

> -Original Message-
> From: Mike Robinson [mailto:mike@;mgrobinson.com] 
> Sent: Saturday, October 19, 2002 2:40 PM
> To: 'Kjartan Mannes'; 'PHP Developers Mailing List'
> Cc: 'Derick Rethans'
> Subject: RE: [PHP-DEV] [PHP-QA] Logs of failed tests PHP 
> 4.3.0pre1 (fwd)
> 
> 
> I don't think that's it, since it's [supposed to be] on be 
> default. Setting the option in the test changes nothing 
> anyways. The test is new since 4.2.3, so i couldn't go back 
> and see when it started failing. (Its interesting to note 
> that in 4.2.3 though, _all_ my xml tests failed).
> 
> Unfortunately, XML has not been a 'buzzword' for me, :) , so 
> I'm not really up on this stuff.
> 
> Mike
> 
> > 
> > Saturday, October 19, 2002, 7:35:05 PM, Derick Rethans wrote:
> > > On Sat, 19 Oct 2002, Mike Robinson wrote:
> > 
> > >> Yes I can reproduce this in 4.3.0pre1 and in CVS from yesterday.
> > >> Exact same output in ext/xml/tests/007.log as below in 
> both cases.
> > 
> > > Do you also know _why_ it fails and how we can fix either
> > the test or
> > > the code?
> > 
> > Couldn't possibly have anything to do with
> > XML_OPTION_CASE_FOLDING being disabled?
> > 
> http://no.php.net/manual/en/function.xml-parser-set-option.php
> 
> -- 
> Kjartan <[EMAIL PROTECTED]> (http://natrak.net/)
> :: "If you wish to be loved, show more of your faults than your
> virtues." - Edward Bulwer-Lytton
> 
> 
> -- 
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, visit: http://www.php.net/unsub.php
> 
> 
> -- 
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, visit: http://www.php.net/unsub.php
> 


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] [PHP-QA] Logs of failed tests PHP 4.3.0pre1 (fwd)

[Mike Robinson]

I don't think that's it, since it's [supposed to be] on be default.
Setting the option in the test changes nothing anyways. The test is new
since 4.2.3, so i couldn't go back and see when it started failing.
(Its interesting to note that in 4.2.3 though, _all_ my xml tests
failed).

Unfortunately, XML has not been a 'buzzword' for me, :) , so I'm not
really up on this stuff.

Mike

> 
> Saturday, October 19, 2002, 7:35:05 PM, Derick Rethans wrote:
> > On Sat, 19 Oct 2002, Mike Robinson wrote:
> 
> >> Yes I can reproduce this in 4.3.0pre1 and in CVS from yesterday. 
> >> Exact same output in ext/xml/tests/007.log as below in both cases.
> 
> > Do you also know _why_ it fails and how we can fix either 
> the test or
> > the code?
> 
> Couldn't possibly have anything to do with 
> XML_OPTION_CASE_FOLDING being disabled?
> 
http://no.php.net/manual/en/function.xml-parser-set-option.php

-- 
Kjartan <[EMAIL PROTECTED]> (http://natrak.net/)
:: "If you wish to be loved, show more of your faults than your
virtues." - Edward Bulwer-Lytton


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] [PHP-QA] Logs of failed tests PHP 4.3.0pre1 (fwd)

[Mike Robinson]

Yes I can reproduce this in 4.3.0pre1 and in CVS from
yesterday. Exact same output in ext/xml/tests/007.log as below
in both cases. 

Mike


> -Original Message-
> From: Derick Rethans [mailto:derick@;php.net] 
> Sent: Saturday, October 19, 2002 1:03 PM
> To: PHP Developers Mailing List
> Subject: [PHP-DEV] [PHP-QA] Logs of failed tests PHP 4.3.0pre1 (fwd)
> 
> 
> Hello,
> 
> somehow the test below fails for some people, but I couldn't 
> reproduce 
> it. Anybody else?
> 
> Derick
> 
> 
> FAIL xml_parse_into_struct/umlauts in tags [ext/xml/tests/007.phpt]
> 
>  EXPECTED OUTPUT
> string(3) "ÄÖÜ"
> array(1) {
>   ["ÜÄß"]=>
>   string(3) "Üäß"
> }
> string(3) "ÄÖÜ"
> array(1) {
>   [0]=>
>   array(5) {
> ["tag"]=>
> string(3) "ÄÖÜ"
> ["type"]=>
> string(8) "complete"
> ["level"]=>
> int(1)
> ["attributes"]=>
> array(1) {
>   ["ÜÄß"]=>
>   string(3) "Üäß"
> }
> ["value"]=>
> string(3) "ÄÖÜ"
>   }
> }
>  ACTUAL OUTPUT
> string(3) "äöü"
> array(1) {
>   ["üäß"]=>
>   string(3) "Üäß"
> }
> string(3) "äöü"
> array(1) {
>   [0]=>
>   array(5) {
> ["tag"]=>
> string(3) "äöü"
> ["type"]=>
> string(8) "complete"
> ["level"]=>
> int(1)
> ["attributes"]=>
> array(1) {
>   ["üäß"]=>
>   string(3) "Üäß"
> }
> ["value"]=>
> string(3) "ÄÖÜ"
>   }
> }
>  FAILED
> 
> -- 
> PHP Quality Assurance Mailing List <http://www.php.net/>
> To unsubscribe, visit: http://www.php.net/unsub.php
> 
> 
> 
> -- 
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, visit: http://www.php.net/unsub.php
> 


--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] 4.3.0-pre1 printf weirdness

[Mike Robinson]

";
  printf("%01.2f",-3000/100);
  echo "";
  printf("%01.2f",-3000/100);
  echo "";
  printf("%01.2f",-3000/100);
  echo "";
  printf("%01.2f",-3001/100);
  echo "";
  printf("%01.2f",-3000/100);
?>

4.2.3 output:
-29.99
-30.00
-30.00
-30.00
-30.01
-30.00

4.3.0pre1 output:
-29.99
296.14
0.00
0.00
-30.01
296.14 

If I comment out one or more of the printf()'s that use -3000/100,
but not all of them, I can get the returned output of the others
to change to all sorts of neat things (just never -30.00). At one
point one of them output 3245234172.00. This is on a stock redhat8
box.

Regards
Mike Robinson






-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] 4.3.0-pre1 printf weirdness

[Mike Robinson]

Yup, I just grabbed a checkout and its fixed.
That was a weird one.

Regards
Mike Robinson


Derick Rethans wrote:

> Hello,
> 
> I could reproduce this with pre1, but latest CVS works fine 
> again. Can 
> you try?
> 
> Derick
> 
> 
> On Thu, 17 Oct 2002, Mike Robinson wrote:
> 
> >  >   printf("%01.2f",-2999/100);
> >   echo "";
> >   printf("%01.2f",-3000/100);
> >   echo "";
> >   printf("%01.2f",-3000/100);
> >   echo "";
> >   printf("%01.2f",-3000/100);
> >   echo "";
> >   printf("%01.2f",-3001/100);
> >   echo "";
> >   printf("%01.2f",-3000/100);
> > ?>
> > 
> > 4.2.3 output:
> > -29.99
> > -30.00
> > -30.00
> > -30.00
> > -30.01
> > -30.00
> > 
> > 4.3.0pre1 output:
> > -29.99
> > 296.14
> > 0.00
> > 0.00
> > -30.01
> > 296.14
> > 
> > If I comment out one or more of the printf()'s that use 
> -3000/100, but 
> > not all of them, I can get the returned output of the 
> others to change 
> > to all sorts of neat things (just never -30.00). At one 
> point one of 
> > them output 3245234172.00. This is on a stock redhat8 box.
> > 
> > Regards
> > Mike Robinson
> > 
> > 
> > 
> > 
> > 
> > 
> > --
> > PHP Development Mailing List <http://www.php.net/>
> > To unsubscribe, visit: http://www.php.net/unsub.php
> > 
> 
> --
> 
> --
> -
>  Derick Rethans   
> http://derickrethans.nl/ 
>  JDI Media Solutions
> 
> --[ if you hold a unix shell to your ear, do you 
> hear the c? ]-
> 


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] short_open_tag

[Ford, Mike [LSS]]

> -Original Message-
> From: Yasuo Ohgaki [mailto:[EMAIL PROTECTED]]
> Sent: 17 October 2002 06:16

[snip]
 
> >>Even if we never change the default,
> >>";?> works always w/o patch.

[snip]
 
> We may even have XML processor that processes PHP code in XML
> documents in the future. i.e. PHP interpreter is invoked from
> XML processor.

... in which case your php echo statement above won't parse properly.  Since the 
definition of an XML PI block is effectively:

   " ?>

-- without any reference to the syntax of what's inside the block -- a true XML parser 
will think the , the one *inside* *the* *quotes*.

A proper XML conformant block would have to do something like:

   ";?>

Cheers!

Mike

-
Mike Ford,  Electronic Information Services Adviser,
Learning Support Services, Learning & Information Services,
JG125, James Graham Building, Leeds Metropolitan University,
Beckett Park, LEEDS,  LS6 3QS,  United Kingdom
Email: [EMAIL PROTECTED]
Tel: +44 113 283 2600 extn 4730  Fax:  +44 113 283 3211 

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] short_open_tag

[Mike Hall]

I would have no problem - as a user - with the removal of short_tags IF
 was allowed!! Because the http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] nl2br is broken in PHP4.3.0pre1

[Mike Robinson]

Derick Rethans writes:

> Hey,
> 
> this is already fixed in CVS.
> 
> thanks,
> Derick

Have you decided yet on the release cycle for 4.3? Are we any
closer to branching 4.3.0 or are we going to do 4.3.0pr2 for
further testing, or....?  :)

Regards
Mike Robinson



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] [PATCH] New function file_put()

[Mike Robinson]

Christian Schneider writes:

> On a side note: I think the file_get_contents() function should be 
> renamed to file_get() as it is useful enough to deserve a 
> shorter name.

Conversely, your new function should be named file_put_contents()
for consistency.  :)

Regards
Mike Robinson


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] short_open_tag

[Mike Robinson]

Dan Hardiker writes
> 
> Im -1 on changing the default before v5 but +1 on it being 
> done in the long run.
> 

This sounds like the best approach.

Regards
Mike Robinson


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Streams Problems

[Mike Robinson]

Im not sure if this is related, but using fopen or fsockopen
to retrieve a document that sends a redirect header (in this
case a 302 Moved Permanently trying to pull the slashdot
headlines rdf/xml file) fails. Worked fine in 4.2.3. This is
the case with 4.3.0pr1 and CVS for a little while now.

Regards
Mike Robinson


> -Original Message-
> From: Ilia A. [mailto:[EMAIL PROTECTED]] 
> Sent: Friday, October 11, 2002 10:11 PM
> To: [EMAIL PROTECTED]; Wez Furlong
> Subject: [PHP-DEV] Streams Problems
> 
> 
> There are 3 streams related problems I've come across today 
> while using CVS 
> code. First it seems that sending of binary data in excess of 
> 8k causes some 
> of the data not to be sent. This can be easily replicated 
> with the following 
> test code:
>  $test_binary_file = file_get_contents("file_name");
> $length = strlen($test_binary_file);
> 
> $fs = fsockopen("host", "port");
> $written = fwrite($fs, $test_binary_file)
> fclose($fs);
> ?>
> 
> According to fwrite() output all the data has been written, 
> since $length 
> equals to $written. However, using a network monitoring tool, 
> Ethereal I was 
> able to see that only about 8k worth of data was sent. This 
> was confirmed by 
> another script that set on the receiving end.
> 
> Another problem I've come across is about reading from 
> sockets that do no 
> terminate connection. Using the following script I've connected to a 
> webserver, in php 4.2.3 the script returns immediately after 
> the last byte 
> has been read. In CVS the script wait about 10 seconds after 
> all the data has 
> been read before finally terminating (timing out?). The 
> example script is 
> below:
>  $fp = fsockopen("host", 80);
> fwrite($fp, "GET / HTTP/1.1\r\nHost: host\r\n\r\n");
> while ( ($data = fgets($fp, 1024)) ) {
> echo $data;
> }
> flose($fp);
> ?>
> 
> The third problem is coredump that is fairly easily replicate 
> with the script 
> below:
>  $fp = fsockopen("localhost", 80);
> fputs($fp, "GET / HTTP/1.0\r\n\r\n");
> fgets($fp, 10);
> ?>
> 
> Ilia
> 
> -- 
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, visit: http://www.php.net/unsub.php
> 


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Streams Problems

[Mike Robinson]

http://www.slashdot.org/slashdot.rdf";,'r');
?>

In 4.2.3 this works as expected. It redirects to
http://slashdot.org/slashdot.rdf (note the 'www.' is gone).

In 4.3.0pr1 this results in:

Warning: fopen(http://www.slashdot.org/slashdot.rdf) [function.fopen]:
failed to create stream: HTTP request failed! HTTP/1.1 301 Moved
Permanently in /home/www/htdocs/test/fopen/slash.php on line 2

Regards
Mike Robinson


> -Original Message-
> From: Wez Furlong [mailto:[EMAIL PROTECTED]] 
> Sent: Saturday, October 12, 2002 1:40 PM
> To: Mike Robinson
> Cc: [EMAIL PROTECTED]; 'Wez Furlong'
> Subject: RE: [PHP-DEV] Streams Problems
> 
> 
> Works for me using latest CVS.
> 
> $fp = fopen("http://site.that.redirects";, "r");
>fpassthru($fp);
>var_dump(stream_get_meta_data($fp));
> ?>
> 
> The var_dump shows that PHP is following the redirects.
> There used to be a bug like that, but it's been fixed for a 
> couple of weeks now.
> 
> How about posting a script that reproduces the problem, and 
> the error output?
> 
> --Wez.
> 
> On 10/12/02, "Mike Robinson" <[EMAIL PROTECTED]> wrote:
> > Im not sure if this is related, but using fopen or fsockopen to 
> > retrieve a document that sends a redirect header (in this 
> case a 302 
> > Moved Permanently trying to pull the slashdot headlines 
> rdf/xml file) 
> > fails. Worked fine in 4.2.3. This is the case with 4.3.0pr1 and CVS 
> > for a little while now.
> 
> 
> 
> 
> -- 
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, visit: http://www.php.net/unsub.php
> 


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Re: session_register warnings

[Mike Hall]

Now I'm not really anyone special - just another user, as it were, but I do
use the session module on a daily basis as part of my job. FWIW, I agree
with Sascha on this one. A user should be able to work with a session
variable in global scope all the time, or not at all. Not some mish-mash of
both.

As it stands at the moment (with register_globals off), variables can be
pulled into a session from global scope, but they cannot be pulled out again
from global scope - you have to use the $_SESSION array. I find this counter
intuative... if I can put them into a session that way, why can't I pull
them out again that way?

Mike


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] bundled gd

[Mike Robinson]

http://downloads.rhyme.com.au/gd/

Newer GD libs with gif support have been around for
quite a while. Compiling PHP against these works fine.

Regards
Mike Robinson


> -Original Message-
> From: Tit "Black" Petric [mailto:[EMAIL PROTECTED]] 
> Sent: Thursday, October 10, 2002 8:52 PM
> To: Joye Pierre-Alain
> Cc: [EMAIL PROTECTED]
> Subject: Re: [PHP-DEV] bundled gd
> 
> 
> > imho, GIF format is dead, still used but dead ;) Providing read 
> > functions
> is
> > enough.
> > I prefer to see a mng support in futur versions 
> > (http://www.libmng.com/)
> 
> backwards compatibility is still backwards compatibility.. 
> either you support it full, or you dont support it at all.
> 
> as for having an uncompressed gif writer.. that would cause a 
> lot of people to use other alternatives, like png.
> 
> still thinking this readonly thing sucks (not that i'dd ever 
> probablly use gif writing.. i guess its just that having 
> something once for free means you're going to have it 
> forever, or atleast it should)
> 
> black
> 
> 
> -- 
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, visit: http://www.php.net/unsub.php
> 


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] bundled gd

[Mike Robinson]

> > p.s. is development on the original libgd officially stopped and/or 
> > propertiary so there is no public CVS of its latest version?
> 
> Dunno, ask the authors.

That won't do any good.
Requests for info seem to go the same route as patches
and suggestions -> /dev/null. A shame really. The upshot is,
with the crew on the PHP team doing the fork, the library is
bound to get a LOT better. :)

Regards
Mike Robinson






-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] ext/aspell

[Mike Robinson]

I like the alias option as well.
The aspell/pspell packages seem to be the exception to the
"gnu names don't change" rule. These two packages have been
a bit of a moving target in terms of both naming and
[inter]dependencies and BC has been an issue a couple of
times.

I apologize in advance, because .02 CDN isn't worth much
these days.

Mike Robinson

> -Original Message-
> From: Melvyn Sopacua [mailto:[EMAIL PROTECTED]] 
> Sent: Monday, October 07, 2002 1:50 PM
> To: Vlad Krupin
> Cc: DJ Anubis; PHP-DEV; Jan Lehnardt
> Subject: Re: [PHP-DEV] ext/aspell
> 
> 
> The config option just makes it easier to find, especially 
> when you delete 
> aspell from the tree.
> 
> You would basically try to accomplish, that:
> ./configure --help | grep aspell
> 
> yields something and possibly hint to pspell.
> 
> How that is done is insignificant. But adding 
> --with-gnu-aspell would allow 
> to move it to that name
> at some point in time, since GNU packages generally don't 
> change names :-)
> 
> my 2.20173 eurocents :)
> 
> At 10:20 10/7/2002 -0700, Vlad Krupin wrote:
> 
> >The new and improved GNU aspell happpens to be almost 100%
> >source-compatible with pspell, in fact, no changes to php source are 
> >necessary to use it. I am against creating a yet-another 
> config option. 
> >We've got a few of those already.
> >
> >I have no problem with nuking aspell and placing a dummy 
> entry in the 
> >docs
> >(akin to www.php.net/delete) telling people to use pspell, 
> because, as far 
> >as PHP is concerned, it's the same thing, if that's ok with 
> everyone else. 
> >But I don't see a good reason for an alias where you don't need one.
> >
> >just my 2 kopecks :)
> >
> >Vlad
> >
> >Melvyn Sopacua wrote:
> >
> >>Agreed, but there's one problem:
> >>
> >>The pspell as you know and love it, is now named "GNU Aspell 0.52". 
> >>The pspell extension must be used, to build with GNU Aspell 
> - the API 
> >>has been kept as an 'alias' for this purpose.
> >>
> >>So I vote for:
> >>--with-aspell -> /dev/null
> >>--with-gnu-aspell -> AC_ARG_WITH alias for --with-pspell - nothing 
> >>more.
> >>
> >>No seperate directory, nor renaming or aliasing of functions.
> >>
> >>
> >>At 13:51 10/7/2002 +0200, DJ Anubis wrote:
> >>
> >>>Le Lundi 7 Octobre 2002 13:39, Jan Lehnardt a écrit :
> >>> > Hey there hard working folks,
> >>> > aspell was replaced by pspell long ago, hence I 
> like to remove 
> >>> > aspell from the main source tree to either PECL or 
> /dev/null. Any 
> >>> > objections?
> >>> >
> >>> > Comments are highly welcome.
> >>>
> >>>Hi,
> >>>
> >>>You're right. aspell is a survival of an antiquated 
> tradition. pspell 
> >>>is
> >>>much
> >>>better. So /dev/null sounds a great place for antiques ;-)
> >>>
> >>>DJ Anubis
> >>>
> >>>
> >>>--
> >>>PHP Development Mailing List <http://www.php.net/>
> >>>To unsubscribe, visit: http://www.php.net/unsub.php
> >>
> >>
> >>Met vriendelijke groeten / With kind regards,
> >>
> >>Webmaster IDG.nl
> >>Melvyn Sopacua
> >>
> >><@Logan> I spent a minute looking at my own code by 
> accident. <@Logan> 
> >>I was thinking "What the hell is this guy doing?"
> >>
> >
> >
> >--
> >Vlad Krupin
> >Software Engineer
> >echospace.com
> >
> >
> >
> >
> >
> 
> 
> 
> 
> 
> void wakeup() {
>  for(unsigned int cuppajava;drink();cuppajava++);
> }
> 
> 
> -- 
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, visit: http://www.php.net/unsub.php
> 
> 


--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] insalling php - 4.2.3 with apache - 2.0.40 on freeBSD 4.6

[Mike Robinson]

Rasmus Lerdorf wrote:

> There are no known holes in the latest Apache 1.3.x. In fact 
> it is by far the most stable version of Apache out there. I 
> still consider Apache 2.0.x to be beta quality and in that 
> sense you are not using the latest and best software.

What's really odd about this (not trolling here) is that the
ASF reads like a who's who of the php dev team. I have to wonder
how the hell Apache2 ever went gold with such shabby support for
php (and mod_perl, mod_python, and others for that matter.)

> If you want to use Apache 2.0.x right now, please use the 
> latest unstable snapshot of PHP from snaps.php.net. But 
> again, this is not the reccomended combination of software right now.

Let the floodgates open.
Redhat-8.0 installs Apache 2.0.40 (which redhat refers to as
httpd-2.0.40)
together with php-4.2.2. A casual upgrade to RH8 is going to bite a lot
of people right on the posterior.

Regards
Mike Robinson





-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] patch to restrict database access for ext/pgsql

[Mike Robinson]

From: Jon Parise 

> Isn't it generally better (where "better" means more secure,
> efficient, and easily maintained) to handle database access
> control using PostgreSQL's native access mappings?

I would think so, and IMHO, that's where pgsql access control
belongs, with pgsql.

Regards
Mike Robinson


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Patches and Extensions and Such

[Mike Robinson]

Instead of?

Why is it that everyone else not only has to change the way they do
things but break everything done the old way?
 
How much plainer does a BC issue have to be?

One man's feature is another man's bug. You guys wanted a valid
reason, I gave one. There's probably more. :)

Did I miss the part in this thread about why this can't be
an option?

.mike




-Original Message-
From: Rick Widmer [mailto:[EMAIL PROTECTED]] 
Sent: Wednesday, September 18, 2002 5:48 PM
To: [EMAIL PROTECTED]
Subject: RE: [PHP-DEV] Patches and Extensions and Such


At 04:44 PM 9/18/02 -0400, you wrote:
>I for one have no use for line numbers in a phps file.
>I do have use for being able to copy/paste out of phps
>files, which would stop working with line numbers there.
>Some folks use phps files to distribute snippets and
>stuff.
>
>Can't this be option, default off (current behaviour)?

cp xxx.php xxx.txt

instead of

cp xxx.php xxx.phps

will provide this functionality, without all the fancy coloroing and
such. I still think if .phps is going to add all the other eye-candy it
does line numbers are a good idea.

Rick


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Patches and Extensions and Such

[Mike Robinson]

I for one have no use for line numbers in a phps file.
I do have use for being able to copy/paste out of phps
files, which would stop working with line numbers there.
Some folks use phps files to distribute snippets and
stuff.

Can't this be option, default off (current behaviour)?

Regards
Mike Robinson


-Original Message-
From: Rick Widmer [mailto:[EMAIL PROTECTED]] 
Sent: Wednesday, September 18, 2002 4:20 PM
To: Jani Taskinen; Devon O'Dell
Cc: Yasuo Ohgaki; [EMAIL PROTECTED]
Subject: Re: [PHP-DEV] Patches and Extensions and Such


At 10:12 PM 9/18/02 +0300, Jani Taskinen wrote:

> I was just thinking that .phps support is there to
> just show source of some php file. I don't think it's
> really any BC problem to always have line numbering on
> for them. And have an optional parameter to the PHP function
> to show those numbers if wanted.

I agree!  Has ANYONE given a good reason why .phps should not ALWAYS
have line numbers turned on.  ?HIGHLIGHT_FORMAT  is a hassle and likeley
to be forgotten when you need it most.  People who don't use .phps have
no business in making this decision.  You are free to disable it on your
system and 
ignore it.


 I don't understand what's the big deal about this thing anyway?
> It's nice new feature.
It sure is!

Rick


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] sockets extension

[Mike Robinson]

Dan Kalowsky writes:

> Not to continue a "flame war", but this is Open Source, and it is
> done on free time.

"Open Source" is a philosophy.
It shouldn't be an excuse.
Nothing prevents us from treating people with patience and courtesy.

Except of course bad manners and bad attitude.

> Because you the user feels you'd like to use such
> functionality it's not typically a concern for the developers.  Often
> times this functionality is added to make their own lives easier, or
> to try an experiment with something.  Take a look at the iD software
> policy: it'll be ready when it's ready.  Thats all there is to it :)

Like so.

Regards
Mike Robinson






-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] php-4.2.3 -> Thanks+Kudos

[Mike Robinson]

I would like to express my sincere appreciation to the php dev
team, the qa team, the php-doc magicians, and as always the
"countless others" for their extraordinary continuing efforts
in making php4 the best.

Awesome work from incredibly awesome people.

My humble thanks.

Regards
Mike Robinson


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP 4.2.3 release.

[Mike Hall]

Beat me to it! :-)

- Original Message - 
From: "Rasmus Lerdorf" <[EMAIL PROTECTED]>
To: "Xavier Spriet" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, September 04, 2002 6:50 PM
Subject: Re: [PHP-DEV] PHP 4.2.3 release.


> This is not a bug.  Your syntax is wrong.  It should be:
> 
> fields[tech_id][]
> 
> -Rasmus




-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PHP 4.2.3 release.

[Mike Hall]

Would the  syntax work? That should give
an identical array, if I'm seeing what you're doing right.

Mike

- Original Message -
From: <[EMAIL PROTECTED]>
To: "Xavier Spriet" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Wednesday, September 04, 2002 6:47 PM
Subject: Re: [PHP-DEV] PHP 4.2.3 release.


> Hey,
>
> did this ever work at all?
> AFAIK you can only use [] _once_ to denote it's an array.
>
> Derick
>
>





-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Problem with http://php.net

[Mike Robinson]

Cross-dressing.
Vibrators.
Oh my.

Breadsticks in the nose anyone?

.mike


-Original Message-
From: Dan Hardiker [mailto:[EMAIL PROTECTED]] 
Sent: Monday, September 02, 2002 9:22 AM
To: [EMAIL PROTECTED]
Subject: Re: [PHP-DEV] Problem with http://php.net


>> P.S.
>> Offtopic sorry
>
> funny things are allowed as off topic posts :)
>
> Derick

Such as Derick's cross dressing tendancies? heh :P [sorry, couldnt
resist]


-- 
Dan Hardiker [[EMAIL PROTECTED]]
ADAM Software & Systems Engineer
First Creative Ltd



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] segfault on adding empty heredoc to string

[Mike Robinson]

No problems with 4.2.2 as apache-1.3.26 dso on RH-7.2

Regards
Mike Robinson


-Original Message-
From: Lukas Schroeder [mailto:[EMAIL PROTECTED]] 
Sent: Sunday, September 01, 2002 1:50 PM
To: [EMAIL PROTECTED]
Subject: [PHP-DEV] segfault on adding empty heredoc to string


hi,

i can crash my php here by using these lines:



can anyone second this?


regards,
  -lukas


#0  0x403218b5 in _zval_dtor (zvalue=0xbfffe214,
__zend_filename=0x4038dc80
"/home/azzit/src/cvs/php4/php4/Zend/zend_operators.c",
__zend_lineno=1057)
at /home/azzit/src/cvs/php4/php4/Zend/zend_variables.c:43
#1  0x4031f15f in concat_function (result=0x8296a0c, op1=0x8296a0c, 
op2=0xbfffe214) at
/home/azzit/src/cvs/php4/php4/Zend/zend_operators.c:1057
#2  0x40333fc0 in execute (op_array=0x829674c)
at /home/azzit/src/cvs/php4/php4/Zend/zend_execute.c:1165
#3  0x403239e4 in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at /home/azzit/src/cvs/php4/php4/Zend/zend.c:810


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] mbstring

[Mike Robinson]

 James Cox wrote:

> I vote to remove mbstring as a default module.

+1

> Let us STOP burdening default builds with crap that is unlikely
> to be used.

Amen.

Regards
Mike Robinson


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Re: cgi and mod_php

[Mike Hall]

I'm sure PHP 4.3.0 builds the CLI as well as any other SAPI you specify,
doesn't it?

- Original Message -
From: "George Schlossnagle" <[EMAIL PROTECTED]>
To: "Daniel Lorch" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Wednesday, August 28, 2002 9:54 PM
Subject: Re: [PHP-DEV] Re: cgi and mod_php


> I think the point isn't that it's not scriptable, but that it would be
> nice if there was a 'canned' way of doing it.  I use the apache sapi and
> the cli, and it would be nice to be able to build them with a single
> make.  Clearly there are ways to build them both (easily), but it should
> be easy for a basic user to have it build multiple targets.  This is
> especially true with the cli, as there are abundant reasons to have it
> and one of the web-centric sapi's cohabitating on a system.



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] PHP 4.3 and PHP 5

[Robinson, Mike]

Title: RE: [PHP-DEV] PHP 4.3 and PHP 5






Wez Furlong wrote:


> o Bundle Brads php-soap extension, and "market" PHP 5 as 
> being "Web Service Enabled".


This will stop the "bleeding of the PHP users"
Manuel Lemos will be pleased.


:P



Mike Robinson
IT/Developer - Torstar Media Group Television
Phone: 416.945.8786 Fax: 416.869.4566
Email: [EMAIL PROTECTED]




To find out more about what we can do for you, please visit us at:
http://www.tmgtv.ca/ and http://www.thestar.com/



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Re: [PHP-QA] Congratulations.

[Robinson, Mike]

Title: RE: [PHP-DEV] Re: [PHP-QA] Congratulations.





Congratulations Derick.
Most deserving recognition for a terrific job.
I will add to that my humble thanks.


Mike Robinson
IT/Developer - Torstar Media Group Television
Phone: 416.945.8786 Fax: 416.869.4566
Email: [EMAIL PROTECTED]




To find out more about what we can do for you, please visit us at:
http://www.tmgtv.ca/ and http://www.thestar.com/



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] php-bugs subject lines

[Ford, Mike [LSS]]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: 25 July 2002 09:15
> To: Marko Karppinen
> 
> I like this idea, but I would propose to let the line always 
> begin with 
> "Bug #bugnr" (for sorting and stuff).

Is there any need to bother with "Bug" when it's on the php-bugs list?
Couldn't subject lines just start with the bug number, so:

  "#12345 Bogused: etc etc..."

Cheers!

Mike

-----
Mike Ford,  Electronic Information Services Adviser,
Learning Support Services, Learning & Information Services,
JG125, James Graham Building, Leeds Metropolitan University,
Beckett Park, LEEDS,  LS6 3QS,  United Kingdom
Email: [EMAIL PROTECTED]
Tel: +44 113 283 2600 extn 4730  Fax:  +44 113 283 3211 

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] bug 16037 help? zend/thread-safety problem

[Mike Hardy]

I've been investigating the source around this bug:

http://bugs.php.net/bug.php?id=16037

...and can't quite wrap my head around how to fix it.

The implication of the bug is that for Apache 2.x platforms using
threading (or Apache 1.3.x on windows, which uses threading), you'll
probably get random parse errors if two threads compile the same script at
once.

The problem seems to be the non-thread-safe use of some variable that's 
used when interpolating variables in strings, but I'm much better at Java 
threading then the Zend TS...() macros so I can't figure out where it is.

By rooting around cvs.php.net, I was able to see that Zeev was in 
zend_language_parser most recently putting in some thread-safety changes, 
but there is definitely still a problem.

Does anyone have interest in working with me to fix this bug? I'm highly 
motivated to fix it, but I need help.

I see a few options if someone has the time:

1) I could test a new build (I can reproduce the bug at will)
2) I could compile and test a new build (haven't built win32 before, but
   I have VC6, so I can give it a shot)
3) I can patch it if someone could help me with the control-flow and
   threading macros

Or, perhaps there is simply a better way?

Any and all help is appreciated -

-Mike


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Release plans for 4.2.2 / 4.3

[Robinson, Mike]

Title: Release plans for 4.2.2 /  4.3





Are there any tentative release plans for 4.2.2 or 4.3?


Mike Robinson
IT/Developer - Torstar Media Group Television
Phone: 416.945.8786 Fax: 416.869.4566
Email: [EMAIL PROTECTED]




To find out more about what we can do for you, please visit us at:
http://www.tmgtv.ca/ and http://www.thestar.com/



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

RE: [PHP-DEV] Re: cvs: php4 /ext/mbstring config.m4

[Robinson, Mike]

Title: RE: [PHP-DEV] Re: cvs: php4 /ext/mbstring config.m4 






Edin Kadribasic writes:


> Sent: Monday, July 15, 2002 12:05 PM
> To: [EMAIL PROTECTED]; Jani Taskinen; Yasuo Ohgaki
> Subject: Re: [PHP-DEV] Re: cvs: php4 /ext/mbstring config.m4 
> 
> 
> > I asked to php-dev and nobody objects enabling mbstirng by
> > default. This allow some modules (extif, mailparse(?), for example)
> > to use multibyte feature.
> 
> No objections here.


Frankly, I don't think mbstring should be enabled by default.


If a user wants mbstring support, is it too much to ask to
have them add --enable-mbstring to their config line? Once
we go down this road, turning it off by default is a huge wtf.


IMHO that is.


Regards


Mike Robinson
IT/Developer - Torstar Media Group Television
Phone: 416.945.8786 Fax: 416.869.4566
Email: [EMAIL PROTECTED]




To find out more about what we can do for you, please visit us at:
http://www.tmgtv.ca/ and http://www.thestar.com/



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] serial port communication

[Mike Hall]

As far as I know, nobody has looked at this before. So you'd be starting
from scratch.

- Original Message -
From: "Zac Hillier" <[EMAIL PROTECTED]>
To: "Mike Hall" <[EMAIL PROTECTED]>
Sent: Tuesday, July 02, 2002 9:40 AM
Subject: Re: [PHP-DEV] serial port communication


> Thanks for the reply, any idea where I could find more information?
>
> Zac
>
> - Original Message -
> From: "Mike Hall" <[EMAIL PROTECTED]>
> To: "Zac Hillier" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
> Sent: Tuesday, July 02, 2002 9:42 AM
> Subject: Re: [PHP-DEV] serial port communication
>
>
> > It's something I need to look into for a project I'm putting together at
> > work. I just haven't got the time at the moment to do it, sadly
> >



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] serial port communication

[Mike Hall]

It's something I need to look into for a project I'm putting together at
work. I just haven't got the time at the moment to do it, sadly

-- Mike

--
"Zac Hillier" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> On the 20th May Mike Hall posted a message about communication with serial
> ports.
>
> I'm trying to research using php with a multi port serial card, can anyone
> tell me if this progressed, else is there anywhere I can look for further
> information?



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Switching zlib.output_compression, bug #16109

[Mike Hall]

Well write your own callback function for ob_start then! ;-)

> Perhaps. :)  But it seems you're missing the point.  Read here:
> 
> http://www.php.net/manual/en/function.session-start.php
> 
> Specifically, the second note:
> 
> Note: Use of zlib.output_compression is recommended rather than
> ob_gzhandler
> 
> zlib.output_compression != ob_start('ob_gzhandler')
> 
> 
> Which brings us back to the original point.  How does one go about
> enabling/disabling zlib.output_compression from within a script?
> ini_set('zlib...', 'On|Off') does not work.
> 





-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Switching zlib.output_compression, bug #16109

[Mike Hall]

ob_start('ob_gzhandler');

Shouldn't this be on php-general by now? ;-)

> let me get this straight.. you can turn off output_buffering = on inside
> php?
>
> then whats the problem with zlib, just make it output_buffer, and AFTER
that
> check the ini value, weather to compress that data or not.. so it could be
> turned off runtime, or am i wrong?



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Switching zlib.output_compression, bug #16109

[Mike Hall]

I never set it in the ini, only set it at runtime.

- Original Message - 
From: "Jaime Bozza" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: "'Mike Hall'" <[EMAIL PROTECTED]>
Sent: Monday, June 24, 2002 4:31 PM
Subject: RE: [PHP-DEV] Switching zlib.output_compression, bug #16109


> Ok, so...  Say you have php.ini that defaults zlib.output_compression to
> On?  How would you go about setting it to off inside the script that
> sends out an image?
> 
> Jaime Bozza




-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Switching zlib.output_compression, bug #16109

[Mike Hall]

I simply don't use output compression for images

- Original Message -
From: "Jaime Bozza" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: "'Stefan Roehrich'" <[EMAIL PROTECTED]>; "'Mike Hall'"
<[EMAIL PROTECTED]>
Sent: Monday, June 24, 2002 4:11 PM
Subject: RE: [PHP-DEV] Switching zlib.output_compression, bug #16109


While this is, in fact, a Netscape-specific bug, it's a pain in that
there is no current easy workaround to disable zlib.output_compression
from the script.  Right now (tested with 4.1.2, so I can't say how it
works in 4.2.x or above) if I have:

ini_set('zlib.output_compression', 'Off');

in my script, it's ignored and still sends out the compressed data.  If
you don't like the browser detection on images, at least allow the
ability to be able to turn off zlib.output_compression from the script.


Jaime Bozza




-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Switching zlib.output_compression, bug #16109

[Mike Hall]

I would venture that this is a bug in Netscape, not a bug in PHP and
therefore not PHP's responsibility to fix.
Netscape is reporting to PHP that it accepts zipped content, when it clearly
doesn't accept zipped images.

Mike

- Original Message -
From: "Stefan Roehrich" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, June 24, 2002 3:23 PM
Subject: [PHP-DEV] Switching zlib.output_compression, bug #16109


> Hello!
>
> There has been a bug report (#16109) about a bug in Netscape 4.79,
> which doesn't display images if Content-Encoding: gzip is used. After
> thinking about a browser detection config flag for zlib.output
> compression, at LinuxTag we discussed, that a more general solution
> would be better, that means switching off output compression for
> images and let it be possible to switch it off (or force it on) during
> script execution.
>
> So I implemented it this way:
>
> The headers for output compression are sent late, not in the zlib
> request init, but in the SAPI send_headers call, I think this is the
> latest possible time I can add it, so that it's possible to switch it
> off before that time. If you send a header("Content-Type: image/xxx")
> output compression is switched off, you can also switch it off via
> ini_set('zlib.output_compression', 'Off') (or force it on, if you use
> this call with 'On' after the image header was sent, but this only
> works, if it was globally enabled, you can't switch it on during
> script execution if the default says 'Off' (you need the output
> buffering, you also can't change the buffer size)).
>
> If output compression was disabled during the script, the compression
> handler simply does noething and no headers are added (so you can
> switch the setting only before the headers are sent).
>
> Because I'm no SAPI expert and I don't know, if there are some other
> effects, if I add the header in the send_headers call, I haven't
> commited it yet, see the attached patch. If nobody objects, I'll
> commit it in a few days.
>
>   Stefan
>
> --
> Stefan Röhrich   [EMAIL PROTECTED], [EMAIL PROTECTED]
>  http://www.roehri.ch/~sr/






> --
> PHP Development Mailing List <http://www.php.net/>
> To unsubscribe, visit: http://www.php.net/unsub.php


-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Seeking Comments - Regarding header()

[Mike Hall]

> Chris Shiflett wrote:
>
> > I have a few sites where I deliberately violate the HTTP spec in this
> > way to get around a bug in IE (I know, shame on me). I've been using
> > relative URLs in a "Location" header for years with no crashes that I
> > know of.
> >
> > There must be something unique in your configuration. Have you mentioned
> > this to the Apache guys?
> >
>
> I've seen this before too, but only on Windows.  I've never noticed the
> problem on Linux, Solaris, or BSD.

I had it on FreeBSD. It was particularly bad under SSL, but happened without
too.



-- 
PHP Development Mailing List 
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Seeking Comments - Regarding header()

[Mike Hall]

> On Fri, Jun 21, 2002 at 10:48:33AM +0100, Mike Hall wrote :
> > You could hardly describe it as a bug if Apache crashes because you're
> > sending Headers that violate the spec, surely?
>
> Hmm  ... I'm not sure. I don't think apache should crash. but
> then how can you be sure it's apache who crashes and not php?
> If it's an apache crash it maybe can be missused too (though
> not remotely).

Well, if you send relative URLs in a Location: header, it causes
intermittent sig11's in Apache. Don't know if that is mod_php causing them,
or apache. But it does happen. I had that problem on GG.COM .. took me weeks
to track it down to relative location headers.

--Mike



-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php