Re: [PHP-DEV] Language Auto Detection / www.php.net

[James Cox]

Gabor Hojtsy <[EMAIL PROTECTED]> wrote:

> > is there any chance that we can revert this annoying feature?
> > The translated documentation is always behind and partly lacks
> > important information from the english version. I want to read
> > the documentation in english (and I am not the only one). This
> > is only possible if I change the url after all searches to /en/
> > The site should at least be so intelligent to search in the 
> > /en/ part of the manual if I search from an /en/ page.
> 
> This is fixed now, and works again the way it was before the
> weekend (if you explicitly specify a language with being on a
> manual page in a language, or using the search page with a language
> parameter, that language is carried on).
> 
> We do have language specification abilities in URL shortcuts, which
> is the short term solution, while I (or someone else) add the
> language cookie support. See http://php.net/urlhowto

I remember adding a cookie before for something trivial (user-configurable
css) and jimw pointing out that it tends to do silly things with caching...
(ie, renders it useless)

 James

___
This mail sent using V-webmail - http://www.v-webmail.co.uk


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

[PHP-DEV] upcoming plans for servers

[James Cox]

All,

I am about to start a process of upgrading/moving all of the services
php.net offers. This is to take advantage of new servers, and to distribute
our load so that servers are not doing "everything" but instead optimized
and configured to be perfect for a particular service.

full details (or, more full details) are available here:
http://master.php.net/sysmatrix.php

The first step is to split cvs.php.net from pair1.php.net onto its own
server. This will result in some cvs _WRITE_ downtime, as dns updates.
However, cvs checkouts will be unaffected, and the changeover should not be
noticed.

If anyone has any further questions, please feel free to email me,
[EMAIL PROTECTED] or simply reply to this email.

Thanks,

 James

--
James Cox :: [EMAIL PROTECTED] :: http://imajes.info/
Was I helpful?  http://www.amazon.co.uk/exec/obidos/wishlist/23IVGHQ61RJGO/



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

RE: [PHP-DEV] can't get wincvs to ask for login

[James Cox]

> Hi,
>
> I'm trying to commit some changes, and can't get wincvs to log me
> in or even
> to request a password with pserver.  I've changed the username
> from cvsread
> to cellog.  Anyone with wincvs experience know how to make the
> stupid thing
> work?
>

Your best bet is to use the CVS win32 port, located at
http://ftp.cvshome.org/win32/cvs-1-11-5.zip


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

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

[James Cox]

> -Original Message-
> From: Dan Kalowsky [mailto:[EMAIL PROTECTED]]
>
> I've heard the arguments for the list, and I can only say they are
> valid reasons.  But you're now making PHP a political project rather
> than a software project.  Thanks.  This is the sort of thing I don't
> want to have to deal with in my personal time.  If you want a private
> list, take PHP out of the Open Source.  If you want to cut down on the
> signal/noise ratio then moderate the list, but don't make it private
> and invite only.

+1. As much as this list is a good thing for advancing development in a sane
way, it creates too many political debates. It causes elitism. In a project
like the ASF, where elitism is almost acceptable, this list would be fine,
however for the PHP project where the emphasis is on community, and allowing
people to get involved, this kind of list just adds bad feelings.

I do not have time or expertise to make PHP5 a reality in the way that Zeev,
Rasmus, Derick or any of the other people on the list do -- i readily admit
that; but I most certainly am interested in the ways that you are taking
PHP5, and if something detrimental was to crop up, (eg, disabling
register_globals entirely, which has been mentioned more than once for PHP5)
, then I would like to be able to add reasoned argument against.

Open up the list so that people can read it, and moderate posts, as you are
continuing too, Andrei.

 -- james


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

RE: [PHP-DEV] PHP4 + PHP5

[James Cox]

> On Tue, 14 Jan 2003, James Cox wrote:
>
> > > On Mon, 13 Jan 2003 20:46:45 -0500
> > > "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.
> > >
> > > I hope so. libphp5 will be the module names, afaik. That will avoid
> > > conflict names. is it ?
> > >
> > i am already cooking up a patch for this.. almost done. just
> waiting on when
> > we split off php5 to commit it.
>
> A patch for naming it libphp5 or a patch that enables them to work
> together in the same webserver? The latter is quite hard and 'cookie a
> patch' for that will almost certainly not work.
>
the patch for naming everything php5 and not php4 is done, i am just
finishing the patch to enable versioning properly.

 -- james


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

RE: [PHP-DEV] RE: [PEAR-DEV] 'php4' CVS module for PHP 5?

[James Cox]

> On Mon, 13 Jan 2003, James Cox wrote:
> > >
> > it's called compatibility Nicos. having libphp4.so, libphp5.so,
> > libphp6.so... and so on means that they can work together. Once
> libphp5.so
> > gets building properly and we have moved onto that track completely, i
> > intend to build a latest stable of php4 and leave it there:
> libphp4.so. make
> > .php, .php4 etc use that hook, so my existing apps don't get broken, and
> > migrate to .php5
>
> There wouldn't be any need to have them both enabled, so why even go
> here?

I think we have already discussed how there is a need to have both enabled.

>
> --
>
> -
>  Derick Rethans http://derickrethans.nl/
>  PHP Magazine - PHP Magazine for Professionals   http://php-mag.net/
> -
>
>
> --
> 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] PHP4 + PHP5

[James Cox]

> On Mon, 13 Jan 2003 20:46:45 -0500
> "Mike Robinson" <[EMAIL PROTECTED]> wrote:
>
> > 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.
>
> I hope so. libphp5 will be the module names, afaik. That will avoid
> conflict names. is it ?
>
i am already cooking up a patch for this.. almost done. just waiting on when
we split off php5 to commit it.

 -- james


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

[PHP-DEV] RE: [PEAR-DEV] 'php4' CVS module for PHP 5?

[James Cox]

> Hello,
>
> What do you think about the idea of Martin that would use
> libphp.so
> and not libphp5.so ?
>
it's called compatibility Nicos. having libphp4.so, libphp5.so,
libphp6.so... and so on means that they can work together. Once libphp5.so
gets building properly and we have moved onto that track completely, i
intend to build a latest stable of php4 and leave it there: libphp4.so. make
.php, .php4 etc use that hook, so my existing apps don't get broken, and
migrate to .php5

 -- james


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

[PHP-DEV] RE: cvs checkout skip dir

[James Cox]

heh :0

we could also just do a system("file $_"); or whatever to work out what kind
of file we're adding... and if it's a binary type file, then just don't
diff. for large diffs, like date changes or doc changes, then publishing the
diffs at a site like cvs.php.net/diffs/ or similar would also be trivial, i
think.

 -- james

> -Original Message-
> From: Gabor Hojtsy [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, January 12, 2003 5:16 PM
> To: James Cox; [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Cc: Php-Dev
> Subject: Re: cvs checkout skip dir
>
>
> > hmm. that is an interesting idea... hacking the dolog.pl script
> to publish
> > the diffs for large attachements instead of including them inline might
> not
> > be a bad thing (tm).
>
> Now, **no** cvs mails are sent regarding the distributions dir. It is
> skipped
> because the files are big. But diffs cannot be made for images
> and I guess,
> the mailer won't try to create diffs for bz2s exes and the like, so it may
> be
> easy to turn those mails on again... But please don't test it by adding a
> large
> bz2 file ;))
>
> Goba
>
>


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

[PHP-DEV] RE: cvs checkout skip dir

[James Cox]

hmm. that is an interesting idea... hacking the dolog.pl script to publish
the diffs for large attachements instead of including them inline might not
be a bad thing (tm).

 -- james

> -Original Message-
> From: Gabor Hojtsy [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, January 12, 2003 5:02 PM
> To: James Cox; [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Cc: Php-Dev
> Subject: Re: cvs checkout skip dir
>
>
> > I am actually pondering about removing distrobutions from phpweb, and
> moving
> > it to it's own cvs module, with slightly more heavier control over it.
> This
> > is to be a bit more secure over releases, and also it is usually not
> needed
> > during a checkout of phpweb. (if you're going to checkout phpweb, you're
> > usually just working on the site, not actually keeping a local
> copy, rsync
> > is fine for that).
> >
> > if no-one objects i'm going to go ahead and do this next week.
>
> Please do! And please turn on cvs mails again (without diifs) for changes
> in distributions. It would be quite nice to see when it changes. We don't
> receive any notice about it right now...
>
> Goba
>
>


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

[PHP-DEV] RE: cvs checkout skip dir

[James Cox]

I am actually pondering about removing distrobutions from phpweb, and moving
it to it's own cvs module, with slightly more heavier control over it. This
is to be a bit more secure over releases, and also it is usually not needed
during a checkout of phpweb. (if you're going to checkout phpweb, you're
usually just working on the site, not actually keeping a local copy, rsync
is fine for that).

if no-one objects i'm going to go ahead and do this next week.

 -- james

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, January 11, 2003 1:45 PM
> To: [EMAIL PROTECTED]
> Subject: Re: cvs checkout skip dir
>
>
> I don't think its possible... or we should create a tag that does that...
>
> --
> Regards.
> M.CHAILLAN Nicolas
> [EMAIL PROTECTED]
> www.WorldAKT.com Hébergement de sites internets.
>
> "Gabor Hojtsy" <[EMAIL PROTECTED]> a écrit dans le message de news:
> 013f01c2b970$e5f72410$[EMAIL PROTECTED]
> > Hi!
> >
> > Can someone please help me with a hint on what command line
> > argument should I pass to CVS to skip one more more folders
> > while doing a checkout? I would be rather happy to check out
> > phpweb without distributions ;))
> >
> > Thanks,
> > Goba
> >
>
>
>


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

Re: [PHP-DEV] ChangeLog

[James Cox]

On Wed, 2003-01-01 at 08:21, Wez Furlong wrote:
> Is there some magic that needs to be done to rotate the ChangeLog?
> By this I mean:
> 
> gzip ChangeLog
> mv ChangeLog.gz ChangeLog2002.gz
> touch ChangeLog
> cvs add -kb ChangeLog2002.gz
> cvs ci -m "rotate changelog" ChangeLog ChangeLog2002.gz
> 
> It seems the most recent entry in the log is from the 29th December, and
> I wonder if some script needs to be kicked to update the log.

you might need to wait a bit for the last couple of days to enter the
changelog, but that seems the right way to do it. 

 -- james


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

Re: [PHP-DEV] CVS mangled (netware/apachecore.imp,netware/bisonflexzend.bat)

[James Cox]

On Wed, 2003-01-01 at 08:17, Wez Furlong wrote:
> % cvs -q up
> cvs server: nothing known about netware/apachecore.imp
> cvs server: nothing known about netware/bisonflexzend.bat
> 
> I can't find any trace of these files in my checkout (or in the CVS
> files), so I presume that something has been munched on the server
> side?

I will investigate, but i believe these files were not really added,
just sort of semi-added, as they are netware confidential.. but i do
need to check on that.

 -- james


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

[PHP-DEV] Re: [PHP-CVS] Not able to check-in files - Need help!

[James Cox]

Ananth, 

I just checked the cvs server and also did a test commit -- it looks
fine, worked for me.

I suggest trying again, and if you have the same problem, try sending me
the log message directly (although, i suspect it's an exact copy of what
you pasted already).

 Thanks,

James

On Fri, 2002-12-20 at 06:31, Ananth Kesari wrote:
> Hi,
> 
> I am checking in some additional files and some modifications related
> to NetWare. I could do so for a couple of files. Now I changed quite a
> few files (about 10) in the NetWare directory and I am doing a cvs
> commit for the netware directory. This checked in about 2 files and now
> it is giving the following error:
> 
> D:\cvs-4.3\php4\netware>cvs commit
> cvs commit: Examining .
> cvs commit: Examining sys
> ? sysexits.h
> assertion "key != NULL" failed: file
> "/usr/src/gnu/usr.bin/cvs/cvs/../../../../c
> ontrib/cvs/src/hash.c", line 312
> cvs [server aborted]: received abort signal
> cvs commit: saving log message in
> C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\18
> 
> I am not able to check-in now. Can someone help?
> 
> Thanks,
> Ananth.
> 


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

[PHP-DEV] test, please disregard.

[James Cox]

--
James Cox :: [EMAIL PROTECTED] :: http://james.blogs.at/
Was I helpful?  http://www.amazon.co.uk/exec/obidos/wishlist/23IVGHQ61RJGO/

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

RE: [PHP-DEV] Problem with commit

[James Cox]

um.. ok..

i'm looking into a few issues with cvs right now...  could you send me the
full content of any header etc you might have received, anything that
suggests what triggered that error...

 -- james

> -Original Message-
> From: Marcus Borger [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, December 05, 2002 9:49 PM
> To: [EMAIL PROTECTED]
> Subject: [PHP-DEV] Problem with commit
>
>
> There seems to be a problem with CVS server:
>
> cvs -z3 -q commit -m "php_error -> php_error_docref" xml.c
> Checking in xml.c;
> /repository/php4/ext/xml/xml.c,v  <--  xml.c
> new revision: 1.112; previous revision: 1.111
> done
> Bad response from SMTP -- 553 (2002/12/04) Open Proxy: http(3128)
>
> Mailing the commit email to [EMAIL PROTECTED]
>


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

RE: [PHP-DEV] LXR on pear/PECL

[James Cox]

Sure,

once LXR moves to a new machine i'll make that work.

 Thanks,

 James

> -Original Message-
> From: Joao Prado Maia [mailto:[EMAIL PROTECTED]]
> Sent: Sunday, December 01, 2002 11:42 PM
> To: [EMAIL PROTECTED]
> Subject: [PHP-DEV] LXR on pear/PECL
> 
> 
> Hi,
> 
> I'm not sure who is "in charge" of LXR, but would it be possible to make
> this tool also parse the extensions available in pear/PECL ? I'm a
> struggling newbie in writing PHP extensions and this ability would help a
> lot.
> 
> Cheers,
> Joao
> 
> 
> -- 
> 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] New vpopmail extension for PHP

[James Cox]

it's not orphaned, i'm nursing it back to life :)

 -- james

> -Original Message-
> From: Markus Fischer [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, November 28, 2002 8:53 PM
> To: Rui Barreiros
> Cc: [EMAIL PROTECTED]
> Subject: Re: [PHP-DEV] New vpopmail extension for PHP
> 
> 
> vpopmail is not part of the core anymore, it has been moved
> to PECL (see pear.php.net.)
> 
> However, I suggest contacting the current (former?) owner(s) of
> the extension, afaik it's not orphaned yet.
> 
> On Thu, Nov 28, 2002 at 07:27:05PM +, Rui Barreiros wrote : 
> > Hi there,
> > 
> > I made a new vpopmail extension for php based on current vpopmail
> > extension, vpopmail and qmailadmin, below is a complete list for all
> > functions available from the extension.
> > 
> > I would like to know if there is any interest on making it available on
> > the standard php dist, if so, i'd need some directions on what to do
> > next.
> > 
> > my best wishes to all,
> > 
> > Rui Barreiros
> > 
> > vpopmail function list:
> > The commented functions are being developed, expecting to finish them
> > this weekend.
> > 
> > PHP_FE(vpopmail_add_domain, NULL)
> > PHP_FE(vpopmail_del_domain, NULL)
> > PHP_FE(vpopmail_add_aliasdomain, NULL)
> > PHP_FE(vpopmail_getdomains, NULL)
> > PHP_FE(vpopmail_getdomaindir, NULL)
> > PHP_FE(vpopmail_getdomainuid, NULL)
> > PHP_FE(vpopmail_getdomaingid, NULL)
> > PHP_FE(vpopmail_getdomainusers, NULL)
> > PHP_FE(vpopmail_is_aliasdomain, NULL)   
> > 
> > // User Functions
> > PHP_FE(vpopmail_add_user, NULL)
> > PHP_FE(vpopmail_del_user, NULL)
> > PHP_FE(vpopmail_add_alias, NULL)
> > PHP_FE(vpopmail_del_alias, NULL)
> > PHP_FE(vpopmail_get_alias, NULL)
> > PHP_FE(vpopmail_del_aliasline, NULL)
> > 
> > PHP_FE(vpopmail_add_forward, NULL)
> > PHP_FE(vpopmail_del_forward, NULL)
> > PHP_FE(vpopmail_get_forwards, NULL)
> > PHP_FE(vpopmail_del_forwardline, NULL)
> > 
> > PHP_FE(vpopmail_chkpwd, NULL)
> > PHP_FE(vpopmail_passwd, NULL)
> > PHP_FE(vpopmail_setuserquota, NULL)
> > PHP_FE(vpopmail_clearuserflags, NULL)
> > PHP_FE(vpopmail_setuserflags, NULL)
> > PHP_FE(vpopmail_userflagchk, NULL)
> > 
> > // Info retrieval Functions
> > 
> > PHP_FE(vpopmail_getuserquota, NULL)
> > PHP_FE(vpopmail_getuserquotausage, NULL)
> > PHP_FE(vpopmail_getuserdir, NULL)
> > PHP_FE(vpopmail_getuserlastauth, NULL)
> > PHP_FE(vpopmail_getuserlastauthip, NULL)
> > PHP_FE(vpopmail_getuserflags, NULL)
> > 
> > // Forward and vacation functions
> > 
> > //PHP_FE(vpopmail_enableforward, NULL)
> > //PHP_FE(vpopmail_disableforward, NULL)
> > //PHP_FE(vpopmail_add_vacation, NULL)
> > //PHP_FE(vpopmail_del_vacation, NULL)
> > //PHP_FE(vpopmail_get_vacations, NULL)
> > 
> > // Auto functions
> > //PHP_FE(vpopmail_add_mailrobot, NULL)  
> > //PHP_FE(vpopmail_del_mailrobot, NULL)  
> > //PHP_FE(vpopmail_get_mailrobot, NULL)  
> > 
> > // Global settings Functions
> > 
> > PHP_FE(vpopmail_setcatchall, NULL)
> > PHP_FE(vpopmail_getcatchall, NULL)
> > 
> > // Utility Functions
> > PHP_FE(vpopmail_verror, NULL)
> > 
> > 
> > 
> > 
> > 
> > -- 
> > 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
> 
> 

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

RE: [PHP-DEV] ZE2 question

[James Cox]

it means double colon in hebrew... i think Zeev and Andi must not have known
what to call it in english when they put it in... but hey, it was the first
i18n'ized error message :)

 -- jamess

> -Original Message-
> From: Marcus Borger [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, November 28, 2002 4:28 PM
> To: [EMAIL PROTECTED]
> Subject: [PHP-DEV] ZE2 question
>
>
> This is may be a nice token name, but i do not understand it.
>
> When trying to execute: $c->parent::function()
> I receive: Parse error: parse error, unexpected T_PAAMAYIM_NEKUDOTAYIM in
> /usr/src/ph
>
> Not that anywhere it is said this should work but i did
> an error and found the error message not helpfull.
>
> marcus
>
>
>
> --
> 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] error handling

[James Cox]

>Also, from a management point of view (I manage programmers),
>what you are describing there can work in some cases but what
>if a programmer forgets/is-too-lazy to to that? I don't want
>to wait for the next morning to know about it.
>
if a programmer is too lazy to test, fire them. there are plenty more better
ones to hire.

 -- james


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

RE: [PHP-DEV] error handling

[James Cox]

>
> 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.

+1... don't commit code without QA!
>
> 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.

i see your point, but php doesn't really provide a way of halting on all
errors, unless you code yourself a funky error handler and well... it gets
messy. throwing http 500 is the right way to do it (tm), and i think would
be better http conformance if we did.

 -- james


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

RE: [PHP-DEV] error handling

[James Cox]

The point is that it should be possible to throw a HTTP 500 error. This is
really only useful in production environments, ie, when the code going live
should already be free of things like parse errors. Throwing a 500 error
would make it easier to merge into your already existing error handling
systems -- eg, for 404.

 -- james

> -Original Message-
> From: Maxim Maletsky [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, November 21, 2002 12:15 PM
> To: James Cox
> Cc: [EMAIL PROTECTED]; 'PHP Developers Mailing List'
> Subject: Re: [PHP-DEV] error handling
>
>
>
> Writing for newbies, I often heard them mentioning one things
> they liked about
> PHP (before even trying to use it) - "PHP errors are not 500 weird pages
> made by your browser".
>
> Moving fatal errors to HTTP 500 can be somewhat confusing, unless we
> have a solid way handling ALL errors in some very logical way. In other
> words - powerful but clear enough to understand and use for neo
> programmers.
>
> +1 to what someone mentioned earlier - PHP is not *only* for web, it is
> *primarily* for web. Maybe, using HTTP headers for error handling would
> make this less obvious.
>
> just my +.2c
>
> --
> Maxim Maletsky
> [EMAIL PROTECTED]
>
>
>
> "James Cox" <[EMAIL PROTECTED]> wrote... :
>
> > it can; 500 means server error -- perl, cgi, mod_include, etc
> all do it, so
> > why shouldn't php?
> >
> >  -- james
> >
> > > -Original Message-
> > > From: John Coggeshall [mailto:[EMAIL PROTECTED]]
> > > Sent: Wednesday, November 20, 2002 11:06 PM
> > > To: 'James Cox'
> > > Cc: 'PHP Developers Mailing List'
> > > Subject: RE: [PHP-DEV] error handling
> > >
> > >
> > >
> > > >true...
> > > >
> > > >i'd like to see a 500 error though, and some persistent vars...
> > >
> > > See, the problem that I'm seeing here is that I don't believe PHP is
> > > reponsible for setting the error code returned by PHP.. For
> instance, a
> > > 404 error isn't handle by PHP at all. Likewise, I don't think PHP can
> > > say "turn this into a 500 error" to Apache.
> > >
> > > John
> > >
> > >
> > > >
> > > > -- james
> > > >
> > > >> -Original Message-
> > > >> From: John Coggeshall [mailto:[EMAIL PROTECTED]]
> > > >> Sent: Wednesday, November 20, 2002 10:48 PM
> > > >> To: 'James Cox'
> > > >> Subject: RE: [PHP-DEV] error handling
> > > >>
> > > >>
> > > >> >that can't really be done because parsing has happened, and so
> > > >> >output has started -- but if we return status 500, the
> > > >> >webserver can manage it properly..
> > > >>
> > > >> Only if output buffering is off. Custom error handling should have
> > > >> output buffering on anyway as I've already said... John
> > > >>
> > > >>
> > > >
> > >
> > >
> >
> >
> > --
> > 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] [PATCH] Redirect on Error

[James Cox]

did you forget to return http 500 in the sapis?

 -- james

> -Original Message-
> From: John Coggeshall [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, November 21, 2002 11:56 AM
> To: 'PHP Developers Mailing List'
> Subject: [PHP-DEV] [PATCH] Redirect on Error
> 
> 
> 
> Okay...
> 
> Well, even though I've yet to convince Derick and a few others... I did
> see enough interest in this to create a patch. This creates two new
> directives: error_redirect (bool) which turns this on/off, and
> error_redirect_url (string) which is the URL to redirect to upon error.
> In order for these directives to have any effect, the headers (of
> course) must not have been already sent. This means that either output
> buffering must be enabled, or the script never got around to outputting
> anything. This patch will allow users to handle every error PHP
> generates if desired (including E_PARSE, etc).
> 
> The URL which is redirected to is passed the following parameters via a
> GET statement:
> 
> errno - The error number (i.e. E_PARSE, whatever)
> Errfile - The path/file of the effected file
> Errline - The line which the error occurred
> Errmsg - The message provided describing the error:
> 
> If the redirection fails (i.e. because headers had already been sent,
> whatever) the standard PHP error routine is used. 
> 
> Disclaimer: This is totally meant to be RFC at this point. It works, but
> Its not very friendly right now with the other error stuff (i.e.
> error_prepend, etc). If I can get a +1 on this concept, I'll clean
> things up before I commit.
> 
> John
> 
> --- php4/main/main.org.cThu Nov 21 05:43:05 2002
> +++ php4/main/main.cThu Nov 21 05:43:18 2002
> @@ -236,6 +236,8 @@
> STD_PHP_INI_ENTRY("docref_root", "http://www.php.net/";,
> PHP_INI_ALL,   OnUpdateString,  docref_root,
> php_core_globals,   core_globals)
> STD_PHP_INI_ENTRY("docref_ext", "",
> PHP_INI_ALL, OnUpdateString, docref_ext,
> php_core_globals,core_globals)
> STD_PHP_INI_BOOLEAN("html_errors",  "1",
> PHP_INI_ALL, OnUpdateBool,   html_errors,
> php_core_globals,core_globals)
> +   STD_PHP_INI_BOOLEAN("error_redirect",   "0",
> PHP_INI_SYSTEM, OnUpdateBool,   error_redirect,
> php_core_globals,   core_globals)
> 
> +STD_PHP_INI_ENTRY("error_redirect_url", NULL,
> PHP_INI_SYSTEM, OnUpdateString,
> error_redirect_url, php_core_globals,core_globals)
> STD_PHP_INI_BOOLEAN("xmlrpc_errors","0",
> PHP_INI_SYSTEM, OnUpdateBool,   xmlrpc_errors,
> php_core_globals,core_globals)
> STD_PHP_INI_ENTRY("xmlrpc_error_number","0",
> PHP_INI_ALL,OnUpdateInt,
> xmlrpc_error_number,php_core_globals,   core_globals)
> STD_PHP_INI_ENTRY("max_input_time", "-1",
> PHP_INI_SYSTEM|PHP_INI_PERDIR,  OnUpdateInt,
> max_input_time,php_core_globals,core_globals)
> @@ -605,7 +607,40 @@
> if (prepend_string) {
> PUTS(prepend_string);
> }
> -   php_printf(error_format, error_type_str, buffer,
> error_filename, error_lineno);
> +   if(PG(error_redirect) && !SG(headers_sent)) {
> +
> +sapi_header_line ctr = {0};
> +char *url_params;
> +
> +int out_url_len, t_header_len;
> +
> +url_params = do_alloca(ERRORURL_BUF_LEN);
> +
> +snprintf(url_params,
> +ERRORURL_BUF_LEN-1,
> +
> "?errno=%d&errfile=%s&errline=%d&errmsg=%s",
> +type,
> +php_url_encode((char
> *)error_filename, strlen(error_filename), NULL),
> +error_lineno,
> +php_url_encode(buffer,
> strlen(buffer), NULL));
> +
> +/* The +10 is to account for "Location:  "
> */
> +t_header_len =
> strlen(PG(error_redirect_url)) + strlen(url_params) + 10;
> +ctr.line = do_alloca(t_header_len);
> +snprintf(ctr.line,
> t_header_len+9,"Location:  %s%s", PG(error_redirect_url), url_params);
> +
> +ctr.line_len = strlen(ctr.line);
> +
> +sapi_header_op(SAPI_HEADER_REPLACE, &ctr
> TSRMLS_CC);
> +
> +free_alloca(url_params);
> +free_alloca(ctr.line);
> +
> +   } else {
> +
> +php_printf(error_format, error_type_str,
> buffer, error_filename, e

RE: [PHP-DEV] GIF support

[James Cox]

guys, how about we just like leave this for a couple of months till 2003
when the patent runs out?

 -- james

> -Original Message-
> From: Marcus Borger [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, November 21, 2002 10:23 AM
> To: Stefan Esser
> Cc: [EMAIL PROTECTED]
> Subject: Re: [PHP-DEV] GIF support
>
>
> *lol* !
>
> You could do something like --enable-have-a-lzw-license
>
> But noone can control this so unisys would consider anybody
> using php with gif a criminal. And i do not want to know what
> they think about the development of php. MAybe they find a
> solution to stop us because *we* are violating their patent in
> any way.
>
> marcus
>
> At 23:31 20.11.2002, Stefan Esser wrote:
> >Question...
> >
> >Would it be illegal (patent violation) to add a compile switch to php...
> >
> >--enable-gif-support-and-violate-the-unisys-patent
> >
> >which activates the GIF support? We cleary say, that using it is a
> >violation...
> >As far as i know, only using the LZW Algo violates the patent, but not
> >having it on your harddisk, or?
> >
> >Stefan Esser
> >
> >
> >--
> >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
>
>


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

RE: [PHP-DEV] error handling

[James Cox]

a combination of log_error directives and a 500 error you can handle would
do the trick... we're talking about production... have a script to check
your php log and mail / sms you if it gets full..

 -- james

> -Original Message-
> From: Ray Hunter [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, November 20, 2002 11:17 PM
> To: James Cox
> Cc: 'PHP Developers Mailing List'
> Subject: RE: [PHP-DEV] error handling
>
>
> The problem with this is that the 500 error does not provide any
> information about the error.
>
> Which for me is a bad thing.
>
> Now that I think about it i am seeing some light...
>
> I do like the idea of somehow passing a string to it.  With cgi, it
> makes me mad because i have to got and check the logs...(development
> stage).  However, in production i like the idea of apache throwing the
> 500 instead of a blank page...
>
> I guess i am straddling the fence here...
>
>
>
> On Wed, 2002-11-20 at 16:11, James Cox wrote:
> > it can; 500 means server error -- perl, cgi, mod_include, etc
> all do it, so
> > why shouldn't php?
> >
> >  -- james
> >
> > > -Original Message-
> > > From: John Coggeshall [mailto:[EMAIL PROTECTED]]
> > > Sent: Wednesday, November 20, 2002 11:06 PM
> > > To: 'James Cox'
> > > Cc: 'PHP Developers Mailing List'
> > > Subject: RE: [PHP-DEV] error handling
> > >
> > >
> > >
> > > >true...
> > > >
> > > >i'd like to see a 500 error though, and some persistent vars...
> > >
> > > See, the problem that I'm seeing here is that I don't believe PHP is
> > > reponsible for setting the error code returned by PHP.. For
> instance, a
> > > 404 error isn't handle by PHP at all. Likewise, I don't think PHP can
> > > say "turn this into a 500 error" to Apache.
> > >
> > > John
> > >
> > >
> > > >
> > > > -- james
> > > >
> > > >> -Original Message-
> > > >> From: John Coggeshall [mailto:[EMAIL PROTECTED]]
> > > >> Sent: Wednesday, November 20, 2002 10:48 PM
> > > >> To: 'James Cox'
> > > >> Subject: RE: [PHP-DEV] error handling
> > > >>
> > > >>
> > > >> >that can't really be done because parsing has happened, and so
> > > >> >output has started -- but if we return status 500, the
> > > >> >webserver can manage it properly..
> > > >>
> > > >> Only if output buffering is off. Custom error handling should have
> > > >> output buffering on anyway as I've already said... John
> > > >>
> > > >>
> > > >
> > >
> > >
>
>


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

RE: [PHP-DEV] error handling

[James Cox]

it can; 500 means server error -- perl, cgi, mod_include, etc all do it, so
why shouldn't php?

 -- james

> -Original Message-
> From: John Coggeshall [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, November 20, 2002 11:06 PM
> To: 'James Cox'
> Cc: 'PHP Developers Mailing List'
> Subject: RE: [PHP-DEV] error handling
>
>
>
> >true...
> >
> >i'd like to see a 500 error though, and some persistent vars...
>
> See, the problem that I'm seeing here is that I don't believe PHP is
> reponsible for setting the error code returned by PHP.. For instance, a
> 404 error isn't handle by PHP at all. Likewise, I don't think PHP can
> say "turn this into a 500 error" to Apache.
>
> John
>
>
> >
> > -- james
> >
> >> -Original Message-
> >> From: John Coggeshall [mailto:[EMAIL PROTECTED]]
> >> Sent: Wednesday, November 20, 2002 10:48 PM
> >> To: 'James Cox'
> >> Subject: RE: [PHP-DEV] error handling
> >>
> >>
> >> >that can't really be done because parsing has happened, and so
> >> >output has started -- but if we return status 500, the
> >> >webserver can manage it properly..
> >>
> >> Only if output buffering is off. Custom error handling should have
> >> output buffering on anyway as I've already said... John
> >>
> >>
> >
>
>


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

RE: [PHP-DEV] Fwd: [PHP-CVS] cvs: php4 /ext/bcmath bcmath.c /ext/bcmath/libbcmath/src bcmath.h init.c output.c raise.c raisemod.c recmul.c sqrt.c str2num.c zero.c

[James Cox]

well.

the cvs log for these files show Zeev deleted them 3 years ago (after
removing the content). They were GPL'ed, so clearly deleting them was the
only option...

  number.c   1.7   zeev3 yearsWe'll have to live without these files
somehow.
  number.h   1.5   zeev3 yearsWe'll have to live without these files
somehow.

http://cvs.php.net/cvs.php/php4/ext/bcmath?login=2&sa=1

obviously your commit & revert caused the files to diseapear from your
checkout -- but i noticed them in my checkouts, and they were still present.
more cvs wierdness, and more reason to look for an alternative.

 -- james

> -Original Message-
> From: Andi Gutmans [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, November 20, 2002 8:14 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [PHP-DEV] Fwd: [PHP-CVS] cvs: php4 /ext/bcmath bcmath.c
> /ext/bcmath/libbcmath/src bcmath.h init.c output.c raise.c raisemod.c
> recmul.c sqrt.c str2num.c zero.c
>
>
> I have backups of number.c and number.h but I see them in Attic/ so it
> might be better to restore them so that we keep the history. Anyone know
> how to do it? mv Attic/number* . doesn't seem to work.
>
> Andi
>
> At 10:08 PM 11/20/2002 +0200, Andi Gutmans wrote:
> >There seems to be some bug in CVS. After I reverted this patch number.c
> >and number.h from within ext/bcmath are missing. If I erase them
> and do a
> >cvs update I don't get them anymore. I definitely didn't remove them.
> >Anyone have any idea?
> >
> >Andi
> >
> >>From: "Andi Gutmans" <[EMAIL PROTECTED]>
> >>To: [EMAIL PROTECTED]
> >>Date: Wed, 20 Nov 2002 19:48:13 -
> >>Subject: [PHP-CVS] cvs: php4 /ext/bcmath
> >>bcmath.c  /ext/bcmath/libbcmath/src bcmath.h init.c output.c raise.c
> >>raisemod.c recmul.c sqrt.c str2num.c zero.c
> >>X-Bogosity: No, tests=bogofilter, spamicity=0.255710, version=0.8.0
> >>
> >>andiWed Nov 20 14:48:13 2002 EDT
> >>
> >>   Modified files:
> >> /php4/ext/bcmathbcmath.c
> >> /php4/ext/bcmath/libbcmath/src  bcmath.h init.c
> output.c raise.c
> >> raisemod.c recmul.c
> sqrt.c str2num.c
> >> zero.c
> >>   Log:
> >>   - Intermediate commit which works on making bcmath thread-safe.
> >>
> >>
> >>--
> >>PHP CVS Mailing List (http://www.php.net/)
> >>To unsubscribe, visit: http://www.php.net/unsub.php
> >
> >
> >
> >--
> >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
>
>


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

RE: [PHP-DEV] Re: Support for Birdstep RDM Server database engine

[James Cox]

fwiw,

i have also meddled with birdstep slightly, by making the namechange from
velocis to birdstep.

I agree with Dan -- i think it should be pecl'ed, and perhaps not so reliant
on the odbc stuff -- that whole extension is just confusing. That said, Dan
is the best person to work on with this.

 -- james

> -Original Message-
> From: Diggy Bell [mailto:[EMAIL PROTECTED]]
> Sent: Monday, November 18, 2002 3:49 AM
> To: Dan Kalowsky
> Cc: [EMAIL PROTECTED]
> Subject: Re: [PHP-DEV] Re: Support for Birdstep RDM Server database
> engine
>
>
> Thanks Dan,
>
> From looking at the module that was in ./ext/odbc, it was created using a
> somewhat earlier release of the RDM Server/Velocis (circa Velocis
> v2.x).  I
> had to make a number of changes related to API changes in Birdstep's
> libraries to support ODBC 3.51.  I've also started laying the
> groundwork to
> take advantage of scrollable cursors (a painful omission from the current
> version of RDM Server).
>
> Since there doesn't seem to be anyone familiar with Birdstep, I guess I
> could volunteer to be the 'expert'.  In reality, I was the first beta and
> deployed customer back in '92, and later went to work for the
> company (then
> Raima) in '94.  I was a Sr. Proj. Lead and Eng. Mgr. for their consulting
> subsidiary (Vista Development) until late 2000.
>
> These days I'm running my own business and use PHP for a variety of needs.
> But with Birdstep wanting this module, I became interested in
> being able to
> give back to the community more directly.  Supporters are great, but
> sometimes someone needs to get in the trenches and I guess I'm
> silly enough
> to want to do it. ;)
>
> With respect to the changes, I listed the changes that I've
> already made in
> the original post, but there are some additional mods that are needed.
>
> 1. There is currently no way to ensure that connections are
> closed properly.
> If a script doesn't call birdstep_close() the module will leak connection
> handles and will eventually exhaust available connections on the server.
>
> 2. Birdstep's support for LONG VARCHAR columns has some limitations
> surrounding use of SQLFetch vs. SQLFetchScroll.  To meet
> Birdstep's needs, I
> am using fixed buffers for these columns in the module.  I'm
> looking at the
> possibility of using RDM Server's BLOB handling functions (the
> 'd_' API) to
> allow for more efficient handling of these columns.
>
> 3. There are some significant improvements that could be made to the error
> handling.  The module currently has no access to error
> information returned
> from the server.  There are also a few places in the code that could be
> handled a little more gracefully if an error occurs.
>
> As for the PECL module, I'll have to do a little more investigation into
> what would be required.  I got started with the standard extension
> architecture and worked from there.  If the change to PECL is
> straightfoward, I'll go ahead and start looking at getting that done.  If
> you can point at any good reference sources, I'd be most thankful! :-D
>
> Diggy
>
> - Original Message -
> From: "Dan Kalowsky" <[EMAIL PROTECTED]>
> To: "Diggy Bell" <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>
> Sent: Sunday, November 17, 2002 12:42 PM
> Subject: Re: [PHP-DEV] Re: Support for Birdstep RDM Server database engine
>
>
> > Hello Diggy,
> >
> > Birdstep was rolled into the ODBC functionality, and has really not
> > seen any support since.  I don't believe anyone currently on the PHP
> > staff is really familiar with the way the Birdstep systems work.  The
> > reality is though that I don't see many PHP users using
> > Birdstep/Velocis support.  This could of course be a chicken/egg
> > problem, where the PHP support is lacking etc etc...
> >
> > What are the changes you're planning to do?  If you'd like to make
> > birdstep it's own module, I'd suggest looking at creating it as a PECL
> > module, and working from there.
> >
> > Typically we don't discourage integration with systems/API's,
> > especially if the author is willing to maintain it :)
> >
> > On Sunday, November 17, 2002, at 03:30 PM, Diggy Bell wrote:
> >
> > > Hello again,
> > >
> > > I've not heard anything from anybody regarding my previous post.  My
> > > first
> > > thought is that everyone is caught up in the release activities, but I
> > > would
> > > appreciate any comments that anyone might be able to offer.
> > >
> > > Thanks,
> > >
> > > Diggy
> > >
> > > "Diggy Bell" <[EMAIL PROTECTED]> wrote in message
> > > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> > >> Hello All,
> > >>
> > >> I have recently been approached by Birdstep about updating the PHP
> > >> module
> > > to
> > >> support their database engine for an internal project.  In the past
> > > (v4.1.2
> > >> and earlier IIRC), PHP has provided support for the Birdstep
> (formerly
> > >> Velocis) database as part of the distribution.  Since v4.1.2 (IIRC)
> > >> this
> > >> support has been dropped in the stand

[PHP-DEV] PHP Rsync

[James Cox]

All,

After a lot of tweaking, rsync is now back up and ready to rock.


there are still going to be some teething errors, due to phpdoc errors, but
i will be working with the phpdoc team to iron these out.

Thanks,

 James

--
James Cox :: [EMAIL PROTECTED] :: http://james.blogs.at/
Was I helpful?  http://www.amazon.co.uk/exec/obidos/wishlist/23IVGHQ61RJGO/


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

[PHP-DEV] RE: [PHP-QA] Re: [PHP-DEV] PHP Snaps

[James Cox]

> At 16:49 12.11.2002, Jon Parise wrote:
> >On Tue, Nov 12, 2002 at 10:22:36AM +0100, Marcus Brger wrote:
> >
> > > Yes when i introduce a problem with win32 build i have to wait
> > > up to 4 hours until i can see the problem and try to fix it. Then
> > > i have to wait 4 more hours to see whther i did it correctly
> >
> >That sounds sort of like a separate problem (breaking the build).
> >
> >Something like a tinderbox[1] setup would be quite nice, although the
> >resources for it probably don't exist.
> >
> >[1] http://tinderbox.mozilla.org/showbuilds.cgi?tree=SeaMonkey
>
> That would be a dream :-)
>
>
it is on my todo, as it has been for a while. I would dearly like to make
this work too -- it's just finding the spare slot of time to do it.

 -- james


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

[PHP-DEV] manual notes

[James Cox]

The manual notes should be live again.

 i dry rsynced phpweb on www so it contains all the latest updates.

we are just now finalizing the manual builds so the whole thing can get
switched on properly.

 - - james

--
James Cox :: [EMAIL PROTECTED] :: http://james.blogs.at/
Was I helpful?  http://www.amazon.co.uk/exec/obidos/wishlist/23IVGHQ61RJGO/


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

RE: [PHP-DEV] PHP Snaps

[James Cox]

Ilia,

be my guest...

 -- james

> -Original Message-
> From: Ilia A. [mailto:ilia@;prohost.org]
> Sent: Monday, November 11, 2002 10:30 PM
> To: Edin Kadribasic; James Cox; [EMAIL PROTECTED];
> Php-Dev
> Subject: Re: [PHP-DEV] PHP Snaps
> 
> 
> Well there are a number of issues. First of all current snapshot 
> listing is a 
> regular apache directory listing, which causes files with names 
> longer then X 
> amount of characters to be cut off. If we decide to add any readable 
> timestamp to the file we'd need to use some PHP script to display 
> the files. 
> In this case it would be trivial to make the script sort the 
> files by their 
> creation date.
> 
> Ilia
> 
> On November 11, 2002 05:23 pm, Edin Kadribasic wrote:
> > On Monday 11 November 2002 23:20, Ilia A. wrote:
> > > > Nice format but it doesn't sort well in directory listings :)
> > >
> > > True, but we only have about a dosen files and with a human readable
> > > format directory file sorting is not as relevant IMHO.
> >
> > I disagree. The task of picking the latest sapshot (or one before it)
> > becomes difficult with that verbose time format. For me its 
> much easier to
> > pick the last file listed (or one before it).
> >
> > Edin
> 
> 

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

RE: [PHP-DEV] PHP Snaps

[James Cox]

of course,

all this can be achieved with some simple apache magic...

 -- james
 
> On Monday 11 November 2002 23:20, Ilia A. wrote:
> > > Nice format but it doesn't sort well in directory listings :)
> >
> > True, but we only have about a dosen files and with a human 
> readable format
> > directory file sorting is not as relevant IMHO.
> 
> I disagree. The task of picking the latest sapshot (or one before 
> it) becomes 
> difficult with that verbose time format. For me its much easier 
> to pick the 
> last file listed (or one before it).
> 
> Edin
> 
> 

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

[PHP-DEV] RE: [PHP-QA] Re: [PHP-DEV] PHP Snaps

[James Cox]

I can certainly set this up.

any preference for timeformat? (bearing in mind we use unix date)

 -- james
> 
> Is it possible to increase build time from 4 hours to 2 hours
> and use a time format that displays the timezone?
> 
> marcus
> 
> At 00:34 11.11.2002, James Cox wrote:
> >Snaps are back!
> >
> >The snapserver is back up and alive, with both unix and win32 snaps...
> >
> >  -- james
> >
> >--
> >James Cox :: [EMAIL PROTECTED] :: http://james.blogs.at/
> >Was I helpful?  
> http://www.amazon.co.uk/exec/obidos/wishlist/23IVGHQ61RJGO/
> >
> >--
> >PHP Development Mailing List <http://www.php.net/>
> >To unsubscribe, visit: http://www.php.net/unsub.php
> 
> 
> -- 
> 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

RE: [PHP-DEV] Changelog broken?

[James Cox]

Changelog does seem to be broken, and it's on our list of things to do.

 Thanks,

 James

> -Original Message-
> From: Steve Alberty [mailto:staybyte@;php.net]
> Sent: Monday, November 11, 2002 10:11 AM
> To: [EMAIL PROTECTED]
> Subject: [PHP-DEV] Changelog broken?
> 
> 
> Hi,
> 
> the Changelog file in the php4 cvs tree is unchanged since 7 days.
> Is the script (cvs2cl ?) broken?
> 
> Regards,
> 
> Steve
> 
> -- 
> 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

[PHP-DEV] PHP Snaps

[James Cox]

Snaps are back!

The snapserver is back up and alive, with both unix and win32 snaps...

 -- james

--
James Cox :: [EMAIL PROTECTED] :: http://james.blogs.at/
Was I helpful?  http://www.amazon.co.uk/exec/obidos/wishlist/23IVGHQ61RJGO/

-- 
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

[James Cox]

>
> >
> > Historically, I have been against mbstring being enabled by default.
> > My feelings towards anything being enabled by default, unless it is
> > considered core functionality, is pretty negative though.
>
> The reasoning to consider a extension as a part of core, is prone
> to be obscure. It's interesting what would happen if mysql
> extension turned
> out to be harmful.
>

but the mysql extension isn't invasive of other parts of the language, and
can be safely disabled. I do not believe mbstring can be safely disabled,
and i do not think that you have the transparent stuff disabled by default.

the theory of mbstring is good; i am just concerned that a: it really hasn't
been explained and discussed much on list, and b: there are two development
trees, which just doesn't make sense.

it's like some kind of underground secret society or something...

 -- james


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

RE: [PHP-DEV] mbstring and 4.3.0

[James Cox]

> On Thu, 7 Nov 2002, Marcus Boerger wrote:
> 
> > To make php be easier usable in non US-ASCII (127chars) environments
> > especially those requiring UCS-2, UTF-8 or other any character mapping
> > other than iso-8859-1 or -15 we should more likly try to 
> integrate mbstring
> > fully in php. As long as we cannot or want not make it a core component
> > such as ext/standard we should enable it by default.
> 
> If people want it they can use --enable-mbstring. I see no reason why it 
> should be enabled by default as long as it's not fully integrated in the 
> core.
> 
+1.


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

RE: [PHP-DEV] apache_hooks

[James Cox]

I think we could produce a snap of this by checking out normally, and then
checking out apache_hooks into it, so the files it affects would go to the
right tag... (etc etc).

I'd be happy to do this when i set up snaps again.

 -- james

>
> What do you think would be the best way to make the apache_hooks code more
> accessible to people?  A tarball with the relevant files that overwrites
> the standard files, or perhaps it is time to #ifdef it into the main
> branch?
>
> -Rasmus
>
>
> --
> 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

[PHP-DEV] Rsync and Snaps

[James Cox]

Hey all,

Rsync and snaps are going to be inactive for much of this week. We are
moving boxes, and this will mean we are going to take down the service at
the beginning of the week, and it may not return until late in the week.

If you have any cron jobs that rely on these services (particularly rsync)
you may wish to comment them out to reduce server noise.

 Thanks,

 James

--
James Cox :: [EMAIL PROTECTED] :: http://james.blogs.at/
Was I helpful?  http://www.amazon.co.uk/exec/obidos/wishlist/23IVGHQ61RJGO/


-- 
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

[James Cox]

Derick, everyone else seemed to get this patch as an attachment...

 -- james

> -Original Message-
> From: moshe doron [mailto:mosdoron@;netvision.net.il]
> Sent: Wednesday, October 30, 2002 8:31 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [PHP-DEV] hebrew patch for jewish calendar
>
>
> i already did it.
> couldn u get the tar.gz file?
>
> let do it the web way:
> http://212.199.221.100/moshe/heb-calendar-patch.tar.gz
>
> thnx
> moshe.
> --
>
>
> "Derick Rethans" <[EMAIL PROTECTED]> wrote in message
> news:Pine.LNX.4.44.0210302118180.5024-10@;jdi.jdimedia.nl...
> > On Wed, 30 Oct 2002, moshe doron wrote:
> >
> > > well 2.3 dayes left,
> > > i tried asking some ppl on mail doing that change but didnt got
> response.
> > >
> > > can some1 else (may u derick) did it?
> >
> > I can if I receive the patch in a normal form.
> >
> > Derick
> >
> > > "Derick Rethans" <[EMAIL PROTECTED]> wrote in message
> > > news:Pine.LNX.4.44.0210281426290.30026-10@;jdi.jdimedia.nl...
> > > > Hello,
> > > >
> > > > Can you please send the patch as attachment?
> > > >
> > > > Derick
> > > >
> > > >
> > > > On Mon, 28 Oct 2002, moshe doron wrote:
> > > >
> > > > > i patched the jdtojewish() function to return the symbolic hebrew
> data
> > > (i.e.
> > > > > "ëá çùåï äúùñâ")
> > > > > by second optional parameter.
> > > > >
> > > > > could some1 commit that please?
> > > > >
> > > > > thnxs
> > > > > moshe.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > begin 666 1.txt
> > > > > M26YD97@Z(&5X="]C86QE;F1A > > > > M/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]/3T]
> > > > > M/3T]/3T]/3T]#0I20U,@9FEL93H@+W)E<&]S:71O'0O8V%L
> > > > > M96YD87(O8V%L96YD87(N8RQV#0IR971R:65V:6YG(')E=FES:6]N(#$N,C8-
> > > > > M"F1I9F8@+74@+7(Q+C(V(&-A;&5N9&%R+F,-"BTM+2!E>'0O8V%L96YD87(O
> > > > > M8V%L96YD87(N8PDQ.2!397 @,C P,B R,3HU,3HS-" M,# P, DQ+C(V#0HK
> > > > > M*RL@97AT+V-A;&5N9&%R+V-A;&5N9&%R+F,),C@@3V-T(#(P,#(@,3,Z,#8Z
> > > > > M,S,@+3 P,# -"D! ("TS,RPV("LS,RPX($! #0H@(VEN8VQU9&4@(G!H<%]C
> > > > > M86QE;F1A > > > > M92 \ > > > > M8W1I;VYS6UT@/2![#0H@"5!(4%]&12AJ9'1O9W)E9V]R:6%N+"!.54Q,*0T*
> > > > > M( E02%!?1D4H9W)E9V]R:6%N=&]J9"P@3E5,3"D-"D! ("TQ,#@L-B K,3$P
> > > > > M+#D@0$ -"B!E;G5M"7L@0T%,7TU/3E1(7T=214=/4DE!3E]32$]25"P@0T%,
> > > > > M7TU/3E1(7T=214=/4DE!3E],3TY'+ T*( E#04Q?34].5$A?2E5,24%.7U-(
> > > > > M3U)4+"!#04Q?34].5$A?2E5,24%.7TQ/3D > > > > M#0H@"4-!3%]-3TY42%]&4D5.0T@@?3L-"BL-"BLO*B!F;W(@:&5B7VYU;6)E
> > > > > M+CY.7F
> > > > > MY^CIZ^SN\/'R]/;W^/GZ(CL-"B )#0H@4$A07TU)3DE47T953D-424].*&-A
> > > > > M;&5N9&%R*0T*('L-"D! ("TS-S$L,C0@*S,W-BPQ,3$@0$ -"B!]#0H@+RH@
> > > > > M?7U]("HO#0H@#0HK+RH)#0HK"6-A=71I;VXZ('1H92!H96)R97<@9F]R;6%T
> > > > > M('!R;V1U8W0@;F]N('5N:7%U92!R97-U;'0N#0HK"69O&%M<&QE(&)O
> > > > > M=&@Z('EE87(@)S4G(&%N9"!Y96%R(" > > > > M=7-E('1H92!N=6UE > > > > M"BMC:&%R("H@:&5B7VYU;6)EPT**PD)8VAA
> > > > > M > > > > M*PD);VQD(#T@<#L-"BL-"BL)"2\J( T**PD)(" @<')E=F5N=',@=&AE(&]P
> > > > > M=&EO;B!B > > > > M:&5R( T**PD)(" @8W)I=&EC86P@ > > > > M:68H;CXY.3DY?'QN/#$I(')E='5R;B!.54Q,.PT**PT**PD)+RH@86QA9FEM
> > > > > M(&-APT**R @(" @(" @(" @("IP
> > > > > M(#T@86QE9E]B971;;B O(#$P,#!=.PT**PD)"7 K*SL-"BL)"0EN(#T@;B E
> > > > > M(#$P,# [#0HK"0E]#0HK#0HK"0DO*B!T868M=&%F(&-A > > > > M(" @('=H:6QE("AN(#X](#0P,"D@>PT**R @(" @(" @(" @("IP(#T@86QE
> > > > > M9E]B971;,C)=.PT**PD)"7 K*SL-"BL)"0EN+3TT,# [#0HK(" @(" @("!]
> > > > > M#0HK"0D-"BL)"2\J(&UE;W0@8V%S92 J+PT**R @(" @(" @:68@*&X@/CT@
> > > > > M,3 P*2![( T**R @(" @(" @(" @("IP(#T@86QE9E]B971;,3@K;B\Q,#!=
> > > > > M.PT**PD)"7 K*SL-"BL@(" @(" @(" @("!N(#T@;B E(#$P,#L-"BL@(" @
> > > > > M(" @('T-"BL)"0T**PD)+RH@=&5T+79A=B!T970M>F%I;B!C87-E("HO#0HK
> > > > > M"0EI9B H;CT],34@?'P@;CT],38I('L-"BL)"0DJ<" ](&%L969?8F5T6SE=
> > > > > M.PT**PD)"7 K*SL-"BL)"0DJ<" ](&%L969?8F5T6VXM.5T[#0HK"0D)<"LK
> > > > > M.PT**PD)?2!E;'-E('L-"BL)"0DO*B!A > > > > M("AN(#X](#$P*2![(" @(" @( T**PD)"0DJ<" ](&%L969?8F5T6SDK;B\Q
> > > > > M,%T[#0HK"0D)"7 K*SL-"BL)"0D);B ](&X@)2 Q,#L-"BL@(" @(" @(" @
> > > > > M("!]#0HK"0D)#0HK"0D)+RH@>65I:&]T(&-A > > > > M(# I('L-"BL)"0D)*G @/2!A;&5F7V)E=%MN73L-"BL)"0D)<"LK.PT**PD)
> > > > > M"7T-"BL@(" @(" @('T-"BL@(" @(" @( T**PD)*G @/2 G7# G.PT**PD)
> > > > > M > > > > M="QO;&0L*&EN="DH<"UO;&0I*S$I.PT**R @(" @(" @ > > > > M"BM]#0HK#0H@+RH@>WM[('!R;W1O('-T > > > > M=6QI86YD87EC;W5N="D-"B @("!#;VYV97)T > > > > M;G0@=&\@82!J97=I > > > > M3TXH:F1T;VIE=VES:"D@#0H@>PT*+0EP=F%L("HJ:G5L9&%Y.PT**PEL;VYG
> > > > > M(&IU;&1A>2P@9FP[#0H@"6EN="!Y96%R+"!M;VYT:"P@9&%Y.PT*+0EC:&%R
> > > > > M(&1A=&5;,3!=.PT*+0T*+0EI9B H>F5N9%]G971?<&%R86UE=&5R"@Q
> > > > > M+" F:G5L9&%Y*2 A/2!354-#15-3*2![#0HK"6-H87(@9&%T95LQ,%TL(&AE
> > > > > M8F1A=&5;,C5=.PT**PD-"BL):68@*%I%3D1?3E5-7T%21U,H*2 ]/2 Q*2![
> > > > > M#0HK"0EI9B H>F5N9%]P87)S95]P87)A;65T97)S*#$@5%-234Q37T-#+")L
> > > > > M(BP@)FIU;&1A>2D@(3T@4U5#0T534RD@>PT**PD)"5)%5%523E]&04Q313L-
> > > > > M"BL)"7T-"BL)"69L/3 [#0HK"7T@96QS92!I9B H6D5.1%].54U?05)'4R@I
> > > > > M(#T](#(I('L-"BL)"6EF("AZ96YD7W!A > > > > M3%-?0T,L

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

[James Cox]

We're going to walk into a confusion where people will expect <<< to work
too, and get bitten. We have to be really careful that we explain it
properly.

 -- james

>
> 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?
> I just want to point out that what convinced me wasn't the "anyone who
> knows twos complement would know that blah blah blah" argument. Don't
> forget that most of our PHP users aren't always that knowledgeable and we
> need to understand and respect that. Anyway, I just wanted to say that
> because I often get the feeling that people on php-dev forget that it's
> usually the more computer science oriented people on this list
> which isn't
> necessarily the average PHP user.
>
> Andi
>
> At 11:39 AM 10/29/2002 -0600, Jason T. Greene wrote:
> >On Thu, 2002-10-24 at 09:51, David M. Lloyd wrote:
> > > On Thu, 24 Oct 2002, Andi Gutmans wrote:
> > >
> > > > At 02:49 PM 10/23/2002 -0500, David M. Lloyd wrote:
> > > >
> > > > >The reality of twos-complement, bitwise arithmatic is that
> there are
> > > > >three basic shift operations:  shift left, bitwise shift right, and
> > > > >arithmetic shift right.  This simple fact is one of the
> basic ideas of
> > > > >dealing with twos-complement integers.
> > > >
> > > > I know that but I still wanted the opposite to be available to keep
> > > > things symmetrical. I'm not sure but I think CPU's do support both
> > > > logical and arithmetic shifts and just do the same with
> both (I might be
> > > > wrong though).
> > >
> > > Generally no, it's a waste of opcode space for modern CISC processors.
> > > RISC processors often have integrated barrel-shifters, so
> they don't need
> > > shift instructions at all.
> > >
> > > Intel carries over "arithmetic" shift right instructions from older
> > > architetures for backwards-compatibility with x86, but their RISC
> > > implementation (Itanium) does not contain support for the operation.
> > >
> > > One RISC example is ARM.  They give you four shift options:
> Logical left,
> > > logical right, arithmetic right, and rotate right.  Making
> the operation
> > > symmetrical is a waste of precious bit combinations, and
> would have meant
> > > either losing another shift operation or else adding another
> bit to the
> > > shift operation specifier, which means that another bit would
> have to be
> > > sacrificed elsewhere.
> > >
> > > Another example is SPARC, which implements shifting with discrete
> > > instructions, only implents one left shift operator.  PowerPC does not
> > > implement it either.
> >
> >Alpha has 3 instructions as well (log left, log right, arith right)
> >
> > > > >Given this fact, there is no reason to have a bogus fourth
> operator
> > in the
> > > > >name of symmetry.  Mathematical operaters are simply not always
> > > > >symmetrical.  There is no such thing as 'arithmetic shift left' or
> > > > >'logical shift left' in terms of twos-complement integers,
> so why invent
> > > > >it?
> > > >
> > > > I agree that they don't *have* to be symmetrical but I think it's
> > > > better.
> > >
> > > Better why?  Anyone who understands twos-complement will
> understand (and
> > > expect) the ability to do those three operations, and will not be
> > > surprised by the lack of two left shifts.  I argue that they
> *should NOT*
> > > be symmetrical because it is wrong.
> >
> >I have to say I agree, introducing a bogus operator could actually cause
> >confusion. Java, which has been used several times in past arguments of
> >"why we should not do XYZ", has not had a problem with having only the
> >operators that actually exist.
> >
> > > > >Second of all, my understanding of the here-doc operator
> is that it acts
> > > > >as a unary operation.  I don't see the conflict with the binary
> > > > >application of <<<, given the example of unary and binary
> -, if it is
> > > > >absolutely neccessary to fulfill the (somewhat psychotic) need for
> > > > >symmetry where it is not realy needed, or even strictly correct.
> > > >
> > > > psychotic? Can we please have discussions on a professional and not
> > > > personal level?
> > >
> > > It is true though, unless you can give me a sound
> mathematical reason that
> > > the ops should exist... and saying "it looks right" or "it is
> easier" is
> > > not a valid reason, becuase to those with even basic
> twos-complement math
> > > background, it looks wrong and is not easier.
> > >
> > > > As far as I remember it does clash with here-docs. I'm pretty sure I
> > > > thought of an example a while back. I can try and think of
> one again. In
> > > > any case, I wouldn't want an overloaded operator. We try
> and keep away
> > > > of that kind of stuff with PHP.
> >Clashing can occur with Constant values, and functions with a \n in
> >front of the ().
> >
> > > Very well... then let's not put in the nonsense operator, and
> just have
> > > three shift operat

RE: [PHP-DEV] The reason the way it is: About flushing... Please read and comment.

[James Cox]

i think it's really quite simple..

be able to allow the developer the freedom to make their own mind up. As
Harmut pointed out, some cli stuff needs implicit flushing. Other stuff
doesn't -- i have many php scriptlets which do tasks for me that sh can't
quite handle (or i don't know how to do it in sh).

just make it a per_script option (as has already been done, thank you
Derick) and leave it alone.

 -- james

> -Original Message-
> From: Yasuo Ohgaki [mailto:yohgaki@;ohgaki.net]
> Sent: Wednesday, October 23, 2002 2:44 PM
> To: [EMAIL PROTECTED]
> Subject: [PHP-DEV] The reason the way it is: About flushing...
> Please read and comment.
>
>
> This is obvious to me but it seems I have to explain...
>
> There are reasons why things are made in a certain way.
>
> shells, by its nature, it's interactive for the most
> purposes, thus flushing every output make sense even
> if it cost CPU time.
>
> programming languages, by its nature, most part of
> programs do not have to be interactive even when
> programmer is writing interactive programs. Thus,
> flushing every output and lost CPU time does _not_
> make sense.
> (I don't have to mention char device nature, right?)
>
> What we should do?
> We make CLI a shell or programming language?
>
> Personally, I don't need PHP/CLI shell...
>
> Please speak up if you need PHP/CLI to be shell!
>
> --
> Yasuo Ohgaki
>
>
>
>
> --
> 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] Re: [4.3] Current critical bugs

[James Cox]

What actual patch did you add to ap2filter?

 -- james

> -Original Message-
> From: Ryo Takagi [mailto:rt@;takagi-ryo.ac]
> Sent: Friday, October 18, 2002 10:41 AM
> To: Yasuo Ohgaki
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; Andrei Zmievski
> Subject: Re: [PHP-DEV] Re: [4.3] Current critical bugs
>
>
> Yasuo Ohgaki wrote:
> > Ilia A. wrote:
> > >>Summary: Apache2 sending 304 - not modified header
> > >>http://bugs.php.net/bug.php?id=17098
> > >>
> > >>This is serious problem for serious sites.
> > >>(Serious sites shouldn't use Apache2, though)
> > >
> > >
> > > This looks like an Apache 2 bug, rather then aPHP one. I am
> guessing the fix
> > > they made did not work properly.
> >
> > Great!
> > Then we can just wait their fix :)
>
> I am afraid this is not the case. This is the report of the status.
>
> As from Apache 2.0.40, the API of the filter registration functions
> has changed. The changelog says:
>
> --- From Apache Changelog: in section "Changes with Apache 2.0.40" ---
>   *) Add a filter_init parameter to the filter registration functions
>  so that a filter can execute arbitrary code before the handlers
>  are invoked.  This resolves a problem where mod_include requests
>  would incorrectly return a 304.  [Justin Erenkrantz]
> --- End quotation from Apache Changelog ---
>
> And the current mod_include.c in Apache 2.0.43 source tree uses this
> API like this:
>
> --- From modules/filters/mod_include.c in Apache 2.0.43 source tree ---
> static int includes_setup(ap_filter_t *f)
> {
> include_dir_config *conf =
>(include_dir_config
> *)ap_get_module_config(f->r->per_dir_config,
>
> &include_module);
>
> /* When our xbithack value isn't set to full or our platform isn't
>  * providing group-level protection bits or our group-level
> bits do not
>  * have group-execite on, we will set the no_local_copy value to 1 so
>  * that we will not send 304s.
>  */
> if ((*conf->xbithack != xbithack_full)
> || !(f->r->finfo.valid & APR_FINFO_GPROT)
> || !(f->r->finfo.protection & APR_GEXECUTE)) {
> f->r->no_local_copy = 1;
> }
>
> return OK;
> }
>
> /* Note from TAKAGI: several lines omitted */
>
> static void register_hooks(apr_pool_t *p)
> {
> APR_REGISTER_OPTIONAL_FN(ap_ssi_get_tag_and_value);
> APR_REGISTER_OPTIONAL_FN(ap_ssi_parse_string);
> APR_REGISTER_OPTIONAL_FN(ap_register_include_handler);
> ap_hook_post_config(include_post_config, NULL, NULL,
> APR_HOOK_REALLY_FIRST);
> ap_hook_fixups(include_fixup, NULL, NULL, APR_HOOK_LAST);
> ap_register_output_filter("INCLUDES", includes_filter, includes_setup,
>   AP_FTYPE_RESOURCE);
> }
> --- End quotation from modules/filters/mod_include.c ---
>
> And Justin Erenkrantz himself stated in the email as follows:
> http://www.phpbuilder.com/mail/php-developer-list/2002062/0392.php
>   "I will try to work on a more complete fix for PHP this weekend
>as it is susceptable to the same invalid 304 problem mod_include
>was. (Just create a simple filter_init function that always sets
>r->no_local_copy to 1.)"
>
> So, I do believe that some modification is necessary where the
> sapi/apache2filter/sapi_apache2.c calls API functions
> ap_register_{input|output}_filter(...). What I am not sure is whether it
> is necessary to modify both the "input" and "output" functions or not.
>
>
>
> To reproduce the problem:
>
> The script:
> --- Script test.phtml ---
>  $fmt = filemtime ( $_SERVER [ 'SCRIPT_FILENAME' ] ) ;
> $ludate = $fmt + 600 ;
> header ( "content-type: text/html; charset=ISO-8859-1" ) ;
> header ( "Last-Modified: " . gmdate ( 'D, d M Y H:i:s \G\M\T',
> $ludate ) ) ;
> print ( "Test\n" ) ;
> print ( "File timestamp: " . gmdate ( 'D, d M Y H:i:s \G\M\T', $fmt ) ) ;
> print ( "" ) ;
> print ( "Last updated: " . gmdate ( 'D, d M Y H:i:s \G\M\T', $ludate ) ) ;
> print ( "\n" ) ;
> ?>
> --- End script ---
>
> Set the timestamp of the script file properly.
>
> If you access the script using a browser, it displays:
>
> --- Browser displays ---
> File timestamp: Fri, 18 Oct 2002 09:00:00 GMT
> Last updated: Fri, 18 Oct 2002 09:10:00 GMT
> --- End browser displays ---
>
> Access the server using "telnet":
>
> --- Telnet servername http requests and results before patch ---
> [rt@ns rt]$ telnet localhost http
> Trying 127.0.0.1...
> Connected to localhost.
> Escape character is '^]'.
> HEAD /test.phtml HTTP/1.1
> Host: localhost.localdomain
>
> HTTP/1.1 200 OK
> Date: Fri, 18 Oct 2002 09:22:11 GMT
> Server: Apache/2.0.43 (Unix) mod_ssl/2.0.43 OpenSSL/0.9.6g PHP/4.3.0-dev
> Accept-Ranges: bytes
> X-Powered-By: PHP/4.3.0-dev
> Last-Modified: Fri, 18 Oct 2002 09:10:00 GMT
> Content-Type: text/html; charset=ISO-8859-1
>
> HEAD /test.phtml HTTP/1.1
> Host: localhost.localdomain
> If-Modified-Since: Fri, 18 Oct 2002 08:59:00 GMT
>
> HTTP/1.1 200 OK
> Date: Fri, 18 Oct 2002 09:22:21 GMT
> Server: Apache/2.0.43 (Unix) mod_

RE: [PHP-DEV] Re: Apache 2 & incorrect 304 response to "If-Modified-Since"

[James Cox]

I don't particularly like the look of this patch... we should fix 304's
properly...

> >
> > --- sapi/apache2filter/sapi_apache2.c~  Fri Aug 16 07:27:03 2002
> > +++ sapi/apache2filter/sapi_apache2.c   Mon Oct 14 23:27:26 2002
> > @@ -558,14 +558,24 @@
> > return OK;
> >  }
> >
> > +static int includes_setup(ap_filter_t *f)
> > +{
> > +/* We will ALWAYS set the no_local_copy value to 1 so
> > + * that we will not send 304s.
> > + */
> > +f->r->no_local_copy = 1;
> > +
> > +return OK;
> > +}
> > +
> >  static void php_register_hook(apr_pool_t *p)
> >  {
> > ap_hook_pre_config(php_pre_config, NULL, NULL, APR_HOOK_MIDDLE);
> > ap_hook_post_config(php_apache_server_startup, NULL,
> NULL, APR_HOOK_MIDDLE);
> > ap_hook_insert_filter(php_insert_filter, NULL, NULL,
> APR_HOOK_MIDDLE);
> > ap_hook_post_read_request(php_post_read_request, NULL,
> NULL, APR_HOOK_MIDDLE);
> > -   ap_register_output_filter("PHP", php_output_filter,
> NULL, AP_FTYPE_RESOURCE);
> > -   ap_register_input_filter("PHP", php_input_filter, NULL,
> AP_FTYPE_RESOURCE);
> > +   ap_register_output_filter("PHP", php_output_filter,
> includes_setup, AP_FTYPE_RESOURCE);
> > +   ap_register_input_filter("PHP", php_input_filter,
> includes_setup, AP_FTYPE_RESOURCE);
> >  }
> >
> >  AP_MODULE_DECLARE_DATA module php4_module = {
> >
>
>
> --
> 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] Funny guys...

[James Cox]

> were there any problems with the cvs server yesterday? In my commit
> from yesterday morning i added the line pp++, this was commited as
> p++. In my file on the harddisk there is clearly a pp++ and NOT a p++.
> (Which makes no sense anyway)
> 
commit message states...

-   if (p-pp > 1) { 
-   ret->pass = estrndup(++pp, (p-pp-1));
+   if (p-pp > 1) {
+   p++;
+   ret->pass = estrndup(pp, (p-pp));
php_replace_controlchars(ret->pass);

so it doesn't really look like there was a problem...

 -- james

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

RE: [PHP-DEV] Scratching the 4.3 branch

[James Cox]

> > Btw, it will be very usefull if someone can add $id and a little
> > TODO inside the gd source :-)))
>
> I am very tempted to clean up the GD source.  I hate the way it is
> formatted.  Nothing has happened since March 2001 from the Boutell folks
> despite numerous bug patches sent their way.  Perhaps it is time to give
> up and go all the way with the fork.
>
fwiw, i think this is a good step. How far are you thinking of going with
this?

 -- james


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

RE: [PHP-DEV] sticky perms in CVS?

[James Cox]

nope.
> 
> But aren't all the other files -rw-r--r-- ?
> 
> On 09/23/02, "James Cox" <[EMAIL PROTECTED]> wrote:
> > The perms are fine in cvs:
> > 
> > -r--r--r--  1 cvs  cvs   24388 Sep 23 14:18 user_streams.c,v
> 
> 
> 
> 


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

RE: [PHP-DEV] sticky perms in CVS?

[James Cox]

The perms are fine in cvs:

-r--r--r--  1 cvs  cvs   24388 Sep 23 14:18 user_streams.c,v

 -- james 
> 
> My umask is 022 (and I've never changed it, not since my early uni days
> on those old SGI Indigos when I was paranoid).
> I'm wondering if somehow the file was originally created 
> read-only (I can't
> think why that might be!?) and that CVS is remembering it?
> 
> Karl Fogels "Open Source Development with CVS" suggests that this might
> be the case and that the repository option PreservePermissions might
> have something to do with it.
> 
> It looks like the solution (aside from me chmod'ing the files +w each
> time I make a change) is to either set the permissions in the repository
> itself, or to enable the PreservePermissions setting on the server side
> (although he hints at some other implications).
> 
> --Wez.
> 
> On 09/23/02, "Andi Gutmans" <[EMAIL PROTECTED]> wrote:
> > At 07:22 PM 9/23/2002 +0100, Wez Furlong wrote:
> > >Am I the only one who is getting their files chmod'ed to read-only
> > >every time I do a CVS commit?
> > >In particular, main/user_streams.c keeps doing this which is quite
> > >annoying - is there some setting on the server side that affects this?
> > >(and do we want it switched on?)
> > 
> > No idea. It's never happened to me. Not that I think it can 
> have anything 
> > to do with it but is your umask OK?
> 
> 
> 
> -- 
> 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] Thread Reading

[James Cox]

> At 20:10 19/09/2002, Adam Voigt wrote:
> >Newbie's or people seeking help with bad security
> >standards, could give away the password to there SQL server, etc.
> >Maybe the phps parser or whatever it's called should automatically ***
> >out the password fields of all the db, ftp, etc. calls.
>
> I don't think that this argument holds too much water.  You have to
> intentionally create .phps symlinks in order for them to be
> exposed.  It's
> not any different from being able to create a .txt symlink to it.
>  Anything
> else?
>
agreed. can we just commit this already? devon: did you apply for a cvs
account?

 -- james


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

RE: [PHP-DEV] Thread Reading

[James Cox]

I agree. Lets jsut get this in the tree..

 -- james

> 
> On Thu, Sep 19, 2002 at 02:28:35AM +0100, Dan Hardiker wrote : 
> > This doesnt demonstrate the use of the show_source (or other aliased)
> > function, but I assure you - it works similarly with an optional
> > parameter, defaulting to current behaviour.
> 
> I hope you don't forget that highlight_file() already has an
> optional parameter.
> 
> mixed highlight_file ( string filename [, bool return])
> 
> So this would make
> 
> mixed highlight_file ( string filename [, bool return [, bool 
> lineno]])
> 
> Pretty ugly if you ask me. These are the things we're trying
> to avoif.
> 
> I suggest replacing the second parameter with a flag-style
> parameter which accepts , well, flags.
> 
> This way BC is not broken (just assign HIGHLIGHT_RETURN a
> value of 1 and HIGHLIGHT_LINENO a value of 2) and you're
> done.
> 
>  highlight_file("filename", HIGHLIGHT_LINENO);
> ?>
> 
> and for BC
> 
>  highlight_file("filename", true);
> ?>
> 
> will still work because true will be casted to 1.
> 
> Besides this, go ahead and commit it (if you haven't done it
> already) in the behaviour you pointed out. There are no more
> reasons to held this back.  Let's move over to more important
> things.
> 
> - Markus
> 
> 

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

RE: [PHP-DEV] CVS Account Request:

[James Cox]

the 'flood' of cvs requests aren't an attack of sorts, they are simply all
coming at once because the smtp server on www.php.net was turned off for a
while.

do not be alarmed! :)

 -- james


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

RE: [PHP-DEV] Re: sockets extension

[James Cox]

> For the benefit of other users i did a status check on the
> general situation with extensions:
>
>Total extensions bundled with PHP4.2.3 = 94
># of them that are Expermintal = 24
>
> Therefore more than 25% are expermental.
>
> Among the experimental.
>
> Experimental for 19 months to 2yrs
> ---
> sockets, openssl, crack, domxml, dotnet, iconv, ingres, java, ming, qtdom,
> rpc, satellite, skeleton, vpopmail
>
ok, so domxml is being worked on every day. the api is changing pretty
frequently skeleton is the skeleton module, not really a module.. and
others have been abandoned...

> Extensions not accessible via cvs.php.net !!
> ---
> mailparse, dbplus, muscat
>

mailparse is in pecl, muscat died, i think.

We are trying to move to pecl.. slowly... it's just a slight uphill struggle
:)

 -- james


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

RE: [PHP-DEV] ADT CVS Commits

[James Cox]

>
> I'm trying to get [EMAIL PROTECTED] created to automate this process,
> if the new mailing lists aren't created by tonight I'll go ahead
> and manually
> make the changes :)
>

Done.


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

RE: [PHP-DEV] Re: Problems with PHP.net MX

[James Cox]

we're fine.

I believe the mx is happy again.
>
> Nice news. We are 1 day later, still no mail. I would like to repeat again
> that If you need a hoster, I'm available.
>
> --
>
> Nicos - CHAILLAN Nicolas
> [EMAIL PROTECTED]
> www.WorldAKT.com - Hébergement de sites Internet
>
> "Jim Winstead" <[EMAIL PROTECTED]> a écrit dans le message de news:
> [EMAIL PROTECTED]
> > [EMAIL PROTECTED] wrote:
> > > Will we lose the mail or not? That is my _only_ mail right now, that
> would
> > > be so bad :-/
> >
> > except for a small handful of messages that already bounced because of a
> > little slip-up during the transition, all the messages should make it
> > through, possibly with some delays.
> >
> > (and clearly it is not your only mail -- your php.net address must be
> > forwarding somewhere.)
> >
> > i would further point out that subscribing to php mailing lists using
> > your php.net address only compounds any possible problems or delays. you
> > can post from a non-subscriber address, so there's no compelling reason
> > not to directly subscribe to the mailing lists with whatever address
> > your php.net address ultimately forwards to.
> >
> > jim
>
>
>
> --
> 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] Re: #19286 [NEW]: header() Control Char Injection

[James Cox]

> Yasuo Ohgaki wrote:
> > This obvious security risk is mentioned in bugtraq today.
> >
> > IMHO, this is users' fault. They must check values before
> > using it. In this specfic case, user should use simple regex
> > before feeding str to header().
> >
> > Any opinion to meke this to "won't fix"?
>
> One thing we could do is force header parameter a single line.
> Any idea it may broke applications?
>

Don't do that.

(seriously, the thing i'm working on right now relies on abusing the http
protocol... this is one way i'm doing it...)


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

RE: [PHP-DEV] [BUG] bugs.php.net bugs

[James Cox]

[EMAIL PROTECTED]

i _guess_ we can turn that into an ezmlm list but it's nice to be able
to monitor who's on it and be sure.. (incase sensitive info gets passed
around).

 -- james

> -Original Message-
> From: Marcus Borger [mailto:[EMAIL PROTECTED]]
> Sent: Friday, September 06, 2002 4:25 PM
> To: James Cox
> Cc: Rasmus Lerdorf; Markus Fischer; Dan Kalowsky; Devon O'Dell; php-dev
> Subject: RE: [PHP-DEV] [BUG] bugs.php.net bugs
>
>
> Just a thought:
> Why not make mail list for the websites and send a mail for those to
> that mailing list instead of letting the users report them?
>
> marcus
>
> At 17:22 06.09.2002, James Cox wrote:
> >agreed, although I can't do much to it, i have had a look.
> >
> >  -- james
> > >
> > > In our case, nobody would check the logs.  Easier to let
> users read them
> > > for us and let us know.  Sounds like something is fishy with
> the new MySQL
> > > 4 setup we are using on the new server.
> > >
> > > -Rasmus
> > >
> > > On Fri, 6 Sep 2002, Markus Fischer wrote:
> > >
> > > > Wait :) You mean even php.net doesn't follow the
> > > > recommendation to no display errors but log them into some
> > > > file or so ... ? :)
> > > >
> > > > On Fri, Sep 06, 2002 at 10:37:19AM -0400, Dan Kalowsky wrote :
> > > > > Yeah I've had this problem too since it's moved.  So far
> my answer has
> > > > > been to reload the page, and it goes away.  Although I've
> > > made mention of
> > > > > it to Derick and Jani.
> > > > >
> > > > > On Fri, 6 Sep 2002, Devon O'Dell wrote:
> > > > >
> > > > > > Hi All,
> > > > > >
> > > > > > I hope this is the right place to post this, I couldn't
> find a valid
> > > > > > place to put this on bugs.php.net.  Please correct me if
> > > this isn't the
> > > > > > right place.
> > > > > >
> > > > > > Browsing through the bug list, I sometimes get mysql errors when
> > > > > > browsing searching for bugs using the input field at
> the top right.
> > > > > >
> > > > > > The errors are as follows:
> > > > > >
> > > > > > Warning: mysql_numrows(): 4 is not a valid MySQL result
> resource in
> > > > > > /local/Web/sites/php-bugs-web/search.php on line 119
> > > > > >
> > > > > > and
> > > > > >
> > > > > > Warning: mysql_fetch_array(): 4 is not a valid MySQL result
> > > resource in
> > > > > > /local/Web/sites/php-bugs-web/search.php on line 139
> > > > > >
> > > > > > I've recieved this twice, once searching for "FreeBSD" and once
> > > > > > searching for "ming", however, it does not occur every
> > > time, and I've
> > > > > > not been able to successfully reproduce it (it happens
> > > always on accident)
> > > > > >
> > > > > > Additionally (while I'm thinking about it), whenever I try
> > > to search the
> > > > > > whole site on php.ca, I get an error stating:
> > > > > >
> > > > > >
> > > > > > *There was an error executing this query.*
> > > > > >
> > > > > > Please try later.
> > > > > >
> > > > > > You can see this at
> > > > > >
http://www.php.ca/search.php?show=nosource&pattern=something_stupid
> > > > >
> > > > > Feel free to substitute anything for something_stupid
> > (including valid
> > > > > php functions).
> > > > >
> > > > > Greetings,
> > > > >
> > > > > Devon O'Dell
> > > > >
> > > > >
> > > > >
> > > >
> > > > >---<
> > > > Dan Kalowsky  "A little less conversation,
> > > > http://www.deadmime.org/~dank a little more action."
> > > > [EMAIL PROTECTED] - "A Little Less Conversation",
> > > > [EMAIL PROTECTED]  Elvis Presley
> > > >
> > > >
> > > > --
> > > > PHP Development Mailing List <http://www.php.net/>
> > > > To unsubscribe, visit: http://www.php.net/unsub.php
> > >
> > > --
> > > GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc
> > > "In short, the window belongs to me.
> > >  The document belongs to the web site designer."
> > > - Poster on opera.wishlist
> > >
> > > --
> > > 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


--
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] [BUG] bugs.php.net bugs

[James Cox]

agreed, although I can't do much to it, i have had a look.

 -- james
>
> In our case, nobody would check the logs.  Easier to let users read them
> for us and let us know.  Sounds like something is fishy with the new MySQL
> 4 setup we are using on the new server.
>
> -Rasmus
>
> On Fri, 6 Sep 2002, Markus Fischer wrote:
>
> > Wait :) You mean even php.net doesn't follow the
> > recommendation to no display errors but log them into some
> > file or so ... ? :)
> >
> > On Fri, Sep 06, 2002 at 10:37:19AM -0400, Dan Kalowsky wrote :
> > > Yeah I've had this problem too since it's moved.  So far my answer has
> > > been to reload the page, and it goes away.  Although I've
> made mention of
> > > it to Derick and Jani.
> > >
> > > On Fri, 6 Sep 2002, Devon O'Dell wrote:
> > >
> > > > Hi All,
> > > >
> > > > I hope this is the right place to post this, I couldn't find a valid
> > > > place to put this on bugs.php.net.  Please correct me if
> this isn't the
> > > > right place.
> > > >
> > > > Browsing through the bug list, I sometimes get mysql errors when
> > > > browsing searching for bugs using the input field at the top right.
> > > >
> > > > The errors are as follows:
> > > >
> > > > Warning: mysql_numrows(): 4 is not a valid MySQL result resource in
> > > > /local/Web/sites/php-bugs-web/search.php on line 119
> > > >
> > > > and
> > > >
> > > > Warning: mysql_fetch_array(): 4 is not a valid MySQL result
> resource in
> > > > /local/Web/sites/php-bugs-web/search.php on line 139
> > > >
> > > > I've recieved this twice, once searching for "FreeBSD" and once
> > > > searching for "ming", however, it does not occur every
> time, and I've
> > > > not been able to successfully reproduce it (it happens
> always on accident)
> > > >
> > > > Additionally (while I'm thinking about it), whenever I try
> to search the
> > > > whole site on php.ca, I get an error stating:
> > > >
> > > >
> > > > *There was an error executing this query.*
> > > >
> > > > Please try later.
> > > >
> > > > You can see this at
> > > > http://www.php.ca/search.php?show=nosource&pattern=something_stupid
> > > >
> > > > Feel free to substitute anything for something_stupid
> (including valid
> > > > php functions).
> > > >
> > > > Greetings,
> > > >
> > > > Devon O'Dell
> > > >
> > > >
> > > >
> > >
> > > >---<
> > > Dan Kalowsky  "A little less conversation,
> > > http://www.deadmime.org/~dank  a little more action."
> > > [EMAIL PROTECTED]  - "A Little Less Conversation",
> > > [EMAIL PROTECTED]  Elvis Presley
> > >
> > >
> > > --
> > > PHP Development Mailing List 
> > > To unsubscribe, visit: http://www.php.net/unsub.php
> >
> > --
> > GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc
> > "In short, the window belongs to me.
> >  The document belongs to the web site designer."
> > - Poster on opera.wishlist
> >
> > --
> > 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
>
>


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

RE: [PHP-DEV] RE: [PHP-CVS] cvs: php4 /ext/xml xml.c

[James Cox]

Marcus pretty much got it..

sorry, php.net mail is broken again.

but if you look over your php-cvs mail, Derick has pointed out a number of
issues.

 --  james

> -Original Message-
> From: Ananth Kesari [mailto:[EMAIL PROTECTED]]
> Sent: Friday, September 06, 2002 2:23 PM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: [PHP-DEV] RE: [PHP-CVS] cvs: php4 /ext/xml xml.c
>
>
> Hi,
>
> I am working on porting PHP for NetWare.
> I am committing changes into the PHP CVS
> source tree from a couple of days now.
> James wrote to me today that I am doing
> something wrong during commiting.
> I wrote the below mail to him seeking clarifications,
> but the mail bounced back!
>
> Can anyone throw more light into this?
>
> Thanks in advance,
> Ananth.
>
> >>> Ananth Kesari 09/06/02 05:19PM >>>
> Hi,
>
> What I am doing is that I got the latest PHP4 project
> from CVS. Then applied only NetWare related
> changes into some files within #ifdef NETWARE
> blocks and then committed them. I did not change
> any other things like header information, licences etc.
> Of course, I added a couple of files under NetWare
> folder that is being used for NetWare.
>
> So, is there anything specific that you can tell me
> which I am doing wrong? In fact, myself and one of my
> colleagues have committed some changes earlier
> the same way as I am doing now. Before we started
> to commit changes, we had gone through
> http://www.php.net/cvs-php.php and other related
> document. Is there something else we need to know?
>
> Please clarify.
>
> Thanks,
> Ananth.
>
> >>> "James Cox" <[EMAIL PROTECTED]> 09/06/02 04:03PM >>>
> Hi,
>
> Please read PHP-CVS!
>
> You are making a large number of commits that conflict with our policies,
> including adding files with strange licenses and not adhering to our
> whitespace policy.
>
> Please do not commit again until you have addressed the concerns expressed
> on-list.
>
> Thanks,
>
>  James
>
> > -Original Message-
> > From: Anantha Kesari H Y [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, September 06, 2002 11:21 AM
> > To: [EMAIL PROTECTED]
> > Subject: [PHP-CVS] cvs: php4 /ext/xml xml.c
> >
> >
> > hyanantha   Fri Sep  6 06:20:39 2002 EDT
> >
> >   Modified files:
> > /php4/ext/xml   xml.c
> >   Log:
> >   NetWare related changes/modifications
> >
> >
> > Index: php4/ext/xml/xml.c
> > diff -u php4/ext/xml/xml.c:1.107 php4/ext/xml/xml.c:1.108
> > --- php4/ext/xml/xml.c:1.107Sat Apr 13 01:06:33 2002
> > +++ php4/ext/xml/xml.c  Fri Sep  6 06:20:39 2002
> > @@ -17,7 +17,7 @@
> >
> > +--+
> >   */
> >
> > -/* $Id: xml.c,v 1.107 2002/04/13 05:06:33 mfischer Exp $ */
> > +/* $Id: xml.c,v 1.108 2002/09/06 10:20:39 hyanantha Exp $ */
> >
> >  #define IS_EXT_MODULE
> >
> > @@ -35,7 +35,8 @@
> >
> >  #if HAVE_LIBEXPAT
> >
> > -#ifndef PHP_WIN32
> > +/*#ifndef PHP_WIN32*/
> > +#if !defined(PHP_WIN32) && !defined(NETWARE)
> >  #  include "build-defs.h"
> >  # endif
> >  # include "ext/standard/head.h"
> >
> >
> >
> > --
> > PHP CVS 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] http://www.php-con.com/

[James Cox]

Andrey,

this has nothing to do with php-dev ...

php-dev is just for the development of PHP ... as in, PHP internals...


 -- james

> -Original Message-
> From: Andrey Hristov [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, September 05, 2002 1:53 PM
> To: [EMAIL PROTECTED]
> Subject: [PHP-DEV] http://www.php-con.com/
>
>
> Hi,
> can someone change the HTML of http://www.php-con.com/ and add
> bgcolor="#FF" in the  tag.
> My default theme is with gray font so the page is not looking so nice :)))
>
> Andrey
>
>
>
>
> --
> 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] Re: mbstring

[James Cox]

So,

lets summarize what we got out of this...

-- mbstring is a very useful part of PHP and should be integrated properly
into ext/standard .

-- mbstring-enc-trans has some issues, but that's ok because you can't
disable-and-not-build it at build time now

-- having default packages is ok, but we need some method of being able to
'clear' the list (or enable them all)

-- we need some kind of documentation about default packages... I might be
able to spend some time on that.

 -- anything else?

 james


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

RE: [PHP-DEV] Re: mbstring

[James Cox]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, September 03, 2002 7:51 AM
> To: James Cox
> Cc: Rui Hirokawa; [EMAIL PROTECTED]
> Subject: RE: [PHP-DEV] Re: mbstring
>
>
> On Tue, 3 Sep 2002, James Cox wrote:
>
> > >
> > > No, this option is 'disabled' by default, and can be enabled by a
> > > ini variable.
> > >
> > > mbstring.encoding_translation = Off; is default.
> > >
> > > If mbstring.encoding_translation = On is set in php.ini,
> > > the transparent conversion will be enabled.
> > >
> > ok, but before, you had to --enable it before it'd work? or did
> it get built
> > _EVERY_ time regardless?
>
> Does it matter? ini settings are much easier to notice during debugging
> than #ifdefs, so I think Rui made an excellent choice here. However,
> some documentation of these settings would be useful (hint :).
>
well, the mbstring-enc-trans stuff is what seems to have caused the issues
before, so having it built in might not be a great idea. Besides, it just
increases the base binary size, which makes life harder for people trying to
embed php.

> >
> > [snip]
> > > Yes, I think mbstring is very fundamental feature and it should
> > > be built-in
> > > feature (in PHP 5.0).
> > > But, string related functions and some other core functions
> > > are included in ext/standard which is also in extension part.
> > >
> >
> > sure, ext/standard works... we just need to lose the duplication.
>
> You obviously have no idea what mbstring exactly does, as this comments
> makes little sense. mbstring _overloads_ functions which are in
> ext/standard (such as strpos() ). That is a little bit too much magic,
> and thus I like to see the mbstring functions merged into the
> ext/standard functions (for PHP 5).
>
Sorry, that's what i meant: to move ext/mbstring overloading stuff into it's
rightful place, rather than duplicating the code.


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

RE: [PHP-DEV] Re: mbstring

[James Cox]

>
> No, this option is 'disabled' by default, and can be enabled by a
> ini variable.
>
> mbstring.encoding_translation = Off; is default.
>
> If mbstring.encoding_translation = On is set in php.ini,
> the transparent conversion will be enabled.
>
ok, but before, you had to --enable it before it'd work? or did it get built
_EVERY_ time regardless?

[snip]
> Yes, I think mbstring is very fundamental feature and it should
> be built-in
> feature (in PHP 5.0).
> But, string related functions and some other core functions
> are included in ext/standard which is also in extension part.
>

sure, ext/standard works... we just need to lose the duplication.


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

RE: [PHP-DEV] Re: mbstring

[James Cox]

>
> I think that the problem is caused by
> --enable-mbstr-enc-trans option and is not caused by mbstring itself.
>
> If --enable-mbstr-enc-trans is enabled,
> php_treat_data, the original handler of user input (POST/GET/Cookie),
> is overrided by mbstr_treat_data in ext/mbstring ,
> the multibyte enabled version.
>
> mbstr_treat_data had a GET handling bug in PHP 4.2.x/PHP 4.1.x.
> Although the bug was already fixed in CVS,
> but mbstr_treat_data is not used by non multibyte user.
>
> So, I abolished --enable-mbstr-enc-trans option in CVS,
> and made a new php.ini option 'mbstring.encoding_translation',
> which is the equivalent of --enable-mbstr-enc-trans,
> and which is 'Off' by default.

so this is now always on, but controlled by an ini variable? that doesn't
sound very good. maybe i'm being paranoid, but it seems to me that you've
just enabled it by default (at build time).
>
> I think the user input (POST/GET/Cookie) related problem
> for non-multibyte user will completely disappeer with this change.
>
> And,
> the mbstring should be 'enabled' by default.
> I18N of PHP is very important for especially multibyte PHP users.
> [snip]
> I agree with Zeev, the simplicity of development work is important.
> So, the duplicate code of the user input handler should be merged
> with the original handler in PHP 5.0.
>

I agree -- it's very useful.. but i don't think it should exist as an
extension, but built in.. the extension just now seems a really messy way of
doing it.

 -- james


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

RE: [PHP-DEV] Default extensions (was: mbstring)

[James Cox]

> Unfortunately we don't live in a perfect world where
> sysadmins know how to read and listen to their users
> requests. That's why mysql for example is enabled by default.
> (or that's the main reasoning behind it at least)
>
> And we can't educate people or force them to anything either.
>
> Maybe we should add a general '--disable-all' option?
>

i'm +1 for that if it means that first it disables everything, and then you
enable stuff bit by bit...

i still don't see why we shouldn't just disable everything by default and
write a 'default configure' script...

 -- james


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

RE: [PHP-DEV] mbstring

[James Cox]

>
> At 22:52 02/09/2002, Dan Kalowsky wrote:
> >On Mon, 2 Sep 2002, Yasuo Ohgaki wrote:
> >
> > > If we should reduce number of modules built by default, 1st
> > > module should be MySQL. Removing MySQL does not cause any
> > > technical problems at all.
> >
> >I'll agree to that as well.  +1 on removing --with-mysql as a default.
> >Although realize I'm also +1 on removing any default modules that are not
> >essential to PHP's running.
>
> -1
>
Nice to see you argue that one so eloquently...

 -- james


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

RE: [PHP-DEV] wassup with master.php

[James Cox]

yes, we're working on it..

 -- james
>
> I assumed, I asked if someone where working on it to set it up back...
>
> --
> Merci de nous avoir choisi. - Thanks you for your choice.
> Nicos - CHAILLAN Nicolas
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
> www.GroupAKT.com - Hébergement Group.
> www.WorldAKT.com - Hébergement de sites Internet
> "James Cox" <[EMAIL PROTECTED]> a écrit dans le message de news:
> [EMAIL PROTECTED]
> > if you'd been paying attention, you would have noticed that the machine
> it's
> > on is down right now.
> >
> >  -- james
> >
> > >
> > > Hi,
> > >
> > > is someone working on master.php.net or what?
> > >
> > > --
> > > Merci de nous avoir choisi. - Thanks you for your choice.
> > > Nicos - CHAILLAN Nicolas
> > > [EMAIL PROTECTED]
> > > [EMAIL PROTECTED]
> > > www.GroupAKT.com - Hébergement Group.
> > > www.WorldAKT.com - Hébergement de sites Internet
> > >
> > >
> > >
> > > --
> > > 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] wassup with master.php

[James Cox]

if you'd been paying attention, you would have noticed that the machine it's
on is down right now.

 -- james

>
> Hi,
>
> is someone working on master.php.net or what?
>
> --
> Merci de nous avoir choisi. - Thanks you for your choice.
> Nicos - CHAILLAN Nicolas
> [EMAIL PROTECTED]
> [EMAIL PROTECTED]
> www.GroupAKT.com - Hébergement Group.
> www.WorldAKT.com - Hébergement de sites Internet
>
>
>
> --
> 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] Problem with http://php.net

[James Cox]

> >> 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]
>
>

Where the hell did that come from? :)


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

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

[James Cox]

> Back to the topic...
>
> When will the MX be up again?
>

The box actually hasn't died yet. SSH and SMTP are open, and seem to be
listening -- it is possible to make a connection to them.

For some reason however... ssh doesn't auth, and then times out... so there
are probably a bunch of defunct processes hanging about.

Syancor should be at work in about 2 hours or so.. (i believe they are west
coast). We should see the box start again then.

I am in the understanding that there is a plan to ditch this box ASAP, and
so we'll move the mx/master capabilities to pair2.php.net, and move the
various sites to rack1.php.net with it's bandwidth limitations.

 -- james


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

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

[James Cox]

> > This goes to everyone who has root or sudo on the boxes.. for 
> example i'll
> > get paged if something gets broken. This should guarentee a faster
> response
> > time (although, php-dev works too :))
> 
> Wow. I guess your pager does not stand still a second then... :)
> 
Well, it works as a good vibrator.. no, systems stuff isn't that busy...

 -- james

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

RE: [PHP-DEV] mbstring

[James Cox]

>
> On Mon, 2 Sep 2002, James Cox wrote:
>
> JC>>> Still, I think it makes more sense to enable, not disable.
> What extensions are enabled by default anyhow?  I am not aware of
> a list. Perhaps that's why i get odd errors when working with
> php, because there are extensions i didn't expect built in.
>
> ./configure --help | egrep -- '--(without|disable)'
>
> exception to the rule being mysql.
>

Yes. It was a rhetorical question -- i wonder if this is worth another page
in the manual?

 james


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

RE: [PHP-DEV] mbstring

[James Cox]

> > As I see it, PHP was designed with speed and simplicity in 
> mind. Having the
> > burden of a large number of extra modules compiled in by default doesn't
> > help, and deviates from this path.
> 
> No, you can always disable those extensions.  The default extensions were
> *voted* in for a reason.
>

Still, I think it makes more sense to enable, not disable. What extensions are enabled 
by default anyhow?  I am not aware of a list. Perhaps that's why i get odd errors when 
working with php, because there are extensions i didn't expect built in.
 
> > Compiling modules by default which are
> > buggy just compounds the problem.
> 
> Yes, but the bug was only present in an advanced optional feature 
> that would
> cause "unexpected behaviour" for non-mbstring aware people anyway.
> *and it has already been fixed a number of weeks ago*
> 
> As I've said, mbstring is very stable in it's default configuration - the
> codebase has been around for years and tested to death by a very dedicated
> i18n team *in production*.
> 
> The "development" you keep referring to is part of a streamable filter
> *add-on* that does not change the existing code that people rely on.
> 
maybe i'm jaded against mbstring here, but i experienced two unexpected crashes which 
i traced back to mbstring, but with no real cause that i could find, as well as 
watching the cvs commits -- and also wondering why on earth they feel they want to 
work on mbstring @ sf.jp. CVS is quite capable of maintaining code (hence branches).

> Why don't you test the current CVS to see if it still has a problem,
> if it does, lets fix it.
> 
I will do that.

> Please don't take a step backwards by disabling this extension by default
> just because you are afraid that people can abuse advanced options.

I'm not taking a step backwards, just trying to remove the potential for confusion. If 
people think that register_globals is confusing, and causes issues, then we should 
also not build stuff by default. I *HATE* it when I don't know what's being built.


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

[PHP-DEV] RE:

[James Cox]

> -Original Message-
> From:
> Sent: None
> Subject:
>
>
> Date: Mon, 2 Sep 2002 06:42:15 -0500 (EST) From: "Sterling
> Hughes" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> In-Reply-To: <[EMAIL PROTECTED]>
> References: <[EMAIL PROTECTED]>
> X-Priority: 3 Importance: Normal X-MSMail-Priority: Normal Cc:
> <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED]
> X-Mailer: SquirrelMail (version 1.2.4) MIME-Version: 1.0
> Content-Type: text/plain; charset=iso-8859-1
> Content-Transfer-Encoding: 8bit Subject: RE: [PHP-DEV] mbstring
>  > Wez, > > lets loose the crap here. I am happy to see mbstring
> in PHP! I have > used it too, when I needed multibyte support. >
> James,  Let's stay consistent here.  Your opinion changes more
> than Microsoft's .NET strategy...  In your original message you
> stated that you wanted to remove mbstring.

no, i've never wanted to remove mbstring, i just would like to see it not
enabled by default.

 If you've changed
> your opinion fine, but don't chide Wez for responding to the
> opinion so forcefully expressed in your original message.
> Furthermore, you've said that you've never used mbstring
> extension and that mbstring is certainly not a gold extension in
> prior messages, what do you think Wez is going to respond too?

no i have used it, and yes, it's a useful extension, my point is that it's
not a gold extension, and thus shouldn't be enabled by default.


>
> But you see, it's not really all that solid. It needs more work
> (hence > this apparent development outside of php.net). All I am
> saying is that > we should disable it by default in current
> releases. For PHP5, we > should have proper mbstring support that
> should probably also be > transparent; by that I mean I see no
> reason for it not to be as > standard functionality rather than
> an extension, if that is necessary. >  _Every_ extension needs
> more work, a redesign, etc.  The mbstring extension minus perhaps
> some of the newer features is quite solid, much more so than many
> of the other standard php extension (for example, xml and
> domxml), its being redesigned and reworked -- that's true, but
> that is imho just a matter of evolution and improvement.

xml/domxml aren't enabled by default.

> I
> will let Phil know that he can update his errata to just removing
> the > one compile option -- however, he demonstrates a valid
> point: > unexpected behaviour sucks. This includes the building
> of modules that > you don't need. >  Yes, unexpected behaviour
> does suck, but this is not unexpected...  if you explicitly
> _enable_ a configuration option, and then it yields a certain
> documented behaviour, I would hardly call that unexpected...

actually, Phil removed the --enable-mbstring configure option too --
_expecting_ mbstring not to be enabled anymore, hence my issue.

  >
> if it were me, i'd rather just be able to build the bare-bones
> PHP > binary without an extensions, and compile others in as i
> needed them. > By enabling extensions by default, what you end up
> doing is increasing > the size of the end product... now that, in
> most cases, doesn't make a > difference, however for scenarios
> where you have very little space to > play with... having
> extensions compiled in by default that you don't > know about
> sucks. > > if we want to do some kind of auto-compile thing, then
> perhaps a script > which detects-and-compiles every extension
> could get stuck in /php4 for > those who were really lazy. > > As
> I see it, PHP was designed with speed and simplicity in mind.
> Having > the burden of a large number of extra modules compiled
> in by default > doesn't help, and deviates from this path.
> Compiling modules by default > which are buggy just compounds the
> problem. >  As Zeev stated this doesn't really hurt speed,
> actually what you're suggesting would provide a larger speed hit
> (although not signifigant) than the current situation.  As far as
> compiling in buggy modules -- yes, of course, that's stating the
> obvious.  However mbstring is certainly not that buggy, unless
> you enable a further option, and that's debatable.  From reading
> Wez's message, I really don't see a reason to unbundle/unenable
> it -- as long as new development doesn't cause a new api
> (backwards compat), i wasn't aware before that it didn't cause
> any bc issues.  I don't know how many people remember the
> bundling of XML with PHP4, but there were _quite_ a few kinks
> with that integration, causing segfaults and unexpected behaviour
> (especially when dealing with objects).  When bundling a new
> extension, you should always expect a few kinks, with mbstring it
> seems that there are less than usual (we also had major problems
> with MySQL integration by the way...)  -Sterling
> --

sure, which is why it should be tested fully before enabled by default.

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


-- 
PHP

RE: [PHP-DEV] mbstring

[James Cox]

> At 13:19 02/09/2002, James Cox wrote:
> >As I see it, PHP was designed with speed and simplicity in mind.
> 
> It was indeed..
> 
> >Having the burden of a large number of extra modules compiled in by 
> >default doesn't help, and deviates from this path.
> 
> Not really.  Speed-wise, adding modules has a negligible effect.  
> As far as 
> simplicity goes, we're talking about simplicity for the 
> developer.  Bundling features does make things simpler for the 
> majority of 
> the target audience.
> 
> >  Compiling modules by default which are buggy just compounds 
> the problem.
> 
> I obviously agree with that.  I do want to see mbstring become an 
> integrated part of PHP, but not a moment sooner than when it is stable.
> 

exactly..

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

RE: [PHP-DEV] mbstring

[James Cox]

Wez,

lets loose the crap here. I am happy to see mbstring in PHP! I have used it too, when 
I needed multibyte support.

But you see, it's not really all that solid. It needs more work (hence this apparent 
development outside of php.net). All I am saying is that we should disable it by 
default in current releases. For PHP5, we should have proper mbstring support that 
should probably also be transparent; by that I mean I see no reason for it not to be 
as standard functionality rather than an extension, if that is necessary.

I will let Phil know that he can update his errata to just removing the one compile 
option -- however, he demonstrates a valid point: unexpected behaviour sucks. This 
includes the building of modules that you don't need.

if it were me, i'd rather just be able to build the bare-bones PHP binary without an 
extensions, and compile others in as i needed them. By enabling extensions by default, 
what you end up doing is increasing the size of the end product... now that, in most 
cases, doesn't make a difference, however for scenarios where you have very little 
space to play with... having extensions compiled in by default that you don't know 
about sucks.

if we want to do some kind of auto-compile thing, then perhaps a script which 
detects-and-compiles every extension could get stuck in /php4 for those who were 
really lazy.

As I see it, PHP was designed with speed and simplicity in mind. Having the burden of 
a large number of extra modules compiled in by default doesn't help, and deviates from 
this path. Compiling modules by default which are buggy just compounds the problem.


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

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

[James Cox]

also,

if you have any issues with php.net servers/services, send mail to
[EMAIL PROTECTED]

This goes to everyone who has root or sudo on the boxes.. for example i'll
get paged if something gets broken. This should guarentee a faster response
time (although, php-dev works too :))

 -- james

> -Original Message-
> From: James Cox [mailto:[EMAIL PROTECTED]]
> Sent: Monday, September 02, 2002 9:53 AM
> To: Andrey Hristov; [EMAIL PROTECTED]
> Subject: RE: [PHP-DEV] Problem with http://php.net
>
>
> some of the httpd processes went defunct (also, because rotatelogs did) .
>
> http://www.php.net/server-status -- works now. :)
>
>  -- james
>
> > -Original Message-
> > From: Andrey Hristov [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, September 02, 2002 9:39 AM
> > To: Andrey Hristov; [EMAIL PROTECTED]
> > Subject: Re: [PHP-DEV] Problem with http://php.net
> >
> >
> > Too much downloads
> >
> > Best regards
> > Andrey Hristov
> >
> >
> > - Original Message -
> > From: "Andrey Hristov" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Sent: Monday, September 02, 2002 11:35 AM
> > Subject: [PHP-DEV] Problem with http://php.net
> >
> >
> > > Hi,
> > > maybe offtopic but I cannot access php.net . I thought that
> it is maybe
> > > problem with my connection so tried http://network-tools.com to
> > fetch the
> > > headers and teh result is timeout.
> > >
> > >
> > > Best regards
> > > Andrey Hristov
> > >
> > >
> > >
> > >
> > > --
> > > 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
>
>


-- 
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

[James Cox]

some of the httpd processes went defunct (also, because rotatelogs did) .

http://www.php.net/server-status -- works now. :)

 -- james

> -Original Message-
> From: Andrey Hristov [mailto:[EMAIL PROTECTED]]
> Sent: Monday, September 02, 2002 9:39 AM
> To: Andrey Hristov; [EMAIL PROTECTED]
> Subject: Re: [PHP-DEV] Problem with http://php.net
> 
> 
> Too much downloads
> 
> Best regards
> Andrey Hristov
> 
> 
> - Original Message - 
> From: "Andrey Hristov" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Monday, September 02, 2002 11:35 AM
> Subject: [PHP-DEV] Problem with http://php.net
> 
> 
> > Hi,
> > maybe offtopic but I cannot access php.net . I thought that it is maybe
> > problem with my connection so tried http://network-tools.com to 
> fetch the
> > headers and teh result is timeout.
> > 
> > 
> > Best regards
> > Andrey Hristov
> > 
> > 
> > 
> > 
> > -- 
> > 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
> 
> 

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

RE: [PHP-DEV] mbstring

[James Cox]

Derick pretty much said it for me... but more explicitly,

mbstring isn't stable enough to be default.

-- james

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
> Sent: Monday, September 02, 2002 6:41 AM
> To: Masaki Fujimoto
> Cc: James Cox; Wez Furlong; Php-Dev
> Subject: Re: [PHP-DEV] mbstring
>
>
> On Mon, 2 Sep 2002, Masaki Fujimoto wrote:
>
> > Hi,
> >
> > let me vote not to remove mbstring (as a default one).
>
> I'd vote for setting it off by default _for now_, and enable it after
> 4.3. has branched, so we have a kick ass i18n solution in PHP5 replacing
> all code it duplicates.
>
> > yes, I can understand the thought that singlebyte users seem mbstirng
> > module is somehow 'extra' one.
> >
> > but please understand that this module is indispensable for multibyte
> > users (at least), and AFAIK there are growing numbers of multibyte users
> > of PHP. we japanese, korean and chinese have to handle 3 (or more) types
> > of encoding (+ UNICODE), and we cannot even count number characters (not
> > bytes) w/out mbstring.
> >
> > besides, I (we?) always make best effort that multibyte features do not
> > harm any other ones, and if it causes bugs, we (Yasuo, Rui or I) will
> > fix it ASAP (maybe:).
>
> Too bad that you can't predict anything.
>
> >
> > of course we can --enable-mbstring even if msbstirg is disabled by
> > default, but please remember that not all the users can always exec
> > 'configure' and edit php.ini. (use dl() ? hmm...)
>
> Every respectable sysadm in eastern countries installing PHP should be
> aware fo this and enable mbstring for his users.
>
> >
> > finally, it is true that mbstring is not the 'golden bullet':), but it
> > would be far better if we have some kind of bullets, isn't it ?
>
> Derick
>
> --
> -
>  Did I help you?   http://www.derickrethans.nl/link.php?url=giftlist
>  Frequent ranting: http://www.derickrethans.nl/
> --
> -
>  PHP: Scripting the Web - [EMAIL PROTECTED]
> All your branches are belong to me!
> SRM: Script Running Machine - www.vl-srm.net
> --
> -
>
>
> --
> 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

[James Cox]

> > So I want to 'disable' it by default. If you want encoding,
> just enable it. But you're right, i've never needed to create a
> truely globalized/localized app. (and from general principles, if
> you feel you need to localize any more than your ui/strings.)
> >
>
> That's not what I read, perhaps you can just double clarify this -- you
> do not at all want to remove mbstring from PHP (and move it say, to
> pear)...
>
> If this is correct, than I'm +1, otherwise I'm -1.  Mbstring is very
> important when it comes to creating i18n applications.  Also, you seem
> to forget that PHP is not only used in England, but other areas where it
> is _quite_ important, and _quite_ necessary.
>

Erm, i'm quite aware of it's global presense.. but you got it right... i
don't care about if it exists as an extension -- actually, yes i do, it
should be a big bonus for us once it's stable -- i just don't think it
should be enabled by default. This seems to cause end-users (and downstream
developers like RedHat) huge issues. Let's not enable it by default now, and
when it's more stable, (say, PHP5 time) we can re-enable it. Who knows, it
might serve as a good extra carrot. :)

 -- James


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

RE: [PHP-DEV] mbstring

[James Cox]

> > I vote to remove mbstring as a default module.
> 
> I guess you have never tried to create a truely globalized/localized
> application then?
> 
> I'm -1 on removing it, because PHP needs a consistent charset encoding
> API that is portable across platforms. iconv and recode are "no good"
> because their supported charsets vary from system to system and version
> to version; some libraries actually have broken encoding tables
> 

Wez, let me rephrase:

mbstring isn't a "gold" module which should be enabled by default.

That is, it's still -- as i see it -- just a bit more than experimental. mbstring work 
is being done on sourceforge! 

So I want to 'disable' it by default. If you want encoding, just enable it. But you're 
right, i've never needed to create a truely globalized/localized app. (and from 
general principles, if you feel you need to localize any more than your 
ui/strings.)

 -- james


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

RE: [PHP-DEV] mbstring

[James Cox]

 
> I do have one request, when the time comes to remove it from the 
> default also change the PHP core code so that it can be built as a 
> shared extension and loaded on the fly.  Currently it can only be 
> compiled into PHP statically and building it as .so means hacking the 
> PHP source and the mbstring module (which I have already done with a 
> small patch).
> 
Where is your patch?

 -- james

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

[PHP-DEV] mbstring

[James Cox]

Phil Copeland @ redhat pointed me at this bug:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=72752

Seems that there are a number of issues (i'm going to verify & patch his
fixes right now).

The other he mentions is mbstring seems to cause problems. I have
experienced this too.

Guys, i don't want to be mean or sound racist or anything else you throw at
me.

But mbstring really isn't a core module, and very few people will require
kr/zh/ru style encoding.

I vote to remove mbstring as a default module.

And for those who say that i could just disable it -- well, the converse is
true. Let us STOP burdening default builds with crap that is unlikely to be
used.

 -- james
--
James Cox :: [EMAIL PROTECTED] :: http://james.blogs.at/
Was I helpful?  http://www.amazon.co.uk/exec/obidos/wishlist/23IVGHQ61RJGO/


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

[PHP-DEV] I'm Back

[James Cox]

For those who may be interested, I am back from my trip to California, and
am going through mails.


 --James

--
James Cox :: [EMAIL PROTECTED] :: http://james.blogs.at/
Was I helpful?  http://www.amazon.co.uk/exec/obidos/wishlist/23IVGHQ61RJGO/


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

Re: [PHP-DEV] Accounts on Alpha/Tru64

[James Cox]

"Sebastian Nohn" <[EMAIL PROTECTED]> wrote:
> I'm currently trying to get a machine for testing PHP on Tru64/Alpha.
> Anyone who is _really_ interested in testing AND hunting bugs on that
> platform should drop me a mail.

http://www.testdrive.compaq.com/
___
This mail sent using V-webmail - http://www.v-webmail.co.uk


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

RE: [PHP-DEV] [Win32] php.ini not found

[James Cox]

does php-cli.ini exist anywhere?

 -- james

> -Original Message-
> From: Sebastian Bergmann [mailto:[EMAIL PROTECTED]]
> Sent: Friday, August 09, 2002 5:52 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [PHP-DEV] [Win32] php.ini not found
> 
> 
> Sebastian Bergmann wrote:
> > Using strace I found out out that my build tries to open the php.ini
> > file in an invalid directory:
> >
> >   662 2012 436 NtCreateFile (0x80100080, {24, 0, 0x42, 0, 1243384,
> >   "\??\C:\home\php\php4\Release_TS_Inline\C:\WINNT\php-cli.ini"},
> >   1243404, 0, 128, 3, 1, 96, 0, 0, ... ) == STATUS_OBJECT_NAME_INVALID
> >
> >   664 2012 436 NtCreateFile (0x80100080, {24, 0, 0x42, 0, 1243400,
> >   "\??\C:\home\php\php4\Release_TS_Inline\C:\WINNT\php.ini"}, 1243420,
> >   0, 128, 3, 1, 96, 0, 0, ... ) == STATUS_OBJECT_NAME_INVALID
> 
>   Forgot to post the strace output for the snapshot binary that works for
>   me:
> 
> 662 260 1956 NtCreateFile (0x80100080, {24, 0, 0x42, 0, 1243380, 
> "\??\c:\php-cli.ini"}, 1243400, 0, 128, 3, 1, 96, 0, 0, ... ) == 
> STATUS_OBJECT_NAME_NOT_FOUND
> 
> 664 260 1956 NtCreateFile (0x80100080, {24, 0, 0x42, 0, 1243380, 
> "\??\C:\WINNT\php-cli.ini"}, 1243400, 0, 128, 3, 1, 96, 0, 0, ... )
> == STATUS_OBJECT_NAME_NOT_FOUND
> 
> 666 260 1956 NtCreateFile (0x80100080, {24, 0, 0x42, 0, 1243396, 
> "\??\c:\php.ini"}, 1243416, 0, 128, 3, 1, 96, 0, 0, ... ) == 
> STATUS_OBJECT_NAME_NOT_FOUND
> 
> 668 260 1956 NtCreateFile (0x80100080, {24, 0, 0x42, 0, 1243396, 
> "\??\C:\WINNT\php.ini"}, 1243416, 0, 128, 3, 1, 96, 0, 0, ... 136, )
> == 0x0
> 
> -- 
>   Sebastian Bergmann
>   http://sebastian-bergmann.de/ http://phpOpenTracker.de/
> 
>   Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/
> 
> -- 
> 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] 0 size snaps?

[James Cox]

This should be fixed.

 -- James

> Sebastian Nohn schrieb:
> 
> > http://snaps.php.net/php4-200207311500.tar.gz
> > http://snaps.php.net/php4-200207311500.tar.bz2
> > 
> > And alle the -latested + the last STABLE Files have 0
> > size.
> 
> The snaps are still broken and the last one is still from 07/31/2002
> 
> Regards, Sebastian Nohn
> -- 
> [EMAIL PROTECTED] - http://nohn.net/
> 
> -- 
> 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] Scripts running on two different browsers crashes the server

[James Cox]

> Please note that I am using the PHP development version 4.0.8.
> 
Ananth,
 
Can I ask why you guys are using such an old version of PHP?

Thanks,

 James

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

[PHP-DEV] RE: [PHP-QA] RE: [PHP-DEV] RE: [PHP-QA] PHP 4.2.3RC1 ?

[James Cox]

> Following that, why not do what a number of people do, and do
>
> major.minor.patch
>
> major releases say every 6 months
> minor ones every 2 - unless serious patch required
> patches as required
>
> This allows people to predict the times also.
>
i would see this working, given it's what we do already. but more
specifically, following the apache method of posting patch files when
something gets fixed, so people can search the directory and find patches
that will fix their problem. See http://www.apache.org/dist/httpd/patches/.

James


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

[PHP-DEV] RE: [PHP-QA] RE: [PHP-DEV] RE: [PHP-QA] PHP 4.2.3RC1 ?

[James Cox]

 the large amount of time between the branches.
>
> Yes. That may be. But there are a lot of bugfixes in the latest
> STABLE-snapshot I tested (26/07/02) - or exactly: All bugs I experienced
> were fixed. So the easiest thing would be to cancel all new features that
> were planned for 4.2.3 and move them to 4.3.0 and apply all patches that
> have been fixed in the last STABLE-snapshot and do a quick release process
> (no new features, no or at least few new problems).
>

we released 4.2.2 less than a week ago. If we release any new package within
2weeks to a month, i feel it'll just infuriate system admins more. People
don't want to be installing new packages every week for the same product.

Of all the complaints i hear about PHP, one of the biggest is the frequency
of packages; it's too much for people to cope with.

I suggest that if you want fixes, use snapshots or cvs... and we release
packages every few months which have been QA tested and are fit for
production use.

 -- James


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

RE: [PHP-DEV] beginner question: how to execute unix command in PHP

[James Cox]

>
> Hi, I'm just starting to learn PHP.  I couldn't find how to exec unix
> command and read the result.  Basically, I just want to execute "ls -lrt"
> and read and display the output.
>
> This may be very simple question, but for some reason, I couldn't find any
> info on executing unix command from PHP.
>
> Thanks.
>

seriously, did you read the manual?

php.net/exec
php.net/system
php.net/passthru

or, simply put, perl style, $foo = `ls -lrt`;

finally. please use [EMAIL PROTECTED] for these types of posts.

 -- James


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

RE: [PHP-DEV] Re: [PHP] Re: PHP Security Advisory: Vulnerability in PHP versions 4.2.0 and 4.2.1

[James Cox]

> On Mon, 22 Jul 2002, Rouvas Stathis wrote:
> 
> > Hi all,
> > 
> > Just wanting to notify everyone that
> > the link for the PHP.4.2.2 download is broken.
> 
> From which mirror, and how does your link look like?
> 
it's fixed.
 

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

RE: [PHP-DEV] CVS Account Request: bobo

[James Cox]

Actually,

Jason will be a primary contact at Rackshack for us (providing a new
server), so is signing up to be able to help us out (and so he has a email
address for peopel to mail him about this too).

he just got in a bit early. :)

 -- james

>
> James Cox said I should sign up for one, since Rackshack.net is
> going to be hosting your new server, and It will be easier to do
> some serverside admining this way
>
> --
> 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] "MYSQL_UNIX_ADDR" redefined

[James Cox]

>
>   After updating to autoconf 2.53 I get the following warnings:
>
> sb@wopr-mobile:/usr/src/php4> ./buildconf
> using default Zend directory
> buildconf: checking installation...
> buildconf: autoconf version 2.53 (ok)
> buildconf: automake version 1.5 (ok)
> buildconf: libtool version 1.4.2 (ok)
> rebuilding configure
> rebuilding main/php_config.h.in
> WARNING: Using auxiliary files such as `acconfig.h', `config.h.bot'
> WARNING: and `config.h.top', to define templates for `config.h.in'
> WARNING: is deprecated and discouraged.
>
[ ... ]

this is a problem when all of your different buildtools are either in
different locations or out of date.

which [autoconf|automake|libtool] and versions of?

this stuff sucks, because it's never really in tune with everything...

 -- james


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

RE: [PHP-DEV] "MYSQL_UNIX_ADDR" redefined

[James Cox]

> Jani Taskinen wrote:
> > Your build stuff (gcc 3.1 installation done wrong?) is shitnitz.
>
>   Hm, how come everything else works fine?
>

this seems to be a problem with the MySQL build, not ours - they need to
wrap their MYSQL_UNIX_ADDR definition around an #ifndef so if a previous
configure does define it, it won't get redefined and cause warnings.

+
+#ifndef MYSQL_UNIX_ADDR
 #define MYSQL_UNIX_ADDR"/tmp/mysql.sock"
+#endif

in mysql/mysql_version.h (libmysql) should do it.


 -- james


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

RE: [PHP-DEV] "MYSQL_UNIX_ADDR" redefined

[James Cox]

can you email me a copy of your php_config.h and config.log, please?

 -- james

> -Original Message-
> From: Sebastian Bergmann [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, July 02, 2002 4:57 PM
> To: [EMAIL PROTECTED]
> Subject: [PHP-DEV] "MYSQL_UNIX_ADDR" redefined
> 
> 
> In file included from /usr/local/mysql/include/mysql/mysql.h:80,
>  from /usr/src/php4/ext/mysql/php_mysql.c:65:
> /usr/local/mysql/include/mysql/mysql_version.h:15:1: warning:
> "MYSQL_UNIX_ADDR" redefined
> In file included from /usr/src/php4/TSRM/tsrm_config.h:1,
>  from /usr/src/php4/TSRM/tsrm_config_common.h:13,
>  from /usr/src/php4/TSRM/tsrm_virtual_cwd.h:26,
>  from /usr/src/php4/main/php.h:327,
>  from /usr/src/php4/ext/mysql/php_mysql.c:31:
> /usr/src/php4/main/php_config.h:1732:1: warning: this is the location of
> the previous definition
> 
> -- 
>   Sebastian Bergmann
>   http://sebastian-bergmann.de/ http://phpOpenTracker.de/
> 
>   Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/
> 
> -- 
> 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] Re: Small CGI Serve

[James Cox]

>
> I have found if you set the environment var "REDIRECT_STATUS" to "FALSE"
> then it works
>
> Someone explain?
> >
> > Having finally found out how to pass the Environment vars onto PHP, I am
> > stumpted to find that PHP wasn't reading them and putting them in their
> > place (GET vars).
> >
> > I tried changing the exe from the php-cli to just php.  This
> now brings up
> a
> > security error and I cannot find a solution
> >
> > Can anyone help?

the REDIRECT_STATUS env var is for cgi security, and is a workaround given
some webservers don't set it properly. That php wasn't showing env vars
sounds to me like a register globals problem, and you having it set to off.

 -- james


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

RE: [PHP-DEV] CVS fails to compile (ext/mysql)

[James Cox]

This would likely be me.

 what OS? can you give me a copy of config.log and php_config.h ?

Thanks,

 -- James

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

RE: [PHP-DEV] Does (will?) php support BerkeleyDB4 yet?

[James Cox]

>  hi,
> 
>  is BerkelyDB4 supported in 5.8.0RC1?
> 
>  i note that -with-db has been deprecated, and that only -with-db2,
>  -with-db3 and -with-dbm remain ..
> 
>  thanks for any comments/pointers.

Hey, could i get a copy of 5.8.0RC1 please?

 -- james 

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

Re: [PHP-DEV] Re: [PHP-EVANGELISM] ANN: QA & Evangelism Call to Arms @ LinuxTag

[James Cox]

When everyone gets into linuxtag, we can work out the best time for a meeting
and take it from there, i think.


 -- james
___
This mail sent using V-webmail - http://www.v-webmail.co.uk


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